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

From: "Aquil, Kamran" <[email-masked]>
Date: Wed, 15 Feb 2006 10:30:43 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Feb 2006 10:51:32 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Aquil, Kamran
Sent: Wednesday, February 15, 2006 10:31 AM
To: [email-masked]
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

Mitretek Systems.

---

From: "François D. Ménard" <[email-masked]>
Date: Wed, 15 Feb 2006 11:13:43 -0500

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" <[email-masked]> 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.
> 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
>  
> 
> 
> Like to know if there are specific ECRIT requirements recognizing support for
> Telecommunications Device for the Deaf (TDD) services for the hearing

-- 
Francois D. Menard
[email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 15 Feb 2006 11:32:00 -0500

Some countries have separate emergency numbers to call for TDD support. 
The implication is that this may have to be reflected somehow in the 
mapping, but definitely will be reflected in the media negotiation 
between the emergency caller's device and the PSAP.

Aquil, Kamran wrote:
> ------------------------------------------------------------------------
>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 15 Feb 2006 23:47:05 +0100

Re: [Ecrit] ECRIT support for TTY/TDD callsIt 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
[email-masked]
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
François D. Ménard
  Sent: Wednesday, February 15, 2006 5:14 PM
  To: [email-masked]; 'Aquil, Kamran'; [email-masked]
  Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls

  -=Francois=-

    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: [email-masked] [mailto:[email-masked]] On Behalf
Of Aquil, Kamran
    Sent: Wednesday, February 15, 2006 10:31 AM
    To: [email-masked]
    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

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

  --
  Francois D. Menard
  [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Feb 2006 18:16:36 -0500

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:[email-masked]] 
Sent: Wednesday, February 15, 2006 5:47 PM
To: [email-masked]; 'Aquil, Kamran'; [email-masked]; 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

And it is documented in

 

Gunnar

-----Original Message-----

-=Francois=-

 
 
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: [email-masked] [mailto:[email-masked]]
<mailto:[email-masked]%5d>  On Behalf Of Aquil, Kamran
Sent: Wednesday, February 15, 2006 10:31 AM
To: [email-masked]
Subject: [Ecrit] ECRIT support for TTY/TDD calls

Folks,

Regards,
Kamran Aquil

  _____  

-- 
Francois D. Menard
[email-masked]

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 16 Feb 2006 00:52:31 +0100

Re: [Ecrit] ECRIT support for TTY/TDD callsWhat 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

Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se
  -----Original Message-----
  From: Brian Rosen [mailto:[email-masked]]
  Sent: Thursday, February 16, 2006 12:17 AM
  To: 'Gunnar Hellstrom'; [email-masked]; 'Aquil, Kamran'; 'François D.
Ménard'
  Cc: 'Gregg Vanderheiden'

  Brian

  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

  And it is documented in

  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.

  Gunnar

  --------------------------------------------------------------------------
---

    -----Original Message-----

    -=Francois=-

    Brian

    Folks,

    Regards,
    Kamran Aquil

    --
    Francois D. Menard
    [email-masked]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 15 Feb 2006 19:43:44 -0500

So the UA must know this?  Not the proxy...?
 
-Marc-

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Wednesday, February 15, 2006 6:17 PM
To: 'Gunnar Hellstrom'; [email-masked]; 'Aquil, Kamran'; 'François D.
Ménard'
Cc: 'Gregg Vanderheiden'
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls

Brian

  _____  

It is discussed in

And it is documented in

 

Gunnar

-----Original Message-----

-=Francois=-

 

Brian

  _____  

Folks,

Regards,
Kamran Aquil

  _____  

-- 
Francois D. Menard
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Feb 2006 20:05:46 -0500

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 helps to find a PSTN based PSAP with text capabilities, it  
> could be called sos.police.txp
>
> tty is a US term.
>
> Gunnar
>
> ---------------------------------------------------------------------- 
> -------
> To: 'Gunnar Hellstrom'; [email-masked]; 'Aquil, Kamran'; 'François  
> D. Ménard'
> Cc: 'Gregg Vanderheiden'
> All I get out of this for ecrit is that we need entries for  
> sos.police.tty in the service registry
>
>
>
> Brian
>
>
>
> 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
>
>
>
> 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  
> 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
>
>
>
> 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  
> 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
>
> ---------------------------------------------------------------------- 
> -------
>
> From: [email-masked] [mailto:[email-masked]]On  
> Behalf Of François D. Ménard
> I made a contribution to CISC NTWG on use of SIP for transporting  
> TDD traffic:
>
> 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.
> 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: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Aquil, Kamran
> 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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Feb 2006 21:17:15 -0500

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 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:[email-masked]] 
Sent: Wednesday, February 15, 2006 8:06 PM
To: Gunnar Hellstrom
Cc: [email-masked]; [email-masked]; 'Aquil, Kamran'; 'François D. Ménard'
; 'Gregg Vanderheiden'

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Feb 2006 21:38:00 -0500

> differentiate the text calls from voice calls.  I suspect that's hard.

I don't think this is hard when you have the SDP information, as the  
codec list would differ depending on whether the caller (or caller's  
device) can do text or audio (or video). Alternatively, there's also  
the caller preferences model.

> resolved to the older technology.

I'm biased towards making the initial system as simple as possible  
and leave out cases that may well become obsolete by the time we see  
deployment, particularly where, as in this case, adding them later is  
not hard, requiring only a registration action. If we're lucky, we'll  
never need the mechanism. I hope we all agree that having separate  
numbers for TTY (or other special media) is not a desirable situation  
from a user interface perspective, even if it exists in some places  
today.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 16 Feb 2006 06:49:52 +0100

Please understand that just showing text capability in SDP does absolutely
not mean that the user needs to get in touch with any special text-adapted
handling in emergency. The real-time-text medium should be used in
mainstream terminals to the benefit of all users.

But if PSAPs have both text capable terminals and plain voice terminals, the
real-time-text sdp capability can be taken as a guiding factor to answer the
call in a capable terminal.

Preference indications are more appropriate to use for diverting calls to
special handling.

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[email-masked] <mailto:[email-masked]>
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se <http://www.omnitor.se>

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 3:38 AM
To: [email-masked]
Cc: 'Gunnar Hellstrom'; [email-masked]; 'Aquil, Kamran'; ''Francois D.
Menard' ' ; 'Gregg Vanderheiden'
Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls

---

From: Francois Menard <[email-masked]>
Date: Thu, 16 Feb 2006 07:15:35 -0500 (EST)

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
[email-masked]

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
>
>> 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, 
>> 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.
>> 
>> 
>> 
>> Within the scope of our work, I dont see how TDD services are impacted 
>> 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.
>> 
>> the IETF, and I dont think the ploy of forcing the entire PSTN to support 
>> 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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 16 Feb 2006 13:45:09 +0100

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

-----Original Message-----
From: Francois Menard [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 1:16 PM
To: Henning Schulzrinne
Cc: Gunnar Hellstrom; [email-masked]; [email-masked]; 'Aquil,
Kamran'; 'Gregg Vanderheiden'
Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls

F.

> Since this could be added on later if necessary, once we know whether
anybody
>> If it helps to find a PSTN based PSAP with text capabilities, it could be
sos.police.tty
>> Also other standardisation bodies have picked up the real-time text
concept
>> phone declaring text capabilities with m=text in sdp?
impact

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Feb 2006 09:13:48 -0500

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:[email-masked]] 
Sent: Thursday, February 16, 2006 7:45 AM
To: Francois Menard; Henning Schulzrinne
Cc: [email-masked]; [email-masked]; 'Aquil, Kamran'; 'Gregg Vanderheiden'
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls

Francois,

Gunnar

-----Original Message-----
From: Francois Menard [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 1:16 PM
To: Henning Schulzrinne
Cc: Gunnar Hellstrom; [email-masked]; [email-masked]; 'Aquil,

F.

anybody
sos.police.tty
concept
impact

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 16 Feb 2006 17:19:01 +0100

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

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 3:14 PM
To: 'Gunnar Hellstrom'; 'Francois Menard'; 'Henning Schulzrinne'
Cc: [email-masked]; 'Aquil, Kamran'; 'Gregg Vanderheiden'
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls

Brian

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 7:45 AM
To: Francois Menard; Henning Schulzrinne
Cc: [email-masked]; [email-masked]; 'Aquil, Kamran'; 'Gregg Vanderheiden'
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls

Francois,

Gunnar

-----Original Message-----
From: Francois Menard [mailto:[email-masked]]
Sent: Thursday, February 16, 2006 1:16 PM
To: Henning Schulzrinne
Cc: Gunnar Hellstrom; [email-masked]; [email-masked]; 'Aquil,

F.

anybody
sos.police.tty
concept
impact

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Feb 2006 12:14:15 -0800

>some older technology, you have to differentiate (that is, the mapping will

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 17 Feb 2006 10:33:12 -0500

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-

> >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.
> >
> >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.
> 
> >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
> >
> >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.
> >
> >> To: [email-masked]; 'Aquil, Kamran'; [email-masked]; 
> François D. 
> >> Ménard
> >> Cc: Gregg Vanderheiden
> >> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>
> >> in 
> www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt
> >>
> >>
> >>       Motivation: In PSTN, voice and text telephony (often 
> called TTY 
> >> or
> >> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> From: [email-masked] 
> [mailto:[email-masked]]On Behalf 
> >> Of François D. Ménard
> >> impacted until we get to the architecture effort, which 
> probably has 
> >> to have some sections on that subject.
> >> 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.
> >>
> >>
> >>
> >>
> >>