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

Согласно рассмотренной в предыдущем параграфе архитектуре «клиент-сервер» все сообщения SIP делятся на запросы клиента серверу и ответы сервера клиенту. Так, для инициирования уста­новления соединения вызывающий пользователь должен сообщить серверу ряд обязательных параметров, в том числе, параметры ин­формационных каналов, адрес вызываемого пользователя и другую информацию. Указанные параметры передаются в соответствую­щем SIP-запросе. От вызываемого пользователя приходит ответ на запрос, также содержащий ряд параметров. Все сообщения протокола SIP - запросы и ответы - представляют собой последо­вательности текстовых строк, структура и синтаксис которых, как уже упоминалось ранее, соответствуют протоколу НТТР. На рис. 4.2 представлена структура сообщения протокола SIP.

Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является запросом, то в стартовой строке указываются тип запроса, текущий узел-адре­сат и номер версии протокола. Если сообщение является ответом на запрос, то в стартовой строке указываются номер версии прото­кола, тип ответа и короткая расшифровка ответа, предназначенная

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

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

• общие заголовки, присутствующие в за­просах и ответах, к которым относятся, в частности, Call-ID (идентификатор со­единения), Contact (контакт), CSeq (по­рядковый номер запроса/ответа), Date (дата), Encryption (кодирование), From (источник запроса), То (адресат), Via (че­рез), Record-Route (запись маршрута);

• заголовки содержания переносят ин­формацию о размере тела сообщения или об источнике запро­са, начинаются со слова 'Content', например, Content-Encoding (кодирование тела сообщения), Content-Length (размер тела сообщения), Content-Type, (тип содержимого);

• заголовки, передающие дополнительную информацию о запро­се, например, Accept (принимается), Accept-Encoding (кодиро­вание принимается), Accept-Language (язык поддерживается), Authorization (авторизация), Hide (скрыть), Max-Forwards (мак­симальное количество переадресаций), Organization (организа­ция), Priority (приоритет), Proxy-Authorization (авторизация прок­си-сервера), Proxy-Require (требование прокси-сервера), Route (маршрут), Response-Key (ключ кодирования ответа), Subject (тема), User-Agent (агент пользователя);

• заголовки ответов, передающие дополнительную информацию об ответе, например Allow (разрешение), Proxy-Authenticate (подтверждение подлиности прокси-сервера), Retry-After (пов­торить через некоторое время), Server (сервер), Unsupported (не поддерживается), Warning (предупреждение), WWW-Authenticate (аутентификация WWW-сервера).

Заголовок состоит из названия, за которым следует отделенное двоеточием значение заголовка. В поле значения содержатся пере­даваемые данные. Если сервер принимает сообщения, заголовки которых ему не известны, то они игнорируются при обработке. По­ясним некоторые из упомянутых выше, наиболее часто используе­мых заголовков.

Заголовок Call-ID - уникальный идентификатор сеанса связи; он подобен метке соединения Call reference в сигнализации DSS1 [5].

Значение идентификатору присваивается стороной, инициирую­щей вызов. Заголовок Call-ID состоит из буквенно-числового зна­чения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@niits.ru.

Заголовок То - определяет адресата. Кроме SIP-адреса, здесь может стоять параметр tag для идентификации определенного терминала пользователя, например, домашнего, рабочего или мо­бильного телефона, в том случае, когда все они зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов одного пользователя; чтобы их различить и нуж­на метка tag. Если необходим визуальный вывод имени пользовате­ля, например, на дисплей, то имя пользователя также размещается в поле То.

Заголовок From - идентифицирует отправителя запроса; по структуре он аналогичен полю То.

Заголовок CSeq — уникальный идентификатор запроса, относя­щегося к одному соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального числа в диапазоне от 1 до 2³² и типа запроса. Сервер должен про­верять значение величины CSeq в каждом принимаемом запросе, и считает его новым, если значение больше предыдущего. Пример заголовка CSeq: 2 INVITE.

Заголовок Via необходим, чтобы избежать зацикливания запро­са, а также в тех случаях, когда требуется, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, при использовании межсетевого экрана firewall). Дело в том, что запрос может проходить через несколько прокси-серверов, каждый из ко­торых принимает, обрабатывает и переправляет запрос к следую­щему прокси-серверу, пока этот запрос не достигнет адресата.

В заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При не­обходимости (в частности, чтобы обеспечить секретность) действи­тельный адрес может скрываться. Например, пусть запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером niits.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля: Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721e418c4.1 и Via: SIP/2.0/UDP niits.ru:5060, где параметр branch означает, что на сервере sip.telecom.com запрос был размножен и направлен од­новременно по разным направлениям, и наш запрос был передан по направлению, которое идентифицируется 721e418c4.1. Содержи­мое полей Via копируется из запросов в ответы на них, и каждый сер­вер, через который проходит ответ, удаляет поле со своим именем.

В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы следующие запросы прошли через него.

Сообщения протокола SIP могут содержать так называемое тело сообщения. Некоторые запросы, например, запрос BYE, не содержат тела сообщения. С ответами дело обстоит иначе: тело сообщения могут содержать любые ответы, но содержимое их тела довольно сильно различается.

Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.

Заголовок Content-Length показывает размер тела сообщения.