Sip update что это

Андрей Погребенник

Всё, что вы хотели знать о протоколе SIP

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

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

Как вы уже знаете, протокол SIP не используется для описания параметров сеанса, таких как вид информации (речь, видео и т. д.), кодек или частота дискретизации. Вместо этого тело сообщения SIP содержит характеристики сеанса, описанные с помощью специального протокола описания сеанса SDP (Session Description Protocol) или (теоретически) другого протокола, выполняющего те же функции. Роль протокола SDP в сети SIP аналогична роли протокола H.245 в сетях H.323. Возможность отделения функций управления установлением сеанса от процесса согласования характеристик сеанса – очень важное свойство протокола SIP, позволяющее использовать для установления сеанса вспомогательный протокол любого типа.

SDP – это протокол описания параметров сеанса для передачи потоковых данных. Своё первое применение он нашёл в качестве средства анонсирования информации о мультимедийных конференциях в экспериментальной академической сети Mbone (Multicast backbone). Первое описание протокола было опубликовано Инженерной проблемной группой Интернета (IETF) как RFC 2327 в апреле 1998 года, а на сегодняшний день актуален RFC 4566.

Любая реализация протокола SIP обязана поддерживать и SDP. Для договора о характере сеанса SIP использует модель предложения и ответа (offer/answer model). Один агент пользователя (UA) посылает описание сеанса, в котором предлагает желаемый способ коммуникации (аудио, видео, игра) и соответствующие типы кодека (кодер/декодер), а также адреса для принятия определённого вида основной информации (медиа). Другой UA в ответе перечисляет, какие из предложенных средств коммуникации приемлемы, и приводит адреса, на которых будут приниматься эти приемлемые виды информации. В процессе сеанса, используя ту же модель, UA может менять договорённые параметры.

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

0=CiscoSystemsSIP-GWUserAgent 762 3453 IN IP4 10.15.1.6

m=audio 16952 RTP/AVP 18 100

В таблице 1 дано пояснение каждой строки. Каждая строка является обязательной, если не указано обратное.

Таблица 1. Список типичных полей SDP в их правильном порядке

Используемая версия протокола SDP

0=CiscoSystemsSIP-GWUserAgent 762 3453 IN IP4 10.15.1.6

Информация об инициаторе вызова, включая тип агента UA, тип сети и контактное имя

Информация о типе среды – используемом типе протокола и адресе соединения. Под адресом соединения понимается адрес отправляющего агента UA

Время начала и остановки сеанса

m=audio 16952 RTP/AVP 18 100

Описание медиа-потока: тип среды и транспортный порт (16952), которые будут использоваться для вызова. Всё, что следует ниже, касается только этого медиа-потока

Необязательные атрибуты медиа-потока. В данном случае одним из таких атрибутов является кодек (G729)

Описание сеанса для одновременной передачи голоса и видео может выглядеть следующим образом:

o=alice 2890844526 2890844526 IN IP4 10.1.3.33

m=audio 49172 RTP/AVP 0

m=video 51172 RTP/AVP 31 34

Обратите внимание: первые четыре строки являются описанием уровня сеанса, а строки a= – описаниями уровня медиа-носителя. При этом каждая новая m-строка обозначает начало нового медиа-потока.

Использование SDP в SIP

Основным документом, нормирующим использование SDP в SIP, является RFC 3264. Упомянем его основные положения:

Протоколы RTP (Real-time Transport Protocol) и RTCP (RTP Control Protocol)

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

Протокол TCP в таких приложениях не приемлем ввиду своих свойств. TCP не гарантирует время доставки, а повторно переданные пакеты, которые в приложениях реального времени уже не несут актуальной информации, ещё и сужают полосу актуальной передачи, что увеличивает неравномерность передачи потока. Другой широко используемый протокол транспортного уровня, UDP, не имеет этих двух ограничений, но и он не предоставляет критически необходимой для приложений реального времени информации о синхронизации. UDP сам по себе не предоставляет каких-либо инструментов общего назначения для создания приложений реального времени. Несмотря на то что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает определение единого протокола весьма желательным. Потому в 1996 году в RFC 1889 были представлены протоколы RTP и RTCP. Актуальные на сегодняшний день версии описаны в RFC 3550.

Это протокол транспортного уровня, который работает поверх UDP (cм. рис. 1) и гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это означает, что данные могут быть воспроизведены в реальном времени.

Рисунок 1. Место RTP в стеке протоколов TCP/IP

Протокол RTP предусматривает такие функции:

Таблица 2. Типы полезной нагрузки аудио и видео в RTP

Частота дискретизации, Гц

ITU G.711 PCM µ-Law Audio 64 Kbps

CELP Audio 4.8 Kbps

ITU G721 ADPCM Audio 32 Kbps

European GSM Audio 13 Kbps

DVI ADPCM Audio 32 Kbps

Experimental LPC Audio

ITU G.711 PCM A-Law Audio 64 Kbps

Linear 16-bit Audio 705.6 Kbps

Linear 16-bit Stereo Audio 1411.2 Kbps

MPEG-I or MPEG-II Audio Only

ITU G.728 Audio 16 Kbps

MPEG-I and MPEG-II Video

MPEG-II transport stream Video

Замечу, что RTP сам по себе не обеспечивает качества услуг (QoS) и не гарантирует корректную доставку данных.

Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Забегая вперёд, скажу, что пакет RTCP имеет следующую структуру: начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину согласно типу пакета.

В соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP).

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

Не всегда все участники конференции имеют возможность получать мультимедийные данные в одинаковом формате. Если новая система хочет принять участие в сеансе, но её канал не обладает достаточной пропускной способностью, помочь может специальное устройство, реализующее механизм трансляции RTP и называемое микшером. Микшер повторно синхронизирует входящие звуковые пакеты от одного или более источников для восстановления исходных интервалов голосового потока (см. врезку «Качество голосовой связи в среде IP»), микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи одному или более получателям. Чтобы в приёмных узлах можно было иметь правильную индикацию источника сообщений, заголовок RTP включает средства опознавания источников, участвовавших в формировании смешанного пакета. Также микшер может изменять формат данных.

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

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

Протоколу RTP не требуется стандартный или статический TCP- или UDP-порт для связи. RFC 3551 указывает, что RTP-подключения осуществляются через UDP-порт с четным номером, а порт с нечётным номером, следующим в порядке возрастания, используется протоколом RTCP. Хотя не существует стандартных назначений диапазона портов для RTP/RTCP, обычно используется диапазон 16384-32767.

Это протокол, предоставляющий приложениям, работающим по протоколу RTP, механизмы обмена управляющей информацией, подтверждения доставки RTP-пакетов, мониторинга состояния сети и реагирования на изменения в ней. Например, получив информацию о повышении интенсивности трафика в сети и уменьшении выделенной приложению полосы пропускания, приложение может отреагировать и умерить свои требования к полосе пропускания за счёт некоторой потери качества. После снижения нагрузки в сети приложение может восстановить исходную полосу пропускания и продолжить работу с тем качеством, какое оно предоставляло вначале. Сообщение RTCP несёт такую информацию, как число переданных и полученных пакетов, число потерянных пакетов, величины задержки и вариации задержки (джитера). Последний термин нуждается в дополнительном разъяснении. Вариация задержки – это величина, характеризующая неравномерность передачи, выражающуюся в наличии переменной задержки между прибытием и иногда – в нарушении порядка доставки пакетов.

Одностороннюю же задержку образуют такие составляющие, как: задержки, вносимые процессами кодирования и декодирования, задержки пакетизации, формирования очереди, задержки при передаче в канал, задержки распространения по каналу и латентность буфера сглаживания вариации задержки (деджитер-буфер, этот механизм описан во врезке «Качество голосовой связи в среде IP»). При этом некоторые составляющие постоянные, а некоторые – переменные. Односторонняя задержка в диапазоне 0-150 миллисекунд, согласно рекомендации ITU-T G.114, является допустимой для большинства приложений. Задержка величиной 150-400 мс ещё не оказывает сильного влияния на качество воспроизведения речи и приемлема для большинства приложений. Что касается количества потерянных пакетов, то для голосовых звонков этот показатель не должен превышать 1%, но при передаче факсимильных сообщений потеря пакетов не допустима вообще. Наконец, допустимые значения вариации задержки – до 30 мс.

Можно выделить три функции протокола RTCP:

Чтобы обеспечить выполнение всех этих функций, участники сеанса обмениваются специальными управляющими сообщениями протокола RTCP. Кратко опишу кратко пять их типов.

Пакеты отчёта RTCP, обеспечивающие обратную связь – оценку качества приёма, могут принимать одну из двух форм в зависимости от того, является получатель также и отправителем или нет: Report (RR) или Sender Report (SR).

Отчёт отправителя – Receiver Report (RR). Эти пакеты создаются участниками сеанса, не являющимися активными отправителями. Они содержат такую информацию, как подтверждение получения пакетов, данные о рассинхронизации входящих пакетов и задержку, связанную с подтверждением приёма.

Отчёт получателя – Sender Report (SR). SR передаётся, если участник сеанса посылал любые пакеты данных в течение интервала, начиная с передачи последнего или предыдущего отчёта, в противном случае передается RR. Единственное отличие между формами отчёта отправителя и отчёта получателя, помимо кода типа пакета, – это то, что отчёт отправителя включает 20-байтовый раздел информации отправителя для использования активными отправителями. Этот раздел включает данные о внутренней аудиовизуальной синхронизации и количестве отправленных пакетов и байтов.

Пакет описания источника – Source Description Items (SDES). Пакеты этого типа содержат информацию об участниках сеанса.

Пакет завершения связи – BYE. Это «прощальный» пакет, с помощью которого пользователь отключается от сеанса.

Пакет, определяемый приложением – APP. Пакет APP предназначен для экспериментального использования при разработке новых приложений и программных средств без регистрации новой величины типа пакета. Пакеты APP с нераспознанными именами должны игнорироваться. После испытания, если оправдано более широкое использование, рекомендуется, чтобы каждый пакет APP был переопределён без полей подтипа и имени и зарегистрирован в IANA с выделением для него нового типа пакета RTCP. В пакет входят сведения о специфических функциях приложения.

Заметим, что и здесь есть новые разработки: так, в RFC 3611 описан тип пакетов Extended Report (XR), который предусматривает сбор статистической информации по двадцати параметрам сетей передачи данных и качеству голоса.

Реализация расширенных услуг на базе протокола SIP

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

Удержание вызова и трёхсторонняя конференция

На рис. 2 показаны сразу две важные услуги: удержание вызова и трёхсторонняя конференция.

Рисунок 2. Трёхсторонняя конференция через агента Bob

Перевод на удержание вызова осуществляется отправкой удерживающим пользовательским агентом сообщения re-INVITE (напомню, что от простого INVITE его отличает наличие тега в поле To и возросший порядковый номер в CSeq), запрашивающего в SDP переключение режима передачи медиа-потока из режима одновременной отправки и приёма «sendrecv» на режим отправки «sendonly». В «200 OK» от второй стороны будет соответственно «recvonly» (только приём).

После установления сессии #2 первые два пользовательских агента проводят ещё один цикл пересогласования для перехода в режим «sendrecv».

С этого момента конференцию можно считать установленной.

Следующей расширенной услугой SIP-телефонии, на которой мы остановимся, является «параллельный вызов» (Call Forking). Суть заключается в том, что прокси-сервер «размножает» входящий INVITE на несколько пользовательских агентов (см. рис. 3).

Рисунок 3. Параллельный вызов

Например пользователь может захотеть, чтобы входящий вызов посылался на его домашний, а затем мобильный телефон. Разветвление может быть как последовательным, так и параллельным. Значения параметра branch поля заголовка Via уникальны для каждого исходящего INVITE. В ответ может прийти несколько «200 OK»-ответов на один и тот же INVITE, которые имеют один и тот же Call-ID, один и тот же параметр tag в заголовке From, но отличаются параметром tag в заголовке To. Все эти диалоги будут соответствовать одному и тому же звонку. Сеанс устанавливается с первым агентом, ответившим «200 OK», а остальным агентам для завершения диалога отправляется запрос CANCEL (если диалог находится в ранней стадии установления), или же ACK и BYE, если диалог уже установлен.

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

Для осуществления перевода вызова используется метод REFER (RFC 3515) – запрос от одного UA для приглашения к сеансу другого пользовательского агента. Обязательный заголовок Refer-To указывает цель запроса – UA, с которым необходимо установить связь. Запрос REFER может содержать также опциональный заголовок Referred-By, указывающий на инициатора запроса.

Адресат запроса (обычно после осуществления аутентификации и авторизации) решает, принимать ли REFER, и в случае успеха немедленно отвечает «202 Accepted». Промежуточные ответы в REFER-транзакции не допустимы. На рис. 4 показан поток сообщений для случая перевода вызова.

Рисунок 4. Перевод вызова

Ниже показано содержимое сообщений REFER и следующего за ним INVITE (здесь и далее заголовки с интересующей нас информацией выделены красным цветом):

REFER sip:alice@atlanta.com SIP/2.0

Via: SIP/2.0/UDP swp34.biloxi.com;branch=z9hG4bKna9

Allow: INVITE, ACK, CANCEL, OPTIONS,

BYE, REFER, NOTIFY, UPDATE

INVITE sip:carol@chicago.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9VHJ23J41

Информация о присутствии

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

Данный механизм реализуется с помощью сервера присутствия (Presence Server). Физически он обычно совмещён с сервером регистрации или одним из других элементов сети SIP.

Служба присутствия включает два различных набора клиентов. Один набор клиентов, называемых presentities (например, производители информации), предоставляет информацию о присутствии, которая распределяется и сохраняется. Другой набор клиентов, именуемых watchers (например, потребители информации), получает данные о присутствии от соответствующей службы. При реализации эти клиенты обычно объединяются, однако обсуждаются отдельно.

Метод SUBSCRIBE (RFC 3265) используется для того, чтобы запросить асинхронное уведомление о наступлении события или группы событий на удалённом узле. В запросе присутствует заголовок Expires, обозначающий длительность подписки на уведомления. Запросы должны иметь только одно значение в заголовке Event, т.е. подписку запрашивать можно только на одно событие за один раз. Собственно уведомление подписчика об изменениях в состоянии, на которые тот подписан, происходит при помощи запроса NOTIFY (также RFC 3265).

Рисунок 5. Услуга присутствия

На рис. 5 показан процесс подписки на информацию о регистрации. Рассмотрим вид запросов SUBSCRIBE и NOTIFY:

SUBSCRIBE sip:alice@atlanta.com SIP/2.0

Via: SIP/2.0/TCP app_IM.atlanta.com;branch=z9hG4bKnashds7

From: sip:app_IM.atlanta.com ;tag=123aa9

CSeq: 9887 SUBSCRIBE

Ответы 2xx на запрос SUBSCRIBE показывают, что подписка принята и что запрос NOTIFY будет отправлен немедленно при наступлении события. Заголовок же Event запроса NOTIFY должен совпадать с заголовком Event из SUBSCRIBE.

NOTIFY sip:app_IM.atlanta.com SIP/2.0

Via: SIP/2.0/TCP server1.atlanta.com;branch=z9hG4bKnasaii

From: sip:alice@atlanta.com ;tag=xyzygg

To: sip:app_IM.atlanta.com ;tag=123aa9

В базовой для SIP рекомендации RFC 3261 определено 6 типов запросов: REGISTER, INVITE, ACK, CANCEL, BYE и OPTIONS. Ниже мы рассмотрим OPTIONS и остановимся на некоторых других методах SIP, применяемых при реализации дополнительных услуг.

Метод OPTIONS даёт возможность узнать у UA, какие кодеки, методы, типы контента, расширения им поддерживаются, а также известные агенту контакты, ещё до попытки установления диалога. Рассмотрим пример такого взаимодействия.

OPTIONS sip:bob@192.168.10.20 SIP/2.0

Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK77i832k9 ;received=10.1.3.33

From: Alice ;tag=1928301774

CSeq: 22756 OPTIONS

Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE

Accept: application/sdp, application/pidf-xml

Целевой UA отвечает на запрос OPTIONS так, как бы он ответил на INVITE (откликом класса 2хх), но с включением вышеупомянутой информации в заголовки Allow, Accept, Accept-Encoding, Accept-Language, Supported и (когда речь идёт о списке кодеков) SDP-часть. Тело SDP здесь не показано для экономии места:

Via: SIP/2.0/TCP sip:alice@atlanta.com;branch=z9hG4bK77i832k9;received=10.1.3.33

To: Bob ; tag=a6c85e3

From: Alice ;tag=1928301774

CSeq: 22756 OPTIONS

Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, MESSAGE

Accept: application/sdp, text/plain, image/jpeg

Accept-language: en, fr

Метод MESSAGE(RFC 3428) используется для передачи мгновенных сообщений между пользователями. Содержимое сообщения помещается в тело приложения MIME. Размер тела сообщения не должен превышать 1300 байт. Метод MESSAGE примечателен тем, что он не образует диалоги. Ответ «200 OK» на MESSAGE означает, что сообщение было доставлено. Ответы 4xx и 5xx показывают, что сообщение не могло быть успешно доставлено, а ответы группы 6xx – что сообщение было успешно доставлено, но отвергнуто.

Метод INFO (RFC 2976) применяется для передачи управляющей информации, относящейся к сеансу и генерируемой в процессе сеанса, как то: сигнальных сообщений ТфОП между шлюзами в течение вызова, цифр тонового набора (DTMF), информации об уровне сигнала в беспроводной сети, состоянии баланса, изображений и т. д. Если INFO не может быть принят, UA шлёт в ответ «487 Request Terminated».

Наконец, метод UPDATE (RFC 3311) позволяет агенту изменять параметры сеанса, например, используемый кодек. UPDATE может быть использован после того, как принят окончательный ответ на INVITE, однако использование re-INVITE предпочтительно.

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

Качество голосовой связи в среде IP

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

Источник

• ← Алишер усманов за что был осужден
• Как называются деньги в перу →