Почему Asterisk срывает звонки: проверяем кодеки и RTP

Если вызов не устанавливается или после ответа пропадает звук, причина не обязательно в кодеке. Я покажу, как последовательно проверить согласование медиа, NAT, сеть, шифрование и нагрузку Asterisk, чтобы найти неисправность по сигналам и журналам, а не менять настройки наугад.

Ошибка №1: считать любой отказ ошибкой кодека

Кодеки действительно могут сорвать вызов, но сообщение 488 само по себе ещё не доказывает, что виноват именно список аудиоформатов. Сначала смотрю на SIP-ответ и SDP в запросе INVITE и ответе: какие медиа предложены, какие приняты, совпадают ли параметры. По RFC 3261 ответ 488 означает, что запрос не принят из-за характеристик ресурса; в телефонии это может быть связано с медиа, но искать нужно в контексте конкретного диалога. Провайдер, телефон и Asterisk могут сообщить разные детали, поэтому фраза «вижу 488 — включаю G.711» годится только для короткого анекдота, но не для диагностики.

Asterisk работает как B2BUA: он завершает один SIP-диалог и создает другой. Поэтому стороны не всегда просто «договариваются друг с другом» напрямую; Asterisk обрабатывает предложения на каждом плече вызова. Сравните разрешённые кодеки endpoint-ов и то, что реально передано в SDP. В PJSIP список задаётся параметром allow; порядок и правила согласования могут влиять на выбор, но сам факт наличия модуля не означает, что кодек включён для конкретного endpoint. В CLI полезно проверить endpoint и каналы, а затем сопоставить вывод с журналом SIP. Сначала установите, на каком плече исчезает общий формат, и только потом меняйте allow.

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

• Сопоставьте SDP в обоих плечах вызова.
• Проверьте allow и доступность нужных codec-модулей.
• Свяжите код 488 с конкретным SIP-ответом и журналом.

Ошибка №2: путать NAT с проблемой кодека

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

Для PJSIP за NAT нет универсальной строки «включить NAT». В официальном примере Asterisk для transport используются local_net, external_media_address и external_signaling_address; для endpoint могут иметь значение rtp_symmetric, force_rport, rewrite_contact и direct_media. Нужный набор зависит от того, кто находится за NAT и где стоит PBX. Параметры externalmediaip и nat=yes из исходного текста не являются корректными именами этих настроек PJSIP. Не вставляйте их в pjsip.conf: сначала определите топологию, затем применяйте подходящие параметры из документации именно вашей версии.

Проверьте путь медиапотока на практике: есть ли RTP-пакеты в обе стороны на сервере, не отправляет ли Asterisk в SDP внутренний адрес для внешнего узла, не направляет ли direct media поток в обход PBX. Настройка direct_media=no в некоторых схемах оставляет Asterisk в медиатракте, но это не универсальное лекарство и увеличивает работу сервера. SIP ALG тоже не следует объявлять виновником заранее. Если на маршрутизаторе включён SIP helper и после его обработки меняется сигнализация или поведение RTP, сравните результат с отключённым helper в контролируемом тесте. У MikroTik параметры SIP helper описаны в RouterOS; учитывайте версию и конкретную конфигурацию, а не миф о том, что любой ALG всегда ломает VoIP.

• Проверьте адреса в SDP.
• Убедитесь, что RTP проходит в обе стороны.
• Тестируйте SIP helper по одному изменению.

Ошибка №3: выбирать кодек по обещанию «переживёт потери»

Кодек не чинит плохой канал. Потери, джиттер, задержка, перегрузка очередей и нестабильный маршрут портят разговор по-разному; подмена одного кодека другим не устраняет причину. Особенно сомнительно без измерений утверждать, что G.711 «лучше переносит потери», чем G.729 или Opus. Результат зависит от реализации, сокрытия потерь, параметров сети и устройства. G.711 передаёт несжатый голосовой сигнал с более высокой нагрузкой на полосу, а кодеки с меньшей скоростью могут экономить трафик, но это не делает их автоматически устойчивее к потерям. Не существует общего правила «при потере пакетов всегда ставьте G.711».

Измерьте качество на том участке, где слышно ухудшение: потери RTP, джиттер и задержку надо наблюдать во время проблемного вызова. Сверьте статистику обеих сторон, потому что замер только на сервере не показывает, что происходит в локальной сети телефона или у оператора. Если в момент жалобы видны потери или всплески задержки, исследуйте канал, Wi-Fi, очереди QoS, загрузку интерфейса и маршрут. Если потерь нет, а речь всё равно искажена, вернитесь к SDP и проверьте, какой кодек реально согласован и нет ли преобразования формата по пути.

Сжатие может быть полезно при ограниченной полосе, но посчитайте полный поток с учётом сетевых заголовков и числа одновременных вызовов; не ориентируйтесь только на битрейт кодека. Учитывайте лицензирование и наличие кодек-модуля в вашей сборке Asterisk. Asterisk использует кодек-модули для обработки и транскодирования медиа, а преобразование форматов может добавить нагрузку. Если один endpoint говорит ulaw, а второй — другой формат, наличие подходящего кодека и разрешённое транскодирование важны. Сравнивайте качество и нагрузку на тестовом вызове, а не по рекламной таблице. Быстрый канал — полезное условие, но он не гарантирует стабильность доставки каждого RTP-пакета.

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

Ошибка №4: смешивать TLS, SRTP и совместимость

TLS защищает SIP-сигнализацию на соответствующем соединении, SRTP — медиапоток. Это разные механизмы, и включение одного не означает, что зашифровано другое. Если вызов устанавливается, но медиа не появляется, проверяйте согласование SRTP, поддержку режимов на обоих устройствах и сообщения Asterisk о создании защищённой сессии. Если не устанавливается сама сигнализация, смотрите транспорт TLS, сертификаты и журнал SIP. Важно отделить отказ регистрации или INVITE от проблемы после ответа. Иначе легко начать менять настройки шифрования, хотя ошибка возникла раньше.

Документация Asterisk описывает поддержку TLS и SRTP и указывает, что для SRTP нужны соответствующие компоненты сборки. Поэтому проверьте сборку и загруженные модули, конфигурацию endpoint и фактические возможности телефона или транка. Не предполагайте, что алгоритмы «включены по умолчанию» для всех устройств: согласованные параметры зависят от конфигурации каждой стороны. Если аппарат не поддерживает нужный режим, безопасное решение — согласовать совместимый вариант или заменить устройство, а не отключать защиту на всём сервере ради одного endpoint.

Когда нужно локализовать сбой, сравнивайте один тестовый вызов с шифрованием и без него только в изолированной и разрешённой конфигурации, не оставляя небезопасный режим рабочим. Зафиксируйте разницу в SDP, SIP-ответах и сообщениях Asterisk. Проверьте, что требование оператора совпадает с настройкой транка, а телефон действительно предлагает нужный режим. Удаление строк из старой конфигурации chan_sip не является универсальным рецептом для PJSIP: это разные драйверы и разные параметры. Защита не должна быть случайной; она должна быть проверяемой с обеих сторон.

• Отделяйте TLS сигнализации от SRTP медиа.
• Сверяйте поддержку шифрования на обеих сторонах.
• Проверяйте журналы и компоненты сборки.

Ошибка №5: объяснять любой сбой нехваткой мощности

Перегрузка действительно может влиять на обработку вызовов и преобразование медиа, но утверждение «одно ядро не выдержит тысячу звонков» без модели нагрузки бессмысленно. Результат зависит от железа, версии Asterisk, типа сигнализации, наличия транскодирования, записи разговоров, конференций, драйверов и профиля трафика. Статическая конфигурация сама по себе не означает низкую производительность, а динамическая не ускоряет систему магически. Уберите такие универсальные рецепты: измерьте реальную нагрузку в часы пик и выясните, что именно упирается в ресурс.

Начните с наблюдений во время жалоб: загрузка CPU по ядрам, процессы Asterisk, число активных каналов, ошибки и задержки, использование диска при записи и сетевые потери. Затем сравните периоды нормальной и плохой работы. Если нагрузку создаёт транскодирование, проверьте, где оно возникает и можно ли согласовать общий кодек без лишнего преобразования. Если проблема связана с потоком SIP-запросов, проверьте регистрацию, таймеры и сетевую сторону. Если растут ошибки RTP, масштабирование сервера не исправит плохую маршрутизацию. Диагноз должен следовать за метрикой, а не за красивой схемой кластеризации.

Балансировка и несколько узлов могут быть частью архитектуры, когда это подтверждают требования доступности и измеренная нагрузка. Но распределить вызовы по серверам — не то же самое, что автоматически получить отказоустойчивую телефонию: нужно продумать регистрацию устройств, транки, маршрутизацию, состояние вызовов и сценарий аварии. Перед изменением архитектуры соберите профиль одновременных вызовов и функций, которые включены на каждом канале. Проведите нагрузочную проверку в стенде с похожей конфигурацией и зафиксируйте точку насыщения. Пока этих данных нет, фраза «сервер не тянет» — только гипотеза. Иногда чинить нужно сеть или конфигурацию, а не покупать ещё один узел.

• Снимайте метрики во время нагрузки.
• Ищите транскодирование и другие узкие места.
• Масштабируйте после измерений и проверки сценария отказа.

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