Внедрение IP-телефонии на базе продуктовой линейки D-Link

Речевые кодеки для IP-телефонии

Особенности функционирования каналов для передачи речевых данных, и прежде всего сети Интернет, а также возможные варианты построения систем телефонной связи на базе сети Интернет предъявляют ряд специфических требований к речевым кодекам (вокодерам). В силу пакетного принципа передачи и коммутации речевых данных отпадает необходимость кодирования и синхронной передачи одинаковых по длительности фрагментов речи. Наиболее целесообразным и естественным для систем IP-телефонии является применение кодеков с переменной скоростью кодирования речевого сигнала. В основе кодека речи с переменной скоростью лежит классификатор входного сигнала, определяющий степень его информативности и, таким образом, задающий метод кодирования и скорость передачи речевых данных. Наиболее простым классификатором речевого сигнала является Voice Activity Detector (VAD), который выделяет во входном речевом сигнале активную речь и паузы. При этом фрагменты сигнала, классифицируемые как активная речь, кодируются каким-либо из известных алгоритмов (как правило, на базе метода Code Excited Linear Prediction - CELP) с типичной скоростью 4-8 кбит/с. Фрагменты, классифицированные как паузы, кодируются и передаются с очень низкой скоростью (порядка 0.1-0.2 кбит/с) либо не передаются вообще. Передача минимальной информации о паузных фрагментах предпочтительна.

Схемы более эффективных классификаторов входного сигнала классификацию фрагментов, соответствующих активной речи, осуществляют детальнее. Это позволяет оптимизировать выбор стратегии кодирования (скорости передачи данных), выделяя для особо ответственных за качество речи участков речевого сигнала большее число битов (соответственно большую скорость), для менее ответственных - меньше битов (меньшую скорость). При таком построении кодеков могут быть достигнуты низкие и средние скорости (2-4 кбит/с) с высоким качеством синтезируемой речи.

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

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

Таким образом, одной из важнейших задач при построении вокодеров для IP-телефонии является создание алгоритмов компрессии речи, толерантных к потерям пакетов.

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

Насколько можно судить по литературным данным, специальных разработок для интернет-телефонии, рекомендованных ITU-T (сектор стандартизации в области телекоммуникаций международного союза телекоммуникаций), пока не существует. Среди международных стандартов, рекомендуемых для подобных систем, чаще других упоминается G.723.1, обеспечивающий передачу речи со скоростью 5.3 и 6.3 кбит/с, а также G.729 для скорости передачи 8 кбит/с. Следует отметить, что упоминаемый в ранних главах кодек G.711 со скоростью передачи 64 кбит/с следует использовать лишь в коммерческих сетях, когда, как правило, ресурсы канала не ограничены, поскольку данный кодек при неэкономном использовании канала обеспечивает наиболее хорошее качество передаваемого речевого сигнала.

Гарантируя достаточно высокое качество речи в идеальных условиях передачи, упомянутые стандарты были разработаны для использования в каналах, отличных от Интернета, и уже позже частично адаптировались для условий потерь пакетов. Развития этих стандартов включают в себя Voice Activity Detector и элементы, ответственные за синтез речевого сигнала во фрагментах, которые соответствуют потерянным речевым данным.

Архитектура шлюза

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

Более полно основные функции, выполняемые шлюзом при соединении типа "точка-точка", состоят в следующем:

• реализация физического интерфейса с коммуникационной сетью (интерфейсы FXO и FSX);
• детектирование и генерация сигналов абонентской сигнализации;
• преобразование сигналов абонентской сигнализации в пакеты данных и обратно;
• преобразование речевого сигнала в пакеты данных и обратно;
• соединение абонентов;
• передача по сети сигнализационных и речевых пакетов;
• разъединение связи.

Большая часть функций шлюза в рамках архитектуры TCP/IP реализуется в процессах прикладного уровня.

Для ознакомления с работой шлюза воспользуемся следующей схемой ( рис. 11.10).

Рис. 11.10. Архитектура шлюза

Звонки могут без проблем проходить между телефонным аппаратом, подключенным к порту FXS, и абонентами мини-АТС с хорошим качеством. Также возможны звонки абонентам ГАТС (городские АТС), поступающим к номеру ГАТС.

При входящем звонке на порт FXO шлюз (в данном случае VIP-400) выдает непрерывный гудок, после чего можно набрать тоном номер абонента, "прописанного" в номерном плане шлюза (это могут быть телефонные аппараты, подключенные к портам FXO, или NetMeeting).

Сетевые протоколы

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

Как известно, Internet Protocol (IP) является протоколом сетевого уровня, который обеспечивает маршрутизацию пакетов в сети. Он, однако, не гарантирует надежную доставку пакетов. То есть пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит, иметь различное время передачи) и т. д. На основе IP работают также протоколы транспортного уровня TCP и UDP.

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

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

Перед поступлением речевого потока на декодер он должен быть восстановлен. Для этого используется протокол реального времени. В заголовке согласно правилам данного протокола передаются, в частности, временная метка и номер пакета. Эти параметры позволяют определить не только порядок пакетов в потоке, но и момент декодирования каждого пакета, т. е. позволяют восстановить поток. Наиболее распространенный протокол реального времени - RTP, рекомендованный к применению в стандарте на построение систем реального времени H.323.

Искажения потока пакетов связаны с загруженностью сети. При отсутствии перегрузок искажения минимальны, а часто отсутствуют. Поток речевых пакетов может значительно загружать сеть, особенно в случае многоканальных систем. Это происходит из-за высокой интенсивности потока (кадры небольшого размера передаются через малые промежутки времени 20 байтов / 30 мс) и большого объема передаваемой служебной информации. Зная размеры заголовков сетевых протоколов (IP - 20 байтов, UDP - 8 байтов, RTP - 12 байтов), легко вычислить общий объем заголовка речевого пакета - 40 байтов. Это в 2 раза превышает размер самого пакета. Передача такого объема служебной информации неприемлема, особенно при построении многоканальных систем. Таким образом, необходимо искать способы уменьшения количества служебной информации, передаваемой по сети. Существует два возможных варианта решения этой проблемы. Первый предполагает создание специальных транспортных протоколов для IP-телефонии, которые могли бы уменьшить длину заголовка протокола транспортного уровня. Второй вариант - мультиплексирование каналов в многоканальных системах. В этом случае речевые пакеты от разных каналов передаются под одним сетевым заголовком. Такое решение не только уменьшает количество передаваемой служебной информации, но и снижает интенсивность потока.

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