Запросы

В настоящей версии протокола SIP определено шесть типов запросов. Каждый из них предназначен для выполнения довольно широкого круга задач, что является явным достоинством протокола SIP, так как благодаря этому число сообщений, которыми обмениваются терминалы и серверы, сведено к минимуму. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. В той же строке в поле Request-URI указан SIP-адрес оборудования, которому этот запрос адресован. Содержание полей То и Request-URI может различаться, например, в поле То может быть указан публикуемый адрес абонента, а в поле Request-URI - текущий адрес пользователя.

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

В этом сообщении могут содержаться также данные, необходимые для аутентификации абонента, и, следовательно, доступа клиентов к SIP-серверу. При необходимости изменить характеристики уже организованных каналов передается запрос INVITE с новым описанием сеанса связи. Для приглашения нового участника к уже установленному соединению также используется сообщение INVITE.

Запрос АСК подтверждает прием ответа на запрос INVITE. Следует отметить, что запрос АСК используется только совместно с запросом INVITE, т.е. этим сообщением оборудование вызывающего пользователя показывает, что оно получило окончательный ответ на свой запрос INVITE. В сообщении АСК может содержаться окончательное описание сеанса связи, передаваемое вызывающим пользователем.

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

запросов, разосланных во всех остальных направлениях, сервер отменяет при помощи сообщения CANCEL.

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

При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:

• Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;

• Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;

• Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ «*»;

• В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется. Регистрацию можно также отменить, передав сообщение REGISTER с полем Expires, которому присвоено значение О, и с соответствующим полем Contact.

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

После испытаний протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести типов запросов недостаточно. Поэтому возможно, что в протокол будут введены новые сообщения. Так, в текущей версии протокола SIP не предусмотрен способ передачи информации управления соединением или другой информации во время сеанса связи. Для решения этой задачи был предложен новый тип запроса - INFO. Он может использоваться в следующих случаях:

• для переноса сигнальных сообщений ТфОП/ISDN/coTOBbix сетей между шлюзами в течение разговорной сессии;

 

 

• для переноса сигналов DTMF в течение разговорной сессии;

• для переноса биллинговой информации.

Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рис. 7.6).

INVITE sip: watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip: a.g.bell@bell-tel.com> To: T. Watson <sip: watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com Cseq: 1 INVITE

Content-Type: application/sdp Content-Length: ...

v=0

o=bell 53655765 2353687637 IN IР4 12&.3.4.5

C=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0345

Рис. 7.6 Пример запроса INVITE

В этом примере пользователь Bell (a.g.bell@bell-tel.com) вызывает пользователя Watson (watson@bell-tel.com). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.

При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, Ниже приведен список таких заголовков (Таблица 7.3).

Таблица 7.3 Сжатые имена заголовков

 

Сжатая форма имени	Полная форма имени
с	Content-Type
е	Content- Encoding
f	From
i	Call-ID
m	Contact (от "moved")
	Content-Length
s	Subject
t	To
v	Via

 

При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим образом (рис. 7.7):

INVITE sip: watson@boston.bell-tel.com SIP/2.0 v: SIP/2.0/UDP kton.bell-tel.com f: A. Bell <sip: a.g.bell@bell-tel.com> t: T. Watson <sip: watson@bell-tel.com> i: 3298420296@kton.bell-tel.com Cseq: 1 INVITE с: application/sdp 1: ...

v=0

o=bell 53655765 2353687637 IN IP4 128.3.4.5

C=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0345

Рис. 7.7 Пример запроса INVITE с сокращенными заголовками

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

Таблица 7.4 Запросы SIP

 

Тип запроса	Описание запроса
INVITE	Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса
АСК	Подтверждает прием окончательного ответа на запрос INVITE
BYE	Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе
CANCEL	Отменяет обработку запросов с теми же заголовками Call-ID, То, From и CSeq, что и в самом запросе CANCEL
REGISTER	Переносит адресную информацию для регистрации пользователя на сервере определения местоположения
OPTION	Запрашивает информацию о функциональных возможностях терминала