Shortening the “answer delay” with early media

It’s common for a UCMA app, before answering an incoming audio call, to perform some setup steps: finding an agent to take the call, preparing media, whatever. These steps may be necessary if, for example, the call is being set up as a back-to-back call and they can’t be done after the call is already established. In other cases, the way the call is set up makes the actual process of accepting the call take some time. Unfortunately, this can lead to callers hearing multiple seconds of ringing (or, even worse, silence) before the call is fully established. It can also lead to “clipping” effects where the beginning of a message or someone’s greeting is cut off because the media flow isn’t quite established yet. A feature called “early media” allows your application to get around these limitations and eliminate most of that delay or clipping. Continue reading “Shortening the “answer delay” with early media” »

How to tell where a call is ringing in UCMA

Lately I’ve been spending a lot of time looking at “forking,” the process where a call (audio, IM, video, whatever) to a user is sent to all devices where that user is logged into Lync, and various ways to handle it in UCMA. A while back, I described how you can look at the SIP headers in the response when an outgoing call is answered to find out if, for example, a voicemail box answered the call. By looking at “provisional responses,” you can get details like this before the call is even answered, while it’s still “ringing” to the user’s various endpoints. Continue reading “How to tell where a call is ringing in UCMA” »

Getting endpoint policy info programmatically

I wanted to share an approach you can use to find out your endpoint’s capabilities and policy settings through UCMA code. To give you an example of where this can be useful, imagine you have an application that creates conferences or provides services to conferences, and in order to work it needs to be able to invite anonymous participants. If the endpoint has this capability turned off in meeting policy, the application will fail or exhibit strange behaviour. You might already have exception handling to deal with the situations where the application tries to do something that’s prohibited by policy, but by that time your application is already running. By querying policy information, you can confirm that the necessary settings are there when your application starts and avoid unpleasant surprises later. Continue reading “Getting endpoint policy info programmatically” »

Recording of UCMA 101 session

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:

http://channel9.msdn.com/posts/Lync-Developer-Roundtable-UCMA-101

IP phones and multiple participant endpoints

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” »

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” »

Getting a list of a user’s conferences

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” »

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?” »

Call replacement extension method for UCMA

Recently I did some experimenting with call replacement, and I came up with a set of extension methods that you can use to try out the INVITE with Replaces technique. To start, I should probably explain what it does. There is a BeginReplace extension method for AudioVideoCall, which allows you to take over the spot in a two-party call that belongs to your application. Continue reading “Call replacement extension method for UCMA” »

What happened to my call?

You may already be aware that you can use the Call.StateChanged event to find out when a call that is handled by your UCMA application becomes established, or terminates, or goes through some other state change. Your UCMA applications probably have event handlers very much like the following:

void OnCallStateChanged(object sender, CallStateChangedEventArgs e)
{
    _logger.Log("Call state changed from {0} to {1}.", e.PreviousState, e.State);
}

Continue reading “What happened to my call?” »