Audio/Video Transport Core Maintenance working group Q. Wu Internet-Draft R. Even Updates: 3551,5761 (if approved) R. Huang Intended status: Standards Track Huawei Expires: March 03, 2014 August 30, 2013 Guideline for dynamic payload type number usage policy draft-wu-avtcore-dynamic-pt-usage-00 Abstract The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551 and provide guidelines for payload type number usage policy. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 03, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Wu, et al. Expires March 03, 2014 [Page 1] Internet-Draft Dynamic PT Usage August 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 2 3. Update to RFC3551 . . . . . . . . . . . . . . . . . . . . . . 2 4. Use of Dynamic payload type . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) [RFC3551] is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP- Based Feedback (RTP/SAVPF). RTP Payload type can have the values 0 to 127. The binding of RTP payload format to Payload type can be static or dynamic. [RFC3551] establishes the policy that no additional static payload types will be assigned beyond the ones defined. As described in RFC5761 [RFC5761], dynamic RTP payload types SHOULD be chosen first from the range 96-127. Values below 64 MAY be used if that is insufficient. However some implementations may still exhaust the dynamic payload type numbering space before re-using a payload type within the scope of a local transport address. This document updates RFC 3551 and provide guidelines for payload type number usage policy. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Update to RFC3551 Section 3 of " RTP Profile for Audio and Video Conferences with Minimal Control " [RFC3551] states: Wu, et al. Expires March 03, 2014 [Page 2] Internet-Draft Dynamic PT Usage August 2013 " This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided. " This document changes the quoted text as follows: " This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions. Support for multiple RTP streams in a single session which is recommended in order to reduce the number of open transport connections can exhaust the payload type space. " 4. Use of Dynamic payload type As described in section 3 of RFC3551 [RFC3551], the payload type number space is relatively small and cannot accommodate assignments for all existing and future encodings. The registry for RTP Payload types (PT) for standard audio and video encodings [http:// www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp- parameters-1] is closed. New payload formats(e.g.,H.264,VP8) MUST use dynamic payload type number assignment. Each payload format is named by a registered media subtype. The "encoding name" is also registered as a media subtype under the media type "audio" or "video". When these dynamic payload type are used, SDP [RFC4566] or other protocols such as ITU-T Recommendation H.323/H.245[H323] [H245] be used to establish dynamic mapping between a payload type and an encoding. Applications SHOULD first use values in the range for dynamic payload types [96-127]. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers [35-63] followed by [20-24], 27, [29-30]. If more payload type numbers are needed the application may use the reserved values 1,2,19 see [RFC3551] and 64, Wu, et al. Expires March 03, 2014 [Page 3] Internet-Draft Dynamic PT Usage August 2013 65 see [RFC5761] If more Payload type numbers are needed then mapping to the defined static payload type may be used [0, 3-18,25,26,28] but may cause problems for applications that may assume a specific payload format based on the Payload Type ignoring the mapping in the signaling. Editor note: do we want to recommend re-use of payload type in bundled m-lines if they map to the same payload format here? 5. Security Considerations This document modifies the IANA allocation of RTP Payload Types in relationship to RFC 3551. This policy change itself does not add security concerns to the ones in [RFC3551] and [RFC5761]. 6. IANA Considerations This section describes changes to the IANA Considerations sections outlined in RFC 3551 regarding the allocation of payload type number by IANA. Add to the note in http://www.iana.org/assignments/rtp-parameters/ rtp-parameters.xhtml the following text "Policy for mapping of dynamic payload type numbers to payload format is defined in RFCxxxx [this document]. 7. Acknowledgements The content of this document is the result of the work in the IETF Audio/Video Transport Core Maintenance (AVTCORE) working group. We would therefore like to thank all the working group members who were involved in that discussion. While it appears to be a fairly small change in the usage policy and allocation policy, the effect on implementations is rather dramatic. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. Wu, et al. Expires March 03, 2014 [Page 4] Internet-Draft Dynamic PT Usage August 2013 8.2. Informative References [H245] ITU, "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION", Recommendation H.245, May 2011. [H323] ITU, "Packet based multimedia communication systems", Recommendation H.323, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol ", RFC 4566, July 2006. Authors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: sunseawq@huawei.com Roni Even Huawei 14 David Hamelech Tel, Aviv 64953 Israel Email: ron.even.tlv@gmail.com Rachel Huang Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: Rachel@huawei.com Wu, et al. Expires March 03, 2014 [Page 5]