Как проверить звонки amoCRM через Asterisk по шагам

Когда звонок из amoCRM не проходит через Asterisk, я сначала выясняю, на каком участке он пропал: CRM, интеграционный интерфейс, SIP-сигнализация или RTP-аудио. Порты и параметры зависят от выбранного коннектора, драйвера и схемы сети; проверять всё подряд — плохой способ диагностики.

Сначала определите, где обрывается вызов

Нажатие кнопки в amoCRM ещё не означает, что CRM сама устанавливает SIP-вызов. Интеграция обычно передаёт команду в телефонную инфраструктуру через коннектор, скрипт или интерфейс Asterisk, а уже АТС выбирает внутренний номер и маршрут к провайдеру. Поэтому фраза «не звонит из CRM» описывает симптом, но не называет виновника. Я записываю точное время попытки, пользователя, номер и результат: кнопка не отвечает, телефон не звонит, вызов сбрасывается или соединение есть без звука.

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

Разделяйте сигнализацию и звук. SIP организует вызов и согласует параметры соединения; RTP переносит аудио. Звонок, который не устанавливается, и звонок без голоса — разные неисправности. Во втором случае полезнее изучить адреса в SDP, сетевую маршрутизацию и RTP, чем снова проверять пароль от транка. Одна и та же кнопка в интерфейсе может запускать цепочку, но не делает все её звенья одним протоколом.

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

SIP ALG: проверяйте поведение, а не мифы

SIP ALG — помощник маршрутизатора для прохождения SIP через NAT. Он анализирует и может переписывать сигнализацию. Если конкретная реализация портит заголовки или адреса, вызовы действительно ломаются; поэтому в базе знаний отдельно отмечена проверка SIP ALG на MikroTik. Но правило «отключить его на любом роутере без раздумий» слишком широкое: оборудование, прошивки и схемы сети различаются. Я проверяю функцию в настройках устройства и связываю её состояние с наблюдаемым сбоем.

Для MikroTik база знаний указывает на раздел service-port в настройках межсетевого экрана, где проверяют состояние SIP-помощника и при необходимости отключают его. Точный способ зависит от модели и версии RouterOS: сверяйтесь с документацией именно вашей версии и согласуйте изменение с владельцем сети. После правки проверьте состояние и повторите вызов. На другом маршрутизаторе названия и действия будут другими; копировать команду вслепую — быстрый путь получить ещё одну проблему.

Если звонок срывается до ответа, сравните SIP-обмен на стороне АТС и данные, которые видит провайдер или шлюз. Важно понять, уходят ли запросы, приходят ли ответы и соответствует ли адрес в сигнализации реальному пути обратно. Если вызов устанавливается, а аудио одностороннее, переключитесь на RTP и SDP. Отключение ALG может оказаться полезным тестом, но оно не задаёт внешний адрес Asterisk и не открывает медиапорты само по себе.

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

• Зафиксировать модель и версию маршрутизатора
• Проверить состояние SIP ALG
• Повторить один и тот же тестовый вызов

NAT и внешний адрес: учитывайте SIP-драйвер

Когда Asterisk находится за NAT, удалённая сторона не должна получать в SIP или SDP адрес, до которого не может маршрутизировать пакеты. При вызове без звука это частая линия проверки: адрес медиапотока внутри SDP, адрес сигнализации в заголовках, соответствие локальных подсетей реальной сети и обратная маршрутизация. Публичный адрес может принадлежать маршрутизатору, а не самому серверу; важно описать фактическую топологию, а не просто вставить «внешний IP» в случайное поле.

Здесь особенно легко дать устаревший совет. sip.conf относится к драйверу chan_sip, а не является универсальным файлом настройки всех SIP-транков. По документации Asterisk, chan_sip признан устаревшим в ветке 17 и удалён в Asterisk 21. В актуальной конфигурации на res_pjsip проверяют транспорт в pjsip.conf: среди параметров для NAT документация называет local_net, external_media_address и external_signaling_address; также рассматривают direct_media на endpoint. Точный набор зависит от того, где находятся телефоны и как устроен медиамаршрут.

В PJSIP внешний адрес для RTP и внешний адрес для SIP-сигнализации решают связанные, но не тождественные задачи. local_net описывает сети, которые Asterisk считает локальными. При внешнем назначении адреса Asterisk может переписать SDP для RTP и сигнализацию отдельно. Неверная сеть в local_net, двойной NAT, несколько внешних адресов или разнесённые узлы сигнализации и медиа меняют картину. Поэтому копировать готовый пример с адресами и одним флагом nat=yes без изучения действующей схемы нельзя.

Если система действительно использует старый chan_sip, сначала подтвердите это по версии и загруженным модулям, затем сверяйтесь с документацией именно этого драйвера. Если используется PJSIP, не переносите значения старых директив в новую конфигурацию механически. После изменения перезагрузите применённую конфигурацию по принятой у вас процедуре и проверьте фактический SDP в тестовом вызове. Нужен наблюдаемый результат: удалённая сторона видит достижимый адрес и отправляет RTP именно туда.

Регистрация и аутентификация транка

Не каждый SIP-транк должен регистрироваться. Одни провайдеры требуют учётные данные и периодические REGISTER-запросы; другие сопоставляют вашу АТС по IP и принимают вызовы без регистрации. Это определяется договорённостью и инструкцией оператора, а не универсальным правилом Asterisk. Отключать регистрацию «на пробу» можно только как согласованный тест: так легко скрыть исходную ошибку или потерять входящие вызовы.

Если регистрация ожидается, проверьте адрес сервера и порт назначения, имя пользователя, пароль, транспорт и сетевой доступ. Сверьте настройки с карточкой услуги у провайдера: имя для аутентификации может отличаться от номера или имени транка. База знаний указывает команду asterisk -rx "pjsip show registrations" для просмотра регистраций PJSIP. Если в вашей установке используется иной драйвер или оболочка, применяйте соответствующую команду и интерпретируйте статус вместе с журналом попытки вызова.

Статус регистрации — только один сигнал. Успешный REGISTER не гарантирует, что разрешён исходящий вызов, что совпадает Caller ID или что оператор принимает выбранный кодек. И обратное: транк без регистрации может быть полностью штатным. Сопоставьте время вызова с журналом Asterisk и ответом провайдера, затем проверьте диалплан и правила маршрутизации. Не публикуйте пароли, секреты AMI и полные конфиги в тикете или чате: для диагностики достаточно замаскированных параметров и кодов ответа.

Ошибки авторизации разбирайте по участникам обмена. Убедитесь, какая сторона отвечает отказом, к какой учётной записи относится запрос и совпадает ли ожидаемая схема аутентификации. Если провайдер использует привязку по IP, перебор паролей не исправит неверный адрес источника. Если он ожидает регистрацию, отключение REGISTER только превратит понятную ошибку в молчащий транк. Сначала выясните условие услуги, затем изменяйте конфигурацию.

• Уточнить у оператора: регистрация или IP-аутентификация
• Сверить учётные данные и адрес назначения
• Проверить ответ провайдера на тестовом вызове

Интерфейс интеграции, AMI и порты

Сама связка с amoCRM — отдельный участок диагностики. Некоторые коннекторы используют AMI, другие обращаются через HTTP/AJAM, ARI или собственный модуль. Поэтому утверждение «для любой интеграции обязательно AMI» неверно. Сначала прочитайте документацию именно установленного виджета: в ней должны быть указаны интерфейс, адрес, метод подключения и требуемые сетевые направления. Устаревшая инструкция для одного скрипта не становится стандартом всей платформы.

AMI настраивается в manager.conf; это подтверждает документация Asterisk. Интерфейс позволяет клиенту управлять АТС и получать события, поэтому доступ к нему требует ограничений. Не выставляйте AMI в интернет с широкими правами. Используйте отдельную учётную запись интеграции, минимальные необходимые разрешения и ACL по адресам, откуда реально подключается коннектор. Если коннектор размещён локально, не открывайте порт наружу только потому, что так написано в старом примере.

Числа 443/TCP и 8088/TCP встречаются в инструкции VoxLink для конкретного варианта интеграции Asterisk и amoCRM. Это не универсальный список портов для всех виджетов. Порт 443 обычно нужен HTTPS-связи с CRM или веб-сервером по выбранной схеме; 8088 — стандартный порт встроенного HTTP-сервера Asterisk, но он не включён автоматически и сам факт его стандартности не означает, что его следует открыть всему интернету. В руководстве Asterisk для HTTP-сервера прямо указано, что его надо включить и задать адрес привязки.

Не смешивайте 8088 для HTTP/AJAM или ARI с SIP-портом и диапазоном RTP. RTP-настройки задаются отдельно в rtp.conf и сетевой политике, а конкретный диапазон нужно сверять с конфигурацией именно этой АТС. Вопрос «какие порты открыть?» без названия коннектора, транспорта, локальной схемы и направления соединения не имеет одного правильного ответа. Составьте таблицу: источник, назначение, протокол, порт, зачем требуется — и проверьте каждую строку по инструкции интеграции.

• Найти документацию установленного коннектора
• Проверить выбранный интерфейс Asterisk
• Ограничить доступ к AMI и HTTP

Порядок проверки и разбор примера

Я прохожу диагностику от CRM к телефону. Сначала повторяю вызов и сохраняю время, пользователя и наблюдаемый эффект. Затем выясняю, отправил ли коннектор запрос и куда; проверяю журнал интеграции и доступность её конечной точки. После этого смотрю события AMI/AJAM/ARI, если именно этот интерфейс использует модуль, и подтверждаю, что Asterisk получил команду. Далее проверяю создание канала и диалплан, ответ транка, а при установленном вызове — SDP и RTP. Так быстро становится ясно, какой журнал читать дальше.

В качестве условного примера оставлю компанию из исходного материала — ООО «Эльбрус». Менеджер нажимает кнопку, но настольный телефон не звонит. Это ещё не доказательство проблемы SIP ALG или внешнего IP. Сначала сравниваем вызов из CRM с ручным исходящим вызовом с того же внутреннего номера. Если вручную маршрут работает, проверяем запрос интеграции, её авторизацию и соответствие добавочного номера. Если не работает и вручную, переходим к транку, диалплану и ответу оператора.

Предположим, телефон звонит и вызов устанавливается, но собеседник не слышит сотрудника. Тогда сохраняем сигнализацию и SDP, смотрим, какие адреса и порты объявлены, доступен ли медиамаршрут через NAT, соответствует ли диапазон RTP конфигурации Asterisk и разрешён ли обмен в обе стороны. В этом сценарии замена SIP-пароля или публикация AMI не лечит аудио. Если SDP показывает внутренний адрес для внешнего собеседника, сверяем NAT-параметры используемого драйвера и только затем меняем конфигурацию.

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

• Один контрольный вызов из CRM
• Один контрольный вызов с телефона
• Отдельная проверка двустороннего аудио

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