Can not make calls from ATA or Fixed phones behind NAT



I’ve been facing a weird issue with my UCM 6510 which is preventing me from making calls from fixed remote extensions.

We have +80 extensions, most are locals and some remotes. Local extensions works fine but remote extensions different than GS Wave or Zoiper can not make calls. They can get inbound calls just fine but they can not make outbound.

The UCM is behing a Fortigate with SIP ALG disabled, I also tried moving it outside the firewall and the issue remains.

The following packet sniffer shows the issue clearly when calling from the ATA or GXP1625:

If you place the call from GS Wave, connected to the same natted LAN it goes without any issue at all:

I am out of ideas right now, it was working fine until suddendly it stopped working. I’ve played with many differents NAT types (STUN, uPnP, Keep-Alive) with no success.


Sorry, but the flow(s) both show what appears to be issues. If you can provide a pcap file so the details can be seen, that would help.

Given what I can see, it is definitely a NAT issue.



Sure, I can share a pcap. What exactly do you want to see so I can create a new one containing the appropiate info?


Do you have your static address in the “External Host”?



  • Static IP Address at External Host.
  • Use IP Address in SDP (checked)
  • External UDP 5060
  • External TCP 5060
  • External TLS 5061

Local Network Address are also defined


Take a capture from the UCM, Maintenance. Network troubleshooting of a call with issue.

Normally what happens is that the remote phone sends the INVITE to initiate a call. In that INVITE, there will be a CONTACT header and in the SDP section a connect info header. These headers should contain the public IP so that the UCM will know how/where to respond.

This is much the same as Lucas referred to with the UCM…but in reverse as the phone started the dialogue. The same things apply with the remote phones being behind a NAT as it does with the UCM. The UCM must know where to send the messaging and RTP stream and the remote router must know how to forward same to the initiating device without altering the messaging itself.

As you did not mention the make model of the ATA or phones, I can only provide some general guidance.

  1. If possible, the remote phones should have a static or reserved private IP. It is not mandatory, but if possible lessens the number of issues.
  2. The phones need to be able to punch holes in the remote firewall. This can be done by enabling keep-alive and setting to 30 seconds or so.
  3. Ideally, the remote router will also have SIP ALG disabled.
  4. A NAT IP should also be entered in the phone/ATA field which should reflect the public IP or FQDN. If the remote site is DHCP controlled, then consider DDNS and a FQDN. You want to maximize the opportunity for each side to know the others’ public IP.
  5. Try not to use random ports as there is no guarantee that other devices might not also be using the same.
  6. Enable any security features within the phone such that it will only accept INVITES and messages from the UCM.
  7. If you are able to do the above and have control of the router, you may consider port forwarding the SIP and RTP to the phone. (you did not mention if there might be more than one phone (how many) behind the remote NAT). If many, then the router may struggle with the NAT/PAT tables.

There are other methods of which a VPN is best, but I assume such is not possible.

IN any event, the capture will show more details of what is happening with a failed call.