Some Incoming calls not coming through

Hello Community :slight_smile:

I have a problem that is somehow weird. We installed FreePBX over 8 months ago and at the beginning we had 80% of incoming calls not cumming trough so in that case the calls would be routed to SIP Providers Voicemail and we would be notified over email that there was a missed call with the Voicemail attached. Eventually we figured out that if we register on our trunk that would solve the case for a while…so we just started a cron job that would register the trunk every 5 seconds and that solved our problem in a big matter. So now there are 5-10 % of calls that are still not cumming trough. Our FreePBX is behind a router and Firewall in LAN Zone and not in a DMZ. On the router itself we disabled the SIP ALG (Application Layer Gateway). Trunk Settings are as follows:
[PEER Details]

[USER Context]

[USER Details]

[Register String]
username:[email protected]

I don’t know where to start to solve this problem and I would appreciate if I would get some hints on how to narrow down the causing problem.

Please if there is some similar Problem - Solution already discussed link me to that one.

Thanks in Advance for the help You provide.

Well for a start the invalid context is ‘invalid’

OK, changed to context=from-trunk :slight_smile:

There is a lot wrong with this. First there is no need for PEER and USER details in the trunk. This can all go under PEER as PEER supersedes USER. Second, they have a bunch of settings that don’t even exist and make no sense.

Everything marked “Garbage” are settings that don’t exist in Chan_SIP, at all. This is how it should look (basic). Everything in the PEER, the USER section empty except for the name and register string.

Now we have to confirm whether this is a sip trunk or an iax2 trunk,

1 Like

@emirbesic If this is an IAX trunk then it’s not SIP and doing all the things in your firewall/NAT for SIP is pointless. IAX and SIP are two different protocols.

This just boggles my mind. How is it even remotely acceptable to have been turned up like this?

1 Like

Sorry I forgot to tell it right away, it is a IAX2 Trunk.

Well my honest suggestion is to get a new provider that actually does SIP. IAX is all but dead, Digium hasn’t touched it in years (over 6+) as Digiuam stopped IAX development before they stopped Chan_SIP development in 2014. Like Chan_SIP it’s a community driven thing now.

On top of that, IAX was never fully or widely adopted so it lacks a lot of documentation and support details when searching the Internet for help with IAX. Not to mention IAX was designed to be simple, one port for everything. If your provider hasn’t been able to solve you not getting 80% of your calls in 8 months then they lack some serious knowledge on how to make IAX work right.

Honestly, like @sorvani pointed out how this could be in production for 8 months like this is beyond me. Why you haven’t switched to a better provider in that time with the amount of failures you are having is also beyond me.

How much traffic is going over this trunk?

Describe your machine, real/virtual, OS , versions.

By what route, physical and directional are the two ends connected?

While calls are open , post the output of

rasterisk -x 'iax2 show netstats'

Machine is Linux 3.10.0-862.2.3.el7.x86_64 #1 SMP Wed May 9 18:05:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and it is Virtual on HyperV with 1GB RAM
HyperV is behind a Firewall and on the Firewall itself we created trough Bandwidth Management guaranteed 3 Mbps Upload/Download and Maximum 5 Mbps Upload/Download for VoIP, we have only 20 VoIP’s so we exaggerate a little :slight_smile:
The two endpoints are connected like this: VoIP Server → Firewall → Router → VoIP Provider Server → PSTN

And this is the rasterisk -x ‘iax2 show netstats’ output:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.