Поля заголовка сообщения при регистрации SIP

Настоящий раздел посвящен описанию состава сообщений SIP на примере регистрации SIP и принципа мобильности пользователя.

Каждое сообщение SIP состоит из трех полей: начальная строка, заголовок сообщения и тело сообщения.

На рис. 18.3. показан пример содержания сообщений для простой транзакции: запрос REGISTER и положительный ответ на него. Как правило, функции сервера регистрации и прокси-сервера выполняет тот же сервер. Агент пользователя UA посылает запрос REGISTER на сервер регистрации домена, представляя свой текущий адрес в поле заголовка Соntact. Постоянный адрес SIP пользователя AoR содержится в поле To запроса. Сервер регистрации модифицирует базу данных расположения служб, чтобы привязать постоянный адрес пользователя к его текущему адресу.

 

Структура сообщения запрос REGISTER

REGISTER sip:iptel.org;transport=udp

From: “Jiri”@iptel.org>

To:: “Jiri”@iptel.org>

Cseq: 119065 REGISTER

Соntact:<sip:jiri@192.168.1.101>;expires=3600

 

 

Структура сообщения ответ REGISTER

200 ОК

From: “Jiri”@iptel.org>

To: “Jiri”@iptel.org>

Cseq: 119065 REGISTER

Соntact:<sip:jiri@192.168.1.101>;expires=3600

 

Рис. 18.3. Сообщения транзакции: запрос REGISTER и положительный ответ на него

 

Начальная строка

В поле начальной строки запроса определена цель сообщения. При этом указывается идентификатор тип запроса и адрес назначения в форме URI. На рис. 18.3 это REGISTER и имя домена назначения iptel.org. Обращаясь к серверу регистрации, пользователь указывает адрес, по которому он находится в настоящее время. Адрес URI в начальной строке, sip:iptel.org;transport=udp, служит для маршрутизации с целью выполнения запроса REGISTER. В качестве транспортных протоколов модели TCP/IP могут использоваться протоколы UDP или TCP. В данном случае используется транспортный протокол UDP. Этот дейтаграммный протокол не устанавливает соединение на транспортном уровня. Надежная передача обеспечивается повтором запроса.

При прохождении запроса через несколько серверов SIP может потребоваться изменение маршрутизации или услуги, что в свою очередь может потребовать изменение адреса назначения. Например, к пользователю потребуется направить запрос по IP-адресу. Тогда URI изменяется на sip:juri@10.0.0.1; transport=tcp. В данном случае используется транспортный протокол TCP, устанавливающий соединение. Начальная строка ответа является строкой состояния и указывает на результат в цифровой и текстовой форме. В этом примере 200 ОК.

Заголовок сообщения

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

· To: идентификатор получателя запроса. Это поле содержит адрес AoR получателя запроса.

· From: идентификатор отправителя запроса. Это поле содержит адрес AoR отправителя запроса.

Часто недостаточно адреса SIP в поле From, особенно в случаях, когда вызовы SIP оканчиваются в ТфОП. При этом оборудование не может идентификатор вызывающего пользователя идентифицировать в нецифровой форме. В таком случае прокси-сервер добавляет к полю From поле заголовка P-Asserted-Identity телефонный номер отправителя, как показано на рис. 18.4.

 

From: “John doe” [e-mail]; tag=9texf/

P-Asserted-identity:<tel:[phone]>

Рис. 18.4. Поле заголовка From в комбинации с заголовком P-Asserted-Identity

 

С точки зрения информационной безопасности оба заголовка From и P-Asserted-Identity могут быть легко изменены злоумышленником, так как уязвимы угрозе «человек посередине». В качестве защиты может быть использован протокол безопасности на транспортном уровне TLS (глава 13).

Для того, чтобы быть уверенным в том, что источник запроса является тот, за кого он себя выдает SIP использует протокол аутентификации, основанный на разделении пароля между сервером и клиентом. Детали этого протокола изложены ниже.

· Contact: описывает местонахождение клиента. Это особенно важно для запроса пользователя REGISTER. В поле Contact этого запроса содержится текущий (контактный) адрес SIP телефона, который должен быть связан с постоянным (глобальным) адресом AoR. Это поле заголовка имеет параметр expires, который указывает на период времени эта привязка допустима. На рис. 18.3 для параметра expire установлено значение 3600 секунд. Для сохранения этой привязки агент UA периодически посылает сообщения регистрации, чтобы обновлять эту информацию. Такой механизм регистрации контактного адреса на сервере регистрации позволяет протоколу SIP поддерживать мобильность пользователя. Когда агент UA посылает запрос REGISTER серверу регистрации SIP он уведомляет службу расположения о своем текущем адресе. Теперь прокси-сервер может передавать запросы этому мобильному пользователю на основании контактного адреса в базе данных сервера местоположения.

· CSeq: целочисленное значение последовательности запросов и названия запроса (в примере REGISTER). Это поле служит для защиты от потери сообщений или повторной их передачи.

· Via: поле заголовка в каждом прокси-сервере содержит список элементов сети SIP, через которые запрос прошел. Список нужен для тех случаев, когда необходимо, чтобы запросы и ответы проходили по одному и тому же пути.

· Record-Route: поле заголовка Record-Route используется для того, чтобы запомнить путь инициализирующего запроса на пути от UAC до UAS. Все прокси-сервера добавляют эти поля для того, чтобы следующие запросы в процессе диалога маршрутизировались через эти же прокси-серверы.

• Rout: поле заголовка служит для принудительной маршрутизации запроса в соответствии со списком прокси-серверов.

· Loop detection (обнаружение петли). Каждый SIP запрос должен включать счетчик, который указывает сколько «хопов» может еще пройти. Этот счетчик называется Max-Forwards и напоминает “Время жизни“ в заголовке IP-пакета. Первоначальное значение устанавливается клиентом. Это число уменьшается каждым сервером, который пересылает запрос далее.

· User-Agent и Warning. Поле заголовка User-Agent содержит ограниченную информацию о клиенте, инициирующем запрос. Поле заголовка Warning содержит дополнительную информацию, об инициаторе ответа.

· Proprietary extention (частные расширения). Некоторые производители считают полезным расширение некоторых возможностей, но не переносят на них стандартизацию. В качестве примера может быть использовано оборудование, фиксирующее качество обслуживания QoS по завершению вызова.

 

Тело сообщения

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

Протокол SDP, определенный в RFC 2327, описывает содержимое сессий, включая телефонию, приложения мультимедиа. SDP содержит также следующую информацию.

Медиа потоки: сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения, сходные с MIME типами электронной почты в Интернете.

Адреса: SDP указывает адреса места назначения для медиа потоков при многоадресной (multicusting) передаче.

Время старта и остановки: Эти данные используются в случае широковещательных сессий, например, телевизионных или радио программ. Указываются время начала, завершения и времена повторов сессии.

Документ RFC 3264 предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно данных, подлежащих пересылке. Примером информации в поле тела сообщения может быть, например, выбор кодека при использовании телефонии.

Как показано ниже (в подразделе 18.1.4) в протоколе SIP для телефонии (SIP-T) предусмотрено инкапсулирование в тело запроса INVITE и ответов сообщений ОКС№7 прикладного уровня ISUP.

Транзакции и диалоги SIP

SIP – это протокол ориентированный на транзакции: взаимодействие между элементами сети происходит путем обмена сообщениями. Транзакция SIP осуществляется между агентами UAC и UAS. Она включает все промежуточные серверы SIP и состоит из всех сообщений запросов и ответов, начиная с INVITE и кончая окончательным ответом агента UAS. Транзакция SIP может установить, изменить или завершить мультимедийный сеанс. Одна транзакция состоит из запроса и нескольких ответов на него. Из приведенного примера на рис. 18.2 видно, что в транзакцию запроса INVITE входит еще один запрос ACK. Процедура транзакции запроса INVITE сложнее, чем процедуры транзакций других запросов. Примером может быть возможность отменять транзакцию после переданного запроса, если ответ на него еще не получен. Для этого необходимо отправить запрос CANCEL. Другим примером является возможность разветвления прокси-сервером запроса INVITE на несколько пунктов назначения.

Транзакция SIP может привести к установлению, изменению или завершению мультимедийного сеанса. На одном установленном сеансе может осуществляться несколько определенных транзакций. Такое состояние отношений между двумя или несколькими агентами UA называется диалогом. Транзакции SIP используют протоколы транспортного уровня TCP и UDP. При использовании протокола UDP приложение SIP запускает таймер для повторения запроса и гарантии сквозной надежности.

Маршрутизация сообщений SIP

Основная функция прокси-сервера является маршрутизация. Для маршрутизации сообщения поле заголовка сообщения INVITE содержит запись адреса AoR SIP вызываемого пользователя. Прокси-сервер использует этот адрес для поиска адреса получателя. Запрос может пройти через несколько прокси-серверов прежде, чем достигнет агента назначения UAC. Каждый прокси-сервер на пути следования должен принимать решение о маршрутизации. Прокси-сервер может перезаписать URI запроса и добавить в заголовок поле Via. Ответы SIP проходят через тот же набор прокси-серверов, что и запрос, но в обратном направлении. Прокси-сервер обычно выполняет функцию сервера регистрации. Таким образом, прокси-сервер имеет доступ к базе данных расположения пользователя назначения, которая создается при регистрации этого пользователя. Если в строке запрос указан прокси-сервер, несущий ответственность за домен, он осуществляет поиск в базе данных. В результате поиска могут быть получены адреса, по которым находится вызываемый пользователь. В результате сервер SIP, прежде всего, выполняет функцию маршрутизации, т.е. определяет устройство следующей транзитной точки, на которое следует переслать сообщение SIP. Ближайшая точка перехода может быть другим прокси-сервером, сервером переадресации, шлюзом ТфОП или оконечным агентом UAC.

Протокол SIP-T

 

Звонки в SIP-телефонии можно совершать с компьютера или специального SIP-телефона, непосредственно подключенных к сети Интернет, либо с обычного телефона (через набор индивидуального пин-кода доступа), подключенного к Интернет через ТфОП. Разработан стандарт RFC 3372 [55] (c переводом в работе [56]) по установлению соединений стационарных аппаратов через сеть SIP. Такие протоколы получили название SIP-T (SIP extention for Telepfony, распространение SIP для телефонии). Кратко изложим некоторые положения этого стандарта.

На рис. 18.5 приведена схема прохождения сообщений сигнализации при установлении соединений между абонентами сети ТфОП. Она включает:

· участки ОКС№7 между граничными станциями ТфОП/ISDN и шлюзами сигнализации MGC (Media Gateway Controller) - MGC1 и MGC2. При этом имеется в виду сообщения всех четырех уровней системы ОКС№7. Шлюзы производят преобразование сигнальных сообщений протоколов ОКС№7 в сигнальные сообщения протокола SIP и наоборот. Шлюз MGC называют также Softswitch, преобразователем систем сигнализации. Со стороны сети SIP он является клиентом агента пользователя UAC.

· сеть SIP.

***** | proxy |***** *** *** * * * * * * * * |----| |----| /|MGC1| Cеть SIP |MGC2|\ / ---- ---- \ ОКС№7 * * ОКС№7 / * * \ / * * \ -------- * * --------- | ТфОП | ** ** | ТфОП | -------- ******* | proxy | **** ---------

Рис. 18.5. Структура транзитной связи сигнализации через сеть SIP при установлении/разъединении соединений между абонентами сети ТфОП через сеть SIP

Требования по взаимодействию систем сигнализации и функции протокола SIP-T изложены в стандарте RFC 3372 (табл. 18.1).

Таблица 18.1. Требования по взаимодействию систем сигнализации и функции протокола SIP-T

Требования по взаимодействию ОКС№7- SIP	Функции SIP-T
Прозрачность сети SIP для сигнализации ISUP	Инкапсуляция ISUP в тело запросов SIP
Маршрутизация сообщений SIP по информации в ISUP	Трансляция информации из ISUP в заголовок запросов SIP
Передача дополнительной сигнальной информации ISUP во время сеанса связи (например, перенос информации об остатке на счете – биллинговой информации)	Использование запроса SIP - INFO

На рис. 18.6 показана упрощенная диаграмма примера обмена сообщениями сигнализации (прикладного уровня ОКС№7, запросы и ответы SIP). Она соответствует приведенной выше на рис. структуры транзитной связи при установлении соединения.

TфОП/ISDN MGC1 Proxy MGC2 TфОП/ISDN |-------IAM------>| | | | | |-----INVITE---->| | | | | |-----IAM----->| | |<--100 TRYING---| | | | | |<----ACM------| | |<-----18x-------| | |<------ACM-------| | | | | | | |<----ANM------| | |<----200 OK-----| | |<------ANM-------| | | | | |------ACK------>| | |===Двусторонняя передача речи по протоколу RTP===|

Рис.18.6. Диаграмма примера обмена сообщениями сигнализации

 

Сообщения ОКС№7 соответствуют прикладному уровню ISUP (см. рис.17.7, глава 17). В шлюзе MGC1 сообщение ОКС№7 IAM инкапсулируется в тело запроса INVITE. Кроме этого из IAM в заголовок INVITE переносятся:

в поле From – адрес вызываемого абонента;

в поле To – адрес вызывающего абонента.

Стек уровней устройств SIP-T включает протоколы уровней системы сигнализации ОКС-7, системы сигнализации SIP и уровней адаптации. Уровень адаптации обеспечивает интерфейс так, что транспортировка протоколов уровней сигнализации ОКС-7 осуществляется в IP-среде. На рис. 18.6, а приведен пример одного из участков SIP-T действующей сети РФ.

Рис.18.6,а. Пример участка SIP-T сети Р.Ф

Протоколы переноса сообщений ОКС-7 через сеть IP, на основе которой построена система сигнализации SIP, разработаны группой SIGTRAN, входящей в техническую комиссию Интернета – IETF. Архитектура SIGTRAN предусматривает следующие уровни:

· стандартный протокол IP;

· уровень усовершенствованного протокола транспортного уровня TCP – протокол управления передачей потока SCTP ( Stream Control Transmission Protocol).

• уровень адаптации, обеспечивающий интерфейс с протоколами и приложениями ОКС-7.

В результате производится передача сообщений верхнего уровня ОКС-7 в IP-сети. Интерфейс IP-сети с внешней сетью ОКС-7 обеспечивает шлюз сигнализации SG (Signaling Gateway). Одним из примеров является протокол M2UA уровня адаптации для пользователей уровня MTP2 (MTP2 Level User Adaptation Layer). Этот протокол предусматривает набор услуг, эквивалентный тому, который предоставляет уровень MTP2 уровню MTP3 в системе сигнализации ОКС-7. Шлюз SG является окончанием для звена сигнализации ОКС-7 MTP2. Используя протокол M2UA, сообщение MTP3 (с входящим в него данными пользовательского уровня ISUP) передается в Softswitch в сообщении транспортного уровня SCTP.

Интерфейс IP-сети с внешней сетью ОКС-7 обеспечивают шлюзы сигнализации. На рисунке представлен вариант, когда на Softswitch включает стандартные приложения ISUP и стандартный протокол МТР3. При этом у Softswitch есть собственный код пункта сигнализации и, являясь полноправным пунктом сигнализации сети ОКС-7, принимает и передает сообщения ОКС-7, в том числе и сообщения эксплуатационного управления сетью сигнализации [10]. Однако в Softswitch отсутствует MTP2.