IT-блог компании "ЛанКей"

В предыдущих частях мы развернули Office Communications Server для компьютерных пользователей. Теперь подошло время начать потихоньку интегрировать его с телефонией.

За интеграцию с телефонией (с теми АТС, которые не умеют напрямую работать с OCS) отвечает специальная роль, называемая Mediation Server. Mediation Server занимается преобразованием звукового потока из форматов G.xxx в формат Microsoft RTAudio — собственный кодек Microsoft. А между Mediation Server и ATC будет находиться VoIP-шлюз.

Развертывание Mediation Server

Выделим серверу MEDIATION две сетевые карты. Одной сетевой картой он будет подключен к локальной сети — назовем это соединение Local, и присвоим соответствующий IP-адрес. Второй сетевой картой сервер будет подключен к VoIP-шлюзу. Я не выделял отдельного коммутатора, а подключал напрямую патчкордом. Назовем это соединение VoIP, и соответственно присвоим IP-адрес из подсети, определенной нами для VoIP-шлюза. Поскольку согласно заводским настройкам IP-адрес шлюза 10.1.10.10/16, то мы, не особо фантазируя, назначим сетевой карте адрес 10.1.10.1 и маску 255.255.0.0. DNS никакого не указываем. Чтобы не загружать соединение с шлюзом лишним ненужным трафиком — отключим на нем NetBIOS over TCP.

Вводим сервер MEDIATION в домен, и запускаем на нем программу установки Office Communications Server. Дополнительных ролей от сервера не потребуется. Выбираем Deploy other server roles — Deploy mediation server.

Install files for Mediation server — развертываем файлы на жесткий диск. Затем запускаем активацию сервера. Указываем пароль для существующей учетной записи службы (она у нас создалась на этапе развертывания сервера OCS). После активации данные о сервере появились в AD, но сам сервер еще не запущен — ему не сопоставлены сертификаты и не настроены адреса шлюза и сервера OCS.

Следующий шаг выполняется не из мастера установки, а из консоли настройки Office Communications Server 2007 R2. Можно конечно установить административные утилиты и на сервер MEDIATION, но, я думаю, это не имеет смысла — мы все будем конфигурировать централизованно. Поэтому переключаемся на сервер OCS и на консоль управления Office Communications Server.

В разделе Mediation Servers после обновления должен появиться наш свежеразвернутый сервер. Щелкаем на нем правой кнопкой и выбираем Properties.

В открывшемся окне мы указываем параметры, которые нужны серверу MEDIATION чтобы найти остальные серверы.

В поле Communications Server listening IP — мы указываем адрес той сетевой карты, которая подключена к локальной сети. В поле Gateway listening IP — мы указываем адрес той сетевой карты, которая подключена к сети VoIP-шлюза. В полях A/V Edge Server и Location profile мы пока ничего не указываем — потому что внешнего сервера еще пока нет, и голосовой профиль мы не конфигурировали.

Переходим на следующую страницу.

В поле FQDN мы пишем полное имя сервера OCS. Порт, по которому MEDIATION будет с ним связываться, оставляем неизменным — мы изначально на сервере OCS его не меняли. В поле PSTN Gateway Address вписываем IP-адрес VoIP-шлюза. Проверяем, что порт и метод подключения (TCP или TLS) соответствуют шлюзу. Мы шлюз не перенастраивали, поэтому оставляем эти поля как есть. Нажимаем OK. Соглашаемся с тем, что мы не указали Edge Server, location profile, и с тем, что изменения вступят после перезапуска Mediation Server.

Возвращаемся назад на сервер MEDIATION. Выбираем следующий шаг, запрашиваем и назначаем серверу сертификат на этот сервер.

После назначения сертификата возвращаемся в консоль управления на сервер OCS и запускаем сервер Mediation.

Сервер запустился. Правда, пока от него толку нет, потому что не настроена самая важная вещь — голосовая политика.

Голосовая политика организации

Голосовая политика определяет план нумерации в организации, определяет маршруты при звонках на городские номера, и, поскольку с точки зрения OCS, имеющиеся внутренние номера телефонов организации — тоже внешние, то политика определяет и методику связи с ними.

Допустим, у нас есть внешний телефонный номер +7 (495) 788-80-43, привязанный к АТС. Есть существующие телефоны, трехзначная нумерация — номера от 100 до 200. Выход в город производится через 9. Соответственно, междугородние звонки — 9-8-код города-телефон.

Мы хотим сделать, чтобы набранные в OCS трехзначные номера соединяли бы нас с внутренними абонентами, набранные семизначные — с городскими в коде города 495, начинающиеся с 8 — с междугородними или федеральными, и начинающиеся с + тоже звонили бы в город.

В соответствии с этим мы и начинаем планировать политику.

Запускаем консоль управления Office Communications Server, щелкаем правой кнопкой по Forest — Properties — Voice properties. На закладке Location Profiles щелкаем Add.

Важная тема — это название Location Profile. Если мы хотим нормально проинтегрировать OCS и Exchange UM — нам нужно правильно назвать Location Profile. Location Profile должен быть обязательно вида имя_профиля.имя_нашего_домена. Требования к пункту имя_профиля — такие же, как к любому корректному имени DNS — латинские буквы, цифры, без пробелов. Этот же идентификатор в дальнейшем будет использоваться как имя Exchange UM Dial Plan. Например, корректным в нашем случае будет назвать профиль — moscow.uc.ru.

Кроме имени профиля мы заносим более удобочитаемое имя в поле Display Text. Затем нам надо добавить Normalization Rules.

Правила нормализации

Именно Normalization Rules определяют телефонные номера, которые могут вводить пользователи OCS, и то, как они будут обрабатываться. Чуть выше мы вывели несколько желаемых исходящих маршрутов — на трехзначные номера в офисе, на семизначные в Москве, на федеральные и междугородние. Вот теперь и будем создавать такие правила нормализации.

Правила нормализации вводятся в виде исходное выражение - целевое выражение. Выражения записываются в виде .NET Regular Expresson. Полностью синтаксис я расписывать не буду — он есть в MSDN — а покажу его на примере наших маршрутов.

Первый маршрут — назовем его 3-digits — будет отвечать за дозвон на трехзначные номера телефонов, от 100 до 200. Сами трехзначные номера никак преобразовывать не надо — надо передавать на АТС в том же самом виде, в котором они были набраны.
Исходным выражением будет: ^(\d{3})$
Результатом будет: $1

Поясню, что делает это выражение. Начинаем обрабатывать входящий номер с начала — символ ^. После этого проверяем, есть ли три цифры — символ \d обозначает цифру от 0 до 9, а {3} — появление цифры три раза. После скобок идет признак конца строки — $. То есть, например, номер из четырех или двух цифр под это правило нормализации не подойдет.
Результатом преобразования будет $1 — то есть, то, что выбрано между скобок — без изменений. А между скобок у нас попадает три цифры — значит, результатом правила будет телефонный номер в три цифры, точно такой же, как и набранный. Он и будет впоследствии передан на АТС.

Казалось бы, зачем нам правило преобразования, которое ничего не преобразовывает? Но — если мы его не создадим, то Office Communications Server вообще не поймет, что надо обратить внимание на набранный телефонный номер из трех цифр, и скажет нам — мол, извини, ты набрал номер, о котором я ничего не знаю.

Параметры для первого правила нормализации заданы. Пункт Internal enterprise extension мы не включаем, а Use translation… не отключаем.

Вторым правилом будет обработка семизначного набранного номера. Опять нажмем Add для Normalization Rules.

Семизначный набранный номер должен быть передан на нашу АТС и стать исходящим вызовом в Москву. Раз это внешний номер — приведем его к стандартному виду, с кодом страны и города.
Исходным выражением будет: ^(\d{7})$
Результирующим выражением будет: +7495$1

То есть, к набранному семизначному номеру мы присоединяем спереди код страны и города Москвы. Например, набранный 7888043 станет +74957888043. При этом, замечу, что для OCS абсолютно все равно, вводится ли номер сплошными цифрами, или с пробелами, или с дефисами или скобками.

Третьим правилом нормализации мы создадим преобразование номеров вида 8-123-4567890 — указании вместо восьмерки кода страны +7.
Исходное выражение будет: ^8(\d{10})$
Результирующее выражение: +7$1

Вот мы и создали три правила нормализации, необходимые нам для обработки вызовов. Теперь необходимо привязать к Location Profile еще и маршруты. У нас с вами один Mediation Server, поэтому все внешние вызовы пройдут через него.

Переходим на закладку Routes и добавляем маршруты:

Первый назовем 3-digits. Выражение Target regular expression будет как и выше, ^(\d{3})$
В качестве шлюза укажем наш сервер mediation.uc.ru.

Второй будет для звонков по России (и Москве, раз мы преобразовали семизначный московский номер в международный формат +7495номер). Результирующее выражение будет: ^\+7(\d{10})$
Обращаю внимание, что знак + мы для порядка экранируем обратным слэшем. Шлюзом будет все тот же Mediation Server.

Третьим маршрутом добавим для разнообразия звонки в США. Результирующее выражение будет: ^\+1(\d{10})$
Шлюзом будет все тот же Mediation Server.