RTP (Real-time Transport Protocol)

RTP ist das Transportprotokoll für Ton und Bild in Echtzeit. Es zerlegt einen laufenden Medienstrom in einzelne Pakete und schreibt jedem Paket vier Angaben in den Kopf: eine laufende Nummer, den Aufnahmezeitpunkt, eine Kennung der Quelle und die Angabe, welches Format im Paket steckt. Mehr macht es nicht — und genau darin liegt seine Rolle.

Denn RTP verspricht nichts. Es reserviert keine Bandbreite, fordert verlorene Pakete nicht nach und stellt keine Reihenfolge sicher; das steht wörtlich im Standard, den Henning Schulzrinne an der Columbia University in New York zusammen mit Stephen Casner, Ron Frederick und Van Jacobson verfasst hat und der 2003 in seiner heutigen Fassung erschienen ist. Die Echtzeiteigenschaft entsteht an zwei anderen Stellen: im Netz darunter, das den Strom rechtzeitig durchlässt, und im Empfangspuffer darüber, der die verbliebenen Schwankungen ausgleicht. RTP liefert nur die Information, mit der beides überhaupt möglich wird.

Was in jedem Paket steht

Der feste Kopf eines RTP-Pakets ist zwölf Byte lang und in jedem Paket vorhanden. Vier seiner Felder entscheiden über alles, was danach möglich ist.

Die Sequenznummer ist 16 Bit breit und zählt Paket für Paket hoch. Der Empfänger stellt damit die Reihenfolge wieder her und erkennt Verluste: Fehlt eine Nummer, ist ein Paket weg. Der Startwert wird zufällig gewählt, das Zählen beginnt also nicht bei null.

Der Zeitstempel ist 32 Bit breit und nennt den Abtastzeitpunkt des ersten Bytes im Paket. Er kommt aus einem Takt, der monoton und linear läuft, und seine Frequenz hängt vom übertragenen Format ab — bei Ton mit 48 kHz zählt er in aller Regel je Abtastwert um eins weiter. Er misst also den Zeitpunkt, zu dem der Inhalt entstanden ist, und nicht den, zu dem das Paket losgeschickt wurde. Aus dem Abstand zwischen erwarteter und tatsächlicher Ankunft berechnet der Empfänger die Ankunftsschwankung, und aus dem Zeitstempel selbst bildet er den Takt der Quelle nach.

Der Payload Type ist sieben Bit breit und sagt, welches Format im Paket steckt. Ein Teil der Nummern ist fest vergeben — 0 für G.711 µ-Law, 8 für G.711 A-Law, 10 und 11 für lineares Audio mit 16 Bit und 44,1 kHz. Der Bereich 96 bis 127 ist ausschließlich für dynamische Vergabe reserviert, und dort landet in der Praxis fast alles, was in einer Anlage interessiert: Lineares Audio mit 24 Bit etwa bekommt seine Nummer immer aus diesem Bereich zugewiesen; eine feste hat es nicht. Welche Nummer welches Format meint, muss der Empfänger deshalb vorher erfahren haben; im Strom selbst steht es nicht.

Die SSRC schließlich ist eine 32 Bit breite Zufallskennung der Quelle. Sie unterscheidet mehrere Ströme, die auf demselben Weg ankommen. Zufällig gewählte Kennungen können kollidieren, und jede Implementierung muss das erkennen und auflösen.

Warum RTP auf UDP aufsetzt und nicht auf TCP

Die übliche Grundlage ist UDP. Das ist eine bewusste Entscheidung gegen Zuverlässigkeit, und sie ist der Kern des ganzen Entwurfs.

TCP wiederholt verlorene Pakete so lange, bis sie ankommen, und hält alles Nachfolgende so lange zurück. Für eine Datei ist das richtig. Für laufenden Ton ist es unbrauchbar: Ein Paket, das eine Zehntelsekunde später eintrifft, hätte längst gespielt werden müssen. Die Wiederholung repariert nichts, sie verschiebt nur die Lücke und macht sie größer. Ein einzelnes fehlendes Paket ist bei 1 ms Paketinhalt eine Millisekunde Ton. Ob das hörbar wird, entscheidet allein der Empfänger mit dem, was er in die Lücke setzt — der Standard regelt es nicht.

Dazu kommt der zweite Grund: UDP kann Multicast. Ein Sender schickt seinen Strom einmal los, und alle angemeldeten Empfänger bekommen ihn — die Voraussetzung dafür, dass eine Zone mehr im Haus keine zusätzliche Last auf der Leitung bedeutet. Was das vom Netz verlangt, steht bei Multicast und IGMP.

RTCP: der Rückkanal, den kaum jemand kennt

Zu RTP gehört ein zweites Protokoll, das im selben Standard beschrieben ist: RTCP. Es überträgt Berichte statt Medien: Sender und Empfänger melden einander regelmäßig, wie der Strom ankommt. Fünf Pakettypen gibt es: Sender Report, Receiver Report, Quellenbeschreibung, Abmeldung und ein anwendungseigener Typ. Als Bandbreite empfiehlt der Standard 5 % der Sitzungsbandbreite; RTCP ist also billig genug, um mitzulaufen, ohne dass es jemand plant.

Der Sender Report enthält eine Angabe, die in einer Anlage mit Bild und Ton den Unterschied macht: einen Zeitpunkt der Wanduhr und den zugehörigen RTP-Zeitstempel derselben Quelle, beide für denselben Moment. Erst damit lassen sich zwei Ströme derselben Quelle — Bild und Ton — aufeinander beziehen. Der Standard nennt die Bedingung dafür ausdrücklich: Die Uhren der beteiligten Quellen müssen synchronisiert sein. Genau das ist die Aufgabe von PTP im Netzwerk-Audiosystem, und deshalb hängen die beiden Themen zusammen.

Für die Fehlersuche ist RTCP der erste Ort, an dem etwas Messbares steht: Paketverlust und Ankunftsschwankung berichtet der Empfänger von sich aus, und Geräte machen diese Zahlen häufig in ihrer Weboberfläche sichtbar.

Die Paketzeit ist die eigentliche Stellschraube

RTP schreibt nicht vor, wie viel Ton in ein Paket gehört. Das legt das Profil fest, und dort entscheidet sich das Verhalten der ganzen Anlage. Das Grundprofil für Konferenzanwendungen sieht 20 ms je Paket vor; AES67 verlangt für Netzwerk-Audio 1 ms als Pflichtwert und erlaubt Verkürzungen bis auf 125 µs.

Die Rechnung dahinter ist einfach und lohnt sich, weil sie beide Richtungen zeigt. Auf jedes Paket kommen 40 Byte Kopf — zwölf für RTP, acht für UDP, zwanzig für IP. Bei acht Kanälen, 48 kHz und 24 Bit enthält ein 1-ms-Paket 1.152 Byte Nutzdaten; der Kopf macht dann rund 3 % aus, und es laufen 1.000 Pakete je Sekunde und Strom über das Netz. Verkürzt man auf 125 µs, sinkt die Verzögerung auf ein Achtel — aber die Nutzdaten schrumpfen auf 144 Byte, der Kopfanteil steigt auf über 20 %, und die Paketrate steigt auf 8.000 je Sekunde und Strom.

Der zweite Wert ist der wichtigere: Nicht die Bandbreite bringt Switches an ihre Grenze, sondern die Zahl der Pakete, die sie in der Sekunde verarbeiten. Eine kurze Paketzeit stellt damit zugleich eine Anforderung an die Hardware.

Häufiges Missverständnis

„RTP sorgt für Echtzeit." Der Name legt es nahe, und der Standard widerspricht in seinen ersten Absätzen. RTP sichert weder rechtzeitige Zustellung noch Dienstgüte zu; es verlässt sich dafür ausdrücklich auf die Schichten darunter. Wer Aussetzer im Netzwerk-Audio dem Protokoll anlastet, sucht an der falschen Stelle. Die Ursachen liegen in der Auslastung der Leitungen, in fehlender Priorisierung (QoS) oder in einem zu knapp bemessenen Empfangspuffer.

„Das ist doch dasselbe wie Streaming aus dem Netz." Beides überträgt Medien über IP, und beides wird umgangssprachlich Streaming genannt. Der Entwurf zielt aber in die entgegengesetzte Richtung. Ein Videodienst puffert einige Sekunden im Voraus und holt fehlende Daten zuverlässig nach; er darf verzögern, aber nicht stocken. Ein RTP-Strom in einer Anlage puffert Millisekunden und verzichtet auf das Nachholen; er darf im Extremfall eine Lücke haben, aber nicht zu spät kommen. Deshalb funktioniert die eine Technik über eine schlechte Internetleitung und die andere nicht.

„Wenn der Strom ankommt, stimmt auch das Format." Ein RTP-Paket enthält nur eine Formatnummer, und bei den interessanten Formaten ist diese Nummer dynamisch vergeben. Was 96 oder 100 bedeutet, steht in der Sitzungsbeschreibung, die der Empfänger vorher bekommen haben muss — über eine Ankündigung im Netz, über eine Steuerverbindung oder über die Konfiguration im Gerät. Ein Empfänger, der Pakete empfängt und trotzdem stumm bleibt, hat oft genau hier sein Problem und nicht auf der Leitung.

Nicht zu verwechseln mit

• RTCP: derselbe Standard, aber der Rückkanal. Berichte über den Strom, keine Medien. Läuft üblicherweise auf der nächsthöheren Portnummer — RTP auf einer geraden, RTCP auf der ungeraden darüber.
• RTSP: die Steuerung. Das Protokoll beschreibt sich selbst als Fernbedienung für Medienserver — starten, anhalten, springen — und überträgt die Daten ausdrücklich außerhalb des eigenen Wegs, meist über RTP. Bei IP-Kameras stehen beide nebeneinander, und die Verwechslung entsteht, weil in der Adresse rtsp:// steht.
• SDP und SAP: die Sitzungsbeschreibung und ihre Ankündigung im Netz. Sie sagen, was ein Strom enthält und welche Formatnummer was bedeutet. RTP selbst sagt es nicht.
• HLS und DASH: gepufferte Verfahren für Mediatheken und Musikdienste. Andere Aufgabe, anderes Verhalten. Was in dieser Welt gilt, steht bei den Zuspielprotokollen.
• PTP: der gemeinsame Takt aller Geräte. Der RTP-Zeitstempel zählt Abtastwerte einer Quelle; PTP stellt die Uhren. Ohne PTP bleibt der Zeitstempel ein Wert ohne gemeinsame Bezugsgröße.

In der Planung

Ein Haus mit Netzwerk-Audio in sieben Zonen, einer Türsprechstelle über SIP und zwei Kameras. Der Elektriker fragt, welche Bandbreite er einplanen muss.

Die Bandbreite ist die einfachste der drei Fragen und die am wenigsten entscheidende. Wichtiger ist zuerst die Konzeptfrage: Welche Verzögerung darf die Anlage haben? Ton, der zum Bild passen muss, und Ton, der in zwei benachbarten Räumen gleichzeitig hörbar ist, setzen enge Grenzen; Hintergrundmusik in getrennten Zonen setzt fast keine.

Zwei Größen bleiben — die Paketzeit und die Größe des Empfangspuffers. Beide zusammen bestimmen die Verzögerung, und beide kosten etwas: Die kurze Paketzeit kostet Paketrate im Switch, der kleine Puffer kostet Sicherheit gegen Schwankungen. Ein Puffer, der auf ein ruhiges Netz ausgelegt ist, fällt in dem Moment auf, in dem jemand eine große Datei über dieselbe Leitung kopiert.

Die Geräteauswahl steht am Schluss dieser Kette, und drei Fragen klären sie: Lässt sich die Paketzeit einstellen? Zeigt das Gerät Paketverlust und Ankunftsschwankung aus den RTCP-Berichten an? Und verarbeitet der Switch die Paketrate, die aus der gewählten Paketzeit folgt, auf allen Ports gleichzeitig? Ein Switch, der bei acht Strömen mit kurzer Paketzeit einbricht, hat kein Bandbreitenproblem.

Verknüpfte Inhalte

Wie ein Strom im ausgelasteten Netz Vorrang bekommt, klärt QoS, DSCP und 802.1p; warum der AV-Verkehr ein eigenes Segment bekommt, VLAN und Subnetz. Die Ankunftsschwankung und ihre Folgen behandelt Jitter und Taktrückgewinnung, die Summe aller Verzögerungen die Latenz der Audiokette. Wie eine Anlage insgesamt aufgebaut ist, steht auf Audio over IP und AV over IP; die beiden verbreiteten Ausprägungen sind AES67 und Dante.

Quellen

Aufbau des Kopfes, Feldbreiten, die Bedeutung von Sequenznummer, Zeitstempel, Payload Type und SSRC sowie die Feststellung, dass RTP keine Zustellung und keine Dienstgüte zusichert, stehen in RFC 3550 von 2003; ebenso die fünf RTCP-Pakettypen, die Empfehlung von 5 % Bandbreite für RTCP, die Zeitangaben im Sender Report und die Portregel. Die festen und dynamischen Nummern des Payload Type sowie die 20 ms des Grundprofils stehen in RFC 3551, die Behandlung von linearem Audio mit 24 Bit über eine dynamisch vergebene Nummer in RFC 3190. Die Abgrenzung gegen RTSP folgt RFC 2326, einschließlich der Selbstbeschreibung als Fernbedienung für Medienserver. Alle vier wurden für diese Seite abgerufen.

Die Rechnung zum Kopfanteil und zur Paketrate ist aus den Feldbreiten der Protokollköpfe abgeleitet und keine Messung.