Network Working Group S. CasnerRequest for Comments: 4856 Packet DesignObsoletes:3555 March 2007Category: Standards TrackMedia Type Registration of Payload Formats in theRTP Profile for Audio and Video ConferencesStatus 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 Contents1. Introduction ....................................................21.1. IANA Considerations ........................................21.2. Terminology ................................................32. Registrations for "Audio/Video Profile" .........................32.1. Audio Type Registrations ...................................32.2. Video Type Registrations ..................................243. Changes fromRFC 3555 ..........................................254. Security Considerations ........................................265. References .....................................................275.1. Normative References ......................................275.2. Informative References ....................................27Casner Standards Track [Page 1]
RFC 4856 RTP Payload Formats for Audio/Video Profile March 20071. Introduction This document updates the media type registrations initially specified inRFC 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 inRFC 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 inRFC 4288 [2] andRFC 4855 [3]. This update makes no technical changes in the registrations. Together withRFC 4855, this document obsoletesRFC 3555.1.1. IANA Considerations As a consequence of the generalized applicability of the media types registry as specified inRFC 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 inRFC 4288 andRFC 4855, so the reference for these media types should be changed fromRFC 3555 to this document. Some media type registrations contained inRFC 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 viaRFC 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 inRFC 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 byCasner 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 CasnerCasner 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 20072.1.3. Registration of Media Type audio/G723 Type name: audio Subtype name: G723 Required parameters: none Optional parameters: ptime, maxptime: seeRFC 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 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 CasnerCasner 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 20072.1.6. Registration of Media Type audio/G726-32 Type name: audio Subtype name: G726-32 Required parameters: none Optional parameters: ptime, maxptime (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 20072.1.7. Registration of Media Type audio/G726-40 Type name: audio Subtype name: G726-40 Required parameters: none Optional parameters: ptime, maxptime (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 20072.1.8. Registration of Media Type audio/G728 Type name: audio Subtype name: G728 Required parameters: none Optional parameters: ptime, maxptime (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 20072.1.9. Registration of Media Type audio/G729 Type name: audio Subtype name: G729 Required parameters: none Optional parameters: ptime, maxptime: seeRFC 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 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 CasnerCasner 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: seeRFC 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 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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: seeRFC 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 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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: COMMONCasner 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 CasnerCasner 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 inRFC 3551. ptime, maxptime: seeRFC 4566 Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 viaRFC 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 inRFC 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 (seeRFC 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 (seeRFC3551) 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. SeeSection 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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: noneCasner 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 inRFC 3551. ptime, maxptime: seeRFC 4566 Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 4 of RFC 4856. Interoperability considerations: none Published specification:RFC 3551Casner 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 inRFC 3551. ptime, maxptime: seeRFC 4566 Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 (seeRFC 4566) Encoding considerations: This media type is framed binary data (see Section 4.8 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 4 of RFC 4856. Interoperability considerations: none Published specification:RFC 3551Casner 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 inRFC4288). Security considerations: This media type does not carry active content. It does transfer compressed data. SeeSection 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 fromRFC 3555RFC 3555 is obsoleted by the combination ofRFC 4855 [3] and this document.RFC 4855 retains the specification of procedures and requirements fromRFC 3555, while the media type registrations fromRFC 3555 were extracted into this document. The media type registrations for the RTP payload formats that are referenced inRFC3551 [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 inRFC 4288 [2] andRFC 4855. WhereasRFC 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 fromRFC 3555, has been corrected.Casner Standards Track [Page 25]
RFC 4856 RTP Payload Formats for Audio/Video Profile March 20074. 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 20075. References5.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",RFC4855, 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",RFC3550, 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",RFC3550, 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 2007Author'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 28]
RFC 4856 RTP Payload Formats for Audio/Video Profile March 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 29]
Datatracker
RFC 4856
RFC - Proposed Standard
| Document | Document type | RFC - Proposed Standard February 2007 View errata Report errata ObsoletesRFC 3555 | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | Stephen L. Casner Email authors | ||
| RFC stream |   | ||
| Other formats | |||
| Additional resources | Mailing list discussion |