CoSIP Eine kooperative SIP-Infrastruktur für hochverfügbare VoIP-Dienste

Transkript

1 Universität Tübingen Rechnernetze und Internet Prof. Dr. Georg Carle CoSIP Eine kooperative SIP-Infrastruktur für hochverfügbare VoIP-Dienste Diplomarbeit Lehrstuhl für Rechnernetze und Internet Wilhelm-Schickard-Institut für Informatik Fakultät für Informations- und Kognitionswissenschaften Universität Tübingen von cand. inform. Holger Kinkelin Betreuer: Prof. Dr.-Ing. Georg Carle Dipl.-Inform. Ali Fessi Tag der Anmeldung: 14. November 2006 Tag der Abgabe: 13. Mai 2007

2

3 Ich erkläre hiermit, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Eningen, den 14. Mai 2007

4

5 Kurzfassung: Die Zuverlässigkeit und Verfügbarkeit von VoIP-Telefonanschlüssen (Voice over IP) ist geringer als die Zuverlässigkeit der nahezu hundertprozentig verfügbaren Festnetzanschlüsse. Daher können VoIP-Telefonanschlüsse noch nicht als vollwertige Telefonanschlüsse angesehen werden und diese ersetzen. Das heute gängigste und von den VoIP-Anbietern am häufigsten eingesetzte Signalisierungsprotokoll ist SIP (Session Initiation Protocol). SIP basiert auf einer aus verschiedenen Servern bestehenden Infrastruktur, die maßgeblich für die Zuverlässigkeit des VoIP-Diensts ist. Serverausfälle bzw. Probleme in der Infrastruktur wirken sich unweigerlich auf die Erreichbarkeit und Funktionstüchtigkeit der VoIP-Anschlüsse aus, da so Signalisierungen nicht mehr durchgeführt werden können. Die hier vorgestellt CoSIP-Infrastruktur kombiniert die herkömmliche, serverbasierte SIP- Signalisierung mit einer Signalisierungsmethode, die auf einem P2P-Netzwerk (Peer-to- Peer) beruht. CoSIP kann durch die P2P-basierte Signalisierungsmethode Ausfälle in der SIP-Infrastruktur überbrücken und den VoIP-Betrieb somit aufrechterhalten. CoSIP vereint die hohe Performance und Sicherheit einer serverbasierten SIP-Infrastruktur mit der hohen Zuverlässigkeit und Widerstandsfähigkeit gegen Ausfälle und Angriffe eines P2P- Netzwerks. CoSIP ist vollständig kompatibel zu der bestehenden SIP-Infrastruktur. Jeder beliebige, SIP-basierte VoIP-Client kann CoSIP verwenden, in dem er den in dieser Arbeit entworfenen und implementierten CoSIP Proxy als SIP Outbound Proxy verwendet. Im Rahmen dieser Arbeit wurde eine Publikation mit dem Titel A Cooperative SIP Infrastructure for Highly Reliable Telecommunication Services verfasst, bei der ACM Konferenz Principles, Systems and Applications of IP Telecommunications (IPTComm), New York, 2007 eingereicht und zur Veröffentlichung angenommen.

6

7 Inhaltsverzeichnis 1 Einleitung Zielsetzung der Arbeit Gliederung der Arbeit Grundlagen Einführung in die Internettelefonie Das Session Initiation Protocol Überblick Begriffe SIP URI Contact URI User Agent SIP-Server Aufgaben und Funktionsweise von SIP SIP-Nachrichten SIP-Methoden (Anfragen) SIP-Response Codes (Antworten) SIP-Header Peer-to-Peer Netzwerke Das Peer-to-Peer-Paradigma Verteilte Hashtabellen Einführung Routing in der DHT Verwaltung der DHT Die API einer DHT P2P-SIP Funktionsweise

8 ii Inhaltsverzeichnis 3 Analyse Zuverlässigkeit und Sicherheit von SIP Sicherheit von P2P Netzwerken Zuverlässigkeit und Sicherheit von P2P-SIP Angriffe auf die Konnektivität Angriffe auf die Netzstruktur Angriffe auf Daten Sonstige Angriffe Design Die CoSIP-Ansatz Allgemeine Designentscheidungen Auswahl der DHT Implementierung als SIP-Proxy Der CoSIP Proxy als Super Node Das CoSIP Schichtenmodell Kompatibilität von SIP und CoSIP Auswahl der Programmiersprache Zusammenfassung Bearbeitung von SIP-Anfragen Registrierung eines UA über den CoSIP Proxy Retransmissionen und zyklische Re-Registrierung Signalisierung eines UAS über den CoSIP Proxy Änderungen an SIP-Nachrichten Unterstützung mehrerer UA und parallele Signalisierung Session State Machines Übersichten REGISTER Session State Machine INVITE Session State Machine Betriebsarten Details der REGISTER Session State Machine Initialisierung und Zustand IDLE Zustand PENDING_SRV Zustand PENDING_DHT Zustand REGISTERED

9 Inhaltsverzeichnis iii Details der INVITE Session State Machine Initialisierung und Zustand IDLE Zustand PENDING_SRV_DHT Zustand PENDING_SRV_UAS Zustand PENDING_DHT Zustand PENDING_SRV Zustand ANY Ansätze zur Entlastung der SIP-Server Ansätze zur Verbesserung der Recovery nach Serverausfällen Speicherung der Contact URI in Bamboo Implementierung des Prototypen Übersicht Events und Event_Queue CoSIP_Server Transport-Dienst DHT Registrator und DHT Resolver Timer UAC-Objekte und UAC_Repository Sessions und Session_Repository SIP-Parser Klassenstruktur CoSIP Events Event-Typen CoSIP_Server Transportschicht DHT-Kommunikation CoSIP Timer UAC-Objekte und UAC_Repository CoSIP Sessions und Session Repository SIP-Parser

10 iv Inhaltsverzeichnis 6 Evaluation Erwartete Auswirkungen auf Zuverlässigkeit und Sicherheit Proof of Concept Testumgebung CoSIP Registrierung Signalisierung über CoSIP Tests auf Planet Lab Testziele PlanetLab Testsuite Versuchsbeschreibung Bewertung der Messwerte bei vollständig verfügbarem SIP-Server Bewertungen der Messwerte bei Ausfall des SIP-Servers Bewertung der Messwerte im DHT-Only Modus Related Work 67 8 Zusammenfassung und Ausblick 69 A Installation und Konfiguration der CoSIP-Infrastruktur 71 A.1 CoSIP Proxy A.1.1 Installation A.1.2 Konfiguration A Adressen von CoSIP Proxy, SIP-Server und DHT-Gateway 71 A Betriebsarten A Timeouts for CoSIP Timer und Daten in Bamboo A.1.3 Start A.2 Bamboo DHT A.2.1 Kompillierung A.2.2 Konfiguration A.2.3 Start A.2.4 Bamboo auf PlanetLab A.3 SER - SIP Express Router A.3.1 Installation A.3.2 Grundlegende Konfiguration A.3.3 Start

11 Inhaltsverzeichnis v B PlanetLab 77 B.1 Grundlagen B.2 Eigenschaften Literatur 79

12

13 Abbildungsverzeichnis 2.1 SIP-Trapezoid Aufbau einer Verbindung mittels INVITE Abbau einer Sitzung mittels BYE Einfügen eines Knotens in die DHT Speicherung eines Datums in der DHT CoSIP Registrierung eines UA CoSIP Signalisierung bei Ausfall des SIP-Servers Übersicht CoSIP Proxy Supernode-Eigenschaft von CoSIP Proxy und Bamboo-Gateways CoSIP Schichtenmodell Anderungen an SIP-Nachrichten durch den CoSIP Proxy REGISTER Session State Machine INVITE Session State Machine Erweiterte INVITE Session State Machine REGISTER State Machine: Übergänge im Zustand IDLE REGISTER State Machine: Übergänge im Zustand PENDING_SRV REGISTER State Machine: Übergänge im Zustand PENDING_DHT REGISTER State Machine: Übergänge im Zustand REGISTERED INVITE State Machine: Übergänge im Zustand IDLE INVITE State Machine: Übergänge im Zustand PENDING_SRV_DHT (1/2) INVITE State Machine: Übergänge im Zustand PENDING_SRV_DHT (2/2) INVITE State Machine: Übergänge im Zustand PENDING_SRV_UAS (1/2) INVITE State Machine: Übergänge im Zustand PENDING_SRV_UAS (2/2) INVITE State Machine: Übergänge im Zustand PENDING_DHT INVITE State Machine: Übergänge im Zustand PENDING_SRV INVITE State Machine: Übergänge im Zustand ANY Vereinfachte Übersicht der CoSIP Proxy-Komponenten

14 viii Abbildungsverzeichnis 5.2 Klassendiagramm: CoSIP Events Klassendiagramm: CoSIP_Server Klassendiagramm: Transportschicht Klassendiagramm: DHT-Kommunikation Klassendiagramm: CoSIP Timer Klassendiagramm: UAC und UAC_Repository Klassendiagramm: CoSIP Sessions Klassendiagramm: Session_Repository Klassendiagramm SIP Message und SIP Header Lokale Testumgebung CoSIP Registrierung bei SIP-Server und in der DHT CoSIP Registrierung bei Server-Ausfall CoSIP Signalisierung über den Server CoSIP Invite mit direkter Signalisierung Testumgebung auf PlanetLab Antwortzeit des Servers auf eine INVITE-Anfrage Antwortzeit des UAS auf eine INVITE-Anfrage über Server Antwortzeit des UAS auf eine INVITE-Anfrage vor und nach Serverausfall Logarithmisches Wachstum der DHT-Antwortzeit A.1 Konfigurationsdatei CoSIP Proxy (Beispiel) A.2 Bamboo-Konfigurationsdatei (Beispiel) A.3 SER-Konfigurationsdatei (Beispiel)

15 1. Einleitung Der Siegeszug breitbandiger Internetanschlüsse bei Privatkunden in Deutschland hat über die letzten Jahre hinweg den Weg für die Einführung einer neuen Telefontechnologie, der so genannten Internettelefonie, geebnet. Die Internettelefonie, oft als Voice over IP (VoIP) oder IP-Telefonie bezeichnet, ist eine Technologie, bei der Informationen zur Steuerung von Telefongesprächen und Sprache in digitalisierter Form über bestehende Computernetzwerke, insbesondere über das öffentliche Internet, übertragen werden. VoIP benutzt keine der von der klassischen Telefonie über das Festnetz (Public Switched Telephone Network, PSTN) benötigten Infrastrukturkomponenten, wie z.b. Telefonnetz oder Vermittlungsstellen. Durch den Wegfall dieser teuren Komponenten ist der Betrieb eines VoIP-Telefonnetzes für den Betreiber günstiger als der Betrieb eines herkömmlichen Telefonnetzwerks. Die erzielte Kostenersparnis wird von den VoIP-Anbietern zum Teil an den Endkunden weitergegeben. Das Telefonieren über das Internet mit VoIP ist aus diesem Grund günstig und daher sehr beliebt. Durch zusätzlich günstig angebotene, oft durch den Betreiber subventionierte Hardware, wie z.b. VoIP-Telefone oder VoIP-Telefonanlagen für den Hausgebrauch, ist es auch für technisch unerfahrene Kunden ein Leichtes die neue Technologie zu nutzen und so in den Genuss des Kostenvorteils, der durch VoIP entsteht, zu kommen. Das hohe Interesse an dieser Technologie bei den Kunden lässt sich indirekt anhand der hohen Kündigungszahlen bei allen deutschen Festnetzanbietern ablesen. Allein bei der Deutschen Telekom kündigen lt. den Angaben eines Internetportals zum Thema VoIP [VoIP] gegenwärtig etwa Kunden monatlich. Es ist anzunehmen, dass ein nicht zu vernachlässigender Teil dieser Kunden zu VoIP-Anbietern wechselt. Nicht nur im privaten, sondern vor allem auch im beruflichen Umfeld wird VoIP heute verstärkt eingesetzt. Firmen rüsten ihre konventionelle Telefoninfrastruktur auf VoIP-fähige Geräte um, damit sie ebenfalls von niedrigeren Gesprächskosten und von der bei VoIP zusätzlich vorhandenen hohen Flexibilität und einfachen Konfigurierbarkeit profitieren können. Das Telefonieren über VoIP bietet aber nicht nur Vorteile, sondern auch etliche Nachteile. Neben der, verglichen zum Festnetz, meist schlechteren Sprachqualität ist vor allem die Zuverlässigkeit und Verfügbarkeit eines auf VoIP basierenden Telefonanschlusses geringer als die eines Festnetzanschlusses.

16 2 1. Einleitung Die Sprachqualität wurde und wird durch neue und immer besser werdende Codecs optimiert. So existieren heute Verfahren, welche Sprachdaten nahezu in HiFi-Qualität übertragen können. Die Verbesserung der Zuverlässigkeit von VoIP wird aber trotz steigender Benutzerzahlen vergleichsweise wenig beachtet. Daher ist die Zuverlässigkeit von VoIP- Anschlüssen noch weit von der nahezu hundertprozentigen Zuverlässigkeit der Festnetzanschlüsse entfernt. Somit ist es nicht verwunderlich, dass VoIP-Telefonanschlüsse von Kunden oftmals nicht als vollwertige Telefonanschlüsse angesehen werden. Daher sind neben VoIP-Telefonanschlüssen häufig herkömmliche Festnetzanschlüsse als Backup vorhanden, um diesen Mangel zu beheben. Vor allem im beruflichen Umfeld werden daher meist VoIP-Telefonanlagen eingesetzt, die bei einem VoIP-Ausfall versuchen, eine Verbindung über den Festnetzanschluss aufzubauen. VoIP wird somit oft nur zur Reduzierung der Gesprächskosten eingesetzt, der Festnetzanschluss bleibt für den Fall eines VoIP-Ausfalls vorhanden. Die Zuverlässigkeit ist einer der wichtigsten Punkte, an dem sich ein Kommunikationsdienst messen lassen muss. Abgesehen davon, dass der Ausfall des Telefonanschlusses unangenehm ist, können daraus vor allem im beruflichen Umfeld, zum Beispiel durch verärgerte Kunden, nicht getätigte Geschäfte oder Ähnliches wirtschaftliche Nachteile entstehen. Zudem können im beruflichen, wie auch im privaten Einsatz des Telefonanschlusses bei Notfällen lebensgefährliche Situationen entstehen, falls der Telefonanschluss ausfällt und somit keine Hilfe angefordert werden kann. Die Möglichkeit eines Ausfalls VoIP-basierter Telefonie ist nicht nur ein theoretisches Schreckgespenst, sondern tritt überraschend oft auch in der Realität auf. So finden sich fast wöchentlich Meldungen auf verschiedenen Internetportalen, die Störungen und Ausfälle innerhalb der für die Internettelefonie benötigten Infrastruktur bei beliebigen VoIP- Anbietern in Deutschland beschreiben. Exemplarisch sei die in der Presse [Heis] beschriebene, tagelange Störung bei einem der größten deutschen VoIP-Anbieter genannt. Diese Störung führte schließlich zu einem kompletten Ausfall vieler VoIP-Telefonanschlüsse über einen Zeitraum von einigen Stunden. Während dieser Zeitspanne konnten keine Anrufe getätigt oder empfangen werden. Dieser Vorfall lieferte die Inspiration zu der vorliegenden Arbeit. Die VoIP-Telefonie ist aus den aufgeführten und sicherlich weiteren Gründen noch weit von einem Entwicklungsstadium entfernt, an dem VoIP die herkömmliche Telefonie über Festnetzanschlüsse komplett ersetzen könnte. 1.1 Zielsetzung der Arbeit Die Zielsetzung dieser Arbeit ist es, eine Möglichkeit zu finden, wie die Zuverlässigkeit der auf dem Session Initiation Protocol (SIP) basierenden VoIP-Telefonie mit vergleichsweise einfachen Mitteln gesteigert werden kann. Als Grundlage für das Projekt soll eine auf den Knoten eines Peer-to-Peer-Netzwerks (P2P) verteilte Hashtabelle (Distributed Hashtable, DHT) dienen. Durch die DHT kann eine zweite Signalisierungsmethode realisiert werden, die von der SIP-Infrastruktur unabhängig ist. Die DHT-basierte Signalisierung ist daher auch noch dann funktionsfähig, wenn die serverbasierte Signalisierung ausgefallen ist und kann somit die Funktionstüchtigkeit der SIP-Signalisierung und somit der VoIP-Telefonie aufrechterhalten. Der entwickelte Ansatz von Cooperative SIP (CoSIP) soll durch eine prototypische Implementierung realisiert werden. Ein wichtiges Kriterium für die Implementierung des CoSIP Prototypen ist seine Kompatibilität zu der bestehenden SIP-Infrastruktur und seine einfache Benutzbarkeit und eine flexible Handhabung. Mit Hilfe des CoSIP Prototypen soll

17 1.2. Gliederung der Arbeit 3 dann die Funktionstüchtigkeit des CoSIP-Ansatzes bewiesen werden (Proof of Concept) und die Leistungsfähigkeit des Konzepts durch Tests auf PlanetLab bewertet werden. Ein wichtiges Kriterium für die Implementierung des CoSIP Prototypen ist seine Kompatibilität zu der bestehenden SIP-Infrastruktur und seine einfache Benutzbarkeit durch herkömmliche SIP UA und eine flexible Handhabung. 1.2 Gliederung der Arbeit In Kapitel 2 werden die benötigten Grundlagen für das Verständnis der Problemstellung und deren Lösung besprochen und die in den folgenden Kapiteln verwendeten Begriffe eingeführt. Der Fokus liegt auf dem Session Initiation Protocol (SIP) und auf Peer-to-Peer Netzwerken (P2P) nebst einer knappen Einführung in P2P-SIP. In dem anschließenden Kapitel 3 werden die Eigenschaften und Probleme des Session Initiation Protocol analysiert. Ferner werden die Eigenschaften von P2P- und P2P-SIP- Netzwerken erläutert. Die Schritte zur Entwicklung des CoSIP Proxy Prototypen, relevante Designentscheidungen, die Funktionsweise des CoSIP Proxy und das CoSIP Protokoll werden in Kapitel 4 beschrieben. In Kapitel 5 werden die einzelnen Komponenten des CoSIP Proxy Prototypen beschrieben und deren Implementierung anhand von Klassendiagrammen erläutert. Anschließend wird die Funktionstüchtigkeit der Implementierung in Kapitel 6 gezeigt und die Leistungsfähigkeit und Sicherheit des CoSIP Systems erörtert. Ferner werden die auf PlanetLab durchgeführten Tests beschrieben und ausgewertet. Den Abschluss dieser Arbeit bildet ein Überblick über ähnliche Arbeiten in Kapitel 7 und eine Zusammenfassung in Kapitel 8, in welchem die wichtigsten Merkmale der CoSIP- Infrastruktur wiederholt und noch offene Fragestellungen bzw. Punkte, durch die CoSIP erweitert werden kann, angesprochen. In Anhang A finden sich einige Hinweise zur Installation und Konfiguration des CoSIP Proxy Prototypen. Zudem wird kurz auf die Installation der als Grundlage verwendeten Softwarekomponenten eingegangen. Grundlagen und Eigenschaften von PlanetLab werden in Anhang B erläutert.

18 4 1. Einleitung

19 2. Grundlagen 2.1 Einführung in die Internettelefonie Bei der Internettelefonie werden digitalisierte Sprach- und Steuerungsdaten eines Telefongesprächs über ein IP-basiertes Netzwerk übertragen. Zum Aufbau und zum Beenden von Verbindungen dienen Signalisierungsprotokolle. Ihre Aufgabe ist es, die aktuelle IP-Adresse des Endgeräts eines gerufenen Gesprächspartners vom VoIP-Anbieter zu erfragen, damit dieser Mittels der IP-Adresse des Endgeräts kontaktieren werden kann. Anstatt dass die Server des VoIP-Anbieters dem rufenden Endgerät eine Auskunft über die IP-Adresse des gerufenen Endgeräts erteilen, ist es ebenfalls möglich, dass der Wunsch zum Verbindungsaufbau vom Anbieter an das gerufene Endgerät weitergeleitet wird. Statt einer festen Rufnummer, wie sie bei herkömmlichen Festnetztelefonanschlüssen verwendet werden, werden Internettelefonanschlüssen symbolische Namen zugewiesen. Diese werden auf die aktuelle IP-Adresse, die dem entsprechenden Endgerät zugeteilt wurde, abgebildet. Diese Abbildung erfolgt über einen serverbasierten Lokationsdienst, den der VoIP-Anbieter zur Verfügung stellen muss. Die Abbildung des symbolischen Namens auf eine IP-Adresse ist dem dynamischen Domain Name System, z.b. [Dynd], sehr ähnlich. Damit die Abbildung von symbolischem Benutzernamen auf IP-Adressen erfolgen kann, muss sich das Endgerät eines Benutzers zuvor beim VoIP-Dienst registrieren; d.h. seine gegenwärtige IP-Adresse unter einem symbolischen Namen beim Anbieter hinterlegen. 2.2 Das Session Initiation Protocol In diesem Abschnitt werden die Grundlagen des Session Initiation Protocols (SIP) erläutert. Weiterführende Details können in der Literatur [John03] nachgelesen werden. Nach dem im Anschluss folgenden Überblick, werden einige in der SIP-Terminologie gebräuchlichen Begriffe eingeführt und die Funktionsweise von SIP erklärt Überblick SIP ist ein Signalisierungsprotokoll. Diese dienen zur Rufsteuerung bzw. zum Sitzungsaufbau zweier oder mehrerer Kommunikationspartner. SIP wurde von der IETF entwickelt und wird in RFC 3261 [RoSo02] (Juni 2002) bzw. dem veralteten RFC 2543 (März 1999) beschrieben. Für RFC 3261 wurden seit 2002 eine Reihe von Aktualisierungen und Erweiterungen publiziert.

20 6 2. Grundlagen SIP wird heute von kommerziellen Anbietern sehr häufig eingesetzt. Es kann daher als der de facto Standart für die Signalisierung im VoIP-Kontext gelten. Ein weiteres, mittlerweile weniger gängiges Signalisierungsprotokoll, ist das von der ITU-T entwickelte H.323. Die Anwendungsgebiete von SIP sind nicht nur auf die Internettelefonie beschränkt. Da SIP ein offenes Protokoll ist, existieren Erweiterungen für beliebige andere Szenarien. Unter anderem wird SIP bei Online-Spielen, bei Instant Messengern, der Videotelefonie oder allgemein für die Signalisierung zum Austausch von beliebigen Multimedia-Strömen verwendet SIP ist im ISO-OSI Referenzmodell auf der Anwendungsschicht (Schicht 7) angesiedelt und kann verschiedene Transportschichtprotokolle (Schicht 4) benutzen. Das für SIP gebräuchlichste Transportschicht-Protokoll ist UDP (User Datagram Protocol). Verwendbar sind aber auch TCP (Transmission Control Protocol), TLS (Transport Layer Security) und SCTP (Stream Control Transmission Protocol). Die Standardports sind 5060 für UDP, TCP und SCTP bzw für TLS. SIP ist ähnlich wie das Hyptertext Transfer Protocol (HTTP) ein textbasiertes Protokoll und ist daher vom Menschen leicht lesbar Begriffe Die in der SIP-Terminologie häufig verwendeten Begriffe werden in diesem Abschnitt eingeführt und erklärt SIP URI Jedem SIP-Teilnehmer wird von Seiten des SIP-Anbieters eine weltweit eindeutige SIP URI (User Request Identifier) zugeordnet. Die SIP URI ist ähnlich aufgebaut wie eine - Adresse. Sie setzt sich aus dem Schlüsselwort sip, einem Doppelpunkt, dem innerhalb der SIP-Domäne einzigartigen Benutzernamen, dem und dem Namen der SIP- Domäne oder deren IP-Adresse zusammen. Z.B.: sip:vorname.nachname@sipdomain.com Die SIP URI stellt einen symbolischen Namen dar, der vom SIP-Dienst auf die Contact URI des entsprechenden Endgeräts abgebildet wird Contact URI Die aktuell einem SIP User Agent zugewiesene IP-Adresse und Port-Nummer wird als dessen Contact URI bezeichnet User Agent Ein SIP User Agent (UA) ist eine Software, die es einem Anwender erlaubt SIP zu nutzen. Im Kontext der Internettelefonie bedeutet dies, dass ein Benutzer mittels des UA Anrufe über SIP tätigen, annehmen, abweisen und beenden kann. Ein UA kann die Rolle eines User Agent Client (UAC) bzw. die eines User Agent Server (UAS) in unterschiedlichen Situationen annehmen. Im Falle, dass ein UA eine Verbindung zu einem anderen UA aufbaut, wird der die Verbindung aufbauende UA als UAC bezeichnet. Der gerufene UA wird als UAS bezeichnet. SIP UA können Softphones sein, welche auf PC installiert werden. Beispiele hierfür sind kphone [Kpho] für Linux Betriebssysteme oder x-lite [X-Li] für Microsoft Windows Betriebssysteme. UA können aber auch auf speziellen SIP-Telefonen bzw. Smartphones mit Internetverbindung über LAN oder WLAN installiert sein. Zusätzlich existiert spezielle Hardware mit darauf installierten UA. Mit solchen als VoIP-Adapter bzw. VoIP-Telefonanlage bezeichneten Geräten, können herkömmliche Telefone an VoIP-Anschlüssen betrieben werden.

21 2.2. Das Session Initiation Protocol SIP-Server SIP-Server erfüllen unterschiedliche Aufgaben bzw. nehmen in verschiedenen Situationen unterschiedliche Rollen ein. Unter anderem wird zwischen den folgenden Server-Typen unterschieden: Registrierungsserver (Registrar): Wird ein UA gestartet, meldet sich dieser zunächst beim Registrierungsserver des VoIP-Anbieters an. Im Kontext von SIP spricht man hierbei von der Registrierung eines UA. Bei der Registrierung wird die Contact URI des UA mit der SIP URI als Schlüssel in die Datenbank des Lokationsdienstes gespeichert. Ein UA kann ab diesem Zeitpunkt weltweit über seine SIP URI erreicht werden. Location Server: Eine Datenbank, die die Abbildung von SIP URI zur Contact URI speichert. Die gespeicherten Daten stammen vom Registrierungsprozess eines UA. Proxy Server: Die Aufgabe eines Proxy Servers ist die Weiterleitung von SIP-Nachrichten von einem UA oder einem Proxy Server an einen anderen UA. Ein Proxy Server leitet Nachrichten genau dann an einen anderen Proxy Server weiter, wenn die Nachricht an einen, durch die SIP URI bestimmten Kommunikationsendpunkt gerichtet ist, der außerhalb seiner SIP-Domäne liegt. Ist die Nachricht an einen Kommunikationsendpunkt innerhalb der Domäne der Proxy Servers gerichtet, wird die Contact URI des Endpunkts mittels des Location Servers ermittelt und die Nachricht direkt an den Endpunkt geschickt. Kommunikationsendpunkte sind in aller Regel SIP UA. Redirect Server: Redirect Server leiten SIP Anfragen, die an eine bestimmte SIP URI gesendet werden, an eine andere SIP URI um. Der Dienst kann z.b. dazu genutzt werden, Anrufe während einer Dienstreise zu einem Kollegen umzuleiten. In der Praxis werden die unterschiedlichen Dienste oft durch denselben Server angeboten. Ein populäres Beispiel für einen SIP-Server, der Proxy-, Redirect-, Location- und Registrierungsdienste anbieten kann, ist der von Iptel entwickelte SIP Express Router (SER) [Routb]. Im Folgenden wird daher die SIP-Infrastruktur auch oft der Einfachkeit halber als der SIP-Server bezeichnet Aufgaben und Funktionsweise von SIP Dieser Abschnitt verfeinert den in der Einleitung gegebenen knappen Überblick über die Funktion und Arbeitsweise des SIP-Protokolls. Zu den Aufgaben von SIP bzw. der SIP-Infrastruktur gehören: die Lokalisierung des gewünschten Kommunikationspartners (Lokationsdienst) die Kontaktierung des Kommunikationspartners und die Feststellung, ob der gewünschte Kommunikationspartner eine Sitzung aufbauen möchte der Transport des in SIP-Nachrichten enthaltenen Session Description Protocol (SDP) [HaJo98] die Veränderung bestehender Sitzungen

22 8 2. Grundlagen das Beenden von bestehenden Sitzungen Der typische Ablauf eines Sitzungsaufbaus mit Hilfe von SIP lässt sich leicht anhand des so genannten SIP-Trapezoids, siehe Abbildung 2.1, erklären: Der UAC von Alice sendet eine SIP-Anfrage, eine sog. INVITE-Anfrage, an den SIP-Proxy seiner Domäne. Der Proxy Server der Domäne A stellt fest, dass die Anfrage an einen UAS außerhalb seiner Domäne gerichtet ist. Er löst daher die IP-Adresse des SIP-Proxy Servers der Domäne B über DNS auf und sendet die Nachricht an diesen weiter. Proxy B empfängt die Nachricht und stellt fest, dass die Anfrage an einen UAS innerhalb seiner eigenen Domäne gerichtet ist und ermittelt dessen Contact URI mit Hilfe des Lokationsdienstes. Der Proxy kann so die Anfrage an die IP-Adresse und Port-Nummer von Bob s UAS weiterleiten. Bob s UAS beantwortet die Anfrage mit einer Reihe weiterer Nachrichten. Mit diesen sagt er aus, dass die Signalisierung erfolgreich war und dass er das Gespräch angenommen hat. Die Medienströme zur Sprachübermittlung werden im Folgenden zwischen Alice und Bob in aller Regel direkt ausgetauscht. Die am Verbindungsaufbau beteiligte SIP-Infrastruktur ist an der Übertragung der Sprachinformation also nicht mehr beteiligt. Der Verbindungsabbau erfolgt, wenn einer der Gesprächspartner sich entschließt das Telefonat zu beenden. Der entsprechende UA sendet dazu eine BYE-Nachricht an sein Gegenüber. Die Gegenstelle quittiert den Empfang mit einer Antwort, und die Sitzung und Medienströme werden beendet SIP-Nachrichten Nach der Vorstellung der Funktionsweise von SIP werden nun die wichtigsten SIP-Nachrichten vorgestellt, die späterer für das Verständnis des Kapitels 4.3 nötig sind SIP-Methoden (Anfragen) Die erste Zeile einer SIP-Nachricht, die sog. Start Line, enthält bei Anfragen die auszuführende SIP-Methode. In den folgenden Abschnitten werden einige in dieser Arbeit wichtige Methoden beschrieben. REGISTER Ein UA sendet eine REGISTER-Nachricht (Tabelle 2.1) an den SIP-Registrar, um seine gegenwärtig gültige Contact URI beim Lokationsdienst zu hinterlegen. Die Contact URI ist im Contact-Header der Nachricht zu finden. Über den Lokationsdienst kann ab diesem Zeitpunkt die SIP URI zur aktuell gültigen Contact URI aufgelöst werden. Ist die Authentifizierung des UA über HTTP Digest erforderlich, sendet der Server eine Not Authorized-Nachricht als Antwort auf die REGISTER-Nachricht. Diese Antwort enthält eine HTTP Digest Challenge für den UA. Der UA berechnet mittels einer kryptographischen Hash-Funktion eine Response und sendet diese in einer zweiten REGIS- TER-Nachricht an den Server. Entspricht die empfangene Response dem erwarteten Wert, sendet der Server eine Antwort mit dem Status Code OK. Der UA hat seine SIP URI erfolgreich registriert. Falls keine Authentifizierung seitens des SIP-Dienstes erforderlich ist, antwortet der Server direkt nach der ersten REGISTER-Nachricht mit einer OK-Nachricht.

23 2.2. Das Session Initiation Protocol 9 DNS-Server Location Server DNS SIP Proxy (Domäne A) SIP SIP Proxy (Domäne B) SIP SIP User Agent Client (Alice) SIP Media Stream (RTP) User Agent Server (Bob) Abbildung 2.1: SIP-Trapezoid REGISTER sip: SIP/2.0 From: "notebook" <sip:1000@ > To: "notebook" <sip:1000@ > Via: SIP/2.0/UDP :10000;branch=z9hG4bK626D4912 Call-ID: @ CSeq: 65 REGISTER Contact: "notebook" <sip:1000@ ;transport=udp>;q=0 Expires: 120 Content-Length: 0 Tabelle 2.1: Register-Nachricht (Beispiel) UAC UAS INVITE +SDP 100 Trying 180 Ringing 200 OK +SDP ACK Session Abbildung 2.2: Aufbau einer Verbindung mittels INVITE

24 10 2. Grundlagen INVITE SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK320C7591 CSeq: 489 INVITE To: Content-Type: application/sdp From: "notebook" Call-ID: Subject: Content-Length: 185 User-Agent: kphone/4.1.0 Contact: "notebook" v=0 o=username 0 0 IN IP s=the Funky Flow c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 ilbc/8000 Tabelle 2.2: INVITE-Nachricht mit SDP-Body (Beispiel) INVITE Die INVITE-Methode wird von einem UAC dazu verwendet eine Sitzung zu einem UAS aufzubauen. Siehe Abbildung 2.2. In aller Regel enthält eine INVITE-Nachricht (siehe Tabelle 2.2) einen SDP-Body, um die für den Aufbau der Medienströme notwendigen Parameter an den UAS zu transportieren. Enthält das INVITE keinen SDP-Body, so werden die SDP-Informationen nach erfolgreicher Signalisierung übertragen. BYE Möchte ein UA eine bestehende Verbindung zu einem anderen UA trennen, sendet er an diesen eine BYE Nachricht. Der Verbindungsabbau wird vom Gegenüber mit einer OK-Nachricht bestätigt, siehe Abbildung 2.3. UAC UAS Session BYE 200 Abbildung 2.3: Abbau einer Sitzung mittels BYE

25 2.2. Das Session Initiation Protocol 11 ACK Die Methode ACK (Acknowledge) dient zur Bestätigung finaler Antworten auf INVITE- Anfragen. Eine ACK-Nachricht wird zum Beispiel vom UAC gesendet, nachdem er vom UAS eine OK-Antwort empfangen hat (Abbildung 2.2) SIP-Response Codes (Antworten) Die Start Line von Antworten enthält unter anderem einen Status-Code. In diesem Abschnitt werden die Bedeutungen der in dieser Arbeit wichtigsten Status Codes kurz beschrieben Trying Antworten mit dem Status Code 100 werden beim Weiterleiten einer INVITE-Anfrage vom der Folgestation zurück an die sendende Station geschickt. Sie dienen dazu, die Bearbeitung bzw. Weiterleitung einer INVITE-Nachricht zu bestätigen Ringing Eine Antwort mit dem Status Code 180 wird von einem signalisierten UAS an den signalisierenden UAC zurück gesendet, um auszudrücken, dass die Signalisierung erfolgreich war. Der UAC muss nun auf die Entscheidung des signalisierten Benutzers warten, ob das Gespräch angenommen werden soll oder nicht OK SIP benutzt den Status Code 200 in zweierlei Kontexten: Bei der Signalisierung hat eine Antwort mit dem Status Code 200 die Bedeutung, dass der angerufene Teilnehmer das Gespräch angenommen hat. In diesem Fall enthält die Nachricht einen SDP-Body. Bei anderen Antworten, die im Zuge des Sitzungsauf- bzw. abbaus gesendet werden, drückt der Status Code 200 den Empfang einer Nachricht bzw. die erfolgreiche Ausführung der entsprechenden Methode aus. Im Kontext einer Registrierung drückt die Nachricht OK aus, dass die Registrierung erfolgreich verlaufen ist Not Authorized Antworten mit dem Status Code 401 werden als Antwort auf eine REGISTER-Anfrage gesendet, wenn der Server die Authentifizierung des Benutzers wünscht Not found Die gesuchte SIP URI konnte nicht vom SIP Dienst lokalisiert werden. Der entsprechende UA kann offline sein bzw. kann die entsprechende SIP URI nicht vergeben sein Timeout Der SIP-Server antwortet mit einer Nachricht Timeout, wenn die gewünschte Anfrage nicht innerhalb einer bestimmten Zeitspanne beantwortet werden kann Internal Server Error Bei der Bearbeitung der Anfrage tritt ein unbestimmter Fehler auf, der Server kann die Anfrage daher nicht korrekt bearbeiten.

26 12 2. Grundlagen SIP-Header Unterhalb der Start Line einer SIP-Nachricht, beginnt der Nachrichten-Body. Der Body ist aus verschiedenen Headern aufgebaut. In diesem Abschnitt wird die Bedeutung der wichtigsten SIP-Header kurz erklärt. Call-ID Die Call-ID dient zur Identifikation von Verbindungen zwischen zwei UA. Die Call-ID besteht aus einer mit einem kryptographisch sicheren Algorithmus generierten Zufallszahl, dem und der SIP URI des rufenden UA. Die Call-ID wird von dem UA generiert, der die erste zur Session gehörige Anfrage sendet und bleibt für die gesamte Sitzung konstant. Contact Der Contact Header gibt die Contact URI des die Nachricht sendenden UA an. Die Contact URI kann von einem UA verwendet werden, um Antworten direkt an sein Gegenüber zu versenden und so dem Umweg über die SIP-Infrastruktur zu umgehen. CSeq Die CSeq (Command Sequence) ist ein numerischer Wert, welcher einzelne Transaktionen innerhalb einer Sitzung identifiziert. Bei neuen Anfragen wird im Allgemeinen die CSeq um den Wert 1 inkrementiert. From Der From Header gibt die SIP URI des UAC an, welcher einen Dialog zwischen zwei SIP- Entitäten initiiert hat. Der im Header enthaltene Local Tag, ein kryptographisch sicherer Zufallszahlenwert, wird zusammen mit dem im To Header enthaltenen Remote Tag zur eindeutigen Identifikation der Sitzung verwendet. To DerTo Header ist das Gegenstück zumfrom Header. Er gibt die SIP URI des signalisierten UAS an. Der signalisierte UAS generiert beim Beantworten der Anfrage den Remote Tag und sendet ihn im To Header der entsprechenden Antwort zurück. Via Jede auf dem Weg einer Anfrage zum Ziel liegende Zwischenstation fügt einen neuen Via Header mit ihrem Hostnamen oder ihrer IP-Adresse über dem obersten in der Anfrage enthaltenen Via Header hinzu. Der so gesammelte Stapel von Adressen der Zwischenstationen wird beim Zurücksenden der Antwort genutzt, um die Antwort auf dem umgekehrten Weg zurück zum Absender zu befördern. 2.3 Peer-to-Peer Netzwerke Eine mögliche, von Shirky [Shir] stammende Definition des Begriffs Peer-to-Peer lautet wie folgt: P2P is a class of applications that takes advantage of resources storage, cycles, content, human presence available at the edges of the Internet. Because accessing these decentralized resources means operating in an environment of unstable connectivity and unpredictable IP addresses, P2P nodes must operate outside the DNS system and have significant or total autonomy from central servers. Im Folgenden wird diese kurze Beschreibung erweitert und die wichtigsten Eigenschaften von P2P-Netzen erklärt. Weitere Informationen sind der Literatur, z.b. Steinmetz/Wehrle [StWe05] zu entnehmen.

27 2.3. Peer-to-Peer Netzwerke Das Peer-to-Peer-Paradigma Neben dem klassischen Client/Server Paradigma existiert ein weiteres Prinzip zur Erbringung von Diensten: Durch Peer-to-Peer-Netzwerke (P2P) können Dienste durch die Kooperation dezentraler, gleichberechtigter und selbst organisierter Endsysteme realisiert werden. Im Gegensatz zu Client/Server Systemen, bei denen eine feste Rollenverteilung existiert, kann ein Peer in einem P2P-Netzwerk den Dienst in Anspruch nehmen, erbringt aber im Gegenzug einen Teil des Dienstes für andere Peers. Bei Client/Server Systemen ist der Client immer Dienstnehmer und der Server Dienstanbieter. Ein weiterer Unterschied zu Client/Server Systemen und einer der wichtigsten Vorteile von P2P-Netzen ist, dass Peers in der Regel keine dedizierten Maschinen sind, sondern herkömmliche Arbeitsplatzrechner. Ein Peer leistet neben seiner eigentlichen Aufgabe am Arbeitsplatz zusätzlich seinen Beitrag zur Realisierung des Dienstes. Somit können Dienste bereitgestellt werden, ohne dass kostenintensive Server angeschafft bzw. unterhalten werden müssten. Beispiele für auf P2P-Netzwerken basierenden Diensten sind oftmals im Bereich Filesharing anzusiedeln (Emule [epro], Overnet [Over], Kazaa [Kaza]). Es können aber auch z.b. Dienste zur Umgehung der Zensur im Internet (Freenet [Free], Publius [Publ]), Dienste für die Arbeit in Gruppen (Groove [Groo]) oder Kommunikationsdienste wie z.b. Skype [Skyp] und P2P-SIP, (Abschnitt 2.4), erbracht werden. Ein weiterer Anwendungsfall von P2P-Netzen ist der Endsystem-Multicast. Durch den Wegfall der Server und die Verteilung der benötigen Infrastruktur entsteht eine Reihe neuer Eigenschaften: Skalierbarkeit Ein einzelner Server kann niemals die Rechenleistung erbringen oder die Speicherkapazität besitzen, die ein Verbund von beliebig vielen Peers in Kooperation zur Verfügung stellen kann. Ein Verbund von Servern ist zwar ähnlich Leistungsfähig, es entstehen aber hohe Kosten durch Anschaffung und Unterhalt der Server. Die Skalierbarkeit des P2P-Paradigmas ist der des Client/Server Paradigmas in der Regel überlegen. Zuverlässigkeit Ein zentraler Server birgt das Risiko zum Single Point of Failure zu werden, da er relativ leicht angegriffen werden und somit ausfallen kann. Im Gegensatz dazu ist es schwierig einen Dienst, der durch ein P2P-Netzwerk realisiert wird, durch DoS-Angriffe stillzulegen. P2P-Netzwerke sind hochgradig dynamisch, sie müssen daher mit einer stets fluktuierenden Menge von am Netzwerk beteiligten Peers umgehen und sich selbständig laufend neu organisieren können. P2P-Knoten besitzen daher Algorithmen zur Aufrechterhaltung der Konnektivität der Knoten untereinander und zur Replizierung von Daten. Geht ein Peer offline, egal ob beabsichtigt oder durch einen Angriff oder Fehler verursacht, übernehmen andere Peers automatisch die Aufgabe des ausgefallenen Peers im Netzwerk. Daten, die auf dem Peer gespeichert waren, sind wegen der Replizierung nicht verloren, sondern können von anderen Knoten empfangen werden Verteilte Hashtabellen Virtuelle Hashtabellen ermöglichen das effiziente Auffinden von in einem P2P-Netzwerk gespeicherten Daten. Im Folgenden werden die grundlegenden Konzepte und Eigenschaften vorgestellt.

28 14 2. Grundlagen Einführung Eine Hashtabelle ist eine Datenstruktur, die den effizienten Zugriff auf große Mengen gespeicherter Datenelemente erlaubt. Das charakteristische Merkmal von Hashtabellen ist, dass ein Suchschlüssel, welcher einem gespeichertem Datum zugeordnet ist, mittels einer konsistenten Hash-Funktion zu einem Index in die Hashtabelle umgerechnet wird. Der Zugriff auf das Datenelement erfolgt über den so berechneten Index. Eine verteilte Hashtabelle (Distributed Hashtable, DHT) ist eine Hashtabelle, die über die Knoten in einem P2P Netzwerk verteilt ist. Ein Knoten wird hierzu zunächst über eine Hash-Funktion in den Indexbereich der Hashtabelle abgebildet. Meist wird hierzu z.b. die IP-Adresse des Knotens oder der öffentliche Teil eines Public-Key Schlüsselpaars verwendet. Der so berechnete Hashwert wird als die ID des Knotens oder schlicht als Knoten-ID bezeichnet. Ein Peer ist in der DHT für die Verwaltung des ihm zugeordneten Teils des Indexbereichs verantwortlich. Dieser entspricht in der Regel dem Bereich, der zwischen der ID des Knotens und der ID seines direkten Nachbarknotens liegt (Abbildung 2.4). IP = a.b.c.d H(IP) = x Schlüsselbereich 0 x 2 n -1 Knoten x zugeteilter Schlüsselbereich Abbildung 2.4: Einfügen eines Knotens in die DHT Datenelemente, die in der DHT gespeichert werden sollen, werden über eine Hashfunktion in den Hashbereich abgebildet und auf dem Knoten gespeichert, welcher den entsprechenden Hashwert verwaltet (Abbildung 2.5). Die Abbildung erfolgt in aller Regel, wie bei herkömmlichen Hashtabellen, durch das Umrechnen eines Schlüsselworts mittels einer Hashfunktion. Der so berechnete Hashwert wird oft als Ressourcen-ID oder als Schlüssel bezeichnet. Datenelement H(Schlüssel) = y Speicherung auf Knoten x Schlüsselbereich 0 x 2 n -1 Knoten x zugeteilter Schlüsselbereich Abbildung 2.5: Speicherung eines Datums in der DHT Routing in der DHT Alle Knoten die einer DHT angehören, besitzen Routingtabellen. Routingtabellen sind Abbildung von einem Wert aus dem Indexbereich auf die Adresse des Knotens, der diesen

29 2.3. Peer-to-Peer Netzwerke 15 Wert verwaltet. Ein Knoten kennt nicht alle anderen Knoten der DHT, sondern nur einen Teil davon. Typischerweise ist die Zahl der Routingeinträge in der Größenordnung von O(log(n)) anzusiedeln. Der Wert n gibt die Anzahl der Knoten in der DHT an. Das Routing zu dem Knoten, welcher den zu einem bestimmten Schlüssel gehörigen Wert speichert, funktioniert durch gezieltes Weiterleiten der Anfrage an den Knoten in der Routingtabelle, der die zur gesuchten Ressourcen-ID ähnlichste Knoten-ID besitzt. Das Verfahren wird so lange wiederholt, bis die Anfrage schließlich den Knoten erreicht hat, der den gesuchten Wert speichert. Das Routing in einer DHT ist daher in der Regel ein deterministischer Prozess. Kann ein Datum nicht gefunden werden, so ist es mit hoher Wahrscheinlichkeit tatsächlich nicht in der DHT verfügbar. Typischerweise ist mit einer Anzahl von durchschnittlich O(log(n)) Routingschritten zu rechnen. DHT mit Routingtabellen, in denen mehr als O(log(n)) Einträge vorhanden sind, bieten performanteres Routing. Der Aufwand zur Aufrechterhaltung der Aktualität der Routingtabellen steigt aber mit der Anzahl der Routingeinträge. O(log(n)) Routingeinträge mit O(log(n)) Routingsschritten sind daher als guter Kompromiss zwischen Performance des Routings und Aufwand zur Verwaltung der Routingtabellen anzusehen Verwaltung der DHT Tritt ein Knoten der DHT bei, muss dieser erst anderen Knoten bekannt gemacht werden, bzw. muss die Routingtabelle des neuen Knotens mit Einträgen gefüllt werden. Dieser Prozess wird als Bootstrapping bezeichnet. Verlässt ein Knoten die DHT ordnungsgemäß, muss dieser aus den Routingtabellen anderer Knoten ausgetragen werden und die auf dem Knoten gespeicherten Werte auf Nachbarknoten übertragen werden. Da nicht immer mit dem ordnungsgemäßen Ausscheiden eines Knotens aus der DHT zu rechnen ist, existieren Verfahren, welche die Erreichbarkeit von Knoten automatisch überprüfen und so die Routingtabellen aktuell halten. Zudem existieren Verfahren, die Daten redundant, d.h. auf mehreren Knoten, speichern Die API einer DHT Die Benutzung einer DHT ist mittels einer API (Application Programming Interface) möglich. Zum Umgang mit Daten sind die folgenden Befehle nötig: put(key, data) zur Speicherung des Werts data unter dem Schlüssel key in der DHT data = get(key), um den Wert data mittels seines Schlüssels key aus der DHT zu lesen remove(key), um den zum Schlüssel key gehörigen Wert aus der DHT zu löschen Zudem werden die Befehle join und leave für den Beitritt in das P2P-Netzwerk bzw. das Austreten aus dem Netzwerk benötigt.

30 16 2. Grundlagen 2.4 P2P-SIP Eine mögliche Definition von P2P-SIP wird von Seedorf [Seed06] geliefert: P2P-SIP: Using a peer-to-peer network as a substrate for SIP user registration and location lookup specified as an open standard. Die grundlegende Idee und Motivation von P2P-SIP ist es, den Dienst SIP ohne Server anbieten zu können oder die Verwendung von Servern auf ein Minimum zu beschränken. Jeder Peer im Netzwerk muss daher die Rolle eines SIP-Registrars und die eines SIP- Location Servers für andere Peers übernehmen können. Eine weitere Motivation für die Entwicklung von P2P-SIP ist in der verglichen zu serverbasiertem SIP höheren Widerstandsfähigkeit des P2P-Netzwerks gegenüber Angreifern und Ausfällen zu sehen. Weitere Gründe sind in der Reduktion der Unterhaltskosten der benötigten Infrastruktur, die ein (weitgehend) serverloses System bietet, zu suchen und die hohe Skalierbarkeit eines auf dem P2P-Paradigma basierenden Systems. Derzeit existieren zwei Ansätze für P2P-SIP, [SiSc04] und [BrLJ05]. Beide sind einander, bis auf wenige Unterschiede, sehr ähnlich. Eine Gegenüberstellung der Ansätze kann in der Arbeit von Seedorf [Seed06] nachgelesen werden. Zwischenzeitlich wurde eine P2P-SIP Arbeitsgruppe seitens der IETF ins Leben gerufen. Ziel der Arbeitsgruppe ist es P2P-SIP zu einem offenen Standard zu machen Funktionsweise Eine Besonderheit der beiden P2P-SIP Ansätze ist die Verwendung von SIP-Nachrichten zur DHT-Verwaltung. Die in beschriebene DHT-API wird nicht verwendet. Die Registrierung eines P2P-SIP UA ist in zwei Phasen unterteilt. In der ersten Phase, welchen als Knoten-Registrierung bezeichnet wird, wird ein Knoten (Alice) in das P2P- Netzwerk eingefügt. Hierzu berechnet Alice z.b. aus ihrer IP-Adresse eine Knoten-ID und tritt dem P2P-Netzwerk über einen Bootstrapping-Knoten bei. Dies geschieht mit dem Befehl: REGISTER(Node_ID(Alice)). In der zweiten Phase, der Benutzer-Registrierung, wird die SIP URI des Benutzers beim P2P-SIP Dienst registriert. Hierzu berechnet Alice aus der zu registrierenden SIP URI eine Ressourcen-ID und registriert ihre gegenwärtige Contact URI mit der Ressourcen-ID als Schlüssel in der DHT. Der dafür benötigte Befehl lautet REGISTER(SIP_URI(Alice)). Ein anderer P2P-SIP UA (Bob) kann nun Alice über das P2P-SIP-Netzwerk kontaktieren. Hierzu errechnet Bob aus der SIP URI von Alice die entsprechende Ressourcen-ID und ruft die entsprechenden Daten aus der DHT ab: INVITE(SIP_URI(Alice)). Mit der so empfangenen Contact URI kann Bob Alice direkt erreichen.

31 3. Analyse In diesem Kapitel werden die Eigenschaften der SIP-Infrastruktur in Hinblick auf Sicherheit und Zuverlässigkeit analysiert. Zudem wird die Sicherheit und Zuverlässigkeit von P2Pund insbesondere von P2P-SIP Netzwerken besprochen. 3.1 Zuverlässigkeit und Sicherheit von SIP Die SIP-basierte Internettelefonie ist nur dann möglich, wenn alle an der Erbringung des Dienstes beteiligten Komponenten erreichbar sind und fehlerfrei arbeiten. Zur SIP- Infrastruktur zählen z.b. die folgenden Komponenten: SIP Registrar Server SIP Proxy Server SIP Redirect Server Datenbankserver für Lokationsdienste DNS-Server Server für Authentifizierung, Autorisierung und Abrechnung (AAA) Jede dieser Komponenten kann durch Hardware-Fehler, Wartung oder Fehler seitens der Administration ausfallen. Zudem kann eine Komponente durch zu viele Anfragen überlastet werden und ausfallen. Ein Ausfall oder eine Überlastung eines Teilsystems kann das Gesamtsystem stören oder einen kompletten Ausfall verschulden. Fällt z.b. der DNS-Server, der vom SIP-Proxy der Domäne A benutzt wird aus, kann eine SIP-Nachricht nicht von diesem an den SIP-Proxy der Domäne B weiter geleitet werden, da die IP-Adresse des Proxy der Domäne B nicht über DNS aufgelöst werden kann. Die Signalisierung scheitert, weil ein einzelnes Teilsystem nicht verfügbar ist. Jede Komponente in einem solchen System kann mit einer gewissen Wahrscheinlichkeit ausfallen. Die Ausfallwahrscheinlichkeit des gesamten Systems kann dabei als mindestens so hoch angenommen werden, wie das Maximum der einzelnen Ausfallwahrscheinlichkeiten aller Teilsysteme. Existieren keine geeigneten Mechanismen, wie mit Ausfällen einzelner