Keywords: SIP, VoIP, NAT, firewall, communication, STUN, TURN

1 INTRODUCTION TO SIP

The Session Initiation Protocol (SIP) is an IP based application protocol that has been developed by IETF [1] as a signaling protocol for multimedia communications established over IP network. SIP provides signaling and control functionality for a large range of multimedia communications. The main functions are: location of parties, invitation to service sessions, and negotiation of session parameters as other signaling protocols. To accomplish this, SIP uses a small number of text-based signaling messages, which are exchanged between the SIP entities.

SIP define some functional entities, which all have their specific task and allows to establish SIP based communication infrastructure, which provides to their users personal, terminal and service mobility.
User agent: The UA represents the main end system, which initiate sessions between two or more UAs. UA consist from a requester of a session, the User Agent Client (UAC) and responder of a session, the User Agent Server (UAS).
Registrar: A registrar receives registration requests sent by the UAC. These requests include the temporary SIP address, the permanent SIP address (SIP Uniform Resource Identifier (URI)) of the UAC and the IP address of the UA. The Registrar keeps this location information so UA can be reached under its permanent SIP-URI.
Proxy: A proxy server receives messages for other entities (UA), processes and then forwards them to an appropriate location. It is located on the way between two user agents. Its main task is message routing.
Redirect server: The main task of a redirect server is to provide to the initiator of the call a list of alternative contact SIP addresses, where the call should be redirected. But the redirect server does not forward messages.
Back-to-back User Agent: A B2BUA is a SIP device that receives 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.

SIP is protocol, where the clients (UAC) send requests which are answered by a response generated by the servers (UAS). The session between UAs consists from the sets of text coded messages. A SIP message consists of the start line, the header, a blank line and the body. The header consists from more header fields, where each header field contain name of the header field, value of the field, names of parameters and its values. The body can be leaved blank, or it may contain session description defined by Session Description Protocol (SDP), or it can contain some other content (image, text, Quality of Service (QoS) parameters [2], etc.). There are two types of SIP messages: Requests (or Methods) and Responses. Requests are generated by clients and its receiving usually starts some processing on the server side. A result is send back using kind of Response message.

Network Address Translation (NAT) is the technique of modifying network address information (Layer 3) and port information (Layer 4) in packet headers (L3 PDU) while it is traversing a traffic routing device (NAT) for the purpose of remapping a given source addresses into another address space. The most typical implementation of the NAT is used to connect stub networks and their IP hosts which are using private IP network ranges (inside) and allow them to access and interact with publicly routed IP networks and its hosts (outside). Dynamic NAT techniques usually allows traffic traverse from inside to outside, back only if the connection was initiated from inside. NAT was developed as a technique which helps to solve public IP address crises. But NAT obscures an internal network’s structure (all traffic appears to outside parties as it originates from the one host or smaller number of hosts as it is in reality) also so it is usually used as the first and simplest method of securing IP network.

There are 4 types of NAT [3]:
Full cone: The simplest implementation. Once an internal address and port (iAddr:port1) is mapped to an external address (eAddr:port2), any packets from iAddr:port1 will be sent through eAddr:port2. Any external host can send packets to iAddr:port1 by sending packets to eAddr:port2.
Address-Restricted cone: as above, but the NAT device is maintaining a list of allowed connections from originating devices inside. So if external device wants sent packet to inside host, connection must be initiated from inside host first.

Port-Restricted cone: As Address-Restricted described above, to the address is applied port restrictions. Symmetric NAT: Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port. If the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back.

 

3 UNDERSTANDING PROBLEMS WITH SIP MULTIMEDIA AND NAT

SIP is a protocol that was designed to work hand in hand with other core Internet protocols and many functions in a SIP-based network rely upon complementary protocols, including IP. Since SIP itself only defines the initiation of a session, all other parts of the session are covered by other protocols. The SIP session is described in two levels. The SIP itself contains the parties’ addresses (caller and callee SIP URIs) and protocol processing features, but the description of the media streams exchanged between the parties of a session is defined by another protocol. The SDP [4] is used for this. The SDP is not a protocol in its sense, but rather a structured, text-based media description format that can be carried in the SIP message body. SDP is used to handle the session negotiation process within a SIP transaction. An SDP message is often carried as the message body of a SIP request. For the media transport itself is used another protocol – the RealTime Transport Protocol (RTP) [6].
There have been developed some guidelines from IETF for application protocol design to make them more NAT friendly [5], but the document was published sooner as was SIP and SDP specified. Unfortunately, SIP violates most of these guidelines, e.g. one of the major recommendations is that the application layer protocols should not transport IP addresses and port numbers inside of their messages. This makes SIP great complications when NAT (or firewall) are introduced. Look at the following example. The session starts by generating SIP INVITE [Fig.1.] request by a Caller, from behind a NAT. The SDP offer is carried inside, detailing a number of characteristics that define the proposed session (such as media and codec types (or media capabilities of the caller), contact information, IP address and ports to be used). The parameters are used for media delivery between parties with help of the RTP over UDP. There is a private address carried inside of Via header field, inside Contact header field and inside of the SDP message too [Fig.1].

Transition of the SIP message through the NAT cause translation of L3 private IP address inside packet header, potentially also L4 port number, but IP addresses inside the SIP header fields and SDP will stay untouched. The session will not be established because:

• The response to this request (200OK) from the Callee could not be routed back (based on an incorrect Via header) to the Caller because of the inability to route this private IP address (private range defined for use on private internal networks).
• Future requests of this session, as Re-INVITE and BYE, would be misrouted, caused by incorrect Contact header field with private IP address.
• RTP packets sent by Callee would be misrouted and media exchange will not start because connection IP address used for RTP media inside of SDP field c= is private.

There are several approaches possibly used for NAT traversal to solve situations mentioned above [7]:

• Modification of SIP signaling, without changing anything in existing firewalls and NATs.
• Modifications to firewalls and NATs so as to make them SIP-aware NAT.
• Firewall traversal using Simple Traversal of UDP through NAT (STUN), and Traversal Using Relay around NAT (TURN).

The answer to the problem of misrouting of SIP messages based on Via header containing private IP address has potentially simple solution inside of SIP. A proxy server or UA receiving this request would compare the IP address in the Via header to the source IP address from which the packet was received. If they are different (they would be if there is a NAT), the correct public IP address is added to the Via header with a received= parameter. This public IP address would be used to route the SIP response successfully back to the NAT, the NAT maintains the same binding between the private IP address and public IP address and forward the message to the Caller.
Problem with misrouting of future messages which comes from outside, for example when session is closing with BYE, could be solved by a persistent TCP connection, which is permanently open during whole session. This does not work with UDP, where NAT will filter UDP segments coming from outside direction because no translation was found.
Solution to the problem with RTP media session is not easy. One functional solution is to use the technique known as Symmetrical RTP [8], where RTP packets using the same UDP port for transmitting and receiving. This is because RTP and RTCP are not inherently bidirectional protocols, and UDP is not a bidirectional protocol. This solution should work in situations, where one endpoint is behind NAT (not both), so the SDP of the endpoint outside of NAT contains a correct public, routable IP address and port number and flow in at least one direction is possible. The use of symmetric RTP would make the recipient of the successful RTP stream outside to use the received IP address and port number to send RTP back, ignoring the private IP address in the SDP (which is not routable).

STUN is the IETF standardized solution [9], which helps to solve the NAT traversal problem. As the name suggests, STUN is a simple protocol that allows a UA to discover if it is behind a NAT, what type of NAT it is and what its public IP address and port is. STUN is using a special entity called STUN server, which is placed on the public Internet. The UA, which is behind NAT have to supports STUN protocol and must be configured with or discover somehow a STUN public IP address (for example using SRV DNS records). The UA than initiate to open secured connection to the STUN server (using Shared secret key and TLS) and starts to send STUN packets directed to a STUN server. The STUN server response the UA and tell it the public IP address and port that the STUN server received from the STUN requests. If the sent and received addresses and ports are the same, there is no NAT. If they are different IP addresses, there is a NAT between them. So if there is a situation where a UA behind a NAT is trying to talk to another UA that has a public IP address, through STUN a UA knows that have to modify all the parts of a SIP and SDP message with the correct public IP address (Via, Contact and SDP c header fields).
STUN does not work if there is a Symmetric NAT, because as was mentioned, this kind of NAT each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port, so there is different mapping for communications between the UA and the STUN server and another between the UAs themselves. STUN does not work also if both ends of the SIP and media session are behind NATs. For this, TURN may be used.

The TURN protocol is not published as the IETF RFC standard yet, but is semifinished as the IETF draft [10]. TURN is a protocol that allows a UA which is behind NAT directly communicate with other peers located behind other NATs [10]. For this purpose TURN is also using a special entity, TURN server, which is placed on the public Internet and which is inserted into the signaling and media path and acts as a communication relay. TURN protocol allows the UA to control the operation of the relay and to exchange packets with its peers using the relay. The TURN supported UA, which is behind NAT must be configured through some means with the TURN server public IP address. To this address will UA sends TURN command messages used to allocate the public relayed transport IP address and port on the TURN server (the relay). If the UA wants send data to its peer, it will send it to the server on the obtained relay transport address and TURN server (the relay), which know from who is the data coming (from the allocation process), will unambiguously relay it towards UAs peers. In the reverse direction, peers can send data to the relayed transport address of the UA. The server will relay this data to the UA as long as the client explicitly created permission for the IP address of the peer.

5 CONCLUSION

Today’s IP network administrators have many possibilities how to extend theirs pure IP data networks with new IP-based voice and multimedia capabilities and services. Unfortunately, there are some technical problems which complicate multimedia implementations and prevent to realize these multimedia networking benefits. One of the most significant of these is NAT techniques used to provide secure connection to users behind NAT and firewalls. The NAT and firewalls breaks the SIP signaling and complicates media delivery. To solve this situation there are the IETF solutions STUN and TURN.

[1] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., JOHNSTON, A., PETERSON, J., SPARKS, R., HANDLEY, M., SCHOOLER, E.: SIP: Session Initiation Protocol, RFC 3261, July 2002
[2] KLIMO. M, BACHRATÁ, K.:Impact of correlated samples loss on VoIP quality [Vplyv korelovaných strát na kvalitu VoIP], In: Scientific Papers of the University of Pardubice : Series B – The Jan Perner Transport Faculta 11 (2005). – Pardubice: University of Pardubice, 2006. – ISBN 80-7194-605-2
[3] http://en.wikipedia.org/wiki/Network_Address_Translation
[4] HANDLEY, J.: SDP: Session Description Protocol, RFC 2327, April 1998
[5] SENIE, D., Network Address Translator (NAT)-Friendly Application Design Guidelines, RFC3235, January 2002
[6] SCHULZRINNE, H., CASNER, S., FREDERICK, R., JACOBSON, V.: RTP – A Transport Protocol for Real Time Applications, RFC3550, July 2003
[7] SINNREICH, H., JOHNSTON, A.: Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Second edition, Wiley Publishing Inc., ISBN: 978-0-471-77657-4
[8] WING, D.: Symmetric RTP / RTP Control Protocol (RTCP), RFC4961, July 2007
[9] ROSENBERG, J., WEINBERGER, J., HUITEMA, C..: STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), RFC 3489, March 2003
[10] ROSENBERG, J., MAHY, R., MATTHEWS, P.: "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-09 (work in progress), July 2008.