Filtering Location Notifications in the Session Initiation
Protocol (SIP)Individualrohan@ekabal.comNeuStar470 Conrad Dr.MarsPA16046US+1 724 382 1051br@brianrosen.netNokia Siemens NetworksLinnoitustie 6Espoo02600Finland+358 (50) 4871445Hannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.at
RAI
GEOPRIVI-DInternet-DraftgeoprivlocationThis document describes filters that limit asynchronous location notifications to
compelling events, designed as an extension to RFC 4661, an XML-based format for event
notification filtering, and based on RFC 3856, the SIP presence event package. The resulting
location information is conveyed in existing location formats wrapped in the Presence
Information Data Format Location Object (PIDF-LO). Conveying location information encapsulated with a PIDF-LO
document within SIP is described in .
An alternative signaling approach, which uses asynchronous communication, is available with
the SIP event notification mechanisms (see RFC 3265 ). This document
focuses on the event notification paradigm. Event notifications are technical more complex
since location may be measured as a continuous gradient and unlike notifications using
discrete-valued quantities, it is difficult to know when a change in location is large enough to
warrant a notification. Event notifications can be used with
filters (see RFC 4661 ) that allows the number of notifications to
be reduced. The mechanism described in this document defines an extension to RFC 4661 , which limits location notification to events that are of relevance to
the subscriber. These filters persist until they are changed with a replacement filter. The frequency of notifications necessary for various geographic location applications
varies dramatically. The subscriber should be able to get asynchronous notifications with
appropriate frequency and granularity, without having to issue a large number of
notifications that are not important to the application. This document defines a new event filters and describes others using existing mechanisms
that may be relevant to a subscriber in the context of location filtering:the Device moves more than a specified distance since the last notification (see ).the Device exceeds a specified speed (see ).the Device enters or exits a region, described by a circle or a polygon (see ).one or more of the values of the specified address labels have changed for the location
of the Device (see ). For example, the value of the
<A1> civic address element has changed from 'California' to 'Nevada'.the type of location information being requested (see ).the rate at which location information delivery is desired (see ).This document builds on the presence event package , i.e. an
existing event package for communicating location information inside the PIDF-LO. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119.This document reuses terminology from .This specification builds on top of a number of other specifications, as noted in . In order to reduce the number of options (and thereby decrease
the chance of interoperability problems), the functionality of
listed in the sub-sections below MUST be implemented, namely the <ns-bindings> (see
Section 3.3 of ), the <filter> (Section 3.4 of ), and the <trigger> (Section 3.6 of
excluding the functionality of the <added> and <removed> element). The <moved> element MUST contain a value in meters indicates the minimum
distance that the resource must have moved from the location of the resource since the
last notification was sent in order to trigger this event. The distance MUST be measured
in meters absolutely from the point of last notification. The <moved>
element MUST NOT appear more than once as a child element of the <filter>
element. Speed changes can be filtered with the help of RFC 4661 and the functionality provided in
, which extends the PIDF-LO with
support for spatial orientation, speed, heading, and acceleration. The value of
<speed> in and MUST be
defined in meters per second. shows an example for a trigger that fires when the speed
of the Target changes by 3 meters per second.An implementation MUST support the functionality as shown in with <ns-bindings> replacing the prefix. No other variant is supported. The
<changed> element comes with a few attributes but only the 'by' attribute
MUST be implemented by this specification.Changes in values, for example related to civic location information, is provided by the
base functionality offered with RFC 4661 utilizing the <changed> element. shows an example where a notification is sent when the
civic address tokens A1, A2, A3, or PC change (all 4 must change in order to let the
<trigger> element evaluate to TRUE).
In times where it is desireable to know if any one individual of a list of CAtypes change,
then they have to be put into separate <changes> filters to ensure you are
notified when any of the element values change.
The following example illustrates a filter that triggers when the Target's location
changes from 'FR' (France) to some other country.An implementation MUST support the functionality as shown in with <ns-bindings> replacing the prefix. No other variant is supported. The
<changed> element comes with a few attributes and the 'by', 'to' and 'from'
attribute MUST be implemented to support this specification. The <enterOrExit> condition is satisfied when the Target enters or exits a
named 2-dimensional region described by a polygon (as defined in Section 5.2.2 of ), or a circle (as defined in Section 5.2.3 of ). The <enterOrExit> element MUST contain either a polygon or a circle as a child
element. The <enterOrExit> element MUST NOT have more than one polygon
and/or circle. If the Target was previously outside the region, the notifier sends a notification when
the Target's location is within the region with at least 50% confidence. Similarly, when a
Target starts within the region, a notification is sent when the Target's location moves
outside the region with at least 50% confidence. Note that having 50% confidence that the Target is inside the area does not correspond
to 50% outside. Confidence that the location is within the region, plus confidence that
the location is outside the region cannot be 100%. The total confidence depends on the
confidence in the original location, which is always less than 100% (95% is recommended in
). The benefit of this is that notifications are naturally
limited: small movements at the borders of the region do not trigger notifications. shows filter examples whereby a notification is sent
when the Target enters or exits an area described by a circle and describes an area using a polygon. The <locationType> element MAY be included as a child element of the
<what> element and it contains a list of location information types that
are requested by the subscriber. The following list describes the possible values: The Notifier SHOULD attempt to provide LI in all forms available to
it.The Notifier SHOULD return a location by value in the form of a
geodetic location. The Notifier SHOULD return a location by value in the form of a
civic address. The Notifier SHOULD return the requested location type or types. The location types the
Notifier returns also depends on the setting of the optional 'exact' attribute. If the
'exact' attribute is set to "true" then the Notifier MUST return either the requested
location type or no location information. The 'exact' attribute does not apply (is
ignored) for a request for a location type of "any". In the case of a request for specific locationType(s) and the 'exact' attribute is
"false", the Notifier MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location type.If the <locationType> element is absent, a value of "any" MUST be assumed
as the default. The Notifier SHOULD provide location in the response in the same order in which they
were included in the "locationType" element in the request. Indeed, the primary advantage
of including specific location types in a request when the 'exact' attribute is set to
"false" is to ensure that one receives the available locations in a specific order. For
example, a subscription for "civic" (with the 'exact' attribute set to "false") could
yield any of the following location types in the response: civiccivic, geodeticgeodetic (only if civic is not available) The default value of "false" for the 'exact' attribute allows the Notifier the option of
returning something beyond what is specified, such as a set of location URIs when only a
civic location was requested.An example is shown in that utilizes the
<locationType> element with the 'exact' and the 'responseTime' attribute. defines an extension to the SIP
events framework defining the following three "Event" header field parameters that allow a
subscriber to set a minimum, a maximum and an average rate of event notifications
generated by the notifier. This document makes use of two of the parameters, namely
"min-interval" (which specifies a minimum notification time period between two
notifications, in seconds) and "max-interval" (which specifies a maximum notification time
period between two notifications, in seconds.). The implementation of only these two
attributes is required from the complete set of attributes defined in . Whenever the time since the most recent
notification exceeds the value in the "max-interval" parameter, the current state would be
sent in its entirety, just like after a subscription refresh. If complete state is not immediately available, then an empty NOTIFY is sent immediately
and subsequently a separate NOTIFY containing location is generated some time between the
time included in 'min-interval' and the time in 'max-interval'. An important use case for
location based applications focuses on the behavior of the initial NOTIFY message(s) and
the information it returns, for example in case of emergency call routing. When an initial
NOTIFY is transmitted it might not include complete state. shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1)
has filters attached and contains a 'max-interval' rate control parameter. In certain
situations it is important to obtain some amount of location information within a
relatively short and pre-defined period of time even if the obtained location information
contains a high amount of uncertainty and location information with less uncertainty at a
later point in time. An example is emergency call routing where a emergency services
routing proxy may need to obtain location information suitable for routing rather quickly
and subsequently a Public Safety Answering Point requests location information for
dispatch. To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism,
it is RECOMMENDED that the initial SUBSCRIBE contains a 'max-interval' rate control
parameter (with a small value) that is in a later message updated to a more sensible
value. The 'max-interval' for this first request is therefore much lower than thereafter.
Updating the 'max-interval' for the subscription can be performed in the 200 response (see
message 3) to the NOTIFY that contains state. Depending on the value in the 'max-interval'
parameter the Notifier may create a NOTIFY message (see message 2) immediately in response
to the SUBSCRIBE that might be empty in case no location information is available at this
point in time. The desired location information may then arrive in the subsequent NOTIFY
message (see message 4). This document specifies one piece, namely filters, utilized in larger system. As such, this
document builds on a number of specifications for the security of the complete solution,
namely the SIP event notification mechanism, described in RFC 3265 ,
defining the SUBSCRIBE/NOTIFY messages. the presence event package, described in RFC 3856 , which is a
concrete instantiation of the general event notification framework.the filter framework, described in RFC 4661 , to offer the
ability to reduce the amount of notifications being sent. Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO,
described in RFC 4119 , as the XML container that carries location
information.Each of these documents listed above comes with a security consideration section but the
security and privacy aspects are best covered by the SIP presence event package, see Section
9 of , and with the GEOPRIV architectural description found in .The functionality offered by authorization policies to limit access to location information
are provided by other protocols, such Common Policy , Geolocation
Policy or more recent work around HELD context
. Although defines a standardized format for geolocation
authorization policies it does not define specific policies for controlling filters. The functionality described in this document extends the filter framework with location
specific filters. Local policies might be associated with the usage of certain filter
constructs and with the amount of notifications specific filter settings might cause.
Uploading filters have a significant effect on the ways in which the request is handled at a
server. As a result, it is especially important that messages containing this extension be
authenticated and authorised. RFC 4661 discusses this security
threat and proposed authentication and authorization solutions applicable by this
specification. This section registers a new XML namespace, as per the guidelines in . urn:ietf:params:xml:ns:location-filter IETF, GEOPRIV working group,
<geopriv@ietf.org>, as delegated by the IESG
<iesg@ietf.org>. This specification registers a schema, as per the guidelines in .URI: urn:ietf:params:xml:schema:location-filterRegistrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by
the IESG (iesg@ietf.org).XML: The XML can be found as the sole content of .We would like to thank Martin Thomson and James Polk for their contributions to this
document. Thanks to Richard Barnes and Alissa Cooper, Carl Reed, Adam Roach, Allan Thomson, James
Winterbottom for their comments.Open Geography Markup Language (GML) Implementation Specification OpenGIS