idnits 2.17.1 draft-wu-avtcore-dynamic-pt-usage-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC5761, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3551, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3551, updated by this document, for RFC5378 checks: 1997-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2013) is 3834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'H245' is mentioned on line 112, but not defined == Missing Reference: '35-63' is mentioned on line 128, but not defined == Missing Reference: '20-24' is mentioned on line 128, but not defined == Missing Reference: '29-30' is mentioned on line 129, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 235, but not defined == Missing Reference: 'RFC3389' is mentioned on line 190, but not defined == Missing Reference: 'RFC2250' is mentioned on line 229, but not defined == Missing Reference: 'RFC2029' is mentioned on line 213, but not defined == Missing Reference: 'RFC2435' is mentioned on line 215, but not defined == Missing Reference: 'RFC4587' is mentioned on line 225, but not defined == Unused Reference: 'H246' is defined on line 305, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Core Maintenance Q. Wu 3 Internet-Draft R. Even 4 Updates: 3551,5761 (if approved) R. Huang 5 Intended status: Standards Track Huawei 6 Expires: April 24, 2014 October 21, 2013 8 Guideline for dynamic payload type number usage policy 9 draft-wu-avtcore-dynamic-pt-usage-02 11 Abstract 13 The RTP Profile for Audio and Video Conferences with Minimal Control 14 (RTP/AVP) is the basis for many other profiles, such as the Secure 15 Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for 16 Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 17 AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback 18 (RTP/SAVPF). This document provides guidelines for payload type 19 number usage policy when dynamic payload type allocation is used. 20 Also this document updates closed IANA registry "RTP Payload types 21 (PT) for standard audio and video encodings". 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 2 59 3. Use of Dynamic payload type . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The RTP Profile for Audio and Video Conferences with Minimal Control 71 (RTP/AVP) [RFC3551]is the basis for many other profiles, such as the 72 Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP 73 Profile for Real-time Transport Control Protocol (RTCP)-Based 74 Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP- 75 Based Feedback (RTP/SAVPF). RTP Payload type can have the values 0 76 to 127. The binding of RTP payload format to Payload type can be 77 static or dynamic. [RFC3551] establishes the policy that no 78 additional static payload types will be assigned beyond the ones 79 defined. As described in RFC5761, dynamic RTP payload types SHOULD 80 be chosen first from the range 96-127. Values below 64 MAY be used 81 if that is insufficient. 83 However some implementations may still exhaust the dynamic payload 84 type numbering space before re-using a payload type within the scope 85 of a local transport address. This document provides guidelines for 86 payload type number usage policy when dynamic payload type allocation 87 is used. Also this document updates closed IANA registry "RTP 88 Payload types (PT) for standard audio and video encodings". 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119]. 96 3. Use of Dynamic payload type 98 As described in section 3 of RFC3551 [RFC3551], the payload type 99 number space is relatively small and cannot accommodate assignments 100 for all existing and future encodings. The registry for RTP Payload 101 types (PT) for standard audio and video encodings [http:// 102 www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp- 103 parameters-1] is closed. New payload formats(e.g.,H.264,VP8) MUST 104 use dynamic payload type number assignment. Each new payload format 105 MUST be named as "encoding name" by a registered media subtype 106 defined in the "RTP Payload Format media types" registry. The 107 "encoding name" in the RTP payload type registry is also registered 108 as a media subtype under the media type "audio" or "video" in the 109 "RTP Payload Format media types" registry. 111 When these dynamic payload types are used, SDP [RFC4566] or other 112 protocols such as ITU-T Recommendation H.323/H.245[H323] [H245] are 113 used to establish dynamic mapping between a payload type and an 114 encoding. 116 [RFC5761] discusses conflicts that may happen when multiplexing RTP 117 and RTCP is the same transport stream. When considering which 118 payload type numbers should be used for mapping RTP dynamic streams, 119 the documents does not differentiate between the cases when RTP and 120 RTCP are multiplexed or not. 122 When the dynamic mapping is needed, implementers can use the payload 123 types in the lower range for dynamic payload type allocation, 124 including the overriding the static ones. Applications SHOULD first 125 use values in the range [96-127]for dynamic payload types. Those 126 applications which need to define more than 32 dynamic payload types 127 MAY bind codes below 96, in which case it is RECOMMENDED that 128 unassigned payload type numbers [35-63] followed by [20-24], 27, 129 [29-30]. If more payload type numbers are needed, the application 130 may use the reserved values 1,2,19 (see [RFC3551]for reserved values) 131 and 64, 65 (see [RFC5761]for reserved value)if H.261 FIR or H.261 132 NACK is not used. However using 64,65 may potentially cause 133 collisions with legacy use. If more Payload type numbers are needed, 134 then applications may override the static types[0, 135 3-18,25,26,28,31-34] and map encodings to these defined static 136 payload type but this may cause problems for applications that ignore 137 the mapping in the signaling and may assume a specific payload format 138 based on the Payload Type. If the application is sure that 139 multiplexing RTP and RTCP are not used, the range 66 and 95 MAY be 140 used but to add extra caution it will be better to use the pt numbers 141 that are not conflicting with the currently assigned RTCP values. 143 The closed IANA registry "RTP Payload types (PT) for standard audio 144 and video encodings" is updated as follows: 146 RTP Payload types (PT) for standard audio and video encodings - Closed 148 Registration Procedure(s) 150 Registry closed; see [RFC3551], Section 3 152 Reference 153 [RFC3551] [RFC5761][RFCxxxx] 154 Note 156 The RFC "RTP Profile for Audio and Video Conferences with Minimal 157 Control" [RFC3551] specifies an initial set "payload types". 158 This list maintains and extends that list. The list is update by 159 [RFCxxxx] to allow using more pt numbers for dynamic mapping. 161 Encoding Audio/Video Clock 162 PT Name (A/V) Rate Channels Reference 164 0 PCMU A 8000 1 [RFC3551] 166 1 Reserved-may be used for dynamic mapping [RFCxxxx] 168 2 Reserved-may be used for dynamic mapping [RFCxxxx] 170 3 GSM A 8000 1 [RFC3551] 172 4 G723 A 8000 1 [Vineet_Kumar][RFC3551] 174 5 DVI4 A 8000 1 [RFC3551] 176 6 DVI4 A 16000 1 [RFC3551] 178 7 LPC A 8000 1 [RFC3551] 180 8 PCMA A 8000 1 [RFC3551] 182 9 G722 A 8000 1 [RFC3551] 184 10 L16 A 44100 2 [RFC3551] 186 11 L16 A 44100 1 [RFC3551] 188 12 QCELP A 8000 1 [RFC3551] 190 13 CN A 8000 1 [RFC3389] 191 14 MPA A 90000 [RFC3551][RFC2250] 193 15 G728 A 8000 1 [RFC3551] 195 16 DVI4 A 11025 1 [Joseph_Di_Pol] 197 17 DVI4 A 22050 1 [Joseph_Di_Pol] 199 18 G729 A 8000 1 [RFC3551] 201 19 Reserved-may be used for dynamic mapping [RFCxxxx] 203 20 Unassigned A 205 21 Unassigned A 207 22 Unassigned A 209 23 Unassigned A 211 24 Unassigned V 213 25 CelB V 90000 [RFC2029] 215 26 JPEG V 90000 [RFC2435] 217 27 Unassigned V 219 28 nv V 90000 [RFC3551] 221 29 Unassigned V 223 30 Unassigned V 225 31 H261 V 90000 [RFC4587] 227 32 MPV V 90000 [RFC2250] 229 33 MP2T AV 90000 [RFC2250] 231 34 H263 V 90000 [Chunrong_Zhu] 233 35-63 Unassigned 235 64-65 Reserved-may be used for dynamic mapping [RFCxxxx] 237 66-71 Reserved for RTCP conflict avoidance [RFC5761] 238 72-82 Reserved already used by RTCP [RFC5761] 240 83-95 Reserved for RTCP conflict avoidance [RFC5761] 242 96-127 dynamic [RFC3551] 244 The table includes the different set of changes and make the current 245 state clear. This should have the original table in the "RTP Payload 246 types (PT) for standard audio and video encodings"registry with the 247 following changes: 249 o Change 1,2, 19 64-65 from "Reserved" to "reserved may be used for 250 dynamic mapping" and reference this document. 252 o Change 66-71 to reserved for rtcp conflict avoidance. 254 o Change 72-82 to reserved used by RTCP. 256 o Change 83-95 to reserved for RTCP conflict avoidance. 258 Editor note: do we want to recommend re-use of payload type in 259 bundled m-lines if they map to the same payload format here? 261 4. Security Considerations 263 This document modifies the IANA allocation of RTP Payload Types in 264 relationship to RFC 3551. This policy change itself does not add 265 security concerns to the ones in [RFC3551] and [RFC5761]. 267 5. IANA Considerations 269 This section describes changes to the IANA Considerations sections 270 outlined in RFC 3551 regarding the allocation of payload type number 271 by IANA. 273 Add to the note in http://www.iana.org/assignments/rtp-parameters/ 274 rtp-parameters.xhtml the following text "Policy for mapping of 275 dynamic payload type numbers to payload format is defined in RFCxxxx 276 [this document]. 278 The table in section 3 replaces the current closed table. 280 6. Acknowledgements 282 The content of this document is the result of the work in the IETF 283 Audio/Video Transport Core Maintenance (AVTCORE) working group. We 284 would therefore like to thank all the working group members who were 285 involved in that discussion. While it appears to be a fairly small 286 change in the usage policy and allocation policy, the effect on 287 implementations is rather dramatic. 289 7. References 291 7.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", March 1997. 296 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 297 Video Conferences with Minimal Control", RFC 3551, July 298 2003. 300 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 301 Control Packets on a Single Port", RFC 5761, April 2010. 303 7.2. Informative References 305 [H246] ITU, "Advanced video coding for generic audiovisual 306 services", Recommendation H.264, January 2012. 308 [H323] ITU, "Packet based multimedia communication systems", 309 Recommendation H.323, July 2003. 311 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 312 Description Protocol", RFC 4566, July 2006. 314 Authors' Addresses 316 Qin Wu 317 Huawei 318 101 Software Avenue, Yuhua District 319 Nanjing, Jiangsu 210012 320 China 322 Email: sunseawq@huawei.com 323 Roni Even 324 Huawei 325 14 David Hamelech 326 Tel, Aviv 64953 327 Israel 329 Email: ron.even.tlv@gmail.com 331 Rachel Huang 332 Huawei Technologies Co., Ltd. 333 101 Software Avenue, Yuhua District 334 Nanjing, Jiangsu 210012 335 China 337 Email: Rachel@huawei.com