Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
Asterisk sip nat
Business SIP Providers
|Provider||Plan Details||Monthly Rate *|
Vonage Business SIP Trunking
SIP Trunking Made Clear and Simple
4 trunk min.
Build your phone system online in 5 minutes
DefinitionIn a client definition
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.
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 infoQ: 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 188.8.131.52. The NAT gateway maps the source ports in a random or pseudorandom manner akin to:
192.168.1.10:5060 --> 184.108.40.206:32947
192.168.1.11:5060 --> 220.127.116.11: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 18.104.22.168: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.
- Siproxd: Has the ability to be run as a transparent sip proxy thus not needing any NAT support to be enabled in asterisk.
- Asterisk config sip.conf
- Asterisk sip qualify: The qualify option
- NAT and VOIP
- Asterisk How to connect to FWD: Examples of configurations
- SIP express router: The SIP express router may be used as an outbound proxy and nat helper for clients inside a NAT device.
- Asterisk Avoid SIP NAT Traversal
- ip_nat_sip Problems with this Linux Module
Back to Asterisk SIP channels
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+