2.2.1 Message Header
All TURN messages consist of a 20 byte TURN header followed by 1 or more TURN attributes. The TURN attributes are type-length-value (TLV) encoded. The TURN message header is the same as the message header specified in [IETFDRAFT-STUN-02] section 10.1. All TURN messages begin with any necessary transport specific framing, as specified in section 2.1, followed by this header.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
00 |
Message Type |
Message Length |
||||||||||||||||||||||||||||||
|
Transaction ID (16 bytes) |
||||||||||||||||||||||||||||||||
Message Type (16 bits): The type of TURN message. The most significant two bits of this field MUST be set to zero so that TURN packets can be differentiated from other protocols. The TURN message types are specified in [IETFDRAFT-TURN-08] section 9.1. The TURN message types supported in this extension:
"0x0003": Allocate request
"0x0103": Allocate response
"0x0113": Allocate error response
"0x0004": Send request
"0x0115": Data Indication
"0x0006": Set Active Destination request
"0x0106": Set Active Destination response
"0x0116": Set Active Destination error response
The following TURN message types are not supported by this extension and the TURN server MUST NOT send them:
"0x0104": Send request response
"0x0114": Send request error response
In addition, this extension does not support the shared secret authentication mechanism. The following shared secret messages, specified in [RFC3489] section 11.1, MUST NOT be used by either the protocol client or TURN server:
"0x0002": Shared Secret request
"0x0102": Shared Secret response
"0x0112": Shared Secret error response
Message Length (16 bits): The length, in bytes, of the message. This length does not include the 20 byte header.
Transaction ID (16 bytes): A 128 bit identifier used to uniquely identify the TURN transaction. A Transaction ID, created by the protocol client and used in a request message, is echoed from the TURN server back to the protocol client in the subsequent response or error response message. The protocol client MUST choose a new Transaction ID for each new transaction. A new Transaction ID SHOULD be uniformly and randomly distributed between 0 and 2^128 -1. If the protocol client is retransmitting a request message, it MUST use the same Transaction ID as it used in the original request message.