Interoperation of "Application Server" B2BUAs with SIP Call Control

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:

|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:

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

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. UA1 has established a dialog chain with UA2. After putting that dialog on hold, UA1 establishes a dialog chain with UA3:

|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:

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

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 and Join headers of INVITE requests and the Target-Dialog header of REFER requests.

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.

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

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

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: determine that the Replaces header describes a dialog D-IN terminating at that target URI (and respond 481 if it does not), determine the dialog D-OUT that is the "other side" of the dialog chain containing D-IN at this application server, proxy the INVITE/Replaces setting the request-URI to the remote target of D-OUT 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:

| | | | | 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 | | | |------------------------------->| | | | | ]]>

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

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.

There are no known security implications of these behaviors.

Initial version.