Media Type Registration of RTP Payload Formats
obsoletes
- rfc-3555 — MIME Type Registration of RTP Payload Formats
updated by
- rfc-8851 — RTP Payload Format Restrictions
Extracted elements (23)
Media type registrations for RTP payload formats defined in RFC 3551 were removed from this document and assembled into a separate companion RFC 4856, leaving out those intended to be registered in revisions of their own payload format specification RFCs. This avoids duplication and keeps each registration close to its normative specification.
This document updates RFC 3555 to conform to revised media type registration procedures in RFC 4288. Whereas RFC 3555 required encoding considerations to specify transfer via RTP, that is now specified under 'restrictions on usage', reflecting the updated RFC 4288 template structure.
For RTP and non-RTP sharing of a subtype name, a second requirement is that the sets of required parameters must be the same for both methods; the file format MAY include a magic number or other header not present in RTP payloads.
Payload format (encoding) names defined in the RTP Profile are commonly shown in upper case while media subtype names are commonly shown in lower case, but these names are case-insensitive in both places. Similarly, parameter names are case-insensitive in media type strings and in the default mapping to the SDP a=fmtp attribute.
A statement that there are 'no security issues associated with this type' MUST NOT be confused with 'the security issues associated with this type have not been assessed'; all descriptions of security issues MUST be as accurate as possible.
All media type registrations MUST state whether or not they employ 'active content', and if they do, MUST state what steps have been taken to protect users from harm.
All media types SHOULD state whether or not they employ compression; if they do, they should discuss steps needed to avoid resource exhaustion attacks (zip-bomb style expansion).
An analysis of security issues MUST be done for all types registered in the standards tree, and all known security risks MUST be identified in the registration regardless of registration tree.
If the RTP payload format does not have a fixed RTP timestamp clock rate, a 'rate' parameter is required in the media type registration to specify the RTP timestamp clock rate.
New optional parameters MAY be added to previously defined RTP media types, but the new parameters MUST NOT change existing functionality and it MUST be possible for existing implementations to ignore the additional parameters without impairing operation.
Payload-format-specific parameters go in SDP 'a=fmtp' and MUST NOT be extended by the media type registration without a corresponding revision of the payload format specification.
The fact that the media type is defined for transfer via RTP MUST be noted under restrictions on usage, particularly if the media type is only defined for transfer via RTP.
The media type registration's encoding considerations MUST note the appropriate encoding considerations (e.g., binary or framed data as described in RFC 4288 Section 4.8).
The payload format specification MUST include the RTP timestamp clock rate (or multiple rates for audio encodings with multiple sampling rates).
The same media subtype name MUST NOT be shared for RTP and non-RTP (file-based) transfer methods unless the data format is the same for both methods.
Where the data format or required parameters cannot be the same for RTP and non-RTP transfer methods, the data formats MUST be registered as separate types. It is RECOMMENDED that subtype names be related, such as using a common root plus a suffix ('+rtp' is suggested for RTP variants).
The media type string maps to SDP as follows: media type goes in 'm='; media subtype (payload format) goes in 'a=rtpmap' as encoding name; 'rate' and 'channels' also go in 'a=rtpmap'; 'ptime' and 'maxptime' go in 'a=ptime' and 'a=maxptime'; payload-format-specific parameters go in 'a=fmtp'.
The optional 'channels' parameter specifies the number of audio channels included in the transmission; defaults to 1 if omitted. The default channel order is as specified in RFC 3551.
The optional 'ptime' parameter specifies the recommended length of time in milliseconds represented by media in a packet; 'maxptime' specifies the maximum amount of media per packet expressed as time in milliseconds. Both are defined in SDP (RFC 4566).
The 'rate' parameter specifies the RTP timestamp clock rate and is required when the payload format does not have a fixed clock rate. The typical rate for audio is 8000; other rates may be specified.
This document specifies requirements and procedures for registering RTP payload formats in the IANA media type registry. No new registrations are defined here; the document defines the process by which others are made.
A media type employing compression may allow a small payload to expand enormously upon receipt, consuming all recipient resources. Registrations must discuss steps to avoid such attacks.
Media types containing 'active content' impose risk of malicious side-effects unless execution is adequately constrained. Several audio/video encodings are suitable for steganographic data hiding. RTP itself (RFC 3550) specifies security considerations including encryption for confidentiality.