Extension behind NAT

Hi all,

I know i am missing something trivial here. I have read a lot about NAT and i do not seem to get this right.
I have a system running:
phone--->NAT router--->internet--->fusionPBX (without NAT)--->trunk provider (no NAT)

Now, when i make a call with my phone, i see in the following SIP packets (heavily redacted):
INVITE sip:0031xxxxxx@tenant.voip.domain.nl:5080 SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK1173805850;rport
From: <sip:202@tenant.voip.domain.nl:5080>;tag=712368681
To: <sip:0031xxxxxxxxxxx@tenant.voip.domain.nl:5080>
Contact: <sip:202@>
User-Agent: Grandstream GXP2130

Obviously the Via and Contact contain the NAT address of my phone (and not the public address of the NAT router). The result is that the RTP stream is send to the address which, of course, ends up nowhere...

The weird thing is: SOMEtimes the calls DO get through and the public ip of the NAT router of the extension is used.

What am i doing wrong here? Please mind: FusionPBX is NOT behind nat... the (remote) phone is.
Thank you very much in advance.

Don't have any knowledge of Grandstream, but if those phone are similar in configuration to Yealink there should be some settings around NAT Traversal. I tend to use a STUN server, there are a few publicly available ones on the internet. With STUN enabed the Yealink phones correctly set the contact headers and the In IP4 in the SDP body.

In the Internal SIP profile there are also some NAT settings to allow FreeSwitch to "Fix" some NAT problems, I believe they are normally defaulted true.
Ok, time to post a bit more information:
Trunk provider:
My PBX's IP:
My phone's public IP:
My phone's private IP:

I hope using this information and the attacked trace someone can help me with this problem.

Attached Files:

After a new inspection i found that the two calls were not THAT identical. A diff identified this:
< m=audio 16390 RTP/AVP 8 101
> m=audio 26878 RTP/AVP 8 101

And my firewall (from Asterisk era) is allowing UDP for ports 10000-20000. Thanks for letting me explain it to you so i understood it myself :)
The first thing to check is that there is no SIP ALG enabled on the router, Freeswitch. What does the SDP of the INVITE look like?
Interesting you say this DigiDaz, I can only get most handsets to work correctly with ALG enabled, if ALG is off i need to hole punch and ports assign and i still get NAT registration, with ALG on i have very little in the way of issues,

I know A******* is an ALG aware service so having two sip helpers trying to do the same job is a nightmare, but i was under the impression that freeswitch does not have a NAT helper in it.

Can you shed some more light please if i have this wrong :)


Staff member
Freeswitch is excellent at breaking through NAT, I can assure you that 99% of times ALG will cause a problem.

The key is usually never port forward/punch holes through anything.

Simply enabling rport on the phones in most cases will fix it as long as ALG is disabled.