The latest update to FreePBX 13 appears to break incoming calls on Vitelity’s SIP trunk. Vitelity uses the outgoing Trunk configuration for both incoming and outgoing trunks. Things were fine with V.13 until the latest batch of updates. Now outgoing still works. Calls from extension to extension still works (even extensions in other states). However, I now only get a busy signal when trying to call in. The FreePBX server is on a static public IP. This only began with the latest FreePBX 13 updates.
Here are the trunk settings:
vitel-inbound
type=friend
dtmfmode=auto
context=from-trunk
insecure=port,invite
canreinvite=no
host=inbound28.vitelity.net
vitel-outbound
type=friend
dtmfmode=auto
context=from-trunk
canreinvite=no
host=outbound.vitelity.net
You should only require a single context and being a trunk, you should be able to set it as a peer (vs. a friend).
There should not be anything that changed at that level going to 13. If you check your sip_additional.conf file from a backup and that generated on 13, for the given context, they should be the same.
If you changed Asterisk versions in the process of your upgrades then it’s possible (though unlikely for this scenario) that something changed.
Also, if your calls are not coming in from inbound18.viteily.net from them, and some overall SIP defautlts changed as a result of the upgrade (that is possible) then it could be that the calls were previously coming in as ‘unknown’ but you were letting them in, and the new settings are not. This is best fixed by having a proper trunk configuration (if it’s not), vs. allowing unknown SIP INVITE’s into the system (which you could do form the SIP Settings module. So, that’s something worth checking.
So … my best guess is it’s one of these issues and solvable by a more ‘proper’ configuration on your end. But these are all things that you can check and verify. I say should because it’s always possible that a bug was introduced that is doing something different in 13. But given how many upgrades there have been without an issue, I’m suggesting you look at these a bit closer to see if it’s more in your control.
Just to clarify. I was ALREADY on 13. Everything was fine. It was the most recent batch of updates to 13 that appear to have broken it. BTW, the latest batch of updates changed several settings in the new firewall module as well. That was working until the recent updates, but after the updates eth0 was back in trusted. When I attempt to move it back to external, Neither incoming or outgoing work. If I disable the firewall outgoing calls again work but incoming do not.
The configuration is the same as it has been for about a year - going back to 12.
I do not allow “unknown” calls. Never have. And its inbound28.vitelity.net not 18. The SIP settings are those recommended by Vitelity. Those have always worked in the past. I have 3 other systems running 12, different locations, all still working. Same SIP settings. Vitelity provides for authentication by static IP.
Any other ideas?
Just incase its relevant. I am having the same issues. I have setup a new freepbx 13 server to test before rolling it out and now can’t get inbound routes to work. I have tried the ext-did context (which always worked on previous versions) to from-trunk and it just fails.
It seems to ignore the context and just fails.
Here’s the log items.
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [0242270087@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000d", "GROUP()=OUT_2") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [s@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000e", "GROUP()=OUT_2") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000e", "GROUP()=OUT_2") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:2] Goto("SIP/exetel0242270087-0000000e", "from-trunk,h,1") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Goto (from-trunk,h,1)
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [h@from-trunk:1] Macro("SIP/exetel0242270087-0000000e", "hangupcall,") in new stack
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000d", "GROUP()=OUT_2") in new stack
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:2] Goto("SIP/exetel0242270087-0000000d", "from-trunk,h,1") in new stack
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Goto (from-trunk,h,1)
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [h@from-trunk:1] Macro("SIP/exetel0242270087-0000000d", "hangupcall,") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("SIP/exetel0242270087-0000000e", "1?theend") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Goto (macro-hangupcall,s,3)
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [s@macro-hangupcall:3] ExecIf("SIP/exetel0242270087-0000000e", "0?Set(CDR(recordingfile)=)") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Executing [s@macro-hangupcall:4] Hangup("SIP/exetel0242270087-0000000e", "") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/exetel0242270087-0000000e' in macro 'hangupcall'
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("SIP/exetel0242270087-0000000d", "1?theend") in new stack
[2015-11-02 12:41:26] VERBOSE[22678][C-00000469] pbx.c: Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/exetel0242270087-0000000e'
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Goto (macro-hangupcall,s,3)
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [s@macro-hangupcall:3] ExecIf("SIP/exetel0242270087-0000000d", "0?Set(CDR(recordingfile)=)") in new stack
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Executing [s@macro-hangupcall:4] Hangup("SIP/exetel0242270087-0000000d", "") in new stack
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/exetel0242270087-0000000d' in macro 'hangupcall'
[2015-11-02 12:41:26] VERBOSE[22677][C-00000468] pbx.c: Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/exetel0242270087-0000000d'
[2015-11-02 12:43:02] VERBOSE[21980] asterisk.c: Remote UNIX connection disconnected
[2015-11-02 12:47:47] VERBOSE[6850][C-0000046a] netsock2.c: Using SIP RTP TOS bits 184
[2015-11-02 12:47:47] VERBOSE[6850][C-0000046a] netsock2.c: Using SIP RTP CoS mark 5
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [s@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000f", "GROUP()=OUT_2") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:1] Set("SIP/exetel0242270087-0000000f", "GROUP()=OUT_2") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [h@from-trunk-sip-exetel0242270087:2] Goto("SIP/exetel0242270087-0000000f", "from-trunk,h,1") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Goto (from-trunk,h,1)
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [h@from-trunk:1] Macro("SIP/exetel0242270087-0000000f", "hangupcall,") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("SIP/exetel0242270087-0000000f", "1?theend") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Goto (macro-hangupcall,s,3)
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [s@macro-hangupcall:3] ExecIf("SIP/exetel0242270087-0000000f", "0?Set(CDR(recordingfile)=)") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Executing [s@macro-hangupcall:4] Hangup("SIP/exetel0242270087-0000000f", "") in new stack
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/exetel0242270087-0000000f' in macro 'hangupcall'
[2015-11-02 12:47:47] VERBOSE[23149][C-0000046a] pbx.c: Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/exetel0242270087-0000000f'FYI I was able to clear the problem by changing the host from inbound28.vitelity.net to inbound7.vitelity.net.
For some reason unknown as of yet, Fail2ban seems to ban the ip address associated with inbound28 since the last FreePBX updates. this even though i have “whitelisted” all of the ip addresses associated with Vitelty’s incoming and outgoung SIP trunks.
Just uninstall the firewall module for now and flush your iptables.
This has nothing to do with contexts.
I agree it has nothing to do with contexts. Its something in the the firewall module. As per tm1000, I disabled the firewall module, flushed iptables and life is back to normal.
I’m still on 12 and have seen the same thing. Fail2ban bans vitelity. It just started around 10/19/15.
Maybe my issue is different. Its not fail2ban or iptables. Its just the correct context not being used.
I’ll try to trace the dialplan and see what happens.
Ok, my fault 
I couldn’t see what was wrong with the dialplan so i turned on sip debug only to see a “CANCEL” being sent from the provider. it turns out that the trunk was registered with another server and it was hanging up. This caused the call to the new server to get cancelled every time.
When I disabled the other trunk, it works now.