Transferring an A/V call into a Lync conference

If you’ve been digging through the archives of this blog, you may remember that, although UCMA doesn’t allow audio/video calls to be escalated to conferences using the Conversation.BeginEscalateToConference method, there is a sneaky alternative way to accomplish the same thing using AudioVideoMcuSession.BeginTransfer. (Incidentally, this technique, which I wrote about for UCMA 2.0, still works in exactly the same way for UCMA 3.0). This is not the only interesting thing you can do with the AudioVideoMcuSession.BeginTransfer method, however.

First of all, let’s take a quick look at how this method works. Here’s a code example:

var avMcu =
    _conversation.ConferenceSession.AudioVideoMcuSession;

try
{
    avMcu.BeginTransfer(
        avCall, null,
        ar =>
        {
            try
            {
                avMcu.EndTransfer(ar);
            }
            catch (RealTimeException ex)
            {
                Console.WriteLine(ex);
            }
        },
        null);
}
catch (InvalidOperationException ex)
{
    Console.WriteLine(ex);
}

The effect of this code will be to take the call referenced in avCall and transfer it into the conference such that the remote party on avCall is now connected to the conference (technically speaking, to the audio/video MCU).

Now, the method is called BeginTransfer, but behind the scenes what UCMA is doing is not really a transfer. In SIP, a typical transfer is performed using a REFER message. My post on Lync transfers explains the whole process in detail. An A/V MCU transfer like this one, however, is actually executed as a call replacement. Here’s how it works, step by step.

First, the UCMA application (User A) sends a SIP INFO message to the conference focus, containing some XML in a format called C3P (Centralized Conference Control Protocol). This XML document provides the MCU’s SIP URI, and asks for the remote party (User B) on the “transferred” two-party call to be added to the conference. It also provides some information on that two-party call.

Next, the MCU sends a SIP INVITE message to User B. In the INVITE there is a Replaces header, which contains the call ID and the from and to tags from the call that is being replaced. (See my post on call replacement for details on how this works.)

User B sends an INVITE to the conference focus to property join the conference. The focus accepts the INVITE with a 200 response.

User B now accepts the INVITE from the MCU with a 200 OK.

User B disconnects the original two-party call with the UCMA application by sending a BYE message. User B is now joined to the conference.

The great thing here is that the experience for User B in the Lync client is quite seamless. There are no new windows popping up as in a regular transfer. It just looks as though the two-party call has suddenly become a conference. Likewise, for a PSTN user being “transferred” to a conference, there will be no ringing sounds. This makes the A/V MCU transfer feature handy for when a UCMA app needs to move a user into a conference without any action from the user’s end.

One important note to remember is that the new call that results from this process is between the A/V MCU and User B. So the UCMA application no longer has a reference to the resulting call, or any control over it. The original two-party call will go into a Terminated state because it has been replaced by the MCU call. If the UCMA app needs to retain control over the resulting call, you should use the BackToBackCall class.