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

From: Moore, Lyn E ^lt;>
Date: Tue May 01 2007 - 20:30:40 EDT

To pick up on Martin's point. Currently, PSTN location-based routing
occurs via SS7 and "phone number to Address" database lookups internal
to a telco. I would consider that in a SIP environment that Martin's
pizza example would still be carried out as location-based routing
"in-bound" calling application within a telco. This could take the form
of an IMS Application Server that processes in bound calls to the
nearest pizza hut and routes them to the nearest one. Other IMS
Application Servers could be used in conjunction to provide the relevant
location information in the correct format, all within the telco
environment. I assume this will be an "unpopular" point of view.

Lyn Moore

-----Original Message-----
From: Dawson, Martin []
Sent: Wednesday, 2 May 2007 10:13 AM
To: Henning Schulzrinne; Richard Barnes
Cc: Ted Hardie;; Rosen, Brian
Subject: RE: [Geopriv] Location in SIP and "retransmission-allowed"

I'd submit that perhaps the important issue is who are considered to be
the peer parties in the communication. That is, should the location
information only be regarded as part of the session layer establishment
or does the sender intend that its context exist in the application
layer as well.

Clearly, in Brian's example, the intended use of the location
information is for routing - that is the session layer establishment to
the correct end node. Does the user intend the location information to
be forwarded in that context? The answer is "yes" to the extent that it
is necessary to establish the session. So, the proxy may need to forward
the location information if such forwarding is necessary to complete the
session establishment. It shouldn't be necessary for it to be sent to
the final point associated with the connection.

Do the proxies, etc, know that this is a Pizza Hut call? I doubt it.
Once the session is established the end point now has a peer
relationship with the Pizza Hut franchise. The latter would like the
location information in order to be able to deliver the product to a
paying recipient (btw, at this stage they may care more about the
integrity of the source of the location information). This is an
application layer consideration - it just happens to care about location
but, just because it's nominally the same quantity used in the session
establishment, it doesn't mean it should be extracted from the same
parameter used in the session layer.

To further highlight this, the form of location suitable for the session
layer may actually be geodetic where the application layer may actually
prefer civic. While the nominal quantity is the same thing, the form and
attributes suitable to each context may be different.

It would certainly be nice if, given an established session, there was
now an application layer associated with location information exchange
(including appropriate form and integrity) between the peers. Having to
second guess this application requirement in the session establishment
layer is what, I think, leads to the pain.

Perhaps it would cause less contortion if the role of SIP was clearer -
even for the use case presented. Is it only for session initiation, or
does it represent some other application function and, if so, what are
the boundaries of that? If it does go beyond the initiation phase, then
perhaps the semantics for further location information exchange belong
to a different set of messages.


-----Original Message-----
From: Henning Schulzrinne []
Sent: Wednesday, 2 May 2007 9:42 AM
To: Richard Barnes
Cc: Ted Hardie;; Rosen,Brian
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

Your example seems to assume that the flag adds privacy by being set.
Unfortunately, that's not the case.

In your example, the privacy-conscious (emergency) caller will say 'no'.
Let's assume that we have the standard two-stage routing (local
+ emergency services network). The call reaches the ESN and the flag
indicates "sorry, no LoST". In this case, the only alternative is to
fail the call. It's not like the LoST lookup is some optional frill for
this call. Thus, the call will fail and, if you're lucky, the UA will
retry, presumably after displaying a warning message to the user to the
effect that no call will go through until they click off on the privacy
release. The outcomes are thus exactly the same with or without the
flag: a successful call, but no additional privacy, or no call.

The hypothetical disclosure of information you mention is in no way
prevented by having this flag set to 'no', even if all entities in the
call path observe the flag. The correct way to protect privacy is to
privacy-protect the signaling channel or, if you're truly paranoid, do
bogus LoST queries to obfuscate real ones.

The same is true for the pizza call, so this does not depend on the
specific example.


On May 1, 2007, at 6:12 PM, Richard Barnes wrote:

> Perhaps location information, by itself, devoid of all context, has no

> privacy implications. But in practice, there's always context.
> If I see a LoST query go by containing a location, I can infer that
> there's something at that location, and probably something capable of
> calling for emergency services. If I want to jam emergency calls in
> an area, LoST queries give me enough information to know where to put
> my jammers. Or if I'm watching a stream of periodic LoST queries, and

> I see one go outside the usual pattern, then I know the location of
> someone making an emergency call.
> I have to agree with Ted: No means no, and when there are exceptions,
> they should be made explicit.
> --Richard

Geopriv mailing list

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

Geopriv mailing list

Geopriv mailing list
Received on Wed, 2 May 2007 10:30:40 +1000

This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 20:30:56 EDT