Subject: RE: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 19 Jan 2006 08:50:05 -0600

Assuming that the OPTIONS mechanism (described in Section 8.2.2 of draft-ietf-sip-location-conveyance-01.txt) exists, there's really nothing you can do to prevent any party you call from sending this request. The question is, what does your SIP endpoint do with the request when it gets it? If your SIP endpoint is configured to always return a 488 reply, then your privacy remains uncompromised, and (going back to the example of what a server that recognizes an emergency call might do) your emergency call gets routed according to your emergency location of record. On the other hand, some people may not really care if their location is known when they call somebody, and may have their SIP endpoint respond to such a query with an OK and the location info. Since this is all under the control of the person who manages the SIP endpoint, I'm not sure I see the privacy issue.
Barbara

-----Original Message-----
From:	Henning Schulzrinne [mailto:[email-masked]]
Sent:	Wed 1/18/2006 4:56 PM
To:	Stark, Barbara
Cc:	[email-masked]
Subject:	Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers
> (e.g., a saved emergency address on file). It might be useful to
> recommend that a server which recognizes an emergency call should send
> the VoIP end device a request for location (OPTIONS request?), just in
> case the device does know the location, but didn't know it was an
> emergency call.

Unfortunately, this clearly has privacy implications. How do you prevent 
  any party I might be calling from sending a "send me your location" 
request?

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Jan 2006 10:00:46 -0500

The problem is default configuration. I presume we'd want systems to  
be configured by default to be secure and privacy-safe, i.e., refuse  
the request without explicit user (GUI) approval. GUI approval isn't  
nearly as helpful for emergency calls. Thus, in practice, either all  
systems would be privacy-unsafe out of the box or this mechanism  
would fail in an emergency. I don't think forcing users to give up  
location privacy for all calls (or manually twiddling configuration  
options before each call) just so that emergency calls work is an  
acceptable design.

I think labeling emergency calls is a much better option and follows  
the general SIP design principle of declaring, rather than inferring,  
intent.

I believe the dial-plan issues are solvable for the vast majority of  
cases, although I agree that we need to specify behavior sufficiently  
well to achieve desirable outcomes. Your mechanism fails to protect  
the user's privacy; the labeling mechanism fails under rather obscure  
circumstances for calls that few people care about. (I can't remember  
ever having called the international operator...)

On Jan 19, 2006, at 9:50 AM, Stark, Barbara wrote:

> Assuming that the OPTIONS mechanism (described in Section 8.2.2 of  
> draft-ietf-sip-location-conveyance-01.txt) exists, there's really  
> nothing you can do to prevent any party you call from sending this  
> request. The question is, what does your SIP endpoint do with the  
> request when it gets it? If your SIP endpoint is configured to  
> always return a 488 reply, then your privacy remains uncompromised,  
> and (going back to the example of what a server that recognizes an  
> emergency call might do) your emergency call gets routed according  
> to your emergency location of record. On the other hand, some  
> people may not really care if their location is known when they  
> call somebody, and may have their SIP endpoint respond to such a  
> query with an OK and the location info. Since this is all under the  
> control of the person who manages the SIP endpoint, I'm not sure I  
> see the privacy issue.
> Barbara
>