Arnoud, 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 factors). 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? Paul _____ From: Arnoud van Wijk [mailto:arnoud@annies.nl] Sent: Friday, August 18, 2006 6:02 AM To: Rac@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 want…audio/t140c. 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 networks. 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 then. Perhaps that is the best way to investigate where the move to IP is impossible. 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@annies.nl> arnoud@annies.nl _____ From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: donderdag 17 augustus 2006 21:34 To: Norman Williams; Rac@Lists.Wisc.Edu Subject: RE: [rac] Audio T.140 evaluation? Norman, 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, Allison --------------------------------------------------------------- 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 ---------------------------------------------------------------------------- - Gunnar Hellström, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Norman Williams [mailto:norman.williams@gallaudet.edu] Sent: Thursday, August 17, 2006 8:19 PM To: Rac@Lists.Wisc.Edu Subject: [rac] Audio T.140 evaluation? Hi, 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? Norman --- You are currently subscribed to rac as: gunnar.hellstrom@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@lists.wisc.edu --- You are currently subscribed to rac as: arnoud@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@lists.wisc.edu --- You are currently subscribed to rac as: paulej@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@lists.wisc.edu --- You are currently subscribed to rac as: paulej@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@lists.wisc.edu