4856
PROPOSED STANDARD
Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
Authors: S. Casner
Date: February 2007
Area: rai
Working Group: avt
Stream: IETF
Obsoletes:
RFC 3555
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. [STANDARDS-TRACK]
RFC 4856
PROPOSED STANDARD
Errata Exist
Network Working Group S. Casner
Request for Comments: 4856 Packet Design
Obsoletes: <a href="./rfc3555">3555</a> March 2007
Category: Standards Track
<span class="h1">Media Type Registration of Payload Formats in the</span>
<span class="h1">RTP Profile for Audio and Video Conferences</span>
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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. IANA Considerations ........................................<a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Registrations for "Audio/Video Profile" .........................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Audio Type Registrations ...................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Video Type Registrations ..................................<a href="#page-24">24</a>
<a href="#section-3">3</a>. Changes from <a href="./rfc3555">RFC 3555</a> ..........................................<a href="#page-25">25</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-26">26</a>
<a href="#section-5">5</a>. References .....................................................<a href="#page-27">27</a>
<a href="#section-5.1">5.1</a>. Normative References ......................................<a href="#page-27">27</a>
<a href="#section-5.2">5.2</a>. Informative References ....................................<a href="#page-27">27</a>
<span class="grey">Casner Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document updates the media type registrations initially
specified in <a href="./rfc3555">RFC 3555</a> for the Real-time Transport Protocol (RTP)
payload formats defined in the RTP Profile for Audio and Video
Conferences, <a href="./rfc3551">RFC 3551</a> [<a href="#ref-1" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">1</a>], 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 <a href="./rfc3551">RFC 3551</a> 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 <a href="./rfc4288">RFC 4288</a> [<a href="#ref-2" title=""Media Type Specifications and Registration Procedures"">2</a>] and <a href="./rfc4855">RFC 4855</a> [<a href="#ref-3" title=""Media Type Registration of RTP Payload Types"">3</a>].
This update makes no technical changes in the registrations.
Together with <a href="./rfc4855">RFC 4855</a>, this document obsoletes <a href="./rfc3555">RFC 3555</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. IANA Considerations</span>
As a consequence of the generalized applicability of the media types
registry as specified in <a href="./rfc4288">RFC 4288</a>, 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 <a href="./rfc4288">RFC 4288</a> and
<a href="./rfc4855">RFC 4855</a>, so the reference for these media types should be changed
from <a href="./rfc3555">RFC 3555</a> to this document. Some media type registrations
contained in <a href="./rfc3555">RFC 3555</a> 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.
<span class="grey">Casner Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 <a href="./rfc2586">RFC 2586</a> for
transports other than RTP. That registration is incorporated here
and augmented with additional information for RTP transport.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-4" title=""Key words for use in RFCs to Indicate Requirement Levels"">4</a>] and
indicate requirement levels for implementations compliant with this
specification.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Registrations for "Audio/Video Profile"</span>
In the following sections, the RTP payload formats defined in the RTP
Profile for Audio and Video Conferences, <a href="./rfc3551">RFC 3551</a> [<a href="#ref-1" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">1</a>], are registered
as media types.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Audio Type Registrations</span>
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
<span class="grey">Casner Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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), <a href="./rfc4566">RFC 4566</a> [<a href="#ref-5" title=""SDP: Session Description Protocol"">5</a>].
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Registration of Media Type audio/DVI4</span>
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 <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a> [<a href="#ref-6" title=""RTP: A Transport Protocol for Real-Time Applications"">6</a>]). Transfer within
other framing protocols is not defined at this time.
Author:
Stephen Casner
<span class="grey">Casner Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Registration of Media Type audio/G722</span>
Type name: audio
Subtype name: G722
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="grey">Casner Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. Registration of Media Type audio/G723</span>
Type name: audio
Subtype name: G723
Required parameters: none
Optional parameters:
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
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 <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
<span class="grey">Casner Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Author:
Stephen Casner
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>. Registration of Media Type audio/G726-16</span>
Type name: audio
Subtype name: G726-16
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
Author:
Stephen Casner
<span class="grey">Casner Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.5" href="#section-2.1.5">2.1.5</a>. Registration of Media Type audio/G726-24</span>
Type name: audio
Subtype name: G726-24
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="grey">Casner Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h4"><a class="selflink" id="section-2.1.6" href="#section-2.1.6">2.1.6</a>. Registration of Media Type audio/G726-32</span>
Type name: audio
Subtype name: G726-32
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="grey">Casner Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h4"><a class="selflink" id="section-2.1.7" href="#section-2.1.7">2.1.7</a>. Registration of Media Type audio/G726-40</span>
Type name: audio
Subtype name: G726-40
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="grey">Casner Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h4"><a class="selflink" id="section-2.1.8" href="#section-2.1.8">2.1.8</a>. Registration of Media Type audio/G728</span>
Type name: audio
Subtype name: G728
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="grey">Casner Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h4"><a class="selflink" id="section-2.1.9" href="#section-2.1.9">2.1.9</a>. Registration of Media Type audio/G729</span>
Type name: audio
Subtype name: G729
Required parameters: none
Optional parameters:
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
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 <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
Author:
Stephen Casner
<span class="grey">Casner Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.10" href="#section-2.1.10">2.1.10</a>. Registration of Media Type audio/G729D</span>
Type name: audio
Subtype name: G729D
Required parameters: none
Optional parameters:
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
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 <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
<span class="grey">Casner Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Author:
Stephen Casner
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.11" href="#section-2.1.11">2.1.11</a>. Registration of Media Type audio/G729E</span>
Type name: audio
Subtype name: G729E
Required parameters: none
Optional parameters:
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
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 <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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
<span class="grey">Casner Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h4"><a class="selflink" id="section-2.1.12" href="#section-2.1.12">2.1.12</a>. Registration of Media Type audio/GSM</span>
Type name: audio
Subtype name: GSM
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
<span class="grey">Casner Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Author:
Stephen Casner
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.13" href="#section-2.1.13">2.1.13</a>. Registration of Media Type audio/GSM-EFR</span>
Type name: audio
Subtype name: GSM-EFR
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
Author:
Stephen Casner
<span class="grey">Casner Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.14" href="#section-2.1.14">2.1.14</a>. Registration of Media Type audio/L8</span>
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 <a href="./rfc3551">RFC 3551</a>.
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). Transfer within
other framing protocols is not defined at this time.
<span class="grey">Casner Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Author:
Stephen Casner
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
<span class="h4"><a class="selflink" id="section-2.1.15" href="#section-2.1.15">2.1.15</a>. Registration of Media Type audio/L16</span>
Media type audio/L16 was initially registered via <a href="./rfc2586">RFC 2586</a> [<a href="#ref-10" title=""The Audio/L16 MIME content type"">10</a>] 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 <a href="./rfc3551">RFC 3551</a> 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 <a href="./rfc3190">RFC 3190</a> [<a href="#ref-7" title=""RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio"">7</a>], Section 7).
Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo,
DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2,
DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
<span class="grey">Casner Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 [<a href="#ref-9" title="and 1250-50 systems)">9</a>]; those are
DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. This parameter MUST
be omitted when the AIFF-C channel order convention (see <a href="./rfc3551">RFC</a>
<a href="./rfc3551">3551</a>) 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 <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
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:
<a href="./rfc2586">RFC 2586</a> for non-RTP transports, <a href="./rfc3551">RFC 3551</a> 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>
<span class="grey">Casner Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 (<a href="./rfc3550">RFC 3550</a>).
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.
<span class="h4"><a class="selflink" id="section-2.1.16" href="#section-2.1.16">2.1.16</a>. Registration of Media Type audio/LPC</span>
Type name: audio
Subtype name: LPC
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
<span class="grey">Casner Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h4"><a class="selflink" id="section-2.1.17" href="#section-2.1.17">2.1.17</a>. Registration of Media Type audio/PCMA</span>
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 <a href="./rfc3551">RFC 3551</a>.
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
<span class="grey">Casner Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h4"><a class="selflink" id="section-2.1.18" href="#section-2.1.18">2.1.18</a>. Registration of Media Type audio/PCMU</span>
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 <a href="./rfc3551">RFC 3551</a>.
ptime, maxptime: see <a href="./rfc4566">RFC 4566</a>
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
<span class="grey">Casner Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h4"><a class="selflink" id="section-2.1.19" href="#section-2.1.19">2.1.19</a>. Registration of Media Type audio/VDVI</span>
Type name: audio
Subtype name: VDVI
Required parameters: none
Optional parameters: ptime, maxptime (see <a href="./rfc4566">RFC 4566</a>)
Encoding considerations:
This media type is framed binary data (see Section 4.8 in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
<span class="grey">Casner Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Video Type Registrations</span>
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.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Registration of Media Type video/nv</span>
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 <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a>).
Security considerations:
This media type does not carry active content. It does
transfer compressed data. See <a href="./rfc4856#section-4">Section 4 of RFC 4856</a>.
<span class="grey">Casner Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Interoperability considerations: none
Published specification: <a href="./rfc3551">RFC 3551</a>
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 (<a href="./rfc3550">RFC 3550</a>). 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Changes from <a href="./rfc3555">RFC 3555</a></span>
<a href="./rfc3555">RFC 3555</a> is obsoleted by the combination of <a href="./rfc4855">RFC 4855</a> [<a href="#ref-3" title=""Media Type Registration of RTP Payload Types"">3</a>] and this
document. <a href="./rfc4855">RFC 4855</a> retains the specification of procedures and
requirements from <a href="./rfc3555">RFC 3555</a>, while the media type registrations from
<a href="./rfc3555">RFC 3555</a> were extracted into this document. The media type
registrations for the RTP payload formats that are referenced in <a href="./rfc3551">RFC</a>
<a href="./rfc3551">3551</a> [<a href="#ref-1" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">1</a>], 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 <a href="./rfc4288">RFC 4288</a>
[<a href="#ref-2" title=""Media Type Specifications and Registration Procedures"">2</a>] and <a href="./rfc4855">RFC 4855</a>. Whereas <a href="./rfc3555">RFC 3555</a> 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 [<a href="#ref-9" title="and 1250-50 systems)">9</a>], which was missing from <a href="./rfc3555">RFC 3555</a>, has
been corrected.
<span class="grey">Casner Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
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 [<a href="#ref-8" title=""RTP: A Transport Protocol for Real-Time Applications"">8</a>].
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.
<span class="grey">Casner Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", <a href="./rfc3551">RFC 3551</a>, July 2003.
[<a id="ref-2">2</a>] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>, December 2005.
[<a id="ref-3">3</a>] Casner, S., "Media Type Registration of RTP Payload Types", <a href="./rfc4855">RFC</a>
<a href="./rfc4855">4855</a>, January 2007.
[<a id="ref-4">4</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-5">5</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-6">6</a>] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", <a href="./rfc3550">RFC</a>
<a href="./rfc3550">3550</a>, July 2003.
[<a id="ref-7">7</a>] 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", <a href="./rfc3190">RFC 3190</a>, January 2002.
[<a id="ref-8">8</a>] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", <a href="./rfc3550">RFC</a>
<a href="./rfc3550">3550</a>, July 2003.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-9">9</a>] 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.
[<a id="ref-10">10</a>] Salsman, J. and H. Alvestrand, "The Audio/L16 MIME content
type", <a href="./rfc2586">RFC 2586</a>, May 1999.
<span class="grey">Casner Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
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: [email protected]
<span class="grey">Casner Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc4856">RFC 4856</a> RTP Payload Formats for Audio/Video Profile March 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Casner Standards Track [Page 29]
Annotations
Select text to annotate