Internet Engineering Task Force J. Elwell Internet Draft Siemens draft-elwell-sipping-redirection-reason-00.txt Expires: November 2004 May 2004 Indicating redirection reasons in SIP Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This examines the need for signalling additional information concerning the reason for redirection in SIP and proposes two possible solutions. Elwell Expires - November 2004 [Page 1]
Indicating redirection reasons in SIP May 2004 Table of Contents 1 Introduction....................................................3 2 Candidate solutions.............................................4 2.1 Solution 1 - add a new "protocol" value to the Reason header..4 2.2 Solution 2 - add a new redirection-reason parameter to a contact URI...............................................................6 3 Conclusions.....................................................8 4 Acknowledgements................................................8 5 Author's Addresses..............................................8 6 Normative References............................................8 Elwell Expires - November 2004 [Page 2]
Indicating redirection reasons in SIP May 2004 1 Introduction Central to SIP [2] is the concept of redirecting or retargeting a request by a proxy, whereby the Request-URI in the original request is replaced before forwarding the request on the next hop. Sometimes this is due to normal rerouting behaviour of the proxy (e.g., resolving an address-of-record URI to a contact URI). At other times it is due to more application-related reasons, e.g., where a user has made arrangements for calls to that user under certain conditions to be forwarded to a different destination. Also retargeting can be performed as a result of a 3xx response from a redirect server. Different 3xx response codes reflect different reasons for rejecting the request. The History-Info header [3] provides a means for conveying information about a retarget to the final destination UAS and also back to the UAC. In addition to providing the retargeted-from and retargeted-to URIs for each recorded retarget, this header also conveys a reason by means of the Reason header. The Reason header accompanies the retargeted-from URI and reflects the reason why attempts to reach that target failed, normally in the form of the SIP response code concerned. However, there is nothing in either a 3xx response or the History- Info header to indicate an explicit reason for the redirection request or the retarget respectively. At present the reason is implicit in the reason for failure of the request to the original target. Sometimes this might give an accurate picture of what is happening, but not always. Consider the following cases: 1. A device acts as a redirect server because it is busy. None of the 3xx response codes can reflect that the reason for retargeting to the URI given in the Contact header of the 3xx response is because the existing target is busy. 2. A device acts as a redirect server because it alerts the user but fails to get a reply within a certain time. None of the 3xx response codes can reflect that the reason for retargeting to the URI given in the Contact header of the 3xx response is because the existing target failed to answer. 3. A proxy is scripted to retarget requests without first attempting to forward them to the original target. Retargeting may be unconditional or based on certain conditions such as date, time, the source of the request or caller preferences. Because it does this without forwarding the request to the original target, no SIP response code is applicable. Elwell Expires - November 2004 [Page 3]
Indicating redirection reasons in SIP May 2004 4. A proxy is scripted to perform hunting or distribution of calls among a number of different targets. When forwarding a request to a target selected from a list of candidate targets, the reason for retargeting is because of hunting or distribution, rather than because of any failure of the existing target. 5. In the hunting or distribution scenario above, forwarding a request to one target from the list of candidate targets may fail for a particular reason (e.g., busy), leading to selection of another target from the list. However, the reason for retargeting is because of hunting or distribution, not specifically because the previous target had a certain condition. This seems to point to a need to convey in a 3xx response or a History-Info header the reason for selecting the retargeted-to URI. Candidate reasons are: CFI, "Call forwarding immediate" - immediate retargeting without forwarding the request to the retargeted-from URI; CFB, "Call forwarding busy" - retargeting because the retargeted-from URI is busy; CFNR, "Call forwarding no reply" - retargeting because there was no reply at the retargeted-from URI; CD, "Call deflection" - retargeting because the user at the retargeted-from URI made a request in real time for retargeting; HUNT, "Hunting" - selection of the target by means of hunting or distribution; NORMAL "Normal redirection" (default) - normal retargeting of a request. Note that selection of the new target may depend on several other conditions (e.g., relating to date, time, the source of the request or caller preferences), but the reasons suggested above should be sufficient to convey the main circumstance leading to the retarget. Two candidate solutions are discussed below. 2 Candidate solutions 2.1 Solution 1 - add a new "protocol" value to the Reason header New reasons could be achieved by adding a new "protocol" value in the Reason header. For example, assume a session was initiated to sip:+14084953756@foo.com;user=phone. Elwell Expires - November 2004 [Page 4]
Indicating redirection reasons in SIP May 2004 Assuming the entity sending the INVITE supports the History-Info header, the INVITE would look like this: INVITE sip:+14084953756@foo.com;user=phone SIP/2.0 From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone> Call-ID: 12345600@foo.com CSeq: 1 INVITE History-Info: <sip:+14084953756@foo.com;user=phone>;index=1 ... The call is then redirected to a contact URI <sip:+44123456789@foo.com;user=phone> in a 302 response. The response would be as follows: SIP/2.0 302 Moved temporarily From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone>;tag=3 Call-ID: 12345600@foo.com CSeq: 1 INVITE Contact: <sip:+44123456789@foo.com;user=phone> Reason: Redirection; cause=CFI The call would be retargeted to the contact URI. The first History- Info header would be augmented with the two reasons for retargeting (302 and CFI)). A second History-Info header would be added with the new retargeted-to Request-URI: INVITE sip:+44123456789@foo.com;user=phone SIP/2.0 From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone> Call-ID: 12345600@foo.com CSeq: 1 INVITE History-Info: <sip:+14084953756@foo.com;user=phone?Reason: SIP; cause=302; text="Moved temporarily"?Reason: Redirection; cause=CFI>;index=1, <sip:+44123456789@foo.com;user=phone>;index=2 The "index 1" entry indicates that the call to +1-408-495-3756 was retargeted because of SIP response code 302 and redirection reason CFI. The "index 2" entry indicates that the call to +44-123456789 has not yet been further retargeted. For the case where the proxy initiates retargeting (not as a result of a 3xx response from a redirect server), the proxy itself would Elwell Expires - November 2004 [Page 5]
Indicating redirection reasons in SIP May 2004 need to generate the Reason header with Redirection;cause=CFI for inclusion in the index 2 URI in History-Info. This solution would require either a new standards track RFC or a standard published by another organisation to define the new "protocol" value in the Reason header. There is an impact on History-Info in that History-Info is required to capture the Redirection reason in a Reason header (since it's not part of the Contact URI in this case). In the current History-Info draft, only the SIP response code is captured in a Reason header. 2.2 Solution 2 - add a new redirection-reason parameter to a contact URI New reasons could be indicated using a new parameter in a URI. For example, assume a session was initiated to sip:+14084953756@foo.com;user=phone. Assuming the entity sending the INVITE supports the History-Info header, the INVITE would look like this: INVITE sip:+14084953756@foo.com;user=phone SIP/2.0 From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone> Call-ID: 12345600@foo.com CSeq: 1 INVITE History-Info: <sip:+14084953756@foo.com;user=phone>;index=1 ... The call is then redirected to a contact URI <sip:+44123456789@foo.com;user=phone;redirection-reason=CFI> in a 302 response. The response would be as follows: SIP/2.0 302 Moved temporarily From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone>;tag=3 Call-ID: 12345600@foo.com CSeq: 1 INVITE Contact: <sip:+44123456789@foo.com;user=phone;redirection- reason=CFI> The call would be retargeted to the contact URI. The first History- Info header will be augmented with the Redirection reason (302). A second History-Info header is added with the new retargeted Request- URI: Elwell Expires - November 2004 [Page 6]
Indicating redirection reasons in SIP May 2004 INVITE sip:+44123456789@foo.com;user=phone;redirection-reason=CFI SIP/2.0 From: "Mr. Whatever" <whatever@foo.com>;tag=2 To: <sip:+14084953756@foo.com;user=phone> Call-ID: 12345600@foo.com CSeq: 1 INVITE History-Info: <sip:+14084953756@foo.com;user=phone?Reason: SIP; cause=302; text="Moved temporarily">;index=1, <sip:+44123456789@foo.com;user=phone;redirection- reason=CFI>;index=2 The "index 1" entry indicates that the call to +1-408-495-3756 was retargeted because of SIP response code 302. The "index 2" entry indicates that the call to +44-123456789 has not yet been further retargeted, but that it was made as a result of a CFI redirection-reason. For the case where the proxy initiates retargeting (not as a result of a 3xx response from a redirect server), the proxy itself would need to generate the redirection-reason parameter for inclusion in the index 2 URI in History-Info. This solution has the advantage that the redirection reason is associated with a particular contact URI and would automatically get copied as part of the contact URI into the Request-URI of the retargeted request. It would be backward compatible with existing implementations of History-Info, since it would automatically be copied with the URI into the History-Info header. A possible disadvantage is that URI parameters are intended to influence a request constructed from the URI. It might be argued that redirection-reason does not meet this requirement. Note the difference between this and solution 1, whereby the additional reason is placed in the index 1 URI for solution 1 but in the index 2 URI for solution 2. It is arguable which is the more appropriate. Also solution 1 could be adapted to use the index 2 URI, if considered more appropriate. The SIP and SIPS URIs are extensible in that new parameters can be added and will be ignored by any implementation that does not understand them. There are plans to create an IANA registry for URI parameters (draft-ietf-sip-uri-parameter-reg-01), and this will require that new parameters be defined in an RFC. There is no impact on the History-Info draft. Elwell Expires - November 2004 [Page 7]
Indicating redirection reasons in SIP May 2004 3 Conclusions The SIP community is asked to express its opinions on the two proposed solutions or suggest other alternatives. 4 Acknowledgements The author would like to acknowledge considerable assistance from Francois Audet and Mary Barnes in drafting this contribution. 5 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com 6 Normative References [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the Session Initiation Protocol (SIP)", RFC 3326. [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [3] M. Barnes "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-sipping-history-info-02 (work in progress) 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 IETF's procedures with respect to rights in IETF 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. Elwell Expires - November 2004 [Page 8]
Indicating redirection reasons in SIP May 2004 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 (2004). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Elwell Expires - November 2004 [Page 9]