Thread Subject: Re: (Postpone the) Real-time text discussion

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.

From: Peter Korn
Date: Mon, Aug 13 2007 7:15 PM

Hi Gunnar,

I appreciate that real-time-text has been examined and worked on in the
telecommunications space for some time, and that in RFC 4103 and RFC
4351 we have specific IETF proposals that have had significant technical
review by telecommunications folks.

However, the real-time-text provisions are brand new to me and I suspect
most of the rest of the desktop computer community, as of the 30May07
TEITAC draft of the technical provisions. That means that we desktop
folks have had just a little over 2 months to think about what is being
sought here, and we haven't had the benefit of the user requirements
gathering and study that folks involved in the RERC that Gregg noted on
the call have had.

Below you note that the first versions of ICQ provide real-time-text, as
well as an old UNIX application (the original was 'talk', a friend of
mine at UC Berkeley wrote the multi-user variant 'phone' that I made
much use of while I was a student at Berkeley in the 1980s). Certainly
neither 'talk' nor 'phone' used RFC 4103/4351, nor ICQ. (by the way,
there is a pretty good wikipedia entry on 'talk' at
http://en.wikipedia.org/wiki/Talk_(Unix) ).

Fundamentally I see a lot of technical interoperability issues to work
through to ensure that we provide what the user communities are seeking
- which I believe is generation real-time-text functionality that can be
used to connection to people wherever they happen to be (on a phone with
a display, on a Skype connection, an iChat, IRC, what-have-you). The
combination of what I think are the larger user desires, coupled with a
number of desktop-to-telephony interoperability questions, on top of the
fact that this is all still terribly new to the desktop world, form me
form a strong argument that we think this stuff through before choosing
a specific technology winner and mandating that - even if just for "PSTN
interoperability".

For emergency calls/relay services/etc., we certainly need some standard
that we know will be used by those services (and perhaps it is RFC
4103/4351; I don't know yet). But I continue to see no significant
value in requiring that every voice/video/chat software application (and
every gateway) itself implement that standard - rather than simply
delegating to resident a real-time-text application that does handle
that communication (and which does handle the interoperability).

Let me try to spell this all out with a couple of examples.

We have two users, Alice and Bob, who are both using desktop computers
to carry on a Skype conversation. This conversation is going over the
Skype proprietary protocol - a peer-to-peer network of other on-line
Skype connections that route the data between Alice and Bob without the
use of a central server. Alice now wants to have a real-time-text chat
with Bob, as she is having some trouble understanding him (RTT to
augment the audio). She selects the menu item "Initiate Real-Time-Text"
from the "Conversation" menu of the Skype window, and Skype gets Bob's
Real-Time-Text system address and invokes the Real-Time-Text application
on Alice's computer. That application in turn connects to Bob's
computer (via the supplied address), and Bob gets a message saying
"Alice wants to have a real-time-text conversation with you, do you
accept?". Once Bob accepts, a new window pops up and Alice and Bob are
having a real-time-text conversation, in parallel with their Skype
conversation. The two real-time-text applications Alice and Bob are
using aren't going over the Skype peer-to-peer network. Rather it is a
direct connection between the two computers via TCP/IP (though it could
certainly be RFC 4103/4351 instead).

Alternately, we have Alice and a new person, Carol. Carol doesn't use
Skype. She doesn't even have a desktop computer. She does have a
feature-phone at work with a text display. As Alice has Carols
real-time-text address in her desktop address book, she finds it, clicks
on it, and the address book application automatically invokes her
real-time-text application with that address. Carol only has a TTY at
home; her real-time-text address is on a gateway that translates between
the real-time-text protocol and BAUDOT. After Alice invoked the
real-time-text application with Carol's address, her application reached
the gateway, which in turn called Carol's phone and initiated a BAUDOT
connection.



For both of these examples to work, we did not need to require that the
Skype protocol implement support for RFC 4103/4351 or anything else.
Nor did we need to implement a whole new user interface for
real-time-text conversation in Skype. Nor in iChat. Nor in MSN
Messenger. Nor in any of the IRC clients. Nor in any of the expanding
plethora of other voice and video and text chat applications that
exist. As those application support the real-time-text helper
application interoperability, we get (what I think will be) a clean user
interface from those applications to real-time-text. At the same time,
with the promulgation of one or several free real-time-text applications
(like the one I understand TRACE is developing/has developed), users can
move forward without needing to wait for direct real-time-text helper
application integration, albeit with a less integrated user experience
(in other words, users can use something sooner, in advance of full
compliance with such a standard).


If this approach is acceptable, then we should make it clear in the
real-time-text draft language that it is. Right now that is not the
case for me.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Peter,
>
> I think usable applications can be created based on your helper-application
> model, but I do not see any problems with the currently defined ways to do
> real-time text that would make it worth while abstaining from continuing on
> the current track and complementing with new ways as needs arise. The
> currently defined methods are agreed among major telecom and IT providers
> and are easily integrated with their environments.
>
>
> Answers on some issues raised during the call today.
>
> 1. Is there any real-time text application on desk-tops.
> Certainly. Many users remember the first versions of ICQ, that had a nice
> real-time text mode.
> There is also an old unix-related application, I think it is called Phone.
> These both can only do text, but they meet many of the other requirements.
> Then there are some modern softphones implementing SIP and H.323 with
> real-time text.
> Today I also was shown a web-based video conference tool with built in
> real-time text.
>
> 2. Does the helper-application model fit the user requirements.
> There always a risk when you try to bolt on a solution to an existing system
> that the pieces do not work well together. The real-time text is such a
> minor addition to a communication system that it is likely easier to issue a
> new version of the application with real-time text included. But well
> integrated you can probably do
> But,
> How do you suggest to do emergency calls?
> How do you suggest to do relay service calls?
> Both these services require consistent and sustained plans. The ecrit group
> in IETF is currently defining a lot of details in future emergency calls.
> Regarding media, they acknowledge voice, real-time text and IM. For
> real-time text RFC 4103 is specified. New ways can be added, but this basic
> set will likely be the base for a long time. If you do not support SIP and
> RFC 4103 directly, you would probably like to do it through gateways in
> order to make emergency services accessible.
>
> For some IM protocols without delaying servers it might be suitable to just
> introduce timed transmission every second in their chat instead of
> user-initiated by Return.
>
>
> 3. Will it block progress if one standard is selected now?
> No, on the contrary, it is the agreement to use compatible protocols over
> large domains that creates usability and user value, so that there will be
> enough volume to base further developments on.
> This happens for voice calls, and it would be very beneficial if it was done
> also for calls containing real-time text.
>
>
>
> Gunnar
>
>
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> = EMAIL ADDRESS REMOVED =
> Tel: +46708204288
> www.omnitor.se
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: Monday, August 13, 2007 8:09 AM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Postpone the Real-time text discussion
>
> Hi Gregg,
>
> For #1 below ("A proposal from Peter on his alternate approach"), I don't
> have a "formal proposal" to hand.
>
> > In prep for the next discussion on Real-time text we were supposed to
> have > > 1) A proposal from Peter on his alternate approach > 2) A list
> of needs/requirements from consumers > 3) The combination proposals of D &
> E and also B& C if possible.
> >
> > #3 is completed and can be found from a link off of the EWG pages for
> this section at >
> http://teitac.org/wiki/EWG:_Draft_July_18:_Section_5_Comments
> >
> >
> > Gregg
>
> My thoughts on this come from the draft provisions requiring support for RTT
> (Real-Time-Text) everywhere that we current have audio communications on the
> desktop (which nearly by definition includes video), and everywhere where we
> have "chat" communications on the desktop. I do not come at this from a
> Telecom background, and have not thought through whether or how this would
> impact traditional telecommunications.
>
> The idea is that, from a user point of view, the desktop experience for RTT
> is very similar to the experience of following hyperlinks.
>
> Today on most graphical desktops, when a URL appears in your e-mail
> (Thunderbird, Evolution, Outlook, Eudora, etc.), it appears underlined and
> in blue, ready to be clicked on. Similarly when a URL appears in your
> office suite (MS-Office, StarOffice, OpenOffice.org), in your PDF viewer
> (Adobe Reader), etc. Whenever we see these "enabled hyperlinks", in a wide
> variety of different programs used for displaying text, we know we can click
> on them to invoke the hyperlink. And when we do, these various applications
> will all launch the "desktop web browser application" - typically Internet
> Explorer or Firefox. What these applications don't do is attempt to display
> the web page from within their own application (e.g. showing the web page
> there inside the OpenOffice.org window, or the Adobe Reader window) - they
> invoke the web browsing "helper application".
>
> In much the same way, I think we can address the requirement for RTT on the
> desktop. Rather than requiring that every audio/video/chat application
> itself implement a RTT option (and every audio/video/chat prototol support
> RTT directly, and every audio/video/chat server support RTT), instead these
> applications must simply invoke a desktop RTT "helper application" that
> handles the RTT communication, which could happen in parallel with the
> audio/video/chat conversation.
>
> If we address the RTT support in this fashion, it greatly reduces the
> expense on industry because it doesn't require that every audio/video/chat
> server support RTT directly. It doesn't require that the existing network
> protocols used for audio/video/chat be extended to support RTT (via RFC 4103
> or any other specific protocol mechanism). It does require a few, fairly
> small things:
> 1. that the desktop define a "RTT application" that handles RTT protocols,
> in the same way as the desktop defines what "the default web browser" is
> (and what application should be invoked to read .gif files, .jpg files,
> etc.).
> 2. that every audio/video/chat application that conforms to the draft
> refreshed 508 standard be able to invoke the desktop RTT application 3.
> that the vcard information for users of every audio/video/chat application
> include a field for the users' RTT address (and that we define such a
> standard addressing scheme)
>
> I've talked with the Sun engineers involved in the video and chat
> applications we include in Solaris (and that we get from the open source
> GNOME community), and they have confirmed my suspicion - implementation of
> what I am proposing is a small number of engineer-months; implementing RTT
> into the applications directly (and the protocols and the servers) is
> multiple years of effort.
>
> Another attraction from going the "helper application" route is that it
> doesn't constrain innovation in communication protocols and mechanisms.
> We are seeing a lot of innovation in computer-based communication mechanisms
> - things like Skype for the desktop that didn't exist just a few years ago
> (and in Skype's case, a technology that uses peer-to-peer networking in
> order to be network utilization efficient and avoid the need for a large
> server infrastructure). I am personally very reluctant to insist that all
> future communications protocols explicitly include an implementation of RFC
> 4103 or any specific protocol. But I am quite comfortable saying that we
> should have a RTT helper application that handles such things, and that our
> audio/video/chat software should know enough to invoke it when the users
> requests it.
>
>
> What this means in end-user terms is that when they are engaging in a
> non-RTT conversation with someone, and want to shift to or supplement with
> RTT, that they use some keyboard or mouse gesture (which may differ from one
> audio/video/chat application to another) to indicate that they want to have
> a RTT conversation with the person they are communication with, and their
> RTT application initiates a connection to the remote users' system, doing so
> in another widow with another application (and via a different network
> protocol). As the RTT conversation is with a different application in a
> different window, the user may need to arrange/re-arrange two different
> windows in order to have them not overlap on their screen [something that
> they might have had to do even if RTT was "integrated" into their
> audio/video/chat application, as multi-windows for this might be an
> implementation detail - certainly the draft provision makes no mention of
> this]. Also, as the RTT conversation is potentially using a different
> network protocol (and different servers, gateways, etc.), the performance
> characteristics may be different from the audio/video/chat conversation.
> E.g. a Skype user whose audio conversation is happening via a distributed
> peer-to-peer network might invoke a point-to-point RTT conversation (in
> which case, the RTT might in fact be faster!). Likewise an IRC chat
> conversation between two users in California might be going through a server
> in Sweden; the RTT conversation they invoke might again be point-to-point
> (or perhaps it goes through a different gateway in some other location than
> Sweden). This has implications on the relative performance guarantees one
> can make. Frankly because text consumes so much less bandwidth than audio
> or video, I believe in most cases an overall bandwidth deficit for RTT won't
> in practice be an issue. This is something we would need to model in
> practice, with prototype implementations in a variety of situations, to
> verify.
>
>
> In our con-call last week, if memory serves Gregg Vanderheiden suggested
> that the existing draft provisions would accommodate the "helper
> application" approach I have sketched out. Perhaps so, but I am not so
> certain of that. I find the language too ambiguous to feel comfortable
> telling my engineers that such an implementation would comply under the
> draft language. For example, if a user I am communicating with doesn't
> choose to have an RTT vcard field (e.g. they expressly decline to engage in
> RTT conversations), would the helper application implementation then fail to
> meet 508 (how can my implementation require an end user expose certain
> information)? Likewise, if the desktop selection of the RTT helper
> application were to get altered/corrupted, would that then make my chat
> application non-compliant? And, as I noted in my original concerns about
> the Section 5 draft language on RTT requirements, when the audio/video/chat
> software is part of a larger operating system release (which contains a RTT
> helper application), but I am having to provide a 508 assessment of *just*
> the audio/video/chat software alone, how can I state whether that software
> complies with the RTT provisions?
>
>
> What I would like to do is:
> 1. Verify that the implementation I have sketched out does or does not meet
> the desires of the community seeking RTT support 2. If this does meet those
> desires, review and update the language to make this unambiguously clear 3.
> If this does meet those desires, figure out how this impacts the more
> traditional (e.g. non-desktop) telecommunications world, especially when it
> comes to interoperability
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University