Thread Subject: Re: teitac-telecom, PSTN Reference

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: Gregg Vanderheiden
Date: Sun, Apr 01 2007 3:50 PM

Hi Jim,



Oh, the point wasn't that one of the three categories wasn't covered by the
definition of E&IT. All three would be covered as you suggest.



The point was that there should be different requirements for the three
categories. (public analog PSTN, public packet/IP/SIP and other, closed
systems)



You have to have interoperability in telecom or you can't have guaranteed
calls. You can't guarantee that the two ends can connect.



o For Voice on IP there is G.711. All systems support it or convert
to it (which is the same as supporting it). they may support many other
format but they will support G.711 when they hit any external systems.



o There needs to be a similar requirement for text for example. But
it needs to be different in different systems.



In analog (PSTN) it needs to be TIA 825 Baudot (TTY). That is the only
standard for text that we have in analog telephone system.



In IP/SIP systems, the industry standard is T140 communicated by RFC 4103
or Text/t140.



There are other formats like (RFC 4351) audio/t140 (note that this is not
audio transmission but text transmitted as T/140 data just like text/t140
except that you mislabel the text data packets as audio data packets and
sort it out at the far end.) This is done to avoid using extra ports. It
works well when linking to PSTN. But again, if you send in RFC 4351 and the
other phone supports only RFC 4103 then the voice will work but not the
text. RFC 4351 is listed as an historical format and many oppose its use
in public systems because it involves mislabeling data so it can masquerade
as audio. It was originally designed for use in closed network IP links
within the PSTN system (which according to the recommendations below -
should be able to use what ever they want. Since they control both ends .

.

** You either have to require that all telecom support one format - or you
have to require that they all support them all.



There is no other way to guarantee that calls go through except if you put
all calls through gateways that support ALL formats. We talked to industry
about this and they said it was too much overhead to run all calls through
these and asked who would pay for them all. (we have proposed such a
method (called T-hybrid servers) for PSTN to IP network gateways.)



The third category is "all things that are part of a closed system". This
can be PBXs or whole government systems. As long as they all provide
quality accurate reliable methods to transport text they do not have to use
the PSTN or the IP/SIP standards internally. They would only need to
convert to one of the standards when they interfaced with the PSTN or public
IP/SIP networks.



Again - there is no problem offering other formats on the PSTN or public
IP/SIP networks. Turbo-code has been available for a long time on PSTN. If
the receiver can handle the format it is fine to use. But like all
Turbo-code TTYs (that also supports TIA 825 Baudot to fall back on it
Turbo-code isn't supported by the other TTY), everything has to support one
standard required format so they can communicate if they don't both support
some other format(s).





In summary,



1) we need to specify a single standard format for the PSTN and IP/SIP
public networks that everything must support. (We could require more than
one but that is requiring more than is needed).

- if there isn't one that everyone supports then there can
be no interoperability or guaranteed connections.

a) TIA 825 Baudot for analog phones

b) ITU T.140 and RFC 4103



2) we should have performance requirements for closed systems but we should
not require that they use any particular format internally. Requirements
would be something like.

a) It support the character set needed to express the languages
involved

b) That they transmit the text with less than 1% character error.

c) That they support mixing of text and audio

d) If packet based, that they support text and voice simultaneously in
both directions (4 channels).

e) Terminal technologies (analog or digital) need to either provide
built in text send and receive/display abilities or they need to provide a
means to connect an appropriate device that will allow this. (Connection can
be in parallel with terminal device). (NOTE: if closed systems us
proprietary transport methods and don't provide built in send &
receive/display then this needs to be handled carefully. )











Gregg

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

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of

> Jim Tobias

> Sent: Saturday, March 31, 2007 8:19 PM

> To: 'TEITAC Telecommunications Subcommittee'

> Subject: Re: [teitac-telecom] teitac-telecom, PSTN Reference

>

> I don't get your point. Anything the feds use for voice

> communication, be it internal, external, private, public,

> gateway, intercom, wireless, CB, ... anything -- it's all

> E&IT, and thus covered. If a vendor uses a proprietary system

> from top to bottom, but it meets the accessibility

> requirements on its own and interoperates (looking only at

> accessibility) with all other systems that the procuring

> agency finds necessary, it's compliant. Am I missing

> something? As much as we may want the telecom industry to

> adhere to some non-proprietary standard, I don't think we can

> use 508 to make that happen.

>

> ***

> Jim Tobias

> Inclusive Technologies

> +1.732.441.0831 v/tty

> +1.908.907.2387 mobile

> skype jimtobias

>

>

> > -----Original Message-----

> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]

> > Sent: Saturday, March 31, 2007 7:07 PM

> > To: 'TEITAC Telecommunications Subcommittee'

> > Subject: Re: [teitac-telecom] teitac-telecom, PSTN Reference

> >

> > Hi Tom

> >

> > Remember that there were three types of systems proposed.

> >

> > The Public Analog, the Public IP and all other closed systems.

> >

> > All of the government phones connect to the PSTN or emerging IP/SIP

> > systems.

> > If they didn't you couldn't make a call.

> >

> > Most of the government phones are part of a system though and only

> > connect

> > to the PSTN through gateways or call managers. Making a

> > call from one

> > phone to another inside an agency may not ever touch the PSTN. It

> > would

> > simply be phone to phone. Some of those phones use

> > different standards and

> > some use proprietary methods to communicate between phone

> and between

> > the phone and the call manager/server/gateway to the PSTN.

> >

> > The problem then breaks down into three parts.

> >

> >

> > 1) can the person with a disability use the terminal device

> > (phone) and/or can they connect any AT they need to it.

> >

> > 2) can the connection between the terminal device (phone) and the

> > public network (or between two phones not on the public

> > network) carry the voice and text and possibly video reliably and

> > accurately.

> >

> > 3) when the call hits the public phone system, is it (the

> voice, text

> > and possibly video) in the right format to travel reliably on the

> > network and to work with the devices (standard phones or AT) at the

> > other end.

> >

> > What will work on the PSTN is different from what will work on the

> > IP/SIP network. And, if the two ends done use the same protocol or

> > support at least one common 'universal'

> > format for voice/text/video then the call

> > cannot be completed. Hence the need for established

> > standards for both the

> > PSTN and the IP/SIP networks.

> >

> >

> >

> > Does this help?

> >

> >

> > Gregg

> > -- ------------------------------

> > Gregg C Vanderheiden Ph.D.

> >

> >

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