Какое первое сообщение отправляет оконечное устройство sip когда устанавливает сессию

Обновлено: 02.07.2024

4.4.9.8 Протокол запуска сессий SIP
Семенов Ю.А. (ГНЦ ИТЭФ)

Протокол SIP (Session Initiation Protocol) описан в документе RFC 3261, (смотри также [6] и The Internet Protocol Journal V6, N1, March 2003, William Stallings, “The Session Initiation Protocol”), и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно так и мультимедийные приложения, включая видеоконференции.

Протокол SIP является лишь одним из протоколов, которые обеспечивают мультимедийный обмен через Интернет. SIP представляет собой сигнальный протокол, который позволяет одному партнеру послать запрос другому и согласовать параметры мультимедиа сессии (см. RFC-2848, -3050, -3261-65, -3311-13, -3319,-3325-3329, -3351, -3398, -3428, -3455, -3485, -3487, -3515, -3666, -3840, -3891-93, -4123, -4354, -4458, -4497, -4504, -4508, -4538, -4575, -4579, -4596, -4662, -4730, -4740, -4780, -4916, -5002, -5009, -5039, -5049, -5079, -5118).

Собственно транспортировка мультимедиа данных обычно осуществляется с помощью протокола RTP (Real-Time Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций:

Положение пользователя: Пользователи могут менять свое положение и сохранять доступ к телефонии и другим приложениям дистанционно.

Доступность пользователя: Предполагается проверка готовности парнера-адресата участвовать в коммуникациях.

Возможности пользователя: Определяются параметры среды, которые должны быть использованы.

Формирование сессии: Создается соединение точка-точка или сессия с несколькими партнерами при заданных коммуникационных параметрах.

Управление сессией: Предполагается создание и завершение сессий, модификация параметров сессии и сервисов.

Компоненты и протоколы SIP

Система, использующая SIP, может рассматриваться состоящей из клиентов, серверов и индивидуальных сетевых элементов. RFC 3261 определяет клиента и сервер следующим образом:

Индивидуальные элементы стандартной конфигурации включают в себя:

Агент пользователя: Агент пользователя резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли.

Агент пользователя клиента UAC (User Agent Client): Посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы

Сервер переадресации: Сервер переадресации используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может использоваться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, используемое для Web адресов имеет тип URI. Подробнее это рассмотрено в RFC 2396 [1].

Регистратор: Регистратор является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который им обслуживается.

Служба локализации: Служба локализации используется серверами переадресации SIP или прокси, чтобы получить информацию о возможном положении источника запроса. Для этой цели служба локализации поддерживает базу данных SIP-адресов/ IP-адресов.

В RFC 3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или они могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере

Рис. 1. Протоколы и компоненты SIP

На рис. 1 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они используют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии использует SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя используют также протокол SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Универсальные локаторы ресурсов SIP

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

URI SIP имеют формат, базирующийся на формате адресов e-mail, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму:

Примеры работы

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

Первая строка содержит название метода (INVITE), SIP URI, номер используемой версии протокола SIP. Последующие строки представляют собой список полей заголовка. В данном примере представлен минимально необходимый набор.

Заголовок Max-Forwards ограничивает число шагов, которые запрос может сделать до точки назначения. Содержимое этого поля является целым числом, которое декрементируется на 1 каждым прокси, переадресующим запрос. Если значение Max-Forwards станет равным 0, прежде чем запрос достигнет места назначения, он отвергается с кодом ошибки в отклике равным 483 (Too Many Hops – слишком много шагов).

Поле заголовка Call-ID содержит глобально уникальный идентификатор данного вызова, генерируемый из комбинации псевдослучайной строки и имени ЭВМ или IP-адреса. Комбинация тэгов To, From и Call-ID полностью определяет отношение SIP партнеров А и B.

CSeq или поле заголовка Command Sequence содержит целое число и имя метода. Число CSeq инициализируется в начале вызова (в данном примере 314159), инкрементируется для каждого нового запроса в рамках диалога, и является традиционным порядковым номером. CSeq используется, чтобы отличить повторную передачу от нового запроса.

Типы откликов SIP, определенных в RFC 3261 имеют следующие категории:

Протокол описания сессии

Протокол SDP (Session Description Protocol), определенный в RFC 2327, описывает содержимое сессий, включая телефонию, Интернет радио, приложения мультимедиа. SDP содержит информацию о [8]:

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

Адресах: SDP указывает адреса места назначения, которые могут быть для медиа потоков мультикастинг-адресами.

Портах: Для каждого потока специфицируются номера UDP портов для отправителя и получателя.

Типах данных: Для каждого используемого типа потока (например, телефония), тип поля данных указывает на медиа форматы, которые могут использоваться во время сессии.

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

Инициаторе: Для широковещательных сессий, инициатор специфицируется, контактной информацией. Это может быть полезно, если получатель встретится с техническими трудностями.

Одним из применений протокола SIP является организация сессий передачи голоса по каналам Интернет (VoIP).

В интернете существует достаточно большое количество приложений, которые заточены на создание и взаимодействие с так называемыми сессиями, где сессия — это обмен данными между связанными ею участниками (диалог). SIP — это протокол программного уровня, который позволяет устанавливать, модифицировать и терминировать мультимедийные сессии, в разрезе интернет-телефонии. С помощью SIP возможно подключать новых участников к уже существующим […]

SIP — это протокол программного уровня, который позволяет устанавливать, модифицировать и терминировать мультимедийные сессии, в разрезе интернет-телефонии. С помощью SIP возможно подключать новых участников к уже существующим сессиям (диалогам), организовывая таким образом групповые(multicast) конференции. Протокол свободно поддерживает службы сопоставления имен и службы переадресации, что добавляет ему мобильность и подвижность в плане работы с сетевым уровнем и взаимодействию с оконечными пользовательскими устройствами!

Протокол SIP представляет собой клиент-серверное взаимодействие и определяет собой 5 ключевых точек, в отношении установления и терминации мультимедиа-диалогов:

Status-Code представляет собой трехсимвольное цифровое значение, символизирующее собой результат попытки сервера понять и обработать переданный ему запрос. Reason-Phrase служит для более удобного восприятия данных кодов, и несет в себе их короткое текстовое описание. Можно сказать, что Status-Code предназначен для программной расшифровки протокола, а Reason-Phrase для человеческой(инженерной). Более подробно этой темы мы коснемся во второй части статьи.

рис. 1 рис. 2

```Имя поля: значение поля```

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

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

Subject: Я знаю, что ты здесь, подними трубку!

Порядок следования заголовков роли не играет, ровно до тех пор, покуда не передаются заголовки с одинаковыми именами полей!

Так или иначе, рекомендуется использовать в шапке заголовки, которые имеют прямое отношения к службам перенаправления запроса(прокси-серверам) и подобным ей. Такими заголовками могут быть: Via, Route, Record-Route, Proxy-Require, Proxy-Authorization, Max-Forwards, и другие.

В целом, порядок следования заголовков значения не имеет, кроме случаев, когда должны передаваться заголовки с одинаковыми именами полей! За редким исключением, такие заголовки можно объединить в одну пару >, отделив с помощью запятой их значения друг от друга.

Простое взаимодействие клиентов

Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.

Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:

Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.

Поля заголовков имеют следующий формат: :

Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.

Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.

Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.

Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.

Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:

Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.

Наконец, в поле Contact содержится актуальный адрес Ивана.

Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.

В ответ на 200 ОК клиент Петра отправляет подтверждение:

Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.

Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:

Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:

Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).

В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.

Содержание

История разработки

Принципы протокола

Разработкой занималась организация IETF MMUSIC Working Group. Протокол начал разрабатываться в 1996 году Хенингом Шулзри (Henning Schulzrinne, Колумбийский университет) и Марком Хэндли (Университетский колледж Лондона). В ноябре 2000 года SIP был утверждён как сигнальный протокол проекта 3GPP и основной протокол архитектуры IMS (модификация 3GPP TS.24.229. Наряду c другим распространённым протоколом H.323, SIP — один из протоколов, лежащих в основе Voice over IP. В основу протокола рабочая группа MMUSIC заложила следующие принципы:

Дизайн протокола

Клиенты SIP традиционно используют порт 5060 TCP или UDP для соединения элементов SIP-сети. В основном, SIP используется для установления и разъединения голосовых и видеозвонков. При этом он может использоваться и в любых других приложениях, где требуется установка соединения, таких, как системы оповещения, мобильные терминалы и так далее. Существует большое количество рекомендаций RFC, относящихся к SIP и определяющих поведение таких приложений. Для передачи самих голосовых и видеоданных используют другие транспортные протоколы, чаще всего RTP. Главной задачей разработки SIP было создание сигнального протокола на базе IP, который мог бы поддерживать расширенный набор функций обработки вызова и услуг, представленных в существующей ТфОП. Сам протокол SIP не определяет этих функций, а сосредоточен только на процедурах регистрации пользователя, установления и завершения вызова и соответствующей сигнализации. При этом он был спроектирован с поддержкой таких функциональных элементов сети, как прокси-серверы (Proxy Servers) и Пользовательские Агенты (User Agents). Эти элементы обеспечивают базовый набор услуг: набор номера, вызов телефонного аппарата, звуковое информирование абонента о статусе вызова. Телефонные сети на основе SIP могут поддерживать и более современные услуги, обычно предоставляемые ОКС-7, несмотря на значительное различие этих двух протоколов. ОКС-7 характеризуется сложной, централизованной интеллектуальной сетью и простыми, неинтеллектуальными, терминалами (традиционные телефонные аппараты). SIP — наоборот, требует очень простую (и, соответственно, хорошо масштабируемую) сеть с интеллектом, встроенным в оконечные элементы на периферии (терминалы, построенные как физические устройства или программы). SIP используется вместе с несколькими другими протоколами и участвует только в сигнальной части сессии связи. SIP выполняет роль носителя для SDP, который описывает параметры передачи медиаданных в рамках сессии, например используемые порты IP и кодеки. В типичном применении сессии SIP — это просто потоки пакетов RTP. RTP является непосредственным носителем голосовых и видеоданных. Первая предложенная версия стандарта (SIP 2.0) была определена в RFC 2543. Протокол был дополнительно уточнён в RFC 3261, хотя многие реализации по-прежнему основаны на промежуточных версиях стандарта. Обратите внимание, что номер версии остался 2.0.

Адресация

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей, SIP использует адрес, подобный адресуэлектронной почты. В качестве адресов рабочих станций используются универсальные указатели ресурсов URI, так называемые SIP URI. Обычно используется следующий формат [sip ":"] идентификатор ["@" фрагмент], где идентификатор указывает на логин абонента или его номер телефона, а фрагмент определяет хост, который может быть задан доменным именем или IP-адресом. Примеры:

логин абонента@[Доменное имя],
доменное имя устройства@[IP-адрес],
№ телефона@[VoIP-шлюз].

Архитектура сети

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

Терминал

Когда клиент и сервер реализованы в оконечном оборудовании и взаимодействуют непосредственно с пользователем, они называются пользовательским агентским клиентом — User Agent Client (UAC) — и пользовательским агентским сервером — User Agent Server (UAS). Если в устройстве присутствуют и UAC, и UAS, то оно называется пользовательским агентом — User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP. Сервер UAS и клиент UAC имеют возможность непосредственно взаимодействовать с пользователем. Другие клиенты и серверы SIP этого делать не могут.

Прокси-сервер

с сохранением состояний (stateful). Такой сервер хранит в своей памяти все полученные запросы и связанные с ним новые сформированные запросы до окончания транзакции.
без сохранения состояний(stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Прокси может указать пользователю в ответ на первый запрос, на необходимость информации для аутентификации - как минимум логина (ответ 407 Proxy authentification required).

Сервер B2BUA

Управление звонками (биллинг, перевод звонка, автоматическое разъединение и т. д.)
Сопряжение разных сетей (в частности, для адаптации разных диалектов протокола, зависимых от производителей)
Сокрытие структуры сети (частные адреса, сетевая топология и т. п.)

Довольно часто B2BUA является частью медиа-шлюза для того, чтобы полностью контролировать медиа-потоки в рамках сессии. Сигнальный шлюз, являющийся частью пограничного контроллера соединений/сеансов — наглядный пример применения B2BUA.

Сервер переадресации

Сервер регистрации (регистратор)

Сервер определения местоположения пользователей

Пользователь может перемещаться в пределах разных сетей, кроме того, подлинный адрес пользователя может быть и не известным, даже если его номер известен. Это актуально, в частности для услуги переносимости номера (LNP/MNP). Для решения таких задач существует механизм определения местоположения пользователя при помощи сторонних средств, не имеющих прямого отношения к элементам SIP-сети. Для этого используется сервер определения местоположения (англ. Location Server), который хранит текущий адрес пользователя и представляет собой регулярно обновляемую базу данных адресной информации Пользователь, которому нужна адресная информация другого пользователя для установления соединения не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов LDAP, RWHOIS, ENUM, RADIUS или других протоколов.

Пример запроса INVITE:

Запросы

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

INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.
ACK — Подтверждает приём ответа на запрос INVITE.
BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
OPTIONS — Запрашивает информацию о функциональных возможностях сервера.

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

Ответы на запросы

Алгоритмы установления соединения

Протокол SIP является управляющим протоколом для установления, модификации и разрыва соединения, ориентированного на передачу потоковых данных. Параметры передачи медиа-потоков описываются в протоколе SIP посредством SDP (протокол описания сессии). Потоковые медиа-данные могут передаваться различными средствами, среди которых наиболее популярны транспортные протоколы RTP и RTCP.

Протокол SIP определяет 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Сценарии отличаются по тому, как осуществляется поиск и приглашение вызываемого пользователя. Основные алгоритмы установления соединения описаны в RFC 3665.

Пример сценария установления соединения, с участием SIP сервера переадресации и SIP Proxy

Пример сценария установления соединения с участием сервера B2BUA

SIP-T и SIP-I

Сравнение с H.323

SIP пригоден для чтения человеком и структурирован в отношении запросов и откликов. Сторонники SIP также заявляют о нём как о более простом, по сравнению с H.323. Однако некоторые склонны считать, что, в то время как первоначально целью SIP была простота, в своём сегодняшнем виде он стал так же сложен, как и H.323. Другие считают, что SIP — протокол без состояний, который тем самым даёт возможность легко реализовать восстановление при отказе и другие возможности, которые затруднены в протоколах с состояниями, таких как H.323. SIP и H.323 не ограничены голосовой связью, они могут обслуживать любой сеанс связи, от голосового до видеосеанса или приложений будущего.

Безопасность

Читайте также: