Voice over IP unter Verwendung von OpenSource-Software

Transkript

1 Voice over IP unter Verwendung von OpenSource-Software Maik Schmitt Rainer Jochem Fortgeschrittenenpraktikum nach einem Thema von Prof. Dr.-Ing. Philipp Slusallek Naturwissenschaftlich-Technische Fakultät I Fachrichtung 6.2 Informatik Universität des Saarlandes, Saarbrücken, 2004 U N S A I V E R S R A V I I T A S S E N S I

2

3 Danksagung: Wir danken Prof. Dr. Philipp Slusallek für das Thema dieser Arbeit, Dipl.-Ing. Edgar Scherer für die Unterstützung, Dipl.-Inf. Georg Demme für die Unterstützung und Betreuung, Mark Spencer für Asterisk und die schnelle Hilfe bei Problemen, Jiri Kuthan und GMD Fokus für SER, Siggi Langauf, sowie dem Rechenzentrum der Universität des Saarlandes und der Firma Snom für die freundliche Leihgabe von Testgeräten

4

5 Inhaltsverzeichnis 1 Einleitung 5 2 Voice over IP Funktionsweise Audiocodecs SIP - Session Initiation Protocol Komponenten Aufbau der SIP-Nachrichten SIP-Rufablauf RTP Weitere Protokolle H IAX2 - Inter Asterisk exchange NAT und Firewalls Situation Lösungen Ziele Anbindung des LS Computergraphik SIP-Server für Studenten und Mitarbeiter Erweiterung der TK-Anlage um ENUM Verwendete Software Überblick Bayonne Vocal SIP Express Router (SER) Asterisk Erfahrungen Lehrstuhl-Server Anforderungen Umsetzung Allgemeine Konfiguration von Asterisk Einrichten der SIP-Teilnehmer Globale Parameter Benutzerspezifische Parameter

6 INHALTSVERZEICHNIS Zugehöriger Rufnummernplan Anbindung an das ISDN-Festnetz Installation Rufnummernplan mit Berechtigungsstufen Voic Sonstige Funktionen im Rufnummernplan Konferenzräume Erreichbarkeit der Teilnehmer ENUM Asterisk-Patches Verschlüsselte SIP-Passwörter Erstellen eines Benutzerinterfaces Studentenserver Anforderungen Umsetzung Konfiguration SER Asterisk DNS Webinterface ENUM public ENUM user ENUM Umsetzung mit Asterisk Konfiguration des E1-Interfaces Rufnummernplan Erweiterung von TK-Anlagen um ENUM user ENUM mit Bind Endgeräte Hardphones Cisco Cisco Snom Analog-IP - Wandler Cisco ATA Digium IAXy Softphones KPhone X-Lite Headsets Zusammenfassung Ausblick

7 INHALTSVERZEICHNIS A Verwendete Konfigurationsdateien 74 A.1 extensions.conf A.2 sip.conf A.3 Skript zum Abgleich der sip.conf mit einer MySQL-Datenbank 81 B Glossar 83 C Verantwortliche 86 C.1 Maik Schmitt C.2 Rainer Jochem

8 INHALTSVERZEICHNIS 4

9 Kapitel 1 Einleitung VoIP steht für Voice over Internet Protocol und bezeichnet das Versenden von Sprachinformation mit Hilfe von IP-Paketen durch Netzwerke. Grob gesagt also telefonieren über Datennetze, wie z.b. unternehmensinterne Netzwerke oder gar das Internet. Mit zunehmender Zahl breitbandiger Internetanschlüsse, die meist auch in Verbindung mit Pauschaltarifen verfügbar sind, gewinnt Voice over IP immer mehr an Popularität. Dies zeigt sich nicht zuletzt auch darin, dass mittlerweile die Regulierungsbehörde für Telekommunikation und Post damit beginnt, Regeln für die Vergabe von Festnetznummern an Internet-Diensteanbieter aufzustellen [1] und große TK-Diensteanbieter ihre Infrastruktur auf Internet-Übertragungstechniken umstellen wollen [2]. Einsatzzwecke für Voice over IP sind vielfältig: Sei es, um jemanden im Ausland zu günstigen Tarifen erreichen zu können, oder um mehrere Standorte eines Unternehmens über kostengünstigere Datennetze, die heutzutage in der Regel ohnehin vorhanden sind, miteinander zu verbinden. Auch bietet VoIP eine bequeme Art von Rufnummernportabilität: denn überall, wo ein Netzwerkzugang mit ausreichender Bandbreite vorhanden ist, kann man VoIP-Telefone z.b. in Form von Software auf einem Laptop oder PDA benutzen. Darüber hinaus sind auch neue Services wie die Integration von Telefoniefunktionen in den PC (CTI, Unified Messaging,...), Directory Services (Telefonbücher die z.b. auf LDAP basieren und vom Telefon aus abgerufen werden können), usw. denkbar. Ein weiterer Vorteil in der Verwendung von VoIP-Techniken besteht in der Möglichkeit, die existierende Netzwerkinfrastruktur mitzuverwenden. Hierdurch kann auch eine einfachere Ausstattung mit Telefonendgeräten erreicht werden, wobei hier in der Regel noch nicht einmal zusätzliche Netzwerkports notwendig sind, da die meisten Telefone über integrierte Switches verfügen. 5

10 KAPITEL 1. Einleitung Verwendet man offene, internationale VoIP-Standards, so besteht auch keine Herstellerabhängigkeit und man kann zwischen den verschiedensten Softund Hardphones wählen. Auch ist der administrative Aufwand, um ein eigenes VoIP-System zu betreiben, relativ gering, da die für Netzwerke üblichen Basistechnologien zum Einsatz kommen. Wenn man von VoIP redet, bedeutet dies allerdings noch lange nicht, dass man dann keinerlei Verbindung mehr zur alten Telefonwelt hat. Viele VoIP- Server bieten Möglichkeiten, mittels entsprechender Schnittstellenkarten Gespräche auch zum Analog- oder ISDN-Netz zu führen. Dabei reichen die Anschlussmöglichkeiten von einfachen Analoganschlüssen bis hin zu mehrfach- ISDN-Primärmultiplex-Anschlüssen. Verfügt man über ein solches System, das sowohl an das herkömmliche Telefonnetz angeschlossen, als auch VoIP-fähig ist, so kann man mit Diensten wie ENUM eine Art Least-Cost-Routing (LCR) für abgehende Gespräche durchführen: findet der Server einen VoIP-Eintrag für den angewählten Gesprächspartner im ENUM, so kann er den Anruf kostengünstig über VoIP weiterleiten und sonst das herkömmliche Telefonnetz benutzen. Auch kann man mit solchen Systemen eine bestehende klassische TK-Infrastruktur um VoIP- Funktionalität erweitern. Da die verwendeten Protokolle von VoIP die gleichen sind, wie sie auch für Video over IP eingesetzt werden, ist es auch leicht möglich mit der gleichen Technik Videokonferenzen durchzuführen. Für die Zukunft sind natürlich noch viele weitere Dienste über reine Telefonieanwendungen hinaus denkbar. Was kann VoIP noch nicht? Verwendet man VoIP-Komponenten (Server, Endgeräte) hinter einer Firewall und/oder NAT, so kann dies mitunter zu Problemen führen. Allerdings gibt es hierfür bereits Lösungen, wie sie im nächsten Kapitel beschrieben werden. Weiterhin benötigt VoIP eine gewisse Mindestbandbreite, die allerdings auch stark von den verwendeten Audiocodecs abhängt. Wichtig sind hier vor allem auch schnelle Verbindungen ohne hohe Latenzen. Auch sind je nach verwendetem Protokoll und Endgerät derzeit noch nicht alle aus dem Festnetz bekannten Dienstmerkmale vorhanden. Wobei diese Merkmale idr. auch nur in speziellen Anwendungsfällen benötigt werden. Ein weiterer Aspekt ist die Sicherheit von VoIP-Verbindungen. Alle internationalen VoIP-Standards haben zwar zu verwendende Verschlüsselungsverfahren spezifiziert, allerdings mangelt es an der Umsetzung durch die Hersteller der entsprechenden Endgeräte. Zum heutigen Zeitpunkt ist uns lediglich ein SIP- Telefon bekannt, das eine Verschlüsselung aller Datenströme anbietet. 6

11 Kapitel 2 Voice over IP Die Idee, Sprachdaten in digitaler Form zu übertragen, ist nicht neu (siehe ISDN): man wandelt die Sprachdaten von analog zu digital, überträgt sie und wandelt sie am Endpunkt wieder von digital nach analog zurück. Genau das macht VoIP - mit dem Unterschied, dass als Transportmedium IPbasierte Netze mit den dafür üblichen Protokollen verwendet werden: In der klassischen Telefonie kommen sogenannte Circuit-switched Networks zum Einsatz, d.h. es wird eine dedizierte Leitung für ein einzelnes Gespräch über die Dauer der Verbindung benötigt. Bei Packet-Switched Networks wie sie in IP-basierten Netzen üblich sind, werden Datenpakete durch das Netz geroutet. Hierbei handelt es sich um eine verbindungslose Kommunikation im Gegensatz zu einem Circuit-Switched Network. Eine Verbindung besteht hier nur für die Dauer des Sendens oder Empfangens eines Datenpaketes. Somit kann ein Netz mit mehreren Benutzern geteilt werden. Weiterhin kann die gleiche Leitung zur Übertragung weiterer Daten (Video, Bilder,...) verwendet werden und es können bei Wahl eines geeigneten Kompressionscodecs mehr Telefonate bei gleicher verfügbarer Bandbreite geführt werden. 2.1 Funktionsweise Hier sei der grobe Ablauf sowie die benötigten Komponenten eines VoIP- Gesprächs skizziert: 1. Die Teilnehmer sind an ihrem jeweiligen VoIP-Server mit einem VoIP- Endgerät angemeldet. Unter Verwendung eines Signalisierungsprotokolls 7

12 KAPITEL 2. Voice over IP initiiert das Endgerät den Anruf und handelt den zu verwendenden Audiocodec aus. 2. Ist die Verbindung aufgebaut, wird der ausgehandelte Codec verwendet, um die Sprachdaten zu komprimieren. (Selbstverständlich ist auch eine geeignete Vorrichtung für die Aufnahme der Sprachdaten notwendig d.h. am PC z.b. Soundkarte mit Mikrofon und Lautsprecher oder Headset) 3. Die so erzeugten Audiodaten müssen nun in ein echtzeittaugliches IP- Transportprotokoll (idr. RTP über UDP) eingebettet und versendet werden. 4. Auf der Empfängerseite geschieht das ganze nun in umgekehrter Reihenfolge: Zerlegen der RTP-Pakete, dekodieren der Sprachdaten und deren Wiedergabe. 2.2 Audiocodecs Es gibt eine Vielzahl von Codecs [3], die im VoIP-Umfeld verwendet werden, um eine möglichst geringe Bandbreite bei gleichzeitig guter Sprachqualität zu erreichen. Codec Samplerate Bandbreite Ursprung G.711 8kHz 64kbps ITU-T G.729 8kHz 8kbps ITU-T G kHz 5.6kbps - 6.3bps ITU-T G.726 8kHz 16, 24, 32, 40kbit/s ITU-T (ADPCM) ersetzt G GSM 8kHz 13kbps ETSI ilbc 8kHz 15kbps IETF-draft [4] Speex 8kHz/16kHz/32kHz 2.15kbps kbps OpenSource speex.org [5] LPC10 8kHz 2.4kbps US. Gov. Tabelle 2.1: Übersicht verbreiteter Audiocodecs Zu den am weitesten verbreiteten Audiocodecs zählen derzeit G.711, GSM und G.729. G.711 bietet die beste Sprachqualität (es handelt sich im übrigen um den gleichen Codec, wie er auch bei ISDN verwendet wird), benötigt allerdings auch viel Bandbreite. Während G.711 vor allem in breitbandigen Netzen Verwendung findet, sind im Internet häufiger GSM (der auch im Mobilfunk verwendet wird) und G.729 anzutreffen. Bis auf LPC10 bieten alle Codecs gute bis sehr gute Sprachqualität. 8

13 2.3. SIP - Session Initiation Protocol 2.3 SIP - Session Initiation Protocol SIP wurde mit Blick auf das Internet von der IETF entwickelt (RFC 3261 [6]) und orientiert sich an der Architektur gängiger Internet-Anwendungen. Dabei wurde von Beginn an auf leichte Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibilität geachtet. Benutzt werden kann es, um beliebige Sessions mit einem oder mehreren Teilnehmern zu eröffnen, zu modifizieren oder zu beenden. Dabei ist es nicht auf Internet-Telefonie beschränkt, sondern Sessions können beliebige Multimediaströme, Konferenzen, Computerspiele, usw. sein. Um jedoch ein Internet-Telefonat zu führen, braucht man mehr als nur SIP. SIP dient lediglich dazu, die Kommunikation zu ermöglichen die eigentlichen Daten für die Kommunikation müssen über andere, dafür geeignete Protokolle ausgetauscht werden. Hierzu werden das Session Description Protocol (SDP, RFC 2327 [7]) und das Realtime Transport Protocol (RTP, RFC 1889 [8]) eingesetzt. SDP dient dazu, die zwischen den Endpunkten zu verwendenden Codecs, Transportprotokolle, usw. auszuhandeln. Aufgabe von RTP ist es, den Multimedia-Datenstrom (Audio, Video, Text,...) zu transportieren d.h. die Daten zu kodieren, zu paketieren und zu versenden. SIP basiert unter anderem auf dem HTTP-Protokoll es verwendet eine ähnliche Header-Struktur und ist ebenfalls ein textbasiertes Protokoll. Zur Schreibweise der Teilnehmeradressen wird das bereits von bekannte Format (sip:user@domain) benutzt. Unterstützung findet SIP bereits in vielen Geräten diverser Hersteller und es scheint sich zum Standard-Protokoll zu entwickeln. SIP wurde auch vom 3rd Generation Partnership Project (3GPP, [9]) als Protokoll für Multimediaunterstützung im 3G-Mobilfunk (UMTS) ausgewählt [10]. Zu den Nachteilen von SIP gehört, dass es zur Übertragung der Sprachdaten auf RTP zurückgreift. Die dafür verwendeten UDP-Ports werden dynamisch vergeben, was die Verwendung von SIP in Verbindung mit Firewalls oder Network Address Translation (NAT, RFC 2663 [11]) schwierig macht, da die meisten Firewalls bzw. NAT-Router die dynamisch vergebenen Ports nicht der Signalisierungsverbindung zuordnen können. Weiterhin sind auch viele Dienstmerkmale die aus dem Festnetz bekannt sind nicht im SIP-Protokoll selbst, sondern in Erweiterungen zum SIP-Protokoll definiert, so dass diese nicht von allen Endgeräten unterstützt werden. Im Gegensatz zu H.323 unterstützt SIP ausschließlich Blockwahl. Dies bedeutet, dass die Rufnummer erst in voller Länge gewählt werden muss und erst dann der Anruf gestartet werden kann im Gegensatz zu der vom herkömmlichen Telefon bekannten Weise, dass man durch Abnehmen des Hörers schon den Anruf startet und dann erst die Rufnummer wählt. 9

14 KAPITEL 2. Voice over IP Komponenten User Agent Als User Agent (UA) werden alle SIP-fähigen Endgeräte (d.h. Softwaretelefon am PC, PDAs, SIP-Telefone, aber auch PSTN-Gateways etc.) bezeichnet. Dabei wird meist noch eine (rein logische) Aufteilung in User Agent Client (UAC) und User Agent Server (UAS) vorgenommen, wobei jedoch jeder UA immer aus einem UAC und einem UAS besteht. Erstere dienen dazu, Anfragen zu stellen und Antworten zu verarbeiten, ein UAS empfängt Anfragen und versendet Antwortnachrichten. Proxy Server Diese spielen eine zentrale Rolle in einem SIP-Netzwerk. Ihre Aufgabe ist es, das Routing der SIP-Nachrichten zum Aufbau einer SIP-Verbindung zu übernehmen. Verbindungsgesuche eines Anrufers können über mehrere Proxies bis zum Aufenthaltsort des Angerufenen geleitet werden. Es wird dabei zwischen Stateless und Stateful Proxies unterschieden. Stateless Proxies leiten empfangene Nachrichten einfach weiter. Sie sind deshalb schneller als Stateful Proxies und finden vor allem Verwendung als Loadbalancer und einfache Router. Allerdings sind sie nicht in der Lage, anspruchvolleres Routing wie z.b. Call Forking (mehrere Endgeräte können gleichzeitig angerufen werden) zu betreiben. Stateful Proxies generieren für eine Anfrage einen Zustand ( State ) und behalten diesen, bis die entsprechende Transaktion beendet ist. Dies kann im Fall einer INVITE-Nachricht relativ lang dauern (nämlich so lange, bis der Angerufene den Anruf annimmt oder abweist). Aufgrund der Tatsache, dass Stateful Proxies diese Zustände für die Dauer der Anfrage aufrecht erhalten müssen, sind an diese höhere Leistungsanforderungen gestellt. Dafür sind sie aber auch in der Lage, weitergehende Dienste anzubieten und können auch von einem Endgerät mehrfach versandte Nachrichten abfangen, da sie ja wissen, ob diese bereits empfangen wurde. Registrar Damit ein Proxy weiss, wo der betreffende Benutzer zu finden ist, muss sich sein UA an einem Registrar angemeldet haben. Dieser speichert dann den derzeitigen Aufenthaltsort (d.h. IP-Adresse, Port und Benutzername) in einer sog. location database. Auf diese kann dann der Proxy-Server des Angerufenen 10

15 2.3. SIP - Session Initiation Protocol zugreifen, um den Aufenthaltsort herauszufinden. Bei einem Registrar handelt es sich allerdings für gewöhnlich nur um eine logische Einheit wegen der engen Verzahnung von Registrar und Proxy sind diese meist in einem Gerät (Soft- oder Hardware) zusammengefasst. Redirect Server Aufgabe dieses Servers ist es, bei eingehenden Anfragen den gewünschten Empfänger in der location database nachzuschlagen. Die gefundenen Aufenthaltsorte es ist bei SIP möglich, dass man sich zur gleichen Zeit mit verschiedenen Endgeräten von verschieden Orten aus mit dem gleichen Benutzer anmelden kann werden dann dem Sender der Anfrage mit einer entsprechenden Nachricht zurückgesandt Aufbau der SIP-Nachrichten Jede Nachricht besteht aus einer ersten Zeile, die den Nachrichtentyp angibt, gefolgt vom Rest des Headers und einem Body. Es gibt dabei zwei Nachrichtentypen: Requests und Responses. Requests dienen dazu, etwas zu initiieren oder den Empfänger über irgendetwas zu benachrichtigen. Durch die Responses wird der Empfang eines Requests bestätigt und der Status der Bearbeitung mitgeteilt. SIP-Requests Einen typischen SIP-Request zeigt Abbildung 2.1. Die erste Zeile beinhaltet den Nachrichtentyp in diesem Fall ein INVITE-Request. Dieser dient dazu, eine Session zu eröffnen. VIA-Felder geben den Weg an, über den die SIP- Responses später geroutet werden sollen. From und To dienen dazu, den Sender und Empfänger der Nachricht zu spezifizieren (vgl. ). Über die Call-ID können die zum gleichen Anruf gehörenden Nachrichten identifiziert werden. Die CSeq gibt die Reihenfolge der Requests an. Mittels des Contact-Feldes gibt der Sender an, wo er die Antworten des Empfängers erwartet. Die übrigen Header sind von untergeordneter Bedeutung. 11

16 KAPITEL 2. Voice over IP H E A D E R INVITE sip:1234@ SIP/2.0 Via: SIP/2.0/UDP CSeq: 799 INVITE To: <sip:1234@ > Content-Type: application/sdp From: Bob <sip:66@ >;tag=64acea4f Call-ID: @ Subject: Important Call Content-Length: 183 User-Agent: KPhone/3.11 Contact: Bob <sip:66@ ;transport=udp> B O D Y 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 Abbildung 2.1: SIP-Request Header und Body sind durch eine Leerzeile voneinander getrennt. Der Body eines INVITE-Requests enthält u.a. die in SDP kodierte Beschreibung der vom Sender unterstützen Medientypen. In diesem Beispiel beherrscht das Endgerät z.b. die Audiocodecs PCM law, GSM und ilbc. Alle weiteren Requests sind in ähnlicher Form aufgebaut. Zu diesen zählen ACK, BYE, CANCEL und REGISTER. SIP Responses Jeder Request ausser ACK muss mit einer geeigneten Response beantwortet werden. Bis auf die erste Zeile ist der Aufbau der Response dem eines Requests ähnlich. Im Beispiel von Abbildung 2.2 befindet sich in der ersten Zeile die SIP- Version, ein Reply-Code (die ähnlich wie bei HTTP aufgebaut sind, Tabelle 2.2) und einen Erklärungstext. 12

17 2.4. RTP SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK51604 From: CSeq: 102 NOTIFY Call-ID: To: Bob Content-Length: 0 User-Agent: kphone/4.0 Contact: Bob <sip:66@ ;transport=udp> Abbildung 2.2: SIP-Response Code 1xx 2xx 3xx 4xx 5xx 6xx Bedeutung Provisional. Der Request wurde empfangen und wird nun verarbeitet Success. Die Anfrage wurde erfolgreich empfangen und verarbeitet Redirection. Der Anruf wird an einen anderen Server weitergeleitet Client Error. Es ist ein Fehler auf der Clientseite aufgetreten Server Error. Es ist ein Fehler auf der Serverseite aufgetreten Global Failure. Die Anfrage kann von keinem Server erfüllt werden SIP-Rufablauf Tabelle 2.2: SIP Reply Codes Im folgenden Beispiel von Abbildung 2.3 sind zwei Benutzer (Alice und Bob) an einem SIP Proxy angemeldet. Wenn Alice Bob anrufen möchte, schickt der UA von Alice eine INVITE-Nachricht an den Proxy, der diese, da er vom Registrar den gegenwärtigen Aufenthaltsort von Bob kennt, an den UA von Bob weiterschickt. Gleichzeitig informiert er Alice über den versuchten Verbindungsaufbau (TRYING) Der UA von Bob schickt als Antwort auf die INVITE-Nachricht über den Proxy ein RINGING zurück. Hebt Bob nun den Hörer ab, wird eine OK-Nachricht versandt, die von Alice mit ACK bestätigt wird. Ab diesem Zeitpunkt läuft die Verbindung direkt zwischen den UAs von Alice und Bob, die einen RTP-Kanal für die Sprachdaten aushandeln und aufbauen und sich die Nachrichten zum Verbindungsabbau auch direkt zusenden. 2.4 RTP Das Internet Protocol (IP) bietet einen best effort -Service, d.h. Ziel ist es, einzelne Datagramme so schnell wie möglich zum Ziel zu befördern. Allerdings gibt es keine Angaben über die gesamte Verzögerung eines Paketes oder 13

18 KAPITEL 2. Voice over IP Abbildung 2.3: SIP Rufaufbau zu möglichen Paketverlusten. Um unnötigen Overhead durch Transportprotokolle zu vermeiden, wird für Echtzeitanwendungen das UDP-basierte RTP verwendet. Retransmits (bei Paketverlust), Congestion control (Anpassen der Übertragungsrate an die verfügbare Bandbreite) und zu großer Overhead durch Headerinformationen des Transportprotokolles wie bei TCP würden den Echtzeitcharakter empfindlich stören. Zudem ist Paketverlust bei diesen Anwendungen ohnehin relativ unkritisch (1% - 20% sind tolerierbar je nach Codec). Mittels RTP kann sowohl Audio als auch Video transportiert werden. In beiden Fällen dient RTP dabei allerdings nur zur Kapselung des Medienstromes in einzelne Pakete. Deren Header enthalten Informationen über den verwendeten Codec, Sequenznummer, Zeitstempel, Synchronisation und ggf. Verschlüsselung (srtp). Somit kann der Empfänger die Pakete wieder in der richtigen Reihenfolge zusammensetzen und eventuell aufgetretene Verluste feststellen allerdings bietet RTP keine Möglichkeit Paketverlust zu verhindern. Dies ist auch nicht möglich, da UDP als Transportprotokoll verwendet wird. Es kann lediglich durch geschickte Paketierung der Mediendaten und Wiedergabemechanismen versucht werden, Paketverluste zu kompensieren. Zudem ist die Verwendung von TCP-Verbindungen für die Übertragung der Medienströme auch nicht sinnvoll, da aufgrund von Retransmits (wie bei TCP üblich) zu spät kommende Pakete ohnehin nicht wiedergegeben werden können denn dies würde bei menschlicher Kommunikation eher verwirrend bis störend wirken. Derartige Nachzügler müssten also ohnehin verworfen werden. 14

19 2.5. Weitere Protokolle 2.5 Weitere Protokolle Wenn auch das Thema dieser Arbeit auf der Verwendung des Session Initiation Protocols (SIP) beruht, so wollen wir noch einen kurzen Blick auf andere VoIP- Protokolle werfen. Dies sind zum einen das weit verbreitete H.323-Protokoll und das zur OpenSource-PBX Asterisk gehörende IAX2-Protokoll. Proprietäre Protokolle wie z.b. SCCP (Skinny Client Control Protocol) von Cisco werden nicht betrachtet, da dies über den Rahmen dieser Arbeit hinausgehen würde und Informationen zu solchen Protokollen z.t. gar nicht öffentlich zugänglich sind H.323 H.323 ist das älteste und zur Zeit am weitesten verbreitete Voice over IP- Protokoll. Es wurde 1996 von der International Telecommunication Union (ITU) [12] verabschiedet und ist eine Weiterentwicklung des ISDN-Standards Q.931. Dadurch erlaubt es eine relativ einfache Integration von traditionellen Telefonsystemen. Außerdem werden alle aus den traditionellen Telefonsystemen bekannten Features von H.323 unterstützt. Das Ziel bei der Enwticklung von H.323 war, einen Standard für Multimediakommunikation über Local Area Networks (LANs) zu schaffen. In den folgenden Jahren wurde H.323 stetig weiterentwickelt; die ersten Erweiterungen wurden im Januar 1998 als H.323v2 verabschiedet. Im September 1999 wurde dann H.323v3 veröffentlicht, mit weiteren Ergänzungen, die vor allem auf den Einsatz in der IP-Telefonie gerichtet sind. Genau wie SIP baut H.323 auf den gängigen Internet Protokollen (IP, TCP, UDP) auf. Auch bei H.323 werden die Signalisierungsdaten getrennt von den Mediendaten übertragen, so dass hier wie bei SIP die gleichen Probleme im Zusammenhang mit NAT und Firewalls entstehen können. H.323-Adressen können entweder wie eine gewöhnliche Rufnummer, ähnlich oder wie eine generelle URI aufgebaut sein. Anders als bei SIP kann eine Adresse nur an einem Endpunkt registriert sein, so dass ein Anruf an diese Adresse genau an einem Endgerät ankommt. Um mehrere Endgeräte gleichzeitig anrufen zu können, wird ein Gatekeeper benötigt, der in der Lage ist, eine einzige Adresse auf mehrere verschiedene abzubilden und diese dann anzuwählen. Wie bereits erwähnt liegt der Ursprung von H.323 bei Multimediakonferenzen. Daher sind eine Vielzahl von Optionen möglich, die nicht alle notwendigerweise für IP-Telefonie benötigt werden. Neben der Komplexität der H.323- Protokollfamilie fehlt ihr zudem die Erweiterbarkeit des Signalisierungsprotokolles. 15

20 KAPITEL 2. Voice over IP IAX2 - Inter Asterisk exchange Das IAX(2)-Protokoll wurde ursprünglich von Mark Spencer zusammen mit Asterisk entwickelt (siehe Kapitel 4.1.4). Es handelt sich hierbei derzeit um keinen offiziellen internationalen Standard, sondern um ein Ergebnis der Zusammenarbeit von OpenSource-Entwicklern. Allerdings wird von diesen bereits eine Einreichung des IAX2-Protokolls bei der IETF diskutiert. IAX benutzt lediglich einen einzelnen UDP-Port (5036 für IAX und 4569 für IAX2) und lässt sich somit hervorragend in NAT-Umgebungen einsetzen. IAX2 kann für Voice- und Video-Telefonie, als auch für die Vernetzung mehrerer Asterisk- Server genutzt werden. IAX2 unterstützt weiterhin Authentifizierung über PKI (PKI = Public-Key Infrastructure) und Trunking. Das Public-Key-Verfahren von IAX2 ermöglicht die Authentifizierung zwischen verschiedenen Asterisk-Servern mittels RSAbasierter Schlüsselpaare. Durch Trunking werden mehrere Gespräche zwischen den gleichen Endpunkten über eine logische Verbindung geleitet, so dass weniger Bandbreite benötigt wird. Zu den wenigen Nachteilen von IAX2 gehört, dass es wie H.323 ein Binärprotokoll ist und damit ohne Parser schwer lesbar ist. Allerdings unterstützt Ethereal [13] ab Version das IAX2 Protokoll. Auch ist die Auswahl an möglichen Endgeräten derzeit noch gering so sind bis jetzt vorrangig Softphones erhältlich (für Windows, Macintosh und Linux). IAX-Telefone (als Hardware) sind allerdings bereits von einigen Herstellern angekündigt. 2.6 NAT und Firewalls Situation Aufgrund der Trennung von Signalisierungsprotokoll (H.323 / SIP) und Medienstrom (RTP) sowie auch durch den Aufbau der Protokolle selbst ergeben sich verschiedene Probleme im Zusammenhang mit Firewalls und/oder NAT. Bei VoIP-Anrufen sind die Signalisierungsdaten, Medienströme, IP-Adresse und Portnummer im Payload-Teil des IP-Paketes eingebettet und nicht ausschliesslich im Header der Pakete (Abbildung 2.4 und 2.5). NAT arbeitet üblicherweise auf Layer 3 (IP Layer) und modifiziert dort die Quell- und Zieladressen. Da aber bei VoIP-Anwendungen die IP-Adressen bis in den Application-Layer enthalten sind, stellt dies für (die meisten) NAT-Router ein Problem dar: die angegebenen IP-Adressen/Ports sind aufgrund der NAT nicht mehr erreichbar und die Signalisierung und Medienstöme laufen nur in eine einzige Richtung. 16

21 2.6. NAT und Firewalls INVITE SIP/2.0 Via: SIP/2.0/UDP CSeq: 799 INVITE To: Content-Type: application/sdp From: Rainer Call-ID: Subject: Content-Length: 183 User-Agent: KPhone/3.11 Contact: Abbildung 2.4: SIP Signalisierung 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 Abbildung 2.5: SDP Signalisierung Firewalls blocken im Normalfall jedweden Verbindungsversuch ab, der von aussen zum geschützten Netzwerkbereich hin erfolgt. Pakete von ausserhalb werden idr. nur erlaubt, wenn sie entweder einer bestehenden Verbindung zugeordnet werden können, oder es sich um einen bestimmten erlaubten Host/- Port handelt. Zudem sind an einem VoIP-Anruf mehrere Protokolle beteiligt: SIP oder H.323 zur Signalisierung, SDP bzw. H.225 und H.245 zur Bestimmung der Fähigkeiten der Endgeräte, RTP/RTCP zur Übertragung und Kontrolle der Medienströme. Während für die Signalisierung noch ein fester Port verwendet wird (z.b bei SIP), werden die RTP-Ports dynamisch ausgehandelt, was dazu führt, dass Firewalls derartige Verbindungen idr. blockieren werden Lösungen Firewall öffnen: Die einfachste Lösung bei einer Firewall ist es, die entsprechenden Ports in der Firewall dauerhaft zu öffnen: Signalisierungsport (z.b bei SIP) und ein fester Portbereich für die RTP-Stöme. 17