Detaillierte Analyse der technischen Grundlagen für Streaming

Transcrição

BERUFSAKADEMIE DRESDEN
–STAATLICHE STUDIENAKADEMIE–
Studienarbeit
Detaillierte Analyse der technischen Grundlagen
für Streaming-Videos sowie vorhandener
Streaming Protokolle
Verfasser:
Geb.:
Fachrichtung:
Firma:
Gutachter:
Eva Feldmann
11.09.1980
Medienproduktion
MUB VideoDesign
Dipl.Chem. Marina Beckert
Themenabgabe: 05. November 2004
Abgabetermin: 14. Februar 2005
Autorenreferat
FELDMANN, Eva: Detaillierte Analyse der technischen Grundlagen für Streaming-Videos
sowie vorhandener Streaming Protokolle; Berufsakademie Sachsen, Staatliche Studienakademie Dresden, Studienrichtung Medienproduktion, Studienarbeit, 2005.
58 Seiten, 18 Literaturquellen, 0 Anlagen
Ziel dieser Studienarbeit ist es, den Unterschied zwischen Streaming und Download in
Bezug auf die technischen Grundlagen zu erarbeiten. Bei dieser Analyse werden die
einzelnen allgemeinen Protokolle näher betrachtet und ihre Wirkung auf das Streaming von
Medieninhalten beschrieben. Die Vorteile des Streamings und die Streamingarten werden
dargestellt.
Dabei ist zu klären, wie die speziell entwickelten Streaming Protokolle auf die allgemeinen
Protokolle aufsetzen. Es werden die Einsatzgebiete dieser Protokolle und damit auch die des
Streamings erfasst.
Dafür werden nicht nur der Aufbau und die Wirkungsweise der allgemeinen Protokolle sondern
auch die der verschiedenen Streaming Protokolle analysiert. Die einzelnen Mechanismen
werden aufgeführt und erläutert. Auch die Rolle der Hauptanbieter für Streaming-Server wird
näher betrachtet.
Die detaillierte Analyse der technischen Grundlagen für Streaming-Videos sowie vorhandener
Streaming Protokolle ist Entscheidungsgrundlage beim Einsatz von Streaming-Protokollen. Die
Auswahl der geeigneten Protokolle fällt damit leichter und es kommt zu weniger Problemen bei
der Arbeit mit Streaming. Die Studienarbeit schafft eine solide Grundlage zur Betrachtung von
Streaming Media.
Inhaltsverzeichnis
Inhaltsverzeichnis
Seite
Verzeichnis der verwendeten Abkürzungen
6
1 Streaming
1.1 Warum Streaming?
1.2 Vorteile von Streaming
1.3 Streaming Komponenten
1.4 Unterschied progressives Herunterladen und Streaming
7
8
8
8
9
2 Streamingarten
2.1 Live-Streaming
2.2 On Demand Streaming – Video On Demand
10
10
11
3 Allgemeine Protokolle
3.1 ISO - OSI Referenzmodell
3.2 TCP / IP - Modell
3.2.1 Transportschicht
3.2.1.1 TCP
3.2.1.2 UDP
3.2.2 Anwendungsschicht
3.2.2.1 FTP
3.2.2.2 HTTP
3.2.2.3 HTTP - Streaming
3.2.2.4 Echtes Streaming
3.3 Vergleich HTTP und RTSP Streaming
12
12
16
18
18
21
22
22
22
23
24
25
4 Streaming Protokolle
4.1 RealTime Streaming Protokoll-Reihe
4.1.1 RTSP - RealTime Streaming Protocol
4.1.2 RTP - RealTime Transport Protocol
4.1.3 RTCP - RealTime Transport Protocol
26
28
28
33
36
4.1.4 RSVP - Resource Reservation Protocol
4.2 PNA - Progressive Network Audio
4.3 MMS - Microsoft Server Protocol
Technische Grundlagen
für Streaming-Videos
Seite 4 von 58
39
42
42
Eva Feldmann
Inhaltsverzeichnis
5 Unicast, Broadcast und Multicast
5.1 Unicast 48
5.2 Broadcast
5.3 Multicast
48
6 Schlussbetrachtung
52
7 Literaturverzeichnis
53
8 Tabellenverzeichnis
55
9 Abbildungsverzeichnis
56
10 Eidesstattliche Erklärung
58
49
50
Seite 5 von 58
Eva Feldmann
Abkürzungsverzeichnis
Verzeichnis der Verwendeten Abkürzungen
ACK
ASF
ASX
CSRC
CUDP
DRM
DVMRP
Acknoldge
Advanced Systems Format
ASF Stream Redirector File
Contributing Source List
Cyclic User Datagram Protocol
Digital Rights Management
Distance Vector Multicast
Routing Protocol
FTP
File Transfer Protocol
HTTP
HyperText Transfer Protocol
IETF
Internet Engineering Task Force
IP
Internet Protocol
ISO
International Standards Organisation
MBone Internet Muticast Backbone
MIME Multipurpose Internet Mail
Extensions
MMS
Microsoft Meda Server Protocol
MMST Microsoft Media Server
Protocol/ TCP
MMSU Microsoft Media Server
Protocol/ UDP
MOSPF Multicast Open Shortest Path First
MSBD Media Stream Broadcast Distribution
Protocol
MTU
Maximum Transmisson Unit
NAT
Network Adress Translation
NFS
Network File System
OSI
Open System Interconnection
PAR
Positive Acknowledgment with
Re-Transmisson
PIM
Protocol Independent Multicast
PNA
Progressive Networks Audio
PC
Personal Computer
QoS
RFC
RSVP
RTP
RTSP
RTCP
SDP
SID
SMIL
SMPT
SSRC
SYN
TCP
UDP
URL
WMA
WMF
Seite 6 von 58
Quality of Service
Request Independent Muticast
Resource Resercation Protocol
RealTime Transport Protocol
RealTime Streaming Protocol
RealTime Transport Control
Protocol
Streaming Download Project
Session Initiation Protocol
Synchronized Multimedia
Integration Language
Simpe Mail Transfer Protocol
Synchronisation Source List
Synchronous Idle
Transmission Control Protocol
User Datagram Protocol
Uniform Resource Locators
Windows Media Audio
Windwos Media Video
Eva Feldmann
1 Streaming
1 Streaming
Das Herunterladen eines 90-minütigen Films aus dem Internet, um im Anschluss festzustellen,
dass er nicht gefällt, ist wenig sinnvoll. Streaming bietet die Möglichkeit bereits während des
Downloads den Film abzuspielen. Es gewährt somit den schnellen Zugriff auf Audio, Video
und Multimediainhalte in Echtzeit oder auf Abruf über Internet sowie Intranet.
Einerseits können Ereignisse, welche in Bild und/ oder Ton aufgezeichnet werden in Echtzeit
übertragen werden. Diese Technik wird als Live-Streaming bezeichnet. Zum anderen ist der
Zugriff auf die vorher aufgezeichneten, im Streamingformat gespeicherten und im Internet
veröffentlichten Medien jederzeit möglich. Dies wird als Video On Demand bezeichnet. Beide
Möglichkeiten werden im nächsten Kapitel näher erläutert.
Die Streamingdaten werden über spezielle Media-Server übertragen und vom Client-Player
verarbeitet und wiedergegeben. Dieser kann mit der Wiedergabe beginnen, sobald er genügend
Daten empfangen hat und muss nicht warten, bis die gesamte Datei geladen ist. Die während
der Übertragung empfangenen Daten werden temporär in einem Puffer gespeichert, welcher
während des Abspielens immer wieder mit neuen Daten gefüllt wird. Die Client-Software
entnimmt im Takt die Daten aus dem Puffer. Dieser versagt nur, wenn die nachgeladene
Datenmenge immer geringer als die zum Abspielen benötigte ist. Die Software muss in diesem
Fall jedes ankommende Datenpaket sofort verarbeiten, der Film stockt und der Puffer muss erst
wieder aufgefüllt werden, bevor die Wiedergabe fortgesetzt werden kann.
Merkmal von echtem Streaming ist die Wiedergabe vor dem Abschließen der Datenübertragung,
die gestreamte Datei wird sofort und simultan empfangen, verarbeitet und wiedergegeben und
es verbleibt keine Kopie des Inhalts auf dem empfangenen Gerät. Damit bleibt das Urheberrecht
gewahrt, denn der Empfänger kann die Inhalte nicht in unberechtigter Weise verändern oder
weitergeben.
Der Anwender sowie das Publikum erhalten mit Streaming neue Möglichkeiten durch
die Zusammenführung aus Rundfunk/ Fernsehen und Rich Media (bewegte Anzeigen
usw.). Das Web-Erlebnis wird interaktiver. Streaming bietet interaktive Funktionen, wie
Kapitelzeitmarken, anklickbare Hot-Spots im Bild, URL-Flips, das automatische Öffnen von
Web-Seiten an bestimmten Punkten oder die Indizierung von Schlüsselwörtern.
Seite 7 von 58
Eva Feldmann
Sieben von zehn Internetnutzern finden Websites mit integrierten Audio- und/ oder Videoinhalten
ansprechender als ohne. Jeder vierte Nutzer sieht sich Audio- oder Video-Streamings an. Laut
einer Hewlett-Packard-Fallstudie sind nach der Integration von Streaming eine Rationalisierung
der Produkteinführung, die Verbesserung der Effektivität und Reichweite von Mitteilungen
sowie die Kostensenkung für wichtige Kommunikationen festzustellen.
Bisherige Einsatzgebiete von Streaming liegen in der firmeninternen Kommunikation,
elektronischen Schulungen sowie im Vertrieb und Marketing.
Sinnvoll sind verschiedene Erweiterungen im Einsatz, wie das Senden von E-Broadcasts an das
gesamte Unternehmen, Fernpräsentationen für Mitarbeiter, Kunden und Partner, Schulungen
zur Verbesserung, Entwicklung und Vermittlung von Personalpolitik, Produktvorführungen
sowie Kundendienst.
1.2 Vorteile von Streaming
Das Ende des Downloads muss nicht abgewartet werden. Multimediadaten müssen nicht auf die
Festplatte kopiert bzw. heruntergeladen werden. Somit verbleibt dabei keine dauerhafte Kopie
der Inhalte auf dem PC des Betrachters. Die Bedenken der Urheberrechtsverletzung werden
damit verringert. Streaming ermöglicht zusätzlich die Übertragung von Live-Ereignissen
nahezu in Echtzeit. Außerdem unterstützt es Interaktivität wie z.B. Kapitelzeitmarken bei
Video On Demand. Somit können statische Websites für das Publikum interessanter werden.
1.3 Streaming Komponenten
Für die Erstellung, Einbindung und Wiedergabe von Streamings sind drei Komponenten
notwendig. Zum einen ist der Encoder, eine Software die Media-Daten komprimiert erforderlich.
Als Authoring-Werkzeug vereint dieser die Audio-Spuren, erstellt Untertitel, anklickbare
URLs und vieles mehr. Der Server, ob als normaler Webserver oder Streaming-Server, stellt die
Encoding Ergebnisse ins Netz. Die Client-Software baut den Kontakt zum Server auf, empfängt
Daten, dekomprimiert sie und spielt diese ab.
Seite 8 von 58
Eva Feldmann
Progressives Herunterladen
Streaming
Progressives Herunterladen (auch PseudoStreaming oder Fast-Start-Streaming bei
QuickTime genannt);
Streaming (auch als echtes Streaming bezeichnet);
Beginn der Wiedergabe, während restlicher
Inhalt noch heruntergeladen wird;
Beginn der Wiedergabe, während restlicher Inhalt
noch heruntergeladen wird;
Sofortiges Sehen und Hören nur wenn
Ladegeschwindigkeit mit erforderlicher Rate
aufrechterhalten wird;
Anpassung an Übertragungsgeschwindigkeit
möglich;
Verbindung stockt oder verlangsamt, Audio und
Video nicht immer synchron;
Mediadatei (Kopie des Inhaltes) auf
Empfangsgerät gespeichert;
Es verbleibt keine Kopie des Inhaltes auf dem
Empfangsgerät (Urheberschutz);
Download kann abgebrochen werden
andere Architektur der Inhalte;
Inhalte können nur kontinuierlich von Anfang bis
Ende betrachtet werden;
höhere Interaktivität;
Inhalte durchsuchbar;
Vor- und Rückspulen;
On Demand oder Live-Streaming in Echtzeit;
Daten auf normalen Webserver bereitgestellt;
Streaming-Media-Server;
keine Anpassung der Übertragung an Verbindungsgeschwindigkeit möglich;
mehrere Versionen kodiert für unterschiedliche
Datenrate;
manuelle Auswahl geeigneter Version, anhand
Standardeinstellung des Browsers oder bezüglich
Verbingsungsgeschwindigkeit automatisch Version
auswählen;
bessere Medien-Server und Client-Software passen
Stream dynamisch an Verbindungs-geschwindingkeit
an;
Übertragung über TCP;
neue angepasste Übertragungsprotokolle;
Kommunikation zwischen Clients und Server;
Software-Lösung für Streaming-Server wechselt zu
HTTP-Streaming, wenn Firewall echtes Streaming
verhindert
Seite 9 von 58
Eva Feldmann
2 Streamingarten
2 Streamingarten
2.1 Live-Streaming
Live-Streaming lässt sich wie ein Fernsehprogramm oder ein Radiosender verstehen. Diese
beiden sind auch die Hauptanwendungen des Live-Streamings. Hierbei wird der Datenstrom
kontinuierlich ausgestrahlt. Dem Benutzer ist es nicht möglich, diesen zu steuern. Er hat keine
interaktiven Möglichkeiten, da die Abfolge der Medieninhalte serverseitig festgelegt ist. Dabei
ist dem Client die Länge und das Ende der Daten zu Beginn der Übertragung nicht bekannt.
Live-Streaming ermöglicht kleinen Sendern oder Privatpersonen Daten weltweit zu übertragen.
Der Nutzer erhält die Möglichkeit Informationen zu empfangen, die sonst nur mit erheblich
größerem Aufwand oder gar nicht empfangen werden können.
Das Live-Streaming unterteilt sich noch einmal in zwei Arten. Einerseits gibt es den geplanten
Webcast, auch als „Streaming Broadcast“ bezeichnet. Dabei werden archivierte Inhalte über
eine nur während des Webcasts gültige URL versendet. Der Host beginnt zu einem festgelegten
Zeitpunkt mit dem Stream und sendet dann von Anfang bis Ende. Die Zuschauer können erst
nach einem festgelegten Startzeitpunkt auf den Stream zugreifen.
Die zweite Variante wird als „Live Webcast“ oder manchmal auch als „Live-Live Cast”
bezeichnet. Live-Inhalte werden sofort per Streaming gesendet. Wie beim geplanten Webcast
sieht jeder die selben Inhalte im selben Moment. Es können beim „Live Webcast“ aber auch
Teile der Präsentation vorab aufgezeichneter Streams und andere interaktive Teile z.B. Chats,
Diskussionen sein.
Einsatzgebiete
Geplanter Webcast
- Konzertübertragungen
- Auktionen/ Ausstellungen
Live-Live Cast
- Internet-Radio
- Internet-TV
- Sponsoring/ Werbung
- Konferenzen
Seite 10 von 58
Eva Feldmann
2.2 On Demand Streaming - Video on Demand
2.2 On Demand Streaming – Video On Demand
Beim Video On Demand werden die Medieninhalte auf einem Server hinterlegt und eine
Benutzerschnittstelle geschaffen, z.B. ein Hyperlink auf einer Website. Der Benutzer kann
die für ihn interessanten Medieninhalte aussuchen und vom Server anfordern. Der daraufhin
angestoßene Datenfluss kann von ihm gesteuert werden. Die Wiedergabe basiert auf der
Pufferung einer fixen Datenmenge. Springt der Konsument zu einem anderen Abschnitt,
muss der Puffer neu gefüllt werden. Dieses geschieht im gleichen Zeitintervall wie am
Übertragungsanfang. Mehrere Anwender können den selben Stream abrufen und gleichzeitig
auf unterschiedliche Teile des Inhaltes zugreifen.
Ein weiteres Anwendungsgebiet ist der Pay per View. Der Anwender zahlt im Gegensatz zum
klassischen Rundfunkt nur das, was er wirklich sehen will und sieht. Bei einer Art „virtueller
Videothek“ wählt der Konsumer den Film aus, den er sehen möchte. Nach dem Bezahlen des
Entgelds wird der Film auf dem Streaming-Server freigeschaltet. Dafür sind einfache und sichere
Zahlungssysteme im Internet notwendig. Außerdem muss die Kapazität des Betreiberservers
die Anfragen bearbeiten können und die Netzwerkleistung muss sicherstellen, dass Daten beim
Kunden zuverlässig und qualitativ hochwertig ankommen.
Streaming kann nicht nur für den Download von Mediadaten wie Video und Audio genutz
werden sondern auch für die Software-Lizensierung und -ausbringung. Dabei wählt der
Anwender die gewünschte Software aus. Die Installationsdatei wird mittels eines Streams
übertragen und ausgeführt. Durch die Pufferung der Daten befindet sich nach Abschluss
der Installation die Software auf dem PC des Anwenders, aber keine Installationsdatei. Die
Weitergabe der Software an Dritte wird damit eingedämmt. Um diesen Bereich von Streaming
besser nutzen zu können, sind auch hier sichere Lizenzierungs- und Bezahlungsmechanismen
notwendig. Außerdem muss verhindert werden, dass nach Computercrashs der Anwender die
Software erneut erwerben muss.
Weitere Einsatzgebiete
- E-Commerce
- Produkt- und Firmendarstellungen durch Audio, Video und Text
- Schulung
- Image Videos
Seite 11 von 58
Eva Feldmann
Das Internet besteht aus vielen unterschiedlichen Arten von Computer-Plattformen, welche über
eine große Ansammlung unterschiedlicher Kommunikationsmedien miteinander verbunden
sind. Protokolle sind eine Reihe von Standards, die definieren wie Informationen übertragen
werden oder Teilnehmer untereinander kommunizieren.
Zur Einordnung der Netzwerkprotokolle wird meist das OSI Referenzmodell genutzt. Für
das Internet wurde das TCP/ IP-Modell entwickelt. Beide Protokoll-Modelle werden in den
nächsten Kapiteln erläutert.
3.1 ISO – OSI Referenzmodell
Das OSI Schichtenmodell (Open System Interconnection) der International Standards
Organisation (ISO) wird zur Beschreibung der Funktionsweise bzw. zur Realisierung von
Netzwerkprotokollen verwendet. Es stellt keine Implementationsspezifikation dar, sondern einen
formalen Standard zur Beschreibung vorhandener Architekturen sowie einen konzeptionellen
Rahmen zur Entwicklung neuer Protokolle. Das Modell ist aufgeteilt in 7 Schichten (Layers).
7
Anwendungsschicht
6
Darstellungsschicht
5
Kommunikationssteuerungsschicht
4
Transportschicht
3
Vermittlungsschicht
2
Sicherungsschicht
1
Bitübertragungsschicht
(Application Layer)
(Presentation Layer)
(Session Layer)
(Transport Layer)
(Network Layer)
(Datalink Layer)
(Physical Layer)
Abb.: 3.1-1 OSI Referenzmodell
Seite 12 von 58
Eva Feldmann
Die hierarchische Schichtenanordnung bewirkt eine Reduktion der Komplexität der
Kommunikation. Jede Schicht bietet Dienste an, welche vollkommen unabhängig von der
Implementation der übrigen Schichten sind. Die Import- und Exportparameter sowie die
Schnittstellendefinition müssen den benachbarten Schichten bekannt sein.
Die Schichten 1-3 betreffen Protokolle für die Kommunikation zwischen direkt benachbarten
Einrichtungen während der Übertragung, die Schichten 4-7 die der von End- zu Endpunkt.
Die Vorteile des Schichtenmodells sind, dass die Probleme der technischen Entwicklung auf
einzelne Schichten beschränkt werden, so dass Neuimplementierungen separat für jede Schicht
vorgenommen werden und Probleme individuell gelöst werden können.
Bei der Übermittlung eines Datenpaketes über ein Netzwerk (siehe Abb.: 3.1.2) durchläuft
dieses beginnend von der Anwendungsschicht nacheinander alle Schichten bis zur
Bitübertragungsschicht. Auf Empfängerseite erfolgt die Prozedur in umgekehrter Reihenfolge.
Zwischen den zwei entsprechenden Schichten auf Sender- und Empfängerseite besteht eine
Art Pseudoverbindung. Die Sicherungsschicht des Sender versieht die Daten mit zusätzlichen
Fehlerkorrekturbits. Die entsprechende Empfängerschicht wertet diese Bits aus und trennt diese
von den eigentlichen Daten.
Seite 13 von 58
Eva Feldmann
Empfänger
Sender
7
Anwendungsschicht
7
Anwendungsschicht
6
Darstellungsschicht
6
Darstellungsschicht
5
5
4
Transportschicht
4
Transportschicht
3
Vermittlungsschicht
3
Vermittlungsschicht
2
Sicherungsschicht
2
Sicherungsschicht
1
1
Abb.: 3.1-2 Weg eines Datenpaketes im Referenzmodell
Die einzelnen Schichten sind folgendermaßen definiert:
1 Bitübertragungsschicht
Diese Schicht definiert die physikalischen Eigenschaften der Übertragungswege,
z.B. Telefonkabel, Koaxialkabel, Lichtwellenleiter usw..
2 Sicherungsschicht
Sie sorgt für eine fehlerfreie Übertragung der empfangenen/ gesendeten Daten.
Ihre Aufgabe ist die Erkennung und Vermeidung von fehlerhaften Datenpaketen.
3 Vermittlungsschicht
Diese dient zur Verwaltung zwischen höheren Schichten und den Rechnern im
Netzwerk. Die Verbindungen können verbindungslos oder verbindungsorientiert
sein. Die Vermittlungsschicht kümmert sich um die Wegewahl im Netz.
4 Transportschicht
Jene Schicht ist für die Verbindungsqualität verantwortlich
(Quality of Service, QoS) z.B. Datendurchsatz, Fehlerwahrscheinlichkeit usw..
Seite 14 von 58
Eva Feldmann
5 Kommunikationssteuerungsschicht
Sie verwaltet den Dialog zwischen den zwei Anwendungen dazu gehört der Aufund Abbau der Verbindung und die Art des Dialoges (Voll- bzw. Halbduplex).
6 Darstellungsschicht
Die Darstellungsschicht ist für Syntax der Daten, wie Format (Komprimierung)
und Kodierungsart (Zeichensatz, Verschlüsselung) zuständig.
7 Anwendungsschicht
Diese Schicht definiert die Kommunikationsschnittstellen für die Anwendungen,
die darauf zugreifen. Um das Netz zu nutzen sind die Anwendungen meist
herstellerspezifisch.
Die folgende Abbildung zeigt die relative Lage der Streaming-Protokolle innerhalb des OSI
Referenzmodells.
7
RTSP
HTTP
RTP/RTCP
Cyclic UDP
6
5
4
TCP
UDP
3
IP
2
Sicherungsschicht
1
RSVP
Abb.: 3.1-3 Zuordnung der Streaming-Protokolle ins OSI Referenzmodell
Seite 15 von 58
Eva Feldmann
3.2 TCP/ IP Modell
3.2 TCP/ IP Modell
Der Unterschied zum OSI Modell liegt hauptsächlich in der Entwicklungszeit, in der das OSI
Referenzmodell noch nicht existierte. Das TCP/ IP Modell besteht nur aus 4 Schichten, da
einige Schichten des OSI Referenzmodell zusammenfallen.
7 Anwendungsschicht
4
Anwendungsschicht
3
Transportschicht
2
Internetschicht
1
6 Darstellungsschicht
5 Kommunikationssteuerungsschicht
(Application Layer)
4 Transportschicht
(Transport Layer)
3 Vermittlungsschicht
(Internet Layer)
Netzzugangsschicht
2
(Network Access Layer)
Sicherungsschicht
1 Bitübertragungsschicht
Abb.: 3.2-1 Zuordnung des OSI Referensmodells zum TCP/ IP Modell
1 Netzzugangsschicht
Diese nicht genau spezifiziert Schicht ist verantwortlich für den Transport von
IP-Datengramme durch das Netzwerk. Sie gibt an, wie die Übertragung im Detail
zu erfolgen hat. Zum Einsatz kommen Protokolle wie z.B. X.25 oder Ethernet.
2 Internetschicht
Wenn die Paketlänge, die durch die Maximum Transmission Unit (MTU) festgelegte
Länge von Datenpaketen (Datengramme) übersteigt, übernimmt die Adressierung
und Fragmentierung das Internet Protokoll (IP).
3 Transportschicht
Es können zwei verschiedene Protokolle zum Einsatz kommen, das
Transmission Control Protocol (TCP) verbindungsorientiert mit Fehlerkorrektur
oder User Datagram Protocol (UDP) verbindungslos nur mit Fehlererkennung.
Die Aufgabe beider ist der Aufbau von Host to Host (End zu End) Verbindung.
Seite 16 von 58
Eva Feldmann
3.2 TCP/ IP Modell
4 Anwendungsschicht
Diese stellt die Anwendungssoftware bereit, wie z.B. FTP, TELNET, SMPT usw.;
Sie ist eine Schnittstelle zum Benutzer.
Telnet
FTP
SMPT
Name Server
TCP
NFS
UDP
Internet Protocol
X.25
Ethernet
Token Ring
Abb. 3.2-2: Architekturbeispiel
Die Abbildung 3.2-2 zeigt ein mögliches Architekturbeispiel des TCP/ IP Modells. Für jede
Schicht gibt es mehrere Möglichkeiten.
Seite 17 von 58
Eva Feldmann
3.2.1.1 TCP - Transmission Control Protocol
Das Transmission Control Protocol (TCP) ist ein verlässliches (reliable) und verbindungsorientiertes (connection oriented) Bytestrom Protokoll. Das positive Acknowledgment with
Re-Transmission (PAR) sorgt für eine fehlerfreie Datenübermittlung. Das Protokoll ist mehr
auf Software konzentriert. Es sichert das Senden, Zustellen und korrekte Zusammensetzen.
Für die Optimierung der Netzwerkbandbreite steuert es den Informationsfluss dynamisch und
verlangsamt ihn bei Überlastung des Netzwerkes.
Vor jedem Datenpaket hängt ein Header (mind. 20 Byte großer Protokollkopf), welcher aus
mehreren Datenfeldern mit für den Empfänger relevanten Informationen besteht.
1
4
8
12
16
24
20
28
32
Empfänger-Port
Sender-Port
Sequenznummer
Quittungsnummer
Datenabstand Reserviert
U A F R S F
R C S S Y I
G K H T N N
Fenstergröße
Dringend-Zeiger
Prüfsumme
Optionen
Füllzeichen
Abb. 3.2.1.1-1: Aufbau TCP-Header
Die in der Abbildung 3.2.1.1-1 einzelnen Felder haben folgende Bedeutung:
Sender-Port/ Empfänger-Port
Adressierung der Endpunkte der Verbindung
Sequenznummer/ Quittungsnummer
Angabe der Position der Daten des Segments innerhalb des Datenstroms.
Die Sequenznummer gibt die Nummer des zuletzt gesendeten und die
Quittungsnummer des nachfolgenden Datenpaketes an.
Datenabstand
Länge des Headers bzw. den Anfang der Daten im Segment
URG, ACK, PSH, RST, SYN, FIN
1-bit Flags, aktivieren bestimmte Aktionen im Protokoll
Seite 18 von 58
Eva Feldmann
Fenstergröße
Anzahl der empfangbaren Bytes ab dem bereits bestätigten Byte
Dringend-Zeiger
Zeiger auf wichtige Daten innerhalb des Datenstroms
Optionen
Optional für extra Funktionen die im normalen TCP-Protokollkopf nicht
vorhanden sind
Die Datenpakete mit Header und Nutzdaten werden als Segmente bezeichnet. Jedes Segment
verfügt über eine Prüfsumme, um dem Empfänger die Fehleranalyse zu ermöglichen. Der
Empfänger bestätigt korrekt empfangene Segmente mit einem Segment. Dieses hat die
Funktion einer Quittung. Wenn die Quittung des Empfängers den Sender nicht in einer
festgelegten Zeitperiode erreicht, werden die nicht korrekt übermittelten Segmente erneut
übertragen. Dadurch kann es zu Mehrfachübertragungen kommen. Dies hat keine negativen
Auswirkungen, da anhand der eindeutigen Sequenznummer für jedes Segment Duplikate
ermittelt und vernichtet werden.
TCP ist außerdem verantwortlich für die Weiterleitung der empfangenen Daten an die
entsprechende Anwendung mittels der Portnummer, welche im Empfänger-Port des TCPHeaders vermerkt ist. Bei der Größe von 16 Bit ist eine Anzahl von 65.535 verschiedener
Portnummern möglich. Für wichtige Anwendungen sind die Portnummern nach RFC 100
standardisiert z.B. FTP = 21, Telnet = 23 usw. Durch die Portnummer und die IP-Adresse kann
ein Anwendungsprozess eindeutig angesprochen werden. Diese Kombination wird als Socket
bezeichnet.
Der Aufbau einer logischen Verbindung zwischen Sender und Empfänger erfolgt über den
sogenannten „Three way handshake“. Zum Verbindungsaufbau wird ein erstes Segment ohne
Nutzdaten vom Sender an den Empfänger übermittelt. Es enthält die Sequenznummer, mit
welcher die Verbindung startet.
Das SYN-Flag wird gesetzt und zeigt den Verbindungsaufbauwunsch an. Der Empfänger sendet
ein Segment mit gesetzten SYN- und ACK-Flag zur Bestätigung des Verbindungsaufbaus. Dieses
Segment enthält außerdem eine vom Empfänger vergebene Sequenz- und Quittungsnummer,
welche der um eins erhöhten Sequenznummer des Senders entspricht.
Seite 19 von 58
Eva Feldmann
Sender
Seq=x
Seq=y
Seq=x
SYN=1
x+1
ACK=
+1 ACK
=y+1
=1
1 ACK
SYN=
Empfänger
Der Sender bestätigt dieses Segment nach dem Empfang wieder, diese Bestätigung darf
bereits Nutzdaten enthalten. Bei diesem Segment ist nur noch das ACK-Flag gesetzt
und das Sequenznummern-Feld enthält die Quittungsnummer des Empfängers und im
Quittungsnummern-Feld die um eins erhöhte Sequenznummer des Empfängers.
ACK=1
Abb. 3.2.1.1-2: Verbindungsaufbau über „Three way handshake“
Der Datenaustausch findet über das „Sliding Window“ Prinzip statt. Dabei versendet der Sender
an den Empfänger so viele Bytes, wie im Fenstergrößen-Feld im TCP-Header angegeben sind.
Er wartet vor dem Senden der nächsten Bytes auf die Bestätigung des Empfängers. Nach der
erfolgreichen Datenübermittlung wird die Verbindung wieder getrennt.
Diese Trennung geschieht mittels des „Three way handshake“ analog zum Verbindungsaufbau.
Der Rechner, der die Verbindung trennen will, sendet an den anderen Rechner ein Segment
mit gesetzten FIN- und ACK-Flag. Alle bis zu diesem Zeitpunkt empfangenen Daten werden
bestätigt. Der andere Rechner sendet nach Erhalt ein Segment, wo er auch die bis dahin
empfangenen Daten quittiert und FIN- und ACK-Flag setzt. Bestätigt der zur Trennung
auffordernde Rechner dieses durch ein ACK-Flag, wird die Verbindung abgebaut.
Seite 20 von 58
Eva Feldmann
3.2.1.2 UDP - User Datagram Protocol
3.2.1.2 UDP - User Datagram Protocol
Auch das User Datagram Protocol (UDP) gehört zur Transportschicht. Es handelt sich um ein
verbindungsloses, unzuverlässiges Protokoll und ist in RFC 768 definiert. Es heißt unzuverlässig,
weil das Protokoll nicht den Empfang der Daten garantiert. Erreichen die Daten den Empfänger,
kann aber deren Korrektheit mittels Prüfsumme überprüft werden. Ist die Prüfung negativ, sind
die Daten verloren, da sie kein zweites Mal gesendet werden.
Der UDP-Header enthält die Informationen zur Adressierung der richtigen Sender- und
Empfänger-Prozesse. Dabei gibt er die UDP-Länge, die gesamte Länge inklusive UDP-Header
an. Die Prüfsumme ist optional. Wird auf sie verzichtet, steht im entsprechenden Feld eine Null
und es findet keine Überprüfung statt.
1
4
8
12
16
20
24
28
Sender-Port
Empfänger-Port
UDP-Länge
UDP-Prüfsumme
32
Abb. 3.2.1.2-1: Aufbau UDP-Header
Die gute Effizienz des Protokolls prädestiniert es für die Audio- und VideodatenÜbermittlung. Hierbei kommt es meist weniger auf die korrekte Datenübermittlung sondern
vielmehr auf die Schnelligkeit an. Eine bestimmte Anzahl der Segmente muss jedoch korrekt
übertragen werden, sonst wird die Verbindung wegen der schlechten Übertragungsqualität
unterbrochen. Ein weiteres Einsatzgebiet ist die Übermittlung kleiner Datenmengen, für die
der Verbindungsaufbau mittels „Three way handshake“ zu aufwendig ist. Der Verlustanteil des
Gesamtdatenstroms ist durch den nur 8 Bytes großen UDP-Header sehr gering.
Speziell für die Übertragung von Audio- und Videodaten wurde Cyclic UDP (CUDP)
entwickelt. Es besteht aus einer Auswertung, welche die Mediendaten speziell nach ihrer
Relevanz sortiert und entsprechend der Priorität neu ordnet. Die Übertragungskomponente
regelt die Übertragung anhand dieser Priorität. Sie enthält einen Kontrollmechanismus für den
Datenstrom und eine spezielle Fehlerkorrektur.
Seite 21 von 58
Eva Feldmann
3.2.2.1 FTP - File Transfer Protocol
Das File Transfer Protocol (FTP) ist ein sehr effizientes Protokoll zur Datenübertragung zwischen
zwei Geräten. Es ist nicht auf das Internet angewiesen. Es wird für sehr unterschiedliche Zwecke
eingesetzt, da es den Download fast jeden Dateityps ermöglicht. Das Hauptanwendungsgebiet
ist die Übertragung von Web-Seiten zum Webserver.
3.2.2.2 HTTP - HyperText Transfer Protocol
Das HyperText Transfer Protocol (HTTP) dient der Übertragung von Hypertext Dateien im
Internet. Hypertext wurde von Ted Nelson in den 60er-Jahren erfunden. Es ist heutzutage ein
Standard für Webinhalte. Web-Seiten bestehen meist aus Hypertext Dateien. Hypertext ist
ein Datenbanksystem, welches zusammengehörige Objekte (Text, Bilder, Musik, Video usw.)
verknüpft. Die Informationen können nicht linear abgerufen werden. Aufgrund der Interaktivität
des Hypertextes wird ein Zweiwegekommunikationsprotokoll (Anfrage-Antwort-Protokoll)
benötigt. Dieses dient zur Kommunikation des Empfängers über das Netzwerk, um URLs
(Uniform Resource Locators) für Objekte aufzurufen, mit denen der Hypertext verknüpft ist.
Nach einem Verbindungsaufbau können mehrere unterschiedliche Nachrichten nacheinander
oder parallel gesendet werden. Alle Anfrage- und Antwortnachrichten enthalten vier
Komponenten. Die initiierende Anfrage-/ Antwortzeile besteht für eine Anfrage aus einem
Methodennamen, dem Lokalistionspfad eines Objektes und der Version des Protokolls und für
eine Antwort aus einem Statuscode und einer Beschreibung des Statuscodes. Der initiierten
Zeile kann eine optionale Zeile folgen, die Informationen der Anfrage bzw. Antwort enthält.
Der optionale Mitteilungsteil enthält Parameter oder Lokalisationsparameter zur übertragenen
Datei.
Seite 22 von 58
Eva Feldmann
3.2.2.3 HTTP-Streaming
Dateien die im Streaming-Media-Format codiert wurden, können auch von einem
herkömmlichen Webserver bereitgestellt werden. Dieses sogenannte HTTP-Streaming (oder
auch als Pseudo-Streaming, Webserver-Streaming, von QuickTime als Fast-Start-Streaming
bezeichnet) erlaubt im Gegensatz zu dem traditionellen Herunterladen die Wiedergabe der
Datei, vor dem kompletten Herunterladen.
Dem Endanwender ist es möglich, die Datei schon während des Downloads des restlichen Inhalts
anzusehen oder ihn abzubrechen. Das HTTP-Streaming ist eine Variante des progressiven
Herunterladens. Dabei wird eine im Cache gespeicherte Kopie der Medieninhalte erzeugt. Es
kann nicht verhindert werden, dass der Anwender die Datei auf seine Festplatte speichert.
Der Vorteil dieser Form des Streamings liegt darin, dass die Streaming-Media-Dateien über
Firewalls hinweg übertragen werden können. Deshalb bieten spezielle Software-Lösungen für
Streaming-Server die Möglichkeit zu HTTP-Streaming zu wechseln, wenn echtes Streaming
von einer Firewall verhindert wird.
Der Webserver übernimmt den Transport der Daten über das HTTP-Protokoll. Es wird zunächst
das Video geladen, dann dargestellt. Dies bedeutet für den Webserver für die Aufbewahrung
und Darstellung eine große Belastung. Deshalb ist es besser, wenn häufig angezeigte Files auf
separaten Streaming-Server ausgelagert werden.
Die Protokolle HTTP und FTP sind nicht für echtes Streaming geeignet, denn sie setzen auf
TCP auf, welches die erneute Übertragung verlorener oder beschädigter Daten sicherstellt. Die
Audio- und Videoinhalte kommen intakt an, aber die Zuverlässigkeit des Protokolls ist für
progressives Herunterladen ein Problem. Die Neuübertragung verlorener oder beschädigter
Daten kann die Wiedergabe unterbrechen.
HTTP und FTP sind zwei zuverlässige Protokolle für die Datenübertragung, können aber
nicht für echtes Streaming eingesetzt werden. Durch die Fehlerkorrektur wird der Zeitbezug
zwischen Video- und Audiopaketen zerstört. Das Herunterladen eines Ein-Minuten-Filmes
kann eine Sekunde, eine Minute oder eine Stunde dauern, je nach Dateigröße und Verbindungsgeschwindigkeit. Die Informationen können nicht linear abgerufen werden.
Seite 23 von 58
Eva Feldmann
Um Videos auf einem Webserver bereit zu stellen, muss dieser in seiner Konfiguration die
folgenden MIME-Types und die entsprechenden Datei-Endungen enthalten.
audio/x-pn-realaudio
audio/x-pn-realaudio-plugin
video/quicktime
video/x-ms-asf
ra, ram
rpm
qt, mov
asf, asx
3.2.2.4 Echtes Streaming
Streaming-Inhalte brauchen eine andere Architektur als herunterladbare Medien. Sie müssen
eine höhere Interaktivität über das Web unterstützen und haben weitere Vorzüge wie zum
Beispiel das Durchsuchen, Vor- sowie Zurückspringen in den Inhalten. Dies ist beim
progressiven Download nicht möglich, dabei muss die Datei von Anfang bis Ende betrachtet
werden. Beim Video On Demand wie beim Live-Streaming (Kapitel 2.1 und 2.2) können
Inhalte in Echtzeit über das Web übertragen werden.
Beim progressiven Herunterladen vom Webserver gibt es keine Anpassung der Verbindungsgeschwindigkeit an unkontrollierbare Schwankungen. Echtes Streaming nutzt dagegen
neue Web-Übertragungsprotokolle (siehe Kapitel 4), welche auf die zeitliche Abfolge der Pakete
achten.
Die Kommunikationstechniken zwischen Clients und Server ermöglichen eine kontinuierliche
Wiedergabe synchronisierter Klänge und Bilder in Echtzeit. Die Streaming-Media-Dateien
werden meist in mehreren Versionen kodiert und die Datenraten optimiert.
Der Streaming-Server liefert die geeignete Version entweder durch die manuelle Auswahl
des Endanwenders, die Standard-Einstellung des Browsers, oder ausgewertete Informationen
vom Client ermöglichen eine automatische Anpassung. Je nach der Intelligenz von Server und
Client-Software kann der Stream dynamisch an beiden Enden angepasst werden, wenn die
Verbindungsgeschwindigkeit sinkt.
Einige Vorteile der Nutzung spezieller Streaming-Server:
Effizientere Nutzung der Netzwerkbandbreite
Bessere Audio- und Videoqualität
Fortschrittliche Funktionen wie detaillierte Berichterstellung
Unterstützung für viele Anwender
Seite 24 von 58
Eva Feldmann
3.3 Vergleich HTTP-Streaming und RTSP Streaming
3.3 Vergleich HTTP-Streaming und RTSP Streaming
HTTP-Streaming bietet keine wirkliche Alternative zum echten Streaming. In dieser
Tabelle sind die wesentlichen Unterschiede der beiden Streaming-Methoden noch einmal
gegenübergestellt.
Vorteile
HTTP-Streaming
Echtes Streaming
+ keine zusätzl. Serversoftware nötig
+ Live-Streaming möglich
+ Inhalte werden unabhängig von der
Verbindungsgeschwindigkeit sicher
übertragen
+ Broadcast und Multicast möglich
+ Gute Verbindungsgeschwindigkeit
ermöglicht, dass Inhalte gleich schnell
wie beim echten Streaming
empfangen werden
+ Benutzt nur soviel Bandbreite, wie
es braucht
+ Verlorene Pakete werden so lange neu
gesendet, bis sie korrekt empfangen
wurden
+ Keine Probleme mit Firewalls
oder NAT
Nachteile
+ Es wird nur wenig Festplattenkapazität beim Benutzer benötigt
+ Die Urheberrechte können
geschützt werden
+ Der Benutzer kann an jede
beliebige Stelle des Inhalts
springen
-
Keine Unterstützung von Broadcast
und Multicast
-
Benötigt einen Streaming Server
oder/ und Broadcast
-
Kein Live-Streaming
-
-
Der Benutzer kann im Inhalt nicht
hin- und herspringen, er muss vorher
die gesamte Datei herunterladen
Übertragung bricht ab, wenn nicht
genügend Bandbreite zur
Verfügung steht
-
Keine Fehlerkorrektur – verlorene
Pakete sind verloren
-
Funktioniert nicht mit NAT und
Firewalls
-
Es wird eine lokale Kopie gespeichert
-
Kein Schutz der Urheberrechte
Tabelle. 3.3-1: Vergleich HTTP- und echtes Streaming
Seite 25 von 58
Eva Feldmann
Streaming Protokolle ermöglichen die Übertragung der Daten in Echtzeit. Die Daten liegen
dazu auf einem speziellen Streaming-Server. Hauptanbieter für diese Server sind die Firmen
Real, Apple und Microsoft, welche auf unterschiedlichen Protokollarten basieren und meist
nur diese unterstützen. In den nachfolgenden Abschnitten werden die einzelnen Protokollarten
näher erläutert.
Die Streaming Protokolle bieten verschiedene Mechanismen. So können einzelne End-anwender
oder bestimmte Web-Konferenzteilnehmer spezifische Streams von einem oder mehreren
Servern aufrufen, spezifische Transporttypen ein oder mehrere Ziele für die Zustellung der
Daten angeben. Es ermöglicht Ihnen auch Informationen zu den Daten in formatspezifischer
Art zu erhalten und die Zustellung der Daten starten, stoppen, unterbrechen sowie zufällig auf
bestimmte Teile der Daten zuzugreifen (nicht möglich z.B. beim Live-Streaming).
Das Diagramm zeigt das Aufsetzen der einzelnen Protokolle am Vergleich von HTTPStreaming und echten Streaming am Beispiel der RealTime Protokoll-Reihe:
Browser
Anzeige / Wiedergabe
Media Player
HTTP
Interaktivität
RTSP
TCP
Transport
RTP/ UDP
IP
Routing
IP
Physikalischer Anschluss
Netzwerk
Physikalischer Anschluss
Abb. 4-1: Protokollvergleich von HTTP- und echten Streaming
Seite 26 von 58
Eva Feldmann
Die RealTime Protokoll-Reihe bietet einen offenen Standard, der keinem Schutz unterliegt und
daher als Schnittstelle für Server und Player verschiedener Hersteller dient. RealNetworks und
Apple nutzen das RealTime Streaming Protokoll in ihren Programmpaketen RealSystem und
QuickTime.
In der Praxis wird damit der Datentransport, die Steuerung der Wiedergabe, die Wahl zwischen
den verschiedenen SureStreams und die Übermittlung der Clipinformationen sowie die
Authentifizierung realisiert.
Streaming-Server und unterstützte Protokolle im Überblick
Name
Protokolle
UDP
RTP
Bemerkungen
RTSP
HTTP
SDP
MMS
Apple Darwin
X
X
X
?
X
---
kostenlos
Apple Quicktime
X
X
X
X
?
---
kostenlos, nur für
Mac OS X Server
Real Server
X
X
X
X
---
---
Basic kostenlos,
sonst kostenpflichtig
Microsoft
Streaming Service
X
---
---
X
---
X
kostenlos, nur für
Windows Server
Tabelle. 4-1: Streaming-Server und unterstützte Protokolle
Seite 27 von 58
Eva Feldmann
Um leistungsfähiges Streaming zu ermöglichen, wurde eine Protokoll-Reihe mit verschiedenen
Aspekten entwickelt. Das RealTime Transport Protocol (RTP) dient der Übermittlung von
Mediadaten vom Server zum Client. Es steht im engeren Zusammenhang mit dem RealTime
Transport Control Protocol (RTCP), welches den Transport überwacht. Das RealTime Streaming
Protocol (RTSP) ist für den Aufbau der Verbindung und Steuerung der Datendarstellung
zuständig. Es handelt sich dabei um ein zweipoliges-Protokoll (ähnlich HTTP). Außerdem hat
es die Funktion einer Netzwerkfernsteuerung des Multimedia-Servers.
Resource Reservation Protocol (RSVP) reserviert die Netzwerkbandbreite für die Übermittlung
des Streaming-Videos. Es sichert eine gleichbleibende Verbindungsqualität und damit den
sogenannten Quality of Service (QoS). In den nächsten Abschnitten werden die einzelnen
Protokolle näher vorgestellt.
„Fernbedienung“ über RTSP
Server
Datenstrom über RTP
Client
Kontrolle über RTCP
Abb. 4.1-1: Verbindungen während eines Streams
Das RealTime Streaming Protocol (RTSP) entstand 1996 durch RealNetworks und Netscape in
Kooperation mit 40 weiteren Unternehmen. Später beteiligten sich an der Weiterentwicklung
gemeinnützige Organisationen, wie die Columbia University und MMUSIC Working Group
der Internet Engineering Task Force (IETF). RTSP wurde 1998 von der IETF als Standard
vorgeschlagen und in „RFC 2326“ festgelegt.
Entwickelt wurde es, um eine effiziente Übermittlung von Multimedia Streams über IPNetzwerke zu gewährleisten. Die multimedialen Datenströme werden nicht mit RTSP
transportiert, aber sie werden damit kontrolliert.
Protokolle tieferer Schichten (RTP und RTCP) übernehmen die Kontrolle der Transportverbindung, die Überprüfung der Verbindungsqualität und verlorener Daten.
RTSP ist eine Art Fernsteuerung des Mutimedia-Servers. Es ermöglicht z.B. Play, Forward
oder Stop während der Übertragung. RTSP lässt sich auf der Anwendungsschicht einordnen.
Seite 28 von 58
Eva Feldmann
Der Client kann auf die Übertragung des Servers direkt Einfluss nehmen. Syntax und Aufbau
ähneln stark dem Internet-Standardprotokoll HTTP. In der Praxis besteht häufig eine Verbindung
zwischen RTSP und HTTP bei der Übertragung. RTSP ist auf der Anwendungsebene nur eine
Befehlsbibliothek, die innerhalb eines Paketes einer Streaming Software installiert wird. Sollte
dieses nicht optional installiert sein, könnte sich dies nachteilig auf die gesamte StreamingAnwendung auswirken.
Steaming Anwendung
SDP
RTSP
HTTP
SIP
H.323
RTP
Transport-Protokolle (TCP, UDP)
RSVP (Ressource Reservation Protocol)
Netzwerk
Abb. 4.1.1-1: Zusammenhang zwischen den Protokollen
RTSP ist nicht auf ein bestimmtes tiefer liegendes Protokoll festgelegt. Die Übertragung des
Streams setzt normalerweise auf eine RTP-Verbindung auf, die wiederum auf UDP setzt. Es ist
aber auch eine Übertragung nur auf UDP-Basis möglich. Auch die RTSP-Verbindung ist von der
Transportverbindung unabhängig, normalerweise wird TCP verwendet. Es besteht sowohl die
Möglichkeit von Unicast- wie auch Multicast-Streaming (s.a. Abschnitt 5). RTSP unterstützt die
gleichberechtigte, beidseitige Kommunikation zwischen Server und Client. Nicht nur der Client
ist zu Anfragen an den Server berechtigt, sondern auch der Server an den Client. Das ClientAnwendungsprogramm hat damit die Möglichkeit, seine Benutzeroberfläche dementsprechend
anzupassen und z.B. Schaltflächen, die nicht vom Server verstanden werden auszublenden.
Ein Stream besteht häufig nicht nur aus einer Multimedia-Datei, sondern aus mehreren zeitlich
aufeinander abgestimmten Quellen in Form einer Präsentation. RTSP unterstützt die Steuerung
und kontrolliert den Ablauf solcher Multimediapräsentationen, welcher in der Präsentation
sbeschreibung festgelegt ist. Standard für Multimediapräsentationen ist die Synchronized
Multimedia Integration Language (SMIL).
Seite 29 von 58
Eva Feldmann
Beispielhafter Ablauf einer RTSP-Sitzung
Auf einer HTML-Seite befindet sich ein Link zur Präsentationsbeschreibung in Form einer
SMIL-Datei. Über das HTTP GET fordert der Client die Datei an. Nach erfolgreicher
Übertragung baut der Multimedia-Client des Anwenders die RTSP-Verbindung basierend auf
der SMIL-Präsentation auf. Hier endet der Bereich von HTTP und geht auf RTSP über. Dieses
stellt nun die Verbindung zum Media-Server her und überträgt den SETUP-Request. Dieser
wird nach erfolgreicher Ausführung vom Server beantwortet. Nach dem PLAY-Request wird
die RTP-Verbindung aufgebaut, Daten werden übertragen. Der Client hat die Möglichkeit,
diesen mit PAUSE zu unterbrechen oder mit TEARDOWN entgültig zu beenden.
HTTP GET
WebServer
Präsentationsbeschreibung
SETUP
Client
PLAY
MediaServer
RTP-Audio
RTP-Video
PAUSE
TEARDOWN
Abb. 4.1.1-2: Schematische Darstellung einer RTSP-Sitzung
Aufbau und Struktur einer RTSP-Nachricht
RTSP-Nachrichten lassen sich in zwei Haupttypen einteilen: in Request-Nachrichten und
Response-Nachrichten, ähnlich wie bei HTTP. Beide sind unterteilt in Status- oder Requestline,
Header- und Body-Bereich (folgt nur wenn im Header angekündigt).
Status- /
Requestline
HeaderBereich
BodyBereich
Abb. 4.1.1-3: Struktur einer RTSP-Nachricht
Entsprechend des Datentyps enthält die Status-/ Requestline Informationen über die Ausführung
einer Aktion oder die Aktion selbst. Parameter, die für die Ausführung der Aktionen benötigt
werden, werden im Header-Bereich aufgeführt. Wenn ein Body angehängt ist, dann enthält dieser
protokollfremde Informationen, entweder Nachrichten anderer Protokolle oder Nutzdaten.
Seite 30 von 58
Eva Feldmann
Der Zweck des RTSP-Request ist, den Empfänger zum Ausführen einer Aktion aufzufordern.
Die Requestline gleicht in etwa dem HTTP-Request. Für die URL der Quelle sind verschiedene
Optionen gültig. Zuerst wird die ausführbare Aktion (Methode) genannt, dann die Quelle auf
die sich die Aktion bezieht.
Im Header-Bereich des RTSP-Responses sind Informationen über die Ausführung der Aktion
meist in Form von Parametern vorhanden. Die Statusline enthält Angaben zur Version, einen
numerischen Status und die textuelle Beschreibung dieses Wertes. Der Statuswert gibt Auskunft
darüber, ob die Aktion korrekt oder mit Fehlern ausgeführt wurde. Die Status-/ Requestline
einer Request-Nachricht und die dazu gehörige Response-Nachricht ohne Header- und BodyBereich könnten z.B. so aussehen:
Request: PAUSE rtsp://ms.web:554/vid.rm RTSP/1.0
Response: RTSP/1.0 200 OK
Aktionen werden durch RTSP-Request ausgelöst. Eine Methode, welche die Aktion beschreibt,
löst diese durch ein Schlüsselwort im Request beim Empfänger aus.
RTSP verfügt über ein Zusatzmodell, damit Server und Client nicht ständig Statusmeldungen
austauschen müssen. Es ändert den Zustand des Teilnehmers abhängig von der empfangenen
Request-/ Response-Nachrichten. Der aktuelle Zustand bestimmt, welche Methode als nächstes
ausgeführt wird.
Wichtigste Methoden
Setup
Diese Methode kann nur durch den Client aufgerufen werden. Die Übertragung
des Datenstroms wird vorbereitet und die Transporteinzelheiten spezifiziert.
Play/ Record
Nach dem erfolgreichen Setup kann der Client damit die Übertragung beginnen
und den Film starten bzw. aufzeichnen. Spezielle Parameter können übergeben
werden, welche spezifizieren, wo die Wiedergabe beginnen soll oder ob nur ein
Ausschnitt wiedergegeben werden soll.
Pause
Fordert durch die Übergabe von Parametern Server auf, die Übertragung zu
stoppen; Zeitpunkt der Pause kann vorher festgelegt werden. Der Request wird
Seite 31 von 58
Eva Feldmann
dabei vor der eigentlichen Pause gesendet. Beim Fortsetzten der Wiedergabe ist
kein neues Setup nötig.
Teardown
Diese Methode beendet die Übertragung und schließt die Verbindung sofort.
Alle ausstehenden Methoden werden nicht mehr ausgeführt. Für einen erneuten
Aufbau eines Datenstroms ist vorher ein erneutes Setup nötig. Der Teardown ist
wie das Setup nur vom Client ausführbar.
Nicht bei jeder Verbindung stehen alle Methoden zur Verfügung, z.B. kann ein Multicast-Client
nicht im Inhalt vor- oder zurückspulen und einzelne Clients nicht mit Pause unterbrechen. Es
stehen noch weitere Methoden zur Verfügung, auf welche hier nicht weiter eingegangen wird.
Das textbasierte Protokoll RTSP interpretiert nur bekannte Befehle und Parameter und ignoriert
unbekannte.
Beispiel für Zustandsänderung
Zustand
Server-Bedeutung
Client-Bedeutung
Init
Wartezustand
SETUP wurde gesendet, warten auf
Response
Ready
SETUP/ PAUSE empfangen und ausgeführt,
Response gesendet
SETUP/ PAUSE-Response wurde
empfangen
Playing
PLAY wurde empfangen, Datenstrom wird gesendet
PLAY Response erhalten
Recording
RECORD wurde empfangen
Datenstrom wird aufgenommen
RECORD Response erhalten
Tabelle. 4.1.1-1: Beispiel für Zustandsänderung
Seite 32 von 58
Eva Feldmann
Das RealTime Transport Protocol (RTP) und das RealTime Transport Control Protocol (RTCP)
wurden von Audio-Video Transport Working Group (AVT WG) im Auftrag der IETF entwickelt
und 1995 als Standard definiert. Die Weiterentwicklung erfolgt von AVT WG und der IETF in
Zusammenarbeit mit Unternehmen wie RealNetworks und Apple.
RTP besitzt wichtige Eigenschaften eines Transportprotokoll. Es wird bislang aber fast nur für
die Applikationsebene implementiert. Es stellt sich als ein nicht vollständiges Transportprotokoll
ohne fest definierte Dienstschnittstelle dar und definiert das Format der Datenpakete. Im OSI
Referenzmodell ist es zwischen Transport- und Applikationsschichten einzuordnen, weil es
unabhängig von den darunterliegenden Netzwerkschichten ist aber meist auf UDP setzt. RTP ist
ein verbindungsloses Protokoll und besitzt weder Flusskontrolle noch Fehlerkorrektur.
Multimedia
Applikation
RTP
TCP
UDP
IP
Ethernet
FDDI
ATM/AAL
Abb. 4.1.2-1: Anordnung des RealTime Transport Protokolls
Wichtige Anforderungen an RTP sind einerseits kontinuierlicher Datenstrom in Echtzeit. Damit
kann es für verschiedene Applikationen und Aufgaben genutzt werden. Des Weiteren muss eine
minimale Bandbreite bei der Datenübertragung eingehalten werden, um eine verzögerungsfreie
Wiedergabe zu ermöglichen. Letztlich ist im Datentransportverlauf der Austausch von
Informationen über Sender und Empfänger erforderlich. Diese Informationen sind vor allem bei
Multicasting wichtig z.B. für Live-Konferenzen mit einer variablen Anzahl von Teilnehmern.
RTP wird um das RealTime Transport Control Protocol (RTCP) ergänzt, um diese Anforderung
zu erfüllen. RTP ist für den eigentlichen Transport der Echtzeitdaten zuständig und RTCP
gibt Informationen über die Übermittlung weiter, welche vom Anwender ausgewertet werden
können.
Seite 33 von 58
Eva Feldmann
Der RTP-Standard schreibt für die verschiedenen Medienströme unterschiedliche
Transportverbindungen vor. Bei der Verwendung von UDP/ IP müssen Kontrollkanal und
Datenkanal eine IP-Adresse besitzen. Außerdem wird eine eigene Verbindung für die
Übermittlung der RTCP-Pakete aufgebaut, meist mit einer Port-Nummer, die um eins höher
ist als die RTP-Verbindung. RTP- und RTCP-Pakete können mit normalen Verschlüsselungsverfahren gegen Fremdzugriff gesichert werden. Eine protokollspezifische Verschlüsselung
ist nicht vorgesehen.
Transportteil
RTP ermöglicht dem Sender von Streaming-Daten die Übertragung durch einen konsistenten
Datenstrom in Echtzeit an einen oder mehrere Empfänger.
Zur Umwandlung der Datenströme und Optimierung der Übertragung stellt RTP die zwei
besonderen Mechanismen Mixer und Übersetzer zur Verfügung. Der Header kann durch
einen Erweiterungsheader variabler Länge ergänzt werden, der anwendungsspezifische
Zusatzinformationen enthält. Nach dem Header folgt die eigentliche Nutzlast des Paketes, die
Art dieser wird im Header festgelegt.
Der Mixer ist ein RTP-Zeichensystem und hat die Umwandlung der Daten vor dem Transport
zur Aufgabe. Die Daten setzen sich aus einer oder mehreren Datenquellen zusammen (z.B.
Kamera für Videospur, Datrecorder für die Audiospur). RTP ordnet den Datenquellen zur
Identifizierung eine eigene, eindeutige Synchronisation Source (SSRC) zu. Der SSRC-Identifier
wird zu Beginn einer Sitzung von einem Sender zufällig generiert. Wenn es zu Kollisionen
kommt, weil zwei Sender die gleiche SSRC gewählt haben, sendet ein Sender unter seinem
alten SSRC-Identifier eine bestimmte RTCP-Kollisionsnachricht an seine Empfänger und gibt
seine neue SSRC-Identifier bekannt. Eine SSRC-Identifier kann sich ohne Auf- oder Abbau der
Verbindung ändern.
Da die verschiedenen Eingangsdatenströme in der Regel nicht synchron sind, führt der Mixer
eine entsprechende Anpassung durch. Es werden dabei alle SSRCs zu einem synchronisierten
Datenstrom umgewandelt. Dieser wird an den Empfänger gesendet und ergibt eine eigene
SSRC-Kennung. Zur Sicherstellung der Synchronisation werden alle SSRCs zu einem
synchronisierten Datenstrom durch den Mixer umgewandelt.
Alle in diesem Strom integrierten SSRCs werden in einer Contributing Source List (CSRC)
eingetragen und an ausgehende Pakete angefügt, um die SSRC-Kennung der ursprünglichen
Quelle verfügbar zu halten. Eine weitere Aufgabe des Mixers ist die Umwandlung der
Seite 34 von 58
Eva Feldmann
Datenströme bei Bedarf oder der Zugriff auf alternatives Material, so dass ein optimales
Verhältnis zwischen Qualität und der zu Verfügung stehenden Bandbreite erreicht werden
kann.
Kamera
(Videodaten)
SSRC:1
SSRC:1
Mixer
(Synchronisation)
Mixer-SSRC:10
Mikrophon
(Audiodaten)
SSRC:2
SSRC:10
CSRC:1,2
Netzwerk
SSRC:2
Abb.4.1.2-2: Schematische Darstellung der Arbeitsweise eines RTP-Mixers
Der Übersetzer leitet die Daten weiter, ohne Inhalt oder SSRC des Datenstroms zu verändern.
Er kann einen „Tunnel“ ermöglichen, um z.B. Multicast in Unicast zu übersetzen oder eine
Firewall zu überwinden.
Die Größe des RTP-Paketes ist abhängig von dem unterliegenden Transportprotokoll, in der
Regel also vom UDP-Paket. Jedes Paket ist in Header und Payload, die eigentlichen Nutzdaten,
unterteilt.
8
0 bit
V
P X
CC
16
M
24
31
Sequence Number (SEQ)
PT
Timestamp (TS)
Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifiers (0-15)
Abb. 4.1.2-3: RTP-Header
V:
P:
X:
CC:
M:
- Gibt die Versionsnummer von RTP an
- Padding Bit Flag gesetzt, wurden am Ende des Pakets Padding-Oktetts
angehängt
- Nur bei Kryptographie eingesetzt
- Extention Bit gesetzt, folgt nach dem Header noch ein optionaler
Erweiterungsheader
- CSRC-Zähler gibt an, wie viele SSRCs (max. 15) die CSRC-Liste enthält
- Anwendungsspezifisch definierbares Flag
Seite 35 von 58
Eva Feldmann
- Zur Markierung bestimmter Punkte im RTP-Paket-Strom verwendet
PT:
- Payloadtype gibt Art der Nutzlast (Kodierung des Datenstroms) an
- Folgt nach dem Header im Paket
SEQ: - Gibt Sequenznummer des aktuellen Pakets im Datenstrom an
- Notwendig für Empfänger, damit er Pakete in sende Reihenfolge ordnen kann
TS:
- Zeitstempel, zu dem das Paket erstellt wurde
SSRC: - Eindeutige, zufällig gewählte Kennzeichnung der Quelle des Pakets
CSRC: - Liste von bis zu 15 SSRCs, die vom Mixern im Datenstrom integriert wurden
4.1.3 RTCP - RealTime Transport Control Protocol
Beim RealTime Transport Control Protokoll (RTCP) handelt es sich um ein Kontrollprotokoll,
das in direkter Verbindung mit RTP arbeitet. RTP ermöglicht den Erhalt von Informationen über
den Ablauf des Datentransports und die Verbindungsqualität. Es basiert auf dem periodischen
Austausch dieser Informationen (Kontrollpaketen) an alle Teilnehmer einer RTP-Sitzung über
eine separate Verbindung. Dadurch wird eine dynamische Skalierung der Anwendung und
eine flexible Anpassung an die jeweilige QoS-Parameter erreicht. Die Häufigkeit der RTCPNachrichten ist abhängig von der Bandbreite und der Anzahl der Teilnehmer einer Sitzung und
wird von RTCP selbständig geregelt. Die Bandbreite für RTCP-Nachrichten ist begrenzt. Es
sollten ca. 5% der Netzauslastung einer RTP-Sitzung für RTCP-Nachrichten benutzt werden,
wobei mind. 25% dieser Bandbreite für die Übertragung von Sendeberichten verwendet
werden sollen. Durch die Auswertung der RTCP-Nachrichten kann festgestellt werden, ob zu
viele Datenpakete verloren gehen. Der Sender kann daraus schließen, dass die zur Verfügung
stehende Bandbreite zu gering ist. Um den Bandbreitenbedarf zu reduzieren, kann er Daten
umkodieren oder auf alternatives Material mit geringerer Größe zurückgreifen.
Der Empfänger kann anhand der RTCP-Berichte entscheiden, wie er mit verspäteten DatenPaketen umgeht. Ist nur eine geringe Verspätung zu erwarten, kann er auf die Pakete warten,
anderenfalls werden die Pakete verworfen. Auch Dritte, z.B. Netzwerkadministratoren, können
wertvolle Informationen aus den Nachrichten ziehen.
Die Übertragung via RTP wäre ohne RTCP fehleranfälliger. Durch die zusätzlichen
Informationen wird die Zuverlässigkeit des RTP erhöht.
Die Hauptaufgaben von RTCP sind die Ermittlung der Qualität der Datenleitung, die
Überwachung und Regulierung der Bandbreite der RTCP-Pakete, die Zuweisung eines
eindeutigen Namens zu jeder Datenquelle und der Austausch von Informationen über die
Seite 36 von 58
Eva Feldmann
4.1.3 RSVP - Resource Persercation Protocol
Sitzung und ihre Teilnehmer, also hauptsächlich die Überwachung der QoS-Parameter.
RTCP verfügt über fünf verschiedene Paketarten, welche alle eine ähnliche Struktur aufweisen.
Nach dem Header folgt der Nutzteil mit variabler Länge, dieser besteht aus einer Liste von
SSRCs und je nach Paketart aus verschiedenen Informationen. Ausnahme ist der Sendebericht,
welchem zwischen Header und SSRC-Liste ein Teil mit Senderinformationen angehängt ist.
Header
ggf.
Senderinformation
SSRC_0
mit paketartspez.
Informationen
SSRC_n
mit paketartspez.
Informationen
Abb. 4.1.3-1: Struktur eines RTCP-Paketes
Paketarten von RTCP
Senderberichte (SR) und Empfangsberichte (RR)
Der Header enthält Informationen über die Version, Padding, Länge des Paketes und die
SSRC des Senders. Der Payloadtype Wert ist 200. Beim Sendebericht folgt ein Teil mit
Senderinformationen, z.B. mit der Anzahl der bis zu diesem Zeitpunkt vom Sender erzeugten
Datenpakete. Danach folgt in beiden Berichten für jede SSRC eine Empfangsstatistik. Diese
enthält Informationen über den Transport z.B. die Sequenznummer des letzten empfangenen
Paketes und Anzahl der verlorenen Pakete seit dem letzten Bericht
Quellenbeschreibung (SDES)
Die SDES enthalten Informationen über ihre Sender. Jeder Teilnehmer der RTP-Sitzung
sendet in regelmäßigen Abständen Quellenbeschreibungspakete. Der Header gleicht in der
Struktur dem des Sendeberichtes, hat aber den Payloadtype 202. Es folgen als Nutzdaten die
Beschreibung einer oder mehrerer SSRCs.
Mögliche Angaben sind z.B.:
CNAME:
Eindeutige Identifizierung der Quelle anhand Benutzer- und
Domainnamens der Quelle. Es ist der einzige verpflichtende Eintrag
LOC:
Geographischer Aufenthaltsort des Teilnehmers
TOOL:
Eingesetztes Programm
NOTE:
Statusmeldung des Benutzers
PRIV:
Anwendungs- und benutzerspezifische Quellenbeschreibung
NAME/EMAIL:
Name bzw. E-Mail Adresse des Benutzers
Seite 37 von 58
Eva Feldmann
Goodbye Pakete (BYE) hat den Payloadtype 203. BYE werden verwendet, um den Empfänger zu informieren,
dass eine oder mehrere SSRC-Quellen nicht länger zur Verfügung stehen. Die Nutzdaten
bestehen aus einer Liste der ausscheidenden SSRCs, die optional um den Grund der
Ausscheidung ergänzt ist, z.B. Log Off. Dieser muss, falls es gesendet wird, als letztes in
einem zusammengesetzten Paket stehen.
Anwendungsspezifische Pakete (APP) zum Austausch von Informationen, die noch nicht durch andere Protokolle abgedeckt sind.
Empfängt die Anwendung ein APP-Paket, das sie nicht interpretieren kann, ignoriert sie es.
Es wirkt sich nicht negativ auf den weiteren Datentransport aus. Um Nutzen aus Paketen zu
ziehen, müssen die sendende und die empfangende Applikation die jeweiligen APP-Pakete
kennen.
Seite 38 von 58
Eva Feldmann
Das Resource Persercation Protocol (RSVP) ist ein Kontrollprotokoll für Netzwerke
zur Reservierung bestimmter, zur Datenübertragung benötigter Ressourcen, um eine
gleichbleibende Verbindungsqualität, den Quality of Service (QoS) zu gewährleisten. RSVP
ist eine gemeinsame Entwicklung von MIT, dem Palo Alto Research Center (PARC) und dem
Internet Sciences Institute (ISI) der University of California. Im September 1997 wurde die
Version 1.0 als Standard (RFC 2205) festgesetzt. Die RSVP Working Group der IETF kümmert
sich um die Weiterentwicklung und Implementierung.
RSVP reserviert auf jedem Knoten zwischen Sender und Empfänger die entsprechende
Bandbreite. Es setzt auf der IP-Schicht auf und steht zwischen ihr und der Transportschicht.
Weder der Datentransport noch das Routing werden von RSVP übernommen, dies bleibt
anderen Protokollen überlassen. Es unterstützt die Dienste der Kommunikationsschicht besser
als andere Transportdienste.
Auch die Festlegung der QoS-Parameter, welche Art und Umfang der Reservierung festlegen,
gehört nicht zur Aufgabe von RSVP, sondern zu denen der Anwendungen die es verwenden.
RSVP übernimmt nur die Parameter, transportiert diese zu den Netzwerkknoten und kontrolliert
den Ablauf der Reservierung der Knoten.
Funktionsweise von RSVP
Die Reservierung der Bandbreite muss stattfinden, bevor die eigentlichen Nutzdaten eines
Streams über die Transportverbindung gesendet werden können.
192.168.0.13
Sender
QoS
192.168.0.44
192.168.0.13
Path-Zustand / -Nachricht
192.168.0.45
QoS
192.168.0.44
Nutzdaten
QoS
192.168.0.133
192.168.0.45
Empf.
Resv-Zustand / -Nachricht
Abb. 4.1.4-1: Ablauf RSVP Reservierung
Zur Reservierung der Bandbreite sendet der Sender eine Path-Nachricht an den oder die
Empfänger. Diese ist wie die späteren Datenpakete adressiert und wird über die gleichen
Netzwerkknoten wie der spätere Datenstrom geroutet. Es setzt in jedem Knoten den
Pfadzustand, welcher unter anderem einen Verweis auf die IP-Adresse der vorherigen Knoten
enthält.
Seite 39 von 58
Eva Feldmann
Der Empfänger wertet nach Eintreffen der Path-Nachricht diese aus und sendet eine ResvNachricht zurück an den Sender. Das Resv-Paket verwendet die Pfadzustände der einzelnen
Knoten und kommt somit auf dem gleichen Weg zurück.
RSVP setzt an jedem Knoten Reservierungszustände mit der benötigten Verbindungs-qualität.
Die eigentliche Reservierung geht demnach vom Empfänger aus.
Wenn RSVP-Daten die Netzwerkknoten durchlaufen, welche das Protokoll nicht unterstützen,
werden sie unbearbeitet an den nächsten Knoten weiter gereicht. Es entsteht eine potentielle
Schwachstelle in der Knotenkette. Nachfolgende RSVP-fähige Knoten können aber
Reservierungen dennoch vornehmen. Kann eine Reservierung nicht gewährt werden, gibt
RSVP eine Fehlermeldung zum entsprechenden Empfänger zurück. Der Sender kann nach
Erhalt der RSVP-Nachricht mit dem Senden des Datenstroms beginnen. RSVP verfolgt das
„Soft-State-Prinzip“. Dies bedeutet, dass die gesetzte Reservierung für den Netzwerkknoten
aufgefrischt werden muss, um nicht zu verfallen. Der Sender übermittelt in regelmäßigen
Abständen Path-Nachrichten. Haben sich die durchlaufenden Netzwerkknoten, also das
Routing verändert, werden durch die Path-Nachrichten neue Knoten erfasst. Der Resv-Zustand
wird durch darauf folgende Resv-Nachricht aufgefrischt oder auf einen neuen Knoten gesetzt.
Die Knoten, über die nicht mehr geroutet wird, lösen den Reservierungszustand selbständig
auf, wenn sie keine RSVP-Nachrichten mehr erhalten.
Reservierungsmechanismus
In der Resv-Nachricht sind alle Informationen enthalten, die der Netzwerkknoten braucht,
um den Reservierungszustand zu setzen. Sie enthält neben allgemeinen Angaben wie
Absenderadresse oder Session einen „Flow Descriptor“. Dieser besteht aus „Flow Spec“ und
„Filter Spec“.
Der Flow Spec enthält die Informationen, der zu reservierenden Verbindungsqualität. Zum
einem ist es die Dienstklasse der Reservierung, dabei sind „Controlled-Load Service“ und
„Guaranteed Service“ möglich. Beim „Controlled-Load Service“ hat der Datenstrom eine
konstante Bandbreite unabhängig von der Knotenbelastung reserviert. Der „Guaranteed
Service“ definiert bestimmte Verzögerungen, innerhalb derer die Daten den Empfänger
erreichen müssen. Es wird die Verbindungsqualität zugesichert, nicht die Bandbreite. Die
Eckdaten der gewünschten Verbindung, wie Bitrate, sind in der Reservation Spec als Teil
der Flow Spec enthalten. Die Struktur des Datenstroms in der Traffic Spec (z.B. maximale
Paketgröße) beschreibt, welche Flow Spec abschließt.
Seite 40 von 58
Eva Feldmann
Die Filter Spec ist der Teil der Reservierungsanforderung, der definiert, welche Pakete die
reservierte Bandbreite nutzen dürfen. Sie enthält hauptsächlich die Absenderadresse und
optional dessen Quellport, also ähnliche Informationen wie Resv-Nachrichten. Dies wird beim
Empfänger dann zur Erstellung von Resv-Nachrichten genutzt.
192.168.0.45
(RSVP)
Routing
192.168.0.44
Resv
QoS
Flow
Spec
Flow
Spec
Packet
Classifier
Packet
Scheduler
Admission
Control
Admission
Control
Daten
Abb. 4.1.4-2: Reservierung in einem Netzwerkknoten
Empfängt ein Knoten eine Reservierungsanforderung, dann übergibt der RSVP-Prozess die
Nachricht zunächst an die Admission Control. Er prüft den Inhalt und reserviert bei positiver
Prüfung die Ressourcen. Die Nachricht wird erst an Admission und Policy Control gegeben,
welche prüfen, ob der Besitzer zur Reservierung berechtigt ist und ob dem Knoten ausreichend
Ressourcen zur Verfügung stehen. Sind die Tests positiv, werden Packet-Classifier und Scheduler konfiguriert. Der Packet Classifier ordnet jedes empfangene Datenpaket einer QoSKlasse zu. Und der Packet-Scheduler sorgt basierend auf Flow Spec dafür, dass die Qualität
der Verbindung aufrecht erhalten wird. Anschließend wird eine neue Resv-Nachricht an den
nächsten Knoten weitergeleitet.
Funktionalitäten und wichtige Eigenschaften von RVSP
Die Verbindungsqualität wird lediglich für Daten vom Server garantiert, da RSVP bei der
Reservierung nur eine Simplex-Verbindung unterstützt. Daten vom Empfänger können die
Reservierung nicht nutzen. RSVP unterstützt Multi- und Unicast.
Bei Multicast treffen die Resv-Nachrichten von mehreren Teilnehmern an einem Netzwerkknoten
zusammen und verschmelzen zur erweiterten Reservierungsanfrage. Um den Datenverkehr
nicht unnötig zu erhöhen, kann eine große Anzahl von Teilnehmern einer Multicast-Gruppe
beitreten. Der Einsatz von RVSP ist langfristig möglich, weil es auch IPv6 netzwerkfähig ist. Es
wird auf längere Sicht Standard für die Sicherung von Bandbreiten in IP-Netzwerken bleiben.
Seite 41 von 58
Eva Feldmann
4.2 PNA - Progressive Networks Audio
4.2 PNA - Progressive Networks Audio
Das PNA-Protokoll wird von RealNetworks bis zum RealSystem 5.0 benutzt. Im RealSystem
G2 wurde es dann durch RTSP ersetzt. Die RealServer und RealPlayer unterstützen noch PNA
aus Gründen der Abwärtskompatibilität.
Sowohl PNA als auch RTSP versenden Mediaclips standardmäßig über One-Way UDPVerbindung. Zur Übertragung der Steuerungs- und Kontrollinformationen wird eine parallele
TCP-Verbindung genutzt.
4.3 MMS - Microsoft Media Server Protocol
Das Microsoft Media Server Protocol (MMS) wird von Microsoft zur Übertragung von
Datenpaketen und Steuerungsbefehlen vom Server zum Client genutzt. MMS ist die DefaultMethode der Verbindungsaufnahme der Clients mit dem Windows Media Unicast Service. Die
für Streaming notwenige Infrastruktur wird von Microsoft monolithisch gestellt. Microsoft
sieht keine Notwendigkeit der Offenlegung dieses Standards.
Denn es wird somit die Entwicklung von Software, die illegal auf digitale Rechte von Microsoft
Digital Rights Management (DRM) einwirken könnte versucht zu unterbinden.
MMS arbeitet nicht mit Klartext-Nachrichten wie RTSP, sondern die Kommandos und
Parameter werden binär kodiert (Hexadezimal-Werte). Die kryptische Verschlüsselung ist für
Netzwerkadministratoren und Streaming-Media-Architekturen von Vorteil.
MMS regelt die Kontrollmechanismen des Streams als auch den Transport selbst. Zu
Sitzungsbeginn wird das optimale Protokoll für den Client ausgewählt. Die Übertragung
kann innerhalb des MMS mittels HTTP, TCP und UDP stattfinden. Für TCP und UDP wird
serverseitig der Port 1755 zugewiesen.
Die Steuerbefehle erreichen per TCP ihr Ziel. Zur Datenübertragung wird ein Prinzip
namens Protocol Rollover genutzt. Beim Protocol Rollover sendet der Client den Datenstrom
nacheinander über verschiedene Protokolle. Zum einen über Microsoft Media Server Protocol/
UDP (MMSU), wobei versucht wird die Daten über eine UDP-Verbindung zu senden.
Beim Microsoft Media Server Protocol/ TCP (MMST) werden die Daten über eine TCPVerbindung versendet. Wenn die ersten zwei Versuche scheitern, wird versucht, die Daten über
das Hypertext Transfer Protocol (HTTP) zu senden. Der Grund für diese Technik sind die
Seite 42 von 58
Eva Feldmann
Firewall-Systeme vieler Firmen, die viele Dienste und Ports blocken, HTTP aber in den meisten
Fällen durchlassen. So können auch Nutzer hinter einer Firewall Streaming Media empfangen.
Phasen einer MMS-Sitzung
Die MMS-Sitzung besteht wie die RTSP-Sitzung aus verschiedene Phasen, welche anhand
dieser Grafik kurz erläutert werden.
WebServer
StreamingServer
Web-Seitenabruf
Aufbau der Kontrollverbidung
Media Player
Web-Browser
Client
Test der Verbindungseigenschaften
Medienauswahl
Aufbau der Transportverbindung
Medienkontrolle
Transportüberwachung
Abbau der Kontrollverbindung
Abb. 4.3-1: Phasen einer MMS-Sitzung
Web-Verbindung
Vor der eigentlichen MMS-Sitzung wird die Verbindung zum Webserver aufgebaut. Dabei
empfängt dieser eine Meta-Datei mit der gewünschten Adresse des Streams.
Aufbau der Kontrollverbindung
Clientseitig wird als Kontrollverbindung eine MMS-Verbindung zum Server aufgebaut. Die
MMS-Sitzung beginnt, welche bis zum Ende der Verbindung bestehen bleibt. Der Stream
wird über das Transportprotokoll zum Client gesendet.
Über die Kontrollverbindung erhält der Client vom Server Informationen wie z.B. die
verschiedenen Tonspuren, Länge des Streams usw.
Seite 43 von 58
Eva Feldmann
Test der Verbindungseigenschaften
Der Server versendet einige Testpakete an den Client. Es werden die Verbindungseigenschaften zwischen Server und Client und die Güte der Verbindung aus der Verzögerung
und der Empfangsrate vor dem Versenden des Streams ermittelt. So kann zur Anpassung
bei schlechten Verbindungseigenschaften ein Stream mit niedrigerer Qualität angefordert
werden.
Medienauswahl
Der Client kann anhand der Informationen über die einzelnen Streams den gewünschten
Stream auswählen. Er kann z.B. die Tonspur in seiner Landessprache wählen oder den
Stream mit einer niedrigeren Auflösung anfordern.
Aufbau der Transportverbindung
Nach der Auswahl des gewünschten Streams wird die Transportverbindung aufgebaut.
Medienkontrolle
Der Betrachter kann Einfluss auf den Stream nehmen z.B. unterbrechen, vor- oder
zurückspulen (nicht bei Live-Streaming).
Transportüberwachung
Es werden ständig statistische Daten über die Übertragung ausgewertet und damit der
Transport vom Server ständig überwacht. MMS ermöglicht die Auswertung empfangener
Daten beim Client und einen zeitlichen Versatz.
Abbau der Kontrollverbindung
Kontroll- und Transportverbindung wird in einem Schritt abgebaut, da MMS ein eigenes
Transportprotokoll definiert. Die MMS-Sitzung wird damit beendet.
Typischer Verlauf einer MMS-Sitzung
Die Grafik zeigt die relevanten Teile einer MMS-Verbindung. Die konkreten Kommandos
können dabei variieren, weil kein offener Standard in den unterschiedlichen Versionen der
Player und Server existiert. MMS ist ein relativ komplexes Protokoll.
Seite 44 von 58
Eva Feldmann
WebServer
1
StreamingServer
HTTP-Request GET
[URL]
HTTP-Response
2
[Meta-Datei. ASX]
3
Media Player
Web-Browser
Client
MMS-0x01
[Setup]
MMS-0x01
[Setup]
4 MMS-0x18
[Timing Request]
MMS-0x15
[Timing Replies]
5 MMS-0x05
[File Name. Path Request]
6
7
8
MMS-0x15
[Header Request]
MMS-0x06
[File Details. Packet Info]
MMS-0x33
[Stream IF, Switch]
MMS-0x07
[Start From]
MMS-0x11
[Send Header]
MMS-0x21
[Accept]
MMS-0x05
9
Stream-Pakete (ASF, Header)
10 MMS-0x0D
[Pause]
11 MMS-0x09
[Stop]
Abb. 4.3-2: Ablauf ASF Stream Redirector File (ASX)
1
Das Video wird nach Auswahl eines Links im Browser angefordert.
2
Der Webserver antwortet auf die Anfrage mit dem ASF Stream Redirector File
(ASX). Eine XML-Datei, welche derMeta-Datei bei RTSP ähnelt.
Bsp.: <ASX version=”3.0”>
<Entry>
<Ref href=”mms://stream.beispielseite.de/video/trailer.wmv”/>
</Entry>
</ASX>
Seite 45 von 58
Eva Feldmann
3
Der ASX-File wird an den Media Player übergeben, welcher eine Verbindung zur
URL herstellt. Er kann mehrere Streams enthalten, welche synchronisiert
wiedergegeben werden. Mit dem Kommando 0x01 wird z.B. Version, Hostname
usw. zwischen Client und Server ausgetauscht. Der Client sendet anschließend
Informationen über den Internetzugang (Providername, Benutzer-Login).
4
Der Client initiiert mit 0x18 einen Timing Request, den der Server mit zufälligen
Paketen in 0x15 beantwortet. Dies ermöglicht die Schätzung von Latenzzeiten
und Jitter der Verbindung.
5
Der Client sendet mit 0x05 eine Anfrage nach den gewünschten Dateinamen
und dessen Pfad. Der Server beantwortet diese mit 0x06 und Informationen über
Kodierung, Pakete und Länge.
6
0x15 fordert zum Senden des Headers auf.
7
Die Entscheidung, welchen Stream er erhalten will, trifft der Client. Durch einen
sogenannten Switch können besondere Eigenschaften automatisch angefordert
werden.
8
Mit 0x07 entscheidet der Client, ab welchem Frame er die Wiedergabe
beginnen möchte (Vergleichbar mit Parameter Rang der Methode PLAY
beim RTSP).
9
Ab dem Kommando 0x05 vom Server wird der Stream in Form von MMSPaketen mit ASF-Inhalten per HTTP, TCP oder UDP gesendet.
10
0x0D entspricht ungefähr der Methode PAUSE bei RTSP.
11
0x09 beendet die Wiedergabe und schließt die Verbindung.
Ähnlich wie beim RTCP sendet der Windows Media Server an den Client ca. jede Minute eine
Statistik über den Streamingverlauf und fragt von ihm Daten ab. Dadurch ist eine Anpassung
des Streams an die Netzwerksituation möglich. Erhält der Server keine Nachricht mehr vom
Client, trennt er die Verbindung automatisch.
Seite 46 von 58
Eva Feldmann
Transportprotokolle bei MMS
MMS kann TCP, UDP oder HTTP für den Datentransport verwenden. Es besitzt also
strenggenommen kein eigenes Transportprotokoll. Die Übertragunspakete haben eine
RTP-ähnliche Struktur. Dabei kommen ASF-Pakete zum Einsatz. Dieses Format wurde von
Microsoft offen gelegt. Man kann ASF-Streams als Audio-/ Video-Komponeten verstehen, die
gespeichert werden können: Videos in WMV (Windows Media Video) oder Audio in WMA
(Windows Media Audio)-Files. Es sind mehrere ASF-Segmente in einem IP-Paket per TCP
oder UDP möglich. Der MMS-Header ist den einzelnen Segmenten vorangestellt. Dieser
enthält analog zu RTP vor allem die Sequenznummer. Die Segmente enthalten zusätzlich ein
ASF-Zeitstempel zur Synchronisierung der Streams.
IP
UDP/TCP
ASF-Segment
ASF-Segment
Sequenznummer
Paket ID Typ
UDP Seq. / TCP Flags
Header Länge
ASF Zeitstempel
...
MMS-Header
UDP-User Datagramm Protocol, TCP = Transmission Control Protocol
Abb. 4.3-3: Struktur eines ASF-Paketes
MSBD - Media Stream Broadcast Distribution Protocol
Das verbindungsbasierte Media Stream Broadcast Distribution Protocol (MSBD) wird von
Microsoft für Live-Broadcast bei der Übertragung vom Encoder zum distribuierenden Server
verwendet.
Für bestimmte Anwendungen (z.B. für firmeninterne Präsentationen mit begrenzter
Teilnehmerzahl) kann der Windows Media Encoder über das MSBD-Protocol auch als
kleine Serverlösung genutzt werden. In der Version 7 wurde auf die Nutzung von MSBD als
verbindungsbasiertes Streaming Protokoll verzichtet und sich ganz auf HTTP verlassen.
Seite 47 von 58
Eva Feldmann
In Netzwerken wie auch im Internet stehen zum Transport von Daten vom Empfänger drei
wichtige Verfahren zur Verfügung. Die meisten Anwendungen im Internet benutzen eine
Unicast-Verbindung. Bei dieser wird eine Kopie angeforderter Daten genau an einen Empfänger
gesendet. Werden die selben Daten von verschiedenen Empfängern angefordert werden diese
mehrfach separat versendet.
Broadcast sendet eine Kopie der angeforderten Daten an alle im Netzwerk verfügbaren
Empfänger. Dabei muss jeder Empfänger diese Daten auswerten und entscheiden, ob sie für
ihn eine Bedeutung besitzen. Da es sich beim Streaming um breitbandintensive Inhalte handelt,
ist bei der Vielzahl der Clients Braodcast weder durchführbar noch zweckmäßig.
Multicast hingegen sendet an eine Gruppe von Clients eine Kopie der Daten. Die Daten
müssen nicht mehrfach vom Server versendet werden, trotz dass nur interessierte Clients diese
empfangen. Die verschiedenen Kommunikationsformen zwischen Rechnersystemen lassen
sich nach der Anzahl der Sender und Empfänger unterscheiden.
Kommunikationsform
Unicast
Concast
Multicast
Multipeer
Broadcast
Anzahl der Sender
1
N
1
N
1
Anzahl der Empfänger
1
1
N
M
Alle Netzwerkteilnehmer
Tabelle 5-1: Übersicht der Kommunikationsformen
5.1 Unicast
Unicast ist eine Punkt zu Punkt-Verbindung. Jeder Endanwender erhält einen separaten Stream.
Bei Unicast wird für jeden abrufenden Player eine neue Verbindung geöffnet, über die der Stream
die Steuerbefehle erhält. So ist es möglich, dass der Client dem Server Anweisungen zukommen
lassen kann, z.B. zum Unterbrechen, Wiederholen, Springen usw.. Diese Steuerung ist nur bei
vorab aufgezeichneten Inhalten möglich. Der Server hat keine Möglichkeit den Datenstrom zu
bündeln, wenn mehrere Clients zur selben Zeit den selben Videostream anfordern.
Seite 48 von 58
Eva Feldmann
5.1 Unicast
Der Vorteil liegt darin, dass jeder Betrachter in das Abspielen seiner Streams eingreifen kann,
um z.B. im Inhalt vor- oder zurückzuspringen. Der Nachteil ist dagegen die hohe ServerBelastung, da jeder Client einen exklusiven Datenstrom erhält.
Es kommt zu einer hohen Netzbelastung beim Senden der Daten. Netzressourcen werden
verschwendet, wenn mehrere Streams gleichzeitig den selben Teil der Übertragungsstrecke
nutzen, um verschiedene Clients zu erreichen. Mit jedem Client, der den gleichen Stream
anfordert, steigt die Belegung der Bandbreite linear an.
Der Einsatz von Unicast beim Streaming ist im Bereich „On Demand Streaming“ sinnvoll, um
die Steuerung des Clips (Pause, Stopp, Positionierung) zu ermöglichen.
Abb. 5.1-1: Grafische Darstellung Unicast-Verbindung
5.2 Broadcast
Bei einer Broadcast Verbindung würde der Stream an alle Clients im Netzwerk übertragen
werden. Der Begriff „Broadcasting“ bedeutet Rundfunk. Alle Clients im Netzwerk erhalten zur
selben Zeit den selben Teil des Mediums, unabhängig ob live oder vorab aufgezeichnet.
Broadcast löst zwar das Problem mehrfacher Streams, aber es überschwemmt das gesamte
Netzwerk damit, auch wenn nur einige Endanwender die Inhalte empfangen wollen.
Abb. 5.2-1: Grafische Darstellung Broadcast-Verbindung
Seite 49 von 58
Eva Feldmann
5.3 Multicast
5.3 Multicast
Bei Multicast überträgt der Server nur einen Stream. Dieser Stream wird von speziellen Routern
im Netzwerk zur Verteilung an Gruppen mehrerer Endanwender vervielfältigt.
Der Client erhält wenig Flexibilität, denn jeder sieht die selben Inhalte zur selben Zeit wie alle
anderen. Beim Multicast schickt der Sender die Pakete nur zum nächsten Router. Dieser erkennt
an Hand der Empfängergruppenadresse, wohin er die Pakete routen soll.
Multicast ist demnach gut zur gleichzeitigen Bereitstellung der selben Inhalte für mehrere
Clients z.B. zur Übertragung von Pressekonferenzen, Sportereignissen oder Konzerten. Es
eignet sich für Live-Streaming.
Abb 5.3-1: Grafische Darstellung Multicast-Verbindung
Multicast ist nur möglich, wenn die Streaming-Software und das Netzwerk dies unterstützen.
Serverseitig wird es von Apple, Microsoft und Real unterstützt. Es fallen weitere Kosten durch
die Implementierung an. Aber diese können sich lohnen, wenn Kosten für Schulungen nicht
anfallen und Kosten der Unternehmenskommunikation gesenkt werden.
Der Vorteil liegt in der Reduktion der Bandbreite und Einsparung von ServerVerarbeitungskapazität. Der Streaming-Server muss, wie oben bereits beschrieben, die Daten
nur einmal an eine Gruppen-Adresse senden, damit alle Clients Zugriff darauf haben je mehr
Nutzer, um so größer demnach die Ersparnis. Clients können jederzeit problemlos dynamisch
einer Gruppe beitreten. Die Gruppe ist also unkompliziert skalierbar.
Der Nutzer hat keine Möglichkeit zum individuellen Eingriff, er kann nicht im Inhalt springen.
Der Stream muss vom Server stetig gesendet werden.
Sendet der Server eine Kopie der Daten an eine Gruppe von Clients, so hat diese MulticastGruppe eine Gruppenadresse, welche in IP-Netzwerken immer einer IP-Adresse der Klasse D
entspricht. Sie liegt also im Bereich zwischen 224.0.0.0 und 239.255.255.255. Die Übermittlung
von Multicast erfolgt über spezielle multicastfähige Netzwerke. Das häufigste ist das Internet
Seite 50 von 58
Eva Feldmann
5.3 Multicast
Multicast Backbone, kurz MBone genannt. Die Subnetze bestehen aus Teilen der InternetInfrastruktur, die multicastfähig sind.
Wenn zwischen diesen Teilen gewisse Bereiche vom Internet liegen, welche nicht multicastfähig
sind, nennt man die Subnetzte „Multicast Islands“. Zwischen diesen Multicast Islands,
wird Multicasts über Unicasts weitergeleitet, um die Subnetze miteinander zum MBone zu
verbinden.
Möchte ein Client der Multicast-Gruppe beitreten, sendet er eine IGMP-Nachricht an seinen
lokalen Router mit der Anfrage. Der Client konfiguriert die IP-Einstellungen und Netzwerkkarte
so, dass Multicast empfangbar ist.
Beim Verlassen des letzten Clients aus der Multicast-Gruppe beendet der Router das Senden
auf dem Kanal und gibt die Bandbreite wieder frei. Multicast Routing Protokolle regeln die
Verteilung, um den effizienten Weg und keine Verschwendung von Bandbreite sicher zu
stellen. Verschiedene Multicast Routing Protokolle sind das Distance Vector Multicast Routing
Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF) und das Protocol Independent
Multicast (PIM).
Anstatt des Begriffs Multicast wird manchmal auch der Bergriff Narrowcast verwendet, obwohl
sich Narrowcast normalerweise auf das Handelsmodell bezieht, während mit Multicast die für
die Datenübertragung tatsächlich verwendete Technologie gemeint ist.
Seite 51 von 58
Eva Feldmann
Streaming bietet den Vorteil, dass der komplette Download einer Multimediadatei nicht erst
abgewartet werden muss. Der Inhalt kann während des Downloads betrachtet werden. Die
bisherigen Haupteinsatzgebiete von Streaming liegen in der firmeninternen Kommunikation,
in elektronischen Schulungen, im Vertrieb und im Marketing. Eine Ausweitung auf andere
Anwendungsgebiete ist sinnvoll, um die Vorteile von Streaming auch in anderen Bereichen,
z.B. Software-Lizenzierung oder Pay per View zu nutzen.
Abschließend lässt sich bei der Analyse der technischen Grundlagen für Streaming-Videos
sowie vorhandener Streaming Protokolle feststellen, dass für jede Streaming-Anwendung eine
individuelle, angepasste Lösung gefunden werden kann. Dabei ist einerseits eine günstige
Kommunikationsform (Unicast, Muticast) zu wählen, um Netzwerkressourcen zu schonen.
(Diese Kommunikationsform legt die Streamingart, ob Video On Demand oder Live-Streaming,
fest.)
Zum anderen bilden die Allgemeinen Protokolle eine Grundlage, welche beim echten Streaming
durch speziell entwickelte Streaming Protokolle unterstützt werden.
Es lässt sich feststellen, dass die Übertragung über TCP für Streaming nicht zu empfehlen ist, da
die Fehlerkorrektur eine gleichbleibende Übertragungsgeschwindigkeit nicht garantieren kann.
Deshalb basieren die meisten Streaming Protokolle auf der Basis von UDP. Die Flexibilität der
Streaming Protokolle lässt auch eine Übertragung über TCP zu. Erst durch die Verwendung
von speziellen Streaming-Servern wird der Einsatz der Streaming-Protokolle möglich. Die
Wahl des Servers schränkt die Wahl der genutzten Protokolle ein. Der Vorteil wird dadurch
jedoch nicht aufgehoben.
Streaming-Inhalte benötigen eine andere Architektur als herunterladbare Medien. Sie
müssen eine höhere Interaktivität über das Internet unterstützen. Sie bieten dem Anwender
die Möglichkeit des Durchsuchens, des Vor- sowie Zurückspringens, der Kapitelmarken und
vieles mehr. Um dies zu gewährleisten, ist der Einsatz von speziell entwickelten StreamingProtokollen notwendig. Diese ermöglichen nicht nur eine kontinuierliche Wiedergabe, sondern
auch eine individuelle Anpassung an die Übertragungsgeschwindigkeit.
Die Verwendung von speziellen Media-Servern für Streaminginhalte ermöglicht eine
effizientere Nutzung der Netzwerkbandbreite, eine bessere Audio- und/ oder Videoqualität,
besondere Funktionen und unterstützt den Zugriff durch mehrere Anwender.
Seite 52 von 58
Eva Feldmann
Bücher
Künkel, Tobias (2001) Streaming Media Technologien, Standards, Anwendungen,
München: Addison-Wesley 2001
Internet Publicationen
Neumann, Marco; Heinbockel, Malte (2003): Erstellung eines Videokonferenzsystems
(13.01.2005)(online)
URL: http://www.uni-weimar.de/~kroop/dokus_MS_SS03/Marco-Neumann_Malte-Heinbockel.doc
Schäfer, Waldemar; Beise, Thorsten (2000): Seminar zur Vorlesung Multimedia
(10.12.2004)(online)
URL: http://www.it.fht-esslingen.de/~schmidt/vorlesungen/mm/seminar/ss00/HTML
Dipl.-Inform. Dachselt, R. (2004): Streaming Medien (1 Einführung in Streaming
Medien, Begriffe, Medientypen, Gesamtprozeß, Protokolle; 2 Von der Produktion bis zur
Auslieferung: Streaming-Architekturen) (30.12.2004)(online)
URL: http://www-mmt.inf.tu-dresden.de/Lehre/Sommersemester_04/Vo_SM/index.htm
Schädler, Martin (1999): Erweiterung eines RTP Recorders um Mechanismen zur
Aufzeichnung ereignisorientierter Medienströme (09.12.2004)(online)
URL: http://pi4.informatik.uni-mannheim.de/~hilt/publications/MartinSchaedlerDipl.pdf
Mieves, Hendrik: Real-time Transport Protocol / RTP Control Protocol – Ein Internet
Protokoll für multimediale Datenströme (09.12.2004)(online)
URL: www.informatik.tu-darmstadt.de/BS/Lehre/Sem99/proceedings/p106-final.ps
Bölsterli, Stefan; Frick, Philip (2003): Verteilte MPEG4 Videoüberwachung
(09.12.2004)(online)
URL: www.medialab.ch/archiv/pdf_studien_ diplomarbeiten/da03/Videouebertragung.pdf
Dr.-Ing. Theile, Günther; Dipl.-Ing. StollI, Gerhard (2005): Internet Streaming
(28.12.2004)(online)
URL: http://www.irt.de/IRT/FuE/as/ASinternet.htm
Seite 53 von 58
Eva Feldmann
Rieger, Sebastian (2003): Streaming-Media und Multicasting in drahtlosen Netzwerken
(13.12.2004)(online)
URL: http://www.gwdg.de/forschung/publikationen/gwdg-berichte/gwdg-bericht-61.pdf
H. Schulzrinne, A. Rao, R. Lanphier (1998): Real Time Streaming Protocol (RTSP)
(23.12.2004)(online)
URL: http://www.cs.columbia.edu/~hgs/rtsp/draft/draft-ietf-mmusic-rtsp-09.pdf
Barz, Bernhard; Lanyi, Katrin (2000): Streaming Media im Internet (24.2.2004)(online)
URL: http://edoc.hu-berlin.de/e_rzm/20/bynum/3.pdf
Adobe Dynamic Media Group (2001): Leitfaden für Streaming Media (25.2.2004)(online)
URL: http://www.adobe.de/products/premiere/pdfs/smprimer_de.pdf
Staab, Markus; Indra, Andreas (2002): Streaming Media (24.2.2004)(online)
URL: http://www.tfh-berlin.de/~godberse/semesterarbeiten/ia2/streaming.pdf
Herche, Daniel u.a. (2000): Streamingtechnologien für Videodaten (31.10.2004)(online)
URL: http://eldorado.uni-dortmund.de:8080/FB4/ls1/lehre/2000/Streamingtechnologien/SeminarStreamingVid
eosig.pdf
Bauer, Thomas (1999): Webbasiertes skalierbares Videoinformationssystem (WESVIN)
für Forschung und Lehre (14.1.2005)(online)
URL: http://www.cells.de/cellsger/4wir/publikationen/diplomarbeit/tbauer/Diplomarbeit.pdf
slashCAM - channel unit GmbH: slashCAM (14.12.2004)(online)
URL: http://www.slashcam.de
Universität zu Köln: Streaming: Video und Audio im Internet (14.12.2004)(online)
URL: http://www.uni-koeln.de/rrzk/multimedia/dokumentation/streaming/
Book, Matthias (2000): Resource Reservation Protocol / Realtime Transport Protocol
(20.12.2004)(online)
URL: http://www.matthiasbook.de/papers/rsvp-rtp/index.html
Seite 54 von 58
Eva Feldmann
Kapitel
Bezeichnung Tabelle
Seite
3.3-1
Vergleich HTTP- und echtes Streaming
25
(Quelle: Staab, Markus; Indra, Andreas (2002): Streaming Media (S. 13))
4-1
Streaming-Server und unterstützte Protokolle
27
(Quelle: Universität zu Köln: Streaming: Video und Audio im Internet)
4.1.1-1 Beispiel für Zustandsänderung (Quelle: Staab, Markus;
32
Indra, Andreas (2002): Streaming Media (S. 18))
5-1
Übersicht der Kommunikationsformen
48
(Quelle: Schädler, Martin (1999): Erweiterung eines RTP Recorders um
Mechanismen zur Aufzeichnung ereignisorientierter Medienströme (S. 10))
Seite 55 von 58
Eva Feldmann
Kapitel
Bezeichnung Abbildung
Seite
3.1-1
OSI Referenzmodell (Quelle: Herche, Daniel u.a. (2000):
12
Streamingtechnologien für Videodaten (Seite 19))
3.1-2
Weg eines Datenpaketes im Referenzmodell
14
(Quelle: Herche, Daniel u.a. (2000): Streamingtechnologien für
Videodaten (Seite 20))
3.1-3
Zuordnung der Streamingprotokolle in sOSI Referenzmodell
15
(Quelle: Bauer, Thomas (1999): Webbasiertes skalierbares
Videoinformationssystem (WESVIN) für Forschung und Lehre (Seite 9))
3.2-1
Zuordnung des OSI Referensmodells zum TCP/ IP Modell
16
3.2-2
Architekturbeispiel (Quelle: Herche, Daniel u.a. (2000):
17
3.2.1.1-1
Aufbau TCP-Header (Quelle: Herche, Daniel u.a. (2000):
18
3.2.1.1-2
Verbindungsaufbau über „Three way handshake“
20
3.2.1.2-1
Aufbau UDP-Header (Quelle: Herche, Daniel u.a. (2000):
21
4-1
Protokollvergleich von HTTP- und echten Streaming
26
(Quelle: Adobe Dynamic Media Group (2001):
Leitfaden für Streaming Media (Seite 19))
4.1-1
Verbindung während eines Streams (Quelle: Staab, Markus;
28
Indra, Andreas (2002): Streaming Media (Seite 15))
4.1.1-1
Zusammenhang zwischen den Protokollen (Quelle: Neumann, Marco;
29
Heinbockel, Malte (2003): Erstellung eines Videokonferenzsystems (S. 12))
4.1.1-2
Schematische Darstellung einer RTSP-Sitzung (Quelle: Staab, Markus;
30
4.1.1-3
Struktur einer RTSP-Sitzung (Quelle: Staab, Markus;
30
Seite 56 von 58
Eva Feldmann
4.1.2-1
Anordnung des RealTime Transport Protokolls
33
(Quelle: Mieves, Hendrik: Real-time Transport Protocol/ RTP Control
Protocol – Ein Internet Protokoll für multimediale Datenströme (Seite 3))
4.1.2-2
Schematische Darstellung der Arbeitsweise eines RTP-Mixers
35
(Quelle: Staab, Markus; Indra, Andreas (2002): Streaming Media
(Seite 20))
4.1.2-3
RTP-Header (Quelle: Staab, Markus; Indra, Andreas (2002):
35
Streaming Media (Seite 21))
4.1.3-1
Struktur eines RTCP-Paketes (Quelle: Staab, Markus;
37
Indra, Andreas (2002):treaming Media (Seite 22))
4.1.4-1
Ablauf RSVP Reservierung (Quelle: Staab, Markus;
39
4.1.4-2
Reservierung in einem Netzwerkknoten (Quelle: Staab, Markus;
41
4.3-1
Phasen einer MMS-Sitzung
43
(Quelle: Rieger, Sebastian (2003): Streaming-Media und Multicasting in
drahtlosen Netzwerken (Seite 54))
4.3-2
Ablauf ASF Stream Redirector File (ASX)
45
4.3-3
Struktur eines ASF-Paketes
47
5.1-1
Grafische Darstellung Unicast-Verbindung
49
5.2-1
Grafische Darstellung Broadcast-Verbindung
49
5.3-1
Grafische Darstellung Multicast-Verbindung
50
Seite 57 von 58
Eva Feldmann
10 Eidesstattliche Erklärung
Ich erkläre am Eides statt, dass ich die vorloegende Arbeit (entsprechend der genannten
Verantwortlichkeit) selbständig und nur unter Verwendung der angegebenen Quellen und
Hilfsmittel angefertigt habe.
Die Zustimmung der Firma zur Verwendung betrieblicher Unterlagen habe ich eingeholt. Die
Arbeit wurde bisher in gleicher oder ähnlicher Form weder veröffentlicht noch einer anderen
Prüfungsbehörde vorgelegt.
Dresden
Ort
14. Januar 2005
Abgabetermin
Unterschrift des Verfassers
Seite 58 von 58
Eva Feldmann

Detaillierte Analyse der technischen Grundlagen für Streaming

Transcrição

Documentos relacionados

Seminarausarbeitung

Truehouse Internet Streaming Installation

1 Historisches 1969: in der Zeit des Kalten Krieges

Streaming Media im Internet

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Abkürzungsverzeichnis

Nicht-Buch-Medien

Begriffe der Netzwerk-Technologie WAN wide area

Linear VAST 2.0 - Microsoft Advertising

Streaming Video - Universität Osnabrück