• Lync 2013 CU1. Перехват звонков

    Lync 2013 CU1. Перехват звонков

     

    Представьте себе ситуацию в одном кабинете сидят 5 сотрудников, Маша сидит через два стола от Петра.  Маша вышла из кабинета и, в это время ей приходит звонок. Задача: как Петру ответить на звонок не вставая со своего стола при использовании Lync. До мартовских обновлений вариант был только одни настроить групповой звонок, то есть Маша в настройках клиента ставить, что одновременно звонок должен приходить Петру.

     

    Рис 1. Выставление параметров группового звонка

    Однако Маше не нравится каждый раз выставлять эту настройку и потом, после того как она вернется снова убирать настройки звонка, кроме того Маша периодически забывает это сделать и Петру приходится бегать к Машиному столу чтобы поднять трубку. До CU1 у Петра был только один выход – подвинуть свой стол поближе к Машиному, чтобы было ближе бегать.

    С выходом пакета обновлений появилась возможность перехвата звонков, приходящих другим сотрудникам.

    Сотруднику или группе сотрудников можно присвоить номер для перехвата их звонков.

    Допустим кроме Маши и Петра в этой комнате еще сидит Сергей. Внутренние номера Маша 1002, Петр – 1003 и Сергей 1004. Можно присвоить номер для перехвата звонка приходящего любому участнику группы, например номер 1010. Когда Петр слышит, что звонок приходит Маше или Сергею которых нет в комнате он просто набирает 1010 и перехватывает звонок не вставая с рабочего стола.

    Второй вариант назначить номер каждому индивидуально, однако номера для перехвата должны быть уникальными, то есть у маши внутренний номер 1002 и мы уже не можем назначить этот же номер чтобы перехватывать ее звонки. С другой стороны назначать несколько номеров одному и тому же пользователю (один для звонков, второй для перехвата) неправильно, Петр может запутаться. Однако, так как как приложение перехвата звонков основано на приложении парковки, то мы можем ввести номера начинающиеся не с цифры а с * или #. Таким образом Маше можно создать номер для перехвата *1002 (или #1002), при внутреннем номере 1002 Петру будет легко запомнить.

    При перехвате звонка пользователь слышит, что раздается звонок и перехватывает его набрав номер для перехвата.

     

     

     

     

    Рис 2. Пользователь набирает номер для перехвата

     

    Рис 3. В этом примере мы перехватили звонок идущий от пользователя Eduard пользователю Amy, перехватил пользователь Adam

    Стоит также отметить .что если пользователь заносит контакт в категорию Friends and Family то звонок от этого пользователя перехватываться не будет.

     

     

    Рис 4. Изменение типа контакта

    Возможность перехвата звонков довольно часто спрашивали на российском рынке.

    Немного техники

    Настройка весьма проста, надо установить CU1 и далее согласно инструкциям на сайте http://technet.microsoft.com/en-us/library/jj945645.aspx

    Несколько тонкостей, требуется настройка SEAFAUtil, что требует установки Apllication Pool, не забывайте что мы рекомендуем устанавливать Application Pool на отдельно стоящих серверах.

    Номера для перехвата не видны в графической консоли, настройка только PowerShell

     

    Рис 4. Настройка номеров для перехвата

    Сами номера пользователям опять же присваиваются только из командной строки утилитой sefautil

     

     

    Рис 5. Присвоение номеров для перехвата утилитой Sefautil

  • Изучая Lync 2013 Preview. Отказоустойчивость между двумя дата центрами

    Как вы наверное уже знаете недавно вышла новая версия Lync 2013. В состав версии вошло достаточно много новых функций со списком Вы можете познакомиться в официальной документации http://technet.microsoft.com/en-us/library/gg398676(v=ocs.15).

    Естественно, увидев новую версию у меня сразу возникло желание попробовать новый функционал. В серии заметок я постараюсь описать наиболее важные изменения в новой версии.

    Начну со сценариев отказоустойчивости, так как изменения помогают значительно упростить построение инфраструктуры, способной предоставлять сервисы Lync даже в случае отказа всего дата центра, и, что немаловажно, при меньшей стоимости и при меньшем количестве усилий по сравнению с предыдущей версией.

    В заметке есть

    - теоретический материал по технологиями отказоустойчивости между сайтами

    - описание изменений в области отказоустойчивости в новой версии

    - подробное описание по настройке и разбор логов клиента для понимания как это работает

    Собственно для полного понимания, что изменилось и как это работает давайте вспомним как реализованы сервисы, предоставляемые клиенту начиная с Lync версии 2010.

    Для обеспечения сценариев отказоустойчивости с версии 2010, сервисы обслуживающие клиентов Lync разнесены по двум разным компонентам. Были разделены компоненты, отвечающие за регистрацию пользователя и за предоставление так называемых пользовательских сервисов (user services).

    Компонент регистрар, отвечающий за регистрацию пользователей устанавливается вместе с ролями Front End, Standard edition, Director и SBA (SBS), пользовательские же сервисы находятся на Back End, то бишь на сервере SQL. При пропадании связи с SQL пользователь может использовать компонент регистрар (например на SBA) но не может использовать функционал, зависящий от доступности пользовательских сервисов. К такому функционалу, например, относится адресная книга, контакты, участие в конференциях, информация о доступности.

    В этом режиме будет доступна регистрация, звонки через телефонную сеть (при наличии локального шлюза), обмен мгновенными сообщениями 1 to 1 (не конференция), то есть то что может обеспечить регистрар.

    Кроме того регистраp может быть первичным и вторичным. В случае отказа дата центра в котором находится первичный регистрар и пользовательские сервисы на SQL, пользователь может перерегистрироваться на вторичном регистраре (например во втором дата центре) при этом его пользовательские сервисы недоступны (находятся в потерянном первичном дата центре на SQL). Обмен данными между первичным и вторичным регистрарами производился автоматически, пользовательские сервисы на SQL реплицировать между двумя дата центрами не применяя гео кластер (очень дорогое и сложное решение) было сделать невозможно.

    Таким образом, начиная с версии 2010 нам стал доступен сценарий построения системы, обеспечивающей отказоустойчивость голоса и ряда других функций при потере дата центра.

    Pic1Lync2010HA

    Рис 1. Обеспечение отказоустойчивости между сайтами в Lync 2010

    В принципе было возможно обеспечить и доступность базы User Services (базы SQL) при потере дата центра . Для этого необходимо было вручную переместить пользователя на пул в другом сайте и, затем, из резервной копии восстановить SQL базу.

    Однако при этом требовалось значительное количество усилий со стороны администратора и наличие процесса резервного копирования базы, позволяющего восстановить базу с оговоренными потерями (нельзя же постоянно копировать базу, какая то информация все равно будет потеряна).

    В Lync 2013 появилась возможность автоматически реплицировать базу SQL между двумя географически распределенными сайтами, и, следовательно обеспечить полную функциональность клиента при работе с резервным дата центром.

    Картинка для Lync 2013 будет выглядеть следующим образом.

    Pic2Lync2013HA

    Рис 2. Обеспечение отказоустойчивости между сайтами в Lync 2013

    Однако, есть одно ограничение при отказе сервера происходит автоматическая регистрация клиента на резервной регистраре в режиме отказоустойчивости (доступны все сервисы кроме зависящих от User Services)

    Для восстановления полной функциональности необходимо с помощью командлета вызвать failover пула после чего у пользователя автоматически восстановятся все сервисы с сервиса SQL  в резервном дата центре.

    Давайте посмотрим как это настраивается и заглянем в логи клиента при переключении с основного на резервный.

    В моей инфраструктуре присутствуют три пула Lync разных версий, однако с целью тестирования сценария отказоустойчивости я буду использовать только два (Lync 2013).

    Pool02.contoso.com

    Один Front End (192.168.100.180), SQL 2008 R2 (192.168.100.151)

    Pool03.contoso.com

    Один Front End (192.168.205.15), SQL 2008 R2 (192.168.205.10)

    Также в моей инфраструктуре есть роль Director которая и будет перераспределять пользователей. Данная роль не является обязательной для построения такого сценария.

    Пулы находятся в разных сайтах, pool02 находится в сайте Redmond, pool03 находится в сайте Toronto.

    TopSnapshot

    Рис 3. Топология тестовой инфраструктуры

    Прежде всего необходимо настроить в редакторе топологии основной и резервный пулы.

    Pic4SetBackupregistrar

    Рис 4. Настройка резервного пула.

    После этой процедуры необходимо запустить мастер установки Lync. даже если он у Вас уже настроен. Мастер установит новую службу Lync Backup и, затем, запустить ее

    Start-CsWindowsService -Name LYNCBACKUP

    Служба Lync Backup это новая служба, отвечающая за копирование данных между пулами.

    Ниже приведены скриншоты служб Lync 2010 и Lync 2013. Обратите внимание на новую службу.

    Pic5Lync2010Services

    Рис 5. Службы Lync 2010

    Pic6 Lync 2013 Servicces

    Рис 6. Службы Lync 2013

    Видно что добавились новые службы LyncBackup и RTCXMPPGATEWAY (в Lync 2013 встроен XMPP шлюз позволяющий настраивать федерацию с XMPP службами, такими как Google Talk)

    Для проверки того, что репликация происходит можно воспользоваться командлетом

    Get-CsBackupServiceStatus  -poolFQDN имя_пула

    Pic7BackupStatus

    Рис 7. Статус синхронизации данных между пулами.

    Обратите внимание что в репликацию в том числе входят User Services и Conferencing Services.

    Примечание: По умолчанию право запустить этот командлет предоставлено только входящим в группу RTCUniversalServerAdmins (администратор и группа CSAdministrator в эту группу не входят) Для возможности мониторинга репликации необходимо дать право использовать этот командлет. Ниже команда для предоставления права группе CSAdministrator

    Set-CSBackupServiceConfiguration –Identity Global –AuthorizedUniversalGroups “CSAdministrator”

    На этом настройка закончена, можно переходить к тестированию.

    Итак имеется пользователь с домашним пулом pool02.contoso.com, я эмулировал отказ всего пула путем остановки службы rtcsrv на пуле pool02 и остановки службы SQL обслуживающей этот пул.

    Клиент автоматически входит в режим resiliency (недоступен функционал, зависящий от User Services) Для возврата User Services ниже мы сделаем процедуру Failover.

    Pic8LyncRes

    Рис 8. Клиент в режиме resiliency

    Давайте посмотрим на логи.

    Итак первоначальная регистрация, видим что пользователь зарегистрировался на домашнем пуле pool02 (192.168.100.180)

    Pic9HomePool

    Рис 9. Первоначальная регистрация пользователя на домашнем пуле.

    Далее произошла остановка служб, клиент обратился к Director для перерегистрации, Director вместо ответа 200ОК на регистрацию выдал 301 Redirect в  котором предоставил основной и резервный пулы (адрес Director 192.168.100.154)

    Pic10Director

    Рис 10. Перенаправление клиента ролью Director

    Так как клиент не видит основного пула, он пытается зарегистрироваться на резервном, резервный пул зарегистрирует его по прошествии времени указанного в поле Voice Failover при настройке резеевного пула (в нашем случае 150 сек см рис. 4)

    Pic11OnSec

    Рис 11. Регистрация клиента на резервном регистраре

    Обратите внимание, что пользователь зарегистрирован на pool03 (192.168.205.15) сервер CS-FE13 (участник домашнего пула pool02) говорит о недоступности сервисов и в поле presense-state видно, что пользователь сидит на резервном пуле и ему пока недоступны пользовательские сервисы. Register action = added

    При этом пользователь постоянно пытается перерегистрироваться, посылая команду Register, пока User Services недоступны службы недоступны сервер ему выдает результат register action = refreshed, User Services Unavailable. Это определяется полем Expires: 180

    Pic11Reregister

    Рис 12. Попытки перерегистрации клиента

    Для воврата пользовательских сервисов (по сути использования второго SQl  в другом сайте) необходимо вызвать процедуру failover путем выполнения командлета

    Invoke-CsPoolFailover –PoolFQDN pool02.contoso.com -DisasterMode –Verbose

    Pic11FailOver

    Рис 12. Вызов процедуры Failover

    После этой процедуры в ответ на следующий Register от клиента, сервер присылает ответ fixed, и, ставит тайме Expired = 7200. Клиент переходит в состояние работы в полном функционале.

    Pic13

    Рис 13. Ответ сервера

    FullModeLync2013

    Рис 14. Клиент перешел автоматически в режим полного функционала.

    Для возврата клиента на домашний пул (после восстановления работоспособности) необходимо выполнить команду

    Invoke-CsPoolFailback –PoolFQDN pool02.contoso.com -Verbose

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

    Николай

    MCM(rgb)_1418

  • Отвечая на вопросы: Lync и несколько телефонных шлюзов

     

    Недавно провел тренинг по Lync Voice для партнеров в ходе которого получил ряд вопросов. Отвечая на них, я увидел необходимость более подробного освещения некоторых моментов, особенно в части маршрутизации голоса. Особенно много вопросов было по обеспечению отказоустойчивости между Lync и шлюзами. Давайте рассмотрим пару сценариев и поймем как Lync работает при различных настройках.

    Дано

    Lync и несколько шлюзов выхода в телефонную сеть, два шлюза находятся в Москве, один шлюз находится в Киеве.

    Задача.

    Обеспечить при нормальной работе звонки по России для всех пользователей, включая киевских через два шлюза в Москве, при этом в случае отказа одного из шлюзов, звонки должны все равно проходить по России (для этого два шлюза), в случае отказа обоих шлюзов звонки совершать через киевский шлюз.

    Как мы знаем из предыдущей статьи при маршрутизации звонка Lync выбирает PSTN записи в политике пользователя, которые в свою очередь состоят из маршрутов. При этом сами PSTN записи применяются по порядку сверху вниз.

    Давайте попробуем реализовать заданный сценарий.

    В моей инфраструктуре три шлюза

    Ucgw9.msucdemo.local – шлюз в Москве

    Ucgw4.msucdemo.local – второй шлюз в Москве

    Ucgw8.msucdemo.local – шлюз в Киеве

    Вариант 1

    Добавляем маршруты.

    1. Звонок на телефонный номер, начинающийся на +7 и, содержащий не менее 10 цифр отправить на шлюзы в Москве, для этого оба шлюза регистрируем в одном маршруте

    clip_image002

    Рис 1. Создание маршрутов для звонков по России

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

    2. Создадим резервный маршрут для звонков по России через киевский шлюз в случае отказа обоих московских.

    clip_image004

    Рис 2. Резервный маршрут

    Теперь я объединю маршруты в PSTN записи в соответствии с условиями задачи.

    Напомню, что мне необходимо реализовать при нормальной работе прохождение звонков по России через московские шлюзы и в случае отказа обоих шлюзов отправить звонок через киевский шлюз. Я создам две PSTN записи и назову их Russia Long Distance for Russia и Backup Russia Long Distance for Russia

    clip_image006

    Рис 3. PSTN записи

    При таком порядке PSTN записей Lync будет пытаться отправить все звонки по России через два московских шлюза (они в маршруте Route495) распределяя их между этими шлюзами и в случае отказа обоих шлюзов будет выбрана вторая PSTN запись, находящаяся ниже и звонки пойдутчерез киевский шлюз.

    Вариант 2

    Однако мы можем не объединять оба московских шлюза в один маршрут, а сделать три маршрута.

    1. Маршрут до шлюза Ucgw9.msucdemo.local (Москва)

    2. Маршрут до шлюза Ucgw4.msucdemo.local (Москва)

    3. Маршрут до шлюза Ucgw8.msucdemo.local (Киев)

    И, затем, распределить требуемый порядок выбора шлюзов с помощью PSTN записи

    clip_image008

    Рис 4. PSTN записи, сравните с рис 3.

    Маршрутизация звонков будет происходить также как и в первом случае, сначала будет выбирать (с распределением и отслеживанием работоспособности) один из маршрутов в первой PSTN записи, а в случае недоступности будет выбрана вторая PSTN запись и звонки уйдут через киевский шлюз.

    А если оба эти сценарии равнозначны, какой же подход выбрать?

    Я предпочитаю второй, так как части пользователей я могу создать PSTN запись с отказоустойчивостью (добавив два маршрута) а части создать PSTN запись только с одним маршрутом (добавив в первую запись только один маршрут)

    Отследить работу можно только с помощью снятия SIP логов, в тест кейсах Lync эта логика отображаться не будет.

    Буду рад любым комментариям, в следующих заметках я постараюсь ответить на интересные вопросы, которые я получаю в ходе своей работы.

  • Маршрутизируем звонки в Lync: как отловить, преобразовать телефонный номер и направить его по нужному маршруту.

     

    Эту статью изначально я задумывал как справочник по регулярным выражениям, использующимся при маршрутизации звонков в Lync сервере, однако в ходе ее написания я понял, что необходимо помимо описания регулярных выражений, все таки рассказать, как и где они используются. Поэтому получилась довольно объемная заметка, состоящая из описания процесса прохождения телефонного звонка через правила нормализации и маршруты а также из справочника по регулярным выражениям. Я очень надеюсь, что после прочтения статьи появится четкое понимание каким образом звонки проходят через правила Lync и как грамотно настроить правила нормализации и маршрутизации. Буду благодарен за любые отзывы.

    Итак, давайте рассмотрим процесс прохождения звонка и какие настройки Lync на него влияют.

    По сути схему прохождения звонка в можно представить в следующем виде

    Пользователь набирает номер в том виде в котором он привык его набирать, допустим 97000000.

    Первым шагом применяются правила нормализации Lync. Основной их целью является прием номера в том виде в котором пользователи привыкли его набирать и изменять его для дальнейшей отправки в том виде, в котором его может принять и понять следующее устройство (например, шлюз). Для пример давайте возьмём случай, когда пользователи вводят городские номера в виде 9ххххххх. Для отправки звонка надо убрать 9 и добавить код страны и города – в итоге номер после правил нормализации должен принять вид +74957000000 – это мы должны получить как итог работы правил нормализации.

    Вторым шагом будет поиск в голосовой политике пользователя маршрута соответствующего этому телефонному номеру. Если есть маршрут который говорит, например что все начинается с +7495 и содержит 11 символов отправить на шлюз, звонок совершен будет, если маршрута в политике пользователя нет, то звонок не сможет быть совершен, даже если маршруты есть в политиках других пользователей. Маршруты в тоже время в политике представлены группами – PSTN Usage. Одну и туже группу PSTN Usage можно использовать в нескольких политиках.

    На рисунке 1 отображено прохождение звонка.

    clip_image002

    Рис 1. Схема прохождения звонка

    Давайте посмотрим, где это настраивается в интерфейсе Lync сервера

    clip_image004

    Рис 2. Lync Control Panel

    Несмотря на то, что существуют три вкладки для настройки политики (политика – PSTN запись - маршрут) настраиваться все может с вкладки Voice Policy

    Для создания образцов номеров, как в правилах нормализации, так и в маршрутах используются регулярные выражения. В правилах нормализации мы обычно описываем ими образец что ловить и образец во что преобразовать, в маршрутах мы прописываем образец что ловить (уже нормализованные номера). Без них пришлось бы по сути набивать каждый номер и говорить разрешено ли звонить по нему или нет.

    Рассмотрим регулярные выражения.

    Казалось бы нужно изучать язык регулярных выражений, ведь Lync позволяет использовать помощник, способный с помощью графики строить базовые выражения. Ключевое слово здесь «базовые», если вам надо использовать более сложные и комплексные правила, то их можно создать только руками, кроме того помощник есть только в правилах нормализации, помощника в правилах маршрутов нет.

    Начнем с основ

    ^ означает начало

    $ означает окончание выражения

    По сути дела в��м надо использовать ^$ и между ними набивать ваш образец набора номера

    \d этот класс определяет количество цифр вне зависимости от их значения. При этом мы можем использовать как выражение \d\d\d для поиска номера из любых трех цифр, так и выражение \d{3} . Очевидно, что второе выражение более просто написать, особенно когда количество цифр большое.

    () кавычки определяют набор или группу, где ( означает начало группы и ) конец группы. Примером может служить (\d{3}). Все что стоит вне кавычек Lync будет убирать.

    Например, если выражению ^(9\d{3})$ подать на вход номер 9100 то он будет преобразован в 9100, если изменить выражение на ^9(\d{3})$ то этот же номер будет преобразован в 100

    [] означают диапазон искомых цифр.

    Например, телефонные номера в Иваново могут начинаться с цифр 2,3 и 4 и состоят в целом из 6 цифр, номер не может начинаться с другой цифры

    Выражение ^( [2-4])(\d{5}) будет принимать номер 255555 и не принимать номер 655555

    Второй пример телефонные номера могут начинаться с цифр 2, 4 или 6. Тогда выражение примет следующий вид ^([2,4,6])(\d{5}) Номер 355555 подпадать под него не будет

    Символ \ ставится перед тем символом, который может иметь значение в регулярном выражении, но мы хотим его использовать как просто образец для поиска, например выражение \+501 будет искать номер +501

    Кроме того существует еще ряд символов, встречающихся в выражениях Lync

    Квантификаторы

    * - означает, что могут последовать 0 или большее количество цифр

    Пример ^(\d{3}\d*)$ будет принимать любой номер с количеством цифр не меньше трех

    + - означает, что должна последовать 1 или большее количество цифр

    Пример ^(\d{3}\d+)$ будет принимать номер с количеством цифр не меньше четырех

    ? – означает 0 или одну цифру

    Пример ^(\d{3}\d?)$ будет принимать только трех или четырехзначный номер

    {3} – означает, что номер должен состоять только из трех цифр

    Пример ^(\d{3})$ будет принимать только номер с количеством цифр равным трем

    {3,} –означает, что могут последовать 0 или более цифр

    Пример ^(\d{3,})$ будет принимать номер с количеством цифр не меньше трех

    Обратите внимание, что все квантификаторы следуют за выражением \d

    Утверждения

    ?! – означает кроме этого

    Пример ^(?!46)(\d{6})$ - будет принимать любой шестизначный номер, кроме начинающегося на 46, пример ^(?![4,6])(\d{6})$ любой шестизначный номер, кроме начинающегося на 4 или 6

    ?= цифра – означает искать номера, только начинающиеся с этой цифры

    Пример ^(?=4)(\d{6})$ - будет принимать шестизначный номер, но только если он начинается с четверки

    ?# - после этого утверждения можно поместить комментарий

    Это конечно не все существующие выражения. Я привел только наиболее использующиеся для маршрутизации звонков в Lync.

    Давайте теперь попробуем разобраться с выражениями на примерах из Lync.

    Нормализация

    Пример 1.

    Представим, что нам надо отправлять городской телефонный номер, находясь в Ростове-на-Дону на шлюз в формате +7863xxxxxxx, но пользователи при этом привыкли набирать 97000000

    Мы можем решить это несколькими выражениями

    В поле Pattern to match вводим ^\d{1}(\d{7})$

    В поле Translation Rules вводим +7863$1

    clip_image006

    Рис 3. Пример правила нормализации

    Правило будет принимать номера состоящие из восьми цифр (любых), убирать первую цифру и добавлять перед ними +7861. Но в таком случае и номера начинающиеся не с девятки тоже будут преобразованы по этому правилу, что не всегда подходит.

    Второй способ это отлавливать номера из восьми цифр, только начинающиеся с девятки

    Тогда

    В поле Pattern to match вводим ^9(\d{7})$

    В поле Translation Rules вводим +7863$1

    Это правило будет принимать и преобразовывать только номера, начинающиеся с девятки и содержащие восемь цифр, при этом девятка будет убрана (она стоит вне кавычек) и вначале будет добавлено +7863

    А вот если у нас номера начинаются только с определённых цифр, например, представим, что в Ростове номера могут начинаться с 2, 3, 4 или 7

    С помощью графического мастера сделать это уже не получится.

    Регулярное выражение в таком случае будет ^9(?=[2,3,4,7])(\d{7})$

    Номера в виде 92000000 будет нормализован в +78632000000, номер 98000000 нормализован не будет

    clip_image007

    Рис 4. Пример правила нормализации

    Также можно сделать своеобразные «горячие клавиши». Допустим у директора внутренний номер 100, с помощью правил нормализации мы тогда можем сделать чтобы при наборе, например 1 номер преобразовывался в +100

    В таком случае

    В поле Pattern to match вводим ^1$

    В поле Translation Rules вводим +100

    clip_image008

    Рис 5. Пример создания «горячей клавиши»

    Следует также отметить, что правила нормализации применяются в том порядке, в котором отображаются в консоли, если вы создадите два правила под которые может подходить один и тот же номер, он будет нормализован по правилу, которое находится выше в консоли.

    Просто преобразовывать номера для маршрутизации недостаточно, при маршрутизации Lync нормализует номера и, затем осуществляет поиск в политике пользователя маршрута по которому этот звонок может быть направлен (за исключением внутренних номеров, в этом случае Lync сразу соединит с внутренним абонентом)

    Маршруты

    Давайте продолжим настройку нашей маршрутизации, теперь у нас стоит задача разрешить звонки на местные локальные номера, состоящие из 7 цифр, за исключением номеров начинающихся на 2,3,4 или 7 всем пользователям. Группе Бухгалтерия кроме того будет разрешены звонки по России.

    С помощью правил нормализации (образец - ^9(?=[2,3,4,7]\d{7}))$ заменяет на +7863$1) к нам будут приходить номера в формате +7863ххххххх

    В маршрутах уже не ставятся скобки перед образцами цифр, таким образом наше выражение для маршрута примет следующий вид +\7863(?=[2,3,4,7])(\d{7})$

    Это выражение мы добавим в маршрут.

    Идем в Voice Policy, вызываем ее свойства и нажимаем в пункте Associated PSTN Usages кнопку Select

    clip_image010

    Рис 6. Настройка голосовой политики

    Как мы видим Lync уже содержит три записи, выбираем Local и выбираем свойства этой записи к которой мы привяжем маршрут

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

    clip_image012

    Рис 7. Настройка маршрута

    Теперь создадим новую политику которая будет применяться для Бухгалтерии и позволять помимо локальных звонков осуществлять звонки по России. При создании политики я выбрал тип User Policy. Я использовал следующее регулярное выражение ^\+7\d{10,}

    clip_image014

    Рис 8. Создание политики на пользователя

    Теперь давайте попробуем как работают наши правила. Сделать это можно с помощью вкладка Create Voice Routing Test Case. Причем я сразу буду брать populate Form user.

    Пользователь Алексей Еременко, стандартная голосовая политика, пробуем набрать два номера 92440000 и 84957000000

    clip_image016

    Рис 9. Проверяем маршрут на локальный номер

    clip_image018

    Рис 10. Проверяем маршрут на междугородний номер для пользователя Алексей Еременко

    Как видим в первом случае номер из 92440000 будет преобразован в +78632440000 по правилам нормализации и отправлен по маршруту Rostov-on-Don Local. Во втором случае номер из 84957000000 будет преобразован в +74957000000 но отправлен никуда не будет, так как отсутствует подходящий маршрут в голосовой политике пользователя.

    Теперь давайте попробуем проверить маршрут междугороднего звонка для пользователя Дарья Попкова, у нее привязана политика, содержащая маршрут для таких номеров

    clip_image020

    Рис 11. Проверяем маршрут на междугородний номер для пользователя Дарья Попкова

    Как видно Дарья сможет совершить звонок, используя маршрут National.

    Надеюсь что после прочтения этой заметки правила настройки звонков стали более понятными.

    Напомню, что партнеры со статусам Silver и Gold могут воспользоваться техническим консалтингом. Для этогго необходимо обратиться по адресу rutpts@microsoft.com

  • Часть 4 Окончание: Новые возможности Microsoft Lync Server 2010. Передача голоса и отказоустойчивость.

    В предыдущей заметке мы познакомились с механизмом обеспечения прохождения звонков в случае отказа домашнего сервера пользователя. Как мы видели прохождение звонков осуществлялось с помощью второго пула серверов Standard или Enterprise.

    Однако в силу ряда причин может быть неоправданным установка еще одного пула для филиалов, особенно если в них работает достаточно небольшое количество сотрудников. Кроме того для филиалов помимо отказа серверов может быть актуальна проблема пропадания связи между ним и головным офисом.

    В этом случае на помощь может прийти такое устройство как Survival Branch Appliance (Устройство для обеспечения связи в филиалах) и именно оно будет освещено более подробно в ходе этой заметки.

    Однако это не единственный вариант обеспечения связью сотрудников филиалов.

    Давайте рассмотрим рекомендуемые варианты обеспечения связи в филиале в зависимости от его размера.

    Мы можем разделить филиалы на три типа в зависимости от количества  - малый филиал с количеством пользователей до 25, средний филиал с количеством пользователей от 25 до 1 000 и большой филиал с количеством пользователей свыше 1 000.

    С точки зрения экономической эффективности малые филиалы проще подключить с помощью интернета к пулу серверов в головном офисе. Основное предназначение этого устройства - средние филиалы с количеством пользователей от 25 до 1 000.  Для крупных филиалов с количеством пользователей свыше 1 000 рекомендуется устанавливать отдельные сервера, например редакции Standard.

     

    Рис. 1 Позиционирование решений для филиалов.

    Основное предназначение устройства SBA  - это филиалы с количеством пользователей от 25 до 1 000.

    Устройства поставляются в виде аппаратного решения и содержат в себе следующие компоненты

    • Windows Server® 2008 R2
    • Роль Mediation сервера Lync
    • Компонент регистратор (подробное описание компонента в части 1)
    • Шлюз IP-PSTN (способен перенаправлять звонки через телефонную сеть в случае пропадания канала связи с головным офисом)
    • SQL Express для хранения конфигурации

    Устройство управляется из головного офиса, способно функционировать как в штатном режиме (при наличии связи с работоспособным пулом в головном офисе) так и в нештатном режиме (при отказе канала связи с головным офисом или пула серверов). При этом обеспечивает соединение с телефонными сетями общего пользования, маршрутизацию голосовых сообщений, перенаправление трафика через телефонные сети. Способно поддерживать до 1 000 пользователей.

    Устройства поставляются партнерами по Объединенным коммуникациям. На данный момент о выпуске таких устройств объявили компании Audiocodes, Dialogic, Ferrari, Hewlett-Packard, NET.

     

     

    Рис 2. Устройства SBA

    При пропадании канала связи с головным офисом клиенты получат уведомление об ограничении функциональности и при этом им будут доступны следующие возможности:

    • Входящие звонки
    • Исходящие звонки
    • Звонки внутри текущего расположения пользователя и между офисами (маршрутизируются через телефонную сеть)
    • Удерживание и перевод звонков
    • Аутентификация и авторизация
    • Запись сообщений в голосовые почтовые ящики (перенаправляются в ExchangeUM в головной офис по телефонной линии)
    • Чтение сообщений в голосовых почтовых ящиках (через телефонную линию)
    • Двустороннее внутрисайтовое общение с помощью мгновенных сообщений и аудио/видео
    • Запись деталей звонков
    • Групповой звонок, одновременный звонок на нескольких телефонах (Simulations Ringing), звонки босс-админ
    • Поиск контакта
    • Участие в аудиоконференциях через телефонную сеть

    Пользователю будет недоступно

    • Межсайтовое общение (мгновенные сообщения, общий доступ к приложениям и т.д)
    • Участие в конференциях мгновенных сообщений, видео и веб
    • Информация о доступности и маршрутизация на основе статуса «Не беспокоить»
    • Изменение настроек перенаправления звонков или информации о доступности
    • Парковка звонков и группа ответа
    • Список контактов

    То есть Устройство обеспечивает базовые возможности голосовой связи для пользователей даже при отсутствии канала связи с головным офисом.

    Пользователь находит устройство с помощью механизма DNS. При этом в первый раз пользователю желательно обеспечить доступ к пулу серверов в головном офисе и к службам сертификации.

    Рассмотрим процесс первого подключения пользователя.

     

     

    Рис 3. Процесс первого подключения пользователя.

    • 1. Клиент выполняет запрос на DNS SRV записи для своего SIP домена,  получает ответ, указывающий на пулы серверов Director (при их отсутствии на пулы серверов FrontEnd)
    • 2. Пул серверов определяет что это первое подключение и перенаправляет для получения сертификата (401)
    • 3. Клиент подключается к службам сертификации, проходит аутентификацию, получает сертификат
    • 4. Сертификат реплицируется на SBA
    • 5. Клиент пытается выполнить SIP регистрацию, получает ответ, перенаправляющий его на SBA и содержащий указания на основной регистратор (SBA) и резервный (пул серверов в головном офисе)
    • 6. Клиент производит SIP регистрацию на устройстве SBA при этом кеширует его имя и IP адрес.

    После первого подключения обеспечивается полная независимость клиента от головного офиса.

    Рассмотрим процесс регистрации пользователя при различных сценариях.

    Сценарий 1. Штатная ситуация, канал работоспособен - все устройства доступны.

    В этом случае пользователь будет регистрироваться на устройстве SBA, даже в том случае, если он находится вне офиса. При нахождении вне офиса пользователь будет подключаться к серверам Edge головного офиса (находит его по записям в DNS), которые все равно перенаправляют его для регистрации на SBA.

    Сценарий 2. Отказ канала связи.

    Для пользователя, находящегося в филиале процесс регистрации не изменится, регистрация проходит на устройстве SBA. Пользователи находящиеся вне офиса будут регистрироваться на резервном регистраторе (пул серверов в головном офисе).

    Сценарий 3. Отказ устройства SBA

    В этом случае все пользователи будут регистрироваться на пуле серверов в головном офисе.

     

    Рис 4. Регистрация пользователей при различных сценариях.

    Как же будет проходить сигнальный и медиа трафик в различных сценариях.

    Сценарий 1. Канал связи доступен, все устройства работоспособны.

    В случае совершения звонков внутри филиала весь трафик (сигнальный и медиа) будет проходить внутри филиала. При звонках на внешние телефонные номера трафик будет проходить через SBA и далее в телефонную сеть.

     

     

     

    Рис.5 Прохождение трафика при звонках внутри филиала и из филиала в телефонную сеть.

    При звонках в головной офис или между офисами сигнальный трафик проходит через SBA на пул серверов в головном офисе. Медиа трафик проходит между устройствами, участвующими в звонке.

    Если же пользователь филиала находится вне филиала, он регистрируется через Edge головного офиса (находит по записям DNS). Сигнальный трафик проходит через Edge, затем через SBA. Медиа трафик проходит через Edge между устройствами, участвующими в звонке.

     

     

    Рис 6. Прохождение трафика при звонках в головной офис и при нахождении пользователя вне филиала.

    Сценарий 2. Недоступен канал WAN или устройство SBA

    Звонки внутри филиала проходят как обычно, также работает функционал передачи видео/мгновенных сообщений/предоставления доступа к приложениям внутри филиала, все сигналирование происходит через устройство SBA. Звонки в головной офис будут проходить через телефонную сеть. Медиа трафик будет приниматься шлюзом в голо��ном офисе и направляться вызываемому абоненту.

     

    Рис 7. Прохождение трафика внутри филиала и при звонках в головной офис при неработоспособности канала WAN

    Пользователь находящийся вне филиала будет регистрироваться в головном офисе и ему будет доступны все возможности за исключением входящих звонков. Входящие звонки не будут приниматься, так как устройство принимающее  их недоступно. Можно обеспечить входящие звонки только в том случае если у Вас настроен SIP транкинг и провайдер этой услуги поддерживает такой сценарий.  Трафик будет проходить через сервера головного офиса.

    В случае отказа устройства SBA все устройства будут регистрироваться на серверах головного офиса. Пользователям будет доступен весь функционал.

     

     

    Рис 8. Прохождение трафика от внешнего пользователя и при отказе устройства SBA.

    Итак, как мы видим, с помощью устройства SBA мы можем обеспечить связью филиал даже в том случае, если откажет канал связи без разворачивания в нем полного пула серверов.

    В следующих заметках мы продолжим знакомство с новым функционалом сервера Lync.