Through the Gate

Along with Skype, the Session Initiation Protocol (SIP) is one of the most popular techniques for setting up Voice over IP connections. Thanks to an open standard (IETF RFC 3261 [1]), it is also easy to develop your own applications for SIP. However, if you use the SIP protocol for Voice over IP calls, you will discover some complications reaching an address on a private network that resides behind a NAT firewall. The data part of a SIP packet includes address and port information that the gateway does not understand. VoIP experts have developed several workarounds, including the STUN (Simple Traversal of UDP through NAT) protocol, but as you will learn in this article, STUN and some of the alternatives each have limitations that you should be aware of when you are planning your VoIP network.

SIP 101

SIP is only responsible for signaling – for example, setting up and breaking down a call. The voice data is transported by another open protocol, the Real-time Transfer Protocol (RTP), which is described in RFC 3550 [2].

Listing 1 shows the SIP Invite request used as an example in the SIP RFC; the request initiates a VoIP call comprising two parts: The first part of the message contains the SIP headers; the second – separated by an empty line – contains the Session Description Protocol (SDP) [3] as the SIP payload. The SDP part describes the audio stream; that is, it contains data such as the codec, the open port (in the m header), and the IP address or name of the hosts.

01 INVITE sip:bob@biloxi.com SIP/2.0
02 Via: SIP/2.0/UDP pc33.atlanta.com:5060; branch=z9hG4bKnashds8
03 Max-Forwards: 70
04 To: Bob <sip:bob@biloxi.com>
05 From: Alice <sip:alice@atlanta.com>;tag=1928301774
06 Call-ID: a84b4c76e66710
07 CSeq: 314159 INVITE
08 Contact: <sip:alice@pc33.atlanta.com:5060>
09 Content-Type: application/sdp
10 Content-Length: 142
11
12 v=0
13 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com
14 s=-
15 t=0 0
16 c=IN IP4 pc33.atlanta.com
17 m=audio 3456 RTP/AVP 0 1 3 99
18 a=rtpmap:0 PCMU/8000

The first line in the SIP message defines the request and the URI (Uniform Resource Identifier, similar to a mail address) to contact. The Via header stores the individual hops the packets take en route from Alice to Bob (Figure 1). Additional Via headers are created for each hop, making it possible to route the response back by the same path.

The To header contains the URI for the person to contact, whereas the From line has the sender's public URI. Call-ID and Cseq are unique identifiers for the current dialog. Contact contains the address at which the terminal device (User Agent, UA) is currently listening for SIP requests. If the user registers the URI alice@atlanta.com multiple times on different user agents, the Contact header contains the data for the user agent that sent the request – this is pc33.atlanta.com in this example. Content-Type and Content-Length define the type and length of the payload. Figure 1 shows two VoIP clients initiating a call via SIP: The messages are transmitted over multiple hops, and multiple messages are required.

Alice Calling Bob

The client with the URI alice@atlanta.com wants to call bob@biloxi.com. It supports several media codecs (you can tell this by the SDP header m=audio 3456 RTP/AVP 0 1 3 99) and has an open socket for media, pc33.atlanta.com:3456. Because Alice does not know on which host Bob has registered, she can either contact Bob's proxy first (see Figure 1, step 1), or she can send the SIP request to her own proxy.

Bob's proxy uses its location database to determine Bob's location and forwards the request to this location (step 3). An alternative, but nontypical, method would be for Alice to contact Bob directly without using proxies. However, this is only possible if Alice knows the current location information for Bob's client.

After Alice has sent the request to the proxy, she receives a response of 100 Trying (2), telling her the next hop has received the request. If the Trying message fails to arrive, Alice tries again – whether she used UDP or TCP to send the message. Once Bob receives the request, he sends a status of 180 Ringing (4), and his user agent outputs a signal. The Ringing response follows the hops collected in the Via headers from Bob back to Alice. When Bob accepts the call, he sends a 200 OK (6). In contrast to the previous responses, this OK will contain a Contact header and an SDP payload that informs Alice of the supported codecs and the open socket for media.

Once the OK (7) has reached Alice, she will send an ACK message (8) directly to the URI sent by Bob in the Contact header. The ACK tells Bob that Alice has successfully received his OK. Following this three-way handshake, Alice now has Bob's media socket, and Bob has Alice's (thanks to the Invite request), and the media transmission can now begin. If Bob terminates the call, he sends a Bye request (9) to the URI in Alice's Contact header, again leaving out the intermediary stations.

NAT Problems

If one of the users is on a private subnet behind a NAT gateway, the Invite request will include multiple private IP addresses (Listing 2), which are inaccessible from the other end. The gateway that translates the Layer 3 (IP) addresses or Layer 3 and 4 addresses (TCP/UDP, NAPT: Network Address Port Translation) is incapable of identifying and correctly modifying the IP addresses in the higher layers.

01 INVITE sip:bob@biloxi.com SIP/2.0
02 Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bKnashds8
03 Max-Forwards: 70
04 To: Bob <sip:bob@biloxi.com>
05 From: Alice <sip:alice@atlanta.com>;tag=1928301774
06 Call-ID: a84b4c76e66710
07 CSeq: 314159 INVITE
08 Contact: <sip:alice@192.168.1.10:5060>
09 Content-Type: application/sdp
10 Content-Length: 142
11
12 v=0
13 o=alice 53655765 2353687637 IN IP4192.168.1.10
14 s=-
15 t=0 0
16 c=IN IP4 192.168.1.10
17 m=audio 5678 RTP/AVP 0 1 3 99
18 a=rtpmap:0 PCMU/8000

The most widespread NAPT technology, symmetric NAPT, dynamically maps the internal source IP address and port to the public target IP address and target port. This assignment remains valid for a certain period, but it is deleted if there is no traffic for a while. Within the period, NAPT will correctly forward responses from the public address to the address in NAPT. However, because the SIP client does not reply to the source address, but to the address specified in the Via header, these messages often end up in a digital black hole. The approaches to solving this problem are several.

STUN

The legacy STUN protocol [4] makes it possible to identify the public IP address and port number. The STUN client, which typically is integrated with the telephony application, sends a binding discovery packet to a STUN server, which responds with a binding response packet whose MAPPED-ADDRESS protocol attribute contains the address the NAT gateway uses for external traffic. The application now inserts the publicly visible IP address into the SIP packet to replace the private addresses.

This technique works fairly well, but not with a symmetric NAPT gateway: The gateway will only accept packets that originate directly with the STUN server on the public IP socket identified by STUN. When the SIP message is sent to the SIP proxy on the gateway, a different mapping occurs, and it does not match the data contained in the SIP message.

Symmetric Response

To save users the trouble of configuring a STUN server and then discovering that it doesn't work, SIP providers have extended their proxies to support what is known as Symmetric Response Routing. The IP address and port from the Via header of an incoming Invite request are compared with the source IP and port. If they do not match, the proxy adds the Received parameter to the Via header and then rewrites the Contact header to contain the publicly reachable NAT gateway socket.

Listing 3 shows an Invite request that has been modified by the SIP proxy: 18.17.16.15 is the gateway's public address; 20.22.24.26 and 20.22.24.27 are the addresses of the SIP and media proxies. Because NAT mapping for this socket only applies to the provider-side proxy, all future requests in the SIP dialog need to be routed via this proxy. To allow this to happen, the proxy adds a Record-Route header with its own IP address.

01 INVITE sip:bob@biloxi.com SIP/2.0
02 Via: SIP/2.0/UDP 20.22.24.26:5060;
03 Via: SIP/2.0/UDP 192.168.1.10:5060;
04 received=18.17.16.15:25588;branch=z9hG4bKnashds8
05 Record-Route: <sip:20.22.24.26;lr>
06 Max-Forwards: 70
07 To: Bob <sip:bob@biloxi.com>
08 From: Alice <sip:alice@atlanta.com>;tag=1928301774
09 Call-ID: a84b4c76e66710
10 CSeq: 314159 INVITE
11 Contact: <sip:alice@18.17.16.15:25588>
12 Content-Type: application/sdp
13 Content-Length: 142
14
15 v=0
16 o=alice 53655765 2353687637 IN IP4
20.22.24.27
17 s=-
18 t=0 0
19 c=IN IP4 20.22.24.27
20 m=audio 20333 RTP/AVP 0 1 3 99
21 a=rtpmap:0 PCMvU/8000

The RTP port causes the next issue; although it is listed in the SDP part, there is no NAT mapping for it. Providers work around this by using a public media proxy: they replace the IP addresses and ports in the SDP header with the address and port of their own media proxy – both in the Invite request and the SDP part of the following OK response.

To keep NAT mapping permanently, clients reduce the re-register time to a very short period of one or two minutes. This means they continually send registration requests and thus renew their entries in the NAT table.

However, this will only work if the first hop in the SIP request is your own provider's SIP proxy. This technique routes both the signalization and media data via the provider.

Application Layer Gateway

If the provider does not support header rewriting (as described above), many ADSL modems and WLAN routers have internal SIP-NAT helper modules. Because only the NAT gateway can actually know which internal socket is communicating with which external socket, only the gateway is capable of modifying the addresses at the application level.

The Application Layer Gateway identifies SIP messages and replaces the addresses and ports in the SDP and SIP headers with the mapping table. This solution works fairly reliably, although problems can occur with multiple-level NAT.

The WLAN router translates the addresses in communications with the ADSL modem, which also uses NAT. This often leads to issues that are difficult to solve.

Local SIP Registrar

Another promising approach uses a local SIP registrar. In fact, this is what the current FRITZ!Box does. The local user agent client (UAC) doesn't communicate directly with the provider. Instead, the SIP registrar implemented on the NAT gateway acts as a "back-to-back user agent" – a user agent that plays the client role in one direction and the role of a user agent server (UAS) in the other ([1], see section 6).

This application is, at the same time, a media proxy, thus providing scope for more developments. For example, it might be possible to recode the RTP packets or use SRTP (Secure Real-time Transport Protocol) for secure encryption in the Internet-bound direction. The same results are also possible with a local Asterisk installation [5].

More Approaches

The TURN protocol (Traversal Using Relays around NAT) [6], which is published as an IETF draft, is an extension of the STUN approach. It extends STUN by not just taking SIP signaling into consideration, but also introducing a solution for the RTP media. A STUN server additionally handles the tasks of an RTP relay. This relay technology is hard on resources and can cause jitter if you have the wrong hardware, thus affecting the perceived call quality.

VPNs offer a complete solution to the problems caused by NAT gateways: The free implementation OpenVPN not only sets up a virtual channel to a server, it also uses TLS to encrypt the data. Thanks to the tunnel, the client has an address in the VPN IP address range that it can then use for SIP signaling. However, a VPN tunnel requires a pre-arranged connection between the calling and receiving networks, which isn't always possible in Internet telephony scenarios.

Solution Possible

Running SIP behind a NAT is difficult, but many potential solutions are available. If you're shopping for an IP telephony system, it is important to consider which technique will work best for your network.