TIPS Can't connect inbound calls on new install of IncrediblePBX

[Dale Fredrikson]

I've run into a problem with inbound calling that I've never seen before, and I'm hoping someone understands it better than I do. Two scenarios may shed light:

1) Inbound route is pointed at an extension with a phone registered. On an inbound call:
-- Caller hears ring tones.
-- Target phone rings.
When target phone is answered:
-- Caller continues to hear ring tones.
-- Target phone stops ringing.
-- Call is not connected.

2) Inbound route is pointed at an IVR. On an inbound call:
-- IVR does not play recording (at least, if it does, the caller can't hear it).
-- Dialable options have no effect.
-- Caller hears 20+ seconds of silence followed by that old ascending 3-tone beep of death that we've all heard.
-- Call is disconnected.

The PBX is a fresh install of IncrediblePBX 13-13.8 (Scientific Linux) on dedicated hardware behind a PfSense firewall, with trunks connected to Skyetel. And it's hard to find anything wrong. Outbound calls work no problem, with 2-way audio. The external and LAN IPs are properly entered in Asterisk SIP Settings and in sip_general_custom.conf. Port 5060 is forwarded to the pbx. Iptables has been updated to allow connection to Skyetel, and Skyetel shows 3 green lights for endpoint health, and also shows the DID has a green light for "inbound activity registered". The PBX shows peer connectivity for some, at least, of the Skyetel IPs:

Skyetel-EU 35.156.192.164 Yes Yes 5060 UNREACHABLE
Skyetel-Inbound 50.17.48.216 Yes Yes 5060 OK (41 ms)
Skyetel-NE 52.60.138.31 Yes Yes 5060 UNREACHABLE
Skyetel-NW 52.41.52.34 Yes Yes 5060 OK (76 ms)
Skyetel-SE 50.17.48.216 Yes Yes 5060 OK (41 ms)
Skyetel-SW 52.8.201.128 Yes Yes 5060 OK (59 ms)

For kicks, I tried my best to take the firewalls out of the picture to see if that would eliminate the problem. I (temporarily) replaced all the iptables rules with an "allow all" rule, and on the PfSense box I currently have TCP/UDP 5000-5082 & 10000-20000 forwarded to the PBX, with linked firewall rules -- even though I know neither TCP nor RTP should need to be forwarded. Result: No dice -- same behavior.

The log doesn't shed much light for me but it might for someone else, so I've attached log dumps for the 2 scenarios.

I'm stumped. Can anyone help me?

Regards,

Dale

 

[Dale Fredrikson]

UPDATE 4/19

I ran tcpdump while attempting an inbound and an outbound call, and the results tell me what's happening, but not why.

For the outbound call, which worked fine with 2-way audio, the pcap shows SIP flows and 2-way RTP. But the inbound call shows only SIP -- no RTP.

Which sounds exactly like a firewall problem, but I'm stumped how. TCP/UDP 10000-20000 are forwarded to the PBX, and iptables on the PBX box has UDP 10000-20000 wide open.

I'm losing my mind on this one. I'd be very grateful if someone could make a suggestion.

Thanks,

Dale

 

[GerryGerry]

I seem to having the exact same issue. Did you ever get it resolved and if so how?
Im running on Incredible PBX 13.13.10 on Ubuntu 18.04 (fresh install)

more info: Every inbound call is cut off with the following in the logs:

Disconnecting call 'SIP/Numbergroup-00000008' for lack of RTP activity in 31 seconds​

 

[Dale Fredrikson]

Hi Gerry. Not exactly. I ended up concluding, tentatively, that the real source of the problem was the ISP (CenturyLink) using a nonstandard MTU and causing packet fragmentation, which didn't agree with the service provider (Skyetel). I solved it by switching to a service provider which uses SIP registration rather than SIP endpoints..

Regards,

Dale

 

[wardmundy]

Whenever we've encountered phones that continue to ring after the call is answered, 99.9% of the time it's because of improperly configured NAT settings, either on the router, or the SIP extension, or the trunk.

 

[Skyetel]

@Dale Fredrikson and @GerryGerry

SIP Fragmentation is really common with CenturyLink. You can actually resolve this by switching to TCP in our portal instead of UDP. UDP can't support larger MTUs in the same way that TCP can. We touch on it briefly here: https://skyetel.atlassian.net/wiki/spaces/SUG/pages/605290497/Troubleshooting

 

[GerryGerry]

Whenever we've encountered phones that continue to ring after the call is answered, 99.9% of the time it's because of improperly configured NAT settings, either on the router, or the SIP extension, or the trunk.

Ward, you were correct (as always ), after much pulling out of hair, I finally tracked the issue down to the following entries in the sip_general_custom.conf file:

;icesupport CHANGED FROM 'yes' to 'no' and stunaddr commented out by GerryGerry  06/06/2019
icesupport=no
;stunaddr=stun.counterpath.net
srvlookup=yes
allowguest=yes

This was found by comparing files from a working install to the fresh problematic one. Why is it there? Anyway I've replied here to help any future users who come across the same issue. thanks everyone for your inputs