rfc-2793

RTP Payload for Text Conversation

G. Hellstrom
date2000-05 streamIETF arearai wgavt statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc2793 doi10.17487/RFC2793
This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]

obsoleted by

Extracted elements (23)

design-rationale §2.1

A 1000 Hz RTP clock was chosen because text is entered at low rates (a few characters per second) and the timestamp only needs to encode approximate entry time rather than sample-accurate durations; redundancy increases channel load minimally since packet overhead dominates payload size.

rtp, realtime

design-rationale §3.4

A zero-length primary T140block MAY be transmitted with redundant data during 'silent periods' to ensure the latest T140block is protected against packet loss at the end of a text input sequence, avoiding the problem of it growing stale before being retransmitted as redundancy.

rtp, realtime

design-rationale §1

UTF-8 encoding of ISO 10646 was chosen because it makes it easy to implement internationally useful applications and to handle text in modern information technology environments, as mandated by T.140.

rtp, realtime

interoperability-note §2.3

Since sequence numbers are not provided in the redundant header per RFC 2198, additional ordering rules must be followed to allow redundant data to be merged properly: redundant blocks must be in age order and sequence numbers are inferred by counting backwards from the RTP header sequence number.

rtp, realtime

interoperability-note §2.2

The redundancy coding for T140 follows RFC 2198; when redundancy is desired, each redundant data block header provides the timestamp offset and length of the corresponding data block plus a payload type number indicating the T140 payload format.

rtp, realtime

normative-requirement §2.1 MUST

A clock frequency of 1000 Hz MUST be used for the RTP timestamp, and sequential packets MUST NOT use the same timestamp.

rtp, realtime

normative-requirement §2 SHOULD

Any composite character sequence (CCS) SHOULD be placed within one T140block.

rtp, realtime

normative-requirement §3.4 MUST

Any zero-length T140blocks sent as primary data MUST be included as redundant T140blocks on subsequent packets just as normal text T140blocks, so that sequence number inference for redundant T140blocks will be correct.

rtp, realtime

normative-requirement §2.3 MUST

Each redundant data block MUST contain the same data as a T140block previously transmitted as primary data, identified with a timestamp offset equating to the original timestamp for that T140block.

rtp, realtime

normative-requirement §2 MUST

Each T140block MUST contain an integral number of UTF-8 encoded characters regardless of the number of octets per character.

rtp, realtime

normative-requirement §3.2 SHOULD

Missing data 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.

rtp, realtime

normative-requirement §3.4 SHOULD NOT

Redundancy for the last T140block SHOULD NOT be implemented by repeatedly transmitting the same packet (with the same sequence number) because this will cause the packet loss count as reported in RTCP to decrement.

rtp, realtime

normative-requirement §2.3 MUST

Redundant data MUST be placed in age order with the most recent redundant T140block last in the redundancy area, and all T140blocks from the oldest desired generation up through the generation immediately preceding the new primary T140block MUST be included.

rtp, realtime

normative-requirement §1 MUST

T.140 text and other T.140 elements MUST be transmitted in ISO 10646-1 code with UTF-8 transformation, making it easy to implement internationally useful applications.

rtp, realtime

normative-requirement §2.1 MUST

The RTP Sequence Number MUST be increased by one for each new transmitted packet, used for detection of packet loss and out-of-order packets.

rtp, realtime

normative-requirement §2.1 MUST

When redundancy is used per RFC 2198, the Payload Type MUST indicate the RED payload format rather than T140.

rtp, realtime

protocol-element §2

A T140block is a block of T.140 data carried in an RTP packet, consisting of one or more T.140 code elements encoded as UTF-8, with no additional framing beyond the standard RTP header.

rtp, realtime

protocol-element §2.1

The RTP payload type is identified by the name 'T140' for profiles using dynamic payload type assignment; when redundancy (RFC 2198) is used, the PT indicates 'RED' instead.

rtp, realtime, registry

protocol-element §2.1

The RTP timestamp encodes the approximate instance of entry of the primary text in the packet, using a 1000 Hz clock frequency. Since packets do not represent any constant duration, the timestamp cannot be used to directly infer packet losses.

rtp, realtime

registry §6.1

This document registers the MIME media type text/t140 for T.140 text conversation content carried in RTP as specified in RFC 2793, with no required or optional parameters.

registry, rtp, realtime

security-consideration §5

Since the payload carries text conversation content, encryption is important for security. Any encryption method MAY be applied to T.140 session contents or to the whole RTP packets; when redundant data is included, the same security considerations as RFC 2198 apply.

security, rtp, realtime

wire-format §4

A T140 RTP packet with one redundant T140block uses PT='RED', followed by a redundant data block header (1-bit marker=1, T140 PT, 14-bit timestamp offset, block length), then a primary data block header (1-bit marker=0, T140 PT), redundant T.140 data, and primary T.140 data.

rtp, realtime

wire-format §4

A T140 RTP packet without redundancy consists of a standard RTP fixed header (V=2, PT=T140 PT, sequence number, timestamp at 1000 Hz, SSRC) followed immediately by T.140 UTF-8 encoded data with no additional payload header.

rtp, realtime