RE: [Ecrit] ECRIT support for TTY/TDD calls
"Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se> Thu, 16 February 2006 16:19 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lqV-0007U9-2g; Thu, 16 Feb 2006 11:19:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lqU-0007U4-78 for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 11:19:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08881 for <ecrit@ietf.org>; Thu, 16 Feb 2006 11:17:17 -0500 (EST)
Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9m4i-0003mb-Uy for ecrit@ietf.org; Thu, 16 Feb 2006 11:33:50 -0500
Received: from MISAN ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 17:19:02 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
To: br@brianrosen.net, 'Francois Menard' <fmenard@xittelecom.com>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls
Date: Thu, 16 Feb 2006 17:19:01 +0100
Message-ID: <GLEFKJBKNILEBOELNIBIAEFIDEAA.gunnar.hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <07a801c63303$36c29c80$640fa8c0@cis.neustar.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 16 Feb 2006 16:19:02.0633 (UTC) FILETIME=[B3403590:01C63314]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08881
Cc: "'Aquil, Kamran'" <kamran.aquil@mitretek.org>, ecrit@ietf.org, 'Gregg Vanderheiden' <gv@trace.wisc.edu>
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
Brian, The ambitions for media and communication methods in PSAPs that you describe look good. Where are they discussed and agreed? I rechecked MSRP negotiation and see that it is a proper SDP media negotiation with m=message. As you know, real time text is a proper SDP media negotiation with m=text. That makes it easy to specify a recommendation on what media to set up. Some decision needs to be taken if both are declared. Preferences or application agreements could help with that decision. It is quite likely that it will confuse the user if both types of text communication are accepted and offered in different windows. I agree that if there are no specific emergency application aspects on that selection, it should be discussed in sipping and simple. I noticed I left one sentence unfinished in my last mail. Here it is finished: If the big VoIP gateway providers are willing to consider PSTN textphone gatewaying at all, they likely only accept to consider gatewaying to RTP for text. For small dedicated text gateways it is another situation, they can have a wider range of communication methods on the IP side. We have reached one important conclusion: It is best to not do any special addressing or routing for calls just because they include text capabilities. Let all PSAP terminals handle voice and real-time text ( and any messaging format that may be agreed ). If special handling of deaf users is felt to be needed in some country, let that be initiated by other indications. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellström, Omnitor gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se <http://www.omnitor.se> -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, February 16, 2006 3:14 PM To: 'Gunnar Hellstrom'; 'Francois Menard'; 'Henning Schulzrinne' Cc: ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls I'm thinking PSAPs will accept: SIP Session creation with audio, video and/or Interactive text Message transactions (IM with no session) MSRP Sessions (IM with session) There are some who want to accept XMPP as well as SIP IM. I don't think this is in ecrit scope until we get to the architecture, and then it couldn't mandate that, just suggest it's likely. Gunnar, if the current capabilities negotiation in SIP are insufficient, I think you have to raise them in sipping and not here. I don't think we have scope for any of that. It's conceivable, if we do the architecture work, that we will discuss gateways, but I'm not certain it will be necessary to. Brian -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: Thursday, February 16, 2006 7:45 AM To: Francois Menard; Henning Schulzrinne Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Francois, Yes, I saw that you had specified SIMPLE for real time text. Can you explain how you intended to signal the real-time characteristics of the session rather than the customary sentence-wise messaging that is usually assumed for SIMPLE? Sentence-wise transmission in emergency situations is risky. It creates loss of time, anxiousness etc. For loosely coupled messaging it is of course OK, but not for a tight conversation. The real-time text users do not accept more than a maximum of two seconds delay from typing a character until it is presented to the other user. And even that is regarded on the high side. One second is quite good. What we found when this was discussed in SIMPLE, was that the overhead even from transmission with one second intervals would become more than what is feasible to use for the real-time text medium. The big VoIP gateway providers Can you accept to change your spec to use real-time RTP text? So that we together try to get the world move in the same direction. Sorry, if this is a deviation from the original topic of Ecrit. But it definitely influences the opportunities to act on capability and preference negotiation if you need to look for various ways of indication that you want to use text in a call. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellström, Omnitor gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se <http://www.omnitor.se> -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Thursday, February 16, 2006 1:16 PM To: Henning Schulzrinne Cc: Gunnar Hellstrom; br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls If you look at my proposal, I was thinking of using SIMPLE for the real-time-text between the SIP client 'MSN Messenger' and the PSAP terminal 'MSN Messenger'. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 15 Feb 2006, Henning Schulzrinne wrote: > I don't think we want a service label for each media type. While *today* > there are PSAPs that only answer TTY calls, is this likely to make sense in > an all-IP PSAP environment where the media would terminate on the same PC > that's used for IM, video and so on? Why would you do this? > > Rather than trying to put SDP in a URN, maybe the better solution is to route > to one PSAP for the emergency service and have that PSAP then redirect the > call based on the full SDP information, if this becomes necessary. That way, > you can deal with situations where the caller can handle a variety of means > of communications, albeit with different ease, and the PSAP has access to the > full media information. > > Since this could be added on later if necessary, once we know whether anybody > actually needs this, maybe it's better to avoid gratuitous complexity, both > in terms of protocol operation, testing (yet another thing a mapping protocol > has to test) and user agents. > > Henning > > On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >> >> If it could lead to a text capable IP terminal, it should be called >> sos.police.real-time-text or so. >> >> If it helps to find a PSTN based PSAP with text capabilities, it could be >> called sos.police.txp >> >> tty is a US term. >> >> 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: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'François D. >> Ménard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> All I get out of this for ecrit is that we need entries for sos.police.tty >> in the service registry >> >> >> >> Brian >> >> >> >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; François D. Ménard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> >> It is quite widely accepted now that real-time text transmitted with its >> own text coded RTP payload RFC 4103 is used to carry text that may be >> gatewayed to/from TTY/TDD/textphones in PSTN. >> >> >> >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- >> sipping-toip-03.txt >> >> >> >> And it is documented in http://www.ietf.org/internet-drafts/draft- >> sinnreich-sipdev-req-08.txt >> >> >> >> Also other standardisation bodies have picked up the real-time text concept >> in IP networks, and pointed at RFC 4103 (or its compatible predecessor >> RFC2793 ). E.g. 3GPP and ETSI. >> >> A couple of years ago we had an intensive discussion in the SIMPLE mail >> list about the possibility to use MSRP to carry the real-time text medium, >> but we concluded that it would cause too much overhead or too much delay >> for the users, so that RTP was recommended instead. The most common use of >> MSRP is to not transmit until end of sentence, while for real time text, >> transmission is required with at most 500 ms interval as long as there is >> anything to transmit in order to maintain the real-time feeling of being in >> touch in a conversation through this medium. >> >> >> >> Quite commonly you will connect a text RTP stream and an audio RTP stream >> and possibly a video RTP stream in the same call, so that you will get an >> enhanced multimedia phone call with all supported media >> >> >> >> The ecrit requirements also mentions this correspondence >> >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >> >> >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >> >> Motivation: In PSTN, voice and text telephony (often called TTY or >> textphone in North America) are the only commonly supported media. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]), instant >> messaging and video. >> >> >> >> I am working in a European group where one of the goals is to agree on >> handling text users' requirements on emergency calling in IP networks. Of >> course we want to agree on global solutions if possible. >> >> >> >> Address mapping is one important and tricky question for text users. It is >> true that different countries have different approaches on emergency >> calling with PSTN Text telephones (TTYs). Some have the same number as >> voice users, while others have specific numbers. On the SIP side it would >> be good to have the same URL and make any required routing based on >> declared media, mode and language capabilities and preferences. >> >> >> >> Text capable gateways are not at all as common as VoIP gateways, so if the >> PSAP is still in PSTN, there is a need to have a good mechanism for routing >> emergency calls from SIP into PSTN through a text capable gateway. I cannot >> say that the mechanisms for finding the right gateway and make the proper >> address mapping to a PSTN number is solved yet for the text calls, and it >> would be excellent if we could have that topic in mind in the discussions >> and get proper methods documented. >> >> >> >> I have drafted, but not yet submitted a registration of a SIP URL and an >> ENUM subservice for real-time text. It might be helpful for finding text >> gateways and mapping addresses and (text) numbers, but I would like to see >> some scenarios thoroughly discussed before adding SIP URL and another ENUM >> subservice. >> >> >> >> Would there be any benefit of being allowed to enter TXP:112 or having >> ENUM to find an appropriate address if I call 112 from a SIP multimedia >> phone declaring text capabilities with m=text in sdp? >> >> >> >> >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> >> Gunnar Hellström, Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of >> François D. Ménard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> I made a contribution to CISC NTWG on use of SIP for transporting TDD >> traffic: >> >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >> >> I think it may be relevant to ECRIT. >> >> -=Francois=- >> >> >> On 2/15/06 10:51 AM, "Brian Rosen" <br@brianrosen.net> wrote: >> >> Within the scope of our work, I dont see how TDD services are impacted >> until we get to the architecture effort, which probably has to have some >> sections on that subject. >> With respect to the mapping protocol, I do not believe there is any impact >> at all. >> With respect to the sos service urn, I do not believe there is any impact >> at all >> >> Ecrit doesnt have scope to talk about any kind of gateways or codec >> support. >> >> Ah! My BCP on phones and proxies may need some mention, although this is >> the IETF, and I dont think the ploy of forcing the entire PSTN to support >> TDD just so 9-1-1 TDD will work. That effort would have to be in the >> general SIP arena. >> >> Brian >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> Folks, >> >> >> >> Like to know if there are specific ECRIT requirements recognizing support >> for Telecommunications Device for the Deaf (TDD) services for the hearing >> impaired. If not is this left for VOIP/SIP gateways to perform this >> requirement of translating the TDD calls to Text and Speech encoding. >> Wanted to make sure how ECRIT meet requirement for TDD services. >> >> >> >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> >> -- >> Francois D. Menard >> fmenard@xittelecom.com >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
- [Ecrit] ECRIT support for TTY/TDD calls Aquil, Kamran
- RE: [Ecrit] ECRIT support for TTY/TDD calls Brian Rosen
- Re: [Ecrit] ECRIT support for TTY/TDD calls Fran=?ISO-8859-1?B?5w==?=ois D. M=?ISO-8859-1?B?6Q==?=nard
- Re: [Ecrit] ECRIT support for TTY/TDD calls Tom-PT Taylor
- RE: [Ecrit] ECRIT support for TTY/TDD calls Gunnar Hellstrom
- RE: [Ecrit] ECRIT support for TTY/TDD calls Brian Rosen
- RE: [Ecrit] ECRIT support for TTY/TDD calls Gunnar Hellstrom
- RE: [Ecrit] ECRIT support for TTY/TDD calls Marc Linsner
- Re: [Ecrit] ECRIT support for TTY/TDD calls Henning Schulzrinne
- RE: [Ecrit] ECRIT support for TTY/TDD calls Brian Rosen
- Re: [Ecrit] ECRIT support for TTY/TDD calls Rockford9
- Re: [Ecrit] ECRIT support for TTY/TDD calls Henning Schulzrinne
- RE: [Ecrit] ECRIT support for TTY/TDD calls Gunnar Hellstrom
- Re: [Ecrit] ECRIT support for TTY/TDD calls Francois Menard
- RE: [Ecrit] ECRIT support for TTY/TDD calls Gunnar Hellstrom
- RE: [Ecrit] ECRIT support for TTY/TDD calls Brian Rosen
- RE: [Ecrit] ECRIT support for TTY/TDD calls Gunnar Hellstrom
- RE: [Ecrit] ECRIT support for TTY/TDD calls Ted Hardie
- RE: [Ecrit] ECRIT support for TTY/TDD calls Marc Linsner