A while ago, in a post about how “manual audio routes” work behind the scenes, I mentioned I was planning to see if it was possible to set manual audio routes for endpoints other than the “local” endpoint for the call, by sending INFO messages manually to the audio/video MCU. In other words, can I join a conference from my UCMA application as a trusted participant, and then send manually constructed INFO messages to create a manual audio route between two other participants in the conference? Continue reading “Third-party manual audio routes: not possible” »
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” »
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” »