One way audio, but only in certain circumstance

I have a strange problem with a customer at the moment. Everything worked until 3 days ago, when inbound audio on external calls stopped working for them.

Setup is SIP trunks to a FreePBX 13.0.192.16 distro hosted on Vultr.
The customer has Grandstream IP phones on their site.
I have a Sangoma Phone in my office, hanging off the same system.

Calls from the SIP trunk to their office exhibit no inbound audio. The audio from the clients office out is fine.
If I add my office phone to their ring group and call their number, then audio is two way.
If they divert their call flow to a mobile, then the audio is two way, so the SIP trunks must be fine

At this stage you will say this must be their firewall. however I can ring from my office to their office using extension numbers and the audio is fine.

There is a second customer also hanging off this same server who have no problems whatsoever.

I have trusted their office IP in the responsive firewall in case this made a difference, but it doesn’t (didn’t think it would).
Is it definitely firewall, or could it be something else?

Do you have NAT set to YES in the extension settings?

Look to the firewall being the problem is calls that do not originate in their network are the ones that fail.

Is the Vultr system “in the cloud” or is it a local implementation?

If in the cloud, make sure that the firewall on the cloud server is set up to route traffic correctly, including redirecting UDP traffic on ports 10000-20000 to the server.

The mystery of one-way traffic is actually fairly simple once you understand that the firewall only opens ports for traffic it recognizes. So, any traffic that starts inside the firewall will work. Any traffic that starts outside the firewall will not. Anything that adds routes out through the firewall will make your two-way traffic work fine.

For calls going out and getting one-way audio, the “return” port for the audio includes the IP address for the traffic. If that address is not routable (NAT is not turned on for the phone and/or a STUN server is not being used to get the routable address), the return traffic will try to go to the non-routable address (192.168.x.z).

So, the problem (as it almost always is) is probably a problem with the firewall. Either it’s blocking the traffic, or the phones are not sending the traffic to the firewall, or some other similar problem.

Since the one-way traffic is on the outbound leg, I’d say the problem is in the NAT configuration on the phone. Either it has lost its “routable” address and/or the NAT setting on the phone has been reset to “No”, which would send a bogus audio destination to the people they are calling.

SIP Debug can help you narrow this down by displaying what addresses are being sent and responded to.

Thank you for your responses.
I can’t find a NAT setting for a pjsip extension. Where is it?
The server is in the cloud on a public IP, so no NAT at the server end.
The phones are sending audio, because in that direction the audio works.

I’ve not used pjsip yet but for chan_sip it was in advanced -> NAT mode. If its not enabled for things not using a VPN then it causes one way audio. All our grandstreams need it.

It should be in the Advnaced SIP Settings (far right side).

You don’t specify PJ-SIP for extensions. It’s a channel driver on the server connected to a UDP/TCP port. The settings for NAT are global for each channel driver and for SIP in general.

The phones should have a NAT settings on them somewhere. I can’t offer more than that on the phones because I only use Polycom phones for SIP and Cisco phones for SCCP.

Problem here is nothing has changed on the phones or the pbx.
The customer is in a business centre, so the firewall serves all the units. Their IT dept is going to reboot the router tonight.

Hi!

Were module updates done on that PBX?

Your problem is not entirely identical to this one

still, the fact configs were apparently not modified but this problems suddenly appeared makes me wonder if the two problems could be related…

Good luck and have a nice day!

Nick