Subject: RE: [Ecrit] Issue 28: NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Dec 2005 19:48:54 -0600

A tel:uri has nothing to do with the receiver, and is not a routable uri 
scheme because it has no domain side of the URI.  If the PSAP is not IP 
enabled, something is going to have to get the emeregency call to a ESGW, 
and a tel:uri is not that something that fixes this in the routing process.

I can right now direct a SIP message with a Request-URI at a GW that will 
get to a SR to a phase 0 PSAP (the phase 0 comment is to elicit the fact 
that the PSAP is ancient).  That Request URI may be a tel uri with the 
sequence 9999999999 or it could be [email-masked]

What matters is how the SIP element that has to route the message based on 
whatever URI decides where that message should go.  If this is a known 
destination based a configured address, it still gets to that ESGW and SR 
and PSAP.

I recommend the text below be rewritten to something like:

"Ideally, the mapping protocol would yield a SIPS-URI which would allow an
emergency call to be completed using IP end-to-end (via the 
Internet).  However, securing the signaling path may cause unwanted 
failures, therefore a SIP URI map be the best attainable in some 
situations.  If a tel:url is returned, this will require either prior 
knowledge of where to route this message, or to do an additional 
translation to a routable SIP or SIPS URI to forward towards the PSAP 
directly, or to the ESGW for non-IP-enabled PSAPs."

At 03:56 PM 12/5/2005 -0800, Roger Marshall wrote:
>NOTE: prior issue tracker url was wrong - should be:
>http://www.ietf-ecrit.org:8080/ecrit-req/
>
>Brian:
>
>Issue 28 talks about some new proposed text to be placed at the end of
>the Introduction section.  I've changed the text slightly from what you
>originally had, and is listed below:
>
>PROPOSED NEW TEXT (at end of Introduction):
>Ideally, the mapping protocol would yield a URI which would allow an
>emergency call to be completed using IP end-to-end (via the Internet).
>However, not all PSAPs may have IP based connectivity.  Thus the URI
>scheme cannot be fixed, and in fact may end up being a tel uri to allow
>calls to be completed over the PSTN.
>
>Editor's Comment: This seems to be consistent with the definition of
>"emergency address" (see Terminology section), which lists tel:uri as
>one potential uri scheme.
>
>Objections? Please send to the list, along with new proposed text.  This
>issue will be marked resolved after 10 days if no comments are received.
>
>
>
>Roger Marshall
>
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:[email-masked]]
> >Sent: Tuesday, November 08, 2005 6:50 PM
> >To: Roger Marshall; [email-masked]
> >Subject: RE: [Ecrit] NENA Comments on
> >draft-ietf-ecrit-requirements-00 -Alternate Routes
> >
> >Consider adding the following paragraph to the introductory
> >text on mapping:
> >
> >Ideally, the mapping protocol would yield a URI which would
> >allow an emergency call to be completed on the Internet.
> >However, not all PSAPs may have IP based connectivity.  Thus
> >the URI scheme cannot be fixed, and in fact may end up being a
> >tel uri to allow calls to be completed on the PSTN.
> >
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 6 Dec 2005 07:48:40 -0500

I'm sorry, have there been some changes to VoIP call handling while I was
sleeping last night?

A tel uri has been routable for some time now, through a variety of
mechanisms, most involving a gateway.  There is static routing, TRIP and
ENUM.  All of them route a tel uri.  Every VoIP system I know of does this
seamlessly.  Do we really need to say this in a requirements document? 

Further, Roger's "not all PSAPs may have IP based connectivity" is useful to
motivate why a tel uri may be returned.

Roger's proposed text is simpler and clearer.

You might want to add "possibly" in front of "via the Internet".  It may be
a private network.

Brian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 06 Dec 2005 09:27:42 -0500

I've finished a new draft of the Security Requirements document.  It is 
just circulating amongst the authors for approval now.  However, the 
possibility that we are talking a mixed IP-PSDTN path adds a new twist. 
I suppose we should have a look at it before issuing the new version of 
the draft.

> You might want to add "possibly" in front of "via the Internet".  It may be
...

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Dec 2005 13:44:11 -0600

At 07:48 AM 12/6/2005 -0500, Brian Rosen wrote:
>mechanisms, most involving a gateway.

A GW is an instance of a SIP endpoint, it is not a Proxy - which is a SIP 
message router.

>   There is static routing,

I can configure a static route on a Call-ID sequence, on an option-tag, or 
a TCP port number - I wouldn't consider these worth mentioning

>TRIP

how deployed is this and how deployed will this be?

>and
>ENUM.

ENUM does a conversion from E.164 to SIP URI to then do the routing.  ENUM 
is analogous to a mapping protocol.  Do we want two of these to get a 911 
call to work?

The text offering has the work "ideally", and we ideally want a SIPS URI.

WE will settle for a SIP URI.

If a tel:uri is returned, we need to do more processing, like convert this 
uri to a SIP URI to route the message *because* we do not know if the next 
hop proxy is PSAP, and it might be a intermediate proxy doing the final 
resolution of URI to IP address, or AOR (or a state's emergency VSP) to 
contact address (of a specific city's PSAP).

>All of them route a tel uri.  Every VoIP system I know of does this

Movitvate? Why do we need motivation here?

Whether my text is used or not, this requirement has the ability to have a 
hierarchy of preferred options listed, and my text gives that order for 
motivation to work towards the most secure solution.  It does not dismiss 
tel:uris, it just says they are not preferred.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Dec 2005 15:30:23 -0500

In-line..... 

snip......

> 
> If a tel:uri is returned, we need to do more processing, like 
> convert this uri to a SIP URI to route the message *because* 
> we do not know if the next hop proxy is PSAP, and it might be 
> a intermediate proxy doing the final resolution of URI to IP 
> address, or AOR (or a state's emergency VSP) to contact 
> address (of a specific city's PSAP).
> 

>From an ECRIT pov, I don't agree.  Yes, the SIP proxy may perform different
(including additional) steps in order to resolve a tel:uri, but ECRIT is
complete at this point.  A tel:uri is valid in the SIP domain so it should
be valid in the ECRIT domain.

> >Further, Roger's "not all PSAPs may have IP based connectivity" is 
> >useful to motivate why a tel uri may be returned.
> 
> Whether my text is used or not, this requirement has the 
> ability to have a hierarchy of preferred options listed, and 
> my text gives that order for motivation to work towards the 
> most secure solution.  It does not dismiss tel:uris, it just 
> says they are not preferred.

The designer of the PSAP system will decide the architecture of the contact
mechanism.  Guidance may be offered in an architecture BCP, but I'm not sure
it's proper for a requirements draft.

I vote for Roger's text.

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Dec 2005 15:02:31 -0600

In-line

>be valid in the ECRIT domain.

but it's not routable in the SIP domain, and the SIP specs state that 
conversion is necessary to make the message routable.  This is an extra 
step that is less desired.

>it's proper for a requirements draft.

This is a ridiculous statement. Of course requirements documents give 
preferential orders to mechanisms. The offered text here is not absolute, 
and does not say that a tel:uri is forbidden.