Audio/Video Transport Core Maintenance Q. Wu Internet-Draft R. Even Updates: 3551,5761 (if approved) R. Huang Intended status: Standards Track Huawei Expires: March 13, 2014 September 9, 2013 Guideline for dynamic payload type number usage policy draft-wu-avtcore-dynamic-pt-usage-01 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 provides guidelines for payload type number usage policy when dynamic payload type allocation is used. Also this document updates closed IANA registry "RTP Payload types (PT) for standard audio and video encodings". 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 13, 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 Wu, et al. Expires March 13, 2014 [Page 1] Internet-Draft Dynamic PT Usage September 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Use of Dynamic payload type . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Wu, et al. Expires March 13, 2014 [Page 2] Internet-Draft Dynamic PT Usage September 2013 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, 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 provides guidelines for payload type number usage policy when dynamic payload type allocation is used. Also this document updates closed IANA registry "RTP Payload types (PT) for standard audio and video encodings". Wu, et al. Expires March 13, 2014 [Page 3] Internet-Draft Dynamic PT Usage September 2013 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]. Wu, et al. Expires March 13, 2014 [Page 4] Internet-Draft Dynamic PT Usage September 2013 3. 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 new 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 types are used, SDP [RFC4566] or other protocols such as ITU-T Recommendation H.323/H.245[H323] [H245] are used to establish dynamic mapping between a payload type and an encoding. [RFC5761] discusses conflicts that may happen when multiplexing RTP and RTCP is the same transport stream. When considering which payload type numbers should be used for mapping RTP dynamic streams, the documents does not differentiate between the cases when RTP and RTCP are multiplexed or not. When the dynamic mapping is needed, implementers can use the payload types in the lower range for dynamic payload type allocation, including the overriding the static ones. 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]for reserved values) and 64, 65 (see [RFC5761]for reserved value). If more Payload type numbers are needed, then applications may override the static types[0, 3-18,25,26,28] map encodings to these defined static payload type but this may cause problems for applications that may assume a specific payload format based on the Payload Type ignoring the mapping in the signaling. If the application is sure that multiplexing RTP and RTCP are not used the range 66 and 95 MAY be used but to add extra caution it will be better to use the pt numbers that are not conflicting with the currently assigned RTCP values. The closed IANA registry "RTP Payload types (PT) for standard audio and video encodings" is updated as follows: RTP Payload types (PT) for standard audio and video encodings - Closed Wu, et al. Expires March 13, 2014 [Page 5] Internet-Draft Dynamic PT Usage September 2013 Registration Procedure(s) Registry closed; see [RFC3551], Section 3 Reference [RFC3551] [RFC5761][RFCxxxx] Note The RFC "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] specifies an initial set "payload types". This list maintains and extends that list. The list is update by [RFCxxxx] to allow using more pt numbers for dynamic mapping. Encoding Audio/Video Clock PT Name (A/V) Rate Channels Reference 0 PCMU A 8000 1 [RFC3551] 1 Reserved-may be used for dynamic mapping [RFCxxxx] 2 Reserved-may be used for dynamic mapping [RFCxxxx] 3 GSM A 8000 1 [RFC3551] 4 G723 A 8000 1 [Vineet_Kumar][RFC3551] 5 DVI4 A 8000 1 [RFC3551] 6 DVI4 A 16000 1 [RFC3551] 7 LPC A 8000 1 [RFC3551] 8 PCMA A 8000 1 [RFC3551] 9 G722 A 8000 1 [RFC3551] 10 L16 A 44100 2 [RFC3551] 11 L16 A 44100 1 [RFC3551] 12 QCELP A 8000 1 [RFC3551] 13 CN A 8000 1 [RFC3389] 14 MPA A 90000 [RFC3551][RFC2250] 15 G728 A 8000 1 [RFC3551] Wu, et al. Expires March 13, 2014 [Page 6] Internet-Draft Dynamic PT Usage September 2013 16 DVI4 A 11025 1 [Joseph_Di_Pol] 17 DVI4 A 22050 1 [Joseph_Di_Pol] 18 G729 A 8000 1 [RFC3551] 19 Reserved-may be used for dynamic mapping [RFCxxxx] 20 Unassigned A 21 Unassigned A 22 Unassigned A 23 Unassigned A 24 Unassigned V 25 CelB V 90000 [RFC2029] 26 JPEG V 90000 [RFC2435] 27 Unassigned V 28 nv V 90000 [RFC3551] 29 Unassigned V 30 Unassigned V 31 H261 V 90000 [RFC4587] 32 MPV V 90000 [RFC2250] 33 MP2T AV 90000 [RFC2250] 34 H263 V 90000 [Chunrong_Zhu] 35-63 Unassigned 64-65 Reserved-may be used for dynamic mapping [RFCxxxx] 66-71 Reserved for RTCP conflict avoidance [RFC5761] 72-82 Reserved already used by RTCP [RFC5761] 83-95 Reserved for RTCP conflict avoidance [RFC5761] Wu, et al. Expires March 13, 2014 [Page 7] Internet-Draft Dynamic PT Usage September 2013 96-127 dynamic [RFC3551] The table includes the different set of changes and make the current state clear. This should have the original table in the "RTP Payload types (PT) for standard audio and video encodings"registry with the following changes: o Change 1,2, 19 64-65 from "Reserved" to "reserved may be used for dynamic mapping" and oreference this RFC. o Change 66-71 to reserved for rtcp conflict avoidance. o Change 72-82 to reserved used by RTCP. o Change 83-95 to reserved for RTCP conflict avoidance. 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? Wu, et al. Expires March 13, 2014 [Page 8] Internet-Draft Dynamic PT Usage September 2013 4. 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]. Wu, et al. Expires March 13, 2014 [Page 9] Internet-Draft Dynamic PT Usage September 2013 5. 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]. The table in section 3 replaces the current closed table. Wu, et al. Expires March 13, 2014 [Page 10] Internet-Draft Dynamic PT Usage September 2013 6. 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. Wu, et al. Expires March 13, 2014 [Page 11] Internet-Draft Dynamic PT Usage September 2013 7. References 7.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. 7.2. Informative References [H246] ITU, "Advanced video coding for generic audiovisual services", Recommendation H.264, January 2012. [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. Wu, et al. Expires March 13, 2014 [Page 12] Internet-Draft Dynamic PT Usage September 2013 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 13, 2014 [Page 13]