Subject: Re: [SIP] geographical location

From: <[email-masked]>
Date: Mon, 26 Feb 2001 13:45:59 +0100

hi, jiri, thank you
some comments below

>Maybe I missed some substantial point but I do not
>understand why users and their applications should
>be willing to deal with some technology-dependent
>geographical format. I really cannot expect
>a Web/SIP server to understand coordinations expressed
>in a format used by my local wireless company.

NO, we are not willing to use technology-dependent formats, but with the
already existing technologies, in some scenarios (like real-time) we are
forced to handle such "strange" formats and need network-based real-time
translations.

>Geographical coordinates (latitude, longitude, elevation
>and precision) will not change. Technological coordinates
>(my GSM cell id) or civil names ("Europe Blvd" formerly
>"Lenin Blvd" formerly "Stalin Blvd" formerly "Hitler
>Blvd" in the city where I was born.) will.

Yes, geographical coordinates is the goal I think ALL OF US are willing,
the point -at least for me- is IF the UA itself can by itself include
geographical coordinates on all different cellular scenarios. I know if the
UA includes GPS funtionality it will provide this info for you, the problem
is that it will take a couple of minutes for GPS to get this info. Does it
mean that the INVITE needs to be delayed for such a long period? If it
takes so much time for the UA with GPS capabilities to offer this kind of
info this means it will be only valid for non-real time services (i.e. I am
traking you on the web, you send me after two minutes your geographical
position obtained via GPRS)

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:
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.

I hope this clarifies why we started discussing about "strange" Cell-Id
codes. See I have always mentioned "...IF a translation is required...",
"...in certain scenarios..."

regards
javier

>I'd really prefer conveying *geo-coordinates* in web/sip
>requests, regardless how they were obtained, what their
>original encoding was and what the application dealing with
>them is.

>I do not think that they should be bound to a specific
>request method (like previously SUB-NOT or REGISTER were
>mentioned.) Something like
>INVITE [email-masked]?latitutude=x;logitude=y;elevation=z
>would be useful as well.

>Jiri

_______________________________________________
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.

_______________________________________________
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: Wed, 28 Feb 2001 17:52:43 +0100

> you WILL BE FORCED to do a translation in the visited cellular network in

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.
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)
2) having the translation logic in end-devices

> 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