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

From: "Roger Marshall" <[email-masked]>
Date: Tue, 6 Dec 2005 17:24:53 -0800

Ted:
See inline...

>-----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?

I like the idea of a "preferred set" of uri's.  That is something that
the current doc DOES NOT currently mention.  Is there text that's
needed?

>
>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.

I'm glad you brought this up, since we currently DON'T yet have the
"with at most one per scheme" qualification.  I think we should, but we
need to be careful, since there are a number of multiple uri scenarios
mentioned.  Here are the four:

1. The mapping server returns two solutions for a given request and
location...

Mapping Client: A Mapping Client interacts with the 
Mapping Server to learn one or multiple URIs for a given location.

2. Though I'm not sure this is Id2's original intent, since there are
various service types are mentioned, could this take the form of
sip:[email-masked] vs. [email-masked] vs.
[email-masked] (or some other combi) that could be provided from
a mapping server?

Id2.  Universal Identifier Resolution: Where multiple 
emergency service types exist, it MUST be possible to treat each 
emergency identifier separately, based on the specific type of 
emergency help requested.

3. The following requirement says nothing of scheme limits.

Ma5.  The mapping protocol MUST allow a response to carry multiple URIs.

4. Here, in fact the scheme would likely be the same, just with two
separate user parts of the PSAP emergency address.

Ma7.  Multiple PSAP URI's:"> The mapping protocol MUST 
be able to return multiple URIs for different PSAPs that cover the same 
area.

SUMMARY:
Number 3 above seems to be the place where such a qualification needs to
live.  Do others agree?

PROPOSED CHANGE to Ma5:
Ma5'.  The mapping protocol MUST allow a response to carry multiple
URIs, and to include the same emergency address if differentiated by uri
scheme.

Motivation: There may be two URIs returned, both an SMS URI and a SIP
URI, which the client can select by choice, based on it's capability
and/or preference setting.

Roger Marshall.

>			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: Ted Hardie <[email-masked]>
Date: Wed, 7 Dec 2005 10:06:36 -0800

>mentioned.  Here are the four:

I believe it was Henning who brought this up initially.  His logic,
if I remember correctly, was that we didn't want the client to have
to order multiple responses for the same URI scheme; the service
should return the best/correct answer for that scheme and any
forwarding or redirection that occurred should take place in the
protocol processing for the scheme.  In the SIP example, the
processing would return something like "sips:[email-masked]";
if that psap were not available, it would be the SIP mechanisms,
not the mapping protocol, that handle the traffic moving to
sips:[email-masked] .

I personally agree with this logic, and I hope others do as well.

>Ma5.  The mapping protocol MUST allow a response to carry multiple URIs.

I would add it here, as "It SHOULD return at most one URI for each scheme
it supports, in order to avoid shifting the burden of discovery back to the
client".

I think SHOULD is the right level here, just to allow for special cases where
multiple URIs are unavoidable or where the scheme has no provision for
forwarding/redirection.  That might, though, cause us to say whether
a return set containing multiple URIs in a single scheme is ordered or
unordered.   I also would have no real heartburn if we said MUST,
and let people draw the conclusion that anything that has no redirection/
redundancy/forwarding might be a bad choice for this use.

				regards,
					Ted Hardie