Команды (запросы)

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

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

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

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

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

При помощи команды REGISTER пользователи сообщают свое текущее местоположение. В этом сообщении содержатся поле То с адресом, который надо сохранить или модифицировать на серве­ре, поле From с адресом инициатора регистрации (зарегистриро­вать пользователя может другое лицо, например, секретарь может зарегистрировать своего начальника), поле Contact с новым ад­ресом пользователя, по которому должны передаваться все даль­нейшие запросы INVITE (если в команде поле Contact отсутствует, регистрация остается неизменной, а в случае отмены регистрации здесь размещается символ «*»), и поле Expires, в котором указыва­ется время в секундах, по истечении которого регистрация закан­чивается (если это поле отсутствует, то по умолчанию назначается время - 1 час). Регистрацию можно отменить и передачей сообще­ния REGISTER с полем Expires, которому присвоено значение 0, и с соответствующим полем Contact.

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

После испытания протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести запросов недо­статочно. Так, не был предусмотрен способ передачи информации управления соединением или другой информации во время разго­ворного сеанса.

Для решения этой задачи был предложен новый запрос INFO, который можно использовать для переноса между шлюзами сиг­нальных сообщений в течение сеанса связи, для переноса сигна­лов DTMF созданных в ходе сеанса, для переноса информации об остатке на счете (билинговой информации), для переноса между

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

Объекты сети SIP могут подписаться на предоставление инфор­мации о состоянии определенного ресурса или процесса обслужи­вания вызова в сети при помощи сообщения SUBSCRIBE. Объекты, располагающие этими сведениями (или объекты, действующие от их лица), будут передавать уведомления NOTIFY каждый раз, когда состояние изменится.

Запрос типа MESSAGE предназначен для реализации служб ин­терактивного обмена текстовыми сообщениями с использованием модели, аналогичной отправке SMS. Запрос REFER, передаваемый отправителем, предписывает получателю связаться с третьей сто­роной, используя контактную информацию, которая содержится в этом сообщении. Такой механизм может быть использован для многих целей, например, для переадресации вызова Call Transfer.

Ответы

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

Протокол SIP определяет два типа ответов на запрос, иниции­рующий соединение: предварительные и окончательные. Оконча­тельные ответы несут результат обработки запроса и передаются «надежно», т.е. с подтверждением. Предварительные ответы несут информацию о текущей стадии обработки запроса, но передаются без подтверждения.

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

предварительных ответов. Для этого вводится механизм надёжнос­ти по схеме, схожей с существующими механизмами для оконча­тельных ответов класса 2хх на запрос INVITE. Используется запрос PRACK, который играет ту же роль, что и ACK, но для предварительных ответов. Однако здесь имеется принципиальное различие - PRACK является обычным SIP-сообщением и требует при его получении пе­редачи ответа 200 (ОК).

Возникают случаи, когда необходимо изменить некоторые пара­метры сеанса (например, тип кодека) до прихода окончательного ответа на начальное сообщение INVITE, для чего вводится запрос UPDATE. Он используется следующим образом: вызывающая сто­рона передает сообщение INVITE, в поле заголовка Allow которого, среди запросов прочих типов, помещается UPDATE для того, чтобы указать на способность вызывающей стороны принимать запросы этого типа. Любой ответ (предварительный или окончательный) вызываемой стороны тоже содержит заголовок Allow с указанным в нем значением UPDATE. Далее вызывающая сторона может со­здать запрос UPDATE, который содержит предложение с описанием сеанса связи в формате SDP для обновления параметров сеанса. На этот запрос передается ответ с указанием принятых параметров (также в формате SDP).

Итак, ответы делятся на предварительные (информационные) и окончательные. Информационные ответы показывают, что запрос находится в стадии обработки, и кодируются трехзначным числом, начинающимся с единицы 1хх (provisional). Некоторые ответы, например, 100 Trying, предназначены для обнуления таймеров в оборудовании пользователя. Если до срабатывания таймера от­вет на запрос не получен, считается, что запрос потерян, и может (по усмотрению изготовителя) производиться его повторная пе­редача. Этот информационный ответ аналогичен сообщению CALL PROCEEDING протокола Q.931.

Еще один распространенный ответ 180 Ringing; его назначение идентично назначению сигнала «Контроль посылки вызова» в ТфОП или сообщению ALERTING протокола Q.931. Если прокси-сервер передает ответ 181 Call Forwarding, он может также указать в теле сообщения, к какому пользователю он переправляет вызов. Ответ 182 Queued for Service используется в приложениях, которые позволяют ставить текущий вызов в очередь для ожидания, пока не будут обслужены вызовы, находящиеся перед ним. Основными пользователями этой возможности являются отделы обслуживания клиентов в крупных корпорациях. Ответ 183 Session Progress ана­логичен сообщению CALL PROGRESS протокола Q.931 и использу­ется для того, чтобы заранее получить описание сеанса информа­ционного обмена от шлюзов на пути к вызываемому пользователю таким образом, чтобы мог быть проключен ранний речевой тракт еще до того, как вызывающий пользователь получит сигнал КПВ. Этот ответ используется, например, при взаимодействии протоко­ла SIP с сетью ТфОП, при котором передача ответа Session Progress с SDP-описанием шлюза ТфОП позволяет входящей АТС послать сигнал КПВ.

Среди других вариантов использования этого ответа - воспро­изведение приветственного объявления или музыкальной фразы при входе в домен перед установлением соединения. Ответ 189 на запрос REFER используется для предоставления текущей ин­формации о состоянии соединения, переключаемого на другой номер в фазе разговора. При этом ожидается получить либо ответ об успешной обработке, либо ответ об отказе вызываемой сторо­ны. Окончательные ответы кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Все они означают завершение обработки запроса, а каждый из них в отдельности - результат об­работки запроса.

Ответы 2хх (success) означают, что запрос был успешно об­работан. Базовым ответом данной группы является сообщение 200 ОК. Значение этого ответа зависит от соответствующего за­проса, например: ответ 200 ОК на запрос INVITE означает, что вызы­ваемый пользователь согласен принять участие в сеансе связи, а в теле ответа указываются возможности оборудования вызываемого пользователя; ответ 200 ОК на запрос BYE означает завершение связи, а в теле ответа никакой информации не переносится; ответ 200 ОК на запрос CANCEL означает отмену поиска, и в теле ответа тоже не переносится никакой информации; ответ 200 ОК на за­прос REGISTER означает, что регистрация прошла успешно; ответ 200 ОК на запрос OPTION означает согласие вызываемого пользо­вателя сообщить возможности своего оборудования, сведения о которых и содержатся в теле ответа.

Ответы 3хх (redirection) информируют оборудование вызы­вающего пользователя о новом местоположении вызываемого пользователя или переносят другую информацию, которая может быть использована, чтобы с ним связаться. В ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, а вызывающему пользователю предлагается выбрать один из них. Ответ 301 Moved Permanently означает, что вызываемый пользователь больше не находится по ад­ресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact. Ответ 302 Moved Tempovarily означает, что пользователь временно (промежуток времени может быть ука­зан в поле Expires) находится по другому адресу, указанному в поле Contact, и все запросы нужно посылать туда.

Ответы 4хх (client error) информируют о том, что в запросе обнаружена ошибка. После получения такого ответа пользователь не должен передавать тот же самый запрос без его модификации. Ответ 400 Bad Request означает, что запрос не понят из-за син­таксических ошибок в нем. Ответ 401 Unauthorized означает, что запрос требует проведения процедуры аутентификации пользовате­ля. Существуют разные варианты аутентификации, и в ответе может быть указано, какой из них использовать в данном случае. Ответ

403 Forbidden означает, что сервер понял запрос, но отказался его обслуживать. Повторный запрос посылать не следует. Причины могут быть разными, например, запросы с этого номера не об­служиваются и т.д. Непосредственно из HTTP заимствован ответ

404 Not Found. А ответ 485 Ambiguous означает, что адрес вызы­ваемого пользователя не однозначен. Ответ 486 Busy Here озна­чает, что вызываемый пользователь в настоящий момент занят и не желает (не может) принять входящий вызов.

Ответы 5хх (server error) информируют о том, что за­прос не может быть обработан из-за ошибки сервера. Ответ

500 Server Internal Error означает, что сервер не имеет возмож­ности обслужить запрос из-за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время. Ответ

501 Not Implemented означает, что в сервере не реализованы ка­кие-либо функции, необходимые для обслуживания запроса. Ответ передается в том случае, когда сервер не может распознать тип за­проса, полученного им от любого из пользователей. Ответ 502 Bad Gateway информирует о том, что сервер, функционирующий в ка­честве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос. Ответ 503 Service Unavailable указывает, что сервер не может в данный момент об­служить вызов вследствие перегрузки или проведения техническо­го обслуживания.

Ответы 6xx (global failure) информируют о том, что соедине­ние с вызываемым пользователем установить невозможно. Ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может содержать указание на время, подходящее для его вызова. Если с пользователем можно связаться по другому адресу или, к приме­ру, оставить сообщение на речевой почтовый ящик, то используется ответ 486 Busy Here. Ответ 603 Decline означает, что вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа. Ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.

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

После того как мы рассмотрели запросы и разные ответы на них, видно, что протокол SIP предусматривает различные алгоритмы установления соединения.