Обрывы звонков — самая изматывающая проблема в любом колл-центре на базе Asterisk. Каждый разорванный вызов означает потерянный контакт с клиентом, раздражённого оператора и, весьма вероятно, упущенную выручку. Хуже того, обрывы связи печально известны сложностью диагностики: за ними могут стоять десятки разных первопричин — от банальных ошибок в настройке NAT до тонких проблем с качеством сети.
В этом руководстве разобраны все типовые причины обрывов звонков в Asterisk, приведены точные команды диагностики и готовые правки конфигурации, а также показано, как настроить проактивный мониторинг, чтобы ловить проблемы раньше, чем их заметят ваши абоненты.
Почему Asterisk обрывает звонки
Прежде чем браться за исправления, полезно понять схему прохождения вызова. Звонок в Asterisk проходит три отдельные фазы, и обрыв может произойти в любой из них:
- —Установка вызова (INVITE, 200 OK, ACK): обрывы здесь выглядят как звонки, которые на мгновение соединяются и тут же разрываются — обычно в пределах 0–5 секунд.
- —Обмен медиа (RTP-потоки аудио): обрывы уже во время разговора, часто на 15-й, 30-й или 60-й секунде — либо через случайные интервалы.
- —Поддержание сессии (re-INVITE, OPTIONS, session timers): обрывы через предсказуемые интервалы, например ровно 15 или 30 минут.
У каждой фазы свой набор сценариев отказа. Разберём их по порядку.
Причина 1: проблемы с прохождением NAT
Симптомы: звонок обрывается ровно через 30 секунд. Односторонний звук перед обрывом. В локальной сети всё работает, а для удалённых внутренних номеров — нет.
NAT — причина номер один среди всех обрывов звонков в Asterisk. Когда сервер Asterisk стоит за NAT-роутером, SIP-сигнализация и RTP-потоки несут в себе внутренние IP-адреса, до которых внешние абонентские устройства просто не могут достучаться.
Диагностика
Проверьте текущую конфигурацию NAT:
# For chan_sip (legacy)
asterisk -rx "sip show settings" | grep -i nat
# For chan_pjsip (modern)
asterisk -rx "pjsip show endpoint <endpoint_name>"Включите отладку SIP, чтобы увидеть, что происходит на самом деле:
asterisk -rx "pjsip set logger on"
# Сделайте тестовый звонок и посмотрите SIP-заголовки на предмет внутренних IP
# Ищите в заголовках Contact: и Via: адреса вида 192.168.x.x или 10.x.x.xРешение
Для pjsip.conf (рекомендуется для Asterisk 16+):
[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=192.168.0.0/16
local_net=10.0.0.0/8
local_net=172.16.0.0/12
[endpoint-template](!)
type=endpoint
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yesДля sip.conf (устаревший вариант):
[general]
externip=YOUR.PUBLIC.IP
localnet=192.168.0.0/255.255.0.0
localnet=10.0.0.0/255.0.0.0
nat=force_rport,comedia
directmedia=noКлючевой момент: direct_media=no (или canreinvite=no в старом синтаксисе) прогоняет весь RTP через Asterisk. Это дороже по ресурсам, но закрывает 90% обрывов, связанных с NAT.
Причина 2: SIP ALG (Application Layer Gateway)
Симптомы: случайные обрывы. Из одних сетей звонки проходят, из других — нет. SIP-заголовки искажены: порты или IP не совпадают с тем, что отправлял Asterisk.
Во многих домашних и корпоративных роутерах есть SIP ALG — механизм, который «помогает» SIP-трафику, переписывая заголовки пакетов. На практике SIP ALG почти всегда создаёт больше проблем, чем решает.
Диагностика
Сравните то, что отправляет Asterisk, с тем, что получает удалённая сторона:
# Снимаем SIP-трафик на сервере Asterisk
tcpdump -i eth0 -n -s 0 port 5060 -w /tmp/sip_capture.pcap
# Разбираем в Wireshark или через sngrep
sngrep -I /tmp/sip_capture.pcapРешение
Отключите SIP ALG на роутере или межсетевом экране:
- —Linux iptables:
modprobe -r nf_nat_sip nf_conntrack_sip - —pfSense: System, Advanced, Firewall and NAT, снять галочку Disable Firewall Scrub
- —Ubiquiti/EdgeRouter:
set system conntrack modules sip disable - —Большинство домашних роутеров: ищите в настройках межсетевого экрана пункты SIP ALG, SIP Passthrough или VoIP Passthrough и выключайте их
Причина 3: рассогласование session timers
Симптомы: звонок обрывается ровно через 15 минут, 30 минут или другой предсказуемый интервал.
SIP session timers (RFC 4028) нужны, чтобы выявлять «зависшие» вызовы за счёт периодического обновления сессии. Если значения таймеров у Asterisk и удалённой стороны не совпадают, одна из сторон посчитает сессию истёкшей и завершит вызов.
Диагностика
asterisk -rx "pjsip show endpoint <endpoint>" | grep -i timer
grep -i "session-expires" /var/log/asterisk/fullРешение
; pjsip.conf
[endpoint-template](!)
type=endpoint
timers=no ; Полностью отключить session timers
; ЛИБО настроить их корректно:
timers=yes
timers_min_se=90 ; Минимальное время жизни сессии (в секундах)
timers_sess_expires=1800 ; Время жизни сессии (по умолчанию 1800 = 30 мин)Если ваш SIP-провайдер требует session timers, приведите значение Min-SE в соответствие с его требованиями:
timers_min_se=900 ; Подогнать под минимум провайдера (часто 900 с = 15 мин)
timers_sess_expires=1800 ; Ставим больше, чем min_seПричина 4: сбои согласования кодеков
Симптомы: вызов соединяется, но сразу же обрывается (за 1–3 секунды). Звука нет вообще. В трассировках виден SIP 488 Not Acceptable Here.
Если Asterisk и удалённая сторона не могут договориться об общем аудиокодеке, вызов либо не устанавливается, либо разрывается сразу после старта медиасессии.
Диагностика
asterisk -rx "pjsip show endpoint <endpoint>" | grep -i allow
asterisk -rx "core show channels verbose"Решение
Убедитесь, что у обеих сторон есть хотя бы один общий кодек:
; pjsip.conf
[endpoint-template](!)
type=endpoint
allow=!all,g722,ulaw,alaw ; g722 в приоритете (широкополосный), запасные — ulaw/alawСовет: порядок имеет значение. Первый кодек в списке считается предпочтительным. Ставьте на первое место тот, что даёт лучшее качество.
Причина 5: нехватка ресурсов
Симптомы: количество обрывов растёт под нагрузкой. В часы пик Asterisk перестаёт отвечать. Перед обрывом качество звука деградирует — речь рвётся и «роботизируется».
Asterisk требователен к процессору, особенно при транскодировании между разными кодеками и при записи разговоров. Исчерпание CPU, памяти или файловых дескрипторов неизбежно приводит к обрывам.
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
Диагностика
asterisk -rx "core show channels count"
asterisk -rx "core show uptime"
top -bn1 | head -20
free -h
ulimit -n # Лимит файловых дескрипторов
ss -unp | grep asterisk | wc -lРешение
- —Поднимите лимит файловых дескрипторов:
# /etc/security/limits.conf
asterisk soft nofile 65536
asterisk hard nofile 65536- —
Избегайте лишнего транскодирования — используйте один и тот же кодек с обеих сторон вызова.
- —
Оптимизируйте диапазон RTP-портов:
; rtp.conf
[general]
rtpstart=10000
rtpend=20000 ; 10 000 портов = 5 000 одновременных звонков- —Следите за загрузкой CPU — если Asterisk стабильно занимает более 80% процессора, масштабируйтесь горизонтально или обновляйте железо.
Причина 6: межсетевой экран и сетевые проблемы
Симптомы: периодические обрывы, совпадающие с сетевыми событиями. Обрывы затрагивают часть транков, а не все. Провалы звука или односторонний звук перед обрывом.
Межсетевые экраны, которые некорректно отслеживают UDP-соединения, начинают отбрасывать RTP-пакеты. Перегрузка сети, jitter и потери пакетов ухудшают звук и в итоге приводят к обрывам.
Диагностика
ping -c 100 provider.sip.address | tail -5
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
asterisk -rx "rtp show stats"Решение
# Увеличиваем таймаут отслеживания UDP-соединений (30 с по умолчанию мало для звонков)
echo 180 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout
echo 180 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
# Закрепляем в /etc/sysctl.conf
net.netfilter.nf_conntrack_udp_timeout=180
net.netfilter.nf_conntrack_udp_timeout_stream=180Убедитесь, что межсетевой экран пропускает:
- —SIP-сигнализацию: UDP/TCP 5060 (или ваш нестандартный порт)
- —RTP-медиа: UDP 10000-20000 (диапазон должен совпадать с rtp.conf)
- —TLS/SRTP: TCP 5061 для шифрованного SIP
Причина 7: сбои qualify и keep-alive
Симптомы: в выводе pjsip show endpoints устройства отображаются как Unreachable или UNKNOWN. Звонки на отдельные внутренние номера не проходят, тогда как остальные работают.
Asterisk рассылает сообщения OPTIONS или NOTIFY, чтобы проверить, доступны ли ещё абонентские устройства. Если устройство не отвечает на такие проверки, Asterisk помечает его как недоступное.
Диагностика
asterisk -rx "pjsip show endpoints" | grep -E "Unavail|Unreachable"
asterisk -rx "pjsip show aor <aor_name>"Решение
; pjsip.conf
[aor-template](!)
type=aor
qualify_frequency=60 ; Проверять каждые 60 секунд
qualify_timeout=5.0 ; Ждать ответа 5 секунд
max_contacts=1Для нестабильных сетей увеличьте таймаут:
qualify_timeout=10.0 ; Мягче для каналов с высокой задержкойПроактивный мониторинг: перехватить обрыв до того, как он случится
Разбираться с обрывами постфактум — когда клиенты уже жалуются — дорого и нервно. Настоящее решение — проактивный мониторинг, который замечает деградацию раньше, чем она превратится в обрывы.
Что мониторить
| Метрика | Почему это важно | Порог оповещения |
|---|---|---|
| Активные каналы | Планирование ёмкости | Более 80% от максимума |
| Распределение длительности звонков | Обрывы выглядят как короткие звонки | Всплеск звонков короче 10 с |
| ASR (Answer-Seizure Ratio) | Доля несостоявшихся вызовов | Ниже 90% |
| ACD (Average Call Duration) | Резкое падение сигнализирует о проблемах | Ниже 50% от нормы |
| Потери RTP-пакетов | Качество звука | Выше 1% |
| Jitter | Качество звука | Выше 30 мс |
| Коды ответов SIP | Паттерны ошибок | Всплеск 408, 480, 503 |
| Статус регистрации транков | Связность | Любой незарегистрированный транк |
| Загрузка CPU/памяти | Нехватка ресурсов | CPU выше 80% |
Анализ обрывов по данным CDR
В базе CDR (Call Detail Records) лежит ценный материал для расследования. Запросы помогут найти закономерности в обрывах:
-- Ищем звонки аномально малой длительности (вероятные обрывы)
SELECT calldate, src, dst, duration, disposition, channel
FROM cdr
WHERE duration < 10
AND disposition = 'ANSWERED'
AND calldate > NOW() - INTERVAL 24 HOUR
ORDER BY calldate DESC;
-- Доля обрывов по часам (находим самые проблемные периоды)
SELECT
HOUR(calldate) as hour,
COUNT(*) as total_calls,
SUM(CASE WHEN duration < 10 AND disposition = 'ANSWERED' THEN 1 ELSE 0 END) as short_calls,
ROUND(SUM(CASE WHEN duration < 10 AND disposition = 'ANSWERED' THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) as drop_rate_pct
FROM cdr
WHERE calldate > NOW() - INTERVAL 7 DAY
GROUP BY HOUR(calldate)
ORDER BY drop_rate_pct DESC;
-- Доля обрывов по транкам (выявляем проблемных провайдеров)
SELECT
SUBSTRING_INDEX(channel, '-', 1) as trunk,
COUNT(*) as total_calls,
SUM(CASE WHEN duration < 10 AND disposition = 'ANSWERED' THEN 1 ELSE 0 END) as potential_drops,
ROUND(AVG(duration), 1) as avg_duration
FROM cdr
WHERE calldate > NOW() - INTERVAL 30 DAY
GROUP BY trunk
ORDER BY potential_drops DESC;Автоматическое выявление обрывов в Astervis
Команды CLI и SQL-запросы хороши для разовой диагностики, но для непрерывного мониторинга они не масштабируются. Astervis даёт дашборды реального времени, специально сделанные под колл-центры на Asterisk, и автоматизирует весь этот процесс:
- —Мониторинг звонков в реальном времени — на живом дашборде видно каждый активный вызов, его длительность, кодек и метрики качества
- —Автоматическое выявление обрывов — Astervis подсвечивает аномально короткие звонки и показывает проблемы по конкретным транкам через тепловые карты: сразу видно, когда и где происходят обрывы
- —Контроль работы операторов — можно сопоставить обрывы с конкретными операторами, очередями или временными интервалами и понять, системная это проблема или дело в отдельном сотруднике
- —Мониторинг состояния транков — статус регистрации, объём вызовов и метрики качества по каждому транку с мгновенными оповещениями, если транк упал
- —Историческая аналитика — 30+ графиков: динамика объёма звонков, время ожидания в очереди, KPI операторов и многое другое — и всё это без единой строчки SQL
Astervis подключается к вашему серверу Asterisk за считанные минуты одной командой установки и сразу начинает собирать данные. Вместе с ручными шагами диагностики выше вы получаете и глубокий разбор инцидентов, и автоматический мониторинг, который предотвращает будущие проблемы.
Начните бесплатный 14-дневный период
Шпаргалка: диагностика по симптому
| Симптом | Наиболее вероятная причина | С какой команды начать |
|---|---|---|
| Обрыв ровно через 30 секунд | Проблемы с NAT | pjsip show endpoint |
| Обрыв на 15-й или 30-й минуте | Рассогласование session timers | Проверить настройку таймеров |
| Случайные обрывы, часть транков | SIP ALG | Отключить ALG, снять tcpdump |
| Нет звука, затем обрыв | Несовпадение кодеков | Проверить настройки allow |
| Обрывы в часы пик | Нехватка ресурсов | top, core show channels count |
| Один внутренний номер недоступен | Таймаут qualify | pjsip show endpoints |
| Обрывы на удалённых номерах | Межсетевой экран / таймаут UDP | Проверить настройки conntrack |
Чек-лист профилактики
Пройдитесь по этому списку при развёртывании нового Asterisk, чтобы обрывы не появились с самого начала:
- —Выставить
direct_media=noна всех endpoint - —Правильно прописать
external_media_addressиexternal_signaling_address - —Отключить SIP ALG на всех роутерах по пути прохождения трафика
- —Поднять таймаут UDP conntrack минимум до 180 секунд
- —Согласовать списки кодеков между Asterisk и всеми SIP-провайдерами
- —Настроить session timers под требования провайдера либо отключить их
- —Выставить лимит файловых дескрипторов от 65536
- —Открыть на межсетевом экране и SIP (5060), и весь диапазон RTP (10000-20000)
- —Настроить мониторинг регистрации транков и качества связи
- —Провести нагрузочный тест одновременными звонками на ожидаемом пике
Заключение
У обрывов звонков в Asterisk почти всегда есть конкретная и устранимая причина. Главные виновники — ошибки в настройке NAT, вмешательство SIP ALG и рассогласование session timers — покрывают подавляющее большинство случаев и чинятся без особых сложностей, как только их удалось опознать.
Ключ к тому, чтобы избавиться от обрывов навсегда, — не только починить текущую поломку, но и выстроить мониторинг, который поймает следующую раньше ваших клиентов. Будь то команды CLI, запросы к CDR или специализированный инструмент вроде Astervis — цель одна: видеть каждый звонок, каждый транк и каждую потенциальную точку отказа.
Ваш колл-центр на Asterisk заслуживает большего, чем оборванные звонки. Начните измерять, начните чинить и начните давать клиентам ту надёжную связь, которой они от вас ждут.
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.