Диагностика проблем с регистрацией и слышимостью

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

Проблема регистрации: телефон не в сети

Проблема регистрации — это состояние, при котором SIP-клиент (IP-телефон, софтфон или шлюз) не может авторизоваться на сервере Asterisk. Без этого сервер не знает, на какой IP-адрес отправлять входящий вызов.

Для диагностики используем метод исключения: от сетевого уровня к прикладному. Как показано в Схеме 1, процесс может прерваться на любом этапе.

1. Проверка статуса в CLI

Прежде чем анализировать дампы, проверьте состояние эндпоинта в консоли Asterisk:

asterisk -rvv
pjsip show endpoints

Статус Unavailable или Unknown означает, что сервер не получал от устройства успешных запросов.

2. Анализ SIP-сообщений в реальном времени

Включите логирование PJSIP, чтобы увидеть входящие пакеты:

pjsip set logger on

Возможны три сценария:

1. В консоли тишина. Пакеты не доходят до Asterisk. Проверьте firewalld на сервере и настройки NAT на роутере.
2. Ответ 401 Unauthorized. Это стандартный запрос пароля. Если за ним не следует повторный запрос с хешем пароля от клиента — устройство настроено неверно или «сдалось».
3. Ответ 403 Forbidden. Сервер отклонил регистрацию. Обычно это ошибка в пароле или включенная опция auth_rejection_permanent в настройках PJSIP.

---

Проблемы со слышимостью и RTP

Если регистрация активна и вызов устанавливается, возникают RTP-проблемы. Сигнализация (SIP) работает, но передача голоса (RTP) нарушена.

Односторонняя связь и тишина

Односторонняя связь — классический симптом проблем с NAT или маршрутизацией UDP-пакетов. Asterisk ожидает RTP-трафик на портах 10000–20000. Если роутер не знает, куда переслать ответные пакеты, один из собеседников ничего не услышит.

Пример

Если сервер за NAT, а параметр external_media_address не указан, Asterisk передаст в SIP-пакете свой локальный IP (например, 192.168.1.10). Удаленный клиент попытается отправить звук на этот адрес, который недоступен из интернета.

Для быстрой диагностики используйте встроенную команду:

rtp set debug on

• Got RTP packet from... — пакеты приходят на сервер.
• Sent RTP packet to... — сервер отправляет пакеты.

Если вы видите только исходящие пакеты (Sent), но не видите входящих (Got) — трафик блокирует сетевой экран или NAT перед сервером.

Алгоритм устранения проблем со звуком

1. Диапазон портов. Убедитесь, что UDP 10000–20000 открыты на всех файрволах.
2. Symmetric RTP. В настройках PJSIP-экстеншена включите rtp_symmetric=yes. Это заставит Asterisk отправлять звук на тот IP и порт, с которых он сам получил первый RTP-пакет, игнорируя (возможно, неверные) данные из заголовков SIP.
3. Direct Media. Отключите direct_media, чтобы звук всегда шел через Asterisk. Это упрощает отладку.

Упражнение

Проверьте состояние RTP-потоков:

1. Совершите звонок между двумя номерами.
2. В консоли введите rtp set debug on.
3. Убедитесь, что видите строки Got RTP от обоих участников. Если от одного их нет — вы нашли сторону, где блокируется трафик.
4. Выключите отладку: rtp set debug off.

Мы научились проверять прохождение пакетов на уровне протоколов. Но если регистрация есть и звук ходит, а звонок обрывается с ошибкой «Номер не существует» — проблема в логике. В следующей теме разберем, как Asterisk принимает решения внутри себя и как искать ошибки в диалплане.