Some additional accessibility comments on the CCXML WD

Hi All,

Here are some comments regarding the CCXML WD.  Almost all of them concern
the needs of deaf telecom users.  I apologize in advance for any questions
or comments I raise that are not technically sophisticated or fully aware of
CCXML's role, and for the lateness of these comments.

BACKGROUND
Many deaf people use text telephones (or "TTYs") that send and receive FSK
or other audible characters with no carrier.  Thus TTY calls are similar to
voice telephone calls: no special signalling, no handshaking.  However, many
TTY users have migrated to other mainstream text media such as email, chat,
IM, and SMS that are not similar to voice calls.  As TTYs will be with us
for a while longer, it is important to be able to communicate across these
incompatible media.

Furthermore, TTY users need to communicate with the majority of the
population that does not have TTYs.  This is accomplished by
telecommunications relay services ("TRS" or "relay").  The TTY user
communicates with a relay operator by text, and the relay operator
communicates with the other party by voice.  There are several "flavors" of
TRS: voice carryover (VCO), in which the TTY user speaks during his or her
turn in the conversation, and hearing carryover (HCO), used by non-deaf
non-speaking people who type during their turn (the relay operator speaks
the typed message) but listen to the reply of the speaking person.  There
are other services that are connected to TRS service provision.  (Privacy
and confidentiality of relay communications is an important goal, so
implementations of relay via CCXML would benefit from its ability to provide
audio path control.)

Finally, there is video relay service (VRS), in which the deaf person
communicates by sign language with a sign language interpreter.  The
interpreter speaks the signed message to the hearing person, and relays that
person's replies back in sign language.

SPECIFIC COMMENTS AND QUESTIONS

1. I did not see any reference to any calls other than voice.  Is CCXML
capable of managing video calls as "media streams"?  If not, is it conceived
that there is such a need, or that CCXML must interoperate with other
standards that do manage video calls?  This question relates to both
point-to-point and multipoint.

2. In 10.5.4.2 <createcall>, it is possible to indicate whether the audio
path is bi-directional or not via the 'joindirection' attribute.  However,
there does not seem to be any ability to change this attribute during the
call.  This may be a useful feature for some relay calls.

3. In 10.5.7.2 <join>, the same audio path attribute is called 'duplex' and
has different values.  Is this difference necessary?

4. Also in 10.5.7.2, there is an ability to control gain.  Gain and
frequency response are 2 problematic areas for hard of hearing users.  For
end-to-end VoIP calls, is it possible to request, as part of call setup,
that wideband audio be used?  Is this implemented in SIP?  (I realize that
<join> is not used for establshing point-to-point calls, but there was no
gain attribute in <createcall>.  In <createcall>, could this feature be
implemented in the 'aai' attribute?).

5. 10.5.10.1 <merge> offers another way to engineer relay calls so that the
operator (User A in the Figures) could be disconnected from the other
parties during the turns that those two are able to communicate directly
(VCO or HCO).  However, there is no <unmerge> that would restore the calls
as they were before <merge>, allowing the relay operator to translate when
the two parties could not communicate directly.

6. I assume that CCXML will accept external messages regarding calls.  For
example, if a deaf person is using IM to communicate with a relay service
instead of a TTY, a CCXML platform could accept a message that directs it to
create a TRS call with a certain telephone or SIP URI.  Is this correct?


Thanks for the opportunity to comment on the document.


***********
Jim Tobias
Inclusive Technologies
tobias@inclusive.com
+732.441.0831 v/tty
www.inclusive.com

Received on Monday, 14 February 2005 17:14:42 UTC