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 29, 2010.

Copyright Notice

Copyright (c) 2010 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 (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
2.  Problem Statement
3.  Requirements
4.  Behavior
    4.1.  In-dialog REFER
    4.2.  INVITE/Replaces
    4.3.  INVITE/Join
    4.4.  REFER/Target-Dialog
5.  Security Considerations
6.  Revision History
    6.1.  draft-worley-sipcore-b2bua-passthru-00
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

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:

       (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.

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] (Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” October 2008.) 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 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.

3.  Requirements

• REQ-1 - A SIP User Agent is able to direct a within-dialog request to reach the target URI of the remote UA.
• REQ-2 - A SIP User Agent is able to direct an out-of-dialog request to reach the target URI of the remote UA.
• 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] (Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” September 2004.) and Join[join] (Mahy, R. and D. Petrie, “The Session Initiation Protocol (SIP) "Join" Header,” October 2004.) headers of INVITE requests and the Target-Dialog[target‑dialog] (Sparks, R., Johnston, A., and D. Petrie, “Session Initiation Protocol (SIP) Call Control - Transfer,” June 2009.) header of REFER requests.

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.

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:

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, rather than the Replaces header.

5.  Security Considerations

There are no known security implications of these behaviors.

6.  Revision History

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

Initial version.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address