AW: [Geopriv] Location Presence Event Package

Hello Brian!
 
Sorry, that it took me some time to reply to your mail.
 
We looked at RFC 4660 that defines event notification filters for
presence, but did not see a feasibile way to express the following rule:
"Send a notification, if the presentity enters an area (e.g. specified
by a circle (center point + radius) or a rectangle)."
There was e.g. the proposal in our research group to use presence event
filters in the following way:
<changed from="-67.563 -13.834" by="0.2 0.2">
We think that such a notation is highly ambigous and will lead to
interoperability problems.
 
RFC 4660 builds on the assumtion that the state space of presence is
restricted to a few logical states that can be filtered by a boolean
combination of filter rules. The location presence event package
notifies on geographical positions, that have an (nearly infinite) state
space. Combining geograhical shapes in boolean terms and calculating if
the presentity is now inside/outside of this area is not feasible on
mobile devices with restricted computation resources.

Therfore we propose to use some different kind of filtering approach
(see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.tx
t).

Now there is the question, why not to use geopriv-loc-filters inside the
presence package:
Our main goal is to route SIP SUBSCRIBE messages containing
geopriv-loc-filters documents from the watcher to the presentity. The
location presence event package is targeted at mobile devices and we
argue that filters have to be executed on the mobile device (otherwise
you will no be able to restrict the number of notification messages on
the radio interface). This means that the subscription cannot be
processed by a (conventional) presence server in the network, but has to
be routed to the mobile phone of the user (but only to those mobile
phones, that have an edge presence server running).
Location presence subscriptions and notifications are processed by
different nodes than conventional presence. The scale of location
presence data may be significatly different to conventional presence.
This means that SUBCRIBE and NOTIFY messages have to take different
paths in the network and will be processed by different nodes than
conventional presence.
We thus discussed several methods, to differentiate the routing of
conventional presence to location presence:
	1) Introduce another URI-scheme. This does not seem to be as
elegent as the introduction of the locpres event package.
	2) The edge presence server on the mobile device registers with
an own SIP URI. This requires a lot of a priori knowledge of the
watcher.
	3) define an own event package - we favored this solution

The idea of the locpres event package is, that it uses the same
framework than conventional presence (e.g. for user profiles, policy
decisions etc.), but that it indicates that this type of presence has to
be routed and processed differently than conventional presence. 
Thus SIP routing of initial SUBCRIBE messages can be based on the
content "locpres" of the SIP Event header field. This solution seems to
integrate well in the existing SIP presence framework and general SIP
specifications. Presence user agents can for example use the "Watcher
Information Event Template-Package" [RFC 3857]. This means that the
Presence User Agent can subscribe to "locpres.winfo" notifications in
order to be notified about changes in the subscription state regarding
locpres events. 
Furthermore [RFC 3840] introduces "User Agent Capabilities" in form of
feature tags that can be conveyed in form of parameters in the Contact
header field to other user agents and registrars. In particular a
Contact header with the sip.event media tag containing a value of
"locpres" can be used by a Presence User Agent to indicate that
subscriptions for location presence data shall be routed to this
address. Sip.event feature tag parameters are also used in [RFC 3841]
that defines the notion of "caller preferences" about request handling
in servers. These preferences include the ability to select which
Uniform Resource Identifiers (URI) a request gets routed to, and to
specify certain request handling directives in proxies and redirect
servers. Again a value of "locpres" in a sip.event media feature tag can
be used by a presence server to route a subscription for location
presence data to the responsible edge presence server or state agent.

greetings
Rudolf

________________________________

Von: Brian Rosen [mailto:[email protected]] 
Gesendet: Montag, 09. April 2007 13:35
An: Pailer Rudolf; [email protected]; [email protected]
Betreff: RE: [Geopriv] Location Presence Event Package



I've read this, and I don't really understand why real presence (with
the filter package) doesn't provide the same service.

Can you give an example where presence+filter is significantly different
from this package, with the filter inclusion?   It seems to me that you
get roughly the same number of messages, with roughly the same content.

 

Brian

 

________________________________

From: Pailer Rudolf [mailto:[email protected]] 
Sent: Monday, April 09, 2007 1:57 AM
To: [email protected]; [email protected]
Subject: [Geopriv] Location Presence Event Package

 

Hello! 

I would like to notify you about the the Internet Draft "A Location
Presence Event Package for the Session Initiation Protocol (SIP)".

http://www.ietf.org/internet-drafts/draft-pailer-locpres-00.txt
<http://www.ietf.org/internet-drafts/draft-pailer-locpres-00.txt>  

The draft describes the usage of the Session Initiation Protocol (SIP)
for subscriptions and notifications of location presence. Location
presence is information about the geographical position of a user.
Subscriptions and notifications of location presence are supported by
defining an event package within the general SIP event notification
framework.

The concept of a SIP based location enabler that is the core of the
proposed draft was published on several occasions: 
*) A Terminal-Based Location Service Enabler for the IP Multimedia
Subsystem, R. Pailer, S. Bessler, F. Wegscheider, IEEE Wireless
Communications and Networking Conference April 2006 (WCNC06), Las Vegas,
USA

*) Terminal-Centric Location Services for the IP Multimedia Subsystem,
J. Fabini, M. Happenhofer, R. Pailer, IEEE 63rd Vehicular Technology
Conference, May 2006, Melbourne, Australia

*) Implementing a Native IMS Location Service Enabler over a
Prototypical IMS Core Network Testbed, P. Reichl, S. Bessler, J. Fabini,
R. Pailer, J. Zeiss,The Third IEEE International Workshop on Mobile
Commerce and Wireless Services (WMCS'06) June 26, 2006, San Francisco,
USA

*) Practical Experiences with an IMS-Aware Location Service Enabler on
Top of an Experimental Open Source IMS Core Implementation, P. Reichl,
S. Bessler, J. Fabini, R. Pailer, A. Poropatich, N. Jordan, R. Huber, H.
Weisgrab, C. Brandner, I. Gojmerac, M. Ries, F. Wegscheider, Journal of
Mobile Multimedia, Rinton Press, Fall 2006

*) Lecture Notes in Geoinformation and Cartography, Location Based
Services an TeleCartography, G. Gartner, W. Cartwright, M. P. Peterson
(Eds.), Springer, 2007

I can provide above documents in PDF format, if needed. 

Feedback from the IETF Working Groups GEOPRIV and SIPPING would be
appreciated very much indeed. 

greetings 
Rudolf 



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP