Lade Inhalt...

Technik, Sicherheit und Nutzen IP-basierter Real-Time-Kommunikation

Diplomarbeit 2006 125 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhalt

1 Konvergenz der Netze
1.1 Motivation und Erkenntnisziel
1.2 Aufbau der Arbeit

IP-basierte Real-Time-Kommunikation
2.1 Definition
2.2 Aktueller Stand
2.3 Wesentliche Aspekte bei der Migration
2.3.1 Planungsphase
2.3.2 Implementierungsphase
2.3.3 Produktivphase
2.4 Best-Practice-Beispiel

3 Technik
3.1 Komponenten (Hard- und Software)
3.1.1 IP-basierte Real-Time-Kommunikations-Lösungen
3.1.2 Endgeräte
3.1.3 Gateways
3.1.4 Session Border Controller
3.2 Protokolle der IP-basierten Real-Time-Kommunikation
3.2.1 Transmission Control Protocol / Internet Protocol
3.2.2 Real-Time Transport Protocol und Real-Time Control Protocol
3.2.3 H.323 vs. Session Initiation Protocol
3.2.4 Anrufsignalisierung mit dem Session Initiation Protocol
3.2.4.1 Systemkomponenten
3.2.4.2 Session Initiation Protocol-Nachrichten
3.2.4.3 Signalisierungsablauf
3.2.5 Gateway-Protokolle
3.3 Weitere Standards
3.3.1 Audio- und Videocodecs
3.3.2 Network Address Translation-Problematik
3.3.3 Telephone Number Mapping
3.3.4 Peer-to-Peer Kommunikation
3.4 Proprietäre Lösungen am Beispiel „Skype“
3.5 Quality-of-Service
3.5.1 Verzögerung
3.5.2 Jitter
3.5.3 Paketverluste
3.5.4 Überdimensionierung
3.5.5 Priorisierung von Paketen
3.5.6 Reservierung von Ressourcen

4.1 Sicherheit der Infrastruktur
4.2 Sicherheitsrisiken der herkömmlichen Telefonie
4.2.1 Denial-of-Service
4.2.2 Fernwartung
4.2.3 Sicherheitsaspekte von ISDN-Leistungsmerkmalen
4.2.4 Gebührenbetrug
4.2.5 Abhören
4.3 Sicherheitsrisiken in Datennetzen
4.3.1 Denial-of-Service
4.3.2 Schwachstellen der aktiven Netzelemente
4.3.3 Abhören
4.3.4 Schwachstellen in Betriebssystemen und Anwendungen
4.4 Sicherheitsrisiken IP-basierter Real-Time-Kommunikations-Systeme
4.4.1 Denial-of-Service
4.4.2 Abhören
4.4.3 Weitere Schwachstellen IP-basierter Real-Time-Kommunikations-Systeme
4.4.4 Evolution des Spam
4.4.5 Instant Messaging Risiken
4.4.6 Ist das Session Initiation Protocol ein sicheres Protokoll?
4.5 Sicherheitsmaßnahmen
4.5.1 Sichere IT-Infrastruktur als Basis einer sicheren IP-basierten Real-Time-Kommunikation
4.5.2 Schwachstelle „Mitarbeiter“
4.5.3 Firewalls
4.5.4 Spezifische Anforderungen an Firewalls
4.5.5 Angriffserkennung (Heuristiken)
4.5.6 Virtual Local Area Networks
4.5.7 Authentifizierung
4.5.8 Verschlüsselung
4.5.8.1 Secure SIP und Transport Layer Security
4.5.8.2 Secure Real-Time Protocol
4.5.8.3 Secure / Multipurpose Internet Mail Extensions
4.5.8.4 IPSec
4.5.8.5 Virtual Private Networks
4.5.9 Spam over Internet Telephony / Instant Messaging-Filter
4.6 Bewertung der Sicherheit

5.1 Kostenvorteile
5.1.1 Verbindungskosten
5.1.2 Infrastruktur
5.1.3 Hosted IP Services
5.2 Prozess-, Ablaufverbesserung und neue Funktionen
5.2.1 Video over IP
5.2.2 Instant Messaging
5.2.3 Verfügbarkeits- und Erreichbarkeitsstatus
5.2.4 Mobilität
5.2.5 Personalisierte Kommunikation
5.2.6 Integration von Informationstechnologie und Telekommunikation
5.3 Return on Investment und Total Cost of Ownership
5.4 Ausblick und weitere Entwicklung

Anhang A: H.323
Systemkomponenten
RAS-Control
Signalisierung
Ergänzende Funktionen nach H.450.x

Anhang B: SIP-Request / Response Nachrichten

Anhang C: Detaillierte Darstellung von SIP-Nachrichten

1 Konvergenz der Netze

“It’s important for everyone to understand and take advantage of the changes taking place. IP Communications is ‘disruptive’ communications in the most positive sense, and it will dramatically enhance the ways in which we communicate.”

Jeff Pulver, IPbRTK-Entrepreneur [PULV05a, S. 2]

Die Geschichte der Sprachkommunikation über das Internet begann bereits 1995 mit der Entwicklung der ersten Voice over Internet Protocol (VoIP) Software durch die israelische Firma Vocaltec. Angetrieben von der damaligen Internet- und New Economy-Euphorie entwickelte sich ein wahrer Hype. Marktforschungsinstitute prognostizierten gewaltige Wachstumsraten [WEIS03, S. 8], sogar von der gänzlichen Ablösung der herkömmlichen Telefonie war die Rede [ZIEG01, S. 154]. Die Technologie war zu diesem Zeitpunkt jedoch noch nicht ausgereift und auch die damals für die Datenübertragung verfügbaren Bandbreiten waren zu gering, um eine ausreichende Sprachqualität zu gewährleisten. Mit dem Platzen der Internetblase schwand die Aufmerksamkeit der Öffentlichkeit. Allerdings wurde die Technologie in der Zwischenzeit kontinuierlich weiterentwickelt.

Seit vergangenem Jahr ist als Folge der verbesserten Technik und der heute verfügbaren höheren Bandbreiten das Interesse der Öffentlichkeit und der Medien an der neuen Technologie wieder erheblich gestiegen.

VoIP isoliert zu betrachten ist kaum möglich, da die Sprachkommunikation in der Regel mit anderen Kommunikationsformen (Video und Text) kombiniert wird. Au-ßerdem ist VoIP mittlerweile ein vom Marketinghype der Telefonieanbieter belasteter Ausdruck, der lediglich auf günstige Gesprächsgebühren abzielt und dabei das Potenzial der Integration mit anderen Diensten und bestehenden Systemen außer Acht lässt. Um diesen Aspekten gerecht zu werden, wurde für diese Arbeit die Bezeichnung „Internet Protocol basierte Real-Time-Kommunikation“ (IPbRTK ‑ Definition siehe 2.1) gewählt.

In einem größeren Kontext ist die IPbRTK als die wichtigste Anwendung konvergenter Netze zu sehen [DELO05, S. 3]. Der Trend zur Konvergenz der Netze ist für die Zukunft der Informations- und Telekommunikationstechnik von enormer Bedeutung und lässt sich folgendermaßen definieren: „Konvergenz beschreibt (…) den evolutionären Prozess des Zusammenwachsens der ursprünglich weitgehend unabhängig operierenden Industrien Medien, Telekommunikation und Informationstechnologie. Sie kennzeichnet sowohl die Annäherung der Technologien als auch die Verbindung der Wertschöpfungsketten sowie das Zusammenwachsen der Märkte insgesamt“ [PICO01, S. 161]. Der Antrieb und die Notwendigkeit zur Konvergenz ergeben sich aus dem Zusammenspiel folgender drei Faktoren [SCHO03, S. 2]:

- Veränderte Informations- und Kommunikationsbedürfnisse der Nutzer (z.B. Mobilität – „jeder Dienst zu jeder Zeit an jedem Ort“, integrierte Sprach-, Video- und Textkommunikation),
- Technischer Fortschritt (z.B. Internet Protocol, höhere Bandbreiten, leistungsfähigere Endgeräte) und
- Veränderte gesetzliche und wirtschaftliche Rahmenbedingungen (Globalisierung und Deregulierung).

Die Entwicklung zu konvergenten Netzen führt zu substituierenden aber auch zu völlig neuen Diensten, welche aufgrund von Verdrängungs- und Kannibalisierungseffekten einschneidende Veränderungen der bestehenden oder sogar die Schaffung völlig neuer Kommunikationsmärkte zur Folge haben.

Das Beratungsunternehmen Deloitte Touche Tohmatsu bezeichnet die Konvergenz als „The Trillion Dollar Challenge“ und rechnet bis 2010 mit einem Marktvolumen von einer Billion Dollar, das sich aus neu entstehenden konvergenten Produkten und Diensten ergeben wird [DELO05, S. 1]. Für VoIP als wesentliches Element der Konvergenz wird ein Marktvolumen von 196 Milliarden Dollar im Jahr 2007 prognostiziert [DELO05, S. 3].

Betrachtet man die Chancen und Möglichkeiten, welche die beschriebenen Entwicklungen mit sich bringen, wird schnell deutlich, wie wichtig es für Unternehmen ist, sich diese zu Nutzen zu machen und in die eigenen Prozesse zu integrieren, um sich Wettbewerbsvorteile zu sichern bzw. Wettbewerbsnachteile zu vermeiden. Dies zeigt auch die Aussage: „If they don’t understand the technology, if they aren’t ready to make the move to IP, they actually take the worst of all decisions for their bottom line.“ von Andy Mattes, Präsident und CEO (Chief Executive Officer) Siemens Communications [MATT05, S. 3].

1.1 Motivation und Erkenntnisziel

„Nichts ist stärker, als eine Idee, deren Zeit gekommen ist!“

Victor Hugo (franz. Dichter 1802-1885)

„Eine Idee muss Wirklichkeit werden können, oder sie ist eine eitle Seifenblase."

Berthold Auerbach (deutscher Schriftsteller 1812-1882)

Die Motivation für diese Arbeit ergibt sich neben der Bedeutung der IPbRTK als wesentliches Element bei der Konvergenz der Netze u.a. aus folgenden Tatsachen, die im weiteren näher erläutert werden:

- Die von der IPbRTK bisher nicht erfüllten Erwartungen,
- Die prognostizierten Nutzenpotenziale,
- Die bestehenden und noch entstehenden Sicherheitsrisiken und
- Die Unsicherheit, die die IPbRTK aufgrund ihrer Bedeutung, Komplexität sowie der geringen Erfahrung mit der neuen Technologie mit sich bringt.

Die Anbieter von Hard- und Software sowie Diensten für die IPbRTK sind sich einig über die Praxistauglichkeit und den Nutzen der neuen Technologie. Auch Marktforschungsunternehmen bescheinigen enorme Chancen. Einer Studie der Economist Intelligence Unit zufolge planen bis Ende 2006 bereits 43% der befragten Unternehmen VoIP-Anwendungen einzusetzen [ATTC04, S. 2]. Doch angesichts der in Abschnitt 1 dargestellten Entwicklung stellt sich realistisch betrachtet die Frage, ob nun die Zeit für die neue Technologie gekommen ist, oder ob es sich nicht erneut nur um eine Blase handelt wie bereits um das Jahr 2000.

Die Nutzenpotenziale der neuen Technologie liegen neben der Kostensenkung durch günstigere Verbindungskosten sowie der gemeinsam genutzten Infrastruktur für Daten und Sprache vor allem in der Produktivitäts- und Effizienzsteigerung durch Integration in die bestehenden Prozesse sowie der verbesserten Erreichbarkeit.

Neben den Chancen gilt es allerdings auch die Risiken, welche die Umsetzung der Echtzeitkommunikation als IP-basierten Datendienst mit sich bringt, zu bewerten. Die folgenden Zahlen verdeutlichen zum einen den Wunsch der Nutzer entsprechende Anwendungen zu verwenden, zum anderen zeigen sie aber auch, dass das Thema Sicherheit selbst dann Beachtung finden muss, wenn noch keine Real-Time-Kommunikation auf IP-Basis im Unternehmen eingeführt wurde.

Die populäre VoIP-Anwendung Skype (www.skype.com – siehe 3.4) ermöglicht neben der Sprachkommunikation auch den Austausch von Dateien und Textnachrichten in Echtzeit (Instant Messaging). Skype wird bereits heute von 30% der aktuell über 100 Millionen registrierten Nutzer für geschäftliche Zwecke genutzt [SKYP05 u. SKYP06]. Es ist davon auszugehen, dass zumindest ein Großteil dieser Nutzer die Software außerhalb der gemanagten unternehmensinternen IT-Infrastruktur (Informationstechnik) und somit nicht nach den geltenden Sicherheitsrichtlinien der Unternehmen einsetzen [DATA05 u. CERN05]. Das von „illegal“ genutzten Anwendungen verursachte Sicherheitsproblem ist jedoch nicht auf Skype beschränkt. Laut Gart-ner wird in 70% der Unternehmen Instant Messaging (IM) Software genutzt, wobei nach einer Studie der Yankee Group lediglich 15-20% eine offizielle Lösung einsetzen [JOEP05].

Die aufgezeigten Chancen und Risiken veranschaulichen, dass es für Unternehmen unumgänglich ist, sich mit dem Thema IPbRTK auseinanderzusetzen. Da die Kommunikation für jedes Unternehmen einen erfolgskritischen Faktor darstellt, und es sich hier um eine junge Technologie handelt, ist eine intensive Auseinandersetzung mit diesem Thema in jedem Falle erforderlich.

Bei der Erstellung dieser Arbeit und dem Besuch verschiedener Fachveranstaltungen hat sich gezeigt, dass die aktuelle Situation von einer teilweise deutlichen Verunsicherung und Skepsis bei Anwendern und Entscheidern geprägt ist. Diese Unsicherheit lässt sich auf verschiedene Faktoren zurückführen. Das Image der neuen Technologie leidet noch heute unter den überzogenen Versprechungen aus der frühen Phase des Produktlebenszyklus einerseits und der gegenüber jungen Technologien typischen Skepsis andererseits. Dies und auch die bei den Risiken sehr gegensätzlichen Einschätzungen führen zu der erwähnten Verunsicherung. Wenn man sich jedoch die Komplexität vor Augen führt, die sich aus dem Zusammenwachsen der klassischen Telefonie mit der Welt der Informationstechnologie sowie insbesondere auch aus der Vielschichtigkeit der Technik der IPbRTK ergibt, werden die divergierenden Meinungen schnell verständlich.

Ziel dieser Arbeit ist es deshalb, auf Basis der aktuell verfügbaren Technologie einen objektiven Überblick über die realisierbaren Nutzenpotenziale und die bestehenden Sicherheitsaspekte zu erarbeiten.

Ein weiterer für den Entscheidungsprozess von Unternehmen relevanter Aspekt ist auch die Entwicklung rechtlicher und regulativer Rahmenbedingungen. Aufgrund der in diesem Bereich derzeit noch bestehenden Ungewissheiten und des begrenzten Umfangs dieser Arbeit wird jedoch auf eine detaillierte Ausarbeitung verzichtet. Dem interessierten Leser wird für Informationen über die Regulierung in Deutschland die Lektüre der Quellen [BUND05a] und [BUND05b] bzw. die Webseite der Bundesnetzagentur (www.bundesnetzagentur.de) empfohlen. Informationen über die Regulierung in den USA finden sich auf den Webseiten der zuständigen Behörde Federal Communications Comission (FCC – www.fcc.gov und www.voip911.gov).

Die Migration zu einem integrierten Kommunikations- und IT-System auf Basis einer gemeinsamen IP-Infrastruktur bedeutet auch, dass für die neuen Systeme die gleichen Dokumentationspflichten und Grundsätze des Risikomanagements (KontraG - Gesetz zur KONtrolle und TRAnsparenz im Unternehmensbereich, Basel2, Sarbanes-Oxley-Act) gelten wie für die bestehenden IT-Systeme. Da diese Problematik nicht speziell auf die hier behandelte Technologie bezogen ist, wird für diesbezügliche Informationen auf entsprechende Publikationen verwiesen.

1.2 Aufbau der Arbeit

Nach der Einordnung der IPbRTK in den Kontext der Konvergenz der Netze und der Erläuterung der Motivation für diese Arbeit (Kapitel 1 ) folgt zunächst ein allgemeiner Überblick zum Begriff IPbRTK (Kapitel 2 ).

Im Anschluss daran werden die technischen Grundlagen dargestellt. Dabei werden verschiedene Systemkomponenten sowie Protokolle und Standards beschrieben, auf deren Basis die IPbRTK realisiert wird. Auf verschiedene Lösungsansätze für Probleme und Herausforderungen, die sich im Zusammenhang mit der IPbRTK ergeben, wird ebenfalls eingegangen (Kapitel 3 ).

Anschließend werden Sicherheitsrisiken der klassischen Telefonie, der Datenkom-munikation sowie der IP-basierten Real-Time-Kommunikation herausgearbeitet und Gegenmaßnahmen vorgestellt (Kapitel 4 ).

Weiterhin wird der Nutzen erläutert, der sich für Unternehmen durch den Einsatz der IPbRTK ergibt (Kapitel 5 ).

Einen strukturellen Überblick über den Aufbau der Arbeit gibt Abbildung 1.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 : Aufbau der Arbeit

(eigene Darstellung)

2 IP-basierte Real-Time-Kommunikation

Wie bereits in Punkt 1 erwähnt, wird in dieser Arbeit anstelle des im allgemeinen Sprachgebrauch üblichen Begriffs VoIP der Ausdruck IPbRTK verwendet. Grund hierfür ist, dass auch Potenziale der Echtzeitkommunikation über das Internet Protocol (IP) betrachtet werden, die über die reine Telefonie hinausgehen. Für ein besseres Verständnis dieses Ausdrucks wird nach einer allgemeinen Definition zunächst ein Überblick über die aktuelle Situation gegeben. Anschließend werden einige wesentliche Aspekte bei der Migration dargestellt und ein derzeit typisches Einsatzszenario beschrieben.

2.1 Definition

Der Ausdruck IP-basierte Real-Time-Kommunikation bezeichnet jede Art von EchtzeitKommunikation, die über das Internet Protocol (siehe 3.2.1) übertragen wird, unabhängig davon, welches Übertragungsmedium (Kabel oder Funk) und welches Kommunikationsmedium (Sprache, Video oder Text) eingesetzt wird. Kommunikation in Real-Time bzw. Echtzeit bedeutet, dass die Informationen synchron, also ohne Verzögerungen (abgesehen von der Übertragungszeit), ausgetauscht werden.

Als Endgeräte kommen alle Geräte in Frage, die über das IP kommunizieren können und die Fähigkeit besitzen, die mithilfe weiterer benötigter Protokolle ausgetauschten Medien darzustellen bzw. wiederzugeben.

Welche Art von Kommunikation mit einem bestimmten Endgerät möglich ist, hängt von den jeweiligen Medienfähigkeiten ab. Neben der erforderlichen Software benötigt man z.B. ein Display zur Darstellung von Video- und Textkommunikation bzw. entsprechende Hardware für die Aufnahme und Wiedergabe von Audiosignalen für die Sprachkommunikation.

2.2 Aktueller Stand

Sowohl die ständig wachsende Anzahl der privaten IPbRTK-Nutzer als auch Umfragen bei Unternehmen zeigen einen eindeutigen Trend hin zur IPbRTK [TAYL04, S. 5 u. TAYL06, S. 6]. Derzeit findet eine Ende-zu-Ende IP-basierte Real-Time-Kommunikation (d.h. die Kommunikation findet zwischen Sender und Empfänger vollständig auf Basis IP-basierter Netze statt) jedoch meist nur innerhalb einzelner logisch abgegrenzter Netze (so genannte „IPbRTK/VoIP-Inseln“) statt. Verbindungen zu einem Ziel außerhalb der eigenen IPbRTK-Insel, was z.B. ein unternehmensinternes oder auch das IPbRTK-Netz eines Diensteanbieters sein kann, werden ge-genwärtig in der Regel über den Umweg der klassischen Telefonnetze oder durch private Peering- bzw. Routing-Vereinbarungen mit ausgewählten anderen IPbRTK-Inseln realisiert (als Routing wird die Weiterleitung der einzelnen Datenpakete im Netz an ihre Zieladresse bezeichnet). Bei einer solchen Vereinbarung einigen sich verschiedene Betreiber ihre Netze (bzw. in diesem Fall IPbRTK-Inseln) zu verknüpfen. Aufgrund der großen Zahl an IPbRTK-Inseln ist dies jedoch nur begrenzt praktikabel.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 : Private Peering- bzw. Routing-Vereinbarungen zwischen IPbRTK-Inseln

(eigene Darstellung)

In Abbildung 2 besteht eine private Vereinbarung, die eine Lokalisierung von Teilnehmern im jeweils anderen Netz ermöglicht, lediglich zwischen A und B. Eine Ende-zu Ende IP-basierte Echtzeitkommunikation findet also nur zwischen diesen beiden IPbRTK-Inseln statt. Alle anderen Echtzeitverbindungen zwischen den vier dargestellten Einheiten (Beispielsweise zwischen A und C oder C und D) werden über den Umweg des klassischen Telefonnetzes abgewickelt. Eine Alternative für dieses Problem wird in Abschnitt 3.3.3 erläutert.

Grund für diese Situation sind einerseits die nach wie vor unterschiedlichen Technologien/Protokolle, mit denen IPbRTK umgesetzt wird, und andererseits das bisher nicht abschließend geklärte Problem der Lokalisierung von Kommunikationspart-nern, die sich nicht im eigenen Netz befinden.

Ihr volles Potenzial hinsichtlich Kosten und Produktivität wird die IPbRTK erst dann entfalten können, wenn diese Probleme gelöst sind und jede Verbindung Ende-zu-Ende IP-basiert realisiert werden kann. Der Schritt zur offenen Real-Time-Kom-munikationsinfrastruktur auf Basis des Internet führt jedoch zu weiteren Herausforderungen, denn das Internet bietet keine Quality-of-Service-Garantien (QoS – siehe 3.5). Und auch Sicherheitsmaßnahmen sind zwar einerseits im nicht vertrauenswürdigen Internet für sicherheitskritische Verbindungen und Systeme unerlässlich, aber andererseits schwierig zu realisieren, da nicht mit jedem potenziellen Kommunikationspartner eine Vertrauensstellung etabliert werden kann.

2.3 Wesentliche Aspekte bei der Migration

Die Komplexität der Migration zur IPbRTK darf nicht unterschätzt werden. Neben den in dieser Arbeit näher beleuchteten technischen Grundlagen, Sicherheitsaspekten und realisierbarem Nutzen ist ein sorgfältiges Projektmanagement, das vor allem auch die Mitarbeiter berücksichtigt, für eine erfolgreiche Migration unerlässlich. Dass trotz aller Komplexität eine erfolgreiche Umstellung möglich ist, hat das Unter-nehmen Cisco Systems gezeigt. Mit der unternehmensweiten Migration wurde im Jahr 2000 begonnen und bereits innerhalb von zwölf Monaten waren fast 20. 000 Mitarbeiter am Standort San Jose in Kalifornien auf ein konvergentes Sprach- und Datennetz umgestellt [BRUN02, S. iii]. In den folgenden Abschnitten werden einige Aspekte beschrieben, die bei der Migration zu berücksichtigen sind.

2.3.1 Planungsphase

Bei der Zusammenstellung eines Projektteams ist auf fach- und funktionsübergreifendes Know-how zu achten. Selbstverständlich sind IT-, TK- (Telekommunikation) und Sicherheitsexperten, die über das nötige Wissen zur neuen Technologie wie auch der bestehenden Systeme verfügen, unerlässlich. Darüber hinaus ist auf Kenntnisse der Geschäfts- und vor allem auch Kommunikationsprozesse im Unternehmen zu achten, um deren Verbesserung möglich zu machen. Letztlich dürfen auch künftige Anwender aus allen betroffenen Bereichen des Unternehmens im Projektteam nicht fehlen. Die Einbeziehung der Anwender in das Projektteam ist ein erster Schritt, um Widerständen entgegen zu wirken, wie sie bei derart umfassenden Veränderungen zu erwarten sind. Wichtig für die Veränderungsbereitschaft der Mitarbeiter ist aber auch ein effizientes Change Management z.B. in Form von früher und offener Kommunikation der Änderungen, frühzeitiger Beginn mit Schulungen sowie Ermittlung der Anwenderwünsche und -erwartungen und deren Einbeziehung in den Planungsprozess.

Eine erfolgreiche Formel besagt, dass 80% der Projektzeit auf die Planung und Vorbereitung sowie 20% auf die Implementierung entfallen. Die Herausforderung besteht darin, ausgehend von der Ist-Situation eine möglichst konkrete Vorstellung über die Soll-Situation, d.h. die zukünftige Kommunikationsstrategie des Unternehmens, zu erarbeiten. Während dieser Phase gilt es zu überlegen, welche Funktionen gefordert werden, um später einen möglichst hohen Nutzen durch Kostenreduktion und Prozessverbesserung zu erreichen. Ebenfalls nicht zu vergessen ist die frühzei-tige Entwicklung und Berücksichtigung eines angemessenen Sicherheitskonzeptes [CARH05, S. 7f].

Anhand der erarbeiteten Kommunikationsstrategie können notwendige Systeme (Hard- und Software) und Dienstleistungen bestimmt werden sowie eine Auswahl entsprechender Anbieter erfolgen. Kommt eine Kosten-Nutzen-Analyse auf Basis der zu erwartenden Investitionen, Einsparungen und Produktivitätssteigerungen zu einem positiven Ergebnis, kann mit der Vorbereitung der Implementierung begonnen werden.

2.3.2 Implementierungsphase

Bei der Implementierung empfiehlt sich ein schrittweises Vorgehen, beginnend mit kleineren Testimplementierungen in weniger kritischen Bereichen, in denen sich z.B. eventuell auftretende Probleme nicht direkt auf Geschäftskontakte auswirken. Auf diese Weise können Änderungen auf Basis der zu Beginn gemachten Erfah-rungen noch ohne zu großen Aufwand in die Kommunikationsstrategie eingebracht werden. Bei späteren größeren Implementierungen in kritischen Bereichen ist dann aufgrund der bereits vorhandenen Erfahrungen das Risiko geringer, dass Probleme auftreten. Um einen möglichst reibungslosen Übergang sicher zu stellen, sind die Anwender auch in dieser Phase mit intensiver Schulung und Support zu unterstützen [CARH05, S. 7].

2.3.3 Produktivphase

Auch während der Produktivphase ist eine kontinuierliche Überprüfung der Kom-munikationsstrategie erforderlich. Die IPbRTK ist eine noch junge Technologie, deren Entwicklung noch nicht abgeschlossen ist. Und auch Unternehmen unterliegen im Wettbewerb einem ständigen Entwicklungs- und Veränderungsprozess. Hierdurch kann sich jederzeit die Chance zu weiteren Prozess- und Ablaufverbesserungen ergeben.

Weiterhin ist ein alle Systeme der IPbRTK umfassendes Updatemanagement und eine kontinuierliche Überprüfung und Anpassung der Sicherheitsstrategie notwendig, um Sicherheitsprobleme frühzeitig zu vermeiden. Nicht nur, aber vor allem bei Änderung und Erweiterung der Systeme sind wiederum die Anwender durch Schulung und Support zu unterstützen.

2.4 Best-Practice-Beispiel

Im Mai 2005 zog IBM Schweiz in den neuen Hauptsitz in Zürich ein. Dabei wurde von Beginn an Wert auf eine effiziente Informations- und Kommunikationsstrategie gelegt. Die strategischen Vorgaben für das Projekt waren klar definiert:

- Mobilität: Jeder Mitarbeiter soll jederzeit und an jedem Ort erreichbar sein und dabei jederzeit Zugriff auf benötigte Unterlagen und Ressourcen haben.
- Verfügbarkeit: Die Ausfallsicherheit der Systeme spielt eine zentrale Rolle.
- Konvergentes Informationsnetz: Die Daten- und Telefoninfrastruktur wird für alle Schweizer IBM-Niederlassungen in einem standardbasierten IP-Kommunikationsnetz zusammengeführt.
- Migration zur IPbRTK: Bisher betriebene herkömmliche Telefonanlagen werden auf IP-Technologie migriert. Als Endgeräte (siehe 3.1.2) werden Hardphones und auch Softphones für mobile Mitarbeiter eingesetzt [IBM05, S.1].

Im Rahmen des Projekts entstanden am Hauptsitz in Zürich 1.450 Arbeitsplätze für 2.400 Mitarbeiter, die mit 1.800 IP-Telefonen an den Arbeitsplätzen und in Sitzungszimmern versorgt werden. Bei der technischen Umsetzung hat man sich für eine sanfte Migrationsstrategie entschieden, bei der zunächst lediglich der Standort Zürich umgestellt wurde und andere Niederlassungen zu späteren Zeitpunkten folgten.

Zur Steigerung der Mitarbeiterproduktivität wurden Daten-, Sprach- und Videokommunikation weiter als bisher integriert. So dient die E-Mailbox zukünftig neben dem Empfang von E-Mails auch dem Empfang von Fax- und Sprachnachrichten. Weiterhin wird eine effizientere Zusammenarbeit zwischen Mitarbeitern und Geschäftspartnern durch neue Anwendungen, die z.B. eine vereinfachte Konfiguration der Sprachmailbox oder auch ein einfacheres Ansetzen von Telefonkonferenzen ermöglichen, erreicht. Außerdem ist die völlige Integration der Sprachkommunikation in die bestehenden IT-Systeme geplant, um zusätzliche Funktionen wie z.B. IM zu realisieren.

Um auch die Sicherheit der neuen Systeme zu gewährleisten, wurden die unterwegs oder zu Hause tätigen Mitarbeiter über ein Virtual Private Network (siehe 4.5.8.5) an die Infrastruktur angebunden.

Auch hinsichtlich der Qualität des Netzes wurde ein gutes Ergebnis erzielt. Theoretisch könnte simultan jeder Mitarbeiter mit jedem Mitarbeiter telefonieren und das Netz wäre immer noch nicht überlastet [IBM05, S. 1-3].

Der Erfolg der Migration drückt sich in folgenden Kostensenkungen aus:

- Bei Infrastruktur und Verkabelung um 30%,
- Bei Management- und Administrationsaufwand um 25% und
- Bei Kommunikationskosten durch kostenfreie unternehmensinterne Verbindungen um 25% [IBM05, S. 3].

3 Technik

Die Anforderungen an die IPbRTK sind sehr hoch, denn die Anwender sind aus den herkömmlichen Telekommunikationsnetzen eine gute bis sehr gute Sprachqualität gewohnt und möchten darauf nicht verzichten. Auch der bekannte Funktionsumfang muss bei einer gleichzeitig einfacheren und flexibleren Anwendung erhalten bzw. erweitert werden, um eine Umstellung auf die neue Technologie zu rechtfertigen.

Um all diese Erwartungen auf Basis des IP erfüllen zu können, wurde eine ganze Reihe von Protokollen und Standards sowie auf diesen basierende Hard- und Software entwickelt. Insbesondere die Tatsache, dass das Internet ursprünglich nicht für die Kommunikation in Echtzeit entwickelt wurde, hat verschiedene Standards z.B. zur Sicherstellung der Qualität, der Adressierung und vor allem auch der Abwicklung der eigentlichen Kommunikation notwendig gemacht. Um den unterschiedlichsten Anforderungen vom Privatanwender bis zum Großunternehmen individuell gerecht zu werden, ist mittlerweile ein breites Angebot an Hard- und Software verfügbar.

Im folgenden Kapitel werden die technischen Grundlagen der wichtigsten Standards und Protokolle sowie Systemkomponenten der IPbRTK vorgestellt.

3.1 Komponenten (Hard- und Software)

So komplex wie die Echtzeitkommunikation ist auch die Auswahl der benötigten Hard- und Software. Neben den Kosten sind beim Entscheidungsprozess zahlreiche weitere Faktoren wie z.B.

- Funktionsumfang,
- Anwenderfreundlichkeit,
- Skalierbarkeit,
- Kompatibilität und auch die
- Sicherheit

zu berücksichtigen. Wichtig für die Akzeptanz durch die Nutzer sind auch das Anwendungserlebnis und eine einfache Bedienung. Für eine erfolgreiche Nutzung der IPbRTK ist es entscheidend, dass sämtliche Komponenten die Anforderungen der Kommunikationsstrategie eines Unternehmens erfüllen. Eine Marktübersicht zu Anbietern, Komponenten und Lösungen findet sich in [FAJG06, S. 40-54]. Im Folgenden werden die wichtigsten für die IPbRTK notwendigen Komponenten vorgestellt. Erläuterungen zu weiteren, spezifischeren Komponenten folgen in den Abschnitten:

- 3.2.4.1: Session Initiation Protocol-Systemkomponenten,
- 4.5.4 u. 4.5.5: Sicherheitskomponenten sowie in
- Anhang A: H.323-Komponenten.

3.1.1 IP-basierte Real-Time-Kommunikations-Lösungen

IPbRTK-Lösungen sind das Äquivalent zu herkömmlichen Telefon- bzw. Nebenstellenanlagen und damit das Herzstück einer IPbRTK-Umgebung. Alternative Bezeichnungen für diese Systeme sind IP-Telekommunikationsanlage oder auch IP-Pri-vate Branch Exchange (PBX). Es sind sowohl rein IP-basierte als auch hybride Lösungen, die neben der IP-Kommunikation auch die klassische leitungsvermittelte Telefonie ermöglichen, erhältlich. Weiterhin lassen sich die Lösungen in Hardware- und Software-basiert unterscheiden.

Zu den vielfältigen Aufgaben dieser Systeme zählen neben der Realisierung der eigentlichen Kommunikationsfunktionen z.B. auch die Registrierung und Lokalisierung der Teilnehmer. Ergänzend zu den klassischen Funktionen einer Telefonanlage sind darüber hinaus häufig auch weitergehende Leistungsmerkmale wie z.B. Sicherheits- und Gatewayfunktionen (siehe 3.2.5) integriert.

Aufgrund der zentralen Rolle, die diese Systeme in einer IPbRTK-Infrastruktur spielen, ist eine sorgfältige Auswahl insbesondere hinsichtlich Verfügbarkeit, Skalierbarkeit und Funktionsumfang sehr wichtig [FAJG06, S. 30].

3.1.2 Endgeräte

Softphones sind Software-Applikationen, mit denen ein Rechner als Telefon genutzt werden kann. Neben der Software werden ein Mikrofon und Lautsprecher für die Aufnahme bzw. Wiedergabe des Gesprächs benötigt. Zu diesem Zweck kommen häufig Headsets (Kombination aus Kopfhörer und Mikrofon) zum Einsatz. In vielen Fällen werden Softphones in einer Kommunikationsanwendung mit anderen Formen der Kommunikation wie z.B. IM und E-Mail kombiniert.

Softphones sind eine günstige Möglichkeit IPbRTK auf Anwenderseite zu realisieren. Sie haben allerdings den Nachteil, dass erstens das gewohnte „Telefoniegefühl“ mit Telefon am Ohr verloren geht, und zweitens stehen sie nur zur Verfügung, wenn auch der Rechner läuft, auf dem sie installiert sind [FAJG06, S. 30].

Hardphones sind eigenständige Geräte, die optisch an herkömmliche Telefone angepasst sind. Sie sind zwar etwas teurer als Softphones, haben dafür aber auch nicht deren Nachteile und können auch unabhängig von einem Rechner genutzt werden. Dies ist möglich, da die Hardphones bzw. IP-Telefone je nach Ausführung über einen eigenen Local Area Network-Anschluss (LAN) verfügen oder Wireless-LAN-fähig (WLAN) sind. Diese Geräte verfügen häufig über Displays, die auch über die klassische Telefonie hinausgehende Funktionen der IPbRTK ermöglichen. Beispiele hierfür sind Präsenzanzeige (siehe 5.2.3), Überprüfung von E-Mail-Accounts oder auch Videotelefonie (siehe 5.2.1) [FAJG06, S. 30 u. KHAS03, S. 70].

Telefonadapter: Eine Lösung um sich beim Einstieg in die IPbRTK die Anschaffung von Hardphones zu sparen sind Telefonadapter. Auf diese Weise können vorhandene herkömmliche Analog- oder auch Integrated Services Digital Network-Telefone (ISDN) weiter genutzt werden. Auch in diesem Fall ist die Nutzung der Telefone unabhängig von einem Rechner möglich. Interessant ist diese Möglichkeit vor allem für Privatanwender und kleine Unternehmen mit wenigen Anschlüssen. Für diese Szenarien sind günstige Geräte auf dem Markt, die z.B. eine hybride Telefonanlage mit Anschlussmöglichkeiten für herkömmliche Telefone, DSL-Modem (Digital Subscriber Line) und (WLAN-)Router kombinieren und somit einen kostengünstigen Einstieg in die IP-basierte Sprachkommunikation ermöglichen [MANS05, S. 108-110].

Mobile Endgeräte: Selbstverständlich kommen neben den kabelgebundenen Lösungen auch IP-fähige mobile Endgeräte wie z.B. Mobiltelefone oder PDAs (Personal Digital Assistant) für die IPbRTK in Frage.

3.1.3 Gateways

Gateways ermöglichen die Kommunikation zwischen Netzen, die unterschiedliche Protokolle verwenden. Dies geschieht z.B. durch Übersetzung zwischen Protokollen der IPbRTK und dem herkömmlichen Telefonnetz [MEYE03, S. 222]. Verfügbar sind Gateways als eigenständige Geräte bzw. Anwendungen oder auch als Bestandteil von hybriden Telefonanlagen. Die Leistungsfähigkeit hängt zum einen von der Anzahl der unterstützten Protokolle und zum anderen von der Anzahl der maximal simultan möglichen Verbindungen ab [FAJG06, S. 39].

3.1.4 Session Border Controller

Im Zusammenhang mit der IPbRTK ist häufig von so genannten Session Border Controllern (SBC) die Rede. Die Tatsache, dass es sich hierbei in erster Linie um einen Marketingbegriff ohne klare technische Bedeutung handelt, führt dazu, dass der Nutzen von SBC kontrovers diskutiert wird. Technisch gesehen ist ein SBC ein zentrales System, über das sowohl die Signalisierungs- (Auf- und Abbau von Kommunikationssitzungen) als auch die Medieninformationen geroutet werden. Je nach Ausführung versprechen SBC durch Kontrolle und Manipulation dieser Informationen die Lösung verschiedener Probleme im Zusammenhang mit der IPbRTK. Die wichtigsten Funktionen, die von SBC bereitgestellt werden, sind:

- Peering zwischen IPbRTK-Inseln (siehe 3.3.3),
- Verbesserung der Interoperabilität durch Gatewayfunktionen (Übersetzen zwischen verschiedenen Protokollen und Codecs ‑ siehe 3.1.3 und 3.3.1),
- Quality-of-Service-Funktionen (siehe 3.5),
- Lösung des Network Address Translation-Problems (siehe 3.3.2) und
- Sicherheitsfunktionen (z.B. Verschlüsselung, Überprüfung der Protokollkonformität – siehe 4.5)

Eine detailliertere Beschreibung der zahlreichen SBC-Funktionen findet sich in [HARD05].

Den genannten Vorteilen stehen jedoch auch einige Nachteile gegenüber. Durch das Routing der gesamten IPbRTK über den SBC entsteht zum einen ein erhöhter Bedarf an Bandbreite und zum anderen kann sich der Übertragungsweg signifikant verlängern. Dies kann zu Quality-of-Service-Problemen führen und damit den an dieser Stelle versprochenen Nutzen zunichte machen. Problematisch ist weiterhin, dass beim Ausfall eines zentralen Kontrollelements, wie beispielsweise ein SBC, keine Kommunikation mehr möglich ist. Diese Bedenken werden gestützt durch Erfahrungen aus der Praxis, die gezeigt haben, dass SBC zumindest derzeit noch mit Zuverlässigkeitsproblemen zu kämpfen haben. Die Praxiserfahrung hat auch gezeigt, dass SBC häufig mit einigen Protokollerweiterungen nicht zu Recht kommen. Obwohl SBC die Interoperabilität verbessern sollen, muss also damit gerechnet werden, dass neue Kompatibilitätsprobleme auftauchen [KUTH06, S. 6-11].

Im konkreten Fall ist letztlich immer eine sorgfältige Abwägung zwischen Vor- und Nachteilen notwendig, um zu entscheiden, ob eine Investition in eine zusätzliche Komponente sinnvoll ist, die außerdem Wartungs- und Administrationskosten verursacht. Bei den Überlegungen darf auch nicht vergessen werden, dass für die Probleme, die die SBC lösen sollen, auch alternative Lösungsansätze vorhanden sind. Querverweise zu den in dieser Arbeit beschriebenen Alternativen finden sich jeweils in Klammern in der obigen Aufzählung.

3.2 Protokolle der IP-basierten Real-Time-Kommunikation

Die Protokollfamilie TCP/IP (Transmission Control Protocol/Internet Protocol) ist die Grundlage der rechnergestützten Kommunikation. Für die Übertragung von Da-ten wie Sprache und Video in Real-Time sind jedoch verschiedene spezielle Protokolle nötig [BADA04, S. 67].

Die derzeit wichtigsten Standards für die paketbasierte Echtzeitkommunikation sind zum einen das Session Initiation Protocol (SIP) und zum anderen das H.323 Framework. Die beiden Standards regeln vor allem die Anrufsignalisierung (bzw. kurz Signalisierung) von paketbasierten Kommunikationssitzungen. Die Verhandlung über die Prinzipien der eigentlichen Kommunikation, wie z.B. die verwendete Sprachcodierung, wird ebenfalls durch diese Protokolle geregelt [BADA04, S. 47]. Neben diesen grundlegenden und für eine Kommunikation unverzichtbaren Funktionen stellen diese Protokolle aber auch weitergehende Funktionen wie z.B. Anrufweiterleitungen, Anrufverzweigungen oder auch Umleitungen zur Verfügung.

Für die Übermittlung der Echtzeitmedien (z.B. Sprache und Video) verwenden beide Standards das Real-Time Transport Protocol (RTP) bzw. die um Sicherheitsfunktionen erweiterte Version Secure Real-Time Protocol (SRTP) sowie die dazugehörigen Kontrollprotokolle Real-Time Control Protocol (RTCP) bzw. Secure Real-Time Control Protocol (SRTCP), die in den Abschnitten 3.2.2 bzw. 4.5.8.2 näher erläutert werden [BADA04, S. 86f].

Weitere Standards und Protokolle, welche die Realisierung und die Funktionalität von Echtzeitkommunikation ermöglichen, sind z.B. ENUM (tElephone NUmber Mapping, s. 3.3.3) oder auch das Media Gateway Control Protocol (MGCP) und Megaco (Media Gateway Control), die die Steuerung von Media-Gateways regeln (siehe 3.2.5). Abbildung 3 zeigt die Struktur der TCP/IP-Protokollfamilie sowie die Einordnung verschiedener Protokolle der IPbRTK in das ISO/OSI-Referenzmodell (International Standards Organization/Open System Interconnection Modell), das die Zusammenarbeit von Hard- und Software beim Informationsaustausch zwischen offenen Systemen beschreibt. Für die Echtzeitkommunikation relevante bzw. spezifische Protokolle sind in der Abbildung gelb hinterlegt und werden im Folgenden genauer beleuchtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 : TCP/IP-Protokollfamilie und spezielle IPbRTK-Protokolle

(in Anlehnung an [BADA04, S. 68] )

3.2.1 Transmission Control Protocol / Internet Protocol

Der Zusammenhang zwischen der TCP/IP-Protokollfamilie und dem ISO/OSI-Referenzmodell wurde in Abbildung 3 aufgezeigt. Das erste vom Übertragungsmedium unabhängige und somit für diese Arbeit relevante Protokoll ist das in der Netzwerkschicht angesiedelte Internet Protocol (IP). Es ist zuständig für die Adressierung sowie Fragmentierung der Datenpakete. Die Übertragung der Datenpakete erfolgt beim IP verbindungslos, d.h. es wird keine virtuelle Verbindung aufgebaut und die korrekte Übermittlung ist nicht garantiert. Für die korrekte Übermittlung enthält jedes Paket sowohl eine Absender- als auch eine Empfängeradresse in Form von IP-Adressen, die mithilfe des Address Resolution Protocol (ARP) den physikalischen Adressen (so genannte Media Access Control-Adressen, kurz MAC-Adressen) der Rechner zugeordnet werden.

Neben dem Header, der u.a. die IP-Adressen enthält, besteht ein IP-Paket aus der Nutzlast, die in der Regel ein TCP- (Transmission Control Protocol) oder UDP-Paket (User Datagram Protocol) ist. TCP ist ein verbindungsorientiertes Transportprotokoll auf der Transportschicht des ISO/OSI-Modells. Zu Beginn einer Kommunikation über TCP wird eine Verbindung aufgebaut und mithilfe von Fehlerkorrekturmechanismen wird die korrekte Übertragung der Daten sichergestellt. Da der Aufbau der TCP-Verbindung sowie die Fehlerkorrektur Zeit kosten, ist diese Art der Datenübertragung für zeitkritische Anwendungen, wie z.B. die Übertragung von Multimediadaten in Echtzeit, problematisch. Derartige Anwendungen setzen deshalb auf das verbindungslose Protocol UDP.

Wie bereits erwähnt werden die TCP- und UDP-Pakete als Nutzlast in IP-Paketen übertragen. Dieses Verfahren nennt man Einkapselung. Sowohl TCP- als auch UDP-Pakete bestehen wiederum aus einem Header und der Nutzlast, wobei sich die Nutzlast hier aus dem jeweiligen Anwendungsprotokoll höherer Schichten des ISO/OSI-Modells ergibt [THAL02, S. 10-15].

3.2.2 Real-Time Transport Protocol und Real-Time Control Protocol

Protokolle, die für die Datenübertragung entwickelt wurden, sind aufgrund ihrer Mechanismen zur Fehlerkorrektur nur bedingt für die Übermittlung von Audio und Video in Echtzeit über IP-Netze geeignet. Deshalb wurde das RTP von der Internet Engineering Task Force (IETF) entwickelt und liegt seit 2003 in der aktuellen Version nach RFC (Request for Comment) 3550 vor. RTP ist ein Transport Protokoll, das jedoch auf UDP aufsetzt und daher meist als Anwendungsprotokoll oberhalb der Transporschicht eingeordnet wird.

Vor der Übertragung von Multimediadaten muss zunächst eine RTP-Session bzw. RTP-Sitzung aufgebaut werden, über welche die Daten dann in RTP-Paketen übermittelt werden. Das RTP stellt sicher, dass die Pakete sowohl in der korrekten Reihenfolge als auch in gleichen Zeitabständen am Ziel wieder hergestellt werden können. Zu diesem Zweck enthält jeder RTP-Header einen Zeitstempel sowie eine Sequenznummer. Neben weiteren Informationen gibt der Header auch an, welche Art von Medien (Audio, Video oder beides) in der Nutzlast (auch Payload genannt) über-mittelt wird.

Da RTP das verbindungslose UDP nutzt und somit Pakete verloren gehen oder in einer anderen Reihenfolge ankommen können, wurde das RTCP entwickelt. Mithilfe des RTCP, welches ebenfalls in RFC 3550 spezifiziert ist, tauschen die an einer RTP-Session beteiligten Endpunkte Informationen über die Qualität der eigentlichen Übertragung aus [BADA04, S. 148-159]. Eine um Sicherheitsfunktionen erweiterte Variante von RTP ist das SRTP, welches in Punkt 4.5.8 näher erläutert wird.

Eine Multimediakommunikation ist alleine mit RTP allerdings nicht zu realisieren. Bevor die eigentliche Kommunikation starten kann, muss zunächst eine Verbindung zwischen den Kommunikationspartnern hergestellt werden, und diese müssen sich über die Grundsätze der Kommunikation einigen. Dieser Prozess wird Anrufsignalisierung oder kurz Signalisierung genannt. H.323 und SIP sind die derzeit wichtigsten Standards die diese Aufgabe übernehmen.

3.2.3 H.323 vs. Session Initiation Protocol

Obwohl sowohl H.323 als auch SIP mit dem Ziel entwickelt wurden, multimediale Kommunikation über paketbasierte Netze zu ermöglichen, unterscheiden sich die beiden Ansätze deutlich. Die Divergenz der beiden Standards resultiert aus ihrer unterschiedlichen Herkunft. Der ältere H.323-Standard hat seine Wurzeln in her-kömmlichen Telekommunikationsnetzen. So wurden z.B. die Signalisierungsnachrichten nach H.225.0 vom ISDN-Standard Q.931 sowie auch die binäre Codierung der Nachrichten übernommen. SIP hingegen wurde in Anlehnung an bereits beste-hende Internettechnologien entwickelt. Daher wurden die SIP-Response Nachrichten weitgehend denen des HTTP (Hypertext Transfer Protocol) angepasst und sind somit textbasiert. Die binäre Codierung der Nachrichten hat den Vorteil, dass die Nachrichtengröße reduziert wird, allerdings ist die Implementierung komplexer als bei Anwendungen mit textbasierten Nachrichten.

Weiterhin ist H.323 ein Dachstandard, der in den einzelnen Unterstandards sämtliche Funktionalitäten festschreibt, die für ein multimediales Kommunikationssystem benötigt werden. Im Vergleich dazu beschränkt sich SIP auf die Basisfunktionen Anrufsignalisierung sowie Teilnehmerlokalisierung und -registrierung, während für zusätzliche Anforderungen weitere nicht zwingend vorgeschriebene Standards und Protokolle zum Einsatz kommen. Durch diesen monolithischen Ansatz erhöht sich ebenfalls die Komplexität des H.323 im Vergleich zum modular aufgebauten Session Initiation Protocol [DETK02a, S.349].

Trotz der nach wie vor vorhandenen Unterschiede (siehe Tabelle 1) haben sich die konkurrierenden Ansätze im Laufe ihrer Entwicklung mehr und mehr angeglichen. Beispielsweise unterstützen beide Standards mittlerweile sowohl TCP als auch UDP, obwohl H.323 zunächst lediglich TCP als Transportprotokoll verwendete, während SIP auf dem verbindungslosen UDP basierte. Eine Angleichung lässt sich auch in Sachen Funktionsumfang erkennen, so wurden z.B. Konferenzen von H.323 von Beginn an unterstützt, bei SIP hingegen kam diese Funktionalität erst später hinzu. Ein weiteres Beispiel für die Evolution der Standards ist die Einführung der Fast Connect-Prozedur mit der zweiten Version von H.323, welche die für den Verbindungsaufbau benötigte Zeit (Call Setup Delay, ausgedrückt in Round-Trips) reduzierte [JOHN04, S. 188f].

Folge dieses Entwicklungsprozesses ist, dass viele in der Vergangenheit publizierten Vergleiche zwischen den beiden Ansätzen mittlerweile obsolet geworden sind. Es wird auch deutlich, dass eine Aussage darüber, welcher Standard aus technischer Sicht bzw. bezüglich Funktionalität der bessere ist, aufgrund der kleiner werdenden Unterschiede derzeit lediglich als Einzelfallentscheidung zu treffen ist bzw. auf längere Sicht kaum möglich ist.

Eine Entscheidung zwischen den beiden Standards kann allerdings auch nicht nur anhand der technischen Details bzw. dem Funktionsumfang gefällt werden. Selbst-verständlich müssen außerdem die entstehenden Kosten sowie Aspekte der Investitionssicherheit berücksichtigt werden. Insbesondere für die Investitionssicherheit ist es von Bedeutung, inwieweit sich ein Standard durchsetzt und von Hard- und Softwareanbietern unterstützt wird. Neue Produkte im IPbRTK-Umfeld basieren mittlerweile fast ausschließlich auf dem SIP-Protokoll, was auch dazu geführt hat, dass die Begriffe VoIP- und SIP-Kommunikation häufig gleichbedeutend verwendet werden. Um dieser Entwicklung Rechnung zu tragen, konzentriert sich diese Arbeit auf das neuere SIP-Protokoll. Da jedoch in der Realität nach wie vor H.323-Implementie-rungen exisiteren, findet sich in Anhang A eine detaillierte Beschreibung dieses Ansatzes.

Tabelle 1 : Vergleich von H.323 und SIP

(eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

3.2.4 Anrufsignalisierung mit dem Session Initiation Protocol

Der aktuell wichtigste Standard für die paketbasierte Real-Time-Kommunikation ist das SIP, welches von der IETF entwickelt wurde. Nachdem die IETF 1999 die erste Version des Standards als RFC 2543 veröffentlichte, liegt seit Mitte 2002 die aktuelle Version im RFC 3261 vor, die u.a. durch die RFCs 3262-3265 ergänzt wird. Neben den genannten Basis-RFCs existieren derzeit über 70 weitere, die sich mit SIP sowie zusätzlichen und unterstützenden Funktionalitäten beschäftigen. Nicht zuletzt diese große Zahl verdeutlicht die umfangreichen Funktionalitäten und Möglichkeiten des SIP [SINN05, S. 4].

RFC 3261 definiert SIP als Kontrollprotokoll auf der Anwendungsschicht, welches Multimediaverbindungen (und Konferenzen) aufbauen, modifizieren und beenden kann. Die fünf Aufgaben, die SIP bei der Multimediakommunikation erfüllt, sind:

- Benutzerlokalisierung,
- Benutzerverfügbarkeit,
- Benutzerfähigkeiten,
- Verbindungsaufbau und
- Verbindungsmanagement [IETF02, S. 8].

Weiterhin ist SIP ein Anrufsignalisierungsprotokoll und somit nicht als komplettes System für die multimediale Kommunikation zu sehen. Erst im Zusammenspiel mit anderen IETF-Protokollen ist z.B. die Übermittlung von Audio- und Videodaten in Echtzeit (RFC 3550 - RTP/RTCP –­­ siehe 3.2.2), die Beschreibung von Multimediaverbindungen (RFC 2327 – Session Description Protocol, kurz SDP) oder auch die Kommunikation mit herkömmlichen Telefonnetzen (RFC 3015 – MEdia GAteway COntrol Protocol, kurz MEGACO – siehe 3.2.5) möglich [IETF02, S.8f].

3.2.4.1 Systemkomponenten

Da SIP ein Client-Server-Protokoll ist, lassen sich die SIP-Systemkomponenten in Clients und Server klassifizieren. Dabei ist jeweils die Komponente, die eine Anfrage (Request) sendet, der Client und die empfangende sowie antwortende Komponente der Server [BADA04, S. 267]. Das SIP unterscheidet sechs Komponenten:

- User Agents,
- Proxy Server,
- Location Service,
- Redirect Server,
- Registrar Server und
- Gateways.

User Agent: SIP-fähige Endgeräte nennt man User Agents (UA). Sie werden je nach der Rolle, die sie entsprechend dem Client-Server-Modell einnehmen, als User Agent Client (UAC) oder als User Agent Server (UAS) bezeichnet.

Proxy Server: Der SIP Proxy Server ist mit einem H.323-Gatekeeper vergleichbar (siehe Anhang A: H.323). Aufgabe des SIP Proxy Servers ist es, Anfragen von Endgeräten oder auch anderen Proxy Servern entgegenzunehmen und zu beantworten oder in deren Auftrag an andere Proxy Server oder Endgeräte weiterzuleiten (Routing). Somit tritt auch ein Proxy Server sowohl als Server wie auch als Client auf. Ein Proxy Server muss die SIP-Nachrichten nicht verstehen, um sie weiterzuleiten. Es ist aber zulässig, dass ein Proxy Server Headerinfomationen verändert oder auch hinzufügt (z.B. dass die Antwort über ihn geroutet werden soll). Weiterhin kann ein Proxy Server die Authentifizierung und Autorisierung der Clients übernehmen [DURK03, S. 41f]. Drei Eigenschaften unterscheiden einen Proxy Server von einem User Agent oder einem Gateway [IETF02, S. 13 u. JOHN04, S. 47f]:

- Ein Proxy Server versendet keine eigenen Anfragen (Ausnahme: cancel request),
- Ein Proxy Server hat keine Medienfähigkeiten und
- Ein Proxy Server analysiert nicht die Nutzlast von Nachrichten, sondern lediglich die Header-Felder.

Prinzipiell ist es auch möglich, bei Verzicht auf dessen Funktionalitäten, ohne Proxy Server Verbindungen aufzubauen.

Location Service: Damit der Proxy Server eine Nachricht korrekt an das Ziel weiterleiten kann, muss er dieses in der Regel zunächst lokalisieren. Wie dies realisiert wird, ist im SIP nicht konkret festgeschrieben. Für die Lokalisierung können sowohl Datenbanken, die Informationen darüber enthalten wo sich das Ziel befindet, als auch DNS (Domain Name Service) verwendet werden [DURK03, S. 41f]. Die DNS-Adressauflösung wird dadurch möglich, dass die SIP-Adressierung an die Adressierung im Internet angepasst wurde, indem sie Uniform Resource Locators (URLs) benutzt. Dementsprechend kann somit eine SIP-URL folgendermaßen aussehen: Benutzer@Domain, Benutzer@IP-Adresse, Telefonnummer@Domain oder auch Telefonnummer@IP-Adresse [BADA04, S. 266].

Redirect Server: Wie der Proxy Server nimmt auch der Redirect Server Anfragen von SIP Clients entgegen. Allerdings leitet er diese nicht weiter, sondern beantwortet sie lediglich.

Registrar Server: Aufgabe des Registrars ist es, Registrierungsanfragen von UACs entgegenzunehmen und diese zu authentifizieren [DURK03, S. 42].

SIP-Gateway: Ein SIP-Gateway ist dafür zuständig, die Kommunikation mit anderen Netzen, wie z.B. H.323-Netzen oder dem Public Switched Telephone Network (PSTN), zu ermöglichen, indem es die SIP-Nachrichten in das jeweils andere Format „übersetzt“.

Die hier vorgestellten Server sind logische Einheiten, die auch gemeinsam implementiert werden können, z.B. kann der Registrar im Proxy- oder Redirect Server integriert sein [JOHN04, S. 46f].

3.2.4.2 Session Initiation Protocol-Nachrichten

SIP-Nachrichten lassen sich in die zwei Arten Request (Anfrage) und Response (Antwort) unterscheiden. Die Nachrichten sind textbasiert und zeilenweise strukturiert. Die Startzeile, mit der jede Nachricht beginnt, enthält den Namen des Nachrichtentyps. Anschließend folgt der Nachrichten Header, wobei jede der folgenden Zeilen jeweils ein Header-Feld repräsentiert. Die Header-Felder sind nach dem Muster „Feld-Name: Feld-Parameter“ aufgebaut.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 : Schematische Darstellung des Aufbaus von SIP-Nachrichten

(eigene Darstellung)

Das Ende des Headers wird immer mit einer Leerzeile angezeigt, auf die optional der Message Body folgt. Im Message Body, der auch als Nutzlast der SIP-Nachricht bezeichnet werden kann, wird z.B. die RTP-Session anhand des Session Description Protocol (SDP) genauer beschrieben, um die Kompatibilität der Endgeräte sicherzustellen [IETF02, S. 12f]. Den schematischen Aufbau von SIP-Requests bzw. SIP-Responses zeigt Abbildung 4.

SIP-Requests: Bei Requests enthält die als Request-Line bezeichnete Startzeile neben dem Request-Typ die Zieladresse sowie die SIP-Version. Während im RFC 3261 sechs Request-Typen (auch Methoden genannt) definiert sind, werden in weiteren RFCs zusätzliche Typen definiert [IETF02, S. 26]. Tabelle 8 (siehe AnhangB) gibt einen Überblick über die wichtigsten Request-Methoden sowie die RFCs, in denen sie spezifiziert sind. Die Antwort auf die in einem SIP-Request geforderte Aktion erfolgt in Form einer Response-Nachricht [BADA04, S.259-264].

SIP-Response: Die Startzeile einer Response-Nachricht wird als Status-Line bezeichnet und enthält die Protokollversion sowie einen dreistelligen, numerischen Status-Code (auch Response Code genannt) und dessen Bezeichnung. Die Response-Nachrichten sind in sechs Klassen unterteilt, aus denen sich auch die erste Stelle des Status-Code ergibt [IETF02, S. 27f]. Tabelle 9 (siehe Anhang B) enthält alle im RFC 3261 definierten Response-Codes. Neben der Verwandtschaft mit den HTTP Re-sponse Nachrichten lässt sich anhand der Response Codes bzw. der textbasierten Beschreibung die Funktionsweise des SIP erkennen [IETF02, S. 181-191].

Tabelle 2 : Die wichtigsten SIP Header-Felder

(in Anlehnung an [BADA04, S. 263f] )

Abbildung in dieser Leseprobe nicht enthalten

Header-Felder: Tabelle 2 gibt einen Überblick über die für einen Verbindungsaufbau wichtigsten SIP Header-Felder und deren Parameter. Auf eine Darstellung aller möglichen Header-Felder wird aufgrund des großen Funktionsumfangs des SIP und dem beschränkten Umfang dieser Arbeit verzichtet.

Eine detaillierte Darstellung von SIP-Nachrichten entsprechend der in Abschnitt 3.2.4.3 beschriebenen Signalisierung findet sich in Anhang C (Abbildung 14).

3.2.4.3 Signalisierungsablauf

Der Einsatz der wichtigsten im vorhergehenden Abschnitt aufgeführten SIP-Nachrichten wird nun anhand von beispielhaften Abläufen einer SIP-Kommuni-kation dargestellt. Ein einfacher Verbindungsaufbau zwischen zwei SIP-Endgeräten beginnt mit dem Request INVITE des initiierenden Teilnehmers an den Zielteilnehmer. Die Nachricht enthält im Message Body die Beschreibung der aufzubauenden RTP-Session nach dem SDP, anhand derer das Zielterminal zunächst überprüft ob es die geforderten Anforderungen (z.B. bezüglich Sprachkodierung) erfüllt. Ist diese Überprüfung erfolgreich, zeigt das Zielterminal den eingehenden Ruf durch Klingeln an und bestätigt dies dem anrufenden Terminal mit der Response Nachricht 180 Ringing. Nimmt der angerufene Teilnehmer die Verbindung an, wird dies mit der Response Nachricht 200 OK angezeigt und vom initiierenden Terminal wiederum mit ACK (ACKnowledgment) bestätigt. Mit dieser Nachricht ist der Verbindungsaufbau beendet und die eigentliche Sprach- und/oder Videokommunikation über den bidirektionalen RTP-Kanal kann beginnen. Das Ende der Kommunikation kann von jedem der Teilnehmer mithilfe der Nachricht BYE angestoßen werden. Wird diese mit der Nachricht 200 OK bestätigt, wird auch die RTP-Session beendet [BADA04, S. 250].

Im folgenden Beispiel wird nun der Verlauf einer Anrufsignalisierung bei Verwendung von Proxy-, Redirect- und Location-Servern gezeigt (Abbildung 5 zeigt grafisch den Verlauf der Anrufsignalisierung). Alice möchte mit der SIP-Adresse Alice@domain1.de eine Verbindung mit Bob (Bob@domain2.de) aufbauen.

Alice sendet zunächst den Request INVITE an den Proxy Server ihrer Domain. Dieser antwortet mit 100 Trying und leitet den Request an die Zieldomain (domain2.de) weiter. In der Zieldomain nimmt der Redirect Server den Request entgegen und muss zunächst Bob lokalisieren. Bob hat sich zuvor beim Registrar der Domain domain2.de abgemeldet und ihm mitgeteilt, das er sich in der Domain domain3.de aufhält. Entsprechend teilt der Redirect Server dies dem Proxy Server der Domain domain2.de durch die Nachricht 302 Moved Temporarily Contact: Bob@domain3.de mit. Als nächsten Schritt sendet der Proxy Server domain2.de den INVITE Request an die Domain domain3.de. Der Proxy Server der Domain domain3.de nimmt den Request entgegen und leitet diesen, nachdem er mithilfe des Location Servers die IP-Adresse ermittelt hat, schließlich an Bob weiter. Falls dieser in der Lage ist, die Verbindung entgegenzunehmen, sendet er die Response Nachricht 180 Ringing an Alice. Wie im ersten Beispiel wird das Annehmen der Verbindung durch die Response Nachricht 200 OK angezeigt und durch ACK bestätigt. Auch diese Nachrichten werden wiederum über die Proxy Server der Domains domain1.de bzw. domain3.de geroutet. Damit ist der Aufbau des RTP-Kanals abgeschlossen und die Kommunikation über eine direkte Ende-zu-Ende-Verbindung, also ohne Beteiligung der Proxy Server, kann beginnen. Die Verbindung wird durch Alice mithilfe des BYE Requests und Bobs Response Nachricht 200 OK beendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 : SIP-Verlauf mit Proxy-, Redirect- und Location-Server

(in Anlehnung an [BADA04, S. 269] )

Eine detaillierte Darstellung, der während der Signalisierung zwischen Alice und ihrem SIP Proxy ausgetauschten SIP-Nachrichten, zeigt Abbildung 14 (Anhang C).

3.2.5 Gateway-Protokolle

Die Anbindung von IP-basierten Kommunikationssystemen an bestehende Telefonnetze wird mit Media Gateways und Media Gateway Controllern realisiert. Für die Kommunikation der Gateways untereinander wurden zwei Protokolle entwickelt. Zum einen das Media Gateway Control Protocol (MGCP) von der IETF und zum anderen das neuere Megaco (Media Gateway Control), das von der International Telecommunications Union, Telecommunication Standardization Sector (ITU-T) gemein-sam mit der IETF entwickelt wurde [BADA04, S. 287-289].

3.3 Weitere Standards

In diesem Abschnitt werden einige Standards und Protokolle dargestellt, welche die Signalisierungs- und Kommunikationsfunktionalitäten der IPbRTK unterstützen und erweitern.

3.3.1 Audio- und Videocodecs

Tabelle 3 : Audiocodecs im Vergleich

(in Anlehnung an [DEVL00, S. 20] )

Abbildung in dieser Leseprobe nicht enthalten

Codecs (Abkürzung für coder/decoder) wandeln analoge Sprach- und Videosignale in digitale Signale um (codieren) bzw. umgekehrt (decodieren). In der Regel werden die Daten zusammen mit der Codierung auch komprimiert, um bei der Übertragung weniger Bandbreite zu benötigen, was aber auch zu Qualitätsverlusten führt. Ein Codec sollte also zum einen möglichst wenig Bandbreite benötigen und zum anderen trotzdem noch die Erwartungen der Benutzer an Sprach- und Bildqualität erfüllen. Weiterhin ist zu beachten, dass ein Endgerät nur direkt mit einem anderen Endgerät kommunizieren kann, mit dem es sich auf einen gemeinsamen, von beiden unterstützten Codec einigen kann. Ist dies nicht der Fall, muss das Signal durch einen Mittler (z.B. Gateway) in einen anderen Codec, den auch der empfangende Teilnehmer interpretieren kann, umgesetzt werden [NÖLL03, S. 33].

Tabelle 3 gibt einen Überblick über verschiedene Audiocodecs hinsichtlich benötigter Bandbreite und erreichbarer Qualität ohne Übermittlungsverluste (Eigenqualität bewertet mithilfe des E-Modells ­– siehe 3.5).

[...]

Details

Seiten
125
Jahr
2006
ISBN (eBook)
9783638847254
ISBN (Buch)
9783638845748
Dateigröße
1.8 MB
Sprache
Deutsch
Katalognummer
v81459
Institution / Hochschule
Bayerische Julius-Maximilians-Universität Würzburg – Lehrstuhl für Betriebswirtschaftslehre und Wirtschaftsinformatik
Note
1,3
Schlagworte
Technik Sicherheit Nutzen IP-basierter Real-Time-Kommunikation

Autor

Teilen

Zurück

Titel: Technik, Sicherheit und Nutzen IP-basierter Real-Time-Kommunikation