SOLVED: No audio on remote extension


after replacing (an old) Freebpx installation with 13, the remote extensions are able to register, intitiate calls, but there is no audio.
During the call setup I can see a 401 error, and after a few seconds the line is dropped because no response from the external extension.
We are running a NAT setup, no SIP ALG, same NAT setting as the old freepbx system.
I’m sure it’s related to some NAT setting, but I cannot find the right one…
Already tried with the (responsive) firewall disabled, and port 5060 and 10000-20000 forwarded, no luck.

What to do…?

Asterisk Version?

In 13, there are two firewall parts.

The first is the Integrated Firewall. You can disable this if you don’t have any ports exposed to the Internet. If your machine has an routable outward-facing interface, you really need to set the Integrated Firewall up so that it works correctly. The second in the Responsive Firewall. This controls your SIP/PJ-SIP/IAX phone connections. They can be controlled independently.

Now, to make matters a little more interesting, your server implements Fail2Ban as well.

If you are coming from an old system, none of this was in place. Also, you need to double check which SIP Channel Driver you are using on port 5060. Look in the Advanced Settings for the controls for these settings.

So, which one did you disable?

Asterisk version is 13.12.2.
I believe I have disabled all firewalls, and the SIP port is right as well.
This is because the phone is regestering, and can initiate calls.
I see the asterisk console messages and when turning sip debug on, I think the root of the cause is to be found in the packets:
A small part regarding the retransmission:


Retransmitting #5 (NAT) to
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK-524287-1—f4f00a539914a437;received=;rport=43129
From: sip:[email protected]2.2;transport=UDP;tag=44c5d920
To: sip:*[email protected];transport=UDP;tag=as462e632e

Looks like the from and to are on the pbx’s internet connection, my quess is that that is the problem!?

It looks to me like there’s some “NAT=YES” entries missing. Check your extension config in the GUI and make sure that NAT is set to Yes. Also, the phone should know if it is routable or NATed and take into account the public/private addresses appropriately.

Hey Dave,

this is the extensions config:

[email protected]
callerid=test <115>

Since the audio outbound is failing, I’d guess that the phone is not set up correctly. It’s either not telling Asterisk how to get the traffic back through the remote firewall, or the remote firewall is not passing the traffic correctly.

Are you sure that force_rport is the right choice for this phone connection? I don’t have an opinion on that nor do I think it’s an issue; I’m just wondering if that might be a factor.

Hi Dave,

I tried all the NAT settings…
Inbound audio is failing as well.
Please mention that the phones were working in the old freebpx setup…

Since you shutdown all of the firewalls, how are you redirecting the audio through the router?

But first, how was it working before? Did you capture the configuration of the extensions and other components before you started? Have you made any other changes except for upgrading the server to the new version? Chan-SIP and PJ-SIP use different ports for listening to the incoming calls - are you sure you’re setting up the right ports and are pointing the extensions at the right channel driver? Are you trying to change to PJ-SIP for your phones?

There are literally a hundred questions that could be asked. I think you need to start explaining what is actually working or not working before we spend dozens of hours trying to shotgun a solution.

What are the logs telling you? You should be getting good information there.

Have you tried any SIP debug steps?

Have you tried wiresharking the connection to make sure that all of the ports and all of the addresses are getting set correctly? How about a ‘tcpdump’ just to make sure that the audio traffic is actually going to the right place?

I know you think the firewall is the problem, but in my experience, it is more of a solution. It lets you control what is connecting and what isn’t. It also gives you the opportunity to positively control what is and isn’t happening in your system. If you are using another firewall (or two), you need to make sure that they are set up correctly. I’d hate to waste more time on a problem that isn’t actually related to FreePBX.

Hi Dave,

thanks for you explanation.
I have triend all sort of things, but now I’m forwarding UDP 5060 and 10000-20000 from the public IP of the router to the IP of the Freepbx (which is on the LAN). These are all the inbound NAT rules to the pbx.
No firewalling in the router is applied.

I’ve tried tcpdump, but there is no audio too. I believe because the to and from are both the public ip of the pbx internet connection, so audio is going nowhere.

I’m also sure I’m using SIP (not PJSIP, as that is disabled) and on the correct ports. Interal extensions are working just fine, so the protocol is doing what it does best.

Logs are telling all kind of things, but I’m not sure what the best approach is, are there any good debug steps to follow and where can I find those?

This tells us a couple of things:

  1. Your remote phone is not providing the correct address for your RTP connection
  2. Your local server isn’t getting any of the audio the other phone is sending.

If you’re forwarding all traffic from 10000-20000 UDP ports to the phone server, then you should be seeing audio traffic coming in from the remote phone. If it’s not working either way, there is definitely something wrong with your NAT setup. Do you have the phone server’s external address set up in the Advanced SIP settings?

Is it possible you made the same mistake I did once and used the “discover external address” from your browser, even though your browser is on another network? It took me a couple of days to figure that one out.

Hi Dave,

what exaclt do you mean with ‘Advanced SIP settings’? I just want to make sure we are looking on the same page.
I have:

  • FreePBX advanced settings
  • SIP settings (tab General SIP settings)
  • SIP settings (tab Chan SIP settings)

The ‘discover external address’ you are referring to is not there, on the General SIP Settings however I have a button with Detect Network Settings.
Under that caption the correct public IP address of the internet connection is visible, as well as the local net.

OK, so it sounds like you’re having an original problem.

Whether all of the settings in FreePBX are correct or not, the issue with audio problems is almost always NAT.

Here’s how I’d approach it:

  1. Start up a tcpdump for the host at the remote end of the connection.
  2. Have the remote phone connect and try to dial.
  3. Watch where the traffic goes.

If you don’t get any traffic on the “external” interface (I don’t know how many interfaces you machine has), try moving to other interfaces. If you see the traffic, look at all of the information in the packets and make sure the remote addresses make sense.

The issue is that the problem could be in any one of four places:

  1. Your local server machine
  2. Your local router to the Internet (the firewall/whatever)
  3. Your remote router (between the Internet and the remote phone) and the remote ISP (they might be blocking your VOIP or RTP traffic?)
  4. Your remote phone (not set up for NAT, getting bad information from DHCP, etc.)

Since we haven’t really gotten any clue where the breakdown is, I suggest you stop changing things until you know where the issue is.

We’re here to help, but there is a universe of places that could be messing your traffic up.

In your original message, you mentioned a 401 error. Did you ever get the “Unauthorized” error fixed?

Hi Dave,

I’ve setup the remote extension behind a pfsense box now, when running a packet trace while calling I can see that the RTP stream is being sent to the internal IP of the PBX.
That is (of course) not reachable.
What can cause the remote extension to try to send the RTP to the PBX’s internal IP while on a remote subnet?

There are NAT settings at each end. These encapsulate the “internal” address inside the routable network packet.

I’m not sure which end’s NAT settings are wrong, but I expect that the NAT setup on the remote phone is not set up for being behind a firewall.

I aggree :smiley:

But…what is the correct setting, the remote phone’s extension config is in the topic…
Currently I testing with a hardphone, what settings can I check?

Which hardphone?
Did you ever resolve the username/password issue (the 401 error from the first message) with the phone?
How did/do you configure the phone?
Can you make this any harder? We’re not mind readers here…

The NAT settings in the remote phone are incorrect. Not in the remote phone’s local extension settings - the phone itself. It has either stopped using a STUN server or it is not configured with the remote routable address at the remote end.

Yealink T42G, I didn’t check if this phone throws that 401 error too (the softphone did, , the current tests are performed with the hardphone. If/when it works with the hardphone, i’ll try the softphone once more.

The phone is manually configured, all I’ve set are the registration server, user and password (and display name).

STUN is not setup, I’m not familiair with STUN at all…do I just set a random STUN server?

And, I know you’re no mind readers…hehe, just don’t know what info you need.

Many thanks (again)

STUN is an acronym I’m too tired to look up right now… Basically, you contact a STUN server and it tells you what your “external” address is. It’s an easy (and more-or-less) universal way to get your routable address without having to know where you are.

Your STUN (or external router) address is required for NAT to work - it’s how the phone tells the server how to get back when it has a non-routable address.

I see.
In the Yealink phone (firmware I’ve found a setting NAT, that was disabled.
After changing that to STUN, savind and rebooting the behaviour hasn’t changed. The trace shows that the RTP packets are still being send to the internal ip adres of the pbx…