| 00:36.41 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 01:04.21 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 01:37.08 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 02:05.02 | *** join/#asterisk MICROburst1 (~Thunderbi@x4d0d9768.dyn.telefonica.de) |
| 02:56.07 | *** join/#asterisk i9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 02:56.34 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 02:57.11 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 03:47.02 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 04:03.46 | *** join/#asterisk cryptic_ (~cryptic@142.196.139.17) |
| 05:38.56 | *** join/#asterisk deavmi (~quassel@165.0.49.28) |
| 05:47.32 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 06:19.10 | *** join/#asterisk joepublic (~joepublic@fsf/member/joepublic) |
| 06:58.10 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 07:10.21 | *** join/#asterisk tsal (~tsal@i59F4A98F.versanet.de) |
| 07:26.03 | *** join/#asterisk jkroon (~jkroon@165.16.203.114) |
| 08:42.59 | *** join/#asterisk naquad_ (~naquad@79.135.214.17) |
| 08:43.03 | naquad_ | hi |
| 08:43.50 | naquad_ | are there any methods for automated dialplan testing/validation? i have found only SIPp and a generator for it Sippy_Cup but they seem to be raw and abandoned |
| 08:47.21 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 09:19.23 | *** join/#asterisk BakaKuna (~user@2a04:9a00:1002:702:f4b5:a89:ab6d:bfff) |
| 09:57.35 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 10:18.02 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 10:44.34 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 10:50.56 | *** join/#asterisk bmg505 (~leon@8ta-246-15-104.telkomadsl.co.za) |
| 10:53.25 | *** join/#asterisk bengoa (~alberto@194.50.55.200) |
| 10:53.25 | *** join/#asterisk mahlon (~mahlon@martini.nu) |
| 11:32.12 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:b019:ad9:d540:d402) |
| 12:03.24 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 12:42.28 | wyoung | naquad_: hi |
| 12:43.54 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 12:44.03 | wyoung | spatel: werd up! |
| 12:51.47 | wyoung | :( |
| 13:48.18 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 14:00.02 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:01.23 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 14:01.43 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-dijyanionfocglqd) |
| 14:30.13 | *** join/#asterisk spatel (~spatel@static-71-174-102-211.bstnma.fios.verizon.net) |
| 14:31.53 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 14:36.40 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-mjvrtckpttwnktyf) |
| 14:36.40 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:42.05 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 14:44.24 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 15:07.32 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 15:10.21 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 15:14.53 | *** join/#asterisk joepublic (~joepublic@fsf/member/joepublic) |
| 15:15.16 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |
| 15:18.46 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-izviazsaleezhcds) |
| 15:18.46 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:38.41 | *** join/#asterisk jkroon (~jkroon@165.16.203.103) |
| 15:49.22 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 15:49.56 | MLC | Is there a command line command that will show the RTP ports in use on a given call, or all call? |
| 15:51.07 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 15:53.59 | igcewieling | netstat -an will show you all open ports and all connected ports. |
| 15:54.37 | MLC | that helps, but doesn't tie the port to the channel |
| 15:54.44 | zicada | m4rcu5: do you mean command line like, the shell, or in the asterisk cli application ? |
| 15:54.47 | igcewieling | correct. |
| 15:54.53 | zicada | mlc: do you mean command line like, the shell, or in the asterisk cli application ? |
| 15:54.54 | MLC | asterisk cli |
| 15:55.28 | Samot | Not that I'm aware. |
| 15:55.40 | Samot | core show channel <channel> doesn't give that information. |
| 15:55.54 | MLC | I wouldn't mind using AMI or ARI if it would be available there |
| 15:56.25 | Samot | Those would be external ways to put/pull information from Asterisk. |
| 15:56.28 | zicada | MLC: do you mean network ports though ? |
| 15:56.33 | Samot | Yes. |
| 15:56.35 | MLC | yes |
| 15:56.41 | Samot | He wants to know which of the RTP ports are in use. |
| 15:56.44 | Samot | Both of them. |
| 15:56.50 | Samot | I would assume. |
| 15:56.59 | zicada | then you can do it at the network layer. |
| 15:57.11 | zicada | not sure any of the libs that implement ARI etc would have that |
| 15:57.22 | zicada | its not really an asterisk thing, more a networking thing i'd say |
| 15:57.56 | MLC | there are messages in the log when the call is established, it is just a pain to look through there and find them |
| 15:57.57 | zicada | at the asterisk level it would be which channels are in use right ? |
| 15:58.02 | zicada | one rtp port per channel or ? |
| 15:58.02 | Samot | Well Asterisk does log the ports. |
| 15:58.10 | Samot | Two |
| 15:58.22 | Samot | There are two RTP ports in use for a single channel. |
| 15:58.25 | Samot | RTP/RTCP |
| 15:58.33 | zicada | ok |
| 15:58.53 | *** join/#asterisk joepublic (~joepublic@fsf/member/joepublic) |
| 15:59.17 | MLC | Maybe I'll just write a quick script to get them from the log file |
| 15:59.46 | Samot | This is a lot of work for a NAT issue. |
| 16:00.09 | zicada | man, i've spent a lot of time on Asterisk NAT issues hehe |
| 16:00.28 | zicada | i never tried to manually gather RTP port numbers though |
| 16:01.04 | zicada | what do you plan to do with the info ? |
| 16:01.13 | zicada | i assume rewrite packets somehow ? |
| 16:01.40 | Samot | No. |
| 16:01.49 | MLC | it is a lot of work. My plan is this: the next time we have calls go silent I'll start a packet capture on the public side of the firewall and also with tshark on the asterisk box. That will let me know where the RTP packets are getting lost. I need the port numbers to correlate with specific agents that report a silent call. |
| 16:01.54 | Samot | The real answer to this, if using PJSIP is to enable HEP |
| 16:02.20 | Samot | Setup Homer to log your traffic. |
| 16:02.25 | Samot | Boom, everything is there. |
| 16:02.28 | zicada | MLC: i see |
| 16:02.32 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 16:02.33 | igcewieling | I thought the real answer was to stop using pfsense, but I might be thinking of someone else. |
| 16:02.44 | Samot | No, that is the real answer for NAT |
| 16:02.52 | Samot | For logging Asterisk SIP packets, HEP+Homer. |
| 16:02.56 | Samot | There's two things happening here. |
| 16:03.00 | MLC | what is HEP? |
| 16:03.14 | zicada | i solved NAT problems with ICE |
| 16:03.26 | MLC | igcewieling: if pfSense turns out to be the problem then I'll certainly change the config or replace it |
| 16:03.40 | Samot | https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Configuration_res_hep |
| 16:03.46 | zicada | not experienced any problems with pfsense and asterisk personally |
| 16:04.55 | ruel | I've only had issues with pfSense and VoIP when the network card wasn't fully supported by pfSense. They _really_ want you to use Intel cards with pfSense. |
| 16:05.16 | zicada | what's the better ARI implementation in your opinion ? Anyone have any experience with the javascript one ? Seems the java one is no longer maintained. Considering options. |
| 16:06.18 | zicada | Samot: what's Homer ? |
| 16:07.00 | zicada | nm |
| 16:07.46 | Samot | It's a logging system. |
| 16:07.52 | zicada | interesting |
| 16:07.54 | Samot | Keeps a history and log of your SIP traffic. |
| 16:08.16 | zicada | can you produce cdr from it ? |
| 16:08.25 | Samot | It's not really meant for that. |
| 16:08.31 | Samot | It's a support tool not an accounting tool. |
| 16:08.52 | zicada | sure but if your cdr blew up somehow could you thoretically reconstruct ? is there enough data for that ? |
| 16:08.58 | igcewieling | zicada: can you generate CDRs from packet captures? I supposed if you wanted to write something to parse the packet captures, but that seems overly complicated. |
| 16:09.01 | Samot | Sure if you want to go through all the packets. |
| 16:09.10 | Samot | Find the INVITES and the BYEs. |
| 16:09.13 | zicada | neat |
| 16:09.15 | Samot | It doesn't do CDRs. |
| 16:09.41 | Samot | It's meant to look at a call and see what happened during it. |
| 16:09.43 | zicada | ah so its logging at the packet level? |
| 16:09.46 | Samot | Yes. |
| 16:09.49 | igcewieling | Homer is an "enterprise" SIP Capture system, it is overly complicated, poorly documented, and appears to have an unhealthy relationship with Docker. |
| 16:09.55 | zicada | why would you want that ? heh |
| 16:10.02 | zicada | unless you're NSA |
| 16:10.44 | zicada | but it solves NAT ? |
| 16:10.52 | zicada | i'm confused |
| 16:11.07 | Samot | That's a networking issue. |
| 16:11.15 | Samot | It's not that hard. |
| 16:11.20 | Samot | MLC is having NAT issues. |
| 16:11.27 | zicada | it just seems to me this Hep things relies/depends on homer |
| 16:11.36 | Samot | MLC is now trying to setup a complicated way to debug these issues. |
| 16:11.43 | zicada | so it only solves Nat issues for people who actually use Homer yes ? |
| 16:11.49 | Samot | No. |
| 16:11.54 | Samot | Homer is for _tracking_ |
| 16:12.06 | zicada | ah right |
| 16:12.11 | Samot | MLC is having a NAT issue. |
| 16:12.11 | zicada | i think i see what you mean |
| 16:12.20 | zicada | so you wanna monitor it with that |
| 16:12.21 | zicada | right |
| 16:12.23 | Samot | He's trying to setup ways to log things for future debugging. |
| 16:13.06 | zicada | the original problem seems to be calls going dead |
| 16:13.09 | zicada | silent |
| 16:13.17 | MLC | that is the problem |
| 16:13.40 | Samot | MLC: are you using the same firewall for lab and production. |
| 16:13.45 | zicada | the asterisk is hosted inside a network with NAT in front or ? |
| 16:13.52 | MLC | Samot: yes |
| 16:14.01 | MLC | zicada: correct |
| 16:14.04 | zicada | where do they go silent ? inside another network with NAT ? |
| 16:14.24 | MLC | on the agent phone, same network as asterisk, behind NAT |
| 16:14.47 | zicada | the phones that go silent are inside the same network as the asterisk ? |
| 16:15.05 | zicada | NAT shouldn't even matter in that case |
| 16:15.23 | MLC | on the same network as asterisk, on calls with sip provider that is outside the network |
| 16:15.43 | MLC | e.g. callers into our call center |
| 16:15.50 | zicada | i see |
| 16:16.26 | zicada | you can't put the asterisk in DMZ or something ? |
| 16:16.39 | zicada | has to be behind NAT essentially ? |
| 16:17.09 | sibiria | the SendDTMF() application describes among the digits, "also 2 for a half second pause, W for a one second pause" - when does this pause happen? |
| 16:17.22 | sibiria | is it equal to SendDTMF -> Wait |
| 16:17.23 | sibiria | ? |
| 16:17.38 | sibiria | also w for a half* |
| 16:17.41 | MLC | I guess it COULD be in DMZ, but I'd rather get a different firewall that will keep it in the LAN |
| 16:18.18 | zicada | sure |
| 16:19.08 | zicada | there's also this one setting in some NAT routers that you wanna turn off, but i guess you've been there already |
| 16:19.50 | zicada | SIP ALG |
| 16:20.17 | zicada | there are some tools to check if the network you're in has SIP ALG on |
| 16:20.50 | MLC | https://forum.netgate.com/topic/105208/does-pfsense-have-sip-alg |
| 16:21.09 | zicada | ah |
| 16:21.30 | zicada | is it easy to test the problem ? |
| 16:21.35 | MLC | no |
| 16:21.39 | MLC | can't replicate it on demand |
| 16:21.43 | zicada | lovely |
| 16:22.37 | zicada | i see why the packet captures now i guess :) |
| 16:25.18 | zicada | do you have a plan for detecting when it happens ? |
| 16:25.20 | Samot | MLC: Did you add NAT rules? |
| 16:25.24 | Samot | Wait. |
| 16:25.37 | Samot | As of yesterday there were no NAT rules. |
| 16:25.50 | MLC | Zicada: my plan is: wait for my agents to complain |
| 16:26.03 | MLC | Samot: I'm experimenting with NAT rules in my lab |
| 16:26.13 | zicada | MLC: ok, they'll notice within a few minutes ? |
| 16:26.21 | zicada | then tcpdump should be suffieicnt right ? |
| 16:26.27 | zicada | and look through it in wireshark |
| 16:26.29 | MLC | within a few seconds |
| 16:26.35 | zicada | np then |
| 16:26.44 | zicada | no need for enterprise system |
| 16:26.45 | zicada | :) |
| 16:26.48 | MLC | I use tshark, but the same output |
| 16:27.28 | zicada | have you looked into the ICE stuff at all ? |
| 16:27.32 | Samot | MLC: Does this happen only on incoming calls or does it happen on outgoing calls as well? |
| 16:27.37 | zicada | to get around NAT that way |
| 16:27.37 | MLC | Samot: both |
| 16:27.51 | MLC | ICE: no. I don't know anything about it |
| 16:27.56 | Samot | And how fast do the call disconnect/loss audio? |
| 16:28.23 | MLC | Samot: varies. Does not seem to be a pattern related to length of call |
| 16:28.32 | Samot | 30 seconds? |
| 16:28.35 | Samot | 15 minutes? |
| 16:28.41 | Samot | 10 minutes? |
| 16:28.44 | MLC | but, when they go silent, it is usually several calls at a time |
| 16:28.50 | MLC | ranges from 3 - 10+ minutes |
| 16:29.06 | zicada | do both ways get silent at once ? |
| 16:29.15 | zicada | or does it go from 2-way to 1-way ? |
| 16:29.17 | MLC | no, I see RTP from the phones outbound |
| 16:29.25 | zicada | is it always working at the start of the call ? |
| 16:29.27 | Samot | And does this happen on internal calls? |
| 16:29.38 | MLC | always works at beginning of call. |
| 16:29.42 | MLC | Does not happen internally |
| 16:29.52 | Samot | OK |
| 16:29.58 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 16:30.02 | zicada | if it always works at the start of the call i tend to think its not really NAT related |
| 16:30.24 | zicada | something happens in the network after some time |
| 16:30.27 | Samot | zicada: That would be incorrect. |
| 16:31.04 | zicada | how would NAT be at fault for that ? |
| 16:31.24 | igcewieling | When it reinvtes or when session timers refresh |
| 16:31.28 | Samot | NAT states being lost. |
| 16:31.32 | Samot | Re-INVITEs |
| 16:32.08 | Samot | MLC: Do you have port randomization enabled on the pfsense box? |
| 16:32.09 | zicada | that sounds almost like a bug |
| 16:32.20 | zicada | it can do it once, can't do it again |
| 16:32.30 | zicada | *shudder* NAT |
| 16:32.40 | igcewieling | Audio loss at around the 30 second mark indicates a possible reinvite issue. Audio loss at 20 or 30 mins indicate a possible session timer issue. |
| 16:33.27 | MLC | Samot: looking... |
| 16:34.12 | Samot | And any "SIP Helpers" |
| 16:34.46 | MLC | Samot: a quick glance at the doc indicates "yes". Randominzation is turned off with static outbound nat rules, which I'm testing in the lab now |
| 16:34.58 | MLC | production is still using the automatic NAT |
| 16:35.00 | Samot | Turn it off. |
| 16:35.08 | Samot | and any SIP Helpers. |
| 16:35.15 | zicada | do calls work in dev over time though ?` |
| 16:35.15 | MLC | no SIP helpers |
| 16:35.43 | zicada | if they do, thats a pretty good reason to disable randomized ports |
| 16:35.46 | MLC | Zicada: so far they have all worked in the lab |
| 16:35.50 | zicada | but that does open up a security consideration |
| 16:36.36 | zicada | still better than putting it in DMZ |
| 16:39.01 | *** join/#asterisk electronic_eel (~quassel@HSI-KBW-46-223-65-185.hsi.kabel-badenwuerttemberg.de) |
| 16:39.41 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 16:40.11 | MLC | pfSense can restrict those static NAT rules to just the one voip.ms server that I use |
| 16:41.04 | *** join/#asterisk hfb (~hfb@47.139.16.213) |
| 16:41.41 | igcewieling | You can't take it out from behind the firewall? |
| 16:42.25 | igcewieling | It isn't tough to secure the system with ip tables as long as you don't have external devices connecting to the server from random IPs. |
| 16:42.33 | MLC | Technically I could, but would rather not |
| 16:43.03 | MLC | yes. I use firehol on my cloud servers for that |
| 16:43.25 | igcewieling | I think 2 or 3 of the 80 FreePBX servers I manage are behind NAT. |
| 16:44.51 | Samot | All of my end users are behind NAT. |
| 16:44.58 | Samot | And generally not just a single device. |
| 16:45.41 | igcewieling | I have many remote voip devices behind NAT. Just not many FreePBX severs |
| 16:45.45 | Samot | Maybe 70 of 2000 endpoints are a PBX or a single IP Phone/ATA. |
| 16:46.14 | Samot | Pretty much the average is about 30 devices per location overall. |
| 16:46.20 | Samot | Maybe higher. |
| 16:46.39 | Samot | And in some cases they have 20 BLFs on their phones. |
| 16:46.49 | Samot | That's a lot of NAT. |
| 16:50.11 | zicada | igcewieling: we have a few, none behind NAT |
| 16:50.20 | igcewieling | Samot: how many registrations on your busiest server? We are at 906 pjsip contacts on my hosted server. |
| 16:50.47 | Samot | I don't have registrations at my server. That's what the proxies are for. |
| 16:51.00 | Samot | <PROTECTED> |
| 16:52.01 | igcewieling | ah, I'd forgotten about that. |
| 16:52.30 | zicada | Samot: is there any mechanism in a redundant setup for notifying your upstream sip provider to route to a different trunk ? |
| 16:52.55 | zicada | or rather, how do you (preferably) do redundancy ? |
| 16:52.57 | igcewieling | zicada: it is called "register from your new IP address" |
| 16:52.57 | Samot | My upstreams don't go directly to my systems like that. |
| 16:53.12 | zicada | igcewieling: interesting |
| 16:53.29 | Samot | My upstreams already have a route set to send my calls to. |
| 16:55.09 | zicada | right, but say datacenter a blows up, would be nice to just tell them to now route to datacenter b |
| 16:55.15 | igcewieling | One of my upstream carrers use SRV to find our servers, another has static IPs set for each of our call routing servers. |
| 16:55.20 | Samot | They already know. |
| 16:55.21 | zicada | or you would have to host a system to do that |
| 16:55.27 | zicada | ok |
| 16:55.45 | Samot | If calls fails to X they failover to Y |
| 16:55.52 | zicada | they already have backups to send to if the primary doesnt answer ? makes sense |
| 16:57.12 | Samot | I have switches between my servers and the upstreams. |
| 16:57.25 | Samot | Upstream sends a call to the switch, the switch decides what to do with it. |
| 16:57.35 | Samot | Servers send calls to switch, same thing. |
| 16:57.43 | zicada | neat |
| 16:57.50 | zicada | what do the proxies do ? |
| 16:57.57 | Samot | Deal with the end users. |
| 16:58.19 | Samot | No end user or upstream directly connects to my voice system. |
| 16:58.30 | zicada | i see |
| 16:58.35 | zicada | so whatever goes through the proxies does |
| 16:58.54 | Samot | Yes, only the proxies and switches are allowed to talk to my voice systems. |
| 17:00.27 | zicada | how much of the total incoming data to the proxies reaches the voice system ? |
| 17:00.40 | zicada | what do you filter away ? |
| 17:00.55 | Samot | Non legitimate traffic. |
| 17:06.34 | *** join/#asterisk spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 17:09.16 | *** join/#asterisk m4rcu5 (nobody@84-106-248-133.cable.dynamic.v4.ziggo.nl) |
| 17:17.59 | zicada | Samot: do you use google's phonenumber lib? |
| 17:18.11 | zicada | for making sense of international calls |
| 17:18.57 | igcewieling | What would you use that for? |
| 17:20.22 | zicada | knowing if some number is valid for a given country |
| 17:21.00 | zicada | and what are cell and what are landline in any given country |
| 17:21.47 | zicada | i use it all over the place now in various wrappers. It's great. Huge collection of compressed regex tables. Updated fairly often. |
| 17:24.58 | igcewieling | I let the carrier reject the call |
| 17:26.27 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 17:26.38 | zicada | its particualrily great in frontends |
| 17:26.43 | zicada | web and such |
| 17:27.30 | zicada | internally inside API's you obviously want to keep to the iso standard for everything, but you know, what is the iso standard way of storing country x's number right |
| 17:27.54 | zicada | i dunno i like it, its a nice "source of truth" and one way fixall for anything having to do with how differnet countries buld up their number stuff |
| 17:28.12 | zicada | and if you have to actually do something with that sort of data, you want something like that, over doing it yourself |
| 17:28.24 | Samot | I already do. |
| 17:28.25 | igcewieling | It is called e.164 |
| 17:28.31 | zicada | yea |
| 17:28.32 | Samot | I have Least Call Routing setup. |
| 17:28.44 | Samot | So based on the match, it goes out a certain carrier. |
| 17:28.56 | Samot | And since I also bill based on that, I already track that. |
| 17:29.05 | zicada | from you guys perspective it would be what the web-developers would use to make it sane in a web form, say |
| 17:29.42 | igcewieling | That isn't really Asterisk. |
| 17:31.07 | zicada | good point, why did i bring that up here. Eh, friday afternoon :) |
| 17:36.12 | *** join/#asterisk offbeatwitch (~offbeatwi@platypus.offbeatwit.ch) |
| 17:49.43 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 17:56.06 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 18:46.23 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:9bf3:59fa:6d08:c46b:5625) |
| 18:47.07 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 19:07.57 | *** join/#asterisk BakaKuna (~user@ip56509c03.direct-adsl.nl) |
| 20:27.15 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 20:38.41 | *** join/#asterisk dobson (~dobson@static.38.6.217.95.clients.your-server.de) |
| 20:55.47 | *** join/#asterisk spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 21:30.43 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 21:30.43 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 21:40.04 | *** join/#asterisk cryptic (~cryptic@142.196.139.17) |
| 21:47.12 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 21:47.12 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 22:32.58 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:9bf3:9953:8aed:d014:e916) |
| 22:43.22 | *** join/#asterisk spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 23:00.43 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 23:49.43 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 23:59.22 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |