Wie RTP-Paketierung Bandbreite und Verzögerung verändert

Eine kürzere RTP-Paketierungsdauer verschickt kleinere Audioabschnitte und erhöht die Zahl der Pakete und Header pro Sekunde. Eine längere Dauer senkt den Header-Aufwand, wartet aber länger auf die zu sammelnden Audiodaten. Diese Einstellung erklärt die gesamte Antwortzeit einer Sprach-KI nicht allein. Entscheidend sind Gesprächsaufkommen, tatsächlicher Netzwerkpfad und der gemessene Ablauf des Gesprächs.

1. Die Grenzen der Berechnung festlegen

Das Beispiel nimmt kontinuierliche, einkanalige G.711-Nutzdaten mit 64 kbit/s an. [2] Hinzu kommen 12 Byte RTP, 8 Byte UDP und 20 Byte IPv4 ohne Optionen; RTP-Erweiterungen und CSRC-Einträge fehlen. [1][3][4] Jedes Paket enthält somit 40 Byte zusätzlich zum Audio. Schreiben Sie diese Annahmen an den Anfang der Kapazitätsplanung, damit alle Beteiligten die Zahlen gleich interpretieren.

Die Rechnung umfasst RTP-Medienverkehr auf der IP-Ebene. Ethernet und andere Lasten der Verbindungsschicht, SRTP-Zusätze, Tunnel, RTCP und Signalisierung fehlen. Ein Schnittstellenzähler kann einen anderen Umfang erfassen. Dokumentieren Sie deshalb Ebene und Messzeitraum, bevor Sie Rechnung und Messung vergleichen. Halten Sie außerdem fest, wie Stille behandelt wird: Das Beispiel setzt keine Verringerung des Verkehrs während Gesprächspausen voraus.

2. 10, 20 und 40 ms gleich berechnen

Pakete pro Sekunde ergeben sich aus 1.000 / ptime(ms). Audio-Byte pro Paket ergeben sich aus 64.000 × ptime(s) / 8. Für die Header-Bitrate gilt Pakete/s × 40 × 8. Die Einheiten sind dezimal: 1 kbit/s entspricht 1.000 Bit pro Sekunde.

Bei 20 ms beträgt die Audio-Nutzlast 160 Byte und das IP-Paket 200 Byte. Zwei Richtungen mit identischen Einstellungen benötigen zusammen ungefähr 160 kbit/s. Bei 10 beziehungsweise 40 ms sind es 192 beziehungsweise 144 kbit/s. Planen Sie bei einer Vollduplexverbindung Eingang und Ausgang getrennt; die Summe beider Richtungen ist nicht der Bedarf einer einzelnen Richtung.

3. Paketierung, Codec-Verarbeitung und Wiedergabe unterscheiden

ptime beschreibt die Audiodauer, die ein RTP-Paket repräsentiert. Sie muss nicht mit der Kodiereinheit oder der Frame-Dauer des Codecs übereinstimmen; ein Paket kann mehrere Kodiereinheiten enthalten. Im G.711-Beispiel bezeichnen 20 ms die Gruppierung von Audio-Abtastwerten. Der Sender sammelt Audio, bis das Paket fertig ist. Der Empfänger kann vor der Wiedergabe eine weitere Wartezeit hinzufügen.

Lesen Sie ptime deshalb nicht als gesamte Verzögerung für Hin- und Rückweg. Netzwerktransport, Warteschlangen, Empfangspuffer, Erkennung des Sprechendes, STT, Modellverarbeitung und Spracherzeugung sind weitere Schritte. Erfassen Sie Zeitstempel an ihren Grenzen, um die Ursache langsamer Antworten zu finden. Messen Sie auch den Abstand zwischen dem letzten hörbaren Laut des Nutzers und dem ersten hörbaren Laut der Antwort. Das erste Netzwerkpaket allein beschreibt das Gesprächserlebnis nur teilweise.

4. Kapazität einer ausgelasteten Supportleitung prüfen

Angenommen, eine Supportleitung bedient 200 gleichzeitige Gespräche mit jeweils einem bidirektionalen Medienabschnitt. Bei 20 ms ergeben sich ungefähr 16 Mbit/s Eingang, 16 Mbit/s Ausgang und insgesamt 32 Mbit/s RTP/IP-Verkehr. Die Schnittstelle empfängt etwa 10.000 Pakete/s und verschickt weitere 10.000 Pakete/s. Diese Planungswerte enthalten weder zusätzlichen Protokollaufwand noch eine Kapazitätsreserve.

Die Leitungsgeschwindigkeit allein reicht für die Prüfung nicht aus. Beobachten Sie auch den Aufwand pro Paket, parallele Transkriptionen und das Verhalten der Warteschlangen. Ein Versuch mit 10 ms verdoppelt die Paketrate, während die Bitrate weniger stark steigt. Bei 40 ms werden weniger Pakete verschickt, doch ein verlorenes Paket betrifft einen längeren Audioabschnitt. Beginnen Sie mit kontrollierten Gesprächen und bilden Sie anschließend realistische Parallelität nach. Behalten Sie dieselben Messpunkte bei, damit der Vergleich aussagekräftig bleibt.

5. Checkliste vor einer Änderung

• Erfassen Sie Codec und tatsächliche Audiodauer pro RTP-Paket für jeden Gesprächsabschnitt. Der Konfigurationsbildschirm allein genügt nicht.
• Vergleichen Sie Bitrate, Paketrate und Zahl gleichzeitiger Gespräche für Eingang und Ausgang im selben Messzeitraum.
• Prüfen Sie Paketverlust, verspätete Pakete, wachsende Warteschlangen und hörbare Aussetzer gemeinsam. Eine durchschnittliche Bitrate verdeckt mögliche Probleme.
• Verwenden Sie dieselben Testsätze und denselben Netzwerkpfad. Ändern Sie nur die Paketierung, damit Unterschiede zugeordnet werden können.
• Definieren Sie vorher Abnahmekriterien und die Einstellung für eine Rückkehr. Bewerten Sie hörbaren Gesprächsablauf, Aufgabenerfüllung und gemessene Zeiten.

6. Häufige Fragen

Sind 20 ms überall die beste Wahl? Nein. Der Wert eignet sich als Ausgangspunkt für Vergleiche. Maßgeblich bleiben die von den Endpunkten akzeptierten Einstellungen und das gemessene Erlebnis. Kleinere Pakete bedeuten nicht automatisch bessere Sprachqualität.

Senken 40 ms die Verzögerung? Der Header-Aufwand sinkt, aber es wird ein längerer Audioabschnitt gesammelt. Erst eine Messung der gesamten Antwortzeit zeigt, ob sich das Gespräch verbessert.

Ist mehr Verkehr als berechnet ein Fehler? Prüfen Sie zunächst den Umfang des Zählers. Kapselung, Kontrollverkehr, weitere Medienabschnitte oder erneute Paketierung können die Differenz erklären. Bestimmen Sie die Ursache mit einer Paketaufzeichnung, bevor Sie den Kapazitätsbedarf korrigieren.