Архитектура

Технологический стек#

Языки разработки ПО:

• Python, Java/Scala, Go, JavaScript (Vue.js), Lua, HTML

Open Source компоненты:

• SIP стек: Opensips, Asterisk
• БД: PostgreSQL, Redis
• Базовые образы Docker: Alpine, Debian
• Веб-сервер: Nginx
• Сбор метрик: VictoriaMetrics
• Визуализация метрик: Grafana

Инфраструктура:

• Контейнеризация: Docker
• Оркестрация: Docker Swarm

Docker Swarm#

Платформа Altuera SmartCPD предназначена для разворачивания в инфраструктуре Docker Swarm. Это решение обеспечивает следующие преимущества:

• Упрощённое масштабирование — легко добавлять или удалять узлы, автоматически распределяя нагрузку.
• Высокая доступность — сервисы перезапускаются при сбоях, поддерживая бесперебойную работу.
• Простое управление — централизованное управление всеми контейнерами через единый интерфейс.
• Автообнаружение экземпляров сервисов.
• Сквозная межсерверная сеть overlay network

Все серверы, входящие в состав кластера Docker Swarm (ноды далее по тексту) делятся на роли:

• manager - “управляющие” кластером ноды
• worker - “рабочие” ноды, на которых выполняются процессы. manager также являются рабочими нодами.

Кластер может работать, когда количество активных управляющих нод равно N/2+1 от настроенного количества. Поэтому для обеспечения отказоустойчивости платформы SmartCPD требуется минимум 3 сервера. При меньшем количестве выход из строя manager ноды приведет к отказу.

Роли нод SmartCPD в Docker Swarm#

Нода SmartCPD - это один сервер кластера swarm. Роль ноды определяет состав запущенных на них контейнеров. Назначение роли ноде swarm осуществляется установкой docker label: scpd.node.role.<role_name> = true, где role_name - целевая роль.

Группировка компонентов платформа SmartCPD логически разбита на ноды по следующим ролям:

• service - сервисные компоненты (веб интерфейс, статистика, вспомогательные сервисы)
• balancer - балансировщики SIP трафика на рабочие ноды
• worker - рабочие ноды SmartCPD, выполняющие выявление роботов, автоответчиков и тишины в телефонных вызовах
• analyzer - анализатор SmartCPD, выполняющий поиск роботов в недавних вызовах и адаптирующий систему к их поиску в реальном времени

Для высоконагруженных инсталляций рекомендуется иметь как минимум по одной ноде (серверу) на каждую роль, но любые роли можно совмещать на одном сервере, включая установку всех компонент на один сервер (только для тестирования или малой нагрузки).

Масштабирование и отказоустойчивость#

balancer ноды масштабируются в режиме active-active, для отказоустойчивой установки достаточно 2-х серверов с этой ролью, нет необходимости установки более 2-х нод с этой ролью. Выход из строя всех нод приводит к полной деградации сервиса.

worker ноды масштабируются в режиме active-active, для отказоустойчивой установки достаточно 2-х нод, для обработки возрастающей нагрузки количество серверов этой роли можно увеличивать. Выход из строя части нод может привести к деградации сервиса (оставшиеся ноды могут не справляться с нагрузкой), всех - к полной деградации сервиса.

analyzer выполняет единственный процесс и ДОЛЖЕН быть запущен в одном экземпляре. Для обеспечения отказоусточивости можно назначить эту роль нескольким серверам, в случае отказа одного из них, процесс будет перезапущен на другом. Краткосрочный выход из строя не приводит к деградации сервиса, однако теряется возможность самообучения, что может привести к деградации качества распознавания при долгосрочном отказе.

service Выполняет вспомогательные, но необходимые для работоспособности комплекса процессы (включая БД Redis). В случае отказа происходит деградация сервиса. Для обеспечения отказоустойчивости достаточно иметь 2 сервера с ролью service. При отказе одного процессы будут перезапущены на втором.

Общая схема взаимодействия компонентов#

Базы данных решения#

PostgreSQL#

Поддерживается СУБД PostgreSQL версий 12+. Не входит в состав продукта, устанавливается, настраивается и сопровождается Заказчиком. Рекомендуется отказоустойчивое

Хранит:

• настройки платформы
• пользователей
• историческую отчетность
• данные биллинга

В случае недоступности БД:

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

Компоненты, подключающиеся к БД:

• portal-api
• billing-server
• amd
• grafana

Redis#

Поддерживаются версии 7.3+. Может использоваться внешний отказоустойчивый сервис Заказчика (sentinel, redis standalone или за прокси, поддержка redis cluster будет добавлена позже)

При установке внутри контура разворачивается на service нодах (в частично отказоустойчивой sentinel реализации при использовании более 1 сервисных нод). При падении ноды и наличии резервных, возможна деградация сервиса на время переключения реплики в режим мастера.

Состоит из 2х компонент.

redis-sentinel#

Обеспечивает обнаружение запущенных экземпляров redis, выбор мастера и реплик, контроль доступности и отказоустойчивости. Подключается к экземплярам redis по порту tcp:6379, и к своим экзеплярам по порту tcp:26379

Запускается на service нодах минимум в 2х экземплярах на порту tcp:26379 для обеспечения кворума.

Подключения к компонентам SmartCPD

redis#

БД хранения пар ключ-значение в оперативной памяти.

Запускается на service нодах по одному экземпляру на каждой на порту tcp:6379

Подключения к компонентам SmartCPD

Компоненты service node#

portal-frontend#

Веб интерфейс для управления платформой (далее “портал”) и просмотра отчетности.

Также выполняет роль reverse-proxy для grafana и metrics.

Публикует один из следующих портов (порт доступен с любой ноды):

• tcp:80 без TLS шифрования, рекомендуется использовать при наличии внешних reverse-proxy
• tcp:443 с TLS шифрованием соединения

Подключения к компонентам SmartCPD

portal-api#

Backend API веб интерфейса платформы

Отвечает за:

• авторизацию в портале и grafana
• чтение/сохранение некоторых настроек продукта
• передачу динамического контента в portal-frontend
• предоставляет внешний API для интеграции с IDM

Запускается на порту tcp:5000 в overlay сети docker.

Подключения к компонентам SmartCPD

metrics#

Собирает, хранит и отдает статистические метрики (prometheus).

Требует запуска на manager ноде и доступа (read, write) к docker socket (unix, plain tcp, mTLS tcp).

Запускается на порту tcp:8428 в overlay сети docker.

Доступ к метрикам за пределами контура SmartCPD по URL портала и пути /prometheus/ с авторизацией заданным при установке токеном API: Authorization: Bearer API_TOKEN.

При отказоустойчивом размещении, требует размещения директории хранения данных metrcis_data в сетевом хранилище для их доступности после запуска на другом сервере.

Подключения к компонентам SmartCPD

grafana#

Веб интерфейс графической визуализации статистических метрик.

Запускается на порту tcp:3000 в overlay сети docker.

Подключения к компонентам SmartCPD

resolver#

Вспомогательный сервис, обеспечивающий автоматическое обнаружение (autodicovery) сервисов, запущенных в сетевом режиме host. Позволяет динамически отслеживать новые запущенные worker ноды и распределять на них трафик.

Публикуется на порту udp:53 (доступен со всех нод кластера). Не требует доступность вне кластера.

Требует запуска на manager ноде и доступа (read, write) к docker socket (unix, plain tcp, mTLS tcp).

config-server#

Предоставляет API для хранения и получения и подписки на обновления конфигурационных данных и файлов.

Запускается в единственном экземпляре. При отказе перезапускается на этой же/резервной ноде. При недоступности сервиса не позволяет изменение/обновление конфигураций, но зависимые уже запущенные сервисы продолжат работать без деградаций.

При отказоустойчивом размещении, требует размещения директории хранения данных config-server_data в сетевом хранилище для их доступности после запуска на другом сервере.

Запускается на порту tcp:8002 в overlay сети docker, публикует этот же порт на все хосты swarm кластера для доступности сервисам, работающим в режиме сети host.

billing-server#

Обеспечивает:

• контроль лицензионных ограничений
• агрегацию исторической отчетности
• расчет потребления услуг
• построение отчетов о потребления услуг

Режим работы:

• Каждые 15 минут агрегирует информацию о совершенных вызовах и формирует историческую отчетность
• раз в сутки в 00:15 формирует отчет о потреблении услуг за предыдущие полные сутки
• контролирует смену лицензий и изменение тарифа

Запускается на порту tcp:8001 в overlay сети docker.

Подключения к компонентам SmartCPD

license-server#

Обеспечивает:

• Валидацию лицензионных файлов
• Предоставление информации о текущей лицензии прочим компонентам

Запускается на порту tcp:8002 в overlay сети docker.

Подключения к компонентам SmartCPD

models-store#

Функциональность:

• хранение системно значимых файлов платформы
• предоставление API для управления хранилищами файлов
• оповещает компоненты об изменении состава хранимых файлов

Запускается на порту tcp:8002 в overlay сети docker.

При отказоустойчивом размещении, требует размещения директории хранения данных models_data в сетевом хранилище для их доступности после запуска на другом сервере.

Подключения к компонентам SmartCPD

cloud-connector#

Опциональный компонент.

Функциональность:

• автоматическое регулярное обновление облачных моделей

Подключения к компонентам SmartCPD

Подключение к облаку Altuera

• адрес облака https://scpd.altuera.ru:5000
• HTTP запросы: PROPFIND, GET
• Получаемые данные: xml, <file>.db (формат sqlite), <file>.pth (файл данных, сохраняющий веса нейронной сети PyTorch)
• Поддержка HTTPS_PROXY: управляемый timeout, использование CA сертификата proxy сервера
• Настройка регулярных обновлений (рекомендуется каждые 15 минут)

Компоненты analyzer node#

analyzer#

Выполняемые задачи:

• сбор классифицированных результатов определения автоответчиков с активных экземпляров samrtcpd
• ежечасный анализ последних 2000 результатов на появление новых шаблонов роботов
• ежесуточный анализ последних 40000 результатов на появление новых шаблонов роботов
• обновление локальной модели dejavu для определения автоответчиков

Процесс обновления локальной модели dejavu:

Подключения к компонентам SmartCPD

Компоненты balancer node#

balancer#

Функциональность:

• обеспечивает подключение платформы SmartCPD к существующей VoIP инфраструктуре
• идентифицирует входящие вызовы и обогащает их данными настроек определения автоответчиков
• распределяет входящие вызовы на worker ноды
• контролирует доступность worker нод решения

Запускается в режиме сети host для обеспечения корректного SIP flow.

• Принимает SIP сообщения на порт udp:5060 серверов, где запущен экземпляр сервиса от PBX/SBC
• Отправляет SIP сообщения с порта udp:5060 серверов, где запущен экземпляр сервиса в сторону SBC/Outbound Proxy
• Принимает запросы на перечитывание конфигурации от локального экземпляра trunksync на порт udp:9091

Читает конфигурацию из локального тома trunksyncdb_data.

Подключения к компонентам SmartCPD

Компоненты worker node#

mgw#

SIP b2bua, выполняет следующие функции:

• отправляет запрос на совершение исходящего вызова в локальный amd
• удерживает инициировавшее вызов плечо в состоянии дозвона пока проиходит дозвон и определение автоответчиков/роботов/тишины
• “замыкает” оба плеча вызова по факту успешного определения человека на линии, исключая платформу из пути RTP трафика
• в случае неуспешного дозвона или определения на линии “не человека”, возвращает в первое плечо результат дозвона, обогащенный данными

Запускается в режиме сети host для обеспечения корректного SIP flow.

• Принимает SIP сообщения на порт udp:5002 от экземпляров balancer
• Отправляет запрос инициализации нового вызова локальному экземпляру amd
• Проксирует SIP сигнализацию локального экземпляра amdв сторону balancer
• Отдает статистические метрики mertics на порту tcp:8888
• Принимает управляющие сообщения от локального экземпляра amd на порт udp:127.0.0.1:9091

Подключения к компонентам SmartCPD

amd#

Реализует голосовую составляющую SIP взаимодействия, а именно:

• Осуществляет исходящий вызов “второму” плечу (абоненту)
• Записывает и отправляет smartcpd на анализ данные ДО установления соединения
• По факту установки соединения пытается “разговорить” абонента (“пробить тишину”)
• Выполняет базовые проверки на автоответчик, тишину и речь (в случае ответа абонента)
• Отправляет запись начала разговора на анализ smartcpd
• Получает результат анализа от smartcpd и обрабатывает вызов

Запускается в режиме сети host для обеспечения корректного SIP flow.

• SIP сигнализация между локальным экземпляром amd (upd:5001) и mgw (udp:5002)
• RTP трафик между amd (udp:21000-21999) и SBC/Outbound Proxy
• Получает запрос на начало нового вызова от локального экземпляра mgw на порт tcp:127.0.0.1:5000
• Отправляет информацию о вызове локальному экземпляру mgw

Сохраняет записи (до соединения и до первых 8 секунд вызова) в локальном томе node_records

Подключения к компонентам SmartCPD

smartcpd#

Выполняет проверку вызова на наличие “человека” на линии, отсекая тишину, автоответчики и роботов. Получает записи вызова:

• до соединения
• до 8 секунд после соединения

Выполняется ряд проверок:

• проверка времени, затраченного на снятие трубки
• определение наличия специальных тонов
• проверка соответствия локальной и “облачной” базами шаблонов dejavu
• проверка LSTM-классификации ИИ моделью (lstm)
• проверка на содержание ключевых слов (VOSK)

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

Читает записи из локального тома node_records.

Сохраняет классифицированные записи в локальном томе node_results.

• Публикует порт tcp:127.0.0.1:8003 для доступа локального экземпляра amd
• На порт tcp:5544 в overlay сети docker отдает статистические метрики matrics и получает события обновления моделей от models-store
• на этот же порт в overlay сети docker отдает классифицированные файлов результатов сервису analyzer.
• подключается к Redis в overlay сети docker

Подключения к компонентам SmartCPD

dircleaner#

Служебный сервис, запускается локально на каждом экземпляре worker нод и осуществляет регулярное удаление старых записей локальных томов node_records (время жизни записи 2 минуты) и node_results (время жизни - 7 дней, для возможности осуществления анализа проблем)

Матрица сетевых взаимодействий#

Основные сетевые взаимодействия между сервисами осуществляются:

• локально в рамках одного сервера
• внутри docker overlay сетей swarm кластера
• Прочие соединения описаны в таблице:

Описание SIP взаимодействий платформы Altuera SmartCPD#

Компоненты SIP#

• balancer (balancer node) - балансировщик SIP трафика между worker нодами
• mgw (worker node) - сервис SIP B2BUA для приёма/передачи сигнализации SIP
• amd (worker node) - сервис обеспечения RTP обмена PBX(SBC) — SmartCPD — PBX(SBC)

Поддерживаемые голосовые кодеки: 711A, 711U.

Варианты подключения к SIP инфраструктуре#

SmartCPD представляет собой B2BUA SIP интерфейс и не предназначен для сложной маршрутизации. Продукт должен устанавливаться “в разрыв” или “петлей” в действующей VoIP инфраструктуре. Во всех сценариях включения предполагается маршрутизация вызовов после SmartCPD.

На PBX(УПАТС)/SBC настраиваются транки к балансировщикам SmartCPD (1 или 2 в зависимости от установки). Адреса PBX/SBC должны настраиваться в портале SmartCPD (раздел Настройки SIP-транка входящих звонков). Поддерживается до 2-х транков (резервирование PBX).

Обратные звонки для дальнейшей маршрутизации на сети провайдера можно направить:

• на Outbound Proxy (вариант подключения “в разрыв”), параметры подключения задаются в портале в разделе Outbound Proxy. Вызовы со всех заданных транков PBX будут направлены на Outbound Proxy.
• в тот же транк (вариант подключения “петлей”), для этого в портале в разделе Outbound Proxy необходимо установить чекбокс Совпадает с входящим. При таком подключении все вызовы отправляются в тот же транк, откуда были инициированы.

При подключении “в разрыв”, после окончания определения человека на линии, SmartCPD исключается из пути RTP трафика, однако остается передавать SIP сигнализацию вызова.

При подключении “петлей”, все аналогично, если SBC может инициировать SIP Refer для исключения SmartCPD из цепочки SIP сигнализации. Такая настройка выходит за рамки продукта SmartCPD, но может быть включена в проект внедрения продукта.

SmartCPD не предназначен для работы напрямую с IP телефонией провайдеров и ДОЛЖЕН находиться в одном сетевом сегменте с существующей VoIP инфраструктурой, исключая NAT. SBC и/или Outbound Proxy ДОЛЖНЫ проксировать RTP трафик, идущий с приватных IP адресов в сторону провайдеров телефонии.

Входящие вызовы в сторону SmartCPD проходят валидацию по параметрам sip подключений заданными на портале. IP адрес источника и доменная часть заголовка via должны быть одинаковыми. Допускается использование динамического выбора порта на стороне источника, однако, порт в заголовке via должен быть статичным и соответствовать настройкам портала.

Детализация работы SIP стека SmartCPD#

Полный стек SIP от начального INVITE до завершения вызова отбоем со стороны SmartCPD разбит на условные 5 сценариев в которые не входит этап установления нового соединения.

• Первым этапом считается сценарий ошибок и отбоев со стороны операторов ТФоП которые полностью дублируются в АТС инициировавшей вызов.

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

• Третий сценарий записывает отвеченный вызов и в случае тишины “пытается” её пробить с помощью предварительно записанных “алло”. В результате работы данного сценария возможны следующие два.

• Четвертый сценарий устанавливает прямое RTP соединение АТС - ТФоП в случае принятия решения анализатором о присутствии человека на линии.

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

Во всех сценариях возможно прерывание анализа со стороны АТС по “нет ответа” или со стороны ТФоП по сбросу вызова абонентом во время анализа. Подобные ситуации не отражены на схеме. Данная диаграмма отражает сжатую структуру диалогов в схеме “петля” и для краткости не включает служебные ответы. В скобках указаны плечи в рамках которых осуществляется диалог и при включении продукта по схеме “разрыв” диалоги (PSTN) будут направляться в Outbound-proxy

Описание порядка установления соединения с примерами SIP диалогов в пределах одной сессии. В примере опущены сигналы подтверждений и не имеющие значения, в примере показан пример успешного прохождения проверок и порядок установления соединения между инициатором вызова и абонентом.

Легенда:

• DESTINATION - номер или имя адреса назначения вызова
• scpd.balancer.node - нода балансера SCPD обслуживающая данный диалог
• scpd.worker.node - воркер нода SCPD обслуживающая данный диалог
• client.sbc.node - в примере показана схема петля, нода которая инициирует вызовы на SCPD и принимает обратные звонки в сторону PSTN
• client.pbx_rtp.farm - адрес RTP для стороны PBX
• client.pstn_proxy.farm - адрес RTP для стороны PSTN

Stage 1: LEG A, PBX 2 SCPD На первом шаге платформа клиента инициирует новый вызов на SmartCPD, это плече А в рамках диалога

INVITE sip:DESTINATION@scpd.balancer.node:5060 SIP/2.0
Via: SIP/2.0/UDP client.sbc.node:5060;branch=z9hG4bKd4e4.23a76d37.0
To: <sip:DESTINATION@scpd.balancer.node:5060>
From: <sip:Altuera@client.sbc.node:5060>;tag=28a1d5a1ac228886e6b95a9163d992d9-b712
CSeq: 2 INVITE
Call-ID: SC38.263.5247499.1744776479.675254830
Max-Forwards: 68
Content-Length: 204
Content-Type: application/sdp
Supported: timer
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
Session-Expires: 1800;refresher=uac
Min-SE: 90
Contact: <sip:scpd@client.sbc.node:5060>

v=0
o=- 2668374840 1 IN IP4 client.pbx_rtp.farm
s=phone-call
c=IN IP4 client.pbx_rtp.farm
t=0 0
m=audio 41746 RTP/AVP 8 101
a=sendrecv
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Stage 2: LEG B, SCPD 2 PSTN На втором шаге SCPD создает плече Б в рамках диалога с новым вызовом в сторону клиентского SBC для соединения с абонентом. Диалог содержит SDP RTP адрес воркера для обработки голосового трафика

INVITE sip:DESTINATION@scpd.balancer.node:5060 SIP/2.0
Via: SIP/2.0/UDP scpd.balancer.node:5060;branch=z9hG4bKe8c8.0df53eb3.0
To: <sip:DESTINATION@scpd.balancer.node:5060>
From: <sip:Altuera@scpd.balancer.node:5060>;tag=2484f84c909ed16bf1a28223438de302
CSeq: 29077 INVITE
Call-ID: BAL41.64866.2834921.1744776480.842442410
Max-Forwards: 67
Content-Length: 262
User-Agent: SCPD
Content-Type: application/sdp
Supported: timer, histinfo
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, MESSAGE
Session-Expires: 1800
Min-SE: 90
Contact: <sip:Altuera@scpd.balancer.node>

v=0
o=SCPD 1162692349 1162692349 IN IP4 scpd.worker.node
s=SCPD
c=IN IP4 scpd.worker.node
t=0 0
m=audio 21464 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

Stage 3: LEG B, PSTN 2 SCPD На третьем шаге клиентский SBC сообщает, что идет вызов абонента с ранним меда, c этого момента начинается отсчет времени соединения и SCPD передает сигнал 180 Ringing в сторону плеча А на четвертом шаге

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP scpd.balancer.node:5060;branch=z9hG4bKe8c8.0df53eb3.0
To: <sip:DESTINATION@scpd.balancer.node:5060>;tag=SC38.458.208.1744776480.546945404
From: <sip:Altuera@scpd.balancer.node:5060>;tag=2484f84c909ed16bf1a28223438de302
Call-ID: BAL41.64866.2834921.1744776480.842442410
CSeq: 29077 INVITE
Content-Type: application/sdp
Supported: timer, path, replaces
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Contact: <sip:scpd@client.sbc.node:5060>
Content-Length: 274

v=0
o=FreeSWITCH 1744744324 1744744325 IN IP4 client.pstn_proxy.farm
s=FreeSWITCH
c=IN IP4 client.pstn_proxy.farm
t=0 0
a=rtpengine:6112fe272b86
m=audio 23510 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:23511
a=ptime:20

Stage 4, LEG A, SCPD 2 PBX На четвертом шаге SCPD сообщает стороне А, что идет вызов абонента. С этого момента платформа клиента считает время вызова абонента и при достижении установленного порога завершает вызов методом CANCEL если абонент так и не ответил на вызов

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.sbc.node:5060;branch=z9hG4bKd4e4.23a76d37.0
To: <sip:DESTINATION@scpd.balancer.node:5060>;tag=BAL41.24999.8182.1744776479.190836345
From: <sip:Altuera@client.sbc.node:5060>;tag=28a1d5a1ac228886e6b95a9163d992d9-b712
Call-ID: SC38.263.5247499.1744776479.675254830
CSeq: 2 INVITE
Init-CallID: BAL41.8292.6398608.1744776479.2041536203
Contact: <sip:DESTINATION@scpd.balancer.node>
Server: SCPD
Content-Length: 0

Stage 5, LEG B, PSTN 2 SCPD На пятом шаге SCPD получает сигнал 200 OK со стороны PSTN, абонент ответил на вызов. С этого момента начинается анализ содержимого аудио потока. Так-же с этого момента начинается тарификация соединения провайдером ТФоП. Сигнал содержит SDP с адресом RTP стороны абонента

SIP/2.0 200 OK
Via: SIP/2.0/UDP scpd.balancer.node:5060;branch=z9hG4bKe8c8.0df53eb3.0
To: <sip:DESTINATION@scpd.balancer.node:5060>;tag=SC38.458.208.1744776480.546945404
From: <sip:Altuera@scpd.balancer.node:5060>;tag=2484f84c909ed16bf1a28223438de302
Call-ID: BAL41.64866.2834921.1744776480.842442410
CSeq: 29077 INVITE
Content-Type: application/sdp
Supported: timer, path, replaces
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip:scpd@client.sbc.node:5060>
Content-Length: 274

v=0
o=FreeSWITCH 1744744324 1744744325 IN IP4 client.pstn_proxy.farm
s=FreeSWITCH
c=IN IP4 client.pstn_proxy.farm
t=0 0
a=rtpengine:6112fe272b86
m=audio 23510 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:23511
a=ptime:20

Stage 6: LEG B, SCPD 2 PSTN В случае обнаружения человека на линии SCPD отправляет INVITE in dialog в сторону PSTN с обновленной информацией SDP для соединения PBX и PSTN Данное действие проходит в два этапа, на шестом шаге SCPD отправляет re-Invite в сторону PSTN

INVITE sip:scpd@client.sbc.node:5060 SIP/2.0
Via: SIP/2.0/UDP scpd.balancer.node:5060;branch=z9hG4bKc9c8.7652c296.0
To: <sip:DESTINATION@scpd.balancer.node:5060>;tag=SC38.458.208.1744776480.546945404
From: <sip:Altuera@scpd.balancer.node:5060>;tag=2484f84c909ed16bf1a28223438de302
CSeq: 29078 INVITE
Call-ID: BAL41.64866.2834921.1744776480.842442410
Max-Forwards: 64
Content-Length: 204
User-Agent: SCPD
Content-Type: application/sdp
X-DuID: SC38.263.5247499.1744776479.675254830
Init-CallID: SC73.257.59108.1744776480.830536345
Contact: <sip:Altuera@scpd.balancer.node>

v=0
o=- 2668374840 1 IN IP4 client.pbx_rtp.farm
s=phone-call
c=IN IP4 client.pbx_rtp.farm
t=0 0
m=audio 41746 RTP/AVP 8 101
a=sendrecv
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Stage 7: LEG A, SCPD 2 PBX Вторым этапом соединения является шаг семь на котором SCPD отвечает 200 OK с SDP на начальный INVITE плечу A в диалоге, с этого момента установлен прямой трафик RTP между PBX и PSTN

SIP/2.0 200 OK
Via: SIP/2.0/UDP client.sbc.node:5060;branch=z9hG4bKd4e4.23a76d37.0
To: <sip:DESTINATION@scpd.balancer.node:5060>;tag=BAL41.24999.8182.1744776479.190836345
From: <sip:Altuera@client.sbc.node:5060>;tag=28a1d5a1ac228886e6b95a9163d992d9-b712
Call-ID: SC38.263.5247499.1744776479.675254830
CSeq: 2 INVITE
Content-Type: application/sdp
Supported: timer, path, replaces
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Session-Expires: 10800;refresher=uac
Require: timer
Init-CallID: BAL41.8292.6398608.1744776479.2041536203
Contact: <sip:DESTINATION@scpd.balancer.node>
Server: SCPD
Content-Length: 274

v=0
o=FreeSWITCH 1744744324 1744744326 IN IP4 client.pstn_proxy.farm
s=FreeSWITCH
c=IN IP4 client.pstn_proxy.farm
t=0 0
a=rtpengine:6112fe272b86
m=audio 23510 RTP/AVP 8 101
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:23511
a=ptime:20

Возвращаемые SIP статусы#

Вызовы, отправленные в SmartCDP, возвращают кроме статуса SIP заголовок X-AMD-STATUS, детализирующий причину того или иного статуса.

*Удаленный сброс: абонент положил трубку во время детекции

Если дозвон до абонента был неудачным, то SmartCPD вернет полученный со стороны абонента статус.

Замена SIP статусов#

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

Параметры задаются для сервиса mgw, формат для каждой записи должен содержать номер кода, затем через запятую текст кода, например:

    environment:
      SIP_ROBOT: 409,Conflict

Доступны следующие переменные для определения кодов статуса.

*SIP_FUNCTIONAL любые функциональные проблемы SmartCPD

Контроль доступности нод SmartCPD#

Балансировщики регулярно проверяют доступность и продуктивное состояние рабочих нод SmartCPD. Если ни одна нода не доступна, то будет возвращаться код 503 Service Unavailable.

Отказоустойчивость и масштабирование#

Сип компоненты платформы SmartCPD работают в режиме active-active c горизонтальным масштабированием.

Балансировщики являются высокопроизводительными компонентами. Одно балансировщика достаточно для обеспечения нормальной функциональности комплекса ПО SmartCPD. Второй ставится для отказоустойчивости.

За балансировку трафика НА балансировщики отвечает УПАТС/SBC, их настройка выходит за рамки настройки платформы, но может быть включена в проект внедрения продукта. УПАТС/SBC/Sip Proxy должны быть настроены на получение SIP и RTP трафика от SmartCPD.

Рабочие (worker) ноды обладают меньшей производительностью, поэтому масштабируются горизонтально. Ограничений в их количестве нет.

В случае отказа/выхода из строя:

• Балансировщика - все находящиеся на нем вызовы будет потеряны, SBC/PBX должны инициировать вызовы на второй балансировщик (если он установлен)
• Рабочей ноды - все находящиеся на ней вызовы будут потеряны. Балансировщики автоматически определят выход ноды из строя и направят новые вызовы на рабочие компоненты системы.