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

From: "James M. Polk" <[email-masked]>
Date: Wed, 07 Dec 2005 20:38:11 -0600

Where does it say that a tel:uri is acceptable between an endpoint and the 
ESRP, and not a mapping protocol response *to* a ESRP?  I.e. I don't want 
the tel:uri to be an answer in the mapping protocol.

Once this is clear, I'm cool on this.

At 05:09 PM 12/7/2005 -0800, Roger Marshall wrote:
>So, (to me) it sounds like we're all more or less in agreement on the
>last paragraph to the Intro section.  Here it is again, with some
>wording changes, taking into account some of the thoughts discussed:
>
>Introduction
>... (at end)
>"Ideally, the mapping protocol would yield a URI from a preferred
>set of URIs (e.g. sips:uri; sip:uri), which would allow an
>emergency call to be completed using IP end-to-end (possibly via
>the Internet).  Despite this goal, some PSAPs may not immediately
>have IP based connectivity, and therefore it is imperative that the
>URI scheme not be fixed, in order to ensure support for a less
>preferred set of URIs, such as a TEL URI which may be used to
>Complete a call over the PSTN."
>
>Objections?
>
>
>Thanks.
>
>Roger Marshall
>
>
> >-----Original Message-----
> >From: Ted Hardie [mailto:[email-masked]]
> >Sent: Tuesday, December 06, 2005 4:37 PM
> >To: James M. Polk; Roger Marshall; Marc Linsner;
> >[email-masked]; [email-masked]
> >Subject: RE: [Ecrit] Issue 28: NENA Comments on
> >draft-ietf-ecrit-requirements-00 -Alternate Routes
> >
> >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:
> >>
> >>"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."
> >
> >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.
> >>
> >>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
> >
> >

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

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Dec 2005 08:26:46 -0500

James,

I'm confused.  If a PSAP loads the mapping db (ecrit) with a tel:uri why is
this not acceptable?  If the UA launched the mapping query and is returned a
tel:uri, the UA will submit this to it's proxy for further routing (unless
the UA has an on-board route/dial plan).  Admittedly, a tel:uri will/may
cause additional work by the proxy vs. a sip:uri, but tel:uri is something
the proxy is suppose to be able to handle.  Are you worried about the proxy
not equipped to handle tel:uri?

-Marc-

> Sent: Wednesday, December 07, 2005 9:38 PM
> To: Roger Marshall; Ted Hardie; Marc Linsner; 
> Where does it say that a tel:uri is acceptable between an 
> endpoint and the ESRP, and not a mapping protocol response 
> *to* a ESRP?  I.e. I don't want the tel:uri to be an answer 
> in the mapping protocol.
> 
> >"Ideally, the mapping protocol would yield a URI from a 
> preferred set 
> >of URIs (e.g. sips:uri; sip:uri), which would allow an 
> emergency call 
> >to be completed using IP end-to-end (possibly via the Internet).  
> >Despite this goal, some PSAPs may not immediately have IP based 
> >connectivity, and therefore it is imperative that the URI 
> scheme not be 
> >fixed, in order to ensure support for a less preferred set of URIs, 
> >such as a TEL URI which may be used to Complete a call over 
> the PSTN."
> >
> >Objections?
> >
> >
> >Thanks.
> >
> >Roger Marshall
> >
> >
> > >>not every PSAP will have IP based connectivity right away, so the 
> > >>URI scheme MAY be different. Given these conditions, alternate
> > >URI schemes,
> > >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
> > >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?
> > >
> 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
> > >
> > >
> > >
> > >>
> > >>
> > >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.
> > >>
> > >and not what is the product of a mapping conversion at a SIP proxy 
> > >*from* a SIP URI.
> > >>
> > >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):
> > >>
> > >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.
> > >>
> > >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?
> > >>
> > >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.
> > >>
> > >be swapped with another tel:uri.  How is this tel:uri 
> going to all of 
> > >a sudden make the non-IP-enabled PSAP work?
> > >>
> > >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?
> > >>
> > >>
> > >>
> > >>>>> > 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,
> > >>>>> 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

---

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

>not equipped to handle tel:uri?

A tel:uri of "tel:911" isn't going anywhere, is it? This is what a phone 
might give an ESRP to figure out where to send a request.  But the tel:uri 
needs further work to find its destination from some sort of look-up 
server/service, because it is not routable without there being a static 
route, which won't work because that ESRP may not be in the jurisdiction of 
the UAC making the emergency call.

So yeah, I'm worried about the additional work, because this is another 
mapping function ( "tel:911" = "<sip:[email-masked]>" ) that should 
have been done in the first place, and is another function which could fail.

So, how do you distinguish these two tel:uris

         1) tel:911 = <sip:[email-masked]>, from
         2) tel:911 = <sip:[email-masked]>

What indication in the INVITE is there to determine which psap this tel:911 
call goes to? If you say the PIDF-LO (if by-value) in the message, then I 
ask what purpose did the first mapping protocol serve?

We're not going to come up with a solution here such as this:

UAC -> ESRP
         INVITE tel:911 SIP/2.0
         (message body = Dallas, Texas)

ESRP (mapping query) -> Mapping server (of whatever kind)
         "look up Dallas, Texas, give me the URI to the PSAP"

Mapping server (of whatever kind) -> ESRP (mapping answer)
         tel:uri = +12145551212

ESRP then is forced to do TRIP or ENUM or "what" to convert 
"tel:+12145551212" into something that has a domain side of the uri scheme 
to route the message to the PSAP, or provide the actual IP address of the 
PSAP to put in the Request-URI field.

Or is it being thought about that every ESRP will have a static entry for 
every tel:uri string that's associated with a PSAP in a country or the 
entire world?

In other words, will either of these be close to what could occur at the 
ESRP *after* receiving the first mapping protocol answer:

a)  ESRP -> Dallas PSAP1
         INVITE tel:+12145551212 SIP/2.0
         Route: <sip:[email-masked]>
         (message body = Dallas, Texas)

where this ESRP understands that "+12145551212" = "[email-masked]" in 
its static configuration file(s)

or

b)  ESRP -> ENUM Server
         "please convert +12145551212 to a SIP URI"

in which there is a necessary 2nd mapping function performed to get to a 
routable URI scheme.

 From this discussion, I think a new requirement is necessary in this doc:

Req X, It MUST NOT be assumed that an ESRP will be the adjacent SIP element 
to the emergency services PSAP SIP element during an emergency call routing 
process.

Motivation: An ESRP cannot maintain the IP address of all emergency 
services ingress points for each potential request message transmission, 
therefore intermediate SIP server may assist in message routing to the 
destination ingress to the emergency services network.