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.