Guideline for dynamic payload type number usage policy
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]