You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Overview

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 

Unable to show "metadata-from": No such page "_space_variables"
uses Azure AD information to detect if the called user had already been migrated to Microsoft Teams, as follows.

  • If the user has been migrated to Teams, the call is sent to the Teams user using Microsoft Direct Routing.
  • If the user is not a Teams user, call is sent to the PBX phone using the PBX connection.

Unable to show "metadata-from": No such page "_space_variables"
 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


Overview - Call Routing Logic 

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:

  • One transformation entry formats the Called Number to match the format used in Azure AD. The 
    Unable to show "metadata-from": No such page "_space_variables"
    adds a "+" to match the format of the telephoneNumber Azure Active Directory user attribute.
  • The second transformation entry searches for this formatted value in the phoneNumber Active Directory user attribute stored in the local Azure AD cache.

For the purpose of this example, the following attributes are used:

Transformation Table - Attributes

FieldAttribute
Calling PartyPSTN phone +15101231234
Called Party
  • From SIP Trunk: 12122139087
  • Teams client with following AD profile:
    • displayName: Ribbon xxxx
    • userPrincipalName: user@domain.com
    • telephoneNumber: +12122139087

  • For general 
    Unable to show "metadata-from": No such page "_space_variables"
    Call Routing information, refer to
    Working with Telephony Routing.
  • For the purposes of this documentation, all 
    Unable to show "metadata-from": No such page "_space_variables"
    screen capture examples are taken from SBC 2000.

Step 1: Prerequisites

The following prerequisites are required for configuring the 

Unable to show "metadata-from": No such page "_space_variables"
and Azure for automated migration:

  • SBC 1000, SBC 2000 or 
    Unable to show "metadata-from": No such page "_space_variables"
  • Unable to show "metadata-from": No such page "_space_variables"
     License includes Active Directory
  • Active Azure subscription
  • Azure Active Directory tenant associated with your subscription (either synchronized with an on-premises directory or a cloud-only directory)

Setup the 
Unable to show "metadata-from": No such page "_space_variables"

Before 

Unable to show "metadata-from": No such page "_space_variables"
configuration, setup the 
Unable to show "metadata-from": No such page "_space_variables"
according to the following:

SBC Edge Portfolio - Installation

ProductRefer to...

SBC 1000

SBC 2000

Installing SBC 1000/2000

Unable to show "metadata-from": No such page "_space_variables"
 On Prem

Installing SBC SWe Edge

Unable to show "metadata-from": No such page "_space_variables"
 in Azure

Running an SBC SWe Edge via Microsoft Azure Marketplace

 


Configure the 
Unable to show "metadata-from": No such page "_space_variables"
to Access PSTN, PBX and Direct Routing

Configure the 

Unable to show "metadata-from": No such page "_space_variables"
according to the following:

SBC Edge Portfolio Configuration

ConfigureRefer to...

Unable to show "metadata-from": No such page "_space_variables"
 between SIP Trunk Provider and PBX

Configure a SIP Trunk With IP PBX

Unable to show "metadata-from": No such page "_space_variables"
 for Microsoft Teams Direct Routing

Configuring Microsoft Teams Direct Routing

 


Prepare Azure Active Directory Domain Services

  1. Configure Azure AD Domain Services. Refer to: Create and Configure an Azure Active Directory Domain Services instance.
  2. 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.

    1. Take note of the "Secure LDAP External IP Address" or the FQDN that you associated. In this example, ldaps.domain.com is used.

    2. Add the SBC Public IP address to the Azure AD Domain Services Network Security Group (AADDS-domain.com-NSG).

  3. Create a user in Active Directory with the correct "AAD DC Administrators". This user is used to query Azure AD from the 
    Unable to show "metadata-from": No such page "_space_variables"
    to read the Azure AD information. In this example, admin@domain.com is used.

Step 2: Configure 
Unable to show "metadata-from": No such page "_space_variables"
for Azure Active Directory

Verify Active Directory License

Active Directory based call routing can be preformed only with an AD feature license. Verify this license is installed as follows:

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, go to System > Licensing > Current Licenses.
  3. Verify that the Active Directory feature is licensed.

    View Active Directory License


    For detailed information on licenses, refer to: Node-Locked Licensing.

Create/Configure Domain Controller

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, go to Auth and Directory Services > Active Directory > Domain Controllers.
  3. Click the Add Domain Controller icon at the top of the Domain Controllers Table page.
  4. Add a domain controller per the parameters below. For details on creating a Domain Controller, refer to Adding and Modifying Domain Controllers.

  5. Click OK.

    Domain Controller Screen

    Domain Controller Configuration

    AttributeValue
    DescriptionAzure 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 TypeCall 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 Timeout5
    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 RolePrimary
    DC Priority1

Create/Configure Active Directory

Create and configure an Active Directory entry as follows:

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, go to Auth and Directory Services > Active Directory > Configuration.
  3. Configure the settings per the table below. For details on Active Directory, refer to Configuring the SBC Edge Portfolio for Active Directory.
  4. Click Apply.

    Active Directory Screen

    Active Directory Configuration

    AttributeValue
    AD EnabledTrue
    Use TLSTrue
    Operating ModeUpdate
    Query/Cache AttributedisplayName, telephoneNumber
    Nested Group Lookup for AuthenticationTrue
    Normalize CacheFalse
    Update Frequency1440
    Configure Initial Update TimeFalse
    AD Backup Failure AlarmEnable
    Encrypt AD CacheTrue

Verify Telephone Number in AD Query 

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:

  1. In the WebUI, click the Diagnostics tab.
  2. In the left navigation pane, go to Tools > Query AD Cache.
  3. In the Property to Match drop down list, select telephoneNumber.
  4. In the Value to Match field, enter the Skype user's telephoneNumber (i.e:+12122139087)
  5. Click OK.
    The query should return results similar to those shown below. 

    Query Results


    If the request is failing, LDAPS may be denying the ACL that protects the Logical Interface for Teams. Create the following rules:

    On the Outbound ACL, create the rule with the following parameters (ensure this rule is higher than "Deny All" rule):

    Outbound ACL

    Outbound ACL Configuration

    Attribute Value
    DescriptionOutbound LDAPS Request
    ProtocolTCP
    ActionAllow
    Port Selection MethodRange
    Source IP Address<IP Address of your logical interface>
    Source Netmask255.255.255.255
    Source Minimum Port Number0
    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

    On the inbound ACL, create the rule with the following parameters (ensure this rule is higher than "Deny All" rule):

    Inbound ACL

    Inbound ACL Configuration

    Attribute Value
    DescriptionOutbound LDAPS Response
    ProtocolTCP
    ActionAllow
    Port Selection MethodRange
    Source IP Address<"Secure LDAP External IP Address">
    Source Netmask255.255.255.255
    Source Minimum Port Number636
    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.

Step 3: Configure SBC for Active Directory Routing

Create/Configure Transformation Tables

A Transformation table contains a list of entries that contain routing rules. Two Transformation table entries are required:

  • Entry for the Called Number to match the format used in Azure AD.
  • Entry to search for the formatted value in the phoneNumber Active Directory user attribute stored in the local Azure AD cache.

Create the Transformation Table entries as follows:

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, go to Call Routing > Transformation.
  3. Create a Transformation table called From SIP-Trunk to Teams user.  For details, refer to Managing Transformation Tables.

  4. In the left navigation pane, select the Transformation Table created in the previous step.
  5. 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

    AttributeValue
    Match TypeMandatory
    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

    AttributeValue
    Match TypeMandatory
    Input Field Type
    User Value 1
    Input Field Value
    =telephoneNumber=
    Output Field Type
    Called Address/Number
    Output Field Value
    =telephoneNumber=


Create/Configure Call Routing Table

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, go to Call Routing > Call Routing Table > From SIP Trunk
  3. Add a new entry as follows: 

    Call Routing Table

    Call Routing Table Entries

    AttributeValue
    DescriptionTo Teams Users
    Number/Name Transformation TableFrom SIP-Trunk to Teams user
    Destination Signaling GroupsMicrosoft Phone System

  4. Reorder this Routing table to have this new rule on TOP of the rule going to the PBX.

    Routing Table - Example

Step 4: Migrate a User to Microsoft Teams

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 

Unable to show "metadata-from": No such page "_space_variables"
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.

  1. Access Office 365 admin portal.
  2. Access to Users > Active Users.
  3. Select the user you previously migrated to Teams.
  4. Enter the user phone number in Phone Number field. 

    Active User Example


Step 5: Verify Call Routing using AD Attributes

Call Type: Call going to a Teams user

To properly verify the

Unable to show "metadata-from": No such page "_space_variables"
's configuration, please review these steps are completed. See figure below.

  1. A SIP Trunk dials the user's number (12122139087).
  2. The call reaches the SIP inbound Signaling Group on the
    Unable to show "metadata-from": No such page "_space_variables"
    .
  3. The call is then sent to the relevant Call Route Table Entry.
  4. 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.

  5. 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

Call Type: Call going to a PBX user

To properly verify the SBC configuration, please follow these steps:
  1. A SIP Trunk dials the user's number (10001001004).
  2. The call reaches the SIP Inbound Signaling Group on the SBC.
  3. The call is then sent to the relevant Call Route Table Entry.
  4. 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

  • No labels