    Network Working Group                                          S. Casner
    Request for Comments: 4855                                 Packet Design
    Obsoletes: 3555                                            February 2007
    Category: Standards Track

                 Media Type Registration of RTP Payload Formats

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The IETF Trust (2007).

    Abstract

       This document specifies the procedure to register RTP payload formats
       as audio, video, or other media subtype names.  This is useful in a
       text-based format description or control protocol to identify the
       type of an RTP transmission.

    Table of Contents

       1. Introduction ....................................................2
          1.1. Terminology ................................................2
       2. Procedure For Registering Media Types for RTP Payload Types .....2
          2.1. Example Media Type Registration ............................4
          2.2. Restrictions on Sharing a Subtype Name .....................5
       3. Mapping to SDP Parameters .......................................6
       4. Changes from RFC 3555 ...........................................7
       5. Security Considerations .........................................8
       6. IANA Considerations .............................................9
       7. References .....................................................10
          7.1. Normative References ......................................10
          7.2. Informative References ....................................10

    Casner                      Standards Track                     [Page 1]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

    1.  Introduction

       RFC 4288 [1] defines media type specification and registration
       procedures that use the Internet Assigned Numbers Authority (IANA) as
       a central registry.  That document covers general requirements
       independent of particular application environments and transport
       modes.  This document defines the specific requirements for
       registration of media types for use with the Real-time Transport
       Protocol (RTP), RFC 3550 [2], to identify RTP payload formats.

    1.1.  Terminology

       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 [3] and
       indicate requirement levels for implementations compliant with this
       specification.

    2.  Procedure For Registering Media Types for RTP Payload Types

       Registering an RTP payload type as a media type follows the same
       procedures as described in RFC 4288 [1] and uses the registration
       template shown in Section 10 of that RFC.  To specify how the
       particular payload format is transported over RTP, some additional
       information is required in the following sections of that template:

         Required parameters:
              If the payload format does not have a fixed RTP timestamp
              clock rate, then a "rate" parameter is required to specify the
              RTP timestamp clock rate.  A particular payload format may
              have additional required parameters.

         Optional parameters:
              Most audio payload formats can have an optional "channels"
              parameter to specify the number of audio channels included in
              the transmission.  The default channel order is as specified
              in RFC 3551 [4].  Any payload format, but most likely audio
              formats, may also include the optional parameters "ptime" to
              specify the recommended length of time in milliseconds
              represented by the media in a packet, and/or "maxptime" to
              specify the maximum amount of media that can be encapsulated
              in each packet, expressed as time in milliseconds.  The
              "ptime" and "maxptime" parameters are defined in the Session
              Description Protocol (SDP) [5].

              A particular payload format may have additional optional
              parameters.  As allowed in Section 4.3 of [1], new parameters
              MAY be added to RTP media types that have been previously

    Casner                      Standards Track                     [Page 2]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

              defined, but the new parameters MUST NOT change existing
              functionality and it MUST be possible for existing
              implementations to ignore the additional parameters without
              impairing operation.

         Encoding considerations:
              Most RTP payload formats include binary or framed data as
              described in Section 4.8 of [1].  The appropriate encoding
              considerations MUST be noted.

         Published specification:
              A description of the media encoding and a specification of the
              payload format must be provided, usually by reference to an
              RTP payload format specification RFC.  That RFC may be
              separate, or the media type registration may be incorporated
              into the payload format specification RFC.  The payload format
              specification MUST include the RTP timestamp clock rate (or
              multiple rates for audio encodings with multiple sampling
              rates).

              A reference to a further description of the data compression
              format itself should be provided, if available.

         Restrictions on usage:
              The fact that the media type is defined for transfer via RTP
              MUST be noted, in particular, if the transfer depends on RTP
              framing and hence the media type is only defined for transfer
              via RTP.

       Depending on whether or not the type has already been registered for
       transfer with a non-RTP protocol (e.g., MIME mail or http), several
       different cases can occur:

          a) Not yet registered as a media type

             A new registration should be constructed using the media type
             registration template.  The registration may specify transfer
             via other means in addition to RTP if that is feasible and
             desired.  The appropriate encoding considerations must be
             specified, and the restrictions on usage must specify whether
             the type is only defined for transfer via RTP or via other
             modes as well.

             Optional parameters may be defined as needed, and it must be
             clearly stated to which mode(s) of transfer the parameters
             apply.

    Casner                      Standards Track                     [Page 3]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

          b) Media type exists for a non-RTP protocol

             The restrictions on usage of the existing type should be
             changed, if present, or added, if not, to indicate that the
             type can also be transferred via RTP.

             RTP-specific parameters may be added, and it must be clearly
             stated that these are only to be used when the media type is
             transmitted via RTP transport.

          c) Update an existing media type for RTP to be used for a non-RTP
             protocol

             The restrictions on usage of the existing type should be
             changed to indicate that the type can also be transferred via a
             non-RTP protocol (e.g., SMTP, HTTP).

             Non-RTP-specific parameters can be added, and it must be
             clearly stated that these are only to be used when the media
             type is transmitted via a non-RTP transport.

    2.1.  Example Media Type Registration

       The following sample registration of a fake media type audio/example
       provides examples for some of the required text.  References to RFC
       nnnn would be replaced by references to the RFC that contains the
       payload format specification and the media type registration.

         Type name: audio

         Subtype name: example

         Required parameters:
              rate: RTP timestamp clock rate, which is equal to the sampling
              rate.  The typical rate is 8000; other rates may be specified.

         Optional parameters:
              channels: number of interleaved audio streams, either 1 for
              mono or 2 for stereo, and defaults to 1 if omitted.
              Interleaving takes place between on a frame-by-frame basis,
              with the left channel followed by the right channel.

              ptime: recommended length of time in milliseconds represented
              by the media in a packet (see RFC 4566).

              maxptime: maximum amount of media that can be encapsulated in
              each packet, expressed as time in milliseconds (see RFC 4566).

    Casner                      Standards Track                     [Page 4]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

         Encoding considerations:
              This media type is framed binary data (see RFC 4288, Section
              4.8).

         Security considerations: See Section n of RFC nnnn

         Interoperability considerations:
              Some receivers may only be capable of receiving single-channel
              audio.

         Published specification: RFC nnnn

         Applications that use this media type:
              Audio and video streaming and conferencing tools.

         Additional information: none

         Person & email address to contact for further information:
              Fred Audio <fred@example.com>

         Intended usage: COMMON

         Restrictions on usage:
              This media type depends on RTP framing, and hence is only
              defined for transfer via RTP (RFC 3550).  Transfer within
              other framing protocols is not defined at this time.

         Author:
              Fred Audio

         Change controller:
              IETF Audio/Video Transport working group delegated from the
              IESG.

    2.2.  Restrictions on Sharing a Subtype Name

       The same media subtype name MUST NOT be shared for RTP and non-RTP
       (file-based) transfer methods unless the data format is the same for
       both methods.  The data format is considered to be the same if the
       file format is equivalent to a concatenated sequence of payloads from
       RTP packets not including the RTP header or any RTP payload-format
       header.

       The file format MAY include a magic number or other header at the
       start of the file that is not included when the data is transferred
       via RTP.

    Casner                      Standards Track                     [Page 5]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

       A second requirement for sharing a media subtype name is that the
       sets of required parameters must be the same for both methods.

       For cases where the data format or required parameters cannot be the
       same for RTP and non-RTP transfer methods, the data formats MUST be
       registered as separate types.  It is RECOMMENDED that the subtype
       names be related, such as by using a common root plus a suffix.  For
       those cases where a suffix is applied in the subtype name for the RTP
       transfer method, the suffix "+rtp" is suggested.

    3.  Mapping to SDP Parameters

       The representation of a media type is specified in the syntax of the
       Content-Type header field in RFC 2045 [6] as follows:

            type "/" subtype  *(";" parameter)

       Parameters may be required for a particular type or subtype or they
       may be optional.  For media types that represent RTP payload formats,
       the parameters "rate", "channels", "ptime", and "maxptime" have
       general definitions (given above) that may apply across types and
       subtypes.  The format for a parameter is specified in RFC 2045 as

            attribute "=" value

       where attribute is the parameter name and the permissible values are
       specified for each parameter.  RFC 2045 specifies that a value MUST
       be present and that the value MUST be a quoted string if it contains
       any of the special characters listed in that RFC.

       The information carried in the media type string has a specific
       mapping to fields in the Session Description Protocol (SDP) [5],
       which is commonly used to describe RTP sessions.  The mapping is as
       follows:

          o  The media type (e.g., audio) goes in SDP "m=" as the media
             name.

          o  The media subtype (payload format) goes in SDP "a=rtpmap" as
             the encoding name.

          o  The general (possibly optional) parameters "rate" and
             "channels" also go in "a=rtpmap" as clock rate and encoding
             parameters, respectively.

          o  The general (and optional) parameters "ptime" and "maxptime" go
             in the SDP "a=ptime" and "a=maxptime" attributes, respectively.

    Casner                      Standards Track                     [Page 6]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

          o  Any payload-format-specific parameters go in the SDP "a=fmtp"
             attribute.  The set of allowed parameters is defined by the RFC
             that specifies the payload format and MUST NOT be extended by
             the media type registration without a corresponding revision of
             the payload format specification.  The format and syntax of
             these parameters may also be defined by the payload format
             specification, but it is suggested that the parameters be
             copied directly from the media type string as a semicolon
             separated list of parameter=value pairs.  For payload formats
             that specify some other syntax for the fmtp parameters, the
             registration of that payload format as a media type must
             specify what the parameters are in MIME format and how to map
             them to the "a=fmtp" attribute.

       An example mapping is as follows:

             audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15

             m=audio 49170 RTP/AVP 97
             a=rtpmap:97 L16/48000/2
             a=fmtp:97 emphasis=50-15
             a=ptime:5

       Note that the payload format (encoding) names defined in the RTP
       Profile [4] are commonly shown in upper case.  Media subtype names
       are commonly shown in lower case.  These names are case-insensitive
       in both places.  Similarly, parameter names are case-insensitive both
       in media type strings and in the default mapping to the SDP a=fmtp
       attribute.

    4.  Changes from RFC 3555

       This document updates RFC 3555 to conform to the revised media type
       registration procedures in RFC 4288 [1].  Whereas RFC 3555 required
       the encoding considerations to specify transfer via RTP, that is now
       specified under restrictions on usage.  This document also specifies
       the conditions under which new optional parameters may be added to a
       previously defined RTP media type and adds a new Section 2.2 to
       clarify the requirements for sharing a media type among RTP and non-
       RTP transfer methods.

       RFC 3555 included media type registrations for the RTP payload
       formats defined in the RTP Profile for Audio and Video Conferences,
       RFC 3551 [4].  Those media type registrations have been removed from
       this document.  Some of them have been assembled into a separate
       companion RFC 4856 [8], leaving out those that have been, or are
       intended to be, registered in revisions of their own payload format
       specification RFCs.

    Casner                      Standards Track                     [Page 7]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

       Philipp Hoschka is a co-author of RFC 3555; his contributions to the
       foundation of this document are appreciated.

    5.  Security Considerations

       The media type registration procedure specified in this memo does not
       impose any security considerations on its own.  Also, registrations
       conforming to this procedure do not themselves impose security risks.
       However, use of the media type being registered could very well
       impose security risks:

          o  Any media type that contains "active content" imposes the risk
             of malicious side-effects unless execution of that content is
             adequately constrained.

          o  Several audio and video encodings are perfect for hiding data
             using steganography.

          o  The RTP specification, RFC 3550, provides security
             considerations for the transport of audio and video data over
             RTP, including the use of encryption where confidentiality is
             required.

       Therefore, each media type registration is required to state any
       security considerations that apply to the use of that type.  The
       remainder of this section is copied from RFC 4288 [1], which
       specifies media type registration procedures in general.

       An analysis of security issues MUST be done for all types registered
       in the standards tree.  A similar analysis for media types registered
       in the vendor or personal trees is encouraged but not required.
       However, regardless of what security analysis has or has not been
       done, all descriptions of security issues MUST be as accurate as
       possible regardless of registration tree.  In particular, a statement
       that there are "no security issues associated with this type" MUST
       NOT be confused with "the security issues associated with this type
       have not been assessed".

       There is absolutely no requirement that media types registered in any
       tree be secure or completely free from risks.  Nevertheless, all
       known security risks MUST be identified in the registration of a
       media type, again regardless of registration tree.

       The security considerations section of all registrations is subject
       to continuing evaluation and modification, and in particular MAY be
       extended by use of the "comments on media types" mechanism described
       in RFC 4288, Section 6.

    Casner                      Standards Track                     [Page 8]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

       Some of the issues that should be looked at in a security analysis of
       a media type are:

          o  Complex media types may include provisions for directives that
             institute actions on a recipient's files or other resources.
             In many cases, provision is made for originators to specify
             arbitrary actions in an unrestricted fashion that may then have
             devastating effects.  See the registration of the
             application/postscript media type in RFC 2046 [7] for an
             example of such directives and how they should be described in
             a media type registration.

          o  All registrations MUST state whether or not they employ such
             "active content", and if they do, they MUST state what steps
             have been taken to protect users of the media type from harm.

          o  Complex media types may include provisions for directives that
             institute actions that, while not directly harmful to the
             recipient, may result in disclosure of information that either
             facilitates a subsequent attack or else violates a recipient's
             privacy in some way.  Again, the registration of the
             application/postscript media type illustrates how such
             directives can be handled.

          o  A media type that employs compression may provide an
             opportunity for sending a small amount of data that, when
             received and evaluated, expands enormously to consume all of
             the recipient's resources.  All media types SHOULD state
             whether or not they employ compression, and if they do they
             should discuss what steps need to be taken to avoid such
             attacks.

          o  A media type might be targeted for applications that require
             some sort of security assurance but not provide the necessary
             security mechanisms themselves.  For example, a media type
             could be defined for storage of confidential medical
             information that in turn requires an external confidentiality
             service or is designed for use only within a secure
             environment.

    6.  IANA Considerations

       The purpose of this document is to specify the requirements and
       procedures for registering RTP payload formats in the IANA media type
       registry.  No registrations are defined here.

    Casner                      Standards Track                     [Page 9]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

    7.  References

    7.1.  Normative References

       [1] Freed, N. and J. Klensin, "Media Type Specifications and
           Registration Procedures", BCP 13, RFC 4288, December, 2005.

       [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
           A Transport Protocol for Real-Time Applications", RFC 3550, July
           2003.

       [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
           Levels", BCP 14, RFC 2119, March 1997.

       [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
           Conferences with Minimal Control", RFC 3551, July 2003.

       [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, July 2006.

       [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part One: Format of Internet Message Bodies",
           RFC 2045, November 1996.

       [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046, November
           1996.

    7.2.  Informative References

       [8] Casner, S., "Media Type Registration of Payload Formats in the
           RTP Profile for Audio and Video Conferences", RFC 4856, February
           2007.

    Author's Address

       Stephen L. Casner
       Packet Design
       3400 Hillview Avenue, Building 3
       Palo Alto, CA 94304
       United States

       Phone: +1 650 739-1843
       EMail: casner@acm.org

    Casner                      Standards Track                    [Page 10]

    RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

    Full Copyright Statement

       Copyright (C) The IETF Trust (2007).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

       This document and the information contained herein are provided on an
       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
       OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
       THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
       OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
       THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
       WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be claimed to
       pertain to the implementation or use of the technology described in
       this document or the extent to which any license under such rights
       might or might not be available; nor does it represent that it has
       made any independent effort to identify any such rights.  Information
       on the procedures with respect to rights in RFC documents can be
       found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the use of
       such proprietary rights by implementers or users of this
       specification can be obtained from the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that may be required to implement
       this standard.  Please address the information to the IETF at
       ietf-ipr@ietf.org.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Casner                      Standards Track                    [Page 11]