Routing calls based off Active Directory LDAP lookups can be a handy feature to utilize. Personally speaking, I don’t typically use LDAP for much else than authentication with Sonus and Audiocodes devices, but that’s just me. In some cases you inherit a previous person’s configuration where it was enabled, and when things break….well….you have to unravel the ball of yarn.
With all that being said, the summary of the configuration at hand was:
- Two T-1 PRI’s connected to an Audiocodes Mediant 1000B Gateway from an upstream provider.
- Note: The PRI’s are all located in the United States
- Two T-1 PRI’s connected to the same Audiocodes Mediant 1000B Gateway from an Inter-Tel Axxess 9000 TDM PBX.
- As a result, the Audiocodes was downstream from the provider, but upstream of the legacy PBX
- A single IP Group/Proxy Set was configured for a Skype for Business Server 2015 deployment, consisting of three Front End Servers with collocated Mediation roles.
- To “simplify” routing & configuration on the Inter-tel for when a user is moved to Skype4B, AD routing was enabled on the Audiocodes gateway.
This is a fairly standard configuration, but AD routing lookup matches were failing for certain numbers on calls inbound from the provider PRI trunk. The numbers were absolutely assigned to an object in Skype for Business Server and were enabled for Enterprise Voice. As a result, there were what seemed like intermittent cases where call flows were being sent to the legacy PBX instead of Skype4B.
Alright, challenge accepted….
The Initial Config
LDAP configuration on Audiocodes can be fairly simplistic and doesn’t necessarily require the use of Call Setup Rules. This particular configuration had them in place so I took at look at the initial config:
The PRI provider was sending the full 11 digits for the called party (DstPn) so the Call Setup Rule was effectively configured to take the 11 digits and then search the msRtcSip-Line attribute to see if there was a user that matched. Additionally, there was a (rightly configured) fail-safe configuration in place that also made sure the user was actually enabled for Enterprise Voice by searching the msRtcSip-OptionFlags attribute.
Note: Greig Sheridan has a good write-up of the “fail-safe” configuration for Sonus SBCs, located here.
Given that the configuration seemed to be correct, I thought…alright….let’s do some tests and gather some logs.
Testing Commences
- I called test number #1 and the call worked as expected with AD routing successfully finding the user in AD.
- I called test number #2 and the call did not work as expected. AD routing did not detect the user in AD.
- I called test number #1 again and the call worked as expected with AD routing successfully finding the user in AD.
- I called test number #3 and the call did not work as expected. AD routing did not detect the user in AD.
- I called test number #4 and the call worked as expected with AD routing successfully finding the user in AD.
- I called test number #5 and the call worked as expected with AD routing successfully finding the user in AD.
Head, meet wall
At this point I am definitely confused because it is very apparent the LDAP lookups are at least working in some capacity. Caching was also not enabled so these lookups are hitting AD real-time for numbers that have been assigned for 2-3 days. AD replication was up-to-date. Beginning to have a hunch that the issue was AD-lookup related, I began to examine the actual user accounts that had the matching LineUri’s and after sorting through a few of the accounts, I noticed why the call was not matching. I’ll give you the data to see if you can catch it….
Test Number #1
Test Number #2
Test Number #3
Test Number #4
Test Number #5
Have you figured it out? If no, I’ll give you a little nugget of help…
Schema attributes for Skype for Business
Root Cause
The Call Setup Rule configuration on the Audiocodes gateway was explicitly looking for a value of ‘385’ for the msRtcSip-OptionFlags attribute. The call tests that were failing to route, however, showed that the AD attribute of the account had a value of ‘1409’ for the msRtcSip-OptionFlags attribute. Since the rule didn’t match the value…the call doesn’t route according to the AD matching rules.
The immediate fix was to simply edit the Call Setup Rule with a logical ‘or’ statement that searches for both values:
ldap.attr.msRTCSIP-OptionFlags == '385' or ldap.attr.msRTCSIP-OptionFlags == '1409'
With the additional condition statement in there, I called all the test numbers again and all calls were routed as expected. AD routing was now truly functional for all account types.
But why ‘1409’?
The OptionFlags value is a bit-mask that takes individual values and adds them up to show what features you are enabled for in Skype4B (or Lync or OCS…). For all the tests conducted, I saw that the following accounts had the expected ‘385’ value:
- Common Area Phone accounts
- User Accounts enabled for EV
- Response Groups
- Analog Phone accounts
- Exchange UM Subscriber Access accounts
- Announcement Service
There was one, and only one, account type that was not showing up with the expected ‘385’ value:
- Exchange UM Auto Attendant accounts
Indeed, every single test number that was failing was isolated to an Exchange UM Auto Attendant contact object that had been created. Initially I thought it might have been a side effect of using the OcsUmUtil.exe application, but this same configuration occurs if you create the contact object using the New-CsExUmContact cmdlet. It appears that either method of creating AD contact objects for Exchange UM Auto Attendant objects stamps the OptionFlags attribute to ‘1409’.
Wrap-Up
Unfortunately I’m not entirely sure why the ‘1409’ value gets set the way it does. Even so, if you are doing AD routing and using that fail-safe configuration – either on Audiocodes or Sonus – you’ll want to update your rule conditions to also filter for the ‘1409’ value. If you don’t, you may end up with inconsistent AD routing results. Given that I don’t typically configure AD routing, I didn’t initially think to examine this as a potential root cause, but you can guarantee that I will be sure to do so from here on out!