Thread Subject: Re: Working our way to common ground.

From: Gunnar Hellström
Date: Fri, Jul 06 2007 12:55 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: None
• Previous message in thread: Gunnar Hellström: "Re: Working our way to common ground."
• Messages sorted by: Author | Thread | Date

My responses below, marked <GH> And red where there is a deviation or
addition.

Is it time to return to the Teitac statements now, and verify that they:

-Support the intended use of real-time text.

-Enforce the interoperability and functional goals.

-Are open for conscious change in the future and voluntary additions today.

-Can be fulfilled by utilizing current standards so that the industry can
accept that the solutions are implementable.

I think that the current statements are close to fullfilling these
requirements.

For best results similar actions with similar conclusions are needed in the
relay service industry, in the emergency services and in other parts of the
world. The process is going on in the right direction.

Europe has had an intensive period of discussions on the same topic that
resulted in recommendations to move on to field trials and interoperability
management.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
= EMAIL ADDRESS REMOVED =
Tel: +46708204288
www.omnitor.se <http://www.omnitor.se/>



_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, July 02, 2007 7:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: [teitac-telecom] Working our way to common ground.





Below is a list of statements that I think we should walk down to find out
where we are all together and where we have differences.



I think it will be much easier to find final wording if we can figure out
what our agreements and differences are -- and then work on ways to address
the differences.



I am seeing too many proposals that break something when trying to fix
something else -- or that seem to fix the wrong thing. We won't get far
that way.





I would suggest we just ask for objections to the following statements ? and
see how many we have consensus on ? then work on the rest.



This will also help remind those less familiar with all of the aspects we
are covering.





I suspect we can go through the first items pretty quickly and will find our
differences down lower.




GROUP 1 Statements




1. People who are DEAF OR HARD OF HEARING

* should have reliable text conversation wherever people who speak and
hear have reliable voice conversation, either directly or via AT.

<GH>Yes, and important to remember that it is for the following purposes:
-Calls with each other globally.
-Calls with other people having real-time text capable terminals. The more,
the better fulfillment of the "comparable access" requirement.
-Calls with other people through relay services
-Calls with emergency services
-Calls with text capable IVR and text capable "voice"-mail
-Calls in fixed, wireless and mobile networks in offices, homes and other
areas.





2. People who are DEAF AND CAN SPEAK


* should be able to use speech to send and text to receive
communication (either simultanously or alternately), either directly or via
AT.

<GH>Yes



3. People who are HARD OF HEARING


* should be able to use speech to send and speech and text together to
receive communication (either simultanously or alternately), either directly
or via AT.

<GH>Yes, and each call can turn out to have different amount of typing
needed. Sometimes hearing is sufficient, sometimes not.

4. People who CAN HEAR BUT CANNOT SPEAK OR SPEAK CLEARLY


* should be able to to use speech to receive and speech and text
together to send communication (either simultanously or alternately), either
directly or via AT.

<GH>Yes.



<GH> 4X.People who ARE DEAF_BLIND and prefer to use sign language

* <GH> should be able to to use text to receive and sign language
or text to send communication (either simultanously or alternately), either
directly or via AT.





5. People WITH DISABILITIES


* should not have to pay more to make phone calls than people without
disabilities. (Cost of AT hardware not included.)

<GH> Yes


GROUP 2 Statements




6. TTY (Baudot/TIA-825) is the only current method supported
universally in the US for text conversation on the PSTN

<GH>Yes

7. In the evolving PUBLIC IP phone system ? we want to use Text Data
not TTY (or other ) audio tones to convey text.

<GH>Yes

8. IM is a valuable means of communication for everyone but particulaly
for people who are deaf.

<GH>Yes

9. IM is not real-time text. It is often near-realtime messaging.
But it is messaging. And it can be delayed in addition to normal messaging
delay (until ?enter?).

<GH>Yes, and it is run by operators who currently show little interest in
global interoperability between operators, that is another reason why it
currently no real contender to be a complete alternative.



10. Real-time conversation and IM are both valuable (to all
communicators) but fill different needs.

<GH>Yes

* IM is sometimes superior to real-time conversation.

<GH>Yes, e.g. when you do not want to disturb. The culture to answer
immediately is less developed with IM than with real-time conversational
services.

* Other times real-time conversation is superior.

<GH>Yes, e.g. for intensive discussions and when timing is critical. and
when you want a good sense of contact with low risk of confusion.

* IM is also used in place of real-time conversation when real-time
conversation is not possible for some reason.

<GH>Yes, availability is an important factor that can cause acceptance of
alternate solutions.

*

<GH> Real-time text is also used in place of IM when IM is not
possible for some reason.

<GH>Yes, to some degree you tend to use what is available.






GROUP 3 Statements




11. Real-time text communication should be as reliable as real-time
voice communication

<GH>Yes

12. Real-time text portion of a call should be as interoperable as
real-time voice portion.

<GH>Yes

13. There is no (interoperability) need to specify which real-time Text
Transport format is used WITHIN a SELF CONTAINED SYSTEM as long as the
format is reliable and supported by all components in the system.

<GH>True if you mean specify in Section 508. But open specification of the
protocols even within closed entities must be strongly encouraged. Othewise
there is an apparent risk that the entity will not have resources enough to
create all variants that are needed because of the accessibility and
assistive technology needs, like text capable IVR systems, big button text
capable phones, multi-party-systems etc. Use common standards whereever
possible!

* ?Self-contained system? is a system where all of the terminals,
routers and servers are manufactured by or controlled by a single entity.

<GH>Yes, and this makes even large entities like the operators and
manufacturers using 3GPP specifications to be one such entity and making
self-contained systems.

* A ?Self-contained system? can include an Internet leg if both ends
terminate inside the ?Self contained system?.

<GH>Yes

* Where the self contained system connects to other systems ? (see
below)

<GH>Yes

14. For two systems to interoperate (with real-time text) they must both
support some protocol between them.

<GH>Yes

15. For a system to interoperate with an UNKNOWN system ? it must
support AT LEAST ONE format that is known to be SUPPORTED BY ALL OTHER
SYSTEMS.

<GH>Yes.

16. RFC-4103 is the most commonly supported real-time text format for
SIP based IP Phone terminals connected directly to Foreign SIP Servers.
<GH>Yes


* Foreign SIP server is a server that is not owned by the same entity
that owns the terminal phone.



17. RFC-4103 and RFC-4351 are essentially identical except that

* RFC-4103 (also called text/t140) sends text data packets on ?text?
channel that is separate from the audio data channel
<GH>Yes. It is announced as text/t140 in the SIP setup.

* RFC-4351 (also called audio/t140c) sends text data packets on the
?audio? channel along with the audio packets. (But the text data is still
sent as T140 data, not as audio tones.)
<GH>Yes. It is announced as audio/t140c in the SIP setup. The specification
says it is limited to gateway applications and intdicate that RFC 4103 is
for the general IP to IP case.

i. The
use of a single channel is of benefit to PSTN gateways because it halves the
number of ?ports? that must be created to handle a call and the voice and
text are mixed on the PSTN side anyway

<GH>Well, it introduces a bit of complexity as well for
the multiplexing of the two kind of "audio" packets, but in some cases the
port-saving seems to be important.

ii. With
RFC-4351 it is not possible to have simultaneous voice and text in one
direction (which is required for IP Captioned Telephone) without
creating/having an additional SSRC in the terminal device to keep the two
data streams separate.
<GH>Yes, and using multiple SSRCs in one media stream is beyond what most
RTP implementations can handle today. But this is not needed for the
intended PSTN text telephone gatewaying application.

iii. RFC-4351
is one of the multiple options that can be used in meeting TIA-1001

<GH>Yes

* RFC-4351 has Intellectual Property claims against it from Cisco.
RFC-4103 also has soft Cisco claims but RFC-4013 is a minor update of
RFC-2793 which had no claims and RFC-4103 can be implemented without
involving Cisco Intellectual Property.

<GH>Yes, but the IPR statements are
relatively mild and allow use on fair terms. Many audio codecs have much
stronger IPR that require
licencing.



18. VoIP Phones (terminals) (hardware and software) that have multiline
displays ALREADY should display realtime text data that they receive.
<GH>Yes


* Does NOT require that display be added
<GH>Yes

* Does NOT require that whole display be used

<GH>Yes

19. VoIP Phones (terminals) (hardware and software) that have text input
capability ALREADY should should allow realtime text data to be transmitted.

<GH>Yes. And text input capabilities should be encouraged strongly. Phone
directory maintenance is hopeless on a 12-key phone, so in today-s world,
all phones should have an alphanumeric keyboard. Real-time text use is of
common interest with directory use, with phone configuration use, and with
emerging IM use.


* Does NOT require that a keyboard be added
<GH>Yes

* Does NOT require any text input capability that is not already
possible with the terminal

<GH>Yes

20. Where phones do not provide built in real-time text conversation
capabilities, there should be a way to connect a device that does


* Either through the phone or in parallel
<GH>Yes, and there should be a common interest with the applications under
19. above.

* That has the same privileges as the phone
<GH>Yes, but there are many obstacles in compatibility, security and
configuration convenience here.

* IF the phone is a public/shared phone ? then connecting the text
capable phone should not require an administrator.

<GH>Yes,






















Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>







__________ NOD32 2368 (20070701) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

• Next message in Thread: None
• Previous message in Thread: Gunnar Hellström: "Re: Working our way to common ground."