Nat Traversal For Video Streaming Applications Information Technology Essay

Video streaming is considering one of the famous technologies which is used today. It provides the ability to playback video files remotely through computer networks. The demand for this technology is rapidly increasing due to wide spread of Internet and increasing of the network bandwidth[1]

While HTTP protocol uses one TCP port at the transport layer, RTP can use many ports. RTP can use UDPs or TCPs ports at the transport layer depending on how much the packet path is suffered from packet loss [2]. In low packets loss environment, the use of RTP over UDP protocol is preferable, since in media streaming, the small ratio of packets loss better than packets delay. Hence, the higher reliability of the TCP is not desired[3]. UDP/RTP has also the multicasting feature and has the ability to deal with real time communication due to its features in bandwidth, jitter, reliability and end node’s processing.

RTP/TCP can cause the video streaming to suffer from discontinuity because the need to retransmission and reordering the packets, whereas RTP/UDP can suffer from dropping the packets by some filters (firewalls) in the Internet Service Provider (ISPs). Some ISPs drop UDP packets because they are connectionless hence unfair against TCP traffic. They also need high processing power and memory to ensure security [4]. But the main issue that can occur is when using the RTP with the Network Address Translation (NAT). NAT drops any RTP/UDP or RTP/TCP packets that are initialized from the outside (Internet) when incoming to the end-systems (behind the NAT).

The NAT is a technology that permits many computers on the same network to share a public Internet Protocol (IP) address for accessing the Internet. The main reason behind the wide spread of using the NAT is the limited number of the available IPv4 addresses [5].

The use of RTP/UDP or RTP/TCP video streaming is started with a TCP connection that is established by a request from the client to the server, after initial negotiation using the RTSP protocol on the same established TCP channel, the server starts video streaming through UDP or TCP ports initialized from the server not through the original RTSP/TCP channel [2].

The NAT permits to pass the outgoing connections requests from a host behind the NAT into the outside network (like Internet) [6], however it does not permit to pass any connection request from the outside network (like Internet) to any host behind the NAT [7]. This is because the translation table entry is constructed only when a client (behind the NAT) initializes a request to connect to a host on the outside network (Internet) [8], [9]. If the initialized request came from a host on the outside network of the NAT into the inside network, the NAT cannot identify the destination host for this request and the connection between the outside host and the inside one cannot be occur [8], [10]. Regarding to the RTP/UDP video streaming, the NAT will not allow the UDP video streaming channels to pass to the client behind the NAT, since the RTP/UDP channels are initially established from the server (on the Internet).

Considering the RTP weakness points, the HTTP protocol, is the preferable choice for video streaming. However, HTTP protocol also has known weakness points: the user can suffer from quality reduction and playback discontinuity due to the probing behaviour of TCP protocol. This can also cause an oscillating throughput and slow recovery of the packet rate.

In contrast, the UDP protocol provides a mean to keep the desired sending rate constant. It also keeps streaming smooth and eliminates the TCP related processing.

This paper presents a novel method to utilize the benefits of both TCP and UDP. The proposed method enables NAT traversal by converting each RTP/UDP and RTCP/UDP packet into fake TCP packet just before being sent (at data link layer) by adding a fabricated TCP header before each UDP video streaming packet and making the necessary modifications to the length and checksums fields.

These fabricated TCP packets will pass the NAT, since they will be transmitted on the channel (IP, TCP port) that firstly initialized (RTSP/TCP channel) by the client behind the NAT. In this paper, this channel is called the active channel.

The receiver, on the other side has to restore the original UDP packet before being processed by the corresponding transport layer. The restoration is based on a specific signature. In order to restore the packets, every fabricated TCP packet has to have a known signature. Depending on that signature, the receiver will restore the original packet. All of the previous changes are performed at the data link layer.

The rest of this paper is organized as follows: section II, looks at some related work. In section III, the proposed methodology and algorithm are presented. In section IV, the experiments of the implemented proposed method and its discussions are described. In section V, the evaluation of the proposed method and comparisons between the proposed method and the existing technologies are presented. The paper is concluded is section VI.

Related work

Limited to our knowledge, no many similar works are presented. However, [4] present a method to overcome the RTP/UDP issues by putting a proxy server between the client and the streaming server (at the global network). The proxy receives a HTTP request (TCP) from the client and translates it to a RTSP/RTP request to the server (TCP+UDP). The proxy has two different connections (one for the client and the other for the streaming serve). The main function of the proxy is to translate the HTTP streaming protocol into RTSP/RTP streaming protocol. This can overcome the NAT problem due to that the HTTP request (TCP) is initialized by the client and the reply will pass through the same TCP port. However a third device is needed. In addition it is still using the constraints of the TCP between the proxy and the client (e.g. retransmission and reordering …etc) (in addition to the increase of traffic to the network). Another issue is that there are too many operations in order to convert a complete application protocol into another one. Beside, this method loses the real time property that is needed for end to end communication because all the packets mush be forwarded at the proxy server.

Proposed Methodology

In this work, both the client and the server are assumed to convert all the RTP/UDP streaming packets into fabricated TCP packets that can be sent to the other side using the active channel.

This fabrication process which is implemented for Windows Operating System (OS) requires a full control of the incoming/outgoing packets. However, there is the issue of source code of the TCP/IP (non open source for Windows OS) is not readily accessible and Windows does not allow the manipulation of the packets in any TCP/IP protocol suite from level above the TCP/IP driver layer.

To overcome the inaccessibility issue, a hooking technique is used in order to control the (frame/packet) at the point that links between the protocol driver and the NIC card(s), which is represented by the Network Driver Interface Specification (NDIS).

Hooking is a technique that can convert the calling of one operating system function into a new one that in turn calls the original one. The new function can do extra job before moving the execution to the original. This can be done without the need for the source code of the original [11].

The proposed modules is implemented and run in windows user mode. When the module can hook the NDIS, it can monitor, control, add, and modify the NDIS incoming/outgoing packets easily.

The NDIS-Hooking driver inserts itself between TCP/IP and all of the adapters that bind with it as shown in figure (1).

Figure 1. NDIS hooking driver with relation to user mode

When TCP/IP sends a packet, it reaches the NDIS-Hooking driver (as a frame) before sending to the adapter. Likewise, packets that are to be indicated (received) on TCP/IP will go to the NDIS-Hooking driver first.

The fabricated TCP header is inserted/deleted in the data link frame, this means that the original RTP/UDP protocol is used without modification. Nonetheless the fabricated packets can still bypass the NAT as authenticated ones.

Figure 2. Proposed frame structure

As these extra bytes (fabricated TCP header) will add when the packet is in the data link layer, this may cause the packet to exceed the Maximum Transfer Unit (MTU) of the network. Since, no packet must exceed the Maximum Transfer Unit (MTU) of the network [12], [13], therefore, the sender’s MTU must be decreased by length of the fabricated TCP header length (20 bytes).

The whole proposed system is composed of two main modules. The first module resides on the streaming client while the second resides on the streaming server. Figure (3) shows the video streaming network topology.

Figure 3. Video streaming network topology

Each module consists of the following components:

A component (hooking function in Fig. 1) that makes the access to the frame at the data link layer. This component accesses the frames in data link layer which is in the kernel mode and moves it into the user mode and vice versa.

A component that finds the required frame based on its content. This component extracts the specified packets from the frames which have to be changed (fabricated/restored) depending on sending direction (income/outcome).

A component that makes the required modifications (fabricating/restoring) to the predetermined packets. This component changes the predetermined packets depending the sending direction (send/receive). In sending, the component changes the RTP/UDP packet into fabricated TCP packet. In receiving, the component restores the fabricated TCP packet into its original RTP/UDP content. This component also re-computes length and checksums.

Client Side Module

As mentioned earlier, the module has to access the kernel (at data link layer). This is done by accessing the NDIS driver. The module listens until a packet event has occurred. There are two possible scenarios:

Incoming packet: If the packet is coming from the streaming server, then the program will look for the TCP that contains an RTSP packet. If this RTSP packet contains both the client’s and server’s streaming ports, then record this connection’s information into an array. This is happened normally at the setup phase of the RTSP connection. Later (when the RTP packet used), the client will check every TCP packet if it contains a specified signature. If this signature is raised (in the TCP header), this mean that this TCP packet is fabricated and it contains the original RTP/UDP packet. The program will remove the TCP header and recomputed the UDP and IP checksums. All these steps are done before sending the packet to the rest of TCP/IP protocol stack

Outgoing packet: If the packet is outgoing to the streaming server and the outgoing packet was a RTP/UDP packet, then insert a new fabricated TCP header before the UDP header. This fabricated TCP header contains the TCP connection information taken from the appropriate record from an array containing all streaming connections’ details. This TCP header also contains a specified signature that has to been recognized from the streaming server in order to return the packet back to its original RTP/UDP packet. This operation also needs to recompute the checksums. All these steps are done before sending the packet to the adapter. Figure 4 shows the flowchart of client side module.

Figure 4. Flowchart of the client side module

Server Side Module

In server side module, steps similar to the client are also implemented. The difference is that the system gets the RTSP connection’s details from the outgoing TCP packet instead of incoming TCP packet in the client. Figure (5) shows the flowchart of the main steps of the server module.

Figure 5. Flowchart of the server side module

Experiments and discussions

Experiments Setup

In this experiment, we use three PCs running windows XP. Two PCs with one LAN card (client and the server). The other PC (working as a NAT) contains two LAN cards.

RedMug streaming server commercial software is used on the server site. The VLC media player (version 1.0.5) is used on the client side. The VLC media player is set to use the RTSP protocol by giving a URL of one movie on the streaming server. The proposed method (client and server modules) is implemented in VC++.Net Framework and it is running in windows OS environment in user mode. A windows device driver (Windows Packet Filter Kit “winpkfilter 3.0” from NT Kernel Resources, http://www.ntkernel.com) is used for the hooking purpose.

Experimental Results and Discussion

In the first experiment (before using the proposed method), the client tries to access the movie on the streaming server using the above system configuration. The connection’s establishment and the video streaming negotiations between the client and the server are established normally. However, the connection fails at the stage of data streaming transformation (see Fig. 6).

Figure 6. Connection breakdown when data streaming transforming began (server side)

The reason for the success of the initialization of the client-server connection and all the negotiations needed to transfer the video streaming are that the connection request is a TCP and the initialization is coming from the client (behind the NAT) and the video streaming negotiations are done by the RTSP that uses the active channel. However, the client could not receive the video streaming data since the NAT dropped the RTP/UDP video streaming packets. The client then sends a teardown command to inform the server that the negotiation is over. The client starts one additional negotiation tries before it close the connection.

In the second experiment, we used the proposed clients and server modules. After running, the two modules start monitoring the data link frames. The client monitors the outgoing streaming request while the server monitors the incoming streaming request.

When the client request a video streaming from the server, The connection’s establishment and the video streaming negotiations between the client and the server are established normally and the client starts to display the video streaming data as shown if figure (7A and 7B).

FEATURE

HTTP

RTP/TCP

RTP/UDP

PROPOSED METHOD

Directional

Bidirectional

Bidirectional

Uniary

Uniary

Playback hiccups

Yes

Yes

No

No

Quality Reductions

Yes

Yes

No

No

Oscillating throughput

Yes

Yes

No

No

Slow recovery

Yes

Yes

No

No

ISP firewall

Traverse

Traverse

Blocked

Traverse

NAT traversal

Yes

No

No

Yes

End-to-End Delay

Long

Long

Short

Short

Window buffer and reordering

Yes

Yes

No

No

Streaming method

Downloading or progressive

Streaming

Streaming

Streaming

Figure 7A. Connection still active when the data streaming are transforming (server side)

Figure 8B. Video streaming is displayed in the client (behind the NAT)

When negotiation is captured, the host records the connection details: IP, TCP port and the streaming UDP ports. The host will insert the fabricated TCP header (after the UDP header) in the video streaming packet before sending it.

The reason for the success of transforming the streaming data is that the sending host converts each streaming UDP packet into a fabricated TCP packet that bypasses the NAT because it uses the active channel. The receiving host in turn restores the fabricated TCP packet into the UDP streaming data at the data link layer before sending it to the upper layer.

Evaluation

A comparison between our proposed method and the existing technologies is presented in Table 1. The proposed method has several advantages over the existing technologies, although the new packet size is 20 bytes larger than the normal RTP/UDP packet, but less compared with the HTTP. This has a little impact on the network performance.

The proposed method can traverse the video streaming over all types of NAT. It can also traverse the firewall that blocks the UDP ports that RTP may use, common with home Internet gateway. Streaming might fail at times even if the gateway has a built-in RTSP NAT.

Reference [4] utilizes the two streaming protocols separately by using a third device (proxy) between the client and server (every side with whole streaming protocol advantages and disadvantages), the proposed method utilizes the benefits of the RTP and HTTP protocols without using any extra device.

Table I. CURRENT AND PROPOSED METHOD COMPARISON

Conclusion

The two main transport layer protocols: TCP and UDP can be used in streaming but with the whole advantages and disadvantages of using that protocol. In this paper, a new method is presented and implemented that can merge some advantages of both protocols. It enables the client and server to use UDP advantages in each side for streaming. Both client and server gains scalability by not having to deal with some TCP processing feature (e.g. Acknowledgement and window buffering …etc). In the other hand, utilize the benefit of the TCP advantages to traverse the NAT and the firewall. In other words, the stream is not discarded and traverses the NAT and the firewall. The experimental results show that the new method achieves the firewall traversal and Nat traversal even with the most difficult NAT (symmetric NAT).