| 00:00.54 | life_of_e | Ok, I think I see the disconnect |
| 00:01.21 | life_of_e | If the FXO accepts the flash over in-band DTMF, then Asterisk can do it via DTMF() (sending signal 16) |
| 00:01.32 | life_of_e | but you're saying Asterisk won't send flash via INFO |
| 00:01.58 | [TK]D-Fender | If that gatway can accept DTMF then that could do it. |
| 00:02.17 | [TK]D-Fender | But * doesn't have a SIP signaliing means of doing the other thing |
| 00:02.34 | life_of_e | Right, ok, that I agree with because I looked for it first |
| 00:02.51 | life_of_e | That's when I stumbled across the DTMF workaround assuming the device can handle DTMF in-band flash signal |
| 00:03.47 | [TK]D-Fender | so when you mention "signal 16", would that be DTMF "D"? |
| 00:03.53 | life_of_e | F |
| 00:04.30 | life_of_e | at least according to what I've read (and that's what's I've written into my test dial plan) |
| 00:05.12 | [TK]D-Fender | F goes beyong the 10+2+4 grid I'm familiar with |
| 00:05.48 | life_of_e | Well F would technically be 15 if you number starting from 0 but if you're starting from 1 it's 16 |
| 00:06.21 | life_of_e | I believe the * and # eat two signals, they may even be the E and F |
| 00:06.53 | [TK]D-Fender | A-D are considered the last 4 as they are not found on the traditional keypad |
| 00:06.58 | [TK]D-Fender | Which should bean "D" |
| 00:07.01 | [TK]D-Fender | mean |
| 00:07.20 | [TK]D-Fender | And I can't see them trying to hijack something you will commonly need to pass-through |
| 00:08.37 | [TK]D-Fender | which I could then at least imagine being able to make work using inband, and a features.conf trigger to SendDTMF(D) |
| 00:08.48 | [TK]D-Fender | If all the rest of that is as hoped |
| 00:10.21 | life_of_e | according to RFC 2833, D is 15 |
| 00:10.36 | life_of_e | so 16 is a completely different code |
| 00:10.51 | [TK]D-Fender | I'm betting more like 16th value |
| 00:10.55 | [TK]D-Fender | which it would be |
| 00:11.17 | life_of_e | could be, unless the DTMF() application had its arguments overloaded to accept a hex value |
| 00:11.19 | [TK]D-Fender | (not starting from 0) |
| 00:11.35 | [TK]D-Fender | SendDTMF only accepts the standard grid |
| 00:11.41 | [TK]D-Fender | including A-D |
| 00:12.06 | [TK]D-Fender | So unless there's something more I've not heard of... we've got 1 thing to test |
| 00:12.09 | [TK]D-Fender | and pray |
| 00:14.16 | life_of_e | Aha |
| 00:14.17 | life_of_e | https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_SendDTMF |
| 00:14.37 | life_of_e | The function is overloaded as of Asterisk 11 |
| 00:14.59 | life_of_e | 0-9,*,#,A-D as well as a W and F |
| 00:16.46 | life_of_e | So I'm not totally crazy, just mostly. :) |
| 00:17.17 | [TK]D-Fender | the catch being chan_sip doesn't handle "flash" |
| 00:18.00 | [TK]D-Fender | And I'm not seeing it in pjsip |
| 00:21.27 | life_of_e | argh, yeah, I see that now. I suspect a patch would not be trivial |
| 00:23.23 | life_of_e | though chan_sip does have an entry for event == 16 |
| 00:32.00 | life_of_e | I suppose I can always just try it, maybe I can borrow someone's Grandstream :) |
| 00:32.39 | *** join/#asterisk elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 00:33.56 | trmg | Somewhat related, is there a way to configure something in features.conf to allow one to send an "F"? I want to try this with a Cisco router I'm using as an FXS/FXO channel bank trunked with Asterisk via PRI. If I can get flash to work with that ohh man that would be sweet. |
| 00:35.05 | life_of_e | I'm certainly not one to know, I know very little (as should be obvious) |
| 00:35.18 | life_of_e | :) |
| 00:36.35 | trmg | lol |
| 00:36.44 | life_of_e | the existence of a stub of code in chan_sip.c is just too annoying. The asterisk-dev list says it doesn't work or at least doesn't work correctly so it's a mystery. |
| 00:38.07 | life_of_e | pj_sip says the 'R' character sends flash |
| 00:38.23 | life_of_e | not sure if it actually works |
| 00:43.38 | [TK]D-Fender | I didn't see reference in chan_pjsip.c |
| 00:43.48 | [TK]D-Fender | but I'm not a full dev and don't know how everything is divided |
| 00:44.30 | life_of_e | I was searching through feature requests and bug reports. One of them was a feature request from five years ago that says it was added as character 'R' in the SendDTMF() function |
| 00:45.04 | life_of_e | (at least that's how I read it since the request is closed and "fixed") |
| 00:46.48 | [TK]D-Fender | Well chan_sip is dead so taht's kinda game-over |
| 00:47.02 | [TK]D-Fender | we'd need to see if there is a feasible way to get it into chan_pjsip |
| 00:47.04 | life_of_e | but it could be it's linked to DAHDI as you've mentioned before and not to the SIP pathway |
| 00:47.12 | [TK]D-Fender | It is in DAHDI |
| 00:47.21 | [TK]D-Fender | which is why I confirmed that possibility from the start |
| 00:47.41 | life_of_e | right, I'm saying the code path might not be obvious in that the handoff only goes one way, it's hard to read all the code |
| 00:47.43 | [TK]D-Fender | it was the lack of being anywhere else that * supported (to my knowledge) |
| 00:48.03 | life_of_e | but the dev discussion talked about adding the path so it could be picked up by a SIP device |
| 00:48.10 | [TK]D-Fender | I saw the "stump" in chan_sip, and nothing every came up about it since .... |
| 00:48.12 | life_of_e | it just wasn't obvious how that path is created |
| 00:48.38 | life_of_e | The claim is that pj_sip is supposed to be easier to support and add features so I don't see why this can't be added |
| 00:49.41 | [TK]D-Fender | Well chan_sip is being abandoned so it's not like there's another choice. i f the library has a means then it's only up to the * dev team to make that bridge. |
| 00:50.01 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 00:51.47 | *** join/#asterisk TheHonorableKit- (~TheHonora@gateway/tor-sasl/thehonorablekitt) |
| 00:51.49 | life_of_e | Yeah, my current project (other than an FXO trunk) is to rework my copy of asterisk and move to pj_sip and see what happens. I've got messaging set up under chan_sip so I can send text messages to my phones (with Jabber integration) and I'll need to try that with pj_sip. |
| 01:02.12 | life_of_e | I suppose if push came to shove I'd just build a relay module triggered by the Raspi GPIO to flash the POTS line manually behind the back of the gateway |
| 01:03.11 | [TK]D-Fender | that is something you could call a script for from features.conf spying for phone DTMF combination. |
| 01:06.56 | life_of_e | Right, exactly |
| 01:07.18 | life_of_e | Intercept the flash signal from the SIP phone and fire off an external GPIO script to pulse the relay |
| 01:07.42 | life_of_e | With the right terminations, the gateway would never know the line went down and the call would just transfer over |
| 01:07.58 | life_of_e | obviously having PJSIP support it would be ideal ;) |
| 01:08.58 | [TK]D-Fender | no, that's the thing.. * doesn't catch "flash" from your phone any more than it can send it out right now. |
| 01:09.30 | life_of_e | Well, I cheated in my case |
| 01:09.52 | [TK]D-Fender | I mean * isn't receiving that via SIP |
| 01:10.02 | [TK]D-Fender | regardless of your triggering a script for the GPIO trick |
| 01:10.04 | life_of_e | I put the call on hold on the SIP phone and then dial a special extension which will do the dirty work |
| 01:10.25 | [TK]D-Fender | I'm talking about Phone> *, not script > custom circuit |
| 01:10.33 | [TK]D-Fender | Oh... yeah |
| 01:10.36 | [TK]D-Fender | that could do it. |
| 01:10.39 | [TK]D-Fender | ICK.... |
| 01:10.41 | [TK]D-Fender | but yeah |
| 01:10.49 | [TK]D-Fender | Serious... use a DTMF feature... |
| 01:10.55 | [TK]D-Fender | whole lot easier |
| 01:11.09 | [TK]D-Fender | no fidgiting with "hold", etc |
| 01:12.22 | life_of_e | hmm, ok, how does one write a DTMF feature? I've not done that before |
| 01:12.41 | life_of_e | oh wait, I see, applicationmap |
| 01:13.12 | [TK]D-Fender | yup |
| 01:13.22 | life_of_e | well silly me |
| 01:13.39 | life_of_e | I wrote this two years ago into my features.conf file: |
| 01:13.52 | [TK]D-Fender | so depending on your phone you may be able to program an in-line DTMF speed-dial that would be physically convenient to send a 2-key combo like #* to trigger it |
| 01:13.52 | life_of_e | hookflash => #9,self/callee,SendDTMF(F) |
| 01:14.00 | [TK]D-Fender | Yes, basically that |
| 01:14.10 | [TK]D-Fender | substituting your script call if required |
| 01:14.40 | [TK]D-Fender | we still have a hint that DTMF "D" might do it; |
| 01:14.53 | [TK]D-Fender | (for the 16 you found) |
| 01:15.07 | life_of_e | that could work then, gives me greater incentive to pick up a Grandstream since I have a way "out" of the hookflash problem if I can't get the more expected methods to work |
| 01:19.01 | *** join/#asterisk infobot (ibot@208.53.50.136) |
| 01:19.01 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.23.1 (2018/09/20) 16.0.1 (2018/11/14), Security Only: 15.6.2 (2018/11/14); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 01:19.31 | life_of_e | If anything I'll probably grab the Grandstream HT813 since it'll do almost the whole list |
| 01:19.49 | life_of_e | except for the two lines which I guess means get another later |
| 01:25.48 | *** part/#asterisk TheHonorableKit- (~TheHonora@gateway/tor-sasl/thehonorablekitt) |
| 01:26.56 | *** join/#asterisk TheHonorableKit- (~TheHonora@gateway/tor-sasl/thehonorablekitt) |
| 01:27.28 | *** part/#asterisk TheHonorableKit- (~TheHonora@gateway/tor-sasl/thehonorablekitt) |
| 01:36.47 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
| 03:27.51 | *** join/#asterisk bank (~bank@acrossthemoat.com) |
| 04:29.38 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 05:40.59 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 05:51.20 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:58.23 | *** join/#asterisk war9407 (~war@2600:4040:400f:c300:10a:12ee:bd81:2acb) |
| 06:00.38 | *** join/#asterisk GameGamer43 (sid5533@gateway/web/irccloud.com/x-ebaimuyzitwrcdzo) |
| 06:00.38 | *** mode/#asterisk [+o GameGamer43] by ChanServ |
| 06:01.09 | *** join/#asterisk drmessano (drmessano@pdpc/supporter/active/drmessano) |
| 06:01.19 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 06:02.29 | *** join/#asterisk emk (~emk@unaffiliated/emk) |
| 06:21.34 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 06:43.07 | *** join/#asterisk Oatmeal (~Suzeanne@c-73-169-85-214.hsd1.co.comcast.net) |
| 07:23.44 | *** join/#asterisk jkroon (~jkroon@165.16.203.61) |
| 07:26.33 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 07:30.15 | *** join/#asterisk pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 08:03.15 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 08:21.15 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |
| 08:40.55 | *** join/#asterisk nix8n82 (~AndChat62@c-71-229-220-202.hsd1.co.comcast.net) |
| 09:37.23 | *** join/#asterisk Asgaroth (~Asgaroth@212.2.172.228) |
| 09:40.24 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 09:47.32 | *** join/#asterisk AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 10:12.58 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 10:44.34 | *** join/#asterisk DanB (~DanB@clt-195.192.207.219.ip-anschluss.net) |
| 12:12.30 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 12:16.11 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 12:37.55 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 12:58.50 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 13:20.15 | *** join/#asterisk tmoore (~tmoore@2600:1702:4110:3d10:a22d:2005:e500:b20e) |
| 13:23.31 | *** join/#asterisk bumblebeer (~bumblebee@071-045-082-221.res.spectrum.com) |
| 13:37.05 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:45.42 | *** join/#asterisk AndChat|620489 (~AndChat62@2600:100e:b049:62e5:61a9:1ced:cbb1:c86c) |
| 13:46.33 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:46.43 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-axmmdilxefsicgmz) |
| 13:46.43 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:11.13 | *** join/#asterisk TheHonorableKit- (~TheHonora@gateway/tor-sasl/thehonorablekitt) |
| 14:33.33 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 14:37.45 | *** join/#asterisk dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 14:49.06 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 14:56.22 | *** join/#asterisk u0m3_ (~u0m3@5-12-140-12.residential.rdsnet.ro) |
| 15:03.05 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 15:04.31 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b049:62e5:5d14:f0bd:ba18:d23d) |
| 15:06.37 | *** join/#asterisk kharwell (kharwell@nat/digium/x-bgwlyehknrofoqtz) |
| 15:06.37 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:19.22 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 15:23.03 | *** join/#asterisk nix8n82 (~AndChat62@2600:100e:b049:62e5:5d14:f0bd:ba18:d23d) |
| 15:31.46 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-vjirxrlkjpavedao) |
| 15:31.46 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 16:26.08 | AlexBell | When sendrpid=pai is set, what determines the phone number Asterisk puts into the P-Asserted-Identity header? |
| 16:28.18 | *** join/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 16:38.55 | *** join/#asterisk bumblebeer_ (~bumblebee@071-045-082-221.res.spectrum.com) |
| 16:44.10 | [TK]D-Fender | the callerid <- |
| 16:45.49 | *** join/#asterisk _0x5eb_ (~seb@seb-hpws2.w1.tele.crt1.net) |
| 16:51.09 | Samot | AlexBell: The same number that is used in the From Headers. Asterisk sets CallerID via From (because that is the core base looked at) when you set sendrpid=pai, it will build the PAI headers based on the Caller ID so unless you override the fromuser in the peer settings, the From Name/User will be the same as the CallerID Name/Number in the PAI headers. |
| 16:52.10 | Samot | If sendrpid=yes or sendrpid=rpid then instead of PAI headers, RPID headers are used. |
| 16:53.46 | Samot | igcewieling: ^^^^ |
| 16:53.54 | Samot | I didn't see the nick change.. |
| 16:53.57 | igcewieling | Samot: thanks. |
| 16:54.01 | igcewieling | I'd forgotten I' |
| 16:54.15 | Samot | PJSIP allows you to set both if desired. |
| 16:54.54 | igcewieling | drat. |
| 16:57.55 | igcewieling | I'll continue to rely on setting PAI manually until all our core servers are on PJSIP, since I can't really modify what Asterisk uses. Asterisk is using formats like 2345678900 instead of what I want +12345678900. I'd hoped to change it using CALLERID(num) and let Asterisk handle the rest. |
| 16:58.56 | *** join/#asterisk puzzled (~puzzled@2001:982:1097:1::1:3) |
| 16:59.10 | Samot | So if you set CALLERID(num) to a E.164 format, the PAI headers do not present it in E.164? |
| 17:02.35 | igcewieling | As far as I can tell, correct. However, I'm setting the CallerID in the pre-dial handler, not the main dialplan. I can try it in the main dialplan if you think it might help. |
| 17:03.19 | igcewieling | It is in the pre-dial handler since there is where custom headers need to be set with pjsip and I set CallerID in the same place by default. |
| 17:03.26 | Samot | This is just a straight up 2-channel call? |
| 17:04.26 | igcewieling | correct. |
| 17:04.58 | Samot | But the dialplan and the debug show it being there without the +? |
| 17:05.02 | igcewieling | From the dialplan: Executing [s@sm_pre_dial:42] Set("PJSIP/vzb-regular-00000004", "ARRAY(CALLERID(num),CALLERID(name))=+12129182000,") in new stack |
| 17:05.02 | igcewieling | From a sip capture of the call: P-Asserted-Identity: <sip:12129182000@209.220.119.20> |
| 17:06.50 | Samot | Is there anything in the dialplan to validate that? |
| 17:07.05 | Samot | That the ARRAY actual set that value? |
| 17:07.26 | Samot | That the ARRAY actually set that value and that nothing replaced it before the final Dial()? |
| 17:07.29 | igcewieling | a dumpchan shows it, but I can add a Noop proving it out if you like. |
| 17:08.55 | igcewieling | A pre-dial handler is run inside the dial |
| 17:09.12 | igcewieling | I'll try setting it on the main channel and see what happens. |
| 17:09.34 | Samot | Oh wait... |
| 17:09.54 | Samot | Yeah, pre-dial assigns the vars to the channel being created... |
| 17:10.00 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 17:10.15 | Samot | So you're setting the CallerID on the new channel that _it_ would preset when it spawns a new channel |
| 17:10.27 | Samot | Yeah do that before pre-dial, it has to be set on the calling channel. |
| 17:10.41 | igcewieling | I wish it was consistant |
| 17:13.11 | Samot | Well how are you calling the pre-dial handlers? |
| 17:13.40 | Samot | b or B |
| 17:14.32 | igcewieling | Unfortunately I can't work on this more right now. |
| 17:14.45 | Samot | Well it sounds like b since you're adding headers.. |
| 17:14.50 | Samot | Which is the callee channel. |
| 17:15.11 | Samot | you need to use B as well to do things on the calling channel, like set that channels callerid. |
| 17:17.12 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 17:22.06 | igcewieling | Executing [~~s~~@sm_dial:19] Dial("PJSIP/ewieling-desk-00000003", "PJSIP/vzb-regular/sip:+18503168628@63.77.76.248,360,gb(sm_pre_dial^s^1)U(sm_answer)F(stub_sm_intercept^s^1)") in new stac |
| 17:22.28 | igcewieling | there is my dial line |
| 17:25.57 | *** join/#asterisk eolz (c3a7c2ac@gateway/web/freenode/ip.195.167.194.172) |
| 17:26.44 | eolz | hello |
| 17:31.34 | Samot | That's the issue. |
| 17:32.46 | Samot | You're only running the handler on the spawned channels. You need to use B(context^ext^pri) to deal with the calling channel. |
| 17:32.48 | igcewieling | I'll go back to the original way, it isn't a big deal. |
| 17:33.02 | Samot | Or just set the CallerID before the dial. |
| 17:33.27 | igcewieling | Until last week I was setting CallerID before the dial. |
| 17:34.08 | igcewieling | Since PAI no longer is copied to the outgoing channel, I thought maybe CallerID wasn't either. |
| 17:34.16 | igcewieling | I see now that I was wrong. |
| 17:42.21 | *** join/#asterisk miralin (~Thunderbi@194.8.128.68) |
| 18:24.13 | *** join/#asterisk u0m3__ (~u0m3@5-12-140-12.residential.rdsnet.ro) |
| 18:42.20 | *** join/#asterisk Oatmeal (~Suzeanne@c-73-169-85-214.hsd1.co.comcast.net) |
| 18:44.40 | *** join/#asterisk rpifan (~rpifan@ipb218f10f.dynamic.kabel-deutschland.de) |
| 19:10.08 | *** join/#asterisk kunwon1 (~kunwon1@unaffiliated/kunwon1) |
| 19:25.13 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 19:27.35 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 19:59.42 | igcewieling | Samot: Back in the Asterisk 1.4 days I needed to use PAI headers, but Asterisk didn't directly support that. It worked well enough I'm just now getting around to looking at letting Asterisk handle it 8-| |
| 20:00.54 | Samot | Well, alright then. It was introduced in 1.8. |
| 20:05.11 | *** join/#asterisk jkroon (~jkroon@165.16.204.34) |
| 20:13.19 | *** part/#asterisk TheGallopingFox (TheGallopi@gateway/vpn/privateinternetaccess/thegallopingfox) |
| 20:14.25 | *** join/#asterisk salviadud (~ralfalfa@187-167-69-132.static.axtel.net) |
| 20:31.06 | *** join/#asterisk miralin (~Thunderbi@194.8.128.68) |
| 20:42.47 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 20:56.40 | *** join/#asterisk tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 21:01.10 | *** join/#asterisk rpifan (~rpifan@ipb218f141.dynamic.kabel-deutschland.de) |
| 21:11.39 | *** join/#asterisk rpifan (~rpifan@ipb218f141.dynamic.kabel-deutschland.de) |
| 21:13.09 | *** join/#asterisk rpifan_ (~rpifan@ipb218f07c.dynamic.kabel-deutschland.de) |
| 21:25.40 | *** join/#asterisk rpifan_ (~rpifan@ipb218f07c.dynamic.kabel-deutschland.de) |
| 21:33.08 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 22:18.41 | *** join/#asterisk dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 22:31.24 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 23:04.40 | *** join/#asterisk Maxxed (~Maxxed@ec2-107-20-252-119.compute-1.amazonaws.com) |
| 23:05.51 | *** part/#asterisk kharwell (kharwell@nat/digium/x-bgwlyehknrofoqtz) |
| 23:06.10 | *** part/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 23:07.54 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 23:26.12 | *** join/#asterisk miralin (~Thunderbi@194.8.128.68) |
| 23:46.39 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 23:54.13 | *** join/#asterisk dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |