draft-ietf-sipping-location-requirements-00.txt   draft-ietf-sipping-location-requirements-01.txt 
Internet Engineering Task Force James M. Polk Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Aug 9th, 2004 Brian Rosen Expiration: Jan 19th, 2005 Brian Rosen
File: draft-ietf-sipping-location-requirements-00.txt Marconi File: draft-ietf-sipping-location-requirements-01.txt Marconi
Requirements for Requirements for
Session Initiation Protocol Location Conveyance Session Initiation Protocol Location Conveyance
February 9th, 2003 July 19, 2004
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, I certify that any applicable
with all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other documents
documents at any time. It is inappropriate to use Internet-Drafts at any time. It is inappropriate to use Internet-Drafts as
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 The list of Internet-Draft Shadow Directories can be accessed at
at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document presents the framework and requirements for an This document presents the framework and requirements for usage of
extension to the Session Initiation Protocol (SIP) [1] for the Session Initiation Protocol (SIP) [RFC 3261] to convey user
conveyance of user location information from a Session Initiation location information from a Session Initiation Protocol (SIP) user
Protocol (SIP) user agent to another SIP entity. We consider cases agent to another SIP entity. We consider cases where location
where location information is conveyed from end to end, as well as information is conveyed from end to end, as well as cases where
cases where message routing by intermediaries is influenced by the message routing by intermediaries is influenced by the location of
location of the session initiator. the session initiator. We offer a set of solutions to the
requirements, based on the scenario(s) being addressed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Changes from Individual Submission Versions . . . . . . . 3 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 3
2. In the Body or in a Header . . . . . . . . . . . . . . . . . 4 2. In the Body or in a Header . . . . . . . . . . . . . . . . . 4
3. Scope of Location in a Message Body . . . . . . . . . . . . . 5 3. Scope of Location in a Message Body . . . . . . . . . . . . . 5
4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 5 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 6
5. Requirements for UA-to-Proxy Server Location Conveyance . . . 5 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 6
6. Additional Requirements for Emergency Calls . . . . . . . . . 6 6. Additional Requirements for Emergency Calls . . . . . . . . . 7
7. Current Known Open issues . . . . . . . . . . . . . . . . . . 8 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8.1.1 UA-to-UA Using INVITE with Coordinate Format . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . . 14
12. Author Information . . . . . . . . . . . . . . . . . . . . . 9 8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . . 17
8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 23
8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 26
8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 30
9. Special Considerations for Emergency Calls . . . . . . . . . 30
9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 31
9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 36
10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 40
11. Current Known Open issues . . . . . . . . . . . . . . . . . . 41
12. New Open issues . . . . . . . . . . . . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 42
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
16.1 Normative References . . . . . . . . . . . . . . . . . 43
17. Author Information . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document presents the framework and requirements for an This document presents the framework and requirements for the usage
extension to the Session Initiation Protocol (SIP) [1] for of the Session Initiation Protocol (SIP) [1] for conveyance of user
conveyance of user location information object described by [7] from location information object described by [7] from a SIP User Agent
a SIP User Agent 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 to reach your nearest pizza another SIP entity. One example is to reach your nearest pizza
parlor. A chain of pizza parlors may have a single well known uri parlor. A chain of pizza parlors may have a single well known uri
(sip:pizzaparlor.com), that is forwarded to the closest franchise by (sip:pizzaparlor.com), that is forwarded to the closest franchise by
the pizzaparlor.com proxy server. The receiving franchise UAS uses the pizzaparlor.com proxy server. The receiving franchise UAS uses
the location information of the UAC to schedule your delivery. the location information of the UAC to schedule your delivery.
skipping to change at page 3, line 4 skipping to change at page 3, line 18
service, which is also based on your location. In many service, which is also based on your location. In many
jurisdictions, accurate location information of the caller in jurisdictions, accurate location information of the caller in
distress is a required component of a call to an emergency center. distress is a required component of a call to an emergency center.
A third example is a direction service, which might give you verbal A third example is a direction service, which might give you verbal
directions to a venue from your present position. This is a case directions to a venue from your present position. This is a case
where only the destination UAS needs to receive the location where only the destination UAS needs to receive the location
information. information.
This document does not discuss how the UAC discovers or is This document does not discuss how the UAC discovers or is
configured with its location (either coordinate or civil based). It configured with its location (either coordinate or civic based). It
also does not discuss the contents of the Location Object (LO). It also does not discuss the contents of the Location Object (LO). It
does specify the requirements for the "using protocol" in [7]. does specify the requirements for the "using protocol" in [7].
Sections 7, 8 and 9 give specific examples (in well-formed SIP
messages) of SIP UA and Proxy behavior for location conveyance, the
last of which is a section devoted to the unique circumstances
regarding emergency calling. Section 10 addresses how this document
adheres to the requirements specified in [7] (Geopriv Requirements).
Sections 11 and 12 list the current open issues with location
conveyance in SIP, and the new open issues recently discovered as a
result of the added effort to this revision.
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 [2]. in [2].
1.2 Changes from Individual Submission Versions 1.2 Changes from Prior Versions
[NOTE TO RFC-EDITOR: If this document is to be published as an RFC,
this section is to be removed prior to that event.]
This is a list of the changes that have been made from the -00 This is a list of the changes that have been made from the -00
individual submission version of this ID: working group version of this ID to this version:
- Added the offered solution in detail (with message flows,
appropriate SIP Methods for location conveyance, and
- Synchronized the requirements here with those from the Geopriv
Working Group's (attempting to eliminate overlap)
- Took on the task of making this effort the SIP "using protocol"
specification from Geopriv's POV
- Refined the Open Issues section to reflect the progress we've made
here, and to indicate what we have discovered needs addressing,
but has not been to date.
This is a list of the changes that have been made from the -01
individual submission version to the WG -00 version of this ID:
- Brian Rosen was brought on as a co-author - Brian Rosen was brought on as a co-author
- Requirements that a location header were negatively received in - Requirements that a location header were negatively received in
the previous version of this document. AD and chair advice was to the previous version of this document. AD and chair advice was to
move all location information into a message body (and stay away move all location information into a message body (and stay away
from headers) from headers)
- Added a section of "emergency call" specific requirements - Added a section of "emergency call" specific requirements
- Added an Open Issues section to mention what hasn't been resolved - Added an Open Issues section to mention what hasn't been resolved
yet in this effort yet in this effort
This is a list of the changes that have been made from the This is a list of the changes that have been made from the
individual submission version -01 individual submission version -00 to the -01 version
- Added the IPR Statement section - Added the IPR Statement section
- Adjusted a few requirements based on suggestions from the - Adjusted a few requirements based on suggestions from the
Minneapolis meeting Minneapolis meeting
- Added requirements that the UAC is to include from where it - Added requirements that the UAC is to include from where it
learned its location in any transmission of its LI learned its location in any transmission of its LI
- Distinguished the facts (known to date) that certain jurisdictions - Distinguished the facts (known to date) that certain jurisdictions
skipping to change at page 4, line 15 skipping to change at page 5, line 4
- Added the Open Issue of whether a Proxy can insert location - Added the Open Issue of whether a Proxy can insert location
information into an emergency SIP INVITE message, and some of the information into an emergency SIP INVITE message, and some of the
open questions surrounding the implications of that action open questions surrounding the implications of that action
- added a few names to the acknowledgements section - added a few names to the acknowledgements section
2. In the Body or in a Header 2. In the Body or in a Header
When one user agent wants to inform another user agent where they When one user agent wants to inform another user agent where they
are, it seems reasonable to have this accomplished by placing the are, it seems reasonable to have this accomplished by placing the
location information (coordinate or civil) in an S/MIME registered location information (coordinate or civic) in an S/MIME registered
and encoded message body, and sending it as part of a SIP request or and encoded message body, and sending it as part of a SIP request or
response. No routing of the request based on the location response. No routing of the request based on the location
information is required in this case; therefore no SIP Proxies information is required in this case; therefore no SIP Proxies
between these two UAs need to view the location information between these two UAs need to view the location information
contained in the SIP messages. contained in the SIP messages.
Although SIP [1} does not permit a proxy server to modify or delete Although SIP [1} does not permit a proxy server to modify or delete
a body, there is no restriction on viewing bodies. However, S/MIME a body, there is no restriction on viewing bodies. However, S/MIME
protection implemented on bodies is only specified between UAS and protection implemented on bodies is only specified between UAS and
UAC, and if engaged, would render the location object opaque to a UAC, and if engaged, would render the location object opaque to a
skipping to change at page 5, line 31 skipping to change at page 6, line 21
as well as the SIP MESSAGE method[4], and SHOULD work with as well as the SIP MESSAGE method[4], and SHOULD work with
most SIP messages. most SIP messages.
U-U2 - UAC Location information SHOULD remain confidential in route U-U2 - UAC Location information SHOULD remain confidential in route
to the destination UA. to the destination UA.
U-U3 - The privacy and security rules established within the U-U3 - 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 [7]. protocol' MUST be met [7].
U-U4 - The UAC SHOULD indicate in the SIP message that includes U-U4 - The LI MUST be contained in the LO as defined in [13],
location information where the LI came from (IANA registered which will satisfy all format requirements for
codes for GPS, Cell Tower Triangulation, WiFi, DHCP, manual interoperability.
entry - as examples).
U-U5 - The requirements of a "using protocol" by RFC 3693
(Geopriv Requirements) MUST be met.
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[4], and SHOULD responses, as well as the SIP MESSAGE method[4], and SHOULD
work with most SIP messages. work with most SIP messages.
skipping to change at page 6, line 17 skipping to change at page 7, line 9
U-PS5 - any mechanism used to prevent unwanted observation of this U-PS5 - any mechanism used to prevent unwanted observation of this
Location Information CANNOT fail the SIP Request if not Location Information CANNOT fail the SIP Request if not
understood by intermediary SIP entities or the destination understood by intermediary SIP entities or the destination
UAS. UAS.
U-PS6 - Proxy Servers that do not or cannot understand the Location U-PS6 - Proxy Servers that do not or cannot understand the Location
Information in the message body for routing purposes MUST Information in the message body for routing purposes MUST
NOT fail the SIP Request. NOT fail the SIP Request.
U-PS7 ˇ It MUST be possible for a proxy server to assert the U-PS7 ű It MUST be possible for a proxy server to assert the
validity of the location information provided by the UA. validity of the location information provided by the UA.
Alternatively, it is acceptable for there to be a mechanism Alternatively, it is acceptable for there to be a mechanism
for a proxy server to assert a location object itself. for a proxy server to assert a location object itself.
U-PS8 - The UAC SHOULD indicate in the SIP message that includes
location information where the LI came from (IANA
registered codes for GPS, Cell Tower Triangulation, WiFi,
DHCP, manual entry - as examples).
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:
Emergency calls presently have between 2 and 8-second call setup Emergency calls presently have between 2 and 8-second call setup
times. There is ample evidence that the longer call setup end of times. There is ample evidence that the longer call setup end of
the range causes an unacceptable number of callers to abandon the the range causes an unacceptable number of callers to abandon the
call before it is completed. Two-second call completion time is a call before it is completed. Two-second call completion time is a
goal of many existing emergency call centers. Allocating 25% of the goal of many existing emergency call centers. Allocating 25% of the
skipping to change at page 7, line 9 skipping to change at page 7, line 46
privacy in cases of failure of the privacy mechanism might be privacy in cases of failure of the privacy mechanism might be
subject to user preference, although such a feature would be within subject to user preference, although such a feature would be within
the domain of a UA implementation and thus not subject to the domain of a UA implementation and thus not subject to
standardization. It should be noted that some jurisdictions have standardization. It should be noted that some jurisdictions have
laws that explicitly deny any expectation of location privacy when laws that explicitly deny any expectation of location privacy when
making an emergency call, while others grant the user the ability to making an emergency call, while others grant the user the ability to
remain anonymous even when calling an ERC. So far, this has been remain anonymous even when calling an ERC. So far, this has been
offered in some jurisdictions, but the user within that jurisdiction offered in some jurisdictions, but the user within that jurisdiction
must state this preference, as it is not the default configuration. must state this preference, as it is not the default configuration.
E-2 ˇ Privacy mechanisms MUST NOT be mandatory for successful E-2 ű Privacy mechanisms MUST NOT be mandatory for successful
conveyance of location during an (sos-type) emergency call. conveyance of location during an (sos-type) emergency call.
E-3 - It MUST be possible to provide a privacy mechanism (that does E-3 - It MUST be possible to provide a privacy mechanism (that does
not violate the other requirements within this document) to a not violate the other requirements within this document) to a
user within a jurisdiction that gives that user the right to user within a jurisdiction that gives that user the right to
choose not to reveal their location even when contacting an choose not to reveal their location even when contacting an
ERC. ERC.
E-4 ˇ The retention and retransmission policy of the ERC MUST be E-4 ű The retention and retransmission policy of the ERC MUST be
able to be made available to the user, and override the able to be made available to the user, and override the
user's normal policy when local regulation governs such user's normal policy when local regulation governs such
retention and retransmission (but does not violate retention and retransmission (but does not violate
requirement E-3). As in E-2 above, requiring the use of the requirement E-3). As in E-2 above, requiring the use of the
ERC's retention and/or retransmission policy may be subject ERC's retention and/or retransmission policy may be subject
to user preference although in most jurisdictions, local laws to user preference although in most jurisdictions, local laws
specify such policies and may not be overridden by user specify such policies and may not be overridden by user
preference. preference.
Location information is considered so important during emergency Location information is considered so important during emergency
skipping to change at page 7, line 41 skipping to change at page 8, line 28
might know that the DHCP reply with location information was might know that the DHCP reply with location information was
overwritten recently (or exactly) when a VPN connection was overwritten recently (or exactly) when a VPN connection was
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 Location information MUST be transmitted, if known to the UAC, E-5 Location information MUST be transmitted, if known to the UAC,
in all calls to an ERC, even in the case it is not considered in all calls to an ERC, even in the case it is not considered
reliable. reliable.
E-6 The UAC SHOULD be able to inform the ERC that the location With that in mind, it is important to distinguish the location
information provided in the SIP message might be wrong. information learned locally from LI learned over a VPN; which in
itself is useful additional information to that ERC operator.
Requirements U-U4 and U-PS8 stipulate the inclusion of how the UAC E-7 THE UA must provide the actual LI of the endpoint, and not
learned its location. This can be especially useful to an ERC location which might have been erroneously given to it by, e.g.
operator attempting to learn all that is possible from this remote a VPN tunnel DHCP server.
person in distress. With that in mind, it is important to
distinguish the location information learned locally from LI learned
over a VPN; which in itself is useful additional information to that
ERC operator.
E-7 The UA MUST not provide the (overwritten?) location information 7. Location Conveyance using SIP
provided by a VPN (in lieu of the LI from the local network).
E-8 The UA SHOULD include within the location conveyance to the ERC Geopriv is the IETF working group assigned to define a Location
that it is (or recently was) connected to a VPN. Object for carrying within another protocol to convey geographic
location of an endpoint to another entity. This Location Object
will be supplied within SIP to convey location of a UA (or user of a
UA). The Location Object (LO) is defined in [13]. Section 26 of [1]
defines the security functionality SIPS for transporting SIP
messages with either TLS or IPsec, and S/MIME for encrypting message
bodies from SIP intermediaries that would otherwise have access to
reading the clear-text bodies. For UA-to-UA location conveyance,
using the PIDF-LO body satisfies the entire format and message-
handling requirements as stated in the baseline Geopriv requirements
[7]. SIP entities that will carry an LO MUST IMPLEMENT S/MIME for
encrypting on an end-to-end basis the location of a user agent,
satisfying [7]'s security requirements. The SIPS-URI from [1]
SHOULD also be used for further message protection (message
integrity, authentication and message confidentiality) and MUST be
used when S/MIME is not used. The entities sending and receiving
the LO MUST implement the privacy and security instructions in the
LO.
7. Current Known Open issues Self-signed certificates SHOULD NOT be used for protecting LI, as
the sender does not have a secure identity of the recipient.
Several LOs MAY be included in a body as long as the message length
is less than the maximum permitted for a single message in the
network the Location will be conveyed within.
Several SIP Methods are capable (and applicable) to carry the LO.
The Methods are divided into two groups, one for those applicable
for UA-to-UA location conveyance, and the other group for UA-to-
Proxy Location conveyance for routing the message.
The list of applicable Methods for UA-to-UA location conveyance is:
INVITE,
UPDATE,
MESSAGE, and
PUBLISH.
The list of applicable Methods for UA-to-Proxy location conveyance
is:
INVITE,
UPDATE, and maybe
MESSAGE
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
see a reason to prevent carrying a LO within these Method Requests
as long as the SIP message meets the requirements stated within this
document.
A 200 OK to an INVITE can carry the UAS's LO back to the UAC that
provided their location in the INVITE, but this is not something
that can be required due to the timing of the INVITE to 200 OK
messages, with potential local/user policy requiring the called user
to get involved in determining if the caller is someone they wish to
give location to (and at what precision).
There is an open question as to whether the SUBSCRIBE and NOTIFY
Methods should be addressed in this document, or another document at
a later date. This combination of Methods would be used in SIP by
having a UA or SIP Server offering a subscription to another UA for
the purposes of location refresh if the subscribed-to UA changes
location within a given time interval. This capability is not
currently considered critical, and considered "phase II" within the
Geopriv working group, but it is an open question here as to whether
the SIP/SIPPING WGs want this to be specified here as a behavior (it
should be pretty straight forward).
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
location can be trusted with the LI, and one in which intermediate
proxies may not be trusted. The former may be implemented with
"hop-by-hop" security as specified in [1] using sips: (i.e. TLS
security). In particular, emergency call routing requires routing
proxies to know location, and sips: protection is appropriate. The
latter case is under study by the SIPPING working group under the
subject "End to Middle" security [12].
Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to
convey location, SIP entities MUST adhere to the rules of [7],
specifically the retention and distribution (privacy) attributes of
a UA's location. When Alice is deciding how to transmit her
location, she should be keenly aware of the parameters in which she
wants her location to be stored and distributed. However, once she
sends that location information to Bob, he MUST also now obey
Alice's wishes regarding these privacy attributes if he is deciding
to inform another party about Alice. This is a fundamental
principle of the Geopriv Working Group, i.e. "PRIVACY".
8. User Agent-to-User Agent Location Conveyance
The offered solution here for the User-to-User solution for location
conveyance between UAs is used with the INVITE, UPDATE, MESSAGE, and
PUBLISH Methods in the following subsections.
8.1 UA-to-UA using INVITE Method
Below is a common SIP session set-up sequence between two user
agents. In this example, Alice will provide Bob with her geographic
location in the INVITE message.
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| |
| 200 OK [M2] |
|<----------------------------------------|
| |
| ACK [M3] |
|---------------------------------------->|
| |
| RTP |
|<=======================================>|
| |
Figure 1. UA-UA with Location in INVITE
User agent Alice INVITEs user agent Bob to a session [M1 of Figure
1]. Within this INVITE is a multipart body indication that it is
S/MIME encrypted [according to the rules of 1] by Alice for Bob.
One body part contains the SDP offered by Alice to Bob. Alice's
location (here coordinate based) is the other body part contained in
this INVITE. Bob responses with a 200 OK [M2] (choosing a codec as
specified by the Offer/Answer Model [14]). Bob can include his
location in the 200 OK response, but this shouldn't be expected due
to user timing. If Bob wants to provide his location to Alice after
the 200 OK, but before a BYE, the UPDATE Method [9] should be used.
Alice's UA replies with an ACK and the session is set up.
Figure 1. does not include any Proxies because in it assumed they
would not affect the session set-up with respect to whether or not
Alice's location is in a message body part, and Proxies don't react
to S/MIME bodies, making their inclusion more or less moot and more
complex than necessary.
The most relevant message in Figure 1 having to do with location is
(obviously) the message with the location object in it [M1]. So to
cut down on length of this document, only the INVITE message in this
example will be shown. Section 8.1.1 will give an example of this
well formed INVITE message using a Coordinate location format.
Section 8.1.2 will give an example of this well formed INVITE
message using the civic location format.
8.1.1 UA-to-UA INVITE with Coordinate Location Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1.
[Message 1 in Figure 1]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases
where hop-by-hop security is deployed.
[Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--broundary1
Content-Type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1 using the civic location format.
[Message 1 in Figure 1]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME
Below is a well-formed SIP INVITE Method message to the example in
Figure 1 in section 8.1. This message is here to show that although
the requirements are mandatory to implement proper security, it is
not mandatory to use. This message below is show for those cases
where the sending user does not wish to use security mechanisms in
transmitting their coordinate location.
[Message 1 in Figure 1]
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--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 8
a=rtpmap:0 PCMU/8000
--broundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.1.3 UA-to-UA Location Conveyance Involving 3 Users
In the following example, Alice presents her location in the INVITE
to Bob, which Bob 200 OKs with his location as well. Bob then
directs Alice to contact Carol with both their locations in the same
message. The REFER Method [15] is used in the message sequence, but
it does not carry anyone's location within the REFER message. This
example is here to show a 3-way communication of location, coupled
with how a UA can include someone else's location. This has
security implications due to neither primary party in the last
location transfer being the owner of the location information.
Alice (in this case) MUST adhere to the retention and distribution
privacy requirements within Bob's location object regarding his
location information prior to considering its inclusion in the
INVITE to Carol.
UA Alice Bob Carol
| INVITE [M1] | |
|---------------------------->| |
| 200 OK [M2] | |
|<----------------------------| |
| ACK [M3] | |
|---------------------------->| |
| RTP | |
|<===========================>| |
| reINVITE (hold) [M4] | |
|<----------------------------| |
| 200 OK [M5] | |
|---------------------------->| |
| REFER (Refer-to:Carol) [M6] | |
|<----------------------------| |
| INVITE [M7] |
|------------------------------------------>|
| 200 OK [M8] |
|------------------------------------------>|
| RTP |
|<=========================================>|
| NOTIFY [M9] | |
|---------------------------->| |
| 200 OK [M10] | |
|<----------------------------| |
| BYE [M11] | |
|<----------------------------| |
| 200 OK [M12] | |
|---------------------------->| |
| |
Figure 1a. UA-to-UA with Location in REFER
8.1.3.1 UA-to-UA REFER with Civic Location Using S/MIME
In Figure 1a., we have an example message flow involving the REFER
Method. The REFER itself does not carry location objects.
We are not including all the messages for space reasons. M1 is a
well-formed SIP message that contains Alice's location. M2 is Bob's
200 OK in response to Alice's INVITE, and it contains Bob's
Location.
[M1 of Figure 1a] - Alice at Sears Tower
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Bob replies to Alice's INVITE with a 200 OK and includes his
location.
[M2 of Figure 4] - Bob watching Cubs Game at Wrigley Field
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bKnashds8 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=bob 2890844530 2890844530 IN IP4 biloxi.example.com
c=IN IP4 192.168.10.20
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:bob@biloxi.example.com">
<tuple id="sg89ae">
<timestamp>2004-08-6T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC>
<cl:civilAddress>
<method>dhcp</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-08-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Bob REFERs Alice to Carol, and in M7, Alice includes both locations
in a single SIP message. This is possible because Bob set his
retention value to "yes", thus allowing Alice to pass his location
on to Carol.
[M7 of Figure 1a] - Alice tells Carol where she and Bob are
INVITE sips:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhdt
Max-Forwards: 70
To: Carol <sips:carol@chicago.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301775
Call-ID: a84b4c76e66711@pc33.atlanta.example.com
CSeq: 314160 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844531 2890844531 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49173 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:bob@biloxi.example.com">
<tuple id="sg89af">
<timestamp>2004-08-5T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-
allowed>
<gp:retention-expiry>2004-08-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-08-6T02:30:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.marconi.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-08-6T18:30:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
It is an open question of whether there should be a mechanism to
request or require the transmission of an LO. The LO is contained
in a body, so the usual sip mechanisms do not apply.
8.2 UA-to-UA Using MESSAGE Method
Anytime a user transmits geographic location outside of an INVITE
Request to another user, the MESSAGE Method is to be used. This
applies even when two users are in an existing dialog. The logic
here is as follows:
- a NOTIFY isn't appropriate because there was not a SUBSCRIBE
performed and accepted.
- a UPDATE isn't appropriate because it is for the updating of
session capabilities and parameters before a dialog is
established, but after a dialog request has been sent. If
Alice and Bob were in an existing dialog, UPDATE is already
outside its window of usage based on [9].
There is one exception to this for UA-to-UA conveyance: if Alice
sent her location in an INVITE, but has moved before receiving a
200 OK, her UA may send an UPDATE to Bob with new location
information.
NOTE: A similar use for UPDATE is within the UA-to-Proxy Location
Conveyance section of this document.
- reINVITE isn't appropriate because it is only used (or only
supposed to be used) for changing the capabilities and/or
parameters of an existing dialog. Transferring location has
nothing in the UA-to-UA conveyance case to do with the actual
dialog, so it does not apply here.
This leaves MESSAGE as the only viable Request Method for location
conveyance outside of a dialog between two users (Alice and Bob in
this case).
UA Alice UA Bob
| MESSAGE [M1] |
|---------------------------------------->|
| |
| 200 OK [M2] |
|<----------------------------------------|
| |
Figure 2. UA-UA with Location in MESSAGE
Section 8.2.1 will give the well formed MESSAGE message containing a
well formed Geopriv Location Object using the Coordinate location
format that is fully complying with all security requirements - SIPS
for hop-by-hop security, and S/MIME for message body confidentiality
end-to-end, as well as adhering to the retention and distribution
concerns from [7]. 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 [7], but does convey retention and distribution
indicators from Alice.
8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME
Below is M1 from Figure 2 in section 8.2. that is fully secure and
in compliance with Geopriv requirements in [7] for security
concerns.
[Message 1 in Figure 2]
MESSAGE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asegma
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 22756 MESSAGE
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: text/plain
HereĆs my location, Bob?
--broundary1
Content-Type: application/cpim-pidf+xml
Content-Disposition: render
Content-Description: my location
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-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>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.2.2 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 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>2004-07-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>2004-07-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 geographic location from UA-to-UA
unless location has already been sent in an INVITE that was the
first message in the same dialog set-up. The same security
properties used in the INVITE MUST be used in the UPDATE message.
The only reason for sending location in an UPDATE message is if
Alice's UA (in the common example used throughout this document) has
moved prior to receiving Bob's 200 OK to the original INVITE. 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 outside
the scope of this document, 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.
UA Alice UA Bob
| INVITE [M1] |
|---------------------------------------->|
| |
| 183 (session Progress) [M2] |
|<----------------------------------------|
| |
| PRACK [M3] |
|---------------------------------------->|
| |
| ACK (PRACK) [M4] |
|<----------------------------------------|
| |
| UPDATE [M5] |
|---------------------------------------->|
| |
| ACK (UPDATE) [M6] |
|<----------------------------------------|
| |
| 200 OK (INVITE) [M7] |
|<----------------------------------------|
| |
| RTP |
|<=======================================>|
| |
Figure 3. UA-UA with Location in UPDATE
The following section will include the M1 and M5 messages in detail,
but only in the civic format.
8.3.1 UA-to-UA UPDATE with Civic Location Not Using S/MIME
Here is the initial INVITE from Alice to Bob.
[M1 INVITE to Bob]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Alice moves locations (with her UA detecting the movement), causing
her UA to generate an UPDATE message ([M5] of Figure 3) prior to
her UA receiving a final response from Bob. Here is that message:
M5 UPDATE to Bob
UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
CSeq: 10197 UPDATE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;
filename=smime.p7m handling=required
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>250</cl:HNO>
<cl:PRD>South Upper</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:NAM>Venice Cafe</cl:NAM>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
8.4 UA-to-UA Location Conveyance Using PUBLISH
** This section could not be completed before submission time and
will be completed shortly after IETF60 (unless). A thousand pardons.
9. Special Considerations for Emergency Calls
When a Proxy Server knows to look for the location message body to
route an emergency call as in [11].
Emergency calls, which might be detected as detailed in 3, 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 connections 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 cannot support TLS establishment.
3. User Agents MUST NOT use S/MIME
Proxies MUST NOT remove a location message body at any time. If
there is a condition that a Proxy adds a location message body,
it:
4. MUST NOT produce a message length over current SIP message
limits (1300 bytes [per 3428])
5. MUST indicate within that added message body that body came
from that server (by some naming convention not defined here)
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 [11], 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 ERC. This is shown in Figure 4A.
UA Alice Proxy ERC
| INVITE [M1] | |
|------------------>| |
| | INVITE [M2] |
| |-------------------->|
| | 200 OK [M3] |
| |<--------------------|
| 200 OK [M4] | |
|<------------------| |
| ACK [M5] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 4A. UA-PROXY with Location in INVITE
[M1 of Figure 4A]
INVITE sips:sos@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
To: <sips:sos@atlanta.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sips: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 8
a=rtpmap:0 PCMU/8000
--boundary1
Once the Proxy receives M1 and recognizes it as an emergency INVITE
Request, this proxy knows to look into the message body for a
location body part to determine the location of the UAC in order to
match the location to an ERC. Once this look-up occurs, the message
is sent directly to the ERC (in message [M2]).
[M2 of Figure 4A] - Proxy has determined when to send message
INVITE sips:sos@192.168.10.20 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 69
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
To: <sips:sos@atlanta.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sips: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 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
The second probability in message flows is in Figure 4B. in which
the first hop Proxy does not either: understand location, or does
not know where the appropriate ERC is to route the message to. In
either case, that Proxy forwards the message to another Proxy for
proper message routing ([11] talks to how this occurs).
UA Alice Proxy Proxy ERC
| INVITE [M1] | | |
|------------>| | |
| | INVITE [M2] | |
| |------------>| |
| | | INVITE [M3] |
| | |------------>|
| | | 200 OK [M4] |
| | |<------------|
| | 200 OK [M5] | |
| |<------------| |
| 200 OK [M6] | | |
|<------------| | |
| ACK [M7] |
|---------------------------------------->|
| RTP |
|<=======================================>|
| |
Figure 4B. UA-PROXY with Location in INVITE
In message flows similar to 4A and/or 4B, the Record-Route header
could be added by the proxies, this is OPTIONAL in usage and left to
other documents to refine.
In the case of an identifiable emergency call, something that cannot
happen is for any Proxy to Challenge [per 1] 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 ERC. 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
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 can be considered the initial unsecure INVITE M1 from Figures
4A and 4A, or the second attempt message to an initial message that
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]
INVITE sip:sos@atlanta.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: <sip:sos@atlanta.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Contact-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 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
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 ERC
responded with a 200 OK, the UPDATE method is the appropriate SIP
Request Method to use to update the proxies and ERC personnel that
Alice has moved geo-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
ERC(2), for example, if she walked across a street into a new ERC
coverage area. The Proxy MUST remain transaction stateful in order
to be aware of the 200 OK Response from ERC1. Upon receiving the
UPDATE from Alice and analyzing the location provided by the message
looking for a geographic change, either forwarding that message to
ERC1 if the change is still within ERC1's coverage area, or deciding
to forward a message to another ERC covering where Alice is now
(ERC2 in this case) with her new location. If the later change in
destinations is required, the Proxy MUST CANCEL the pending INVITE
to ERC1 (with a 487 "terminated request" being the specified
response).
SIPS MUST be used by Alice initially. Upon any failure of the
initial Request, Alice's UA can decide to send the new message
without SIPS.
UA Alice Proxy ERC1 ERC2
| INVITE [M1] | | |
|---------------->| | |
| | INVITE [M2] | |
| |------------>| |
| 183 SP [M3] | | |
|<----------------| | |
| PRACK [M4] | | |
|---------------->| | |
| 200 OK (PR)[M5] | | |
|<----------------| | |
| UPDATE [M6] | | |
|---------------->| | |
| 200 OK (UP)[M7] | | |
|<----------------| | |
| | CANCEL [M8] | |
| |------------>| |
| | 487 [M9] | |
| |<------------| |
| | INVITE [M10] |
| |-------------------------->|
| | 200 OK (INV) [M11] |
| |<--------------------------|
|200 OK (INV)[M12]| |
|<----------------| |
| ACK [M13] |
|-------------------------------------------->|
| RTP |
|<===========================================>|
| |
Figure 5A. UA-PROXY with Location in UPDATE
** see new open issue #9 for the problems with messages 8 through 10
** of the above flow.
9.2.1 UA-to-Proxy Routing the Message with UPDATE (secure)
INVITE sip:sos@atlanta.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: <sip:sos@atlanta.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Contact-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 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>233</cl:HNO>
<cl:PRD>South</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:LMK>Sears Tower</cl:LMK>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.cisco.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
Alice moves locations (with her UA detecting the movement), causing
her UA to generate an UPDATE message ([M5] of Figure 3) prior to her
UA receiving a final response from the ERC. In this case, Alice has
walked across the South Wacker Drive to another building. Here is
that message:
[M5 UPDATE to ERC]
UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:sos@atlanta.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 10187 UPDATE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Contact-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 8
a=rtpmap:0 PCMU/8000
--boundary1
Content-type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-
xsd:feature:v3.0"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Illinois</cl:A1>
<cl:A3>Chicago</cl:A3>
<cl:HNO>250</cl:HNO>
<cl:PRD>South Upper</cl:PRD>
<cl:A6>Wacker</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>60606</cl:PC>
<cl:NAM>Venice Cafe</cl:NAM>
<cl:FLR>1</cl:FLR>
<cl:civilAddress>
<method>dhcp</method>
<method>802.11</method>
<provided-by>www.t-mobile.com</provided-by/>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2004-07-13T14:57:29Z</gp:retention-
expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure)
left blank for now
10. Meeting RFC3693 Requirements
Section 7.2 of [7] 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.
[1] 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 This is a list of open issues that have not yet been addressed to
conclusion: conclusion:
1) Whether SIP Proxies SHOULD be able to insert location information 1) Whether SIP Proxies SHOULD be able to insert location information
into an emergency call set-up (the INVITE)? into an emergency call set-up (the INVITE)?
1a) This has the additional implication of whether or not, or 1a) This has the additional implication of whether or not, or
regardless of the fact the UAC already inserted location into regardless of the fact the UAC already inserted location into
the sos@localdomain INVITE. the sos@homedomain INVITE.
1b) Should the Proxy somehow differentiate its location 1b) Should the Proxy somehow differentiate its location
information from that provided by the UAC (with each LI information from that provided by the UAC (with each LI
having a SIP entity (type?) originator label? having a SIP entity (type?) originator label?
1c) Should there be any behavior difference with respect to Open 1c) Should there be any behavior difference with respect to Open
Issue #1b if the Proxy does not know or cannot tell if the Issue #1b if the Proxy does not know or cannot tell if the
UAC inserted location information (further emphasizing the UAC inserted location information (further emphasizing the
need for some form of originator label)? need for some form of originator label)?
2) Whether SIP Proxies SHOULD be able to return location information 2) Whether SIP Proxies SHOULD be able to return location information
in a Redirect message to the UAC making the emergency call? in a Redirect message to the UAC making the emergency call?
3) If S/MIME is chosen as a SHOULD (in general, vs. TLS), this doc 12. New Open Issues
might consider stipulating a special purpose Proxy (an "emergency
services" proxy) that can process location information (a Geopriv
LO) and route the message directly to the appropriate ERC.
At Issue: plain "vanilla" proxies probably won't have the These are new open issues to be addressed within this document or
capabilities to route based on location information in the the topics/areas dropped from consideration:
near future, but should that timing be considered here?
8. Security Considerations 1) How do we handle proxy authenticated location?
2) What do we do in an Offer/Answer model where the INV contains an
Offer to the UAS asking which format they want to receive?
3) What do we do with Alice wanting Bob's Location in the 200 OK (to
her INVITE with location)?
4) What about a new 4XX error for unknown or bad location given?
5) There is the case in the Proxy Routing in which a UAC sent an
INVITE to sos@ without a location message body. Does this
necessitate the need for a 4XX level error informing the UAC to
"retry with the location message body included this time"?
Another spin on this is if the UAC doesn't know it's location and
wants to ask a Proxy server to include the UAC's location if it
is known to the Proxy...
6) How or should we get into a Redirect message from a PS that
contains a Location body for that UAC? Should we RECOMMEND a UAC
that receives a 3XX Reply to an INVITE that contains a Location
body with a presence line signifying the UAC, the UAC MUST
include that Location body in the new INVITE?
6a) What if the UAC already sent a Location body in the original
message, should it replace the location body with what the PS
included, or include both?
6ai) If we state "both", which we agreed in the past is a good
idea, I see no way in the PIDF-LO or in MIME to denote
which message body came from Alice and which came from
the PS...
7) The authors failed to get this document reclassified into a
specification effort (from a requirements ID effort)
7a) will re-request to the ADs after IETF60 for this
8) Req U-PS7 (Proxy Assertion of a Location body) is not addressable
yet in SIP (as Identity is barely addressable).
8a) Should this requirement remain as a goal?
9) From section 9.2 (Emergency call with an updated location), if
Alice does venture into another coverage area, how does her new
UPDATE with new location get sent to a second (and now
appropriate) ERC(2)?
The pending INVITE needs to be cancelled or able to be
sequentially forked (which not all Proxies will be able to do).
Without that occurring, the new UPDATE will not cause a new
INVITE to be originated from the Proxy towards ERC2... and what
happens to the UPDATE message (which cannot be an original
request into ERC2)?
13. Security Considerations
Conveyance of geo-location of a UAC is problematic for many reasons. Conveyance of geo-location of a UAC is problematic for many reasons.
This document calls for that conveyance to normally be accomplished This document calls for that conveyance to normally be accomplished
through secure message body means (like S/MIME or TLS). In cases 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 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 initiating the session or SIP MESSAGE, securing the location with an
end-to-end mechanism such as S/MIME is problematic. end-to-end mechanism such as S/MIME is problematic.
9. IANA Considerations 14. IANA Considerations
There are no IANA considerations within this document at this time. There are no IANA considerations within this document at this time.
10. Acknowledgements 15. Acknowledgements
To Dave Oran for helping to shape this idea. To Jon Peterson and To Dave Oran for helping to shape this idea. To Jon Peterson and
Dean Willis on guidance of the effort. To Henning Schulzrinne, Dean Willis on guidance of the effort. To Henning Schulzrinne,
Jonathan Rosenberg, Dick Knight, and Keith Drage for constructive Jonathan Rosenberg, Dick Knight, and Keith Drage for constructive
feedback. feedback.
11. References - Normative 16. References
16.1 References - Normative
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
Initiation Protocol ", RFC 3261, June 2002 Initiation Protocol ", RFC 3261, June 2002
[2] S. Bradner, "Key words for use in RFCs to indicate requirement [2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Mar. 1997. levels," RFC 2119, Mar. 1997.
[3] H. Schulzrinne, "draft-schulzrinne-sipping-sos-04.txt", Internet [3] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet
Draft, Jan 03, Work in progress Draft, Feb 2004, Work in progress
[4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. [4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D.
Gurle, "Session Initiation Protocol (SIP) Extension for Instant Gurle, "Session Initiation Protocol (SIP) Extension for Instant
Messaging" , RFC 3428, December 2002 Messaging" , RFC 3428, December 2002
[5] J. Polk, J. Schnizlein, M. Linsner, " draft-ietf-geopriv-dhcp-lci- [5] J. Polk, J. Schnizlein, M. Linsner, " DHCP Option for Location
option-03.txt", Internet Draft, Dec 2003, Work in progress Configuration Information", RFC 3825, July 2004
[6] H. Schulzrinne, "draft-schulzrinne-geopriv-dhcp-civil-01.txt", [6] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-03.txt", Internet
Internet Draft, Feb 03, Work in progress Draft, July 04, Work in progress
[7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "draft- [7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv
ietf-geopriv-reqs-04.txt", Internet Draft, Oct 03, Work in Requirements", RFC 3693, February 2004
progress
[8] J. Rosenberg, "Requirements for Session Policy for the Session [8] J. Rosenberg, "Requirements for Session Policy for the Session
Initiation Protocolö, draft-ietf-sipping-session-policy-req-00", Initiation Protocolö, draft-ietf-sipping-session-policy-req-00",
Internet Draft, June, 2003, "work in progress"
12. Author Information [9] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002
[10] A. Niemi, Ed., "draft-ietf-sip-publish-04", Internet Draft, May
2004, work in progress
[11] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping-emergency-
arch", Internet Draft, Feb 2004, work in progress
[12] "Requirements for End to Middle Security in SIP",
draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June
2004, work in progress,
[13] J. Peterson, "draft-ietf-geopriv-pidf-lo-02", Internet Draft, May
2004, work in progress
[14] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002
[15] R. Sparks, "The Session Initiation Protocol (SIP) Refer Method",
RFC 3515, April 2003
17. Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike 33.00111N
Richardson, Texas 75082 USA Richardson, Texas 75082 USA 96.68142W
jmpolk@cisco.com jmpolk@cisco.com
Brian Rosen Brian Rosen
Marconi Communications, Inc. Marconi Communications, Inc.
2000 Marconi Drive 2000 Marconi Drive 40.65923N
Warrendale, PA 15086 Warrendale, PA 15086 80.09958W
Brian.rosen@marconi.com Brian.rosen@marconi.com
IPR Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (C) The Internet Society (2004). This document is subject
intellectual property or other rights that might be claimed to to the rights, licenses and restrictions contained in BCP 78, and
pertain to the implementation or use of the technology described in except as set forth therein, the authors retain all their rights.
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any This document and the information contained herein are provided on
copyrights, patents or patent applications, or other proprietary an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
rights which may cover technology that may be required to practice REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
this standard. Please address the information to the IETF Executive INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
Director. IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement Intellectual Property
"Copyright (C) The Internet Society (February 23rd, 2001). The IETF takes no position regarding the validity or scope of any
All Rights Reserved. Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use
and distributed, in whole or in part, without restriction of any of such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph specification can be obtained from the IETF on-line IPR repository
are included on all such copies and derivative works. However, this at http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
This document and the information contained herein is provided on an Acknowledgement
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Funding for the RFC Editor function is currently provided by the
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Internet Society.
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
August 9th, 2004 January 19th, 2005
 End of changes. 

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