Interoperation of "Application Server" B2BUAs with SIP Call Control

(Much of this section and the next section are taken from .) 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 for the users participating in the conversation. This leads to a generic call structure as shown in .

|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 single 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 terminating UA. The route of the initial INVITEs creating the dialog chain is typically as shown in .

| 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 terminating 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 conditions are 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, as shown in .

|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, as shown in .

|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 REFER 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 application 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 operate), this strategy maximizes the likelihood of achieving interoperation in practical SIP environments of this kind. Because no new protocol elements are introduced by this document, we cannot call these behaviors by name of a new protocol element. Instead, we call these behaviors the "B2BUA (or application server) passthru" behaviors, or simply the "passthru" behaviors. The behaviors described in this document are an expansion of the techniques described in section 4.2 of .

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, as shown in . 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 | | | Refer-To: X | | |--------------->| | | 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 first UA that is participating in a dialog to instruct a third UA to generate an INVITE/Replaces that effectively refers to the target URI and dialog identifiers of the remote UA of the dialog chain, despite that the first UA does not know these identifiers. With the passthru behaviors, this is implemented by requiring that an application server, when it receives an INVITE/Replaces that is targeted to a dialog that terminates 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. With one application server between UA1 and UA2, the consultative transfer example now operates as shown in .

| | | | | INVITE App2 | | | | Call-Id: D2 | | | |--------------->| | | | 200 | | | | Contact: C2 | | | |<---------------| | | 200 | | | | Contact: C1 | | | |<---------------| | | | | | | [Set up of dialog chain from UA1 to UA3 omitted.] | | | | [UA1 sends "REFER/Refer-To: C1&Replaces=D1" through the application server chain to UA3. UA3 sends "INVITE C1/Replaces: D1":] | | | | | | 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: C2 | | | |------------------------------->| | | | | ]]> If there are three application servers between UA1 and UA2 as in , if each application server implements the behavior described above, the consultative transfer example now operates as shown in .

| | | | | | |INVITE App2 | | | | | |Call-Id: D2 | | | | | |Contact: A1R| | | | | |----------->| | | | | | |INVITE App3 | | | | | |Call-Id: D3 | | | | | |Contact: A2R| | | | | |----------->| | | | | | |INVITE UA2 | | | | | |Call-Id: D4 | | | | | |Contact: A3R| | | | | |----------->| | | | | |200 | | | | | |Call-Id: D4 | | | | | |Contact: UA2| | | | | |<-----------| | | | |200 | | | | | |Call-Id: D3 | | | | | |Contact: A3L| | | | | |<-----------| | | | |200 | | | | | |Call-Id: D2 | | | | | |Contact: A2L| | | | | |<-----------| | | | |200 | | | | | |Call-Id: D1 | | | | | |Contact: A1L| | | | | |<-----------| | | | | | | | | | | [Resulting in a series of dialogs:] | | | | | | |Call-Id: D1 |Call-Id: D2 |Call-Id: D3 |Call-Id: D4 | | |UA1 A1L|A1R A2L|A2R A3L|A3R UA2| | |<---------->|<---------->|<---------->|<---------->| | | | | | | | [Set up of dialog chain from UA1 to UA3 omitted.] | | | | | | [UA1 sends "REFER/Refer-To: A1L&Replaces=D1" through the application server chain to UA3. UA3 sends "INVITE A1L/Replaces: D1":] | | | | | | | |INVITE A1L | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D1| | | | | |<--------------------------------------------------| | |INVITE A2L | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D2| | | | | |----------->| | | | | | |INVITE A3L | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D3| | | | | |----------->| | | | | | |INVITE UA2 | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D4| | | | | |----------->| | | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |<-----------| | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |<-----------| | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |<-----------| | | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |-------------------------------------------------->| | | | | | | [Dialog D5 is now established between UA3 and UA2.] | | | | | | | | | | |BYE UA2 | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |<-----------| | | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |----------->| | | | | | | ]]>

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.

The Endpoint-View header was defined to solve the same problems as the passthru behaviors. This section shows that these two techniques interoperate correctly, provided that a B2BUA with passthru behavior acts as an endpoint with regard to the Endpoint-View header, that is, does not pass its value through when forwarding a dialog. This is best demonstrated by an example. We modify by assuming that App1 and App2 implement Endpoint-View and App3 implements the passthru behaviors. This results in the behavior shown in . (Of course, this example requires that UA1, UA2, and UA3 implement Endpoint-View.)

;call-id=D1 | | | |----------->| | | | | | |INVITE App2 | | | | | |Call-Id: D2 | | | | | |Contact: A1R| | | | | |Endpoint-View: ;call-id=D1 | | | |----------->| | | | | | |INVITE App3 | | | | | |Call-Id: D3 | | | | | |Contact: A2R| | | | | |Endpoint-View: ;call-id:D3 | | | |----------->| | | | | | |INVITE UA2 | | | | | |Call-Id: D4 | | | | | |Contact: A3R| | | | | |Endpoint-View: | | | | | ;call-id:D3 | | | | |----------->| | | | | |200 | | | | | |Call-Id: D4 | | | | | |Contact: UA2| | | | | |Endpoint-View: | | | | | ;call-id:D4 | | | | |<-----------| | | | |200 | | | | | |Call-Id: D3 | | | | | |Contact: A3L| | | | | |Endpoint-View: ;call-id:D4 | | | |<-----------| | | | |200 | | | | | |Call-Id: D2 | | | | | |Contact: A2L| | | | | |Endpoint-View: ;call-id=D2 | | | |<-----------| | | | |200 | | | | | |Call-Id: D1 | | | | | |Contact: A1L| | | | | |Endpoint-View: ;call-id=D2 | | | |<-----------| | | | | | | | | | | [Resulting in a series of dialogs:] | | | | | | |Call-Id: D1 |Call-Id: D2 |Call-Id: D3 |Call-Id: D4 | | |UA1 A1L|A1R A2L|A2R A3L|A3R UA2| | |<---------->|<---------->|<---------->|<---------->| | |<--Endpoint-View: ;call-id=D1 | | | | Endpoint-View: ;call-id=D2 | | | | | -->| | | | | | |<--Endpoint-View: ;call-id:D3 | | | | Endpoint-View: ;call-id:D4 | | | | | -->| | | | | | | | [Set up of dialog chain from UA1 to UA3 omitted.] | | | | | | [Because UA1 received "Endpoint-View: ;call-id=D2" when establishing the dialog, it sends "REFER/Refer-To: A2L?Replaces=D2" through the server chain to UA3. UA3 sends "INVITE A2L/Replaces: D2":] | | | | | | | | |INVITE A2L | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D2| | | | | |<-------------------------------------| | | | | | | [Based on the passthru behaviors, App2 proxies this INVITE into "INVITE A3L/Replaces: D3", but because it received "Endpoint-View: ;call-id:D4" when establishing D3, it sends "INVITE UA2/Replaces:D4". Note that because it is proxying this INVITE, it does not add or modify any Endpoint-View header in this INVITE (which we do not show).] | | | | | | | | |INVITE UA2 | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |Replaces: D4| | | | | |------------------------>| | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |<------------------------| | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |------------------------------------->| | | | | | | [Dialog D5 is now established between UA3 and UA2.] | | | | | | | | | | |BYE UA2 | | | | | |Call-Id: D5 | | | | | |Contact: UA3| | | | | |<-----------| | | | | |200 | | | | | |Call-Id: D5 | | | | | |Contact: UA2| | | | | |----------->| | | | | | | ]]> In this way, one can mix-and-match application servers that use the two behavior patterns: application servers that implement Endpoint-View application servers that implement the passthru behaviors, and act as UAs with regard to Endpoint-View The result is that one can transition incrementally in either direction through the following sequence of system configurations, changing only one network element at a time: UAs may or may not support Endpoint-View; application servers all implement passthru behaviors (and may or may not support Endpoint-View) UAs all support Endpoint-View; application servers all implement passthru behaviors (acting as UAs regarding Endpoint-View) UAs all support Endpoint-View; application servers are a mixture of the two types UAs all support Endpoint-View; application servers all support Endpoint-View

There are no known security implications of these behaviors.

Add captions and figure numbers to figures. Add reference to . Add showing an INVITE-with-Replaces passing through three application servers. Add regarding interoperation of passthru with Endpoint-View.

Initial version.