# NGMedia – Medien-Relais in Rust | NGsipStack

> NGMedia leitet Sprache verschlüsselt und im Linux-Kern weiter: SRTP, WebRTC, G.722, Opus, Aufzeichnung, Hot-Standby ohne Gesprächsabbruch.

Quelle: https://ngstack.de/ngmedia

NGMedia · Klarer Ton bei jedem Gespräch

# NGMedia – RTP-Relais in Rust, ng-kompatibel zu rtpengine

Steuerung über das ng-Protokoll (Bencode/UDP) wie rtpengine – der SBC schaltet ohne Codeänderung um. Weiterleitung im Programm oder per XDP im Linux-Kern, SRTP und DTLS in Rust, laufender Abgleich zum Standby-Knoten.

**Verschlüsselt**

**HD-Klang**

**Kein Abbruch** bei Ausfall

## Funktionen

| Bereich | Stand | Details |
|---|---|---|
| Steuerung | ja | ng-Protokoll wie rtpengine (offer, answer, delete, query, list, statistics, play media, DTMF) plus eigene Erweiterungen |
| SRTP SDES | ja | AES_CM_128_HMAC_SHA1_80/_32, AEAD_AES_128/256_GCM (RFC 3711/4568/7714); Rollover, Replay-Fenster 64, eigener Schlüssel je Seite (recrypt)bitgenau gegen rtpengine mr26.2.1.2 und 11.5.1: 32/32 |
| WebRTC | ja | DTLS 1.2/1.3, ICE-lite, rtcp-mux, Fingerprint-Pflicht, kein Klartext vor dem Handshakeechter Browser (Chromium): 18/18 · gegen rtpengine: 36/36 |
| Umrechnung | ja | G.722 ↔ G.711, Opus ↔ G.711/G.722, Tastentöne ↔ Töne im SprachkanalG.722 gegen rtpengine: 12/12, Pegel 1,00–1,01 |
| Kern-Schnellweg | ja | XDP im Linux-Kern für fertig ausgehandelte Gespräche, ohne Kernelmodul; Port-Sperre im KernKern-Prüfung 26/26 |
| Hot-Standby | ja | Zustand jedes Gesprächs samt Schlüsseln verschlüsselt beim Partner, gleiche Ports nach der ÜbernahmeStandby-Prüfung 12/12: hartes Beenden, 0 Pakete verloren |
| Qualität | ja | eigene Messung nach RFC 3550 je Richtung (auch im Kern), RTCP SR/RR/XR, Laufzeit je Strecke, MOS nach E-Modell G.107, Zwischenstände alle 5 s, HEP Typ 5/35 an Homer |
| Aufzeichnung | ja | WAV je Seite + gemischt, Dateinamen wie der rtpengine-Aufnahmedienst, fertig erst mit geschlossenem Kopf; SIPREC-Modus |
| Jitterpuffer | ja | aus (Vorgabe) / fest / adaptiv, je Seite und im laufenden Gespräch umstellbar |
| Endpunkt-Lernen | ja | wie `endpoint-learning = heuristic` (Schutz gegen RTP Bleed, CVE-2025-53399), bei SRTP nur Pakete mit gültigem Prüfwert; Netzwechsel nur nach 3 geprüften Paketen |
| BUNDLE, Trickle-ICE, TURN | geplant | nicht angeboten – Browser mit `bundlePolicy: max-bundle` gehen noch nicht |
| SRTP im Kern | geplant | verschlüsselte Flüsse laufen im Userspace (Stufe R6, geplant) |
| Verteilung | in Arbeit | mehrere Relais-Knoten über den SBC (Rendezvous-Hashing je Call-ID); im Relais selbst ein Prozess je Knoten |

## Messwerte

| Messung | Ergebnis | Rahmen |
|---|---|---|
| Userspace → XDP, 200 Gespräche | Relais-CPU 20,8 % → 0,7 %; Laufzeit P50 0,75 → 0,25 ms, P99 2,65 → 1,45 ms | Netz-Namensräume, eine VM, im Wechsel gemessen |
| Userspace → XDP, 500 Gespräche | Relais-CPU 52 % → 1,5 %; P99 3,5 → 1,65 ms | 50 000 Pakete/s |
| XDP je Paket | 530–590 ns (Userspace ≈ 10 µs) | `kernel.bpf_stats_enabled` |
| 2 000 Gespräche | 4 000 Flüsse im Kern, ~200 000 Pakete/s, 0 Aufbaufehler, 44 MB | 200 Aufbauten/s, Prüfnetz in einer VM |
| Speicher je Gespräch | ~15 KB | Runde 288 |
| G.722 ↔ G.711, Verzögerung | ja | P50 2,25 ms (rtpengine 26,65 ms) |

Messungen in Netz-Namensräumen; der Lastvergleich gegen rtpengine mit Kernelmodul am echten Adapter (Stufe R5) folgt, die Werkzeuge liegen bereit.