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: Paul E. Jones
Date: Mon, Aug 13 2007 4:30 PM

Peter,

You're entirely correct that implementing real-time text (RTT) in platforms
is one that will require multiple years in order to implement across the
board. RFC 4103 and RFC 4351, in and of themselves, is fairly simple.
However, adding tone detectors to DSPs to properly discriminate one
textphone modulation from another or from fax or modems requires time.
Further, adding proper support in all call control elements (phones, SBCs,
media gateways, media gateway controllers, PBXes, firewall devices, etc.)
takes a tremendous amount of time and coordination between various product
teams. It's certainly doable, but not something to chase without strong
commitment.

This is why I've asked several times before-- and I still do not have a
warm, fuzzy feeling-- whether users really want real-time text, how
important interfacing with the legacy PSTN devices is, etc. I have received
the following sets of answers:
1) RTT is important, yes TTYs are important
2) RTT is important, but TTYs are not
3) Neither RTT or TTYs are important, as folks are moving on to newer
technologies that are more ubiquitous

Personally, I'm very supportive to produce some kind of solution that meets
the needs of users. As one who has his own hearing problems, I tend to
think about these issues a lot and honestly prefer the IM-style of
communication better than RTT. (Admittedly, I've used RTT rarely, so
perhaps my bias is toward that with which I am most familiar. Even so, IM
is my personal preference.)

Having said that, I'd like to speak to your thinking about how this
functionality might be realized on the desktop. I've encouraged the group
from not taking a position with respect to particular technology for a
number of reasons, not the least of which is that technology is
ever-changing and perhaps more so now than ever in the telecommunications
space.

One of the projects in which I am engaged is called the "Advanced Multimedia
System" (AMS), which is a new system we are defining in ITU-T SG16 (the same
group that created H.323). I chair the H.323 standards group and I will be
chairing this new committee on AMS. At the moment, it is at the concept
stage, but perhaps this conceptual overview might be helpful:
http://www.packetizer.com/voip/ams/papers/

The idea is to separate the "call control" from the application
functionality. By doing this, we actually have the wherewithal to introduce
new applications (which might include a RTT application) by simply "plugging
it in" to the system. The same could be said of video streaming, voice,
whiteboarding, app sharing, or any other kind of real-time (or
quasi-real-time) application.

If AMS is realized (and it does have growing support), then it would be
possible for a person to walk to a phone and interface their RTT-capable
device (e.g., a Pocket PC or a mobile phone) with that phone to make RTT
available as an application.

So, this fits into the concept of what you're calling a "helper
application". What AMS proposes is that all applications are, in fact,
"helper applications", which enables anybody to create a new application and
make it available as part of the communication system.

Paul

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-telecom-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: Monday, August 13, 2007 2: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