For anyone who wanted to attend but couldn’t, the recording from my Lync Developer Roundtable session (“UCMA 101”) from March has been posted on the Channel 9 site:
As a sort of follow-up to my post last week about remote participants and where they hide in the UCMA classes, I wanted to call out one case where the difference between the ConversationParticipant and ParticipantEndpoint classes is very important.
There are a number of IP phones that have been optimized for Lync, and some of them can be tethered with a PC via a USB cable for added capabilities. Even when tethered to a PC with the Lync client running, though, these phones function as separate Lync endpoints. In other words, the user who has the phone is actually signed in to Lync from two network locations: the Lync client on the PC, and Lync Phone Edition on the phone. If you pick up a call on one of these phones, the SIP response comes from the phone itself, not from the PC, and the audio media is sent to and from the phone. Continue reading “IP phones and multiple participant endpoints” »
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.
I wanted to share an approach for getting details on an individual user’s conferences that I think many people may not be aware of. You may know that you can have a UCMA application schedule a conference programmatically through the ConferenceServices object, which you can access via a property on your UserEndpoint or ApplicationEndpoint. In my experience, the ConferenceServices class is used almost exclusively for scheduling conferences, and you may not be aware that you can also use it to find the URIs or IDs of conferences that a user has created. Continue reading “Getting a list of a user’s conferences” »
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?” »