Архитектура системы
Общая архитектура, слои системы, потоки данных и разделение сигнализации и медиа.
Общая схема
Архитектура для крупной компании с присутствием в 43 странах. Гео-распределённая система с полной отказоустойчивостью, SBC на границе каждого региона, локальный breakout трафика (вызовы остаются в регионе), централизованное управление и мониторинг. Каждый регион автономен — при потере связи между регионами локальные вызовы продолжают работать.
═══════════════════════════════════════════════════════════════════════════════════════ ГЛОБАЛЬНАЯ АРХИТЕКТУРА — 43 СТРАНЫ, 4 РЕГИОНА ═══════════════════════════════════════════════════════════════════════════════════════ ┌─────────────────────────────┐ │ КЛИЕНТЫ (43 страны) │ │ WebPhone IP-телефоны │ │ Мобильные Софтфоны │ │ Web UI Contact Center │ └──────────────┬──────────────┘ │ GeoDNS / Anycast (маршрутизация к ближайшему региону) │ ┌──────────────────────────────┬┴┬──────────────────────────────┐ ▼ ▼ ▼ ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ РЕГИОН: EUROPE │ │ РЕГИОН: AMERICAS │ │ РЕГИОН: ASIA-PAC │ + MIDDLE EAST │ Frankfurt (Primary) │ │ US-East (Primary) │ │ Singapore (Primary) │ Dubai │ Amsterdam (Standby) │ │ US-West (Standby) │ │ Tokyo (Standby) │ │ ~20 стран │ │ ~10 стран │ │ ~8 стран │ ~5 стран └──────────┬───────────┘ └──────────┬───────────┘ └──────────┬───────────┘ │ │ │ └───────────────────────────┼───────────────────────────┘ │ Межрегиональная связь (WireGuard VPN mesh / выделенные каналы) │ ┌────────┴────────┐ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ CENTRAL MGMT │ │ GLOBAL MONITOR │ │ Go API Master │ │ Homer + Grafana │ │ PostgreSQL (HA) │ │ Prometheus │ │ Admin Panel │ │ Loki (logs) │ └──────────────────┘ └──────────────────┘
Каждый регион — это полностью автономный кластер со всеми компонентами. Ниже — детальная схема одного региона (Europe / Frankfurt):
═══════════════════════════════════════════════════════════════════════════════════════ РЕГИОН EUROPE (Frankfurt) — детальная архитектура ═══════════════════════════════════════════════════════════════════════════════════════ КЛИЕНТЫ РЕГИОНА ┌───────────┬────────────┬──────────────┬───────────────┐ │ Web UI │ WebPhone │ IP-телефоны │ Мобильные │ │ (React) │ (SIP.js) │ Yealink,Snom │ iOS/Android │ └─────┬─────┴─────┬──────┴───────┬──────┴──────┬────────┘ │HTTPS │WSS │SIP/TLS │SIP/TLS ▼ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────┐ │ СЛОЙ 1: EDGE / LOAD BALANCER │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ HAProxy / Nginx │ │ HAProxy / Nginx │ (Active/Active)│ │ │ HTTPS, WSS │ │ HTTPS, WSS │ │ │ │ TLS termination│ │ TLS termination│ │ │ └────────┬────────┘ └────────┬────────┘ │ │ └──────────┬─────────┘ │ └──────────────────────┼──────────────────────────────────┘ │ ┌──────────────────────┼──────────────────────────────────┐ │ СЛОЙ 2: SBC (Session Border Controller) │ │ │ │ │ ┌───────────────────▼───────────────────┐ │ │ │ Kamailio SBC Cluster (Active/Active) │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ │ │ KAM-SBC-1 │ │ KAM-SBC-2 │ │ Keepalived │ │ │ │ Внешний │ │ Внешний │ │ Floating │ │ │ │ интерфейс │ │ интерфейс │ │ VIP │ │ │ └──────┬─────┘ └──────┬─────┘ │ │ │ │ └────────┬────────┘ │ │ │ │ │ │ │ │ │ Функции SBC: │ │ │ │ • Topology hiding (скрытие топологии) │ │ │ │ • SIP normalization (нормализация) │ │ │ │ • Anti-fraud / rate limiting │ │ │ │ • TLS termination для SIP │ │ │ │ • Транк-аутентификация (IP ACL) │ │ │ │ • DDoS protection (pike + htable) │ │ │ │ • Протокол-конвертация (WSS↔UDP) │ │ │ └────────────────────┬──────────────────-┘ │ │ ┌────────────────────▼───────────────────┐ │ │ │ RTPEngine Cluster │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ │ │ RTPE-1 │ │ RTPE-2 │ │ │ │ │ │ NAT trav. │ │ NAT trav. │ │ │ │ │ │ SRTP↔RTP │ │ SRTP↔RTP │ │ │ │ │ │ WebRTC↔SIP │ │ WebRTC↔SIP │ │ │ │ │ └────────────┘ └────────────┘ │ │ │ └────────────────────────────────────────┘ │ └──────────────────────┬──────────────────────────────────┘ │ SIP (внутренний, доверенный) ┌──────────────────────┼──────────────────────────────────┐ │ СЛОЙ 3: CORE SIP PROXY │ │ │ │ │ ┌───────────────────▼───────────────────┐ │ │ │ Kamailio Core Cluster (Active/Active) │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ │ │ KAM-CORE-1 │ │ KAM-CORE-2 │ │ DMQ sync │ │ │ │ Регистрация│ │ Регистрация│ │ между │ │ │ │ Маршрутиз. │ │ Маршрутиз. │ │ нодами │ │ │ │ LB → FS │ │ LB → FS │ │ │ │ │ └──────┬─────┘ └──────┬─────┘ │ │ │ │ └────────┬────────┘ │ │ │ └──────────────────┼─────────────────────┘ │ │ │ │ │ Функции Core: │ │ │ • User registration (usrloc) │ │ • Internal routing (диалплан, DID) │ │ • Load balancing → FreeSWITCH (dispatcher) │ │ • Failover между FS-нодами │ │ • Dialog tracking │ └─────────────────────┼────────────────────────────────────┘ │ ┌─────────────────────┼────────────────────────────────────┐ │ СЛОЙ 4: MEDIA SERVERS (FreeSWITCH Cluster) │ │ │ │ │ ┌──────────────────▼──────────────────────────────┐ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ FS-1 │ │ FS-2 │ │ FS-N │ │ │ │ │ │ IVR │ │ IVR │ │ IVR │ │ │ │ │ │ Queues │ │ Queues │ │ Queues │ │ │ │ │ │ Conf │ │ Conf │ │ Conf │ │ │ │ │ │ Record │ │ Record │ │ Record │ │ │ │ │ │ Bridge │ │ Bridge │ │ Bridge │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ (горизонтальное масштабирование по нагрузке) │ │ │ └─────────────────────────────────────────────────┘ │ └──────────┬──────────────┬──────────────┬─────────────────┘ │ESL │CDR │recordings ▼ ▼ ▼ ┌──────────────────────────────────────────────────────────┐ │ СЛОЙ 5: APPLICATION & API │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ │ │ │ Go API-1 │ │ Go API-2 │ │ Go API-N │ │ │ │ REST/WS │ │ REST/WS │ │ REST/WS │ │ │ │ ESL client │ │ ESL client │ │ ESL client │ │ │ │ CDR writer │ │ Dialer │ │ Webhooks │ │ │ └─────────────┘ └─────────────┘ └──────────────┘ │ └──────────┬──────────────┬──────────────┬─────────────────┘ │ │ │ ┌──────────┼──────────────┼──────────────┼─────────────────┐ │ СЛОЙ 6: DATA & EVENTS │ │ │ │ │ │ │ │ │ ┌───────▼─────┐ ┌─────▼─────┐ ┌─────▼──────┐ │ │ │PostgreSQL │ │ Redis │ │ NATS │ │ │ │Primary + │ │ Sentinel │ │ Cluster │ │ │ │Replica (HA) │ │ Cluster │ │ (JetStream)│ │ │ └─────────────┘ └───────────┘ └────────────┘ │ │ │ │ ┌─────────────┐ ┌───────────────┐ │ │ │ MinIO (S3) │ │ Homer + Grafana│ │ │ │ Recordings │ │ SIP capture │ │ │ │ Voicemail │ │ Prometheus │ │ │ │ IVR audio │ │ Loki (logs) │ │ │ └─────────────┘ └───────────────┘ │ └──────────────────────────────────────────────────────────┘ │ │ SIP (от Core к транкам) │ ┌──────────┼───────────────────────────────────────────────┐ │ СЛОЙ 7: TRUNK SBC (Session Border Controller — PSTN) │ │ │ │ │ ┌───────▼──────────────────────────────────────┐ │ │ │ Kamailio Trunk SBC (Active/Active) │ │ │ │ │ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ KAM-TRUNK-1 │ │ KAM-TRUNK-2 │ │Keepalived│ │ │ │ SIP-facing │ │ SIP-facing │ │Floating │ │ │ │ к провайдерам│ │ к провайдерам│ │VIP │ │ │ └──────┬──────┘ └──────┬──────┘ │ │ │ │ └────────┬────────┘ │ │ │ │ │ │ │ │ │ Функции Trunk SBC: │ │ │ │ • SIP-нормализация (разные провайдеры = разный SIP) │ │ │ • Транк-аутентификация (IP ACL + credentials) │ │ │ • E.164 нормализация номеров │ │ │ • LCR (Least Cost Routing) между транками │ │ │ • Failover: primary → backup провайдер │ │ │ • Topology hiding от провайдеров │ │ │ • Anti-fraud / toll fraud protection │ │ │ • Кодек-переговоры (Offer/Answer) с провайдерами │ │ │ • Caller ID manipulation / CNAM │ │ └────────────────────┬─────────────────────────┘ │ │ │ │ │ ┌────────────────────▼───────────────────┐ │ │ │ RTPEngine Trunk (опционально) │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ │ │ RTPE-T1 │ │ RTPE-T2 │ │ │ │ │ │ Кодек │ │ Кодек │ │ │ │ │ │ транскод. │ │ транскод. │ │ │ │ │ │ G.711↔G.729│ │ G.711↔G.729│ │ │ │ │ └────────────┘ └────────────┘ │ │ │ │ (для провайдеров с жёсткими кодек- │ │ │ │ требованиями или RTP-пиннингом) │ │ │ └────────────────────────────────────────┘ │ └──────────────────────┬────────────────────────────────────┘ │ ┌──────────────────────┼───────────────────────────────────┐ │ СЛОЙ 8: PSTN / ВНЕШНИЙ МИР │ │ │ │ │ ┌───────────────────▼───────────────────────────────┐ │ │ │ SIP-транки (локальные для региона) │ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ │ │ Telnyx │ │ Twilio │ │ Локальный │ │ │ │ │ │ (backup) │ │ (primary)│ │ оператор │ │ │ │ │ └──────────┘ └──────────┘ │ (DE, FR, UK) │ │ │ │ │ └──────────────┘ │ │ │ │ Маршрутизация: LCR + failover + geo-local │ │ │ └───────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────┘
1. Тройной Kamailio — Access SBC (внешний, клиенты/интернет), Core (внутренний, маршрутизация), Trunk SBC (внешний, PSTN-провайдеры). Три зоны доверия: Access SBC принимает удар из интернета, Trunk SBC нормализует трафик от провайдеров, Core работает только с доверенным трафиком от обоих SBC.
2. Двусторонняя граница — SBC и на северной стороне (клиенты), и на южной (PSTN). Внутренняя сеть полностью изолирована от внешнего мира с обоих направлений.
3. Гео-распределение — каждый регион автономен. Звонки внутри региона не зависят от других регионов.
4. Локальный breakout — звонок из Германии на немецкий номер идёт через локальный транк в Frankfurt, не через US.
5. Все компоненты в HA — нет единой точки отказа. Каждый компонент задублирован минимум 2x.
При работе в 43 странах с десятками SIP-провайдеров SBC обязателен. Это не дублирование Kamailio Core — это принципиально другая роль: граница доверия между внешним миром и вашей внутренней сетью.
| Компонент | Зона | Задачи | Почему отдельный |
|---|---|---|---|
| Kamailio Access SBC | DMZ North / клиенты | Topology hiding, anti-DDoS, SIP normalization, TLS termination, протокол-конвертация (WSS↔UDP), NAT traversal | Принимает весь недоверенный трафик от клиентов из интернета. Северная граница |
| RTPEngine Access | DMZ North / клиенты | NAT traversal, SRTP↔RTP, WebRTC bridge, медиа-прокси для клиентского трафика | Медиа-трафик из интернета не попадает напрямую к FreeSWITCH |
| Kamailio Core | Внутренняя сеть | Регистрация пользователей, внутренняя маршрутизация, LB между FreeSWITCH, dialog tracking | Работает только с доверенным трафиком от обоих SBC. Оптимизирован под скорость, не под защиту |
| FreeSWITCH | Внутренняя сеть | IVR, очереди, конференции, запись, bridge, диалплан | Никогда не виден из интернета. Занимается только медиа-логикой |
| Kamailio Trunk SBC | DMZ South / PSTN | SIP-нормализация для разных провайдеров, транк-аутентификация (IP ACL + credentials), E.164 нормализация, LCR, Caller ID, anti-fraud | Изолирует внутреннюю сеть от PSTN-провайдеров. Южная граница. Каждый провайдер «видит» только Trunk SBC |
| RTPEngine Trunk | DMZ South / PSTN | Транскодирование кодеков (G.711↔G.729), RTP-пиннинг, медиа-прокси для PSTN-трафика | Опциональный. Нужен если провайдеры требуют специфические кодеки или RTP-параметры |
На нашем масштабе оба SBC (Access + Trunk) необходимы:
Access SBC (северная граница — клиенты):
— Защита от атак — публичные SIP-адреса постоянно сканируются ботами, без SBC внутренняя сеть уязвима
— WebRTC-мост — конвертация WSS/DTLS-SRTP от браузеров в стандартный SIP/RTP
— NAT traversal — клиенты за NAT, SBC решает проблемы доставки медиа
Trunk SBC (южная граница — PSTN-провайдеры):
— Десятки SIP-транков в разных странах с разными особенностями SIP-стека (каждый оператор кодирует SIP по-своему)
— Регуляторные требования — в ряде стран (ОАЭ, Сингапур, Германия) оператор требует сертифицированную точку подключения
— Нормализация SIP — разные провайдеры отправляют CallerID, кодеки и заголовки в разных форматах, Trunk SBC приводит всё к единому виду
— LCR + Failover — маршрутизация по стоимости между провайдерами, автоматическое переключение при отказе транка
— Anti-fraud — защита от toll fraud (мошеннические звонки на premium-номера) на уровне транков
Compliance (оба SBC):
— GDPR (Europe), CCPA (US), локальные законы о записи звонков требуют контроля на обеих границах
Межрегиональная маршрутизация и GeoDNS
┌──────────────────┐
│ GeoDNS │
│ sip.company.com │
└────────┬─────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ EU SBC Cluster │ │ US SBC Cluster │ │ APAC SBC │
│ Frankfurt │ │ Virginia │ │ Singapore │
│ 2x Kamailio │ │ 2x Kamailio │ │ 2x Kamailio │
│ 2x RTPEngine │ │ 2x RTPEngine │ │ 2x RTPEngine │
└───────┬────────┘ └───────┬────────┘ └───────┬────────┘
│ │ │
└─────────┬─────────┴─────────┬─────────┘
│ │
▼ ▼
WireGuard VPN Mesh SIP trunk routing:
(между регионами) EU user → EU trunk
US user → US trunk
Cross-region → nearest
Правила межрегиональной маршрутизации:
┌─────────────────────────────────────────────────────────┐
│ 1. Звонок внутри региона → локальный FreeSWITCH + транк│
│ 2. Звонок между регионами → VPN → SBC другого региона │
│ 3. PSTN → ближайший к номеру регион (local breakout) │
│ 4. Failover: EU primary down → EU standby │
│ EU standby down → US cluster (geo-failover) │
└─────────────────────────────────────────────────────────┘
| Регион | Primary ДЦ | Standby ДЦ | Страны | Локальные транки |
|---|---|---|---|---|
| Europe | Frankfurt, DE | Amsterdam, NL | ~20 (DE, FR, UK, ES, IT, PL, ...) | Deutsche Telekom, BT, Orange, Telnyx EU |
| Americas | Virginia, US | Oregon, US | ~10 (US, CA, MX, BR, AR, ...) | Twilio, Bandwidth, Telnyx US |
| Asia-Pacific | Singapore | Tokyo, JP | ~8 (SG, JP, AU, IN, KR, ...) | SingTel, NTT, Telstra, Tata |
| Middle East | Dubai, UAE | Frankfurt (EU failover) | ~5 (UAE, SA, QA, KW, BH) | du, Etisalat, STC |
Сетевые зоны безопасности (Network Zones)
ИНТЕРНЕТ — КЛИЕНТЫ (недоверенная зона North) ───────────────────────────────────────────────── │ WebRTC-браузеры, SIP-телефоны за NAT, мобильные ───────────────────────────────────────────────── │ FIREWALL L1 (North) │ DMZ NORTH — Access (полу-доверенная зона) ───────────────────────────────────────────────── │ Kamailio Access SBC — внешний SIP от клиентов │ RTPEngine Access — медиа-прокси, SRTP↔RTP │ HAProxy/Nginx — HTTPS/WSS, TLS termination │ TURN-сервер — relay для WebRTC ───────────────────────────────────────────────── │ FIREWALL L2 │ CORE (доверенная зона) ───────────────────────────────────────────────── │ Kamailio Core — внутренняя маршрутизация │ FreeSWITCH — медиа-обработка (IVR, очереди) │ Go API — бизнес-логика, ESL, WebSocket ───────────────────────────────────────────────── │ FIREWALL L3 │ DATA (защищённая зона) ───────────────────────────────────────────────── │ PostgreSQL — данные (шифрование at rest) │ Redis — кеш и сессии │ MinIO — записи разговоров │ NATS — шина событий ───────────────────────────────────────────────── │ FIREWALL L4 │ DMZ SOUTH — Trunk (полу-доверенная зона) ───────────────────────────────────────────────── │ Kamailio Trunk SBC — SIP к PSTN-провайдерам │ RTPEngine Trunk — транскодирование кодеков │ Нормализация SIP, LCR, anti-fraud, Caller ID ───────────────────────────────────────────────── │ FIREWALL L5 (South) │ PSTN / ВНЕШНИЕ ПРОВАЙДЕРЫ (недоверенная зона South) ───────────────────────────────────────────────── │ SIP-транки (Telnyx, Twilio, локальные операторы) │ SMS-шлюзы, внешние API ─────────────────────────────────────────────────
Северная граница (клиенты): Любой SIP/RTP от клиентов из интернета сначала проходит через Access SBC (DMZ North), где нормализуется, фильтруется и проксируется. Только доверенный трафик от Access SBC попадает к Kamailio Core и FreeSWITCH.
Южная граница (PSTN): Исходящие вызовы к PSTN проходят через Trunk SBC (DMZ South), который нормализует SIP под требования каждого провайдера, применяет LCR-маршрутизацию и защищает от toll fraud. Провайдеры видят только Trunk SBC, а не внутреннюю архитектуру.
Данные (PostgreSQL, Redis) находятся в самой защищённой зоне и недоступны извне — ни с северной, ни с южной стороны.
Слои системы
Система разделена на шесть функциональных слоёв. Каждый слой изолирован и взаимодействует с соседними по чётко определённым протоколам.
Точки входа пользователей в систему. Четыре типа клиентов:
React — веб-интерфейс администратора и оператора (управление, статистика, настройки).
SIP.js — веб-телефон в браузере через WebRTC (звонки без установки ПО).
IP-телефоны — аппаратные SIP-телефоны (Yealink, Grandstream, Snom).
Мобильные — SIP-клиенты на смартфонах (Ooh, Ooh, Ooh Ooh Ooh, Ooh Ooh Ooh Ooh, Ooh Ooh, Ooh Ooh, Ooh Ooh Ooh Ooh, и т.д.).
Входная точка для всего трафика. Два компонента:
Nginx — reverse proxy для HTTP/HTTPS и WebSocket. TLS-терминация, маршрутизация запросов к Go API и WebSocket-соединений к Kamailio.
Kamailio — SIP proxy/registrar. Регистрация устройств, аутентификация, маршрутизация SIP, балансировка нагрузки между FreeSWITCH-серверами, обработка NAT.
Центральный узел управления системой:
Go Backend API — REST API и WebSocket-сервер. Управление пользователями, правами, настройками. Логика автообзвона, аналитика, CDR-записи, интеграции с CRM. Взаимодействует с FreeSWITCH через ESL (Event Socket Library).
Обработка голоса и медиа-потоков:
FreeSWITCH — медиа-сервер (B2BUA). IVR, очереди, конференции, запись, диалплан. Кластер из N серверов для горизонтального масштабирования.
RTPEngine — медиа-прокси. Транскодирование (WebRTC ↔ RTP), управление NAT для медиа, проксирование голосового трафика.
Персистентное и оперативное хранение:
PostgreSQL — основная БД: пользователи, настройки, CDR, диалпланы, маршрутизация.
Redis — кеш и оперативные данные: сессии, статусы операторов, блокировки, очереди задач.
MinIO — S3-совместимое хранилище: записи разговоров, голосовые сообщения, файлы IVR.
Второй SBC — пограничный контроллер между внутренней сетью и PSTN-провайдерами:
Kamailio Trunk SBC — SIP-нормализация для разных провайдеров, транк-аутентификация, E.164 нормализация номеров, LCR-маршрутизация, Caller ID manipulation, anti-fraud.
RTPEngine Trunk — опциональный, для транскодирования кодеков (G.711↔G.729) если провайдеры требуют специфические форматы.
Topology hiding — провайдеры видят только Trunk SBC, а не внутреннюю архитектуру.
Связь с внешними сетями и сервисами:
SIP-транки — подключение к PSTN через провайдеров (Telnyx, Twilio, локальные операторы). Входящие и исходящие вызовы на обычные телефоны.
SMS-шлюзы — отправка SMS-уведомлений (пропущенные, callback).
Внешние API — CRM, Helpdesk, системы аналитики.
Потоки данных
Три основных сценария звонков, показывающие как данные проходят через все слои системы.
Клиент звонит на номер компании, проходит IVR-меню и попадает к свободному оператору.
Оператор звонит клиенту через веб-телефон (SIP.js в браузере) на мобильный номер.
Сотрудник звонит коллеге из браузера на настольный IP-телефон внутри компании.
Сигнализация vs Медиа
Фундаментальный принцип VoIP-архитектуры: сигнализация и медиа идут по совершенно разным путям, через разные компоненты, по разным протоколам. Сигнализация (SIP) — это управляющий канал: «кто звонит, кому, принять или отклонить». Медиа (RTP) — это сам голос, реальные аудио-данные. Понимание этого разделения критически важно для диагностики и архитектуры.
═══ СИГНАЛИЗАЦИЯ (Control Plane) ═══ ═══ МЕДИА (Data Plane) ═══ Протокол: SIP Протокол: RTP / SRTP Транспорт: TCP / UDP / WSS Транспорт: UDP Нагрузка: Лёгкая (текстовые сообщения) Нагрузка: Тяжёлая (50 пакетов/сек) Задача: Управление вызовами Задача: Передача голоса ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Телефон │─SIP─▶│ Kamailio │─SIP─▶│FreeSWITCH│ └──────────┘ └──────────┘ └──────────┘ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Телефон A│═RTP═▶│RTPEngine │═RTP═▶│ Телефон B│ └──────────┘ └──────────┘ └──────────┘ Сигнализация проходит: Медиа проходит: Телефон → Kamailio → FreeSWITCH Телефон A → RTPEngine → Телефон B (настройка, изменение, завершение) (голос, реальное время)
Путь: Телефон → Kamailio → FreeSWITCH
Протокол: SIP (TCP/UDP/WSS, порт 5060/5061)
Характер: Лёгкий трафик, текстовые сообщения
Задачи: Установка вызова, перевод, удержание, завершение, регистрация устройств
Компоненты: Kamailio (маршрутизация), FreeSWITCH (логика)
Путь: Телефон A → RTPEngine → Телефон B
Протокол: RTP/SRTP (UDP, порты 10000–20000)
Характер: Тяжёлый трафик, 50 пакетов/сек на поток
Задачи: Передача голоса, транскодирование, шифрование
Компоненты: RTPEngine (прокси, транскодирование)
Сигнализация — это SMS-сообщения, которыми вы договариваетесь о встрече: «Давай встретимся в кафе в 15:00». Медиа — это сама встреча: реальный разговор лицом к лицу. SMS идут через сотового оператора, а встреча происходит в кафе — совершенно разные каналы для совершенно разных задач.
Если звонок устанавливается (телефон звонит), но нет голоса — проблема в медиа-пути (RTPEngine, NAT, файрволл для UDP-портов). Если звонок вообще не проходит — проблема в сигнализации (Kamailio, SIP-маршрутизация, аутентификация). Диагностика всегда начинается с определения: «Это проблема сигнализации или медиа?»