TTY & real-time text
Captions, TTY, and RTT: choose the right text communication
Captions turn speech into readable text. TTY and real-time text carry typed conversation. Start by deciding what each person needs to send and receive.
By Tenacity Updated
Three terms that describe different jobs
| Approach | What it does | What to establish |
|---|---|---|
| Speech captions | Present spoken conversation as readable text. | Which speech is captioned, where it appears, and how the user responds. |
| TTY | Lets people type and read telephone conversation, including traditional devices that send text as tones. | How the telephone network carries those tones and what the receiving endpoint supports. |
| Real-time text (RTT) | Sends typed text during the conversation instead of waiting for a completed chat message. | Which RTT protocol the endpoints and intervening service support. |
These may all show words on a screen, but they solve different communication problems. A speech-to-text display does not by itself let a caller type a response. A TTY endpoint does not automatically caption the speech of a person using a voice phone. Define both directions of the conversation.
Check the full route, not just the softphone
A typed call can cross an endpoint, a PBX or cloud calling platform, an external carrier, and a receiving service. Determine whether the route uses traditional TTY audio, supported RTT, or a conversion between them. A normal voice call succeeding on that route does not prove that its text path also works.
RFC 4103 specifies a way to carry real-time text in RTP packets. Ask whether the configured service and endpoints support the required text transport. “SIP compatible” alone does not answer that question: call setup and text-media interoperability must both be addressed.
Tenacity’s ipTTY is a Windows software option for typed telephone communication. The RingCentral ipTTY listing describes its SIP/RTT integration. Confirm your current service, operating system, and call route before using a directory entry as an installation specification.
Plan how staff will receive typed calls
For an incoming accessibility line, the operational question is larger than which application to install. Decide who answers, how staff recognize a typed caller, what happens when the primary person is unavailable, and how a conversation reaches the right department. Give staff a short handling procedure and practice it with the actual equipment.
Keep the caller’s communication method available during escalation. An ordinary transfer that loses the text session can make a successfully answered call unusable. Include transfers, queues, and an accessible alternative contact route in the evaluation when the service needs them.
TTY Agent is an on-premises virtual appliance that auto-answers TTY/TDD calls, decodes Baudot tones into text, uses a local AI assistant with customer-approved knowledge-base content, and escalates complex calls to a browser-based human queue.
Verify both directions before choosing a solution
- Identify at least one real sending and receiving endpoint for each required call route.
- Send names, numbers, punctuation, and ordinary conversation in both directions.
- Test incoming as well as outgoing calls; do not assume they use identical routing.
- Try the staff handoff and end-of-call process. Confirm that the user knows when the other person has finished.
- Review any saved text, who can read it, and how it is deleted according to your organization’s policy.
Record the protocol and tested configuration with the result. If the need is reading spoken calls instead, return to the workplace captioning guide. If the barrier is operating buttons or reading call status, consider accessible phone control. Choosing the right category early avoids an expensive trial of a product that cannot perform the required conversation.