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

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

Roger

I'll propose what you wrote with the appropriate MUSTs, SHOULDs and MAYs 
like most requirements should have:

"Ideally, the mapping protocol SHOULD yield a URI (e.g. sip:uri,
sips:uri, etc.) which would allow an emergency call to be routed
using IP end-to-end  (possibly, via the Internet).  Though this is the
goal, not every PSAP will have IP based connectivity right away, so the
URI scheme MAY be different.  Given these conditions, alternate URI schemes,
such as tel:uri, MAY be used in order to complete calls over the PSTN."

I don't know if we want to get into specifying that dialog generating SIP 
requests SHOULD have a SIP or SIPS URI.  INVITE is such a request, whereas 
Rohan's XMPP scheme example would not be used to generate a dialog, so that 
wouldn't be a contradiction.

Now for me scratching my head at the second sentence:
I'm a bit vague as to how a tel:uri is going to solve the ESRP to ESGW 
communications route path.

Generally, a tel:uri is what is entered at the endstation, and not what is 
the product of a mapping conversion at a SIP proxy *from* a SIP URI.

In other words, tel:911 is what could be entered by an IP phone, and shows 
up as the Request-URI in the INVITE to a ESRP server.  This ESRP needs to 
do a mapping function to determine which PSAP is going to get this call 
set-up message. Take this basic topology (apologies James for the ESGW 
reference, but this makes the most sense to some of us for this discussion):

IP phone ==> ESRP ==> ESGW ==> SR ==> PSAP

The IP Phone creates an INVITE such as this:

INVITE tel:911 SIP/2.0
Via: SIP/2.0/UDP ipphone1.localdomain.com;
   branch=z9hG4bK776asdhs
To: 911
From: Roger <[email-masked]>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REGISTER,
   REFER, NOTIFY, UPDATE
Call-ID: [email-masked]
CSeq: 1 INVITE
Contact: <[email-masked]>
Content-Type: mulipart/mixed; boundary=--0a1
Content-length: ...

--0a1
Content-Type: application/sdp
(SDP)
--0a1
Content-Type: pidf-lo+xml
(PIDF-LO)
--0a1--

Now, the ESRP receives this message, realizes this is an emergency call, 
knows to look for the location message body to ship off to a mapping 
server.  This could be a local process, or use one of the various methods 
discussed on this list.  I'm not playing favorites in that regard for now.

The nut of this discussion is what the ESRP gets back from the mapping server.

Is this, or can it be, a tel:uri?

The way I read the requirement as written, even with my alteration above, 
is I think both are saying it's possible to use a tel:uri from the mapping 
server to replace the existing Request-URI (tel:911 here) with.  What is 
this uri going to look like, and how exactly will this get the message 
towards the ESGW to ensure it meets the i2 requirement of getting to the 
Selective Router and towards the proper PSAP?

Are we talking about keeping the Request-URI the same and adding a Route 
header of the ESGW? This isn't the mapping protocol function as I'm 
understanding it to be, although this could work, as long as the ESRP 
maintains dialog state and the Contact header remains the same in case 
there are issues involving redundancy with a callback situation.

I don't see why a tel:uri has to stay as the Request-URI, or be swapped 
with another tel:uri.  How is this tel:uri going to all of a sudden make 
the non-IP-enabled PSAP work?

I should think that any ESGW receiving an INVITE from a ESRP with an 
agreeable emergency declaration should translate that INVITE into starting 
a call set-up to the Selective Router with the ANI of the user. How does a 
tel:uri scheme enable this, whereas a SIP URI would not?

At 03:03 PM 12/6/2005 -0800, Roger Marshall wrote:
>James:
>It seems like we have agreement (I think) that tel:uri's shouldn't be
>excluded altogether.  I also agree that there is a preference as to
>which uri scheme is to be used, (e.g. sip:uri over a tel:uri), so I've
>revised the text:
>
>PROPOSED (updated 12/06) TEXT:
>"Ideally, the mapping protocol would yield a URI (e.g. sip:uri,
>sips:uri, etc.) which would allow an emergency call to be completed
>using IP end-to-end (possibly, via the Internet).  Though this is the
>goal, not every PSAP will have IP based connectivity right away, so the
>URI scheme is not fixed.  Given these conditions, alternate URI schemes,
>
>such as tel:uri, are allowed in order to complete calls over the PSTN."
>
>Agreeable?
>
>Roger Marshall
>
>
> >-----Original Message-----
> >From: James M. Polk [mailto:[email-masked]]
> >Sent: Tuesday, December 06, 2005 1:03 PM
> >To: Marc Linsner; [email-masked]; Roger Marshall; [email-masked]
> >Subject: RE: [Ecrit] Issue 28: NENA Comments on
> >draft-ietf-ecrit-requirements-00 -Alternate Routes
> >
> >In-line
> >
> >At 03:30 PM 12/6/2005 -0500, Marc Linsner wrote:
> >>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.
> >
> >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.
> >
> >
> >> > >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.
> >> >
> >> > 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.
> >>
> >>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.
> >
> >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.
> >
> >
> >>I vote for Roger's text.
> >>
> >>-Marc-
> >

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Dec 2005 16:36:37 -0800

At 6:21 PM -0600 12/6/05, James M. Polk wrote:
>Roger
>
>I'll propose what you wrote with the appropriate MUSTs, SHOULDs and MAYs like most requirements should have:
>

Written this way, I would interpret this to mean that any URI scheme which
mapped to a protocol that used IP end-to-end was in the preferred set, and
that URI schemes like tel which required gateways or further mapping
in this context were in a less preferred set.    I am fine with this, since I think
the choice of specific URI schemes (sip, sips) falls out pretty
easily in operational reality, but I wanted to flag it in case James meant
it to say "SHOULD yield a SIP or SIPS URI which would allow an emergency
call to be routed" and to put non-SIP URI schemes in the same bucket
whether they were IP end-to-end or not.  To put this in another way, would
a registered scheme of SMS be in the preferred set if it were possible to
use it over IP without gateways?

Also, I believe we said earlier that the mapping protocol would yield one
or more URIs, with at most one per scheme.  So you could have a SIP URI
returned, as well as an SMS URI, with the preference order set by the client
according to its capabilities.
			regards,
				Ted

>
>
>I don't know if we want to get into specifying that dialog generating SIP requests SHOULD have a SIP or SIPS URI.  INVITE is such a request, whereas Rohan's XMPP scheme example would not be used to generate a dialog, so that wouldn't be a contradiction.
>
>I'm a bit vague as to how a tel:uri is going to solve the ESRP to ESGW communications route path.
>
>Generally, a tel:uri is what is entered at the endstation, and not what is the product of a mapping conversion at a SIP proxy *from* a SIP URI.
>
>In other words, tel:911 is what could be entered by an IP phone, and shows up as the Request-URI in the INVITE to a ESRP server.  This ESRP needs to do a mapping function to determine which PSAP is going to get this call set-up message. Take this basic topology (apologies James for the ESGW reference, but this makes the most sense to some of us for this discussion):
>
>Now, the ESRP receives this message, realizes this is an emergency call, knows to look for the location message body to ship off to a mapping server.  This could be a local process, or use one of the various methods discussed on this list.  I'm not playing favorites in that regard for now.
>
>The way I read the requirement as written, even with my alteration above, is I think both are saying it's possible to use a tel:uri from the mapping server to replace the existing Request-URI (tel:911 here) with.  What is this uri going to look like, and how exactly will this get the message towards the ESGW to ensure it meets the i2 requirement of getting to the Selective Router and towards the proper PSAP?
>
>Are we talking about keeping the Request-URI the same and adding a Route header of the ESGW? This isn't the mapping protocol function as I'm understanding it to be, although this could work, as long as the ESRP maintains dialog state and the Contact header remains the same in case there are issues involving redundancy with a callback situation.
>
>I don't see why a tel:uri has to stay as the Request-URI, or be swapped with another tel:uri.  How is this tel:uri going to all of a sudden make the non-IP-enabled PSAP work?
>
>I should think that any ESGW receiving an INVITE from a ESRP with an agreeable emergency declaration should translate that INVITE into starting a call set-up to the Selective Router with the ANI of the user. How does a tel:uri scheme enable this, whereas a SIP URI would not?
>
>
>