ICE [19] is used to select the appropriate source/destination transport addresses for RTP packet delivery. The candidates of the transport addresses for RTP include the UA’s lo-cal transport addresses and the mapped transport addresses obtained using the solutions described in the previous sections (e.g., the STUN solution). These candidates are ex-changed during call setup by being filled in the a=candidate fields in the SDP description.
In addition, the SIP NAT traversing issue is out of the scope of the ICE solution. Any solution can be adopted to cooperate with ICE, such as the usage of the rport parame-ter [22] described in Section 2.6. In ICE, both the UAs engaged in the RTP media session are required to support ICE so that the connectivity checks (which check the connectivity of the combination of a source and a destination transport addresses) can be performed.
The connectivity checks are for selecting the most suitable source/destination transport addresses for RTP packet delivery. The details of the ICE solution are elaborated in the following example as shown in Figures 2.8 and 2.9.
Assume that UA1 (in the private network) obtains an RTP mapping through STUN and attempts to establish a call to UA2 (in the Internet). The IP address settings for UA1, UA2, the NAT, and the STUN server are the same as those in Figures 2.1 and 2.5.
In this example, the symmetric NAT is adopted to show how ICE supports RTP NAT traversal over symmetric NAT while the mapped transport address for RTP is obtained through STUN (which does not support symmetric NAT traversal). The RTP mapping in the NAT’s mapping table, which is created when UA1 obtains the RTP mapping through STUN, is shown in entry 1 of the mapping table in Figure 2.8.
INVITE sip:ua2@140.113.10.10 Via: SIP/2.0/UDP 192.168.0.10:5060 Contact: <sip:ua1@192.168.0.10:5060>
c=IN IP4 140.113.10.1
m=audio 19000 RTP/AVP 0 8 3 4 18 a=candidate:1 ... 192.168.0.10 9000 ...
a=candidate:2 ... 140.113.10.1 19000 ...
Src: 140.113.10.1:10080 Dst: 140.113.10.10:5060
App. Layer (2)
Net. & Trans. Layer INVITE sip:ua2@140.113.10.10
Via: SIP/2.0/UDP 192.168.0.10:5060 Contact: <sip:ua1@192.168.0.10:5060>
c=IN IP4 140.113.10.1
m=audio 19000 RTP/AVP 0 8 3 4 18 a=candidate:1 ... 192.168.0.10 9000 ...
a=candidate:2 ... 140.113.10.1 19000 ...
Src: 192.168.0.10:5060
Net. & Trans. Layer
≈ a=candidate:1 ... 140.113.10.10 9002 ...
Src: 140.113.10.10:5060 Dst: 192.168.0.10:5060
App. Layer
Net. & Trans. Layer
(4) 200 OK a=candidate:1 ... 140.113.10.10 9002 ...
Src: 140.113.10.10:5060 Dst: 140.113.10.1:10080
App. Layer
Net. & Trans. Layer (3) Obtain An RTP Mapping through STUN
Figure 2.8: SIP/RTP NAT Traversing: Call Setup in the ICE Solution
Figure 2.8 illustrates the SIP message flow for call setup. The SIP NAT travers-ing issue is resolved by the usage of the rport parameter. The call setup procedure is similar to that in Section 2.6. During SIP message exchange, UA1 includes its private transport address 192.168.0.10:9000 and the corresponding mapped transport address 140.113.10.1:19000 in the a=candidate fields of the INVITE message (Figure 2.8 (1)).
Similarly, UA2 includes its transport address 140.113.10.10:9002 in the a=candidate field of the 200 OK message (Figure 2.8 (3)). After exchange, UA1 combines its private trans-port address 192.168.0.10:9000 with UA2’s transtrans-port address 140.113.10.10:9002 as a pair of the source/destination transport addresses. The pair is added to UA1’s check list (i.e., entry 1 of UA1’s check list in Figure 2.9). In addition, the pair with the source/destination transport addresses 140.113.0.1:19000/140.113.10.10:9002 is added to UA1’s check list (i.e., entry 2 of UA1’s check list in Figure 2.9). Since 140.113.10.1:19000 is the corre-sponding mapped transport address of 192.168.0.1:9000, the second entry is marked as associated to the first entry. That is, UA1 does not perform the connectivity check to the second entry because the transport address 140.113.10.1:19000 does not belong to UA1.
(The transport address 140.113.10.1:19000 belongs to the NAT.) UA2 performs similar procedure to construct its check list (see UA2’s check list in Figure 2.9) except that the second entry is not associated to the first entry.
Before sending the RTP packets to each other, UA1 and UA2 perform the connectivity checks to all the entries in their check lists, as illustrated in Figure 2.9. Suppose that UA1 checks the first entry in its check list. First, UA1 sends a STUN Binding Request message with the source transport address 192.168.0.10:9000 and the destination transport address 140.113.10.10:9002 (Figure 2.9 (1)). Upon receipt of the message, the NAT creates a new private-to-public transport address mapping (i.e., entry 3 of the NAT’s mappings table in Figure 2.9), translates the source transport address into 140.113.10.1:29000, and forwards the message to UA2 (Figure 2.9 (2)). Note that the source port number of the message received by UA2 (i.e., 29000) is different from UA1’s mapped port number specified in the INVITE message (i.e., 19000). Therefore, UA2 adds to its check list a new pair with the source/destination transport addresses 140.113.10.10:9002/140.113.10.1:29000 (i.e., entry
Binding Response MAPPED-ADDRESS IP 140.113.10.1 Port 29000
Src: 140.113.10.10:9002; Dst: 192.168.0.10:9000 App. Layer
(4)
Net. & Trans. Layer
Binding Response MAPPED-ADDRESS IP 140.113.10.1 Port 29000
Src: 140.113.10.10:9002; Dst: 140.113.10.1:29000 App. Layer
(3)
Net. & Trans. Layer Binding Request
Src: 140.113.10.1:29000; Dst: 140.113.10.10:9002 App. Layer
(2)
Net. & Trans. Layer Binding Request
Src: 192.168.0.10:9000; Dst: 140.113.10.10:9002 App. Layer
(1)
Net. & Trans. Layer
Binding Response MAPPED-ADDRESS IP 140.113.10.10 Port 9002
Src: 192.168.0.10:9000; Dst: 140.113.10.10:9002 App. Layer
(9)
Net. & Trans. Layer
Binding Response MAPPED-ADDRESS IP 140.113.10.10 Port 9002
Src: 140.113.10.1:29000; Dst: 140.113.10.10:9002 App. Layer
(10)
Net. & Trans. Layer Binding Request
Src: 140.113.10.10:9002; Dst: 140.113.10.1:29000 App. Layer
(7)
Net. & Trans. Layer Binding Request
Src: 140.113.10.10:9002; Dst: 192.168.0.10:9000 App. Layer
(8)
Net. & Trans. Layer
Binding Request
Src: 140.113.10.10:9002; Dst: 140.113.10.1:19000 App. Layer
(6)
Net. & Trans. Layer Binding Request
Src: 140.113.10.10:9002; Dst: 192.168.0.10:9000 App. Layer
(5)
Net. & Trans. Layer UA1
Figure 2.9: SIP/RTP NAT Traversing: Connectivity Checks in the ICE Solution
3 of UA2’s check list in Figure 2.9). UA2 then replies a STUN Binding Response message to UA1 (Figure 2.9 (3)). When UA1 receives this message, the first entry in its check list is marked “valid” (Figure 2.9 (4)). Besides, UA1 learns from the message a new mapped transport address (i.e., 140.113.10.1:29000). UA1 then adds to its check list a new pair with the source/destination transport addresses 140.113.10.1:29000/140.113.10.10:9002 (i.e., entry 3 of UA1’s check list in Figure 2.9). Like the second entry, the new entry is marked as associated to the first entry, and no connectivity check is performed to it.
UA2 performs similar procedure to check all the entries in its check list. For the first entry, the destination transport address 192.168.0.10:9000 is unreachable from the Inter-net (Figure 2.9 (5)). For the second entry, there is no mapping in the NAT’s mapping table that satisfies the condition where the destination transport address is 140.113.10.10:9002 and the mapped transport address is 140.113.10.1:19000 (Figure 2.9 (6)). For the third entry, the STUN Binding Request message from UA2 is sent to UA1 according to entry 3 in the NAT’s mapping table in Figure 2.9 (Figure 2.9 (7) and (8)). After receiv-ing the STUN Bindreceiv-ing Response message from UA1 (Figure 2.9 (9) and (10)), UA2 marks the third entry “valid.” After the connectivity checks, both UA1 and UA2 se-lect the source/destination transport addresses for RTP from the entries that are marked
“valid.” In this example, UA1 selects 192.168.0.10:9000/140.113.10.10:9002, and UA2 selects 140.113.10.10:9002/140.113.10.1:29000. Therefore, the RTP packets delivered be-tween UA1 and UA2 are translated by the NAT according to entry 3 in the NAT’s mapping table in Figure 2.9.
Consider another example where UA1 and UA2 reside in the same private network.
Both UA1 and UA2 obtain the mapped transport addresses through STUN and exchange their private and mapped transport addresses during call setup. After the connectivity checks, they detect that they can send the RTP packets to each other directly using each other’s private transport address. This avoids the address translation performed at the NAT. Therefore, in this case, ICE provides more efficient RTP packet delivery than the other solutions.
Table 2.2: Comparisons of the SIP/RTP NAT Traversing Solutions
Solution UA Scope of NATs Multi-layer Extra Extra Public Configuration Modification Supported NAT Traversal Server IP Address Complexity
VPN Yes All Types of NATs Yes Yes Yes Medium
Static
Yes All Types of NATs Yes No No High
Route
UPnP Yes NATs Supporting UPnP No No No Low
STUN Yes All Types of NATs
Yes Yes No Medium
except Symmetric NAT
ICE Yes All Types of NATs Yes Yes No Low
SIP-ALG No NATs Supporting
Yes No No Low
SIP-ALG
SBC No All Types of NATs Yes Yes No Medium
2.8 Comparisons
This section compares the SIP/RTP NAT traversing solutions. The compared items are listed in Table 2.2 and described as follows.
UA Modification: For VPN, the UA is equipped with the VPN software to establish the VPN tunnel. For ICE, not only the UA in the private network but also the UA in the Internet are equipped with the ICE software. For SIP-ALG and SBC, the UA does not require any modification (except for outbound SIP proxy setting in SBC).
For Static Route, UPnP, and STUN, the standard UA is modified to perform two tasks. In the first task, the SIP and the RTP mappings at the NAT are obtained through manual setting, UPnP, or STUN. In the second task, the UA translates the transport address in the SIP messages. For example, this task can be achieved by the functions in eXtended osip (eXosip) library [3]:
• The eXosip set firewallip() uses the specific IP address in the Via header field, the Contact header field, and the c field in the generated SIP messages (i.e., in which the mapped IP address in Table 2.1 should be filled).
• The eXosip initiate call() fills the indicated port number in the m field in the generated SIP messages.
The problem of eXosip set firewallip() is that it does not specify the port number
in both the Via and the Contact header fields. Instead, the source port number of those IP packets carrying the generated SIP messages is used. To resolve this issue, we have added a function eXosip set firewallsipPort() that allows the UA to specify the port number filled in both the Via and the Contact header fields.
Scope of NATs Supported: VPN, Static Route, ICE, and SBC support SIP/RTP traversal over all types of NATs. The NATs need not be modified. In UPnP and SIP-ALG, an agent should be collocated with the NAT to serve as an IGD and a SIP-ALG, respectively. Although no modification is made to the NAT for STUN, STUN does not support SIP/RTP traversal over symmetric NAT.
Multi-layer NAT Traversal: When a UA resides in a private network within another private network (therefore there are multi-layer NATs), all solutions but UPnP support SIP/RTP NAT traversal. UPnP does not work because a UPnP client can only identify the NAT closest to it. It does not have any knowledge to pass through the other NATs.
Extra Server: VPN, STUN, ICE, and SBC require extra servers in the Internet. Static Route does not require any extra server. For UPnP, the NAT is modified as a UPnP server. SIP-ALG typically resides in the NAT.
Extra Public IP Address: In VPN, an extra public IP address is required for each VPN tunnel. Other solutions do not require any extra public IP address.
Configuration Complexity: Since the SIP and the RTP mappings are automatically established by UPnP, ICE, and SIP-ALG, these solutions do not incur any configu-ration cost. In VPN and STUN, a user configures the server location and the user name/password for authentication. In SBC, the UA sets the SBC as the outbound SIP proxy. On the other hand, a Static Route user should manually configure the SIP and the RTP mappings for SIP/RTP in both the UA and the NAT.
Furthermore, We conduct measurements in an experimental environment (as shown in Figure 2.10) where the UA in the private network (UA1) connects to the NAT through
NAT
VPN Server STUN Server
UA2
Packet Analyzer
Private Network Internet
UA1
SBC Hub
Hub
Figure 2.10: Experimental Environment for SIP/RTP NAT Traversing Solutions
a hub. The other UA (UA2), the VPN server, the STUN server, and the SBC reside in the Internet and connect to the NAT through another hub. To provide the same baseline for the following performance comparisons, a UA that supports all the SIP/RTP NAT traversing solutions discussed in this chapter is required. Therefore, we design and develop a UA using eXosip library [3] to which some modifications are made as described above.
Table 2.3 shows the time complexities of the solutions discussed in this chapter ex-cept ICE. Since ICE utilizes the solutions described in this chapter for resolving SIP NAT traversing issue and for obtaining the RTP mappings, the costs for private-to-public transport address mapping establishment, the call setup latency, and the RTP latency are the same as those of the solution utilized in ICE. Moreover, the connectivity checks increase the call setup latency for ICE.
The table indicates that UPnP has the longest private-to-public transport address mapping establishment time, and VPN requires long VPN connection establishment time.
In terms of SIP setup and RTP delivery, Static Route, UPnP, and STUN are better than the server-based solutions, which are in turn better than VPN.
Table 2.3: Time Complexities of the SIP/RTP NAT Traversing Solutions
Solution Private-to-public Transport VPN Connection Call RTP Address Mapping Establishment Establishment Setup Latency
VPN N/A 2114 ms 161 ms 8.3 ms
Static Route Manual Setup N/A 71 ms 0.7 ms
UPnP 261 ms N/A 71 ms 0.7 ms
STUN 27 ms N/A 71 ms 0.7 ms
SIP-ALG N/A N/A 96 ms 0.7 ms
SBC N/A N/A 96 ms 4.3 ms
2.9 Summary
In this chapter, five UA-based (VPN, Static Route, UPnP, STUN, and ICE) and two server-based (SIP-ALG and SBC) SIP/RTP NAT traversing solutions are investigated.
Our study indicates that VPN’s time complexity is much higher than those of the other solutions. Static Route requires manual setting, which is considered inefficient. UPnP automates Static Route. However, UPnP requires NAT modification and cannot traverse over multi-layer NATs. STUN also automates Static Route while it requires an extra server and cannot traverse symmetric NAT. ICE supports symmetric NAT traversal and automates the selection of the source/destination transport addresses for RTP through connectivity checks. Nevertheless, ICE requires both the UAs engaged in the RTP media session to support ICE, and the connectivity checks introduce extra call setup latency.
Both SIP-ALG and SBC automate translation of SIP messages without any modification to UAs. The NAT needs to be modified to accommodate the SIP-ALG, and an extra server is required for SBC. The call setup time and the RTP latency for the server-based solutions are longer than those for the UA-based solutions (except for VPN). In summary, there is no SIP/RTP NAT traversing solution that is better than the others in all aspects.