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: Paul E. Jones
Date: Sat, Jun 09 2007 3:35 PM

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that?s not what I would want to use!



I think we need to ?be careful what we ask for?, otherwise what we might
have is a large number of inferior devices and then people asking, ?what
more do you want??? There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is ?network
access?, not ?phone access?. If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
?natural extension? of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It?s not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it?s not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





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



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and and
RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS ? OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give preference to
RFC-4351 (offer it first) so that they can save a port for each call. (if
everyone supports both as they should ? then RFC-4351 would work first time.


3) On non public systems (Skype, Vonnage, Corporations Internal systems,
etc) any text transport that meets the requirements is allowed as long as it
is translated into TTY at any PSTN interface and into RFC04103 and 4351 at
any external IP SIP interface.





Would this hit the major issues?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Friday, June 08, 2007 2:10 PM
To: 'TEITAC Telecommunications Subcommittee'
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