Troubleshooting SIP

Назначение и область применения#

Документ описывает диагностику и устранение проблем SIP-контура SmartCPD: компоненты balancer, mgw, amd, типовые SIP-ошибки, переменные сервисов и трассировку в Homer.

Это не общий runbook по контуру и не инструкция по проектированию SIP. Первичная диагностика платформы, портал, лицензия, метрики и не-SIP сервисы — в Troubleshooting. Проектирование и call flow — в SIP.

Аудитория#

• инженер внедрения;
• техническая эксплуатация;
• support;
• DevOps на стороне заказчика.

Границы документа#

Входит#

• управление переменными SIP-сервисов для диагностики;
• состав и роли balancer, mgw, amd;
• типовые проблемы и ошибки SIP-компонентов;
• диагностика amd и связанного CDR;
• SIP-трассировка в Homer;
• быстрый справочник по симптомам.

Не входит#

• общая экспресс-диагностика контура, портал, лицензия, метрики — Troubleshooting;
• установка и первичный setup — Установка, Docker;
• SIP-проектирование, транки и call flow — SIP;
• ведение проекта внедрения — Внедрение;
• устройство observability-контура — Мониторинг.

1. Управление переменными сервисов#

Параметры сервисов рекомендуется изменять через конфигурацию стека.

Для временного изменения переменной можно использовать:

docker service update \
  --env-add VAR=NEW_VALUE \
  smartcp_<service>

Например:

docker service update \
  --env-add X_LOGLEVEL=4 \
  smartcp_balancer

Важно:

• после выполнения docker service update сервис перезапускается;
• изменение действует до следующего передеплоя стека;
• временное изменение необходимо зафиксировать в заявке;
• после диагностики следует вернуть исходное значение или внести изменение в стек штатным способом.

Все SIP-компоненты должны использовать одну и ту же версию. Использование компонентов разных версий не гарантирует совместимость. Исключение допускается только для hotfix-патчей конкретного сервиса.

2. Состав SIP-компонентов#

2.1. balancer#

balancer — пограничный SIP-компонент SmartCPD, выполненный на OpenSIPS.

Сервис:

• работает в сетевом режиме host;
• принимает SIP-трафик от дайлера;
• добавляет в INVITE параметры клиента, маршрутизации и уникальный UUID вызова;
• передает вызов на воркер;
• принимает обратный вызов от воркера;
• направляет вызов на SBC или SIP-провайдера;
• применяет настройки транков и маршрутизации из веб-портала продукта;
• выполняет защиту от DDoS-подобных запросов;
• контролирует доступность воркеров.

2.1.1. Переменные окружения#

В облачной инсталляции BALANCER_MIHTTP_ENABLE включен.

2.1.2. Уровни логирования#

Допустимые значения:

X_LOGLEVEL=3 является штатным и наиболее информативным уровнем для анализа SIP-флоу.

Повышение O_LOGLEVEL допустимо только:

• для тяжелых случаев отказа ПО;
• на тестовых или стендовых окружениях;
• по согласованию с ответственными специалистами.

В продуктивной среде повышать O_LOGLEVEL не следует.

2.1.3. MI HTTP#

При включенном MI HTTP интерфейс доступен по адресу:

http://<BALANCER_IP>:<BALANCER_MIHTTP_PORT>/mi/

При значениях по умолчанию:

http://<BALANCER_IP>:8088/mi/

2.2. mgw#

mgw — сервис поддержки SIP-сигнализации, выполненный на OpenSIPS.

Сервис:

• принимает вызов от balancer;
• распаковывает параметры детекции из SIP-заголовков;
• удерживает вызов;
• принимает обратный вызов от amd;
• отправляет его балансировщику, с которого пришел исходный вызов;
• после соединения с абонентом выводит amd из вызова;
• соединяет плечи A и B через B2B-прокси;
• предоставляет метрики Prometheus для Grafana;
• проверяет доступность движка детекции через REST health check;
• сообщает балансеру о своей доступности через SIP OPTIONS.

Если движок детекции недоступен, mgw возвращает 503 на OPTIONS. В результате балансер исключает ноду из балансировки.

Потеря части воркеров может привести к:

• перегрузке оставшихся воркеров;
• увеличению времени обработки;
• росту числа отказов.

2.2.1. SIP-порты#

2.2.2. Переменные окружения#

MGW_MODE не следует переопределять.

Все функциональные отказы возвращаются с кодом и причиной, заданными FUNCTIONAL_CODE и FUNCTIONAL_REASON, а также с заголовком:

X-AMD-STATUS: functional

2.3. amd#

amd — сервис обеспечения медиавзаимодействия для SIP, выполненный на Asterisk.

Сервис:

• получает команду от mgw по ARI;
• инициирует дозвон до абонента через mgw;
• записывает раннее медиа при наличии ответа 183 с SDP;
• передает аудио на анализ движку детекции через REST после получения 200 OK;
• при отсутствии признаков автоответчика в раннем медиа записывает аудио средствами Asterisk;
• передает запись на анализ после завершения записи;
• при наличии соответствующей настройки записывает события о звонках в БД CDR.

Именно amd отвечает за запись вызовов в CDR.

Если проблема относится к работе движка детекции, БД или другого внешнего сервиса, необходимо обратиться к соответствующему разделу документации.

3. Типовые проблемы balancer#

3.1. Сервис не запускается#

Симптом#

В логах присутствует сообщение:

Config-server unavailable, restarting...

Диагностика#

Получить логи сервиса:

docker service logs smartcpd_balancer --no-trunc -f

Проверить:

• доступность сервиса конфигурации;
• сетевое соединение между balancer и сервисом конфигурации;
• разрешение имени сервиса;
• наличие необходимых параметров конфигурации;
• состояние контейнеров сервиса конфигурации.

Устранение#

Провести диагностику сервиса конфигурации. После восстановления его доступности проверить автоматический запуск balancer.

3.2. Нет реакции на INVITE#

Возможная причина#

IP-адрес шлюза источника запросов помещен в черный список DDoS-защиты.

Диагностика по логам#

Проверить наличие сообщения:

[DDoS] Dropped INVITE from <IP_ADDRESS> cause=bl_count=11

Диагностика через MI HTTP#

Запросить содержимое коллекции блокировок:

/cachedb_local/cache_fetch_chunk?arg=["*"%2C"collection5"]

В ответе будет JSON со значениями вида:

name: <IP_ADDRESS>
value: <INVALID_ATTEMPT_COUNT>

Если значение счетчика равно 11, запросы с этого IP игнорируются.

Устранение#

Удалить IP-адрес из списка блокировок:

/cachedb_local/cache_remove_chunk?arg=["<IP_ADDRESS>"%2C"collection5"]

После удаления проверить повторную обработку INVITE.

3.3. Нет реакции на OPTIONS#

Возможная причина#

balancer не работает с публичными адресами напрямую и не bind-ит их интерфейсы. Для подключения используются DNAT и SNAT.

Прохождение пакетов через NAT в Linux контролируется модулем conntrack, который кэширует состояния соединений и маршрутов.

Если шлюз клиента некоторое время был недоступен, conntrack может сохранить состояние недоступности. В результате система перестает предпринимать попытки отправить запрос или ответ этому шлюзу.

Диагностика#

Проверить:

• наличие SIP-пакетов на интерфейсе;
• правила DNAT и SNAT;
• состояние сетевого интерфейса;
• наличие записей и состояний conntrack;
• доступность шлюза клиента.

Устранение#

При подтверждении проблемы очистить соответствующую запись или кэш conntrack вручную согласно процедурам эксплуатации операционной системы.

После очистки проверить прохождение:

• OPTIONS от балансера к шлюзу;
• ответов от шлюза;
• повторной регистрации или SIP-доступности транка.

3.4. INVITE отклоняется с кодом 401 Unauthorized#

Возможная причина 1: неавторизованный шлюз#

Проверить:

1. настройки транка на веб-портале продукта;
2. наличие транка в настройках маршрутизации;
3. соответствие IP-адреса и порта источника настроенному транку;
4. логи balancer.

При первом запросе балансер получает учетные данные из сервиса конфигурации. При успешном поиске появляется сообщение:

[CONFIG] New valid trunk found udp:192.168.31.245:6060 for trunksegment 0011223344/597ba2e4-6196-49ad-ab87-8230f6c4d0e2

Данные сохраняются в локальный кэш.

При отсутствии авторизации:

• увеличивается счетчик неудачных попыток;
• запросы с этого IP:PORT отклоняются примерно 30 секунд;
• повторный запрос к сервису конфигурации в этот период не выполняется;
• при достижении 11 невалидных попыток IP блокируется на один час.

Признак валидного входящего запроса#

При успешной авторизации в логе появляется:

[PBX] New inbound INVITE request from udp:192.168.31.245:6060 for segment ID 0011223344/597ba2e4-6196-49ad-ab87-8230f6c4d0e2

Сообщение содержит:

• источник запроса;
• SIP-метод;
• идентификатор сегмента;
• параметры детекции.

Возможная причина 2: 401 от SBC или провайдера клиента#

В схеме B2B ответ 401 Unauthorized может быть сформирован не balancer, а SBC или SIP-провайдером клиента.

В этом случае необходимо:

1. открыть SIP-трассировку;
2. определить, на каком плече сформирован ответ;
3. проверить настройки авторизации на стороне SBC или провайдера;
4. обратиться к соответствующему разделу документации по интеграции с SBC или провайдером.

3.5. Вызовы завершаются с кодом 408 Timeout#

Возможные причины#

• на вызов SmartCPD в сторону SBC или провайдера нет ответа;
• SBC или провайдер возвращает 408;
• ответ теряется на сетевом уровне;
• проблема связана с маршрутизацией, NAT или доступностью внешнего узла.

Диагностика#

Требуется доступ к SIP-трассировке.

Необходимо определить:

• отправлялся ли запрос на SBC или провайдера;
• какой узел не ответил;
• был ли получен ответ от внешнего узла;
• на каком плече сформирован 408;
• соблюдаются ли тайминги SIP-диалога.

3.6. INVITE отклоняется с кодом 500 Service full#

Причина 1: все воркеры заняты#

Все доступные воркеры заняты либо не имеют ресурсов для нового вызова.

Диагностика#

Проверить:

• общую нагрузку кластера;
• ошибки и отказы движка детекции;
• количество активных SIP-сессий;
• значение load на каждом воркере;
• соответствие текущей нагрузки параметру max.

При устойчивой перегрузке необходимо пересмотреть сайзинг продукта.

Причина 2: недоступен resolver#

balancer получает адреса воркеров через сервис resolver. Если resolver недоступен, балансер не может получить актуальный список воркеров и отклоняет все вызовы.

Необходимо провести диагностику сервиса resolver.

Проверка списка воркеров через MI HTTP#

Выполнить запрос:

/load_balancer/lb_list

Список не должен быть пустым.

Для каждого воркера проверить раздел Resources:

Ожидаемые условия:

load < max
enabled = true

Проверка логов#

Проверить сообщения с тегом:

[DISPATCHER]

Особое внимание обратить на сообщения, содержащие операцию:

remove

Они могут указывать на исключение воркера из балансировки.

Причина 3: сервис воркеров не работает на нодах кластера#

Проверить:

• состояние Docker-сервиса воркеров;
• наличие задач сервиса на всех необходимых нодах;
• ошибки запуска контейнеров;
• сетевую доступность mgw;
• ответы воркеров на OPTIONS.

4. Ошибки mgw#

4.1. Balanced mode with wrong headers!#

Причина#

В INVITE, поступившем от balancer, отсутствуют обязательные заголовки либо в компонентах используются несовместимые версии.

Обязательные заголовки#

Диагностика#

1. Открыть SIP-трассировку.
2. Проверить входящий INVITE на стороне mgw.
3. Проверить наличие всех обязательных заголовков.
4. Проверить корректность значений заголовков.
5. Сверить версии balancer, mgw и amd.

4.2. DS not in list!#

Причина#

Некорректно переопределен режим работы сервиса.

Диагностика и устранение#

Проверить значение переменной:

MGW_MODE

Штатное значение:

MGW_MODE=balanced

Переменную не следует переопределять. После возврата корректного значения проверить перезапуск сервиса и обработку нового вызова.

4.3. trigger_call fail#

Причина#

Сервис amd недоступен по ARI.

Диагностика#

Проверить:

• состояние сервиса amd;
• доступность ARI;
• сетевое соединение между mgw и amd;
• логи amd;
• наличие ошибок авторизации или подключения к ARI.

Устранение#

Провести диагностику сервиса amd в соответствии с соответствующим разделом документации.

4.4. SmartCPD Engine health check failed#

Причина#

Движок детекции недоступен по REST.

Диагностика и устранение#

Проверить:

• доступность REST health endpoint;
• состояние сервиса движка;
• сетевое соединение между воркером и движком;
• ошибки в логах движка;
• корректность адреса и параметров подключения.

Дальнейшую диагностику выполнять по соответствующему разделу документации по движку SmartCPD.

5. Диагностика amd и CDR#

5.1. В CDR отсутствует запись о вызове#

Шаг 1. Проверка поступления вызова в amd#

Проверить лог amd на наличие сообщения:

<CALL_ID> [ACQUIRE] Action:...

Если сообщения нет:

• вызов не дошел до amd;
• необходимо проверять цепочку выше — mgw и balancer;
• проверить SIP-трассировку и логи соответствующих сервисов.

Шаг 2. Проверка ошибки записи в БД#

Если сообщение о поступлении вызова есть, проверить логи за период вызова на наличие:

Failed to insert call detail record into database!

При наличии сообщения проверить:

• доступность БД;
• сетевое соединение с БД;
• учетные данные;
• права пользователя;
• наличие свободного места;
• ошибки схемы или миграций;
• корректность параметров подключения.

Шаг 3. Проверка включения CDR#

При запуске amd должно присутствовать сообщение:

CDR simple logging enabled.

Если сообщение отсутствует, проверить:

• настройки записи CDR;
• параметры подключения к БД;
• наличие необходимых переменных окружения;
• доступность БД во время запуска сервиса.

Классы причин#

Причины отсутствия записи в CDR относятся к одному из двух классов:

1. вызов не пришел в amd или не прошел через balancer;
2. возникла проблема с настройками или доступностью БД.

5.2. В CDR указано stage_error=call_controller_unavailable#

Причина#

Недоступен или отказал движок детекции.

Диагностика#

Проверить соответствующий раздел документации по движку SmartCPD:

• состояние движка;
• доступность REST;
• ошибки обработки задач;
• сетевое соединение;
• лимиты ресурсов.

Все вызовы с такой ошибкой направляются на оператора.

6. SIP-трассировка в Homer#

6.1. Ограничения захвата#

В состав продукта может быть включен инструмент сбора SIP-трассировки Homer.

Захват выполняется:

• только для аутентифицированных запросов;
• только для INVITE;
• только для плеча A — между дайлером и SmartCPD;
• только для плеча B — между SmartCPD и SBC или провайдером.

Сигнализация между воркерами в трассировку не попадает. Это сделано для:

• уменьшения объема малоинформативного трафика;
• экономии дискового пространства БД;
• снижения расходов на передачу данных в Homer.

6.2. Определение идентификатора вызова#

Для связывания двух плеч одной детекции используется sip_trace_id. Он является UUID вызова.

UUID можно получить двумя способами.

Способ 1. Из CDR#

Найти соответствующую запись вызова в БД CDR и использовать значение поля:

sip_trace_id

Способ 2. Из начального INVITE#

1. Найти начальный INVITE от дайлера.
2. Открыть Details.
3. Найти поле:

correlation_id

Значение correlation_id соответствует sip_trace_id.

6.3. Поиск вызова#

Для поиска двух плеч одного вызова:

1. В виджете фильтра открыть настройки полей.
2. Добавить поле фильтрации по correlation_id.
3. Вставить в него значение sip_trace_id.
4. Очистить остальные поля фильтра.
5. Убедиться, что временной диапазон включает время вызова.
6. Выполнить поиск.

В результате должны отобразиться два плеча вызова, связанные одним UUID.

6.4. Что проверять в трассировке#

При анализе отказа проверить:

• направление вызова;
• источник и получателя каждого SIP-сообщения;
• SIP-коды ответов;
• наличие ответов на INVITE, OPTIONS и последующие запросы;
• место формирования ошибки;
• соответствие Call-ID, correlation_id и sip_trace_id;
• задержки между запросами и ответами;
• различия между плечом A и плечом B.

7. Быстрый справочник#