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

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