skip to main content

High Contrast | (-) Smaller Font | (+) Larger Font

PDF Version

Proposal R1 for Implementation of Real-Time Text Across Platforms

Built on the Industry-Consumer Consensus Provisions on Real-Time Text, submitted by the Telecommunications and Electronic and
Information Technology Advisory Committee (TEITAC) to the Architectural and Transportation Barriers Compliance Board  (Access Board) in April 2008

Developed by the Telecommunications Access Rehabilitation Engineering Research Center (RERC) Trace R&D Center – University of Wisconsin-Madison and The Technology Access Program (TAP) – Gallaudet University

VERSION 1.0

December 10, 2008

The contents of this proposal were developed under a grant from the Department of Education, National Institute on Disability and Rehabilitation Research grant number H133E040013. However, those contents do not necessarily represent the policy of the Department of Education, and you should not assume endorsement by the Federal Government.

1.)  Introduction

Real-time text (RTT) is a mode of communication that permits flowing text conversation, mixing of text and voice, and efficient text communication for urgent and emergency calls. It functions much as voice communication functions, allowing for interruption and for following the flow of conversation as it proceeds. It is distinct from instant messaging, SMS, and email in its fundamental properties.

The availability, reliability, and interoperability of text communication are important for equitable communications by people who are deaf, people who are hard of hearing (who may not reliably understand conversations without some or all of the conversation being in text), and for those who can hear but not speak. The increasing number of older people who are hard of hearing and will need incoming text to supplement speech in order to have reliable phone communication makes the need for real-time text all the more critical.

Migration to VoIP is well underway but implementation of equitable access via text has not occurred.

The purpose of this document, Proposal R1, is to provide a common point of discussion, and to clear up any confusion or misunderstandings about what is involved in implementing real-time text. This proposal builds upon a consumer-industry consensus agreement reached during the deliberations of the U.S. Access Board’s Telecommunications and Electronic and Information Technology Advisory Committee (TEITAC). More information about TEITAC is included in Appendix 1.

Specifically, Proposal R1 seeks:

  1. to provide a concrete proposal, with details, around which discussion can be carried forward and agreements reached
  2. to answer questions and clear up misunderstandings
  3. to lay out the benefits of real-time text to all stakeholders including
    1. consumers with disabilities
    2. elders
    3. potentially all telecommunications users, especially in emergency situations
    4. industry

This document contains the following Sections:

  1. 1.) Introduction - (this section)
  2. 2.) Proposal R1  – lays out the basic proposal for real-time text
  3. 3.) FAQ – addresses key user and industry questions 
  4. 4.) Benefits to Users – outlines benefits of R1 to users (with and without disabilities)
  5. 5.) Industry Benefits and Considerations – addresses issues of interest to industry
  6. 6.) Real-time Text Standards  – summarizes all existing real-time text standards
  7. 7.) Implementations – provides additional implementation information and options
  8. 8.) References and Extracts – provides excerpts from standards and other documents describing implementation specifics for the real-time text feature
  9. (Appendix 1) TEITAC Consensus Language – that this proposal is built upon
  10. (Appendix 2) Details on requirements and benefits for different user groups

2.)  Proposal R1

Goal of Proposal R1

The goal of Proposal R1 is to ensure that, wherever voice is supported in IP for conversational communication, reliable and interoperable real-time text, that can be used alone or together with voice, is also available and supported.

Quick Summary Benefits of Proposal R1

  • Cross-disability – Proposal R1 addresses the needs of a wide range of users including people who are deaf, late deafened (and communicate in speech and text), hard of hearing (and need captioned telephone) and those who can hear but are speech-disabled.   It could also open up IP telecommunication at lower costs for individuals who are deaf-blind.
  • Standards based – Proposal R1 is based on industry standards from the standards groups (ITU and IETF) that created almost all of the standards used in VoIP today.
  • Mainstream technology based – – Proposal R1 provides access via mainstream phone technologies – moving away from special devices (such as TTYs).  This eliminates the need to support, distribute and maintain compatibility between mainstream devices or networks and special devices that use non-mainstream text formats.  It would also allow users with disabilities to be able to take advantage of the same cost saving calling plans, bundles, etc from telecommunication vendors that everyone else enjoys.
  • Mainstream usable – Proposal R1 enables new mainstream applications and features on phones.
  • Flexible – Proposal R1 allows companies to choose their own format for the transport of real-time text within their systems as long as it is reliable and interoperable.
  • Opens up communication – Proposal R1 allows people using text to be able to communicate with most mainstream callers.  Those who need to use text could call friends, family, co-workers, and strangers without friends or family having to own special telecommunication devices or having to use relay services with the loss of privacy.
  • Allows direct communication – By allowing people to communicate directly with each other in voice and/or text as needed, more personal and private communications are possible.
    Promotes international harmonization – Proposal R1 uses international standards, so that companies can use one solution that will work in all countries, rather than the multiple standards used for TTYs and textphones today.  This will also allow all of the groups who need to use text (see above) to be able to talk internationally as voice callers do today.
  • Supports character- and sentence/message-based text during a call – Real-time text allows users to send text character-at-a-time as it is typed for real-time conversations, for relay service use, for captioned telephone, and for emergency communication. RTT transport formats (and Proposal R1) also allow a second, user selectable mode of transmission in sentences or messages for those who prefer to send text only after finished or reviewed.
  • No increased phone hardware costs – Proposal R1 only requires real-time text support on phones and other terminal devices if the display or text entry hardware needed to support RTT is already a part of the device for other purposes.  (For example, a phone may already have a multi-line display for the phone’s menus, contacts, SMS, etc.  Or a device may already have a means for the user to enter text in order for the user to enter contacts, speed-dial names, etc.)

The 11 Parts of Proposal R1

  1. Wherever voice communication is supported, reliable and interoperable real-time text is available and supported. 
  2. A 'Common Real-time text Interconnection Standard’ (CRIS) is established and supported by all VoIP systems at their borders to insure that when VoIP systems interconnect real-time text can travel between them.
  3. Any format or standard for real-time text can be used by manufacturers and service providers within their system, as long as all of the following reliability and interoperability measures are true:
    1. 3.1 The characters are transmitted within 1 second of when they are generated.
    2. 3.2 The text is transported as data and not as tones (where ‘tones’ refers to coding of data in audio form, as has been done for TTY and other analog text telephone protocols).
    3. 3.3 There is less than 1% character error rate (within a system including its gateways).
    4. 3.4 The RTT format is supported by all components in the system in which it is used (works with all terminals, routers, etc.).
    5. 3.5 Where the internal RTT format chosen is not the same as the CRIS, then conversion between the internal RTT format and CRIS takes place at the edges of networks, where it connects to devices or systems that might use other RTT formats.
    6. 3.6 Transmission supports Unicode character set.  (Support at terminals is recommended.)
  4. Speech and real-time text work in both directions in the same call session.  If all connections and legs are IP-based, speech and real-time text can be used simultaneously in both directions in the same call session. (If there is a PSTN leg in the path, then simultaneous speech and text is not required.)
  5. The user can choose to text in real-time or in blocks (sentence-based, paragraphs, etc.).
  6. If in message mode, the mode automatically switches to real-time text when an emergency number is known to have been dialed.
  7. If a product that supports voice communication already has a multiline display for any purpose, then when real-time text is sent to the product, it must accept and display the real-time text. (This includes software that runs on a device that has a multiline display.) (A display does not need to be added for this purpose if it is not already present.)
  8. If a product that supports voice communication already has the ability for users to create text for any purpose, then it will allow the user to generate and send real-time text. (A text-entry capability does not need to be added for this purpose if it is not already present.)
  9. Special public switched telephone network (PSTN) gateways are established to handle the translation of text between analog TTY formats on the PSTN and the VoIP standard format (CRIS) on IP networks, until analog TTY use ceases. A mechanism is established to allow users who are reliant on TTYs to route their calls to the special gateways using a prefix or special number.
  10. VoIP devices are not required to support TTY formats directly – only through gateways.
  11. The CRIS would be established as IETF SIP for call control, ITU-T T.140 for real-time text presentation, and IETF RFC 4103* for the real-time text transport.

* RFC 4103 is proposed because it is lighter weight and has the largest commitment and implementation support.  Multiple companies have or are developing products using RFC 4103 and it is cited in numerous IP and e9-1-1 planning documents in US and EU.

3.) Frequently Asked Questions

3.1 Questions About Real-time Text Usage

Q1) If users have IM, why would they want real-time text?

This question comes up often because IM has become widely used, and has been considered synchronous communications when compared to email.  The chart below demonstrates the many advantages of RTT compared to email, SMS, and IM:  

Email
  • advantage Allows long messages
  • advantage Can send when receiver not on-line
  • advantage Complete interoperability (all email programs work with all other email programs)
  • disadvantage  Delivery is reliable but irregular and can be slow 
  • disadvantage  Spam blocker or spam load can cause email to be lost

SMS
  • disadvantage  Messages limited to 160 (Latin) characters
  • advantage Can send when receiver is not on-line
  • advantage Today SMS is interoperable – and most are also interoperable with email
  • disadvantage  Delivery is irregular and can take quite awhile sometimes

  • disadvantage There is no guarantee of delivery (messages are dumped in overload or long delay situations)

Note:  As IP comes to phones, SMS is predicted by many to disappear in favor of IM which is free (though not currently interoperable).

IM & Chat
  • advantage IM is delivered immediately (usually less than a second after the transmitting person sends)
  • advantage Individual messages are generally not long but are not limited like SMS
  • advantage Chat offers good multiparty functionality
  • disadvantage In close or intense conversations, IM causes one user to wait with a blank screen, wondering what the other person is typing and when it will come.  When the message is long or the typist slow this can lead to frustration or sending of another message.
  • disadvantage Crossed messages can occur and lead to misunderstanding and loss of time. (Crossed messages are where a person sends a second message before you finish answering the first.  In an emergency situation, a panicked caller may ask a second or third question if there is no immediate visible response from the 9-1-1 call-taker.  This can lead to confusion, crossed answers, and error.
  • disadvantage  Typically, can only send messages when both sender and receiver are on-line (though some store messages and wait until both parties are on-line to deliver)
  • disadvantage  IM is not currently interoperable so messages cannot be sent from one system to another.  There is software that enables logging into multiple IM systems at the same time – but it does not allow conferencing and other features of the individual IM systems.
  • disadvantage  IM cannot be used with captioned telephone relay services.  (Many IM have voice but IM is not real-time except for AOL’s IM with real-time text option.)
  • disadvantage  IM does not have the same ‘wiretap’ protections as voice phone calls do.

RTT
  • advantage RTT is immediate: instant delivery and instant view of letters as they are typed
  • disadvantage RTT requires both parties to be on-line at the same time, like a phone call
  • disadvantage RTT displays errors in typing (unless used in block transmit mode)
  • advantage RTT typing errors can be corrected after transmission.  Erasure works across connection.
  • advantage RTT is like voice and signed languages in that it is continuous and there is no waiting to see what is being said – or for the receiver to read the sender's message after completion.
  • advantage In time-limited situations, RTT can save time. The receiver can see the text as it is being typed, and when they see that what has been typed is sufficient, they can interact to confirm – shortening message and eliminating typing that is not needed.
  • advantage Multi-party functionality is possible
  • advantage RTT can look like IM. RTT systems CAN send character-by-character or line-by-line at the user’s choice (though it should be character by character in 9-1-1 situations).
  • advantage RTT systems provide the real-time text required by captioned telephone relay services.  This mode presents voice and text transcription simultaneously for people who have voices and want to use their residual hearing.
RTT also has advantages in emergency communications
  • advantage RTT allows for the efficient exchange of information and a continued sense of contact.
  • advantage With RTT, there is less risk of crossed messages because the receiver can read the other person's message as it is typed.  There is no waiting or looking at a blank screen.

  • advantage With RTT, all messages are delivered even if they are not finished. For example, the following messages would get through successfully with RTT:

    "I think I'm having a heart att..."

    "Help. My ex is breaking into my hous..."

    By contrast, no part of the above messages would be received using IM or SMS if, while the caller is still typing, the emergency prevents that person from finishing the message and pressing the send key.

  • advantage With RTT, emergency call-takers can view the message as it is being typed and respond, refer, interrupt, or guide the information being sent to speed up communication and make it more helpful to emergency responders.
Under Proposal R1:
  • advantage RTT would be as interoperable as voice.
  • advantage RTT would always be available where voice is available, so real-time text could be added to any call on any phone that had a multi-line display to make information clear to listeners who are hard of hearing.
  • advantage Because RTT will be part of the 'phone' call, it can be protected to the same extent that the voice content of calls are protected (wiretap restrictions, etc.).

Q2) How would this work with relay services?

Most U.S.-based IP text relay services already support a real-time mode between the text user and the communication assistant (see Section 7.5, Services and Service Elements), although proprietary protocols are often used by providers.  Proposal R1 would not need to directly affect these relay services.

However, Proposal R1 can make it easier to provide voice carryover (VCO) and hearing carryover (HCO) services over IP, because it uses standards-based voice and text for bridging the two legs of the call.  Therefore relay services may adopt Proposal R1 as they evolve their systems.

Proposal R1 also allows older people who are deaf and can speak (and who want to use voice carryover) to use any VoIP phone with a multi-line display.  This would eliminate the need to purchase special and more expensive textphones or to master use of a computer.

People using videophones that support real-time text could also use text as needed during a sign language call with a video relay service (VRS) to supplement sign language communications for numbers, codes, URLs, etc.

Q3) Can Proposal R1 support captioned telephone calls?

Yes. In fact, it would allow captioned telephone to be used with any phone that has a display on it. One would not need a special phone. This would include captioned telephone relay services but would also allow commercial captioning of phone calls in the same or in different languages (see Industry Issues and Benefits section that follows). It would also allow bi-directional captioned telephone where two users (with or without disabilities) could both see captions for each other’s speech.

Q4) Could people (particularly friends and family) with computers use them to communicate with real-time text users?

Yes. There would be a number of ways that people can use computers with real-time text. This includes communicating from computer to computer and communicating from computer to phones (wired and wireless). In fact, any time you can use voice between two modern IP devices you would be able to use text between them as well, with or without voice. Some computer-based real-time text options would include:

Q5) What if I use T9 on my phone keypad. Is that allowed?

Yes, if the phone supports T9, text could be sent in a word-by-word fashion under this proposal (rather than one letter at a time) since with T9, the correct text for the word is not created until the user finishes pressing all of the keys for the word.

Q6) Is speech recognition input allowed?

Yes.  If a phone (or computer) had speech recognition already on it, it could be used to send real-time text.  With speech recognition, the text is often not generated until entire words or sometimes phrases or sentences are recognized.  In this case, the text would be generated in those chunks and, as long as it can be automatically sent as it is generated and not accumulated, it would be real-time.

Q7) Can real-time text be combined with IM?

Yes. For example, AOL has combined IM with real-time text in AOL's Instant Messenger 6.8.  

In addition, under this proposal, any real-time text format can also be used to send message-at-a-time communication rather than just letter-at-a-time communication, and in fact this is encouraged.  Any real-time text format can be programmed to also allow the user to accumulate their text and then, when they are ready, send the whole message at once in a rapid sequence of packets of characters.

Proposal R1 only requires that every phone be capable of sending text in real-time. It does not require that all communications occur in real-time communication mode.  The user should be allowed to choose between real-time text and message-based text on any particular call.   

Q8) Could IM and other IP text users (who don't have a VoIP subscription) communicate directly in real-time text to hearing VoIP customers under Proposal R1?

Yes, in most cases. It would take a gateway between the IM service and the VoIP.

If the IM or IP text users were on a system that supported voice and connected to the phone system (as many/most do already) then Proposal R1 would mean that there would be a gateway that could translate the real-time text feature of the IM+Voice service.

If the IM they were using had no voice support whatsoever, then Proposal R1 would not apply and they could communicate with VoIP users only if there was an IM to VoIP gateway for that IM. This is not technically difficult, but would be needed and is not currently required.

Q9) Would users who are blind have access to real-time text under Proposal R1?

Since real-time text would be real text and is based on Unicode, it would be accessible and readable by any software the person who is blind is using to have the other aspects of their phone voiced to them.  On a phone call this would be by demand so that text is only voiced when asked to.  This also facilitates access by people who are deaf-blind.

3.1 Questions of a Technical Nature

Q10) When you say a company can use any real-time text standard they wish within their own systems, what exactly do you mean?

Companies may find that there are technical or cost reasons for them to use a particular technology to implement real-time text within their systems. They may even want to use a proprietary method for transport. With Proposal R1, any method can be used to provide the real-time text capability within a system as long as it is reliable, and it supports the Common Real-time text Interconnection Standard (CRIS) where their systems connect to other transport/call-handling technologies.

For example a company might have a comprehensive communication product that supports Voice + Video + IM within an enterprise. It would also allow calls out to other IP phone systems within the enterprise or outside. With Proposal R1 the company would provide real-time text in conjunction with their voice system. This might be separate from their IM or it might be a real-time text feature on their IM. They could use any technology or method they choose for the real-time text within their system as long as it was reliable, and, where they connect to other IP phone systems, they would convert their real-time text to the CRIS format. Since the other system would also support CRIS, the real-time text could flow between the two systems along with the voice.

Q11) Is a Common Real-time text Interconnection Standard (CRIS) really needed?

Different approaches have been proposed for transporting real-time text. Because some are incompatible with others, a coordinated approach is necessary to ensure RTT interoperability.

Unless there is one interconnection format that is supported by everyone, the only way to ensure that everyone can connect to everyone else would be for each company to support all of the other companies' formats. Because new formats will need to be allowed in the future, it is not technically possible to support all formats going forward.

Q12) Which standard would be used as the CRIS?

Although there is not yet a universal agreement on which standard to use as the CRIS, an increasing number of groups are choosing SIP as the call transport and RFC 4103 as the standard for real-time text. RFC 4103 is cited in most planning documents for next generation IP telecom and emergency response systems and is currently the most widely adopted and supported format for real-time text. (See References and Extracts Section).

SIP and RFC 4103 are therefore proposed for CRIS in Proposal R1: IETF SIP for call control, ITU-T T.140 for real-time text presentation, and IETF RFC 4103 for the real-time text transport.

Once formally established, the existence of a CRIS gives each company, or group of companies using the same call control system, a way to ensure interoperability while maintaining flexibility with regard to protocols internal to their products or systems. They can use CRIS within their systems where that makes technical and economic sense – or use any other reliable real-time text format and convert to and from CRIS at the edge of their systems where that is better technically or economically for them.

Q13) Would it be better to keep the selection of a proposed CRIS open until all interested parties have made a choice?

The IP voice communication infrastructure is rapidly being deployed.  In addition, a number of industry groups have already decided on their preferred real-time text transport formats.  But without a CRISthere is no way to ensure interoperability.  The sooner this common standard is adopted, the less expensive it will be to support throughout the system, and the less likely it will be that companies will have to retrofit or update an installed base that is being created.   Waiting only makes it harder and more expensive for everyone – and delays availability to those who need text to communicate.  Waiting also raises the potential that companies will develop products and features that will be incompatible with the standard chosen, creating more expenses associated with retrofitting.

Q14) Would it add cost to every voice communication product to require that it support real-time text?

The proposal would not add any hardware costs to support real-time text because it only requires products to receive and display real-time text if they already have a multi-line display (or software designed to run on a multi-line display); and it only requires products to send real-time text if they already have a mechanism for generating text for another purpose.

While this proposal would require initial software costs to develop, test, and connect a software text codec into their device software and to connect display and text generation software to the codec, both open source and commercial codecs and reference designs for implementation are available for this purpose.

Q15) Are there real-time text standards today?

Yes.  Details can be found in the Real Time Text Standards section of this proposal.

Q16) Are these real-time text standards in use today on network and consumer products?

Yes, some are.   For a listing of currently known products that use the standards, see the Implementations section of this proposal.

Q17) Why not just use TTYs with VoIP and the new IP networks?

There are a number of reasons for not using the older TTY standards to transmit text on the new IP networks. They include:

Q18) Do all PSTN to VoIP gateways need to support translation of real-time text to TTY?

No.  See Industry Benefits and Considerations section of this document for a longer discussion of this topic.

Q19) Will real-time text work with normal SIP security measures?

Yes.  There are a number of technical methods available for securing SIP calls, both for the call control security and the media security including real-time text. For the media, all agree that a method called SRTP, specified in IETF RFC 3711, shall be used.

Q20) Will real-time text be blocked by network security measures and firewalls?

Blocking of real-time text may occur where security or IT management personnel are not aware of real-time text and where it is not required to be supported.   By using a SIP-aware firewall, the firewall understands the media stream setup and keeps the media port open just during the call and directed to the terminal that set up the call.  If Proposal R1 is adopted, real-time text should be treated as a standard part of every SIP call and should not be blocked.   Regular use of real-time text by all callers (see next section) will also reinforce requirements to have proper pass-through for the real-time text part of the calls.

Q21) Would non-VoIP legacy cellular (GSM, CDMA, etc.) be affected by R1?

No.  Non-IP based legacy cellular (GSM, CDMA, etc.) would not be covered by  Proposal R1.

Q22) How would this apply to DTV and IPTV based telecommunication?

With the advent of digital television and IPTV, there are efforts to create IPTV based telecommunication (video phone calls).   If these calls are carried over IP networks then they would fall under Proposal R1 and real-time text capability would be needed in parallel with the voice.  Again, they could use any format for the real-time text as long as it is reliable and is converted to the CRIS if the network connects to other IP communication systems that support voice.    Systems that are not IP based would not be covered by Proposal R1.

4.) Benefits to Users

Proposal R1 would allow text communication on the Internet and VoIP telephone networks to be as fluid, interoperable, reliable, and ubiquitous as voice communications are.

It is important to note that text communication is used by different groups of people who have different functional requirements for accessibility – and who may need to use text in different ways. Some of the communication requirements for these individuals can be met through IM, SMS or real-time text alone while for others, concurrent real-time text and speech transmission is needed.

NOTE: In reviewing the needs of different groups for real-time text, it is important to remember that real-time text systems can allow users to choose between communicating character-based (for conversational typing), word-based (for T9 or ASR), or sentence-based (for message-like communication).

4.1) The benefits of Proposal R1 for individual populations:

Appendix 2 provides details on the requirements for each group as well as their benefits.

5.)  Industry Benefits and Considerations

5.1) Ability to use real-time text to introduce new mainstream features and capabilities.

Because real-time text would be interoperable and implemented using standard IP technologies and methods, it creates the opportunity for companies to implement real-time text in a way that can contribute to the public good and provide them with new marketable mainstream functionality as well.  Some potential new features would be:

  1. On international calls, participants could choose to have the call captioned in the language of their choice.
  2. A phone could have a feature that would allow a person to listen to one call and watch the captioning for a second call that was on hold.
  3. A person could turn on captioning when they were interrupted in their office so that they could catch up when they were finished with the interruption.  Similarly, people could take a health break and catch up when they get back.
  4. A 'queue' query feature could be implemented by a teleconferencing company that would allow any participant to type "q+" to raise their hand (without disrupting the call).   They could also type "q?" to have a waiting list sent to them so they can see where they are.  This could even be done by people using the captioning feature.
  5. In voice mail,  the ‘envelope’ information including name of the caller, return number (from caller ID), length of call, time of call, etc., could be sent and viewable on screen while listening to voice mail.
  6. If not otherwise being used for text conversation, it might be used to provide general advertisements.
  7. Text on a screen might be a much friendlier way to while away time than listening to music on hold.  Perhaps a scroll of today's headlines.  Or of the company news or new products. 
  8. On a phone call, real-time text can be used to ensure that booking numbers, phone numbers, email addresses, codes and other information are conveyed accurately and without great effort. This can be of particular benefit on international calls or for persons with different accents.
  9. If a manufacturer chose to provide real-time text along with an IVR's voice prompts, all users with a phone that has a display could quickly see all the choices in text instead of waiting for them to be read aloud – making IVR systems faster and less frustrating.

A few of these would require an on-demand speech-to-text service.  But for executives, the cost of missing information (and their personal cost per hour) would far exceed these costs.   And as speech recognition advances, the ability to use automated recognition with a moderately skilled person correcting it can move this feature to more users – but this can only occur if the capability is in the network and equipment.

5.3) Minimizing costs for access features

Proposal R1 does not require any additional hardware (displays, keyboards, etc.) beyond what a phone/device already has for other functions.   Open source versions of the software (stacks and Codecs), as well as some commercial versions (including reference designs) needed to receive and send real-time text, are available.   As a result, the costs associated with this proposal are primarily in the initial implementation for a company or transport technology.  But even these costs will be kept down if real-time text design is incorporated in the beginning of the design process.  At that stage, these costs should be merely a small fraction of the overall design costs, which can be amortized across all of the products sold – and carried forward to future designs.   Indeed, given the capabilities of modern VoIP devices (the only type of devices to which this proposal applies), the small software (including firmware) changes needed should not add any significant cost to the manufacture of the products.

5.4) Ability to combine with instant messaging functionality

Proposal R1 allows real-time text to be combined with IM in a number of ways.  

Note:  Proposal R1 does NOT require real-time text with IM products unless the products also support voice.

5.5) Concern about the responsibilities of carriers

In response to a question about whether carriers had to provide real-time text products or whether they just have to pass real-time text through their systems, under Proposal R1:

5.7) Concern about the availability of sufficient equipment

If Proposal R1 is implemented, there will be wide range of standard desk, wireless and computer-based (softphone) VoIP phones that will support real-time text.  In addition, specialized phones that are tailored to meet the needs of people with more severe disabilities (e.g., individuals who are deaf-blind) will also exist.   Thus, it is anticipated that there will be sufficient equipment on the free market to meet the real-time texting requirements of all users.

NOTE: It is anticipated that real-time text will eventually be like captions on TV in that it will not just be people who are deaf who find this feature useful.  Anyone on a phone call who wants to convey a credit card number, address, or other detailed information might find it handy to send it as real-time text rather than via voice when their phone has text capability.  

5.8) Concern about every PSTN to VoIP gateway having to do TTY conversion.

Under Proposal R1, a carrier does not have to translate between IP real-time text formats and TTY formats at every gateway between the two. Rather, special gateways would be established, along with mechanisms that callers could employ to ensure that the calls are routed through these gateways.

Although the ideal way to handle this from a consumer perspective would indeed be that every gateway between VoIP and PSTN would translate between the VoIP real-time text standard format and the PSTN analog format, there is great concern among carriers that this is not technically feasible. There are too many such gateways and their technology level varies greatly. Also, real-time text support on the gateways may use up twice the ports on the IP side. For the relatively small amount of real-time text flowing through the gateways, this limitation of the ports would not be a problem if it only occurred on calls with text. But with calls coming from the PSTN side, it is not always possible at call origin to know whether the call will contain analog text (TTY). As a consequence, all calls would have to be set up to support text, or be able to re-invite with text, or have a mechanism to handle this. This is not too complicated for special gateways but it may be problematic for the installed base of network gateways, especially given the declining nature of TTY traffic.

Still, the fact is that everyone is not on broadband today. Until PSTN disappears, there will be people with hearing or speech disabilities who are on PSTN who still need to communicate in text. This is why support for analog text formats and their ability to communicate with the rest of the world is still needed.

Proposal R1 says that, instead of all gateways having to support TTY translation, special gateways will be established that can handle the translation of text between analog formats and the VoIP standard format. PSTN callers would have to use a prefix (short or full 10-digit) when calling in order to have their calls routed through one of these gateways. Those who do not use the prefix would have their calls put through and TTY tones would arrive at the calling end – but the tones may not be reliable enough for good transmission – and reception at the far end would require that the person have a TTY (as is required now). Standard VoIP phones that do display IP real-time text would not have to support TTY text.

What does this look like to the text (IP) and TTY (PSTN) user?

What does this look like to carriers?

What does this look like to manufacturers?

5.9) Benefits from using RFC 4103 as the internal real-time text format in networks.

In Proposal R1, it is proposed that RFC 4103 be used as the Common Real-time text Interconnection Standard.  This is both because of its inherent characteristics (light weight, uses RTP, built-in redundancy, international character set support (Unicode), robustness, etc.) and because of the level of implementation to date.  

In addition to being used as the CRIS, it also has many advantages for use within networks, particularly SIP and H323 networks.   These include:

6.) Real-Time Text Standards

For the PSTN, there are different standards in different countries: TIA-825 transmission of Baudot (TTY) is used in the U.S., while a half dozen other standards (e.g., TTY, V.21, EDT, DTMF) are used in other countries. (This has caused great problems with interoperability between countries.)1

For VoIP, there currently is only one IP real-time text standard format in use today for products other than gateways: IETF RFC 4103. Other formats have been discussed in standards groups (e.g., sending characters individually using IETF MSRP messaging technology) but have not been standardized or used. In addition there are three methods for transmitting the older real-time text formats analog (e.g., TTY, V.21, EDT, DTMF) over IP networks for use between gateways. But the only standard for sending text as text in real-time, intended for non-gateway applications, and currently in use, is RFC 4103.

6.1. Real-Time Text Presentation Standards

6.2. IP Real-Time Text Standards

6.3. IM (Messaging) Standards Where Real-Time Text Option Was Discussed

6.4. Standards for Transmission of Analog Text Formats Over IP Networks or Legs

1 The term TTY is used in U.S. telecom policies to refer to text telephone devices using Baudot TIA-825 over the PSTN.  While some other countries also use this term to refer to such analog devices, many other countries use the term ‘textphone.’  For the purpose of interpreting this paper in other places around the world, the term 'analog textphone' could replace "TTY," and "ITU-T V.18 and its sub-modes" could replace "TIA-825."

7.) Implementations

7.1) Phones and system components that have implemented real-time text

7.2) Network components

7.3) Implementation tools available

7.4) Codecs available

7.5) Services and service elements available

8.) References and Extracts

Specifics on implementation of a real-time text feature in IP environments have been described in a number of standards and published documents.  Some of them are referenced here, with an extract of the text.

Links to many of the standards, and further descriptions of available components can be found in the real-time text forum group of the Internet Society ISOC at www.realtimetext.org.

EU COCOM 04-08 Report from the inclusive communications (INCOM) subgroup

"The favored solution is to adopt a single, IP-based set of preferred standards for all modes of accessible conversation facilitation. The set of preferred standards are IETF SIP for call control, ITU-T H.263 for video, ITU-T T.140 with transmission as specified in IETF RFC 2793 for text and ITU-T G.723.1 for audio. Nothing prevents implementations to include other coding standards, but the preferred ones should be maintained for interoperability."

Note:  RFC 2793 is a compatible predecessor, replaced by RFC 4103.

EU TCAM eWGD Roadmap to accessible telecommunications services and terminals

"Two way simultaneous real-time text should be provided with low delays. The delay for characters from entry to remote display should be short enough to allow a good sense of connection between the parties. This immediacy and two-way simultaneous transmission will allow parties to interact with each other in a conversational manner. Transmission can be made time-based three times per second in order to keep network resource usage low with maintained user satisfaction. There are existing standards for this mode of text conversation, so this implies adding these standards in an interoperable way into terminals and services."

EICTA recommendations on Total Conversation – from Vision to Implementation

  •  “There is a clearly defined evolution path to Total Conversation service
    • T.140, RTP, UDP http://en.wikipedia.org/wiki/User_Datagram_Protocol, and SIP are the basic protocols that pave the way for Total Conversation service.
    • The interfaces will be based on open international standards.
    • Terminals and services using deviating protocols due to short term technological reasons may be used but they are encapsulated and interoperability is ensured via gateways."

IETF RFC 4103  RTP Payload for text conversation

"Abstract
This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.
This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss."

IETF RFC 5012  Requirements for Emergency Context Resolution with Internet Technologies.

"Emergency calling must support a variety of media.  Such media should include voice, conversational text (RFC 4103 [RFC4103]), instant messaging, and video."

IETF RFC 4504  SIP Telephony Device Requirements and Configuration.

    "Req-55: SIP telephony devices that include a display, or have a facility for connecting an external display, MUST include protocol support as described in RFC 4103 for real-time interactive text."

IETF RFC 4733  RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals.

    "The gateway or end system can change to a higher-bandwidth codec such as G.711 when tone signals are to be conveyed.  See new ITU-T Recommendation V.152 for a formal treatment of this approach.  Alternatively, for fax, text, or modem signals respectively, a specialized transport such as T.38 , RFC 4103, or V.150.1 modem relay may be used."

IETF RFC 4734 Definition of Events for Modem, Fax, and Text Telephony Signals.

"2.7.1.  Signal Format Indicators for Text Telephony Legacy text telephony uses a wide variety of terminals, with different standards favored in different parts of the world.  Going forward, the vision is that new terminals will work directly into the packet network and be based on RFC 4103 packetization of character data.  In anticipation of this migration, it is RECOMMENDED that text carried in the PSTN by legacy modem protocols be converted to RFC 4103 packets at the sending gateway."

IETF RFC 4351   Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream.

"The payload format for real-time text transmission with RTP described in this [standard] is intended for use between Public Switched Telephone Network (PSTN) gateways and is called audio/t140c . ----

The audio/t140c payload specification is intended to allow gateways that are interconnecting two PSTN networks to interleave, through a single RTP session, audio and text data received on the PSTN circuit.

The audio/t140c format SHALL NOT be used for applications other than PSTN gateway applications.  In such applications, a specific profiling document MAY make it REQUIRED for a specific application. The reason to prefer to use audio/t140c could be for gateway application where the ports are a limited and scarce resource. Applications SHOULD use RFC 4103 for real-time text communication that falls outside the limited scope of this specification."

IETF RFC 5194  Framework for Real-Time Text over IP Using  the Session Initiation Protocol (SIP)

  "The Real-Time Transport Protocol (RTP) is the protocol of choice for real-time data transmission, and its use for real-time text payloads is described in RFC 4103."

....and...

"ToIP services MUST support the Real-Time Transport Protocol (RTP) according to the specification of RFC 4103 for the transport of real-time text between participants.  RFC 4103 describes the transmission of T.140 real-time text on IP networks."

3GPP TS 26.114  IP Multimedia Subsystem IMS; Multimedia Telephony; Media handling and interaction.

"7.4.4  Real-time text
The following RTP payload format shall be used:

  • T.140 text conversation RTP payload format according to RFC 4103."

3GPP TS 26.235 Packet Switched Conversational Multimedia Applications; Default codecs

  "RTP payload format for the ITU-T Recommendation T.140 text conversation coding is specified in IETF RFC 4103."

3GPP TS 23.226  Global Text Telephony; Stage 2.

   "IP Multimedia, supported by the IPMM subsystem, is a suitable environment for real time text conversation. It shall use IETF SIP, with text coded according to ITU-T T.140 and transported with IETF RTP-text as indicated in 3G TS 26.235. This allows conversation in a selection of simultaneous media, such as text, video and voice."

ITU-T J.161  Audio and video codec requirements and usage for the provision of bidirectional audio services over cable television networks using cable modems.

"When text is combined with audio, the real-time communication may be established as described in [ITU-T F.703], [ITU-T T.140] and [IETF RFC 4103]."

ITU-T H.248.2 Gateway control protocol: Facsimile, text conversation and call discrimination packages

   "Text received through the V.18 modem is converted if necessary to T.140. It is embedded in the RTP/T.140 format according to the rules in T.140 and IETF RFC 2793, specifying RTP/T.140." 

Note: RFC 2793 is a compatible predecessor, replaced by RFC 4103.

ITU-T V.151 Procedures for the end-to-end connection of analogue PSTN text telephones over an IP network utilizing text relay.

    "In general, ITDs transmit text characters when communicating with other ITDs using [b-IETF RFC 4103], which specifies the establishment of a separate RTP stream specifically for transmitting text characters."  

Note: ITDs refers to IP terminals.

ETSI EG 202 320 Duplex Universal Speech and Text (DUST) communication.

"C.3.1.1.2          Text transmission with RTP

Media is transmitted with Real Time Protocol (RTP). By specifying a method based on RTP for the text transmission in SIP calls, the same mechanism is used as for other media. Audio and video are also sent using RTP, using other payload descriptions. This allows the text medium to be treated in the same manner as other media in the call and so reduces the risk of blocking. No extra servers are required, no special routing and no special protocol support. Currently, RTP is the only formally allowed protocol for media transmission in SIP calls, and therefore is also the natural choice for text.

For each type of medium and coding, a specification must exist, describing how this medium is put in packets and transmitted. These specifications are called RTP payload specifications. For real time text, the RTP payload specification is RFC 4103 "RTP Payload for text conversation". This specification describes how to put the characters and other related information in packets, and also describes a procedure to make the transmission reliable."

Draft ETSI ES 202 325 Harmonised Relay Services

"A.2.3  IP based text service

Any IP based text relay service should be interoperable with any text terminal or service using IETF SIP for call control and IETF RFC 4103 for real-time text. Audio support should be provided for G.711 A-Law.

Further guidance on IP access can be found in ETSI EG 202 320."

"A.2.4    IP based Video service

Any sign relay service should be interoperable with IP based video terminals or services using IETF SIP for call control and ITU‑T Recommendation H.263 for video. It should also provide support for ITU‑T Recommendation H.264 for video. The relay service should offer sign language with good usability as described in ITU-T Series H Supp. 1.

Audio support should be provided for G.711 A-Law encoding.

Real-time text support should be provided in accordance with IETF RFC 4103.

Further guidance can be found in ETSI EG 202 320. "

Note: This draft is in member voting stage and approved by the Technical Committee ETSI HF.

Appendix 1 TEITAC Consensus Language (April 2008)

Proposal R1 builds on the consensus agreement reached between industry and consumers as part of the deliberations of the U.S. Access Board's Telecommunications and Electronic and Information Technology Advisory Committee (TEITAC) in April 2008.  This Proposal (R1) takes one step forward by making a proposal for CRIS from one of three alternative real-time text formats described in the TEITAC report.  The TEITAC report consensus language provided below is quoted from  http://www.access-board.gov/sec508/refresh/report/#656.

6-A: Real-Time Text Reliability and Interoperability

If hardware or software provides real-time voice conversation functionality it must provide at least one means of REAL-TIME TEXT communication where the following reliability requirements are met:

  1. Products must use a REAL-TIME TEXT (RTT) system that meets the following requirements:
    1. RTT format must be a standard REAL-TIME TEXT format for the voice platform that is supported by all TERMINAL, router, gateway and other products on that platform;
    2. RTT format must transmit characters with less than 1 second delay from entry;
    3. RTT system must transmit TEXT with less than 1% Total Character Error Rate at the peak network traffic specified for intelligible speech transmission (TEXT must work on the network as long as speech does);
    4. The RTT system, together with the audio system, must support speech and TEXT in both directions in the same call session (and support speech and TEXT simultaneously in both directions in the same call session if IP based)
    5. RTT system must not utilize audio tones for transmission of REAL-TIME TEXT over IP. Note: this is subject to a waiver of the TTY support requirement from the FCC for systems that implement IP based RTT. Also subject to consumer acceptance of prefixes or phone numbers to direct TTY traffic to gateways capable of handling TTY translation.
  2. Where products or systems interoperate outside of their closed systems, they must:
    1. If product interfaces with PSTN, it must use TIA 825A Baudot where it interfaces to the PSTN.
    2. If product interfaces with other VoIP products or systems (outside of a self-contained product-system) using SIP it must support transmission of TEXT as per XXX where it interfaces with other VoIP products or systems. Note: this is subject to a waiver of the TTY support requirement from the FCC for systems that implement IP based RTT. Also subject to consumer acceptance of prefixes or phone numbers to direct TTY traffic to gateways capable of handling TTY translation.
    3. If product connects to other products or systems using a protocol other than SIP it must use the standard REAL-TIME TEXT protocol that meets provision 1 above that has been established for that protocol.
      Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to fill the role of XXX. The intention is that XXX will be replaced by one interconnection format in all places it was used.
      Note 2: All products may support and use other protocols in addition to these as long as they meet the 5 requirements of 5-B(1) above.
      Note 3: A self-contained SIP system that uses the same real-time text protocol can be treated as a single product and can use any protocol internally as long as it supports XXX where the system-product connects to other systems or products.

6-B: Voice Terminal Hardware and Software

TERMINAL hardware or software that is capable of providing voice communications in real-time must comply with the following:

  1. Receive only: If hardware or software TERMINAL provides voice conversation over IP in any form, and has a user interface with a multi-line display or a user interface that runs on devices that have a multi-line display, then that TERMINAL must display any REAL-TIME TEXT that is received if it is received in the format for the voice and REAL-TIME TEXT system being used on the network on which it is installed.
  2. Send and Receive: If TERMINAL hardware or software provides voice conversation over IP in any form, and has TEXT generation capability, then the TERMINAL must allow users to send REAL-TIME TEXT in the format for the voice and REAL-TIME TEXT system being used on the network on which it is installed.
  3. If IP TERMINAL hardware or software does not provide REAL-TIME TEXT send and receive capability then the TERMINAL must support the addition of TERMINALS and TERMINAL peripheral equipment that support REAL-TIME TEXT functionality in conjunction with the voice call functionality, in the same location and with the same permissions for use as their voice TERMINAL. If the TERMINAL is in a public or shared area and not in an individual's private work area then the connection must be possible [without requiring system-administrator intervention]. Note: the "without system-administrator intervention" is a serious concern due to security issues, but removal would prevent people from connecting devices outside of their home system. Additional work is needed to address this issue.]
  4. If TERMINAL is analog or TDM-digital wired TERMINAL then it must support the connection of a TTY via an RJ-11 jack in the same location and with the same permissions for use as the telephone and it must be capable of allowing simultaneous speech and TEXT conversation without interference or its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.

    Note 1:  Provision of the RJ-11 jack may be accomplished through one of the following techniques:

    1. provision of the RJ-11 jack on the telephone,
    2. the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet,
    3. having built in capability to support an RJ11 module that can provide a connection point for TTYs.

    Note 2:  The standard format for PSTN is TIA-825A. For SIP is it XXX. For other voice transport protocols the format is to be determined by the entity responsible for the voice transport protocol.

Rationale:

This provision, along with 6-A, allows people with disabilities to communicate using standard IP methods rather than continuing to support TTY within IP networks and devices.

Appendix 2 Details on Requirements and Benefits for Different User Groups

People who want to use TEXT IN BOTH DIRECTIONS

  • This includes
    • People who are deaf and also cannot speak
    • All people who are deaf when communicating with other people who are deaf
    • Hearing people who cannot speak – communicating with others who cannot speak or cannot hear

REQUIREMENTS FOR THIS GROUP

  • Need text in both directions
  • Messaging or real-time text can be used.  Both should be available to meet user needs and preferences.   In emergencies real-time text should be used.
  • Text only technologies and service plans (no speech support) are sufficient.
  • People at both ends of the call must have means to create and display text on their devices.

Technical Requirements:

  • TEXT SEND
  • TEXT RECEIVE
  • [NO VOICE SUPPORT required]

USER GROUP BENEFIT

For these callers Proposal R1 would mean that

  • they could communicate with each other using REAL-TIME text or MESSAGE based text
  • Special devices would not be needed. Standard devices could be used – allowing these people to benefit from mainstream special prices, deals etc.
  • They could use any device that has a multiline display and text generation capability.
  • This would include almost all cell phones and some desk phones as well as all computers, PDAs etc.
  • Text only plans could still be used – but the array of potential communication devices would be wider. 

In emergency situations – if they didn’t have a phone (or had one with a dead battery or out of range) they could use almost anyone’s phone because most phones would support text.

 

People who want SPEECH OUT and TEXT BACK

  • This includes
    • Some people who are deaf and can speak – communicating a person who can hear where person who is deaf would like to talk and have text back.
    • Late deafened adults  - who prefer to talk to the person they are calling and have the other person (or a relay service) text back to them.

REQUIREMENTS FOR THIS GROUP

  • The form communication for these callers is to speak and see text coming back.
  • Can use their speech and a relay service so that both they, and the person being called, do not need to type anything (especially important for elders).
  • Both people must have a means to display text.  Neither needs to have a means to create text if relay is used.  (A phone that displays incoming text but does not send text is sufficient).

Technical Requirements:

  • TEXT RECEIVE
  • TEXT + VOICE support needed on the call
  • [NO TEXT SEND capability needed]

USER GROUP BENEFIT

For these users – Proposal R1 would mean that

  • They could use almost all portable and stationary VoIP phones since almost all have a multiline display.
  • They could use PDAs or computers as well.
  • They could use relay services without any need for special equipment on either end.
  • Because standard devices could be used – these people can benefit from mainstream special prices, deals, etc.
  • In emergency situations – if they didn’t have a phone (or had one with a dead battery or out of range) they could use almost anyone’s phone because most phones would support text.
 

People who need to TEXT OUT but want SPEECH BACK

  • Hearing people who cannot speak – often need to communicate by text but would like to hear the other person (and not make them type).

REQUIREMENTS FOR THIS GROUP

  • For direct communication – the person who cannot speak would use text – and the other person would to talk back to them.  
  • This would require this person’s device to generate text but the person they are communicating with can use any device that receives text.

Technical Requirements:

  • TEXT SEND (only) for person without speech
  •  TEXT RECEIVE (only)  – required by other person
  •  TEXT + VOICE required by both people
  •  Alternately – the person without speech could use a relay operator.  The needs of the person without speech and the relay operator would be the same as the above.   The person being called by the relay operator would need no text ability.

USER GROUP BENEFIT

For these users, Proposal R1 would mean that

  • they could communicate with each other using REAL-TIME text or MESSAGE based text.
  • Special devices would not be needed. Standard devices could be used – allowing these people to benefit from mainstream special prices, deals, etc.
    • They could use any device that has any text generation capability.
    • This would include almost all cell phones, some desk phones, as well as computers, PDAs etc.
  • Loved ones, friends or even strangers could get calls from them without any of them having to have/buy a special  (higher cost) phone.  They could use the standard bargain phones since almost all have a multiline display.
  • In emergency situations – if they didn’t have a phone (or had one with a dead battery or out of range) they could use almost anyone’s phone because most phones would support text.  
 

People who need TEXT OUT and TACTILE BACK

  • People who are deaf and blind  – communicating with any of the other groups mentioned.

REQUIREMENTS FOR THIS GROUP

  • For many in this group it is necessary to communicate in text in both directions.  Messaging or real-time text can be used.  Both should be available to meet user needs and preferences
  • The person who is deaf-blind would need a specialized device with a tactile display – or a (specialized) phone that allows received text to be sent to an external tactile display.
  • The person being called requires a device that can send and receive text (or make the call through a relay that has these capabilities).

Technical Requirements:

  • TEXT SEND
  •  TEXT RECEIVE
  • [NO VOICE SUPPORT required]

USER GROUP BENEFIT

For these users  Proposal R1 would mean that

  •  Though they might need a special device or tactile display, they could communicate with others using REAL-TIME text or MESSAGE based text
  • Special devices would not be needed by the other person. Standard devices could be used – allowing the person who is deaf-blind to call almost anyone who has a device with a multiline display and text generation capability.
  • That would include almost all cell phones and some desk phones as well as all computers, PDAs etc.

In addition, it is likely that tactile displays could be connected to an increasing number of standard phones meaning that even people who are deaf-blind could take advantage of the lower costs of mainstream phones and phone plans (be they standard voice plans – that would now include real-time text) or text only plans.

 
  • People (without disabilities) – who want to communicate with any or all of the groups above.

An important stakeholder group that often gets left out is "all those who don’t yet have disabilities" that would like to, or need to, communicate with those that currently do.

Proposal R1 would mean that this group would be able to use their standard phones and phone plans and be able to communicate with their friends, family, or strangers who have disabilities. Most phones would provide the abilities needed to allow them to communicate with all of the groups above without any special features or phone plan additions.

 

PDF Version