Re: [Geopriv] Location in SIP and "retransmission-allowed"

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Wed May 09 2007 - 11:30:28 EDT

On May 9, 2007, at 11:06 AM, Richard Barnes wrote:

>> (1) The URI is a normal SIP destination, which performs no
>> routing. No flag of any sort is needed since no proxy is trying to
>> use any location information for anything.
>
> That's not necessarily true. As you've said before, the standard
> way for a proxy to verify that the R-URI is a PSAP is to use the
> location in a LoST query. You can imagine similar situations for
> non-emergency cases.

Interesting example. You just provided a very good toll bypass
mechanism: Mark an emergency call as 'don't lookup location', but the
URL is grandma@example.com. What, other than failing the call, do
you expect the VSP to do in that case?

>
>> (2) The URI is either a service URN or another URI that needs
>> further routing. In that case, any flag is useless since the call
>> will fail without it. Thus, the flag or indication offers no
>> additional privacy, unless you consider call failure privacy.
>
> In this case, the UAC has explicitly contradicted itself: It has
> asked for location-based routing, when it is not willing to allow
> its location to be used in that way. It makes sense for such a
> request to fail (e.g., with a 485/Ambiguous or a new 48X/Privacy-
> restricted).
>
> This is the correct behavior in non-emergency cases (such as Ted's
> use case), since the user has asked for his location not to be
> passed outside the signaling path, as LoST would cause it to be.
> The UAC can always retry with different privacy settings.

This kind of works. I just fail to see the practical privacy
advantage of that. You have yet to identify a case where a call
succeeds and the privacy is improved by this mechanism.

>
> --Richard
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 9 May 2007 11:30:28 -0400

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 11:28:52 EDT