WebRTC protocol stack
Figure 1 WebRTC stack
The full name of TURN is Traversal Using Relays around NAT, which is an extension of STUN/RFC5389, mainly adding the Relay function. As shown in Figure 1, the TURN protocol is an application layer protocol built on top of the UDP protocol. If a host is behind NAT, under certain conditions (NAT penetration failure) two hosts cannot communicate with each other. Under such conditions, it is necessary to use relay services to provide communication. The TURN protocol allows a host to use the relay service to transmit messages with the peer. The TURN protocol is also an integral part of the ICE (Interactive Connection Establishment) protocol, and can also be used alone. If TURN is used in the ICE protocol, the relay address will be used as a candidate, and ICE will evaluate among multiple candidates and select the most suitable communication address. Generally, relays have the lowest priority.
TURN differs from other relay protocols in that it allows clients to communicate with multiple different peers using the same relay address. As shown in Figure 2.
Figure 2 The same relay address communicates with multiple peers
How the Turn protocol works
The working principle of the Turn protocol mainly has three stages, also known as the three major mechanisms. Allocation, Relay and Channel.
1. Distribution mechanism:
If the client wants to use the relay function, it needs to apply for a relay address on the relay server. The client sends an allocation request (Allocate request) to the server, and the server opens a relay port for the user and then returns an allocation success response, which includes the allocated address.
Figure 3 Allocation Mechanism
a) Client A sends an Allocate request to STUN Port (the green part in the figure).
b) The STUN server receives the Allocate request from client A. When the server sees that it is an Allocate request, it allocates a port for A according to the relay port allocation policy.
c) The server sends a response success response. Include the XOR-RELAYED-ADDRESS attribute in the response. The attribute value is the relay port of A.
d) After the client receives the response, it knows its own relay address. The relay address is a public network address, which can be regarded as a proxy of client A on the public network. Any client who wants to contact A can just send data to A's relay address.
2. Forwarding mechanism:
Anyone who wants to contact client A only needs to know the relay address of client A.
There are two methods between client and peer to exchange data through the relay server. The first is to use a relay, and the second is to use a channel. Both methods somehow tell the server which peer should receive the data, and the server tells the client which peer the data comes from.
Relay Mechanism uses Send and Data instructions (Indication). Among them, the Send command is used to send data from the client to the server, and the Data command is used to send data from the server to the client.
Figure 4 Relay Mechanism
As shown in the figure above, B actively sends a message to A: "Hello", and A responds with "Hi".
a) Sequence numbers 1, 2, 3, 4, and 5 are the sending requests of B (direction of the blue arrow);
b) Sequence numbers 6, 7, 8, 9, and 10 are the responses of A, and return to the original route (direction of the green arrow).
c) In phases 1 and 2, bare UDP data is sent.
d) The third stage is: the process of receiving data from the relay port of A, adding the STUN header, and finally sending it from the STUN Port
e) In the process of 4 and 5, it is "Hello" wrapped by the STUN protocol, which is called Data indication. In order to let client A know which client sent the packet, the STUN protocol repackages "Hello", the most important thing is to add an XOR-PEER-ADDRESS attribute.
f) Phases 6 and 7 are "Hi" wrapped by the STUN protocol, called Send indication. In order to let the relay port of A know which client it will finally send to, a STUN header is added to "Hi", and the XOR-PEER-ADDRESS attribute is also added.
g) The eighth stage is the process of receiving data with STUN header from STUN Port, removing STUN header, and finally sending out from A's relay port.
h) 9 and 10 are bare UDP data.
3. Channel mechanism:
For some applications, such as VOIP, the additional 36-byte format information in the Send/Data Indication will increase the bandwidth pressure between the client and the server. To improve this situation, TURN provides a second method to allow client and peer to exchange data. This method uses another data packet format, ChannelData message, channel data message.
The ChannelData message does not use the STUN header, but uses a 4-byte header that contains a value called the channel number (channel number). Each channel number in use is bound to a specific peer, ie As a token of the peer's address.
To bind a channel to a peer, the client first sends a Channel Bind Request (ChannelBind Request) to the server, specifying an unbound channel number and the address information of the peer.
Figure 5 Channel Mechanism
As shown in Figure 5, the relay server encapsulates the data into a channel message and sends it to the peer. Comparing with Figure 4, it is actually replacing the indication of 4/5/6/7 with a channel message.
In audio and video transmission applications, using the channel mechanism will greatly reduce the length of the packet header, save bandwidth occupation, and improve transmission efficiency.
Turnser practice
Some government and enterprise customers will deploy firewalls to isolate the office environment from the external network, and their firewalls usually have very strict ip and port restrictions, so point-to-point transmission is basically impossible. At this time, the Turn protocol is a good choice. Turnserver has a fixed public network ip and a fixed port. You only need to open its whitelist on the firewall to build a communication channel.
Agora provides a good solution on the web side: WebProxy.
Figure 6 WebProxy
As shown in Figure 6, WebProxy includes two relay servers for signaling and data, and Turnserver is mainly responsible for the transmission of audio and video data. Turnserver opens a TCP port and a UDP port for the user. The user creates a relay address through these two ports, and the back-end service transmits data with the intranet user through the relay address.
postscript
The TURN protocol is a relatively important protocol in real-time audio and video, which can well ensure the availability, stability and efficiency of connections in real-time audio and video transmission. However, the TURN protocol has a high dependence on the server, and the server has a lot of pressure on the bandwidth and the cluster, so the TURN protocol is usually used as a part of the ICE protocol.
Introduction to the original WebRTC TURN protocol and practice of turnserver
★The business card at the end of the article can receive audio and video development learning materials for free, including (FFmpeg, webRTC, rtmp, hls, rtsp, ffplay, srs) and audio and video learning roadmaps, etc.
see below!