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: Gregg Vanderheiden
Date: Thu, Jun 07 2007 5:55 PM

Yep. But other security systems don't like finding text masquerading as
audio packet in and audio channel. So having the pair of them meets the
different criteria and needs in different systems.



Your thoughts on just requiring support for both?


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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Combs
(jcombs)
Sent: Thursday, June 07, 2007 6:06 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

One reason they went with RFC-4351 is that is much more likely to get
through a firewall than RFC-4103 (because of the separate text & audio
channels in 4103).






_____


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

RFC 4103 and RFC-4351 (the part of V.151 that is being referred to) are
very similar (almost identical except that 4103 ships text and audio data
on different channels where 4351 ships them on the same channel. They
both use T.140 for text encoding and RTP etc. ) Since they are so similar
it isnt that hard to support both if you support 4351 (which is arguably
slightly harder to implement than RFC-4103 since you have to sort out the
audio from the text packets in the audio channel) what about if we just
require the pair of them.



Then we have RFC-4103 for all IP to IP communication

and RFC-4351 for communication between VoIP devinces and PSTN gateways.



(RFC-4103 can communicate with PSTN gateways but would use up two ports
rather than 1)





If we require both 4103 adn 4351 then we provide both the clean 4103 and the
4351 which masquarades text in voice channels but is more efficient for PSTN
gateways where you mix the voice and text together anyway on the Analog
(PSTN) side.



Someday ? when there is no longer a PSTN and as PSTN slowly fades, we can
rely more and more on the 4103.





NOTE: this still allows closed systems like Skype, VoIP company systems,
Vonnage, Cable phone, etc to use whatever they want internally that is
reliable as long as they translate into the standard format when they
connect to other systems. They dont have to use them even then ? but have
to be able to be able to use them ? so that there is always something that
everyone supports so they can communicate/connect with text as they do with
voice.





Thoughts?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 4: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