SIP Signaling vs. Media im QoS-Kontext sauber zu trennen, ist eine der wirkungsvollsten Maßnahmen, um VoIP-Dienste stabil, skalierbar und SLA-fähig zu betreiben. Viele Qualitätsprobleme entstehen nicht, weil „RTP nicht priorisiert ist“, sondern weil Signalisierung und Medienverkehr in falschen Klassen landen, Markierungen inkonsistent sind oder eine strikt priorisierte Queue durch falsch klassifizierten Traffic überläuft. SIP ist für Rufaufbau, Rufabbau, Registrierungen und Session-Steuerung zuständig – es ist bursty, kleinvolumig, aber zeitkritisch. Media Traffic (RTP/SRTP) ist kontinuierlich, extrem jitter- und loss-sensitiv und reagiert sofort auf Warteschlangen und Drops. Genau deshalb braucht es getrennte QoS Klassen: Medienverkehr muss so behandelt werden, dass Latenz- und Jitterspitzen minimiert werden, während SIP Signaling zuverlässig und bevorzugt transportiert wird, ohne die Echtzeitklasse zu belasten. Ein Provider- oder Enterprise-taugliches Design definiert hierfür klare Traffic Classes, Trust Boundaries und Messkriterien, sodass sowohl Rufaufbau als auch Gesprächsqualität unter Last kontrollierbar bleiben.
Warum SIP und RTP unterschiedliche Profile haben
SIP und RTP lösen unterschiedliche Aufgaben und erzeugen dadurch völlig unterschiedliche Lastmuster. SIP besteht aus vergleichsweise wenigen Nachrichten pro Ruf (INVITE, 180 Ringing, 200 OK, ACK, BYE) sowie regelmäßigen Registrierungen und Keepalives. Der Verkehr ist bursty: kurze Spitzen, dann wieder Ruhe. RTP hingegen sendet kontinuierlich Pakete, oft in festen Intervallen (z. B. alle 20 ms bei Voice), und ist damit ein stetiger Echtzeitstrom. QoS muss diese Unterschiede abbilden, sonst leidet entweder die Signalisierung (Rufaufbauprobleme) oder die Medienqualität (Audio-/Videoartefakte).
- SIP Signaling: klein, bursty, aber zeitkritisch für Setup/Teardown; Verlust führt zu Retransmits und Timeouts.
- RTP/SRTP Media: kontinuierlich, timingkritisch; Verlust und Jitter wirken sofort hörbar/ sichtbar.
- RTCP: klein, aber wichtig für Qualitätsfeedback und Diagnose; sollte nicht im Bulk verschwinden.
Typische Symptome, wenn QoS Klassen nicht getrennt sind
Wenn SIP und Media in derselben QoS-Klasse landen oder wenn Signalisierung im Best Effort „untergeht“, zeigen sich wiederkehrende Failure Patterns. Diese Muster sind in Telco- und Enterprise-Netzen besonders häufig, weil Congestion oft nur punktuell auftritt (Busy Hour, Mikrobursts, Failover) und dadurch Probleme „sporadisch“ wirken. Eine saubere Trennung der Klassen reduziert diese Effekte drastisch.
- Rufaufbau dauert lange: SIP-Nachrichten werden verzögert oder gedroppt; Retransmits erhöhen Last zusätzlich.
- Ruf bricht beim Aufbau ab: SIP-Timeouts, fehlende Responses, instabile Registrierungen.
- Audio gut, aber Setup instabil: RTP priorisiert, SIP nicht; der Call kommt nicht zuverlässig zustande.
- Audio bricht sporadisch: Media landet in Best Effort oder konkurriert mit Bulk-Traffic; Jitter steigt.
- Priority-Queue läuft über: SIP oder sogar Best Effort wird fälschlich als Media klassifiziert und flutet LLQ.
Das Zielbild: Schlankes Klassenmodell mit klarer Rollenverteilung
Eine praxistaugliche QoS-Architektur hält die Anzahl der Klassen bewusst klein, trennt aber die entscheidenden Profile: Media (Voice), Media (Video) und Signalisierung. Zusätzlich wird Network Control geschützt, damit Routing und OAM auch unter Last stabil bleiben. In Provider-Netzen ist ein solches Modell besonders wichtig, weil es über Plattformen, Regionen und Vendoren konsistent umgesetzt werden muss.
Minimalmodell für VoIP (robust und leicht operierbar)
- Network Control: Routing/OAM/Management – höchste Schutzpriorität für Stabilität.
- Voice Media (RTP/SRTP): Low-Latency Queue (LLQ), strikt priorisiert, aber limitiert.
- Voice Signaling (SIP/RTCP): bevorzugte, gewichtete Klasse; keine strikte Priorität nötig.
- Best Effort: Standardverkehr.
- Bulk/Scavenger: Backups/Updates – bewusst nachrangig.
Erweitertes Modell, wenn UC/Video relevant ist
- Real-Time Video (interaktiv): gewichtete Echtzeitklasse mit Mindestbandbreite, nicht in die Voice-LLQ.
- Business Critical Data: bevorzugte Datenklasse für produktive Anwendungen.
- Streaming/Assured: optional für IPTV/Streaming oder definierte Durchsatzprofile.
Warum SIP nicht in die LLQ gehört
Es klingt zunächst plausibel, SIP „auch ganz nach oben“ zu legen. In der Praxis ist das selten nötig und kann sogar schaden. Die LLQ ist für sehr kleine, zeitkritische Medienpakete gedacht, die kontinuierlich kommen. SIP ist bursty, kann in Sonderfällen (z. B. Mass-Registrierungen, Re-INVITEs bei Failover, SBC-Events) größere Spitzen erzeugen und würde dann die LLQ unnötig belasten. Besser ist eine bevorzugte, gewichtete Klasse: SIP bekommt Schutz vor Congestion, ohne die strikte Echtzeitklasse zu „verwässern“.
- LLQ knapp halten: Voice profitiert von minimaler Queueing-Latenz; die Klasse darf nicht wachsen.
- SIP ist bursty: Peaks können die LLQ überproportional füllen, obwohl SIP selbst wenig Bandbreite braucht.
- Gewichtete Priorisierung: SIP erhält garantierte Ressourcen, ohne andere Klassen zu verdrängen.
Marking-Strategie: DSCP für Signaling und Media konsistent definieren
Die Trennung von Klassen beginnt bei der Markierung. In IP-Netzen wird dafür üblicherweise DSCP genutzt. Entscheidend ist die Konsistenz: Endgeräte, SBCs, CEs, PEs und Firewalls müssen dieselben Marking-Regeln verstehen, und an Übergängen müssen DSCP↔PCP↔MPLS-TC-Mappings stimmen. Gleichzeitig braucht es Trust Boundaries: In Provider-Netzen kann kundenseitige Markierung nicht blind vertraut werden. Ein auditierbares Design arbeitet mit Allowlists und Remarking.
- Definierte DSCP-Werte: separate Markings für Media und Signaling, dokumentiert und netzweit gleich.
- Trust Boundary: Marking nur dort akzeptieren, wo Identität und Policy klar sind.
- Remarking: falsche/unerlaubte Markings normalisieren, um Premium-Queues zu schützen.
- Mapping-Konsistenz: DSCP↔PCP↔MPLS-TC (und ggf. WMM) ohne Lücken.
Klassifizierung: Wie Signaling und Media zuverlässig erkannt werden
In kontrollierten Umgebungen ist Marking die beste Grundlage: effizient und skalierbar. In gemischten Umgebungen kann eine zusätzliche Klassifizierung nach Servicekontext sinnvoll sein, etwa per VLAN/VRF, per Subscriber-Policy oder über SBC/Access-Profile. Reine Port-Heuristiken sind weniger robust, weil SIP je nach Deployment über TCP/UDP und unterschiedliche Ports laufen kann, und RTP-Ports dynamisch sind. Entscheidend ist, dass Klassifizierung im Betrieb stabil bleibt – auch bei Verschlüsselung (SRTP) und bei NAT/SBC-Szenarien.
- Primär: Marking: DSCP als skalierbarer Indikator, wenn Trust sauber geregelt ist.
- Ergänzend: Servicekontext: VRF/VLAN/Subscriber-Profile, um Kundenprofile sauber durchzusetzen.
- Port/Signatur nur ergänzend: dynamische Ports und Verschlüsselung reduzieren Zuverlässigkeit.
Queueing & Scheduling: So wird die Trennung wirksam
QoS wirkt nur bei Congestion. Deshalb muss die Trennung der Klassen dort sichtbar werden, wo Warteschlangen entstehen: am WAN-Uplink, in der Aggregation, am Provider-Edge, an VPN-Tunnels oder an Interconnects. Für Voice-Media ist LLQ sinnvoll, aber strikt begrenzt. Für Signaling ist eine bevorzugte Queue mit garantierter Mindestbandbreite und geringen Queue-Limits sinnvoll, damit SIP-Nachrichten nicht in langen Best-Effort-Queues verhungern. Video gehört in der Regel in eine gewichtete Echtzeitklasse, weil es schnell skaliert.
- Voice Media: LLQ, geringe Queue-Limits, harte Obergrenze für Bandbreite.
- SIP/RTCP: bevorzugte Queue, kleine, aber garantierte Bandbreite, ebenfalls geringe Queue-Limits.
- Video: gewichtete Echtzeitklasse mit Mindestbandbreite, optional class-based shaping.
- Best Effort/Bulk: AQM/WRED/ECN nach Bedarf, damit TCP-Verkehr nicht alles „aufbläht“.
Shaping und Policing: Profile durchsetzen, ohne Media zu zerstören
Die meisten VoIP-Probleme entstehen an Engpässen, die nicht kontrolliert sind. Shaping am WAN-Edge knapp unter der Provider-Rate ist ein bewährtes Muster, weil es die Queue in den eigenen Einflussbereich bringt. Policing ist dagegen für Echtzeit heikel, weil harte Drops sofort hörbar werden. Im Governance-Sinn ist Policing dennoch wichtig, um Missbrauch zu verhindern – dann aber vorzugsweise an Trust Boundaries und mit Remarking-Strategien, sodass Überschreitungen degradiert statt gedroppt werden, wenn das Serviceprofil es erlaubt.
- Egress Shaping: stabilisiert Queueing, reduziert Drop-Bursts und Jitter.
- Per-Class Budgets: Voice klein, aber ausreichend; Signaling minimal, aber garantiert; Video kontrolliert.
- Policing an Trust Boundaries: schützt Premium-Klassen vor Fehlmarking.
- Remarking statt Drop: Überschreitungen in niedrigere Klasse ummarkieren, wo sinnvoll.
Messbarkeit: Wie Sie die Trennung nachweisen und im Betrieb überwachen
Eine saubere Klassentrennung muss sichtbar sein. Im Betrieb sind dafür drei Perspektiven wichtig: erstens die Verteilung der Markings (werden SIP und RTP wirklich getrennt markiert?), zweitens die Queue-Telemetrie (Drops und Queue-Delay pro Klasse) und drittens sessionnahe Metriken (SIP Setup Times, Retransmits, RTP Jitter/Loss). Besonders wertvoll ist die Korrelation: Wenn SIP-Setup-Zeiten steigen, sollte erkennbar sein, ob die Signaling-Queue Delay/Drops zeigt oder ob das Problem außerhalb der eigenen Domäne liegt.
- Marking-Distribution: DSCP-Verteilung pro Interface, Ausreißer und Missmarking erkennen.
- Queue KPIs: Queue-Delay und Queue-Drops pro Klasse, insbesondere für Voice und Signaling.
- SIP KPIs: Setup-Time, Retransmits, Registration Success Rate, Timeout-Events.
- RTP KPIs: Loss/Jitter, ggf. MOS/R-Faktor-Schätzungen aus RTCP/SBC.
Typische Fehler bei der Klassentrennung und wie man sie vermeidet
Auch bei guter Absicht führen kleine Designfehler zu großen Auswirkungen. Häufig sind es inkonsistente DSCP-Mappings, fehlende Trust Boundaries oder die falsche Platzierung von QoS (nur im Core, obwohl Congestion im Access sitzt). Ebenso kritisch: SIP wird in Best Effort belassen und leidet unter Last, oder SIP wird in die LLQ gepackt und verursacht dort unnötige Spitzen. Ein robustes Design adressiert diese Punkte systematisch.
- SIP im Best Effort: Setup-Probleme unter Last; Signaling-Klasse fehlt.
- SIP in der LLQ: unnötige Belastung der Echtzeitklasse, besonders bei Burst-Events.
- Unlimitierte LLQ: Fehlmarking flutet Echtzeitqueues; Limits und Allowlists fehlen.
- Marking geht verloren: Tunnel/Firewall/Provider-Übergänge löschen DSCP; Mapping/Copy prüfen.
- QoS am falschen Ort: Engpass sitzt am WAN-Edge oder WLAN; dort fehlt Shaping/Queueing.
Blueprint: SIP Signaling und Media end-to-end sauber trennen
Ein praxiserprobtes Vorgehen beginnt mit einem schlanken Klassenmodell und verbindlichen Markings: separate Klassen für Voice-Media und Signaling, optional Video als eigene Echtzeitklasse. Danach werden Trust Boundaries definiert und durch Allowlists sowie Remarking abgesichert. Anschließend wird Queueing an den realen Congestion Points implementiert: LLQ für Voice-Media mit striktem Limit, bevorzugte gewichtete Queue für SIP/RTCP, gewichtete Queue für Video. Shaping am WAN-Edge stellt sicher, dass die Queue kontrollierbar bleibt. Abschließend werden Monitoring und Audits aufgebaut, die Markings, Queue-Drops/Delay sowie SIP- und RTP-KPIs korrelieren. So entsteht eine robuste Trennung: Media bleibt zeitstabil, Signalisierung bleibt zuverlässig, und das Gesamtsystem bleibt auch bei Last und in Failover-Szenarien beherrschbar.
