Какое сообщение sip использует uac для завершения установленного сеанса

Обновлено: 07.07.2024

Можно смело сказать, что лето на Урале еще не начиналось - идет эдакая затяжная весна (и вероятен плавный переход в осень). Но кто о чем, а "домашние сети" о грозах. Каждое третье письмо - о них, вернее о средствах защиты от этого природного явления.

Однако время итогов еще не пришло. Вернее - пока нет ничего неожиданного, ранее не описанного. Классика отрасли - оптика спасает, защита - как может защищает, а коммутаторы без нее - горят массово и бесповоротно.

Разве что можно особо выделить эффективность дополнительных средств защиты на базе ферромагнитных сердечников (смотреть тут внизу страницы). Практика показала, что такое нехитрое устройство (получившее уже прозвище "бочка") мало уступает по эффективности обычной диодно-сапрессорной грозозащите, а их совместное использование так и вообще приближает качество к заветным (но недостижимым) 100%.

Увы, сердечники очень не дешевы (более $10 пара), да и их намотка довольно трудоемка. Поэтому массовое распространение им, скорее всего, не грозит.

Небольшая коллекция грозоужастиков:

Эти защиты (классический АРС) стояли с двух сторон одной линии. После грозы в них не осталось ни одного целого элемента. Даже текстолит выгорел.

Несмотря на лето, время отпусков и снижения объемов продаж, интересно и на другом краю провайдерского рынка. Так, в Екатеринбурге интрига прихода на рынок новой "дочки" телефонного монополиста начала приобретать реальные черты. Время презентаций еще не настало (для них есть осень), однако какие-то выводы сделать уже можно.

Напомню предысторию. До недавнего времени основным трансгородским транспортным средством была сеть "ОАО СЦК", построенная в основном на инфраструктуре телефонного монополиста "Уралтелеком". При этом конечных пользователей мог подключить через сеть ADSL любой оператор, которому "ОАО СЦК" предоставляло в аренду транспорт на равных и публичных условиях.

Т.е. ADSL использовалась именно как транспортная среда, стоил он дорого (около $120 в месяц только абонентской платы, и подключение в районе $800). Тем не менее провайдеры Екатеринбурга в острой конкуренции между собой подключили на настоящий момент около 1200 точек.

Однако время идет. Вместо Уралтелекома появился филиал Уралсвязьинформа, который объявил о планах самостоятельной работы по АДСЛ с конечным пользователем (через дочку "Уралком"). Правда намерения целых два месяца не могли получить развития в виде коммерческого предложения. Только на прошлой неделе оно появилось, но по нему условия для провайдеров стали, пожалуй, только хуже.

Снижение абонентской платы с лихвой компенсируется стоимостью транзитного трафика, которая возросла (от тарифов "ОАО СЦК") в 10 (!) раз, и составляет порядка 0,7 - 1,1 рубля за мегабайт. Повторюсь, это именно транзитный трафик, а не интернетный, который каждый провайдер покупает отдельно. Видимо "Уралком" оставляет "запас" рентабельности для своего выхода на рынок конечных пользователей (для которого, вероятно, сейчас еще просто не отстроен механизм продаж).

В то же время сразу несколько альтернативных операторов успели построить свои магистральные сети масштаба города (сотни километров оптоволокна), и относительно успешно их продают конечным пользователям и небольшим субпровайдерам (как правило "домашним сетям"). Так что можно сказать, что роль ADSL как магистрального транспорта уже сыграна, и новое его позиционирование должно быть сделано на домашнего пользователя. Это значит, что конкуренция домашним сетям усилится, а транзитная сеть для них должна в недалекой перспективе стать оптической (для сохранения качественного отрыва).

Технически все выглядит довольно красиво - кольцо из трех узлов АТМ (STM4), связанное с гигабитной сетью metroEthernet. Есть подключение к основным магистральным операторам, узел в трамвайно-троллейбусном управлении (а это крупнейший владелец опор для недорогой прокладки оптики), core из двух узлов связанных линией 10G. Кроме этого оборудован мощный (конечно, для Екатеринбурга) дата-центр (его фотографии ниже):

Кроме того, есть примерно полдюжины "выносов" в разных районах города, от которых можно проложить "волокно до стола" чуть не в любой офис. Последнее, кстати, выгодно отличает "GigaLine" от MSK-IX (структура, тарифы).

Подключение на существующем узле на скорости 10Мб стоит $2350, и абонентская плата $175 в месяц. На 100Мб - соответственно 4300/245. Если нужно проложить последнюю милю оптикой - то это еще плюс $1100. За отдельную плату доступны приоритеты, транзитные виланы, и прочие вкусности MAN в его толковании Cisco.

Дорого это или дешево? С одной стороны, кажется что это астрономически много. Но с другой - проложить "свою" оптику через полгорода встанет в несколько раз дороже. Да и платить за аренду канализации (опор) то же придется не мало.

Тут уж пусть рассудит рынок - но наблюдать, сможет ли "ОАО СЦК" продать ТСПД в Екатеринбурге будет очень интересно. Для "домашних сетей" польза - еще один вариант подключения к магистрали им явно не повредит.

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

Так что думаю, что осенью скучать не придется. ;-)

Немного ссылок на полезные ресурсы и документы:

Статья под броским заголовком - ФАС защитила связистов От Леонида Реймана. Цитата - федеральная антимонопольная служба (ФАС) "завернула" проект постановления Министерства информационных технологий и связи, согласно которому число лицензируемых услуг связи могло бы вырасти вдвое - к удовольствию чиновников и монополиста дальней связи "Ростелекома". Министерство утверждает, что ФАС неправильно его поняла, и собирается настаивать на своем. Рынок замер в ожидании развязки.

КОНЦЕПЦИЯ информатизации органов самоуправления города Ставрополя на 2003 - 2006 годы Полезный документ, на основе которого оператор связи может предложить свое решения муниципальным органам власти.

Тихое жужжание кулеров (ссылку прислал Zoro). Статья о вентиляторах - может пригодиться любителям самосборных рутеров на базе ПС.

Беспроводные сети и прочее Ужасы по построению радиолинка в военной части.

Ссылка на отчет о финансовом состоянии "Комкор-ТВ" (благо, это открытая компания). Очень интересно для анализа, но к сожалению, все на английском языке.
Несколько интересных цифр, грубо выдернутых из контеста: убытки первые девять месяцев 2003 года = $3,440,000 (очевидно, большие расходы на строительство). Надеются получить небольшой плюс в первом квартале 2004. Построить сеть на 50.000 квартир стоит $2.000.000. ARPU пользователя интернет $25, а кабельных каналов - всего $11.

Бесплатная биллинговая система для ВПН сетей. Работает только под LINUX-ом. Практически все нужные и ненужные функции, открытый исходный код, возможность легкого изменения под свои нужды. Подойдет для использования средним ISP (количество пользователей до 5000), в домашних сетях, организациях и т.п.

Забавное объяснение чему равен 1U и подарок админу на день рождения:

Узел называется (вроде бы) кулак обезьяны.

VoIP для начинающих. Часть вторая: SIP

Автор данного текста Эдуард Афонцев, Екатеринбург.

Одним из наиболее перспективных протоколов сигнализации в современных приложениях IP телефонии является SIP. Расшифровывается как Session Initiation Protocol, то есть протокол управления (инициализации, модификации и прерывания) коммуникационными сессиями с одним или несколькими участниками. Определение сессии включает в себя: интернет мультимедиа конференции, интернет телефонные звонки и прочее.

Компоненты SIP делятся на два класса: клиенты и серверы.

User agent (UA) - клиентское приложение, которое посылает и принимает SIP запросы. В свою очередь состоит из UAC (user agent client - клиент) и UAS (user agent server - сервер). UAC представляет собой инициатора SIP запросов к UAS.

Только UA непосредственно взаимодействует с клиентом. Все остальные компоненты SIP сети этого не могут, они взаимодействуют только с UA или между собой.

Proxy server - принимает SIP запросы от UAC (UA) и инициирует новые запросы в сторону запрашиваемого абонента UAS (UA). Это может быть поиск и вызов абонента, маршрутизация запроса и т.п. Практически это SIP роутер (маршрутизатор),который перенаправляет запросы сигнализации (call signalling) в реальном времени.

Registrar - сервер определения местоположения объектов. Регистрирует клиентов (адреса, по которым они достижимы).

Часто Registrar комбинируется с proxy, но это отдельный логический процесс.

Redirect server - сервер переадресации. Предназначен для определения текущего адреса вызываемого абонента. Алгоритм простой: вызывающий абонент обращается к redirect серверу с известным ему адресом вызываемого пользователя, а redirect переадресует вызов на текущий адрес. В процессе данной деятельности redirect server взаимодействует с сервером registrar. Redirect только сообщает адрес вызываемого абонента или proxy сервера.

Redirect сервер не терминирует звонки.

В результате SIP архитектура выглядит следующим образом:

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

IP адреса серверов могут быть внесены в конфигурацию клиентского приложения. Это менее гибкий, но более надежный способ для статичных топологий.
Для поиска сервера регистрации (Registrar) может использоваться мультикастовый запрос.
Для поиска прокси сервера (Proxy) и сервера переадресации (Redirect) может использоваться специальный запрос к серверу имен (DNS). User agent посылает SRV запрос DNS серверу, а тот в случае наличия в своей базе нужной информации возвращает имя (Hostname) запрашиваемого сервера и порт (Port) для взаимодействия. По данному имени User agent может выяснить требуемый IP адрес.

Адресация.

Для взаимодействия между собой приложения используют SIP адрес, очень напоминающий адрес электронной почты (SIP URL) . Адреса SIP имеют только UA. Все остальные компоненты (Proxy, Redirect, Registrar) идентифицируются только IP адресами и номерами портов (например, по умолчанию SIP сервер использует 5060 порт).

Синтаксис SIP адреса следующий:

sip: userid@hostname
где userid - username или e.164 адрес (телефонный номер), hostname - домен, хост или IP адрес.

Кроме того, в SIP адрес могут входить дополнительные параметры (пароли, номера портов и тому подобное).

Приведем примеры SIP адресов:

В свою очередь Start line запроса включает в себя Method, Request-URI, SIP version.

REGISTER - регистрация на Registrar сервере,
INVITE - приглашение к началу сеанса связи,
ACK - подтверждение приема,
BYE - завершение сеанса связи,
INFO - информация,
OPTIONS - дополнительные опции,
и другие.

Ответы делятся на две группы: информационные и финальные.

Информационные ответы содержат в себе ознакомительные данные. Например:
Trying, ringing.

Финальные обозначают завершение каких-либо транзакций. Например:
Ok. Начало любого SIP ответа (start line) состоит из SIP version, Status Code и Reason Phrase, например:
SIP 2.0 Trying

Сценарии SIP взаимодействий.

UA-UA. Взаимодействие непосредственно между клиентскими приложениями (UA) без участия серверов. Для этого вызывающий UA должен знать текущий адрес вызываемого абонента.

Во время вызова происходит следующий диалог:
вызывающий UA - приглашаю к разговору (INVITE).
вызываемый UA - выдаю звонок (RINGING), трубка поднята, можно начинать разговор (OK)
вызывающий UA - подтверждаю начало разговора (ACK)

Далее идет разговор (RTP/RTCP между клиентскими приложениями).

Если один из участников решает прекратить связь, то:
вызываемый UA - завершаем звонок (BYE)
вызываемый UA - хорошо, завершаем (OK).

Звонки c участием Proxy сервера (или нескольких серверов).

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

Фаза вызова (звонка):

Сначала вызывающий абонент (UA) обращается к Proxy с вызовом на постоянный адрес требуемого абонента - INVITE. Далее Proxy выясняет у REGISTRAR сервера текущий адрес вызываемого и от своего имени посылает к нему запрос на установление связи (INVITE). Ответы (RINGING, OK) и подтверждение (ACK) так же проходят через Proxy.

Разговорная фаза (RTP, RTCP) проходит только между клиентскими приложениями (UA) и не задействует прокси.

Фаза завершения связи (разрыва соединения):

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

Обычно сервер регистрации и прокси сервер объединяют в одно приложение и в результате получают комбинированный SIP сервер доступа к VoIP сети.

Взаимодействие с участием Redirect сервера.

В данном случае UA в итоге самостоятельно установит соединение, а сервер переадресации только преобразует постоянный адрес в текущий. Текущий адрес знать не обязательно, это задача сервера переадресации.

Фаза вызова (звонка):

Сначала вызывающий абонент (UA) обращается к REDIRECT с вызовом на постоянный адрес требуемого абонента - INVITE. Далее REDIRECT выясняет у REGISTRAR сервера текущий адрес вызываемого и возвращает его вызывающему.

Далее вызывающий абонент взаимодействует с вызываемым непосредственно и без участия REDIRECT сервера.

Фаза завершения связи (разрыва соединения):

Заключение.

Как видно даже из такого неполного описания, протокол SIP позволяет строить гибкие схемы IP телефонии, предоставляя клиентам расширенные сервисы управления соединениями.

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

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

Чтобы установить сеанс, SIP обычно должен использовать следующие протоколы:

DNS: разрешить имя хоста или домена;

SDP (протокол описания сеанса): описание и согласование параметров мультимедийного сеанса;

RTP (транспортный протокол реального времени): передача данных в реальном времени (аудио- и видеопакеты) к конечной точке;

RSVP (протокол резервирования ресурсов): зарезервируйте требуемую полосу пропускания перед установкой медиа-сеанса;

TLS (протокол безопасного транспортного уровня): на основе этого может быть обеспечена конфиденциальность и целостность SIP;

STUN (простое проникновение UDP в NAT): узнать, есть ли трансляция адресов;

Введение в некоторые термины

Back-to-Back User Agent（B2BUA）: Последовательный пользовательский агент - это логическая сущность, которая принимает запросы и обрабатывает их как сервер пользовательских агентов (UAS). Чтобы определить, как ответить на запрос, он действует как клиент пользовательского агента (UAC) и генерирует запрос. В отличие от прокси-сервера, B2BUA поддерживает состояние диалога и участвует во всех запросах, отправляемых в установленном им диалоге. Поскольку B2BUA - это соединение между UAC и UAS, нет необходимости четко определять его поведение.

User Agent Client(UAC)：Клиент пользовательского агента - это логическая сущность, которая создает новый запрос и затем использует конечный автомат транзакции клиента для отправки запроса. Роль UAC существует только на время транзакции. Другими словами, если программное обеспечение инициирует запрос, это только UAC на время транзакции. Если он впоследствии получает запрос, предполагается, что он является сервером пользовательского агента при обработке этой транзакции.

User Agent Server(UAS)：Сервер пользовательского агента - это логический объект, который генерирует ответы на запросы SIP. Отвечайте на получение, отклонение и перенаправление запросов. Эта роль существует только во время транзакции. Другими словами, если программное обеспечение отвечает на запрос, это UAS во время транзакции. Если он впоследствии сгенерирует запрос, мы будем считать его клиентом пользовательского агента во время транзакции.

User Agent(UA)：Его можно использовать как в качестве клиента пользовательского агента, так и в качестве логической сущности сервера пользовательского агента. Роли UAC и UAS, а также прокси и сервер перенаправления определяются на основе транзакций. Например, когда пользователь инициирует вызов и отправляет начальный запрос INVITE, он действует как UAC; когда он получает запрос BYE от вызываемого, он действует как UAS. Точно так же одно и то же программное обеспечение может действовать как прокси-сервер для одного запроса и сервер перенаправления для следующего запроса. Все агенты, местоположения и серверы регистрации, определенные выше, являются логическими объектами. При реализации они могут быть объединены в одно приложение.

SIP-адресация

SIP-адрес используется для идентификации пользователя или ресурса в сети. Он часто называется SIP URI и имеет формат адреса, аналогичный EMail:

порт не является обязательным, в противном случае используйте значение по умолчанию 5060

SIP запрос：

Request-Line = Method + SP + Request-URI + SP + SIP-Version + CRLF

В RFC определены 6 запросов:

ПРИГЛАШЕНИЕ: указывает, что принимающий пользователь или услуга приглашены присоединиться к сеансу; этот метод также может использоваться для изменения характеристик ранее установленного сеанса; успешный ответ (200 ОК) указывает, что вызываемая сторона желает участвовать в сеансе;

ВАРИАНТ: UA использует это для запроса UAS о его функциях;

BYE: используется для завершения ранее установленного сеанса;

ОТМЕНА: заставить UAC и веб-сервер отменить текущий запрос (например, ПРИГЛАСИТЬ);

РЕГИСТРАЦИЯ: клиент регистрирует информацию о своем текущем местоположении;

SIP ответ：

Status-Line := SIP-Version + SP + Status-Code + SP + Reason-Phrase + CRLF

Заголовок SIP

От: Определите отправителя запроса (обычно AOR отправителя), включая SIP или SIP URI и необязательное отображаемое имя;

Через: Определите путь запроса и адрес, который будет отправлен в ответ;

Контакт: определите SIP или SIPS URI (фактический адрес), по которому США хотят получать новые запросы SIP;

Поддерживается: список всех расширений SIP (RFC3262), поддерживаемых UA;

Требовать: содержит расширения SIP, которые должен поддерживать удаленный UA;

Транзакция и сеанс

Транзакция транзакция

Согласно описанию протокола sip, транзакция состоит из 5 необходимых частей: от, до, параметр ветвления в заголовке Via, call-id и cseq. Эти 5 частей вместе идентифицируют определенную транзакцию. Если какая-либо часть отсутствует, транзакция будет Ошибка установки.

Диалог

Сессия сессия

Это ассоциация между всеми участниками коммуникационного процесса и сбор медиапотоков между ними. Только после успешного согласования носителя можно установить сеанс.

Три разных соединения

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

Диалог: поддержание статуса однорангового узла. В настоящее время диалог запускается только при запросах приглашения и подписки. Его жизненный цикл проходит через непрерывный диалог.

Следующая диаграмма ясно показывает взаимосвязь между ними (RINGING - это ответ 1xx, OK - ответ 2xx):

Вызывающий абонент вызывает номер вызываемого, чтобы установить серию диалогов (Dialogs):

Диалог между UA-A и B2BUA;

Диалог между B2BUA и UA-B;

Эти разговоры составляют звонок (Call), то есть разговор.

Расширенный механизм согласования SIP

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

SIP использует SDP (RFC4566) для описания фактических параметров сеанса мультимедиа, включая: тип мультимедиа, кодирование, скорость передачи данных, а также адреса и номера портов, связанные с сеансом.

SDP включает в себя следующие аспекты:

Название и цель сеанса

Время сеанса жить

Информация СМИ, включенная в беседу, в том числе:

Тип носителя (видео, аудио и т. Д.)

Протокол передачи (RTP / UDP / IP, H.320 и т. Д.)

Формат мультимедиа (видео H.261, видео MPEG и т. Д.)

Многоадресный или удаленный (одноадресный) адрес и порт

Информация, необходимая для получения медиа (адреса, порты, форматы и т. Д.)

Информация об используемой пропускной способности

Надежная контактная информация (Контактная информация)

Описание сеанса SDP состоит из нескольких строк = . Где - символ. - это строка, и ее формат зависит от . Весь протокол чувствителен к регистру. По обе стороны от " " src="https://russianblogs.com/images/601/287b9867d842d8b56e4a022dc5823cc9.JPEG" />

Media Type

Примеры файлов sdp для сеанса VLC на уровне мультимедиа, воспроизводящего звук g711:

m=audio 8888 RTP/AVP 0

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:

Стартовая строка содержит метод, 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-сервере.

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