Application of STUN/TURN/ICE protocol in P2P SIP (I)

1 Description

This article describes in detail the P2P SIP telephone process based on the STUN series protocol, which involves the interaction of SIP signaling, the principles of P2P, and Protocol interaction of STUN, TURN, and ICE.

The interaction between service units mentioned in this article uses UDP, which does not involve TCP holes and other TCP-related operations.

This document assumes that neither party has firewall restrictions on the Protocol and port.

This article does not involve publishing and searching client resources.

This article applies to readers who have a certain degree of knowledge, such as understanding the different types and characteristics of NAT devices, basic concepts of STUN/TURN/ICE protocols, and the interaction process of SIP protocols.

This article strives to be rigorous, but there are inevitable omissions. Please forgive me and welcome to criticize and correct me.

This article is divided into four parts:

The first part explains the concepts of traversal and penetration and the features of the STUN series protocol traversal.

The second part describes the working principle and functions of the STUN and TURN protocols. It describes in detail the allocation of relay ports, the receipt and transmission of messages, and the addition and removal of STUN headers.

The third part is the working principle and function of the ICE protocol. It introduces in detail the Drilling Principle of ICE, two drilling modes, and the concept and discovery process of Peer Reflexive.

The fourth part is the application of ICE in P2P SIP. It describes in detail the process of SIP signaling interaction and media establishment.

2 Concepts of holes and traversing

Some people think of it as a concept. In fact, this is also harmless. It is good to avoid ambiguity when talking with others. Strictly speaking, it is a hole first and then a cross.

Due to the characteristics of NAT (see the characteristics of different types of NAT), it is impossible for an external host to directly establish a connection to an intranet host. To realize the interaction between the external host and the Intranet host, "I (internal host) First holes in my own NAT device so that you (external host) the data can pass through this hole ".

When we open the computer, connect to the network, and open several different websites, the penetration and penetration are always happening. When you open www.sina.com, you create a hole in your own NAT. This hole only allows data on port 80 of www.sina.com to be crossed back. Without your first hole, sina cannot send messages to you.

Remember a concept at all times. The goal is to let the other Party's data come over.

3. Drilling and traversing in P2P

Since the real-time penetration and penetration are both happening, why is the concept of penetration and traversal seldom mentioned in network programming of the client/server model, but it is repeatedly mentioned in P2P communication?

First, in network programming of the cs model, servers are all set up on the public network, and the server side does not need to be punched in (the server side does not need to be punched out on the client side, so the client data can also come over ), the client can send a request to the server.

Second, when the client sends a request to the server, the client's holes and Server Response traversal are automatically implemented.

Finally, it is clear that in the cs model, the holes are in the single direction, that is, only the client holes are needed.

 

In P2P network programming, both parties A and B must act as both servers and clients. Therefore, the holes are implemented by both parties: A holes B in its own NAT so that B's data can come over; B holes A in its own NAT, allow A's data to come over;

We have to mention the concept of cross-hole drilling because the operation of both sides of AB must be completed by ourselves.

Understanding the point that "holes are made by both parties in P2P communication" means understanding half of ICE.

4. Features of protocol traversal using STUN Series

After you know several types of NAT and the limits of each type, you can solve these problems to achieve NAT traversal.

The easiest thing to think about is whether or not we can make some effort on NAT so that it can identify my own protocol, so as not to limit my unique protocol. This is the original intention of ALG. ALG (Application Layer Gateway) has two functions: one is to modify the Intranet address of the related fields in the "recognized" protocol as the Internet address; the other is, allow self-known protocols to penetrate directly without holes;

It can be considered that the capability of ALG is a plug-in of NAT. When plug-ins of the protocol type are inserted, NAT can identify the types of protocols and perform related operations on the corresponding types of protocols. Common applications include FTP, DNS, ICMP, and SIP. In VOIP, if ALG is used, direct media communication between both parties can be implemented. However, NAT must support SIP, which is not suitable for applications like skype.

There is also a mature traversal technology: UPnP. Its idea is a bit similar to that of ALG, and it is also done on NAT. When an intranet host starts the UPnP program, a "ing port" is generated on the NAT server and the port of the UPnP program is mapped one by one, and will not be recycled. For external messages, as long as they are sent to the "ing port", they are directly sent to the Intranet UPnP program. For example, we usually use Xunlei and dianjing. This method does not require holes, but the disadvantage is that it requires applications, operating systems, and NAT to support UPnP, which is also not applicable to skype applications.

The biggest advantage of using STUN/TURN/ICE is to make full use of the features of NAT. You can achieve traversal without the support of the operating system or changing the existing NAT device.

The last point to note is that there are no bad technologies and only unsuitable technologies.

5 relationship between STUN/TURN/ICE protocols

To put it simply,STUNFor P2PCommunicationBy providing the reflection Address (Server Reflexive Address) capability, both parties can perform P2P communication, but depending on the NAT type, this method has the probability of failure: for example, both parties are symmetric NAT or one side is symmetric, and the other side is port restricted.

Because of the possibility of failure, if you rely solely on the reflection address provided by the STUN Protocol, You need to first detect the NAT type of both parties. If you find that the NAT is symmetric, you will not be able to crack the hole, instead, it is directly transferred. Currently, the network type is complex, and the STUN Protocol removes the NAT type judgment capability in 5389, because more and more practices have found that in multi-layer NAT, type detection is not always effective. When using ICE, you do not need to detect the NAT type in advance.

STUN also provides support for ICE (Binding extension ).

TURNThe purpose of the agreement is to ensure that both parties can communicate with each other.It is a supplementary solution in the case that only the reflected address is known and the redirection fails-the use of relay can completely enable communication between the two parties, but it is no longer P2P, in addition, it is accompanied by the forwarding efficiency problem. However, this does not matter, because the purpose of this Agreement is to ensure that both parties can certainly communicate, and the loss of efficiency ensures the same-sex connection.

ICEThe purpose of the Protocol is to combine the above two solutions to find the most reasonable and cheapest feasible path through mutual probe packets sent by both parties. ICE first detects the Intranet address, then the reflection address provided by STUN, and finally the relay address of the TURN protocol. The ultimate goal is to find a path, and the Intranet address cannot use the reflection address, the reflected address does not work. In the end, use the relay address.

Generally, the current TURN server also implements the STUN Protocol, so it can be called the TURN server or STUN server.

If a server is a STUN server, it may be a pure STUN (RFC 5389) server or a TURN (RFC 5766) server, it may also be the server that both implement. The STUN servers mentioned in this article are all servers that implement STUN and TURN.

 

Not complete .... To be continued ....

 

This article is original and reprinted with the following content:

Name: Application of STUN/TURN/ICE protocol in P2P SIP (1)

Author: Mr. heavy snow

Link: http://www.cnblogs.com/ishang/p/3810382.html