Audiocodes + Lync 2013 + провайдер, не поддерживающий History-info

В ходе работы над проектом внедрения Lync 2013 я столкнулся с проблемой, связанной с переадресацией (Call Forwarding) и одновременным вызовом (Simultaneous Ring). Тестовая группа жаловалась на то, что не работает переадресация.

Траблшутинг выявил, что данная проблема существует в определенных сценариях. Проблема связана с тем, что провайдер не маршрутизирует исходящиe вызовы, где номер звонящего (calling number) не входит в пул номеров, предоставленный клиенту.

Подробное описание и решение проблемы — под катом.

Описание проблемы


Схема стыковки Lync инфраструктуры с телефонией:



На схеме показаны:
  • АТС Nortel CS1000;
  • Audiocodes Mediation 1000, v 6.60;
  • Lync 2013 c совмещенными ролями Front End, Mediation.


На следующей схеме показаны возможные сценарии переадресации вызовов.


Условные обозначения:
  • N – АТС Nortel;
  • A – Audiocodes;
  • N1, N2 – абоненты АТС Nortel;
  • L1 – Lync абонент (Lync сервер намерено не изображен для упрощения схемы);
  • P – Провайдер телефонии;
  • E1, E2 – Внешнии абоненты;
  • Красной рамкой выделен абонент на которого переадресованы вызовы с абонента Lync.


В сценарии #3 провайдер «режет» исходящий звонок от организации, так как calling number «E1» не зарегистрирован за организацией. По хорошему, провайдер должен отработать вызов по соответствующему маршруту и сделать запись в билинговой системе согласно полю History-info. Но в нашем случае, провайдер не принимает поле HISTORY-INFO, работа билинговой системы провайдера построена только на атрибутах FROM, TO.

От Lync Mediation на Audiocodes приходит следующий SIP Invite запрос:

FROM: <sip:"E1";phone-context=enterprise@domain.net;user=phone>;epid=7B11BD1265;tag=8c9e1f2146
TO: <sip"E2"@voice_gw.domain.net;user=phone>CSEQ: 329 INVITE
HISTORY-INFO: <sip:"L1"@lyncmediation1.domain.net;user=phone>;index=1;ms-retarget-reason=forwarding,<sip:"E2"@lyncmediation1.domain.net;user=phone>;index=1.1


Постановка задачи


Варианты решения:
  1. Переработать билинговую систему провайдера;
  2. Создать маршрут со специальным префиксом, активировать на нем параметр «Скрыть идентификатор звонящего» (Suppress caller ID) и задать «Дополнительный идентификатор звонящего» (Alternate caller ID). Рекомендовать пользователям вводить номер для переадресации с назначенным префиксом:



  3. Использовать функцию «SIP Message Manipulation Rule», как описано здесь. (аналогичное решение было предложено поддержкой вендора).


Первый вариант даже не стали пробовать.

Второй и третий вариант дают больше минусов, чем плюсов. Исправляется сценарий #3, но при этом теряется полезный функционал в сценариях #1, 2, 4 – все переадресованные вызовы приходят с номера, на котором активирована переадресация.

Было принято решение использовать третий вариант, доработав его.

Необходимо, используя Message Manipulations Rule, заменить значение поля FROM c sip:«E1» на sip«L1» для сообщений, где “E1” и «E2» внешние номера.

Для остальных сценариев данное правило не должно применяться, так как это приведет к потере функциональности. Абонент, получающий переадресованный вызов, не будет видеть действительный caller-id вызывающего.

Таблица активации правила подмены calling number:
# FROM Forward TO(History-info) IsRuleNeedToBeApplied
1 internal interna FALSE
2 external internal FALSE
3 external external TRUE
4 internal external FALSE

Пояснение к таблице:
  • Правило замены должно активироваться только в случае когда вызывающий номер и номер переадресации внешние.
  • Internal eq +7717212XXXX, номера зарегистрированные за организацией.
  • External not eq +7717212XXXX, номена не зарегистрированные за организацией.
  • #1. Правило применять не нужно, так как маршрутизация осуществляется внутри организации. Фильтр провайдера не задействован.
  • #2. Правило применять не нужно, так как CallingNumber (FROM) зарегистрирован за организацией. Фильтр провайдера задействован, но не блокирует вызов.
  • #3. Правило применять не нужно, так как маршрутизация осуществляется внутри организации. Фильтр провайдера не задействован.
  • #4. Правило необходимо применить. Фильтр провайдера задействован, вызов будет заблокирован, если не произвести подмену CallingNumber (FROM).


Решение


Конфигурация:
  1. Открыть страницу INI параметров по адресу x.x.x.x/AdminPage. Задать SetID, для этого в поле Parameter Name ввести GWINBOUNDMANIPULATIONSET, в поле Enter Value соответствующий номер SetID.



  2. Создать правила, описанные в следующей таблице, по адресу VOIP > SIP Defenitions > Message Manipulations.




Таблица правил:
Indx ID MsgType Condition ActSubj ActType ActValue RowRole
1 1 invite header.history-info regex (sip:\+7(717212....)@) var.call.src.0 modify $2 0
2 1 invite header.to regex (sip:(?!717212)(.*)@) var.global.0 modify '1' 0
3 1 invite header.from regex (sip:(?!717212)(.*)@) header.from.url.user modify var.call.src.0 0

Правило №1 проверяет есть ли заголовок HISTORY-INFO, формирует группу, соответствующую шаблону внутреннего номера, записывает эту группу в переменную var.call.src.0. Данная переменная будет использоваться в 3-м правиле для подмены calling number в заголовке header.from.url.user.

Правило №2 проверяет заголовок TO на наличие внешнего номера. Используется функция regex “Negative lookahead”, которая исключает локальные номера по префиксу 717212. В случае положительного результата записывается переменная var.global.0. Данная переменная не несет ни какой роли.

Правило №3 проверяет заголовок FROM на наличие внешнего номера. Используется функция regex “Negative lookahead”, которая исключает локальные номера по префиксу 717212. В случае положительного результата используется переменная var.call.src.0, записанная на шаге 1, для подмены called number в заголовке header.from.url.user.

Результат


В сценарии #3 calling number подменяется на номер инициатора переадресации.
В остальных сценариях calling number не изменяется.

Приложение 1. Листинг конфигурации


GWINBOUNDMANIPULATIONSET = 1
[ MessageManipulations ]
FORMAT MessageManipulations_Index = MessageManipulations_ManSetID, MessageManipulations_MessageType, MessageManipulations_Condition, MessageManipulations_ActionSubject, MessageManipulations_ActionType, MessageManipulations_ActionValue, MessageManipulations_RowRole;
MessageManipulations 1 = 1, "invite", "header.history-info regex (sip:\+7(717212....)@)", "var.call.src.0", 2, "$2", 0;
MessageManipulations 2 = 1, "invite", "header.to regex (sip:(?!717212)(.*)@)", "var.global.0", 2, "'1'", 0;
MessageManipulations 3 = 1, "invite", "header.from regex (sip:(?!717212)(.*)@)", "header.from.url.user", 2, "var.call.src.0", 0;
[ \MessageManipulations ]


Приложение 2. Полезные ресурсы


  1. Quick Refence Guide. SIP Message Manipulation
  2. Regexr.com Online tool to learn, build and test Regular Expressions
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 2

    0
    Спасибо за решение!
      0
      Для проверки регулярных выражений я обычно использую Regex tracer — бесплатная программка, очень удобная.

      Only users with full accounts can post comments. Log in, please.