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

From: "Roger Marshall" <[email-masked]>
Date: Mon, 5 Dec 2005 15:56:11 -0800

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

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 6 Dec 2005 15:03:20 -0800

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

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

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 6 Dec 2005 16:46:32 -0800

James:
Your explanation makes sense to me.  Allow the use of tel:uri at the
"edge" (e.g. UA-to-ESRP), but don't let it be used in std core SIP
signaling.  Did I understand this to be your point?

Assuming this is the case, the inclusion of the MUST/MAY language would
turn the paragraph into a real requirement, something that doesn't
belong in the Intro section.

Also, Rohan's suggestion of removing tel:uri from the "emergency
address" defn makes more sense too, and I think is warranted, as
"tel:uri" is used nowhere else in the document.

Question remains, what should this paragraph say, is it still necessary
as written, and if so, where do we place it.

Roger Marshall

>Sent: Tuesday, December 06, 2005 4:21 PM
>To: Roger Marshall; Marc Linsner; [email-masked]; [email-masked]
>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:
>> >> > 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 
>> >>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.
>> >
>state that 
>> >conversion is necessary to make the message routable.  This is an 
>> >extra step that is less desired.
>> >
>> >
>> >> > order for motivation to work towards the most secure solution.  
>> >> > It does not dismiss tel:uris, it just says they are not 
>preferred.
>> >>
>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-
>> >
>

---

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

Roger

>signaling.  Did I understand this to be your point?

yep

>belong in the Intro section.

you're right, lower case all the requirements words then to keep the meaning.

>as written, and if so, where do we place it.

I think so, but I haven't looked for a propoer place within the Intro yet.

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 7 Dec 2005 17:09:48 -0800

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

>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]
>At 6:21 PM -0600 12/6/05, James M. Polk wrote:
>>Roger
>>
>>"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, 
>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'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.
>>
>>The nut of this discussion is what the ESRP gets back from 
>the mapping server.
>>
>>>goal, not every PSAP will have IP based connectivity right away, so 
>>>the URI scheme is not fixed.  Given these conditions, alternate URI 
>>>schemes,
>>>

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 7 Dec 2005 17:18:08 -0800

Works for me.  Thanks.

Roger.

>Sent: Wednesday, December 07, 2005 5:01 PM
>At 4:45 PM -0800 12/7/05, Roger Marshall wrote:
>>
>>NEW (PROPOSED) REQUIREMENT:
>>
>>Ma5x.  When multiple URIs are returned, the mapping protocol SHOULD 
>>differentiate multiple URIs by use of different URI schemes.
>
>Sorry, but I think this doesn't quite capture it.  This sounds 
>like a server wanting to return multiple URIs should 
>differentiate them by scheme (e.g. assign one to sip and one 
>to sips), where what we want to say is that servers may return 
>multiple URIs when the PSAP supports multiple contact 
>protocols, but should return only one per protocol, to avoid 
>the client getting muddled. 
>Proposed replacement text:
>
>Ma5x.  The mapping protocol MAY return multiple URIs.  It 
>SHOULD return only one URI per scheme, so that clients are not 
>required to select among different targets for the same 
>contact protocol.
>
>Motivation:  There may be two or more URIs returned when 
>multiple contact protocols are available (e.g. SIP and SMS).
>The client may select among multiple contact protocols based 
>on its capabilities, preference settings, or availability.
>
>Does this replacement text work  for you?
>			regards,
>				Ted
>
>>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.
>>
>>Are the other (existing) requirements sufficient to address use cases 
>>where same schemas might be returned if unavoidable?
>>
>>Please comment if objectionable.
>>
>>
>>Thanks.
>>
>>Roger Marshall
>>
>>
>>
>>>Sent: Wednesday, December 07, 2005 10:07 AM
>>>To: Roger Marshall; James M. Polk; Marc Linsner; [email-masked]; 
>>>[email-masked]
>>>At 5:24 PM -0800 12/6/05, Roger Marshall wrote:
>>>>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:
>>>
>>>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.
>>>
>>>
>>>>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.
>>>
>>>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
>>>
>
>