One way audio, remote endpoint, NAT, and SIP Trunk

endpoint
siptrunk
Tags: #<Tag:0x00007f7027b53878> #<Tag:0x00007f7027b53710>

#1

The perennial one-way-audio issue is plaguing me. I’ve search and read many posts but nothing fits nicely with my situation. I’m hoping to talk this through and figure out the solution.

Situation:
remote phone = 10.6.2.227
firewall @ phone = 10.6.2.254
firewall @ freepbx = 10.1.1.254
freepbx = 10.1.1.227
freepbx NAT external IP = 1.1.2.21
ATT SIP Trunk = 1.1.2.1

Most things work just fine:

  1. The phone registers
  2. It accepts calls
  3. Remote phone hears callers
  4. Callers cannot hear remote phone

This seems like a classic one-way audio issue related to RTP and NAT.

  • The firewalls are not blocking any of the communications
  • TCPDUMP on FreePBX shows SIP communications to remote site

What else can you suggest for diagnosing the one-way audio issue?


(Lorne Gaetz) #2

What local networks have you defined?


#3

Under Settings - Asterisk SIP - NAT Settings …

I’ve set the local networks as those only on the FreePBX side of the firewalls:
10.1.1.0/24
10.1.2.0/24 — we have a VLAN for physical phones that use this network
10.101.1.0/24 — we have a VPN and softphones register and work properly here

I originally had these additional networks listed as local:
10.6.1.0/24 – remote data network, expect softphones registering from here
10.6.2.0/24 – remote VLAN for physical phones, this is where the problem phone lives now

I removed those entries earlier today after I was informed of the one-way audio issue. I’m working remote, about 60 minutes from the impacted site. Trying to fix things this way is quite a challenge (stressful and frustrating)

NOTE - I have only Applied Config after these changes to Asterisk SIP. Recently I’ve read that doesn’t truly apply the changes made to NAT settings. Is that assumption correct? Must I purposefully restart asterisk at the command line?


(Avayax) #4

This maybe?
https://community.freepbx.org/t/public-ip-in-contact-header-despite-network-set-in-local-networks/72467


#5

Something else that I’m having trouble grasping is what the NAT External IP should be.

I understand it’s often the public IP of the FreePBX server.
It could also be the SIP Trunk Gateway.

In all packet traces I continue to see this external IP appearing and wonder if it’s affecting the routing of traffic to/from the FreePBX server.

And could this be the main reason for my one-way audio issues?


#6

Does it show RTP coming in from the remote site? If so, what’s wrong with it (codec, port numbers, etc.)? If not, where did the SDP in the INVITE tell the phone to send it? (It should be the FreePBX public IP and the same port number from which Asterisk is sending RTP.) Does the router/firewall on the FreePBX side have the RTP UDP port range (10000 to 20000 by default) forwarded to 10.1.1.227? Have you confirmed that any SIP ALG is disabled in both router/firewalls?

Can we pinpoint the problem by capturing traffic at the remote phone, the remote router/firewall and/or the local router/firewall? Please post make and model of all three devices.


#7

@Stewart1 , thanks for those suggestions.
endpoint = Grandstream gxp-2130
firewall = pfsense

All proper ports are open, I’m not seeing anything blocked in the pfSense firewall logs.

I can capture traffic on the firewalls or on the FreePBX server. Capturing traffic at the endpoint may be possible, I’ll have to look at how to mirror that switch port’s traffic elsewhere.

The unusual thing is that I’m not seeing any RTP traffic in my packet captures. It’s so strange.

As for the FreePBX public IP, this is where things get complex for me.

Currently the SIP NAT External IP = 1.1.2.21 which is our ATT SIP Trunk gateway
If I change to one of our external public IPs then all incoming/outgoing calls to FreePBX break.

A different testing approach; Since I’m remote from the location I’m attempting another approach for testing and now using a soft phone on my cell phone and registering successfully over the public Internet (I’ve carefully crafted pfSense firewall rules for security). Trouble here is we get no audio at all. Packet tracing this soft phone shows zero RTP traffic, as far as I can tell, I only see SIP.


#8

Very Simply, a successful call needs two parts,

A) SIP negotiates a connection between the two endpoints
B) If successful , any SDP session so negotiated needs to be both honored, opened and forwarded by all router/firewalls between the two endpoints.

Almost allways if no audio, then some element is failing the B bit.


#9

Well, RTP was obviously going out. Did you have a capture filter on tcpdump? Possibly, it went out a different interface?


#10

Assuming that the PBX has two NICs, 1.1.2.21 and 10.1.1.227, in Asterisk SIP Settings, try adding 1.1.2.0 / 24 to Local Networks and change External Address to the public IP through which the remote phone is reached. Restart Asterisk and test.

If no luck, post SIP traces of two failing calls, one with the above settings and one with your original settings.


#11

Thanks for the tips so far. They’ve been helpful in narrowing my focus.

I was able to perform several packet captures which included RTP (had to choose the correct interface).

Result 1 - from cell phone, soft phone; connected over home wifi and public internet to FreePBX
SIP = good, connection made, phone registered
RTP = soft phone sending RTP to 1.1.2.21, which fails entirely

image

Result 2 - from remote office phone, Grandstream; connected over our private WAN
SIP = good, connection made, phone registered
RTP = Grandstream sending packets to 1.1.2.21, response from phone system at 10.1.1.227, results in one-way audio

image

Conclusion - I have a messy config.

But, seriously, these packet captures are clearly pointing at RTP issues and NAT or firewall configurations that need adjustments.

ATT SIP Trunk
Our ATT SIP Trunk is through a local gateway installed on-premise with our firewall and freepbx. It’s physically connected to our firewall because the original plan was to use the fiber installed with the SIP Trunk as a fail-over Internet connection.

The physical connections look like this:
ATT device -> pfSense firewall -> freePBX

The IP addresses look like:
1.1.2.1 -> 1.1.2.21 / 10.1.1.254 -> 10.1.1.227

That’s where the 1.1.2.21 SIP NAT External IP comes into play.

And, if I change the NAT External IP to one of our real public IP addresses then we cannot make/receive calls from the ATT SIP trunk properly.

Source NAT?
I’ve read about programming source NAT/outgoing NAT on the pfSense firewall. Anyone have experience with this to resolve a situation like this?

ATT direct to FreePBX?
Should I just connect the ATT equipment to our FreePBX server? We have the physical NIC ports available on the FreePBX server. My security brain cringes at directly connecting an external device directly to an internal server. To me, that would introduce a vulnerability. Though, ATT assured me nothing can breach their network and crawl out to their customers like me. (haha)


#12

Partial Solution
I’ve resolved the one-way audio issue. The RTP packet analysis for the remote phone to FreePBX revealed packets were flowing properly. The trouble was the pfSense firewall was not properly forwarding the incoming packets from the remote phone to FreePBX. I adjusted the NAT Port Forwarding settings on pfSense and we have two-way audio.

YAY!

New problem
Now I’m encountering the other dreaded problem - calls drop after 30 seconds.

Prior research on this points to NAT issues too, I think.

Here - any advice on the 30-second call drop?


#13

Final outcome (sorta)

It seems things are randomly working fine. The 30-second call drop didn’t exist at all for one endpoint at the remote office. Another phone which had the trouble now doesn’t. There’s no clear explanation for what happened. I haven’t purposefully changed anything.

I’m going to consider this particular thread “closed”.

Thank you for all the tips and suggestions.

For anyone looking here for answers, my solution was to use tcpdump on FreePBX and Diagnostics - Packet Capture on pfSense. Then analyze the results with Wireshark. My findings pointed my to a missing NAT Port Forward missing for one of the interfaces in pfSense.

tcpdump is now my friend