draft-ietf-sipcore-location-conveyance-02.txt | draft-ietf-sipcore-location-conveyance-03.txt | |||
---|---|---|---|---|
SIPCORE Working Group James Polk | Network Working Group James Polk | |||
Internet Draft Cisco Systems | Internet Draft Cisco Systems | |||
Expires: August 12, 2010 Brian Rosen | Expires: January 12, 2011 Brian Rosen | |||
Intended Status: Standards Track (PS) NeuStar | Intended Status: Standards Track (PS) Jon Peterson | |||
Feb 12, 2010 | NeuStar | |||
July 12, 2010 | ||||
Location Conveyance for the Session Initiation Protocol | Location Conveyance for the Session Initiation Protocol | |||
draft-ietf-sipcore-location-conveyance-02.txt | draft-ietf-sipcore-location-conveyance-03.txt | |||
Abstract | Abstract | |||
This document defines an extension to the Session Initiation | This document defines an extension to the Session Initiation | |||
Protocol (SIP) to convey geographic location information from one | Protocol (SIP) to convey geographic location information from one | |||
SIP entity to another SIP entity. The extension covers end-to-end | SIP entity to another SIP entity. The extension covers end-to-end | |||
conveyance as well as location-based routing, where SIP servers | conveyance as well as location-based routing, where SIP | |||
make routing decisions based upon the location of the user agent | intermediaries make routing decisions based upon the location of the | |||
client. | user agent client. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with | This Internet-Draft is submitted to IETF in full conformance with | |||
the provisions of BCP 78 and BCP 79. | the provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 42 | skipping to change at page 1, line 43 | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
reference material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on Aug 12, 2010. | This Internet-Draft will expire on Jan 12, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 26 | skipping to change at page 2, line 27 | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Conventions and Terminology used in this document . . . . . . 3 | 1. Conventions and Terminology used in this document . . . . . . 3 | |||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1 Scoping and Describing a Target verses a Device . . . . . 4 | 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 3 | |||
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 | 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 | |||
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 | 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 | |||
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8 | 4.2 424 (Bad Location Information) Response Code . . . . . . 9 | |||
4.2 424 (Bad Location Information) Response Code . . . . . . 12 | 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 | |||
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 12 | 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 12 | |||
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 24 | 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 12 | |||
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 24 | 4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 12 | |||
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 25 | 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 13 | |||
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 26 | 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 13 | |||
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 27 | 5.2 Two Locations Composed in Same Location Object Example . 14 | |||
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 28 | 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 16 | |||
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 28 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 33 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 | |||
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 38 | 8.1 IANA Registration for New SIP Geolocation Header . . . . 19 | |||
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 42 | 8.2 IANA Registration for New SIP 'geolocation' Option Tag . 19 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | 8.3 IANA Registration for New 424 Response Code . . . . . . . 19 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 | 8.4 IANA Registration for New SIP Geolocation-Error Header . 19 | |||
9.1 IANA Registration for New SIP Geolocation Header . . . . 45 | 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 19 | |||
9.2 IANA Registration for New SIP 'geolocation' Option Tag . 45 | 8.6 IANA Registration of Location URI Schemes . . . . . . . . 20 | |||
9.3 IANA Registration for New 424 Response Code . . . . . . . 45 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9.4 IANA Registration for New SIP Geolocation-Error Header . 45 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 46 | 10.1 Normative References . . . . . . . . . . . . . . . . . 21 | |||
9.6 IANA Registration of Location URI Schemes . . . . . . . . 47 | 10.2 Informative References . . . . . . . . . . . . . . . . . 22 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 | Author Information . . . . . . . . . . . . . . . . . . . . . 22 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | Appendix A. Requirements for SIP Location Conveyance . . . . 23 | |||
11.1 Normative References . . . . . . . . . . . . . . . . . 48 | ||||
11.2 Informative References . . . . . . . . . . . . . . . . . 49 | ||||
Author Information . . . . . . . . . . . . . . . . . . . . . 49 | ||||
Appendix A. Requirements for SIP Location Conveyance . . . . 50 | ||||
1. Conventions and Terminology used in this document | 1. Conventions and Terminology used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described | "OPTIONAL" in this document are to be interpreted as described | |||
in [RFC2119]. | in [RFC2119]. This document furthermore uses numerous terms defined | |||
in RFC 3693 [RFC3693], including Location Objection, Location | ||||
The following terms and acronyms used throughout this document are | Recipient, Location Server, Target, and Using Protocol. | |||
defined here: | ||||
LbyV: Location-by-Value | ||||
Location Generator (LG): The entity that initially determines or | ||||
gathers the location of the Target and creates Location | ||||
Objects describing the location of the Target [RFC3693]. | ||||
Location Inserter: a role created in this document describing the | ||||
entity that included location in a SIP request, either by-value | ||||
or by-reference (i.e., including a location URI). | ||||
Location Object (LO): An object conveying location information | ||||
(and possibly privacy rules) to which Geopriv security | ||||
mechanisms and privacy rules are to be applied [RFC3693]. | ||||
Location Recipient (LR): The entity that receives location | ||||
information. It may have asked for this location explicitly | ||||
(by sending a query to a location server), or it may receive | ||||
this location asynchronously [RFC3693]. | ||||
Location Server (LS): The entity to which a LG publishes location | ||||
objects, the recipient of queries from location receivers, and | ||||
the entity that applies rules designed by the rule maker | ||||
[RFC3693]. | ||||
A Location Server is also an entity that retains Target Location | ||||
Objects that are dereferenced by Location Recipients via SIP | ||||
SUB/NOT transactions. | ||||
Target: A person or other entity whose location is communicated by | ||||
a Geopriv Location Object [RFC3693]. | ||||
Using Protocol: A protocol that carries a Location Object [RFC3693]. | ||||
2. Introduction | 2. Introduction | |||
This document describes how geolocation can be "conveyed" in a SIP | Session Initiation Protocol (SIP) [RFC3261] creates, modifies and | |||
request from one SIP entity unsolicited to another entity using SIP | terminates multimedia sessions. SIP carries certain information | |||
[RFC3261]. Here, "Location" is a description of the physical | related to a session while establishing or maintaining calls. This | |||
geographical area where something currently exists. This | document defines how SIP conveys geographic location information of | |||
"something" is a Location Target. Note that this information is not | a Target (Target) to a Location Recipient (LR). SIP acts as a Using | |||
solicited (i.e., asked for or requested) by the entity that receives | Protocol of location information, as defined in RFC 3693. | |||
it. The mechanism in this document does not define how one SIP | ||||
entity requests the location of another SIP entity to be returned in | ||||
a response. | ||||
Geographic location in the IETF is discussed in RFC 3693 (Geopriv | ||||
Requirements) [RFC3693]. It defines a "Target" as the entity whose | ||||
location is being transmitted over IP. A [RFC3693]-defined "Using | ||||
Protocol" describes how a "Location Server" transmits a "Location | ||||
Object" to a "Location Recipient" while maintaining the contained | ||||
privacy intentions of the Target intact. This document describes a | ||||
SIP extension to carry a Location Object and how it complies with | ||||
the Using Protocol requirements in RFC 3693. | ||||
Common terms are in Section 1. Section 3 provides an overview of SIP | ||||
location conveyance. Section 4 details the extensions to SIP | ||||
necessary to accomplish location conveyance. Section 5 gives decode | ||||
examples of geolocation within SIP requests, both with a value and | ||||
with a reference. Section 6 articulates the SIP element type | ||||
behaviors for location conveyance. Section 7 discusses Geopriv | ||||
privacy considerations. Section 8 discusses security | ||||
considerations. Section 9 IANA registers the modifications made to | ||||
SIP by this document in section 4. | ||||
2.1 Scoping and Describing a Target verses a Device | ||||
Geographic location is related to a device, not to a user as far as | ||||
this document is concerned. When a user is logged onto a device, | ||||
the two entities are bound and can be said to be the same Location | ||||
Target - as far as this document is concerned. This document | ||||
specifies how one UA uses a SIP request to convey its whereabouts to | ||||
another UA. | ||||
Devices have a <device ID> element in a presence document for | ||||
identification, which is usually its MAC (or equivalent) address. | ||||
This element is not always present in the presence document. As | ||||
will be mentioned in Section 6.1, there are different ways to | ||||
identify a Target, including in the form of a SIP Contact address | ||||
(as defined by RFC 3261) or a pseudonym. | ||||
In SIP, we often interchangeably use the terms 'Alice' and '(the) | ||||
UA' to mean the same thing. Sometimes we refer to 'Alice the user', | ||||
which means the human, and not the SIP instance of an endpoint. | ||||
When we talk about 'Alice' without clarifying we are talking about | ||||
the human user, we implicitly bind Alice and the UA as the same | ||||
entity, even if she is identified with a pseudonym in SIP signaling. | ||||
This is common practice throughout most SIP documents. The Geopriv | ||||
architecture does not make this user-to-device binding very often in | ||||
its documentation. | ||||
The Geopriv architecture describes Location Targets (Target) and | ||||
Location Recipients (LR), which can easily fit into the SIP model by | ||||
having Alice send Bob her location. In this example, Alice is the | ||||
Target and Bob is the Location Recipient. Here, we are not | ||||
concerned with how a UA learns its location, either by being told | ||||
where it is or from an onboard GPS. This is exclusively within the | ||||
Geopriv architecture. | ||||
In this document, we allow SIP servers to insert the Target's | ||||
location while processing the SIP request towards the destination. | ||||
In this scenario, the originating UA (Alice) is always the Target. | ||||
The location inserting SIP server is not the Target. | ||||
We also allow SIP servers to be consumers of location, i.e., an LR, | ||||
for the purposes of making routing decisions based on the location | ||||
in a SIP request. | ||||
This document maintains the practice of other SIP documents by: | ||||
o a Target associated with a user has the inherited identity of | ||||
that user (i.e., Alice or Bob). The SIP-URI will generally be | ||||
similar to (or be) a Contact address, which could be a pseudonym | ||||
for the user; (see Section 6.1 for more on this) | ||||
o Alice is a UA, as is Bob. Understanding SIP signaling will | ||||
determine which is the UAC and which is the UAS. We specify | ||||
later that location can only be in a SIP request, even if that | ||||
request contains the location of more than one Target. | ||||
o a Target without an identifiable user associated with it is not | In order to convey location information, this document specifies a | |||
necessarily user-less, the binding is just not obvious or could | new SIP header, the Geolocation header, which carries a reference to | |||
purposely be a pseudonym (for security reasons) . The SIP-URI | a Location Object. That Location Object may appear in a MIME body | |||
will be more like a fully qualified Call-ID (unique through space | attached to the SIP request, or it may be a remote resource in the | |||
and time, as defined by RFC 3261); | network. | |||
o a Target which is user-less will likely have a SIP-URI, where the | Note that per RFC 3693, a Target is an entity whose location is | |||
user-part of the address is the MAC (or equivalent) address of | being conveyed. Thus, a Target could be a SIP user agent (UA), some | |||
the device, or a pseudo-string id, but still a URI for this | other IP device (a router or a PC) that does not have a SIP stack, a | |||
document's purpose; | non-IP device (a person or a black phone) or even a | |||
non-communications device (a building or store front). In no way | ||||
does this document assume that the SIP user agent client which sends | ||||
a request containing a location object is necessarily the Target. | ||||
The location of a Target conveyed within SIP typically corresponds | ||||
to that of a device controlled by the Target, for example, a mobile | ||||
phone, but such devices can be separated from their owners, and | ||||
moreover, in some cases the user agent may not know its own | ||||
location. | ||||
The above is informative in nature. | In the SIP context, a location recipient will most likely be a SIP | |||
UA, but due to the mediated nature of SIP architectures, location | ||||
information conveyed by a single SIP request may have multiple | ||||
recipients, as any SIP proxy server in the signaling path that | ||||
inspects the location of the Target must also be considered a | ||||
Location Recipient. In presence-like architectures, an intermediary | ||||
that receives publications of location information and distributes | ||||
them to watchers acts as a Location Server per RFC 3693. This | ||||
location conveyance mechanism can also be used to deliver URIs point | ||||
to such Location Servers where prospective Location Recipients can | ||||
request Location Objects. | ||||
3. Overview of SIP Location Conveyance | 3. Overview of SIP Location Conveyance | |||
An operational overview of SIP location conveyance can be shown in 4 | ||||
basic diagrams, with most applications falling under one of these | ||||
basic use cases. | ||||
The concept of conveying location in SIP is fairly straightforward. | Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob | |||
Location is conveyed directly or indirectly from a transmitting SIP | is an LR. A SIP intermediary appears in some of the diagrams. Any | |||
entity to a receiving SIP entity. When location is conveyed | SIP entity that receives and inspects location information is an LR, | |||
directly, it is conveyed as a value contained within the SIP | therefore any of the diagrams the SIP intermediary receives the SIP | |||
request, as in Figure 1. | request is potentially an LR - though that does not mean such an | |||
intermediary necessarily has to route the SIP request based on the | ||||
Alice Bob LS | location information. In some use cases, location information | |||
| | | | passes through the LS on the right of each diagram. | |||
| Request w/ Location | | | ||||
|------------------------>| | | ||||
| | | | ||||
| Response | | | ||||
|<------------------------| | | ||||
| | | | ||||
Figure 1. Location Conveyed by Value | Alice SIP Intermediary Bob LS | |||
| | | | | ||||
| Request w/Location | | | ||||
|----------------------------------->| | | ||||
| | | | ||||
| Response | | | ||||
|<-----------------------------------| | | ||||
| | | | | ||||
When location is conveyed indirectly, analogous to Content | Figure 1. Location Conveyed by Value | |||
Indirection [RFC4483], Bob receives (from Alice) a location URI and | ||||
must make an additional request - here called a dereference - to | ||||
learn Alice's actual location from a Location Server (LS) | ||||
identified in the location URI, as in Figure 2. | ||||
Alice Bob LS | In Figure 1, Alice is both the Target and the LS that is conveying | |||
| | | | her location directly to Bob, who acts as an LR. This conveyance is | |||
| Request w/ Location URI | | | point-to-point - it does not pass through any SIP-layer | |||
|------------------------>| | | intermediary. A Location Object appears by-value in the initial SIP | |||
| | Dereference Request | | request as a MIME body, and Bob responds to that SIP request as | |||
| |---------------------->| | appropriate. There is a 'Bad Location Information' response code | |||
| | | | introduced within this document to specifically inform Alice if she | |||
| | Dereference Response | | conveys bad location to Bob (i.e., Bob "cannot parse the location | |||
| |<----------------------| | provided", or "there is not enough location information to determine | |||
| Response | (includes location) | | where Alice is"). | |||
|<------------------------| | | ||||
| | | | ||||
Figure 2. Location Conveyed by Reference | Alice SIP Intermediary Bob LS | |||
| | | | | ||||
| Request w/Location URI | | | ||||
|----------------------------------->| | | ||||
| | Dereference | | ||||
| | Request | | ||||
| (To: Location URI) | | ||||
| |---------------->| | ||||
| | | | ||||
| | Dereference | | ||||
| | Response | | ||||
| (includes location) | | ||||
| |<----------------| | ||||
| Response | | | ||||
|<-----------------------------------| | | ||||
| | | | | ||||
Many protocols can be used for this dereference transaction, but | Figure 2. Location Conveyed as a Location URI | |||
this is usually determined by the scheme of the location URI in the | ||||
SIP request. In other words, if the location URI is a SIPS: URI, | ||||
then SIPS would be used to contact the LS to make the dereference. | ||||
The location "value" in this SIP extension is in the form of a | In Figure 2, location is conveyed indirectly, via a Location URI | |||
"Presence Information Data Format - Location Object", or PIDF-LO, as | carried in the SIP message (more of those details later). If Alice | |||
described in [RFC4119]. A PIDF-LO is an XML scheme specifically for | sends Bob this Location URI, Bob will need to dereference the URI - | |||
carrying the geographic location of a Target. LbyV refers to a UA | analogous to Content Indirection [RFC4483] - in order to request the | |||
including a PIDF-LO as a message body part of a SIP request, sending | location information. In general, the LS provides the location value | |||
that Location Object to another SIP element. A UA can included a | to Bob instead of Alice directly. From a user interface | |||
location URI in a SIP request header field, pointing at a Location | perspective, Bob the user won't know that this information was | |||
Server, which can be dereferenced by a Location Recipient of this | gathered from an LS indirectly rather than culled from the SIP | |||
location URI to retrieve Alice's Location Object, always in the form | request, and practically this does not impact the operation of | |||
of a PIDF-LO. | location-based applications. | |||
To accomplish location conveyance in SIP, a new SIP header field, | Alice SIP Intermediary Bob LS | |||
Geolocation, is created and described in this document. The | | | | | | |||
Geolocation header field contains a URI that points to where the | | Request | | | | |||
location is for the location Target, either in the body of the SIP | | w/Location | | | | |||
request itself, or on a Location Server. A URI to help entities | |--------------->| | | | |||
parse for the location in a SIP request will (always) get this in | | | Request | | | |||
the form of a "cid:" URI (Content Identification), as defined in | | | w/Location | | | |||
[RFC2392]. | | |------------------>| | | |||
| | | | | ||||
| | Response | | | ||||
| |<------------------| | | ||||
| Response | | | | ||||
|<---------------| | | | ||||
| | | | | ||||
If the URI in the Geolocation header field is a scheme other than | Figure 3. Location Conveyed though a SIP Intermediary | |||
"cid:", a dereference transaction (see Figure 2) is necessary. This | ||||
document describes how a SIP presence subscription [RFC3856] can be | ||||
used as a dereference protocol to retrieve the PIDF-LO for the | ||||
Target (see Section 4.5). | ||||
Location can be inserted in a SIP request by a SIP server as well as | In Figure 3, we introduce the idea of a SIP intermediary into the | |||
by a UA. This document offers guidance on this practice. This | example to illustrate the role of proxying in the location | |||
document also describes how a location recipient can determine which | architecture. This intermediary could be a SIP proxy or it could be | |||
entity included a specific location, as more than one location can | a back-to-back-user-agent (B2BUA). In this message flow, the SIP | |||
be conveyed in a given SIP request. Section 4 gets into guidance and | intermediary may act as a LR, in addition to Bob. The primary use | |||
limitations of this behavior. | case for intermediaries consuming location information is | |||
location-based routing. In this case, the intermediary chooses a | ||||
next hop for the SIP request by consulting a specialized location | ||||
service which selects forwarding destinations based on geographical | ||||
location. In this case, the intermediary acts as a Location | ||||
Recipient. | ||||
A new error response (424 Bad Location Information) is also defined | However, it can be the case that the SIP intermediary receives a | |||
in this document. Within this response is a new header field | request with location information (conveyed either by-value or | |||
indicating location-based errors, called the Geolocation-Error | by-reference) and does not know or care about Alice's location, or | |||
header field. This header field has various codes that provide | support this extension, and merely passes it on to Bob - in this | |||
additional information about the type of location error experienced | case, the intermediary does not act as a Location Recipient. | |||
by a Location Recipient, separated into actionable categories to be | ||||
taken by the UAC. | ||||
Because more than one SIP entity can insert location, when | Note that an intermediary does not have to perform location-based | |||
considering SIP as an end-to-end protocol, there needs to be a means | routing in order to be location recipient. It could be the case that | |||
of identifying which location within a message of multiple locations | a SIP intermediary which does not perform location-based routing but | |||
was considered bad by a location recipient - if that were to occur. | does care when Alice includes her location; for example, it could | |||
The ability to tell which entity (identified by host-id) inserted a | care that the location information is complete or that it correctly | |||
specific location is extremely important. Not only does this allow | identifies where Alice is. The best example of this is | |||
each location error to be Targeted at a particular inserter of a | intermediaries that verify location information for emergency | |||
specific location object, but it also allows error recipients to | calling, but it could also be for any location based routing - e.g., | |||
understand when the location they inserted was not at fault, and | contacting Pizza Hut, making sure that organization has Alice's | |||
that a received error is not meant for them. This optimization is | proper location in the initial SIP request. | |||
necessary, otherwise each location error would be a blanket error to | ||||
every entity upstream in the signaling path. | ||||
Just as location can be conveyed by more than one entity about the | If the SIP intermediary rejects the message due to unsuitable | |||
same Target, there can be more than one location recipient along a | location information (we are not going to discuss any other reasons | |||
request's path. It is possible to route SIP requests based on the | in this document, and there are many), the SIP response will | |||
location of the Target (i.e., source based routing, instead of | indicate there was 'Bad Location Information' in the SIP request, | |||
normal destination based routing). This means SIP servers can be | and provide a location specific error code indicating what Alice | |||
location recipients. If this is not desired by a Location Inserter, | needs to do to send an acceptable request. | |||
then the Location Inserter can also include a separate indication in | ||||
the Geolocation header field showing that this usage is not desired. | ||||
Location Inserters have the ability to provide instructional | Alice SIP Intermediary Bob LS | |||
parameters about location it has inserted. These are hints to | | | | | | |||
downstream entities on how the location information in the message | | Request | | | | |||
was originated, intended and is to be used. | | w/Location | | | | |||
|--------------->| | | | ||||
| | | | | ||||
| Rejected | | | | ||||
| w/New Location | | | | ||||
|<---------------| | | | ||||
| | | | | ||||
| Request | | | | ||||
| w/New Location | | | | ||||
|--------------->| | | | ||||
| | Request | | | ||||
| | w/New Location | | | ||||
| |------------------>| | | ||||
| | | | | ||||
Transport Layer Security is expected when a request contains a | Figure 4. SIP Intermediary Replacing Bad Location | |||
Target's location. Some implementations will choose to have S/MIME | ||||
for integrity protection, or to encrypt message bodies from source | ||||
to destination(s). | ||||
This document creates a new option tag: geolocation, to indicate | In this last use case, the SIP intermediary wishes to include a | |||
support for this extension by UAs. | Location Object indicating where it understands Alice to be. Thus, | |||
it must inform her user agent what location she should include in | ||||
any subsequent SIP request that contains her location. In these | ||||
cases, the intermediary can reject Alice's request, through the SIP | ||||
response, convey to her the best way to repair the request in order | ||||
for the intermediary to accept it. | ||||
The new header field, the header parameters, the new option tag, the | Overriding location information provided by the user requires a | |||
new error response, and Geolocation-Error codes are defined in | deployment where an intermediary necessarily knows better than an | |||
Section 4, each of which are IANA registered by this document. | end user - after all, it could be that Alice has an on-board GPS, | |||
and the SIP intermediary only knows her nearest cell tower. Which is | ||||
more accurate location information? Currently, there is no way to | ||||
tell which entity is more accurate, or which is wrong - for that | ||||
matter. This document will not specify how to indicate which | ||||
location is more accurate than another. If desired, intermediaries | ||||
may furthermore allow both Alice's internally generated location, as | ||||
well as the SIP intermediary's determination of where Alice, to | ||||
appear in the same SIP request (the resubmitted one), and permit | ||||
that to be forwarded to Bob. This case is discussed in more detail | ||||
in section 4.2 of this document. | ||||
RFC 3693 demands that a transmitted location be required to maintain | As an aside, it is not envisioned that any SIP-based emergency | |||
privacy considerations. This document maintains all of the privacy | services request (i.e., IP-911, or 112 type of call attempt) will | |||
considerations defined by RFC 3693, plus adds an intended usage | receive a corrective 'Bad Location Information' response from an | |||
indication within the SIP Geolocation header field. This increases | intermediary. Most likely, the SIP intermediary would in that | |||
the considerations for recipients not to inspect a Target's location | scenario act a B2BUA and insert into the request by-value any | |||
when they are not the intended location recipient. | appropriate location information for the benefit of Public Safety | |||
Answering Point (PSAP) call centers to expedite call reception by | ||||
the emergency services personnel; thereby, minimizing any delay in | ||||
call establishment time. The implementation of these specialized | ||||
deployments is, however, outside the scope of this document. | ||||
4. SIP Modifications for Geolocation Conveyance | 4. SIP Modifications for Geolocation Conveyance | |||
The following sections detail the standards track modifications | The following sections detail the modifications | |||
to SIP for Location Conveyance. | to SIP for location conveyance. | |||
4.1 The Geolocation Header Field | 4.1 The Geolocation Header | |||
This document defines Geolocation as a new SIP header field | This document defines "Geolocation" as a new SIP header field | |||
registered by IANA, with the following ABNF [RFC5234]: | registered by IANA, with the following ABNF [RFC5234]: | |||
Geolocation = "Geolocation" HCOLON (locationArg | Geolocation = "Geolocation" HCOLON locationArg | |||
*COMMA locationArg) | (*COMMA locationArg) | |||
locationArg = locationValue / routing-param | locationArg = locationValue / routing-param | |||
locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param | locationValue = LAQUOT locationURI RAQUOT | |||
*(SEMI geoloc-param) | *(SEMI geoloc-param) | |||
locationURI = sip-URI / sips-URI / pres-URI | locationURI = sip-URI / sips-URI / pres-URI | |||
/ cid-url ; (from RFC 2392) | / cid-url ; (from RFC 2392) | |||
/ absoluteURI ; (from RFC 3261) | / absoluteURI ; (from RFC 3261) | |||
inserted-param = "inserted-by" EQUAL geoloc-inserter | geoloc-param = generic-param; (from RFC 3261) | |||
geoloc-inserter = DQUOTE hostport DQUOTE | ||||
/ gen-value ; (from RFC 3261) | ||||
geoloc-param = "used-for-routing" / generic-param ; | ||||
(from RFC 3261) | ||||
routing-param = "routing-allowed" EQUAL "yes" / "no" | routing-param = "routing-allowed" EQUAL "yes" / "no" | |||
sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. | sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. | |||
The pres-URI is defined in [RFC3859]. | The pres-URI is defined in [RFC3859]. | |||
The cid-url is defined in [RFC2392] to locate message body | The cid-url is defined in [RFC2392] to locate message body parts. | |||
parts. This URI type is present in a SIP request when location | This URI type is present in a SIP request when location is conveyed | |||
is conveyed as a value. | as a MIME body in the SIP message. | |||
Other protocols used in the location URI MUST be reviewed against | ||||
the RFC 3693 [RFC 3693] criteria for a Using Protocol. | ||||
The Geolocation header field MAY have one or more locationValues. | ||||
SIP servers inserting a locationValue MUST add the new value as the | ||||
last locationValue in the Geolocation header field (i.e., the last | ||||
locationValue in the header field is the most recent one added to | ||||
the message). Placement of the "routing-allowed" parameter, when | ||||
present, MUST be the last header field value in the Geolocation | ||||
header field. | ||||
A locationValue has the following independent header field | ||||
parameters, | ||||
o the "inserted-by=" parameter provides the hostport | ||||
(alice.example.com -- which is the same as the "sent-by" | ||||
parameter in a Via header field, with or without a port number) | ||||
of the SIP entity that inserted this locationValue into the | ||||
request. If a Location Recipient has determined a supplied | ||||
location is in error, as there can be more than one location in | ||||
any request, the "inserted-by=" parameter is copied into the | ||||
locationErrorValue in the response indicating the location error, | ||||
and to whom the error is for. Hence, this "inserted-by=" | ||||
parameter MUST be present in each locationValue. If an entity | ||||
receives an Geolocation-Error with a hostport that does not | ||||
identify this entity, the Geolocation-Error MUST be ignored. | ||||
o the "used-for-routing" parameter to inform recipients that the | ||||
location in this locationValue was used to route the message | ||||
towards the ultimate destination UAS. "used-for-routing" can | ||||
occur more than once along the request's path. Because | ||||
locationValues are inserted as last inserted is last in the | ||||
header field, the last locationValue is the most recent one added | ||||
to the message. This also gives the "used-for-routing" header | ||||
field parameter added meaning - as the receiving SIP entity knows | ||||
which location URI the message was routed upon. | ||||
Each locationValue MUST contain exactly one "inserted-by" parameter, | ||||
indicating which SIP entity added the locationValue to the SIP | ||||
request. | ||||
There MUST NOT be more than one "inserted-by=" parameter or one | Other URI schemas used in the location URI MUST be reviewed against | |||
"used-for-routing" parameter in the same locationValue. However, | the RFC 3693 [RFC3693] criteria for a Using Protocol. | |||
there can be more than one locationValue in the same Geolocation | ||||
header field. | ||||
The "routing-allowed" header field parameter is a global parameter | The Geolocation header field has zero or one locationValue, but | |||
over any (and all/each) locationValues in the Geolocation header | MUST NOT contain more than one locationValue. | |||
field. The placement of the parameter is outside any locationValue, | ||||
appears only once, and is always last in the header field value. The | ||||
routing-allowed parameter MAY be present when no locationValue is | ||||
present. This scenario sets the routing-allowed policy downstream | ||||
along the request's signaling path. | ||||
This header field parameter only has the values "=yes" or "=no". | The placement of the "routing-allowed" header field parameter is | |||
When this parameter is "=yes", any locationValue can be used for | outside the locationValue, and MUST always be last in the header | |||
routing decisions along the downstream signaling path by | field value. The routing-allowed parameter MAY be present when no | |||
intermediaries. | locationValue is present. This scenario sets the routing-allowed | |||
policy downstream along the request's signaling path. This header | ||||
field parameter only has the values "=yes" or "=no". When this | ||||
parameter is "=yes", the locationValue can be used for routing | ||||
decisions along the downstream signaling path by intermediaries. | ||||
When this parameter is "=no", this means no locationValue (inserted | When this parameter is "=no", this means no locationValue (inserted | |||
by the originating UAC or any (or subsequent) intermediary(ies) | by the originating UAC or any intermediary along the signaling path | |||
along the signaling path) can be used by any SIP intermediary to | can be used by any SIP intermediary to make routing decisions. | |||
make routing decisions. This behavior MUST be adhered to. Sections | Intermediaries that attempt to use the location information for | |||
4.3 and 6.3 describe the details on what a routing intermediary does | routing purposes in spite of this counter indication may end up | |||
if it believes it needs to use the location in the SIP request in | routing the request improperly as a result. Sections 4.3 describes | |||
order to process the message further. | the details on what a routing intermediary does if it determines it | |||
needs to use the location in the SIP request in order to process the | ||||
message further. | ||||
The practical implication is that when the "routing-allowed" | The practical implication is that when the "routing-allowed" | |||
parameter is set to "no", if a cid:url is present in the SIP | parameter is set to "no", if a cid:url is present in the SIP | |||
request, intermediaries MUST NOT view the location (because it is | request, intermediaries MUST NOT view the location (because it is | |||
not for intermediaries to view), and if a location URI is present, | not for intermediaries to view), and if a location URI is present, | |||
intermediaries MUST NOT dereference it. UAs are allowed to view | intermediaries MUST NOT dereference it. UAs are allowed to view | |||
location in the SIP request even when the "routing-allowed" | location in the SIP request even when the "routing-allowed" | |||
parameter is set to "no". | parameter is set to "no". An LR MUST by default consider the | |||
"routing-allowed" header parameter as set to "no", with no | ||||
There MUST not be more than one routing-allowed parameter in any SIP | exceptions, unless the header field value is set to "yes". | |||
request, regardless of when there are cases of more than one | ||||
Geolocation header field row (i.e., more than one Geolocation | ||||
header in the SIP request, as defined in section 7.3.1 of RFC 3261). | ||||
There does not have to be any routing-allowed parameter present in a | ||||
Geolocation header value of a SIP request. However, the default | ||||
treatment of the absence of the routing-allowed parameter is as if | ||||
it were present, and set to "=no" without exception. | ||||
If a routing-allowed parameter is parsed as set to "=yes", an | If a routing-allowed parameter is parsed as set to "=yes", an | |||
implementation MUST parse the rest of the SIP header for another | implementation MUST parse the rest of the SIP headers for another | |||
instance of the Geolocation header value to determine if there is | instance of the Geolocation header value to determine if there is | |||
another instance of the routing-allowed parameter set to "=no". If | another instance of the routing-allowed parameter set to "=no". If | |||
this is the case, the behavior MUST be to process the "=no" | this is the case, the behavior MUST be to process the "=no" | |||
indication only, and ignore the "=yes". | indication only, and ignore the "=yes". | |||
This document defines the Geolocation header field as valid in the | This document defines the Geolocation header field as valid in the | |||
following SIP requests: | following SIP requests: | |||
INVITE [RFC3261], REGISTER [RFC3261], | INVITE [RFC3261], REGISTER [RFC3261], | |||
OPTIONS [RFC3261], BYE [RFC3261], | OPTIONS [RFC3261], BYE [RFC3261], | |||
UPDATE [RFC3311], INFO [RFC2976], | UPDATE [RFC3311], INFO [RFC2976], | |||
MESSAGE [RFC3428], REFER [RFC3515], | MESSAGE [RFC3428], REFER [RFC3515], | |||
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], | SUBSCRIBE [RFC3265], NOTIFY [RFC3265], | |||
PUBLISH [RFC3903] and PRACK [RFC3262] | PUBLISH [RFC3903], PRACK [RFC3262] | |||
Discussing location using the PUBLISH request is out of scope | ||||
for this document since it is part of Presence, therefore, for | ||||
completeness, Table 1 shows PUBLISH is to support Location | ||||
Conveyance via this extension, but is not discussed further. | ||||
The following table extends the values in Tables 2 and 3 of RFC 3261 | The following table extends the values in Tables 2 and 3 of RFC 3261 | |||
[RFC3261]. | [RFC3261]. | |||
Header field where proxy INV ACK CAN BYE REG OPT PRA | Header field where proxy INV ACK CAN BYE REG OPT PRA | |||
---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
Geolocation R ar o - - o o o o | Geolocation R ar o - - o o o o | |||
Header field where proxy SUB NOT UPD MSG REF INF PUB | Header field where proxy SUB NOT UPD MSG REF INF PUB | |||
---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
Geolocation R ar o o o o o o o | Geolocation R ar o o o o o o o | |||
Table 1: Summary of the Geolocation Header Field | Table 1: Summary of the Geolocation Header Field | |||
The Geolocation header field MAY be included in any one of the above | The Geolocation header field MAY be included in any one of the | |||
requests by a UA. A proxy MAY add the Geolocation header field, | optional requests by a UA. A proxy MAY add the Geolocation header | |||
but MUST NOT modify any pre-existing locationValue, including any | field, but MUST NOT modify any pre-existing locationValue, including | |||
associated header field parameters within an existing Geolocation | the "routing-allowed" header field value. | |||
header field value, unless one of the existing locationValues is | ||||
used to retarget the request towards a new destination UAS. This is | ||||
discussed in section 6.3. | ||||
[RFC3261] states message bodies cannot be added by proxies. | ||||
Therefore, any Geolocation header field added by a proxy MUST be in | ||||
the form of an location URI, in its own locationValue header field | ||||
value. | ||||
A SIP proxy MAY add a Geolocation header field if one is not | ||||
present, and MAY add the "routing-allowed" parameter if not yet | ||||
present in the SIP request. When a "routing-allowed" parameter is | ||||
already present in the SIP request, a SIP server MUST NOT change the | ||||
value of the parameter (i.e., from 'yes' to 'no', or from 'no' to | ||||
'yes'). This would override the policy set by an upstream SIP | ||||
entity (i.e., the UAC). | ||||
Adding a new locationValue to an in-transit request is NOT | ||||
RECOMMENDED for at least two reasons, | ||||
#1 SIP Servers are not the best geographic locators of where a | ||||
UA is; the location information that a SIP server knows might | ||||
not be the best location information available. | ||||
#2 this document gives limited guidance as to what a Location | ||||
Recipient should do when receiving more than one location (no | ||||
instructions are given about which locationValue to use when | ||||
more than one is present), so adding a new locationValue may | ||||
lead to undesirable results. | ||||
Location Recipients receiving a location object, whether received | A SIP intermediary MAY add a Geolocation header field if one is not | |||
directly or as the result of a dereference, MUST honor the usage | present - for example, when a user agent does not support the | |||
element rules within that XML document, as defined in [RFC4119]. | Geolocation mechanism but their outbound proxy does and knows their | |||
Such entities MUST NOT alter the rule set. | location, or any of a number of other use cases (see Figure 4 in | |||
section 3). When adding a Geolocation header, a SIP intermediary | ||||
MAY supply the "routing-allowed" parameter if not yet present in the | ||||
SIP request. | ||||
Other modifications of the Geolocation header field MUST NOT occur | SIP implementations are advised to pay special attention to the | |||
without an update to this specification. | policy elements for location retransmission and retention described | |||
in RFC 4119. | ||||
4.2 424 (Bad Location Information) Response Code | 4.2 424 (Bad Location Information) Response Code | |||
This SIP extension creates a new location specific response code, | This SIP extension creates a new location-specific response code, | |||
defined as follows. | defined as follows, | |||
424 (Bad Location Information) | 424 (Bad Location Information) | |||
The 424 (Bad Location Information) response code is a rejection of | The 424 (Bad Location Information) response code is a rejection of | |||
the request due to its location contents, indicating the location | the request due to its location contents, indicating location | |||
information was malformed or not satisfactory for the recipient's | information that was malformed or not satisfactory for the | |||
purpose, or could not be dereferenced. | recipient's purpose, or could not be dereferenced. | |||
Section 4.3 creates the Geolocation-Error header field to provide | A SIP intermediary can also reject a location it receives from a | |||
Target when it understands the Target to be in a different location. | ||||
The proper handling of this scenario is for the SIP intermediary to | ||||
include the proper location in the 424 Response. This SHOULD be | ||||
included in the response as a MIME message body (i.e., a location | ||||
value), rather than as a URI; however, in cases where the | ||||
intermediary is willing to share location with recipients but not | ||||
with a user agent, a reference might be necessary. | ||||
As mentioned in section 3 (below Figure 4), it might be the case | ||||
that the intermediary does not want to chance providing less | ||||
accurate location information than the user agent; thus it will | ||||
compose its understanding of where the user agent is in a separate | ||||
<geopriv> element of the same PIDF-LO message body of the SIP | ||||
response (which also contains the Target's version of where it is). | ||||
Therefore, both locations are included - each potentially with | ||||
different <method> elements. The proper reaction of the user agent | ||||
is to generate a new SIP request that includes this composed | ||||
location object, and send it towards the original LR. SIP | ||||
intermediaries can verify that subsequent requests properly insert | ||||
the suggested location information before forwarding said requests. | ||||
Section 4.3 describes a Geolocation-Error header field to provide | ||||
more detail about what was wrong with the location information in | more detail about what was wrong with the location information in | |||
the request. This header field MUST be in the 424 response, | the request. This header field MUST be included in the 424 response. | |||
containing a locationErrorValue for each invalid locationValue in | ||||
the request (i.e., and one-for-one matching if all locationValues | ||||
in the request were bad). | ||||
If more than one location is present in a request (value or location | The 424 is only appropriate when the Location Recipient needs a | |||
URI), and the Location Recipient can process any of the | locationValue and there are no locationValues included in a SIP | |||
locationValues, a 424 MUST NOT be sent. The 424 is only appropriate | request that are usable by a recipient, or as shown in Figure 4 of | |||
when the Location Recipient needs a locationValue and there are no | section 3, a SIP intermediary is informing the UA which location to | |||
locationValues included in a SIP request that are usable by a | include in the next SIP request. A 424 MUST NOT be sent in response | |||
recipient. | to a request that lacks a Geolocation header entirely, as the user | |||
agent in that case may not support this extension at all. | ||||
A 424 (Bad Location Information) response is a final response within | A 424 (Bad Location Information) response is a final response within | |||
a transaction, and does not terminate an existing dialog. | a transaction, and does not terminate an existing dialog. | |||
The UA can use whatever means it knows of to verify/refresh its | 4.3 The Geolocation-Error Header | |||
location information before attempting a new request that includes | ||||
location. There is no cross-transaction awareness expected by either | ||||
the UA or any SIP intermediary as a result of this error message. | ||||
The new 424 (Bad Location Information) error code is registered with | ||||
IANA in Section 8 of this document. An initial set of | ||||
IANA-registered Geolocation-Error codes are in Section 4.3 of this | ||||
document. | ||||
4.3 The Geolocation-Error Header Field | ||||
As discussed in Section 4.2, more granular error notifications, | As discussed in Section 4.2, more granular error notifications | |||
specific to location errors within a received request, are required | specific to location errors within a received request are required | |||
if the UA is to know what was wrong within the original request. | if the UA is to know what was wrong within the original request. | |||
The Geolocation-Error header field is used for this purpose. | The Geolocation-Error header field is used for this purpose. | |||
The Geolocation-Error header field is used to convey | The Geolocation-Error header field is used to convey | |||
location-specific errors within a response. Additional | location-specific errors within a response. The Geolocation-Error | |||
IANA-registered values must be defined in an RFC (this is the "RFC | ||||
Required" IANA policy defined in [RFC5226]). The Geolocation-Error | ||||
header field has the following ABNF [RFC5234]: | header field has the following ABNF [RFC5234]: | |||
Geolocation-Error = "Geolocation-Error" HCOLON | Geolocation-Error = "Geolocation-Error" HCOLON | |||
locationErrorValue | locationErrorValue | |||
*(COMMA locationErrorValue) | locationErrorValue = location-error-arg | |||
locationErrorValue = location-error-arg SEMI | ||||
node-param SEMI inserter-param | ||||
location-error-arg = location-error-code | location-error-arg = location-error-code | |||
*(SEMI location-error-params) | *(SEMI location-error-params) | |||
location-error-code = 1*3DIGIT | location-error-code = 1*3DIGIT | |||
location-error-params = location-error-code-text | location-error-params = location-error-code-text | |||
/ generic-param ; from RFC3261 | / generic-param ; from RFC3261 | |||
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 | location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 | |||
node-param = location-error-node-id | ||||
location-error-node-id = "node" EQUAL | ||||
DQOUTE hostport DQOUTE ; from RFC3261 | ||||
inserter-param = location-error-host-id | ||||
location-error-host-id = "inserter" EQUAL | ||||
DQOUTE hostport DQOUTE ; from RFC3261 | ||||
The Geolocation-Error header field MUST contain at least one | The Geolocation-Error header field MUST contain only one | |||
locationErrorValue to indicate what was wrong with the locationValue | locationErrorValue to indicate what was wrong with the locationValue | |||
in the corresponding request the Location Recipient determined was | the Location Recipient determined was bad. The locationErrorValue | |||
bad. Each locationErrorValue contains a 3-digit error code | contains a 3-digit error code indicating what was wrong with the | |||
indicating what was wrong with the location in the request. Each | location in the request. Each error code has a corresponding quoted | |||
error type has a corresponding quoted error text string that is | error text string that is human understandable. This text string is | |||
human understandable. This text string is OPTIONAL, but RECOMMENDED | OPTIONAL, but RECOMMENDED for human readability. | |||
for easy understanding. | ||||
Each locationErrorValue contains the Location Recipient identifier | ||||
(the "node=" parameter) which experienced the location error, as | ||||
well as an identifier of which SIP entity (the "inserter=" | ||||
parameter) the Location Recipient is told (in the locationValue) | ||||
added this problematic locationValue to the request. The "node=" | ||||
and "inserter=" are the domain identifier of a SIP entity, with the | ||||
ability to have the same host communicate on different ports - and | ||||
have port specific identification. This is the same information that | ||||
would be entered in the "sent-by" parameter of the Via header field | ||||
for that entity [RFC3261]. As stated in section 18 of RFC 3261, | ||||
the usage of FQDN is RECOMMENDED. Here are examples of both | ||||
locationErrorValue parameters, | ||||
node="bob.example.com" | ||||
inserter="alice.example.com" | ||||
Both the "node=" and "inserter=" parameters MUST be present in all | ||||
locationErrorValues in a response, unless the locationValue of the | ||||
request did not include the "inserted-by=" parameter (which is a | ||||
violation of this document). The "inserter=" parameter value is | ||||
copied from the "inserted-by=" parameter within the locationValue of | ||||
the request. This is required because a Location Recipient that | ||||
experienced a problem with the location included in a request needs | ||||
to tell the specific SIP entity which added the locationValue in | ||||
error into the original request. Since more than one SIP entity can | ||||
insert location into a request in transit, all other SIP elements | ||||
may be confused by receiving this error header field, were it to | ||||
remain generic to all entities in the response path. This | ||||
requirement means that the header field identifies the Location | ||||
Inserter who inserted the problematic locationValue, so that all | ||||
other SIP entities that read the header field know to ignore it. | ||||
This is of particular use if the original UAC did not include a | ||||
locationValue in the original SIP request, but a SIP server along | ||||
the path did insert a locationValue. The locationErrorValue would | ||||
be interpreted by each SIP entity along the original path upstream | ||||
and be processed by both the server that included the invalid | ||||
locationValue and the UAC that did not, resulting in confusion at | ||||
the UAC. | ||||
A worse case is when both the original UAC and a SIP server along | ||||
the path included a locationValue, but there was something | ||||
wrong with only one of the locationValues. Without an | ||||
identification of the specific locationValue in error, both entities | ||||
would react, and one would react incorrectly. | ||||
When more than one locationErrorValue is present in a | ||||
Geolocation-Error header field, they are separated by commas. | ||||
If more than one locationErrorValue is present in a response, and | ||||
intended for the same "inserter=", each error code MUST be unique to | ||||
this "inserter=" entity, and the error codes MUST NOT conflict in | ||||
meaning. | ||||
Here is an example of a Geolocation-Error header field: | ||||
Geolocation-Error: 200; code="Retry Location Later"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
The following table extends the values in Table 2&3 of RFC 3261 | The following table extends the values in Table 2&3 of RFC 3261 | |||
[RFC3261]. | [RFC3261]. | |||
Header field where proxy INV ACK CAN BYE REG OPT PRA | Header field where proxy INV ACK CAN BYE REG OPT PRA | |||
---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
Geolocation-Error r ar o - - o o o o | Geolocation-Error r ar o - - o o o o | |||
Header field where proxy SUB NOT UPD MSG REF INF PUB | Header field where proxy SUB NOT UPD MSG REF INF PUB | |||
---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
Geolocation-Error r ar o o o o o o o | Geolocation-Error r ar o o o o o o o | |||
Table 2: Summary of the Geolocation-Error Header Field | Table 2: Summary of the Geolocation-Error Header Field | |||
The Geolocation-Error header field MAY be included in any response | The Geolocation-Error header field MAY be included in any response | |||
to one of the above SIP requests, so long as Geolocation was in the | to one of the above SIP requests, so long as a Geolocation | |||
request part of the transaction. For example, Alice includes her | locationValue was in the request part of the transaction. For | |||
location in an INVITE to Bob. Bob can accept this INVITE, thus | example, Alice includes her location in an INVITE to Bob. Bob can | |||
creating a dialog, even though his UA determined the location | accept this INVITE, thus creating a dialog, even though his UA | |||
contained in the INVITE was bad. There is a Geolocation-Error | determined the location contained in the INVITE was bad. Bob merely | |||
header value in the 200 OK to the INVITE informing Alice the INVITE | includes a Geolocation-Error header value in the 200 OK to the | |||
was accepted but the location provided was bad. The SIP requests | INVITE informing Alice the INVITE was accepted but the location | |||
included in table 2 above are the ones allowed to optionally contain | provided was bad. The SIP requests included in table 2 above are the | |||
the Geolocation header field (see section 4.1). That said, a UAC | ones allowed to optionally contain the Geolocation header field (see | |||
MUST ignore a Geolocation-Error header field value that did not | section 4.1). | |||
contain its host-id.. | ||||
Here is an example of a transaction that has a location error. In | ||||
this case, Bob responds with a 424 (Bad Location Information) | ||||
response, including a Geolocation-Error header field, is in Figure 3. | ||||
Alice Bob | ||||
| | | ||||
| Request w/ Location | | ||||
|------------------------------------------------>| | ||||
| | | ||||
| | | ||||
| 424 (Bad Location Information) | | ||||
| with Geolocation-Error containing | | ||||
| 200 ("Retry Location Later with same data") | | ||||
|<------------------------------------------------| | ||||
| | | ||||
Figure 3. Basic Transaction with 424 and Geolocation-Error Header | If, on the other hand, Bob cannot accept Alice's INVITE without a | |||
Field | suitable location, a 424 (Bad Location Information) is sent. This | |||
message flow is shown in Figures 1, 2 or 3 in Section 3. | ||||
The following subsections provide an initial list of location | The following subsections provide an initial list of location | |||
based errors for any SIP non-100 response, including the new 424 | based errors for any SIP non-100 response, including the new 424 | |||
(Bad Location Information) response. These error codes are divided | (Bad Location Information) response. These error codes are divided | |||
into 5 categories, based on how the response receiver should react | into 4 categories, based on how the response receiver should react | |||
to these errors. | to these errors. | |||
We start with a general purpose location error, meaning we are not | o 1XX errors mean the LR cannot process the location within the | |||
being specific about what is wrong with the location provided, but | request. | |||
it has been determined to be bad. | ||||
o 1XX "Cannot Process Location" | ||||
We next have an error that indicates there is probably nothing wrong | ||||
with the location information provided, but the receiver cannot | ||||
process it at this time. A Retry-After header value will indicate | ||||
how long to wait until sending location again to this Location | ||||
Recipient and expect it to be processed. | ||||
o 2XX "Retry Location Later with same data" | ||||
We next have an indication that something was wrong with the | ||||
location information supplied in the SIP request, and something on | ||||
the sender's side needs to be done to correct the bad information. | ||||
A Retry-After header value will indicate when to resend the location | ||||
information. | ||||
o 3XX "Retry Location Later with updated device location" | ||||
We next have a permission flag contained with this SIP request | ||||
indicating an LR need permission to reveal this information to a 3rd | ||||
party (retransmission-allowed flag) or permission to view the | ||||
contained location to properly process the SIP request | ||||
(routing-allowed flag). We will define two individual errors here to | ||||
facilitate informing the "inserter=" which flag needs to be adjusted | ||||
if they want this SIP request processed further by this SIP entity. | ||||
o 4XX "Permission To Use Location Information" | ||||
Finally, we create a general location denial error, for times when a | ||||
dereference was denied or timed-out. | ||||
o 5XX "Location Information Denial" | ||||
All 5 of the above error codes MUST be implemented to comply with | ||||
this specification. Each of these actionable errors is given a 3 | ||||
digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, | ||||
and 5XX error codes defined will have the same action expected by | ||||
X00 categories, although the future error code may provide more | ||||
granular information. If another action is expected to occur with a | ||||
newly defined error code, it MUST outside the 100-599 range. | ||||
4.3.1 Location Error: 100 "Cannot Process Location" | ||||
The location error 100 "Cannot Process Location" indicates to a | ||||
Geolocation-Error recipient that the locationValue supplied in a | ||||
request cannot be processed at this time. This only has to do with | ||||
the location that the location "inserter=" added to the request, and | ||||
not about the overall request that was sent. | ||||
Action(s) to be taken by Geolocation-Error receiver for a 1XX: | ||||
This error gives no guidance on what to do next. It is a | ||||
general information indication to a SIP "inserter=" entity | ||||
that there was an unspecific problem with the location | ||||
supplied in the SIP request. | ||||
Implementations MAY choose to react as if the "inserter=" | ||||
entity received a 2XX or 3XX location error. Implementations MUST | ||||
NOT react as if the "inserter=" entity received a 4XX location | ||||
error, as that error category involves human intervention to grant, | ||||
or not, permission to reveal "inserter=" location when this is | ||||
likely not desired. | ||||
The text string of "Cannot Process Location" is RECOMMENDED, but not | ||||
mandatory for usage in this error. Implementations MAY use another | ||||
text string. | ||||
An example 100 location error is: | ||||
Geolocation-Error: 100; code="Cannot Process Location"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
This category covers all 1XX location errors. The same basic | ||||
reaction is expected when a location "inserter=" entity receives any | ||||
1XX location error. | ||||
4.3.2 Location Error: 200 "Retry Location Later same data" | ||||
The location error 200 "Retry Location Later same data" indicates | ||||
to a Geolocation-Error recipient that what they supplied in a | ||||
request, as far as location is concerned, cannot be processed at | ||||
this time, but there is no need to update the location at a later | ||||
time in a new SIP request. For example, this location error is | ||||
appropriate when the Location Recipient cannot process location at a | ||||
specific time, or when there is there was a timeout when a location | ||||
URI is dereferenced. | ||||
Action(s) to be taken by Geolocation-Error receiver for a 2XX: | ||||
Reactions to a 2XX location error are to try again after some | ||||
period of time has elapsed. The "inserter=" has not identified | ||||
problems with the location provided in the original request, | ||||
so there is no need to update this location unless the | ||||
requestor moves. A Retry-After header field MUST be present in | ||||
the 424 response indicating after how long the LR thinks it | ||||
can process the location, the error recipient MUST obey this | ||||
instruction. A Retry-After header value of '0' indicates try | ||||
again immediately. | ||||
Implementations SHOULD choose to react by queuing another message | ||||
with the same location information, unless the "inserter=" entity | ||||
knows it has changed locations. | ||||
Implementations MAY inform the user of this error. The text string | ||||
of "Retry Location Later same data" is RECOMMENDED, but not | ||||
mandatory for this error. Implementations MAY use another text | ||||
string to inform the user that location was not received by the UA | ||||
(i.e., the called party). | ||||
An example 200 location error is: | ||||
Geolocation-Error: 200; code="Retry Location Later same data"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
This category covers all 2XX location errors. The same basic | ||||
reaction is expected when a location "inserter=" entity receives any | ||||
2XX location error. | ||||
If a SIP request has the "routing-allowed" header field parameter | ||||
set to "no", and the SIP server believes processing location is | ||||
required in order to service the request properly, a 2XX location | ||||
error is sent towards the recipient. This error is the proper error | ||||
even when there is no location in the SIP request, but the SIP | ||||
request contains a policy statement that location is not to be | ||||
viewed during transit towards the ultimate destination. | ||||
4.3.2.1 Location Error: 201 "Linkable Target Identity Required" | ||||
The error code 201 "Linkable Target Identity Required" is | ||||
specifically for the event in which a SIP request requires a binding | ||||
of the Target's identity to the presence document in order to know | ||||
this is the Target's location to make an appropriate routing | ||||
decision. Because Alice could include Bob's location in her SIP | ||||
request, the SIP server - in this specific case - needs to | ||||
understand this message is routed based on Alice's location, and not | ||||
Bob's. There is no absolute binding between presence documents and | ||||
SIP signaling, hence a separate error with specific behaviors are | ||||
necessary. | ||||
It is of particular importance is the emergency calling case, | ||||
described here [ID-PHONE]. The presence document has a <presence> | ||||
element containing an "entity=" attribute identifying who the | ||||
presence document is about. The PIDF-LO is a presence document. | ||||
[RFC3693] allows unlinkable pseudonyms to be in the "entity=" | ||||
attribute. This is problematic for some (all?) source location based | ||||
call routing situations. | ||||
The "node=" routing intermediary makes this locationErrorValue a 201 | ||||
to resolve this problem. In the 424 response, the Retry-After header | ||||
value of '0' is REQUIRED, indicating the new request be sent | ||||
immediately, but with a Target identification resolved in the | ||||
PIDF-LO and SIP request. In presence, the "entity=" attribute is | ||||
typically the URI of the presentity, meaning something like the | ||||
Contact address of the UAC here. | ||||
If there is no Retry-After header value, the default is to resend | ||||
the SIP request immediately with the corrected "entity=" attribute | ||||
(i.e., emulating a Retry-After: 0 header value). | ||||
Action(s) to be taken by Geolocation-Error receiver for a 201: | ||||
201 location error indicate the "inserter=" did not properly | ||||
identify the Target of this presence document. The | ||||
Retry-After has been received - or is assumed to be 0 - | ||||
meaning the new SIP request is to be sent immediately. | ||||
4.3.3 Location Error: 300 "Retry Location Later with device updated | ||||
location" | ||||
The location error 300 "Retry Location Later with device updated | ||||
location" indicates to a Geolocation-Error recipient that what they | ||||
supplied in a request, as far as location is concerned, cannot be | ||||
processed. In order to retry this request in a new SIP request, the | ||||
location information must be updated. | ||||
Action(s) to be taken by Geolocation-Error receiver for a 3XX: | ||||
3XX location errors indicate the "inserter=" SIP entity needs | ||||
to refresh its location, or make the location information | ||||
supplied more complete, without notifying the user of this | ||||
error. 3XX errors may be resolved without user intervention. | ||||
This document gives no guidance how this is accomplished, given the | ||||
number of ways a UAC can learn its location, or a SIP intermediary | ||||
can determine this UAC's location (with or without the help of a | ||||
Location Server. | ||||
This 300 location error currently does not indicate what exactly was | ||||
wrong with the location supplied, according to the Location | ||||
Recipient. That is left for a future effort. | ||||
Implementations MAY choose whether or not to inform the user of this | ||||
error. The text string of "Retry Location Later with device updated | ||||
location" is RECOMMENDED, but not mandatory for usage in this | ||||
error. Implementation MAY use another text string to inform the | ||||
user that location was not received by the UA (i.e., the called | ||||
party). | ||||
A 3XX location error would be used where the Location Recipient | ||||
cannot find or cannot parse the location supplied. 3XX location | ||||
errors should cause a requestor to retry with refreshed location | ||||
information, which might be sufficient to fix the problem. Also, a | ||||
3XX location error would be used when a Location Recipient was | ||||
expecting to find location in a SIP request, but did not find it - | ||||
perhaps an emergency request was made that did not contain location. | ||||
The retry in this case would be in the form of an UPDATE Method | ||||
request, containing location. If the 424 response contains a | ||||
Retry-After value, there SHOULD NOT be a long delay associated with | ||||
a new request - under the guise that if the location had been good, | ||||
there would not have been an error to this request. | ||||
An example 300 location error is: | ||||
Geolocation-Error: 300; code="Retry Location Later with device | ||||
updated location"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
This category covers all 3XX location errors. The same basic | ||||
reaction is expected when a location "inserter=" entity receives any | ||||
3XX location error. | ||||
4.3.4 Location Error: 400 "Permission To Use Location Information" | ||||
The location error 400 "Permission To Use Location Information" | ||||
indicates to a Geolocation-Error recipient that they sent a | ||||
particular SIP Request including location in that request, without | ||||
giving permission in the request for an intermediary SIP entity to | ||||
look at that location information (i.e., the | ||||
<retransmission-allowed> was set to "no" in the PIDF-LO for B2BUAs, | ||||
or "routing-allowed=no" as a Geolocation header field parameter for | ||||
proxy servers) to route the request toward the intended recipient | ||||
(i.e., the called party). | ||||
All 4XX level location errors are asking for permission from the | ||||
"inserter=" to set a flag differently in order to accomplish | ||||
something with the location. | ||||
An example 400 location error is: | ||||
Geolocation-Error: 400; code="Permission To Use Location | ||||
Information"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
Because there are two completely separate flags known at this time, | ||||
one in the PIDF-LO (retransmission-allowed) and one as a Geolocation | ||||
header parameter (routing-allowed), two separate Locations Errors | ||||
are created to give the "inserter=" entity the specific choice to | ||||
reset the right flag. | ||||
4.3.4.1 Location Error: 401 "Permission To Retransmit Location | ||||
Information to a Third Party" | ||||
This location error is specific to having the PIDF-LO | ||||
<retransmission-allowed> element set to "=no". This location error | ||||
is asking for permission of the "inserter=" entity to resend the SIP | ||||
request with a PIDF-LO <retransmission-allowed> element set to | ||||
"=yes". | ||||
Action(s) to be taken by Geolocation-Error receiver for a 401: | ||||
The 401 location error indicates to the location "inserter=" | o 2XX errors mean the LR wants the LS to send new or updated | |||
that the LR (i.e., a UA or SIP intermediary server) needs to | location information, perhaps with a delay associated with when | |||
have permission to transmit the supplied location information | to send the request. | |||
to a third party. This indication MUST require human user | ||||
intervention, acting as the Ruleholder of the policy on | ||||
whether or not location is to be revealed. | ||||
The user of the location "inserter=" device can choose to grant | o 3XX errors mean some specific permission is necessary to process | |||
permission to the LR to allow this request to be sent on to another | the included location information. | |||
entity, or the user can deny permission. It is the user's choice as | ||||
Ruleholder. | ||||
Implementations MUST provide the user, as Ruleholder, a clear | o 4XX errors mean there was trouble dereferencing the Location URI | |||
indication that permission to consume their location is sought by an | sent. | |||
entity that is not the entity that the user is calling. The text | ||||
string of " Permission To Retransmit Location Information to a Third | ||||
Party " is RECOMMENDED, but not mandatory for this error. | ||||
Implementations MAY use another text string to inform the user that | ||||
location is being sought by an LR. | ||||
This document gives no guidance how the UA can seek permission from | All 4 of these error groups have a top level error code with the | |||
the user, given the number of ways a UA can accomplish this (i.e., | meaning as stated above (i.e., a Location Error: 100 is "Cannot | |||
audio prompt or toggle or keystroke on the UA). | Process Location", etc). There are two exceptions necessary to | |||
include in this document, both have to do with permissions necessary | ||||
to process the SIP request; they are | ||||
An example 401 location error is: | Location Error: 301 "Permission To Retransmit Location | |||
Information to a Third Party" | ||||
Geolocation-Error: 401; code="Permission To Retransmit Location | This location error is specific to having the Presence Information | |||
Information to a Third Party"; | Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set | |||
node="bob.example.com"; | to "=no". This location error is stating it requires permission | |||
inserter="alice.example.com"; | (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 reset | ||||
this permission in a new request. If the LS wants this message | ||||
processed without this permission reset, it MUST choose another | ||||
logical path (if one exists). | ||||
4.3.4.2 Location Error: 402 "Permission to Route based on Location | Location Error: 302 "Permission to Route based on Location | |||
Information" | Information" | |||
This location error is specific to having the locationValue header | This location error is specific to having the locationValue header | |||
parameter <routing-allowed> set to "=no". This location error is | parameter <routing-allowed> set to "=no". This location error is | |||
asking for permission of the "inserter=" entity to resend the SIP | stating it requires permission (i.e., a <routing-allowed> set to | |||
request with a locationValue header parameter <routing-allowed> set | "=yes") to process this SIP request further. If the LS sending the | |||
to "=yes". | location information does not want to give this permission, it will | |||
not reset this permission in a new request. If the LS wants this | ||||
Action(s) to be taken by Geolocation-Error receiver for a 402: | message processed without this permission reset, it MUST choose | |||
another logical path (if one exists). | ||||
The 402 location error indicates to the location "inserter=" | ||||
that the LR (i.e., SIP intermediary server) needs to have | ||||
permission in to look at and use the supplied location to | ||||
complete the message routing. This indication MUST require | ||||
human user intervention, acting as the Ruleholder of the | ||||
policy on whether or not location is to be revealed. | ||||
The user of the location "inserter=" can choose to grant permission | ||||
to this SIP intermediary server to allow this request to be routed, | ||||
or the user can deny permission. It is the user's choice as | ||||
Ruleholder. | ||||
Implementations MUST provide the user, as Ruleholder, a clear | ||||
indication that permission to consume their location is sought by an | ||||
entity that is not the entity that the user is calling. The text | ||||
string of "Permission to Route based on Location Information" is | ||||
RECOMMENDED, but not mandatory for usage in this error. | ||||
Implementations MAY use another text string to inform the user that | ||||
location is being sought by an intermediary (i.e., not the called | ||||
party). | ||||
This document gives no guidance how the UA can seek permission from | ||||
the user, given the number of ways a UA can accomplish this (i.e., | ||||
audio prompt or toggle or keystroke on the UA). | ||||
This 402 location error indicates which specific SIP server needs | ||||
the location by the "node=" FQDN address supplied, perhaps telling | ||||
the user (via audio or video indication) which SIP entity wants its | ||||
location learned for routing purposes. Perhaps the user can know in | ||||
some circumstances whether this is an appropriate "node=" (domain). | ||||
This latter feature is not described in this document (just | ||||
mentioned here as a possibility). | ||||
An example 402 location error is: | ||||
Geolocation-Error: 402; code="Permission to Route based on | ||||
Location Information"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
4.3.5 Location Error: 500 "Location Information Denial" | ||||
The location error 500 "Location Information Denial" indicates to a | ||||
Geolocation-Error recipient that what they supplied in a request, as | ||||
far as location is concerned, has been denied at this time. | ||||
This only has to do with the location that the location "inserter=" | ||||
added to the request, and not about the overall request that was | ||||
sent. If this were applied to the SIP request itself, this would | ||||
equate to a 6XX Global error. | ||||
Action(s) to be taken by Geolocation-Error receiver for a 5XX: | ||||
This error gives no guidance on what to do next, other than to | ||||
not try again with this same location supplied. | ||||
If the Location Recipient determined that merely refreshing, or in | ||||
some other way alter or augment the location supplied would work in | ||||
a new request, then a 3XX location error would have been more | ||||
appropriate. An example of why this 5XX could have been returned is | ||||
if location were sent as a location URI, and the LS denied the | ||||
dereference request from the potential Location Recipient, this is | ||||
the expected location error returned to the "inserter=" entity. In | ||||
all likelihood, this is a dereference function error, meaning this | ||||
will not occur when location is carried by-value in the request. | ||||
Implementations MUST NOT make any assumptions about the implications | ||||
of this location error other than recognizing that a location based | ||||
denial error has occurred. This does not mean the SIP request was | ||||
denied, or even had an error, unless the response was a 424. | ||||
Otherwise, this only has to do with the location part of the | ||||
request. | ||||
The difference between a 1XX and a 5XX location error is simple. A | ||||
1XX location error is appropriate when a Location Recipient either | ||||
does not know or cannot tell the "inserter=" entity what was wrong | ||||
with the location supplied in a SIP request. A 5XX location error | ||||
is appropriate when the Location Recipient was purposely and | ||||
actively prevented from retrieving the location information. This | ||||
could occur in a UA or SIP server. | ||||
If implementations choose to inform the UA user of this error, the | ||||
text string of "Location Information Denial" is RECOMMENDED, but not | ||||
mandatory for usage in this error. Implementations MAY use another | ||||
text string. | ||||
An example of this location error is here: | ||||
Geolocation-Error: 500; code="Location Information Denial"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
This category covers 5XX location errors. The same basic reaction | ||||
is expected when a location "inserter=" entity receives any 5XX | ||||
location error. | ||||
4.3.6 Which Scenario Matches Which Error Code? | ||||
The following scenario/error code mapping MUST be used for | 4.4 The 'geolocation' Option Tag | |||
consistency, | ||||
- Scheme (sip:, or sips:, or pres:, etc.) of the location URI | This document creates and registers with the IANA one new option | |||
is not supported - (100) | tag: "geolocation". This option tag is to be used, as defined in | |||
- Format (geo or civic) is not supported - (100) | [RFC3261], in the Require, Supported and Unsupported header fields. | |||
- Found where location information should be in the request, but do | ||||
not understand what is at that part of the request -(300) | ||||
- Cannot find LS in location URI (no access or no path) - (100) or | ||||
denied access - (500)) | ||||
- Dereference failed (timeout) - (200) | 4.5 Location URIs in Message Bodies | |||
- Insufficient location info supplied - (300) | ||||
4.4 The 'geolocation' Option Tag | In the case where a location recipient sends a 424 response and | |||
wishes to communicate suitable location by reference rather than by | ||||
value, the 424 MUST include a content-indirection body per RFC 4483. | ||||
This document creates and IANA registers one new option tag: | 4.6 Location URIs Allowed | |||
"geolocation". This option tag is to be used, as defined in | ||||
[RFC3261], in the Require, Supported and Unsupported header fields. | ||||
4.5 Using sip/sips/pres as a Dereference Scheme | The following is part of the discussion started in Section 3, Figure | |||
2, which initiated the concept of sending location indirectly. | ||||
If a location URI is included in a SIP request, it MUST be a SIP-, | If a location URI is included in a SIP request, it MUST be a SIP-, | |||
SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if | SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if | |||
the resulting resolution resolves to a SIP: or SIPS: URI, this | the resulting resolution resolves to a SIP: or SIPS: URI, this | |||
section applies. | section applies. These schemes MUST be implemented according to | |||
this document. | ||||
This document IANA registers 3 mandatory-to-implement URI schemes | ||||
for a location URI: | ||||
o SIP: | ||||
o SIPS: | ||||
o PRES: | ||||
These 3 are registered with IANA in Section 9.6. | ||||
These schemes MUST be implemented according to this document. | ||||
absoluteURI is not mandatory-to-implement, but allowed. | absoluteURI is not mandatory-to-implement, but allowed. | |||
Dereferencing a Target's location using SIP- or SIPS-URI is | See [ID-GEO-FILTERS] for more details on dereferencing location. | |||
accomplished by treating the URI as a PRES-URI and generating a | ||||
SUBSCRIBE request to a presence server as defined in [RFC3856] | ||||
using the 'presence' event package. The resulting NOTIFY MUST | ||||
contain a PIDF-LO. See Figure 4 for a basic message flow for a | ||||
dereference. The NOTIFY contains Alice's PIDF-LO in Figure 4. | ||||
When used in this manner, SIP is a Using Protocol as defined in | ||||
[RFC3693] and elements receiving location MUST honor the | ||||
'usage-element' rules as defined in this specification. | ||||
Alice Location Server Bob | ||||
| | | ||||
| INVITE w/ Location URI | | ||||
|-------------------------------------------------------->| | ||||
| | | | ||||
| | SUBSCRIBE to location URI | | ||||
| |<-----------------------------| | ||||
| | 200 (OK) | | ||||
| |----------------------------->| | ||||
| | | | ||||
| | NOTIFY w/ PIDF-LO | | ||||
| |----------------------------->| | ||||
| | 200 (OK) | | ||||
| |<-----------------------------| | ||||
| | | | ||||
| 200 (OK) | | ||||
|<--------------------------------------------------------| | ||||
| | | | ||||
Figure 4. Location-by-Reference and Dereferencing | ||||
In Figure 4, Alice sends Bob her location as a location URI. Bob | ||||
receives this location URI in the INVITE and generates a new | ||||
transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO. If accepted, | ||||
the PIDF-LO will be returned in the NOTIFY request from the Location | ||||
Server to Bob's UA. This is the first instance between Alice and | ||||
Bob that Alice's location is in any message. | ||||
The SUBSCRIBE contains a geolocation option tag in either the | ||||
Supported or Require header field (depending on what strength of | ||||
support the UA requires). The NOTIFY MUST match the subscribing | ||||
UA's option-tag strength for geolocation. | ||||
A dereference of a location URI using SUBSCRIBE is not violating a | ||||
PIDF-LO 'retransmission-allowed' element value set to 'no', as the | ||||
NOTIFY is the only message in this multi-message set of transactions | ||||
that contains the Target's location, with the location recipient | ||||
being the only SIP element to receive this PIDF-LO. This is the | ||||
purpose of this extension to SIP - to convey location to a specific | ||||
destination. | ||||
Certain nuances about this subscription exist that will not be | ||||
covered in this document. Instead these additional functions will be | ||||
described in the following document: [ID-GEO-FILTERS]. Here we | ||||
introduce the general concept; the "Filters" document has the | ||||
details. These two are consistent with each other. | ||||
5. Geolocation Examples | ||||
This section contains are two examples of messages providing | ||||
location. One shows LbyV with coordinates, the other shows | ||||
dereferencable location URI. The example for (Coordinate format) is | ||||
taken from [RFC3825]. A Civic-format example of the same position on | ||||
the earth as is in the coordinate format example is in appendix B, | ||||
which is taken from [RFC4776]. The differences between the two | ||||
formats appear within the <gp:location-info> in the examples. Other | ||||
than this portion of each PIDF-LO, the rest is the same for both | ||||
location formats. | ||||
The key to the provided samples is in the Geolocation header field, | 5. Geolocation Example | |||
which has a different type of URI, based on the different means of | ||||
location conveyance. Section 5.1 shows a "cid:" URI, indicating | ||||
this SIP request contains an LbyV message body - which is in the | ||||
form of a PIDF-LO. Section 5.2 shows an location URI indicating | ||||
location is to be acquired via an indirection dereference mechanism, | ||||
which is determined by the scheme of URI supplied. | ||||
5.1 Location-by-value (Coordinate Format) | 5.1 Location-by-value (in Coordinate Format) | |||
This example shows an INVITE message with a coordinate location. In | This example shows an INVITE message with a coordinate location. In | |||
this example, the SIP request uses a sips-URI [RFC3261], meaning | this example, the SIP request uses a sips-URI [RFC3261], meaning | |||
this message is protected using TLS on a hop-by-hop basis. | this message is protected using TLS on a hop-by-hop basis. | |||
INVITE sips:bob@biloxi.example.com SIP/2.0 | INVITE sips:bob@biloxi.example.com SIP/2.0 | |||
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 | Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 | |||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sips:bob@biloxi.example.com> | To: Bob <sips:bob@biloxi.example.com> | |||
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | |||
Call-ID: 3848276298220188511@atlanta.example.com | Call-ID: 3848276298220188511@atlanta.example.com | |||
Geolocation: <cid:target123@atlanta.example.com> | Geolocation: <cid:target123@atlanta.example.com> | |||
;inserted-by="alice@atlanta.example.com" | ;routing-allowed=no | |||
,routing-allowed=no | ||||
Supported: geolocation | Supported: geolocation | |||
Accept: application/sdp, application/pidf+xml | Accept: application/sdp, application/pidf+xml | |||
CSeq: 31862 INVITE | CSeq: 31862 INVITE | |||
Contact: <sips:alice@atlanta.example.com> | Contact: <sips:alice@atlanta.example.com> | |||
Content-Type: multipart/mixed; boundary=boundary1 | Content-Type: multipart/mixed; boundary=boundary1 | |||
Content-Length: ... | Content-Length: ... | |||
--boundary1 | --boundary1 | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
skipping to change at page 26, line 50 | skipping to change at page 13, line 52 | |||
Content-Type: application/pidf+xml | Content-Type: application/pidf+xml | |||
Content-ID: <target123@atlanta.example.com> | Content-ID: <target123@atlanta.example.com> | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<presence xmlns="urn:ietf:params:xml:ns:pidf" | <presence xmlns="urn:ietf:params:xml:ns:pidf" | |||
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" | xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" | |||
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" | xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" | |||
xmlns:gml="http://www.opengis.net/gml" | xmlns:gml="http://www.opengis.net/gml" | |||
entity="pres:alice@atlanta.example.com"> | entity="pres:alice@atlanta.example.com"> | |||
<tuple id="target123"> | <tuple id="target123"> | |||
<status> | <dm:device id="target123-1"> | |||
<gp:geopriv> | <gp:geopriv> | |||
<gp:location-info> | <gp:location-info> | |||
<gml:location> | <gml:location> | |||
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> | <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> | |||
<gml:pos>33.001111 -96.68142</gml:pos> | <gml:pos>32.86726 -97.16054</gml:pos> | |||
</gml:Point> | </gml:Point> | |||
</gml:location> | </gml:location> | |||
</gp:location-info> | </gp:location-info> | |||
<gp:usage-rules> | <gp:usage-rules> | |||
<gp:retransmission-allowed>no</gp:retransmission-allowed> | <gp:retransmission-allowed>no</gp:retransmission-allowed> | |||
<gp:retention-expiry>2010-02-12T06:00:00Z</gp:retention- | <gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- | |||
expiry> | expiry> | |||
</gp:usage-rules> | </gp:usage-rules> | |||
<gp:method>802.11</gp:method> | <gp:method>802.11</gp:method> | |||
</gp:geopriv> | </gp:geopriv> | |||
</status> | <dm:deviceID>mac:1234567890ab</dm:deviceID> | |||
<timestamp>2010-02-12T04:00:00Z</timestamp> | <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp> | |||
</dm:device> | ||||
</tuple> | </tuple> | |||
</presence> | </presence> | |||
--boundary1-- | --boundary1-- | |||
The Geolocation header field from the above INVITE: | The Geolocation header field from the above INVITE: | |||
Geolocation: <cid:target123@atlanta.example.com> | Geolocation: <cid:target123@atlanta.example.com> | |||
... indicates the content-ID location [RFC2392] within the multipart | ... indicates the content-ID location [RFC2392] within the multipart | |||
message body of where location information is, with SDP being the | message body of where location information is. An assumption can be | |||
other message body part. The "cid:" eases message body parsing. | made that SDP is the other message body part. The "cid:" eases | |||
message body parsing by disambiguating the MIME body that contains | ||||
the location information associated with this request. | ||||
If the Geolocation header field did not contain a "cid:" scheme, for | If the Geolocation header field did not contain a "cid:" scheme, for | |||
example, like this location URI: | example, it could look like this location URI: | |||
Geolocation: <sips:server5.atlanta.example.com/target123> | Geolocation: <sips:target123@server5.atlanta.example.com> | |||
... the existence of a non-"cid:" scheme indicates this is a | ... the existence of a non-"cid:" scheme indicates this is a | |||
location URI, to be dereferenced to learn the Target's location. Any | location URI, to be dereferenced to learn the Target's location. Any | |||
node wanting to know where user "target123" is would subscribe to | node wanting to know where user "target123" is would subscribe to | |||
server5 to dereference the sips-URI (see Figure 4 for this message | that user at server5 to dereference the sips-URI (see Figure 3 in | |||
flow, and Section 5.2 for this decoded example). The returning | section 3 for this message flow). | |||
NOTIFY would contain Alice's location in a PIDF-LO, as if it were | ||||
included in a message body (part) of the original INVITE. | ||||
5.2 Location-by-reference | 5.2 Two Locations Composed in Same Location Object Example | |||
Below is an INVITE request with a location URI that is not a "cid:" | This example shows the INVITE message after a SIP intermediary | |||
- instead of an LbyV PIDF-LO message body part as shown in Section | rejected the original INVITE (say, the one in section 5.1). This | |||
5.1. The Location Recipient will dereference Alice's location at | INVITE contains the composed LO sent by the SIP intermediary which | |||
the Atlanta Location Server the location URI is pointing towards. | includes where the intermediary understands Alice to be. The rules | |||
Dereferencing, if done using SIP, is accomplished by the Location | of RFC 5491 [RFC5491] are followed in this construction. | |||
Recipient sending a SUBSCRIBE request to the URI reference for | ||||
Alice's location. The received NOTIFY is the first SIP request | This example is here, but should not be taken as occurring very | |||
containing Alice's UA location, as a PIDF-LO message body (see | often. In fact, this is believed to be a corner case of location | |||
Figure 4 for this message flow example). The NOTIFY, in this case, | conveyance applicability. | |||
and not the INVITE, is the SIP request that is conveying location. | ||||
There is no retransmission of location in this usage. | ||||
INVITE sips:bob@biloxi.example.com SIP/2.0 | INVITE sips:bob@biloxi.example.com SIP/2.0 | |||
Via: SIP/2.0/TLS pc33.atlanta.example.com | Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 | |||
;branch=z9hG4bK74bf9 | ||||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sips:bob@biloxi.example.com> | To: Bob <sips:bob@biloxi.example.com> | |||
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | |||
Call-ID: 3848276298220188511@atlanta.example.com | Call-ID: 3848276298220188512@atlanta.example.com | |||
Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com> | Geolocation: <cid:target123@atlanta.example.com> | |||
;inserted-by="bigbox3.atlanta.example.com" | ;routing-allowed=no | |||
,routing-allowed=no | ||||
Supported: geolocation | Supported: geolocation | |||
Accept: application/sdp, application/pidf+xml | Accept: application/sdp, application/pidf+xml | |||
CSeq: 31862 INVITE | CSeq: 31863 INVITE | |||
Contact: <sips:alice@pc33.atlanta.example.com> | Contact: <sips:alice@atlanta.example.com> | |||
Content-Type: multipart/mixed; boundary=boundary1 | ||||
(...SDP goes here as the only message body) | Content-Length: ... | |||
A Location Recipient would need to dereference the sips-URI in the | ||||
Geolocation header field to retrieve Alice's location. If the | ||||
atlanta.example.com domain chooses to implement location conveyance | ||||
and delivery in this fashion, it is RECOMMENDED that entities | ||||
outside this domain be able to reach the dereference server, unless | ||||
location is intentionally restricted within the atlanta.example.com | ||||
domain. | ||||
6. SIP Element Behavior | ||||
Because a device's location is generally considered to be sensitive | ||||
in nature, location information needs to be protected when | ||||
transmitted. This can be addressed through securing the location | ||||
information to prevent either viewing or changing the PIDF-LO. | ||||
Section 26 of [RFC3261] defines the SIPS security functionality by | ||||
transporting SIP messages with either TLS protection between SIP | ||||
entities. | ||||
If a SIP entity wants to prevent all SIP entities in a request path | ||||
that do not possess a decryption key from viewing or changing the | ||||
contents of the PIDF-LO, the message body needs to be secure by a | ||||
means such as S/MIME. | ||||
6.1 UAC Behavior | ||||
A UAC might choose to send location in a SIP request to facilitate | ||||
location-based routing of the request, or for some other purpose. | ||||
Alice communicating her location to Bob in a SIP request is a simple | ||||
example of this. If Alice wanted to include her location as a | ||||
message body in an INVITE that also has an SDP message body, the | ||||
Content-Type: Multipart MUST be supported by both UAC and UAS. | ||||
Multipart comes in many forms (/mixed, /alternative, etc), and this | ||||
document does not limit which type of multipart is used, though | ||||
future documents might specify or limit multipart to a subset of | ||||
all the choices for a given use. | ||||
A UAC conveying location MUST include a locationValue in a | ||||
Geolocation header (see section 4.1) with either an LbyV indication | ||||
(a cid-URL), or a dereferencable location URI. Requests containing | ||||
an LbyV message body sent MUST also contain a Geolocation header | ||||
field. The UAC supporting this extension MUST include a Supported | ||||
header with the 'geolocation' option tag. | ||||
More than one location format (civic and coordinate) can be included | ||||
in the same message body part, but all location parts of the same | ||||
PIDF-LO MUST point at the same position on the earth, identifying | ||||
the same Target. The same location in multiple formats, for | ||||
example, a partial or complete geodetic and a partial or complete | ||||
civic, allows the recipient to select the most preferred format for | ||||
its use. Additional complementary location information can be in | ||||
the second format as well. | ||||
Multiple PIDF-LOs are allowed in the same request, with each allowed | ||||
to point at separate positions - however, each PIDF-LO MUST identify | ||||
a different Target (i.e., in the "entity=" attribute in the | ||||
<presence> element of the presence document). Therefore, there will | ||||
be no confusion by a Location Recipient receiving more than one | ||||
PIDF-LO (in a message body or when dereferenced, or a combination). | ||||
A SIP request SHOULD include only one location per Target in a | ||||
single SIP request. More than one will likely lead to confusion by | ||||
a Location Recipient because this extension does not provide | ||||
guidance on what a recipient is to do with more than one location | ||||
for the same Target (which could point to different positions), nor | ||||
does it give any preference regarding which location is more or less | ||||
reliable than another location in the same request. | ||||
The presence of the 'geolocation' option tag in a Supported header | ||||
field without a Geolocation header field in the same message informs | ||||
a SIP element receiving this request that the UAC understands this | ||||
extension, but it does not know or wish to convey its location at | ||||
this time. Certain scenarios exist (location-based retargeting) in | ||||
which location is required in a SIP request in order to retarget the | ||||
message properly. Indicating support with a geolocation option tag | ||||
affects how a UAS or SIP server processes such a request. For | ||||
example, it ought to understand that erroring the request because | ||||
there was no location in the request is likely not going to result | ||||
in the location appearing in the subsequent request. | ||||
The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require | ||||
header field, because often the UAC will not know the underlying | ||||
topology to know which proxy will do the retargeting, thus | ||||
increasing the likelihood of a request failure at the first hop | ||||
proxy that does not understand this extension, as is required by | ||||
inclusion of the option tag in this header field. | ||||
A UAC inserting a locationValue MUST include an "inserted-by=" | ||||
parameter to indicate its hostport. This is copied to the | ||||
"inserter=" parameter of the Geolocation-Error header field in a | ||||
response if a Location Recipient determines there is something wrong | ||||
with the locationValue in this request. Because more than one | ||||
locationValue can be inserted along the path of the request, this | ||||
indication is necessary to show which locationValue had the problem | ||||
in the response, and who the locationErrorValue is for. For | ||||
example: | ||||
Geolocation: <cid:alice123@atlanta.example.com>; | ||||
inserted-by="alice@atlanta.example.com" | ||||
If a UAC does not learn and store its location locally (a GPS chip) | ||||
or from the network (DHCP or LLDP-MED), the UAC MAY learn its | ||||
location URI (from DHCP for example). If the latter is the case, | ||||
the UAC can SUBSCRIBE to this location URI, using the 'presence' | ||||
event package, to get and store its own location. | ||||
The Location Server will likely challenge requests to dereference a | ||||
Target's location URI. The location URI SHOULD be treated as | ||||
equivalent to possession of the location information itself and thus | ||||
TLS SHOULD be used when transmitting any location URI hop-by-hop | ||||
along the path to the Location Recipient, for protection reasons. | ||||
This is not to be confused with a 'possession model', in which | ||||
possessing the location URI grants authorization to dereference the | ||||
URI. Any entity dereferencing the location URI MUST pass whatever | ||||
authentication and authorization rules are on the LS to acquire this | ||||
location. The Ruleholder from [RFC3693] is still very much in | ||||
control - for any entity possessing the location URI. | ||||
If the Location Generator wishes to control whether any location | ||||
included in the SIP request or added along the signaling path of | ||||
this request can be viewed for routing decisions, the Location | ||||
Generator adds a Geolocation header field value including the | ||||
"routing-allowed=no" parameter. This header field parameter | ||||
provides specific policy rules for each locationValue (if more than | ||||
one locationValue is inserted along the signaling path) within the | ||||
SIP request. A UAC SHOULD include the "routing-allowed" header | ||||
field parameter, with or without a locationValue, to each SIP | ||||
request supporting this specification to ensure the UAC's policy for | ||||
intermediaries which might add a locationValue of the Target | ||||
downstream. The default behavior for SIP servers is to consider | ||||
this value to be present, with a value of "=no". A "=no" value in | ||||
this parameter indicates there can be no routing decisions derived | ||||
from the UAC's location. UACs MUST be prepared to receive an error | ||||
indicating a SIP intermediary needs to have this parameter set | ||||
to"=yes" in order to properly routing this message. The UAC can | ||||
make a local policy choice as to whether it wishes to set the | ||||
parameter to "=yes", thus allowing each SIP entity along the message | ||||
path to use the UAC's location when making routing decisions. There | ||||
is no way to indicate that only a subset of SIP intermediaries have | ||||
permission, while other intermediaries do not. | ||||
There is no feedback mechanism to inform the Target if a SIP server | ||||
has included a locationValue downstream. If a UAC has already | ||||
conveyed location in the original request of a transaction, and | ||||
wants to update its location information (for whatever reason) after | ||||
the original request is sent, or after a dialog is created, this is | ||||
done by sending an UPDATE request [RFC3311]. The UPDATE will include | ||||
a geolocation option tag and Geolocation header field with the new | ||||
locationValue to the original destination UAS. | ||||
A presence document includes identity information (in the "entity=" | ||||
attribute of the <presence> element), although the identity could be | ||||
an unlinkable pseudonym [RFC3693]. Implementations of this | ||||
extension SHOULD consider the appropriateness of including an | ||||
unlinkable pseudonym as the identity in the location information | ||||
where a real identity is not required. See the concerns raised in | ||||
section 4.3.2 about unlinkable pseudonyms in relation to their | ||||
potential problems with requests that need to route based on the | ||||
location contained in the message. | ||||
A location URI MUST NOT contain any user identifying information. | ||||
For example, it is much more secure to use something unidentifiable | ||||
like | ||||
3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com | ||||
rather than something identifiable like | ||||
aliceishere@example.atlanta.com. | ||||
Use of self-signed certificates is inappropriate for use in | ||||
protecting a PIDF, as the sender does not have a secure identity of | ||||
the recipient. | ||||
Although this is discussed in more detail in later in section 6.2, | ||||
SIP entities MUST NOT bypass rules and behaviors conveyed in a | ||||
PIDF-LO. UACs SHOULD take care when setting their | ||||
<retransmission-allowed> flag to "yes". When Alice tells Bob her | ||||
location with this flag set to "yes", Bob is free to tell Carol | ||||
where Alice is (as long as the <retention-expiry> time has not | ||||
elapsed, indicating that the location information should have | ||||
already been deleted, according to RFC 4119). This is an implicit | ||||
byproduct of the PIDF-LO rule-set, as of this writing. This decision | ||||
is a configuration issue, but is worth mentioning here. | ||||
6.1.1 UAC Receiving a Location Failure Indication | ||||
Location Recipients that use the location information for | ||||
location-based routing decisions can be either destination UAs or | ||||
intermediate servers. If a request fails based on the location | ||||
information in the request, a 424 (Bad Location Information) | ||||
response is sent back to the UAC. The 424 MUST have a | ||||
Geolocation-Error header field containing one or more | ||||
locationErrorValues in the response message. A locationErrorValue | ||||
has a header field parameter indicating which entity inserted the | ||||
locationValue correlated to this error, called the "inserter=" | ||||
parameter. This "inserter=" parameter (in the locationErrorValue) | ||||
is copied from the "inserted-by=" parameter (from the locationValue) | ||||
by the Location Recipient (UA or proxy) sending the error response. | ||||
A UAC receiving a Geolocation-Error in any response type MUST check | ||||
whether the "inserter=" parameter in the locationErrorValue | ||||
indicates this UAC. | ||||
o If locationErrorValue does not match, the locationErrorValue | ||||
MUST be ignored. | ||||
o If a locationErrorValue is in a 424, and the "inserter=" entity | ||||
is not this UAC, the response SHOULD be treated as a 400 | ||||
response. | ||||
o If locationErrorValue does indicate this UAC, this UAC MUST | ||||
process the response, including the Geolocation-Error code | ||||
(defined in section 4.3), taking the action described in that | ||||
section for the received error code. | ||||
Additionally, the UAC MUST ignore a Geolocation-Error header field | ||||
value, even for this UAC, even in a 424 response if the UAC did not | ||||
include a Geolocation header field value (with locationValue) in the | ||||
request part of the transaction. | ||||
A UAC MAY reattempt a new request if it can correct the stated | ||||
failure in the Geolocation-Error header field, unless the location | ||||
error is a 5XX level error - Section 4.3 clearly states not to do | ||||
this. A UAC MUST follow all the guidance that pertains to UACs from | ||||
Section 4.3 (Geolocation-Error Header Field), heeding what to do | ||||
when it receives any of the error codes articulated in that section. | ||||
Any UAC that inserted location into a request MUST be prepared to | ||||
receive the Geolocation-Error header field in any response, looking | ||||
to determine if a locationErrorValue is meant for the UAC, and to | ||||
react accordingly. | ||||
If a UAC includes location in a request, and either the UAS does not | ||||
determine errored location was critical to the transaction and | ||||
accept the request, or the request failed for reason other than | ||||
location, any response MAY contain a Geolocation-Error header field | ||||
containing a locationErrorValue with the details of the location | ||||
error. | ||||
6.2 UAS Behavior | ||||
If the Geolocation header field is present in a received SIP | ||||
request, the type of URI contained in the locationValue will | ||||
indicate if location is in a message body (part) or requires an | ||||
additional dereference transaction. If the location URI is sip:, | ||||
sips: or pres:, and the UAS wants to learn the UAC's location, the | ||||
UAS MUST SUBSCRIBE to the provided URI to retrieve the PIDF-LO being | ||||
conveyed by the UAC as defined in [RFC3856]. If successful, the | ||||
Target's PIDF-LO will be returned in the NOTIFY request from the | ||||
remote host. The UAS is not REQUIRED to dereference the location | ||||
URI if location is not needed to process the request. It is | ||||
RECOMMENDED the UAS display the location to the user, or otherwise | ||||
render the location appropriately. | ||||
A Require header field with the 'geolocation' option tag indicates | ||||
the UAC requires that the UAS understand this extension, sending an | ||||
error response if it does not. A 420 (Bad Extension) with a | ||||
'geolocation' option tag in an Unsupported header field would be the | ||||
appropriate response in this case. | ||||
It is possible, but undesirable, for a message to arrive with a body | ||||
containing an LbyV, but with no Geolocation header field value | ||||
pointing to it (potentially no Geolocation header field at all). In | ||||
this case, the recipient MAY still read and use the message body. | ||||
Unless stated otherwise by future standards-track publication(s), a | ||||
location URI only has meaning within the Geolocation header field | ||||
and MUST NOT appear in any other SIP header field. | ||||
There are 3 Geolocation header field parameters, | ||||
o "inserted-by=" | ||||
o "used-for-routing" | ||||
o "routing-allowed" | ||||
The "inserted-by=" and "used-for-routing" parameters are contained | ||||
within a locationValue, whereas the "routing-allowed" parameter is | ||||
outside any locationValue, and is to appear at most once in the SIP | ||||
request. | ||||
The "inserted-by=" parameter informs a Location Recipient which SIP | ||||
entity added this locationValue to the SIP request. This parameter | ||||
is mandatory for each locationValue in the request. The value in | ||||
the "inserted-by=" parameter is copied into the "inserter=" | ||||
parameter in each locationErrorValue if there is an error in the | ||||
location to be reported back to the location sender. See section | ||||
6.2.1. | ||||
The "used-for-routing" parameter is included in the locationValue if | ||||
a SIP server used the location in the request to determine how to | ||||
route or forward the message towards the ultimate destination. If | ||||
there are more than one locationValues in the Geolocation header | ||||
field, it is possible that different locationValues were used to | ||||
route the message at different points along the path traversed by | ||||
the request. This is allowed, as it is consistent with the rule | ||||
that whenever a message is routed based upon a locationValue, a | ||||
"used-for-routing" parameter is added to the applicable | ||||
locationValue. This parameter MUST be present in each locationValue | ||||
used along the path. A "used-for-routing" parameter MUST NOT be | ||||
removed from a locationValue in a request. | ||||
The "routing-allowed" parameter is exclusively for SIP servers, and | ||||
will be discussed in section 6.3. | ||||
Additional locationValues inserted into a request MUST be placed | ||||
the order they were generated, and not rearranged. This informs a | ||||
Location Recipient which was the last locationValue in the message | ||||
that was used to route the message. This is for troubleshooting and | ||||
management reasons. | ||||
Individual header field parameters in any received locationValue | ||||
MUST NOT be modified or deleted in transit to the ultimate | ||||
destination. | ||||
A UAS MUST NOT send location in a response message, as there can be | ||||
any number of issues/problems with receiving location, and the UAC | ||||
or proxy server(s) cannot reply to a response with an error | ||||
response. If the UAS wants to send its location to a UAC, it can do | ||||
so in a new request within a separate transaction. This document | ||||
gives no recommendation about which SIP request to use, but SIP | ||||
MESSAGE is a viable choice. | ||||
A UAS MAY include a 'geolocation' option tag in the Supported header | ||||
field of a response, indicating it does understand this extension, | ||||
even if location was not included in a request to the UAS. | ||||
A UAS wishing to dereference a location URI contained in a received | ||||
request will use the 'presence' event package in a SUBSCRIBE request | ||||
to the URI. If accepted, the LS will return the PIDF-LO to the UAS | ||||
in one or more NOTIFY requests - depending on the duration of the | ||||
subscription. If there are any errors during dereferencing, | ||||
or in the PIDF-LO itself, the UAS will respond to the original | ||||
request with a locationErrorValue indicating what the UAS concluded | ||||
was wrong with the location. This is to include any dereferencing | ||||
problems encountered. | ||||
Dereferencing for sip:, sips: and pres: URI schemes are | ||||
mandatory-to-implement. | ||||
A UAS MUST be prepared to receive subsequent location updates from | ||||
upstream entities (regardless of how the UAS received location | ||||
previously from this UAC). The UAC will convey updated location | ||||
using the UPDATE [RFC3311] method to the UAS, and not a reINVITE. | ||||
The UAS MUST NOT reject updated location arriving in a reINVITE | ||||
though, as other dialog parameters might be changing also (in which | ||||
a reINVITE is appropriate). | ||||
If there is more than one location (any combination of PIDF-LOs or | ||||
location URIs), this document does not give guidance as to what a | ||||
Location Recipient does with each location. There are no priority | ||||
or 'more-trusted' indications specified by this document. All this | ||||
is considered application-specific, and out-of-scope for this | ||||
document. If more than one location is present in the PIDF-LO, | ||||
location elements in the same PIDF-LO MUST apply to the same Target | ||||
(identified in the "entity=" attribute) and MUST point at the same | ||||
position on the earth. If there is more than one PIDF-LO with | ||||
different Target identifiers, then the UAC is merely telling the UAS | ||||
where more than one Target is, and there SHOULD NOT be any conflict. | ||||
Within any PIDF-LO, there is a <retransmission-allowed> policy | ||||
element that can be set to "yes" or "no". These are the only | ||||
possibilities. If Alice conveys her location to Bob (as has been | ||||
described throughout this document) with a <retransmission-allowed> | ||||
element set to "no", then Bob MUST NOT inform any other element | ||||
where Alice is. If the <retransmission-allowed> element is set to | ||||
"yes", then Bob can inform other elements where Alice is, but only | ||||
as long as the <retention-expiry> policy element, also in the | ||||
PIDF-LO, allows [RFC4119]. As a byproduct of this, that means that | ||||
if Alice conveys her location to Bob with a <retransmission-allowed> | ||||
element set to "yes", and the <retention-expiry> time does not | ||||
require Bob to delete Alice's location yet, then Bob is free to tell | ||||
anyone else where Alice is. The "entity=" attribute in the | ||||
<presence> element identifies who is the Target of each location, | ||||
preventing confusion. Whenever Bob conveys Alice's location, | ||||
<retention-expiry> timer MUST be maintained as is (i.e., not changed | ||||
from when Bob received it). RFC 4119 implicitly allows this | ||||
behavior, and the behavior does not change when SIP is the Using | ||||
Protocol. | ||||
6.2.1 UAS Generating a Location Failure Indication | ||||
If a UAS receives location in a request, but determines there is a | ||||
problem with the location in the request, it is the responsibility | ||||
of the UAS to inform the entity that inserted the problematic | ||||
location into that request. The Geolocation header field in the | ||||
request has a locationValue, providing the UAS a location URI | ||||
indicating where the Target's location is. The Location Target | ||||
identified in the PIDF-LO may or may not be the location inserter, | ||||
or the generator of the request. Ultimately, location is in a | ||||
PIDF-LO. This is either in the request as a message body (LbyV), or | ||||
obtained by initiating a dereference transaction on a Location | ||||
Server identified in the location URI. Location Servers typically | ||||
challenge all dereference requests. All PIDF-LOs have a Location | ||||
Target identifier. The "inserted-by=" parameter of the | ||||
locationValue tells the UAS which SIP entity inserted that | ||||
locationValue. This "inserted-by=" parameter is copied into the | ||||
"inserter=" parameter of the locationErrorValue generated by the | ||||
Location Recipient (the UAS), in a response, when it wants to inform | ||||
the location "inserter=" entity there was a problem with the | ||||
location it received. | ||||
There can be more than one locationValue in a request. The | ||||
"inserter=" parameter in the locationErrorValue will prevent | ||||
entities that did not insert the errored location from | ||||
misunderstanding whether the locationErrorValue applies to them. | ||||
If there is one valid locationValue in a request, even if all the | ||||
others have errors associated with them, the Location Recipient MUST | ||||
NOT send a 424 (Bad Location Information) response. The Location | ||||
Recipient (the UAS) MUST send a locationErrorValue for each errored | ||||
locationValue, with unique "inserter=" parameters to make sure the | ||||
right entities know which locations were in error. | ||||
As hinted at, a location "inserter=" can be a UAC or it can be an | ||||
in-signaling-path SIP server acting as a UAC locator. This | ||||
means the SIP server is including its version of where it thinks the | ||||
UAC is, geographically. This "inserter=" has to be in the form of | ||||
an dereferencable location URI in a locationValue, because SIP | ||||
servers are not allowed to insert message bodies. | ||||
Each locationErrorValue has an error code, letting the location | ||||
"inserter=" entity know what was wrong with the location supplied by | ||||
that entity. See Section 4.3 for the 5 actionable responses a UAC | ||||
can take from a locationErrorValue. | ||||
If the location "inserted-by=" entity, meaning either the UAC or | ||||
proxy in the message path chose to indicate that location was | ||||
sufficiently important to include a 'geolocation' option tag in a | ||||
Require header field, any error response SHOULD be a 424 (Bad | ||||
Location Information) back to the "inserter=" entity (knowing the | ||||
response will ultimately go to the UAC regardless) if there needs to | ||||
be a good locationValue sent to properly process the request. Only | ||||
entities identified in a locationErrorValue as the "inserter=" | ||||
entity will pay attention to this locationErrorValue. All other | ||||
entities MUST ignore any locationErrorValue not directed towards | ||||
them. See section 4.3 for more information on this, including all | ||||
the location-specific errors and Geolocation-Error header field | ||||
parameters. | ||||
In the above scenario ('geolocation' option tag in a Require | ||||
header field), the only other response can be a 420, if the UAS | ||||
does not support this Geolocation extension to SIP. | ||||
If the "inserted-by=" location entity placed the 'geolocation' | ||||
option tag in a Supported header field, the response can be a 424 if | ||||
it chooses, but also can be any other SIP response, including a 200 | ||||
OK. A locationErrorValue in a Geolocation-Error header field that | ||||
is not in a 424 (Bad Location Information) response is considered | ||||
informational by the Location Recipient, and does not cause the | ||||
Location Recipient to reject the request solely because of bad | ||||
location information. | ||||
For example, Alice INVITEs Bob to a dialog, and includes geolocation | ||||
in the request. Bob can accept the INVITE with a 200 OK and still | ||||
add a locationErrorValue in the 200 OK indicating "yes, I accept | ||||
your request, and btw, something was wrong with the location you | ||||
provided in the INVITE". The specific problem with the location is | ||||
indicated by the Geolocation-Error code. The "inserter=" parameter | ||||
identifies the Location Inserter this locationErrorValue is intended | ||||
for. | ||||
Each locationErrorValue is destined for one "inserter=" entity. | ||||
This gives a Location Recipient a mechanism to tell each inserter | ||||
what the Location Recipient concluded was wrong with the location | ||||
the "inserter=" entity included. Therefore, | ||||
o there MUST be a locationErrorValue for each locationValue that | ||||
was considered bad by the UAS to ensure each upstream location | ||||
inserter understands which error code is intended for the | ||||
inserter (and which to ignore). | ||||
o there MUST NOT be more than one locationErrorValue in the | ||||
response per locationValue in the request. | ||||
o there MUST NOT be more than one locationErrorValue with the same | ||||
"inserter=" entity in the request. | ||||
o there MUST NOT be a locationErrorValue in the response for a | ||||
locationValue in the request that was not in error, according to | ||||
the Location Recipient. | ||||
Here is an example of a Geolocation-Error header field | ||||
Geolocation-Error: 201; code="Linkable Target Identity Required"; | ||||
node="server42.example.com"; | ||||
inserter="alice.example.com"; | ||||
The above example says that the Location Recipient is | ||||
server42.example.com, and this entity cannot verify the Target's | ||||
identity within this message. This is typically needed in order to | ||||
make routing decisions for the SIP request where the "entity=" | ||||
attribute has an unlinkable pseudonym obscuring a location Target's | ||||
identity from the signaling. This is not desire because if Alice's | ||||
message is to be routed based on the location in the SIP request, | ||||
server42 has to verify that this is Alice's location. The | ||||
appropriate action is to send a 424 (Bad Location Information) | ||||
response with the above (201) Geolocation-Error header value. We do | ||||
not want Alice's request routed based on Bob's location. | ||||
See Section 4.3 for further rules about the Geolocation-Error header | ||||
field and the locationErrorValue. | ||||
This document says nothing about what a Location Recipient does with | ||||
more than one 'good' locationValue in a request (i.e., which to | ||||
choose to use). This scenario MAY be addressed in a future effort. | ||||
Further, more than one error code is allowed in the | ||||
locationErrorValue - each having one "inserter=" parameter. | ||||
6.3 Proxy Behavior | ||||
[RFC3261] states message bodies cannot be added by proxies. | ||||
However, proxies are permitted to add a header field to a request. | ||||
This means that a proxy can add a Geolocation locationValue header | ||||
field with a dereferencable location URI, but not an LbyV message | ||||
body. | ||||
It is allowed, but NOT RECOMMENDED, for more than one SIP element to | ||||
insert location into a request along its path. As described earlier | ||||
in this document, each insertion of location into a SIP request is | ||||
accompanied by a new locationValue in a Geolocation header field. | ||||
Also described earlier, each locationValue MUST contain an | ||||
"inserted-by=" value indicating to a Location Recipient the host | ||||
that inserted a specific location into a particular request. | ||||
If, however, location is already in a SIP request, a SIP server | ||||
SHOULD NOT add another location URI that identifies the same Target | ||||
in the PIDF-LO (in the "entity=" attribute) to the same request. | ||||
This will likely cause confusion at the Location Recipient as to | ||||
which to use. | ||||
More than one Geolocation locationValue in a message is permitted, | ||||
but can cause confusion at the recipient. If a proxy chooses to add | ||||
a locationValue to a Geolocation header field, which would be a | ||||
local policy decision, the new locationValue MUST be added to the | ||||
end of the header field (after previous locationValue(s)). This is | ||||
done to create an order of insertion of locationValues along the | ||||
path. Proxies MUST NOT modify the order of locationValues in a | ||||
geolocation header field. Section 4 covers more details with | ||||
respect to the rules of usage for the Geolocation header value(s). | ||||
Each rule MUST be obeyed as written there. | ||||
A proxy wishing to dereference a location URI contained in a | ||||
received request will use the 'presence' event package in a | ||||
SUBSCRIBE request to the URI, but only if the "routing-allowed" | ||||
header parameter is set to "=yes". This transaction is described in | ||||
Section 4.5. If accepted, the LS will return the PIDF-LO to the | ||||
proxy in a NOTIFY request. If there are any errors during | ||||
dereferencing, or in the PIDF-LO itself, the proxy will send an | ||||
error to the UAC with a locationErrorValue indicating what the proxy | ||||
concluded was wrong with the location. This is to include any | ||||
dereferencing problems encountered. | ||||
6.3.1 Proxy Behavior with Geolocation Header Field Parameters | ||||
SIP servers MUST NOT delete any existing Geolocation locationValue | ||||
(URI or header field parameter) from a request. An existing | ||||
locationValue MAY be modified by adding a "used-for-routing" | ||||
parameter to an existing locationValue, if the request was | ||||
retargeted based on the location within that locationValue. | ||||
According to this specification, the default value of any | ||||
Geolocation header value "routing-allowed" is "no". If a Geolocation | ||||
header value is received by a SIP server with a "routing-allowed" | ||||
parameter set to "=no", the SIP server MUST NOT view or dereference | ||||
the location in the SIP request. If there is no "routing-allowed" | ||||
parameter in the SIP request (i.e., all instances of Geolocation | ||||
header field rows (as defined in section 7.3.1 of RFC 3261), the | ||||
previously stated default is to treat the Geolocation header value | ||||
as if it contained a "routing-allowed=no" parameter, without | ||||
exception. Therefore, this parameter does not have to be present to | ||||
deny SIP servers along the signaling path the ability to view the | ||||
Target's location. This parameter MAY be added in transit by a SIP | ||||
server, and MUST be with a value of "no". | ||||
For example, an existing Geolocation locationValue in a request of: | ||||
Geolocation: <cid:alice123@atlanta.example.com>; | ||||
inserted-by="alice123@atlanta.example.com" | ||||
can be modified by a proxy to add the "used-for-routing" parameter, | ||||
like this: | ||||
Geolocation: <cid:alice123@atlanta.example.com>; | ||||
inserted-by="alice123@atlanta.example.com", | ||||
used-for-routing | ||||
if this is the locationValue the proxy used to make a retargeting | ||||
decision based upon, but the proxy can make no other modification. | ||||
A SIP server MAY add a new Geolocation locationValue to a SIP | ||||
request. The server SHOULD NOT insert a locationValue of a Target | ||||
unless it is reasonably certain it knows the actual geographic | ||||
location of the Location Target (for example, if it thoroughly | ||||
understands the topology of the underlying access network and it can | ||||
identify the device location reliably, even in the presence of NAT | ||||
or VPN). Routing errors are likely if the SIP server inserts an | ||||
incorrect locationValue. | ||||
A locationValue added to an existing Geolocation header field | ||||
would look like: | ||||
Geolocation: <cid:alice123@atlanta.example.com>; | ||||
inserted-by="alice123@atlanta.example.com", | ||||
<sips:3sdefrhy2jj7@ls7.atlanta.example.com>; | ||||
inserted-by="ls7.atlanta.example.com" | ||||
Notice the locationValue added by proxy "ls7" is last among | ||||
locationValues. Proxies MUST add locationValue at the end of all | ||||
locationValues that are already present in the request. | ||||
If this request was then retargeted by an intermediary using the | ||||
locationValue inserted by server "ls7", the intermediary would add a | ||||
"used-for-routing" parameter like this: | ||||
Geolocation: <cid:alice123@atlanta.example.com>; | ||||
inserted-by="alice123@atlanta.example.com", | ||||
<sips:3sdefrhy2jj7@ls7.atlanta.example.com>; | ||||
inserted-by="ls7.atlanta.example.com", used-for-routing | ||||
It is conceivable that an initial routing decision is made on | ||||
one locationValue, and subsequently another routing decision is | ||||
made on a different locationValue further towards the ultimate | ||||
destination. This retargeting decision can be made on a newly | ||||
inserted locationValue. While unusual, it can occur. In such a | ||||
case, proxies MUST NOT remove any existing "used-for-routing" header | ||||
field parameter. In this instance, the SIP server retargeting based | ||||
on another locationValue MUST add the "used-for-routing" header | ||||
field parameter to the locationValue used for retargeting by this | ||||
server. This will result in a Geolocation header field indicating | ||||
that the request has been retargeted more than once, which is | ||||
allowed. | ||||
A Proxy that inserts or adds locationValue into a request MAY move a | ||||
'geolocation' option tag that is in a Supported header field into a | ||||
Require header field if this proxy deems geolocation to be | ||||
sufficiently important to Location Recipient(s) of this request. | ||||
A proxy can read any locationValue present, and the associated body, | ||||
if not S/MIME protected, and can use the contents of the header | ||||
field to make location-based retargeting decisions, if retargeting | ||||
requests based on location is a function of that proxy. Retargeting | ||||
is defined in [RFC3261]. However, if the Geolocation header field | ||||
parameter "routing-allowed" is present and set to "no", or is not | ||||
present (the default behavior is "no" if "routing-allowed" is not | ||||
present, whether or not a Geolocation header field is present), SIP | ||||
servers MUST NOT view the contents of the location message body. | ||||
Further, SIP servers MUST NOT attempt to dereference a location URI. | ||||
This is because the Location Inserter (likely the originating UAC) | ||||
did not give the SIP server permission to view the location within | ||||
the SIP request. How a SIP server indicates it requires permission | ||||
to view a request's location in order to properly process this | ||||
request is described in section 6.3.2. | ||||
If the Geolocation header field parameter "routing-allowed" is | ||||
present in a SIP request, the value MUST NOT be changed during | ||||
processing of the request. If the Geolocation header field | ||||
parameter "routing-allowed" is not present, SIP servers MUST treat | ||||
the location within the request as if the header field parameter | ||||
"routing-allowed" were present and set to "no". | ||||
B2BUAs and SBCs should also adhere to the above proxy guidance with | ||||
respect to the "Routing-allowed" header field parameter. In other | ||||
words, if the particular type of SIP server mentioned here supports | ||||
this SIP extension and is not the ultimate destination of this SIP | ||||
request, each policy rule within the Geolocation header field MUST | ||||
remain intact and unchanged. | ||||
SIP server MUST NOT delete a "routing-allowed" header field | ||||
parameter, but if one is not yet present, any SIP server MAY add a | ||||
"Routing-allowed" header field parameter with the value set to "no" | ||||
only. | ||||
6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues | ||||
For proxies that receive a SIP request that contains a location | ||||
error, all the rules applicable to a UAS apply (see Section 6.2.1.). | ||||
The one point to add is that a proxy does not need to examine | ||||
location contained in a request. Section 6.2.1. only applies to | ||||
proxies that need to monitor or police location within requests (for | ||||
whatever reason). | ||||
If a proxy inserted a locationValue into a request, it MUST be | ||||
ready to examine the response to that request, in case there is one | ||||
or more location errors in the response. To a great degree, this | ||||
scenario has the proxy behaving as a UAC (see section 6.1.1.) that | ||||
included a locationValue a request, which then receives an error to | ||||
that locationValue. | ||||
This location-inserting proxy SHOULD be (at least) transaction | ||||
stateful for the response. If the proxy is configured as a | ||||
stateless proxy, and it inserts location, it MUST process and | ||||
monitor all SIP responses, looking for locationErrorValues that | ||||
indicate it was the "inserter=" to learn that the location it | ||||
supplied was in error. It SHOULD react according to the error code | ||||
received. This document gives no guidance what the proxy should do | ||||
to rectify the bad location information, since the proxy is not the | ||||
SIP response destination, but a future document could address this. | ||||
The "routing-allowed" parameter's purpose is to indicate if SIP | ||||
servers along the signaling path should bother looking at the | ||||
location message body or dereferencing the location URI. There are | ||||
two values specified here for this parameter: "yes" and "no". If | ||||
the "routing-allowed" parameter is set to "yes", and the SIP server | ||||
determines this SIP request should be routed based on the Target's | ||||
location, this parameter gives the server permission to look at the | ||||
location (or dereference it). If this parameter is set to "no", | ||||
then the SIP server MUST NOT view the location message body or | ||||
dereference the location URI within this SIP request. If the SIP | ||||
server believes it cannot process this message properly because it | ||||
needs to learn the Target's location in order to route the message, | ||||
then it MUST return a 424 (Bad Location Information) response, | ||||
indicating it requires permission (error code 402) to view the | ||||
location. | ||||
Here is an example of a Geolocation-Error header field | --boundary1 | |||
Geolocation-Error: 402; code="Permission to Route based on | Content-Type: application/sdp | |||
Location Information"; | ||||
node="bob.example.com"; | ||||
inserter="alice.example.com"; | ||||
The above example says that the Location Recipient is | ...SDP goes here | |||
server42.example.com, and this entity believes it cannot route this | ||||
message without knowing permission to view the Target's location. | ||||
Regardless of whether there is a Geolocation header value parameter, | ||||
such as | ||||
routing-allowed=no | --boundary1 | |||
or this parameter is not present in the SIP request (as shown 402 | <?xml version="1.0" encoding="UTF-8"?> | |||
error example above). The default behavior is to act as if the | <presence xmlns="urn:ietf:params:xml:ns:pidf" | |||
parameter is present and set to "=no". Server42 MUST get permission | xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" | |||
to view the Target's location by reading a routing-allowed header | xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" | |||
parameter saying "=yes", otherwise a 402 error is sent back to the | xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" | |||
"inserter=" entity to get permission. | xmlns:gml="http://www.opengis.net/gml" | |||
entity="pres:alice@atlanta.example.com"> | ||||
<tuple id="target123"> | ||||
<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> | ||||
<gp:retransmission-allowed>no</gp:retransmission-allowed> | ||||
<gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- | ||||
expiry> | ||||
</gp:usage-rules> | ||||
<gp:method>802.11</gp:method> | ||||
</gp:geopriv> | ||||
<dm:deviceID>mac:1234567890ab</dm:deviceID> | ||||
<dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp> | ||||
</dm:device> | ||||
<dm:person id="target123"> | ||||
<gp:geopriv> | ||||
<gp:location-info> | ||||
<cl:civilAddress> | ||||
<cl:country>US</cl:country> | ||||
<cl:A1>Texas</cl:A1> | ||||
<cl:A3>Colleyville</cl:A3> | ||||
<cl:HNO>3913</cl:HNO> | ||||
<cl:A6>Treemont</cl:A6> | ||||
<cl:STS>Circle</cl:STS> | ||||
<cl:PC>76034</cl:PC> | ||||
<cl:NAM>Haley's Place</cl:NAM> | ||||
<cl:FLR>1</cl:FLR> | ||||
<cl:civilAddress> | ||||
</gp:location-info> | ||||
<gp:usage-rules> | ||||
<gp:retransmission-allowed>no</gp:retransmission-allowed> | ||||
<gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- | ||||
expiry> | ||||
<gp:method>triangulation</gp:method> | ||||
</gp:usage-rules> | ||||
</geopriv> | ||||
<dm:timestamp>2010-07-28T12:28:04Z</dm:timestamp> | ||||
</dm:person> | ||||
</tuple> | ||||
</presence> | ||||
Section 4.3 highlights this example, stating the user, Alice, MUST | --boundary1-- | |||
be made aware of this location revelation request. This document | ||||
does not give any guidance how Alice is to be informed (i.e., audio, | ||||
visual, etc). Alice can grant permission or choose not to, knowing | ||||
this SIP request attempt (to this destination, at this time) will | ||||
fail. The problem might not recur if a future SIP request were to | ||||
travel through a different server than server42 (or it might again). | ||||
7. Geopriv Privacy Considerations | 6. Geopriv Privacy Considerations | |||
Location information is considered by most to be highly | Location information is considered by most to be highly | |||
sensitive information, requiring protection from eavesdropping, | sensitive information, requiring protection from eavesdropping, | |||
and altering in transit. [RFC3693] articulates rules to | and altering in transit. [RFC3693] articulates rules to | |||
be followed by any protocol wishing to be considered a "Using | be followed by any protocol wishing to be considered a "Using | |||
Protocol", specifying how a transport protocol meets those rules. | Protocol", specifying how a transport protocol meets those rules. | |||
This section describes how SIP as a Using Protocol meets those | This section describes how SIP as a Using Protocol meets those | |||
requirements. | requirements. | |||
Quoting requirement #4 of [RFC3693]: | Quoting requirement #4 of [RFC3693]: | |||
skipping to change at page 43, line 37 | skipping to change at page 17, line 25 | |||
"(Single Message Transfer) In particular, for tracking of | "(Single Message Transfer) In particular, for tracking of | |||
small Target devices, the design should allow a single | small Target devices, the design should allow a single | |||
message/packet transmission of location as a complete | message/packet transmission of location as a complete | |||
transaction." | transaction." | |||
When used for tracking, a simple NOTIFY or UPDATE normally is | When used for tracking, a simple NOTIFY or UPDATE normally is | |||
relatively small, although the PIDF itself can be large. Normal | relatively small, although the PIDF itself can be large. Normal | |||
RFC 3261 procedures of reverting to TCP when the MTU size is | RFC 3261 procedures of reverting to TCP when the MTU size is | |||
exceeded would be invoked. | exceeded would be invoked. | |||
8. Security Considerations | 7. Security Considerations | |||
Conveyance of physical location of a UA raises privacy concerns, | Conveyance of physical location of a UA raises privacy concerns, | |||
and depending on use, there probably will be authentication and | and depending on use, there probably will be authentication and | |||
integrity concerns. This document calls for conveyance to | integrity concerns. This document calls for conveyance to | |||
be accomplished through secure mechanisms, like S/MIME protecting | be accomplished through secure mechanisms, like S/MIME encrypting | |||
message bodies (although this is not widely deployed) or TLS | message bodies (although this is not widely deployed), TLS | |||
protecting the overall signaling. In cases where a session set-up | protecting the overall signaling or conveyance location by-reference | |||
is retargeted based on the location of the UA initiating the call | and requiring all entities that dereference location to authenticate | |||
or SIP MESSAGE, securing the LbyV location with an end-to-end | themselves. In location-based routing cases, encrypting the | |||
mechanism such as S/MIME is problematic, because one or more proxies | location payload with an end-to-end mechanism such as S/MIME is | |||
on the path need the ability to read the location information to | problematic, because one or more proxies on the path need the | |||
retarget the message to the appropriate new destination UAS. | ability to read the location information to retarget the message to | |||
the appropriate new destination UAS. Data can only be encrypted to a | ||||
particular, anticipated target, and thus if multiple recipients need | ||||
to inspect a piece of data, and those recipients cannot be predicted | ||||
by the sender of data, encryption is not a very feasible choice. | ||||
Securing the location hop-by-hop, using TLS, protects the message | Securing the location hop-by-hop, using TLS, protects the message | |||
from eavesdropping and modification, but exposes the information to | from eavesdropping and modification in transit, but exposes the | |||
all proxies on the path as well as the endpoint. In most cases, the | information to all proxies on the path as well as the endpoint. In | |||
UA does not know the identity of the proxy or proxies providing | most cases, the UA has no trust relationship with the proxy or | |||
location-based routing services, so that end-to-middle solutions | proxies providing location-based routing services, so such | |||
might not be appropriate either. | end-to-middle solutions might not be appropriate either. | |||
These same issues exist for basic SIP signaling, but SIP normally | When location information is conveyed by reference, however, one can | |||
does not carry information to physically track a user. This | properly authenticate and authorize each entity that wishes to | |||
extension is especially sensitive. That said, there is the ability, | inspect location information. This does not require that the sender | |||
according to [RFC3693] to have an anonymous identity for the | of data anticipate who will receive data, and it does permit | |||
Target's location. This is accomplished by use of an unlinkable | multiple entities to receive it securely, but it does not however | |||
pseudonym in the "entity=" attribute of the <presence> element | obviate the need for pre-association between the sender of data and | |||
[RFC4479]. Though, this can be problematic for routing messages | any prospective recipients. Obviously, in some contexts this | |||
based on location (covered several times in the document above). | pre-association cannot be presumed; when it is not, effectively | |||
unauthenticated access to location information must be permitted. In | ||||
this case, choosing pseudo-random URIs for location by-reference, | ||||
coupled with path encryption like SIPS, can help to ensure that only | ||||
entities on the SIP signaling path learn the URI, and thus restores | ||||
rough parity with sending location by-value. | ||||
Location information is especially sensitive when the identity of | ||||
its Target is obvious. Note that there is the ability, according to | ||||
[RFC3693] to have an anonymous identity for the Target's location. | ||||
This is accomplished by use of an unlinkable pseudonym in the | ||||
"entity=" attribute of the <presence> element [RFC4479]. Though, | ||||
this can be problematic for routing messages based on location | ||||
(covered in the document above). Moreover, anyone fishing for | ||||
information would correlate the identity at the SIP layer with that | ||||
of the location information referenced by SIP signaling. | ||||
When a UA inserts location, the UA sets the policy on whether to | When a UA inserts location, the UA sets the policy on whether to | |||
reveal its location along the signaling path - as discussed in | reveal its location along the signaling path - as discussed in | |||
Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC | Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC | |||
implementations MUST make such capabilities conditional on explicit | implementations MUST make such capabilities conditional on explicit | |||
user permission, and SHOULD alert the user that location is being | user permission, and MUST alert the user that location is being | |||
conveyed. Proxies inserting location for location-based routing are | conveyed. | |||
unable to alert users, and such use is NOT RECOMMENDED. Proxies | ||||
conveying location using this extension MUST have the permission of | ||||
the Target to do so. | ||||
This SIP extension offers the default ability to require permission | This SIP extension offers the default ability to require permission | |||
to view location while the SIP request is in transit. The default | to view location while the SIP request is in transit. The default | |||
for this is set to "no", and there is an error explicitly describing | for this is set to "no". There is an error explicitly describing | |||
how an intermediary asks for permission to view the Target's | how an intermediary asks for permission to view the Target's | |||
location. | location, plus a rule stating the user has to be made aware of this | |||
permission request. | ||||
Because Target locations can be placed on a Location Server | ||||
accessible with the possession of a location URI, this URI has its | ||||
own security considerations. It is tempting to assume that the | ||||
dereference of this URI would have authentication, authorization and | ||||
other security mechanisms that limit the access to information. | ||||
Unfortunately, this might not be true. The access network the UA is | ||||
connected to can be the source of location reference, and it might | ||||
not have any credentialing mechanism suitable for controlling access | ||||
to a Target's location. Consider, specifically, a nomadic user | ||||
connected to an access network in a hotel. The UA has no way to | ||||
provide a credential acceptable of the hotel Location Server (LS) to | ||||
any of its intended Location Recipients. The recipient of a | ||||
reference does not know if a reference has appropriate authorization | ||||
policies or not. | ||||
Accordingly, possession of the reference should be considered | ||||
equivalent to possession of the value, and the reference should be | ||||
treated with the same degree of care as the value. Specifically, | ||||
TLS MUST be used to protect the security of the reference. Notice | ||||
that this specification does not constrain the dereference protocol | ||||
to use TLS. That specification is left entirely to the dereferencing | ||||
protocol documents. | ||||
There is no end-to-end integrity on any locationValue or | There is no end-to-end integrity on any locationValue or | |||
locationErrorValue header field parameter (or middle-to-end if the | locationErrorValue header field parameter (or middle-to-end if the | |||
value was inserted by a intermediary), so recipients of either | value was inserted by a intermediary), so recipients of either | |||
header field need to implicitly trust the header field contents, and | header field need to implicitly trust the header field contents, and | |||
take whatever precautions each entity deems appropriate given this | take whatever precautions each entity deems appropriate given this | |||
situation. Any idea of using SIP Identity is lost as soon as it is | situation. | |||
realized that the Geolocation header value can be added to by | ||||
intermediaries in the signaling path. | ||||
9. IANA Considerations | 8. IANA Considerations | |||
The following are the IANA considerations made by this SIP | The following are the IANA considerations made by this SIP | |||
extension. Modifications and additions to these registrations | extension. Modifications and additions to these registrations | |||
require a standards track RFC (Standards Action). | require a standards track RFC (Standards Action). | |||
[Editor's Note: RFC-Editor - within the IANA section, please | [Editor's Note: RFC-Editor - within the IANA section, please | |||
replace "this doc" with the assigned RFC number, | replace "this doc" with the assigned RFC number, | |||
if this document reaches publication.] | if this document reaches publication.] | |||
9.1 IANA Registration for the SIP Geolocation Header Field | 8.1 IANA Registration for the SIP Geolocation Header Field | |||
The SIP Geolocation Header Field is created by this document, with | The SIP Geolocation Header Field is created by this document, with | |||
its definition and rules in Section 4.1 of this document, and should | its definition and rules in Section 4.1 of this document, and should | |||
be added to the IANA sip-parameters registry, in the portion titled | be added to the IANA sip-parameters registry, in the portion titled | |||
"Header Field Parameters and Parameter Values". | "Header Field Parameters and Parameter Values". | |||
Predefined | Predefined | |||
Header Field Parameter Name Values Reference | Header Field Parameter Name Values Reference | |||
---------------- ------------------- ---------- --------- | ---------------- ------------------- ---------- --------- | |||
Geolocation inserted-by= no [this doc] | ||||
Geolocation used-for-routing yes [this doc] | ||||
Geolocation routing-allowed yes [this doc] | Geolocation routing-allowed yes [this doc] | |||
9.2 IANA Registration for New SIP Option Tag | 8.2 IANA Registration for New SIP 'geolocation' Option Tag | |||
The SIP option tag "geolocation" is created by this document, with | The SIP option tag "geolocation" is created by this document, with | |||
the definition and rule in Section 4.4 of this document, to be added | the definition and rule in Section 4.4 of this document, to be added | |||
to the IANA sip-parameters registry. | to the IANA sip-parameters registry. | |||
9.3 IANA Registration for Response Code 424 | 8.3 IANA Registration for 424 Response Code | |||
Reference: RFC-XXXX (i.e., this document) | Reference: RFC-XXXX (i.e., this document) | |||
Response code: 424 (recommended number to assign) | Response code: 424 (recommended number to assign) | |||
Default reason phrase: Bad Location Information | Default reason phrase: Bad Location Information | |||
This SIP Response code is defined in section 4.2 of this document. | This SIP Response code is defined in section 4.2 of this document. | |||
9.4 IANA Registration of New Geolocation-Error Header Field | 8.4 IANA Registration of New Geolocation-Error Header Field | |||
The SIP Geolocation-error header field is created by this document, | The SIP Geolocation-error header field is created by this document, | |||
with its definition and rules in Section 4.3 of this document, to be | with its definition and rules in Section 4.3 of this document, to be | |||
added to the IANA sip-parameters registry, in the portion titled | added to the IANA sip-parameters registry, in the portion titled | |||
"Header Field Parameters and Parameter Values". | "Header Field Parameters and Parameter Values". | |||
Predefined | Predefined | |||
Header Field Parameter Name Values Reference | Header Field Parameter Name Values Reference | |||
----------------- ------------------- ---------- --------- | ----------------- ------------------- ---------- --------- | |||
Geolocation-Error inserter= no [this doc] | ||||
Geolocation-Error node= no [this doc] | ||||
Geolocation-Error code= yes* [this doc] | Geolocation-Error code= yes* [this doc] | |||
* see section 9.5 for the newly created values. | * see section 9.5 for the newly created values. | |||
9.5 IANA Registration for the SIP Geolocation-Error Codes | 8.5 IANA Registration for the SIP Geolocation-Error Codes | |||
New location specific Geolocation-Error codes are created by this | New location specific Geolocation-Error codes are created by this | |||
document, and registered in a new table in the IANA sip-parameters | document, and registered in a new table in the IANA sip-parameters | |||
registry. Details of these error codes are in Section 4.3 of this | registry. Details of these error codes are in Section 4.3 of this | |||
document. | document. | |||
Geolocation-Error codes | Geolocation-Error codes | |||
----------------------- | ----------------------- | |||
Geolocation-Error codes provide reason for the error discovered by | Geolocation-Error codes provide reason for the error discovered by | |||
Location Recipients, categorized by action to be taken by error | Location Recipients, categorized by action to be taken by error | |||
recipient to be placed into SIP responses to inform the location | recipient. | |||
inserter of the error. | ||||
Code Description Reference | Code Description Reference | |||
---- --------------------------------------------------- --------- | ---- --------------------------------------------------- --------- | |||
100 "Cannot Process Location" General location error, [this doc] | 100 "Cannot Process Location" [this doc] | |||
meaning location in the request cannot be | ||||
processed at this time. No actionable guidance. | ||||
Can be treated as a 200 or 300 error by error | ||||
recipient. | ||||
200 "Retry Location Later with same data" The location [this doc] | ||||
cannot be processed at this time. Error recipient | ||||
should try again with same data. | ||||
201 "Linkable Target Identity Required" [this doc] | ||||
Target's identity cannot be unlinkable within | ||||
the presence element's "entity=" attribute. This | ||||
is necessary for routing SIP requests based | ||||
on Target's location (and some other entity's). | ||||
300 "Retry Location Later with device updated location" [this doc] | 200 "Retry Location Later with device updated location" [this doc] | |||
Location cannot be processed at this time. Error | ||||
recipient should try again with same data. | ||||
400 "Permission To Use Location Information " [this doc] | 300 "Permission To Use Location Information" [this doc] | |||
Permission is being requested from the calling | ||||
user to reveal and or use location in request | ||||
before request can be processed. This error | ||||
informs the "inserter=" entity that permission | ||||
is required to process this SIP request. Ruleholder | ||||
MUST be informed of permission request. | ||||
401 "Permission To Retransmit Location Information to a Third Party" | 301 "Permission To Retransmit Location Information to a Third Party" | |||
Permission from the calling user to send location [this doc] | [this doc] | |||
information to a third party entity - not in the | ||||
signaling path. This flag is in the PIDF-LO. The | ||||
user MUST be informed of permission request. | ||||
402 "Permission to Route based on Location Information" [this doc] | 302 "Permission to Route based on Location Information" [this doc] | |||
Permission from calling user to reveal location | ||||
in request before request can be processed. This | ||||
is a routing by location error. The user MUST be | ||||
informed of permission request. | ||||
500 "Location Information Denial" Request has been [this doc] | 400 "Location Information Denial" [this doc] | |||
Explicitly denied because of the location in | ||||
the request. Sender should not try again. | ||||
9.6 IANA Registration of Location URI Schemes | 8.6 IANA Registration of Location URI Schemes | |||
This document directs IANA to create a new set of parameters in a | This document directs IANA to create a new set of parameters in a | |||
separate location from SIP and Geopriv, called the "Location | separate location from SIP and Geopriv, called the "Location | |||
Reference URI" registry, containing the URI scheme, the | Reference URI" registry, containing the URI scheme, the | |||
Content-Type, and the reference, as follows: | Content-Type, and the reference, as follows: | |||
URI Scheme Content-Type Reference | URI Scheme Content-Type Reference | |||
---------- ------------ --------- | ---------- ------------ --------- | |||
SIP: [this doc] | SIP: [this doc] | |||
SIPS: [this doc] | SIPS: [this doc] | |||
PRES: [this doc] | PRES: [this doc] | |||
Additions to this registry must be defined in a permanent and | Additions to this registry must be defined in a permanent and | |||
readily available specification (this is the "Specification | readily available specification (this is the "Specification | |||
Required" IANA policy defined in [RFC5226]).. | Required" IANA policy defined in [RFC5226]). | |||
10. Acknowledgements | 9. Acknowledgements | |||
To Dave Oran for helping to shape this idea. | To Dave Oran for helping to shape this idea. | |||
To Jon Peterson and Dean Willis on guidance of the effort. | To Dean Willis for guidance of the effort. | |||
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning | To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning | |||
Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois | Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois | |||
Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, | Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, | |||
Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard | Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard | |||
Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for | Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for | |||
constructive feedback and nits checking. | constructive feedback and nits checking. | |||
Special thanks to Paul Kyzivat for his help with the ABNF in this | Special thanks to Paul Kyzivat for his help with the ABNF in this | |||
document and to Robert Sparks for many helpful comments and the | document and to Robert Sparks for many helpful comments and the | |||
proper construction of the Geolocation-Error header field. | proper construction of the Geolocation-Error header field. | |||
And finally, to Spencer Dawkins for giving this doc a good scrubbing | And finally, to Spencer Dawkins for giving this doc a good scrubbing | |||
to make it more readable. | to make it more readable. | |||
11. References | 10. References | |||
11.1 References - Normative | 10.1 Normative References | |||
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. | [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. | |||
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: | Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: | |||
Session Initiation Protocol", RFC 3261, May 2002. | Session Initiation Protocol", RFC 3261, May 2002. | |||
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object | [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object | |||
Format", RFC 4119, December 2005 | Format", RFC 4119, December 2005 | |||
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate | [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, March 1997 | Requirement Levels", RFC 2119, March 1997 | |||
[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource | [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource | |||
Locators", RFC 2392, August 1998 | Locators", RFC 2392, August 1998 | |||
[RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. | ||||
Peterson, "Presence Information Data Format (PIDF)", RFC | ||||
3863, August 2004 | ||||
[RFC3856] J. Rosenberg, " A Presence Event Package for the Session | [RFC3856] J. Rosenberg, " A Presence Event Package for the Session | |||
Initiation Protocol (SIP)", RFC 3856, August 2004 | Initiation Protocol (SIP)", RFC 3856, August 2004 | |||
[RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, | [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, | |||
August 2004 | August 2004 | |||
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, | [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, | |||
D. Gurle, "Session Initiation Protocol (SIP) Extension for | D. Gurle, "Session Initiation Protocol (SIP) Extension for | |||
Instant Messaging" , RFC 3428, December 2002 | Instant Messaging" , RFC 3428, December 2002 | |||
skipping to change at page 44, line 265 | skipping to change at page 22, line 5 | |||
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer | [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer | |||
Method", RFC 3515, April 2003 | Method", RFC 3515, April 2003 | |||
[RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension | [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension | |||
for Event State Publication", RFC 3903, October 2004. | for Event State Publication", RFC 3903, October 2004. | |||
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
[IANA-civic] http://www.iana.org/assignments/civic-address-types- | ||||
Registry | ||||
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | |||
Considerations Section in RFCs", RFC 5226, May 2008 | Considerations Section in RFCs", RFC 5226, May 2008 | |||
[RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July | [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July | |||
2006 | 2006 | |||
11.2 References - Informative | [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with | |||
Session Description Protocol", RFC 3264, June 2002 | ||||
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, | ||||
"Geopriv Requirements", RFC 3693, February 2004 | ||||
[RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC | [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC | |||
4483, May 2006 | 4483, May 2006 | |||
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host | [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO | |||
Configuration Protocol Option for Coordinate-based Location | Usage Clarification, Considerations, and Recommendations ", | |||
Configuration Information", RFC 3825, July 2004 | RFC 5491, March 2009 | |||
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol | 10.2 Informative References | |||
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration | ||||
Information ", RFC 4776, October 2006 | ||||
[ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP", | [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, | |||
draft-ietf-ecrit-phonebcp, "work in progress", Jan 2010 | "Geopriv Requirements", RFC 3693, February 2004 | |||
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location | [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location | |||
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work | Notifications in SIP", draft-ietf-geopriv-loc-filters, "work | |||
in progress", December 2009 | in progress", March 2010 | |||
Author Information | Authors' Addresses | |||
James Polk | James Polk | |||
Cisco Systems | Cisco Systems | |||
3913 Treemont Circle | 3913 Treemont Circle | |||
Colleyville, Texas 76034 | Colleyville, Texas 76034 | |||
33.00111N | 33.00111N | |||
96.68142W | 96.68142W | |||
Phone: +1-817-271-3552 | Phone: +1-817-271-3552 | |||
Email: jmpolk@cisco.com | Email: jmpolk@cisco.com | |||
Brian Rosen | Brian Rosen | |||
NeuStar, Inc. | NeuStar, Inc. | |||
470 Conrad Dr. | 470 Conrad Dr. | |||
Mars, PA 16046 | Mars, PA 16046 | |||
skipping to change at page 44, line 319 | skipping to change at page 23, line 4 | |||
Brian Rosen | Brian Rosen | |||
NeuStar, Inc. | NeuStar, Inc. | |||
470 Conrad Dr. | 470 Conrad Dr. | |||
Mars, PA 16046 | Mars, PA 16046 | |||
40.70497N | 40.70497N | |||
80.01252W | 80.01252W | |||
Phone: +1 724 382 1051 | Phone: +1 724 382 1051 | |||
Email: br@brianrosen.net | Email: br@brianrosen.net | |||
Jon Peterson | ||||
NeuStar, Inc. | ||||
Appendix A. Requirements for SIP Location Conveyance | Email: jon.peterson@neustar.biz | |||
Appendix A. Requirements for SIP Location Conveyance | ||||
The following subsections address the requirements placed on the | The following subsections address the requirements placed on the | |||
UAC, the UAS, as well as SIP proxies when conveying location. If a | UAC, the UAS, as well as SIP proxies when conveying location. If a | |||
requirement is not obvious in intent, a motivational statement is | requirement is not obvious in intent, a motivational statement is | |||
included below it. | included below it. | |||
A.1 Requirements for a UAC Conveying Location | A.1 Requirements for a UAC Conveying Location | |||
UAC-1 The SIP INVITE Method [RFC3261] must support location | UAC-1 The SIP INVITE Method [RFC3261] must support location | |||
conveyance. | conveyance. | |||
End of changes. 144 change blocks. | ||||
1957 lines changed or deleted | 562 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |