Bandbreitenplanung für Voice: Wie viel braucht ein VoIP-Call wirklich?

Bandbreitenplanung für Voice ist eine der wichtigsten Grundlagen, wenn VoIP im Alltag zuverlässig funktionieren soll – unabhängig davon, ob es um ein kleines Büro, ein Contact Center oder ein Provider-Netz geht. Viele Teams unterschätzen den tatsächlichen Bandbreitenbedarf eines VoIP-Calls, weil sie nur die Codec-Bitrate betrachten (z. B. „G.711 hat 64 kbit/s“) und den Protokoll-Overhead ignorieren. In der Praxis entscheidet jedoch nicht nur der Codec, sondern auch die Paketisierungszeit (z. B. 20 ms), die Header von RTP/UDP/IP, Verschlüsselung (SRTP, VPN), Layer-2-Overhead (Ethernet, VLAN, PPPoE) und das Verhalten unter Last (Bursts, Queueing). Wer hier sauber rechnet, kann QoS-Klassen realistisch dimensionieren, LLQ-Limits richtig setzen und Engpässe vermeiden – besonders im Upstream, wo Bufferbloat und harte Rate-Limits schnell zu Jitter und hörbarem Knacken führen. Dieser Artikel zeigt verständlich, wie Sie den Bandbreitenbedarf pro Call korrekt berechnen, typische Werte für gängige Codecs ableiten, Reserven sinnvoll planen und typische Stolperfallen (VAD, Transcoding, SRTP, Dual-Stack) berücksichtigen.

Warum „Codec-Bitrate“ nicht gleich „Call-Bandbreite“ ist

Die Codec-Bitrate beschreibt nur den Nutzdatenstrom (Payload) des Audiocodecs. VoIP transportiert diese Nutzdaten aber in Paketen, und jedes Paket trägt zusätzliche Informationen:

• RTP: Sequenznummern, Timestamps, Payload-Type (typisch 12 Byte Header).
• UDP: Port-Informationen, Prüfsumme (8 Byte Header).
• IP: Routing-Informationen (IPv4 typischerweise 20 Byte, IPv6 typischerweise 40 Byte).
• Layer 2: Ethernet-Header, VLAN-Tag(s), ggf. PPPoE, Interframe Gap, Preamble (je nach Medium).

Je kleiner die Audiopayload pro Paket ist, desto stärker fällt der Overhead ins Gewicht. Bei 20-ms-Paketisierung erzeugen Sie 50 Pakete pro Sekunde – das ist gut für geringe Latenz, erhöht aber den Overheadanteil.

Die Grundformel: Bandbreite pro Richtung berechnen

Für eine überschlägige, aber praxistaugliche Berechnung reicht diese Logik: Bits pro Paket mal Pakete pro Sekunde. In HTML-kompatibler Schreibweise:

$B=(\mathrm{Payload}+\mathrm{Overhead})\times \mathrm{PPS}$

Wobei:

• Payload: Audiopayload pro Paket in Bit oder Byte (abhängig von Codec und Paketisierungszeit).
• Overhead: Summe aus RTP/UDP/IP und ggf. Layer-2-/Tunnel-Overhead pro Paket.
• PPS (Packets per Second): bei 20 ms typischerweise 50 pps, bei 30 ms typischerweise ~33,33 pps, bei 10 ms typischerweise 100 pps.

Wichtig: Diese Bandbreite gilt pro Richtung. Ein Gespräch ist bidirektional. Für die Leitungsplanung addieren Sie also Up- und Downstream – und berücksichtigen gleichzeitige Gespräche.

Schritt 1: Payload pro Paket aus Codec und Paketisierung

Der Audiocodec erzeugt einen kontinuierlichen Bitstrom. Die Payload pro Paket ergibt sich aus:

$\mathrm{PayloadBytes}=\mathrm{CodecBitrate}\times \mathrm{Packetization}/8$

Beispiele für 20 ms (0,02 s):

• G.711 (64 kbit/s): 64.000 bit/s × 0,02 s = 1.280 bit = 160 Byte Payload.
• G.729 (8 kbit/s): 8.000 bit/s × 0,02 s = 160 bit = 20 Byte Payload.
• Opus (variabel): hängt von Konfiguration ab (z. B. 24 kbit/s → 60 Byte Payload bei 20 ms als grobe Näherung).

Je kleiner die Payload, desto mehr dominiert der Header-Overhead.

Schritt 2: IP/UDP/RTP-Overhead korrekt ansetzen

Für klassische RTP-Streams ohne zusätzliche Header können Sie als Basis rechnen:

• RTP: 12 Byte
• UDP: 8 Byte
• IPv4: 20 Byte (ohne Optionen)
• IPv6: 40 Byte (ohne Extension Header)

Damit ergeben sich typische L3/L4/L7-Headergrößen:

• IPv4-RTP: 12 + 8 + 20 = 40 Byte Overhead pro Paket (ohne Layer 2).
• IPv6-RTP: 12 + 8 + 40 = 60 Byte Overhead pro Paket (ohne Layer 2).

Schon hier sieht man: IPv6 erhöht den Overhead pro Paket. Das ist kein Problem, solange Sie es in der Bandbreitenplanung berücksichtigen.

Schritt 3: Layer-2-Overhead – oft der unterschätzte Teil

Im LAN/WAN tragen Frames zusätzlichen Overhead. Für Ethernet ist (vereinfacht) relevant:

• Ethernet Header + FCS: typischerweise 18 Byte (14 Byte Header + 4 Byte FCS).
• 802.1Q VLAN-Tag: +4 Byte (bei Q-in-Q entsprechend mehr).
• Preamble + Interframe Gap: auf dem Medium zusätzlich, häufig mit ~20 Byte äquivalent angesetzt.

Für eine praxisnahe Planung (ohne sich in Bit-Timing zu verlieren) rechnen viele Engineers pro Paket zusätzlich mit:

• Ethernet „on the wire“: ungefähr 38–42 Byte extra (je nach VLAN/IFG/Preamble-Annahme).

Wenn Sie PPPoE/DSL oder bestimmte Access-Techniken nutzen, kommt weiterer Overhead hinzu. Wichtig ist nicht die letzte Nachkommastelle, sondern dass Sie konsistent und konservativ planen.

Rechenbeispiele: Wie viel Bandbreite braucht ein VoIP-Call wirklich?

Im Folgenden sind praxistaugliche Richtwerte für eine Richtung (One-Way) bei 20 ms Paketisierung. Zur Orientierung nutzen wir IPv4-RTP (40 Byte L3/L4/RTP-Overhead) plus einen konservativen Ethernet-Aufschlag.

Beispiel A: G.711 (64 kbit/s), 20 ms, IPv4

• Payload: 160 Byte
• RTP/UDP/IP: 40 Byte
• Summe L3: 200 Byte pro Paket
• PPS: 50
• L3-Bandbreite: 200 × 8 × 50 = 80.000 bit/s = 80 kbit/s pro Richtung

Mit Ethernet-Overhead (konservativ) landen Sie in der Praxis häufig bei etwa 85–95 kbit/s pro Richtung. Ein bidirektionaler Call liegt damit grob bei 170–190 kbit/s.

Beispiel B: G.729 (8 kbit/s), 20 ms, IPv4

• Payload: 20 Byte
• RTP/UDP/IP: 40 Byte
• Summe L3: 60 Byte pro Paket
• PPS: 50
• L3-Bandbreite: 60 × 8 × 50 = 24.000 bit/s = 24 kbit/s pro Richtung

Mit Ethernet-Overhead landen Sie typischerweise bei 30–35 kbit/s pro Richtung, also 60–70 kbit/s pro Call bidirektional. Der Codec spart Payload, aber der Overhead bleibt – daher ist der Unterschied nicht „64 vs. 8“, sondern deutlich kleiner.

Beispiel C: G.711, 20 ms, IPv6

• Payload: 160 Byte
• RTP/UDP/IPv6: 60 Byte
• Summe L3: 220 Byte pro Paket
• L3-Bandbreite: 220 × 8 × 50 = 88.000 bit/s = 88 kbit/s pro Richtung

Mit Layer-2-Overhead ergibt sich grob 95–105 kbit/s pro Richtung. Das ist in vielen Netzen unkritisch, aber für knappe Links und genaue Profile relevant.

Paketisierungszeit: 10 ms, 20 ms, 30 ms – was ändert sich?

Die Paketisierungszeit (Packetization Interval) beeinflusst den Overhead und die Latenz. Kürzere Intervalle bedeuten mehr Pakete pro Sekunde, also mehr Overhead, aber potenziell geringere Codec-Latenz. Längere Intervalle reduzieren Overhead, erhöhen aber die „Codec-Latenz“ und können bei Verlust größere hörbare Lücken erzeugen.

• 10 ms: 100 pps → mehr Overhead, mehr PPS-Last auf Geräten, tendenziell geringere Verzögerung
• 20 ms: 50 pps → gängiger Standard, guter Kompromiss
• 30 ms: ~33 pps → weniger Overhead, aber höhere Latenz und größere Verlustauswirkung pro Paket

Für Bandbreitenplanung heißt das: Wenn Sie von 20 ms auf 30 ms gehen, sinkt der Overheadanteil deutlich. Wenn Sie auf 10 ms gehen, steigt er stark. Gleichzeitig müssen Endgeräte, SBCs und Netzkomponenten mehr Pakete verarbeiten.

VAD/Silence Suppression: Spart Bandbreite, ist aber kein verlässlicher Planungsfaktor

Viele Codecs können Voice Activity Detection (VAD) nutzen und in Sprechpausen weniger oder keine RTP-Pakete senden. Das kann Bandbreite sparen, ist aber für Kapazitätsplanung heikel:

• Sprechpausen sind unvorhersehbar: In Stresssituationen (Contact Center) ist der „Sprechanteil“ oft höher.
• Komfortgeräusche: Manche Implementierungen senden weiterhin kleine Pakete (CNG), wodurch nicht „0“ entsteht.
• QoS-Limits: LLQ- und Profil-Dimensionierung sollten nicht auf VAD-Sparannahmen beruhen.

Best Practice: Planen Sie konservativ ohne VAD-Einsparung, nutzen Sie VAD höchstens als „Bonus“ im Betrieb.

SRTP, VPN und Tunnel: Wenn Sicherheit Bandbreite kostet

Telefoniemedien sind heute häufig verschlüsselt (SRTP), und in vielen Umgebungen laufen sie zusätzlich durch VPNs oder Tunnel. Bandbreitenplanung muss diese Overheads berücksichtigen:

• SRTP: fügt pro Paket zusätzliche Felder (Authentifizierung/Tag, ggf. MKI) hinzu; die genaue Größe hängt von Profil/Implementierung ab.
• IPsec/UDP-Tunnel: Outer-IP/UDP/ESP-Header erhöhen die Paketgröße; zudem entscheidet der Outer-Header über QoS im Underlay.
• MTU: Overhead kann Fragmentierung verursachen, was Voice massiv schadet; Bandbreite ist dann nicht das Hauptproblem, sondern Paketverlust durch Fragment-/PMTUD-Probleme.

Praktisch heißt das: Wenn Voice über VPN läuft, planen Sie zusätzliche Reserve pro Call ein und stellen Sie sicher, dass DSCP/EF korrekt in den Outer-Header gemappt wird, damit QoS im Underlay nicht „unsichtbar“ wird.

Wie viele gleichzeitige Calls? Dimensionierung pro Standort

Der Bandbreitenbedarf pro Call ist nur die halbe Antwort. Die andere Hälfte lautet: Wie viele gleichzeitige Gespräche treten realistisch auf? Typische Ansätze:

• Worst-Case: alle Geräte gleichzeitig im Call (sehr konservativ, oft teuer).
• Busy-Hour-Annahme: realistische Gleichzeitigkeit basierend auf Nutzung (z. B. Contact Center mit hoher Concurrent Ratio).
• Messdaten: vorhandene Call-Statistiken (Peak Concurrent Calls) sind der beste Input, wenn verfügbar.

Praktische Vorgehensweise für Standortplanung:

• Schritt 1: Codec und Paketisierung festlegen (z. B. G.711, 20 ms).
• Schritt 2: Bandbreite pro Call pro Richtung konservativ ansetzen (inkl. Overhead).
• Schritt 3: erwartete gleichzeitige Calls multiplizieren (Upstream und Downstream getrennt betrachten).
• Schritt 4: Reserve für Signaling, RTCP, Fehlerfälle, Bursts und Wachstum hinzufügen (typisch 15–30 %, je nach Kritikalität).

QoS-Implikation: LLQ-Limit und Klassenbudgets aus der Bandbreitenplanung ableiten

Bandbreitenplanung ist nicht nur für Linkkapazität wichtig, sondern auch für QoS-Parameter. Wenn Sie Audio als EF in eine LLQ legen, müssen Sie das LLQ-Limit sinnvoll setzen:

• Zu niedrig: Voice läuft ins Limit, es entstehen Drops oder Delay-Spikes → Knacken.
• Zu hoch: Voice-Klasse kann andere Klassen verdrängen, besonders bei Fehlmarkierung → Netzinstabilität.

Deshalb sollte das LLQ-Limit aus dem konservativen Peak-Bedarf der gleichzeitigen Calls abgeleitet werden, plus einer kleinen Reserve. Gleichzeitig brauchen Sie eine Trust Boundary, damit nicht „alles“ in EF landet.

Häufige Stolperfallen in der Praxis

• Nur Downstream geplant: Voice ist oft symmetrisch, aber Engpässe liegen häufig im Upstream (Filialen, Heimnetze).
• Overhead ignoriert: besonders bei kleinen Payload-Codecs und kurzen Packetization-Intervallen.
• Video in Voice-Klasse: Videokonferenzen oder Screen Sharing als EF markiert → Premium-Inflation.
• Firewall/NAT neutralisiert DSCP: QoS wirkt nicht, obwohl intern korrekt markiert.
• Policing statt Shaping am Engpass: harte Drops erzeugen Drop-Cluster; Voice knackt trotz „genug Bandbreite“.
• IPv6 nicht berücksichtigt: größerer Header, andere Policies; Voice über v6 landet plötzlich im Default.

Checkliste: Bandbreitenplanung für Voice schnell und sauber durchführen

• Codec & Packetization festlegen: z. B. G.711, 20 ms (50 pps) oder G.729, 20 ms.
• Overhead wählen: IPv4 vs. IPv6, RTP/UDP/IP, plus L2 und ggf. Tunnel.
• Pro-Call-Bandbreite pro Richtung berechnen: Payload + Overhead pro Paket × pps.
• Bidirektional denken: Upstream und Downstream getrennt dimensionieren.
• Gleichzeitigkeit definieren: Peak Concurrent Calls statt Geräteanzahl.
• Reserve einplanen: 15–30 % je nach SLA/Kritikalität, plus Signaling/RTCP.
• QoS daraus ableiten: LLQ-Limit passend setzen, Trust Boundary aktivieren, Shaping am Engpass nutzen.
• Validieren: Monitoring auf Queue-Drops, Queueing Delay, Policer-Hits und MOS/R-Faktor (wo verfügbar).