Microsoft Lync and Skype for Business have a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use those APIs.

Call Admission Control and UCMA

Posted: October 23rd, 2013 | Author: | Filed under: UCMA 4.0 | Tags: , , , , | 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.

Let me start by summarizing how CAC works, since it’s not a feature that you normally run into much in doing Lync development. In a nutshell, CAC causes Lync to reject calls between sites or redirect them over the PSTN if bandwidth usage exceeds a certain threshold on the network link that the call would use. So if a company has a site in New York and a site in London, and bandwidth usage has reached the limit on the link between them, Lync will start forcing calls between those two sites to go over the PSTN, or, failing that, will reject them entirely (and send them to voicemail, if available).

Now, this is great for maintaining call quality on ordinary Lync calls. But UCMA applications often depend on being able to connect calls reliably at a moment’s notice. If you have a customer call coming in, for instance, you probably don’t want to block it because of bandwidth usage.

You might think the easy answer is to disable CAC for calls involving your UCMA application. You can do this, but only partly. There is a voice policy setting (EnableBWPolicyOverride) that disables CAC for incoming calls only to the endpoints the policy is applied to. For instance, if you apply a policy with EnableBWPolicyOverride set to true to your trusted application endpoint, anyone who calls your application will be able to get through regardless of network conditions. However, if your application places an outbound call, all bets are off.

If you have a group of users that will be receiving frequent calls from your UCMA application, you can deal with outbound calls by applying a special voice policy to these users as well. The downside is that the override will apply to all of their calls, not just the ones from your UCMA application, so if you override the bandwidth policies for too many users, you’ll be defeating the purpose of having CAC in the first place.

To modify a voice policy to override CAC, just set the EnableBWPolicyOverride property to true:

Modify-CsVoicePolicy -Identity Tag:TestVoicePolicy -EnableBWPolicyOverride $true

You can assign the policy to your UCMA application using the Grant-CsVoicePolicy commandlet:

Grant-CsVoicePolicy -Identity sip:mytrustedappendpoint@example.com -PolicyName Tag:TestVoicePolicy

If your situation does not allow you to get around CAC through selective use of voice policy settings, there are a couple more things you can do. First, instead of just catching RealTimeException when establishing calls, you can first explicitly catch FailureResponseException, which is a subclass of RealTimeException. The WarningInformation collection on FailureResponseException has WarningHeader objects that contain details on the cause of failure, so you can find out if CAC caused the call to be rejected. It can be helpful for other troubleshooting as well, and may occasionally save you a trip to the Lync Server Logging Tool for additional logs.

Second, when accepting calls, UCMA by default refuses to allow calls to be redirected over the PSTN. So if CAC is in place, calls to your UCMA application will, by default, either connect as full IP calls or be rejected entirely. However, you can manually tell UCMA to allow redirection by changing a property on CallAcceptOptions, as in the following example:

CallAcceptOptions options = new CallAcceptOptions();
options.RedirectDueToBandwidthPolicyEnabled = true;

try
{
    call.BeginAccept(options, OnAcceptCompleted, null);
}
catch (FailureResponseException ex)
{
    Console.WriteLine(ex);

    foreach (WarningHeader warning in ex.WarningInformation)
    {
        // Do something with the warning headers...
    }
}
catch (RealTimeException ex)
{
    Console.WriteLine(ex);
}

Set the RedirectDueToBandwidthPolicyEnabled property to true on CallAcceptOptions, and at least calls to your application can be redirected over the PSTN when CAC requires it.

Last but not least, keep in mind that if you ARE hitting CAC limits regularly, although these solutions will help identify the problem and possibly get around it, the eventual solution is probably to add bandwidth (or reduce traffic). The purpose of CAC is to protect call quality, so if you disable or override it, you may later pay the price in call quality issues.



Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •