draft-ietf-avtcore-rfc5285-bis-13.txt   draft-ietf-avtcore-rfc5285-bis-14.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: January 23, 2018 R. Even, Ed. Expires: February 3, 2018 R. Even, Ed.
Huawei Technologies Huawei Technologies
July 22, 2017 August 2, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-13.txt draft-ietf-avtcore-rfc5285-bis-14.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 January 23, 2018. This Internet-Draft will expire on February 3, 2018.
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 14, line 10 skipping to change at page 14, line 10
If an extension map is offered as "sendrecv", explicitly or If an extension map is offered as "sendrecv", explicitly or
implicitly, and asymmetric behavior is desired, the SDP answer MAY be implicitly, and asymmetric behavior is desired, the SDP answer MAY be
changed to modify or add direction qualifiers for that extension. changed to modify or add direction qualifiers for that extension.
If an extension is marked as "sendonly" and the answerer desires to If an extension is marked as "sendonly" and the answerer desires to
receive it, the extension MUST be marked as "recvonly" in the SDP receive it, the extension MUST be marked as "recvonly" in the SDP
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. An answerer MAY want to respond that he supports the answer. An answerer MAY want to respond that he supports the
extension and may use it in the future will mark the extension as extension and does not want to receive it at the moment but may offer
to receive it in a future offer, will mark the extension as
"inactive" "inactive"
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. An answerer MAY want extension SHOULD remove it from the SDP answer. An answerer MAY want
to respond that he support this extension and may send in the future to respond that he support this extension yet has no intention of
or will be able to receive by marking the extension as "inactive" sending it now but may offer to send it in a future offer by marking
the extension as "inactive"
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). The local dentifiers MUST be unique in an session-level section). The local identifiers MUST be unique in an
RTP session and the same identifier MUST be used for the same offered RTP session and the same identifier MUST be used for the same offered
extension in the answer. A session update MAY change the direction extension in the answer. 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 17, line 48 skipping to change at page 17, line 48
This document updates the IANA consideration to reference this This document updates the IANA consideration to reference this
document and adds a new SDP attribute in section 10.3 document and adds a new SDP attribute in section 10.3
Note to IANA : change RFCxxxx to this RFC number and remove the note. Note to IANA : change RFCxxxx to this RFC number and remove the note.
10.1. Identifier Space for IANA to Manage 10.1. Identifier Space for IANA to Manage
The mapping from the naming URI form to a reference to a The mapping from the naming URI form to a reference to a
specification is managed by IANA. Insertion into this registry is specification is managed by IANA. Insertion into this registry is
under the requirements of "Expert Review" as defined in [RFC5226]. under the requirements of "Expert Review" as defined in [RFC8126].
The IANA will also maintain a server that contains all of the The IANA will also maintain a server that contains all of the
registered elements in a publicly accessible space. registered elements in a publicly accessible space.
Here is the formal declaration to comply with the IETF URN Sub- Here is the formal declaration to comply with the IETF URN Sub-
namespace specification [RFC3553]. namespace specification [RFC3553].
o Registry name: RTP Compact Header Extensions o Registry name: RTP Compact Header Extensions
o Specification: RFC 5285 and RFCs updating RFC 5285. o Specification: RFC 5285 and RFCs updating RFC 5285.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
be sent with the same ID. 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 registration of the extmap SDP
[RFC4566] attribute. [RFC4566] attribute.
o Contact Name and email address: IETF, contacted via o Contact Name and email address: IETF, contacted via
mmusic@ietf.org, or a successor address designated by IESG mmusic@ietf.org, or a successor address designated by IESG
Attribute Name: extmap Attribute Name: extmap
o Attribute Syntax: See section 8 of [RFCXXXX]. o Attribute Syntax: See section 8 of [RFCXXXX].
o Attribute Semantics: The details of appropriate values are given o Attribute Semantics: The details of appropriate values are given
in [RFC XXXX]. in [RFC XXXX].
skipping to change at page 23, line 5 skipping to change at page 23, line 5
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses Authors' Addresses
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
 End of changes. 11 change blocks. 
15 lines changed or deleted 17 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/