Codec-Auswahl und QoS hängen enger zusammen, als viele VoIP-Projekte am Anfang vermuten. Häufig wird der Codec rein nach „klingt gut“ oder „spart Bandbreite“ entschieden – und erst später merkt man, dass Sprachqualität im Betrieb nicht nur vom Codec abhängt, sondern von Latenz, Jitter, Paketverlust, Burst-Verhalten, Transcoding und der Fähigkeit des Netzes, Echtzeitpakete zuverlässig zu priorisieren. Ein Codec wie G.711 liefert zwar exzellente Sprachqualität und ist technisch robust, benötigt aber mehr Bandbreite pro Call. Ein komprimierter Codec wie G.729 spart Bandbreite, ist aber empfindlicher gegenüber Verlustmustern und kann bei falscher Paketisierung oder in überlasteten SBCs schneller an Grenzen stoßen. Opus wiederum ist sehr flexibel, kann bei niedrigen Bitraten erstaunlich gut klingen und passt sich dynamisch an – stellt aber höhere Anforderungen an Interoperabilität, Konfiguration und teilweise auch an die Stabilität der Echtzeitpfade, weil die dynamische Regelung nur dann optimal funktioniert, wenn Jitter und Drop-Cluster nicht aus dem Ruder laufen. Für ein professionelles Design bedeutet das: Codec-Auswahl und QoS müssen gemeinsam geplant werden. Sie definieren zuerst, welche Qualitätsziele (MOS/R-Faktor, maximale Latenz, Jitter, Loss) erreicht werden sollen, welche Netzdarstellung vorhanden ist (LAN, WAN, MPLS, Internet, VPN, Wi-Fi), und wählen dann einen Codec, dessen Bandbreitenprofil, Fehlertoleranz und Betriebsaufwand zu Ihrem Szenario passen. Dieser Artikel vergleicht G.711, G.729, Opus und weitere gängige Codecs aus Sicht von Sprachqualität, Bandbreite, Robustheit und QoS-Design – praxisnah und direkt umsetzbar.
Warum Codec-Auswahl immer auch eine QoS-Entscheidung ist
Ein VoIP-Call ist nicht einfach „Audio über IP“, sondern ein Echtzeitstrom (RTP/SRTP), der auf zeitkritische Zustellung angewiesen ist. Der Codec bestimmt dabei mehrere Eigenschaften, die QoS direkt beeinflussen:
- Bitrate und Paketgröße: beeinflussen, wie viel Bandbreite Sie pro Call planen müssen und wie stark Overhead ins Gewicht fällt.
- Paketisierungszeit: bestimmt die Paketfrequenz (PPS) und damit Overhead, Gerätebelastung und Latenz.
- Fehlertoleranz: wie stark hört man einzelne Drops, wie gut kaschiert der Codec Verluste?
- Transcoding-Risiko: wenn Endpunkte unterschiedliche Codecs sprechen, muss umkodiert werden – das kostet CPU, erhöht Latenz und kann Qualität verschlechtern.
QoS wiederum bestimmt, ob diese Eigenschaften „stabil“ bleiben: LLQ für Audio, Shaping gegen Bufferbloat, Vermeidung von Drop-Clustern und konsistente Markierung (DSCP EF) sind oft wichtiger für die reale Qualität als der „perfekte“ Codec auf dem Papier.
Die zwei Grundfragen vor jeder Codec-Entscheidung
Bevor Sie G.711, G.729 oder Opus vergleichen, sollten Sie zwei Fragen beantworten:
- Welche Transportumgebung? LAN mit Überkapazität, MPLS/Carrier-Backbone, Internet-VPN, Wi-Fi Calling, mobile Backhaul, Contact Center mit vielen gleichzeitigen Calls?
- Welche Betriebsziele? maximale Verständlichkeit, minimale Bandbreite, höchste Interoperabilität, geringste CPU-Last, beste Qualität bei Paketverlust?
In einem gut gemanagten LAN ist der Codec oft weniger kritisch als in einem knappen Upstream oder über VPN/Internet. In einem Contact Center sind Planbarkeit und CPU-Reserve wichtiger als „theoretisch beste Klangfarbe“.
Bandbreite pro Call: Warum komprimiert nicht automatisch „viel weniger“ bedeutet
Viele erwarten bei G.729 (8 kbit/s) achtmal weniger Bandbreite als bei G.711 (64 kbit/s). In Wirklichkeit bleibt der RTP/UDP/IP-Overhead gleich, und je kleiner die Payload, desto größer der Overheadanteil. Mit typischer 20-ms-Paketisierung (50 Pakete/s) ergeben sich grobe Richtwerte (pro Richtung, inklusive praxisnaher Layer-2-Reserve):
- G.711: oft grob 85–100 kbit/s pro Richtung
- G.729: oft grob 30–40 kbit/s pro Richtung
Das ist immer noch eine deutliche Ersparnis, aber nicht im Verhältnis 64:8. Für QoS bedeutet das: Auch „sparsame“ Codecs benötigen saubere Echtzeitqueues und Upstream-Shaping, sonst knackt es trotz geringer Bitrate.
Paketisierungszeit: 10 ms, 20 ms, 30 ms – der versteckte Qualitätshebel
Die Paketisierungszeit beeinflusst Latenz, Overhead und Verlustwirkung:
- 10 ms: mehr Pakete/s, mehr Overhead, mehr PPS-Last, tendenziell geringere Codec-Latenz
- 20 ms: Standard in vielen Umgebungen, guter Kompromiss
- 30 ms: weniger Overhead, aber höhere Latenz und größerer „Schaden“ pro Paketverlust
QoS-relevant ist vor allem: Kürzere Intervalle erzeugen mehr Pakete und damit mehr Potenzial für Microbursts, wenn Geräte/Queues nicht sauber arbeiten. Längere Intervalle reduzieren Overhead, können aber bei Jitter und Loss hörbarer sein. Für viele Enterprise- und Telco-Setups ist 20 ms ein stabiler Standard.
G.711: Qualität, Interoperabilität und einfache Betriebsführung
G.711 (PCMU/PCMA) ist in vielen Netzen die „Baseline“ für sehr gute Sprachqualität. Er komprimiert nicht stark, ist rechenleicht und nahezu überall verfügbar.
- Stärken: hohe Qualität, sehr geringe Codec-CPU, höchste Interoperabilität, einfaches Troubleshooting.
- Schwächen: höherer Bandbreitenbedarf pro Call, in knappen Upstreams schneller limitierend.
- QoS-Implikation: weniger anfällig für CPU/Transcoding-Probleme, aber benötigt stabile Echtzeitpfade, weil RTP trotzdem jitter- und loss-sensibel bleibt.
G.711 ist oft die beste Wahl, wenn Bandbreite ausreichend ist und Sie maximale Kompatibilität wollen – etwa in Carrier-Interconnects, SIP-Trunks und heterogenen Endgeräteflotten.
G.729: Bandbreite sparen, aber sauber planen
G.729 ist ein klassischer Low-Bitrate-Codec, der Bandbreite deutlich reduziert. In knappen WANs oder bei vielen gleichzeitigen Calls kann das wirtschaftlich wichtig sein.
- Stärken: deutlich geringerer Payload, mehr Calls pro Link, gute Sprachverständlichkeit bei stabilen Netzen.
- Schwächen: stärkerer Overheadanteil, potenziell empfindlicher gegenüber Loss/Delay-Spitzen, Transcoding kann CPU-lastig sein.
- QoS-Implikation: Bandbreite ist weniger das Problem, Stabilität des Engpasses ist entscheidend (Shaping gegen Bufferbloat, LLQ für Audio). Policer-Drops sind besonders schädlich, weil Verlust bei komprimierten Codecs schneller hörbar wird.
G.729 ist sinnvoll, wenn Sie Bandbreite wirklich knapp halten müssen – aber nur, wenn Sie konsequent QoS einsetzen und Transcoding vermeiden oder ausreichend dimensionieren.
Opus: flexibel, modern, sehr gut – aber mit Designverantwortung
Opus ist in WebRTC und modernen UC-Stacks sehr verbreitet. Er kann bei niedrigen Bitraten erstaunlich gut klingen und skaliert bis zu sehr hoher Qualität. Er ist zudem adaptiv: Bitrate und Eigenschaften können dynamisch angepasst werden.
- Stärken: sehr gute Qualität über breites Bitratenband, robust in vielen realen Netzen, ideal für WebRTC.
- Schwächen: Interoperabilität zu klassischen SIP/Carrier-Setups ist nicht immer trivial; falsche Parameter (Bitrate, FEC, Packetization) können QoE verschlechtern; Transcoding zu G.711/G.729 ist häufig nötig.
- QoS-Implikation: Opus profitiert stark von stabilen Throughput- und Delay-Bedingungen. Wenn das Netz Microbursts, Bufferbloat oder Drop-Cluster erzeugt, reagiert die Adaptation oft mit Qualitätssprüngen. Gute QoS-Mechanik (LLQ für Audio, Shaping am Upstream, stabile Queue-Limits) macht Opus spürbar „ruhiger“.
Opus ist oft die beste Wahl in modernen WebRTC-/UC-Umgebungen, besonders wenn End-to-End Opus möglich ist. In klassischen SIP-Trunk-Szenarien ist G.711 oft operativ einfacher.
Weitere Codecs: AMR/AMR-WB, G.722 und warum sie relevant sind
In Mobilfunk- und IMS-Umgebungen sind AMR und AMR-WB (Wideband) zentral. Im Enterprise-Umfeld sieht man häufig G.722 (Wideband) für HD-Voice.
- G.722: liefert Wideband-Qualität, ähnlich „einfach“ wie G.711 im Betrieb, oft in internen UC-Umgebungen beliebt.
- AMR/AMR-WB: in VoLTE/VoNR Standard, optimiert für Funkbedingungen und kann in mobilen Netzen sehr robust wirken.
QoS-technisch gilt auch hier: Wideband ist oft nicht „viel mehr Bandbreite“, aber die Anforderungen an Jitter/Loss bleiben gleich. In Mobilfunknetzen ist zusätzlich das 5QI/QFI-Design entscheidend.
Transcoding: Der stille Qualitäts- und Kapazitätskiller
In der Praxis entstehen viele Qualitätsprobleme nicht durch den Codec selbst, sondern durch Transcoding an SBCs, Gateways oder Cloud-Edges. Transcoding:
- kostet CPU: bei hoher Auslastung entsteht Compute-Jitter, der sich als Paketjitter äußern kann.
- erhöht Latenz: zusätzliche Verarbeitung und Buffering.
- verschlechtert Qualität: jede Umkodierung kann Artefakte hinzufügen, besonders von/zu stark komprimierten Codecs.
Best Practice ist daher: Codec-End-to-End so weit wie möglich vereinheitlichen. Wenn Transcoding unvermeidbar ist, müssen SBCs/Media-Relays auf Peak dimensioniert und QoS-seitig sauber eingebunden sein.
Fehlertoleranz: Welche Codecs verzeihen Paketverlust besser?
Kein Sprachcodec „mag“ Paketverlust. Aber die Wahrnehmung unterscheidet sich:
- Loss-Cluster sind immer schlecht: unabhängig vom Codec. Sie erzeugen hörbare Lücken.
- Komprimierte Codecs: können bei gleicher Verlustquote subjektiv schneller „kaputt“ wirken, weil weniger Redundanz vorhanden ist.
- Mechanismen wie FEC/PLC: manche Stacks nutzen Forward Error Correction oder Packet Loss Concealment; das kann helfen, ersetzt aber kein QoS.
Für QoS heißt das: Fokus auf Verlustvermeidung an Engpässen (LLQ, Shaping, keine harten Policer auf Audio, kontrollierte Queue-Limits). Das verbessert jeden Codec stärker als „Codec wechseln“.
QoS-Designregeln je nach Codec-Strategie
Die Codec-Auswahl beeinflusst, wie Sie QoS dimensionieren und absichern:
- G.711-dominiert: LLQ-Limit höher dimensionieren, dafür weniger Transcoding-Risiko; Bandbreite in WAN/Access sicherstellen.
- G.729-dominiert: LLQ-Limit niedriger möglich, aber Overhead bleibt relevant; besonders auf Drop-Cluster achten; Transcoding vermeiden.
- Opus/WebRTC-dominiert: neben LLQ für Audio ist Upstream-Shaping gegen Bufferbloat entscheidend, weil Adaptation sonst pendelt; Interop zu SIP-Trunks bewusst planen.
In allen Fällen gilt: Audio in EF/LLQ mit Limit, Signaling separat, Video niemals in EF.
Praxis-Blueprint: Codec-Auswahl mit QoS zusammen entscheiden
- Szenario festlegen: LAN, WAN, MPLS, Internet, VPN, Wi-Fi, Mobilfunk, Contact Center.
- QoS-Ziele definieren: maximale Latenz, Jitter, Loss, gewünschter MOS/R-Faktor, Peak-Busy-Hour.
- Codec-Interoperabilität prüfen: Endpunkte, SBC, Trunks, Cloud-UC, PSTN-Gateways.
- Bandbreite pro Call realistisch rechnen: Overhead, Packetization, IPv4/IPv6, VLAN/PPPoE/VPN berücksichtigen.
- Transcoding minimieren: End-to-End Codec-Set standardisieren, SBC-Kapazität für unvermeidbares Transcoding planen.
- QoS umsetzen: Audio EF/LLQ mit Limit, Shaping am Upstream, Trust Boundary, konsistentes DSCP->CoS/TC Mapping.
- Validieren: Queue-Drops, Queueing Delay, Policer-Hits, MOS/R-Faktor, Call Setup Times überwachen.
Typische Fehler in Codec- und QoS-Projekten
- „Wir nehmen den sparsamsten Codec“: ohne QoS und ohne Transcoding-Plan wird es unter Last schlechter, nicht besser.
- Alles als EF markieren: Video/Content in EF → Premium-Inflation, Voice leidet.
- Policing statt Shaping: harte Drops auf Audio erzeugen Knacken, egal welcher Codec.
- IPv6 vergessen: andere Header, andere Policies; QoS greift nur in IPv4.
- Security-Hop zerstört Markierung: Firewall/VPN neutralisiert DSCP, Underlay sieht Best Effort.
Häufige Fragen zur Codec-Auswahl und QoS
Ist G.711 immer „besser“ als G.729?
Qualitativ liefert G.711 meist eine sehr natürliche Stimme und ist operativ einfach. G.729 ist sinnvoll, wenn Bandbreite knapp ist oder viele Calls über schmale Links laufen. „Besser“ hängt vom Szenario ab – entscheidend ist, dass QoS und Transcoding-Strategie passen.
Warum klingt Opus in der Praxis oft sehr gut?
Weil Opus über ein breites Bitratenband gute Qualität liefert und sich an Bedingungen anpassen kann. Damit diese Vorteile wirken, muss das Netz jedoch stabil sein: Shaping gegen Bufferbloat, LLQ für Audio und die Vermeidung von Drop-Cluster sind besonders wichtig.
Was ist wichtiger: Codec oder QoS?
Für die reale Nutzererfahrung ist QoS oft der größere Hebel. Ein guter Codec kann schlechte Netzbedingungen nur begrenzt kaschieren. Umgekehrt kann ein sauber gebautes QoS (LLQ für Audio, Shaping, Trust Boundary, konsistentes Mapping) selbst mit „einfachen“ Codecs eine sehr stabile, professionelle Sprachqualität liefern.