Filtering Location Notifications in the Session Initiation Protocol (SIP)
Extracted elements (24)
Civic address tokens (country, A1, A2, ..., A6) are hierarchical: a change in a higher-level token (e.g., A3 'city or town') likely causes changes in tokens lower in the hierarchy (A4, A5, A6). This justifies using separate <trigger> elements when any one of multiple civic elements changing should fire a notification.
Location information is a continuous gradient unlike discrete-valued notification quantities, making it difficult to determine when a change is sufficiently large to warrant a notification. This motivates the location-specific filter extensions (movement, speed, region entry/exit, civic element changes) defined in this document.
The 50% confidence threshold for <enterOrExit> notifications naturally limits notification frequency: small movements relative to location uncertainty at region borders do not trigger notifications, since the total confidence depends on location confidence (95% recommended per RFC 5491) and does not simply add to 100%.
This specification extends RFC 4661 (XML-based event notification filtering) and uses the SIP presence event package (RFC 3856) as its transport. Location information is conveyed in PIDF-LO format (RFC 4119), and the <enterOrExit> region shapes rely on RFC 5491 geometry definitions (circle and polygon).
For speed change filtering, the value of the <speed> element from RFC 5962 MUST be defined in meters per second. An implementation MUST support <ns-bindings> to replace the namespace prefix, and the XPath expression MUST start with '//' followed by a single element.
For the <changed> element used in speed and element value change filters, only the 'by' attribute MUST be implemented for speed changes, while the 'by', 'to', and 'from' attributes MUST be implemented for element value change filtering.
From RFC 6446, only the 'min-rate' and 'max-rate' Event header field parameters are required to be implemented. When time since the most recent notification exceeds 1/'min-rate' seconds, the current state MUST be sent in its entirety.
If the 'exact' attribute is set to 'true', the Notifier MUST return either the requested location type or no location information. The 'exact' attribute is ignored for a location type request of 'any'.
If the <locationType> element is absent, a value of 'any' MUST be assumed as the default.
It is RECOMMENDED that the initial SUBSCRIBE contain a 'min-rate' rate control parameter with a large value (corresponding to a very short delay) that is updated in a later message to a more sensible value, to obtain location information in a timely fashion for use cases such as emergency call routing.
The <enterOrExit> element MUST contain either a polygon or a circle (as defined in RFC 5491) as a child element, and MUST NOT have more than one polygon and/or circle.
The <moved> element MUST contain a value in meters indicating the minimum distance the resource must have moved from its last notification location to trigger an event. The distance MUST be measured in meters absolutely from the point of the last notification and must include vertical movement.
The <moved> element MUST NOT appear more than once as a child element of the <filter> element.
The Notifier SHOULD return the requested location type(s) and SHOULD provide civic and geodetic location information in the response in the same order in which they were included in the <locationType> element in the request.
The RFC 4661 sub-elements <ns-bindings>, <filter>, and <trigger> (except <added> and <removed>) MUST be implemented to reduce interoperability problems.
Element value changes (e.g., civic address fields like country, A1, A2, A3, PC) are filtered using the <changed> element from RFC 4661. Multiple <changed> elements within a single <trigger> require ALL to change simultaneously; separate <trigger> elements fire on ANY individual change.
The <enterOrExit> condition is satisfied when the target enters or exits a 2-dimensional region described by a polygon or circle. A notification is sent when the target's location is within (or outside) the region with at least 50% confidence.
The <locationType> element, placed as a child of <what>, specifies the location information types requested by the subscriber: 'any', 'geodetic', or 'civic'. The optional 'exact' attribute (default false) controls whether the notifier MUST return only the requested type or may substitute alternatives.
The <moved> element triggers a location notification when the target has moved more than a specified number of meters (as a double value) from the location at the time of the last notification, including vertical movement.
IANA registered the XML namespace URN 'urn:ietf:params:xml:ns:location-filter' for the PIDF-LO location filter namespace, as per RFC 3688 guidelines, under the GEOPRIV working group.
IANA registered the XML schema URI 'urn:ietf:params:xml:schema:location-filter' for the location-filter XML schema defined in Section 4 of this document.
Authorization policies to limit access to location information are provided by external protocols such as Common Policy (RFC 4745), Geolocation Policy, or HELD context. While Geolocation Policy defines a standardized format for geolocation authorization policies, it does not define specific policies for controlling filters.
Uploading filters has a significant effect on how requests are handled at a server. It is especially important that messages containing this location filter extension be authenticated and authorized. RFC 4661 discusses this threat and proposes applicable authentication and authorization solutions.
The XML schema defines three top-level elements: <enterOrExit> of type gml:GeometryPropertyType; <moved> of type movedType (xs:double with any attributes); and <locationType> of type locationTypeType (union of 'any' token or list of 'civic'/'geodetic' tokens, with optional boolean 'exact' attribute defaulting to false). Namespace: urn:ietf:params:xml:ns:location-filter.