Subject: [Ecrit] Unclear about tel:uris solving old PSAP connectivity...?

From: "James M. Polk" <[email-masked]>
Date: Thu, 08 Dec 2005 12:48:41 -0600

I'm unclear why some one us think a tel:uri scheme will aid an emergency 
INVITE message in getting to a PSAP that isn't IP enabled?  How does the 
tel:uri help the tradictional infrastructure?

This is analogous to the NENA i2 solution, in which the Selective Router 
and PSAP do not have to have any modifications in order for an IP based 
phone/device to be able to call said PSAP with a nationally generic 
emergency number sequence (like "911").

How will a tel:uri accomplish something in this scenario that a SIP or SIPS 
URI doesn't?

This is related to the current thread on Issue #28.

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Dec 2005 14:08:06 -0500

You are totally convincing when you say that it is pointless for the 
mapping protocol to return "tel:911". But I cannot see why there should 
be a problem with needing a second mapping for an E.164 number or even 
an enterprise emergency centre number suitably constrained by 
"phone-context". The "P" in "ESRP" stands for "Proxy", and it's an 
ordinary part of a Proxy's job description to perform such routings 
(subject, of course, to operator policy).

The need for a separate mapping operation is a separate issue from 
whether it is possible to use an ordinary telephone number to reach the 
desired PSAP. Maybe it's this latter concern that has you so upset.

James M. Polk wrote:
> How will a tel:uri accomplish something in this scenario that a SIP or 
> SIPS URI doesn't?
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 08 Dec 2005 13:54:20 -0600

Tom

I'm not upset, I'm just focused on this issue at the moment, because I 
think several of us were assuming different pieces were also in play.

I've been in enough discussions where ECRIT was going to produce the one 
true address to be routed to the PSAP, that if the ECRIT mapping protocol 
were to produce something that needs to be looked up a second time using a 
second procedure (likely ENUM), this will change many of those discussions.

I am not opposd to the idea of the mapping protocol producing a "unique" 
E.164 for the destination PSAP, but I know not all (not many?) PSAPs have a 
unique E.164 number that's considered to be an emergency line.  This number 
is more likely to be the PSAP's admin line that doesn't get preferential 
attention, doesn't tie into the MSAG, and doesn't produce the ALI-type 
location look-up that most want an emergency call to produce.  This is the 
'E' in E911 as far as North America is concerned.

At 02:08 PM 12/8/2005 -0500, Tom-PT Taylor wrote:
>mapping protocol to return "tel:911". But I cannot see why there should be 
>a problem with needing a second mapping for an E.164 number or even an 
>enterprise emergency centre number suitably constrained by 
>The need for a separate mapping operation is a separate issue from whether 
>it is possible to use an ordinary telephone number to reach the desired 
>PSAP. Maybe it's this latter concern that has you so upset.
>
>James M. Polk wrote:

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Dec 2005 15:54:00 -0500

The purpose of ecrit is to solve a 'mapping' function from a pidf-lo to a
uri such that a VoIP (and other contexts) device can continue with it's
intended process of determining the routing for session setup.  With this
said, IMO, any uri that is valid for route processing, should be allowed
within the ecrit mapping architecture.

In reading rfc2806, a tel:uri specifically identifies a destination in the
PSTN (I think the rfc says 'phone network').  A tel:uri can include global
(unique on earth) e.164 identifiers as well as locally significant (unique
within domain) identifiers.

We all imagine that an ecrit mapping system will be implemented on a
public/global scale, but IMO we must also assume enterprise scale systems
for handling campus type environments.

Hence, IMO, a tel:uri that is unique within the intended domain should be
(ecrit) valid.  So, within an enterprise domain, tel:911 should be a
perfectly valid response to a ecrit mapping query.  This would tell the VoIP
routing device to utilize it's preprogrammed gateway mechanism to reach the
intended e.164 identifier on the PSTN.  If the domain is global/public,
since tel:911 would not be unique, words covering the obvious may be
warranted.

Just another opinion....

-Marc-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of James M. Polk
> Sent: Thursday, December 08, 2005 2:54 PM
> To: Tom-PT Taylor
> Cc: [email-masked]
> Subject: Re: [Ecrit] Unclear about tel:uris solving old PSAP 
> connectivity...?
> 
> Tom
> 
> I'm not upset, I'm just focused on this issue at the moment, 
> because I think several of us were assuming different pieces 
> were also in play.
> 
> I've been in enough discussions where ECRIT was going to 
> produce the one true address to be routed to the PSAP, that 
> if the ECRIT mapping protocol were to produce something that 
> needs to be looked up a second time using a second procedure 
> (likely ENUM), this will change many of those discussions.
> 
> E.164 for the destination PSAP, but I know not all (not 
> many?) PSAPs have a unique E.164 number that's considered to 
> be an emergency line.  This number is more likely to be the 
> PSAP's admin line that doesn't get preferential attention, 
> doesn't tie into the MSAG, and doesn't produce the ALI-type 
> location look-up that most want an emergency call to produce. 
>  This is the 'E' in E911 as far as North America is concerned.
> 
> >>I'm unclear why some one us think a tel:uri scheme will aid an 
> >>emergency INVITE message in getting to a PSAP that isn't IP 
> enabled?  
> >>How does the tel:uri help the tradictional infrastructure?
> >>This is analogous to the NENA i2 solution, in which the Selective 
> >>Router and PSAP do not have to have any modifications in 
> order for an 
> >>IP based phone/device to be able to call said PSAP with a 
> nationally 
> >>generic emergency number sequence (like "911").

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 08 Dec 2005 15:37:09 -0600

>since tel:911 would not be unique, words covering the obvious may be

one I agree with, with this scoping included.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Dec 2005 17:04:02 -0500

Two quick remarks on tel URIs:

- Please note that 2806 has been obsoleted by RFC 3966.

- In particular, tel:911 is *not* valid; you'd have to add a context 
label to that URI to make it a valid tel URI.

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Dec 2005 17:25:13 -0500

So, it would be either:

tel:+1-911

or 

tel:911;phone-context=example.com

-Marc- 

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, December 08, 2005 5:04 PM
> To: Marc Linsner
> Cc: [email-masked]
> - In particular, tel:911 is *not* valid; you'd have to add a 
> context label to that URI to make it a valid tel URI.
> 
> Henning
> 
> Marc Linsner wrote:
> 
> > In reading rfc2806, a tel:uri specifically identifies a 
> destination in 
> > the PSTN (I think the rfc says 'phone network').  A tel:uri can 
> > include global (unique on earth) e.164 identifiers as well 
> as locally 
> > significant (unique within domain) identifiers.
> > 
> > Hence, IMO, a tel:uri that is unique within the intended 
> domain should 
> > be
> > perfectly valid response to a ecrit mapping query.  This would tell 
> > the VoIP routing device to utilize it's preprogrammed gateway 
> > mechanism to reach the intended e.164 identifier on the 
> PSTN.  If the 
> > domain is global/public, since tel:911 would not be unique, words 
> > covering the obvious may be warranted.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Dec 2005 17:26:31 -0500

The former is not an E.164 number since you can't dial it from anywhere 
else except the US.

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Dec 2005 17:31:03 -0500

But it is a valid nanpa number.....interesting...

-Marc- 

> Sent: Thursday, December 08, 2005 5:27 PM
> To: Marc Linsner
> Cc: [email-masked]
> The former is not an E.164 number since you can't dial it 
> from anywhere else except the US.
> 
> Marc Linsner wrote:
> > So, it would be either:
> > 
> > tel:+1-911
> > 
> > or
> >

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Dec 2005 17:46:38 -0500

Based on these two quotes:

On Dec 8, 2005, at 2:23 PM, Stastny Richard wrote:
> You are correct that tel URIs are only required for i2 solutions
> and this is the reason why we need the tel URI IN ADDITION
> to the SIP URI in the response of the database query

On Dec 8, 2005, at 3:54 PM, Marc Linsner wrote:
> So, within an enterprise domain, tel:911 should be a
> the VoIP

It would seem that this is not a protocol requirements issue but a  
deployment considerations issue.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Dec 2005 17:55:49 -0500

> > You are correct that tel URIs are only required for i2 
> solutions and 
> > this is the reason why we need the tel URI IN ADDITION to 
> the SIP URI 
> > in the response of the database query
> 
> 
> perfectly valid 
> > response to a ecrit mapping query.  This would tell the 
> VoIP routing 
> > device to utilize it's preprogrammed gateway mechanism to reach the 
> > intended e.164 identifier on the PSTN.  If the domain is global/ 
> > public, since tel:911 would not be unique, words covering 
> the obvious 
> > may be warranted.
> 
> It would seem that this is not a protocol requirements issue 
> but a deployment considerations issue.

That's the way I see it....

-Marc-