вторник, 7 апреля 2015 г.

ИНТЕГРАЦИЯ LYNC SERVER 2013 С АТС PANASONIC TDE600

C выходом Lync Server 2010/2013 особое распространение получила интеграция Lync c телефонными сетями общего пользования, что позволило в ряде случаев заменить корпоративные PBX (АТС) на решение, построенное с использованием Lync Server 2013. Замена PBX и настройка телефонии на софтовых решениях достаточно серьезная задача, т.к. требует понимания основ телефонии, знакомства с аппаратными решениями (шлюзами) ну и знание самой софтовой АТС (в нашем случае Lync). В рамках данной статьи я расскажу об интеграции Lync Server 2013 в организации, уже использующей PBX PANASONIC TDE600, останавливаясь на ключевых моментах и сложностях, которые могут возникнуть в процессе подобной интеграции. Данная статья не является пошаговой инструкцией, ее задача раскрыть концепцию подобных интеграций и описать точки соприкосновения двух систем.

Существующая топология
Изначально в организации использовалась телефония, реализованная на базе гибридной АТС Panasonic TDE600. Связь с телефонной сетью общего пользования (PSTN) осуществлялась через поток Е1. Соответственно, у сотрудников на рабочих местах стояли цифровые телефоны, каждый сотрудник имел аппарат и внутренний номер, закреплённый за ним. В плане IT-инфраструктуры организация уже имела такие сервисы, как Active Directory, TMG 2010, Exchange 2013.
То есть в компании присутствовало две несвязанных между собой структуры – офисная телефония и IT-инфраструктура:
Схема_было
Поставленная задача
Поставленная задача требовала объединить воедино существующую телефонию на PBX и телефонию, реализованную через новую установку Lync Server 2013. Главная цель всей операции заключалась в расширении рамок офисной телефонии и необходимости сделать так, чтобы сотрудники не были привязаны к рабочему месту и могли пользоваться телефонной связью, даже если они находятся вне офиса. Собственно, это не отменяло потребности в мессенджере, аудио-видео и веб-конференциях, возможности использования VoIP связи на мобильных устройствах.
Требуемые ресурсы
Для выполнения поставленной задачи понадобилось следующее:
Медиа-шлюз AudioCodes Mediant 1000;
Медиа-шлюз. Проблема в том, что Lync как софтовое решение имеет только один интерфейс взаимодействия – Ethernet. А как видно по предыдущей схеме телефония приходила в организацию по каналу E1, который ну никак напрямую в Lync не завернуть. Медиа-шлюз необходим для интеграции с телефонными сетями общего пользования. По сути, шлюз — это конструктор Lego, состоящий из шасси и набора плат расширения (E1/FXS/FXO). Задача шлюза преобразовывать сигнал, полученный с Lync по протоколу TCP и передавать его либо оборудованию телефонного провайдера, либо на PBX, но уже по интерфейсу E1. Взять абсолютно любой шлюз вы не можете, т.к. гарантии его работы не даст никто, равно как и не даст инструкций по его настройке. Существует строго определенный список шлюзов, которые прошли сертификацию на предмет работы Lync Server. В нашем случае выбор пал на модель AudioCodes Mediant 1000 в конфигурации с одним E1 портом.
image
Таблица 1. Список поддерживаемых медиа-шлюзов
Виртуальная машина под Lync Server 2013 Standard Front End;
Это «сердце» инфраструктуры Lync. Все внутренние клиенты регистрируются на нем, именно поэтому его так же называют «sip registar». В нем сосредоточены основные роли, которые дают возможность обмениваться IM сообщения, делать аудио звонки VoIP, делать видео звонки и организовывать конференции. Правда делать это все исключительно со внутренних клиентов. В том числе на Lync Server 2013 Standard Front End находится очень важная в этом развертывании роль — Mediation, отвечающая за голосовую связь через телефонные сети общего пользования, а точнее за коммуникации со шлюзом. Данная роль занимается перекодированием голоса и преобразования трафика с SIP over TLS в SIP over TCP, который понимает шлюз. Данная роль может стоять отдельным серверов, но в том случае если количество одновременных звонков превышает 226 штук. В нашем случае такое количество не предвидится, а поэтому роль отдельно не выносилась.
Системные требования к оборудованию для развертывания данного виртуального сервера были следующие:
  • 4 логических процессора с частотой 2,26 ГГц или выше;
  • 20 Гб оперативной памяти;
  • 10000 RPM жесткие диски со свободным объемом в 200 Гб;
  • Сетевой адаптер со скоростью подключения 1 Гигабит/с.
Официальные системные требования Microsoft несколько выше, но они рассчитаны на 2500 человек даже в виртуальной среде. В данном решении системные требования подбирались из расчета текущих потребностей, учитывая количество пользователей и планируемый запас.
Виртуальная машина под Lync Server 2013 Standard Edge;
В отличие от Exchange в Lync роль Edge является обязательной и отвечает за подключения внешних клиентов. Edge нужен для того чтобы клиенты могли подключаться с любой точки земли, имеющей доступ к интернету. Также роль Edge отвечает за федерацию, т.е. обеспечивает связь с другими организациями, где установлен Lync, с клиентами Office 365 и Skype и внешними клиентами Lync Mobile.
Для развертывания Lync Edge необходимо иметь 3 «белых» IP-адреса, связано это с тем, что разные сервисы используют один и тот же 443 порт. Поскольку сервисы разные, а порт одинаковый, приходится сажать их на разные IP адреса.
  • Системные требования под пограничный виртуальный сервер:
  • 4 логических процессора с частотой 2,26 ГГц или выше;
  • 20 Гб оперативной памяти;
  • 10000 RPM жесткие диски со свободным объемом в 200 Гб;
  • Сетевой адаптер со скоростью подключения 1 Гигабит/с или выше.
Reverse Proxy
В качестве Reverse Proxy использовали уже имеющийся сервер TMG 2010. На нем осуществлялась публикация сервисов, путем настройки правил. Reverse Proxy имеет несколько важных задач, первая из них это подключение мобильных клиентов Lync. Lync клиент на мобильных телефонах подключается через Reverse Proxy и только потом гонит медиа трафик через Lync Edge. Кроме этого Reverse Proxy позволяет публиковать наружу адресную книгу Lync и дает доступ из интернета к содержимому конференций.
Сейчас данный продукт не продается, а поэтому в тех компаниях, где TMG не присутствовало изначально можно использовать IIS ARR. Под этот сервер в компании используется следующая конфигурация:
  • 8-миядерный Xeon 3,5 ГГц;
  • 16 Гб оперативной памяти;
  • 10000 RPM жесткие диски;
  • Несколько сетевых интерфейсов.
Таким образом, у нас получилась схема будущего решения:
2c392e68d7ef.png
Внутренние клиенты (неважно какие) всегда регистрируются на Lync 2013 Front End, который дает практически полный функционал внутри сети. Все внешние клиенты регистрируются на Lync 2013 Edge, более того Edge позволяет общаться с внешним миром. Роль Mediation совмещена с Lync 2013 Front End и настроена на использование медиа-шлюза, который в свою очередь по E1 каналу подключен к PBX, имеющей доступ также по E1 к телефонной сети. Как видно из схемы, число возможных клиентов Lync значительно больше, чем было доступно при использовании только АТС и стационарных телефонов.
Физика объединения с АТС
Физическое подключение медиа-шлюза к АТС осуществляется по витой паре, только обжатой особым образом – кроссом. Схему обжима ниже:
image
Таким образом, обжимаются контакты 1,2,4,5 перекрестно. Чтобы выход с АТС приходил на вход шлюза и наоборот. Но это только первый шаг. Чтобы АТС и шлюз увидели друг друга необходимо было провести основные настройки на шлюзе. Вначале на шлюзе меняются настройки потока E1:
image
  • Тип протокола выбрали ISDN. В принципе, это стандарт для российских провайдеров Е1.
  • Clock Master в режиме Recovered, т.е. мы шлюз синхронизируем с генератором на стороне АТС.
  • Framing Method – режим разделения на кадры выбран, как указано на скриншоте. Если выбрать неправильный режим, то разбиение потока на кадры будет неправильным.
  • Termination Side выбран на стороне сети, а не шлюза.
Также нужно настроить маршрутизацию на медиа-шлюзе, чтобы у нас исчезла ошибка синхронизации D-канала. Самое главное – указать внутренний адрес нашего Lync Front End.
image
image
Соответственно, теперь Mediant знает, что данные, которые приходят с АТС надо направлять на Lync Front End и наоборот. После этих манипуляций ошибки синхронизации D-канала ушли и статус порта Е1 на Mediant’е должны загореться зеленым.
Публикация шлюза в топологию
Для интеграции с PSTN серверу Lync надо рассказать о существовании медиа-шлюза и о том, что он может отправлять и принимать телефонные вызовы через него. Для этого в топологию Lync нужно добавить объект  PSTN Gateway и переопубликовать топологию. Физически медиа-шлюз – это как раз наш Mediant. Там же указываем, какой порт по TCP будем слушать:
image
Настройка плана набора номера и настройка транка
Напомню, что весь телефонный трафик идет через АТС и на Lync-сервере мы должны подстраиваться под нее. Поэтому на транке (для сервера Lync транком является медиа-шлюз) настраиваем отправку телефонного номера (нормализованного) в вид, понятный АТС для выхода в город (в нашем случае, через «9»). Т.е АТС в нашем случае принимает номера начинающиеся «98ХХХХХХХХХХ», а Lync работает с форматом E.164, т.е для России «+7ХХХХХХХХХХ». Поэтому преобразования на транке меняют вызываемый номер так, чтобы его приняла АТС.
image
Как видно из скриншота, если нормализованный номер начинается на «+7», то Lync меняет его начало на «98». Т.е. номер «+74951234567» будет преобразован в «984951234567» для отправки на транк. В таком виде АТС сможет его корректно пропустить.
Теперь попробуем разобраться, как привести номер, набираемый пользователем в Lync’е в такой формат, который будет понятен серверу. Это должен быть формат «+7ХХХХХХХХХХ» для городских и мобильных номеров, а для внутренних стационарных телефонов это «ХХХ» (кроме «3ХХ»), а для звонка абоненту Lync по внутреннему номеру «+74955555555;ext=3XX». Поскольку Lync требует E164, а пользователи могу набирать как угодно (без +, без +7, начиная с 8) делаются правила нормализации, суть которых привести набираемый пользователем номер к формату E.164.  Реализуется такая нормализация в настройках плана набора номера, путем добавления правил.
image
  • Первое правило создано для нормализации набираемого трехзначного номера абонента Lync (начинающегося с тройки) в формат, который задан у пользователя в LineURI.
  • Второе правило говорит серверу, что для звонка на стационарный телефон 3 набранные цифры добавочного номера должны отправляться без изменений.
  • Оставшиеся 3 правила созданы для удобства пользователей, чтобы автоматически добавлять «+7» перед номером, если он начинается с кода города/оператора, добавлять «+» перед семеркой, если его не ввел пользователь, и менять «8» на «+7», если номер был введен с восьмеркой.
Чтобы иметь возможность ограничивать определенных пользователей в звонках на городские и мобильные телефоны создано 2 политики. Каждая использует свой маршрут:
image
Первый маршрут разрешает звонки только на внутренние стационарные телефоны сотрудников компании и на номера абонентов Lync (если введены 3 цифры номера, то звонок идет по маршруту «Внутренние»). Для всех остальных звонков, включая мобильные и городские номера звонок идет по второму маршруту. Это позволяет компании избежать лишних трат.
Настройка нормализации номера на медиа-шлюзе
Вся нормализация у нас происходит на стороне Lync Front End, значит, на шлюзе не надо производить никаких манипуляций с номером и отдавать/принимать в том же виде, в каком номер пришел на шлюз.
Единственное, что нужно, это обозначить адрес и порт нашего Front End и указать для номеров «*», т.е. любой номер. У нас одна Trunk-группа на медианте, которая использует только один порт Е1:
image
Ее мы и будем использовать для маршрутизации входящих и исходящих звонков. Настройки маршрутизации видны на скриншотах ниже.
Для исходящих звонков:
image
И для входящих:
image
Грубо говоря, единственное, что делает медиа-шлюз – это преобразует голосовой трафик в формат, понятный АТС и Lync-серверу.
Настройка АТС
Корректная настройка АТС может занять много времени, т.к. содержит тонкие моменты, которые надо учитывать для правильной работы связки LyncFE+Mediant1000+TDE600.
Первое, на что надо обратить внимание – настройка CO-линии:
image
«Наша» плата Е1 установлена в 7й слот, ее мы и будем настраивать. Номер абонента, соответственно, тот городской номер, который выдал провайдер, без указания кода города. Самое важное здесь – выбрать тип исходящего вызова: нам нужен En-bloc. Этот тип ждет, пока будет введен весь номер и целиком его отправляет – режим последовательного добавления цифр нам не подходит, т.к. он будет обрезать 1-2 цифры номера и возникнут проблемы.
Следующим шагом будет настройка плана набора номера. Нам выделили свободный пул добавочных номеров, начинающихся на «3». Т.к. удалять нам ничего не надо, то просто его определяем:
image
И сохраняем это как таблицу плана набора под номером «4».
В настройках группы СО указывает соответствие плана набора группе внешних линий:
image
Наш поток Е1 до медианта воспринимается, как группа внешних линий. Мы выбрали 12 группу и определили первые цифры номера (для абонентов Lync):
image
Остается еще указать соответствие номеров СО линий определенному слоту с картой (наш 7й) и указать номер группы внешних линий (наш 12):
image
Очень удобная утилита для проверки работы встроена в консоль управления АТС – называется «Трассировка протокола ISDN/QSIG (A) ». Мы можем собрать лог звонка и посмотреть, в каком виде идут вызовы. Вот пример входящего звонка на городской номер компании и вызов абонента Lync:
image
Заключение
После всех манипуляций и настроек были реализованы следующие сценарии звонков:
  1. Из Lync’а в Lync;
  2. Из Lync’а на добавочные номера стационарных телефонов сотрудников;
  3. Из Lync’а на городские и мобильные телефоны;
  4. Со стационарных офисных телефонов абонентам в Lync;
  5. С городских и мобильных телефонов абонентам в Lync;
В рамках данной статьи я постарался рассказать об основных тонкостях и проблемах, которые могут возникнуть при интеграции Lync Server 2013 и АТС Panasonic TDE600. Она не претендует на Step-by-step инструкцию, но может помочь при внедрении и уменьшить потраченное на него время.
Ахмадуллин Марат
MCSE: Messaging

Комментариев нет:

Отправить комментарий