Posted: March 20th, 2012 | Author: Michael | Filed under: UCMA 3.0 | No Comments »
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?” »
Posted: March 12th, 2012 | Author: Michael | Filed under: Lync Development, UCMA 3.0 | 1 Comment »
For anyone who is just starting out with UCMA development, I’m doing a UCMA 101 session for the Lync Developer Roundtable series. Click on the link for the online meeting details. I’ll be talking about UCMA, what it’s good for, and some of the basics of UCMA development.
Posted: March 2nd, 2012 | Author: Michael | Filed under: UCMA 3.0 | Tags: routing | 6 Comments »
One of the cool things about Lync that people often take for granted is that you can sign in from multiple computers (or devices), and any call that is sent to you will ring at all of those various locations. There’s quite a bit of complex routing logic that goes into this, but it mostly takes place under the covers, and even when you’re developing a UCMA application, you generally don’t need to worry about it. If you create a new AudioVideoCall object and call AudioVideoCall.BeginEstablish with a SIP URI, Lync automatically “forks” that call to all of the registered endpoints for that user. Basically when the call hits the Lync Front End Server, the Front End Server sends a branch to each of the endpoints where that user is signed in. The first one to answer gets to take the call.
While it’s very courteous of Lync Server to do all of this stuff on its own without bothering us, the branching behaviour can sometimes get in the way. You might want to send an IM or a call to a user at one specific location. Maybe you want a call to go only to the user’s IP desk phone, but not to the Lync client on the PC. What do you do in a case like this? Continue reading “Sending a call to a specific endpoint in UCMA” »
Posted: February 22nd, 2012 | Author: Michael | Filed under: UCMA 2.0, UCMA 3.0 | Tags: Conversation | No Comments »
To make it possible for developers to extend the functionality of Lync without having to deal with the nitty-gritty details of Session Initiation Protocol (a.k.a. SIP), UCMA introduces a lot of abstractions. One of the abstractions that pops up most frequently is the Conversation class. Unfortunately, it’s also one of the most confusing to new UCMA developers. This is partly because its purpose isn’t immediately obvious when you start doing things like sending IMs or answering audio calls. Continue reading “What are Conversation objects for?” »
Posted: February 16th, 2012 | Author: Michael | Filed under: Lync Development | Tags: external access, federation, policy, provisioning, trusted application endpoint, voice policy | 3 Comments »
Unless your Lync environment has a single global policy for each type of policy setting (voice policy, conferencing policy, dial plan, etc.) you may run into problems where your UCMA trusted application endpoints don’t work properly with the default policy. A couple of common examples:
- Voice policy – the default collection of PSTN usages may not be appropriate for the PSTN calls initiated by your application
- External access policy – if your application needs to contact public IM or federated users and the default policy doesn’t allow this Continue reading “Trusted applications and policy settings” »
Posted: February 9th, 2012 | Author: Michael | Filed under: Lync Development, MSPL, OCS Development | Tags: MSPL | 7 Comments »
Some things are much easier to understand when you can see them in action. To add to my post on setting up MSPL scripts, I recorded a 12-minute video that shows the step-by-step process for installing an MSPL script on a Lync Front End Server and checking that it has started up properly. Let me know if this is a helpful format or if you have any questions or suggestions!
Posted: February 6th, 2012 | Author: Michael | Filed under: UCMA 3.0 | Tags: app sharing, application sharing | 4 Comments »
UCMA doesn’t include support for application sharing calls out of the box; it can handle only audio/video and instant messaging calls. This is normally not a big deal, since there’s not a whole lot that you could do in UCMA with application sharing. By virtue of not having a screen image to share, a UCMA app would be a pretty meaningless participant in an application sharing call. There’s one case, though, where being able to handle application sharing calls would be convenient: creating back-to-back calls between other Lync users. Continue reading “Handling application sharing calls in UCMA” »
Posted: January 29th, 2012 | Author: Michael | Filed under: UCMA 3.0 | Tags: formatting, html, IM, instant messaging | 2 Comments »
I can’t honestly say that I’ve run into a lot of situations where I’ve said to myself, “If only I could send an HTML formatted instant message right now, my problems would go away.” But adding formatting to IMs can definitely help with some specialized communication applications such as bots where you want to distinguish different types of messages, or emphasize certain parts of a conversation. So, to make those nice visual touches easier, and for anyone out there who is in a tight spot by virtue of not knowing how to send an IM with special formatting, I thought I’d write up a quick post on it. Continue reading “Sending formatted IMs from a UCMA application” »
Posted: January 25th, 2012 | Author: Michael | Filed under: UCMA 3.0 | Tags: Conversation, forwarding, multi-modality, multimodal, PSTN | 2 Comments »
If you have a UCMA application that communicates with users via both IM and audio in the same conversation, you may one day be caught off guard by the following exception:
Microsoft.Rtc.Signaling.OperationFailureException: Application must register
for ConversationChanged event when a call is moved to a derived conversation.
Specifically, this exception occurs if you try to add audio to a conversation that currently only has instant messaging and/or application sharing, and the remote party redirects the audio call to a PSTN phone; maybe because they don’t have headphones plugged in, or because they are on a wireless network which has been causing poor audio quality, or even because they are logged in on a client that doesn’t support audio. Continue reading “Call forwarding, UCMA, and “derived conversations”” »