Manipulation of numbers through LDAP

When integrating different PBXs among themselves or when connecting to a telecom operator, the question often arises of how a large number of numbers can be converted. And in most cases there is no relationship between the numbers. Alternatively, you can use the number conversion table for this, but it does not look very nice, and management will not be the easiest in this case. The simplest, especially in the corporate market, is using the LDAP protocol for this purpose.

Why LDAP, and not some other mechanism, such as an external file. Everything is quite simple - AD is used in most companies as a corporate standard, where all the necessary information about employees is stored, namely, with their data, in this case, manipulations are required. So why create some kind of parallel database if it already exists in your infrastructure? Where and how such manipulations can be applied - there are a lot of options, I will only list the most popular ones I meet.

• FMC service, when your mobile operator is ready to give you your extension numbers to your PBX, but the mobile phone remains in the caller’s number. There may be a task in converting the employee's mobile number to the employee's internal number for correct display. Accordingly, we need to find the record in AD, with the corresponding mobile number, and substitute the internal number of this AD record as the caller's number.
• The process of migration from one PBX to another. You have two PBXs and your task is to smoothly migrate from one PBX to another, while you cannot migrate selected areas of numbers, but you need to migrate several numbers from a different range. In this case, several fields are used, where one PBX corresponds to one field, and the second PBX corresponds to the second field. Depending on which field the number is in, the call should be routed there.
• If we talk about Skype For Business functionality - Call via Work, then this functionality may simply be necessary, since with this functionality there may be a lot of tasks, how should the number be displayed when calling from Skype For Business on the PBX and under what number it should go this number is out.
• Well, those cases that may arise. And as my practice shows, requests, where it is convenient to use this functionality as a result, arise quite often.

Now how it is configured.

In order to make it clearer, we give the problem. You need the internal number of the employee 1234 in the outgoing number, replace it with his mobile phone 89997776655. The internal number of the employee is in the telephoneNumber attribute, and the mobile number is in the Mobile attribute.

In order to get started with LDAP, you need to enable the LDAP service on Mediant. To do this, open VoIP-> Services-> LDAP
')


LDAP Service - Enable, after which the gateway / SBC must be overloaded.

A very important point that needs to be determined right away is the LDAP Cache. That is, whether the gateway / SBC will remember the information that it received from LDAP or not. And if so, how often he will update it. This is done to ensure that with a large number of requests Mediant does not heavily load the LDAP server and process requests as quickly as possible.

After that, we need to configure a connection to the LDAP server. Go to: Configuration tab> VoIP menu> Services> LDAP> LDAP Configuration Table:



Here you can configure the IP address of the server and its purpose. I will describe only a number of parameters on this page, since most of the parameters are understandable by name:

1. LDAP Bind DN is the name of the account that is used to log into the LDAP server. It can be written in one of the following formats:
   
   • CN = Administrator, CN = Users, DC = domain, DC = com
   • administrator@domain.com
   • domain \ administrator
2. It is also important to choose what you use LDAP for (type parameter)
   
   • Control (default) - means that this server will be used to signal voice traffic. Actually, that option which we consider in this example.
   • Management - when this option is selected, the LDAP server is used to check the access authorization for the voice gateway control.

By default, Mediant does not use encryption, and authorization on the LDAP server occurs using the Simple method.
After successfully connecting to the LDAP server, it should have “Connected” status.

After connecting to the LDAP server, you need to configure the DN where the search will be performed. This is done in: Configuration tab> VoIP menu> Services> LDAP> LDAP Configuration Table.



At this stage, we configured the interface to the LDAP server and defined the area where we will search for objects. In order to do the conversion to SIP, you need to configure Call Setup Rules, where we define how we do the object search in LDAP and what attribute we get from LDAP.

LDAP rules are configured: Configuration tab> VoIP menu> Services> Call Setup Rules.



Here we describe each parameter separately:

1. Rules Set ID: The number of the rule set. Sometimes it is required to use several rules, in this case several rules are configured with one Rule Set ID.
2. Attribute To Query: Specifies the query string on the LDAP server. The syntax is pretty simple. All static data is entered in single quotes, all variables are entered without quotes. There must be a “+” sign between them. Example: 'telephoneNumber =' + param.call.src.user. The list of possible variable parameters is presented below.
3. Attribute to Get: The attribute that we are trying to get from LDAP for further work with it. In our example, this is a mobile phone number: mobile. This parameter is entered without quotes. If you want to get more than one attribute, in this case they are written separated by commas.
4. Condition: This parameter defines the condition under which this rule works. In our case it will be: ldap.attr.mobile exists. (The mobile attribute exists). Examples of other conditions:
   
   • param.call.dst.user == '1234'
   • ldap.found! exists (LDAP entry not found)
   • ldap.err exists (error while searching for LDAP)
   • Regular expressions can also be used.
5. Action Subject: Determines which call parameter we will modify. In our case it will be: param.call.src.user
6. Action Type: What we will do with this call parameter (Add / Remove / Modify / Add Prefix / Add Suffix / Remove prefix / Remove suffix / Exit (stop Rule Set ID and do not apply the following rules) / Run Rules Set (switch to another rule). In our case - Modify
7. Action Value: A parameter that determines what we will do. In our example, we need to substitute the source in the number - the mobile phone number: ldap.attr.mobile. The syntax for this parameter is identical to Attribute to Query. (If Exit is configured in the action type, then the value of this parameter must be false or true. That is, if a match is made, exit or not from the Rule Set ID).

The list of parameters that can be used:

• param.call.dst.user (destination number)
• param.call.src.user (caller number)
• param.call.src.name (caller name)
• param.call.redirect (call forwarding number)
• param.call.src.host (the domain of the call source is in the from field)
• param.call.dst.host (call destination domain - in the to field)

After we set up a manipulation rule, we must apply it for those calls where it is required. This is done in the call routing settings in the Call Setup Rules Set ID parameter. After that, the rule created by us will be applied to those calls that will be routed according to this rule, thus we can flexibly configure those cases when LDAP manipulation is required.
You can also use LDAP integration for the following tasks:

1. Authorization of access to Mediant only for users who belong to a particular group.
2. Call Routing
   
   • To route a call, based on which attribute the desired call parameter is in.
   • Parallel call to several directions for each attribute of the LDAP server.
   • Sequential calls to several numbers that are in the attributes of the LDAP server.