Сообщения протокола SIP. Часть 1.

В интернете существует достаточно большое количество приложений, которые заточены на создание и взаимодействие с так называемыми сессиями, где сессия — это обмен данными между связанными ею участниками (диалог).

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

Протокол SIP представляет собой клиент-серверное взаимодействие и определяет собой 5 ключевых точек, в отношении установления и терминации мультимедиа-диалогов:

• Местоположение: определение оконечного оборудования, его сетевой адрес.
• Доступность: определение состояния оконечного оборудования, его готовности вступить в диалог.
• Возможности: определение возможностей оконечного оборудования, определение медиа-форматов для взаимодействия.
• Установление сессии: «дозвон», установление параметров сессии, связывание оконечных устройств между собой.
• Управление сессией: включает в себя изменение параметров установленных сессий, подключение дополнительных служб, терминации, перенаправление и пр.

Взаимодействие устройств внутри протокола условно называется сигнализацией, описывается в rfc3261 и строится на взаимном обмене сообщениями (между клиентом и сервером). Сообщения, таким образом, можно разделить на сообщения запросов и сообщения ответов. Данную тему и предлагаю раскрыть подробнее.

• Протокол SIP: инфраструктура, механизм обмена сообщениями, дополнительные возможности,
• Доступно о протоколе SIP.

Структура сообщения

Поскольку SIP представляет собой протокол основанный на тексте, подобно протоколу http, внутри себя он переносит запросы от клиента к серверу или ответы от сервера клиенту. Данные сообщения называют сообщениями-SIP.

Оба типа sip-сообщений (и запросы и ответы) используют базовый формат, описанный в RFC2822, за исключением поправок в отношении синтаксиса и используемых кодировок. Оба типа sip-сообщений содержат: стартовую строку, один или более полей заголовка, пустую линию (символизирующую конец полей заголовка) и тело сообщения(message-body), которое в сущности носит опциональный характер.

Стартовая строка, в зависимости от типа сообщения, называется Request-Line или Status-Line.

В сообщениях запроса Request-Line содержит в себе имя метода, адрес получателя(оконечного устройства) и версию протокола, разделенные между собой символом пробела (single space (SP) character)

Сообщения ответа синтаксически выделены от сообщений запроса наличием уже Status-Line в содержании своей стартовой строки. Status-Line содержит в себе версию протокола, числовой код(Status-Code) ответа и ассоциированный с данным кодом текстовый месседж(Reason-Phrase). Каждый элемент, подобно прежнему типа сообщения, отделен от другого символом пробела.

Status-Code представляет собой трехсимвольное цифровое значение, символизирующее собой результат попытки сервера понять и обработать переданный ему запрос. Reason-Phrase служит для более удобного восприятия данных кодов, и несет в себе их короткое текстовое описание. Можно сказать, что Status-Code предназначен для программной расшифровки протокола, а Reason-Phrase для человеческой(инженерной). Более подробно этой темы мы коснемся во второй части статьи.

На рисунках 2,3 схематично изобразил, как выглядит структура SIP-сообщения.

В целом, своим синтаксисом и семантикой, поля заголовков протокола SIP подобны полям заголовка протокола HTTP. Задача полей заголовка — перенести всю необходимую информацию для обработки данного сообщения. Грубо говоря, можно сказать, что sip-сообщение в сущности и есть — набор информации.

Базово-необходимый набор полей заголовков для успешной обработки SIP-сообщения представляют собой поля: Via, Max-Forwards, From, To, Call-ID и CSeq. (Для сообщений INVITE, к данному перечную необходимо добавить также поле заголовка Contact)

Каждое поле заголовка sip-сообщения состоит из его имени и значения, разделенные между собой символов двоеточия:

```Имя поля: значение поля```

Значения заголовков воспринимаются сервером в регистронезависимом виде, кроме случаев когда значение было передано в кавычках, поэтому, в нижеследующем примере, со стороны сервера, это будет воспринято как два различных по своей сути сообщения:

```
Warning: 370 pc2.example.org "Insuf. bandwidth"
Warning: 370 pc2.example.org "INSUF. BANDWIDTH"
``` --- два различных сообщения

В основной своей массе, поля заголовков придерживаются формата представления, заключающегося в цепочках <имя-значение>, разделенных между собой точкой с запятой, однако в целом формат значения заголовка зависит от его имени.

```
Имя поля: значение поля; имя параметра=значение параметра; имя параметра=значение параметра …

```

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

«`

Subject: Я знаю, что ты здесь, подними трубку!

Subject: Я знаю,

что ты здесь,

подними

трубку!

«` — два равнозначных друг другу сообщения

Порядок следования заголовков роли не играет, ровно до тех пор, покуда не передаются заголовки с одинаковыми именами полей!

Так или иначе, рекомендуется использовать в шапке заголовки, которые имеют прямое отношения к службам перенаправления запроса(прокси-серверам) и подобным ей. Такими заголовками могут быть: Via, Route, Record-Route, Proxy-Require, Proxy-Authorization, Max-Forwards, и другие.

В целом, порядок следования заголовков значения не имеет, кроме случаев, когда должны передаваться заголовки с одинаковыми именами полей! За редким исключением, такие заголовки можно объединить в одну пару <<имя поля: значение поля>>,  отделив с помощью запятой их значения друг от друга.

Например,

```
Route: <sip:[email protected]>

Subject: Уведомление

Route: <sip:[email protected]>

Route: <sip:[email protected]>

```
Можно свести к виду: 

```

Subject: Уведомление

Route: <sip:[email protected]>, <sip:[email protected]>, <sip:[email protected]>

```

И синтаксис данного сообщения будет правильным.

Поскольку, в приведенном примере порядок следования ряда заголовков с одинаковыми именами сохранен, данные сообщения равнозначны. Однако, еще раз: порядок следования ряда заголовков с одинаковыми именами полей должен передаваться в изначально-верной последовательности. Если мы вернёмся к нашему примеру и передадим, например, заголовки в иной последовательности:

 ```
Route: <sip:[email protected]>, <sip:[email protected]>, <sip:[email protected]>

```

То сообщения перестанут быть равнозначными друг другу. Получим 2 разных сообщения.

В расширение к заголовкам, могут передаваться так называемые тела сообщения. К примеру, в сообщении запроса INVITE в теле сообщения передается описание формата медиа-сессии, а в сообщении запроса BYE тело сообщения уже ни к чему – оно избыточно.

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