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

    Вместо предисловия

    Во время Teched Russia 2011 самым задаваемым мне вопросом оказался вопрос про отсутствие длинного гудка при вызове абонента Lync из ТфОП. При этом, все спрашивающие являлись читателями ITBand.RU. Так что, первым делом по возвращении домой с MVP Open Days, я решил перенести уже готовую статью по данной теме из собственного блога (являющегося для меня чем-то вроде инкубатора) сюда. Надеюсь будет полезно.

    Урок номер 3

    Продолжаем разговор про использование 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 и SIP. Обзор SDP и разбор SIP сообщения

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

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

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

      • Старости и новости Remote Call Control

        Remote Call Control (RCC) – технология, позволяющая управлять телефоном, подключенным к какой-либо телефонной станции из программного клиента (Office Communicator / Lync) без необходимости расширения клиента. RCC позволяет из программного клиента принять телефонный вызов, выполнить вызов, переключить входящий или текущий вызов на другого пользователя. При этом соответствующие действия будут выполнены на аппаратном телефоне, подключенном к другой телефонной станции. Статус пользователя во время телефонного разговора изменяется на «говорю по телефону».

        Сама технология была придумана задолго до того как Microsoft примеил её в LCS 2005 SP 1 и называется Computer Supported Telecommunications Applications (CSTA).  Для работы CSTA от MS требуется промежуточный сервер, переводящий запросы стандарта TR/87 в запросы понятные АТС. Общая схема решения приведена на рисунке ниже.

        Программный клиент через сервер MS и TR/87 Proxy регистрируется в качестве источника управления вызовами телефонного аппарата, подключенного к АТС. На клиент приходит информация о событиях на телефоне. Команды клиента передаются на телефон.

        Старости :-)

        Глава 1. LCS

        Впервые RCC появился в Microsoft Office Live Communications Server 2005 SP1. В то время это был очень хитрый маркетинговый ход. В Microsoft понимали перспективы рынка IP телефонии и свою неготовность к выходу на этот рынок.

        В то же время, удобный интерфейс всегда был одним из главных достоинств Microsoft. На этом и решили сыграть.

        Набрать одиннадцатизначный номер мобильного телефона парой кликов мыши или видеть, готов ли ваш коллега принять телефонный вызов – неплохое расширение функционала телефонной станции.  Под этим соусом решение и подавалось. И производители АТС «купились», на перебой предлагая свои решения по интеграции с Microsoft LCS / OCS. Ведь, RCC стал конкурентным преимуществом. Нет у тебя, но есть у конкурента – купят конкурента. Так производители АТС сами начали раскручивать своего будущего конкурента.

        Глава 2. OCS 2007

        Выход на рынок Microsoft Office Communications Server 2007 происходил довольно весело. В это время в Microsoft начали активно продвигать понятие Unified Communications (UC). Все коммуникации в одном. Синергия в чистом виде. За полгода до выхода OCS маркетинг Microsoft был уверен, что их разработчики выведут на рынок настоящую бомбу, которая будет на голову выше любой АТС. Однако ближе к выходу об этом начали забывать, всё больше вспоминая прежнюю концепцию расширения функционала АТС. Только изредка звучало скромное: «а для тех, кому нужно больше функционала, возможен полный переход на OCS». От телефонных аппаратов предлагали полностью отказаться и переходить на USB гарнитуры. Из RCC вырезали возможность переадресации вызовов по расписанию.  Остальной функционал остался, но отставание от возможностей телефонии на OCS появилось не из-за этого. Удаленный доступ и конференции. Возможность делать телефонные вызовы из сети Интернет без использования VPN и мышкой собирать телефонную конференцию были отличным поводом перейти на использование OCS как телефонии. К сожалению, доводов против было намного больше, так что RCC использовался повсеместно, как одна из причин внедрения Office Communications Server.

        Для того, чтобы побудить людей попробовать использовать OCS в качестве АТС был придуман еще один маркетинговый ход – Dual forking. При грамотной настройке – входящий вызов поступал как на АТС так и OCS. Предполагалось, что при работе из Интернет вы ответите в программном клиенте и будите говорить через гарнитуру, а на рабочем месте продолжите использовать ваш старый телефон. Самый «козырный» сценарий (Dual Forking + RCC) был доступен только с АТС основного партнера MS в области телефонии на тот момент – Nortel CS 1000.

        Есть мнение, что RCC в OCS 2007 оставили как раз, чтоб обеспечить отображение статуса доступности при разговоре с телефона в режиме Dual Forking + RCC. Но идею Dual Forking производители АТС не поддержали. И почему бы это? :-)

        Глава 3. OCS 2007 R2

        Microsoft Office Communications Server 2007 R2 стал логичным предложением идей, заложенных в OCS 2007. Телефония развивалась и достигла приемлемого уровня, достаточного для внедрения на небольших предприятиях (если закрыть глаза на отсутствие нормальных телефонов), в то время как наличие RCC до самого релиза ставилось под сомнение.

        Тем не менее, RCC сохранился в прежнем объеме. Теперь уже RCC стал оружием производителей АТС в борьбе против MS. Оставьте Microsoft ПО, а телефонию нам. Каждый делает то, в чем лучше разбирается. Говоря так, тем не менее, основные игроки на рынке активно пытались догнать Microsoft на его поле. Идея UC уже распространилась и все понимали, что просто IP-телефония скоро уже будет мало кого интересовать. Как IP-телефония постепенно заменила аналоговую, так UC решения постепенно заменят собой обычные средства коммуникаций, включая IP-телефонию «без наворотов».  Независимые аналитики прогнозировали в недалеком будущем борьбу за рынок UC между гигантами Cisco и Microsoft.

        Глава 4. Lync Server 2010

        Lync Server вышел на рынок всё так же с поддержкой RCC. Это был вынужденный ход. Слишком много заказчиков, которых нужно было пересадить на Lync Server, активно использовали RCC.

        Для Microsoft в Lync Server 2010 RCC стал тем же, чем Public Folders в Exchange Server. И хочется выкинуть, да все используют. Функционал RCC опять урезан. На этот раз, пользователи RCC лишились возможности участия в видео конференциях Lync Server. Судя по всему, это ошибка, которую не стали исправлять, пожалев время. Возможно, функционал вернут в одном из патчей, если будет много «криков» от заказчиков.

        Взамен, в Microsoft предложили протокол обмена статусами доступности между АТС. Такая же мертворожденная идея как Dual Forking + RCC и Advanced Gateway. Обе идеи поддержали по одному производителю, да и то, когда в MS к самим идеям уже охладели. 🙂

        Обещанная конкуренция идет полным ходом (сам принимал участие в паре крупных проектов / битв Cisco vs MS) и RCC используется, как последний аргумент против полной миграции на Lync Server c других платформ.

        Кому я должен – я всем прощаю

        C RCC у Microsoft связана интересная ситуация. Microsoft поддерживает технологию, но не поддерживает реализацию. Что это означает? Если вы настроите один компонент  Lync Server без оглядки на Supportability Guide, а проблемы будут с другим компонентом, техническая поддержка может отказаться решать вашу проблему пока первый компонент не будет настроен. Поддержка технологии означает, что использование RCC разрешено. Однако, если возникнут проблемы именно с работой RCC, и вы обратить непосредственно в Microsoft, вам ответят, что вам следует обратиться к тому, кто заявил, что их решение работает с Microsoft Lync Server 2010 в режиме RCC.

        И что теперь?

        В последнее время, два производителя заявили о поддержке RCC с Lync Server 2010.

        Cisco поддерживает RCC c Lync Server 2010 при использовании  Cisco Unified Communications Manager 8.x и Cisco Unified Presence 8.5.2. На самом деле, все отлично работает и на старых версиях CUCM и CUPS. Но зачем Cisco поддерживать интеграцию последней версии продукта конкурента со старой версией своего продукта? Так можно постепенно быть вытесненным из заказчика. http://www.microsoft.com/download/en/confirmation.aspx?id=11530

        В Avaya добавили поддержку RCC с Lync Server в AE Services R6.1.1. К слову, в данном случае, добавили поддержку, значит, устранили недочет, вызывающий сбой. До AE Services R6.1.1 настроить RCC между Lync Server и Avaya Session Manager было нельзя. http://support.avaya.com/css/P8/documents/100144425

        На этом можно и закончить рассказ об истории небольшой технологии, которая несколько лет двигала прогресс вперед и повышала эффективность бизнеса. Сейчас использование RCC не окупается. Правильный вариант – выбрать одну платформу, а не платить сразу двум производителям. Я совсем забыл упомянуть про лицензирование. В LCS / OCS функционал RCC требовал лицензии Enterprise CAL, а в Lync – Plus CAL. Те же лицензии требуются для функционала телефонии и стоимость, соответственно одинакова. Но в дополнении к  RCC  вам нужно иметь оплачивать еще и поддержку существующей телефонии, и ограничивать себя в функционале.

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

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

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

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

            Одним из нововведений 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 соответственно).

            • Лицензирование Lync Server 2010

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

              Схема лицензирования

              Lync Server 2010 лицензируется по схеме “Сервер + Лицензии на подключение”. На деле, обычно дополнительно нужно приобретать клиентское ПО, но об этом позже.

              • Компоненты Lync Server 2010

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

                • Настройка взаимодействия Exchange 2010 SP1 и Communications Server. Часть 1. Exchange UM

                  Голосовая почта Exchange 2010 Unified Messaging (Exchange UM) на русском языке уже доступна для скачивания, а значит, настало время поговорить об основных нюансах конфигурации Exchange UM. В этой статье я постараюсь подробно описать процесс настройки взаимодействия Exchange UM и Communications Server (CS). Хотя взаимодействие стало возможно ещё в Exchange 2007 SP1, на форумах TechNet всё равно периодически возникают различные вопросы касательно интеграции CS и Exchange UM.

                  • Телефоны Microsoft Communications Server “14”

                    Одной из основных проблем продвижения OCS как телефонии являлось отсутствие нормальных телефонов. В Microsoft утверждали что смогут перенести всех с аппаратных телефонов на программный клиент. Полагаю, никто не будет спорить, что осуществлять вызовы с програмного клиента намного проще. Однако, даже к программному клиенту нужна гарнитура. И если людям постоянно “сидящим на телефоне” удобнее использовать наушники с микрофоном, то большинству сотрудников компаний при входящем звонке легче просто снять трубку со стоящего рядом телефона.

                    В Microsoft наконец-то тоже это поняли и ниже вы найдете описание существующих в настоящий момент и готовящихся к выходу в этом году аппаратных телефонов для Communications Server “14”.