Inbound Caller RTP audio stream being blocked or dropped intermittently

Hello,

I’m new to FreePBX. Having come into a system where it was previously deployed I recently started having a problem where the inbound caller’s audio is being blocked. The RTP stream is not connecting, but everything else about the call connects fine and the caller can hear the outbound audio just fine. It doesn’t happen consistently, so it’s been difficult to pinpoint.

This issue is the same across all 6 of our lines we have from the ITSP. The lines are used as the phone lines to 3 radio studios, 2 in each. The troubleshooting I have done with the Telos VX Prime+ interface shows that everything about the call is connected, but the RTP for the Rx audio is showing no traffic on the failed calls.

I’m in the process of setting up a SPAN connection on the switches to use Wireshark to try to find out if it’s maybe related to a specific port.

Please advise and thank you.

DG

In your router/ firewall, confirm that the RTP port range (default is UDP 10000-20000) is forwarded to the PBX.

Otherwise, you may lose inbound audio when the RTP source port is rewritten by the router.

Thanks. I verified firewall is open to any. This configuration has worked flawlessly for over a year without any changes. One call will work just fine and then the next couple won’t. No pattern to it. Only happens on the inbound RTP. Does the same thing on all 6 of our lines. The logs for the VX Prime show that a connection is made, but 0kbps traffic passing. I’m also working with Telos to troubleshoot.

Update. After reviewing PCAP data all the dropped RTP streams were associated with one specific IP from our provider that our firewall was blocking, even though the rules were set to “any”. The only way to get RTP from that IP was to basically remove the firewall to our FreePBX host VM completely. Not a comfortable feeling, but we are now getting 2-way audio on all calls.

You would have to know which iptables ‘chain’ did the blocking, there are many ‘rules’ and you were presumably blocked by a rule with precedence over what you thought would allow it.

iptables -v -n -L