- •Глава 1 Конвергенция сетей связи 4
- •Глава 2. Сетевые аспекты ip-телефонии 34
- •Глава 3 Передача речи по ip-сетям 56
- •Глава 4 Протоколы сети Интернет 84
- •Глава 5 - Архитектура н.323 116
- •Глава 8 Протокол управления шлюзами mgcp 221
- •11 Принципы реализации
- •Глава 1 Конвергенция сетей связи
- •1.1 Пропорции в телекоммуникациях
- •А) Трафик в сша б) Трафик в Европе
- •1.2 Перспективы развития ТфОп и ip-сетей
- •1.3 Транспортные технологии пакетной коммутации
- •1.4 Уровни архитектуры ip-телефонии
- •1.5 Различные подходы к построению сетей ip-телефонии
- •1.5.1 Построение сети по рекомендации н.323
- •1.5.2 Сеть на базе протокола sip
- •1.5.3 Сеть на базе mgcp и megaco
- •1.5.4 Сравнение подходов к построению сети ip-телефонии
- •Глава 2. Сетевые аспекты ip-телефонии
- •2.1 Три основных сценария ip-телефонии
- •Вызов инициирован абонентом ТфОп
- •2.2 Проект tiphon
- •2.3 Установление телефонного соединения в ip-сети
- •Абонент а набирает телефонный номер вызываемого абонента б.
- •Шлюз консультируется с привратником о возможных способах маршрутизации вызова.
- •2.4 Эффективность ip-телефонии
- •Глава 3 Передача речи по ip-сетям
- •3.1 Особенности передачи речевой информации по ip - сетям
- •3.1.1 Задержки
- •3.1.3 Устройства ограничения эффектов эха
- •3.2 Принципы кодирования речи
- •3.2.1 Кодирование формы сигнала
- •3.2.2 Кодеры исходной информации (вокодеры) и гибридные алгоритмы
- •Генератор возбуждающего сигнала
- •3.2.3 Процессоры цифровой обработки сигналов для речевых кодеков
- •3.2.4 Основные алгоритмы кодирования речи, используемые в ip-телефонии
- •3.3 Кодеки, стандартизованные itu-t
- •Кодек g.711
- •Кодек g.723.1
- •Кодек g.726
- •Кодек g.728
- •3.3.5 Кодек g.729
- •3.4 Кодеки, стандартизованные etsi
- •3.5 Передача сигналов dtmf
- •3.6 Передача факсимильной информации
- •3.7 О реализации «стандартных» алгоритмов
- •Глава 4 Протоколы сети Интернет
- •4.1 Интернет ab ovo
- •4.2 Стандарты в сфере Интернет
- •4.3 Адресация
- •4.4 Уровни архитектуры Интернет
- •4.5 Протокол ip версии 4
- •4.6 Протокол ip версии 6
- •4.7 Протокол tcp
- •1 Потоки, стек протоколов, механизм портов и мультиплексирование
- •4.7.2 Установление tcp-соединения и передача данных
- •4.7.3 Механизмы обеспечения достоверности
- •4.7.4 Механизм управления потоком данных
- •4.7.5 Состав и назначение полей заголовка
- •4.8 Протокол udp
- •4.9 Требования к современным ip-сетям
- •4.10 Протоколы rtp и rtcp
- •4.11 Многоадресная рассылка
- •Глава 5 - Архитектура н.323
- •5.1 Стандарты мультимедийной связи
- •5.2 Архитектура систем видеотелефонии в узкополосных isdn
- •5.3 Мультимедийная связь в ip-сетях
- •5.4 Терминал н.323
- •5.5 Шлюз н.323
- •5.6 Привратник
- •5.7 Устройство управления конференциями
- •5.8 Реализация оборудования н.323
- •Глава 6 Сигнализация н.323
- •6.1 Семейство протоколов н.323
- •6.2 Протокол ras
- •6.2.1 Обнаружение привратника
- •6.2.2 Регистрация оконечного оборудования
- •6.2.3 Доступ к сетевым ресурсам
- •6.2.4 Определение местоположения оборудования в сети
- •6.2.5 Изменение полосы пропускания
- •6.2.7 Освобождение полосы пропускания
- •6.2.8 Метка доступа
- •6.3 Сигнальный канал н.225.0
- •Сигнальные сообщения h.225.0/q.931 Сообщения ras
- •6.4 Управляющий канал н.245
- •6.4.1 Определение ведущего и ведомого
- •6.4.2 Обмен данными о функциональных возможностях
- •6.4.3 Открытие и закрытие логических каналов
- •6.4.4 Выбор режима обработки информации
- •6.5 Алгоритмы установления, поддержания и разрушения соединения
- •6.5.1 Базовое соединение с участием привратника
- •6.5.2 Базовое соединение без участия привратника
- •Туннелирование управляющих сообщений
- •Процедура быстрого установления соединения
- •6.5.5 Установление соединения с участием шлюза
- •Глава 7 Протокол инициирования сеансов связи - sip
- •7.1 Принципы протокола sip
- •7.2 Интеграция протокола sip с ip-сетями
- •7.4 Архитектура сети sip
- •Терминал
- •7.3 Адресация
- •Прокси-сервер
- •7.4.3 Сервер переадресации
- •Сервер определения местоположения пользователей
- •Пример sip- сети
- •7.5 Сообщения протокола sip
- •7.5.1 Структура сообщений
- •7.5.2 Заголовки сообщений
- •7.5.3 Запросы
- •7.5.4 Ответы на запросы
- •7.6 Алгоритмы установления соединения
- •7.8 Сравнительный анализ протоколов н.323 и sip
- •Глава 8 Протокол управления шлюзами mgcp
- •8.1 Принцип декомпозиции шлюза
- •8.2 Классификация шлюзов
- •8.3 Модель организации связи
- •8.4 Команды протокола mgcp
- •1 (Телефонный ::: канал 2)
- •8.5 Структура команд
- •8.6 Структура ответов на команды
- •8.7 Описания сеансов связи
- •8.8 Установление, изменение и разрушение соединений
- •8.9 Реализация оборудования с поддержкой протокола mgcp
- •8.10 Возможности и перспективы протокола mgcp
- •Глава 9 Протокол megaco/h.248
- •9.1 История создания и особенности протокола megaco/h.248
- •9.3 Сравнительный анализ протоколов mgcp и megaco
- •9.4 Структура команд и ответов
- •9.5 Пример установления и разрушения соединения
- •Глава 10 Качество обслуживания в сетях ip-телефонии 10.1 Что понимается под QoS?
- •Качество обслуживания в сетях пакетной коммутации
- •Трафик реального времени в ip-сетях
- •10.4 Дифференцированное обслуживание разнотипного трафика - Diff-Serv
- •10.5 Интегрированное обслуживание IntServ
- •10.6.2 Процедура резервирования ресурсов
- •10.7 Технология mpls
- •10.8 Обслуживание очередей
- •10.8.1 Алгоритмы организации очереди
- •10.8.1.1 Алгоритм Tail Drop
- •10.8.1.2 Алгоритм Random Early Detection (red)
- •10.8.2 Алгоритмы обработки очередей
- •10.8.2.1 Стратегия fifo
- •10.8.2.2 Очередь с приоритетами
- •10.8.3 Алгоритмы сглаживания пульсации графика
- •10.8.3.1 Алгоритм Leaky Bucket
- •10.8.3.2 Алгоритм «Token Bucket»
- •Глава 11 Принципы реализации
- •11.1 Оборудование ip-телефонии
- •11.2 Особенности оборудования ip-телефонии для России
- •11.3 Шлюз ip-телефонии Протей-itg
- •11.4 Привратник Протей-gk и варианты организации связи
- •11.5 Экономические аспекты применения оборудования ip- телефонии
- •11.6 Виртуальная телефонная линия
- •Система сервисных телефонных карт
- •11.7 Центр обработки вызовов
- •11.8 Модуль ipu как средство интеграции цифровых атс с ip- сетями
- •11.9 Тестирование протоколов ip-телефонии
3.2.4 Основные алгоритмы кодирования речи, используемые в ip-телефонии
В первую очередь необходимо понять, какими критериями нужно руководствоваться при выборе «хорошего» кодекадля использования в IP-телефонии.
Использование полосы пропускания канала
Скорость передачи, которую предусматривают имеющиеся сегодня узкополосные кодеки, лежит в пределах 1.2 - 64 Кбит/с. Естественно, что от этого параметра прямо зависит качество воспроизводимой речи. Существует множество подходов к проблеме определения качества. Наиболее широко используемый подход оперирует оценкой MOS (Mean Opinion Score), которая определяется для конкретного кодека как
^ WW W ^ W
средняя оценка качества большой группой слушателей по пятибалльной шкале. Для прослушивания экспертам предъявляются разные звуковые фрагменты - речь, музыка, речь на фоне различного шума и т.д. Оценки интерпретируют следующим образом:
4-5 - высокое качество; аналогично качеству передачи речи в ISDN, или еще выше;
3.5-4- качество ТфОП (toll quality); аналогично качеству речи, передаваемой с помощью кодека АДИКМ при скорости 32 Кбит/с. Такое качество обычно обеспечивается в большинстве телефонных разговоров. Мобильные сети обеспечивают качество чуть ниже toll quality;
3-3.5- качество речи, по-прежнему, удовлетворительно, однако его ухудшение явно заметно на слух;
2.5-3 - речь разборчива, однако требует концентрации внимания для понимания. Такое качество обычно обеспечивается в системах связи специального применения (например, в вооруженных силах).
В рамках существующих технологий качество ТфОП (toll quality) невозможно обеспечить при скоростях менее 5 Кбит/с.
Подавление периодов молчания (VAD, CNG, DTX)
При диалоге один его участник говорит, в среднем, только 35 процентов времени. Таким образом, если применить алгоритмы, которые позволяют уменьшить объем информации, передаваемой в периоды молчания, то можно значительно сузить необходимую полосу пропускания. В двустороннем разговоре такие меры позволяют достичь сокращения объема передаваемой информации до 50%, а в децентрализованных многоадресных конференциях (за счет большего количества говорящих) - и более. Нет никакого смысла организовывать многоадресные конференции с числом участников больше 5-6, не подавляя периоды молчания. Технология подавления таких периодов имеет три важные составляющие.
Нужно отметить, что определение границ пауз в речи очень существенно для эффективной синхронизации передающей и приемной сторон: приемник может, незначительно изменяя длительности пауз, производить подстройку скорости воспроизведения для каждого отдельного сеанса связи, что исключает необходимость синхронизации тактовых генераторов всех элементов сети, как это имеет место в ТфОП.
Детектор речевой активности (Voice Activity Detector - VAD) необходим для определения периодов времени, когда пользователь говорит. Детектор VAD должен обладать малым временем реакции, чтобы не допускать потерь начальных слов и не упускать бесполезные фрагменты молчания в конце предложений; в то же время детектор VAD не должен срабатывать от воздействия фонового шума.
Детектор VAD оценивает энергию входного сигнала и, если она превышает некоторый порог, активизирует передачу. Если бы детектор отбрасывал всю информацию до момента, пока энергия сигнала не стала выше порога, то происходило бы отрезание начальной части периода активности. Поэтому реализации VAD требуют сохранения в памяти нескольких миллисекунд информации, чтобы иметь возможность запустить передачу до начала периода активности. Это увеличивает, в некоторой степени, задержку прохождения сигнала, однако ее можно минимизировать или свести к нулю в кодерах, работающих с блоками отсчетов.
Поддержка прерывистой передачи (Discontinuous Transmission - DTX) позволяет кодеку прекратить передачу пакетов в тот момент, когда VAD обнаружил период молчания. Некоторые наиболее совершенные кодеры не прекращают передачу полностью, а переходят в режим передачи гораздо меньшего объема информации (интенсивность, спектральные характеристики), нужной для того, чтобы декодер на удаленном конце мог восстановить фоновый шум.
Генератор комфортного шума (Comfort Noise Generator - CNG) служит для генерации фонового шума. В момент, когда в речи активного участника беседы начинается период молчания, терминалы слушающих могут просто отключить воспроизведение звука. Однако это было бы неразумно. Если в трубке возникает «гробовая тишина», т.е. фоновый шум (шум улицы и т.д.), который был слышен во время разговора, внезапно исчезает, то слушающему кажется, что соединение по каким- то причинам нарушилось, и он обычно начинает спрашивать, слышит ли его собеседник.
Генератор CNG позволяет избежать таких неприятных эффектов. Простейшие кодеки просто прекращают передачу в период молчания, и декодер генерирует какой-либо шум с уровнем, равным минимальному уровню, отмеченному в период речевой активности. Более совершенные кодеки (G.723.1 Annex A, G. 729 Annex В) имеют возможность предоставлять удаленному декодеру информацию для восстановления шума с параметрами, близкими к фактически наблюдавшимся.
Размер кадра
Большинство узкополосных кодеков обрабатывает речевую информацию блоками, называемыми кадрами (frames), и им необходимо производить предварительный анализ отсчетов, следующих непосредственно за отсчетами в блоке, который они в данный момент кодируют.
Размер кадра важен, так как минимальная теоретически достижимая задержка передачи информации (алгоритмическая задержка) определяется суммой этого параметра и длины буфера предварительного анализа. В действительности процессоры цифровой обработки сигналов, которые выполняют алгоритм кодирования, имеют конечную производительность, так что реальная задержка сигнала больше теоретической.
Можно, казалось бы, заключить, что кодеки с меньшим размером кадра лучше в смысле такого важного критерия как минимизация задержки. Если, однако, учесть, что происходит при передаче информации по сети, то мы увидим, что к кадру, сформированному кодеком, добавляется множество дополнительной информации - заголовки IP (20 байтов), UDP (8 байтов), RTP (12 байтов). Для кодека с длительностью кадра 30 мс посылка таких кадров по сети привела бы к передаче избыточной информации со скоростью 10.6 кбит/с, что превышает скорость передачи речевой информации у большинства узкополосных кодеков.
Поэтому обычно используется пересылка нескольких кадров в пакете, при этом их количество ограничено максимально допустимой задержкой. В большинстве случаев в одном пакете передается до 60 мс речевой информации. Чем меньше длительность кадра, тем больше кадров приходится упаковывать в один пакет, т.е. задержка определяется вовсе не длиной кадра, а практически приемлемым объемом полезной нагрузки в пакете.
Кроме того, кодеки с большей длиной кадра более эффективны, так как здесь действует общий принцип: чем дольше наблюдается явление (речевой сигнал), тем лучше оно может быть смоделировано.
Чувствительность к потерям кадров
Потери пакетов являются неотъемлемым атрибутом IP-сетей. Так как пакеты содержат кадры, сформированные кодеком, то это вызывает потери кадров. Но потери пакетов и потери кадров не обязательно напрямую связаны между собой, так как существуют подходы (такие как применение кодов с исправлением ошибок -forward error correction), позволяющие уменьшить число потерянных кадров при данном числе потерянных пакетов. Требующаяся для этого дополнительная служебная информация распределяется между несколькими пакетами, так что при потере некоторого числа пакетов кадры могут быть восстановлены.
Однако положительный эффект от введения избыточности для борьбы с потерями пакетов не столь легко достижим, поскольку потери в IP-сетях происходят пачками, т.е. значительно более вероятно то, что будет потеряно сразу несколько пакетов подряд, чем то, что потерянные пакеты распределятся в последовательности переданных пакетов по одному. Так что если применять простые схемы введения избыточности (например, повторяя каждый кадр в двух последовательно передаваемых пакетах), то в реальных условиях они, хотя и увеличат объем избыточной информации, но, скорее всего, окажутся бесполезными.
Кроме того, введение избыточности отрицательно сказывается на задержке воспроизведения сигнала. Например, если мы повторяем один и тот же кадр в четырех пакетах подряд, чтобы обеспечить возможность восстановления информации при потере трех подряд переданных пакетов, то декодер вынужден поддерживать буфер из четырех пакетов, что вносит значительную дополнительную задержку воспроизведения.
Влияние потерь кадров на качество воспроизводимой речи зависит от используемого кодека. Если потерян кадр, состоящий из N речевых отсчетов кодека G.711, то на приемном конце будет отмечен пропуск звукового фрагмента длительностью М*125 мкс. Если используется более совершенный узкополосный кодек, то потеря одного кадра может сказаться на воспроизведении нескольких следующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером - потеря кадра длительностью 20 мс может приводить к слышимому эффекту в течение 150 мс и более.
Кодеры типа G.723.1 разработаны так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качество ухудшается катастрофически.
