| 00:06.13 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:06.13 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:07.54 | dan_j | Any idea why 'ast_sip_location_retrieve_aor(aor_name)' would stop asterisk from qualifying realtime endpoints that require qualifying? |
| 00:08.11 | dan_j | Is there anything that needs releasing when using that function? |
| 00:20.03 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:20.03 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 00:22.53 | dan_j | Just saw that and added it, but it doesnt seem to help with the lack of qualifying. |
| 00:23.36 | file | I don't know otherwise. |
| 00:23.45 | dan_j | ok. will keep at it. thanks. |
| 00:31.19 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 04:09.20 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 05:18.34 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 06:53.45 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 07:02.19 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:13.49 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.45) |
| 07:56.07 | *** join/#asterisk-dev bof22 (~Thunderbi@80.12.37.218) |
| 07:59.44 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:04.24 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:10.06 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:11.24 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::152e) |
| 08:20.43 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 08:21.10 | tsearle | good morning world! |
| 08:55.58 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 09:36.38 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:40.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 11:03.14 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 11:12.24 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.182.47) |
| 11:17.49 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-240-195.try.wideopenwest.com) |
| 11:17.49 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 11:45.24 | *** join/#asterisk-dev oej (~oej@host-95-195-215-140.mobileonline.telia.com) |
| 11:45.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:08.04 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 12:11.05 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 12:43.02 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 12:44.03 | gtjoseph | @wdoekes: got a sipp question for you... is there any way other than an oocsf to start a scenario by sending a REGISTER but then accepting an INVITE, NOTIFY or OPTIONS? |
| 12:57.15 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-zmgiezoofkdcpuqi) |
| 12:57.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:16.22 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.182.47) |
| 14:05.08 | seanbright | why would you NOT want to optimize the local channels? |
| 14:10.33 | file | optimizing can complicate the events/CDRs/etc, and keeping it in ensures that the Dial() remains active after answer |
| 14:14.27 | dan_j | I'm having a problem using ast_sip_location_retrieve_aor when looping through an endpoints aors. When I use it, it stops asterisk from performing qualifies on realtime endpoints. Endpoints defined in loca files seem fine. |
| 14:14.58 | dan_j | If someone has a spare few minutes, please can you take a glance at this and see if you can spot anything obvious. If there is nothing obvious, I'll give up on this one for now. |
| 14:15.04 | dan_j | https://gerrit.asterisk.org/#/c/5162/6/res/res_pjsip/pjsip_configuration.c |
| 14:17.43 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ijpapcbsqztaipyc) |
| 14:17.43 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:23.39 | file | I do not have a reason, and the interactions are rather complex |
| 14:30.06 | tsearle | @file I should have the pjsip patch corresponding to the noexten testcase I pushed to gerrit last friday ready tomorrow |
| 14:30.29 | tsearle | when I push that patch into gerrit, what's the best way to indicate the 2 gerrits are linkeD? |
| 14:30.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:30.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:30.53 | file | the only way to indicate they are linked is by the topic |
| 14:31.01 | file | normally everything should have a JIRA issue, so they'd use the same one |
| 14:31.27 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:31.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.30 | stefan27 | seanbright, out of curiousity, were you talking about the two different behaviors you get if you Dial Local/extension@context[/n] with and without the /n ? |
| 14:35.35 | seanbright | stefan27: i understand the difference between the two. i didn't understand why you would not want to optimize. |
| 14:39.23 | stefan27 | our current dialplan depends on the /n option, because we have an external java-client (which was built for asterisk 1.2 but is still functional) that does things depending on the state of the channels... We have local channels for many different purposes, and the client must be able to track the state of all channels in all call chains |
| 14:39.45 | stefan27 | I'm sure it could all be rewritten to allow optimizations though, but cdrs and lots of magic would break for us :) |
| 14:40.02 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-xgrrfmacavlerhdz) |
| 14:40.02 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:46.35 | tsearle | is there a way to add a topic to an existing gerrit? |
| 14:46.53 | seanbright | given an ast_channel *, is there a straight-forward way to determine which, if any, bridges that channel is in? |
| 14:47.00 | seanbright | tsearle: yes |
| 14:47.13 | seanbright | tsearle: you have to be signed in |
| 14:47.19 | seanbright | (top right) |
| 14:47.32 | seanbright | and click the little pad icon next to Topic |
| 14:48.19 | seanbright | or if you're using git review, you can pass the -t option |
| 14:49.01 | file | seanbright: there's an API call you can use to get the bridge |
| 14:49.08 | tsearle | ok so git reveiw -t of an already comitted review will just add a topic |
| 14:49.10 | seanbright | file: great. thanks. |
| 14:49.23 | seanbright | tsearle: not 100% sure |
| 14:49.31 | seanbright | it would be easier to just use the web interface |
| 14:49.54 | tsearle | ok |
| 14:50.45 | tsearle | so tomorrow I'll make a jira with the patch, then push the patch in gerrit & update the testsuite to point to that jira with the patch |
| 14:50.59 | tsearle | I suppose no reason to include a tarball of the testcase in the jira |
| 14:52.03 | file | nope |
| 14:54.24 | wdoekes | gtjoseph: I don't see why you'd need -oocsf (I have never used that). I'm thinking you can surely send a REG and then wait for INVITE with optional="true" (and the others as alternatives, with appropriate next="label"). you don't need to mention the original [call_id] ever afterwards, just use [last_Call-ID:] when building replies |
| 14:54.41 | gtjoseph | nope. |
| 14:55.17 | gtjoseph | the INVITE element gets ignored and the incoming INVITE gets an error with a non matched call id |
| 14:55.46 | gtjoseph | with optionsl, i get an error (that i can't remember) |
| 14:55.52 | wdoekes | meh. you're right. I forget that it does that |
| 14:56.19 | wdoekes | do you need it in a single scenario? or can you get away with firing up a second sipp instance? |
| 14:56.36 | gtjoseph | they have to be listening on the same ports |
| 14:57.14 | wdoekes | -p will help you there, if there aren't any other port stealing processes on that box |
| 14:57.38 | gtjoseph | i'm checking that asterisk sends an INVITE using the same transport as the one it received the REGISTER on |
| 14:57.50 | gtjoseph | so they NEED to be on the same port |
| 14:58.33 | gtjoseph | you mentioned using '///' to attempt it in an old post but i haven't had time top mess with it. |
| 14:58.52 | wdoekes | I understand that. in my experience firing up sipp twice works fine. just make sure you get a proper free port to begin with |
| 14:59.11 | wdoekes | /// will only help you when you're creating the call-ids |
| 14:59.19 | gtjoseph | hmmm. to instances on the same port? how do you control which gets what message? |
| 14:59.35 | wdoekes | no, sequential, not parallel |
| 14:59.43 | gtjoseph | oh i gotcha |
| 15:00.29 | gtjoseph | i'm not sure i can do that from inside a single testsuite test though. |
| 15:00.38 | gtjoseph | the oocsf does work |
| 15:00.59 | gtjoseph | just takes a little extra |
| 15:01.52 | wdoekes | starting sipp twice also takes extra; so I guess you have a choice between two evils |
| 15:35.25 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 15:54.48 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 16:34.24 | seanbright | well... it's official |
| 16:34.30 | seanbright | app_queue is a cluster fuck |
| 16:34.56 | seanbright | i can't even watch for device state changes because ringinuse makes it pointless |
| 16:51.39 | seanbright | what is the most "elegant" way of determining if a given ast_channel * is a local channel? |
| 16:52.05 | seanbright | strncasecmp(chan, "Local/", 6) |
| 16:52.06 | seanbright | ? |
| 16:53.35 | gtjoseph | channel_tech->type? |
| 16:54.19 | seanbright | hmmm |
| 16:56.35 | seanbright | yeah that'll work |
| 16:56.36 | seanbright | thanks |
| 17:07.43 | gtjoseph | @putnopvut: i'm having an issue with ast_sdp_state_get_local and ast_sdp_state_set_remote actually changing the state of the machine. Would you mind if I removed that logic for now? |
| 17:08.24 | gtjoseph | You'd never be able to call either one twice |
| 17:09.23 | putnopvut | Yeah, if you think it'll help, that's fine. |
| 17:09.31 | gtjoseph | i'm also not comfortable with automatically translating them either. |
| 17:10.00 | gtjoseph | i'm gonna split them to get_local_sdp and get_local_impl |
| 17:10.12 | gtjoseph | etc. |
| 17:23.50 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-ubrmdctptmuevuqg) |
| 17:23.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:24.02 | mjordan | gtjoseph: re: commit dbc787b0d |
| 17:24.12 | mjordan | I think this might have had some unintended consequences on the Test Suite |
| 17:24.22 | gtjoseph | looks |
| 17:24.33 | mjordan | unless I'm a ways back and the test suite was updated as well |
| 17:24.59 | mjordan | The dependency checks for Asterisk modules are going to use what is defined in asterisk.conf, which by default, is /usr/lib/asterisk/modules |
| 17:25.03 | gtjoseph | i tested it thoughoughly with testsuite |
| 17:25.18 | mjordan | how does the dependency checking work then if the modules are in /usr/lib64? |
| 17:25.36 | gtjoseph | <PROTECTED> |
| 17:25.47 | mjordan | And I ask because it is failing locally for me :-) |
| 17:25.49 | gtjoseph | i think make install updates it |
| 17:25.59 | gtjoseph | really |
| 17:26.03 | gtjoseph | do you use astroot? |
| 17:26.06 | mjordan | no |
| 17:26.14 | mjordan | which wasn't a prerequisite previously |
| 17:26.16 | gtjoseph | what distro and arch? |
| 17:26.22 | mjordan | ubuntu 14.04 |
| 17:26.26 | mjordan | 64-bit |
| 17:26.37 | gtjoseph | been running on @file's jenkins nodes ok |
| 17:27.05 | gtjoseph | do you have the subsequent patch that cleans up old installs? |
| 17:27.11 | mjordan | I'm running on latest 14. |
| 17:27.23 | rmudgett | wonders why people are using @ to indicate a reference in IRC when it isn't needed. |
| 17:27.23 | gtjoseph | yeah ok |
| 17:27.27 | mjordan | And this was a fresh build, as I hadn't rebuilt my Asterisk install on a clean laptop |
| 17:27.34 | mjordan | @rmudgett: Because I'm used to it |
| 17:27.38 | gtjoseph | because i'm used to the "other" thing we're forced to use |
| 17:27.42 | gtjoseph | :) |
| 17:28.02 | gtjoseph | what's the error exactly? |
| 17:28.13 | gtjoseph | can you run asterisk from the command line? |
| 17:29.09 | mjordan | Asterisk runs fine. The error is that the Test Suite dependency checking fails to find the Asterisk modules. |
| 17:29.32 | mjordan | Which is expected, since the Test Suite looks to either (a) what is specified in asterisk.conf, or (b) defaults to /usr/lib/asterisk/modules |
| 17:29.42 | mjordan | Since the section is not required in asterisk.conf, you end up with the default. |
| 17:29.49 | mjordan | Particularly if you started from the basic-pbx build. |
| 17:30.16 | mjordan | If you go with samples, it does do the correct thing |
| 17:30.38 | mjordan | Which, I guess, since we always assumed you would start with samples, is okay. I just hate installing the sample configs, and was surprised that this was changed in a mainline branch. |
| 17:30.47 | mjordan | Much like renaming modules, small things break people. |
| 17:31.32 | gtjoseph | well the testsuite depends on the samples. |
| 17:31.56 | gtjoseph | but the interesting part is that un ubuntu 14, there'sd no /usr/lib64 anyway so |
| 17:32.03 | gtjoseph | i'm not sure where it's failing |
| 17:33.39 | gtjoseph | did asterisk correctly install to /usr/lib/asterisk/modules? |
| 17:35.27 | gtjoseph | well this sucks... Command 'core show calls' cannot be run during shutdown |
| 17:46.56 | rmudgett | gtjoseph: What is the need to backport https://gerrit.asterisk.org/#/c/5169/ to v13 and v14? |
| 17:47.57 | gtjoseph | keeping menuselect consistent |
| 18:39.41 | seanbright | rmudgett: please be gentle, re: https://gerrit.asterisk.org/5149 |
| 18:53.07 | seanbright | is it worth putting up a review for my patch on ASTERISK-26835? |
| 18:53.18 | seanbright | i'd call it a workaround at best |
| 19:01.22 | rmudgett | I don't see how it fixes anything. If Ross would ever actually run with MALLOC_DEBUG he may actually provide useful backtraces. |
| 19:06.18 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 19:23.02 | gtjoseph | anyone want to suggest an algorithm for determining sdp session id and version? sdp->origin.version = sdp->origin.id = tv.sec + 2208988800UL; |
| 19:23.16 | gtjoseph | other than that...that is |
| 19:31.27 | seanbright | i would use an ntp format timestamp |
| 19:31.33 | seanbright | because that is what the rfc says |
| 19:31.44 | gtjoseph | yeah |
| 19:31.47 | seanbright | but i am just being a smartass |
| 19:31.55 | seanbright | go figure |
| 19:32.33 | *** join/#asterisk-dev tripleslash (~triplesla@unaffiliated/imsaguy) |
| 19:33.49 | gtjoseph | I was thinking t.tv_sec + 0x617374647269736bUL :) |
| 19:34.56 | seanbright | nice |
| 19:36.03 | seanbright | can it be an arbitrarily long string of digits? |
| 19:36.37 | gtjoseph | just says "number" |
| 19:36.40 | seanbright | yeah |
| 19:37.07 | gtjoseph | Ha! pjproject has it only being a 32 bit int |
| 19:37.32 | seanbright | well that limits things a bit |
| 19:37.39 | seanbright | signed or unsigned? |
| 19:37.44 | gtjoseph | at least iut's unsigned |
| 19:38.16 | gtjoseph | the odd thing is that they're adding the 2208988800UL to current seconds |
| 19:40.48 | seanbright | what is that magic number? |
| 19:41.09 | gtjoseph | not a clue |
| 19:41.27 | seanbright | ah. seconds between 1900 and 1970 |
| 19:41.41 | gtjoseph | ah, that makes it a ntpo timestamp |
| 19:45.07 | gtjoseph | can't even add fractional seconds to it though |
| 19:47.54 | gtjoseph | putnopvut: what do you think? should we represent the session id and version as an opaque string internally and sprintf 2-bit int into it? |
| 19:48.57 | gtjoseph | or continue to store them as uint64 but only set them to uint32> |
| 19:48.59 | gtjoseph | ? |
| 19:52.38 | putnopvut | GOtta catch up. Just a sec. |
| 19:54.17 | gtjoseph | i think since the version has to increment it'd probably be better to leave them as uint64. |
| 19:54.55 | putnopvut | Yeah, typical wisdom is that if you're actually treating a number as a number (i.e. doing calculations) then storing as a number is probably best. Since it does require incrementing, it's probably best to store as an actual number. |
| 19:55.15 | gtjoseph | yep |
| 20:21.14 | *** join/#asterisk-dev jkroon (~jkroon@154.73.32.15) |
| 20:31.00 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-176-140-167.ph.ph.cox.net) |
| 21:02.01 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 21:07.44 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 21:45.42 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 22:22.28 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:22.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:23.33 | cresl1n | waves goodbye |
| 22:45.01 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:45.01 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:26.03 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ijpapcbsqztaipyc) |