Can CUBE route based upon Active Directory lookups

[JamesHawkins]

I think the answer to this is going to be no but just want to check. Other SBC vendors, such as Ribbon, offer a feature where the SBC can look at the called number in a received SIP Invite and then do a look up against Active Directory and route the call accordingly.

An example where this may be used is an SBC that connects to the PSTN and routes call to an on-premise CUCM and a cloud collab system such as Microsoft Teams.

Is there any way to do similar when using a Cisco CUBE? It seems a really useful feature and not having it would maybe put people off using CUBEs.

[Steven L · Accepted solution]

this is not a part of the core feature set.

i would question the value of this, honestly

you are either configuring AD or the SBC but there is nothing 100% automated.

[b.winter]

IMHO, this is not a bad question and furthermore, a very useful feature.
AudioCodes is able to route based on AD lookups, which in the end makes the "routing table" very small.

I have a customer with 5-digit count of users, everyone with a telephone number. And different systems, with a complete mix up, to where the telephone numbers should go to.
Every user (real life user, dummy user) has a tag in AD (e.g. MS, CUCM). When a call hits the SBC, the SBC searches the AD for the called number and gets a tag as the return. And based on the tag, the outbound "dial-peer" is selected.

Without this feature, this customer would be unmanageable.

[Steven L]

i wasnt saying it is a bad idea. Just saying that either way, you are maintaining an AD attribute to point where the call should go, or an e164 map.

feels like the same effort.

I feel like integrating CUCM with SNR that points to MS Teams as a remote destination is the most manageable.

At the end of the day, we all decide what/how we want to manage a particular requirement.

[b.winter]

I wouldn't say, it's the same effort. Simple scenario:
If a user switches from CUCM to MS teams (a classic scenario at the customer I've mentioned), in CUBE you would need 2 steps: 1) delete the pattern in e164-pattern-map <x> and 2) add the pattern in e164-pattern-map <y>.
Or even with a remote file: 1) change the files, 2) load the files.
In AD, I just need to change the tag (1 step).

And if you have CUBE redundancy, it's 4 steps in total compared to 1 step in AD.

And yes, everyone decides, what/how to manage it. But if there are options to manage it faster/easier/more efficient, I guess everybody would use the better ones.
On the other hand, if I don't have the options, I have no choices to decide upon, and need to work with what I got. Whether the only option I have is good or bad.

[Roger Kallberg · Accepted solution]

There’s a hard no on that. Cube doesn’t have this functionality.

[JamesHawkins]

Thanks everyone who replied. b.winter it is interesting to see your perspective on this and how it is vital for your customer's deployment.

To do similar on a CUBE I guess that a Powershell script could be used to extract user telephone numbers based upon group membership - e.g. "member of group MS Teams Users" - and that could then be dumped on a web server accessible to the CUBE.

The PS script could be scheduled and the CUBE configured to reload the text file containing the numbers on a regular basis.

To be honest using Audiocodes or Ribbon as the SBC seems a lot less hassle!

[b.winter]

The only thing in my mind is to use "voice class e164-pattern-map" and use a remote-file, where the patterns are stored in. And then have a fancy dashboard to manage the patterns in that file.

But I'm not sure, if CUBE does a lookup, every time a call hits the dial-peer with the e164-pattern-map configured.

Edit: It needs to be loaded manually via the command "voice class e164-pattern-map load <tag>".
Which maybe could be executed via API or something.

[Steven L]

you can probably do something with scripting. probably do it with CVP as well.