<?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-02"
     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 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. </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 [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. <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 reference this document. </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>
