| 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 12, 2014 | September 08, 2013 |
Guideline for dynamic payload type number usage policy
draft-wu-avtcore-dynamic-pt-usage-01
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”.
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 12, 2014.
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 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.
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”.
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].
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.
RTP Payload types (PT) for standard audio and video encodings - Closed
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]
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]
96-127 dynamic [RFC3551]
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:
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].
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.
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.
| [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. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [H323] | ITU, "Packet based multimedia communication systems", Recommendation H.323, July 2003. |
| [H246] | ITU, "Advanced video coding for generic audiovisual services", Recommendation H.264, January 2012. |