sip rtp что это

IP-телефония: от медных проводов до цифровой обработки сигнала

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.

1. Базовые понятия телефонии

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

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.

По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто — на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.

Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента — с помощью модуля DAA (Direct Access Arrangement).

Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.

Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) — телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия — POTS (Plain Old Telephone Service) — простая старая телефонная система.

С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг — дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.

Skype — самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго — не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.

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

Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.

2. Описание связки SIP/SDP/RTP-протоколов

SIP (Session Initiation Protocol) — протокол установления сессии (не только телефонной) — это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.

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

RTP (Real-time Transport Protocol) — протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.

Общая структура SIP-пакетов:

Вот пример двух SIP-пакетов для одной частой процедуры — установления вызова:

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Слева изображено содержимое пакета SIP INVITE, справа — ответ на него — SIP 200 OK.

Основные поля выделены рамками:

SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:

RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https://en.wikipedia.org/wiki/RTP_audio_video_profile.

Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).

Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.

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

Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.

Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток — если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT’ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.

После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.

3. Передача информации о нажатых кнопках

Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) — удержание вызова, перевод, голосовая почта и т.п. — которые реагируют на определенные сочетания нажатых кнопок.

Так, в обычной телефонной линии есть два способа набора номера:

Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс — разрыв линии, 40 мс — замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.

В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:

Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков — это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).

Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.

4. Передача голоса и факсов

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

Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.

Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.

Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.

Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.

Основные достоинства T.38 — снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Процедура передачи факса в режиме T.38 выглядит следующим образом:

Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.

Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы — David Hanes и Gonzalo Salgueiro.

5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования

С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос — качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС — цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.

Основные процедуры, улучшающие качество звука:

VAD (Voice activity detector) — процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).

Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.

Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).

Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

CNG (сomfort noise generation) — процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.

PLC (packet loss concealment) — процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Простейший способ эмуляции потери пакетов (в Linux) — воспользоваться утилитой tc из пакета iproute с модулем netem. Она выполняет шейпинг только исходящего трафика.

Пример запуска эмуляции сети с потерей 50% пакетов:

Jitter buffer — процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):

LEC (Line Echo Canceller) — процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Эхо может возникать по нескольким причинам:

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

Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books.

На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.

[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad.

Источник

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что этоВсё, что вы хотели знать о протоколе SIP

Архив номеров / 2007 / Выпуск №8 (57) / Всё, что вы хотели знать о протоколе SIP

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что этоАндрей Погребенник

Всё, что вы хотели знать о протоколе 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) и гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это означает, что данные могут быть воспроизведены в реальном времени.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Рисунок 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 показаны сразу две важные услуги: удержание вызова и трёхсторонняя конференция.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

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

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

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

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

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

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Рисунок 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 показан поток сообщений для случая перевода вызова.

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Рисунок 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).

sip rtp что это. Смотреть фото sip rtp что это. Смотреть картинку sip rtp что это. Картинка про sip rtp что это. Фото sip rtp что это

Рисунок 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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Рубрика: Сети / Сети