DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

In this section:

Related articles:


The SBC Core supports Flexible Active Directory (AD) functionality for large enterprises with a bigger subscriber base to provide 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 the following:

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

As LDAP is a known slow response protocol, 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 manage various call parameters and routing logic.

 Flexible AD configurations are classified into two categories:

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

Figure 1: 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 the Configuration Guide.

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.

Figure 2: 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.

Figure 3: Subscriber Information Use Cases


 

DM/PM of AD Attributes

The SBC has a "Transformation Table" that performs number manipulations. This table is configured so that any of the parameters input in the table are modifiable using regular expression or replaced by values of any AD attributes. For example, an AD lookup is done on the Called Number. If it is a success, then the called number is modified to the value that is present in the "mobile" AD attribute or "msRTCSIP" AD attribute received in the AD lookup. Similarly, you can change the calling number to the "displayname" AD attribute. The DM/PM is enhanced to reflect the flex AD attributes that are configured at the SBC-ERE.

The flexible AD attributes are available to the DM/PM rules when AD service is invoked. This is applicable for both "In" and "Out" DM/PM.

Prior to this release, the pre-defined AD attributes in the SBC are available for DM/PM. With the SBC enhancement of flexible AD attributes, the dynamically configured AD attributes are also available for DM/PM.

Flexible AD Attributes for CPFP

The Flexible AD attributes for CPFP involves the following:

  • In addition to the pre-defined AD attributes, the flexible AD attributes are options are available at CPFP to influence the routing decisions.
  • The flexible AD attributes are dynamically available to CPFP for routing (for example; standard routing , username routing) decisions.
  • The SBC-ERE presents the complete calling number for outbound calls to the mobile subscriber who is a part of enterprise. This takes higher precedence than the other outbound calls requirements
  • The SBC-ERE uses the "UnixHomeDirectory" AD attribute, if present as the calling number for outbound calls.
  • The SBC-ERE uses a desired number as the calling number for outbound calls, if "UnixHomeDirectory" AD attribute is not available.
  • The SBC-ERE uses the "info" AD attribute, if present to route the call for the called number.
  • The SBC-ERE uses the "msRTCSIP" AD attribute if present to route the call for the called number, provided the "info" AD attribute is not available.
  • The SBC-ERE routes the call as per the existing routing mechanism if both "info" and "msRTCSIP" AD attributes are not preset for called number.
  • The SBC-ERE uses the management interface to query the AD server
  • The SBC-ERE supports VLAN tagging while communicating with the AD server.

Platform Changes

The Flexible AD functionality is applicable for SBC with ERE (SWe and hardware-based).

Capacity Changes

The SBC-ERE supports a minimum of 100,000 subscriber entries.