draft-ietf-avtcore-rfc5285-bis-08.txt   draft-ietf-avtcore-rfc5285-bis-09.txt 
AVTCore R. Even, Ed. AVTCore D. Singer
Internet-Draft Huawei Technologies Internet-Draft Apple, Inc.
Obsoletes: 5285 (if approved) D. Singer Obsoletes: 5285 (if approved) H. Desineni
Intended status: Standards Track Apple, Inc. Intended status: Standards Track Qualcomm
Expires: August 31, 2017 H. Desineni Expires: October 4, 2017 R. Even, Ed.
February 27, 2017 Huawei Technologies
April 2, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-08.txt draft-ietf-avtcore-rfc5285-bis-09.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 39
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 31, 2017. This Internet-Draft will expire on October 4, 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 3, line 43 skipping to change at page 3, line 43
This mechanism provides an alternative to the practice of burying This mechanism provides an alternative to the practice of burying
associated metadata into the media format bit stream. This has often associated metadata into the media format bit stream. This has often
been done in media data sent over fixed-bandwidth channels. Once been done in media data sent over fixed-bandwidth channels. Once
this is done, a decoder for the specific media format needs to this is done, a decoder for the specific media format needs to
extract the metadata. Also, depending on the media format, the extract the metadata. Also, depending on the media format, the
metadata can be added at the time of encoding the media so that the metadata can be added at the time of encoding the media so that the
bit-rate used for the metadata is taken into account. But the bit-rate used for the metadata is taken into account. But the
metadata can be unknown at that time. Inserting metadata at a later metadata can be unknown at that time. Inserting metadata at a later
time can cause a decode and re-encode to meet bit-rate requirements. time can cause a decode and re-encode to meet bit-rate requirements.
In some cases, a more appropriate, higher-level mechanism can be In some cases, a more appropriate, higher-level mechanism may be
available, and if so, it can be used. For cases where a higher-level available, and if so, it can be used. For cases where a higher-level
mechanism is not available, it is better to provide a mechanism at mechanism is not available, it is better to provide a mechanism at
the RTP level than have the metadata be tied to a specific form of the RTP level than have the metadata be tied to a specific form of
media data. media data.
4. Packet Design 4. Packet Design
4.1. General 4.1. General
The following design is fit into the "header extension" of the RTP The following design is fit into the "header extension" of the RTP
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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
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:
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 ID value 0 is reserved for padding and MUST NOT be used as a The ID value 0 is reserved for padding and MUST NOT be used as a
local identifier. local identifier.
An extension element with an ID value equal 0 MUST NOT have len An extension element with an ID value equal 0 MUST NOT have len field
greater than 0. If such an extension element is encountered, its greater than 0. If such an extension element is encountered, its
length field MUST be ignored, processing of the entire extension MUST length field MUST be ignored, processing of the entire extension MUST
terminate at that point, and only the extension elements present terminate at that point, and only the extension elements present
prior to the element with ID 0 and len greater than 0 SHOULD be prior to the element with ID 0 and len field greater than 0 SHOULD be
considered. 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.
Only the extension element types that match the header extension Extension element types that dp not match the header extension
format, i.e. one- or two-byte, MUST be used in that RTP packet. format, i.e. one- or two-byte, MUST NOT be used in that RTP packet.
Transmitters SHOULD NOT use the two-byte form when all extensions are Transmitters SHOULD NOT use the two-byte form when all extensions are
small enough for the one-byte header form. Transmitters that intend small enough for the one-byte header form. Transmitters that intend
to send the two-byte form SHOULD negotiate the use of IDs above 14 if to send the two-byte form SHOULD negotiate the use of IDs above 14 if
they want to let the Receivers know that they intend to use two-byte 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 form, for example if the RTP header extension is longer than 16
bytes. A transmitter MAY be aware that an intermediary may add RTP bytes. A transmitter may be aware that an intermediary may add RTP
header extensions in this case, the transmitter SHOULD use two-byte header extensions in this case, the transmitter SHOULD use two-byte
form. 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
skipping to change at page 7, line 41 skipping to change at page 7, line 41
unless the RTP header compression module is updated to recognize the unless the RTP header compression module is updated to recognize the
extension header. If header extensions are present in some packets, extension header. If header extensions are present in some packets,
but not in others, this can also reduce compression efficiency by but not in others, this can also reduce compression efficiency by
requiring an update to the fixed header to be conveyed when header requiring an update to the fixed header to be conveyed when header
extensions start or stop being sent. The interactions of the RTP extensions start or stop being sent. The interactions of the RTP
header extension and header compression is explored further in header extension and header compression is explored further in
[RFC2508] and [RFC3095]. [RFC2508] and [RFC3095].
4.2. One-Byte Header 4.2. One-Byte Header
In the one-byte header form of extensions, the 16-bit value REQUIRED In the one-byte header form of extensions, the 16-bit value required
by the RTP specification for a header extension, labeled in the RTP by the RTP specification for a header extension, labeled in the RTP
specification as "defined by profile", MUST have the fixed bit specification as "defined by profile", MUST have the fixed bit
pattern 0xBEDE (the first version of this specification was written pattern 0xBEDE (the first version of this specification was written
on the feast day of the Venerable Bede). on the feast day of the Venerable Bede).
Each extension element MUST starts with a byte containing an ID and a Each extension element MUST starts with a byte containing an ID and a
length: length:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 12, line 22 skipping to change at page 12, line 22
In order to allow for backward interoperability with systems that do In order to allow for backward interoperability with systems that do
not support mixing of one byte and two bytes header extensions this not support mixing of one byte and two bytes header extensions this
document defines the "a=extmap-allow-mixed" Session Description document defines the "a=extmap-allow-mixed" Session Description
Protocol (SDP) [RFC4566] attribute to indicate if the participant is Protocol (SDP) [RFC4566] attribute to indicate if the participant is
capable of supporting this new mode. The attribute takes no value. capable of supporting this new mode. The attribute takes no value.
This attribute can be used at the session or media levels. A This attribute can be used at the session or media levels. A
participant that proposes the use of this mode SHALL itself support participant that proposes the use of this mode SHALL itself support
the reception of mixed one byte and two bytes header extensions. the reception of mixed one byte and two bytes header extensions.
The negotiation for mixed one byte and two bytes extension MUST be If offer/answer [RFC3264] is supported and used,the negotiation for
negotiated in offer/answer [RFC3264]. In the absence of negotiation mixed one byte and two bytes extension MUST be negotiated using
using offer/answer, mixed headers MUST NOT occur unless the offer/answer [RFC3264]. In the absence of negotiations using offer/
transmitter has some (out of band) knowledge that all potential answer, for example when declarative SDP is used, mixed headers MUST
recipients support this mode. NOT occur unless the transmitter has some (out of band) knowledge
that all potential recipients support this mode.
The formal definition of this attribute is: The formal definition of this attribute is:
Name: extmap-allow-mixed Name: extmap-allow-mixed
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Example: Example:
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 where the attribute has been attribute in the answer. In the cases where the attribute has been
excluded, both clients SHALL NOT use mixed one bytes and two bytes excluded, both clients SHALL NOT use mixed one bytes and two bytes
extensions in the same RTP stream but MAY use one-byte or two-bytes extensions in the same RTP stream but MAY use one-byte or two-bytes
form exclusively (see section 4.1.2). form exclusively (see section 4.1.2).
7. Offer/Answer 7. Offer/Answer
The simple signaling described above for the extmap attribute MAY be The simple signaling described above for the extmap attribute MAY be
enhanced in an offer/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),
skipping to change at page 13, line 50 skipping to change at page 13, line 50
answer. An answerer that has no desire to receive the extension or answer. An answerer that has no desire to receive the extension or
does not understand the extension SHOULD remove it from the SDP does not understand the extension SHOULD remove it from the SDP
answer. answer.
If an extension is marked as "recvonly" and the answerer desires to If an extension is marked as "recvonly" and the answerer desires to
send it, the extension MUST be marked as "sendonly" in the SDP send it, the extension MUST be marked as "sendonly" in the SDP
answer. An answerer that has no desire to, or is unable to, send the answer. An answerer that has no desire to, or is unable to, send the
extension SHOULD remove it from the SDP answer. extension SHOULD remove it from the SDP answer.
Local identifiers in the valid range inclusive in an offer or answer Local identifiers in the valid range inclusive in an offer or answer
MUST NOT be used more than once per media section (including the must not be used more than once per media section (including the
session-level section). A session update MAY change the direction session-level section). A session update MAY change the direction
qualifiers of extensions under use. A session update MAY add or qualifiers of extensions under use. A session update MAY add or
remove extension(s). Identifiers values in the valid range MUST NOT remove extension(s). Identifiers values in the valid range MUST NOT
be altered (remapped). be altered (remapped).
Note that, under this rule, the same local identifier cannot be used Note that, under this rule, the same local identifier cannot be used
for two extensions for the same media, even when one is "sendonly" for two extensions for the same media, even when one is "sendonly"
and the other "recvonly", as it would then be impossible to make and the other "recvonly", as it would then be impossible to make
either of them sendrecv (since re-numbering is not permitted either). either of them sendrecv (since re-numbering is not permitted either).
skipping to change at page 16, line 33 skipping to change at page 16, line 33
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 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 Extensions usage is negotiated using [RFC3264] so integrity
protection and end-to-end authentication MUST be used. The security protection and end-to-end authentication MUST be implemented. The
considerations of [RFC3264] MUST be followed, to prevent, for security considerations of [RFC3264] MUST be followed, to prevent,
example, extension usage blocking. 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. In order to prevent DOS attacks, for or integrity protected. In order to prevent DOS attacks, for
example, by changing the header extension integrity protection SHOULD example, by changing the header extension integrity protection SHOULD
be used. Lower layer security protection like DTLS[RFC6347] MAY be be used. Lower layer security protection like DTLS[RFC6347] MAY be
used. RTP header extensions can carry sensitive information for used. RTP header extensions can carry sensitive information for
which participants in multimedia sessions want confidentiality. which participants in multimedia sessions want confidentiality.
skipping to change at page 22, line 23 skipping to change at page 22, line 23
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015, DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>. <http://www.rfc-editor.org/info/rfc7667>.
Authors' Addresses Authors' Addresses
Roni Even (editor)
Huawei Technologies
Tel Aviv
Israel
Email: Roni.even@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
Qualcomm
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
Roni Even (editor)
Huawei Technologies
Tel Aviv
Israel
Email: Roni.even@huawei.com
 End of changes. 18 change blocks. 
34 lines changed or deleted 30 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/