Глава 3.ПРОТОКОЛ ИНИЦИАЦИИ СЕССИЙ SIP
Структура протокола SIP
Протокол инициации сессий SIP (SessionInitiationProtocol) был разработан группой MMUSIC (MultipartyMultimediaSessionControl) и описан в RFC 2543. Также как и протокол Н.323, SIPбыл создан для управления аудио- и видеоконференциями и входит в стек протоколов, обеспечивающих передачу мультимедийных сеансов.
Протокол SIP предназначен для организации, модификации изавершения мультимедийных конференций. При этом передачиинформации, контроль качества обслуживания и другие функциивозложены на разные протоколы, входящие в стек протоколов, который иногда называют по имени основного сигнального протокола SIP.
Стек протоколов поддержки мультимедийных сеансов представлен на рис 3.1.
Рисунок 3.1 - Стек протоколов поддержки мультимедийных сеансов
Передача аудио- и видеоинформации выполняется при помощи известных протоколов RTP/RTCP. Управление конференциямиосуществляется протоколом SCCP (SimpleConference Control Protocol).
При резервировании пропускной способности каналов дляконференции может использоваться протокол RSVP. СобственноSIP выполняет функции установления, поддержки и разъединениясессий, то есть является сигнальным протоколом. Вся информацияпо характеристикам устанавливаемой сессии определяется протоколом SDP (Session Description Protocol), данные которого вкладываются в сообщения SIP. Кроме информации протокола SDP в сообщения SIP могут вкладываться данные и других протоколов,например ISUP.
Как видно из рис. 3.1, протокол SIP может использовать в качестве транспорта как стек протоколов UDP/IP, так истек TCP/IP. Однако, на практике стек TCP/IP обычно не используется.
Протокол SIP является текстовым протоколом, использующимсинтаксис и структуру протокола HTTP. Протокол SIP построен попринципу «клиент – сервер». Клиент посылает запросы на сервер,в которых указывает, что он хочет получить от сервера. Серверобрабатывает запросы и выдает ответы, которые могут содержатьуспешные результаты обработки или сообщения о сбоях и ошибках.Основным сетевым элементом, обеспечивающим управлениесоединением, является терминал, который выполняет функцииагента пользователя UA (User Agent). Программное обеспечениеUA имеет клиентскую и серверную части, которые также размещаются в терминале.
|
|
Сервера в архитектуре SIP (SIP server) отвечают за маршрутизацию вызовов и предоставление дополнительных услуг.
В зависимости от своего назначения, различают несколько типов серверов SIP:
- прокси-сервер (Proxy server) – обеспечивает взаимодействие стерминалами;
- сервер определения месторасположения (Registrar server илиLocation Server) – обеспечивает определение текущего адресавызываемого абонента;
- сервер переадресации (Redirect server) – обеспечивает переадресацию вызова на текущий адрес вызываемого абонента.
Сообщения SIP
Все сообщения SIP представляют собой последовательноститекстовых строк (RFC 2279), организованных в следующую структуру:
1. Стартовая строка сообщения.
2. Заголовки (общие, содержания, запросов/ответов).
3. Содержание сообщения (тело).
В протоколе SIP определено шесть типов запросов. Тип запроса указывается терминалом в стартовой строке.
Запрос REGISTER посылается для указания своего текущего
месторасположения, новой адресной информации и продолжительность регистрации.
Запрос INVITE приглашает вызываемого пользователя участвовать в сеансе связи, а также содержит SIP-адрес вызываемогопользователя и описание сеанса.
|
|
Запрос ACK подтверждает прием ответа на запрос INVITE исодержит окончательное (согласованное) описание сеанса связи.
Запрос BYE посылается оборудованием терминала, которыйхочет завершить сеанс связи. Терминал, получивший BYE долженпрекратить передачу информации и подтвердить свои действияответом.
Запрос CANCEL отменяет обработку ранее переданных запросов с указанными идентификаторами.
Запрос OPTIONS посылается для получения информации овозможностях терминального оборудования вызываемого пользователя.
Все ответы делятся на информационные и окончательные (финальные).
Информационные ответы кодируются трехзначным числом извторой и третьей сотни 1xx. Информационные ответы переносятсообщения о выполняемых в настоящий момент действиях, например 100 Trying – процесс установления сеанса продолжается,180 Ringing – КПВ.
Ответы 2xx означают, что запрошенное действие успешно выполнено.
Ответы 3xx информируют вызывающего пользователя о перемещении вызываемого пользователя. Например, 302 MovedTemporary– пользователь временно находится по другому адресу.
Ответы 4xx информируют о наличии ошибки в полученномзапросе. Например, 402 Unauthorized – означает необходимостьпроведения процедуры аутентификации.
Ответы 5xx информируют о невозможности выполнения запроса из-за отказа сервера. Например, 503 Service Unavailable –служба недоступна.
Ответы 6xx информируют о невозможности связи с вызываемым пользователем. Например, 600 BusyEverywhere – вызываемый абонент занят.
|
|
В качестве адресов в SIP используются универсальные указателиресурсов – URL (UniversalResourceLocators) – SIPURL.
SIP-адреса бывают 4-х типов:
- Имя @ домен.
- Имя @ хост.
- Имя @ IP – адрес.
- N телефона @ шлюз.
Таким образом, адрес состоит из 2-х частей. Первая включаетимя пользователя или номер телефона. Вторая указывает имя домена, хоста или шлюза.
Примеры SIP- адресов:
SIP: asa@mtuci.ru
SIP: victor@192.168.0.3
SIP: 1886229@sipgate.de.
Сценарий установления соединения
Рассмотрим алгоритм установления сессии через 2 прокси-сервера, каждый из которых обслуживает свою группу пользователей.
В качестве начальных условий положим, что терминал 1зарегистрирован на SIP-сервере 1, а терминал 2 – на SIP-сервере 2.
1. Перед началом сессии терминал 2 должен быть зарегистрирован на Proxy-сервере (запрос REGISTER).
2. Терминал 1 посылает запрос INVITE к своему SIP-серверу.
3. SIP-сервер 1 отвечает сообщением 100 TRYING.
4. SIP-сервер 1 пересылает запрос INVITE SIP-серверу 2.
5. SIP-сервер 2 отвечает сообщением 100 TRYING.
6. SIP-сервер 2 посылает запрос INVITE терминалу 2.
Рисунок 3.2 - Сценарий установления сессии (часть 1)
7. Терминал 2 отвечает сообщением 180 RINGING.
8. SIP-сервер 2 пересылает сообщение 180 RINGING SIP-серверу1.
9. SIP-сервер 1 пересылает сообщение 180 RINGING терминалу1.
10. Терминал 2 отвечает SIP-серверу 2 сообщением 200 OK.
11. SIP-сервер 2 пересылает сообщение 200 OK к SIP-серверу 1.
12. SIP-сервер 1 пересылает сообщение 200 OK терминалу 1.
13. Терминал 1 отвечает SIP серверу 1 сообщением ACK.
14. SIP-сервер 1 пересылает это сообщение SIP серверу 2.
15. SIP-сервер 2 пересылает это сообщение терминалу 2.
16. Между терминалами устанавливается сессия (RTP/RTCP).
Рисунок 3.2 - Сценарий установления сессии (часть 2)
После окончания разговорной фазы терминал 1 посылает запрос BYE, который транслируется прокси-серверами к терминалу2. Терминал 2 посылает ответ 200 OK, после чего терминалы возвращаются в исходное состояние.
Формат сообщений SIP
Рассмотрим подробнее структуру SIP запросов и ответов.
Рисунок 3.3 - Структура сообщения SIP
Каждое сообщение SIP (запрос или ответ) начинается со стартовой строки. Если сообщение является запросом, то в стартовойстроке (Request-Line) указываются: тип запроса, адресат и номерверсии протокола SIP.
В стартовой строке ответа (Status-Line) указываются: номер версии протокола SIP, тип ответа и краткая расшифровка действий.
Заголовок сообщения содержит достаточно много полей, которые будут расшифрованы позже.
Пустая строка CLRF отделяет заголовок SIP сообщения от содержания, которое включает информацию по описанию будущейсессии при помощи протоколов SDP, ISUP...
В заголовке сообщения SIP размещаются следующие поля: Via(Через), From (От), To (Кому), Contact (Контакт), Call ID (Идентификатор вызова), Cseq (Номер запроса), Authorization (Авторизация), Max-Forwards (Макс. переадресаций), User Agent (Агентпользователя), Content Type (Типсодержимого) и Content-Length(Длина содержимого).
Поле Via содержит информацию о маршруте: при прохождении каждого прокси-сервера его адрес записывается в этом поле.
Таким образом, в поле Via будет записан весь пройденный маршрут. Это дает возможность отправить ответ по тому же пути. Параметр branch означает, что на данном сервере запрос был размножен и передан по указанному направлению.
В поле From указывается адрес вызывающего пользователя.Кроме адреса здесь же указывается параметр tag для идентификации конкретного терминала пользователя.
В поле To указывается SIP-адрес вызываемого пользователя.
В поле Contact помещается SIP-адрес пользователя, по которому с ним можно установить контакт.
В поле Call ID помещается уникальный идентификатор сеансасвязи, состоящий из буквенно-цифрового идентификатора и именитерминала, который присвоил этот идентификатор (например,5CC933F2BADC5802@pc.alcatel.be).
В поле CSeq записывается уникальный идентификатор запроса, относящегося к данному соединению.
В поле Authorization записываются параметры, используемыепри авторизации. Параметр Digest описывает метод авторизациипо HTTP.
Параметр Nonce включает случайное криптографическоечисло, realm – содержит имя домена и т.д.
В поле Max-Forwards указывается максимальное число переадресаций. Используется для предотвращения петель.
В поле User Agent указывается тип терминала.
В поле Content Type указывается тип передаваемой информации.
В поле Content-Length указывается длина содержимого в октетах.
Рассмотрим конкретный пример записи сообщения Register,
представленный на рис. 3.4.
На рис. 3.4 приведен текст запроса REGISTER, который посылает пользователь LeonhardStiegler на свой прокси-сервер.
В стартовой строке запроса указан адрес прокси-сервера
(sip:sipgate.de), версия протокола SIP/2.0, и наименование запроса
(Method: REGISTER).
В поле Via указан IP-адрес терминала и порт.
Рисунок 3.4 Пример записи запроса REGISTER
В поле From указан SIP адрес пользователя (sip:1886929@sipgate.de – в формате: № телефона@шлюз).
Поскольку пользователь предполагает получить ответ на регистрацию, то он указывает в поле «To» свой же SIP-адрес.
В поле контакт размещен SIP-адрес и IP-адрес + порт пользователя.
Поле Call ID содержит уникальный идентификатор вызова впределах домена sipgate.de.
В поле Cseq указан порядковый номер запроса – 13012, а вподполе Expires = 1800 время длительности регистрации в секундах.
В поле Authorization приведены имя пользователя (username) иего универсальный идентификатор URI, имя сервера регистрации(realm), атакже параметры авторизации (nonce, response).
В сообщении отсутствует содержание, поэтому в поле Content-Length стоит «0».
Допустим, что в ответ на приведенный запрос Register терминалполучит сообщение 401 Unauthorized (рис. 3.5).
Это означает, что сервер отказывается регистрировать данного
пользователя и посылает ему значение поля nonce =”43c23548f0…”.
Если терминал сможет правильно обработать полученное значение, то при повторном запросе он будет зарегистрирован на этомсервере и получит ответ 200 ОК.
В результате приема такого ответа терминал получает от сервера данные аутентификации: Digestrealm = "sipgate.de", nonce ="43c23548f0...".
Получив этот ключ и запросив собственную программу аутентификации, терминал вновь обращается к серверу иполучает регистрацию.
Рисунок 3.5 - Пример записи ответа 401 Unauthorized