draft-ietf-avtcore-rfc5285-bis-00.txt   draft-ietf-avtcore-rfc5285-bis-01.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 2, 2016 H. Desineni Expires: June 25, 2016 H. Desineni
November 30, 2015 December 23, 2015
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-00.txt draft-ietf-avtcore-rfc5285-bis-01.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 2, 2016. This Internet-Draft will expire on June 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 24 skipping to change at page 2, line 24
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 7
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 8 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 8
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. . . . . . . . . . . . . . . . . . . . . . 10 header extensions. . . . . . . . . . . . . . . . . . . . . . 10
7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 11
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 15 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 14
10.2. Registration of the SDP extmap Attribute . . . . . . . . 16 10.2. Registration of the SDP extmap Attribute . . . . . . . . 16
10.3. Registration of the SDP Attribute . . . . . . . . . . . 17 10.3. Registration of the SDP Attribute . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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 inherits the requirement from the RTP This specification updates the requirement from the RTP specification
specification that the header extension "is designed so that the that the header extension "is designed so that the header extension
header extension may be ignored". To be specific, header extensions may be ignored". To be specific, header extensions using this
using this specification MUST only be used for data that can safely specification SHOULD be used for data that can safely be ignored by
be ignored by the recipient without affecting interoperability, and the recipient without affecting interoperability, there may be
MUST NOT be used when the presence of the extension has changed the essential header extensions for interoperability and intermediaries
form or nature of the rest of the packet in a way that is not should not remove such header extensions. Note that the support of
compatible with the way the stream is signaled (e.g., as defined by header extension as specified in this recommendation is negotiated.
the payload type). Valid examples might include metadata that is RTP Header extensions MUST NOT be used when the presence of the
additional to the usual RTP information. 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
(e.g., as defined by the payload type). Valid examples might include
metadata that is additional to the usual RTP information, e.g. Audio
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
skipping to change at page 4, line 48 skipping to change at page 4, line 52
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 headers all receivers. A stream MUST contain only one-byte or two-byte
unless it is known that all recipients support mixing, either by headers unless it is known that all recipients support mixing, either
offer/answer negotiation (see section 6) or by out-of-band knowledge. by offer/answer negotiation (see section 6) or by out-of-band
One-byte and two-byte headers MUST NOT be mixed in a single RTP knowledge. One-byte and two-byte headers MUST NOT be mixed in a
packet. Transmitters SHOULD NOT use the two-byte form when all single RTP packet. Transmitters SHOULD NOT use the two-byte form
extensions are small enough for the one-byte header form. when all extensions are small enough for the one-byte header form. 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 required), and parsing stops at the earlier element (no alignment is required), and parsing stops at the earlier
of the end of the entire header extension, or in one-byte headers of the end of the entire header extension, or in one-byte headers
only case, on encountering an identifier with the reserved value of only case, on encountering an identifier with the reserved value of
skipping to change at page 14, line 25 skipping to change at page 14, line 25
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
This defines only a place to transmit information; the security This document defines only a place to transmit information; the
implications of the extensions must be discussed with those security implications of each of the extensions must be discussed
extensions. with those extensions.
Care should be taken when defining extensions. Clearly, they should
be solely informative, but even when the information is extracted,
should not cause security concerns.
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 may 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. Therefore, it is inappropriate to place or integrity protected. RTP header extensions may carry sensitive
information in header extensions that cause security problems if information for which participants in multimedia sessions want
disclosed, unless the entire RTP packet is protected by a lower-layer confidentiality. RFC6904 [RFC6904] provides a mechanism, extending
security protocol providing both confidentiality and integrity the mechanisms of SRTP, to selectively encrypt RTP header extensions
capability. 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
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
skipping to change at page 18, line 31 skipping to change at page 18, line 27
[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, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
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
Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>.
12.2. Informative References 12.2. Informative References
[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, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[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>.
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
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
Harikishan Desineni Harikishan Desineni
10001 Pacific Heights Blvd 10001 Pacific Heights Blvd
San Diego, CA 92121 San Diego, CA 92121
USA USA
Phone: +1 858 845 8996 Phone: +1 858 845 8996
EMail: hdesinen@quicinc.com Email: hdesinen@quicinc.com
 End of changes. 14 change blocks. 
36 lines changed or deleted 49 lines changed or added

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