1. Einführung

Bei der Verwendung von RTP zur Bereitstellung multimedialer Inhalte ist es oft notwendig, die Wiedergabe von Audio- und Videokomponenten einer Präsentation zu synchronisieren. Dies wird unter Verwendung von Informationen erreicht, die in RTP Control Protocol (RTCP) Sender Report (SR) Paketen [RFC3550] enthalten sind. Diese werden periodisch gesendet, und die Komponenten einer Multimedia-Sitzung können nicht synchronisiert werden, bis für jeden RTP-Strom genügend RTCP SR-Pakete empfangen wurden, damit der Empfänger Zuordnungen zwischen dem für jeden RTP-Strom verwendeten Medien-Takt und dem gemeinsamen (NTP-Format) Referenztakt herstellen kann, der zur Etablierung der Synchronisation verwendet wird.

In letzter Zeit wurde die Besorgnis geäußert, dass diese Synchronisationsverzögerung für einige Anwendungen problematisch ist, beispielsweise für solche, die eine geschichtete oder Multi-Description-Videokodierung verwenden. Dieses Memorandum gibt einen Überblick über die Abläufe der RTP-Synchronisation und beschreibt die zu erwartende Synchronisationsverzögerung. Es werden drei rückwärtskompatible Erweiterungen zum grundlegenden RTP-Synchronisationsmechanismus vorgeschlagen:

• Die RTCP-Übertragungs-Timing-Regeln werden für Source-Specific Multicast (SSM)-Sender gelockert, um die anfängliche Synchronisationslatenz für große SSM-Gruppen zu verringern. Siehe Abschnitt 3.1.

• Eine Erweiterung des erweiterten RTP-Profils für RTCP-basiertes Feedback (RTP/AVPF) [RFC4585] wird definiert, um es Empfängern zu ermöglichen, zusätzliche RTCP SR-Pakete anzufordern, die die zur Synchronisation von RTP-Strömen erforderlichen Metadaten liefern. Dies kann die Synchronisationsverzögerung beim Beitritt zu Sitzungen mit großen RTCP-Meldeintervallen, bei Paketverlusten oder beim Einsatz von videoumschaltenden MCUs verringern. Siehe Abschnitt 3.2.

• Zwei RTP-Header-Erweiterungen werden definiert, um Synchronisations-Metadaten In-Band mit RTP-Datenpaketen zu übertragen. Diese Erweiterungen stellen Synchronisations-Metadaten bereit, die auf die RTP-Datenpakete ausgerichtet sind, und machen so die Schätzung der Taktabweichung (Clock Skew) zwischen den Strömen vor der Synchronisation überflüssig. Sie können auch die Notwendigkeit verringern, RTCP SR-Pakete zu empfangen, bevor Ströme synchronisiert werden können, obwohl sie die Notwendigkeit von RTCP nicht beseitigen. Siehe Abschnitt 3.3.

Der unmittelbare Anwendungsfall für diese Erweiterungen ist die Verringerung der synchronisationsbedingten Verzögerung beim Beitritt zu einer geschichteten Videositzung (z. B. eine H.264/SVC (Scalable Video Coding)-Sitzung im Non-Interleaved Timestamp-based (NI-T) Modus [AVT-RTP-SVC]). Die Erweiterungen sind jedoch nicht spezifisch für die geschichtete Kodierung und können in jeder Umgebung verwendet werden, in der die Synchronisationslatenz ein Thema ist.

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "KANN" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [RFC2119] beschrieben zu interpretieren.

2. Synchronisation von RTP-Strömen

RTP-Ströme werden von Empfängern basierend auf Informationen synchronisiert, die in von Sendern erzeugten RTCP SR-Paketen enthalten sind (insbesondere der Zeitstempel im NTP-Format und der RTP-Zeitstempel). Die Synchronisation erfordert, dass ein gemeinsamer Referenztakt verwendet werden MUSS, um die Zeitstempel im NTP-Format in einer Gruppe von zu synchronisierenden Strömen zu erzeugen (d. h. bei der Synchronisation mehrerer RTP-Ströme werden die RTP-Zeitstempel für jeden Strom von separaten und medienspezifischen Takten abgeleitet, aber die Zeitstempel im NTP-Format in den RTCP SR-Paketen aller zu synchronisierenden Ströme MÜSSEN von demselben Takt abgetastet werden). Um eine schnellere und genauere Synchronisation zu erreichen, wird ferner EMPFOHLEN, dass Sender und Empfänger nach Möglichkeit einen synchronisierten gemeinsamen NTP-Format-Referenztakt mit gemeinsamen Eigenschaften, insbesondere der Zeitbasis, verwenden (wobei anerkannt wird, dass dies oft nicht möglich ist, wenn RTP außerhalb von kontrollierten Umgebungen verwendet wird); die Mittel, durch die dieser gemeinsame Referenztakt und seine Eigenschaften signalisiert und verteilt werden, liegen außerhalb des Rahmens dieses Memorandums.

Bei Multimedia-Sitzungen wird jeder Medientyp (z. B. Audio oder Video) in einer separaten RTP-Sitzung gesendet, und der Empfänger ordnet zu synchronisierende RTP-Ströme mittels des kanonischen Endpunkt-Bezeichners (CNAME) zu, der in den vom Sender erzeugten oder Out-of-Band signalisierten RTCP Source Description (SDES) Paketen [RFC5576] enthalten ist. Bei geschichteten Medien können verschiedene Schichten in verschiedenen RTP-Sitzungen oder unter Verwendung verschiedener Synchronisationsquellen-Werte (SSRC) innerhalb einer einzigen RTP-Sitzung gesendet werden; in beiden Fällen wird der CNAME verwendet, um zu synchronisierende Ströme zu identifizieren. Um die Synchronisation zu gewährleisten, MUSS ein RTP-Sender daher periodische zusammengesetzte RTCP-Pakete gemäß Abschnitt 6 von RFC 3550 [RFC3550] senden.

Das Timing dieser periodischen zusammengesetzten RTCP-Pakete hängt von der Anzahl der Teilnehmer in jeder RTP-Sitzung, dem Anteil derer, die Daten senden, der Sitzungsbandbreite, dem konfigurierten RTCP-Bandbreitenanteil und davon ab, ob die Sitzung Multicast oder Unicast ist (siehe RFC 3550, Abschnitt 6.2 für Details). Zusammenfassend lässt sich sagen, dass dem RTCP-Kontrollverkehr ein kleiner Anteil, im Allgemeinen 5 %, der Sitzungsbandbreite zugewiesen wird. Von diesem Anteil wird ein Viertel aktiven RTP-Sendern zugewiesen, während Empfänger die verbleibenden drei Viertel nutzen (diese Anteile können über das Session Description Protocol (SDP) [RFC3556] konfiguriert werden). Jeder Teilnehmer einer RTP-Sitzung leitet ein RTCP-Meldeintervall basierend auf diesen Anteilen ab, ob die Sitzung Multicast oder Unicast ist, der Anzahl der beobachteten Teilnehmer und ob er aktiv Daten sendet oder nicht. Er sendet dann durchschnittlich einmal pro Meldeintervall ein zusammengesetztes RTCP-Paket (die tatsächliche Paketübertragungszeit wird im Bereich [0,5 ... 1,5] mal dem Meldeintervall zufällig verteilt, um eine Synchronisation der Berichte zu vermeiden).

Ein minimales Meldeintervall von 5 Sekunden wird EMPFOHLEN, wobei die Verzögerung vor dem Senden des ersten Berichts "auf die Hälfte des minimalen Intervalls eingestellt werden KANN, um eine schnellere Benachrichtigung über die Anwesenheit des neuen Teilnehmers zu ermöglichen" [RFC3550]. Außerdem KANN bei Unicast-Sitzungen "die Verzögerung vor dem Senden des ersten zusammengesetzten RTCP-Pakets Null sein" [RFC3550]. Zusätzlich KANN bei Unicast-Sitzungen und bei aktiven Sendern in einer Multicast-Sitzung das feste minimale Meldeintervall auf "360 geteilt durch die Sitzungsbandbreite in Kilobit/Sekunde" skaliert werden. Dieses Minimum ist bei Bandbreiten von mehr als 72 kb/s kleiner als 5 Sekunden" [RFC3550].

2.1. Anfängliche Synchronisationsverzögerung

Eine Multimedia-Sitzung umfasst eine Gruppe gleichzeitiger RTP-Sitzungen unter einer gemeinsamen Gruppe von Teilnehmern, wobei eine RTP-Sitzung für jeden Medientyp verwendet wird. Zum Beispiel könnte eine Videokonferenz (die eine Multimedia-Sitzung ist) eine Audio-RTP-Sitzung und eine Video-RTP-Sitzung enthalten. Um einem Empfänger die Synchronisation der Komponenten einer Multimedia-Sitzung zu ermöglichen, MUSS von jedem Sender ein zusammengesetztes RTCP-Paket, das ein RTCP SR-Paket und ein RTCP SDES-Paket mit einem CNAME-Element enthält, an jede der RTP-Sitzungen in der Multimedia-Sitzung gesendet werden. Ein Empfänger kann die Wiedergabe über die Multimedia-Sitzung erst dann synchronisieren, wenn solche RTCP-Pakete in allen beteiligten RTP-Sitzungen empfangen wurden. Wenn kein Paketverlust auftritt, ergibt dies eine erwartete anfängliche Synchronisationsverzögerung, die der durchschnittlichen Zeit entspricht, die benötigt wird, um das erste RTCP-Paket in der RTP-Sitzung mit dem längsten RTCP-Meldeintervall zu empfangen. Dies variiert zwischen Unicast- und Multicast-RTP-Sitzungen.

Die anfängliche Synchronisationsverzögerung für geschichtete Sitzungen ist ähnlich der für Multimedia-Sitzungen. Die Schichten können erst synchronisiert werden, wenn die RTCP SR- und CNAME-Informationen für jede Schicht in der Sitzung empfangen wurden.

2.1.1. Unicast-Sitzungen

Bei Unicast-Multimedia- oder geschichteten Sitzungen SOLLTEN Sender unmittelbar nach dem Beitritt zu jeder RTP-Sitzung in der Multimedia-Sitzung ein erstes zusammengesetztes RTCP-Paket (das ein RTCP SR-Paket und ein RTCP SDES-Paket mit einem CNAME-Element enthält) senden. Die einzelnen RTP-Sitzungen gelten als beigetreten, sobald jegliche In-Band-Signalisierung für NAT-Traversal (z. B. [RFC5245]) und/oder Sicherheits-Keying (z. B. [RFC5764], [ZRTP]) abgeschlossen ist und der Medienpfad offen ist. Dies impliziert, dass das erste RTCP-Paket parallel zum ersten Datenpaket gesendet wird, gemäß der Anleitung in RFC 3550, dass "die Verzögerung vor dem Senden des ersten zusammengesetzten RTCP-Pakets Null sein KANN", und bei Abwesenheit von Paketverlusten können Ströme sofort synchronisiert werden.

Es wird erwartet, dass NAT-Pinholes, Firewall-Öffnungen, Dienstgüte und Medien-Sicherheitsschlüssel als Teil der Signalisierung, ob In-Band oder Out-of-Band, ausgehandelt wurden, bevor das erste RTCP-Paket gesendet wird. Dies sollte sicherstellen, dass alle Middleboxes bereit sind, Verkehr zu akzeptieren, und die Wahrscheinlichkeit verringern, dass das erste RTCP-Paket verloren geht.

2.1.2. Source-Specific Multicast (SSM)-Sitzungen

Bei Multicast-Sitzungen variiert die Verzögerung vor dem Senden des ersten RTCP-Pakets und damit die Synchronisationsverzögerung mit der Sitzungsbandbreite und der Anzahl der Teilnehmer in der Sitzung. Bei einer Multicast-Multimedia- oder geschichteten Sitzung hängt die durchschnittliche Synchronisationsverzögerung von der langsamsten der beteiligten RTP-Sitzungen ab; dies wird im Allgemeinen die Sitzung mit der niedrigsten Bandbreite sein (vorausgesetzt, alle RTP-Sitzungen haben die gleiche Anzahl an Teilnehmern).

Beim Senden an eine Multicast-Gruppe sollte das reduzierte minimale RTCP-Meldeintervall von 360 Sekunden geteilt durch die Sitzungsbandbreite in Kilobit pro Sekunde [RFC3550] verwendet werden, wenn die Synchronisationslatenz wahrscheinlich ein Problem darstellt. Außerdem wird das Meldeintervall wie üblich für das erste RTCP-Paket halbiert. Abhängig von der Sitzungsbandbreite und der Anzahl der Teilnehmer ergeben sich die in Abbildung 1 dargestellten durchschnittlichen Synchronisationsverzögerungen.

    Sitzungsband-| Anzahl der Empfänger:
           breite|  2     3     4     5     10   100   1000  10000
             --+------------------------------------------------
          8 kbps| 2.73  4.10  5.47  5.47  5.47  5.47  5.47  5.47
         16 kbps| 2.50  2.50  2.73  2.73  2.73  2.73  2.73  2.73
         32 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
         64 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
        128 kbps| 1.41  1.41  1.41  1.41  1.41  1.41  1.41  1.41
        256 kbps| 0.70  0.70  0.70  0.70  0.70  0.70  0.70  0.70
        512 kbps| 0.35  0.35  0.35  0.35  0.35  0.35  0.35  0.35
          1 Mbps| 0.18  0.18  0.18  0.18  0.18  0.18  0.18  0.18
          2 Mbps| 0.09  0.09  0.09  0.09  0.09  0.09  0.09  0.09
          4 Mbps| 0.04  0.04  0.04  0.04  0.04  0.04  0.04  0.04

   Abbildung 1: Durchschnittliche anfängliche Synchronisationsverzögerung
                in Sekunden für eine RTP-Sitzung mit 1 Sender

Diese Zahlen gehen von einem Source-Specific Multicast-Kanal mit einem einzigen aktiven Sender aus, wobei eine durchschnittliche RTCP-Paketgröße von 70 Oktetts angenommen wird. Diese Intervalle reichen für Lip-Sync ohne übermäßige Verzögerung aus, könnten aber als zu große Latenz für die Synchronisation von Teilen eines geschichteten Videostroms angesehen werden.

Das RTCP-Intervall wird in der üblichen Weise zufällig verteilt, so dass die minimale Synchronisationsverzögerung die Hälfte dieser Intervalle beträgt und die maximale Verzögerung das 1,5-fache dieser Intervalle. Beachten Sie auch, dass diese RTCP-Intervalle unter der Annahme einer perfekten Kenntnis der Anzahl der Teilnehmer in der Sitzung berechnet werden.

2.1.3. Any-Source Multicast (ASM)-Sitzungen

Bei ASM-Sitzungen spielt der Anteil der Teilnehmer, die Sender sind, eine wichtige Rolle und verursacht größere Schwankungen im durchschnittlichen RTCP-Meldeintervall. Dies wird in Abbildung 2 und Abbildung 3 verdeutlicht, die das RTCP-Meldeintervall für dieselben Sitzungsbandbreiten und Empfängerpopulationen wie die in Abbildung 1 beschriebene SSM-Sitzung zeigen, jedoch für Sitzungen mit 2 bzw. 10 Sendern. Es ist zu sehen, dass die anfängliche Synchronisationsverzögerung mit der Anzahl der Sender skaliert (dies soll sicherstellen, dass der gesamte RTCP-Verkehr aller Gruppenmitglieder nicht unbegrenzt wächst) und deutlich größer sein kann als bei Source-Specific-Gruppen. Dennoch bleibt die anfängliche Synchronisationszeit für Lip-Sync in typischen kleinen bis mittelgroßen Gruppen-Videokonferenz-Szenarien akzeptabel.

Beachten Sie, dass Multi-Sender-Gruppen, die unter Verwendung von Multi-Unicast mit einem zentralen RTP-Translator (Topo-Translator in der Terminologie von [RFC5117]) implementiert sind, eine ähnliche Synchronisationsleistung wie ASM-Gruppen (Topo-ASM) aufweisen, da der Translator effektiv eine ASM-Gruppe bildet.