Re: [Ecrit] ECRIT support for TTY/TDD calls
Francois Menard <fmenard@xittelecom.com> Thu, 16 February 2006 12:15 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 1F9i3B-000076-PS; Thu, 16 Feb 2006 07:15:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9i38-0008VD-Og for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 07:15:56 -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 HAA16380 for <ecrit@ietf.org>; Thu, 16 Feb 2006 07:14:07 -0500 (EST)
Received: from ns.xittelecom.com ([205.151.16.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9iHI-00027F-7Z for ecrit@ietf.org; Thu, 16 Feb 2006 07:30:36 -0500
Received: from fmenard (helo=localhost) by ns.xittelecom.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1F9i2p-0001vC-00; Thu, 16 Feb 2006 07:15:35 -0500
Date: Thu, 16 Feb 2006 07:15:35 -0500
From: Francois Menard <fmenard@xittelecom.com>
X-X-Sender: fmenard@localhost
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls
In-Reply-To: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu>
Message-ID: <Pine.LNX.4.61.0602160714410.4579@localhost>
References: <GLEFKJBKNILEBOELNIBIAEEADEAA.gunnar.hellstrom@omnitor.se> <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-515440095-1140092135=:4579"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636
Cc: "'Aquil, Kamran'" <kamran.aquil@mitretek.org>, 'Gregg Vanderheiden' <gv@trace.wisc.edu>, ecrit@ietf.org
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
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