ECRIT Working Group James Polk Internet-Draft Cisco Systems Expires: Aug 27th, 2006 Feb 27th, 2006 ECRIT Mapping During Session Initiation Protocol Registration draft-polk-ecrit-mapping-during-registration-00 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 August 27th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses four different Layer-7 options to solve the problem of getting the appropriate Public Safety Answering Point (PSAP) Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) into an emergency calling capable device prior to it's user calling for help. Polk Expires August 27th, 2006 [Page 1] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. Options for Layer-7 Mapping Prior to Emergency Call . . . . . 3 3. Requirements on Transaction to Learn PSAP-URI at Layer-7 . . 4 4. Basic Assumptions About Location . . . . . . . . . . . . . . 5 5. Transaction Overview . . . . . . . . . . . . . . . . . . . . 6 6. Option #1 - SIP REGISTER with a PSAP-URI Request Header . . . 6 6.1 New PSAP-URI Header in SIP . . . . . . . . . . . . . . . 6 6.2 Usage of PSAP-URI Header Field . . . . . . . . . . . . . 7 6.3 PSAP-URI Option Tag . . . . . . . . . . . . . . . . . . . 7 6.4 SIP Element Rules . . . . . . . . . . . . . . . . . . . . 7 7. Option #2 - SIP REGISTER with a new event package . . . . . . 10 8. Option #3 - UA Performs a HTTP Query to a Remote Server . . . 11 9. Option #4 - SIP SUBSCRIBE With a New Event Packet . . . . . . 11 10. Examples of All Four Options . . . . . . . . . . . . . . . . 11 10.1 Example of PSAP-URI Header Transaction . . . . . . . . . 11 10.2 Example of SIP REGISTER Event Package Transaction . . . . 12 10.3 Example of HTTP Transaction . . . . . . . . . . . . . . . 13 10.4 Example of SIP SUBSCRIBE Event Package Transaction . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1 Normative References . . . . . . . . . . . . . . . . . . 13 14.2 Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 15 1. Introduction ECRIT Requirements [ID-ECRIT-REQS] are defining how a emergency capable device requests a binding of a given location in the form of a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] to a SIP(S)-URI of the appropriate PSAP for that location. [ID-SOS] defines how a voice call can be identified as an emergency cell set-up message within SIP. The prevalent model most are working towards is that a user of a SIP user agent (UA) enters a designated (locally, perhaps by law) dialstring into the entry point of said UA, which recognizes this as a locally significant emergency dialstring. Both [ID-DHC-DIAL] and [ID-ECRIT-DIAL] provide means that this can be learned from the UA's location at different layers of the network during boot-up time, as well as the UA likely being configured with an appropriate 'home' dialstring the user will have learned from society. For example, in North America the dialstring would be '9-1-1', and it is '9-9-9' in the United Kingdom. Polk Expires August 27th, 2006 [Page 2] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 Once the caller enters the appropriate dialstring, the UA sends a specially formed SIP INVITE message with a Request-URI of "urn:service:sos" and includes the location of the UA. Within the network, a SIP server, called an Emergency Services Proxy Server (ESRP) will be the first to understand the concept of emergency calling, and provide a unique routing action with this message. The ESRP will query a remote server with the ECRIT Mapping protocol, yet to be defined, but scoped in [ID-ECRIT-REQS]. This is ECRIT mapping protocol will return the appropriate PSAP SIP(S)-URI to be placed into this emergency message for routing to the PSAP. A few have questioned if this is the best time to rely on this Location-to-PSAP routing decision. What if the mapping function fails, what happens to the INVITE message? [ID-DHC-URI] defines how a user agent can learn the appropriate PSAP-URI well before the emergency call is placed by the user. Some want the mapping function to have the freshest information. This is ideal, with no doubt. But there are always failures in systems, this document discusses one alternative time in which a UA can learn its PSAP-URI. For the purposes of clarity, throughout this document the acronyms PSAP SIP(S)-URI and PSAP-URI mean the same thing. The intention is addressing the SIP INVITE with a Request-URI or a (loose) Route header that is destined for the network local to the appropriate PSAP. [ID-MAPPING] provides several scenarios in which this location-to- PSAP-URI mapping can occur, and the ideal situation is that the mapping can occur in all the scenarios and not conflict. This is to show that mapping should be done before an emergency call takes place, as well as during the emergency call. The former transaction provides a fallback mapping result that can be used at any time there is a failure in the primary ECRIT mapping function during the call, without having to send an error back to the UA. The UA may not know what to do with an error of this kind. 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]. 2. Options for Layer-7 Mapping Prior to Emergency Call There are four options discussed in this document for how a PSAP-URI can be obtained by a SIP user agent during, or soon after device Polk Expires August 27th, 2006 [Page 3] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 registration: Option #1 - SIP REGISTER with a header in the request Option #2 - SIP REGISTER with a new event package Option #3 - UA performs a HTTP Query to a remote server Option #4 - SIP SUBSCRIBE with a new event packet The advantages of placing this function in a SIP REGISTER message is that in travels with the device configuration. Meaning the UA would learn of this information at boot time, with appropriate indicators to tell the UA when the Registrar can and cannot perform this task. Using a new event package creates more flexibility in what information can be provided lateral to the PSAP-URI, for example: - a service-identifier type of PSAP-URI - indicating if this is the primary or secondary URI PSAP target The type of PSAP-URI is important in those countries that today have more than one emergency dialstring; [ID-SOS] provides a list of service-id types. For example, in Switzerland, the dialstring '116'is used to contact the police, and '117' is used to contact the fire department. This capability is not available throughout the world, but it is important were it is available now; and may spread to other parts. The ability to download a primary and secondary PSAP-URI means there is a fallback with this fallback idea. Given that in times of an emergency, preloading however many fallback routes is never a bad idea. But there will likely always be a primary coverage PSAP in any case, and this should be identifiable. Constructing a request and response for a PSAP-URI is not really that hard, and neither is adding a cursory second piece of information to that URI, but there may be some security risks that some may not want to take on a open public network in transit to an emergency services network. Choosing one of the two ways in a SIP REGISTER Request is open for discussion. Creating this capability in HTTP should be fairly straight forward, but there have been some issues raised lately that not all HTTP implementations are created equal, and this would force HTTP onto every UA that wanted this capability, which may not be the case, and may not be desired. Here we talk about an HTTP server being any server running HTTP, and not a necessarily (any or all) traditional Web-server(s). Polk Expires August 27th, 2006 [Page 4] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 It is possible that the same, or a similar, event package could be used in a SIP SUBSCRIBE message as is suggested above for a REGISTER message. 3. Requirements on Transaction to Learn PSAP-URI at Layer-7 The following are the requirements necessary for a UA to learn its PSAP-URI during a Layer-7 transaction: Req#1 - A (SIP or HTTP) user agent MUST be able to indicate it requires an PSAP-URI during a transaction with a remote entity (i.e. a SIP Registrar or HTTP server). Req#2 - A (SIP or HTTP) user agent SHOULD be able to indicate it requires a secondary PSAP-URI during a transaction with a remote entity (i.e. SIP Registrar or HTTP a server). Req#3 - A user agent MUST its location in a PIDF-LO by-reference or by-value in the request for a PSAP-URI. By-value is RECOMMENDED as a dereference transaction can also fail. Req#4 - A (SIP or HTTP) user agent SHOULD be able to indicate which service-id type of PSAP-URI it is seeking during a transaction with a remote entity (i.e. only police or only fire). Req#5 - A (SIP or HTTP) user agent SHOULD be able to indicate more than one service-id type of PSAP-URI it is seeking during a transaction with a remote entity (i.e. to a general request, respond with all that apply in that location/country). Req#6 - A server node (SIP Registrar Server or server running HTTP) MUST recognize a request for a PSAP-URI from a UA, understand to look for the UA's location within the message, then perform an ECRIT Mapping function (query) to learn the appropriate URI for that location. Req#7 - A server node (SIP Registrar or HTTP Server) MUST be able to respond with one or more PSAP-URI's for that location, including indicating the service-id type of URI each is in the response of a transaction with the user agent. Req#8 - A user agent MUST be able to request and update existing information at any time the device can contact the server. 4. Basic Assumptions About Location One basic assumption has to be made here: the UA knows its location, either by-value or by-reference. Without this knowledge, any request for the appropriate PSAP-URI would not yield a valid answer, Polk Expires August 27th, 2006 [Page 5] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 because there is such a list to choose from. This document does not discuss how the UA was sent, retrieved or knows its location; just that it has to know where it is, at least at a country level, in order to expect a server to plausibly be able to answer this request for information. 5. Transaction Overview Here is the basic message flow of this transaction, regardless of which of the four options are chosen: Here Alice is registering to a (SIP or HTTP) server. Alice SIP or HTTP Server [M1] Request ------------------------> [M2] Response <------------------------ From a "where in the request is the request indication for the PSAP-URI"? It does not matter from a messaging point of view. The request indication could be in a Header or a new event package message body. The event package could be different for what goes in a SIP REGISTER and SUBSCRIBE Request, the transaction looks the same. It also looks similar to an HTTP transaction, even it the message body is different. The key facet of the request is two-fold: - That the message contains location by-value or by-reference, and - That the message requests what it seeks This message MAY be at device boot time in each of these messages, or it MAY be after device boot time with any of these messages. 6. Option #1 - SIP REGISTER with a PSAP-URI Request Header 6.1 New PSAP-URI Header in SIP Communicating the primary or secondary PSAP-URI in a request or response can be accomplished with a new header. The PSAP-URI header would have the following syntax (The "token-nodot" production is copied from [RFC3265]): PSAP-URI = "PSAP-URI " HCOLON PSAP-URI-value *(COMMA PSAP-URI-value) PSAP-URI-value = (absoluteURI / option-tag) option-tag = string Polk Expires August 27th, 2006 [Page 6] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 service-id = string NOTE: we aren't sure this BNF is correct. The goal is to get this Result as a Request: PSAP-URI: , , , And this result in a Response: PSAP-URI: 6.2 Usage of PSAP-URI Header Field The following table extends the values in Tables 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- PSAP-URI Rr - - - - o o - Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- PSAP-URI Rr o o o o - o - This header is opaque to proxy servers. It has optional usage in the REG [RFC3261], OPT [RFC3261], SUB/NOT [RFC3265], UPD [RFC3311], INF [RFC2976] and MSG [RC3428]. 6.3 PSAP-URI Option Tag This document creates a new option tag "psap-uri" to be used in Requires, Supported and Unsupported headers in SIP between compliant SIP elements of this extension. At this time, the authors do not see any need for this option tag to be placed in the Proxy-Requires header, as this extension should be opaque to proxies and merely propagated by B2BUAs. This option tag will be IANA registered. 6.4 SIP Element Rules Here are the behaviors of the relevant SIP elements within this operation. This SIP extension is opaque to SIP Proxies, SHOULD be copied unchanged from receiving request to transmitted request by B2BUAs and SBCs. Polk Expires August 27th, 2006 [Page 7] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 6.4.1 UAC Behavior with PSAP-URI Header Option A UAC wanting an appropriate PSAP-URI be returned during registration process will do the following: - The UAC SHOULD include psap-uri Option-tag in a Requires header, but MAY include option-tag in Supported header to prevent initial 420 if Registrar doesn't understand this extension. - The UAC MUST include location in the REGISTER Request message, by-value is RECOMMENDED, but MAY send location by-reference in Location header [ID-SIP-LOC]. - The UAC SHOULD include a Location header in the request, with a cid indication of where location is in the message body, even if there is only one message body part. - If the UAC has its location by-reference URI, it MUST include this in the Location header of the REGISTER request, unless location by-value is included. Both MUST NOT be included in the same message. - A UAC requesting an PSAP-URI MUST expect to receive a server identifier in the response. - The UAC SHOULD use S/MIME to protect the PIDF-LO for e2e confidentiality. - The UAC MUST use TLS or IPSec for hop-by-hop confidentiality. - A UAC MAY request this PSAP-URI with every REGISTER Request, include a refresh, to ensure it has the freshest information. - There may be more than one valid PSAP-URI for where the UAC is at the moment. The UAC MUST be prepared to receive more than one URI in the PSAP-URI header. 6.4.2 Server Behavior with Emergency-Dialstring Header Option A Registrar server understanding the concept of PSAP-URI will do the following: - The Registrar MUST understand Emergency-Dialstring header and emergency-dialstring option-tag in a Supported or Requires header. - If the Registrar does not understand the psap-uri option-tag in a Requires header, the Registrar MUST reject the message with a 420 (Bad Extension) Response, including the psap-uri option-tag in an Unsupported header. - A Registrar MUST respond to an OPTIONS request with psap-uri Polk Expires August 27th, 2006 [Page 8] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 option-tag in a Supported header with the psap-uri option-tag in an Unsupported header. - Having understood the request to perform an ECRIT Mapping Query for a PSAP-URI, the Registrar MUST look for location within the Request message to determine where the UAC is geographically, or contact another server, perhaps using another protocol, that can do this operation. - The Registrar MUST look for the Location header in the Request message to indicate a location by-reference URI, or a cid value of where the location message body part is in the overall message body [ID-SIP-LOC]. - The Registrar MUST understand location by-reference, per [ID-SIP-LOC] and fetch the PIDF-LO from remote server to include the location of the UAC in the ECRIT Mapping Query. - The Registrar MUST understand the content-type application/pidf+xml to properly parse the PIDF-LO fetched or from the by-value message body. - The Registrar MUST understand all both parts of the PSAP-URI Header (i.e. also the service-ID part). - A request for an PSAP-URI MUST include a service identifier in the response, with the default value being 'primary'. - If more than one PSAP-URI is used or appropriate within the UAC's current location, more than one URI MUST be returned in the PSAP-URI header, separated by a ',' (comma), with each URI partnered with the respective service identifier - The Registrar MUST use TLS for hop-by-hop Confidentiality of these Transactions; IPSec usage is optional. - The Registrar MUST adhere to the location retention and distribution rules set in the PIDF-LO [RFC4119]. 6.4.3 Error Conditions with Emergency-Dialstring Header Option 6.4.3.1 UAC Error Conditions A user agent client, having included an PSAP-URI in a request message, receives an error response, will do the following: - If the UAC receives a 420 (Bad Extension), if it placed the psap-uri option tag in a Requires header, it SHOULD resend the REGISTER request, but place the psap-uri option tag in a Supported header. Polk Expires August 27th, 2006 [Page 9] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 - If the UAC sent a REGISTER with an psap-uri option tag in a Requires header, and receives a 503 (Service Unavailable) from the Registrar with an psap-uri option tag in a Supported header, it knows the Registrar understood the request, but could not complete URI request. The UAC SHOULD retry registration with the psap-uri option tag in a Supported header. - If the UAC receives a 415 (Unsupported Media type) from a Registrar to the content-type application/pidf+xml, the UAC SHOULD NOT attempt to send a PIDF-LO again to the Registrar, meaning the UAC cannot ask for its PSAP-URI from that SIP element. 6.4.3.2 Registrar Error Conditions to Header A Registrar server understanding the concept of PSAP-URIs will do the following: - If the Registrar does not understand the psap-uri option tag in a Requires header, the proper response is a 420 (Bad Extension), including psap-uri - If the Registrar does not understand the psap-uri option tag in a Supported header, the proper response is to convey a lack of support for the option tag by including this in the Unsupported header in the response message - If the Registrar does not understand the content-type application/pidf+xml, the proper error response is a 415 (Unsupported Media type) - an Unsupported header MUST be in the 415, which includes this option tag - If a Registrar server understands the concept of PSAP-URIs, and receives a request for an PSAP-URI from a UAC during registration in a Requires header, but for whatever reason cannot complete this part of the transaction, the server MUST return a 503 (Service Unavailable) response to the UAC. The Registrar MUST include the psap-uri option tag in a Supported header to indicate this part of the request was understood, but could not be performed at this time. 7. Option #2 - SIP REGISTER with a new event package The creation of a new SIP REGISTER event package to request and respond with a psap-uri and service identifier in a request or response can be accomplished ... This section to be completed soon Polk Expires August 27th, 2006 [Page 10] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] 8. Option #3 - UA Performs a HTTP Query to a Remote Server The creation of a new HTTP Query to request and respond with a psap-uri and service identifier in a request or response can be accomplished ... This section to be completed soon [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] 9. Option #4 - SIP SUBSCRIBE With a New Event Packet The creation of a new SIP SUBSCRIBE event package to request and respond with a psap-uri and service identifier in a request or response can be accomplished ... This section to be completed soon [The authors did not have time prior to the submission cut-off to complete additional options to these requirements. We are sorry!] 10. Examples of All Four Options This section illustrates only one of the four options at this time. As soon as the event packages are completed in XML, they will be incorporated into the text here. However, if any of these options are not considered appropriate by the community, they will be dropped like a burning pan you didn't realize was hot before you picked it up. Thank you for your patience... 10.1 Example of PSAP-URI Header Transaction Here is Alice's modified registration transaction. Alice Registrar Server [M1] REGISTER (with PIDF-LO, and Requires plus PSAP-URI header) ------------------------> [M2] 200 OK (with PSAP-URI header) <------------------------ Polk Expires August 27th, 2006 [Page 11] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 The following message are *not* well-formed. [Message 1 - REGISTER from Alice to Registrar Server] REGISTER registrar-server@example.com SIP/2.0 Via: Alice To: Alice From Alice PSAP-URI: Requires: psap-uri Location: cid Call-ID: 1 Content-type: application/pidf+xml Content-Length: ... cid [PIDF-LO message body (not shown)] [Message 2 - 200 OK from Registrar Server to Alice] SIP/2.0 200 OK Via: Alice To: Alice From Alice PSAP-URI: Supported: psap-uri Call-ID: 1 Content-Length: 0 Location is sent to the Registrar in the form of the [RFC 4119] PIDF-LO message body in the above example. The Registrar is the destination UAS of this message, so it can read all that is in the message, even if encrypted. The Registrar will generate a ECRIT Mapping Query to learn the PSAP-URI for this location (which is include in the Query). The (hopefully) positive results of the query will be sent to the UA in the 200 OK SIP response. At this point, Alice's UA has a PSAP-URI, which she may refresh at any time, to place (conceivably) in a (loose) Route header of the INVITE request message that is generated if and when Alice calls for emergency help. The exact placement of this URI in the INVITE has not reach consensus in the community, but this is the likely target header for it. 10.2 Example of SIP REGISTER Event Package Transaction To be completed... Polk Expires August 27th, 2006 [Page 12] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 10.3 Example of HTTP Transaction To be completed... 10.4 Example of SIP SUBSCRIBE Event Package Transaction To be completed... 11. IANA Considerations This document will make IANA Registrations when one or more of the four options to these requirements has been decided upon. 12. Security Considerations A concern with this extension (in its current form) is making sure the header field is not changed in transit between the Registrar server and the UAC, as this could start a chain of events to occur that will have a SIP INVITE fallback to the a bad PSAP-URI if the ESRP Mapping function failed. Therefore, message integrity is necessary. Normal SIP mechanisms, such as using TLS or IPSec for message transmissions, should suffice. Message body confidentiality needs to be used to protect the PIDF-LO message body to adhere to location information retention and distribution rules. Normal SIP mechanisms, such as using TLS or IPSec for message transmissions, as well as S/MIME encryption of the message body, should suffice. 13. Acknowledgements Your name here 14. References 14.1 Normative References [ID-ECRIT-REQS] H. Schulzrinne, R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-04.txt, "work in progress", January 2006 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-00, "work in progress", January 2006 Polk Expires August 27th, 2006 [Page 13] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 [ID-DHC-DIAL] J. Polk, "A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring", draft-polk-dhc-emergency-dialstring-option-00, "work in progress", February 2006 [ID-ECRIT-DIAL] J. Polk, " Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring", draft-polk-ecrit-emergency-dialstring-00, "work in progress", February 2006 [ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers", draft-polk-dhc-uri-02.txt, "work in progress", October 2005 [ID-MAPPING] J. Polk, " Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling", draft-polk-ecrit-mapping-events-00.txt, "work in progress", February 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-01.txt, "work in progress", June 2005 14.2 Informative References [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC 3428, December 2002 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 Polk Expires August 27th, 2006 [Page 14] Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com 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 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 (2006). 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. Polk Expires August 27th, 2006 [Page 15]