draft-ietf-sipcore-location-conveyance-00.txt   draft-ietf-sipcore-location-conveyance-01.txt 
SIP Working Group James Polk SIPCORE Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: December 18, 2009 Brian Rosen Expires: January 13, 2009 Brian Rosen
Intended Status: Standards Track (PS) NeuStar Intended Status: Standards Track (PS) NeuStar
June 18, 2009 July 13, 2009
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-00.txt draft-ietf-sipcore-location-conveyance-01.txt
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. This document may contain the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or made material from IETF Documents or IETF Contributions published or made
publicly available before November 10, 2008. The person(s) publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an material outside the IETF Standards Process. Without obtaining an
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 18, 2009. This Internet-Draft will expire on January 13, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
skipping to change at page 2, line 21 skipping to change at page 2, line 21
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
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 servers
make routing decisions based on the location of the user agent make routing decisions based on the location of the user agent
clients. client.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7
4.2 424 (Bad Location Information) Response Code . . . . . . 10 4.2 424 (Bad Location Information) Response Code . . . . . . 10
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 19 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 20
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 20
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 21 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 22
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 21 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 22
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 24
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 24
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 25
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 27 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 32 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 34
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 36 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
9.1 IANA Registration for New SIP Geolocation Header . . . . 38 9.1 IANA Registration for New SIP Geolocation Header . . . . 41
9.2 IANA Registration for New SIP 'geolocation' Option Tag . 39 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 41
9.3 IANA Registration for New 424 Response Code . . . . . . . 39 9.3 IANA Registration for New 424 Response Code . . . . . . . 41
9.4 IANA Registration for New SIP Geolocation-Error Header . 39 9.4 IANA Registration for New SIP Geolocation-Error Header . 41
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 39 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 42
9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 40 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 43
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1 Normative References . . . . . . . . . . . . . . . . . 41 11.1 Normative References . . . . . . . . . . . . . . . . . 43
11.2 Informative References . . . . . . . . . . . . . . . . . 42 11.2 Informative References . . . . . . . . . . . . . . . . . 45
Author Information . . . . . . . . . . . . . . . . . . . . . 42 Author Information . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Requirements for SIP Location Conveyance . . . . 43 Appendix A. Requirements for SIP Location Conveyance . . . . 45
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].
The following terms and acronyms used throughout this document are The following terms and acronyms used throughout this document are
defined here: defined here:
LbyR = Location-by-Reference LbyR = Location-by-Reference
LbyV = Location-by-Value LbyV = Location-by-Value
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location gathers the location of the Target and creates Location
Objects describing the location of the Target [RFC3693]. Objects describing the location of the Target [RFC3693].
Location Information Server (LIS) - a logical server that stores Location Inserter: a role created in this document describing the
geolocation records of Targets, which correspond to LbyR URIs. 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 Location Object (LO): An object conveying location information
(and possibly privacy rules) to which Geopriv security (and possibly privacy rules) to which Geopriv security
mechanisms and privacy rules are to be applied [RFC3693]. mechanisms and privacy rules are to be applied [RFC3693].
Location Recipient (LR): The entity that receives location Location Recipient (LR): The entity that receives location
information. It may have asked for this location explicitly information. It may have asked for this location explicitly
(by sending a query to a location server), or it may receive (by sending a query to a location server), or it may receive
this location asynchronously [RFC3693]. this location asynchronously [RFC3693].
Location Server (LS): The entity to which a LG publishes location Location Server (LS): The entity to which a LG publishes location
objects, the recipient of queries from location receivers, and objects, the recipient of queries from location receivers, and
the entity that applies rules designed by the rule maker the entity that applies rules designed by the rule maker
[RFC3693]. [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 Target: A person or other entity whose location is communicated by
a Geopriv Location Object [RFC3693]. a Geopriv Location Object [RFC3693].
Using Protocol: A protocol that carries a Location Object [RFC3693]. Using Protocol: A protocol that carries a Location Object [RFC3693].
2. Introduction 2. Introduction
This document describes how Location can be "conveyed" from one SIP This document describes how geolocation can be "conveyed" in a SIP
entity unsolicited to another entity using SIP [RFC3261]. Here, request from one SIP entity unsolicited to another entity using SIP
"Location" is a description of the physical geographical area where [RFC3261]. Here, "Location" is a description of the physical
something currently exists. The phrase "location conveyance" geographical area where something currently exists. Note that this
describes scenarios in which a SIP user agent client (UAC) is information is not solicited by the entity that receives it. The
informing a user agent server (UAS) or intermediate SIP server mechanism in this document does not allow one SIP user to request
without being previously asked where the UAC is. the location of another SIP user to be returned in a response.
Location Conveyance is different from a UAC, Alice, seeking the
location the UAS, Bob. Location conveyance, using SIP, never asks
for another entity's location be in a response. Asking for someone
else's location is not discussed in this document.
Geographic location in the IETF is discussed in RFC 3693 (Geopriv Geographic location in the IETF is discussed in RFC 3693 (Geopriv
Requirements) [RFC3693]. It defines a "Target" as the entity whose Requirements) [RFC3693]. It defines a "Target" as the entity whose
location is being transmitted over IP. A [RFC3693] defined "Using location is being transmitted over IP. A [RFC3693]-defined "Using
Protocol" describes how a "Location Server" transmits a "Location Protocol" describes how a "Location Server" transmits a "Location
Object" to a "Location Recipient" while maintaining the contained Object" to a "Location Recipient" while maintaining the contained
privacy intentions of the Target intact. This document describes the privacy intentions of the Target intact. This document describes a
extension to SIP for how it complies with the Using Protocol SIP extension to carry a Location Object and how it complies with
requirements, where the location server is a UA or Proxy Server and the Using Protocol requirements in RFC 3693.
the Location Recipient is another UA or Proxy Server.
Common terms are in Section 1. Section 3 provides an overview of SIP Common terms are in Section 1. Section 3 provides an overview of SIP
location conveyance. Section 4 details the modifications necessary location conveyance. Section 4 details the extensions to SIP
to accomplish location conveyance. Section 5 gives decode examples necessary to accomplish location conveyance. Section 5 gives decode
of geolocation within SIP requests, both LbyV and LbyR. Section 6 examples of geolocation within SIP requests, both LbyV and LbyR.
articulates the SIP element type behaviors for location conveyance. Section 6 articulates the SIP element type behaviors for location
Section 7 discusses Geopriv privacy considerations. Section 8 conveyance. Section 7 discusses Geopriv privacy considerations.
discusses security considerations. Section 9 IANA registers the Section 8 discusses security considerations. Section 9 IANA
modifications made to SIP by this document from section 4. registers the modifications made to SIP by this document in section
4.
3. Overview of SIP Location Conveyance 3. Overview of SIP Location Conveyance
The concept of conveying location in SIP is fairly straightforward. The concept of conveying location in SIP is fairly straightforward.
Location is conveyed directly or indirectly from transmitting SIP Location is conveyed directly or indirectly from a transmitting SIP
entity to a receiving SIP entity. If directly, then it is conveyed entity to a receiving SIP entity. When location is conveyed
as a value contained within the SIP request, see Figure 1., directly, it is conveyed as a value contained within the SIP
request, as in Figure 1.
Alice Bob LIS Alice Bob LIS
| | | | | |
| Request w/ Location | | | Request w/ Location | |
|------------------------>| | |------------------------>| |
| | | | | |
| Response | | | Response | |
|<------------------------| | |<------------------------| |
| | | | | |
Figure 1. Location Conveyed by Value Figure 1. Location Conveyed by Value
If location is conveyed indirectly, analogous to Content Indirection When location is conveyed indirectly, analogous to Content
[RFC4483], this is a case where Bob receives (from Alice) an LbyR Indirection [RFC4483], Bob receives (from Alice) a location URI and
location URI that requires an additional transaction - here called a must make an additional request - here called a dereference - to
dereference - to learn Alice's location by requesting that location learn Alice's actual location from a Location Server (LS)
from a LIS, see Figure 2., identified in the location URI, as in Figure 2.
Alice Bob LIS Alice Bob LS
| | | | | |
| Request w/ Location URI | | | Request w/ Location URI | |
|------------------------>| | |------------------------>| |
| | Fetch Request | | | Dereference Request |
| |---------------------->| | |---------------------->|
| | | | | |
| | Fetch Response | | | Dereference Response |
| |<----------------------| | |<----------------------|
| Response | (includes location) | | Response | (includes location) |
|<------------------------| | |<------------------------| |
| | | | | |
Figure 2. Location Conveyed by Reference Figure 2. Location Conveyed by Reference
Many protocols can be used for this fetch transaction, but this is Many protocols can be used for this dereference transaction, but
usually bounded by the scheme of the URI in the SIP request. In this is usually determined by the scheme of the location URI in the
other works, if the location URI is a SIPS: URI, then SIPS would be SIP request. In other words, if the location URI is a SIPS: URI,
used to contact the LIS to make the dereference. 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 The location "value" in this SIP extension is in the form of a
Presence Information Data Format - Location Object, or PIDF-LO, as "Presence Information Data Format - Location Object", or PIDF-LO, as
described in [RFC4119]. A PIDF-LO is an XML scheme specifically for described in [RFC4119]. A PIDF-LO is an XML scheme specifically for
carrying the geographic location of a Target. LbyV refers to a UA carrying the geographic location of a Target. LbyV refers to a UA
including a PIDF-LO as a body part of a SIP request, sending that including a PIDF-LO as a message body part of a SIP request, sending
Location Object to another SIP element. LbyR refers to a UA that Location Object to another SIP element. LbyR refers to a UA
including a location URI in a SIP request header field which can be including a location URI in a SIP request header field which can be
dereferenced by a Location Recipient to receive Alice's Location dereferenced by a Location Recipient to retrieve Alice's Location
Object, in the form of a PIDF-LO. Dereferencing is done by a Object, in the form of a PIDF-LO.
Location Recipient.
To accomplish location conveyance in SIP, a new SIP header, To accomplish location conveyance in SIP, a new SIP header field,
Geolocation, is created and described in this document. The Geolocation, is created and described in this document. The
Geolocation header field contains a URI that points to the where the Geolocation header field contains a URI that points to where the
location is for that target, either in the SIP request itself location is for the location target, either in the body of the SIP
(LbyV), or on an external server (LbyR). A location URI that points request itself (LbyV), or on a Location Server (LbyR). A location
to a message body is always a "cid:" URI (Content Identification), URI that points to a message body is always a "cid:" URI (Content
as defined in [RFC2392]. Identification), as defined in [RFC2392].
If the URI in the Geolocation header field is a scheme other than If the URI in the Geolocation header field is a scheme other than
"cid:", a fetch transaction (see Figure 2) is necessary. This "cid:", a dereference transaction (see Figure 2) is necessary. This
document describes how a SIP presence subscription [RFC3856] can be document describes how a SIP presence subscription [RFC3856] can be
used as a dereference protocol. used as a dereference protocol.
Including location in a SIP request is not limited to insertion by a Location can be inserted in a SIP request by a SIP server as well as
UA. There are times where a SIP server wants to insert location of a by a UA. This document offers guidance on this practice. This
location target into a request from that target towards the document also describes how a location recipient can determine which
request's destination. This document offers guidance on this entity included a specific location, as more than one location can
practice. This document also describes how a location recipient can be conveyed in a given SIP request. Section 4 gets into guidance and
determine which entity included what location, as it is allowed for limitations of this behavior.
more than one location to be conveyed in a given SIP request.
Section 4 gets into guidance and limitations of this behavior.
A new error response (424 Bad Location Information) is also defined A new error response (424 Bad Location Information) is also defined
in this document. Within this response is a new header indicating in this document. Within this response is a new header field
location-based errors, call the Geolocation-Error header. This indicating location-based errors, called the Geolocation-Error
header has various codes that provide additional information about header field. This header field has various codes that provide
the type of location error experienced by a Location Recipient. additional information about the type of location error experienced
by a Location Recipient, separated into actionable categories to be
taken by the UAC.
Because more than one SIP entity can insert location, when Because more than one SIP entity can insert location, when
considering SIP as an end-to-end protocol, there needs to be a means considering SIP as an end-to-end protocol, there needs to be a means
of identifying which location within a message of multiple locations of identifying which location within a message of multiple locations
was considered bad by a location recipient - if that were to occur. was considered bad by a location recipient - if that were to occur.
The ability to tell by host-id which entity inserted which location The ability to tell which entity (identified by host-id) inserted a
is extremely important. Not only does this allow each location error specific location is extremely important. Not only does this allow
to be targeted at a particular inserter of particular location, but each location error to be targeted at a particular inserter of a
it also allows error recipients to understand when their inserted specific location object, but it also allows error recipients to
location was not at fault, and when a received error is not meant understand when the location they inserted was not at fault, and
for them. This optimization is necessary, otherwise each location that a received error is not meant for them. This optimization is
error would be a blanket error to every entity upstream in this necessary, otherwise each location error would be a blanket error to
signaling path. every entity upstream in the signaling path.
Just as location can be conveyed by more than one entity about the Just as location can be conveyed by more than one entity about the
same target, there can be more than one location recipient along a same target, there can be more than one location recipient along a
message's path. It is possible, and it fact, planned in certain request's path. It is possible to route SIP requests based on the
circumstances to have SIP requests routed based on the location of location of the target (i.e., source based routing, instead of
the target. This means SIP servers can be location recipients. If normal destination based routing). This means SIP servers can be
this is not desired by a location inserter - the act of including location recipients. If this is not desired by a Location Inserter,
location into this request, then a separate indication is given in then the Location Inserter can also include a separate indication in
the Geolocation header it this usage is allowed. the Geolocation header field showing that this usage is not desired.
There is no mechanism by which the veracity of these parameters can Location Inserters have the ability to provide instructional
be verified. They are hints to downstream entities on how the parameters about location it has inserted. These are hints to
location information in the message was originated, intended and downstream entities on how the location information in the message
used. Transport Layer Security is expected when a request contains was originated, intended and is to be used.
a target's location. Some implementations will choose to have
S/MIME to encrypt message bodies from source to destination. Transport Layer Security is expected when a request contains a
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 This document creates a new option tag: geolocation, to indicate
support for this extension by UAs. support for this extension by UAs.
The new headers, the header parameters, the new option tag, the new The new header field, the header parameters, the new option tag, the
error response, and Geolocation-Error codes, which are defined in new error response, and Geolocation-Error codes are defined in
Section 4., are IANA registered by this document. Section 4, each of which are IANA registered by this document.
RFC 3693 demands that a transmitted location must maintain privacy RFC 3693 demands that a transmitted location be required to maintain
considerations. This document maintains all of the privacy privacy considerations. This document maintains all of the privacy
considerations defined by RFC 3693, plus adds an intended usage considerations defined by RFC 3693, plus adds an intended usage
indication within the SIP Geolocation header. This increases the indication within the SIP Geolocation header field. This increases
considerations for recipients not to inspect a target's location the considerations for recipients not to inspect a target's location
when they are not the intended location recipient. when they are not the intended location recipient.
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following are sections detail the standards track modifications The following sections detail the standards track modifications
to SIP for Location Conveyance. to SIP for Location Conveyance.
4.1 The Geolocation Header 4.1 The Geolocation Header Field
This document defines and IANA registers a new SIP header: This document defines Geolocation as a new SIP header field
Geolocation, with the following ABNF [RFC5234]: registered by IANA, with the following ABNF [RFC5234]:
Geolocation = "Geolocation" HCOLON (locationValue *(COMMA Geolocation = "Geolocation" HCOLON (locationValue *(COMMA
locationValue)) (COMMA retrans-param) locationValue)) (COMMA retrans-param)
locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationValue = LAQUOT locationURI RAQUOT *(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)
geoloc-param = "inserted-by" EQUAL geoloc-inserter geoloc-param = "inserted-by" EQUAL geoloc-inserter
/ "used-for-routing" / "used-for-routing"
/ generic-param ; (from RFC 3261) / generic-param ; (from RFC 3261)
geoloc-inserter = DQUOTE hostport DQUOTE geoloc-inserter = DQUOTE hostport DQUOTE
/ gen-value ; (from RFC 3261) / gen-value ; (from RFC 3261)
retrans-param = "routing-allowed" EQUAL "yes" / "no" retrans-param = "routing-allowed" EQUAL "yes" / "no"
sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. sip-URI, sips-URI and absoluteURI are defined according to [RFC3261].
The pres-URI is defined in RFC 3859 [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. This URI type MUST be present in a SIP request if location parts. This URI type is present in a SIP request where location
is transmitted LbyV only. is conveyed as a value.
Other protocols used in the Location URI MUST be reviewed against Other protocols used in the location URI MUST be reviewed against
the RFC 3693 criteria for a Using Protocol. the RFC 3693 criteria for a Using Protocol.
The Geolocation header MAY have one or more locationValues. SIP The Geolocation header field MAY have one or more locationValues.
servers inserting a locationValue MUST add the new value as the last SIP servers inserting a locationValue MUST add the new value as the
locationValue in the Geolocation header (i.e., the last last locationValue in the Geolocation header field (i.e., the last
locationValue in the header is the most recent one added to the locationValue in the header field is the most recent one added to
message). Placement of the "routing-allowed" parameter, when the message). Placement of the "routing-allowed" parameter, when
present, MUST be the last header value in the Geolocation header. present, MUST be the last header field value in the Geolocation
header field.
A locationValue has the following independent header parameters, A locationValue has the following independent header field
parameters,
o the "inserted-by=" parameter provides the hostport o the "inserted-by=" parameter provides the hostport
(alice.example.com -- which is the same as the "sent-by" (alice.example.com -- which is the same as the "sent-by"
parameter in a Via header, with or without a port number) of the parameter in a Via header field, with or without a port number)
SIP entity that inserted this locationValue into the request. If of the SIP entity that inserted this locationValue into the
a Location Recipient has determined a supplied location is in request. If a Location Recipient has determined a supplied
error, as there can be more than one in any request, the location is in error, as there can be more than one location in
"inserted-by=" parameter is copied into the locationErrorValue in any request, the "inserted-by=" parameter is copied into the
the response indicating the location error, and to whom the error locationErrorValue in the response indicating the location error,
is for. Hence, this "inserted-by=" parameter MUST be present in and to whom the error is for. Hence, this "inserted-by="
each locationValue. If an entity receives an Geolocation-Error parameter MUST be present in each locationValue. If an entity
with a hostport not identifying this entity, the receives an Geolocation-Error with a hostport that does not
Geolocation-Error MUST be ignored. identify this entity, the Geolocation-Error MUST be ignored.
o the "used-for-routing" parameter to inform recipients that the o the "used-for-routing" parameter to inform recipients that the
location in this locationValue was used to route the message location in this locationValue was used to route the message
towards the ultimate destination UAS. "used-for-routing" can towards the ultimate destination UAS. "used-for-routing" can
occur more than once along the request's path. Because occur more than once along the request's path. Because
locationValues are inserted as last inserted is last in the locationValues are inserted as last inserted is last in the
header, the last locationValue is the most recent one added to header field, the last locationValue is the most recent one added
the message. This also gives the "used-for-routing" header to the message. This also gives the "used-for-routing" header
parameter added meaning - as the receiving SIP entity knows which field parameter added meaning - as the receiving SIP entity knows
locationURI the message was routed upon. which location URI the message was routed upon.
Each locationValue MUST contain exactly one "inserted-by" parameter, Each locationValue MUST contain exactly one "inserted-by" parameter,
indicating which SIP entity added the locationValue to the SIP indicating which SIP entity added the locationValue to the SIP
request. request.
There MUST NOT be more than one "inserted-by=" parameter or one There MUST NOT be more than one "inserted-by=" parameter or one
"used-for-routing" parameter in the same locationValue. However, "used-for-routing" parameter in the same locationValue. However,
there can be more than one locationValue in the same Geolocation there can be more than one locationValue in the same Geolocation
header. header field.
The "routing-allowed" header parameter is a global parameter over The "routing-allowed" header field parameter is a global parameter
any (and all/each) locationValues in the Geolocation header. This over any (and all/each) locationValues in the Geolocation header
is the reason why the placement of the header parameter is outside field. This is the reason why the placement of the header field
any locationValue, and appears only once, and is always last in the parameter is outside any locationValue, appears only once, and is
header value. always last in the header field value.
This header parameter has values "=yes" or "=no" only. When this This header field parameter only has the values "=yes" or "=no".
parameter "=yes", any locationValue can be used for routing When this parameter is "=yes", any locationValue can be used for
decisions along the downstream signaling path by intermediaries. routing decisions along the downstream signaling path by
When this parameter "=no", this means no locationValue (inserted by intermediaries. When this parameter is "=no", this means no
the originating UAC or any (or subsequent) intermediary(ies) along locationValue (inserted by the originating UAC or any (or
the signaling path) can be used by any SIP intermediary to make subsequent) intermediary(ies) along the signaling path) can be used
routing decisions. This behavior MUST be adhered to. by any SIP intermediary to make routing decisions. This behavior
MUST be adhered to. Section 4.3 describes the details on what a
routing intermediary does if it believes 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 an LbyV is present in the SIP request, parameter is set to "no", if an LbyV is present in the SIP request,
intermediaries SHOULD NOT view the location (because it is not intermediaries MUST NOT view the location (because it is not
for intermediaries to view), and if an LbyR is present, SHOULD NOT for intermediaries to view), and if an LbyR is present, MUST NOT
dereference it. UASs are allowed to view location in the SIP dereference it. UASs are allowed to view location in the SIP
request even when the "routing-allowed" header parameter is set to request even when the "routing-allowed" header field parameter is
"no". set to "no".
The default behavior when this header parameter is not present in a The default behavior when this header field parameter is not present
message is to treat the SIP request as if the parameter were present in a message is to treat the SIP request as if the parameter were
and its value is set to "no". present and its value is set to "no".
This document defines the Geolocation header 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] and PRACK [RFC3262]
Discussing location using the PUBLISH request is out of scope Discussing location using the PUBLISH request is out of scope
for this document since it is part of Presence, therefore, for for this document since it is part of Presence, therefore, for
completeness, Table 1 shows PUBLISH is to support Location completeness, Table 1 shows PUBLISH is to support Location
Conveyance via this extension, but is not discussed further. Conveyance via this extension, but is not discussed further.
The following table extends the values in Table 2&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 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 above
requests by a UAC. A proxy MAY add the Geolocation header, but MUST requests by a UAC. A proxy MAY add the Geolocation header field,
NOT modify any pre-existing locationValue, including any associated but MUST NOT modify any pre-existing locationValue, including any
header parameters within an existing Geolocation header value, associated header field parameters within an existing Geolocation
unless one of the existing locationValues is used to retarget the header field value, unless one of the existing locationValues is
request towards a new destination UAS. This is discussed in section used to retarget the request towards a new destination UAS. This is
6.3. discussed in section 6.3.
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation header field added by a proxy MUST be in Therefore, any Geolocation header field added by a proxy MUST be in
the form of an LbyR URI, in its own locationValue header value. the form of an location URI, in its own locationValue header field
value.
A SIP proxy MAY add a Geolocation header if one is not present, and A SIP proxy MAY add a Geolocation header field if one is not
MAY add the "routing-allowed" parameter if not yet present in the present, and MAY add the "routing-allowed" parameter if not yet
SIP request. When a "routing-allowed" parameter is already present present in the SIP request. When a "routing-allowed" parameter is
in the SIP request, a SIP server MUST NOT change the value of the already present in the SIP request, a SIP server MUST NOT change the
parameter (i.e., from 'yes' to 'no', or from 'no' to 'yes'). This value of the parameter (i.e., from 'yes' to 'no', or from 'no' to
would override the policy set by an upstream SIP entity (i.e., 'yes'). This would override the policy set by an upstream SIP
likely the UAC). entity (i.e., likely the UAC).
Adding a new locationValue to an in-transit request is NOT Adding a new locationValue to an in-transit request is NOT
RECOMMENDED to occur for at least two reasons, RECOMMENDED for at least two reasons,
#1 - SIP Servers are not the best locators geographically of where a #1 SIP Servers are not the best locators geographically of where a
UAC is; meaning the location information is not necessarily the UAC is; the location information that a SIP server knows may
greatest. There MAY be exceptions, but this SHOULD be the rule not be the best location information available.
of thumb.
#2 - without appropriate caution to the fact that Location #2 this document gives limited guidance as to what a Location
Recipients might not understand how to process more than one Recipient should do when receiving more than one location (no
location, given this document's limited guidance as to what a instructions are given about which locationValue to use when
Location Recipient should do when receiving more than one more than one is present), so adding a new locationValue may
location (i.e., currently no priority instructions are given lead to undesirable results.
for which locationValue to use if there are more than one). A
Location Recipient can easily be confused by too much location
information, producing undesirable results. The <dm:device id>
element [RFC5491] in the PIDF-LO XML indicates whose location
is contained in the PIDF-LO.
Location Recipients receiving a location object, received directly Location Recipients receiving a location object, whether received
or as the result of a dereference, MUST honor the usage element directly or as the result of a dereference, MUST honor the usage
rules within that XML document, as defined in [RFC4119]. Such element rules within that XML document, as defined in [RFC4119].
entities MUST NOT alter the rule set. Such entities MUST NOT alter the rule set.
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 the location
information was malformed or not satisfactory for the recipient's information was malformed or not satisfactory for the recipient's
purpose, or could not be dereferenced. purpose, or could not be dereferenced.
Section 4.3 creates the Geolocation-Error header to provide more Section 4.3 creates the Geolocation-Error header field to provide
detail about what was wrong with the location information in the more detail about what was wrong with the location information in
request. This header MUST be in the 424 response, containing a the request. This header field MUST be in the 424 response,
locationErrorValue for each invalid locationValue in the request containing a locationErrorValue for each invalid locationValue in
(i.e., and one-for-one matching if all locationValues in the request the request (i.e., and one-for-one matching if all locationValues
were bad). in the request were bad).
If more than one location is present in a request (LbyV or LbyR), If more than one location is present in a request (LbyV or LbyR),
and any of the locationValues is good for the Location Recipient to and the Location Recipient can process any of the locationValues, a
process, a 424 MUST NOT be sent. The 424 is only appropriate when 424 MUST NOT be sent. The 424 is only appropriate when the Location
the Location Recipient needs a locationValue and there are no Recipient needs a locationValue and there are no locationValues
locationValues included in a SIP request that are usable by a included in a SIP request that are usable by a recipient.
recipient.
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 a usage or a dialog. a transaction, and does not terminate an existing dialog.
The UAC can use whatever means it knows of to verify/refresh its The UAC can use whatever means it knows of to verify/refresh its
location information before attempting a new request that includes location information before attempting a new request that includes
location. There is no cross-transaction awareness expected by either location. There is no cross-transaction awareness expected by either
the UAS or any SIP intermediary as a result of this error message. the UAS or any SIP intermediary as a result of this error message.
The new 424 (Bad Location Information) error code is registered with
The new 424 (Bad Location Information) error code is IANA registered IANA in Section 8 of this document. An initial set of
in Section 8 of this document. An initial set of location error of IANA-registered Geolocation-Error codes are in Section 4.3 of this
IANA registered Geolocation-Error codes are in Section 4.3 of this
document. document.
4.3 The Geolocation-Error Header 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 UAC is to know what was wrong within the original request. if the UAC is to know what was wrong within the original request.
The Geolocation-Error header is created here for this purpose. The Geolocation-Error header field is used for this purpose.
Geolocation-Error header is used to convey location specific errors The Geolocation-Error header field is used to convey
within a response. Additions to this IANA registered header require location-specific errors within a response. Additional
an RFC be published. The Geolocation-Error header has the following IANA-registered values must be defined in an RFC (this is the "RFC
ABNF [RFC5234]: Required" IANA policy defined in [RFC5226]). The Geolocation-Error
header field has the following ABNF [RFC5234]:
Geolocation-Error = "Geolocation-Error" HCOLON Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue locationErrorValue
*(COMMA locationErrorValue) *(COMMA locationErrorValue)
locationErrorValue = location-error-code *(SEMI locationErrorValue = location-error-code *(SEMI
location-error-params) location-error-params)
location-error-code = 1*3DIGIT location-error-code = 1*3DIGIT
location-error-params = location-error-node-id location-error-params = location-error-node-id
/ location-error-host-id / location-error-host-id
/ location-error-code-text / location-error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC3261
location-error-node-id = "node" EQUAL location-error-node-id = "node" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261 DQOUTE hostport DQOUTE ; from RFC3261
location-error-host-id = "inserter" EQUAL location-error-host-id = "inserter" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261 DQOUTE hostport DQOUTE ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
The Geolocation-Error header MUST contain at least one The Geolocation-Error header field MUST contain at least one
locationErrorValue to indicate what was wrong with the original locationErrorValue to indicate what was wrong with the locationValue
locationValue in the corresponding request. If a Location Recipient in the corresponding request the Location Recipient determined was
experienced more than one error a particular locationValue of the bad. Each locationErrorValue contains a 3-digit error code
corresponding SIP request, there can be one locationErrorValue per indicating what was wrong with the location in the request. Each
problem with the locationValue in the request. Each error type has a corresponding quoted error text string that is
locationErrorValue contains one 3-digit error code indicating what human understandable.
was wrong with the location in the request. Each error type has a
corresponding quoted error text string that is human
understandable. If there was something wrong with more than one
locationValue in a request, a corresponding locationErrorValue would
be sent, one per error, in the response.
Each locationErrorValue contains the Location Recipient identifier Each locationErrorValue contains the Location Recipient identifier
(the "node=" parameter) which experienced the location error, as (the "node=" parameter) which experienced the location error, as
well as an identifier of which SIP entity (the "inserter=" well as an identifier of which SIP entity (the "inserter="
parameter) the Location Recipient is told (in the locationValue) parameter) the Location Recipient is told (in the locationValue)
added this problematic locationValue to the request. The "node=" added this problematic locationValue to the request. The "node="
and "inserter=" are the domain identifier of a SIP entity, with the and "inserter=" are the domain identifier of a SIP entity, with the
ability to have the same host communicate on different ports - and ability to have the same host communicate on different ports - and
have port specific identification. This is the same as is entered in have port specific identification. This is the same information that
the "sent-by" parameter of the Via header for that entity would be entered in the "sent-by" parameter of the Via header field
[RFC3261]. As stated in section 18 of RFC 3261, the usage of FQDN for that entity [RFC3261]. As stated in section 18 of RFC 3261,
is RECOMMENDED. Here are examples of both locationErrorValue the usage of FQDN is RECOMMENDED. Here are examples of both
parameters locationErrorValue parameters,
node="bob.example.com" node="bob.example.com"
inserter="alice.example.com" inserter="alice.example.com"
Both the "node=" and "inserter=" parameters MUST be present in all Both the "node=" and "inserter=" parameters MUST be present in all
locationErrorValues in a response, unless the "inserted-by=" locationErrorValues in a response, unless the locationValue of the
parameter was not in the locationValue of a request (which is a request did not include the "inserted-by=" parameter (which is a
violation of this document). The "inserter=" parameter value is violation of this document). The "inserter=" parameter value is
copied from the "inserted-by=" parameter within the locationValue of copied from the "inserted-by=" parameter within the locationValue of
the request. No manipulation or calculation is necessary to the request.
accomplish this.
Here's why this is necessary, a Location Recipient that experienced This is required because a Location Recipient that experienced a
the location problem with the request needs to tell the specific SIP problem with the location included in a request needs to tell the
entity which added the locationValue in error into the original specific SIP entity which added the locationValue in error into the
request. Since more than one SIP entity can insert location into a original request. Since more than one SIP entity can insert
request in transit, all other SIP elements may be confused by location into a request in transit, all other SIP elements may be
receiving this error header, were it to remain generic to all confused by receiving this error header field, were it to remain
entities in the response path. So, the header has to identify who generic to all entities in the response path. This requirement
it is for, so that all other SIP entities that read the header know means that the header field identifies the Location Inserter who
to ignore it, since it is not for them. This is of particular use inserted the problematic locationValue, so that all other SIP
if the original UAC did not include a locationValue in the original entities that read the header field know to ignore it. This is of
SIP request, but a SIP server along the path did insert a particular use if the original UAC did not include a locationValue
locationValue. The locationErrorValue would travel to each SIP in the original SIP request, but a SIP server along the path did
entity along the original path and tell both the server that insert a locationValue. The locationErrorValue would be interpreted
included the locationValue what was wrong with the location and the by each SIP entity along the original path upstream and be processed
UAC who did not know what the error meant. This will cause by both the server that included the invalid locationValue and the
confusion if left without this indication. UAC that did not, resulting in confusion at the UAC.
A worse case is when both the original UAC and a SIP server along A worse case is when both the original UAC and a SIP server along
the path included a locationValue, but there was only something the path included a locationValue, but there was something
wrong with one of the locationValues. Without this identification wrong with only one of the locationValues. Without an
of which locationValue was in error, both entities would react and identification of the specific locationValue in error, both entities
one would do so incorrectly. would react, and one would react incorrectly.
More than one locationErrorValue in a Geolocation-Error header is When more than one locationErrorValue is present in a
separated by a comma. Geolocation-Error header field, they are separated by commas.
If more than one locationErrorValue is in a response, and intended If more than one locationErrorValue is present in a response, and
for the same "inserter=", each error code MUST be unique to this intended for the same "inserter=", each error code MUST be unique to
"inserter=" entity, and the error codes SHOULD NOT conflict in this "inserter=" entity, and the error codes MUST NOT conflict in
meaning. In other words, two error codes (within separate meaning.
locationErrorValues of the same response) SHOULD NOT give misleading
or inconsistent indications to the location "inserter=".
Here is an example of a Geolocation-Error header Here is an example of a Geolocation-Error header field:
Geolocation-Error: 200; code="Retry Location Later"; Geolocation-Error: 200; code="Retry Location Later";
node="bob.example.com"; node="bob.example.com";
inserter="alice.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 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 Geolocation was in the
request part of the transaction. The choice of which SIP requests request part of the transaction. For example, Alice includes her
are in table 2 above come from which Methods can optionally have the location in an INVITE to Bob. Bob can accept this INVITE, thus
Geolocation header (see section 4.1). That said, a UAC MUST ignore creating a dialog, even though his UA determined the location
a Geolocation-Error header value if it did not include a Geolocation contained in the INVITE was bad. There is a Geolocation-Error
header value in the request part of the transaction. header value in the 200 OK to the INVITE informing Alice the INVITE
was accepted but the location provided was bad. The SIP requests
included in table 2 above are the ones allowed to optionally contain
the Geolocation header field (see section 4.1). That said, a UAC
MUST ignore a Geolocation-Error header field value that did not
contain its host-id..
Here is an example of a transaction that has a location error. In Here is an example of a transaction that has a location error. In
this case, Bob responds with a 424 (Bad Location Information) this case, Bob responds with a 424 (Bad Location Information)
response, including a Geolocation-Error header, is in Figure 3. response, including a Geolocation-Error header field, is in Figure 3.
Alice Bob Alice Bob
| | | |
| Request w/ Location | | Request w/ Location |
|------------------------------------------------>| |------------------------------------------------>|
| | | |
| | | |
| 424 (Bad Location Information) | | 424 (Bad Location Information) |
| with Geolocation-Error containing | | with Geolocation-Error containing |
| 200 ("Retry Location Later" (with same data)) | | 200 ("Retry Location Later with same data") |
|<------------------------------------------------| |<------------------------------------------------|
| | | |
Figure 3. Basic Transaction with 424 and Geolocation-Error Header Figure 3. Basic Transaction with 424 and Geolocation-Error Header
Field
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, each based on receiver (of the response) into 5 categories, based on how the response receiver should react
actionable reactions to these errors. to these errors.
o 100 "Cannot Process Location" o 1XX "Cannot Process Location"
o 200 "Retry Location Later" (with same data) o 2XX "Retry Location Later with same data"
o 300 "Retry Location Later" (with device updated location) o 3XX "Retry Location Later with updated device location"
o 400 "Permission Necessary" o 4XX "Permission To Reveal Location Information to a Third Party"
o 500 "Location Information Denial" o 5XX "Location Information Denial"
All 5 of the above error codes MUST be implemented to comply with All 5 of the above error codes MUST be implemented to comply with
this specification. Each of these actionable errors is given a 3 this specification. Each of these actionable errors is given a 3
digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX,
and 5XX error codes defined will have the same action expected by and 5XX error codes defined will have the same action expected by
X00 categories - just increase granular meaning. If another action X00 categories, although the future error code may provide more
is expected to occur with a newly defined error code, it MUST granular information. If another action is expected to occur with a
outside the 100-599 range. 100 unit ranges are OPTIONAL for future newly defined error code, it MUST outside the 100-599 range.
error codes, but they apply here.
4.3.1 Location Error: 100 "Cannot Process Location" 4.3.1 Location Error: 100 "Cannot Process Location"
The location error 100 "Cannot Process Location" indicates to a The location error 100 "Cannot Process Location" indicates to a
Geolocation-Error recipient that what they supplied in a request, as Geolocation-Error recipient that the locationValue supplied in a
far as location is concerned, cannot be processed at this time. request cannot be processed at this time. This only has to do with
This only has to do with the location that the location "inserter=" the location that the location "inserter=" added to the request, and
added to the request, and not about the overall request that was not about the overall request that was sent.
sent.
Action(s) to be taken by Geolocation-Error receiver to a 1XX: 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 This error gives no guidance on what to do next. It is a
general information indication to a SIP "inserter=" entity general information indication to a SIP "inserter=" entity
that there was an unspecific problem with the location that there was an unspecific problem with the location
supplied in the SIP request. supplied in the SIP request.
Implementations MAY choose to react in a way as if this "inserter=" Implementations MAY choose to react as if the "inserter="
entity received a 2XX or 3XX location error. A 4XX error MUST NOT be entity received a 2XX or 3XX location error. Implementations MUST
misunderstood here, as that error category involves human NOT react as if the "inserter=" entity received a 4XX location
intervention to grant, or not, permission to reveal "inserter=" error, as that error category involves human intervention to grant,
location when this is likely not desired. or not, permission to reveal "inserter=" location when this is
likely not desired.
The text string of "Cannot Process Location" is RECOMMENDED, but not The text string of "Cannot Process Location" is RECOMMENDED, but not
mandatory for usage in this error. Implementations MAY use another mandatory for usage in this error. Implementations MAY use another
text string. text string.
An example of this location error is here: An example 100 location error is:
Geolocation-Error: 100; code="Cannot Process Location"; Geolocation-Error: 100; code="Cannot Process Location";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 1XX. The same basic actionable This category covers all 1XX location errors. The same basic
reaction is expected by a location "inserter=" entity to any 1XX reaction is expected when a location "inserter=" entity receives any
location error. 1XX location error.
4.3.2 Location Error: 200 "Retry Location Later" (same data) 4.3.2 Location Error: 200 "Retry Location Later same data"
The location error 200 "Retry Location Later" (same data) indicates The location error 200 "Retry Location Later same data" indicates
to a Geolocation-Error recipient that what they supplied in a to a Geolocation-Error recipient that what they supplied in a
request, as far as location is concerned, cannot be processed at request, as far as location is concerned, cannot be processed at
this time, but to retry this request, without changing the location this time, but there is no need to update the location at a later
information, at a later time - in a new SIP request. It is possible time in a new SIP request. For example, this location error is
that the Location Recipient cannot process location at this time, or appropriate when the Location Recipient cannot process location at a
there was a timeout during dereferencing, if an LbyR were sent. 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 to a 2XX: Action(s) to be taken by Geolocation-Error receiver for a 2XX:
Reactions to a 2XX location error are to try again, without Reactions to a 2XX location error are to try again after some
having to update the location supplied originally. There is period of time has elapsed. The "inserter=" has not identified
no constraints on how long this new try has to wait, unless problems with the location provided in the original request,
there is a Retry-After header in a 424 response. 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.
Implementations SHOULD choose to react by preparing, however this Implementations SHOULD choose to react by queuing another message
"inserter=" does or can, to queue another message with the same with the same location information, unless the "inserter=" entity
location information, provided the "inserter=" does not move between knows it has changed locations.
the time of the original request and the transmission time of the
new request.
Implementations MAY choose whether or not to inform the user of this Implementations MAY inform the user of this error. The text string
error. The text string of "Retry Location Later" is RECOMMENDED, of "Retry Location Later same data" is RECOMMENDED, but not
but not mandatory for usage in this error. Implementations MAY use mandatory for this error. Implementations MAY use another text
another text string to inform the user that location was not string to inform the user that location was not received by the UAS
received by the UAS (i.e., the called party). (i.e., the called party).
An example of this location error is here: An example 200 location error is:
Geolocation-Error: 200; code="Retry Location Later"; Geolocation-Error: 200; code="Retry Location Later same data";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 2XX. The same basic actionable This category covers all 2XX location errors. The same basic
reaction is expected by a location "inserter=" entity to any 2XX reaction is expected when a location "inserter=" entity receives any
location error. 2XX location error.
If a SIP request has the "routing-allowed" header parameter set to If a SIP request has the "routing-allowed" header field parameter
"no", and the SIP server believes processing location within the set to "no", and the SIP server believes processing location is
request in order to service the request properly, a 2XX location required in order to service the request properly, a 2XX location
error is sent towards the recipient. This error is the proper error 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 even when there is no location in the SIP request, but the SIP
request contains a policy statement that location is not to be request contains a policy statement that location is not to be
viewed during transit towards the ultimate destination. viewed during transit towards the ultimate destination.
4.3.3 Location Error: 300 "Retry Location Later" (device updated 4.3.2.1 Location Error: 201 "Linkable Target Identity Required"
location)
The location error 300 "Retry Location Later" (device updated The error code 201 "Linkable Target Identity Required" is
location) indicates to a Geolocation-Error recipient that what they 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 supplied in a request, as far as location is concerned, cannot be
processed at this time, but to retry this request, once the location processed. In order to retry this request in a new SIP request, the
information has been updated, in a new SIP request. location information must be updated.
Action(s) to be taken by Geolocation-Error receiver to a 3XX: Action(s) to be taken by Geolocation-Error receiver for a 3XX:
3XX location errors indicate the "inserter=" SIP entity needs 3XX location errors indicate the "inserter=" SIP entity needs
to refresh its location, or make the location information to refresh its location, or make the location information
supplied more complete, without notifying the user of this supplied more complete, without notifying the user of this
error. 3XX error are to be solved by without user error. 3XX errors may be resolved without user intervention.
intervention.
This document gives no guidance how this is accomplished, given the This document gives no guidance how this is accomplished, given the
number of ways a UAC can learn its location, or a SIP intermediary number of ways a UAC can learn its location, or a SIP intermediary
can Sight a UAC, as defined in [RFC3693]. can Sight a UAC, as defined in [RFC3693].
This 300 location error currently does not indicate what exactly was This 300 location error currently does not indicate what exactly was
wrong with the location supplied, according to the Location wrong with the location supplied, according to the Location
Recipient. That is left for a future effort. Recipient. That is left for a future effort.
Implementations MAY choose whether or not to inform the user of this Implementations MAY choose whether or not to inform the user of this
error. The text string of "Retry Location Later" is RECOMMENDED, error. The text string of "Retry Location Later with device updated
but not mandatory for usage in this error. Implementation MAY use location" is RECOMMENDED, but not mandatory for usage in this
another text string to inform the user that location was not error. Implementation MAY use another text string to inform the
received by the UAS (i.e., the called party). user that location was not received by the UAS (i.e., the called
party).
A 3XX location error would be used where the Location Recipient A 3XX location error would be used where the Location Recipient
cannot find or cannot parse the location supplied, believing that a cannot find or cannot parse the location supplied. 3XX location
automated refresh and retry could fix the problem. Also, a 3XX errors should cause a requestor to retry with refreshed location
location error would be used when a Location Recipient did not find information, which might be sufficient to fix the problem. Also, a
any location in a SIP request, but was expecting it. Perhaps an 3XX location error would be used when a Location Recipient was
emergency request was made that did not contain location. The retry expecting to find location in a SIP request, but did not find it -
in this case would be in the form of an UPDATE Method request, perhaps an emergency request was made that did not contain location.
containing location (LbyV or LbyR). 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 of this location error is here: An example 300 location error is:
Geolocation-Error: 300; code="Retry Location Later"; Geolocation-Error: 300; code="Retry Location Later with device
updated location";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 3XX. The same basic actionable This category covers all 3XX location errors. The same basic
reaction is expected by a location "inserter=" entity to any 3XX reaction is expected when a location "inserter=" entity receives any
location error. 3XX location error.
4.3.4 Location Error: 400 "Permission Necessary"
The location error 400 "Permission Necessary" indicates to a 4.3.4 Location Error: 400 "Permission to Reveal Location Information to
Geolocation-Error recipient that when they sent a particular SIP a Third Party"
request, they included location in that request without giving The location error 400 "Permission to Reveal Location Information to
permission in the request for a (or any) SIP server to look at that a Third Party" indicates to a Geolocation-Error recipient that they
location information (i.e., the <retransmission-allowed> was set to sent a particular SIP Request including location in that request,
"no" in the PIDF-LO for B2BUAs, or "routing-allowed=no" as a without giving permission in the request for an intermediary SIP
Geolocation header parameter for proxy servers) to route the message entity to look at that location information (i.e., the
at the intended recipient (i.e., the UAS, or the called party). <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 UAS, or the called party).
Action(s) to be taken by Geolocation-Error receiver to a 4XX: Action(s) to be taken by Geolocation-Error receiver for a 4XX:
4XX location errors indicate to the UAC (i.e., the calling 4XX location errors indicate to the UAC (i.e., the calling
party) that they need to grant permission to a SIP party) that they need to grant permission to a SIP
intermediary server to look at the supplied location to intermediary server to look at the supplied location to
complete the message routing. This indication MUST require complete the message routing. This indication MUST require
human user intervention, as the rulemaker of the policy on human user intervention, acting as the ruleholder of the
whether or not their location is to be revealed. policy on whether or not location is to be revealed.
The user of the location "inserter=" device can choose to grant The user of the location "inserter=" device can choose to grant
permission to this SIP intermediary server to allow this request to permission to this SIP intermediary server to allow this request to
be routed, or the user can deny this location revelation (request by be routed, or the user can deny permission. It is the user's choice
the server). It is the user's choice as rulemaker. as ruleholder.
Implementations MUST provide the user, as rulemaker, a clear Implementations MUST provide the user, as ruleholder, a clear
indication that permission to consume their location is sought by an indication that permission to consume their location is sought by an
entity other than who that user is calling. The text string of entity that is not the entity that the user is calling. The text
"Permission Necessary" is RECOMMENDED, but not mandatory for usage string of "Permission To Reveal Location Information to a Third
in this error. Implementation MAY use another text string to inform Party" is RECOMMENDED, but not mandatory for usage in this error.
the user that location is being sought by an intermediary (i.e., not Implementations MAY use another text string to inform the user that
the called party). location is being sought by an intermediary (i.e., not the called
party).
This document gives no guidance how this intervention is This document gives no guidance how the UAC can seek permission from
accomplished, given the number of ways a UAC can accomplish this the user, given the number of ways a UAC can accomplish this (i.e.,
(i.e., audio prompt or toggle or keystroke on their UA). audio prompt or toggle or keystroke on a UA).
This 400 location error currently does not indicate exactly which This 400 location error indicates exactly which SIP server indicates
SIP server indicates it needs the location revealed. That said, the that it needs the location by the "node=" FQDN address supplied,
"node=" FQDN address could be supplied, telling the user (via audio perhaps telling the user (via audio or video indication) which SIP
or video indication) which SIP entity wants this location. Perhaps entity wants this location. Perhaps the user can know in some
the user can know in some circumstances whether this is an circumstances whether this is an appropriate "node=" (domain). This
appropriate "node=" (domain). All of this is left for a future latter feature is not described in this document.
effort(s).
An example of this location error is here: An example 400 location error is:
Geolocation-Error: 400; code="Permission Necessary"; Geolocation-Error: 400; code="Permission to Reveal Location
Information to a Third Party";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 4XX. The same actionable This category covers all 4XX location errors. The same resolution
solution is expected to be afforded to the UAC user, as rulemaker, is expected to be afforded to the UAC user, as ruleholder, to any
to any 4XX location error. 4XX location error.
4.3.5 Location Error: 500 "Location Information Denial" 4.3.5 Location Error: 500 "Location Information Denial"
The location error 500 "Location Information Denial" indicates to a The location error 500 "Location Information Denial" indicates to a
Geolocation-Error recipient that what they supplied in a request, as Geolocation-Error recipient that what they supplied in a request, as
far as location is concerned, has been denied at this time. far as location is concerned, has been denied at this time.
This only has to do with the location that the location "inserter=" This only has to do with the location that the location "inserter="
added to the request, and not about the overall request that was added to the request, and not about the overall request that was
sent. If this were applied to the SIP request itself, this would sent. If this were applied to the SIP request itself, this would
equate to a 6XX Global error. equate to a 6XX Global error.
Action(s) to be taken by Geolocation-Error receiver to a 1XX: 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 This error gives no guidance on what to do next, other than to
not try again with this same location supplied. not try again with this same location supplied.
If the Location Recipient believed that merely refreshing, or in If the Location Recipient determined that merely refreshing, or in
some other way alter or augment the location supplied would work in some other way alter or augment the location supplied would work in
a new request, then a 3XX location error SHOULD have been returned a new request, then a 3XX location error would have been more
(to the "inserter="). An example of why this 5XX could have been appropriate. An example of why this 5XX could have been returned is
returned is if location were sent as an LbyR, and the LIS denied the if location were sent as a location URI, and the LS denied the
dereference request from the Location (reference) Recipient, this is dereference request from the potential Location Recipient, this is
the expected location error returned to the "inserter=" entity. 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 interpret anything else into this location Implementations MUST NOT make any assumptions about the implications
error other than it is considered a location based denial error. of this location error other than recognizing that a location based
This does not mean the SIP request was denied, or even had an error, denial error has occurred. This does not mean the SIP request was
unless the response was a 424. Otherwise, this only has to do with denied, or even had an error, unless the response was a 424.
the location part of the request. 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 The difference between a 1XX and a 5XX location error is simple. A
1XX location error is a case of a Location Recipient either not 1XX location error is appropriate when a Location Recipient either
knowing or not being able to tell the "inserter=" entity what was does not know or cannot tell the "inserter=" entity what was wrong
wrong with the location supplied in a SIP request. Whereas, a 5XX with the location supplied in a SIP request. A 5XX location error
location error is where the location was purposely, and actively is appropriate when the Location Recipient was purposely and
denied (or declined) from being received by the Location Recipient actively prevented from retrieving the location information. This
entity, or its user. This could occur in a UAS or SIP server. could occur in a UAS or SIP server.
If implementations choose to inform the UAC user of this error, the If implementations choose to inform the UAC user of this error, the
text string of "Location Information Denial" is RECOMMENDED, but not text string of "Location Information Denial" is RECOMMENDED, but not
mandatory for usage in this error. Implementations MAY use another mandatory for usage in this error. Implementations MAY use another
text string. text string.
An example of this location error is here: An example of this location error is here:
Geolocation-Error: 500; code="Location Information Denial"; Geolocation-Error: 500; code="Location Information Denial";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 5XX. The same basic actionable This category covers 5XX location errors. The same basic reaction
reaction is expected by a location "inserter=" entity to any 5XX is expected when a location "inserter=" entity receives any 5XX
location error. location error.
4.3.6 Which Scenario Matches Which Error Code? 4.3.6 Which Scenario Matches Which Error Code?
The following are some additional failure scenarios, with which The following scenario/error code mapping MUST be used for
error code SHOULD be used for consistency, consistency,
- Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI - Scheme (sip:, or sips:, or pres:, etc.) of the location URI
isn't supported (100) isn't supported - (100)
- Format (geo or civic) isn't supported (100) - Format (geo or civic) isn't supported - (100)
- Cannot parse location (100) - Found where location should be, but do not understand what is
- Can't find LIS (no access or no path (100) or denied access(500)) there -(300)
- Dereference failed (timeout) (200) - Cannot find LS in location URI (no access or no path) - (100) or
- Insufficient location info supplied (300) denied access - (500))
- Cannot find location in message (300) - Dereference failed (timeout) - (200)
- Insufficient location info supplied - (300)
4.4 The 'geolocation' Option Tag 4.4 The 'geolocation' Option Tag
This document creates and IANA registers one new option tag: This document creates and IANA registers one new option tag:
"geolocation". This option tag is to be used, as defined in RFC "geolocation". This option tag is to be used, as defined in
3261, in the Require, Supported and Unsupported headers. Whenever a [RFC3261], in the Require, Supported and Unsupported header fields.
UA wants to indicate support for this SIP extension, the geolocation
option tag is included in a Supported header of the SIP request.
4.5 Using sip/sips/pres as a Dereference Scheme 4.5 Using sip/sips/pres as a Dereference Scheme
If an LbyR URI is included in a SIP request, it MUST be a SIP-, If an LbyR URI is included in a SIP request, it MUST be a SIP-,
SIPS- or PRES-URI. When PRES: is used, if the resulting resolution, SIPS- or PRES-URI. When PRES: is used, if the resulting resolution,
as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this
section applies. section applies.
This document IANA registers 3 mandatory to implement URI schemes This document IANA registers 3 mandatory-to-implement URI schemes
for LbyR: for LbyR:
o SIP: o SIP:
o SIPS: o SIPS:
o PRES: o PRES:
These 3 are IANA registered in Section 9.6. These 3 are registered with IANA in Section 9.6.
These schemes MUST be implemented according to this document. These schemes MUST be implemented according to this document.
absoluteURI is not mandatory to implement.
absoluteURI is not mandatory-to-implement.
Dereferencing a Target's location using SIP- or SIPS-URI is Dereferencing a Target's location using SIP- or SIPS-URI is
accomplished by treating the URI as a PRES-URI and generating a accomplished by treating the URI as a PRES-URI and generating a
SUBSCRIBE request to a presence server as defined in [RFC3856] SUBSCRIBE request to a presence server as defined in [RFC3856]
using the 'presence' event package. The resulting NOTIFY will using the 'presence' event package. The resulting NOTIFY MUST
contain the PIDF, rather MUST contain a PIDF-LO. See Figure 4. for a contain a PIDF-LO. See Figure 4 for a basic message flow for a
basic message flow for a dereference. The NOTIFY contains Alice's dereference. The NOTIFY contains Alice's PIDF-LO in Figure 4.
PIDF-LO in Figure 4.
When used in this manner, SIP is a Using Protocol as defined in When used in this manner, SIP is a Using Protocol as defined in
[RFC3693] and elements receiving location MUST honor the [RFC3693] and elements receiving location MUST honor the
'usage-element' rules as defined in this extension. 'usage-element' rules as defined in this specification.
Alice Location Server Bob Alice Location Server Bob
| | | |
| INVITE w/ LbyR URI | | INVITE w/ Location URI |
|-------------------------------------------------------->| |-------------------------------------------------------->|
| | | | | |
| 200 (OK) | | 200 (OK) |
|<--------------------------------------------------------| |<--------------------------------------------------------|
| | | | | |
| | SUBSCRIBE to LbyR URI | | | SUBSCRIBE to location URI |
| |<-----------------------------| | |<-----------------------------|
| | 200 (OK) | | | 200 (OK) |
| |----------------------------->| | |----------------------------->|
| | | | | |
| | NOTIFY w/ PIDF-LO | | | NOTIFY w/ PIDF-LO |
| |----------------------------->| | |----------------------------->|
| | 200 (OK) | | | 200 (OK) |
| |<-----------------------------| | |<-----------------------------|
| | | | | |
Figure 4. Location-by-Reference and Dereferencing Figure 4. Location-by-Reference and Dereferencing
In Figure 4., Alice sends Bob her location in an LbyR URI. Bob In Figure 4, Alice sends Bob her location in a location URI. Bob
receives this LbyR URI in the INVITE and generates a new transaction receives this location URI in the INVITE and generates a new
(SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO. If accepted,
PIDF-LO will be in the NOTIFY request from the Location Server back the PIDF-LO will be returned in the NOTIFY request from the Location
to Bob's UA. This is the first instance between Alice and Bob that Server to Bob's UA. This is the first instance between Alice and
Alice's location is in any message, therefore it is sent only once, Bob that Alice's location is in any message, therefore it is sent
from the Location Server to Bob. only once, from the Location Server to Bob.
The SUBSCRIBE contains a geolocation option tag in either the The SUBSCRIBE contains a geolocation option tag in either the
Supported or Require header (depending on what strength of support Supported or Require header field (depending on what strength of
the UAC wants to apply). The NOTIFY MUST match the subscribing support the UAC requires). The NOTIFY MUST match the subscribing
UAC's option-tag strength for geolocation. UAC's option-tag strength for geolocation.
A dereference of an LbyR URI using SUBSCRIBE is not violating a A dereference of an LbyR URI using SUBSCRIBE is not violating a
PIDF-LO 'retransmission-allowed' element value set to 'no', as the PIDF-LO 'retransmission-allowed' element value set to 'no', as the
NOTIFY is the only message in this multi-message set of transactions NOTIFY is the only message in this multi-message set of transactions
that contains the Target's location, with the location recipient that contains the Target's location, with the location recipient
being the only SIP element to receive this PIDF-LO. This is the 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 purpose of this extension to SIP - to convey location to a specific
destination. destination.
5. Geolocation Examples 5. Geolocation Examples
This section contains are two examples of messages providing This section contains are two examples of messages providing
location. One shows LbyV with coordinates, the other shows LbyR. location. One shows LbyV with coordinates, the other shows
The example for (Coordinate format) is taken from [RFC3825]. A dereferencable location URI. The example for (Coordinate format) is
civic format example of the same position on the earth as is in the taken from [RFC3825]. A Civic-format example of the same position on
coordinate format example is in appendix B, which is taken from the earth as is in the coordinate format example is in appendix B,
[RFC4776]. The differences between the two formats are within the which is taken from [RFC4776]. The differences between the two
<gp:location-info> of the examples. Other than this portion of each formats appear within the <gp:location-info> in the examples. Other
PIDF-LO, the rest is the same for both location formats. 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, which The key to the provided samples is in the Geolocation header field,
has a different type of URI, based on the different means of which has a different type of URI, based on the different means of
location conveyance. Section 5.1 shows a "cid:" URI, indicating location conveyance. Section 5.1 shows a "cid:" URI, indicating
this SIP request contains an LbyV message body - which is in the this SIP request contains an LbyV message body - which is in the
form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating
location is to be acquired via an indirection dereference mechanism, location is to be acquired via an indirection dereference mechanism,
which is determined by the scheme of URI supplied. which is determined by the scheme of URI supplied.
5.1 Location-by-value (Coordinate Format) 5.1 Location-by-value (Coordinate Format)
This example shows an INVITE message with a coordinate, or This example shows an INVITE message with a coordinate location. In
coordinate location. In this example, the SIP request uses a this example, the SIP request uses a sips-URI [RFC3261], meaning
sips-URI [RFC3261], meaning this message is TLS protected on a this message is protected using TLS on a hop-by-hop basis.
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" ;inserted-by="alice@atlanta.example.com"
;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 22, line 10 skipping to change at page 23, line 14
--boundary1 --boundary1
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">
<dm:device id="target123"> <tuple id="target123">
<timestamp>2007-12-02T14:00:00Z</timestamp>
<status> <status>
<timestamp>2009-07-13T09:00:00Z</timestamp>
<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>33.001111 -96.68142</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>2007-12-07T18:00:00Z</gp:retention- <gp:retention-expiry>2009-07-29T18:00:00Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>DHCP</gp:method> <gp:method>802.11</gp:method>
<gp:provided-by>www.example.com</gp:provided-by> a </gp:geopriv>
</gp:geopriv>
</status> </status>
</dm:device> </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, with SDP being the
other message body part. The "cid:" eases parsing of message other message body part. The "cid:" eases message body parsing.
bodies.
If the Geolocation header field were this instead: If the Geolocation header field did not contain a "cid:" scheme, for
example, like this location URI:
Geolocation: <sips:server5.atlanta.example.com/target123> Geolocation: <sips:server5.atlanta.example.com/target123>
...the presence of something other than "cid:" indicates an LbyR is ... the existence of a non-"cid:" scheme indicates this is a
included in this message. It is expected that any node wanting to location URI, to be dereferenced to learn the target's location. Any
know where user "target123" is would subscribe to server5 to node wanting to know where user "target123" is would subscribe to
dereference the sips-URI (see Figure 4 for this message flow, and server5 to dereference the sips-URI (see Figure 4 for this message
Section 5.2 for this decoded example). The returning NOTIFY would flow, and Section 5.2 for this decoded example). The returning
contain Alice's location in a PIDF-LO, as if it were included in a NOTIFY would contain Alice's location in a PIDF-LO, as if it were
message body (part) of the original INVITE here. included in a message body (part) of the original INVITE.
5.2 Location-by-reference 5.2 Location-by-reference
Below is an INVITE request with an LbyR URI instead of an LbyV Below is an INVITE request with a location URI that is not a "cid:"
PIDF-LO message body part shown in Section 5.1. It is up to the - instead of an LbyV PIDF-LO message body part as shown in Section
location recipient to dereference Alice's location at the Atlanta 5.1. The Location Recipient will dereference Alice's location at
LIS server containing the location record. Dereferencing, if done the Atlanta Location Server the location URI is pointing towards.
with SIP, is accomplished by the Location Recipient sending a Dereferencing, if done using SIP, is accomplished by the Location
SUBSCRIBE request to the URI reference for Alice's location. The Recipient sending a SUBSCRIBE request to the URI reference for
received NOTIFY is the first SIP request containing Alice's UA Alice's location. The received NOTIFY is the first SIP request
location, as a PIDF-LO message body (see Figure 4 for this message containing Alice's UA location, as a PIDF-LO message body (see
flow example). The NOTIFY, in this case, is the SIP request that is Figure 4 for this message flow example). The NOTIFY, in this case,
conveying location, and not the INVITE. There is no retransmission and not the INVITE, is the SIP request that is conveying location.
of location in this usage. 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: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;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: <sips:3sdefrhy2jj7@lis.atlanta.example.com> Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
;inserted-by="bigbox3.atlanta.example.com" ;inserted-by="bigbox3.atlanta.example.com"
;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@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
(...SDP goes here as the only message body) (...SDP goes here as the only message body)
A Location Recipient would need to dereference the sips-URI in the A Location Recipient would need to dereference the sips-URI in the
Geolocation header field to retrieve Alice's location. If the Geolocation header field to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location conveyance atlanta.example.com domain chooses to implement location conveyance
and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that and delivery in this fashion, it is RECOMMENDED that entities
entities outside this domain be able to reach the dereference outside this domain be able to reach the dereference server, unless
server, otherwise this model of implementation is only viable within location is intentionally restricted within the atlanta.example.com
the atlanta.example.com domain. domain.
6. SIP Element Behavior 6. SIP Element Behavior
Because a device's location is generally considered to be sensitive Because a device's location is generally considered to be sensitive
in nature, location information needs to be protected when in nature, location information needs to be protected when
transmitted. This can be addressed through securing the location transmitted. This can be addressed through securing the location
information to prevent either viewing or changing the PIDF-LO. information to prevent either viewing or changing the PIDF-LO.
Section 26 of [RFC3261] defines the security functionality SIPS by Section 26 of [RFC3261] defines the SIPS security functionality by
transporting SIP messages with either TLS or IPSec protection transporting SIP messages with either TLS protection between SIP
between SIP entities. entities.
If a SIP entity wants to prevent all SIP entities in a request path If a SIP entity wants to prevent all SIP entities in a request path
from viewing or just changing the contents of the PIDF-LO, save that do not possess a decryption key from viewing or changing the
those that possess decryption key, the message body needs to be contents of the PIDF-LO, the message body needs to be secure by a
secure by a means such as S/MIME. This would be the case in which a means such as S/MIME.
UAC wants to make sure only the destination UAS can read the
PIDF-LO.
6.1 UAC Behavior 6.1 UAC Behavior
A UAC can send location in a SIP request, either because it is A UAC might choose to send location in a SIP request to facilitate
expected to facilitate location-based routing of the request, or location-based routing of the request, or for some other purpose.
spontaneously (i.e., for a purpose not defined in this document but Alice communicating her location to Bob in a SIP request is a simple
known to the UAC). Alice communicating her location to Bob in a SIP example of this. If Alice wanted to include her location as a
request is a simple example of this. If Alice wanted to include her message body in an INVITE that also has an SDP message body, the
location as a message body in an INVITE that also has an SDP message Content-Type: Multipart MUST be supported by both UAC and UAS.
body, the Content-Type: Multipart MUST be supported by both UAC and Multipart comes in many forms (/mixed, /alternative, etc), and this
UAS. Multipart comes in many forms (/mixed, /alternative, etc), and document does not limit which type of multipart is used, though
this document does not limit which type of multipart is used, though future documents might specify or limit multipart to a subset of
future documents MAY specify or limit multipart to a subset of all all the choices for a given use.
the choices for a given use.
A UAC conveying location MUST include a locationValue in a A UAC conveying location MUST include a locationValue in a
Geolocation header (see section 4.1) with either an LbyV indication Geolocation header (see section 4.1) with either an LbyV indication
(a cid-URL), or an LbyR. An LbyV message body sent without a (a cid-URL), or a dereferencable location URI. Requests containing
Geolocation header field MUST NOT occur. The UAC supporting this an LbyV message body sent MUST also contain a Geolocation header
extension MUST include a Supported header with the 'geolocation' field. The UAC supporting this extension MUST include a Supported
option tag. header with the 'geolocation' option tag.
More than one location format (civic and coordinate) can be included More than one location format (civic and coordinate) can be included
in the same message body part, but all location parts of the same 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 PIDF-LO MUST point at the same position on the earth, identifying
the same target. The same location in multiple formats, for the same target. The same location in multiple formats, for
example, a partial or complete geodetic and a partial or complete example, a partial or complete geodetic and a partial or complete
civic, can allow the recipient to use the most convenient or civic, allows the recipient to select the most preferred format for
preferable format for its use. 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 Multiple PIDF-LOs are allowed in the same request, with each allowed
to point at separate positions - however, each PIDF-LO MUST identify to point at separate positions - however, each PIDF-LO MUST identify
a different Target. Therefore, there will be no confusion by a a different Target (i.e., in the entity= attribute in the <presence>
Location Recipient receiving more than one PIDF-LO (in a message element of the presence document). Therefore, there will be no
body or when dereferenced, or a combination). It is RECOMMENDED confusion by a Location Recipient receiving more than one PIDF-LO
there is only one locationValue in a single SIP request for the same (in a message body or when dereferenced, or a combination). A SIP
Target. More than one will likely lead to confusion by a Location 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 because this extension does not provide guidance on what a
recipient is to do with more than one location, nor does it give any recipient is to do with more than one location for the same target
preference regarding which location is better or worse than another (which could point to different positions), nor does it give any
location in the same request. preference regarding which location is more or less reliable than
another location in the same request.
The 'geolocation' option tag is inserted in a Supported header by a The presence of the 'geolocation' option tag in a Supported header
UAC to provide an indication of support for this extension. The field without a Geolocation header field in the same message informs
presence of the 'geolocation' option tag in a Supported header a SIP element receiving this request that the UAC understands this
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 extension, but it does not know or wish to convey its location at
this time. Certain scenarios exist (location-based retargeting) in this time. Certain scenarios exist (location-based retargeting) in
which location is required in a SIP request in order to retarget the which location is required in a SIP request in order to retarget the
message properly. This affects how a UAS or SIP server processes message properly. Indicating support with a geolocation option tag
such a request. 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 The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require
Header, because the UAC often will not know the underlying topology header field, because often the UAC will not know the underlying
to know which proxy will do the retargeting, thus increasing the topology to know which proxy will do the retargeting, thus
likelihood of a request failure by the first hop proxy that does not increasing the likelihood of a request failure at the first hop
understand this extension, but is required to by inclusion of the proxy that does not understand this extension, as is required by
option tag in this header. inclusion of the option tag in this header field.
A UAC inserting a locationValue MUST include an "inserted-by=" A UAC inserting a locationValue MUST include an "inserted-by="
parameter to indicate its hostport. This is copied to the parameter to indicate its hostport. This is copied to the
"inserter=" parameter of the Geolocation-Error header in a response "inserter=" parameter of the Geolocation-Error header field in a
if a Location Recipient determines there is something wrong with the response if a Location Recipient determines there is something wrong
locationValue in this request. Because more than one locationValue with the locationValue in this request. Because more than one
can be inserted along the path of the request, this indication is locationValue can be inserted along the path of the request, this
necessary to show which locationValue had the problem in the indication is necessary to show which locationValue had the problem
response, and who the locationErrorValue is for. For example: in the response, and who the locationErrorValue is for. For
example:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice@atlanta.example.com" inserted-by="alice@atlanta.example.com"
If a UAC does not learn and store its location locally (a GPS chip) 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 LbyR or from the network (DHCP or LLDP-MED), the UAC MAY learn its
URI (from DHCP for example). If the latter is the case, the UAC can location URI (from DHCP for example). If the latter is the case,
SUBSCRIBE to this LbyR URI, using the 'presence' event package, to the UAC can SUBSCRIBE to this location URI, using the 'presence'
get and store its own location. event package, to get and store its own location.
The act of dereferencing a Target's LbyR will be challenged by the The Location Server will likely challenge requests to dereference a
LIS where this location record is - providing a good deal of Target's location URI. The location URI SHOULD be treated as
protection, SHOULD still be treated as equivalent to possession of equivalent to possession of the location information itself and thus
the location information itself and thus TLS SHOULD be used when TLS SHOULD be used when transmitting any location URI hop-by-hop
transmitting LbyR hop-by-hop along the path to the Location along the path to the Location Recipient, for protection reasons.
Recipient, for protection reasons. This is not to be confused with This is not to be confused with a 'possession model', in which
a possession model, in which possessing the LbyR grants possessing the location URI grants authorization to dereference the
authorization to dereference the URI. Any entity dereferencing the URI. Any entity dereferencing the location URI MUST pass whatever
LbyR MUST pass whatever authentication and authorization rules are authentication and authorization rules are on the LS to acquire this
on the LIS for this location record. The Ruleholder from [RFC3693] location. The Ruleholder from [RFC3693] is still very much in
is still very much in control - for any entity possessing the LbyR. control - for any entity possessing the LbyR.
If the Location Generator wishes to control whether any location If the Location Generator wishes to control whether any location
included in the SIP request or added along the signaling path of included in the SIP request or added along the signaling path of
this request can be viewed for routing decisions, the Location this request can be viewed for routing decisions, the Location
Generator adds a Geolocation header value including the Generator adds a Geolocation header field value including the
"routing-allowed=no" parameter. This header parameter provides "routing-allowed=no" parameter. This header field parameter
specific policy rules for each locationValue (if there is more than provides specific policy rules for each locationValue (if more than
one inserted along the signaling path) within the SIP request. A one locationValue is inserted along the signaling path) within the
UAC SHOULD include the "routing-allowed" header parameter, with or SIP request. A UAC SHOULD include the "routing-allowed" header
without a locationValue, to each SIP request supporting this field parameter, with or without a locationValue, to each SIP
specification to ensure the UAC's policy for intermediaries which request supporting this specification to ensure the UAC's policy for
might add a locationValue of the Target downstream. The UAC intermediaries which might add a locationValue of the Target
understands that the default behavior for SIP servers is to consider downstream. The default behavior for SIP servers is to consider
this value to be present, and that it is set to "no". this value to be present, with a value of "no".
The UAC MUST understand 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 There is no feedback mechanism to inform the Target if a SIP server
transaction, and wants to update its location information (for has included a locationValue downstream. If a UAC has already
whatever reason) after the original request is sent, or after a conveyed location in the original request of a transaction, and
dialog is created (regardless of how the UAC conveyed location wants to update its location information (for whatever reason) after
previously, as an LbyV or LbyR) - this is done by a UAC sending an the original request is sent, or after a dialog is created, this is
UPDATE request [RFC3311] containing the geolocation option tag and done by sending an UPDATE request [RFC3311]. The UPDATE will include
Geolocation header with the new locationValue (LbyV or LbyR) to the a geolocation option tag and Geolocation header field with the new
original destination UAS. locationValue to the original destination UAS.
A PIDF includes identity information. It is possible for the A presence document includes identity information (in the "entity="
identity in the PIDF to be anonymous. Implementations of this 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 extension SHOULD consider the appropriateness of including an
anonymous identity in the location information where a real identity unlinkable pseudonym as the identity in the location information
is not required. When using LbyR, the LbyR MUST NOT contain any where a real identity is not required. See the concerns raised in
user identifying information. For example, use something section 4.3.2 about unlinkable pseudonyms in relation to their
unidentifiable like potential problems with requests that need to route based on the
location contained in the message.
3fg5t5yqw@example.atlanta.com When using LbyR, the location URI MUST NOT contain any user
identifying information. For example, use something unidentifiable
like
3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com
rather than rather than
aliceishere@example.atlanta.com). aliceishere@example.atlanta.com).
Use of self-signed certificates is inappropriate for use in Use of self-signed certificates is inappropriate for use in
protecting a PIDF, as the sender does not have a secure identity of protecting a PIDF, as the sender does not have a secure identity of
the recipient. the recipient.
Mentioned in more detail in later in section 6.2, SIP MUST NOT Although this is discussed in more detail in later in section 6.2,
attempt to overcome rules and behaviors conveyed in a PIDF-LO. SIP entities MUST NOT bypass rules and behaviors conveyed in a
Therefore, UACs SHOULD take care when setting their PIDF-LO. UACs SHOULD take care when setting their
<retransmission-allowed> flag to "yes", as when Alice tells Bob her <retransmission-allowed> flag to "yes". When Alice tells Bob her
location with this flag set to "yes", as long as the location with this flag set to "yes", Bob is free to tell Carol
<retention-expiry> time is not indicating the location information where Alice is (as long as the <retention-expiry> time has not
needs to be deleted - Bob is free to tell Carol where Alice is. elapsed, indicating that the location information should be
This is an implicit byproduct of how the PIDF-LO rule-set is, as of deleted). This is an implicit byproduct of the PIDF-LO rule-set, as
this writing. This is a configuration issue, but something worth of this writing. This decision is a configuration issue, but is
mentioning here. worth mentioning here.
6.1.1 UAC Receiving a Location Failure Indication 6.1.1 UAC Receiving a Location Failure Indication
Location Recipients can be either, or both, destination UASs and Location Recipients that use the location information for
intermediate servers that use the location information for location-based routing decisions can be either destination UASs or
location-based routing decisions. If a sent request fails based on intermediate servers. If a request fails based on the location
the location information in the request, a 424 (Bad Location information in the request, a 424 (Bad Location Information)
Information) response is sent back to the UAC. The 424 MUST have a response is sent back to the UAC. The 424 MUST have a
Geolocation-Error header containing one or more locationErrorValues Geolocation-Error header field containing one or more
in the response message. A locationErrorValue has a header locationErrorValues in the response message. A locationErrorValue
parameter indicating which entity inserted the locationValue has a header field parameter indicating which entity inserted the
correlated to this error, called the "inserter=" parameter. This locationValue correlated to this error, called the "inserter="
"inserter=" parameter (in the locationErrorValue) is copied from the parameter. This "inserter=" parameter (in the locationErrorValue)
"inserted-by=" parameter (from the locationValue) by the Location is copied from the "inserted-by=" parameter (from the locationValue)
Recipient (UAS or proxy) sending the error response. A UAC by the Location Recipient (UAS or proxy) sending the error response.
receiving a Geolocation-Error in any response type MUST review the A UAC receiving a Geolocation-Error in any response type MUST check
"inserter=" parameter in the locationErrorValue to see if it whether the "inserter=" parameter in the locationErrorValue
indicates this UAC. If locationErrorValue does not match, the indicates this UAC.
locationErrorValue MUST be ignored. If a locationErrorValue is in a
424, and the "inserter=" entity is not this UAC, the response SHOULD
be treated as a 400 response. If locationErrorValue does indicate
this UAC, this UAC MUST process the response, including the
Geolocation-Error code (defined in section 4.3). Further, UAC MUST
ignore a Geolocation-Error header value, even for this UAC, even in
a 424 response if the UAC did not include a Geolocation header value
(with locationValue) in the request part of the transaction.
A UAC MAY reattempt a new request if it believes it can correct the o If locationErrorValue does not match, the locationErrorValue
stated failure in the Geolocation-Error header, unless the location MUST be ignored.
error is a 5XX level error - which clearly states in Section 4.3 not
to do this. A UAC MUST follow all the guidance that pertains to
UACs from Section 4.3 (Geolocation-Error header), heeding what to do
in case it receives any of the error codes articulated in that
section.
Any UAC that inserted location into a request SHOULD be prepared to o If a locationErrorValue is in a 424, and the "inserter=" entity
receive the Geolocation-Error header in any response, looking to is not this UAC, the response SHOULD be treated as a 400
determine if a locationErrorValue is meant for the UAC, and to react response.
accordingly.
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 If a UAC includes location in a request, and either the UAS does not
determine errored location was critical to the transaction and determine errored location was critical to the transaction and
accept the request, or the request failed for reason other than accept the request, or the request failed for reason other than
location, any response MAY contain a Geolocation-Error header location, any response MAY contain a Geolocation-Error header field
containing a locationErrorValue with the details of the location containing a locationErrorValue with the details of the location
error. error.
6.2 UAS Behavior 6.2 UAS Behavior
If the Geolocation header field is present in a received SIP If the Geolocation header field is present in a received SIP
request, the type of URI contained in the locationValue will request, the type of URI contained in the locationValue will
indicate if location is an LbyV in a message body (part) or LbyR, indicate if location is in a message body (part) or requires an
requiring an additional dereference transaction. If the LbyR URI is additional dereference transaction. If the location URI is sip:,
sip:, sips: or pres:, and the UAS wants to learn the UAC's location, sips: or pres:, and the UAS wants to learn the UAC's location, the
the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve UAS MUST SUBSCRIBE to the provided URI to retrieve the PIDF-LO being
the PIDF-LO being conveyed by the UAC as defined in [RFC3856]. If conveyed by the UAC as defined in [RFC3856]. If successful, the
successful, the PIDF-LO will be returned in the NOTIFY request from Target's PIDF-LO will be returned in the NOTIFY request from the
the remote host. The UAS is not REQUIRED to dereference the LbyR if remote host. The UAS is not REQUIRED to dereference the location
it does not want to (by configuration or user choice). It is URI if location is not needed to process the request. It is
RECOMMENDED the UAS render the location sent to it, however it is RECOMMENDED the UAS display the location to the user, or otherwise
configured to do so. render the location appropriately.
A Require header with the 'geolocation' option tag indicates the A Require header field with the 'geolocation' option tag indicates
UAC is requiring the UAS understand this extension or else send the UAC requires that the UAS understand this extension, sending an
an error response. A 420 (Bad Extension) with a 'geolocation' error response if it does not. A 420 (Bad Extension) with a
option tag in an Unsupported header would be the appropriate 'geolocation' option tag in an Unsupported header field would be the
response in this case. appropriate response in this case.
It is possible, but undesirable, for a message to arrive with a body It is possible, but undesirable, for a message to arrive with a body
containing an LbyV, but with no Geolocation header field value containing an LbyV, but with no Geolocation header field value
pointing to it (potentially no Geolocation header field at all). In pointing to it (potentially no Geolocation header field at all). In
this case, the recipient MAY still read and use the message body. this case, the recipient MAY still read and use the message body.
Unless stated otherwise by future standards-track publication(s), a Unless stated otherwise by future standards-track publication(s), a
LbyR URI only has meaning within the Geolocation header field and location URI only has meaning within the Geolocation header field
MUST NOT appear in any other SIP header field. and MUST NOT appear in any other SIP header field.
There are 3 Geolocation header parameters, There are 3 Geolocation header field parameters,
o "inserted-by=" o "inserted-by="
o "used-for-routing" o "used-for-routing"
o "routing-allowed" o "routing-allowed"
The "inserted-by=" parameter informs a Location Recipient which SIP The "inserted-by=" parameter informs a Location Recipient which SIP
element added this locationValue to the SIP request. This parameter entity added this locationValue to the SIP request. This parameter
is mandatory for each locationValue in the request. The value in is mandatory for each locationValue in the request. The value in
the "inserted-by=" parameter is copied into the "inserter=" the "inserted-by=" parameter is copied into the "inserter="
parameter in each locationErrorValue if there is an error in the parameter in each locationErrorValue if there is an error in the
location to be reported back to the location sender. See section location to be reported back to the location sender. See section
6.2.1. 6.2.1.
The "used-for-routing" parameter is included in the locationValue if The "used-for-routing" parameter is included in the locationValue if
a SIP server used the location in the request to determine how to a SIP server used the location in the request to determine how to
route or forward the message towards the ultimate destination. If route or forward the message towards the ultimate destination. If
there are more than one locationValues in the Geolocation header, there are more than one locationValues in the Geolocation header
and it is possible that different locationValues were used to route field, it is possible that different locationValues were used to
the message at different times of this request's journey. This is route the message at different points along the path traversed by
allowed, as it is consistent with the rule that anytime a message is the request. This is allowed, as it is consistent with the rule
routed based upon a locationValue, a "used-for-routing" parameter is that whenever a message is routed based upon a locationValue, a
added to the applicable locationValue. This parameter should be "used-for-routing" parameter is added to the applicable
present in each locationValue used along the path. A locationValue. This parameter MUST be present in each locationValue
"used-for-routing" parameter MUST NOT ever be removed from a used along the path. A "used-for-routing" parameter MUST NOT be
locationValue in a request. removed from a locationValue in a request.
The "routing-allowed" parameter is exclusively for SIP servers, and The "routing-allowed" parameter is exclusively for SIP servers, and
will be discussed in section 6.3. will be discussed in section 6.3.
Additional locationValues inserted into a request SHOULD be placed Additional locationValues inserted into a request MUST be placed
the order they were generated, and not rearranged. This informs a the order they were generated, and not rearranged. This informs a
Location Recipient which was the last locationValue in the message Location Recipient which was the last locationValue in the message
that was used to route the message. This is for troubleshooting and that was used to route the message. This is for troubleshooting and
management reasons. management reasons.
Individual header parameters in any received locationValue MUST NOT Individual header field parameters in any received locationValue
be modified or deleted in transit to the ultimate destination. 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 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 any number of issues/problems with receiving location, and the UAC
or proxy servers cannot error a response. Therefore, the UAS, if it or proxy server(s) cannot reply to a response with an error
wants to send a UAC its location, SHOULD do so in a new request in a response. If the UAS wants to send its location to a UAC, it can do
separate transaction. This document gives no guidance which SIP so in a new request within a separate transaction. This document
request to use, but SIP MESSAGE is a viable choice. 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 A UAS MAY include a 'geolocation' option tag in the Supported header
of a response, indicating it does understand this extension, even if field of a response, indicating it does understand this extension,
location was not in a request to the UAS. even if location was not included in a request to the UAS.
A UAS wishing to dereference an LbyR URI contained in a received A UAS wishing to dereference an location URI contained in a received
request will use the 'presence' event package in a SUBSCRIBE request request will use the 'presence' event package in a SUBSCRIBE request
to the URI. If accepted, the PIDF-LO will return to the UAS in a to the URI. If accepted, the LS will return the PIDF-LO to the UAS
NOTIFY request. If there are any errors during dereferencing, or in in a NOTIFY request. If there are any errors during dereferencing,
the PIDF-LO itself, the UAS will error the original request to the or in the PIDF-LO itself, the UAS will respond to the original
UAC with a locationErrorValue indicating what the UAS concluded was request with a locationErrorValue indicating what the UAS concluded
wrong with the location. This is to include any dereferencing was wrong with the location. This is to include any dereferencing
problems encountered. problems encountered.
Section 4.5 of this document called for the IANA registration of 3 Dereferencing for sip:, sips: and pres: URI schemes are
URI schemes (sip:, sips:, and pres:) that are mandatory to implement mandatory-to-implement.
for dereferencing.
A UAS MUST be prepared to receive subsequent location updates from A UAS MUST be prepared to receive subsequent location updates from
the UAC, either LbyV or LbyR (regardless of how the UAS received the UAC, either LbyV or LbyR (regardless of how the UAS received
location previously from this UAC). The UAC will convey location location previously from this UAC). The UAC will convey updated
using the UPDATE [RFC3311] method to the UAS, and not a reINVITE. 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 LbyV and If there is more than one location (any combination of LbyV and
LbyR), this document does not give guidance what a Location LbyR), this document does not give guidance about what a Location
Recipient does with each location. There are no priority or Recipient does with each location. There are no priority or
more-trusted indications given by this document. All this is more-trusted indications specified by this document. All this is
considered application specific, and out-of-scope of this document. considered application-specific, and out-of-scope for this document.
This document makes it clear that if when there are more than one If more than one location is present in the PIDF-LO, location
location, each in the same PIDF-LO MUST be about the same Target elements in the same PIDF-LO MUST apply to the same Target
(identifier) and point at the same position on the earth. If there (identified in the "entity=" attribute) and point at the same
is more than one PIDF-LO with different Target identifiers, then position on the earth. If there is more than one PIDF-LO with
the UAC is merely telling the UAS where more than one Target is, and different Target identifiers, then the UAC is merely telling the UAS
there should not be any conflict. where more than one Target is, and there should not be any conflict.
Within any PIDF-LO, there is a <retransmission-allowed> element that Within any PIDF-LO, there is a <retransmission-allowed> policy
can be set to "yes" or "no". These are the only possibilities. If element that can be set to "yes" or "no". These are the only
Alice conveys her location to Bob (as has been described throughout possibilities. If Alice conveys her location to Bob (as has been
this document) with a <retransmission-allowed> element set to "no", described throughout this document) with a <retransmission-allowed>
then Bob MUST NOT inform any other element where Alice is. If the element set to "no", then Bob MUST NOT inform any other element
<retransmission-allowed> element is set to "yes", then Bob can where Alice is. If the <retransmission-allowed> element is set to
inform other elements where Alice is, but only until the "yes", then Bob can inform other elements where Alice is, but only
<retention-expiry> element, also in the PIDF-LO, allows Bob to as long as the <retention-expiry> policy element, also in the
[RFC4119]. As a byproduct of this, that means that if Alice conveys PIDF-LO, allows [RFC4119]. As a byproduct of this, that means that
her location to Bob with a <retransmission-allowed> element set to if Alice conveys her location to Bob with a <retransmission-allowed>
"yes", and the <retention-expiry> time is not requiring Bob to element set to "yes", and the <retention-expiry> time does not
delete Alice's location yet, then Bob is free to tell anyone else require Bob to delete Alice's location yet, then Bob is free to tell
where Alice is. Whenever Bob conveys Alice's location, anyone else where Alice is. The entity= attribute in the <presence>
<retention-expiry> timer MUST be maintained as is (i.e., not element identifies who is the target of each location, preventing
changed). The <dm:device id> element identifies that Alice is the confusion. Whenever Bob conveys Alice's location,
target of this location. RFC 4119 implicitly allows this behavior, <retention-expiry> timer MUST be maintained as is (i.e., not changed
thus SIP is not going to change this behavior from occurring. 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 6.2.1 UAS Generating a Location Failure Indication
If a UAS receives location in a request, but determines there is a If a UAS receives location in a request, but determines there is a
problem with the location in the request, it is the responsibility problem with the location in the request, it is the responsibility
of the UAS to inform whomever inserted location into that request of the UAS to inform the entity that inserted the problematic
there was a problem experienced. The Geolocation header in the location into that request. The Geolocation header field in the
request has a locationValue, providing the UAS a URI indicating request has a locationValue, providing the UAS a location URI
where the Target's location is. The Location Target identified in indicating where the Target's location is. The Location Target
the PIDF-LO may or may not be the location inserter, or the identified in the PIDF-LO may or may not be the location inserter,
generator of the request (the UAC or SIP server). Ultimately, or the generator of the request. Ultimately, location is in a
location is in a PIDF-LO. This is either in the request as a PIDF-LO. This is either in the request as a message body (LbyV), or
message body (LbyV), or it has to be dereferenced from the LbyR in obtained by initiating a dereference transaction on a Location
the locationValue in the request. LbyR records are typically kept Server identified in the location URI. Location Servers typically
on a LIS, which can challenge all dereference requests. All challenge all dereference requests. All PIDF-LOs have a Location
PIDF-LOs have a Location Target identifier. This is who the Target identifier. The "inserted-by=" parameter of the
location is about. The "inserted-by=" parameter of the locationValue tells the UAS which SIP entity inserted that
locationValue tells the UAS who inserted that locationValue. This locationValue. This "inserted-by=" parameter is copied into the
"inserted-by=" parameter is copied into the "inserter=" parameter of "inserter=" parameter of the locationErrorValue generated by the
the locationErrorValue generated by the Location Recipient (the Location Recipient (the UAS), in a response, when it wants to inform
UAS), in a response, when it wants to inform the location the location "inserter=" entity there was a problem with the
"inserter=" entity there was a problem with the location it location it received.
received.
There can be more than one locationValues in a request. The There can be more than one locationValue in a request. The
"inserter=" parameter in the locationErrorValue will distinguish it "inserter=" parameter in the locationErrorValue will prevent
from being misunderstood by entities that did not insert the errored entities that did not insert the errored location from
location. misunderstanding whether the locationErrorValue applies to them.
If there is one valid locationValue in a request, even if all the If there is one valid locationValue in a request, even if all the
others have errors with them, a 424 (Bad Location Information) others have errors with them, the Location Recipient MUST NOT send a
response MUST NOT be sent. The Location Recipient (the UAS) is 424 (Bad Location Information) response. The Location Recipient
RECOMMENDED to send a locationErrorValue for each errored (the UAS) MUST send a locationErrorValue for each errored
locationValue, with unique "inserter=" parameters to make sure the locationValue, with unique "inserter=" parameters to make sure the
right entities know which locations were in error. right entities know which locations were in error.
As hinted at, a location "inserter=" can be a UAC or it can be an As hinted at, a location "inserter=" can be a UAC or it can be an
in-signaling-path SIP server, who is acting as a UAC locator. This in-signaling-path SIP server acting as a UAC locator. This
means the SIP server is including its version of where it thinks the 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 UAC is, geographically. This "inserter=" has to be in the form of
an LbyR URI in a locationValue, because SIP servers are not allowed an dereferencable location URI in a locationValue, because SIP
to insert message bodies, as of the time of this publication, from servers are not allowed to insert message bodies.
all the way back to RFC3261.
Each locationErrorValue has an error code, letting the location Each locationErrorValue has an error code, letting the location
"inserter=" entity know what was wrong with the location supplied. "inserter=" entity know what was wrong with the location supplied by
See Section 4.3 for the 5 actionable responses a UAC can take from that entity. See Section 4.3 for the 5 actionable responses a UAC
a locationErrorValue. can take from a locationErrorValue.
If the location "inserted-by=" entity, meaning either the UAC or If the location "inserted-by=" entity, meaning either the UAC or
proxy in the message path, chose to indicate that location was so proxy in the message path chose to indicate that location was
important in the request to include a 'geolocation' option tag in a sufficiently important to include a 'geolocation' option tag in a
Require header, the response SHOULD be a 424 (Bad Location Require header field, any error response SHOULD be a 424 (Bad
Information) back to the "inserter=" entity (knowing the response Location Information) back to the "inserter=" entity (knowing the
will ultimately go to the UAC regardless) if there needs to be a response will ultimately go to the UAC regardless) if there needs to
locationErrorValue sent because the location was bad. Only entities be a good locationValue sent to properly process the request. Only
identified in a locationErrorValue as the "inserter=" entity will entities identified in a locationErrorValue as the "inserter="
pay attention to this locationErrorValue. All other entities MUST entity will pay attention to this locationErrorValue. All other
ignore any locationErrorValue not directed towards them. See entities MUST ignore any locationErrorValue not directed towards
section 4.3 for more information on this, including all the location them. See section 4.3 for more information on this, including all
specific errors and Geolocation-Error header parameters. the location-specific errors and Geolocation-Error header field
parameters.
In the above scenario ('geolocation' option tag in a Require In the above scenario ('geolocation' option tag in a Require
header), the only other response can be a 420, but only if the UAS header field), the only other response can be a 420, if the UAS
does not support this Geolocation extension to SIP, else the 424 is does not support this Geolocation extension to SIP.
sent.
If the location "inserted-by=" entity placed the 'geolocation' If the "inserted-by=" location entity placed the 'geolocation'
option tag in a Supported header, the response can be a 424 if it option tag in a Supported header field, the response can be a 424 if
chooses, but also can be any other SIP response, including a 200 it chooses, but also can be any other SIP response, including a 200
OK. A locationErrorValue in a Geolocation-Error header that is not OK. A locationErrorValue in a Geolocation-Error header field that
in a 424 (Bad Location Information) response is considered is not in a 424 (Bad Location Information) response is considered
informational by the Location Recipient, and not considered informational by the Location Recipient, and does not cause the
important enough to reject the request based solely on bad location Location Recipient to reject the request solely because of bad
information. location information.
For example, Alice INVITEs Bob to a dialog, and includes geolocation 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 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 add a locationErrorValue in the 200 OK indicating "yes, I accept
your request, and btw, something was wrong with the location you your request, and btw, something was wrong with the location you
provided (in the INVITE)". What was wrong with the location is provided in the INVITE". The specific problem with the location is
indicated by the Geolocation-Error code. Who this indicated by the Geolocation-Error code. The "inserter=" parameter
locationErrorValue is for is indicated by the "inserter=" parameter. identifies the Location Inserter this locationErrorValue is intended
for.
Each locationErrorValue is destined for one "inserter=" entity. Each locationErrorValue is destined for one "inserter=" entity.
This gives a Location Recipient one mechanism to tell each inserter This gives a Location Recipient a mechanism to tell each inserter
what the Location Recipient concluded was wrong with what the what the Location Recipient concluded was wrong with the location
"inserter=" included (as far as location is concerned). Therefore, the "inserter=" entity included. Therefore,
o there MUST be a locationErrorValue for each locationValue that o there MUST be a locationErrorValue for each locationValue that
was considered bad by the UAS to ensure each upstream location was considered bad by the UAS to ensure each upstream location
inserter understands which error code(s) is intended for them inserter understands which error code is intended for the
(and which to ignore). inserter (and which to ignore).
o there MUST NOT be more than one locationErrorValue in the o there MUST NOT be more than one locationErrorValue in the
response per locationValue in the request. response per locationValue in the request.
o there MUST NOT be more than one locationErrorValue to the same o there MUST NOT be more than one locationErrorValue with the same
"inserter=" in the request. "inserter=" entity in the request.
o there MUST NOT be a locationErrorValue in the response for a o there MUST NOT be a locationErrorValue in the response for a
locationValue in the request that was not in error, according to locationValue in the request that was not in error, according to
the Location Recipient. the Location Recipient.
Here is an example of a Geolocation-Error header Here is an example of a Geolocation-Error header field
Geolocation-Error: 400; code="Permission Necessary"; Geolocation-Error: 201; code="Linkable Target Identity Required";
node="server42.example2.com"; node="server42.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
The above example says that the Location Recipient is The above example says that the Location Recipient is
server42.example.com, and this entity believes it cannot route this server42.example.com, and this entity cannot verify the Target's
message without knowing the "inserter="'s location. This location identity within this message. This is typically needed in order to
may be in the request, or it may need to be in the request and was make routing decisions for the SIP request where the entity=
not. If location is encrypted, server42 doesn't know it is in the attribute has an unlinkable pseudonym obscuring a location target's
request. server42.example.com sends a 424 (Bad Location identity from the signaling. This is not desire because if Alice's
Information) response with a locationErrorValue indicating a 400 message is to be routed based on the location in the SIP request,
location error, which means it requires permission to view Alice's server42 has to verify that this is Alice's location. The
location to proceed with processing her signaling. Section 4.3 appropriate action is to send a 424 (Bad Location Information)
highlights this example, stating the user, Alice, MUST be made aware response with the above (201) Geolocation-Error header value. We do
of this location revelation request. This document does not give not want Alice's request routed based on Bob's location.
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 could be corrected if a future SIP request were to travel
through a different server than server42 (or it might not).
See Section 4.3 for further rules about the Geolocation-Error header See Section 4.3 for further rules about the Geolocation-Error header
and the locationErrorValue. field and the locationErrorValue.
This document says nothing about what a Location Recipient does with This document says nothing about what a Location Recipient does with
more than one 'good' locationValue in a request (i.e., which to more than one 'good' locationValue in a request (i.e., which to
choose to use). This scenario MAY be addressed in a future effort. choose to use). This scenario MAY be addressed in a future effort.
Further, more than one error code is allowed in the Further, more than one error code is allowed in the
locationErrorValue - each having one "inserter=" parameter. The locationErrorValue - each having one "inserter=" parameter.
error codes destined for the same inserter MUST NOT contradict the
meaning of the problem the Location Recipient had with a particular
locationValue.
6.3 Proxy Behavior 6.3 Proxy Behavior
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
However, proxies are permitted to add a header to a request. This However, proxies are permitted to add a header field to a request.
implies that a proxy can add a Geolocation locationValue with This means that a proxy can add a Geolocation locationValue header
LbyR URI, but not LbyV message body. field with a dereferencable location URI, but not a LbyV message
body.
It is allowed, but NOT RECOMMENDED, for more than one SIP element to It is allowed, but NOT RECOMMENDED, for more than one SIP element to
insert location into a request along its path. As described earlier insert location into a request along its path. As described earlier
in this document, each insertion of location into a SIP request is in this document, each insertion of location into a SIP request is
accompanied by a new locationValue in a Geolocation header. Also accompanied by a new locationValue in a Geolocation header field.
described earlier, each locationValue MUST contain an "inserted-by=" Also described earlier, each locationValue MUST contain an
value indicating to a Location Recipient which host inserted "inserted-by=" value indicating to a Location Recipient the host
location into a particular request. that inserted a specific location into a particular request.
However, if location is already in a SIP request, a SIP server If, however, location is already in a SIP request, a SIP server
SHOULD NOT add another LbyR that identifies the same target in the SHOULD NOT add another location URI that identifies the same target
PIDF-LO (in the <dm:device id> element) to the same request. This 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 will likely cause confusion at the Location Recipient as to which to
use. use.
A proxy is permitted to read any locationValue, and the associated
body, if not S/MIME protected, in transit if present, 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 parameter "routing-allowed" is present and
set to "no", or is not present (knowing the default behavior is "no"
if not present, with or without a Geolocation header), SIP servers
MUST NOT view the contents of the LbyV message body. Further, SIP
servers MUST NOT attempt to dereference an LbyR. This is because
the SIP request, likely from 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 in
section 6.3.2.
If the Geolocation header parameter "routing-allowed" is present in
a SIP request, the value MUST NOT be changed during processing of
the request. If the Geolocation header parameter "routing-allowed"
is not present, SIP servers are to treat the location within the
request as if the header parameter "routing-allowed" were present
and set to "no".
In the spirit of informing implementers of B2BUAs and SBCs, each
server type really should adhere to the above proxy guidance with
respect to the "Routing-allowed" header parameter, understanding
that there are no IETF police, and the specific behaviors of these
types of SIP servers cannot presently be defined. In other words, if
the particular type of SIP server mentioned here is not the ultimate
destination of this SIP request and supports this SIP extension,
each policy rule within the Geolocation header needs to remain
intact and unchanged.
No type of SIP server can delete a "Routing-allowed" header
parameter, but if one is not yet present, any SIP server MAY add a
"Routing-allowed" header parameter with the value set to "no" only.
More than one Geolocation locationValue in a message is permitted, More than one Geolocation locationValue in a message is permitted,
but can cause confusion at the recipient. If a proxy chooses to add but can cause confusion at the recipient. If a proxy chooses to add
a locationValue to a Geolocation header, which would be a local a locationValue to a Geolocation header field, which would be a
policy decision, the new locationValue MUST be added to the end of local policy decision, the new locationValue MUST be added to the
the header (after previous locationValue(s)). This is done to end of the header field (after previous locationValue(s)). This is
create an order of insertion of locationValues along the path. done to create an order of insertion of locationValues along the
Proxies MUST NOT modify the order of locationValues in a geolocation path. Proxies MUST NOT modify the order of locationValues in a
header. geolocation header field.
A proxy wishing to dereference an LbyR URI contained in a received A proxy wishing to dereference a location URI contained in a
request will use the 'presence' event package in a SUBSCRIBE request received request will use the 'presence' event package in a
to the URI. If accepted, the PIDF-LO will return to the proxy in a SUBSCRIBE request to the URI. If accepted, the LS will return the
NOTIFY request. If there are any errors during dereferencing, or in PIDF-LO to the proxy in a NOTIFY request. If there are any errors
the PIDF-LO itself, the proxy will error the original request to the during dereferencing, or in the PIDF-LO itself, the proxy will send
UAC with a locationErrorValue indicating what the proxy concluded an error to the UAC with a locationErrorValue indicating what the
was wrong with the location. This is to include any dereferencing proxy concluded was wrong with the location. This is to include any
problems encountered. dereferencing problems encountered.
6.3.1 Proxy Behavior with Geolocation Header Parameters 6.3.1 Proxy Behavior with Geolocation Header Field Parameters
SIP servers MUST NOT delete any existing Geolocation locationValue SIP servers MUST NOT delete any existing Geolocation locationValue
(URI or header parameter) from a request. An existing locationValue (URI or header field parameter) from a request. An existing
(URI or header parameter) MAY only be modified by adding a locationValue MAY be modified by adding a "used-for-routing"
"used-for-routing" parameter to an existing locationValue, if the parameter to an existing locationValue, if the request was
request was retargeted based on the location within that retargeted based on the location within that locationValue.
locationValue. Further modification of this Geolocation header
field MUST NOT occur. For example, an existing Geolocation According to this specification, the default value of any
locationValue in a request of: Geolocation header value "routing-allowed" is "no". 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". Other modifications of the Geolocation header field MUST NOT
occur.
For example, an existing Geolocation locationValue in a request of:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com"; inserted-by="alice123@atlanta.example.com";
can be modified by a proxy to add the "used-for-routing" parameter, can be modified by a proxy to add the "used-for-routing" parameter,
like this: like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com"; inserted-by="alice123@atlanta.example.com";
used-for-routing used-for-routing
if this is the locationValue the proxy used to make a retargeting if this is the locationValue the proxy used to make a retargeting
decision based upon, but make no other modification. decision based upon, but the proxy can make no other modification.
A SIP server MAY add a new Geolocation locationValue to a SIP A SIP server MAY add a new Geolocation locationValue to a SIP
request. The proxy SHOULD NOT insert a locationValue of a Location request. The server SHOULD NOT insert a locationValue of a Target
Target unless it is reasonably certain it knows the actual location unless it is reasonably certain it knows the actual geographic
of the Location Target, for example, if it thoroughly understands location of the Location Target (for example, if it thoroughly
the topology of the underlying access network and it can identify understands the topology of the underlying access network and it can
the device reliably (in the presence of, for example, NAT or VPN). identify the device location reliably, even in the presence of NAT
Routing errors are likely if the SIP server inserts an incorrect or VPN). Routing errors are likely if the SIP server inserts an
locationValue. incorrect locationValue.
A server adding a locationValue to an existing Geolocation header A locationValue added to an existing Geolocation header field
would look like: would look like:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com", inserted-by="alice123@atlanta.example.com",
<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; <sips:3sdefrhy2jj7@ls7.atlanta.example.com>;
inserted-by="lis1.atlanta.example.com" inserted-by="ls7.atlanta.example.com"
Notice the locationValue added by the proxy is last among Notice the locationValue added by proxy "ls7" is last among
locationValues. This practice MUST be done for all added locationValues. Proxies MUST add locationValue at the end of all
locationValues. locationValues that are already present in the request.
If this request was then retargeted by an intermediary using the If this request was then retargeted by an intermediary using the
locationValue inserted by the server, the intermediary would add a locationValue inserted by server "ls7", the intermediary would add a
"used-for-routing" parameter like this: "used-for-routing" parameter like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com", inserted-by="alice123@atlanta.example.com",
<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; <sips:3sdefrhy2jj7@ls7.atlanta.example.com>;
inserted-by="lis1.atlanta.example.com"; used-for-routing inserted-by="ls7.atlanta.example.com"; used-for-routing
It is conceivable that an initial routing decision is made on It is conceivable that an initial routing decision is made on
one locationValue, and subsequently another routing decision is one locationValue, and subsequently another routing decision is
made on a different locationValue further towards the ultimate made on a different locationValue further towards the ultimate
destination. This retargeting decision can be made on a newly destination. This retargeting decision can be made on a newly
inserted locationValue. While unusual, it can occur. In such a inserted locationValue. While unusual, it can occur. In such a
case, proxies MUST NOT remove any existing "used-for-routing" header case, proxies MUST NOT remove any existing "used-for-routing" header
parameter. In this instance, the SIP server retargeting based on field parameter. In this instance, the SIP server retargeting based
another locationValue MUST add the "used-for-routing" header on another locationValue MUST add the "used-for-routing" header
parameter to the locationValue used for retargeting by this server. field parameter to the locationValue used for retargeting by this
This will result in a Geolocation header looking as if it were server. This will result in a Geolocation header field indicating
retargeting more than once, which would be true - and is the desired that the request has been retargeted more than once, which is
outcome. allowed.
A Proxy that inserts or adds locationValue into a request MAY move a A Proxy that inserts or adds locationValue into a request MAY move a
'geolocation' option that is in a Supported header into a Require 'geolocation' option tag that is in a Supported header field into a
header if this proxy deems geolocation to be that important to Require header field if this proxy deems geolocation to be
Location Recipient(s) of this request. 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.
No SIP server can 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 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues
For proxies that receive a SIP request that contains a location For proxies that receive a SIP request that contains a location
error, either in a contained message body or after the proxy does a error, all the rules applicable to a UAS apply (see Section 6.2.1.).
dereference of the LbyR URI, all the rules applicable to a UAS apply The one point to add is that a proxy does not need to examine
here (see Section 6.2.1.), since in this case, the proxy is location contained in a request. Section 6.2.1. only applies to
considered a Location Recipient. Therefore, there is no reason to proxies that need to monitor or police location within requests (for
restate them here, and potentially have the two sections be whatever reason).
inconsistent. The one thing 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 are needing, monitoring or policing location within
requests (for whatever reason).
If a proxy inserted a locationValue into a request, it SHOULD be 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 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 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 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 included a locationValue a request, which then receives an error to
that locationValue. that locationValue.
This location inserting proxy SHOULD be transaction stateful for the This location-inserting proxy SHOULD be (at least) transaction
response. If the proxy is configured as a stateless proxy, and it stateful for the response. If the proxy is configured as a
inserts location, it MUST process and monitor all SIP responses, stateless proxy, and it inserts location, it MUST process and
looking for locationErrorValues that indicate it was the "inserter=" monitor all SIP responses, looking for locationErrorValues that
to learn that location it supplied was in error. It SHOULD react indicate it was the "inserter=" to learn that the location it
accordingly to the error code received. This document gives no supplied was in error. It SHOULD react according to the error code
guidance what the proxy should do to rectify the bad location received. This document gives no guidance what the proxy should do
information, but a future document MAY address this. 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 The "routing-allowed" parameter's purpose is to indicate if SIP
servers along the signaling path should bother looking at the LbyV servers along the signaling path should bother looking at the
or dereferencing the LbyR. There are two values specified here for location message body or dereferencing the location URI. There are
this parameter: "yes" and "no". If the "routing-allowed" parameter two values specified here for this parameter: "yes" and "no". If
is set to "yes", and the SIP server determines this SIP request the "routing-allowed" parameter is set to "yes", and the SIP server
needs to be routed based on the location of the target's location, determines this SIP request should be routed based on the target's
this parameter gives the server permission to look at the location location, this parameter gives the server permission to look at the
(or dereference it). If this parameter is set to "no", then the SIP location (or dereference it). If this parameter is set to "no",
server MUST NOT view the LbyV or dereference the LbyR within this then the SIP server MUST NOT view the location message body or
SIP request. If the SIP server believes it cannot process this dereference the location URI within this SIP request. If the SIP
message properly because it needs to learn the target's location in server believes it cannot process this message properly because it
order to route the message, then it MUST return a 424 (Bad Location) needs to learn the target's location in order to route the message,
response, indicating it requires permission (error code 400) to view then it MUST return a 424 (Bad Location Information) response,
the location. indicating it requires permission (error code 400) to view the
location.
Here is an example of a Geolocation-Error header field
Geolocation-Error: 400; code="Permission to Reveal Location
Information to a Third Party";
node="server42.example.com";
inserter="alice.example.com";
The above example says that the Location Recipient is
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
or this parameter is not present in the SIP request (as shown 400
error example above). The default behavior is to act as if the
parameter is present and set to "no". Server42 MUST get permission
to view the Target's location by reading a routing-allowed header
parameter saying "yes", otherwise a 400 error is sent back to the
inserter= entity to get permission.
Section 4.3 highlights this example, stating the user, Alice, MUST
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 7. 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.
skipping to change at page 37, line 24 skipping to change at page 39, line 23
establishment mechanisms. establishment mechanisms.
Quoting requirement #6 of [RFC3693]: Quoting requirement #6 of [RFC3693]:
"(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 get 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 8. Security Considerations
Conveyance of physical location of a UAC raises privacy concerns, Conveyance of physical location of a UAC 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 normally 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 protecting
message bodies (but this is not widely deployed) or TLS protecting message bodies (although this is not widely deployed) or TLS
the overall signaling. In cases where a session set-up is protecting the overall signaling. In cases where a session set-up
retargeted based on the location of the UAC initiating the call or is retargeted based on the location of the UAC initiating the call
SIP MESSAGE, securing the LbyV location with an end-to-end or SIP MESSAGE, securing the LbyV location with an end-to-end
mechanism such as S/MIME is problematic, because one or more proxies mechanism such as S/MIME is problematic, because one or more proxies
on the path need the ability to read the location information to on the path need the ability to read the location information to
retarget the message to the appropriate new destination UAS. retarget the message to the appropriate new destination UAS.
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, but exposes the information to
all proxies on the path as well as the endpoint. In most cases, the all proxies on the path as well as the endpoint. In most cases, the
UAC does not know the identity of the proxy or proxies providing UAC does not know the identity of the proxy or proxies providing
location-based routing services, so that end-to-middle solutions location-based routing services, so that end-to-middle solutions
might not be appropriate either. might not be appropriate either.
These same issues exist for basic SIP signaling, but SIP normally These same issues exist for basic SIP signaling, but SIP normally
does not carry information to physically track a user; making this does not carry information to physically track a user. This
extension especially sensitive. extension is especially sensitive. That said, 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 several times in the document above).
When location is inserted by a UAC, which is RECOMMENDED, it can When location is inserted by a UAC, which is RECOMMENDED, it can
decide whether to reveal its location using hop-by-hop methods. UAC decide whether to reveal its location using hop-by-hop methods. UAC
implementations MUST make such capabilities conditional on explicit implementations MUST make such capabilities conditional on explicit
user permission, and SHOULD alert a user that location is being user permission, and SHOULD alert a user that location is being
conveyed. Proxies inserting location for location-based routing are conveyed. Proxies inserting location for location-based routing are
unable to meet this requirement, and such use is NOT RECOMMENDED. unable to alert users, and such use is NOT RECOMMENDED. Proxies
Proxies conveying location using this extension MUST have the conveying location using this extension MUST have the permission of
permission of the Target to do so. the Target to do so.
One facet within this extension is such that locations can be placed This SIP extension offers the default ability to require permission
on a remote server, accessible with the possession of a URI. The to view location while the SIP request is in transit. The default
concept of an LbyR URI has its own security considerations. It is for this is set to "no", and there is an error explicitly describing
tempting to assume that the dereference would have authentication, how an intermediary asks for permission to view the Target's
location.
Because target locations can be placed on a remote server, called 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 authorization and other security mechanisms that limit the access to
information. Unfortunately, this might not be true. The access information. Unfortunately, this might not be true. The access
network the UAC is connected to can be the source of location network the UAC is connected to can be the source of location
reference, and it might not have any credentialing mechanism reference, and it might not have any credentialing mechanism
suitable for controlling access to location. Consider, suitable for controlling access to a target's location. Consider,
specifically, a nomadic user connected to an access network in a specifically, a nomadic user connected to an access network in a
hotel. The UAC has no way to provide a credential acceptable to hotel. The UAC has no way to provide a credential acceptable of the
the hotel Location Server (LS) to any of its intended Location hotel Location Server (LS) to any of its intended Location
Recipients. The recipient of a reference does not know if a Recipients. The recipient of a reference does not know if a
reference has appropriate authorization policies or not. The LS reference has appropriate authorization policies or not.
should provide location to any requestor.
Accordingly, possession of the reference should be considered Accordingly, possession of the reference should be considered
equivalent to possession of the value, and the reference should be equivalent to possession of the value, and the reference should be
treated with the same degree of care as the value. Specifically, treated with the same degree of care as the value. Specifically,
TLS MUST be used to protect the security of the reference. Notice TLS MUST be used to protect the security of the reference. Notice
that this does not constrain the dereference protocol to use TLS. that this specification does not constrain the dereference protocol
That specification is left entirely to the dereferencing protocol to use TLS. That specification is left entirely to the dereferencing
documents. protocol documents.
There is no integrity on any locationValue or locationErrorValue There is no end-to-end integrity on any locationValue or
header parameter end-to-end (or middle-to-end if the value was locationErrorValue header field parameter (or middle-to-end if the
inserted by a intermediary), so recipients of either header need to value was inserted by a intermediary), so recipients of either
implicitly trust the header contents, and take whatever precautions header field need to implicitly trust the header field contents, and
each entity deems appropriate give these facts. take whatever precautions each entity deems appropriate given this
situation. Any idea of using SIP Identity is lost as soon as it is
realized that the Geolocation header value can be added to by
intermediaries in the signaling path.
9. IANA Considerations 9. 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).
9.1 IANA Registration for the SIP Geolocation Header [Editor's Note: RFC-Editor - within the IANA section, please
replace "this doc" with the assigned RFC number,
if this document reaches publication.]
The SIP Geolocation header is created by this document, with its 9.1 IANA Registration for the SIP Geolocation Header Field
definition and rules in Section 4.1 of this document, to be added to
the sip-parameters, in the portion titled "Header Field Parameters The SIP Geolocation Header Field is created by this document, with
and Parameter Values". 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
"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 inserted-by= no [this doc]
Geolocation used-for-routing yes [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 9.2 IANA Registration for New SIP 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 sip-parameters within IANA. to the IANA sip-parameters registry.
9.3 IANA Registration for Response Code 424 9.3 IANA Registration for Response Code 424
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 9.4 IANA Registration of New Geolocation-Error Header Field
The SIP Geolocation-error header is created by this document, with The SIP Geolocation-error header field is created by this document,
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 sip-parameters, in the portion titled "Header Field added to the IANA sip-parameters registry, in the portion titled
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 inserter= no [this doc]
Geolocation-Error node= no [this doc] Geolocation-Error node= no [this doc]
Geolocation-Error code= no [this doc] Geolocation-Error code= yes* [this doc]
* see section 9.5 for the newly created values.
9.5 IANA Registration for the SIP Geolocation-Error Codes 9.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 at sip-parameters within document, and registered in a new table in the IANA sip-parameters
IANA. 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 to be placed into SIP responses to inform the location
inserter of the error. inserter of the error.
Code Description Reference Code Description Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
100 "Cannot Process Location" General location error, [this doc] 100 "Cannot Process Location" General location error, [this doc]
meaning location in the request cannot be meaning location in the request cannot be
processed at this time. No actionable guidance. processed at this time. No actionable guidance.
Can be treated as a 200 or 300 error by error Can be treated as a 200 or 300 error by error
recipient. recipient.
200 "Retry Location Later" (with same data) Location [this doc] 200 "Retry Location Later with same data" The location [this doc]
cannot be processed at this time. Error recipient cannot be processed at this time. Error recipient
should try again with same data. should try again with same data.
300 "Retry Location Later" (with device updated location) [this doc] 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]
Location cannot be processed at this time. Error Location cannot be processed at this time. Error
recipient should try again with same data. recipient should try again with same data.
400 "Permission Necessary" Permission from calling user [this doc] 400 "Permission To Reveal Location Information to a Third Party"
to reveal location in request before request can Permission from calling user to reveal location [this doc]
be processed. This is a routing by location error. in request before request can be processed. This
User MUST be informed of permission request. is a routing by location error. User MUST be
informed of permission request.
500 "Location Information Denial" Request was actively [this doc] 500 "Location Information Denial" Request was actively [this doc]
denied because of the location in the request. denied because of the location in the request.
Recipient should not try again. Recipient should not try again.
9.6 IANA Registration of LbyR Schemes 9.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. Below is an example of how it Content-Type, and the reference, as follows:
could look
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 require an industry specification. Additions to this registry must be defined in a permanent and
readily available specification (this is the "Specification
Required" IANA policy defined in [RFC5226])..
10. Acknowledgements 10. Acknowledgements
To Dave Oran for helping to shape this idea. To Jon Peterson and To Dave Oran for helping to shape this idea.
Dean Willis on guidance of the effort. To Allison Mankin, Dick
Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,
Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith
Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie,
Shida Shubert, Umesh Sharma, Richard Barnes, Matt Lepinski and
Jacqueline Lee for constructive feedback and nits checking.
A special thanks to Paul Kyzivat for his help with the ABNF in this To Jon Peterson and Dean Willis on guidance of the effort.
document, to Dan Wing for help with the S/MIME example, and to
Robert Sparks for many helpful comments and the proper building of To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning
the Geolocation-Error header. Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois
Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson,
Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard
Barnes, Dan Wing, Matt Lepinski and Jacqueline Lee for constructive
feedback and nits checking.
Special thanks to Paul Kyzivat for his help with the ABNF in this
document and to Robert Sparks for many helpful comments and the
proper construction of the Geolocation-Error header field.
And finally, to Spencer Dawkins for giving this doc a good scrubbing
to make it more readable.
11. References 11. References
11.1 References - Normative 11.1 References - Normative
[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
skipping to change at page 41, line 43 skipping to change at page 44, line 24
[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
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002 Method", RFC 3311, October 2002
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol (SIP)", Provisional Responses in Session Initiation Protocol (SIP)",
RFC 3262, June 2002. RFC 3262, June 2002.
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
[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- [IANA-civic] http://www.iana.org/assignments/civic-address-types-
Registry Registry
[RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Usage Clarification, Considerations, and Recommendations ", [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July
2006
11.2 References - Informative 11.2 References - Informative
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "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
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, October 2006 Information ", RFC 4776, October 2006
[ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP",
Author Information Author Information
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
skipping to change at page 43, line 4 skipping to change at page 44, line 75
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
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
Appendix A. Requirements for SIP Location Conveyance 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. There UAC, the UAS, as well as SIP proxies when conveying location. If a
is a motivational statement below each requirements that is not requirement is not obvious in intent, a motivational statement is
obvious in intent 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.
UAC-2 The SIP MESSAGE method [RFC3428] must support location UAC-2 The SIP MESSAGE method [RFC3428] must support location
conveyance. conveyance.
UAC-3 SIP Requests within a dialog should support location UAC-3 SIP Requests within a dialog should support location
conveyance. conveyance.
UAC-4 Other SIP Requests may support location conveyance. UAC-4 Other SIP Requests may support location conveyance.
UAC-5 There must be one, mandatory to implement means of UAC-5 There must be one, mandatory to implement means of
transmitting location confidentially. transmitting location confidentially.
Motivation: interoperability Motivation: to guarantee interoperability.
UAC-6 It must be possible for a UAC to update location conveyed UAC-6 It must be possible for a UAC to update location conveyed
at any time in a dialog, including during dialog at any time in a dialog, including during dialog
establishment. establishment.
Motivation: in case a UAC has moved prior to the establishment of a Motivation: if a UAC has moved prior to the establishment of a
dialog between UAs, the UAC must be able to send new location dialog between UAs, the UAC must be able to send location
information. In the case of location having been conveyed, information. If location has been conveyed, and the UA
and the UA moves, it needs a means to update the conveyed to moves, the UAC must be able to update the location previously
party of this location change. conveyed to other parties.
UAC-7 The privacy and security rules established within [RFC3693] UAC-7 The privacy and security rules established within [RFC3693]
that would categorize SIP as a 'Using Protocol' must be met. that would categorize SIP as a 'Using Protocol' must be met.
UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for
location conveyance within SIP, whether included LbyV or location conveyance within SIP, whether included LbyV or
LbyR. LbyR.
Motivation: interoperability with other IETF location protocols and Motivation: interoperability with other IETF location protocols and
mechanisms Mechanisms.
UAC-9 There must be a mechanism for the UAC to request the UAS send UAC-9 There must be a mechanism for the UAC to request the UAS send
its location its location.
UAC-9 has been DEPRECATED by the SIP WG, due to the many UAC-9 has been DEPRECATED by the SIP WG, due to the many
problems this requirement would have caused if implemented. problems this requirement would have caused if implemented.
The solution is for the above UAS to send a new request to The solution is for the above UAS to send a new request to
the original UAC with the UAS's location. the original UAC with the UAS's location.
UAC-10 There must be a mechanism to differentiate the ability of the UAC-10 There must be a mechanism to differentiate the ability of the
UAC to convey location from the UACs lack of knowledge of its UAC to convey location from the UACs lack of knowledge of its
location location
Motivation: Failure to receive location when it is expected can
Motivation: Failure to receive location when it is expected can be happen because the UAC does not implement this extension, or
because the UAC does not implement this extension, or it can because the UAC implements the extension, but does not know
be that the UAC implements the extension, but does not know where the Target is. This may be, for example, due to the
where it is. This may be, for example, due to the failure of failure of the access network to provide a location
the access network to provide a location acquisition acquisition mechanism the UAC supports. These cases must be
mechanisms the UAC understands. These cases must be
differentiated. differentiated.
UAC-11 It must be possible to convey location to proxy servers UAC-11 It must be possible to convey location to proxy servers
along the path. along the path.
Motivation: Location-based routing. Motivation: Location-based routing.
A.2 Requirements for a UAS Receiving Location A.2 Requirements for a UAS Receiving Location
The following are the requirements for location conveyance by a UAS: The following are the requirements for location conveyance by a UAS:
skipping to change at page 44, line 43 skipping to change at page 44, line 165
UAS-1 SIP Responses must support location conveyance. UAS-1 SIP Responses must support location conveyance.
Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG,
due to the many problems this requirement would have caused due to the many problems this requirement would have caused
if implemented. The solution is for the above UAS to send a if implemented. The solution is for the above UAS to send a
new request to the original UAC with the UAS's location. new request to the original UAC with the UAS's location.
UAS-2 There must be a unique 4XX response informing the UAC it did UAS-2 There must be a unique 4XX response informing the UAC it did
not provide applicable location information. not provide applicable location information.
In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS.
A.3 Requirements for SIP Proxies and Intermediaries A.3 Requirements for SIP Proxies and Intermediaries
The following are the requirements for location conveyance by a SIP The following are the requirements for location conveyance by a SIP
proxies and intermediaries: proxies and intermediaries:
Proxy-1 Proxy servers must be capable of adding a Location header Proxy-1 Proxy servers must be capable of adding a Location header
field during processing of SIP requests. field during processing of SIP requests.
Motivation: Provide the capability of network assertion of location Motivation: Provide network assertion of location
when UACs are unable to do so, or when network assertion is when UACs are unable to do so, or when network assertion is
more reliable than UAC assertion of location more reliable than UAC assertion of location
Note: Because UACs connected to SIP signaling networks may have Note: Because UACs connected to SIP signaling networks may have
widely varying access network arrangements, including VPN widely varying access network arrangements, including VPN
tunnels and roaming mechanisms, it may be difficult for a tunnels and roaming mechanisms, it may be difficult for a
network to reliably know the location of the endpoint. Proxy network to reliably know the location of the endpoint. Proxy
assertion of location is NOT RECOMMENDED unless the sip assertion of location is NOT RECOMMENDED unless the SIP
signaling network has reliable knowledge of the actual signaling network has reliable knowledge of the actual
location of the Targets. location of the Targets.
Proxy-2 There must be a unique 4XX response informing the UAC it Proxy-2 There must be a unique 4XX response informing the UAC it
did not provide applicable location information. did not provide applicable location information.
 End of changes. 280 change blocks. 
1022 lines changed or deleted 1153 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/