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