| 00:40.20 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 02:02.08 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 02:37.25 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-yhcijyubkqxbkmwr) |
| 06:52.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.156) |
| 06:53.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.156) |
| 06:54.48 | *** join/#asterisk-dev chare (322f529d@gateway/web/freenode/ip.50.47.82.157) |
| 06:56.26 | chare | what does google voice ending xmpp mean for asterisks? |
| 07:01.34 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:01.43 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:01.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:03.04 | chare | is anyone alive here? |
| 07:35.25 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:16.40 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 08:16.40 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:27.23 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 08:38.07 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 08:43.17 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 08:49.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.149) |
| 09:05.57 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:15.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93.191.18.82) |
| 09:33.52 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:25.33 | *** part/#asterisk-dev chare (322f529d@gateway/web/freenode/ip.50.47.82.157) |
| 11:25.36 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:25.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:51.28 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-90-222.user.veloxzone.com.br) |
| 12:41.50 | *** join/#asterisk-dev infobot_ (~infobot@rikers.org) |
| 12:41.50 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 12:42.59 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 12:42.59 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 12:44.23 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 12:54.15 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:54.15 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 13:02.43 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 13:08.58 | hexanol | I need an ao2_container which is used only to link / unlink objects and apply a callback to all objects in it |
| 13:09.07 | hexanol | I was wondering what was the "best" parameter to create such a container |
| 13:09.11 | hexanol | I tought about "ao2_container_alloc(1, NULL, NULL)" |
| 13:09.22 | hexanol | Is it ok ? Should I use more than 1 bucket ? Should I use a hash function that hash on the pointer address ? |
| 13:17.42 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:24.04 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 13:25.27 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:27.35 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 13:33.54 | *** join/#asterisk-dev pc-m (~Thunderbi@modemcable094.94-70-69.static.videotron.ca) |
| 13:40.16 | *** join/#asterisk-dev Jacke (~jacke@iam.ss7.pl) |
| 13:57.09 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:57.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:58.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:58.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:10.32 | oej | Hello folks! |
| 14:13.12 | sruffell | waves |
| 14:31.06 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 14:55.11 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-xekprcyjcvbtriqx) |
| 14:58.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.180) |
| 15:03.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.180) |
| 15:09.32 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.180) |
| 15:10.40 | opticron | X-Rob, are you xrobau on jira? I've got a patch on ASTERISK-23081 that could use some testing |
| 15:11.39 | Qwell | opticron: he is, and he's sleeping (probably. he's a bad Australian) |
| 15:11.52 | opticron | ah |
| 15:12.33 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:12.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:23.33 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-zqlyksvxwtrlbllb) |
| 15:23.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:25.03 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-bqksfcridcfvcfva) |
| 15:28.33 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:30.20 | wdoekes | wow, apparently my manager didn't have 5038 because of a broken SHELL() command yesterday (after which asterisk had been restarted).. sh -c grep \"^+31... holds the listening socket |
| 15:30.50 | wdoekes | quite unexpected, as it should've been closed on exec/fork |
| 15:31.41 | mjordan | weird. |
| 15:36.57 | wdoekes | wait, not so weird, as popen() doesn't get the 'e' flag |
| 15:39.28 | wdoekes | or no.. that applies to its new fd's, not all fd's of the forked child |
| 15:40.26 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-cwccchjkjndnmiqv) |
| 15:40.26 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:46.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:3e97:eff:fe14:ef66) |
| 15:57.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.129) |
| 16:05.10 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:05.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:22.15 | file | opticron, much nicer. |
| 16:34.08 | opticron | :D |
| 16:34.49 | opticron | hopefully there's not too much to rage on |
| 16:35.09 | opticron | the infrastructure is now the vast majority of that patch |
| 16:36.23 | file | nothing major |
| 16:40.15 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 16:50.22 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 16:50.22 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:57.17 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.180) |
| 17:06.31 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 17:10.54 | mjordan | file: looking at your multi-homed routing patch, my first thought was: gee, we really do need a new module loader. |
| 17:14.50 | file | mjordan, and a single apple. |
| 17:16.03 | mjordan | file: what is the effect of having the multi-homed module loaded with res_pjsip_nat? In particular, say I have Asterisk behind a NAT and it has two interfaces (who knows why, but let's just pretend). On transmitted messages, what IP address gets placed in, say, the Contact header? |
| 17:16.26 | file | NAT occurs after multi-homed |
| 17:16.54 | mjordan | k, so we'd start off by replacing it with whatever route won out in multi-homed, then go through and blow them away again if we needed to |
| 17:17.00 | file | yes |
| 17:23.23 | *** join/#asterisk-dev outtolunc (~me@c-67-170-214-55.hsd1.ca.comcast.net) |
| 17:28.19 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.131) |
| 17:35.49 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@91.206.59.132) |
| 18:02.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.110) |
| 18:10.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.133) |
| 18:37.20 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-qhihefdilpzbvvgd) |
| 18:40.24 | tm1000 | its too quiet in here….file mjordan break something please |
| 18:40.48 | file | breaks reality |
| 18:40.54 | opticron | nooooo, I need that! |
| 18:43.01 | jsmith | Reality is an illusion -- just look at "reality" television :-p |
| 18:43.53 | sgriepentrog | So on my sip_one_legged_transfer test failure, I compared the full log with a passing log that jbigelow gave me, and on mine it just never gets the replaces invite. I've rebuilt pjsua per puppet's procedure, no go. I'm down to trying ubuntu and an earlier copy of pjprj |
| 18:45.16 | jsmith | mjordan: Did you ever approach the pjproject folks about https://github.com/asterisk/pjproject/issues/3, perchance? |
| 18:45.27 | jsmith | just needed the opportunity to use the word "perchance" today |
| 18:46.31 | file | he hasn't yet afaik |
| 18:46.42 | jsmith | OK |
| 18:46.56 | jsmith | Meanwhile, Linux distros just keep on rolling... |
| 18:47.13 | jsmith | returns to his regularly scheduled programming |
| 18:48.08 | mjordan | jsmith: nope, dropped the ball on that one. I'll get something together on it this week |
| 18:55.03 | sgriepentrog | Finally success: answer is current svn.pjsip.org code will not work to build pjsua, have to use older version |
| 19:00.37 | sgriepentrog | When you think you've tried everything, the one thing you haven't yet tried is invariably the answer. |
| 19:03.02 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:04.28 | mjordan | sgriepentrog: weird. Hopefully we didn't screw up their build system for that. |
| 19:04.59 | mjordan | do you know what the issue is between the two versions? |
| 19:05.13 | sgriepentrog | Not sure it was build - at least, the script I used was the same just switched to the tarball that puppet uses. |
| 19:05.42 | sgriepentrog | I.e. it has always compiled, just wouldn't issue the Replaces invite. |
| 19:06.08 | sgriepentrog | I can diff them and try to determine... |
| 19:07.03 | sgriepentrog | Or I could just rig a script to sneak backwards through git commits until it works again. |
| 19:09.07 | mjordan | hm. |
| 19:09.14 | mjordan | Might be worthwhile reporting the issue up stream |
| 19:10.36 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.110) |
| 19:15.48 | X-Rob | opticron: I'm here. Patch me up! |
| 19:16.11 | opticron | X-Rob, it's on the issue https://issues.asterisk.org/jira/browse/ASTERISK-23081 |
| 19:16.18 | *** join/#asterisk-dev pc-m (~Thunderbi@modemcable094.94-70-69.static.videotron.ca) |
| 19:21.24 | X-Rob | opticron: ooh yeah I saw that, thanks |
| 19:21.44 | X-Rob | I was using our RPM, but I'm now able to play with source builds again |
| 19:21.51 | mjordan | X-Rob: if you're up for testing... |
| 19:21.56 | X-Rob | mjordan: always. |
| 19:22.01 | mjordan | X-Rob: there's a patch up on review board right now as well for multihomed support |
| 19:22.07 | X-Rob | OH. MY. GLOB. |
| 19:22.12 | mjordan | it's an entirely new module :-) |
| 19:22.17 | X-Rob | Wow. |
| 19:22.25 | mjordan | it adds a bit of extra processing in Asterisk, so file stuck it there so if you don't need it, you don't have to load it |
| 19:22.47 | mjordan | https://reviewboard.asterisk.org/r/3102/diff/raw/ |
| 19:25.48 | *** join/#asterisk-dev danjenkins_ (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:28.49 | mjordan | sgriepentrog: do you have an update on the valgrind support for the test suite? I really, really don't want to check in the PEP 8 changes until you get yours in :-) |
| 19:29.50 | mjordan | and before it gets too late in the day, can I get some love on https://reviewboard.asterisk.org/r/3107/ and https://reviewboard.asterisk.org/r/3099/? :-D |
| 19:31.00 | opticron | I need new eyes after going through the PEP8 changes... |
| 19:31.18 | putnopvut | opticron: more power to you |
| 19:31.22 | opticron | at least it went faster after the 6th page |
| 19:31.35 | sgriepentrog | mjordan: I was presuming to update valgrind support after resyncing it with your pep8 changes. I don't have a *lot* of work to do on it, but was still treating this as back-burner. |
| 19:33.05 | tzafrir | sruffell, you need -maxdepth for find |
| 19:33.33 | tzafrir | There's also 'setopt -s nullglob' if we want to assume bash |
| 19:35.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 19:36.00 | sruffell | yikes..I opened a can of worms. I should have just left it the way you had it originally. |
| 19:36.37 | sruffell | although, if we can stay away from bashims as much as possible I'm all for it. |
| 19:37.10 | sruffell | so…what's your opinion about the best way to handle this? |
| 19:37.26 | sruffell | stick with grep -v '*' or a variation of find? |
| 19:39.01 | pabelanger | jsmith, Have you had any transfer deadlocks with app_queue in the past? |
| 19:40.58 | jsmith | pabelanger: deadlocks, no. Crashes, yes. See ASTERISK-20226 |
| 19:41.24 | jsmith | pabelanger: But thankfully, putnopvut wrote us a patch and we haven't had any crashes in the past 14 months |
| 19:41.46 | jsmith | pabelanger: FWIW, that patch really helped leifmadsen as well |
| 19:42.43 | leifmadsen | no crashes (in that area of the code) since commit |
| 19:42.51 | leifmadsen | were getting them 1-3 times a day depending on server and load |
| 19:42.51 | putnopvut | I think I remember that one. That's the one where I adjusted the refcounting in SIP attended transfers. |
| 19:43.19 | pabelanger | jsmith, Ya, not running that one... yet, |
| 19:43.22 | sruffell | tzafrir: also, just FYI, how do you handle a system with a configuration already in a place, then adding a new device and re-running dahdi_genconf? It seems like I have to blow away the existing configs in /etc/dahdi or hand run dahdi_assign_spans before running the generator since the presence of the /etc/dahdi/span-assignments prevents the new spans from being assigned. |
| 19:43.25 | pabelanger | looks like I just ran into ASTERISK-19639 |
| 19:43.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.135) |
| 19:43.54 | jsmith | pabelanger: If you're not running that patch, do so now... it'll save you *all* kinds of headaches (related to memory corruption) |
| 19:43.54 | pabelanger | let me backport ASTERISK-20226 and get some testing on it |
| 19:44.02 | pabelanger | jsmith, ack'd |
| 19:44.04 | jsmith | pabelanger: Backport to 1.4? |
| 19:44.08 | pabelanger | 1.8.7.1 |
| 19:44.24 | jsmith | pabelanger: Seriously? |
| 19:44.33 | jsmith | can't figure out why people are running such old versions of 1.8 |
| 19:44.45 | pabelanger | yup |
| 19:44.46 | tzafrir | sruffell, not completely blow away. The theory is: you configure it as you please, and then you run dahdi_genconf, which records the existing assignments |
| 19:44.55 | pabelanger | jsmith, stable for us |
| 19:44.58 | tzafrir | I can't think of anything better |
| 19:45.10 | pabelanger | however, we are now moving into 12 for our current development |
| 19:46.04 | sruffell | hmm…so it's more like dahdi_saveconf? :) |
| 19:46.27 | sruffell | but yeah…I've been thinking about how to handle this…I've not had any epiphanies yet except to do what you said. |
| 19:47.27 | sruffell | I was thinking that dahdi_genconf might auto_assign any spans that weren't taken care of by udev? |
| 19:48.00 | pabelanger | jsmith, Oh, I know why I didn't backport it already. We don't use connected line updates, so we are not affected. However, I'll set some time aside to test and merge |
| 19:49.07 | jsmith | pabelanger: We didn't really use connected line updates, but the patch made a world of difference for us |
| 19:51.27 | putnopvut | Yes, the crash tended to happen during connected line operations, but the actual problem lay deeper. |
| 19:51.46 | leifmadsen | jsmith: that overview you gave me that one day of what the problem was might not be a bad idea to add to the wiki for historical purposes |
| 19:52.06 | leifmadsen | ya, we don't use connected line appearances really either; the issue for us was large use of AMI and chan_sip together with app_queue |
| 19:54.54 | mjordan | jsmith: ASTERISK-19639 looks to be different than the memory corruption/crash, unless I'm missing something |
| 19:55.30 | mjordan | sighs |
| 19:55.33 | mjordan | I really need to scroll up further |
| 19:55.59 | mjordan | sgriepentrog: np - if you don't mind losing the commit race on that at least |
| 19:56.22 | mjordan | and yeah, opticron, thanks. Believe it or not, that was my holiday |
| 19:58.45 | sgriepentrog | mjordan: not at all, will make it easier matching up to proper pep8 coding style |
| 20:08.10 | opticron | mjordan, you must really hate holidays |
| 20:08.24 | mjordan | I do. No coal for anyone. |
| 20:12.18 | X-Rob | mjordan: any news on the codec issue, since I'm building from source and applying patches |
| 20:12.22 | X-Rob | ? |
| 20:15.34 | mjordan | X-Rob: we haven't hit it yet |
| 20:16.22 | X-Rob | Poot. |
| 20:16.29 | mjordan | sorry :-\ |
| 20:16.31 | mjordan | it's high on the list |
| 20:16.50 | mjordan | but there's some subtle behavior in that's going to take a bit to shake loose |
| 20:17.04 | X-Rob | yeah, file said he knew what the cause was |
| 20:17.22 | X-Rob | in a global overview sorta way |
| 20:19.05 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:25.34 | X-Rob | opticron: after building from current SVN, I can't duplicate my original error, either. |
| 20:26.07 | opticron | hah |
| 20:26.35 | opticron | I guess I'll just put it up on general reviewboard, then |
| 20:26.45 | X-Rob | opticron: sorry 8-( |
| 20:27.13 | mjordan | well, it's not like there weren't other problems with the CLI command tab completion |
| 20:27.18 | opticron | it's cool |
| 20:27.26 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.110) |
| 20:27.28 | opticron | mjordan, I'm pretty sure that's most of what I fixed |
| 20:29.28 | tzafrir | sruffell, sorry: was away. saveconf to where? |
| 20:30.13 | tzafrir | dahdi_genconf's handling of system.conf is different: it is completely generated and not saved |
| 20:31.03 | tzafrir | I wonder if it's possible to have a dumpconfig for system.conf |
| 20:31.38 | tzafrir | What information is missing in sysfs? |
| 20:33.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.110) |
| 20:34.10 | mjordan | pabelanger: are you going to take the patch on ASTERISK-19639 and put it up for review? |
| 20:34.50 | sruffell | I think the channel assignments for FXO / FXS. |
| 20:34.56 | sruffell | But I think we can change that. |
| 20:35.07 | pabelanger | mjordan, as soon as I find out how to apply it against http://svnview.digium.com/svn/asterisk/branches/1.8/apps/app_queue.c?r1=378663&r2=378662&pathrev=378663 I will |
| 20:35.14 | pabelanger | that code patch changed |
| 20:35.19 | pabelanger | path* |
| 20:35.40 | pabelanger | Trying to understand how the patch fixes the issue |
| 20:40.38 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:40.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:42.54 | mjordan | I can guess how it fixed the issue in that version of 1.8, but I doubt it's still a problem. During the transfer, we're locking the channel, followed by the queue. Without his patch, we hold the queue lock, and have gone off to get the device state of something. This requires locking the channels container and the channel, causing an inversion. |
| 20:43.06 | mjordan | However, we now no longer look at the device state at that point - we merely clear it from the user. |
| 20:43.36 | mjordan | guess we already fixed our shitty code ;-) |
| 20:44.27 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:44.30 | pabelanger | Hmm... |
| 20:44.40 | pabelanger | then that patch is not the fix |
| 20:44.53 | pabelanger | I think I am hitting the same issue |
| 20:45.07 | pabelanger | it locks look the same, as well as the backtrace |
| 20:45.18 | pabelanger | but I have the patch from richard applied |
| 20:45.43 | pabelanger | looks like, queue member does a transfer just as a new caller enters the queue and rings a member |
| 20:45.44 | pabelanger | lock |
| 20:46.35 | pabelanger | mjordan, get_queue_member_status() is holding the lock right? |
| 20:48.43 | pabelanger | okay |
| 20:48.46 | pabelanger | I think I see it now |
| 20:48.50 | mjordan | get_queue_member_status is calling into the device state core. If the device state core doesn't have the state of the channel, it will end up finding the channel that it needs to go get the state from - which involves locking the channels container and the channel. |
| 20:49.02 | pabelanger | we are just moving get_queue_member_status before we do the lock |
| 20:49.13 | mjordan | the lock of the queue, correct. |
| 20:49.17 | mjordan | However, since Richard nuked out the location of that patch, whatever you're hitting sounds different. |
| 20:49.51 | mjordan | without a backtrace, however, it's hard to know for sure, since I'm not sure who called get_queue_member_status |
| 20:50.06 | mjordan | but since you're running a pretty heavily patched version, it may not be in the latest 1.8 either |
| 20:52.08 | X-Rob | mjordan: Good news! http://pastebin.com/dzxcLrqZ |
| 20:52.17 | pabelanger | so, I found this pretty cool script that graphs locks! http://minus.com/i/1LBHcftDwBXu |
| 20:52.28 | pabelanger | generated from: http://pastebin.com/WBq4DAQq |
| 20:52.46 | X-Rob | I can now call between 300 and they work. HOWEVER. When I do a Dial(PJSIP/300) only one of them rings. |
| 20:52.51 | pabelanger | which is from gdb: http://pastebin.com/qP760Qz0 |
| 20:53.16 | mjordan | X-Rob: oooo, two devices registered to a single endpoint |
| 20:53.48 | mjordan | X-Rob: correct, you'll need https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Function_PJSIP_DIAL_CONTACTS |
| 20:54.04 | pabelanger | Thread 5 and Thread 6 are waiting on each other |
| 20:54.11 | mjordan | it's a convenience dialplan function that does that for you. You can technically do it yourself with a lot of magicry, but it's a bit of a pain |
| 20:55.01 | X-Rob | mjordan: thanks. Investigating. |
| 20:55.22 | file | one day... the core will support it |
| 20:55.50 | mjordan | pabelanger: right, but that doesn't show the call stack in app_queue |
| 20:59.22 | mjordan | pabelanger: that's a different deadlock that you have |
| 20:59.46 | pabelanger | Ya |
| 20:59.49 | pabelanger | I see that now |
| 20:59.55 | X-Rob | mjordan: ok. That's an awesome function. Tell me why I shouldn't be using that for EVERY PJSIP Dial command? Because I think I should be? |
| 21:00.05 | pabelanger | locks a little further down |
| 21:03.00 | mjordan | its also happening between your AMI execution and the attended transfer. Since you're patched, though, I'm not sure why. The AMI execution doesn't appear to grab a channel lock in 1.8, and locks things in the queue -> member order, which is what update_queue also does (called from the fixup). If we attempted to grab a channel lock in the AMI action I'd expect bad things, but I don't see that there. |
| 21:03.08 | mjordan | X-Rob: you probably should be |
| 21:03.26 | mjordan | unless you want the granularity of dialing only a single PJSIP contact |
| 21:03.28 | mjordan | for some reason |
| 21:04.09 | mjordan | and it is only really needed if you have multiple devices registering to an endpoint. Otherwise, it's not needed. |
| 21:04.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.98) |
| 21:06.06 | X-Rob | and the only way I can tell if multiple devices are registering to an endpoint is by..checking to see if the dial string returned by PJSIP_DIAL_CONTACTS contains more than one result.. Yeeeeah I'm just gunna go ahead and use that for every PJSIP Dial string. |
| 21:06.32 | mjordan | pabelanger: disregard that |
| 21:07.07 | mjordan | pabelanger: your deadlock isn't that. It's between the masquerade fixup and chan_sip. I'm 99.9999% sure we fixed that. |
| 21:07.20 | pabelanger | mjordan, ok |
| 21:07.38 | mjordan | there were a lot of patches that went in and fixed a number of masquerade/chan_sip channel allocation issues in the high teens of 1.8 |
| 21:07.39 | pabelanger | checking chan_sip svn log |
| 21:07.44 | mjordan | god speed sir |
| 21:07.48 | mjordan | (upgrade!) |
| 21:07.53 | pabelanger | Am |
| 21:07.54 | pabelanger | 12 |
| 21:07.59 | mjordan | ballsy |
| 21:08.03 | pabelanger | Once I replace app_queue |
| 21:08.04 | pabelanger | :D |
| 21:08.54 | pabelanger | mjordan, actually, 1.8.7.1 has been very good to me. Aside from a few backport jsmith and leifmadsen run, we haven't had any issues |
| 21:09.17 | pabelanger | this properly is because the client changed out polycom / zoiper with an unknown sip stack we have never tested with |
| 21:09.18 | mjordan | X-Rob: I'd probably do that, personally |
| 21:09.36 | X-Rob | mjordan, file -- with that patch I can now have two devices on different subnets register and both can make and receive calls. This is awesome. However. What if I want to have 300 as a desk phone, but I also want them to be able to log in via websockets and make/receive a call via a web page? I still can't bind an endpoint to two transports, correct? |
| 21:09.51 | file | don't specify a transport |
| 21:10.04 | mjordan | file: how would it know the local_nets then? |
| 21:10.40 | file | it'll end up using the UDP transport if it's for UDP, or it'll use the open WS connection if it's for that |
| 21:11.00 | mjordan | X-Rob: you guys are going to go with a single UDP transport definition, right? |
| 21:11.24 | mjordan | I think tm1000 might have mentioned that |
| 21:11.26 | X-Rob | mjordan: with this patch, I'm going to rip out all the work I did for multiple per-interface transports |
| 21:11.33 | mjordan | sorry |
| 21:11.46 | file | it'll work either way, just don't specify an explicit transport |
| 21:12.09 | X-Rob | http://i.imgur.com/FSY85bl.png |
| 21:12.11 | file | I foresee a wiki page in my future |
| 21:12.21 | X-Rob | I hated that |
| 21:12.25 | X-Rob | so I'm happy to throw it away |
| 21:13.00 | mjordan | file: I see that too! |
| 21:13.08 | X-Rob | I remember reading something about endpoints picking the first transport in the file.. |
| 21:13.44 | tm1000 | change is good |
| 21:14.02 | X-Rob | For example, endpoint's "transport=" option, if no value is assigned then Asterisk will *DEFAULT* to the first configured transport in pjsip.conf which is valid for the URI we are trying to contact. |
| 21:14.13 | X-Rob | Ah. I read incorrectly. |
| 21:14.28 | file | res_pjsip_multihomed changes things |
| 21:14.56 | tm1000 | X-Rob: wanna change pjsip dial to dial contacts then? |
| 21:15.06 | tm1000 | X-Rob: (really how much work is that though) |
| 21:15.14 | file | ACHOO |
| 21:15.16 | X-Rob | tm1000: Trivial. |
| 21:15.35 | tm1000 | X-Rob: lets do it, as users are expecting this feature to work in 12 as it was touted by people named ward mundy |
| 21:15.51 | tm1000 | so if it doesnt work for a technically then people will be confused |
| 21:16.01 | tm1000 | plus it gives us more ammo for destroying DU mode someday |
| 21:16.13 | tm1000 | X-Rob: want a ticket for it? |
| 21:16.18 | X-Rob | tm1000: Sure. |
| 21:20.05 | tm1000 | file: mjordan with all of these changes when is 12.0.1? |
| 21:20.20 | tm1000 | as I am weary if freepbx should just not work with 12.0.0 at all at this point |
| 21:23.03 | pabelanger | mjordan, thanks for looking and the pointers. I have a few potential patches to now test |
| 21:23.23 | mjordan | tm1000: I'd say whenever you guys want |
| 21:24.20 | mjordan | tm1000: it's not a lot of work for us to create a tarball. I mentioned it to tony; I'd say when you guys are happy, we should roll a tarball so we have a line in the sand for all of the issues you've found |
| 21:24.34 | X-Rob | mjordan: +1 multihome |
| 21:24.39 | tm1000 | mjordan: maybe tomorrow then? |
| 21:24.48 | X-Rob | I built from SVN and things seem better |
| 21:24.50 | tm1000 | I want bryan (GameGamer43) to roll a new RPM so we can check |
| 21:24.55 | X-Rob | I'd love for the codec issue to be fixed tho 8-( |
| 21:24.59 | tm1000 | and then X-Rob and I can be on RPM as well |
| 21:25.04 | tm1000 | X-Rob: g722? |
| 21:25.07 | mjordan | yeah, I'm with X-Rob - there are a few patches in flight |
| 21:25.35 | X-Rob | tm1000: it's actually more than just g722, turns out it's a ball of wibbly-wobbly codecy ... stuff. |
| 21:25.43 | mjordan | along with a few other things that may be worth us fixing. But if it's giving you a headache, I'll roll one |
| 21:25.54 | tm1000 | mjordan: no we can hold off |
| 21:25.55 | mjordan | shakes his fist at format_cap.c |
| 21:26.14 | tm1000 | this is another reason we are hiding the release from the public, except for digium employees and our own |
| 21:26.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 21:26.23 | tm1000 | I can only imagine the headaches we would have already had |
| 21:26.25 | tm1000 | :-p |
| 21:26.39 | mjordan | it's been a productive couple of weeks, I'll just say that :-D |
| 21:26.40 | tm1000 | and then the useless bug and dup bugs you'd all have |
| 21:27.32 | GameGamer43 | tm1000: I can roll an rpm tomorrow morning if you want |
| 21:27.58 | tm1000 | G+1 |
| 21:28.04 | tm1000 | GameGamer43: +1 as well |
| 21:29.27 | pabelanger | mjordan, actually, if you look at http://svnview.digium.com/svn/asterisk?view=revision&revision=331774 |
| 21:29.51 | pabelanger | there is a commit to explicitly unload the queue before calling update_queue |
| 21:30.02 | pabelanger | however, in queue_transfer_fixup() we don't do that |
| 21:30.14 | pabelanger | I'm curious if that is an oversight |
| 21:30.46 | pabelanger | s/unload/unlock |
| 21:30.54 | mjordan | you can't unlock the channel there. |
| 21:30.55 | mjordan | so. Hm. |
| 21:31.13 | pabelanger | okay, maybe not |
| 21:31.24 | mjordan | Not saying it isn't a problem. |
| 21:31.42 | pabelanger | the lock is in try_calling() |
| 21:32.01 | mjordan | I'm not sure what agent list lock Matt is referring to there |
| 21:33.21 | mjordan | k. I'd file a bug for that then. But to be frank: that's going to be a beast to solve correctly. You *cannot* unlock a channel during a masquerade: that would lead to all sorts of horror shows. |
| 21:33.32 | mjordan | which means the fixup has to find another way to update the queue, which should be entertaining. |
| 21:34.24 | pabelanger | okay |
| 21:35.07 | danjenkins | in new pjsip configuration, where are you meant to specify the mailbox? in the aor type? or the endpoint type? I'm a little confused |
| 21:35.25 | danjenkins | the file seems to suggest endpoint but the wiki seems to suggest the aor |
| 21:35.51 | danjenkins | i did see a jira saying the docs werent up to scratch ;) |
| 21:36.52 | putnopvut | danjenkins: it depends on if you want solicited or unsolicited MWI notifications. |
| 21:37.12 | danjenkins | oh right |
| 21:37.13 | putnopvut | If your device sends a SUBSCRIBE in order to get MWI, then put the mailboxes in the aor |
| 21:37.25 | putnopvut | If you want to get unsolicited MWI notifications, then put the mailboxes in the endpoint. |
| 21:37.44 | danjenkins | digium phone? Think it does it as a subscribe |
| 21:37.51 | putnopvut | danjenkins: I believe you're right. |
| 21:37.57 | danjenkins | thanks putnopvut |
| 21:38.37 | pabelanger | danjenkins, so, what timezone you have to work in? |
| 21:38.41 | pabelanger | CST? |
| 21:38.54 | danjenkins | i work in gmt |
| 21:39.21 | leifmadsen | what offset? |
| 21:39.33 | danjenkins | its 6 hours from CST |
| 21:39.40 | leifmadsen | so no offset :) |
| 21:39.47 | danjenkins | ? |
| 21:39.57 | pabelanger | do you start at 9am GMT or 2pm GMT |
| 21:40.20 | danjenkins | 9 GMT, well im actually starting at 10 but you get my point |
| 21:40.23 | pabelanger | to match the guys in huntsville |
| 21:40.28 | pabelanger | cool |
| 21:40.36 | danjenkins | starting at 10 to get a bigger overlap |
| 21:40.47 | pabelanger | .notbad |
| 21:41.06 | danjenkins | yeah seems to work well |
| 21:41.47 | mjordan | putnopvut: ironically, we have an issue to clarify that in the documentation |
| 21:43.31 | danjenkins | mjordan: i found it earlier while trying to figure out what was right and wrong, and went "well that doesnt help" |
| 21:44.13 | pabelanger | On a side note, are Changelogs formatting is terrible. Going to find that patch I started a while back to make it more human readable. |
| 21:45.26 | mjordan | pabelanger: I was thinking about that too recently. Are you updating svn2log? |
| 21:48.47 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:50.55 | ipengineer | Are there any known issues in Asterisk 12 with bridging a forwarded call? I am having issues with no RTP being passed when taking an inbound call from PSTN and turning around and trying to send it back out to the PSTN |
| 21:52.20 | ipengineer | If I look at bridge show all it says it is a basic, native_rtp bridge |
| 21:54.35 | mjordan | uhm. You said PSTN. Are the channels DAHDI? |
| 21:54.57 | ipengineer | mjordan: No it is all SIP Trunks.. |
| 21:55.10 | mjordan | k. Just checking. |
| 21:55.36 | ipengineer | No prob.. What is weird is I have no problems with RTP anywhere else.. Only when trying to bridge calls in this scenario |
| 21:55.49 | mjordan | So the answer is no, I'm not aware of any issue. A native_rtp bridge is either going to be doing packet 2 packet bridging between two RTP capable channels drivers, or is going to also support remote bridging, i.e., direct media |
| 21:56.16 | ipengineer | That may be the issue right there.. |
| 21:56.34 | ipengineer | On my peers I have direct media set to off.. How would I turn direct_media off on chan_sip for this scenario since there is no peer |
| 21:56.53 | file | directmedia=no |
| 22:00.23 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 22:00.59 | ipengineer | Nah.. Didn't seem to help. That is on chan_sip since for the life of me I couldn't figure out how to get Flowroute working with PJSIP. Everything else is running on PJSIP well |
| 22:06.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.107) |
| 22:07.53 | file | ipengineer, do you have a SIP trace (chan_sip and PJSIP) you can pastebin? does rtp set debug on show anything as well? |
| 22:08.15 | ipengineer | file: Let me see what I can dig up |
| 22:14.30 | danjenkins | has anyone chucked asterisk logs into loggly before? Looking for a ready made filter... |
| 22:17.03 | ipengineer | file here is a sip trace: http://gist.github.com/zconkle/3cc800d67a70e5bca67a |
| 22:18.01 | file | your chan_sip is not configured for your NAT |
| 22:18.45 | mjordan | ipengineer: I know it isn't FlowRoute, but rnewton wrote some documentation on the Asterisk wiki about setting up a trunk with an ITSP here - https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT |
| 22:19.24 | [TK]D-Fender | <PROTECTED> |
| 22:19.31 | [TK]D-Fender | not a different tech? |
| 22:19.36 | file | he's using chan_sip |
| 22:19.47 | [TK]D-Fender | that's what I wa thinking |
| 22:20.15 | [TK]D-Fender | Contact: <sip:12149601082@192.168.3.212:5069> <- and here's where we see that NAT setup was done wrong |
| 22:21.46 | ipengineer | [TK]D-Fender: will extenip in sip.conf fix that? |
| 22:22.07 | [TK]D-Fender | if you set everything else that is part of this right... it'll do it's part |
| 22:51.05 | wedhorn | Getting an unused variable "i" in chan_dahdi with dev-mode (only). Seems to do with "i" being declared outside ifdef in dahdi_create_channel_range (r396103) |
| 22:51.22 | wedhorn | ^^^ ast12 and trunk |
| 22:53.23 | mjordan | wedhorn: interesting... what version of gcc? |
| 22:53.32 | mjordan | looks |
| 22:54.08 | mjordan | ah |
| 22:54.12 | mjordan | yup. HAVE_PRI. |
| 22:54.41 | mjordan | wedhorn: if you want to fix that's fine, otherwise I'll make a quick issue so we don't forget about it |
| 22:55.24 | wedhorn | easy to fix, but with out knowing the logic, not sure whether to move i to within or remove/move the ifdef's? |
| 22:55.34 | mjordan | move i into the range |
| 22:56.09 | mjordan | honestly, both i and x should probably be in that range. Hm. |
| 22:56.41 | wedhorn | yep, and the for loop |
| 22:56.50 | wedhorn | for x |
| 22:57.01 | mjordan | this is new in 12... |
| 22:58.17 | mjordan | ah. This is part of tzafrir's patch, I think |
| 22:58.50 | mjordan | yeah. |
| 22:58.58 | mjordan | r396474 |
| 22:59.27 | mjordan | wedhorn: I'd make a new block scope and put i and x inside of it, since the for loop is pointless without PRI. That's me, personally. |
| 23:00.59 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-64.dllstx.fios.verizon.net) |
| 23:02.27 | wedhorn | okay, and coding style? Just put { on a line by itself? |
| 23:02.30 | pabelanger | mjordan: yes, I had something going before. Just need to find it |
| 23:03.25 | snuff-work | wedhorn: =) |
| 23:03.43 | mjordan | wedhorn: pretty sure you have to for a new block scope |
| 23:03.57 | wedhorn | okay, cool |
| 23:04.15 | wedhorn | hey snuff-work, how's life treating you |
| 23:04.43 | snuff-work | busy.. wanting to do more stuff with skinny @ work but haven't had the time |
| 23:05.19 | snuff-work | midst of deploying 50 servers over 10 blade chassis.. keep me busy for the next lil while too |
| 23:06.35 | wedhorn | sounds like you've got your work cut out |
| 23:06.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.172) |
| 23:07.11 | snuff-work | yer.. lucky most of the 'hard' part is done.. golden set of images.. |
| 23:07.48 | snuff-work | still bits of manual to do for each |
| 23:08.07 | snuff-work | how's things with u ? |
| 23:09.20 | wedhorn | yeah pretty good. Moved to Brisbane, enjoying the weather (apart from the odd day) and being a kept man. Not sure how much longer that'll last though ;) |
| 23:10.44 | snuff-work | ;) |
| 23:36.39 | file | I'm adding "silly use of RAII_VAR" to my list of things that would take collateral damage when I'm fixing nearby code |
| 23:36.51 | file | or rather, will take damage |
| 23:37.00 | mjordan | file: +1 |
| 23:37.29 | mjordan | we have a very nice screwdriver. Some things are nails. |
| 23:38.21 | file | uses RAII_VAR on mjordan, it's super effective! |
| 23:38.41 | mjordan | crap. I think when I leave my office, that means I'll be auto-destructed |
| 23:38.43 | mjordan | NOOOOO |
| 23:38.52 | file | you're welcome |
| 23:41.12 | mjordan | file: http://shirt.woot.com/offers/what-are-those-foxes-saying |
| 23:41.25 | file | I approve |
| 23:44.38 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-zqlyksvxwtrlbllb) |
