Перейти до змісту

10.5 Робочий референс — софтовий IMS-стенд

[!IMPORTANT] Проєкт lyatanski/ims — це повний, цілком софтовий IMS — Kamailio CSCF плюс повний supporting cast — зшитий через Docker Compose і Helm, запускається на одній машині. Цей розділ мапить його компоненти на решту цієї частини.

[!NOTE] lyatanski/ims — сторонній лаб, що підтримується незалежно від цього посібника. Сприймайте його як навчально-тестовий референс, не як production-blueprint, і звіряйтеся з репозиторієм щодо поточного стану — він активно розвивається.

Що це

Відтворюваний, цілком опенсорсний IMS-core, що підіймається однією командою docker compose або передеплоюється на Kubernetes через прикладені Helm-чарти. Він цілить у VoLTE/5G-flow'и і тримається 3GPP-специфікацій (TS 23.228, 24.229, Cx 29.228/229, Rx 29.214, charging 32.299).

Компоненти, змапані на цю частину

Стек розбитий на Compose-профілі — IMS, core network, billing, monitoring, test — які лягають майже один-в-один на 10.4:

Шар Компонент Грає роль Покрито в
IMS-сигналізація Kamailio (P/I/S-CSCF) CSCF 10.2
Медіа rtpengine медіа-релей 10.4
Маршрутизація CoreDNS NAPTR/SRV/ENUM 10.4
Стан MariaDB / Valkey стор S-CSCF / rtpengine 10.2
Абонент/політика open5gs HSS, PCRF 10.3
Пакетне ядро open5gs SMF, UPF (CUPS) 10.4
Diameter-маршрутизація freeDiameter DRA 10.3
Білінг CGRateS OCS 10.3
Моніторинг Prometheus · Grafana · Loki · cAdvisor · Promtail observability 10.4
Тестовий UE Doubango-форк + go-gtp телефон — 
flowchart LR
    Test([тестовий UE]) -->|GTP| CORE[open5gs<br/>SMF · UPF]
    CORE -->|Gm| P[P-CSCF]
    P --- I[I-CSCF] --- S[S-CSCF]
    P -.Rx.-> PCRF[(PCRF)]
    I -.Cx.-> DRA{{freeDiameter DRA}} -.-> HSS[(HSS)]
    S -.Cx.-> DRA
    S -.Ro.-> OCS[(CGRateS)]
    P --- RTP[rtpengine]
    S --- RTP

    classDef cscf fill:#1f6feb,stroke:#1f6feb,color:#fff
    classDef ext fill:#bf8700,stroke:#bf8700,color:#fff
    classDef media fill:#238636,stroke:#238636,color:#fff
    class P,I,S cscf
    class PCRF,HSS,OCS,DRA ext
    class RTP,CORE,Test media

Як усередині налаштований Kamailio

Лаб тримає три CSCF-ролі як окремі конфіги Kamailio зі спільною базою:

  • common.cfg — спільні завантаження модулів і дефолти
  • proxy.cfg — P-CSCF
  • interrogating.cfg — I-CSCF
  • serving.cfg — S-CSCF
  • 5g.cfg, monitor.cfg — 5G-специфічна обв'язка і metrics/health-ендпоінт

У цих конфігах можна вичитати точний набір ims_*-модулів, що описувала ця частина — список loadmodule включає:

cdp            cdp_avp            ims_auth
ims_icscf      ims_registrar_pcscf  ims_registrar_scscf
ims_usrloc_pcscf  ims_usrloc_scscf  ims_ipsec_pcscf
ims_isc        ims_qos            ims_charging
ims_dialog     rtpengine          db_redis

плюс звичні робочі конячки (tm, rr, sl, sanity, siputils, textops, pv, presence/pua для reg-event-підписки, і xhttp_prom для Prometheus-метрик). Завантажені разом у role-specific-файлах, вони — мапа роль→модуль із 10.2 у конкретній формі.

Що з цим робити

Репо постачає flow-доки (doc/registration.md, doc/session.md, doc/transaction.md) і doc по reference-points, що дзеркалить таблицю з 10.1. Продуктивний цикл:

  1. Підняти (docker compose --profile test up -d — воно вантажить kernel-модуль, тож рекомендована VM).
  2. Дивитися на дріт: wireshark -i any --display-filter 'gtpv2 or sip or diameter.cmd.code != 280' (відфільтрувавши Diameter-watchdog'и).
  3. Тригернути реєстрацію і простежити двопрохідний flow із 10.2 пакет за пакетом — REGISTER, UAR/UAA, MAR/MAA, 401, IPSec, SAR/SAA, 200, далі reg-event SUBSCRIBE.

Простеживши цей один обмін на дроті, ви мапите всю частину на реальні пакети.

Інший кут — академічний single-VM-стенд

Контрастний, навчально-орієнтований сетап — IMS-Kamailio-Tutorial від Ana Belén García Hernando (Universidad Politécnica de Madrid): повний IMS на одній VM, оптимізований під чіткі Wireshark-flow'и, а не під реалістичність.

  • Усі три CSCF-ролі — це Kamailio. P-CSCF (:5060), S-CSCF (:6060) та I-CSCF (:4060) крутяться як три окремі процеси Kamailio на одному хості (форк herlesupreeth із Kamailio_IMS_Config-шаблонами) — один бінар покриває весь шар CSCF. Кожна роль тримає свій kamailio_*.cfg, *.xml (конфіг Diameter-peer'а cdp) і файл defines.
  • Інший склад компонентів. Kamailio з FHoSS (Java-HSS від FOKUS з лінії OpenIMSCore) замість open5gs, bind9 для DNS, PJSUA як тестовий UA — контраст із виборами 10.4: ролі важать більше за продукти.
  • Чистий IMS, без EPC. Без пакетного ядра, тож немає Rx-інтерфейсу і підняття bearer'а — SIP+Cx-ядро IMS в ізоляції.
  • Capture-first. Кожна функція отримує свій 127.0.0.X-loopback; cgroups + iptables SNAT + nflog дають один capture з коректно-адресованими, причинно-впорядкованими трасами.

Обидва стенди походять від upstream-рецепту — Open5GS «VoLTE Setup with Kamailio IMS and Open5GS» Сукчана Лі.

Підсумок

IMS ставить Kamailio в обмежену роль: conformant-CSCF, що володіє SIP-reference-points і делегує Cx/Rx/Ro/Rf зовнішнім Diameter-peer'ам. Два стенди зшивають цю роль двома способами — cloud-native (Compose/Helm, ядро open5gs) і single-VM (FHoSS, фокус на capture). Обидва — read-the-configs, run-the-flows-референси для всього з 10.1–10.4.

← Зміст · ← 10.4 Повне рішення · Далі: 11.1 Ролі процесів →