Ваши операторы колл-центра узнают об этом первыми. Клиент в третий раз переспрашивает: «Повторите, пожалуйста». Оператор извиняется, вслушивается в рваный звук, и разговор, который должен занять 3 минуты, растягивается на 8. Умножьте это на 50 операторов и 500 звонков в день. Вот во что обходится отсутствие мониторинга качества связи.
Большинство администраторов Asterisk следят за количеством звонков и временем ожидания в очереди. Мало кто смотрит на качество этих звонков — jitter, packet loss, MOS, работу кодеков. Эта статья исправляет ситуацию.
Что делает VoIP-звонок «качественным»?
Прежде чем переходить к инструментам Asterisk, разберитесь с четырьмя метриками, которые определяют, звучит звонок чисто или как разговор через консервную банку.
Задержка (Latency, One-Way Delay)
Задержка — это время, за которое голосовые пакеты доходят от отправителя к получателю. Она не искажает звук, она портит сам разговор: собеседники начинают перебивать друг друга.
| Задержка | Влияние |
|---|---|
| < 150ms | Незаметна. Разговор идёт естественно. |
| 150-300ms | Заметная задержка. Собеседники начинают накладываться друг на друга. |
| > 300ms | Разговор рассыпается. Ощущение спутникового звонка. |
Для инсталляций Asterisk измеряйте задержку между вашей АТС и провайдером SIP-транка. Если система развёрнута на собственном сервере, это обычно участок между сервером и шлюзом ITSP.
Jitter (вариация задержки пакетов)
Jitter показывает, насколько неравномерно приходят пакеты. Если пакеты идут с интервалом 20ms, но временами интервал подскакивает до 80ms — у вас высокий jitter. Результат: рваный звук, роботизированные голоса и провалы в речи.
Asterisk сглаживает jitter встроенным jitter-буфером. Но буфер — это компромисс: слишком маленький не сгладит колебания, слишком большой добавит задержку.
Проверьте текущие настройки jitter-буфера в rtp.conf:
; /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=20000
; Jitter buffer settings
jbenable=yes ; Enable jitter buffer
jbforce=no ; Don't force on all channels
jbmaxsize=200 ; Max jitter buffer size (ms)
jbresyncthreshold=1000 ; Resync threshold (ms)
jbimpl=adaptive ; Use adaptive jitter buffer
jbtargetextra=40 ; Extra delay for target (ms)
jblog=no ; Enable for debuggingРеализация adaptive подстраивает размер буфера динамически под состояние сети. Если jitter стабильно выше 30ms, переключитесь с fixed на adaptive и увеличьте jbmaxsize до 200.
Packet loss (потеря пакетов)
Каждый потерянный пакет — это выпавший кусок звука. В отличие от протоколов поверх TCP, RTP (Real-time Transport Protocol) не запрашивает повторную передачу: пока пакет придёт заново, момент уже упущен.
| Packet loss | Влияние |
|---|---|
| < 1% | Незаметно на большинстве кодеков |
| 1-3% | Редкие щелчки, лёгкая деградация |
| 3-5% | Отчётливо слышны провалы, слушать тяжело |
| > 5% | Разговаривать становится трудно |
Одни кодеки переносят потери лучше других. Opus держит до 5% packet loss за счёт встроенной коррекции ошибок (FEC). У G.711 запаса нет вообще — каждый потерянный пакет превращается в провал.
MOS (Mean Opinion Score)
MOS сворачивает jitter, задержку и packet loss в одно число от 1.0 до 5.0:
| MOS | Качество | Аналогия из жизни |
|---|---|---|
| 4.3-5.0 | Отличное | Качество городской линии |
| 4.0-4.3 | Хорошее | Мобильный в сети 4G |
| 3.5-4.0 | Приемлемое | Громкая связь в переговорной |
| 3.0-3.5 | Плохое | Слабый сигнал сотовой сети, но разобрать можно |
| < 3.0 | Непригодное | «Вы меня слышите?» каждые 10 секунд |
Теоретический максимум для G.711 — MOS 4.5. Для G.729 это 3.92 даже в идеальных условиях: алгоритм сжатия сам по себе ухудшает качество.
Мониторинг качества связи через Asterisk CLI
Asterisk отдаёт данные о качестве в реальном времени через статистику RTCP (Real-Time Control Protocol). Каждый активный RTP-поток обменивается RTCP-пакетами, в которых передаются jitter, packet loss и round-trip time.
Качество активных каналов
Во время разговора метрики можно снять напрямую:
# List active channels
asterisk -rx "core show channels verbose"
# Show RTP stats for a specific channel
asterisk -rx "rtp show stats"Команда rtp show stats выводит текущие jitter, packet loss и round-trip time по каждому активному RTP-потоку. Запускайте её в часы пик, чтобы ловить проблемы качества в моменте.
Данные RTCP в CDR и CEL
Asterisk умеет писать данные о качестве RTCP вместе с записями о звонках. Включите это в cdr.conf и используйте модуль CDR adaptive ODBC, чтобы складывать метрики качества в базу:
; /etc/asterisk/cdr.conf
[general]
enable=yes
unanswered=yesДля более детальных данных настройте систему Channel Event Logging (CEL):
; /etc/asterisk/cel.conf
[general]
enable=yes
apps=dial,queue
events=ALLИзвлечение качества из переменных канала
После каждого звонка Asterisk заполняет переменные канала статистикой RTP. Обратитесь к ним в диалплане:
; In extensions.conf — log quality after each call
exten => h,1,NoOp(Call quality - RTP stats)
same => n,Set(JITTER=${CHANNEL(rtcp,all_jitter)})
same => n,Set(LOSS=${CHANNEL(rtcp,all_loss)})
same => n,Set(RTT=${CHANNEL(rtcp,all_rtt)})
same => n,NoOp(Jitter: ${JITTER} | Loss: ${LOSS} | RTT: ${RTT})
same => n,Set(CDR(jitter)=${JITTER})
same => n,Set(CDR(packet_loss)=${LOSS})
same => n,Set(CDR(rtt)=${RTT})Функция CHANNEL(rtcp,...) отдаёт данные RTCP по текущему плечу вызова. Доступные поля:
- —
all_jitter— jitter за время звонка (min/max/avg/stdev) - —
all_loss— процент потери пакетов - —
all_rtt— round-trip time - —
txcount/rxcount— отправленные и принятые пакеты - —
txjitter/rxjitter— jitter на передаче и на приёме
Складывайте их в базу CDR, чтобы видеть историю и тренды качества связи.
Выбор кодека и его влияние на качество
Кодек задаёт потолок качества. Никакая оптимизация сети не заставит G.729 звучать как G.711.
| Кодек | Полоса | Макс. MOS | Устойчивость к packet loss | Где применять |
|---|---|---|---|---|
| G.711 (ulaw/alaw) | 87.2 kbps | 4.5 | Низкая (< 1%) | LAN, широкие каналы |
| G.729 | 31.2 kbps | 3.92 | Низкая (< 1%) | WAN, узкие каналы |
| Opus | 6-510 kbps | 4.5+ | Высокая (до 5% с FEC) | WebRTC, нестабильные сети |
| G.722 | 87.2 kbps | 4.5 | Низкая (< 1%) | HD Voice, широкополосные звонки |
| iLBC | 38.4 kbps | 4.14 | Средняя (2-3%) | Сети с потерями |
Приоритет кодеков настраивается в sip.conf или pjsip.conf:
; /etc/asterisk/pjsip.conf
[my-trunk]
type=endpoint
; ...
allow=!all,opus,g722,ulaw,alawСтавьте предпочитаемый кодек первым. Если провайдер SIP-транка поддерживает Opus — берите его: Opus подстраивается под сеть на лету и переносит packet loss куда лучше любого кодека с фиксированным битрейтом.
Проверка качества кодека
Чтобы посмотреть, какой кодек согласовался, используйте sip show channelstats (chan_sip) или аналогичную команду PJSIP:
# For PJSIP
asterisk -rx "pjsip show channelstats"
# Output includes:
# BridgeId | Channel | Codec | Rx/Tx Count | Lost | Jitter | RTTЕсли у вас стабильно согласуется G.729, а нужен G.711, проверьте конфигурацию транка и порядок allow/disallow.
Мониторинг качества на уровне сети
Asterisk показывает, что случилось со звонками. Сетевой мониторинг показывает, почему.
RTCP-XR (расширенные отчёты)
Asterisk 13+ поддерживает RTCP-XR — расширенные метрики качества сверх стандартного RTCP:
- —Метрики burst/gap loss (отличают случайные потери от пакетных)
- —Round-trip delay
- —Уровни сигнала и шума
- —R-factor (исходная величина, из которой считается MOS)
Включение RTCP-XR в PJSIP:
; /etc/asterisk/pjsip.conf
[global]
type=global
; Enable RTCP-XR
send_rtcp_xr=yesМониторинг через sngrep
Для разбора SIP-сигнализации в реальном времени sngrep незаменим:
# Install
apt-get install sngrep
# Capture live SIP traffic
sngrep -d eth0
# Filter specific calls
sngrep -c port 5060sngrep показывает полную SIP-лестницу: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE. Когда звонки срываются или качество проседает, первопричину ищут именно здесь.
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
Анализ RTP через tcpdump
Снимите RTP-пакеты и разберите их в Wireshark:
# Capture RTP traffic (common port range)
tcpdump -i eth0 -w /tmp/rtp-capture.pcap portrange 10000-20000
# Run for 60 seconds during peak traffic
timeout 60 tcpdump -i eth0 -w /tmp/rtp-$(date +%Y%m%d-%H%M).pcap portrange 10000-20000Откройте дамп в Wireshark и перейдите в Telephony > RTP > RTP Streams. Wireshark посчитает jitter, packet loss и MOS по каждому потоку. Это золотой стандарт для диагностики плавающих проблем с качеством.
Проактивные оповещения о качестве
Реактивный мониторинг означает, что о проблеме вы узнаёте от клиентов. Настройте проактивные алерты по пороговым значениям.
Скрипт мониторинга по пороговым значениям
Соберите простой скрипт, который проверяет качество на активных звонках:
#!/bin/bash
# /usr/local/bin/asterisk-quality-check.sh
JITTER_THRESHOLD=30 # ms
LOSS_THRESHOLD=2 # percent
RTT_THRESHOLD=300 # ms
# Get RTP stats from active channels
asterisk -rx "rtp show stats" | while read line; do
jitter=$(echo "$line" | awk '{print $5}')
loss=$(echo "$line" | awk '{print $7}')
rtt=$(echo "$line" | awk '{print $9}')
if (( $(echo "$jitter > $JITTER_THRESHOLD" | bc -l) )); then
echo "ALERT: High jitter detected: ${jitter}ms" | \
mail -s "Asterisk Quality Alert" admin@yourcompany.com
fi
if (( $(echo "$loss > $LOSS_THRESHOLD" | bc -l) )); then
echo "ALERT: Packet loss detected: ${loss}%" | \
mail -s "Asterisk Quality Alert" admin@yourcompany.com
fi
doneЗапускайте его по cron каждые 5 минут в рабочие часы:
*/5 8-18 * * 1-5 /usr/local/bin/asterisk-quality-check.sh
Мониторинг SIP-кодов ответа
Отслеживайте SIP-ошибки, чтобы ловить проблемы на стороне провайдера:
| Код | Значение | Что делать |
|---|---|---|
| 408 | Request Timeout | Проверить сетевую доступность транка |
| 486 | Busy Here | Норма, но всплески говорят о нехватке ёмкости |
| 503 | Service Unavailable | Проблема у провайдера транка или перегруженная АТС |
| 488 | Not Acceptable | Несовпадение кодеков — проверьте настройки allow/disallow |
Смотреть их можно из Asterisk CLI:
# Watch for failed SIP transactions in real-time
asterisk -rx "pjsip show registrations" | grep -v "Registered"Типовые проблемы с качеством связи и их решение
Проблема: односторонняя слышимость
Симптомы: клиент слышит оператора, а оператор клиента — нет (или наоборот).
Причина: почти всегда NAT. RTP-пакеты уходят не на тот IP.
Решение в pjsip.conf:
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=YOUR.PUBLIC.IP
external_signaling_address=YOUR.PUBLIC.IP
local_net=10.0.0.0/8
local_net=172.16.0.0/12
local_net=192.168.0.0/16Проблема: рваный звук в часы пик
Симптомы: качество проседает с 9 до 11 утра и с 14 до 16.
Причина: насыщение канала. Голосовой трафик конкурирует с данными.
Решение: внедрить маркировку QoS. Помечайте голосовые пакеты DSCP EF (Expedited Forwarding):
; /etc/asterisk/rtp.conf
[general]
tos=ef ; DSCP EF for RTP
cos=5 ; 802.1p CoS for RTP
; /etc/asterisk/sip.conf or pjsip.conf
tos_sip=cs3 ; DSCP CS3 for SIP signaling
cos_sip=3Затем настройте роутер или коммутатор на приоритизацию помеченных пакетов.
Проблема: случайные обрывы через 30 секунд
Симптомы: звонок соединяется, звук идёт, а ровно на 30-32 секунде связь рвётся.
Причина: SIP ALG на роутере или файрволе переписывает SIP-заголовки.
Решение: отключить SIP ALG на роутере. У каждой модели своё меню, но обычно это раздел настроек файрвола или NAT. Одно это исправление решает больше проблем с Asterisk, чем любая другая правка конфигурации.
Проблема: эхо в разговоре
Симптомы: клиент или оператор слышит собственный голос с задержкой.
Причина: рассогласование импеданса на аналоговых/TDM-интерфейсах или слишком большой jitter-буфер.
Решение:
# If using DAHDI analog interfaces
# Tune echo cancellation in /etc/dahdi/system.conf
echocanceller=mg2,1-4
# In chan_dahdi.conf
echocancel=yes
echocancelwhenbridged=yes
echotraining=800Для чисто SIP-инсталляций эхо обычно приходит от абонентского устройства — телефона или софтфона. Проверьте настройки эхоподавления на самом аппарате.
Собираем дашборд качества связи
Сырые данные RTCP бесполезны, если на них никто не смотрит. Нужен дашборд, который показывает тренды качества во времени и подсвечивает деградацию до того, как операторы начнут жаловаться.
Вариант 1: своими руками на Grafana
Складывайте данные RTCP в time-series базу (InfluxDB, TimescaleDB) и стройте дашборды в Grafana. Это работает, но заложите 20-40 часов на настройку:
- —Написать свой AGI/ARI-скрипт для сбора данных RTCP
- —Развернуть InfluxDB/TimescaleDB
- —Настроить источник данных в Grafana
- —Собрать панели: тренды MOS, распределение jitter, потери по транкам
- —Создать правила алертов
- —Поддерживать всё это, когда обновления Asterisk сломают ваши скрипты
Вариант 2: Astervis — готовая аналитика для Asterisk
Astervis подключается к вашей базе CDR Asterisk и даёт 30+ готовых отчётов: аналитику качества связи, показатели очередей, метрики операторов, загрузку транков. Установка занимает 5 минут:
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashНикаких самописных скриптов. Никакой настройки Grafana. Никакой возни с базой. Тепловые карты очередей, отслеживание работы операторов и аналитика трендов по звонкам — сразу из коробки за $119 в месяц фиксированно, сколько бы операторов у вас ни было.
Разница простая: дашборд в Grafana даёт то, что вы в нём настроили. Astervis даёт то, что за 15 лет работы колл-центров доказало свою полезность.
Чек-лист по качеству связи
Прежде чем закрыть вкладку, пройдитесь по списку:
- —Jitter-буфер: проверьте
jbenable=yesиjbimpl=adaptiveвrtp.conf - —Приоритет кодеков: убедитесь, что предпочитаемые кодеки стоят первыми в конфиге эндпоинта
- —Логирование RTCP: добавьте переменные
CHANNEL(rtcp,*)в hangup-хендлер - —Маркировка QoS: задайте
tos=efдля RTP иtos_sip=cs3для SIP-сигнализации - —Настройка NAT: проверьте, что
external_media_addressсовпадает с вашим публичным IP - —SIP ALG: убедитесь, что он выключен на файрволе или роутере
- —Мониторинг: поставьте регулярные проверки качества на часы пик
- —Алерты: задайте пороги jitter > 30ms, loss > 2%, RTT > 300ms
- —Исторические данные: храните метрики RTCP в базе для анализа трендов
- —Согласование кодеков: проверяйте
pjsip show channelstatsво время звонков
Прогоняйте этот список раз в квартал и после любых изменений в сети. Аудит на 15 минут избавляет от недель тикетов «телефоны плохо звучат».
Что дальше
Мониторинг качества связи — не разовая настройка, а постоянная дисциплина. Начните с базы: включите логирование RTCP, проверьте настройки jitter-буфера, пересмотрите конфигурацию кодеков. Дальше двигайтесь к непрерывному мониторингу с пороговыми алертами и анализом исторических трендов.
Цель — не идеальный MOS на каждом звонке. Цель — заметить деградацию раньше, чем это сделают клиенты. Просадка MOS на 0.5, которую две недели никто не видел, — это сотни раздражённых людей, которые никогда не объяснят вам, почему не перезвонили.
Следите за сетью. Собирайте метрики. Чините проблемы до того, как они начнут стоить вам клиентов.
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.