One document matched: draft-ietf-sip-location-conveyance-01.txt
Differences from draft-ietf-sip-location-conveyance-00.txt
SIP Working Group James M. Polk
Internet Draft Cisco Systems
Expiration: Jan 17th, 2006 Brian Rosen
NeuStar
Session Initiation Protocol Location Conveyance
draft-ietf-sip-location-conveyance-01.txt
July 17th, 2005
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document presents the framework and requirements for usage of
the Session Initiation Protocol (SIP) to convey user location
information from one Session Initiation Protocol (SIP) entity to
another SIP entity. We consider cases where location information is
conveyed from end to end, as well as cases where message routing by
intermediaries is influenced by the location of the session
initiator, the user agent client (UAC). We offer a set of solutions
to the requirements, each based on the scenario being addressed.
Polk & Rosen [Page 1]
Internet Draft SIP Location Conveyance July 17th, 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4
2. Location In the Body or in a Header . . . . . . . . . . . . . 7
3. Scope of Location Conveyance . . . . . . . . . . . . . . . . 8
3.1 Scope of Location in a Message Body . . . . . . . . . . . 8
3.2 Scope of Location in a Header . . . . . . . . . . . . . . 9
4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 10
5. Requirements for UA-to-Proxy Server Location Conveyance . . . 11
6. Additional Requirements for Emergency Calls . . . . . . . . . 12
7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 14
7.1 Indicating Support for Location by the UAC . . . . . . . 16
7.2 Location Rejection Responses . . . . . . . . . . . . . . 19
7.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 20
7.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 21
8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 23
8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 23
8.1.1 UA-to-UA Using INVITE w/ Geo Format w-w/o S/MIME . . 25
8.1.2 UA-to-UA Using INVITE w/ Civic Format w-w/o S/MIME . 26
8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 28
8.2 OPTIONS Method and Location . . . . . . . . . . . . . . . 31
8.2.1 OPTIONS Request to Learn UAC's Location . . . . . . . 31
8.2.2 OPTIONS Request to Learn UAS's Location . . . . . . . 33
8.3 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 34
8.4 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 36
8.4.1 UPDATE Updates Location During Session
Establishment . . . . . . 37
8.4.2 UPDATE Updates Location After Session
Establishment . . . . . . 39
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
Polk & Rosen [Page 2]
Internet Draft SIP Location Conveyance July 17th, 2005
1. Introduction
This document presents the framework and requirements for the usage
of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of
user location information described by [RFC3693] from a SIP entity
to another SIP entity.
There are several situations in which it is appropriate for SIP to
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
pizza parlors may be contacted through a single well known uri
(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
sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The
example.com proxy server must route the call to the correct public
safety answering point (PSAP) determined by the location of the
caller. At the PSAP, the UAS must determine the correct
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
directions to a venue from your present position. This is a case
where only the destination UAS needs to receive the location
information.
This document does not discuss how the UAC discovers or is
configured with its location (either coordinate based such as from
[RFC3825] or civic based such as from [ID-CIVIC]). This document
will also not discuss the contents of the SIP message body part that
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
messages) of SIP UA and Proxy behavior for location conveyance, the
Polk & Rosen [Page 3]
Internet Draft SIP Location Conveyance July 17th, 2005
last of which is a section devoted to the unique circumstances
regarding emergency calling. Section 10 addresses how this document
adheres to the requirements specified in [RFC3693] (Geopriv
Requirements). Sections 11 and 12 list the current open issues with
location conveyance in SIP, and the new open issues recently
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC2119].
1.2 Changes from Prior Versions
[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 is a list of the changes that have been made from the SIP WG
version -00 to this version -01:
- cleaned up a lot of loose ends in the text
- created a new Location header to convey many means (location is in
the body - even if not viewable, which location format is present,
which format is requested in a query, how to request more than one
location format in a query, whether the UAC understands location
at all, if the UA knows its location, how to push location from
one UA to through a second to a third UA, etc).
- added the ability to convey location by-reference, but only under
certain conditions.
- Added support for the OPTIONS Request to query a server for the
UAC's location, through the use of the new Location header.
- moved both new Response code sections forward in the document for
their meaning to be clearer, earlier for necessary discussion.
- Changed the message flows to only have the pertinent message
headers shown for brevity.
- Added text to the SUB/NOT section showing how and why the location
of a UA can be refreshed or updated with an interval, or by a
trigger.
This is a list of the changes that have been made from the SIPPING
WG version -02 to this SIP WG item document version -00:
Polk & Rosen [Page 4]
Internet Draft SIP Location Conveyance July 17th, 2005
- Changed which WG this document is in from SIPPING to SIP due to
the extension of the protocol with new Response codes (424 and
425) for when there is an error involving the LO message body.
- Moved most of the well formed SIP messages out of the main body of
this document and into separate appendixes. This should clean up
the document from a readability point of view, yet still provide
the intended decode examples to readers of this document who wish
that level of detail per flow. The first few flows still have the
decoded SIP messages (unencrypted and encrypted).
- Removed some flow examples which no longer made sense
- Changed all references of "ERC" (Emergency Response Center) to
"PSAP" (Public Safety Answering Point) as a result of discussion
within the new ECRIT WG to define a single term
This is a list of the changes that have been made from the sipping-
01 working group version of this effort to the sipping-02 version:
- added requirements for 2 new 4XX error responses (Bad Location
Information) and (Retry Location Body)
- added "Bad Location Information" as section 8.6
- added "Retry Location Body " as section 9.3
- added support for session mode to cover packet sizes larger than
the single packet limit of 1300 bytes in the message body
- added requirement for a SIP entity to SUBSCRIBE to another for
location information
- added SUBSCRIBE and NOTIFY as section 8.5
- added requirement to have user turn off any tracking created by
subscription
- removed doubt about which method to use for updating location
after a INVITE is sent (update)
- cleaned up which method is to be used if there is no dialog
existing (message)
- removed use of reINVITE to convey location
- clarified that UAs include <provided-by> element of PIDF-LO when
placing an emergency call (to inform PSAP who supplied Location
information)
- updated list of open issues
Polk & Rosen [Page 5]
Internet Draft SIP Location Conveyance July 17th, 2005
- added to IANA Considerations section for the two new 4XX level
error responses requested in the last meeting
This is a list of the changes that have been made from the sipping-
00 working group version of this ID to the sipping-01 version:
- Added the offered solution in detail (with message flows,
appropriate SIP Methods for location conveyance, and
- Synchronized the requirements here with those from the Geopriv
Working Group's (attempting to eliminate overlap)
- Took on the task of making this effort the SIP "using protocol"
specification from Geopriv's POV
- Refined the Open Issues section to reflect the progress we've made
here, and to indicate what we have discovered needs addressing,
but has not been to date.
This is a list of the changes that have been made from the -01
individual submission version to the sipping-00 version of this ID:
- Brian Rosen was brought on as a co-author
- Requirements that a location header were negatively received in
the previous version of this document. AD and chair advice was to
move all location information into a message body (and stay away
from headers)
- Added a section of "emergency call" specific requirements
- Added an Open Issues section to mention what hasn't been resolved
yet in this effort
This is a list of the changes that have been made from the
individual submission version -00 to the -01 version
- Added the IPR Statement section
- Adjusted a few requirements based on suggestions from the
Minneapolis meeting
- Added requirements that the UAC is to include from where it
learned its location in any transmission of its LI
- Distinguished the facts (known to date) that certain jurisdictions
relieve persons of their right to privacy when they call an PSAP,
while other jurisdictions maintain a person's right to privacy,
while still others maintain a person's right to privacy - but only
if they ask that their service be set up that way.
Polk & Rosen [Page 6]
Internet Draft SIP Location Conveyance July 17th, 2005
- Made the decision that TLS is the security mechanism for location
conveyance in emergency communications (vs. S/MIME, which is still
the mechanism for UA-to-UA non-emergency location conveyance
cases).
- Added the Open Issue of whether a Proxy can insert location
information into an emergency SIP INVITE message, and some of the
open questions surrounding the implications of that action
- added a few names to the acknowledgements section
2. Location In the Body or in a Header
In determining where "location" is placed in a SIP message,
consideration is taken as to where the trust model is based on the
architecture involved.
If the user agent has the location stored within it, and one user
agent wants to inform another user agent where it is, it seems
reasonable to have this accomplished by placing the location
information (coordinate or civic) in an S/MIME registered and
encoded message body, and sending it as part of a SIP request or
response. No routing of the request based on the location
information is required in this case; therefore no SIP Proxies
between these two UAs need to view the location information
contained in the SIP messages. This is location by-value.
Although SIP [RFC3261] does not permit SIP intermediaries to modify
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
Polk & Rosen [Page 7]
Internet Draft SIP Location Conveyance July 17th, 2005
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,
Polk & Rosen [Page 8]
Internet Draft SIP Location Conveyance July 17th, 2005
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.
Polk & Rosen [Page 9]
Internet Draft SIP Location Conveyance July 17th, 2005
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
The following are the requirements for UA-to-UA Location Conveyance
Situations where routing is not based on the LI of either UA, and
location is stored/cached in the UAC:
U-U1 - Dialog-initiating SIP Requests and their responses MUST
support Location Conveyance
U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location
Conveyance
U-U3 - Other SIP Requests SHOULD support Location Conveyance
U-U4 - UAC Location information SHOULD remain confidential e2e
to the destination UAS except when the session is to an
identifiable emergency endsystem.
U-U5 - UAC MUST not use S/MIME on the Location message body
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
to the destination UAC except when the session is to/from an
identifiable emergency endsystem.
Emergency callback is one example where this may apply.
U-U7 - The privacy and security rules established within the
Geopriv Working Group that would categorize SIP as a 'using
Polk & Rosen [Page 10]
Internet Draft SIP Location Conveyance July 17th, 2005
protocol' [RFC3693] MUST be met. See Section 10 for
analysis.
U-U8 - Location information SHOULD be contained in the location
Object as defined in [ID-PIDF-LO], which will satisfy all
format requirements for interoperability.
U-U9 - Location information MAY be contained in a by-reference URI
contained in a Location Header. All privacy and security
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
for the UAC's location; including offering a preferential
location format to be returned.
U-U11- User Agents and Proxies SHOULD be able to handle SIP
messages in which Location Information is fragmented across
multiple packets.
U-U12- There MUST be a unique UAC error response code informing the
UAC it did not provide applicable location information.
U-U13- There MUST be a unique UAC error response code informing the
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
information for a particular presentity to a Presence
Compositor Server.
U-U15- User Agents and Proxies SHOULD be able to process SIP
messages which contains more than one piece of Location
information.
U-U16- User Agents MUST have the ability to query another user
agent for location information refresh and movement of the
UA.
5. Requirements for UA-to-Proxy Server Location Conveyance
The following are the requirements for UA-to-Proxy Server Location
Conveyance situations:
U-PS1 - MUST work with dialog-initiating SIP Requests and
responses, as well as the SIP MESSAGE method [RFC3428], and
SHOULD work with most SIP messages.
U-PS2 - UAC location information SHOULD remain opaque to
intermediaries the message was not addressed to, but MUST
Polk & Rosen [Page 11]
Internet Draft SIP Location Conveyance July 17th, 2005
be useable (i.e. viewable) by intermediary proxy servers
requiring location knowledge of the UAC to properly route
the message.
U-PS3- User Agents MUST have a means for indicating they understand
what location conveyance is, but currently do not have their
location information to convey.
U-PS4 - The privacy and security rules established within the
Geopriv Working Group which would categorize SIP as a
'using protocol' MUST be met [RFC3693].
U-PS5 - Proxy servers MUST NOT modify or remove an location message
body part ([RFC3261] currently forbids this).
U-PS6 - A SIP message containing location information MUST NOT be
rejected by a SIP intermediary because the message body
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
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
the UAC it did not provide applicable location information.
U-PS8 - There MUST be a unique UAC error response code informing
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
Emergency calls have requirements that are not generally important
to other uses for location in SIP:
Emergency calls presently have between 2 and 8-second call setup
times. There is ample evidence that the longer call setup end of
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
Polk & Rosen [Page 12]
Internet Draft SIP Location Conveyance July 17th, 2005
setup time when implemented in present technology UAs and
Proxy Servers.
It may be acceptable for full privacy mechanisms related to the
location of the UAC (and it's user) to be tried on an initial
attempt to place a call, as long as the call attempt may be retried
without the privacy mechanism present (or enabled) if the first
attempt fails. Abandoning privacy in cases of failure of the
privacy mechanism might be subject to user preference, although such
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
conveyance of location during an (sos-type) emergency call.
E-3 - It MUST be possible to provide a privacy mechanism (that does
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
able to be made available to the user, and override the
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
calls, that it is to be transmitted even when it is not considered
reliable, or might even be wrong. For example, some application
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
considered a violation of the distribution privacy attribute
contained within the location object.
This transfer will likely be for legitimate reasons; for example,
the session was misrouted to the wrong PSAP, and is referred
Polk & Rosen [Page 13]
Internet Draft SIP Location Conveyance July 17th, 2005
[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,
in all calls to a PSAP, even in the case the location
information known to the UAC is not considered reliable by the
UAC.
With that in mind, it is important to distinguish the location
information learned locally from location information learned over a
VPN; which in itself is useful additional information to that PSAP
operator.
E-7 The UA must provide the actual location of the endpoint, and
not location which might have been erroneously given to it by,
e.g. a VPN tunnel DHCP server.
E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a
session. If this is supported by the UAC, all NOTIFY messages
MUST contain the UAC's location information.
This is a means for the emergency response centers to maintain a
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
this subscription, as this will provide a means of alert to the
user who does not wish this capability to remain enabled.
7. Location Conveyance using SIP
Geopriv is the IETF working group assigned to define a Location
Object for carrying within another protocol to convey geographic
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
otherwise have access to reading the clear-text bodies. For UA-to-
UA location conveyance, using the PIDF-LO body satisfies the entire
format and message-handling requirements as stated in the baseline
Geopriv Requirements [RFC3693]. SIP entities that will carry an LO
MUST implement S/MIME for encrypting on an end-to-end basis the
location of a user agent, satisfying [RFC3693]'s security
requirements. The SIPS-URI from [RFC3261] SHOULD also be used for
further message protection (message integrity, authentication and
Polk & Rosen [Page 14]
Internet Draft SIP Location Conveyance July 17th, 2005
message confidentiality) and MUST be used when S/MIME is not used
(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
message body. The Methods are divided into two groups, one for
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:
INVITE,
OPTIONS,
UPDATE,
MESSAGE,
SUBSCRIBE/NOTIFY, and
PUBLISH.
The list of applicable Methods for UA-to-Proxy location conveyance
is:
INVITE,
UPDATE, and
MESSAGE
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
reason to prevent carrying a LO within these Method Requests as long
as the SIP message meets the requirements stated within this
document.
A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that
provided its location in the INVITE, but this is not something
that can be required due to the timing of the INVITE to 200 OK
messages, with potential local/user policy requiring the called user
to get involved in determining if the caller is someone they wish to
give location to (and at what precision).
For UA-to-Proxy location conveyance, there are two cases: one in
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.
Polk & Rosen [Page 15]
Internet Draft SIP Location Conveyance July 17th, 2005
TLS security). In particular, emergency call routing requires
routing proxies to know the location of the UAC, and sips:
protection is appropriate. The latter case is under study by the
SIPPING working group under the subject "End to Middle" security
[ID-End-Mid-Sec].
Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to
convey location, SIP entities MUST adhere to the rules of [RFC3693],
specifically the retention and distribution (privacy) attributes of
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
User agent clients who supports this specification will indicate
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-
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
INVITE message an indication that it understands what "location"
means, that it is necessary to convey location in this INVITE
message, and understands any location based rejection responses from
the SIP intermediary. There are two new 4XX level Responses defined
later in this document. This indication is a new "Location" header
with the following syntax:
Polk & Rosen [Page 16]
Internet Draft SIP Location Conveyance July 17th, 2005
Location = "Location" HCOLON Location-value *(COMMA
Location-value)
location-value = (addr-spec / option-tag / token)
addr-spec = cid-url / absoluteURI
option-tag = string
token = token / quoted-string
cid-url =
absoluteURI =
IANA Registered Option-tags are: loc-body, civic-loc, geo-loc,
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,
but does not have knowledge of where it is to include in the
message.
Unknown is a case in which the UAC is asking for help of any
intermediary to populate a location header with a by-reference URI,
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
Polk & Rosen [Page 17]
Internet Draft SIP Location Conveyance July 17th, 2005
could become the UAS target for future OPTIONS requests.
The following table extends the values in Table 2/3 of RFC3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Location Rr amdr o - - o o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Location Rr amdr o o o o o o o
The Location header MAY be added, modified, read or deleted if
present in a Request message listed above. Deleting a location
header appears detrimental for communicating a necessary piece of
information described throughout this document, unless this is an
act of hiding that information. Modifying this header, other than
correcting the header of some error, appears to cause more harm than
good, and is ill advised. Unless from the SIP Proxy/intermediary
generating an error response (see section 7.2), the location header
SHOULD NOT be modified or deleted if present in a Response. Only
the intermediary that is originating the header value in the
response SHOULD add a location header, if one is not yet present.
A Proxy/intermediary MAY add the location header in transit if one
is not present. A Proxy/intermediary MAY read the location header
in transit if present.
Here is an example INVITE that includes the proper Location and
Supported headers (with a reduced size multipart message body):
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Location: cid: alice123@atlanta.example.com, geo-loc
Supported: location
Accept: application/sdp, application/cpim-pidf+xml
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP here
Polk & Rosen [Page 18]
Internet Draft SIP Location Conveyance July 17th, 2005
--boundary1
Content-Type: application/cpim-pidf+xml
Content-ID: alice123@atlanta.example.com
...PIDF-LO with geolocation coordinates here
--boundary1--
The location header from the above INVITE:
Location: cid:alice123@atlanta.example.com, geo-loc
indicates the Content-ID location [RFC2392] within the multipart
message body of were location information is. The geo-loc option-
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:
Location: <server5@atlanta.example.com/alice123>, geo-loc
this would indicate location by-reference was included in this
message, and in the geo-loc format for whoever fetches it.
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
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, a new 4XX level error is called for to
indicate this is the problem with the message. This document
creates the new error code:
Polk & Rosen [Page 19]
Internet Draft SIP Location Conveyance July 17th, 2005
424 (Bad Location Information)
The 424 Bad Location Information Response code is a rejection of the
location contents, whether by-value or by-reference of the original
SIP Request. The server function of the recipient (UAS or
intermediary) had deemed this location by-reference or location by-
value to be bad. No further action by the UAC is expected. The UAC
can use whatever means it knows to verify/refresh its location
information before attempting the Request again.
This new error code will be IANA registered.
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 document.
7.3 Example PIDF-LO in Geo Format
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
a look at a location by-value message body, and secondly, give the
authors the ability to show how large this is to persuade readers
that this doesn't have to be shown in every example of this
document. Full example message flows will be in the appendixes of
Polk & Rosen [Page 20]
Internet Draft SIP Location Conveyance July 17th, 2005
this document.
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
change to its format, text or characteristics. Whether TLS or IPsec
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
characteristics. The examples in section 7.3 (Geo format) taken
from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for
the exact same position on the earth. The civic formatted PIDF-LO
is a little larger (i.e. more lines), but this is not substantial.
The differences between the two formats is within the <gp:location-
info> are of the examples. Other than this portion of each PIDF-LO,
the rest the same for both location formats.
<?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-08-01T10:00:00Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>33.001111N
96.68142W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<method>dhcp</method>
<provided-by><nena>www.cisco.com</nena></provided-by/>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
7.4 Example PIDF-LO in Civic Format
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
a look at a location by-value message body, and secondly, give the
authors the ability to show how large this is to persuade readers
Polk & Rosen [Page 21]
Internet Draft SIP Location Conveyance July 17th, 2005
that this doesn't have to be shown in every example of this
document. Full example message flows will be in the appendixes of
this document.
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
change to its format, text or characteristics. Whether TLS or IPsec
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
characteristics. The examples in section 7.3 (Geo format) taken
from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for
the exact same position on the earth. The civic formatted PIDF-LO
is a little larger (i.e. more lines), but this is not substantial.
The differences between the two formats is within the <gp:location-
info> are of the examples. Other than this portion of each PIDF-LO,
the rest the same for both location formats.
<?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-08-01T10:00:00Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3>
<cl:HNO>3913</cl:HNO>
<cl:A6>Treemont</cl:A6>
<cl:STS>Circle</cl:STS>
<cl:PC>76034</cl:PC>
<cl:LMK>Polk Place</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
</gp:location-info>
<method>dhcp</method>
<provided-by><nena>www.cisco.com</nena></provided-by/>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
Polk & Rosen [Page 22]
Internet Draft SIP Location Conveyance July 17th, 2005
8. User Agent-to-User Agent Location Conveyance
The offered solution here for the User-to-User location conveyance
between UAs is used with the INVITE, OPTIONS, UPDATE, MESSAGE,
SUB/NOT and PUBLISH Methods in the following subsections.
All complete message flows in this document will be with well-formed
SIP messages. That said, there will be a few individual example
messages containing only the key headers to convey the point being
made that do not include all the requisite SIP headers. As you will
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
Below is a common SIP session set-up sequence between two user
agents. In this example, Alice will provide Bob with her geographic
location in the INVITE message.
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
| ACK [M3] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 1. UA-UA with Location in INVITE
User agent Alice invites user agent Bob to a session [M1 of Figure
1].
INVITE sips:bob@biloxi.example.com SIP/2.0
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Supported: Location
Location: loc-body, geo-loc
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.
Polk & Rosen [Page 23]
Internet Draft SIP Location Conveyance July 17th, 2005
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.
Polk & Rosen [Page 24]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 25]
Internet Draft SIP Location Conveyance July 17th, 2005
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]
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
Polk & Rosen [Page 26]
Internet Draft SIP Location Conveyance July 17th, 2005
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 Civic PIDF-LO goes here]
--boundary1--
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
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 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-Length: ...
Polk & Rosen [Page 27]
Internet Draft SIP Location Conveyance July 17th, 2005
--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]
--boundary1--
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.
Polk & Rosen [Page 28]
Internet Draft SIP Location Conveyance July 17th, 2005
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;
INVITE sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Supported: location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
Polk & Rosen [Page 29]
Internet Draft SIP Location Conveyance July 17th, 2005
...
--boundary1
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
--boundary1--
M2 - Bob 200 OKs this INVITE and includes his location back to Alice
(with his distribution indication set to "yes").
If Alice included a location header with a "convey-uas" option-tag:
INVITE sips:bob@biloxi.example.com SIP/2.0
Location: convey-uas
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
Polk & Rosen [Page 30]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 31]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 32]
Internet Draft SIP Location Conveyance July 17th, 2005
(Unauthorized) or 407 (Proxy Authentication Required) challenged.
An OPTIONS Request can be redirected to a server that knows the
UAC's location.
A 424 (Bad Location) is the proper indication if the queried server
has no knowledge of the UAC's location. An Unsupported header MUST
be in this 424 Response indicating "location" was not supported.
[alternate M2 in Figure 2b]
SIP/2.0 424 (Bad Location Information)
To: server1
From: Alice
Unsupported: location
8.2.2 OPTIONS Request to Learn UAS's Location
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
Polk & Rosen [Page 33]
Internet Draft SIP Location Conveyance July 17th, 2005
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
another user, the MESSAGE Method is to be used. The logic here is
as follows:
Polk & Rosen [Page 34]
Internet Draft SIP Location Conveyance July 17th, 2005
- UPDATE isn't appropriate because it is for the updating of
session capabilities and parameters of a dialog (after the
INVITE included location information).
- reINVITE isn't appropriate because it is only used (or only
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
conveyance outside of a dialog between two users (Alice and Bob in
this case). The following is an example of this communication.
To comply with privacy concerns raised in [RFC3693] and [ID-PIDF-
LO], a MESSAGE Method Request including a location message body
SHOULD S/MIME encrypt the message body (part) under the rules
outlined in [RFC3261]. This is not generally possible if the
location is conveyed by-reference in a Location header.
Implementers and end-users should be aware of this shortcoming of
this means for location conveyance.
UA Alice UA Bob
| MESSAGE [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
| |
Figure 3. UA-UA with Location in MESSAGE
Below is a sample, non-well-formed MESSAGE Method message from Alice
to Bob conveying her geo location:
[M1 of Figure 3]
OPTIONS sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Supported: location
Location: geo-loc
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
Polk & Rosen [Page 35]
Internet Draft SIP Location Conveyance July 17th, 2005
[Alice's geo format PIDF-LO goes here]
--broundary1--
The Content-type of M1 here is "multipart/mixed" to have a text
message incorporated into the message. Within the PIDF-LO message
body, there is a Content-Disposition of "render" to display this
location information to Bob when his UA receives it. The cautions
about whether or not Bob actually reads this message are outlined in
[RFC3428].
The 200 OK to M1 of Figure 3 is a simple OK.
A 424 (Bad Location Information) Response with a Unsupported header
(stating Location) is the proper response if Bob's UA cannot display
this information, but does understand the concept of location.
[Alternative M2 of figure 3]
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 M2 of figure 3]
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]
SIP/2.0 488 Not Acceptable Here
To: Bob
From: Alice
Location: civic-loc
8.4 UA-to-UA Location Conveyance Using UPDATE
The UPDATE Method is to be used any time location information is to
be updated between UAs setting up a dialog or after the dialog has
been established, no matter how long that dialog has been
Polk & Rosen [Page 36]
Internet Draft SIP Location Conveyance July 17th, 2005
operational. reINVITE is out of scope here, and the MESSAGE Method
is for non-dialog location conveyance between UAs only. The same
security properties used in the INVITE MUST be used in the UPDATE
message.
There are 3 conditions UPDATE is to be used to convey location
between Uas:
1) During dialog establishment, but before the final 200 OK (see
section 8.4.1)
2) After dialog establishment, but no prior location information has
been convey (see section 8.4.2), and
3) After dialog establishment, when a UA has determined it has moved
(see section 8.4.3)
8.4.1 UPDATE Updates Location During Session Establishment
Use#1 of the UPDATE Method is during dialog establishment, Alice
updates Bob with her location information. This might be different
location information than was in message [M1] of Figure 4a., or it
could be the first time Alice conveys location to Bob.
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| UPDATE [M2] |
|---------------------------------------->|
| 200 OK (UPDATE) [M3] |
|<----------------------------------------|
| 200 OK (INVITE) [M4] |
|<----------------------------------------|
| ACK (UPDATE) [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 4a. UA-UA with Location in UPDATE
[M2 of Figure 4a]
UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Supported: location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Polk & Rosen [Page 37]
Internet Draft SIP Location Conveyance July 17th, 2005
Content-Type: application/sdp
v=
...
--broundary1
Content-Type: application/cpim-pidf+xml
[Alice's geo format PIDF-LO goes here]
--broundary1--
The above example has Alice also changing something within her
original SDP, but this is not necessary for this update of location
information.
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 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]
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 M2 UPDATE Request message, 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 M3 of figure 4a]
SIP/2.0 488 Not Acceptable Here
To: Bob
From: Alice
Location: civic-loc
Polk & Rosen [Page 38]
Internet Draft SIP Location Conveyance July 17th, 2005
8.4.2 UPDATE Updates Location After Session Establishment
Use #2 of the UPDATE Method is if a dialog *has been* set up between
more than one UA, say between Alice and Bob without location
conveyed in either direction, and location is now going to be sent
from one of those UAs to the other. For example, if Alice invites
Bob to a dialog, but does not include her location in that dialog
establishment. Anytime during that dialog, Alice uses the UPDATE
Method, not the INVITE Method (in a reINVITE), to update the
location parameters of that dialog by sending an UPDATE message,
even if it is from no location parameters to start with.
Once a dialog has been established, a UAC MUST NOT use the INVITE
Method to convey location. The UPDATE Method MUST be used.
Consider the following example message flow in Figure 4b.:
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| 200 OK (INVITE) [M2] |
|<----------------------------------------|
| ACK [M3] |
|<----------------------------------------|
| RTP |
|<=======================================>|
| UPDATE [M4] |
|---------------------------------------->|
| 200 OK (UPDATE) [M5] |
|<----------------------------------------|
| |
Figure 4b. UA-UA with Location in UPDATE
[M4 of Figure 4b]
UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Supported: location
Location: geo-loc
Content-Type: application/cpim-pidf+xml
[Alice's geo format PIDF-LO goes here]
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 4b]
SIP/2.0 424 Bad Location Information
Polk & Rosen [Page 39]
Internet Draft SIP Location Conveyance July 17th, 2005
To: Bob
From: Alice
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
Acceptable Here) is the appropriate response. This 488 MAY include
a location header indicating he does support the civic-loc format.
[Alternative M5 of figure 4b]
SIP/2.0 488 Not Acceptable Here
To: Bob
From: Alice
Location: civic-loc
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
Use#3 of the UPDATE Method is if one UA that already conveyed
location to the other UA, has moved since the dialog was originally
sent up. How a UA determines it has moved is out of scope for this
document.
However that "movement" trigger occurred, M4 of Figure 4c. is the
result: an UPDATE Method Request indicating new location by Alice.
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| 200 OK (INVITE) [M2] |
|<----------------------------------------|
| ACK [M3] |
|<----------------------------------------|
| RTP |
|<=======================================>|
Polk & Rosen [Page 4]
Internet Draft SIP Location Conveyance July 17th, 2005
**Alice's UA determines it has moved, and needs to update Bob**
| UPDATE [M4] |
|---------------------------------------->|
| 200 OK (UPDATE) [M5] |
|<----------------------------------------|
| |
Figure 4c. UA-UA with Location in UPDATE
Message M4 of Figure 4c. shows the UPDATE of Alice's location
information to Bob. That message may look like this (non-well-
formed SIP message):
[M4 of Figure 4c]
UPDATE sips:bob@biloxi.example.com SIP/2.0
To: Bob
From: Alice
Supported: location
Location: geo-loc
Content-Type: application/cpim-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]
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 M5 of figure 4c]
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
Polk & Rosen [Page 41]
Internet Draft SIP Location Conveyance July 17th, 2005
Acceptable Here) is the appropriate response. This 488 MAY include
a location header indicating he does support the civic-loc format.
[Alternative M5 of figure 4c]
SIP/2.0 488 Not Acceptable Here
To: Bob
From: Alice
Location: civic-loc
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
The PUBLISH Method Request [RFC3903] is for conveying state
information of a user agent to a compositor server for others to
query for that information. This creates the benefit of the user
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:
Compositor
UA Alice Server2
| PUBLISH [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
Figure 5. OPTIONS Request for 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]
PUBLISH sips:server2@atlanta.example.com SIP/2.0
To: server2
From: Alice
Accept: application/cpim-pidf+xml
Location: geo-loc
Expires: 21600
Content-type: application/cpim-pidf+xml
Polk & Rosen [Page 42]
Internet Draft SIP Location Conveyance July 17th, 2005
[Alice's geo formatted PIDF-LO goes here]
The record location on this compositor server MAY become the
location by-reference URI for future location conveyance by this
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
like this non-well-formed 200 OK message:
[M2 in Figure 5]
SIP/2.0 200 OK
To: server2
From: Alice
Location: geo-loc
SIP-ETag: alice987
Expires: 21600
The Location header copying the option-tag from the Request SHOULD
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
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
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]
SIP/2.0 424 (Bad Location Information)
To: server2
From: Alice
Unsupported: location
If a compositor server understands location, but does not prefer (or
like) the location format the UAC chose to convey location in, a 488
(Not Acceptable Here) would be the appropriate response. Within
this message, the 488 MUST indicate which format was not preferred
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
Polk & Rosen [Page 43]
Internet Draft SIP Location Conveyance July 17th, 2005
server received Alice's civic location and prefers her location in
the geo format
[alternate M2 in Figure 5]
SIP/2.0 488 Not Acceptable Here
To: server2
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.
Polk & Rosen [Page 44]
Internet Draft SIP Location Conveyance July 17th, 2005
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] |
|<----------------------------------------|
Polk & Rosen [Page 45]
Internet Draft SIP Location Conveyance July 17th, 2005
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.
Polk & Rosen [Page 46]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 47]
Internet Draft SIP Location Conveyance July 17th, 2005
(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
Polk & Rosen [Page 48]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 49]
Internet Draft SIP Location Conveyance July 17th, 2005
"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.
Polk & Rosen [Page 50]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 51]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 52]
Internet Draft SIP Location Conveyance July 17th, 2005
...
--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
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)
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.
Polk & Rosen [Page 53]
Internet Draft SIP Location Conveyance July 17th, 2005
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
To: psap1
From: Alice
Location: geo-loc
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
[M3 of Figure 7b]
INVITE sips:sos@psap1.atlanta.us 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
Polk & Rosen [Page 54]
Internet Draft SIP Location Conveyance July 17th, 2005
Content-Type: application/cpim-pidf+xml
(Alice's geo PIDF-LO goes here)
10. Meeting RFC3693 Requirements
Section 7.2 of [RFC3693] details the requirements of a "using
protocol". They are:
Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage of the
LO.
This document requires, in Section 7, that SIP entities sending or
receiving location MUST obey such instructions.
Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective
parties, that is, key establishment is the responsibility of the
using protocol.
[RFC3261] and the documents it references define the key establish
mechanisms.
Req. 6. (Single Message Transfer) In particular, for tracking of
small target devices, the design should allow a single
message/packet transmission of location as a complete
transaction.
This document specifies that the LO be contained in the body of a
single message.
11. Open issues
This is a list of open issues that have not yet been addressed to
conclusion:
1) Should a Proxy somehow label its location information in the 4XX
(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
Polk & Rosen [Page 55]
Internet Draft SIP Location Conveyance July 17th, 2005
Patrik Faltstrom.
Options to this are use the Content-Type headers associated with
each message body part, using either:
A) multipart/mixed - because they could be considered different
B) multipart/alternative - for one application to use only one, and
allowing another application to use another
C) multipart/related - because they could be considered similar
enough as they each deal with location
2) May add a section for end-to-middle in a services model
12. Security Considerations
Conveyance of geo-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.
13. IANA Considerations
This section defines two new 4XX error response codes within the
sip-parameters section of IANA. [NOTE: RFC XXXX denotes this
document.
13.1 IANA Registration for Response Code 4XX
Reference: RFC-XXXX (this document)
Response code: 424
Default reason phrase: Bad Location Information
13.2 IANA Registration for Response Code 4XX
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
Polk & Rosen [Page 56]
Internet Draft SIP Location Conveyance July 17th, 2005
14. Acknowledgements
To Dave Oran for helping to shape this idea. To Jon Peterson and
Dean Willis on guidance of the effort. To Henning Schulzrinne,
Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for
constructive feedback.
To Paul Kyzivat for inspiring some of the recent text addressing
lingering issues the authors could not resolve.
15. References
15.1 References - Normative
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for
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
Locators", RFC 2393, August 1998
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
Polk & Rosen [Page 57]
Internet Draft SIP Location Conveyance July 17th, 2005
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",
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
Session Initiation Protocolö, draft-ietf-sipping-session-
policy-req-00", Internet Draft, June, 2003, "work in
progress"
[ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet
Draft, Feb 2004, Work in progress
[ID-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping-
emergency-arch", Internet Draft, Feb 2004, work in progress
Author Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike 33.00111N
Richardson, Texas 75082 USA 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.
Polk & Rosen [Page 58]
Internet Draft SIP Location Conveyance July 17th, 2005
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>
Polk & Rosen [Page 59]
Internet Draft SIP Location Conveyance July 17th, 2005
<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] |
Polk & Rosen [Page 60]
Internet Draft SIP Location Conveyance July 17th, 2005
|------------------------------------------>|
| 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
Polk & Rosen [Page 61]
Internet Draft SIP Location Conveyance July 17th, 2005
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
Polk & Rosen [Page 62]
Internet Draft SIP Location Conveyance July 17th, 2005
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>
Polk & Rosen [Page 63]
Internet Draft SIP Location Conveyance July 17th, 2005
<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">
Polk & Rosen [Page 64]
Internet Draft SIP Location Conveyance July 17th, 2005
<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>
Polk & Rosen [Page 65]
Internet Draft SIP Location Conveyance July 17th, 2005
<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.
Polk & Rosen [Page 66]
Internet Draft SIP Location Conveyance July 17th, 2005
[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>
Polk & Rosen [Page 67]
Internet Draft SIP Location Conveyance July 17th, 2005
</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>
Polk & Rosen [Page 68]
Internet Draft SIP Location Conveyance July 17th, 2005
<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
Polk & Rosen [Page 69]
Internet Draft SIP Location Conveyance July 17th, 2005
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>
Polk & Rosen [Page 70]
Internet Draft SIP Location Conveyance July 17th, 2005
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
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>
Polk & Rosen [Page 71]
Internet Draft SIP Location Conveyance July 17th, 2005
<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>
--boundary1--
Appendix A10. UA-to-UA Location Conveyance Using PUBLISH (from 8.5)
** This appendix is not be completed at this time.
Appendix A11. UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY
(from 8.6)
** This appendix is not be completed at this time.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
Polk & Rosen [Page 72]
Internet Draft SIP Location Conveyance July 17th, 2005
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
The Expiration date for this Internet Draft is:
January 17th, 2006
Polk & Rosen [Page 73]
| PAFTECH AB 2003-2026 | 2026-04-21 02:34:18 |