Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
obsoletes
- rfc-3555 — MIME Type Registration of RTP Payload Formats
Extracted elements (19)
Because data compression for these media types is applied end-to-end, encryption may be performed after compression with no conflict between the two operations, enabling straightforward security layering over compressed audio/video streams.
RFC 3555 is split into two documents: RFC 4855 retains the procedures and requirements, while RFC 4856 extracts the media type registrations. Media type registrations for RTP payload formats defined in other RFCs are omitted and left to be updated by those individual RFCs.
The encoding considerations field was updated from requiring RTP transport to instead warning that types are 'framed binary data'; RTP transport dependency is now expressed under 'restrictions on usage'. This reflects the revised registration procedures in RFC 4288 and RFC 4855.
audio/L16 is compatible with the encoding used in WAV (Microsoft Windows RIFF) and Apple AIFF formats, and with the public domain 'sox' and 'rateconv' programs. Unlike other audio types in this document, audio/L16 is also defined for non-RTP file-based transfer.
All audio and video media types registered in this document depend on RTP framing and are only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined.
For audio/L16, the 'channel-order' parameter MUST be omitted when the AIFF-C channel order convention (see RFC 3551) is in use. Permissible values define specific DV channel combinations.
For audio/L16, the 'emphasis' parameter MUST be omitted if no analog preemphasis was applied to the signal before quantization. The only defined value is 'emphasis=50-15' for the 50/15 microsecond preemphasis used with Compact Discs.
RTP may be sent via IP multicast, which provides no direct means for a sender to know all receivers and no privacy. Users may be more sensitive to privacy concerns with audio/video communication; use of security mechanisms with RTP to provide confidentiality and integrity is important.
For video payload formats including video/nv, the RTP timestamp clock rate is always 90000 Hz, so the 'rate' parameter is not applicable. The 'channels' parameter is also not used with video.
The audio/DVI4 media type requires a 'rate' parameter specifying the RTP timestamp clock rate equal to the sampling rate (typical value 8000 Hz). Optional parameters are 'ptime' and 'maxptime' as defined in RFC 4566 (SDP).
The audio/G723 media type supports optional 'bitrate' parameter (5.3 or 6.3 kb/s) and 'annexa' parameter for voice activity detection (VAD); 'annexa=yes' is implied if the parameter is omitted.
The audio/G729, audio/G729D, and audio/G729E media types support an optional 'annexb' parameter for voice activity detection; 'annexb=yes' is implied if omitted.
The audio/L16 media type requires a 'rate' parameter; for non-RTP transport, permissible values are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples/second. For RTP transport, other values are permissible but the aforementioned values are RECOMMENDED.
The audio/L8 media type requires a 'rate' parameter and supports an optional 'channels' parameter (defaulting to 1) specifying the number of interleaved audio streams; interleaving occurs between individual one-byte samples, with channel order per RFC 3551.
The audio/PCMA and audio/PCMU media types require a 'rate' parameter (typical value 8000 Hz) and support an optional 'channels' parameter (defaulting to 1) for interleaved audio streams with channel order per RFC 3551.
This document updates IANA media type registrations for 19 RTP payload formats: 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, and video/nv. References for these types are changed from RFC 3555 to RFC 4856.
A denial-of-service threat exists for encodings using compression with non-uniform receiver-end computational load; an attacker can inject pathological datagrams that are complex to decode. None of the encodings registered here has an expansion factor greater than about 20.
Network-layer authentication MAY be used to discard packets from undesired sources to mitigate packet-flood denial-of-service, but the authentication processing cost itself may be too high.
None of the registered media types carry 'active content' that could impose malicious side-effects; content consists solely of compressed audio or video data. However, several audio and video encodings are suitable for hiding data using steganography.