| 00:03.55 | *** join/#asterisk-dev snuff-work (~snuffy@1.157.105.164) |
| 00:03.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:40.46 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-gcekothiugfdymuk) |
| 01:26.14 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 02:06.13 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:06.13 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:10.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.201) |
| 03:11.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.243) |
| 04:12.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.4) |
| 05:13.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.253) |
| 05:44.00 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:44.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:14.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.248) |
| 07:08.40 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:08.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:10.48 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:10.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:15.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.248) |
| 07:22.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.248) |
| 07:37.27 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:37.27 | *** join/#asterisk-dev snuff-work (~snuffy@1.157.105.164) |
| 07:37.27 | *** join/#asterisk-dev mwally (~mwally@mwally.opencnam.com) |
| 07:37.27 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-hlpezlfbpdxzyurz) |
| 07:37.27 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 07:37.27 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 07:37.28 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 07:37.28 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:37.28 | *** join/#asterisk-dev jmls1 (~julian@77.107.171.82) |
| 07:37.28 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 07:37.28 | *** mode/#asterisk-dev [+oooo oej snuff-work snuff-home Corydon76-home] by barjavel.freenode.net |
| 07:37.28 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 07:37.28 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 07:37.28 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 07:37.28 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 07:37.28 | *** join/#asterisk-dev LieutPants (~LieutPant@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:37.28 | *** mode/#asterisk-dev [+ooo seanbright Qwell LieutPants] by barjavel.freenode.net |
| 07:39.46 | *** join/#asterisk-dev newtonr (~newtonr@64.34.219.47) |
| 07:39.46 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 07:42.28 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 07:47.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:47.26 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:12.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@62.141.80.122) |
| 08:59.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@62.141.80.122) |
| 09:08.35 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d03f:b054:d596:a020) |
| 09:16.50 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-tgybyopnttcnzzuv) |
| 09:59.23 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 10:15.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@62.141.80.122) |
| 10:36.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@62.141.80.122) |
| 10:58.33 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 11:30.20 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:50.17 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:46.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.173.70) |
| 13:07.08 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:44.51 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:55.28 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xozaobasolatpvfn) |
| 13:55.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:55.54 | mjordan | jsmith: ping |
| 14:00.49 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:00.49 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:03.43 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 14:05.22 | jsmith | mjordan: pong |
| 14:05.32 | jsmith | mjordan: (Sorry, just got back to the office -- what's up?) |
| 14:05.50 | mjordan | jsmith: np, can I PM you? |
| 14:06.04 | jsmith | mjordan: Any time -- no need to ask permission |
| 14:11.02 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 14:15.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:15.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:16.29 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-vpyvybawfhupqxrd) |
| 14:54.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.235) |
| 15:04.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.235) |
| 15:04.57 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:04.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:08.17 | pabelanger | come one come call, time to play it is a bug or feature in asterisk! Todays question, if receiving a fax on analog, should asterisk automatically disable callwaiting on the channel? |
| 15:08.27 | pabelanger | vote noe |
| 15:08.29 | pabelanger | now* |
| 15:08.48 | oej | Vote no to receiving a fax. It's so last century. |
| 15:08.50 | opticron | I vote that fax support in asterisk is a bug |
| 15:09.53 | oej | pabelanger: You have the results of the vote. |
| 15:09.57 | leifmadsen | pabelanger: I'll be serious! If the call waiting on a channel *can* be disabled, it likely should. Anything that generates a tone that could interrupt a fax seems to be wrong, or at least an oversight. |
| 15:10.16 | pabelanger | Ya, I've been banging my head with this issue for the last week. Turns out the callwaiting indicator was over writing the fax audio signal, tipping over my faxes. |
| 15:10.21 | leifmadsen | pabelanger: the only thing i can think of is that if you're connected to the PSTN, you might not be in control of disabling the call waiting tone right? |
| 15:10.23 | oej | The Fax protocol has retransmissions to cover that situation, right? |
| 15:10.30 | pabelanger | I only asked if asterisk should auto disable it, because we auto disable echo cancellation |
| 15:10.37 | leifmadsen | +1 |
| 15:10.40 | leifmadsen | makes sense to me |
| 15:11.02 | pabelanger | oej: correct, however in my case, spandsp cannot recover all the time |
| 15:11.12 | WIMPy | How are you going to disable CW while you have a call? You need to do that before. |
| 15:11.44 | pabelanger | WIMPy: right, I figure at the same time we disable echo canceller |
| 15:11.53 | opticron | the ambiguity here is whether it's CW from the telco to asterisk or CW from asterisk to an endpoint |
| 15:12.07 | pabelanger | asterisk to endpoint |
| 15:12.19 | oej | In which cases do asterisk send cw |
| 15:12.36 | WIMPy | Ok, in that case it would work. |
| 15:12.48 | pabelanger | cool |
| 15:13.19 | oej | If we disable echo cancellation I think we should disable call waiting too |
| 15:13.42 | pabelanger | let me see if I can hack something up and get it to the issue tracker, deciding to included it will be another discussion for the mailing list |
| 15:13.46 | pabelanger | oej: right, my thoughts too |
| 15:14.02 | oej | I am still curious on how we send cw |
| 15:14.36 | *** join/#asterisk-dev outtolunc (~me@c-50-136-182-86.hsd1.ca.comcast.net) |
| 15:15.57 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-184-183-148-253.ph.ph.cox.net) |
| 15:16.16 | pabelanger | oej: what do you mean? |
| 15:16.46 | oej | When and where does asterisk send call waiting? |
| 15:17.02 | oej | In SIP we don't really need it… ;-) |
| 15:18.46 | file | sig_analog supports call waiting, so it does the necessary analog silliness to achieve that |
| 15:19.35 | oej | Aha. |
| 15:19.38 | oej | Thanks, file. |
| 15:21.24 | pabelanger | yup |
| 15:21.27 | pabelanger | silliness is true |
| 15:23.39 | *** join/#asterisk-dev serafie (~erin@50.58.247.162) |
| 15:29.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:29.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:50.54 | *** join/#asterisk-dev tzanger (tzanger@wallace.mixdown.ca) |
| 16:01.43 | file | kharwell, you are missing a file on your stasis review (I think) |
| 16:02.24 | file | actually wrong person |
| 16:02.25 | file | Qwell, YOU |
| 16:02.52 | Qwell | wHAT?! |
| 16:02.56 | Qwell | which one? |
| 16:03.01 | Qwell | oh, system_registry |
| 16:03.03 | file | Qwell, you are missing files on your registry events review |
| 16:03.05 | Qwell | svn is stupid |
| 16:03.20 | Qwell | new svn doesn't show new files in a diff. will fix. |
| 16:03.24 | pabelanger | you wouldn't say that if we didn't have git |
| 16:03.26 | pabelanger | :p |
| 16:03.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.162) |
| 16:06.30 | Qwell | file: fixed |
| 16:35.38 | file | opticron, why did you go for a channel callback that returns the role? |
| 16:39.28 | opticron | versus the previous binary hidden/not hidden? there was a need for more granularity in describing how a channel is used as a tool to accomplish other things and at present, this is generally a property that you would expect to be attached to the channel tech |
| 16:40.25 | file | a channel callback that just returns an abritrary string just seems... unclean |
| 16:41.20 | opticron | I agree, but I felt that using an enum or a bitfield to describe it was too restricting |
| 16:42.06 | file | well it just feels as though you are overloading it - it's written as an informational retrieval function but then you act on its presence |
| 16:43.05 | file | just really... weird |
| 16:43.49 | opticron | currently, all channel techs that return something for that field should be hidden, but that may not always be the case |
| 16:46.02 | file | I think I would feel better if those two were separated... you could use a channel flag to hide it, but also have the ability to retrieve role information for other purposes |
| 17:10.13 | file | mjordan, alwaysauthreject. |
| 17:12.21 | file | "this diff has been split across 4 pages" = o.o |
| 17:13.06 | mjordan | file: I know |
| 17:13.17 | mjordan | file: so here's the question: what should the sequence of rejection messages be |
| 17:13.31 | mjordan | should it be always challenge - so we send a 401 constantly - or should we do the 401/403 dance |
| 17:13.55 | file | there's pros and cons for both |
| 17:13.58 | mjordan | challenging constantly until they get it right feels appropriate - incorrect, try again. There's very little room for that to go wrong |
| 17:14.05 | mjordan | on the other hand, I can't figure out when to send a 403 |
| 17:14.27 | mjordan | with 401/403, you've made it more complex that you send the responses differently (401/401/403, 401/403, whoops) |
| 17:16.03 | file | the con of having them challenge over and over is potentially useless DB traffic |
| 17:17.23 | file | pro being in code it's easy to do, and if you have transitory DB issues then clients will eventually work again |
| 17:25.55 | Qwell | leedm777: Do you have any input on the comments putnopvut raised on https://reviewboard.asterisk.org/r/2626/ ? Other existing stuff uses 5xx errors for invalid input. |
| 17:27.45 | mjordan | file: I kind of like the 401 simply because it is what occurs when you try to authenticate something and it fails. "Nope, try again". If someone wants to reject after three attempts (or something like that) then you'd send the 403 and perma-ban them |
| 17:46.26 | *** join/#asterisk-dev serafie (~erin@50.58.247.162) |
| 18:29.00 | leifmadsen | mjordan: newtonr: got my stickers!!! |
| 18:29.01 | leifmadsen | thanks! |
| 18:29.51 | mjordan | woot |
| 18:29.54 | mjordan | np :-) |
| 18:31.05 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:33.45 | leifmadsen | newtonr: btw, redirect your thanks to bchia :D |
| 18:33.50 | leifmadsen | lolz. |
| 18:34.09 | leifmadsen | will promptly get a new sticker onto the car with the SHIFT 8 license plate |
| 18:52.02 | mjordan | gotta represent yo |
| 18:57.27 | file | Oh, I'm down with 401 always... |
| 19:02.22 | mjordan | file: so, I guess that would be the only change. I think at that point we're meeting the intent of the feature |
| 19:02.48 | mjordan | kharwell: ^^^ |
| 19:04.11 | kharwell | okay will do |
| 19:06.51 | mjordan | jrose_atDigium: is there any reason why we have a parkinglot in a channel snapshot? |
| 19:08.23 | jrose_atDigium | mjordan: I'm not aware of everything stored in channel snapshots. If I had to guess, the reason for having parkinglot would be the name of the parkinglot specified to park to by the channel, but that seems like it would be superfluous data. |
| 19:08.56 | jrose_atDigium | mjordan: Confirmed. The parkinglot value in the channel snapshot is the parkinglot currently set for the channel to park to. |
| 19:09.13 | mjordan | yeah, it shouldn't be in there. |
| 19:09.48 | mjordan | That's application specific data that shouldn't be associated as part of a channel snapshot. That's why we have JSON blobs we pass around with Stasis messages |
| 19:10.07 | leifmadsen | sticker applied! |
| 19:10.42 | jrose_atDigium | It isn't directly related to parking work. It's simply exposing the value from the channel struct. |
| 19:11.36 | jrose_atDigium | But anyway, I'm not using it for anything, and I don't think anyone currently is. It's probably safe to just get rid of it. |
| 19:11.37 | leedm777 | mjordan: I believe the parkinglot field in the snapshot predates jrose's parking work. |
| 19:11.43 | jrose_atDigium | It does. |
| 19:11.50 | jrose_atDigium | except |
| 19:11.55 | jrose_atDigium | well, snapshots themselves don't. |
| 19:12.20 | leedm777 | by like a few days, they might :-P |
| 19:12.21 | jrose_atDigium | The source of that value however has been around a long time. |
| 19:12.26 | leedm777 | agreed. |
| 19:13.49 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:16.46 | mjordan | issue created to kill it |
| 19:16.48 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:16.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:38.10 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:38.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:09.18 | putnopvut | So here's a fun little puzzler that I just figured out. |
| 20:09.31 | leifmadsen | https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash3/q71/s720x720/936444_10151662409200762_1676484883_n.jpg |
| 20:09.40 | leifmadsen | Very safe for work, and nearly on-topic |
| 20:10.01 | putnopvut | I had the following: transferer = ast_dial_answered_steal(dial); |
| 20:10.16 | putnopvut | I realized that I needed to bump the refcount of the channel returned by ast_dial_answered_steal() |
| 20:10.20 | putnopvut | So I tried this: |
| 20:10.32 | putnopvut | transferer = ast_channel_ref(ast_dial_answered_steal(dial)); |
| 20:10.40 | putnopvut | And every time, transferer would be NULL after that call. |
| 20:10.58 | putnopvut | Quiz: why does this happen? |
| 20:12.31 | putnopvut | Answer: ast_channel_ref() is a macro, not a function. It expands to { ao2_ref((arg), +1); (arg); } |
| 20:13.04 | putnopvut | So in my case, it expanded to { ao2_ref(ast_dial_answered_steal(dial), +1); ast_dial_answered_steal(dial) ; } |
| 20:13.25 | putnopvut | That second call to ast_dial_answered_steal(dial) would return NULL since the first one removed the answered channel from the dial. |
| 20:13.39 | putnopvut | Remember kids: macros can be SNEAKY |
| 20:38.48 | mjordan | putnopvut: nice |
| 20:47.00 | Qwell | it's easy enough to fix that sort of thing |
| 20:47.11 | Qwell | _typeof(arg) arg_ = (arg); |
| 20:47.19 | Qwell | then just replace instances of (arg) with arg_ |
| 20:47.39 | Qwell | erm, typeof, not _typeof |
| 20:48.12 | Qwell | I'm pretty sure that's how S_OR works |
| 20:51.54 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:29.20 | mjordan | leedm777: question |
| 21:29.37 | mjordan | leedm777: if I have a websocket client connected to app 'foo' and I break it, what should happen to the callers? |
| 21:29.45 | mjordan | callers => channels currently in the application |
| 21:38.25 | file | that's a good question |
| 21:43.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.162) |
| 21:51.37 | jsmith | mjordan: Funny you should ask that -- I was wondering the same thing today |
| 21:52.48 | mjordan | currently they seem to hang out |
| 21:53.02 | mjordan | I would not be asking this because my python script had a bug and threw an exception |
| 21:53.04 | mjordan | <_< |
| 21:53.05 | mjordan | >_> |
| 21:53.58 | mjordan | jsmith: eating my own dog food this week ;-) |
| 21:54.17 | file | if the python script were stateful enough could it recover? |
| 21:54.42 | mjordan | file: if I had bothered putting in a try: it could as well |
| 21:54.58 | mjordan | I suspect the answer is they hang out waiting for someone to come along and save them |
| 21:55.09 | mjordan | but that does mean that a good library should query the system on connect to see who's hanging out |
| 21:55.16 | file | nah I mean if it persisted state externally, and then was restarted... |
| 21:55.24 | mjordan | it could |
| 21:55.28 | mjordan | but I'd probably just resync it |
| 21:55.35 | file | if it could recover as if nothing happened... that would be very very nice |
| 21:55.37 | mjordan | new callers would be rejected |
| 21:56.01 | mjordan | file: I suspect that's the intent. If you were connected and then lost your connection, new ones get rejected but everyone who is in progress keeps going (they're in bridges, etc.) |
| 21:56.13 | file | aye |
| 21:56.17 | mjordan | but I don't see a way around the client either having maintained state, or having to ask for the state |
| 21:56.29 | mjordan | unless as part of the spec you dump state on new client connection |
| 21:56.49 | mjordan | but that's not really helpful when you can just ask for the state anyway |
| 21:57.12 | file | well, that's our state... you'd have to have application state as well |
| 21:57.25 | mjordan | jsmith: fyi, while they're a little out of date and need some TLC, have you seen the wrapper libraries? |
| 21:57.38 | mjordan | I started with the python one we have and it saved me some serious time |
| 21:58.09 | jsmith | mjordan: Aye :-) |
| 21:58.19 | jsmith | mjordan: I stumbled across them before they were really public |
| 22:00.43 | mjordan | good! |
| 22:00.54 | mjordan | I'm making notes on what we need to update them with |
| 22:01.11 | mjordan | the biggest thing they need - other than getting rebased - is message handling/routing |
| 22:13.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.182) |
| 22:30.07 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:30.07 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:34.18 | leedm777 | mjordan: re: WebSocket connections. Yes, the channels should remain up even if the WebSocket connection comes and goes. |
| 22:34.43 | leedm777 | In fact, the current behavior of rejecting new channels if the application isn't there to handle it bothers me a bit. |
| 22:35.05 | leedm777 | But it's in the category of things that are "good enough for now" |
| 22:35.16 | mjordan | we do have a slight problem then |
| 22:35.25 | mjordan | if you reconnect and a channel hangs up, you don't get the stasis_end event |
| 22:38.16 | leedm777 | hm. that's unexpected. |
| 22:38.26 | leedm777 | certainly a bug. |
| 22:48.11 | putnopvut | mjordan: is ast_backtrace() a thing of the past now? |
| 22:48.42 | mjordan | no |
| 22:48.45 | mjordan | it should work |
| 22:48.50 | mjordan | leedm777: I'll file it |
| 22:48.58 | putnopvut | weird, I just grepped for it and don't see it in my tree. |
| 22:50.23 | putnopvut | Yeah, and trying to add it into my code is giving me a compilation error "implicit declaration of function 'ast_backtrace'" |
| 22:50.39 | mjordan | backtrace.h |
| 22:50.44 | putnopvut | I included that. |
| 22:50.48 | mjordan | huh |
| 22:51.06 | putnopvut | I don't see ast_backtrace() in there. I see functions to create an ast_bt structure and manipulate it. |
| 22:51.12 | mjordan | looks |
| 22:51.16 | putnopvut | But no single function to just create and print a backtrace. |
| 22:51.20 | mjordan | ah |
| 22:51.23 | mjordan | It did get renamed, my bad |
| 22:51.27 | mjordan | ast_log_backtrace, IIRC |
| 22:51.35 | putnopvut | okay, and is that in logger.h? |
| 22:51.40 | mjordan | yes |
| 22:51.45 | mjordan | sorry :-\ |
| 22:51.47 | putnopvut | Okay, cool beans yo |
| 22:52.35 | putnopvut | Thank you kindly! |
| 22:55.45 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 22:56.06 | *** join/#asterisk-dev newtonr (~newtonr@64.34.219.47) |
| 22:56.06 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
