Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Mar 2007 20:39:17 -0500

I'm editing -framework and resolving comments.

See in line for my responses

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]]
> Sent: Sunday, November 05, 2006 6:55 PM
> To: [email-masked]
> Cc: Henning Schulzrinne; [email-masked]
> Subject: Comments on draft-ietf-ecrit-framework-00
> 
> 
> Hi;
> 
>  Few comments on the draft.
> 
>  1. What is the early URL? I can guess what this is but I think
>     it should be clarified somewhere as it
I removed the "early".  It's just a URI now.
> 
>  2. Section 3, 4th paragraph explains how the proxy(ESRP)
>    would query the LoST server to resolve a Service URN but
>    this is based on the assumption that the URI in the route header
>    addressing the PSAP(assuming we are using the loose-route
>    Jonathan proposed.) is stale. But is it really? And how do we
>    know. There is no indication to show how fresh the psap-URI
>    is. So UA can literally have obtained a new psap-URI just before
>    it initiated an emergency call but according to the draft, ESRP or
>    proxy would still redo the mapping.. Worse yet, because there is
>    no indication that mapping has been accomplished, we may see
>    multiple proxies redoing the mapping as it can't tell if the mapping
>    has been executed already.. I don't know if there is any resolution
>    to this and I actually don't know if this is really a problem but I
> figured
>    I should share my concern..
I'm in the midst of changing the example to be endpoint routed, rather than
proxy routed.  We want to promote the endpoint routed model anyway.  This
should eliminate the confusion in the text.  I think we need an unambiguous
indication that LoST mapping has been done.  We should discuss this point.
 
> 
>  3. Section 5.8 talks about location being validated prior to a device
> placing
>    an actual emergency call. I don't understand what the text is trying
> to say here.
>    How could the validation take place without the actual request?? I am
> probably
>    being stupid here and not fully understanding the text here so
> clarification would
>    be much appreciated.
If you read on, you will see that the real validation is loading the value
IN to the LIS.  The endpoint can revalidate when it gets location (which is
boot time and when it is reading location from the LIS), and any time
thereafter.

> 
>  4. Section 16.5. Call Signaling Integrity I think is better provided by
> SIP-Identity,
>    which can provide over some headers and message body end-to-end over
> TLS
>    which only provides integrity hop-by-hop. You already recommend the
> use of
>    sip-identity to provide caller-authentication, it won't hurt to
> recommend its use
>    to provide signaling integrity.
Well, most of the text talks about maintaining the privacy of the location
header, but I added text for the integrity protection Identity would get
you.

Thanks
Brian

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

---

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Mar 2007 19:01:58 -0800

Brian,

 My comments in-line.

> indication that LoST mapping has been done.  We should discuss this point.
 I agree.
 I think the current direction of how to route and label the emergency 
call was to place Service URN
in R-URI and PSAP URI in the Route header. Problem I see with this is 
that if there are more than
one LoST querying proxy, the recursive LoST query may result in each of 
the LoST server resolving
to the same URI placed in the Route header(time delay, failure at one 
server can mean call failure).

 As PSAP URI is expected to have no constant semantics indicating that 
it's a URI for PSAP, dip
indicator may be needed to prevent this recursive LoST query at every 
LoST querying proxy along
the signaling path.

 However, Henning did point out an interesting point (before or during 
the last IETF). I don't know
if I interpreted his comment properly though... If not Henning please 
clarify what you meant..

 As I understand Henning's idea was to use R-URI/Route header as an 
indicator to trigger the
resolution.

 1. If R-URI is urn:sos and Route header is not the proxy handling the 
message then the proxy is to assume
     the resolution is already done.
 2. If R-URI is urn:sos and Route header is the proxy handling the 
message then the proxy is to conduct
     the resolution if capable.
 3. If R-URI is urn:sos and Route header is empty obviously the 
resolution hasn't been completed thus
     the resolution is necessary if the proxy handling the message is 
capable to do so.

 I don't know how this would work with pre-configured route set and 
service-route etc.
 
> boot time and when it is reading location from the LIS), and any time
Okay.
> header, but I added text for the integrity protection Identity would get
 Apologize for not reading it thorough enough.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 02 Mar 2007 12:05:47 +0100

> server can mean call failure).

They should never resolve to the same URI, as that would presumably 
cause looping. Let's say if the outbound proxy resolves to (PSAP) URL A. 
If A does the resolution and again produces A, you have a problem. No 
amount of identification is going to help with that problem.

Please remember that SIP doesn't just randomly route messages. A proxy, 
except for the outbound proxy, will be named in the R-URL or the Route 
header. Otherwise, it's an error. You can't just expect to send a SIP 
message with a random URL to a proxy and say "please take care of it". 
(Otherwise, we'd have a problem very similar to the open relays in SMTP 
that caused a fair amount of email spam grief until running such an open 
relay would be a one-way ticket to a black list.)

> LoST querying proxy along

See above; this doesn't work and is unnecessary.

>     the resolution is already done.

As noted above, this can only occur if the proxy is an outbound proxy 
(P-CSCF in IMS terminology, I think).

>     the resolution if capable.

Right.

> I don't know how this would work with pre-configured route set and 

Case 2 applies. Details probably require a bit of thought, as there are 
several possible answers, depending on whether that resolving proxy also 
  "flushes" the remainder of the routes if it's in the middle of a route 
list or just adds the PSAP URI to the end of the list, which would be 
the normal behavior. I suspect that this depends a bit on the 
operational environment. Would an operator, for example, want the call 
to visit its service proxies before it heads to the PSAP? Given the 
proclivity of some architectures to tie, say, media authorization to SIP 
signaling, this may be necessary.

In short, I'm opposed to an explicit marking since it would either be 
redundant or insufficient. The latter would occur if multiple mappings 
are done, as you'd have to keep track not just of whether "a" mapping 
has taken place, but which ones and where, essentially re-inventing Via 
or history (4244), depending on the details of how calls are bounced around.

Henning

---

From: Shida Schubert <[email-masked]>
Date: Fri, 02 Mar 2007 19:39:01 -0800

Henning,
>> one LoST querying proxy, the recursive LoST query may result in each 
>> of the LoST server resolving
> cause looping. Let's say if the outbound proxy resolves to (PSAP) URL 
> A. If A does the resolution and again produces A, you have a problem. 
> No amount of identification is going to help with that problem.
>
> Please remember that SIP doesn't just randomly route messages. A 
> proxy, except for the outbound proxy, will be named in the R-URL or 
> the Route header. Otherwise, it's an error. You can't just expect to 
> send a SIP message with a random URL to a proxy and say "please take 
> care of it". (Otherwise, we'd have a problem very similar to the open 
> relays in SMTP that caused a fair amount of email spam grief until 
> running such an open relay would be a one-way ticket to a black list.)

 The source of resolution is location, so I am assuming every time you 
conduct the resolution,
the resolution in fact should resolve to the same URL. So your statement 
about resolution pointing
to a different PSAP URI puzzles me and concerns me a bit.
 If you are calling the fact that resolution for same location-info 
always resolve to the same URI
is a loop, and is a problem then I think we have problem in hand.

 1. Assuming user was roaming from a hotel.
 2. User ends up with record-set for outbound proxy of the hotel and 
home proxy.
 3. UA does the LoST resolution and forwards the request to outbound proxy.
 4. Outbound proxy does the LoST resolution and forwards the request to 
the next route(home proxy).
 5. Home proxy does the LoST resolution and forwards the request to the 
next route(hopefully PSAP).

 I think what's illustrated above can easily happen. I may be 
misunderstanding something very fundamental
and if so, I do appreciate it if you can aid me so I have the right 
understanding.

 As I was thinking about this, another question I had was if there are 
more than one LoST querying proxy
on the signaling path what happens when each LoST querying proxy uses 
different location information
contained in the request. 

 Assuming I was in Prague, connecting to my home proxy via VPN and my UA 
obtained location from
  1. GPS (geo-location[Prague])
  2. DHCP (civic-location[Czech])
 and home proxy inserted location reference (may be civic-location[North 
America])

 Each of the location may be different enough that resolution for each 
of the location may resolve to a different
PSAP URI. And if the behavior of proxy for the resolved URI is to push 
it into the route-set, the request may end
up with 3 Route entry each destined for different PSAPs.  Probably not a 
problem, as I understand PSAP operator
always ask for the physical location to the caller..

 Regards
  Shida

> Case 2 applies. Details probably require a bit of thought, as there 
> are several possible answers, depending on whether that resolving 
> proxy also  "flushes" the remainder of the routes if it's in the 
> middle of a route list or just adds the PSAP URI to the end of the 
> list, which would be the normal behavior. I suspect that this depends 
> a bit on the operational environment. Would an operator, for example, 
> want the call to visit its service proxies before it heads to the 
> PSAP? Given the proclivity of some architectures to tie, say, media 
> authorization to SIP signaling, this may be necessary.
>
> has taken place, but which ones and where, essentially re-inventing 
> Via or history (4244), depending on the details of how calls are 
> bounced around.
>
> Henning
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 03 Mar 2007 10:00:25 +0100

> the resolution in fact should resolve to the same URL. So your statement 

Not necessarily. The idea, discussed on this list, would be that you do 
incremental resolution:

location -> national ESRP uses location to derive -> state ESRP, which 
uses location to arrive at actual PSAP

Thus, you might have the URLs

[email-masked]
[email-masked]
[email-masked]

along the way.

> 
> Each of the location may be different enough that resolution for each of 
> the location may resolve to a different

Note that the route will only be pushed once the call actually reaches 
that destination, unless each intermediary decides to do resolution from 
scratch. Even in that case, there will be somewhat rational behavior in 
that the call will arrive at the PSAP that has been identified first, 
with some additional Route's left over.

---

From: Shida Schubert <[email-masked]>
Date: Sat, 03 Mar 2007 12:25:59 -0800

Hmm.. Interesting..

 I understand how this would work once it gets into the ESRP domain(or
network or whatever you want to call it), to find a finer grained 
resolution.

 What I want to know is if I am understanding correctly whether UA,
hotel proxy and home proxy when conducting a LoST query on say, civic 
location
obtained through DHCP, that it would resolve to a same URI(PSAP or ESRP..)?

 If not I am totally LoST..

 Regards
  Shida

Henning Schulzrinne wrote:
> Not necessarily. The idea, discussed on this list, would be that you 
> do incremental resolution:
>
>> PSAP URI. And if the behavior of proxy for the resolved URI is to 
>> push it into the route-set, the request may end
>> up with 3 Route entry each destined for different PSAPs.  Probably 
>> not a problem, as I understand PSAP operator
> that destination, unless each intermediary decides to do resolution 
> from scratch. Even in that case, there will be somewhat rational 
> behavior in that the call will arrive at the PSAP that has been 
> identified first, with some additional Route's left over.
>
>
>>
>> Regards
>>  Shida
>>
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 03 Mar 2007 21:40:05 +0100

> obtained through DHCP, that it would resolve to a same URI(PSAP or ESRP..)?

Yes, like you said - it would be rather odd (and some kind of fault) if 
they didn't. There are various disclaimers about caching behavior, 
roundtrip delays while databases are being updated, etc, but I don't 
think you were worried about that...