Звонок прошёл, а карточки в 1С нет: что проверить в Asterisk

Если разговор состоялся, а записи в 1С нет, сначала проверьте не только SIP и RTP, но и отдельный канал передачи событий в интеграционный модуль. Я покажу, как разделить эти участки, проверить NAT и Docker и найти конкретное место, где вызов перестал превращаться в карточку.

Сначала разделяю звонок и запись в 1С

Если телефон звонит, а карточка не появляется в 1С, я сначала разделяю две задачи: прохождение вызова и передачу события в учётную систему. У SIP есть сигнализация, у RTP — аудио, а интеграция получает сведения о состоянии каналов через отдельный механизм. Успешный разговор доказывает только то, что конкретный вызов прошёл по телефонному маршруту. Он не доказывает, что интеграционный модуль получил событие, сопоставил номер с контактом и записал результат в 1С. Именно здесь обычно и прячется ошибка: проверяют трубку, а не путь данных до карточки. В условном кейсе ООО «Вереск-Плюс» я бы начал с журнала интеграционного модуля и времени конкретного тестового вызова. Есть ли событие на стороне Asterisk? Получил ли его промежуточный сервис? Какой ответ вернула 1С? Сверяю идентификатор вызова, номер, направление и время на каждом участке. Если журнал Asterisk показывает вызов, а приложение его не видит, искать неисправность в кодеке преждевременно. Если событие дошло до приложения, но 1С не создала карточку, проверяю формат номера, права, сопоставление контакта и ответ API. У Asterisk нет универсальной кнопки «отправить вебхук в 1С». Для обмена используют подходящий интерфейс и отдельный обработчик: например, AMI передаёт события управления, а ARI предоставляет REST API и события через WebSocket. Конкретный путь зависит от интеграционного модуля и конфигурации. Поэтому я сначала выясняю, какой компонент должен передать событие и где он журналирует результат. Иначе можно часами настраивать NAT, хотя сигнализация и аудио уже работают, а сбой — в учётной записи или обработчике события.

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

• Проверить событие в Asterisk
• Найти его в журнале интеграции
• Сверить ответ и запись 1С
• Сравнить номер и время вызова

NAT в PJSIP: проверьте адреса и подсети

Когда вызов не устанавливается или слышимость односторонняя, проверяю NAT и адреса, которые Asterisk помещает в SIP и SDP. В конфигурации PJSIP параметры local_net, external_media_address и external_signaling_address относятся к транспортному объекту. Первый описывает локальные сети; два других помогают подставлять внешний адрес в сигнализацию и описание медиапотока для удалённой стороны. Это не универсальные обязательные строки для любого сервера. Их значения зависят от схемы сети, а при прокси в той же сети документация Asterisk отдельно предупреждает не переносить NAT-параметры вслепую. Я сверяю реальный внешний адрес, локальные подсети, адрес прослушивания транспорта, правила NAT и то, что видно в SDP. Не указываю здесь шаблонный конфиг как рецепт: правильные значения без топологии неизвестны. Если сигнализация содержит частный адрес, недоступный провайдеру, или RTP объявлен на неверном адресе, удалённая сторона не сможет корректно ответить. Но это объясняет проблемы установления вызова или аудио, а не автоматически пустую историю 1С. Для пустой карточки отдельно прослеживаю событие интеграции. В кейсе «Вереск-Плюс» сначала фиксирую один звонок с точным временем и проверяю, куда направлены SIP-ответы и медиапоток. Затем сравниваю внешний адрес в настройках PJSIP с тем, который видит удалённый узел, и проверяю разрешённые адреса у оператора, если транк привязан к IP. После каждого изменения делаю один контрольный вызов и записываю результат. Перезапускать или менять сразу несколько узлов — удобный способ потерять причинно-следственную связь; сеть такого энтузиазма не оценит.

Для диагностики смотрю конфигурацию именно того транспорта, которым пользуется endpoint, и учитываю, что изменения transport в PJSIP требуют корректного применения конфигурации. Не добавляю external_media_address только потому, что где-то есть NAT: если Asterisk и посредник находятся в одной локальной сети, внешняя подстановка может быть неуместна. Проверяю вызов с обеих сторон и сверяю SDP, а не угадываю по факту «трубку подняли». Для регистрации, маршрута, аудио и записи в 1С нужны разные подтверждения.

SIP ALG: проверяйте как гипотезу

SIP ALG — механизм сетевого оборудования, который может вмешиваться в SIP-трафик и переписывать адреса или порты. Если после его работы заголовки или адрес в SDP расходятся с реальной схемой, вызов может регистрироваться нестабильно, не устанавливаться или давать односторонний звук. В базе знаний сайта есть практическая рекомендация проверить и отключить SIP ALG на MikroTik при проблемах VoIP. Я использую её как проверяемую гипотезу, не как закон природы: симптомы должны совпасть, а после изменения нужен контрольный вызов. Не любое устройство на MikroTik обязательно ломает Asterisk, и выключение ALG не гарантирует, что появятся записи в 1С. Сначала фиксирую состояние до изменения, выясняю, где включена обработка SIP в конкретной модели и версии RouterOS, затем отключаю её только если это допустимо в данной сети. Сравниваю пакеты до и после, проверяю регистрацию, установление вызова и RTP. Если SIP-поток не меняется или проблема остаётся, возвращаюсь к другим участкам: правилам firewall/NAT, PJSIP и интеграции. В случае «Вереск-Плюс» я бы не писал в отчёт «ALG был причиной» только потому, что после перезагрузки стало лучше. Для доказательства нужны наблюдаемый дефект и повторяемая проверка: тот же маршрут, такой же тест, понятный результат. Если после отключения ALG аудио восстановилось, это подтверждает сетевую проблему с медиапотоком. Если звонки и звук в порядке, но событие не доходит до 1С, решение нужно искать в AMI/ARI-клиенте или модуле интеграции. Точная диагностика скучнее магии, зато не требует второй раз чинить то, что уже работало.

Путь настройки зависит от оборудования и прошивки; поэтому я не даю выдуманную универсальную команду RouterOS. Проверяю актуальную документацию именно для установленной версии и экспорт действующих правил. Важно также не спутать ALG с фильтрацией: одно может переписывать содержимое SIP, другое — блокировать пакеты. Сетевые журналы и захват трафика позволяют увидеть разницу. И да, одна галочка в маршрутизаторе иногда влияет на телефонию, но CRM от этого не начинает понимать события сама.

• Зафиксировать симптомы до правки
• Проверить правила SIP и NAT
• Отключить ALG для контрольного теста
• Сравнить сигнализацию и аудио

PJSIP, контекст и кодеки: не смешивайте причины

В PJSIP проверяю, что входящий запрос сопоставляется с нужным endpoint, у endpoint указан ожидаемый context, а dialplan действительно содержит маршрут для этого вызова. Контекст определяет, куда попадёт канал внутри диалплана; это не поле для настройки истории 1С. Если неверен endpoint или маршрут, вызов может быть отклонён либо попасть не туда. Если звонок успешно дошёл до абонента, а карточки в 1С нет, одна лишь смена context не является обоснованным исправлением. Сначала устанавливаю, в каком компоненте потерялось событие. Кодеки согласуют стороны для передачи аудио. Несовместимость способна испортить или сорвать звук, но не объясняет сама по себе, почему приложение не создало запись о вызове. Проверяю разрешённые кодеки и транскодирование тогда, когда есть аудиосимптомы или ошибки согласования. Транспорт UDP, TCP или TLS выбирают в соответствии с настройкой оператора и endpoint; утверждать, что UDP обязателен для любой интеграции 1С, нельзя. Транспорт SIP также не заменяет отдельный интерфейс событий. Отдельно поправлю устаревший совет «просто переходите с chan_sip на PJSIP». Документация Asterisk говорит точнее: chan_sip объявлен устаревшим в Asterisk 17 и удалён в Asterisk 21. Это аргумент учитывать версию при планировании обновления, а не причина срочно мигрировать любой работающий старый сервер ради истории звонков. На поддерживаемой конфигурации проверяю фактический драйвер и его доступность; миграцию делаю как отдельную работу с тестированием регистрации, входящих и исходящих маршрутов.

При разборе транка не полагаюсь на слово «зарегистрирован» как доказательство полного здоровья: регистрация подтверждает один механизм авторизации, но не правильность входящего сопоставления, dialplan, аудио и интеграции. Для PJSIP полезно посмотреть, загружен ли endpoint, подходит ли входящий адрес под правила identify и что пишет CLI при тестовом вызове. Лишь после этого связываю конкретную ошибку с настройкой. Конфигурация не становится виноватой только потому, что в ней много секций.

Docker: отдельно проверьте SIP и RTP

В контейнерной установке я сначала выясняю сетевой режим и какие порты реально использует конфигурация Asterisk. SIP несёт сигнализацию, а RTP — медиапоток; публикация только SIP-порта не гарантирует звук. Диапазон RTP задаётся конфигурацией Asterisk, поэтому открывать нужно тот диапазон, который настроен в конкретной системе, для нужного протокола и направления. Не подставляю диапазон из случайной инструкции и не утверждаю, что событие для 1С передаётся через RTP: это разные каналы. В Docker bridge-сеть позволяет публиковать порты контейнера на адресах хоста. Проверяю соответствие публикации фактическим портам Asterisk и правилам firewall, затем делаю вызов и смотрю, приходит ли RTP. Режим host — другой вариант: контейнер использует сетевой стек хоста, а публикация портов не применяется. Это не волшебный переключатель, который всегда исправляет VoIP; учитываю платформу, занятые порты и требования изоляции. На Docker Desktop поведение host имеет дополнительные ограничения по сравнению с Linux. События в учётную систему идут по настроенному интерфейсу интеграции — например, по отдельному соединению AMI либо приложению ARI, если именно так устроено решение. Поэтому кроме SIP/RTP проверяю сетевую доступность этого интерфейса между компонентами, правила доступа и журнал клиента. Не придумываю «улучшение ulimits», если нет признака исчерпания дескрипторов или другого лимита. Для проблемы без симптомов ресурса это будет шумная настройка наугад.

В «Вереск-Плюс» разбирал бы конфигурацию Compose, фактические слушающие сокеты, публикацию портов и маршрут от Asterisk до интеграционного сервиса. Затем отдельно проверил бы поток RTP и получение события. Если используется Docker Desktop, проверил бы его сетевые особенности; если Linux host mode — убедился бы, что порт не занят другим процессом. На каждом этапе сохраняю результат теста. Просто работающий контейнер — это только запущенный процесс, а не доказательство доступности всех его сетевых функций.

• Сверить режим сети контейнера
• Проверить опубликованные SIP-порты
• Сверить настроенный диапазон RTP
• Проверить доступ к интерфейсу интеграции

Диагностируйте по одному участку

Для PJSIP штатная CLI-команда включает SIP-логирование так: pjsip set logger on. В руководстве Asterisk для сбора диагностики также приведены core set verbose 4 и core set debug 4. Включаю подробный вывод на время одного теста, сопоставляю его со временем в приложении и затем выключаю лишнюю трассировку. SIP-логи могут содержать номера, адреса и служебные данные, поэтому храню их ограниченно и перед отправкой кому-либо очищаю от чувствительной информации. Коды 401 и 407 часто участвуют в штатном обмене аутентификацией: сами по себе они не доказывают поломку. Проверяю, последовал ли запрос с credentials и принял ли его сервер. Ответ 403 обычно означает отказ, но причину выясняю в журнале и настройках конкретной стороны, а не по одному числу. Для проверки endpoint использую вывод PJSIP CLI; для сетевого пути — захват пакетов на соответствующей точке. tcpdump показывает обмен пакетами, но сам не устанавливает, почему 1С не создала запись. Дальше прохожу путь события: журнал Asterisk, AMI/ARI-клиент или коннектор, промежуточная служба, ответ интеграционного API и запись в 1С. Сверяю номер в нормализованном виде, идентификатор звонка, направление и состояние вызова. Меняю одну настройку за раз и повторяю тот же тест. В кейсе «Вереск-Плюс» только после подтверждения места потери я бы называл исправление: если событие не покинуло АТС — настраиваю канал событий; если пришло в коннектор, но отвергнуто 1С — разбираю формат, права и ответ приложения.

Не обещаю «исправить за час» или восстановить историю завтра: срок зависит от того, какая интеграция установлена и доступны ли журналы всех компонентов. Если нужна помощь, мы в «АйТи-Фреш» можем обследовать маршрут вызова, проверить PJSIP и сеть, затем вместе с владельцем 1С проследить доставку события и оформить точечное исправление. Начинаем с одного воспроизводимого звонка. Так в отчёте будет не перечень подозрительных параметров, а конкретный участок сбоя и проверенный результат.

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