Movatterモバイル変換

Network Working Group                                          S. CasnerRequest for Comments: 4855                                 Packet DesignObsoletes:3555                                            February 2007Category: Standards TrackMedia Type Registration of RTP Payload FormatsStatus 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 Contents1. Introduction ....................................................21.1. Terminology ................................................22. Procedure For Registering Media Types for RTP Payload Types .....22.1. Example Media Type Registration ............................42.2. Restrictions on Sharing a Subtype Name .....................53. Mapping to SDP Parameters .......................................64. Changes fromRFC 3555 ...........................................75. Security Considerations .........................................86. IANA Considerations .............................................97. References .....................................................107.1. Normative References ......................................107.2. Informative References ....................................10Casner                      Standards Track                     [Page 1]

RFC 4855         Media Type Reg. of RTP Payload Formats    February 20071.  IntroductionRFC 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 inRFC 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 inRFC 4288 [1] and uses the registration   template shown inSection 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          inRFC 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 previouslyCasner                      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 (seeRFC 4566).          maxptime: maximum amount of media that can be encapsulated in          each packet, expressed as time in milliseconds (seeRFC 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 (seeRFC 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 inRFC 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 inRFC 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 fromRFC 3555   This document updatesRFC 3555 to conform to the revised media type   registration procedures inRFC 4288 [1].  WhereasRFC 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 newSection 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   companionRFC 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 ofRFC 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 fromRFC 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   inRFC 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 inRFC 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 20077.  References7.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.orgCasner                      Standards Track                    [Page 10]

RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]