Телекомунікаційні оператори стикаються з критичною необхідністю модернізації архітектури для захисту голосового трафіку. За даними звіту CFCA Global Fraud Loss Survey 2025, очікувані глобальні втрати від телеком-шахрайства у 2025 році досягнуть приблизно $41.82 млрд, що є значним зростанням порівняно з $38.95 млрд у 2023 році. Значна частина цих збитків припадає на міжнародне шахрайство з розподілом доходів (IRSF), яке лише протягом 2023 року коштувало індустрії близько $6.23 млрд. Ці фінансові ризики змушують технічних директорів та архітекторів зв'язку переглядати підходи до маршрутизації голосового трафіку.
Традиційні підходи до побудови SIP-роутингу, орієнтовані виключно на швидкість комутації та оптимізацію вартості маршруту, більше не здатні забезпечити безпеку голосового ядра. Сучасний softswitch повинен не просто комутувати сесії, а в реальному часі здійснювати глибокий аналіз сигналізації та криптографічно підтверджувати ідентичність абонентів без деградації показників пропускної здатності.
Анатомія загрози: чому застарілий SIP-роутинг пропускає IRSF-фрод
Класичний SIP-роутинг будується на статичних або напівдинамічних таблицях маршрутизації. Отримуючи запит SIP INVITE, softswitch аналізує префікс номера призначення та вибирає транк на основі вартості чи пріоритету. Фундаментальна вразливість цієї схеми полягає у повній довірі до текстових заголовків ідентифікації відправника.
Зловмисники використовують цю слабкість для реалізації масового спуфінгу (підміни номера) та IRSF. Схема працює так: генерується потік викликів на номери з преміальною тарифікацією. Щоб обійти антифрод-системи, шахраї підміняють ідентифікатор абонента (Caller ID). Застарілий softswitch, який не має вбудованих інструментів криптографічної перевірки, безперешкодно пропускає цей трафік.
Спроби розв'язати проблему шляхом простих синхронних запитів до зовнішніх антифрод-платформ під час обробки SIP-сесії призводять до критичного зростання затримки (Post Dial Delay, PDD) та перевантаження сигнальних потоків.
RFC 8224 та STIR/SHAKEN: як працює криптографічна автентифікація в SIP INVITE
Для боротьби з підробкою ідентифікаторів індустрія стандартизувала механізми криптографічного підпису. Згідно з даними IETF, стандарт RFC 8224 визначає використання спеціального заголовка Identity у протоколі SIP для перенесення криптографічно підписаної інформації про походження виклику.
Цей механізм є технічним фундаментом фреймворку STIR/SHAKEN, який, відповідно до вимог FCC, базується на перевірці SIP INVITE за допомогою архітектури відкритих ключів (PKI):
- Автентифікація: Коли абонент ініціює виклик, мережа оператора-відправника підтверджує право абонента використовувати цей номер.
- Криптографічний підпис: На основі підтвердження формується підпис із використанням приватного ключа оператора-ініціатора, який додається в заголовок Identity сигнального пакета.
- Верифікація: Softswitch або сервіс верифікації оператора-термінатора отримує запит, вилучає заголовок Identity та перевіряє підпис за допомогою публічного ключа оператора-відправника.
Впровадження STIR/SHAKEN не ліквідує всі існуючі види телеком-шахрайства. Проте воно унеможливлює безкарний спуфінг номерів, надаючи інструмент для точної ідентифікації джерела виклику.
Архітектурний перехід: від монолітного BSS/OSS до Open Digital Architecture (ODA)
Реалізація криптографічних перевірок на рівні сигналізації вимагає структурних змін в IT-інфраструктурі телеком-оператора. Спроба інтегрувати логіку валідації STIR/SHAKEN у застарілі монолітні системи підтримки бізнесу та операцій (BSS/OSS) зазвичай знижує загальну надійність та гнучкість мережі.
Оптимальним шляхом є перехід до Open Digital Architecture (ODA), розробленої TM Forum. ODA замінює монолітні BSS/OSS на компоновану, API-first архітектуру. Це означає поділ функцій управління трафіком на незалежні сервіси: високопродуктивне ядро маршрутизації (softswitch), асинхронні сервіси криптографічної верифікації та модулі тарифікації. Такий підхід не є простим процесом розгортання типу plug-and-play, а є довгостроковою траєкторією розвитку оператора в напрямку автономних операцій.
Оптимізація продуктивності softswitch при глибокій перевірці сигнального трафіку
Криптографічні обчислення створюють суттєве навантаження на обчислювальні ресурси. Якщо softswitch виконуватиме перевірку підпису для кожного SIP INVITE синхронно, продуктивність маршрутизації значно погіршиться. Для забезпечення безперебійної роботи застосовують такі рішення:
- Асинхронна валідація: Процес перевірки підпису виноситься в окремі мікросервіси через API або черги повідомлень, що дозволяє softswitch паралельно обробляти інші етапи встановлення з'єднання.
- Кешування сертифікатів: Публічні ключі інших операторів зберігаються та оновлюються локально, щоб уникнути затримок на мережеві запити під час сигнальної сесії.
- Гібридна маршрутизація: Поєднання традиційного LCR з інтелектуальним аналізом статусу криптографічної верифікації номера для прийняття рішення про пропуск виклику в режимі реального часу.
Інтеграція DooxSwitch: побудова захищеного та масштабованого голосового ядра
Для практичного розв'язання цих завдань операторам потрібні сучасні рішення класу Class 4/5, які об'єднують можливості маршрутизації та вбудованого білінгу. Прикладом такого продукту є операторська VoIP-платформа DooxSwitch (розробник DooxSwitch, продукт входить до портфеля рішень технологічного альянсу Intecracy Group).
Платформа дозволяє забезпечити гнучкий SIP-роутинг та білінг у реальному часі без зниження продуктивності ядра мережі. Архітектура рішення підтримує інтеграцію із сучасними стандартами автентифікації викликів та дозволяє динамічно управляти трафіком на основі показників якості (QoS), маржинальності LCR та верифікації абонента, відповідаючи вимогам модульного підходу ODA.
| Критерій | Монолітна архітектура (Legacy) | Компонентна архітектура (TM Forum ODA / DooxSwitch) |
|---|---|---|
| Обробка RFC 8224 (Identity) | Синхронна перевірка, що викликає затримки SIP-сесії | Асинхронна валідація через API-first сервіси без деградації роутингу |
| Захист від IRSF та спуфінгу | Реактивний (аналіз CDR постфактум) | Проактивний (блокування на етапі SIP INVITE) |
| Гнучкість налаштування LCR | Ручне оновлення таблиць маршрутизації | Динамічний роутинг на основі реального часу та маржинальності |
Поширені питання
Як впровадження RFC 8224 впливає на показник PDD (Post Dial Delay) softswitch?
При правильній асинхронній архітектурі та використанні локального кешування публічних ключів вплив на PDD зводиться до мінімуму. Однак, у разі застосування застарілих синхронних запитів до зовнішніх серверів без кешування, показник PDD може критично зрости, створюючи помітну затримку.
Чи можна інтегрувати STIR/SHAKEN у softswitch без повної заміни застарілого BSS/OSS?
Так, технічно це можливо шляхом впровадження проміжних пристроїв контролю сесій (SBC) або спеціалізованих мікросервісів автентифікації/верифікації на межі мережі, що частково розвантажує ядро. Але для повної автоматизації доцільний перехід до API-first підходів.
Які вимоги висуває TM Forum ODA до сучасних систем маршрутизації голосового трафіку?
Ключовою вимогою є декомпозиція: перехід від монолітних рішень до модульної архітектури. Системи маршрутизації, білінгу та захисту повинні функціонувати як незалежні компоненти, що взаємодіють виключно через стандартизовані API для забезпечення операційної гнучкості.