RFC 4856

Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences

📅 published February 2007, from ietf

RFC 4856: Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences 🎀

Okay bestie, so this is RFC 4856 and it's giving registration paperwork, but make it iconic 💅. S. Casner from Packet Design wrote it, it's dated March 2007, and it's a Standards Track document in the Network Working Group 🌸. It obsoletes RFC 3555, and it also updates the media type registrations that RFC 3555 started, which you'll see in Section 1 ✨.

Status of This Memo 🦋

This doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. To check the standardization state and status of this protocol, go look at the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜.

Copyright Notice 💖

Copyright (C) The IETF Trust (2007).

Abstract ✨

This doc gives media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these can also be used for transfer modes that aren't 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

1. Introduction ✨

Okay so this doc updates the media type registrations first specified in RFC 3555 💅. Those registrations cover the Real-time Transport Protocol (RTP) payload formats from the RTP Profile for Audio and Video Conferences, which is RFC 3551 [1]. They're filed as subtypes under the "audio" and "video" media types. This doc does NOT cover payload formats that RFC 3551 mentions but that are defined in other RFCs. Registrations for those are supposed to get updated when the individual RFCs that define them get revised 🫶.

The registrations here follow the updated template format and procedures in RFC 4288 [2] and RFC 4855 [3]. No technical changes were made to the registrations. Together with RFC 4855, this doc obsoletes RFC 3555 🦋.

1.1. IANA Considerations 🌈

Because the media types registry is generalized as specified in RFC 4288, the RTP Payload Format section of the registry needs some nomenclature changes. The registry title "RTP Payload Format MIME types" and its intro text should swap "MIME" for "media". "MIME" also gets deleted from the table headings, so you're left with just "media type" and "subtype" 💀.

These media type registrations are updated to match the revised format from RFC 4288 and RFC 4855, so their reference should change from RFC 3555 to this doc. A few registrations from RFC 3555 aren't in this doc. Those existing registrations stay valid until other RFCs update them. Nothing new is registered here 🧚.

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

The media type audio/L16 was first registered through RFC 2586 for transports other than RTP. That registration is folded into this doc and gets extra info 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 doc are interpreted as described in RFC 2119 [4]. They show the requirement levels for implementations that comply with this spec 🔥.

2. Registrations for "Audio/Video Profile" 🦋

In the next sections, the RTP payload formats from the RTP Profile for Audio and Video Conferences (RFC 3551 [1]) get registered as media types 💖.

2.1. Audio Type Registrations 🎀

For most audio payload formats, the RTP timestamp clock rate equals the sampling rate. Some formats only run at one fixed sampling rate, and others can be adjusted 🌸.

These audio formats also take the optional parameters "ptime" and "maxptime". "ptime" says the recommended amount of media, in milliseconds, that goes in one packet. "maxptime" says the maximum amount of media that can be packed into each packet, also as a time in milliseconds. Both 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

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.

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.

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

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.

2.1.6. Registration of Media Type audio/G726-32 🎀

Okay bestie, next up is G726-32 🦋 Same registration drill as always: the fields are below, copied exactly as written so nothing gets lost ✨

   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.

2.1.7. Registration of Media Type audio/G726-40 🌸

Next is G726-40, and honestly the template is giving déjà vu 🙈 Same fields, same vibes, same citations. Here it is, verbatim 💅

   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.

2.1.8. Registration of Media Type audio/G728 🧚

G728 next ✨ Same deal: required parameters are none, optional ones are ptime and maxptime, and it's framed binary data that doesn't carry active content (just compressed data, periodt) 🫶

   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.

2.1.9. Registration of Media Type audio/G729 🦋

Now G729, and this one is a little different because it has an extra optional parameter called annexb 👀 It says whether Annex B (voice activity detection) is used or preferred, the allowed values are "yes" and "no" (no quotes in the real thing), and "yes" is implied if you leave it out. Main character energy 👑

   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

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.10. Registration of Media Type audio/G729D 💜

G729D is basically G729's twin, same annexb parameter and same "yes" default. Lowkey iconic 🥹

   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.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.11. Registration of Media Type audio/G729E 🔥

G729E keeps the same optional parameters as the G729 family (ptime, maxptime, and annexb). Everything else is the same, so here's the full template as-is 💖

   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
   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 🍓

GSM is up next 📞 Required parameters: none. Optional parameters: ptime and maxptime. Still framed binary data, still no active content, still compressed data only 🫶

   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.

   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 🌈

GSM-EFR is the GSM sibling, and the template matches plain GSM exactly: same optional parameters, same security note, same restrictions 🎀

   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

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.14. Registration of Media Type audio/L8 🦋

Last one in this batch is L8, and it's a bit of a glow-up because it has a required parameter: rate, which is the RTP timestamp clock rate 🕰️ There's also an optional channels parameter (defaults to 1, stereo would be 2, and so on). Interleaving happens between individual one-byte samples, and the channel order follows RFC 3551 ✨ Here's the full template, verbatim 💅

   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.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.15. Registration of Media Type audio/L16 ✨

Okay so audio/L16 was first registered in RFC 2586 [10] for transports other than RTP 🎀. That registration gets folded in here and glowed up with extra info for RTP transport 💖.

The rate parameter is required 🔥. For non-RTP transport, the allowed values are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. For RTP, other values are allowed too, but the list above is RECOMMENDED. Over RTP, rate is the RTP timestamp clock rate, and it's equal to the sample rate 🦋.

Now the optional parameters:

channels: how many audio streams are interleaved. It defaults to 1, so stereo would be 2, and so on. Interleaving happens between individual two-byte samples. The channel order follows 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, which means the 50/15 microsecond preemphasis used with Compact Discs 💿. This parameter MUST be omitted if no analog preemphasis was applied. It's a stream property parameter, not a receiver configuration parameter, so if parameters get negotiated, the sender may not be able to honor a receiver's request for a particular setting 🙈.
channel-order: the sample interleaving order for multiple-channel audio streams (see RFC 3190 [7], Section 7) 🧚. The permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, and DV.LRCWoLsRsLcRc. For DV video interop, only a subset is specified for 20-bit linear encoding in the DV video specification [9]: DV.LRLsRs, DV.LRCS, and DV.LmixRmixTWoQ1Q2. This parameter MUST be omitted when the AIFF-C channel order convention (see RFC 3551) is in use 👑.
For RTP, ptime: a RECOMMENDED duration of each packet in milliseconds ⏱️.
For RTP, maxptime: the maximum duration of each packet in milliseconds 🌈.

The rest of the template:

   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>

   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 🎶

Here's the LPC registration, all laid out for you 💅.

   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
   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 🌷

PCMA next, and it's giving very similar vibes to the last one 🫶.

   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
   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 🍓

PCMU is basically PCMA's twin, same rate story, same vibes 👯‍♀️.

   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.

   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 🦢

And last up in the audio crew, 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
   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 🎬

Okay, video time! For most video payload formats, including the one registered here, the RTP timestamp clock rate is always 90000 Hz 🕘. That means the rate parameter doesn't apply. The channel parameter isn't used with video either, and ptime and maxptime could be used but typically aren't 💜.

2.2.1. Registration of Media Type video/nv 📹

Here's the nv registration, lovely and verbatim 🌸.

   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.

   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 🔄

okay so, RFC 3555 got obsoleted by the combo of RFC 4855 [3] and this document 💅 RFC 4855 keeps the procedures and requirements from RFC 3555, and the media type registrations from RFC 3555 got moved over into this doc 🎀 The media type registrations for the RTP payload formats that are referenced in RFC 3551 [1] but defined in other RFCs got left out of this document 🧚 That's because those registrations are meant to get updated by including them in revisions of the individual RFCs that define the payload formats 💜

The media type registrations in this document got glow-ups to match the revised media type registration procedures in RFC 4288 [2] and RFC 4855 ✨ Back in RFC 3555, the encoding considerations had to say transfer happens via RTP. Now that's handled under restrictions on usage instead 🦋 The encoding considerations also warn that these types are framed binary data 🍓 The change controller is identified using current conventions too 👑 The optional parameter "channels" got clarified for the audio subtypes L8, PCMA, and PCMU 🔥 And finally, reference [9], which was missing from RFC 3555, has been fixed 🫶

4. Security Considerations 🔐

okay bestie, this part is serious, so let's go 🙈 This memo specifies media type registrations for transferring 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 on the receiver 🫶 The content is just 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 👀

There's a potential denial-of-service threat for data encodings that use compression techniques with non-uniform receiver-end computational load 😭 An attacker can inject pathological datagrams into the stream. These are complex to decode and can overload the receiver 💀 Still, none of the encodings registered here has an expansion factor greater than about 20, and all of them 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 receiving too many packets, whether 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 gives a sender no direct means of knowing all the receivers of the data it sends, 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 🥹 So using 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's no conflict between the two operations 💖

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.

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

Full Copyright Statement ⚖️

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. It also doesn't 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. 🌸

📦 where this page comes from

ietf: rfc4856 2007-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms