| 00:29.00 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:29.00 | *** 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:36.58 | *** join/#asterisk-dev Dovid (~dovid@ool-3f8fe226.dyn.optonline.net) |
| 00:44.21 | *** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 00:52.10 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 02:09.18 | *** join/#asterisk-dev joshelson (~joshelson@67.142.235.252) |
| 02:21.39 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-151-135.dialup.adsl.anteldata.net.uy) |
| 03:00.09 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 05:11.51 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-19-79.w90-32.abo.wanadoo.fr) |
| 05:39.48 | *** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 05:58.08 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:14.53 | *** join/#asterisk-dev joshelson (~joshelson@65.220.5.3) |
| 06:37.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.35) |
| 06:39.14 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:50.47 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:59.13 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:18.35 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::ced) |
| 07:20.27 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:20.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:22.34 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:05.36 | *** join/#asterisk-dev Dovid (~dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 08:11.10 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:30.00 | *** join/#asterisk-dev joshelson (~joshelson@65.220.5.3) |
| 09:26.05 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 11:01.51 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-151-135.dialup.adsl.anteldata.net.uy) |
| 11:03.09 | tsearle | good afternoon all |
| 11:05.50 | file | hola |
| 11:06.50 | tsearle | found some more details about my T.38 race condition |
| 11:07.12 | tsearle | the ACK of the invite on the B leg happens before the 200 ok is fed back to the core |
| 11:07.22 | tsearle | and before the A and B legs are bridged |
| 11:07.44 | tsearle | so if B sends a T.38 re-invite right away, it doesn't get forwarded because the channels are not bridged |
| 11:09.01 | tsearle | I suppose either channel.c or bridged_channel.c should be modified to forward the T.38 control frame even in early bridging? |
| 11:09.54 | file | the bridging core isn't used for early bridging, except for specific usage in ARI |
| 11:10.02 | tsearle | either that, or if there is an on bridged event taht res_pjsip_t38 can latch onto, re-send the control frame |
| 11:10.03 | file | Dial() or other things exchange the frames |
| 11:10.30 | tsearle | or, make sure that the bridgeing is completed before sending the ACK |
| 11:13.02 | tsearle | is there a way of knowing from pjsip_session that a channel has been bridged? |
| 11:14.02 | file | you can... |
| 11:14.05 | tsearle | or do you think patching Dial() for this race condition would be better? |
| 11:14.27 | file | Dial() would be saner... |
| 11:14.41 | file | but ultimately understanding the precise flow and where stuff is at the time is needed to adequately determine the way forward |
| 11:14.55 | tsearle | well I have that |
| 11:15.14 | file | you have the scenario, but do you know exactly where the frame is getting lost? |
| 11:15.18 | file | ie: what's dropping it |
| 11:17.00 | tsearle | in the ok case, the renvite is sligtly delayed (500 ms), Applying negotiated SDP media 'audio" happens and native bridge is created before T.38 re-invite happens |
| 11:17.24 | tsearle | in the 2nd case, the natvie-bridge isn't created yet |
| 11:17.33 | file | right, that's telling me what is happening - but it's not telling me where the frame exactly is getting dropped or who is doing it |
| 11:18.24 | tsearle | so the T38_CONTROL flame is not getting forwarded to the A leg when the T.38 state transitions from the 0 to 2 on the B leg |
| 11:19.10 | tsearle | setting the T.38 state generates the control frame that's fed to the core |
| 11:19.23 | file | yes. |
| 11:19.25 | tsearle | and if a channel is bridged, the bridge would take responsibility of forwarding it |
| 11:19.55 | tsearle | in this case there isn't a bridge yet, because the core hasn't been fed the 200 OK yet, (which another thread is working on) |
| 11:20.20 | tsearle | so that frame would be going directly to app dial |
| 11:20.32 | file | that needs to be confirmed |
| 11:21.45 | file | it's a T.38 re-invite right? |
| 11:23.05 | tsearle | yes |
| 11:23.18 | tsearle | and I have an ast-testsuite test case that can reliably reproduce it |
| 11:23.43 | tsearle | so on the A leg I have a 3second sleep between recipt of the 200 OK and the Ack |
| 11:23.45 | file | then I don't know exactly what would be handling the frames at that point in time, because the initial answering of the session should have caused app_dial to then go into the bridging |
| 11:24.00 | file | so either app_dial or bridging could be handling them |
| 11:24.18 | tsearle | and the B leg sends RE-INVITE immediately on recipt of ACK |
| 11:24.58 | tsearle | in this case, pjsip is sending the ACK to B before telling app dial that the call has been answered |
| 11:25.21 | tsearle | so the T.38 re-invite is happining before the answer from the POV of the core |
| 11:30.12 | tsearle | I have an ok and nok flow with lots of extra debug output added |
| 11:30.21 | tsearle | shall I post them to pastbin? |
| 11:31.35 | file | you can |
| 11:32.01 | file | does it show that app_dial is indeed the one dropping the frame? |
| 11:34.44 | tsearle | does such a message exist or it needs to be added? |
| 11:34.56 | file | there's a debug message when a control frame is dropped |
| 11:35.19 | file | if it is indeed app_dial then our PJSIP usage has to be checked to ensure that the threading model is being adhered to, because stuff relating to a session should be serialized |
| 11:43.07 | tsearle | https://pastebin.com/hM4cNhH4 |
| 11:43.13 | tsearle | this is the nok case |
| 11:43.38 | tsearle | the simple_bridge is being created after the recipt of the T.38 re-invite |
| 11:43.49 | tsearle | but I don't see what's happeneing to the control frame |
| 11:44.08 | tsearle | I suppose I need to add more log statements somewhere |
| 11:45.35 | tsearle | [Apr 4 09:04:19] DEBUG[27576] res_pjsip_t38.c: T.38 state changed to '2' from '0' on channel 'PJSIP/sbc-00000001' |
| 11:45.36 | tsearle | [Apr 4 09:04:19] DEBUG[27576] res_pjsip_t38.c: Deferring incoming SDP stream on PJSIP/sbc-00000001 for peer re-invite |
| 11:46.11 | tsearle | it just silently falls into a blackhole after that |
| 11:46.35 | tsearle | and times out 5 seconds later as per pjsip design |
| 11:49.07 | file | yes, it needs to be determined where the frame is going |
| 11:49.29 | tsearle | https://pastebin.com/QbUN5e6e |
| 11:49.52 | tsearle | this is the OK case, slight wait, so 200 OK is forwarded & bridge made before re-invite happens |
| 11:50.13 | tsearle | so where can I add loggign to trace this down more? |
| 11:50.15 | tsearle | app dial? |
| 11:50.26 | file | app_dial and bridging probably |
| 11:50.26 | tsearle | where else are possible guilty parties? |
| 12:00.17 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-151-135.dialup.adsl.anteldata.net.uy) |
| 12:10.05 | tsearle | <PROTECTED> |
| 12:10.05 | tsearle | <PROTECTED> |
| 12:10.05 | tsearle | <PROTECTED> |
| 12:10.05 | tsearle | <PROTECTED> |
| 12:10.07 | tsearle | <PROTECTED> |
| 12:10.09 | tsearle | <PROTECTED> |
| 12:10.13 | tsearle | <PROTECTED> |
| 12:10.15 | tsearle | <PROTECTED> |
| 12:10.19 | tsearle | chan_pjsip sets ignore_cc to -1 |
| 12:12.42 | file | cc is call completion, which chan_pjsip does not support |
| 12:18.39 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 12:19.07 | *** join/#asterisk-dev joshelson (~joshelson@65.220.5.3) |
| 12:27.49 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-151-135.dialup.adsl.anteldata.net.uy) |
| 12:49.52 | tsearle | ok, so reviewing the code of app_dial there is 1 place where a control frame can be discarded w/o logging, but as far as I can tell it isn't hitting that case |
| 12:57.05 | tsearle | chan_sip supports early bridge, but chan_pjsip seems not to |
| 12:57.32 | tsearle | what other bridge types can be happening before answer? |
| 12:57.38 | file | none |
| 12:58.12 | file | and I don't think it's chan_sip supporting something and chan_pjsip not, they both are architected differently and as a result have different timing |
| 12:58.39 | tsearle | so, this AST_CONTROL_T38_PARAMETERS has to be hitting app_dial then |
| 12:59.07 | file | if you aren't seeing a log message about it, then it's not |
| 12:59.31 | file | which means the queueing of it is not working, or it's past app_dial and starting to go into the bridging layer |
| 13:02.20 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-151-135.dialup.adsl.anteldata.net.uy) |
| 13:02.38 | tsearle | by the way in app_dial |
| 13:03.00 | tsearle | the switch statement around 1727 can silently discard T38 control frames |
| 13:03.35 | tsearle | default is goto skip_frame: which just silently frees the frame |
| 13:03.50 | file | I don't think there was ever any expectation of receiving T.38 control frames in an early bridge, so I'm not that surprised |
| 13:06.32 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-bmggbrjcbuycmygk) |
| 13:06.32 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:23.15 | tsearle | is there a way to enable debugging on the queueing to see where the frame is going? |
| 13:23.27 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:23.27 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:23.55 | file | I'm not aware of any general debugging for that |
| 13:24.16 | cresl1n | waves |
| 13:24.26 | tsearle | so I got a frame vanishing into the ether and no way to hunt it down |
| 13:24.28 | tsearle | *cries* |
| 13:24.30 | tsearle | waves |
| 13:24.56 | file | not without seeing if debug lines exist which are executed under such circumstances or adding your own |
| 13:26.01 | tsearle | I guess I can put a debug statement in as_channel_read and see if anything is actually trying to read it |
| 13:41.49 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-85-139.dialup.adsl.anteldata.net.uy) |
| 13:48.52 | tsearle | interesting, so it seems the T38 frame isn't read by anything until after a bridge is created |
| 13:48.59 | stefan27 | is code.asterisk.org having issues at the moment? |
| 13:49.16 | tsearle | -gtjoseph/#asterisk-dev- The Asterisk community servers are currently unavailable. We're investigating. |
| 13:49.36 | tsearle | that was from afew hours ago |
| 13:49.51 | stefan27 | Ah, missed that thanks |
| 13:49.53 | file | it shouldddddd be better now |
| 13:50.25 | gtjoseph | Yeah I was just waiting to make sure everything was stable before updating |
| 13:56.10 | stefan27 | All right, I might have experienced an issue different from what you had then; The link 'View as Patch' at https://code.asterisk.org/code/changelog/asterisk/?cs=8721d0bf1b20ccd02dfe4e0388e3a33ee7e7f6e8 doesn't take me anywhere |
| 13:57.10 | stefan27 | It redirected me to https://code.asterisk.org/code/rdiff/asterisk?csid=8721d0bf1b20ccd02dfe4e0388e3a33ee7e7f6e8&u&N which in turn never responds... but I recall that link working before |
| 13:57.15 | stefan27 | that's why I asked |
| 14:07.36 | stefan27 | That's odd, now the page finally loaded, 4.9 KB after 4.3 minutes :) |
| 14:08.46 | tsearle | ok, I have a new theory |
| 14:09.12 | tsearle | it seems that asterisk creates a simple_bridge, reads the control frame |
| 14:09.22 | tsearle | and then only after adds the A leg in the bridge |
| 14:09.46 | tsearle | so in that case the "ast_bridge_queue_everyone_else" would have nobody else to send to |
| 14:14.00 | file | 'tis possible |
| 14:14.08 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-pqikpnbjcatwqzve) |
| 14:14.08 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:15.19 | tsearle | adding debugging in "ast_bridge_queue_everyone_else" to be sure |
| 14:18.19 | tsearle | [Apr 4 14:16:36] DEBUG[11752][C-00000000] bridge_channel.c: ast_bridge_queue_everyone_else: frame 4 type 24 went nowhere! |
| 14:18.50 | tsearle | ok, so is there a way to prevent the bridge from reading frames until all the participants have been added? |
| 14:19.11 | file | not that I'm aware of |
| 14:19.37 | tsearle | this write callback would return -1 in this case |
| 14:19.51 | tsearle | anything that can take advantage of that fact? |
| 14:27.01 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 14:27.33 | *** join/#asterisk-dev quintana (42820e47@gateway/web/cgi-irc/kiwiirc.com/ip.66.130.14.71) |
| 14:28.08 | quintana | Hello, is there a bug report for this commit https://github.com/asterisk/asterisk/commit/b05d2fda0c8b3473c3d6d7bd1cc0473e2728b744 ? |
| 14:29.44 | quintana | i'm looking for the scenario of this issue |
| 14:32.47 | gtjoseph | It doesn't look like a jira issue was filed for it |
| 14:33.11 | gtjoseph | seanbright fixed it though... app_queue: Fix locking behavior in stasis message handlers |
| 14:35.00 | quintana | ok thank gtjoseph |
| 14:38.38 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 14:45.29 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-jbhsrjmjdqfjmghk) |
| 14:45.29 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:53.19 | scgm11_ | one question about AST-2017-001: Buffer overflow in CDR's set user, how many characters are the maximun? thanks |
| 14:55.44 | scgm11_ | found it 256 |
| 14:56.06 | gtjoseph | Yep, AST_MAX_USER_FIELD |
| 14:56.54 | tsearle | just a thought, could ast_channel_make_compatible be made to notice that the new channel is joining with a udptl channel and re-ask for the parameters? |
| 15:18.46 | cresl1n | file: did you see the note from Gaston Draque about the links that aren't working? |
| 15:18.52 | file | no |
| 15:18.53 | cresl1n | http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-13.13-cert3 |
| 15:19.04 | file | oh, certified nonsense |
| 15:19.05 | cresl1n | http://downloads.asterisk.org/pub/telephony/certified-asterisk/asterisk-certified-13.13-current.tar.gz |
| 15:19.14 | cresl1n | http://downloads.asterisk.org/pub/telephony/certified-asterisk/ChangeLog-certified-13.13-current |
| 15:19.16 | cresl1n | Yeah |
| 15:22.10 | file | gotta wait for ye ol' sync now |
| 15:24.22 | cresl1n | Oh my goodness |
| 15:24.40 | cresl1n | how many people subscribe their ticketing systems to security@asterisk.org? |
| 15:24.47 | file | a few. |
| 15:27.24 | rmudgett | file: gtjoseph https://gerrit.asterisk.org/#/c/5398/ |
| 15:28.22 | gtjoseph | kk, thanks |
| 15:28.35 | rmudgett | I'll wait for initial reaction to put up the other cherry-picks |
| 15:34.17 | cresl1n | How much does everyone know about the STIR and SHAKEN changes to the SIP protocol? |
| 15:34.36 | cresl1n | goes to read about them |
| 15:34.42 | gtjoseph | pleads ignorance |
| 15:34.46 | file | I know about STIR |
| 15:34.50 | file | I don't know about SHAKEN |
| 15:34.57 | cresl1n | Aww crap, STIR is what I thought it was |
| 15:34.59 | gtjoseph | was stir the caller id verification thing/ |
| 15:35.04 | cresl1n | yep |
| 15:35.05 | file | yes |
| 15:35.17 | cresl1n | I think we talked about it about 6 months ago |
| 15:35.18 | file | k lunch bbs |
| 15:35.22 | cresl1n | ttyl |
| 15:35.34 | gtjoseph | yep, just after the sip conf |
| 15:38.17 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 15:39.16 | file | Yup |
| 15:39.21 | file | It was a big thing there |
| 16:27.36 | *** join/#asterisk-dev tuxd00d (~tuxd00d@vacant-111-249.rio.maricopa.edu) |
| 17:18.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0070d4a68e54aa519b.ipv6.abo.wanadoo.fr) |
| 17:48.50 | sduthil | hi, I'm currently reading some code from asterisk, and I'm wondering what is impart/depart regarding bridges and channels. what's the difference between depart and leave, for example? |
| 17:58.55 | rmudgett | Channels can join or be imparted into a bridge. A joined channel lends the thread to the bridge to handle channel servicing. When that channel leaves the bridge it the thread still has control of the channel. |
| 17:59.27 | rmudgett | An imparted channel enters the bridge without a thread so the bridge must create one for it. |
| 18:00.07 | rmudgett | The imparted channel can enter the bridge as an independent threaded or departable threaded. |
| 18:00.35 | rmudgett | The departable threaded channel can be departed from the bridge by another thread and take control of the channel. |
| 18:01.36 | rmudgett | A mode of operation which I really don't like because there are limitations involved which unfortunately stasis is built. |
| 18:01.57 | *** join/#asterisk-dev scgm11__ (~scgm11@r186-52-85-139.dialup.adsl.anteldata.net.uy) |
| 18:06.53 | rmudgett | s/stasis is built/stasis got built around/ |
| 18:08.01 | rmudgett | Leaving a bridge doesn't have any special meaning except that the channel leaves a bridge. |
| 18:08.11 | rmudgett | All channels leave bridges. |
| 18:08.16 | rmudgett | eventually. |
| 18:11.43 | *** join/#asterisk-dev quintana (42820e47@gateway/web/cgi-irc/kiwiirc.com/ip.66.130.14.71) |
| 18:15.37 | *** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 18:15.58 | sduthil | rmudgett, thanks for the explanation. I'm reading https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project at the same time and it explains a lot |
| 18:24.06 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 18:45.51 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ksunetzmdqaiuxdc) |
| 18:45.51 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:52.14 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-240-195.try.wideopenwest.com) |
| 18:52.14 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 18:52.33 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-85-139.dialup.adsl.anteldata.net.uy) |
| 18:56.59 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 18:56.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:00.13 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 19:27.31 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 19:27.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:11.09 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 20:11.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:53.00 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 20:53.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:04.47 | *** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 21:14.29 | *** join/#asterisk-dev scgm11__ (~scgm11@r186-50-105-236.dialup.adsl.anteldata.net.uy) |
| 21:43.25 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 21:44.25 | *** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 21:49.12 | *** join/#asterisk-dev Dovid (~dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 21:54.28 | cresl1n | About to go be a dad |
| 21:54.33 | cresl1n | see you all later |
| 21:57.44 | scgm11__ | @rmudgett I tested today had a crash but could check the core dump, anyway I saw new patch and Im uploading it tonight |
| 21:59.10 | scgm11__ | no deadlock I´m getting more info tomorrow |
| 22:05.48 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 22:26.08 | gtjoseph | I want to have a "chat" with whoever packages libvpb1 for ubuntu. it pops up an ncurses box to get country code so it kills unattended install. |
| 22:27.15 | file | oh, that works fine in my ansible |
| 22:27.17 | file | lemme grab it... |
| 22:27.42 | gtjoseph | some option to disable the prompt or provide default? |
| 22:27.49 | file | <PROTECTED> |
| 22:27.49 | file | <PROTECTED> |
| 22:28.01 | gtjoseph | ah ha |
| 22:32.43 | rmudgett | scgm11__: You should also watch ASTERISK-26853 as it is a similar rtp reentrancy problem that I'm working with the same patch. |
| 22:36.50 | scgm11__ | ok |
| 22:40.57 | *** join/#asterisk-dev joshelson (~joshelson@65.220.5.3) |
| 22:50.57 | rmudgett | gtjoseph: I'm not sure how cheap that deadlock insurance is. We may be trading a non-issue for a hard to understand crash when dereferencing the tsx->last_tx pointer. |
| 22:51.33 | gtjoseph | hmmm. |
| 22:52.00 | gtjoseph | IIRC, this was reported to pjproject in reference to an asterisk crash |
| 22:52.15 | gtjoseph | er, deadlock. but i'll check |
| 23:23.33 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-pqikpnbjcatwqzve) |
| 23:35.17 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-243-239.dialup.adsl.anteldata.net.uy) |