One document matched: draft-wu-avtcore-dynamic-pt-usage-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-avtcore-dynamic-pt-usage-01"
ipr="trust200902" updates="3551,5761">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Dynamic PT Usage">Guideline for dynamic payload type number
usage policy</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street>14 David Hamelech</street>
<city>Tel</city>
<region>Aviv</region>
<code>64953</code>
<country>Israel</country>
</postal>
<email>ron.even.tlv@gmail.com</email>
</address>
</author>
<author fullname="Rachel Huang" initials="R" surname="Huang">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>Rachel@huawei.com</email>
</address>
</author>
<date year="2013" />
<area>RAI Area</area>
<workgroup>Audio/Video Transport Core Maintenance</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Audio/Video Transport</keyword>
<abstract>
<t>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”.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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”.</t>
</section>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</section>
<section title="Use of Dynamic payload type">
<t>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".</t>
<t>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.</t>
<t>[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. </t>
<t>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. <vspace
blankLines="1" />The closed IANA registry “RTP Payload types (PT) for
standard audio and video encodings” is updated as follows: <figure>
<artwork>
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]
</artwork>
</figure>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:<list style="symbols">
<t>Change 1,2, 19 64-65 from “Reserved” to “reserved may be used for
dynamic mapping” and oreference this RFC.</t>
<t>Change 66-71 to reserved for rtcp conflict avoidance.</t>
<t>Change 72-82 to reserved used by RTCP.</t>
<t>Change 83-95 to reserved for RTCP conflict avoidance.</t>
</list><list>
<t>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?</t>
</list></t>
</section>
<section title="Security Considerations">
<t>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].</t>
</section>
<section title="IANA Considerations">
<t>This section describes changes to the IANA Considerations sections
outlined in RFC 3551 regarding the allocation of payload type number by
IANA.</t>
<t>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].</t>
<t>The table in section 3 replaces the current closed table.</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal
Control</title>
<author fullname="H.Schulzrinne" initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="S.Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3551" />
</reference>
<reference anchor="RFC5761">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single
Port</title>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5761" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4566" />
</reference>
<reference anchor="H323">
<front>
<title>Packet based multimedia communication systems</title>
<author>
<organization>ITU</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="Recommendation" value="H.323" />
</reference>
<reference anchor="H246">
<front>
<title>Advanced video coding for generic audiovisual
services</title>
<author>
<organization>ITU</organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo name="Recommendation" value="H.264" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:31 |