Guideline for dynamic payload type number usage policy
draft-wu-avtcore-dynamic-pt-usage-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Qin Wu , Roni Even , Rachel Huang | ||
| Last updated | 2013-08-30 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-avtcore-dynamic-pt-usage-00
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]