Seminarausarbeitung

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 Visits1 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 verbun1
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 Server1 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 LiveStream 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-Player1 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 WebServers 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
Media-Server
Puffer
Format
Unicast
Stream-TP
Multicast
Wiedergabe
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
• Monitoringprotokolle1:
Ü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
TCP
RTCP
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/IP1Protokollfamilie 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 UDP2, 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
2
TCP: Transmission Control Protocol, IP: Internet Protocol
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-Header1, der die Informationen enthält. Abbildung 5 zeigt die allgemeine Struktur einer RTPDateneinheit im IP-Paket. Analog zum RTP-Header fügen die Protokolle
UDP und IP ihre jeweiligen spezifischen Header an das bereits beste1
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
201
202
203
204
Report des Senders
Report des Empfängers
Beschreibung der Nachrichtenquelle
Abmeldung (Bye-Message)
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 HTTP1 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-Browser1 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:
•
•
•
1
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.
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 CDPlayers 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>
<BODY>
<AUDIO SRC=“rtsp://realserver.example.com/one.rm”>
<IMG SRC=“image/realimg.gif”>
<VIDEO SRC=“video/example.rm”>
<TEXT SRC=”beschreibung.txt”>
</BODY>
</SMIL>
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 HTML1 eine einfache MarkupSprache, 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 Signalisierungsprotokoll1 erforderlich, das es den auf Hosts2 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
2
„Signalisierungsprotok.“ stammt aus dem Jargon des vermittelten Telefonnetzbereichs
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 MultimediaInhalt 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).
Endsystem B
Router 2
Router 3
Router 1
PEP
RSVP-Request
COPS-Request
PDP
Endsystem A
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/IPNetzwerken.
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 LiveStream 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
Web-Server, 9
Zeitstempel, 8, 13, 14
Echtzeit, 4, 7
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