SIPPING Workng Group R. Ramanathan Internet-Draft M. Vakil Intended status: Standards Track S. Parameswar Expires: September 5, 2007 Microsoft Corporation March 4, 2007 Serial Forking and 605 draft-rajesh-sipping-605-01.txt 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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The session initiation protocol (SIP) [2] allows users' end systems to decline calls for many reasons. 6xx response codes communicate global failures generated by callee's end system. It defines 6xx class response codes in the spirit of parallel forking scenarios only. There're scenarios where, authoritative server performs parallel forking of the call to callee's own set of endpoints, and then serially move on to fork call to alternate set of endpoints Ramanathan, et al. Expires September 5, 2007 [Page 1] Internet-Draft Serial Forking and 605 March 2007 (callee's voice mail and/or team call). This draft clarifies behavior for existing 603 response code and proposes new 605 response code to handle complete rejection of the call, which halts any further processing of the call. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Serial Forking upon Partial Rejection . . . . . . . . . . . 3 3.2. Complete Call Rejection . . . . . . . . . . . . . . . . . . 4 3.2.1. Why not 603 for 605 above? . . . . . . . . . . . . . . 5 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. 603 Decline . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. 605 Decline Everywhere . . . . . . . . . . . . . . . . . . 6 5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. 603 Decline . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. 605 Decline Everywhere . . . . . . . . . . . . . . . . . . 6 6. 605 Decline Everywhere . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Ramanathan, et al. Expires September 5, 2007 [Page 2] Internet-Draft Serial Forking and 605 March 2007 1. Introduction The session initiation protocol (SIP) [2] allows users' end systems to decline calls for many reasons. 6xx response codes communicate global failures generated by callee's end system. It defines 6xx class response codes in the spirit of parallel forking scenarios only. There're scenarios where, authoritative server performs parallel forking of the call to callee's own set of endpoints, and then serially move on to fork call to alternate set of endpoints (callee's voice mail and/or team call). This draft clarifies behavior for existing 603 response code and proposes new 605 response code to handle complete rejection of the call, which halts any further processing of the call. The 603 response code in the current RFC3261, communicates that call has been rejected, and all existing call legs be cancelled. It doesn't specify, how call can be routed to voice mail and/or other alternate locations in the case of team call scenarios. This draft clarifies the current 603 behavior. On the other hand, it proposes new 605 response to communicate complete rejection of the call where it must not even send to any alternate location, beside cancelling existing call legs. This enables scenarios, such as callee wants to respond the call with alternate mode of communication, such as IM. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Motivation The following two scenarios have not been addressed by SIP [2] 3.1. Serial Forking upon Partial Rejection In the following scenario, Alice calls Bob. Bob's authoritative server forks the call to all of Bob's registered endpoints. Bob rejects the from one of his endpoints (softphone), and wants all of his endpoints to stop ringing. In this scenario, Bob does want to have the call forwarded to his team members. Carol and Tom are alternate point of contacts. Server forks the call to both of Bob's alternate point of contacts. Ramanathan, et al. Expires September 5, 2007 [Page 3] Internet-Draft Serial Forking and 605 March 2007 Alice's atlanta.com Bob's Bob's Cell Carol's phone Tom's cell Softphone softphone | INVITE(F1) | | | | | |----------->| | | | | | | INVITE(F2) | | | | | |------------->| | | | | | | | | | | | INVITE(F3) | | | | | |---------------------------->| | | | | 603 Decline | | | | | |<-------------| | | | | | CANCEL(F5) | | | | | |--------------|------------->| | | | | 200 OK (F6) | | | | | |<-------------|--------------| | | | | | | | | | 181 Call Being Forwarded (|F6) | | | |<-----------| | | | | | | | INVITE(F7) | | | | |--------------|------------------------>| | | | | INVITE(F8) | | | |--------------|--------------------------------------->| | | | | | | | | | | | | | | | | | | The current 603 semantic must be able to clarify this behavior and must allow calls to be serially forked when one set of locations are rejected to another set of locations. 3.2. Complete Call Rejection In the following scenario, Alice calls Bob. Bob's authoritative server forks the call to all of Bob's registered endpoints. Bob's softphone wants to respond by IM, and wants to completely reject the incoming INVITE, so that he can initiate another IM session back to Alice. Bob's softphone responds with new 605 response to achieve that. Server rejects the call completely, cancels existing legs, and doesn't serially fork to alternate set of contacts. Note that, this scenario cannot be handled by media negotiation during INVITE transaction, as caller may have multiple devices in hand with varied capabilities. After rejecting current INVITE, another INVITE for a different mode may end up at callee's other endpoint(s), depending upon the caller's devices capabilities. Ramanathan, et al. Expires September 5, 2007 [Page 4] Internet-Draft Serial Forking and 605 March 2007 Alice's atlanta.com Bob's Bob's Cell Carol's phone Tom's cell Softphone softphone | INVITE(F1) | | | | | |----------->| | | | | | | INVITE(F2) | | | | | |------------->| | | | | | | | | | | | INVITE(F3) | | | | | |---------------------------->| | | | | 605 Decline Everywhere | | | | |<-------------| | | | | | CANCEL(F5) | | | | | |--------------|------------->| | | | | 200 OK (F6) | | | | | |<-------------|--------------| | | | | | | | | | 605 Decline Everywhere | | | | |<-----------| | | | | | | | | | | The new proposed 605 response handles this case, by saying that all forking (parallel, serial) should seize and call MUST be rejected completely. 3.2.1. Why not 603 for 605 above? One may argue for using 603 Decline for the above described scenario for 605. The reason for not using 603 is that, co-existing widely rolled out SIP endpoints, who do not understand 605 semantic, may end up always rejecting the calls completely. And new endpoints, who support multi modal communication, may not be able to co-exist with these endoints and leverage identified features above. 4. Client Behavior 4.1. 603 Decline A UAS receiving the INVITE can decline the call partially using 603 to have the server cancel all the parallely forked call legs. If there're any alternate endpoints configured, call should be forwarded to those endpoints. One of those endpoints could also be voice mail or any other application server. The presence of Retry-After header could be the deciding factor, Ramanathan, et al. Expires September 5, 2007 [Page 5] Internet-Draft Serial Forking and 605 March 2007 whether to forward the call to alternate set of endpoints or not. If client inserts Retry-After header, it indicates that client wants to have the call retried at a later point in time. A UAC receiving 603 response should behave the same way as it does according to RFC3261. 4.2. 605 Decline Everywhere A UAS can cancel the call completely from all the alerting endpoint and all other possible alternate endoints, by sending 605 Decline Everywhere. In this case, client may send Retry-After header. A UAC receiving 605 response should treat it as it does any 6xx response and consider that call has been declined. If it does find Retry-After header, it may retry the request after that time. 5. Server Behavior 5.1. 603 Decline When a server receives 603 Decline response, it's free to forward the call further to any alternate set of location(s). If it decides to forward the call, it must absorb the 603 response and MUST NOT send 603 response upstream. If it doesn't forward the call to alternate location(s), then it must send 603 upstream. 5.2. 605 Decline Everywhere A server receiving 605 response must cancel all the existing forked call legs. It must not forward the call to any other endpoint and send 605 upstream immediately after canceling outstanding call leg(s). 6. 605 Decline Everywhere This response indicates to the receiving authoritative server that the callee's endpoint(s) have rejected the call completely and cannot answer the call at this time. It doesn't even want the call to be forwarded to any other configured alternate endpoint(s). Its default reason phrase is "Decline Everywhere" 7. IANA Considerations This section registers a new SIP response code according to the Ramanathan, et al. Expires September 5, 2007 [Page 6] Internet-Draft Serial Forking and 605 March 2007 procedures of RFC 3261. RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification]] Response Code Number: 605 Default Reason Phrase: Decline Everywhere 8. Security Considerations The 605 response code, is not revealing any alternate locations. All the security considerations related to SIP RFC3261 [2] apply in its entirety. 9. Acknowledgments Thanks to the SIPPING Mailing list (specifically to Paul Tidwell, John Elwell, Keith Drage, and Johnathan Rosenberg for providing useful comments). 10. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. Authors' Addresses Rajesh Ramanathan Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: rajeshra@microsoft.com Ramanathan, et al. Expires September 5, 2007 [Page 7] Internet-Draft Serial Forking and 605 March 2007 Mohammad Vakil Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: mvakil@microsoft.com Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: srirampa@microsoft.com Ramanathan, et al. Expires September 5, 2007 [Page 8] Internet-Draft Serial Forking and 605 March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ramanathan, et al. Expires September 5, 2007 [Page 9]