Nat crossing based on stun, turn, ice protocol

stun, turn, Ice Protocol overview

Stun,turn,ice is a protocol group proposed by IETF to deal with Nat crossing problem in VoIP network.

Stun can handle most NAT problems, turn is an enhanced version of the stun protocol, designed to deal with symmetric NAT problems, while ice is the product of comprehensive stun and turn, a framework for combining stun and turn structures, It provides reliable VoIP or video call configuration as well as media transmission through a SIP supply/answer model for endpoints to Exchange multiple candidate IP addresses and ports (such as private addresses and turn server addresses).

This framework can solve the problem of NAT and firewall in the media transmission in VoIP, and the signaling crossing needs another set of mechanisms, in the past people put forward a variety of programs to deal with NAT problems, but there are limitations, the use of ice completely solved these problems, Another feature of ice can be detected by a certain mechanism of NAT type, which determines what scheme to deal with, for example, for most calls, the media may be directly with the peer-to-peer approach, and some scenarios may be no matter what NAT type is Media-relay way, This method increases end-to-end latency and packet loss probability.

Stun and turn are client/server protocols, the white is the client to the server to their own public network address and port, and then placed in their own invite request SDP message body and the invite of the "OK SDP" message body.

Most SIP clients and servers support the stun protocol, so there are some drawbacks.

http://blog.csdn.net/perfectpdl/article/details/7636067

Deep analysis of TURN protocol

To sum up:

If a host is behind a NAT, it cannot communicate with other hosts in a particular environment. In this case, it is necessary for this host to communicate through a forwarding host. There is a protocol called Turn that allows the host to communicate with other hosts by forwarding. The turn protocol differs from other forwarding protocols in that it allows clients to communicate with multiple hosts with a forwarding address.

1 Introduction

A host behind the NAT may communicate with other hosts located behind the NAT. To achieve the goal, a hole can be used to find a path, but not by forwarding.

When both hosts are located after symmetric NAT, the hole-piercing technology may fail.

The turn protocol allows a host after NAT to request another host to forward. The client can transfer to the other end through the server. And you can control how forwarding ends. This client obtains an IP port pair on the server, also known as the forwarding port address.

The server forwards the packet to the client when it sends a packet to the forwarding port address. When a client sends a packet to the server, the server forwards the packet to the client corresponding to the address of the forwarding port.

A client using the turn protocol must have some way to tell each other the forwarding address and know the IP port address pair of each communication partner.

If the turn protocol is used as an ice protocol, its forwarding IP port pair and other partner IP port pairs are included in the ice candidate information. For example, if turn and ice are used for media transmission by SIP, the SIP takes the information of the ice candidate into the SIP message body in the form of a session protocol. If the turn and ICE protocols are used in other session protocols, then "MUSIC-ICE-NONSIP" will provide some functionality that the session protocol must implement.

Although the application of the turn server makes it possible to communicate with two hosts after Nat, this is too expensive for turn servers. As a result, the turn server is used only when direct communication cannot be performed. When the client and the partner through the ICE protocol to determine the communication path, the ICE protocol will first through the hole to find a direct path to the two-party communication, only when this path can not find the use of Turn server.

Turn was originally designed to support SIP-based multimedia session signal transmission.

Turn is designed as part of the ice for Nat crossing.

Turn is an extended version of stun. In most cases, the turn message is a stun-formatted message. Readers of this document should be familiar with the stun protocol.

2 roughly look at the operation

This section gives a preview of the turn operation.

In a traditional configuration, the turn client is connected to a private network and is connected to a shared network through one or more Nats. In this no common network, is the turn server. The other is the companion client that the turn client wants to connect to. These companions may be behind the NAT or not behind the NAT. The client uses this server as a forwarding to send packets to other partners, and receives packets from peer machines by forwarding.

Figure 1 shows a classic process. In this diagram, the turn client and the turn server are split by Nat. The client is in the private network and the service is in the public network. NAT is a symmetric address port.

The client calls the same server via an IP address port called the client host transport address.

The client transmits turn messages from its host transport address to a Turnserver port address.

Since this client is located behind the NAT, the server sees the packets returned from the client based on the client's transport address at Nat. The transfer address of this NAT is called Server-reflexivetransport.

This client uses the turn command to perform a allocation operation on the server. Allocation is a data structure in the server. This data structure contains the assigned relayed transport address. Partners can use this relayed transportaddress to let the server forward messages to the client.

As soon as this allocation is created, the client can send the application data to the server and indicate that the data will be sent to that partner. This allows the server to forward data island-related partners. The application data sent by the client is contained in the turn message.

On the server side, the application takes the data out of the turn message. and send the data to the partner in the form of UDP. Conversely, the partner can also send the application data to the server-side forwarding transfer address as UDP. The server resolves the data from the turn message and sends the data to the client specified by the partner. Because the turn message always contains the address of the companion that the client will send. The client can communicate with only one allocation and multiple peer.

When peer is located in Nat, the client must identify peer instead of host transportaddress through the peer Server-reflexive transport address. For example, the image above, sending data to Peera, the client must identify 192.0.2.150:32102 rather than 192.168.100.2:49582.

Each allocation belongs to a single client. And there is an exact one relayed transport address. This way when a package arrives at the relayed transport address, the server knows which client the data will go to.

Each allocation belongs to only one client. However, a client can have multiple allocation.

2.1 Transport

TURN, as defined in this specification, always communicates through UDP in both the server and peer. However also TCP permits.

2.2 Allocation

In order to create a allocation on the service side. The client sends a allocate request server, and the server responds with a allocate sucessresponse, which contains a allocated relayed. The client can include attributes into this allocate request, which can describe the type of allocation (for example, allocation life).

Once relayed transport address is assigned. The client must ensure that the allocation is in active condition. To achieve the goal, the client must periodically send an update request to the server. The frequency of the update is related to the allocation life. The default allocation life is 10 minutes. This value is often enough to be updated in time.

http://my.oschina.net/u/220943/blog/38158