RTP Payload for Text Conversation
obsoletes
- rfc-2793 — RTP Payload for Text Conversation
updated by
- rfc-9071 — RTP-Mixer Formatting of Multiparty Real-Time Text
Extracted elements (29)
Although the text payload is robust against packet loss due to redundancy and has very low bit-rate, this also means it can tolerate high packet loss before needing to reduce sending rate — so the congestion response actions prioritize increasing transmission intervals and limiting character rate before dropping redundancy, preserving reliability as long as possible.
An empty T140block is transmitted at the start of an idle period (when no new text is pending after the buffering interval) so that the receiver can more rapidly detect missing text before the idle period begins. Empty T140blocks must also be carried as redundant data in subsequent packets to keep sequence number inference for redundant blocks correct.
Because text is transmitted only when available, the timestamp cannot identify lost packets (unlike constant-rate media); instead, missing RTP sequence numbers are used to detect lost text packets. This also means text/t140 should be the sole payload type in its RTP stream, since mixed streams would make sequence-number-based loss detection unreliable at payload boundaries.
Text/t140 is specified as a separate RTP session dedicated to text, not shared with other media. This enables uniform media-level functions such as routing, device selection, transcoding invocation, and QoS parameter selection that depend on each medium being explicitly identified.
The 'cps' parameter was not defined in RFC 2793; therefore implementations of text/t140 may not recognize or act upon it. Receivers MUST be designed to handle temporary reception of characters at a rate higher than the cps value to avoid malfunction due to buffer overflow.
The text/t140 payload format specified in RFC 4103 is backward-compatible with RFC 2793. RFC 4103 refines the specification to minimize interoperability problems and encourage reliability, but does not change the on-wire format.
Automated systems MUST NOT use the text/t140 format to send large amounts of text at rates significantly above those a human user could enter, in order to control network load.
Devices MUST adhere to the 'cps' parameter by transmitting characters at or below the specified rate. However, receivers of text/t140 MUST be designed to handle temporary reception of characters at a higher rate than the parameter specifies, since implementations may pre-date the parameter's definition.
For best-effort networks, an application MUST monitor the packet loss rate and take appropriate actions to reduce its sending rate if it sends at a rate higher than TCP would achieve over the same path. If rate reduction is needed, the application SHOULD NOT reduce redundancy levels below the default two generations.
For out-of-order compensation, if a gap is detected and no redundant data fills it, the received packet SHOULD be buffered; the waiting time is RECOMMENDED to be limited to 1 second. T140blocks not arriving before this limit should be treated as lost.
For synchronization of text with other media, RTP streams MUST be associated at session establishment and MUST share the same reference clock. Association can be done through the CNAME field of RTCP SDES.
Missing text SHOULD be marked by insertion of a missing text marker in the received stream for each missing T140block, as specified in ITU-T T.140 Addendum 1. Packet loss is detected by observing gaps in RTP sequence numbers.
Redundant data that would require a timestamp offset higher than 16383 (due to age at transmission) MUST NOT be included in transmitted packets.
T.140 data MAY be buffered for up to 500 ms; a buffering time of 300 ms is RECOMMENDED when application or network conditions are not known to require another value. The buffering time MUST be selected so that users perceive real-time text flow.
The default loss-protection method that MUST be used (when no other method is explicitly selected) is redundancy per RFC 2198. When used, the original text and two redundant generations SHOULD be transmitted unless application or network conditions call for other redundancy levels.
The M-bit MUST be included. The first packet in a session and the first packet after an idle period SHOULD have the marker bit set to one; all other packets MUST have the marker bit set to zero. Receipt of the M-bit MAY be used for refined loss detection methods.
The RTP timestamp for text/t140 MUST use a clock frequency of 1000 Hz. Sequential packets MUST NOT use the same timestamp. Because packets do not represent constant duration, the timestamp cannot be used to directly infer packet loss.
The text/t140 format SHOULD be the only payload type in the RTP stream, because it relies on sequence numbers for loss detection and interleaving with other payload types would make loss detection at stream boundaries unreliable.
When using redundancy: each redundant data block MUST contain the same data as a previously transmitted primary T140block; redundant data MUST be placed in age order with the most recent last; and all T140blocks from the oldest desired generation up through the generation immediately preceding the new primary MUST be included.
When valid T.140 data has been sent and no new data is available after the buffering period, an empty T140block SHOULD be transmitted to mark the beginning of an idle period, enabling more rapid detection of potentially missing text. Any empty T140block sent as primary MUST also be included as redundant in subsequent packets.
A T140block contains one or more T.140 code elements, UTF-8 encoded per T.140 and ISO 10646. Each block MUST contain an integral number of UTF-8 encoded characters, and any composite character sequence (CCS) SHOULD be placed within one block.
The 'cps' MIME/SDP parameter (in 'a=fmtp') specifies the maximum number of characters that may be received per second, as a mean value over any 10-second interval. The default value is 30. Devices receiving this parameter MUST transmit at or below the specified rate.
The text/t140 RTP payload format carries T.140 text conversation data in a dedicated RTP session. Each RTP packet contains exactly one T140block (a block of UTF-8 encoded T.140 data) with no additional framing or payload-specific headers beyond the standard RTP header.
RFC 4103 updates the MIME media type 'text/t140' in the IANA RTP and Media Type registries. Required parameter: 'rate' (must be 1000). Optional parameter: 'cps' (maximum characters per second, default 30). The SDP clock rate in 'a=rtpmap' MUST be 1000.
Confidentiality: because text conversation carries sensitive content and the data volume is low, any encryption method MAY be applied to T.140 session contents or whole RTP packets. SRTP (RFC 3711) is identified as a suitable method for ensuring confidentiality.
Integrity: SRTP provides methods for integrity protection of RTP streams that MAY be applied to prevent manipulation of text contents.
Source authentication SHOULD be applied during registration and session establishment procedures to reliably associate the sender identity with the session. Once established, SRTP mechanisms MAY be used to verify the source remains the same during the session.
A text/t140 RTP packet with redundancy (RFC 2198) uses the RED payload type. After the RTP header, one or more redundant block headers (each with F-bit, T140 PT, 14-bit timestamp offset, 10-bit block length) precede the redundant T140block data fields; the final entry has F-bit=0 and is followed by the primary T140block data.
A text/t140 RTP packet without redundancy consists of: the standard RTP fixed header (V=2, P, X, CC, M-bit, payload type, sequence number, timestamp at 1000 Hz, SSRC) followed directly by T.140 UTF-8 encoded data with no additional framing.