Thread Subject: Re: Proposed new Provisions toreplaceTTY provisions

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: Tom Brett
Date: Fri, Apr 13 2007 8:15 AM

I think it would be better if we did not state specific ports or products.
There are other ports that are available that allow video communications.
Stating specific products would tend to show favoritism by the Feds towards
a specific product and by stating the port would tend to limit future
development.





Tom Brett



_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Karen Peltz
Strauss
Sent: Friday, April 13, 2007 10:43 AM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] Proposed new Provisions toreplaceTTY
provisions



Norman Williams of Gallaudet Universtiy also suggested that the following
concepts be incorporated in the final guidelines on this issue. I am not
sure all of these belong in the Access guidelines, or some should ultimately
go into the more specific procurement standards, but I did want to pass
these along from him:



The goal is to make it same access as voice calls enjoyed by hearing
employees:



1. Make and receive video calls from/to anyone
with similar device (H.323 protocol) and video relay services.

2. At least 256kbps upload and download needs to
be provided for satisfactory video performance.

3. Sharing public IP address with other devices
or machines is prohibited. The videophone needs have its own public IP
address either at the device or the NAT 1 to 1 (a technical term for public
to private translation table) routing device. This is needed for receiving
video calls.

4. The public IP address needs to be static. Or
the device must be allowed to reach to external servers directly to update
the directory (i.e. Sorenson server that tracks IP address for phone number
lookups).

5. If using Federal network, the ports must be
opened for Sorenson VP 100/200 and DLink I2Eye:

6. TCP 1720

7. TCP/UDP 15328 to 15348

8. TCP 80 (only if public IP address is dynamic - See #4 above)

9. If the IT determines they cannot provide
this internet connection for VP, alternative network must be provided (i.e.
DSL line). Agency needs to pay for it, not departments. (I know some agency
asks departments to pay).

10. Karen





----- Original Message -----

From: Gregg Vanderheiden <mailto: = EMAIL ADDRESS REMOVED = >

To: 'TEITAC Telecommunications Subcommittee'
<mailto: = EMAIL ADDRESS REMOVED = >

Sent: Friday, April 13, 2007 7:26 AM

Subject: Re: [teitac-telecom] Proposed new Provisions to replaceTTY
provisions



Hi Tom,



Yep. Good. That would restrict it to accessibility which is all this is
about.



I think you may want to put the clause at the end of the sentence though so
it reads.



Telecommunication systems with the bandwidth and video capability to support
sign language shall not block video telecommunication for the Deaf and Hard
of Hearing Federal Employee or member of the public.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
Sent: Friday, April 13, 2007 5:31 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Proposed new Provisions to replace TTY
provisions

>5) Telecommunication systems with the bandwidth and video capability to
support sign language video shall not block video telecommunication.



>> -#5 basically says that if the system technically CAN be used
for sign language that users should be able to use it for such.



The projects that I have worked on in the past 2 years with the Federal
Government have shown reluctance on the part of the Network Management Staff
to support video telecommunication. The primary reason for this reluctance
is that opening a port in the agency's firewall would subject the network to
hacking or malicious snooping. This will be a major impediment towards the
implementation of this item. To provide video telecommunication to the
Deaf/Hard of Hearing required that the agency lease separate DSL lines
($200/month) as a work around.



Bandwidth.many agencies will focus on the assumption that video
telecommunication would be required for every employee.



I would propose



Telecommunication systems with the bandwidth and video capability to support
sign language video for the Deaf and Hard of Hearing Federal Employee or
member of the public shall not block video telecommunication.





Tom Brett




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Thursday, April 12, 2007 5:31 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: [teitac-telecom] Proposed new Provisions to replace TTY provisions



Hi all,





Per assignment on last weeks call Jim and I talked about the real-time text
parts. Here are the notes I prepared for our discussion - with edits
based on our discussion.



The suggested provisions below would replace the TTY provisions in the
current 508 and 255.



These are not believed to be final - but are pretty far along the line in
moving from TTY only to provisions that work for TTY on analog and non-TTY
on other platforms.



Take a look for Friday call to replace TTY centric language.



Gregg









General Introductory Notes



Mainstream telephony has always supported one standard form for fallback.
It allows innovation and many different formats to be used, but to insure
interoperability they have always had one format that everyone supports.
Otherwise there is no guarantee that a call will be able to be completed.
Devices at both ends must support at least one format in common. If not
they cannot communicate.



In talking with mainstream industry, for voice they all support G.711 for
expressly this purpose.



For text there needs to similarly be a standard fallback format that
everyone can rely on. This does not in any way inhibit the development and
use of new and additional or even better text techniques in the future. But
it does ensure that the text portion of a call can go through. Between
products today and between today's and tomorrows products.



In the PSTN in the USA TIA 825 Baudot was used for this. Even when Turbo
code was used extensively, all Turbo code devices also supported TIA 825
Baudot to ensure interoperability



Since we have already seen that different industries prefer to support
different text formats (which would result in the voice channel connecting
but not the text when these different products are used together) I don't
see how we can do anything other than specify one format that must be
supported. It does not have to be the format used if the devices have
another format in common. But there needs to be some one format that all
support.



The format that industry has developed for this is on SIP is RFC-4103.
(RFC-4103 uses T.140)







My thoughts about the provisions in 508/255 are





- we have a general provision that states the overall goal. It has
subprovisions for PSTN and IP-SIP but that we do NOT provide and technology
specifics for private, proprietary systems or other peer-to-peer systems
that provide their own standard internal format.







Something like the following provisions



==================

PROPOSED ALTERNATIVE PROVISIONS TO THE TTY PROVISIONS TO MOVE TO FUTURE AND
OPEN FOR OTHER TECHNOLOGIES

==================



1) [Telecommunication?] products that pass real-time voice conversation
signals shall also pass real-time text conversation signals (including mixed
voice and real-time text) that are standard for that medium without
distortion or error beyond 1%.



- #1 just deals with things that pass voice not with phones or
other terminal devices.



2) [Telecommunication?] products or systems that provide real-time
conversation text functionality shall do so in the format that is supported
for that transport medium.

a) products that connect directly to the PSTN shall support TIA
825 Baudot.

b) products that connect directly to the Internet via SIP shall
support RFC 4103

c) products that connect to any other system (including
connecting to the Internet in a non SIP peer-to-peer fashion) shall support
the standard real-time-text format for that system. They only need to
support TIA 825 Baudot at the juncture to the PSTN (if any) and only need to
support RFC 4103 at the point where they connect to public SIP Systems (if
any).



- #2 allows Skype PBXs, and any other closed systems to use
whatever they want to for internal text transport and for transport between
their own systems. If the connect to public systems (PSTN or Public SIP)
then they need to convert to the public formats at that point only. They
are still free to USE other formats but they must support the public formats
to guarantee that they can interface with other companies equipment at the
far end of the public network call.



3) [Telecommunication?] systems that support voice conversation shall
provide at least one standard means for real-time text conversation that is
supported by all products on that system and that meets the following
requirements.

a) it provides transmission of character with less than 1 second
delay from entry

b) it provides transmission with less than 1% error under heavy
normal network traffic

c) it allows intermixing of speech and text in both directions
(simultaneously if packet based).



- #3 provides the specifications for text transport. Although
closed systems can use any technology to transport text, it must meet these
reliability specifications. TTY and RFC 4103 can already meet these
specifications.





4) IP Telecommunications terminal devices that provide a function allowing
real-time voice conversation communication shall meet the following
provision:

a) Products that have a display of more than 12 characters shall
display any real-time-text that is received in standard format.

b) Products that have the ability to generate text shall allow
sending of real-time-text in the standard format in connection with voice
phone calls.

c) Products that do not have both send and receive capability
for real-time-text shall support the connection of real-time-text devices in
parallel with the voice call capability in the same location and with the
same permissions for use as the product.



- #4 This provision basically says that if the device can
display text then it should display real-time-text that is sent to it. If
it can generate text it should allow users to send real-time-text. If it
can't do both then there should be some method for connecting a device that
can - and that device should be allowed to work (permission).



5) Telecommunication systems with the bandwidth and video capability to
support sign language video shall not block video telecommunication.



-#5 basically says that if the system technically CAN be used
for sign language that users should be able to use it for such.



{do we need something for voice-mail and IVR or do we make these work for
those too.}.





4c would be equivalent to what is available today with TTY - but would open
it up for other technologies on other systems.



Video is handled separately. It has extra bandwidth and hardware
requirements so I think it should be treated separately and simply as shown.






Thanks




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.


_____

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