2.3 Сценарии сеансов связи
2.3.1 В соответствии с архитектурой «клиент-сервер» все сообщения SIP делятся на запросы клиента серверу и ответы сервера клиенту. Запросы (команды) предназначены для выполнения задач при предоставлении базовых и дополнительных услуг в сетях фиксированной (стационарной) и подвижной (мобильной) связи. Ответы несут разную функциональную нагрузку, и их тип зависит от принятого запроса.
Сообщения SIP представляют собой последовательности текстовых строк. На рисунке 2.5 показана структура сообщения протокола SIP.
Стартовая строка представляет собой начальную строку любого SIP-сообщения.
Если сообщение является запросом, в стартовой строке указываются тип запроса, текущий узел-адресат и номер версии протокола.
Если сообщение является ответом на запрос, то в стартовой строке указываются номер версии протокола, тип ответа и короткая расшифровка ответа, предназначенная только для обслуживающего персонала и не обрабатываемая клиентом.
Заголовки сообщений содержат информацию об отправителе, адресате, пути следования и др., т.е. переносят информацию, необходимую для обслуживания сообщения (таблица 2.1).
Заголовок состоит из названия, за которым после двоеточия следует значение заголовка. Если сервер принимает сообщения с неизвестными ему заголовками, то он их игнорирует при обработке.
Рисунок 2.5 – Структура сообщения протокола SIP
Таблица 2.1 – Типы заголовков протокола SIP
Типы заголовков |
Характеристика |
|
Название |
Назначение |
|
Общие (присутствуют в запросах и ответах) |
Call-ID |
Идентификатор соединения |
Contact |
Контакт |
|
CSeq |
Порядковый номер запроса/ответа |
|
Date |
Дата |
|
Encryption |
Кодирование |
|
From |
Источник запроса |
|
To |
Адресат |
|
Via |
Через |
|
Record-Route |
Запись маршрута |
|
Заголовки содержания (информация о размере тела сообщения или об источнике запроса) |
Content-Encoding |
Кодирование тела сообщения |
Content-Length |
Размер тела сообщения |
|
Content-Type |
Тип содержимого |
|
Заголовки дополнительной информации о запросе |
Accept |
Принимается |
Accept- Encoding |
Кодирование принимается |
|
Accept-Language |
Язык поддерживается |
|
Authorization |
Авторизация |
|
Hide |
Скрыть |
|
Max-Forwards |
Максимальное количество переадресаций |
|
Organization |
Организация |
|
Priority |
Приоритет |
|
Proxy- Authorization |
Авторизация прокси-сервера |
|
Proxy-Require |
Требование прокси-сервера |
|
Route |
Маршрут |
|
Response-Key |
Ключ кодирования ответа |
|
Suject |
Тема |
|
User-Agent |
Агент пользователя |
|
Заголовки дополнительной информации об ответах |
Allow |
Разрешение |
Proxy-Authenticate |
Подтверждение подлинности прокси-сервера |
|
Retry-After |
Повторить через некоторое время |
|
Server |
Сервер |
|
Unsupported |
Не поддерживается |
|
Warning |
Предупреждение |
|
WWW-Authencate |
Аутентификация WWW-сервера |
|
2.3.2 Запросы (команды) SIP в спецификациях называются SIP-методы. Они предназначены для выполнения задач предоставления базовых и дополнительных услуг в сетях фиксированной и подвижной связи. С помощью команд клиент сообщает о своем текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке сообщения.
Виды запросов (команд) и их назначение показаны в таблице 2.2.
Таблица 2.2 – Типы запросов (команд) протокола SIP
Запрос (команда) |
Назначение |
INVITE |
Запрос на установление сеанса связи |
ACK |
Подтверждение приема ответа на команду INVITE |
BYE |
Разрушение соединения |
REGISTER |
Сообщение пользователя о своем текущем местоположении |
OPTIONS |
Запрос вызывающего пользователя о возможностях терминального оборудования вызываемого пользователя |
INFO |
Перенос между шлюзами сигналов сообщений в течение сеанса связи; перенос сигналов кода DTMF, созданных в ходе сеанса связи; перенос информации об остатке на счете (биллинговой информации); перенос между участниками сеанса связи изображений и другой не потоковой информации |
SUBSCRIBE |
Запрос на предоставление информации о состоянии определенного ресурса или процесса обслуживания вызова в сети |
MESSAGE |
Реализация служб интерактивного обмена текстовыми сообщениями с использованием модели, аналогичной отправке SMS |
REFER |
Команда получателю от отправителя связаться с третьей стороной, используя контактную информацию, которая содержится в этом сообщении (например, при переадресации вызова) |
После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на полученный запрос. Протокол SIP определяет два типа ответов на запрос, инициирующий соединение: предварительные и окончательные. Запросы и ответы на них образуют SIP-транзакцию. Она происходит между клиентом и сервером и включает в себя все сообщения, начиная с первого запроса и заканчивая окончательным ответом.
Предварительные (информационные) ответы показывают, что запрос находится в стадии обработки, передаются без подтверждения и кодируются трехзначным числом, начинающимся с единицы 1хх.
Окончательные ответы несут результат обработки запроса, передаются с подтверждением и кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Все они означают окончание обработки запроса, а каждый в отдельности – результат обработки запроса. Ответы 2хх означают, что запрос был успешно обработан. Ответы 3хх информируют оборудование вызывающего пользователя о новом местоположении вызываемого пользователя или переносят другую информацию, которая может быть использована для организации связи с ним. Ответы 4хх информируют об обнаружении ошибки в запросе, а ответы 5хх – о невозможности обработки запроса из-за ошибки сервера. Ответы 6хх сообщают о невозможности установления соединения с вызываемым пользователем (таблица 2.3).
Таблица 2.3 – Примеры видов ответов протокола SIP
Тип ответа |
Характеристики |
||
Код |
Название |
Комментарий |
|
Предварительные (информационные) |
100 |
Trying |
Обнуление таймеров в оборудовании пользователя. Если до срабатывания таймера ответ на запрос не получен, запрос считается потерянным |
180 |
Ringing |
Аналогичен сигналу КПВ в ТфОП |
|
181 |
Call Forwarding |
Перенаправление вызова к другому пользователю |
|
182 |
Queued for Service |
Постановка вызова в очередь для ожидания |
|
Окончательные |
200 |
OK |
Базовый ответ, значение которого зависит от полученного запроса |
300 |
Multiple Choices |
В ответе указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя |
|
302 |
Multiple Tempovarily |
Пользователь временно находится по адресу, указанному в поле ответа |
|
400 |
Bad Request |
Запрос не понят из-за синтаксических ошибок в нем |
|
486 |
Busy Here |
Вызываемый пользователь занят и не желает (не может) принять входящий вызов |
|
500 |
Server Internal Error |
Сервер не может обслужить запрос из-за внутренней ошибки |
|
501 |
Not Implemented |
В сервере не реализованы функции, необходимые для обслуживания запроса |
|
502 |
Bad Gateway |
Сервер, функционирующий в качестве шлюза или прокси-серверы, принимает некорректный ответ от сервера, к которому он направил запрос |
|
Продолжение таблицы 2.3
Тип ответа |
Характеристики |
||
Код |
Название |
Комментарий |
|
|
503 |
Service Unavailable |
Сервер не может обслужить вызов из-за перегрузки или проведения технического обслуживания |
600 |
Busy Everywhere |
Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может содержать указание на время, подходящее для вызова. Если с пользователем можно связаться по другому адресу, то используется ответ 486 |
|
603 |
Decline |
Вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа |
|
604 |
Does Not Exist Anywhere |
Вызываемого пользователя не существует |
|
Протокол SIP обеспечивает реализацию трех типов сценариев установления соединения:
с участием сервера перенаправления,
с участием прокси-сервера,
непосредственно между пользователями.
2.3.3 На рисунке 2.6 показан сценарий установления соединения с участием сервера перенаправления.
Рисунок 2.6 – Сценарий установления соединения через сервер перенаправления
Администратор сети сообщает пользователям адрес сервера перенаправления.
1. INVITE – вызывающий пользователь передает запрос на известный ему адрес сервера перенаправления и указывает в запросе адрес вызываемого пользователя в поле заголовка CSeq. В заголовке сообщения также указывается идентификатор соединения в поле Call-ID.
2. Запрос текущего адреса вызываемого пользователя – сервер перенаправления запрашивает текущий адрес у сервера определения местоположения.
3. Ответ с текущим адресом – сервер местоположения сообщает серверу перенаправления текущий адрес вызываемого пользователя.
4. 302 Multiple Tempovarily – сервер перенаправления сообщает вызывающей стороне текущий адрес вызываемого пользователя.
5. АСК – вызывающая сторона подтверждает прием ответа 302.
6. INVITE – вызывающая сторона непосредственно связывается с вызываемой стороной. Для этого передается новый запрос на установление сеанса связи с тем же идентификатором Call-ID, но с другим номером CSeq. В теле сообщения указываются возможности вызывающей стороны
7. 100 Trying – вызываемая сторона начинает обработку запроса и сообщает об этом вызывающей стороне ответом 100 для рестарта таймеров.
8. 180 Ringing –после обработки поступившего запроса оборудование вызываемого пользователя сообщает ему о поступившем вызове, а вызывающей стороне выдается ответ 180 для передачи пользователю сигнала «Ожидайте ответа».
9. 200 ОК – после приема вызываемым пользователем входящего вызова передается ответ, в котором содержится описание возможностей вызываемого терминала.
10. АСК – подтверждение приема ответа.
На этом фаза установления соединения закончена и начинается разговорная фаза.
11. BYE – запрос на разрушение соединения.
12. 200 ОК – подтверждение приема запроса на разрушение соединения.
2.3.4 На рисунке 2.7 показан сценарий установления соединения с участием прокси-сервера.
Администратор сети сообщает пользователям адрес прокси-сервера.
1. INVITE – вызывающий пользователь передает запрос на адрес прокси-сервера и указывает в запросе известный ему адрес вызываемого пользователя в поле заголовка CSeq. В заголовке сообщения также указывается идентификатор соединения в поле Call-ID.
2. Запрос текущего адреса вызываемого пользователя – прокси-сервер запрашивает текущий адрес у сервера определения местоположения.
3. Ответ с текущим адресом – сервер местоположения сообщает серверу перенаправления текущий адрес вызываемого пользователя.
4. INVITE – прокси-сервер передает запрос непосредственно вызываемому пользователю. В теле сообщения указываются возможности вызывающей стороны
5. 180 Ringing –после обработки поступившего запроса оборудование вызываемого пользователя сообщает ему о поступившем вызове, а вызывающей стороне выдается ответ 180 для передачи пользователю сигнала «Ожидайте ответа».
6. 200 ОК – после приема вызываемым пользователем входящего вызова передается ответ, в котором содержится описание возможностей вызываемого терминала.
7. АСК – подтверждение приема ответа.
На этом фаза установления соединения закончена и начинается разговорная фаза.
8. BYE – запрос на разрушение соединения
9. 200 ОК – подтверждение приема запроса на разрушение соединения.
Рисунок 2.7. – Сценарий установления соединения через прокси-сервер