Application of stun/turn/ice protocol in P2P SIP (2)

1 Description

2 Concepts of drilling and traversing... 1

3. Drilling and traversing in P2P... 2

4. Features of protocol traversal using stun series... 2

5 relationship between stun/turn/ice protocols... 3

6 STUN Protocol (RFC 5389) 3

6.1 Why stun protocol is used... 3

6.2 how stun works... 4

7 TURN protocol... 4

7.1 why the TURN protocol is used... 4

7.2 how the TURN protocol works... 5

7.2.1 allocate request... 5

7.2.2 relay port message forwarding... 6

7.2.2.1 the relay port of a accepts messages from other clients... 6

7.2.2.2 A's original response message... 6

7.2.2.3 thinking... 7

7.2.3 refresh request... 7

7.2.4 retention of the stun port... 8

7.2.5 Add the stun header (send and Data Request) when forwarding relay... 8

7.2.6 necessity of using the TURN protocol... 9

8 Ice protocol... 9

8.1 Drilling Principle... 9

8.2 ice holes... 10

4 handshakes of 8.3 ice holes... 11

8.4 ice extended binding message... 12

8.5 regular nomination and aggressive nomination... 12

8.6 peer reflexive. 13

8.6.1 concepts of peer reflexive candidates... 13

8.6.2 discovery of peer reflexive candidates... 13

8.6.2.1 when the communication parties are at different levels of Nat... 14

8.6.2.2 related to the NAT type... 15

8.6.2.3 other cases... 16

8.6.2.4 peer reflexive in Internet p2p... 16

9 Application of ice in SIP... 16

9.1 both parties collect three groups of addresses ...... 17

9.1 A sends invite to B... 18

9.2 B returns 100, 101, 180 to a... 18

9.3 B returns 200 OK to a... 19

9.4 A returns ack to B... 19

 

Last week I wrote 1st, 2, 3, 4, and 5. Today I have finished writing 6 and 7, and I also summarized 8th and 9th. I am going to release them again in two minutes.

For details about 1st, 2, 3, 4, and 5, refer to the application of stun/turn/ice protocol in P2P SIP (1)

This book is now available.

Bytes ---------------------------------------------------------------------------------------------------------------------------

6 STUN Protocol (RFC 5389) 6.1 Why stun protocol is used

The first thing to be clear is that the STUN Protocol does not have the ability to traverse. It only provides the server reflexive address for traversal ). When both parties communicate, the destination addresses of the two parties can be the reflection addresses of the other party, but the reflection addresses cannot be crossed successfully (when the NAT type is symmetric ), turn is required.

The STUN Protocol mentioned in this Article refers to RFC (5389). RFC (5389) has removed the NAT type detection capability (RFC (3489) defines the NAT type detection capability ), the STUN Protocol has two main functions:

• This function allows a client located after Nat to obtain its own public address (reflection address, server reflexive address). By sending a binding request to the server, the server returns a success Response Message. A success response message contains an attribute called a XOR-MAPPED-ADDRESS whose value is the value of an exclusive or exclusive reflection address.

 

• It is used to test the connectivity of both parties when an ice (interactive connection established) is established. This function is also implemented by sending a binding message to the client of the other party in response to the request. Note that the binding message during ice interaction is different from the binding message mentioned in 1. Ice adds several new attributes to extend binding messages: priority, use-Candidate, ice-controlled, and ice-controlling. This extended binding message is only used for ice detection.

6.2 how stun works

A.The client is used to obtain its own Internet address (Reflection address, server reflexive address), As shown in:

A) Client A sends a binding request to the stun port (green in the figure)

B)The stun server receives the Binding Request from client a. It can obtain the source address and port of the request (the address and port are Nat mapped ), mark the address and port as the server reflexive address.

C) The stun server sends the response, and in the response carries the server reflexive address through an exclusive or post-filled XOR-MAPPED-ADDRESS attribute.

D) after Client A receives the response from the stun server, it will know its own Internet address (reflection address, server reflexive address ).

 

B.In ice (Interactive connection creation)Yes, used for connectivity detection between the two parties.

Detailed introduction to ice hole Detection

7. Why is the turn protocol used in turn 7.1?

As mentioned above, the TURN protocol is an effective supplement to the STUN Protocol. It is used only when the reflection address (server reflexive address) Traversal method fails.

To put it simply, The Turn protocol uses a transit method to implement communication between two clients with different NAT addresses. The TURN protocol assigns a public address (relayed address) to each client connected to the server. The relayed address is dedicated to sending messages to the client.

This method is used to implement communication between two clients with different NAT addresses (other methods include P2P ).

This method has the following advantages: No matter what type of NAT is (NAT can be divided into full taper, address restriction cone, port restriction cone, and symmetric type ), both clients can communicate with each other in this way.

This method has two drawbacks:

1. First, if the data transmitted between the two ends of the communication is too large (for example, audio and video are transmitted between clients), then each data packet must be forwarded by the turn server, this will lead to data loss and an increase in transmission latency;
2. Second, there is a cost problem. If the communication between each two clients is forwarded by a turn, a large number of turn servers need to be set up after the client reaches a certain scale (more than 100,000 million. This is unacceptable in terms of cost. That's why P2P is used. One thing to note is that both parties can perform point-to-point direct communication, not because packet loss and latency problems can be solved after point-to-point communication between them (P2P may also cause large packet loss ), it is a cost issue.

Therefore, this transfer method can only be used when there is a small amount of data in the communication and interaction between the two parties.

7.2 how the TURN protocol works

This section describes the general working principle of the turn protocol, which is different from RFC 5766. If you understand the working principle, then you can get twice the result with half the effort. This section does not cover the createpermission and channelbind operations mentioned in RFC 5766.

7.2.1 allocate request

The client sends an allocate request to the stun server so that the stun Server opens a relay port for user.

 

A) Client A sends the allocate request to the stun port (green in the figure)

B)The stun server receives the allocate request from Client A. When the server sees the request as allocate, it assigns a port to a according to the relay port allocation policy.

C) the server sends a successful response to the response. Contains XOR-RELAYED-ADDRESS properties in this response. The attribute value is the XOR of the relay port of.

D) after the client receives the response, it will know its own relay address. This relay address is a public address and can be considered as a proxy of Client A on the public network. Any client that wants to contact a can send data to the relay address of Client, for detailed forwarding principles, see the next section.

7.2.2 relay port message forwarding

Anyone who wants to contact client a only needs to know the relay address of Client.

7.2.2.1 the relay port of a accepts messages from other clients

 

As shown in: Because Client A is located after Nat, other clients cannot establish direct communication with client. However, Client A has applied for a port (medium: A's relay port) on the stun server. If other clients want to communicate with A, they only need to send the information to "A's relay port ", the stun server sends the information received from the relay port through the stun port to.

7.2.2.2 A's original Response Message

When a responds to messages sent from other clients, it is returned through the original path.

 

 

7.2.2.3 Thoughts

1. Why does the stun server not forward data directly from the relay port of A to a (as shown in )? Do I have to send messages from the stun port?

2. When the Response Message of Client A is returned from the original path, the Response Message of A is first sent to the stun port and then sent through the relay port of. So how does a's relay port know where to send data?

 

See 7.2.4 and 7.2.5.

7.2.3 refresh request

The relay address allocated by the stun server to Client A has a certain validity period, which may be 30 seconds, 1 minute, or dozens of minutes. If the client needs the stun server to enable this port for it all the time, it needs to regularly send a request to the stun server, and the request uses the time remaining to refresh the relay port.

In the standard turn (RFC 5766) protocol, client a sends an allocate request to the stun server. The stun Server adds a "Lifetime" attribute to the response message, this attribute indicates the relay survival time. The client needs to periodically call the refresh request within the relay survival period. After receiving the refresh request, the server refreshes the remaining time. When the lifetime attribute in the refresh request is 0, this indicates that the relay address is disabled by the client.

7.2.4 retention of the stun Port

The communication with the stun server uses UDP. To maintain a persistent connection, the client periodically sends a heartbeat packet to the stun port of the stun server.

The objective of a periodic heartbeat packet is to make the NAT device valid for the server reflexive address of Client. This allows the data sent from the stun port to a through the reflection address of. If you do not understand this, refer to "nat category and Nat role ".

As explained here, the first problem In 7.2.2.3 is that client A is not active with relay port, and because of the characteristics of NAT, when data is directly forwarded to a through relay port, nat is discarded directly, so a cannot receive it. Therefore, data must be sent through the stun port of the stun server.

7.2.5 Add the stun header (send and data requests) during relay forwarding)

The combination of 7.2.2.1 and 7.2.2.2 is:

 

 

As shown in, B actively sends a message to a: "hello", and a responds to "hi.

The numbers 1, 2, 3, 4, and 5 send requests to B (in the direction of the Blue Arrow );

If the numbers 6, 7, 8, 9, and 10 are responses to A, the original path is returned (Green Arrow direction ).

Note: during the "hello" transmission process, the data sent in stages 1 and 2 is raw UDP data. In the process 4 and 5, it is the "hello" packaged by the STUN Protocol, which is called data indication.

In the same process of sending "hi", the 6 and 7 stages are the "hi" encapsulated by the STUN Protocol, which is called "Send indication", and 9 and 10 are the raw UDP data.

In stages 4 and 5, as data is forwarded from the stun port, in order to let Client A know which client sent the package, STUN Protocol on the "hello" re-packaging, the most important is to add a XOR-PEER-ADDRESS attribute, from the raw data packaging into the STUN Protocol process, we call it added the stun header. The content of the XOR-PEER-ADDRESS is the reflection address (server reflexive address) of client B ).

In stages 6 and 7, A's response to the original path is returned. In order to let a's relay port know which client is finally sent to, a stun header is added for "hi, the XOR-PEER-ADDRESS property is also added with the reflection address (server reflexive address) of client B ). In this way, the relay port of a knows the target address of "hi.

The 3rd phase is the process of receiving data from the relay port of A, adding the stun header, and finally sending data from the stun port.

The 8th phase is the process of receiving data with the stun header from the stun port, removing the stun header, and finally sending data from the relay port of.

The second question of 7.2.2.3 is explained here.

 

Shows the interaction process in which client B actively sends information to A. What is the interaction process in which client a actively sends information to client B? Can you draw it out?

To know that client a actively sends a message to client B, send the message to the relay port of client B ..

7.2.6 necessity of using the TURN protocol

Do I have to use the TURN protocol to transfer messages? Of course, the answer is no.

The TURN protocol is only a accepted and standard protocol. Of course we can implement our own protocol, but some people have already implemented the standard TURN protocol (such as pjproject, which implements stun, turn, ice, and SIP ), why don't we just use it?

In the process of using it, some changes will be made to the standards that have been implemented. However, this does not matter much. We can simply implement the functions we are concerned about.

 

This article is original and reprinted with the following content:

Name: Application of stun/turn/ice protocol in P2P SIP (2)

Mr. heavy snow

Link: http://www.cnblogs.com/ishangs/p/3816689.html