RFC 3555

MIME Type Registration of RTP Payload Formats

📅 published July 2003, from ietf

RFC 3555 ✨ Part 1 of 5 🎀

Title Block 💖

Okay bestie, this is RFC 3555, and it's called "MIME Type Registration of RTP Payload Formats" 🦋 It came from the Network Working Group in July 2003. The authors are S. Casner from Packet Design and P. Hoschka from W3C/INRIA/MIT. It's a Standards Track document, which means it's an official protocol spec, not just a casual memo 💅 It doesn't list anything it obsoletes or updates, so it's standing on its own, iconic 👑

Status of This Memo 🌸

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 If you want to know where this protocol is in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 And yes, distribution of this memo is unlimited, so share the wisdom 🌈

Copyright Notice 🧚

Abstract ✨

Okay so the big idea is that this doc defines how to register RTP Payload Formats as audio, video, or other MIME subtype names 🎧 That's super useful in a text-based format or control protocol, because it lets you identify what kind of RTP transmission you're dealing with 🔥 It also registers every RTP payload format from the RTP Profile for Audio and Video Conferences as a MIME subtype, which is so thorough it's giving 😭 And some of these might work for transfer modes other than RTP too 🦋

Table of Contents 🎀

   1. Introduction ..................................................  2
      1.1. IANA Considerations ......................................  2
      1.2. Terminology ..............................................  3
   2. Procedure For Registering MIME Types for RTP Payload Types ....  3
   3. Mapping to SDP Parameters .....................................  5
   4. Registrations for "Audio/Video Profile" .......................  6
      4.1. Audio Type Registrations .................................  6
      4.2. Video Type Registrations ................................. 30
   5. Security Considerations ....................................... 42
   6. Normative References .......................................... 43
   7. Authors' Addresses ............................................ 44
   8. Full Copyright Statement ...................................... 45

1. Introduction 🌷

So the MIME registration procedure from RFC 2048 [1] was originally built for sending multimedia through asynchronous Internet mail 📬 But the MIME namespace has grown up and now identifies other transport modes too, which is such a glow-up 💜 This doc sets out how to register MIME subtype names for the Real-time Transport Protocol (RTP), described in RFC 3550 [2], so RTP payload formats can be identified 🎶

It also registers all the RTP payload formats from the RTP Profile for Audio and Video Conferences, RFC 3551 [3], as MIME subtypes under the "audio" and "video" MIME types 🍓

1.1. IANA Considerations 🧁

This document registers the following MIME subtypes:

   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/MPA
   audio/PCMA
   audio/PCMU
   audio/QCELP
   audio/RED
   audio/VDVI
   video/BT656
   video/CelB
   video/JPEG
   video/H261
   video/H263
   video/H263-1998
   video/H263-2000
   video/MPV
   video/MP2T
   video/MP1S
   video/MP2P
   video/BMPEG
   video/nv

MIME subtype audio/L16 was already registered through RFC 2586 for transports other than RTP 🌈 This document takes that registration, keeps it, and adds more 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 document are to be interpreted as described in RFC 2119 [4] 🫶 They're the requirement levels for implementations that comply with this spec, so they really matter 💅

2. Procedure For Registering MIME Types for RTP Payload Types 🦋

Registering an RTP payload type as a MIME type follows the same steps as RFC 2048, and it uses the registration template shown in Section 2.8 of RFC 2048 ✨ Some extra parameters are needed to say how a payload format gets carried over RTP 🎀

Published specification 📜 A description of the encoding and a specification of the payload format must be provided, usually by reference to an RTP payload format specification RFC. That RFC can be separate, or the MIME subtype registration can be built into the payload format specification RFC. The payload format specification MUST include the RTP timestamp clock rate (or multiple rates for audio encodings with multiple sampling rates) 🔥

A reference to a further description of the data compression format itself should be provided, if available 🧚

Required parameters 🌸 If the payload format doesn't have a fixed RTP timestamp clock rate, then a "rate" parameter is required to specify the RTP timestamp clock rate 💜 A particular payload format may have additional required parameters too 🍓

Optional parameters 🌈 Most audio payload formats can have an optional "channels" parameter to specify the number of audio channels in the transmission 🎶 Any payload format, but most likely audio formats, may also include the optional parameters "ptime", which gives the recommended length of time in milliseconds represented by the media in a packet, and/or "maxptime", which gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds 💖 The "ptime" and "maxptime" parameters are defined in the Session Description Protocol (SDP) [5] 🦋

A particular payload format may have additional optional parameters 💅

Encoding considerations ✨ The fact that the type can be transferred via RTP MUST be noted 🙈

Depending on whether the type has already been registered for transfer with a non-RTP protocol (e.g. MIME mail or http) or not, a few different cases can come up 👑

a) Not yet registered as a MIME type 🌷 A new registration should be constructed using the MIME registration template. The registration may specify transfer via other means in addition to RTP if that's feasible and desired. The encoding considerations must specify how the type is transferred via RTP.

Optional parameters may be defined as needed, and it must be clearly stated whether to which mode(s) of transfer the parameters apply. 🧁

b) MIME type exists for a non-RTP protocol 🫶 The encoding considerations of the existing type should be changed to indicate that the type can also be transferred via RTP.

RTP-specific parameters may be added, and it must be clearly stated that these are only to be used when the media type is transmitted via RTP transport. 🎀

c) Update an existing MIME type for RTP to be used for a non-RTP protocol 🌈 The encoding considerations of the existing type should be changed to indicate that the type can also be transferred via a non-RTP protocol (e.g. SMTP, HTTP).

Non-RTP-specific parameters can be added, and it must be clearly stated that these are only to be used when the media type is transmitted via a non-RTP transport. 🍓

3. Mapping to SDP Parameters 🧚

A MIME media type is written according to the Content-Type header field syntax in RFC 2045 [6], like this:

   type "/" subtype  *(";" parameter)

Parameters may be required for a particular type or subtype, or they may be optional 💜 For media types that represent RTP payload formats, the parameters "rate", "channels", "ptime", and "maxptime" have general definitions (given above) that can apply across types and subtypes 🌸 A parameter is written according to RFC 2045 like this:

   attribute "=" value

Here the attribute is the parameter name, and the allowed values are specified for each parameter 🎶 The value might need to be a quoted string if it contains any of the special characters listed in RFC 2045 🔥

The info in the media type string maps to specific fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions 🦋 The mapping goes like this:

The MIME type (e.g., audio) goes in SDP "m=" as the media name.
The MIME subtype (payload format) goes in SDP "a=rtpmap" as the encoding name.
The general (possibly optional) parameters "rate" and "channels" also go in "a=rtpmap" as clock rate and encoding parameters, respectively.
The general (and optional) parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Any payload-format-specific parameters go in the SDP "a=fmtp" attribute. The set of allowed parameters is defined by the RFC that specifies the payload format and MUST NOT be extended by the MIME subtype registration without a corresponding revision of the payload format specification. The format and syntax of these parameters may also be defined by the payload format specification, but it's suggested that the parameters be copied directly from the MIME media type string as a semicolon separated list of parameter=value pairs. For payload formats that specify some other syntax for the fmtp parameters, the registration of that payload format as a MIME subtype must specify what the parameters are in MIME format and how to map them to the SDP "a=fmtp" attribute. See Section 4.1.21 for an example. 💖

Here's an example mapping 🧁

   audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15

   m=audio 49170 RTP/AVP 97
   a=rtpmap:97 L16/48000/2
   a=fmtp:97 emphasis=50-15
   a=ptime:5

Quick note: the payload format (encoding) names defined in the RTP Profile are usually shown in upper case, and MIME subtypes are usually shown in lower case 🌈 Both are case-insensitive, and parameter names are case-insensitive too, both in MIME types and in the default mapping to the SDP a=fmtp attribute 🙈

4. Registrations for "Audio/Video Profile" 💅

In the sections that follow, every RTP payload format described in the RTP Profile for Audio and Video Conferences, RFC 3551 [3], gets registered as a MIME subtype 🎀

4.1. Audio Type Registrations 🎧

These sections register all of the RTP audio payload types defined in RFC 3551 as MIME types 🦋

For most audio payload formats, the RTP timestamp clock rate is equal to the sampling rate ✨ Some payload formats only run at one fixed sampling rate, while others can be adjusted 🌷

More to come in the next part, bestie! 🫶

4.1.1. Registration of MIME media type audio/DVI4 💖

okay bestie, DVI4 is the first audio type on the list and it's giving classic 🎀. Here's the registration exactly as written:

   MIME media type name: audio

   MIME 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

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.2. Registration of MIME media type audio/G722 🦋

G722 keeps it simple, no required parameters, just the usual ptime and maxptime extras. ✨

   MIME media type name: audio

   MIME subtype name: G722

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.3. Registration of MIME media type audio/G723 🌸

G723 is the one with extra parameters, so pay attention here 👀. There's bitrate and annexa, and each has its own little rules.

   MIME media type name: audio

   MIME subtype name: G723

   Required parameters: None

   Optional parameters:
        ptime, maxptime

        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 type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.4. Registration of MIME media type audio/G726-16 🍓

Same vibe as G722: no required parameters, just ptime and maxptime. 🫶

   MIME media type name: audio

   MIME subtype name: G726-16

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.5. Registration of MIME media type audio/G726-24 🧚

   MIME media type name: audio

   MIME subtype name: G726-24

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:

        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.6. Registration of MIME media type audio/G726-32 💜

   MIME media type name: audio

   MIME subtype name: G726-32

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.7. Registration of MIME media type audio/G726-40 ⭐

   MIME media type name: audio

   MIME subtype name: G726-40

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.8. Registration of MIME media type audio/G728 🌈

   MIME media type name: audio

   MIME subtype name: G728

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.9. Registration of MIME media type audio/G729 🎀

G729 brings annexb, which is the voice activity detection one. The default is "yes" if you leave it out, so keep that in mind 💅.

   MIME media type name: audio

   MIME subtype name: G729

   Required parameters: None

   Optional parameters:
        ptime, maxptime

        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 type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.10. Registration of MIME media type audio/G729D 🦋

G729D has the same annexb parameter as G729, so it's basically the same story. 🙈

   MIME media type name: audio

   MIME subtype name: G729D

   Required parameters: None

   Optional parameters:
        ptime, maxptime

        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 type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.11. Registration of MIME media type audio/G729E 🔥

   MIME media type name: audio

   MIME subtype name: G729E

   Required parameters: None

   Optional parameters:
        ptime, maxptime

        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 type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.12. Registration of MIME media type audio/GSM 👑

   MIME media type name: audio

   MIME subtype name: GSM

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.13. Registration of MIME media type audio/GSM-EFR 🌸

   MIME media type name: audio

   MIME subtype name: GSM-EFR

   Required parameters: None

   Optional parameters: ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.14. Registration of MIME media type audio/L8 🍒

L8 is the one that wants a rate up front, and it also takes channels. Bring your clock rate, babe ⏰✨.

   MIME media type name: audio

   MIME subtype name: L8

   Required parameters: rate, the RTP timestamp clock rate

   Optional parameters: channels, ptime, maxptime

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC 3550].

   Security considerations: See Section 5 of RFC 3555

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications which 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

   Author/Change controller:
        Stephen Casner

4.1.15. Registration of MIME media type audio/L16 🎧

okay so audio/L16 already got registered back in RFC 2586 for non-RTP transports 💅 and this section basically takes that registration and glows it up with extra info for RTP. same type, just with more main character energy for RTP ✨

MIME media type name: audio
MIME subtype name: L16

Required parameters

rate: number of samples per second. For non-RTP transport, the allowed values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. For RTP transport, other values are allowed too, but the values I just listed are RECOMMENDED 🫶. For RTP, rate is the RTP timestamp clock rate, which is the same as the sample rate.

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 🎀.
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 Disks 💿. This parameter MUST be omitted if no analog preemphasis was applied.
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see [7] Section 7) 🌈. Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, and DV.LRCWoLsRsLcRc. 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 [4]. Those are 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: RECOMMENDED duration of each packet in milliseconds ⏱️.
For RTP, maxptime: maximum duration of each packet in milliseconds.

Encoding considerations

Audio data is binary data, so it has to be encoded for non-binary transport. Base64 works well for Email 📧. Heads up, though: audio data does not compress easily with lossless compression 🙈.

This type is also defined for transfer via RTP [RFC 3550].

Security considerations

Audio data is believed to offer no security risks. See Section 5 of RFC 3555 🔐.

Interoperability considerations

This type is compatible with the encoding used in the WAV (Microsoft Windows RIFF) and Apple AIFF union types. It also plays nicely with the public domain "sox" and "rateconv" programs 🤝.

Published specification

RFC 2586 for non-RTP transports, RFC 3551 for RTP.

Applications which use this media

The public domain "sox" and "rateconv" programs accept this type.

Magic number(s) : None
File extension(s) : WAV L16
Macintosh file type code : AIFF

Person to contact for further information

Name : James Salsman
E-mail : jps-L16@bovik.org

Intended usage

Common. It's expected that lots of audio and speech apps will use this type 🎙️. The most popular platforms already offer it with the rate=11025 parameter, which they call "radio quality speech" 📻.

Author/Change controller

James Salsman for non-RTP transports. Stephen Casner for RTP transport.

4.1.16. Registration of MIME media type audio/LPC 🌸

this one is a quick and cute registration for LPC, and it's only for RTP 🦋

MIME media type name: audio
MIME subtype name: LPC
Required parameters: None
Optional parameters: ptime, maxptime
Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].
Security considerations: See Section 5 of RFC 3555
Interoperability considerations: none
Published specification: RFC 3551
Applications which 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
Author/Change controller: Stephen Casner

4.1.17. Registration of MIME media type audio/MPA 🎶

this is the registration for MPEG audio, so it's giving full multimedia era 🎬

MIME media type name: audio
MIME subtype name: MPA (MPEG audio)
Required parameters: None

Optional parameters

layer: which layer of MPEG audio encoding. Permissible values are 1, 2, and 3 🔢.
samplerate: the rate at which audio is sampled. MPEG-1 audio supports sampling rates of 32, 44.1, and 48 kHz. MPEG-2 supports sampling rates of 16, 22.05, and 24 kHz. This parameter is separate from the RTP timestamp clock rate, which is always 90000 Hz for MPA 🕰️.
mode: permissible values are "stereo", "joint_stereo", "single_channel", and "dual_channel". The channels parameter does not apply to MPA. It is undefined to put a number of channels in the SDP rtpmap attribute for MPA 🙅.
bitrate: the data rate for the audio bit stream.
ptime: RECOMMENDED duration of each packet in milliseconds ⏱️.
maxptime: maximum duration of each packet in milliseconds.

Parameters that get left out are up to the encoder to pick, based on the session bandwidth, configuration information, or other constraints 🤷‍♀️. The chosen layer, plus the sampling rate and mode, are shown in the payload. That way receivers can process the data without those parameters being set from outside 💜.

Encoding considerations

This type is only defined for transfer via RTP [RFC 3550].

Security considerations

See Section 5 of RFC 3555

Interoperability considerations

none

Published specification

RFC 3551

Applications which 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

Author/Change controller

Stephen Casner

4.1.18. Registration of MIME media type audio/PCMA 🍓

PCMA is another RTP-only registration, and it's basically the same vibe as PCMU, so let's get into it 💅

MIME media type name: audio
MIME 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 can be specified too ⏰.

Optional parameters: channels, ptime, maxptime
Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].
Security considerations: See Section 5 of RFC 3555
Interoperability considerations: none
Published specification: RFC 3551
Applications which 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
Author/Change controller: Stephen Casner

4.1.19. Registration of MIME media type audio/PCMU 🌈

PCMU is PCMA's twin 👯‍♀️. It's registered the same way, so everything you just read applies here too ✨

MIME media type name: audio
MIME 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 can be specified too ⏰.

Optional parameters: channels, ptime, maxptime
Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].
Security considerations: See Section 5 of RFC 3555
Interoperability considerations: none
Published specification: RFC 3551
Applications which 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
Author/Change controller: Stephen Casner

4.1.20. Registration of MIME media type audio/QCELP 🎤

QCELP is a speech codec with its own spec, and it's RTP-only 📞.

MIME media type name: audio
MIME subtype name: QCELP
Required parameters: None
Optional parameters: ptime, maxptime
Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].
Security considerations: See Section 5 of RFC 3555
Interoperability considerations: none
Published specification: RFC 2658
Applications which 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
Author/Change controller: Stephen Casner

4.1.21. Registration of MIME media type audio/RED 🧩

RED is where things get a little wild 🫠. It's a redundancy format that carries other payload types inside it, so the pt parameter has to list them, and the quoting rules are a bit of a maze. Read this part slowly bestie, it's worth it 💖.

MIME media type name: audio
MIME subtype name: RED

Required parameters

pt: a comma-separated list of RTP payload types. Because comma is a special character, the list must be a quoted-string (enclosed in double quotes). For static payload types, each list element is simply the type number. For dynamic payload types, each list element is a mapping of the dynamic payload type number to an embedded MIME content-type specification for the payload format corresponding to that dynamic payload type. The format of the mapping is:

dynamic-payload-type "=" content-type

If the content-type string includes a comma, then the content-type string MUST be a quoted-string. If the content-type string does not include a comma, it MAY still be quoted. Since it is part of the list, which must itself be a quoted-string, the quotation marks MUST be quoted with backslash quoting as specified in RFC 2045. If the content-type string itself contains a quoted-string, then the backslash quoting requirement applies recursively 🔁.

To specify the audio/RED payload format in SDP, the pt parameter is mapped to an a=fmtp attribute by dropping the parameter name (pt) and changing the commas to slashes. For example, 'pt="0,5"' maps to 'a=fmtp:99 0/5' ✨.

A more complicated example, with a dynamic payload type, looks like this:

pt = "0, 103 = \"audio/G729D;annexb=yes\" "

m=audio 49170 RTP/AVP 99 0 103
a=rtpmap:99 RED/8000
a=fmtp:99 0/103
a=rtpmap:103 G729D/8000
a=fmtp:103 annexb=yes

Optional parameters: ptime, maxptime

Encoding considerations

This type is only defined for transfer via RTP [RFC 3550].

Security considerations

See Section 5 of RFC 3555

Interoperability considerations

none

Published specification

RFC 2198

Applications which 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

Author/Change controller

Stephen Casner

4.1.22. Registration of MIME media type audio/VDVI 🎵

last one in this batch! VDVI is another RTP-only registration, and it's pretty straightforward, which is a nice break after RED 😌🦋.

MIME media type name: audio
MIME subtype name: VDVI
Required parameters: None
Optional parameters: ptime, maxptime
Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].
Security considerations: See Section 5 of RFC 3555
Interoperability considerations: none
Published specification: RFC 3551
Applications which 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
Author/Change controller: Stephen Casner

Intended usage: COMMON

Author/Change controller: Stephen Casner

4.2.7. Registration of MIME media type video/H263-2000 👑

MIME media type name: video

MIME subtype name: H263-2000

Required parameters: None

Optional parameters:

profile: H.263 profile number, in the range 0 through 10, specifying the supported H.263 annexes/subparts.
level: Level of bitstream operation, in the range 0 through 100, specifying the level of computational complexity of the decoding process.

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2429 The specific values for the profile and level parameters and their meaning are defined in Annex X of ITU-T Recommendation H.263, "Video coding for low bit rate communication". Note that the RTP payload format for H263-2000 is the same as for H263-1998, but additional annexes/subparts are specified along with the profiles and levels.

Applications which 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

Author/Change controller: Stephen Casner

4.2.8. Registration of MIME media type video/MPV 🎞️

MIME media type name: video

MIME subtype name: MPV MPEG-1 or -2 Elementary Streams

Required parameters: None

Optional parameters:

type: the type of MPEG video, from the set "mpeg1", "mpeg2-halfd1", or "mpeg2-fulld1". The default is "mpeg1". The mapping to a=fmtp is identity.

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2250

Applications which 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

Author/Change controller: Stephen Casner

4.2.9. Registration of MIME media type video/MP2T 📼

MIME media type name: video

MIME subtype name: MP2T MPEG-2 Transport Streams

Required parameters: None

Optional parameters: None

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2250

Applications which 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

Author/Change controller: Stephen Casner

4.2.10. Registration of MIME media type video/MP1S 🌟

MIME media type name: video

MIME subtype name: MP1S MPEG-1 Systems Streams

Required parameters: None

Optional parameters: None

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2250

Applications which 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

Author/Change controller: Stephen Casner

4.2.11. Registration of MIME media type video/MP2P 🫶

MIME media type name: video

MIME subtype name: MP2P MPEG-2 Program Streams

Required parameters: None

Optional parameters: None

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2250

Applications which 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

Author/Change controller: Stephen Casner

4.2.12. Registration of MIME media type video/BMPEG 🎀

MIME media type name: video

MIME subtype name: BMPEG

Required parameters: None

Optional parameters: None

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 2343

Applications which 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

Author/Change controller: Stephen Casner

4.2.13. Registration of MIME media type video/nv 💜

MIME media type name: video

MIME subtype name: nv

Required parameters: None

Optional parameters: None

Encoding considerations: This type is only defined for transfer via RTP [RFC 3550].

Security considerations: See Section 5 of RFC 3555

Interoperability considerations: none

Published specification: RFC 3551

Applications which 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

Author/Change controller: Stephen Casner

5. Security Considerations 🔒

The MIME subtype registration procedure specified in this memo does not impose any security considerations on its own. This memo also contains several MIME type registrations. The registrations themselves do not impose security risks, but some may state security considerations specific to the particular registration.

Okay bestie, this part is SERIOUS 😭 Several audio and video encodings are perfect for hiding data using steganography. Like, someone could hide a secret message inside a song or a video and nobody would know 🕵️‍♀️ Be careful out there!

The RTP specification, RFC 3550, provides security considerations for the transport of audio and video data over RTP, including the use of encryption where confidentiality is required. Encrypt your media when it needs to stay private! 🔐✨

6. Normative References 📚✨

okay so the references are the docs this spec leans on, and they're kinda essential 🤓

[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. 📝
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. 🎀
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. 🎬
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🌸
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 💜
[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. 🦋

7. Authors' Addresses 🌷

these are the people who wrote the thing, so here are their deets, bestie 🫶

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

Philipp Hoschka INRIA Route des Lucioles 2004 06904, Sophia-Antipolis Cedex BP 93, France

Phone: (+33) 4 92 38 79 84 Fax: (+33) 4 92 38 77 65 EMail: ph@w3.org

W3C http://www.w3.org/people/hoschka

8. Full Copyright Statement ⚖️

okay so the legal bit, and yes it's a lot, but it's giving very important energy 💅

This document and translations of it can be copied and handed out to others. You can also make derivative works that comment on or explain it, or help people implement it, and you can prepare, copy, publish and distribute those in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph stay on all of those copies and derivative works ✨. Still, this document itself can't be changed in any way, so you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed, or when it's translated into languages other than English 🌍.

The permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them. 💖

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🙈

Acknowledgement 🫧

the RFC Editor function is currently funded by the Internet Society, so a big thank you to them 🧚💜

📦 where this page comes from

ietf: rfc3555 2003-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms