WikiDer > Echtzeit-Transportkontrollprotokoll

Echtzeit-Transportkontrollprotokoll (RTCP) wird zusammen mit . verwendet RTP beschrieben in RFC 3550.^[1] Das Protokoll verarbeitet Feedback, Synchronisation und die Benutzeroberfläche. Es transportiert keine Medienproben, kann aber verwendet werden, um Informationen über Verzögerungen, Verzögerungsschwankungen (zittern), Bandbreite, Überlastung und andere Netzwerkeigenschaften.

Anwendungen

Die Informationen können vom Verschlüsselungsprozess verwendet werden, um die Übertragungsrate (einschließlich der Übertragungsqualität) zu erhöhen, wenn das Netzwerk ordnungsgemäß funktioniert, und um die Übertragungsrate bei einem Problem im Netzwerk zu verringern. Kontinuierliches Feedback an die Verschlüsselungsalgorithmen ermöglicht es, unter aktuellen Bedingungen optimale Qualität zu liefern. Wenn beispielsweise die Bandbreite während der Übertragung zu- oder abnimmt, kann der Verschlüsselungsalgorithmus auf Wunsch geändert werden MP3 zu 8-bit PCM oder Delta-Modulation geschaltet werden. Das Datenfeld wird verwendet, um dem Ziel mitzuteilen, welcher Verschlüsselungsalgorithmus für das aktuelle Paket verwendet wird, sodass es zwischendurch umgeschaltet werden kann. Ein Problem bei der Bereitstellung von Feedback besteht darin, dass die RTCP-Berichte an alle Teilnehmer gesendet werden. Bei Multicast-Anwendungen mit einer großen Gruppe muss die von RTCP verwendete Bandbreite schnell wachsen. Um dies zu verhindern, skalieren RTCP-Sender ihre Berichte so weit herunter, dass sie zusammen zB nicht mehr als 5% der Medienbandbreite nutzen. Dazu muss jeder Teilnehmer die Medienbandbreite kennen, die er vom Sender erfährt, und die Anzahl der Teilnehmer, die er durch Anhören anderer RTCP-Berichte schätzen kann. RTCP stellt auch die Synchronisation zwischen den Flüssen sicher. Das Problem besteht darin, dass unterschiedliche Flüsse mit unterschiedlichen Geschwindigkeiten arbeiten können. RTCP kann verwendet werden, um diese zu synchronisieren. RTCP bietet auch die Möglichkeit, verschiedene Quellen zu benennen.Diese Informationen werden auf dem Bildschirm des Empfängers angezeigt, um anzuzeigen, wer gerade spricht.

Wiedergabe mit Pufferung und Jitterkontrolle

Wenn die Medieninformationen beim Empfänger ankommen, müssen sie zum richtigen Zeitpunkt abgespielt werden. Im Allgemeinen ist dies nicht der Fall, wenn das RTP-Paket beim Empfänger ankommt, da Pakete eine etwas andere Zeit benötigen, um das Netzwerk zu passieren. Selbst wenn die Pakete dem Sender in genau gleichen Abständen zugeführt werden, erreichen sie den Empfänger zu unterschiedlichen relativen Zeiten. Diese Verzögerungsvariation wird zu zittern erwähnt. Selbst ein geringer Paket-Jitter kann störende Medienartefakte verursachen, wie z. B. abgehackte Videobilder oder unverständliches Audio. Die Lösung für dieses Problem ist Puffer der Pakete beim Empfänger vor der Wiedergabe, um Jitter zu reduzieren.

Beispiel

Glätten des Ausgabestroms durch Puffern von Paketen

Ein Stream von Paketen wird mit beträchtlichem Jitter geliefert. Paket 1 wird bei t=0s von einem Server gesendet und kommt bei t=1s beim Client an. Paket 2 hat mehr Verzögerung und dauert 2 Sekunden, um anzukommen. Wenn die Pakete eintreffen, werden sie auf dem Client-Computer gepuffert. Die Wiedergabe beginnt bei t=10s. An diesem Punkt werden die Pakete 1 bis 6 gepuffert, so dass sie in gleichmäßigen Intervallen für eine regelmäßige Wiedergabe aus dem Puffer entfernt werden können. Im Allgemeinen müssen keine einheitlichen Intervalle verwendet werden, da RTP-Zeitstempel anzeigen, wann das Medium abgespielt werden soll. Leider sehen wir, dass Paket 8 so stark verzögert ist, dass es nicht verfügbar ist, wenn es an der Reihe ist . Es gibt zwei Möglichkeiten. Paket 8 kann übersprungen werden, so dass der Spieler mit den nächsten Paketen fortfahren kann. Eine andere Möglichkeit besteht darin, dass die Wiedergabe stoppt, bis Paket 8 eintrifft, was zu einer nervigen Unterbrechung der Musik oder des Films führt. In einer Live-Medienanwendung wird das Paket normalerweise übersprungen. Bei Streaming-Anwendungen kann die Wiedergabe eine Weile pausieren. Dieses Problem kann durch eine weitere Verzögerung der Startzeit durch Verwendung eines größeren Puffers gemildert werden. Bei einem Streaming-Audio- oder Videoplayer werden oft Puffer von etwa 10 Sekunden verwendet, um sicherzustellen, dass der Player alle Pakete (die nicht ins Netzwerk geworfen werden) rechtzeitig erhält. Live-Anwendungen wie Videokonferenzen erfordern kurze Puffer für die Reaktionsfähigkeit. Eine wichtige Überlegung für das regelmäßige Betrachten ist die Wiedergabepunkt, oder wie lange der Receiver auf das Medium warten soll, bevor er abgespielt wird. Die Entscheidung, wie lange gewartet werden soll, hängt von den Schwankungen ab. Die durchschnittliche Verzögerung zwischen hohem und niedrigem Jitter unterscheidet sich möglicherweise nicht sehr, aber bei hohem Jitter muss der Wiedergabepunkt möglicherweise viel weiter entfernt sein, um 99% der Pakete zu erfassen, als bei niedrigem Jitter.

(a) Viel Jitter. (b) Niedriger Jitter

Wiedergabepunkt auswählen

Um einen guten Wiedergabepunkt auszuwählen, kann die Anwendung den Jitter messen, indem sie die Differenz zwischen den RTP-Zeitstempeln und der Ankunftszeit misst. Jede Differenz ergibt eine Stichprobe der Verzögerung plus eine zufällige, feste Verschiebung. Die Verzögerung kann jedoch aufgrund unterschiedlichen konkurrierenden Verkehrs und sich ändernder Routen im Laufe der Zeit variieren. Um diese Änderung zu berücksichtigen, können Anwendungen ihren Wiedergabepunkt während der Ausführung anpassen. Wenn dies jedoch nicht ordnungsgemäß erfolgt, kann das Ändern des Wiedergabepunkts für den Benutzer zu einem spürbaren Schluckauf führen. Eine Möglichkeit, dieses Problem bei Audio zu vermeiden, besteht darin, den Wiedergabepunkt zwischen Sprints reden, in der Stille innerhalb eines Gesprächs. Niemand wird einen Unterschied zwischen einer kürzeren und einer längeren Stille bemerken. Zu diesem Zweck ermöglicht RTP Anwendungen, das M-Marker-Bit zu setzen, um zu diesem Zweck den Beginn eines neuen Talk-Sprints anzuzeigen. Ist die absolute Verzögerung bis zum Abspielen des Mediums zu groß, leiden Live-Anwendungen. Es kann nichts unternommen werden, um die Ausbreitungsverzögerung zu verringern, wenn bereits ein direkter Pfad verwendet wird. Der Wiedergabepunkt kann widerrufen werden, indem einfach akzeptiert wird, dass ein größerer Teil der Pakete zu spät zum Abspielen ankommt. Wenn dies nicht akzeptabel ist, besteht die einzige Möglichkeit zum Zurückziehen des Wiedergabepunkts darin, den Jitter zu reduzieren, indem ein besseres QoS, zum Beispiel durch den Notfall Weiterleitung differenzierter Service. Mit anderen Worten, es braucht ein besseres Netzwerk.

Verweise

• Tanenbaum, A. (2003). Computernetzwerke. Oberer Saddle River: Prentice Hall.
• Schulzrinne, H. (2003). RTP: Ein Transportprotokoll für Echtzeitanwendungen. Universität von Columbia. Abgerufen am 3. Dezember 2013. (RFC 3550)
• Lazzaro, J. (2006). RFC4571: Framing Real-time Transport Protocol (RTP) und RTP Control Protocol (RTCP) Pakete über verbindungsorientierten Transport. UC Berkeley. Abgerufen am 3. Dezember 2013. (RFC 4571)
• Perkins, C. (2003). RTP: Audio und Video für das Internet. Boston: Addison Wesley.