| 00:23.24 | *** join/#asterisk infobot (ibot@208.53.50.136) |
| 00:23.24 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.22.0 (2018/07/12) 16.0.0-rc1 (2018/08/08), Standard: 15.5.0 (2018/07/12); 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 |
| 00:36.44 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-uzttumezvyaobxul) |
| 00:50.44 | *** join/#asterisk rpifan (~rpifan@2604:2000:6017:bc00::1) |
| 01:22.18 | *** join/#asterisk [NC] (~NC@208.94.241.140) |
| 02:23.51 | frinklabs | F WORD. |
| 02:24.16 | frinklabs | For the record, the SELINUX in any flavor of RH isn't called that |
| 02:24.21 | frinklabs | it is called firewalld |
| 02:24.32 | frinklabs | and if you disable it, your pjsip will work... |
| 02:45.01 | *** join/#asterisk Samot (sid133316@gateway/web/irccloud.com/x-wxkidwhbhumipaeo) |
| 03:09.15 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 03:13.11 | *** join/#asterisk K0HAX_ (~michael@gateway/tor-sasl/k0hax) |
| 03:30.07 | drmessano | wrong |
| 03:32.38 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-vqxzywplrrrofosy) |
| 03:38.09 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 03:45.18 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 03:50.17 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 03:56.11 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 03:59.14 | *** join/#asterisk RT_FM (~RT_FM@unaffiliated/rt-fm/x-8074213) |
| 04:00.47 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 04:12.43 | Samot | 11:30:07 PM <drmessano> wrong <-- YOU'RE WRONG |
| 04:28.24 | *** join/#asterisk kayatwork (~kayfox@orca.zerda.net) |
| 04:47.16 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 04:52.18 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 05:13.14 | *** join/#asterisk Samael28 (~Samael28@149.28.58.236) |
| 05:25.52 | *** join/#asterisk Samael28 (~Samael28@149.28.58.236) |
| 05:26.55 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 05:37.06 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 05:38.10 | Maliuta_ | Samot: he can't be! |
| 05:38.27 | Maliuta_ | stands up for the SAGE-AU homies |
| 05:50.29 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 06:20.24 | *** join/#asterisk Sepultura (~Sepultura@unaffiliated/sepultura) |
| 06:23.28 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 06:24.32 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 06:34.22 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
| 07:07.46 | *** join/#asterisk jamesaxl (~James_Axl@176.98.159.116) |
| 07:33.01 | *** join/#asterisk Sepultura (~Sepultura@unaffiliated/sepultura) |
| 07:44.58 | *** join/#asterisk jkroon (~jkroon@165.16.203.126) |
| 07:48.50 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 08:12.40 | jkroon | has anyone else observed that asterisk (13.22.0) seems to be crashing on shutdown? |
| 08:12.51 | *** join/#asterisk miralin (~Thunderbi@194.8.128.67) |
| 08:13.56 | jkroon | seemingly passing through cdr_mysql based on my stack trace I got from core dump, but actually some call inside libmysqlclient, I'm not observing the crash from elsewhere so thinking that perhaps it's invalid parameters passed to mysql_close() that's causing the problem. |
| 08:17.35 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 08:21.43 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.213.148) |
| 08:24.29 | *** join/#asterisk Alblasco1702 (~Alblasco1@ip5456b46b.speed.planet.nl) |
| 08:28.00 | *** join/#asterisk Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 08:31.30 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.213.148) |
| 08:32.25 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 09:23.44 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 10:09.43 | *** join/#asterisk Eloy (~Eloy@89.101.24.185) |
| 10:30.06 | *** join/#asterisk Asgaroth (~Asgaroth@212.2.172.228) |
| 10:31.46 | *** join/#asterisk rad1game (~R@89.188.103.106) |
| 10:31.54 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 10:32.48 | rad1game | hi again. i'm trying to install softphones for my office on asterisk+freepbx and getting strange error. |
| 10:32.51 | rad1game | [2018-09-05 02:30:03] NOTICE[1796][C-0000000f]: chan_sip.c:25639 handle_request_invite: Failed to authenticate device "102"<sip:102@192.168.0.128>;tag=9485d035 |
| 10:33.23 | rad1game | but user 102 have same pass 102 and I'm entered everything correct. is any way that im entering smth worng in configs? |
| 10:43.45 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:07.46 | n3t | Is there any (recommended?) GUI for exploring CEL? |
| 11:09.14 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 11:09.29 | jkroon | chan_pjsip (res_pjsip?) advertises it's IP address in SDP as the bound-to IP address of the transport (or I assume using some other method of determining the source address when sending from that socket rather). However, for RTP it opens a new port using ANY, which then ends up sending from another address effectively. Can I get pjsip to bind the rtp socket to the same address as what the transport socket was bound to? |
| 11:10.26 | file | there is only the ability to configure a media address and bind to that |
| 11:10.31 | jkroon | ie, if the transport socket is bound to ANY, then so should the RTP socket, if however I choose to bind the transport socket to a specific IP, then so should the RTP socket. For WebSockets it gets even more nasty, but one problem at a time. |
| 11:10.50 | jkroon | file, that should do the trick, "media address" is what I was missing. |
| 11:11.18 | file | it's ANY because of two reasons: first is that DNS can result in IPv6 or IPv4 being used - and later versions will fallback to try to send messages, secondly is for ICE so that all interfaces are tried |
| 11:11.59 | file | it's also complicated because in PJSIP you may not know what transport is being used until later |
| 11:13.20 | jkroon | my use case: I've got multiple IPs bound to the host, primary IP is my management address, and then an address for asterisk to use (1 x IPv4 + 1 x IPv6). In the SDP the correct IP is advertised, but then it gets bound to ANY resulting in RTP being sent from the management IP instead of the instance specific IP. |
| 11:13.54 | file | alter your routing table metric so that the instance specific IP gets used over management? |
| 11:14.09 | file | (unless you can't) |
| 11:14.40 | jkroon | i can't :) |
| 11:15.01 | jkroon | well, in theory I could, have done that in the past, but in this case I could have the same remote IP connect to multiple local IPs. |
| 11:16.11 | jkroon | so i've got a tool called rtdaemon that'll do exactly that given a filter to sniff for port 5060 traffic, and if egress selected IP is different from inbound it'll auto-adjust the routing table to select the correct source-ip, but in this use case that's not going to fly. |
| 11:16.38 | jkroon | file, if I understand, even if the incoming SIP is thus SIP/UDP/IPv4 it is possible that PJSIP will select IPv6 for RTP? |
| 11:17.07 | file | in that case it is unlikely |
| 11:17.16 | file | but everyone always focuses on the easy incoming SDP case for everything |
| 11:17.22 | file | if you know what the remote side wants, everything is easy |
| 11:17.33 | file | if you don't, it's hard |
| 11:19.10 | file | (I am open to someone making an option for it, but it's just not an easy thing) |
| 11:22.55 | jkroon | i'm tring to think of a use-case where binding to ANY instead of the address we advertise in the SDP will NOT work. o=- 20120 20120 IN IP4 192.168.42.139 <-- you mentioned DNS, is there any way that address will not be an IP? |
| 11:23.34 | file | you're thinking SDP, but this also means SIP |
| 11:23.42 | file | if I send a SIP request to "bob.com" |
| 11:23.58 | file | bob.com can resolve to different things, so if you're dual stack, then you may need to transition from IPv6 to IPv4 in the SDP, or vice versa |
| 11:24.01 | jkroon | ok, so pjsip is already bound to a specific IP address on the host, so the SIP traffic works fine. |
| 11:24.10 | file | right, your scenario is specific |
| 11:24.18 | file | so in your case things could be done a specific way and work |
| 11:24.21 | file | but that doesn't cover everyone |
| 11:24.37 | jkroon | agreed. i'm fine with the fact that I'm going to have to write code here. |
| 11:25.36 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 11:26.15 | jkroon | just need to understand enough before going down a road that will (like the chan_sip change recently) cause major problems for others. |
| 11:27.49 | file | if things are behind an option then I'm less concerned |
| 11:33.43 | jkroon | ok, so currently, RTP sockets is always bound against ANY. I'd like that to bind to the address advertised in the SDP (which is determined by the transport socket?). Why not simply bind the rtp socket to the same address as specified in the transport section? |
| 11:33.59 | jkroon | trying to think of a use-case where that would break. happy to make it an option. |
| 11:34.19 | file | so, specifying a transport is not required and actually makes things less RFC compliant |
| 11:34.44 | file | the address advertised in the SDP is determined based on the transport chosen at the time the SIP request is sent |
| 11:35.09 | file | if you are not calling an IP address and you are dual stack, then the request can start out IPv6, if that fails then it can drop down to IPv4 |
| 11:35.20 | file | and in the case of ICE like I said, we can add candidates for both IPv6 and IPv4 |
| 11:35.40 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 11:35.53 | file | so in the case where you are certain that a request will always go out a specific transport, then it can bind to that address |
| 11:36.27 | jkroon | ok, so I'm (as I've learned the hard way over the last couple of years) one of those "I thought I understood SIP but I plainly don't" people. And I'v not even touched on ICE yet. |
| 11:36.47 | file | SIP address resolution can result in a hostname providing different addresses |
| 11:36.51 | file | basically a list |
| 11:37.01 | jkroon | and the SIP conversation can happen over multiple of those channels? |
| 11:37.23 | file | it can |
| 11:37.42 | file | and technically you can provide a hostname as a Contact, so during a session it could change |
| 11:38.59 | file | and ICE essentially gives a list of IP addresses/ports that could be used for RTP, probes them to see which ones work, and based on the priority of them uses one |
| 11:39.38 | jkroon | damn. i'm going to need to re-investigate how I deal with SRV records. because as I understand you, if I have SRV records that state communicate with either host A or host B, and each of those has both an IPv4 and IPv6 address, then in theory the client could switch between sending to host A or host B? |
| 11:40.10 | *** join/#asterisk jamesaxl (~James_Axl@176.98.159.116) |
| 11:40.17 | file | within a session it is unlikely you use a hostname |
| 11:40.41 | file | more large scale operations can do that for more easier load balancing of sessions and for failover within a session itself |
| 11:40.57 | file | the common stuff puts in an IP address, so it's fine |
| 11:40.58 | jkroon | is extremely confused at the moment. |
| 11:41.10 | file | and this is why it's not easy :D |
| 11:41.19 | file | if you stick within your specific scenario, it's simple |
| 11:41.48 | jkroon | yea, even for ICE I'd want to tell the engine, you can use these IP addresses that's local, but nothing else. |
| 11:42.06 | jkroon | however, that would likely result in two ports having to be bound in this case/ |
| 11:42.14 | file | rtp.conf provides a mechanism to blacklist |
| 11:47.30 | jkroon | seems only for stun related? |
| 11:47.46 | file | ICE is a combination of things, including STUN |
| 11:48.12 | file | ah, maybe we don't have one for ICE... |
| 11:48.24 | file | ah no there it is |
| 11:48.29 | jkroon | there is alias related stuff, in other words, local address == actual public |
| 11:48.53 | file | https://github.com/asterisk/asterisk/blob/master/configs/samples/rtp.conf.sample#L89 |
| 11:50.22 | jkroon | ok, so I'll hopefully be able to expand that to have a whitelist too such that I can blacklist [::]/0 and whitelist the i.p.v.4/32 and i:p::v:6/128 |
| 11:50.34 | jkroon | that's a later project though. |
| 11:51.02 | *** join/#asterisk jamesaxl (~James_Axl@176.98.159.116) |
| 11:57.56 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 12:05.18 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 12:05.59 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 12:07.25 | *** join/#asterisk Samael28 (~Samael28@185.139.30.137) |
| 12:32.59 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 12:44.29 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:47.55 | jkroon | file, as per above, in my case I (PJSIP really, chan_sip does what I expected with the RTP port in asterisk 11 at least) advertise an IP in the SDP for the purposes of RTP. My SIP ports is already bound to X:5060/UDP+TCP, X:5061/TLS, where X is a specific IPv4 address, and a matching IPv6 address (so total 2 UDP ports, and 4 TCP ports). So in such a case it would make sense to bind the RTP socket to that specific IP (be it IPv4 or IPv6 as per selection |
| 12:47.55 | jkroon | for SDP), but in cases where there are multiple options (ICE?) it would not? |
| 12:50.42 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 12:50.50 | file | if using a hostname with multiple different address family transports configured OR ICE, then it wouldn't |
| 12:52.09 | jkroon | ok, chan_sip still does in 13 what it did in 11 and rtp socket is bound to the IP. |
| 12:52.22 | jkroon | wondering how to best approach this. |
| 12:52.25 | file | chan_sip rarely changes, so unsurprising |
| 12:52.57 | jkroon | file, agreed, but I suspect you would agree that it would make sense to confirm :). |
| 12:53.59 | jkroon | when setting up, would it be possible to bind to multiple sockets for RTP (ie, one for the IPv4 address, and one for the IPv6 address) and then discard one of them as soon as RTP starts flowing? (or switching between them as the sender switches) |
| 12:54.03 | file | not really, chan_sip can be as it wants to be |
| 12:54.13 | file | it's code so anything is possible but it's not easy |
| 12:54.35 | file | the interface doesn't expect more than 2 sockets (1 RTP and 1 RTCP), the PJSIP RTP side doesn't expect more than 1 RTP instance per stream |
| 12:54.42 | jkroon | ok, so wrong phrasing then - how easy would it be to :). thanks for giving the answer to the intended question. |
| 12:55.14 | jkroon | ok, and binding one socket to both ipv4 and ipv6 is not possible (kernel side). |
| 12:55.25 | file | any does that |
| 12:55.35 | file | it's bound to wildcard IPv4/IPv6 so both |
| 12:55.36 | jkroon | starting to think updating the routing table might not be such a bad idea. |
| 12:55.49 | jkroon | ok, a *specific* ipv4 and a *specific* ipv6. |
| 12:55.55 | file | not possible afaik |
| 12:56.22 | jkroon | upon receiving rtp on the socket, would it be possible to update the sending address? |
| 12:56.35 | file | not afaik |
| 12:56.57 | jkroon | would require rebinding the port? |
| 12:57.00 | file | not without rebinding, which would change the file descriptor, and then that has to be communicated up somehow |
| 12:57.31 | file | haven't touched that though so dunnnnnnnno for sure |
| 12:57.34 | jkroon | EINVAL The socket is already bound to an address. |
| 12:57.40 | jkroon | from bind(2) |
| 13:04.03 | jkroon | of course we're assuming that bind() is in the first place ... |
| 13:27.58 | jkroon | file, once could create a new socket and use dup2() to replace the socket (but keeping the fd). |
| 13:28.09 | jkroon | s/once/one/ |
| 13:28.23 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 13:29.07 | jkroon | the *downside* would be that if the remote side later decides to start sending to another option as provided in the SDP it would break. |
| 13:30.04 | file | I think looking at code initially for this is the wrong direction, the cases have to be defined with their expected behavior and then going from there |
| 13:30.23 | jkroon | please elaborate |
| 13:30.56 | jkroon | oh, sorry. my head is spinning. you're saying use-cases have to be drawn up first, and then we can start coding. |
| 13:31.07 | jkroon | once the decision has been made as to "what the right thing" is. |
| 13:31.11 | file | yes |
| 13:31.14 | jkroon | email discussion on asterisk-dev? |
| 13:31.44 | file | sure, although we have test cases for how things currently work as a result of failover (where the SDP has to change to the new address family) |
| 13:31.57 | file | so existing behavior expectations are there with kinda use cases |
| 13:32.11 | jkroon | won't issuing a new SDP potentially create a new RTP instance anyway? |
| 13:32.19 | file | no. |
| 13:32.51 | jkroon | do we have some indicator that we need to return to "wide" accept (ie, return to ANY address)? |
| 13:33.32 | file | I don't know because as I stated your usage and what you are trying to do is different than exists now, so stuff hasn't been written or thought about for it |
| 13:36.24 | jkroon | ok, i'll draft an email to asterisk-dev to see if we can get some feedback. in case of emergency I'll have to revert to using rtdaemon but that's not ideal. |
| 13:36.46 | file | the current implementation works for the vast majority of people, so I don't know if there would be any feedback |
| 13:37.42 | jkroon | i'll explain, hopefully someone has some ideas. otherwise I'll just implement the "narrowing with bind/dup2" and hide that behind an option (ie, only use it if it's active), in which case I suspect it would be acceptable for most. |
| 13:38.20 | file | the only other time I've seen mention vaguely of it in recent times was a person who wanted at runtime to use IPv6 for RTP and IPv4 for signaling |
| 13:40.14 | jkroon | thanks for your time file. appreciated |
| 13:40.20 | file | oui |
| 13:41.53 | stefan27 | I'm trying to debug an old asterisk (13.15). Didn't the CLI always support some kind of "print ast_sched contents" CLI command? |
| 13:43.38 | file | there's a DEBUG_SCHEDULER compile time option that can be enabled which dumps stuff to debug? |
| 13:45.37 | stefan27 | ah cool, i'll check for that flag |
| 14:08.18 | *** join/#asterisk jeffspeff (~jeff@12.49.160.131) |
| 14:09.54 | *** join/#asterisk tehgooch (tehgooch@unaffiliated/tehgooch) |
| 14:13.41 | *** join/#asterisk kharwell (kharwell@nat/digium/x-wgbhoanxsrvrcucy) |
| 14:13.41 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:17.36 | *** join/#asterisk jkroon (~jkroon@165.16.204.173) |
| 14:23.23 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 14:25.09 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 14:34.49 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:30bd:d471:2b1e:a682) |
| 14:36.01 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 14:47.08 | *** join/#asterisk waldo323 (~waldo323@75-151-31-89-Michigan.hfc.comcastbusiness.net) |
| 14:48.33 | *** join/#asterisk gruetzkopf (gruetzkopf@bnc.dont-follow.us) |
| 14:50.29 | *** join/#asterisk salviadud (~ralfalfa@187-167-69-132.static.axtel.net) |
| 14:50.34 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 14:50.34 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 14:57.42 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-biniajryorzfvtti) |
| 14:57.43 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:00.29 | *** join/#asterisk Samael28 (~Samael28@host70-233-static.58-79-b.business.telecomitalia.it) |
| 15:07.39 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 15:07.44 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-ynlfrezxtlagcdsa) |
| 15:07.44 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:56.32 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 16:10.10 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-lvkvlhbtysfwmjya) |
| 16:20.10 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 17:29.20 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 17:38.49 | *** join/#asterisk jay-- (~jay--@146.218.63.188.dynamic.wline.res.cust.swisscom.ch) |
| 17:58.04 | *** join/#asterisk Xiretza (~Xiretza@mx.brose.me) |
| 17:59.45 | *** join/#asterisk Xiretza (~Xiretza@mx.brose.me) |
| 18:07.29 | *** topic/#asterisk by kharwell -> #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.23.0 (2018/09/05) 16.0.0-rc1 (2018/08/08), Standard: 15.6.0 (2018/09/05); 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 |
| 18:35.21 | *** join/#asterisk Xiretza (~Xiretza@mx.brose.me) |
| 18:37.45 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 18:46.28 | *** join/#asterisk jay-- (~jay--@146.218.63.188.dynamic.wline.res.cust.swisscom.ch) |
| 18:47.10 | *** join/#asterisk jeffspeff (~jeff@12.49.160.131) |
| 18:51.16 | *** join/#asterisk jay-- (~jay--@146.218.63.188.dynamic.wline.res.cust.swisscom.ch) |
| 18:58.17 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 19:53.36 | *** join/#asterisk foo (~foo@unaffiliated/foo) |
| 19:54.32 | foo | Does anyone happen to know how this works? https://www.zipwhip.com - specifically, it seems they allow you to "turn a landline number into a text messaging number" - I haven't heard of this before, didn't think it was possible. Thank you |
| 20:03.27 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 20:13.54 | *** join/#asterisk yoink (~yoink@unaffiliated/yoink) |
| 20:49.26 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 21:01.58 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 21:04.57 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
| 21:06.42 | wyoung | foo: Texting from landlines is disabled in my country so YMMV |
| 21:11.58 | *** join/#asterisk troyt (zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) |
| 21:18.52 | *** join/#asterisk kayfox (~kayfox@orca.zerda.net) |
| 21:28.15 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 21:57.39 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 22:06.12 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 22:19.36 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 22:25.37 | *** join/#asterisk sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 22:33.37 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 22:56.57 | *** part/#asterisk kharwell (kharwell@nat/digium/x-wgbhoanxsrvrcucy) |
| 23:22.24 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 23:47.14 | *** join/#asterisk corretico (~corretico@200.91.143.34) |