Subject: Re: [SIP] geographical location

From: <[email-masked]>
Date: Wed, 28 Feb 2001 18:55:25 +0100

Hi, jiri, thank you. Comments below

[email-masked] wrote:
>> IF (AND ONLY IF) there are not means for a UA to obtain geographical
>> coordinates on a real time basis BY ITSELF (i mean without interacting
with
>> the cellular network) then it means if you want to provide such services
>> you WILL BE FORCED to do a translation in the visited cellular network
in
>> terms of:

>I think this is a possible solution but not the only one. There are
solutions
>which do not require the coordinate translation logic to be built in
>SIP proxies. Which I would actually like to avoid as it may have some
>tricky side-effects, for example failure if encryption is used or
>used outbound proxy is not able to perform a correct translation.

Well, I see what you mean. See I just mention "... translation in the
visited cellular network..." so it sounds quite generic for me (SIP server,
application server, etc.). I am too new in SIP to suggest the right entity.
Your arguments, anyway, sounds to me quite appropriate.

>The other solutions could be in order of my preference
>1) having a "where am I" service in the access network (which performs
>   exactly the same translation logic but enables end-devices to insert
>   geo-coordinates)

Ummm, are you suggesting not to include the location info. in the session
establishment but to offer a server in the visited network to perform
location queries? This is LCS, and for some scenarios it is the best
option. Anyway any realtime response will depend on the location technology
deployed in the visited network (assisted GPS, triangulation takes some
seconds, Cell-Id doesn´t)

>2) having the translation logic in end-devices

Does it mean the translation is to be performed on the end-device that
establishes the call?

Probably the easiest scenario would be
a)to offer a public match between Cell-Ids and geographical coordinates
b)include in the Cell-Ids structure the geographical coordinates

Anyway no Cellular Operator has offered such information as far as i know.
By the way visited operators could change slightly the geographical
coordinates every time a Cell-Id is translated in order to hide the exact
position of their radio systems to competitors. That's more or less what
the US goverment used to do with GPS in every positioning query:(

For everyone interested in location staff, i would recommend to read the
different scenarios described in LCS architecture (mobile originated
queries, third party originated queries, call-related, non-call-related)
and also the ones covered by CAMEL Phase 3 (subscription to Presentity and
location-changes) and SoLSA (location-based billing). Every different
scenario requires different performance in terms of accuracy, traffic
volume, real time constraints, authorisation, etc. and also targets
different needs. LCS is primary for E911, so LCS servers do not handle
heavy traffic, are more focused on accuracy rather than real-time. CAMEL
Phase 3 is based on Cell-Id and offers call-related location info, presence
& location-change notifications, so CAMEL "servers" will handle heavy
traffic, are more focused on real-time rather than accuracy. SoLSA covers
location-based billing and is a more network-centric vision than the
others.

>> INVITE [email-masked]?cellid=lewkjf
>> into
>> INVITE [email-masked]?latitutude=x;logitude=y;elevation=z
>>
>> actually IF a translation is required I would rather prefer to handle
this
>> location info in a specific header.

>In fact, the syntax above indicates headers. I like the ability to
>specify header field values in URLs. Location information actually
>identifies services and this is what URLs are used for in a protocol-
>independent manner. For example, it allows the following link to be
>included in a webpage:
>  Turkey:
>  Look at    <a
href=http://www.hotel.com?latitutude=40N;longitude=32E>hotels</a>
>  and call a <a
href=sip:[email-masked]?latitutude=40N;longitude=32E>
>         reservation office</a>
>Jiri

I must agree with you.

By the way, SIP proxies can change URLs. Is that correct?
3GPP seems to have defined a kind of Visited Proxy Server/Outbound Proxy :)
Anyway, as you mention, visited network real time translation is not the
best solution with encryption scenarios

regards
javier f.

-----------------------------< O >-----------------------------------
Javier Ferreiro Garcia
Consultant
Telefonica Moviles Spain
Div. de Nuevos Productos/Voice Services Unit
    Telf.: +34 630 00 43 13
-----------------------------< O >-----------------------------------

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 01 Mar 2001 02:13:53 +0100

[email-masked] wrote:
> location queries? 

    cell phone           "where am I" service              SIP destination
       |                       |                                      |
       |      "where am I (d)?"|                                      |
       | --------------------->|                                      |
       |      x,y,z            | d->x,y,z                             |
       | <---------------------|                                      |
       |      INVITE a@b?geo-info=xyz                                 |
       | ------------------------------------------------------------>|

> Anyway no Cellular Operator has offered such information as far as i know.

Is this such a hard problem? If the operators do not offer this information, 
after-market competitors may possibly do this job as well. There are
actually websites (sorry, I cannot find an illustrating bookmark right
now) that maintain such translation info.

[...]

> By the way, SIP proxies can change URLs. Is that correct?

"The Request URI MAY be re-written by proxies". (2543bis, Section 4.3)

Regards, Jiri