draft-ietf-avtcore-rfc5285-bis-06.txt   draft-ietf-avtcore-rfc5285-bis-07.txt 
AVTCore R. Even, Ed. AVTCore R. Even, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 5285 (if approved) D. Singer Obsoletes: 5285 (if approved) D. Singer
Intended status: Standards Track Apple, Inc. Intended status: Standards Track Apple, Inc.
Expires: August 18, 2017 H. Desineni Expires: August 29, 2017 H. Desineni
February 14, 2017 February 25, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-06.txt draft-ietf-avtcore-rfc5285-bis-07.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. This session are signaled in the setup information for that session. This
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 August 18, 2017. This Internet-Draft will expire on August 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 Considerations . . . . . . . . . . . . . 5 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5
4.1.2. Header Extension Type Considerations . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 9
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 9 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10
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. . . . . . . . . . . . . . . . . . . . . . 12
7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 13
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 16 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17
10.2. Registration of the SDP extmap Attribute . . . . . . . . 17 10.2. Registration of the SDP extmap Attribute . . . . . . . . 18
10.3. Registration of the SDP extmap-allow-mixed Attribute . . 18 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 18
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 42 skipping to change at page 4, line 42
since they'll fall back to the original, non-optimised, behaviour if since they'll fall back to the original, non-optimised, behaviour if
the header extension is not present. The use of header extensions to the header extension is not present. The use of header extensions to
convey information that will, if missing, disrupt the behaviour of a convey information that will, if missing, disrupt the behaviour of a
higher layer application that builds on top of RTP is only acceptable higher layer application that builds on top of RTP is only acceptable
if this doesn't affect interoperability at the RTP layer. For if this doesn't affect interoperability at the RTP layer. For
example, applications that use the SDP BUNDLE extension with the MID example, applications that use the SDP BUNDLE extension with the MID
RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to
correlate RTP streams with SDP m= lines likely won't work with full 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 functionality if the MID is missing, but the operation of the RTP
layer of those applications will be unaffected. Support for RTP layer of those applications will be unaffected. Support for RTP
header extensions based on this memo is negotoited using, for header extensions based on this memo is negotiated using, for
example, SDP offer answer [RFC3264]; intermediaries aware of the RTP example, SDP offer answer [RFC3264]; intermediaries aware of the RTP
header extensions are advised to be cautious when removing or header extensions are advised to be cautious when removing or
generating RTP header extensions see section 4.7 of [RFC7667]. 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 Considerations 4.1.1. Transmission Considerations
skipping to change at page 6, line 25 skipping to change at page 6, line 25
4.1.2. Header Extension Type Considerations 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.
an extension element with a value equal 0 MUST NOT have len greater
than 0. If such an extension element is encountered, its length
field MUST be ignored, processing of the entire extension MUST
terminate at that point, and only the extension elements present
prior to the element with ID 0 and len greater than 0 SHOULD be
considered.
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. 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.
 End of changes. 10 change blocks. 
18 lines changed or deleted 25 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/