draft-ietf-sip-location-conveyance-01.txt   draft-ietf-sip-location-conveyance-02.txt 
SIP Working Group James M. Polk SIP Working Group James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Jan 17th, 2006 Brian Rosen Expiration: Sept 6th, 2006 Brian Rosen
NeuStar NeuStar
Session Initiation Protocol Location Conveyance Session Initiation Protocol Location Conveyance
draft-ietf-sip-location-conveyance-01.txt draft-ietf-sip-location-conveyance-02.txt
July 17th, 2005 Mar 6th, 2006
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 reference material or to cite them other than as "work in
progress." 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 January 17th, 2006. This Internet-Draft will expire on September 6th, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document presents the framework and requirements for usage of This document defines how the Session Initiation Protocol (SIP)
the Session Initiation Protocol (SIP) to convey user location conveys, or pushes, user location information from one SIP entity
information from one Session Initiation Protocol (SIP) entity to to another SIP entity. SIP Location Conveyance is always end to
another SIP entity. We consider cases where location information is end, but sometimes the embedded location information can be acted
conveyed from end to end, as well as cases where message routing by upon by SIP Servers to direct where the message goes, based on where
intermediaries is influenced by the location of the session the user agent client is.
initiator, the user agent client (UAC). We offer a set of solutions
to the requirements, each based on the scenario being addressed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4
2. Location In the Body or in a Header . . . . . . . . . . . . . 7 2. Location In the Body or in a Header . . . . . . . . . . . . . 8
3. Scope of Location Conveyance . . . . . . . . . . . . . . . . 8 3. Requirements for SIP Location Conveyance . . . . . . . . . . 9
3.1 Scope of Location in a Message Body . . . . . . . . . . . 8 4. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 12
3.2 Scope of Location in a Header . . . . . . . . . . . . . . 9 4.1 New Option Tags and a Location Header Created . . . . . . 13
4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 10 4.2 424 (Bad Location Information) Response Code . . . . . . 16
5. Requirements for UA-to-Proxy Server Location Conveyance . . . 11 4.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 16
6. Additional Requirements for Emergency Calls . . . . . . . . . 12 4.3 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 17
7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 14 5. SIP Element Behavior When Conveying Location . . . . . . . . 18
7.1 Indicating Support for Location by the UAC . . . . . . . 16 5.1 Location Conveyance Using the INVITE Method . . . . . . . 19
7.2 Location Rejection Responses . . . . . . . . . . . . . . 19 5.2 Location Conveyance Using the MESSAGE Method . . . . . . 21
7.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 20 5.3 Location Conveyance Using the UPDATE Method . . . . . . . 22
7.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 21 5.4 Location Conveyance Using the REGISTER Method . . . . . . 27
8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 23 6. Special Considerations for Emergency Calls . . . . . . . . . 29
8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 23 7. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 29
8.1.1 UA-to-UA Using INVITE w/ Geo Format w-w/o S/MIME . . 25 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1.2 UA-to-UA Using INVITE w/ Civic Format w-w/o S/MIME . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
8.2 OPTIONS Method and Location . . . . . . . . . . . . . . . 31 10.1 IANA Registration for the SIP Location Header . . . . . 31
8.2.1 OPTIONS Request to Learn UAC's Location . . . . . . . 31 10.2 IANA Registration of the Location Option Tags. . . . . . 31
8.2.2 OPTIONS Request to Learn UAS's Location . . . . . . . 33 10.3 IANA Registration for Response Code 424 . . . . . . . . 31
8.3 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8.4 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4.1 UPDATE Updates Location During Session 12.1 Normative References . . . . . . . . . . . . . . . . . 31
Establishment . . . . . . 37 12.2 Informative References . . . . . . . . . . . . . . . . . 32
8.4.2 UPDATE Updates Location After Session Author Information . . . . . . . . . . . . . . . . . . . . . 32
Establishment . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 33
8.4.3 UPDATE Updates Location After a UA Moves
in a Dialog . . . . . . 40
8.5 Location Conveyance Using PUBLISH . . . . . . . . . . . . 42
8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 44
9. Special Considerations for Emergency Calls . . . . . . . . . 47
9.1 Emergency UAC Behavior Rules . . . . . . . . . . . . . . 49
9.2 Emergency UAS/Intermediary Behavior Rules . . . . . . . . 50
9.3 Basic Emergency Message Flow Examples . . . . . . . . . . 52
10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 55
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 55
12. Security Considerations . . . . . . . . . . . . . . . . . . . 56
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 56
13.1 IANA Registration for Response Code 424 . . . . . . . . 56
13.2 IANA Registration for Response Code 425 . . . . . . . . 56
13.3 IANA Registration for the SIP Location Header . . . . . 56
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
15.1 Normative References . . . . . . . . . . . . . . . . . 57
15.2 Informative References . . . . . . . . . . . . . . . . . 58
Author Information . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . 72
1. Introduction 1. Introduction
This document presents the framework and requirements for the usage There are several situations in which it is desired or necessary for
of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of a Session Initiation Protocol (SIP) [RFC3261] user agent to convey,
user location information described by [RFC3693] from a SIP entity or push Location Information (LI) from one SIP entity to another.
to another SIP entity. This document discusses the scenarios for such conveyance, and
includes the requirements to be met when a SIP UAC wants or needs to
convey its location to another SIP entity. A concept of inheritance
exists in which the conveyance of the location of a user agent means
conveying the location of a user of that user agent. This is not an
absolute in SIP, but applies for the pushing of location using SIP.
The privacy concerns of this topic are also discussed, and need to
meet the requirements laid out in RFC 3693 [RFC3693]. This document
does not discuss the pulling of location information from a user
agent. This is left for a future effort.
There are several situations in which it is appropriate for SIP to Why would a SIP user agent (UA) push its location to another SIP UA?
be used to convey Location Information (LI) from one SIP entity to
another. This document specifies requirements when a SIP UAC knows
its location by some means not specified herein, and needs to inform
another SIP entity. One example is one user agent informing another
user agent where it is (i.e. you want to tell your friend where you
are). There is a migration issue requiring the capability to convey
location seemingly from the source to destination, but in times in
which the source, or the originating user agent, has not be upgraded
to support this extension to the SIP architecture. There are
limitations to this "fix", but it serves a purpose for a critical
service discussed in sections 6 and 9 of this document.
Another example is to reach your nearest pizza parlor. A chain of There are 3 reasonable scenarios why location can be, or needs to be
pizza parlors may be contacted through a single well known uri conveyed to a remote SIP element:
(sip:pizzaparlor.com). This SIP message could be forwarded to the
closest franchise by the pizzaparlor.com proxy server. The
receiving franchise UAS uses the location information of the UAC to
determine the location your delivery.
Another important example is emergency calling. A call to 1) to include location in a request message seeking the nearest
sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The instance of destination, where there could be more than one
example.com proxy server must route the call to the correct public choice; (hey, here I am, I want to talk to the nearest instance
safety answering point (PSAP) determined by the location of the of you? i.e. where's the nearest Pizza Hut relative to where I
caller. At the PSAP, the UAS must determine the correct am).
police/fire/ambulance/... service, which is also based on your
location. In many jurisdictions, precise location information of
the caller in distress is a required component of a call to an
emergency center.
A fourth example is a direction service, which might give you verbal 2) to push the user's location to a server that can deal with all
directions to a venue from your present position. This is a case the inquiries, leaving the UA to do other tasks; (Presence
where only the destination UAS needs to receive the location Server)
information.
3) to inform the user of another UA where the sending user is;
(dude, he is where I am) or (I need help, here I am)
Scenario #1 revolves around the idea of a user wanting to find the
nearest instances of something else. For example, where is the
nearest pizza parlor. A chain of pizza parlors may be contacted
through a single well known URI (sip:pizzaparlor.example.com). This
by itself does not solve enough to the sending UA. The server at
this well known URI needs to know where the nearest one is to the
requester. In SIP, this could be accomplished in the initial
message by including the location of the UAC in the Request message.
This allows the SIP message to be forwarded to the closest physical
site by the pizzaparlor.com proxy server. Additionally, the
receiving site's UAS uses the UAC's location to determine the
location your delivery. A more immediate example may be: where's
the nearest (car) garage repair shop, because the user of the UAC
has a flat tire.
Scenario #2 revolves around pushing the user's location information
to an external server to deal with all location requests in the
future. This leaves a buffer layer between the user and the seeker
of the user's location. This server would typically handle all
security checks and challenges of those seeking the user's location,
as well as handling all the processing of the location target's
profile rules entered into that server. This external server
c/would be a Presence server. This scenario will not be addressed
in this document because of the prevailing Presence solutions for
conveying location information.
Scenario #3 actually has a part A and a part B to it. Both involve
the UAC including its location in the request to the UAS within a
SIP transaction. Part A simply has the user, Alice, informing
another user, Bob, where she is. This could be for the loan purpose
for this SIP message, or it could be part of another transaction -
in which location were merely included, such as within a call set-
up.
Part B of this scenario has a user, Alice calling for help and
including location to inform who she's calling where she is. This
is where the called party needs to come bring help to. Within this
scenario, the UAC will need to know this is an emergency SIP request
message, and to include the UAC's location in this message.
While scenarios 1, 2 and 3A should use some form of SIP security,
typically at the wishes of the user, scenario 3B may or may not
involve SIP security measures. This is because including any
security measures may cause the SIP request to fail, and that is
likely not a good result. It is also conceivable that a first
attempt with the user's security measures enabled is tried, and if
there are any failures, the subsequent attempt or attempts do not
involve security measures. Most believe that completing the
emergency call is more important than protecting the information in
the SIP message. Obviously this is up to local and jurisdictional
policies, but is mentioned here as a hint of a rationale of a later
section of this document.
This document does not discuss how the UAC discovers or is This document does not discuss how the UAC discovers or is
configured with its location (either coordinate based such as from configured with its location, however will specify how this spec
[RFC3825] or civic based such as from [ID-CIVIC]). This document meets the requirements for SIP qualifying as a "using protocol" as
will also not discuss the contents of the SIP message body part that defined in [RFC3693], in section 7.
is the Location Object (LO) itself. We will specify the
requirements for SIP qualifying as a "using protocol" as defined by
Geopriv in [RFC3693].
Sections 7, 8 and 9 give specific examples (in well-formed SIP Section 3 lists the requirements for SIP location conveyance.
messages) of SIP UA and Proxy behavior for location conveyance, the Section 4 defines how SIP conveys location. Section 5 illustrates
last of which is a section devoted to the unique circumstances specifics about location conveyance in certain SIP request messages.
regarding emergency calling. Section 10 addresses how this document Section 6 briefly discusses pertinent behaviors with respect to the
adheres to the requirements specified in [RFC3693] (Geopriv unique nature of emergency calling. Section 9 provides the security
Requirements). Sections 11 and 12 list the current open issues with considerations and Section 10 IANA registers one new SIP header, two
location conveyance in SIP, and the new open issues recently new option tags and one new 4XX Response codes.
discovered as a result of the added effort to this revision.
Section 13 IANA registers 2 new Response codes.
1.1 Conventions used in this document 1.1 Conventions 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].
1.2 Changes from Prior Versions 1.2 Changes from Prior Versions
[NOTE TO RFC-EDITOR: If this document is to be published as an RFC, [NOTE TO RFC-EDITOR: If this document is to be published as an RFC,
this section is to be removed prior to that event.] this section 1.2 is to be removed prior to that event.]
This is a list of the changes that have been made from the SIP WG
version -01 to this version -02:
- streamlined the doc by removing text (ultimately removing 42 pages
of text).
- Limited the scope of this document to SIP conveyance, meaning only
how SIP can push location information.
- reduced emergency calling text to just a few paragraphs now that
the ECRIT WG is taking most of that topic on.
- greatly reduced the number of requirements in this version.
- changed the requirements groups from "UA-to-UA", "UA-to-Proxy",
etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is
being asked of each SIP element.
- Removed the full SIP message examples.
- completed the ABNF for the Location header, including a cid-url to
point at a message body part to help in parsing for location.
- Deleted the call for a new 425 (Retry Location) response code, as
it appears this can easily be used to spoof a UA into providing
where it is inadvertently, even if the intent is legitimate by the
UAC.
This is a list of the changes that have been made from the SIP WG This is a list of the changes that have been made from the SIP WG
version -00 to this version -01: version -00 to this version -01:
- cleaned up a lot of loose ends in the text - cleaned up a lot of loose ends in the text
- created a new Location header to convey many means (location is in - created a new Location header to convey many means (location is in
the body - even if not viewable, which location format is present, the body - even if not viewable, which location format is present,
which format is requested in a query, how to request more than one which format is requested in a query, how to request more than one
location format in a query, whether the UAC understands location location format in a query, whether the UAC understands location
skipping to change at page 4, line 174 skipping to change at page 8, line 18
open questions surrounding the implications of that action open questions surrounding the implications of that action
- added a few names to the acknowledgements section - added a few names to the acknowledgements section
2. Location In the Body or in a Header 2. Location In the Body or in a Header
In determining where "location" is placed in a SIP message, In determining where "location" is placed in a SIP message,
consideration is taken as to where the trust model is based on the consideration is taken as to where the trust model is based on the
architecture involved. architecture involved.
If the user agent has the location stored within it, and one user If the user agent has the location stored within it, and this user
agent wants to inform another user agent where it is, it seems agent wants to inform another user agent where it is, it seems
reasonable to have this accomplished by placing the location reasonable to have this accomplished by placing the location
information (coordinate or civic) in an S/MIME registered and information (coordinate or civic) in an S/MIME registered and
encoded message body, and sending it as part of a SIP request or encoded message body, and sending it as part of a SIP request or
response. No routing of the request based on the location response. No routing of the request based on the location
information is required in this case; therefore no SIP Proxies information is required in this case; therefore no SIP Proxies
between these two UAs need to view the location information between these two UAs need to view the location information
contained in the SIP messages. This is location by-value. contained in the SIP messages. The UAC should know messages will be
routed based on location when creating a message. This is location
Although SIP [RFC3261] does not permit SIP intermediaries to modify by-value.
or delete a message body, there is no restriction on viewing message
bodies. S/MIME protected message bodies, implemented on bodies for
communications between user agents only, would render the location
object opaque to a proxy server for any desired modification if it
is not correct or precise enough from that proxy's point of view
(were it to be able to view it). This problem is similar to that
raised in Session Policy [ID-Sess-Pol], where an intermediary may
need information in a body, such as IP address of media streams or
codec choices to route a call properly. Requirements in [ID-Sess-
Pol] are applicable to routing based on location, and are
incorporated in these requirements by reference.
It is conceivable to create a new header for location information.
However, [RFC3693] prefers S/MIME for security of Location
Information, and indeed S/MIME is preferable in SIP [RFC3261] for
protecting a message body. Accordingly, these requirements specify
location be carried in a body when it is known to/stored in a user
agent.
It is the use of S/MIME however, that limits message routing based
on the location of the UAC. Therefore, it seems appropriate to
require that, where routing is dependent on location, protection of
the location information object be accomplished by other mechanisms
visible to SIP proxies: here TLS ("sips:" from [RFC3261]). It is
envisioned that S/MIME SHOULD be used when location information is
not required by proxy servers, and TLS MUST be used when it is. The
UAC will need to know the difference in the call's intent as to
which security mechanism to engage for location conveyance.
There is another limitation, one that is very real, as a unfortunate
result of how certain messages are addressed that limits this
restriction to "only in a message body shall location be". Because
SIP will be used for emergency calling, and because emergency
calling has nothing like an area code - given SIP's purposeful
separation from geophysical awareness - a means must be created for
any SIP UA to call 911 or 112 (or the like). Because this document
is not being generated when all SIP devices are, it is an extension
to all UAs existing today. This means for some time, there will
need to at least be a stop-gap mechanism for conveying location for
the purposes of routing an emergency call which is highly dependent
on where it is on the planet; something SIP generally cares nothing
about. With this in mind, a Location header will be created to
accomplish a location by-reference insertion by a SIP intermediary
along the path from UAC towards a Public Safety Answering Point
(PSAP). This will not be the sole purpose of this header, but this
header can be used for this purpose, as [RFC3261] allows SIP
intermediaries to insert headers in transit.
This document does not address the behavior or configuration of SIP
Proxy Servers in cases in order to accomplish location-sensitive
routing. That is out of scope, and left for further study.
3. Scope of Location Conveyance
As concluded from the previous section, location information is to
be contained within a message body when the user agent has this
information locally. Location, if not known to the user agent, can
be inserted by a SIP intermediary in transit, but there must be
rules surround this capability.
3.1 Scope of Location in a Message Body
If location is to be protected with S/MIME, even when another body
(SDP for example) is also to be sent in the message, the rules
stated in section 7 of [RFC3261] regarding multipart MIME bodies
MUST be followed. The format and privacy/security rules of
[RFC3693] MUST too be followed.
User agents providing location can convey it incorrectly or
inappropriately. Therefore, there needs to be a new UAC error
response code created to inform the UAC by a UAS or Proxy of this
rejected request message because of the location information in the
message. If the SIP intermediary has location knowledge of the UAC,
it can include that information in an error message for use in a
subsequent request by that UAC, therefore, there needs to be two new
response codes currently not defined in SIP:
1) the first indicating the existing location information was not
considered good by the viewing or receiving SIP element.
There will be times in which the UAC does not know its location
information, or another SIP entity knows the UAC's location better
than the UAC itself. How this is determined is out of scope of this
document. In these times, a Proxy servers that know the location
of the UAC needs inform the UAC of its location information and have
that UAC include that message body in its next SIP message to the
same destination UA. This error code needs to be unique with
respect to the error code for merely incorrect location information
from the UAC.
2) a second new response code indicating the existing location
information was not considered good by the viewing SIP element,
but in this case, the SIP element does have current and correct
location information for the UAC to be one that included in a new
message body to be used in a subsequent SIP Request by the UAC.
This second response code would be more applicable for cases in
which a SIP intermediary knows more about the location of the UAC
than the UAC, and needs to get the more appropriate location
information into the SIP message in order for it to be processed
correctly by it, and upstream SIP intermediaries. This cannot occur
with existing rules stating message bodies cannot be modified or
added by intermediaries. This new response code message containing
new location information of the UAC appears the best course of
action.
Since there can be multiple location observations of the same UAC,
each transmitted or otherwise inputted into the UAC, there MUST be a
means for including more than one piece of location information in a
SIP message. As best as possible, each should be labeled to
indicate they are separate observations for the receiving entity to
determine which is most correct.
3.2 Scope of Location in a Header
The first, best location for location relating to the endpoint is in
the endpoint. This allows the endpoint to send its location to
wherever it wants, using whichever application it wants to use.
Keeping the location of an endpoint in a server on a network may be
detrimental to the operation at hand. One example is for emergency
calling. If the UA does not have its location, and a server does,
that means the server has to be 100% stateful of that UA's location
100% of the time, wherever that UA goes. [ID-EMER-ARCH] states
clearly that time is of the essence in placing an emergency call.
The time it takes to do a non-stateful lookup of a UAC's mobile
location will impact the time it takes SIP signaling to process that
location to determine which PSAP the call should be routed to.
Therefore, the use of location by-reference SHOULD be used as a last
resort. This becomes obviously the only choice if the UA has no
concept of location to include by-value in the first place. For
that reason, there needs to be an identifier in SIP messaging
indicating a UA is aware of location conveyance. This will greatly
speed up the processing at a SIP intermediary and limit its choices
when processing a SIP Request that may require location to be
present in the SIP message (such as emergency calling). Sections 6
and 9 delve deep into this topic.
This indication of location awareness MUST be outside a message
body, therefore in a header - and as one does not exist today
related to location, this document will create one. Section 7
details the many purposes of this header, including the ability to
convey which location format a UAC is transmitting, or a UAS wants.
4. Requirements for UA-to-UA Location Conveyance SIP currently does not permit SIP intermediaries to modify
or delete a message body [RFC3261]. There is, however, no
restriction on intermediaries viewing message bodies. S/MIME
protected message bodies, implemented on bodies for end-to-end
communications only (i.e. between user agents), would render the
location object opaque to a proxy server from any viewing of the
message body. This problem is similar to that raised in Session
Policy [ID-Sess-Pol], where an intermediary may need information in
a body, such as IP address of media streams or codec choices to
route a call properly. Requirements in [ID-Sess-Pol] are applicable
to routing based on location, and are incorporated in these
requirements by reference.
The following are the requirements for UA-to-UA Location Conveyance The location format is defined in [RFC4119] as a "Presence
Situations where routing is not based on the LI of either UA, and Information Data Format - Location Object", or PIDF-LO. The amount
location is stored/cached in the UAC: of information that is necessary to appropriately transmit location
information in a format that is understandable is larger than a SIP
header could realistically include. However, there must be a means
for both a UAC to include a reference point to where location can be
retrieved from a remote server, and in some cases, a SIP server
wants or needs to add location to a SIP message as it is processed
by that server. This must be in a compact form in a SIP header. A
URI satisfies this description. This is location-by-reference.
U-U1 - Dialog-initiating SIP Requests and their responses MUST Location-by-Reference allows a UA to place its location on a remote
support Location Conveyance node, to be retrieved by who has this URI. This allows the server
to use its processing power to handle all policy rule operations the
user wants performed per request, and all security challenges done
as well.
U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location [RFC3693] prefers S/MIME for security of Location Information, and
Conveyance indeed S/MIME is preferable in SIP [RFC3261] for protecting a
message body. Accordingly, these requirements specify location be
carried in a body when it is known to/stored in a user agent.
U-U3 - Other SIP Requests SHOULD support Location Conveyance It is the use of S/MIME however, that limits message routing based
on the location of the UAC, scenario 3B from above. Therefore, it
seems appropriate to require that, where routing is dependent on
location, protection of the location information object be
accomplished by other mechanisms visible to SIP proxies: here TLS
("sips:" from [RFC3261]). The UAC will need to know the difference
in the call's intent as to which security mechanism to engage for
location conveyance.
U-U4 - UAC Location information SHOULD remain confidential e2e It is conceivable that an initial attempt to communicate with
to the destination UAS except when the session is to an location included may fail due to the security measures used.
identifiable emergency endsystem. Subsequent requests ought to use less security. For example, if an
initial request used S/MIME and failed. A subsequent request could
downgrade the security measures used to that of TLS. This is a
matter for local and jurisdictional policy, and is merely a hint at
implementation possibilities.
U-U5 - UAC MUST not use S/MIME on the Location message body 3. Requirements for SIP Location Conveyance
if the message is a dialog related or MESSAGE Request
message unless the UAC has a pre-established association
with the routing SIP intermediary.
U-U6 - UAS Location information SHOULD remain confidential e2e The following subsections address the requirements placed on the
to the destination UAC except when the session is to/from an user agent client, the user agent server, as well as SIP proxies
identifiable emergency endsystem. when conveying location.
Emergency callback is one example where this may apply. 3.1 Requirements for a UAC Conveying Location
U-U7 - The privacy and security rules established within the The following are the requirements for location conveyance by a user
Geopriv Working Group that would categorize SIP as a 'using agent client. There is a motivational statement below each
protocol' [RFC3693] MUST be met. See Section 10 for requirements that is not obvious in intent.
analysis.
U-U8 - Location information SHOULD be contained in the location UAC-1 The SIP INVITE Method [RFC3261] MUST support Location
Object as defined in [ID-PIDF-LO], which will satisfy all Conveyance.
format requirements for interoperability.
U-U9 - Location information MAY be contained in a by-reference URI UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location
contained in a Location Header. All privacy and security Conveyance.
rules associated with a Location message body as defined in
[ID-PIDF-LO], MUST be maintained.
U-U10- User Agents MUST have a means for querying a remote server UAC-3 SIP Requests within a dialog SHOULD support Location
for the UAC's location; including offering a preferential Conveyance.
location format to be returned.
U-U11- User Agents and Proxies SHOULD be able to handle SIP UAC-4 Other SIP Requests MAY support Location Conveyance.
messages in which Location Information is fragmented across
multiple packets.
U-U12- There MUST be a unique UAC error response code informing the UAC-5 There MUST be one, mandatory to implement means of
UAC it did not provide applicable location information. transmitting location confidentially.
U-U13- There MUST be a unique UAC error response code informing the Motivation: interoperability
UAC of new Location Information known to a SIP Intermediary,
and the UAC MUST be prepared to receive that information in
the error response itself.
U-U14- There MUST be a means for publishing location state UAC-6 It MUST be possible for a UAC to update location conveyed
information for a particular presentity to a Presence prior to dialog establishment.
Compositor Server.
U-U15- User Agents and Proxies SHOULD be able to process SIP Motivation: in case a UAC has moved prior to the establishment of a
messages which contains more than one piece of Location dialog between UAs, the UAC must be able to send new location
information. information.
U-U16- User Agents MUST have the ability to query another user UAC-7 The privacy and security rules established within [RFC3693]
agent for location information refresh and movement of the that would categorize SIP as a 'using protocol' MUST be met.
UA. See Section 7 for analysis.
5. Requirements for UA-to-Proxy Server Location Conveyance UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for
location conveyance within SIP, whether included by-value or
by-reference.
The following are the requirements for UA-to-Proxy Server Location Motivation: interoperability
Conveyance situations:
U-PS1 - MUST work with dialog-initiating SIP Requests and UAC-9 A UAC MUST be capable of transmitting a SIP request without
responses, as well as the SIP MESSAGE method [RFC3428], and protecting the PIDF-LO message body. It is RECOMMENDED this
SHOULD work with most SIP messages. not be the default configuration of any UA. This requirement
is orthogonal to the use of TLS or IPSec hop-by-hop between
SIP elements.
U-PS2 - UAC location information SHOULD remain opaque to Motivation: If a SIP request is part of an emergency call,
intermediaries the message was not addressed to, but MUST therefore includes the UAC's location, the UAC may understand
be useable (i.e. viewable) by intermediary proxy servers through local policy or configuration that a proxy server
requiring location knowledge of the UAC to properly route will need to learn the UAC's location to route the message
the message. correctly. Using S/MIME on the PIDF-LO defeats this
capability in proxies.
U-PS3- User Agents MUST have a means for indicating they understand UAC-10 A UAC MUST allow its user to be able to disable providing
what location conveyance is, but currently do not have their location within any SIP request message. It is RECOMMENDED
location information to convey. this not be the default configuration of any UA.
U-PS4 - The privacy and security rules established within the Motivation: local laws may give this right to all users within a
Geopriv Working Group which would categorize SIP as a jurisdiction, even when the request is initiating an
'using protocol' MUST be met [RFC3693]. emergency call.
U-PS5 - Proxy servers MUST NOT modify or remove an location message 3.2 Requirements for a UAS Receiving Location
body part ([RFC3261] currently forbids this).
U-PS6 - A SIP message containing location information MUST NOT be The following are the requirements for location conveyance by a user
rejected by a SIP intermediary because the message body agent server:
part or LO itself was not understood (except when the
intermediary complies with requirement U-PS8 below, or when
the SIP message is addressed to that intermediary).
With regards to requirement U-PS6, not all SIP Proxies are expected UAS-1 SIP Responses MUST support Location Conveyance.
to route messages based on the contained location information from
the UAC. There will likely be a SIP Proxy able to perform this
function downstream, and the original SIP message needs to reach
that location enabled Proxy to route correctly.
U-PS7 - There MUST be a unique UAC error response code informing UAS-2 There MUST be one, mandatory to implement means of
the UAC it did not provide applicable location information. transmitting location confidentially.
U-PS8 - There MUST be a unique UAC error response code informing Motivation: interoperability
the UAC it did not provide applicable location information,
and to include the location information contained in the
message body of the error message for usage in the UAC's
next attempt to the same UAS of the original message.
6. Additional Requirements for Emergency Calls UAS-3 The PIDF-LO [RFC4119] is a mandatory to implement format for
location conveyance within SIP, whether included by-value or
by-reference.
Emergency calls have requirements that are not generally important Motivation: interoperability
to other uses for location in SIP:
Emergency calls presently have between 2 and 8-second call setup UAS-4 There MUST be a unique 4XX error response code informing
times. There is ample evidence that the longer call setup end of the UAC it did not provide applicable location information.
the range causes an unacceptable number of callers to abandon the
call before it is completed. Two-second call completion time is a
goal of many existing emergency call centers. Allocating 25% of the
call set up for processing privacy concerns seems reasonable; 1
second would be 50% of the goal, which seems unacceptable; less than
0.5 second seems unachievable, therefore:
E-1 - Privacy mechanisms MUST add no more than 0.5 second of call UAS-5 SIP UAs MUST be prepared to receive location without privacy
setup time when implemented in present technology UAs and mechanisms enabled. It is RECOMMENDED this not be the
Proxy Servers. default configuration of any UA, however, this is possible
based on local laws.
It may be acceptable for full privacy mechanisms related to the Motivation: Because a SIP request can fail in transit for security
location of the UAC (and it's user) to be tried on an initial reasons, UACs are allowed to transmit, or retransmit requests
attempt to place a call, as long as the call attempt may be retried including location without any security mechanisms utilized,
without the privacy mechanism present (or enabled) if the first even when this SIP transaction is an emergency call. UAs
attempt fails. Abandoning privacy in cases of failure of the must be prepared to receive the messages without confidential
privacy mechanism might be subject to user preference, although such location.
a feature would be within the domain of a UA implementation and thus
not subject to standardization. It should be noted that some
jurisdictions have laws that explicitly deny any expectation of
location privacy when making an emergency call, while others grant
the user the ability to remain anonymous even when calling an PSAP.
So far, this has been offered in some jurisdictions, but the user
within that jurisdiction must state this preference, as it is not
the default configuration.
E-2 ű Privacy mechanisms MUST NOT be mandatory for successful UAS-6 There MUST be a unique 4XX error response code informing the
conveyance of location during an (sos-type) emergency call. UAC it did not provide applicable location information.
E-3 - It MUST be possible to provide a privacy mechanism (that does 3.3 Requirements for SIP Proxies and Intermediaries
not violate the other requirements within this document) to a
user within a jurisdiction that gives that user the right to
choose not to reveal their location even when contacting an
PSAP.
E-4 ű The retention and retransmission policy of the PSAP MUST be The following are the requirements for location conveyance by a SIP
able to be made available to the user, and override the proxies and intermediaries:
user's normal policy when local regulation governs such
retention and retransmission (but does not violate
requirement E-3). As in E-2 above, requiring the use of the
PSAP's retention and/or retransmission policy may be subject
to user preference; although in most jurisdictions, local
laws specify such policies and may not be overridden by user
preference.
Location information is considered so important during emergency Proxy-1 Proxy servers MUST NOT modify or remove a location
calls, that it is to be transmitted even when it is not considered message body part, and SHOULD NOT modify or remove a
reliable, or might even be wrong. For example, some application location header or location header value.
might know that the DHCP reply with location information was
overwritten recently (or exactly) when a VPN connection was
activated. This could, and likely will, provide any new location
information to the UA from somewhere far away from the UA (perhaps
the user's corporate facility).
E-5 - A call transfer between response centers MUST NOT be Motivation: [RFC3261] forbids the removal of a message body part,
considered a violation of the distribution privacy attribute and the proxy may not have all the relevant information as
contained within the location object. to why location was included in this message (meaning it
might need to be there), and should not remove this
critical piece of information.
This transfer will likely be for legitimate reasons; for example, Proxy-2 Proxy servers MUST be capable of adding a Location header
the session was misrouted to the wrong PSAP, and is referred during processing of SIP requests.
[RFC3515] to the correct one. Of there might have been an overload
condition in which more calls were directed to a PSAP than if could
handle efficiently, so some of the calls were diverted to another
PSAP.
E-6 Location information MUST be transmitted, if known to the UAC, Motivation: If the proxy determines a message needs to have the
in all calls to a PSAP, even in the case the location location of the UAC in the message, and knows the UAC's
information known to the UAC is not considered reliable by the location by-reference, it must be able to add this header
UAC. and URI to the message during processing. This MUST NOT
violate requirement Proxy-3 below.
With that in mind, it is important to distinguish the location Proxy-3 If a Proxy server detects "location" already exists within
information learned locally from location information learned over a a SIP message, it MUST NOT add another location header or
VPN; which in itself is useful additional information to that PSAP location body to the message.
operator.
E-7 The UA must provide the actual location of the endpoint, and Motivation: This may lead to confusion, and should be left for the
not location which might have been erroneously given to it by, UAC to do on purpose.
e.g. a VPN tunnel DHCP server.
E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a Proxy-4 There MUST be a unique 4XX error response code informing
session. If this is supported by the UAC, all NOTIFY messages the UAC it did not provide applicable location information.
MUST contain the UAC's location information.
This is a means for the emergency response centers to maintain a 4. Location Conveyance Using SIP
location the callers in distress, even if the UA were to move, even
if the caller does not indicate there was a move. This lets the
PSAP determine what it considers to be "movement", and leaves that
decision out of the user's.
E-9 It MUST be possible that any UAC supporting E-8 be informed of RFC 4119 defines the PIDF-LO location object to be inside a RFC 3693
this subscription, as this will provide a means of alert to the defined "using protocol" message from one entity to another entity.
user who does not wish this capability to remain enabled. For SIP location conveyance, using the PIDF-LO body satisfies the
entire format and message-handling requirements as stated in the
baseline Geopriv Requirements [RFC3693].
7. Location Conveyance using SIP Although a PIDF-LO is to be used to indicate location of a UA, the
actual PIDF-LO does not need to be contained in the message itself,
it can be as a by-reference URI in a SIP header or message body
part, pointing to the PIDF-LO of that UA on a remote node.
Geopriv is the IETF working group assigned to define a Location Section 26 of [RFC3261] defines the security functionality SIPS for
Object for carrying within another protocol to convey geographic transporting SIP messages with either TLS or IPSec, and S/MIME for
location of an endpoint to another entity. This Location Object
will be supplied within SIP to convey location of a UA (or user of a
UA). The Location Object (LO) is defined in [ID-PIDF-LO]. Section
26 of [RFC3261] defines the security functionality SIPS for
transporting SIP messages with either TLS or IPsec, and S/MIME for
encrypting message bodies from SIP intermediaries that would encrypting message bodies from SIP intermediaries that would
otherwise have access to reading the clear-text bodies. For UA-to- otherwise have access to reading the clear-text bodies. SIP
UA location conveyance, using the PIDF-LO body satisfies the entire endpoints MUST implement S/MIME to encrypt the PIDF-LO message body
format and message-handling requirements as stated in the baseline (part) end-to-end. The SIPS-URI from [RFC3261] SHOULD be used for
Geopriv Requirements [RFC3693]. SIP entities that will carry an LO message protection (message integrity and confidentiality) and MUST
MUST implement S/MIME for encrypting on an end-to-end basis the be used when S/MIME is not used (when not violating the requirements
location of a user agent, satisfying [RFC3693]'s security for emergency messaging detailed in section 3 of this document).
requirements. The SIPS-URI from [RFC3261] SHOULD also be used for The entities sending and receiving location MUST obey the privacy
further message protection (message integrity, authentication and and security rules in the PIDF-LO to be compliant with this
message confidentiality) and MUST be used when S/MIME is not used specification.
(when not violating the requirements for emergency messaging
detailed in section 6 of this document). The entities sending and
receiving the LO MUST obey the privacy and security instructions in
the LO to be compliant with this specification.
Self-signed certificates SHOULD NOT be used for protecting LI, as
the sender does not have a secure identity of the recipient.
Several LOs MAY be included in a body. If the message length
exceeds the maximum message length of a single packet, session mode
is to be used.
Several SIP Methods are capable (and applicable) to carry the LO Self-signed certificates SHOULD NOT be used for protecting PIDF-LO,
message body. The Methods are divided into two groups, one for as the sender does not have a secure identity of the recipient.
those applicable for UA-to-UA location conveyance, and the other
group for UA-to-Proxy Location conveyance for routing the message.
The list of applicable Methods for UA-to-UA location conveyance is: More than one location representation or format MAY be included in
the same message body part, but all MUST point at the same position
on the earth (altitude not withstanding), as this would confuse the
recipient by pointing at more than one position within the same
PIDF-LO. There MAY be a case in which part of one location format
and part of another exist in the same message body part. These all
still MUST point at the same position on the earth, yet are
incomplete within their own format. For example, there maybe be a
latitude and longitude in coordinate format and a civic altitude
value to complete a 3-dimenttional position of a thing (i.e. which
floor of a building the UA is on in a building at a particular
lat/long coordinate pair).
INVITE, There MAY be several PIDF-LOs in separate message body parts in the
OPTIONS, same message, and each MAY point at different positions on the earth
UPDATE, (altitude not withstanding). If the message length exceeds the
MESSAGE, maximum message length of a single packet (1300 bytes), TCP MUST to
SUBSCRIBE/NOTIFY, and be used for proper message fragmentation and reassembly.
PUBLISH.
The list of applicable Methods for UA-to-Proxy location conveyance Several push-based SIP Request Methods are capable (and applicable)
is: of carrying location, including:
INVITE, INVITE,
REGISTER,
UPDATE, and UPDATE, and
MESSAGE MESSAGE,
While the authors do not yet see a reason to have location conveyed While the authors do not yet see a reason to have location conveyed
in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a
reason to prevent carrying a LO within these Method Requests as long reason to prevent carrying a PIDF-LO within these Method Requests as
as the SIP message meets the requirements stated within this long as the SIP message meets the requirements stated within this
document. Discussing Location in the PUBLISH Request Method will be
for another document.
SIP Methods such as SUBSCRIBE and NOTIFY are considered a pull-based
location retrieval mechanism, and are therefore not part of this
document. document.
A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the
provided its location in the INVITE, but this is not something UAC that provided its location in the original request, but this is
that can be required due to the timing of the INVITE to 200 OK not something that can be required due to the timing of the request
messages, with potential local/user policy requiring the called user to 200 OK messages, with potential local/user policy requiring the
to get involved in determining if the caller is someone they wish to called user to get involved in determining if the caller is someone
give location to (and at what precision). they wish to give their location to (and at what precision).
For UA-to-Proxy location conveyance, there are two cases: one in 4.1 New Option Tags and a Location Header Created
which all proxies in the path from the UA to the proxy that requires
location can be trusted with the LI, and one in which intermediate
proxies may not be trusted. The former may be implemented with
"hop-by-hop" security as specified in [RFC3261] using sips: (i.e.
TLS security). In particular, emergency call routing requires This document creates and IANA registers two new option tags,
routing proxies to know the location of the UAC, and sips: "location" or "unknown-location". User agent clients who support
protection is appropriate. The latter case is under study by the this specification will indicate that support by including either of
SIPPING working group under the subject "End to Middle" security these option-tags in a Supported header.
[ID-End-Mid-Sec].
Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to This document also creates and IANA registers a new Location header.
convey location, SIP entities MUST adhere to the rules of [RFC3693], The Location header, if present, will have one of three header
specifically the retention and distribution (privacy) attributes of values defined by this document:
a UA's location. When Alice is deciding how to transmit her
location, she should be keenly aware of the parameters in which she
wants her location to be stored and distributed by who she transmits
her location to. However, once she sends that location information
to Bob, he MUST also now obey Alice's wishes regarding these privacy
attributes if he is deciding to inform another party about Alice.
This is a fundamental principle of the Geopriv Working Group, i.e.
"PRIVACY".
7.1 Indicating Support for Location by the UAC o a Location-by-reference URI
User agent clients who supports this specification will indicate o a Content ID indicating where location is within the message body
that support in two ways, by including two headers in all messages
conveying location of any kind specified here: a new "Location"
header, and the Supported Header indicating "location" as the value
of the header. SIP Requests lacking this combination will indicate
to SIP intermediaries that determine there is a problem with a SIP
Request that should contain location information whether any of
their responses will have a chance at successful understanding. In
other words, does the UAC have location clue, or not? If not,
because the SIP Request from that UAC didn't include these headers,
the intermediary will not rely on the UAC to correct the problem,
and will do what it can to fix the problem without the UAC. More on
this in section 8 of this document.
Location inclusion within a SIP Request will be by-value or by- o a location based option tag
reference. By-value is the case in which the location information
of the UAC is included or contained within the SIP message itself.
By-reference is the case in which the location of the UAC is in a
database (record or document) somewhere else, but the UAC knows the
URI to that record/document and includes only that URI in the SIP
Request, in the location header.
A UAC that conforms with this specification will include within this A location-by-reference URI is a pointer to a record on a remote
INVITE message an indication that it understands what "location" node containing the PIDF-LO of a UA.
means, that it is necessary to convey location in this INVITE
message, and understands any location based rejection responses from If the PIDF-LO of a UA is contained in a SIP message, a Location
the SIP intermediary. There are two new 4XX level Responses defined header will be present in the message with a content-ID (cid-url)
later in this document. This indication is a new "Location" header [RFC2392] indicating where in the message body location is for this
with the following syntax: UA. This is to aid a node in not having to parse the whole message
body or body parts looking for this body type.
The Unknown-Location option tag in a Location header indicates a UA
understands the concept of location conveyance, but does not have
its location to provide. This can save error messages from being
generated looking for an answer the UA does not have to give. It
can also allow a processing entity the immediate knowledge it needs
to act as if the UA will not learn location on its own, and perhaps
call on another process to address the location needs for that
message.
The purpose of the Location option-tag is to indicate support for
this document in the Requires, Supported and Unsupported headers.
It gives a UAS the proper means to indicate it does not support the
concept of location in an Unsupported header in a response message
that might otherwise not be clear that the lack of support for
location is the problem with the request message.
The new "Location" header has the following BNF syntax:
Location = "Location" HCOLON Location-value *(COMMA Location = "Location" HCOLON Location-value *(COMMA
Location-value) Location-value)
location-value = (addr-spec / option-tag / token) location-value = (addr-spec / option-tag / token)
addr-spec = cid-url / absoluteURI addr-spec = cid-url / absoluteURI
option-tag = string option-tag = string
token = token / quoted-string token = token / quoted-string
cid-url = cid-url = "cid" ":" content-id /
absoluteURI = absoluteURI = SIP or SIPS-URI
content-id = url-addr-spec
IANA Registered Option-tags are: loc-body, civic-loc, geo-loc, url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
convey-uac, convey-uas, unknown
- "loc-body" identifies location is present in the message body of
this message, but gives no indication which format it is in, or
even if it is visible to the SIP element viewing the message.
- "civic-loc" identifies the format of location included, or
desired.
- "geo-loc" identifies the format of location included, or desired.
- "convey-uac" identifies in a message for the receiver of this
message to forward the sender's location information to another
UA.
This convey-uac is telling the UAS of this transaction to convey the
location of the UAC of this transaction to another UA. This is most
clearly applicable in a REFER transaction (see section 8.3).
- "convey-uas" identifies to a UAS within a transaction to convey
its location to the UAC of that transaction, or to a third party
UA (see section 8.3 for this latter example involving REFER).
This convey-uas indication is both a request for a UAS to respond to
the UAC with the UAS's location (see section 8.1) and a request for
a UA to send location information somewhere else (see section 8.3).
Civic-loc and geo-loc are defined as being "desired" (not known yet)
because each can be placed in a location header within an OPTIONS
Request message to learn the UAC's location. See section 8.2 for
the details of this.
- "unknown" indicates the UAC understands the concept of location, The Content-ID (cid) is defined in [RFC2392] to locate message body
but does not have knowledge of where it is to include in the parts.
message.
Unknown is a case in which the UAC is asking for help of any The absoluteURI is the SIP or SIPS URI of the location-by-reference,
intermediary to populate a location header with a by-reference URI, which points at a PIDF-LO of a UA in a record on a remote node.
or to return a 425 (Retry Location Body) response that includes a
PIDF-LO message body that describes the location for that UAC to be
used at a later time. The intermediary that responds to this query
could become the UAS target for future OPTIONS requests.
The following table extends the values in Table 2/3 of RFC3261 The following table extends the values in Table 2/3 of RFC3261
[RFC3261]. [RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- ----------------------------------------------------------------
Location Rr amdr o - - o o o - Location Rr ar 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
---------------------------------------------------------------- ----------------------------------------------------------------
Location Rr amdr o o o o o o o Location Rr ar - - o o o o -
The Location header MAY be added, modified, read or deleted if The Location header MAY be added, or read if present in a Request
present in a Request message listed above. Deleting a location message listed above. A proxy MAY add the location header in
header appears detrimental for communicating a necessary piece of transit if one is not present. [RFC3261] states message bodies
information described throughout this document, unless this is an cannot be added by proxies. A proxy MAY read the location header in
act of hiding that information. Modifying this header, other than transit if present.
correcting the header of some error, appears to cause more harm than
good, and is ill advised. Unless from the SIP Proxy/intermediary It is RECOMMENDED that only one Location header be in the same
generating an error response (see section 7.2), the location header message, but this is not mandatory. That said, there MUST NOT be
SHOULD NOT be modified or deleted if present in a Response. Only more than one cid-url pointing to a location message body (part) in
the intermediary that is originating the header value in the a SIP message, regardless of how many Location headers there are in
response SHOULD add a location header, if one is not yet present. that message. There MUST NOT be more than one location by-reference
A Proxy/intermediary MAY add the location header in transit if one URI in any SIP message, regardless of how many Location headers
is not present. A Proxy/intermediary MAY read the location header there are in a message.
in transit if present.
Here is an example INVITE that includes the proper Location and Here is an example INVITE that includes the proper Location and
Supported headers (with a reduced size multipart message body): Supported headers (without the PIDF-LO message body part):
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Location: cid: alice123@atlanta.example.com, geo-loc Location: cid:alice123@atlanta.example.com
Supported: location Supported: location
Accept: application/sdp, application/cpim-pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com> Contact: <sip: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
...SDP here ...SDP here
skipping to change at page 4, line 771 skipping to change at page 15, line 45
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com> Contact: <sip: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
...SDP here ...SDP here
--boundary1 --boundary1
Content-Type: application/cpim-pidf+xml Content-Type: application/pidf+xml
Content-ID: alice123@atlanta.example.com Content-ID: alice123@atlanta.example.com
...PIDF-LO with geolocation coordinates here ...PIDF-LO with geo-location coordinates here
--boundary1-- --boundary1--
The location header from the above INVITE: The location header from the above INVITE:
Location: cid:alice123@atlanta.example.com, geo-loc Location: cid:alice123@atlanta.example.com
indicates the Content-ID location [RFC2392] within the multipart indicates the Content-ID location [RFC2392] within the multipart
message body of were location information is. The geo-loc option- message body of were location information is.
tag indicates the location format within the PIDF-LO message body.
If both geo-loc and civic-loc formats were present in the PIDF-LO,
the UAC SHOULD include both option-tags if it includes either. The
UAC MAY NOT include either option-tag indicating the format of
location within the message body.
If the Location header were this instead: If the Location header were this instead:
Location: <server5@atlanta.example.com/alice123>, geo-loc Location: <server5@atlanta.example.com/alice123>
this would indicate location by-reference was included in this this would indicate location by-reference was included in this
message, and in the geo-loc format for whoever fetches it. message. It is expected that any node wanting to know where user
alice123 is would fetch the PIDF-LO from the server5 URI.
More than one location by-value message body-part MAY be included in
the same SIP message.
7.2 Location Rejection Responses
Two new 4XX Response messages are created here:
- '424 Bad Location Information' - indicates the location in the SIP
Request message was bad.
- '425 Retry Location Body' - indicates to the UAC that location in
the SIP Request message was bad and this response has a new PIDF-
LO location-by-value to be stored in the UAC for future use.
7.2.1 The 424 "Bad Location Information" Error Code 4.2 424 (Bad Location Information) Response Code
In the case that a UAS or SIP intermediary detects an error In the case that a UAS or SIP intermediary detects an error
in a Request message specific to the location information supplied in a Request message specific to the location information supplied
by-value or by-reference, a new 4XX level error is called for to by-value or by-reference, a new 4XX level error is created here to
indicate this is the problem with the message. This document indicate this is the problem with the request message. This
creates the new error code: document creates the new error code:
424 (Bad Location Information) 424 (Bad Location Information)
The 424 Bad Location Information Response code is a rejection of the The 424 (Bad Location Information) Response code is a rejection of
location contents, whether by-value or by-reference of the original the location contents, whether by-value or by-reference of the
SIP Request. The server function of the recipient (UAS or original SIP Request. The server function of the recipient (UAS or
intermediary) had deemed this location by-reference or location by- intermediary) has deemed this location by-reference or location by-
value to be bad. No further action by the UAC is expected. The UAC value to be bad. No further action by the UAC is required. The UAC
can use whatever means it knows to verify/refresh its location can use whatever means it knows to verify/refresh its location
information before attempting the Request again. information before attempting a new request. There is no cross-
transaction awareness expected by either the UAS or SIP intermediary
This new error code will be IANA registered. as a result of this error message.
7.2.2 The 425 "Retry Location Body" Error Code
In the case that a UAS or SIP intermediary detects an error
in a Request message specific to the location information supplied
by-value or by-reference within that message, and both has the
location by-value of that UAC stored locally and wants to transmit
this value to the UAC, a new 4XX level error need is called for to
indicate this. This document creates the new error code:
425 (Retry Location Body)
The 425 Retry Location Body Response code is a rejection of the by-
value or by-reference location contained in the original SIP
Request. The 425 Response will contain a application/cpim-pidf+xml
encoded message body to be stored in the UAC for future use. This
will typically be incorporated into the subsequent SIP Request from
the UAC that received the 425 Response to the previous message
attempt.
The UAC SHOULD include this PIDF-LO message body in the subsequent
Request message towards that same intermediary - as it felt strong
enough to reject the last message that had bad location information
to send the UAC new location information.
This new error code will be IANA registered.
An example flow of this scenario will be included in section 9 of This new error code will be IANA registered in Section 10.
this document.
7.3 Example PIDF-LO in Geo Format 4.3 Example PIDF-LO in Geo Format
This subsection will show a sample of what just the PIDF-LO can look This subsection will show a sample of what just the PIDF-LO can look
like, as defined in [ID-PIDF-LO]. Having this here will first offer like, as defined in [RFC4119]. Having this here will first offer a
a look at a location by-value message body, and secondly, give the look at a location by-value message body, and secondly, give readers
authors the ability to show how large this is to persuade readers an appreciation for how large a location message body is so that
that this doesn't have to be shown in every example of this this document does not have to show a PIDF-LO in every message flow
document. Full example message flows will be in the appendixes of example. This section shows a coordinate position based PIDF-LO.
this document. Section 4.4 shows this same position in a civic address format.
Full example message flows will be left for another document.
Whether this PIDF-LO message body is S/MIME encrypted in the SIP Whether this PIDF-LO message body is S/MIME encrypted in the SIP
message or not, the PIDF-LO stays exactly the same. There is no message or not, the PIDF-LO stays exactly the same. There is no
change to its format, text or characteristics. Whether TLS or IPsec change to its format, text or characteristics. Whether TLS or IPSec
is used to encrypt this overall SIP message or not, the PIDF-LO is used to encrypt this overall SIP message or not, the PIDF-LO
stays exactly the same. There is no change to its format, text or stays exactly the same. There is no change to its format, text or
characteristics. The examples in section 7.3 (Geo format) taken characteristics. The examples in section 4.3 (Geo format) taken
from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for
the exact same position on the earth. The civic formatted PIDF-LO the exact same position on the Earth. The differences between the
is a little larger (i.e. more lines), but this is not substantial. two formats is within the <gp:location-info> are of the examples.
The differences between the two formats is within the <gp:location- Other than this portion, of each PIDF-LO, the rest the same for both
info> are of the examples. Other than this portion of each PIDF-LO, location formats.
the rest the same for both location formats.
<?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:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-08-01T10:00:00Z</timestamp> <timestamp>2006-03-20T14:00:00Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326"> <gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>33.001111N <gml:coordinates>33.001111N
96.68142W</gml:coordinates> 96.68142W</gml:coordinates>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<method>dhcp</method> <method>dhcp</method>
<provided-by><nena>www.cisco.com</nena></provided-by/> <provided-by><nena>www.cisco.com</nena></provided-by/>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention- <gp:retention-expiry>2006-03-24T18:00:00Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
7.4 Example PIDF-LO in Civic Format 4.4 Example PIDF-LO in Civic Format
This subsection will show a sample of what just the PIDF-LO can look This subsection will show a sample of what just the PIDF-LO can look
like, as defined in [ID-PIDF-LO]. Having this here will first offer like, as defined in [RFC4119]. Having this here will first offer a
a look at a location by-value message body, and secondly, give the look at a location by-value message body, and secondly, give readers
authors the ability to show how large this is to persuade readers an appreciation for how large a location message body is so that
that this doesn't have to be shown in every example of this this document does not have to show a PIDF-LO in every message flow
document. Full example message flows will be in the appendixes of example. This section shows a civic address based PIDF-LO. Section
this document. 4.3 shows this same position in a coordinate format. Full example
message flows will be left for another document.
Whether this PIDF-LO message body is S/MIME encrypted in the SIP Whether this PIDF-LO message body is S/MIME encrypted in the SIP
message or not, the PIDF-LO stays exactly the same. There is no message or not, the PIDF-LO stays exactly the same. There is no
change to its format, text or characteristics. Whether TLS or IPsec change to its format, text or characteristics. Whether TLS or IPSec
is used to encrypt this overall SIP message or not, the PIDF-LO is used to encrypt this overall SIP message or not, the PIDF-LO
stays exactly the same. There is no change to its format, text or stays exactly the same. There is no change to its format, text or
characteristics. The examples in section 7.3 (Geo format) taken characteristics. The examples in section 4.3 (Geo format) taken
from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for
the exact same position on the earth. The civic formatted PIDF-LO the exact same position on the Earth. The differences between the
is a little larger (i.e. more lines), but this is not substantial. two formats is within the <gp:location-info> are of the examples.
The differences between the two formats is within the <gp:location- Other than this portion, of each PIDF-LO, the rest the same for both
info> are of the examples. Other than this portion of each PIDF-LO, location formats.
the rest the same for both location formats.
<?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:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-08-01T10:00:00Z</timestamp> <timestamp>2006-03-20T14:00:00Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civilAddress> <cl:civilAddress>
<cl:country>US</cl:country> <cl:country>US</cl:country>
<cl:A1>Texas</cl:A1> <cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3> <cl:A3>Colleyville</cl:A3>
<cl:HNO>3913</cl:HNO> <cl:HNO>3913</cl:HNO>
<cl:A6>Treemont</cl:A6> <cl:A6>Treemont</cl:A6>
<cl:STS>Circle</cl:STS> <cl:STS>Circle</cl:STS>
<cl:PC>76034</cl:PC> <cl:PC>76034</cl:PC>
<cl:LMK>Polk Place</cl:LMK> <cl:LMK>Polk Place</cl:LMK>
<cl:FLR>1</cl:FLR> <cl:FLR>1</cl:FLR>
<cl:civilAddress> <cl:civilAddress>
</gp:location-info> </gp:location-info>
<method>dhcp</method> <method>dhcp</method>
<provided-by><nena>www.cisco.com</nena></provided-by/> <provided-by><nena>www.cisco.com</nena></provided-by/>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention- <gp:retention-expiry>2006-03-24T18:00:00Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
8. User Agent-to-User Agent Location Conveyance 5. SIP Element Behavior When Conveying Location
The offered solution here for the User-to-User location conveyance The SIP Request Methods that MUST convey location are the INVITE,
between UAs is used with the INVITE, OPTIONS, UPDATE, MESSAGE, REGISTER, UPDATE and MESSAGE Methods. It is not forbidden by this
SUB/NOT and PUBLISH Methods in the following subsections. document to convey location with any other SIP method. However, no
other methods are detailed here.
All complete message flows in this document will be with well-formed The message flows in this document will be example messages
SIP messages. That said, there will be a few individual example containing only the key headers to convey the point being made that
messages containing only the key headers to convey the point being do not include all the requisite SIP headers. All well formed SIP
made that do not include all the requisite SIP headers. As you will message flows are to be in a separate document for brevity here.
see in the following section (8.1), a well-formed SIP message
containing a PIDF-LO is quite large (at least 59 lines of text), and
will likely be overload to most readers if written for every example
here (given how many examples there are). All well formed SIP
message flows are in separate appendixes at the end of this document
for brevity here.
8.1 UA-to-UA using INVITE Method 5.1 Location Conveyance Using the INVITE Method
Below is a common SIP session set-up sequence between two user Below is a common SIP session set-up sequence between two user
agents. In this example, Alice will provide Bob with her geographic agents. In this example, Alice will provide Bob with her location
location in the INVITE message. in the INVITE message.
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | [M1] INVITE |
|---------------------------------------->| |---------------------------------------->|
| 200 OK [M2] | | [M2] 200 OK |
|<----------------------------------------| |<----------------------------------------|
| ACK [M3] | | [M3] ACK |
|---------------------------------------->| |---------------------------------------->|
| RTP | | RTP |
|<=======================================>| |<=======================================>|
| | | |
Figure 1. UA-UA with Location in INVITE Figure 1. Location Conveyance in INVITE Requests
User agent Alice invites user agent Bob to a session [M1 of Figure User agent Alice invites user agent Bob to a session [M1 of Figure
1]. 1].
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Supported: Location Supported: Location
Location: loc-body, geo-loc Location: cid:alice123@atlanta.example.com
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
- Within this INVITE is a multipart body indication that it is
S/MIME encrypted [according to the rules of RFC3261] by Alice for
Bob. One body part contains the SDP offered by Alice to Bob.
Alice's location (here coordinate based) is the other body part
contained in this INVITE.
Within the message body is this:
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
...
--boundary1
Content-type: application/cpim-pidf+xml
PIDF-LO
--boundary1--
- Bob responses with a 200 OK [M2] (choosing a codec as specified by
the Offer/Answer Model [RFC3264]). Bob can include his location
in the 200 OK response, but this shouldn't be expected to due to
user timing. If Bob wants to provide his location to Alice after
the 200 OK, but before a BYE, the UPDATE Method [RFC3311] should
be used.
Bob also has Alice's location once he decrypts the S/MIME (in
conjunction with decrypting if for the SDP message body).
In this message, Alice decided to include the Supported and
Location headers in the SIP headers even though SIP intermediaries
would not be able to view the information. This SHOULD be
configurable, based on local policy for revealing such information
hints.
If Alice wanted to know Bob's location, she could have included in
the existing Location header an option-tag of "convey-uas". This is
the indication to the UAS within this transaction, in this case Bob,
to return his location in the 200 OK if he chooses too. This
request MAY prompt Bob, the user, of the request, and wait for him
to indicate to his UA whether he would want his location included in
the 200 OK.
- Alice's UA replies with an ACK and the session is set up.
Figure 1. does not include any Proxies because in it assumed they
would not affect the session set-up with respect to whether or not
Alice's location is in a message body part, and Proxies don't react
to S/MIME bodies, making their inclusion more or less moot and more
complex than necessary.
The most relevant message in Figure 1 having to do with location is
(obviously) the message with the location object in it [M1]. So to
cut down on length of this document, only the INVITE message in this
example will be shown. Section 8.1.1 will give an example of this
well formed INVITE message using a Coordinate location format.
Section 8.1.2 will give an example of this well formed INVITE
message using the civic location format.
8.1.1 UA-to-UA INVITE Request with Geo Location Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1.
[Message 1 in Figure 1]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
[Alice's Geo PIDF-LO goes here]
--boundary1--
8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases
where hop-by-hop security is deployed.
[Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--broundary1
Content-type: application/cpim-pidf+xml
[Alice's Geo PIDF-LO goes here]
--boundary1--
8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1 using the civic location format.
[Message 1 in Figure 1] If the message were S/MIME encrypted, this would be the Content-type
header:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime; Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
[Alice's Civic PIDF-LO goes here]
8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in If this INVITE were not S/MIME encrypted, this would be the
Figure 1 in section 8.1. This message is here to show that although Content-Type header:
the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases
where the sending user does not wish to use security mechanisms in
transmitting their coordinate location.
[Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--broundary1
Content-type: application/cpim-pidf+xml
[Alice's Civic PIDF-LO goes here]
8.1.3 UA-to-UA Location Conveyance Involving 3 Users
As stated in [RFC3693], the distribution indication within the PIDF-
LO provides the information regarding if a learned PIDF-LO of
another UA can be given out or not. The distribution element within
the PIDF-LO looks like this:
<gp:retransmission-allowed>no</gp:retransmission-allowed>
The values within this element are either "yes" or "no".
The element within the PIDF-LO indicating how long this location
information is to be considered good/reliable for is the location
expiration element, which looks like this:
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-expiry>
So, if Bob's location, which was transmitted to Alice, has not
reached the expiration time, and Bob set his distribution indication
to "can redistribute", then when Bob refers Alice to call Carol,
Alice can include both hers and Bob's LOs in that new INVITE (from
Alice to Carol). This will tell Carol where both Alice and Bob are.
Bob should be conscious of this capability when setting his
distribution indication with any location conveyance transmission.
Consider the following example message flow [Figure 1a] to show a
3-way communication of location, coupled with how a UA can include
someone else's location.
UA Alice Bob Carol
| INVITE [M1] | |
|---------------------------->| |
| 200 OK [M2] | |
|<----------------------------| |
| ACK [M3] | |
|---------------------------->| |
| RTP | |
|<===========================>| |
| reINVITE (hold) [M4] | |
|<----------------------------| |
| 200 OK [M5] | |
|---------------------------->| |
| REFER (Refer-to:Carol) [M6] | |
|<----------------------------| |
| NOTIFY [M7] | |
|---------------------------->| |
| 200 OK [M8] | |
|<----------------------------| |
| INVITE [M9] |
|------------------------------------------>|
| 200 OK [M10] |
|------------------------------------------>|
| RTP |
|<=========================================>|
| NOTIFY [M11] | |
|---------------------------->| |
| 200 OK [M12] | |
|<----------------------------| |
| BYE [M13] | |
|<----------------------------| |
| 200 OK [M14] | |
|---------------------------->| |
| |
Figure 1a. UA-to-UA with Location in REFER
M1 - Alice presents her location in the INVITE to Bob; The obvious reason this for a multipart/mixed Content-Type is that
this is an INVITE message and there is an SDP message body part
included. This is not mandatory, but highly likely. The cid-url in
the Location header points a parsing entity that can view the
message body to where the PIDF-LO is in the message.
INVITE sips:bob@biloxi.example.com SIP/2.0 Within the non-S/MIME message body is this:
To: Bob
From: Alice
Supported: location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
... ...
--boundary1 --boundary1
Content-type: application/cpim-pidf+xml Content-type: application/pidf+xml
[Alice's geo formatted PIDF-LO goes here] PIDF-LO
--boundary1-- --boundary1--
M2 - Bob 200 OKs this INVITE and includes his location back to Alice In the INVITE, Alice's UAC included the Supported header with the
(with his distribution indication set to "yes"). location option tag, and the Location header with the cid:url
pointing at the by-value PIDF-LO. These two headers MAY be hidden
If Alice included a location header with a "convey-uas" option-tag: in the S/MIME encrypted message body next to the topmost
Content-Type header to hide the fact that this message is carrying
INVITE sips:bob@biloxi.example.com SIP/2.0 location in transit. Bob's UAS, the destination UA of Alice's
Location: convey-uas message, will read these headers when deciphering the overall
message body.
Bob SHOULD feel compelled to reply with his location to Alice. If
Bob doesn't understand this request, Bob returns an Unsupported
header with "location" if his UA doesn't understand location, or
just "convey-uas" if his UA does understand location but doesn't
know his location, or cannot process the request in time for the 200
OK return.
M6 - Bob then directs Alice to contact Carol using a REFER Request
(RFC3515].
The REFER is used in this message sequence, but it does not carry
anyone's location within the REFER message. UAs SHOULD be prepared
to receive a PIDF-LO message body in a REFER Method Request,
although this doesn't seem likely. Nothing here prevents that from
occurring. If Bob didn't return his location in the 200 OK, but
still wants to convey his location to Alice to send to Carol, he can
include the PIDF-LO in the REFER. Bob can include the following
header in the REFER to tell Alice to tell Carol both of their
locations:
REFER sips:alice@atlanta.example.com SIP/2.0
Location: convey-uac, convey-uas
The [M11] NOTIFY message from Alice to Bob MAY confirm to Bob that
Alice did indeed convey both UA's locations.
If Alice accepted the transaction request of the REFER in a 202
Accepted message, but didn't include her location in the subsequent
INVITE to Carol, her 202 Accepted message would have this header in
it:
[M7]
SIP/2.0 202 Accepted
To: Alice
From: Bob
Unsupported: convey-uac
This indicates to Bob his request was partially fulfilled. Bob
knows his location was conveyed to Carol and that his REFER Request
was accepted, but Alice chose not to send Carol her location
information.
Regardless of Bob's request in the REFER, if he set his retention
indication to "no", Alice MUST NOT forward Bob's location to Carol,
even if he asked her to. This document currently doesn't have a
granular enough indication from Alice to Bob to tell Bob this piece
of information.
8.2 OPTIONS Method and Location
The OPTIONS Method can be used by a UAC to learn its location from a
SIP intermediary that may know this information, or to request the
location of a UAS. A combination of the location header option-tags
in an OPTIONS query can achieve this.
8.2.1 OPTIONS Request to Learn UAC's Location
If Alice knows which server knows her location, perhaps because her
UA was either configured with this server manually or through
registration to the network, she can send an OPTIONS query to it to
learn her location. Take the following message flow as an example:
UA Alice Server1
| OPTIONS [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
Figure 2a. OPTIONS Request for Location
A non-well-formed message example of how an OPTIONS Method Request
could be used to query a server for the UAC's location might be:
[M1 of Figure 2a]
OPTIONS sips:server1@atlanta.example.com SIP/2.0
To: server1
From: Alice
Proxy-Require: location
Require: location
Location: unknown, geo-loc
Including both the "unknown" and "geo-loc" option-tags in the
Location header indicates the UAC wants to learn its location in the
geo format only. If the Location header were:
OPTIONS sips:server1@atlanta.example.com SIP/2.0
To: server1
From: Alice
Proxy-Require: location
Require: location
Location: unknown, geo-loc, civic
the UAC is asking for both formats to be in the reply.
The key to this request is the "unknown" option-tag. This, in an
OPTIONS Request, if telling the server the UAC doesn't know its
location, and to include the UAC's location in the 200 OK Response.
The presence or lack of presence of other option-tags indicate to
the server how its response will be formed. If no other option-tags
are present in the Location header of this OPTIONS Request, the
server is free to choose whatever format it wishes in the reply.
In the above partial OPTIONS Request, there is a Proxy-Require
header (if the intermediary is a Proxy) and a Require header (if the
intermediary is an instance of a B2BUA). If either apply to the
responding UAS in this transaction, and the location header included
an option-tag the UAS cannot answer, perhaps because it doesn't have
the UAC's civic location format, the 200 OK to this Request will
include what location format(s) is has, and indicates it does not
have the remainder of the request with the Unsupported header
indicating which formats were requested, but not available. An
example of this is the following partial SIP message;
[M2 in Figure 2a]
SIP/2.0 200 OK
To: server1
From: Alice
Unsupported: civic-loc
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
If location is to be returned as a by-reference location header
value, a subset of the 200 OK could look like this:
[M2 of Figure 2a]
SIP/2.0 200 OK
To: server1
From: Alice
Location: <www.atlanta.example.com/server1/alice123>
The above 200 OK example MAY include an additional option-tag
indicating the format or the location at that by-reference URI.
An OPTIONS Request for the location of the UAC MAY be 401
(Unauthorized) or 407 (Proxy Authentication Required) challenged.
An OPTIONS Request can be redirected to a server that knows the - If Bob's UA wants to join the call, his UA responses with a 200 OK
UAC's location. [M2]. Bob can include his location in the 200 OK response, but
this shouldn't be expected to due to user timing.
A 424 (Bad Location) is the proper indication if the queried server A 424 (Bad Location Information) Response with a Unsupported header
has no knowledge of the UAC's location. An Unsupported header MUST (option tag of 'location') is the proper response if Bob's UA cannot
be in this 424 Response indicating "location" was not supported. display this information, but does understand the concept of
location.
[alternate M2 in Figure 2b] [Alternative M2 of Figure 2]
SIP/2.0 424 (Bad Location Information) SIP/2.0 424 Bad Location Information
To: server1 To: Bob <sips:bob@biloxi.example.com>
From: Alice From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Unsupported: location Unsupported: location
8.2.2 OPTIONS Request to Learn UAS's Location - If Bob's UA accepts with a 200 OK message, Alice's UA replies with
an ACK and the session is set up.
Below is Figure 2b, which shows the OPTIONS Request being used to
query another UA for its location. In this case, it is the UA for
Bob.
UA Alice Bob
| OPTIONS [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
Figure 2b. OPTIONS Request for Location
Here is a non-well-formed example of the OPTIONS Request from Alice
to Bob:
[M1 of Figure 2b]
OPTIONS sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Require: location
Location: geo-loc
In M1 of Figure 2b, Alice queries Bob for his location, and
specifically in his geo format. She has included a Require header
to compel Bob to answer, unless he wishes to reject that inquiry
even if he knows his location. From M1, Bob can do one of the
following:
1) 200 (OK) this with his geo PIDF-LO
2) 488 (Not Acceptable Here), with no further information
3) 488 (Not Acceptable Here), with a Unsupported Header indicating
Bob does not know or understand his geo format, with no further
Information
4) 488 (Not Acceptable Here), with a Unsupported Header indicating
Bob does not know or understand his geo format, but include a
location header indicating he does support the civic-loc format
If Alice did not include a Require header (location), and if Bob
sends option#4 above, Alice can retransmit the OPTIONS Request
indicating the civic format is fine to respond with. Bob SHOULD NOT
send a format not requested unless Alice included a Require header
(with Location) and Bob could not provide location in that format,
but could in another format.
Bob's option#1 200 OK would look like this (non-well-formed)
message:
[M2 in Figure 2b]
SIP/2.0 200 OK
To: Bob
From: Alice
Content-type: application/cpim-pidf+xml
[Bob's geo formatted PIDF-LO goes here]
Bob's option#4 488 (Not Acceptable Here) would look like this (non-
well-formed) message if Bob had his civic location and did not have
his geo location:
[alternate M2 in Figure 2b]
SIP/2.0 488 Not Acceptable Here
To: Bob
From: Alice
Unsupported: geo-loc
Content-type: application/cpim-pidf+xml
[Bob's civic formatted PIDF-LO goes here]
The 424 (Bad Location Information) and 425 (Retry Location Body)
MUST NOT be used in response to an OPTIONS Request. This is because
both of these response codes are for the react to inclusion of
location information in the Request. With OPTIONS, Alice MUST NOT
include her location. Another SIP Method is used for that purpose
(MESSAGE, PUBLISH).
8.3 UA-to-UA Using MESSAGE Method
Anytime a user transmits location information outside a dialog to - If Bob's UA does not accept the INVITE for reasons other than
another user, the MESSAGE Method is to be used. The logic here is location included, a 488 (Not Acceptable Here) may be the
as follows: response.
- UPDATE isn't appropriate because it is for the updating of Figure 1 does not include any Proxies because in it assumed they
session capabilities and parameters of a dialog (after the would not affect the session set-up with respect to whether or not
INVITE included location information). Alice's location is in a message body part, and Proxies do not react
to S/MIME encrypted bodies, making their inclusion more or less moot
and asking for more complex message flows than necessary here.
- reINVITE isn't appropriate because it is only used (or only 5.2 Location Conveyance Using the MESSAGE Method
supposed to be used) for changing the parameters of an existing
dialog, and one might not exist in all cases of location
conveyance.
This leaves MESSAGE as the only viable Request Method for location Alice can choose to merely want to communicate her location to Bob
conveyance outside of a dialog between two users (Alice and Bob in point-to-point, without starting a (voice) conversation, the MESSAGE
this case). The following is an example of this communication. Method MAY be used here.
To comply with privacy concerns raised in [RFC3693] and [ID-PIDF- To comply with privacy concerns raised in [RFC3693] and [RFC4119], a
LO], a MESSAGE Method Request including a location message body MESSAGE Method Request would be built according to [RFC3428] that
SHOULD S/MIME encrypt the message body (part) under the rules includes a location message body. S/MIME encryption SHOULD be used
outlined in [RFC3261]. This is not generally possible if the on the message body (part), as outlined in [RFC3261]. Figure 2 here
location is conveyed by-reference in a Location header. shows a simplistic MESSAGE method message flow.
Implementers and end-users should be aware of this shortcoming of
this means for location conveyance.
UA Alice UA Bob UA Alice UA Bob
| MESSAGE [M1] | | MESSAGE [M1] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK [M2] | | 200 OK [M2] |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 3. UA-UA with Location in MESSAGE Figure 1. Location Conveyance in MESSAGE Requests
Below is a sample, non-well-formed MESSAGE Method message from Alice Below is a sample, non-well-formed MESSAGE Method message from Alice
to Bob conveying her geo location: to Bob conveying her geo location:
[M1 of Figure 3] [M1 of Figure 2]
OPTIONS sips:bob@biloxi.example.com SIP/2.0 MESSAGE sips:bob@biloxi.example.com SIP/2.0
To: Bob To: Bob
From: Alice From: Alice
Supported: location Supported: location
Location: geo-loc Location: cid:alice123@atlanta.example.com
If the message were S/MIME encrypted, this would be the Content-type
header:
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
If this MESSAGE request were not S/MIME encrypted, this would be the
Content-Type header:
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
--boundary1 --boundary1
Content-Type: text/plain Content-Type: text/plain
Here's my location, Bob? Here's my location, Bob?
--broundary1 --broundary1
Content-Type: application/cpim-pidf+xml Content-Type: application/pidf+xml
Content-Disposition: render Content-Disposition: render
[Alice's geo format PIDF-LO goes here] [Alice's PIDF-LO goes here]
--broundary1-- --broundary1--
The Content-type of M1 here is "multipart/mixed" to have a text The Content-type of M1 here is "multipart/mixed" to have a text
message incorporated into the message. Within the PIDF-LO message message incorporated into the message. Within the PIDF-LO message
body, there is a Content-Disposition of "render" to display this body, there is a Content-Disposition of "render" to display this
location information to Bob when his UA receives it. The cautions location information to Bob when his UA receives it. The cautions
about whether or not Bob actually reads this message are outlined in about whether or not Bob actually reads this message are outlined in
[RFC3428]. [RFC3428].
The 200 OK to M1 of Figure 3 is a simple OK. The 200 OK to M1 of Figure 2 is a simple 200 OK.
A 424 (Bad Location Information) Response with a Unsupported header A 424 (Bad Location Information) Response with a Unsupported header
(stating Location) is the proper response if Bob's UA cannot display (option tag of 'location') is the proper response if Bob's UA cannot
this information, but does understand the concept of location. display this information, but does understand the concept of
location.
[Alternative M2 of figure 3] [Alternative M2 of Figure 2]
SIP/2.0 424 Bad Location Information SIP/2.0 424 Bad Location Information
To: Bob To: Bob
From: Alice From: Alice
Unsupported: location Unsupported: location
If Bob's UA merely does not support that location format, the If Bob is declining the M2 MESSAGE Request message, a 488 (Not
Location header would be: Acceptable Here) is the appropriate response. A Supported header
with a location option tag indicates location was not the reason
[Alternative M2 of figure 3] this message was declined.
SIP/2.0 424 Bad Location Information
To: Bob
From: Alice
Unsupported: geo-loc
This alternative indicates to Alice to send another location format
(civic) if she knows her location in that other format. A
subsequent MESSAGE Request could supply this information to Bob.
If Bob is declining the original M1 MESSAGE Request, a 488 (Not
Acceptable Here) is the appropriate response. This 488 MAY include
a location header indicating he does support the civic-loc format.
[Alternative M2 of figure 3] [Alternative M2 of Figure 2]
SIP/2.0 488 Not Acceptable Here SIP/2.0 488 Not Acceptable Here
To: Bob To: Bob
From: Alice From: Alice
Location: civic-loc Supported: location
8.4 UA-to-UA Location Conveyance Using UPDATE 5.3 Location Conveyance Using the UPDATE Method
The UPDATE Method is to be used any time location information is to The UPDATE Method [RFC3311] is to be used any time location
be updated between UAs setting up a dialog or after the dialog has information is to be updated between UAs setting up a dialog or
been established, no matter how long that dialog has been after the dialog has been established, no matter how long that
operational. reINVITE is out of scope here, and the MESSAGE Method dialog has been operational. reINVITE is inappropriate here, and
is for non-dialog location conveyance between UAs only. The same the MESSAGE Method is for non-dialog location conveyance between UAs
security properties used in the INVITE MUST be used in the UPDATE only. The same security properties used in the INVITE MUST be
message. applied in the UPDATE message.
There are 3 conditions UPDATE is to be used to convey location There are 3 conditions UPDATE is to be used to convey location
between Uas: between UAs:
1) During dialog establishment, but before the final 200 OK (see 1) During dialog establishment, but before the final 200 OK (see
section 8.4.1) section 5.3.1)
2) After dialog establishment, but no prior location information has 2) After dialog establishment, but no prior location information has
been convey (see section 8.4.2), and been convey (see section 5.3.2), and
3) After dialog establishment, when a UA has determined it has moved 3) After dialog establishment, when a UA has determined it has moved
(see section 8.4.3) (see section 5.3.3)
8.4.1 UPDATE Updates Location During Session Establishment 5.3.1 UPDATE Updates Location During Session Establishment
Use#1 of the UPDATE Method is during dialog establishment, Alice Figure 3a. shows the first example of what the UPDATE Method is
updates Bob with her location information. This might be different used: during dialog establishment when Alice updates Bob with her
location information than was in message [M1] of Figure 4a., or it location information [M3]. This might be different location
could be the first time Alice conveys location to Bob. information than was in message [M1] of Figure 3a. or it could be
the first time Alice conveys location to Bob during the dialog
set-up.
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | INVITE [M1] |
|---------------------------------------->| |---------------------------------------->|
| UPDATE [M2] | | UPDATE [M2] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK (UPDATE) [M3] | | 200 OK (UPDATE) [M3] |
|<----------------------------------------| |<----------------------------------------|
| 200 OK (INVITE) [M4] | | 200 OK (INVITE) [M4] |
|<----------------------------------------| |<----------------------------------------|
| ACK (UPDATE) [M5] | | ACK (UPDATE) [M5] |
|---------------------------------------->| |---------------------------------------->|
| RTP | | RTP |
|<=======================================>| |<=======================================>|
| | | |
Figure 4a. UA-UA with Location in UPDATE Figure 3a. Updating Location During Dialog Establishment
[M2 of Figure 4a] [M2 of Figure 3a]
UPDATE sips:bob@biloxi.example.com SIP/2.0 UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob To: Bob
From: Alice From: Alice
Supported: location Supported: location
Location: geo-loc Location: cid:alice123@atlanta.example.com
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v= v=
... ...
--broundary1 --broundary1
Content-Type: application/cpim-pidf+xml Content-Type: application/pidf+xml
[Alice's geo format PIDF-LO goes here] [Alice's PIDF-LO goes here]
--broundary1-- --broundary1--
The above example has Alice also changing something within her The above example has Alice also changing something within her
original SDP, but this is not necessary for this update of location original SDP, but this is not necessary for this update of location
information. information.
A 424 (Bad Location Information) Response with a Unsupported header - If Bob agrees with this INVITE and the UPDATE, there his UA
(stating Location) is the proper response if Bob's UA cannot support transits 200 OKs for each [M4] and [M5] in Figure 3a.
this information, but does understand the concept of location.
[Alternative M3 of figure 4a]
SIP/2.0 424 Bad Location Information
To: Bob
From: Alice
Unsupported: location
If Bob's UA merely does not support that location format, the
Location header would be:
[Alternative M3 of figure 4a] - Alice, upon receiving the 200 OKs, sends an ACK to establish the
SIP/2.0 424 Bad Location Information dialog with her modified location.
To: Bob
From: Alice
Unsupported: geo-loc
This alternative indicates to Alice to send another location format Bob's UA should send a 424 (Bad Location Information) Response with
(civic) if she knows her location in that other format. A a Unsupported header (stating 'location') if his UA does not
subsequent UPDATE Request could supply this information to Bob. understand the concept of location conveyance; meaning to the INVITE
in [M1]. Therefore, a 424 SHOULD NOT be sent to the UPDATE of
location information if the PIDF-LO is well formed and has valid
(not validated!) location fields. If Bob's UA sends a 424 to this
UPDATE without an Unsupported header containing a location option
tag, Alice's UA MUST interpret that to mean the location in the
PIDF-LO was poorly generated. Perhaps it was missing a field.
Perhaps a field was incomplete.
If Bob is declining the M2 UPDATE Request message, a 488 (Not If Bob is declining the M2 UPDATE Request message, a 488 (Not
Acceptable Here) is the appropriate response. This 488 MAY include Acceptable Here) is the appropriate response. A Supported header
a location header indicating he does support the civic-loc format. with a location option tag indicates location was not the reason
this message was declined.
[Alternative M3 of figure 4a] [Alternative M3 of Figure 3a]
SIP/2.0 488 Not Acceptable Here SIP/2.0 488 Not Acceptable Here
To: Bob To: Bob
From: Alice From: Alice
Location: civic-loc Supported: location
8.4.2 UPDATE Updates Location After Session Establishment 5.3.2 UPDATE Updates Location After Session Establishment
Use #2 of the UPDATE Method is if a dialog *has been* set up between Figure 3b. shows the second example of what the UPDATE Method is
more than one UA, say between Alice and Bob without location used for: if a dialog exists between Alice and Bob without location
conveyed in either direction, and location is now going to be sent having been conveyed previously in either direction, and one of the
from one of those UAs to the other. For example, if Alice invites UAs wants to convey location to the other. For example, if Alice
Bob to a dialog, but does not include her location in that dialog invites Bob to a dialog, but does not include her location in that
establishment. Anytime during that dialog, Alice uses the UPDATE dialog establishment. Anytime during that dialog that Alice's UA
Method, not the INVITE Method (in a reINVITE), to update the decides to convey location, she uses the UPDATE Method, not the
location parameters of that dialog by sending an UPDATE message, INVITE Method (in a reINVITE), to update the location parameters of
even if it is from no location parameters to start with. that dialog.
Once a dialog has been established, a UAC MUST NOT use the INVITE Once a dialog has been established, a UAC MUST NOT use the INVITE
Method to convey location. The UPDATE Method MUST be used. Method as a reINVITE to convey location within a dialog. The UPDATE
Method MUST be used.
Consider the following example message flow in Figure 4b.: Consider the following example message flow in Figure 3b.:
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | INVITE [M1] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK (INVITE) [M2] | | 200 OK (INVITE) [M2] |
|<----------------------------------------| |<----------------------------------------|
| ACK [M3] | | ACK [M3] |
|<----------------------------------------| |<----------------------------------------|
| RTP | | RTP |
|<=======================================>| |<=======================================>|
| UPDATE [M4] | | UPDATE [M4] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK (UPDATE) [M5] | | 200 OK (UPDATE) [M5] |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 4b. UA-UA with Location in UPDATE Figure 3b. Updating Location After Dialog Establishment
[M4 of Figure 4b] For whatever reason, Alice decides to send Bob her location for the
first time. [M4] is an example of the UPDATE message used to
accomplish this.
[M4 of Figure 3b]
UPDATE sips:bob@biloxi.example.com SIP/2.0 UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob To: Bob
From: Alice From: Alice
Supported: location Supported: location
Location: geo-loc Location: cid:alice123@atlanta.example.com
Content-Type: application/cpim-pidf+xml Content-Type: application/pidf+xml
[Alice's geo format PIDF-LO goes here] [Alice's PIDF-LO goes here]
A 424 (Bad Location Information) Response with a Unsupported header A 424 (Bad Location Information) Response with a Unsupported header
(stating Location) is the proper response if Bob's UA cannot support (stating Location) is the proper response if Bob's UA does not
this information, but does understand the concept of location. understand the concept of location. In this case, the dialog MUST
remain unaffected by this rejection message. Here is a rough idea
of this 424:
[Alternative M5 of figure 4b] [Alternative M5 of Figure 3b]
SIP/2.0 424 Bad Location Information SIP/2.0 424 Bad Location Information
To: Bob To: Bob
From: Alice From: Alice
Unsupported: location Unsupported: location
If Bob's UA merely does not support that location format, the
Location header would be:
[Alternative M5 of figure 4b]
SIP/2.0 424 Bad Location Information
To: Bob
From: Alice
Unsupported: geo-loc
This alternative indicates to Alice to send another location format
(civic) if she knows her location in that other format. A
subsequent UPDATE Request could supply this information to Bob.
If Bob is declining the M4 UPDATE Request message, a 488 (Not If Bob is declining the M4 UPDATE Request message, a 488 (Not
Acceptable Here) is the appropriate response. This 488 MAY include Acceptable Here) is the appropriate response. A Supported header
a location header indicating he does support the civic-loc format. with a location option tag indicates location was not the reason
this message was declined.
[Alternative M5 of figure 4b] [Alternative M5 of figure 3b]
SIP/2.0 488 Not Acceptable Here SIP/2.0 488 Not Acceptable Here
To: Bob To: Bob
From: Alice From: Alice
Location: civic-loc Supported: location
NOTE: A similar use for UPDATE is within the UA-to-Proxy Location
Conveyance section of this document.
8.4.3 UPDATE Updates Location After a UA Moves in a Dialog 5.3.3 UPDATE Updates Location After a UA Moves in a Dialog
Use#3 of the UPDATE Method is if one UA that already conveyed Figure 3c. shows the first example of what the UPDATE Method is
location to the other UA, has moved since the dialog was originally used: if one UA that already conveyed location to the other UA, and
sent up. How a UA determines it has moved is out of scope for this has moved since the dialog was originally sent up. How a UA
document. determines it has moved is out of scope for this document.
However that "movement" trigger occurred, M4 of Figure 4c. is the However that "movement" trigger occurred, M4 of Figure 3c. is the
result: an UPDATE Method Request indicating new location by Alice. result: an UPDATE Method Request indicating new location by Alice,
to keep Bob current with Alice's position.
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | INVITE [M1] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK (INVITE) [M2] | | 200 OK (INVITE) [M2] |
|<----------------------------------------| |<----------------------------------------|
| ACK [M3] | | ACK [M3] |
|<----------------------------------------| |<----------------------------------------|
| RTP | | RTP |
|<=======================================>| |<=======================================>|
**Alice's UA determines it has moved, and needs to update Bob** **Alice's UA determines it has moved, and needs to update Bob**
| UPDATE [M4] | | UPDATE [M4] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK (UPDATE) [M5] | | 200 OK (UPDATE) [M5] |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 4c. UA-UA with Location in UPDATE Figure 3c. Updating Location During Dialog After Movement
Message M4 of Figure 4c. shows the UPDATE of Alice's location This message flow assumes Alice conveyed location in [M1], and that
Bob's UA supports location conveyance by not rejecting the INVITE
request.
Message M4 of Figure 3c. shows the UPDATE of Alice's location
information to Bob. That message may look like this (non-well- information to Bob. That message may look like this (non-well-
formed SIP message): formed SIP message):
[M4 of Figure 4c] [M4 of Figure 3c]
UPDATE sips:bob@biloxi.example.com SIP/2.0 UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob To: Bob
From: Alice From: Alice
Supported: location Supported: location
Location: geo-loc Location: cid:alice123@atlanta.example.com
Content-Type: application/cpim-pidf+xml Content-Type: application/pidf+xml
[Alice's geo format PIDF-LO goes here]
There currently is not an indication Alice can make conveying this
PIDF-LO is new, replacement location information from a previous
message (here in the M1 INVITE message).
A 424 (Bad Location Information) Response with a Unsupported header
(stating Location) is the proper response if Bob's UA cannot support
this information, but does understand the concept of location.
[Alternative M5 of figure 4c] [Alice's PIDF-LO goes here]
SIP/2.0 424 Bad Location Information
To: Bob
From: Alice
Unsupported: location
If Bob's UA merely does not support that location format, the There currently is not an indication within the PIDF-LO for Alice to
Location header would be: tell Bob this PIDF-LO is new, replacement location information from
a previous message (here in the M1 INVITE message).
[Alternative M5 of figure 4c] Because of the 200 OK to the INVITE containing location, Alice knows
SIP/2.0 424 Bad Location Information Bob's UA understands location conveyance. Therefore, if Bob's UA
To: Bob sends a 424 to this UPDATE, it MUST NOT contain an Unsupported
From: Alice header containing a location option tag.
Unsupported: geo-loc
This alternative indicates to Alice to send another location format If Alice does receive a 424 (with the Unsupported header with a
(civic) if she knows her location in that other format. A location option tag), Alice's UA MUST interpret that to mean the
subsequent UPDATE Request could supply this information to Bob. location in the PIDF-LO was poorly generated. Perhaps it was
missing a field. Perhaps a field was incomplete.
If Bob is declining the M4 UPDATE Request message, a 488 (Not If Bob is declining the M4 UPDATE Request message, a 488 (Not
Acceptable Here) is the appropriate response. This 488 MAY include Acceptable Here) is the appropriate response. A Supported header
a location header indicating he does support the civic-loc format. with a location option tag indicates location was not the reason
this message was declined.
[Alternative M5 of figure 4c] [Alternative M5 of figure 3c]
SIP/2.0 488 Not Acceptable Here SIP/2.0 488 Not Acceptable Here
To: Bob To: Bob
From: Alice From: Alice
Location: civic-loc Supported: location
NOTE: A similar use for UPDATE is within the UA-to-Proxy Location
Conveyance section of this document.
8.5 UA-to-UA Location Conveyance Using PUBLISH 5.4 Location Conveyance Using the REGISTER Method
The PUBLISH Method Request [RFC3903] is for conveying state Alice can choose to merely want to communicate her location to Bob
information of a user agent to a compositor server for others to point-to-point, without starting a (voice) conversation, the
query for that information. This creates the benefit of the user REGISTER Method MAY be used here.
agent not always being requested from all angles of the Internet.
That task or chore can be left for a SIP entity build for that task,
as well as one that is built for the efficient task of doing proper
challenges for each user's state information. One piece of state
information interesting to those involved in Presence is geophysical
location. The PUBLISH Method Request message is used by a user
agent to transmit location information to this compositor server for
queries by others.
Consider the following basic message flow in Figure 5: To comply with privacy concerns raised in [RFC3693] and [RFC4119], a
REGISTER Method Request MUST S/MIME encrypt the PIDF-LO, as outlined
in [RFC3261]. A UAC SHOULD use a SIPS-URI, as outlined in
[RFC3261]. Figure 4 here shows a simplistic REGISTER method
message flow.
Compositor UA Alice Registrar
UA Alice Server2
| PUBLISH [M1] | | REGISTER [M1] |
|---------------------------------------->| |---------------------------------------->|
| 200 OK [M2] | | 200 OK [M2] |
|<----------------------------------------| |<----------------------------------------|
| |
Figure 4. Location Conveyance in REGISTER Requests
Figure 5. OPTIONS Request for Location Below is a sample, non-well-formed REGISTER Method message from
Alice to Bob conveying her geo location:
A non-well-formed message example of how an PUBLISH Method Request
could be used to push location information to a server representing
the UAC might be:
[M1 of Figure 5] [M1 of Figure 2]
PUBLISH sips:server2@atlanta.example.com SIP/2.0 REGISTER sips:registrar1@biloxi.example.com SIP/2.0
To: server2 To: Alice <sips:alice@atlanta.example.com>;
From: Alice From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Accept: application/cpim-pidf+xml Supported: location
Location: geo-loc Location: cid:alice123@atlanta.example.com
Expires: 21600 Expires: 21600
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
The record location on this compositor server MAY become the If the message were S/MIME encrypted, this would be the Content-type
location by-reference URI for future location conveyance by this header:
UAC. This would have to be returned to the UAC in Location header
of the 200 OK Response if the UAC is expected to use this.
Otherwise, the response to the PUBLISH Request would be something Content-Type: application/pkcs7-mime;
like this non-well-formed 200 OK message: smime-type=enveloped-data; name=smime.p7m
[M2 in Figure 5] If this REGISTER request were not S/MIME encrypted, this would be
SIP/2.0 200 OK the Content-Type header:
To: server2
From: Alice
Location: geo-loc
SIP-ETag: alice987
Expires: 21600
The Location header copying the option-tag from the Request SHOULD Content-Type: application/pidf+xml
be considered the indication the compositor server understood the
format and the elements within the PIDF-LO message body of the
PUBLISH message.
PUBLISH performs 4 functions: initial, modify, refresh, or provided there were no other registration event message bodies.
terminate. Based on this, it can be easily concluded that a PUBLISH
Request conveying the location of a UAC MAY be 401 (Unauthorized) or
407 (Proxy Authentication Required) challenged. UAs MUST be
prepared to be challenged when they communicate location to a
compositor server.
A 424 (Bad Location) is the proper indication if the compositor The 200 OK to M1 of Figure 2 is a simple 200 OK.
server has no knowledge of location capabilities. An Unsupported
header MUST be in this 424 Response indicating "location" was not
supported.
[alternate M2 in Figure 5] A 424 (Bad Location Information) Response with a Unsupported header
SIP/2.0 424 (Bad Location Information) (option tag of 'location') is the proper response if the Registrar
To: server2 server does not understand location conveyance.
[Alternative M2 of Figure 2]
SIP/2.0 424 Bad Location Information
To: Alice
From: Alice From: Alice
Unsupported: location Unsupported: location
If a compositor server understands location, but does not prefer (or If the Registrar Server is declining the original [M1] REGISTER
like) the location format the UAC chose to convey location in, a 488 Request, a 488 (Not Acceptable Here) is the appropriate response. A
(Not Acceptable Here) would be the appropriate response. Within Supported header with a location option tag indicates location was
this message, the 488 MUST indicate which format was not preferred not the reason this message was declined.
using the Unsupported header and a location option-tag indicating
the existing format. The 488 MUST also have a Location header with
the preferred option-tag format to plainly inform the UAC which
location format to send in a subsequent Request.
This 488 could look like this (non-well-formed) message if the
server received Alice's civic location and prefers her location in
the geo format
[alternate M2 in Figure 5] [Alternative M2 of Figure 2]
SIP/2.0 488 Not Acceptable Here SIP/2.0 488 Not Acceptable Here
To: server2 To: Alice
From: Alice
Unsupported: civic
Location: geo-loc
Accept: application/cpim-pidf+xml
** The corresponding appendix has not be completed at this time.**
8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY
The SUBSCRIBE Method Request [RFC3265] can be used to request the
location, by-reference or by-value of another SIP entity. What is
different in this method of conveying location is the answer is in
the NOTIFY Method Request [RFC3265] from the original UAS, the
subscribed-to entity. This has at least two advantages:
1) This transaction can be used in conjunction with a Geopriv-based
Target and SIMPLE-based Presentity's use of the PUBLISH Method to
a Location server or Compositor. This allows a location target
to publish their location to a server and have that server be the
focus of AAA processes for that target's location, and not burden
the target's device - other than if that target wants to real-
time authorize a location request from one or more requestors.
2) A UAC can subscribe to a UAS (or its server/compositor) for an
ongoing location conveyance; meaning, this can be how a location
requestor (or seeker) establishes a connection to a knowledgeable
source of the UAC's/Presentity's location for more than a one
time request. Consider this to be a tracking capability.
This tracking capability MUST be authorized by the rulemaker of the
UAC/Target/Presentity, but there are some uses in which this is
valuable; consider the 911/112 caller.
When a UAC calls a 911/112-type of local emergency service for help,
regardless of how this occurs within SIP, one of the key functions
of this call is to convey the location of the caller for a PSAP
operator to dispatch first responders. It is very important that
the PSAP operator knows where the caller is to do this. If the
person who called for help is mobile or roaming, depending on how
each is defined, the fact that the caller is not tied to a cable
means they can move to a new location even during the emergency
call. The UPDATE Method is used to update a UAS if the UAC moves,
but this is not necessary reliable, and currently cannot be required
within existing SIP capabilities. This is where the SUB/NOT Request
Methods come in.
Once a caller (UAC) calls a PSAP (UAS) for help (regardless of the
routing issues discussed in section 9 of this document), the PSAP
operator may want to SUBSCRIBE to the caller's UAC to learn where it
is. This can be considered a location refresh. The US Cellular
industry calls this "reachback", and it is part of Wireless Phase II
systems today. This subscription can perform a nearly identical
function, plus a little more. This subscription can request of the
UAC to let the UAS know if there are any location changes to the
UAC. The subscription SHOULD define, or include, what it considers
locally to be "movement". In this way, what one jurisdiction
considers to a large enough change to be "movement" by the UAC does
not mandate this for all jurisdictions. Just as SIP message carry
all the necessary addressing and routing information in each message
- this type of subscription can include what it considers to be a
"movement" by the UAC. This will be what triggers the caller's UA
to NOTIFY the PSAP it has moved, either as a delta from the original
location or a new location the UAC is at.
Here is an example message flow depicting this SUB/NOT for movement
of Alice's UA during an emergency call:
UA Alice Proxy PSAP
| INVITE [M1] | |
|------------------>| |
| | INVITE [M2] |
| |-------------------->|
| | 200 OK [M3] |
| |<--------------------|
| 200 OK [M4] | |
|<------------------| |
| ACK [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
| SUBSCRIBE [M6] |
|<----------------------------------------|
| 200 OK (SUB) [M7] |
|---------------------------------------->|
| NOTIFY (init loc verify) [M8] |
|---------------------------------------->|
| 200 OK (NOT) [M9] |
|<----------------------------------------|
**Alice moves locations, causes a trigger**
| NOTIFY (new loc given) [M10] |
|---------------------------------------->|
| 200 OK (NOT) [M11] |
|<----------------------------------------|
Figure 6a. UA-PROXY with Location in INVITE
The call flow shows this:
- Alice called 911/112 (M1 of Figure 6a) and included here location
in a PIDF-LO message body.
- The message was routed correctly (M2 of Figure 6a) (message
routing is not defined here).
- The call was accepted and RTP packets flowed.
- The PSAP operator, either manually or automatically, sent a
SUBSCRIBE Method Request (M6 of Figure 6a) to Alice's UA to
determine or refresh where she is located.
This SUBSCRIBE informs Alice's UA with all it needs to look for
(i.e. what constitutes a change in location, and perhaps which is
the preferred location format for the NOTIFY messages to be sent
back to the PSAP.
- The SUB was accepted with a 200 OK (M7 of Figure 6a).
- Alice's UA immediately, according to [RFC3265], MUST send an
initial status to the subscriber (M8 of Figure 6a). In this
NOTIFY MUST be (perhaps another copy of the same) PIDF-LO from
Alice to the PSAP.
- The PSAP acknowledged receipt of this PIDF-LO in the 200 OK to the
NOTIFY (M9 of Figure 6a).
- If Alice and her UA move enough for the UA to detect what the
SUBSCRIBE considered "movement", Alice's UA, without Alice being
necessarily told, sends a new NOTIFY (M10 of Figure 6a) with this
new location PIDF-LO as a message body.
- This new NOTIFY is acknowledged with another 200 OK (M11 of Figure
6a).
The Subscription SHOULD be for as long as the PSAP operator
considers it needs to know if movement can occur at Alice's UA. In
other words, Alice's UA SHOULD be prepared to receive a SUBSCRIBE
with a very lengthy expires time, and not attempt to reduce the time
requested. When the PSAP considers it time to end the subscription,
it will actively refresh the subscription with a expires of 0, thus
terminating the it.
** the corresponding appendix has not be completed at this time.
9. Special Considerations for Emergency Calls
Calling for local emergency, such as 911 or 112 today, has special
handling characteristics. First of which is the identification of
the call as an emergency call. When a node detects a call is a
local emergency call, certain processes need to occur that are more
complicated in a SIP architecture than in the circuit switched
world. In the circuit switched world, a caller is tied to a known
Class-5 switch, or a PBX connected to a Class-5 switch. This has
the benefit of providing a location of the end of the wire of that
phone, or more accurately, to the termination point on a wall (of an
office or cube) or on the side of a house or building. Each of
these locations is just that, a physical location. This location
(typically the street address) is entered into a database that
provides a means for looking up where an emergency call came from
during that call's set-up to the PSAP. The look-up is to the
binding of that phone number to that street address.
The challenge in SIP is the disconnect of call processing, either by
the UA itself or by a SIP intermediary, from where the UAC is
located when this emergency call is made. A "call" here in SIP can
be for voice, video, instant messaging or something else - all of
this is considered a call in this document. If the call needs to be
routed to the proper PSAP by some network entity, for example
because the Request-URI didn't have an IP address in it, the routing
entity has to have enough information to route this call to the
proper PSAP.
The routing function towards the proper PSAP is out of scope of this
document, but this document must specify enough SIP capabilities and
information to that SIP intermediary to do the routing correctly
from the contents of that SIP message.
[ID-SIP-SOS] provides one means for identifying a SIP Request as an
emergency session set-up. Once that information is understood by a
routing SIP intermediary, the intermediary (Proxy or an instance of
a B2BUA) must look for the location of the UAC originating the
Request to determine internally or externally where to route the
message to. The mapping of a location to where to route the message
to is also out of scope of this document, and is currently under
investigation. The capability to include location of the UAC in a
SIP message is the task of this document. And this is where it is
separate from the task of defining how to convey location between
user agents that merely want to share location of the UAC. This SIP
intermediary MUST look into the SIP Request, for example an INVITE
Request Method message, for the location of the UAC to be included
in the message.
Location inclusion within a SIP Request will be by-value or by-
reference. By-value is the case in which the location information
is included or contained within the SIP message itself. By-
reference is the case in which the location of the UAC in a
(database) record or document on a server somewhere else, but the
UAC knows the URI to that record/document and includes only that URI
in the SIP Request.
Including this new Location header is not always enough. Therefore,
if the UAC chooses to require there be location recognizable by the
intermediary in order to process this message, the UAC will include
both the "Proxy-Require" and "Require" headers, each with "location"
as their option-tags. The reason for both is that the UAC will not
know the type of SIP element that is doing the routing to the PSAP.
[RFC3261] states the "Proxy-Require" header is for SIP Proxies to
process, and the "Require" header is for SIP UAs to process. Since
the SIP intermediary can be an instance of a B2BUA or a Border
Controller, and neither is guaranteed to adhere to the "Proxy-
Require" header, the Require header MUST be included as well in this
emergency SIP message.
A non-well formed message example would be:
INVITE sip:sos@psap1.tx.us
Proxy-Require: location
Require: location
Location: <location of "location", and/or type of location included>
If the intermediary understands this message and is able to learn
the UAC's location because it is recognizable as included in the
Request, or to perform a mapping function (locally or remotely) to
determine where to route the call (to the correct PSAP), the message
is forwarded towards that PSAP with the new Request-URI of that
PSAP.
NOTE: The ability and process of this mapping function (taking a
location and determining the correct PSAP for that location)
within the SIP intermediary is defined elsewhere.
If the intermediary does not understand this message and its
relationship to location, perhaps because it does not understand the
concept of routing based on the UAC's location, it needs to forward
the message to another intermediary that will understand how to take
location from the message and route it correctly, or communicate
with the UAC if there are issues with the message. The intermediary
MUST not reject the message because it does not understand the
concept of "location". This document does not define how this
occurs, as the offered solution here is to include a "Proxy-Require"
and a "Require" header in this original Request.
[NOTE: the authors are not sure where that needs to be defined -
here, or in another document. Another way to address this
inconsistency, one that is less forceful, is to mandate the
inclusion of the Supported header instead of the "Proxy-
Require" and a "Require" headers by the UAC in the original
Request. An option is to have the subsequent message from
the UAC remove the Proxy-Require and Require headers and
insert a Supported header, which will not cause a well
behaving intermediary to reject the request. Comments are
desired]
The ability of a PSAP to SUBSCRIBE to the caller's UA to learn if it
moves to a new location, thus changing where the first responders
need to be dispatched, is described in section 8.6 of this document.
That section goes into some detail on how this subscription can be
long lasting to receive repeated updates from the caller's UA if
there is movement.
9.1 Emergency UAC Behavior Rules
The following are the rules of behavior for the UAC transmitting an
emergency SIP Request:
1) The UAC MUST include a location header with a viable location
value indicating where the UAC is to aid the routing
intermediary.
If location is by-value, the location header will have a "loc-body"
option-tag, and the message will include a PIDF-LO message body
indicating the UAC's currently location.
If the location is by-reference, the location header will have the
URI of the location of that UAC as the header value.
Either of the above will indicate to the intermediary that the UAC
is knowledgeable of location, and indicated where the location can
be learned by the intermediary. If this is not present, the
intermediary will act accordingly and supply location other than in
a location message body. This gives the intermediary the ability to
add a location header with a uri of the location record from a
database that the UAS (in the PSAP) will access to learn the UAC's
location when necessary.
2) The UAC MUST include both the "Proxy-Require" and a "Require"
header indicating "location" is required for this message.
3) The UAC MUST understand any 425 (Retry Location Body) Response
message with the PIDF-LO included as a message body part for that
UAC to include in the subsequent retry INVITE to the PSAP as its
location.
NOTE: An open question remains in the case in which the UAC includes
what it thinks is a viable location by-value or by-reference
and receives a 488 (Not Acceptable Here) with an Unsupported
header indicating "Location".
Option#1 to this would be for the UAC to back off including the
"Proxy-Require" and a "Require" headers and merely put in a
Supported Header with "location" in the attempt to get the
message past the SIP intermediary that is rejecting the INVITE
Request message from a lack of understanding of location.
Comments are asked in this case.
4) the UAC SHOULD NOT S/MIME or SIPFRAG protect location
Information without certainty of knowledge the intermediary can
decrypt the message to learn the location of the UAC. This
defeats the purpose of an intermediary assisting in routing the
message correctly - which will be required for 911/112-type
request attempts.
5) the SIP Request from the UAC to the PSAP SHOULD be protected
through a SIPS-URI, TLS or IPsec, but the UAC MUST be prepared to
initially send the message, or a retransmission (based on a
timeout or rejection message) in cleartext to ensure the session
set-up does not fail due to security incompatibilities in
transit, or at the PSAP.
6) the UAC MUST include both a <provided-by> element and a <method>
element in the PIDF-LO message body indicating #1 the
organization that provided the location information to the UAC,
and #2 how the UAC learned its location information,
respectively.
7) The UAC SHOULD be prepared to receive a SUBSCRIBE Request message
from the PSAP seeking verification of its location. This
subscription SHOULD want to last for more than one NOTIFY back to
the subscriber, for the purposes of getting updates of movement
the calling (UAC) detects, based on what is in the original
SUBSCRIBE Request message. As such, this SUBSCRIBE SHOULD have a
lengthy Expires timer. The original (the calling) UAC MUST NOT
reduce the time of this Expires Timer if it accepts the
SUBSCRIBE. See section 8.6 for more on SUB/NOT and location
conveyance.
This SUBSCRIBE SHOULD provide within the message what it considers
to be "movement" by the emergency calling (UAC).
9.2 Emergency UAS/Intermediary Behavior Rules
The following are the rules of behavior for the UAS or intermediary
receiving an emergency SIP Request:
1) identifies that SIP Request as an emergency Request.
2) The intermediary looks for the "location" header to inform it
where location is within this message (by-reference or by-value),
and if the format of the location information is given as a hint.
3) The intermediary looks for a "Proxy-Require" and/or a "Require"
header indicating "location" is required for this message.
4) If the intermediary does not understand location, or does not
observe viable location information within this message MUST do
one of the following action items:
a) reject the message with a 488 (Not Acceptable Here) with a
Unsupported header indicating "location" if the intermediary
does not understand location and there is a "Proxy-Require"
and/or a "Require" header indicating "location"
b) if the intermediary does not understand location, and there is
no "Proxy-Require" and/or a "Require" header indicating
"location", the intermediary MUST not reject the message, but
MUST forward this message to another (upstream) SIP
intermediary for proper processing.
c) reject the message with a 425 (Retry Location Body) if it
understands the concept of location, but does not detect
location in the message, and has a current PIDF-LO for that
UAC. The UAC will know to reattempt the INVITE with this new
PIDF-LO message body.
d) if the intermediary understands the concept of location, but
does not detect location within this message, it MAY insert a
location by-reference, if known
Of particular concern to this option "d" above is the fact this
information never gets back to the UAC, so it MAY remain in the dark
as to its location. If the UAC does not understand location, which
SHOULD be indicated by the lack of presence of the Location header,
insertion is the best possible solution short of upgrading the UAC.
However, if the UAC includes a Location header, an intermediary
SHOULD NOT insert location by-reference and forward the message.
5) the intermediary MUST NOT delete a PIDF-LO message body
6) the intermediary that knows the concept of location SHOULD NOT
insert a location by-reference header value if there is a
location by-value currently in the SIP message from the UAC.
Behavior #5 above MUST NOT be done to satisfy Behavior #6 here, just
to get a by-reference location indication in the message.
7) If the UAC included a location header, but this was not deemed
usable, or determined to be incorrect, the intermediary MAY
reject the Request with one of the following response codes:
a) a 424 (Bad Location Information) response informing the UAC to
include its location in a subsequent attempt, or
b) a 425 (Retry Location Body) if the intermediary can include
what it considers to be current and accurate location
information to the UAC.
9.3 Basic Emergency Message Flow Examples
The following subsections provide a discussion on the basic message
flows for emergency messaging.
9.3.1 Basic INVITE with Location Body
Here is the basic message flow for Alice calling for help.
UA Alice Proxy PSAP
| INVITE (w/ PIDF-LO)[M1] |
|------------------>| |
| INVITE (w/ PIDF-LO) [M2] |
| |-------------------->|
| | 200 OK [M3] |
| |<--------------------|
| 200 OK [M4] | |
|<------------------| |
| ACK [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 7a. UA-PROXY with Location in INVITE
Consider Figure 7a as a very basic message flow establishing an
emergency call from Alice to the correct PSAP suiting her location.
[M1 of Figure 7a]
INVITE sips:sos@atlanta.com SIP/2.0
From: Alice
To: sos@
Proxy-Require: Location
Require: Location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
...
--boundary1
Content-Type: application/cpim-pidf+xml
(Alice's geo PIDF-LO goes here)
Once the intermediary's mapping function determines the correct PSAP
for Alice's sos@ call to go to, the INVITE will look something like
this (with a changed Request-URI):
[M2 of Figure 7a]
INVITE sips:sos@psap1.atlanta.us SIP/2.0
From: Alice From: Alice
To: sos@ Supported: location
Proxy-Require: Location
Require: Location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
...
--boundary1
Content-Type: application/cpim-pidf+xml
(Alice's geo PIDF-LO goes here)
The call gets set up and everything is grand.
See section 8.6 for the message flow that will likely be the follow-
on to this flow in Figure 7a.
9.3.2 Basic INVITE Retry from 425 Response
If the routing SIP intermediary does not detect location in Alice's
INVITE, or determines if it is wrong, and the intermediary knows the
current and correct location of Alice's UAC, it transmits a 425
(Retry Location Body) and includes that location information (by-
value or by-reference) in the rejection response. Figure 7b shows
this basic message flow.
UA Alice Proxy PSAP
| INVITE [M1] | |
|------------------>| |
| 425 Retry Location Body [M2] |
|<------------------| |
| INVITE [M3] | |
|------------------>| |
| | INVITE [M4] |
| |-------------------->|
| | 200 OK [M5] |
| |<--------------------|
| ACK [M6] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 7b. INVITE Retry with Location
The 425 rejection Response could look something like this:
[M2 of Figure 7b]
SIP/2.0 425 Retry Location Body 6. Special Considerations for Emergency Calls
To: psap1
From: Alice
Location: geo-loc
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here] Emergency calling, such as 911, 112 and 999 calling today,
necessitates a UAC to understand the type of call it is about to
generate with an INVITE message to a PSAP. First of all, the
purpose of calling for emergency help is to get someone to respond
to the UAC's location, therefore, location MUST be included in the
INVITE, if known by the UAC.
[M3 of Figure 7b] The emergency services community strongly prefers that message
routing occur in the network with the freshest available Public
Safety Answering Point (PSAP) information. Message routing, in this
context, means choosing which SIP(S)-URI to place in the Request-URI
field of the status line.
INVITE sips:sos@psap1.atlanta.us SIP/2.0 If a UAC knows it is generating an emergency request towards a PSAP,
From: Alice there MAY be unique message handling characteristics that diminish
To: sos@ the level of confidentiality of the location information within the
Proxy-Require: Location SIP message(s). This is because emergency call routing requires
Require: Location proxies to know the location of the message originating UAC in order
Location: geo-loc to make a decision on where to route the message. This is because
Content-Type: multipart/mixed; boundary=boundary1 emergency calls are directed to the PSAP local to the caller's
Content-Length: ... location. A proxy performing this function requires that proxy to
learn the location of the UAC during message processing.
--boundary1 How a message is routed based on the location of the UAC, and if and
by how much the level of confidentiality of location information is
diminished when calling for emergency help are both out of scope of
this document.
Content-Type: application/sdp Hop-by-hop confidentiality mechanisms, as defined in [RFC3261] MUST
v=0 be attempted initially by a UAC that includes location. Local
... configuration MAY allow a subsequent retry, after a security related
failure, to be without hop-by-hop confidentiality. SIP elements
MUST obey the rules set forth in [RFC3261] regarding maintaining
hop-by-hop confidentiality when a message using a SIPS-URI.
--boundary1 While many jurisdictions force a user to reveal their location
Content-Type: application/cpim-pidf+xml during an emergency call set-up, there is a small, but real, number
(Alice's geo PIDF-LO goes here) of jurisdictions that allow a user to configure their calling device
to disable providing location, even during emergency calling. This
capability MUST be configurable, but is not RECOMMENDED as the
default configuration of any UA. Local policies will dictate this
ability.
10. Meeting RFC3693 Requirements 7. Meeting RFC3693 Requirements
Section 7.2 of [RFC3693] details the requirements of a "using Section 7.2 of [RFC3693] details the requirements of a "using
protocol". They are: protocol". They are:
Req. 4. The using protocol has to obey the privacy and security Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage of the corresponding Rules regarding the transmission and storage of the
LO. LO.
This document requires, in Section 7, that SIP entities sending or This document requires, in Section 3, that SIP entities sending or
receiving location MUST obey such instructions. receiving location MUST obey such instructions.
Req. 5. The using protocol will typically facilitate that the keys Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective associated with the credentials are transported to the respective
parties, that is, key establishment is the responsibility of the parties, that is, key establishment is the responsibility of the
using protocol. using protocol.
[RFC3261] and the documents it references define the key establish [RFC3261] and the documents it references define the key establish
mechanisms. mechanisms.
Req. 6. (Single Message Transfer) In particular, for tracking of Req. 6. (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.
This document specifies that the LO be contained in the body of a This document specifies that the LO be contained in the body of a
single message. single message, which may be fragmented via TCP, but is still not a
streaming delivery.
11. Open issues 8. Open issues
This is a list of open issues that have not yet been addressed to This is a list of open issues that have not yet been addressed to
conclusion: conclusion:
1) Should a Proxy somehow label its location information in the 4XX none
(Retry Location Body) message?
11.1 New Open Issues
These are new open issues to be addressed within this document or
the topics/areas dropped from consideration:
1) There is an outstanding request to be able to include more than
one location element, and label at least one the current position
of the UAC, and another the "billing" address of the owner of the
UAC. This comes from the country of Sweden, from our favorite
Patrik Faltstrom.
Options to this are use the Content-Type headers associated with 9. Security Considerations
each message body part, using either:
A) multipart/mixed - because they could be considered different Conveyance of physical location of a UAC is problematic for many
reasons. This document calls for that conveyance to normally be
accomplished through secure message body means (like S/MIME or TLS).
In cases where a session set-up is routed based on the location of
the UAC initiating the session or SIP MESSAGE, securing the location
with an end-to-end mechanism such as S/MIME is problematic, due to
the probability of a proxy from requiring the ability to read that
information to route the message appropriately. This means the use
of S/MIME may not be possible. This leaves location information of
the caller available in each proxy through to the PSAP. This may
not be a perfect solution, but may be a pill we need to swallow to
enable this functionality.
B) multipart/alternative - for one application to use only one, and A bad implementation of SIP location conveyance would have a UAC
allowing another application to use another send location in cleartext, without hop-by-hop confidentiality, or
have any SIP element along the path towards the PSAP alter the
transport of any message carrying location to be without hop-by-hop
confidentiality between elements. The latter would be in clear
violation of RFC3261 rules surrounding the use of a SIPS-URI.
C) multipart/related - because they could be considered similar 10. IANA Considerations
enough as they each deal with location
2) May add a section for end-to-middle in a services model This section defines one new SIP header, two new option tags, and
one new 4XX error response code within the sip-parameters section of
IANA. [NOTE: RFC XXXX denotes this document].
12. Security Considerations 10.1 IANA Registration for the SIP Location Header
Conveyance of geo-location of a UAC is problematic for many reasons. The Location header is created by this document, with its definition
This document calls for that conveyance to normally be accomplished and rules in Section 4 of this document.
through secure message body means (like S/MIME or TLS). In cases
where a session set-up is routed based on the location of the UAC
initiating the session or SIP MESSAGE, securing the location with an
end-to-end mechanism such as S/MIME is problematic.
13. IANA Considerations 10.2 IANA Registration for Two New SIP Option Tags
This section defines two new 4XX error response codes within the Two new SIP option tags are created by this document, "Location" and
sip-parameters section of IANA. [NOTE: RFC XXXX denotes this "Unknown-location", with the definitions and rules for each in
document. Section 4 of this document.
13.1 IANA Registration for Response Code 4XX 10.3 IANA Registration for Response Code 4XX
Reference: RFC-XXXX (this document) Reference: RFC-XXXX (i.e. this document)
Response code: 424 Response code: 424
Default reason phrase: Bad Location Information Default reason phrase: Bad Location Information
13.2 IANA Registration for Response Code 4XX 11. Acknowledgements
Reference: RFC-XXXX (this document)
Response code: 425
Default reason phrase: Retry Location Body
13.3 IANA Registration for the SIP Location Header
This subsection will be completed once the authors work out the ABNF
for the header
14. Acknowledgements
To Dave Oran for helping to shape this idea. To Jon Peterson and To Dave Oran for helping to shape this idea. To Jon Peterson and
Dean Willis on guidance of the effort. To Henning Schulzrinne, Dean Willis on guidance of the effort. To Henning Schulzrinne,
Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for
constructive feedback. constructive feedback.
To Paul Kyzivat for inspiring some of the recent text addressing To Paul Kyzivat for inspiring some of the recent text addressing
lingering issues the authors could not resolve. lingering issues the authors could not resolve.
15. References To Jon Peterson for his guidance in this effort.
15.1 References - Normative 12. References
12.1 References - Normative
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004
[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
[RFC4119] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet
Draft, Sept 2004, work in progress
[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
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-CIVIC] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-06.txt",
Internet Draft, May 05, Work in progress
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[ID-PIDF-LO] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet
Draft, Sept 2004, work in progress
[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
Locators", RFC 2393, August 1998 Locators", RFC 2393, August 1998
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Session Description Protocol", RFC 3264, June 2002 Method", RFC 3311, October 2002
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
15.2 References - Informative
[ID-End-Mid-Sec] "Requirements for End to Middle Security in SIP", 12.2 References - Informative
draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June
2004, work in progress,
[ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the [ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the
Session Initiation Protocolö, draft-ietf-sipping-session- Session Initiation Protocol”, draft-ietf-sipping-session-
policy-req-00", Internet Draft, June, 2003, "work in policy-req-02", Internet Draft, July, 2004, "work in
progress" progress"
[ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Draft, Feb 2004, Work in progress Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping- [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
emergency-arch", Internet Draft, Feb 2004, work in progress (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
progress", January 2006
Author Information Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 33.00111N 3913 Treemont Circle 33.00111N
Richardson, Texas 75082 USA 96.68142W Colleyville, Texas 76034 96.68142W
jmpolk@cisco.com
Brian Rosen 40.4N
br@brianrosen.net 80.0W
NeuStar
NOTE: these appendixes are not in good order yet, and will be worked
on soon.
Appendix A1. UA-to-UA INVITE with Coordinate Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases
where hop-by-hop security is deployed.
[Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--broundary1
Content-Type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N
87.63649W</gml:coordinates>
</gml:Point>
</gml:location>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Appendix A2. INVITE and REFER between 3 UAs
In the following example, Alice presents her location in the INVITE
to Bob, which Bob 200 OKs with his location as well. Bob then
directs Alice to contact Carol. The REFER Method [RFC3515] is used
in the message sequence, but it does not carry anyone's location
within the REFER message. This example is here to show a 3-way
communication of location, coupled with how a UA can include someone
else's location. This has security implications due to neither
primary party in the last location transfer being the owner of the
location information. Alice (in this case) MUST adhere to the
retention and distribution privacy requirements within Bob's
location object regarding his location information prior to
considering its inclusion in the INVITE to Carol.
UA Alice Bob Carol
| INVITE [M1] | |
|---------------------------->| |
| 200 OK [M2] | |
|<----------------------------| |
| ACK [M3] | |
|---------------------------->| |
| RTP | |
|<===========================>| |
| reINVITE (hold) [M4] | |
|<----------------------------| |
| 200 OK [M5] | |
|---------------------------->| |
| REFER (Refer-to:Carol) [M6] | |
|<----------------------------| |
| NOTIFY [M9] | |
|---------------------------->| |
| 200 OK [M10] | |
|<----------------------------| |
| INVITE [M7] |
|------------------------------------------>|
| 200 OK [M8] |
|------------------------------------------>|
| RTP |
|<=========================================>|
| NOTIFY [M9] | |
|---------------------------->| |
| 200 OK [M10] | |
|<----------------------------| |
| BYE [M11] | |
|<----------------------------| |
| 200 OK [M12] | |
|---------------------------->| |
| |
Figure A2. UA-to-UA with Location in REFER
Appendix A3. UA-to-UA REFER with Civic Location Using S/MIME
In Figure A2., we have an example message flow involving the REFER
Method. The REFER itself does not carry location objects.
We are not including all the messages for space reasons. M1 is a
well-formed SIP message that contains Alice's location. M2 is Bob's
200 OK in response to Alice's INVITE, and it contains Bob's
Location.
[M1 of Figure A2] - Alice at Sears Tower
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<provided-by><nena>www.cisco.com</nena></provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Bob replies to Alice's INVITE with a 200 OK and includes his
location.
[M2 of Figure A2] - Bob watching Cubs Game at Wrigley Field
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bKnashds8 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=bob 2890844530 2890844530 IN IP4 biloxi.example.com
c=IN IP4 192.168.10.20
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:bob@biloxi.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-6T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC>
<cl:civilAddress>
<method>dhcp</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Bob refers Alice to Carol, and in M7, Alice includes both locations
in a single SIP message. This is possible because Bob set his
retention value to "yes", thus allowing Alice to pass his location
on to Carol.
[M7 of Figure A2] - Alice tells Carol where she and Bob are
INVITE sips:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhdt
Max-Forwards: 70
To: Carol <sips:carol@chicago.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301775
Call-ID: a84b4c76e66711@pc33.atlanta.example.com
CSeq: 314160 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844531 2890844531 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49173 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:bob@biloxi.example.com">
<tuple id="sg89af">
<timestamp>2005-11-5T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-
allowed>
<gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-6T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.marconi.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
It is an open question of whether there should be a mechanism to
request or require the transmission of an LO. The LO is contained
in a body, so the available sip mechanisms do not apply.
Appendix A4. UAC to UAS or Proxy Using OPTIONS Method (from 8.2)
Appendix A5. UA-to-UA Using MESSAGE Method (from 8.3)
UA Alice UA Bob
| MESSAGE [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
| |
Figure A5. UA-UA with Location in MESSAGE
Appendix A6. UA-to-UA MESSAGE with Coordinate Location Using S/MIME
Below is M1 from Figure 2 in section 8.2. that is fully secure and
in compliance with Geopriv requirements in [RFC3693] for security
concerns.
[Message 1 in Figure A5]
MESSAGE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asegma
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 22756 MESSAGE
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: text/plain
Here's my location, Bob?
--broundary1
Content-Type: application/cpim-pidf+xml
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N
87.63649W</gml:coordinates>
</gml:Point>
</gml:location>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Appendix A7. UA-to-UA MESSAGE with Civic Location Not Using S/MIME
Below is a well-formed SIP MESSAGE Method message to the example in
Figure 2 in section 8.2 when hop-by-hop security mechanisms are
deployed.
[Message 1 in Figure A5]
MESSAGE sip:bob@biloxi.example.com SIP/2.0
From: <sip:alice@atlanta.example.com>;tag=34589882
To: <sip:bob@biloxi.example.com>
Call-ID: 9242892442211117@atlanta.example.com
CSeq: 6187 MESSAGE
Content-Type: application/cpim-pidf+xml
Content-ID: <766534765937@atlanta.example.com>
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
Appendix A8. UA-to-UA Location Conveyance Using UPDATE (from 8.4)
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| 183 (session Progress) [M2] |
|<----------------------------------------|
| PRACK [M3] |
|---------------------------------------->|
| ACK (PRACK) [M4] |
|<----------------------------------------|
| UPDATE [M5] |
|---------------------------------------->|
| ACK (UPDATE) [M6] |
|<----------------------------------------|
| 200 OK (INVITE) [M7] |
|<----------------------------------------|
| RTP |
|<=======================================>|
| |
Figure A6. UA-UA with Location in UPDATE
The following section will include the M1 and M5 messages in detail,
but only in the civic format.
Appendix A9. UA-to-UA UPDATE with Civic Location Not Using S/MIME
Here is the initial INVITE from Alice to Bob.
[M1 INVITE to Bob]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
Alice moves locations (with her UA detecting the movement), causing
her UA to generate an UPDATE message ([M5] of Figure 3) prior to
her UA receiving a final response from Bob. Here is that message:
M5 UPDATE to Bob
UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 10197 UPDATE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>250</cl:HNO>
<cl:PRD>South Upper</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:NAM>Venice Cafe</cl:NAM>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
Appendix A10. UA-to-UA Location Conveyance Using PUBLISH (from 8.5)
** This appendix is not be completed at this time. Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Appendix A11. UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY Brian Rosen
(from 8.6) 470 Conrad Dr. 40.70497N
Mars, PA 16046 80.01252W
US
** This appendix is not be completed at this time. Phone: +1 724 382 1051
Email: br@brianrosen.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
skipping to change at page 73, line 31 skipping to change at page 33, line 41
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
The Expiration date for this Internet Draft is:
January 17th, 2006
 End of changes. 264 change blocks. 
2836 lines changed or deleted 835 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/