Aggregating the media capabilities of SIP user agents using third-party call control techniques

This document is concerned with the concept of SIP user agent "aggregation", that is, where two or more user agents provide media interfaces for media sessions that are controlled by one SIP dialog. This facility is also called "disaggregated media" or "device pairing". The approach to UA aggregation that is explored in this document is one where a single "primary" UA is the SIP endpoint of the dialog to the far-end UA and it manages that dialog and the interactions with the other, "secondary" UAs that provide additional media interfaces. The primary UA interacts with the secondary UAs using ordinary SIP third-party call control (3PCC) operations, and so the secondary UAs need to implement no facilities beyond ordinary SIP requirements. Similarly, the far-end UA only sees an ordinary SIP dialog with the primary UA, and so needs to implement no facilities beyond ordinary SIP requirements.

In various situations, the operations described in this document provide effects that vary enough from the user's point of view that they can be considered different modes of operation: The baseline model of operation is that these operations are implemented by a SIP UA that can be used by the user as an ordinary UA, allowing it to utilize other UAs as media interfaces. The primary UA may not provide any media interfaces of its own. This turns the UA into a B2BUA that manages the UA aggregation, controlled by an interface it presents to the user. The primary B2BUA may have no direct interface to the user, but instead be "in the network", and be controlled by information communicated to it by secondary UA(s) or other interfaces under direction of the user. E.g. the B2BUA could be controlled by eavesdropping the media streams for DTMF signals, or by RPC requests sent by a secondary UA. In regard to SIP signaling, all of these modes of operation are included in the baseline model, and so are not discussed separately. However, for convenience of exposition, we will assume that the primary UA has no media interfaces of its own. The case where the primary UA has media interfaces is modeled by separating the media interfaces into a secondary UA that is co-located with the primary UA, and which is always controlled by the primary UA through 3PCC SIP. In most situations, the interactions between the primary and each secondary are identical, and so illustrations will be limited to one secondary UA.

We first illustrate how the various SIP signaling operations are carried out.

The first operation we consider is originating a call, aggregating the media capabilities of the primary and secondary UAs. In order to originate a call, the primary UA needs to obtain an SDP offer from the secondary. One way to do this is to send an offer-less INVITE to the secondary. This technique has the disadvantage that the initial INVITE to the secondary must be answered on the secondary (unless the secondary is somehow directed to automatically answer the call), and if the call to the remote UA fails, the call to the secondary remains.

| | | | INVITE | | | SDP offer | | |------------------>| | | 200 OK | | | SDP answer | | |<------------------| | | ACK | | |------------------>| | ACK | | | SDP answer | | |<------------------| | | | | | | | ]]> A second technique is to induce the secondary to send an INVITE to the primary. This can be done by sending an out-of-dialog REFER.

| | | | INVITE | | | SDP offer | | |------------------>| | | 200 OK | | | SDP answer | | |<------------------| | | ACK | | |------------------>| | 200 OK | | | SDP answer | | |<------------------| | | ACK | | |------------------>| | | | | | | | ]]>

This call flow is for answering an incoming INVITE that has SDP, as is usual.

| | | ACK | | |<------------------| | | | 200 OK | | | SDP answer | | |------------------>| | | ACK | | |<------------------| | | | | | | ]]> This call flow is for an incoming INVITE without SDP.

| | | | 200 OK | | | SDP offer | | |------------------>| | | ACK | | | SDP answer | | |<------------------| | ACK | | | SDP answer | | |<------------------| | | | | | | | ]]>

Terminating a call is straightforward, as it only requires terminating the dialogs with the remote and the secondary

| | | 200 OK | | |<------------------| | BYE | | |<------------------| | | 200 OK | | |------------------>| | | | | | | | ]]>

| | BYE | | |<------------------| | | 200 OK | | |------------------>| | | | | | | | ]]>

This call flow is for a re-INVITE (an in-dialog INVITE) with SDP received from the remote.

| | | ACK | | |<------------------| | | | 200 OK | | | SDP answer | | |------------------>| | | ACK | | |<------------------| | | | | | | ]]> This call flow is for a re-INVITE (an in-dialog INVITE) without SDP received from the remote.

| | | | 200 OK | | | SDP offer | | |------------------>| | | ACK | | | SDP answer | | |<------------------| | ACK | | | SDP answer | | |<------------------| | | | | | | | ]]>

This call flow is for a re-INVITE (an in-dialog INVITE) generated locally that contains updated SDP. In the illustration, the re-INVITE is initiated by secondary S1 by sending a re-INVITE to the primary. (E.g., because it has gone on-hold). Another secondary, S2, must be prompted to start an offer/answer cycle. This pattern can be used for a re-INVITE initiated by the primary by considering all secondaries in the same role as S2 in the illustration.

| | | | re-INVITE | | | |<------------------| | | | 200 OK | | | | SDP offer | | | |------------------>| | | | | re-INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | 200 OK | | | | SDP answer | | | |<--------------------------------------| | | ACK | | | |-------------------------------------->| | | | ACK | | | | SDP answer | | | |<------------------| | | | | | | | | | ]]> This call flow is for a re-INVITE (an in-dialog INVITE) generated locally that contains no SDP. In the illustration, the re-INVITE is initiated by secondary S1 by sending a re-INVITE to the primary. (E.g., because it has gone on-hold). Another secondary, S2, must be prompted to start an offer/answer cycle. This pattern can be used for a re-INVITE initiated by the primary by considering all secondaries in the same role as S2 in the illustration.

| | | | | re-INVITE | | | |------------------>| | | | 200 OK | | | | SDP offer | | | |<------------------| | 200 OK | | | | SDP offer | | | |<--------------------------------------| | | ACK | | | | SDP answer | | | |-------------------------------------->| | | | re-INVITE | | | | SDP offer | | | |<------------------| | | | 200 OK | | | | SDP answer | | | |------------------>| | | | ACK | | | |<------------------| | | | | ACK | | | | SDP answer | | | |------------------>| | | | | | | | | ]]>

This call flow is for an INVITE with a Replaces header that is received from the remote UA. Generally, the INVITE is handled as would an INVITE without a Replaces header, whether or not the INVITE contains SDP. But as the INVITE is passed on to the secondary UA, the Replaces header value is changed to name the dialog between the primary and secondary that matches the dialog between the primary and the remote UA that is named in the original Replaces header.

| | | | | INVITE | | | | Call-Id: 1-R | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | Call-Id: 1-R | | | | SDP answer | | | |<------------------| | | | ACK | | | | Call-Id: 1-R | | | |------------------>| | | ACK | | | | Call-Id: 1-S | | | | SDP answer | | | |<------------------| | | | Call 1 established | | |...........................................................| | | INVITE | | | | Call-Id: 2-R | | | | Replaces: 1-R | | | | SDP offer | | | |<--------------------------------------| | INVITE | | | | Call-Id: 2-S | | | | Replaces: 1-S | | | | SDP offer | | | |<------------------| | | | 200 OK | | | | Call-Id: 2-S | | | | SDP answer | | | |------------------>| | | | ACK | | | | Call-Id: 2-S | | | |<------------------| | | | BYE | | | | Call-Id: 1-S | | | |------------------>| | | | 200 OK | | | | Call-Id: 1-S | | | |<------------------| | | | | 200 OK | | | | Call-Id: 2-R | | | | SDP answer | | | |-------------------------------------->| | | ACK | | | | Call-Id: 2-R | | | |<--------------------------------------| | | BYE | | | | Call-Id: 1-R | | | |------------------>| | | | 200 OK | | | | Call-Id: 1-R | | | |<------------------| | | | | | | | | | ]]>

This call flow is for receiving a REFER within the dialog from the remote UA, or an out-of-dialog REFER whose Target-Dialog header specifies the dialog with the remote UA. The REFER is duplicated and sent to the secondary UA, with the Refer-To URI changed to that of the primary UA. The resulting INVITE is generated in much the same way as for originating a call.

| | | | INVITE | | | Call-Id: 1-R | | | SDP offer | | |------------------>| | | 200 OK | | | Call-Id: 1-R | | | SDP answer | | |<------------------| | | ACK | | | Call-Id: 1-R | | |------------------>| | ACK | | | Call-Id: 1-S | | | SDP answer | | |<------------------| | | Call 1 established | |.......................................| | | REFER | | | Call-Id: 1-R | | | Refer-To: R2 | | |<------------------| | REFER | | | Call-Id: 1-S | | | Refer-To: P | | |<------------------| | | INVITE | | | Call-Id: 2-S | | | SDP offer | | |------------------>| | | | INVITE | | | Call-Id: 2-R | | | SDP offer | | |------------------>| | | 200 OK | | | Call-Id: 2-R | | | SDP answer | | |<------------------| | | ACK | | | Call-Id: 2-R | | |------------------>| | 200 OK | | | Call-Id: 2-S | | | SDP answer | | |<------------------| | | ACK | | | Call-Id: 2-S | | |------------------>| | | BYE | | | Call-Id: 1-S | | |------------------>| | | 200 OK | | | Call-Id: 1-S | | |<------------------| | | | BYE | | | Call-Id: 1-P | | |------------------>| | | 200 OK | | | Call-Id: 1-P | | |<------------------| | | | | | | ]]>

When the primary UA wants to incorporate a secondary UA into the call, it can initiate a re-INVITE cycle either with an SDP offer from its end, or an offer from the remote end. The first call flow generates the SDP offer at the primary's end.

| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | Call established using S1 | | |...........................................................| | re-INVITE | | | |<--------------------------------------| | | 200 OK | | | | SDP offer | | | |-------------------------------------->| | | | INVITE | | | |<------------------| | | | 200 OK | | | | SDP offer | | | |------------------>| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | | ACK | | | | SDP answer | | | |<------------------| | | | | | | | | | ]]> The second call flow generates the SDP offer at the remote end.

| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | Call established using S1 | | |...........................................................| | | | re-INVITE | | | |------------------>| | | | 200 OK | | | | SDP offer | | | |<------------------| | re-INVITE | | | | SDP offer | | | |<--------------------------------------| | | 200 OK | | | | SDP answer | | | |-------------------------------------->| | | | INVITE | | | | SDP offer | | | |<------------------| | | | 200 OK | | | | SDP answer | | | |------------------>| | | | | ACK | | | | SDP answer | | | |------------------>| | ACK | | | |<--------------------------------------| | | | ACK | | | |<------------------| | | | | | | | | | ]]>

When the primary UA wants to remove a secondary UA from the call, it needs to release the dialog with the secondary and perform a re-INVITE cycle to rearrange the media streams. The first call flow generates the SDP offer at the primary's end.

| | | | INVITE | | | |<------------------| | | | 200 OK | | | | SDP offer | | | |------------------>| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | | ACK | | | | SDP answer | | | |<------------------| | | Call established using S1 and S2 | | |...........................................................| | re-INVITE | | | |<--------------------------------------| | | 200 OK | | | | SDP offer | | | |-------------------------------------->| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | | BYE | | | |<------------------| | | | 200 OK | | | |------------------>| | | Call established using S1 | | |...........................................................| | | | | | | | | ]]> The second call flow generates the SDP offer at the remote end.

| | | | INVITE | | | |<------------------| | | | 200 OK | | | | SDP offer | | | |------------------>| | | | | INVITE | | | | SDP offer | | | |------------------>| | | | 200 OK | | | | SDP answer | | | |<------------------| | | | ACK | | | |------------------>| | ACK | | | | SDP answer | | | |<--------------------------------------| | | | ACK | | | | SDP answer | | | |<------------------| | | Call established using S1 and S2 | | |...........................................................| | | | re-INVITE | | | |------------------>| | | | 200 OK | | | | SDP offer | | | |<------------------| | re-INVITE | | | | SDP offer | | | |<--------------------------------------| | | 200 OK | | | | SDP answer | | | |-------------------------------------->| | | | | ACK | | | | SDP answer | | | |------------------>| | ACK | | | |<--------------------------------------| | | | BYE | | | |<------------------| | | | 200 OK | | | |------------------>| | | Call established using S1 | | |...........................................................| | | | | | | | | ]]>

Question: How do we handle glare situations? Various operations can be initiated various elements simultaneously, and some operations can fail. We need recovery strategies for these situations. At what point has the primary UA committed to complete a sequence of operations? Upon sending an INVITE, or upon sending a response to an INVITE. Let's suppose we get a remote re-INVITE, but during the processing a secondary sends a re-INVITE. The primary can reject the secondary's re-INVITE with 491. If the secondary accepts the primary's re-INVITE, the sequence can continue. But the secondary can reject the primary's re-INVITE with 491. How should the primary continue? One alternative is to reject the remote's re-INVITE with 491. Another approach would be to wait (based on RFC 3261 section 14.1) and send its re-INVITE again.

| | | 491 Request Pending | |<------------------| | | ACK | | |------------------>| | | 491 Request Pending | |------------------>| | | ACK | | |<------------------| | | Alternative 1: | | |.......................................| | | 491 Request Pending | |------------------>| | | ACK | | |<------------------| | Alternative 2: | | |.......................................| | re-INVITE | | | SDP offer | | |<------------------| | | 200 OK | | | SDP answer | | |------------------>| | | ACK | | |<------------------| | | | 200 OK | | | SDP answer | | |------------------>| | | ACK | | |<------------------| | | | | | | ]]> This leads to an alternative approach: Instead of worrying about glare specifically, just consider that any request sent to any UA may receive a failure response for unknown reasons. Our sequencing must be able to recover from this. In most cases, the goal is to abort the operation. The exceptions are (1) attempting to tear down the entire call structure, and (2) releasing a secondary, both of which should succeed (attain the desired state) even if the other UAs are non-responsive.

| | | ACK | | |<------------------| | | | 400 Request Failed | |------------------>| | | ACK | | |<------------------| | | | | | | ]]> Although this case doesn't have the problem that the primary commits to a transaction before it obtains commitment from all the other UAs. Here is an example with a worse failure. The remote sends a re-INVITE, causing the primary to send re-INVITEs to the secondaries. The first secondary completes the re-INVITE sequence, but the second secondary fails. At this point, there is no consistent set of SDP states that can be used, as Secondary 1 has renegotiated its SDP but Secondary 2 has not. (Although it is possible that Secondary 1's answer SDP is the same as it provided previously, in which case the primary could send an error response to the remote and be in a consistent state.)

| | | ACK | | | |<--------------------------------------| | | | re-INVITE | | | | SDP offer | | | |<------------------| | | | 4xx Ugh | | | |------------------>| | | | ACK | | | |<------------------| | | | | | | | | | ]]> One possible solution is for the primary to wait a short time and then initiate a re-INVITE sequence. If that sequence completes successfully, the SDP state will be correct again.

| | Wait | | | |...........................................................| | | | re-INVITE | | | |------------------>| | | | 200 OK | | | | SDP offer | | | |<------------------| | re-INVITE | | | | SDP offer | | | |<--------------------------------------| | | 200 OK | | | | SDP answer | | | |-------------------------------------->| | | ACK | | | |<--------------------------------------| | | | re-INVITE | | | | SDP offer | | | |<------------------| | | | 200 OK | | | | SDP answer | | | |------------------>| | | | ACK | | | |<------------------| | | | | ACK | | | | SDP answer | | | |------------------>| | | | | | | | | ]]> A more drastic solution is for the primary to replace all the existing dialogs with new ones, using INVITEs with the Replaces header. In principle, this should have the same effect as doing re-INVITEs, but in practice, it seems more likely to not correctly carry forward into the new dialogs any state the UAs are maintaining about the old dialogs. On the other hand, it's more likely to clear any erroneous state the UAs are maintaining about the old dialogs. A simplified diagram of this approach looks like the previous diagram:

| | Wait | | | |.......................................| | | | | INVITE | | | | Replaces | | | |------------------>| | | | 200 OK | | | | SDP offer | | | |<------------------| | re-INVITE | | | | Replaces | | | | SDP offer | | | |<--------------------------------------| | | 200 OK | | | | SDP answer | | | |-------------------------------------->| | | ACK | | | |<--------------------------------------| | | | re-INVITE | | | | Replaces | | | | SDP offer | | | |<------------------| | | | 200 OK | | | | SDP answer | | | |------------------>| | | | ACK | | | |<------------------| | | | | ACK | | | | SDP answer | | | |------------------>| | | | | | | | | ]]> With any of these approaches, we should probably use the SDP mapping that was in effect before the failure to guide the correlation of the media streams during the SDP negotiation to minimize disruptions in the user experience. In any case, we need a robust strategy to handle the various failure situations.

To a considerable extent, SDP processing is decoupled from SIP signaling. The fundamental SDP processing operations are (1) receiving SDP from the remote UA and from it generating SDP for each secondary, and (2) receiving SDP from each secondary and assembling them into SDP for the remote UA. Each offer/answer exchange which passes through the primary contains one of each of these operations. (Question: Can we avoid involving a particular secondary in an offer/answer exchange, just reusing its last offer? No: The answer might be different than previously, and there is no way to present the answer to the secondary. Since it's an answer, we can't present it as an offer to the secondary, and if we prompt the secondary for a new offer, it might be different from and incompatible with the "last offer" that we presented to get the answer.) SDP assembly/disassembly is driven by a mapping which specifies which media streams to/from the secondaries are connected to which media streams to/from the remote. The handling of offers and answers and the manipulation of the mapping is constrained by the offer-answer model: The mapping is separate for each aggregation group (which encompasses a dialog to the remote, and the group of dialogs to the secondaries for that dialog). The long-term identity of each stream to the remote is its m= line sequence number. The long-term identity of each stream to a secondary is the secondary UA identity and its m= line sequence number. Each secondary stream can be connected to only one remote stream, and vice-versa. But streams of either type can be in a non-connected state. When a new stream appears in an incoming offer, it must be connected to a new stream in an outgoing offer, or else left disconnected. New streams cannot appear in an incoming answer, as answers are not allowed to add streams relative to the corresponding offer. When processing an incoming offer stream, it can be disconnected from the stream that it was connected to, and connected to a new stream in the outgoing offer. The processing of answers uses the mapping that was established when processing the corresponding offers. (Question: In abstract, we assume that if a UA that supports, e.g., video, and it receives SDP containing multiple video streams, but all but one of them has been marked rejected (port = 0), the UA will identify the non-rejected video stream and connect its video resources to that stream. But this sort of operation is not, strictly speaking, specified and has almost never been done in the past, so UAs may not support it as they should. If they don't, how do we have to re-architect aggregation?) The atomic processing problem here is that when processing a stream in an incoming offer, we must decide which stream in which outgoing offer it is to be connected to, if any. The input information to this decision is whether the stream is marked rejected in the offer, the stream, if any, that it is already connected to, the media type of the stream, the user-prescribed prioritization of the UAs on the outgoing side for receiving media of this type, whether outgoing-side UAs are already receiving a stream of this type, and thus presumed not to be capable of handling further streams of this type. (Question: However, the prioritization of secondaries may depend on knowledge of what media the UA supports. How do we determine that?)

In this example of SDP processing, a call is initiated and later another secondary UA is seized and then released. After each operation, the state of the SDP mapping is shown: Each stream is represented by a line of text, showing the connected media streams and the media type the stream carries. Streams of the remote UA are named R.1, R.2, etc. Streams of secondary UA 1 are name S1.1, S1.2, etc., and similarly for other secondary UAs. Streams that are not connected are shown as connected to "x".

This example continues the previous example. S2 is seized again, and R's video stream (R.2) is directed to it. Here we are assuming that streams can be "reused", that is, connected to another stream after it has been unconnected. This violates the non-reuse of codec number rules, but probably works in practice.

We know we can implement this if R generates the offer. Can we implement it if S2 generates the offer? This is a version of the payload-type-number problem in draft-worley-service-example. In this case, R.2 hasn't seen any remote SDP yet, so no payload numbers have been sent to R.2. (That isn't strictly correct: R.2 has seen the rejection response in the first offer/answer exchange, but it appears that the pro-forma format number in that m= line is ignored. But in general, R.2 may have SDP history. Should we care about previous use of payload numbers? We probably don't have to in practice. But I think we could avoid doing so even in theory by connecting S2.2 to a new stream, R.3:

But how likely is it that R.3 will be handled correctly? That is, given that video stream R.2 was rejected, will R accept the offered R.3? I expect many UAs to not sort through many streams to find the one audio and one video stream that are not rejected.

Success and stablity in mapping would seem to rest on having complete knowledge of the media facilities provided by each UA. In the case of a secondary, this suggests that one get an offer from it first, so as to know what media types (and how many streams) it is willing to process. This can be done straightforwardly in most situations, but it's hard when answering a call that comes with an offer. At that point, we don't know what the secondaries have to offer. One possibility is sending an OPTIONS request to get a sample SDP offer. Another is to just remember the secondary device's capabilities from previous usage. A third is to use either REFER or offer-less INVITE to force the secondary to provide an offer (and then reject or release the resulting dialog). Or perhaps an OPTIONS can be used as a query.

There is further ugliness if the UAs use ICE or require other negotiation. Generally, negotiations assume a number of offer/answer cycles between the endpoints. But if there are secondaries, the various endpoints will generate re-INVITEs/UPDATEs out of sync with each other.

In this section we consider the situation where the primary UA does not have a user interface and instead is mostly controlled by operations initiated by one of its secondary UAs. This situation obtains especially when the primary is a B2BUA "in the network". We will designate the controlling UA "Secondary 1". This is made more difficult by assuming that Secondary 1 does not have any facilities specifically for controlling the aggregating primary.

In this case, primary obtains an offer from the secondary, and must solicit offers from the other secondaries.

Secondary 1 executes a blind transfer by sending an in-dialog REFER. The primary must pass the REFER through to the remote UA. The remote UA executes the REFER. Eventually, either the remote UA or Secondary 1 terminates the aggregated call.

| | | | | NOTIFY | | | |<------------------| | NOTIFY | | | |<--------------------------------------| | | 200 OK | | | |-------------------------------------->| | | | | 200 OK | | | |------------------>| | | | NOTIFY | | | |<------------------| | NOTIFY | | | |<--------------------------------------| | | 200 OK | | | |-------------------------------------->| | | | | 200 OK | | | |------------------>| | Call is released by R | | |...........................................................| | | | BYE | | | |<------------------| | | | 200 OK | | | |------------------>| | BYE | | | |<--------------------------------------| | | 200 OK | | | |-------------------------------------->| | | | BYE | | | |<------------------| | | | 200 OK | | | |------------------>| | | | | | | | | | ]]> Alternatively, Secondary 1 can release the call:

| | | | | 200 OK | | | |------------------>| | Call is released by S1 | | |...........................................................| | BYE | | | |-------------------------------------->| | | 200 OK | | | |<--------------------------------------| | | | | BYE | | | |------------------>| | | | 200 OK | | | |<------------------| | | BYE | | | |<------------------| | | | 200 OK | | | |------------------>| | | | | | | | | | ]]>

Secondary 1 executes a consultative transfer by creating a second call to R2 and then sending an in-dialog REFER to R1 containing a Refer-To URI that has a Replaces header.

| | | | | | REFER | | | | | Call-Id: 1-R1 | | | | | Refer-To: R2?Replaces=2-R2 | | | |------------------>| | | | | 200 OK | | | | |<------------------| | | 200 OK | | | | |<--------------------------------------| | | | | | NOTIFY | | | | |<------------------| | | NOTIFY | | | | |<--------------------------------------| | | | 200 OK | | | | |-------------------------------------->| | | | | | 200 OK | | | | |------------------>| | | | | | INVITE | | | | | Call-Id: 3 | | | | | Replaces: 2-R2 | | | | |------------------>| | | | | 200 OK | | | | |<------------------| | | | NOTIFY | | | | |<------------------| | | NOTIFY | | | | |<--------------------------------------| | | | 200 OK | | | | |-------------------------------------->| | | | | | 200 OK | | | | |------------------>| | | Call to R1 is released by R1 | | | |...............................................................................| | Call to R2 is released by R2 | | | |...............................................................................| | | | | | | | | | | ]]>

It may become necessary to replace the primary with a new primary without interrupting the call. This will generally require establishing new dialogs with the remote UA and with the secondaries. Because of this, the new primary will have to organize the SDP mapping itself (as the ordering an significance of the m= lines may be different in the new dialogs compared to the old dialogs). Since the SDP mapping does not need to be transferred to the new primary, the information that needs to be transferred is relatively small, being limited to the dialog identifiers of the dialogs with the remote and the secondaries, so that the new primary can send INVITE-with-Replaces to them. One way to arrange this is to have the old primary send a REFER to the new primary, carrying a Refer-To header with a Replaces value, directing the new primary to establish a dialog with the remote UA. An additional header, "Secondaries", carries the contact URIs of the secondaries with Replaces values containing the dialog identifiers of the dialogs with the secondaries. In order to allow the old primary to test a putative new primary for its support of the aggregation-transfer feature, a "secondaries" option-tag is used:

| | | | |INVITE | | | |Call-Id: 1-R | | | |SDP offer | | | |-------------------------------------->| | |200 OK | | | |Call-Id: 1-R | | | |SDP answer | | | |<--------------------------------------| | |ACK | | | |Call-Id: 1-R | | | |-------------------------------------->| |ACK | | | |Call-Id: 1-S | | | |SDP answer | | | |<------------------| | | |Call established by old primary | | |...........................................................| | |REFER sip:New-primary | | |Secondaries: S?Replaces=1-S... | | |Require: secondaries | | |------------------>| | | |200 OK | | | |<------------------| | |INVITE | | | |Call-Id: 2-S | | | |Replaces: 1-S | | | |<--------------------------------------| | |200 OK | | | |Call-Id: 2-S | | | |SDP offer | | | |-------------------------------------->| | |BYE | | | |Call-Id: 1-S | | | |------------------>| | | |200 OK | | | |Call-Id: 1-S | | | |<------------------| | | | | |INVITE | | | |Call-Id: 2-R | | | |Replaces: 1-R | | | |SDP offer | | | |------------------>| | | |200 OK | | | |Call-Id: 2-R | | | |SDP answer | | | |<------------------| | | |ACK | | | |Call-Id: 2-R | | | |------------------>| | |BYE | | | |Call-Id: 1-R | | | |<--------------------------------------| | |200 OK | | | |Call-Id: 1-R | | | |-------------------------------------->| |ACK | | | |Call-Id: 2-S | | | |SDP answer | | | |<--------------------------------------| | |Call established by new primary | | |...........................................................| | | | | | | | | ]]> Note that if the old primary is participating in the call as a media interface (and wishes to continue doing so), it must provide in the Secondaries header a contact URI and dialog identifiers by which the new primary can access the interface. Similarly, if the new primary may have been participating as a secondary, it must be prepared to receive its own contact URI in the Secondaries header.

If the primary UA needs to authenticate itself to the remote UA or to intermediate proxies, it needs to possess the credentials to do so. This could be problematic if the primary UA does not really possess a SIP user name of its own, but is representing a "leader" secondary UA. The primary UA could be given access to the credentials of all the leader secondaries that it is working for. It might limit its use of these credentials based on the user which the leader secondary authenticates itself as. Alternatively, the primary UA could function as a quasi-proxy, passing requests and responses between the leader secondary and the remote. This allows the leader UA to authenticate itself to the remote.

Initial version.