Sonus SBC1000/2000 Active Directory Call Routing: how to query both Configuration and Default Naming Context

Hi, today I want to show you how to configure your Sonus SBC1000/2000 to make LDAP Query in Configuration and Default Naming Context.

The schema below is a very common configuration, where a Sonus SBC1000/2000 work as a man-in-the-middle between your PSTN Carrier and a legacy PBX during a migration to Lync Enterprise Voice.
It’s important to say that this is a fresh Lync 2013 deployment, no OCS to Lync migration.


A foundamental feature of SBC is the ability to query Active Directory and routing the call to Lync or to PBX if the Called number is associated to a Lync EV User or not.

To configure your SBC start reading this Sonus Guide articles:
Configuring the Sonus SBC 1000-2000 for Active Directory
Call Routing Based on Active Directory User Attributes

This is an example of a standard AD Configuration, where the AD DNS domain is dnsdomain.local



To test it, go to Diagnostics -> Query AD Cache -> enter the msRTCSIP-Line of Lync EV User, the result should be this one (you may have to Refresh the Cache, Settings->Auth and Directory Services->Active Directory->Configuration->Refresh Cache)


Now you can implement the Transformation Table, the Call Routing Table and the Signaling Group. Everything works fine and the calls are correctly routed between PSTN, PBX and Lync (these arguments are not in the scope of this article, sorry 🙂 )


Ok, now the customer wants to test the RGS Feauture of Lync.
You say: PERFECT! Let’s do it!

Create a new Lync RGS HuntGroup and assign a telephone number like +390512345678
 (note that there isn’t the extension).

The scenario change to this one.ADRouting2

Test the new Workflow from Lync and everything works fine.
Test it from PSTN and the call is routed to PBX! Hey!!??!
If you test the number with Active Directory Cache Query, you will obtain an error:
Active directory query failed.


The reason is that Lync 2010/2013 use the AD Configuration context to store the Aplication Contacts, not the Default Naming context.
Use ADSI Edit to open the Configuration context of you AD, browse the tree into CN=Services -> CN=RTC Service -> CN=Application Contacts


That’s why the Sonus LDAP Search in AD will fail.
To allow Sonus SBC1000/2000 to make LDAP Search in AD in both the Configuration and Default Naming context, simply add a second DC (could be the same of the first you have configured), be careful to add
in the Search Scope. In our example should be CN=Configuration,DC=dnsdomain,DC=local
set at 2 the DC Priority


If you test the AD query now, the Sonus will find the RGS Application Contact.


The dynamic AD routing is now working perfectly!

PS: someone could have noticed that if you use the standard AD Transformation Table present in the Sonus documentation (see the image below), the routing of a msRTCSIP-Line without the extension will fail.

There is a simple tip to allow Sonus to search for a normalized number that may have o have not the extension:
place an * at the end of the Output Field Value

For ex, in our lab should be:

Input Field

Input Field Value

Output Field

Output Field Value

Match Type

Called Address/Number


User Value 1



User Value 1


User Value 1



Called Address/Number


Called Address/Number



I hope this could help you 🙂
Best Regards


4 thoughts on “Sonus SBC1000/2000 Active Directory Call Routing: how to query both Configuration and Default Naming Context

Add yours

  1. Hi Luca, great peace of info, just to add to the details .. in case someone faces this. If you are on a Lync system that had been upgraded from OCS, you might not find that node. The node from OCS days is at CN=RTC Service,CN=Microsoft,CN=System,DC=contoso,DC=com


  2. Figured I’d drop a line here, I have a customer environment that returns nothing unless I specify the full path

    CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=Skype4bAdmin,DC=local

    Liked by 1 person

  3. Hi James,
    This is interesting and a bit strange, it seems that Sonus do not make recursive search in that environment. Maybe a Syslog capture on Sonus could help to understand this behavior. Thank you for sharing! Regards. Luca


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: