Добрый день!

Итого: система мониторинга представляет собой комплекс, подключаемый в неинтрузивном режиме к n-ному количеству 10-гигабитных линков Ethernet, который непрерывно “наблюдает” за передачей всех присутствующих в трафике видео-потоков RTP и проводит измерения с определённым интервалом времени, чтобы потом сохранить их в базу. По данным из базы регулярно строятся отчёты для всех камер.

И что тут сложного?

В процессе поиска решения сразу зафиксировали несколько проблем:

• Неинтрузивное подключение. Система мониторинга подключается к уже работающим каналам, в которых большинство соединений (по RTSP) уже установлены, сервер и клиент уже знают, по каким портам происходит обмен, но нам это заранее неизвестно. Well-known порт есть только для протокола RTSP, а вот UDP-потоки могут идти по произвольным портам (к тому же, оказалось, что нередко они нарушают требование SHOULD чётности/нечётности портов, см. rfc3550). Как определить, что тот или иной пакет от какого-то IP-адреса принадлежит к видео-потоку? Например, протокол BitTorrent ведёт себя аналогично - на этапе установки соединения клиент и сервер договариваются о портах, а потом весь UDP-трафик выглядит как “просто битовый поток”.
• В подключенных линках могут быть не только видео-потоки. Могут быть и HTTP, и BitTorrent, и SSH, и любые другие протоколы, которыми мы сегодня пользуемся. Следовательно, система должна правильно идентифицировать видео-потоки, чтобы отделить их от остального трафика. Как это проделать в реальном времени с 8-ю десяти-гигабитными линками? Они, конечно, обычно не заполняются на 100%, поэтому суммарно трафика будет не 80 гигабит/с, а примерно 50-60, но и это не так уж мало.
• Масштабируемость. Там, где уже много видео-потоков, их может стать ещё больше, поскольку видео-наблюдение уже давно оправдало себя как эффективный инструмент. Это говорит о том, что должен быть запас по производительности и резерв по линкам.

Ищем подходящее решение…

Мы, естественно, стремились максимально использовать собственный опыт. К моменту принятия решения у нас уже была реализация обработки ethernet-пакетов на FPGA-powered девайсе Беркут-МХ (проще - MX). С помощью Беркут-MX мы умели получать из заголовков Ethernet-пакетов нужные поля для анализа. Опыта обработки такого объёма трафика средствами “обычных” серверов у нас не было, увы, поэтому на подобное решение смотрели с некоторой опаской…

Казалось бы, оставалось просто применить метод к RTP-пакетам и золотой ключик был бы у нас в кармане, но MX умеет только обрабатывать трафик, в него не заложены возможности учёта и хранения статистики. Для хранения найденных соединений (комбинаций IP-IP-порт-порт) в ПЛИС не хватит памяти, ведь в 2x10-гигабитном линке, заходящем на вход, может быть около 15 тысяч видео-потоков, и по каждому нужно “помнить” количество принятых пакетов, количество потерянных пакетов и так далее… Более того, поиск на такой скорости и по такому количеству данных при условии обработки без потерь становится нетривиальной задачей.

Чтобы найти решение, пришлось “копнуть глубже” и разобраться в том, по каким алгоритмам мы будем измерять качество и идентифицировать видео-потоки.

Что можно измерить по полям RTP-пакета?

Из описания видно, что с точки зрения измерений качества в RTP-пакете нас интересуют следующие поля:

• sequence number - 16-ти разрядный счётчик, увеличивающийся с каждым отправленным пакетом;
• timestamp - временная метка, для h.264 величина дискрета составляет 1/90000 c (т.е. соответствует частоте 90 КГц);
• Marker-бит. В rfc3550 в общем виде описано, что этот бит предназначен для обозначения “значимых” событий , а по факту этим битом чаще всего камеры маркируют начало видео-кадра и специализированные пакеты с SPS/PPS-информацией.

Вполне очевидно, что sequence number позволяет определить следующие параметры потока:

• потери пакетов (frame loss);
• повторную посылку пакета (duplicate);
• изменение порядка прихода (reordering);
• перезагрузку камеры, при большом «разрыве» в последовательности.

Timestamp позволяет измерить:

• вариацию задержки (ещё называют джиттером). При этом на приёмной стороне должен работать 90 КГц счётчик;
• в принципе, задержку прохождения пакета. Но для этого нужно синхронизировать время камеры с timestamp’ом, а это возможно, если камера передаёт sender reports (RTCP SR), что в общем случае неверно, т.к. в реальной жизни многие камеры игнорируют посылку RTCP SR (примерно половина камер, с которыми нам довелось поработать).

Ну а M-бит позволяет измерить частоту кадров. Правда, SPS/PPS-кадры протокола h.264 вносят погрешность, т.к. видео-кадрами не являются. Но её можно нивелировать, использовав информацию из заголовка NAL-unit’а, который всегда идёт следом за RTP-заголовком.

Подробные алгоритмы измерения параметров выходят за рамки статьи, не буду заглубляться. Если интересно, то в rfc3550 есть пример кода вычисления потерь и формулы для вычисления джиттера . Главный же вывод заключается в том, что для измерений базовых характеристик транспортного потока достаточно всего лишь нескольких полей из RTP-пакетов и NAL-юнитов. А остальная информация в измерениях не участвует и её можно и нужно отбросить!

Как идентифицировать RTP-потоки?

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

• IP-адреса источника и получателя
• Порты источника и получателя
• SSRC. Имеет особое значение тогда, когда с одного IP вещается несколько потоков, т.е. в случае с многопортовым энкодером.

Что интересно, мы сначала сделали идентификацию камер только по IP источника и SSRC, полагаясь на то, что SSRC должен быть случайным, но на практике оказалось, что многие камеры устанавливают SSRC в фиксированное значение (скажем, 256). Видимо, это связано с экономией ресурсов. В итоге нам пришлось к идентификатору камеры добавить ещё и порты. Это решило проблему уникальности полностью.

Как отделить RTP-пакеты от остального трафика?

Остался вопрос: как Беркут-MX, приняв пакет, поймёт, что это RTP? RTP-заголовок не имеет такой явной идентификации, как IP, у него нет контрольной суммы, передаваться он может по UDP с номерами портов, которые выбираются динамически при установке соединения. А в нашем случае большинство соединений уже давно установлены и ждать переустановки можно очень долго.

Для решения этой задачи в rfc3550 (Appendix A.1) рекомендуется проверять биты версии RTP - это два бита, и поле Payload Type (PT) - семь бит, которое в случае с динамическим типом принимает небольшой диапазон. Мы на практике выяснили, что для того множества камер, c которым мы работаем, PT укладывается в диапазон от 96 до 100.

Есть ещё один фактор - чётность порта, но как показала практика, не всегда соблюдается, поэтому от него пришлось отказаться.

Таким образом, поведение Беркут-MX следующее:

1. получаем пакет, разбираем на поля;
2. если версия равна 2 и payload type находится в заданных пределах, то отправляем заголовки серверу.

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

Для фильтрации ложных случаев сервер использует механизм, который регистрирует источник видео-трафика по нескольким последовательно принятым пакетам (в пакете же есть sequence number!). Если несколько пакетов пришло с последовательными номерами, то это не случайное совпадение и начинаем работать с этим потоком. Этот алгоритм оказался весьма надёжным.

Двигаемся дальше…

Поняв, что вся информация, идущая в пакетах, для измерения качества и идентификации потоков не нужна, мы решили всю highload & time-critical работу по приёму и вычленению полей RTP-пакетов взвалить на Беркут-MX, то бишь на FPGA. Он “находит” видео-поток, разбирает пакет, оставляет только нужные поля и в UDP-туннеле отправляет на обычный сервер. Сервер проводит измерения по каждой камере и сохраняет результаты в базу данных.

В итоге сервер работает не с 50-60 Гигабит/с, а максимум с 5% (именно такая получилась пропорция отсылаемых данных к среднему размеру пакета). То есть на входе всей системы 55 Гигабит/с, а на сервер попадает всего-то не более 3 Гигабит/с!

В итоге у нас получилась такая архитектура:

И первый результат в такой конфигурации мы получили через две недели после постановки начального ТЗ!

Чем в итоге занят сервер?

Итак, что же делает сервер в нашей архитектуре? Его задачи:

• слушать UDP-сокет и вычитывать из него поля с упакованными заголовками;
• разбирать приходящие пакеты и доставать оттуда поля RTP заголовков вместе с идентификаторами камеры;
• соотносить полученные поля с теми, что были получены прежде, и понимать, потерялись ли пакеты, посылались ли пакеты повторно, менялся ли порядок прихода, какая была вариация задержки прохождения пакета (джиттер) и т.д.;
• фиксировать измеренное в базе с привязкой ко времени;
• анализировать базу и генерировать отчёты, посылать трапы о критических событиях (высокие потери пакетов, пропадание пакетов от какой-то камеры и т.п.).

При том, что суммарный трафик на входе сервера составляет около 3 Гигабит/с, сервер справляется даже при условии, что мы не используем никаких DPDK, а работаем просто через linux’овый сокет (предварительно увеличив размер буфера для сокета, конечно). Более того, можно будет подключать новые линки и MX"ы, потому что запас по производительности остаётся.

Вот как выглядит top сервера (это top только одного lxc-контейнера, отчёты генерируются в другом):

Из него видно, что вся нагрузка по расчёту параметров качества и учёту статистики распределена по четырём процессам равномерно. Нам удалось добиться такого распределения за счёт применения хеширования в FPGA: по IP считается хеш-функция, а младшие биты полученного хеша определяют номер UDP-порта, на который уйдёт статистика. Соответственно, каждый процесс, слушающий свой порт, получает примерно одинаковое количество трафика.

Cons and pros

Настало время похвастаться и признаться в недостатках полученного решения.

Начну с плюсов:

• отсутствие потерь на стыке с 10G-линками. Поскольку весь “удар” на себя берёт ПЛИС, мы можем не сомневаться в том, что будет проанализирован каждый пакет;
• для мониторинга 55000 камер (и более) требуется всего один сервер с одной 10G карточкой. Мы пока используем сервера на базе 2х Xeon c 4мя ядрами по 2400 МГц каждое. Хватает с запасом: параллельно со сбором информации генерируются отчёты;
• мониторинг 8-ми “десяток” (10G линков) укладывается всего в 2-3 юнита: не всегда под систему мониторинга есть много места и питания в стойке;
• при подключении линков от MX’ов через коммутатор можно добавлять новые линки без остановки мониторинга, т.к. никакие платы в сервер вставлять не надо и для этого не требуется его выключать;
• сервер не перегружен данными, он получает только то, что необходимо;
• заголовки с MX’а приходят в jumbo Ethernet-пакете, значит процессор не захлебнётся прерываниями (к тому же мы не забываем и про interrupt coalescing).

Справедливости ради рассмотрю и недостатки:

• из-за жёсткой оптимизации под конкретную задачу добавление поддержки новых полей или протоколов требует изменений в коде ПЛИС. Это приводит к бОльшим затратам времени, чем если бы мы делали это же на процессоре. Как в разработке и тестировании, так и при деплое;
• видео-информация не анализируется вообще. Камера может снимать сосульку, висящую перед ней, или быть повёрнутой не в ту сторону. Этот факт останется незамеченным. Мы, конечно, предоставили возможность записи видео с выбранной камеры, но не перебирать же оператору все 55000 камер!
• сервер и FPGA-powered девайсы - это дороже, чем просто один-два сервера;)

Резюме

В конечном итоге у нас получился программно-аппаратный комплекс, в котором мы можем контролировать и ту часть, которая парсит пакеты на интерфейсах, и ту, которая ведёт статистику. Полный контроль над всеми узлами системы буквально спас нас, когда камеры начали переводить на RTSP/TCP interleaved mode. Потому что в этом случае заголовок RTP перестал располагаться в пакете по фиксированному смещению: он может находиться где угодно, даже на границе двух пакетов (первая половина в одном, вторая - в другом). Соответственно, алгоритм получения RTP-заголовка и его полей претерпел кардинальные изменения. Нам пришлось сделать TCP reassembling на сервере для всех 50000 соединений - отсюда и довольно высокая нагрузка в top’е.

Мы никогда до этого не работали в сфере высоконагруженных приложений, но нам удалось решить задачу за счёт наших скилов в FPGA и получилось довольно-таки неплохо. Даже остался запас - например, к системе с 55000 камерами можно подключить ещё 20-30 тысяч потоков.

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

Я описал далеко не всё, граблей было собрано немало, поэтому не стесняйтесь задавать вопросы:)

Большое спасибо всем, кто дочитал до конца!

Стремительный рост Internet предъявляет новые требования к скорости и объемам передачи данных. И для того чтобы удовлетворить все эти запросы, одного увеличения емкости сети недостаточно, необходимы разумные и эффективные методы управления трафиком и загруженностью линий передачи.

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

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

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

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

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

Примечание

Для каждого участника RTP сеанс определяется парой транспортных адресов назначения пакетов (один сетевой адрес - IP и пара портов: RTP и RTCP).

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

Примечание

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

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

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

Методы контроля работы

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-time Transport Control Protocol), основная задача которого состоит в обеспечении управления передачей RTP. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTCP выполняет несколько функций:

1. Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео - это позволяет передавать данные по соединению низкой емкости.
2. Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
3. Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

Формат заголовка протокола RTP

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

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

Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам:

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

Другой широко используемый протокол транспортного уровня - LJDP не имеет части ограничений TCP, но и он не предоставляет критической информации о синхронизации.

Несмотря на то, что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает определение единого протокола весьма желательным.

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

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

0

2

3

4

8

16

31

Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifiers

Рис. 1. Фиксированный RTP-заголовок.

V (2 бита). Поле версии. Текущая версия - вторая.
Р (1 бит). Поле заполнения. Это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам. В этом случае последний октет указывает число заполняющих октетов.
Х (1 бит). Поле расширения заголовка. Когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.
СС (4 бита). Поле числа отправителей. Это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит). Поле маркера. Смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания.
РТ (7 бит). Поле типа полезной нагрузки. Это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol).
Sequence Number (16 бит). Поле порядкового номера. Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.
Timestamp (32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Synchronization Source (SSRC) Identifier (32 бита). Поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса и независимое от сетевого адреса. Это число играет важную роль при обработке поступившей порции данных от одного источника.
Contributing source (CSRC) Identifier (32 бита). Список полей идентификаторов источника, "подмешанных" в основной поток, например, с помощью микшера. Микшер вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Этот список и называется CSRC. Количество элементов в списке: от 0 до 15. Если число участников более 15 - выбираются первые 15. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим SSRC - они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям (сравните, например, протоколы IP и TCP). Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.

Протокол резервирования ресурсов - RSVP

Решить проблему приоритетности для чувствительных к задержкам данных, в противовес традиционным данным, для которых задержки не столь критичны, призван протокол резервирования ресурсов - RSVP, находящийся в настоящее время на рассмотрении в группе инженерной поддержки Internet (IETF). RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы для графика реального времени по протоколу RTP. RSVP касается прежде всего маршрутизаторов, хотя приложения в конечных узлах также должны знать, как использовать RSVP в целях резервирования необходимой полосы пропускания для данного класса услуг или уровня приоритета.

RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям. RTP/RTCP/RSVP - стандартизованное решение для сетей с передачей данных в реальном времени. Единственным его недостатком является то, что оно предназначено только для IP-сетей. Однако это ограничение временное: сети так или иначе будут развиваться в этом направлении. Данное решение обещает решить проблему передачи чувствительных к задержкам данных по Internet.

Литература

Описание протокола RTP можно найти в RFC-1889.

Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов TCP/IP сейчас весьма акту­ально. Эту задачу призван решить транспортный протокол реального времени (Real-Time Transport Protocol, RTP), который является стандартом IETF для передачи таких данных, как голос или видео, в реальном времени по сети, не гарантирующей качества обслуживания.

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

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

Адресная схема протокола IP

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

При использовании в сети стека протоколов TCP/IP конечные устройства получают уникальные адреса. Такими устройствами могут быть персональные компьютеры, коммуникационные сервера, маршрутизаторы и т. д. При этом не­которые устройства, которые имеют несколько физических портов, например маршрутизаторы, должны иметь уникальный адрес на каждом из портов. Исходя из схемы адресации и того, что некоторые устройства в сети могут иметь не­сколько адресов, можно сделать вывод, что данная схема адресации описывает не само устройство в сети, а определенное соединение этого устройства с сетью. Данная схема приводит к ряду неудобств. Одним из них является необходи­мость замены адреса устройства при перемещении его в другую сеть. Другой недостаток в том, что для работы с устройством, имеющим несколько подключе­ний в распределенной сети, необходимо знать все его адреса, идентифицирую­щие эти подключения.

Итак, для каждого устройства в сетях IP можно говорить об адресах трех уровней:

q Физический адрес устройства (точнее - определенного интерфейса). Для устройств в сетях Ethernet - это МАК - адрес сетевой карты или порта маршрутизатора. Эти адреса назначаются производителями оборудования. Физический адрес имеет шесть байтов: старшие три байта - идентифика­тор фирмы-производителя, младшие три байта назначаются самим произ­водителем;

q IP-адрес, состоящий из четырех байт. Этот адрес используется на сетевом уровне эталонной модели OSI;

q Символьный идентификатор - имя. Этот идентификатор может назна­чаться администратором произвольно.

Когда протокол IP был стандартизован в сентябре 1981 года, его специфика­ция требовала, чтобы каждое устройство, подключенное к сети, имело уникаль­ный 32-битный адрес. Этот адрес разбивается на две части. Первая часть адреса идентифицирует сеть, в которой располагается устройство. Вторая часть одноз­начно идентифицирует само устройство в рамках сети. Такая схема приводит к двухуровневой адресной иерархии (рис. 6.23).

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

Для обеспечения гибкости в присвоении адресов компьютерным сетям разра­ботчики протокола определили, что адресное пространство IP должно быть раз­делено на три различных класса - А, В и С. Зная класс, вы знаете, где в 32-битном адресе проходит граница между сетевым префиксом и номером устройства. На рис. 6.24 показаны форматы адресов этих основных классов.

Одно из основных достоинств использования классов заключается в том, что по классу адреса можно определить, где проходит граница между сетевым пре­фиксом и номером устройства. Например, если старшие два бита адреса равны 10, то точка раздела находится между 15 и 16 битом.

Недостатком такого метода является необходимость изменения сетевого ад­реса при подключении дополнительных устройств. Например, если общее число устройств в сети класса С будет превышать 255, то потребуется заменить ее адреса на адреса класса В. Изменение сетевых адресов потребует от админист­ратора дополнительных усилий по отладке сети. Администраторы сетей не могут осуществить плавный переход к новому классу адресов, так как классы четко разделены. Приходится запрещать использовать целую группу сетевых адресов, производить одновременное изменение всех адресов устройств в этой группе, и только затем вновь разрешать их использование в сети. Кроме того, введение классов адресов значительно уменьшает теоретически возможное число индивидуальных адресов. В текущей версии протокола IP (версия 4) общее число адресов могло составлять 2 32 (4 294 967 296), так как протокол преду­сматривает использование 32 бит для задания адреса. Естественно, использование части бит в служебных целях уменьшает доступное количество индивидуальных адресов.

Класс А предназначен для больших сетей. Каждый адрес класса А имеет 8-битовый префикс сети, в котором старший бит установлен в 1, а следующие семь бит используются для номера сети. Для номера устройства задействуются оставшиеся 24 бита. В настоящий момент все адреса класса А уже выделены. Сети класса А также обозначаются как «/8», поскольку адреса этого класса имеют 8-битовый сетевой префикс.

Максимальное число сетей класса А составляет 126 (2 7 -2 - вычитаются два адреса, состоящие из одних нулей и единиц). Каждая сеть этого класса поддер­живает до 16 777 214 (2 24 -2) устройств. Так как адресный блок класса А может содержать максимум до 2 31 (2 147483648) индивидуальных адресов, а в прото­коле IP версии 4 может поддерживаться максимум до 2 32 (4 294 967 296) адре­сов, то класс А занимает 50 % общего адресного пространства протокола IP.

Класс В предназначен для сетей среднего размера. Каждый адрес класса В имеет 16-битовый сетевой префикс, в котором два старших бита равны 10, а следующие 14 бит используются для номера сети. Для номера устройства выде­лены 16 бит. Сети класса В также обозначаются как «/16», поскольку адреса этого класса имеют 16-битный сетевой префикс.

Максимальное число сетей класса В равно 16 382 (2 14 -2). Каждая сеть этого класса поддерживает до 65 534 (2 16 -2) устройств. Так как весь адресный блок класса В может содержать максимум до 2 30 (1 073 741 824) индивидуальных ад­ресов, он занимает 25 % общего адресного пространства протокола IP.

Адреса класса С используются в сетях с небольшим числом устройств. Каж­дая сеть класса С имеет 24-битный сетевой префикс, в котором три старших бита равны 110, а следующие 21 бит используются для номера сети. Под номера устройства выделены оставшиеся 8 бит. Сети класса С также обозначаются как «/24», поскольку адреса этого класса имеют 24-битный сетевой префикс.

Максимальное число сетей класса С составляет 2 097 152 (2 21). Каждая сеть этого класса поддерживает до 254 (2 8 -2) устройств. Класс С занимает 12.5 % общего адресного пространства протокола IP.

В табл. 6.9 подводится итог нашему анализу классов сетей.

Таблица 6.9. Классы сетей

В дополнение к этим трем классам адресов выделяют еще два класса. В клас­се D старшие четыре бита равны 1110. Этот класс используется для групповой передачи данных. В классе Е старшие четыре бита - 1111. Он зарезервирован для проведения экспериментов.

Для удобства чтения адресов в технической литературе, прикладных про­граммах и т. д. IP-адреса представляются в виде четырех десятичных чисел, раз­деленных точками. Каждое из этих чисел соответствует одному октету (8 битам) IP-адреса. Этот формат называют точечно-десятичным (Decimal-Point Notation) или точечно-десятичной нотацией (рис. 6.25).

В табл. 6.10 перечислены диапазоны десятичных значений трех классов адре­сов. В табл. 6.10 запись XXX означает произвольное поле.

Таблица 6.10. Диапазоны значений адресов

Некоторые IP-адреса не могут присваиваться устройствам в сети (табл. 6.11).

Как показано в этой таблице, в зарезервированных IP-адресах все биты, установленные в ноль, соответствуют либо данному устройству, либо данной сети, а IP-адреса, все биты которых установлены в 1, используются при ши­роковещательной передаче информации. Для ссылки на всю IP-сеть в целом используется адрес с номером устройства, у которого все биты установлены в «0». Сетевой адрес класса А - 127.0.0.0 зарезервирован для обратной связи и введен для проверки взаимодействия между процессами на одной машине. Ког­да приложение использует адрес обратной связи (loopback), стек протоколов TCP/IP возвращает эти данные приложению, ничего не посылая в сеть. Кроме того, данный адрес можно использовать для взаимодействия отдельных процес­сов в пределах одной машины. Поэтому в сетях IP запрещается присваивать устройствам IP-адреса, начинающиеся со 127.

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

Направленное широковещание позволяет устройству из удаленной сети по­слать дейтаграмму всем устройствам в текущей сети. Дейтаграмма с направлен­ным широковещательным адресом может проходить через маршрутизаторы, но доставлена она будет только всем устройствам в указанной сети, а не вообще всем устройствам. При направленном широковещании адрес получателя состоит из номера конкретной сети и номера устройства, все биты которого равны 0 или 1. Например, адреса 185.100.255.255 и 185.100.0.0 будут рассматриваться как адреса направленного широковещания для сети 185.100.xxx.xxx класса В. С точки зрения адресации, главным недостатком направленного широковеща­ния является то, что требуется знание номера целевой сети.

Вторая форма широковещания, называемая ограниченным широковещанием, обеспечивает широковещательную передачу в рамках текущей сети (сети, где находится устройство-отправитель). Дейтаграмма с ограниченным широкове­щательным адресом никогда не будет пропущена через маршрутизатор. При ограниченном широковещании биты номера сети и номера устройства состоят из всех нулей или единиц. Таким образом дейтаграмма с адресом получате­ля 255.255.255.255 или 0.0.0.0 будет доставлена всем устройствам в сети. На рис. 6.26 показаны сети, связанные маршрутизаторами. В табл. 6.12 перечис­лены получатели широковещательных дейтаграмм, отправляемых рабочей стан­цией А.

Протокол IP поддерживает три способа адресации: единичную (unicast), ши­роковещательную (broadcast) и групповую (multicast).

Таблица 6.12. Получатели широковещательных дейтаграмм

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

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

При групповой адресации дейтаграммы доставляются определенной группе устройств. При этом (что очень важно при работе в распределенных сетях) не генерируется избыточный трафик. Дейтаграммы с групповым и единичным ад­ресом различаются адресом. В заголовке IP-дейтаграммы с групповой адреса­цией вместо IP-адресов классов А, В, С содержится адрес класса D, то есть групповой адрес.

Групповой адрес присваивается некоторым устройствам-получателям или, иными словами, группе. Отправитель записывает данный групповой адрес в за­головок IP-дейтаграммы. Дейтаграмма будет доставлена всем членам группы. Первые четыре бита адреса класса D равны 1110. Остальную часть адреса (28 бит) занимает идентификатор группы (рис. 6.27).

В точечно-десятичном формате групповые адреса лежат в диапазоне от 224.0.0.0 до 239.255.255.255. В табл. 6.13 показана схема распределения адресов класса D.

Таблица 6.13. Распределение адресов класса D

Как видно из табл. 6.13, первые 256 адресов зарезервированы. В частности, этот диапазон отведен протоколам маршрутизации и другим низкоуровневым протоколам. В табл. 6.14 содержатся некоторые зарезервированные IP-адреса класса D.

Выше этого диапазона находится большая группа адресов, выделенных для приложений, работающих в сети Internet. Самый верхний диапазон адресов (примерно 16 миллионов адресов) предназначен для административных целей в локальных сетях. Централизованным управлением и регистрацией групповых адресов класса D занимается специальная организация IANA.

Групповая адресация может быть реализована на двух уровнях модели OSI - канальном (Data-Link Layer) и сетевом (Network Layer). Протоколы пе­редачи канального уровня, например, Ethernet и FDDI, могут поддерживать еди­ничную, широковещательную и групповую адресацию. Групповая адресация на канальном уровне особенно эффективна, если она поддерживается сетевой пла­той аппаратно.

Для поддержки групповой адресации IANA выделен блок групповых Ether­net-адресов, начиная с 01-00-5Е (в шестнадцатеричном представлении). Груп­повой IP-адрес может транслироваться в адрес из этого блока. Принцип трансляции достаточно прост: младшие 23 бита идентификатора IP-группы ко­пируются в младшие 23 бита Ethernet-адреса. При этом необходимо учитывать, что данная схема ассоциирует до 32 различных IP-групп с одним и тем же Ethernet-ад­ресом, так как следующие 5 бит идентификатора IP-группы игнорируются.

Таблица 6.14. Зарезервированные адреса класса D

Адрес	Назначение
224.0.0.1	Все устройства подсети
224.0.0.2	Все маршрутизаторы подсети
224.0.0.4	Все DVMRP-маршрутизаторы
224.0.0.5	Все MOSPF-маршрутизаторы
224.0.0.9	RIP IP версии II
224.0.1.7	Аудионовости
224.0.1.11	IEFT аудио
224.0.1.12	IEFT видео

Если отправитель и получатель принадлежат одной физической сети, про­цесс передачи и приема групповых кадров на канальном уровне достаточно прост. Отправитель указывает IP-адрес группы получателей, а сетевая плата вы­полняет трансляцию этого адреса в соответствующий групповой Ethernet-адрес и посылает кадр.

Если отправитель и получатель находятся в разных подсетях, связанных мар­шрутизаторами, доставка дейтаграмм затруднена. В этом случае маршрутизато­ры должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM - см. ниже). Согласно этим протоколам маршрутиза­тор построит дерево доставки и правильно передаст групповой трафик. Кроме того, каждый маршрутизатор должен поддерживать протокол управления груп­пами (IGMP) для определения наличия членов группы в непосредственно под­ключенных подсетях (рис. 6.28).

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

Итак, с чем мы будем разбираться под катом:

1. Базовые понятия телефонии: типы аппаратов, схемы подключения
2. Связка SIP/SDP/RTP-протоколов: как это работает
3. Как передается информации о нажатых кнопках
4. Как происходит передача голоса и факсов
5. Цифровая обработка сигналов и обеспечение качества звука в IP-телефонии

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

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

На стороне провайдера (АТС) установлен телефонный модуль с портом 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-пакетов:

• Start-Line: поле, указывающее SIP-метод (команду) при запросе или результат выполнения SIP-метода при ответе.
• Headers: дополнительная информация к Start-Line, оформленная в виде строк, содержащих пары АТТРИБУТ: ЗНАЧЕНИЕ.
• Body: бинарные или текстовые данные. Обычно используется для передачи SDP-параметров или сообщений.

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

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

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

• Method/Request-URI содержит SIP-метод и URI. В примере происходит установление сессии - метод INVITE, вызов абонента [email protected].
• Status-Code - код ответа на предыдущую SIP-команду. В данном примере команда выполнилась успешно - код 200, т.е. абонент 555 поднял трубку.
• Via - адрес, на котором абонент 777 ждет ответа. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• From/To - отображаемые имя и адрес отправителя и получателя сообщения. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Cseq содержит порядковый номер команды и название метода, к которому относится данное сообщение. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Content-Type - тип данных, которые передаются в блоке Body, в данном случае - SDP-данные.
• Connection Information - IP-адрес, на который второму абоненту необходимо отправлять пакеты RTP (или UDPTL пакеты в случае передачи факса по T.38).
• Media Description - порт, на который второй абонент должен передавать указанные данные. В данном случае это звук (audio RTP/AVP) и список поддерживаемых типов данных - PCMU, PCMA, GSM-кодеки и DTMF-сигналы.

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

• o - Origin, имя организатора сессии и идентификатор сессии.
• с - Connection Information, поле описано ранее.
• m - Media Description, поле описано ранее.
• a - медиа-атрибуты, уточняют формат передаваемых данных. Например, указывают направление звука - прием или передача (sendrecv), для кодеков указывают частоту дискретизации и номер привязки (rtpmap).

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

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

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

Как только запускается 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. Передача информации о нажатых кнопках

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

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

• Импульсный - исторически первый, использовался в основном в телефонах с дисковым номеронабирателем. Набор происходит за счет последовательного замыкания и размыкания телефонной линии согласно набираемой цифре.
• Тоновый - набор номера DTMF-кодами (Dual-Tone Multi-Frequency) - каждой кнопке телефона соответствует своя комбинация двух синусоидальных сигналов (тонов). Выполняя алгоритм Гёрцеля можно довольно просто определить нажатую кнопку.

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

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

1. DTMF Inband - генерация звукового тона и передача его внутри аудиоданных (текущего RTP-канала) - это обычный тоновый набор.
2. RFC2833 - генерируется специальный RTP-пакет telephone-event, в котором содержится информация о нажатой клавише, громкость и длительность. Номер RTP-формата, в котором будут передаваться пакеты DTMF RFC2833, указывается в теле SDP-сообщения. Например: a=rtpmap:98 telephone-event/8000.
3. SIP INFO - формируется пакет SIP INFO c информацией о нажатой клавише, громкости и длительности.

Передача 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-передачей факса.

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

1. Устанавливается обычное голосовое соединение по любому кодеку.
2. Когда бумага загружена в отправляющий факс, он периодически шлет T.30-сигнал CNG (Calling Tone), что означает готовность к передаче факса.
3. На принимающей стороне генерируется T.30-сигнал CED (Called Terminal Identification) - это готовность принять факс. Данный сигнал отправляется либо после нажатия кнопки «Получить факс» либо факс делает это автоматически.
4. На отправляющей стороне обнаруживается CED-сигнал и происходит процедура SIP REINVITE, а в SDP-сообщении указывается T.38 тип: m=image 39164 udptl t38.

Передавать факсы по интернету желательно в 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-серверов.

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

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

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

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

Tc qdisc change dev eth1 root netem loss 50%

Отключение эмуляции:

Tc qdisc del dev eth1 root

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

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

tc qdisc add dev eth1 root netem delay 500ms reorder 99%

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

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

• акустическое эхо из-за некачественного аудиотракта (звук из динамика попадает в микрофон);
• электрическое эхо из-за несогласованности импедансов между телефонным аппаратом и SLIC-модулем. В большинстве случаев это происходит в цепях преобразования 4-проводной телефонной линии в 2-проводную.

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

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

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

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

Теги:

• для начинающих
• для новичков

Добавить метки