00:17.36 | *** join/#asterisk mepholic (~mepholic@unaffiliated/mepholic) |
00:18.51 | mepholic | anyone know how to deal with the autotools abomination in pjproject? |
00:19.32 | mepholic | ./configure doesn't like my host triple and I can't autoreconf -fvi because configure.in is missing and the autotools config file seems to be called aconfigure.ac |
00:19.39 | mepholic | checking build system type... Invalid configuration `powerpc64-foxkit-linux-musl': machine `powerpc64-foxkit-linux' not recognized |
00:20.44 | mepholic | I've attempted to move aconfigure.ac to configure.ac and run autoreconf, but autoheader bails out after warning about a bunch of missing macros |
01:21.49 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
01:35.11 | *** join/#asterisk ganbold_ (~ganbold@202.21.108.8) |
01:51.58 | *** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
01:54.13 | *** join/#asterisk lgambit (~josephsin@p54A9E999.dip0.t-ipconnect.de) |
01:54.43 | lgambit | hellp |
01:54.45 | lgambit | Hello |
02:08.53 | *** join/#asterisk dandann000dle (~dandann00@2601:840:8401:29c0:2128:b79a:22ce:3341) |
02:22.12 | *** part/#asterisk LiuYan (~NiHola@unaffiliated/liuyan) |
02:42.24 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
02:43.48 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:c59f:c931:1390:5517) |
03:04.18 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
03:48.29 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-149-217.yt.northwestel.net) |
05:24.08 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
05:27.24 | *** join/#asterisk derPlexus (~plexus@ip-176-198-128-59.hsi05.unitymediagroup.de) |
05:41.09 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
06:19.04 | *** join/#asterisk coldfront4 (~coldfront@64.225.16.199) |
06:26.32 | *** join/#asterisk tsal_ (~tsal@i59F5F0DF.versanet.de) |
06:42.24 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:3cd6:b722:66ed:f4d4) |
07:16.13 | *** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
07:25.23 | *** join/#asterisk sekil (~sekil@178-222-1-219.dynamic.isp.telekom.rs) |
07:37.10 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
07:37.17 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:3cd6:b722:66ed:f4d4) |
07:37.43 | *** join/#asterisk Corydon76 (~quassel@96.69.98.139) |
07:37.44 | *** mode/#asterisk [+o Corydon76] by ChanServ |
07:53.31 | *** join/#asterisk eharris (~eharris@unaffiliated/eharris) |
07:59.27 | *** join/#asterisk dandann00dle (~dandann00@2601:840:8401:29c0:1c5c:be9b:647b:ba19) |
08:54.31 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
10:20.32 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:3cd6:b722:66ed:f4d4) |
11:06.36 | *** join/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
11:07.08 | *** join/#asterisk wonderworld (~wonderwor@unaffiliated/wonderworld) |
11:13.10 | _ganapathi_ | https://paste.linux.community/view/a08279f8 |
11:13.51 | _ganapathi_ | i have strange problem suddenly once AGI file changed. |
11:21.26 | *** join/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
11:21.43 | _ganapathi_ | AGI trowing error as Dead CHannel but actually channel is live |
11:23.18 | *** join/#asterisk miltux (~miltux@94-225-27-17.access.telenet.be) |
11:56.29 | *** join/#asterisk jerlique (~stavros@210.8.168.2) |
12:07.27 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
12:09.17 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:3cd6:b722:66ed:f4d4) |
12:21.19 | *** join/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
12:23.50 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
12:56.10 | *** join/#asterisk dandann00dle (~dandann00@2601:840:8401:29c0:e8fe:c222:1254:a068) |
13:08.49 | *** join/#asterisk matrix1233 (~matrix123@80.215.46.147) |
13:14.37 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
13:30.30 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:31b6:354d:3677:6501) |
13:33.34 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:31b6:354d:3677:6501) |
13:55.01 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-zlruzcwxfvyiwgsq) |
13:55.01 | *** mode/#asterisk [+o kharwell] by ChanServ |
14:00.25 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-ftgkoctokxdvrlsh) |
14:00.25 | *** mode/#asterisk [+o bford] by ChanServ |
14:31.21 | *** join/#asterisk wonderworld (~wonderwor@unaffiliated/wonderworld) |
15:01.49 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:c59f:c931:1390:5517) |
15:07.20 | *** join/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
15:08.01 | _ganapathi_ | anybody please help me on this error. Channel is live eventhough playback from agi is failure by saying Dead Channel. |
15:08.05 | _ganapathi_ | https://paste.linux.community/view/a08279f8 |
15:08.39 | _ganapathi_ | am sorry for repeated post on same question. had some internet problem. |
15:14.57 | igcewieling | I don't see any of the surrounding dialplan. |
15:16.11 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
15:16.11 | *** mode/#asterisk [+o cresl1n] by ChanServ |
15:17.14 | _ganapathi_ | exten => cusinfo,n,AGI(/etc/asterisk/kstych-10.121.206.43.sh) |
15:17.40 | igcewieling | No exten => _.,1,whatever? |
15:17.44 | _ganapathi_ | this is the dialplan executing. here i used playback welcome using |
15:18.04 | _ganapathi_ | exten => cusinfo,1,AGI(/etc/asterisk/kstych-10.121.206.43.sh) |
15:18.15 | _ganapathi_ | there is no dialplan unknown extension. |
15:18.26 | _ganapathi_ | it's executing.. |
15:18.35 | igcewieling | no, that is what you have in the dialplan, not what shows in the CLI as it executes. |
15:19.12 | _ganapathi_ | in extension am calling AGI for playback two audio. |
15:19.34 | igcewieling | At this point, I assume either you are violating the AGI protocol or the caller hung up in the middle of your AGI. |
15:19.42 | _ganapathi_ | only that line is for this execution. |
15:20.22 | igcewieling | Well, good luck. |
15:20.34 | _ganapathi_ | here prlbem is am using one AGI,. in that using stream file. then after calling another agi for another playback. |
15:20.53 | igcewieling | I only see one AGI line. |
15:21.00 | igcewieling | you can't call an AGI from another AGI. |
15:22.25 | _ganapathi_ | https://paste.linux.community/view/85e8b628 |
15:22.44 | _ganapathi_ | you may refer complete log on above. |
15:23.40 | _ganapathi_ | $this->getAgi()->exec("AGI", array("buzztts.agi",$text)) |
15:23.49 | _ganapathi_ | using this on 1st AGI. |
15:24.05 | _ganapathi_ | it's working though mostly. |
15:24.19 | _ganapathi_ | sometime am getting error as Dead Channel. |
15:24.28 | _ganapathi_ | on 2nd AGI. |
15:24.55 | _ganapathi_ | once after this error also i can able to playback audio on the same channel using 1st AGI. |
15:25.07 | _ganapathi_ | which shows that channel is not dead. |
15:25.16 | greenlight | I'm following the information here https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers on attended remote transfers. Is there anything special I need to do when recieving an INVITE with a Replaces header? |
15:25.20 | igcewieling | yup, calling an AGI from an AGI: 2020-04-09 12:28:27] VERBOSE[23089][C-00004fc9] res_agi.c: <DAHDI/i1/9558765406-1000>AGI Rx << EXEC "AGI" "buzztts.agi,1238493398"[2020-04-09 12:28:27] VERBOSE[23089][C-00004fc9] res_agi.c: AGI Script Executing Application: (AGI) Options: (buzztts.agi,1238493398) |
15:25.27 | igcewieling | Don;t do that; |
15:26.43 | _ganapathi_ | i will try to avoid that. |
15:27.05 | igcewieling | Since it violates the AGI protocol, I hope you "try" hard. |
15:27.25 | _ganapathi_ | but would you please help me on here what's exactly happening. it's shows dead channel. but actually it's not. |
15:27.54 | igcewieling | I assume it thinks the channel is deal because the protocol was violated. |
15:28.49 | _ganapathi_ | channel is not dead actually. |
15:28.59 | igcewieling | I didn't say it was. |
15:30.03 | _ganapathi_ | ok. it's happening for me for some calls. for some calls it's working though. 30% have prblm. |
15:31.45 | greenlight | Should pjsip handle INVITEs with a Replaces header? |
15:33.51 | igcewieling | greenlight: It should, but if it doesn't then there is nothing you can do about it. |
15:35.33 | greenlight | I see ... I was wondering if it was a configuration option somewhere for security. It seems to be treating it like a normal invite and trying to put it into the dialplan. I'd have thought it would work as it's documented on the wiki (at least generating the outgoing INVITE with a Replaces header) |
15:47.19 | *** join/#asterisk hfb (~hfb@47.139.16.229) |
15:57.03 | seanbright | greenlight: where is it documented on the wiki? |
15:57.29 | greenlight | https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers |
15:57.41 | seanbright | (and you have res_pjsip_refer.so loaded, i assume?) |
15:58.39 | greenlight | Yea, it's generating the outgoing INVITE when it receives the REFER |
15:58.48 | Kobaz | speaking of pjsip |
15:58.54 | greenlight | And that's to another asterisk box that has the call it want's to transfer |
15:59.16 | greenlight | That's getting the INVITE (with a Replaces header) but not reINVITEing as I'd expect |
15:59.20 | Kobaz | with pjsip, can asterisk cause a replaces transfer to occur on a 'remote pbx' |
15:59.57 | greenlight | Yea, that's pretty much what the wiki article I linked discusses |
16:00.49 | greenlight | So my scenario is almost exactly like that article, except "Box B" is another asterisk server |
16:01.08 | greenlight | And that Box B doesn't seem to be looking at the Replaces header on the INVITE it's getting from box A |
16:01.09 | seanbright | there is code in res_pjsip_refer to handle an INVITE with a Replaces header |
16:01.26 | seanbright | you should turn on debug logging and try to figure out why it's not being acted upon as you'd expect |
16:01.49 | greenlight | Okay, perfect, if it *should* handle it that's a decent start |
16:02.13 | greenlight | Is it gated behind a security setting or something? |
16:02.25 | greenlight | (I imagine allowing replaces from anywhere could be a risk?( |
16:03.37 | seanbright | https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_refer.c#L937-L1054 |
16:04.31 | seanbright | so it does the checks mentioned in RFC 3891 Section 3 |
16:04.37 | igcewieling | you mean like allow_transfer= |
16:04.57 | seanbright | that doesn't apply to the INVITE |
16:04.58 | greenlight | And refer_incoming_invite_request would get called for any invites? |
16:04.59 | seanbright | just the REFER |
16:05.25 | seanbright | greenlight: yes, any INVITEs |
16:05.52 | greenlight | Perfect, looking at the code, I wonder if it's not finding the other dialog and just doing that "return 0" on line 955 |
16:06.00 | seanbright | that's possible |
16:06.00 | greenlight | I'll turn on debug like you suggest and see what's going on |
16:06.05 | seanbright | good deal |
16:06.09 | seanbright | i think you can turn it on just for that file |
16:06.17 | greenlight | Thanks so much for confirming and pointing me in the right direction |
16:06.27 | seanbright | 'core set debug 1000 res_pjsip_refer.c' or something like that? not sure off hand |
16:06.53 | greenlight | cool, lemme try that |
16:11.02 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:e414:7d7b:e4ce:9bd0) |
16:14.07 | Kobaz | external_replaces should be implemented using hangup-handler style registration |
16:14.13 | Kobaz | rather than a context sitting in an extension |
16:15.31 | Kobaz | adds to the wish list |
16:19.12 | greenlight | So I gave it an extension in the dialplan, and now it seems to be working... Channel PJSIP/gl-cpbx-01a-0000002d swapped with PJSIP/gl-custsbc-01-0000002c into 'simple_bridge' basic-bridge <c366ee50-233b-46 |
16:21.40 | seanbright | so you followed the instructions in the wiki then? :P |
16:22.02 | greenlight | Naa, the wiki doesn't have any instructions about the receiving side |
16:22.31 | seanbright | well then i don't understand what you did |
16:22.36 | greenlight | I had to make an extension that the INVITE generated from the REFER *would* hit if it wasn't picked up by the replaces |
16:22.45 | seanbright | oh, sure |
16:23.00 | greenlight | I guess that check gets done *before* checking about the repalces stuff |
16:23.09 | greenlight | So not having it prevented it even getting that far |
16:23.11 | greenlight | At a guess |
16:23.55 | seanbright | it would be great if you could add a section to that wiki page that talks about this configuration |
16:24.05 | seanbright | so that others don't have the same problem |
16:27.06 | *** join/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
16:28.17 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
16:30.09 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
16:31.49 | *** join/#asterisk greenlight (~wluke@2a02:c7f:8ca4:5a00:2c1c:d3b4:2f78:7d93) |
16:32.32 | greenlight | Sorry ... my pc died mid chat there, not sure if I missed anything. But would that make sense that the extension needs to exist even if the "Replaces" would stop it ever getting there? |
16:34.47 | seanbright | yes. at least i think so. |
16:35.00 | seanbright | and you should update the wiki to document your experience. |
16:35.06 | greenlight | If that's the case I'll just need to modify the Refer-To header a little on the opensips side before it gets passed to the Asterisk box to ensure it's always to somewhere that exists |
16:35.24 | greenlight | Sure - I certainly will. I'll do some tests with and without to be sure and then add to it |
16:35.32 | greenlight | Thanks again it's really appriciated |
16:54.37 | *** join/#asterisk jjrh (~weechat12@2607:f0b0:7:834a:216:3eff:fefe:444f) |
17:14.02 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
17:14.14 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
17:19.34 | *** join/#asterisk twanny796 (~user@antazzo.com) |
17:19.47 | twanny796 | which is the best free sip server nowadays? |
17:20.04 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
17:28.32 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
17:35.08 | joepublic | {best,free} pick any one |
17:38.08 | *** join/#asterisk retentiveboy (~retentive@2001:558:6011:a2:6c20:c96f:ca4f:bf72) |
17:42.50 | *** join/#asterisk greenlight (~wluke@141.170.33.185) |
17:53.05 | *** join/#asterisk epaphus (ba05a922@gateway/web/cgi-irc/kiwiirc.com/ip.186.5.169.34) |
17:53.58 | epaphus | I have the weirdest issue i have seen in my life with asterisk. Recently for 2 weeks and in specific hours of the day at least 2 agents are starting to get a type of loop call from admin@their.local.ip , or 5000@ , or @9001 . The agent all the sudden starts revieving many of these calls he tries to answer but nobody seems to be there he hangs up |
17:53.58 | epaphus | and immdiately gets anothers call. It happens to about 2 agents simultenaously. |
17:54.07 | epaphus | If we set the call the extensions to DND it still happens. If we turn off the asterisk on the server the call still comes in. This only happens to about 4 extensions . All the users are connected via VPN from their remote locations. We cannot recreate the issue from other locations even with the same extension. |
17:55.00 | epaphus | Ive been looking at a sip debug but i dont see any pattern that would indicate this flood, suggesting the call doesnt originate from the server. |
17:56.53 | greenlight | Grab a SIP trace on the agents phones or PCs and check where the calls originate |
17:56.59 | greenlight | Perhaps they have 5060 open publically |
18:05.32 | epaphus | greenlight. We use the eyebeam client. This sip debug should be running on the agents client? |
18:05.59 | greenlight | Yea, most softphones will be able to give a SIP trace |
18:07.14 | epaphus | i will do that. |
18:07.18 | epaphus | Thank you so much. |
18:12.49 | greenlight | https://github.com/asterisk/asterisk/blob/1ef1b1b0c2df9c4e8251f8854968863715cb64c8/res/res_pjsip_session.c#L3267 <-- I'm checking my understanding is correct, would this be where it then goes to call into the part you linked earlier that does the Replaces check, seanbright? |
18:14.29 | seanbright | yes, it calls each session supplement, like the one that is registered by res_pjsip_refer |
18:14.44 | greenlight | Perfect, that's what I assumed that call did |
18:15.36 | greenlight | So yea, if does the check for an extension existing first. Now, if I can get my password reset I can update the wiki.. unfortunately I'm not getting the emails through from it ;/ |
18:26.29 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
18:30.30 | greenlight | Is there a way I can suggest an edit to the wiki page, or should I just add my findings as a comment? |
18:31.33 | seanbright | file: wiki password reset e-mails not going through to greenlight for some reason. something you can look at? |
18:32.26 | greenlight | I managed to get it ... its the same logic as the issues jira which did send the reset email through |
18:32.36 | greenlight | *login |
18:32.48 | file | I can grant access to edit wiki pages |
18:33.01 | seanbright | oh, i thought anyone could edit |
18:33.06 | seanbright | i guess nevermind |
18:33.14 | file | seanbright: no - or else it ends up like voip-info.org |
18:33.25 | seanbright | a dumpster fire? |
18:33.28 | file | greenlight: username? |
18:34.01 | sibiria | a severely outdated dumpster fire |
18:34.05 | sibiria | that somehow still burns |
18:34.12 | greenlight | greenlightcrm |
18:34.36 | file | done |
18:35.12 | greenlight | Thanks -- I refreshed... should I see an edit button? |
18:35.24 | seanbright | log out and log back in maybey? |
18:35.25 | seanbright | maybe* |
18:36.14 | greenlight | Hmm... nope unless I'm being dumb I can't see an edit button |
18:36.33 | file | lemme double check a thingy |
18:36.38 | greenlight | ty |
18:37.34 | file | how about now? |
18:37.58 | greenlight | Bingo |
18:37.59 | greenlight | Thanks |
18:43.13 | _ganapathi_ | $this->chVars->getChannel() giving me with spaces at front. like some variable am getting space at front on AGI. is that normal behaviour or receiving end is the problem. |
18:43.42 | _ganapathi_ | almost all the channel variable having problem. |
18:46.32 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
18:48.51 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:994c:2f5:1a81:908a) |
18:51.36 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
19:09.50 | greenlight | https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers I fixed a missing ) and added the section "Accepting INVITEs of Remote Attended Transfers". Hopefully it makes things cleared to anyone trying this in the future |
19:11.46 | seanbright | great. thanks for doing that. |
19:12.45 | greenlight | No problems, I'm more than happy to contribute back what I can. And thanks for your help with my issues on this and the REFER issue too |
19:17.48 | seanbright | sure |
19:22.55 | *** part/#asterisk _ganapathi_ (~Ganapathi@27.62.18.115) |
19:30.09 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
19:33.18 | *** join/#asterisk hfb (~hfb@47.139.16.229) |
20:05.24 | velix | Isn't it useful to always send ${SIPREFERTOHDR} then ? |
20:05.40 | velix | set* |
20:05.51 | velix | Because you'll never know, what B does. |
20:11.59 | greenlight | It depends what ${SIPREFERTOHDR} is set to really.. it may have no corelation to the call you're wanting to take over |
20:16.25 | greenlight | For instance, in the example, perhaps Bob didn't call Carol directly, perhaps he called an extension on Server B that did something else (maybe a queue), and then ended up bridging to Carol. The Refer-To would contain whatever Bob originally dialled. |
20:17.39 | greenlight | In my particular setup I've an opensips proxy between the Asterisk servers and the users, so the Refer-To contains what they dialled before the proxy decided where to route the call |
20:22.02 | *** join/#asterisk hfb (~hfb@47.139.18.84) |
20:23.16 | velix | greenlight: But can't the other PBX do the bridging? |
20:23.30 | velix | I mean, can't PBX B bridge the incoming call to Carol? |
20:23.36 | velix | And drop Bob? |
20:23.45 | velix | Then there shouldn't be an issue at all? |
20:25.38 | greenlight | Yea, the extension that it'll look for (${SIPREFERTOHDR} if that's what's used), should never be hit, as it should look instead at the Replaces header and bridge to that active call. |
20:27.37 | greenlight | But just Dial on ${SIPREFERTOHDR}, may not even go to the correct server, nevermind an extension that needs to exist |
20:34.21 | velix | :D |
20:37.08 | greenlight | I guess it's also a pretty big security risk. As you're effectively allow users to have the server make calls to any destination they like. Like I could send a Refer-To: premiumnumer@server_that_does_ip_based_auth |
20:37.37 | greenlight | Better be darn sure we trust Bob :) |
20:57.02 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
20:57.38 | *** join/#asterisk netman (~netman@185.94.249.222) |
21:23.31 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:e9ac:8a03:4766:116e) |
21:37.03 | Cyrillax | well written, greenlight :) |
21:39.39 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
21:47.50 | Cyrillax | RIP epaphus, lol. Those were definitely external calls, there's a misconfigured firewall or something over there. We see calls from those extensions all the time on our external proxies. |
21:58.55 | *** join/#asterisk Lenore (b84a0f22@rrcs-184-74-15-34.nys.biz.rr.com) |
22:37.19 | *** join/#asterisk ironhelix (~d@193.56.117.52) |
23:30.31 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
23:50.34 | *** join/#asterisk Janos (~Janos@201.204.94.76) |