Ribbon SBC – Teams Direct Routing – Automated Routing with AD

I suddenly have found the time to blog about the things I have been doing over the past few years, even if this doesn’t get a look, it’s always great for my own reference!

I have been working with Sonus/Ribbons for 5 years, and I love them as an SBC – out the box they just work, very easy to follow and setup, not to mention with virtualization of SweLite’s now out, it just makes deployment that much more flexible. – And I’m still learning them!

Automation for me is the next big ‘thing’ – if it eases up a workload to focus on something else – bring it on.

I have also seen a few posts floating around and coming back out the woodwork of how to do this automated routing with Teams DR kicking in more and more, so having the need to join in the blogging mindset – here is how we do it:

BIG STUFF:

Teams Direct Routing – Let’s not beat about the bush, this is here and it’s the only thing we all should be thinking about now, Teams DR has changed the way we think with calling platforms, manipulation, and all the fun stuff that’s kicking around about it now – Microsoft have a one-liner – If you can get us the call, we will do the rest.

 

SIDE STUFF:

Active Directory – It’s all in, everyone’s using it, it’s the backbone of every company – AD has been kicking around for user databases since the time of dawn – it’s powerful and with the right configuration can be used to automate quite a bit.

GOAL BITS:

On that train of thought – Ribbon + Direct Routing + Active Directory = Call Flow Automation

The first thing we need to decide is what attribute in AD is to be used to control the flow of the calls, you have a wide variety to choose from – Sticking with the one is the way forward – one attribute can contain a particular string which then can be acted on from the Ribbon side of things

For me, the choice has always been one of the extension attributes:

Having a single string of your target routing platform in one of these will be all you need (e.g – TEAMS, SKYPE, ANALOGUE)

Before we go any further, there are multiple ways of doing this… the popular one is using the DeploymentLocator attribute, which is fine, but I like to have that extra bit of control, just in case you have an extra route in there, use all the strings! and it’s more fun 🙂

1 – AD Cache

The first thing to ensure is that you are set up to talk to AD from the SBC’s, there is a pretty solid guide on the site to get you to this point:

https://support.sonus.net/display/UXDOC70/Configuring+the+SBC+Edge+for+Active+Directory

Once you have decided on the attribute itself – pop into your AD configuration on your Ribbon and add that extension to your AD cache (Auth and Directory Services -> Active Directory -> Configuration):

2 – Transformation Table

2a – Create a new Transformation Table that will capture all your PSTN traffic and scoop it up straight over the Teams Direct Routing SG

Name: from PSTN to Teams

2b – Create some new Transformation Entries inside the previously created Transformation Table (all mandatory – we want it to hit, or miss in one…)

Catch your LineURI from your provider – As you will see in my one below – Sipgate doesn’t like to send me the + – we took care of that – adjust for your upstream! – Keep E.164 clean!

Make the initial AD check using the SIPLine attribute – we need this to pull back the extentionAttribute10 relating to the Called number above!

Make the comparison with a string of your choice in that AD variable – in this case, I just use TEAMS string inside of the user’s account.

This should be enough in the TX rule to go off to AD, match against the TEAMS string and do the next part of the puzzle… the call routing!

Overview here:

3 – Call Routing Table / Entry

Add a new call routing entry to your CRT from your upstream provider to the Teams SG, above your current entry for Skype, PBX etc

Having it above will perform the mandatory lookup first, this is why we add the whole lot as a match all, from here IF the TEAMS string doesn’t hit, it will drop to your next matches you have and carry on its merry way.

This should be a good starting point to getting AD involved in your solution… a couple of points to watch out for below that have hit me in the past

• SBC Cache Update Interval – Remember, you set the update interval, so making changes in the AD cache may not kick in, you can refresh but watch the load!
• Scopes – Limit your scopes if you can, there is nothing more frustrating caching information you don’t need.
• Testing – Instead of capturing all your numbers when activating, capture a single number and test first – don’t trust the sync!

Hope it helps, I may have some issues and tweaks I need to make.. or perhaps someone may be able to simplify it even more!

Ben