Summary:ASTERISK-18203: Problems with NAT on realtime peers (and maybe static ones)
Reporter:daren ferreira (daren)Labels:
Date Opened:2011-07-28 09:51:37Date Closed:2012-11-02 07:32:45
Status:Closed/CompleteComponents:Channels/chan_sip/General PBX/pbx_realtime
Versions: Frequency of
is related toASTERISK-20572 Realtime Peers behind NAT are Set to RFC1918 private address after sip reload
Description:I just upgraded from to because of ASTERISK-17964 and related issues, to see if the leak was corrected, it was, but now i get NAT problems.

My peers are set to nat=yes but asterisk send packets to their private IPs (fullcontact) instead of public IP (ipaddr).

I didn't change anything else rtcachefriends from "yes" to "no" to test the leak i had on
Comments:By: daren ferreira (daren) 2011-07-28 16:44:47.253-0500

After more tests i discovered that the problem was related to fullcontact information that pointed to a private ip, like "sip:s@" and asterisk was using it... and so it failed (probably because not taking attention of NAT).

After deleting fullcontact info from database the calls stopped to fail.

I get a bit lost with asterisk way of managing NAT, for example i don't understand why it sends packets to private ip adress ( according to tcpdump ) and then use public IP address...

In the previous issue, i don't understand why a buggy fullcontact made the call fails...
Normally asterisk sends packets to private IP then if it fails and NAT is activated asterisk send packets to ipaddr:port got at registration time... but why a buggy fullcontact makes asterisk differ

Then i don't know when fullcontact should be updated by asterisk. Since i emptied it to get calls to work, it has never been refilled by asterisk... even if peer registered dozens times since then...

So because of all these questions i don't know if my issue is a real issue

By: Walter Doekes (wdoekes) 2011-08-16 03:07:52.640-0500

I'm not a 100% sure, but I believe the following was the case when I looked into this on 1.6.2.x:

(1) fullcontact is only written when rtcachefriends=yes
(2) the (unaltered) Contact: header is stored there, so it could be a RFC1918 address
(3) asterisk uses the ipaddr field from the DB if present for the IP-destination, and the fullcontact as the R-URI. i.e.: "INVITE <fullcontact> ..." sent to <ipaddr>

I quick guess is that it still loads the fullcontact when rtcachefriends=no and uses that address for IP-destination => you're now sending to the RTF1918 addresses, if the fullcontact is still set.

By: daren ferreira (daren) 2011-08-25 04:02:47.644-0500

Thank you for your comment, but according to my case, the way it should do is not the way it does.

I discovered that even if rtcachefriends=no, fullcontact is used to reach the peer, packets are send to the RFC1918 ip address, and so it fails, and it never tries to use the ipaddr

Since i reset the fullcontact fields of my peers, it first tries to send packets to private IP (maybe from asterisk internal database's /SIP/Registry information) and if it fails, it uses ipaddr (from realtime or asterisk internal database - no idea).

Might it be considered as normal or as buggy?

By: Rachickiy Andrey (gofman) 2011-09-02 12:44:19.100-0500

IP address changes to Private only after 'sip reload'. I confirm the problem with.
voip*CLI> core show version

A similar problem has already been - https://issues.asterisk.org/view.php?id=15194
But in version  1.8 already has a this patch

I am really sorry for my bad English.

By: Walter Doekes (wdoekes) 2011-09-09 01:32:13.129-0500

Are you guys listening on IPv6 as well? (bindaddr=[::] ?)

By: Rachickiy Andrey (gofman) 2011-09-09 03:06:29.187-0500

I'm not listening to ipv6
[root@voip ~]# cat /etc/asterisk/sip.conf | grep -v '^;' | grep bindaddr | awk '{print $1}'

By: JoshE (n8ideas) 2012-10-16 22:25:31.066-0500

I can confirm this behavior also persists on Asterisk 10.9.0 as well.

Register a realtime peer with a fullcontact that is behind NAT with rtcachefriends=yes and do a 'sip reload'.  Make a call and Asterisk will query the database for the realtime peer.  It will return the private address and so a 'sip show peers' shows the private IP address.  If that peer is qualified, as many of them are, it will now go and stay unreachable until the peer re-registers, which resolves the issue.