Table of contents
Create a forward authorization request
Mechanism of TURN transfer data
I. Introduction
The full name of TURN is Traversal Using Relays around NAT, which is an extension of the STUN protocol, mainly adding the relay function. If two hosts are behind different NATs, and they want to communicate with each other, either through P2P traversal, or through a machine with a public IP to transfer, the TURN server provides a relay function to help Communication between hosts.
2. Working principle of TURN
The above figure shows the schematic diagram of TURN Client communicating with Peer A and Peer B through TURN Server.
The address of TURN Server listening is 192.0.2.15:3478, the intranet address of TURN Client is 10.1.1.2:49721, the address after NAT mapping is 192.0.2.1:7000, the intranet address of Peer A is 192.168.100.2:49582, The address after NAT mapping is 192.0.2.150:32102, and the intranet address of Peer B is 192.0.2.210:49191.
The work of the TURN protocol is divided into two phases: distribution and forwarding.
distribute
If the TURN Client wants to use the relay function, it first needs to request a relay address from the TURN Server. After obtaining the relay address, the TURN Client can distribute the address to the peers who want to communicate. Peers who know the relay address can Communicate with the TURN Client through this address (the TURN Client needs to create a forwarding authorization request before communication).
TURN Server requires each request to carry a certificate for authentication. If the request sent does not carry a certificate, the server will return an error of ERROR-CODE 401 Unauthenticated. After receiving the 401 error code, the client needs to re-initiate the Allocate request and carry the certificate info(username, password).
After the Allocate request is successful, the server will respond to the Allocate success resp message, which carries XOR-RELAYED-ADDRESS (assigned relay address), XOR-MAPPED-ADDRESS (address after TURN Client NAT mapping) and LIFETIME (validity period, in seconds) ).
childcare
After the Allocate responds successfully, the response message will carry the LIFETIME attribute, which indicates the lifetime, that is, if the TURN Client does not send a keep-alive message, the Allocation will expire after the LIFETIME time expires (in seconds).
The keep-alive message in the TURN protocol is Refresh, which can not only be used to keep the Allocation alive, but also explicitly delete the Allocation. There is a LIFETIME attribute in the Refresh message. If you want the Allocation to continue to be valid, the value of LIFETIME in the Refresh request message should be set to be greater than 0. If you do not need to use the Allocation, then the LIFETIME should be filled with 0. It is generally recommended that if you want to continue If Allocation is used, a Refresh message can be sent about 1 minute before the failure.
Forward
Create a forward authorization request
After the relay address is allocated, not any host sending data to the relay address will be forwarded to the TURN Client, and it is not possible for the TURN Client to directly send data to other Peers through the relay address. Before this, it needs to be created by the TURN Client Forward the authorization request (CreatePermission Req).
CreatePermission Req carries the XOR-PEER-ADDRESS attribute, which requests the server if the TURN Client sends data to the TURN Server through the Send method (XOR-PEER-ADDRESS in the Send method is the address created by CreatePermission Req), and the TURN Server should forward the data To XOR-PEER-ADDRESS, and if the Peer address sends data to the relay address, TURN Server will also forward the data to TURN Client, as shown in the Peer A process in the above figure.
If TURN Client wants to send data to Peer B through Send, but Peer B's address does not request the server through CreatePermission Req, then TURN Server will directly discard the data after receiving it, otherwise Peer B cannot directly send data to TURN Client through the relay address .
Mechanism of TURN transfer data
1. Send/Data
If TURN Client wants to send data to Peer, it needs to send Send Indication message to TURN Server, which contains two attributes (XOR-PEER-ADDRESS, DATA), XOR-PEER-ADDRESS is the address mapped by Peer NAT, and DATA is For the data to be forwarded, the TURN Server sends the original data to the address mapped by Peer NAT after receiving the Send Indication message.
If the Peer wants to send a message to the TURN Client, it only needs to send the data directly to the relay address of the TURN Client. After receiving the data, the TURN Server encapsulates it into a STUN Message (the Message Type is Data Indication, the data is stored in the DATA attribute, and the Peer's address to the XOR-PEER-ADDRESS attribute, so that the TURN Client knows which Peer sent the data).
2. ChannelData
To send and receive data through Send/Data, each time it needs to be encapsulated into STUN Message (Message Type, Length, Cookie, Transaction ID, Attributes...), TURN also provides ChannelData message to transfer data, which is relatively Higher payload rate than Send/Data.
As shown below, before using ChannelData message, you need to perform ChannelBind Req first. ChannelBind Req has two important attribute values (CHANNEL-NUMBER, XOR-PEER-ADDRESS), that is, to bind the Channel Number with the Peer address. If If the binding is successful, the server returns ChannelBind succ resp. Note: the value range of Channel Number is 0x4000~0x7FFE.
Use the message format of ChannelData to send data. If TURN Client wants to send data to Peer, then encapsulate the data according to the following message format, fill in the Channel Number bound to the Peer address, and store the data in Application Data. If it is Peer, send it to TURN Client sends data, and TURN Server obtains the Channel Number corresponding to the Peer address, and then sends the encapsulated data according to the following ChannelData message.
Length indicates the length of Application Data.
