Goto (ext-local,vmu101,1)
-- Executing [vmu101@ext-local:1] Macro("SIP/WLC-Inbound-0000051e", "vm,101,NOANSWER,") in new stack
-- Executing [s@macro-vm:1] Macro("SIP/WLC-Inbound-0000051e", "user-callerid,SKIPTTL") in new stack
-- Executing [s@macro-user-callerid:1] Set("SIP/WLC-Inbound-0000051e", "TOUCH_MONITOR=1618349137.144495") in new stack
-- Executing [s@macro-user-callerid:2] Set("SIP/WLC-Inbound-0000051e", "AMPUSER=5053430650") in new stack
-- Executing [s@macro-user-callerid:3] Set("SIP/WLC-Inbound-0000051e", "HOTDESCKCHAN=WLC-Inbound-0000051e") in new stack
-- Executing [s@macro-user-callerid:4] Set("SIP/WLC-Inbound-0000051e", "HOTDESKEXTEN=WLC") in new stack
-- Executing [s@macro-user-callerid:5] Set("SIP/WLC-Inbound-0000051e", "HOTDESKCALL=0") in new stack
-- Executing [s@macro-user-callerid:6] ExecIf("SIP/WLC-Inbound-0000051e", "0?Set(HOTDESKCALL=1)") in new stack
-- Executing [s@macro-user-callerid:7] ExecIf("SIP/WLC-Inbound-0000051e", "0?Set(CALLERID(name)=)") in new stack
-- Executing [s@macro-user-callerid:8] GotoIf("SIP/WLC-Inbound-0000051e", "0?report") in new stack
-- Executing [s@macro-user-callerid:9] ExecIf("SIP/WLC-Inbound-0000051e", "0?Set(REALCALLERIDNUM=5053430650)") in new stack
-- Executing [s@macro-user-callerid:10] Set("SIP/WLC-Inbound-0000051e", "AMPUSER=") in new stack
-- Executing [s@macro-user-callerid:11] GotoIf("SIP/WLC-Inbound-0000051e", "0?limit") in new stack
-- Executing [s@macro-user-callerid:12] Set("SIP/WLC-Inbound-0000051e", "AMPUSERCIDNAME=") in new stack
-- Executing [s@macro-user-callerid:13] ExecIf("SIP/WLC-Inbound-0000051e", "0?Set(__CIDMASQUERADING=TRUE)") in new stack
-- Executing [s@macro-user-callerid:14] GotoIf("SIP/WLC-Inbound-0000051e", "1?report") in new stack
-- Goto (macro-user-callerid,s,23)
-- Executing [s@macro-user-callerid:23] NoOp("SIP/WLC-Inbound-0000051e", "Macro Depth is 2") in new stack
-- Executing [s@macro-user-callerid:24] GotoIf("SIP/WLC-Inbound-0000051e", "1?report2:macroerror") in new stack
-- Goto (macro-user-callerid,s,25)
-- Executing [s@macro-user-callerid:25] GotoIf("SIP/WLC-Inbound-0000051e", "1?continue") in new stack
-- Goto (macro-user-callerid,s,44)
-- Executing [s@macro-user-callerid:44] Set("SIP/WLC-Inbound-0000051e", "CALLERID(number)=5053430650") in new stack
-- Executing [s@macro-user-callerid:45] Set("SIP/WLC-Inbound-0000051e", "CALLERID(name)=BARKING DOG") in new stack
-- Executing [s@macro-user-callerid:46] GotoIf("SIP/WLC-Inbound-0000051e", "0?cnum") in new stack
-- Executing [s@macro-user-callerid:47] Set("SIP/WLC-Inbound-0000051e", "CDR(cnam)=BARKING DOG") in new stack
-- Executing [s@macro-user-callerid:48] Set("SIP/WLC-Inbound-0000051e", "CDR(cnum)=5053430650") in new stack
-- Executing [s@macro-user-callerid:49] Set("SIP/WLC-Inbound-0000051e", "CHANNEL(language)=en") in new stack
-- Executing [s@macro-vm:2] Set("SIP/WLC-Inbound-0000051e", "VMGAIN=") in new stack
-- Executing [s@macro-vm:3] Macro("SIP/WLC-Inbound-0000051e", "blkvm-check,") in new stack
-- Executing [s@macro-blkvm-check:1] Set("SIP/WLC-Inbound-0000051e", "GOSUB_RETVAL=TRUE") in new stack
-- Executing [s@macro-blkvm-check:2] ExecIf("SIP/WLC-Inbound-0000051e", "0?Set(GOSUB_RETVAL=TRUE)") in new stack
-- Executing [s@macro-blkvm-check:3] MacroExit("SIP/WLC-Inbound-0000051e", "") in new stack
-- Executing [s@macro-vm:4] GotoIf("SIP/WLC-Inbound-0000051e", "0?vmx,1") in new stack
-- Executing [s@macro-vm:5] Hangup("SIP/WLC-Inbound-0000051e", "") in new stack
== Spawn extension (macro-vm, s, 5) exited non-zero on 'SIP/WLC-Inbound-0000051e' in macro 'vm'
== Spawn extension (ext-local, vmu101, 1) exited non-zero on 'SIP/WLC-Inbound-0000051e'
-- Executing [h@ext-local:1] Macro("SIP/WLC-Inbound-0000051e", "hangupcall,") in new stackOk - I am pretty sure it is resource exhaustion - I did a fwconsole restart and the problem went away - This is Asterisk 18.2.2 with all PJSIP extensions and 1 SIP trunk - Has anyone else seen this problem?
Why do you suspect "resource exhaustionâ "
I would install sysstat and verify . . .
Because making no config changes whatsoever and just restarting Asterisk made the problem go away - It was working for days before it started this today - just rebooting cleared it - If not resource exhaustion/corruption then why?
sysstat will maintain a history of io,network,cpu etc. Any burgeoning stress will be apparent even in retrospect after you hit the problem with a sledgehammer.
I am wondering if it is something with PJSIP - I have not seen this before with SIP.
Hehe, please donât start that one again !
The mantra is chan_pjsip is wonderful in every way, chan-sip is a POS and should be buried because it doesnât work 
Yeah, that is the mantra I keep hearing - but I also HATE having problems with production boxes that I canât isolate to either misconfiguration or network issues - this one is neither - I have SIP boxes that have been up and running for YEARS! I just got this customer switched over last week and now they had an interruption that I have never seen before - it does not build âbrand-loyaltyâ
You are hitting a dialplan line that does the hangup
-- Executing [s@macro-vm:4] GotoIf("SIP/WLC-Inbound-0000051e", "0?vmx,1") in new stack
-- Executing [s@macro-vm:5] Hangup("SIP/WLC-Inbound-0000051e", "") in new stack
Priority 4 in the macro-vm context does a gotoif with a condition that fails, and so proceeds to priority 5 that does the hangup.
Priority 4 does this check:
GotoIf($["${GOSUB_RETVAL}" != "TRUE"]?vmx,1)
Iâm not sure where in the call flow that the channel var GOSUB_RETVAL gets set to TRUE, but that step appears to be happening in your call scenario. Perhaps a clue might be had if you share the entire call trace via pastebin.
No. The mantra is that chan_pjsip is the current supported driver and chan_sip is unsupported (or to be more precise, community supported). One may well find success by changing to chan_sip, but should be as a last resort.
Yeah, I could see from the console that it was hanging up, but why? And why did rebooting Asterisk (but not changing anything in DialPlan) fix the problem - That is what worries me.
I am trying very hard to stick with PJSIP, but weird problems like this that I have not seen before (we have been using Asterisk since 2004) make me question that decision - no faster way to turn a new customer sour on your services than have a production bug that affects their work.
True, it mostly now works, couple of rough edges still, last to come up for me, how does one totally disable IP auths? This sort of problem also needs a solid corporate response to give comfort , according to the OP it was working for 16 years on chan_sip, now perhaps broken on chan_pjsip?
Are you sure about that? Because:
Thatâs a Chan_SIP channel that is sending your calls to voicemail and causing these âweirdâ issues based on what youâve posted. So if this is a Chan_PJSIP problem, as @lgaetz pointed out we would need to see some actual debugs where PJSIP could be causing these issues.
You should post the actual debug output from when the Park return happens so we can see it from the start.
What rough edges are you referring to? If disabling IP auth is one of those edges then it is clear you havenât spent much time in the last 7.5 years learning about Chan_PJSIP.
First, Chan_PJSIP doesnât have a concept of anonymous callers. You just canât turn on a single setting and let anyone calls/requests come in. You want to accept anonymous calls, you need an actual anonymous endpoint setup for that (FreePBX does that work for you when enabling âAllow Guestsâ).
Second, Chan_PJSIP by default does endpoint matching by username then IP. The username check will check username@domain and then username, if not match on user@domain. Then if none of those match it will look at the IPs. However, in order for it to match those IPs there needs to be an Identity section that has those IPs listed. Not listed, not allowed. Then again, I could also change the match order and even do it by a custom header and not match against username or IP at all. That custom header doesnât exist, rejected.
Just remember this, Asterisk 21. This is a very important future version to be aware of. It is when Chan_SIP has been slated to be completely removed from Asterisk. Gone, see ya later, bye Felicia.
Chan SIP Trunk (Because the provider canât figure out how to make a PJSIP Trunk work) but Chan PJSIP Extensions that are doing the parking and retrieval.
Hereâs a question - When I answer a SIP call with a PJSIP extension and then park it, am I parking a PJSIP channel or a SIP channel? And specifically with this, I am transferring to a PJSIP VoiceMail box - Is that a PJSIP failure or a SIP failure?
I am suspecting PJSIP only because before this year, we were (obstinately) purely Chan SIP - Most of our boxes still are, I am just doing all the new boxes as PJSIP (as much as possible) and in the process of conversion of our base.
Again, itâs a problem we have never seen before, and the only difference is PJSIP for all the extensions - if you take that out, this box is just like the other 70 or so other boxes we have out there.
The provider doesnt need to make chan_pjsip work because it is just SIP. They donât care what SIP driver you have. Making PJSIP work is on you as it would be a config problem.
You are also not sending calls to a PJSIP voicemail. You are sending calls to voicemail. Mailboxes are mailboxes they are not tied to a driver tech.
Again, we need to see a full debug. A variable is being set and the Dialplan is reacting to that. This really isnât a driver issue per se.
Canât get a debug until it starts doing it again - which I am probably going to avoid by setting a CRON job to fwcosole restart in the middle of each night - itâs all well and good to troubleshoot on a bench box - troubleshooting on a production system does not make any friends.
If the Asterisk full log has not rotated out, you can pull it from there:
https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII
1 Like
Ok - That is very cool - yes, I still had the logs - It does look like the log reveals a fair amount of IP information (both internal and external) and the extension with both itâs external IP and itâs internal IP so I anonymized the IPâs and the Phone Numbers.