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

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

В этой статье я постараюсь описать базовые принципы 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.

 

комментария 2 to “Lync и SIP. Начальные сведения”

  1. DenisO Says:

    нехватает перевода SBA (Survivable Branch Appliance), два раза по тексту используется, но без объяснений. Расшифровку нашел только гуглом

  2. Александр Донин Says:

    Принятно. Привел расшифровку.
    Кстати, если интересно:
    описание ролей Lync Server я приводил тут https://adonin.wordpress.com/2010/11/05/%d0%ba%d0%be%d0%bc%d0%bf%d0%be%d0%bd%d0%b5%d0%bd%d1%82%d1%8b-lync-server-2010/
    Более подробно SBA расписан тут https://adonin.wordpress.com/2010/07/04/microsoft-communications-server-%e2%80%9c14%e2%80%9d-%d0%ba%d0%b0%d0%ba-%d1%82%d0%b5%d0%bb%d0%b5%d1%84%d0%be%d0%bd%d0%bd%d0%b0%d1%8f-%d1%81%d1%82%d0%b0%d0%bd%d1%86%d0%b8%d1%8f-%d0%b2%d1%8b%d1%81/

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s


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