| 00:04.22 | *** part/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 00:04.34 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 00:27.48 | jameswf | thinks we need to give JessicaRabbit the hammer http://issues.freepbx.org/browse/FREEPBX-7469 |
| 00:28.03 | jameswf | ignore that... nothing to see here |
| 00:29.23 | tm1000 | jameswf: that ticket is invalid |
| 01:12.55 | *** join/#asterisk-dev spditner (~simon@23.91.131.127) |
| 01:13.11 | tm1000 | ${ATTENDEDTRANSFER} works in Asterisk 12, but doesnt work in Asterisk 11 |
| 01:13.22 | tm1000 | anyone know how to get attended transfer there? |
| 01:29.37 | coreyfarrell | tm1000: Looks like that's a new feature in 12. builtin_atxfer in main/features.c does use masquerade, so it might be possible to preset ${_ATTENDEDTRANSFER} and have it copied to the new channel. not sure sorry |
| 01:31.29 | tm1000 | coreyfarrell: yeah I will just limit it to 12 which is a-ok. thanks for the confirmation |
| 01:32.41 | coreyfarrell | tm1000: funny thing is 11 has a BLINDTRANSFER variable but no ATTENDEDTRANSFER |
| 01:32.48 | tm1000 | yup |
| 01:33.16 | coreyfarrell | the only other way you could know the info is to watch AMI |
| 01:33.20 | coreyfarrell | on 11 that is |
| 01:33.36 | tm1000 | coreyfarrell: thats why this is so handy on 12, exten => s,n,ExecIf($[${LEN(${BLINDTRANSFER})} > 0]?Set(PARKRETURNTO=${CUT(BLINDTRANSFER,-,1)}):Set(PARKRETURNTO=${CUT(ATTENDEDTRANSFER,-,1)})) |
| 01:33.40 | tm1000 | but not so much on 11 ;-) |
| 01:33.59 | tm1000 | coreyfarrell: yuck. no thank you, trying to avoid AGI as much as possible :-) |
| 01:34.23 | coreyfarrell | AGI != AMI, but AMI wouldn't help you do things with dialplan :) |
| 01:35.01 | tm1000 | thats what I meant. I know AGI != AMI, but I could parse the AMI by using the AGI… thats what I was going for coreyfarrell |
| 01:35.20 | coreyfarrell | I do everything with AMI, loads of fun |
| 01:36.01 | tm1000 | coreyfarrell: I do tons with it too, but the only way I could think oh how to talk to the AMI through dialplan was with AGI. Ah well you’ve helped a lot anyways |
| 01:36.38 | tm1000 | coreyfarrell: now if only Park() in 12 respected priority on the return context……hmmmm. Will have to talk to rmudgett about that tomorrow |
| 01:36.43 | coreyfarrell | tm1000: actually you would have AMI listen for the attended transfer, and Action: SetVar :) |
| 01:38.27 | tm1000 | coreyfarrell: hmmmm |
| 01:38.29 | tm1000 | that could work |
| 01:40.02 | coreyfarrell | dialplan doesn't really talk to AMI, but AMI can talk to dialplan |
| 01:40.18 | coreyfarrell | s/talk to/talk at/ |
| 01:54.50 | WIMPy | For these kind of things some sort of wait for AMI action in the dialplan would be nice to avoid race conditions. |
| 02:18.48 | coreyfarrell | WIMPy: I do that with a dialplan loop and AMI Action: Redirect. AMI transfers dialplan to the next step when it completed the action. not perfect but it's pretty good |
| 03:46.33 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 05:19.57 | WIMPy | Yeah, I use a Wait(2) followed by a error handler and redirect to another place. |
| 06:54.06 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 07:07.04 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:2d47:e4c2:eb8:edf5) |
| 07:40.27 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 08:22.09 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 08:35.35 | michael_work | hello chan |
| 08:35.42 | michael_work | i need advice |
| 08:37.03 | michael_work | app_queue has exit context and if you press any key(dtmf) it would check if it exists in that context and if so it would forward you there. |
| 08:37.47 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 08:38.32 | stevePearPear | Hi I’m just curious if this was an issue with anyone else: https://code.google.com/p/sipml5/issues/detail?id=156#makechanges |
| 08:38.44 | stevePearPear | using Asterisk hosted on AWS had that problem |
| 08:40.27 | michael_work | the problem here is that if you want to use same context for all queues, where the data you get by pressed dtmf is dynamic and loaded"on the fly" |
| 08:40.57 | stevePearPear | micheal ar u replying to me? |
| 08:41.10 | michael_work | the problem would be that i'll need to make same dialplan with all options of dtmf |
| 08:41.34 | michael_work | or i can add the setting to enable/disable dtmf (which is not that hard in my opinion) |
| 08:41.47 | michael_work | the qeustion is how this patch would be welcome and usefull for otheres? |
| 08:42.30 | michael_work | as well at the end my plan to extend penaltyrules and switch them to just rules where i can change this paramater over time |
| 08:42.47 | michael_work | stevePearPear, nope |
| 08:43.19 | michael_work | stevePearPear, i was in the middle of speeach :) anyway i think it's better you ask it on #asterisk |
| 08:45.11 | *** join/#asterisk-dev oej (~Adium@bl15-151-24.dsl.telepac.pt) |
| 08:45.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:45.18 | stevePearPear | good idea micheal :) thanks |
| 08:51.08 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 09:00.04 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:19.34 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:19.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:47.31 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 11:36.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:36.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:40.49 | *** join/#asterisk-dev oej (~Adium@62.28.178.18) |
| 11:40.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:21.02 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:35.31 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:53.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:10.48 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:16.50 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:21.32 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cdqhongnljllxjuv) |
| 13:23.46 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qhixnloontevktgc) |
| 13:28.21 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-gokjnlvsrdmgvfcd) |
| 13:32.27 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:42.34 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:42.34 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:02.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:02.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:03.22 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qdxwhobfrikgtthg) |
| 14:12.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:17.53 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-eshywgqnkkppvdmp) |
| 14:18.21 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-qyoxiwmgzcvfqluw) |
| 14:18.21 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:26.24 | *** join/#asterisk-dev Stefan27 (~Stefan27@212.247.4.149) |
| 14:26.43 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 14:31.16 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ojygpqhmwixiqdao) |
| 14:31.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:41.56 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:49.44 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 14:52.46 | *** join/#asterisk-dev oej (~Adium@62.28.178.18) |
| 14:52.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:53.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:57.50 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:07.05 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 16:01.34 | *** join/#asterisk-dev terryw (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 16:06.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.128) |
| 16:13.05 | tm1000 | rmudgett: The park application in Asterisk 12 has a bug in the return priority. It’s not respected and just returns to the top of the context. |
| 16:13.25 | tm1000 | was seeing if you knew about it before I post a bug or duplicate bug |
| 16:16.27 | rmudgett | tm1000: This is with the c() option? |
| 16:16.35 | tm1000 | rmudgett: yes sir |
| 16:17.08 | rmudgett | Internally that is doing a goto dialplan location. |
| 16:17.44 | rmudgett | What are you giving for the dialplan location? |
| 16:17.52 | tm1000 | rmudgett: the priority is not respected. I done the same (modified) on asterisk 11 and it works, when I switch the dialplan to asterisk 12, it doesn’t go to the priority |
| 16:18.10 | tm1000 | rmudgett: ill pastebin it for you |
| 16:18.38 | tm1000 | yes the application parameters are different between A11 and A12 and I am changing it to account for that |
| 16:20.04 | tm1000 | rmudgett: exten => s,n,Park(${ARG2},sc(${CONTEXT},s,200)) |
| 16:20.12 | tm1000 | but I can get you the whole thing as well |
| 16:21.26 | rmudgett | tm1000: try 199 instead of 200 for the priority to see if that works. |
| 16:21.41 | tm1000 | rmudgett: http://pastebin.com/Y0LMqizP |
| 16:23.01 | tm1000 | rmudgett: ok going to try it now |
| 16:23.40 | rmudgett | tm1000: Was this where it was supposed to go: exten => s,1+199(backtosender),Noop(Doing important stuff) |
| 16:23.52 | tm1000 | that didnt work |
| 16:23.56 | tm1000 | rmudgett: yes |
| 16:24.08 | tm1000 | 1+199 instead of 200 because FreePBX |
| 16:24.34 | tm1000 | if you think the 1+199 is the issue instead of 200 then I can just change that as well |
| 16:25.00 | rmudgett | You could also use the label: backtosender as the priority |
| 16:25.07 | tm1000 | rmudgett: did that didnt work, went to 1 |
| 16:25.17 | tm1000 | and in asterisk 11, it doesn’t like labels anyways |
| 16:25.44 | tm1000 | it complains in A11, saying “backtosender” is not a valid priority. In Asterisk 12, it accepts it but goes to priority 1 |
| 16:25.57 | mjordan | weird |
| 16:26.23 | mjordan | not that Park has a bug, but that Asterisk 12 doesn't complain about the label :-) |
| 16:26.56 | tm1000 | mjordan: right? but rmudgett or someone has done some extensive work to park in 12, as the params are very different now |
| 16:28.00 | mjordan | parsing out pbx dialplan locations are typically handled in the core - we're probably just not incrementing one to the priority when we send it off |
| 16:28.04 | tm1000 | rmudgett: with the label it still does the same thing |
| 16:28.04 | mjordan | tm1000: mind filing a bug? |
| 16:28.26 | tm1000 | mjordan: yeah I just wanted rmudgett to tell me if I was an idiot or not, didnt need to fill your bugs up with crap |
| 16:28.56 | rmudgett | I'd say it's a bug as well. |
| 16:31.20 | mjordan | tm1000: fill away ;-) |
| 16:31.34 | tm1000 | mjordan: isn’t parking in app_park? |
| 16:31.44 | file | res_parking |
| 16:32.33 | tm1000 | yup. thanks file |
| 16:38.58 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:44.37 | michael_work | mjordan, ping. as i see you assigned yourself to the patch i submited (realtime queues) i just assumed you are the guy to talk to about few other Q features i want add (send patch) |
| 16:45.09 | michael_work | s/add/to add/ |
| 16:45.27 | mjordan | Hm. |
| 16:45.36 | mjordan | Unfortunately, I shouldn't be assigned to that - IIRC, it is still in Triage |
| 16:45.57 | mjordan | takes a look at the issue |
| 16:46.11 | mjordan | Ah, it did that since I had requested feedback |
| 16:46.44 | mjordan | I'll comment as well on the issue, but the next step is to put it up for peer review on Review Board |
| 16:47.00 | mjordan | michael_work: https://wiki.asterisk.org/wiki/display/AST/Code+Review |
| 16:47.07 | michael_work | there is exit context when you press dtmf in the middle of the call, right now it checks if the digit exists in the context. Now it means i need to create several various exit contexts for each queue with different combinations of digits i want to allow |
| 16:47.49 | michael_work | but if i have single conxet where i can load dynamicly the logic |
| 16:47.51 | mjordan | most of that logic - the DTMF return code + bounce to another context/extension/priority - is handled in the pbx core. What exactly are you attempting to achieve? |
| 16:48.33 | michael_work | all i want to do is to add the ability (optional for sure) to have allowed dtmfs |
| 16:48.47 | mjordan | what do you mean by "allowed dtmfs"? |
| 16:48.51 | tm1000 | mjordan: rmudgett https://issues.asterisk.org/jira/browse/ASTERISK-23850 |
| 16:48.59 | mjordan | tm1000: thanks |
| 16:49.10 | michael_work | for example i have exten => _X.,1,Agi(coolAgiForQueues.php) |
| 16:50.20 | michael_work | mjordan, some parameter (string) like e.g. "1237" that would mean i can use any of those dtmfs (1,2,3,7) to go to the context |
| 16:50.42 | michael_work | instead of creating dialplan with exten => 1, exten => 2 ... etc |
| 16:50.56 | mjordan | when would those DTMF keys be accepted? |
| 16:51.11 | michael_work | when you in the queue |
| 16:51.27 | mjordan | when in the queue? When you are waiting to be connected to an agent? While dialing the agent? While talking to the agent? |
| 16:51.28 | michael_work | and you press dtmf it runs the check if exit context have it |
| 16:51.42 | mjordan | and why would you not just use the features blind transfer DTMF? |
| 16:51.53 | michael_work | same logic as today (AFAIK while waiting/dialing) |
| 16:52.08 | mjordan | Bouncing to one DTMF variable extensions is done for several applications, but I'm not sure it's really the most useful. For the most part, that feature only supports going to one digit extensions as well |
| 16:52.28 | michael_work | because it's already there, now it checks by context, what i want to make it hardcoreded |
| 16:52.39 | mjordan | hardcoded is usually not a good approach. |
| 16:53.02 | michael_work | i mean optionally hardcored |
| 16:53.04 | mjordan | I mean, if you want to patch your version of Asterisk with said feature, that's fine, but I'm not convinced that would a be a good, useful, generic feature for all users of Asterisk |
| 16:53.07 | michael_work | it's more hardcorded now :P |
| 16:55.00 | michael_work | i'm talking about valid_exit function |
| 16:56.16 | michael_work | currently it checks if the context exists and dtmf suits it |
| 16:57.29 | michael_work | and i can use _!. but the problem that all dtmfs would let it there |
| 16:57.54 | michael_work | and i need for each new specific ones i need to create dummy dialplans for each case of dtmf combinations |
| 16:58.25 | mjordan | I wouldn't personally advocate changing that logic. |
| 16:58.35 | michael_work | it's not changing |
| 16:58.37 | michael_work | it's adding |
| 16:58.50 | mjordan | You're more than welcome to propose a patch. |
| 16:58.55 | michael_work | ok |
| 16:59.01 | mjordan | I'm still not sure I see the utility of said patch |
| 16:59.10 | mjordan | And changes to app_queue will require tests |
| 16:59.57 | michael_work | the utility if that you have logic made out of agi or else where (maybe previous chan params) for what to do for each dtmf, so you have only one context for all Queue who has this option |
| 17:00.47 | michael_work | mjordan, and other thing i want to propose (surely with patch) to have more than penalty changed over time |
| 17:01.01 | mjordan | so, let me caution you here. |
| 17:01.12 | mjordan | app_queue is highly volatile. |
| 17:01.20 | mjordan | The risk of regression in it is typically very high. |
| 17:01.20 | michael_work | in other words to extend penaltyrules to more changes (like announecements or other parameters) over time |
| 17:01.42 | mjordan | Particularly when patches are made to 'business logic', such as call routing and penalties. |
| 17:01.49 | michael_work | mjordan, all the patches would be tested on productive server with heavy usage |
| 17:01.56 | coreyfarrell | michael_work: why not use exten => _[1237].,1,Agi(coolAgiForQueues.php) ? |
| 17:02.04 | mjordan | The burden of proof that you do not cause a regression or an inappropriate behavior change will be very, very, high |
| 17:02.14 | mjordan | michael_work: that is not sufficient |
| 17:02.21 | mjordan | that only proves that it works in your environment |
| 17:02.31 | mjordan | not in the other million or so Asterisk deployments |
| 17:02.40 | mjordan | Nor does it guarantee that other patches to app_queue don't break your feature |
| 17:02.46 | mjordan | or that you haven't broken someone else's feature |
| 17:02.47 | michael_work | coreyfarrell, because i still need to have 10 of those contexts if i have 10 Queues where each customer want his own dtmf |
| 17:02.55 | mjordan | If you are going to go down that road, you will absolutely need to learn the Asterisk Test Suite |
| 17:03.22 | mjordan | how to write tests in it. You'll need to make sure you have good coverage for your feature, as well as for other areas of app_queue affected by such a change |
| 17:03.31 | mjordan | We've been burned a lot by app_queue patches :-) |
| 17:03.35 | mjordan | see: ringinuse |
| 17:03.37 | michael_work | mjordan, i would always like to learn new things, though i would like to have some help/directions at first steps |
| 17:04.03 | mjordan | to be frank, if you need this kind of business logic, I'd recommend abandoning app_queue and writing your own Queue in ARI |
| 17:04.27 | michael_work | ringinuse is not working properly and i submitted patch, but there i less usre if it's right way to do :( |
| 17:04.30 | mjordan | Asterisk Test Suite documentation can be found here - http://pastebin.com/mTSgYP7D |
| 17:04.32 | mjordan | er |
| 17:04.33 | mjordan | wrong one :-) |
| 17:04.37 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation |
| 17:04.47 | michael_work | thanks |
| 17:04.50 | michael_work | i'll read thru it |
| 17:04.58 | mjordan | ringinuse is a cluster of unintended side effects. As are most business logic patches in app_queue. |
| 17:06.18 | michael_work | i mean there is bug in it and i can reproduce it (when it calls someone in call) and even submited patch (from boss account, before i got own), but as little bit noob, i'm sure it's not the best solution there :( |
| 17:06.30 | mjordan | michael_work: I would tend to agree with coreyfarrell. Having individual contexts per customer is generally the right way to do things anyway, to prevent calls from accessing other customer's logic |
| 17:07.15 | michael_work | the logic is made out of the asterisk (e.g. agi) |
| 17:07.34 | michael_work | and it's easier to maintain |
| 17:08.14 | michael_work | anyway i'll submit it for jira to see what others think |
| 17:08.38 | mjordan | sounds good |
| 17:09.25 | michael_work | i'll submit the patch from the issue before to review board hopefully tomorrow or this week |
| 17:09.28 | michael_work | ok |
| 17:09.33 | michael_work | thanks again and good day |
| 17:29.53 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:46.18 | rmudgett | mjordan: Should stasis mixing bridges be propagating linkedids and accountcodes? |
| 17:46.32 | rmudgett | They currently are not doing this. |
| 17:46.32 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-wzqfzuzxngwxprla) |
| 17:51.49 | mjordan | rmudgett: no |
| 17:51.59 | mjordan | or at least, not necessarily. |
| 17:52.30 | mjordan | A stasis created mixing bridge is, in many ways, an unknown quantity. We don't know what purpose it is going to be used for. |
| 17:52.37 | mjordan | linkedid propagation: that probably should happen |
| 17:52.41 | mjordan | accountcodes: I'm not so sure on. |
| 17:53.03 | mjordan | In general, bridges - or any resource managed by Stasis - should have as little done to it as possible |
| 17:53.13 | mjordan | accountcodes can be set through ARI with impunity |
| 17:53.17 | mjordan | linkedids, on the other hand, cannot |
| 17:54.50 | rmudgett | mjordan: I'll create an issue for linkedids then. |
| 18:16.48 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:09.11 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-gmlvmyrjviqximeo) |
| 20:00.11 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:00.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:33.30 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 20:33.30 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 20:33.43 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 20:34.00 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-vbnuklrjvqkmhqtm) |
| 21:00.43 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:21.43 | tm1000 | newtonr: |
| 21:24.45 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-iwjfvizilednhoic) |
| 21:25.54 | mjordan | wow. Take that tm1000 |
| 21:26.20 | tm1000 | mjordan: haha I was talking to him in pm, just was lazy, didnt want to lookup his name in the list :-D |
| 21:26.36 | tm1000 | so I typed: n <tab>, click, pm |
| 21:26.37 | tm1000 | :-) |
| 21:27.50 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 21:50.26 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:36.44 | gtjoseph | rmudgett: 'bout time for me to ping you again. :) |
| 22:38.06 | rmudgett | I haven't looked at it at all today. |
| 22:38.25 | gtjoseph | no worries |
| 23:07.48 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-qdxwhobfrikgtthg) |
| 23:58.54 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:58.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |