IRC log for #asterisk on 20200409

00:17.36*** join/#asterisk mepholic (~mepholic@unaffiliated/mepholic)
00:18.51mepholicanyone know how to deal with the autotools abomination in pjproject?
00:19.32mepholic./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.39mepholicchecking build system type... Invalid configuration `powerpc64-foxkit-linux-musl': machine `powerpc64-foxkit-linux' not recognized
00:20.44mepholicI'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.43lgambithellp
01:54.45lgambitHello
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.57igcewielingI 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.40igcewielingNo 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.35igcewielingno, 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.34igcewielingAt 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.22igcewielingWell, 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.53igcewielingI only see one AGI line.
15:21.00igcewielingyou 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.16greenlightI'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.20igcewielingyup, 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.27igcewielingDon;t do that;
15:26.43_ganapathi_i will try to avoid that.
15:27.05igcewielingSince 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.54igcewielingI assume it thinks the channel is deal because the protocol was violated.
15:28.49_ganapathi_channel is not dead actually.
15:28.59igcewielingI 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.45greenlightShould pjsip handle INVITEs with a Replaces header?
15:33.51igcewielinggreenlight: It should, but if it doesn't then there is nothing you can do about it.
15:35.33greenlightI 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.03seanbrightgreenlight: where is it documented on the wiki?
15:57.29greenlighthttps://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers
15:57.41seanbright(and you have res_pjsip_refer.so loaded, i assume?)
15:58.39greenlightYea, it's generating the outgoing INVITE when it receives the REFER
15:58.48Kobazspeaking of pjsip
15:58.54greenlightAnd that's to another asterisk box that has the call it want's to transfer
15:59.16greenlightThat's getting the INVITE (with a Replaces header) but not reINVITEing as I'd expect
15:59.20Kobazwith pjsip, can asterisk cause a replaces transfer to occur on a 'remote pbx'
15:59.57greenlightYea, that's pretty much what the wiki article I linked discusses
16:00.49greenlightSo my scenario is almost exactly like that article, except "Box B" is another asterisk server
16:01.08greenlightAnd that Box B doesn't seem to be looking at the Replaces header on the INVITE it's getting from box A
16:01.09seanbrightthere is code in res_pjsip_refer to handle an INVITE with a Replaces header
16:01.26seanbrightyou should turn on debug logging and try to figure out why it's not being acted upon as you'd expect
16:01.49greenlightOkay, perfect, if it *should* handle it that's a decent start
16:02.13greenlightIs it gated behind a security setting or something?
16:02.25greenlight(I imagine allowing replaces from anywhere could be a risk?(
16:03.37seanbrighthttps://github.com/asterisk/asterisk/blob/master/res/res_pjsip_refer.c#L937-L1054
16:04.31seanbrightso it does the checks mentioned in RFC 3891 Section 3
16:04.37igcewielingyou mean like allow_transfer=
16:04.57seanbrightthat doesn't apply to the INVITE
16:04.58greenlightAnd refer_incoming_invite_request would get called for any invites?
16:04.59seanbrightjust the REFER
16:05.25seanbrightgreenlight: yes, any INVITEs
16:05.52greenlightPerfect, 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.00seanbrightthat's possible
16:06.00greenlightI'll turn on debug like you suggest and see what's going on
16:06.05seanbrightgood deal
16:06.09seanbrighti think you can turn it on just for that file
16:06.17greenlightThanks so much for confirming and pointing me in the right direction
16:06.27seanbright'core set debug 1000 res_pjsip_refer.c' or something like that? not sure off hand
16:06.53greenlightcool, lemme try that
16:11.02*** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1098:d33f:e414:7d7b:e4ce:9bd0)
16:14.07Kobazexternal_replaces should be implemented using hangup-handler style registration
16:14.13Kobazrather than a context sitting in an extension
16:15.31Kobazadds to the wish list
16:19.12greenlightSo 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.40seanbrightso you followed the instructions in the wiki then? :P
16:22.02greenlightNaa, the wiki doesn't have any instructions about the receiving side
16:22.31seanbrightwell then i don't understand what you did
16:22.36greenlightI 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.45seanbrightoh, sure
16:23.00greenlightI guess that check gets done *before* checking about the repalces stuff
16:23.09greenlightSo not having it prevented it even getting that far
16:23.11greenlightAt a guess
16:23.55seanbrightit would be great if you could add a section to that wiki page that talks about this configuration
16:24.05seanbrightso 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.32greenlightSorry ... 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.47seanbrightyes. at least i think so.
16:35.00seanbrightand you should update the wiki to document your experience.
16:35.06greenlightIf 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.24greenlightSure - I certainly will. I'll do some tests with and without to be sure and then add to it
16:35.32greenlightThanks 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.47twanny796which 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.08joepublic{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.58epaphusI 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.58epaphusand immdiately gets anothers call. It happens to about 2 agents simultenaously.
17:54.07epaphusIf 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.00epaphusIve 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.53greenlightGrab a SIP trace on the agents phones or PCs and check  where the calls originate
17:56.59greenlightPerhaps they have 5060 open publically
18:05.32epaphusgreenlight. We use the eyebeam client. This sip debug should be running on the agents client?
18:05.59greenlightYea, most softphones will be able to give a SIP trace
18:07.14epaphusi will do that.
18:07.18epaphusThank you so much.
18:12.49greenlighthttps://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.29seanbrightyes, it calls each session supplement, like the one that is registered by res_pjsip_refer
18:14.44greenlightPerfect, that's what I assumed that call did
18:15.36greenlightSo 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.30greenlightIs there a way I can suggest an edit to the wiki page, or should I just add my findings as a comment?
18:31.33seanbrightfile: wiki password reset e-mails not going through to greenlight for some reason. something you can look at?
18:32.26greenlightI managed to get it ... its the same logic as the issues jira which did send the reset email through
18:32.36greenlight*login
18:32.48fileI can grant access to edit wiki pages
18:33.01seanbrightoh, i thought anyone could edit
18:33.06seanbrighti guess nevermind
18:33.14fileseanbright: no - or else it ends up like voip-info.org
18:33.25seanbrighta dumpster fire?
18:33.28filegreenlight: username?
18:34.01sibiriaa severely outdated dumpster fire
18:34.05sibiriathat somehow still burns
18:34.12greenlightgreenlightcrm
18:34.36filedone
18:35.12greenlightThanks -- I refreshed... should I see an edit button?
18:35.24seanbrightlog out and log back in maybey?
18:35.25seanbrightmaybe*
18:36.14greenlightHmm... nope unless I'm being dumb I can't see an edit button
18:36.33filelemme double check a thingy
18:36.38greenlightty
18:37.34filehow about now?
18:37.58greenlightBingo
18:37.59greenlightThanks
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.50greenlighthttps://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.46seanbrightgreat. thanks for doing that.
19:12.45greenlightNo 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.48seanbrightsure
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.24velixIsn't it useful to always send ${SIPREFERTOHDR} then ?
20:05.40velixset*
20:05.51velixBecause you'll never know, what B does.
20:11.59greenlightIt depends what  ${SIPREFERTOHDR} is set to really.. it may have no corelation to the call you're wanting to take over
20:16.25greenlightFor 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.39greenlightIn 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.16velixgreenlight: But can't the other PBX do the bridging?
20:23.30velixI mean, can't PBX B bridge the incoming call to Carol?
20:23.36velixAnd drop Bob?
20:23.45velixThen there shouldn't be an issue at all?
20:25.38greenlightYea, 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.37greenlightBut just Dial on ${SIPREFERTOHDR}, may not even go to the correct server, nevermind an extension that needs to exist
20:34.21velix:D
20:37.08greenlightI 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.37greenlightBetter 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.03Cyrillaxwell written, greenlight :)
21:39.39*** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca)
21:47.50CyrillaxRIP 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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.