Effective Mechanisms for SIP/IMS Applications Traverse over NAT

Transcription

1 Effective Mechanisms for SIP/IMS Applications Traverse over NAT Dr. Whai-En Chen ( 陳懷恩博士 ) 國立宜蘭大學資訊工程系 wechen@niu.edu.tw TEL:

2 Introduction To support voice communications in 4G LTE (Long Term Evolution), the operators start to deploy the VoLTE (Voice over LTE) solution. With the rapidly growth of the VoLTE (i.e., SIP/IMS) devices, the IP address shortage problem is more and more important. Since IPv6 (IP version 6) is not widely deployed yet, NAT (Network Address Translation) is a practical solution in current stage of the IPv6 deployment [1][2]. However, NAT blocks the incoming requests from Internet (i.e., the public IP network), and do not translate the applicationlayer IP/port. These issues are referred to as the NAT-T (NAT traversal) problem of SIP/IMS services. 2

3 The NAT-T Problem In the SIP/IMS applications, a User Equipment (UE) creates, modifies, and terminates multimedia sessions by using SIP. A SIP message contains the location (i.e., IP/port) information in the SIP header and body (i.e., in Application Layer). When the SIP message passes through a NAT device, the NAT device only translates the IP/port in the IP/UDP header (i.e., Network and Transport Layers) but leaves the IP/port in Application layer unchanged. If the IP/port parameters in the SIP body (SDP c/m foelds) are incorrect, the media session cannot be established correctly. We utilize a call setup flow to illustrate the NAT traversal problem for SIP-based services. 3

4 The NAT-T Problem When the SIP message passes through a NAT device, the NAT device only translates the IP/port in the IP/UDP header (i.e., Network and Transport Layers) but leaves the IP/port in the Application Layer header unchanged. If the IP/port in the SIP body (i.e., SDP c and m fields) is incorrect, the media session cannot be established correctly. UE1 NAT IMS Peer SIP Call Setup 1.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1 SIP ;rport Request-URI:Peer@IMS c:ip UE1 SDP m:p RTP1 Src:IP UE1 / P SIP1 IP/UDP Dst:IP IMS / P IMS OK 2.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1 ;rport Request-URI:Peer@IMS c:ip UE1 m:p RTP1 Src:IP NAT / P' SIP1 Dst:IP IMS / P IMS OK 3.INVITE Via:IP IMS /P IMS ; branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ; branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:Peer@IMS c:ip UE1 m:p RTP1 Src:IP IMS / P IMS Dst:IP Peer / P Peer OK 5.ACK 5.ACK 5.ACK 6.RTP 4 Private IP UE1 / P SIP1 Public IP NAT / PʹSIP1 Src:IP Peer / P PRTP Dst:IP UE1 / P RTP1

5 Message Flows (1/3) 5 Step 1. UE1 issues an INVITE message to Peer. The INVITE message contains the IP/port pairs IP UE1 /P SIP1, IP UE1 /P RTP1 and IP UE1 /P SIP1 in SIP, SDP and IP/UDP headers, respectively. The Via fields in the SIP header indicate the transmission path of a transaction. Each Via field contains a branch parameter to identify the transaction. The Request-URI field in the SIP header identifies the application-layer contact address (e.g., Peer@IMS). The c and m fields in the message body (i.e., SDP) contain the IP address and port used to establish the upcoming media sessions. The INVITE message is first sent to the IMS because UE1 does not have the contact information (IP/port) of Peer. Since the IMS and UE1 reside in the different networks, the INVITE message is routed to the default gateway (i.e., the NAT device).

6 6 國立宜蘭大學 Message Flows (2/3) Step 2. The NAT device translates the source IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1, and then the NAT device forwards the translated message to the IMS based on the destination IP/port. Note that in this INVITE message, the IP/port in the SDP c and m fields are not translated. Step 3. When the IMS receives the INVITE message, it checks the IP/port in both IP/UDP header and SIP header. Since the IP/port values in the IP/UDP header and SIP header are different, the IMS inserts a new Via field with the received and rport parameters (received=ip NAT and rport=p SIP1 ) into the INVITE message. The INVITE message is then forwarded to Peer based on the Request-URI. Note that UE1 utilizes the rport parameter to request the IMS records the received IP address and port in the Via field.

7 Message Flows (3/3) Steps 4-5. When Peer accepts the call, it replies a 200 OK message to UE1 through the IMS. Upon receipt of the 200 OK message, the IMS forwards the 200 OK message to UE1 according to the received and rport parameters in the Via field. When UE1 receives the 200 OK message, it replies an ACK message to complete the INVITE transaction. Since the IP/port in the SDP c and m fields of the INVITE message are not translated. Step 6. Peer obtains the private IP/port IP UE1 /P RTP1 that cannot be routed in Internet. On the other hand, UE1 obtains the public IP/port of Peer (i.e., IP Peer /P PRTP ). Therefore, UE1 cannot receive the media session sent from Peer but Peer can receive the media session sent from UE1. 7

8 The NAT-T Solutions To solve the NAT-T problems, the following famous solutions have been proposed in [7-11]. Universal Plug-and-Play (UPnP) Session Traversal Utilities for NAT (STUN) Traversal Using Relays around NAT (TURN) Session Initiation Protocol-Application Layer Gateway (SIP-ALG) Interactive Connectivity Establishment (ICE) Create and Obtain IP/port mappings Select IP/port mappings The UPnP, STUN, TRUN and SIP-ALG solutions are used to create and obtain the IP/port mappings in the NAT, and the ICE solution is used to select a suitable IP/port mapping. 8

9 The UPnP Solution UE1(UPnP Client) NAT(IGD) IMS Peer Note: UE is equipped with the UPnP Client. NAT acts as an Internet Gateway Device (IGD). 1.M-SEARCH * HTTP/1.1 Ssdp:discover InternetGatewayDevice Dst: : HTTP/ OK Location:IP PrivateNAT 3.POST HTTP/1.1 GetExternalIP Address 4.HTTP/ OK IP NAT 5.POST HTTP/1.1 NewPortMappingDescription (IP UE /P SIP )PʹRTP1 6.HTTP/ OK Request the NAT s Private IP address (Multicast) Request the NAT s Public IP address (Unicast) Create a IP/port mapping on NAT (Unicast) 7.SIP Call Setup 8.RTP 8.RTP 9 UPnP is a network framework for automatic configuration and discovery of the IP/port mapping. In the NAT environments, UPnP is used between the UE and the NAT device to negotiate the IP/port mappings of the media sessions.

10 The STUN Solution UE1(STUN Client) NAT STUN Server 1.Binding Request (For RTP) Src:IP UE1 / P RTP1 Dst:IP STUN / P STUN 1.Binding Request Src:IP NAT / PʹRTP1 Dst:IP STUN / P STUN 2.Binding Response 2.Binding Response Mapped IP/Port:IP NAT / PʹRTP1 Mapped IP/Port:IP NAT / PʹRTP1 IMS Peer Note: The NAT device is not modified in STUN. Request the IP/port mapping for RTP 3.SIP Call Setup 4.RTP 4.RTP 10 Perform the IP/port translation UE1 performs the STUN solution to automatically create and obtain the IP/port mappings with a STUN server outside the NAT. Since the NAT device creates IP/port mappings for UE1 and the STUN server, the NAT device (e.g., the symmetric NAT) may blocks the connections between UE and Peer.

11 The TURN Solution UE1 (TURN Client) NAT TURN Server 1.Allocate Request Src:IP UE1 /P RTP1 Dst:IP TURN /P TURN 3.Allocate Success Response 1.Allocate Request Src:IP NAT /P RTP1 Dst:IP TURN /P TURN 3.Allocate Success Response Relay IP/port:IP TURN /P TURN IMS 2.Create Relay IP/port Mapping IP NAT /P RTP1 IP TURN /P TURN Peer Relay IP/port:IP TURN /P TURN 4.SIP Call Setup 5.RTP 5.RTP 5.RTP Perform the IP/port translation The TURN solution is almost same as the STUN solution except that the TURN server acts as a relay for the media sessions. UE1 (i.e., the TURN client) utilizes the IP/port offered by the TURN server to establish the incoming media sessions. 11

12 The SIP-ALG Solution UE1 1.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1 ;rport c:ip UE1 m:p RTP1 Src:IP UE1 / P SIP1 Dst:IP IMS / P IMS OK 7.ACK NAT 1.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1 ;rport Request-URI:Peer@IMS c:ip UE1 m:p RTP1 Src:IP NAT / PʹSIP1 Dst:IP IMS / P IMS OK Via:IP UE1 /P SIP1 ; branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:Peer@IMS c:ip Proxy m:p Proxy2 Src:IP IMS / P IMS Dst:IP NAT / P' SIP1 7.ACK IMS (SIP-ALG) 2.Create Address Mapping IP NAT / PʹSIP1 IP Proxy / P Proxy1 3.INVITE Via:IP IMS /P IMS ; branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ; branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:Peer@IMS c:ip Proxy m:p Proxy1 Src:IP IMS / P IMS Dst:IP Peer / P Peer OK 5.Create Address Mapping IP Peer / P PRTP IP Proxy / P Proxy2 7.ACK RTP Proxy Peer Via:IP IMS /P IMS ; branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ; branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:Peer@IMS c:ip Peer m:p PRTP Src:IP Peer / P Peer Dst:IP IMS / P IMS 12 8.RTP 8.RTP Perform the IP/port translation 8.RTP

13 13 國立宜蘭大學 Message Flows (1/3) Step 1. UE1 issues an INVITE message to Peer. The INVITE message contains the IP/port pairs IP UE1 /P SIP1, IP UE1 /P RTP1, and IP UE1 /P SIP1 in the SIP, SDP and IP/UDP headers, respectively. Upon receipt of the INVITE message, the NAT device translates the source IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1, and then the NAT device forwards the translated message to the IMS. Step 2. When the IMS receives the INVITE message, it checks the IP/port values in both IP/UDP header and SIP header. Since the IP/port values in the IP/UDP header and SIP header are different, the IMS identifies that the INVITE message is translated by a NAT device. Then the IMS requests the RTP proxy to create a mapping IP NAT /P SIP1 IP Proxy / P Proxy1 and replies the assigned IP/port (IP Proxy /P Proxy1 ) to UE1.

14 Message Flows (2/3) Step 3. The IMS utilizes the assigned IP/port (IP Proxy /P Proxy1 ) to replace the IP/port (IP UE1 /P RTP1 ) in the SDP c and m fields. Then the IMS forwards the INVITE message to Peer. Step 4. When Peer receives the INVITE message, it replies a 200 OK message with its IP/port IP Peer /P PRTP in c and m fields to UE1 through IMS. Note that the Via fields are copied from the INVITE message. Step 5. Upon receipt of the 200 OK message, the IMS requests the RTP proxy to assign a public IP/port ( IP Proxy / P Proxy2 ) and create a mapping IP Peer /P PRTP IP Proxy / P Proxy2. 14

15 Message Flows (3/3) Step 6. Then IMS replaces IP Peer /P PRTP in the SDP c and m fields by using IP Proxy /P Proxy2 and forwards the modified 200 OK message to UE1 according to the received and rport parameters in the Via field. Steps 7-8. Upon receipt of the 200 OK message, UE1 replies an ACK message to complete the INVITE transaction. At this point, the media session between UE1 and Peer are established. Then RTP proxy plays a role as a relay to forward the media session between UE1 and Peer. 15

16 Comparison of the NAT-T Solutions 16 Best Solutions SIP-ALG /Proxy UPnP STUN TURN All Classifications of NAT Support Yes Yes No Yes Cascade NATs Support Yes No Yes Yes Client Modification No Yes Yes Yes NAT Modification No Yes No No External Server for Signaling SIP-ALG on SIP Server UPnP on NAT STUN Server TURN Server External Server for TURN RTP Proxy No No Media Server Extra RTP delay Yes No No Yes Major Issue of SIP-ALG

17 Comparison (1/2) The RTP proxy, the STUN server and the TURN server assists the media sessions to traverse over NAT, respectively. The SIP-ALG and the TURN solutions relay the RTP packets, and thus increase additional RTP transmission delay. Among the solutions, the UPnP, the STUN and the TURN solutions modify the client-side software. The SIP-ALG solution performs IP/port translation only on the server-side, and there is no modification on the UEs. Thus, the SIP-ALG solution is easily deployed among these solutions. In addition, 3rd Generation Partnership Project (3GPP) technical specifications [14] [15] also adopt the SIP- ALG solution to resolve the NAT traversal problems. 17

18 Comparison (2/2) The major issues of the SIP-ALG solution is that all the media sessions are exchanged through the RTP proxy. If the media sessions are exchanged through the RTP proxy, the RTP transmission includes additional delay for the transmission process and IP/port translations. This paper proposes a solution to prevent the extra RTP transmission delay and reduce the RTP packet loss. Specifically, the proposed esip-alg negotiates the mapped IP/port parameters with the NAT device instead of the RTP proxy and inform Peer the mapped IP/port. Thus, the translated RTP packets can be exchanged between the NAT and Peer directly without passing through the RTP proxy. 18

19 RTP Path of the SIP-ALG Solution The major problems of the SIP-ALG are that all multimedia sessions are exchanged through the RTP proxy. Thus, extra transmission delay and packet loss possibility due to RTP translation are increased. 3 transmissions 2 translations NAT IMS SIP-ALG Peer UE1 enb/henb Private Network RTP proxy Public Network 19

20 Problem Description In the SIP-ALG solution, the multimedia sessions are exchanged through the RTP proxy. The IP/port of the RTP packets are translated twice by the NAT device and the RTP proxy, respectively. The public IP/port assigned by the NAT device can be routed in Internet. However, the public IP/port is translated again by the RTP proxy. The delay and the packet loss probability are increased due to the unnecessary IP/port translation in RTP proxy. 20

21 RTP Path of the esip-alg Solution The proposed esip-alg negotiates the mapped IP/port with the NAT device instead of the RTP proxy. The RTP packets translated by the NAT device are sent to Peer directly without passing through the RTP proxy. 2 transmissions 1 translations NAT IMS SIP-ALG Peer UE1 enb/henb Private Network RTP proxy Public Network 21

22 esip-alg Call Setup Flow UE1 1.INVITE Contact:IP UE1 / P SIP1 c:ip UE1 m:p RTP1 Src:IP UE1 / P SIP1 Dst:IP IMS / P IMS Private IP UE1 / P SIP1 IP UE1 / P RTP OK SIP SDP IP/UDP Public IP NAT / PʹSIP1 IP NAT / PʹRTP1 NAT 2.INVITE Request-URI:Peer@IMS Contact:IP UE1 / P SIP1 c:ip UE1 m:p RTP1 Src:IP NAT / PʹSIP1 Dst:IP IMS / P IMS 3. Insert IP/Port Add Mapping Private:IP UE1 / P RTP1 Public:IP NAT / PʹRTP OK IMS (esip-alg) Private IP UE1 / P SIP1 4.INVITE Request-URI:Peer@IMS Contact:IP NAT / PʹSIP1 c:ip NAT m:pʹrtp1 Src:IP IMS / P IMS Dst:IP Peer / P Peer OK 6.ACK 6.ACK 6.ACK Public IP NAT / PʹSIP1 Peer 7.RTP 7.RTP 8.BYE Private Public 8.BYE 9. Delete Mappings 8.BYE 22 IP UE1 / P SIP1 IP NAT / PʹSIP OK OK OK

23 esip-alg Call Setup Flow (1/2) Step 1. The UE1 issues an INVITE message to Peer. This INVITE message contains the IP/port parameters IP UE1 /P SIP1, IP UE1 /P RTP1, and IP UE1 /P SIP1 in SIP, SDP and IP/UDP headers, respectively. Step 2. Upon receipt of the INVITE message, the NAT device translates the IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1. Then the NAT device forwards the translated message to the IMS. Step 3. When the IMS receives the INVITE message, it checks the IP/port parameters in the SIP header (IP UE1 /P SIP1 ) and the IP/UDP header (IP NAT /P SIP1 ). Since the IP/port parameters are different, the IMS assumes that the IP/UDP parameters are translated by the NAT. 23

24 esip-alg Call Setup Flow (2/2) 24 Step 3. The IMS requests the NAT to insert a mapping IP UE1 /P RTP1 IP NAT /P RTP1 for the media session and stores a mapping From/To/Call-ID P RTP1 in the IMS s media session table. Step 4. The IMS translates the IP/port parameter in the SDP header from IP UE1 /P RTP1 to IP NAT /P RTP1, and then forwards the translated message to Peer. Steps 5-7. Assume that Peer accepts the call and replies a 200 OK message to the UE1. The 200 OK message includes the IP/port (IP Peer /P PRTP ) for the media session in the SDP header. Upon receipt of the 200 OK message, UE1 replies an ACK message to complete the INVITE transaction. At this point, the media sessions between UE1 and Peer are established.

25 esip-alg Call termination Flow Steps To terminate the media sessions, Peer issues a BYE message to UE1 through the IMS. When the IMS receives this BYE message, it retrieves index P RTP1 of the media session from the IMS s media session table by using the index From/To/Call-ID in the BYE message. Then the IMS requests the NAT device to remove the mapping of the RTP session by using the index P RTP1, and the NAT device deletes the mapping IP UE1 /P RTP1 IP NAT /P RTP1. When UE1 receives the BYE message, it replies 200 OK message to Peer and the media session is terminated. 25

26 esip-alg Solution for Symmetric NAT Private IP UE1 /P SIP1 IP UE1 /P RTP1 Private IP UE1 /P SIP1 IP UE1 /P RTP1 UE1 NAT IMS Peer 1.INVITE Contact:IP UE1 / P SIP1 c:ip UE1 m:p RTP1 Src:IP UE1 / P SIP1 Dst:IP IMS / P IMS Peer IP IMS /P IMS IP IMS /P IMS Peer IP IMS /P IMS IP Peer /P PRTP NAT IP/Port IP NAT /PʹSIP1 IP NAT /PʹRTP1 NAT IP/Port IP NAT /PʹSIP1 IP NAT /PʹRTP OK 2.INVITE Request-URI:Peer@IMS Contact:IP UE1 / P SIP1 c:ip UE1 m:p RTP1 Src:IP NAT / PʹSIP1 Dst:IP IMS / P IMS 3. Insert IP/Port Add Mapping Private:IP UE1 / P RTP1 Peer:IP IMS / P IMS NAT:IP NAT / PʹRTP1 Major Difference 6. Modify IP/Port Peer:IP Peer / P PRTP OK Private IP UE1 /P SIP1 4.INVITE Request-URI:Peer@IMS Contact:IP NAT / PʹSIP1 c:ip NAT m:pʹrtp1 Src:IP IMS / P IMS Dst:IP Peer / P Peer OK Contact:IP NAT / PʹSIP1 c:ip Peer m:p PRTP Src:IP Peer / P Peer Dst:IP IMS / P IMS 7.ACK 7.ACK 7.ACK Peer IP IMS /P IMS NAT IP/Port IP NAT /PʹSIP1 8.RTP 8.RTP 26 9.BYE 9.BYE 9.BYE

27 Message Flows (1/4) Step 1. UE1 issues an INVITE message to Peer. The INVITE message contains the IP/port IP UE1 /P SIP1, IP UE1 /P RTP1, and IP UE1 /P SIP1 in the SIP, SDP and IP/UDP headers, respectively. The Request-URI field identifies the application-layer contact address (e.g., The SDP c and m fields are the IP address and port for establishing the media sessions. The INVITE message is first sent to the IMS because UE1 does not know the IP/port of Peer. Since the IMS and UE1 reside in the different networks, the INVITE message is routed to the NAT device. When the NAT device receives the INVITE message, it translates the source IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1. Then the NAT device forwards the translated message to the IMS. 27

28 Message Flows (2/4) Step 2. When the IMS receives the INVITE message, it checks the IP/port parameters in the SIP header (IP UE1 /P SIP1 ) and the IP/UDP header (IP NAT /P SIP1 ). Since the IP/port values are different, the IMS detects that the IP/port parameters in the IP/UDP header are translated by the NAT device. Then the SIP-ALG requests the NAT device to insert a mapping IP UE1 /P RTP1 : IP IMS /P IMS IP NAT /P RTP1 for the media session and stores a mapping From/To/Call-ID P RTP1 in the IMS s media session table. Since the IP/port for Peer s media session is unknown, the IMS temporarily uses IP IMS /P IMS instead of the IP/port of Peer mapping. 28

29 Message Flows (3/4) Step 3. Then the IMS modifies the c and m fields in the SDP header from IP UE1 /P RTP1 to IP NAT /P RTP1. The INVITE message is forwarded to Peer based on the Request-URI field. Step 4. Peer accepts the call and replies a 200 OK message to UE1. The 200 OK message includes the IP/port for media (IP Peer /P PRTP ) in the SDP header. Step 5. When the IMS receives the 200 OK message, it retrieves the IP/port IP Peer /P PRTP from the SDP header and requests the NAT device to modify the mapping from IP UE1 /P RTP1 : IP IMS /P IMS IP NAT /P RTP1 to IP UE1 /P RTP1 : IP Peer /P PRTP IP NAT /P RTP1. Specifically, the IP/port IP IMS /P IMS is changed to IP Peer /P PRTP. 29

30 Message Flows (4/4) Steps 6-8. These steps are the same as Steps 4~6 in Figure After Step 7, the INVITE transaction is complete, and a media sessions are established at Step 8. Note that the media session between UE and Peer is divided into two sub-sessions. Steps The steps are the same as Steps 7~9 in Figure The mapping entry IP UE1 /P RTP1 : IP IMS /P IMS IP NAT /P RTP1 to IP UE1 /P RTP1 : IP Peer /P PRTP IP NAT /P RTP1 is removed by using the index P RTP1 In the both cone NAT and symmetric NAT cases, the esip-alg solution does not require the RTP proxy to translate the IP/port for the media sessions. Since the NATs are controlled by the operator s core network component/function (e.g., the IMS), the IP/port mappings are controlled by the IMS. 30

31 Summary of the esip-alg Solution Since the public IP/port assigned by the NAT device can be routed in Internet and the NAT device (e.g., P-GW) is controlled by the core network, this thesis proposes an enhanced SIP-ALG (esip-alg) solution to improve the performance of the media transmission by removing the additional translation of the RTP proxy. The esip-alg solution negotiates with the NAT device instead of the RTP proxy to create the IP/port mappings and inform Peer the mapped public IP/port. Therefore, the esip-alg solution provides a better transmission path compared to the SIP-ALG solution. 31

32 Devices within the Same NATthe SIP-ALG Solution The devices cannot communicate directly when they reside within the same private network (NAT device). If the multimedia streams are exchanged through the RTP proxy in such case, the transmission path includes additional transmission paths and unnecessary IP/port translations. 4 transmissions 3 translations IMS SIP Registrar UE1 NAT SIP-ALG RTP proxy UE2 enb/henb Private Network Public Network 32

33 Devices within the Same NAT- Problem of the esip-alg Solution Some NATs will not accept an internal packet sent to NAT s public IP address and loops back to a private IP address [17]. Thus, the esip-alg detects whether the communication parties reside in the same NAT device during the session setup process. If yes, the esip-alg solution keeps the local IP/port for the multimedia streams (i.e., SDP c and m fields) unchanged. 1 transmissions 0 translations IMS SIP Registrar UE1 NAT SIP-ALG RTP proxy 33 UE2 enb/henb Private Network Public Network

34 Registration Flow UE1 NAT IMS 1.REGISTER UE1 /P SIP1 SIP Src:IP UE1 / P SIP1 Dst:IP IMS / P IMS IP/UDP (a) mapping table Private Public IP UE1 /P SIP1 IP NAT /P' SIP1 2.REGISTER Request-URI:UE1@IMS Contact:UE1@IP UE1 /P SIP1 Src:IP NAT / P' SIP1 Dst:IP IMS / P IMS (b) Location table URI NAT IP/port UE1@IMS IP NAT /P' SIP OK OK 34

35 Registration Flow (1/2) Step 1. UE1 issues a REGISTER message to the IMS. The REGISTER message contains the IP/port parameters in the IP header and the SIP header. Since the IMS and UE1 reside in different networks, the REGISTER message is sent to the default gateway of UE1 (i.e., the NAT device). Step 2. The NAT device translates the IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1, and stores the mapping (IP UE1 /P SIP1 IP NAT /P SIP1 ) into its mapping table. Then the NAT device forwards the message to the IMS. 35

36 Registration Flow (2/2) Step 3. When the IMS receives the REGISTER message, it retrieves the application-layer identity from the Request-URI field, the IP/port (IP UE1 /P SIP1 ) from SIP Contact header field, and the public IP/port (IP NAT /P SIP1 ) from the IP/UDP header. The IMS compares the IP/port retrieved from the Contact field with that retrieved from the IP/UDP header. Since the IP/port values are different, the IMS detects that the REGISTER message is translated by the NAT. The IMS uses the IP (IP NAT ) in the IP header instead of that (IP UE1 ) in the Contact field as the contact address and stores the mapping (UE1@IMS IP NAT /P SIP1 ) into the Location table. After the registration process is success, the IMS replies a 200 OK message to UE1. 36

37 Message Flow of esip-alg Solution UE1 UE2 NAT IMS 1.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1 ;rport c:ip UE1 m:p RTP1 Src:IP UE1 / P SIP1 Dst:IP IMS / P IMS SIP SDP IP/UDP (a) Mapping table Private IP UE1 /P SIP1 IP UE2 /P SIP2 Public IP NAT /P' SIP1 IP NAT /P' SIP2 1.INVITE Via: IP UE1 /P SIP1 ;branch=z9hg4bkabcde1; ;rport Request-URI:UE2@IMS c:ip UE1 m:p RTP1 Src:IP NAT / P' SIP1 Dst:IP IMS / P IMS 2 (b) Location table URI NAT IP/port UE1@IMS IP NAT /P' SIP1 UE2@IMS IP NAT /P' SIP RTP 7.ACK 3.INVITE Via:IP IMS /P IMS ;branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ;branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:UE2@IMS c:ip UE1 m:p RTP1 Src:IP IMS / P IMS Dst:IP UE2 / P SIP OK Via:IP IMS /P IMS ;branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ;branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:UE2@IMS c:ip UE2 m:p RTP2 Src:IP UE2 / P SIP2 Dst:IP IMS / P IMS OK 7.ACK 3.INVITE Via:IP IMS /P IMS ;branch=z9hg4bkabcde2 Via:IP UE1 /P SIP1 ;branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:UE2@IMS c:ip UE1 m:p RTP1 Src:IP IMS / P IMS Dst:IP NAT / P' SIP OK OK Via:IP UE1 /P SIP1 ;branch=z9hg4bkabcde1; received=ip NAT ;rport=p' SIP1 Request-URI:UE2@IMS c:ip UE2 m:p RTP2 Src:IP IMS / P IMS Dst:IP NAT / P' SIP1 7. ACK 7. ACK 5 (c) Transaction table branch DC z9hg4bkabcde2 Yes

38 Description of esip-alg Solution (1/3) 38 Step 1. UE1 issues an INVITE message to UE2. The INVITE message is first sent to the IMS. Since the IMS and UE1 reside in the different networks, the INVITE message is routed to the NAT device. The NAT device translates the IP/port in the IP/UDP header from IP UE1 /P SIP1 to IP NAT /P SIP1, and forwards the message to the IMS. Step 2. When the IMS receives the INVITE message, it checks the IP/port of the IP/UDP header and SIP header. Since the IP/port values are different, the IP/port (IP NAT / P SIP1 ) in the IP/UDP header is translated by the NAT device. Then the IMS starts to check whether UE1 and UE2 reside in the same private network. According to the Request-URI, the IMS retrieves UE2 s IP address (IP NAT ). The IMS compares the IP address of UE1 with that of UE2 and detects that UE1 and UE2 use the same IP address (IP NAT ).

39 Description of esip-alg Solution (2/3) Step 3. The IMS then records the branch parameter (i.e., branch=z9hg4bkabcde2) and DC field Yes in the Transaction table. The DC field value Yes represents that UE1 and UE2 can directly communicate with each other. Thus, the IP/port in the SDP header does not require to modify. Then the IMS inserts new Via field (Via:IP IMS /P IMS ;branch=z9hg4bkabcde2) with the received and rport parameters (received=ip NAT and rport=p SIP1 ) into the INVITE message. The INVITE message is forwarded to UE2 based on the Request-URI. Step 4. UE2 accepts the call and replies 200 OK message to UE1. The 200 OK message includes the IP/port of RTP (IP UE2 /P RTP2 ) in the SDP header. The IP/port in the IP/UDP header through the NAT device is translated from IP UE2 /P SIP2 to IP NAT /P SIP2. 39

40 Description of esip-alg Solution (3/3) Step 5. When the IMS receives the 200 OK message, it checks the top Via field and obtains the branch parameter (z9hg4bkabcde2). According to the value of the branch parameter, the IMS retrieves the DC value Yes from the Transaction table. The IMS keeps the IP/port (IP UE2 /P RTP2 ) in the SDP header unchanged. Step 6. Then the IMS removes the top Via field and forwards the message to UE1 based on the Via field. Steps 7-8. The process of the ACK message is similar to that of the INVITE message in Step 1 and is omitted here. When UE2 receives the ACK message, the media sessions between UE1 and UE2 are established. At this point, UE1 and UE2 directly communicate with each other. 40

41 Performance Analysis In the SIP-ALG solution, there is a RTP proxy relaying the media sessions between the NAT device and Peer. The RTP transmission path (i.e., Path 2) of the SIP-ALG solution is (a) (c) (d). In the esip-alg solution, the RTP packets are translated by the NAT device and then forwarded to Peer directly. The RTP transmission path (i.e., Path 1) is (a) (b). Obviously, the RTP proxy in Path 2 increases the RTP transmission delay and the packet loss possibility. UE (a) NAT (c) RTP proxy (d) Peer (b) Path 1 (a) (b) The esip-alg solution Path 2 (a) (c) (d) The ALG solution 41

42 Input Parameters The NAT and the RTP proxy follow the M/M/1/k model. λ 1 and λ 2 are the input rates to the NAT and the RTP proxy. μ 1 and μ 2 are the processing rates of the NAT and the RTP proxy. k 1 and k 2 are queue sizes of the NAT and the RTP proxy. The load factors ρ 1 = λ 1 / μ 1 and ρ 2 = λ 2 / μ 2. P k1 and P k2 be the packet loss possibilities for the NAT and the RTP proxy Based on above input parameters, this thesis derives the analytic models for the throughput and transmission delay. 42

43 Derivation (1) P k1 = Pr the NAT s queue is full = Pr k 1 packets are in the NAT s queue = ρ 1 k 1 1 ρ 1 1 ρ 1 k1+1. (1) P k2 = Pr the RTP proxy s queue is full = Pr k 2 packets are in the proxy s queue = ρ 2 k 2 1 ρ 2 1 ρ 2 k2+1, (2) 43 where ρ 1 = λ 1 μ 1 and ρ 2 = λ 2 μ 2.

44 Derivation (2) Based on (1), the packet loss probability of the esip-alg solution is λ 1 P k1 = λ 1 ρ 1 k 1 1 ρ 1 1 ρ 1 k1+1. (3) The throughput of the esip-alg (T 1 ) is T 1 = λ 1 1 P k1 = λ 1 (1 ρ 1 k 1 1 ρ 1 1 ρ 1 k1+1) = λ 1 (1 ρ 1 k 1 ρ 1 k ρ 1 k1+1 ). (4) 44

45 Derivation (3) The delay of the esip-alg solution (D 1 ) is D 1 = k1 n =0 n P n = λ 1 (1 P k 1 ) k1 n =0 n ρ1 k1 λ 1 1 ρ 1 k1 1 ρ 1 k1+1 1 ρ 1 1 ρ 1 k1+1 (5) Based on Figure 4.1.1, the throughput of the NAT is the input rate of the RTP proxy λ 2. λ 2 = λ 1 (1 P k1 ). (6) 45

46 Derivation (4) From (4) and (6) the packet loss probability of the RTP proxy is derived as λ 2 P k2 = λ 1 1 P k1 P k2 = λ 1 (1 ρ 1 k 1 = λ 1 ( 1 ρ k1 1 k1+1) 1 ρ 1 1 ρ 1 1 ρ 1 k1+1) ρ 2 k 2 1 ρ 2 k2 1 ρ 2 1 ρ 2 k2+1 1 ρ 2 k2+1. (7) 46

47 Derivation (5) From (4) and (6), the throughput of RTP proxy (T 2 ) is derived as T 2 = λ 2 1 P k2 = λ 1 (1 P k1 ) (1 P k2 ) = λ 1 (1 ρ 1 k 1 = λ 1 1 ρ 1 k1 1 ρ 1 k1+1 1 ρ 1 1 ρ 1 k1+1) (1 ρ 2 k 2 1 ρ 2 k2 1 ρ 2 1 ρ 2 k2+1) 1 ρ 2 k2+1. (8) 47

48 Derivation (6) From (8), the delay of the RTP proxy (D 2 ) is derived as D 2 = k2 n =0 n P n λ 2 1 P k 2 = k2 n =0 λ 1 n ρ 2 k2 1 ρ 2 k2+1 1 ρ 2 1 ρ k1 1 k1+1 1 ρ k1 1 k1+1 1 ρ 1 1 ρ 1. (9) 48

49 Derivation (7) From (4) and (6), ρ 2 is re-written as ρ 2 = λ 2 = λ 1 (1 P k 1 ) μ μ 1 2 ν = ν ρ 1 λ 1 (1 P k1 ) = ν ρ 1 λ 1 1 ρ 1 k1 1 ρ 1 k1+1 (10) 49 where ν = μ 1 μ 2.

50 Output Measurement- Throughput P k1 = ρ 1 k 1 P k2 = ρ 2 k 2 1 ρ 1 1 ρ 1 k1+1 1 ρ 2 1 ρ 2 k2+1 The throughput of the esip-alg solution is k λ 1 1 P k1 = λ 1 (1 ρ 1 1 ρ 1 1 k 1 ρ 1 +1 ) 1 The throughput of the SIP-ALG solution is λ 2 1 P k2 = λ 1 (1 P k1 ) (1 P k2 ) 50

51 Output Measurement- Transmission Delay The delay of the esip-alg solution is k1 n=0 n P n = λ 1 (1 P k 1 ) k1 n=0 n ρ1 k1 λ 1 1 ρ 1 k1 1 ρ 1 1 ρ 1 k1+1 1 ρ 1 k1+1 The delay of the SIP-ALG solution is k 2 n=0 n P n = λ 2 1 P k2 k 2 n=0 n ρ 2 k 2 1 ρ 2 1 ρ 2 k 2 +1 k 1 k 1 ρ 1 λ 1 1 k 1 ρ ρ 1 k 1 1 ρ

52 Effect of the μ 2 on the Throughput when 0 < ρ 1 < 1, the throughput decreases slowly. That s because most of input packets are served. After ρ 1 >1, the throughput decreases dramatically since the processes of the NAT device and the RTP proxy are overloaded and most of the input packets are dropped. when the RTP proxy s processing rate is twice than that of the NAT device (i.e., μ 1 =0.5μ 2 ), the maximum throughput of the Path 2 is almost the same as that of the Path 1. 52

53 Effect of the μ 2 on the Delay When the load ρ 1 increases, there are more packets buffered in the queue. The input packets should wait more time to be processed. When the queue is not full, the delay increases with the input rate increases. Although the processing rate of the RTP proxy is twice than that of the NAT device (i.e., μ 1 =0.5μ 2 ), the delay of the SIP-ALG is still larger than that of the esip-alg. 53

54 Effect of the Queue Size k on the Delay The packets translated by NAT are transmitted to the RTP proxy s queue. Since the processing rates of the NAT device and the RTP proxy are the same (i.e., ν=1), there are few packets queued in the RTP proxy. As a result, the most delay is caused by the NAT s queue (i.e., k 1 ). 54

55 Conclusion and Future Work 55 The proposed esip-alg solution removes the RTP proxy from the RTP transmission path. The processing rate of the RTP proxy should be larger (e.g., twice larger) than that of the NAT to prevent that the SIP- ALG s throughput decreases dramatically. Even if the RTP proxy has twice processing rate than the NAT, the total delay of the SIP-ALG solution is still larger than the proposed esip-alg solution. Based on the numerical results, the esip-alg solution provides the direct communications and the optimal transmission path. In future work, we will investigate the device s mobility in the NAT environments.

56 Appendix- Parameters in the Message Flows IP UE1 is the IP address of UE1. IP UE2 is the IP address of UE2. IP Peer is the IP address of Peer. IP NAT is the IP address of the NAT. IP IMS is the IP address of the IMS (e.g., Proxy-CSCF). P SIP1 is the UDP port used by UE1 for SIP. P RTP1 is the UDP port used by UE1 for RTP. P SIP2 is the UDP port used by UE2 for SIP. P RTP2 is the UDP port used by UE2 for RTP. P IMS is the UDP port used by the IMS for SIP. P Peer is the UDP port used by Peer for SIP. P PRTP is the UDP port used by Peer for RTP. P' SIP1 is the translated port of P SIP1, which is translated by the NAT. P' RTP1 is the translated UDP port of P RTP1. P' SIP2 is the translated port of P SIP2, which is translated by the NAT. P' RTP2 is the translated UDP port of P RTP2. 56

57 References [1] IPv6 Adoption. Online Access: adoption&tab=ipv6-adoption. [2] Skoberne, N.; Maennel, O.; Phillips, I.; Bush, R.; Zorz, J.; Ciglaric, M. IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis. IEEE Transaction, 2014, Volume 22, Issue 2, pp [3] Yeh C.-C., C.-W. Mint: A Cost-effective Network-address Translation Architecture with Multiple Inexpensive NAT Servers. Ubiquitous and Future Networks (ICUFN), 2015 Seventh International Conference. 2015, pp [4] Pelagie, H., & Ernesto, D. (2011, October). Overcoming NAT traversal issue for SIP-based communication in P2P networks. In Wireless and Mobile Networking Conference (WMNC), pp [5] Chen, W.-E., Huang, Y.-L., & Chao, H.-C. (2008). NAT traversing solutions for SIP applications. EURASIP Journal on Wireless Communications and Networking, 2008,

58 References 58 [6] Wacker, A., Schiele, G., Holzapfel, S., & Weis, T. (2008). A NAT traversal mechanism for peer-to-peer networks. Peer-to-Peer Computing, 2008, [7] Boucadair, M., Penno, R., & Wing, D. (2013, July). Universal Plug and Play (UPnP) Internet Gateway Device, Internet Engineering Task Force, RFC [8] Rosenberg, J., Mahy, R., Matthews, P., & Wing, D. (2008, October). Session Traversal Utilities for NAT(STUN). RFC [9] Rosenberg, J., Mahy, R., Matthews, P., & Wing, D. (2010, April). Traversal Using Relays around NAT (TURN): Relay extensions to Session Traversal Utilities for NAT (STUN), RFC [10] Beijnum, I. V. (2011, October). An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation. Internet Engineering Task Force, RFC [11] Rosenberg, J. (2010, April). Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. RFC 5245.

59 References 59 [12] Kimoon, B., & Kyuseob C. (2010). The problems and their solutions when using SIP in NAT environment. In th international conference on computer sciences and convergence information technology (ICCIT), pp [13] Muller, A., Carle, G., & Klenk, A. (2008). Behavior and classification of NAT devices and implications for NAT traversal. Network IEEE, 22(5), [14] Third Generation Partnership Project (3GPP). (2015). Technical specification group services and system aspects. IP Multimedia Subsystem (IMS), Technical Specification (TS) version , June 24. [15] Third Generation Partnership Project (3GPP). (2015). Technical specification group services and system aspects. IMS Application Level Gateway (IMS-ALG) IMS Access Gateway (IMS-AGW) interface, Technical Specification (TS) version , June 23. [16] Lin, Y.-D., & Tseng, C.-C. (2010). How NAT-compatible are VoIP applications? Communications Magazine IEEE, 48(12),

60 References [17] Rosenberg, J., Mahy, R., Matthews, P., & Wing, D. STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), Internet Engineering Task Force, RFC [18] Artalejo, J. R., & Lopez-Herrero, M. J. (2001). Analysis of the busy period for the M/M/c queue: An algorithmic approach. Applied Probability, 38, [19] Gautam, N. (2012). Analysis of queues: Methods and applications. Taylor & Francis Group: CRC Press. [20] Omahen, K., & Marathe, V. (1978). Analysis and applications of the delay cycle for the M/M/c queueing system. JACM, 25(2),

61 Thank you for your attention. Q&A 61