SIPPING Workng Group R. Ramanathan Internet-Draft Microsoft Corporation Intended status: Informational October 14, 2006 Expires: April 17, 2007 Response code for declining completely draft-rajesh-sipping-605-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 April 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines new response code that clients would use for instructing the server to decline a call completely. This fills in the gap that existing response codes do not provide Ramanathan Expires April 17, 2007 [Page 1] Internet-Draft 605 October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 605 Decline Everywhere . . . . . . . . . . . . . . . . . . . . 3 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Normative References . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Intellectual Property and Copyright Statements . . . . . . . . . . 5 Ramanathan Expires April 17, 2007 [Page 2] Internet-Draft 605 October 2006 1. Introduction The 605 Decline Everywhere response code allows the receiving UA the ability to instruct the proxy to decline a call completely, and terminate all call legs including any staged ringing to other destinations such as a team. It fills in the gap that existing 6xx response codes have with staged ringing. The 605 looks identical to the 603 in all respects, except that the response code has a very special meaning for the proxy. Proxys that do not support 605 are expected to treat this as a 603 and send the response all the back to the client. 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. 605 Decline Everywhere We have the following scenarios that need to be addressed with SIP response codes Scenario1: User declines a call from one specfic endpoint and allows other endpoints to ring. One example of this scenario is where the current endpoint already has one or more ongoing calls and cannot accept any other calls. The client can send out a 486 Busy Here response code and the proxy will continue to ring other endpoints. Scenario2: User declines a call and does not want to accept it from any of his own endpoints. However, he would like the call to be answered by voicemail or, in a staged ringing scenario, by endpoints capable of answering the call such as a team member. The 603 response code allows the user to support this scenario. Scenario3: User is currently busy and knows that the call cannot be answered by any other of his own endpoints including voicemail. However he would like the call to be answered by other endpoints not his own (such as a team member) that are capable of answering the call. The 600 reason code can be used for this purpose Scenario4: User wants to decline the call and convey the intention that he wants to contact through a different mode. The user wants no Ramanathan Expires April 17, 2007 [Page 3] Internet-Draft 605 October 2006 other staged ringing endpoints such as team to pick up the call, and does not want the call to be answered by voicemail. The new 605 Decline Everywhere response code fills in this gap. The 605 response code indicates to the server to decline the call completely and stop further processing of the call. An example of a scenario there this is required is where the receving user wants to reply to the incoming call with another mode (such as instant messaging) and does not want the incoming call to be sent to voicemail or other destinations. The 605 is identical to 603 in all respects, with the exception that the Retry-After semantics shall not be supported. Proxy servers that do not support 605 are expected to sent it all the way to the calling party. Clients should be prepared to recive a 605 and treat it similar to a 603 4. References 4.1. Normative References [1] 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. Author's Address Rajesh Ramanathan Microsoft Corporation One Microsoft Way Redmond, WA 98052, USA Email: rajeshra@microsoft.com Ramanathan Expires April 17, 2007 [Page 4] Internet-Draft 605 October 2006 Full 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. 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. 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 Expires April 17, 2007 [Page 5]