Multimediastreaming Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester 2003/04 Universität Jena vorgelegt von Tom Brauer Januar 2004
Abstract Die Übertragung von Multimediadaten in Echtzeit über das Internet stellt hohe Anforderungen an dieses selbst. Zeitkritische Parameter sind einzuhalten und eine Garantie der sicheren Übermittlung der Daten ist erwünscht. Deshalb sind zusätzliche Protokolle zur Unterstützung notwendig, die die Schwachstellen des herkömmlichen Internets in dieser Beziehung überwinden. In dieser Ausarbeitung werden im Einzelnen Lösungsmöglichkeiten dargeboten und deren Manifestierung in Protokollen aufgezeigt. Es werden das für das Streaming spezifizierte Transportprotokoll RTP und dessen integriertes Monitoringprotokoll RTCP sowie das Kontrollprotokoll RTSP bzgl. der Eigenschaften und Wirkungsweise erklärt. Darüber hinaus werden die beiden Protokolle RSVP und COPS zur Reservierung von Ressourcen im Internet vorgestellt. Nebenbei wird auf die Qualitiy of Service und deren mögliche Realisierung in Bezug auf Streaming eingegangen. Zum besseren Verständnis erfolgt zudem eine Erörterung der Funktionskomponenten von Streaming-Media, um die Zusammenhänge zwischen diesen und den vorgestellten Protokollen zu verdeutlichen. 1
Inhaltsverzeichnis 1 Einleitung 3 2 Multimedia im Internet 4 3 Anforderungen an das Internet 7 4 Funktionskomponenten bei Streaming-Media 8 5 Streaming-Protokolle und Verfahren 11 5.1 Übermittlung von Streams mit RTP 13 5.2 Überwachung der Stream-Übermittlung mit RTCP 15 5.3 Streaming-Media mit RTSP.. 16 6 Ressourcenreservierung und Dienstgüte (Quality of Service) 20 6.1 RSVP.. 21 6.2 COPS. 23 7 Zusammenfassung 25 A Glossar 26 B Wichtige Internetadressen 27 C Abkürzungen und Akronyme 28 Literaturverzeichnis 29 Index 30 2
1. Einleitung Live-Sportübertragungen verfolgen, obwohl die Fernsehsender ein anderes Programm vorsehen, oder sich mit Freunden aus aller Welt nicht nur per Telefon unterhalten, sondern auch sich visuell dabei sehen können - all dies macht das Internet heutzutage möglich. Eine Web-Seite, die mit Audio- und Videoangeboten aufwarten kann, wird als attraktiver und informativer eingeschätzt. Dies hat nicht nur zur Folge, dass der Besucher länger auf solchen Seiten verweilt. Es werden zudem die Popularität und damit die Anzahl der Page Visits 1 zunehmend gesteigert. Doch inwieweit bietet das Internet selbst schon Unterstützung für solche Anforderungen wie eine Live-Übertragung? Die Antwort klingt erst einmal ernüchternd: im Prinzip gar keine. Es werden also effektive Verfahren zur Übertragung von Audio und Video im Web zusätzlich benötigt. Schließlich will der User nicht drei Stunden bei der Übertragung warten, um sich letztendlich einen Film ansehen zu können, der eine Gesamtlänge von zehn Minuten aufweist. Wir werden Schritt für Schritt uns die notwendigen Grundlagen zum Thema Multimediastreaming erarbeiten und erfahren, welche theoretischen Möglichkeiten es gibt und wie diese in der Praxis umgesetzt werden. Dabei werden u.a. folgende Fragen behandelt und beantwortet: Was versteht man unter dem Begriff des Streamings? Welche Probleme treten bei der Übertragung von Echtzeit-Daten auf? Welche Lösungen gibt es dafür und welche Protokolle werden für das Streaming eingesetzt? Welche Komponenten spielen bei der Übertragung von Multimedia im Internet eine Rolle? Was für Möglichkeiten hat man, um im Voraus abzusichern, dass die Übertragung relativ gut gelingen wird? Die nachfolgenden Kapitel werden diesen Fragen auf den Grund gehen. Kapitel 2 beschäftigt sich mit Grundbegriffen zu diesem Gebiet und macht den Leser mit dem Thema vertraut. In Kapitel 3 werden wir konkrete Anforderungen an das Internet formulieren und die damit verbun- 1 Page Visits: eindeutig identifizierbarer Besucher auf der Internetseite 3
denen Probleme aufzeigen. Die entsprechenden Lösungen und ein kleiner Ausblick auf die so genannte Dienstgüte runden dieses Kapitel ab. Welche Funktionskomponenten für die Übertragung von Streaming-Media vonnöten sind, wird in Kapitel 4 erörtert. Kapitel 5 widmet sich der Umsetzung in der Praxis, sprich den Protokollen für das Streaming. Die bereits angedeutete Dienstgüte wird zusammen mit der Ressourcenreservierung und den dazugehörigen Protokollen im 6. Kapitel ausführlich behandelt. Als Abschluss beinhaltet Kapitel 7 eine Zusammenfassung, um die wesentlichen Aspekte nochmalig zu betonen. 2. Multimedia im Internet Internet-Radio, Internet-Telefonie, Videokonferenzen, Teleteaching, interaktive Spiele - das sind alles Beispiele für so genannte kontinuierliche Medienanwendungen, die über das Internet realisiert werden. Kontinuierlich bedeutet, dass fortlaufend Informationen geliefert werden. Daher ist eine relativ schnelle Übertragung von großen Bild-, Audio- und Videodaten notwendig. Diese wird vor allem durch die stetig steigende Bandbreite im Netzwerk realisiert. Um weiter in das Gebiet des Multimediastreamings einzudringen, ist es erst einmal von Nutzen, grundlegende Begriffe zu klären. Streaming bedeutet die kontinuierliche Wiedergabe eines entfernten Multimedia-Inhaltes. Dabei ist zu beachten, dass die Wiedergabe bereits während der Übertragung stattfindet. Man spricht auch davon, dass die Übertragung und Darstellung der Daten in Echtzeit (Real Time) erfolgt. Zum Beispiel kann der User somit bereits den Anfang eines Filmes sehen, obwohl die ganze Filmdatei noch nicht vollständig empfangen wurde. Ermöglicht wird dies allgemein durch eine Pufferung der Daten, d.h. es wird zunächst gewartet, bis eine gewisse Menge von Daten, welche zwischengespeichert werden, eingetroffen ist, und danach die Wiedergabe gestartet. Kapitel 3 geht darauf ausführlich ein. Unter Streaming-Media versteht man die Erzeugung, die gleichzeitige Übertragung und unmittelbare Wiedergabe von verschiedenen Medien (Audio, Video, Daten). Es können folgende Eigenschaften von Streaming-Media im Überblick festgestellt werden: Der übertragene Medienstrom ist kontinuierlich. 4
Es erfolgt zunächst kein komplettes Herunterladen des Medienstroms. Der Medienstrom wird in der Regel unmittelbar wiedergegeben. Der Medienstrom ist kontrollierbar, z.b. um vor- bzw. zurückzuspulen. Man unterscheidet prinzipiell drei Klassen von kontinuierlichen Multimedia-Anwendungen. Wie wir sehen werden, steigen mit jeder Klasse die Möglichkeiten der Interaktion und zeitgetreuen Darstellung, aber natürlich auch die Anforderungen an das Internet. Dies ist nicht verwunderlich, denn je höher die Qualität sein soll, desto mehr Aufwand muss geleistet werden. Die Klasseneinteilung im Überblick: Streaming von gespeicherten Audio- und Video-Datenströmen Streaming von Live Audio- und Video-Datenströmen Interaktives Echtzeit-Audio und -Video Beim Streaming von gespeicherten Audio- und Video-Datenströmen geht es darum, dass die vom Nutzer gewünschte Datei bereits vollständig auf einem Server 1 abgespeichert ist und dort komprimiert vorliegt. Dadurch, dass die gesamte Datei schon existiert, kann der Nutzer beliebig in dieser navigieren (z.b. Anhalten, Vorwärtsspulen). Der Vergleich zu einem Musikalbum auf einer CD liegt nahe. Dort kann man ebenfalls beliebig zwischen den einzelnen Titeln wählen und innerhalb eines Titels spulen. Auch wenn wiederum eine durchgängige, kontinuierliche Darstellung der gerade übertragenen Datei erfolgt, sind die Zeitbedingungen hier nicht so kritisch. Kurzweilige Verzögerungen im Sekundenbereich (1 bis 10 Sekunden) sind für den Nutzer relativ akzeptabel. Bei Videokonferenzen, die, wie wir später sehen werden, zur 3. Klasse gehören, wäre dies nicht mehr vertretbar. Man spricht bei diesem Vorgang, dass der Streaming-Server zunächst den Stream abspeichert und später an den Empfänger weitergibt, auch von einem on-demand-stream. Ein Beispiel dafür ist in Abbildung 1 zu sehen. 1 Der Begriff des Servers wird in Kapitel 4 näher erläutert. 5
Abb. 1. Die Seite www.pixar.com bietet Heimkino für zu Hause. Streaming von Live Audio- und Video-Datenströmen kann mit einer herkömmlichen Radio- oder Fernseh-Liveübertragung verglichen werden. Die Multimedia-Daten werden direkt während ihrer Aufzeichnung über das Internet übertragen. Klar ist, dass der Datenstrom erst mit einer geringen Verspätung beim Nutzer dargestellt werden kann, da Verzögerungen der Dateneinheiten auf Grund des Sendens durch eine Pufferung ausgeglichen werden müssen. Heimtückisch ist hierbei, dass man in der Regel nicht davon ausgehen kann, dass die Daten immer in festen Zeitabständen nacheinander eintreffen. Im nächsten Kapitel werden wir nochmals darauf zu sprechen kommen. Bedenken wir, dass normalerweise mehrere Nutzer denselben Live- Stream empfangen wollen, könnte man doch die Daten gleichzeitig an mehrere Empfänger senden. Dieses Verfahren wird als Multicasting bezeichnet. Es wird also eine unnötige Replizierung der Datenpakete vermieden, wodurch das Netzwerk weniger überlastet wird. In Analogie dazu sehen auch mehrere Zuschauer dasselbe Fußballspiel live im Fernsehen, obwohl die Informationen nur einmal von einer Senderstation ausgestrahlt werden. Wir halten ebenfalls fest, dass diese Klasse von kontinuierlichen Multimedia-Anwendungen schon zeitkritischer ist als die vorher besprochene. Schließlich möchte man ein Ereignis bei einer angeblichen Liveübertragung nicht erst Minuten später erleben. Internet-Telefonie oder Videokonferenzen sind Beispiele für die Kategorie interaktives Echtzeit-Audio und -Video. Videokonferenzen erlau- 6
ben die visuelle und verbale Kommunikation von Anwendern über das Internet. Hierbei sind zeitliche Restriktionen bzgl. Verzögerungen besonders streng. Ein akzeptabler Zeitkorridor für Verzögerungen bewegt sich daher nur im Millisekundenbereich. 3. Anforderungen an das Internet Anwendungen zur Übertragung von Audio- und Videodaten werden oft als Echtzeit-Anwendungen (Real Time Applications) bezeichnet, da sie eine zeitgerechte Übertragung und Darstellung erfordern. Zudem ist Interaktivität erwünscht, d.h. der Nutzer soll selber aktiv entsprechend seiner Wünsche in das Geschehen eingreifen können. Leider bietet das Internet in seiner reinen Form keinerlei Unterstützung dafür. Im Folgenden werden einige Probleme aufgelistet, die bei der Übertragung von Daten über das Internet entstehen können: Datenpaketverluste, d.h. eigentlich zu übertragene Daten kommen erst gar nicht beim Empfänger an. Datenpakete können dupliziert werden, was sich störend auf die Wiedergabe des Medienstroms auswirken kann. Es gibt keine Garantie einer Mindestverzögerung beim Empfangen der Daten. Die Anlieferung der Datenpakete ist starken Schwankungen unterworfen (Jitter). Eintreffende Datenpakete können in verkehrter Reihenfolge sein. Wir sehen somit, dass eine qualitativ hochwertige Wiedergabe eines Medienstroms ohne zusätzliche Maßnahmen nicht garantiert werden kann. Allein die Tatsache, dass die Datenpakete irgendwann einmal oder im Extremfall gar nicht beim Empfänger ankommen können, erschwert zum Beispiel eine Videokonferenz so erheblich, dass die ganze Idee eigentlich gar nicht realisiert werden kann. Wir benötigen also Garantien darüber, dass ein Datenpaket nicht nur sicher ankommt, sondern auch noch innerhalb gewisser Zeitschranken. Jene Überlegung führt zum Begriff der Dienstgüte (Quality of Service). Laut Steinmetz kennzeichnet Dienstgüte das definierte, kontrollierbare Verhalten eines Systems bezüglich quantitativ messbarer Parameter. In unserem Fall ist das System das Internet, von dem wir erwarten, dass es 7
uns entsprechende Zusicherungen machen kann. Doch kann das durch bereits bestehende Verfahren im Internet nicht realisiert werden. Wir brauchen daher sowohl theoretische Lösungsansätze als auch praktische Überlegungen, was sich letztendlich in zusätzlichen Protokollen für das Streaming manifestiert. Um die obig aufgeführten Probleme bei der Übertragung im Internet zu überwinden, bieten sich die nachfolgenden Lösungen an: Sequenznummern für jedes Datenpaket Somit können Datenpaketverluste und doppelte Datenpakete sofort erkannt werden und es wird eine Rekonstruktion der Originalreihenfolge des Datenstroms ermöglicht. Zeitstempelinformation für jedes Datenpaket Die zeitlich getreue Wiedergabe eines Datums wird damit gewährleistet. Wiedergabe-Puffer (Playback Buffer) Temporäre Speicherung der eintreffenden Daten führt dazu, dass Schwankungen in der Übertragungsverzögerung einzelner Datenpakete ausgeglichen werden können. Ressourcenreservierung Durch Protokolle wird vor der Übertragung der Daten sichergestellt, dass genügend Netzwerkressourcen (Bandbreite) zur Verfügung stehen, um (siehe Kapitel 6). Es ist die Aufgabe von Protokollen, die wir im 5. und 6. Kapitel kennen lernen werden, sich um Sequenznummern, Zeitstempelinformationen und Ressourcenreservierung zu kümmern. Dagegen wird der Wiedergabe-Puffer durch die so genannten Media-Player 1 realisiert. 4. Funktionskomponenten bei Streaming-Media In diesem Kapitel wollen wir uns anhand des Beispiels einer Audio- /Video-Übertragung klar machen, welche Funktionskomponenten bei der Übertragung von Streaming-Media zum Einsatz kommen. Zunächst müssen einige Begriffe erläutert werden, die auch für das Verständnis der nachfolgenden Kapitel nötig sind. 1 Media-Player: siehe Kapitel 5.3 8
Das Client/Server-Prinzip ist ein wichtiges Verfahren beim Streaming. Ein Client ist ein Programm, das einen Server kontaktiert und Informationen anfordert. In unserem Fall ist ein Media-Player ein Beispiel dafür. Der Media-Player fordert Multimediadaten über Streaming von einem Media-Server an. Nachdem wir uns mit den Fachbegriffen Client und Server vertraut gemacht haben, können wir jetzt zu unserem Beispiel Streaming-Media über das Internet zurückkehren. Ein Media-Server besteht aus einem Web-Server und eines Streaming-Servers. Der Streaming-Server nimmt die eingehenden Streams auf und speichert sie. Die Aufgabe des Web- Servers besteht darin, die Präsentation der Streams über den Web-Dienst zu übernehmen. Folgender Ablauf ist wesentlich: Stream-Erzeugung Das von einer Kamera oder einem Mikrophon eingegebene Signal wird vom Media-Encoder in ein Streaming-Format konvertiert und in der Regel komprimiert. Der somit erzeugte Stream wird auf den Media-Server übertragen. Im Falle der sofortigen Weiterleitung spricht man von einem Live-Stream (siehe Streaming von Live Audio- und Video-Datenströmen in Kapitel 2). Wird der Stream auf dem Media-Server abgespeichert und später von einem Client abgerufen, so nennt man dies einen on-demand-stream. Der Abruf des Streams passiert typischerweise über das Internet mittels Web-Dienst. Dabei wählt der Empfänger in der Regel einen auf einer Web-Seite präsentierten Stream aus. Dieser wird über das Internet zum Empfänger übertragen und dargestellt, wobei der Stream vorher wieder dekomprimiert werden muss. Die Erzeugung von Streaming-Media wird in Abbildung 2 im Detail aufgezeigt. Das von außen analoge Signal (z.b. Sprache) wird zunächst digitalisiert. Der daraus erzeugte Bitstrom wird schließlich über den Kodierer, auch häufig als Codec bezeichnet, in ein vorgegebenes Format überführt, so dass ein Stream entsteht. Der Kodierer komprimiert oft den Bitstrom zusätzlich, um die erforderliche Bandbreite zu reduzieren. Danach wird für die Übertragung an den Media-Server der Stream in einzelne Segmente als Portionen aufgeteilt und für die Übermittlung in Pakete eines Stream-Transportprotokolls eingebettet. Ein solches Stream-Transportprotokoll stellt z.b. das Real-Time Transport Protocol (RTP) dar 9
(siehe Kapitel 5.1). Je nach Art des Streams erfolgt der Abruf vom Media-Server entweder als Live-Stream oder als on-demand-stream. Media-Server Live Format Kodierer ondemand Stream-TP Digitalisierer Media-Encoder Signal Abb. 2. Funktionskomponenten bei der Erzeugung von Streaming-Media Der auf dem Web-Server abgespeicherte Stream wird nun entweder als Unicast oder als Multicast zum Empfänger, dem Media-Player gesendet. Die Datenpakete werden in einem Puffer zwischengespeichert und anschließend dekodiert. Letztendlich kann der Stream wiedergegeben werden. Abbildung 3 verdeutlicht diesen Vorgang. Dekodierer Puffer Media-Server Wiedergabe Format Stream-TP Unicast Multicast Media-Player Abb. 3. Funktionskomponenten beim Abruf von Streaming-Media Für die Lieferung eines Streams an den Empfänger können zwei Verfahren verwendet werden: Unicasting Übertragung des Streams separat an jeden Empfänger (benötigte Bandbreite steigt linear mit Anzahl der Empfänger). 10
Multicasting Übertragung des Streams gleichzeitig an mehrere Empfänger (benötigte Bandbreite unabhängig von der Anzahl der Empfänger). Während beim Unicasting der Empfänger selbst die Zieladresse für die Datenübertragung darstellt, bekommen beim Multicasting die Empfänger desselben Streams die Absenderadresse und die Portnummer zugewiesen. 5. Streaming-Protokolle und Verfahren Im Kapitel 3 wurden theoretische Lösungen aufgeführt, die die Schwachstellen des Internet überwinden sollen. Jene Ansätze müssen nun durch zusätzliche Protokolle umgesetzt werden, die sowohl den Datenverkehr im Internet in den strengen Zeitschranken abwickeln als auch den Übertragungsvorgang überwachen und Steuerungsmanipulation des Datenstroms erlauben. Deshalb unterscheidet man bei Streaming-Protokollen drei Arten mit der jeweiligen Aufgabe: Transportprotokolle: Übermittlung von Streams Monitoringprotokolle 1 : Überwachung der Stream-Übermittlung Kontrollprotokolle: Kontrolle des Medienstroms durch Anwender (z.b. Zurückspulen) Im Konkreten werden wir als Transportprotokoll für die Übermittlung von Echtzeitdaten das Real-Time Transport Protocol (RTP) im Kapitel 5.1 genauer untersuchen. Das zu RTP zugehörige Monitoring-Protokoll, das so genannte Real-Time Transport Control Protocol (RTCP), wird Kapitel 5.2 erläutern. Das Real-Time Streaming Protocol (RTSP) ermöglicht mit Hilfe eines Media Players die Streamkontrolle, d.h. der Anwender kann abhängig von der Art (siehe Klasseneinteilung in Kapitel 2) innerhalb des Streams navigieren. Wir werden darauf in Kapitel 5.3 eingehen. Bei den Begriffen Monitoring- und Kontrollprotokoll ist Vorsicht geboten, da hier leicht eine Verwechslung auftreten könnte. 1 Der Begriff monitoring bedeutet soviel wie Überwachung 11
HTTP RTSP RTP RTCP TCP UDP IP Abb. 4. Zusammenhang zwischen den Protokollen für Streaming-Media Abbildung 4 illustriert, wie die verschiedenen Streaming-Protokolle voneinander abhängen und welche Protokolle aus der TCP/IP 1 - Protokollfamilie sie in Anspruch nehmen. Es werden im Folgenden nur Eigenschaften dieser Protokolle aufgeführt, die für unser Gebiet wichtig sind. Es wird also nicht nötig sein, diese Protokolle im technischen Detail wissen zu müssen. Die Übermittlung von Streams (Audio, Video) stellt eine Form der Echtzeitkommunikation dar, bei der keine wiederholte Übertragung von verloren gegangenen Stream-Segmenten in Frage kommt. Eine Begründung dafür ist, dass bei einem Live-Stream letztendlich doch noch empfangene Daten nutzlos geworden sind, weil sie beispielsweise 30 Sekunden früher gebraucht wurden. Daher eignet sich das IP-Transportprotokoll TCP wenig, da bei diesem verloren gegangene Datenpakete wiederholt übertragen werden müssen. Deshalb erfolgt der Einsatz des IP-Transportprotokolls UDP 2, da es keine wiederholten Übertragungen voraussetzt. Ein weiterer wichtiger Vorteil von UDP ist, dass viel geringe Verzögerungszeiten als bei TCP vorliegen. Genau diese Eigenschaft brauchen wir ja, da die Datenpakete beim Streaming so schnell wie möglich übertragen werden sollen. Normalerweise sendet bei einer Datenübertragung der Empfänger an den Absender eine Bestätigung (Quittung) darüber, welche Datensegmente ordnungsgemäß angekommen und welche verloren gegangen sind. Jedoch wird dies bei der Übermittlung von Echtzeitdaten nicht getan. Der Sender eines Streams hätte somit keine Information über die Tatsache, ob 1 TCP: Transmission Control Protocol, IP: Internet Protocol 2 User Datagram Protocol 12
die Daten überhaupt den Empfänger erreichen und wenn ja, in welcher Qualität bzgl. der Übertragungszeit usw. Somit ist ein Monitoringprotokoll notwendig, dass Sender und Empfänger dazu befähigt, sich gegenseitig über die Lage der Übermittlung eines Streams zu berichten. Aus Abbildung 4 ist ersichtlich, dass das Kontrollprotokoll RTSP sowohl TCP als auch UDP nutzen kann. Was letztendlich verwendet wird, hängt von den gewünschten Eigenschaften ab, ob die Kontrollnachrichten entweder sicher oder schnell ankommen sollen. 5.1 Übermittlung von Streams mit RTP Für die Übermittlung von Streaming-Media über IP-Netze lassen sich die für die klassische Datenkommunikation konzipierten Protokolle nicht einsetzen. Deshalb wurde das Protokoll RTP (Real-Time Transport Protocol) speziell für die Übertragung von Echtzeitdaten wie Audio und Video über IP-Netze entwickelt. Folgende Besonderheiten von RTP sind für das Streaming relevant: Übermittlung eines Streams als eine zusammenhängende Folge von RTP-Dateneinheiten über eine RTP-Session (RTP-Sitzung). Sequenznummer und Zeitstempel werden für jedes zu übertragende Datenpaket vermerkt. RTP übermittelt unterschiedliche Formate von Streams. RTP bietet die Möglichkeit verschiedene Datenströme aus Effizienzgründen zusammenzumischen (z.b. bei Videokonferenzen). Wie wir bereits in Kapitel 3 gesehen haben, garantieren Sequenznummern die korrekte Reihenfolge der Dateneinheiten und ermöglichen die Erkennung eines Datenpaketverlustes. Die Zeitstempel sorgen dafür, dass der Empfänger die erhaltenen Datenpakete zeitgerecht wiedergeben kann. Um diese zusätzlichen Informationen an jedes einzelne Stream-Segment anzuheften, bekommen diese jeweils einen RTP-Header 1, der die Informationen enthält. Abbildung 5 zeigt die allgemeine Struktur einer RTP- Dateneinheit im IP-Paket. Analog zum RTP-Header fügen die Protokolle UDP und IP ihre jeweiligen spezifischen Header an das bereits beste- 1 Header: Dateikopf 13
hende Datenpaket an. Die einzelnen Informationen in jenen beiden Headern soll uns hier nicht weiter interessieren. Allerdings werden wir den RTP-Header im Detail untersuchen. IP UDP RTP RTP-Payload RTP-Dateneinheit Abb. 5. RTP-Dateneinheit im IP-Paket Der RTP-Header umfasst im Wesentlichen folgende Angaben (siehe Abb. 6): Nutzlasttyp (Payload Type): Spezifiziert den Typ der beförderten Daten (z.b. Audio, Video) und deren Format. Vom Typ ist auch die Interpretation der restlichen Headerfelder abhängig. Zeitstempel (Time Stamp): Markiert den Zeitpunkt der Aufzeichnung der Nutzlast. Der erste Zeitstempel einer Sequenz wird zufällig bestimmt. Sequenznummer (Sequence Number): Enthält die jeweilige Sequenznummer des Datenpakets. Die erste Sequenznummer einer neuen Sequenz wird zufällig ermittelt. Synchronization Source Identifier (SSI): Identifiziert den Sender eines Datenstroms (bei zusammengemischten Datenströmen: Identifikation des Mixers). Contributing Source ID: Optionales Feld für die Angabe der Original-Quellen bei zusammengemischten Datenströmen (siehe SSI). Nutzlasttyp (7 Bit) Sequenznummer (16 Bit) Zeitstempel (32 Bit) SSI (32 Bit) Verschiedene Felder (9 Bit) Abb. 6. Die Felder eines RTP-Headers mit zugehöriger Bitlänge 14
5.2 Überwachung der Stream-Übermittlung mit RTCP Für die Überwachung des Verlaufs der Übermittlung eines Streams über RTP ist ein Monitoringprotokoll nötig. Hierfür verwendet man das Protokoll RTCP (Real-Time Transport Control Protocol), das integraler Bestandteil von RTP ist. Über RTCP können die beteiligten Kommunikationspartner Informationen über die vermittels RTP transportierten Daten oder Reports zur aktuellen Leistung der zu Grunde liegenden Netzwerkinfrastruktur austauschen. Es werden somit Kontroll- und Statusinformationen zwischen den Teilnehmern einer RTP-Session übertragen. RTCP verwendet als Transportprotokoll UDP, d.h. es wird Wert darauf gelegt, dass die Informationen schnell ankommen. Die wichtigste Aufgabe des RTCP ist die Überwachung des Verlaufs der Übermittlung. Dafür werden zusätzliche austauschbare Informationen über die stattfindende Übertragung benötigt, die in fünf verschiedenen RTCP Basis-Nachrichtentypen implementiert sind (siehe Tabelle 1). Typ Bedeutung 200 Report des Senders 201 Report des Empfängers 202 Beschreibung der Nachrichtenquelle 203 Abmeldung (Bye-Message) 204 anwendungsspezifische Nachricht Tabelle 1. RTCP Basis-Nachrichtentypen Report des Senders Für jeden RTP-Strom, den ein Sender überträgt, erstellt und überträgt er RTCP-Berichtspakete. Diese Pakete beinhalten folgende Informationen über den RTP-Strom: o Die SSI des RTP-Stroms. o Den Zeitstempel und die Uhrzeit des zuletzt erzeugten RTP-Pakets eines Stroms. Die Uhrzeit ist ein unabhängiger absoluter Zeitstempel, der nötig ist, um mehrere Datenströme zu synchronisieren. o Die Anzahl der im Strom gesendeten Pakete. o Die Anzahl der im Strom gesendeten Bytes. 15
Report des Empfängers Der Empfänger informiert den Sender mit diesem Report über die Qualität der empfangenen Datenströme. Der Empfangsbericht umfasst folgende Felder: o Die SSI des RTP-Stroms, für den der Report bestimmt ist o Der Anteil der verlorenen Pakete eines RTP-Stroms seit dem letzten Report. o Die letzte von einem RTP-Paketstrom empfangene Sequenznummer. o Einem Jitter-Wert, der aus den Abweichungen der Ankunftszeiten der eintreffenden Datenpakete fortlaufend aktualisiert wird. Beschreibung der Nachrichtenquelle Textuelle Informationen über den Absender des Multimedia-Datenstroms (z.b. Name des Senders). Anwendungsspezifische Nachricht Frei zu definierende Erweiterung des über RTP gesendeten Nachrichtentyps. Abmeldung Sender beendet Übertragung des Datenstroms und signalisiert dies seinen Empfänger mit Hilfe dieser RTCP-Meldung. Anzumerken ist noch, dass RTCP-Pakete periodisch gesendet werden und eine wichtige Grundlage für Diagnosezwecke bilden. Beispielsweise kann der Sender auf Grund des Empfängerreports seine Übertragungsrate ändern. Ferner wird parallel zu einer RTP-Session ein Monitoringkanal eingerichtet, in dem die Informationen zwischen Sender und Empfänger ausgetauscht werden. 5.3 Streaming-Media mit RTSP Im Rahmen des Audio- und Video-Streaming können sich Clients komprimierte Multimedia-Daten von speziellen Streaming-Servern anfordern. Über das RTP erfolgt eine segmentierte Übertragung der angeforderten Daten. Eine gute Verbindung vorausgesetzt, ist der Empfänger in der Lage, die Wiedergabe nach ein paar Sekunden zu starten, obwohl die Übertragung aller Daten noch nicht abgeschlossen ist bzw. noch läuft. Darüber hinaus kann der Client bereits während der Übertragung in einem gewissen Umfang innerhalb der übertragenen Daten navigieren. Wir benötigen also ein Kontrollprotokoll, das die Kontrolle des Medienstroms durch den Anwender erlaubt. Somit kann dieser beispielsweise zurück- 16
spulen oder die Wiedergabe stoppen und wieder aufnehmen. RTSP (Real-Time Streaming Protocol) ist ein solches Protokoll, was die Interaktion zwischen Client und Server ermöglicht. Man kann deshalb auch die Bezeichnung Client-Server-Protokoll verwenden. Zu den Hauptaufgaben von RTSP zählen: Anforderung eines Medienstroms vom Streaming-Server Der Client fordert zunächst eine Medienbeschreibung vom Server über HTTP 1 oder ein anderes geeignetes Protokoll an. Danach erfolgt die Unterscheidung, ob der Datenstrom als Uni- oder Multicast übertragen werden soll. Im Falle des Unicasting stellt der Empfänger die Zieladresse für die Übertragung des Mediendatenstroms bereit. Beim Multicasting bekommt der Empfänger die für den Datenstrom zu verwendenden Multicast-Adressen und Portnummern. Einladung eines Medien-Servers zu einer Konferenzschaltung Um entweder selbst einen Datenstrom beizusteuern oder um Datenströme der Konferenz aufzuzeichnen, kann ein Medien-Server in eine bereits laufende Konferenz mit eingeladen werden. Ein wichtiges Anwendungsgebiet betrifft den Bereich des Teleteachings. Medien zu einer bestehenden Übertragung hinzufügen Speziell im Falle von Live-Streaming-Anwendungen ist es für den Client von Vorteil zu wissen, ob während der Übertragung bereits andere Medieninhalte zur Verfügung stehen, die ebenfalls übertragen werden könnten. Analog zum RTCP gibt es beim RTSP ebenfalls Nachrichten. Der Client stellt eine Anfrage (Request) an den Server, welche dieser in einer entsprechenden Antwort oder Aktion beantwortet (Response). Die folgenden Kommandos zur Steuerung der Darstellung eines Multimedia-Datenstroms beinhaltet RTSP: SETUP Ressourcenreservierung durch Server und Start der RTSP-Sitzung PLAY Abruf eines Streams vom Server nach erfolgreich durchgeführten SETUP 1 Hypertext Transfer Protocol 17
RECORD Aufnahme eines Streams auf den Server PAUSE kurzzeitige Unterbrechung der Datenübertragung (ohne Freigabe der allozierten Ressourcen) TEARDOWN Ressourcenfreigabe durch Server und Abbau der RTSP-Sitzung ( Herunterfahren ) Des Weiteren bietet RTSP u.a. folgende Abfragemöglichkeiten an den Server: OPTIONS Abfrage der Fähigkeiten des Servers, inwieweit dieser überhaupt Anfragen (Requests) versteht DESCRIBE Abfrage der Stream-Beschreibung (z.b. Länge) Weiterhin kann der Server dem Client unter zu Hilfenahme des Requests REDIRECT mitteilen, dass der Client den von ihm gewünschten Stream von einem anderen Server abrufen soll. Nun ist es langsam an der Zeit die so genannten Media-Player aufzuführen. Media-Player unterstützen viele Aspekte, die in den vorangegangenen Kapiteln erläutert wurden, einschließlich RTSP-Anfragen. Normalerweise bewegt man sich via WWW-Browser 1 durch das Internet. Diese unterstützen jedoch nicht alle die mit dem Streaming verbundenen Anforderungen. Deshalb ist zusätzliche Unterstützung durch Helper-Applications (Plugins) notwendig, damit der Empfänger streaming-fähig wird. Media-Player, wie zum Beispiel der Real Player von RealNetworks, Microsoft Windows Media Player oder QuickTime Player, stellen solche Plugins dar. Folgende Funktionen führen Media-Player aus: Kontaktieren als Client einen Streaming-Server. Sorgen für die Übertragung und Wiedergabe der angeforderten Multimedia-Datenströme. Dekomprimierung der übertragenen Audio- und/oder Videodaten. 1 Beispiele für Browser sind der Microsoft Internet Explorer oder Netscape Navigator 18
Verwaltung eines Playback Puffers zum Ausgleich des Jitter-Effekts. Fehlerkorrektur bei Datenpaketverlust: Es gibt Möglichkeiten von der Neuübertragung der Daten (falls es sich in den engen Zeitschranken überhaupt lohnt) bis hin zu interpolativen Verfahren, die teilweise eine Rekonstruktion der fehlenden Informationen erlauben. Bereitstellung einer grafischen Benutzeroberfläche zur Steuerung von Übertragung und Darstellung. Dabei werden unter anderem die oben aufgeführten RTSP-Kommandos zur Steuerung der Darstellung eines Multimedia-Datenstroms mit implementiert. Die Bedienung eines Media-Players kann mit der Bedienung eines CD- Players verglichen werden. Der Nutzer braucht sich selbst nicht über die einzelnen technischen Aufgaben, wie beispielsweise der Verbindungsaufbau zum Streaming-Server, kümmern. Die Navigation innerhalb eines Streams wird ebenfalls durch virtuelle Tasten wie Play erleichtert. <SMIL> </SMIL> <BODY> <AUDIO SRC= rtsp://realserver.example.com/one.rm > <IMG SRC= image/realimg.gif > <VIDEO SRC= video/example.rm > <TEXT SRC= beschreibung.txt > </BODY> Abb. 7. Beispiel für die Sprache SMIL Ergänzend zu RTSP sei noch angemerkt, dass es sich hierbei um ein so genanntes Out-of-Band-Protokoll handelt, d.h. RTSP verläuft parallel zur Übertragung von Streams mit Hilfe von RTP und RTCP. Dadurch ist es mit dem RTSP möglich, die Übermittlung von mehreren parallelen Streams zu kontrollieren und zu synchronisieren. Speziell für diese Aufgabe wurde die Synchronized Multimedia Integration Language (SMIL) spezifiziert. SMIL ist analog zu HTML 1 eine einfache Markup- Sprache, die eine synchrone Übertragung mehrerer Audio-, Video- oder auch Text-Datenströme und eine entsprechende Darstellung beim Client ermöglicht. Ein kleines Beispiel ist dazu in Abbildung 7 angegeben. 1 Hyper Text Markup Language 19
6. Ressourcenreservierung und Dienstgüte (Quality of Service) Wie wir bereits in Kapitel 3 erfahren haben, bietet ein IP-basiertes Netzwerk keinerlei Garantien über einzuhaltende Dienstgüteparameter. Es scheint sich ein Dilemma zwischen der Dienstqualität (Quality of Service - QoS) und dem IP aufzutun. Allgemein werden drei Dienstgüteklassen unterschieden: Best-Effort-Dienste Dienste, die keine Garantien ermöglichen Vorhersagbare Dienste Grenzwerte der Dienstgüteparameter sind Schätzungen des vergangenen Verhaltens, die der Dienst auch zukünftig zu erfüllen anstrebt Garantierte Dienste stellen QoS-Garantien zur Verfügung Es werden noch einmal die wesentlichen Schwachstellen bzgl. der Übertragung von Echtzeitdaten über das herkömmliche Internet und dem zugrunde liegenden Protokoll IP aufgelistet: Keine Garantie über bestimmte Latenzzeiten eines übertragenen Datenpakets, d.h. es kann im Voraus nicht bestimmt werden, wie lange die Übertragung des Datenpakets dauern wird Keine Garantie über das Ankommen eines Datenpakets beim Empfänger Keine Garantie über die richtige Reihenfolge der empfangenen Pakete Probleme wie das zuletzt aufgeführte können wir im Nachhinein auflösen. Das Schlüsselwort hierbei waren Sequenznummern, welche über das Protokoll RTP realisiert werden (siehe Kapitel 5.1). Die beiden ersten Probleme sind durch solche Methoden nicht lösbar. Es ist also bisher meistens nur Fehlererkennung möglich (z.b. Paketverlust), jedoch nicht Fehlerbehebung (z.b. Wiederherstellung der richtigen Reihenfolge der Datenpakete durch Sequenznummern). 20
Das Internet gehört somit zur Klasse der Best-Effort-Dienste. Doch wie können wir über diesen mache es so gut wie möglich - Ansatz hinausgelangen? Die entscheidende Idee ist die Vorabreservierung von Ressourcen im Internet, sprich Bandbreite. Die somit zur Verfügung stehenden Ressourcen sollen die Quality of Service gewährleisten. Wiederum werden hierfür zusätzliche Protokolle benötigt, die genau das umsetzen. Wir werden die beiden Protokolle Resource Reservation Protocol (RSVP) in Kapitel 6.1 und Common Open Policy Services (COPS) in Kapitel 6.2 auf Eigenschaften untersuchen und anschließend die gemeinsame Arbeitsweise erklären. Zunächst müssen wir aber festhalten, dass diese beiden Protokolle gewisse Voraussetzungen an die Netzhardware stellen. Diese Anforderungen sind: Router müssen dazu fähig sein, Garantien darüber anzugeben, dass bestimmte Bandbreiten für eine Reservierung zur Verfügung stehen. Traffic Pollicing Router überwachen den gesamten Datenverkehr und gegebenenfalls steuernde Eingriffe vornehmen. Traffic Shaping Es müssen geeignete Warteschlangenmechanismen bei Routern vorhanden sein, um eine auftretende Überlast abzuschwächen und auszugleichen. Jeder Router auf dem Übertragungsweg muss den Anforderungen (notwendige Bandbreite) seitens des Servers und Clients zustimmen und entsprechen. 6.1 RSVP Wie im vorangehenden Abschnitt beschrieben wurde, ist ein Signalisierungsprotokoll 1 erforderlich, das es den auf Hosts 2 laufenden Anwendungen ermöglicht, Ressourcen (Bandbreite) im Internet zu reservieren, damit ein Netzwerk QoS-Zusicherungen gewähren kann. Ein solches Signalisierungsprotokoll für das Internet ist RSVP. Klar sollte sein, dass RSVP vor der eigentlichen Übertragung eines Multimedia-Datenstroms 1 Signalisierungsprotok. stammt aus dem Jargon des vermittelten Telefonnetzbereichs 2 Server in einem Netzwerk, der Rechenzeit, Speicherkapazität, Daten oder andere Dienstleistungen zur Verfügung stellt 21
abläuft. Denn sobald die Übertragung gestartet wurde, kann über RSVP nicht mehr eingegriffen werden. Die wichtigsten Eigenschaften von RSVP sind: RSVP ist empfängerorientiert, d.h. der Empfänger eines Datenflusses leitet die Ressourcenreservierung ein. RSVP arbeitet unidirektional, d.h. die Reservierung erfolgt nur in eine Richtung der Datenverbindung. Möchte der andere Kommunikationspartner ebenfalls Ressourcen für die entgegengesetzte Richtung reservieren, wird nicht unbedingt derselbe Verbindungsweg gewählt. RSVP ist multicastorientiert. Ein Unicast wird als degenerierter Fall vom Mulicast behandelt. Es gilt das so genannte Soft State Prinzip in der Praxis: Die Ressourcenreservierung ist zeitlich begrenzt. Empfänger müssen daher periodisch neue Anfragen zur Ressourcenreservierung vornehmen, wenn sie die Reservierung behalten wollen. Ein wichtiges Problem beim Versenden der Datenströme ist, dass die Empfänger heterogen bzgl. ihrer Empfangsraten sind. Einige Empfänger besitzen höhere Bandbreiten und sind somit potenziell in der Lage, Multimediaströme höherer Qualität zu empfangen. Dagegen ist eine geringere Qualität für solche Empfänger empfehlenswert, die niedrige Bandbreiten vorweisen. Was macht man aber bei einem Multicast, der von beiden Gruppen empfangen wird? Wird ein niedrig qualitativer Datenstrom übertragen, kann jeder diesen ohne große Probleme empfangen. Dies wäre aber ein schlechter Kompromiss für die bzgl. der Bandbreite besser ausgestatteten Empfänger. Als eine Lösung wird der Multimedia- Inhalt in mehreren Schichten kodiert: beispielsweise in eine Basis- und eine Erweiterungsschicht. Die Empfänger mit niedriger Empfangsrate suchen sich nur die Basisschicht heraus, während Empfänger mit hohen Empfangsraten beide Schichten empfangen und diese wieder zusammensetzen können. Der Ablauf bei der Ressourcenreservierung mit RSVP sieht im Überblick folgendermaßen aus: Einer der Kommunikationspartner sendet eine RSVP path Nachricht zur Ermittlung des Verbindungspfads zwischen zwei Endpunkten. Nachdem der Pfad ermittelt wurde, sendet einer der beiden Kommunikationspartner eine Reservierungsanfrage für die benötigten 22
Netzwerk-Ressourcen. Dabei sind für die Übertragung einzuhaltende Dienstgütekriterien in dieser Anfrage enthalten. Jeder Router entlang des Verbindungspfads zwischen den beiden Kommunikationspartnern muss dieser Anforderung zustimmen und die gewünschten Ressourcen reservieren. Ist einer der Router nicht in der Lage, die gewünschten Ressourcen zu liefern, sendet er über RSVP eine negative Antwort an das anfordernde Endsystem. Können alle Zwischensysteme die Reservierungsanforderung erfüllen, erfolgt eine positive RSVP-Nachricht und der Datentransfer kann gestartet werden. Wir sehen somit, dass RSVP eine Möglichkeit des Dialogs zwischen den Kommunikationspartnern mit den Vermittlungsstationen im Internet darstellt. Jedoch ergibt sich die Frage, inwieweit die Vermittlungsstationen die Reservierung der gewünschten Ressourcen vornehmen können, ohne dabei insgesamt Probleme im Internet zu verursachen. Denn wenn jeder die für ihn beste Lösung wählt, heißt das noch lange nicht, dass dies zur besten Lösung für alle beiträgt. Das bringt uns zum nächsten Abschnitt. 6.2 COPS Bekommt ein Router eine RSVP-Anfrage, so muss er erst einmal lokal überprüfen, ob die angeforderten Ressourcen überhaupt bereitgestellt werden können. Jedoch muss er sich auch allgemein festgelegten Richtlinien (Global Policies) beugen. Mit anderen Worten könnte ein Router durchaus in der Lage sein, die gewünschten Ressourcen zu reservieren, aber eine über ihm stehende Regel verbietet es ihm aus gewissen Gründen. Doch woher weiß ein Router nun, ob er sich bei seiner Aktion an die globalen Richtlinien hält oder nicht? Die Antwort ist wiederum relativ einfach. Stellt der Router bei der RSVP-Anfrage noch eine Instanz dar, die einen Service liefert, so tritt der Router nun selbst als Client in Erscheinung. Er kontaktiert einen so genannten Policy Decision Point (PDP), der dazu fähig ist zu entscheiden, ob angeforderte Ressourcen den allgemeinen Richtlinien entsprechen. Das Protokoll, über das Router und PDP kommunizieren, ist an RSVP angelehnt und wird als Common Open Policy Services (COPS) bezeichnet. Man nennt den Router dann auch den Policy Enforcement Point (PEP). 23
Der Ablauf des Dialogs über COPS zwischen PDP und PEP sieht so aus: Ein Router erhält eine RSVP-Anfrage und wandelt diese in einen COPS-Request um, indem er die angefragten Ressourcen aus dem RSVP-Request übernimmt. Danach schickt der Router, der jetzt als PEP fungiert, diesen COPS-Request an einen für ihn zuständigen PDP. Der PDP überprüft, ob die angeforderten Ressourcen den allgemeinen Richtlinien entsprechen, und sendet dem PEP entweder eine positive oder negative Rückmeldung. Der PEP kann darauf entscheiden, ob er die Ressourcen reservieren kann oder nicht, und schickt über RSVP eine entsprechende Antwort an das ursprüngliche System, das die Ressourcen reservieren will (siehe RSVP-Ablauf in Kapitel 6.1). Router 2 Endsystem B Router 1 Router 3 PEP RSVP-Request COPS-Request Endsystem A PDP Abb. 8. Zusammenwirken von RSVP und COPS Abbildung 8 illustriert diesen Ablauf des COPS-Dialogs. Wir haben es somit geschafft, durch die vorzeitige Reservierung von Netzwerkressourcen einigermaßen verlässliche Zusicherungen des übertragenen Systems (Internet) bzgl. von Dienstgüteparametern zu erreichen. 24
7. Zusammenfassung Die Übertragung von Multimedia-Inhalten über das Internet stellt hohe Anforderungen an dieses selbst. Das Protokoll RTP garantiert durch Anfügen von Sequenz- und Zeitstempelinformation die korrekte Reihenfolge und zeitgerechte Wiedergabe der einzelnen übertragenen Multimedia-Datensegmente. Weil beim Multimediastreaming keine Empfangsbestätigungen verschickt werden, ermöglicht RTCP den Austausch von Informationen über die Qualität der Streamübertragung zwischen dem Sender und Empfänger. Da der Anspruch auf Interaktivität gewünscht ist, bietet RTSP die Möglichkeit der Navigation innerhalb eines Streams mit Hilfe von Media-Playern. Vorzeitige Ressourcenreservierung ist eine Lösung dafür, dass die fehlenden Garantien des Internets für eine hohe Übertragungsqualität überwunden werden können. Die Protokolle RSVP und COPS setzen dies in der Praxis um. 25
A Glossar Best effort: Keine Garantien über einzuhaltende Kriterien sind vorhanden. Client: Bezeichnet ein Programm, das einen Server kontaktiert und von diesem Informationen anfordert. Als Beispiele sind Media-Player und WWW-Browser zu erwähnen. COPS: Common Open Policy Services; ein Kommunikationsprotokoll, das Router zur Abfrage von globalen Richtlinien bzgl. der Ressourcenreservierung nutzen. Echtzeit (Real Time): die Zeit, die während der Verarbeitung von Daten tatsächlich vergeht. Jitter: Allg. eine Verzerrung eines Signals oder einer Aufzeichnung. Bei der Datenübertragung wird die Verzerrung durch starke Zeitschwankungen hervorgerufen. Media Player: Streamingfähige Multimedia-Applikation. Multicasting: Kommunikationsvorgang zwischen einem Sender und einer festgelegten Gruppe von Empfängern mit identischer Gruppenadresse in einem Netzwerk. Quality of Service: Dienstgüte; kennzeichnet das definierte, kontrollierbare Verhalten eines Systems bezüglich quantitativ messbarer Parameter RSVP: Resource Reservation Protocol; ein Kommunikationsprotokoll für die Anforderung und Reservierung von Bandbreite in TCP/IP- Netzwerken. RTCP: Real-Time Transport Control Protocol; ein Monitoringprotokoll, das zusammen mit dem Transportprotokoll RTP bei Echtzeitübertragung von Audio- und Videodaten eingesetzt wird. RTSP: Real-Time Streaming Protocol; ein Kontrollprotokoll, das unter Zuhilfenahme eines Media-Players die Streamkontrolle erlaubt. 26
RTP: Real-Time Transport Protocol; ein Übertragungsprotokoll, das bei der Echtzeitübertragung von Audio- und Videodaten eingesetzt wird. Server: Bezeichnet einen Prozess, der von Clients kontaktiert wird, um diesen Informationen zurückzuliefern. Oft wird auch der Rechner, auf dem ein Server-Prozess abläuft, als Server bezeichnet. Streaming: Ein Verfahren zur kontinuierlichen Übertragung von großen Datenmengen im Internet, das v.a. bei Video- und Audiodateien genutzt wird. Bei einem on-demand-stream werden die Daten vorher komplett abgespeichert, währenddessen bei einem Live- Stream die Datenübertragung direkt während der Aufzeichnung erfolgt. Unicasting: Kommunikationsvorgang in einem Netzwerk, bei dem ein einzelner Sender und ein einzelner Empfänger miteinander Daten/Nachrichten austauschen. B Wichtige Internetadressen Webseite Request for Comments (enthält Spezifikationen folgender Protokolle: RTP in RFC 1889, RTCP in RFC 1889, RTSP in RFC 2326, RSVP in RFC 2205) http://www.rfc-editor.org/rfc.html 27
C Abkürzungen und Akronyme COPS HTML HTTP IP PDP PEP QoS RSVP RTP RTSP SMIL SSI TCP UDP WWW Common Open Policy Services Hypertext Markup Language Hypertext Transfer Protocol Internet Protocol Policy Decision Point Policy Enforcement Point Quality of Service Resource Reservation Protocol Real-Time Transport Protocol Real-Time Streaming Protocol Synchronized Multimedia Integration Language Synchronization Source Identifier Transmission Control Protocol User Datagram Protocol World Wide Web 28
Literatur [MS04] Ch. Meinel, H. Sack: WWW - Kommunikation, Internetworking, Web-Technologien, Springer, 2004. [BRS03] A. Badach, S. Rieger, M. Schmauch: Web-Technologien - Architekturen, Konzepte, Trends, Hanser, 2003. [KR01] J. F. Kurose, K. W. Ross: Computernetze, Pearsons, 2001. [Ste03] E. Stein: Taschenbuch Rechnernetze und Internet, Fachbuchverlag Leipzig, 2003. [Ste99] R. Steinmetz: Multimedia-Technologie, Springer, 1999 29
Index Client, 9 COPS, 21, 23 Echtzeit, 4, 7 Web-Server, 9 Zeitstempel, 8, 13, 14 Jitter, 7 Kontrollprotokoll, 11 Live-Stream, 6, 10 Media-Player, 9, 18 Monitoringprotokoll, 11 Multicasting, 6, 11 on-demand-stream, 5, 10 Out-of-Band-Protokoll, 19 Playback Buffer, 8 Quality of Service, 7, 20 Ressourcenreservierung, 8, 21 Router, 21 RSVP, 21 RTCP, 11, 15 RTP, 11, 13 RTSP, 11, 16 Sequenznummer, 8, 13, 14 Server, 9 SMIL, 19 Streaming, 4 Streaming-Media, 4, 8 Traffic Pollicing, 21 Traffic Shaping, 21 Transportprotokoll, 11 30