RE: Re: [Geopriv] SIP LocationConveyance: dereferencing location-by-reference
"Thomson, Martin" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
> -----Original Message----- > From: Henning Schulzrinne [mailto:[email protected]] > Sent: Thursday, 20 July 2006 3:01 AM > To: Andrew Newton > Cc: [email protected]; [email protected]; James M. Polk > Subject: Re: [Sip] Re: [Geopriv] SIP LocationConveyance: dereferencing > location-by-reference > > I suspect we're talking about two different use cases: > > - proxies will find subscriptions rather tedious when doing call routing > (do a SUBSCRIBE, wait for authorization, NOTIFY just to get a location > to route a call?), and don't get any benefit from the subscription model; > > - UASs will find subscriptions helpful, in some limited circumstances > (e.g., if I call OnStar for directions, they might want to see where I'm > going in real time, rather than where I was five minutes ago while all > their agents were busy assisting other customers) I disagree - this sort of system is, in effect, provided by a cellular network. For Phase II, PSAPs are, in effect, given a reference to location information (through the callback number, and, in the US, the chain through the ALI). > I don't see particular security issues as long as the UAC realizes that > any subscription URI that it hands out might be used by anybody that is > on the call path. In some cases, that's an acceptable model, > particularly if the caller identity is obscured, so that you only know > that "random caller abc17 is at location X waiting for tow truck". (In > that case, subscriptions are probably somewhat pointless.) > > In short, I think we should allow all of these and simply make sensible > recommendations, such as that location information meant for call > routing should NOT just use subscriptions and also provide location > by-value/by-attachment, simply because location subscriptions are too > painful and useless for proxies in practice. > I am happy with that conclusion. Keep the basic element simple, and provide guidance so that it isn't misused. ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip