RTP Payload for Timed Text Markup Language (TTML)
Extracted elements (26)
Existing RTP text payload types (RFC 4103 for text conversation, RFC 4396 for 3GPP timed text) lack the formatting capabilities required for television closed-caption workflows. The absence of a suitable format for TTML or generic XML necessitated this new payload format.
The RTP Timestamp does not encode constant-duration media; it encodes the document epoch. Combined with possible fragmentation across packets, the RTCP jitter calculation is rendered unusable for this payload format.
This payload format uses the existing 'application/ttml+xml' media type rather than defining a new one; the clock rate parameter is specific to RTP usage and has not been added to the media type definition because it is inapplicable outside RTP contexts.
Applications implementing this standard MUST comply with RFC 8083 (RTP Circuit Breakers), with particular attention to Section 4.4 on Media Usability. Congestion control SHALL follow RFC 3550 and any applicable RTP profile.
Documents spread across multiple RTP packets MUST use the same timestamp but different consecutive Sequence Numbers. Sequential documents MUST NOT use the same timestamp.
Documents using character encodings where characters are not represented by a single byte MUST be serialised in big-endian (network byte) order.
If a TTML document is assessed to be invalid (including zero-length/empty documents), it MUST be discarded.
Multiple TTML subtitle streams MUST NOT be interleaved in a single RTP stream.
The document epoch E MUST be set equal to the RTP Timestamp in the header of the packet carrying the TTML document; computed TTML media times are offset relative to E.
The length of User Data Words MUST match the value specified in the Length field.
The minimal TTML2 processor profile (designator 'urn:ietf:rfc:8759#processor') MUST be supported by receivers; it requires #timeBase-media and the #rtp-relative-media-time extension.
The Reserved 16-bit field in the payload header MUST be set to 0x0 by senders and ignored upon reception.
The SDP 'codecs' media type parameter MUST specify at least one processor profile, and every permitted profile option in 'codecs' MUST be compatible with the processor profile defined in this document.
The SDP mapping SHALL follow RFC 4855: type 'application' in 'm=', subtype 'ttml+xml' in 'a=rtpmap', and the 'codecs' parameter MUST be included in the 'a=fmtp' line.
The TTML document root 'tt' element (in the http://www.w3.org/ns/ttml namespace) MUST include a 'timeBase' attribute in the TTML parameter namespace with the value 'media'. This prohibits the 'smpte' and 'clock' time bases.
When an active document D_(n-1) is superseded by a new document D_(n) with a later epoch, processing of D_(n-1) MUST stop at E_(n) and processing of D_(n) MUST begin at that point.
When fragmenting a TTML document across multiple packets, text strings MUST split only at character boundaries to enable decoding of partial documents; this requires knowledge of UTF-8/UTF-16 encoding.
Where end-to-end network conditions cannot guarantee acceptable packet-loss limits, implementations MUST use a mechanism to protect against packet loss, such as FEC (RFC 5109), retransmission (RFC 4588), or duplication (SMPTE ST 2022-7).
The default RTP clock rate for TTML over RTP is 1000 Hz. When TTML is synchronized with other media (e.g., video or audio), it is RECOMMENDED that all streams share the same clock source and rate.
The Marker Bit (M) in the RTP header is set to '1' to indicate the last packet of a TTML document, and '0' otherwise. The first packet may also be the last.
The RTP Timestamp encodes the epoch (E) of the TTML document carried in the payload. All fragments of a single document share the same timestamp but carry different consecutive Sequence Numbers.
The TTML feature extension designation 'urn:ietf:rfc:8759#rtp-relative-media-time' identifies processors that set the epoch E to the RTP Timestamp as required by this specification. The namespace 'urn:ietf:rfc:8759' is defined per RFC 2648.
Receivers must validate that User Data Words are of the length specified in the Length field to avoid potential buffer overflow attacks.
Repeated expansion of maliciously constructed XML entities can consume large amounts of memory, potentially causing XML processors in constrained environments to fail, as noted in RFC 7303 Section 10.
This payload format places no restrictions on document size or frequency, so malicious implementations could mount denial-of-service attacks. Senders should avoid DoS-like stream behavior and receivers should avoid false-positive identification of legitimate streams as malicious.
The TTML RTP payload prepends a standard RTP header with two additional 16-bit fields: Reserved (must be 0x0) and Length (byte count of the User Data Words). User Data Words follow and carry the full or partial TTML document.