draft-ietf-avtcore-rfc5285-bis-03.txt   draft-ietf-avtcore-rfc5285-bis-04.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: February 13, 2017 H. Desineni Expires: May 1, 2017 H. Desineni
August 12, 2016 October 28, 2016
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-03.txt draft-ietf-avtcore-rfc5285-bis-04.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. The
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 February 13, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 13 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. transmission considertions . . . . . . . . . . . . . 4 4.1.1. transmission considertions . . . . . . . . . . . . . 4
4.1.2. Header Extension type consideration . . . . . . . . . 5 4.1.2. Header Extension type consideration . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 15 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 Attribute . . . . . . . . . . . 17 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
at most one extension per RTP packet, identified by a 16-bit at most one extension per RTP packet, identified by a 16-bit
identifier and a 16-bit length field specifying the length of the identifier and a 16-bit length field specifying the length of the
header extension in 32-bit words. header extension in 32-bit words.
skipping to change at page 3, line 12 skipping to change at page 3, line 16
compatible and extensible means to carry multiple header extension compatible and extensible means to carry multiple header extension
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 removes a limitation from RFC5285 that did not allow This document obsoletes [RFC5285] and removes a limitation from
sending both one byte and two bytes header extensions in the same RTP RFC5285 that did not allow sending both one byte and two bytes header
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
The goal of this design is to provide a simple mechanism whereby The goal of this design is to provide a simple mechanism whereby
skipping to change at page 4, line 43 skipping to change at page 4, line 50
4.1.1. transmission considertions 4.1.1. transmission considertions
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
delivered to the receiver: delivered to the receiver:
1. The probability for packet loss and burst loss determine how many 1. The probability for packet loss and burst loss determine how many
repetitions of the header extensions will be required to reach a repetitions of the header extensions will be required to reach a
targeted delivery probability, and if burst loss is likely, what targeted delivery probability, and if burst loss is likely, what
distribution would be needed to avoid getting all repetitions of distribution would be needed to avoid getting all repetitions of
the header extensions lost in a single burst. the header extensions lost in a single burst.
2. If a set of packets are all needed to enable decoding, there is 2. If a set of packets are all needed to enable decoding, there is
commonly no reason for including the header extension in all of commonly no reason for including the header extension in all of
skipping to change at page 6, line 15 skipping to change at page 6, line 21
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. Each RTP packet with an RTP header extension following
single RTP packet. Transmitters SHOULD NOT use the two-byte form this specification will indicate if it contains one or two byte
when all extensions are small enough for the one-byte header form. A header extensions through the use of the "defined by profile" field.
transmitter MAY be aware that an intermediary may add RTP header Only the extension element types that match the header extension
extensions in this case, the transmitter SHOULD use two-byte form. 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
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
the Receivers know that they intend to use two-byte form, for example
if the RTP header extension is longer than 16 bytes. A transmitter
MAY be aware that an intermediary may add RTP 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 5 skipping to change at page 9, line 9
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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). '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
in the 4-bit ID field in the one-byte header format as well.
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 51 skipping to change at page 11, line 7
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:
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 inclusive (0
is reserved for padding in both forms, and 15 is reserved in the one- is reserved for padding in both forms, and 15 is reserved in the one-
byte header form, as noted above), and <direction> is one of byte header form, as noted above), and <direction> is one of
"sendonly", "recvonly", "sendrecv", or "inactive" (without the "sendonly", "recvonly", "sendrecv", or "inactive" (without the
quotes). quotes) with 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 8 skipping to change at page 12, line 14
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 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 but MAY use one-byte or two-bytes form (see
section 4.1.2).
7. Offer/Answer 7. Offer/Answer
The simple signaling described above MAY be enhanced in an offer/ The simple signaling described above for the extmap attribute MAY be
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
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" as specified in [RFC3264]
indicates an ability to send; a "recvonly" direction indicates a
desire to receive; a "sendrecv" direction indicates both. An
"inactive" direction indicates neither, but later re-negotiation MAY
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
skipping to change at page 15, line 29 skipping to change at page 15, line 29
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.
Extensions usage is negotiated using [RFC3264] so integrity
protection and end-to-end authentication MUST be used. The security
considerations of [RFC3264] MUST be followed, to prevent, for
example, extension usage blocking.
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 can 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 can carry sensitive or integrity protected. In order to prevent DOS attacks, for
information for which participants in multimedia sessions want example, by changing the header extension integrity protection SHOULD
confidentiality. RFC6904 [RFC6904] provides a mechanism, extending be used. Lower layer security protection like DTLS[RFC6347] MAY be
the mechanisms of SRTP, to selectively encrypt RTP header extensions used. RTP header extensions can carry sensitive information for
in SRTP. which participants in multimedia sessions want confidentiality.
RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of
SRTP, to selectively encrypt RTP header extensions in SRTP.
Other security options for securing RTP are discussed in [RFC7201].
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
Note to IANA : change RFCxxxx to this RFC number and remove the note. Note to IANA : change RFCxxxx to this RFC number and remove the note.
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.
skipping to change at page 16, line 36 skipping to change at page 16, line 43
For extensions defined in RFCs, the URI SHOULD be of the form For extensions defined in RFCs, the URI SHOULD be of the form
urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC urn:ietf:params:rtp-hdrext:, and the formal reference is 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;
is still decodable if the extension is ignored or not
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;
4. that the extension does not duplicate functionality in 4. that the extension does not duplicate functionality in
existing IETF specifications (including RTP itself), or other existing IETF specifications (including RTP itself), or other
extensions already registered; extensions already registered;
5. that the specification contains a security analysis regarding 5. that the specification contains a security analysis regarding
the content of the header extension; the content of the header extension;
skipping to change at page 17, line 16 skipping to change at page 17, line 23
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 requested by [RFC4566] for an IANA is requested to register the extmap SDP [RFC4566] attribute.
SDP attribute.
o contact name, email address, and telephone number:
D. Singer
singer@apple.com
+1 408-974-3162
o attribute name (as it will appear in SDP): extmap
o long-form attribute name in English: generic header extension map
definition
o type of attribute (session level, media level, or both): both
o whether the attribute value is subject to the charset attribute:
not subject to the charset attribute
o a one-paragraph explanation of the purpose of the attribute: This
attribute defines the mapping from the extension numbers used in
packet headers into extension names as documented in
specifications and appropriately registered.
o a specification of appropriate attribute values for this SDP Attribute ("att-field"):
attribute: see RFC 5285. Attribute name: extmap
Long form: generic header extension map definition
Type of name: att-field
Type of attribute: Media or session level
Subject to charset: No
Purpose: defines the mapping from the extension numbers used in
packet headers into extension names.
Reference: [RFCXXXX]
Values: See [RFCXXXX]
10.3. Registration of the SDP 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
Subject to charset: No Subject to charset: No
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. Acknowledgments 11. Changes from RFC5285
The major motivation for updating [RFC5285] was to allow having one
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
using a new SDP attribute "extmap-allowed-mixed" specified in this
document.
The other major change is to update the requirement from the RTP
specification and[RFC5285] that the header extension "is designed so
that the header extension MAY be ignored". This is described in
section 4.1.
The transmission consideration section (4.1.1) adds more text to
clarify when and how many times to send the RTP header extension to
provide higher probability of delivery
>The security section was expanded
The rest of the changes are editorial.
12. Acknowledgments
Both Brian Link and John Lazzaro provided helpful comments on an Both Brian Link and John Lazzaro provided helpful comments on an
initial draft of this document. Colin Perkins was helpful in initial draft of this document. Colin Perkins was helpful in
reviewing and dealing with the details. The use of URNs for IETF- reviewing and dealing with the details. The use of URNs for IETF-
defined extensions was suggested by Jonathan Lennox, and Pete Cordell defined extensions was suggested by Jonathan Lennox, and Pete Cordell
was instrumental in improving the padding wording. Dave Oran was instrumental in improving the padding wording. Dave Oran
provided feedback and text in the review. Mike Dolan contributed the provided feedback and text in the review. Mike Dolan contributed the
two-byte header form. Magnus Westerlund and Tom Taylor were two-byte header form. Magnus Westerlund and Tom Taylor were
instrumental in managing the registration text. instrumental in managing the registration text.
12. References 13. References
12.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, February
1999. 1999.
[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, July 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. 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)",
skipping to change at page 19, line 32 skipping to change at page 19, line 48
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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>.
12.2. Informative References 13.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
with Session Description Protocol (SDP)", RFC 3264, June "RTP Control Protocol Extended Reports (RTCP XR)",
2002. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011, DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>. <http://www.rfc-editor.org/info/rfc6464>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
Authors' Addresses Authors' Addresses
Roni Even (editor) Roni Even (editor)
Huawei Technologies Huawei Technologies
Shabazi 12A Shabazi 12A
Tel Aviv Tel Aviv
Israel Israel
Email: Roni.even@mail01.huawei.com Email: Roni.even@mail01.huawei.com
David Singer David Singer
 End of changes. 31 change blocks. 
77 lines changed or deleted 131 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/