draft-ietf-sip-location-conveyance-00.txt   draft-ietf-sip-location-conveyance-01.txt 
SIP Working Group James M. Polk SIP Working Group James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Dec 17th, 2005 Brian Rosen Expiration: Jan 17th, 2006 Brian Rosen
File: draft-ietf-sip-location-conveyance-00.txt Emergicom NeuStar
Session Initiation Protocol Location Conveyance Session Initiation Protocol Location Conveyance
draft-ietf-sip-location-conveyance-01.txt
June 17th, 2005 July 17th, 2005
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17th, 2005. This Internet-Draft will expire on January 17th, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document presents the framework and requirements for usage of This document presents the framework and requirements for usage of
the Session Initiation Protocol (SIP) to convey user location the Session Initiation Protocol (SIP) to convey user location
information from one Session Initiation Protocol (SIP) entity to information from one Session Initiation Protocol (SIP) entity to
another SIP entity. We consider cases where location information is another SIP entity. We consider cases where location information is
conveyed from end to end, as well as cases where message routing by conveyed from end to end, as well as cases where message routing by
intermediaries is influenced by the location of the session intermediaries is influenced by the location of the session
initiator. We offer a set of solutions to the requirements, each initiator, the user agent client (UAC). We offer a set of solutions
based on the scenario being addressed. to the requirements, each based on the scenario being addressed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 3 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4
2. Location In the Body or in a Header . . . . . . . . . . . . . 6 2. Location In the Body or in a Header . . . . . . . . . . . . . 7
3. Scope of Location in a Message Body . . . . . . . . . . . . . 7 3. Scope of Location Conveyance . . . . . . . . . . . . . . . . 8
4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 8 3.1 Scope of Location in a Message Body . . . . . . . . . . . 8
5. Requirements for UA-to-Proxy Server Location Conveyance . . . 9 3.2 Scope of Location in a Header . . . . . . . . . . . . . . 9
6. Additional Requirements for Emergency Calls . . . . . . . . . 10 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 10
7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 12 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 11
8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 13 6. Additional Requirements for Emergency Calls . . . . . . . . . 12
8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 13 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 14
8.1.1 UA-to-UA Using INVITE with Coordinate Format. . . . . 15 7.1 Indicating Support for Location by the UAC . . . . . . . 16
8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . 17 7.2 Location Rejection Responses . . . . . . . . . . . . . . 19
8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 20 7.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 20
8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 23 7.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 21
8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 27 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 23
8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 28 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 23
8.6 424 "Bad Location Information" Response Code . . . . . . 28 8.1.1 UA-to-UA Using INVITE w/ Geo Format w-w/o S/MIME . . 25
9. Special Considerations for Emergency Calls . . . . . . . . . 28 8.1.2 UA-to-UA Using INVITE w/ Civic Format w-w/o S/MIME . 26
9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 29 8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 28
9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 34 8.2 OPTIONS Method and Location . . . . . . . . . . . . . . . 31
9.3 425 "Retry Location Body" Response Code . . . . . . . . . 38 8.2.1 OPTIONS Request to Learn UAC's Location . . . . . . . 31
10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 39 8.2.2 OPTIONS Request to Learn UAS's Location . . . . . . . 33
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.3 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8.4 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 36
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 8.4.1 UPDATE Updates Location During Session
13.1 IANA Registration for Response Code 424 . . . . . . . . 40 Establishment . . . . . . 37
13.2 IANA Registration for Response Code 425 . . . . . . . . 40 8.4.2 UPDATE Updates Location After Session
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 Establishment . . . . . . 39
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.4.3 UPDATE Updates Location After a UA Moves
15.1 Normative References . . . . . . . . . . . . . . . . . 40 in a Dialog . . . . . . 40
15.2 Informative References . . . . . . . . . . . . . . . . . 40 8.5 Location Conveyance Using PUBLISH . . . . . . . . . . . . 42
16. Author Information . . . . . . . . . . . . . . . . . . . . . 41 8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 44
9. Special Considerations for Emergency Calls . . . . . . . . . 47
9.1 Emergency UAC Behavior Rules . . . . . . . . . . . . . . 49
9.2 Emergency UAS/Intermediary Behavior Rules . . . . . . . . 50
9.3 Basic Emergency Message Flow Examples . . . . . . . . . . 52
10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 55
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 55
12. Security Considerations . . . . . . . . . . . . . . . . . . . 56
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 56
13.1 IANA Registration for Response Code 424 . . . . . . . . 56
13.2 IANA Registration for Response Code 425 . . . . . . . . 56
13.3 IANA Registration for the SIP Location Header . . . . . 56
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
15.1 Normative References . . . . . . . . . . . . . . . . . 57
15.2 Informative References . . . . . . . . . . . . . . . . . 58
Author Information . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . 72
1. Introduction 1. Introduction
This document presents the framework and requirements for the usage This document presents the framework and requirements for the usage
of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of
user location information described by [RFC3693] from a SIP entity user location information described by [RFC3693] from a SIP entity
to another SIP entity. to another SIP entity.
There are several situations in which it is appropriate for SIP to There are several situations in which it is appropriate for SIP to
be used to convey Location Information (LI) from one SIP entity to be used to convey Location Information (LI) from one SIP entity to
another. This document specifies requirements when a SIP UAC knows another. This document specifies requirements when a SIP UAC knows
its location by some means not specified herein, and needs to inform its location by some means not specified herein, and needs to inform
another SIP entity. One example is one user agent informing another 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 user agent where it is (i.e. you want to tell your friend where you
are). 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 Another example is to reach your nearest pizza parlor. A chain of
pizza parlors may be contacted through a single well known uri pizza parlors may be contacted through a single well known uri
(sip:pizzaparlor.com). This SIP message could be forwarded to the (sip:pizzaparlor.com). This SIP message could be forwarded to the
closest franchise by the pizzaparlor.com proxy server. The closest franchise by the pizzaparlor.com proxy server. The
receiving franchise UAS uses the location information of the UAC to receiving franchise UAS uses the location information of the UAC to
determine the location your delivery. determine the location your delivery.
Another important example is emergency calling. A call to Another important example is emergency calling. A call to
sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The
skipping to change at page 3, line 40 skipping to change at page 4, line 7
will also not discuss the contents of the SIP message body part that will also not discuss the contents of the SIP message body part that
is the Location Object (LO) itself. We will specify the is the Location Object (LO) itself. We will specify the
requirements for SIP qualifying as a "using protocol" as defined by requirements for SIP qualifying as a "using protocol" as defined by
Geopriv in [RFC3693]. Geopriv in [RFC3693].
Sections 7, 8 and 9 give specific examples (in well-formed SIP Sections 7, 8 and 9 give specific examples (in well-formed SIP
messages) of SIP UA and Proxy behavior for location conveyance, the messages) of SIP UA and Proxy behavior for location conveyance, the
last of which is a section devoted to the unique circumstances last of which is a section devoted to the unique circumstances
regarding emergency calling. Section 10 addresses how this document regarding emergency calling. Section 10 addresses how this document
adheres to the requirements specified in [RFC3693] (Geopriv adheres to the requirements specified in [RFC3693] (Geopriv
Requirements). Section 11 lists the current open issues with Requirements). Sections 11 and 12 list the current open issues with
location conveyance in SIP, and the new open issues recently location conveyance in SIP, and the new open issues recently
discovered as a result of the added effort to this revision. discovered as a result of the added effort to this revision.
Section 13 IANA registers 2 new Response codes. Section 13 IANA registers 2 new Response codes.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
skipping to change at page 4, line 4 skipping to change at page 4, line 22
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
1.2 Changes from Prior Versions 1.2 Changes from Prior Versions
[NOTE TO RFC-EDITOR: If this document is to be published as an RFC, [NOTE TO RFC-EDITOR: If this document is to be published as an RFC,
this section is to be removed prior to that event.] this section 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 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: WG version -02 to this SIP WG item document version -00:
- Changed which WG this document is in from SIPPING to SIP due to - Changed which WG this document is in from SIPPING to SIP due to
the extension of the protocol with new Response codes (424 and the extension of the protocol with new Response codes (424 and
425) for when there is an error involving the LO message body. 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 - Moved most of the well formed SIP messages out of the main body of
this document and into separate appendixes. This should clean up this document and into separate appendixes. This should clean up
the document from a readability point of view, yet still provide the document from a readability point of view, yet still provide
skipping to change at page 7, line 5 skipping to change at page 4, line 204
Pol] are applicable to routing based on location, and are Pol] are applicable to routing based on location, and are
incorporated in these requirements by reference. incorporated in these requirements by reference.
It is conceivable to create a new header for location information. It is conceivable to create a new header for location information.
However, [RFC3693] prefers S/MIME for security of Location However, [RFC3693] prefers S/MIME for security of Location
Information, and indeed S/MIME is preferable in SIP [RFC3261] for Information, and indeed S/MIME is preferable in SIP [RFC3261] for
protecting a message body. Accordingly, these requirements specify protecting a message body. Accordingly, these requirements specify
location be carried in a body when it is known to/stored in a user location be carried in a body when it is known to/stored in a user
agent. agent.
It is the use of S/MIME however, that limits routing based on It is the use of S/MIME however, that limits message routing based
location. Therefore, it seems appropriate to require that, where on the location of the UAC. Therefore, it seems appropriate to
routing is dependent on location, protection of the location require that, where routing is dependent on location, protection of
information object be accomplished by other mechanisms visible to the location information object be accomplished by other mechanisms
SIP proxies: here TLS ("sips:" from [RFC3261]). It is envisioned visible to SIP proxies: here TLS ("sips:" from [RFC3261]). It is
that S/MIME SHOULD be used when location information is not required envisioned that S/MIME SHOULD be used when location information is
by proxy servers, and TLS MUST be used when it is. The UAC will not required by proxy servers, and TLS MUST be used when it is. The
need to know the difference in the call's intent as to which UAC will need to know the difference in the call's intent as to
security mechanism to engage for LI conveyance. 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 This document does not address the behavior or configuration of SIP
Proxy Servers in these cases in order to accomplish location- Proxy Servers in cases in order to accomplish location-sensitive
sensitive routing. That is out of scope, and left for further routing. That is out of scope, and left for further study.
(complementary) efforts within the ECRIT WG.
3. Scope of Location in a Message Body 3. Scope of Location Conveyance
As concluded from the previous section, location information is to As concluded from the previous section, location information is to
be contained within a message body when the user agent has this be contained within a message body when the user agent has this
information locally. If either another body (SDP for example) is information locally. Location, if not known to the user agent, can
also to be sent in the message, or the LI is to be protected with be inserted by a SIP intermediary in transit, but there must be
S/MIME, the rules stated in section 7 of [RFC3261] regarding rules surround this capability.
multipart MIME bodies MUST be followed. The format and
privacy/security rules of [RFC3693] MUST too be followed. 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 User agents providing location can convey it incorrectly or
inappropriately. Therefore, there needs to be a new UAC error inappropriately. Therefore, there needs to be a new UAC error
response code created to inform the UAC by a UAS or Proxy of this response code created to inform the UAC by a UAS or Proxy of this
rejected rejected request message because of the location information in the
request message because of the location information in the message. message. If the SIP intermediary has location knowledge of the UAC,
it can include that information in an error message for use in a
There needs to be two new response codes currently not defined in subsequent request by that UAC, therefore, there needs to be two new
SIP: response codes currently not defined in SIP:
1) the first indicating the existing location information was not 1) the first indicating the existing location information was not
considered good by the viewing SIP element. considered good by the viewing or receiving SIP element.
There will be times in which the UAC does not know its location There will be times in which the UAC does not know its location
information, or another SIP entity knows the UAC's location better 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 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 document. In these times, a Proxy servers that know the location
of the UAC needs inform the UAC of its location information and have 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 that UAC include that message body in its next SIP message to the
same destination UA. This error code needs to be unique with same destination UA. This error code needs to be unique with
respect to the error code for merely incorrect location information respect to the error code for merely incorrect location information
from the UAC. from the UAC.
2) a second new response code indicating the existing location 2) a second new response code indicating the existing location
information was not considered good by the viewing SIP element, information was not considered good by the viewing SIP element,
one that includes a new message body with new location but in this case, the SIP element does have current and correct
information of the UAC to be used in a subsequent SIP Request by location information for the UAC to be one that included in a new
the UAC. message body to be used in a subsequent SIP Request by the UAC.
This second response code would be more applicable for cases in This second response code would be more applicable for cases in
which a SIP intermediary knows more about the location of the UAC which a SIP intermediary knows more about the location of the UAC
than the UAC, and needs to get the more appropriate LO into the SIP than the UAC, and needs to get the more appropriate location
message. This cannot occur with existing rules stating message information into the SIP message in order for it to be processed
bodies cannot be modified or added by intermediaries. This new correctly by it, and upstream SIP intermediaries. This cannot occur
response code message containing a new LO of the UAC appears the with existing rules stating message bodies cannot be modified or
best course of action. added by intermediaries. This new response code message containing
new location information of the UAC appears the best course of
action.
If there can be more than one LO within the same SIP message is not Since there can be multiple location observations of the same UAC,
addressed in this document at this time. 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.
If there can be more than one LO within the same SIP message and the 3.2 Scope of Location in a Header
message is routed by a SIP Proxy based on the contents of an LO,
this document currently does not specify how the proxy determines The first, best location for location relating to the endpoint is in
which LO to route the message based on. This is currently an open the endpoint. This allows the endpoint to send its location to
question as to whether this topic is addressed in the SIP WG or in wherever it wants, using whichever application it wants to use.
the ECRIT WG, therefore this is left for future study at this time. Keeping the location of an endpoint in a server on a network may be
detrimental to the operation at hand. One example is for emergency
calling. If the UA does not have its location, and a server does,
that means the server has to be 100% stateful of that UA's location
100% of the time, wherever that UA goes. [ID-EMER-ARCH] states
clearly that time is of the essence in placing an emergency call.
The time it takes to do a non-stateful lookup of a UAC's mobile
location will impact the time it takes SIP signaling to process that
location to determine which PSAP the call should be routed to.
Therefore, the use of location by-reference SHOULD be used as a last
resort. This becomes obviously the only choice if the UA has no
concept of location to include by-value in the first place. For
that reason, there needs to be an identifier in SIP messaging
indicating a UA is aware of location conveyance. This will greatly
speed up the processing at a SIP intermediary and limit its choices
when processing a SIP Request that may require location to be
present in the SIP message (such as emergency calling). Sections 6
and 9 delve deep into this topic.
This indication of location awareness MUST be outside a message
body, therefore in a header - and as one does not exist today
related to location, this document will create one. Section 7
details the many purposes of this header, including the ability to
convey which location format a UAC is transmitting, or a UAS wants.
4. Requirements for UA-to-UA Location Conveyance 4. Requirements for UA-to-UA Location Conveyance
The following are the 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 Situations where routing is not based on the LI of either UA, and
location is stored/cached in the UAC: location is stored/cached in the UAC:
U-U1 - Dialog-initiating SIP Requests and their responses MUST U-U1 - Dialog-initiating SIP Requests and their responses MUST
support Location Conveyance support Location Conveyance
U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location
Conveyance Conveyance
U-U3 - Other SIP Requests SHOULD support Location Conveyance U-U3 - Other SIP Requests SHOULD support Location Conveyance
U-U4 - UAC Location information SHOULD remain confidential e2e U-U4 - UAC Location information SHOULD remain confidential e2e
to the destination UAS except when the session is to an to the destination UAS except when the session is to an
identifiable emergency endsystem. identifiable emergency endsystem.
U-U5 - UAC MUST not use S/MIME on the Location Object message body U-U5 - UAC MUST not use S/MIME on the Location message body
if the message is a dialog related or MESSAGE Request if the message is a dialog related or MESSAGE Request
message unless the UAC has a pre-established association message unless the UAC has a pre-established association
with the routing SIP intermediary. with the routing SIP intermediary.
U-U6 - UAS Location information SHOULD remain confidential e2e U-U6 - UAS Location information SHOULD remain confidential e2e
to the destination UAC except when the session is to/from an to the destination UAC except when the session is to/from an
identifiable emergency endsystem. identifiable emergency endsystem.
Emergency callback is one example where this may apply. Emergency callback is one example where this may apply.
U-U7 - The privacy and security rules established within the U-U7 - The privacy and security rules established within the
Geopriv Working Group that would categorize SIP as a 'using Geopriv Working Group that would categorize SIP as a 'using
protocol' MUST be met [RFC3693]. See Section 10 for protocol' [RFC3693] MUST be met. See Section 10 for
analysis. analysis.
U-U8 - Location information MUST be contained in the location U-U8 - Location information SHOULD be contained in the location
Object as defined in [ID-PIDF-LO], which will satisfy all Object as defined in [ID-PIDF-LO], which will satisfy all
format requirements for interoperability. format requirements for interoperability.
U-U9 - User Agents and Proxies SHOULD be able to handle SIP 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 messages in which Location Information is fragmented across
multiple packets. multiple packets.
U-U10 - There MUST be a unique UAC error response code informing U-U12- There MUST be a unique UAC error response code informing the
the UAC it did not provide applicable location information. UAC it did not provide applicable location information.
U-U11 - There MUST be a means for publishing location state 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 information for a particular presentity to a Presence
Compositor Server Compositor Server.
U-U12 - User Agents and Proxies SHOULD be able to handle SIP U-U15- User Agents and Proxies SHOULD be able to process SIP
messages which contain more than one Location Object. 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 5. Requirements for UA-to-Proxy Server Location Conveyance
The following are the requirements for UA-to-Proxy Server Location The following are the requirements for UA-to-Proxy Server Location
Conveyance situations: Conveyance situations:
U-PS1 - MUST work with dialog-initiating SIP Requests and U-PS1 - MUST work with dialog-initiating SIP Requests and
responses, as well as the SIP MESSAGE method [RFC3428], and responses, as well as the SIP MESSAGE method [RFC3428], and
SHOULD work with most SIP messages. SHOULD work with most SIP messages.
U-PS2 - UAC location information SHOULD remain opaque to U-PS2 - UAC location information SHOULD remain opaque to
intermediaries the message was not addressed to, but MUST intermediaries the message was not addressed to, but MUST
be useable (i.e. viewable) by intermediary proxy servers be useable (i.e. viewable) by intermediary proxy servers
requiring location knowledge of the UAC to properly route requiring location knowledge of the UAC to properly route
the message. the message.
U-PS3 - The privacy and security rules established within the 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 Geopriv Working Group which would categorize SIP as a
'using protocol' MUST be met [RFC3693]. 'using protocol' MUST be met [RFC3693].
U-PS4 - Proxy servers MUST NOT modify or remove an LO message body U-PS5 - Proxy servers MUST NOT modify or remove an location message
part ([RFC3261] currently forbids this). body part ([RFC3261] currently forbids this).
U-PS5 - A SIP message containing a Location Object MUST NOT be U-PS6 - A SIP message containing location information MUST NOT be
rejected by a SIP intermediary because the message body rejected by a SIP intermediary because the message body
part or LO itself was not understood (except when the part or LO itself was not understood (except when the
intermediary complies with requirement U-PS7 below, or when intermediary complies with requirement U-PS8 below, or when
the SIP message is addressed to that intermediary). the SIP message is addressed to that intermediary).
With regards to requirement U-PS5, not all SIP Proxies are expected With regards to requirement U-PS6, not all SIP Proxies are expected
to route messages based on the contained Location Object from the to route messages based on the contained location information from
UAC. There will likely be a SIP Proxy able to perform this function the UAC. There will likely be a SIP Proxy able to perform this
downstream, and the original SIP message needs to reach that function downstream, and the original SIP message needs to reach
location enabled Proxy to route correctly. that location enabled Proxy to route correctly.
U-PS6 - There MUST be a unique UAC error response code informing U-PS7 - There MUST be a unique UAC error response code informing
the UAC it did not provide applicable location information. the UAC it did not provide applicable location information.
U-PS7 - There MUST be a unique UAC error response code informing U-PS8 - There MUST be a unique UAC error response code informing
the UAC it did not provide applicable location information, the UAC it did not provide applicable location information,
and to include the location information contained in the and to include the location information contained in the
message body of the error message for usage in the UAC's message body of the error message for usage in the UAC's
next attempt to the same UAS of the original message. next attempt to the same UAS of the original message.
6. Additional Requirements for Emergency Calls 6. Additional Requirements for Emergency Calls
Emergency calls have requirements that are not generally important Emergency calls have requirements that are not generally important
to other uses for location in SIP: to other uses for location in SIP:
skipping to change at page 11, line 33 skipping to change at page 4, line 515
activated. This could, and likely will, provide any new location activated. This could, and likely will, provide any new location
information to the UA from somewhere far away from the UA (perhaps information to the UA from somewhere far away from the UA (perhaps
the user's corporate facility). the user's corporate facility).
E-5 - A call transfer between response centers MUST NOT be E-5 - A call transfer between response centers MUST NOT be
considered a violation of the distribution privacy attribute considered a violation of the distribution privacy attribute
contained within the location object. contained within the location object.
This transfer will likely be for legitimate reasons; for example, This transfer will likely be for legitimate reasons; for example,
the session was misrouted to the wrong PSAP, and is referred the session was misrouted to the wrong PSAP, and is referred
[RFC3515] to the correct one. [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, E-6 Location information MUST be transmitted, if known to the UAC,
in all calls to a PSAP, even in the case it is not considered in all calls to a PSAP, even in the case the location
reliable. information known to the UAC is not considered reliable by the
UAC.
With that in mind, it is important to distinguish the location With that in mind, it is important to distinguish the location
information learned locally from LI learned over a VPN; which in information learned locally from location information learned over a
itself is useful additional information to that PSAP operator. VPN; which in itself is useful additional information to that PSAP
operator.
E-7 THE UA must provide the actual LI of the endpoint, and not E-7 The UA must provide the actual location of the endpoint, and
location which might have been erroneously given to it by, e.g. not location which might have been erroneously given to it by,
a VPN tunnel DHCP server. e.g. a VPN tunnel DHCP server.
E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a 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 session. If this is supported by the UAC, all NOTIFY messages
MUST contain the UAC's location information. MUST contain the UAC's location information.
This is a means for the emergency response centers to maintain a This is a means for the emergency response centers to maintain a
location the callers in distress. 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 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 this subscription, as this will provide a means of alert to the
user who does not wish this capability to remain enabled. user who does not wish this capability to remain enabled.
7. Location Conveyance using SIP 7. Location Conveyance using SIP
Geopriv is the IETF working group assigned to define a Location Geopriv is the IETF working group assigned to define a Location
Object for carrying within another protocol to convey geographic Object for carrying within another protocol to convey geographic
location of an endpoint to another entity. This Location Object location of an endpoint to another entity. This Location Object
skipping to change at page 12, line 45 skipping to change at page 4, line 587
is to be used. is to be used.
Several SIP Methods are capable (and applicable) to carry the LO Several SIP Methods are capable (and applicable) to carry the LO
message body. The Methods are divided into two groups, one for message body. The Methods are divided into two groups, one for
those applicable for UA-to-UA location conveyance, and the other those applicable for UA-to-UA location conveyance, and the other
group for UA-to-Proxy Location conveyance for routing the message. group for UA-to-Proxy Location conveyance for routing the message.
The list of applicable Methods for UA-to-UA location conveyance is: The list of applicable Methods for UA-to-UA location conveyance is:
INVITE, INVITE,
OPTIONS,
UPDATE, UPDATE,
MESSAGE, MESSAGE,
SUBSCRIBE/NOTIFY, and SUBSCRIBE/NOTIFY, and
PUBLISH. PUBLISH.
The list of applicable Methods for UA-to-Proxy location conveyance The list of applicable Methods for UA-to-Proxy location conveyance
is: is:
INVITE, INVITE,
UPDATE, and UPDATE, and
MESSAGE MESSAGE
While the authors do not yet see a reason to have location conveyed While the authors do not yet see a reason to have location conveyed
in the OPTIONS, ACK, PRACK, BYE, REFER and CANCEL Methods, we do not in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a
see a reason to prevent carrying a LO within these Method Requests reason to prevent carrying a LO within these Method Requests as long
as long as the SIP message meets the requirements stated within this as the SIP message meets the requirements stated within this
document. document.
A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that 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 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 that can be required due to the timing of the INVITE to 200 OK
messages, with potential local/user policy requiring the called user messages, with potential local/user policy requiring the called user
to get involved in determining if the caller is someone they wish to to get involved in determining if the caller is someone they wish to
give location to (and at what precision). give location to (and at what precision).
For UA-to-Proxy location conveyance, there are two cases: one in For UA-to-Proxy location conveyance, there are two cases: one in
which all proxies on the path from the UA to the proxy that requires 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 location can be trusted with the LI, and one in which intermediate
proxies may not be trusted. The former may be implemented with proxies may not be trusted. The former may be implemented with
"hop-by-hop" security as specified in [RFC3261] using sips: (i.e. "hop-by-hop" security as specified in [RFC3261] using sips: (i.e.
TLS security). In particular, emergency call routing requires TLS security). In particular, emergency call routing requires
routing proxies to know location, and sips: protection is routing proxies to know the location of the UAC, and sips:
appropriate. The latter case is under study by the SIPPING working protection is appropriate. The latter case is under study by the
group under the subject "End to Middle" security [ID-End-Mid-Sec]. 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 Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to
convey location, SIP entities MUST adhere to the rules of [RFC3693], convey location, SIP entities MUST adhere to the rules of [RFC3693],
specifically the retention and distribution (privacy) attributes of specifically the retention and distribution (privacy) attributes of
a UA's location. When Alice is deciding how to transmit her a UA's location. When Alice is deciding how to transmit her
location, she should be keenly aware of the parameters in which she location, she should be keenly aware of the parameters in which she
wants her location to be stored and distributed. However, once she wants her location to be stored and distributed by who she transmits
sends that location information to Bob, he MUST also now obey her location to. However, once she sends that location information
Alice's wishes regarding these privacy attributes if he is deciding to Bob, he MUST also now obey Alice's wishes regarding these privacy
to inform another party about Alice. This is a fundamental attributes if he is deciding to inform another party about Alice.
principle of the Geopriv Working Group, i.e. "PRIVACY". 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:
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
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
--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:
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
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
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>
8. User Agent-to-User Agent Location Conveyance 8. User Agent-to-User Agent Location Conveyance
The offered solution here for the User-to-User location conveyance The offered solution here for the User-to-User location conveyance
between UAs is used with the INVITE, UPDATE, MESSAGE, SUB/NOT and between UAs is used with the INVITE, OPTIONS, UPDATE, MESSAGE,
PUBLISH Methods in the following subsections. SUB/NOT and PUBLISH Methods in the following subsections.
Well formed SIP messages are only in the main body of this document All complete message flows in this document will be with well-formed
for the first few examples. All well formed SIP message flows are SIP messages. That said, there will be a few individual example
in separate appendixes at the end of this document for brevity here, messages containing only the key headers to convey the point being
while there providing a complete set of example flows to review and made that do not include all the requisite SIP headers. As you will
comment on. 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 8.1 UA-to-UA using INVITE Method
Below is a common SIP session set-up sequence between two user Below is a common SIP session set-up sequence between two user
agents. In this example, Alice will provide Bob with her geographic agents. In this example, Alice will provide Bob with her geographic
location in the INVITE message. location in the INVITE message.
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | INVITE [M1] |
|---------------------------------------->| |---------------------------------------->|
| |
| 200 OK [M2] | | 200 OK [M2] |
|<----------------------------------------| |<----------------------------------------|
| |
| ACK [M3] | | ACK [M3] |
|---------------------------------------->| |---------------------------------------->|
| |
| RTP | | RTP |
|<=======================================>| |<=======================================>|
| | | |
Figure 1. UA-UA with Location in INVITE Figure 1. UA-UA with Location in INVITE
User agent Alice invites user agent Bob to a session [M1 of Figure User agent Alice invites user agent Bob to a session [M1 of Figure
1]. 1].
INVITE sips:bob@biloxi.example.com SIP/2.0
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 - Within this INVITE is a multipart body indication that it is
S/MIME encrypted [according to the rules of RFC3261] by Alice for S/MIME encrypted [according to the rules of RFC3261] by Alice for
Bob. One body part contains the SDP offered by Alice to Bob. Bob. One body part contains the SDP offered by Alice to Bob.
Alice's location (here coordinate based) is the other body part Alice's location (here coordinate based) is the other body part
contained in this INVITE. 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 - Bob responses with a 200 OK [M2] (choosing a codec as specified by
the Offer/Answer Model [RFC3264]). Bob can include his location the Offer/Answer Model [RFC3264]). Bob can include his location
in the 200 OK response, but this shouldn't be expected due to user in the 200 OK response, but this shouldn't be expected to due to
timing. If Bob wants to provide his location to Alice after the user timing. If Bob wants to provide his location to Alice after
200 OK, but before a BYE, the UPDATE Method [RFC3311] should be the 200 OK, but before a BYE, the UPDATE Method [RFC3311] should
used. 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. - 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 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 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 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 to S/MIME bodies, making their inclusion more or less moot and more
complex than necessary. complex than necessary.
The most relevant message in Figure 1 having to do with location is 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 (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 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 example will be shown. Section 8.1.1 will give an example of this
well formed INVITE message using a Coordinate location format. well formed INVITE message using a Coordinate location format.
Section 8.1.2 will give an example of this well formed INVITE Section 8.1.2 will give an example of this well formed INVITE
message using the civic location format. message using the civic location format.
8.1.1 UA-to-UA INVITE with Coordinate Location Using S/MIME 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 Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1. Figure 1 in section 8.1.
[Message 1 in Figure 1] [Message 1 in Figure 1]
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds ;branch=z9hG4bK776asdhds
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 15, line 41 skipping to change at page 4, line 1121
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--boundary1 --boundary1
Content-type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> [Alice's Geo PIDF-LO goes here]
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N
87.63649W</gml:coordinates>
</gml:Point>
</gml:location>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1-- --boundary1--
8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME 8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in 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 Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases not mandatory to use. This message below is show for those cases
where hop-by-hop security is deployed. where hop-by-hop security is deployed.
[Message 1 in Figure 1] [Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com Via: SIP/2.0/TCP pc33.atlanta.example.com
skipping to change at page 16, line 54 skipping to change at page 4, line 1158
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--broundary1 --broundary1
Content-Type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> [Alice's Geo PIDF-LO goes here]
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N
87.63649W</gml:coordinates>
</gml:Point>
</gml:location>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1-- --boundary1--
8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME 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 Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1 using the civic location format. Figure 1 in section 8.1 using the civic location format.
[Message 1 in Figure 1] [Message 1 in Figure 1]
skipping to change at page 18, line 21 skipping to change at page 4, line 1199
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--boundary1 --boundary1
Content-type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> [Alice's Civic PIDF-LO goes here]
<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-- --boundary1--
8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME 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 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 Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases not mandatory to use. This message below is show for those cases
where the sending user does not wish to use security mechanisms in where the sending user does not wish to use security mechanisms in
skipping to change at page 19, line 43 skipping to change at page 4, line 1239
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--broundary1 --broundary1
Content-type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> [Alice's Civic PIDF-LO goes here]
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" --boundary1--
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" 8.1.3 UA-to-UA Location Conveyance Involving 3 Users
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> As stated in [RFC3693], the distribution indication within the PIDF-
<timestamp>2005-11-11T08:57:29Z</timestamp> LO provides the information regarding if a learned PIDF-LO of
<status> another UA can be given out or not. The distribution element within
<gp:geopriv> the PIDF-LO looks like this:
<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:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> The values within this element are either "yes" or "no".
</gp:usage-rules>
</gp:geopriv> The element within the PIDF-LO indicating how long this location
</status> information is to be considered good/reliable for is the location
</tuple> expiration element, which looks like this:
</presence>
<gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention-expiry>
So, if Bob's location, which was transmitted to Alice, has not
reached the expiration time, and Bob set his distribution indication
to "can redistribute", then when Bob refers Alice to call Carol,
Alice can include both hers and Bob's LOs in that new INVITE (from
Alice to Carol). This will tell Carol where both Alice and Bob are.
Bob should be conscious of this capability when setting his
distribution indication with any location conveyance transmission.
Consider the following example message flow [Figure 1a] to show a
3-way communication of location, coupled with how a UA can include
someone else's location.
UA Alice Bob Carol
| INVITE [M1] | |
|---------------------------->| |
| 200 OK [M2] | |
|<----------------------------| |
| ACK [M3] | |
|---------------------------->| |
| RTP | |
|<===========================>| |
| reINVITE (hold) [M4] | |
|<----------------------------| |
| 200 OK [M5] | |
|---------------------------->| |
| REFER (Refer-to:Carol) [M6] | |
|<----------------------------| |
| NOTIFY [M7] | |
|---------------------------->| |
| 200 OK [M8] | |
|<----------------------------| |
| INVITE [M9] |
|------------------------------------------>|
| 200 OK [M10] |
|------------------------------------------>|
| RTP |
|<=========================================>|
| NOTIFY [M11] | |
|---------------------------->| |
| 200 OK [M12] | |
|<----------------------------| |
| BYE [M13] | |
|<----------------------------| |
| 200 OK [M14] | |
|---------------------------->| |
| |
Figure 1a. UA-to-UA with Location in REFER
M1 - Alice presents her location in the INVITE to Bob;
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
...
--boundary1
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
--boundary1-- --boundary1--
8.2 UA-to-UA Using MESSAGE Method M2 - Bob 200 OKs this INVITE and includes his location back to Alice
(with his distribution indication set to "yes").
Anytime a user transmits location information outside a dialog, the If Alice included a location header with a "convey-uas" option-tag:
MESSAGE Method is to be used. The logic here is as follows:
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
From: Bob
Unsupported: convey-uac
This indicates to Bob his request was partially fulfilled. Bob
knows his location was conveyed to Carol and that his REFER Request
was accepted, but Alice chose not to send Carol her location
information.
Regardless of Bob's request in the REFER, if he set his retention
indication to "no", Alice MUST NOT forward Bob's location to Carol,
even if he asked her to. This document currently doesn't have a
granular enough indication from Alice to Bob to tell Bob this piece
of information.
8.2 OPTIONS Method and Location
The OPTIONS Method can be used by a UAC to learn its location from a
SIP intermediary that may know this information, or to request the
location of a UAS. A combination of the location header option-tags
in an OPTIONS query can achieve this.
8.2.1 OPTIONS Request to Learn UAC's Location
If Alice knows which server knows her location, perhaps because her
UA was either configured with this server manually or through
registration to the network, she can send an OPTIONS query to it to
learn her location. Take the following message flow as an example:
UA Alice Server1
| OPTIONS [M1] |
|---------------------------------------->|
| 200 OK [M2] |
|<----------------------------------------|
Figure 2a. OPTIONS Request for Location
A non-well-formed message example of how an OPTIONS Method Request
could be used to query a server for the UAC's location might be:
[M1 of Figure 2a]
OPTIONS sips:server1@atlanta.example.com SIP/2.0
To: server1
From: Alice
Proxy-Require: location
Require: location
Location: unknown, geo-loc
Including both the "unknown" and "geo-loc" option-tags in the
Location header indicates the UAC wants to learn its location in the
geo format only. If the Location header were:
OPTIONS sips:server1@atlanta.example.com SIP/2.0
To: server1
From: Alice
Proxy-Require: location
Require: location
Location: unknown, geo-loc, civic
the UAC is asking for both formats to be in the reply.
The key to this request is the "unknown" option-tag. This, in an
OPTIONS Request, if telling the server the UAC doesn't know its
location, and to include the UAC's location in the 200 OK Response.
The presence or lack of presence of other option-tags indicate to
the server how its response will be formed. If no other option-tags
are present in the Location header of this OPTIONS Request, the
server is free to choose whatever format it wishes in the reply.
In the above partial OPTIONS Request, there is a Proxy-Require
header (if the intermediary is a Proxy) and a Require header (if the
intermediary is an instance of a B2BUA). If either apply to the
responding UAS in this transaction, and the location header included
an option-tag the UAS cannot answer, perhaps because it doesn't have
the UAC's civic location format, the 200 OK to this Request will
include what location format(s) is has, and indicates it does not
have the remainder of the request with the Unsupported header
indicating which formats were requested, but not available. An
example of this is the following partial SIP message;
[M2 in Figure 2a]
SIP/2.0 200 OK
To: server1
From: Alice
Unsupported: civic-loc
Content-type: application/cpim-pidf+xml
[Alice's geo formatted PIDF-LO goes here]
If location is to be returned as a by-reference location header
value, a subset of the 200 OK could look like this:
[M2 of Figure 2a]
SIP/2.0 200 OK
To: server1
From: Alice
Location: <www.atlanta.example.com/server1/alice123>
The above 200 OK example MAY include an additional option-tag
indicating the format or the location at that by-reference URI.
An OPTIONS Request for the location of the UAC MAY be 401
(Unauthorized) or 407 (Proxy Authentication Required) challenged.
An OPTIONS Request can be redirected to a server that knows the
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
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:
- UPDATE isn't appropriate because it is for the updating of - UPDATE isn't appropriate because it is for the updating of
session capabilities and parameters of a dialog (after the session capabilities and parameters of a dialog (after the
INVITE included location information). INVITE included location information).
- reINVITE isn't appropriate because it is only used (or only - reINVITE isn't appropriate because it is only used (or only
supposed to be used) for changing the parameters of an existing supposed to be used) for changing the parameters of an existing
dialog, and one might not exist in all cases of location dialog, and one might not exist in all cases of location
conveyance. conveyance.
This leaves MESSAGE as the only viable Request Method for location This leaves MESSAGE as the only viable Request Method for location
conveyance outside of a dialog between two users (Alice and Bob in conveyance outside of a dialog between two users (Alice and Bob in
this case). The following is an example of this communication. 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 UA Alice UA Bob
| MESSAGE [M1] | | 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
[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
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
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
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
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 |
|<=======================================>|
**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
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] | | 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
[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
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.
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] |
|<----------------------------------------|
Figure 2. UA-UA with Location in MESSAGE **Alice moves locations, causes a trigger**
Section 8.2.1 will give the well formed MESSAGE Method containing a | NOTIFY (new loc given) [M10] |
well formed Geopriv Location Object using the Coordinate location |---------------------------------------->|
format that fully complies with all security requirements - SIPS for | 200 OK (NOT) [M11] |
hop-by-hop security, and S/MIME for message body confidentiality |<----------------------------------------|
end-to-end, as well as adhering to the retention and distribution Figure 6a. UA-PROXY with Location in INVITE
concerns from [RFC3693]. Section 8.2.2 will show the Civic Location
format alternative to the same location, as conveyed from Alice to
Bob. This section does not adhere to confidentiality or integrity
concerns of [RFC3693], but does convey retention and distribution
indicators from Alice.
8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME The call flow shows this:
Below is M1 from Figure 2 in section 8.2. that is fully secure and - Alice called 911/112 (M1 of Figure 6a) and included here location
in compliance with Geopriv requirements in [RFC3693] for security in a PIDF-LO message body.
concerns.
[Message 1 in Figure 2] - The message was routed correctly (M2 of Figure 6a) (message
routing is not defined here).
MESSAGE sips:bob@biloxi.example.com SIP/2.0 - The call was accepted and RTP packets flowed.
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asegma - The PSAP operator, either manually or automatically, sent a
Max-Forwards: 70 SUBSCRIBE Method Request (M6 of Figure 6a) to Alice's UA to
To: Bob <sips:bob@biloxi.example.com> determine or refresh where she is located.
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com This SUBSCRIBE informs Alice's UA with all it needs to look for
CSeq: 22756 MESSAGE (i.e. what constitutes a change in location, and perhaps which is
Content-Type: application/pkcs7-mime; the preferred location format for the NOTIFY messages to be sent
smime-type=enveloped-data; name=smime.p7m back to the PSAP.
Content-Disposition: attachment;
filename=smime.p7m handling=required - The SUB was accepted with a 200 OK (M7 of Figure 6a).
- Alice's UA immediately, according to [RFC3265], MUST send an
initial status to the subscriber (M8 of Figure 6a). In this
NOTIFY MUST be (perhaps another copy of the same) PIDF-LO from
Alice to the PSAP.
- The PSAP acknowledged receipt of this PIDF-LO in the 200 OK to the
NOTIFY (M9 of Figure 6a).
- If Alice and her UA move enough for the UA to detect what the
SUBSCRIBE considered "movement", Alice's UA, without Alice being
necessarily told, sends a new NOTIFY (M10 of Figure 6a) with this
new location PIDF-LO as a message body.
- This new NOTIFY is acknowledged with another 200 OK (M11 of Figure
6a).
The Subscription SHOULD be for as long as the PSAP operator
considers it needs to know if movement can occur at Alice's UA. In
other words, Alice's UA SHOULD be prepared to receive a SUBSCRIBE
with a very lengthy expires time, and not attempt to reduce the time
requested. When the PSAP considers it time to end the subscription,
it will actively refresh the subscription with a expires of 0, thus
terminating the it.
** the corresponding appendix has not be completed at this time.
9. Special Considerations for Emergency Calls
Calling for local emergency, such as 911 or 112 today, has special
handling characteristics. First of which is the identification of
the call as an emergency call. When a node detects a call is a
local emergency call, certain processes need to occur that are more
complicated in a SIP architecture than in the circuit switched
world. In the circuit switched world, a caller is tied to a known
Class-5 switch, or a PBX connected to a Class-5 switch. This has
the benefit of providing a location of the end of the wire of that
phone, or more accurately, to the termination point on a wall (of an
office or cube) or on the side of a house or building. Each of
these locations is just that, a physical location. This location
(typically the street address) is entered into a database that
provides a means for looking up where an emergency call came from
during that call's set-up to the PSAP. The look-up is to the
binding of that phone number to that street address.
The challenge in SIP is the disconnect of call processing, either by
the UA itself or by a SIP intermediary, from where the UAC is
located when this emergency call is made. A "call" here in SIP can
be for voice, video, instant messaging or something else - all of
this is considered a call in this document. If the call needs to be
routed to the proper PSAP by some network entity, for example
because the Request-URI didn't have an IP address in it, the routing
entity has to have enough information to route this call to the
proper PSAP.
The routing function towards the proper PSAP is out of scope of this
document, but this document must specify enough SIP capabilities and
information to that SIP intermediary to do the routing correctly
from the contents of that SIP message.
[ID-SIP-SOS] provides one means for identifying a SIP Request as an
emergency session set-up. Once that information is understood by a
routing SIP intermediary, the intermediary (Proxy or an instance of
a B2BUA) must look for the location of the UAC originating the
Request to determine internally or externally where to route the
message to. The mapping of a location to where to route the message
to is also out of scope of this document, and is currently under
investigation. The capability to include location of the UAC in a
SIP message is the task of this document. And this is where it is
separate from the task of defining how to convey location between
user agents that merely want to share location of the UAC. This SIP
intermediary MUST look into the SIP Request, for example an INVITE
Request Method message, for the location of the UAC to be included
in the message.
Location inclusion within a SIP Request will be by-value or by-
reference. By-value is the case in which the location information
is included or contained within the SIP message itself. By-
reference is the case in which the location of the UAC in a
(database) record or document on a server somewhere else, but the
UAC knows the URI to that record/document and includes only that URI
in the SIP Request.
Including this new Location header is not always enough. Therefore,
if the UAC chooses to require there be location recognizable by the
intermediary in order to process this message, the UAC will include
both the "Proxy-Require" and "Require" headers, each with "location"
as their option-tags. The reason for both is that the UAC will not
know the type of SIP element that is doing the routing to the PSAP.
[RFC3261] states the "Proxy-Require" header is for SIP Proxies to
process, and the "Require" header is for SIP UAs to process. Since
the SIP intermediary can be an instance of a B2BUA or a Border
Controller, and neither is guaranteed to adhere to the "Proxy-
Require" header, the Require header MUST be included as well in this
emergency SIP message.
A non-well formed message example would be:
INVITE sip:sos@psap1.tx.us
Proxy-Require: location
Require: location
Location: <location of "location", and/or type of location included>
If the intermediary understands this message and is able to learn
the UAC's location because it is recognizable as included in the
Request, or to perform a mapping function (locally or remotely) to
determine where to route the call (to the correct PSAP), the message
is forwarded towards that PSAP with the new Request-URI of that
PSAP.
NOTE: The ability and process of this mapping function (taking a
location and determining the correct PSAP for that location)
within the SIP intermediary is defined elsewhere.
If the intermediary does not understand this message and its
relationship to location, perhaps because it does not understand the
concept of routing based on the UAC's location, it needs to forward
the message to another intermediary that will understand how to take
location from the message and route it correctly, or communicate
with the UAC if there are issues with the message. The intermediary
MUST not reject the message because it does not understand the
concept of "location". This document does not define how this
occurs, as the offered solution here is to include a "Proxy-Require"
and a "Require" header in this original Request.
[NOTE: the authors are not sure where that needs to be defined -
here, or in another document. Another way to address this
inconsistency, one that is less forceful, is to mandate the
inclusion of the Supported header instead of the "Proxy-
Require" and a "Require" headers by the UAC in the original
Request. An option is to have the subsequent message from
the UAC remove the Proxy-Require and Require headers and
insert a Supported header, which will not cause a well
behaving intermediary to reject the request. Comments are
desired]
The ability of a PSAP to SUBSCRIBE to the caller's UA to learn if it
moves to a new location, thus changing where the first responders
need to be dispatched, is described in section 8.6 of this document.
That section goes into some detail on how this subscription can be
long lasting to receive repeated updates from the caller's UA if
there is movement.
9.1 Emergency UAC Behavior Rules
The following are the rules of behavior for the UAC transmitting an
emergency SIP Request:
1) The UAC MUST include a location header with a viable location
value indicating where the UAC is to aid the routing
intermediary.
If location is by-value, the location header will have a "loc-body"
option-tag, and the message will include a PIDF-LO message body
indicating the UAC's currently location.
If the location is by-reference, the location header will have the
URI of the location of that UAC as the header value.
Either of the above will indicate to the intermediary that the UAC
is knowledgeable of location, and indicated where the location can
be learned by the intermediary. If this is not present, the
intermediary will act accordingly and supply location other than in
a location message body. This gives the intermediary the ability to
add a location header with a uri of the location record from a
database that the UAS (in the PSAP) will access to learn the UAC's
location when necessary.
2) The UAC MUST include both the "Proxy-Require" and a "Require"
header indicating "location" is required for this message.
3) The UAC MUST understand any 425 (Retry Location Body) Response
message with the PIDF-LO included as a message body part for that
UAC to include in the subsequent retry INVITE to the PSAP as its
location.
NOTE: An open question remains in the case in which the UAC includes
what it thinks is a viable location by-value or by-reference
and receives a 488 (Not Acceptable Here) with an Unsupported
header indicating "Location".
Option#1 to this would be for the UAC to back off including the
"Proxy-Require" and a "Require" headers and merely put in a
Supported Header with "location" in the attempt to get the
message past the SIP intermediary that is rejecting the INVITE
Request message from a lack of understanding of location.
Comments are asked in this case.
4) the UAC SHOULD NOT S/MIME or SIPFRAG protect location
Information without certainty of knowledge the intermediary can
decrypt the message to learn the location of the UAC. This
defeats the purpose of an intermediary assisting in routing the
message correctly - which will be required for 911/112-type
request attempts.
5) the SIP Request from the UAC to the PSAP SHOULD be protected
through a SIPS-URI, TLS or IPsec, but the UAC MUST be prepared to
initially send the message, or a retransmission (based on a
timeout or rejection message) in cleartext to ensure the session
set-up does not fail due to security incompatibilities in
transit, or at the PSAP.
6) the UAC MUST include both a <provided-by> element and a <method>
element in the PIDF-LO message body indicating #1 the
organization that provided the location information to the UAC,
and #2 how the UAC learned its location information,
respectively.
7) The UAC SHOULD be prepared to receive a SUBSCRIBE Request message
from the PSAP seeking verification of its location. This
subscription SHOULD want to last for more than one NOTIFY back to
the subscriber, for the purposes of getting updates of movement
the calling (UAC) detects, based on what is in the original
SUBSCRIBE Request message. As such, this SUBSCRIBE SHOULD have a
lengthy Expires timer. The original (the calling) UAC MUST NOT
reduce the time of this Expires Timer if it accepts the
SUBSCRIBE. See section 8.6 for more on SUB/NOT and location
conveyance.
This SUBSCRIBE SHOULD provide within the message what it considers
to be "movement" by the emergency calling (UAC).
9.2 Emergency UAS/Intermediary Behavior Rules
The following are the rules of behavior for the UAS or intermediary
receiving an emergency SIP Request:
1) identifies that SIP Request as an emergency Request.
2) The intermediary looks for the "location" header to inform it
where location is within this message (by-reference or by-value),
and if the format of the location information is given as a hint.
3) The intermediary looks for a "Proxy-Require" and/or a "Require"
header indicating "location" is required for this message.
4) If the intermediary does not understand location, or does not
observe viable location information within this message MUST do
one of the following action items:
a) reject the message with a 488 (Not Acceptable Here) with a
Unsupported header indicating "location" if the intermediary
does not understand location and there is a "Proxy-Require"
and/or a "Require" header indicating "location"
b) if the intermediary does not understand location, and there is
no "Proxy-Require" and/or a "Require" header indicating
"location", the intermediary MUST not reject the message, but
MUST forward this message to another (upstream) SIP
intermediary for proper processing.
c) reject the message with a 425 (Retry Location Body) if it
understands the concept of location, but does not detect
location in the message, and has a current PIDF-LO for that
UAC. The UAC will know to reattempt the INVITE with this new
PIDF-LO message body.
d) if the intermediary understands the concept of location, but
does not detect location within this message, it MAY insert a
location by-reference, if known
Of particular concern to this option "d" above is the fact this
information never gets back to the UAC, so it MAY remain in the dark
as to its location. If the UAC does not understand location, which
SHOULD be indicated by the lack of presence of the Location header,
insertion is the best possible solution short of upgrading the UAC.
However, if the UAC includes a Location header, an intermediary
SHOULD NOT insert location by-reference and forward the message.
5) the intermediary MUST NOT delete a PIDF-LO message body
6) the intermediary that knows the concept of location SHOULD NOT
insert a location by-reference header value if there is a
location by-value currently in the SIP message from the UAC.
Behavior #5 above MUST NOT be done to satisfy Behavior #6 here, just
to get a by-reference location indication in the message.
7) If the UAC included a location header, but this was not deemed
usable, or determined to be incorrect, the intermediary MAY
reject the Request with one of the following response codes:
a) a 424 (Bad Location Information) response informing the UAC to
include its location in a subsequent attempt, or
b) a 425 (Retry Location Body) if the intermediary can include
what it considers to be current and accurate location
information to the UAC.
9.3 Basic Emergency Message Flow Examples
The following subsections provide a discussion on the basic message
flows for emergency messaging.
9.3.1 Basic INVITE with Location Body
Here is the basic message flow for Alice calling for help.
UA Alice Proxy PSAP
| INVITE (w/ PIDF-LO)[M1] |
|------------------>| |
| INVITE (w/ PIDF-LO) [M2] |
| |-------------------->|
| | 200 OK [M3] |
| |<--------------------|
| 200 OK [M4] | |
|<------------------| |
| ACK [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 7a. UA-PROXY with Location in INVITE
Consider Figure 7a as a very basic message flow establishing an
emergency call from Alice to the correct PSAP suiting her location.
[M1 of Figure 7a]
INVITE sips:sos@atlanta.com SIP/2.0
From: Alice
To: sos@
Proxy-Require: Location
Require: Location
Location: geo-loc
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1 --boundary1
Content-Type: text/plain Content-Type: application/sdp
Here's my location, Bob? v=0
...
--boundary1
Content-Type: application/cpim-pidf+xml
(Alice's geo PIDF-LO goes here)
Once the intermediary's mapping function determines the correct PSAP
for Alice's sos@ call to go to, the INVITE will look something like
this (with a changed Request-URI):
[M2 of Figure 7a]
INVITE sips:sos@psap1.atlanta.us SIP/2.0
From: Alice
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.
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
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
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
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
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.
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 --broundary1
Content-Type: application/cpim-pidf+xml Content-Type: application/cpim-pidf+xml
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp> <timestamp>2005-11-11T08:57:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 22, line 35 skipping to change at page 60, line 18
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
8.2.2 UA-to-UA MESSAGE with Civic Location Not Using S/MIME Appendix A2. INVITE and REFER between 3 UAs
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 2]
MESSAGE sip:bob@biloxi.example.com SIP/2.0
From: <sip:alice@atlanta.example.com>;tag=34589882
To: <sip:bob@biloxi.example.com>
Call-ID: 9242892442211117@atlanta.example.com
CSeq: 6187 MESSAGE
Content-Type: application/cpim-pidf+xml
Content-ID: <766534765937@atlanta.example.com>
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
8.3 UA-to-UA Location Conveyance Using UPDATE
UPDATE MUST NOT be used to send location information from UA-to-UA
unless location has already been sent in an INVITE or corresponding
200 OK that was the first message exchange in the same dialog set-
up. The same security properties used in the INVITE MUST be used in
the UPDATE message.
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
operational. reINVITE is out of scope here, and the MESSAGE Method
is for non-dialog location conveyance between UAs only.
One reason for this message being generated is if either UA that
sent its location information to the other UA (say in the INVITE and
corresponding 200 OK) is if either UA determines that is has moved
while the dialog has remained operational. How this movement is
determined is outside the scope of this document, but ultimately
should be configurable by local administration or the user of the
UA. By how much Alice has moved to trigger the "sense of movement"
(i.e. the need to send new location) to Bob is also outside the
scope of this specification, but ultimately should be configurable
by local administration or the user of the UA.
In Figure 3., we have an example message flow involving the UPDATE
Method. We are not including all the messages for space reasons. M1
is a well formed SIP message that contains Alice's location. During
the session set-up, Alice's UA knows it has moved while knowing too
the session has not been formally accepted by Bob. Alice's UA
decides to update Bob with her new location with an UPDATE Method
message. Messages M2, M3 and M4 have nothing to do with location
conveyance, therefore will not be shown in detail. Only M1 and M5
will be shown.
NOTE: A similar use for UPDATE is within the UA-to-Proxy Location In the following example, Alice presents her location in the INVITE
Conveyance section of this document. 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 UA Bob UA Alice Bob Carol
| INVITE [M1] | | INVITE [M1] | |
|---------------------------------------->| |---------------------------->| |
| | | 200 OK [M2] | |
| 183 (session Progress) [M2] | |<----------------------------| |
|<----------------------------------------| | ACK [M3] | |
| | |---------------------------->| |
| PRACK [M3] | | RTP | |
|---------------------------------------->| |<===========================>| |
| | | reINVITE (hold) [M4] | |
| ACK (PRACK) [M4] | |<----------------------------| |
|<----------------------------------------| | 200 OK [M5] | |
| | |---------------------------->| |
| UPDATE [M5] | | REFER (Refer-to:Carol) [M6] | |
|---------------------------------------->| |<----------------------------| |
| | | NOTIFY [M9] | |
| ACK (UPDATE) [M6] | |---------------------------->| |
|<----------------------------------------| | 200 OK [M10] | |
| | |<----------------------------| |
| 200 OK (INVITE) [M7] | | INVITE [M7] |
|<----------------------------------------| |------------------------------------------>|
| | | 200 OK [M8] |
|------------------------------------------>|
| RTP | | RTP |
|<=======================================>| |<=========================================>|
| NOTIFY [M9] | |
|---------------------------->| |
| 200 OK [M10] | |
|<----------------------------| |
| BYE [M11] | |
|<----------------------------| |
| 200 OK [M12] | |
|---------------------------->| |
| | | |
Figure 3. UA-UA with Location in UPDATE Figure A2. UA-to-UA with Location in REFER
The following section will include the M1 and M5 messages in detail, Appendix A3. UA-to-UA REFER with Civic Location Using S/MIME
but only in the civic format.
8.3.1 UA-to-UA UPDATE with Civic Location Not Using S/MIME In Figure A2., we have an example message flow involving the REFER
Method. The REFER itself does not carry location objects.
Here is the initial INVITE from Alice to Bob. 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 INVITE to Bob] [M1 of Figure A2] - Alice at Sears Tower
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds ;branch=z9hG4bK776asdhds
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
skipping to change at page 26, line 14 skipping to change at page 62, line 33
<cl:A3>Chicago</cl:A3> <cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO> <cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD> <cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6> <cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS> <cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC> <cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK> <cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR> <cl:FLR>1</cl:FLR>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<method>802.11</method> <provided-by><nena>www.cisco.com</nena></provided-by/>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
Alice moves locations (with her UA detecting the movement), causing Bob replies to Alice's INVITE with a 200 OK and includes his
her UA to generate an UPDATE message ([M5] of Figure 3) prior to location.
her UA receiving a final response from Bob. Here is that message:
M5 UPDATE to Bob [M2 of Figure A2] - Bob watching Cubs Game at Wrigley Field
UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds ;branch=z9hG4bKnashds8 ;received=10.1.3.33
Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Bob <sips:bob@biloxi.example.com> From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
From: Alice <sips:alice@atlanta.example.com>;tag=1928 Call-ID: a84b4c76e66710
Call-ID: a84b4c76e66710@pc33.atlanta.example.com CSeq: 314159 INVITE
CSeq: 10197 UPDATE Contact: <sip:bob@192.168.10.20>
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime; Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment; Content-Disposition: attachment;
filename=smime.p7m handling=required filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=bob 2890844530 2890844530 IN IP4 biloxi.example.com
c=IN IP4 10.1.3.33 c=IN IP4 192.168.10.20
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--boundary1 --boundary1
Content-type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:bob@biloxi.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp> <timestamp>2005-11-6T02:30:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civilAddress> <cl:civilAddress>
<cl:country>US</cl:country> <cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1> <cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3> <cl:A3>Chicago</cl:A3>
<cl:HNO>250</cl:HNO> <cl:A6>Addison</cl:A6>
<cl:PRD>South Upper</cl:PRD> <cl:HNO>1060</cl:HNO>
<cl:A6>Wacker</cl:A6> <cl:PRD>W</cl:PRD>
<cl:STS>Drive</cl:STS> <cl:STS>street</cl:STS>
<cl:PC>60606</cl:PC> <cl:LMK>Wrigley Field</cl:LMK>
<cl:NAM>Venice Cafe</cl:NAM> <cl:PC>60613</cl:PC>
<cl:FLR>1</cl:FLR>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<method>802.11</method> <provided-by>www.cisco.com</provided-by/>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
8.4 UA-to-UA Location Conveyance Using PUBLISH Bob refers Alice to Carol, and in M7, Alice includes both locations
in a single SIP message. This is possible because Bob set his
** This section could not be completed before submission time and retention value to "yes", thus allowing Alice to pass his location
will be completed shortly after IETF61. A thousand and one pardons. on to Carol.
8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY
This section was not completed in time for the ID cut-off, thus all
text was removed until it can be completed. The authors apologize.
8.6 424 "Bad Location Information" Error Response
In the case that a user agent server or SIP Proxy detects an error
in a message containing location information specific to that
message body, a new 4XX level error needs to be sent. This document
creates the new error code:
424 (Bad Location Information)
This will provide the UAC with directed feedback about the status of
location information it sent to that UAS or Proxy. The UAC MAY
attempt to retry sending the message providing its location.
This new error code will be IANA registered.
An example flow of this scenario will be included in the next
version of this internet draft.
9. Special Considerations for Emergency Calls
When a Proxy Server knows to look for a location message body to
route an emergency call as in [ID-EMER-ARCH].
Emergency calls, which might be detected as detailed in [ID-SIP-
SOS], have special rules for conveyance of location:
1. An emergency call MUST have all LI available to the UA, if any,
sent with the INVITE, and subsequent UPDATE or reINVITE messages
as a PIDF-LO in a body
2. The LO must be protected with sips: unless the attempt to
establish hop-by-hop TLS connection fails and cannot reasonably
be established in a very short (less than a second) time. In
such a case, the LO SHOULD be sent without TLS ONLY for those
hops that failed to support TLS establishment.
3. User Agents MUST NOT use S/MIME
4. User Agents MUST include the <provided-by> element in the PIDF-LO
(if known) to give the PSAP an indication as to who is
responsible for providing the UA with its location information.
Proxies MUST NOT remove a location message body at any time. In the
case where the Proxy knows the location of the UAC and does not
detect the UAC's location information message body in the message
(or determines the LO is bad), the Proxy generates a new 4XX (Retry
Location Body) error message that includes a location information
message body for that UAC to include in the subsequent message. The
user agent MUST include this message body in the subsequent
emergency message.
In the <provided-by> element of the PIDF-LO, the Proxy MUST identify
itself as the source of this location information. The user agent
MUST NOT alter this field's value if received from a Proxy server.
If the UAS of the PSAP receives a SIP request with multiple location
objects, it must determine which to use, since more than one may be
present. This specification does not limit the number of LOs in a
message, even in session mode.
9.1 UA-to-Proxy Routing the Message with INVITE (secure)
When Alice signifies "sos@" [per 3], her UA must understand this
message MUST NOT use S/MIME for the message body, because this is an
emergency call - otherwise the message will not properly route to
the correct destination. Two definite possibilities will exist for
how this message flow will occur [note: the message flows are not
being defined here, they are defined in [ID-EMER-ARCH], but two are
shown here to show the messages themselves]. The first possibility
has Alice sending her INVITE to her first hop Proxy, which
recognizes the message as an emergency message. The Proxy knows to
look into the message bodies for the location body; determine where
Alice is and route the call to the appropriate PSAP. This is shown
in Figure 4A.
UA Alice Proxy PSAP
| INVITE [M1] | |
|------------------>| |
| | INVITE [M2] |
| |-------------------->|
| | 200 OK [M3] |
| |<--------------------|
| 200 OK [M4] | |
|<------------------| |
| ACK [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 4A. UA-PROXY with Location in INVITE [M7 of Figure A2] - Alice tells Carol where she and Bob are
[M1 of Figure 4A]
INVITE sips:sos@atlanta.example.com SIP/2.0 INVITE sips:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;branch=z9hG4bK776asdhdt
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl To: Carol <sips:carol@chicago.example.com>
To: <sips:sos@atlanta.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301775
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: a84b4c76e66711@pc33.atlanta.example.com
CSeq: 31862 INVITE CSeq: 314160 INVITE
Contact: <sips:alice@atlanta.example.com> 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 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844531 2890844531 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49173 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
--boundary1 --boundary1
Once the Proxy receives M1 and recognizes it as an emergency INVITE Content-type: application/cpim-pidf+xml
Request, this proxy knows to look into the message body for a <?xml version="1.0" encoding="UTF-8"?>
location body part to determine the location of the UAC in order to <presence xmlns="urn:ietf:params:xml:ns:pidf"
match the location to an PSAP. Once this look-up occurs, the xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
message is sent directly to the PSAP (in message [M2]). xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
[M2 of Figure 4A] - Proxy has determined when to send message entity="pres:bob@biloxi.example.com">
<tuple id="sg89af">
INVITE sips:sos@192.168.10.20 SIP/2.0 <timestamp>2005-11-5T02:30:29Z</timestamp>
Via: SIP/2.0/TLS pc33.atlanta.example.com <status>
;branch=z9hG4bK74bf9 <gp:geopriv>
Max-Forwards: 69 <gp:location-info>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl <cl:civilAddress>
To: <sips:sos@atlanta.example.com> <cl:country>US</cl:country>
Call-ID: 3848276298220188511@atlanta.example.com <cl:A1>Illinois</cl:A1>
CSeq: 31862 INVITE <cl:A3>Chicago</cl:A3>
Contact: <sips:alice@atlanta.example.com> <cl:A6>Addison</cl:A6>
Content-Type: multipart/mixed; boundary=boundary1 <cl:HNO>1060</cl:HNO>
Content-Length: ... <cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS>
--boundary1 <cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC>
Content-Type: application/sdp <cl:civilAddress>
v=0 <method>dhcp</method>
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com <method>802.11</method>
c=IN IP4 10.1.3.33 <provided-by>www.cisco.com</provided-by/>
t=0 0 </gp:location-info>
m=audio 49172 RTP/AVP 0 4 18 <gp:usage-rules>
a=rtpmap:0 PCMU/8000 <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 --boundary1
Content-type: application/cpim-pidf+xml Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp> <timestamp>2005-11-6T02:30:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civilAddress> <cl:civilAddress>
<cl:country>US</cl:country> <cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1> <cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3> <cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO> <cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD> <cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6> <cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS> <cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC> <cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK> <cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR> <cl:FLR>1</cl:FLR>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<method>802.11</method> <method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/> <provided-by>www.marconi.com</provided-by/>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-6T18:30:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
The second probability in message flows is in Figure 4B. in which It is an open question of whether there should be a mechanism to
the first hop Proxy1 does not either: understand location, or does request or require the transmission of an LO. The LO is contained
not know where the appropriate PSAP is to route the message to. In in a body, so the available sip mechanisms do not apply.
either case, that Proxy(1) forwards the message to another Proxy(2)
for proper message routing ([ID-EMER-ARCH] talks to how this
occurs).
UA Alice Proxy1 Proxy2 PSAP Appendix A4. UAC to UAS or Proxy Using OPTIONS Method (from 8.2)
| INVITE [M1] | | | Appendix A5. UA-to-UA Using MESSAGE Method (from 8.3)
|------------>| | |
| | INVITE [M2] | |
| |------------>| |
| | | INVITE [M3] |
| | |------------>|
| | | 200 OK [M4] |
| | |<------------|
| | 200 OK [M5] | |
| |<------------| |
| 200 OK [M6] | | |
|<------------| | |
| ACK [M7] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 4B. UA-PROXY with Location in INVITE UA Alice UA Bob
In message flows similar to 4A and/or 4B, the Record-Route header | MESSAGE [M1] |
could be added by the proxies, this is OPTIONAL in usage and left to |---------------------------------------->|
other documents to refine. | 200 OK [M2] |
|<----------------------------------------|
| |
In the case of an identifiable emergency call, something that cannot Figure A5. UA-UA with Location in MESSAGE
happen is for any Proxy to Challenge [per RFC3261] the INVITE
message. In fact, while usage of the SIPS URI is encouraged and
SHOULD be used, it MUST NOT be mandatory for successful message
routing. If the first SIPS INVITE fails for security property
reasons, the second attempt by Alice (in these examples) MUST be
allowed to be in the clear, not challenged, and routed properly.
Security mechanisms MUST NOT fail any call attempt, and if they do
once, they MUST NOT be mandatory for the subsequent attempt for a
successful session set-up to an PSAP. The results of this are that
the Proxy that failed the first attempt for security reasons MUST be
aware of this failed attempt for the subsequent attempt that MUST
process without failure a second time. It must be assumed that the
INVITE in any instance is considered "well formed".
The remaining messages in both 4A and 4B are not included at this Appendix A6. UA-to-UA MESSAGE with Coordinate Location Using S/MIME
time. If the working groups wants these added, they will be in the
next revision of this document.
9.1.1 UA-to-Proxy Routing the Message with INVITE (unsecure) Below is M1 from Figure 2 in section 8.2. that is fully secure and
Below can be considered the initial unsecure INVITE M1 from Figures in compliance with Geopriv requirements in [RFC3693] for security
4A and 4A, or the second attempt message to an initial message that concerns.
was failed by a Proxy. This version of M1 is not using any security
measures and is using the civic format message body that is the
identical location to the previous example.
[Message M1 from Figure 4A] [Message 1 in Figure A5]
INVITE sip:sos@atlanta.example.com SIP/2.0 MESSAGE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;branch=z9hG4bK776asegma
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sips:bob@biloxi.example.com>
To: <sip:sos@atlanta.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 31862 INVITE CSeq: 22756 MESSAGE
Contact: <sip:alice@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 Content-Type: multipart/mixed; boundary=boundary1
Contact-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: text/plain
v=0 Here's my location, Bob?
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 --broundary1
Content-Type: application/cpim-pidf+xml
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N
87.63649W</gml:coordinates>
</gml:Point>
</gml:location>
<method>dhcp</method>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Appendix A7. UA-to-UA MESSAGE with Civic Location Not Using S/MIME
Below is a well-formed SIP MESSAGE Method message to the example in
Figure 2 in section 8.2 when hop-by-hop security mechanisms are
deployed.
[Message 1 in Figure A5]
MESSAGE sip:bob@biloxi.example.com SIP/2.0
From: <sip:alice@atlanta.example.com>;tag=34589882
To: <sip:bob@biloxi.example.com>
Call-ID: 9242892442211117@atlanta.example.com
CSeq: 6187 MESSAGE
Content-Type: application/cpim-pidf+xml
Content-ID: <766534765937@atlanta.example.com>
Content-Disposition: render
Content-Description: my location
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema- xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0" xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2005-11-11T08:57:29Z</timestamp> <timestamp>2005-11-11T08:57:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 34, line 10 skipping to change at page 68, line 52
<cl:A3>Chicago</cl:A3> <cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO> <cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD> <cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6> <cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS> <cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC> <cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK> <cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR> <cl:FLR>1</cl:FLR>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
Appendix A8. UA-to-UA Location Conveyance Using UPDATE (from 8.4)
9.2 UA-to-Proxy Routing with UPDATE
If the previous example of the location contained in the INVITE were
to account for the movement of Alice (and her UA) before the PSAP
responded with a 200 OK, the UPDATE method is the appropriate SIP
Request Method to use to update the proxies and PSAP personnel that
Alice has moved locations from where she initially made her set-up
request.
In this scenario (shown in the call flow of Figure 5A), Alice
sending the UPDATE message here may cause the Proxy to CANCEL an
existing pending INVITE Request, and retransmit INVITE to a NEW
PSAP(2), for example, if she walked across a street into a new PSAP
coverage area. The Proxy MUST remain transaction stateful in order
to be aware of the 200 OK Response from PSAP1. Upon receiving the
UPDATE from Alice and analyzing the location provided by the message
looking for a location change, either forwarding that message to
PSAP1 if the change is still within PSAP1's coverage area, or
deciding to forward a message to another PSAP covering where Alice
is now (PSAP2 in this case) with her new location. If the latter
change in destinations is required, the Proxy MUST CANCEL the
pending INVITE to PSAP1 (with a 487 "terminated request" being the
specified response).
SIPS SHOULD be used by Alice initially. Upon any failure of the
initial Request, Alice's UA MUST decide to send the new message
without SIPS.
UA Alice Proxy PSAP1 PSAP2 UA Alice UA Bob
| INVITE [M1] | | | | INVITE [M1] |
|---------------->| | | |---------------------------------------->|
| | INVITE [M2] | | | 183 (session Progress) [M2] |
| |------------>| | |<----------------------------------------|
| 183 SP [M3] | | | | PRACK [M3] |
|<----------------| | | |---------------------------------------->|
| PRACK [M4] | | | | ACK (PRACK) [M4] |
|---------------->| | | |<----------------------------------------|
| 200 OK (PR)[M5] | | | | UPDATE [M5] |
|<----------------| | | |---------------------------------------->|
| UPDATE [M6] | | | | ACK (UPDATE) [M6] |
|---------------->| | | |<----------------------------------------|
| 200 OK (UP)[M7] | | | | 200 OK (INVITE) [M7] |
|<----------------| | | |<----------------------------------------|
| | CANCEL [M8] | |
| |------------>| |
| | 487 [M9] | |
| |<------------| |
| | INVITE [M10] |
| |-------------------------->|
| | 200 OK (INV) [M11] |
| |<--------------------------|
|200 OK (INV)[M12]| |
|<----------------| |
| ACK [M13] |
|-------------------------------------------->|
| RTP | | RTP |
|<===========================================>| |<=======================================>|
| | | |
Figure 5A. UA-PROXY with Location in UPDATE Figure A6. UA-UA with Location in UPDATE
** see new open issue #9 for the problems with messages 8 through 10 The following section will include the M1 and M5 messages in detail,
** of the above flow. but only in the civic format.
9.2.1 UA-to-Proxy Routing the Message with UPDATE (secure) Appendix A9. UA-to-UA UPDATE with Civic Location Not Using S/MIME
INVITE sip:sos@atlanta.example.com SIP/2.0 Here is the initial INVITE from Alice to Bob.
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9 [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 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sips:bob@biloxi.example.com>
To: <sip:sos@atlanta.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 31862 INVITE CSeq: 314159 INVITE
Contact: <sip:alice@atlanta.example.com> 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 Content-Type: multipart/mixed; boundary=boundary1
Contact-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
skipping to change at page 37, line 4 skipping to change at page 71, line 11
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
Alice moves locations (with her UA detecting the movement), causing Alice moves locations (with her UA detecting the movement), causing
her UA to generate an UPDATE message ([M5] of Figure 3) prior to her her UA to generate an UPDATE message ([M5] of Figure 3) prior to
UA receiving a final response from the PSAP. In this case, Alice her UA receiving a final response from Bob. Here is that message:
has walked across the South Wacker Drive to another building. Here
is that message:
[M5 UPDATE to PSAP] M5 UPDATE to Bob
UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds ;branch=z9hG4bK776asdhds
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sips:bob@biloxi.example.com>
To: <sip:sos@atlanta.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 10187 UPDATE CSeq: 10197 UPDATE
Contact: <sip:alice@atlanta.example.com> 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 Content-Type: multipart/mixed; boundary=boundary1
Contact-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 18 m=audio 49172 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
skipping to change at page 38, line 24 skipping to change at page 72, line 34
<gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention- <gp:retention-expiry>2005-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure) Appendix A10. UA-to-UA Location Conveyance Using PUBLISH (from 8.5)
left blank for now
9.3 425 "Retry Location Body" Error Response
In the case that a SIP Proxy detects an error in a SIP message
containing location information specific to that message body and
has the location of that UAC locally, a new 4XX level error needs to
be sent back to the UAC containing a new Location Object message
body of the UAC as the SIP intermediary understands where the UAC is
with the intent of the UAC including this LO message body in a
subsequent message to the originally addressed UAS. This document
creates the new error code:
425 (Retry Location Body)
The UAC MUST include the SIP intermediary provided LO message body
in the retransmission of the rejected message to the original UAS if
the UAC attempts this communication. User agents may conclude they
have already supplied a proper LO in the rejected request. That LO
can be resent, but the intermediary supplied LO MUST be included as
well.
This new error code will be IANA registered.
An example flow of this scenario will be included in the next
version of this internet draft.
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. Current Known Open issues
This is a list of open issues that have not yet been addressed to
conclusion:
1) Still have not determined how a SIP entity can request location
to be delivered in a certain format (civil vs. coordinate).
11.1 New Open Issues
These are new open issues to be addressed within this document or
the topics/areas dropped from consideration:
1) 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
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.
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
[ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet
Draft, Feb 2004, Work in progress
[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
[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
Method", RFC 3515, April 2003
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
16.1 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-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping-
emergency-arch", Internet Draft, Feb 2004, work in progress
16. Author Information
James M. Polk ** This appendix is not be completed at this time.
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
Appendix A. Additional stuff Appendix A11. UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY
(from 8.6)
This section is coming in the next release. ** This appendix is not be completed at this time.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
skipping to change at page 43, line 12 skipping to change at page 73, line 42
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
December 17th, 2005 January 17th, 2006
 End of changes. 

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