Zusammenfassung

  • Die RTP-Sequenznummer beschreibt die Reihenfolge gesendeter Pakete. Der Zeitstempel bezeichnet eine Position auf der formatabhängigen Abtast- oder Präsentationsuhr. Keines der Felder belegt die absolute Sendezeit.
  • Für die Abstimmung mehrerer Ströme koppelt ein RTCP-Senderbericht gelegentlich einen RTP-Zähler an einen Referenzwert im NTP-Format. Erst diese Abbildung liefert Evidenz für gemeinsame Zeit.

RFC 3550 definiert den 32-Bit-Zeitstempel als Abtastzeitpunkt des ersten Oktetts im RTP-Paket. Bei periodisch erzeugten Medien soll er aus der nominellen Abtastuhr stammen, nicht aus einer Abfrage der Systemuhr im Moment der Übertragung. Der Feldname klingt nach Datum; seine tatsächliche Aufgabe ist Medienposition.

RTP ist das gemeinsame Werk von Henning Schulzrinne, Stephen Casner, Ron Frederick und Van Jacobson. RFC 1889 veröffentlichte die Spezifikation 1996, RFC 3550 löste sie 2003 ab. Das USC Information Sciences Institute schreibt Casner die Leitung von Entwicklung und Standardisierung zu. Dieses Profil folgt seiner Rolle, ohne den Standard als Einzelerfindung umzudeuten.

Zwei Zähler, zwei Aussagen

Die 16-Bit-Sequenznummer steigt mit jedem gesendeten Datenpaket um eins. Empfänger können Lücken erkennen und die Sendereihenfolge wiederherstellen. Ihr Startwert ist zufällig. Sie ist also kein globaler Vorgangszähler, sondern eine Position im Paketstrom einer Quelle.

Der Zeitstempel bewegt sich auf einer anderen Achse. Seine Frequenz hängt vom Nutzlastformat ab. Liest eine Audioanwendung einen Block mit 160 Abtastperioden, steigt der Zähler um 160. Das gilt auch, wenn der Block wegen Stille nicht gesendet wird. Die Medienzeit umfasst den stillen Abschnitt, obwohl kein Paket dafür unterwegs ist.

Video zeigt den umgekehrten Eindruck. Ein Bild kann auf mehrere Pakete verteilt werden. Deren Sequenznummern unterscheiden sich, ihre Zeitstempel dürfen gleich sein. Manche Kodierungen übertragen Bilddaten zudem in einer anderen Reihenfolge, als sie abgetastet wurden. Die Paketnummern bleiben monoton, während aufeinanderfolgende Zeitstempel es nicht sein müssen.

Ein doppelter Zeitstempel beweist daher kein doppeltes Paket. Ein rückläufiger Wert beweist keine Umordnung im Netz. Beides kann korrekt aus Medienrahmung und Kodierreihenfolge folgen. Erst wenn ein Messsystem Sendefolge und Medienposition vermischt, erscheint richtiges Verhalten als Störung.

Auch der erste Zeitstempel ist zufällig. Zur Umrechnung einer Differenz in Sekunden braucht man die Taktrate. Zur Zuordnung braucht man die SSRC. Zum Vergleich mit einer anderen Quelle braucht man eine Abbildung auf eine gemeinsame Referenz. Ein nackter Integer trägt keinen dieser Kontexte in sich.

Gleiche Szene, inkompatible Zahlen

Mikrofon und Kamera können denselben physischen Moment erfassen und völlig unterschiedliche RTP-Werte erzeugen. Ihre Taktraten weichen voneinander ab, ebenso die unabhängigen Zufalls-Offsets. RFC 3550 warnt deshalb ausdrücklich vor dem direkten Vergleich von Zeitstempeln verschiedener Medienströme.

Diese Grenze hält den Datenpfad schlank. Innerhalb eines Stroms genügt die Medienuhr, um Präsentation zu ordnen und Ankunftsschwankungen gegen den Abtastrhythmus zu messen. Nicht jedes Paket benötigt ein absolutes Datum, und eine RTP-Implementierung muss nicht zwingend NTP betreiben.

Für den Übergang zu gemeinsamer Zeit gibt es RTCP. Ein Senderbericht enthält einen Referenzzeitstempel im NTP-Format und einen RTP-Zeitstempel für denselben Zeitpunkt. Das Paar beschreibt die Beziehung zwischen lokalem Medienzähler und Referenzuhr. Audio und Video gelangen über getrennte Abbildungen auf dieselbe Zeitbasis.

Die Paare stehen nicht in jedem Datenpaket. Sie werden seltener mit RTCP gesendet; dazwischen setzt der Empfänger die Beziehung anhand der bekannten Taktrate fort. Der RTP-Wert im Bericht ist meistens nicht mit dem Wert eines benachbarten Datenpakets identisch. Er wird für den Referenzzeitpunkt des Berichts berechnet. Ein Prüfer, der die Nachbarpaket-Gleichheit verlangt, verwirft eine korrekte Zuordnung.

NTP-Format bedeutet zudem nicht automatisch UTC. Fehlt absolute Zeit, darf ein Sender eine verbreitete relative Systemuhr wie die Laufzeit verwenden. Fehlen auch Angaben über verstrichene Zeit, darf er null eintragen. Die Darstellung verrät weder Herkunft noch Genauigkeit der Referenz.

RFC 7273 fasste später ausdrücklich zusammen, dass das NTP/RTP-Paar eines Senderberichts eine Abbildung definiert. Zeitgleiche Wiedergabe mehrerer Quellen setzt weiterhin synchronisierte Referenzwerte voraus. Der Bericht belegt eine Relation; er beglaubigt die zugrunde liegende Uhr nicht.

Aus Paketstimme wurde ein Zeitmodell

Casners Weg zu RTP begann mit Paketstimme im ARPANET. Die ISI schildert, wie kontinuierliches Audio unter knapper Bandbreite komprimiert, in Pakete zerlegt und am Ziel rekonstruiert werden musste. Später arbeitete er an Paketvideo, am MBONE und an der RTP-Standardisierung. Der Nachruf des Instituts führt die Linie vom Network Voice Protocol und Packet Video Protocol zu RTP.

Diese Vorgeschichte erklärt die Zurückhaltung des Standards. RTP reserviert keine Ressourcen und garantiert keine Dienstgüte. Das Netz darf verzögern, verlieren und Ankunftsfolgen verändern. Das Protokoll liefert gerade genug getrennte Hinweise zu Quelle, Format, Sendefolge, Medienzeit und Empfang, damit Anwendungen Kontinuität herstellen und Unsicherheit erkennen können.

Die Revision von 2003 änderte die Paketformate auf dem Draht nicht. Als größte Neuerung nennt RFC 3550 den skalierbaren RTCP-Timer für den Fall, dass viele Teilnehmer gleichzeitig eintreten. Nicht der Zeitstempel bekam mehr Bedeutungen; die Verteilung der Kontrollbelege wurde belastbarer.

Ohne Uhrdomäne ist die Messung unvollständig

Eine brauchbare Aufzeichnung speichert neben dem RTP-Zeitstempel SSRC, Nutzlastformat, Taktrate, Sequenznummer, Beobachtungszeit und die nächsten gültigen RTP/NTP-Paare. War die Referenz relativ oder null, gehört auch das in den Beleg.

Damit lassen sich Signale trennen. Eine Sequenzlücke deutet auf Verlust. Ein Sprung im Medienzähler kann einen Neustart, Formatwechsel oder Präsentationssprung anzeigen. Ein alter Senderbericht vergrößert die Unsicherheit der Abbildung. Erst nach Projektion auf dieselbe Referenz ist wachsende Abweichung zwischen Audio und Video ein plausibler Driftbefund.

Fehlt der Kontext, erzeugt das Dashboard Sicherheit aus Voreinstellungen: Es teilt jeden Wert durch 90.000, sortiert Sendungen nach Abtastzeit, subtrahiert zufällige Offsets oder druckt eine relative NTP-Zahl als UTC. Rechenbar ist nicht gleich belegt.

Casners Protokollarbeit hinterlässt damit eine allgemeine Regel: Ein enges Feld ist kein Mangel, wenn der Übergang zu einer größeren Aussage als eigener, prüfbarer Beleg erhalten bleibt.

Quellen