Posted: November 20th, 2014 | Author: Michael | Filed under: UCMA 4.0 | Tags: backup pools, disaster recovery, DR, failover, paired pools | No Comments »
Periodically I get a question about what happens to UCMA applications that are associated with one of the pools in a paired pool architecture when users are failed over to a backup pool. This can be very important since in some cases a UCMA application is serving a critical function for some part of the organization, and so they want to be sure that it will remain available in a failover situation.
Unfortunately, UCMA applications are not automatically failed over when you run the Invoke-CsPoolFailover cmdlet in Lync Server Management Shell. If a pool that is the next hop for a UCMA application goes down, and the users are failed over to the backup pool, the UCMA application will still be out of commission. This means that it’s not uncommon for UCMA applications to be overlooked in failover planning. People may assume they will fail over with everything else, while others may simply not know about the applications. If you want to include UCMA applications in your failover plan, you’ll need to plan for some additional manual steps to fail them over.
Continue reading “UCMA applications and Lync paired pools” »
Posted: March 31st, 2014 | Author: Michael | Filed under: UCMA 4.0 | Tags: Exchange UM, voice mail, voicemail | 2 Comments »
A while back, I wrote a post on how to call an Exchange UM voice mail box directly. The trouble with the approach described in that post is that it generates a missed call notification in the Exchange inbox of the recipient. A colleague of mine discovered a way to nix this missed call notification, and I thought I would share it.
You can get a SIP URI that goes directly to a user’s voice mail box by appending ;opaque=app:voicemail to the end of that user’s address of record. For instance, if the user has the SIP URI sip:firstname.lastname@example.org, you can get their voice mail box by calling sip:email@example.com;opaque=app:voicemail. However, this will lead to a missed call notification.
If you instead call sip:firstname.lastname@example.org;opaque=app:voicemail;local-resource-path=voicememo, you will get the user’s voice mail box but there will be no missed call notification.
Posted: March 20th, 2014 | Author: Michael | Filed under: UCMA 4.0 | Tags: impersonation, SIP URI, troubleshooting | No Comments »
For a development platform that abstracts away a whole lot of underlying activity, UCMA really does a pretty good job of letting you know the cause when a problem occurs. But there are a few cases where errors in UCMA applications can be utterly bewildering, and probably the most frustrating of these are the ones that result from typos in SIP URIs. Missing a character or misspelling a part of a SIP URI can lead to errors that seem to have no relationship to what is actually going wrong. I wanted to cover a couple of those errors here in the hope of preventing others from tearing their hair out for multiple days trying to troubleshoot these sneaky problems. Continue reading “SIP URI typos and the misleading errors they cause” »
Posted: February 16th, 2014 | Author: Michael | Filed under: UCMA 4.0 | Tags: Enterprise Voice, presence, UCMA, UCMA 4.0 | No Comments »
How can your UCMA application determine whether a Lync user is enabled for Enterprise Voice? The answer is a bit more complex than you might think. In short, the best way appears to be establishing a UserEndpoint for the user in question, subscribing to local owner presence, and checking the information in the userProperties presence category. The rest of this post describes how to do this. Continue reading “Determining whether a user has Enterprise Voice” »
Posted: January 8th, 2014 | Author: Michael | Filed under: MSPL, UCMA 4.0 | 2 Comments »
One of the great things you can do with the Lync Server SDK is reroute calls to a UCMA application. Your MSPL script or managed SIP application can intercept any call that goes through the Front End Server (or any SIP request or response, more generally) and send it to a UCMA application you’ve written, rather than the originally intended recipient. Your application can then handle the request, and proxy it through to the destination, or block it, or do something else entirely. There are more uses for this than I can possibly describe here: recording, call filtering, auto-attendants, compliance, call billing, you name it.
Typically in a case like this the UCMA application has a default routing endpoint so that it will answer all of these calls that have a To SIP URI that doesn’t belong to the application. But what if you don’t want all rerouted calls to go to a single endpoint? What if you need to have a number of endpoints in your application – let’s say one for recording and another for call filtering – and your Lync Server SDK application needs to somehow specify which of the endpoints the rerouted call should go to? Continue reading “Getting rerouted messages to the right UCMA endpoint” »
Posted: December 16th, 2013 | Author: Michael | Filed under: MSPL | 6 Comments »
Every so often I get a question about Response Groups – can you use the APIs to make it do this or that thing differently? Unfortunately, the answer to these questions is usually no; Response Group Services is not very customizable. But there is one feature of Response Groups that can be changed relatively easily using the development platform. By default, calls from Response Groups ignore call forwarding or simultaneous ring settings. If you receive a call from Response Groups, it will not ring your cell phone or any other phone number you have set up the Lync client to forward to. With a simple Lync Server SDK application, you can change this and allow Response Group calls to go to call forwarding numbers. Continue reading “Response Groups and call forwarding” »
Posted: December 6th, 2013 | Author: Michael | Filed under: UCMA 3.0, UCMA 4.0 | Tags: presence, presence subscription, RemotePresenceView | 2 Comments »
In Lync development, as in many other areas of life, things get much more complicated when you have more than one application pool. You need to start thinking about scenarios that previously weren’t possible. One important case your application needs to account for if it may be deployed across more than one pool of servers is receiving presence updates from different pools of Front End servers. You can often get away with ignoring this effect, but you risk running into strange and seemingly inexplicable behaviour once in a while. This post explains the issue and what you can do about it. Continue reading “Presence updates and multiple application pools” »
Posted: October 30th, 2013 | Author: Michael | Filed under: UCMA 4.0 | Tags: conference, conferencing, delay | No Comments »
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” »
Posted: October 23rd, 2013 | Author: Michael | Filed under: UCMA 4.0 | Tags: bandwidth policy, CAC, call admission control, UCMA, voice policy | No Comments »
Just as dial plans, voice policies, conferencing policies, and so forth apply to trusted application endpoints, calls placed by UCMA applications can be affected by call admission control (CAC). This can produce seemingly inexplicable call failures when call admission control is enabled, and the problem is exacerbated by the fact that CAC only makes sense in larger, distributed Lync environments, and therefore is almost never turned on in development or testing environments. Issues with CAC are therefore much more likely to arise in production, and cause a great deal of vexation and hair-pulling. This post explains how to build your UCMA applications to avoid or at least identify failures related to CAC so that they will be less mysterious if they come up in a new environment. Continue reading “Call Admission Control and UCMA” »
Posted: October 3rd, 2013 | Author: Michael | Filed under: MSPL | Tags: Lync Server SDK, MSPL, re-INVITE | No Comments »
When handling Lync Server activity at a SIP level, it is often important to identify re-INVITE messages and ignore them or handle them differently. I recently found out about a better way of reliably identifying re-INVITEs than the ones I’ve recommended in the past, and wanted to share it here. Continue reading “Identifying re-INVITEs” »