RTP Payload Format for a 64 kbit/s Transparent Call
Extracted elements (17)
Clearmode is introduced as a pseudo-codec for transparent relay of 64 kbit/s data streams (e.g., ISDN data, ISDN 7 kHz voice) that cannot tolerate non-linear encoding. No encoder/decoder is used; only packetization and depacketization occur.
The 'audio' top-level MIME type was chosen for clearmode—despite it not being audio per se—because dominant uses are telephony-related and because 'audio' allows port sharing in the SDP 'm=' line with codecs such as audio/g711, which is an important application scenario.
The payload format encoding name in RTP profiles is commonly shown in upper case (CLEARMODE) while the MIME subtype is in lower case (clearmode); both names are case-insensitive.
A sample rate of 8000 Hz MUST be used, yielding a 64 kbit/s transmission rate per channel.
Each Clearmode octet SHALL be octet-aligned in an RTP packet, and the sign bit of each octet SHALL correspond to the most significant bit of the octet in the RTP packet.
If tunnels or security encapsulation are expected, the number of samples per packet SHOULD be reduced to allow for extra header space.
The number of samples per packet SHOULD be less than the path MTU minus combined packet header length to avoid fragmentation.
The RTP Timestamp SHALL be set as described in RFC 3550.
Clearmode supports RTP over unicast UDP, multicast UDP, and TCP, without precluding use over other lower-layer protocols.
SDP mapping: MIME type 'audio' goes in 'm=', subtype 'clearmode' goes in 'a=rtpmap' as encoding name at 8000 Hz, and optional parameters 'ptime'/'maxptime' map to 'a=ptime'/'a=maxptime' attributes.
The RTP marker bit is always zero for Clearmode; silence suppression is not applicable to Clearmode data streams.
The RTP payload type for Clearmode is dynamically assigned and is not statically defined in this document.
This document registers the MIME subtype audio/clearmode with IANA. Required parameters: none. Optional parameters: ptime, maxptime. Encoding: transfer via RTP only.
A receiver may be overloaded by receipt of too many packets from undesired sources. Network-layer authentication MAY be used to discard such packets, though the processing cost of authentication itself may be prohibitive. The ptime parameter can be used to negotiate an appropriate packetization period during session setup to avoid sender-induced overload.
Confidentiality of Clearmode media streams must be achieved by encryption, for example by applying the Secure RTP (SRTP) profile (RFC 3711). The payload format itself defines no additional security services beyond those in RFC 3550.
RTP is not an appropriate transfer protocol for reliable octet streams; TCP is preferred for reliable transfer. Packet loss due to congestion affects Clearmode as much as other RTP payload formats.
Each Clearmode sample is exactly one octet (8 bits), octet-aligned in the RTP payload with the most significant bit corresponding to the sign bit. No additional framing or header fields are defined within the payload.