Главная Exchange/UC, Без рубрики, Новое Lync и SIP. Обзор SDP и разбор SIP сообщения
  • Lync и SIP. Обзор SDP и разбор SIP сообщения

    Данная статья является второй частью рассказа, про использование 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:в сегодняшней статье. Считайте это домашним заданием, а правильный ответ будет во время следующего урока по теме :-)

Комментарии

  1. >ох и намучился же я, занимаясь этой выжимкой
    А в чем проблема с выжимкой была, если не секрет?

  2. Только с мозгами и временем.
    Поиск раздела с параметром в документе. изучение раздела. Изучение, как используется параметр на реальных имеющихся примерах. Выделение, действительно нужного. Обычно, изучение нового материала и написание статьи, для меня, это разные этапы. А в этот раз попутно узнал много интересных меочей 🙂 Надеюсь, статья понравится и пригодится.

  3. На самом деле именно по этому написание статей очень полезно – когда работаешь над чем-то главное результат, и иногда просто нет временижелания копаться в мелочах. А статьи (хорошие 😉 ) заставляют именно копать всё до мелочей.

  4. У инженеров для этих целей есть разработка комплекта проектной документаци 😉

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

    А у меня есть проблемка. При звонке с АТС=>Asterisk 1.6=>Lync я в телефонной трубке Lync-а слышу гудки и поднятие трубки, через каждые 5-8 секунд.
    Вот на форуме обсуждаем, пока правда без результатов
    http://social.technet.microsoft.com/Forums/ru-RU/lync2010ru/thread/e9d9ba5a-d206-4ebb-901a-fd568f33ee25
    вопрос, моя проблема не связана ли как раз с ring back tone?

  6. Если коротко – проблема с отсутствием КПВ связана с тем, как АТС и Lync понимают сообщение 183: session in progress. Lync считает, что если пришел пакет 183, но нет RTP от удаленного источника, шлюз должен генерировать КПВ сам. Это описано в одном из RFC, но как should, так что многие забивают. Подробности придётся подождать.
    С вашей проблемой это не связано. До сих пор гудками в линии не сталкивался.
    По проблеме, могу предложить вытащить RTP Трафик между Lync и шлюзом через wireshark. Прослушав его, вы сможете понять, кто генерирует гудки.