Запросы

В базовой рекомендации IETF RFC 3261 определены запросы 6 типов: REGISTER, INVITE, ACK, СANCEL, BYE и OPTIONS.

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

Запрос ACK подтверждает прием окончательного ответа на запрос INVITE. Если описание сессии отсутствовало в запросе INVITE, оно может быть передано в запросе ACK.

Сообщением BYE клиент агента пользователя разрушает соединение. Сторона, получившая запрос BYE, должна прекратить передачу медиа-информации и передать ответ с кодом 200 (OK).

C помощью запроса REGISTER UA выполняет процедуры, связанные с регистрацией пользователя. В нем указывается имя домена, на котором хочет зарегистрироваться пользователь, списочный адрес регистрирующегося пользователя, время регистрации (в секундах).

Для отмены регистрации используется также запрос REGISTER. В этом случае значение параметра Expires (длительность действия регистрации) или одноименного заголовка устанавливается равным нулю.

Запрос CANCEL отменяет обработку ранее переданного запроса с такими же, как в запросе CANCEL значениями полей Call-ID, To, From и CSeq.

Запросом OPTIONS клиент UA запрашивает информацию о возможностях терминального оборудования вызываемого пользователя. В ответ на запрос оборудование вызываемого пользователя передает требуемую информацию.

После испытания протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести запросов недостаточно. Поэтому организацией IETF были введены дополнительные запросы: INFO, PRACK, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, PUBLISH.

Запрос INFO предназначен для обмена дополнительной сигнальной информацией при установлении и поддержании соединения (как правило, используется при взаимодействии с ОКС7). Запрос INFO не изменяет состояния SIP-сессии, однако он обеспечивает передачу дополнительной информации прикладного уровня, которая в дальнейшем может способствовать более производительному функционированию приложений, использующих протокол SIP.

Запрос PRACK. В некоторых случаях, включая взаимодействие с телефонной сетью, построенной с использованием технологии коммутации каналов, необходим механизм обеспечения надёжности передачи предварительных ответов. Запрос PRACK используется для подтверждения приема предварительных ответов и, как и запрос ACK, – для окончательных ответов на запрос INVITE.

Запрос UPDATE. Часто возникают случаи, когда необходимо изменить некоторые параметры устанавливаемой сессии до приема окончательного ответа на INVITE. Запрос UPDATE содержит новое предложение с описанием сеанса связи в формате SDP (Offer), предназначенное для обновления параметров сессии, ранее переданных в Offer сообщения INVITE. Ответ на этот запрос класса 2хх переносит ответ на предложение с указанием принятых параметров также в формате SDP (аnswer). Если окончательный ответ не 2хх, то параметры сессии остаются неизменными.

Запрос SUBSCRIBE используется для запроса определенной информации о текущем состоянии или об изменениях состояния удалённого UA. Если уведомитель поддерживает функцию извещения о событиях определённого в запросе типа, то он создаёт подписку и передает ответ 2хх. После того как подписка была успешно создана, уведомитель должен незамедлительно послать сообщение NOTIFY, чтобы сообщить запросившей стороне текущее состояние ресурса. Когда происходит изменение в состоянии ресурса, на контроль которого была открыта подписка, подписчику также направляется запрос NOTIFY. После того как подписчик примет уведомление, он должен передать ответ с кодом 200 (OK). NOTIFY передается также для уведомления о событиях при реализации некоторых дополнительных услуг (без предварительной передачи SUBSCRIBE). Тип события указывается в параметре Event cообщения SUBSCRIBE или REFER.

Запрос REFER предписывает получателю связаться с третьей стороной, используя контактную информацию, которая содержится в заголовке Refer-To запроса. Такой механизм может быть использован для многих целей, включая перевод вызова (Call Transfer). Если запрос принят, сервер UA должен передать ответ с кодом 202 (Accepted). Вслед за этим UA получателя создаёт подписку.

Подписка, создаваемая запросом REFER, по своей сути является такой же, как подписка, создаваемая запросом SUBSCRIBE, только она создается для контроля события перевода вызова. Создание подписки тоже влечёт за собой отправку запроса NOTIFY. Механизм отправки сообщений NOTIFY используется для извещения клиента UA, передавшего REFER, об этапе перевода вызова (начало установления сессии, ответ третьей стороны).

Запрос MESSAGE предназначен для обмена короткими текстовыми сообщениями между пользователями в рамках установленного диалога или вне диалога. Текстовое сообщение помещается в тело запроса. Получив запрос, UA получателя переходит к его обработке и, в случае успеха, отправляет окончательный ответ с кодом 200 (OK). Это означает, что текстовое сообщение доставлено пользователю, но не указывает на то, что пользователь с ним ознакомился.

Запрос PUBLISH публикует на элементе сети SIP информацию о присутствии пользователя в сети. Используется для предоставления пользователям дополнительных услуг в сети связи следующего поколения.

Ответы

Рисунок 3‑ 15

Для описания ответов используется два параметра: код ответа (Status-Code) и фраза, которая поясняет смысл ответа и предназначена для пользователя (Reason-Phrase).

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

Все ответы делятся на: предварительные, которые означают, что запрос находится в стадии обработки; и окончательные, указывающие на завершение обработки запроса.

Status Code для предварительных ответов начинается с 1.

Ответы с кодами 2хх - 6хх являются окончательными. Класс окончательного ответа (от 2 до 6) определяет результат обработки запроса или работу сервера.