Audio/Video Transport Core Maintenance Q. Wu
Internet-Draft R. Even
Updates: 3551,5761 (if approved) R. Huang
Intended status: Standards Track Huawei
Expires: April 24, 2014 October 21, 2013
Guideline for dynamic payload type number usage policy
draft-wu-avtcore-dynamic-pt-usage-02
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 April 24, 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 April 24, 2014 [Page 1]
Internet-Draft Dynamic PT Usage October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Use of Dynamic payload type . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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".
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 April 24, 2014 [Page 2]
Internet-Draft Dynamic PT Usage October 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
MUST be named as "encoding name" by a registered media subtype
defined in the "RTP Payload Format media types" registry. The
"encoding name" in the RTP payload type registry is also registered
as a media subtype under the media type "audio" or "video" in the
"RTP Payload Format media types" registry.
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 [96-127]for dynamic payload types. 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 H.261 FIR or H.261
NACK is not used. However using 64,65 may potentially cause
collisions with legacy use. If more Payload type numbers are needed,
then applications may override the static types[0,
3-18,25,26,28,31-34] and map encodings to these defined static
payload type but this may cause problems for applications that ignore
the mapping in the signaling and may assume a specific payload format
based on the Payload Type. 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.
Wu, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Dynamic PT Usage October 2013
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
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]
Wu, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Dynamic PT Usage October 2013
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]
Wu, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Dynamic PT Usage October 2013
72-82 Reserved already used by RTCP [RFC5761]
83-95 Reserved for RTCP conflict avoidance [RFC5761]
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 reference this document.
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?
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].
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 April 24, 2014 [Page 6]
Internet-Draft Dynamic PT Usage October 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.
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.
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Wu, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Dynamic PT Usage October 2013
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 April 24, 2014 [Page 8]