Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Download
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
2Activity
×
0 of .
Results for:
No results containing your search query
P. 1
Nat Traversal for Video Streaming Applications

Nat Traversal for Video Streaming Applications

Ratings: (0)|Views: 1,166|Likes:
Published by ijcsis
Abstract— This paper presents a novel method that exploits the strength features of two streaming protocols (Real-time Transport Protocol (RTP) and Hypertext Transfer Protocol (HTTP)) to overcome the Network Address Translation (NAT) and firewall traversal problem. The proposed solution is able to bypass the RTP over all kinds of NATs (including symmetric NATs) by adding extra fields to the RTP/UDP packet at transport layer in the sender side. The NAT and firewall will detect these packets as TCP packets on the channel that initialized the connection. The receiver side will then remove the extra fields and recover the packets to their original content. The proposed work involves adding two modules, one at the client and the other at the video streaming server. The proposed work also avoids any modification to the NAT or the RTP protocol itself.

Keywords- NAT Traversal; Video Streaming; RTP; TCP; UDP; Windows OS.
Abstract— This paper presents a novel method that exploits the strength features of two streaming protocols (Real-time Transport Protocol (RTP) and Hypertext Transfer Protocol (HTTP)) to overcome the Network Address Translation (NAT) and firewall traversal problem. The proposed solution is able to bypass the RTP over all kinds of NATs (including symmetric NATs) by adding extra fields to the RTP/UDP packet at transport layer in the sender side. The NAT and firewall will detect these packets as TCP packets on the channel that initialized the connection. The receiver side will then remove the extra fields and recover the packets to their original content. The proposed work involves adding two modules, one at the client and the other at the video streaming server. The proposed work also avoids any modification to the NAT or the RTP protocol itself.

Keywords- NAT Traversal; Video Streaming; RTP; TCP; UDP; Windows OS.

More info:

Published by: ijcsis on Oct 10, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less

11/18/2013

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 2010
 
Nat Traversal for Video Streaming Applications
 Abstract
 — 
This paper presents a novel method that exploits thestrength features of two streaming protocols (Real-timeTransport Protocol (RTP) and Hypertext Transfer Protocol(HTTP)) to overcome the Network Address Translation (NAT)and firewall traversal problem. The proposed solution is able tobypass the RTP over all kinds of NATs (including symmetricNATs) by adding extra fields to the RTP/UDP packet attransport layer in the sender side. The NAT and firewall willdetect these packets as TCP packets on the channel thatinitialized the connection. The receiver side will then remove theextra fields and recover the packets to their original content. Theproposed work involves adding two modules, one at the clientand the other at the video streaming server. The proposed workalso avoids any modification to the NAT or the RTP protocolitself.
 Keywords- NAT Traversal; Video Streaming; RTP; TCP; UDP;Windows OS.
I.
 
I
NTRODUCTION
 Video streaming is considering one of the famoustechnologies which is used today. It provides the ability toplayback video files remotely through computer networks.The demand for this technology is rapidly increasing due towide spread of Internet and increasing of the network bandwidth[1]There are two main application layer protocols that are usedfor video streaming: RTP and HTTP. Although the RTPprotocol is originally developed for video streaming and theHTTP protocol is originally developed for browsing, whichhas many weakness points when dealing with video streaming,HTTP protocol is still used and more spread than RTP whenused with video streaming. This is due to the simplicity of using the HTTP protocol and in order to avoid the problemsthat faced the RTP protocol.While HTTP protocol uses one TCP port at the transportlayer, RTP can use many ports. RTP can use UDPs or TCPsports at the transport layer depending on how much the packetpath is suffered from packet loss [2]. In low packets lossenvironment, the use of RTP over UDP protocol is preferable,since in media streaming, the small ratio of packets loss betterthan packets delay. Hence, the higher reliability of the TCP isnot desired[3]. UDP/RTP has also the multicasting feature andhas 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 fromdiscontinuity because the need to reordering,acknowledgement, and retransmission and the packets,whereas RTP/UDP can suffer from dropping the packets bysome filters (firewalls) in the Internet Service Provider (ISPs).Some ISPs drop UDP packets because they are connectionlesshence unfair against TCP traffic. They also need highprocessing power and memory to ensure security [4]. But themain issue that can occur is when using the RTP with theNetwork Address Translation (NAT). NAT drops anyRTP/UDP or RTP/TCP packets that are initialized from theoutside (Internet) when incoming to the end-systems (behindthe NAT).The NAT is a technology that permits many computers onthe same network to share a public Internet Protocol (IP)address for accessing the Internet. The main reason behind thewide spread of using the NAT is the limited number of theavailable IPv4 addresses [5].The use of RTP/UDP or RTP/TCP video streaming isstarted with a TCP connection that is established by a requestfrom the client to the server, after initial negotiation using theRTSP protocol on the same established TCP channel, theserver starts video streaming through UDP or TCP portsinitialized from the server not through the establishedRTSP/TCP channel [2].The NAT permits to pass the outgoing connections requestsproduced from a host behind the NAT into the outsidenetwork (like Internet) [6], however it does not permit to passany connection request produced from the outside network (like Internet) to any host behind the NAT [7]. This is becausethe translation table entry is constructed only when a client(behind the NAT) initializes a request to connect to a host onthe outside network (Internet) [8], [9]. If the initialized requestcomes from a host outside the network of the NAT into theinside network, the NAT cannot identify the destination hostfor this request and the connection between the outside hostand the inside one cannot be occur [8], [10]. Regarding to theRTP/UDP video streaming, the NAT will not allow the UDPvideo streaming channels to pass to the client behind the NAT,since the RTP/UDP channels are initially established from theserver (on the Internet).Considering the RTP weakness points, the HTTP protocol,is the preferable choice for video streaming. However, HTTPprotocol also has known weakness points: the user can sufferOmar A. IbraheemNational Advanced IPv6 Centre of Excellence (NAv6)Universiti Sains Malaysia11800, Penang, MALAYSIAibraheem@nav6.usm.myOmr.aldabagh@gmail.comOmer Amer AbouabdallaNational Advanced IPv6 CentreExcellence (NAv6)Universiti Sains Malaysia11800, Penang, MALAYSIAomar@nav6.usm.mySureswaran RamadassNational Advanced IPv6 CentreExcellence (NAv6)Universiti Sains Malaysia11800, Penang, MALAYSIAsures@nav6.usm.my
41http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 2010
 
from quality reduction and playback discontinuity due to theprobing behaviour of TCP protocol. This can also cause anoscillating throughput and slow recovery of the packet rate.In contrast, the UDP protocol provides a mean to keep thedesired sending rate constant. It also keeps streaming smoothand eliminates the TCP related processing.
 
This paper presents a novel method to utilize the benefits of both TCP and UDP. The proposed method enables the videostreaming to traverse the NAT by converting each RTP/UDPand RTCP/UDP packet into fake TCP packet just before beingsent (at data link layer) by adding a fabricated TCP headerbefore each UDP video streaming packet and making thenecessary modifications to the length and checksums fields.These fabricated TCP packets will pass the NAT, sincethey will be transmitted on the channel (IP, TCP port) thatfirstly initialized (RTSP/TCP channel) by the client behind theNAT. In this paper, this channel is called the
active channel
.The receiver, on the other side has to restore the originalUDP packet before being processed by the correspondingtransport layer. The restoration is based on a specific signature.In order to restore the packets, every fabricated TCP packethas to have a known signature. Depending on that signature,the receiver will restore the original packet. All of theprevious 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 proposedmethodology and algorithm are presented. In section IV, theexperiments of the implemented proposed method and itsdiscussions are described. In section V, the evaluation of theproposed method and comparisons between the proposedmethod and the existing technologies are presented. The paperis concluded in section VI.II.
 
R
ELATED WORK
 Limited to our knowledge, no many similar works arepresented. However, [4] present a method to overcome theRTP/UDP issues by putting a proxy server between the clientand the streaming server (at the global network). The proxyreceives a HTTP request (TCP) from the client and translatesit to a RTSP/RTP request to the server (TCP+UDP). Theproxy has two different connections (one for the client and theother for the streaming serve). The main function of the proxyis to translate the HTTP streaming protocol into RTSP/RTPstreaming protocol. This can overcome the NAT problem dueto that the HTTP request (TCP) is initialized by the client andthe reply will pass through the same TCP port. However athird device is needed. In addition it is still using theconstraints 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 thereare too many operations in order to convert a completeapplication protocol into another one. Beside, this methodloses the real time property that is needed for end to endcommunication because all the packets must be forwarded atthe proxy server.III.
 
P
ROPOSED
M
ETHODOLOGY
 In this work, both the client and the server are assumed toconvert all the RTP/UDP streaming packets into fabricatedTCP packets that can be sent to the other side using the
activechannel
.This fabrication process which is implemented forWindows Operating System (OS) requires a full control of theincoming/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 themanipulation of the packets in any TCP/IP protocol suite fromlevel above the TCP/IP driver layer.To overcome the inaccessibility issue, a hooking techniqueis used in order to control the (frame/packet) at the point thatlinks between the protocol driver and the NIC card(s), whichis represented by the Network Driver Interface Specification(NDIS).Hooking is a technique that can convert the calling of oneoperating system function into a new one that in turn calls theold one. The new function can do extra job before moving theexecution to the old one. This can be done without the needfor the source code of the old one [11].The proposed modules is implemented and run in windowsuser mode. When the module can hook the NDIS, it canmonitor, control, add, and modify the NDISincoming/outgoing packets easily.The NDIS-Hooking driver inserts itself between TCP/IPand all of the adapters that bind with it as shown in figure (1).
Figure 1. NDIS hooking driver with relation to user mode
1
 
When TCP/IP sends a packet, it reaches the NDIS-Hookingdriver (as a frame) before sending to the adapter. Likewise,packets that are to be indicated (received) on TCP/IP will goto the NDIS-Hooking driver first.
1
http://www.ntkernel.com/w&p.php?id=7
42http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 6, September 2010
 
The fabricated TCP header is inserted/deleted in the data link frame, this means that the original RTP/UDP protocol is usedwithout modification. Nonetheless the fabricated packets canstill bypass the NAT as authenticated ones.
Figure 2. Proposed frame structure
As these extra bytes (fabricated TCP header) will be addedwhen the packet is in the data link layer, this may cause thepacket to exceed the Maximum Transfer Unit (MTU) of thenetwork. Since, no packet must exceed the Maximum TransferUnit (MTU) of the network [12], [13]
, therefore, the sender’s
MTU must be decreased by length of the fabricated TCPheader length (20 bytes).The whole proposed system is composed of two mainmodules. The first module resides on the streaming clientwhile 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 provides away to access the frame at the data link layer. This componentaccesses the frames in data link layer which is in the kernelmode and moves it into the user mode and vice versa.A component that finds the required frame based on itscontent. This component extracts the specified packets fromthe 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. Thiscomponent changes the predetermined packets depending thesending direction (send/receive). In sending, the componentchanges the RTP/UDP packet into fabricated TCP packet. Inreceiving, the component restores the fabricated TCP packetinto its original RTP/UDP content. This component also re-computes length and checksums.
 A.
 
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. Thereare two possible scenarios:Incoming packet: If the packet is coming from thestreaming server, then the program will look for the TCP thatcontains an RTSP packet. If this RTSP packet contains both
the client’s and server’s streaming ports, then record thisconnection’s information into an array. This is happened
normally at the setup phase of the RTSP connection. Later(when the video streaming data is transfered), the client willcheck every TCP packet if it contains a specified signature. If this signature is raised (in the TCP header), this mean that thisTCP packet is fabricated and it contains the originalRTP/UDP packet. The program will remove the TCP headerand recomputed the UDP and IP checksums. All these stepsare done before sending the packet to the rest of TCP/IPprotocol stack Outgoing packet: If the packet is outgoing to the streamingserver and the outgoing packet was a RTP/UDP packet, theninsert a new fabricated TCP header before the UDP header.This fabricated TCP header contains the TCP connectioninformation taken from the appropriate record from an array
containing all streaming connections’ details. This TCP
header also contains a specified signature that has to beenrecognized from the streaming server in order to return thepacket back to its original RTP/UDP packet. This operationalso needs to recompute the checksums. All these steps aredone before sending the packet to the adapter. Figure 4 showsthe flowchart of client side module.
Start
Access the Datalink layer (inkernel mode)Wait untilpacket eventoccurs
Packet eventMove the packetto the user modeapplicationYes
Incoming OrOutgoing
NoTCP or UDPIncomingTCP withsignatureReturn back to itsoriginal UDPpacketYESTCP or UDPOutgoingNormal orStreaming UDPUDP
Add a fabricatedTCP header withsignature
StreamingMove the packetto the kernel modeMove the packetto the kernel mode
Send packet tothe physicallayerSend packet tothe upperlayer
New streamingconnection
Get connection’s
informationNormalUDPNORecompute thechecksumsRecompute thechecksumsNoYesTCPTCP
Figure 4. Flowchart of the client side module
43http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->