Zum Hauptinhalt springen

3. Verringerung der RTP-Synchronisationsverzögerungen

Drei rückwärtskompatible RTP-Erweiterungen werden definiert, um die mögliche Synchronisationsverzögerung zu verringern: ein verkürztes anfängliches RTCP-Intervall für SSM-Sender, eine Nachricht für eine schnelle Resynchronisationsanfrage und RTP-Header-Erweiterungen, die Synchronisations-Metadaten In-Band übertragen können.

3.1. Verkürztes anfängliches RTCP-Intervall für SSM-Sender​

In SSM-Sitzungen, in denen die anfängliche Synchronisationsverzögerung wichtig ist, KANN der RTP-Sender die Verzögerung vor dem Senden des ersten zusammengesetzten RTCP-Pakets auf Null setzen und sein erstes RTCP-Paket unmittelbar nach dem Beitritt zur SSM-Sitzung senden. Dies ist rein eine lokale Änderung am Sender, die als konfigurierbare Option implementiert werden kann. RTP-Empfänger in einer SSM-Sitzung, die Unicast-RTCP-Feedback senden, DÜRFEN KEINE RTCP-Pakete mit einer anfänglichen Verzögerung von Null senden; die in [RFC5760] definierten Timing-Regeln gelten unverändert für Empfänger.

3.2. Schnelle Resynchronisationsanfrage​

Das allgemeine Format einer RTP/AVPF-Transportschicht-Feedback-Nachricht ist in Abbildung 4 dargestellt (siehe [RFC4585] für Details).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT   | PT=RTPFB=205  |             Länge             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC des Paketsenders                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC der Medienquelle                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :            Feedback Control Information (FCI)                 :
     :                                                               :

             Abbildung 4: RTP/AVPF Transportschicht-Feedback-Nachricht

Ein neuer Feedback-Nachrichtentyp, RTCP-SR-REQ, wird mit FMT = 5 definiert. Der Teil Feedback Control Information (FCI) der Feedback-Nachricht MUSS leer sein. Die SSRC des Paketsenders gibt den Teilnehmer an, der die Medienströme nicht synchronisieren kann, während die SSRC der Medienquelle den Sender der Medien angibt, die er nicht synchronisieren kann. Die Länge MUSS gleich 2 sein.

Wenn das RTP/AVPF-Profil [RFC4585] verwendet wird, KANN diese Feedback-Nachricht von einem Empfänger gesendet werden, um anzuzeigen, dass er einige Medienströme nicht synchronisieren kann und wünscht, dass die Medienquelle so bald wie möglich ein RTCP SR-Paket überträgt (innerhalb der Einschränkungen der RTCP-Timing-Regeln für frühes Feedback). Wenn eine Medienquelle, die das RTCP-SR-REQ-Paket versteht, einen solchen Hinweis erhält, SOLLTE sie so bald wie möglich ein RTCP SR-Paket unter Einhaltung der RTCP-Regeln für frühes Feedback erzeugen. Wenn die Verwendung von nicht-zusammengesetztem RTCP [RFC5506] zuvor ausgehandelt wurde, können sowohl die Feedback-Anfrage als auch die RTCP SR-Antwort als nicht-zusammengesetzte RTCP-Pakete gesendet werden. Das RTCP-SR-REQ-Paket KANN einmal pro RTCP-Meldeintervall wiederholt werden, wenn kein RTCP SR-Paket eintrifft. Die Medienquelle kann RTCP-SR-REQ-Pakete ignorieren, wenn ihr regulärer Zeitplan für die Übertragung von Synchronisations-Metadaten voraussichtlich dazu führt, dass der Empfänger die Medienströme innerhalb eines angemessenen Zeitrahmens synchronisieren kann.

Bei der Verwendung von SSM-Sitzungen mit Unicast-Feedback ist es möglich, dass das Feedback-Ziel und die Medienquelle nicht am selben Ort angesiedelt sind. Wenn ein Feedback-Ziel in einem solchen Fall eine RTCP-SR-REQ Feedback-Nachricht erhält, sollte die Anfrage an die Medienquelle weitergeleitet werden. Der Mechanismus, der zum Weiterleiten solcher Anfragen zu verwenden ist, wird hier nicht definiert.

Wenn das Feedback-Ziel eine Netzwerkmanagement-Schnittstelle bereitstellt, könnte es nützlich sein, ein Protokoll darüber bereitzustellen, welche Empfänger RTCP-SR-REQ Feedback-Pakete senden und welche nicht, da diejenigen, die dies nicht tun, eine langsamere Strom-Synchronisation sehen werden.

3.3. In-Band-Übermittlung von Synchronisations-Metadaten​

Der in [RFC5285] definierte RTP-Header-Erweiterungsmechanismus kann so angepasst werden, dass ein OPTIONALER Zeitstempel im NTP-Format in RTP-Datenpaketen mitgeführt wird. Wenn ein solcher Zeitstempel enthalten ist, MUSS er demselben Zeitpunkt entsprechen wie der RTP-Zeitstempel im Header des Pakets und MUSS von demselben Takt abgeleitet sein, der zur Erzeugung der in RTCP SR-Paketen enthaltenen Zeitstempel im NTP-Format verwendet wird. Vorausgesetzt, er kennt die SSRC-zu-CNAME-Zuordnung, entweder durch den vorherigen Empfang eines RTCP CNAME-Pakets oder über Out-of-Band-Signalisierung [RFC5576], kann der Empfänger die bereitgestellten Informationen als Eingabe für den Synchronisationsalgorithmus in genau derselben Weise verwenden, als ob ein zusätzliches RTCP SR-Paket für den Strom empfangen worden wäre.

Für diese Header-Erweiterung werden zwei Varianten definiert. Die erste Variante erweitert den RTP-Header um einen 64-Bit-Zeitstempel im NTP-Format, wie in [RFC5905] definiert. Die zweite Variante überträgt den unteren 24-Bit-Teil der Sekunden (Seconds) eines Zeitstempels im NTP-Format und die 32 Bit des Bruchteils (Fraction) eines Zeitstempels im NTP-Format. Die Formate der beiden Varianten sind in Abbildung 5 und Abbildung 6 dargestellt.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |         Sequenznummer         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          Zeitstempel                          |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |            Synchronisationsquelle (SSRC) Bezeichner           |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |             Länge=3           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-A  | L=7   |   NTP-Zeitstempelformat - Sekunden (Bit 0-23) |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |NTP Sek(24-31) |   NTP-Zeitstempelformat - Bruch (Bit 0-23)    |e
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
     |NTP Frc(24-31) |    0 (Pad)    |    0 (Pad)    |    0 (Pad)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         Nutzlastdaten                         |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Abbildung 5: Variante A / 64-Bit NTP-RTP-Header-Erweiterung
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |         Sequenznummer         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          Zeitstempel                          |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |            Synchronisationsquelle (SSRC) Bezeichner           |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |             Länge=2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-B  | L=6   |   NTP-Zeitstempelformat - Sekunden (Bit 8-31) |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |               NTP-Zeitstempelformat - Bruch (Bit 0-31)        |e
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         Nutzlastdaten                         |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Abbildung 6: Variante B / 56-Bit NTP-RTP-Header-Erweiterung

Ein Zeitstempel im NTP-Format KANN in jedes beliebige RTP-Paket aufgenommen werden, das der Sender wählt. Es wird jedoch EMPFOHLEN, ihn aufzunehmen, wenn eine zeitstempelbasierte Wiederherstellung der Dekodierungsreihenfolge für geschichtete Codecs durchgeführt wird, die in mehreren RTP-Strömen transportiert werden, wie in Abschnitt 4.1 näher spezifiziert. Diese Header-Erweiterung SOLLTE auch in den RTP-Paketen gesendet werden, die einem Video-Random-Access-Point entsprechen, sowie in den zugehörigen Audio-Paketen, um eine schnelle Synchronisation für Späteinsteiger in Multimedia-Sitzungen und in Videoumschaltungsszenarien zu ermöglichen.

Hinweis: Die Aufnahme einer RTP-Header-Erweiterung verringert die Effizienz der RTP-Header-Komprimierung, falls diese verwendet wird. Darüber hinaus können Middleboxes, die die Header-Erweiterungen nicht verstehen, diese entfernen oder den Inhalt nicht gemäß diesem Memorandum aktualisieren.

In allen Fällen MÜSSEN, unabhängig davon, ob In-Band-Zeitstempel im NTP-Format enthalten sind oder nicht, reguläre RTCP SR-Pakete gesendet werden, um die Rückwärtskompatibilität mit Empfängern zu gewährleisten, die RTP-Ströme gemäß [RFC3550] synchronisieren, sowie die Robustheit gegenüber Middleboxes (RTP-Translators), die RTP-Header-Erweiterungen entfernen könnten. Wenn die Variante B / 56-Bit NTP-RTP-Header-Erweiterung verwendet wird, MÜSSEN RTCP-Senderberichte verwendet werden, um die oberen 8 Bits der Sekunden für den Zeitstempel im NTP-Format abzuleiten.

Wenn SDP verwendet wird, MUSS die Verwendung der oben definierten RTP-Header-Erweiterungen wie in [RFC5285] spezifiziert angegeben werden. Daher MÜSSEN die folgenden URIs verwendet werden:

  • Der zur Signalisierung der Verwendung der Variante A / 64-Bit NTP-RTP-Header-Erweiterung in SDP verwendete URI ist "urn:ietf:params:rtp-hdrext:ntp-64".

  • Der zur Signalisierung der Verwendung der Variante B / 56-Bit NTP-RTP-Header-Erweiterung in SDP verwendete URI ist "urn:ietf:params:rtp-hdrext:ntp-56".

Die Verwendung dieser RTP-Header-Erweiterungen kann die Benutzererfahrung beim IPTV-Zapping und in einigen interaktiven Videokonferenzszenarien erheblich verbessern. Netzwerkmanagement-Tools, die versuchen, die Benutzererfahrung zu überwachen, möchten möglicherweise protokollieren, welche Sitzungen diese Erweiterungen signalisieren und verwenden.

Letztes Update am