SIP D. Worley Internet-Draft Bluesocket Intended status: Standards Track July 6, 2008 Expires: January 7, 2009 Supporting Multiple Path Routing in the Session Initiation Protocol (SIP) draft-worley-redundancy-response-03 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 7, 2009. Worley Expires January 7, 2009 [Page 1] Internet-Draft Supporting Path Redundancy July 2008 Abstract An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). To implement MPR well, the proxy which forks a request onto the redundant paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). This document is to begin a discussion of strategies for making this determination. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Revision History . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. draft-worley-sip-redundancy-response-00 . . . . . . . . . . 6 4.2. Changes from draft-worley-sip-redundancy-response-00 to draft-worley-sip-redundancy-response-01 . . . . . . . . 6 4.3. Changes from draft-worley-sip-redundancy-response-01 to draft-worley-sip-redundancy-response-02 . . . . . . . . 6 4.4. Changes from draft-worley-sip-redundancy-response-02 to draft-worley-sip-redundancy-response-03 . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Worley Expires January 7, 2009 [Page 2] Internet-Draft Supporting Path Redundancy July 2008 1. Background An increasing number of Session Initiation Protocol (SIP) [rfc3261] system architectures implement multiple path routing (MPR), the feature of providing more than one path for a call to reach a destination user agent (UA). (MPR is also called path redundancy (PR) or alternate path retry (APR).) Typical situations are: o multiple gateway devices that connect a SIP network to the PSTN, such that if one gateway is occupied to capacity, calls should be routed to the next gateway o a PSTN gateway device as fallback when SIP connection over the public Internet fails o sending a request to multiple services that determine how to reach a destination, with an order of precedence among the services as to which service is to be used (e.g., connecting to an ENUM contact, falling back to a PSTN gateway) From a protocol point of view, a proxy is presented with the situation where a request (typically an INVITE) should be serially forked to more than one SIP URI, and from an application-layer point of view, all of the URIs are expected to ultimately reach the same user agent (UA). Of course, if one fork of the request succeeds at the destination UA, the proxy should not attempt any further forks. If the forked request failed and did not reach the destination UA, then in order implement MPR, the proxy must attempt the next fork. But if the request did reach the destination UA, and the UA returned a failure response, sending the request to the same UA via a different path is unlikely to yield success, and may even degrade the user experience. For example, if the first request was not accepted by the attending human (ring-no-answer), sending a second request to the UA by a different path, which will cause the UA to alert again, is not the desired behavior. The purpose of this document is to open the discussion of methods by which the proxy can implement the desired behavior. Two subordinate problems are contained in the main problem: One is how the proxy becomes aware that a request to be forked is a MPR situation. Another is the question of when two destinations are to be considered to be "the same", and so constitute an MPR set. Worley Expires January 7, 2009 [Page 3] Internet-Draft Supporting Path Redundancy July 2008 2. Proposed Solutions This section discusses proposed solutions to the problem. One possible solution is to split the failure response codes into two groups, one of which is only generated by proxies, the other is only generated by UAs. Then the response code from a failed fork should identify whether the call reached a destination UA or not. Most current failure response codes fall into one or the other of these two classes, but several of them can be generated by either proxies or user agents. In addition, the rules for choosing the "best" response from among the set of responses from a set of forks must be adjusted to give preference to UA-generated responses, which causes difficulties in some situations where the UAC might be able to amend its request in ways that increase its chances of success. Other possible approaches to this problem are solicited. Worley Expires January 7, 2009 [Page 4] Internet-Draft Supporting Path Redundancy July 2008 3. Security Considerations Alternate path retry presents no security considerations that are known to the author beyond what is present in non-MPR SIP system architectures. Worley Expires January 7, 2009 [Page 5] Internet-Draft Supporting Path Redundancy July 2008 4. Revision History 4.1. draft-worley-sip-redundancy-response-00 First version. 4.2. Changes from draft-worley-sip-redundancy-response-00 to draft-worley-sip-redundancy-response-01 Add note that the new variant of 500 would be like "reorder" in the PSTN. Add note that dealing with 402 can be postponed to when 402 is standardized. Add section proposing how to split response codes. 4.3. Changes from draft-worley-sip-redundancy-response-01 to draft-worley-sip-redundancy-response-02 Narrow the scope of the document to be a problem description. 4.4. Changes from draft-worley-sip-redundancy-response-02 to draft-worley-sip-redundancy-response-03 Refresh I-D. Improve wording in some places. Worley Expires January 7, 2009 [Page 6] Internet-Draft Supporting Path Redundancy July 2008 5. Normative References [rfc3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Worley Expires January 7, 2009 [Page 7] Internet-Draft Supporting Path Redundancy July 2008 Author's Address Dale R. Worley Bluesocket Inc. 10 North Ave. Burlington, MA 01803 US Phone: +1 781 229 0533 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires January 7, 2009 [Page 8] Internet-Draft Supporting Path Redundancy July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Worley Expires January 7, 2009 [Page 9]