< draft-ietf-sipping-location-requirements-01.txt   draft-ietf-sipping-location-requirements-02.txt >
Internet Engineering Task Force James M. Polk Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Jan 19th, 2005 Brian Rosen Expiration: April 25th, 2005 Brian Rosen
File: draft-ietf-sipping-location-requirements-01.txt Marconi File: draft-ietf-sipping-location-requirements-02.txt Emergicom
Requirements for Requirements for
Session Initiation Protocol Location Conveyance Session Initiation Protocol Location Conveyance
July 19, 2004 October 25th, 2004
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 and any of which I become aware will be disclosed, in accordance
with RFC 3668. 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
skipping to change at page 1, line 43 skipping to change at page 1, line 42
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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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) [RFC 3261] to convey user the Session Initiation Protocol (SIP) to convey user location
location information from a Session Initiation Protocol (SIP) user information from one Session Initiation Protocol (SIP) entity to
agent to another SIP entity. We consider cases where location another SIP entity. We consider cases where location information is
information is conveyed from end to end, as well as cases where conveyed from end to end, as well as cases where message routing by
message routing by intermediaries is influenced by the location of intermediaries is influenced by the location of the session
the session initiator. We offer a set of solutions to the initiator. We offer a set of solutions to the requirements, based
requirements, based on the scenario(s) being addressed. 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 Prior 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 . . . . . . . . . . . . . . . . . 5
3. Scope of Location in a Message Body . . . . . . . . . . . . . 5 3. Scope of Location in a Message Body . . . . . . . . . . . . . 6
4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 6 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 7
5. Requirements for UA-to-Proxy Server Location Conveyance . . . 6 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 7
6. Additional Requirements for Emergency Calls . . . . . . . . . 7 6. Additional Requirements for Emergency Calls . . . . . . . . . 8
7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 8 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 10
8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 10 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 12
8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 10 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 12
8.1.1 UA-to-UA Using INVITE with Coordinate Format . . . . . 11 8.1.1 UA-to-UA Using INVITE with Coordinate Format. . . . . 13
8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . . 14 8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . 15
8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . . 17 8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 18
8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 23 8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 24
8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 26 8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 27
8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 30 8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 32
9. Special Considerations for Emergency Calls . . . . . . . . . 30 8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 32
9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 31 8.6 424 "Bad Location Information" Error Response . . . . . . 32
9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 36 9. Special Considerations for Emergency Calls . . . . . . . . . 32
10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 40 9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 33
11. Current Known Open issues . . . . . . . . . . . . . . . . . . 41 9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 38
12. New Open issues . . . . . . . . . . . . . . . . . . . . . . . 41 9.3 425 "Retry Location Body" Error Response . . . . . . . . 42
13. Security Considerations . . . . . . . . . . . . . . . . . . . 42 10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 43
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 11. Current Known Open issues . . . . . . . . . . . . . . . . . . 43
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 12. New Open issues . . . . . . . . . . . . . . . . . . . . . . . 44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. Security Considerations . . . . . . . . . . . . . . . . . . . 44
16.1 Normative References . . . . . . . . . . . . . . . . . 43 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44
17. Author Information . . . . . . . . . . . . . . . . . . . . . 44 14.1 IANA Registration for Response Code 424 . . . . . . . . 45
14.2 IANA Registration for Response Code 425 . . . . . . . . 45
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.1 Normative References . . . . . . . . . . . . . . . . . 45
17. Author Information . . . . . . . . . . . . . . . . . . . . . 46
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) [1] for conveyance of user of the Session Initiation Protocol (SIP) [1] for conveyance of user
location information object described by [7] from a SIP User Agent location information described by [7] from a SIP entity to another
to another SIP entity. 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 one user agent informing another
parlor. A chain of pizza parlors may have a single well known uri user agent where it is (you want to tell your friend where you are).
Another example is to reach your nearest pizza 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.
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 [3]. The example.com sip:sos@example.com is an emergency call as in [3]. The example.com
proxy server must route the call to the correct emergency response proxy server must route the call to the correct emergency response
center (ERC) determined by the location of the caller. At the ERC, center (ERC) determined by the location of the caller. At the ERC,
the UAS must determine the correct police/fire/ambulance/... the UAS must determine the correct police/fire/ambulance/...
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, precise 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 forth 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 civic 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" as defined by
Geopriv in [7].
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 [7] (Geopriv Requirements). adheres to the requirements specified in [7] (Geopriv Requirements).
Sections 11 and 12 list the current open issues with location Sections 11 and 12 list the current open issues with location
conveyance in SIP, and the new open issues recently discovered as a conveyance in SIP, and the new open issues recently discovered as a
result of the added effort to this revision. result of the added effort to this revision.
skipping to change at page 3, line 43 skipping to change at page 3, line 52
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 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 -01
working group version of this effort to this -02 version:
- added requirements for 2 new 4XX error responses (Bad Location
Information) and (Retry Location Body)
- added "Bad Location Information" as section 8.6
- added "Retry Location Body " as section 9.3
- added support for session mode to cover packet sizes larger than
the single packet limit of 1300 bytes in the message body
- added requirement for a SIP entity to SUBSCRIBE to another for
location information
- added SUBSCRIBE and NOTIFY as section 8.5
- added requirement to have user turn off any tracking created by
subscription
- removed doubt about which method to use for updating location
after a INVITE is sent (update)
- cleaned up which method is to be used if there is no dialog
existing (message)
- removed use of reINVITE to convey location
- clarified that UAs include <provided-by> element of PIDF-LO when
placing an emergency call (to inform ERC who supplied Location
information)
- updated list of open issues
- added to IANA Considerations section for the two new 4XX level
error responses requested in the last meeting
This is a list of the changes that have been made from the -00 This is a list of the changes that have been made from the -00
working group version of this ID to this version: working group version of this ID to this version:
- Added the offered solution in detail (with message flows, - Added the offered solution in detail (with message flows,
appropriate SIP Methods for location conveyance, and appropriate SIP Methods for location conveyance, and
- Synchronized the requirements here with those from the Geopriv - Synchronized the requirements here with those from the Geopriv
Working Group's (attempting to eliminate overlap) Working Group's (attempting to eliminate overlap)
- Took on the task of making this effort the SIP "using protocol" - Took on the task of making this effort the SIP "using protocol"
skipping to change at page 5, line 13 skipping to change at page 6, line 8
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 civic) 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 UAC and
UAC, and if engaged, would render the location object opaque to a UAS, and if engaged, would render the location object opaque to a
proxy server for any desired modification if it is not correct or proxy server for any desired modification if it is not correct or
precise enough from that proxy's point of view (were it to be able precise enough from that proxy's point of view (were it to be able
to view it). This problem is similar to that raised in Session to view it). This problem is similar to that raised in Session
Policy [8], where an intermediary may need information in a body, Policy [8], where an intermediary may need information in a body,
such as IP address of media streams or codec choices to route a call such as IP address of media streams or codec choices to route a call
properly. Requirements in [8] are applicable to routing based on properly. Requirements in [8] are applicable to routing based on
location, and are incorporated in these requirements by reference. location, and are 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, [7] prefers S/MIME for security of Location Information, However, [7] prefers S/MIME for security of Location Information,
skipping to change at page 6, line 5 skipping to change at page 6, line 49
3. Scope of Location in a Message Body 3. Scope of Location in a Message Body
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. If either another body (SDP for be contained within a message body. If either another body (SDP for
example) is also to be sent in the message, or the LI is to be example) is also to be sent in the message, or the LI is to be
protected with S/MIME, the rules stated in section 7 of [1] protected with S/MIME, the rules stated in section 7 of [1]
regarding multipart MIME bodies MUST be followed. The format and regarding multipart MIME bodies MUST be followed. The format and
privacy/security rules of the location information SHOULD be defined privacy/security rules of the location information SHOULD be defined
within the Geopriv WG. within the Geopriv WG.
User agents providing location can perform this function
incorrectly. Therefore, there needs to be a UAC error response code
created to inform the UAC by a UAS or Proxy of this incorrect
request message containing location information.
There will be times in which the UAC does not know its location
information, or another SIP entity knows the UAC's location better
than the UAC itself. How this is determined is out of scope of this
document. In these times, a Proxy servers that knows the location
of the UAC needs inform the UAC of its location information and have
that UAC include that message body in its next SIP message to the
same destination UA. This error code needs to be unique with
respect to the error code for merely incorrect location information
from the UAC.
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: Situations where routing is not based on the LI of either UA:
U-U1 - MUST work with dialog-initiating SIP Requests and responses, U-U1 - MUST work with dialog-initiating SIP Requests and responses,
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 LI MUST be contained in the LO as defined in [13], U-U4 - Location information MUST be contained in the location
which will satisfy all format requirements for Object as defined in [13], which will satisfy all format
interoperability. requirements for interoperability.
U-U5 - The requirements of a "using protocol" by RFC 3693 U-U5 - SHOULD be able to communicate location between user agents
(Geopriv Requirements) MUST be met. with as many packets as is necessary.
U-U6 - There MUST be a unique UAC error response code informing the
UAC is did not provide valid location information.
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 50 skipping to change at page 8, line 11
servers. servers.
U-PS3 - The privacy and security rules established within the U-PS3 - 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 [7]. 'using protocol' MUST be met [7].
U-PS4 - Modification or removal of the LO by proxy servers MUST NOT U-PS4 - Modification or removal of the LO by proxy servers MUST NOT
be required (as [1] currently forbids this). be required (as [1] currently forbids this).
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 MUST NOT 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 - There MUST be a unique UAC error response code informing
the UAC is did not provide valid location information.
U-PS9 - There MUST be a unique UAC error response code informing
the UAC it did not provide valid location information, and
to include the location information contained in the
message body of the error message in its 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:
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 46 skipping to change at page 9, line 14
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
specify such policies and may not be overridden by user laws 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
calls, that it is to be transmitted even when it is not considered calls, that it is to be transmitted even when it is not considered
reliable, or might even be wrong. For example, some application reliable, or might even be wrong. For example, some application
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).
skipping to change at page 8, line 36 skipping to change at page 9, line 54
reliable. reliable.
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 LI learned over a VPN; which in
itself is useful additional information to that ERC operator. itself is useful additional information to that ERC operator.
E-7 THE UA must provide the actual LI of the endpoint, and not E-7 THE UA must provide the actual LI of the endpoint, and not
location which might have been erroneously given to it by, e.g. location which might have been erroneously given to it by, e.g.
a VPN tunnel DHCP server. a VPN tunnel DHCP server.
E-8 An ERC MAY wish to SUBSCRIBE to the UAC that initiated a
session. If this is supported by the UAC, all NOTIFY messages
MUST contain the UAC's location information.
This is a means for the emergency response centers to maintain a
location the callers in distress.
E-9 It MUST be possible that any UAC supporting E-8 be informed of
this subscription, as this will provide a means of alert to the
user who does not wish this capability to remain enabled.
7. Location Conveyance using SIP 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
will be supplied within SIP to convey location of a UA (or user of a 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] UA). The Location Object (LO) is defined in [13]. Section 26 of [1]
defines the security functionality SIPS for transporting SIP defines the security functionality SIPS for transporting SIP
messages with either TLS or IPsec, and S/MIME for encrypting message messages with either TLS or IPsec, and S/MIME for encrypting message
bodies from SIP intermediaries that would otherwise have access to bodies from SIP intermediaries that would otherwise have access to
reading the clear-text bodies. For UA-to-UA location conveyance, reading the clear-text bodies. For UA-to-UA location conveyance,
using the PIDF-LO body satisfies the entire format and message- using the PIDF-LO body satisfies the entire format and message-
handling requirements as stated in the baseline Geopriv requirements handling requirements as stated in the baseline Geopriv requirements
[7]. SIP entities that will carry an LO MUST IMPLEMENT S/MIME for [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, encrypting on an end-to-end basis the location of a user agent,
satisfying [7]'s security requirements. The SIPS-URI from [1] satisfying [7]'s security requirements. The SIPS-URI from [1]
SHOULD also be used for further message protection (message SHOULD also be used for further message protection (message
integrity, authentication and message confidentiality) and MUST be integrity, authentication and message confidentiality) and MUST be
used when S/MIME is not used. The entities sending and receiving used when S/MIME is not used. The entities sending and receiving
the LO MUST implement the privacy and security instructions in the the LO MUST obey the privacy and security instructions in the
LO. LO to be compliant with this specification.
Self-signed certificates SHOULD NOT be used for protecting LI, as Self-signed certificates SHOULD NOT be used for protecting LI, as
the sender does not have a secure identity of the recipient. 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 Several LOs MAY be included in a body. If the message length
is less than the maximum permitted for a single message in the exceeds the maximum message length of a single packet, session mode
network the Location will be conveyed within. 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.
The Methods are divided into two groups, one for those applicable The Methods are divided into two groups, one for those applicable
for UA-to-UA location conveyance, and the other group for UA-to- for UA-to-UA location conveyance, and the other group for UA-to-
Proxy Location conveyance for routing the message. 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,
UPDATE, UPDATE,
MESSAGE, and MESSAGE, 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 maybe UPDATE,
MESSAGE MESSAGE, and
SUBSCRIBE/NOTIFY
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 OPTIONS, ACK, PRACK, BYE, REFER and CANCEL Methods, we do not
see a reason to prevent carrying a LO within these Method Requests see a reason to prevent carrying a LO within these Method Requests
as long as the SIP message meets the requirements stated within this as long as the SIP message meets the requirements stated within this
document. document.
A 200 OK to an INVITE can 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 their 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).
There is an open question as to whether the SUBSCRIBE and NOTIFY There is an open question as to whether there needs to be a new
Methods should be addressed in this document, or another document at event package created for a SUBSCRIBE such that one SIP entity
a later date. This combination of Methods would be used in SIP by (perhaps a service using SIP) can request the ability to have a
having a UA or SIP Server offering a subscription to another UA for remote UA's location refreshed at some interval. This idea is not
the purposes of location refresh if the subscribed-to UA changes explored further in this version of the document. The capability to
location within a given time interval. This capability is not have location information refreshed between devices is out of scope
currently considered critical, and considered "phase II" within the within the Geopriv working group at this time, but could easily
Geopriv working group, but it is an open question here as to whether become part of the "using protocol's" capabilities without violating
the SIP/SIPPING WGs want this to be specified here as a behavior (it any of the Geopriv Requirements in [7]. The authors want feedback
should be pretty straight forward). on incorporating this into this document, or a separate document.
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 on 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 [1] using sips: (i.e. TLS "hop-by-hop" security as specified in [1] using sips: (i.e. TLS
security). In particular, emergency call routing requires routing security). In particular, emergency call routing requires routing
proxies to know location, and sips: protection is appropriate. The proxies to know location, and sips: protection is appropriate. The
latter case is under study by the SIPPING working group under the latter case is under study by the SIPPING working group under the
subject "End to Middle" security [12]. subject "End to Middle" security [12].
skipping to change at page 11, line 5 skipping to change at page 12, line 34
| | | |
| 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]. Within this INVITE is a multipart body indication that it is 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. 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 One body part contains the SDP offered by Alice to Bob. Alice's
location (here coordinate based) is the other body part contained in location (here coordinate based) is the other body part contained in
this INVITE. Bob responses with a 200 OK [M2] (choosing a codec as this INVITE. Bob responses with a 200 OK [M2] (choosing a codec as
specified by the Offer/Answer Model [14]). Bob can include his specified by the Offer/Answer Model [14]). Bob can include his
location in the 200 OK response, but this shouldn't be expected due 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 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. 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. Alice's UA replies with an ACK and the session is set up.
skipping to change at page 12, line 4 skipping to change at page 13, line 33
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> 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=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 8 m=audio 49172 RTP/AVP 0 4 8
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:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326"> <gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N <gml:coordinates>41.87891N
87.63649W</gml:coordinates> 87.63649W</gml:coordinates>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
<method>dhcp</method> <method>dhcp</method>
</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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.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
skipping to change at page 13, line 39 skipping to change at page 15, line 16
--broundary1 --broundary1
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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326"> <gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N <gml:coordinates>41.87891N
87.63649W</gml:coordinates> 87.63649W</gml:coordinates>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
<method>dhcp</method> <method>dhcp</method>
</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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.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.
skipping to change at page 14, line 54 skipping to change at page 16, line 33
--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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
<provided-by><nena>www.cisco.com</nena></provided-by/> <provided-by><nena>www.cisco.com</nena></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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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.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
skipping to change at page 16, line 26 skipping to change at page 18, line 4
--broundary1 --broundary1
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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
<provided-by><nena>www.cisco.com</nena></provided-by/> <provided-by><nena>www.cisco.com</nena></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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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.1.3 UA-to-UA Location Conveyance Involving 3 Users 8.1.3 UA-to-UA Location Conveyance Involving 3 Users
In the following example, Alice presents her location in the INVITE In the following example, Alice presents her location in the INVITE
to Bob, which Bob 200 OKs with his location as well. Bob then 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 directs Alice to contact Carol. The REFER Method [15] is used in
message. The REFER Method [15] is used in the message sequence, but the message sequence, but it does not carry anyone's location within
it does not carry anyone's location within the REFER message. This the REFER message. This example is here to show a 3-way
example is here to show a 3-way communication of location, coupled communication of location, coupled with how a UA can include someone
with how a UA can include someone else's location. This has else's location. This has security implications due to neither
security implications due to neither primary party in the last primary party in the last location transfer being the owner of the
location transfer being the owner of the location information. location information. Alice (in this case) MUST adhere to the
Alice (in this case) MUST adhere to the retention and distribution retention and distribution privacy requirements within Bob's
privacy requirements within Bob's location object regarding his location object regarding his location information prior to
location information prior to considering its inclusion in the considering its inclusion in the INVITE to Carol.
INVITE to Carol.
UA Alice Bob Carol UA Alice Bob Carol
| INVITE [M1] | | | INVITE [M1] | |
|---------------------------->| | |---------------------------->| |
| 200 OK [M2] | | | 200 OK [M2] | |
|<----------------------------| | |<----------------------------| |
| ACK [M3] | | | ACK [M3] | |
|---------------------------->| | |---------------------------->| |
| RTP | | | RTP | |
skipping to change at page 18, line 53 skipping to change at page 20, line 31
--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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
<provided-by><nena>www.cisco.com</nena></provided-by/> <provided-by><nena>www.cisco.com</nena></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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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--
Bob replies to Alice's INVITE with a 200 OK and includes his Bob replies to Alice's INVITE with a 200 OK and includes his
location. location.
[M2 of Figure 4] - Bob watching Cubs Game at Wrigley Field [M2 of Figure 4] - Bob watching Cubs Game at Wrigley Field
skipping to change at page 20, line 20 skipping to change at page 21, line 51
--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:bob@biloxi.example.com"> entity="pres:bob@biloxi.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2004-08-6T02:30:29Z</timestamp> <timestamp>2004-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:A6>Addison</cl:A6> <cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO> <cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD> <cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS> <cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK> <cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC> <cl:PC>60613</cl:PC>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<provided-by>www.cisco.com</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>2004-08-6T18:30:29Z</gp:retention- <gp:retention-expiry>2004-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--
Bob REFERs Alice to Carol, and in M7, Alice includes both locations Bob REFERs Alice to Carol, and in M7, Alice includes both locations
in a single SIP message. This is possible because Bob set his in a single SIP message. This is possible because Bob set his
retention value to "yes", thus allowing Alice to pass his location retention value to "yes", thus allowing Alice to pass his location
on to Carol. on to Carol.
[M7 of Figure 1a] - Alice tells Carol where she and Bob are [M7 of Figure 1a] - Alice tells Carol where she and Bob are
INVITE sips:carol@chicago.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=z9hG4bK776asdhdt ;branch=z9hG4bK776asdhdt
Max-Forwards: 70 Max-Forwards: 70
To: Carol <sips:carol@chicago.example.com> To: Carol <sips:carol@chicago.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301775 From: Alice <sips:alice@atlanta.example.com>;tag=1928301775
Call-ID: a84b4c76e66711@pc33.atlanta.example.com Call-ID: a84b4c76e66711@pc33.atlanta.example.com
CSeq: 314160 INVITE CSeq: 314160 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
skipping to change at page 21, line 43 skipping to change at page 23, line 20
--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:bob@biloxi.example.com"> entity="pres:bob@biloxi.example.com">
<tuple id="sg89af"> <tuple id="sg89af">
<timestamp>2004-08-5T02:30:29Z</timestamp> <timestamp>2004-11-5T02: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:A6>Addison</cl:A6> <cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO> <cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD> <cl:PRD>W</cl:PRD>
skipping to change at page 22, line 4 skipping to change at page 23, line 34
<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:A6>Addison</cl:A6> <cl:A6>Addison</cl:A6>
<cl:HNO>1060</cl:HNO> <cl:HNO>1060</cl:HNO>
<cl:PRD>W</cl:PRD> <cl:PRD>W</cl:PRD>
<cl:STS>street</cl:STS> <cl:STS>street</cl:STS>
<cl:LMK>Wrigley Field</cl:LMK> <cl:LMK>Wrigley Field</cl:LMK>
<cl:PC>60613</cl:PC> <cl:PC>60613</cl:PC>
<cl:civilAddress> <cl:civilAddress>
<method>dhcp</method> <method>dhcp</method>
<method>802.11</method> <method>802.11</method>
<provided-by>www.cisco.com</provided-by/> <provided-by>www.cisco.com</provided-by/>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission- <gp:retransmission-allowed>yes</gp:retransmission-
allowed> allowed>
<gp:retention-expiry>2004-08-6T18:30:29Z</gp:retention- <gp:retention-expiry>2004-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
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>2004-08-6T02:30:29Z</timestamp> <timestamp>2004-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>
skipping to change at page 22, line 53 skipping to change at page 24, line 30
<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.marconi.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>2004-08-6T18:30:29Z</gp:retention- <gp:retention-expiry>2004-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--
It is an open question of whether there should be a mechanism to 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 request or require the transmission of an LO. The LO is contained
in a body, so the usual sip mechanisms do not apply. in a body, so the available sip mechanisms do not apply.
8.2 UA-to-UA Using MESSAGE Method 8.2 UA-to-UA Using MESSAGE Method
Anytime a user transmits geographic location outside of an INVITE Anytime a user transmits location information outside a dialog, the
Request to another user, the MESSAGE Method is to be used. This MESSAGE Method is to be used. The logic here is as follows:
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 - UPDATE isn't appropriate because it is for the updating of
Conveyance section of this document. session capabilities and parameters of a dialog (after the
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 capabilities and/or supposed to be used) for changing the parameters of an existing
parameters of an existing dialog. Transferring location has dialog, and one might not exist in all cases of location
nothing in the UA-to-UA conveyance case to do with the actual conveyance.
dialog, so it does not apply here.
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). this case). The following is an example of this communication.
UA Alice UA Bob UA Alice UA Bob
| MESSAGE [M1] | | MESSAGE [M1] |
|---------------------------------------->| |---------------------------------------->|
| | | |
| 200 OK [M2] | | 200 OK [M2] |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 2. UA-UA with Location in MESSAGE Figure 2. UA-UA with Location in MESSAGE
Section 8.2.1 will give the well formed MESSAGE message containing a Section 8.2.1 will give the well formed MESSAGE Method containing a
well formed Geopriv Location Object using the Coordinate location well formed Geopriv Location Object using the Coordinate location
format that is fully complying with all security requirements - SIPS format that fully complies with all security requirements - SIPS for
for hop-by-hop security, and S/MIME for message body confidentiality hop-by-hop security, and S/MIME for message body confidentiality
end-to-end, as well as adhering to the retention and distribution end-to-end, as well as adhering to the retention and distribution
concerns from [7]. Section 8.2.2 will show the Civic Location concerns from [7]. Section 8.2.2 will show the Civic Location
format alternative to the same location, as conveyed from Alice to format alternative to the same location, as conveyed from Alice to
Bob. This section does not adhere to confidentiality or integrity Bob. This section does not adhere to confidentiality or integrity
concerns of [7], but does convey retention and distribution concerns of [7], but does convey retention and distribution
indicators from Alice. indicators from Alice.
8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME 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 Below is M1 from Figure 2 in section 8.2. that is fully secure and
skipping to change at page 24, line 47 skipping to change at page 26, line 11
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: text/plain Content-Type: text/plain
HereÆs my location, Bob? Here's my location, Bob?
--broundary1 --broundary1
Content-Type: application/cpim-pidf+xml Content-Type: application/cpim-pidf+xml
Content-Disposition: render Content-Disposition: render
Content-Description: my location 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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57:29Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326"> <gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>41.87891N <gml:coordinates>41.87891N
87.63649W</gml:coordinates> 87.63649W</gml:coordinates>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
<method>dhcp</method> <method>dhcp</method>
</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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 8.2.2 UA-to-UA MESSAGE with Civic Location Not Using S/MIME
skipping to change at page 26, line 10 skipping to change at page 27, line 24
Content-Disposition: render Content-Disposition: render
Content-Description: my location 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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-11-13T14:57:29Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
8.3 UA-to-UA Location Conveyance Using UPDATE 8.3 UA-to-UA Location Conveyance Using UPDATE
UPDATE MUST NOT be used to send geographic location from UA-to-UA UPDATE MUST NOT be used to send location information from UA-to-UA
unless location has already been sent in an INVITE that was the unless location has already been sent in an INVITE or corresponding
first message in the same dialog set-up. The same security 200 OK that was the first message exchange in the same dialog set-
properties used in the INVITE MUST be used in the UPDATE message. up. The same security properties used in the INVITE MUST be used in
The only reason for sending location in an UPDATE message is if the UPDATE message.
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 The UPDATE Method is to be used any time location information is to
this movement is determined is outside the scope of this document, be updated between UAs setting up a dialog or after the dialog has
but ultimately should be configurable by local administration or the been established, no matter how long that dialog has been
user of the UA. By how much Alice has moved to trigger the "sense operational. reINVITE is out of scope here, and the MESSAGE Method
of movement" (i.e. the need to send new location) to Bob is outside is for non-dialog location conveyance between UAs only.
the scope of this document, but ultimately should be configurable by
local administration or the user of the UA. 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 In Figure 3., we have an example message flow involving the UPDATE
Method. We are not including all the messages for space reasons. M1 Method. We are not including all the messages for space reasons. M1
is a well formed SIP message that contains Alice's location. During 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 set-up, Alice's UA knows it has moved while knowing too
the session has not been formally accepted by Bob. Alice's UA the session has not been formally accepted by Bob. Alice's UA
decides to update Bob with her new location with an UPDATE Method decides to update Bob with her new location with an UPDATE Method
message. Messages M2, M3 and M4 have nothing to do with location message. Messages M2, M3 and M4 have nothing to do with location
conveyance, therefore will not be shown in detail. Only M1 and M5 conveyance, therefore will not be shown in detail. Only M1 and M5
will be shown. will be shown.
NOTE: A similar use for UPDATE is within the UA-to-Proxy Location
Conveyance section of this document.
UA Alice UA Bob UA Alice UA Bob
| INVITE [M1] | | INVITE [M1] |
|---------------------------------------->| |---------------------------------------->|
| | | |
| 183 (session Progress) [M2] | | 183 (session Progress) [M2] |
|<----------------------------------------| |<----------------------------------------|
| | | |
| PRACK [M3] | | PRACK [M3] |
|---------------------------------------->| |---------------------------------------->|
skipping to change at page 28, line 34 skipping to change at page 30, line 4
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 8 m=audio 49172 RTP/AVP 0 4 8
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:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
skipping to change at page 29, line 12 skipping to change at page 30, line 34
<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.cisco.com</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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
skipping to change at page 30, line 4 skipping to change at page 31, line 25
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 8 m=audio 49172 RTP/AVP 0 4 8
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:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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:HNO>250</cl:HNO>
<cl:PRD>South Upper</cl:PRD> <cl:PRD>South Upper</cl:PRD>
<cl:A6>Wacker</cl:A6> <cl:A6>Wacker</cl:A6>
skipping to change at page 30, line 34 skipping to change at page 32, line 4
<cl:PC>60606</cl:PC> <cl:PC>60606</cl:PC>
<cl:NAM>Venice Cafe</cl:NAM> <cl:NAM>Venice Cafe</cl:NAM>
<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.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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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.4 UA-to-UA Location Conveyance Using PUBLISH 8.4 UA-to-UA Location Conveyance Using PUBLISH
** This section could not be completed before submission time and ** This section could not be completed before submission time and
will be completed shortly after IETF60 (unless). A thousand pardons. will be completed shortly after IETF61. A thousand and one pardons.
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 9. Special Considerations for Emergency Calls
When a Proxy Server knows to look for the location message body to When a Proxy Server knows to look for a location message body to
route an emergency call as in [11]. route an emergency call as in [11].
Emergency calls, which might be detected as detailed in 3, have Emergency calls, which might be detected as detailed in [3], have
special rules for conveyance of location: special rules for conveyance of location:
1. An emergency call MUST have all LI available to the UA, if 1. An emergency call MUST have all LI available to the UA, if any,
any, sent with the INVITE, and subsequent UPDATE or reINVITE sent with the INVITE, and subsequent UPDATE or reINVITE messages
messages as a PIDF-LO in a body as a PIDF-LO in a body
2. The LO must be protected with sips: UNLESS the attempt to 2. The LO must be protected with sips: unless the attempt to
establish hop-by-hop TLS connections fails and cannot establish hop-by-hop TLS connection fails and cannot reasonably
reasonably be established in a very short (less than a second) be established in a very short (less than a second) time. In
time. In such a case, the LO SHOULD be sent without TLS ONLY such a case, the LO SHOULD be sent without TLS ONLY for those
for those hops that cannot support TLS establishment. hops that failed to support TLS establishment.
3. User Agents MUST NOT use S/MIME 3. User Agents MUST NOT use S/MIME
Proxies MUST NOT remove a location message body at any time. If 4. User Agents MUST include the <provided-by> element in the PIDF-LO
there is a condition that a Proxy adds a location message body, (if known) to give the ERC an indication as to who is responsible
it: for providing the UA with its location information.
4. MUST NOT produce a message length over current SIP message Proxies MUST NOT remove a location message body at any time. In the
limits (1300 bytes [per 3428]) 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.
5. MUST indicate within that added message body that body came In the <provided-by> element of the PIDF-LO, the Proxy MUST identify
from that server (by some naming convention not defined here) 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 ERC 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) 9.1 UA-to-Proxy Routing the Message with INVITE (secure)
When Alice signifies "sos@" [per 3], her UA must understand this 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 message MUST NOT use S/MIME for the message body, because this is an
emergency call - otherwise the message will not properly route to emergency call - otherwise the message will not properly route to
the correct destination. Two definite possibilities will exist for the correct destination. Two definite possibilities will exist for
how this message flow will occur [note: the message flows are not 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 being defined here, they are defined in [11], but two are shown here
to show the messages themselves]. The first possibility has Alice to show the messages themselves]. The first possibility has Alice
skipping to change at page 33, line 27 skipping to change at page 35, line 34
--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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
skipping to change at page 33, line 49 skipping to change at page 36, line 4
<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.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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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--
The second probability in message flows is in Figure 4B. in which The second probability in message flows is in Figure 4B. in which
skipping to change at page 35, line 51 skipping to change at page 38, line 7
--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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
skipping to change at page 36, line 22 skipping to change at page 38, line 29
<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.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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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 UA-to-Proxy Routing with UPDATE 9.2 UA-to-Proxy Routing with UPDATE
If the previous example of the location contained in the INVITE were 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 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 responded with a 200 OK, the UPDATE method is the appropriate SIP
Request Method to use to update the proxies and ERC personnel that Request Method to use to update the proxies and ERC personnel that
Alice has moved geo-locations from where she initially made her set- Alice has moved locations from where she initially made her set-up
up request. request.
In this scenario (shown in the call flow of Figure 5A), Alice In this scenario (shown in the call flow of Figure 5A), Alice
sending the UPDATE message here may cause the Proxy to CANCEL an sending the UPDATE message here may cause the Proxy to CANCEL an
existing pending INVITE Request, and retransmit INVITE to a NEW existing pending INVITE Request, and retransmit INVITE to a NEW
ERC(2), for example, if she walked across a street into a new ERC ERC(2), for example, if she walked across a street into a new ERC
coverage area. The Proxy MUST remain transaction stateful in order coverage area. The Proxy MUST remain transaction stateful in order
to be aware of the 200 OK Response from ERC1. Upon receiving the to be aware of the 200 OK Response from ERC1. Upon receiving the
UPDATE from Alice and analyzing the location provided by the message UPDATE from Alice and analyzing the location provided by the message
looking for a geographic change, either forwarding that message to looking for a location change, either forwarding that message to
ERC1 if the change is still within ERC1's coverage area, or deciding 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 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 (ERC2 in this case) with her new location. If the latter change in
destinations is required, the Proxy MUST CANCEL the pending INVITE destinations is required, the Proxy MUST CANCEL the pending INVITE
to ERC1 (with a 487 "terminated request" being the specified to ERC1 (with a 487 "terminated request" being the specified
response). response).
SIPS MUST be used by Alice initially. Upon any failure of the SIPS SHOULD be used by Alice initially. Upon any failure of the
initial Request, Alice's UA can decide to send the new message initial Request, Alice's UA MUST decide to send the new message
without SIPS. without SIPS.
UA Alice Proxy ERC1 ERC2 UA Alice Proxy ERC1 ERC2
| INVITE [M1] | | | | INVITE [M1] | | |
|---------------->| | | |---------------->| | |
| | INVITE [M2] | | | | INVITE [M2] | |
| |------------>| | | |------------>| |
| 183 SP [M3] | | | | 183 SP [M3] | | |
|<----------------| | | |<----------------| | |
skipping to change at page 38, line 30 skipping to change at page 40, line 39
--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>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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>
skipping to change at page 38, line 48 skipping to change at page 41, line 4
<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.cisco.com</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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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 her
UA receiving a final response from the ERC. In this case, Alice has UA receiving a final response from the ERC. In this case, Alice has
walked across the South Wacker Drive to another building. Here is walked across the South Wacker Drive to another building. Here is
skipping to change at page 39, line 49 skipping to change at page 42, line 4
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:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2004-07-11T08:57:29Z</timestamp> <timestamp>2004-11-11T08:57: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:HNO>250</cl:HNO>
<cl:PRD>South Upper</cl:PRD> <cl:PRD>South Upper</cl:PRD>
<cl:A6>Wacker</cl:A6> <cl:A6>Wacker</cl:A6>
skipping to change at page 40, line 20 skipping to change at page 42, line 29
<cl:PC>60606</cl:PC> <cl:PC>60606</cl:PC>
<cl:NAM>Venice Cafe</cl:NAM> <cl:NAM>Venice Cafe</cl:NAM>
<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.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>2004-07-13T14:57:29Z</gp:retention- <gp:retention-expiry>2004-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) 9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure)
left blank for now left blank for now
9.3 425 "Retry Location Body" Error Response
In the case that a SIP Proxy detects an error in a message
containing location information specific to that message body and
has the location of that UAC locally, a new 400 level error needs to
be sent back to the UAC to instruct the UAC to include the included
location information message body in a subsequent message. This
document creates the new error code:
425 (Retry Location Body)
The UAC MUST ]retransmission of the failed message including this
new location information. User agents may conclude they have
already supplied a proper LO in the failed request. That LO can be
resent, but the Proxy 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 10. Meeting RFC3693 Requirements
Section 7.2 of [7] details the requirements of a "using protocol". Section 7.2 of [7] details the requirements of a "using protocol".
They are: They are:
Req. 4. The using protocol has to obey the privacy and security Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage of the corresponding Rules regarding the transmission and storage of the
LO. LO.
skipping to change at page 41, line 18 skipping to change at page 43, line 47
transaction. transaction.
This document specifies that the LO be contained in the body of a This document specifies that the LO be contained in the body of a
single message. single message.
11. Current Known Open issues 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) Should a Proxy somehow label its location information in the 4XX
into an emergency call set-up (the INVITE)? (Retry Location Body) message?
1a) This has the additional implication of whether or not, or
regardless of the fact the UAC already inserted location into
the sos@homedomain INVITE.
1b) Should the Proxy somehow differentiate its location
information from that provided by the UAC (with each LI
having a SIP entity (type?) originator label?
1c) Should there be any behavior difference with respect to Open
Issue #1b if the Proxy does not know or cannot tell if the
UAC inserted location information (further emphasizing the
need for some form of originator label)?
2) Whether SIP Proxies SHOULD be able to return location information
in a Redirect message to the UAC making the emergency call?
12. New Open Issues
These are new open issues to be addressed within this document or
the topics/areas dropped from consideration:
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 2) Still have not determined how a SIP entity can request location
specification effort (from a requirements ID effort) to be delivered in a certain format (civil vs. coordinate).
7a) will re-request to the ADs after IETF60 for this 3) Still have not determined how a UAC can request the UAS return
its location in a 1XX or 2XX response
8) Req U-PS7 (Proxy Assertion of a Location body) is not addressable 4) Still have not determined if a Redirect model should be accounted
yet in SIP (as Identity is barely addressable). for (if the 3XX response includes LI, does that get included in
the new Request by the UAC?)
8a) Should this requirement remain as a goal? 5) This document needs to be renamed within SIPPING to remove the
"requirements" portion
9) From section 9.2 (Emergency call with an updated location), if 6) From section 9.2 (Emergency call with an updated location), if
Alice does venture into another coverage area, how does her new Alice does venture into another coverage area, how does her new
UPDATE with new location get sent to a second (and now UPDATE with new location get sent to a second (and now
appropriate) ERC(2)? appropriate) ERC(2)?
The pending INVITE needs to be cancelled or able to be The pending INVITE needs to be cancelled or able to be
sequentially forked (which not all Proxies will be able to do). sequentially forked (which not all Proxies will be able to do).
Without that occurring, the new UPDATE will not cause a new Without that occurring, the new UPDATE will not cause a new
INVITE to be originated from the Proxy towards ERC2... and what INVITE to be originated from the Proxy towards ERC2... and what
happens to the UPDATE message (which cannot be an original happens to the UPDATE message (which cannot be an original
request into ERC2)? request into ERC2)?
12. 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
2) Is there a need to create a new events package for a subscription
to a UA to get it's location either at periodic time intervals or
when the UA has determined it has moved?
13. Security Considerations 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.
14. IANA Considerations 14. IANA Considerations
There are no IANA considerations within this document at this time. This section defines two new 4XX error response codes within the
sip-parameters section of IANA. [NOTE: RFC XXXX denotes this
document.
14.1 IANA Registration for Response Code 4XX
RFC number: XXXX
Response code: 424
Default reason phrase: Bad Location Information
14.2 IANA Registration for Response Code 4XX
RFC number: XXXX
Response code: 425
Default reason phrase: Retry Location Body
15. 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.
16. References 16. References
skipping to change at page 44, line 29 skipping to change at page 46, line 35
RFC 3515, April 2003 RFC 3515, April 2003
17. Author Information 17. Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 33.00111N 2200 East President George Bush Turnpike 33.00111N
Richardson, Texas 75082 USA 96.68142W Richardson, Texas 75082 USA 96.68142W
jmpolk@cisco.com jmpolk@cisco.com
Brian Rosen Brian Rosen 40.4N
Marconi Communications, Inc. br@brianrosen.net 80.0W
2000 Marconi Drive 40.65923N
Warrendale, PA 15086 80.09958W
Brian.rosen@marconi.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
skipping to change at page 45, line 31 skipping to change at page 47, line 36
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
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:
January 19th, 2005 April 25th, 2005
 End of changes. 110 change blocks. 
265 lines changed or deleted 374 lines changed or added

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