Archive for the ‘Lync 2010’ Category

Обработка телефонных вызовов в Lync Server 2010

12.02.2012

Тема непростая, но обязательная для изучения всеми, кто хочет «собрать» из Lync телефонную станцию. При чтении желательно иметь перед глазами интерфейс администрирования Lync Server под странным названием: «Communications Server Control Panel» (CSCP). В противном случае, многие места понять будет довольно сложно.

Итак, CSCP открыт… Кружка пива (чашка кофе) на столе под рукой… Мозг расслаблен… Приступаем.

Форматы номеров в Lync.

Существует три идеологически верных 🙂 формата телефонных номеров в Lync:

  • Е.164: +<код страны><код региона/ оператора><номер>, например +74951234567
  • E.164 c доб. номером: +<код страны><код региона/оператора><номер>;ext=<доб. номер>, например +74951234567;ext=1234

Первый вариант подходит для прямых номеров, второй для случаев, когда имеется один прямой номер на организацию/филиал организации. Номер без «ext=XXXX» в этом случае хитрым правилом должен ссылаться на автосекретарь.

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

Преимущество схемы c использованием E.164 в том, что ваши партнёры по федерации, если вы разрешите им видеть ваш номер, смогут позвонить на него из любой страны, невзирая на свой номерной план.

Недостатков тоже вагон и маленькая тележка, но об этом позже. А пока скажу, что намного чаще приходится давать пользователям стандартные  номера форматов XXX, XXXX или XXXYYYY.

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

Как Lync проверяет, что номер в формате Е.164? Очень просто. Смотрит на «+» в начале номера. То есть «прокатит» даже +123. Если же идет звонок на номер без «+», такой номер нужно нормализовать, то есть, в идеале, преобразовать к формату E164.

Правило нормализации можно условнео разделить на три категории (моё личное разделение, в документации этого нет):

  • Преобразующие номер к E.164
  • Преобразующие номер к другому формату нежели у.164
  • Закрепляющие правила

Как происходит нормализация. В Lync существуют наборы правил преобразования номеров (normalization rules), называемые планами нумерации (Dial Plan). Dial Plan может назначаться на пользователя, применяться ко всем вызовам пула Lync или сайта Lync. Кроме того, всегда существует Dial Plan с именем Global, применяемый ко всей организации Lync. К каждому объекту может быть применен только один Dial plan. При наличии нескольких Dial Plan, применимых к объекту на разных уровнях, выбирается Dial Plan с наименьшей зоной действия. В порядке уменьшения приоритета User, Pool, Site, Global.

Правила внутри Dial Plan применяются в порядке, выставленном администратором до первого соответствия. Если правило не приводит номер к формату E.164, то ищется закрепляющее правило. Если номер не подпадает под какое-либо правило, либо отсутствует закрепляющее праило, происходит сбой вызова.

В докуменации ничего не говорится про закрепляющие правила, но схема работы проверена на нескольких инсталяциях с декабрьскими обновлениями (CU4) . Возможно требование к «закреплению» правил это Баг и исправят позднее. Закрепляющие правила могут не изменять номер, но дают Lync Server понять, что вы уверены в том, что хотите использовать номер не в E.164 формате. Просто измененный одним правилом номер должен подпадать под регулярное выражение другого правила.

Примеры:

Имеем Dial Plan из  6-и правил:

  • Правило 1: ^(\d{4})$ -> 111$1
  • Правило 2: ^(\d{5})$ -> 111$1
  • Правило 3: ^(\d{7})$ -> $1      (Закрепляющее правило для правила 1)
  • Правило 4: ^9(\d{7})$ -> +7495$1
  • Правило 5: ^98(\d{10})$ -> +7$1
  • Правило 6: ^(\d{3})$ -> +74951234567;ext=$1

И имеем 6 вызовов, попавших на этот Dial Plan, на следующие номера:

  • 12
  • 12345
  • 1234
  • +74951234567
  • 91234567
  • +1234
  • 123

Попробуйте сами определить, какие вызовы «пройдут» и что произойдёт с номерами, а потом проверьте себя ниже по тексту.

Вызов 1. Звонок на номер 12. Номер не в формате E.164 и не подходит ни под одно правило. Значит, вызов будет отбит без дополнительных проверок. 

Вызов 2. Звонок на номер 12345. Согласно правилу 2 вызов преобразуется к 11112345. Но это еще не всё. Правил для номера 11112345 нет, вызов не «закреплен» и также будет отбракован.

Вызов 3. Звонок на номер 1234. Согласно правилу 1 вызов преобразуется к 1111234, а согласно правилу 3 происходит «закрепление». Проверка нормализацией пройдена.

Вызов 4. Звонок на номер +74951234567. Номер уже в формате E.164 и в нормализации не нуждается. Проверка пройдена.

Вызов 5. Звонок на номер 91234567. Согласно правилу 4 номер преобразуется  к +74951234567. Номер +74951234567 в формате E.164. Больше преобразования не требуются. Проверка пройдена.

Вызов 6. Звонок на номер +1234. «+» перед номером есть, значит, считаем, что номер в порядке J. Преобразований не требуется. Проверка пройдена.

Вызов 7. Звонок на номер 123. Согласно правилу 6 номер преобразуется  к +74951234567;ext=123. Больше преобразования не требуются. Проверка пройдена. Собственно, это пример правила, преобразующего номер к формату, рекомендованному MS для организаций, в которых имеется один прямой номер.

Принцип понятен? Тогда еще нюансы:

  • При исходящих вызовах проверяется и меняется только номер вызываемого абонента (Calling ID).
  • При входящем вызове меняется и номер вызывающего (Caller ID) и номер вызываемого (Calling ID), но проверяется только (Caller ID). То есть, если Caller ID  не подпадает ни под одно правило – вызов всё равно пройдет.
  • Для входящих вызовов можно использовать планы только план нумерации уровня пула, (где пул – это голосовой шлюз) либо global.
  • Вызовы, пришедшие от автосекретаря Exchange UM, если уж они пришли, подпадают только под план нумерации global.       

Сколько следует создавать планов нумерации? 

Обычно – столько, сколько у вас филиалов с выходом в город. Посмотрите на правило номер 4 из приведенного выше примера. В каждом городе люди захотят звонить в родной город по короткому номеру. Если сможете приучить пользователей звонить в ближайший город, используя E.164 или формат из правила 5 того же примера, сможете обходиться одним Dial Plan на организацию.

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

Транзитные АТС

Существует такое понятие, как транзитная АТС (автоматическая телефонная станция). Это означает, что АТС выступает как шлюз между двумя другими телефонными станциями. То есть с одного не привязанного к АТС телефонного номера можно позвонить через АТС на другой номер, также не привязанный к АТС.

<Телефон 1> — <АТС 1> — <АТС 2> — <АТС 3> — <Телефон 2>

Так вот, ни OCS, ни Lync в текущей версии, транзитной АТС не является. То есть, для всех телефонных вызовов, номер вызывающего или вызываемого должен быть в базе OCS/Lync.

Единственный способ обойти правило – создать в конфигурации Lync аналоговое устройство. Например, мы говорим, что у нас есть аналоговый телефон с номером 1234 и находится он за шлюзом АТС 3. Теперь с любого номера через АТС 1 можно позвонить на номер 1234 за АТС 3. С обратным сценарием сложнее, но об этом в другой раз.

Обработка входящих вызовов

Теперь у нас достаточно информации для разбора процесса обработки входящих вызовов. Итак:

  1. На первом этапе к номерам  Caller ID и Called ID применятся Dial Plan.
  2. Полученный после обработки номер  Called ID проверяется на соответствие телефонным номерам объектов Lync: клиентов, почтовых контактов, аналоговых аппаратов, служб конференций и групп дозвона (Response Group).
  3. Если соответствие найдено – вызов пересылается на нужный объект: клиенту, на сервер Exchange с ролью Unified Messaging либо на шлюз, за которым находится аналоговый телефон.

Отображение имени звонящего

Кстати, если телефонный номер вызывающего абонента по итогам нормализации пришел клиенту Lync в формате E.164, клиентское ПО Lync попытается распознать вызывающего, сопоставив номер с имеющимся списком контактов. Если же номер пришел без «+» в начале, единственный способ увидеть имя звонящего – передать Caller Name через шлюз.  

Обработка исходящих вызовов

В этом сценарии действий чуть больше.

После выполнения нормализации проводится проверка, имеет ли право абонент звонить на этот номер.

Политики Вызовов

Для исходящих вызовов, после выполнения нормализации, выполняется проверка, может ли пользователь звонить по набранному номеру (нормализованному).

В проверке участвуют три компонента: Voice Policy, PSTN Usage и Route.

Voice Policy (голосовая политика) применяется по той же схеме, что и Dial Plan. Помимо доступных функций телефонии, Voice Policy определяет перечень так называемых PSTN Usage (приблизительно можно перевести как тип вызовов), включая приоритет использования.

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

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

Пример использования такой схемы не самый эффективный, но сойдет для понимания концепции:

  • Голосовая политика MSK_BUH – включает в себя два типа вызовов: BRANCHES_LOCAL и MSK_RU.
  • Голосовая политика SBP_ BUH включает в себя два типа вызовов: BRANCHES_LOCAL и SPB_RU.
  • Голосовая политика MSK_VIP – включает в себя три типа вызовов: BRANCHES_LOCAL, MSK_ALL и SPB_ALL
  • Голосовая политика SPB_VIP – включает в себя три типа вызовов: BRANCHES_LOCAL, SPB_ALL и SPB_ALL
  • И т. д.

Соответственно, BRANCHES_LOCAL входит в кучу маршрутов формата +7<код города филиала> -> шлюз в филиале.

C остальным всё просто. При вызовах в город, где у нас есть филиал, вначале пробуем позвонить через этот филиал. Если не вышло или нет маршрута до этого города, звоним через местный шлюз.

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

Нормализация на выходе

Моя «любимая» тема 🙂

Теперь, когда мы почти уже выполнили вызов, осталась самая малость… Привести номера в соответствие требованиям оператора телефонии.  Хотелки у операторов бывают разные. 84951234567, 4951234567, 74951234567.Некоторые хотят получить номер 1234567, для локальных вызовов и 74951234567 для вызовов по стране.

А что мы можем?

В настройках взаимодействия со шлюзом (Trunk settings) можно указать регулярные выражения для манипуляций Called ID, что не может не радовать…. Но вот номер звонящего (Calling ID) можно поменять только в свойствах маршрута, причем не регулярным выражением, а исключительно на другой номер (один на маршрут).  В Trunk settings мы можем дополнительно только срезать с Calling ID пресловутый «+».

Выходит, что для каждого VIP с прямым номером, мы должны делать отдельные Voice Policy, PSTN Usage и Route. Это если у нас нет шлюза, и мы не договорились с оператором. 🙂

Ждем Lync 15.

Обработка исходящих вызовов

Теперь коротко весь процесс для исходящих вызовов:

  1. На первом этапе, еще на клиенте Lync, к номеру Called ID применятся Dial Plan.
  2. Полученный после обработки номер Called ID прогоняется через связку Voice Policy, PSTN Usage, Route
  3. Если соответствие найдено – идет попытка вызова на маршрут. При этом номера Called ID и Calling ID меняются в соответствии с настройками Trunk settings и Route.
  4. Если шлюз не доступен – проверяется следующий шлюз маршрута
  5. Если все шлюзы маршрута недоступны – ищется следующий подходящий маршрут.

И напоследок. Обычно, получая номера формате +74951234567;ext=1234 шлюз отбрасывает ;ext=1234, что нам и требуется.

И напоследок, снова про форматы номеров

Предположим, у нас есть 10 филиалов, в каждом из которых есть по 10 VIP пользователей с прямыми номерами. Остальным можно дозвониться через локальный номер автосекретаря.

Как я уже говорил, обычно для каждого филиала создается свой Dial Plan.

Теперь считаем.

В каждом Dial Plan для каждого филиала нужно создать правило: <внутренние номера диапазона филиала> -> <номер автосекретаря>;ext=<внутренние номера диапазона филиала>.

Итого 10*10 = 100 правил

VIP наверняка получат красивые внутренние номера (а значит записанные вразнобой) и для них нужно написать отдельные правила формата <внутренний номер VIP пользователя> -> <городской номер VIP пользователя>;ext=<внутренний номер VIP пользователя>.

Итого 100*10 = 1000 Правил.

1100 правил. При этом любое изменение нужно отразить в 10 местах. Вот почему я так «люблю» формат +74951234567;ext=1234 🙂

Есть кстати еще одна причина. Если у вас имеется сопряжение с другими АТС и номер от другой АТС пришел к вам после преобразований формате +74951234567;ext=1234, в клиенте вы увидите только +74951234567.  Причем, с номерами, начинающимися на «+1» такой проблемы нет. Может на тот момент когда вы читаете эту статью, проблема уже исправлена, но я застал её и в OCS и Lync Server. 

P.S.

Давно не писал статьи, так что считайте эту своего рода извинением перед читателями. Уверен, что читать её было сложно, но до сих пор столько фактов по обработке вызовов в Lync Server в одном месте я не встречал.

Реклама

А вы готовы к Lync Mobile?

12.12.2011

Ждать выхода Lync Mobile осталось совсем немного. Счет идет на дни, если не на часы.

На Microsoft Download уже можно скачать «надстройку» над Lync Server (Mobility Service), необходимую для работы Lync Mobile (требует установки четвертого пакета обновлений для Lync Server).

Там же выложено руководство по настройке функционала Mobility.

Кроме того, CHM файл, включающий полное руководство по работе с Lync Server, также был обновлен.  Поиск по слову «Mobile» в файле выдает на 105 результатов (страниц руководства, где слово встречается) больше, чем в старой версии файла. В общем, работа была проделана немаленькая.

Некоторые особо активные участники Интернет-сообщества уже успели написать и выложить на всеобщее обозрение короткие пошаговые инструкции по настройке функционала Mobility.

Пошел обратный отсчет 🙂

Первым должен выйти клиент для Windows Phone. Ищите на Microsoft MarketPlace. За ним подтянутся клиенты для iPhone, iPad, Android, Symbian. Клиента от MS для Blackberry не будет. Но не потому, что данную платформу проигнорировали, а потому что производитель смартфонов Blackberry уже все сделал сам 🙂

Сопряжение с SIP-системами в продуктах серии Communications Server. От Trusted Host до Trusted Application.

21.11.2011

Статья выросла из так и ненаписанного комментария к веб-касту Илгиза Мамышева и Александра Станкевича, описывающему сопряжение Lync Server c системы видео конференций (ВКС) от компании Polycom. Один из вопросов, прозвучавший во время веб-каста и так и оставшийся без ответа, касался назначения настройки Trusted Application и Static Route на стороне Lync. Начав писать про эти настройки, я понял, что формат комментария не подходит. Кроме того, в голове родилась мысль одного эксперимента, но об этом позже.

Как это было…

Мало кто знает, но через LCS 2005 уже можно было звонить по протоколу SIP на другие IP-АТС. Без роли Mediation (так нелюбимой многими в OCS 2007 и OCS 2007 R2 за необходимость выносить её на отдельный сервер), без проприетарного кодека RTAudio и, даже, без пресловутого E.164.

Все взаимодействие с телефонными станциями и системами видео-конференций в LCS 2005 настаивалось на двух вкладках: Host Authorization и Routing.

Разделение довольно простое: Host Authorization определяет, от кого могут приходить SIP-сообщения, Routing – куда отправлять SIP-сообщения в различных ситуациях.

Host Authorization

clip_image002clip_image004

Host Authorization (ныне Trusted Application) отвечает за две вещи: возможность входящих вызовов от SIP-адресов из других доменов и возможность регистрации абонентов в LCS/OCS без необходимости аутентификации.

Допустим у нас есть:

  • организация LCS/OCS/Lync (SIP-домен mydom.ru);
  • пользователь Вася c SIP-адресом vasya@mydom.ru;
  • сервер ВКС от компании Polycom.

Мы можем создать домен polycom.mydom.ru и пригласить в конференцию пользователя vasya@mydom.ru от имени конференции Meet-room@polycom.mydom.ru.

А можем создать учетные записи для нужных нам комнат в Active Directory, настроить их на работу с LCS/OCS с именами Meet-roomXX@mydom.ru и настроить сервер Polycom на регистрацию комнат в LCS/OCS без необходимости аутентификации. В этом случае пользователи будут видеть статус доступности комнат. Как минимум: On-Line, Off-Line. А в приглашении Вася увидит не SIP-адрес, а нормальное имя конференции, указанное в поле Display Name учетной записи, используемой конференцией.

Данный механизм можно использовать для подключения к LCS/OCS (для Lync не проверял) стандартных (не заточенных под решение от MS) SIP-телефонов, спотыкающихся на этапе аутентификации. Абсолютно противопоказано с точки зрения любых политик безопасности, но поиграть можно.

Routing

clip_image006

Routing (ныне Static Routes) определяет, куда отправлять вызовы, в которых получателем значится определенный SIP-адрес (убрали в OCS) или любой адрес из указанного SIP-домена.

В предыдущем примере, если мы хотим, чтобы пользователи могли звонить в конференцию Meet-room@polycom.mydom.ru, нужно создать маршрут, описывающий на какой сервер и в каком виде слать сообщения для домена polycom.mydom.ru или пользователя Meet-room@polycom.mydom.ru.

Можно указать свой SIP-домен (в примере mydom.ru). В этом случае в сторону маршрута будут уходить вызовы на имена формата <имя>@mydom.ru, которые не зарегистрированы в LCS/OCS. В LCS/OCS можно указать, что маршрут будет использоваться для вызовов на телефонные номера (Phone URI). Этот параметр нужен для настройки RCC или маршрутизации телефонных вызовов.

Безопасность

Коммуникации между LCS/OCS и другим SIP-сервером рекомендуется шифровать. Для этого нужно настроить с обеих сторон отправку/вызовов по протоколу TLS (само собой, требуется установка на серверы сертификатов безопасности, организация доверия сертификату другой стороны и включения механизма прослушивания TLS).

Federation

Стоит сразу отметить, что Host Authorization и Routing позиционируются для коммуникаций внутри организаций. Для внешних коммуникаций еще в LCS использовался граничный сервер (Access Proxy в LCS или Access Edge позднее).

Приложения

Основное назначение Host Authorization и Routing с точки зрения Microsoft – обеспечение доступа сторонних приложений к LCS/OCS. В первую очередь откликнулись телефонисты (RCC). Во вторую – производители систем ВКС. Как я уже писал, производители IP-телефонии охладели к RCC в «эпоху» OCS 2007 (когда поняли, что MS хочет занять их позиции) и активизировались после выхода OCS 2007 R2 и приближении выхода Lync, когда поняли, что у MS может получиться. С производителями ВКС ситуация похожа.

Конференции

Забавно, но только сейчас интеграция Lync с Polycom выходит на уровень, имевшийся во времена LCS 2005 SP1. Связано это, пожалуй, с излишней самоуверенностью разработчиков OCS.

В LCS 2005 не было своего сервера конференций (MCU), и Office Communicator 2005 был «заточен» под взаимодействие с серверами конференций третьих фирм. См. скриншот.

clip_image008

Производители ВКС писали инструкции по настройке клиентов под их решения, создавали скрипты, выполняющие настройки автоматически и надстройки над Office Communicator 2005, позволяющие создавать конференции на их оборудовании одним кликом.

Уже LCS 2005 при интеграции с оборудованием Polycom была возможность, которая в Lync, при той же интеграции появилась только недавно и то пока находится на стадии беты: возможность выделить несколько человек из списка контактов и создать конференцию, в которой будет видно всех участников.

Вся красота разрушилась с выходом OCS 2007. Мало того, что в MS убрали возможность подключения к сторонним MCU, так еще и изменили формат SIP-сообщений (например, добавили поддержку ICE v12). Производители ВКС «прифигели» от такого «счастья» настолько, что отошли только через год после выхода OCS 2007 R2. А еще через полгода вышел OCS 2007 R2 с поддержкой ICE v19 и опять проблемы сопряжения. Мы поддерживаем работу наших систем c OCS 2007 R2, писали производители ВКС, дописывая мелким шрифтом, что клиент при этом должен оставаться Office Communicator 2007 (не R2). 🙂 Потом конечно поправили и это, но настолько тесной интеграции, как была при LCS 2005, пока что нет.

Настоящее время

В Lync Server интерфейс администрирования был переделан с нуля (не считая куска Response Group, но это отдельная тема), и сопряжение с SIP-серверами у разработчиков было далеко не на первом месте. В последнее время это означает, что функционал остается, но доступен только через PowerShell. 🙂

Так что, вместо вкладок выше, имеем команды

  • XXX-CsTrustedApplicationPool
  • XXX-CsTrustedApplicationComputer
  • XXX-CsTrustedApplicationEndpoint
  • XXX-CsTrustedApplication

и

  • XXX-CsStaticRoute
  • XXX-CsStaticRoutingConfiguration

Кроме того, для сопряжения систем по TCP (без шифрования) придётся еще и руками править файл конфигурации Lync. (Об этом я уже писал в отдельной статье)

В официальной документации информации по командам не так много. К счастью, уже есть неплохие инструкции по настройке RCC от Cisco и сопряжения с оборудованием ВКС от Polycom. Их вы можете использовать (в части настроек на стороне Lync) и при настройке сопряжения с оборудованием других фирм.

Чего ждать

О продолжении банкета пока говорить рано.

Судьба RCC каждую новую версию весит на волоске, прямо как Public Folders в Exchange.

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

От сторонних разработчиков MS не откажется, так что Trusted Application и Static Route никуда не денутся. Может, только опять поменяется интерфейс доступа.

Эксперимент

Описание данного механизма нигде, вроде, не встречалось, но логично предположить, что используя Trusted Application и Static Route, одну организацию LCS/OCS/Lync можно скрестить с другой организацией LCS/OCS/Lync без использования серверов с ролью Edge. Данной идеей я поделился с Александром Станкевичем (известным в Российском IT-сообществе любителем такого рода «асоциальных» экспериментов). Поделился и лег спать, планируя вместе настроить всё в свободное время. А на утро получил письмо, что эксперимент успешно завершен. 🙂

… Тут у нас с тезкой должен быть спор на 5 листов, сколько технической информации для эксперимента я ему дал и сколько он сам накопал, но вырезано цензурой для сокращения объема статьи. Ожидайте предложения в комментах 🙂 …

В общем, имеем: организация Lync, организация OCS 2007 R2.

Настроено сопряжение по протоколу TLS, используя Trusted Application и Static Route со стороны Lync и Host Authorization и Routing со стороны OCS.

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

Lync и SIP. Объявление медиа-возможностей и ошибка КПВ

12.10.2011

Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.

Домашнее задание

Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.

Как и в прошлый раз, я выложил разбор в отдельный PDF.

Несколько коментариев:

  1. Как видно из SDP, H.263 в реализации от MS не будет принимать/передавать разрешение больше чем CIF. Только используя 121 x-rtvc1/90000 можно добиться VGA и HD разрешения приема/передачи видео. Поэтому, при сопряжении Lync / OCS c большинством  систем ВКС, качество видео будет довольно низким.
  2. Ответ на вопрос про Communicator for MAC, заданный в предыдущей статье, также довольно прост. Поддержки H.263 в нем нет. Остается только проприетарный кодек от MS. А если двум системам не удалось найти общий кодек – соединение данного типа не будет установлено. Вот и получится – организовывали видео-вызов (голос + видео) – получили просто голосовой.
  3. Если посмотреть на SDP приглашения отправляемого от Lync на голосовой шлюз, вы увидите только два голосовых кодека: G.711 в его двух разновидностях.  Забавно, что убрали RTAudio. Производители шлюзов уже давно были на низком старте, готовые включить данный кодек в следующую прошивку, как только MS даст разрешение. А тут такой облом. 🙂 Зачем? Почему? Ни RTAudio, ни G.729.
  4. Доступные разрешения видео-вызова при использовании RTVideo зависит от мощности рабочей станции и настроек Lync Server. Подробности тут.

Разбор ошибки с отсутствие гудков

Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках.  Проще говоря, отсутствие гудков.

Идеальная ситуация

Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:

   

Сигнал КПВ генерирует голосовой шлюз, непосредственно подключенный к аналоговым/цифровым телефонным линиям. При IP-to-IP вызовах сеть передачей КПВ вообще не нагружается, так как КПВ генерирует сам вызывающий клиент, получив 180 Ringing.

Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).

Истоки проблемы

В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так:
 
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь.
 
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.

Ответ 183 Session  Progress и RFC

Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP: 
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified.  The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress

Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен,  но голосовые пакеты еще не пошли, то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation.  For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:

  1. Unless a 180 (Ringing) response is received, never generate local ringing.
  2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
  3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
  4. Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.

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

Реализация Early Media от MS

MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP.
Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.


 
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183 Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!

Что имеем

Проблему решили, но, в результате получили новую. 🙂 Идеей загорелись, и ответ 183 Session progress начали передавать даже в сторону голосовых шлюзов/IP-АТС. Однако, как оказалось, ответ 183 Session progress — одна из давних головных болей IP-АТС. Одни IP-АТС перестают отдавать КПВ, получая ответ 183, содержащий SDP, и ждут, когда пойдет голосовой трафик. У других «сносит крышу» от ответа 183, не содержащего SDP. А  теперь еще и Microsoft, в продуктах которого традиционно почти нет настроек сопряжения с продуктами «партнеров».
Некоторые производители в очередных обновлениях по просьбам трудящихся добавили корректную обработку 183 Session progress (Например, Avaya). Другие предлагают срезать приходящие ответы 183 от Microsoft (Cisco).
Один из инженеров MS даже написал плагин для OCS 2007 R2, генерирующий КПВ пока не будет установлен настоящий вызов. Но, видимо, это шло вразрез с политикой партии, и в Lync Server данный функционал  добавлен не был.
В общем, пока проблема есть и решается индивидуально. Так и живем….

P.S.

Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.

Lync на SMB рынке. Разбор одного случая

13.08.2011

Наткнулся недавно на интересную статью. Автор описывает свои впечатления от установки Lync Server 2010.
Читая, отмечал про себя ошибки, допущенные автором, и пытался проанализировать ситуацию с разных сторон.

Разбор действий

  • Требования к дополнительным компонентам легко найти в документации, на которую есть ссылка из мастера установки. Planning for Microsoft Lync Server 2010 > Determining Your Infrastructure Requirements > Determining Your System Requirements > Additional Software Requirements.
  • SQL потребовался потому как в Topology Builder была выбрана установка Enterprise версии продукта, отличающаяся от Standard только наличием высокой доступности, которая, собственно, и требует выделенного сервера (в идеале, кластера) SQL. Видимо, устанавливающий решил что версия Enterprise имеет больший функционал. Избежать этой ошибки можно было изучив лицензирование Lync Server либо воспользовавшись инструментом c говорящим названием Lync Server 2010 Planning Tool. Ссылка на инструменты также имеется в мастере установки Lync Server 2010.
  • Ну и раз уж был выбран Enterprise Pool – для него нужно создать запись в DNS. Можно было бы это сделать автоматически, но вдруг у вас имя доменная часть пула отличается от AD и совпадает в SIP доменом. А SIP домен обслуживают другие серверы.
  • Кроме того, для автоматического поиска северов тоже нужны записи в DNS. Об этом говориться в документации в разделе по планированию внедрения (что логично) и в инструменте Lync Server 2010 Planning Tool, упоминавшемся ранее.
  • Silverlight устанавливается при установке Lync (хотя как раз это можно и не заметить), а к консоли администрирования можно подключаться по сети из веб браузера. Адрес консоли есть в Topology Builder в разделе Simple URL. Даже если там пусто – консоль доступна по адресу HTTPS://FQDN сервера/sccp. Но эту информацию тоже нужно найти в документации.
  • Про Exchange – всё так и есть. Lync Server без Exchange ставить смысла нет. Никто это не скрывает.
  • А вот информацию, что при отсутствии связи между пользователями, голос и видео передаются через Lync Edge, а не через Front End искать можно очень долго. Странно поведение, хотя и объяснимое. Кстати, трафик конференций идет через Front End, так что удивление бывает еще большим, если доходит до конференций с тремя участниками и сервер Lync Edge не установлен. Общаются двое – нет звука. Общаются трое – звук есть.

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

Оценка ситуации

Точка зрения автора, как представителя ИТ-администраторов, работающих на SMB рынке, понятна из статьи.

С точки зрения Microsoft, продукт нацелен на Enterprise рынок. Lync Server “заточен” под масштабное внедрение. Именно поэтому криво выглядит установка первого сервера. Если у вас нет своего специалиста, прошедшего обучение в сертифицированном центре, пригласите интегратора. При этом маркетинг MS понимает, что SMB тоже можно продать Lyn Server и понимают, что собственными силами ИТ-отдел заказчика легко «завалит» внедрение. Недаром, недавно стартовала новая компания: маленькие интеграторы за маленькие деньги поставят вам один сервер с базовым функционалом (шаблон документации, разработанный в MS прилагается).

ИТ-администраторы, работающие в компаниях среднего и Enterprise уровня, где имеется специализация ИТ-персонала, посоветовали бы автору прочесть документацию перед внедрением нового продукта :-). Также поступят отвечающие на форумах специалисты интеграторов. Но и здесь есть подвох. Документация тоже заточена под внедрение в компаниях уровня Enterprise. Простой инструкции по настройке сервера Standard Edition в ней нет. Вернее есть, но разброса она по всему немаленькому многостраничному документу. Тут требуемые для установки сервера службы, тут описание инструмента Topology Builder в котором описывается топология Lync Server, там указания на дополнительные записи в DNS, для автоматического поиска сервера. В общем, для ИТ-администратора, у которого нет времени головой погружаться в изучение еще одного продукта, более правильным способом будет найти в пошаговую инструкцию на одном из блогов. И хорошо, если инструкция будет написана специалистом, а не коллегой бедолаги админа, который с горем пополам поставил новый продукт и теперь готов рассказать всему миру, как он это сделал.

Статья по ссылке – не единичный случай в моей практике. Периодически слышу подобные замечания. Да и сам, когда-то ставя LCS в первый раз долго удивлялся, почему мастер установки сам не создал нужные записи в DNS. Теперь я это понимаю, а про невозможность установки нужных компонентов Windows удивляюсь до сих пор. Exchange 2010 SP1 это делать криво-косо, но научился. Опять же, это не критично для Enterprise рынка,  но для SMB…

В компании, где я работаю, есть программа поощрений для сотрудников, приносящих полезные идеи, помогающие продвигать бизнес. Если такая программа есть в MS и эту запись читают сотрудники MS – предложите разработчикам сделать отдельный мастер установки для SMB рынка. Чуть больше вопросов. Большое предупреждение c длинным текстом ограничений использования и куча скрытых скриптов :-).
А может, я ошибаюсь, и это не недоработка, а хитрый способ вырастить множество партнеров, которые будут уметь внедрять Lync Server ;-). От представителей одного производителя (не MS), я как то слышал, что они могли бы сделать интерфейс проще, но не будут. Потому как их продукцию продвигают партнеры, внедряющие решение. Если заказчик сам может внедрить продукт, ему не нужны будут партнеры. Значит, некому будет продвигать решение этого производителя. Вот такой забавный расклад.

Lync и SIP. Обзор SDP и разбор SIP сообщения

18.07.2011

Вступительное слово

Данная статья является второй частью рассказа, про использование SIP в Lync Server 2010.

Статья сильно отличается от того что я писал ранее. Даже статьёй данный текст можно только с большой натяжкой. Больше похоже на второй урок. Так что я даже решил воспользоваться терминологией преподавателей.

В документации по Lync часто можно увидеть пример SIP запроса с комментарием типа: «вот так выглядит SIP сообщение, генерируемое в таком конкретном случае». Разобрать что к чему, не проштудировав кучу дополнительной документации довольно сложно. Как понять, на что стоит обращать внимание, что является признаком некорректной работы? Особенно это важно при работе с внешними SIP системами.

Целью первых двух уроков (напоминаю, что это уже второй) является заложить базовые знания SIP/SDP, что поможет в будущем понять непростые взаимоотношения Lync Server с другими устройствами и системами, работающими на базе SIP. 🙂

Итак, сегодня наш урок будет поделен на две части:

  • Вначале – теория. Я постараюсь кратко изложить RFC 4566, описывающий Session Description Protocol (SDP).
  • Потом, вместо практической части, будет разбор одного SIP сообщения, выдернутого из Snooper, включая SDP часть. Так мы закрепим знания первых двух уроков.

Новая тема

Сообщение SDP состоит из множества строк формата <параметр> = <значение> … [<значение>…<значение>].

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

В случае SIP, SDP сообщение вкладывается к SIP сообщение. В этом случае SIP часть считается заголовком сообщения, а SDP часть (или части, если SDP сообщений несколько) включается в тело сообщения.

Большинство параметров SDP и их описание приведены в следующей таблице. Ох и намучился же я, занимаясь этой выжимкой. Собственно, таблица и есть почти вся теория на сегодня. 🙂 Ознакомьтесь с ней и можно приступать к практическому занятию. Жирным шрифтом я выделил параметры, на которые нужно обращать внимание при поиске проблем.

v(protocol version) Версия протокола SDP. Пока – «0».
o(owner/creator and session identifier) <username> <session id> <version> <network type> <address type> <address>Информация об инициаторе сессии: имя абонента, код сессии, сколько раз уже в рамках сессии встречался SDP , тип сети, тип адреса, сам адрес.
s(session name) Имя сессии.
i(session information) Информация по сессии.
u(URI of description) Ссылка на более подробное описание сессии.
e(email address) Почтовый адрес для связи с ответственным за проведение конференции.
p(phone number) Телефонный номер для связи с ответственным за проведение конференции.
c(connection information — not required if included in all media) <network type> <address type> <connection address> Куда следует слать трафик медиа: тип сети, тип адреса, сам адрес.
b(bandwidth information) Максимальная возможная полоса пропускания.
t(time the session is active) <start time>  <stop time>Время начала и конца сессии. 0 0 означает отсутствие. Ограничений
m(media name and transport address)  <media> <port> <transport> <fmt list>Тип медиа (аудио/видео), порт по которому слать поток, транспортный протокол, список поддерживаемых форматов (обычно — кодеков).
a(zero or more media attribute lines)  a=<attribute>a=<attribute>:<value>Без комментариев. Ниже – несколько примеров.
a=rtpmap:  rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]Тип кодека, имя кодека / параметры кодека (обычно – частота дискретизации в герцах).
a=fmtp:Частный случай 2  <format> <format specific parameters>Номер кодека, параметры формата. MS таки образом обозначает используемую полосу пропускания кодека.    
a=candidate Куда слать трафик медиа. Используется когда нужно указать несколько возможных вариантов. Например, при использовании ICE.Подробности тут.

Первичное закрепление

Разбирать будем пришедший на Lync Server запрос (сообщение INVITE) на голосовой вызов с телефона CX 600. пользователь Calling@croc.ru звонит пользователю Called@croc.ru.

Информация скопирована из Snooper. Реальные IP адреса заменены на “(IP адрес)”.

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

Поскольку на странице текст разбора отображается не очень хорошо, я вынес его в PDF.

Итоги урока

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

В следующих статьях/уроках на ту же тему, если они будут, конечно, вы узнаете:

  • почему основной проблемой связки Lync c другими АТС является отсутствие контроля посылки вызова (КПВ, ring back tone);
  • действительно ли нужно, как часто советуют на форумах отключать Refer Support при проблемах с Exchange Auto Attendant;
  • почему у communicator for MAC проблемы  при интеграции с ВКС;
  • на что влияет параметр «AnalogFax» в команде New-CSAnalogDevice;
  • и т.д. и т.п. 🙂

В качестве домашнего задания, предлагаю выполнить подобный разбор пары сообщений на вашем сервере. Кроме того, я специально не стал проводить описание всех кодеков из a=rtpmap:в сегодняшней статье. Считайте это домашним заданием, а правильный ответ будет во время следующего урока по теме 🙂

Lync и SIP. Начальные сведения

25.06.2011

О чем эта статья

В этой статье я постараюсь описать базовые принципы SIP со ссылками на то, как они используются с Lync Server. А если будет настроение и немного свободного времени, то в будущем постараюсь написать несколько более глубоких статей по реализации SIP Lync Server.

К счастью, протокол установления соединений (Session Initiation Protocol, SIP) очень нагляден и прост в разборе. Все сообщения в отличие от H.323 изначально представлены в текстовом виде. Зная логику работы протокола вы не потеряетесь независимо от того каким инструментом был получен журнал вызова.

Кстати, SIP в Lync используется для установления любых типов соединений, а значит, поняв его принципы, вам будут проще выявлять не только ошибки VoIP, но и других аспектов работы Lync Server. (и конечно, не только Lync Server).

Сразу оговорюсь, что в VoIP я далеко не гуру и осилить тот же FRC 3261 пока не сумел. Так что, если будут замечания, пожалуйста, не стесняйтесь.

Для начала, самые простые вещи которые вы можете выяснить, глядя на журнал обмена SIP сообщениями:

  • Номер или sip адрес вызывающего абонента;
  • Номер или sip адрес вызываемого абонента.

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

  • IP адрес и порт источника и получателя сообщения.

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

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

  • IP адрес и порт, на котором ожидается голосовой трафик. На самом деле это уже не SIP, а SDP (Session Description Protocol), но об этом дальше.

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

Справочная информация

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

Основные компоненты SIP

  • UAC (User agent client) – Клиент или тот, кто инициализирует запрос.
  • UAS (User agent server) – Сервер или тот, кто отвечает на запросы UAC.
  • UA (User Agent) – Терминал SIP (SIP телефоны, шлюзы и т.д.), включает в себя UAC или UAS. В зависимости от ситуации (запрашивает или отвечает) играет роль UAC или UAS.
  • Proxy server (SIP Proxy) – Занимается перенаправлением вызовов. Промежуточное звено маршрутизации вызовов.
  • Redirect server – обрабатывает запросы и отвечает на них сведениями о другом пункте назначения.
  • Location Server – Поддерживает базу знаний о терминалах. Соответственно, к этой базе могут обращаться серверы Redirect server и Proxy server для получения информации по маршрутизации вызовов.
  • SIP Registrar – Обрабатывает запросы на регистрацию от терминалов. Либо совмещается с Location Server либо передает Location Server данные по зарегистрированным терминалам.

Обычно выделяют SIP Proxy и SIP Registrar. Опять же, обычно, говоря SIP registrar, имеют ввиду сервер со всеми серверными ролями. А в понятие SIP Proxy включают Redirect server.

Прочитали, поняли и отложили в дальний уголок сознания. 🙂 Главное, что нужно запомнить на первых парах:

  • SIP Registrar, как видно из названия, регистрирует абонентов.
  • SIP Proxy – пробрасывает вызовы между абонентами, если абоненты, не могут общаться напрямую.
  • Любое устройство в рамках SIP может выступать клиентом или сервером.
  • SIP Proxy так вообще обычно сначала выступает в качестве сервера, отвечая на запрос и тут же в качестве клиента инициируя новую транзакцию.

В простейших случаях SIP вызов может идти по следующей схеме.

Терминал SIP ——>Терминал SIP

или

Терминал SIP——>SIP Proxy——>SIP Proxy——>…… ——>Терминал SIP

Что касается Lync Server:

  • Front End объединяет в себе все серверные роли.
  • Сервер Mediation выступает в качестве SIP Proxy для телефонных вызовов.
  • Со стороны Lync Server c сервером Mediation общается Front End, но не клиентское ПО.
  • С точки зрения SIP можно сказать, что внутри сервера Lync Server SBA (Survivable Branch Appliance) сидят маленькие Front End и Mediation.
  • SIP трафик можно обнаружить между различными компонентами SBA (пересылка с порта обслуживающего службу Front End на порт обслуживающий службу Mediation).
  • В Lync Server SIP вызовы всегда идут через SIP Proxy.

Стандартные запросы

  • INVITE – Приглашение на установление сессии.
  • ACK – Хоть и называется «запрос», но на деле — подтверждение ответа на запрос INVITE. В отличие от остальных запросов — не требует ответа.
  • BYE – Прекращение сессии.
  • CANCEL – Отмена еще не установленной сессии.
  • REGISTER – Запрос на регистрацию на Location Server.
  • OPTIONS – Запрос параметров / возможностей терминала. Может использоваться для мониторинга состояния соседа на манер ping. «Вася, ты там жив еще?».

Это запросы, появившиеся в FRC 3261. Остальные были добавлены позже

  • PRACK — На случай, если UAS просит / требует подтверждения получения ответа.
  • SUBSCRIBE — подписка на получение уведомлений о каком-либо событии (например, об изменении статусов контактов в Lync)
  • NOTIFY — Уведомление подписчика о событии.
  • PUBLISH — Публикация события на сервере.
  • INFO — Передача информации, которая не изменяет состояние сессии
  • REFER — Запрос получателя о передаче запроса SIP (Об этом запросе и его реализации в Lync хочется поговорить отдельно. Собственно, это одна из причин, почему я решил начать писать про SIP.
  • MESSAGE — Передача мгновенных сообщений средствами SIP. (Маленькое замечание: первое сообщение Lync шлет вместе с INVITE, поэтому и максимальный объем для первого и последующих сообщений отличается). 🙂
  • UPDATE — модификация состояния сессии без изменения состояния диалога.

Ответы

Ответы в SIP имеют не только имя, но и номер. По номерам они и делятся на категории. Приведу несколько примеров для каждой категории

  • 1XX – просто информация. Обычно тут сообщается, в каком состоянии находится обработка запроса.  Обычно вы будете сталкиваться с тремя типами ответа.
    • 100 – Trying. Запрос получил, разбираюсь, что с ним делать
    • 180 – Ringing. Звоню. Или «кажись, звонят», если отвечает Proxy server.
    • 183 – Session in progress. Что-то между Trying и Ringing. Обычно, Session in progress подразумевает то же что и Ringing, но с одним дополнением. UAS сообщает UAC что сейчас будет Early Media. То есть, будет проиграно некое сообщение еще до установления соединения. Это может быть просто гудок или заранее записанное сообщение автоинформатора. Как раз для этого ответа может потребоваться PRACK. А поведение Lync при передаче Session in progress – вторая причина.
  • 2XX – Ответы об успешной обработке запроса.  
    • 200 – OK. Без комментариев.
    • 202 Accepted — запрос принят для обработки. Используется для справки о состоянии обработки.
  • 3XX –Предложение пойти куда подальше. 🙂 Местонахождение «куда подальше» может прилагаться. Типичные примеры:
    • 302 – Temporarily moved;
    • 305 – Use proxy.
  • 4XX – ошибка клиента:
    • 403 – Forbidden. У вызывающего нет прав на данный вызов;
    • 404 – Not Found. Вызываемый не найден.
  • 5XX – Ошибка сервера.
    • 500 – Server Internal Error;
    • 501 – Not Implemented.
  • 6XX – Обычно эту группу называют «Глобальные ошибки».  
    • 603 Decline. Вызываемый отказался принять вызов;
    • 606 Not Acceptable. Не договорились о параметрах вызова

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

Вы наверно заметили, как часто я говорю «обычно».  Для понимания, приведу выдержку из RFC.

In this document, the key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY», and «OPTIONAL» are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant SIP implementations.

Вот и получается, что в различных реализациях, даже полностью соответствующих RFC, части выделенные «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY» и «OPTIONAL» могут отличаться. А учитывая, что полностью RFC соответствует далеко не каждая реализация SIP 2.0. можете представить, во что выливается сопряжение двух систем различных производителей. 

Как пример, при переадресации по ответам класса 3xx идентификатор сессии может быть сохранен, а может и обновлен (что такое идентификатор сессии, читайте дальше).

Еще немного определений

  • Initiator, calling party, caller – инициатор вызова, вызывающий
  • Invitee, invited user, called party, callee – тот, кого вызывают, вызываемый.
  • SIP Транзакция – обмен сообщениями между клиентом и сервером от первого запроса до последнего (не 1XX)
  • Сессия  – набор отправителей и получателей, а также потоки передаваемых между ними данных.

Session description protocol (SDP)

SDP сообщение включается в состав запросов типа INVITE и представляет из себя объявление возможностей вызывающего по организации дальнейшего взаимодействия вне SIP. То есть, если идет телефонный вызов, то в SDP к INVITE будет, например, перечень поддерживаемых клиентским ПО вызывающего голосовых кодеков и параметры приемы входящего медиа соединения (IP адрес и порт, по которому вызывающий готов принять входящей поток данных).

SIP Proxy может подменить SDP при отправке INVITE дальше, если он будет терминировать медиа трафик на себе.

SIP Proxy может просто подставить свой IP адрес вместо адреса вызывающего, а может и поменять набор предлагаемых кодеков. В этом случае на SIP Proxy будет возлагаться задача транскодинга.  Например, на границе с WAN вы можете захотеть использовать кодек с худшим качеством, но с меньшим объемом передаваемых данных.

Положительный ответ на INVITE (200 OK) также будет включать в себя SDP c описанием возможностей клиентского ПО вызываемого, согласующихся с возможностями клиентского ПО вызывающего. Обычно в ответ включается один кодек, по которому и будет происходить взаимодействие.

Кроме того, SDP обычно включается в ответ Session in progress.

Классика из RFC

Первый пример.

                     atlanta.com  . . . biloxi.com
                 .      proxy              proxy     .
               .                                       .
       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

Начали вызов, прогнали вызов через два SIP Proxy, приняли вызов, инициировали сессию медиа напрямую между абонентами, поговорили и закончили вызов.

Пример вызова из того же RFC. Пока без SDP. Выделенные поля обязательны для любого SIP запроса.

 
INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
      Max-Forwards: 70
      To: Bob <sip:bob@biloxi.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710@pc33.atlanta.com
      CSeq: 314159 INVITE
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: application/sdp
      Content-Length: 142

Устроим разбор.

 INVITE sip:bob@biloxi.com SIP/2.0

Запрос – INVITE на SIP адрес sip:bob@biloxi.com. Версия SIP 2.0

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

Отвечать через терминал pc33.atlanta.com по протоколу UDP и порту SIP по умолчанию (5060) в формате SIP 2.0, указав в качестве идентификатор запроса z9hG4bK776asdhds.

      Max-Forwards: 70

TTL

      To: Bob <sip:bob@biloxi.com>

Звоним на адрес sip:bob@biloxi.com, который в нашей адресной книге записан как Bob. И не знаю, зачем мы передаем имя абонента, которому звоним. 🙂

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

Звонит Alice с адреса sip:alice@atlanta.com с клиента, имеющего в рамках текущего вызова код 1928301774.

      Call-ID: a84b4c76e66710@pc33.atlanta.com

Тут у нас идентификатор Сессии, идентичный для всех сообщений в рамках сессии на всех терминалах.

      CSeq: 314159 INVITE

А тут номер запроса и сам запрос. Для чего это нужно. Например, в рамках сессии сначала может прийти INVITE а потом в ответ на 183 Session in progress будет отправлен PRACK. CSeq поможет определиться на какой запрос пришел ответ 200 ОК.

      Contact: <sip:alice@pc33.atlanta.com>

Указание, куда можно слать ответные запросы.

      Content-Type: application/sdp

К запросу прилагается SDP. Должен идти ниже.

      Content-Length: 142

Типа контрольной суммы.

А самим посмотреть?

Перейдем от теории к практике.

Итак, у нас есть Lync Server, несколько клиентов и некая проблема… ну или Lync Server, несколько клиентов и немного любопытства. 🙂

Для начала, заходим на Lync Server и запускаем Lync Server 2010 Logging Tool.

Lync Server 2010 Logging Tool

clip_image002

В Logging Tool выбираем SIPStack. Изменять собираемые данные не нужно. Теперь нажимаем Start и повторяем операцию, которую хотим отследить. Например, голосовой вызов коллеге по работе.

Останавливаем сбор данных. Теперь нажимаем кнопку view log files и … убеждаемся что без пол-литры  аналайзера копаться тут можно долго и упорно. 🙂 Закрываем текстовый файл,  нажимаем в Logging Tool кнопку analyze и …. получаем сообщение о том, что нам чего-то нехватает. А нехватает нам Lync Server 2010 Resource Kit Tools, которые мы и скачиваем тут.

Установив Lync Server 2010 Resource Kit Tools, снова нажимаем analyze, но на этот раз уже наблюдаем инструмент под названием Snooper.

Нас интересует вкладка Messages.

clip_image003

Вбейте в поле фильтра через пробел ваш login и login вашего коллеги и наблюдайте перечень сообщений, которыми обменивались ваши клиенты Lync с Lync Server.

Конечно, не так удобно, как на картинке нарисованной псевдографикой выше, но уже лучше, чем в файле с непроизносимым названием, в который сохраняются журналы из Lync Server 2010 Logging Tool.

Советы по работе с инструментом можно найти тут

Wireshark

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

Скачиваем инструмент Wireshark и устанавливаем его на сервер Mediation вместе с предлагаемым в процессе установки PCAP. 

Запускаем в Wireshark сбор данных, набираем в поле фильтра SIP (не забыв нажать Enter) и инициируем вызов.

Наблюдаем сессию в реальном времени. В нижней части можно разобрать как SIP сообщение выбрав строчку с ним в верхнем.

clip_image005

Но это не самое интересное. Выбираем Telephony/Voip Calls. Выделяем выполненный вызов и жмем Flow.

clip_image007clip_image009

clip_image011

Вот это я понимаю. 🙂 Такую бы схемку да в Snooper. Видно схему вашего успешного (или не успешного, как в примере) вызова. Причем, если удалось перехватить сессии с несколькими участниками – на схеме увидим несколько колонок. Можно выбрать любую строчку и вернуться в основное окно. Вы окажетесь как раз на нужном сообщении.

Трафик между клиентами и серверами Lync обычно шифрован, так что так просто его не соберешь. Однако возможность расшифровать сетевой трафик Lync есть через плагины для Wireshark. Мне проще нужные вещи посмотреть в  Lync Server 2010 Logging Tool, тем более, что включив журналирование других данных, там можно узнать намного больше подробностей сессии, таких как логику обработки сообщений. Но об этом в другой раз.

Напоследок, несколько примеров из Snooper

1. Подписка на статус контакта. Вырезаны имя пула и имя Front End. DIAGNOSTIC – внутренняя информация сервера, которая никуда не отсылается.

clip_image013

Имя  контакта находится в теле запроса (вырезано желтым)

  clip_image015

2. Оповещение о статусе контакта. Вот и пример отхода от RFC. BENOTIFY – тот же NOTIFY но без необходимости ответа. В результате — меньше нагрузка на сервер.

clip_image017

3. Голосовой вызов Lync-to-Lync. (вставлю на неделе) 🙂

Журнал с точки зрения Lync Server.

  1. In INVITE. Получили запрос от абонента «А» (c SDP).
  2. Out 100. Ответили абоненту «А», что работаем над установлением соединения
  3. Out 183. Ответили абоненту «А», что работаем над установлением соединения. (без SDP)
  4. Out INVITE. Переслали запрос абоненту «Б» (c SDP).
  5. Out 101, Ответили абоненту «А», что работаем над установлением соединения.
  6. In 100, In 180. Получили от абонента «Б» ответ, о что вызов обработан и ожидается полднятие трубки.
  7. Out 180. Ответили абоненту «А», что вызов поступил абоненту «Б» .
  8. In 183. Получили от абонента «Б» ответ с параметрами соединения (с SDP).
  9. Out 183. Переправили абоненту «А»  ответ абонента «Б» с параметрами соединения (с SDP).
  10. In PRACK. Получили от абонента «A» запрос с подтверждением получения ответа. 🙂
  11. Out PRACK. Переслали запрос  PRACK абоненту «Б».
  12. In 200 OK. Получили ответ на PRACK от абонента «Б».
  13. Out 200 OK. Переправили абоненту «А» ответ абонента «Б».
  14. In 200 OK. Получили ответ на INVITE от абонента «Б» (c SDP).
  15. Out 200 OK. Переправили абоненту «А» ответ абонента «Б» (c SDP).

Если будут пожелания или вопросы по статье – оставляйте / задавайте их тут. Вопросы по трабшуттингу Lync Server лучше писать на форумы Technet в раздел Lync Server 2010.

 

Размышления о высокой доступности UC решений от MS

18.05.2011

Сколько минимум серверов нужно для построения UC решения от решения Microsoft с обеспечением высокой доступности?

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

Обеспечение высокой доступности UC от Microsoft c минимальными затратами но сохранением поддержки 🙂

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

Начну с критики в адрес Microsoft. Это гигантская компания и разные подразделения зачастую не могут не то что, влиять на разрабатываемые в других подразделениях решения, но даже договориться J.

Нет, ну честно, несколько вопросов касающихся взаимодействия продуктовых групп внутри MS, решение которых позволило бы, как минимум, снизить стоимость внедрения Unified Communications от MS:

1. Конфликт network load balancing (NLB) и Failover Cluster. В результате невозможно поднять Exchange 2010 с высокой доступностью, используя только серверные лицензии Windows Server / Exchange 2010 и не имея балансировщиков нагрузки сторонних производителей. Требуется, как минимум, два сервера Exchange с ролью Mailbox Server (MB), объединенных в Database Availability Group (DAG )и два сервера с ролями Client Access Server (CAS)и Hub Transport Server (HUB) где роли CAS балансируются посредством службы Windows NLB.

clip_image002

2. Отсутствие в network load balancing возможности определения сессии по cookie для веб трафика и контроля за балансируемыми службами. Технологии network load balancing уже много лет, а с Windows Server 2003 изменения косметические. Про конфликт с Failover Cluster я уже написал. Второй момент, который вполне можно было бы реализовать – настройка различных способов определения сессии, как делается в нормальных балансировщиках сетевой нагрузки (affinity, как называют это в MS, или persistence, как это называют в остальном мире). Ну а третий, возможность мониторинга служб, балансировка которых выполняется. Хотя бы банальным telnet. В результате, решение от MS (Microsoft Lync Server / Microsoft OCS) не поддерживает собственный механизм балансировки нагрузки.

clip_image004

3. Отсутствие поддержки механизма SQL Database Mirroring в Microsoft Lync Server 2010 для обеспечения высокой доступности баз данных. Мало кто готов тратиться на СХД с синхронной репликацией, а без SQL Database Mirroring это единственный способ хотя-бы приблизить высокую доступность Microsoft SQL к пресловутым пяти девяткам.

clip_image006

Казалось бы

clip_image008

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

Попробуем оптимизировать

Что ж, значит, если мы хотим сэкономить, нужно искать маленькие хитрости. Хитрости как обычно рождаются на стыке стандартных возможностей, так что о них и поговорим. Но сначала небольшое предупреждение. Как я уже писал ранее, в данной статье рассматриваются только поддерживаемые производителем решения.

1. Виртуализация. Зачем покупать 4 физических сервера под Exchange (2 MB и 2 CAS+HUB), когда можно купить два и поднять на каждом узле по одному виртуальному серверу с MB и одному с CAS+HUB. Затраты уже меньше а высокая доступность не страдает. Все компоненты Exchange Server и все компоненты Lync Server полностью поддерживаются в виртуальной среде. Поддержка серверов Exchange с ролью Unified Messaging, кстати, была объявлена на днях.

clip_image010

2. Строим единое решение :-). Если у вас уже используются балансировщики нагрузки (например, для lync Server), вы можете развернуть все роли Exchange Server 2010 (кроме Edge конечно), на двух серверах с сохранением высокой доступности. Правда стоят они обычно в России дороже чем хорошие серверы, но и тут есть нюанс. И еще моя маленькая гордость 🙂

Небольшое отступление. Балансировщики нагрузки в виде виртуальным машин (software load balancers или load balancers as virtual appliance) для Exchange Server поддерживаются давно. Поддержки же их для OCS / Lync еще год назад не было. Но несколько месяцев назад мне повезло оказаться на тренинге, проводимым продуктовой группой Lync, по бете продукта. На мои вопросы касательно поддержки Database Mirroring и NLB положительный ответ от выступающего представителя продуктовой группы, занимающейся обеспечением высокой доступности, не последовал. 🙂 На вопрос, почему поддерживаются только аппаратные балансировщики нагрузки, ответ был – потому что у программных версий недостаточный функционал. После выступления я поймал выступающего и 15 минут объяснял ему разницу (а вернее её отсутствие) между поддерживающимися тогда аппаратными балансировщиками Citrix Netscaler и их виртуальными копиями Citrix Netscaler VPX. Через 3 недели Citrix Netscaler VPX появились в списке поддерживаемых балансировщиков для OCS 2007 R2.

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

На каждом сервере запущены следующие виртуальные машины: Exchange Server (MB+CAS+HUB), Lync Server Front End, SQL Server, балансировщик нагрузки в виде Virtual Appliance, балансирующий трафик для Lync и для Exchange в части CAS.

Если требуется телефония, самый дешевый вариант – обойтись без дополнительных виртуальных машин и голосовых шлюзов, совместить роли Lync Server Front End с Lync Server Mediation и организовать до оператора SIP trunk. Но тут очень много маленьких нюансов, ограничений и подводных камней. Так что это уже на свой страх, риск и геморрой.

3. Послабление требований. Допустим, из всего функционала Lync для вас критичным является только телефония. И Вы готовы ради существенной экономии на время восстановления какого-либо компонента решения отказаться от IM и различных конференций. В этом случае Вам уже не требуются жутко дорогие дисковые хранилища с синхронной репликацией. Ведь в случае выхода из строя кластера SQL, телефония Lync всё рано будет работать. А если вы готовы на 5-10 минут остаться без телефонии в случае непредвиденной ситуации, вы можете отказаться и от SQL серверов вообще и перейти на использование двух серверов Lync Server Standard вместо кластера Lync Server Front End. Об этом я уже писал в одной из статей.

4. Хостинг. Тут, как говорится, без комментариев. И без затей. Зачастую, самый дешёвый способ обеспечения высокой доступности решения это обеспечение высокой доступности канала в Интернет и использование хостинга. Даешь облака!  🙂 Кстати, Lync Server в облаке пока еще не доступен широкой публике хостеров и есть только у MS, да и в России пока Office 365 отсутвует. Минусы и плюсы, думаю, каждый для себя найдет сам.

Итого

Вывод простой и короткий. Идеального решения, как всегда, пока нет и наверно не будет. Оптимальное — подбирается исходя из имеющихся возможностей и требований. 🙂

Последние новости MS UC кратко и в порядке увеличения значимости

18.05.2011

Новые обновления для Lync Server. Если честно, последние обновления для Lync Server всегда доступны тут. Делюсь ссылкой.

Поддержка SQL Server 2008 R2 для Lync Server 2010 с формулировкой: «Мы проверили и проблем не нашли».

Поддержка виртуализации для Exchange Unified Messaging. Давно пора. Не понимаю, чего ждали. Даешь UC решение с высокой доступностью на двух физических серверах! Подробности в отдельной статье.

Поддержка RTV в Polycom HDX (за приблизительно 1500$) и Polycom RMX (бесплатно, если ресурсов хватит для новой прошивки). Кроме того, HDX теперь будет поддерживать протокол CCCP, что позволит с HDX принимать участие в конференциях организованных на Lync Server.

Ну и само собой, покупка Skype. Обнаружил кучу форумов с обсуждением покупки. Зачем купили? Что будет? Странные люди. Причин для покупки куча, начиная от аудитории продукта, продолжая выходами в ТфОП которые можно использовать для Office 365 и заканчивая защитой от покупки Skype конкурентами. С тем, что будет дальше, еще проще. Пока покупка юридически не завершится о прогнозах говорить рано. А юридические формальности отнимут не один месяц. Так что в краткосрочной перспективе покупка ничего не принесет.  А в долгосрочной MS хочет получить схему, когда их продукты используется и на предприятиях (Lync) и дома (Skype), при этом продукты заточены под свои сегменты (тот же compliance для предприятий), но коммуникации между продуктами максимально бесшовные, а интерфейс максимально похожий. Это и без аналитиков понятно.

Очередной набор старостей UC от Microsoft

08.04.2011

1. Вышел набор обновлений для Lync. На этот раз только клиентские обновления и обновления Group Сhat

2. Blackberry Enterprise теперь поддерживает работу с Lync Server на манер Outlook Web App. Информация честно взята тут

3. Раздел форумов TechNet по Forefront для OCS был жестоко заспамлен. Туды им и дорога. Пока про Forefront для Lync ни слуха не духа 🙂 Информация о спам атаке найдена тут.

4. Скоро стоит ждать книги по Lync 2010. Достанется и админам и разработчикам. Кстати, писатели первой книги порадовали. Оптимисты 🙂 Еще не понятно, что будет раньше – очередной релиз Lync Server или поддержка SQL 2008 R2, а в книге уже есть главы по установке и настройке как раз той версии SQL Server для работы в качестве сервера баз данных Lync Server 2010.

Официальный Recourse Kit Book тоже готовится, но будет еще не скоро. Сами писатели говорят, что будет много вкусного… Увидим.

5. В ближайшее время стартует серия вебинаров по Office 365. Если вам интересна эта тема – присоединяйтесь. Напомню только, что пока официальных анонсов от MS о сроках появления Office 365 в России не поступало. Поправьте, если я не прав.

6. Вышли экзамены по Lync Server 2010

Кстати, в бете они были доступны еще в конце прошого года, так что один из LOGO, которые я сгенерил на mcp.microsoft.com теперь выглядит так

отрывок из transcipt прилагаю

Русификация Lync

20.02.2011

Продолжение, и, отчасти, корректировка статьи «Первый пакет обновлений для Lynс 2010 + немного русификации»

На сегодня в Lync русифицирована вся клиентская составляющая, включая серверные компоненты доступные клиентам (Lync Web App, голосовое меню).

Lync Client x32 Trial (RUS)

Lync Client x64 Trial (RUS)

Lync Client x32 (MUI)

Lync Client x64 (MUI)

Lync Attendant x32 (RUS)

Lync Attendant x64 (RUS)

Lync Attendee (RUS)

Lync Web App hotfix (Multilanguage)

Lync Phone Edition v. 7577.107 для Polycom CX700 и LG-Nortel IP Phone 8540 (RUS)

Lync Phone Edition v. 7577.107 для Polycom CX500, Polycom CX600 и PolycomCX3000 (Multilanguage)

Lync Phone Edition v. 7577.107 для Aastra 6721ip и Aastra 6725ip (Multilanguage)

Про Group Chat я умолчал, потому как не считаю его частью Lync. Улыбка Вот когда в единый клиент функционал Group Chat добавят, тогда и можно будет что-то обсуждать.

Расчет каналов для Lync 2010

19.02.2011

Введение

calculatorОдним из нововведений Lync Server 2010 стало появление стандартного для IP-АТС механизма ограничения вызовов по WAN-каналам (Call Addition Control, CAL). Подробно об этой технологии уже писал Николай Муравлянников в статье «Новые возможности Microsoft Lync Server 2010 (Часть 1). Контроль допуска звонков в Lync Server 2010 (Call Admission Control)»

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

Механизм CAC, реализованный Microsoft, существенно отличается от общепринятого. У администраторов нет прямого контроля над списком доступных аудио/видео-кодеков и количеством вызов. Можно лишь задать максимальную используемую Lync под голос (Audio Limit) и видео (Video Limit) полосу пропускания и максимальную полосу пропускания одной сессии (Audio Session Limit и Video Session Limit соответственно).

Параметры кодеков

Каждый аудио/видео-кодек имеет ряд параметров. Адаптивные кодеки могут эти параметры менять на лету.

Время пакетизации: 20, 40, 60 мс. Чем больше время разговора, передаваемое за один раз, тем больше задержка в передаче, но тем меньше накладные расходы на передачу (меньше суммарный объем различных заголовков)

Частота дискретизации: Narrowband (8 КГц), Wideband (16 КГц), Ultra-Wideband (32 КГц). Не буду вдаваться в подробности (вспоминаем теорему Котельникова из курса физики), но чем больше частота дискретизации, тем естественнее голос. Но и информации при этом передается значительно больше.

Коррекция ошибок (Forward Error Correction, FEC): ВКЛ, ВЫКЛ :-). Избыточность данных, помогающая восстановить данные при искажении / потери части пакетов в канале.

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

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

Время пакетизации увеличивается в последнюю очередь. В официальной документации MS даже нет информации о полосе пропускания кодеков при значениях 40 и 60 мс. Дело в том, что задержка от времени пакетизации складывается с другими и, в конце концов, может превысить допустимые для нашего мозга 300 мс. RTT (туда обратно). При этом ответ собеседника придёт позже, чем мы ожидаем, и мы непроизвольно уточним, слышат ли нас с другой стороны. В результате, мы перебьём начавшего было говорить человека :-).  Секунд 5 будет потрачено на «АЛЛО АЛЛО». Затем начнется общение, но с внутренним дискомфортом (мозг от таких асинхронных коммуникаций входит в ступор). Думаю, с таким все сталкивались при звонках на дальние расстояния.

Кодеки Lync

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

Пока лишь уточню, что кодеки RTAudio и RTVideo были несколько лет назад куплены MS и теперь постоянно дорабатываются, а кодеки Siren и G.722 лицензированы у компании Polycom.

Еще замечу, что RTAudio позиционируется MS как супер-адаптивный кодек. Но пока у него есть два ограничения: не предназначен для конференций и имеет не самые низкие требования к каналам (там где тот-же Skype работает стабильно, RTAudio может начать проседать).

Теперь пора привести таблицы из документации к Lync Server 2010 по кодекам продукта, которые предлагается использовать для планирования каналов.

Таблица планировании аудио / видео сессий точка-точка
Тип медиа трафика кодек Средняя занимаемая полоса пропускания (Кбит/с) Максимальная занимаемая полоса пропускания без FEC Максимальная занимаемая полоса пропускания с FEC
Audio RTAudio Wideband 39.8 62 91
Audio RTAudio Narrowband 29.3 44.8 56.6
Main video CIF RTVideo 220 260 нет
Main video VGA RTVideo 508 610 нет
Main video HD RTVideo 1210 1510 нет
Panoramic video RTVideo 269 360 нет
Таблица планировании аудио / видео конференций
Тип медиа трафика кодек Средняя занимаемая полоса пропускания (Кбит/с) Максимальная занимаемая полоса пропускания без FEC Максимальная занимаемая полоса пропускания с FEC
Audio G.722 46.1 100.6 164.6
Audio Siren 25.5 52.6 68.6
Main video CIF RTVideo 220 260 нет
Main video VGA RTVideo 508 610 нет
Panoramic video RTVideo 269 360 нет
Таблица планирования вызовов в город
Тип медиа трафика кодек Средняя занимаемая полоса пропускания (Кбит/с) Максимальная занимаемая полоса пропускания без FEC Максимальная занимаемая полоса пропускания с FEC
Audio G.711 64.8 97 161
Audio RTAudio Narrowband 30.7 44.8 56.6

А теперь несколько советов и немного малоизвестной информации

Собственно, ради чего данная статья и затевалась. Надеюсь, информация в данном разделе будет для вас полезна.

Microsoft рекомендует не выставлять Session Limit для аудио вызовов. Поскольку количество вызовов можно спрогнозировать, а требуемую полосу пропускания вычислить – рекомендуется заранее планировать и закупать каналы с необходимой полосой пропускания. Сразу предвижу контраргументы, думаю в России их видят все, так что пожалуйста, опустим в комментариях разговоры про дураков и дороги и про бизнес, IT и деньги :-).  Качество VS затраты. Так было всегда.

Как вы видите на таблицах выше, для конференций и для вызовов «точка-точка» используются разные аудиокодеки. Это нужно учитывать при задании ограничений. Если, например, указать Audio Session Limit, равный 44,8, — этого хватит для вызовов «точка-точка», но конференции если и будут идти, то с повышенным временем пакетизации, что может вызвать негативную реакцию пользователей.

Если уж указывать ограничение для голоса, то коллеги из MS рекомендуют выставить Audio Session Limit в районе 65. В этом случае мы получим кодек хорошего качества RTAudio Wideband на стабильных каналах, а в случае проблем, автоматически переключимся на кодек приемлемого качества RTAudio Narrowband, но с коррекцией ошибок. Конференции тоже продолжат работать, но с небольшими задержками.

Audio Session Limit и Audio Limit ограничивают не только лимит аудиовызова, но и лимит аудиочасти в видеовызовах. Не совсем понятно из документации.

Поэтому, если вы выставили альтернативный маршрут для голоса, то голос в рамках одной сессии может идти одним маршрутом, а видео – другим.

Для расчёта, стоит ли пускать еще один голосовой вызов, Lync Server вычитает суммарную максимальную пропускную способность всех текущих вызовов в канале из Audio Limit, вычитает из полученного значения Audio Session Limit и если результат положительный — пропускает вызов. То же и с видео-вызовами.

Поясню на примере:

Допустим, мы выставили Audio Limit в 1024 Кбит/с, a Audio Session Limit в 100 Кбит/с. В текущий момент в канале идет 14 вызовов RTAudio Wideband без FEC (62 Кбит/с). Вызов делает 15-й пользователь. Lync Server делает расчет “(1024 — 62*14) – 100”, получает положительное число 56 и пропускает вызов.

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

Расчет трафика.

Теперь, когда мы приблизительно знаем параметры наших вызовов, мы можем подсчитать предполагаемый объем трафика в канале за день/неделю/месяц. Для этого нам потребуется дополнительная информация, которую обычно не так сложно получить, а именно время в секундах, которое в среднем тратят сотрудники на телефонные переговоры между площадками за отчетный период. Данные можно получить от оператора телефонии (придётся обработать) либо собрать с вашей уже существующей АТС, если ведется отчетность.

Зная суммарное время, умножаем его на значение из столбца «Средняя занимаемая полоса пропускания» таблиц выше для выбранного кодека.

При переходе на IP-телефонию реальные значения будут несколько выше по понятным причинам, но приблизительное представление о предстоящих расходах, если у вас не безлимит, вы получите.

Это интересно. Архив переписки.

03.02.2011

Возможность централизованного хранения истории обмена мгновенными сообщениями была еще когда Lync Server назывался Live Communications Server. И с тех пор концепция не поменялась. Вся переписка проходит через серверы с ролью Front-End. Есть сервер архива (Archiving Server), забирающий по средствам Microsoft Message Query сообщения c этих серверов и сохраняющий в базу данных SQL. Высокая доступность сервера архива не поддерживается, но можно настроить выключение серверов Front-End обслуживаемых сервером архива при его недоступности. Если безопасность не может прочесть ваше сообщение – вы его не отправите (злобный смех за кадром)

В Lync Server в работу сервера архива внесена пара небольших изменений.

Во-первых, появилось возможность архивировать не только мгновенные сообщения, но и содержимое проводимых конференций: выкладываемые файлы и презентации PowerPoint.

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

Допустим сервер архива у вас уже настроен и необходимо получить переписку какого-либо сотрудника за некий период времени. Для этого в Lync Server Management Shell запускаем команду Export-CsArchivingData, например, так:

Export-CsArchivingData -UserUri «adonin@croc.ru» -DBInstance SQLServer -StartDate «2/3/2011» -EndDate «2/4/2011» -OutputFolder «c:\temp»

Кстати, в описании команды ошибка. Параметр -EndDate указан как необязательный, но если его не указать будет экспортировано 0 сообщений. Из них 0 с ошибкой 🙂

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

clip_image001

К сожалению формат писем выбрать нельзя. EML – стандарт для Windows Mail и Windows Live Mail так что просто подсовываем письма соответствующий в клиент и ищем/читаем/изучаем

clip_image003

Для работы с архивом из MS Office Outlook вначале нужно изменить формат писем на MSG. Для этого можно воспользоваться, например, бесплатным плагином к Outlook от OUTLOOK FREEWARE.

clip_image005

Это интересно. Добавляем участников в телефонную конференцию.

31.01.2011

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

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

  1. На время дозвона вызывающий «отключается» от вызова и не может продолжать разговор. Время тратится впустую;
  2. Если идет конференция, то временно отсоединившейся участник может передавать «музыку на удержании», чем будет мешать обещаться остальным;
  3. Есть возможность проинструктировать нового участника, прежде чем добавлять его в конференцию.

В Microsoft Office Communicator 2007 R2 использоваться другой подход к добавлению участников в конференцию. Номер участника набирался в фоновом режиме, благо, что в клиенте имелся индикатор состояния подключения, и мы всегда могли видеть, когда человек реально поднял трубку.

  1. Нет возможности проинструктировать нового участника, прежде чем добавлять его в конференцию а ваш диалог с секретарем: «позовите Ивана Васильевича из ИТ отдела» будут слышать все участники конференции, в то время как они могли бы обсудить другие моменты;
  2. Не работает с донабором (DTMF), то есть, не получится пройти через голосовое меню.
  3. Приглашающий нового участника не отключается от беседы.

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

clip_image001clip_image002

Это интересно. Видео-вызовы между Lync и Windows Live Messenger.

31.01.2011

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

Начну с возможности организации видео-вызовов между Lync 2010 и Windows Live Messenger.

Для этого нам потребуется:

  1. Клиент Lync 2010, зарегистрированный на пуле Lync Server 2010;
  2. OCS 2007 R2 Edge либо Lync Server 2010 Edge Server (да, работает даже если вы не до конца успели обновить свою инфраструктуру);
  3. Настроенный и активированный в Microsoft (в общем, рабочий) функционал Public IM Connectivity с сетью Microsoft Live;
  4. Windows live Messenger 2011 на стороне оппонента;
  5. Дополнительные настройки на стороне Lync Server 2010, о которых ниже.

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

Set-CsExternalAccessPolicy Global —EnablePublicCloudAudioVideoAccess $true

Но у меня заработало и без этой команды. Возможно, как раз по тому что на момент теста использовался OCS 2007 R2 Edge а не Lync Server 2010 Edge Server.

Второй момент, который следует настроить – это шифрование. Live Messenger не поддерживает шифрование медиа-трафика (протокол SRTP), так что нужно поменять настройки по умолчанию для медиа трафика с «требуется шифрование» на «поддерживается шифрование».

Set-CsMediaConfiguration Global —EncryptionLevel SupportEncryption

Те же настройки отвечают за максимально возможное разрешение видео для вызовов один на один. В том числе и с Live Messenger. Значение по умолчанию – VGA можно заменить на 720p. Совмещенная команда будет выглядеть так:

Set-CsMediaConfiguration Global -EncryptionLevel SupportEncryption -MaxVideoRateAllowed Hd720p15M

Ждем минут 5 и пробуем звонить.

Вуаля.

clip_image002

Кстати, в скором времени можно будет делать видео-вызовы между Lync 2010 и X-BOX 360 c подключенным Kinect.