draft-ietf-avtcore-rfc5285-bis-11.txt   draft-ietf-avtcore-rfc5285-bis-12.txt 
AVTCore D. Singer AVTCore D. Singer
Internet-Draft Apple, Inc. Internet-Draft Apple, Inc.
Obsoletes: 5285 (if approved) H. Desineni Obsoletes: 5285 (if approved) H. Desineni
Intended status: Standards Track Qualcomm Intended status: Standards Track Qualcomm
Expires: November 3, 2017 R. Even, Ed. Expires: December 5, 2017 R. Even, Ed.
Huawei Technologies Huawei Technologies
May 2, 2017 June 3, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-11.txt draft-ietf-avtcore-rfc5285-bis-12.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 39 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 November 3, 2017. This Internet-Draft will expire on December 5, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . 9 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10 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. . . . . . . . . . . . . . . . . . . . . . 12 header extensions. . . . . . . . . . . . . . . . . . . . . . 12
7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13 7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17
10.2. Registration of the SDP extmap Attribute . . . . . . . . 18 10.2. Registration of the SDP extmap Attribute . . . . . . . . 19
10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 13, line 5 skipping to change at page 13, line 5
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 the cases 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).
When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute
is specified as normal category for the
[I-D.ietf-mmusic-sdp-mux-attributes]. This allows for only a subset
of the m-lines in the bundle group to offer extmap-allow-mixed. When
an answerer supporting the extmap-allow-mix attribute receives an
offer where only some of the m-lines in the bundle group include the
extmap-allow-mixed attribute, the answerer MUST receive this offer
and support mixed one-byte and two-bytes only for those m-lines.
Transmitters MUST only send RTP header extensions using mixed on
those RTP streams originating from those media sources (m=) blocks
that includes extmap-allow-mixed, and are RECOMMENDED to support
receiving mixed on all RTP streams being received in an RTP session
where at least one bundled m= block is indicating extmap-allow-mixed.
7. SDP Offer/Answer 7. SDP 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 SDP Offer/Answer [RFC3264] context, to permit: enhanced in an SDP Offer/Answer [RFC3264] context, to permit:
o asymmetric behavior (extensions sent in only one direction), o asymmetric behavior (extensions sent in only one direction),
o the offer of mutually exclusive alternatives, or o the offer of mutually exclusive alternatives, or
o the offer of more extensions than can be sent in a single session. o the offer of more extensions than can be sent in a single session.
skipping to change at page 15, line 30 skipping to change at page 15, line 37
m=video m=video
a=sendrecv a=sendrecv
a=extmap:1 URI-toffset a=extmap:1 URI-toffset
a=extmap:2/recvonly URI-gps-string a=extmap:2/recvonly URI-gps-string
a=extmap:3 URI-frametype a=extmap:3 URI-frametype
m=audio m=audio
a=sendrecv a=sendrecv
a=extmap:1/sendonly URI-toffset a=extmap:1/sendonly URI-toffset
When using [I-D.ietf-mmusic-sdp-bundle-negotiation] to bundle
multiple m-lines the extmap attribute falls under the special
category of [I-D.ietf-mmusic-sdp-mux-attributes]. All the m-lines in
a bundle group are considered to be part of the same local identifier
(ID) space. If an RTP header extension, i.e. a particular extension
URI and configuration using <extensionattributes>, is offered in
multiple m-lines that are part of the same bundle group it MUST use
the same ID in all of these m-lines. Each m-line in a bundle group
can include different RTP header extensions allowing for example
audio and video sources to use different sets of RTP header
extensions. It SHALL be assumed that for any RTP header extension,
difference in configuration using any of the <extensionattributes> is
important and need to be preserved to any receiver, thus requiring
assignment of different IDs. Any RTP header extension that do not
match this assumption MUST explicitly provide rules for what are
compatible configurations that can be sent with the same ID. The
directionality of the RTP header extensions in each m-line of the
bundle group are handled as the non-bundled case. This allows for
specifying different directionality for each of the repeated
extension URI in bundled group.
8. BNF Syntax 8. BNF Syntax
The syntax definition below uses ABNF according to [RFC5234]. The The syntax definition below uses ABNF according to [RFC5234]. The
syntax element 'URI' is defined in [RFC3986] (only absolute URIs are syntax element 'URI' is defined in [RFC3986] (only absolute URIs are
permitted here). The syntax element 'extmap' is an attribute as permitted here). The syntax element 'extmap' is an attribute as
defined in [RFC4566], i.e., "a=" precedes the extmap definition. defined in [RFC4566], i.e., "a=" precedes the extmap definition.
Specific extensionattributes are defined by the specification that Specific extensionattributes are defined by the specification that
defines a specific extension name; there can be several. defines a specific extension name; there can be several.
Name: extmap Name: extmap
skipping to change at page 18, line 32 skipping to change at page 18, line 48
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;
6. that the extension is generally applicable, for example point- 6. that the extension is generally applicable, for example point-
to-multipoint safe, and the specification correctly describes to-multipoint safe, and the specification correctly describes
limitations if they exist; and limitations if they exist; and
7. that the suggested naming URI form is appropriately chosen and 7. that the suggested naming URI form is appropriately chosen and
unique. unique.
8. That for [I-D.ietf-mmusic-sdp-bundle-negotiation] multiplexed
m-lines, any RTP header extension with difference in
configurations of <extensionattributes> that do not require
assignment of different IDs, MUST explicitly indicate this and
provide rules for what are compatible configurations that can
be sent with the same ID.
o Size and format of entries: a mapping from a naming URI string to o Size and format of entries: a mapping from a naming URI string to
a formal reference to a publicly available specification, with a a formal reference to a publicly available specification, with a
descriptive phrase and contact information. descriptive phrase and contact information.
o Initial assignments: none. o Initial assignments: none.
10.2. Registration of the SDP extmap Attribute 10.2. Registration of the SDP extmap Attribute
IANA is requested to update the registeration of the extmap SDP IANA is requested to update the registeration of the extmap SDP
[RFC4566] attribute. [RFC4566] attribute.
skipping to change at page 21, line 42 skipping to change at page 22, line 18
<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] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-38 (work in progress), April 2017.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>. 2003, <http://www.rfc-editor.org/info/rfc3553>.
 End of changes. 12 change blocks. 
11 lines changed or deleted 58 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/