Как работает кодек g 729

Обновлено: 06.07.2024

Компоненты H.323. Рекомендация ITU-T G.729

Рекомендация ITU-T G.729 - это CS-ACELP вокодер (Conjugate-structure Algebraic-code-excited Linear-Prediction). Алгоритм основан на модели кодирования с использованием линейного предсказания с возбуждением по алгебраической кодовой книге (CELP-модель). Кодер оперирует с кадрами речевого сигнала длиной 10мс, дискретизованными с частотой 8КГц, что соответствует 80 16-битным отсчетам в линейном законе. Для каждого кадра производится анализ речевого сигнала и выделяются параметры модели (коэффициенты фильтра линейного предсказания, индексы и коэффициенты усиления в адаптивной и фиксированной кодовых книгах). Далее эти параметры кодируются и передаются в канал.

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

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

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

Вокодер обрабатывает кадры речевых сигналов длиной 10мс. Дополнительно, существует задержка длиной 5мс (look-ahead buffer), что в сумме выливается в алгоритмическую задержку 15мс. Также, задержки речевого сигнала в практическом приложении этого алгоритма определяются временем, затрачиваемым на:

  • процессы кодирования и декодирования;
  • передачу по каналу;
  • мультиплексирование при комбинировании аудиоданных с другими видами данных.

Помимо "чистой" рекомендации G.729, существуют "приложения" (annexes) А и B. Приложение А - версия рекомендации, менее требовательная к вычислительной мощности ЦПОС за счет некоторого ухудшения качества кодирования. Алгоритм теоретически должен потреблять на 40-50% меньше временного ресурса, чем "чистая" G.729. Изменения, в основном, касаются следующих частей алгоритма: поиск периода основного тона и поиск параметров возбуждения по алгебраической кодовой книге. Приложение В добавляет в кодер часть классификации входного речевого сигнала. Это, так называемый, VAD - voice activity detector. Классификатор входного сигнала определяет, что в данный момент присутствует на входе - речь или пауза. В моменты пауз битовый поток понижается с 8 кбит/с до 0.8 кбит/с. Более того, в моменты пауз в битовом потоке передается информация о структуре фонового шума, чтобы на стороне декодера у слушателя не возникало дискомфорта от "чистых" пауз между фразами - т.е. присутствует генератор комфортного шума.

Полное описание рекомендации можно найти в документах (или на сайте ITU):

  • ITU-T Recommendation G.729, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACLEP);
  • ITU-T Recommendation G.729 - Annex A, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACLEP), Annex A: Reduced complexity 8 kbit/s CS-ACELP speech codec;
  • ITU-T Recommendation G.729 - Annex B, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACLEP), Annex B: A silence compression scheme for G.729 optimized for terminals conforming to Recommendation V.70

Многоканальная реализация для ЦПОС семейства TMS320C54x

Алгоритм реализован для ЦПОС семейства TMS320C54x фирмы Texas Instruments.

VoIP


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

Если Вы еще не выбрали VPS/VDS

Список неплохих конфигураций можно найти и заказать тут.

Постоянный контроль доступности вашего сервера

Для контроля на работоспособность вашего сервера используйте следующий сервис ping-admin

Предшествующие статьи из цикла

G711 и G729

G.711 рекомендуемый ITU-T для импульсно-кодовой модуляции голосовых частот. Наиболее часто используемый в телекоммуникационных каналах с шириной в 64кбита. Существует две версии стандарта, μ-law and A-law(вспоминаем как видели в Asterisk ulaw, alaw). A-Law используется в большинстве стран мира, тогда как μ-law в большинстве используется в Северной Америке. ITU-T рекомендует для G.711 использовать 8000 тактов в секунду с отклонением в +50 на миллион. Каждая часть канала квантуется по 8 бит и занимает 64кбита передачи данных. G.711 слабо нагружает системы из-за незначительных(легких) алгоритмов обработки для преобразования голосовых сигналов в цифровой формат, но перегружает сеть за счет малой компрессии данных.

Есть и другие варианты стандарта G.711, такие как G.711.0, в котором описывается схема без потерь на сжатие потока и предназначен он для передачи по IP голосового трафика VoIP. Кроме того, есть еще G.711.1 в котором описываются рекомендации для широкополосной передачи речи и кодирования звука алгоритмом стандарта G.711, который работает на более высоких скоростях передачи данных, такие как 64, 80 и 96 кбит, а так же по умолчанию использует частоту дискретизации в 16000 тактов/секунду.

G.729 — широко используемый тип кодека, скорость 8 Кбит/с. Согласно теории, речевой сигнал длительностью в одну секунду можно полностью описать (то есть оцифровать, передать или сохранить в цифровом виде и затем восстановить в исходный сигнал по цифровому представлению) цифровым потоком 60 байт/сек. Идея оцифровывать и передавать (или сохранять) в цифровом виде не сам сигнал, а его параметр (количество переходов через ноль, спектральные характеристики и др.), чтобы затем по этим параметрам выбирать модель голосового тракта и синтезировать исходный сигнал, лежит в основе «вокодеров» (VOice CODER) или «синтезирующих кодеков».
Для всех типов кодеков справедливо правило: чем меньше плотность цифрового потока, тем больше восстановленный сигнал отличается от оригинала. Однако восстановленный сигнал гибридных кодеков обладает вполне высокими характеристиками, восстанавливается тембр речевого сигнала, его динамические характеристики, другими словами, его «узнаваемость» и «распознаваемость».
Алгоритм основан на модели кодирования с использованием линейного предсказания с возбуждением по алгебраической кодовой книге (CELP-модель). Кодер оперирует с кадрами речевого сигнала длиной 10 мс, дискретизованными с частотой 8 КГц, что соответствует 80-ти 16-битным отсчётам в линейном законе. Для каждого кадра производится анализ речевого сигнала и выделяются параметры модели (коэффициенты фильтра линейного предсказания, индексы и коэффициенты усиления в адаптивной и фиксированной кодовых книгах). Далее эти параметры кодируются и передаются в канал.
В декодере битовая посылка используется для восстановления параметров сигнала возбуждения и коэффициентов синтезирующего фильтра. Речь восстанавливается путём пропускания сигнала возбуждения через кратковременный синтезирующий фильтр.
Подробнее G729

Так в чем же все-таки разница между G711 и G729?

  • Оба алгоритма кодирования используются в коммуникациях и стандартизированы организацией ITU-T.
  • Оба использует 8000 тактов в секунду на считывание сигнала используя теорию Частота Найквиста, используя ширину канала в 64кбит/сек для G.711 и 8кбит/сек для G.729.
  • Концепт G.711 был впервые предложен в 1970х годах Bell Systems и стандартизирован в 1988 году, тогда как G.729 стандартизирован в 1996 году.
  • G.729 использует специальные алгоритмы сжатия для уменьшения затрат на ширину передачи данных, в то время как G.711 требует низкой вычислительной мощности, по сравнению с G.729, благодаря простому алгоритму кодирования.
  • Оба алгоритма имеют свои расширенные версии с небольшими вариациями.
  • Не смотря на то что G.729 обеспечивает более низкий обьем передаваемых данных, требуется обратить внимание на вопросы лицензии. Из слов Википедии:
    -----------------------
    G.729 включает программные патенты от нескольких компаний и лицензировано от имени Sipro Lab Telecom. Sipro Lab Telecom является авторизованным представителем прав на G.729 технологию и патентный портфель.[2][3][4][5] В ряде стран, при использовании G.729 может потребоваться плата за лицензию и/или роялти сбор.[4]. В России кодек G.729 полностью бесплатен.
    ------------------------
  • Исходя из вышеперечисленного получилось так что G.711 поддерживается большим количеством устройств и системы на его основе проще использовать.

Заключение

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

В ходе изучения материалов к экзамену CCNA Voice родилась идея оформить некоторую полученную информацию в виде отдельной статьи. Преследуя при этом две цели: одна корыстная — получше самому разобраться в изучаемом материале и разложить всё по полочкам в своём сознании; вторая альтруистическая — поделиться полученными знаниями с теми, кому это мало мальски интересно.

В статье поведаю о процессах кодирования голоса, кодеках как таковых и расчётах полосы пропускания, необходимой для передачи голоса в IP-сетях

Про основной цифровой сигнал

Думаю, не стоит объяснять что, для передачи аналогового сигнала (коим является голос человека) по IP-сетям, необходимо этот самый сигнал преобразовать в последовательность единиц и нулей. Как это делается, прекрасно объяснил пользователь denis_g в своей многим понравившейся статье. Дабы не сойти за плагиатора и дабы не дублировать информацию, я просто оставлю это здесь. Вкратце суть такова — исходя из теоремы Котельникова (буржуи зовут её теоремой Найквиста) при использовании импульсно-кодовой модуляции для передачи голосового сигнала без потери качества достаточно передавать данные со скоростью 64 kbit/сек.
64 килобита в секунду — это то, что в современной цифровой телефонии называется основным цифровым сигналом.

На 32-х (30 голосовых + 2 служебных) основных цифровых сигналах построен первичный (самый маленький, простой) уровень в плезиосинхронной (почти синхронной) цифровой иерархии (PDH) — т.н. поток E1 (2048 кбит/сек). А сам основной цифровой сигнал порой называют нулевым уровнем. Стоит отметить, что в PDH существует второй (E2), третий (E3) и четвёртый (E4) уровни. Каждый последующий уровень мультиплексируется из четырёх предыдущих с добавлением кое-какой служебной информации, например E3=4*E2+сигнализация.

На смену технологии PDH пришла SDH (синхронная цифровая иерархия), которая и по сей день остаётся основным вариантом организации связи у сотовых операторов, да и сети наших двух магистральных провайдеров (ТТК, РТК) до сих пор основаны на SDH.

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

Ага, отвлёкся. Вернёмся таки к IP-телефонии, то бишь к коммутации пакетов, а про коммутацию каналов пока забудем.

Про кодеки

Итак, у нас с вами есть первичный цифровой канал воплощением которого в IP-сетях стал кодек G.711. Этот стандарт стал де-факто самым популярным и нынче используется в таких протоколах как SIP и SCCP. Он использует полосу пропускания в 64 кбит/секунду и наверное знаком всем, кто имеет дело с современной IP-телефонией.
Стандарт был разработан в 70-х годах прошлого столетия и в данный момент срок патента на него истёк, и он является народным достоянием.
В стандарте описано два алгоритма кодирования — Mu-law (используется в Северной Америке и Японии) и A-law (используется в Европе и в остальном мире). Оба алгоритма являются логарифмическими, но более поздний a-law был изначально предназначен для компьютерной обработки процессов. (с) Wikipedia

Помимо общепризнанного G.711 существует ещё масса стандартов для кодирования\декодирования аудиосигналов. Наиболее популярными из них являются G.729, G.729a, G.726, G.728. Если оценивать их по занимаемой полосе пропускания, то увидим следующую картину:

G.729 — 8 кбит/сек
G.729а — 8 кбит/сек
G.726 — 32 кбит/сек
G.728 — 16 кбит/сек

Казалось бы, если они используют меньшую полосу, то почему не стали популярнее G.711? Дело в том, что полоса пропускания — не самый важный параметр кодека, важна ещё и скорость работы, и как следствие — загрузка DSP (Digital Signal Processor) — цифровго сигнального процессора, который в реальном времени отвечает за кодирование/декодирования сигнала.
Ещё одним немаловажным критерием определяющим успешность того или иного кодека является т.н. MOS (Mean Opinion Score, в русской литературе встречается как усреднённая субъективная оценка). Идея MOS очень проста: специально сформированной группе людей предоставляют возможность воспользоваться системой связи и просят поставить оценку от 1 (ужасно) до 5 (отлично). Усредненные данные такого исследования и называются MOS.

Так вот, для указанных мною кодеков оценки MOS имеют следующие значения:

G.711 — 4,1 (по некоторым источникам 4,45 для Мю-закона)
G.729 — 3, 92 (возможно бы и потягался с G.711, да вот процессорного времени много сжирает)
G.729а — 3,7 (этот кодек работает гораздо быстрее своего старшего брата, но как видим — в ущерб качества)
G.726 — 3,85
G.728 — 3,61

И вот совокупность всех этих факторов (пропускная способность, скорость работы, MOS) определяет главенство того или иного кодека в царстве цифрового кодирования сигналов.

К слову сказать, все эти стандарты (ну которые начинаются на G.) являются плодами деятельности международного консультационного комитета по телефонии и телеграфии (подразделения ITU — международного союза электросвязи) и по сути дела являются проприетарными. А в наше время сложно представить отсутствие свободных альтернатив у проприетраных стандартов. Так и в сфере кодирования аудиосигналов родился стандарт iLBC (internet Low Bitrate Codec), который использует15,2 Кбит/секунду и имеет оценку MOS 4,1. Именно эти факторы наряду с открытостью оказали влияние на то, что данный стандарт используется в Google talk, Yahoo messenger и всем нами любимом Skype.

Стоит отметить, что популярные IP-АТС (asterisk, cisco CME) поддерживают все эти кодеки, и вы всегда вправе сами определить, что будете использовать в вашей телефонной сети.

Про полосу пропускания

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

Немаловажным параметром в данном частном случае является размер сэмпла (измеряется в миллисекундах). Размер сэмпла это тот параметр который определяет «количество» голосовой информации в IP-пакете — например, в один и тот же стандартных размеров пакет вы можете запихать один слог или два. Чем больше размер сэмпла, тем экономнее вы расходуете свою пропускную способность, но тем больше в разговоре будет слышна задержка (следствие работы цифрового процессора по кодированию/раскодированию).

Не знаю как в Asterisk (надеюсь кто-нибудь подскажет), но в Cisco CME (решение от Cisco в области IP-телефонии) при настройке параметров кодека к сожалению нет такого параметра — размер сэмпла, зато есть параметр, определяющий количество байт в сэмпле. Они друг с другом связаны простой формулой (линейная зависимость), и легко выражаются друг через друга. А вот и формула:

БвС = РС*ППК/8, где БвС — количество байт в сэмпле, РС — размер сэмпла в секундах, ППК — пропускания кодека в битах/сек. То есть если мы хотим чтобы при использовании кодека G.711 в одном пакете было, к примеру, 20 милисекунду разговора, то нам необходимо выставить значение параметра БвС=0,02*64000/8=160

Таким образом нам в наш UDP-фрагмент необходимо заложить 160 байт полезной информации. Ок, идём дальше.

Допустим мы используем классическую IP сеть, канальным протоколом для которой является Ethernet, плюс хотим это всё гонять в шифрованной сети VPN. Тогда к нашим 160 байтам добавятся ещё 18 байт служебной информации Ethernet. Добавляем сюда сетевой и транспортный уровень — заголовки IP, UDP и RTP (20+8+12 байт). И заворачиваем всё наше добро в IPSec — ещё плюс 50 байт. На выходе имеем пакет размером 268 байт.

Чтобы вычислить итоговую полосу пропускания нам необходимо умножить размер этого пакета на количество пакетов в секунду. С учётом того, что размер нашего сэмпла — 20 мс, то в одну секунду таких сэмплов будет 50. Умножая 50 на 268 видим что за одну секунду нам надо гонять 13400 байт или 107200 бит в секунду, то есть 107, 2 Кбита в секунду. А это уже почти в два раза больше чем изначальные 64 килобита! Именно из этого числа необходимо исходить при планировании своей сети.

В этом документе содержится обзор различных кодеков, используемых со шлюзами Cisco IOS® Voice over IP (VoIP). В релизах программного обеспечения Cisco IOS ранее 12.0(5)T шлюзы VoIP поддерживают только кодеки G.729 и G.711 и только один вызов передачи голосовых/факсимильных данных на цифровой процессор обработки сигналов (DSP). Начиная с релиза 12.0(5)T программного обеспечения Cisco IOS шлюзы Cisco VoIP поддерживают большое число кодеков и модулей DSP. Они могут поддерживать до четырех вызовов передачи голосовых/факсимильных данных на один DSP.

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты.

Данный документ не ограничен отдельными версиями программного и аппаратного обеспечения.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. в разделе Технические советы Cisco. Условные обозначения.

Сложность кодека

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

Средняя сложность разрешает C549 DSP обрабатывать до четырех вызовов передачи голосовых/факсимильных данных на DSP, а C5510 DSP - до восьми таких вызовов.

Средняя сложность разрешает C549 DSP обрабатывать до двух вызовов передачи голосовых/факсимильных данных на DSP, а C5510 DSP - до шести таких вызовов.

Средняя сложность (4 вызова на dsp)

Высокая сложность (2 вызова на dsp)

G.711 (a-law и m -law)

G.726 (все версии)

G.723 (все версии)

G.729a, G.729ab (G.729a AnnexB)

G.729, G.729b (G.729-AnnexB)

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

Примечание: ретранслятор факса (2400 бит/с, 4800 бит/с, 7200 бит/с, 9600 бит/с, 12 кбит/с и 14,4 кбит/с) может использовать кодеки средней и высокой сложности.

На платформах, поддерживающих технологию C549 DSP, сложность кодека настраивается по голосовым платам (например, модуль голосовой сети с высокой плотностью 2600/3600/VG-200). Некоторые платформы поддерживают только кодеки высокой сложности, поскольку у них есть достаточно встроенных DSP для поддержки всех каналов T1/E1, которые используют режим высокой сложности. Чтобы указать плотность вызова и сложность кодека в соответствии с используемым стандартом кодека, примените команду codec complexity в режиме настройки голосовой платы.

Пример настройки сложности приведен ниже:

На платформах, которые поддерживают технологию C5510 DSP, доступен дополнительный параметр настраиваемой сложности. При использовании настраиваемой сложности на DSP могут быть разрешены до 16 вызовов. Число поддерживаемых вызовов колеблется от 6 до 16 и зависит от используемого для вызовов кодека.

Пример настройки приведен ниже:

Фрагмент выходных данных команды show running-config, которая определяет конфигурацию сложности:

В этой таблице приведены данные о поддержке кодеков для различных платформ маршрутизаторов Cisco.

G.711 a-law и u-law PCM (64 кбит/с)

G.726 ADPCM (32, 24,16 кбит/с)

G.728 LD-CELP (16 кбит/с)

G.729 CS-ACELP (8 кбит/с)

G.729a CS-ACELP (8 кбит/с)

G.729 Annex-B (8 кбит/с) [VAD]

G.729a Annex-B (8 кбит/с)

G.723.1 MP-MLQ (6.3 кбит/с)

G.723.1 ACELP (5,3 кбит/с)

G.723.1 Annex-A MP-MLQ (6,3 кбит/с)

G.723.1 Annex-A ACELP (5,3 кбит/с)

Метод сжатия кодека

PCM = Pulse Code Modulation

ADPCM = Adaptive Differential Pulse Code Modulation

LDCELP = Low-Delay Code Excited Linear Prediction

CS-ACLEP = Conjugate-Structure Algebraic-Code-Excited Linear-Prediction

MP-MLQ = Multi-Pulse, Multi-Level Quantization

ACELP = Algebraic Code Excited Linear Prediction

Codec Mean Opinion Score (MOS)

Каждый кодек обеспечивает определенное качество речи. Качество передачи речи - это субъективная оценка слушателя. Типичным способом определения качества звука, производимого определенными кодеками, является MOS. При использовании MOS большая группа разных слушателей оценивает качество звука в примере (связанном с отдельным кодеком) по шкале от 1 (плохое) до 5 (отличное). Данные усреднены, чтобы получить MOS для этого примера. Данная таблица содержит связи между кодеками и оценками по MOS.

Задержка сжатия (мс)

G.729 x 2 кодировки

G.729 x 3 кодировки

Хотя с финансовой точки зрения выглядит логичным конвертировать все вызовы в низкоскоростные кодеки, что снизит инфраструктурные затраты, построение голосовых сетей с низкоскоростным сжатием требует особого внимания. У технологии сжатия речевого сигнала есть свои недостатки. Один из основных недостатков – искажение сигнала из-за многократного кодирования (оно называется тандемным перекодированием). Например, когда голосовой сигнал G.729 тандемно перекодируется три раза, его очки по MOS падают с 3.92 (очень хорошо) до 2.68 (неприемлемо). Другой недостаток – это вызываемая кодеком задержка с кодеками с низкой скоростью передачей данных.

Вопросы, связанные с кодеком G.729

В этих двух главах разъясняются основные проблемы совместимости, связанные с реализацией кодека G.729 (8 кбит/с).

Cisco Pre-IETF G.729 и стандартизированная реализация G.729

Компания Cisco выпустила релиз кодека G.729 до утверждения его Комитетом по проблемам проектирования Интернета (IETF) и до формирования стандарта кодека G.729. В релизе Cisco IOS 12.0(5)T и более поздних порядок битов по умолчанию кодека G.729 изменился от стандарта Pre-IETF до утвержденного IETF стандарта. Эти два формата несовместимы, что для конечного пользователя выливается в искаженные булькающие звуки.

Для обеспечения совместимости с реализациями G.729 других поставщиков программное обеспечение Cisco IOS, релиз 12.0.5T и более поздние по умолчанию применяют стандартную реализацию G.729. Для обратной совместимости с релизами программного обеспечения Cisco IOS, выпущенными ранее релиза 12.0.5T, следует использовать реализацию pre-IETF G.729 с такой командой:

Параметр pre-ietf в этой команде не поддерживается в релизе 12.2 программного обеспечения Cisco IOS и более поздних.

Высокая сложность: G.729, G.729A Annex-B и средняя сложность: G.729A, G.729A Annex-B

G.729 – это алгоритм высокой сложности, а G.729A (также известный как G.729 Annex-A) – среднесложный вариант, отличающийся от G.729 чуть более низким качеством передачи голоса. Все платформы, которые поддерживают G.729, также поддерживают и G.729A.

В шлюзах Cisco IOS выбор между G.729 и G.729A связан с настройкой сложности кодека на голосовой плате. Она точно не показывает выбор кодека на интерфейсе командной строки (CLI) Cisco IOS. Например, CLI не показывает g729ar8 (код "a") как параметр кодека. Однако если голосовая плата определена как среднесложная, то параметр g729r8 означает кодек G.729A.

Примечание: для MC3810 в программном обеспечении Cisco IOS релизов ранее 12.0.7XK существует точный выбор CLI между 24-мя каналами G.729A или 12-ю каналами G.729.

G.729 Annex-B – это алгоритм высокой сложности, а G.729A Annex-B – среднесложный вариант, отличающийся от G.729 Annex-B чуть более низким качеством передачи голоса. Различие между кодеками G.729 и G.729 Annex-B состоит в том, что кодек G.729 Annex-B имеет встроенную возможность обнаружения голосовой активности IETF (VAD) и генерации комфортного шума (CNG).

В данных комбинациях кодеки G.729 являются совместимыми:

G.729 Annex-B и G.729A Annex-B

G.729 Annex-B и G.729 Annex-B

G.729A Annex-B и G.729A Annex-B

Примечание: нет четкого способа настройки G.729A на Cisco 2600/3600/VG-200 NM-1V и NM-2V (сетевой модуль передачи голоса), так как эти модули передачи голоса не поддерживают настройку codec complexity, которая поддерживается на NM-HDV (сетевом модуле высокоплотной передачи голоса). Однако если вызов G.729A делается другой конечной точкой подключения, которая заканчивается на NM-1V/2V, он может быть успешно соединен.

Проблемы с кодеком G.723.1

Эти две версии G.723.1 называются Annex-A и non Annex-A. Они несовместимы. G.723.1 Annex-A включает встроенный алгоритм IETF VAD и CNG.

Кроме того, в программное обеспечении Cisco IOS, релиз 12.0(5)T и более поздние, кодек G.723.1 поддерживается со скоростями 5,3 кбит/с и 6,3 кбит/с. Когда шлюз Cisco VoIP делает вызов между устройствами, которые используют G723.1, предполагается только, что на дальнем конце также используется G.723.1. Ни для одной из сторон не важно, какую скорость, 5,3 кбит/с или 6,3 кбит/с, поддерживает другая сторона. Это означает, что хотя поддержка обеими сторонами одной и той же скорости является преимуществом, возможно, что одна сторона будет вести передачу на скорости 5,3 кбит/с, а в обратной направлении скорость составит 6,3 кбит/с. Об используемой скорости можно узнать с помощью команды show call active voice brief , как показано ниже:

Стандарт G.723.1 позволяет станциям менять скорости в диапазоне между 6,3 кбит/с и 5,3 кбит/с в целях оптимизации загрузки сети. Шлюзы Cisco VoIP не поддерживают эту возможность. Но они нормально воспримут передачу удаленным устройством (таким, как IP-телефон Cisco) данных на скорости, отличной от заранее определенной.

В данных комбинациях кодеки G.723.1 являются совместимыми:

G.723.1 (5,3 кбит/с) и G.723.1 (6,3 кбит/с)

G.723.1 (5,3 кбит/с) и G.723.1 (5,3 кбит/с)

G.723.1 (6,3 кбит/с) и G.723.1 (6,3 кбит/с)

G.723.1 Annex-A (5,3 кбит/с) и G.723.1 Annex-A (6,3 кбит/с)

G.723.1 Annex-A (5,3 кбит/с) и G.723.1 Annex-A (5,3 кбит/с)

G.723.1 Annex-A (6,3 кбит/с) и G.723.1 Annex-A (6,3 кбит/с)

Согласование кодеков

Начиная с релиза 12.0(5)T программного обеспечения Cisco IOS шлюзы Cisco VoIP поддерживают функцию согласования кодеков. Эта функция предоставляет шлюзу Cisco VoIP возможность подключаться к другим устройствам VoIP без необходимости знать, какой кодек используется для установления вызова. Кроме того, с помощью этой функции шлюзы Cisco VoIP могут динамически изменять настройки в соответствии с изменениями на удаленных устройствах. Если кодек, используемый удаленным устройством VoIP, входит в список совместимых для шлюза Cisco VoIP, вызов VoIP принимается. Согласование кодека поддерживается как на C542 DSP, так и на C549 DSP. Чтобы указать список предпочитаемых кодеков для использования на адресуемой точке вызова, примените команду codec preference в режиме настройки класса голоса.

В этом примере показывается, как настроить согласование кодеков:

%DSPRM-5-SETCODEC:

Ошибка %DSPRM-5-SETCODEC возникает из-за настройки кодека высокой сложности на адресуемой точке вызова VoIP, хотя ее голосовая плата по умолчанию настроена на среднюю сложность. Чтобы разрешить проблему, необходимо удалить конфигурацию ds0-group из контроллера, что вызовет и удаление голосового порта. После удаления ds0-group следуйте ранее описанной в этом документе процедуре для изменения сложности.

Примечание.

Большинство людей отдают предпочтение Asterisk с применением кодека G.729 для замены дорогостоящих шлюзов. В настоящее время Asterisk поддерживает только кодек G.729 Annex A, хотя есть ещё 729b.

Относительно производительности системы: все преобразования кодека G.729 происходят в программном обеспечении, поэтому требуется тщательно взвесить все за и против, когда вы собираете сервер для работы с Asterisk. Тесты компании Digium показывают, что сервер на базе процессора Intel® Xeon 1.8GHz поддерживает до 60 одновременных звонков с использованием кодека G.729. Процессор Dual Xeon 2.8GHz поддерживает до 80 одновременных звонков с G.729.

Кодек G.729 работает со всеми интерфейсными платами Digium и с любыми процессорами.

Напомню, что по умолчанию asterisk использует кодек G711.

Всё нижеописанное проводилось на стенде:

FreeBSD 7.0-RELEASE, Asterisk 1.4.24.1

2) Просмотр информации о кодеках

asterserver*CLI> show codecs
Disclaimer: this command is for informational purposes only.
It does not indicate anything about your configuration.
INT BINARY HEX TYPE NAME DESC
--------------------------------------------------------------------------------
1 (1 << 0) (0x1) audio g723 (G.723.1)
2 (1 << 1) (0x2) audio gsm (GSM)
4 (1 << 2) (0x4) audio ulaw (G.711 u-law)
8 (1 << 3) (0x8) audio alaw (G.711 A-law)
16 (1 << 4) (0x10) audio g726aal2 (G.726 AAL2)
32 (1 << 5) (0x20) audio adpcm (ADPCM)
64 (1 << 6) (0x40) audio slin (16 bit Signed Linear PCM)
128 (1 << 7) (0x80) audio lpc10 (LPC10)
256 (1 << 8) (0x100) audio g729 (G.729A)
512 (1 << 9) (0x200) audio speex (SpeeX)
1024 (1 << 10) (0x400) audio ilbc (iLBC)
2048 (1 << 11) (0x800) audio g726 (G.726 RFC3551)
4096 (1 << 12) (0x1000) audio g722 (G722)
65536 (1 << 16) (0x10000) image jpeg (JPEG image)
131072 (1 << 17) (0x20000) image png (PNG image)
262144 (1 << 18) (0x40000) video h261 (H.261 Video)
524288 (1 << 19) (0x80000) video h263 (H.263 Video)
1048576 (1 << 20) (0x100000) video h263p (H.263+ Video)
2097152 (1 << 21) (0x200000) video h264 (H.264 Video)

А теперь посмотрим, установлен ли кодек:

asterserver*CLI> core show translation
Translation times between formats (in milliseconds) for one second of data
Source Format (Rows) Destination Format (Columns)
g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
g723 - - - - - - - - - - - - -
gsm - - 2 2 2 2 1 2 - 14 12 2 -
ulaw - 2 - 1 2 2 1 2 - 14 12 2 -
alaw - 2 1 - 2 2 1 2 - 14 12 2 -
g726aal2 - 2 2 2 - 2 1 2 - 14 12 1 -
adpcm - 2 2 2 2 - 1 2 - 14 12 2 -
slin - 1 1 1 1 1 - 1 - 13 11 1 -
lpc10 - 2 2 2 2 2 1 - - 14 12 2 -
g729 - - - - - - - - - - - - -
speex - 3 3 3 3 3 2 3 - - 13 3 -
ilbc - 12 12 12 12 12 11 12 - 24 - 12 -
g726 - 2 2 2 1 2 1 2 - 14 12 - -
g722 - - - - - - - - - - - - -

минусы напротив кодека значат, что не установлен.

А можно просто глянуть на наличие файла codec_g729.so в библиотеке с модулями (по умолчанию это либо /usr/lib/asterisk/modules, /usr/local/lib/asterisk/modules, /var/lib/asterisk/modules).

asterserver*CLI> show modules like 729
Module Description Use Count
format_g729.so Raw G729 data 0
1 modules loaded

3) Установка кодека.

asterserver*CLI> module load codec_g729.so

== Registered translator 'g729tolin' from format g729 to slin, cost 1
== Registered translator 'lintog729' from format slin to g729, cost 4
Loaded codec_g729.so => (g729 Coder/Decoder, based on IPP)

asterserver*CLI> show modules like 729
Module Description Use Count
format_g729.so Raw G729 data 0
codec_g729.so g729 Coder/Decoder, based on IPP 5
2 modules loaded
asterserver*CLI> core show translation
Translation times between formats (in milliseconds) for one second of data
Source Format (Rows) Destination Format (Columns)
g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
g723 - - - - - - - - - - - - -
gsm - - 2 2 2 2 1 2 5 14 12 2 -
ulaw - 2 - 1 2 2 1 2 5 14 12 2 -
alaw - 2 1 - 2 2 1 2 5 14 12 2 -
g726aal2 - 2 2 2 - 2 1 2 5 14 12 1 -
adpcm - 2 2 2 2 - 1 2 5 14 12 2 -
slin - 1 1 1 1 1 - 1 4 13 11 1 -
lpc10 - 2 2 2 2 2 1 - 5 14 12 2 -
g729 - 2 2 2 2 2 1 2 - 14 12 2 -
speex - 3 3 3 3 3 2 3 6 - 13 3 -
ilbc - 12 12 12 12 12 11 12 15 24 - 12 -
g726 - 2 2 2 1 2 1 2 5 14 12 - -
g722 - - - - - - - - - - - - -

4) Использование кодека.

Для того, что бы определённый peer мог использовать этот кодек, нужно его добавить в разрешающие в настройках sip-аккаунта в файле sip.conf (можно так же добавить и в секцию [general] ):

[1111]
type=peer
host=x.x.x.x
port=5060
disallow=all
allow=g729
allow=gsm
allow=ulaw
allow=alaw

Этими настройками мы установили доступные для использования кодеки и их приоритеты: выше, значит первый. Эту же информацию можна получить и через команду (привожу не весь вывод команды, а только ту часть, которая касается кодеков)

asterserver*CLI> sip show peer 1111
.
Codecs : 0x10e (gsm|ulaw|alaw|g729)
Codec Order : (g729|gsm|ulaw|alaw)
.

После этого перечитываем конфиг sip.conf и пробуем звонить. Для того, что бы удостовериться, что кодек действительно работает, можно, например, разрешить пиру использовать только его.

Так же можно проверять и во время звонка, какой кодеки достуны для использования:

asterserver*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message
10.0.52.16 75206 001bd4a0-35 00101/00102 (None) No Rx: ACK
XX.XX.XX.XX 3809569429 20abc7a85b2 00102/00000 (g729) No Init: INVITE
10.0.52.17 75207 001bd47d-54 00101/00102 (ulaw|alaw) No Rx: INVITE
XX.XX.XX.XX 3803548215 2baa3656262 00102/00000 (g729) No Tx: ACK
10.0.52.12 75203 002155d5-6c 00101/00102 (ulaw|alaw) No Rx: ACK
XX.XX.XX.XX 3803126694 0f7a8fe514a 00102/00000 (g729) No Tx: ACK
10.0.52.11 75202 001e4af2-a9 00101/00102 (ulaw|alaw) No Rx: ACK
7 active SIP channels

5) Возможные проблемы.

Как вариант, можно в настройках пира либо прописать dtmfmode=info/auto, либо вообще заккоментировать dtmfmode. Некоторые пишут, что им помогла опция rfc2833compensate=yes в файле sip_general_custom.conf

Значит, что кодек собран не для вашей ОС или процессора.

6) Дополнения.

Теперь пару слов о поддержке этого кодека аппаратами cisco 7911. Мне так и не удалось заставить его работать с этим кодеком, хотя в прошивке его явно указано использовать этот кодек:

<preferredCodec>g729a</preferredCodec>

Видимо это баг, но информации об этом вообще нет.

Используем кодек G729 в asterisk. : 4 комментария

Читайте также: