Протокол установления сеансов мультимедийной связи SIP

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

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

Согласно архитектуре «клиент-сервер» все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.
      Например, чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя, параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.
      Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP, как уже упоминалось ранее, идентичны используемым в протоколе HTTP. На рисунке 6 представлена структура сообщений протокола SIP.

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

Рис. 6 Структура сообщений протокола SIP

      Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является запросом, в этой строке указываются тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указываются номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.
      Заголовки сообщений содержат сведения об отправителе, адресате, пути следования и др., в общем, переносят информацию, необходимую для обслуживания данного сообщения. О типе заголовка можно узнать по его имени. Оно не зависит от регистра (т.е. буквы могут быть прописные и строчные), но обычно имя пишут с большой буквы, за которой идут строчные.
      Сообщения протокола SIP могут содержать так называемое тело сообщения. В запросах АСК, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Запрос BYE тела сообщения не содержит, а ситуация с запросом REGISTER подлежит дальнейшему изучению. С ответами дело обстоит иначе: любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Заголовки сообщений

      В протоколе SIP определено четыре вида заголовков (Таблица 1):
      • Общие заголовки, присутствующие в запросах и ответах;
      • Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова «Content»);
      • Заголовки запросов, передающие дополнительную информацию о запросе;
      • Заголовки ответов, передающие дополнительную информацию об ответе.
      Заголовок содержит название, за которым, отделенное двоеточием, следует значение заголовка. В поле значения содержатся передаваемые данные. Следует отметить, что если сервер принимает сообщения, заголовки которых ему не известны, то эти заголовки игнорируются.
      Ниже представлены наиболее часто используемые заголовки.
      Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1 . Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.loniis.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.
      Заголовок То - определяет адресата. Кроме SIP-адреса здесь может стоять параметр «tag» для идентификации конкретного терминала пользователя (например, домашнего, рабочего или сотового телефона) в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов пользователя; чтобы их различать, необходимо иметь метку tag. Ее вставляет в заголовок терминальное оборудование вызванного пользователя при ответе на принятый запрос.
      Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
      Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.

Таблица 1 Виды заголовков сообщений SIP

Общие заголовки

Заголовки содержания

Заголовки запросов

Заголовки ответов

Call-ID (идентификатор сеанса связи)

Content-Encoding (кодирование тела сообщения)

Accept (принимается)

Allow (разрешение)

Contact (контактировать)

Content-Length (размер тела сообщения)

Accent-Encoding (метод кодирования поддерживается)

Proxy-Authenticate (подтверждение подлинности прокси-сервера)

CSeq (последовательность)

Content-Type (тип содержимого)

Accent-Language (язык поддерживается)

Retro-After (повторить через некоторое время)

Date (Дата)

 

Authorization (авторизация)

Server (сервер)

Encryption (шифрование)

 

 

Unsupported (не поддерживается)

Expires (срабатывание таймера)

 

Hide (скрыть)

Warning (предупреждение)

From (источник запроса)

 

Max-Forwards (максимальное количество переадресаций)

WWW-Authenticate (подтверждение подлинности WWW-сервера)

Record-Route (запись маршрута)

 

Organization (организация)

 

Timestamp (метка времени)

 

Priority (приоритет)

 

То (Адресат)

 

Proxy-Authorization (авторизация прокси-сервера)

 

Via (через)

 

Proxy-Require (требуется прокси-сервер)

 

 

 

Route (маршрут)

 

 

 

Require (требуется)

 

 

 

Response-Key (ключ кодирования ответа)

 

 

 

Subject (тема)

 

 

 

User-Agent (агент пользователя)

 

      Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального числа из диапазона от 1 до 232 и типа запроса. Сервер должен проверять значение CSeq в каждом принимаемом запросе и считать запрос новым, если значение CSeq больше предыдущего. Пример заголовка: CSeq: 2 INVITE.
      Заголовок Via служит для того, чтобы избежать ситуации, в которых запрос пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, в случае использования межсетевого экрана - firewall). Дело в том, что запрос может проходить через несколько прокси-сервером, каждый из которых принимает, обрабатывает и переправляет запрос к следующему прокси-серверу, и так до тех пор, пока запрос не достигнет адресата. Таким образом, в заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости (например, чтобы обеспечить секретность) действительный адрес может скрываться.
      Например, запрос на своем пути обрабатывался двумя прок си-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
      Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721 e418c4.1 Via: SIP/2.0/UDP loniis.ru: 5060, где параметр «branch» означает, что на сервере sip.telecom.com запрос был размножен и направлен одновременно по разным направлениям, и наш запрос был передан по направлению, которое идентифицируется следующим образом: 721е418c4.1.
      Содержимое полей Via копируется из запросов в ответы на них, и каждый сервер, через который проходит ответ, удаляет поле Via со своим именем.
      В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.
      Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.
      Заголовок Content-Length указывает размер тела сообщения.


<
Cодержание
>