4 Protocol Examples
In the following figure, a TURN client is behind a NAT and is communicating with a peer using Session Initiation Protocol (SIP), as described in [RFC3261]. The protocol client and peer attempt to establish a media flow between them. Because the protocol client is behind a NAT, it allocates a public transport address which it includes in the Session Description Protocol (SDP) of the SIP INVITE sent to the peer, as described in [RFC4566]. The details of the SIP message exchange are not included in the example; only the basic message flow used to communicate the public address of the protocol client and peer to each other is included.
The TURN client has a private transport address of 10.0.0.1 that it uses for network connectivity. The NAT on the protocol client's private network has a public transport address of 192.0.2.10. The TURN server has a public transport address of 192.0.2.20. The peer is connected directly to the Internet and has a transport address of 192.0.2.30. The following figure shows the flow of TURN messages used to allocate a public transport address.
Figure 3: Example of TURN message flow
The protocol client sends an initial Allocate request message to the TURN server. This request message does not include a Message Integrity attribute and begins the digest authentication exchange specified in section 3.1.12. The source address for the request is 10.0.0.1:12345 and the destination address is 192.0.2.20:3478. The request passes through the NAT, which allocates a new port, 54321, and creates a binding between the internal address 10.0.0.1:12345 and 192.0.2.10:54321. The NAT translates the source address to 192.0.2.10:54321 and sends the request on to the TURN server. The TURN server checks the request for a Message Integrity attribute. Because the Message Integrity attribute is missing, the TURN server challenges the protocol client for credentials by responding with an Allocate error response or with an error response code of 401 Unauthorized. The TURN server sends the response message to the protocol client, through the NAT binding, with the NAT translating the destination address.
When the protocol client receives the Allocate error response message, it retries the Allocate request using the Username, Nonce, and Realm attributes specified in section 3.1.12. The request is sent through the NAT binding to the TURN server, with the NAT translating the source address discussed in Step 1. The TURN server validates and authenticates the new Allocate request and allocates transport address 192.0.2.20: 55667. It forms an Allocate response message and includes the Mapped Address attribute with a value of 192.0.2.20:55667 and the XOR Mapped Address attribute with a value of 192.0.2.10:54321 XOR'd with the Transaction ID, as specified in section 184.108.40.206. The response is sent to the protocol client through the NAT binding, with the NAT again doing the required address translation.
The protocol client receives the Allocate response and uses the Mapped Address, 192.0.2.20:55667, in the SDP of the SIP INVITE to signal to the peer the address to send data to. The peer responds to the SIP INVITE with a SIP 200 OK and includes its address of 192.0.2.30:44556 in the SDP.
At this point, both the protocol client and the peer have a transport address that they can use to receive data. However, until the protocol client has set permission on the allocated port, the TURN server does not allow any data to be received on the allocated port. The following figure shows the messages used to set permissions on an allocated port and the subsequent data flow.
Figure 4: Using TURN messages to set permissions
Once the peer has the public transport address of the protocol client, it can start to send data. When the data arrives at the allocated port on the TURN server, the TURN server checks to see if the protocol client has permissions to receive data from the peer, 192.0.2.30:44556. Permissions are set when the protocol client does a Send request to the TURN server with the peer's transport address in the Destination Address attribute. Because the protocol client has not sent a Send request, the TURN server drops the data.
Once the protocol client has the public transport address of the peer, it can start to send data. It does this by sending a Send request message to the TURN server with the data to be sent in the Data attribute and the address of the peer, 192.0.2.30:44556, in the Destination Address attribute. The Send request is sent to the TURN server through the NAT binding. When the TURN server receives the Send request, it adds the peer's IPv4 address to the permissions list for the allocated address. It then forwards the data contained in the Data attribute on to the peer. The data is sent using the allocated address, 192.0.2.20:55667, as the source address and the address in the Destination Address attribute, 192.0.2.30:44556, as the destination address.
The peer again attempts to send data to the allocated address. The TURN server checks the permissions list and finds that the peer now has permissions to send data to the protocol client. The TURN server forwards the data to the protocol client using a Data Indication message, encapsulating the data in the Data attribute and identifying the peer as the source of the data by including a Remote Address attribute with the peer's address. The Data Indication message is sent to the protocol client through the NAT binding.
The protocol client is now ready to make the peer the active destination for all non-TURN encapsulated data. It sends a Set Active Destination request message to the TURN server with the peer's address in the Destination Address attribute. The request is sent to the TURN server through the NAT binding. When the TURN server receives the request, it identifies the peer as the active destination and sends a Set Active Destination response back to the protocol client.
Now that the protocol client has established the peer as the active destination, all non-TURN data sent by either the protocol client or the peer is relayed between the two with non-TURN message encapsulation. Only transport specific framing is required. This is a more efficient mechanism for relaying the data.