RFC 6442
Location Conveyance for the Session Initiation Protocol
Location Conveyance for the Session Initiation Protocol 🎀 RFC 6442, from December 2011, is a Standards Track doc. The authors are J. Polk (Cisco Systems), B. Rosen (NeuStar), and J. Peterson (NeuStar). It's published by the IETF under ISSN 2070-1721. This header doesn't list anything it obsoletes or updates. 💅
Abstract ✨
Okay, so this doc adds an extension to SIP (the Session Initiation Protocol) so one SIP entity can send geographic location info to another one. It covers both end-to-end conveyance and location-based routing, where SIP intermediaries make routing decisions based on where the Location Target is. Iconic. 🌍
Status of This Memo 🧚
This is an Internet Standards Track document. 💖
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741. 📚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6442. 🦋
Copyright Notice 💜
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. 🫶
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🌸
Table of Contents 🍓
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............4
3. Overview of SIP Location Conveyance .............................4
3.1. Location Conveyed by Value .................................4
3.2. Location Conveyed as a Location URI ........................5
3.3. Location Conveyed though a SIP Intermediary ................6
3.4. SIP Intermediary Replacing Bad Location ....................7
4. SIP Extensions for Geolocation Conveyance .......................8
4.1. The Geolocation Header Field ...............................8
4.2. The Geolocation-Routing Header Field ......................11
4.2.1. Explaining Geolocation-Routing Header-Value
States .............................................12
4.3. 424 (Bad Location Information) Response Code ..............14
4.4. The Geolocation-Error Header Field ........................15
4.5. Location URIs in Message Bodies ...........................19
4.6. Location Profile Negotiation ..............................19
5. Geolocation Examples ...........................................20
5.1. Location-by-Value (in Coordinate Format) ..................20
5.2. Two Locations Composed in Same Location Object Example ....21
6. Geopriv Privacy Considerations .................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................26
8.1. IANA Registration for the SIP Geolocation Header Field ....26
8.2. IANA Registration for the SIP Geolocation-Routing
Header Field ..............................................26
8.3. IANA Registration for Location Profiles ...................27
8.4. IANA Registration for 424 Response Code ...................27
8.5. IANA Registration of New Geolocation-Error Header Field ...28
8.6. IANA Registration for the SIP Geolocation-Error Codes .....28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................31
Appendix A. Requirements for SIP Location Conveyance ..............321. Introduction ✨
Session Initiation Protocol (SIP) [RFC3261] is what creates, changes, and ends multimedia sessions. 📞 SIP carries certain session-related info while it sets up or keeps up calls. This doc explains how SIP conveys the geographic location of a Target to a Location Recipient (LR). SIP is acting as a Using Protocol for location information, as defined in RFC 3693. 🧚
To convey location info, this doc specifies three new SIP header fields: Geolocation, Geolocation-Routing, and Geolocation-Error. 💅 Geolocation carries a reference to a Location Object (LO). Geolocation-Routing grants permission to route a SIP request based on the location-value. Geolocation-Error gives error notifications specific to location errors. The Location Object (LO) can show up in a MIME body attached to the SIP request, or it can be a remote resource in the network. 🗺️
A Target is an entity whose location is being conveyed, per RFC 3693. So a Target could be a SIP user agent (UA), some other IP device (like a router or a PC) that doesn't have a SIP stack, a non-IP device (a person or a black phone), or even a non-communications device (a building or store front). 🏢 This doc does NOT assume that the SIP user agent client sending a request with a location object is necessarily the Target. 🙈 The location of a Target conveyed within SIP usually matches a device the Target controls, like a mobile phone. But those devices can get separated from their owners, and sometimes the user agent doesn't even know its own location. 📱
In the SIP context, a location recipient will most likely be a SIP UA. But because SIP architectures are mediated, location info carried by one SIP request could have multiple recipients. Any SIP proxy server in the signaling path that inspects the Target's location also counts as a Location Recipient. 🫶 In presence-like architectures, an intermediary that receives location publications and distributes them to watchers acts as a Location Server per RFC 3693. This conveyance mechanism can also deliver URIs that point to such Location Servers, so prospective Location Recipients can request Location Objects. 🦋
2. Conventions and Terminology Used in This Document 📚
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 [RFC2119]. Furthermore, this document uses a bunch of terms defined in [RFC3693], including: Location Object, Location Recipient, Location Server, Target, Rule Maker, and Using Protocol. 🤓
3. Overview of SIP Location Conveyance 🌈
An operational overview of SIP location conveyance can be shown in four basic diagrams, and most applications fall under one of these basic use cases. Each one gets its own subsection here in Section 3. 🎀
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob is an LR. A SIP intermediary shows up in some of the diagrams. Any SIP entity that receives and inspects location information is an LR. So in any of the diagrams, the SIP intermediary that receives a SIP request is potentially an LR. That doesn't mean that intermediary has to route the SIP request based on the location information, though. 🙃 In some use cases, location information passes through the LS on the right of each diagram. 🧚
3.1. Location Conveyed by Value 💖
We start with the simplest diagram of Location Conveyance: Alice to Bob, where no other Layer 7 entities are involved. 💅
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location | |
|----------------------------------->| |
| | |
| Response | |
|<-----------------------------------| |
| | | |
Figure 1. Location Conveyed by ValueIn Figure 1, Alice is both the Target and the LS that conveys her location directly to Bob, who acts as an LR. ✨ This conveyance is point-to-point. It doesn't go through any SIP-layer intermediary. A Location Object shows up by-value in the initial SIP request as a MIME body, and Bob responds to that SIP request as appropriate. 🫶
There's a 'Bad Location Information' response code introduced in this document specifically to tell Alice if she conveys bad location to Bob. For example, Bob might say he "cannot parse the location provided," or that "there is not enough location information to determine where Alice is." 🙈
3.2. Location Conveyed as a Location URI 🎀
Okay, so this one takes Figure 1 and adds a middle character 🦋. Bob's entity has to go fetch the location object from a third-party server, which is the LS.
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location URI | |
|----------------------------------->| |
| | Dereference |
| | Request |
| (To: Location URI) |
| |---------------->|
| | |
| | Dereference |
| | Response |
| (includes Location Object) |
| |<----------------|
| Response | |
|<-----------------------------------| |
| | | |
Figure 2. Location Conveyed as a Location URIIn Figure 2, the location shows up indirectly, through a Location URI that rides along in the SIP request (more deets on that later 💅). If Alice sends Bob this Location URI, Bob has to dereference it. This is kind of like Content Indirection [RFC4483] 🌸, and it's how Bob asks for the location info. Basically the LS hands the location value to Bob instead of Alice handing it over directly. Bob, the user, has no idea the info came from an LS rather than straight out of the SIP request, and honestly that's the vibe 🫶. Location-based apps keep working just fine either way.
The example in this section is only illustrative, not normative, so it's not the official rulebook 📖. Applications can dereference a location URI whenever they want, multiple times if they're feeling extra, or not at all 🙈. Apps that get a Location URI in a SIP transaction need to watch their timers, because different transactions run on different clocks ⏰. If dereferencing might take longer than the SIP transaction timeout (Timer C for INVITE transactions, Timer F for non-INVITE transactions), the app needs something other than the transaction's response code to report location errors, if it needs to report them at all 😭.
3.3. Location Conveyed though a SIP Intermediary 🧚
Now we bring in a SIP intermediary, which is the plot twist of the whole arc 🔥. It can be a SIP proxy or a back-to-back user agent (B2BUA), and it can also act as an LR alongside Bob. The big reason intermediaries care about location is location-based routing, where the intermediary picks the next hop by asking a specialized location service that chooses forwarding destinations based on the geographic location info inside the SIP request 🗺️.
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | Request | |
| | w/Location | |
| |------------------>| |
| | | |
| | Response | |
| |<------------------| |
| Response | | |
|<---------------| | |
| | | |
Figure 3. Location Conveyed though a SIP IntermediaryBut the most common situation is way more chill 😌. The intermediary gets a request with location info, either by-value or by-reference, and it doesn't know or care where Alice is. It also might not support this extension at all, so it just passes the request along to Bob 🍓. In that case the intermediary is not acting as a Location Recipient, and the whole thing works the same as in Section 3.1.
Here's a fun detail: an intermediary doesn't have to do location-based routing to be a Location Recipient 👑. An intermediary that doesn't route by location might still care when Alice includes her location. Maybe it needs to check that the info is complete, or that it correctly says where Alice is. The best example is intermediaries that verify location for emergency calling, but it also applies to any location-based routing, like making sure your favorite local pizza place gets Alice's correct location in the initial SIP request 🍕.
There's one more scenario where a non-LR intermediary cares about location, and this one is a bit messy 😬. The intermediary inserts its own location for the Target (Alice, in this case) into the request, then forwards it. This second location insertion is generally not advisable, because downstream SIP entities get no guidance about which location to trust. They can't tell if one is better, more reliable, less error-prone, more granular, worse than the other, or just plain wrong 💀.
This document takes a "you break it, you bought it" approach to second locations that an intermediary puts into a SIP request 💅. That intermediary becomes completely responsible for all location within that SIP request (more on this in Section 4).
3.4. SIP Intermediary Replacing Bad Location 🙅♀️
If the SIP intermediary rejects a message because the location info isn't suitable, the SIP response says there was 'Bad Location Information' in the request. It also includes a location-specific error code that tells Alice what to fix so her next request is acceptable (see Figure 4 for this scenario) ✨.
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | | |
| Rejected | | |
| w/New Location | | |
|<---------------| | |
| | | |
| Request | | |
| w/New Location | | |
|--------------->| | |
| | Request | |
| | w/New Location | |
| |------------------>| |
| | | |
Figure 4. SIP Intermediary Replacing Bad LocationIn this last use case, the intermediary wants to include a Location Object showing where it thinks Alice is 🗺️. So it needs to tell her user agent which location it's going to include in any later SIP request that carries her location. The intermediary can reject Alice's request and, in the SIP response, explain the best way to fix the request so the intermediary will accept it 🌈.
Overriding location info from the user only makes sense in a deployment where the intermediary knows better than the end user 🤔. Like, Alice might have an on-board GPS, while the intermediary only knows her nearest cell tower. So which one is more accurate? Right now there's no way to tell which entity is more accurate, or even which one is wrong. This document won't specify how to indicate that one location is more accurate than another 🤷♀️.
As an aside, no SIP-based emergency services request (you know, IP-911 or 112 type calls) is expected to get a corrective 'Bad Location Information' response from an intermediary 🚨. Most likely, in that case the SIP intermediary acts as a B2BUA and inserts any appropriate location info by-value. That helps Public Safety Answering Point (PSAP) call centers get the call to emergency personnel faster, which cuts down on delay in call establishment 🚑. Setting up these specialized deployments is, however, outside the scope of this document 💜.
4. SIP Extensions for Geolocation Conveyance 🌟
The following sections detail the extensions to SIP for location conveyance 💖.
4.1. The Geolocation Header Field ✨
okay so bestie, this section is where the Geolocation header field gets officially defined 🎀 IANA registers it as a new SIP header, and the grammar is written in ABNF [RFC5234] (the little language everyone uses to write these rules, and it's giving precision 💅):
message-header =/ Geolocation-header
; (message-header from RFC 3261)
Geolocation-header = "Geolocation" HCOLON locationValue
*( COMMA locationValue )
locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / https-URI
/ cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261)
geoloc-param = generic-param ; (from RFC 3261)HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in [RFC3261] 🦋
sip-URI, sips-URI, and absoluteURI are defined according to [RFC3261] 💖
The pres-URI is defined in [RFC3859] 🌸
http-URI and https-URI are defined according to [RFC2616] and [RFC2818], respectively 🧚
The cid-url is defined in [RFC2392] to locate message body parts. This URI type shows up in a SIP request when the location is conveyed as a MIME body in the SIP message 🫶
GEO-URIs [RFC5870] are NOT appropriate for usage in the SIP Geolocation header, ngl, because they don't include retention and re-transmission flags as part of the location information 💀 Any other URI schemes used in the location URI MUST be reviewed against the criteria in [RFC3693] for a Using Protocol. Section 4.6 explains how URI schemes get communicated with this SIP extension and what to do if a URI scheme shows up that can't be supported 🔥
The generic-param in the definition of locationValue is there as a mechanism for future extensions that might need parameters 🌈 This document defines NO parameters for use with locationValue. If a Geolocation header field is received with generic-params, each parameter SHOULD be ignored, and SHOULD NOT be removed when forwarding the locationValue. If a need comes up to define parameters for locationValue, a revision or extension to this document is required 💜
The Geolocation header field MUST have at least one locationValue. A SIP intermediary SHOULD NOT add location to a SIP request that already contains location, because this will quite often lead to confusion within LRs 🙈 However, if a SIP intermediary adds location (even if location wasn't previously present in the request), that intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition, and it MUST NOT pass on (upstream) the 424 response 👑 A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request ⭐
This document defines the Geolocation header field as valid in the following SIP requests:
INVITE [RFC3261] REGISTER [RFC3261]
OPTIONS [RFC3261] BYE [RFC3261]
UPDATE [RFC3311] INFO [RFC6086]
MESSAGE [RFC3428] REFER [RFC3515]
SUBSCRIBE [RFC3265] NOTIFY [RFC3265]
PUBLISH [RFC3903]The Geolocation header field MAY be included in any one of the above requests by a UA, and in a 424 response to any one of the requests sent above. Fully appreciating the caveats and warnings mentioned above, a SIP intermediary MAY add the Geolocation header field 🍓
A SIP intermediary MAY add a Geolocation header field if one isn't present. For example, that happens when a user agent doesn't support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or for any number of other use cases (see Section 3) 🦋
The Geolocation header field MAY be present in a SIP request or response without a Geolocation-Routing header (defined in Section 4.2). As Section 4.2 says, the default value of Geolocation-Routing header-value is "no", which means SIP intermediaries MUST NOT view (i.e., process, inspect, or actively dereference) any direct or indirect location within this SIP message. This is for at least two fundamental reasons 💅
- to make the possibility of retention of the Target's location moot (because it was never viewed in the first place); and
- to prevent a different treatment of this SIP request based on the contents of the Location Information in the SIP request.
Any locationValue MUST be related to the original Target. This is equally true for the location information in a SIP response, i.e., from a SIP intermediary back to the Target, as explained in Section 3.4 🌸 SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s). The one case where this wouldn't apply is when the SIP intermediary is an anonymizer. The problem with that scenario is that the geolocation the Target included becomes useless for whatever purpose or service they wanted it for. For example, 911/emergency calling or finding the nearest (towing company/pizza delivery/dry cleaning) service(s) won't yield the intended results if the Location Information gets modified or deleted from the SIP request 🚨
4.2. The Geolocation-Routing Header Field 🎀
okay this one is the gatekeeper header 👑 This document defines "Geolocation-Routing" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
message-header =/ Georouting-header
; (message-header from RFC 3261)
Georouting-header = "Geolocation-Routing" HCOLON
( "yes" / "no" / generic-value )
generic-value = generic-param; (from RFC 3261)HCOLON is defined in [RFC3261] 💖
The only defined values for the Geolocation-Routing header field are "yes" or "no". When the value is "yes", the locationValue can be used for routing decisions along the downstream signaling path by intermediaries. Values other than "yes" or "no" are permitted for future extensions. Implementations that aren't aware of an extension MUST treat any other received value the same as "no" 🧚
If no Geolocation-Routing header field is present in a SIP request, a SIP intermediary MAY insert this header. Without knowledge from a Rule Maker, the SIP intermediary inserting this header-value SHOULD NOT set the value to "yes", because that may be more permissive than the originating party intends. An easy way around this is for the Target to always insert this header-value as "no" 🫶
When the Geolocation-Routing header-value is set to "no", that means no locationValue (inserted by the originating User Agent Client (UAC) or any intermediary along the signaling path) can be used by any SIP intermediary to make routing decisions. Intermediaries that try to use the location information for routing anyway, despite this counter indication, could end up routing the request improperly as a result 🙈 Section 4.4 gives the details on what a routing intermediary does if it decides it needs to use the location in the SIP request to process the message further. The practical implication is that when the Geolocation-Routing header-value is "no": if a cid:url is present in the SIP request, intermediaries MUST NOT view the location (because it isn't for intermediaries to consider when processing the request); and if a location URI is present, intermediaries MUST NOT dereference it. UAs are allowed to view location in the SIP request even when the Geolocation-Routing header-value is "no". An LR MUST by default consider the Geolocation-Routing header-value as set to "no", with no exceptions, unless the header field value is set to "yes" 🔥
A Geolocation-Routing header-value that is set to "no" has no special security properties. At most, it's a request for behavior within SIP intermediaries. That said, if the Geolocation-Routing header-value is "no", SIP intermediaries are still to process the SIP request and send it further downstream within the signaling path, as long as there are no errors present in the request 💅
The Geolocation-Routing header field satisfies the recommendations made in Section 3.5 of RFC 5606 [RFC5606] regarding indication of permission to use location-based routing in SIP ✨
SIP implementations are advised to pay special attention to the policy elements for location retransmission and retention described in RFC 4119 🌈
The Geolocation-Routing header field cannot appear without a header-value in a SIP request or response (i.e., a null value is NOT allowed). The absence of a Geolocation-Routing header-value in a SIP request is always the same as the following header field:
Geolocation-Routing: noThe Geolocation-Routing header field MAY be present without a Geolocation header field in the same SIP request. This concept is further explored in Section 4.2.1 💜
4.2.1. Explaining Geolocation-Routing Header-Value States ✨
okay so the Geolocation header field holds the Target's location, and it MUST NOT be there if the SIP request has no location info at all 🗺️ The location info lives in one or more locationValues. These locationValues MAY sit in one single Geolocation header field or be spread out across several of them. (See Section 7.3.1 of RFC 3261.)
The Geolocation-Routing header field is the bit that decides whether SIP intermediaries can look at this request and route it based on the location info (directly or indirectly included) 👀 It MUST NOT appear more than once in any SIP request, and it MUST NOT be missing its header-value. If a SIP request doesn't have a Geolocation-Routing header field, the default or implied policy acts exactly like it's there with the header-value set to "no". Main character energy for "no" 💅
There are only three possible states for this header field:
- "no"
- "yes"
- no header-field present in this SIP request
Here's what each state gets you 🫶
If the Geolocation-Routing Only possible interpretations:
-------------------------- -----------------------------
"no" SIP intermediaries MUST NOT process
included geolocation information
within this SIP request.
SIP intermediaries inserting a
locationValue into a Geolocation
header field (whether adding to an
existing header-value or inserting the
Geolocation header field for the first
time) MUST NOT modify or delete the
received "no" header-value.
"yes" SIP intermediaries can process
included geolocation information
within this SIP request and can
change the policy to "no" for
intermediaries further downstream.
Geolocation-Routing absent If a Geolocation header field exists
(meaning a locationValue is already
present), a SIP intermediary MUST
interpret the lack of a
Geolocation-Routing header field as if
there were one present and the
header-value is set to "no".
If there is no Geolocation header
field in this SIP request, the default
Geolocation-Routing is open and can be
set by a SIP intermediary or not at
all.4.3. 424 (Bad Location Information) Response Code 🎀
this SIP extension creates a brand new location-specific response code, and it's giving rejection 🙅♀️
424 (Bad Location Information)The 424 (Bad Location Information) response code basically means the request got turned down because of what it says about location. The location info was malformed, not good enough for what the recipient needs, or couldn't be dereferenced 💀
A SIP intermediary can also reject a location it gets from a Target when it knows the Target is actually somewhere else. The right move here, which is described in Section 3.4, is for the SIP intermediary to put the proper location in the 424 response. This SHOULD be included in the response as a MIME message body (aka a location value) instead of as a URI 🍓 The exception is when the intermediary is happy to share location with recipients but not with a user agent. Then a reference might be needed.
As Section 3.4 mentioned, the intermediary might not want to risk giving less accurate location info than the user agent already has 🧚 So it writes its own understanding of where the user agent is in a separate <geopriv> element, inside the same Presence Information Data Format Location Object (PIDF-LO) [RFC4119] message body in the SIP response. The Target's version of its location is in there too. That means both locations get included, each with its own <method> elements 🌈 The user agent's proper reaction is to generate a new SIP request that includes this composed location object, and send it toward the original LR. SIP intermediaries can check that later requests actually insert the suggested location info before forwarding them ✨
SIP intermediaries that are forwarding a 424 response (as opposed to generating one) MUST NOT add, modify, or delete any location in that response. This especially applies to intermediaries sitting between the 424 response generator and the original UAC. Geolocation and Geolocation-Error header fields and PIDF-LO body parts MUST remain unchanged, never added to or deleted 🔒
Section 4.4 describes a Geolocation-Error header field that gives more detail about what was wrong with the location info in the request. This header field MUST be included in the 424 response 📝
It's only appropriate to generate a 424 response when the responding entity needs a locationValue and there are no values in the request the responder can actually use, or when the responder has extra location info to share. The second case shows up in Figure 4 of Section 3.4, where a SIP intermediary is telling the upstream UA which location to put in the next SIP request 🦋
A 424 response MUST NOT be sent in response to a request that has no Geolocation header at all, because the user agent in that case might not support this extension whatsoever 🙈 If a SIP intermediary inserted a locationValue into a SIP request where one wasn't there before, it MUST take any and all responsibility for the corrective action if it gets a 424 response to a SIP request it sent. Big accountability energy 👑
A 424 (Bad Location Information) response is a final response within a transaction, and it MUST NOT terminate an existing dialog 💜
4.4. The Geolocation-Error Header Field 💅
Okay so remember in 4.3 when we talked about needing more granular error notifications? 💖 The location inserting entity can't fix what it doesn't know went wrong 😭, which is where the Geolocation-Error header field comes in. It's giving detective energy 🔍
The Geolocation-Error header field is used to convey location-specific errors within a response. Here's the ABNF [RFC5234] for it:
message-header =/ Geolocation-Error
; (message-header from RFC 3261)
Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue
locationErrorValue = location-error-code
*(SEMI location-error-params)
location-error-code = 1*3DIGIT
location-error-params = location-error-code-text
/ generic-param ; from RFC 3261
location-error-code-text = "code" EQUAL quoted-string
; from RFC 3261HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].
The Geolocation-Error header field MUST contain only one locationErrorValue to indicate what was wrong with the locationValue the Location Recipient determined was bad. The locationErrorValue contains a 3-digit error code indicating what was wrong with the location in the request. This error code has a corresponding quoted error text string that is human understandable. The text string is OPTIONAL, but RECOMMENDED for human readability, similar to the string phrase used for SIP response codes. That said, the strings are complete enough for rendering to the user, if so desired. ✨ The strings in this document are recommendations and are not standardized, which means an operator can change the strings, but they MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code. 🎀
The Geolocation-Error header field MAY be included in any response to one of the SIP Methods mentioned in Section 4.1, so long as a locationValue was in the request part of the same transaction. For example, Alice includes her location in an INVITE to Bob. Bob can accept this INVITE, thus creating a dialog, even though his UA determined the location contained in the INVITE was bad. Bob merely includes a Geolocation-Error header value in the 200 OK response to the INVITE, informing Alice the INVITE was accepted but the location provided was bad. 🦋
If, on the other hand, Bob cannot accept Alice's INVITE without a suitable location, a 424 (Bad Location Information) response is sent. This message flow is shown in Figures 1, 2, or 3 in Sections 3.1, 3.2, and 3.3, respectively. 🌸
If Alice is deliberately leaving location information out of the LO because she does not want Bob to have this additional information, it's smart for implementations to be aware that Bob could keep erroring so he can get more location information about Alice in a subsequent SIP request. 🙈 Implementations MUST be on guard for this, by not allowing continually more information to be revealed unless it is clear that any LR is permitted by Alice to know all that Alice knows about her location. A limit on the number of such rejections to learn more location information SHOULD be configurable, with a RECOMMENDED maximum of three times for each related transaction. 💀 Boundaries, bestie.
A SIP intermediary that requires Alice's location in order to properly process Alice's INVITE also sends a 424 response with a Geolocation-Error code. This message flow is shown in Figure 4 of Section 3.4. 🧚
If more than one locationValue is present in a SIP request and at least one locationValue is determined to be valid by the LR, the location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is to be sent. 👑
Here's the initial list of location-based error code ranges for any SIP response, including provisional responses (other than 100 Trying) and the new 424 (Bad Location Information) response. These error codes are divided into three categories based on how the response receiver should react to them. There MUST be no more than one Geolocation-Error code in a SIP response, regardless of how many locationValues there are in the correlating SIP request. When more than one locationValue is present in a SIP request, this mechanism provides no indication of which one the Geolocation-Error code corresponds to. If multiple errors are present, the LR applies local policy to select one. 🍓
- 1XX errors mean the LR cannot process the location within the request:
A non-exclusive list of reasons for returning a 1XX is as follows:
- the location was not present or could not be found in the SIP request,
- there was not enough location information to determine where the Target was,
- the location information was corrupted or known to be inaccurate.
- 2XX errors mean some specific permission is necessary to process the included location information.
- 3XX errors mean there was trouble dereferencing the Location URI sent.
Dereference attempts to the same request SHOULD be limited to 10 attempts within a few minutes. This number SHOULD be configurable, but it results in a Geolocation-Error: 300 error once reached. ⏱️
It's worth noting that for non-INVITE transactions, the SIP response will likely be sent before the dereference response has been received. This document does not alter that SIP protocol reality. 🥲 This means the receiver of any non-INVITE response to a request containing location SHOULD NOT consider a 200 OK response to mean the act of dereferencing has concluded and the dereferencer (i.e., the LR) has successfully received and parsed the PIDF-LO for errors and found none. The end of Section 3.2 discusses how transaction timing considerations lead to this requirement.
Additionally, if an LR cannot or chooses not to process location from a SIP request, a 500 (Server Internal Error) SHOULD be used, with or without a configurable Retry-After header field. There is no special location error code for what already exists within SIP today. 🌈
Within each of these ranges, there is a top-level error as follows:
Geolocation-Error: 100 ; code="Cannot Process Location"
Geolocation-Error: 200 ; code="Permission To Use Location
Information"
Geolocation-Error: 300 ; code="Dereference Failure"If an error recipient cannot process a specific error code (such as the 201 or 202 below), perhaps because it doesn't understand that specific error code, the error recipient SHOULD process the error code as if it originally were a top-level error code where the X in X00 matches the specific error code. If the error recipient cannot process a non-100 error code, for whatever reason, then the error code 100 MUST be processed. 🫶
There are two specific Geolocation-Error codes included in this document, and both have to do with permissions necessary to process the SIP request. They are:
Geolocation-Error: 201 ; code="Permission To Retransmit Location
Information to a Third Party"This location error is specific to having the PIDF-LO [RFC4119] <retransmission-allowed> element set to "no". It's stating it requires permission (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request. 🔐
Geolocation-Error: 202 ; code="Permission to Route based on Location
Information"This location error is specific to having the Geolocation-Routing header value set to "no". It's stating it requires permission (i.e., the Geolocation-Routing header value set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request. 🚦
4.5. Location URIs in Message Bodies ✨
In the case where an LR sends a 424 response and wishes to communicate suitable location-by-reference rather than location-by-value, the 424 response MUST include a content-indirection body per RFC 4483. 📦
4.6. Location Profile Negotiation 🎀
The following is part of the discussion started in Section 3, Figure 2, which introduced the concept of sending location indirectly. 🧠
If a location URI is included in a SIP request, the sending user agent MUST also include a Supported header field indicating which location profiles it supports. Two option tags for location profiles are defined by this document: "geolocation-sip" and "geolocation-http". Future specifications MAY define further location profiles per the IANA policy described in Section 8.3. 🌟
The "geolocation-sip" option tag signals support for acquiring location information via the presence event package of SIP [RFC3856]. A location recipient who supports this option can send a SUBSCRIBE request and parse a resulting NOTIFY containing a PIDF-LO object. The URI schemes supported by this option include "sip", "sips", and "pres". 📡
The "geolocation-http" option tag signals support for acquiring location information via HTTP [RFC2616]. A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI schemes supported by this option include "http" and "https". A failure to parse the 200 response, for whatever reason, will return a "Dereference Failure" indication to the original location sending user agent to inform it that location was not delivered as intended. 💌
If the location URI receiver does not understand the URI scheme sent to it, it will return an Unsupported header value of the option tag from the SIP request, and include the option tag of the preferred URI scheme in the response's Supported header field. 🔁
See [GEO-FILTERS] or [HELD-DEREF] for more details on dereferencing location information. 🔗
5. Geolocation Examples 🦋
5.1. Location-by-Value (in Coordinate Format) ✨
okay so this example is an INVITE carrying a coordinate location 📍 The SIP request uses a sips-URI [RFC3261], which means this message is protected with Transport Layer Security (TLS) on a hop-by-hop basis 🔐 bestie, it's giving secure 💅
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com>
Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...Session Description Protocol (SDP) goes here
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--The Geolocation header field from the above INVITE:
Geolocation: <cid:target123@atlanta.example.com>...this tells you the content-ID location [RFC2392] inside the multipart message body where the location info lives 🗺️ The other body part is SDP. The cid: scheme eases message body parsing and disambiguates multiple parts of the same type, so nothing gets mixed up 🧚
If the Geolocation header field did not contain a cid: scheme, for example, it could look like this location URI:
Geolocation: <sips:target123@server5.atlanta.example.com>...the existence of a non-cid: scheme indicates this is a location URI, which needs to be dereferenced to learn the Target's location 🦋 Any node that wants to know where the target is would subscribe to the SIP presence event package [RFC3856] at:
sips:target123@server5.atlanta.example.com(see Figure 2 in Section 3.2 for this message flow 💜)
5.2. Two Locations Composed in Same Location Object Example 🌈
This example shows the INVITE message after a SIP intermediary rejected the original INVITE (say, the one in Section 5.1) 🙈 This INVITE contains the composed LO sent by the SIP intermediary, which includes where the intermediary understands Alice to be. The rules of RFC 5491 [RFC5491] are followed in this construction, so it's all very by-the-book ✨
This example is here, but ought not be taken as occurring very often. In fact, this example is believed to be a corner case of location conveyance applicability. So don't go thinking this is the everyday vibe 💀
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188512@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com>
Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml
CSeq: 31863 INVITE
Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP goes here
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
<dm:person id="target123">
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3>
<cl:RD>Treemont</cl:RD>
<cl:STS>Circle</cl:STS>
<cl:HNO>3913</cl:HNO>
<cl:FLR>1</cl:FLR>
<cl:NAM>Haley's Place</cl:NAM>
<cl:PC>76034</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>triangulation</gp:method>
</gp:geopriv>
<dm:timestamp>2010-11-04T12:28:04Z</dm:timestamp>
</dm:person>
</presence>
--boundary1--6. Geopriv Privacy Considerations 🔒
okay, real talk: location information is considered by most to be highly sensitive info 😭 It needs protection from eavesdropping and altering in transit. [RFC3693] originally laid out the rules any protocol wanting to be a "Using Protocol" has to follow, including how a transport protocol meets those rules 🫶 [RFC6280] then updates that guidance to cover entities and concepts that showed up later in the geolocation architecture 🌸
RFC 5606 explores the difficulties inherent in mapping the GEOPRIV architecture onto SIP elements. The tricky part is defining and identifying recipients of location information, and that doc goes through it all. It also gives guidance in Section 3.3.2 on using location-by-reference mechanisms to keep location information confidential from unauthorized recipients 🕵️♀️
In a SIP deployment, location information may be added by any of several elements, including the originating user agent or a proxy server. In all cases, the Rule Maker associated with that location information decides which entity adds it and what access control rules apply 👑 For example, a SIP user agent that doesn't support the Geolocation header may rely on a proxy server, under the direction of the Rule Maker, to add a Geolocation header with a reference to location information. How the Rule Maker operates on these devices is outside the scope of this document, so that's a different story 🧚
How SIP implementations honor the Rule Maker's stipulations for access control rules (including retention and retransmission) is application specific and not within the scope of SIP protocol operations 💅 Entities in SIP networks that fill the architectural roles of the Location Server or Location Recipient treat the privacy rules tied to location information per the guidance in [RFC6280], Section 4.2.1. In particular, RFC 4119 (especially Section 2.2.2) gives guidance for handling access control rules, and SIP implementations should furthermore consult the recommendations in RFC 5606 🦋
7. Security Considerations 🔐
Okay bestie, time for the serious bit 😭 Sharing someone's physical location is a huge privacy thing, and depending on what it's used for, there are probably authentication and integrity worries too 💀. So this doc asks for location to travel through secure mechanisms like S/MIME encrypting the message bodies (ngl, not widely deployed 🥲), TLS protecting the overall signaling, or conveyance by reference where every entity that dereferences the location has to authenticate itself 🔒.
Location-based routing is the tricky part 🙈. Encrypting the location payload end-to-end with something like S/MIME is a problem, because one or more proxies on the path need to read the location to retarget the message to the right new destination User Agent Server (UAS). You can only encrypt data for a specific, expected target. If several recipients need to inspect the same piece of data and the sender can't predict who they are, encryption just isn't very feasible 😩.
Securing the location hop-by-hop with TLS does protect the message from eavesdropping and modification in transit. But it also exposes the information to every proxy on the path, plus the endpoint 👀. The UA usually has no trust relationship with the proxy or proxies providing location-based routing, so those end-to-middle solutions might not be the right fit either 🫤.
When location is conveyed by reference, though, you can properly authenticate and authorize each entity that wants to look at it 🎀. The sender doesn't have to know ahead of time who will receive the data, and multiple entities can get it securely. It does not get rid of the need for some pre-association between the sender and any prospective recipients, though 🙅♀️. And in some contexts that pre-association just can't be assumed. When it can't, effectively unauthenticated access to location information MUST be permitted 🫶. In that case, using pseudorandom URIs for location-by-reference, plus path encryption like Session Initiation Protocol Secure (SIPS), can help make sure only the entities on the SIP signaling path learn the URI. That brings things back to rough parity with sending location-by-value ✨.
Location information is extra sensitive when the identity of its Target is obvious 🚨. According to [RFC3693], there's the ability to have an anonymous identity for the Target's location. This is done with an unlinkable pseudonym in the "entity=" attribute of the <presence> element [RFC4479]. But that can make routing messages based on location difficult (which [RFC4479] covers) 🤔. And anyone fishing for info could correlate the identity at the SIP layer with the location information referenced by the SIP signaling 🕵️♀️.
When a UA inserts location, the UA sets the policy on whether to reveal its location along the signaling path. That's discussed in Section 4, and it also involves flags in the PIDF-LO [RFC4119] 🎛️. UAC implementations MUST make these capabilities conditional on explicit user permission, and they MUST alert the user that location is being conveyed 🙋♀️📢. No cap, this part is non-negotiable.
This SIP extension gives a default ability to require permission to process location while the SIP request is in transit 🛑. The default for this is set to "no" 🙅. There's an error that explicitly describes how an intermediary asks for permission to view the Target's location, plus a rule saying the user has to be made aware of that permission request 💅.
There is no end-to-end integrity on any locationValue or locationErrorValue header field parameter (or middle-to-end if the value was inserted by an intermediary) 😱. So recipients of either header field need to implicitly trust the header field contents, and take whatever precautions each entity deems appropriate given this situation 🫠.
8. IANA Considerations 🧚
Here are the IANA considerations for this SIP extension 🌸. Any modifications or additions to all of these registrations require a Standards Track RFC (Standards Action) 📜.
8.1. IANA Registration for the SIP Geolocation Header Field
The SIP Geolocation header field is created by this document. Its definition and rules are in Section 4.1 of this document, and it's been added to the IANA sip-parameters registry like this 🎀.
The Header Fields registry has been updated with:
Header Name Compact Reference
----------------- ------- ---------
Geolocation [RFC6442]8.2. IANA Registration for the SIP Geolocation-Routing Header Field
The SIP Geolocation-Routing header field is created by this document. Its definition and rules are in Section 4.2 of this document, and it's been added to the IANA sip-parameters registry as follows 🦋.
The Header Fields registry has been updated with:
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Routing [RFC6442]8.3. IANA Registration for Location Profiles
This document defines two new SIP option tags, "geolocation-sip" and "geolocation-http" 🌈. They've been added to the IANA sip-parameters Options Tags registry like so ✨.
Name Description Reference
----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [RFC6442]
support for acquiring location information
via the presence event package of SIP
(RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI
schemes supported by this option include
"sip", "sips", and "pres".
geolocation-http The "geolocation-http" option tag signals [RFC6442]
support for acquiring location information
via HTTP (RFC 2616). A location
recipient who supports this option can
request location with an HTTP GET and
parse a resulting 200 response containing
a PIDF-LO object. The URI schemes
supported by this option include "http"
and "https".The names of profiles are SIP option tags. This document doesn't override the option tag assignment guidance in [RFC3261], which requires a Standards Action for assigning a new option tag 📋. However, this document does say that option tags used to convey the name of a location profile MUST begin with the string "geolocation" followed by a dash 💖. All of these tags should describe protocols used to acquire location by reference. They have nothing to do with location carried in SIP requests by value, which uses standard MIME typing and negotiation 🙃.
8.4. IANA Registration for 424 Response Code
In the SIP Response Codes registry, the following gets added 💜.
Reference: RFC 6442
Response code: 424 (recommended number to assign)
Default reason phrase: Bad Location Information
Registry:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [RFC6442]This SIP response code is defined in Section 4.3 of this document 🍓.
8.5. IANA Registration of New Geolocation-Error Header Field
The SIP Geolocation-Error header field is created by this document. Its definition and rules are in Section 4.4 of this document, and it gets added to the IANA sip-parameters registry with two actions 🔥.
- Update the Header Fields registry with:
Registry:
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Error [RFC6442]- In the portion titled "Header Field Parameters and Parameter Values", add:
Predefined
Header Field Parameter Name Values Reference
----------------- ------------------- ---------- ---------
Geolocation-Error code yes [RFC6442]8.6. IANA Registration for the SIP Geolocation-Error Codes
This document creates a new SIP registry called "Geolocation-Error Codes" 🎉. Geolocation-Error codes give the reason for an error discovered by Location Recipients, and they're categorized by the action the error recipient should take 🧠. The initial values for this registry are below.
Registry Name: Geolocation-Error Codes
Reference: [RFC6442]
Registration Procedures: Specification Required
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [RFC6442]
200 "Permission To Use Location Information" [RFC6442]
201 "Permission To Retransmit Location Information
to a Third Party" [RFC6442]
202 "Permission to Route based on Location Information" [RFC6442]
300 "Dereference Failure" [RFC6442]Details of these error codes are in Section 4.4 of this document 👑.
9. Acknowledgements 🫶
Huge thanks to Dave Oran for helping shape this idea 💖, and to Dean Willis for guiding the effort 🌷.
Thank you to Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, Jacqueline Lee, and Adam Roach for constructive feedback and nit checking 🧚♀️.
Special thanks to Paul Kyzivat for his help with the ABNF in this document, and to Robert Sparks for many helpful comments and for the proper construction of the Geolocation-Error header field 🌟.
And finally, to Spencer Dawkins for giving this document a good scrubbing to make it more readable 🧼✨.
10. References 📚
10.1. Normative References 📚
[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[RFC4119]Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2392]Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.[RFC3856]Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.[RFC3859]Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.[RFC3428]Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.[RFC3311]Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.[RFC3265]Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.[RFC6086]Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.[RFC3515]Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.[RFC3903]Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.[RFC5234]Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.[RFC4479]Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.[RFC4483]Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.[RFC5491]Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.[RFC5870]Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010.[RFC2616]Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
10.2. Informative References 🌸
[RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.[RFC2818]Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.[RFC5606]Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009.[GEO-FILTERS]Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in SIP", Work in Progress, March 2010.[HELD-DEREF]Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", Work in Progress, October 2011.[RFC6280]Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
Appendix A. Requirements for SIP Location Conveyance 🧚
okay so this part is the historical receipts 🧾✨ The next few subsections cover what the UAC, the UAS, and SIP proxies are each asked to do when conveying location. This text comes from an earlier draft of the location conveyance requirements, which later grew up into this document (RFC 6442). It's been kept around for historical reasons, so don't panic about it 🫶
If a requirement isn't obvious in what it's trying to do, there's a motivational statement right under it. Very helpful, very iconic 💅
A.1. Requirements for a UAC Conveying Location 💖
UAC-1The SIP INVITE Method [RFC3261] must support location conveyance.UAC-2The SIP MESSAGE method [RFC3428] must support location conveyance.UAC-3SIP Requests within a dialog should support location conveyance.UAC-4Other SIP Requests may support location conveyance.UAC-5There must be one, mandatory-to-implement means of transmitting location confidentially.
Motivation: To guarantee interoperability. 🤝
UAC-6It must be possible for a UAC to update location conveyed at any time in a dialog, including during dialog establishment.
Motivation: If a UAC has moved prior to the establishment of a dialog between UAs, the UAC must be able to send location information. If location has been conveyed, and the UA moves, the UAC must be able to update the location previously conveyed to other parties. 🚗💨
UAC-7The privacy and security rules established within [RFC3693] that would categorize SIP as a 'Using Protocol' MUST be met. 🔐UAC-8The PIDF-LO [RFC4119] is a mandatory-to-implement format for location conveyance within SIP.
Motivation: Interoperability with other IETF location protocols and Mechanisms. 🌈
UAC-9There must be a mechanism for the UAC to request the UAS send its location.
UAC-9 has been DEPRECATED by the SIP WG, due to the many problems this requirement would have caused if implemented. The solution is for the above UAS to send a new request to the original UAC with the UAS's location. 🙈
UAC-10There must be a mechanism to differentiate the ability of the UAC to convey location from the UACs lack of knowledge of its location.
Motivation: Failure to receive location when it is expected can happen because the UAC does not implement this extension, or because the UAC implements the extension, but does not know where the Target is. This may be, for example, due to the failure of the access network to provide a location acquisition mechanism the UAC supports. These cases must be differentiated. 🧠
UAC-11It must be possible to convey location to proxy servers along the path.
Motivation: Location-based routing. 🛣️
A.2. Requirements for a UAS Receiving Location 🎀
The following are the requirements for location conveyance by a UAS:
UAS-1SIP Responses must support location conveyance.
The SIPCORE WG reached consensus that this be allowed, but not to communicate the UAS's location; rather for a SIP intermediary to inform the UAC which location to include in its next SIP request (as a matter of correcting what was originally sent by the UAC). 🔁
UAS-2There must be a unique 4XX response informing the UAC it did not provide applicable location information.
In addition, requirements UAC-5, 6, 7, and 8 also apply to the UAS. ✨
A.3. Requirements for SIP Proxies and Intermediaries 🦋
The following are the requirements for location conveyance by a SIP proxies and intermediaries:
Proxy-1Proxy servers must be capable of adding a Location header field during processing of SIP requests.
Motivation: Provide network assertion of location when UACs are unable to do so, or when network assertion is more reliable than UAC assertion of location. 📡
Note: Because UACs connected to SIP signaling networks can have widely varying access network arrangements, including VPN tunnels and roaming mechanisms, it can be difficult for a network to reliably know the location of the endpoint. Proxies SHOULD NOT assert location of an endpoint unless the SIP signaling network has reliable knowledge of the actual location of the Targets. 🚨
Proxy-2There must be a unique 4XX response informing the UAC it did not provide applicable location information.
Authors' Addresses 💜
James Polk
Cisco Systems
3913 Treemont Circle
Colleyville, Texas 76034
33.00111N
96.68142W
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Brian Rosen
NeuStar, Inc.
470 Conrad Dr.
Mars, PA 16046
40.70497N
80.01252W
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Jon Peterson
NeuStar, Inc.
EMail: jon.peterson@neustar.bizAnd that's the whole RFC, bestie! 🌈👑 Thanks for hanging in there with me 🫶💖
📦 where this page comes from
- ietf: rfc6442 2011-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms