Thread Subject: Real-time text requirements, comparisons and standards
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
Return to this mailing list's archives
From: Gunnar Hellström
Date: Mon, Aug 06 2007 12:35 AM
Subject: Real-time text requirements, comparisons and standards
Dear all,
I have noticed that in the efforts to create condensed but well defined
language for accessible conversational services, and specifically for
real-time text, the background and requirements may not always be clear.
Therefore I have made an effort to compose a description of what I see as
essential factors in accessible conversational services. I hope it can be to
some guidance in the work with the condensed statements:
We are working with a view that telecommunications suitable for people with
disabilities is best offered as part of the general telecom service
provision. This is required by many policy documents and even regulations,
and is the only realistic solution to the requirement to provide comparable
access to telecomms for people with disabilities. It is also commonly found
that features introduced because of accessibility needs are found very
valuable by most users.
The requirements on accessible real-time conversational services are:
1) interoperability, so that anyone can call anyone using accessible
conversational services just as hearing voice-phone users can.
2) good functionality, so that :
-it is possible to address all other telecom users by number or some
address form.
-it is possible to be alerted on incoming calls in a way that suits the
user,
by audible, tactile or visual means.
-it is possible to use video with quality for signing and lip-reading in
the calls
-it is possible to use text with good interaction for intensive exchange in
the calls
-it is possible to use voice with good hearing conditions during the calls
3) access to a range of services in a convenient way:
-Person to person calls, using the common media between two terminals.
-Emergency calls using any combination of the media video, text and voice.
-Calls through relay services to get translation between two communication
modes.
-Calls with legacy systems for text telephony where they still exist.
-Calls directly in voice between accessible terminals and voice telephone
terminals,
so that hearing persons easily can switch between accessible calls and
voice calls.
-Calls between different technologies, such as between mobile and fixed
networks.
-Supplementary services such as call forwarding and call transfer.
-Mulimedia IVR, and mulimedia answering machine services.
These main requirements need some explanations and specific detailing
Text specifics
The text medium is the one that is currently furthest away from being widely
deployed in an interoperable fashion with good interactivity, and therefore
needs most attention from the accessibility side.
Emergency services
The emergency service is the one that makes it most apparent that we must
get down to a very limited number of ways to make calls with the three media
video, text and voice. Emergency services cannot be expected to be
accessible from a wide range of different protocols and proprietary
services. And the service you use for everyday communication should also be
the one you use for emergency services, otherwise you will not have your
device in order for the emergency call the day when you need it.
Real-time text versus text messaging for the text requirements
Real-time text best fulfills the requirements for use of text during a
real-time call. It is found through brief research that if a character shows
up on the receiver's terminal not more than one second after a character key
was pressed on the transmitting side, then the users feel that it is a good
text connection suitable for conversations.
Messaging, where you do not send text until after a specific action, e.g.
pressing the Enter key, is also useful in many situations, and can to some
degree be used for similar conversation tasks as real-time text. But since
it has some evident drawbacks in some important situations with high
interactivity, and since it cannot be used for captioned telephony ( a key
new service for people who are hard of hearing), it is important to
implement reliable interoperable real-time text wherever voice calls are
implemented.
There are more mature, more commonly accepted standards for real-time text
than there are standards for text messaging. But implementation of the
real-time text standards lag behind.
Specific applications where real-time text is desired
The following are situations when it seems to be favourable for the
communication result to use real-time text:
-In intensive conversations, focused on getting to an agreement or solving a
joint task.
-When small items of information shall be transferred during a voice or
video call, like a booking number, an address etc.
-For phone or video conferences, where one or some participants are deaf or
hard-of-hearing ad get supported by typed interpretation (real-time
captioning of the call) (In these situations real-time text is important to
allow the person to keep up with the call and to be able to interrupt or
comment at appropriate times in the conversation flow)
-For calls with emergency services. (Imagine that a person is fainting or
pulled away before they press Enter and no message is sent. (With real-time
text, the emergency service would have everything up to the interruption
whereas for the messaging case they wouldn?t even know a message was being
prepared or that an emergency existed.) )
-For captioned IP telephony calls, where a relay service adds real-time text
to a voice call (The user who is hard of hearing both hears the caller and
sees real-time captioning of the call simultaneously.)
-For relay service calls, where text is a dominating medium in at least one
direction. The flow is much faster if real-time text is used. It causes less
frustration by the person being called. It causes better user satisfaction.
-In fact, in any communication situation it seems preferable that the
receiving part would benefit from getting a chance to view the entry as it
built up by the transmitting part, rather than just waiting.
Applications where text messaging may be equally usable as real-time text
But certainly there are situations when the difference in usability between
real-time text and messaging is not dramatic, and where the availability of
some text communication method at all is more important than how its timing
and transmission are arranged. That is for example:
-For side conversations, with occasional short messages exchanged during
other tasks.
-For discussions over formulating text or other topics that require more
thoughts and preparation than interactions.
-For multi-party chats where it is normally more interesting to take part
of completed entries than to read what each person is currently typing.
-For non-intrusive dialogues of low priority. It may feel good for the
transmitter to send a low priority question and know that the receiver does
not need to interrupt what she is doing, but may respond when it is
suitable.
However, in all these situations, a preview of the entry in creation would
not be disturbing.
Current standards for real-time text in IP
There is a standard for presentation of a real-time text dialogue valid for
any transport and environment. It is named ITU-T T.140.
Just as with voice and video, the real-time text medium needs to be
transported in a specific way in each call environment. Therefore a number
of standards describe how a T.140 dialogue is transported.
The current standard for real-time text transport in IP terminal calls is
IETF RFC 4103 "RTP Payload for text conversation".
<http://www.ietf.org/rfc/rfc4103.txt?number=4103>
http://www.ietf.org/rfc/rfc4103.txt?number=4103
It is using the same method for transmission as the voice and video media,
the Real Time Protocol RTP, with text coded as text characters in the
internationally usable code Unicode and its UTF-8 transform.
RFC 4103 is described for use for the real-time text medium in calls set up
through the call control protocols IETF SIP and ITU-T H.323. It is also
referenced from a large number of standards describing emergency services,
gateways, total conversation and text telephony services.
It is beneficial to use the same main transport protocol for all three media
because:
-Until recently RTP was the only allowed protocol for media in SIP, the
dominating call control protocol for IP telephony and IP multimedia.
Therefore other protocols are still not well supported through firewalls and
routers.
-By using the same protocol for text as for video and voice, the complexity
of the termnal is kept low.
-RTP has low overhead and low delay that makes it feasible to send text with
good flow without noticeable network load.
-No specific intermediate servers are used that can introduce delays or
reduced reliability.
Strategy for interoperability
For the IP environment, one call control standard and one text transport
standard should be the current default set. Since IETF SIP currently
dominates as call control protocol for VoIP and IP multimedia, it should be
viewed as the current default call control protocol. And since RTP with RFC
4103 is the only current standard for real-time text transport in IP
terminals, it shall be viewed as the current default real-time text
protocol. If anyone wants to create something different, it should of course
be allowed, but interoperability must be assured through universal support
of this default set of standards.
In fact more is required to achieve interoperability than just supporting
the default set of standards. Authorization for users from different
providers to call each other is one prerequisite. Therefore, the requirement
of interoperability for real-time text must be included in the emerging
trend to interconnect VoIP and IP Multimedia services from different
providers. Interoperability by interconnecting at the PSTN level may be
done, but causes too much functionality loss for real-time text, while it is
a useful option for plain voice calls.
Takeup in mainstream deployment
With the 3G consortium 3GPP taking up real-time text as one medium with
equal rights in the definition of IMS Multimedia Telephony, real-time text
has got a very good acknowledgement in mainstream industry and has a chance
to move on to good success, making telecoms accessible for all. IMS
Multimedia Telephony makes use of SIP with RFC 4103 for real-time text, so
it matches the current default set of standards.
Real-time text in other environments
Real-time text is defined also for other telecomms environments than IP. A
good overview of available solutions is given in ETSI EG 202 320 Duplex
Universal Speech and Text.
It also gives backgrounds, user requirements and indications on arranging
gateways between different environments where real-time text is defined.
Real-time text and VoIP gateways
VoIP gateways are implemented in order to provide interoperability between
PSTN voice phones and VoIP. There are descrioptions on how interoperability
between PSTN Textphones can be achieved through gateways, (including TTY.s
in the US and the other types in other countries).
Most gateway descriptions describe interoperability between PSTN textphones
and SIP calls with text in RFC 4013 format. One gateway standard however,
ITU-T V.151 is mainly intended for trunking textphone calls between PSTN
textphones through IP, and describes as Annex E, another packetisation than
RFC 4103 to transport text optimised for the trunking situation. There is
also an annex describing communication between gateways and IP terminals
requiring the terminals to use Annex E packetisation of text for this
purpose and RFC 4103 for general terminal-to-terminal use. Annex E
packetisation is compatible with RFC 4351 "RTP Payload for text conversation
interleaved with the audio stream". This is the background for why sometimes
both RFC 4103 and RFC 4351 are mentioned as needed in text capable IP
terminals. Work is going on in ITU-T to add another annex to V.151 to make
it possible to have terminals with only RFC 4103 implemented.
It is important for the interoperability goals that the service providers
declare if they will introduce real-time text support through any VoIp
gateways and if so by the current V.151 Recommendation or by any of the
other gateway standards allowing the terminals to use RFC 4103 for real-time
text transport in all cases.
Regards
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
= EMAIL ADDRESS REMOVED =
Tel: +46708204288
www.omnitor.se <http://www.omnitor.se/>