[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
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]