All incoming routes died after modules update

Hi all!

Saturday night I figured I’d update the modules in our FreePBX Distro since it has been a good month since I had done so previously. This morning we noticed no inbound calls were coming through, callers only heard silence. After checking firewall, ISP, and SIP trunk providers for issues, I thought it may have something to do with the module updates, so I checked and verified that there was no incoming calls since the updates . By total chance I got one of the incoming routes working by changing the ring group, then found that if I made any change to the route, such as destination, or caller ID lookup source, that route would start working again. So after making simple edits in all of our 25 incoming routes, they are all working again. But I’m curious on what could of caused this. I always figured updating modules was a safe bet? Any thoughts would be greatly appreciated!

Here’s our current setup…
FreePBX 5.211.65-8
Asterisk 1.8.26.1
All modules up to date as of May 3, 2014

Here’s the log of when a call would come in. It would bascially just loop the same lines every 3 or 4 seconds, I searched the non-existent destination for Gosub line, but only found non-related issues from like 5 years ago.

[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [mydid@from-trunk:1] Set(“SIP/inno-00002422”, “__FROM_DID=mydid”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [mydid@from-trunk:2] Gosub(“SIP/inno-00002422”, “app-blacklist-check,s,1()”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@app-blacklist-check:1] GotoIf(“SIP/inno-00002422”, “0?blacklisted”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@app-blacklist-check:2] Set(“SIP/inno-00002422”, “CALLED_BLACKLIST=1”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@app-blacklist-check:3] Return(“SIP/inno-00002422”, “”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [mydid@from-trunk:3] Gosub(“SIP/inno-00002422”, “cidlookup,cidlookup_3,1()”) in new stack
[2014-05-05 10:21:49] ERROR[2880] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:cidlookup, Extension:cidlookup_3, Priority:1)
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: == Spawn extension (from-trunk, mydid, 3) exited non-zero on ‘SIP/inno-00002422’
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [h@from-trunk:1] Macro(“SIP/inno-00002422”, “hangupcall,”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@macro-hangupcall:1] GotoIf(“SIP/inno-00002422”, “1?theend”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Goto (macro-hangupcall,s,3)
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@macro-hangupcall:3] ExecIf(“SIP/inno-00002422”, “0?Set(CDR(recordingfile)=)”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: – Executing [s@macro-hangupcall:4] Hangup(“SIP/inno-00002422”, “”) in new stack
[2014-05-05 10:21:49] VERBOSE[2880] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/inno-00002422’ in macro ‘hangupcall’
[2014-05-05 10:21:49] VERBOSE[2880] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on ‘SIP/inno-00002422’
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [mydid@from-trunk:1] Set(“SIP/inno-00002423”, “__FROM_DID=mydid”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [mydid@from-trunk:2] Gosub(“SIP/inno-00002423”, “app-blacklist-check,s,1()”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@app-blacklist-check:1] GotoIf(“SIP/inno-00002423”, “0?blacklisted”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@app-blacklist-check:2] Set(“SIP/inno-00002423”, “CALLED_BLACKLIST=1”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@app-blacklist-check:3] Return(“SIP/inno-00002423”, “”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [mydid@from-trunk:3] Gosub(“SIP/inno-00002423”, “cidlookup,cidlookup_3,1()”) in new stack
[2014-05-05 10:21:53] ERROR[2881] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:cidlookup, Extension:cidlookup_3, Priority:1)
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: == Spawn extension (from-trunk, mydid, 3) exited non-zero on ‘SIP/inno-00002423’
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [h@from-trunk:1] Macro(“SIP/inno-00002423”, “hangupcall,”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@macro-hangupcall:1] GotoIf(“SIP/inno-00002423”, “1?theend”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Goto (macro-hangupcall,s,3)
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@macro-hangupcall:3] ExecIf(“SIP/inno-00002423”, “0?Set(CDR(recordingfile)=)”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: – Executing [s@macro-hangupcall:4] Hangup(“SIP/inno-00002423”, “”) in new stack
[2014-05-05 10:21:53] VERBOSE[2881] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/inno-00002423’ in macro ‘hangupcall’
[2014-05-05 10:21:53] VERBOSE[2881] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on ‘SIP/inno-00002423’

Wow, same issue.

Thanks for your “fix”

You are a life saver.

You should open a bug report to put it on the radar of the developers.

I have this issue now too… where is the fix or work around? I did updates last night… and now the PBX will accept no calls.

Did you try making small changes to the incoming routes and applying the changes?

how are you doing the updates? via the gui? the paid sysadmin module or via the command line?

For mine it was just using the Module Admin and doing normal updates there. I did make a change to the inbound routes, saved it, then a reload made it work again. Very odd.

I’m bumping this because this just happened to me this week. As noted, making a minor change to the Inbound Route, submitting the change, changing it back, submitting then change and then committing the change will get the route working again.

Nothing will get changed ptravel, I opened this issue as a bug and Tony Lewis determined it was a problem with one of the modules and not FreePBX itself. With well over 100+ modules included with the FreePBX distro, good luck in trying to narrow it down :frowning: I myself haven’t had the same issue since.