18.1.3. Сообщения sip

Из приведенного примера видно, что сообщения SIP делятся на запросы и ответы.

Запросы SIP

Запросы SIP (SIP request) – это сообщения, которые передаются от клиента серверу, чтобы он осуществил операцию SIP. В примерах были показаны запросы:

• INVITE (приглашение на установление сеанса);

• ACK (подтверждение, что клиент агента пользователя UAC получил окончательный ответ на запрос INVITE;

• REGISTER (регистрация клиентом информации о его текущем месторасположения в соответствии с записями AoR пользователя на сервере SIP;

• BYE (агент UA завершает установленный ранее сеанс).

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

• CANCEL (позволяет пользовательским агентам и сетевым серверам отменить ранее переданный запрос, если ответ на него еще не получен);

• OPTION (позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов).

Сервер посылает клиенту ответ SIP для того, чтобы оповестить его о состоянии запроса SIP, посланного клиентом на сервер раньше.

Ответы SIP

Агенты UAC и прокси-серверы создают ответы SIP на запросы SIP для того, чтобы инициировать агент UAC. Ответы SIP пронумерованы от 100 до 699 и сгруппированы как 1хх, 2хх и так далее до 6хх. По классификации они разделены на предварительные и окончательные. Предварительный ответ означает, что сервер работает, но это неокончательный ответ. Из приведенного примера к таким ответам относятся: 100 trying, 180 ringing. Завершение обработки и финальное состояние запроса SIP означает окончательный ответ. Все ответы остальных классов являются окончательными. Из приведенного примера таким ответом является “200 OK”.

18.1.3.1. Поля заголовка сообщения при регистрации sip

Настоящий раздел посвящен описанию состава сообщений SIP на примере регистрации SIP и принципа мобильности пользователя.

Каждое сообщение SIP состоит из трех полей: начальная строка, заголовок сообщения и тело сообщения.

На рис. 18.3. показан пример содержания сообщений для простой транзакции: запрос REGISTER и положительный ответ на него. Как правило, функции сервера регистрации и прокси-сервера выполняет тот же сервер. Агент пользователя UA посылает запрос REGISTER на сервер регистрации домена, представляя свой текущий адрес в поле заголовка Соntact. Постоянный адрес SIP пользователя AoR содержится в поле To запроса. Сервер регистрации модифицирует базу данных расположения служб, чтобы привязать постоянный адрес пользователя к его текущему адресу.

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

REGISTER sip:iptel.org;transport=udp

From: “Jiri”@iptel.org>

To: : “Jiri”@iptel.org>

Cseq: 119065 REGISTER

Соntact:<sip:jiri@192.168.1.101>;expires=3600

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

200 ОК

From: “Jiri”@iptel.org>

To: “Jiri”@iptel.org>

Cseq: 119065 REGISTER

Соntact:<sip:jiri@192.168.1.101>;expires=3600

Рис. 18.3. Сообщения транзакции: запрос REGISTER и положительный ответ на него

Начальная строка

В поле начальной строки запроса определена цель сообщения. При этом указывается идентификатор тип запроса и адрес назначения в форме URI. На рис. 18.3 это REGISTER и имя домена назначения iptel.org. Обращаясь к серверу регистрации, пользователь указывает адрес, по которому он находится в настоящее время. Адресом URI в начальной строке, sip:iptel.org;transport=udp, служит для маршрутизации с целью выполнения запроса REGISTER. В качестве транспортных протоколов модели TCP/IP могут использоваться протоколы UDP или TCP. В данном случае используется транспортный протокол UDP. Этот дейтаграммный протокол не устанавливает соединение на транспортном уровня. Надежная передача обеспечивается повтором запроса.

При прохождении запроса через несколько серверов SIP может потребоваться изменение маршрутизации или услуги, что в свою очередь может потребовать изменение адреса назначения. Например, к пользователю потребуется направить запрос по IP-адресу. Тогда URI изменяется на sip:juri@10.0.0.1; transport=tcp. В данном случае используется транспортный протокол TCP, устанавливающий соединение. Начальная строка ответа является строкой состояния и указывает на результат в цифровой и текстовой форме. В этом примере 200 ОК.

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

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

• To: идентификатор получателя запроса. Это поле содержит адрес AoR получателя запроса.

• From: идентификатор отправителя запроса. Это поле содержит адрес AoR отправителя запроса.

Часто недостаточно адреса SIP в поле From, особенно в случаях, когда вызовы SIP оканчиваются в ТфОП. При этом оборудование не может идентификатор вызывающего пользователя идентифицировать в нецифровой форме. В таком случае прокси-сервер добавляет к полю From поле заголовка P-Asserted-Identity телефонный номер отправителя, как показано на рис. 18.4.

From: “John doe” joe@ipel.org; tag=9texf/

P-Asserted-identity:<tel:16181234567>

Рис. 18.4. Поле заголовка From в комбинации с заголовком P-Asserted-Identity

С точки зрения информационной безопасности оба заголовка From и P-Asserted-Identity могут быть легко изменены злоумышленником, так как уязвимы угрозе «человек посередине». В качестве защиты может быть использован протокол безопасности на транспортном уровне TLS (глава 13).

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

• Contact: описывает местонахождение клиента. Это особенно важно для запроса пользователя REGISTER. В поле Contact этого запроса содержится текущий (контактный) адрес SIP телефона, который должен быть связан с постоянным (глобальным) адресом AoR. Это поле заголовка имеет параметр expires, который указывает на период времени эта привязка допустима. На рис. 18.3 для параметра expire установлено значение 3600 секунд. Для сохранения этой привязки агент UA периодически посылает сообщения регистрации, чтобы обновлять эту информацию. Такой механизм регистрации контактного адреса на сервере регистрации позволяет протоколу SIP поддерживать мобильность пользователя. Когда агент UA посылает запрос REGISTER серверу регистрации SIP он уведомляет службу расположения о своем текущем адресе. Теперь прокси-сервер может передавать запросы этому мобильному пользователю на основании контактного адреса в базе данных сервера местоположения.

• CSeq: целочисленное значение последовательности запросов и названия запроса (в примере REGISTER). Это поле служит для защиты от потери сообщений или повторной их передачи.

• Via: поле заголовка в каждом прокси-сервере содержит список элементов сети SIP, через которые запрос прошел. Список нужен для тех случаев, когда необходимо, чтобы запросы и ответы проходили по одному и тому же пути.

• Record-Route: поле заголовка Record-Route используется для того, чтобы запомнить путь инициализирующего запроса на пути от UAC до UAS. Все прокси-сервера добавляют эти поля для того, чтобы следующие запросы в процессе диалога маршрутизировались через эти же прокси-серверы.

• Rout: поле заголовка служит для принудительной маршрутизации запроса в соответствии со списком прокси-серверов.

• Loop detection (обнаружение петли). Каждый SIP запрос должен включать счетчик, который указывает сколько «хопов» может еще пройти. Этот счетчик называется Max-Forwards и напоминает “Время жизни“ в заголовке IP-пакета. Первоначальное значение устанавливается клиентом. Это число уменьшается каждым сервером, который пересылает запрос далее.

• User-Agent и Warning. Поле заголовка User-Agent содержит ограниченную информацию о клиенте, инициирующем запрос. Поле заголовка Warning содержит дополнительную информацию, об инициаторе ответа.

• Proprietary extention (частные расширения). Некоторые производители считают полезным расширение некоторых возможностей, но не переносят на них стандартизацию. В качестве примера может быть использовано оборудование, фиксирующее характеристик качество обслуживания QoS по завершению вызова.

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

Тело сообщения приведем на примере запроса INVITE. Эта часть заголовка сообщения служит для выполнения функции обмена определенными данными между двумя участниками сессии. В соответствии с протоколом описания сессии (сеанса) SDP (Session Description Protocol), в простейшем случае в тело заголовка включены IP-адреса и номера портов, по которым агенты пользователя обмениваются данными.

Протокол SDP, определенный в RFC 2327, описывает содержимое сессий, включая телефонию, приложения мультимедиа. SDP содержит также следующую информацию.

Медиа потоки: сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения, сходные с MIME типами электронной почты в Интернете.

Адреса: SDP указывает адреса места назначения для медиа потоков при многоадресной (multicusting) передаче.

Порты: для каждого потока специфицируются номера UDP портов для отправителя и получателя.

Время старта и остановки: Эти данные используются в случае широковещательных сессий, например, телевизионных или радио программ. Указываются время начала, завершения и времена повторов сессии.

Документ RFC 3264 предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно данных, подлежащих пересылке. Примером информации в поле тела сообщения может быть, например, выбор кодека при использовании телефонии.

Как показано ниже (в подразделе 18.1.4) в протоколе SIP для телефонии (SIP-T) предусмотрено инкапсулирование в тело запроса INVITE и ответов сообщений ОКС№7 прикладного уровня ISUP.