Internet DRAFT - draft-worley-redundancy-response

draft-worley-redundancy-response






SIP                                                            D. Worley
Internet-Draft                                           Nortel Networks
Intended status: Standards Track                           March 6, 2009
Expires: September 7, 2009


  Supporting Multiple Path Routing in the Session Initiation Protocol
                                 (SIP)
                  draft-worley-redundancy-response-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 7, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








Worley                  Expires September 7, 2009               [Page 1]

Internet-Draft         Supporting Path Redundancy             March 2009


Abstract

   An increasing number of SIP architectures implement multiple path
   routing (MPR), which is the providing of more than one path for a
   call to reach a destination user agent (UA).  A typical example is a
   redundant pair of gateways from a SIP system to the PSTN.  A call
   from the SIP system to the PSTN can pass through either gateway to
   ultimately reach the destination telephone.  In order to gain the
   benefits of redundancy in case one of the gateways fails or reaches
   capacity, a proxy forks INVITEs serially to both gateways.

   Unfortunately, if the call passes through one gateway but fails at
   the destination phone (e.g., ring-no-answer), the proxy will then
   fork the call to the other gateway, because the proxy has no way to
   know that the call failed at the destination phone rather than at the
   first gateway.  The second fork will fail in the same way at the same
   destination phone.  This annoys both the caller (because the call
   takes twice as long as it should before failing) and anyone within
   earshot of the destination phone.  Similar failures plague any other
   SIP architecture where a request can reach a destination through
   multiple paths.

   To gain the benefits of MPR without suffering from this problem, the
   proxy which forks a request onto the redundant paths needs to be able
   to determine if a fork that failed reached the destination UA and was
   rejected by the UA (and so an alternate path should not be tried), or
   if the fork failed before reaching the UA (and so an alternate path
   should be attempted).  This document is to begin a discussion of
   strategies for making this determination.






















Worley                  Expires September 7, 2009               [Page 2]

Internet-Draft         Supporting Path Redundancy             March 2009


Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Proposed Solutions . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Revision History . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  draft-worley-redundancy-response-00  . . . . . . . . . . .  8
     5.2.  Changes from draft-worley-redundancy-response-00 to
           draft-worley-redundancy-response-01  . . . . . . . . . . .  8
     5.3.  Changes from draft-worley-redundancy-response-01 to
           draft-worley-redundancy-response-02  . . . . . . . . . . .  8
     5.4.  Changes from draft-worley-redundancy-response-02 to
           draft-worley-redundancy-response-03  . . . . . . . . . . .  8
     5.5.  Changes from draft-worley-redundancy-response-03 to
           draft-worley-redundancy-response-04  . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10































Worley                  Expires September 7, 2009               [Page 3]

Internet-Draft         Supporting Path Redundancy             March 2009


1.  Background

   An increasing number of Session Initiation Protocol (SIP) [rfc3261]
   system architectures implement multiple path routing (MPR), the
   feature of providing more than one path for a call to reach a
   destination user agent (UA).  (MPR is also called path redundancy
   (PR) or alternate path retry (APR).)  Typical situations are:

   o  multiple gateway devices that connect a SIP network to the PSTN,
      such that if one gateway is occupied to capacity, calls should be
      routed to the next gateway

   o  a PSTN gateway device as fallback when SIP connection over the
      public Internet fails

   o  sending a request to multiple services that determine how to reach
      a destination, with an order of precedence among the services as
      to which service is to be used (e.g., connecting to an ENUM
      contact, falling back to a PSTN gateway)

   From a protocol point of view, a proxy is presented with the
   situation where a request (typically an INVITE) should be serially
   forked to more than one SIP URI, and from an application-layer point
   of view, all of the URIs are expected to ultimately reach the same
   user agent (UA).  Of course, if one fork of the request succeeds at
   the destination UA, the proxy should not attempt any further forks.

   If the forked request failed and did not reach the destination UA,
   then in order implement MPR, the proxy must attempt the next fork.
   But if the request did reach the destination UA, and the UA returned
   a failure response, sending the request to the same UA via a
   different path is unlikely to yield success, and may even degrade the
   user experience.  For example, if the first request was not accepted
   by the attending human (ring-no-answer), sending a second request to
   the UA by a different path, which will cause the UA to alert again,
   is not the desired behavior.

   The purpose of this document is to open the discussion of methods by
   which the proxy can implement the desired behavior.

   Two subordinate problems are contained in the main problem: One is
   how the proxy becomes aware that the forking of a request is a MPR
   situation.  Another is the question of when two destinations are to
   be considered to be "the same", and so constitute an MPR set.







Worley                  Expires September 7, 2009               [Page 4]

Internet-Draft         Supporting Path Redundancy             March 2009


2.  Proposed Solutions

   This section discusses proposed solutions to the problem.

   One possible solution is to split the failure response codes into two
   groups, one of which is only generated by proxies, the other is only
   generated by UAs.  Then the response code from a failed fork should
   identify whether the call reached a destination UA or not.  Most
   current failure response codes fall into one or the other of these
   two classes, but several of them can be generated by either proxies
   or user agents.  In addition, the rules for choosing the "best"
   response from among the set of responses from a set of forks must be
   adjusted to give preference to UA-generated responses, which causes
   difficulties in some situations where the UAC might be able to amend
   its request in ways that increase its chances of success.

   Other possible solutions to this problem are solicited.


































Worley                  Expires September 7, 2009               [Page 5]

Internet-Draft         Supporting Path Redundancy             March 2009


3.  Related Work

   This section lists related work.

      ITU-T Recommendation Q.850 (telephone call failure cause
      codes)[Q.850]

      The Q.850 failure cause codes used in SS7 provide a "location"
      field that distinguishes the network (caller's local network,
      callee's local network, transit network) in which the failure
      occurred.  In addition the cause codes are segregated in such a
      way that it is clear whether the call reached the destination
      telephone before failing.

      RFC 3326: The Reason Header Field for the Session Initiation
      Protocol (SIP)[rfc3326]

      The Reason header can carry a Q.850 failure cause code.  However,
      there is no provision for carrying the Q.850 location value.
      Given that the cause codes are well-segregated regarding network
      errors vs. endpoint errors, the cause code is probably sufficient
      to regulate MPR.

      The SIP SPECIFY Method[sreeram-specify]

      Abstract: This document proposes an extension to the Session
      Initiation Protocol (SIP).  This extension adds the SPECIFY method
      to the SIP protocol.  The intent of the SPECIFY method is to allow
      conveying SIP entity's (Proxy, User Agent, Redirect Server)
      intention of asynchronous service change (i.e. to be taken out of
      service or has just return to service) with and with out a backup
      SIP entity within the same administrative domain.

      No Service To This Number Reject Code[schwartz-nsr]

      Abstract: This specification discusses a SIP response error code
      ambiguity that may exist due to semantic differences between SIP
      [RFC3261] and TEL [RFC3966] URIs.













Worley                  Expires September 7, 2009               [Page 6]

Internet-Draft         Supporting Path Redundancy             March 2009


4.  Security Considerations

   Alternate path retry presents no security considerations that are
   known to the author beyond what is present in non-MPR SIP system
   architectures.














































Worley                  Expires September 7, 2009               [Page 7]

Internet-Draft         Supporting Path Redundancy             March 2009


5.  Revision History

5.1.  draft-worley-redundancy-response-00

   First version.

5.2.  Changes from draft-worley-redundancy-response-00 to
      draft-worley-redundancy-response-01

   Add note that the new variant of 500 would be like "reorder" in the
   PSTN.

   Add note that dealing with 402 can be postponed to when 402 is
   standardized.

   Add section proposing how to split response codes.

5.3.  Changes from draft-worley-redundancy-response-01 to
      draft-worley-redundancy-response-02

   Narrow the scope of the document to be a problem description.

5.4.  Changes from draft-worley-redundancy-response-02 to
      draft-worley-redundancy-response-03

   Changes were minimal.

5.5.  Changes from draft-worley-redundancy-response-03 to
      draft-worley-redundancy-response-04

   Added "Related Work" section.

   Updated contact information.

   Revised Abstract.
















Worley                  Expires September 7, 2009               [Page 8]

Internet-Draft         Supporting Path Redundancy             March 2009


6.  References

6.1.  Normative References

   [rfc3261]  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.

   [rfc3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

6.2.  Informative References

   [sreeram-specify]
              Kanumuri, S. and S. Sarkar, "The SIP SPECIFY Method",
              I-D draft-sreeram-specify-method-00, April 2007.

   [schwartz-nsr]
              Schwartz, D., "No Service To This Number Reject Code",
              I-D draft-schwartz-sipping-nsr-code-01, November 2008.

   [Q.850]    ITU-T, "Usage of cause and location in the Digital
              Subscriber Signalling System No. 1 and the Signalling
              System No. 7 ISDN User Part", ITU-T Recommendation Q.850,
              May 1998.
























Worley                  Expires September 7, 2009               [Page 9]

Internet-Draft         Supporting Path Redundancy             March 2009


Author's Address

   Dale R. Worley
   Nortel Networks Corp.
   600 Technology Park Dr.
   Billerica, MA  01821
   US

   Phone: +1 978 288 5505
   Email: dworley@nortel.com
   URI:   http://www.nortel.com








































Worley                  Expires September 7, 2009              [Page 10]