On this page
Accessibility complaints filed against contact centers rarely start with a dramatic incident. More often, they begin with a customer who could not get through at all. For the roughly 15 percent of American adults who report some degree of hearing difficulty, traditional voice calls present a genuine barrier, and legacy workarounds like TTY devices have been fading from use for years. Real-time text has stepped into that gap, and contact center leaders who have not yet mapped what is RTT calling onto their infrastructure are running a compliance and customer experience risk they may not fully see yet.
What is RTT calling and how it works for emergency situations
RTT, or real-time text, is a communication method that transmits each character to the other party the instant it is typed, rather than holding the full message until the sender presses send. According to the FCC, RTT calls can be initiated and received using the same ten-digit numbers used for voice calls, and both parties can send and receive text simultaneously within the same session. That simultaneity is what separates RTT from SMS or in-app chat: the conversation is live, not asynchronous.
How RTT differs from TTY
TTY, the older teletypewriter standard, required dedicated hardware, a separate number and a relay operator in many situations. RTT is built into the native dialer on modern smartphones and runs over VoIP and LTE networks using the RFC 4103 protocol over SIP, as documented in Gallaudet University’s Technology Access Program interoperability research. No special device purchase is required. A caller simply enables RTT in their phone settings and dials normally.
The emergency services dimension
The stakes rise sharply in 911 contexts. A deaf caller reaching a public safety answering point via RTT can convey a situation in real time without waiting for a relay service to interpret and re-transmit. Characters appear as typed, including deletions and corrections, which means a dispatcher reads the unfiltered communication as it forms. That transparency matters when seconds count. Contact centers handling emergency escalations or serving utility, healthcare or public sector clients inherit this same obligation when their queues connect to any emergency-adjacent workflow.
Compliance requirements your contact center must meet
The FCC’s rules under the Twenty-First Century Communications and Video Accessibility Act require that advanced communications services support real-time text for people with disabilities. For contact centers, the practical implication is that any inbound queue accepting calls over IP networks must be capable of receiving and rendering RTT sessions. Routing an RTT call to a standard voice agent who sees no text, or dropping the session entirely, is not a compliant outcome.
ADA and Section 508 alignment
Beyond FCC rules, contact centers serving federal contractors or government clients face Section 508 obligations that require equivalent access across communication channels. The Americans with Disabilities Act applies to public accommodations and commercial facilities, and courts have increasingly interpreted digital and telephony channels as covered under its provisions. Organisations that have mapped their inbound calling services for voice SLA compliance but not for RTT accessibility may find a gap in their legal exposure analysis.
RTT compliance is not purely a technology certification exercise: it also requires that agents handling RTT sessions have been trained to read and respond to live text without the conversational cues that voice provides, which changes quality scoring criteria fundamentally.
What “compliant” actually means operationally
- The telephony platform receives RFC 4103 RTT sessions without converting or dropping them
- Routing logic can identify an RTT call and direct it to a trained agent or queue
- Agents have a screen interface that displays incoming characters in real time
- Quality monitoring tools capture RTT transcripts for compliance review
- Supervisors can join an RTT session for coaching without disrupting the customer
Integration challenges with existing telephony infrastructure
Most contact centers built their telephony stack around voice, and the upgrade path to RTT is not a single switch. The core technical issue is that RTT over IP uses the T.140 text protocol carried within an RTP stream, alongside the voice media. Legacy PBX systems and older ACD platforms were not designed to handle that combined media type, and many will silently strip the text component while passing the voice portion through, leaving the agent hearing silence from a caller who is typing.
A returns-surge scenario that exposed the gap
An e-commerce retailer running a 90-agent operation across day and overnight shifts hit a returns surge the second week of January. Call volume spiked, and the overnight team, running at reduced staffing, began logging an unusual pattern: short-duration calls with no voice activity that ended without resolution. By mid-week, eight such calls had been flagged by a team leader during a Thursday calibration session. The team leader pulled the session logs and found that all eight originated from a single area code with a high concentration of customers using a known deaf and hard-of-hearing support service. The platform, a SIP trunk arrangement purchased several years earlier, was receiving the RTT component but the agent desktop was rendering nothing. Agents heard silence and closed the interaction as an abandoned call. The fix required a firmware update to the session border controller and a new agent desktop widget, but the more significant cost was the week of unreached customers and the complaint filed with the FCC that arrived the following month. For more on how relay-assisted RTT calls flow through carrier infrastructure, the RTT relay service calls explained overview covers the network path in detail.
Cloud platform considerations
Cloud-native CCaaS platforms generally handle RFC 4103 more reliably than on-premise hardware, but middleware layers, screen-pop integrations and older CRM connectors can still break the text stream before it reaches the agent. Any integration point that inspects or transforms the SIP message payload is a potential failure point. Testing RTT end-to-end, from a physical handset with RTT enabled through to the agent desktop, is the only way to confirm the chain is intact.
RTT readiness factors across common contact center infrastructure types
| Infrastructure type | RTT session handling | Agent desktop visibility | Key risk | Source |
|---|---|---|---|---|
| Legacy PBX with PSTN trunks | TTY only, RTT not supported | No native RTT display | Silent call drop | Gallaudet TAP, 2015 |
| SIP trunk with older SBC firmware | Partial: voice passes, text may strip | Depends on desktop client | Text silently lost | Gallaudet TAP, 2015 |
| Cloud CCaaS (modern) | RFC 4103 supported natively | Built-in RTT widget | Middleware transform layers | Genesys definitions |
| Microsoft Teams telephony | RTT supported in calls and meetings | Native Teams interface | PSTN gateway compatibility | KIT SCC / Microsoft Teams RTT |
| WebRTC-based soft client | Experimental RTT over WebRTC tested | Browser-dependent | Interop with carrier RTT | Gallaudet TAP, 2015 |
Source: Gallaudet University Technology Access Program, 2015; Genesys; KIT SCC.
Measuring RTT adoption and customer usage patterns
RTT call volume is typically low relative to total queue traffic, which creates a measurement problem. When a contact center sees two or three RTT sessions per day across a 90-agent floor, those interactions rarely surface in standard reporting dashboards built for voice metrics. The result is that operations leaders have no reliable picture of whether RTT is working, failing silently, or simply not being discovered by customers who need it.
Metrics worth tracking
- RTT session initiation rate: how many inbound calls arrive with an active RTT stream
- RTT completion rate: sessions that reached an agent versus those that dropped or were routed to voicemail
- First-contact resolution for RTT sessions, compared against the voice FCR baseline
- Average handle time for RTT interactions, which typically runs longer than voice due to typing speed
- Post-interaction survey response rate from RTT callers, as a proxy for perceived accessibility quality
What low RTT volume actually signals
A contact center receiving almost no RTT calls despite serving a broad consumer base is not necessarily succeeding at accessibility. It may mean customers have already learned the channel does not work reliably and have stopped trying. Checking IVR logs for calls that entered a queue with an RTT stream and then abandoned within the first 30 seconds is a more honest diagnostic than raw RTT session counts. Abacus BPO, which has operated contact centre and back-office programmes since 2008 and holds ISO 18295-1 certification for customer contact centres, treats near-zero RTT volume on a consumer-facing queue as a signal to test the channel end-to-end before assuming demand is simply absent. The relationship between RTT and broader assisted-channel strategy connects to the same operational discipline required for self-service customer portaldesign: if customers cannot find or trust the channel, the data will not show them using it.
Frequently Asked Questions
What is RTT calling in simple terms?
RTT calling, or real-time text calling, transmits each character of a typed message to the other party as it is typed, rather than sending the full message at once. It runs over the same phone call session as voice, using the RFC 4103 protocol over SIP networks. It is designed primarily to give deaf, hard-of-hearing and speech-impaired users a direct, real-time communication channel without specialist hardware.
Is what is RTT calling the same as TTY?
RTT and TTY both send text over phone networks, but they work differently. TTY uses older acoustic or electrical coupling technology and often requires dedicated hardware and separate numbers, while RTT is built into modern smartphones and uses standard ten-digit dialing over LTE or VoIP. RTT is faster, requires no extra device purchase, and is the FCC-endorsed replacement for TTY on wireless networks.
Are US contact centers legally required to support RTT calling?
Contact centers operating advanced communications services under FCC jurisdiction are required to support real-time text for users with disabilities under the Twenty-First Century Communications and Video Accessibility Act. Those serving federal contractors or government clients also face Section 508 obligations. Routing or dropping RTT sessions without resolution is not a compliant outcome under these frameworks.
Why do what is RTT calling sessions sometimes show as abandoned calls?
Many older SIP trunk arrangements and legacy PBX platforms receive the voice component of an RTT call but strip the T.140 text stream before it reaches the agent desktop. The agent hears silence, sees no interaction, and closes the call as abandoned. This failure mode is silent in standard reporting, so it requires deliberate end-to-end testing from a handset with RTT enabled through to the agent interface to detect.
How should a contact center measure whether RTT calling is working?
The most useful metrics are RTT session completion rate (sessions reaching an agent versus those that drop), first-contact resolution for RTT interactions compared to the voice FCR baseline, and IVR abandonment logs filtered for calls that entered with an active RTT stream. Near-zero RTT volume on a consumer-facing queue should be treated as a testing prompt rather than evidence that demand is absent.
