Re: AW: [Geopriv] Location Presence Event Package

On 21/04/07, Pailer Rudolf <[email protected]> wrote:
> 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.

What kind of interoperability problem?

Please also note that you can extend RFC4660.

Hisham

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


_______________________________________________
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