rfc-4102

Registration of the text/red MIME Sub-Type

P. Jones
date2005-06 streamIETF arearai wgavt statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc4102 doi10.17487/RFC4102 errataview
This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]

updated by

Extracted elements (14)

design-rationale §4

The ordering of primary and redundancy encodings is fixed for each redundancy payload type. If more than one combination of primary and redundancy encoding(s) is desired, multiple redundancy payload types must be defined rather than reordering within a single type.

rtp, realtime

interoperability-note §3

Optional parameters ptime and maxptime (originally defined in RFC 2327 and RFC 3267, respectively) are supported by the text/red MIME type registration.

rtp, realtime, sip

interoperability-note §1

The text/red MIME type is based on RFC 2198 (RTP Payload for Redundant Audio Data), which is also the published specification for this MIME type. The format defined in RFC 2198 for audio redundancy is equally suitable for text redundancy.

rtp, realtime

normative-requirement §4 MUST

Any dynamic payload type in the SDP 'pt' list MUST be represented by its payload type number and not by its content-type. The mapping of payload types to content-type is done using normal SDP procedures with 'a=rtpmap'.

rtp, realtime, sip

normative-requirement §3 MUST

For dynamic payload types in the 'pt' list, if the content-type string includes a comma, then the content-type string MUST be a quoted-string. Quotation marks within the list MUST be quoted with backslash quoting as specified in RFC 2045.

rtp, realtime

normative-requirement §3 MUST

The 'pt' parameter list MUST be a quoted-string (enclosed in double quotes) because comma is a special character in MIME parameter syntax.

rtp, realtime

normative-requirement §3 MUST NOT

The text/red type is defined only for transfer via RTP and shall not be defined for a storage format.

rtp, realtime

protocol-element §3

Dynamic payload type mapping format within the 'pt' parameter: 'dynamic-payload-type "=" content-type'. This allows dynamic payload types to reference their corresponding MIME content-type specification.

rtp, realtime

protocol-element §4

SDP mapping: the MIME type 'text' goes in 'm=' as media name; 'rate' goes in 'a=rtpmap'; subtype 'RED' goes in 'a=rtpmap' as encoding name; 'ptime' and 'maxptime' map to 'a=ptime' and 'a=maxptime' attributes respectively.

rtp, realtime, sip

protocol-element §4

The 'pt' parameter maps to an 'a=fmtp' attribute by eliminating the parameter name and replacing commas with slashes. For example, 'pt="101,102"' maps to 'a=fmtp:99 101/102' where 99 is the payload type of the redundancy frames.

rtp, realtime, sip

protocol-element §3

The 'pt' required parameter is a comma-separated ordered list of RTP payload types enumerating the primary, secondary, etc., encodings in accordance with RFC 2198. Because comma is a special character, the list MUST be a quoted-string enclosed in double quotes.

rtp, realtime

protocol-element §3

The 'rate' required parameter specifies the RTP clock rate of the payload carried within the RTP packet. Typically 1000, but other rates MAY be specified; it MUST be set equal to the clock rate of the text payload format carried as the primary encoding.

rtp, realtime

registry §3

Registers the text/red MIME sub-type with IANA. The media type is 'text' and the subtype is 'RED', intended for RTP transport of redundant text data as specified in RFC 2198.

registry, rtp, realtime

security-consideration §5 RECOMMENDED

Text data is susceptible to unwanted modification that may lead to undesired results, perhaps even more so than audio data. Payload integrity protection over at least the complete RTP packet is RECOMMENDED, for example using SRTP (RFC 3711), to prevent modification of primary, secondary, or header information.

security, rtp, realtime, crypto