RE: [Ecrit] ECRIT support for TTY/TDD calls

["Marc Linsner" <[e-mail]>]

After reading this thread, it makes one wonder if ecrit mapping is the most
appropriate place to perform 'routing' based on attributes other than
pidf-lo.  If we define service urns for media types, why not language
preferences?  Why not time of day?  Why not current weather conditions?  Why
not color of handset?

My point: Routing based on non-location attributes belongs to the ESRP/PSAP
domain and should remain there.  I don't believe that anyone expects the uri
returned by the ecrit mapping mechanism to be the actual end device at the
PSAP.  There will be an intermediary proxy that can/should handle routing
based on attributes other than location.  IMO, keeping the for-public-view
ECRIT mapping simple and clean goes a long way towards acceptance and
easy/fast implementation.

-Marc-




> At 9:17 PM -0500 2/15/06, Brian Rosen wrote:
> >If a country has a dialstring that is the text-to-police dialstring, 
> >then we must map it into a unique urn unless we know that in every 
> >instance we can differentiate the text calls from voice 
> calls.  I suspect that's hard.
> >
> >With a SIP URI, you know you can use media negotiation to 
> get the text 
> >codec, and if the PSAP accepts the text call, then the 
> mapper will have 
> >the same result for sos.police.txt as sos.police.  If you 
> have to map 
> >instead to some older technology, you have to differentiate 
> (that is, 
> >the mapping will be different).
> 
> It does seem possible to define a URI scheme specific to the 
> text service, so that the mapping protocol can respond with a 
> URI for that service which is distinguishable from the voice 
> service.  As it stands, we have said that the mapping 
> protocol should return at most one result per URI scheme, but 
> if the URI schemes are distinct that's not a problem.
> 
> This also makes it possible to define the text-capable PSAP 
> mapping independently of the voice-capable PSAP mapping, 
> which may be valuable if a subset of PSAPs are capable.
> 
> I agree with Henning, though, that this subset case should get rarer.
> 			regards,
> 				Ted
> 
> 
> >It may be that we make an assumption that the mapping 
> function does not 
> >yield a URI if the PSAP doesn't accept a call with a negotiated text 
> >codec, which would mean we don't need to have sos.police.txt.  That 
> >would force backwards compatibility to existing systems when mapping 
> >fails.  That's not terrible, but I thought it made more sense to let 
> >mapping yield a URI that resolved to the older technology.
> >
> >Brian
> >
> >-----Original Message-----
> >From: Henning Schulzrinne [mailto:[e-mail]]
> >Sent: Wednesday, February 15, 2006 8:06 PM
> >To: Gunnar Hellstrom
> >Cc: [e-mail]; [e-mail]; 'Aquil, Kamran'; 
> 'François D. Ménard'
> >; 'Gregg Vanderheiden'
> >Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls
> >
> >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
> >> [e-mail]
> >> Mob: [phone]
> >> Phone: [phone]
> >> www.omnitor.se
> >> -----Original Message-----
> >> From: Brian Rosen [mailto:[e-mail]]
> >> Sent: Thursday, February 16, 2006 12:17 AM
> >> To: 'Gunnar Hellstrom'; [e-mail]; '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:[e-mail]]
> >> Sent: Wednesday, February 15, 2006 5:47 PM
> >> To: [e-mail]; 'Aquil, Kamran'; [e-mail]; 
> 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
> >>
> >> [e-mail]
> >>
> >> -----Original Message-----
> >> From: [e-mail] 
> [mailto:[e-mail]]On Behalf 
> >> Of François D. Ménard
> >> Sent: Wednesday, February 15, 2006 5:14 PM
> >> To: [e-mail]; 'Aquil, Kamran'; [e-mail]
> >> 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" <[e-mail]> wrote:
> >>
> >> Within the scope of our work, I don’t 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 doesn’t 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 don’t 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: [e-mail] [mailto:[e-mail]] On 
> >> Behalf Of Aquil, Kamran
> >> Sent: Wednesday, February 15, 2006 10:31 AM
> >> To: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >>
> >> --
> >> Francois D. Menard
> >> [e-mail]
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit