draft-ietf-avtcore-rfc5285-bis-05.txt   draft-ietf-avtcore-rfc5285-bis-06.txt 
AVTCore R. Even, Ed. AVTCore R. Even, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: RFC5285 (if approved) D. Singer Obsoletes: 5285 (if approved) D. Singer
Intended status: Standards Track Apple, Inc. Intended status: Standards Track Apple, Inc.
Expires: May 18, 2017 H. Desineni Expires: August 18, 2017 H. Desineni
November 14, 2016 February 14, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-05.txt draft-ietf-avtcore-rfc5285-bis-06.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. The session are signaled in the setup information for that session. This
document obsoletes RFC5285 document obsoletes RFC5285.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 18, 2017. This Internet-Draft will expire on August 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. transmission considertions . . . . . . . . . . . . . 4 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5
4.1.2. Header Extension type consideration . . . . . . . . . 6 4.1.2. Header Extension Type Considerations . . . . . . . . 6
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 8 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 8
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 9 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 9
6. SDP Signaling for support of mixed one byte and two bytes 6. SDP Signaling for support of mixed one byte and two bytes
header extensions. . . . . . . . . . . . . . . . . . . . . . 11 header extensions. . . . . . . . . . . . . . . . . . . . . . 11
7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 16 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 16
10.2. Registration of the SDP extmap Attribute . . . . . . . . 17 10.2. Registration of the SDP extmap Attribute . . . . . . . . 17
10.3. Registration of the SDP extmap-allow-mixed Attribute . . 17 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 18
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The RTP specification [RFC3550] provides a capability to extend the The RTP specification [RFC3550] provides a capability to extend the
RTP header. It defines the header extension format and rules for its RTP header. It defines the header extension format and rules for its
use in Section 5.3.1. The existing header extension method permits use in Section 5.3.1. The existing header extension method permits
skipping to change at page 3, line 17 skipping to change at page 3, line 17
elements in a single RTP packet. It removes the second drawback by elements in a single RTP packet. It removes the second drawback by
defining that these extension elements are named by URIs, defining an defining that these extension elements are named by URIs, defining an
IANA registry for extension elements defined in IETF specifications, IANA registry for extension elements defined in IETF specifications,
and a Session Description Protocol (SDP) method for mapping between and a Session Description Protocol (SDP) method for mapping between
the naming URIs and the identifier values carried in the RTP packets. the naming URIs and the identifier values carried in the RTP packets.
This header extension applies to RTP/AVP (the Audio/Visual Profile) This header extension applies to RTP/AVP (the Audio/Visual Profile)
and its extensions. and its extensions.
This document obsoletes [RFC5285] and removes a limitation from This document obsoletes [RFC5285] and removes a limitation from
RFC5285 that did not allow sending both one byte and two bytes header RFC5285 that did not allow sending both one-byte and two-byte header
extensions in the same RTP stream extensions in the same RTP stream
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Design Goals 3. Design Goals
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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 16-bit identifier for the two forms of
(defined below for the one-byte and two-byte header forms) is only an RTP extension defined here is only an architectural constant (e.g.,
architectural constant (e.g., for use by network analyzers); it is for use by network analyzers); it is the negotiation/definition
the negotiation/definition (e.g., in SDP) that is the definitive (e.g., in SDP) that is the definitive indication that this header
indication that this header extension is present. extension is present.
This specification updates the requirement from the RTP specification The RTP specification [RFC3550] states that RTP "is designed so that
that the header extension "is designed so that the header extension the header extension may be ignored by other interoperating
MAY be ignored". To be specific, header extensions using this implementations that have not been extended". The intent of this
specification SHOULD be used for data that can safely be ignored by restriction is that RTP header extensions MUST NOT be used to extend
the recipient without affecting interoperability, there can be RTP itself in a manner that is backwards incompatible with non-
essential header extensions for interoperability and intermediaries extended implementations. For example, a header extension is not
SHOULD NOT remove such header extensions. Note that the support of allowed to change the meaning or interpretation of the standard RTP
header extension as specified in this recommendation is negotiated. header fields, or of the RTCP Control Protocol (RTCP). Header
RTP Header extensions MUST NOT be used when the presence of the extensions MAY carry metadata in addition to the usual RTP header
extension has changed the form or nature of the rest of the packet in information, provided the RTP layer can function if that metadata is
a way that is not compatible with the way the stream is signaled missing. For example, RTP header extensions can be used to carry
(e.g., as defined by the payload type). Valid examples might include data that's also sent in RTCP, as an optimisation to lower latency,
metadata that is additional to the usual RTP information, e.g. Audio since they'll fall back to the original, non-optimised, behaviour if
level from Client to mixer [RFC6464]. Note that some header the header extension is not present. The use of header extensions to
extensions, for example MID [I-D.ietf-mmusic-sdp-bundle-negotiation] convey information that will, if missing, disrupt the behaviour of a
might, if removed, disrupt the behaviour of the higher-level higher layer application that builds on top of RTP is only acceptable
application that builds on RTP, but are acceptable since they do not if this doesn't affect interoperability at the RTP layer. For
affect interoperability of the RTP stack itself. example, applications that use the SDP BUNDLE extension with the MID
RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to
correlate RTP streams with SDP m= lines likely won't work with full
functionality if the MID is missing, but the operation of the RTP
layer of those applications will be unaffected. Support for RTP
header extensions based on this memo is negotoited using, for
example, SDP offer answer [RFC3264]; intermediaries aware of the RTP
header extensions are advised to be cautious when removing or
generating RTP header extensions see section 4.7 of [RFC7667].
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).
4.1.1. transmission considertions 4.1.1. Transmission Considerations
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 can 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.
Some general considerations for getting the header extensions Some general considerations for getting the header extensions
skipping to change at page 6, line 7 skipping to change at page 6, line 16
Layer Feedback Messages for generic NACK [RFC4585] is used, it can Layer Feedback Messages for generic NACK [RFC4585] is used, it can
indicate the failure to deliver an RTP packet with the header indicate the failure to deliver an RTP packet with the header
extension, thus indicating the need for further repetitions. The extension, thus indicating the need for further repetitions. The
normal RTCP report blocks can also provide an indicator of successful normal RTCP report blocks can also provide an indicator of successful
delivery, if no losses are indicated for a reporting interval delivery, if no losses are indicated for a reporting interval
covering the RTP packets with the header extension. Note that loss covering the RTP packets with the header extension. Note that loss
of an RTCP packet reporting on an interval where RTP header extension of an RTCP packet reporting on an interval where RTP header extension
packets were sent, does not necessarily mean that the RTP header packets were sent, does not necessarily mean that the RTP header
extension packets themselves were lost. extension packets themselves were lost.
4.1.2. Header Extension type consideration 4.1.2. Header Extension Type Considerations
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
skipping to change at page 6, line 30 skipping to change at page 6, line 39
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. Each RTP packet with an RTP header extension following knowledge. Each RTP packet with an RTP header extension following
this specification will indicate if it contains one or two byte this specification will indicate if it contains one or two byte
header extensions through the use of the "defined by profile" field. header extensions through the use of the "defined by profile" field.
Only the extension element types that match the header extension Only the extension element types that match the header extension
format, i.e. one- or two-byte, MUST be used in that RTP packet. format, i.e. one- or two-byte, MUST be used in that RTP packet.
Transmitters SHOULD NOT use the two-byte form when all extensions are Transmitters SHOULD NOT use the two-byte form when all extensions are
small enough for the one-byte header form. Transmitters that intend small enough for the one-byte header form. Transmitters that intend
to send the two-byte form SHOULD use IDs above 14 if they want to let to send the two-byte form SHOULD negotiate the use of IDs above 14 if
the Receivers know that they intend to use two-byte form, for example they want to let the Receivers know that they intend to use two-byte
if the RTP header extension is longer than 16 bytes. A transmitter form, for example if the RTP header extension is longer than 16
MAY be aware that an intermediary may add RTP header extensions in bytes. A transmitter MAY be aware that an intermediary may add RTP
this case, the transmitter SHOULD use two-byte form. header 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 needed), and parsing stops at the earlier of element (no alignment is needed), and parsing stops at the earlier of
the end of the entire header extension, or in one-byte headers only the end of the entire header extension, or in one-byte headers only
case, on encountering an identifier with the reserved value of 15. case, on encountering an identifier with the reserved value of 15.
skipping to change at page 9, line 16 skipping to change at page 9, line 24
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length | | ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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). Note that there is one ID space for both one-byte 'appbits' (above). Note that there is one ID space for both one-byte
and two-byte form this means that the lower values (1-14) can be used and two-byte form. This means that the lower values (1-14) can be
in the 4-bit ID field in the one-byte header format as well. used in the 4-bit ID field in the one-byte header format with the
same meanings.
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, and some An example header extension, with three extension elements, and some
padding 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
skipping to change at page 10, line 25 skipping to change at page 10, line 34
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 do not have to be and gives documentation on the extension. The URIs do not have to be
de-referencable, in order to permit confidential or experimental use, de-referencable, in order to permit confidential or experimental use,
and to cover the case when extensions continue to be used after the and to cover the case when extensions continue to 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
can, of course, be used for several streams, and can appear can, of course, be used for several streams, and can appear with
differently parameterized for the same stream.) different extensionattributes 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:
skipping to change at page 10, line 49 skipping to change at page 11, line 10
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 in each media section of the SDP, or
or for the session for session-level declarations. unique in the session for session-level SDP declarations.
Each local identifier potentially used in the stream is mapped to a Each local identifier potentially used in the stream is mapped to an
string using an attribute of the form: extension identified by a URI using an attribute of the form:
a=extmap:<value>["/"<direction>] <URI> <extensionattributes> a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
where <URI> is a URI, as above, <value> is the local identifier (ID) where <URI> is a URI, as above, <value> is the local identifier (ID)
of this extension and is an integer in the valid range inclusive (0 of this extension and is an integer in the valid range (0 is reserved
is reserved for padding in both forms, and 15 is reserved in the one- for padding in both forms, and 15 is reserved in the one-byte header
byte header form, as noted above), and <direction> is one of form, as noted above), and <direction> is one of "sendonly",
"sendonly", "recvonly", "sendrecv", or "inactive" (without the "recvonly", "sendrecv", or "inactive" (without the quotes) with
quotes) with relation to the device being configured. relation to the device being configured.
The formal BNF syntax is presented in a later section of this The formal BNF syntax is presented in a later section of this
specification. specification.
Example: Example:
a=extmap:1 http://example.com/082005/ext.htm#ttime a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
skipping to change at page 12, line 18 skipping to change at page 12, line 26
Example: Example:
a=extmap-allow-mixed a=extmap-allow-mixed
When doing SDP Offer/Answer [RFC3264] an offering client that wishes When doing SDP Offer/Answer [RFC3264] an offering client that wishes
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 where the attribute has been
neither clients SHALL use mixed one bytes and two bytes extensions in excluded, both clients SHALL NOT use mixed one bytes and two bytes
the same RTP stream but MAY use one-byte or two-bytes form (see extensions in the same RTP stream but MAY use one-byte or two-bytes
section 4.1.2). form exclusively (see section 4.1.2).
7. Offer/Answer 7. Offer/Answer
The simple signaling described above for the extmap attribute MAY be The simple signaling described above for the extmap attribute MAY be
enhanced in an offer/answer context, to permit: enhanced in an offer/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
skipping to change at page 13, line 4 skipping to change at page 13, line 11
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 answer MAY be
modified to modify or add direction qualifiers for that extension. changed 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
skipping to change at page 13, line 32 skipping to change at page 13, line 40
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 extended 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 An answerer may copy an extmap for an identifier in the extended
the SDP answer (for example, due to lack of a free identifier value range into the answer to indicate to the offerer that it supports
in the valid range). Extensions with an identifier outside the valid that extension. Of course, such an extension cannot be used, since
range MUST NOT, of course, be used. If needed, the offerer or there is no way to specify them in an extension header. If needed,
answerer can update the session to make space for such an extension. the offerer or answerer can update the session to assign a valid
identifier to that extension URI.
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
sent. sent.
skipping to change at page 15, line 5 skipping to change at page 15, line 14
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 can be several. defines a specific extension name; there can be several.
extmap = mapentry SP extensionname [SP extensionattributes] Name: extmap
extensionname = URI Value: extmap-value
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" Syntax:
extmap-value = mapentry SP extensionname
[SP extensionattributes]
mapentry = "extmap:" 1*5DIGIT ["/" direction] mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionname = URI
extensionattributes = byte-string extensionattributes = byte-string
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
URI = <Defined in RFC 3986> URI = <Defined in RFC 3986>
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
skipping to change at page 17, line 29 skipping to change at page 18, line 5
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
IANA is requested to register the extmap SDP [RFC4566] attribute. IANA is requested to register the extmap SDP [RFC4566] attribute.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: extmap Attribute name: extmap
Long form: generic header extension map definition Long form: generic header extension map definition
Type of name: att-field Type of name: att-field
Type of attribute: Media or session level Type of attribute: Media or session level
Subject to charset: No Subject to charset: No
Purpose: defines the mapping from the extension numbers used in Purpose: defines the mapping from the extension
packet headers into extension names. numbers used in packet headers
Reference: [RFCXXXX] into extension names.
Values: See [RFCXXXX] Reference: [RFCXXXX]
Values: See [RFCXXXX]
10.3. Registration of the SDP extmap-allow-mixed Attribute 10.3. Registration of the SDP extmap-allow-mixed Attribute
The IANA is requested to register one new SDP attribute: The IANA is requested to register one new SDP attribute:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: extmap-allow-mixed Attribute name: extmap-allow-mixed
Long form: One and Two bytes mixed mode Long form: One and Two bytes mixed mode
Type of name: att-field Type of name: att-field
Type of attribute: Media or session level Type of attribute: Media or session level
skipping to change at page 18, line 21 skipping to change at page 18, line 37
Purpose: Negotiate the use of One and Two bytes Purpose: Negotiate the use of One and Two bytes
in the same RTP stream. in the same RTP stream.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: None Values: None
11. Changes from RFC5285 11. Changes from RFC5285
The major motivation for updating [RFC5285] was to allow having one The major motivation for updating [RFC5285] was to allow having one
byte and two bytes RTP header extensions in the same RTP stream (but byte and two bytes RTP header extensions in the same RTP stream (but
not in the same RTP packet). The support for this case is negotiated not in the same RTP packet). The support for this case is negotiated
using a new SDP attribute "extmap-allowed-mixed" specified in this using a new SDP attribute "extmap-allow-mixed" specified in this
document. document.
The other major change is to update the requirement from the RTP The other major change is to update the requirement from the RTP
specification and[RFC5285] that the header extension "is designed so specification and[RFC5285] that the header extension "is designed so
that the header extension MAY be ignored". This is described in that the header extension MAY be ignored". This is described in
section 4.1. section 4.1.
The transmission consideration section (4.1.1) adds more text to The transmission consideration section (4.1.1) adds more text to
clarify when and how many times to send the RTP header extension to clarify when and how many times to send the RTP header extension to
provide higher probability of delivery provide higher probability of delivery
skipping to change at page 19, line 15 skipping to change at page 19, line 26
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February Headers for Low-Speed Serial Links", RFC 2508,
1999. DOI 10.17487/RFC2508, February 1999,
<http://www.rfc-editor.org/info/rfc2508>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-34 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
skipping to change at page 20, line 41 skipping to change at page 21, line 9
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
Authors' Addresses Authors' Addresses
Roni Even (editor) Roni Even (editor)
Huawei Technologies Huawei Technologies
Shabazi 12A
Tel Aviv Tel Aviv
Israel Israel
Email: Roni.even@mail01.huawei.com Email: Roni.even@huawei.com
David Singer David Singer
Apple, Inc. Apple, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Phone: +1 408 996 1010 Phone: +1 408 996 1010
Email: singer@apple.com Email: singer@apple.com
URI: http://www.apple.com/quicktime URI: http://www.apple.com/quicktime
 End of changes. 47 change blocks. 
113 lines changed or deleted 140 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/