How to manage alternative Caller ID in Teams via SBC

Hi All,

a well known missing feature of Microsoft Teams Phone System compared to Skype for Business Server is the ability to mask the Caller ID based on the used Voice Route.

In other words, we strongly miss the “Suppress caller ID / Alternate caller ID” settings in SfB Voice Route

Caller ID in Teams

Microsoft Teams moved the “Suppress caller ID / Alternate caller ID” settings from Voice Routes to a dedicated User’s Policy, the “Caller ID policy

In the “Caller ID Policy” you can suppress the original Users’ number with a new one, but at this moment the choices are very limited:

  • Service number: you can set the Caller ID to a Microsoft Service number
  • Anonymous: you can remove the Caller ID

There is no way to set other numbers, and in particular it’s not possible to set a owned PSTN number used via Direct Routing.

So at this moment there are two problems:

  1. There is no way to freely set a number in the Caller ID Policy
  2. The alternate Caller ID settings is a policy, so it’s applied to EVERY calls the User will place. This is a big issue if the User need to call an internal number in a Legacy PBX via Direct Routing for example

You can imagine to use PSTN Gateway Transformations Rules to solve these issue, but this way could be very time consuming and you can easily reach the 400 transformations rule cap limit.

Instead, let’s see how to solve these two problems with an SBC

The SBC solution

The idea is very simple: use an AD attribute of the User to set the “alternative Caller ID number” to be used on PSTN outbound calls, and use the AD integration of the Ribbon SBC EDGE to “make the magic”.
The alternative value is not mandatory, if it’s present it will be used, if not, the original Callerd ID will not be changed.

In this article I'll use the ipPhone AD attribute (you can use whatever you prefer) and a Ribbon SBC.
I take for granted that the basic AD integration on the SBC is done and working.
If you have to set it up, use this Ribbon official documentation: 
Call Routing Based on Active Directory User Attributes

AD attributes check

First of all, on the Ribbon SBC EDGE go to Setting -> Auth and Directory Services -> Active Directory -> Configuration and check/add the attribute you want to use, ipPhone in this example.

Transformation Rule

In these examples I assume that:

  • you have in place a Transformation Rule that route calls from Teams to PSTN, called FROM TEAMS TO PSTN like in this example
  • the E.164 User’s number is correctly set in telephoneNumber attribute. Instead of that, you can use msRTCSIP-Line
  • the alternative Caller ID is stored in ipPhone attribute.
    The alternative value is not mandatory, if it’s present it will be used, if not, the original Callerd ID will not be changed.

The first entry you have to check/add in the Transformation Rule is the one that make an AD lookup to find the User with the telephoneNumber (point 2) equal to the Calling Number (point 1), read the ipPhone number (point 3) and save it in User Value 1 (point 4).
Note: at this point we do not know if the ipPhone attribute is populated or not.

The next line will check if the User Value 1 is populated with a number or not.
The Expression Rule \+?\d+ (point 6) will accept a string from User Value 1 (point 5) with digits and that could start with a +, if this is true the ipPhone value (point 7) will overwrite the Calling Address/Number value (point 8)

Next line is a “Safe Rule”, it’s meant to allow the whole Transformation Rule to not fail if the previous check fail. It’s a line that it’s always true.

To learn more about the Optional Matching in Ribbon SBC, take a look at this document: Optional Matching Overview

Next lines will normalize the Caller ID, manage the redirecting number and other two “Safe Rules”

These few lines in the Transformation Rules will accomplish the goals we had:

  • an easy and not time wasting way to manage the alternative Caller ID
  • the alternative Caller ID could be used in some routes (eg: to PSTN) and not in other routes (eg: to legacy PBX)

Let me know what do you think about that.

As always, I hope this could help some of you.
Best. Luca

Leave a Reply

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

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

Up ↑

%d bloggers like this: