Манипуляция номерами через LDAP

При интеграции различных АТС между собой или при подключении к оператору связи очень часто встает вопрос, каким образом можно сделать преобразование большого количества номеров. Причем в большинстве случаев никакой взаимосвязи между номера нет. Как вариант, можно использовать для этого таблицу преобразования номеров, но выглядит это не очень красиво, да и управление будет не самое простое в данном случае. Самое простое, особенно на корпоративном рынке, это использование протокола LDAP для этой цели.

Почему именно LDAP, а не какой-то другой механизм, типа внешнего файла. Всё достаточно просто – AD используется в большинстве компаний как корпоративный стандарт, где хранится вся необходимая информация о сотрудниках, а именно с их данными в данном случае требуется производить манипуляции. Так что зачем создавать какую-то параллельную базу данных, если она уже есть в вашей инфраструктуре? Где и как можно применять такие манипуляции – вариантов огромное множество, я лишь перечислю самые популярные, с которыми я встречаюсь.

• Услуга FMC, когда у вас оператор мобильный связи готов подавать вам ваши внутренние номера на вашу АТС, но при этом в номере звонящего остается мобильный телефон. Тут может быть задача в том, чтобы мобильный номер сотрудника преобразовывать во внутренний номер сотрудника, для корректного отображения. Соответственно, нам надо найти запись в AD, с соответствующим мобильным номером, и подставить в качестве номера звонящего внутренний номер данной записи AD.
• Процесс миграции с одной АТС на другую. У вас стоит две АТС и ваша задача плавно мигрировать с одной АТС на другую, при этом вы не можете мигрировать выделенными областями номеров, а требуется мигрировать по несколько номеров из разного диапазона. В этом случае применяется несколько полей, где одному поле соответствует одна АТС, а второму полю соответствует вторая АТС. В зависимости от того, в каком поле находиться номер, туда и следует маршрутизировать вызов.
• Если говорить о новой функциональности Skype For Business – Call via Work, то тут данная функциональность может быть просто необходима, так как при данной функциональности может возникнуть массу задач, как должен отображаться номер при вызове со Skype For Business на АТС и под каким номером должен выходить этот номер во вне.
• Ну и те случаи, которые могут возникнуть. А как показывает моя практика, запросы, где в итоге удобно использовать данную функциональность, возникают достаточно часто.

Теперь о том, как это настраивается.

Для того, чтобы было нагляднее, приведем задачу. Надо внутренний номер сотрудника 1234 в исходящем номере, заменить на его мобильный телефон 89997776655. Внутренний номер сотрудника находится в атрибуте telephoneNumber, а мобильный номер находится в атрибуте Mobile.

Для того, чтобы начать работать с LDAP, надо включить сервис LDAP на Mediant. Для этого надо открыть VoIP->Services->LDAP



LDAP Service – Enable, после чего шлюз/SBC надо перегрузить.

Очень важный момент, который надо сразу определить, это LDAP Cache. То есть, будет ли запоминать шлюз/SBC информацию, которую получил из LDAP или нет. И если будет, то как часто он её будет обновлять. Делается это для того, чтобы при большом количестве запросов Mediant не сильно загружал LDAP сервер и максимально быстро отрабатывал запросы.

После этого, нам надо настроить соединение с сервером LDAP. Заходим: Configuration tab > VoIP menu > Services > LDAP > LDAP Configuration Table:



Тут настраивается IP адрес сервера и его назначение. Опишу только ряд параметров на данной странице, так как большинство параметров понятно по названию:

1. LDAP Bind DN – это имя учетной записи, под которым выполняется вход на LDAP сервер. Он может быть записан в одном из следующих форматах:
   
   • CN=Administrator,CN=Users,DC=domain,DC=com
   • administrator@domain.com
   • domain\administrator
2. Так же важно выбрать для чего вы используете LDAP (параметр type)
   
   • Control (по умолчанию) – означает, что данный сервер будет использоваться для сигнализации голосового трафика. Собственно, тот вариант, который мы рассматриваем в данном примере.
   • Management – при выборе данного варианта, LDAP сервер используется для проверки авторизации доступа на управление голосового шлюза.

По умолчанию Mediant не использует шифрование, и авторизация на сервере LDAP происходит по методу Simple.
После успешного подключения к серверу LDAP, у него должен быть статус “Connected”.

После подключения к LDAP серверу требуется настроить DN, где будет осуществляться поиск. Это делается в: Configuration tab > VoIP menu > Services > LDAP > LDAP Configuration Table.



На данном этапе мы настроили стык к LDAP серверу и определили область, где мы будет производить поиск объектов. Для того, чтобы делать преобразование в SIP, требуется настроить Call Setup Rules, где мы определяем, как мы делаем поиск объекта в LDAP и какой атрибут мы получаем из LDAP.

Правила LDAP настраиваются: Configuration tab > VoIP menu > Services > Call Setup Rules.



Тут опишем каждый параметр в отдельности:

1. Rules Set ID: Номер набора правила. Иногда требуется использовать несколько правил, в этом случае настраиваются несколько правил с одним Rule Set ID.
2. Attribute To Query: Определяет строку запроса на LDAP сервер. Синтаксис достаточно простой. Все статические данные вводятся в единичных кавычках, все переменные вводятся без кавычек. Между ними должен быть знак «+». Пример: 'telephoneNumber='+param.call.src.user. Список возможных переменных параметров представлен ниже.
3. Attribute to Get: Тот атрибут, который мы пытаемся получить из LDAP для дальнейшей работы с ним. В нашем примере, это мобильный номер телефона: mobile. Данный параметр вводится без кавычек. Если требуется получить более одного атрибута, то в этом случае они пишутся через запятую.
4. Condition: Данный параметр определяет условие, при котором данное правило работает. В нашем случае это будет: ldap.attr.mobile exists. (Аттрибут mobile существует). Примеры других условий:
   
   • param.call.dst.user == ‘1234’
   • ldap.found !exists (запись LDAP не найдена)
   • ldap.err exists (ошибка при поиске LDAP)
   • Так же могут применяться регулярные выражения.
5. Action Subject: Определяет какой параметр вызова мы будем модифицировать. В нашем случае это будет: param.call.src.user
6. Action Type: Что мы будем делать с данным параметром вызова (Add/Remove/Modify/Add Prefix/Add Suffix/Remove prefix/Remove suffix/Exit (остановить Rule Set ID и не применять следующие правила)/Run Rules Set (перейти на другое правило). В нашем случае – Modify
7. Action Value: Параметр, который определяет, что мы будет делать. В нашем примере, нам требуется подставить в номер source – номер мобильного телефона: ldap.attr.mobile. Синтаксис данного параметр идентичен Attribute to Query. (В случае, если в action type настроено Exit, то значение данного параметра должно быть false или true. То есть при совпадении производить выход или нет из Rule Set ID).

Список параметров, которые могут использоваться:

• param.call.dst.user (номер назначения)
• param.call.src.user (номер вызывающего абонента)
• param.call.src.name (имя вызывающего абонента)
• param.call.redirect (номер переадресации вызова)
• param.call.src.host (домен источника вызова – в поле from)
• param.call.dst.host (домен назначения вызова – в поле to)

После того, как мы настроили правило манипуляции, мы должны его применить для тех вызовов, где это требуется. Это делается в настройках маршрутизации вызова в параметре Call Setup Rules Set ID. После этого созданное нами правило будет применяться на те вызовы, которые будут маршрутизироваться по данному правилу, тем самым мы можем достаточно гибко настраивать те случаи, когда требуется манипуляция LDAP.
Так же интеграцию с LDAP можно использовать для следующих задач:

1. Авторизация доступа на Mediant только для тех пользователей, которые входят в определенную группу.
2. Маршрутизация вызовов
   
   • Маршрутизировать вызов, исходя из того, в каком атрибуте находиться требуемый параметр вызова.
   • Параллельный вызов на несколько направлений для каждого атрибута LDAP сервера.
   • Последовательный обзвон на несколько номеров, которые находятся в атрибутах LDAP сервера.