The access token is issued by the authorization server. OAuth 2.0 does not
impose any limitation on the length of the access token but if path MTU is
unknown, then STUN messages over IPv4 would need to be less than 548 bytes
(Section 7.1 of [RFC5389]). The access token length needs to be restricted
to fit within the maximum STUN message size. Note that the self-contained
token is opaque to the client, and the client MUST NOT examine the token.
The ACCESS-TOKEN attribute is a comprehension-required attribute (see
Section 15 from [RFC5389]).
This attribute is used by clients to request the allocation of an IPv4 and
IPv6 address type from a server. It is encoded in the same way as the
REQUESTED-ADDRESS-FAMILY attribute; The ADDITIONAL-ADDRESS-FAMILY attribute
MAY be present in the Allocate request. The attribute value of 0x02 (IPv6
address) is the only valid value in Allocate request.
The Address attribute indicates a reflexive transport address
of the client. It consists of an 8-bit address family and a 16-bit
port, followed by a fixed-length value representing the IP address.
If the address family is IPv4, the address MUST be 32 bits. If the
address family is IPv6, the address MUST be 128 bits. All fields
must be in network byte order.
The CHANNEL-NUMBER attribute contains the number of the channel. The
value portion of this attribute is 4 bytes long and consists of a
16-bit unsigned integer followed by a two-octet RFFU (Reserved For
Future Use) field, which MUST be set to 0 on transmission and MUST be
ignored on reception.
The DATA attribute is present in all Send and Data indications. The
value portion of this attribute is variable length and consists of
the application data (that is, the data that would immediately follow
the UDP header if the data was been sent directly between the client
and the peer). If the length of this attribute is not a multiple of
4, then padding must be added after this attribute.
This attribute is used by the client to request that the server set the DF
(Don’t Fragment) bit in the IP header when relaying the application data
onward to the peer and for determining the server capability in Allocate
requests. This attribute has no value part, and thus, the attribute length
field is 0.
The ERROR-CODE attribute is used in error response messages. It
contains a numeric error code value in the range of 300 to 699 plus a
textual reason phrase encoded in UTF-8 RFC3629; it is also
consistent in its code assignments and semantics with SIP RFC3261
and HTTP RFC7231. The reason phrase is meant for diagnostic
purposes and can be anything appropriate for the error code.
Recommended reason phrases for the defined error codes are included
in the IANA registry for error codes. The reason phrase MUST be a
UTF-8-encoded RFC3629 sequence of fewer than 128 characters (which
can be as long as 509 bytes when encoding them or 763 bytes when
decoding them).
The ERROR-CODE attribute is used in error response messages. It
contains a numeric error code value in the range of 300 to 699 plus a
textual reason phrase encoded in UTF-8 RFC3629; it is also
consistent in its code assignments and semantics with SIP RFC3261
and HTTP RFC7231. The reason phrase is meant for diagnostic
purposes and can be anything appropriate for the error code.
Recommended reason phrases for the defined error codes are included
in the IANA registry for error codes. The reason phrase MUST be a
UTF-8-encoded RFC3629 sequence of fewer than 128 characters (which
can be as long as 509 bytes when encoding them or 763 bytes when
decoding them).
This attribute allows the client to request that the port in the relayed
transport address be even, and (optionally) that the server reserve the
next-higher port number. The value portion of this attribute is 1 byte
long.
The ICE-CONTROLLED attribute is present in a Binding request. The
attribute indicates that the client believes it is currently in the
controlled role. The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number. The
number is used for solving role conflicts, when it is referred to as
the “tiebreaker value”. An ICE agent MUST use the same number for
all Binding requests, for all streams, within an ICE session, unless
it has received a 487 response, in which case it MUST change the
number. The agent MAY change the number when an ICE restart occurs.
The ICE-CONTROLLING attribute is present in a Binding request. The
attribute indicates that the client believes it is currently in the
controlling role. The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number. As
for the ICE-CONTROLLED attribute, the number is used for solving role
conflicts. An agent MUST use the same number for all Binding
requests, for all streams, within an ICE session, unless it has
received a 487 response, in which case it MUST change the number.
The agent MAY change the number when an ICE restart occurs.
The LIFETIME attribute represents the duration for which the server
will maintain an allocation in the absence of a refresh. The value
portion of this attribute is 4-bytes long and consists of a 32-bit
unsigned integral value representing the number of seconds remaining
until expiration.
The MAPPED-ADDRESS attribute indicates a reflexive transport address
of the client. It consists of an 8-bit address family and a 16-bit
port, followed by a fixed-length value representing the IP address.
If the address family is IPv4, the address MUST be 32 bits. If the
address family is IPv6, the address MUST be 128 bits. All fields
must be in network byte order.
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 RFC2104 of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA-1 hash, the HMAC will
be 20 bytes.
The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in
RFC3261. Note that this means that the NONCE attribute will not
contain the actual surrounding quote characters. The NONCE attribute
MUST be fewer than 128 characters (which can be as long as 509 bytes
when encoding them and a long as 763 bytes when decoding them). See
Section 5.4 of RFC7616 for guidance on selection of nonce values in
a server.
The PRIORITY attribute indicates the priority that is to be
associated with a peer-reflexive candidate, if one will be discovered
by this check. It is a 32-bit unsigned integer and has an attribute
value of 0x0024.
The REALM attribute may be present in requests and responses. It
contains text that meets the grammar for “realm-value” as described
in RFC3261 but without the double quotes and their surrounding
whitespace. That is, it is an unquoted realm-value (and is therefore
a sequence of qdtext or quoted-pair). It MUST be a UTF-8-encoded
RFC3629 sequence of fewer than 128 characters (which can be as long
as 509 bytes when encoding them and as long as 763 bytes when
decoding them) and MUST have been processed using the OpaqueString
profile RFC8265.
The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request the
allocation of a specific address type from a server. The following is the
format of the REQUESTED-ADDRESS-FAMILY attribute. Note that TURN attributes
are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit length,
and a variable-length value.
The RESERVATION-TOKEN attribute contains a token that uniquely identifies a
relayed transport address being held in reserve by the server. The server
includes this attribute in a success response to tell the client about the
token, and the client includes this attribute in a subsequent Allocate
request to request the server use that relayed transport address for the
allocation.
The RESPONSE-ORIGIN attribute is inserted by the server and indicates
the source IP address and port the response was sent from. It is
useful for detecting double NAT configurations. It is only present
in Binding Responses.
The SOFTWARE attribute contains a textual description of the software
being used by the agent sending the message. It is used by clients
and servers. Its value SHOULD include manufacturer and version
number. The attribute has no impact on operation of the protocol and
serves only as a tool for diagnostic and debugging purposes. The
value of SOFTWARE is variable length. It MUST be a UTF-8-encoded
RFC3629 sequence of fewer than 128 characters (which can be as long
as 509 when encoding them and as long as 763 bytes when decoding
them).
This attribute is used by the STUN server to inform the client that
it supports third-party authorization. This attribute value contains
the STUN server name. The authorization server may have tie ups with
multiple STUN servers and vice versa, so the client MUST provide the
STUN server name to the authorization server so that it can select
the appropriate keying material to generate the self-contained token.
If the authorization server does not have tie up with the STUN
server, then it returns an error to the client. If the client does
not support or is not capable of doing third-party authorization,
then it defaults to first-party authentication. The
THIRD-PARTY-AUTHORIZATION attribute is a comprehension-optional
attribute (see Section 15 from [RFC5389]). If the client is able to
comprehend THIRD-PARTY-AUTHORIZATION, it MUST ensure that third-party
authorization takes precedence over first-party authentication (as
explained in Section 10 of [RFC5389]).
The USE-CANDIDATE attribute indicates that the candidate pair
resulting from this check will be used for transmission of data. The
attribute has no content (the Length field of the attribute is zero);
it serves as a flag. It has an attribute value of 0x0025..
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS
attribute, except that the reflexive transport address is obfuscated
through the XOR function.
The XOR-PEER-ADDRESS specifies the address and port of the peer as
seen from the TURN server. (For example, the peer’s server-reflexive
transport address if the peer is behind a NAT.) It is encoded in the
same way as XOR-MAPPED-ADDRESS RFC5389.
The XOR-RELAYED-ADDRESS is present in Allocate responses. It
specifies the address and port that the server allocated to the
client. It is encoded in the same way as XOR-MAPPED-ADDRESS
RFC5389.