Что измерять в Asterisk при жалобах на голос

Если в Asterisk слышно плохо, сначала определите направление проблемы и соберите RTCP или захват RTP: смена кодека наугад редко объясняет причину. Я покажу, какие данные доступны в CLI, что можно записать по завершении вызова и как отделить сбой сети от проблемы самой АТС.

Почему «голос плохой» — это не диагноз

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

Дальше важно понимать, что в VoIP есть два разных мира. SIP — это сигнализация: регистрация, вызов, ответ, перевод, завершение. RTP — это сам голос, поток мелких UDP-пакетов, который идёт отдельно и часто совсем другим путём. Если звонок не устанавливается, сначала проверяю SIP и журнал вызова; обрыв по таймеру сам по себе не доказывает неисправность сигнализации. Если звонок есть, но голос булькает, пропадает слогами или идёт с эхом и задержкой, — это проверяю медиапоток RTP, конечные устройства и сеть. Перепутать эти миры — самый дорогой способ потратить неделю.

Отдельная беда — «у всех плохо». На практике «у всех» означает трёх человек из одного отдела, которые сидят на одном коммутаторе или на одной Wi‑Fi точке. Когда жалобы раскладываешь по времени и сторонам вызова, картина почти всегда сужается до одного участка: конкретный маршрут через транк, конкретная VPN‑связка с удалённым сотрудником, конкретный час, когда кто-то заливает бэкап в облако. Общее «плохо» лечится только общими заклинаниями, а конкретный маршрут — конкретной настройкой.

Эта статья продолжает тему наблюдаемости после интеграций: в предыдущем материале серии разбирали, как связать звонок с CRM без хрупкого скрипта, а здесь — что из АТС стоит мерить постоянно, чтобы следующую жалобу можно было сопоставить с цифрами, а не с воспоминаниями.

• Время звонка с точностью до минуты
• Номер или внутренний абонента и собеседника
• Кто кого не слышал: обе стороны или одна
• Внутренний вызов или через SIP‑транк
• Устройство и сеть: телефон, софтфон, Wi‑Fi, VPN

Какие метрики RTP реально говорят о качестве

Для голоса важны четыре величины. Потери пакетов — доля RTP‑пакетов, которые не дошли. Джиттер — разброс времени прихода пакетов: если пакеты идут неравномерно, буфер на приёмной стороне не успевает их выровнять, и речь рвётся. Задержка (RTT или односторонняя) — сколько времени голос идёт от рта до уха; при большой задержке люди начинают перебивать друг друга. И последовательность: пакеты, пришедшие не по порядку или с дырками в нумерации. Всё остальное — производные от этих четырёх.

Для задержки часто используют ориентир из ITU‑T G.114: до 150 мс в одну сторону обычно считают приемлемой целью планирования, а не универсальной границей хорошего звука. У потерь и джиттера тоже нет одного процента или числа миллисекунд, которое одинаково описывает все кодеки, буферы и устройства. Я сравниваю направления и стабильные вызовы с проблемными, а затем проверяю, что именно меняется.

Главная мысль: метрики считаются по направлению. Поток от АТС к телефону и поток от телефона к АТС — два разных потока, и плохим может быть только один. Жалоба «меня не слышат» означает проблему на входящем к собеседнику направлении, а не «связь вообще плохая». Именно поэтому я всегда спрашиваю, кто кого не слышал: это сразу сокращает поле поиска вдвое.

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

Что смотреть в Asterisk: PJSIP через CLI

Начинаю с CLI. pjsip show endpoints показывает объекты endpoint, а pjsip show contacts — контакты AOR и их состояние. При настроенной проверке доступности qualify_frequency в выводе можно увидеть результат OPTIONS и время ответа. Это данные сигнализации, не качества речи: быстрый OPTIONS не доказывает, что RTP идёт без потерь.

В подходящей версии Asterisk команда pjsip show channelstats показывает доступную статистику медиа для активных каналов PJSIP; состав полей зависит от версии и ситуации с RTCP. Не обещаю, что у каждого вызова появятся потери, джиттер и RTT: сначала смотрю фактический вывод и сопоставляю его с настройками второй стороны. core show channels помогает найти активные каналы, но не заменяет измерение RTP.

Для глубокого разбора включаю логи осторожно и коротко. pjsip set logger on выводит SIP‑сообщения — по SDP видно, какие адреса и порты стороны объявили для медиа и какой кодек договорились использовать. rtp set debug on печатает каждый RTP‑пакет и на нагруженной АТС заваливает консоль за секунды, поэтому включаю его с фильтром по адресу (rtp set debug ip) и выключаю сразу после теста. Включать отладку RTP на весь офис в рабочее время — это как искать утечку воды, открыв все краны.

asterisk -rx "pjsip show endpoints"
asterisk -rx "pjsip show contacts"
asterisk -rx "pjsip show channelstats"
asterisk -rx "core show channels"

Названия и вывод команд проверьте в своей версии Asterisk: набор полей в channelstats менялся между ветками.

Как сохранять качество каждого звонка, а не ловить момент

Для ретроспективы можно сохранять статистику по завершённым вызовам. В Asterisk есть функция CHANNEL(rtcp,<stat>) для chan_pjsip; документация описывает варианты статистики и отдельные показатели Media Experience Score. Сначала проверьте перечень доступных полей в документации именно вашей версии и сделайте пробный вызов: статистика зависит от собранных медиа-данных.

На hangup-обработчике выбранные значения можно записать в пользовательские поля CDR, если схема CDR и обработчик это поддерживают. Я сохраняю только то, что реально возвращает функция, отдельно помечаю направление и сохраняю идентификатор вызова и время. Так проще сравнить жалобу с данными; обещать потери и джиттер в обе стороны для каждого вызова без проверки конфигурации нельзя.

Для общей картины полезны число активных каналов, контакты, доступность транков, загрузка процессора и состояние сетевого канала. В Asterisk есть и Media Experience Score — сводная оценка медиасессии, рассчитанная на основе доступной статистики; это дополнительный индикатор, а не диагноз и не замена исходным показателям. В Zabbix можно забирать системные показатели и результаты выбранных CLI-команд, проверив права и нагрузку опроса.

Отдельно проверяю часовой пояс и синхронизацию времени. Если на АТС, в Zabbix и на маршрутизаторе время разъехалось на несколько минут, все сопоставления превращаются в гадание. NTP на всех трёх — скучная, но обязательная деталь.

• Сводка RTCP по каждому звонку в CDR
• RTT квалификации транков и ключевых телефонов
• Активные каналы и регистрации
• Потери и джиттер на канале провайдера и VPN
• Синхронизация времени NTP на всех узлах

Сеть под голосом: где теряются пакеты

Когда измерения указывают на потери, проверяю участок за участком: загрузку аплинка, Wi‑Fi, ошибки интерфейсов, MTU и таймеры NAT. Это гипотезы, не диагнозы по одному симптому: например, односторонний звук требует отдельно проверить согласованные адреса медиа и путь пакетов.

Метод простой и тупой, и именно поэтому работает: захват трафика с обеих сторон проблемного участка. На сервере АТС — tcpdump по диапазону RTP‑портов из rtp.conf, на маршрутизаторе или на зеркале порта — то же самое. Затем Wireshark: меню Telephony → RTP → RTP Streams и анализ потока покажут потери, джиттер и дыры в последовательности по каждому направлению. Если на АТС поток чистый, а у телефона — с дырами, проблема между ними, и Asterisk можно оставить в покое.

tcpdump -i any -n -w /tmp/call.pcap udp portrange 10000-20000

Числа здесь — пример фильтра, а не штатный диапазон любой установки. Перед захватом проверьте rtpstart и rtpend в rtp.conf и учтите, что RTP/RTCP mux или иная конфигурация может потребовать другого фильтра.

Приоритизация голоса — отдельная тема, и подробно я её разбирал в материале про приоритизацию VoIP в офисной сети. Коротко: метки DSCP на телефонах и АТС бессмысленны, если маршрутизатор на узком канале их не учитывает. Красить пакеты и не настраивать очередь — всё равно что повесить мигалку на велосипед.

SRTP и мониторинг: шифрование не отменяет измерения

SRTP защищает содержимое RTP. В обычном захвате без ключей голос не прослушать, но заголовок RTP сохраняет последовательность и временные метки, полезные для анализа потока. Однако RTCP тоже может быть защищён как SRTCP; нельзя утверждать, что все отчёты RTCP всегда видны в сетевом захвате. Смотрите, что именно включено на конечных точках, и используйте статистику внутри Asterisk, если она доступна.

В PJSIP медиа-шифрование задаётся media_encryption: среди режимов есть sdes и dtls. Для SDES ключ передаётся в SDP, поэтому сигнализацию следует защищать транспортом TLS. Но не всякое несовпадение настройки приводит к передаче открытого голоса: результат зависит от параметров endpoint и согласования, поэтому проверьте журнал и фактический SDP.

Для диагностики сначала использую доступные отчёты Asterisk и анализ метаданных захвата. Отключение SRTP ради прослушивания — отдельное изменение защиты: оно допустимо лишь в контролируемом тесте с согласованными участниками и немедленным возвратом настройки. Чаще до причины достаточно дойти по времени, направлению и потерям.

Разбор: «Городской атлас», 31 рабочее место

Редакция «Городской атлас», 31 рабочее место, Asterisk на PJSIP, один SIP‑транк и шесть сотрудников на удалёнке через VPN. Жалоба типовая: «связь ужасная, особенно днём». Сначала проверили, какие RTCP-поля возвращает установленная версия, затем стали собирать доступные значения и время звонков. В Zabbix добавили доступность транка и сетевого канала, синхронизировали часы. Через несколько рабочих дней сравнили вызовы по направлениям и времени.

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

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

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

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