SBC Call Routing With Multiple Phone Systems

It’s not uncommon to have some combination of Skype for Business, Teams, and other PBXs in an organization, especially during migrations. One of the most challenging aspects in a scenario like this is maintaining call flow inbound from the PSTN, to the correct destination.

The magical way of doing this is to have contiguous blocks of numbers move from one platform to the next. In the real world, this almost never happens. That leaves us with the ugliness of static routing with a ton of rules to match the various number ranges and exceptions to them, or seeking some automated routing method.

One automated method is to have the SBC do a lookup in Active Directory, or some other LDAP directory. The SBC performs a lookup for the called number in a certain field, and can then look in a related field for that same user to understand the destination it should route the call to.

When a user is homed on a Skype for Business server, there phone number (lineURI) is stored in a field called msRTCSIP-LineURI. When an organization has just SfB server and another phone system, this allows for an easy “yes/no” decision. When there are multiple other phone systems, this task gets more challenging, as none of these other phone systems have a field like msRTCSIP-LineURI. This, by the way, includes Teams, which is rather ignorant of AD given that it’s a cloud platform.

There are a couple of solutions to this challenge. The first is for you to administratively populate the phone number and some sort of routing code/PBX identifier into unused fields in AD, AAD, or another LDAP platform. You can (but shouldn’t, yuck!) do this manually. Instead, populate these fields with scripting or another automated process. Now you can perform lookups and routing decisions based on the details that you’ve populated. However, you’ll need to keep these fields up-to-date with any adds/moves/changes to users and their numbers. This could mean that a user won’t receive their calls to the appropriate system until after an update completes.

A quick-and-dirty solution to this problem is to insert a series of alternate routes at the bottom of your routing table, that will try each of your phone systems in sequence, and if they receive a “404 not found”, they’ll roll to the next system:

Priority

Logic

Send to:

1

If LDAP Lookup says SfB

SfB Server

2

else if LDAP lookup says Cisco

Cisco

3

else if LDAP Lookup says Avaya

Avaya

4

else

Teams

5

If 404 return from Teams

Avaya

6

If 404 returned from Avaya

SfB Server

7

If 404 returned from SfB Server

Cisco

At first glance, this table seems to duplicate things – why do we need row 5 sending to the Avaya system if row 3 sends to Avaya? We wouldn’t, if row 3 was always able to receive up-to-date, perfectly synchronized lookup data, and there were never any system errors. That’s not reality though, so placing rules 5-7 at the bottom to simply brute-force try all the systems is a nice catch-all.

The “dirty” part of this “quick-and-dirty” solution is that the SBC logs will see the 404 failure each time these rules are used. You’ll need to tune your systems to not throw alarms and freak out due to those, and you’ll need to do a bit of extra work when you’re doing any syslogs or call traces. Of course, a spike in the appearance of 404s in your logs indicates something broken, so don’t ignore them completely.

The noise of all of these 404 entries is also why I’d never recommend only using this type of logic in a production environment. Performance really doesn’t take a hit, but good luck trying to troubleshoot calls when all you can see in your traces is 404s. However, doing pure brute-force can be useful during a rapid migration where LDAP lookup results will never stay in sync. You can also shift the priority of your rules in such a scenario so that the system likely to receive the most calls is at the top of the routing list.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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