Asterisk sip nat

Asterisk sip nat

Definition

In a client definition

nat=yes|no|never|route

If a peer is configured with  nat=yes , it causes Asterisk to ignore the address information in the SIP and SDP headers from this peer, and reply to the sender's IP address and port.  nat=yes  enables a form of  Symmetric RTP  and SIP  Comedia mode  in Asterisk.

Comedia mode means that Asterisk will ignore the IP and port in the received SDP from the peer and will wait for incoming RTP. This RTP should arrive to the port that Asterisk replied in the "200 OK" SDP. After that, Asterisk already knows where to send its RTP.

This make communication possible with UA's behind  NAT  which don't solve NAT problem in client side ( STUN ,  ICE , ALG enabled router, etc). This options works properly in conjuntion with  qualify=yes  option in order to keep open the connection from Asterisk to the peer behind NAT.

Asterisk 1.8:
The 'nat' option has now been been changed to have  yes ,  no ,  force_rport , and  comedia  as valid values. Setting it to yes forces RFC 3581 behavior and enables symmetric RTP support. Setting it to no only enables RFC 3581 behavior if the remote side requests it and disables symmetric RTP support. Setting it to force_rport forces RFC 3581 behavior and disables symmetric RTP support. Setting it to comedia enables RFC 3581 behavior if the remote side requests it and enables symmetric RTP support.

If your phone does not support "rport"

nat=never  was added around June 29, 2004 to solve a problem where some SIP UAs can't handle the addition of support for "rport" in the header (see RFC3581 ), one of those UAs being the Uniden SIP phone UIP200, for which  nat=route  was then introduced.
It is unfortunate that this "feature" was intermingled with the symmetric NAT option (NAT=yes) on the same parameter, since they are quite different mechanism. A separate parameter to control the RFC3581 behavior
would have been better. 'no' now means "No NAT and/or RFC3581"

Background info

Q:  Is it possible to have several clients behind NAT to register to an Asterisk-server with a public IP-address? When Asterisk receives an incoming call, how will it know @ which private IP-address the client is reachable?

A:  The NAT gateway creates a UDP state mapping between internal source ports and external source (and destination, since most user agents are symmetrical nowadays) ports. The NAT gateway then allocates different external UDP ports for
different "connections" being tracked in this manner.

Consider, for example, two phones - 192.168.1.10 and 192.168.1.11 - registering to an outside SIP UAS through a NAT gateway whose public address is 67.194.23.55. The NAT gateway maps the source ports in a random or pseudorandom manner akin to:

192.168.1.10:5060 --> 67.194.23.55:32947
192.168.1.11:5060 --> 67.194.23.55:47948

If far-end NAT traversal is enabled on the UAS (in the case of Asterisk, that's nat=yes in sip.conf), the Contact URI supplied in the REGISTER message is ignored and the actual "received" IP and port on the network and transport layer is used in its place. The latter is what is stored as the contact binding.

Later, a call comes in and the UAS maps it back to 67.194.23.55:47948 or 32947 depending on which registrant it is destined to go to.

This scenario is not without its problems. Some user agents do not behave symmetrically. Some firewall/NAT router ALGs (application layer gateways) break this process, though they mean well and try to be helpful. But by far the most pressing problem is that many NAT gateways rather quickly age the temporary state information (internal:external UDP port mapping) out after a relatively short period of inactivity.

That is why many far-end NAT traversal approaches implement a policy of periodically "pinging" the stored ("received") contact with some sort of message that causes a bidirectional exchange of communication, and therefore causes the NAT gateway to reset its expiration timer for that "connection" state. In Asterisk, the OPTIONS messages generated when the qualify=yes option is enabled in sip.conf fulfill this function.