Как найти причину тишины на G.729 в Asterisk

Если звонок на G.729 соединяется, но звука нет, это ещё не доказывает проблему с лицензией или самим кодеком. Я сначала проверяю, какие форматы согласовали обе стороны, умеет ли установленная сборка Asterisk переводить их между собой и идут ли RTP-пакеты в обе стороны. Ниже — порядок проверки и разбор условного случая.

Почему G.729 может дать тишину, но не обязан рвать звонок

G.729 — голосовой кодек с номинальной скоростью 8 кбит/с; в RTP профиль для него описан в RFC 3551. Это скорость кодирования голоса, а не полный расход канала: заголовки IP, UDP и RTP тоже занимают место. Поэтому обещание «всего 8 кбит/с на разговор» без оговорок — арифметика для рекламного буклета. Если экономия полосы действительно важна, сравнивайте полный сетевой расход и качество на своей линии. Для многих офисов разумно сначала проверить, нельзя ли оставить одинаковый кодек на телефоне и у оператора.

Сам факт, что в конфигурации разрешён G.729, не означает, что Asterisk способен кодировать и декодировать его. В документации Asterisk отдельно перечислены поддерживаемые форматы, модули и коммерческая поддержка G.729A; у Sangoma есть инструкция по включению транскодирования для систем с лицензированным программным кодеком или аппаратным транскодером. Это два разных вопроса: согласовать формат для передачи и преобразовать звук из одного формата в другой. Если обе стороны уже говорят на одном кодеке, преобразование может вообще не требоваться.

Я не связываю каждую тишину с лицензией. При несовпадающих кодеках Asterisk должен иметь подходящий путь преобразования; если такого пути нет, вызов может не состояться или медиа не заработает ожидаемым образом. Но потерю RTP, неверный адрес в SDP, NAT, односторонний звук и ошибку на телефоне лицензия не исправляет. Начинайте с признака, который видите: SIP-вызов установлен, но не слышно одну или обе стороны? Это уже сужает поиск. Если нужна помощь с настройкой Asterisk, я проверяю всю цепочку, а не покупаю лицензию наугад.

Разбор случая: что проверять до обвинений провайдера

В условном кейсе ООО «Янтарь» жалоба звучала так: внешний вызов устанавливается, но один сотрудник не слышит собеседника. В исходном описании фигурировали «обрыв каждые 30 секунд», задержки RTP и найденная эмуляция лицензии. Эти детали не подтверждены измерениями, поэтому я не буду выдавать их за причину. Прежде всего фиксирую направление проблемы, время вызова и участников, затем сопоставляю журнал Asterisk с SDP и сетевой записью. Само по себе отсутствие явной SIP-ошибки не подтверждает исправность медиапотока.

При проверке я отдельно смотрю предложения кодеков в SDP обоих плеч вызова. Если внутренний телефон предлагает G.711, а оператор — G.729, нужно выяснить, есть ли у конкретной сборки Asterisk подходящий перевод форматов и допускают ли его параметры согласования. Для PJSIP настройки лежат в pjsip.conf; allow — параметр endpoint, который задаёт разрешённые кодеки, а не универсальная команда «включить транскодер». Для старого chan_sip используется другой драйвер и другой конфигурационный контекст. Смешивать их примеры в одном рецепте — способ получить уверенный конфиг, который никто не проверил.

Дальше проверяю медиа в обе стороны: видит ли Asterisk входящий RTP, куда отправляет исходящий, совпадает ли адрес назначения с доступной сетью, нет ли блокировки на маршруте. При симптоме «слышит только одна сторона» сетевой путь особенно важен. Если звонок действительно завершается через фиксированный интервал, отдельно анализирую SIP-сигнализацию и таймеры; аудиокодек сам по себе не объясняет точный таймер разрыва. Для разбора сигнального плеча полезен материал про ошибки PJSIP-конфигурации.

Какие команды покажут кодеки и путь преобразования

Подключитесь к CLI именно того экземпляра Asterisk, который обслуживает вызов. Команда core show codecs показывает известные системе кодеки; module show помогает увидеть загруженные модули. Если нужно понять, какие преобразования Asterisk зарегистрировал между форматами, используйте core show translation. Это диагностические проверки, а не доказательство того, что конкретный вызов согласовал нужный формат: состояние вызова и SDP всё равно нужно смотреть отдельно. В контейнере важно попасть в правильный контейнер и CLI; не угадывайте имя сервиса по чужой инструкции.

Для активного вызова core show channels полезна как общий обзор каналов, но не как надёжный способ увидеть согласованный кодек: не обещайте себе поля, которого команда может не выводить в вашей версии. Посмотрите SIP/SDP-трассу подходящим для вашего драйвера способом и сопоставьте её с логом. В PJSIP ведите диагностику через средства res_pjsip; точные команды и уровень детализации сверяйте с версией Asterisk. Сохраните небольшой фрагмент одного проблемного вызова, предварительно удалив номера, учётные данные и реальные адреса.

При проверке перечислите факты, а не гипотезы: какие кодеки предложил телефон; какие предложил оператор; какой набор остался после согласования; загружен ли нужный модуль; требуется ли преобразование; идут ли RTP-пакеты на обоих плечах. Если список модулей не показывает возможности перевода, это повод сверить пакетирование и сборку с документацией поставщика, а не искать мифический chan_g729 или выдуманный путь к библиотеке. Для общего понимания настройки стека пригодится руководство по PJSIP в Asterisk.

• Сверьте SDP телефона и оператора.
• Проверьте кодеки через `core show codecs`.
• Проверьте модули командой `module show`.
• Оцените преобразование через `core show translation`.
• Проверьте входящий и исходящий RTP.

Как исправить несовпадение кодеков в PJSIP

Сначала согласуйте с оператором и телефоном общий формат. Если обе стороны поддерживают G.711 и это подходит по полосе, общий G.711 может убрать необходимость в преобразовании именно между этими плечами. Это не обещание «качество станет идеальным» и не гарантия, что исчезнут сетевые потери. Если нужен G.729, проверьте лицензионный и технический вариант у поставщика решения, установку нужных модулей, поддержку сборкой и настройки endpoint. Sangoma документирует включение G.729 для своей лицензированной программной реализации или аппаратного транскодера; это не общее правило, что любой Asterisk без лицензии обязан выдавать тишину.

В PJSIP задавайте допустимые форматы на нужных endpoint и сверяйте итоговую политику согласования с документацией своей версии. Параметр allow определяет разрешённые кодеки. Пример с disallow=all и allow=g729,g711 часто переносят из chan_sip, поэтому я не вставляю его как готовую директиву в pjsip.conf. В документации PJSIP формат задаётся через allow, например allow=!all,g722,ulaw; конкретный синтаксис, порядок и расширенные codec negotiation параметры зависят от версии и сценария. Примените изменение контролируемо и проверьте новый вызов с обеих сторон.

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

Если кодеки согласованы, проверьте RTP и сеть

Если в SDP есть общий кодек и медиа всё равно пропадает, переходите к сетевой части. В PJSIP настройка NAT зависит от топологии: важны внешний адрес для сигнализации и медиа, локальные сети, поведение endpoint за NAT и фактический маршрут RTP. В официальной документации Asterisk приведены параметры транспорта и endpoint для такого случая; директивы nat=yes и externalmediaip из старого текста не являются универсальным рецептом для pjsip.conf. Сверьте параметры с версией и схемой: телефон за NAT, сервер за NAT или оба находятся в разных сегментах — это разные ситуации.

Сравните адрес и порт назначения из SDP с тем, что разрешают межсетевой экран и маршрутизатор, затем подтвердите трафик захватом на обеих сторонах. Номер RTP-порта нельзя брать из случайного примера: диапазон задаётся конфигурацией вашей установки и должен совпадать с правилами сети. Для одной стороны без звука выясните, приходит ли от неё RTP и уходит ли к ней ответный поток. Для обеих сторон без звука проверьте, не объявлен ли в SDP недоступный адрес и не потерян ли медиамаршрут. Здесь точная запись полезнее десяти перезапусков. Перед изменением сделайте снимок текущего SDP или сохраните короткую трассу вызова, чтобы сравнить объявленные адреса и форматы до и после правки. Сначала повторите один и тот же тест из той же сети и с тем же телефоном; иначе одновременно изменятся несколько условий и вывод станет гаданием. Успешный тест — это не только установленный вызов: подтвердите слышимость в обе стороны и отсутствие аномалий в RTP на обоих плечах. Если результат изменился после конкретной настройки, оставьте её и переходите к следующей проверке.

Wi-Fi, перегруженный канал, потери и джиттер тоже влияют на речь; но совет «перейдите на провод» имеет смысл только если измерения связывают проблему с радиосетью. QoS может помочь при конкуренции трафика, но не починит неверное согласование SDP или закрытый RTP-путь. Перезагрузка Asterisk не очищает причину и способна оборвать активные звонки, поэтому я оставляю её на случай, когда есть конкретное основание. Если проблема проявляется только на внешнем SIP-направлении, сверяйте всю цепочку с материалом о SIP-транках и IP-телефонии.

Частые вопросы