SIP

Компоненты 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. Данный механизм имеет ряд преимуществ;

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

Процесс соединения полностью идентичен ранее описанному, до этапа 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.3.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 должны инициировать вызовы на второй балансировщик (если он установлен)
Рабочей ноды - все находящиеся на ней вызовы будут потеряны. Балансировщики автоматически определят выход ноды из строя и направят новые вызовы на рабочие компоненты системы.

Защита и управление трафиком внутренних компонентов SIP#

Введение#

В архитектуре системы роль «первого рубежа» защиты и распределения трафика выполняет SIP-балансировщик. Все первичные механизмы фильтрации, аутентификации и защиты внутренних узлов (воркеров) реализованы на уровне балансировщика. Это позволяет изолировать внутреннюю инфраструктуру от некорректного или вредоносного трафика, гарантируя стабильность работы системы.

1. Аутентификация и валидация#

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

Валидация вызовов#

Все входящие запросы проходят проверку на соответствие настройкам разрешенных транков.

Результат: Если вызов не проходит валидацию (неверные учетные данные, неавторизованный IP и т.д.), балансировщик отклоняет запрос методом 401 Unauthorized.
Мотивация: Это предотвращает несанкционированный доступ к ресурсам системы и защищает от попыток использования системы для нелегитимной телефонии.

Процедура регистрации (SIP Registration)#

Если для конкретного транка на портале включена возможность регистрации, балансировщик обрабатывает ее в строгом соответствии со стандартом RFC 3261:

Запрос: Клиент отправляет запрос REGISTER.
Вызов (Challenge): Балансировщик отвечает 401 Unauthorized, передавая в заголовке WWW-Authenticate nonce (случайную строку) и параметры аутентификации.
Повторный запрос: Клиент отправляет REGISTER повторно, добавляя заголовок Authorization с вычисленным хэшем пароля.
Подтверждение: После успешной проверки данных балансировщик возвращает ответ 200 OK, подтверждая успешную регистрацию устройства/шлюза.

2. Защита от фрода и DDoS-атак#

Для предотвращения перегрузки системы попытками подбора паролей (Brute-force) и распределенных атак на уровне протокола SIP, в балансировщике реализован механизм автоматической блокировки (Blacklisting).

Алгоритм работы#

Система отслеживает каждую неудачную попытку взаимодействия с SIP-сервисом:

Триггеры блокировки: Неаутентифицированная попытка вызова или отклоненная попытка регистрации.
Лимит: При достижении 10 неудачных попыток с одного IP-адреса, данный адрес заносится в черный список.
Действие: Все последующие запросы с заблокированного IP сбрасываются без обработки.

Мониторинг и логирование#

Инженеры и DevOps могут отслеживать активность системы защиты по следующим меткам в логах:

Нарастание счетчика: [DDoS] add to bl {IP} — фиксирует каждую неудачную попытку.
Факт блокировки: {Call-ID} [DDoS] Dropped {SIP METHOD} from {IP} cause bl_count=11 — сообщение о сбросе трафика из-за превышения лимита.

Управление состоянием#

Таймаут: Запись в счетчике фрода автоматически аннулируется через 3600 секунд (1 час) отсутствия активности с данного IP.
Сброс: Счетчик является внутренним ресурсом балансировщика. Для ручного принудительного сброса всех текущих блокировок требуется перезапуск сервиса балансировщика.

3. Контроль заголовков маршрутизации (Route)#

Система блокирует вызовы, содержащие предустановленные заголовки Route. При обнаружении таких заголовков возвращается ответ 403 Preload Route denied.

Мотивация: Предустановленные маршруты могут быть использованы злоумышленниками для обхода логики балансировщика или попыток «проброса» трафика напрямую на внутренние IP-адреса воркеров (Route Hijacking). Запрет Preload Route гарантирует, что управление потоком вызова полностью контролируется архитектурой SmartCPD.

4. Валидация структуры URI (From/To)#

Балансировщик проверяет наличие заполненной пользовательской части (user part) в URI заголовков From и To. Если пользовательская часть отсутствует (например, запрос в формате sip:domain.com вместо sip:user@domain.com), вызов отклоняется методом 400 Bad Request.

Мотивация: Отсутствие идентификатора пользователя в SIP-запросе может свидетельствовать о некорректной конфигурации оборудования клиента или использовании инструментов для сканирования сетей. Блокировка таких запросов на входе предотвращает возможные сбои в логике биллинга, маршрутизации и обработки CDR на уровне воркеров.

Управление ресурсами и нагрузкой#

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

Стратегия распределения#

Распределение нагрузки осуществляется по принципу равномерного заполнения на основе количества активных сессий. Запрос направляется на воркер с наименьшим числом текущих соединений.

Лимиты и отказоустойчивость#

Для каждого воркера установлен жесткий лимит ресурсов: 600 конкурентных линий.

Сценарии обработки перегрузки:

Превышение лимита: Если все доступные воркеры достигли порога в 600 линий, новые вызовы отклоняются методом 500 Service full.
Отказ воркеров: Если все воркеры вышли из строя или недоступны, система возвращает ответ 500 Service full.

Логирование инцидентов#

В случае невозможности обработки вызова из-за отсутствия свободных ресурсов в лог записывается критический репорт: {CallID} [PBX] NO WORKERS AVAILABLE!

Это служит сигналом для DevOps-инженеров о необходимости масштабирования ресурсов (добавления новых воркеров) или проверки состояния текущего пула.

Сбор данных и метрик (Важные особенности)#

В системе разделены зоны ответственности за маршрутизацию и учет трафика. Запись детальной информации о вызовах (CDR) и сбор основных эксплуатационных метрик продукта выполняются исключительно на стороне воркеров.

🚨Внимание: Поскольку учет осуществляется воркерами, любые вызовы, которые были отклонены на уровне Балансировщика (в результате работы фильтров безопасности, блокировки по DDoS или из-за отсутствия свободных ресурсов 500 Service full), не попадают в CDR и не учитываются в общих метриках продукта.
При диагностике «пропадания» вызовов, которые отсутствуют в отчетах, необходимо в первую очередь анализировать логи балансировщика на предмет меток [DDoS] или [PBX] NO WORKERS AVAILABLE!.

Диагностика и анализ трафика с помощью HOMER (SIPCapture)#

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

Обзор системы#

HOMER — это специализированная платформа для захвата и анализа VoIP-трафика в реальном времени. Она позволяет инженерам видеть структуру звонков и ошибки протоколов без необходимости ручного сбора PCAP-дампов с каждого сервера.

Архитектура состоит из трех компонентов (протокол HEP):

Capture Agent: В контуре SmartCPD эту роль выполняют балансировщики (точки входа/выхода трафика).
Capture Server: Принимает данные от агентов и сохраняет их в БД.
Web Interface (GUI): Интерфейс для построения графиков, анализа звонков и экспорта трафика.

Особенности реализации в SmartCPD#

SmartCPD работает как B2BUA (Back-to-Back User Agent). Это означает, что один вызов фактически состоит из двух независимых диалогов:

Диалог А: Вызывающая сторона -> Балансировщик.
Диалог Б: Балансировщик -> Вызываемая сторона.

Оптимизация захвата: Для экономии ресурсов из захвата исключен трафик между балансировщиком и воркером. Таким образом, в HOMER фиксируются только внешние сегменты (Сторона А и Сторона Б). Для связки этих двух диалогов используется уникальный идентификатор sip_trace_id (в терминах HOMER — correlation id).

Важное ограничение (Known Issue)#

В связи с особенностями работы модулей сокрытия топологии (topology_hiding) и b2b_logic в OpenSIPS, существует проблема с отображением измененного Call-Id вызываемой стороны.

Симптом: Во всех захваченных сообщениях сохраняется Call-Id вызывающей стороны, а оригинальный Call-Id вызываемой стороны будет утерян.
Рекомендация: Данный факт необходимо учитывать при проведении совместной диагностики с клиентами.

Руководство по поиску детекций#

Основная работа ведется в виджетах SIP CALL SEARCH и Widget result.

Поиск связанных диалогов по Call-ID:

Введите Call-id в поиске -> выберите временной диапазон -> нажмите «Поиск».
В результатах вы найдете Сторону А. Нажмите на любой SIP Method в колонке результатов -> перейдите на вкладку Details -> скопируйте значение correlation_id.
Очистите параметры поиска -> вставьте скопированный ID в поле Correlation ID -> нажмите «Поиск».
В результатах отобразятся оба диалога (А и Б), выделенные разными цветами.

Интеграция в публичные сети (Сервисное внедрение)#

Данный раздел описывает опциональную конфигурацию системы, доступную только при сервисном внедрении квалифицированными специалистами.

Продукт поддерживает возможность работы не только в локальном контуре (on-premise), но и в публичных сетях (Интернет). Для обеспечения безопасности и корректности прохождения трафика в таком режиме применяется следующая модель:

Сетевая топология и безопасность#

Для минимизации рисков безопасности используется строгая сегментация сети:

Изоляция воркеров: Воркеры полностью изолированы от публичной сети. Прямой доступ воркеров в интернет или из интернета запрещен.
Шлюзование балансировщика: Балансировщик, являясь единственной точкой контакта с внешним миром, настраивается через NAT (внешний шлюз или NAT на уровне хоста). Это позволяет скрыть внутреннюю топологию сети и защитить внутренние IP-адреса системы.

Работа с медиа-трафиком (RTP)#

Для обеспечения корректного прохождения RTP-трафика через NAT-шлюзы используется инструмент rtpengine. Он может быть развернут двумя способами в зависимости от требований к нагрузке:

Как отдельный выделенный сервис.
В составе функционального стека балансировщика.

rtpengine берет на себя функции проксирования и ретрансляции медиа-потоков, гарантируя, что голос будет доставлен между публичной сетью и изолированными воркерами.

Сайзинг#

В связи с дополнительной нагрузкой на обработку медиа-трафика и спецификой сетевых задержек в публичных сетях, стандартные расчеты ресурсов не применяются. Требуется индивидуальный расчет сайзинга оборудования для каждого проекта с учетом прогнозируемого количества одновременных сессий и объема трафика.