In this section:
Modified: for 8.0.3
This best practice details how to use Microsoft Azure AD to automatically route calls from a SIP Trunk or PSTN to Microsoft Teams Direct Routing at the same time user migrates to Microsoft Teams.
In this network scenario, a call arrives from the carrier and the SBC Edge uses Azure AD information to detect if the called user had already been migrated to Microsoft Teams, as follows.
SBC Edge does not require any configuration updates when a user is migrated to Microsoft Teams.
Network Scenario- Use Azure AD to Automate Migration to Microsoft Teams Direct Routing
In the configuration example used for this Best Practice, a call arrives from the SIP Trunk and an IP address is associated with a SIP Signaling Group (SIP SG). The SIP Signaling Group points to a Call Routing Table which in turn specifies a Transformation Table.
The Transformation Table contains two entries:
For the purpose of this example, the following attributes are used:
Transformation Table - Attributes
Field | Attribute |
---|---|
Calling Party | PSTN phone +15101231234 |
Called Party |
|
The following prerequisites are required for configuring the SBC Edge and Azure for automated migration:
Before SBC Edge configuration, setup the SBC Edge according to the following:
SBC Edge - Installation
Product | Refer to... |
---|---|
SBC 1000 SBC 2000 | Installing SBC 1000/2000 |
SBC SWe Lite On Prem | Installing SBC SWe Lite |
SBC SWe Lite in Azure | Running a SWe Lite via Microsoft Azure Marketplace |
Configure the SBC Edge according to the following:
SBC Edge Configuration
Configure | Refer to... |
---|---|
SBC Edge between SIP Trunk Provider and PBX | Configure a SIP Trunk With IP PBX |
SBC Edge for Microsoft Teams Direct Routing | Configuring Microsoft Teams Direct Routing |
Configure LDAPS on Azure AD Domain Services. Refer to: Configure Secure LDAP for an Azure Active Directory Domain Services Managed Domain. The section "Export a certificate for client computers" is not required.
Take note of the "Secure LDAP External IP Address" or the FQDN that you associated. In this example, ldaps.domain.com is used.
Add the SBC Public IP address to the Azure AD Domain Services Network Security Group (AADDS-domain.com-NSG).
Active Directory based call routing can be preformed only with an AD feature license. Verify this license is installed as follows:
Verify that the Active Directory feature is licensed.
View Active Directory License
For detailed information on licenses, refer to: Working with Licenses.
Add a domain controller per the parameters below. For details on creating a Domain Controller, refer to Adding and Modifying Domain Controllers.
Click OK.
Domain Controller Screen
Domain Controller Configuration
Attribute | Value |
---|---|
Description | Azure AD |
Domain Controller Address | <"Secure LDAP External IP Address" or the FQDN that you associated to it.>. Enter the user created in step 2 in Prepare Azure Active Directory Domain Services. Example: ldaps.domain.com. |
DC Type | Call Route |
Search Scope | <AD object that contains the domain user> Example: DC=domain,DC=com |
LDAP Query | <Filter to query the proper user>. Example: displayName=* |
Server Timeout | 5 |
User Name | <User used to query Azure AD>. Enter the name created in step 3 in Prepare Azure Active Directory Domain Services. Example: admin@domain.com. |
Password | <Password for admin@domain.com> |
DC Role | Primary |
DC Priority | 1 |
Create and configure an Active Directory entry as follows:
Click Apply.
Active Directory Screen
Active Directory Configuration
Attribute | Value |
---|---|
AD Enabled | True |
Use TLS | True |
Operating Mode | Update |
Query/Cache Attribute | displayName, telephoneNumber |
Nested Group Lookup for Authentication | True |
Normalize Cache | False |
Update Frequency | 1440 |
Configure Initial Update Time | False |
AD Backup Failure Alarm | Enable |
Encrypt AD Cache | True |
The Active Directory Cache Query tool allows you to query the local AD Cache for records that match a selected property/value pair. The query returns the records associated with the first match it finds. This tool is useful in determining if the Cache has been updated after a record has been added on the Domain Controller.
Perform an AD query as follows:
Click OK.
The query should return results similar to those shown below.
Query Results
Outbound ACL
Outbound ACL Configuration
Attribute | Value |
---|---|
Description | Outbound LDAPS Request |
Protocol | TCP |
Action | Allow |
Port Selection Method | Range |
Source IP Address | <IP Address of your logical interface> |
Source Netmask | 255.255.255.255 |
Source Minimum Port Number | 0 |
Source Maximum Port Number | 65535 |
Destination IP Address | <"Secure LDAP External IP Address"> |
Destination Netmask | 255.255.255.255 |
Destination Minimum Port Number | 636 |
Destination Maximum Port Number | 636 |
Inbound ACL
Inbound ACL Configuration
Attribute | Value |
---|---|
Description | Outbound LDAPS Response |
Protocol | TCP |
Action | Allow |
Port Selection Method | Range |
Source IP Address | <"Secure LDAP External IP Address"> |
Source Netmask | 255.255.255.255 |
Source Minimum Port Number | 636 |
Source Maximum Port Number | 636 |
Destination IP Address | <IP Address of your logical interface> |
Destination Netmask | 255.255.255.255 |
Destination Minimum Port Number | 0 |
Destination Maximum Port Number | 65535 |
For detailed information about ACLs, refer to Working with Access Control Lists and Session Control.
A Transformation table contains a list of entries that contain routing rules. Two Transformation table entries are required:
Create the Transformation Table entries as follows:
Create a Transformation table called From SIP-Trunk to Teams user. For details, refer to Managing Transformation Tables.
Add two entries. See below for configuration. For details, refer to Creating and Modifying Entries to Transformation Tables.
From SIP-Trunk Teams User - Entry 1
From SIP-Trunk to Teams Entry 2 - Attributes
Attribute | Value |
---|---|
Match Type | Mandatory |
Input Field Type | Called Address/Number |
Input Field Value | (.*) |
Output Field Type | User Value 1 |
Output Field Value | +\1 |
From SIP-Trunk to Teams User - Entry 2
From SIP-Trunk to Teams Entry 2 - Attributes
Attribute | Value |
---|---|
Match Type | Mandatory |
Input Field Type | User Value 1 |
Input Field Value | =telephoneNumber= |
Output Field Type | Called Address/Number |
Output Field Value | =telephoneNumber= |
Add a new entry as follows:
Call Routing Table
Call Routing Table Entries
Attribute | Value |
---|---|
Description | To Teams Users |
Number/Name Transformation Table | From SIP-Trunk to Teams user |
Destination Signaling Groups | Microsoft Phone System |
Reorder this Routing table to have this new rule on TOP of the rule going to the PBX.
Routing Table - Example
When migrating a user to Microsoft Teams, the administrator needs to enter a Phone Number (with a format that match the one used in the transformation table) via Office 365 Portal. The SBC Edge replicates this information locally. When a call comes from the SIP Trunk, if the Called Number matches the telephoneNumber, the call is sent to Teams. If the Call Number does not match, the call is sent to the PBX.
Enter the user phone number in Phone Number field.
Active User Example
To properly verify the SBC Edge's configuration, please review these steps are completed. See figure below.
In the Call Route Entry, the incoming number is first formatted to the proper format (+12122139087) using the relevant call route entry. A match is then made using the cached Active Directory user attributes.
The call is then routed to the relevant Direct Routing outbound Signaling Group.
To view the AD usage in progression via the WebUI log, refer to Working with Logging. See below for an example.
Call Going to a Teams User
In the Call Route Entry, the incoming number is first formatted to the proper format (+10001001004) using the relevant call route entry. A match is NOT made using the cached Active Directory user attributes. The call is then routed to the relevant PBX outbound Signaling Group.
To view the AD usage in progression via the WebUI log, refer to Working with Logging. See below for an example.
Call Going to a PBX User