Der Packetization Interval (häufig als ptime bezeichnet) ist einer der unterschätztesten Stellhebel im VoIP- und RTP-Design – und gleichzeitig ein Parameter, der QoS messbar beeinflusst. Ob ein Sprachstream mit 20 ms oder 30 ms paketisiert wird, entscheidet nicht nur über die Anzahl der Pakete pro Sekunde, sondern auch über Header-Overhead, Burstverhalten, Jitter-Resilienz, die Auswirkung einzelner Paketverluste und über die Dimensionierung von Echtzeitklassen (LLQ) im WAN oder Provider-Core. In Telco- und Enterprise-Netzen führt ptime deshalb oft zu „unerklärlichen“ Effekten: Eine QoS-Konfiguration, die mit 20 ms stabil läuft, kann bei 30 ms plötzlich häufiger hörbare Aussetzer erzeugen – oder umgekehrt kann ein knapper WAN-Link mit 30 ms deutlich weniger Header-Overhead haben und damit entspannter wirken. Wer Packetization Interval professionell plant, behandelt ptime als Teil des Bandbreiten-, Latenz- und Loss-Budgets und standardisiert ihn pro Service, statt ihn dem Zufall von Endgeräten, SBCs oder UC-Plattformen zu überlassen.
Was bedeutet Packetization Interval (ptime) technisch?
ptime beschreibt, wie viele Millisekunden Audio (oder generell Mediendaten) in einem RTP-Paket zusammengefasst werden. Bei 20 ms enthält jedes RTP-Paket typischerweise 20 ms Sprachsamples, bei 30 ms entsprechend 30 ms. Daraus ergibt sich direkt die Paketfrequenz: Je kleiner ptime, desto mehr Pakete pro Sekunde werden gesendet. Diese Paketfrequenz ist aus QoS-Sicht entscheidend, weil sie den Anteil des Protokoll-Overheads (RTP/UDP/IP plus Layer-2/Encapsulation) bestimmt und weil sie das Verhalten in Warteschlangen (Queues) und bei Mikrobursts beeinflusst.
- 20 ms: typischerweise 50 RTP-Pakete pro Sekunde (pro Richtung).
- 30 ms: typischerweise ca. 33,3 RTP-Pakete pro Sekunde (pro Richtung).
- Konsequenz: weniger Pakete/s bedeutet weniger Header-Overhead, aber „größere“ Audio-Blöcke pro Paket.
Warum 20 ms vs. 30 ms die Bandbreite verändert – obwohl der Codec gleich bleibt
Viele verwechseln Codec-Bitrate mit Leitungslast. Die Codec-Bitrate beschreibt die Nutzlast, nicht den Overhead. RTP-Streams bestehen aus vielen kleinen Paketen; dabei ist der Header-Anteil oft erheblich. Wenn ptime von 20 ms auf 30 ms erhöht wird, sinkt die Anzahl der Pakete pro Sekunde um rund ein Drittel. Damit sinkt auch der Anteil der Header pro Sekunde – und die effektive Leitungslast pro Call kann spürbar fallen, vor allem bei komprimierten Codecs, bei denen die Payload klein ist und der Header prozentual stark ins Gewicht fällt.
- Header-Overhead: RTP/UDP/IP-Header fällt pro Paket an, unabhängig von der Codec-Nutzlast.
- Encapsulation: VLAN, MPLS, GRE/IPsec erhöhen Bytes pro Paket zusätzlich.
- Effekt: 30 ms kann auf knappen Links mehr gleichzeitige Calls ermöglichen, weil weniger Overhead anfällt.
Warum dieser Effekt in Telco-Netzen besonders sichtbar ist
Provider- und WAN-Links sind häufig die ersten echten Congestion Points. Wenn dort Shaping und LLQ-Limits sehr eng gesetzt sind, kann ein Drittel weniger Pakete pro Sekunde den Unterschied machen zwischen „LLQ bleibt stabil“ und „LLQ produziert Drops“. Gerade bei vielen parallelen Calls oder bei Busy-Hour-Peaks wirkt ptime daher wie ein Multiplikator.
Der QoS-Kernpunkt: ptime verändert das Loss-Risiko pro Ereignis
Bei Echtzeit ist nicht nur die durchschnittliche Loss-Rate entscheidend, sondern wie viel Nutzinformation pro verlorenem Paket verschwindet. Ein einzelnes verlorenes RTP-Paket entspricht näherungsweise einem verlorenen Audio-Block in Höhe der ptime. Bei 20 ms bedeutet ein Paketverlust: 20 ms Audio fehlen. Bei 30 ms fehlen 30 ms Audio – also 50% mehr verlorener Inhalt pro Drop-Ereignis. Das ist der Grund, warum 30 ms in Netzen mit sporadischen Drops oder burstigem Loss häufig „härter“ klingt, obwohl die durchschnittliche Loss-Rate gleich sein kann.
- 20 ms: feinere Granularität, einzelne Drops wirken oft weniger gravierend.
- 30 ms: gröbere Granularität, Drops sind akustisch stärker wahrnehmbar.
- Bursty Loss: mehrere verlorene Pakete am Stück sind bei 30 ms besonders kritisch, weil lange Lücken entstehen.
ptime und Jitter: Warum größere Pakete nicht automatisch „stabiler“ sind
Jitter ist die Schwankung der Laufzeit. ptime beeinflusst Jitter indirekt über Queueing und Buffering. Mit 30 ms gibt es weniger Pakete pro Sekunde, was in manchen Netzen die Wahrscheinlichkeit reduziert, dass RTP-Pakete in einem vollen Best-Effort-Pulk „untergehen“. Gleichzeitig bedeutet 30 ms oft, dass der Jitter-Buffer anders arbeitet: Größere Audio-Blöcke pro Paket erhöhen die Anforderungen an gleichmäßige Lieferung, weil ein verspätetes Paket mehr „Playout-Zeit“ beeinflusst. In der Praxis gilt: In sehr stabilen Netzen kann 30 ms Vorteile durch geringeren Overhead bringen; in jitteranfälligen Netzen (WLAN, stark ausgelastete Aggregation) ist 20 ms oft toleranter, weil Ausreißer kleiner ausfallen.
- WLAN/Funk: variable Retries erzeugen Jitter; kleinere ptime kann Ausreißer weniger drastisch machen.
- WAN mit Shaping: geringerer Overhead kann Jitter reduzieren, weil weniger Queue-Druck entsteht.
- Queue-Limits: große Buffers erzeugen Bufferbloat; ptime ändert, wie schnell Queues „gefühlt“ anwachsen.
Queueing und Scheduling: Was ptime in LLQ und CBWFQ verändert
QoS arbeitet in Warteschlangen. Für Voice-Media wird häufig eine Low-Latency Queue (LLQ) eingesetzt, die strikte Priorität bietet, aber limitiert sein muss. ptime beeinflusst die Paketfrequenz und damit das Scheduling-Verhalten: Bei 20 ms müssen 50 Pakete pro Sekunde bedient werden, bei 30 ms nur etwa 33. Das reduziert Scheduling-Overhead und kann in bestimmten Plattformen die Queue-Stabilität verbessern. Gleichzeitig erhöht 30 ms die „Kosten“ eines Drop- oder Delay-Ereignisses. Ein gutes Design berücksichtigt daher beide Effekte: LLQ-Limitierung und Queue-Limits müssen zu ptime passen.
- LLQ-Limit: muss den realen Pro-Call-Bedarf inklusive Overhead abdecken; ptime verändert diesen Bedarf.
- Queue-Delay: bei hoher Paketrate können kurze Bursts schneller zu Delay-Spitzen führen.
- Starvation-Risiko: zu große LLQ oder Fehlmarking bleibt unabhängig von ptime gefährlich.
Mikrobursts: Warum ptime die „Spikiness“ der Echtzeitklasse beeinflusst
Mikrobursts entstehen, wenn viele Flows kurzzeitig gleichzeitig senden. VoIP wirkt zwar gleichmäßig, aber in aggregierten Szenarien (viele Endpunkte, viele Calls) können Bündelungen entstehen – etwa bei gleichzeitigen Talkspurts oder bei Taktung durch Endgeräte. Mit 20 ms entstehen häufiger Pakete; das kann Bursts „feiner“ verteilen, aber auch die Wahrscheinlichkeit erhöhen, dass in einem sehr kurzen Zeitfenster viele Pakete ankommen. Mit 30 ms sind Pakete seltener, dafür können sie in größeren Wellen auftreten, je nach Synchronisation der Endpunkte. Deshalb ist ptime in großen Netzen kein rein lokaler Parameter, sondern beeinflusst das Aggregationsverhalten.
- Synchronisationseffekte: viele Clients mit gleicher ptime können Traffic-Wellen erzeugen.
- Shaping als Gegenmaßnahme: glättet Bursts und hält die Queue im eigenen Einflussbereich.
- HQoS: per-Subscriber/Service Hierarchie reduziert Noisy-Neighbor Effekte in Shared Access.
Interaktivitätsbudget: ptime beeinflusst „gefühlte“ Reaktionsfähigkeit
Für Voice zählt Interaktivität. Neben der Netzlatenz fließt auch die algorithmische Verzögerung ein: Codec-Frames müssen gesammelt, kodiert, übertragen, gepuffert und dekodiert werden. Eine größere ptime erhöht typischerweise den Zeitabschnitt, der gesammelt werden muss, bevor ein Paket gesendet werden kann. Das kann die End-to-End Latenz erhöhen, insbesondere wenn zusätzlich große Jitter-Buffer genutzt werden. In engen Latenzbudgets ist das relevant: 10 ms zusätzliche algorithmische Komponente können den Unterschied machen, ob ein Dienst „snappy“ wirkt oder ob Over-Talking zunimmt.
- 20 ms: oft ein guter Kompromiss aus Overhead und Interaktivität.
- 30 ms: spart Overhead, kann aber mehr Verzögerung und stärkere Drop-Auswirkung bringen.
- Echo/Double-Talk: höhere End-to-End Latenz kann Echo-Management stärker belasten.
Codec-spezifische Betrachtung: Warum ptime je nach Codec anders wirkt
ptime ist nicht losgelöst vom Codec. Bei G.711 ist die Payload pro Zeitfenster größer als bei stark komprimierten Codecs. Deshalb ist der relative Vorteil von Overhead-Reduktion bei G.711 geringer als bei sehr niedrigen Bitraten. Bei G.729 oder ähnlichen komprimierten Codecs ist der Header-Anteil besonders dominant; hier kann 30 ms deutlich mehr Leitungslast sparen. Bei Opus wird es komplexer, weil Opus adaptiv sein kann und je nach Konfiguration mit Redundanz/FEC arbeitet. In solchen Fällen muss ptime zusammen mit Bitratenprofilen betrachtet werden, nicht als isolierter Wert.
- G.711: Overhead relevant, aber Payload groß; ptime-Wechsel wirkt moderater.
- G.729: Overhead sehr dominant; 30 ms kann spürbar mehr Calls pro Link ermöglichen.
- Opus: abhängig von Bitrate/FEC; ptime muss mit realen Profilen gemessen und budgetiert werden.
QoS-Policies und ptime: Praktische Regeln für LLQ-Budgets und Policer
In professionellen Netzen wird die Voice-Media-Klasse meist strikt priorisiert und gleichzeitig limitiert. Genau hier entscheidet ptime über die richtige Dimensionierung. Wenn Sie ptime erhöhen, sinkt oft die effektive Leitungslast pro Call (wegen weniger Overhead), aber die Qualität kann bei Drops schneller kippen. Wenn Sie ptime reduzieren, steigt die Leitungslast pro Call, dafür sind einzelne Loss-Ereignisse weniger „teuer“. Deshalb sollte ptime eine definierte, dokumentierte Serviceentscheidung sein – und QoS-Policies müssen darauf abgestimmt werden.
- LLQ-Limitierung: anhand Pro-Call-Modell (inkl. Overhead) und Busy-Hour dimensionieren.
- Policing vermeiden: harte Drops in Echtzeit sind sofort hörbar; lieber Shaping und klare Budgets.
- Remarking an Trust Boundaries: schützt LLQ vor Missmarking, unabhängig von ptime.
- Queue-Limits: klein genug gegen Bufferbloat, groß genug gegen Mikrobursts – ptime beeinflusst die Feinabstimmung.
Monitoring: Wie Sie ptime-Effekte sichtbar machen
ptime-Probleme bleiben oft unsichtbar, wenn nur Durchschnittswerte betrachtet werden. Sie brauchen kurze Zeitfenster und Perzentile: Queue-Delay in der Voice-Klasse, Queue-Drops, RTP-Loss/Jitter aus RTCP oder Session-Statistiken sowie Call-Setup/Teardown-Metriken zur Abgrenzung von Signaling-Problemen. Besonders nützlich ist die Segmentierung: Vergleichen Sie Qualitätsmetriken nach ptime (20 ms vs. 30 ms), wenn die Plattform das liefert. So sehen Sie, ob ein ptime-Change tatsächlich Overhead spart, aber gleichzeitig die Loss-Sensitivität erhöht.
- Queue-Delay: Frühindikator für Jitter und bevorstehende Drops.
- Queue-Drops: direkte Ursache für hörbare Aussetzer; nach Klasse und Richtung trennen.
- RTP-Loss/Jitter: sessionnah messen, idealerweise in kurzen Intervallen.
- Perzentile: p95/p99 statt Mittelwert, damit Mikrobursts sichtbar werden.
Typische Failure Patterns bei falscher ptime-Wahl
Fehlentscheidungen bei ptime zeigen sich oft nicht sofort, sondern unter Last oder in Randdomänen (WLAN, VPN, Interconnect). Typisch ist ein Netz, das „meistens“ gut funktioniert, aber in Busy Hour oder bei Failover plötzlich hörbar schlechter wird. Häufige Ursachen sind zu knapp dimensionierte Echtzeitbudgets, fehlendes Shaping am WAN-Edge, Mikroburst-Drops oder Jitter-Buffer-Konflikte durch zu hohe Gesamtlatenz.
- Mehr Aussetzer nach Umstellung auf 30 ms: einzelne Drops wirken stärker; burstiger Loss wird sichtbar.
- LLQ-Drops nach Umstellung auf 20 ms: Overhead steigt, LLQ-Budget war zu knapp dimensioniert.
- Probleme nur im WLAN: Retries/Jitter; 20 ms kann toleranter sein, aber WLAN-Design ist meist der Hebel.
- Probleme nur im VPN/Overlay: MTU/DSCP-Copy; ptime ändert Symptome, nicht die Ursache.
Blueprint: So entscheiden Telcos und Enterprises sauber zwischen 20 ms und 30 ms
Ein belastbarer Entscheidungsprozess beginnt mit der Definition des Serviceziels: Interaktivität, erwartete Loss/Jitter-Umgebung und Kapazitätsgrenzen. Danach wird ein Bandbreitenmodell pro Codec mit beiden ptime-Varianten erstellt, inklusive Overhead der realen Transportumgebung (VLAN/MPLS/VPN). Im nächsten Schritt werden LLQ-Budgets und Shaper so dimensioniert, dass Congestion kontrollierbar bleibt. Anschließend erfolgt eine Validierung unter Last: nicht nur im Mittelwert, sondern mit p95/p99 für Queue-Delay und RTP-Loss/Jitter. Daraus ergibt sich eine klare Regel: In sehr knappen Links kann 30 ms sinnvoll sein, wenn das Netz stabil und lossarm ist; in jitter-/lossanfälligen Umgebungen ist 20 ms oft der robustere Standard. Entscheidend ist, dass ptime standardisiert, dokumentiert und mit QoS-Policies sowie Monitoring verknüpft wird, sodass QoS nicht „zufällig“, sondern reproduzierbar funktioniert.