SIP and NAT - An Introduction
Written by x-console on Oct 05, 2006 - 11:42 AM
The purpose of this article is to provide an introduction to SIP networks, and to provide a definiton of the protocols, processes, and devices commonly used in a SIP network. Tha rticle then expands on NAT, and how it affects SIP communications, explaining some of the solutions that are available for NAT traversal with SIP.
DEFINITIONS
SIP
SIP is a protocol; the product of the Internet Engineering Task Force (IETF), and was developed using open standards. SIP stands for Session Initiation Protocol, which pretty much says it all. SIP, in simple terms, provides a means for users to do 3 simple things:
- Locate other users in order to try and establish a session.
- Establish communicative sessions, through negotiation.
- Enable users to terminate an active session.
RTP
RTP uses UDP for transport over IP. This means it uses a connection-less method of communication, which is great for getting as much data transmitted to the destination as soon as possible, but does not offer any guarantee of delivery as its major drawback.
SDP
SDP stands for Session Description Protocol, and it is used to handle the session negotiation process within a SIP transaction. An SDP packet is often carried as the message body of a SIP request. As part of a SIP INVITE request, an SDP offer is made, detailing a number of characteristics that define the proposed session (such as codec type, contact information, and ports to be used). The response to this, acknowledges acceptance, or offers alternative session parameters, or declines the proposed session with no alternatives offered.
STUN (Simple Traversal of UDP through NAT's)
allows your IP phone to discover NAT implementations (and the type of NAT it provides), in between the ip phone and the STUN server. for this reason most STUN servers are located on the Internet. Your IP phone, prior to making a SIP request, uses the STUN server to find out what NAT binding is in place, and rewrites its SIP packet accordingly. It can also be used to refresh NAT bindings (keep-alive as mentioned earlier). STUN operates great for all NAT implementations apart for symmetric NAT (explained in more detail below..).
TURN (Traversal using Relay NAT)
TURN operates in a ver similar way to STUN but also can handle RTP as well as SIP, meaning the media and signalling are proxied.
NAT
Network Address Translators modify the IP address and port information for packets traversing from one network to another. In its most typical incarnation, this is to used to manage private network ranges, and allow them to interract with publicly routed networks.
There are 4 types of NAT:
- Full cone: The most simple (and least common in modern products) implementation. Operates in a similar way to Port address translation in that packets are accepted and forwarded according to NAT binding rules regardless of source.
- Restricted cone: as above, with the NAT device maintaining a list of allowed originating devices
- Port restricted cone: applies port restrictions to the above
- Symmetric: The most common in modern day solutions. A NAT 'binding' is created by the NAT device in response to a request made from internal_source_ip:port to public_destination_ip:port. This binding is kept alive so you can recieve responses from public_destination_ip:port (but it _has_ to come from this address/port combo). A new binding is created for each unique internal_source_ip:port combo that sends packets somewhere on a network that is external to your NAT device which controls your private LAN.
-------------------------------------------------------------
Elements of a SIP network
The elements of a SIP network fall into one of two categories, broadly speaking: User Agents and SIP Servers
SIP User Agents (UA's)
These are the endpoints in a SIP network, and each UA can be divided into two
sub-components:
User Agent Client (UAC): This entitiy initiaites requests. Imagine picking up your SIP phone to make a call. It is the UAC that makes the request to the SIP server (or sometimes directly to another UA), in order to try and establish a session.
User Agent Server (UAS): This element of a UA is the one which generates responses to requests it has recieved. It is this part of your SIP phone that will play a ring-tone to notify you that another UA wishes to establish a session.
SIP Servers
There are three core pieces of functionality, defined within SIP RFC 3261, which are performed by SIP Servers. One or more (or all) can be performed by the same application or device, and this is exactly what OpenSER is capable of. These types of server, are:
Registrar Sever: This server takes registration requests from UA's, and maintains information as to their location.
Proxy Server: A SIP proxy recieves SIP messages (both requests and responses), that are gerneated by UA's, and forwards them on (either to the destination UA, or the next SIP Server in the route, as specified in the SIP message itself). A proxy does not need to be aware of SIP message body content, as it only operates on SIP headers.
Redirect Server: This conceptual entity recieves requests from a proxy or UA, and responds with a specific SIP response method, telling the originator of the request that the user is not available at that location, and indicates where the request should be sent in order to try again.
Other SIP network entities
Back-to-back User Agent - A B2BUA is a SIP device that recieves a SIP request, reformulates it, and then sends it out as a new request. Responses to the new request are also reformulated and sent back out in the opposite direction. In simple terms, think of it as two IP phones that have some controlling logic about what the other one is doing.. if one rings, it lets the other know, and that phone then makes an outgoing call based on whatever logic has been set.
Some B2BUA's also have built-in media servers so they can perform useful tasks such as transcoding, security, conferencing etc.
RTP Proxy - This merely accepts RTP from a location, and then relays it to another location. packets sent in response are relayed in the opposite direction.
-------------------------------------------------------------
Network Address Translation (NAT) and SIP
There are several 'points of impact' where SIP finds NAT problematic, and it is not merely limited to NAT. RTP also has problems with NAT. Because SIP packets go out from a NATed client with their private (and un-routable) IP addresses coded into the message headers and SDP bodies, they are not processed by a NAT device, that operates only on the IP packets as they pass by. This then means that when the packets get to their destination, they are processed and responded to using completley useless source address information.
The 3 major problems of NAT in SIP
The VIA header problem: Responses to requests cannot he be routed back ot the originating party, as the supplied addressing information is not globally routable.
The CONTACT header problem: This refers to the fact that future requests would be routed incorrectly, again due to non-routable addresses being supplied.
The RTP problem: The final problem in the NAT/SIP category is to do with RTP (by that i mean the actual voice part of the session). The SDP messages which are used to negotiate the session format (codecs, ports, IP's etc), which are often enclosed within the SIP message body, and thus not processed by a SIP proxy according to IETF standards, will contain non-routable contact information as well (i.e. your internal address e.g. 192.168.x.x). This is a tough problem to solve.
There are several solutions to choose from to allow SIP to traverse NAT effectively. None of them is ideal, and much of it is external to SIP. The following sections refers to the
three main problems caused by SIP (listed above), and discusses the techniques applied within the protocol, and common third party solutions, to the problems.
Solutions to those 3 major problems
The Via header answer
This is solved within SIP. When a message arrives at a SIP server or UA, a comparison is made between the address the packet came from, and the one that is listed in the via header. If there is a difference, then the correct IP address (the one from which the packet originated from) is written as a parameter 'recieved=', and is added to the via header.
The contact header answer
This is a similar problem to the Via header issue, and is solved in the same way, updating the contact header instead. The contact header is referred to for communications that occur some time after an original request (such as BYE's or re-INVITE's), and this can cause additional problems, for the following reason:
NAT bindings are kept active on the NAT device for only a finite amount of time if SIP is being transported over UDP.
Solutions to this include using TCP for SIP instead of UDP (which is a connection-oriented protocol and so bindings and associated timeouts arent a problem), employing some kind of keep_alive program to maintain NAT bindings, or using STUN/TURN servers, or even a B2BUA.
The RTP answer
For instances where only one UA is behind a NAT device, symmetric NAT can be used. This effectively synchronises the two RTP streams; the recipeint of the successful RTP stream
(i.e. the globally routable UA in the session) transmits its RTP stream using the source IP of that RTP flow, ignoring the one that SDP has told it to use.
For instances where both users are behind NAT, you can employ a RTP proxy/media server/B2BUA of some kind to relay voice, breaking the call into two separate legs or you can use the TURN protocol (which essentailly does the same thing).
DEFINITIONS
SIP
SIP is a protocol; the product of the Internet Engineering Task Force (IETF), and was developed using open standards. SIP stands for Session Initiation Protocol, which pretty much says it all. SIP, in simple terms, provides a means for users to do 3 simple things:
- Locate other users in order to try and establish a session.
- Establish communicative sessions, through negotiation.
- Enable users to terminate an active session.
RTP
RTP uses UDP for transport over IP. This means it uses a connection-less method of communication, which is great for getting as much data transmitted to the destination as soon as possible, but does not offer any guarantee of delivery as its major drawback.
SDP
SDP stands for Session Description Protocol, and it is used to handle the session negotiation process within a SIP transaction. An SDP packet is often carried as the message body of a SIP request. As part of a SIP INVITE request, an SDP offer is made, detailing a number of characteristics that define the proposed session (such as codec type, contact information, and ports to be used). The response to this, acknowledges acceptance, or offers alternative session parameters, or declines the proposed session with no alternatives offered.
STUN (Simple Traversal of UDP through NAT's)
allows your IP phone to discover NAT implementations (and the type of NAT it provides), in between the ip phone and the STUN server. for this reason most STUN servers are located on the Internet. Your IP phone, prior to making a SIP request, uses the STUN server to find out what NAT binding is in place, and rewrites its SIP packet accordingly. It can also be used to refresh NAT bindings (keep-alive as mentioned earlier). STUN operates great for all NAT implementations apart for symmetric NAT (explained in more detail below..).
TURN (Traversal using Relay NAT)
TURN operates in a ver similar way to STUN but also can handle RTP as well as SIP, meaning the media and signalling are proxied.
NAT
Network Address Translators modify the IP address and port information for packets traversing from one network to another. In its most typical incarnation, this is to used to manage private network ranges, and allow them to interract with publicly routed networks.
There are 4 types of NAT:
- Full cone: The most simple (and least common in modern products) implementation. Operates in a similar way to Port address translation in that packets are accepted and forwarded according to NAT binding rules regardless of source.
- Restricted cone: as above, with the NAT device maintaining a list of allowed originating devices
- Port restricted cone: applies port restrictions to the above
- Symmetric: The most common in modern day solutions. A NAT 'binding' is created by the NAT device in response to a request made from internal_source_ip:port to public_destination_ip:port. This binding is kept alive so you can recieve responses from public_destination_ip:port (but it _has_ to come from this address/port combo). A new binding is created for each unique internal_source_ip:port combo that sends packets somewhere on a network that is external to your NAT device which controls your private LAN.
-------------------------------------------------------------
Elements of a SIP network
The elements of a SIP network fall into one of two categories, broadly speaking: User Agents and SIP Servers
SIP User Agents (UA's)
These are the endpoints in a SIP network, and each UA can be divided into two
sub-components:
User Agent Client (UAC): This entitiy initiaites requests. Imagine picking up your SIP phone to make a call. It is the UAC that makes the request to the SIP server (or sometimes directly to another UA), in order to try and establish a session.
User Agent Server (UAS): This element of a UA is the one which generates responses to requests it has recieved. It is this part of your SIP phone that will play a ring-tone to notify you that another UA wishes to establish a session.
SIP Servers
There are three core pieces of functionality, defined within SIP RFC 3261, which are performed by SIP Servers. One or more (or all) can be performed by the same application or device, and this is exactly what OpenSER is capable of. These types of server, are:
Registrar Sever: This server takes registration requests from UA's, and maintains information as to their location.
Proxy Server: A SIP proxy recieves SIP messages (both requests and responses), that are gerneated by UA's, and forwards them on (either to the destination UA, or the next SIP Server in the route, as specified in the SIP message itself). A proxy does not need to be aware of SIP message body content, as it only operates on SIP headers.
Redirect Server: This conceptual entity recieves requests from a proxy or UA, and responds with a specific SIP response method, telling the originator of the request that the user is not available at that location, and indicates where the request should be sent in order to try again.
Other SIP network entities
Back-to-back User Agent - A B2BUA is a SIP device that recieves a SIP request, reformulates it, and then sends it out as a new request. Responses to the new request are also reformulated and sent back out in the opposite direction. In simple terms, think of it as two IP phones that have some controlling logic about what the other one is doing.. if one rings, it lets the other know, and that phone then makes an outgoing call based on whatever logic has been set.
Some B2BUA's also have built-in media servers so they can perform useful tasks such as transcoding, security, conferencing etc.
RTP Proxy - This merely accepts RTP from a location, and then relays it to another location. packets sent in response are relayed in the opposite direction.
-------------------------------------------------------------
Network Address Translation (NAT) and SIP
There are several 'points of impact' where SIP finds NAT problematic, and it is not merely limited to NAT. RTP also has problems with NAT. Because SIP packets go out from a NATed client with their private (and un-routable) IP addresses coded into the message headers and SDP bodies, they are not processed by a NAT device, that operates only on the IP packets as they pass by. This then means that when the packets get to their destination, they are processed and responded to using completley useless source address information.
The 3 major problems of NAT in SIP
The VIA header problem: Responses to requests cannot he be routed back ot the originating party, as the supplied addressing information is not globally routable.
The CONTACT header problem: This refers to the fact that future requests would be routed incorrectly, again due to non-routable addresses being supplied.
The RTP problem: The final problem in the NAT/SIP category is to do with RTP (by that i mean the actual voice part of the session). The SDP messages which are used to negotiate the session format (codecs, ports, IP's etc), which are often enclosed within the SIP message body, and thus not processed by a SIP proxy according to IETF standards, will contain non-routable contact information as well (i.e. your internal address e.g. 192.168.x.x). This is a tough problem to solve.
There are several solutions to choose from to allow SIP to traverse NAT effectively. None of them is ideal, and much of it is external to SIP. The following sections refers to the
three main problems caused by SIP (listed above), and discusses the techniques applied within the protocol, and common third party solutions, to the problems.
Solutions to those 3 major problems
The Via header answer
This is solved within SIP. When a message arrives at a SIP server or UA, a comparison is made between the address the packet came from, and the one that is listed in the via header. If there is a difference, then the correct IP address (the one from which the packet originated from) is written as a parameter 'recieved=', and is added to the via header.
The contact header answer
This is a similar problem to the Via header issue, and is solved in the same way, updating the contact header instead. The contact header is referred to for communications that occur some time after an original request (such as BYE's or re-INVITE's), and this can cause additional problems, for the following reason:
NAT bindings are kept active on the NAT device for only a finite amount of time if SIP is being transported over UDP.
Solutions to this include using TCP for SIP instead of UDP (which is a connection-oriented protocol and so bindings and associated timeouts arent a problem), employing some kind of keep_alive program to maintain NAT bindings, or using STUN/TURN servers, or even a B2BUA.
The RTP answer
For instances where only one UA is behind a NAT device, symmetric NAT can be used. This effectively synchronises the two RTP streams; the recipeint of the successful RTP stream
(i.e. the globally routable UA in the session) transmits its RTP stream using the source IP of that RTP flow, ignoring the one that SDP has told it to use.
For instances where both users are behind NAT, you can employ a RTP proxy/media server/B2BUA of some kind to relay voice, breaking the call into two separate legs or you can use the TURN protocol (which essentailly does the same thing).
| Forum Rules and Guidelines | About VoIP User | Privacy Policy |
All logos and trademarks in this site are property of their respective owner. Comments and posts are property of the poster, all the rest (c) 2003-2006 VoIP User. No part of this site may be reproduced without our prior consent. |
