draft-ietf-avtcore-rfc5285-bis-02.txt   draft-ietf-avtcore-rfc5285-bis-03.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: November 12, 2016 H. Desineni Expires: February 13, 2017 H. Desineni
May 11, 2016 August 12, 2016
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-02.txt draft-ietf-avtcore-rfc5285-bis-03.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 November 12, 2016. This Internet-Draft will expire on February 13, 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. transmission considertions . . . . . . . . . . . . . 4
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Header Extension type consideration . . . . . . . . . 5
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 8 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 8
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. . . . . . . . . . . . . . . . . . . . . . 10 header extensions. . . . . . . . . . . . . . . . . . . . . . 11
7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 14 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 15
10.2. Registration of the SDP extmap Attribute . . . . . . . . 16 10.2. Registration of the SDP extmap Attribute . . . . . . . . 17
10.3. Registration of the SDP Attribute . . . . . . . . . . . 16 10.3. Registration of the SDP Attribute . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 30 skipping to change at page 4, line 33
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].
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
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
delivered to the receiver:
1. The probability for packet loss and burst loss determine how many
repetitions of the header extensions will be required to reach a
targeted delivery probability, and if burst loss is likely, what
distribution would be needed to avoid getting all repetitions of
the header extensions lost in a single burst.
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
these packets, as they share fate. Instead, at most one instance
of the header extension per independently decodable set of media
data would be a more efficient use of the bandwidth.
3. How early the Header Extension item information is needed, from
the first received RTP data or only after some set of packets are
received, can guide if the header extension(s) should be in all
of the first N packets or be included only once per set of
packets, for example once per video frame.
4. The use of RTP level robustness mechanisms, such as RTP
retransmission [RFC4588], or Forward Error Correction, e.g.,
[RFC5109] may treat packets differently from a robustness
perspective, and header extensions should be added to packets
that get a treatment corresponding to the relative importance of
receiving the information.
As a summary, the number of header extension transmissions should be
tailored to a desired probability of delivery taking the receiver
population size into account. For the very basic case, N repetitions
of the header extensions should be sufficient, but may not be
optimal. N is selected so that the header extension target delivery
probability reaches 1-P^N, where P is the probability of packet loss.
For point to point or small receiver populations, it might also be
possible to use feedback, such as RTCP, to determine when the
information in the header extensions has reached all receivers and
stop further repetitions. Feedback that can be used includes the
RTCP XR Loss RLE report block [RFC3611], which will indicate
successful delivery of particular packets. If the RTP/AVPF Transport
Layer Feedback Messages for generic NACK [RFC4585] is used, it can
indicate the failure to deliver an RTP packet with the header
extension, thus indicating the need for further repetitions. The
normal RTCP report blocks can also provide an indicator of successful
delivery, if no losses are indicated for a reporting interval
covering the RTP packets with the header extension. Note that loss
of an RTCP packet reporting on an interval where RTP header extension
packets were sent, does not necessarily mean that the RTP header
extension packets themselves were lost.
4.1.2. Header Extension type consideration
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
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
 End of changes. 8 change blocks. 
20 lines changed or deleted 77 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/