| 01:27.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:27.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:46.58 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 02:20.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:20.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:59.03 | *** join/#asterisk-dev serafie1 (~erin@user-24-214-173-250.knology.net) |
| 04:30.53 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 05:46.30 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:46.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:39.57 | *** join/#asterisk-dev fish9370 (~Miranda@psy.iptelefon.su) |
| 06:41.01 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 07:08.17 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:08.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.57 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6c3e:8f4c:d0d8:8c6d) |
| 07:43.43 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:43.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:03.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:03.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:20.16 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 10:03.52 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-34999.vm.okeanos.grnet.gr) |
| 10:26.40 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 11:28.18 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:29.37 | *** join/#asterisk-dev tzanger (tzanger@wallace.mixdown.ca) |
| 12:07.29 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:55.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nfhfmcmikladgiah) |
| 13:44.58 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:44.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:47.09 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:47.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:49.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:49.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:09.11 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ozrfekbhrseujgna) |
| 14:09.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:11.49 | file | hrm |
| 14:19.55 | leifmadsen | indeed |
| 14:42.06 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:44.37 | file | I am surprised pjsip has no way to get a const PJ str for common header namea |
| 14:44.41 | file | Or names |
| 14:49.40 | jsmith | Really? |
| 14:49.49 | jsmith | Seems like a bit of an oversight |
| 14:50.33 | file | Well it is a common enough operation, oh well |
| 14:51.06 | jsmith | file: I hear they accept patches :-p |
| 14:51.36 | file | I have better things to do :P |
| 14:51.55 | file | Just came up during code review and me thinking back to other code |
| 14:56.49 | Kobaz | okay so |
| 14:56.58 | Kobaz | i'm figuring out more stuff here |
| 14:57.11 | Kobaz | asterisk -> phone: INVITE |
| 14:57.22 | Kobaz | phone -> asterisk: TRYING, RINGING, OK |
| 14:57.32 | Kobaz | asterisk -> phone: .....nothing? |
| 14:57.45 | Kobaz | phone -> asterisk: OK, OK, OK, OK |
| 14:57.49 | Kobaz | and so on |
| 14:57.55 | Kobaz | soooo, what could be the problem here |
| 14:58.04 | Kobaz | no ACK from asterisk -> phone |
| 15:01.56 | jsmith | Kobaz: Wrong contact header? |
| 15:02.26 | Kobaz | http://pastebin.com/raw.php?i=H8WxSSqn |
| 15:02.32 | Kobaz | there's a dump... not sure what's wrong |
| 15:04.51 | jsmith | Whoa, that's crazy! |
| 15:05.15 | jsmith | doesn't spot anything obviously wrong with the INVITE |
| 15:05.24 | Kobaz | yeah that is crazy |
| 15:05.35 | Kobaz | and this is totally random |
| 15:05.43 | Kobaz | sometimes it barfs like that, sometimes it doesn't |
| 15:05.44 | jsmith | Is the phone firmware up to date? |
| 15:05.47 | Kobaz | yeah fairly |
| 15:06.00 | Kobaz | it's one firmware ref behind, latest is 3.3.5 that's 3.3.4 |
| 15:06.05 | jsmith | Might check the firmware errata and see if that's a bug that has been fixed |
| 15:06.08 | Kobaz | but |
| 15:06.08 | jsmith | I don't know what else to tell you |
| 15:06.22 | Kobaz | isn't asterisk supposed to reply to the 200 OK, with an ACK |
| 15:06.25 | Kobaz | to start the call? |
| 15:06.29 | jsmith | It is |
| 15:06.34 | Kobaz | and asterisk doesn't |
| 15:06.46 | jsmith | But it looks like all the 200 OKs are coming pretty rapid-fire, without giving Asterisk a chance to respond to the 200 OK |
| 15:06.59 | Kobaz | lemme check the timestamps |
| 15:07.26 | jsmith | Actually, I was looking at them wrong |
| 15:07.36 | jsmith | It does appear that there are several seconds between each 200 OK |
| 15:07.46 | jsmith | So yeah -- looks like Asterisk isn't sending the ACK for some reason |
| 15:08.00 | jsmith | has to run... back in a little while |
| 15:08.02 | Kobaz | aw |
| 15:38.34 | file | kharwell, nice (re: diversion) |
| 15:43.54 | kharwell | file: good to hear it. |
| 15:52.59 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 16:02.37 | Kobaz | do de do |
| 16:02.41 | Kobaz | so where to look |
| 16:03.22 | file | Mars? |
| 16:04.14 | Kobaz | asterisk chan_sip apparently |
| 16:04.23 | Kobaz | something is srsly fscked up somewhere |
| 16:05.03 | WIMPy | As long as it isn;t everything everywhere this seems to be a good day. |
| 16:05.08 | Kobaz | asterisk gets a 200 OK from the phone |
| 16:05.11 | Kobaz | and does not send an ACK |
| 16:05.41 | Kobaz | this might be the same problem i'm seeing at another customer (but less frequently) |
| 16:10.38 | Kobaz | so why would asterisk not send an ACK |
| 16:10.39 | Kobaz | is the problem |
| 16:14.58 | Kobaz | it would be cool if there was a 'sip register' command, to go along with sip unregister |
| 16:20.25 | jsmith | There is "sip show registry" and "sip reload" :-p |
| 16:21.30 | Kobaz | yeah |
| 16:21.40 | Kobaz | would be cool to force a register when you lose one |
| 16:22.06 | file | a sip reload will re-register |
| 16:22.30 | Kobaz | no no |
| 16:22.32 | Kobaz | the other way |
| 16:22.37 | Kobaz | fake a phone register -> asterisk |
| 16:22.49 | file | ... |
| 16:23.39 | Kobaz | like |
| 16:23.42 | file | opticron, did you look at pjmedia at all just to see how it handles SDP with SRTP in it? (just curious) |
| 16:23.48 | file | I understand what you mean :P |
| 16:23.53 | Kobaz | heh |
| 16:23.59 | Kobaz | well i was gonna give a reason for it |
| 16:24.25 | Kobaz | say you're developing stuff and you have some phone registered and then shut down asterisk |
| 16:24.46 | Kobaz | and you start it back up after deleting out the astdb, and now you have no cached registration |
| 16:25.05 | Kobaz | and say your phone reg time was like an hour... so it would be nice to say, hey... i know there's a phone here, put it back in |
| 16:26.21 | mjordan | why would you blow out the astdb? |
| 16:26.53 | Kobaz | testing, or maybe it got corrupted, which i've run into |
| 16:41.29 | Kobaz | er, aw.. i forgot to build 11 with BETTER_BACKTRACES |
| 16:42.34 | Kobaz | does that add overhead? |
| 16:43.09 | mjordan | some but not a lot. DEBUG_THREADS is your killer. |
| 16:43.36 | Kobaz | heh, i have debug threads on every system |
| 16:44.36 | opticron | file, no, I was mainly focused on chan_sip |
| 16:44.52 | file | opticron, ack |
| 16:45.18 | Kobaz | mm |
| 16:45.21 | Kobaz | first deadlock in 11 |
| 16:46.08 | Kobaz | between app_softhangup and add_features_datastore |
| 16:47.42 | Kobaz | called from Bridge() |
| 17:01.18 | Kobaz | oh cool, parallel make works |
| 17:07.16 | leifmadsen | Kobaz: Bridge() being the thing that failed, doesn't surprise me :) |
| 17:14.08 | Kobaz | heh |
| 17:14.12 | Kobaz | aww |
| 17:14.19 | Kobaz | but that must always work |
| 17:15.57 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-67-161.user.veloxzone.com.br) |
| 17:22.28 | file | I love seeing stuff added to pimp my SIP |
| 17:22.36 | file | it makes me happy |
| 17:25.07 | Kobaz | sip my ride |
| 17:26.27 | Kobaz | so hmm |
| 17:26.29 | Kobaz | === ---> Lock #0 (features.c): MUTEX 910 add_features_datastore chan 0x838d350 (1) |
| 17:26.34 | Kobaz | === ---> Waiting for Lock #1 (channel.c): MUTEX 1848 ast_channel_by_name_cb chan 0x838d350 (1) |
| 17:26.40 | Kobaz | shouldn't that say waiting for lock #0 ? |
| 17:32.01 | mjordan | what's the full text/ |
| 17:33.17 | Kobaz | pasting |
| 17:33.42 | Kobaz | putting up a bug report and trying to build a small production case |
| 17:34.10 | Kobaz | http://pastebin.com/AA59F2gV |
| 17:34.29 | Kobaz | slightly different trace than what i pasted snips of before but the same deadlock |
| 17:34.49 | Kobaz | it's actually not between Bridge and SoftHangup... i took out the SoftHangup and it still happened |
| 17:34.58 | Kobaz | but it's Bridge related |
| 17:35.41 | Kobaz | i don't know why add_features_datastore is locking up |
| 17:35.58 | Kobaz | it's inside a AST_LIST_TRAVERSE with no locks |
| 17:36.45 | Kobaz | er i mean, wrong thread... i meant the ast_channel_by_name_cb from the last one |
| 17:38.07 | mjordan | I'm not really seeing the deadlock - I'm curious why add_features_datastore snagged the lock and never released it |
| 17:38.19 | mjordan | deadlock => circular waiting |
| 17:38.33 | Kobaz | well those locks aren't going away |
| 17:39.19 | Kobaz | deadlock to me means, something in some thread is locking something that another thread needs and they'll both never complete due to the mutual dependence |
| 17:39.28 | mjordan | there isn't mutual dependence, that's my point |
| 17:39.45 | mjordan | something called out to ast_channel_datastore_find and never returned |
| 17:39.57 | Kobaz | in the trace pasted... the bottom thread 0xb40f3b70 locked 0xea5d658 |
| 17:40.08 | mjordan | right |
| 17:40.09 | mjordan | that's fine |
| 17:40.10 | Kobaz | and the top thread 0xb6affb70 is waiting on lock 0xea5d658 |
| 17:40.26 | Kobaz | so until the bottom thread finishes, the top one will block |
| 17:40.34 | mjordan | right. So why isn't the bottom one finishing? |
| 17:40.38 | Kobaz | no idea |
| 17:40.47 | Kobaz | oh yeah right, there's no mutual dependency |
| 17:40.50 | Kobaz | just a depending on b |
| 17:41.11 | Kobaz | memory corruption maybe |
| 17:41.13 | Kobaz | lemme valgrind it |
| 17:44.20 | Kobaz | ooo there it goes |
| 17:44.42 | Kobaz | slew of invalid reads and writes |
| 17:46.22 | mjordan | file: putnopvut: hi there |
| 17:46.33 | file | putnopvut, you'll like what mjordan is gonna say |
| 17:46.45 | mjordan | I may have already told him |
| 17:46.50 | file | mjordan, LAME |
| 17:46.52 | mjordan | he's still typing in his window to me |
| 17:46.55 | mjordan | let's talk about him |
| 17:46.59 | file | mjordan, tests will need to be moved |
| 17:47.05 | mjordan | indeedy |
| 17:47.06 | file | or the plan updated |
| 17:47.16 | mjordan | moving tests will be trivial-ish |
| 17:47.22 | mjordan | updating test plan => not quite as much |
| 17:48.04 | mjordan | it'd be good to get snuff-home's documentation in, so people can configure it easier |
| 17:48.20 | mjordan | but that can still happen in trunk. I doubt everyone will jump on it in 24 hours |
| 17:48.26 | mjordan | and if so, that's a problem I'd like to have |
| 17:48.53 | file | yeah I'm fine without that for now |
| 17:49.03 | putnopvut | hI! |
| 17:49.23 | file | for those following along at home: we are referring to the merging of the Pimp My SIP branch into trunk |
| 17:49.28 | putnopvut | I figure I can send out a dev-list e-mail talking about it as well. |
| 17:51.35 | file | aye |
| 17:57.42 | file | it's a good Thursday |
| 18:07.08 | file | opticron, I'm so anti-any optional encryption that it's not funny :P |
| 18:13.00 | opticron | fair enough |
| 18:13.20 | opticron | I'll nuke the current "no" option and replace it with the functionality of what is currently "deny" |
| 18:22.13 | file | Jingle has a way to be explicit about optional encryption |
| 18:22.17 | file | it makes me happier |
| 18:25.47 | Kobaz | this one isn't terrible |
| 18:25.49 | Kobaz | but i'm getting |
| 18:25.54 | Kobaz | ==19629== Conditional jump or move depends on uninitialised value(s) |
| 18:26.08 | Kobaz | on if (cause_code->emulate_sip_cause) { in ast_channel_hangupcause_hash_set |
| 18:26.37 | Kobaz | isn't cause_code calloc'd ? |
| 18:31.35 | putnopvut | Kobaz: looks like it's alloca'd |
| 18:32.18 | putnopvut | And that emulate_sip_cause is only set if global_store_sip_cause is true |
| 18:34.33 | Kobaz | so shouldn't that be |
| 18:34.50 | Kobaz | if (global_store_sip_cause && cause_code->emulate_sip_cause) |
| 18:36.29 | Kobaz | oh, i see the call in chan_sip where it's alloa'd |
| 18:36.38 | Kobaz | there's another spot where it's calloc'd but that's not it |
| 18:37.31 | putnopvut | yeah |
| 18:41.34 | Kobaz | fixed it in chan_sip |
| 18:45.06 | *** join/#asterisk-dev acidfoo (~nib@unaffiliated/acidmen) |
| 18:48.17 | Kobaz | https://issues.asterisk.org/jira/browse/ASTERISK-21693 |
| 18:48.18 | LieutPants | [ASTERISK-21693] [Status: Triage] Use of unitalized value in channel.c - https://issues.asterisk.org/jira/browse/ASTERISK-21693 |
| 18:48.25 | Kobaz | if anyone wants to give the ok for that fix |
| 18:58.23 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 18:58.24 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 19:04.47 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 19:04.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:09.37 | Kobaz | <PROTECTED> |
| 19:09.45 | Kobaz | that's not a very useful day-to-day log message |
| 19:10.15 | Kobaz | without having the sip dialog or sip peer name also in there |
| 19:20.02 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 19:21.51 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 19:21.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:27.59 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 19:28.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:34.59 | mjordan | putnopvut: file: do you still need to pre-load sorcery modules? |
| 19:40.15 | file | Ummmm |
| 19:40.27 | file | I dunno |
| 19:40.40 | file | I think Qwell poked at that |
| 19:55.17 | Kobaz | okay so... trying to find what func/line(s) write to the console or attached console |
| 19:55.29 | Kobaz | playing around in logger_print_normal() in logger.c |
| 19:55.40 | Kobaz | but that doesn't seem to be the logger for when you get a channel related log line |
| 20:05.03 | Kobaz | ah it's at the top of logger_print_normal, when it cycles through the verbosers |
| 20:32.48 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 20:32.56 | jmls | evening all |
| 20:33.25 | jmls | I have a reproducible problem (segfault) with the latest svn of the 11 branch |
| 20:33.43 | jmls | #0 0xb5e91850 in sip_request_call (type=0x2244240 "SIP", cap=0x22425f0, requestor=0x22b12e4, |
| 20:33.43 | jmls | <PROTECTED> |
| 20:33.43 | jmls | 29706 ast_copy_flags(&p->flags[0], &p->relatedpeer->flags[0], SIP_NAT_FORCE_RPO RT); |
| 20:34.06 | jmls | this is on 2 different boxes |
| 20:34.27 | jmls | it was working fine before I "made update" :( |
| 20:34.38 | putnopvut | my guess, p->relatedpeer is NULL. Sounds like someone coded something assuming you'd be placing outbound calls to a SIP peer instead of an arbitrary URI. |
| 20:34.58 | snuff-home | mjordan: question.. i hope by default res_sip / chan_gulp is noload => in modules.conf :) |
| 20:35.06 | snuff-home | in trunk |
| 20:35.22 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 20:35.45 | jmls | let me see |
| 20:39.17 | jmls | yup |
| 20:39.37 | jmls | sip/078x@foobar worked |
| 20:39.55 | jmls | where foobar has ip of 77.107.128.156 |
| 20:40.29 | jmls | still a bug, tough, right ? |
| 20:40.38 | jmls | *though |
| 20:40.50 | wdoekes | http://lists.digium.com/pipermail/asterisk-commits/2013-April/060743.html |
| 20:41.18 | jmls | yeah, I suspected that patch was the culprit |
| 20:41.23 | mjordan | jmls: yup - if you want we can just reopen that issue |
| 20:41.30 | wdoekes | spot on mark |
| 20:41.40 | jmls | no worries - if that's easier |
| 20:41.50 | jmls | thanks |
| 20:42.20 | mjordan | jmls: can you attach a backtrace and comment on ASTERISK-21374? |
| 20:42.20 | LieutPants | [ASTERISK-21374] [Status: Reopened] [Assigned: elguero] [patch] One-way Audio With auto_* NAT Settings When SIP Calls Initiated By PBX - https://issues.asterisk.org/jira/browse/ASTERISK-21374 |
| 20:43.19 | wdoekes | in case anyone is bored and has ideas about misalignment: ASTERISK-21665 |
| 20:43.20 | LieutPants | [ASTERISK-21665] [Status: Open] [Assigned: wdoekes] 11.4 rc1 Crash on debian/sparc with SIGBUS, Bus Error - https://issues.asterisk.org/jira/browse/ASTERISK-21665 |
| 20:46.56 | jmls | mjordan,done |
| 20:50.38 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:50.38 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:57.09 | jmls | mark: congrats on "Pimp My SIP merge" |
| 20:57.25 | jmls | exciting times ahead |
| 21:02.49 | file | VERY exciting times |
| 21:12.20 | jsmith | No kidding :-) |
| 21:23.05 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:23.06 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 21:26.32 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:26.34 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 21:30.49 | pabelanger | so, who bind to port 5060 first, chan_sip or chan_gulp? |
| 21:30.55 | pabelanger | binds* |
| 21:31.22 | file | res_sip has no defaults |
| 21:31.27 | file | (coded in defaults) |
| 21:31.31 | file | (for transports) |
| 21:32.38 | mjordan | pabelanger: if you choose to run both, you'd better configure both ;-) |
| 21:33.02 | file | I just commented out the transport in the sample configuration, so a make samples won't go nuts |
| 21:33.46 | pabelanger | mjordan: well, didn't plan to run both, more thinking about a default install. Was curious if chan_sip was still the default channel driver, or if chan_gulp is. |
| 21:34.06 | pabelanger | I have not tired chan_gulp yet, so not sure what the base configuration is |
| 21:34.16 | pabelanger | file: okay, coolio |
| 21:34.17 | mjordan | We haven't really gotten that far. Much like the joy that ICE was in 11, I think we'll run for awhile to try and find the best solution |
| 21:34.30 | file | as it is even with a make samples res_sip will not bind to anything, you have to explicitly configure it |
| 21:34.42 | pabelanger | Yup, make sense |
| 21:38.15 | pabelanger | Is there a specific date to merge our changes to pjproject back upstream set? |
| 21:38.32 | pabelanger | Would like to help tzafrir get that packaging into Debian before astricon |
| 21:39.45 | tzafrir | I asked a question regarding packaging of pjproject on the -dev list, BTW |
| 21:39.52 | tzafrir | Is there a better place to ask it? |
| 21:40.03 | mjordan | tzafrir: nope. Qwell was taking a look at what you asked |
| 21:40.10 | mjordan | pabelanger: upstream decisions aren't made by us |
| 21:40.11 | pabelanger | tzafrir: Ya, seen that. I haven't had much time to play with it either |
| 21:40.34 | pabelanger | mjordan: has our patches landed upstream? |
| 21:42.59 | mjordan | nope. We've got a lot of other things up in the air right now |
| 21:45.16 | pabelanger | okay. Hopefully pushing those patches back upstream is on a list |
| 21:46.18 | mjordan | it is :-) |
| 21:47.41 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-ndeuvdbpltyluhbx) |
| 21:58.55 | *** join/#asterisk-dev bkruse (~Adium@107-220-153-105.lightspeed.jcvlfl.sbcglobal.net) |
| 22:22.50 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ozrfekbhrseujgna) |
| 23:31.59 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:32.00 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |