draft-ietf-avtcore-rfc5285-bis-01.txt   draft-ietf-avtcore-rfc5285-bis-02.txt 
AVTCore R. Even, Ed. AVTCore R. Even, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: RFC5285 (if approved) D. Singer Obsoletes: RFC5285 (if approved) D. Singer
Intended status: Standards Track Apple, Inc. Intended status: Standards Track Apple, Inc.
Expires: June 25, 2016 H. Desineni Expires: November 12, 2016 H. Desineni
December 23, 2015 May 11, 2016
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-01.txt draft-ietf-avtcore-rfc5285-bis-02.txt
Abstract Abstract
This document provides a general mechanism to use the header This document provides a general mechanism to use the header
extension feature of RTP (the Real-Time Transport Protocol). It extension feature of RTP (the Real-Time Transport Protocol). It
provides the option to use a small number of small extensions in each provides the option to use a small number of small extensions in each
RTP packet, where the universe of possible extensions is large and RTP packet, where the universe of possible extensions is large and
registration is de-centralized. The actual extensions in use in a registration is de-centralized. The actual extensions in use in a
session are signaled in the setup information for that session. session are signaled in the setup information for that session.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 25, 2016. This Internet-Draft will expire on November 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 30 skipping to change at page 3, line 30
3. Design Goals 3. Design Goals
The goal of this design is to provide a simple mechanism whereby The goal of this design is to provide a simple mechanism whereby
multiple identified extensions can be used in RTP packets, without multiple identified extensions can be used in RTP packets, without
the need for formal registration of those extensions but nonetheless the need for formal registration of those extensions but nonetheless
avoiding collision. avoiding collision.
This mechanism provides an alternative to the practice of burying This mechanism provides an alternative to the practice of burying
associated metadata into the media format bit stream. This has often associated metadata into the media format bit stream. This has often
been done in media data sent over fixed-bandwidth channels. Once been done in media data sent over fixed-bandwidth channels. Once
this is done, a decoder for the specific media format is required to this is done, a decoder for the specific media format needs to
extract the metadata. Also, depending on the media format, the extract the metadata. Also, depending on the media format, the
metadata may need to be added at the time of encoding the media so metadata can be added at the time of encoding the media so that the
that the bit-rate required for the metadata is taken into account. bit-rate used for the metadata is taken into account. But the
But the metadata may not be known at that time. Inserting metadata metadata can be unknown at that time. Inserting metadata at a later
at a later time can require a decode and re-encode to meet bit-rate time can cause a decode and re-encode to meet bit-rate requirements.
requirements.
In some cases, a more appropriate, higher-level mechanism may be In some cases, a more appropriate, higher-level mechanism can be
available, and if so, it should be used. For cases where a higher- available, and if so, it can be used. For cases where a higher-level
level mechanism is not available, it is better to provide a mechanism mechanism is not available, it is better to provide a mechanism at
at the RTP level than have the metadata be tied to a specific form of the RTP level than have the metadata be tied to a specific form of
media data. media data.
4. Packet Design 4. Packet Design
4.1. General 4.1. General
The following design is fit into the "header extension" of the RTP The following design is fit into the "header extension" of the RTP
extension, as described above. extension, as described above.
The presence and format of this header extension and its contents are The presence and format of this header extension and its contents are
negotiated or defined out-of-band, such as through signaling (see negotiated or defined out-of-band, such as through signaling (see
below for SDP signaling). The value defined for an RTP extension below for SDP signaling). The value defined for an RTP extension
(defined below for the one-byte and two-byte header forms) is only an (defined below for the one-byte and two-byte header forms) is only an
architectural constant (e.g., for use by network analyzers); it is architectural constant (e.g., for use by network analyzers); it is
the negotiation/definition (e.g., in SDP) that is the definitive the negotiation/definition (e.g., in SDP) that is the definitive
indication that this header extension is present. indication that this header extension is present.
This specification updates the requirement from the RTP specification This specification updates the requirement from the RTP specification
that the header extension "is designed so that the header extension that the header extension "is designed so that the header extension
may be ignored". To be specific, header extensions using this MAY be ignored". To be specific, header extensions using this
specification SHOULD be used for data that can safely be ignored by specification SHOULD be used for data that can safely be ignored by
the recipient without affecting interoperability, there may be the recipient without affecting interoperability, there can be
essential header extensions for interoperability and intermediaries essential header extensions for interoperability and intermediaries
should not remove such header extensions. Note that the support of SHOULD NOT remove such header extensions. Note that the support of
header extension as specified in this recommendation is negotiated. header extension as specified in this recommendation is negotiated.
RTP Header extensions MUST NOT be used when the presence of the RTP Header extensions MUST NOT be used when the presence of the
extension has changed the form or nature of the rest of the packet in extension has changed the form or nature of the rest of the packet in
a way that is not compatible with the way the stream is signaled a way that is not compatible with the way the stream is signaled
(e.g., as defined by the payload type). Valid examples might include (e.g., as defined by the payload type). Valid examples might include
metadata that is additional to the usual RTP information, e.g. Audio metadata that is additional to the usual RTP information, e.g. Audio
level from Client to mixer [RFC6464]. level from Client to mixer [RFC6464].
The RTP header extension is formed as a sequence of extension The RTP header extension is formed as a sequence of extension
elements, with possible padding. Each extension element has a local elements, with possible padding. Each extension element has a local
identifier and a length. The local identifiers may be mapped to a identifier and a length. The local identifiers MAY be mapped to a
larger namespace in the negotiation (e.g., session signaling). larger namespace in the negotiation (e.g., session signaling).
As is good network practice, data should only be transmitted when As is good network practice, data SHOULD only be transmitted when
needed. The RTP header extension should only be present in a packet needed. The RTP header extension SHOULD only be present in a packet
if that packet also contains one or more extension elements, as if that packet also contains one or more extension elements, as
defined here. An extension element should only be present in a defined here. An extension element SHOULD only be present in a
packet when needed; the signaling setup of extension elements packet when needed; the signaling setup of extension elements
indicates only that those elements may be present in some packets, indicates only that those elements can be present in some packets,
not that they are in fact present in all (or indeed, any) packets. not that they are in fact present in all (or indeed, any) packets.
Each extension element in a packet has a local identifier (ID) and a Each extension element in a packet has a local identifier (ID) and a
length. The local identifiers present in the stream MUST have been length. The local identifiers present in the stream MUST have been
negotiated or defined out-of-band. There are no static allocations negotiated or defined out-of-band. There are no static allocations
of local identifiers. Each distinct extension MUST have a unique ID. of local identifiers. Each distinct extension MUST have a unique ID.
The value 0 is reserved for padding and MUST NOT be used as a local The value 0 is reserved for padding and MUST NOT be used as a local
identifier. identifier.
There are two variants of the extension: one-byte and two-byte There are two variants of the extension: one-byte and two-byte
headers. Since it is expected that (a) the number of extensions in headers. Since it is expected that (a) the number of extensions in
any given RTP session is small and (b) the extensions themselves are any given RTP session is small and (b) the extensions themselves are
small, the one-byte header form is preferred and MUST be supported by small, the one-byte header form is preferred and MUST be supported by
all receivers. A stream MUST contain only one-byte or two-byte all receivers. A stream MUST contain only one-byte or two-byte
headers unless it is known that all recipients support mixing, either headers unless it is known that all recipients support mixing, either
by offer/answer negotiation (see section 6) or by out-of-band by offer/answer negotiation (see section 6) or by out-of-band
knowledge. One-byte and two-byte headers MUST NOT be mixed in a knowledge. One-byte and two-byte headers MUST NOT be mixed in a
single RTP packet. Transmitters SHOULD NOT use the two-byte form single RTP packet. Transmitters SHOULD NOT use the two-byte form
when all extensions are small enough for the one-byte header form. A when all extensions are small enough for the one-byte header form. A
transmitter may be aware that an intermediary may add RTP header transmitter MAY be aware that an intermediary may add RTP header
extensions in this case, the transmitter SHOULD use two-byte form. extensions in this case, the transmitter SHOULD use two-byte form.
A sequence of extension elements, possibly with padding, forms the A sequence of extension elements, possibly with padding, forms the
header extension defined in the RTP specification. There are as many header extension defined in the RTP specification. There are as many
extension elements as fit into the length as indicated in the RTP extension elements as fit into the length as indicated in the RTP
header extension length. Since this length is signaled in full header extension length. Since this length is signaled in full
32-bit words, padding bytes are used to pad to a 32-bit boundary. 32-bit words, padding bytes are used to pad to a 32-bit boundary.
The entire extension is parsed byte-by-byte to find each extension The entire extension is parsed byte-by-byte to find each extension
element (no alignment is required), and parsing stops at the earlier element (no alignment is needed), and parsing stops at the earlier of
of the end of the entire header extension, or in one-byte headers the end of the entire header extension, or in one-byte headers only
only case, on encountering an identifier with the reserved value of case, on encountering an identifier with the reserved value of 15.
15.
In both forms, padding bytes have the value of 0 (zero). They may be In both forms, padding bytes have the value of 0 (zero). They MAY be
placed between extension elements, if desired for alignment, or after placed between extension elements, if desired for alignment, or after
the last extension element, if needed for padding. A padding byte the last extension element, if needed for padding. A padding byte
does not supply the ID of an element, nor the length field. When a does not supply the ID of an element, nor the length field. When a
padding byte is found, it is ignored and the parser moves on to padding byte is found, it is ignored and the parser moves on to
interpreting the next byte. interpreting the next byte.
Note carefully that the one-byte header form allows for data lengths Note carefully that the one-byte header form allows for data lengths
between 1 and 16 bytes, by adding 1 to the signaled length value between 1 and 16 bytes, by adding 1 to the signaled length value
(thus, 0 in the length field indicates 1 byte of data follows). This (thus, 0 in the length field indicates 1 byte of data follows). This
allows for the important case of 16-byte payloads. This addition is allows for the important case of 16-byte payloads. This addition is
skipping to change at page 5, line 49 skipping to change at page 5, line 46
unless the RTP header compression module is updated to recognize the unless the RTP header compression module is updated to recognize the
extension header. If header extensions are present in some packets, extension header. If header extensions are present in some packets,
but not in others, this can also reduce compression efficiency by but not in others, this can also reduce compression efficiency by
requiring an update to the fixed header to be conveyed when header requiring an update to the fixed header to be conveyed when header
extensions start or stop being sent. The interactions of the RTP extensions start or stop being sent. The interactions of the RTP
header extension and header compression is explored further in header extension and header compression is explored further in
[RFC2508] and [RFC3095]. [RFC2508] and [RFC3095].
4.2. One-Byte Header 4.2. One-Byte Header
In the one-byte header form of extensions, the 16-bit value required In the one-byte header form of extensions, the 16-bit value REQUIRED
by the RTP specification for a header extension, labeled in the RTP by the RTP specification for a header extension, labeled in the RTP
specification as "defined by profile", takes the fixed bit pattern specification as "defined by profile", MUST have the fixed bit
0xBEDE (the first version of this specification was written on the pattern 0xBEDE (the first version of this specification was written
feast day of the Venerable Bede). on the feast day of the Venerable Bede).
Each extension element starts with a byte containing an ID and a Each extension element MUST starts with a byte containing an ID and a
length: length:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| ID | len | | ID | len |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 4-bit ID is the local identifier of this element in the range The 4-bit ID is the local identifier of this element in the range
1-14 inclusive. In the signaling section, this is referred to as the 1-14 inclusive. In the signaling section, this is referred to as the
valid range. valid range.
The local identifier value 15 is reserved for future extension and The local identifier value 15 is reserved for future extension and
MUST NOT be used as an identifier. If the ID value 15 is MUST NOT be used as an identifier. If the ID value 15 is
encountered, its length field should be ignored, processing of the encountered, its length field MUST be ignored, processing of the
entire extension should terminate at that point, and only the entire extension MUST terminate at that point, and only the extension
extension elements present prior to the element with ID 15 elements present prior to the element with ID 15 SHOULD be
considered. considered.
The 4-bit length is the number minus one of data bytes of this header The 4-bit length is the number minus one of data bytes of this header
extension element following the one-byte header. Therefore, the extension element following the one-byte header. Therefore, the
value zero in this field indicates that one byte of data follows, and value zero in this field indicates that one byte of data follows, and
a value of 15 (the maximum) indicates element data of 16 bytes. a value of 15 (the maximum) indicates element data of 16 bytes.
(This permits carriage of 16-byte values, which is a common length of (This permits carriage of 16-byte values, which is a common length of
labels and identifiers, while losing the possibility of zero-length labels and identifiers, while losing the possibility of zero-length
values -- which would often be padded anyway.) values -- which would often be padded anyway.)
An example header extension, with three extension elements, some An example header extension, with three extension elements, and some
padding, and including the required RTP fields, follows: padding follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 | | 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | data | ID | L=1 | data... | ID | L=0 | data | ID | L=1 | data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...data | 0 (pad) | 0 (pad) | ID | L=3 | ...data | 0 (pad) | 0 (pad) | ID | L=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. Two-Byte Header 4.3. Two-Byte Header
In the two-byte header form, the 16-bit value required by the RTP In the two-byte header form, the 16-bit value defined by the RTP
specification for a header extension, labeled in the RTP specification for a header extension, labeled in the RTP
specification as "defined by profile", is defined as shown below. specification as "defined by profile", is defined as shown below.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x100 |appbits| | 0x100 |appbits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The appbits field is 4 bits that are application-dependent and may be The appbits field is 4 bits that are application-dependent and MAY be
defined to be any value or meaning, and are outside the scope of this defined to be any value or meaning, and are outside the scope of this
specification. For the purposes of signaling, this field is treated specification. For the purposes of signaling, this field is treated
as a special extension value assigned to the local identifier 256. as a special extension value assigned to the local identifier 256.
If no extension has been specified through configuration or signaling If no extension has been specified through configuration or signaling
for this local identifier value 256, the appbits field SHOULD be set for this local identifier value 256, the appbits field SHOULD be set
to all 0s by the sender and MUST be ignored by the receiver. to all 0s by the sender and MUST be ignored by the receiver.
Each extension element starts with a byte containing an ID and a byte Each extension element starts with a byte containing an ID and a byte
containing a length: containing a length:
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The 8-bit ID is the local identifier of this element in the range The 8-bit ID is the local identifier of this element in the range
1-255 inclusive. In the signaling section, the range 1-256 is 1-255 inclusive. In the signaling section, the range 1-256 is
referred to as the valid range, with the values 1-255 referring to referred to as the valid range, with the values 1-255 referring to
extension elements, and the value 256 referring to the 4-bit field extension elements, and the value 256 referring to the 4-bit field
'appbits' (above). 'appbits' (above).
The 8-bit length field is the length of extension data in bytes not The 8-bit length field is the length of extension data in bytes not
including the ID and length fields. The value zero indicates there including the ID and length fields. The value zero indicates there
is no data following. is no data following.
An example header extension, with three extension elements, some An example header extension, with three extension elements, and some
padding, and including the required RTP fields, follows: padding follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=3 | | 0x10 | 0x00 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | ID | L=1 | | ID | L=0 | ID | L=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 | | data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 47 skipping to change at page 8, line 47
that contain a domain name SHOULD also contain a month-date in the that contain a domain name SHOULD also contain a month-date in the
form mmyyyy. The definition of the element and assignment of the URI form mmyyyy. The definition of the element and assignment of the URI
MUST have been authorized by the owner of the domain name on or very MUST have been authorized by the owner of the domain name on or very
close to that date. (This avoids problems when domain names change close to that date. (This avoids problems when domain names change
ownership.) If the resource or document defines several extensions, ownership.) If the resource or document defines several extensions,
then the URI MUST identify the actual extension in use, e.g., using a then the URI MUST identify the actual extension in use, e.g., using a
fragment or query identifier (characters after a '#' or '?' in the fragment or query identifier (characters after a '#' or '?' in the
URI). URI).
Rationale: the use of URIs provides for a large, unallocated space, Rationale: the use of URIs provides for a large, unallocated space,
and gives documentation on the extension. The URIs are not required and gives documentation on the extension. The URIs do not have to be
to be de-referencable, in order to permit confidential or de-referencable, in order to permit confidential or experimental use,
experimental use, and to cover the case when extensions continue to and to cover the case when extensions continue to be used after the
be used after the organization that defined them ceases to exist. organization that defined them ceases to exist.
An extension URI with the same attributes MUST NOT appear more than An extension URI with the same attributes MUST NOT appear more than
once applying to the same stream, i.e., at session level or in the once applying to the same stream, i.e., at session level or in the
declarations for a single stream at media level. (The same extension declarations for a single stream at media level. (The same extension
may, of course, be used for several streams, and may appear can, of course, be used for several streams, and can appear
differently parameterized for the same stream.) differently parameterized for the same stream.)
For extensions defined in RFCs, the URI used SHOULD be a URN starting For extensions defined in RFCs, the URI used SHOULD be a URN starting
"urn:ietf:params:rtp-hdrext:" and followed by a registered, "urn:ietf:params:rtp-hdrext:" and followed by a registered,
descriptive name. descriptive name.
The registration requirements are detailed in the IANA Considerations The registration requirements are detailed in the IANA Considerations
section, below. section, below.
An example (this is only an example), where 'avt-example-metadata' is An example (this is only an example), where 'avt-example-metadata' is
the hypothetical name of a header extension, might be: the hypothetical name of a header extension, might be:
urn:ietf:params:rtp-hdrext:avt-example-metadata urn:ietf:params:rtp-hdrext:avt-example-metadata
An example name not from the IETF (this is only an example) might be: An example name not from the IETF (this is only an example) might be:
http://example.com/082005/ext.htm#example-metadata http://example.com/082005/ext.htm#example-metadata
The mapping may be provided per media stream (in the media-level The mapping MAY be provided per media stream (in the media-level
section(s) of SDP, i.e., after an "m=" line) or globally for all section(s) of SDP, i.e., after an "m=" line) or globally for all
streams (i.e., before the first "m=" line, at session level). The streams (i.e., before the first "m=" line, at session level). The
definitions MUST be either all session level or all media level; it definitions MUST be either all session level or all media level; it
is not permitted to mix the two styles. In addition, as noted above, is not permitted to mix the two styles. In addition, as noted above,
the IDs used MUST be unique for each stream type for a given media, the IDs used MUST be unique for each stream type for a given media,
or for the session for session-level declarations. or for the session for session-level declarations.
Each local identifier potentially used in the stream is mapped to a Each local identifier potentially used in the stream is mapped to a
string using an attribute of the form: string using an attribute of the form:
skipping to change at page 11, line 7 skipping to change at page 11, line 7
to use both one and two bytes extensions MUST include the attribute to use both one and two bytes extensions MUST include the attribute
"a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed
" is present in the offer SDP, the answerer that supports this mode " is present in the offer SDP, the answerer that supports this mode
and wishes to use it SHALL include the "a=extmap-allow-mixed " and wishes to use it SHALL include the "a=extmap-allow-mixed "
attribute in the answer. In cases the answer has been excluded, attribute in the answer. In cases the answer has been excluded,
neither clients SHALL use mixed one bytes and two bytes extensions in neither clients SHALL use mixed one bytes and two bytes extensions in
the same RTP stream. the same RTP stream.
7. Offer/Answer 7. Offer/Answer
The simple signaling described above may be enhanced in an offer/ The simple signaling described above MAY be enhanced in an offer/
answer context, to permit: answer context, to permit:
o asymmetric behavior (extensions sent in only one direction), o asymmetric behavior (extensions sent in only one direction),
o the offer of mutually exclusive alternatives, or o the offer of mutually exclusive alternatives, or
o the offer of more extensions than can be sent in a single session. o the offer of more extensions than can be sent in a single session.
A direction attribute MAY be included in an extmap; without it, the A direction attribute MAY be included in an extmap; without it, the
direction implicitly inherits, of course, from the stream direction, direction implicitly inherits, of course, from the stream direction,
or is "sendrecv" for session-level attributes or extensions of or is "sendrecv" for session-level attributes or extensions of
"inactive" streams. The direction MUST be one of "sendonly", "inactive" streams. The direction MUST be one of "sendonly",
"recvonly", "sendrecv", or "inactive". A "sendonly" direction "recvonly", "sendrecv", or "inactive". A "sendonly" direction
indicates an ability to send; a "recvonly" direction indicates a indicates an ability to send; a "recvonly" direction indicates a
desire to receive; a "sendrecv" direction indicates both. An desire to receive; a "sendrecv" direction indicates both. An
"inactive" direction indicates neither, but later re-negotiation may "inactive" direction indicates neither, but later re-negotiation MAY
make an extension active. make an extension active.
Extensions, with their directions, may be signaled for an "inactive" Extensions, with their directions, MAY be signaled for an "inactive"
stream. It is an error to use an extension direction incompatible stream. It is an error to use an extension direction incompatible
with the stream direction (e.g., a "sendonly" attribute for a with the stream direction (e.g., a "sendonly" attribute for a
"recvonly" stream). "recvonly" stream).
If an offer or answer contains session-level mappings (and hence no If an offer or answer contains session-level mappings (and hence no
media-level mappings), and different behavior is desired for each media-level mappings), and different behavior is desired for each
stream, then the entire set of extension map declarations may be stream, then the entire set of extension map declarations MAY be
moved into the media-level section(s) of the SDP. (Note that this moved into the media-level section(s) of the SDP. (Note that this
specification does not permit mixing global and local declarations, specification does not permit mixing global and local declarations,
to make identifier management easier.) to make identifier management easier.)
If an extension map is offered as "sendrecv", explicitly or If an extension map is offered as "sendrecv", explicitly or
implicitly, and asymmetric behavior is desired, the SDP may be implicitly, and asymmetric behavior is desired, the SDP MAY be
modified to modify or add direction qualifiers for that extension. modified to modify or add direction qualifiers for that extension.
If an extension is marked as "sendonly" and the answerer desires to If an extension is marked as "sendonly" and the answerer desires to
receive it, the extension MUST be marked as "recvonly" in the SDP receive it, the extension MUST be marked as "recvonly" in the SDP
answer. An answerer that has no desire to receive the extension or answer. An answerer that has no desire to receive the extension or
does not understand the extension SHOULD remove it from the SDP does not understand the extension SHOULD remove it from the SDP
answer. answer.
If an extension is marked as "recvonly" and the answerer desires to If an extension is marked as "recvonly" and the answerer desires to
send it, the extension MUST be marked as "sendonly" in the SDP send it, the extension MUST be marked as "sendonly" in the SDP
answer. An answerer that has no desire to, or is unable to, send the answer. An answerer that has no desire to, or is unable to, send the
extension SHOULD remove it from the SDP answer. extension SHOULD remove it from the SDP answer.
Local identifiers in the valid range inclusive in an offer or answer Local identifiers in the valid range inclusive in an offer or answer
must not be used more than once per media section (including the MUST NOT be used more than once per media section (including the
session-level section). A session update MAY change the direction session-level section). A session update MAY change the direction
qualifiers of extensions under use. A session update MAY add or qualifiers of extensions under use. A session update MAY add or
remove extension(s). Identifiers values in the valid range MUST NOT remove extension(s). Identifiers values in the valid range MUST NOT
be altered (remapped). be altered (remapped).
Note that, under this rule, the same local identifier cannot be used Note that, under this rule, the same local identifier cannot be used
for two extensions for the same media, even when one is "sendonly" for two extensions for the same media, even when one is "sendonly"
and the other "recvonly", as it would then be impossible to make and the other "recvonly", as it would then be impossible to make
either of them sendrecv (since re-numbering is not permitted either). either of them sendrecv (since re-numbering is not permitted either).
If a party wishes to offer mutually exclusive alternatives, then If a party wishes to offer mutually exclusive alternatives, then
multiple extensions with the same identifier in the (unusable) range multiple extensions with the same identifier in the (unusable) range
4096-4351 may be offered; the answerer should select at most one of 4096-4351 MAY be offered; the answerer SHOULD select at most one of
the offered extensions with the same identifier, and remap it to a the offered extensions with the same identifier, and remap it to a
free identifier in the valid range, for that extension to be usable. free identifier in the valid range, for that extension to be usable.
Similarly, if more extensions are offered than can be fit in the Similarly, if more extensions are offered than can be fit in the
valid range, identifiers in the range 4096-4351 may be offered; the valid range, identifiers in the range 4096-4351 MAY be offered; the
answerer should choose those that are desired, and remap them to a answerer SHOULD choose those that are desired, and remap them to a
free identifier in the valid range. free identifier in the valid range.
It is always allowed to place the offered identifier value "as is" in It is always allowed to place the offered identifier value "as is" in
the SDP answer (for example, due to lack of a free identifier value the SDP answer (for example, due to lack of a free identifier value
in the valid range). Extensions with an identifier outside the valid in the valid range). Extensions with an identifier outside the valid
range cannot, of course, be used. If required, the offerer or range MUST NOT, of course, be used. If needed, the offerer or
answerer can update the session to make space for such an extension. answerer can update the session to make space for such an extension.
Rationale: the range 4096-4351 for these negotiation identifiers is Rationale: the range 4096-4351 for these negotiation identifiers is
deliberately restricted to allow expansion of the range of valid deliberately restricted to allow expansion of the range of valid
identifiers in future. identifiers in future.
Either party MAY include extensions in the stream other than those Either party MAY include extensions in the stream other than those
negotiated, or those negotiated as "inactive", for example, for the negotiated, or those negotiated as "inactive", for example, for the
benefit of intermediate nodes. Only extensions that appeared with an benefit of intermediate nodes. Only extensions that appeared with an
identifier in the valid range in SDP originated by the sender can be identifier in the valid range in SDP originated by the sender can be
skipping to change at page 13, line 37 skipping to change at page 13, line 37
a=sendrecv a=sendrecv
a=extmap:1/sendonly URI-toffset a=extmap:1/sendonly URI-toffset
8. BNF Syntax 8. BNF Syntax
The syntax definition below uses ABNF according to [RFC5234]. The The syntax definition below uses ABNF according to [RFC5234]. The
syntax element 'URI' is defined in [RFC3986] (only absolute URIs are syntax element 'URI' is defined in [RFC3986] (only absolute URIs are
permitted here). The syntax element 'extmap' is an attribute as permitted here). The syntax element 'extmap' is an attribute as
defined in [RFC4566], i.e., "a=" precedes the extmap definition. defined in [RFC4566], i.e., "a=" precedes the extmap definition.
Specific extensionattributes are defined by the specification that Specific extensionattributes are defined by the specification that
defines a specific extension name; there may be several. defines a specific extension name; there can be several.
extmap = mapentry SP extensionname [SP extensionattributes] extmap = mapentry SP extensionname [SP extensionattributes]
extensionname = URI extensionname = URI
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "extmap:" 1*5DIGIT ["/" direction] mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionattributes = byte-string extensionattributes = byte-string
skipping to change at page 14, line 26 skipping to change at page 14, line 26
byte-string = <Defined in RFC 4566> byte-string = <Defined in RFC 4566>
SP = <Defined in RFC 5234> SP = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234> DIGIT = <Defined in RFC 5234>
9. Security Considerations 9. Security Considerations
This document defines only a place to transmit information; the This document defines only a place to transmit information; the
security implications of each of the extensions must be discussed security implications of each of the extensions MUST be discussed
with those extensions. with those extensions.
Header extensions have the same security coverage as the RTP header Header extensions have the same security coverage as the RTP header
itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is
used to protect RTP sessions, the RTP payload may be both encrypted used to protect RTP sessions, the RTP payload can be both encrypted
and integrity protected, while the RTP header is either unprotected and integrity protected, while the RTP header is either unprotected
or integrity protected. RTP header extensions may carry sensitive or integrity protected. RTP header extensions can carry sensitive
information for which participants in multimedia sessions want information for which participants in multimedia sessions want
confidentiality. RFC6904 [RFC6904] provides a mechanism, extending confidentiality. RFC6904 [RFC6904] provides a mechanism, extending
the mechanisms of SRTP, to selectively encrypt RTP header extensions the mechanisms of SRTP, to selectively encrypt RTP header extensions
in SRTP. in SRTP.
10. IANA Considerations 10. IANA Considerations
This document updates the IANA consideration to reference this This document updates the IANA consideration to reference this
document and adds a new SDP attribute in section 10.3 document and adds a new SDP attribute in section 10.3
skipping to change at page 15, line 8 skipping to change at page 15, line 8
10.1. Identifier Space for IANA to Manage 10.1. Identifier Space for IANA to Manage
The mapping from the naming URI form to a reference to a The mapping from the naming URI form to a reference to a
specification is managed by IANA. Insertion into this registry is specification is managed by IANA. Insertion into this registry is
under the requirements of "Expert Review" as defined in [RFC5226]. under the requirements of "Expert Review" as defined in [RFC5226].
The IANA will also maintain a server that contains all of the The IANA will also maintain a server that contains all of the
registered elements in a publicly accessible space. registered elements in a publicly accessible space.
Here is the formal declaration required by the IETF URN Sub-namespace Here is the formal declaration to comply with the IETF URN Sub-
specification [RFC3553]. namespace specification [RFC3553].
o Registry name: RTP Compact Header Extensions o Registry name: RTP Compact Header Extensions
o Specification: RFC 5285 and RFCs updating RFC 5285. o Specification: RFC 5285 and RFCs updating RFC 5285.
o Information required: o Information required:
A. The desired extension naming URI A. The desired extension naming URI
B. A formal reference to the publicly available specification B. A formal reference to the publicly available specification
C. A short phrase describing the function of the extension C. A short phrase describing the function of the extension
D. Contact information for the organization or person making the D. Contact information for the organization or person making the
registration registration
For extensions defined in RFCs, the URI is recommended to be of For extensions defined in RFCs, the URI SHOULD be of the form
the form urn:ietf:params:rtp-hdrext:, and the formal reference is urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC
the RFC number of the RFC documenting the extension. number of the RFC documenting the extension.
o Review process: Expert review is required. The expert review o Review process: Expert review is REQUIRED. The expert review
should check the following requirements: SHOULD check the following requirements:
1. that the specification is publicly available; 1. that the specification is publicly available;
2. that the extension complies with the requirements of RTP and 2. that the extension complies with the requirements of RTP and
this specification, for extensions (notably, that the stream this specification, for extensions (notably, that the stream
is still decodable if the extension is ignored or not is still decodable if the extension is ignored or not
recognized); recognized);
3. that the extension specification is technically consistent (in 3. that the extension specification is technically consistent (in
itself and with RTP), complete, and comprehensible; itself and with RTP), complete, and comprehensible;
skipping to change at page 16, line 16 skipping to change at page 16, line 16
unique. unique.
o Size and format of entries: a mapping from a naming URI string to o Size and format of entries: a mapping from a naming URI string to
a formal reference to a publicly available specification, with a a formal reference to a publicly available specification, with a
descriptive phrase and contact information. descriptive phrase and contact information.
o Initial assignments: none. o Initial assignments: none.
10.2. Registration of the SDP extmap Attribute 10.2. Registration of the SDP extmap Attribute
This section contains the information required by [RFC4566] for an This section contains the information requested by [RFC4566] for an
SDP attribute. SDP attribute.
o contact name, email address, and telephone number: o contact name, email address, and telephone number:
D. Singer D. Singer
singer@apple.com singer@apple.com
+1 408-974-3162 +1 408-974-3162
o attribute name (as it will appear in SDP): extmap o attribute name (as it will appear in SDP): extmap
 End of changes. 45 change blocks. 
71 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/