I have recently been troubleshooting issues with a Sonus SBC 1000 doing call routing using AD lookups.
There are many blogs out there about how to do this, including the guide from Sonus themselves which is pretty descent.
Let me however, go into some of the gotchas that caught me by surprise, and are not well documented on the Sonus site…
AD Cache Lookup
There is a very clear note saying that it is “recommended” to have a USB stick attached to the SBC if you are going to use the AD Lookup in cached mode.
What there is no mention of, is the way the Sonus SBC uses the cache, and how it gets updated. This information was provided to me from Sonus TAC/Engineering, and is current as of the date of publishing this blog post; this applies to having the AD Configuration in “Updates” mode…
- All domain controllers configured are treated equally; i.e. if any one of them responds back with a successful query, then the cache is valid, even if all the other queries fail.
- The cache is dropped before the new cache is read; thus if the AD query fails, the system is left with “NO CACHE” unless you have a USB stick with a backup cache to be used.
- if “ALL” domain controllers fail to respond, the SBC switches to online mode, and tries to query the domain controllers in order for the user in question.
- The system will not try any failed domain controllers again until the next update cycle as configured in the “Cache Settings”
they have said that they are working on improving the process…
Case Sensitive Lookup
Again with AD Cache lookups; apparently the lookup is case-sensitive; while simply testing for “=msRTCSIP-Line=” in your transformation table may work most of the time, apparently, if an admin in Lync has decided to type “Tel:+xxxxx” instead of “tel:+xxxx” the query would fail to return a positive match.
To overcome this issue the recommendation is to use “(?i)=msRTCSIP-Line=” which would make the lookup case-in-sensitive.
Of course you can use the same “(?i)” in other locations too for matching without case.