Application of Stun/turn/ice protocol in peer-to sip (II.)

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

Application of Stun/turn/ice protocol in peer-to sip (II.)

1 description

2 dozen holes and the concept of crossing ... 1

3 hitting holes and crossing ... 2

4 using the STUN Series Protocol traversal features ... 2

5 Stun/turn/ice The relationship of the agreement ... 3

6 Stun protocol (RFC 5389) 3

6.1 Why the STUN protocol is used ... 3

How the 6.2 stun protocol works ... 4

7 Turn protocol ... 4

7.1 Why the Turn protocol is used ... 4

How the 7.2 Turn protocol works ... 5

7.2.1 Allocate request ... 5

7.2.2 Relay Port Message Forwarding ... 6

7.2.2.1 A's relay port accepts messages from other clients ... 6

7.2.2.2 a response message The original path returns ... 6

7.2.2.3 thinking ... 7

7.2.3 Refresh Request ... 7

7.2.4 stun Port of the keepalive ... 8

7.2.5 relay forwarding When adding stun headers (send and data requests) ... 8

7.2.6 the need to use the Turn protocol ... 9

8 Ice Protocol ... 9

8.1 Hole-Punching principle ... 9

8.2 Ice's hole-punching ... 10

8.3 ICE's 4-time handshake ... 11

8.4 Ice extension's binding message ... 12

8.5 REGULAR nomination and aggressive nomination. 12

8.6 Peer reflexive. 13

8.6.1 Peer reflexive candidates concept ... 13

The discovery of 8.6.2 Peer reflexive candidates ... 13

8.6.2.1 when the communication between the two sides at different levels of NAT under the situation ... 14

8.6.2.2 is related to the type of NAT ... 15

8.6.2.3 Other situations ... 16

Peer reflexive in the 8.6.2.4 public network. ... 16

9 Application of ice in SIP ... 16

9.1 The two sides of the call collect 3 sets of addresses respectively ... 17

9.1 A sends invite to B. ... 18

9.2 B gives a back 100, 101, 180. ... 18

9.3 B to a back to the OK. ... 19

9.4 A to B ack ... 19

Last week wrote the 1th, 2, 3, 4, 5, today 6, 7 also finished, also summed up the 8th and 9th, ready to be released in two times.

For 1th, 2, 3, 4, 5 please see: Application of Stun/turn/ice protocol in peer sip (i.)

The book was last, and now begins.

--------------------------------------------------------------------------------------------------------------- ------------

6 Stun protocol (RFC 5389)6.1 Why the STUN protocol is used

The first clear concept is that the stun protocol does not have the ability to traverse, it simply provides a reflection address for traversal (Server reflexive addresses). At the time of communication between the two sides, the destination address of both sides can be the reflection address of each other, but the reflection address cannot pass through the success (NAT type is symmetric type), must use turn.

The stun protocol referred to in this article refers to the RFC (5389), where RFC (5389) has removed the ability to detect NAT types (RFC (3489) defines the ability to detect NAT types), and the stun protocol mainly has 2 functions:

• Let a client behind a NAT get its own public address (reflection address, Server reflexive addresses), which is done by sending a binding request to the service side, which returns a success response message. The success response message contains a property called Xor-mapped-address, which is the value of the reflected address after an XOR

• When ice (interactive connection is established) is used to detect the connectivity of both parties. This feature also sends a binding message to the other client, and the caller should request implementation. It is important to note that the binding message at ice interaction is different from the binding message described in 1. ICE has added several new properties to extend the binding message: priority, Use-candidate, ice-controlled, ice-controlling. This expanded binding message will only be used in the ice probe.

How the 6.2 stun protocol works

A. the client is used to get its own extranet address (reflection address, Server reflexive addresses) as shown in :

A) client A sends a binding request to stun port (green section of the figure)

b) The stun server receives a binding request from client A, which can get the source address and Port of the request (the address and port are NAT-mapped), and the address and port are recorded as server reflexive addresses.

c) The stun server sends a response response, and in the response response, the server reflexive address is filled with the xor-mapped-address attribute.

d) After client a receives the response of the stun server, it knows its own extranet address (reflection address, server reflexive addresses).

B. On ice (interactive connection establishment) is a connectivity probe for both parties.

Detailed introduction to the ice hole detection

7 Turn Protocol7.1 Why the Turn protocol is used

As mentioned earlier, the turn protocol is an effective complement to the stun protocol, and turn is used when the use of a reflection address (Server reflexive addresses) traversal fails.

Simply put, the turn protocol uses a brokered approach to communicate with clients that are located in two different Nat. The turn protocol assigns a public address to each client connected to the server (relayed address), which is specifically brokered for that client. relayed

This method is one way to implement client communication that is located after two different NAT (other ways are peer-by-side).

The advantage of this approach is that both client communication can be implemented in this way regardless of the type of NAT (NAT type: Full cone, address limit cone, port-limited cone, symmetric).

There are two drawbacks to this approach:

1. The first is, if the traffic on both ends of the data transmission is too large (such as the transmission of audio and video between the client), then each packet must be forwarded by the turn server, then the loss of data and the increase of transmission delay;
2. The second is the cost issue, if the communication between every two clients to go through turn forwarding, then after the client reached a certain size (100,000 million), the need to set up a large number of turn servers. This is not affordable in cost. That's why you use the peer-to-peer approach. It is important to note that the two sides can do point-to-point direct communication, not because of their point-to-point communication after packet loss and delay problem can be resolved (peer-to-peer and may have a larger packet loss), but the cost problem.

So this way of using the turn protocol will only be used in the communication between the two sides of the content of the data less than the situation.

How the 7.2 Turn protocol works

This section describes the general workings of the turn protocol, which has a certain discrepancy with RFC 5766, and how it works to see RFC 5766 with less effort. This section describes the CreatePermission, Channelbind operations that are not addressed in RFC 5766.

7.2.1 Allocate Request

The client sends a allocate request to the stun server, allowing the stun server to open a relay port for the a user.

A) Client A sends a allocate request to stun port (green section of the figure)

b) The stun server receives a allocate request from client A, and the server sees the allocate request, assigning a port to a based on the relay port assignment policy.

c) The server sends a response successful response. Include the Xor-relayed-address property in the response. The attribute value is the XOR result of the relay port of a.

D) When the client receives the response, it knows its relay address. The relay address is a public address, can be seen as client A on the public network of a proxy, any want to contact a client, as long as the data sent to a relay address can be, the specific forwarding principle see the next section.

7.2.2 forwarding of Relay port messages

Anyone who wants to contact client A will need to know the relay address of client A.

7.2.2.1 A's relay port accepts messages from other clients

As shown: Because Client A is behind NAT, other clients cannot establish direct communication with a. However, client a requested a port (medium: A relay port) on the stun server, and the other client wants to communicate with a, so that only the information is sent to the "a relay port", and the stun server sends the information received from the relay port to a through stun.

7.2.2.2 A response message is returned from the original path

A when replying to messages from other clients, it is returned by the original path.

7.2.2.3 Thinking

Why doesn't the 1.STUN server forward the data directly from a relay port to a (as shown)? Instead of sending it from the stun port?

2. Client A's response message is returned at the original path, a response message is sent to the stun port, and then through the relay port A is issued. So how does A's relay port know where it's going to send the data?

Please look at 7.2.4 and 7.2.5.

7.2.3 Refresh Request

The relay address assigned by the stun server to client A has a valid length of time, which can be 30 seconds or 1 minutes or 10 minutes. If the client needs the stun server to open the port for it, it needs to periodically send a request to the stun server with the time remaining to flush the relay port.

In the standard turn (RFC 5766) protocol, client A sends a allocate request to the stun server, and the stun server adds a "LifeTime" property in the response message that represents the relay's survival time. The client needs to call the refresh request periodically during the lifetime of the relay, refresh the remaining time after the server receives the refresh request, and when the Lifetime property in the refresh request is 0 o'clock, the client actively requests that the relay address be closed.

7.2.4 Stun Port KeepAlive

Because UDP is used for communication with the stun server, in order to maintain a long connection, the client is required to periodically send a heartbeat packet to the stun port of the stun server.

The purpose of the periodic heartbeat packet is to make the NAT device valid for the reflection address of client A (Server reflexive addresses). The data sent from stun port can be reached through a's reflected address. This is not understood here to see "The classification of NAT types and the role of Nat".

The first problem in 7.2.2.3 is explained here, because client A does not live with relay port, and because of the NAT nature, the data is forwarded directly to a by relay port, and the NAT is discarded, so a is not received. So the data must be sent through the stun port of the stun server.

7.2.5 relay forwarding When adding stun headers (send and data requests)

Merging 7.2.2.1 and 7.2.2.2 together is:

As shown in the "B" initiative to send a message: "Hello", a response "Hi" process.

Sequence number 1, 2, 3, 4, 5 is the sending request of B (blue arrow direction);

Sequence Number 6, 7, 8, 9, 10 is a response, the original way back (green Arrow direction).

Note: During the 1, 2 stages of the "Hello" sending process, the data sent is the bare UDP data. In the 4, 5 process, is the stun protocol wrapped "Hello", called the data indication.

Also in the "HI" Send process, 6, 7 stage is the stun protocol wrapped "Hi", called Send indication,9, 10 is the bare UDP data.

In the 4, 5 phase, because the data is forwarded from STUN port, in order to enable client A to know which client this package is sent, so the STUN protocol to "Hello" has been repackaged, the main thing is to add a xor-peer-address attribute, The process of wrapping the bare data into the stun protocol is called adding the stun header. The content of xor-peer-address is the reflection address of client B (Server reflexive addresses).

In the 6, 7 phase, A's response to the original way back, in order to be able to let a relay port to know which client to end, so also added the stun header for "Hi", but also added the Xor-peer-address property, the content is the reflection address of client B (Server Reflexive Address). The relay port of a will know the destination address of "Hi".

The 3rd stage is the process of receiving data from a relay port, adding the stun header, and finally from stun port.

The 8th stage is: Receive data with stun header from stun port, remove the stun header, and finally the process from the relay port of a.

The second question of 7.2.2.3 is explained here.

Client B actively sends information to A's interactive flow as shown, so what is client A's interaction process of sending information to client B, can you draw it?

To know that client A is actively sending messages to client B, the message should be sent to client B's relay port.

7.2.6 the need to use the Turn protocol

Do you have to use the turn protocol to implement a message relay? The answer is, of course, negative.

The turn agreement is just a recognized, standard protocol. We can certainly implement our own protocol, but there are already some implementations of the standard TURN protocol (such as Pjproject, which implements stun, TURN, ICE, SIP), why don't we take it?

In the process of using it, it will certainly make certain changes to the standards that have been achieved. But it's not a big relationship, so we can do what we care about.

Application of Stun/turn/ice protocol in peer-to sip (II.)