[Ecrit] Re: Ecrit Digest, Vol 13, Issue 20

["Hansen, Jenny <Contractor>" <[e-mail]>]

I agree w/Henning. From an operational standpoint, old salt dispatcher that I am, have the call (all of them) routed to the Primary PSAP.

Jenny Hansen
NG9-1-1

--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: [e-mail] <[e-mail]>
To: [e-mail] <[e-mail]>
Sent: Wed Feb 15 21:20:21 2006
Subject: Ecrit Digest, Vol 13, Issue 20

Send Ecrit mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ecrit
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ecrit digest..."


Today's Topics:

   1. Re: ECRIT support for TTY/TDD calls (Henning Schulzrinne)
   2. RE: ECRIT support for TTY/TDD calls (Brian Rosen)
   3. Re: ECRIT support for TTY/TDD calls ([e-mail])


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

Message: 1
Date: Wed, 15 Feb 2006 20:05:46 -0500
From: Henning Schulzrinne <[e-mail]>
Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls
To: "Gunnar Hellstrom" <[e-mail]>
Cc: 'Gregg Vanderheiden' <[e-mail]>, "'Aquil,	Kamran'"
	<[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
	format=flowed

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




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

Message: 2
Date: Wed, 15 Feb 2006 21:17:15 -0500
From: "Brian Rosen" <[e-mail]>
Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls
To: "'Henning Schulzrinne'" <[e-mail]>,	"'Gunnar
	Hellstrom'" <[e-mail]>
Cc: "'Aquil, Kamran'" <[e-mail]>, [e-mail],
	'Gregg Vanderheiden' <[e-mail]>
Message-ID: <070c01c6329f$1d36b030$[e-mail]>
Content-Type: text/plain;	charset="iso-8859-1"

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:[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




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

Message: 3
Date: Wed, 15 Feb 2006 21:18:03 EST
From: [e-mail]
Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls
To: [e-mail], [e-mail],
	[e-mail],	[e-mail],
	[e-mail], [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

 
I have a question on what is being discussed. Are you only discussing  
TTY/TDD devices used via PSTN specifically by deaf to access emergency services?  
Wanting to clarify that you are not discussing any text user access beyond that, 
 since that could be used by anyone to access emergency services and so 
should  have no special TTY/TDD type handling.
 
Thanks for assistance.
 
Rick Jones
 
In a message dated 2/15/2006 7:47:33 PM Eastern Standard Time,  
[e-mail] writes:

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


 
____________________________________
 From: [e-mail]  [mailto:[e-mail]] On Behalf Of 
Brian  Rosen
Sent: Wednesday, February 15, 2006 6:17 PM
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_ 
(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_ 
(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_ 
(http://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]_ (mailto:[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_ 
(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âEUR(tm)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âEUR(tm)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âEUR(tm)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]]_ 
(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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ecrit/attachments/20060215/840ae5e2/attachment.htm

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

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


End of Ecrit Digest, Vol 13, Issue 20
*************************************

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