From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4855.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc4855.txt (limited to 'doc/rfc/rfc4855.txt') diff --git a/doc/rfc/rfc4855.txt b/doc/rfc/rfc4855.txt new file mode 100644 index 0000000..67a3be7 --- /dev/null +++ b/doc/rfc/rfc4855.txt @@ -0,0 +1,619 @@ + + + + + + +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 + + 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] + -- cgit v1.2.3