diff options
Diffstat (limited to 'doc/rfc/rfc4856.txt')
| -rw-r--r-- | doc/rfc/rfc4856.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc4856.txt b/doc/rfc/rfc4856.txt new file mode 100644 index 0000000..5d6229c --- /dev/null +++ b/doc/rfc/rfc4856.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group S. Casner +Request for Comments: 4856 Packet Design +Obsoletes: 3555 March 2007 +Category: Standards Track + + + Media Type Registration of Payload Formats in the + RTP Profile for Audio and Video Conferences + +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 media type registrations for the RTP payload + formats defined in the RTP Profile for Audio and Video Conferences. + Some of these may also be used for transfer modes other than RTP. + +Table of Contents + 1. Introduction ....................................................2 + 1.1. IANA Considerations ........................................2 + 1.2. Terminology ................................................3 + 2. Registrations for "Audio/Video Profile" .........................3 + 2.1. Audio Type Registrations ...................................3 + 2.2. Video Type Registrations ..................................24 + 3. Changes from RFC 3555 ..........................................25 + 4. Security Considerations ........................................26 + 5. References .....................................................27 + 5.1. Normative References ......................................27 + 5.2. Informative References ....................................27 + + + + + + + + + + + + +Casner Standards Track [Page 1] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +1. Introduction + + This document updates the media type registrations initially + specified in RFC 3555 for the Real-time Transport Protocol (RTP) + payload formats defined in the RTP Profile for Audio and Video + Conferences, RFC 3551 [1], as subtypes under the "audio" and "video" + media types. This document does not include media type registrations + for the RTP payload formats that are referenced in RFC 3551 but + defined in other RFCs. The media type registrations for those + payload formats are intended to be updated by including them in + revisions of the individual RFCs defining the payload formats. + + The media type registrations specified here conform to the updated + template format and procedures in RFC 4288 [2] and RFC 4855 [3]. + This update makes no technical changes in the registrations. + Together with RFC 4855, this document obsoletes RFC 3555. + +1.1. IANA Considerations + + As a consequence of the generalized applicability of the media types + registry as specified in RFC 4288, some changes in nomenclature are + needed in the RTP Payload Format section of the registry. In the + registry title "RTP Payload Format MIME types" and the introductory + text, "MIME" should be changed to "media". "MIME" should be deleted + from the table headings, leaving just "media type" and "subtype". + + This document updates the media type registrations listed below to + conform to the revised registration format specified in RFC 4288 and + RFC 4855, so the reference for these media types should be changed + from RFC 3555 to this document. Some media type registrations + contained in RFC 3555 are omitted from this document; the existing + registrations for those types continue to be valid until updated by + other RFCs. There are no new registrations contained here. + + + + + + + + + + + + + + + + + + +Casner Standards Track [Page 2] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + audio/DVI4 + audio/G722 + audio/G723 + audio/G726-16 + audio/G726-24 + audio/G726-32 + audio/G726-40 + audio/G728 + audio/G729 + audio/G729D + audio/G729E + audio/GSM + audio/GSM-EFR + audio/L8 + audio/L16 + audio/LPC + audio/PCMA + audio/PCMU + audio/VDVI + video/nv + + Media type audio/L16 was initially registered via RFC 2586 for + transports other than RTP. That registration is incorporated here + and augmented with additional information for RTP transport. + +1.2. 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 [4] and + indicate requirement levels for implementations compliant with this + specification. + +2. Registrations for "Audio/Video Profile" + + In the following sections, the RTP payload formats defined in the RTP + Profile for Audio and Video Conferences, RFC 3551 [1], are registered + as media types. + +2.1. Audio Type Registrations + + For most audio payload formats, the RTP timestamp clock rate is equal + to the sampling rate. Some payload formats operate only at one fixed + sampling rate, while others are adjustable. + + These audio formats also include the optional parameters "ptime" to + specify the recommended length of time in milliseconds represented by + + + + +Casner Standards Track [Page 3] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + the media in a packet, and "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), RFC 4566 [5]. + +2.1.1. Registration of Media Type audio/DVI4 + + Type name: audio + + Subtype name: DVI4 + + Required parameters: + rate: The RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000, but other rates may + be specified. + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + Intended usage: COMMON + + Restrictions on usage: + This media type depends on RTP framing, and hence is only + defined for transfer via RTP (RFC 3550 [6]). Transfer within + other framing protocols is not defined at this time. + + Author: + Stephen Casner + + + + +Casner Standards Track [Page 4] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.2. Registration of Media Type audio/G722 + + Type name: audio + + Subtype name: G722 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + + + + +Casner Standards Track [Page 5] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +2.1.3. Registration of Media Type audio/G723 + + Type name: audio + + Subtype name: G723 + + Required parameters: none + + Optional parameters: + ptime, maxptime: see RFC 4566 + + bitrate: the data rate in kb/s used or preferred for the audio + bit stream, with permissible values 5.3 or 6.3. If + unspecified, the bitrate may change from frame to frame as + indicated inband. + + annexa: indicates that Annex A, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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. + + + + +Casner Standards Track [Page 6] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Author: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.4. Registration of Media Type audio/G726-16 + + Type name: audio + + Subtype name: G726-16 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + + + + +Casner Standards Track [Page 7] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.5. Registration of Media Type audio/G726-24 + + Type name: audio + + Subtype name: G726-24 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + + + + +Casner Standards Track [Page 8] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +2.1.6. Registration of Media Type audio/G726-32 + + Type name: audio + + Subtype name: G726-32 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + + + + + + + + +Casner Standards Track [Page 9] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +2.1.7. Registration of Media Type audio/G726-40 + + Type name: audio + + Subtype name: G726-40 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + + + + + + + + +Casner Standards Track [Page 10] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +2.1.8. Registration of Media Type audio/G728 + + Type name: audio + + Subtype name: G728 + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + + + + + + + + +Casner Standards Track [Page 11] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +2.1.9. Registration of Media Type audio/G729 + + Type name: audio + + Subtype name: G729 + + Required parameters: none + + Optional parameters: + ptime, maxptime: see RFC 4566 + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + + + + + +Casner Standards Track [Page 12] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.10. Registration of Media Type audio/G729D + + Type name: audio + + Subtype name: G729D + + Required parameters: none + + Optional parameters: + ptime, maxptime: see RFC 4566 + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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. + + + + + +Casner Standards Track [Page 13] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Author: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.11. Registration of Media Type audio/G729E + + Type name: audio + + Subtype name: G729E + + Required parameters: none + + Optional parameters: + ptime, maxptime: see RFC 4566 + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + Intended usage: COMMON + + + + + + + +Casner Standards Track [Page 14] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.12. Registration of Media Type audio/GSM + + Type name: audio + + Subtype name: GSM + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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. + + + +Casner Standards Track [Page 15] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Author: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.13. Registration of Media Type audio/GSM-EFR + + Type name: audio + + Subtype name: GSM-EFR + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + + + + +Casner Standards Track [Page 16] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.14. Registration of Media Type audio/L8 + + Type name: audio + + Subtype name: L8 + + Required parameters: + rate: the RTP timestamp clock rate + + Optional parameters: + channels: how many audio streams are interleaved -- defaults + to 1; stereo would be 2, etc. Interleaving takes place + between individual one-byte samples. The channel order is as + specified in RFC 3551. + + ptime, maxptime: see RFC 4566 + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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. + + + + +Casner Standards Track [Page 17] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Author: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.15. Registration of Media Type audio/L16 + + Media type audio/L16 was initially registered via RFC 2586 [10] for + transports other than RTP. That registration is incorporated here + and augmented with additional information for RTP transport. + + Type name: audio + + Subtype name: L16 + + Required parameters: + rate: number of samples per second -- For non-RTP transport, + the permissible values for rate are 8000, 11025, 16000, 22050, + 24000, 32000, 44100, and 48000 samples per second. For RTP + transport, other values are permissible but the aforementioned + values are RECOMMENDED. For RTP, the rate parameter indicates + the RTP timestamp clock rate, which is equal to the sample + rate. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults + to 1; stereo would be 2, etc. Interleaving takes place + between individual two-byte samples. The channel order is as + specified in RFC 3551 unless a channel-order parameter is also + present. + + emphasis: analog preemphasis applied to the signal before + quantization. The only emphasis value defined here is + emphasis=50-15 to indicate the 50/15 microsecond preemphasis + used with Compact Discs. This parameter MUST be omitted if no + analog preemphasis was applied. Note that this is a stream + property parameter, not a receiver configuration parameter. + Thus, if parameters are negotiated, it may not be possible for + the sender to comply with a receiver request for a particular + setting. + + channel-order: specifies the sample interleaving order for + multiple-channel audio streams (see RFC 3190 [7], Section 7). + Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, + DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, + DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. + + + +Casner Standards Track [Page 18] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + For interoperation with DV video systems, only a subset of + these channel combinations is specified for use with 20-bit + linear encoding in the DV video specification [9]; those are + DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. This parameter MUST + be omitted when the AIFF-C channel order convention (see RFC + 3551) is in use. + + For RTP, ptime: RECOMMENDED duration of each packet in + milliseconds. + + For RTP, maxptime: maximum duration of each packet in + milliseconds. + + Encoding considerations: + Audio data is binary data, and must be encoded for non-binary + transport; the Base64 encoding is suitable for Email. Note + that audio data does not compress easily using lossless + compression. + + Security considerations: + Audio/L16 data is believed to offer no security risks. This + media type does not carry active content. The encoding is not + compressed. See Section 4 of RFC 4856. + + Interoperability considerations: + This type is compatible with the encoding used in the WAV + (Microsoft Windows RIFF) and Apple AIFF union types, and with + the public domain "sox" and "rateconv" programs. + + Published specification: + RFC 2586 for non-RTP transports, RFC 3551 for RTP + + Applications that use this media type: + The public domain "sox" and "rateconv" programs accept this + type. + + Additional information: + Magic number(s): none + File extension(s): WAV L16 + Macintosh file type code: AIFF + + Person to contact for further information: + James Salsman <jps-L16@bovik.org> + + + + + + + + +Casner Standards Track [Page 19] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Intended usage: + Common + + It is expected that many audio and speech applications will + use this type. Already the most popular platforms provide + this type with the rate=11025 parameter, referred to as "radio + quality speech". + + Restrictions on usage: + In addition to file-based transfer methods, this type is also + defined for transfer via RTP (RFC 3550). + + Author: + James Salsman for non-RTP transports. + Stephen Casner for RTP transport. + + Change controller: + James Salsman for non-RTP transports. + For RTP transport, IETF Audio/Video Transport working group + delegated from the IESG. + +2.1.16. Registration of Media Type audio/LPC + + Type name: audio + + Subtype name: LPC + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + + + +Casner Standards Track [Page 20] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.17. Registration of Media Type audio/PCMA + + Type name: audio + + Subtype name: PCMA + + Required parameters: + rate: The RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000, but other rates may + be specified. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults + to 1; stereo would be 2, etc. Interleaving takes place + between individual one-byte samples. The channel order is as + specified in RFC 3551. + + ptime, maxptime: see RFC 4566 + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + + + +Casner Standards Track [Page 21] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.18. Registration of Media Type audio/PCMU + + Type name: audio + + Subtype name: PCMU + + Required parameters: + rate: The RTP timestamp clock rate, which is equal to the + sampling rate. The typical rate is 8000, but other rates may + be specified. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults + to 1; stereo would be 2, etc. Interleaving takes place + between individual one-byte samples. The channel order is as + specified in RFC 3551. + + ptime, maxptime: see RFC 4566 + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + + +Casner Standards Track [Page 22] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.1.19. Registration of Media Type audio/VDVI + + Type name: audio + + Subtype name: VDVI + + Required parameters: none + + Optional parameters: ptime, maxptime (see RFC 4566) + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + Interoperability considerations: none + + Published specification: RFC 3551 + + + + +Casner Standards Track [Page 23] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +2.2. Video Type Registrations + + For most video payload formats, including the one registered here, + the RTP timestamp clock rate is always 90000 Hz, so the "rate" + parameter is not applicable. Likewise, the "channel" parameter is + not used with video, while "ptime" and "maxptime" could be but + typically are not. + +2.2.1. Registration of Media Type video/nv + + Type name: video + + Subtype name: nv + + Required parameters: none + + Optional parameters: none + + Encoding considerations: + This media type is framed binary data (see Section 4.8 in RFC + 4288). + + Security considerations: + This media type does not carry active content. It does + transfer compressed data. See Section 4 of RFC 4856. + + + + +Casner Standards Track [Page 24] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications that use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner <casner@acm.org> + + 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: + Stephen Casner + + Change controller: + IETF Audio/Video Transport working group delegated from the + IESG. + +3. Changes from RFC 3555 + + RFC 3555 is obsoleted by the combination of RFC 4855 [3] and this + document. RFC 4855 retains the specification of procedures and + requirements from RFC 3555, while the media type registrations from + RFC 3555 were extracted into this document. The media type + registrations for the RTP payload formats that are referenced in RFC + 3551 [1], but defined in other RFCs, have been elided from this + document because those registrations are intended to be updated by + including them in revisions of the individual RFCs defining the + payload formats. + + The media type registrations in this document have been updated to + conform to the revised media type registration procedures in RFC 4288 + [2] and RFC 4855. Whereas RFC 3555 required the encoding + considerations to specify transfer via RTP, that is now specified + under restrictions on usage. The encoding considerations now warn + that these types are framed binary data. The change controller is + also now identified according to current conventions. The optional + parameter "channels" was clarified for audio subtypes L8, PCMA, and + PCMU. Finally, reference [9], which was missing from RFC 3555, has + been corrected. + + + +Casner Standards Track [Page 25] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +4. Security Considerations + + This memo specifies media type registrations for the transfer of + several compressed audio and video data encodings via RTP, so + implementations using these media types are subject to the security + considerations discussed in the RTP specification [8]. + + None of these media types carry "active content" that could impose + malicious side-effects upon the receiver. The content consists + solely of compressed audio or video data to be decoded and presented + as sound or images. However, several audio and video encodings are + perfect for hiding data using steganography. + + A potential denial-of-service threat exists for data encodings using + compression techniques that have non-uniform receiver-end + computational load. The attacker can inject pathological datagrams + into the stream, which are complex to decode and cause the receiver + to be overloaded. However, none of the encodings registered here has + an expansion factor greater than about 20, and all are considered + relatively simple by modern standards (some are implemented on + handheld devices and most were implemented on general-purpose + computers ten years ago). + + As with any IP-based protocol, in some circumstances a receiver may + be overloaded simply by the receipt of too many packets, either + desired or undesired. Network-layer authentication MAY be used to + discard packets from undesired sources, but the processing cost of + the authentication itself may be too high. + + RTP may be sent via IP multicast, which provides no direct means for + a sender to know all the receivers of the data sent and therefore no + measure of privacy. Rightly or not, users may be more sensitive to + privacy concerns with audio and video communication than they have + been with more traditional forms of network communication. + Therefore, the use of security mechanisms with RTP to provide + confidentiality and integrity of the data is important. Because the + data compression used with these media types is applied end-to-end, + encryption may be performed after compression so there is no conflict + between the two operations. + + + + + + + + + + + + +Casner Standards Track [Page 26] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 2007 + + +5. References + +5.1. Normative References + + [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + Conferences with Minimal Control", RFC 3551, July 2003. + + [2] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + + [3] Casner, S., "Media Type Registration of RTP Payload Types", RFC + 4855, January 2007. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 3550, July 2003. + + [7] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP + Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear + Sampled Audio", RFC 3190, January 2002. + + [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 3550, July 2003. + +5.2. Informative References + + [9] IEC 61834, Helical-scan digital video cassette recording system + using 6,35 mm magnetic tape for consumer use (525-60, 625-50, + 1125-60, and 1250-50 systems), August 1998. + + [10] Salsman, J. and H. Alvestrand, "The Audio/L16 MIME content + type", RFC 2586, May 1999. + + + + + + + + + + + + +Casner Standards Track [Page 27] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 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 28] + +RFC 4856 RTP Payload Formats for Audio/Video Profile March 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 29] + |