Session Initiation Protocol


Session Initiation Protocol

SIP (англ. Session Initiation Protocol — протокол установления сессии) — стандарт на способ установления и завершения пользовательского интернет-сеанса, включающего обмен мультимедийным содержимым (видео- и аудиоконференция, мгновенные сообщения, онлайн игры).

В модели взаимодействия открытых систем SIP является сетевым протоколом прикладного уровня.

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

Содержание

Принципы протокола

Разработкой занималась организация MMUSIC Working Group. Протокол начал разрабатываться в 1996 году Хенингом Шулзри (Henning Schulzrinne, Колумбийский университет) и Марком Хэндли (Университетский колледж Лондона). В ноябре 2000 года SIP был утверждён как сигнальный протокол проекта 3GPP и основной протокол архитектуры 3GPP TS.24.229)[1]. Наряду с довольно сильно в настоящее время устаревшим Voice over IP.

В основу протокола рабочая группа MMUSIC заложила следующие принципы:

Дизайн протокола

Клиенты SIP традиционно используют порт 5060 UDP для соединения серверов и других элементов SIP. В основном SIP используется для установления и разъединения голосовых и видеозвонков. При этом он может использоваться и в любых других приложениях, где требуется установка соединения, таких как Event Subscription and Notification, Terminal mobility и так далее. Существует большое количество Real-time Transport Protocol (RTP).

Главной задачей разработки SIP было создание сигнального протокола и протокола установления соединений для ТфОП. Сам протокол SIP не определяет этих функций, а сосредоточен только на процедурах установления звонка и сигнализации. При этом он был спроектирован обеспечивать создание таких функций элементов сети, как Прокси-сервер (Proxy Servers) и Пользовательские Агенты (User Agents). При помощи этих элементов можно поддерживать базовые телефонные операции: набор номера, звонок телефонного аппарата, возможность после набора услышать длинные или короткие гудки.

Телефонные сети на основе SIP могут поддерживать и более современные услуги, обычно предоставляемые Signalling System 7 (SS7), несмотря на значительное различие этих двух протоколов. SS7 характеризуется сложной, централизованной интеллектуальной сетью и простыми, неинтеллектуальными, терминалами (традиционные телефонные аппараты). SIP — наоборот, требует очень простую (и, соответственно, хорошо масштабируемую) сеть с интеллектом, встроенным в оконечные элементы на периферии (терминалы, построенные как физические устройства или программы).

SIP используется вместе с несколькими другими протоколами и участвует только в сигнальной части сессии связи. SIP выполняет роль носителя для SDP, который описывает параметры media-данных в рамках сессии, например используемые порты IP и кодеки. В типичном применении сессии SIP — это просто потоки пакетов

Первая предложенная версия стандарта (SIP 2.0) была определена в RFC 2543. Протокол был дополнительно уточнён в RFC 3261, хотя многие реализации по-прежнему основаны на промежуточных версиях стандарта. Обратите внимание, что номер версии остался 2.0.

Адресация

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

Адрес состоит из двух частей. Первая часть — имя пользователя (может указываться в виде телефонного номера), зарегистрированного в домене или на рабочей станции. Вторая часть идентифицирует какой-либо шлюз по его доменному имени или IP-адресу.

В начале SIP-адреса ставится слово «sip:», указывающее, что это именно SIP-адрес, так как бывают и другие (например, «mailto:»).

Архитектура сети

Протокол SIP имеет клиент-серверную архитектуру.

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

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

Терминал

Когда клиент и сервер реализованы в оконечном оборудовании и взаимодействуют непосредственно с пользователем, они называются клиентом агента пользователя — User Agent Client (UAC) — и сервером агента пользователя — User Agent Server (UAS). Если в устройстве присутствуют и UAC, и UAS, то оно называется агентом пользователя — User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.

Сервер UAS и клиент UAC имеют возможность непосредственно взаимодействовать с пользователем. Другие клиенты и серверы SIP этого делать не могут.

Прокси-сервер

Прокси-сервер (от англ. proxy — "представитель") представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и выполняет соответствующие действия. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать запросы и возвращать ответы.

Предусмотрено два типа прокси-серверов

  • с сохранением состояний (stateful). Такой сервер хранит в своей памяти все полученные запросы и связанные с ним новые сформированные запросы до окончания транзакции.
  • без сохранения состояний(stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Сервер переадресации

Сервер переадресации используется для определения текущего местоположения пользователя. Сервер переадресации не терминирует вызовы и не инициирует собственные запросы, а только сообщает адрес необходимого терминала или прокси-сервера. Для этих целей он взаимодействует с сервером определения местоположения.

Однако, для осуществления соединения пользователь может не использовать сервер переадресации, если он сам знает текущий адрес требуемого пользователя.

Сервер определения местоположения пользователей

Пользователь может перемещаться в пределах сети SIP, поэтому существует механизм определения его местоположения в текущий момент времени. Сервер определения местоположения пользователей служит для хранения текущего адреса пользователя и представляет собой базу данных адресной информации.

Пользователь, которому нужна адресная информация не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов WHOIS, или других протоколов.

Сообщения протокола SIP

Сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP идентичны используемым в протоколе

Стартовая строка
Заголовки
Пустая строка
Тело сообщения
  • Стартовая строка — начальная строка любого SIP-сообщения. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.
  • Заголовки сообщений содержат информацию, необходимую для обработки сообщения (информация об отправителе, адресате, пути следования и пр.)
  • Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Пример запроса INVITE:

INVITE sip:nikolia@zenit.chempion.spb.ru SIP/2.0
Record-Route: <sip:nikolia@10.0.0.10;lr>
Via: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0
Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060
From: "78128210000" <sip:78128210000@vladimir.spb.ru>;tag=as149b2d97
To: <sip:nikolia@zenit.chempion.spb.ru>
Contact: <sip:78128210000@vladimir.spb.ru>
Call-ID: 3cbf958e6f43d91905c3fa964a373dcb_zenit.chempion.spb.ru
CSeq: 103 INVITE
Max-Forwards: 16
Date: Wed, 10 Jan 2001 13:16:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 394

v=0
o=root 3303 3304 IN IP4 10.0.0.10
s=session
c=IN IP4 10.0.0.10
t=0 0
m=audio 40358 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=sendrecv

Запросы

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

  1. INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.
  2. АСК — Подтверждает прием ответа на запрос INVITE.
  3. BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
  4. CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
  5. REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
  6. OPTION — Запрашивает информацию о функциональных возможностях терминала.

    Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:
  7. PRACK - временное подтверждение (RFC 3262)
  8. SUBSCRIBE - подписка на получение уведомлений о событии (RFC 3265)
  9. NOTIFY - уведомление подписчика о событии (RFC 3265)
  10. PUBLISH - публикация события на сервере (RFC 3903)
  11. INFO - передача информации, которая не изменяет состояние сессии (RFC 2976)
  12. REFER - запрос получателя о передаче запроса SIP (RFC 3515)
  13. MESSAGE - передача мгновенных сообщений средствами SIP (RFC 3428)
  14. UPDATE - модификация состояния сессии без изменения состояния диалога (RFC 3311)

Ответы на запросы

Ответы на запросы сообщают о результате обработки запроса, либо передают запрошенную информацию. Структуру ответов и их виды протокол SIP унаследовал от протокола

  1. 1ХХ — Информативные ответы показывают, что запрос находится в стадии обработки. Наиболее распространенные ответы данного типа 100 Trying, 180 Ringing, 183 Session Progress.
  2. 2ХХ — Финальные ответы означающие, что запрос был успешно обработан. В настоящее время в данном типе определён только один ответ — 200 OK.
  3. 3ХХ — Финальные ответы информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например ответ 302 Moved Temporary.
  4. 4ХХ — Финальные ответы информирующие об ошибке при обработке или выполнении запроса, например 403 Forbidden или классический для протокола 404 Not Found.
  5. 5ХХ — Финальные ответы информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.
  6. 6ХХ — Финальные ответы информирующие о том, что соединение с вызываемым пользователем установить невозможно, например ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

Алгоритмы установления соединения

Протокол SIP определяет 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Сценарии отличаются по тому, как осуществляется поиск и приглашение вызываемого пользователя. Основные алгоритмы установления соединения описаны в RFC 3665.

Пример сценария установления соединения:

   Alice        Redirect Server     Proxy 3             Bob
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|                |                |
     |     302 F2     |                |                |
     |<---------------|                |                |
     |     ACK F3     |                |                |
     |--------------->|                |                |
     |     INVITE F4                   |                |
     |-------------------------------->|    INVITE F5   |
     |             100  F6             |--------------->|
     |<--------------------------------|      180 F7    |
     |             180 F8              |<---------------|
     |<--------------------------------|                |
     |                                 |     200 F9     |
     |             200 F10             |<---------------|
     |<--------------------------------|                |
     |             ACK F11             |                |
     |-------------------------------->|     ACK F12    |
     |                                 |--------------->|
     |                Both Way RTP Media                |
     |<================================================>|
     |                                 |     BYE F13    |
     |             BYE F14             |<---------------|
     |<--------------------------------|                |
     |             200 F15             |                |
     |-------------------------------->|     200 F16    |
     |                                 |--------------->|
     |                                 |                | 

SIP-T

Для взаимодействия с традиционными телефонными сетями, использующими сигнализацию ОКС-7, была разработана модификация протокола SIP для телефонии: Session Initiation Protocol for Telephones (SIP-T). Данный протокол описан в RFC 3372. Основная задача данной модификации протокола SIP заключается в прозрачной передаче сообщений инкапсуляции сигнальных единиц ОКС в сообщения SIP. Все требуемые задачи по взаимодействию между протоколами были решены на базе протокола SIP:

Требование по взаимодействию Функция SIP-T
Прозрачность сигнализации ISUP Инкапсуляция ISUP в тело сообщения SIP
Возможность маршрутизировать сообщения SIP в зависимости от ISUP Трансляция параметров ISUP в заголовке сообщения SIP
Трансляция адресной информации при установленном соединении Использование метода INFO

Сравнение с
Параметр сравнения SIP
Набор услуг, поддерживаемых обоими протоколами примерно одинаков
Персональная мобильность пользователей Имеется хороший набор средств поддержки мобильности Персональная мобильность поддерживается, но менее гибко
Расширяемость протокола Удобная расширяемость, простая совместимость с предыдущими версиями Расширяемость поддерживается, но существует ряд сложностей
Масштабируемость сети
Оба протокола обеспечивают хорошую масштабируемость сети
Время установления соединения Достаточно одной транзакции Требуется несколько транзакций.
Сложность протокола Простой, мало запросов, текстовый формат сообщений Сложный, много запросов и протоколов, двоичное представление сообщений

Примечания

  1. Статья «Предпосылки появления NGN»

Литература

  • Гольдштейн, Б. С. Протокол SIP. Справочник. — СПб.: BHV-Санкт-Петербург, 2005. — С. 456. — ISBN 5-8206-0123-8
  • Гольдштейн, Б. С. IP телефония — М.: Радио и связь, 2001. — 336 C.: ил. — ISBN 5-256-01585-0

См. также


Wikimedia Foundation. 2010.