Conference deactivation and UCMA trusted participants

UCMA allows you to join a Lync conference as a so-called “trusted participant,” which has several interesting effects. First, it hides the participant in the conference roster, so that participants can’t see that your application is joined to the conference. Second, it allows your application to perform a variety of privileged operations like changing how audio is routed within the conference. If your application keeps conferences around for a while with trusted participants connected, you may run into a situation where conferences get unexpectedly deactivated by Lync Server. This can lead to confusing state changes, or even cause external participants like PSTN callers to be ejected. Continue reading “Conference deactivation and UCMA trusted participants” »

The many faces of remote participants

One common source of confusion in the conferencing APIs in UCMA has to do with getting information on the conference participants. If you look at the various classes that come into play when you are dealing with a conference, there are not one, not two, but FOUR different ways (methods or properties) to get a list of remote participants. See if you can think of them before reading on.

Continue reading “The many faces of remote participants” »

How do manual audio routes work?

It’s been a while since I last wrote about manual audio routes, and I thought it might be helpful to describe how they work from a SIP signaling perspective.

There are essentially two media handling modes that participants in an audio conference can be in. The first is the default, where audio from each participant is sent to every other participant. The second is a sort of “create your own audio routing” mode. When you switch a participant into this mode, using the BeginRemoveFromDefaultRouting method on AudioVideoMcuSession, two things happen:

1. Audio from the affected participant is no longer sent to other participants, and
2. Audio from other participants is no longer sent to the affected participant.

At this point, you can wire up your own custom audio routes to and from the participant, using the methods on the AudioVideoMcuRouting class. Continue reading “How do manual audio routes work?” »

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. Continue reading “Transferring an A/V call into a Lync conference” »

Conference invitations vs. MCU dial-outs

At times I find it confusing to how an MCU dial-out (as triggered by methods like AudioVideoMcuSession.BeginDialOut in UCMA) differs from a conference invitation (ConferenceInvitation class in UCMA). In my previous post I described what happens behind the scenes when a conference invitation is sent to a Lync user, so I thought I would take this post to explain the very different process that occurs during an MCU dial-out. UCMA does a very good job of putting a layer of abstraction over the extensive SIP signaling that goes on at a lower level during both of these operations, which is a good thing overall, since it frees up developers to focus on solving business problems using the API. However, at times it is useful to know things like the underlying difference between a conference invitation and an MCU dial-out in order to solve complex technical questions. Continue reading “Conference invitations vs. MCU dial-outs” »

Lync conference invitations in SIP terms

From the Lync client, the process of inviting someone to a conference, or of being invited to a conference, seems simple and straightforward. The recipient clicks on the incoming call popup to accept the invitation, a Lync conversation window opens up, and he or she is connected to the conference. If you take a look at the SIP messaging that is going on during this process, though, it is quite a bit more involved than you might expect. Inviting a new participant to a typical audio conference involves three separate SIP dialogs. Continue reading “Lync conference invitations in SIP terms” »

A/V MCU encryption fix in Lync CU4

The latest cumulative update for Lync was recently released, and one of the fixes deals with an interesting problem to do with audio conferences. I thought I would take the opportunity to discuss a few things about how media works in a Lync audio conference, and the implications of this change in the update.

The fix that I’m referring to (details here) resolves a problem where one-way audio could occur between a client and an audio/video MCU. For background, the MCU, or multipoint control unit, is the Lync component that mixes media for the conference and distributes it to the participants. What was happening in certain cases was that an audio conference participant would be audible in the conference, but could not hear other participants.

It turns out that the reason for this was an issue with media encryption in the MCU. Continue reading “A/V MCU encryption fix in Lync CU4” »