Real-time text — the standards and the gaps — library

The relay-services entry explains why RTT replaces TTY as the network moves to IP. This one covers the standards that make RTT work — and the gaps that keep it from being the seamless successor it is supposed to be.

The core standards

RTT is a small, well-layered stack:

ITU-T T.140 is the presentation protocol — the actual text coding. It carries Unicode as UTF-8 and defines control functions like the missing-text marker and erasure, and it presents text as it arrives, with no required “message” or turn boundary. It is the coding reference every transport below cites.
RFC 4103 (“RTP Payload for Text Conversation”) maps T.140 onto RTP as media type text/t140. Because a lost packet would mean lost characters, RFC 4103 uses the RFC 2198 redundancy mechanism (text/red) — each packet repeats recent text (typically sent at ~300 ms intervals, rate-capped by an SDP cps parameter), so ordinary single-packet loss is recovered without retransmission.
RFC 9071 handles multiparty RTT through an RTP mixer, using the CSRC list to label each source and an rtt-mixer SDP attribute to negotiate the capability.
RFC 8865 carries T.140 over a WebRTC data channel; because that channel is already reliable and ordered, the redundancy mechanism is dropped.

Mechanically: keystrokes are encoded per T.140 and sent character by character (with small buffering) as T.140 blocks in a dedicated m=text media stream negotiated in SDP alongside m=audio — the “total conversation” model of simultaneous voice, text, and (optionally) video in one call.

RTT on mobile: IMS, VoLTE, VoNR

On mobile networks RTT is part of the IMS multimedia telephony service (MTSI). 3GPP TS 26.114 is the core spec — it defines the RTT media handling for VoLTE and VoNR, mandating RFC 4103 with redundancy and the rate/jitter handling around it. TS 22.173 lists real-time text as a first-class MMTel media component alongside voice and video, and TS 24.229 governs the SIP/SDP session control that negotiates the text media line. GSMA’s interoperability profiles — IR.92 for VoLTE and NG.114 for voice/video/messaging over 5G — carry RTT as the accessible-text component. US carriers implemented RTT natively on VoLTE against this 3GPP stack, per the FCC’s 2016 order (FCC 16-169), replacing the previously unreliable approach of pushing legacy TTY tones over VoLTE.

The gaps — the important half

RTT is standardized and, on the major nationwide carriers, deployed. But its real-world shortcomings are well documented, and they are the reason “RTT already works over IP” is only half true:

Cross-carrier, cross-OEM, cross-OS interoperability is the most-cited failure. RTT can break passing between devices on different networks or running different operating systems and manufacturer builds; the European emergency-number association calls device- and network-level interoperability one of the hardest hurdles, precisely because inconsistent implementations defeat end-to-end RTT.
The TTY-gateway downgrade. When an RTT user reaches a legacy TTY user through a gateway, the conversation drops to the Baudot/TTY character set (losing the full Unicode repertoire) and becomes half-duplex turn-taking rather than simultaneous character-by-character — at ~45 baud with no error correction, so garbling is inherent on the TTY leg.
911 / NG911 inconsistency. Full RTT-to-PSAP depends on NG911/ESInet readiness, which is incomplete, and responsibility for transcoding at the ESInet boundary has been ambiguous. In some jurisdictions enhanced RTT-to-911 is not expected until well into the transition.
“Message mode” versus true character-by-character. Some implementations — relay bridges, certain apps, TTY interworking — buffer and send text in chunks or lines rather than per character, which defeats the interactive, interruptible nature that makes RTT feel like conversation rather than texting.
Missing telephony features and coverage. RTT implementations often lack integration with caller ID, IVR/DTMF menus, call transfer, and conferencing. Many OTT/VoIP apps do not implement RTT at all, and wireline RTT is largely absent — a gap disability advocates flag as critical for older users, wireless-to-wireline interworking, and access to 911, 711, and 988.
Relay integration. Native RTT integration into relay-service operations was left open in the original rulemaking and remains incomplete.

These are almost certainly the shortcomings a working accessibility practitioner would raise: the protocol is fine, but the end-to-end experience still fractures at carrier boundaries, at the TTY gateway, at 911, and off the wireless network entirely.

What it would take

For RTT to be the first-class, native capability of an all-IP network that its design promises, the work is mostly at the edges of the standard, not the center: enforceable interoperability conformance and testing across carriers, OEMs, and OS builds; true character-by-character behavior everywhere, with faithful T.140 presentation; complete NG911/ESInet RTT ingestion with clear transcoding responsibility and universal reach to 911/711/988; wireline RTT parity and RTT in OTT apps; native relay integration; and multiparty and telephony-feature parity. Only once native RTT interoperability is proven end to end does sunsetting TTY backward-compatibility become safe. It is the same lesson as the rest of the transition: the standard being done is not the same as the capability being native, and the distance between the two is where real users get stranded.