1 more; RE: Further numbers; Re: Document number requests

Paul E. Jones paulej at packetizer.com
Sat Aug 19 01:07:08 EDT 2006



I feel compelled to reply to just one point:


“If Paul wants audio/t140c so much


Personally, I do not care whether audio/t140c or text/t140 is adopted as the
industry standard.  It makes absolutely no difference to me, as I view both
as a viable means of delivering real-time text in a way that we can use it.


What has mattered to me is delivering real-time text capability at all,
which was incredibly hard in the face of constant customer requests for
instant messaging.  I’ve given both technical and business reasons why
text/t140 cannot be universally deployed today and the near future.  I’ve
given other business reasons why text/t140 is not favored presently (cost


Working within those constraints, I wrote the audio/t140c document.  I might
be blamed for creating something evil (and I have been accused of trying to
“screw over deaf people”), but the truth is that I tried to create something
that is a stepping stone that will allow us to deploy RTT universally and
will not exclude legacy TTY devices: the roadmap that I have proposed is
easier (and therefore more likely to succeed) than taking the bigger leap to
text/t140, in my opinion.  (Note: text/t140 is now 6 years old, so I do not
think my assessment is wrong.)


I’ve said before that I think text/t140 is where we want to be.  How do you
suggest we get there?


1) We can simply demanding text/t140 support on platforms.  Some platforms
cannot support it.  Some platforms could support it, but would require
coordination with other products that also need to implement it (e.g.,
softswitches, firewalls, NAT devices, and policy enforcement devices).  You
end up having an end-to-end tug of war between product teams who wait for
the others to take the first step.  Worse, you isolate anybody using a
technology that simply cannot do it.  (How long until the last MGCP or NCS
gateway is decommissioned?)


2) Shall we demand that service providers deploy special text gateway
devices and just use V.152 to those gateways?  (That pushes all of the cost
and burden onto the service provider, rather than GW vendors.  However, it
also presents special dialing requirements or line provisioning
requirements.  For reasons that would require another full page of text, I
will say this will not work unless we remove the requirement that users be
able to go anywhere with their TTY devices.)


3) Shall we just forget about TTY devices and move everybody to IP, letting
those with TTY devices just limp along until such time as they’re tired of
being isolated or things not working part of the time?


Other ideas?





From: Arnoud van Wijk [mailto:arnoud at annies.nl] 
Sent: Friday, August 18, 2006 6:02 AM
To: Rac at lists.wisc.edu
Subject: RE: [rac] Audio T.140 evaluation?


And that is so absolutely true.

Audio/t140c is a very dangerous genie that is almost out of the bottle now.

And once deployed outside its limited purpose, we will get a big mess with
fragmentation dangers.

You only have to look at what has happened to the different text telephone
protocols, or the different IM protocols. 

If it is up to me, I want audio/t140c erased from existence. It will be hard
enough to get text/t140 deployed.


Now as I always say, audio/t140c is ok in gateway-gateway connections. IP
terminals must never be mandated to support audio/t140c.

Audio/y140c could be added as a special PSTN functionality. But such IP
terminal MUST have text/t140.


What about gateways? They must support text/t140 and if they

You will get a number of scenarios all from IP side starting: (gateway
supports both text/t140 and audio/t140c)

1.	call has audio/t140c and text/t140 in the SDP, nice for the gateway,
it selects audio/t140c. No issue here.
2.	call has text/t140 in the SDP plus an indicator that text must be
used. No issues here.
3.	call has text/t140 in the SDP, there is no indicator if text must be
used. There are a few possibilities: 
a: set up text in a reinvite if a key or text telephony is detected.
b: set up text/t140 port anyway and close this port if no text input is
detected after 60 seconds, it can always then reinvite for text if any text
is detected later.


So, if Paul wants Audio/t140c so much. OK but only mandate gateways to
support both. Text/140 is the universal lina franca real-time text protocol
and will also be set for interconnectivity between any text to any text


With the coming of WiMax, rural areas will be able to get high speed
internet. Sprint is starting to roll out such network.

The range is 50 kilometers in rural areas and 2-3 kilometers in cities.

So this is quite promising. TTY users should be one of the first to switch

Perhaps that is the best way to investigate where the move to IP is

Perhaps we can mandate in the US that ToIP must be able to pass through any
operators network, and find a way to ensure we have ata boxes for TTY
connectivity. Such box can support audio/t140c and text/t140.


Just my 2 cents and a bit.


Arnoud A. T. van Wijk
AnnieS New Technology
 <http://www.AnnieS.nl> www.AnnieS.nl
Mobile textphone (SIP):  <mailto:arnoud at annies.nl> arnoud at annies.nl


From: Gunnar Hellstrom [mailto:gunnar.hellstrom at omnitor.se] 
Sent: donderdag 17 augustus 2006 21:34
To: Norman Williams; Rac at Lists.Wisc.Edu
Subject: RE: [rac] Audio T.140 evaluation?



I hope you will get a sample, and a gateway to use it with.


audio/t140c should have very good opportunities to work well, at least for
pure text and for alternating text and voice. And that is as far as it needs
to be used with the applications that are proposed.


As usual, there are many opportunities to do the application integration
with different ambition levels. If you find issues, they may have a source
in the surrounding software or environment but not in the standard itself. 


The issues are more on an IP service architecture plane. You simply should
not call other media "audio" just for sake of convenience even if it seems
to work. 


We got the RFC classified "historic", and we had to put in a lot of words
about how the use was restricted to gateway applications.


This is a copy of the words we got from the IETF area director Allison
Mankin explaining why it got deemed "historic" from the beginning:



Gunnar, Paul,

t140c was approved today, with the IESG finding it in perfect

shape. The only discussion was about the Historic designation. We

discussed the Last Call comments, the GEN-ART comment, and my rationale

(including the announcement text I wrote in the tracker and my report

on the Chairs' views).

First, congratulations to you both on the excellent quality of the

document as a document. It made it easy to work with.

The purpose of making it Historic is not to condemn trunking gateways,

it is to avoid setting precedent with a PS for calling text data an audio

type. This document does so due to implementation pressures of SDP in

these gateways. RFC 4103 has the example (text/t140) we want people

to follow.

The impact of going to Historic should not block the goals you and

Paul have described: the payload specification is in an RFC-to-be, the

media type being registered with no blockage from any media experts

(which it would have gotten with a different designation on the

document!). There is no internal text that says the RFC is Historic.

So the only meaning of this designation is for later, when someone

pops up with an audio major type with data that is not audio, the AVT

or other working group can press back for a very tight applicability

statement and cite precedent, or if there's no deployment, ask them to

go to a different design.

A few more bits inline.

I hope this is more understandable now. Let me underline again

the point about the problem of media type expert review if we

had not gone Historic. 

With my best regards,



I find it very hard to go against these words and strt to use it between
terminals. I find it easy and perfectly OK to use it between gateways. 

To use it between gateways and terminals is a grey area. The words in the
RFC does not totally forbid that application, even if it is clearly stated
that the intention is for trunking gateways. However accepting it between
gateways and terminals makes the idea of media declarations in SIP collapse
and the architecture of IP múltimedia to become a mess. I do not want to
contribute to that.

These issues will not be visible when you try it, but certainly something
we, as a global advisory group will need to consider. 



Gunnar Hellström, Omnitor
gunnar.hellstrom at omnitor.se
Mob: +46 708 204 288
Phone: +46 8 556 002 03

-----Original Message-----
From: Norman Williams [mailto:norman.williams at gallaudet.edu]
Sent: Thursday, August 17, 2006 8:19 PM
To: Rac at Lists.Wisc.Edu
Subject: [rac] Audio T.140 evaluation?



I forgot to bring this topic to the phone conference we had recently.


Is there a way for us to evaluate audio T.140 to see if there are issues? Do
we have a working audio T.140 solution?



You are currently subscribed to rac as: gunnar.hellstrom at omnitor.se. 
To unsubscribe click here: https://lists.wisc.edu/u?id)14436N&n=l=c&o455168 
or send a blank email to leave-3455168-2914436N at lists.wisc.edu 

You are currently subscribed to rac as: arnoud at annies.nl.
To unsubscribe click here: https://lists.wisc.edu/u?id)14433R&n=l=c&o456252
or send a blank email to leave-3456252-2914433R at lists.wisc.edu 

You are currently subscribed to rac as: paulej at packetizer.com.
To unsubscribe click here: https://lists.wisc.edu/u?id)14439J&n=l=c&o463578
or send a blank email to leave-3463578-2914439J at lists.wisc.edu 

You are currently subscribed to rac as: paulej at packetizer.com.
To unsubscribe click here: https://lists.wisc.edu/u?id)14439J&n=T&l=rac&o474178
or send a blank email to leave-3474178-2914439J at lists.wisc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20060819/2cc7b763/attachment-0001.htm>

More information about the sg16-avd mailing list