Архитектура

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

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

• 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. При отказе одного процессы будут перезапущены на втором.

Требования к ресурсам#

Серверные мощности нод по типам#

Количество нод по типам#

• service: 1 для обычной, 2 для отказоустойчивой установки
• balancer: 1 для обычной, 2 для отказоустойчивой установки
• analyzer: достаточно 1, можно использовать 2 для failover
• worker: горизонтально масштабируется в зависимости от нагрузки: одна нода (c вышеуказанными требованиями) на 25 CPS (calls per second)

База данных#

• 500 MB на 1.000.000 попыток дозвона.

Попытка дозвона - это каждая попытка дозвониться до абонента, не зависимо от того было соединение или нет.

Время хранения данных в БД настраивается при установке, по-умолчанию 6 месяцев.

Метрики#

• 25 MB на 1 000 000 попыток дозвона.

Попытка дозвона - это каждая попытка дозвониться до абонента, не зависимо от того было соединение или нет.

Время хранения метрик запрашивается при установке, по-умолчанию 6 месяцев.

Redis#

• 500 MB RAM на каждый 1 000 000 отвеченных вызовов в сутки.

Каждые сутки бОльшая часть счетчиков сбрасывается, поэтому пик потребления приходится на конец суток.

Прочие требования к ресурсам#

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

Типовые конфигурации для установки#

Минимальная конфигурация 25 CPS + масштабирование горизонтально#

Минимально отказоустойчивое решение 50 CPS + масштабирование горизонтально#

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

Высоконагруженное отказоустойчивое решение 100 CPS + масштабирование горизонтально#

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

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

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

PostgreSQL#

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

Хранит:

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

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

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

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

• 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

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 минут)

markup-api#

Сервис получение разметки операторов.

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

• предоставляет http API для загрузки данных разметки вызовов операторами

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

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

analyzer#

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

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

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

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

Важно: у сервиса высокие требования к потреблению RAM. Это происходит только во время ежесуточного анализа, т.е. в ночное время, и зависит от нагрузки (количества вызовов за сутки). Расчетные параметры представлены для максимальной загруженности каждого типового варианта установки. Допустимо в период опытной эксплуатации на расчетной нагрузке снять показания потребления с целью уменьшить требования к RAM на хосте. В этом случае необходимо ограничить RAM контейнера сервиса analyzer, чтобы остались ресурсы на прочие сервисы. При повышении нагрузки следить за потреблением и добавлять по мере необходимости.

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

balancer#

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

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

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

• Принимает SIP сообщения на порт udp:5060 серверов, где запущен экземпляр сервиса от PBX/SBC
• Отправляет SIP сообщения с порта udp:5060 серверов, где запущен экземпляр сервиса в сторону SBC/Outbound Proxy
• Читает конфигурацию из сервиса config-server.

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

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

mgw#

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

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

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

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

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

amd#

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

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

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

• SIP сигнализация между локальным экземпляром amd (upd:5001) и mgw (udp:5002)
• RTP трафик между amd (udp:21000-21999) и SBC/Outbound Proxy
• Получает информацию о параметрах вызова от локального экземпляра smartcpd с порта tcp/8003
• Отправляет информацию о вызове локальному экземпляру 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
• на этот же порт в 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 инфраструктуре с типом подключения по типу “разрыв” или “петля”. При расчетах сайзинга следует учитывать, что при включении продукта “петлей” общая нагрузка на маршрутизатор увеличится в два раза.

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

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

• Входящие транки - уникальная сущьность через которую дайлер может инициировать вызов.
• Исходящие транки - имеют возможность указывать на один шлюз, но должны иметь уникальные “имя” и “label”.

При подключении “в разрыв”, после окончания определения человека на линии, 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

Дозвон до абонента: SmartCPD начинает звонок в сторону абонента по первичному INVITE от дайлера с параметром “время дозвона” установленном для профиля на портале, при этом исходный вызов будет удерживатся в состоянии Ringing все время дозвона и анализа отвеченного вызова. SmartCPD закончит вызов дайлера в соответствии с настройками поведения при обнаружении робота, тишины и т.п., либо выполнит соединение с оператором. В случае отсутствия ответа со стороны абонента, дайлер должен сам закончить вызов по таймауту, в связи с чем параметры дозвона для кампании и SmartCPD должы иметь корректные настройки. Время дозвона на дайлере должно учитывать время анализа и быть больше на N секунд времени дозвона SmartCPD. В случае установки идентичных параметров времени дозвона для дайлера и SmartCPD, будут возникать сбросы звонков находящихся на анализе.

Описание порядка установления соединения с примерами 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

Начиная с данного момента звонки стороны PBX и SBC переходят в режим 2b2 proxy, все запросы и ответы для диалогов перенаправляются сторонам.

Метод REFER#

В версии SmartCPD 5.2 и выше реализован метод спрямления вызывающей стороны с вызываемой SIP методом REFER. Данный механизм имеет ряд преимуществ;

1. Выход SmartCPD из диалога вместо перехода в режим b2b proxy
2. Полный контроль состояния вызова оборудованием клиента

Процесс соединения полностью идентичен ранее описанному, до этапа Stage 6. На данном этапе вместо метода INVITE в SBC направляется метод REFER с заголовком Replaces, который содержит call-id, to-tag и from-tag диалога стороны PBX. Данный механим мозволяет при реализации спрямления, заменить исходный вызов PBX в сторону SmartCPD на вызов SmartCPD с SBC в котором сам SmartCPD выходит из звонка. Важным отличием от метода INVITE является необходимость “пересборки” диалогов PBX и SBC оборудованием клиента. При обработке сигнала REFER сторона SBC должна информировать SmartCPD о ходе соединения методом NOTIFY и при достижении результата финальным методом NOTIFY с телом сообщения “SIP/2.0 200 OK”, в результате SmartCPD завершит диалог SBC методом BYE и будет ожидать сигнала CANCEL со стороны PBX.

Пример REFER

REFER sip:scpd@client.sbc.node:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP scpd.balancer.node:5060;branch=z9hG4bK83d7.7e5f6f46.0
To: <sip:destination@scpd.balancer.node:5060>;tag=b2a5df3b-5ff3-485d-9b0c-724f763acd08
From: <sip:source@scpd.balancer.node:5060>;tag=98d91b6af8bec7378b7439653a878a36-8cad
CSeq: 4667 REFER
Call-ID: SCPD_HDNXXGJnYWd9XlBXY3ppan1eVFllfWZkd0ZVXn17ZmB3SVVZYH4-
Max-Forwards: 70
Content-Length: 0
User-Agent: Altuera.ru (SCPD v5.0.0)
Contact: <sip:Altuera@scpd.balancer.node;did=b3.31550be7>
Refer-To: <sip:source@scpd.balancer.node:5060?Require=replaces&Replaces=b90d40cd-9cee-4777-a156-aa72128cb9a5%3bto-tag%3d8MwzlNEONyzqdbG7%3bfrom-tag%3ddf31-a94be0acf3557840f7b865f14c7e24fb>
Allow-Events: refer
Accept: message/sipfrag;version=2.0
Event: refer
Expires: 600
Supported: 100rel, replaces
Referred-By: <sip:source@scpd.balancer.node:5060>;tag=98d91b6af8bec7378b7439653a878a36-8cad

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

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

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

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

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

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

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

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

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