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

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

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

  1. b Says:

    В общем, пока проблема есть и решается индивидуально. и довольно успешно.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s


%d такие блоггеры, как: