The Lync Server 2013 cumulative update back in July fixed a potentially serious issue with conference scheduling. The main symptom of the issue is long delays when scheduling many Lync conferences simultaneously – it can take around two minutes per conference, rather than a few seconds as you would expect. I wanted to write up a quick explanation here for anyone who runs into this issue when building UCMA applications. Continue reading “Fix for long delay when scheduling many conferences in UCMA” »
In the Lync client, if you are participating in a conference and someone starts recording, you get notified: a red dot appears near the bottom of the window, and a message pops up letting you know that recording has started. How do you get the same kind of notification in a UCMA application?
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 BackToBackCall class is staple of more complex UCMA applications, especially those that perform some kind of third-party call control (brokering or providing services to calls between other users). In a nutshell, the BackToBackCall class allows a UCMA-controlled endpoint to keep a handle to a call that is going on between two other endpoints, rather than between a single remote endpoint and the UCMA application. But there are several features of the BackToBackCall class that you may not be aware of, that can be helpful in certain situations. Continue reading “Advanced BackToBackCall features” »
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” »
There are a number of situations where it is necessary for a UCMA application to connect more than one call to a conference. One example that I’ve seen more than once is the situation where you want your application to play messages to a caller, but you also want to record both the messages and the caller’s response. The way to do this is to create two separate instances of AudioVideoCall, join both of them to the conference, and establish them. One of them can then play the messages, while the other can be hooked up to a Recorder object to record both sides of the conversation. Continue reading “Multiple calls to a conference from the same UCMA endpoint” »