draft-ietf-avtcore-rfc5285-bis-04.txt   draft-ietf-avtcore-rfc5285-bis-05.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: May 1, 2017 H. Desineni Expires: May 18, 2017 H. Desineni
October 28, 2016 November 14, 2016
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-04.txt draft-ietf-avtcore-rfc5285-bis-05.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. The
document obsoletes RFC5285 document obsoletes RFC5285
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 1, 2017. This Internet-Draft will expire on May 18, 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . 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 . . 17
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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
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 4, line 33 skipping to change at page 4, line 33
specification SHOULD be used for data that can safely be ignored by specification SHOULD be used for data that can safely be ignored by
the recipient without affecting interoperability, there can be the recipient without affecting interoperability, there can be
essential header extensions for interoperability and intermediaries essential header extensions for interoperability and intermediaries
SHOULD NOT remove such header extensions. Note that the support of SHOULD NOT remove such header extensions. Note that the support of
header extension as specified in this recommendation is negotiated. header extension as specified in this recommendation is negotiated.
RTP Header extensions MUST NOT be used when the presence of the RTP Header extensions MUST NOT be used when the presence of the
extension has changed the form or nature of the rest of the packet in extension has changed the form or nature of the rest of the packet in
a way that is not compatible with the way the stream is signaled a way that is not compatible with the way the stream is signaled
(e.g., as defined by the payload type). Valid examples might include (e.g., as defined by the payload type). Valid examples might include
metadata that is additional to the usual RTP information, e.g. Audio metadata that is additional to the usual RTP information, e.g. Audio
level from Client to mixer [RFC6464]. level from Client to mixer [RFC6464]. Note that some header
extensions, for example MID [I-D.ietf-mmusic-sdp-bundle-negotiation]
might, if removed, disrupt the behaviour of the higher-level
application that builds on RTP, but are acceptable since they do not
affect interoperability of the RTP stack itself.
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 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
skipping to change at page 16, line 42 skipping to change at page 16, line 42
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; this specification, for header extensions (specifically, that
the header extension can be ignored or discarded without
breaking the RTP layer);
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 20, line 5 skipping to change at page 20, line 15
[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>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-34 (work in progress), October 2016.
[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,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
 End of changes. 7 change blocks. 
11 lines changed or deleted 23 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/