Intro

Let’s immediately pick up where we left off in Part 1: TURN Server. The Allocate Request and Response I mentioned there is in fact part of the STUN protocol. Again, me liking to decode acronyms: Session Traversal Utilities for NAT. It’s defined in RFC5389 and is the protocol used by TURN and ICE.

Allocations and Terminology

So what do these messages contain? First of all – authentication, we don’t want to hand out allocations to anyone. Second, in addition to the TURN address and port that was allocated, the IP address and port that the TURN server sees as the source (typically the public IP of the device doing the NATing). This is how it looks like for our endpoint A:

It is important to note at this stage that this process happens for each media stream. Therefore normally you will see many allocations. What is also pretty important for our further discussion on ICE is the terminology used:

All of these are transport addresses – a combination of an IP address and port.
Host – the endpoint itself
Server Reflexive – public side of NAT corresponding to the host, XOR-MAPPED-ADDRESS in the Allocate Success Response
Relayed – TURN server allocation, XOR-RELAYED-ADDRESS in the Allocate Success Response
Peer – the endpoint we’re communicating with, XOR-PEER-ADDRESS in the Create Permission Request below

Permissions

Next come permissions that are vital for ensuring the solution is even more secure. What do I mean by that? Well, theoretically anyone who knows the public IP of the TURN server and the port that was allocated for a particular client, can send RTP packets to it. We definitely want to avoid that. So what does the client do? It uses another STUN request – CreatePermission containing the Peer address that is allowed to send packets to the TURN server. Without a successfull permission response, the RTP packets will not be relayed.

Data Flows

Last piece I want to talk about in relation to STUN is the two options of data flow. By data I mean the RTP packets.
One is called Send & Data Indications, the other one is Channel Data.

In simple words, Send & Data Indications are STUN packets carrying the RTP payload. They are used between the client and the TURN server. Send Indication is for outgoing traffic while Data Indication for incoming. The RTP packets then flow freely between the TURN server and the Peer.

Channel Data also carries the RTP stream but it requires an additional step of Channel Binding (another STUN message). This is also a different method of creating permissions.

ChannelData is being used for both outgoing and incoming traffic. It only carries the Channel Number and the RTP payload.

You can compare Channel Data to compressed RTP. The STUN overhead is much lower with this method as you actually only send the Channel Number instead of all the STUN headers (if you’re interested it’s 32 bytes vs 4 bytes per packet).

Summary

There you have it, a crash course on STUN. Next comes ICE where we’ll combine TURN and STUN to establish an optimal media path.