5 Technische Anforderungen und Fehlersuche

Transkript

1 5 Technische Anforderungen und Fehlersuche 5.1 Netzanforderungen Für erfolgreiche Videokonferenzen werden Anforderungen an die Bandbreite (Übertragungsrate) im Netz gestellt, die für die Akzeptanz der Anwendung eine wesentliche Rolle spielen. Netzwerke, in denen die Datendienste wie WWW, FTP und andere Formen von Filetransfer ohne Störungen funktionieren, sind nicht automatisch auch für Echtzeitanwendungen wie Videokonferenzen geeignet. Videokonferenzen stellen die konstante und verlustfreie Datenübertragung als Hauptforderung an die Netzwerkverbindung. Das bedeutet, dass in einem Netz oder Netzknoten mit hoher Auslastung (bereits ab 30 Prozent) die Wahrscheinlichkeit von Engpässen stark zunimmt. Mechanismen, welche der Videoanwendung die benötigte Bandbreite garantieren, sind in IP-Netzwerken meist nicht verfügbar. Den Daten der Videoanwendung kann in modernen Netzen höchstens ein Vorrang vor den normalen Filetransferdaten eingeräumt werden. Die für Videokonferenzen benötigte Bandbreite beginnt bei minimal 128 kbps für eine sehr geringe Videoqualität und endet bei 6 Mbps. Üblich sind in der Praxis Bandbreiten zwischen 768 kbps und 4 Mbps. Die am häufigsten zur Übertragung benutzte Videokomprimierung H.264 ist sehr effektiv für ruhende und Bewegtanteile im Videobild. Bei einer Übertragungsrate unter 768 kbps sind Bildrate und Schärfe der bewegten Bereiche schlecht. Bei steigender Datenrate wird der Einfluss von Bewegungen deutlich geringer, ab 768 kbps werden auch großflächige Bewegungen noch recht scharf übertragen. Die übertragene Auflösung ist fast immer 720p oder 1080p. Dadurch wird eine hohe Schärfe und Kantenglättung des Bildes erreicht. Im LAN (und Internet) besteht zusätzlich das Problem, dass die zur Verfügung stehende Bandbreite gleichzeitig von anderen Anwendungen genutzt wird. Falls der Videokonferenz auch nur sehr kurzzeitig Bandbreite fehlt und dadurch Pakete verloren gehen, kommt es zu Darstellungsfehlern im Video (Anhang D: Einfluss von Paketverlusten auf die Videoqualität) oder Audiostörungen oder beidem. Bei Teilnehmeranschlüssen an das X-WiN ab 34 Mbps kann von einer ausreichenden Qualität auf der Zugangsleitung selbst ausgegangen werden. Die lokalen Netze sind vermutlich geeignet, wenn es sich um moderne Netzkomponenten (Router und Switche, welche neuere Technologien unterstützen) mit reichlich Reserven handelt. Zu Problemen kann es kommen, wenn hochwertige Videokonferenzsysteme über wenig leistungsfähige oder veraltete Netzkomponenten eingebunden werden. Für ihre Funktionalität benötigen die Datenströme in vernetzten multimedialen Anwendungen folgende Bandbreiten: Version 3.2 1

2 Minimum Ausreichend Gut Sehr gut Audio-Daten 8 kbps 64 kbps 128 kbps Video-Daten 64 kbps 748 kbps 2048 kbps 4096 kbps Application-Sharing 30 kbps 300 kbps 2048 kbps 4096 kbps Die genaue Bandbreitenanforderung des Videobildes hängen vom Bildformat (die gewünschte Auflösung auf der Senderseite), der Farbtiefe und der Übertragungsrate (Bilder pro Sekunde) ab. Anhang B: Videonormen vermittelt einen Überblick der notwendigen Bandbreiten. 5.2 Netzcheck Für eine erste Bewertung der Netzverbindung sind folgende Werte hilfreich: Kapazität des schmalbandigsten Netzabschnittes Auslastung des am höchsten belasteten Netzabschnittes Diese Werte lassen sich natürlich nur schwer genau ermitteln. Hier sind meist nur Abschätzungen möglich. Zur Auslastungsbewertung der Netzabschnitte lässt sich das Antwortverhalten der an der Übertragung beteiligten Netzkomponenten heranziehen. Die an der Übertragung beteiligten Netzkomponenten lassen sich mit 'traceroute ZIEL' (bzw. 'tracert ZIEL' unter Windows) bestimmen. Das Antwortverhalten kann mit 'ping ZIEL' ermittelt werden. Dabei wird an das angegebene Ziel ein "ICMP Echo Request" geschickt und die Zeit bis zum Eintreffen der Antwort gemessen. Der so ermittelte Wert muss nicht mit dem Verhalten bei Audio-/Videodaten übereinstimmen, jedoch ist ein ähnliches Verhalten wahrscheinlich. Besonders komfortabel ist der Einsatz des UNIX-Programmes 'mtr', welches eine Kombination aus 'traceroute' und 'ping' samt Statistik beinhaltet. Auch bieten einige Videokonferenzsysteme Funktionalitäten, um Paketpfade und Antwortzeiten auszuwerten. Antwortzeiten von über 200ms sind bereits als kritisch anzusehen und für Echtzeitmultimediaanwendungen wenig geeignet. Im X-WiN sollten Werte über 100ms selten sein. Zur Kapazitätsbestimmung sind am besten die Aussagen der entsprechenden Netzadministratoren geeignet. Hier wird man bei längeren Strecken jedoch nicht immer alle Informationen bekommen können. Das UNIX-Tool 'pathchar' versucht mit Hilfe diverser Tricks Kapazitätsabschätzungen der einzelnen Abschnitte vorzunehmen, die häufig verblüffend genau sind. 5.3 Systemcheck Audio/Video Um das lokale Videobild zu testen, empfiehlt sich der Start des Systems und in diesem dann das Anzeigen des lokalen Videos. Alle gängigen VC-Systeme bieten diese Möglichkeit. Wenn das eigene Bild lokal gut sichtbar ist, sollte auch der Partner dieses sehen können. Version 3.2 2

3 Ein Audiocheck ist ohne Partner nicht möglich. Deshalb muss ein beidseitiger Test erfolgen. Dabei kann erstens geprüft werden, ob überhaupt ein Audiokontakt zustande kommt und zweitens, wenn nötig, die Qualität noch im Rahmen der Möglichkeiten des Systems nachgeregelt werden muss. Manche VC-Systeme (Desktop- oder Raumsysteme) verfügen über einen Audioassistenten oder andere Audiochecktools, womit die Funktionsfähigkeit angeschlossener Mikrofone und Lautsprecher getestet werden kann. 5.4 Fehlersuche Fehlerquellen bei Videokonferenzen sind sehr vielfältig, da in diesem Bereich sehr viele unterschiedliche Techniken zusammenwirken müssen. Deshalb ist bei der Fehlersuche ein möglichst systematisches Vorgehen nötig. Folgende Fehler können auftreten: VC-System startet nicht Bei SetTop-Geräten sind die Anschlüsse, Stromzufuhr und die Verbindung zum TV-Gerät zu prüfen. Bei PC-basierten Systemen wird vorausgesetzt, dass der PC ordnungsgemäß funktioniert. Für das VC-System ist die Softwareinstallation zu überprüfen Rufe funktionieren nicht Zum Aufbau einer Videokonferenz nach H.323 müssen verschiedene Voraussetzungen erfüllt sein: 1.) IP-Verbindung Alle beteiligten Geräte müssen erreichbar sein (z.b. zu rufendes Gerät und Gatekeeper). Dieses lässt sich mittels 'ping ZIEL' überprüfen. Falls die Verbindung über einen Firewall führt, ist dieser wahrscheinlich die Fehlerursache. Firewalls verhindern in der Regel H.323 Kommunikation (siehe Kap: 5.5: Firewall). Die IP-Adresse des eigenen Systems lässt sich in Eigenschaften von Netzwerk Internetprotokoll (TCP/IP) finden. Alternativ kann auf der Kommandozeile der Befehl 'ipconfig' verwendet werden. Die Ermittlung der den IP-Adressen zugeordneten DNS-Namen kann mittels 'nslookup ZIEL' erfolgen. 2.) Gatekeeper (siehe auch Kap. 7) Ist das zu rufende Gerät an einem Gatekeeper angemeldet, so muss sich auch das rufende Gerät im Gatekeeperverbund befinden. Ist das zu rufende Gerät nicht an einem Gatekeeper angemeldet, so darf auch das rufende nicht an einem Gatekeeper angemeldet sein. Abweichend vom Standard ermöglichen die meisten aktuellen Gatekeeper auch Rufe zwischen registrierten und nicht registrierten Geräten. Das zu rufende Gerät muss den Ruf akzeptieren. Hier muss entweder jemand den Ruf manuell annehmen oder das Gerät muss für automatische Rufannahme konfiguriert sein. Das zu rufende Gerät darf sich nicht bereits in einem Ruf befinden. Version 3.2 3

4 Die Berechtigung zum Rufen muss bestehen. Für VC-Systeme werden in der Regel keine speziellen Rufberechtigungen vergeben. Bei MCU- und Gatewaydiensten sind meist spezielle Berechtigungen nötig. 3.) Systeminkompatibilitäten Der Standard H.323 soll die Kommunikation zwischen den Geräten verschiedener Hersteller sicherstellen. Das ist auch in der Regel gewährleistet. In Ausnahmefällen kann es jedoch zu Problemen kommen. Die Grundfunktionalität wird jedoch fast immer erreicht. 5.5 Firewall Der Einsatz von Firewalls in Videokonferenzumgebungen ist prinzipiell problematisch. Bei Konferenzen nach H.323 gibt es eine Vielzahl von festen Ports und für die dynamische Vergabe kommen alle Ports oberhalb von 1024 in Frage. Dadurch sind nur speziell für H.323 vorgesehene Firewalls in der Lage, Funktion und Sicherheit in Einklang zu bringen. Eine spezielle Unterstützung von H.323 wird nur von wenigen Firewalls realisiert. Aus diesem Problemfeld ergeben sich fünf Lösungsansätze: 1.) Videokonferenzen werden außerhalb des geschützten Bereiches für die Kommunikation nach außen genutzt. Vorteile sind die uneingeschränkte Funktion der Videokonferenz-Geräte und der Schutz der Daten im gesicherten Bereich vor der Freigabe an Außenstehende. Soll die Kommunikation nur innerhalb des geschützten Bereiches erfolgen, können die VC-Geräte auch im geschützten Bereich aufgestellt werden. 2.) Proprietäre Optionen an VC-Geräten verschiedener Hersteller ermöglichen es, die Bereiche für die dynamischen Ports stark einzuengen. Allerdings wird bei Nutzung dieser Funktion die Kommunikation zwischen Systemen unterschiedlicher Hersteller nicht mehr erreicht. 3.) Bei Nutzung einer Firewall mit H.323-Unterstützung ist es auch über eine Firewall hinweg möglich, Videokonferenzen nach H.323 zu führen. Dabei sollte man jedoch die Funktion der Firewall kritisch hinterfragen, um eventuell zusätzliche Schwachstellen aufzudecken. Lösungen mit H.323-Unterstützung werden von Cisco und Checkpoint angeboten. 4.) Durch den Aufbau eines Virtuellen Privaten Netzwerkes (VPN) lassen sich Videokonferenzdaten durch die Firewall tunneln. 5.) Mit H.323 Proxies lassen sich die Videokonferenzdaten entweder durch die Firewall oder an ihr vorbei leiten. Den Proxy bildet hierbei ein Gateway, welches auf beiden Seiten H.323 als Protokoll verwendet. Besonders bewährt hat sich der gleichzeitige Einsatz eines GNU-GK als Proxy. Ein Konfigurationsbeispiel findet sich im Videokonferenzportal des DFN. Für die Punkte 2.) bis 5.) gilt, dass Videokonferenzen zwischen geschützten und öffentlichen Bereichen prinzipiell die Gefahr in sich bergen, dass über die Datendienste der Videokonferenz vertrauliche Daten nach außen gelangen. Viele Systeme bieten deshalb die Möglichkeit, die Videokonferenzdaten zu verschlüsseln. Version 3.2 4

5 5.6 Sicherheit Die Sicherheit von Videokonferenzen nach H.323 lässt sich am ehesten mit der Sicherheit von vergleichen. Es besteht die Gefahr, dass Dritte die Informationen mithören und dass die Verbindung zu einem falschen Endpunkt aufgebaut wird. Zusätzlich besteht die Möglichkeit, bei vergessenen Verbindungen oder unbemerkt hergestellten Verbindungen abgehört zu werden. Obwohl nur sehr wenige Fälle in der Praxis bekannt wurden, wo ein Abhören stattfand, sollten sich die Teilnehmer aber der prinzipiellen Gefahr bewusst sein. Folgende Problemfelder ergeben sich: 1.) Mithören von Konferenzen ist möglich, sobald der Datenstrom zwischen den Endgeräten abgehört werden kann. Das ist in ungeswitchten Netzen prinzipiell von allen im Netzwerk befindlichen Geräten möglich. In geswitchten Netzen liegen die Daten zwar nur an den beteiligten Geräten an, jedoch ist nicht auszuschließen, dass durch Konfiguration oder Überlastung des Switches die Daten an andere Geräte im Netz gelangen können. Die Konferenzdaten selbst lassen sich dann mit üblichen Streaming-Playern (z.b. Real oder Quicktime) wiedergeben. Eine Verschlüsselung der Konferenzdaten für den IP-Bereich ist im Standard H.235 geregelt. Im ISDN-Bereich können Verschlüsslungsboxen hinter bzw. vor dem Gerät eingesetzt werden, welche eine abhörsichere Übertragung gewährleisten. 2.) Mithören bei Mehrpunktkonferenzen ist möglich, wenn ein Unbefugter Zugriff auf die Konferenz an der MCU bekommt. Die Anzeige der Teilnehmer an einer Mehrpunktkonferenz kann am Endgerät zwar für die Datenanwendung erfolgen, jedoch nicht für Audio und Video. Hier erfolgt die Teilnehmeranzeige über die MCU. Die MCU stellt den Teilnehmern diese Informationen per WWW zur Verfügung. Es ist also möglich, per Webinterface zu kontrollieren, wer Teilnehmer der Konferenz ist. Diese Möglichkeit sollte im Verlauf der Konferenz auch in regelmäßigen Abständen genutzt werden. 3.) Endgeräte müssen bei ihrer Anmeldung am Gatekeeper einen Alias-Namen und/oder eine Alias-Nummer angeben. Diese Aliase werden während der Zeit der Anmeldung über eine Tabelle im Gatekeeper der entsprechenden IP-Adresse zugeordnet. Andere Teilnehmer können diese Endgeräte durch Ruf eines Alias erreichen. Die Umsetzung des Alias in die IP-Adresse wird dabei vom Gatekeeper vorgenommen. Da die Endgeräte theoretisch jedes Mal einen anderen Alias verwenden könnten, ist es nötig, im Vorfeld einen Nummernplan aufzustellen. Hier sind Rufe zum falschen Endpunkt möglich, indem ein System bei der Anmeldung am Gatekeeper durch die Angabe eines fingierten Alias die Identität des ursprünglichen Gerätes vortäuscht. Dadurch würde ein Alias-Ruf eines anderen Teilnehmers beim falschen Endpunkt ankommen. Diese Verwechslung bei der Anmeldung muss nicht einmal absichtlich geschehen. Bei direkten Rufen ohne die Nutzung eines Gatekeepers besteht die Möglichkeit, dass ein anderes Gerät unter der IP-Adresse erreicht wird, falls im Routing oder im entfernten Netz eine Manipulation erfolgte. Der Gatekeeper des DFN verwendet eine Struktur mit vordefinierten Endgeräten. Bei diesem geschlossenen System können sich nur dem Gatekeeper bekannte Videokonferenzterminals an der MCU einwählen. Version 3.2 5