Location Conveyance for the Session Initiation Protocol
updated by
Extracted elements (29)
Location-by-reference (a URI the recipient dereferences) is preferred over location-by-value when confidentiality from intermediaries is required (per RFC 5606 Section 3.3.2), because it permits access control per recipient without requiring the sender to anticipate all recipients in advance.
The default Geolocation-Routing value is "no" for two reasons: (1) to make retention of the Target's location moot because intermediaries never view it in the first place, and (2) to prevent differential routing treatment of SIP requests based on location the Target did not consent to share with intermediaries.
The document deliberately does not specify which of multiple competing location sources (e.g., on-board GPS vs. cell tower assertion) is more accurate. Instead, a 'you break it, you bought it' policy makes an intermediary that inserts a second location fully responsible for all location information in that request.
For non-INVITE transactions, the SIP response is likely sent before the dereference of a location URI completes. Receivers of a 200 OK to a non-INVITE request containing location SHOULD NOT interpret that response as confirmation that dereferencing succeeded and the PIDF-LO was parsed without errors.
A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. If it does add a locationValue, it MUST position it last in the Geolocation header and MUST NOT pass any resulting 424 response upstream — the intermediary bears full responsibility for that addition.
GEO-URIs (RFC 5870) MUST NOT be used in the SIP Geolocation header because they do not include retention and re-transmission flags required by RFC 3693 for a Using Protocol. Any other URI scheme used MUST be reviewed against RFC 3693 Using Protocol criteria.
If a location URI is included in a SIP request, the sending UA MUST also include a Supported header field indicating which location profiles ("geolocation-sip" and/or "geolocation-http") it supports. All location profile option tags MUST begin with the string "geolocation" followed by a dash.
Implementations MUST guard against repeated Geolocation-Error rejections used to probe for more precise location information. A configurable limit is required with a RECOMMENDED maximum of three rejections per related transaction.
SIP intermediaries forwarding (not generating) a 424 response MUST NOT add, modify, or delete any location in that response; Geolocation and Geolocation-Error header fields and PIDF-LO body parts MUST remain unchanged.
The Geolocation-Error header MUST be included in every 424 response. A 424 MUST NOT be sent in response to a request that lacks a Geolocation header entirely, as the UA may not support the extension.
The Geolocation header field MUST have at least one locationValue, and every locationValue MUST be related to the original Target. SIP intermediaries SHOULD NOT modify or delete existing locationValues.
The Geolocation-Routing header field MUST NOT appear more than once in any SIP request and MUST NOT lack a header-value. When absent in a request that contains a Geolocation header, it MUST be interpreted as if present with value "no".
UAC implementations MUST make location-conveying capabilities conditional on explicit user permission and MUST alert the user that location is being conveyed in a SIP request.
When multiple locationValues are present in a SIP request and at least one is determined valid by the Location Recipient, the location MUST be considered good and no Geolocation-Error is to be sent. Dereference attempts SHOULD be limited to 10 within a few minutes before returning error code 300.
When the Geolocation-Routing header-value is "no", SIP intermediaries MUST NOT view, process, inspect, or actively dereference any location (neither cid: body parts nor location URIs). An LR MUST default to treating Geolocation-Routing as "no" unless the header is explicitly set to "yes".
Location information is highly sensitive and governed by GEOPRIV rules (RFC 3693, RFC 6280). The Rule Maker controls which entity adds location and what access control rules apply. SIP implementations must honor PIDF-LO usage-rules including <retransmission-allowed> and <retention-expiry> per RFC 4119 Section 2.2.2.
Geolocation-Error codes are divided into three ranges: 1xx (cannot process — missing, insufficient, or corrupted location), 2xx (permission required, e.g., 201 for retransmission to third party, 202 for routing permission), and 3xx (dereference failure). Only one code per response is allowed; when multiple errors exist the LR applies local policy to select one.
Location profile negotiation uses SIP option tags in a Supported header. "geolocation-sip" signals PIDF-LO retrieval via SIP SUBSCRIBE/NOTIFY (sip/sips/pres URIs); "geolocation-http" signals retrieval via HTTP GET (http/https URIs). If the receiver does not understand the URI scheme, it returns the option tag in Unsupported and its preferred scheme in Supported.
The 424 (Bad Location Information) response code rejects a request due to malformed, unsatisfactory, or non-dereferenceable location. It MUST include a Geolocation-Error header and SHOULD include a PIDF-LO body with corrective location when the intermediary has better information. It is a final response and MUST NOT terminate an existing dialog.
The Geolocation header field is valid in INVITE, REGISTER, OPTIONS, BYE, UPDATE, INFO, MESSAGE, REFER, SUBSCRIBE, NOTIFY, and PUBLISH requests. It carries one or more locationValues referencing a PIDF-LO either by value (cid: URI pointing to a MIME body) or by reference (sip/sips/pres/http/https URI to be dereferenced).
IANA created a new "Geolocation-Error Codes" registry (Specification Required) with initial codes: 100 (Cannot Process Location), 200 (Permission To Use Location Information), 201 (Permission To Retransmit to Third Party), 202 (Permission to Route based on Location), 300 (Dereference Failure).
IANA registered 424 (Bad Location Information) in the SIP Response Codes registry and added two new SIP option tags: "geolocation-sip" (PIDF-LO via SIP presence SUBSCRIBE/NOTIFY) and "geolocation-http" (PIDF-LO via HTTP GET) to the Options Tags registry.
IANA updated the SIP Header Fields registry with three new entries: Geolocation (Section 4.1), Geolocation-Routing (Section 4.2), and Geolocation-Error (Section 4.4). Modifications require a Standards Action.
There is no end-to-end integrity protection on Geolocation or Geolocation-Error header fields; recipients must implicitly trust their contents. When unauthenticated access to location-by-reference is unavoidable, pseudorandom URIs combined with SIPS path encryption limits exposure to entities on the SIP signaling path only.
TLS (hop-by-hop) protects against eavesdropping but exposes location to all proxies on the path. S/MIME end-to-end encryption is problematic for location-based routing because proxies need to read location. Location-by-reference with per-entity authentication is the preferred model when pre-association is possible, as it allows proper authorization of each entity that dereferences location.
The Geolocation-Routing header has three states: "yes" (intermediaries may use location for routing and may change to "no" for downstream), "no" (intermediaries MUST NOT view or route on location), and absent-while-Geolocation-present (treated identically to "no"). Absent-with-no-Geolocation-header allows intermediaries to freely set the value.
The Geolocation-Error header ABNF: 'Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue'; locationErrorValue is a 1–3-digit error code with an optional 'code' parameter carrying a quoted human-readable string. Only one locationErrorValue is permitted per response.
The Geolocation header ABNF: 'Geolocation-header = "Geolocation" HCOLON locationValue *( COMMA locationValue )'; locationValue is a URI (sip, sips, pres, http, https, cid-url, or absoluteURI) enclosed in angle brackets followed by optional SEMI-separated generic-params.
The Geolocation-Routing header ABNF: 'Georouting-header = "Geolocation-Routing" HCOLON ( "yes" / "no" / generic-value )'. Only "yes" and "no" are defined values; a null/absent value is not permitted, and unknown values MUST be treated as "no".