SIPPING Working Group R. Ramanathan Internet-Draft Microsoft Corporation Intended status: Informational October 15, 2006 Expires: April 18, 2007 Response code for dynamic proxy redirect draft-rajesh-sipping-303-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 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines new response code that clients would use for hinting the server to retarget a redirect response rather than allowing the sending client do perform the redirect Ramanathan Expires April 18, 2007 [Page 1] Internet-Draft 303 October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 303 Proxy Redirect . . . . . . . . . . . . . . . . . . . . . . 3 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Normative References . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Intellectual Property and Copyright Statements . . . . . . . . . . 5 Ramanathan Expires April 18, 2007 [Page 2] Internet-Draft 303 October 2006 1. Introduction The 303 Proxy Redirect response code allows the receiving UA the ability to hint the proxy to retarget an INVITE, rather than send the INVITE all the way back to the calling UA. The 303 looks identical to the 302 in all respects, except that the response code servers as a hint to the proxy to retarget the INVITE. Proxys that do not support 303 or intentionally do not honor 303 are expected to send the 303 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. 303 Proxy Redirect SIP provides a 302 response code which allows the client receiving an INVITE request to redirect the caller to a new URI. The 302 response code can be sent all the way back to the calling party, or can be retargeted by the proxy. Currently SIP does not provide for a way for the redirecting client to instruct the server to perform one specific action dynamically on a call by call basis. An example where a new response code which provides a hint to retarget the call is needed is where the client wants to dynamically choose to the call to be sent through the PSTN gateways in the client's own domain for billing purposes. Another example is when the client is retargeting to a URI that is routable only through the receiving clients's own domain. For example if a redirecting to sip:+14251234567@microsoft.com;user=phone will fail from a federated company contoso.com because the microsoft.com access proxies may not authorize an incoming call to a PSTN number from contoso.com. Moving the decision the retargeting on the client side reduces complexity on the server side and provides more flexibilty to the client. The server does not need to be updated on the list of retargeting destinations, and clients can be designed to make this choice. Ramanathan Expires April 18, 2007 [Page 3] Internet-Draft 303 October 2006 The 303 response code is very similar in structure to the 302, but the server interprets this as a hint to retarget the response. When a client sends a 303 back, the proxy should handle this in the following way: Proxies that do not support 303 should send the response all the way to the caller. Proxies that do support the 303 but do not authorize the redirect for the user can either choose to send a 302 to the caller, or proxy the 303 all the way back. Proxies that support the 303 and authorize the redirect should retarget the INVITE to the Contact URI specified in the 303 response. Clients should be prepared to receive a 303 and treat it similar to a 302. 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 18, 2007 [Page 4] Internet-Draft 303 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 18, 2007 [Page 5]