Multicast-Proxy-Server für Audio-Live-Streams

Transcription

Multicast-Proxy-Server
für
Audio-Live-Streams
Projektarbeit PA2 / Sna06
21. Mai bis 6. Juli 2001
Reto Glanzmann, José Fontanil
Dozent: Dr. Andreas Steffen
6. Juli 2001
Inhaltsverzeichnis
1. Zusammenfassung und Ausblick...........................................................................4
1.1 Zusammenfassung............................................................................................4
1.2 Ausblick............................................................................................................5
1.3 Zeitplanung......................................................................................................5
2. Grundlagen.............................................................................................................6
2.1 Multicasting......................................................................................................6
2.1.1 IP Multicasting Übersicht....................................................................6
2.1.2 Adressen................................................................................................6
2.1.2.1 IP-Multicast-Adressen..............................................................6
2.1.2.2 Umsetzung der IP-Multicast Adresse in Multicast-MACAdressen im Ethernet...........................................................................7
2.1.3 Internet Group Management Protocol (IGMP)...................................8
2.1.3.1 IGMP Version 1.........................................................................8
2.1.3.2 IGMP Version 2.........................................................................8
2.1.4 Distance Vector Multicast Routing Protocol (DVMRP)......................9
2.1.5 Protocol Independent Multicast (PIM)..............................................10
2.1.5.1 PIM Dense Mode.....................................................................10
2.1.5.2 PIM Sparse Mode....................................................................10
2.1.6 Inter-Domain Multicast......................................................................12
2.1.6.1 Multicast Border Gateway Protocol (MBGP).........................12
2.1.6.2 Multicast Source Discovery Protocol (MSDP)........................12
2.1.6.3 Border Gateway Multicast Protocol (BGMP).........................13
2.1.7 Administrative Konzepte....................................................................14
2.1.7.1 Multicast Scope Control..........................................................14
2.1.7.2 Bandbreitenlimitierung / Flusskontrolle...............................15
2.1.7.3 Aufsetzen eines IP-Multicast-Tunnels...................................16
2.1.8 Router..................................................................................................16
2.1.9 MBone.................................................................................................16
2.1.10 Zukünftige Entwicklungen...............................................................17
2.1.10.1 Multicast in IPv6...................................................................17
2.1.10.2 QoS-Unterstützung für IP-Multicast...................................18
2.2 Streaming.......................................................................................................19
2.2.1 Streaming Übersicht..........................................................................19
2.2.2 Unicast Streaming..............................................................................19
2.2.3 Multicast Streaming...........................................................................21
2.2.3.1 SDP, SAP und SIP...........................................................................23
2.2.3.2 RTP, RTCP und RTSP.....................................................................25
2.3 Multicast Streams per Web publizieren (Bsp. Apache)................................26
2.4 SDR MP3 Audio Plug-In................................................................................27
3. Aufgabenstellung..................................................................................................28
4. Analyse..................................................................................................................29
4.1 Vergleich von Streaming / Proxy Server-Produkten....................................29
Übersicht der verfügbaren Audio-Streaming Produkte.............................30
Doku PA2_Sna06.sdw
Seite 2
© 2001 R. Glanzmann & J. Fontanil
6. Juli 2001
4.2 ZHW MBone Anbindung................................................................................31
5. Realisierung..........................................................................................................33
5.1 Beschreibung unserer Multicast-Streaming Lösung....................................33
5.2 Versuchsaufbau..............................................................................................33
5.2.1 Einführung..........................................................................................33
5.2.2 Darstellung des Testaufbaus.............................................................34
5.2.3 Erläuterungen zum Testaufbau.........................................................35
5.2.4 Performance Aspekte..........................................................................36
5.3 Beurteilung der Lösung.................................................................................37
5.4 Beschreibung der Komponenten...................................................................37
5.4.1 LiveCaster...........................................................................................37
5.4.2 SHOUTcast DNAS-Server..................................................................38
5.4.3 oddcast DSP – Winamp Plug-In.........................................................38
5.5 Kosten / Lizenzierung....................................................................................39
6. Benutzeranleitung................................................................................................40
6.1 Administrator.................................................................................................40
6.1.1 LiveCaster (Multicast-Server)............................................................40
6.1.2 SHOUTcast DNAS-Server (Unicast Server).....................................41
6.1.3 Winamp Plug-In oddcast DSP............................................................43
6.1.4 Winamp Line-In Plug-In....................................................................45
6.1.5 Webpage mit 'tune-in' Angebot (Beispiel Apache)............................45
6.2 Empfänger......................................................................................................47
7. Literaturverzeichnis.............................................................................................48
7.1 Buch................................................................................................................48
7.2 Internet...........................................................................................................48
7.3 RFCs und Internet Drafts..............................................................................50
8. Software Versionen..............................................................................................51
8.1 Auf dem Server / Proxy eingesetzte Software...............................................51
8.2 Auf dem Client eingesetzte Software............................................................51
Doku PA2_Sna06.sdw
Seite 3
6. Juli 2001
1. Zusammenfassung und Ausblick
1.1 Zusammenfassung
Im Rahmen unserer zweiten Projektarbeit im dritten Studienjahr evaluierten
wir Multicast-Streaming-Lösungen für den Campus-Einsatz. Nach Versuchen
mit den einzelnen Komponenten haben wir das geforderte Ziel erreicht. Ein
flexibles, leistungsfähiges und in der Anschaffung erstaunlich preisgünstiges
Gesamtsystem. Die Kosten der eingesetzten Software belaufen sich auf magere
US$ 100, wobei die Anzahl der Zuhörer nicht begrenzt ist.
Die Lösung enthält alle geforderten Features: Proxy-Funktionalität, LiveStreaming ab einer beliebigen analogen Quelle und Multiple-SimultaneousStreaming. Die Streams können bequem per Webinterface bezogen werden.
Der vorliegende Projektbericht soll dem Leser die Grundlagen des Multicastings
und Streamings vermitteln. Weiter ist eine Analyse und komplette Anleitung
zum Aufbau der von uns erarbeiteten Gesamtlösung enthalten. Mit diesen
Unterlagen soll es Firmen und Institutionen ermöglicht werden, innert kurzer
Zeit eine lauffähige Multicast-Proxy-Lösung in Betrieb zu nehmen.
Die Multicasting-Technologie ist heute noch sehr unausgereift. Router müssen
neueste Betriebssystem-Updates haben, neue Routingprotokolle werden noch
nicht von allen Routern unterstützt und gewisse Protokolle haben es noch nicht
einmal auf den Stand eines RFCs geschafft. Gleichwohl glauben wir, dass diese
Technologie eine grosse Zukunft haben wird, nicht nur im Campus-Bereich.
Mit dem MBone existiert jetzt schon ein stetig wachsendes, weltumspannendes
Multicast-Netz mit interessanten Inhalten. Auf unsere Initiative hin, sollte auch
die ZHW in den nächsten Wochen den Anschluss an das MBone erhalten.
Winterthur im Juli 2001
Reto Glanzmann
Doku PA2_Sna06.sdw
José Fontanil
Seite 4
6. Juli 2001
1.2 Ausblick
Mit dieser Projektarbeit wurde der Grundstein gelegt, um sich genauer mit dem
Thema Multicasting zu befassen.
Mögliche Erweiterungen unserer Arbeit wären:
?
Langzeittest des Gesamtsystems
?
Da es trotz Multicasting nicht möglich ist, eine beliebige Anzahl Streams
gleichzeitig anzubieten, benötigt man ein Auswahl- und Bewertungsverfahren.
Wir haben uns vorgestellt, dass dies am einfachsten mit einem eVote-System
per Webinterface zu realisieren ist.
?
Viele Webradio-Stationen senden ihr Angebot in den proprietären RealMediaund Quicktime-Formaten, es wäre deshalb wünschenswert einen Konverter zu
haben, sodass der LiveCaster auch diese Streams empfangen kann.
1.3 Zeitplanung
Da es sich bei dieser Projektarbeit nicht um ein eigentliches Entwicklungsprojekt
handelt, konnten wir keine Planung im klassischen Stil betreiben, da wir nicht
wussten, was überhaupt auf uns zukommen wird.
Zurückblickend kann gesagt werden, dass eine detaillierte Aktivitätenplanung
im voraus für länger als eine Woche kaum möglich ist, da Produkte und Verfahren, die bei einer ersten Betrachtung vielversprechend ausgesehen haben, sich
bei genauerem Studium als völlig untauglich entpuppen und umgekehrt.
José Fontanil & Reto Glanzmann
Schulfreie Zeit
José Fontanil
Reto Glanzmann
KW 21
KW 22
KW 23
KW 24
KW 25
KW 26
KW 27
21.5.01-27.5.01
28.5.01-3.6.01
4.6.01-10.6.01
11.6.01-17.6.01
18.6.01-24.6.01
25.6.01-1.7.01
2.7.01-6.7.01
M D M D F M D M D F M D M D F M D M D F M D M D F M D M D F M D M D F
Militär
Inbetriebnahme Infrastruktur
Projektbesprechung
Aufsetzen LiveCast-Server
Aufsetzen Shoutcast-Server
Aufsetzen Shoutcast-Source
Installation Obsequieum
Suche nach Proxy-Lösungen
Einlesen Multicasting
Krankheit
Multiple Streams per LiveCaster
Audio Live Stream
Ressourcenanalyse
Web-Oberfläche
Daten kommerzielle Produkte
Firmen kontaktieren für Details
Daten nichtkommerz. Produkte
SDR-Plugin
ZHW-MBone-Anbindung
Dokumentation
Die relativ lange, krankheitsbedingte Abwesenheit von Reto Glanzmann brachte
unsere am Anfang erstellte Grobplanung auch noch durcheinander. Wir verzichten hier deshalb, auf die Illustration aller Planungsversionen, da aus unserer
Sicht das Schlussergebnis am aussagekräftigsten ist.
Doku PA2_Sna06.sdw
Seite 5
6. Juli 2001
2. Grundlagen
2.1 Multicasting
2.1.1 IP Multicasting Übersicht
Schon Mitte 1993, noch bevor die Inflation von multimedialen Präsentationen im
World Wide Web richtig angefangen hatte, war es für einige wenige schon möglich, die Übertragung eines Space-Shuttle-Flugs auf einer SUN-Workstation live
miterleben zu können. Dies waren erste Anwendungen des IP-Multicasting im
Rahmen des 1992 erschaffenen Multicast-Backbones, auch MBone genannt. Da
der MBone nur ein virtuelles Overlay-Netzwerk auf der eigentlichen InternetStruktur darstellt, ist es relativ einfach neue Verbindungen zu etablieren, da
physisch keine neuen Leitungen geschaltet werden müssen.
Multicasting bietet im Wesentlichen eine günstige und intelligente Möglichkeit,
one-to-many und many-to-many Verbindungen zu ermöglichen, beziehungsweise
zu routen.
In den nächsten Kapiteln sollen der Aufbau des Multicast-Adressraums und die
gebräuchlichsten Routing-Protokolle erläutert werden. Es werden auch zwei
verschiedene Router vorgestellt. Weiter wird noch auf das Session Description
Protokoll eingegangen. Mit ihm ist es möglich, seine Multicast Beiträge lokal
oder weltweit anzukündigen. Es ist für das Verständnis des Resultats dieses
Praktikums nicht nötig, Multicasting in dieser Tiefe verstehen zu müssen, jedoch
ist es vorteilhaft.
2.1.2 Adressen
Nun folgend wird der Aufbau der Layer 3 Multicast Adressen und deren Zuordnung zur Ethernet-Layer 2 Schicht näher betrachtet.
2.1.2.1 IP-Multicast-Adressen
In der Version 4 des IP-Protokolls werden die verfügbaren 32Bit-Adressen zunächst einmal in grobe Adressräume unterteilt: A, B, C, D, E. Aus der Grafik
kann man entnehmen, dass für die genauere Betrachtung nur die Gruppe D interessant ist. Der IP-Multicast-Adressraum umfasst alle IP-Adressen von
224.0.0.0 bis 239.255.255.255 (Siehe auch noch Kapitel 2.1.7.1).
Doku PA2_Sna06.sdw
Seite 6
6. Juli 2001
Multicast-Adressen werden keinem einzelnen Host, Router oder Netzwerkkarte
zugeordnet. Multicast-Adressen werden einer sogenannten Multicast-Gruppe erteilt. Die Gruppenteilnehmer hören alle auf dieselbe, bekannte Multicast-Adresse
und empfangen so die für sie bestimmten Daten.
Die IANA (Internet Assigned Numbers Authority) hat den Multicast-Adressraum
feiner unterteilt und je nachdem einzelnen Multicast-Anwendungen oder Routing-Protokollen zugeordnet. Die meisten dieser 'reservierten' Adressen dienen
administrativen Zwecken oder enthalten Managementinformationen. Der
Adressbereich zwischen 224.0.0.0 und 224.0.0.255 ist generell nur für die
Managementkommunikation innerhalb eines Subnetzes vorgesehen und wird
von Routern nicht über das lokale Netzwerk hinaus weitergeleitet. Die vollständige Liste aller reservierten Adressen findet man in der RFC-1700.
2.1.2.2 Umsetzung der IP-Multicast Adresse in Multicast-MAC-Adressen im Ethernet
Wie werden die Daten nun im Ethernet MAC-Layer (OSI-Layer 2) weiter verteilt? Im uns bekannten Unicast Fall geschieht das, indem dem IP-Paket der
MAC-Header mit der entsprechenden MAC-Adresse (48 Bit) des Empfängers vorangestellt als Ethernet-Frame aufs Netz gesendet wird. Die Umsetzung beim
Unicast übernimmt das ARP-Protokoll (Address Resolution Protocol).
Da es sich beim Ethernet um ein Broadcast-Netz handelt, muss man ein IP-Multicast-Paket also nur aufs Netz legen und schon können alle im gleichen Netzwerksegment angeschlossenen Benutzer die Multicast-Pakete erhalten. Ethernet
bietet weiter sogenannte Multicast-Adressen auf der MAC-Ebene, auch Hardware-Multicast genannt. Wenn ein User also einer Multicast-Gruppe beitritt, instruiert er seine Netzwerkkarte einfach dazu, diese Pakete an die IP-Schicht
weiterzuleiten.
MAC-Multicast-Adressen bestehen von links nach rechts gelesen aus der Herstellerkennung der IANA, welche im ersten Byte um ein Bit erhöht wurde (01
00 5Ehex). Die restlichen 24 Bit bilden das Kennzeichnungsfeld für die MulticastGruppe, wobei das erste Bit reserviert ist und immer 0 sein muss.
Bei der Umsetzung einer 32 Bit langen IPv4-Adresse in eine MAC-Adresse, werden also NUR die 23 unteren Bits der IP-Adresse in die MAC-Adresse gemappt.
Es wird in Kauf genommen, dass es zu Kollisionen und Mehrfachvergabe der
gleichen Multicast-Gruppe auf einem Netzsegment kommen kann.
Doku PA2_Sna06.sdw
Seite 7
6. Juli 2001
2.1.3 Internet Group Management Protocol (IGMP)
IGMP dient dazu, die Multicast-Pakete zwischen den Routern und Gruppenmitgliedern in einem Netzwerksegment zu vermitteln. In den RFCs 1112 und 2236
wurden Version eins und zwei spezifiziert. Die Version drei ist in Abstimmung.
2.1.3.1 IGMP Version 1
Im IGMP-Protokoll gibt es zwei verschiedene Nachrichtentypen:
?
HOST-MEMBERSHIP-QUERY
?
HOST-MEMBERSHIP-REPORT
Die Query-Nachrichten werden vom Router mit TTL=1 in periodischen Abständen auf die Multicast-Adresse 224.0.0.1 gesendet, wobei die Abstände je nach
Implementierung individuell eingestellt werden können. Üblich sind Werte zwischen ein bis zwei Minuten.
Auf die Query-Anforderung antworten die Hosts im Netzsegment mit einem Report, aber jeder erst nach einer zufälligen Zeitspanne. Darin enthalten ist ihre
Multicast-Gruppe, so sie denn einer angehören. Sind mehrere Rechner in der
gleichen Multicast-Gruppe, greift das Prinzip mit dem zufälligen Zähler: Wenn
ein Client schon einen Report zurück gesendet hat, sehen das die anderen
Gruppenteilnehmer und senden daraufhin keine eigenen Reports.
Ein Report kann auch unaufgefordert gesendet werden (join group). Ein 'leave
group' gibt es in IGMP Version 1 noch nicht.
2.1.3.2 IGMP Version 2
Neu gibt es hier eine 'leave group' Anweisung, dadurch wurde die Latenzzeit für
das Verlassen einer Gruppe und dadurch die unnötige Belastung des Netzwerks
durch unerwünschte Pakete signifikant verringert. Damit das 'leave group'
funktioniert, wird noch eine gruppenspezifische Query-Anfrage eingeführt, damit
der Router anfragen kann, ob nach einem 'leave group' überhaupt noch jemand
dieser Gruppe angehört, ohne zuviel Traffic zu erzeugen. Zum Schluss wurde
noch das Verhalten bei mehreren Multicast-Routern in einem Netzwerksegment
definiert. Der Router mit der tiefsten IP wird als Querier festgelegt.
Doku PA2_Sna06.sdw
Seite 8
6. Juli 2001
2.1.4 Distance Vector Multicast Routing Protocol (DVMRP)
Das bis heute am meisten verbreitetste Multicast Routing Protokoll DVMRP,
wurde ursprünglich von Steeve Deering entwickelt und ist ein Routing Protokoll,
das auf Basis von Distanzvektoren, also Hop-Counts, basiert. Eine frühe Version
des Protokolls, eine Art Multicast-RIP, wurde in der RFC 1075 spezifiziert. Moderne Implementierungen beinhalten die starken Verbesserungen, die 1999 im
Internet Draft draft-ietf-idmr-dvmrp-v3-09.txt festgehalten wurden.
Der Aufbau des MBones und seine schnelle, weltweite Ausdehnung, geschah mit
Hilfe dieses Protokolls und ist dem Umstand zu verdanken, dass es immer schon
den frei verfügbaren Software-Multicast-Routing-Dämon mrouted für UNIX Betriebssysteme gab.
DVMRP ist bekannt als ein 'prune and flood protocol' was heisst, dass DVMRP
ähnlich wie IGMP arbeitet, aber über Netzwerksegmente hinweg. Schliesslich ist
es ein Routing-Protokoll. Seit der Version drei routet mrouted auf der Basis vom
Reverse Path Multicasting:
Pruning: Der Sender S am Router R1 beginnt Daten an die Multicast-Gruppe G1
zu schicken, wofür die Kurzform (S,G1) üblich ist. RPB sorgt nun dafür, dass alle
Router R1 bis R7 ein Paket der Übertragung erhalten (flooding). Truncated Reverse Path Broadcasting sorgt nun dafür, dass die Pakete nur an diejenigen
LANs weitergeleitet werden, wo es auch zugehörige Gruppenmitglieder von G1
gibt (R3, R5). R7 und R6 stellen per IGMP fest, dass es in ihrem LAN keine zugehörigen Gruppenteilnehmer gibt und senden nun eine Prune-Nachricht an den
jeweils vorderen Router im 'Multicast-Baum' zurück (pruning = beschneiden,
entspricht abmelden).
Damit ein Benutzer sich jederzeit in einer Multicast-Gruppe anmelden kann,
wurde der grafting-Mechanismus eingeführt. In unserem Beispiel meldet sich ein
User über IGMP am Router R7 an. Dieser sendet nun eine Graft-Nachricht zum
vorderen und dieser weiter bis zum Router R1. Danach wird R1 den G1 Multicast-Baum erweitern.
DVMRP ist relativ einfach zu implementieren, hat aber den Nachteil, dass es
einiges mehr an Ressourcen benötigt als z.B. PIM, da es die schon vorhandenen
Unicast Routing-Tabellen nicht mitbenutzt. Weiter skaliert DVMRP schlecht und
ist für grössere Netze deshalb weniger geeignet.
Doku PA2_Sna06.sdw
Seite 9
6. Juli 2001
2.1.5 Protocol Independent Multicast (PIM)
PIM bietet mit seinen beiden Modi dense und sparse im Gegensatz zu DVMRP
auch Unterstützung von spärlich besetzten Regionen und die Verteilung mit
möglichst geringen Verzögerungszeiten. Ein weiterer wichtiger Vorteil ist, dass
PIM die schon vorhandenen Unicast Routingtabellen unabhängig vom eingesetzten Unicast-Routingprotokoll nutzt und dadurch Ressourcen spart. PIM ist zu
schon existierenden Multicast-Routing-Protokollen wie z.B. DVMRP kompatibel
und bietet eine erhöhte Skalierbarkeit (Steuermechanismen, Bandbreitenbedarf,
...). Die Definition des PIM-Protokolls wurde in der RFC 2362 festgehalten.
2.1.5.1 PIM Dense Mode
Der PIM Dense Mode (PIM-DM) arbeitet analog zum DVMRP Protokoll. Es
handelt sich dabei auch um ein 'flood and prune' Protokoll. Der Unterschied zwischen DVMRP und PIM-DM liegt in der Ermittlung des kürzesten Pfades zum
Sender. PIM-DM greift auf die im Router schon vorhandenen eigenen UnicastRouting-Tabellen zu, während DVMRP eigene erstellen und verwalten muss. Insofern ist PIM-DM auch einfacher zu implementieren. Es müssen nur die PruneZustände bezogen auf die Gruppen gespeichert werden. Es ist nicht nötig, Routen
zu berechnen. Dies hat den kleinen Nachteil, dass man etwas Flexibilität in Sachen Wegwahl einbüsst, da man den Multicast-Verkehr, den schon vorhandenen
Routen entlang senden muss (Stichwort 'unsymmetrische Hin- und Rückwege').
2.1.5.2 PIM Sparse Mode
Die wichtigste Neuerung im PIM-Protokoll kommt eigentlich erst mit dem PIM
Sparse Mode (PIM-SM). PIM-SM geht grundsätzlich davon aus, dass es keine
Teilnehmer einer bestimmten Multicast Gruppe gibt und kann somit auf das
'flood and prune' Prinzip verzichten.
In PIM-SM existieren ausgewählte Router als sogenannte Rendezvous Points
(RP), bei denen sich die Teilnehmer zuerst anmelden müssen, bevor sie Multicast-Pakete einer bestimmten Gruppe erhalten. Sender müssen sich ebenfalls als
RP registrieren. Ein PIM-SM Netz kann aus einem oder mehreren RPs bestehen,
welche dann auch für verschiedene Multicast Gruppen zuständig sind.
PIM-SM kann sowohl Shared Trees als auch Source-Based Trees aufbauen. Bei
einem Shared Tree bildet der RP den initialen Kernverteilungsbaum. Es wird
also ein gruppenspezifischer Shared Tree bestehend aus den Sendern und den
Empfängern zusammengesetzt, die alle wiederum über einen RP miteinander
verbunden sind. Beim Shared Tree senden die Sender ihre Pakete an den RP.
Dieser weiss, wer die Multicast-Pakete empfangen will und leitet diese weiter.
Ab einem gewissen Schwellenwert kann der RP den Shared Tree in einen SourceBased Tree umwandeln. Das heisst, dass der Verkehr nicht mehr über den RP
läuft, sondern vom Sender direkt zu gewissen Teilnehmern.
Doku PA2_Sna06.sdw
Seite 10
6. Juli 2001
1. Registrierung des Senders beim RP
2. Neuer Teilnehmer für Empfang
3 RP erweitert den Verteilungsbaum
4. Aufbau eines Source-based-Trees
5. Multicastverkehr auf dem kürzesten Pfad
Zusammenfassend kann man also sagen, dass PIM wesentliche Verbesserungen
gegenüber dem bisher bekannten DVMRP bietet. Es basiert nicht auf dem Fluten
von Multicast-Paketen, sondern basiert auf einem expliziten Anmeldeverfahren
an so genannten RPs. Es kombiniert die Möglichkeiten des Source-Based Tree
(kürzester Pfad von Sender zu Empfänger) und des Shared Tree (nur Router im
Pfad, die Teilnehmer haben) und geht effizienter mit Netzwerkressourcen um.
Doku PA2_Sna06.sdw
Seite 11
6. Juli 2001
2.1.6 Inter-Domain Multicast
Bisher haben wir nur Routingverfahren angeschaut, die primär auf einen Einsatz innerhalb einer Routingdomäne (Autonomous System, AS) zielen. InterDomain-Routing verlangt aber Unabhängigkeit von den in den AS eingesetzten
Routingprotokollen, sollte möglichst nicht fluten und prunen (!) und wäre zuständig für den Aufbau der Multicastbäume über Domänen hinweg.
Da dringender Handlungsbedarf bestand, hat sich die IETF dazu entschlossen,
eine schnelle Lösung für internationales Multicast-Routing zu erstellen. Als eine
Art Zwischenlösung entstanden dann die Protokolle Multicast Border Gateway
Protocol (MBGP, Erweiterung der RFC 2283) und Multicast Source Discovery
Protocol (MSDP). Eine ganzheitliche Problemlösung für internationales Multicast Routing sieht die IETF in Form des Border Gateway Multicast Protocols
(BGMP, draft-ietf-bgmp-spec-02.txt)
2.1.6.1 Multicast Border Gateway Protocol (MBGP)
MBGP ist eigentlich kein 'eigenes' Protokoll. Der Name hat sich mittlerweile
etabliert verweist aber lediglich auf die Multicast-Erweiterung des Border Gateway Protocol in der Version 4 (BGP-4, RFC 2283).
Durch den Kennzeichner der Adressfamilie (SAFI), werden zwei neue BGP-4 Attribute hinzugefügt, welche den Austausch Multicast-relevanter Informationen
erlaubt:
?
MP_REACH_NLRI
Multiprotocol Reachable NLRI, die Menge der erreichbaren Ziele und
deren Next-Hop-Information
?
MP_UNREACH_NLRI
Multiprotocol Unreachable, die Menge der nicht erreichbaren Ziele
Damit ist es nun möglich, Multicast-Routen separat von Unicast-Routen zu
übermitteln, was zusätzlich den Vorteil hat, dass man für Unicast und Multicast
getrennte Routing-Topologien konfigurieren kann. Der Einsatz von MBGP verhindert, dass der Grenzrouter eines Autonomen Systems (AS) die ganze Topologie des Multicast-Netzes kennen muss. Es genügt das Verständnis über die Topologie des eigenen AS und das Wissen um die Routen zu anderen AS.
2.1.6.2 Multicast Source Discovery Protocol (MSDP)
MBGP regelt zwar den Austausch von Routinginformationen zwischen einzelnen
AS, gibt aber keinerlei Auskünfte darüber, welche Domäne wann Teilnehmer in
welcher Gruppe besitzt. Da PIM-SM ein explizites Anmelden der Gruppen-Teilnehmer beim entsprechenden Rendezvouz-Point Router erfordert, diese Router
aber nur Multicast-Gruppen in der eigenen Domäne kennen, gibt es für einen
Benutzer in der Domäne A keine Möglichkeit einer Multicast-Gruppe in der
Domäne B beizutreten. Der Anmeldeversuch würde an den RP der Domäne A
gesendet werden welcher die Multicast-Gruppe der Domäne B nicht kennt.
Doku PA2_Sna06.sdw
Seite 12
6. Juli 2001
Das Multicast Source Discovery Protocol (MSDP, draft-ieft-msdp-spec-06.txt) erlaubt es also PIM-SM-Domänen mit eigenen RPs miteinander zu verbinden.
MSDP basiert auf TCP-Verbindungen, um die Zuverlässigkeit der Übertragung
zu gewährleisten. Dem für die Domäne verantwortlichen RP wird je eine MSDP
Instanz zur Seite gestellt. Diese ist üblicherweise im gleichen Rechner installiert.
MSDP funktioniert auch mit mehreren RPs pro Domäne, es wird dann einer
ausgewählt, der die MSDP-Funktionalität für die Domäne übernimmt.
Funktionsweise:
?
Jeder neue Teilnehmer der Multicast Daten sendet, ein Sender also,
muss sich beim PIM-SM zuerst am für die Domäne verantwortlichen RP
anmelden.
?
MSDP erkennt die neue Quelle und sendet eine Source-Active Nachricht an alle direkt verbundenen Nachbarn.
?
Ein MSDP Nachbar überprüft nun zuerst, ob die Nachricht von der
richtigen Stelle her kommt (Endlosschleifenvermeidung). Ist dies der
Fall, wird die Nachricht an alle Nachbarn weitergeleitet, ausser an den,
von welchem die Nachricht erhalten wurde.
?
Will nun jemand einer entfernten Multicast-Gruppe beitreten, werden
PIM-Join-Nachrichten an die Multicast-Senderadresse gesendet und
der Multicast-Verteilbaum erweitert.
2.1.6.3 Border Gateway Multicast Protocol (BGMP)
Dieses Protokoll stellt eine vollständige Interdomain Multicast Routing Architektur dar, hatte dafür aber etwas länger in der Entwicklung. Aktuell ist die
Spezifikation vom November 2000 im IETF-Draft: draft-ietf-bgmp-spec-02.txt.
BMGP etabliert wie PIM-SM gemeinsam genutzte Verteilungsbäume (Shared
Tree), die jedoch im Gegensatz zu PIM bidirektional sind. Dies ermöglicht ein
frühzeitiges erreichen der Teilnehmer einer Session auf der gleichen Hierarchieebene. Die Wurzel eines solchen Baumes ist immer eine ganze Domäne und nicht
etwa ein einzelner Rechner.
BGMP benutzt wie auch MSDP TCP, um zuverlässige Übertragungen der Routing-Informationen garantieren zu können. Das An- und Abmelden wird über
Join- und Prune-Nachrichten vollzogen. Per KeepAlive-Nachrichten werden
die Zustände periodisch aufgefrischt. BGMP arbeitet stark mit dem Unicast
Border Gateway Protocol BGP zusammen und benutzt dessen Routing-Informationen, um die Verteilbäume zu generieren.
BGMP unterstützt Classless Inter-Domain Routing (CIDR), welches schon seit
einigen Jahren in Unicast-Netzen eingesetzt wird. Mit dieser wichtigen Funktionalität kann die Menge der zu übertragenden Routing-Informationen vermindert werden. Damit CIDR effizient mit Multicast eingesetzt werden kann, bedarf
es einer strukturierten und hierarchischen Vergabe der Multicast-Adressen.
Doku PA2_Sna06.sdw
Seite 13
6. Juli 2001
Dieser Problematik hat sich die Multicast Address Allocation Architecture
(MAAA) angenommen. Darauf sei hier aber nicht weiter eingegangen. Wer mehr
Informationen
über
MAAA
benötigt,
findet
diese
unter
http://north.east.isi.edu/malloc der Adresse der IETF Multicast Address Allocation Group.
2.1.7 Administrative Konzepte
In den nächsten drei Kapiteln geht es um drei Kernprobleme, vor allem aus
Administratoren-Sicht:
?
Reichweite der Multicast-Gruppen festlegen
?
Bandbreitenbegrenzung / Flusskontrolle des Multicast-Verkehrs
?
Da nicht alle Router über Multicastfähigkeiten verfügen müssen Tunnel
eingerichtet werden können
2.1.7.1 Multicast Scope Control
Je nachdem, was der Inhalt des über Multicast gesendeten Materials ist, will
man die Verbreitung eingrenzen können. Es gibt zwei Konzepte um die Reichweite von IP-Multicast-Paketen zu beschränken. Die Begrenzung des erreichbaren Bereichs über den Time To Live Wert (TTL) im IP-Header oder das administrative Scoping.
TTL Beschränkung: Man setzt gezielt den TTL-Wert der Multicast-Pakete. Multicast-Router besitzen einen Konfigurationsparamter, der sogenannte treshold.
Dieser ist eine Art Schwellwert einer Übertragungsleitung. Trifft ein Multicast
Paket mit einem grösseren TTL als im treshold angegeben, bei einem Router
ein, so wird das TTL dekrementiert und das Paket weitergeleitet. Ist der TTL
Wert kleiner als der treshold, so wird das Paket verworfen.
MBone De-Facto TTL-Standards
Reichweite
treshold
lokales Subnetz
1
Innerhalb der Organisation / Institution
16
Innerhalb eines Landes
32
Innerhalb Europas
48
Ausserhalb Europas (z.B. USA)
64
Grösstmögliche Verbreitung (world)
255
Administrative Multicast-Bereiche: Da die Bereiche per TTL nur sehr grob 'beschrieben' werden können, hat man noch ein weiteres Konzept erarbeitet. Administratively Scoped IP Multicast (RFC 2365). Der administrative MulticastBereich ist ein definierter Bereich im Multicast-Adressraum. Er hat folgende
Doku PA2_Sna06.sdw
Seite 14
6. Juli 2001
Eigenschaften:
?
Multicast-Pakete, die an administrative Multicast-Bereiche adressiert
sind, überschreiben keine konfigurierten Administrationsgrenzen.
?
Adressen aus dem administrativen Bereich, werden lokal zugewiesen
und besitzen deshalb nicht die Notwendigkeit, ausserhalb des Administrationsbereichs eindeutig zu sein.
Der administrative Multicast-Bereich liegt zwischen 239.0.0.0 und
239.255.255.255. Es existiert noch eine weitere Unterteilung dieses Adressbereichs:
Einsatzgebiet
Nicht zugewiesen
Adressbereich
239.0.0.0/10
Nicht zugewiesen
239.64.0.0/10
Nicht zugewiesen
239.128.0.0/10
Organisation / Institution
239.192.0.0/14
Reserviert für Erweiterung im lokalen Bereich
239.253.0.0/16 bis
239.254.0.0/16
Lokaler Bereich
239.0.0.0/16
Damit die administrativen Bereiche nutzbringend eingesetzt werden können,
muss ein Multicast-Router die Konfiguration von IP-Multicast Bereichsgrenzen
(Boundries) zulassen. Ein sogenannter Boundry-Router steht an der Grenze eines
zu administrierenden Bereichs zu anderen Netzen. Der Router sperrt bidirektional alle Paket-Weiterleitungen an den Grenzen des administrativen Bereichs.
2.1.7.2 Bandbreitenlimitierung / Flusskontrolle
Da der Multicast-Verkehr auf UDP basiert und somit keine Flusskontrolle hat
wie z.B. der Sliding-Windows-Algorithmus vom TCP ihn bieten würde, muss man
sein Netz vor Überbelastung schützen. Auch wenn der Verkehr das LAN verlässt
und über das WAN geht, wo Bandbreite teuer ist, wäre man um eine Bandbreitenlimitierung froh.
Da UDP keinen Rückkanal besitzt, wurde als 'Allerheilmittel' die Bandbreitenbeschränkung gewählt. Alle derzeit verfügbaren Implementierungen von Multicast-Router stellen eine Möglichkeit der Bandbreitenlimitierung zur Verfügung.
Insbesondere bei Tunneln ist diese Limitierung wünschenswert.
Beim bekannten Unix-Multicast-Router mrouted, konfiguriert man die Bandbreitenlimitierung mittels rate_limit x, wobei x = Anzahl KBit/s ist. Bei den
CISCO-Pendants kann man noch richtungsabhängig konfigurieren: rate-limit
in und rate-limit out.
Doku PA2_Sna06.sdw
Seite 15
6. Juli 2001
2.1.7.3 Aufsetzen eines IP-Multicast-Tunnels
Das Internet besteht noch aus vielen nicht multicast-fähigen Routern. Trotzdem
möchte man Multicast Inseln über viele Unicast-Strecken miteinander verbinden. Dies geschieht über Multicast-Tunnels. Hierbei wird eine virtuelle UnicastVerbindung zwischen zwei Multicast Routern konfiguriert, die zwei oder mehrere
direkt angeschlossene multicast-fähige lokale Netze miteinander verbindet.
Multicast-Pakete aus dem LAN werden dann komplett in Unicast-IP-Datagramme mit der Adresse des Tunnelendpunkts verpackt und über normale Unicast-Routen ans Ziel befördert. Es wird dabei das IP over IP Protokoll benutzt
(RFC 1700). Als Beispiel eine einfache Tunnelkonfiguration mit mrouted:
tunnel IP1 IP2 metric 1 treshold 32 rate_limit 1000
Hier wird also ein Tunnel zwischen dem Router mit IP1 und einem anderen
Router mit IP2 angelget. Der Tunnel bietet eine maximale Transferleistung von
1MBit/s für Multicastverkehr. Die Reichweite der Multicast-Pakete muss mindestens TTL=32 sein.
2.1.8 Router
Hier soll nur erwähnt werden, wie es mit der IP-Multicast-Fähigkeit der heutigen Routern aussieht.
mrouted ist der im MBone zur Zeit am meisten verbreitete Router, seine Handhabung ist sehr einfach. Leider unterstützt er nur das DVMRP Protokoll. Der
mrouted wurde 1989 von Steve Deering an der Stanford University entwickelt.
Die Weiterentwicklung lag danach beim Paolo Alto Centers, zur Zeit (Juni 2001)
ist die Version 3.9 aktuell. Man sollte keine alten Versionen mehr benutzen, da
es etliche Änderungen gegeben hat. Für den mrouted gibt es sogar ein SNMPInterface und er ist für fast alle bekannten UNIXe erhältlich und gratis.
CISCO Router unterstützen IP-Multicast seit der Betriebssystem Version IOS
10.2. Die Version 10.2 ist jedoch ungenügend implementiert. Einsetzen sollte
man kein IOS unter Version 11.1(9). CISCO Router bieten im Gegensatz zum
mrouted das modernere Protokoll PIM an. Sie unterstützen sowohl PIM-SM als
auch PIM-DM.
Natürlich gibt es auch andere Router-Hersteller, die Multicast-Unterstützung
bieten. Die beiden Alternativen mrouted und CISCO-Router sind aber die am
meisten verbreiteten IP-Multicast-Router.
2.1.9 MBone
Der erste Multicast-Tunnel wurde im Sommer 1988 zwischen der BBN und der
Stanford University aufgeschaltet. Seit den ersten Live-Übertragungen von
NASA-Missionen und Rock-Konzerten 1993, wuchs der MBone (Multicast-Backbone) enorm. Dank dem kostenlos verfügbaren UNIX Multicast Routingdämon
mrouted, verbreiteten sich schnell überall auf der Welt Multicast-Inseln. Der
Doku PA2_Sna06.sdw
Seite 16
6. Juli 2001
heutige MBone wird vor allem von den kontinentalen Forschungsnetzen gebildet
(Europa: TEN-155, USA: vBNS, CAIDA ...). Die Kern-Router implementieren das
Multicast-Netz direkt auf ATM-Verbindungen. Alle daran angeschlossenen
Gegenstellen sind über MBGP und MSDP angeschlossen. Innerhalb der
einzelnen MBone-Netzwerke läuft heute noch mehrheitlich das DVMRP
Protokoll, beziehungsweise PIM-DM. Es gibt aber schon vereinzelte PIM-SM
Inseln.
1988 wurde noch angenommen, dass das Tunneling nur als Hack gebraucht
werde, bis die Kern-Router Multicasting kennen. Diese Annahme erwies sich als
falsch. Multicasting hat sich bis heute noch nicht breit genug durchgesetzt, so
dass die meisten Neuanschlüsse immer noch per Multicast-Tunnel an den MBone
angeschlossen werden.
Bevor der MBone auch das Interesse der kommerziellen Provider weckte, war
das Multicast-Netz eine reine 'Spielwiese' von Universitäten und Forschungseinrichtungen, welche auf diese Weise bereits erste Konferenzen ausserhalb der
eigenen Netze realisieren konnten.
2.1.10 Zukünftige Entwicklungen
In den folgenden Kapiteln wird jeweils kurz beschrieben, wie sich die zukünftigen Entwicklungen des Internets auf das Multicasting auswirken.
2.1.10.1 Multicast in IPv6
Mit IPv6 (RFCs 2373, 2526), haben wir sage und schreibe 1500 nutzbare IPv6Adressen pro Quadratmeter Erdoberfläche. Klar ist, dass bei einer neuen Adresse
auch die Adressauflösung anders vonstatten geht. Dies ist eine Auswirkung auf
Doku PA2_Sna06.sdw
Seite 17
6. Juli 2001
das Multicasting. Eine IPv6-Multicast-Adresse beginnt mit acht auf eins
gesetzten Bits, gefolgt von drei Nullen (future use) und dann, je nachdem ob es
eine well-known IP-Adresse ist, ein 0 oder eine 1, wenn es sich um eine normale
Adresse handelt. Dann folgen vier Bits, welche die Scope des Pakets definieren
(von Node-local bis Global). Am Ende bleiben dann noch 112 Bits um die
Multicast-Gruppe zu identifizieren.
Weiter gibt es als grosse Neuerung die Anycast Adressierung: Anycast beschreibt
die Adressierung eines beliebigen Knotens aus einer Gruppe von Rechnern. Über
diese Technik wird das Adressieren von Multicast-Gruppen einfacher.
Ein weiterer Vorteil von IPv6 ist, dass die Funktionalität vom IGMP Protokoll
ins ICMPv6 (Internet Control Message Protocol) eingeflossen sind (QUERY, REPORT).
IGMPv2 wird durch MLD (Multicast Listener Discovery, RFC 2710) ersetzt, das
auf Basis von ICMPv6 arbeitet.
2.1.10.2 QoS-Unterstützung für IP-Multicast
Die IETF bietet hier auch ohne IPv6 bereits QoS-Lösungen in einem IP-Netzwerk an:
IntServ (Integrated-Services-Modell): Bietet zwar noch keine garantierte Übertragung an, unterstützt dafür aber bevorzugte IP-Pakete. Weitere Informationen
findet man in den RFCs 2212 und 2211.
RSVP (Resource-Reservation-Protocol): Dieses Signalisierungsprotokoll für IntServ ist in der RFC 2205 definiert. Über dieses Protokoll werden die Dienstklassen realisiert. RSVP bietet schon vom Konzept her eine gute Unterstützung für
IP-Multicast. RSVP reserviert für einzelne Datenströme (definiert durch Quell-,
Zieladresse und Portnummern) Netzressourcen. Diese Informationen werden in
periodischen Abständen wiederholt gesendet um die Reservierungszustände in
den Routern aufzufrischen. Da sich die Topologie des Multicast-Baums permanent ändern kann, werden so veraltete Reservierungen gleich implizit gelöscht.
Bei Multicast-Gruppen mit mehreren aktiven Sendern (Konferenzen), werden in
RSVP sogar verschiedene Reservierungstypen unterstützt.
Ein weiterer Ansatz bietet noch die Differentiated-Service-Group der IETF, welche das Type-of-Service-Feld der IPv4 Headers benutzen will. Hier soll aber nicht
näher auf den noch stark auf IP-Unicast ausgerichteten Ansatz eingegangen
werden. Weitere Informationen findet man unter: draft-ietf-diffserv-framework02.txt und in draft-bless-diffserv-multicast-00.txt.
Doku PA2_Sna06.sdw
Seite 18
6. Juli 2001
2.2 Streaming
2.2.1 Streaming Übersicht
Die Online-Radiostationen stossen auf grosses Interresse bei den Surfern. Das
Radio ist als klassisches Tagesmedium besonders geeignet für das Internet. Berufsleute am Arbeitsplatz, Studenten und immer mehr Privathaushalte haben
permanenten, breitbandigen Zugriff auf das globale Netzwerk. Gemäss einer
Studie der amerikanischen Markforschungsfirma NPD hat bereits mehr als die
Hälfte aller Internetsurfer schon einmal im Netz nach Audio- oder Videoangeboten Ausschau gehalten. Der Schwerpunkt des Nutzerinteresses liegt bei Musikprogrammen und Konzerten.
Gemäss Schätzungen (Stand März 2000), sind 58 Prozent der Surfer, die Audiound Videoangebote via Internet nutzen männlich. Die meisten Nutzer sind zwischen 25 und 44 Jahre alt. Webcasting-Fans, auch „Streamers“ genannt, haben
darüber hinaus eine überdurchschnittlich gute Bildung. Diese soziodemographische Erkenntnis ist damit zu erklären, dass es momentan noch vorwiegend erfahrene Internetbenutzer sind, die mit Online-Audio und Videoangeboten vertraut sind. Dies wird sich aber in naher Zukunft sicher ändern, was Firmen und
Schulen zwingen wird, sich Gedanken über die Verteilung und Unterbindung von
Audio- bzw. Video-Livestreams zu machen.
2.2.2 Unicast Streaming
Leider ist es heute noch so, dass der grösste Teil der Audio-Video Streams per
Unicast übertragen wird. Dass heisst, dass jeder Zuhörer seine eigene Verbindung zum Streamingserver unterhält. Wollen z.B acht Leute an der ZHW DRS3
hören, so wird der gleiche Stream vom DRS3-Server acht mal an unsere Schule
gesendet. Man kann sich leicht vorstellen, dass die benötigte Bandbreite für jeden weiteren Zuhörer linear ansteigt. Diesem Missstand kann durch Installation
lokaler Proxy-/Relayingserver ein wenig entgegengewirkt werden (siehe Bild unten), da dann eigentlich der Proxy-/Relayingserver der einzige Empfänger des
Streams ist und ihn dann im LAN an die Zuhörer verteilt. Dadurch wird die
"teure" Leitung zum Internet wesentlich entlastet. Der Netzverkehr auf dem
"billigen" LAN bleibt jedoch hoch.
Die Übermittlung von Multimedia-Streams mittels Unicast hat jedoch auch nicht
zu unterschätzende Vorteile. So kann die Übertragungsqualität individuell für
jeden Zuhörer je nach Verbindungsqualität realtime verändert werden. Sollte die
Verbindung zum Server für eine kurze Zeit ganz abreissen, kann der Mediaplayer aus dem Buffer die Empfangslücke für eine gewisse Zeit ausfüllen. Besteht die Verbindung dann zum Server wieder, so wird im Hintergrund der Buffer des Empfängers erneut gefüllt. So kann mit grosser Wahrscheinlichkeit ein
Stream über lange Zeit unterbrechungsfrei empfangen werden. Ausserdem ist
das Billing für kostenpflichtige Dienste sehr einfach zu realisieren.
Doku PA2_Sna06.sdw
Seite 19
6. Juli 2001
Benötigte Bandbreite für Unicast ohne einen Proxy- / Relaying-Server
Streaming-Server
8 * 128 kbit/s = 1 Mbit/s
Internet
H S1 HS 2 OK 1 OK 2 PS
1 2 3 4 5 6 7 8 9 101 112
C O LAC TSTA -
CO N SOL E
Hub/Switch
Zuhörer
Benötigte Bandbreite für Unicast mit einen Proxy- / Relaying-Server
Streaming-Server
Internet
1 * 128 kbit/s = 128 kbit/s
Lokaler Proxy/
Relaying-Server
H S1 HS 2 OK 1 OK 2 PS
1 2 3 4 5 6 7 8 9 101 112
C O LAC TSTA -
CO N SOL E
Hub/Switch
Zuhörer
Doku PA2_Sna06.sdw
Seite 20
6. Juli 2001
2.2.3 Multicast Streaming
Multicast Streaming erfreut sich langsam aber sicher immer grösserer Beliebtheit. Vor allem für den Streamer (Sender des Streams) bedeutet es eine enorme
Kostenersparnis, da von seinem Server aus nur noch ein Stream gesendet wird.
Will ein Zuhörer einen Media-Stream empfangen, so muss er seine Absicht dem
Sender mitteilen. Dieser schaut dann dafür, dass der Zuhörer die Multicastpakete zugestellt bekommt. Wie wir bereits einige Kapitel früher erfahren haben,
ist mit dem MBone (Multicast-Backbone) auch die nötige Technik im Backbonebereich vorhanden. Firmen und Schulen (die am MBone angeschlossen sind)
können mittels Multicasting-Empfang unter Umständen enorm Bandbreite einsparen.
Sofern man Campus-intern über eine multicastfähige Infrastruktur verfügt, aber
nicht am MBone angeschlossen ist, kann man auch einen Proxy- / Relayingserver
in Betrieb nehmen, der zwar die Streams per Unicast empfängt, dann aber per
Multicast in das lokale Netz sendet. Somit entsteht vom Internet zum Campus
auch nur eine einfache Bandbreitenbelastung, egal wie viele Hörer diesen Sender
hören.
Die Vorteile des Unicasting sind die Nachteile des Multicasting. Empfängt ein
Hörer auf einmal keine Multicast-Pakete mehr, kann der Empfangsbuffer (welcher bei Empfangsbeginn gefüllt wird) zwar für eine gewisse Zeit den Player mit
Daten versorgen, wenn der Hörer dann aber wieder Multicast-Pakete empfängt,
kann der Buffer nicht wieder ohne Unterbruch gefüllt werden. Weil es halt eben
Multicast ist und nicht individuell vom Sender auf die Probleme des Einzelnen
eingegangen werden kann. Der unterbrechungsfreie Empfang über eine längere
Zeit, ist also nicht gewährleistet. Ein nicht unwesentlicher Aspekt ist auch der
Anschaffungskostenfaktor. Die wenigsten Firmen verfügen bereits über multicastfähige Netzwerktechnik, was dazu führt, dass aus Multicast ziemlich schnell
Broadcast werden kann.
Auch wenn die zur Verfügung stehende Bandbreite ständig wächst, die Zukunft
liegt im Backbonebereich eindeutig beim Multicasting, weil dadurch enorme
Bandbreitenersparnisse erwirkt werden können. In mikrosegmentierten LAN's
ist der Einsatz von Multicasting unter Umständen zuerst abzuklären.
2
Erforderliche Bandbreite
Bandbreite in MBit/s
1.75
Unicast vs. Multicast
1.5
Multicast
Unicast
1.25
1
0.75
0.5
0.25
0
1
5
10
15
Anzahl Empfänger (gleicher Sender)
Doku PA2_Sna06.sdw
Seite 21
6. Juli 2001
Verkehrsaufkommen bei acht 128kbit/s Livestream-Empfängern (gleicher Sender)
Unicast
Streaming-Server
Router
5 * 128 kbit/s = 0.5 Mbit/s
1 * 128 kbit/s = 128 kbit/s
3 * 128 kbit/s = 384 kbit/s
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9 101112
COLACTSTA-
CONSOLE
Hub / Switch
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACT STA-
CONSOLE
Hub / Switch
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACT STA-
CONSOLE
Hub / Switch
Multicast
Streaming-Server
1 * 128 kbit/s = 128 kbit/s
Multicastfähiger Router
1 * 128 kbit/s = 128 kbit/s
1 * 128 kbit/s = 128 kbit/s
1 * 128 kbit/s = 128 kbit/s
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACT ST A-
Doku PA2_Sna06.sdw
CONSOLE
Hub / Switch
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACT ST A-
CONSOLE
Seite 22
Hub / Switch
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACT STA-
CONSOLE
Hub / Switch
6. Juli 2001
2.2.3.1 SDP, SAP und SIP
Das Session Description Protocol (SDP, RFC 2327) dient dazu Sitzungen zu beschreiben. Diese Beschreibungen werden mit Hilfe der Protokolle SAP, SIP,
SMTP (E-Mail) oder HTTP an potentielle Teilnehmer verteilt. Eine SDP-Beschreibung einer Session besteht aus reinem ASCII-Text, der die eigentliche Beschreibung der Session, den geplanten Zeitraum und die verwendeten Medien
enthält.
SDP
SAP
SIP
HTTP
SMTP
TCP
UDP
IP
In der oben abgebildeten Grafik wurde der im Multicasting meistens verwendete
Fall, SDP in SAP über UDP über IP markiert. Man kann eine Session natürlich
auch über HTTP und SMTP ankündigen, hierbei besteht aber das Problem, dass
der potentielle Gruppenteilnehmer nicht zwingend auch Zugang zur angekündigten Session haben wird. Das Session Initiation Protocol (SIP, RFC 2543) erlaubt es Nutzer oder auch bestimmte Dienste explizit zu einer Sitzung einzuladen. Als Beschreibungsformat kommt wiederum SDP zum Zuge.
Das Session Announcement Protocol (SAP, draft-ietf-mmusic-sap-v2-06.txt) dient
zur Ankündigung von Sitzungen. Die Sitzungs-Ankündigungen werden periodisch
an
die
festgelegte
Multicast
Adresse
sap.mcast.net
(224.2.127.254:9875) gesendet. Bei administrativem Scoping wird statt dieser
well-known Adresse jeweils die höchste Multicast-Adresse des Adressbereichs
genutzt.
Wenn man mit Multicast-Streaming arbeitet, wird man früher oder später einmal über ein SDP-Announcement stolpern, sei dies im Cache vom Programm
SDR oder wenn man die Announcements eines LiveCaster-Streaming Servers
anschaut. Deshalb schauen wir nun noch an, wie eine SDR Nachricht aufgebaut
ist.
SDP Nachrichten werden also meistens via UDP und SAP verbreitet. Hierbei ist
zu beachten, dass wenn man SAP verwendet, nur ein Announcement pro Paket
gesendet werden darf und dass die SDP-Beschreibung nicht länger als 1kByte
sein darf.
UDP
SAP Header
SDP
1kByte max.
Doku PA2_Sna06.sdw
Seite 23
6. Juli 2001
Der Aufbau einer SDP Nachricht ist zeilenweise in <type> = <value> Paare
aufgeteilt. <type> ist dabei immer ein case-sensitives Zeichen, <value> ist ein
zum <type> entsprechender String. Nun folgt eine Übersicht, welche Typen es
in SDP gibt und was sie bedeuten:
Session Beschreibung
Typ
Wert
Weitere Erklärungen
v
Protokollversion
o
Ersteller der Session und Identifier
s
Name der Session
i
Optionale weitere Informationen
u
URI der Beschreibung
e
E-Mail Adresse des Erstellers
p
Tel. Nr. des Erstellers
c
Connection Information
b
Bandbreiten Informationen
z
Zeitzonenanpassungen
k
Verschlüsselungs-Schlüssel
a
Null oder mehrere Attribute
<username> <session_id> <version>
<network_type> <address_type> <address>
Session bezogene Information
Optional, wenn weiter unten schon angegeben
Genauere Beschreibung der Session
Zeit bezogene Beschreibungen
Typ
Wert
t
Zeitblock in der die Session aktiv ist
<starttime> <stoptime> Format: Dezimale
Darstellung des Network Time Values
r
Null oder mehrere Repetitionen
z.B. täglich, wöchentlich um 10Uhr morgens, ...
Medium Beschreibung
Typ
Wert
m
Name des Mediums und Transport
Adressen
i
Titel des Mediums
c
Connection Information
b
Bandbreiten Informationen
k
Verschlüsselungs-Schlüssel
a
Null oder mehrere MediumAttribute
Doku PA2_Sna06.sdw
<media> <port/anzahl> <transport_protocol>
<format_list>
Optional wenn es oben schon angegeben wurde
Seite 24
6. Juli 2001
Hier noch ein Beispiel einer SDP-Nachricht. Sie wurde aus dem Cache des SDR
v.3.0 kopiert. Der Sender ist der LiveCaster Streaming Server:
v=0
o=- 991741912 3202204387 IN IP4 160.85.138.78
s=phpserver - WOLF FM - the hottest mix of the 70s,
80s and today!
i=MP3 audio
u=160.85.138.78/
[email protected]
t=3202204387 3202206007
a=type:broadcast
a=tool:lc v1.0a83
m=audio 59106 RTP/AVP 14
c=IN IP4 239.14.136.2/63
2.2.3.2 RTP, RTCP und RTSP
Was Streaming auszeichnet ist, dass man die gewünschten Daten schon während
der Übertragung anschauen kann. Bei solchen Übertragungen ist es wichtig, eine
niedrige Verzögerungszeit für den Empfang der Pakete zu gewährleisten. Probleme bei der Rekonstruktion des gesendeten Signals beim Empfänger treten
insbesonderer dann auf, wenn Pakete unterschiedliche Verzögerungszeiten haben, auch Jitter genannt. TCP eignet sich nicht, da es jedes verloren gegangene
Paket nochmals beim Sender anfordert. Der Empfänger müsste zu lange Wartezeiten hinnehmen. Verwendet man hingegen nur UDP, können Fehler in der
Übertragung, übermässige Paketverluste und Änderung der Paketreihenfolge die
Qualität negativ beeinflussen. Auch gibt es beim UDP kein Feedback über die
Qualität der 'Verbindung'.
Aus all diesen Gründen wurde 1991 das Real-Time Transport Protocol (RTP,
RFC 1889) entwickelt. Es wurde primär für die Übertragung von kontinuierlichen Datenströmen, wie Audio- und Video, konzipiert. RTP stellt im Vergleich zu
UDP zusätzliche Funktionalitäten bereit, bietet aber im Gegensatz zu TCP keine
garantierte Übertragung aller gesendeten Pakete.
RTP versieht die Audio- und Videopakete mit Zeitstempeln, um sie beim Empfänger wieder in die richtige Reihenfolge zu bringen. Sequenznummern werden
verwendet, damit Paketverluste zuverlässig diagnostiziert werden können. Weiter können via RTP auch verschiedene Datenströme synchronisiert werden. RTP
wird eigentlich immer über UDP versendet, es muss aber nicht. Denkbar wäre
RTP auch direkt in einem ATM-Netzwerk auf dem Adaptation Layer 5 (AAL-5).
RTP wird ausschliesslich für die Übertragung der Datenpakete verwendet. Damit man eine Kontrolle über die Qualität der Datenübertragung hat, verwendet
Doku PA2_Sna06.sdw
Seite 25
6. Juli 2001
man das Real-Time Transport Control Protocol (RTCP, siehe auch RFC 1889,
Kapitel 6). Über Sender- und Empfänger-Reports werden Informationen über die
Qualität der Übertragung zwischen den Teilnehmern ausgetauscht (Paketverlustrate, u.s.w.).
Das Real-Time Streaming Protocol (RTSP, RFC 2326) dient der Kontrolle von
Multimedia-Echtzeit-Datenübertragungen. Es wurde 1996 von Real Networks,
Netscape und der Columbia University entwickelt. RTSP bietet eine Art Fernbedienung für Multimedia Server (play, stop, u.s.w.). Für die Datenübertragung
selbst, wird dann meistens RTP benutzt. Weiter überwacht es die Datenverbindung im Sinne einer Qualitätssicherung und bietet auch noch Urheberrechtsschutz-Funktionen.
Eine Anmerkung am Rande: Für Shared Whiteboards (wb-Dienst) und Text
Applikationen muss eine gesicherte Datenübertragung existieren, deshalb wird
hier nicht auf der Basis von UDP operiert, vielmehr wird der Reliable Multicast
(RMC)–Ansatz benutzt. Wer mehr über diesen neuen Ansatz wissen will, verweisen wir an die RMRG (Reliable Multicast Research Group der IETF) weiter.
Interessantes zu diesem Thema findet man auch in 'NACK-Oriented Reliable
Multicast (NORM) Protocol Building Blocks', festgehalten in dem draft-ietf-rmtnorm-bb-00.txt.
Audio/Videoanwendungen
RTP
RTCP
RTSP
Whiteboard, TextTools
Reliable MC
UDP
IP
2.3 Multicast Streams per Web publizieren (Bsp. Apache)
Um einen Multicast Stream im RTP/AVP Format 14 per Weblink verfügbar zu
machen, muss man wie folgt vorgehen:
1. Apache httpd.conf editieren und folgende Zeile hinzufügen:
AddType audio/mpegurl .pls
Tipp: Browsercache leeren und dann erst erneut versuchen auf die Datei zuzugreifen
2. Eine Homepage erstellen, die einen Link mit einer Datei z.B. song_1.pls
enthält. (Genauerer Beschrieb, siehe auch Kapitel 6.1.5)
Die Datei song1.pls enthält folgenden ASCII-Text und ist für alle lesbar:
[playlist]
numberofentries=1
File1=rtp://239.14.136.3:59106
Doku PA2_Sna06.sdw
Seite 26
6. Juli 2001
Der RTP-Protokoll-Link hinter File1 enthält die Multicast Adresse und Port.
Wenn der Client nun einen Multicast fähigen Player hat (z.B. Winamp 2.7x inkl.
in_rtp.dll), kann er diesen Stream per Mausklick aktivieren, einmal angenommen er ist in einem per Multicast erreichbaren Subnetz.
2.4 SDR MP3 Audio Plug-In
SDR ist ein SAP und SDP Parser, mit welchem man bequem alle Sessions des MBones visualisiert und verwaltet. Man kann mit SDR auch via SIP andere zu Sessions
einladen und eigene Sessions erzeugen.
Damit man mit dem Programm SDR, die per SDP angekündigten MP3-Streams per Mausklick auf JOIN hören
kann, muss ein Plug-In geschrieben werden, denn SDR
muss wissen, mit welcher Anwendung es den MIMEType mpegurl assoziieren soll.
Dies ist allerdings nicht schwer. Folgender Text muss in
eine Datei namens:
sdr2.plugin.S07.audio.rtp.14.winamp
im Verzeichnis Pfad\sdr\plugins gespeichert werden. (Unix: ~/.sdr/plugins/)
media:audio
proto:RTP/AVP
protoname:RTP
tool:winamp
fmt:14
{
fmtname:MP3 audio
flags:
}
flags:rtp://$(ADDRESS):$(PORT)
Dieses Plug-In ist für Winamp gedacht. Will man aber Freeamp starten, so muss
man nur den Namen des Plug-Ins anpassen und in der Datei unter dem Punkt
tool: Winamp durch Freeamp ersetzen.
Wenn jemand Plug-Ins für andere Zwecke schreiben will, findet er eine ausführliche Anleitung in der Hilfe-Funktion des SDR-Programms.
Doku PA2_Sna06.sdw
Seite 27
6. Juli 2001
3. Aufgabenstellung
Fachgebiet Kommunikation
Arbeit Nummer: PA2 Sna 01/6
Proxy-Server für Audio-Live-Streams
Dozent:
Steffen Andreas, Büro: E509, Tel.: 434
Beschreibung:
Real-Audio und MP3 Audio-Live-Streams erfreuen sich nicht nur bei den
Studierenden einer grossen Beliebtheit. Hunderte von Radiostationen und
Spartenprogramme können über das Internet empfangen werden. Die Begeisterung der Informatikdienste hält sich jedoch in Grenzen, da Dutzende
von parallelen Kanälen den Internetanschluss zustopfen, auch wenn die
gemietete Bandbreite noch so gross ist. Auch die Belastung der internen
LAN-Segmente ist nicht zu vernachlässigen. Als drastische Gegenmassnahme werden die Audio-Live-Streams häufig durch Sperrung der
gängigen Ports mittels eines Firewalls unterbunden.
Als Kompromiss bietet sich ein Proxy-Server an, der eine limitierte Anzahl
von Audio-Live-Streams zulässt und damit die durch Audio-Streams beanspruchte Bandbreite unter strenger Kontrolle hält. Da meist einige wenige
Radioprogramme von vielen Benutzern gleichzeitig gehört werden, drängt
sich eine Verteilung dieser Kanäle im Intranet durch den Proxy-Server mittels IP Multicast auf.
In dieser Projektarbeit soll ein Bestand aufgenommen werden, welche
Produkte auf dem Markt erhältlich sind, die diese Proxy-Funktionalität anbieten. Da kommerzielle Server meist nicht ganz billig sind (z.Bsp. einige
tausend Franken für einen RealSystem Proxy 8 Server), soll OpenSource
Implementationen besondere Aufmerksamkeit geschenkt werden.
Mindestens zwei verschiedene Lösungen sollen installiert und konfiguriert
werden und deren Vor- und Nachteile aufgezeigt werden. Um die
Belastung der internen LAN-Segmente auf ein Minimum zu begrenzen,
sollen bevorzugt IP-Multicast Lösungen eingesetzt werden.
Doku PA2_Sna06.sdw
Seite 28
6. Juli 2001
4. Analyse
4.1 Vergleich von Streaming / Proxy Server-Produkten
Wir haben eine Vergleichstabelle mit den momentan gängigsten kommerziellen,
sowie den vielversprechendsten nichtkommerziellen Produkten zusammengestellt. Die Preisspanne reicht von Freeware bis US$21'000.
Die kommerziellen Produkte sind ganz klar auch für den kommerziellen Einsatz
bestimmt. So kann fast jedes Produkt dem Media-Stream noch Werbeinformationen in irgendeiner Form beifügen. Payment-Möglichkeiten (Pay per View/Listen) bieten auch die meisten. Diese beiden Features erfordern jedoch den Einsatz
von proprietären Streaming-Formaten. Das bedingt natürlich, dass alle Empfänger den Player des Streamers installiert haben müssen. RealNetworks versucht mittels geschickter Verwirrungstaktik auch beim Streaminkonsumenten
noch abzukassieren.
Eine erstaunlich günstige professionelle Streaminglösung ist mit dem Einsatz
des Darwin Streaming Servers möglich. Dieser Server ist die Open Source Version des Apple Streaming Servers und bietet auch dieselbe Funktionalität. Der
einzige Softwarekostenpunkt bei dieser Lösung ist die Quicktime-Pro Lizenz,
welche zur Encodierung des Mediastreams gebraucht wird. Diese kostet gerade
einmal lächerliche US$29.99.
„Backbone Radio“ verwandelt den PC mit der zugehörigen GUI-Control-Unit
gleich in ein komplettes Radiostudio mit allen dazu benötigten Funktionen
(Crossfading, Live Durchsagen, Realtime-Playlist-Change,..).
Das absolute Highlight für den Campus-Einsatz ist der LiveCaster. Er unterstützt das parallele Multicast-Relaying von mehreren MP3-Streams. Dieser Server ist eigentlich Freeware. Man ist jedoch gezwungen, monatlich die neuste
Version auf dem Streamingserver neu zu installieren. Von dieser relativ unangenehmen Freeware-Restriktion kann man sich jedoch durch die einmalige Bezahlung von $100 freikaufen.
Nicht empfehlen können wir den NetShow Encoder von Microsoft. Die von uns
eingesetzte Version (3.1.0.2954) stürzte mitsamt dem System auf verschiedenen
Rechnern permanent nicht reproduzierbar ab. Die Möglichkeit, eine Playlist zu
verwenden ist leider nicht gegeben und Dateien im MP3-Format wurden konsequent verweigert, obwohl NetShow dieses Format offiziell unterstützt. Ausserdem können MPEG 1 Layer 3 Livestreams nur mit einer maximalen Bitrate von
56 kBit/s codiert werden.
Doku PA2_Sna06.sdw
Seite 29
6. Juli 2001
Übersicht der verfügbaren Audio-Streaming Produkte
Produkt
Typ
Backbone Radio
http://www.backbone.com
Encoding &
Streaming
Darwin Streaming Server 3.0.1
http://www.darwin.org
Betriebssystem
Multicast /Unicast
Qualitäten
Stream-Typ
Preis
Signalquelle
- Multicast
- Unicast
8..48 kBit/s
- Quicktime-Audio
$4'500 - $17'500
Streaming & Relaying - Max OS X
- Linux (RedHat 6.2, Intel)
- Solaris 7
- FreeBSD 3.5 (Intel)
- Windows 2000/NT (SP5)
k/a
- Unicast
- Multicast
20..100 kbit/s
- Quicktime-Audio
- Quicktime-Video
Freeware (open source) - Quicktime Files
- Live Quicktime Streams
- bezieht Quicktime-Stream von beliebiger Quelle, kann aber nicht
selbst Encodieren
- Quicktime Pro Lizenz ($29.99) wird zum Encodieren gebraucht
- Open Source, gleiche Funktionalität wie Apple Streaming Server 3
- Multistream-fähig (verschiedene Streams von einem Server)
RealSystem Server
http://www.realnetworks.com
Encoding &
Streaming
- Windows 2000/NT
- Linux 2.2 (glib c6)
- Free BSD 3.0
- Solaris 2.6-2.8
- AIX 4.3
- HP-UX 11.x
- IRIX 6.5
- 256-768 MB Ram
- Multicast
- Prozessoren:
- Unicast
- Intel Pentium
- Sun Sparc
- IBM RS/6000 Power PC
- HP PA-RISC 2.0
- R4000 (MIPS3)
bis 320 kBit/s
- RealAudio 8
- RealVideo 8
$1'995- $21'313
- 45 Verschiedene MediaFormate (MP3,
Quicktime,..)
- Live- Audio/Video per
Capture-Karte
- 45 verschiedene Media-Formate wie MP3, Quicktime, WAV...
können gelesen werden
RealSystem Proxy
http://www.realnetworks.com
Proxy-Server
- Windows 2000
- IBM-AIX 4.3
- HP UX-11
- Linux 2.2 (libc6)
- Solaris 2.6-2.8
- 512 MB Ram
- Prozessoren:
- Intel
- Sun SPARC
- Multicast
- Unicast
bis 320 kBit/s
- RealAudio 8
- RealVideo 8
$3'995
- RealMedia Streams
- Bandbreiten-Kontrolle
- Caching Funktionalität
NetShow Encoder 3.1.0.2954
http://www.microsoft.com
Encoding &
Streaming
- Windows
k/a
- Unicast
8..96.1 kBit/s
- ACELP
- CELP
- MS G.723.1
- MPEG Layer 3
- Voxware MetaSound
Freeware
- Live (Line-IN)
- MP3-Files
- WAV-Files
- AVI-Files
- Unterstütz keine Playlists (nur immer ein File kann gesendet
werden)
- hat Problemen mit MP3-Files
- Streams können an Microsoft NetShow-Server gesendet werden,
der diese dann per Multicast weitersenden kann.
Obsequieum
http://obs.freeamp.org
Streaming
- Linux 2.x.x
- Pentium 100 MHz
- Linux 2.x.x
- glibc 2.x
- Unicast
8..320 kBit/s
- MPEG Layer 3
Freeware (open source) - MP3-Files
- Playlistenverwaltung in MySQL
- Web-basierte Administration
SHOUTcast DNAS-Server
http://www.shoutcast.com
Relaying
- Windows 95/98/NT/2000
- Linux glibc (intel)
- FreeBSD 3.x (intel)
- FreeBSD 4.x (intel)
- BSDi (intel)
- Solaris 7 (SPARC)
k/a
- Unicast
8..320 kBit/s
- MPEG Layer 3
Freeware
- beliebige MPEG Layer 3
Streaming Quelle
- von beliebiger MPEG Layer 3 Streaming-Quelle speisbar
- Nullsoft Streamin-Tool DSP-Plugin ist auch Freeware
liveCaster
http://www.live.com
Streaming & Relaying - Windows 95/98/NT
- Solaris (SPARC)
- FreeBSD
- Linux (GNU/Linux/x86)
k/a
- Multicast
8..320 kBit/s
- MPEG Layer 3
$100
- MP3-Files
- MP3-Streams
- MP3 von 'standard input'
- kann mittels LiveGate Multicast-Tunnel betreiben
- unterstützt Session-Description-Protokoll
- mehrere Streams möglich
k/a
- Unicast
8..320 kBit/s
- MPEG Layer 3
- Freeware (open
source)
- beliebige MPEG Layer 3
Streaming Quelle
- open source, Quellcode verfügbar
- Remote Adminstration per Telnet möglich
Doku PA2_Sna06.sdw
- Windows 95/98
- Linux
- OS/2
- BeOS
Seite 30 von 51
- CD-Audio
- MP3-Files
- WAV-Files
- Live (Line-In)
Features
k/a
icecast
http://www.icecast.org
Control Unit:
- Mac OS
- (Windows geplant)
Streaming Server:
- Linux
System-Anforderungen
- Quicktime Pro Lizenz enthalten
- GUI Control Unit
- Live Radio Features:
- Crossfading
- Playlist change
- Live Durchsagen
- Zuhörerstatistik
- Billingfunktionen
6. Juli 2001
4.2 ZHW MBone Anbindung
Nachdem wir uns mehr mit Multicast und dem MBone befasst haben, wollten wir
natürlich auch die ZHW an den Vorzügen eines MBone-Anschlusses teilhaben
lassen. Leider ist die Schule nicht direkt am MBone angeschlossen und Cablecom, der Provider der Zürcher Hochschule Winterthur, routet Multicast Pakete noch nicht durch ihr Netzwerk. Es wird also ein Multicast-Tunnel zur
nächsten MBone Insel benötigt. Die SWITCH ist über das TEN-155 am MBone
angeschlossen und somit unser nächster Anschluss-Partner. Auf unsere Anfrage
vom 11. Juni 2001 hin bekamen wir schnell eine positive Antwort.
Am Donnerstag dem 14. Juni 2001 wurde mit Herrn Eggimann und Herrn
Schmid in einer Sitzung ein 512kBit/s Multicast-Tunnel zur SWITCH bewilligt.
Als Router der ZHW wurde unser Multicast-Streaming-Server (phpserver) ausgewählt, darauf soll mrouted (DVMRP) laufen. Diese Konfiguration soll bis Ende
2001 aufgeschaltet bleiben. Was jetzt noch fehlt ist ein formeller Antrag der von
der Kontaktperson der ZHW, Peter Eggimann her beantragt werden muss, was
bis heute, 4. Juli 2001, leider noch nicht geschehen ist.
Wir haben uns entschieden eine mögliche mrouted-Konfiguration zu entwerfen,
testen können wir sie aus oben genannten Gründen aber leider noch nicht.
Die ZHW wird wie in der Grafik unten gezeigt wird, ihren gesamten MulticastVerkehr über den phpserver (160.85.138.78) abwickeln, welcher eine GatewayFunktion zum MBone übernimmt.
Doku PA2_Sna06.sdw
Seite 31
6. Juli 2001
Die mrouted Konfiguration (mrouted.conf) beinhaltet allgemeine Konfigurationen und ein virtuelles Interface, den Tunnel:
cache_lifetime 300
prune_lifetime 7200
zhwlan 160.85.0.0/16
# Hier Definition weiterer Router im lokalen ZHW-LAN
# Tunnel zum SWITCH MBone-Zugangs-Router
tunnel 160.85.138.78 switch-ip metric 1 treshold 1 rate_limit 512
Cache- und prune_lifetime sind übernommene Default-Werte (in Sekunden). Je
nach Bedarf kann man sie auch anpassen, wir fanden sie aber angebracht und
beliessen sie in ihrer Default-Konfiguration.
Der Eintrag zhwlan 160.85.0.0/16 definiert eine sogenannte Boundry (Grenze)
und verbindet diese mit dem Namen 'zhwlan'. Auf diese Weise kann man bei
späteren lokalen Multicast-Routern Interfaces definieren, welche keine Pakete
über diese definierte Multicast-Adressbereichs-Grenze hinaus routen. Momentan
wird sie aber noch nicht verwendet, da nur ein Tunnel definiert wurde, der ja
keine Grenze hat.
Wie man sieht wird ein Multicast-Tunnel zwischen dem phpserver mit der IP
160.85.138.78 zur Gegenstelle bei der SWITCH mit noch unbekannter IP aufgebaut. Da der treshold auf 1 gesetzt wurde, wird jedes ankommende Paket weitergeleitet. Will man später nur schulintern verteilte Anwendungen, z.B. das
ZHW-Radio einführen, dann muss man beim liveCaster den Paketen einen TTLWert kleiner dem hier im Tunnel-Interface definierten treshold wählen.
Wenn dann der MBone Anschluss aufgeschaltet ist und der mrouted konfiguriert
ist, kann man mit Hilfe des Tools mtrace (analog zu traceroute) überprüfen ob
die Pakete den richtigen Weg nehmen. Um überhaupt zu prüfen, ob man jetzt auf
dem MBone ist, sollte man einfach das Programm Session Directory Tool (SDR)
installieren und aufstarten. Es findet automatisch alle per SDP angekündigten
Sessions.
Doku PA2_Sna06.sdw
Seite 32
6. Juli 2001
5. Realisierung
5.1 Beschreibung unserer Multicast-Streaming Lösung
Unsere Streaming-Komplettlösung unterstützt IP-Multicast und wurde möglichst nur aus Freeware und Open-Source Komponenten zusammengestellt.
Damit die Realisierung möglichst billig ist, war es zwingend notwendig, dass der
Streaming-Server auch auf einem Freeware Betriebssystem funktioniert. Als
hauptsächlichen Einsatz, sehen wir dieses System im LAN. Es wurde nicht unbedingt dafür konzipiert, Streams über das Internet zu versenden, auch wenn es
dazu in der Lage ist. Die drei Hauptaufgaben die das System erfüllt sind:
1. Proxy Funktion: Das System kann MP3-Streams aus dem Internet / Intranet empfangen und per Multicast im Intranet (LAN) verteilen.
2. Server Funktion: Das System ist in der Lage, von einer Quelle (Std-In,
http-Stream, Line-In) einen MP3-Stream als Multicast im Intranet (LAN)
verteilen zu können.
3. Multiple simultaneous Streaming: Es ist möglich, mit diesem System
mehrere voneinander unabhängige Multicast-Streams zu erzeugen und
zeitgleich zu versenden. Dabei ist die Begrenzung der Anzahl Streams
allein von der Hardware abhängig.
Die zentrale Komponente ist der LiveCaster (www.live.com), welcher für die Erzeugung und Verteilung der Multicast-Streams verantwortlich ist. Die anderen
beiden Komponenten, SHOUTcast und oddcast, sind nur nötig, um den liveCaster mit http-Unicast-Streams, 'Sendematerial' also, zu versorgen. Braucht man
den LiveCaster lediglich, um bereits gespeicherte Dateien abzuspielen, so werden
serverseitig keine weiteren Anwendungen mehr benötigt. Will man im LAN nur
Inhalte verteilen, welche über den MBone empfangen werden, benötigt man
nicht einmal den LiveCaster, dann reicht schon das konfigurieren der Router im
LAN.
5.2 Versuchsaufbau
5.2.1 Einführung
Bei unserem Testaufbau gingen wir davon aus, dass man sowohl noch nicht digitalisierte Inhalte, als auch schon als MP3-Stream vorhandene Inhalte per Multicast im LAN verteilen will.
Gleich von Beginn an sollte die ganze Schule mit Multicast Streams versorgt
werden. Weil das LAN der Zürcher Hochschule Winterthur auf einer flachen
Layer-2 Struktur basiert, haben wir uns entschieden, nicht allzu viele Streams
zu senden und haben uns auf vier Streams beschränkt.
Wir nutzten den Vorteil, dass wir mit unserem System auch noch nicht digitalisierte Inhalte senden können. An einen PC schlossen wir per Line-In einen Tuner an, welcher uns das Radio DRS3 als analoges Audiosignal lieferte. Dieses
Doku PA2_Sna06.sdw
Seite 33
6. Juli 2001
wird im PC cobalt (160.85.131.61) digitalisiert und mit einer festgelegten Bitrate
vom Winamp Plug-In oddcast DSP encodiert an den SHOUTcast Server gesendet.
Damit wir den Multicast-Empfängern auch noch andere musikalische Stilrichtungen bieten können, haben wir aus dem Internet drei 'MP3-Sender' ausgewählt, welche nun ebenfalls als Multicasts an der ZHW gesendet werden. Diese
drei MP3-Streams kommen direkt aus dem Internet über das ZHW-LAN als
Unicast-http-Streams zum LiveCaster auf dem phpserver (160.85.138.78).
5.2.2 Darstellung des Testaufbaus
In zwei Grafiken haben wir den Versuchsaufbau visualisiert. In der ersten Grafik sieht man, welche Kommunikationskanäle zwischen den einzelnen Geräten
existieren und welche Unicast- respektive Multicast-Streams vorhanden sind.
Analog
Radio
ZHW-LAN
3 MP3-Streams:
128KBit/s
44.1kHz
Analog Audio
PC: Line-IN
http://160.85.138.78
Unicast MP3-Stream
Per Winamp Plugin:
56kBit/s
22kHz MP3-Stream
Workstation: cobalt
160.85.131.61
Server: phpserver
160.85.138.78
rtp://239.14.136.73
Live Radio (z.B. DRS3)
rtp://239.14.136.3
Jazz Radio
rtp://239.14.136.1
hot hit radio
rtp://239.140.136.2
wolf fm
Unicast
Doku PA2_Sna06.sdw
Multicast
Seite 34
6. Juli 2001
In der zweiten Grafik sehen wir, wie die Software-Komponenten miteinander
verknüpft sind und welche Streams von welcher Komponente aus gesendet werden.
Analog
Radio
Internet
analoges Audiosignal
cobalt
3 * MPEG-3 Audiostream à
128 kBit/s
oddcast DSP
Encoder
encodiertes Audiosignal (56kBit/s)
Shoutcast DNAS
Server
phpserver
liveCaster
Server
3 * MPEG-3 Audiostream à 128 kBit/s
1 * MPEG-3 Audiostream à 56 kBit/s
Unicast
Multicast
LAN
5.2.3 Erläuterungen zum Testaufbau
Der Versuchsaufbau diente vor allem dazu, die evaluierte Lösung auch im Einsatz zu erproben, damit wir allfällige Schwierigkeiten und Beschränkungen in
Konfiguration und Betrieb erkennen und dokumentieren können.
Die Installation selbst lief erstaunlich gut. Das Winamp Plug-In oddcast DSP ist
mit wenigen Mausklicks installiert. Der LiveCaster ist ebenfalls eine reine Routinearbeit. Lediglich beim SHOUTcast DNAS-Server muss man sich durch eine
etwas grösser geratene Konfiguration durcharbeiten, was aber auch keine grösseren Schwierigkeiten bereitet. Alles in allem kann man mit einem halben Tag
für die Installation und Konfiguration der gesamten Multicast-Streaming Lösung
rechnen.
Doku PA2_Sna06.sdw
Seite 35
6. Juli 2001
Dieser Versuchsaufbau hat natürlich das Problem, dass wir ihn im gleichen
Netzwerk-Segment installiert haben, wo auch die potentiellen Empfänger der
Multicast-Streams sind. Dies macht insofern keinen Sinn, als dass auch die Unicasts in einem Shared-Net an alle angeschlossenen Computer gelangen. Bridges
bieten hier immerhin eine gewisse Segmentierung, aber sauber ist es nicht. In
einem realen System gehört dieser Streaming-Aufbau hinter einen multicast-fähigen Router, damit die MP3-Unicasts gar nicht erst ins LAN gelangen. Wenn
man Streams vom Internet her bezieht und via Proxy ins LAN einspeist, ist es
sicher von Vorteil, wenn die Proxy Infrastruktur möglichst gleich nach dem Internet Anschluss der Firma positioniert wird.
Als Nachteil werten wir im Moment, dass es nicht möglich ist, vom oddcast DSP
Plug-In direkt zum liveCaster streamen zu können. Damit wäre dann der
SHOUTcast DNAS-Server überflüssig. So wie es aussieht, gibt es aber in nächster Zeit kein oddcast-Update, welches dieses Feature beinhaltet.
5.2.4 Performance Aspekte
Wir haben untersucht, wie stark die einzelnen Programme die jeweilige Hardware belasten. Da wir zuerst mit dem SHOUTcast for Winamp Plug-In arbeiteten, haben wir auch zu diesem Encodierungs-Plug-In Messwerte. SHOUTcast for
Winamp hat den Nachteil, dass man als Encoder die Advanced Version des
Fraunhofer MP3-Codecs verwendet. Dieser kann nur MP3-Streams bis 56kBit/s
erzeugen. Mit dem oddcast DSP Plug-In fällt diese Einschränkung weg.
Wieviel Prozessorleistung und Memory benötigen die Programme:
?
Server:
Plattform: PII-350MHz, 128MB RAM, SuSE Linux 7.1 (Kernel 2.4.0)
SHOUTcast:
1 sc_serv Prozess benötigt: 4.0% vom RAM und ~ 0% von der Prozessorleistung
LiveCaster:
1 lc Prozess benötigt: 0.5-0.9% RAM und 1.2% von der Prozessorleistung
?
Source Client (oddcast DSP Plug-In):
Plattform:PIII-450MHz, 128MB RAM, MS-Windows2000® SP-1
Winamp 2.72 inkl. oddcast DSP Beta 14 Plug-In und Line-In Plug-In v.1.41:
1 Prozess benötigt: 4.224 MB RAM, 29-74% von der Prozessorleistung (Peakwerte!), Durchschnittswert ist 40% bei 56kBit/s 22kHz UND 128kBit/s
44.1kHz !
?
Source-Client (SHOUTcast Plug-In):
Plattform: PIII-450MHz, 128MB RAM, MS-Windows2000® SP-1
Winamp 2.72 inkl. SHOUTcast for Winamp v.1.8.0 Plug-In:
1 Prozess benötigt: 2.992 MB RAM, 12-18% von der Prozessorleistung um
einen 56kBit/s 22kHz MP3-Stream zu erzeugen
Doku PA2_Sna06.sdw
Seite 36
6. Juli 2001
Wir sehen also, dass oddcast DSP zwar eine deutlich höhere Grundbelastung für
den Source-Client darstellt, dies aber nahezu unabhängig von der Bitrate des
Ausgabe Streams. Wir vermuten, dass der eigentliche Encodierungs-Prozess mit
einer hohen Bitrate (Qualität) durchgeführt wird und je nach Bedarf die Datenrate für den Ausgangs-Stream reduziert wird. Erstaunt hat uns, dass die LiveCaster Prozesse (pro Multicast-Stream ein ist lc Prozess nötig) und der
SHOUTcast DNAS-Server so wenig Ressourcen beanspruchen.
Quellen: Beim auf Linux basierenden Server holten wir uns die Informationen
mit Hilfe des Tools top (top, dann P oder M). Auf dem Windows Rechner bemühten wir den Task-Manager. Wir haben jeweils den Mittelwert und die PeakWerte aus fünf Minuten Beobachtungszeit gewählt.
5.3 Beurteilung der Lösung
Das Dreigespann LiveCaster – SHOUTcast DNAS-Server – oddcast DSP liefert
eine sehr günstige, flexible und leistungsfähige Multicast-Streaming-Suite. Sie
bietet ein optimales Preis-Leistungs Verhältnis im Vergleich zu anderen Streaming Varianten, allen voran, zum viel verbreitete RealServer.
Als Nachteil kann man werten, dass man einen Windows-PC benötigt, um LiveStreams erzeugen zu können. Wenn man lediglich einen Live-Stream benötigt,
bietet sich noch der Weg über den Standard IN des Linux-Servers an (Soundkarte -> digitalisieren -> auf Std-In streamen -> LiveCaster).
An dieser Stelle möchten wir noch darauf hinweisen, dass man den SHOUTcast
DNAS-Server je nach belieben auch durch den Open-Source Freeware Server
icecast (v.0.1.x oder 0.2.0, experimental) austauschen kann. Das Winamp Plug-In
oddcast DSP kann beide Server bedienen. SHOUTcast ist schon etwas etablierter, wer aber lieber auf Open-Source Produkte setzt, wählt den icecast Server.
Beide Server sind kostenlos.
5.4 Beschreibung der Komponenten
5.4.1 LiveCaster
Die aktuelle Version des LiveCasters ist kostenlos. Dafür muss man ein Ablaufdatum in Kauf nehmen, welches immer zum Ende des Monats abläuft. Dann ist
man gezwungen, den LiveCaster erneut herunterladen und in das gleiche Verzeichnis zu entpacken. Wer diese Tortour nicht auf sich nehmen will, der muss
eine Lizenz für US$ 100.00 erwerben. Diese Lizenz ist nur für eine Maschine mit
statischer IP gedacht. Um eine Lizenz zu erhalten, muss man ein E-Mail an die
Adresse [email protected] senden. Darin soll man die IP des Rechners angeben, für den die Lizenz gelten soll. In einer Lizenz sind noch zusätzliche
Dienste enthalten:
?
Ein Jahr lang technischen Support via E-Mail
Doku PA2_Sna06.sdw
Seite 37
6. Juli 2001
?
Priorität bei der Ankündigung / Benachrichtigung von neuen Versionen
und Produkte-News.
?
Bei der Windows NT Version kann man danach den LiveCaster als NTDienst laufen lassen (GUI-less), bei Linux ist dies schon in der GratisVersion möglich.
?
Weiter vereinfacht sich die Konfiguration, da man mehrere gleichzeitige
Streams mit nur einem Prozess laufen lassen kann (UNIX).
Wir empfehlen eine Lizenz zu erwerben, zumal die Kosten für die Lizenz rein
symbolisch sind und jeden Monat die Software neu aufzuspielen, nicht wirklich
eine sinnvolle Sache ist.
LiveCaster bildet das Herz dieser Multicast-Streaming-Suite und bietet eine
vielfältige Flexibilität an. Er kann Streams vom Standard-In, direkt von
gespeicherten MP3-Dateien oder von http-Streams verarbeiten. Er bietet weiter
noch einen Modus an, indem man Text per Multicast verteilen kann, was hier
aber nicht gefragt ist. Er läuft unter Solaris, FreeBSD und x86-Linux, sowie unter Windows 9x und Windows NT. Für jede Multicast-Gruppe wird eine simple
Konfigurations-Datei angelegt. Diese kann man einfach beim Start einlesen und
schon läuft der Multicast-Stream. Dazu mehr in der Installationsanleitung.
LiveCaster kündigt seine Multicast-Gruppen via SDP an. D. h. man kann sich
bequem, zum Beispiel via Session Directory Tool (SDR) oder Multikit (siehe
www.live.com), Übersicht verschaffen und sich gegebenenfalls per Mausklick
einwählen.
5.4.2 SHOUTcast DNAS-Server
Dieser Server wird von der Firma Nullsoft entwickelt und ist Freeware. Wer es
nicht mag, sich dem Goodwill einer Firma auszusetzen, der kann alternativ zum
SHOUTcast DNAS-Server (www.shoutcast.com) auch den Open-Source Server
icecast (www.icecast.org) einsetzen.
Der SHOUTcast DNAS-Server ist eigentlich ein kompletter Unicast-StreamingServer. Er kann Unicast-MP3-Streams via http-Protokoll verteilen und dies an
eine beliebige Menge von Empfängern. Die einzige Limitierung ist die Hardware
und die verfügbare Bandbreite.
SHOUTcast wird in unserer Multicast-Streaming-Suite benutzt, damit man die
vom oddcast DSP encodierten Streams dem LiveCaster Server als http-Streams
übergeben kann. Auf diese Weise speisen wir ein Live-Audiosignal in den LiveCaster ein.
5.4.3 oddcast DSP – Winamp Plug-In
Dieses DSP-Plug-In für Nullsofts Audio Player Winamp 2.7x (und neuer), ist
Open-Source und somit Freeware. Anzumerken ist noch, dass die momentan
neuste Release immer noch eine Beta-Version ist (Beta 14), wobei wir betonen
möchten, dass wir nicht einen Absturz oder Unterbruch während des Encodings
Doku PA2_Sna06.sdw
Seite 38
6. Juli 2001
zu verzeichnen hatten.
Da oddcast DSP den eigentlichen MP3-Codec (Open-Source Projekt LAME) schon
statisch dazugelinkt hat, muss man nicht noch einen externen Codec installieren.
Zudem erlaubt es LAME Bitraten von 8 – 320kBit/s zu verwenden. Wenn man
will, auch variable Datenraten. Seit Beta 7 kann man sogar den neuen OpenSource Codec Ogg-Vorbis wählen, dies bedingt aber den Einsatz von icecast 0.2.0
als Unicast-Server.
5.5 Kosten / Lizenzierung
LiveCaster:
US$ 100.00 (Eine Lizenz für eine IP)
SHOUTcast DNAS-Server: US$
0.00
oddcast DSP
US$
0.00
Winamp
US$
0.00
Total
US$ 100.00
Doku PA2_Sna06.sdw
Seite 39
6. Juli 2001
6. Benutzeranleitung
6.1 Administrator
6.1.1 LiveCaster (Multicast-Server)
Um LiveCaster (v.1.0aXX) auf einem x86-Linux zu installieren, lädt man zuerst
das LiveCaster Paket von http://www.live.com/liveCaster/downloading.html herunter. Danach wird das Paket mit tar -xzf liveCaster.tar.gz ins entsprechende Verzeichnis entpackt.
Es ist wichtig, dass das Programm 'liveCaster' sowie alle .gif und .tcl Dateien im
Pfad enthalten sind. Dies erledigt man am einfachsten, indem man das LiveCaster-Verzeichnis in den Pfad aufnimmt: export $PATH:/usr/local/LiveCaster (Dies ist ein Beispiel-Pfad, Ihr eigener kann natürlich anders aussehen).
Bevor wir liveCaster nun starten, noch einige Informationen zur Arbeitsweise
von liveCaster. liveCaster kann grundsätzlich in zwei verschiedenen Ausführungen benutzt werden. Als X-Anwendung, mit einer einfachen, informativen
grafischen Oberfläche (liveCaster) und als Kommandozeilen-Prozess (lc). liveCaster liest alle für eine Multicast-Gruppe wichtigen Informationen aus einer
Konfigurations-Datei. Defaultmässig heisst diese SELF.txt. Will man eine andere Datei benutzen, so muss man dies mit dem Kommando lc -d Pfad/Dateiname beim Start mitangeben. Zu beachten ist, dass immer nur eine Konfigurations-Datei pro Verzeichnis existieren darf. Als lizenzierter User kann man
sogar mehrere Streams mit nur einer Instanz des liveCasters starten (lc -d
SELF1.txt SELF2.txt ...).
Um eine Konfigurations-Datei erstellen zu können, empfehlen wir, den liveCaster in seiner X-Version zu starten. Existiert noch kein SELF.txt im angegebenen
Verzeichnis, wird ein Assistent eingeblendet, der hilft, die Datei zu erstellen.
Wer will, kann die Konfigurations-Datei natürlich auch von Hand erstellen.
Die Konfigurations-Datei ist sehr simpel aufgebaut und kann mit jedem Editor
bearbeitet werden. Hier eine Beispielsdatei:
bwLimit
URI
info
email_address
progId
source
SDPdir
outputMode
nickname
tunnelState
GroupEId
Doku PA2_Sna06.sdw
128
160.85.138.78/
MP3 audio
[email protected]
P:160.85.138.78:991741912
http://211.115.216.23:8080
local-default
audio
phpserver – new mp3s
0 { } 10100 10100 1
239.14.136.73 59106 {63 nokey}
Seite 40
6. Juli 2001
Als Administrator können Sie obiges Beispiel gleich als Vorlage nehmen und die
einzelnen Parameter anpassen.
bwLimit bedeutet Bandbreiten-Limite. Hier wird die maximale Bitrate des MP3Streams festgelegt (128 = 128kBit/s).
URI ist die richtige IP Adresse des Servers (nicht die Multicastgruppe!)
Dem info-Tag kann ein beliebiger Text zugeordnet werden. Dieser wird danach
per SDP als Session-Beschreibung gesendet.
Die E-Mail Adresse des Sender-Verantwortlichen und optional noch seine Telefon-Nr. sind sinnvoll, auf diese Weise kann man nötigenfalls einfach in Kontakt
mit der verantwortlichen Person treten (z.B. bei Scope-Probleme o. ä.).
Die progId ist eine eindeutige Identifikation des Rechners und Programmes.
Bei source wird eine IP-Adresse mit Port angegeben. Dies ist im obigen Fall der
Quellstream, von wo LiveCaster den Unicast Stream empfängt, den er per Multicast weiter verteilen soll.
Will man nur MP3-Dateien streamen, so kann die source-Zeile weggelassen
werden. Es werden dann alphabetisch alle Dateien in diesem Verzeichnis abgespielt. Hierbei ist auch der URI-Tag nicht nötig.
SDPdir definiert, ob man SDP Ankündigungen entweder nur im lokalen Administrations-Bereich (höchste Adresse im admin-Bereich) verteilt oder diese per
TTL begrenzt, bis weltweit über das MBone auf sap.mcast.net
(224.2.127.254:9875) ankündigt.
Der outputMode muss auf audio gesetzt sein (Wir wollen ja keine Texte senden).
Nickname definiert den dargestellten Namen der Quelle des Multicast-Streams.
tunnelState kann man getrost in den default-Einstellungen belassen. Diese sind
nur nötig, wenn man das LiveGate-Tunneling Programm verwendet.
Zum Schluss wird noch die Multicast-Gruppen-Adresse und den Port angegeben.
In geschweiften Klammern wird noch angegeben, wie der TTL-Wert der gesendeten UDP-Pakete gesetzt werden soll.
Nun können wir den liveCaster starten: ./lc -d ./SELF.txt &
6.1.2 SHOUTcast DNAS-Server (Unicast Server)
Wie wir bereits weiter oben beschrieben haben, brauchen wir den SHOUTcast
DNAS-Sever nur, um die vom oddcast DSP encodierten Streams dem liveCasterSever als http-Streams zu übergeben.
Die Installation des SHOUTcast DNAS-Servers gestaltet sich sehr einfach.
Nachdem man von http://www.shoutcast.com/download/ die aktuellste Version
des Servers in ein beliebiges Verzeichnis heruntergeladen und entpackt hat,
muss man noch die Zugriffsberechtigungen für das vom Entpacker erstellte Verzeichnis (/sc_serv) auf 755 ändern (chmod 755 sc_serv).
Doku PA2_Sna06.sdw
Seite 41
6. Juli 2001
Bevor der SHOUTcast-Server gestartet werden kann, sind noch einige Änderungen im Konfigurationsfile sc_serv.conf empfehlenswert. Dieses File befindet
sich im Root-Verzeichnis des SHOUTcast-Servers und kann einfach mit einem
Editor bearbeitet werden.
Der SHOUTcast-Server verfügt über ein Web-Interface, welches mittels http://ipnummer-des-servers:8000 aufgerufen werden kann.
Administrationsbilschirm (Server Status und Listener)
Administrationsbilschirm (Auszug des Logfiles)
Doku PA2_Sna06.sdw
Seite 42
6. Juli 2001
Auf eine ausführliche Beschreibung des Web-Interfaces wird hier verzichtet. In
diesem Web-Interface kann man einzelne Zuhörer vom Server rauswerfen, sperren und die Logfiles des Servers betrachten. Damit das nicht jedermann kann,
muss unbedingt im Konfigurationsfile das Administratorenpasswort geändert
werden (Passwort=ihr_passwort). Da wir den SHOUTcast-Server nur als Relay-Station missbrauchen, wollen wir nicht, dass Zuhörer sich per Unicast auf
den Server konnektieren können. Aus diesem Grund ist der Wert für die maximale Zuhöreranzahl auf 1 zu setzten (MaxUser=1). Da wir auch nicht wollen,
dass im ungünstigsten Fall irgend jemand den SHOUTcast-Server mit einem
falschen Stream speisen kann, setzten wir den Parameter SrcIP auf die IPAdresse, von welcher aus der Livestream kommt (z.B. SrcIP=160.85.131.61).
Als letzte Sicherheit setzen wir noch den DestIP-Wert auf 127.0.0.1 (sofern der
SHOUTcast- und liveCaster-Server auf der gleichen Maschine laufen).
Wenn alle diese Einstellungen gemacht sind, kann der SHOUTcast-Server mittels Shell Eingabe ./sc_serv gestartet werden.
6.1.3 Winamp Plug-In oddcast DSP
Das Winamp Plug-In oddcast DSP lässt sich unter Windows bequem mittels Installer installieren. Es kann von http://www.oddsock.org/tools/dsp_oddcast/ herungergeladen werden.
Nach erfolgreicher Installation findet man das Plug-In in den Winamp Preferences unter dem Punkt „Plug-Ins“ „DSP/Effect“.
Das oddcast DSP-Plugin findet man unter dem Punkt DSP/Effect
Drückt man den 'Configure' Button, erscheint das GUI des Plug-Ins. Bevor man
zum Server konnektieren kann, sind noch zwingend einige Einstellungen notwendig.
Doku PA2_Sna06.sdw
Seite 43
6. Juli 2001
Folgende Informationen müssen eingegeben werden:
?
?
?
?
?
LAME Options: Use LAME
Server Location: Shoutcast
Server (def localhost): IP-Adresse von dem Rechner, auf welchem SHOUTcast
DNAS läuft
Port: 8000 (hängt von der SHOUTcast Konfiguration ab)
Password: Passwort des SHOUTcast-Servers
Servereinstellungen
Die Streaming-Einstellungen können, je nach vorhandener Bandbreite und gewünschter Übertragungsqualität, individuell eingestellt werden.
Es ist zu beachten, dass keine Einstellungen verändert werden können, solange
eine Verbindung zum SHOUTcast Server besteht.
Streaming-Einstellungen
Doku PA2_Sna06.sdw
Seite 44
6. Juli 2001
Verbindung hergestellt, der Stream wird gesendet
6.1.4 Winamp Line-In Plug-In
Das Line-In Plug-In wird nur bei Verwendung von oddcast DSP benötigt. Das
SHOUTcast Plug-In enthält bereits ein Line-In Plug-In.
Die Installation ist wirklich sehr einfach:
Auf http://home.hccnet.nl/th.v.d.gronde/dev/lineinWA2/index.html die neuste
Version downloaden (bei uns war das noch v.1.42) und die ausführbare Datei
starten. Ein OK-Mausklick reicht und mehr ist nicht zu tun!
Wenn man jetzt z.B. den Tuner oder ein CD-Player an den Line-In Eingang des
PCs angeschlossen hat, so sollte man sich zuerst vergewissern, dass das Audiosignal auch korrekt auf dem lokalen PC angehört werden kann. Ist das der Fall,
so kann man Winamp starten und mit CTRL+L das Location Fenster öffnen.
Dort kann man eine Art URL eingeben: line://mute. Der Befehl 'mute' ist nur
eine von vielen möglichen Konfigurations-Optionen. Welche Möglichkeiten man
hat, kann man mittels CTRL+P -> Input -> Line-In plugin -> Configure lesen.
Mit line:// wird das Line-In Plug-In angesprochen und mit dem Befehl mute
wird das Audiosignal zwar übermittelt, aber am lokalen PC nicht ausgegeben.
Dann kann man auch getrost im Windows Sound-Mixer den Line-In Eingangspegel auf Null reduzieren.
Bei unserem Multicast-Streaming-System hat sich die folgende Reihenfolge für
das Streaming bewährt (SHOUTcast-Server läuft schon):
1. oddcast DSP: Auf CONNECT-Button klicken
2. Line-In Plug-In starten: CTRL+L line://mute
3. liveCaster starten: ./lc -d ./SELF.txt &
6.1.5 Webpage mit 'tune-in' Angebot (Beispiel Apache)
Damit man Multicast-MP3-Streams empfangen kann, muss man neben einem
geeigneten Player auch eine spezielle Art von Link bieten. Wenn man nämlich
einen üblichen Link via HTML-Tag <a href="rtp://239.14.136.73:59106">...</a>
erstellt, weiss der Browser damit nichts anzufangen. Man muss also entweder
ein spezielles Multicast Directory Tool (SDR) installieren, oder die Webpage speziell gestalten. Wir wollen hier den zweiten Weg beschreiten.
Als erstes muss dem Webserver mitgeteilt werden, dass .pls-Dateien einem gewissen Mime-Type zugeordnet werden (audio/mpegurl). Dies ist für den meistDoku PA2_Sna06.sdw
Seite 45
6. Juli 2001
verbreitetsten Webserver Apache im Kapitel 2.3 beschrieben.
Nun zur Webpage an sich. Das Vorgehen ist an sich recht einfach. Im HTMLLink gibt man eine Datei an (diese hat die Dateiendung .pls) und somit überträgt
der Webserver im Header den vorher eingerichteten Mime-Type. Hat man Winamp installiert, so funktioniert das ohne Probleme, da dieser pls-Dateien mit
sich selbst assoziiert. Benutzt man andere Player, muss man vielleicht die Dateiendung .m3u benutzen.
In der Datei, die vom Link referenziert wird, soll folgender Text enthalten sein:
[playlist]
numberofentries=1
File1=rtp://239.14.136.3:59106
Dem MP3-Player wird nun als Source den rtp:// - Link übergeben.
Nun den Dateien noch Zugriffsrechte geben: chmod 755, das wärs auch schon.
Für jede Multicast-Gruppe muss man einen Link dieser Art erstellen. Als Beispiel folgt die RADIO-ZHW Page als Source und mit Bild.
Sourcecode:

<html>
<head>
<title>ZHW Radio</title>
</head>
<body background="./bild.gif">
<h1><B><img src="./zhw.gif" border=0 align=top></B></h1><BR><BR>
<P><FONT face="Arial, Helvetica"><B><H2>Projektarbeit Sna06: Proxy-Server für Audio-LiveStreams</H2></B></FONT></P>
<BR><BR>
<blockquote>
<table border=0 width=100%>
<tr>
<td align=left valign=middle>
<a href="live_radio.pls"><img src="tunein.gif" border=0 align=top></a> Live Radio
Stream (momentan DRS3)
</td></tr>
<tr>
<a href="hothitradio.pls"><img src="tunein.gif" border=0 align=top></a> Hot Hit Radio
on Multicast
</td></tr>
<tr>
<a href="wolf_fm.pls"><img src="tunein.gif" border=0 align=top></a> WOLF FM on
Multicast
</td></tr>
<tr>
<a href="jazz.pls"><img src="tunein.gif" border=0 align=top></a> Jazz on Multicast
</td></tr>
</table>
</blockquote>
<BR><BR><BR>
<I>Winamp</I> Users: download this Plugin to enable Winamp to receive multicast streams [<a
href="in_rtp.dll">in_rtp.dll</a>]
<BR>...otherwise use <I>Freeamp</I>, which can play RTP-multicast-streams without any
plugins.
<BR><BR><BR>
<I><a href="mailto:[email protected]">For further information</a></I>
</body>
</html>
Doku PA2_Sna06.sdw
Seite 46
6. Juli 2001
Screenshot:
RADIO ZHW Einwahlseite
6.2 Empfänger
Damit mit unserem Multicast-Streaming-System auch Musik empfangen werden
kann, muss auf den PCs der Zuhörer ein MP3-Player installiert werden, welcher
RTP Multicast Streams empfangen kann. Freeamp (www.freeamp.org) kann das
in der Version v.2.1 schon von Haus aus. Der von den meisten Leuten eingesetzte
Winamp benötigt noch ein Plug-In, welches man hier findet:
http://www.live.com/multikit/windows/in_rtp.dll
Nach dem download muss diese Datei in das Plugins-Verzeichnis von Winamp
kopiert werden. Meistens wäre das: C:\Programme\Winamp\Plugins.
Danach kann man sich via Weblinks (siehe Kapitel 6.1.5) direkt in den Stream
einklinken.
Doku PA2_Sna06.sdw
Seite 47
6. Juli 2001
7. Literaturverzeichnis
7.1 Buch
Titel
Bemerkungen
MBONE Aufbau und Einsatz von
IP-Multicast-Netzen
Holger Fahner, Peter Feil, Tanja Zseby
dpunkt-Verlag, D-69115 Heidelberg
1. Auflage, 2001
298 Seiten
ISBN 3-920993-99-3
Ein sehr gutes Buch. Beschreibt ausführlich IP-Multicast und die Anbindung eines Netzwerks an den MBone.
Das Buch ist sehr aktuell und leicht
verständlich.
7.2 Internet
Link
Beschreibung
Multicasting
http://www.microsoft.com/ntserver/mediaserv/tec Multicast-Streaming – An Introduction
hdetails/overview/multiwp.asp
http://www.switch.ch/lan/ipmcast/
Multicast LAN-Anbindung
http://www.multicasttech.com/multicast_faq.html Multicast FAQ
http://hill.lut.ac.uk/DS-Archive/MTP.html
Multicast Transport Protokolle
ftp://sunsite.cnlab-switch.ch/mirror/mbone/
Grosses FTP-Archiv mit Multicast / MBone
Programmen
http://www.linuxdoc.org/HOWTO/MulticastHOWTO.html
Multicast over TCP/IP HowTo
http://www.sims.berkeley.edu/~zhounan/proj
RTP/RTSP
http://www.mbone.or.kr/rtmw/
RTMW RTP(RSVP) Plug-In & Applet
(RTMW = Real-Time Multimedia Web)
http://pec.etri.re.kr/~mkshin/www7/186.html
The RTMW Application
MBone
http://www.arl.hpc.mil/PET/training/slides/MBon MBone Tutorial und Geschichte
e/index.htm
http://www.savetz.com/mbone/
Ältere MBone Beschreibung (noch als reines
DVMRP-Netz)
http://www.caida.org/tools/measurement/mantra/ Mantra - MBone Topologie
http://www-graphics.stanford.edu/papers/mbone/
MBone Visualisierung (auch in VRML)
http://aohakobe.ipc.chiba-u.ac.jp/misc/JPMBone/MBone-World-en.html
MBone Information Pages
http://wwwmice.cs.ucl.ac.uk/multimedia/software
MBone Applikationen (SDR, RAT, VAT,...)
http://www.ietf.org/ids.by.wg/mboned.html
MBone Entwicklung (IETF)
Doku PA2_Sna06.sdw
Seite 48
6. Juli 2001
Link
Beschreibung
http://bzvd.urz.tu-dresden.de/mbone/sessions/
MBone Tools aus dem Browser starten
http://bzvd.urz.tudresden.de/mbone/sessions/qt4.html
MBone Audio/Video mit Quicktime anzeigen
http://www.cdt.luth.se/~peppar/progs/mSD/
mSD ein SAP/SDP Parser (SDP->HTML)
http://majordomo.belnet.be/wilma/mbonebe/199904/msg00023.htm
SDR-Plugins (MP3 onMBone)
http://imj.ucsb.edu/sdr-monitor/global/
SDR Global Session Monitoring Effort ('Was
läuft denn momentan so auf dem MBone...')
Streaming Server / -Proxys
http://www.live.com/
LiveCaster (Hier findet man auch zu
Multicast / MBone viele Informationen)
http://www.shoutcast.com/support/docs/
SHOUTCast
http://www.icecast.org/
ICECast
http://obs.freeamp.org/index.html?mode=features Obsequieum
http://www.microsoft.com/NetShow/Download/en/ Microsoft Netshow
release.htm
http://www.realnetworks.com/products/servers/pr Real Networks
oxy/index.html
http://www.ispplanet.com/equipment/teraedge1.html
Tera Edge 1
http://www.cdt.luth.se/~rolle/mIR/
mIR (Multicast Internet Radio)
http://www.sowerbutts.com/audio.html
Zusammengestrickte Freeware Lösung
Weiteres
http://www.oddsock.org/tools/dsp_oddcast/
oddcast SHOUTcast / icecast MP3-Encoder
http://www.dailymp3.com/encoders.html
MP3 Encoder und Decoder
http://home.hccnet.nl/th.v.d.gronde/
Winamp Line-In Plug-In
http://private.essex.ac.uk/~djmrob/mp3decoders/d ACM Codecs
ecoders_acm.htm
http://www.isi.edu/~eddy/pim/pim.html
PIM Implementation für ein UNIX Tool
Linksammlungen
http://www.switch.ch/lan/ipmcast/references.html Enorm ausführliche Linksammlung über
Multicast von der SWITCH
http://wwwcmc.pharm.uu.nl/gillies/bookmarks/m
ulticast.html
Gute Multicast Linksammlung
Multicast MP3-Player
http://www.freeamp.org
Freeamp Multicast Player für Linux und
Windows
http://www.live.com/multikit/winampplugin.html
in_rtp.dll Multicast Plugin für Winamp
(www.winamp.com)
Doku PA2_Sna06.sdw
Seite 49
6. Juli 2001
7.3 RFCs und Internet Drafts
RFCs (http://www.ietf.org/rfc.html):
RFC 1112 IGMP Host Extensions for IP Multicasting
RFC 2236 IGMP Internet Group Management Protocol, Version 2
RFC 1075 DVMRP Distance Vector Multicast Routing Protocol
RFC 2362 PIM Protocol Independent Multicast-Sparse Mode (PIM-SM)
RFC 2283 MBGP Multiprotocol Extensions for BGP-4
RFC 2365 Administratively Scoped IP Multicast
RFC 1889 RTP A Transport Protocol for Real-Time Applications
RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
RFC 2326 RTSP: Real-Time Streaming Protocol
RFC 2373 IP Version 6 Addressing Architecture
RFC 2526 Reserved IPv6 Subnet Anycast Addresses
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
RFC 2205 RSVP Resource ReSerVation Protocol Version 1 Functional Descr.
RFC 2212 Specification of Guaranteed Quality of Service
RFC 2211 Specification of the Controlled-Load Network Element Service
RFC 2327 SDP Session Description Protocol
RFC SIP Session Initiation Protocol
RFC 2848 Extensions to SIP and SDP for IP Access to Telephone Call Services
Internet Drafts (http://www.ietf.org/internet-drafts/name.txt):
draft-ietf-idmr-dvmrp-v3-09
DVMRP Verbesserung von 1999
draft-ietf-msdp-spec-10.txt
Multicast Source Discovery Protocol (MSDP)
draft-ietf-bgmp-spec-02.txt
Border Gateway Multicast Protocol (BGMP)
draft-ietf-mboned-intro- multicast- 03.txt
Introduction to IP-Multicasting
draft-ietf-mmusic-sdp-directory-type-02.txt Describing session directories in SDP
Eigentlich kein Internet Draft, aber doch erwähnenswerte Protokolle:
http://www.live.com/rtp-mp3/rtp-mp3.txt
A More Loss-Tolerant RTP Payload
Format for MP3 Audio
http://www.live.com/umtp.txt
The UDP Multicast Tunneling Protocol
Doku PA2_Sna06.sdw
Seite 50
6. Juli 2001
8. Software Versionen
8.1 Auf dem Server / Proxy eingesetzte Software
SuSE Linux 7.1 Professional
(http://www.suse.de)
Apache 1.3.14
(http://www.apache.org)
LiveCaster 1.0a83 (nicht lizensierte Version, gültig bis 20.7.2001)
(http://www.live.com)
SHOUTcast DNAS-Server 1.8.0
(http://www.shoutcast.com)
8.2 Auf dem Client eingesetzte Software
Windows2000 Professional (SP1)
(http://www.microsoft.ch)
Winamp 2.72 / 2.75
(http://www.winamp.com)
oddcast DSP Beta 14 Winamp Plug-In (inkl. LAME MP3-Encoder)
(http://www.oddsock.org/tools/dsp_oddcast/)
Line-In Plug-In for Winamp 2.x
(http://home.hccnet.nl/th.v.d.gronde/)
Freeamp v.2.1 (funktioniert auch auf Linux)
(http://www.freeamp.org)
Session Directory Tool v.3.0 (SDR)
(http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/)
Doku PA2_Sna06.sdw
Seite 51

Multicast-Proxy-Server für Audio-Live-Streams

Transcription

Similar documents

Studienarbeit Implementierung einer IP-Multicast

Diplomarbeit

InQu.MES - InQu Informatics GmbH

Personalprofil Marek Wojcicki - Accont Management Consulting

Ein wuchtiger Trip bei Zap

Rund ums Ruderboot - des Rudervereins `Neptun` eV Konstanz

Powador-proLOG - Kaco New Energy

Webcasting: Möglichkeiten der Automatisierung