In this section:

Related articles:

Profiles - Number Translation Criteria

Servers - CLI

Request System - CLI

Show Status System

Show Status Global

Number Translation Criteria - CLI

all Routing: System Provisioning - Profiles

Global - Servers

System - Admin

All - System 

Global - Policy Server

Profiles - Number Translation Criteria

The SBC Core supports Flexible Active Directory (AD) functionality for large enterprises with a bigger subscriber base to provide a better call capacity solutions.

It is a mechanism to retrieve user/subscriber data, used in call-routing/policy decisions, stored in Microsoft Active Directory (AD), eliminating the need to configure the same again on the SBC/PSX. This reduces the administrative overhead of provisioning and managing the user information at two places. The ERE retrieves the subscriber information by querying the Active Directory database,

The subscriber information includes:

  • Subscriber Identity
  • Display name
  • Home phone number
  • Mobile phone number
  • Office/Lync phone number

LDAP is a known slow response protocol, and hence, the SBC fetches the data from the remote server and stores it in the local database instead of querying real time to the remote server. This data is later used during calls to manipulate various call parameters and use them in routing logic.

 Flexible AD configurations are classified as follows:

  • Configuration to Sync Data from Remote Server
  • Synced data use during call processing

AD Query Process Flow

The ERE performs the following steps to communicate to the configured Active Directory servers and load the data into the local database.

  1.   Fetch the AD Profile information which is enabled.
  2.   Fetch the AD Attribute Profile configured in the AD Profile.
  3.   Fetch the each domain controller information configured in the AD Profile.
  4.   If the useTLS flag is enabled, then openLDAP queries over TLS. 
  5.   Perform LDAP query to the domain controller.
  6.   Read the LDAP response and format it and write into the file. If the response has more pages, then it reads all the pages, format it and write into the file.
  7.   Repeat the step 3 to step 6 for all the domain controllers, if multiple domain controllers are present.
  8.   Fetch the postgres database table and load the file containing LDAP response.
  9. Update the inUse table name to the new table in AD Profile Status.

AD Query Process

AD Sync

The SBC fetches the data from remote server in the following ways:

  • Manual Sync - This option is provided to trigger manual sync request on a condition the AD Profile sync attribute is enabled.
  • Delayed Sync -This parameter is configured in AD Profile and is a date and time string parameter. This value is always greater than current system time during configuration. So when the system time is equal to the configure date and time, the SBC triggers to fetch the data from remote AD server when the AD Profile sync attribute is enabled.
  • Sync Interval – This parameter is configured in the AD Profile and its value is in the range of 60 minutes to 43200 minutes (30 Days). This gets triggered only after a successful sync due to delayed sync configuration.
     For example,
     If the delayed sync is configured as 6th March, 02.45 AM and sync interval is configured as 1440 minutes (24 hrs),
    then
    the delayed sync is triggered at the time configured and from that time this sync interval time. In other words, 1440 minutes is calculated. So at 7th March, 02.45 AM the SBC trigger the sync request again. This sync interval triggers the sync operation at regular interval.

For more information to fetch the data from the remote server, refer to < Configuration Guide page.The list of all the required configuration is in this page Flex AD Support SBX-72926 : TOI>

Ad Storage

The SBC queries the Active Directory and gets all the attribute information and stores into the postgres database. These attributes are added dynamically using the json datatype in postgres, allowing the data to be stored in a flexible manner easily accessible. The SBC uses two tables for HA mechanism so that whenever there is an AD sync , the SBC stores into the other table and making that table also accessible.

AD Lookup

A new lookup type and service type is added to Number Translation Criteria (NTC) and service definition respectively. In a prerouter layer, the PES looks for services to be executed. If an AD lookup type matches the service definition,it is executed as follows:

  1.   Perform In DM/PM rule configured in the NTC.
  2.   Fetch the CallParameterFilterProfile Group configuration and form a dynamic query.
  3.   Fetch the data from the inUse ad user info table.
  4.   Perform Out DM/PM rule configured in the number translation criteria.
  5.   Perform routing.

AD Lookup

 Use Cases

The subscriber information retrieved from Microsoft AD is enabled in the following use cases.

  • Forwarding the calls to other numbers of the user based on policy 
    • The ERE translates the dialed number with users Home / Mobile or Lync phone numbers for completing the calls based on policy configurations,
  • Populating caller Display name
    • The ERE queries the display name based on AD users Mobile or Home phone number and set the same in policy response. The called party can see caller name, even when caller name is not set by PSTN network.
  • Determining AD Subscriber has Lync voice line or not
    • ERE queries the subscriber information to determine, whether user has Lync voice (msRTCSIP-Line) or being served by the PBX infrastructure. This information is then used to route the calls appropriately to Microsoft Lync or ERE.

Subscriber information Use Cases

overview.bmp