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” »
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.
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:
- Audio from the affected participant is no longer sent to other participants, and
- 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?” »
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” »
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” »