Thread Subject: Re: RFC 4103 reference for real-time text.

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: Diane Golden
Date: Sun, Jun 10 2007 2:50 PM

VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.

Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.

Diane

Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.



Diane,



What is a ?VCO phone?? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we?ve
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they?ve repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber?s homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Pam Ransom
Sent: Friday, June 08, 2007 2:16 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Just a reminder ... There are approximately 25-27 states that continue to
administer TTY Distribution Programs, and thus there is a significant
embedded base of this older TTY technology. Pam Ransom

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

From: Paul E. Jones

To: 'TEITAC Telecommunications Subcommittee'

Sent: Friday, June 08, 2007 2:10 PM

Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We've got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they're not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider's ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it's really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift - figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP - PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP -
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA
calls a native IP terminal. Should the call be routed to a big VoIP gateway
where proper support would be found for conversion to an IP transport of
text that is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

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

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


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

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I'm very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs - What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

"in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices."

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

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



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:" Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field."

Other methods than forcing all ports to support TTY are required to
achieve TTY / IP text interoperability. It is very likely that we need to
agree on some way to route the calls that MAY contain TTY so that they pass
gateway ports with special capability of conversion between TTY and an IP
real-time text format. Such methods are discussed in standards groups, and
they should be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 "Sip Telephony devices" says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







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

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

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

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


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

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue,
but in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices. When developing TIA-1001, we were presented with a laundry
list of requirements that, unfortunately, RFC 4103 could not always satisfy
for gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I've pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we're still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it's a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if
there are H.248 media gateways, two media gateway controllers, and one or
more proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and
citing standards references is insufficient. The problem is a complicated
on a number of levels, which is why carriers seem to favor treating TTY as
voice. Placing a requirement on gateway equipment to relay modulated TTY
signals is an uphill battle, and one that simply cannot be met with many of
the tens of thousands of already-deployed gateway devices in the field.
When we can get a foot in the door, to then further complicate the problem
with multiple RTP streams, multiplexing issues, and higher per-port costs,
increased signaling overhead, etc., will likely mean we stick with G.711 for
legacy TTY support indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today's meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can
answer and hopefully resolve.



I will take them in portions.



Concern 1: "RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose."



Answer: IETF RFC 4103 "RTP Payload for text conversation" is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

"Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text."



2. >From ietf-draft-ecrit-requirements: "Requirements for Emergency
Context Resolution with Internet Technologies"

"Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video."



3. >From ITU-T V.151 "Procedures for the end-to-end connection of
analogue PSTN text telephones over an IP network utilizing text relay"

"In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters." ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

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

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com


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

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