Der Codec-Impact auf QoS wird in VoIP-Projekten oft unterschätzt: Viele Teams optimieren Markings, Queues und Shaping – und wundern sich trotzdem über instabile Sprachqualität oder überraschende Engpässe. Dabei entscheidet die Codec-Wahl (z. B. G.711, Opus oder G.729) nicht nur über die subjektive Sprachqualität, sondern auch über Bandbreitenbedarf, Paketgrößen, Burstverhalten, Toleranz gegenüber Packet Loss und Jitter sowie über die Rechenlast durch Transcoding. Für ein sauberes QoS-Design im Telco- oder Enterprise-Umfeld müssen Codec- und Bandbreitenmodelle deshalb von Anfang an in die Planung einfließen: Wie viele gleichzeitige Calls sind realistisch? Welche Paketisierungszeit (ptime) wird genutzt? Welche Overheads entstehen durch RTP/UDP/IP, VLAN, MPLS oder VPN? Und wie verändern sich QoS-Budgets, wenn Opus adaptiv die Bitrate anpasst oder wenn G.729 bei Verlust schneller hörbar wird? Dieser Artikel zeigt, wie sich G.711, Opus und G.729 in QoS-Sicht unterscheiden und wie Sie daraus belastbare Bandbreitenmodelle für Echtzeitklassen ableiten.
Warum Codec-Wahl ein QoS-Thema ist – nicht nur ein „Voice-Feature“
QoS steuert, wie Pakete bei Congestion behandelt werden. Der Codec bestimmt, wie viele Pakete pro Sekunde entstehen, wie groß diese Pakete sind und wie empfindlich sie auf Verzögerung und Verlust reagieren. Daraus folgt: Der Codec beeinflusst direkt, wie groß Ihre Echtzeitklasse sein muss, wie strikt eine Priority-Queue limitiert werden kann und wie wahrscheinlich es ist, dass Mikrobursts oder Policer-Events hörbare Aussetzer erzeugen. Außerdem beeinflusst die Codec-Wahl die Messbarkeit und Interpretation von KPIs wie MOS/R-Faktor, da Codecs unterschiedliche Robustheit (PLC, FEC, Fehlertoleranz) mitbringen.
- Paketfrequenz: ptime bestimmt, wie oft pro Sekunde RTP-Pakete gesendet werden.
- Pakethöhe: Codec-Bitrate und Payload-Größe bestimmen die Paketgröße – plus Protokoll-Overhead.
- Fehlertoleranz: unterschiedliche PLC/FEC-Fähigkeiten ändern die „tolerierbare“ Loss-Rate.
- Transcoding: kann zusätzliche Latenz und CPU-Last erzeugen und damit QoS-Budgets belasten.
Die Bausteine eines Bandbreitenmodells für VoIP
Um Codec-Impact sauber zu bewerten, braucht es ein Bandbreitenmodell, das nicht nur die reine Codec-Bitrate betrachtet. In der Praxis entsteht die Leitungslast pro Call aus Nutzlast plus Overhead. Overhead kommt aus RTP, UDP und IP – zusätzlich aus Layer-2-Encapsulation (Ethernet, VLAN), eventuell MPLS-Labels, GRE/IPsec oder anderen Tunneln. Außerdem spielt die Paketisierungszeit (ptime) eine große Rolle: Kürzere ptime bedeutet mehr Pakete pro Sekunde und damit mehr Header-Overhead, aber oft geringere Algorithmic Delay. Längere ptime reduziert Overhead, kann aber die Latenz erhöhen und macht Loss pro Paket „teurer“, weil mehr Sprachinformation pro Paket verloren geht.
Einfaches Modell: Pakete pro Sekunde und Overhead
- Pakete pro Sekunde: bei ptime 20 ms typischerweise 50 Pakete/s (pro Richtung).
- Payload: hängt von Codec-Bitrate und ptime ab (Bitrate × Zeitfenster).
- Header: RTP/UDP/IP-Header plus Layer-2/Transport-Overhead.
- Gesamtbitrate: (Payload + Header) × Pakete/s.
G.711: Hohe Qualität, hoher Bandbreitenbedarf, einfacher Betrieb
G.711 ist in vielen Netzen der „Baseline“-Codec: sehr gute Sprachqualität, geringe Codec-Komplexität, wenig CPU-Last und häufig die beste Wahl, wenn Bandbreite ausreichend vorhanden ist. Der Nachteil: G.711 erzeugt eine relativ hohe Nutzlast, was pro Call einen deutlich höheren Bandbreitenbedarf bedeutet als komprimierte Codecs. Das wirkt sich besonders in Access- und WAN-Engpässen aus, wo die Echtzeitklasse limitiert werden muss. In QoS-Sicht ist G.711 komfortabel, weil er oft stabile MOS-Werte liefert und Transcoding seltener nötig ist – aber er braucht saubere Kapazitätsplanung, sonst steigt das Risiko von Congestion und damit von Jitter/Packet Loss.
- Vorteile: hohe Qualität, niedrige CPU-Last, geringe Codec-Artefakte, robust im Betrieb.
- Nachteile: höherer Bandbreitenbedarf pro Call, Echtzeitklasse muss größer dimensioniert werden.
- QoS-Implikation: LLQ-Budgets und Headroom müssen Busy Hour realistisch abdecken.
G.729: Bandbreiteneffizient, aber empfindlicher – besonders bei Loss
G.729 ist ein klassischer, stark komprimierender Codec, der Bandbreite spart und lange Zeit in WAN-sensitiven Szenarien beliebt war. Die Kehrseite: Komprimierte Codecs reagieren oft empfindlicher auf Paketverlust und können bei Bursty Loss schneller hörbar „kaputtgehen“. Außerdem ist Transcoding zu oder von G.729 im Provider- oder SBC-Umfeld ein häufiger Faktor: Es kostet CPU und kann zusätzliche Latenz einführen. In QoS-Sicht bedeutet das: Zwar kann die Echtzeitklasse pro Call kleiner dimensioniert werden als bei G.711, dafür müssen Loss- und Jitter-Budgets strenger eingehalten werden, weil die Qualitätsreserve kleiner ist.
- Vorteile: geringerer Bandbreitenbedarf pro Call, sinnvoll bei knappen WAN-Links.
- Nachteile: empfindlicher gegenüber Loss, Transcoding-Aufwand, potenziell geringere QoE.
- QoS-Implikation: besonders auf Loss Pattern achten; Mikroburst-Drops früh erkennen.
Opus: Adaptiv, robust und modern – aber anspruchsvoll im Bandbreitenmodell
Opus ist ein moderner, sehr flexibler Codec, der dynamisch zwischen Sprach- und Musikoptimierung wechseln kann und häufig als besonders robust gegenüber wechselnden Netzwerkbedingungen gilt. Opus kann Bitrate und Verhalten adaptieren, was für QoE vorteilhaft ist, aber Bandbreitenmodelle komplexer macht: Der „typische“ Bandbreitenbedarf ist nicht immer konstant, sondern hängt von Konfiguration, Plattform und Verhalten unter Netzstress ab. Zudem kann Opus zusammen mit Mechanismen wie FEC oder Redundanz arbeiten, die die effektive Bitrate erhöhen, aber Loss besser kaschieren. Für QoS heißt das: Sie brauchen realistische Profile (Konfigurationswerte, erwartete Bitraten-Spannen) und sollten die Echtzeitklasse so dimensionieren, dass kurzzeitige Spitzen nicht sofort zu Drops führen.
- Vorteile: hohe Qualität bei variabler Bitrate, gute Robustheit, oft bessere QoE bei schwierigen Links.
- Nachteile: Bandbreite kann variieren; ohne klare Profile wird Dimensionierung unscharf.
- QoS-Implikation: Sizing nach Perzentilen/Busy Hour, nicht nach „einem“ Durchschnittswert.
Paketisierungszeit (ptime): Der unsichtbare Hebel für Overhead und Loss-Auswirkung
Viele QoS-Planungen betrachten nur den Codec-Namen, nicht aber die Paketisierungszeit. Dabei verändert ptime die Paketfrequenz und damit den Overhead massiv. Kürzere ptime erhöht die Anzahl der Pakete und damit den Header-Anteil; längere ptime reduziert Overhead, kann aber Latenz erhöhen und macht jeden Paketverlust „schwerer“, weil mehr Sprachinhalt pro Paket verloren geht. Für Telcos und große Enterprise-Netze ist ptime deshalb ein bewusster Designparameter: Er beeinflusst sowohl Bandbreitenbudgets als auch Jitter- und Loss-Toleranzen.
- Kurze ptime: mehr Pakete/s, mehr Overhead, oft geringere Algorithmic Delay.
- Lange ptime: weniger Overhead, aber potenziell höhere Latenz und höhere Loss-Auswirkung pro Paket.
- QoS-Praxis: ptime standardisieren, damit Modelle und SLIs/SLOs vergleichbar bleiben.
Overhead in Telco-Netzen: VLAN, MPLS, VPN und warum „Codec-Bitrate“ nicht reicht
In Provider-Netzen kommt häufig zusätzlicher Overhead hinzu: VLAN-Tagging im Access, MPLS-Labels im Core, Pseudowires, GRE/IPsec in Overlays oder Segment-Routing-Encapsulation. Dadurch kann der Unterschied zwischen „reiner Codec-Bitrate“ und „tatsächlicher Leitungslast“ erheblich sein. Für QoS-Design und LLQ-Limits ist deshalb nicht die Codec-Bitrate entscheidend, sondern die echte Paketgröße und Paketfrequenz auf dem Engpasslink. Besonders bei kleinen RTP-Paketen wirkt sich zusätzlicher Header-Overhead prozentual stark aus.
- Layer-2 Overhead: Ethernet/VLAN kann relevant sein, besonders bei vielen kleinen Paketen.
- MPLS/Encapsulation: zusätzliche Bytes pro Paket erhöhen die effektive Bitrate.
- VPN/Overlay: erhöht Overhead und kann MTU-Probleme verursachen; Fragmentierung ist Gift für Echtzeit.
- Shaping: sollte reale Leitungslast berücksichtigen, nicht nur „Nutzdatenrate“.
Codec-Impact auf QoS-Klassen: Wie Sie LLQ-Budgets sinnvoll dimensionieren
Die wichtigste praktische Konsequenz: Die Größe der Echtzeitklasse (Voice Media) hängt direkt vom Codec-Mix und der erwarteten gleichzeitigen Call-Anzahl ab. In professionellen Designs wird die LLQ strikt limitiert, um Missbrauch zu verhindern – daher muss das Limit realistisch gewählt werden. Ein zu knappes Limit erzeugt Policer-Drops oder Queue-Drops und damit sofort hörbare Probleme. Ein zu großes Limit kann andere Klassen aushungern, besonders bei Fehlmarking. Ein guter Weg ist, für jeden relevanten Codec ein Pro-Call-Bandbreitenprofil (inklusive Overhead) zu definieren, daraus Busy-Hour-Lasten abzuleiten und anschließend Headroom für Spitzen, Failover und kurzfristige Bitratenvariation (Opus) einzuplanen.
- Codec-Mix modellieren: Anteil G.711 vs. Opus vs. G.729 in der Realität, nicht in Wunschannahmen.
- Busy Hour: Dimensionierung auf Spitzenzeiten, nicht auf Tagesmittel.
- Headroom: Reserve für Failover, Peaks und Bitratenvariation.
- LLQ-Limit: strikt, aber ausreichend; Monitoring der Auslastung ist Pflicht.
Loss- und Jitter-Toleranz: Warum G.711 „verzeiht“ und G.729 schneller kippt
Auch wenn konkrete Toleranzen von Implementierung und PLC abhängen, lässt sich ein stabiler Grundsatz formulieren: Komprimierte Codecs haben oft weniger „Redundanz“ und reagieren empfindlicher auf Paketverlust, insbesondere auf Bursts. G.711 liefert meist eine hohe Grundqualität und kann kleinere Artefakte weniger „auffällig“ machen, während G.729 bei ähnlichem Loss schneller als „robotisch“ wahrgenommen wird. Opus kann je nach Konfiguration durch Anpassung und FEC erstaunlich robust wirken, aber das kostet unter Umständen zusätzliche Bandbreite. Für QoS-Design heißt das: Je komprimierter und je stärker der Loss-Burst-Impact, desto wichtiger werden Shaping, Mikroburst-Kontrolle und kurze Zeitfenster in der Überwachung.
- Random Loss: kann je nach Codec unterschiedlich auffallen; Bursty Loss ist fast immer kritisch.
- Jitter: trifft alle Codecs; wenn Pakete zu spät kommen, hilft die beste Kompression nicht.
- Opus-FEC: kann Loss kaschieren, erhöht aber die effektive Bitrate.
Transcoding: Der versteckte QoS-Killer im Provider- und SBC-Umfeld
Wenn Calls zwischen Netzen oder Plattformen unterschiedliche Codecs nutzen, wird häufig transcoded – etwa im SBC, Media Gateway oder in UC-Plattformen. Transcoding kostet CPU und kann zusätzliche Verzögerung einführen. Unter Last kann dies zu nichtlinearen Effekten führen: Die Netz-QoS ist korrekt, aber die Sprachqualität sinkt, weil Media-Processing an Grenzen stößt. In QoS- und SLA-Diskussionen ist es daher wichtig, Transcoding als Teil des End-to-End Budgets zu betrachten und Telemetrie nicht nur im Transportnetz, sondern auch in den Media-Komponenten zu etablieren.
- Zusatzlatenz: Processing Delay kann die Interaktivität spürbar verschlechtern.
- CPU-Bottleneck: führt zu Drops/Artefakten, die wie Netzwerkprobleme wirken können.
- Design-Prinzip: Codec-Policy harmonisieren, Transcoding minimieren, Kapazität der Media-Komponenten planen.
Monitoring und SLIs: Codec-Awareness in QoS-KPIs einbauen
Wenn der Codec die Robustheit und den Bandbreitenbedarf beeinflusst, sollten Monitoring und SLOs das reflektieren. Ein guter Ansatz ist, MOS/R-Faktor oder plattformspezifische QoE-Metriken zusammen mit RTP-Loss/Jitter pro Codec auszuwerten. Zusätzlich sind queuebezogene KPIs entscheidend: Queue-Delay und Drops in der Voice-Klasse zeigen früh, ob die LLQ zu knapp dimensioniert ist oder ob Mikrobursts auftreten. Für Opus ist es hilfreich, Bitratenverteilungen (Perzentile) zu beobachten, um die Varianz im Bandbreitenmodell realistisch abzubilden.
- Per-Codec KPIs: Loss/Jitter/MOS nach Codec auswerten, nicht nur global.
- Queue Health: Drops und Queue-Delay in der Voice-Klasse als Frühwarnsystem.
- Perzentile statt Mittelwerte: Peaks und „Bad Minutes“ sichtbar machen.
- Kapazitätsfeedback: reale Auslastung der Echtzeitklasse gegen Budget spiegeln.
Praxis-Blueprint: Bandbreitenmodelle für G.711, Opus und G.729 sauber aufsetzen
Ein belastbares Vorgehen beginnt mit Standardisierung: ptime, Codec-Prioritäten und Transcoding-Policies definieren. Danach wird pro Codec ein Pro-Call-Profil erstellt, das Payload und Overhead in der jeweiligen Transportumgebung berücksichtigt (Access, MPLS, VPN/Overlay). Anschließend wird der reale Codec-Mix in der Busy Hour geschätzt oder gemessen und in ein LLQ-Budget überführt – inklusive Headroom für Failover und Opus-Varianz. Parallel wird QoS so platziert, dass Congestion kontrolliert wird (Shaping am WAN-Edge, HQoS im Access), und Monitoring wird codec-aware aufgebaut (per Codec KPIs, Queue-Delay/Drops). So wird der Codec-Impact auf QoS nicht zum Überraschungsfaktor, sondern zu einem planbaren Bestandteil von Voice-Design und Servicequalität.
