Где пропадает вызов между Asterisk и GSM-шлюзом

Если вызов пропадает между Asterisk и GSM-шлюзом, сначала определите, на каком участке он исчезает: до АТС, в маршруте, на очереди или уже в мобильной сети. Я покажу, какие записи действительно помогают, как проверить SIP-состояние и почему одно событие ABANDON ещё не обвиняет шлюз.

Где искать потерю: в шлюзе, Asterisk или дальше?

Я разбираю такие сбои по ходу конкретного вызова. Сначала выясняю, где он должен появиться: приходит ли звонок из GSM-сети через шлюз в Asterisk или АТС отправляет его через шлюз наружу. Направление важно: регистрация, контекст диалплана и очередь участвуют не во всяком сценарии. Если нужен внешний разбор всей телефонии, мы занимаемся обслуживанием ИТ-инфраструктуры, но первый диагностический шаг можно сделать и самостоятельно.

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

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

В условном примере из задания возьму ООО «Хрусталь-Сервис»: у компании есть офисная АТС и аппаратный GSM-шлюз, а жалоба звучит как «часть вызовов не проходит». Данных о модели шлюза, версии Asterisk, операторе и сетевой схеме нет, поэтому я не выдаю догадку за найденную причину. Покажу порядок проверки: каждая гипотеза должна подтвердиться в журнале или уступить место следующей.

Для разборчивого теста я веду короткую таблицу: направление, время по часам сервера, ожидаемый маршрут, последний подтверждённый шаг и результат на телефоне. Затем сравниваю неудачный вызов с успешным на том же направлении. Если одновременно менялись оператор, SIM, настройки шлюза и диалплан, причинность уже не установить. Фиксирую исходную конфигурацию и после каждой корректировки повторяю одинаковый тест. Иначе через полчаса никто не помнит, что именно «починило» звонки.

• Запишите время одного контрольного вызова.
• Уточните направление: GSM-вызов в АТС или из АТС.
• Отметьте последний этап, где вызов ещё виден.
• Сравнивайте только записи одного вызова.

Что означает ABANDON в queue_log?

ABANDON — это запись о том, что абонент покинул очередь до соединения с её участником. В ней указаны позиция вызова, исходная позиция и время ожидания. Сама запись не говорит, что GSM-шлюз потерял регистрацию, не получил канал или отказал в вызове. Если приписать ей такую причину без соседних событий, отчёт станет уверенным, но неверным.

Событие полезно только для вызова, который действительно дошёл до приложения Queue. В штатной файловой конфигурации queue_log обычно находится в /var/log/asterisk/queue_log, но расположение и способ хранения могут быть переопределены. Сначала убедитесь, что на этой АТС ведётся файловый журнал очередей, затем сопоставьте время, имя очереди и уникальный идентификатор вызова с другими записями.

Читайте соседние события, а не один ярлык. ENTERQUEUE подтверждает вход вызова в очередь; RINGNOANSWER означает, что попытка дозвониться до участника очереди завершилась без ответа; TRANSFER фиксирует перевод на другой внутренний номер. Эти записи сужают место поиска, но не заменяют проверку SIP-обмена со шлюзом. Если вызов вообще не проходил через Queue, отсутствие строки queue_log ожидаемо.

Если вызов пришёл через очередь, полезно сопоставить несколько строк одного идентификатора, а не читать запись отдельно. В queue_log есть время, идентификатор канала, имя очереди, канал участника, тип события и дополнительные поля. Так можно увидеть, вошёл ли вызов в очередь, звонили ли участнику и чем закончился этот этап. Для звонка, который ушёл из диалплана сразу на шлюз, ищите продолжение в журнале канала и самого устройства.

Есть и другие полезные окончания очереди. CONNECT фиксирует соединение с участником, EXITEMPTY — выход по правилу для очереди без доступных участников, EXITWITHKEY — выход по выбранной клавише, EXITWITHTIMEOUT — окончание ожидания по тайм-ауту. Эти события помогают отделить ожидание в очереди от отказа внешнего направления. Если проверка упирается в стратегию распределения или доступность участников, смотрите настройку очередей Asterisk, а не меняйте параметры GSM-линии наугад.

• ABANDON — абонент вышел из очереди.
• RINGNOANSWER — участник очереди не ответил.
• TRANSFER — вызов перевели на другой номер.

Какие логи Asterisk смотреть при сбое?

В Asterisk нет универсального файла main.log, sip.log или pjsip.log, который обязательно появится на каждом сервере. Состав журналов задаётся настройкой logger.conf: события можно направлять в файлы, консоль или системный журнал, а имя файла и уровни сообщений выбирает администратор. Поэтому сначала смотрю конфигурацию логирования и фактические каналы вывода, а не ищу файлы по названию из чужой инструкции.

Для одного контрольного звонка сопоставьте время и идентификатор канала в записях Asterisk с событиями queue_log и журналом самого GSM-шлюза. Ищите последовательность: входящий SIP-запрос, выбор endpoint, ответ на запрос, переход в диалплан, набор номера и завершение канала. Формулировки зависят от драйвера и версии; важны не знакомые слова сами по себе, а то, какой шаг подтверждается и какого ответа после него не видно.

Если обычного журнала недостаточно, подробную PJSIP-трассировку можно включить на время повторного контрольного вызова командой pjsip set logger on. После проверки выключите её и ограничьте доступ к собранным данным: документация Asterisk отдельно предупреждает, что консоль и логи могут содержать пароли и историю звонков. Отправлять такой архив в общий чат — плохой способ диагностики.

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

События шлюза — вторая половина картины. Если его панель или журнал показывает попытку вызова, а Asterisk её не видит, проверьте, на какой адрес и интерфейс устройство отправляет SIP, и есть ли соответствующая запись на стороне сети. Если запрос появился в CLI, но в файловом журнале пусто, проверьте syslog и настройки logger.conf. Для сравнения оставьте узкий временной интервал вокруг теста, скройте номера и учётные данные, прежде чем передавать материалы подрядчику.

Как проверить SIP-регистрацию GSM-шлюза?

Сначала определите, кто именно регистрируется. В одном варианте Asterisk отправляет регистрацию на сервер шлюза или оператора; в другом шлюз регистрируется на Asterisk как endpoint; некоторые устройства работают без регистрации. Надпись «Registered» у одной стороны не гарантирует, что другая сторона настроена так же. Проверяйте роль каждой учётной записи по конфигурации обеих систем.

Для PJSIP команда pjsip show registrations показывает исходящие регистрации, созданные на стороне Asterisk. Она не является универсальной проверкой устройств, которые сами регистрируются на Asterisk. Для просмотра настроенных PJSIP endpoint в CLI используется pjsip show endpoints; результат сопоставьте с журналом попытки и состоянием контакта шлюза. Команда должна отвечать на конкретный вопрос, а не служить ритуалом «проверили SIP».

При отказе сверяйте адрес сервера, имя учётной записи, пароль и способ аутентификации на обеих сторонах, а также сетевую доступность в момент теста. Если связь раньше работала, выясните, что менялось: маршрутизатор, адресация, учётные данные, настройки NAT, прошивка или конфигурация АТС. DDNS не чинит регистрацию сам по себе и не заменяет проверку того, куда устройство реально отправляет SIP-запрос.

Смотрите на статус вместе со временем и контекстом. Для исходящей регистрации PJSIP состояние Unregistered может появиться до первой успешной регистрации или после её истечения; Rejected указывает, что попытка закончилась отказом. Важнее не выхватить одно слово из вывода, а проверить, повторяется ли попытка, какой ответ приходит и что показывает журнал удалённого устройства. Если конфигурация шлюза предусматривает работу без регистрации, статус регистрации вообще не будет критерием его доступности.

Не смешивайте регистрацию и возможность выполнить вызов. Зарегистрированный endpoint может не иметь подходящего маршрута, свободной SIM-линии или разрешения на нужное направление; а шлюз, настроенный без регистрации, всё равно может быть доступен по другому сценарию. Поэтому после проверки состояния сделайте один исходящий и один входящий тест, если оба направления используются. В практическом руководстве по PJSIP отдельно разобраны объекты и связи PJSIP.

• Установите, какая сторона выполняет регистрацию.
• Для PJSIP проверьте endpoint и исходящие регистрации раздельно.
• Сверьте отказ в CLI с журналом шлюза.
• Повторите проверку во время сбоя.

Как исключить ошибку номера и диалплана?

Если SIP-обмен состоялся, но вызов ушёл не туда или сразу завершился, я проверяю набираемое значение и маршрут. Сравните номер, который Asterisk получил от шлюза, номер, который диалплан передал дальше, и формат, ожидаемый конкретной SIM-линейкой или оператором. Плюс, код страны и префикс могут иметь значение, но нельзя заранее объявить один формат правильным для всех шлюзов.

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

Меня интересует не только строка в конфигурационном файле, но и результат конкретного вызова. Сверьте загруженный диалплан, записи CLI и журнал шлюза; затем меняйте одно условие и повторяйте тест. Так видно, исправило ли преобразование причину. Пакет из нескольких случайных замен может временно убрать симптом, но потом никто не вспомнит, какое правило изменило поведение и почему.

Не исправляйте формат номера по принципу «везде надо убрать плюс». Настройте тест с известным входным номером и запишите три значения: что пришло в SIP-сообщении, что выбрал диалплан и что шлюз отправил на линию. Если меняется только один символ, результат покажет конкретное правило преобразования. Для входящего вызова отдельно проследите номер назначения и контекст, куда попал запрос; Caller ID абонента и DID назначения отвечают на разные вопросы.

Для проверки правил заведите разрешённое тестовое направление и запишите его до и после преобразования. Входящий Caller ID показывает, кто звонит; DID указывает, на какой номер пришёл вызов. Они могут участвовать в разных условиях маршрута, поэтому подмена одного другим скрывает ошибку, а не исправляет её. Проверяйте входящий и исходящий сценарии отдельно: у них разные начальная строка, выбранная линия и контекст. После правки сначала повторите тот же контрольный звонок, затем убедитесь, что соседние направления не попали под новое условие.

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

Когда проверять RTP, NAT и сетевые правила?

Если соединение устанавливается, но слышит только одна сторона или нет звука вовсе, переходите к медиапотоку. SIP управляет сигнализацией, RTP переносит аудио; успешный ответ на SIP-вызов сам по себе не доказывает, что аудиопакеты проходят в обе стороны. Проверьте, какие адреса и порты объявлены в параметрах медиа и соответствуют ли они реальной схеме сети.

При NAT сверяйте настройки Asterisk с фактической топологией и разрешёнными диапазонами сигнального и медиатрафика. Значения зависят от конфигурации: слепо открывать любые порты или добавлять STUN как универсальное лекарство не нужно. В документации Asterisk для PJSIP отдельно описаны сетевые параметры сигнализации и RTP, а также поведение endpoint за NAT; применяйте их только после определения, где именно меняется адрес или теряется пакет.

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

Сигнализация и аудио требуют разных наблюдений. Если вызов завершился до ответа, сначала выясняйте, кто и почему завершил SIP-обмен; проверять RTP на этом шаге бессмысленно. Если вызов принят, но слышимость односторонняя, сопоставьте адрес медиа в SIP/SDP с направлением фактического трафика и правилами фильтрации. Открытый порт сигнализации не подтверждает прохождение RTP, а успешный RTP-тест не исправляет неверный маршрут номера.

Проверяйте медиапуть с той стороны сети, где возникает жалоба. Вызов из локальной сети может обходить NAT и фильтры, поэтому успешный внутренний тест не гарантирует работу удалённого устройства или мобильного направления. Сопоставьте IP-адрес в SDP, фактические сетевые интерфейсы и разрешения межсетевого экрана для обеих сторон аудио. Номера портов и диапазоны берите из конфигурации именно этой системы, а не из случайного примера. Для отдельного разбора есть руководство по PJSIP и NAT.

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

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