| 01:04.33 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip72-201-239-241.ph.ph.cox.net) |
| 01:56.37 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:56.38 | *** 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! asterisk-blog.com -=- Follow on Twitter at @AsteriskDev |
| 02:01.05 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 02:39.06 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 03:13.08 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 04:08.54 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 05:01.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 05:11.14 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:25.51 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 05:35.09 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip72-201-239-241.ph.ph.cox.net) |
| 05:55.30 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 06:08.12 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:46.19 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:49.49 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:50.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:21.46 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:21.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:36.37 | *** join/#asterisk-dev ksmutthu (~ksmutthu@58.68.95.90) |
| 07:40.18 | *** join/#asterisk-dev ksmutthu_ (~ksmutthu@58.68.95.90) |
| 07:57.51 | *** join/#asterisk-dev ksmutthu (~ksmutthu@58.68.95.90) |
| 08:26.37 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lcy44-2-88-161-121-174.fbx.proxad.net) |
| 08:28.56 | *** join/#asterisk-dev jkroon (~jkroon@41.0.127.24) |
| 08:36.01 | *** join/#asterisk-dev oej (~oej@192.71.21.87) |
| 08:36.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:12.34 | *** join/#asterisk-dev oej (~oej@192.71.21.87) |
| 09:12.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:43.23 | *** join/#asterisk-dev jkroon (~jkroon@105.6.211.144) |
| 09:47.38 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 10:04.26 | *** join/#asterisk-dev jkroon (~jkroon@41.0.127.66) |
| 10:07.36 | *** join/#asterisk-dev oej (~oej@192.71.21.87) |
| 10:07.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:58.03 | *** join/#asterisk-dev ksmutthu (~ksmutthu@58.68.95.90) |
| 11:46.46 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 11:48.45 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 12:20.28 | *** join/#asterisk-dev SunnyB_ (~SunnyB@unaffiliated/sunnyb) |
| 12:46.37 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 13:03.12 | *** join/#asterisk-dev SunnyB (~SunnyB@unaffiliated/sunnyb) |
| 13:05.43 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:05.43 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:07.34 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-iuhegeprwwhkyuuz) |
| 13:07.34 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:10.22 | newtonr | Moooorning |
| 13:10.44 | file | hola |
| 13:15.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 13:48.01 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:48.01 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:48.23 | file | hiya cresl1n! |
| 13:48.32 | cresl1n | file!!~! |
| 13:48.37 | cresl1n | Good morning! |
| 13:49.11 | file | gooooooooood morning |
| 13:49.12 | file | how goes? |
| 13:53.15 | cresl1n | good :-) |
| 13:53.20 | cresl1n | how's your morning going? |
| 13:53.44 | file | cresl1n, lemon! |
| 13:53.47 | file | or well |
| 14:00.28 | cresl1n | Noooooo |
| 14:00.33 | cresl1n | SunnyB left the room!!!!!! |
| 14:01.21 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ulgouvmfgxwnqnsh) |
| 14:21.10 | cresl1n | Ok, I'm gonna cry uncle |
| 14:21.30 | file | cresl1n, orly |
| 14:21.42 | cresl1n | can anybody help me figure out what direction to go with for this test failure I get to work on about one day a week? |
| 14:21.50 | cresl1n | more recently one day a month :-) |
| 14:21.56 | file | no, you're on your own |
| 14:22.00 | cresl1n | file: meanie |
| 14:22.05 | cresl1n | test bully |
| 14:22.07 | file | pushes cresl1n into the deep end |
| 14:22.41 | cresl1n | this is for tests/apps/confbridge/confbridge_end_marked |
| 14:23.06 | cresl1n | failure symptom is: |
| 14:23.06 | cresl1n | [Jun 04 01:16:27] WARNING[11402]: apptest:143 _evaluate_expected_results: Expected result Conference transitioned from SINGLE to INACTIVE failed! |
| 14:23.07 | cresl1n | [Jun 04 01:16:27] WARNING[11402]: apptest:143 _evaluate_expected_results: Expected result Conference transitioned from INACTIVE to EMPTY failed! |
| 14:23.58 | cresl1n | I think what happens is a waitmarked channel, a waitmarked_endmarked channel, and then a marked channel get dumped into confbridge |
| 14:24.24 | file | that sounds like the start of a joke |
| 14:24.36 | cresl1n | the marked channel leaves, and in 20% of tests, confbridge fails to go through those state changes on exit |
| 14:25.16 | cresl1n | why? I have no freaking idea at this point |
| 14:25.32 | file | so my question is thus: is the state of everything in the bridge such that it should transition like so, or are other channels also leaving early causing transitions to get skipped? |
| 14:26.01 | cresl1n | like are the waitmarked or waitmarked_endmarked channels leaving prior to the marked channel? |
| 14:26.08 | cresl1n | accidentally? |
| 14:26.14 | file | yes, or leaving immediately after |
| 14:26.26 | cresl1n | I will check to be sure, but if I remember right they're not |
| 14:26.35 | cresl1n | but I will add that to my list to double check |
| 14:26.39 | cresl1n | why would that matter though? |
| 14:26.49 | file | no idea! I'm just asking questions :P |
| 14:28.00 | cresl1n | according to https://wiki.asterisk.org/wiki/display/AST/Confbridge+state+changes the empty state is defined as having no active or waiting users in the conference |
| 14:28.22 | cresl1n | the inactive state is defined as having only inactive/waitmarked users |
| 14:28.47 | cresl1n | the single state is defined as having a single active unmarked user |
| 14:29.55 | file | so it's skipping inactive? |
| 14:30.10 | cresl1n | I *think* so |
| 14:30.23 | cresl1n | it may not be going to the empty state to be honest |
| 14:30.26 | cresl1n | let me check to be sure |
| 14:30.31 | file | it is |
| 14:30.52 | *** join/#asterisk-dev dandann00dle (uid120491@gateway/web/irccloud.com/x-zggpnsyujwibhglk) |
| 14:30.54 | stefan27 | has anyone tested how having lots of local channels impacts performance? That is, if the dialplan has lots of Dial(Local/...) so that any call from SIP A to SIP B passes through 2 sip channels and 10 local channels SIP_A -> LocalX;1 -> LocalX;2 -> LocalY;1 -> ... -> SIP_B resulting on 6 times higher average "core show channels" count than just SIP to SIP... Will this cause negligable |
| 14:30.54 | stefan27 | extra cpu load? |
| 14:31.02 | cresl1n | last transition is from MULTI_MARKED to SINGLE |
| 14:31.15 | cresl1n | at least in the test results |
| 14:31.28 | file | cresl1n, I pulled the full log from your SWP and it showed a last transition of single to empty |
| 14:31.33 | cresl1n | thanks |
| 14:31.44 | cresl1n | goes to check the full log |
| 14:31.53 | cresl1n | I'm looking at the test result log |
| 14:32.19 | file | stefan27, I wouldn't expect it to be a ton but it can add up... |
| 14:32.32 | cresl1n | Cool, so that would confirm your theory that it's skipping inactive |
| 14:32.42 | cresl1n | but nothing else |
| 14:33.06 | cresl1n | (i.e. it's not skipped empty) |
| 14:33.21 | file | cresl1n, SO - I'd look at the previous state transition and that final state transition and determine the state of each channel from the full log |
| 14:33.24 | cresl1n | lawnmowers are at it again |
| 14:33.31 | file | so you can get a timeline |
| 14:34.16 | cresl1n | I started that last week, but I only got 3/4 of the way through the test log |
| 14:34.27 | cresl1n | I'll see if I can complete the search |
| 14:34.41 | file | the full log will be more helpful |
| 14:34.41 | cresl1n | there's a ton of data in these logs |
| 14:34.48 | cresl1n | that's what I was looking at |
| 14:35.05 | cresl1n | I was comparing it against a success case on my VM and trying to figure out what was different |
| 14:35.09 | file | you can also grab the messages log provided you know when stuff happened and cut out some of it |
| 14:35.15 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:35.15 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:35.17 | cresl1n | ok |
| 14:35.45 | file | my gut tells me that channels are leaving early which is mucking with the transitions, but that's just me |
| 14:35.52 | cresl1n | sorry, by test log above I meant full log :-) |
| 14:35.56 | cresl1n | ok |
| 14:36.00 | cresl1n | thanks for the direction |
| 14:36.02 | file | has nothing else to offer |
| 14:36.03 | cresl1n | I should've asked sooner |
| 14:36.11 | cresl1n | no, this is already excellent |
| 14:36.16 | cresl1n | I needed to get out of my own head on it |
| 14:36.36 | file | are you a brain in a jar? |
| 14:36.43 | cresl1n | I *was* |
| 14:36.49 | cresl1n | I still might be :-) |
| 14:36.54 | cresl1n | but less so, perhaps |
| 14:38.10 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 14:44.25 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 14:46.48 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ngzwpsjlqewcogyh) |
| 15:10.40 | *** join/#asterisk-dev Gugge_ (gugge@92.246.2.105) |
| 15:11.25 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-udchowjqbmzsxybi) |
| 15:12.31 | *** join/#asterisk-dev jkroon (~jkroon@105.255.184.56) |
| 15:19.01 | cresl1n | file: so you think a channel is leaving slightly early? |
| 15:19.05 | file | maybe |
| 15:19.08 | file | I'm trying to confirm |
| 15:19.17 | file | by slightly cheating |
| 15:19.29 | cresl1n | cheating? |
| 15:19.55 | file | cresl1n, yeah... take a gander at the CDR CSV and see if anything looks afoul on the non-working and working case |
| 15:20.58 | file | it's quicker than trying to piece together the timeline immediately |
| 15:21.07 | cresl1n | I don't have a CDR CSV in the logs.tar.gz I downloaded from jenkins |
| 15:21.26 | cresl1n | let me go look at jenkins a bit |
| 15:21.32 | file | aw you're right |
| 15:21.42 | file | lamezorz |
| 15:24.44 | file | cresl1n, the ball is in your court :D |
| 15:24.51 | cresl1n | it's ok |
| 15:24.55 | cresl1n | thanks for looking at it |
| 15:25.31 | gtjoseph | bootstrap only needed to be run in 11. review up... 3069 |
| 15:26.36 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 15:26.51 | *** join/#asterisk-dev jkroon (~jkroon@105.255.184.56) |
| 15:27.46 | rmudgett | I could use another +1 on https://gerrit.asterisk.org/#/c/3040/ |
| 15:32.48 | rmudgett | gtjoseph: If that is the only difference on the configure script then there isn't any need for updating the configure script. Those changes seem to depend upon which autoconf version is used to generate the configure script. |
| 15:33.52 | gtjoseph | well, on 13 and master, i did the bootstrap in my commit when when in after so those are fine. 11 did generate a change to configure |
| 15:34.36 | gtjoseph | i get what you're saying but we regenerating it doesn't harm anything |
| 15:35.25 | rmudgett | The review/change isn't needed as it didn't have any effective difference. |
| 15:35.44 | jkroon | so why commit it? |
| 15:36.26 | gtjoseph | what did you bring it up for then??? :) |
| 15:37.20 | rmudgett | I thought that since the source files got changed it would cause a difference in the generated configure script. Apparently it had no effect. |
| 15:37.37 | gtjoseph | well, it did 64 bit shifts instead of 31 bit. |
| 15:38.00 | gtjoseph | i'll abandon |
| 15:38.57 | rmudgett | Which seems to be a difference in which autoconf version generates the file. |
| 15:40.29 | stefan27 | ok thanks file, I guess I can ask in bigger channel as well |
| 16:00.02 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 16:03.05 | cresl1n | file: so to confirm your thoughts, it looks like in apps/confbridge/conf_state_single.c that it will transition directly to empty if there are no waitingusers in the conference |
| 16:03.27 | file | cresl1n, did the waiting user go on vacation? |
| 16:03.29 | cresl1n | it stinks of channel exit timing |
| 16:03.31 | cresl1n | heh |
| 16:03.41 | cresl1n | marks the waiting user as ON_VACATION |
| 16:04.25 | cresl1n | sends file a baconator wrapped fruit salad |
| 16:08.34 | file | wobbles |
| 16:27.07 | file | I tweaked the memory allotment to gerrit this morning and removed the daily restart |
| 16:27.14 | file | I'm going to see how it goes |
| 16:27.29 | gtjoseph | it's been pretty snappy so far |
| 16:27.53 | file | yeah, it may be at the right spot ... but I wouldn't hold out hope |
| 16:28.26 | file | Mem: 781.75m total = 516.03m used + 265.58m free + 151.03k buffers |
| 16:28.26 | file | <PROTECTED> |
| 16:29.39 | file | we shall seeeeee |
| 16:37.19 | *** join/#asterisk-dev jkroon (~jkroon@105.255.184.56) |
| 16:37.26 | *** join/#asterisk-dev ksmutthu (~ksmutthu@106.51.241.133) |
| 16:37.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip72-201-239-241.ph.ph.cox.net) |
| 16:37.56 | cresl1n | tweaks file's memory allotment |
| 16:38.15 | file | transfers cresl1n to the cloud |
| 16:38.39 | cresl1n | NOOOOOOooooooooooooooooooo |
| 16:39.01 | cresl1n | makes me want to listen to the new tron soundtrack |
| 16:40.53 | gtjoseph | gcc 6 now warns..... |
| 16:40.54 | gtjoseph | say.c: In function âast_say_date_with_format_itâ: |
| 16:40.54 | gtjoseph | say.c:5208:5: error: this âelseâ clause does not guard... [-Werror=misleading-indentation] |
| 16:40.54 | gtjoseph | <PROTECTED> |
| 16:40.54 | gtjoseph | <PROTECTED> |
| 16:40.54 | gtjoseph | say.c:5210:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the âelseâ |
| 16:40.56 | gtjoseph | <PROTECTED> |
| 16:40.58 | gtjoseph | <PROTECTED> |
| 16:41.07 | gtjoseph | :) |
| 16:41.11 | gtjoseph | Fedora 24 |
| 16:41.51 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 16:42.13 | sgriepentrog | there you go running that cutting edge stuff and getting burned ;-) |
| 16:42.26 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 16:42.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:42.28 | gtjoseph | luckily not my dev machine. :) |
| 16:46.07 | gtjoseph | ooooh... also caught this in res_rtp_asterisk... |
| 16:46.07 | gtjoseph | res_rtp_asterisk.c:544:21: error: self-comparison always evaluates to false [-Werror=tautological-compare] |
| 16:46.08 | gtjoseph | <PROTECTED> |
| 16:46.08 | gtjoseph | <PROTECTED> |
| 17:29.20 | seanbright | gtjoseph: the stuff in say.c appears to just be bad indentation |
| 17:29.46 | gtjoseph | yep. just new things gcc 6 cares about. :) |
| 17:30.11 | gtjoseph | now it's commenting on style |
| 17:30.40 | gtjoseph | i wonder if it has a plugin where we can enforce the Asterisk style :) |
| 17:31.43 | rmudgett | gtjoseph: That would be rather bad as older code is poorly following current standards. |
| 17:32.11 | gtjoseph | well then, a plugin to automatically reformat it during compile. :) |
| 17:33.25 | rmudgett | Use indent for that. It comes closest to reformatting code without screwing up. |
| 17:34.09 | gtjoseph | It's was a joke. |
| 17:34.39 | gtjoseph | i was simply commenting that gcc warnings are getting into the realm of the absurd. |
| 17:35.01 | rmudgett | Nothing like a massive reformat of the code base. |
| 17:35.10 | seanbright | i think that warning is pretty helpful |
| 17:35.29 | seanbright | are there other warnings showing up that are false positives? |
| 17:35.36 | gtjoseph | it is actually, but i'm not sure a compiler should be warning on style. |
| 17:36.01 | rmudgett | Or lack of it |
| 17:36.06 | gtjoseph | nope, that's the only non-logic error i saw |
| 17:36.09 | seanbright | hmm |
| 17:36.33 | file | makes note that talking about GCC warnings and errors makes seanbright appear |
| 17:36.33 | gtjoseph | there were a few that do need fixing |
| 17:42.57 | gtjoseph | i'm going to give "realtime performance #2" a +1 finally. :) the testsuite passed |
| 17:49.23 | putnopvut | Does anyone know of softphones/devices that support the SILK codec? |
| 17:50.37 | seanbright | eyebeam |
| 17:50.59 | seanbright | so perhaps x-lite by extension |
| 17:51.04 | gtjoseph | bria |
| 17:51.43 | seanbright | putnopvut: http://imgur.com/bXNZQpP |
| 17:52.00 | seanbright | oh... |
| 17:52.08 | seanbright | i'm running bria, not eyebeam |
| 17:52.11 | seanbright | so bria |
| 17:52.11 | seanbright | :-) |
| 17:52.14 | putnopvut | Thanks! |
| 17:52.45 | gtjoseph | I thought CSipSimple did too but I gave up on that. |
| 17:53.27 | seanbright | they dropped support for it apparently |
| 17:53.44 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00e46b2d688d07cb37.ipv6.abo.wanadoo.fr) |
| 17:54.52 | seanbright | putnopvut: https://en.wikipedia.org/wiki/Comparison_of_VoIP_software |
| 17:54.57 | seanbright | lists codecs there |
| 17:55.12 | putnopvut | nice thanks |
| 18:21.33 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:28.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip72-201-239-241.ph.ph.cox.net) |
| 18:40.45 | file | tick tock goes the clock |
| 18:43.02 | *** join/#asterisk-dev F2Knight_ (~F2Knight@73.96.106.134) |
| 19:24.01 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 19:40.35 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 19:40.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:47.37 | putnopvut | file: any idea how long it will be before the stuff that is +2'd and verified on gerrit gets merged? |
| 19:47.47 | file | awhile |
| 19:48.21 | file | you can check the status of in progress ones on https://jenkins.asterisk.org/jenkins/ |
| 19:48.46 | file | wanting to get the Alembic in? |
| 19:49.08 | file | if so I think that should merge in... sooner rather than later |
| 19:52.45 | putnopvut | ALl right thanks. Just trying to make the call about whether I'll be able to make RCs today |
| 19:53.01 | file | lemme check |
| 19:53.43 | file | it should be done in... 20-30 minutes |
| 19:54.02 | file | so, up to you |
| 20:11.38 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip72-201-239-241.ph.ph.cox.net) |
| 20:21.39 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 20:23.26 | file | putnopvut, it went in |
| 20:23.41 | putnopvut | Excellent. Thank you very much |
| 20:26.24 | putnopvut | I shall be starting the RC creation process very soon. I think I can get it done today. |
| 21:29.09 | *** join/#asterisk-dev ksmutthu (~ksmutthu@106.51.241.133) |
| 22:05.01 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 22:20.50 | rmudgett | file: putnopvut Is there a testsuite test that tests the CANCEL race condition for an outgoing call? |
| 22:21.02 | rmudgett | I don't see one |
| 22:21.08 | putnopvut | I doubt there is |
| 22:21.11 | file | I don't think so |
| 22:21.20 | putnopvut | Mainly because it's difficult to reliably test race conditions. |
| 22:21.44 | rmudgett | With a testsuite test you can fake it with a sipp scenario. |
| 22:22.14 | rmudgett | Just send a 200 even though we got the CANCEL |
| 22:23.28 | rmudgett | I found the reason we send two BYEs. PJPROJECT sends one BYE because of the bad SDP. We send the second BYE because we think we see the CANCEL race condition. |
| 23:11.32 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 23:26.29 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:26.29 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:31.36 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ulgouvmfgxwnqnsh) |