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