Skip to main content

11. Channels

Channels provide a way for the client and server to send application data using ChannelData messages, which have less overhead than Send and Data indications.

The ChannelData message (see Section 11.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows:

  • 0x0000 through 0x3FFF: These values can never be used for channel numbers.

  • 0x4000 through 0x7FFF: These values are the allowed channel numbers (16,383 possible values).

  • 0x8000 through 0xFFFF: These values are reserved for future use.

Because of this division, ChannelData messages can be distinguished from STUN-formatted messages (e.g., Allocate request, Send indication, etc.) by examining the first two bits of the message:

  • 0b00: STUN-formatted message (because the first two bits of a STUN-formatted message are always zero).

  • 0b01: ChannelData message (because the channel number is the first field in a ChannelData message and channel numbers are in the range 0x4000 - 0x7FFF).

  • 0b10: Reserved

  • 0b11: Reserved

The reserved values may be used in the future to extend the range of channel numbers. Thus, an implementation MUST NOT assume that a TURN message always starts with a 0 bit.

Channel bindings are always initiated by the client. The client may bind a channel to a peer at any time during the lifetime of the allocation. The client may bind a channel to a peer before exchanging data with it, or after exchanging data (using Send and Data indications) for some time, or may choose never to bind a channel to it. The client may also bind channels to some peers while not binding channels to other peers.

Channel bindings are specific to an allocation, so a channel number or peer transport address used in the channel binding of one allocation has no impact on their use in the channel binding of a different allocation. If an allocation expires, all its channel bindings expire with it.

A channel binding consists of:

  • A channel number.

  • A transport address (of the peer).

  • A time-to-expiry timer.

Within the context of an allocation, a channel binding is uniquely identified either by the channel number or by the peer's transport address. Thus, the same channel cannot be bound to two different transport addresses, nor can the same transport address be bound to two different channels.

Channel bindings last for 10 minutes unless refreshed. Refreshing the binding (by the server receiving a ChannelBind request rebinding the channel to the same peer) resets the time-to-expiry timer back to 10 minutes.

When a channel binding expires, the channel becomes unbound. Once unbound, the channel number can be bound to a different transport address, and the transport address can be bound to a different channel number. To prevent race conditions, the client MUST wait 5 minutes after a channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number.

When binding a channel to a peer, the client SHOULD be prepared to receive ChannelData messages on the channel from the server as soon as it has sent the ChannelBind request. Over UDP, the client MAY receive ChannelData messages from the server before receiving the ChannelBind success response.

In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data or use Send indications until the channel binding is confirmed.

11.1. Sending a ChannelBind Request​

A ChannelBind transaction is used to create or refresh a channel binding. A ChannelBind transaction also creates or refreshes the permission towards the peer (see Section 8).

To initiate the ChannelBind transaction, the client forms a ChannelBind request. The channel to be bound is specified in the CHANNEL-NUMBER attribute, and the peer's transport address is specified in the XOR-PEER-ADDRESS attribute. Section 11.2 describes the restrictions on these attributes.

Rebinding a channel to the same transport address that it is already bound to provides a way to refresh the channel binding and the corresponding permission without sending data to the peer. Note, however, that permissions need to be refreshed more frequently than channels.

11.2. Receiving a ChannelBind Request​

When the server receives a ChannelBind request, it processes it as per Section 4 plus the specific rules mentioned here.

The server checks the following:

  • The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute.

  • The channel number is in the range 0x4000 through 0x7FFE (inclusive).

  • The channel number is not currently bound to a different transport address (same transport address is OK).

  • The transport address is not currently bound to a different channel number.

If any of these tests fail, the server replies with a 400 (Bad Request) error.

The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error.

If the request is valid, but the server is unable to fulfill the request due to some capacity limit or similar, the server replies with a 508 (Insufficient Capacity) error.

Otherwise, the server replies with a ChannelBind success response. There are no required attributes in a successful ChannelBind response.

If the server can satisfy the request, then the server creates or refreshes the channel binding using the channel number in the CHANNEL-NUMBER attribute and the transport address in the XOR-PEER-ADDRESS attribute. The server also installs or refreshes the permission for the IP address in the XOR-PEER-ADDRESS attribute as described in Section 8.

NOTE: The server need not do anything special to implement idempotency of ChannelBind requests over UDP using the "stateless stack approach". Retransmitted ChannelBind requests will simply refresh the channel binding and the corresponding permission. Furthermore, the client must wait 5 minutes before binding a previously bound channel number or peer address to a different channel, eliminating the possibility that the transaction would initially fail but succeed on a retransmission.

11.3. Receiving a ChannelBind Response​

When the client receives a ChannelBind success response, it updates its data structures to record that the channel binding is now active. It also updates its data structures to record that the corresponding permission has been installed or refreshed.

If the client receives a ChannelBind failure response that indicates that the channel information is out of sync between the client and the server (e.g., an unexpected 400 "Bad Request" response), then it is RECOMMENDED that the client immediately delete the allocation and start afresh with a new allocation.

11.4. The ChannelData Message​

The ChannelData message is used to carry application data between the client and the server. It has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Channel Number        |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                       Application Data                        /
/                                                               /
|                                                               |
|                               +-------------------------------+
|                               |
+-------------------------------+

The Channel Number field specifies the channel number on which the data is traveling, and thus the address of the peer that is sending or is to receive the data.

The Length field specifies the length in bytes of the Application Data field (i.e., it does not include the size of the ChannelData header). Note that 0 is a valid length.

The Application Data field carries the data the client is trying to send to the peer, or that the peer is sending to the client.

11.5. Sending a ChannelData Message​

Once a client has bound a channel to a peer, then when the client has data to send to that peer, it may use either a ChannelData message or a Send indication; that is, the client is not obligated to use the channel when it exists and is free to use either message type when sending data to the peer. The server, on the other hand, MUST use the ChannelData message if a channel has been bound to the peer.

The fields of the ChannelData message are filled in as described in Section 11.4.

Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4. Over UDP, the padding is not required but MAY be included.

The ChannelData message is then sent on the 5-tuple associated with the allocation.

11.6. Receiving a ChannelData Message​

The receiver of a ChannelData message uses the first two bits to distinguish it from a STUN-formatted message, as described above. If the message uses a value in the reserved range (0x8000 through 0xFFFF), then the message is silently discarded.

If the ChannelData message is received in a UDP datagram, and if the UDP datagram is too short to contain the length of data that the ChannelData message claims to carry (i.e., the value of the UDP header length field is less than the ChannelData header length field + 4 + 8), then the message is silently discarded.

If the ChannelData message is received over TCP or TLS-over-TCP, then the actual length of the ChannelData message is as described in Section 11.5.

If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded.

On the client, it is RECOMMENDED that the client discard the ChannelData message if the client believes there is not an active permission towards the peer. On the server, the receipt of a ChannelData message MUST NOT refresh either the channel binding or the permission towards the peer.

On the server, if no errors are detected, the server relays the application data to the peer by forming a UDP datagram as follows:

  • The source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived.

  • The destination transport address is the transport address to which the channel is bound.

  • The data following the UDP header is the contents of the data field of the ChannelData message.

The resulting UDP datagram is then sent to the peer. Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent.

11.7. Relaying Data from the Peer​

When the server receives a UDP datagram on the relayed transport address associated with an allocation, it processes it as described in Section 10.3. If that section indicates that a ChannelData message should be sent (because there is a channel bound to the peer that sent the UDP datagram), then the server forms and sends a ChannelData message as described in Section 11.5.

Last updated on