Internet DRAFT - draft-worley-sipcore-b2bua-passthru

draft-worley-sipcore-b2bua-passthru






SIPCORE                                                        D. Worley
Internet-Draft                                                     Avaya
Intended status: BCP                                    January 23, 2010
Expires: July 27, 2010


  Interoperation of "Application Server" B2BUAs with SIP Call Control
                 draft-worley-sipcore-b2bua-passthru-00

Abstract

   Some SIP architectures use "application servers", B2BUAs that are
   inserted between two user agents during a conversation, to provide
   additional processing.  Since B2BUAs do not follow the rules for SIP
   proxies, they do not by default interoperate with SIP call control
   operations.  Augmenting application servers with suitable behaviors
   for handling SIP call control operations mitigates these problems,
   and in many cases, allows standard user agents to use SIP call
   control features without modification.

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 July 27, 2010.

Copyright Notice

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




Worley                    Expires July 27, 2010                 [Page 1]

Internet-Draft    Application Servers and Call Control      January 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  In-dialog REFER  . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  INVITE/Replaces  . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  INVITE/Join  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  REFER/Target-Dialog  . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  draft-worley-sipcore-b2bua-passthru-00 . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15























Worley                    Expires July 27, 2010                 [Page 2]

Internet-Draft    Application Servers and Call Control      January 2010


1.  Background

   A number of SIP architectures, for example the IP Multimedia System
   (IMS), provide various features and services to users by inserting
   B2BUAs, called "application servers", into the path between two UAs.
   Each application server implements one feature to the users
   participating in the conversation.  This leads to a generic call
   structure as follows:

                        +----+     +----+     +----+
        UA1 <---------->|App1|<--->|App2|<--->|App3|<----------> UA2
                        +----+     +----+     +----+

   Since the application servers are B2BUAs, the figure contains four
   dialogs (each represented by an arrow), forming a "dialog chain"
   which carries the conversation between UA1 and UA2.  (The application
   servers may set up other dialogs to assist their functions for the
   dialog chain, but in this document we will only consider the dialog
   chain which carries the conversation between the two primary UAs.)

   (Note that proxies may be transiently or permanently ("Record-
   Routed") inserted into each of the dialogs.  Since proxies are
   transparent for the purposes of SIP call control operations, they
   need not be discussed in this document.)

   In some cases, application servers can be implemented as proxies.
   Since proxies are transparent for the purposes of SIP call control
   operations, these application servers need not be considered in this
   document.

   The structures of application servers that will be considered in this
   document are set up only to service a conversation between two UAs,
   and are to be dissolved when the dialog chain is terminated.  (This
   is in contrast to "session border controllers", which usually are to
   remain in the dialog chain regardless of call control operations
   executed by either UA.)  Typically a dialog chain is created by one
   or more proxies functioning as a "sequencing engine", which
   successively route the INVITEs that create the dialog chain to a
   series of application servers.  The sequencing engine and the
   application servers are usually administered by the service provider
   that immediately manages either the originating or destination UA.

   The route of the initial INVITEs creating the dialog chain is
   typically like this:







Worley                    Expires July 27, 2010                 [Page 3]

Internet-Draft    Application Servers and Call Control      January 2010


                  (1)    +---------------------+    (8)
           SIP --------->| Sequencing Engine   |-----------> SIP
                         +---------------------+
                          | ^      | ^      | ^
                       (2)| |   (4)| |   (6)| |
                          | |(3)   | |(5)   | |(7)
                          v |      v |      v |
                        +----+   +----+   +----+
                        |App1|   |App2|   |App3|
                        +----+   +----+   +----+

   The first dialog contains messages 1 and 2, the second dialog
   contains messages 3 and 4, the third dialog contains messages 5 and
   6, and the fourth dialog contains messages 7 and 8.

   Of course, application servers could be inserted by both the
   originating UA's service provider and the destination UA's service
   provider, and also by any intermediate service providers.  However,
   the techniques described in this document are insensitive to the
   manner in which the chain of application servers is established, so
   such details will not be discussed.






























Worley                    Expires July 27, 2010                 [Page 4]

Internet-Draft    Application Servers and Call Control      January 2010


2.  Problem Statement

   The design of SIP call control operations assumes that each UA is
   aware of the dialog identifiers (Call-Id, from-tag, and to-tag) of
   the dialog as seen by the other UA, and of the target URI of the
   other UA (carried by the Contact header in the SIP messages it
   sends).  Of course, these conditionsare true if a single dialog
   connects the two UAs, but it is not true if application server B2BUAs
   are inserted.  In the latter case, if the UA attempts to carry out a
   call control operation, it will (by default) fail, as the operation
   will operate upon the first B2BUA inserted rather than on the other
   UA.

   As a typical example, let us consider a "consultative transfer"
   operation.[service-examples] UA1 has established a dialog chain with
   UA2.  After putting that dialog on hold, UA1 establishes a dialog
   chain with UA3:

             Call-Id:X  +----+     +----+     +----+
        UA1 <---------->|App1|<--->|App2|<--->|App3|<----------> UA2
         ^              +----+     +----+     +----+
         |
         |   Call-Id:Y  +----+     +----+     +----+
         +------------->|App4|<--->|App5|<--->|App6|<----------> UA3
                        +----+     +----+     +----+

   UA1 then desires to connect UA2 with UA3, removing itself from
   communication.  UA1 does this by sending a REFER to UA2 within the
   established dialog, with the REFER's Refer-To URI specifying the
   target address of UA3, with a Replaces header-specification
   describing the dialog from UA2 to UA3.  Unless some additional
   processing is done, the REFER will arrive at UA2, with the Refer-To
   URI "App4&Replaces=X".  (Here omitting the to-tag and from-tag, as
   tag processing is exactly parallel to Call-Id processing.)  UA2 will
   then send an INVITE/Replaces to the target of App4 within dialog Y,
   and the new dialog will replace dialog Y:

                        +----+     +----+     +----+
        UA1             |App1|     |App2|     |App3|             UA2
                        +----+     +----+     +----+              ^
                                                                  |
         +--------------------------------------------------------+
         |
         |   Call-Id:Z  +----+     +----+     +----+
         +------------->|App4|<--->|App5|<--->|App6|<----------> UA3
                        +----+     +----+     +----+

   (In addition, the sequencing engine(s) may have added application



Worley                    Expires July 27, 2010                 [Page 5]

Internet-Draft    Application Servers and Call Control      January 2010


   servers on the path of the new dialog Z.) The problem is that the
   application servers App4, App5, and App6 remain in the path of the
   new dialog chain from UA2 to UA3, whereas they should be skipped; the
   stimulated INVITE from UA2 should have been directed to the target
   URI of UA3.














































Worley                    Expires July 27, 2010                 [Page 6]

Internet-Draft    Application Servers and Call Control      January 2010


3.  Requirements

   o  REQ-1 - A SIP User Agent is able to direct a within-dialog request
      to reach the target URI of the remote UA.

   o  REQ-2 - A SIP User Agent is able to direct an out-of-dialog
      request to reach the target URI of the remote UA.

   o  REQ-3 - A SIP User Agent can, within a request, effectively
      specify the dialog identifiers that a remote UA sees within a
      dialog chain that the SIP User Agent is participating in.
      Specifically, this can be done in the Replaces[replaces] and
      Join[join] headers of INVITE requests and the Target-
      Dialog[target-dialog] header of REFER requests.





































Worley                    Expires July 27, 2010                 [Page 7]

Internet-Draft    Application Servers and Call Control      January 2010


4.  Behavior

   This section describes behaviors to be adopted by application servers
   to satisfy the requirements to support SIP call control operations.
   These behaviors allow the user agents to perform call control without
   consideration for the presence of the applciation servers.  By
   displacing the burden of adaptation from the user agents (which are
   likely to be generic products) and placing it on the application
   servers (which are likely to be heavily customized for the context in
   which they operation), this strategy maximizes the liklihood of
   achieving interoperation in practical SIP envrionments of this kind.

   Because no new protocol elements are introduced by this document, we
   call these behaviors by the name B2BUA (or application server)
   "passthru" behavior.

4.1.  In-dialog REFER

   The first required behavior is one that is implemented in most
   application server B2BUAs already: A REFER request received within a
   dialog from one UA is passed through largely without change.  This is
   in contrast to how a "session border controller" (SBC) B2BUA would
   behave; an SBC would "shortstop" a REFER by having its UA component
   that receives the REFER act on the REFER within its containing dialog
   (which keeps the SBC within the dialog chain).

                   UA1             App1              UA2
                    |                |                |
                    |  REFER C1      |                |
                    |  Call-Id: D1   |                |
                    |--------------->|                |
                    |                |  REFER C2      |
                    |                |  Call-Id: D2   |
                    |                |--------------->|
                    |                |  200           |
                    |                |  Call-Id: D2   |
                    |                |<---------------|
                    |  200           |                |
                    |  Call-Id: D1   |                |
                    |<---------------|                |
                    |                |                |

   Of course, the second REFER has the Call-Id and tags of the dialog
   from App1 to UA2 rather than those in the first REFER.  The Refer-To
   URI of the REFER request is not modified.






Worley                    Expires July 27, 2010                 [Page 8]

Internet-Draft    Application Servers and Call Control      January 2010


4.2.  INVITE/Replaces

   The next needed behavior is to allow a UA to generate an INVITE/
   Replaces that effectively refers to the target URI and dialog
   identifiers of a remote UA, despite that the UA does not know them.
   This is implemented by requiring that an application server, when it
   receives an INVITE/Replaces at one of its target URIs, to:

   1.  determine that the Replaces header describes a dialog D-IN
       terminating at that target URI (and respond 481 if it does not),

   2.  determine the dialog D-OUT that is the "other side" of the dialog
       chain containing D-IN at this application server,

   3.  proxy the INVITE/Replaces

   4.  setting the request-URI to the remote target of D-OUT

   5.  changing the value of the Replaces header to the dialog
       identifiers of D-OUT.

   If the application servers in a dialog chain implement this behavior,
   an INVITE/Replaces will pass through the application servers in
   sequence and will arrive at the intended user agent with a Replaces
   header that describes the dialog as seen by the intended user agent.

   The consultative transfer example now operates in this way:
























Worley                    Expires July 27, 2010                 [Page 9]

Internet-Draft    Application Servers and Call Control      January 2010


      UA1             App1              UA2             UA3
       |                |                |               |
       |  INVITE App1   |                |               |
       |  Call-Id: D1   |                |               |
       |--------------->|                |               |
       |                |  INVITE App2   |               |
       |                |  Call-Id: D2   |               |
       |                |--------------->|               |
       |                |   200          |               |
       |                |   Contact: C2  |               |
       |                |<---------------|               |
       |   200          |                |               |
       |   Contact: C1  |                |               |
       |<---------------|                |               |
       |                |                |               |
      [Set up of dialog chain frm UA1 to UA3 omitted.]
       |                |                |               |
      [UA1 sends "REFER/Refer-To: C1&Replaces=D1" through application
       server chain to UA3.]
       |                |                |               |
       |                |  INVITE C1     |               |
       |                |  Call-Id: D5   |               |
       |                |  Replaces: D1  |               |
       |                |<-------------------------------|
       |                |  INVITE C2     |               |
       |                |  Call-Id: D5   |               |
       |                |  Replaces: D2  |               |
       |                |--------------->|               |
       |                |  200           |               |
       |                |  Call-Id: D5   |               |
       |                |  Contact: C2   |               |
       |                |<---------------|               |
       |                |  200           |               |
       |                |  Call-Id: D5   |               |
       |                |  Contact: C1a  |               |
       |                |------------------------------->|
       |                |                |               |

4.3.  INVITE/Join

   The B2BUA behavior needed to allow INVITE/Join to operate is exactly
   the same as that used for INVITE/Replaces.

4.4.  REFER/Target-Dialog

   The processing for an out-of-dialog REFER with a Target-Dialog header
   is analogous to that for INVITE/Replaces, with the Target-Dialog
   header providing the dialog identifiers that need to be rewritten,



Worley                    Expires July 27, 2010                [Page 10]

Internet-Draft    Application Servers and Call Control      January 2010


   rather than the Replaces header.


















































Worley                    Expires July 27, 2010                [Page 11]

Internet-Draft    Application Servers and Call Control      January 2010


5.  Security Considerations

   There are no known security implications of these behaviors.
















































Worley                    Expires July 27, 2010                [Page 12]

Internet-Draft    Application Servers and Call Control      January 2010


6.  Revision History

6.1.  draft-worley-sipcore-b2bua-passthru-00

   Initial version.














































Worley                    Expires July 27, 2010                [Page 13]

Internet-Draft    Application Servers and Call Control      January 2010


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [endpoint-view]
              Boulton, C., Evans, I., Liddell, G., Shutt, D., and P.
              Barrett, "An Extension to the Session Initiation Protocol
              (SIP) for Endpoint Session View",
              I-D draft-boulton-sip-endpoint-view-00, September 2009.

   [service-examples]
              Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
              K. Summers, "Session Initiation Protocol Service
              Examples", RFC 5359, October 2008.

   [replaces]
              Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
              Protocol (SIP) "Replaces" Header", RFC 3891,
              September 2004.

   [join]     Mahy, R. and D. Petrie, "The Session Initiation Protocol
              (SIP) "Join" Header", RFC 3911, October 2004.

   [target-dialog]
              Sparks, R., Johnston, A., and D. Petrie, "Session
              Initiation Protocol (SIP) Call Control - Transfer",
              RFC 5589, June 2009.

















Worley                    Expires July 27, 2010                [Page 14]

Internet-Draft    Application Servers and Call Control      January 2010


Author's Address

   Dale R. Worley
   Avaya Inc.
   600 Technology Park Dr.
   Billerica, MA  01821
   US

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








































Worley                    Expires July 27, 2010                [Page 15]