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 requiriert, 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]) oder Mixer (Topo-Mixer) oder bestimmten Formen von videoumschaltenden MCUs (Topo-Video-switch-MCU) implementiert sind, RTCP-Pakete an alle Gruppenmitglieder verteilen und daher in Bezug auf die anfängliche Synchronisationslatenz in gleicher Weise skalieren wie eine ASM-Gruppe.
Sitzungsband-| Anzahl der Empfänger:
breite| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
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 2: Durchschnittliche anfängliche Synchronisationsverzögerung
in Sekunden für eine RTP-Sitzung mit 2 Sendern
Sitzungsband-| Anzahl der Empfänger:
breite| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Abbildung 3: Durchschnittliche anfängliche Synchronisationsverzögerung
in Sekunden für eine RTP-Sitzung mit 10 Sendern
2.1.4. Diskussion
Für Unicast-Sitzungen ermöglicht der bestehende RTCP SR-basierte Mechanismus eine sofortige Synchronisation, vorausgesetzt, das erste RTCP-Paket geht nicht verloren.
Für SSM-Sitzungen reicht die anfängliche Synchronisationsverzögerung für Lip-Sync aus, kann jedoch für einige geschichtete Codecs größer sein als gewünscht. Der Grund dafür, keine sofortigen RTCP-Pakete für Multicast-Gruppen zu senden, besteht darin, eine Implosion von Anfragen zu vermeiden, wenn eine große Anzahl von Teilnehmern gleichzeitig der Gruppe beitritt ("Flash Crowd"). Dies ist für SSM-Sender kein Problem, da es höchstens einen Sender gehen kann. Daher ist es wünschenswert, SSM-Sendern zu erlauben, beim Beitritt zu einer Sitzung ein sofortiges RTCP SR zu senden (wie es derzeit für Unicast-Sitzungen zulässig ist, die ebenfalls nicht unter dem Implosionsproblem leiden). SSM-Empfängern, die Unicast-Feedback verwenden, wäre es nicht gestattet, sofortiges RTCP zu senden. Für ASM-Sitzungen ist die Implosion von Antworten ein Problem, daher wird keine Änderung der RTCP-Timing-Regeln vorgeschlagen.
In allen Fällen ist es möglich, dass das erste RTCP SR-Paket verloren geht. In diesem Fall kann der Empfänger die Medien erst synchronisieren, wenn das Meldeintervall verstrichen ist und das nächste RTCP SR-Paket gesendet wird. Dies ist unerwünscht. Abschnitt 3.2 definiert eine neue RTP/AVPF-Transportschicht-Feedback-Nachricht, um die Erzeugung eines RTCP SR anzufordern, was eine schnelle Resynchronisation im Falle von Paketverlusten ermöglicht.
2.2. Synchronisation für Späteinsteiger
Die Synchronisation zwischen RTP-Sitzungen ist für Späteinsteiger potenziell langsamer als für Teilnehmer, die zu Beginn der Sitzung anwesend waren. Die Gründe hierfür sind dreifach:
-
Viele der Optimierungen, die eine schnelle Übertragung von RTCP SR-Paketen ermöglichen, gelten nur zu Beginn einer Sitzung. Dies bedeutet, dass ein neuer Teilnehmer möglicherweise ein vollständiges RTCP-Meldeintervall für jede Sitzung warten muss, bevor er die erforderlichen Daten zur Synchronisation der Medienströme erhält. Dies kann je nach konfigurierter Sitzungsbandbreite und Anzahl der Teilnehmer potenziell mehrere Sekunden dauern.
-
Eine zusätzliche Synchronisationsverzögerung ergibt sich aus der Art der RTCP-Timing-Regeln. Pakete werden durchschnittlich einmal pro Meldeintervall erzeugt, wobei die genauen Übertragungszeiten jedoch um +/- 50 % zufällig verteilt werden, um eine Synchronisation der Berichte zu vermeiden. Dies ist wichtig, um Netzüberlastungen in Multicast-Sitzungen zu vermeiden, bedeutet aber, dass das Timing der RTCP-Senderberichte für verschiedene RTP-Sitzungen nicht synchronisiert ist. Dementsprechend muss ein Empfänger die Taktabweichung (Skew) auf dem NTP-Format-Takt schätzen, um die RTP-Zeitstempel über die Sitzungen hinweg ausrichten zu können. Diese Schätzung ist ein wesentlicher Bestandteil einer RTP-Synchronisationsimplementierung und kann bei ausreichend vorhandenen Berichten mit hoher Genauigkeit durchgeführt werden. Das Sammeln von ausreichend RTCP SR-Daten zur Durchführung dieser Schätzung kann jedoch den Empfang mehrerer RTCP-Berichte erfordern, was die Synchronisationsverzögerung weiter erhöht.
-
Viele Medien-Codecs verfügen über das Konzept periodischer Zugangspunkte (Access Points), so dass ein neu beigetretener Empfänger oft erst dann mit der Dekodierung eines Medienstroms beginnen kann, wenn die dem Zugangspunkt entsprechenden Pakete empfangen wurden. Diese Zugangspunkte werden möglicherweise seltener als RTCP SR-Pakete gesendet und können daher der begrenzende Faktor beim Start der synchronisierten Medienwiedergabe für Späteinsteiger sein. Die RTP-Erweiterung für die Unicast-basierte schnelle Erfassung von Multicast-RTP-Sitzungen [AVT-ACQUISITION-RTP] kann in einigen Szenarien verwendet werden, um die Zeit bis zum Empfang der Zugangspunkte zu verkürzen.
Diese Verzögerungen sind wahrscheinlich ein Problem beim Einschalten in eine laufende Multicast-RTP-Sitzung oder für videoumschaltende MCUs.