Voice over IP unter Verwendung von OpenSource

Transcription

Voice over IP
unter Verwendung von OpenSource-Software
Maik Schmitt
<[email protected]>
<sip:[email protected]>
Rainer Jochem
<[email protected]>
<sip:[email protected]>
RSI
T
IS
S
UN
R
VE
AS
SA
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
I
Fortgeschrittenenpraktikum
A V EN
I
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
Inhaltsverzeichnis
1
Einleitung
5
2
Voice over IP
2.1 Funktionsweise . . . . . . . . . . . . .
2.2 Audiocodecs . . . . . . . . . . . . . .
2.3 SIP - Session Initiation Protocol . . . .
2.3.1 Komponenten . . . . . . . . . .
2.3.2 Aufbau der SIP-Nachrichten . .
2.3.3 SIP-Rufablauf . . . . . . . . .
2.4 RTP . . . . . . . . . . . . . . . . . . .
2.5 Weitere Protokolle . . . . . . . . . . .
2.5.1 H.323 . . . . . . . . . . . . . .
2.5.2 IAX2 - Inter Asterisk eXchange
2.6 NAT und Firewalls . . . . . . . . . . .
2.6.1 Situation . . . . . . . . . . . .
2.6.2 Lösungen . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
9
10
11
13
13
15
15
16
16
16
17
3
Ziele
3.1 Anbindung des LS Computergraphik . . . . . . . . . . . . . .
3.2 SIP-Server für Studenten und Mitarbeiter . . . . . . . . . . .
3.3 Erweiterung der TK-Anlage um ENUM . . . . . . . . . . . .
19
19
19
20
4
Verwendete Software
4.1 Überblick . . . . . . . . . . . . .
4.1.1 Bayonne . . . . . . . . .
4.1.2 Vocal . . . . . . . . . . .
4.1.3 SIP Express Router (SER)
4.1.4 Asterisk . . . . . . . . . .
4.2 Erfahrungen . . . . . . . . . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
21
22
22
23
Lehrstuhl-Server
5.1 Anforderungen . . . . . . . . . . . . .
5.2 Umsetzung . . . . . . . . . . . . . . .
5.3 Allgemeine Konfiguration von Asterisk
5.4 Einrichten der SIP-Teilnehmer . . . . .
5.4.1 Globale Parameter . . . . . . .
5.4.2 Benutzerspezifische Parameter .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
28
30
31
32
.
.
.
.
.
.
.
.
.
.
.
.
1
INHALTSVERZEICHNIS
5.5
5.6
5.7
5.8
6
7
8
9
2
5.4.3 Zugehöriger Rufnummernplan . . . . . . .
Anbindung an das ISDN-Festnetz . . . . . . . . .
5.5.1 Installation . . . . . . . . . . . . . . . . .
5.5.2 Rufnummernplan mit Berechtigungsstufen
Voicemail . . . . . . . . . . . . . . . . . . . . . .
Sonstige Funktionen im Rufnummernplan . . . . .
5.7.1 Konferenzräume . . . . . . . . . . . . . .
5.7.2 Erreichbarkeit der Teilnehmer . . . . . . .
5.7.3 ENUM . . . . . . . . . . . . . . . . . . .
Asterisk-Patches . . . . . . . . . . . . . . . . . .
5.8.1 Verschlüsselte SIP-Passwörter . . . . . . .
5.8.2 Erstellen eines Benutzerinterfaces . . . . .
Studentenserver
6.1 Anforderungen
6.2 Umsetzung . .
6.3 Konfiguration .
6.3.1 SER . .
6.3.2 Asterisk
6.3.3 DNS .
6.4 Webinterface .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
35
35
36
41
42
43
43
44
44
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
48
48
50
51
51
ENUM
7.1 public ENUM . . . . . . . . . . . . . . .
7.2 user ENUM . . . . . . . . . . . . . . . .
7.3 Umsetzung mit Asterisk . . . . . . . . .
7.3.1 Konfiguration des E1-Interfaces .
7.3.2 Rufnummernplan . . . . . . . . .
7.4 Erweiterung von TK-Anlagen um ENUM
7.5 user ENUM mit Bind . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
54
55
55
57
61
62
.
.
.
.
.
.
.
.
.
.
.
64
64
64
65
66
67
67
67
68
68
69
69
Zusammenfassung
9.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
72
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Endgeräte
8.1 Hardphones . . . . . .
8.1.1 Cisco 7960 . .
8.1.2 Cisco 7905 . .
8.1.3 Snom 100 . . .
8.2 Analog-IP - Wandler .
8.2.1 Cisco ATA-186
8.2.2 Digium IAXy .
8.3 Softphones . . . . . .
8.3.1 KPhone . . . .
8.3.2 X-Lite . . . . .
8.4 Headsets . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
A Verwendete Konfigurationsdateien
A.1 extensions.conf . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 sip.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Skript zum Abgleich der sip.conf mit einer MySQL-Datenbank
74
74
80
81
B Glossar
83
C Verantwortliche
C.1 Maik Schmitt . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 Rainer Jochem . . . . . . . . . . . . . . . . . . . . . . . . .
86
86
86
3
INHALTSVERZEICHNIS
4
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
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 VoIPServer 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 mehrfachISDN-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 VoIPFunktionalitä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 SIPTelefon bekannt, das eine Verschlüsselung aller Datenströme anbietet.
6
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 VoIPGesprächs skizziert:
1. Die Teilnehmer sind an ihrem jeweiligen VoIP-Server mit einem VoIPEndgerät angemeldet. Unter Verwendung eines Signalisierungsprotokolls
7
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 IPTransportprotokoll (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
G.711
G.729
G.723.1
G.726
(ADPCM)
GSM
iLBC
Speex
LPC10
Samplerate
8kHz
8kHz
8kHz
8kHz
Bandbreite
64kbps
8kbps
5.6kbps - 6.3bps
16, 24, 32, 40kbit/s
8kHz
8kHz
8kHz/16kHz/32kHz
13kbps
15kbps
2.15kbps - 44.2kbps
8kHz
2.4kbps
Ursprung
ITU-T
ITU-T
ITU-T
ITU-T
ersetzt G.723.1
ETSI
IETF-draft [4]
OpenSource
speex.org [5]
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
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 e-mail 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
2.3.1 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
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.
2.3.2 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 SIPResponses später geroutet werden sollen.
From und To dienen dazu, den Sender und Empfänger der Nachricht zu spezifizieren (vgl. e-mail). Ü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
HEADER
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2
CSeq: 799 INVITE
To: <sip:[email protected]>
Content-Type: application/sdp
From: “Bob” <sip:[email protected]>;tag=64ACEA4F
Call-ID: [email protected]
Subject: Important Call
Content-Length: 183
User-Agent: KPhone/3.11
Contact: “Bob” <sip:[email protected];transport=udp>
BODY
v=0
o=username 0 0 IN IP4 192.168.1.2
s=The Funky Flow
c=IN IP4 192.168.1.2
t=0 0
m=audio 32820 RTP/AVP 0 97 3
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 SIPVersion, ein Reply-Code (die ähnlich wie bei HTTP aufgebaut sind, Tabelle
2.2) und einen Erklärungstext.
12
2.4. RTP
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bK51604
From: <sip:[email protected]>;tag=as668fc20b
CSeq: 102 NOTIFY
To: ”Bob” <sip:[email protected]>;tag=3DA82C86
Content-Length: 0
User-Agent: kphone/4.0
Contact: ”Bob” <sip:[email protected];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
Tabelle 2.2: SIP Reply Codes
2.3.3 SIP-Rufablauf
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
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
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 VoIPProtokolle 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.
2.5.1 H.323
H.323 ist das älteste und zur Zeit am weitesten verbreitete Voice over IPProtokoll. 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, Emailä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.323Protokollfamilie fehlt ihr zudem die Erweiterbarkeit des Signalisierungsprotokolles.
15
2.5.2 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 AsteriskServer 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 0.10.1 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
2.6.1 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
2.6. NAT und Firewalls
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2
CSeq: 799 INVITE
To: <sip:[email protected]>
Content-Type: application/sdp
From: “Rainer” <sip:[email protected]>;tag=64ACEA4F
Subject: sip:[email protected]
Content-Length: 183
User-Agent: KPhone/3.11
Contact: <sip:[email protected];transport=udp>
Abbildung 2.4: SIP Signalisierung
v=0
o=username 0 0 IN IP4 192.168.1.2
s=The Funky Flow
c=IN IP4 192.168.1.2
t=0 0
m=audio 32820 RTP/AVP 0 97 3
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.
5060 bei SIP), werden die RTP-Ports dynamisch ausgehandelt, was dazu führt,
dass Firewalls derartige Verbindungen idR. blockieren werden.
2.6.2 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. 5060 bei SIP) und ein fester Portbereich für die RTP-Stöme.
17
Die meisten Endgeräte sind in der Lage, einen durch den Benutzer definierten Portbereich für die Medienströme zu verwenden. Diese Möglichkeit bietet sich v.a. dann an, wenn sich die VoIP-Endgeräte in einem
eigenen Netzbereich befinden.
“Fixup-Protokoll”: Eine elegantere Lösung bietet der Einsatz von Firewalls/
NAT-Routern, die die gängigen VoIP-Protokolle kennen. Einige Hersteller bieten ein sog. ”Fixup-Protocol” in ihren Geräten an, mit dem die
Firewall oder der Router in der Lage ist, die in den Datenpaketen angegebenen IP-Adressen und Ports bis in Layer 7 zu korrigieren. Somit sind
VoIP-Gespräche auch durch Firewalls und NAT möglich. Allerdings versagt auch diese Technik, wenn verschlüsselte Datenströme (z.B. über
IPSec oder SSL/TLS) verwendet werden.
UPnP: Als weitere Lösungsmöglichkeit bietet sich UPnP (Universal Plug and
Play) an. Dabei fragt das Endgerät am NAT-Router nach dem zu verwendenden Mapping von privater und öffentlicher IP-Adresse und Port und
verwendet dann dies als Absenderadresse in den entsprechenden Protokollen. Auch bietet z.B. Windows XP die Möglichkeit, dass ein Endgerät
die Internetverbindungsfirewall mittels UPnP so umkonfigurieren kann,
dass die entsprechenden Pakete die Anwendung erreichen. Das Problem
hierbei ist, dass dies nicht bei kaskadierten NATs funktioniert, die wenigsten NAT-Implementierungen UPnP-tauglich sind und Änderungen
von Firewallregeln durch Anwendungen ein Sicherheitsrisiko bergen.
STUN: (Simple Traversal of UDP Through NATs, RFC3489 [14]) ist eine
Möglichkeit mit der Endgeräte, die sich hinter einem NAT-Router befinden, Informationen über die Netzwerkkonfiguration erlangen können.
Hierbei sendet das Endgerät eine Nachricht an einen ausserhalb des
NATs befindlichen STUN-Server. Dieser antwortet dann mit der Kombination aus IP-Adresse und Port, mit der das Paket abgesendet wurde.
Verwendet ein Endgerät z.B. die lokale Adresse 192.168.1.3:12345, so
schickt es mit dieser Adresse eine Anfrage an den STUN-Server ausserhalb des NATs. Dieser empfängt das Paket mit der Absendeadresse
134.96.249.10:8899 und antwortet an diese Adresse mit einem Paket,
dass diese IP:Port-Kombination enthält. Somit kann das hinter dem NAT
befindliche Endgerät dann für alle folgenden Verbindungen diese Adresse in den SIP/SDP-Paketen verwenden, während es selbst weiterhin auf
192.168.1.3:12345 hört.
Somit kann das Endgerät herausfinden, ob es Netzwerkzugang hat, ob
eine Firewall UDP blockt und ob NAT zum Einsatz kommt.
Eine weitere Möglichkeit wäre natürlich noch, das VoIP-Protokoll selbst zu
ändern oder zu erweitern, dass derartige Probleme gar nicht erst auftreten (wie
es z.B. bei IAX der Fall ist).
18
Kapitel 3
Ziele
Im Rahmen dieses Projektes soll in Zusammenarbeit mit dem Rechenzentrum
der Universität des Saarlandes eine SIP-basierte VoIP-Lösung geschaffen werden, die Studenten und Mitarbeiter gleichermaßen nutzen können.
Die Aufgaben gliedern sich im Wesentlichen in die folgenden drei Bereiche:
3.1 Anbindung des Lehrstuhls für Computergraphik
an die bestehende VoIP-Infrastruktur
Im Rahmen dieses Teilprojektes soll der Lehrstuhl für Computergraphik mit
IP-Telefonen ausgestattet werden und ein lehrstuhleigener VoIP-Server installiert werden. Dieser Server soll die benötigten Dienste wie Voicemail, Konferenzräume, Rufweiterleitung, Fax, ENUM, usw. bereitstellen. Die Anbindung
zum Festnetz erfolgt hierbei per IP über den Asterisk-Server im Rechenzentrum und von dort über eine S2M-Leitung zur TK-Anlage. Als Failover / Testkarte dient eine ISDN-Karte im lokalen Server, die direkt mit der TK-Anlage
verbunden ist.
3.2 SIP-Server für Studenten und Mitarbeiter
Ziel dieses Teilprojektes ist es, jedem Studenten und Mitarbeiter eine gültige
SIP-Adresse zuzuweisen. Dabei soll eine möglichst weite Integration in die
bestehende Struktur gewährleistet sein. So sollen z.B. die bestehenden EmailAdressen auch gleichzeitig als SIP-Adressen verwendet werden können.
Den Studenten und Mitarbeitern soll es zusätzlich zur Erreichbarkeit über VoIP
ermöglicht werden, mit ihrer SIP-Adresse auch alle internen Telefonanschlüs-
19
KAPITEL 3. Ziele
se der Universität des Saarlandes und Anschlüsse anderer Universitäten, die
bereits über das Netzwerk des Deutschen Forschungsnetzes (DFN) erreichbar sind, kostenlos anzurufen. Außerdem sollen die SIP-Teilnehmer auch aus
dem Festnetz erreichbar sein. Weiterhin soll jeder SIP-Adresse auch eine Voicemailbox zugeordnet werden, die die aufgenommen Nachrichten an die zur
SIP-Adresse gehörende Email-Adresse weiterleitet.
3.3 Erweiterung der bestehenden TK-Anlage um
ENUM-Funktionalität
Um den Vorteil der Kostenersparnis durch den Einsatz von Voice over IP für
alle Anwender nutzen zu können (z.B. um Anschlüsse an anderen Universitäten zu erreichen), ohne dabei die bisherige TK-Infrastruktur ersetzen zu müssen, werden abgehende Gespräche über einen Server geroutet, der durch Prüfung von ENUM-Einträgen versucht, diese kostengünstig über VoIP an den
gewünschten Gesprächspartner weiterzuleiten.
Auch sind für alle Nebenstellen der Universität des Saarlandes ENUM-Einträge
vorhanden, so dass alle Nebenstellen auch über VoIP erreichbar sind. Daher
besteht die weitere Aufgabe des Systems darin, eingehende VoIP-Gespräche
an die betreffenden Nebenstellen weiterzuleiten.
20
Kapitel 4
Verwendete Software
4.1 Überblick
Derzeit gibt es vier größere OpenSource-Projekte im VoIP-Umfeld: Bayonne,
Vocal, SER und Asterisk.
4.1.1 Bayonne
Bayonne [15] ist eine in C++ geschriebene Interactive Voice Response (IVR)
Plattform und unter der GPL erhältlich. Zur Verbindung ins Festnetz unterstützt Bayonne dabei Voicetronix- und Dialogic-Hardware, sowie CAPI-fähige
Hardware.
Allerdings wurde Bayonne ursprünglich als reine IVR-Lösung geschrieben
und später um Telefonanlagenfunktionalität erweitert. Die vorhandenen Anwendungen sind allerdings nicht sehr umfangreich und Bayonne bietet auch
keine gute Möglichkeit, eigene Skripte oder Anwendungen einzubinden, wie
es beispielsweise bei Asterisk der Fall ist. Auch ist die Konfiguration der Hardware und Treiber umständlich. Zudem wird als VoIP-Protokoll zur Zeit ausschließlich H.323 unterstützt.
Da Bayonne schon aus diesen Gründen für unsere Zwecke nicht geeignet ist,
wurde auf eine weitere Betrachtung verzichtet.
4.1.2 Vocal
Vocal [16] ist ein unter einer BSD-ähnlichen, Vocal-Lizenz frei erhältlicher
VoIP-Server, der sowohl SIP als auch H.323 beherrscht. Eine Anbindung zum
Festnetz ist nur über zusätzliche Soft- oder Hardware möglich. Vocal zeich-
21
KAPITEL 4. Verwendete Software
net sich vor allem über einen sehr umfassenden und redundanten Aufbau aus,
der es erlaubt verschiedene Dienste auf separate Rechner zu verteilen. Allerdings lässt sich Vocal nur sehr kompliziert installieren, was unter anderem
daran liegt, dass es Bibliotheken benötigt, die ebenfalls recht umständlich zu
installieren sind. Weiterhin kann Vocal nur mittels einer (etwas trägen) und unübersichtlichen JAVA-GUI konfiguriert werden und bietet keinen Zugriff auf
etwaige Textkonfigurationsdateien mit denen z.B. eine automatisierbare Konfiguration möglich wäre.
4.1.3 SIP Express Router (SER)
SER ist ein OpenSource SIP-Server (GPL), der als Registrar-, Proxy- oder
Redirectserver betrieben werden kann. Gegenwärtig wird SER von iptel.org
[17] in Berlin entwickelt, einer Arbeitsgruppe der FhG FOKUS [18].
Zu den Vorteilen von SER gehört, dass es sich sehr einfach installieren lässt
und auch bei geringen Systemanforderungen sehr gut skalierbar und leistungsfähig ist. Weiterhin verfügt SER über die Möglichkeit, Benutzer nicht nur über
eine eigene SQL-Datenbank, sondern auch mittels RADIUS zu authentifizieren. Neben der Authentifizierung gibt es auch ein Abrechnungsmodul für RADIUS. Die Konfiguration erfolgt über Textdateien, die eine C-ähnliche Syntax
verwenden.
SER wird derzeit relativ aktiv entwickelt und findet auch bereits bei vielen
VoIP-Diensteanbietern wie z.B. Free World Dialup [19] Verwendung.
Allerdings ist SER lediglich ein reiner SIP-Server, d.h. eine Anbindung zu
anderen VoIP-Protokollen oder zum Festnetz muss über zusätzliche Soft- oder
Hardware erfolgen.
Mittlerweile wird an einer Nachfolgeversion “Application Agent (AA)” [20]
von SER gearbeitet, die allerdings nicht mehr unter der GPL steht.
4.1.4 Asterisk
Asterisk [21] ist eine OpenSource-PBX (GPL). Maßgeblich an der Entwicklung von Asterisk beteiligt ist Digium [22], ein mittelständisches, US-amerikanisches Unternehmen, das zusätzlich auch kommerziellen Support und kommerzielle Lösungen für Asterisk anbietet und Telefonhardware zur Verwendung mit Asterisk herstellt. Zudem gibt es auch eine äußerst aktive und große
weltweite Entwicklergemeinde, die an und mit Asterisk arbeitet. Die zentrale
Verwaltung (Releases, CVS, Bugtracker, Mailinglisten, usw.) geschieht hierbei
durch Mark Spencer/Digium.
22
4.2. Erfahrungen
Asterisk bietet eine Vielzahl an Funktionen und Erweiterungsmöglichkeiten.
Neben der Unterstützung zahlreicher Voice over IP-Protokolle (SIP, H.323,
IAX, MGCP, Skinny) bietet Asterisk auch die Möglichkeit der Festnetzanbindung. Hierbei können prinzipiell alle Analog- als auch ISDN-Karten verwendet werden, die unter Linux Unterstützung finden. Digium selbst bietet auch
eigene Hardware (E1-Karten, uvm.) zur Verwendung mit Asterisk an.
Darüber hinaus verfügt Asterisk über viele weitere in der Telefonie übliche
Funktionen wie CTI, IVR, ACD und DISA, sowie ENUM und eine Schnittstelle zum Einbinden eigener Skripte/Programme (AGI).
Durch die recht grosse Zahl an Benutzern und Entwicklern findet desweiteren
eine stetige Weiter- und Neuentwicklung verschiedenster Features statt: Datenbanksupport, GUIs zur Konfiguration, Faxempfang- und Versand, uvm.
Weitere Vorteile von Asterisk sind u.a. dass es übersichtliche, textbasierte Konfigurationsdateien verwendet, Schnittstellen zum Einbinden eigener Skripte
bietet und einen leicht erweiterbaren modularen Aufbau besitzt.
Natürlich hat auch Asterisk noch einige Schwächen: So sind die Implementierungen der einzelnen VoIP-Module (z.B. SIP) nicht vollständig im Vergleich
zum RFC (wobei die wichtigsten Funktionen durchaus bereits implementiert
sind) und eine native Datenbankunterstützung und grafische Benutzeroberflächen befinden sich erst in der Entwicklung.
Eine Einführung zu Asterisk kann bei O’Reilly [23] nachgelesen werden. Auch
ist eine Aufzeichnung des Vortrags von Mark Spencer zu Asterisk, der anlässlich des 10. Linuxkongress 2003 in Saarbrücken stattfand, auf den Seiten des
VCORE-Projektes [24] verfügbar.
4.2 Erfahrungen
Um eine geeignete Software zu finden, wurden verschiedene Kombinationen
getestet. Da das SIP-Protokoll verwendet werden sollte, haben wir zunächst
einen SER-Server aufgesetzt. Dabei erwies sich SER als recht gut zu administrierende Software, so dass es schnell möglich war, SIP-Telefonate zu führen.
Da SER allerdings über keinerlei Möglichkeiten verfügt, eine Verbindung zum
ISDN herzustellen, war weitere Software erforderlich.
Hier gab es nun mehrere Möglichkeiten: Es existiert ein isdn2h323-Gateway
[25], mit dessen Hilfe Verbindungen zwischen ISDN und einem H.323-Gatekeeper möglich sind. Weiterhin verfügt Vocal über ein sip-h323-Gateway, das
auch getrennt von Vocal betrieben werden kann.
23
KAPITEL 4. Verwendete Software
Aus diesem Grund wurden zunächst die Kombinationen aus
SER + sip2h323 + isdn2h323
Vocal + isdn2h323
einer näheren Betrachtung unterzogen.
Keine dieser Varianten hat sich jedoch als praxistauglich herausgestellt - einerseits weil es schlichtweg nicht oder nur sehr umständlich und nicht mit dem
vollen, benötigten Funktionsumfang funktioniert. Auch hätte es teilweise eine
Kombination vieler unterschiedlicher Programme bedeutet.
Deshalb wurde auf einem weiteren Rechner ein Asterisk-Testsystem installiert.
Zunächst verwendeten wir eine ISDN-Karte mit den ISDN4Linux-Treibern,
was auch sehr schnell den gewünschten Erfolg brachte. Um allerdings eine
bessere Sprachqualität zu erreichen, benutzten wir im folgenden jedoch die
CAPI-Treiber.
Da sich auch eine Anbindung von SER an Asterisk reibungslos gestaltete, wurden für die Umsetzung der Projekte (Studentenserver, Lehrstuhlserver, ENUMLookup) somit SER und Asterisk verwendet.
24
Kapitel 5
Lehrstuhl-Server
5.1 Anforderungen
Zu den Funktionen und Möglichkeiten, die ein VoIP-System bietet, sollen für
den Lehrstuhl auch weiterhin alle benötigten Merkmale der bekannten Telefonwelt zur Verfügung stehen und eine Anbindung zum bestehenden Telefonnetz über ISDN erfolgen:
Berechtigungsstufen für abgehende Gespräche Jedem Telefonanschluss an
der Universität ist eine bestimmte Berechtigungsstufe zugeordnet, d.h.
je nach Anschluss können z.B. nur Teilnehmer aus Saarbrücken oder
dem Saarland erreicht werden. Diese Rufnummernbeschränkungen sollen auch für ins Festnetz abgehende Gespräche der VoIP-Teilnehmer
übernommen werden.
Voicemailbox für jeden Teilnehmer Jeder VoIP-Teilnehmer soll eine eigene
Voicemailbox (“Anrufbeantworter”) erhalten.
Konferenzräume Das System soll auch Telefonkonferenzen mit mehreren
Teilnehmern, d.h. mehr als die vom ISDN her bekannte Dreierkonferenz, bieten.
Fax Weiterhin soll das System Faxempfang und -versand ermöglichen. Idealerweise sogar mit direkter Weiterleitung des empfangenen Faxes an den
betreffenden Teilnehmer per Email.
Erreichbarkeit von Teilnehmern anderer Protokollwelten (H.323) Da derzeit zwei große internationale VoIP-Standards existieren, soll auch eine
Kommunikation mit Nutzern dieser Technik ermöglicht werden.
ENUM Bei abgehenden Gesprächen ins Festnetz soll durch Prüfung von ENUMEinträgen ein kostengünstigeres Vermitteln der Gespräche über VoIP
versucht werden.
25
KAPITEL 5. Lehrstuhl-Server
Erweiterbarkeit Das verwendete System sollte so aufgebaut sein, dass es
leicht um weitere Funktionen oder Protokolle ergänzt werden kann.
Einfache und flexible Administration Selbstverständlich soll der VoIP-Server auch leicht zu installieren und gut zu warten sein.
5.2 Umsetzung
Die einzige Software, die die benötigten Anforderungen erfüllt, ist Asterisk.
Um sich mit Asterisk vertraut zu machen, haben wir zuerst ein Testsystem zusammengestellt: Hierzu dient ein PentiumII 350MHz, 384MB RAM, 40GB
Festplatte, Kernel 2.4.21 und Debian Linux. Da mit diesem Rechner auch eine Verbindung ins Festnetz hergestellt werden soll, ist desweiteren eine PCIISDN-Karte vom Typ Fritz!Card PCI eingebaut.
Abbildung 5.1: Ursprüngliche Installation
26
5.2. Umsetzung
Abbildung 5.1 zeigt die ursprünglich vorhandene Infrastruktur mit den an der
TK-Anlage angeschlossenen ISDN-Telefonen sowie die vorhandene Netzwerkinfrastruktur. Ausgehend von diesem Aufbau wurden alle nachfolgend beschriebenen Installationen durchgeführt.
Zunächst geschah die Anbindung des Asteriskservers zum ISDN unter Verwendung von ISDN4Linux (I4L). Allerdings hat sich dies aufgrund der auftretenden Echos in den Gesprächen als weniger brauchbar herausgestellt. Auch
gibt es bei I4L einen Kernel-Bug der zur Fehlerkennung von DTMF-Tönen
führt, die sich ebenfalls störend im Gespräch bemerkbar machen. Daher wurde
beschlossen, Linux mit CAPI-Unterstützung und den CAPI-Treibern des Kartenherstellers (AVM) [26] zu verwenden. Dies hat erwartungsgemäß die mit
I4L auftretenden Fehler behoben und sich auch als stabile Lösung erwiesen.
Nach der Anbindung ans Festnetz wurden auf dem Server Testbenutzer für SIP
eingerichtet, mit denen Anrufe von und zur TK-Anlage der Universität geführt
werden konnten. Da sich dies als funktionstüchtig erwiesen hat, wurde dem
Lehrstuhl durch das Rechenzentrum ein vorläufiger Rufnummernblock von 20
Rufnummern für weitere Tests zur Verfügung gestellt. Diese Rufnummern sind
von allen Nebenstellenanschlüssen der TK-Anlage erreichbar und werden von
dieser über eine E1-Leitung zum Rechenzentrum geleitet, wo die Anrufe durch
einen Cisco-Router aus dem ISDN-Netz in das VoIP-Netz ausgekoppelt wurden. Dieser Router leitete die Gespräche mittels SIP an den Asterisk-Server
des Lehrstuhls weiter. Auch war es in umgekehrter Richtung möglich, vom
Asterisk-Server unter Verwendung von SIP Anrufe über den Cisco-Router ins
ISDN-Netz zu leiten.
Mittlerweile geschieht die Auskopplung der ISDN-Anrufe in das VoIP-Netz
über einen im Rechenzentrum installierten Asterisk-Server (siehe Kapitel 7),
der die Gespräche ebenfalls direkt per VoIP mittels IAX2 zum Lehrstuhl weiterleitet.
Die oben erwähnten Rufnummern wurden im weiteren Verlauf den Mitarbeitern des Lehrstuhls für weitere Testzwecke zur Verfügung gestellt: jeder
ISDN-Rufnummer wurde eine SIP-Rufnummer mit einer entsprechenden Berechtigungsstufe zugewiesen. Auf diese Weise ist es nun möglich, jede dieser
Rufnummern sowohl über IP (SIP) als auch über ISDN – durch die TK-Anlage
der Universität über das Rechenzentrum zum Lehrstuhl – anzurufen. Weiterhin
können die am Asterisk-Server angemeldeten SIP-Benutzer andere Teilnehmer
entweder per VoIP als auch über ISDN erreichen. In letzterem Fall wird der
abgehende Anruf über die ISDN-Karte im Asterisk-Server des Lehrstuhls zur
TK-Anlage der Universität geleitet, um eventuell entstehende Kosten eindeutig
dem Lehrstuhl Computergraphik zuordnen zu können (siehe Abb. 5.2).
Im weiteren Verlauf wurden dann die VoIP-Verbindungen des Servers erweitert: So verfügen die Universität Stuttgart und die Universität Ulm ebenfalls
über Asterisk-Server, zu denen eine Verbindung unter Verwendung des IAX2-
27
Abbildung 5.2: Testaufbau
Protokolls hergestellt wurde. Durch entsprechende Einträge im Rufnummernplan des lokalen Asterisk-Servers ist es somit möglich, abgehende Gespräche
der hier am Lehrstuhl angemeldeten Teilnehmer zu diesen beiden Universitäten kostengünstig über VoIP zu leiten. Zudem wurden für abgehende Gespräche ENUM-Anfragen aktiviert (siehe Kapitel 7).
Für Asterisk ist auch ein Software-Fax-Plugin erhältlich [27]. Allerdings befindet sich dieses Modul noch in der Entwicklung und bereitet noch mit einigen
“echten” Faxgeräten Probleme, so dass ein Einsatz in produktiver Umgebung
derzeit noch nicht sinnvoll erscheint.
5.3 Allgemeine Konfiguration von Asterisk
Im folgenden wollen wir die genaue Konfiguration der umgesetzten Funktionen betrachten. Zunächst jedoch ein kurzer Überblick der allgemeinen Kon-
28
5.3. Allgemeine Konfiguration von Asterisk
figuration. Die Konfiguration von Asterisk geschieht mit Hilfe von Textdateien, die sich bei einer Standardinstallation in /etc/asterisk befinden. Die
Konfigurationsdateien von Asterisk sind der Datei win.ini von Windows
sehr ähnlich.
;
; Beispiel-Konfigurationsdatei
;
[abschnitt1]
Variable = Wert
[abschnitt2]
Variable = Wert
Objekt => Wert
Abbildung 5.3: Format der Konfigurationsdatei
Sie sind in Abschnitte unterteilt, die jeweils mit einem in eckigen Klammern
eingeschlossenen Namen beginnen. Der Name dient zur späteren Referenzierung des Inhaltes dieses Abschnittes. Die erste Zeile in einer Datei (die keine
Leer- oder Kommentarzeile ist) muss einen Abschnitt einleiten. In den einzelnen Abschnitten stehen Zeilen mit Paaren aus Schlüsselwort und Wert, die
durch = oder => getrennt werden. Beide Schreibweisen haben die gleiche Bedeutung. Es ist lediglich eine verbreitete Gewohnheit einfache Variablenzuweisungen in den Konfigurationsdateien mit = und die Logik des Rufnummernplanes mit => zu kennzeichnen. Kommentare werden mit ; eingeleitet und
erstrecken sich bis zum Ende der jeweiligen Zeile.
Obwohl das Format bei allen Konfigurationsdateien gleich ist, gibt es drei verschiedene Grammatiken, die typischerweise verwendet werden.
Simple Groups: Hier werden Objekte mit allen Argumenten in einer einzigen
Zeile definiert. Dieses Format ist sinnvoll bei Objekten, die nur wenige
Optionen haben.
[mysection]
object1 => option1a,option1b,option1c
object2 => option2a,option2b
Abbildung 5.4: Simple Groups
Dieses Format wird z.B. in den Dateien extensions.conf,
meetme.conf und voicemail.conf verwendet.
29
Inherited Option Object: Dieses Format ist sinnvoll bei Objekten, die viele Optionen haben, welche bei den meisten Objekten gleich sind. Hier
werden die Optionen vor dem Objekt definiert und sind, sofern sie nicht
geändert werden, auch für alle folgenden Objekte gültig.
[mysection]
option1 = foo
option2 = bar
object => 1
option2 = baz
object => 2
Abbildung 5.5: Inherited Option Object
Dieses Format wird u.a. in den Dateien capi.conf und zapata.conf
verwendet.
Complex Entity Object: Diese Grammatik ist sinnvoll bei Objekten, die viele Optionen haben, von denen nur wenige für alle Objekte gleich sind.
Hier wird jedem Objekt ein eigener Abschnitt zugeteilt. Oft gibt es bei
diesen Dateien auch einen Abschnitt mit dem festen Namen general, in
dem globale Parameter definiert werden.
[general]
globaloption1 = globalvalue1
globaloption2 = globalvalue2
[object1]
option1 = value1
Abbildung 5.6: Complex Entity Object
Dieses Format wird vor allem in den Konfigurationsdateien der VoIP
Channel-driver verwendet.
5.4 Einrichten der SIP-Teilnehmer
Zunächst einmal wollen wir die einzelnen SIP-Teilnehmer im System einrichten und den Server soweit konfigurieren, dass VoIP-Gespräche mittels SIP
möglich sind.
30
5.4. Einrichten der SIP-Teilnehmer
5.4.1 Globale Parameter
Am Beginn der Datei sip.conf werden die allgemeinen Parameter für den
SIP Channel-Treiber im Abschnitt [general] eingestellt. Dies dient zum einen
dazu Parameter, die für alle Teilnehmer gleich sind zu definieren, als auch
Default-Werte für eingehende Gespräche aus dem Internet zu setzen.
[general]
port = 5060
bindaddr = 0.0.0.0
context = default
maxexpirey = 3600
defaultexpirey = 120
disallow = all
allow = alaw
allow = ulaw
allow = gsm
srvlookup = yes
dtmfmode = inband
Abbildung 5.7: Globale Parameter in sip.conf
Abbildung 5.7 zeigt einen typischen Aufbau für diesen Abschnitt. Die Variablen port und bindaddr bestimmen den Port und das Netzwerkinterface auf
dem SIP-Anfragen entgegengenommen werden sollen. Der Wert 0.0.0.0 steht
hierbei für alle im Server vorhandenen Netzwerkinterfaces. Mit context wird
ein sog. Kontext – dies ist ein Abschnitt des Rufnummernplanes, der die entsprechenden Berechtigungen für diesen Teilnehmer regelt – festgelegt. Der
hier angegebene Kontext wird für alle Teilnehmer verwendet, denen kein eigener Kontext zugewiesen wurde. Dies sind z.B. auch alle von außerhalb eingehenden SIP-Telefonate. maxexpiry und defaultexpiry regeln die maximale bzw.
standardmäßige Dauer einer Registrierung der SIP-Teilnehmer. Nach Ablauf
dieser Dauer muss sich der Teilnehmer erneut am Server anmelden.
Mit den Variablen disallow und allow werden die vom Server erlaubten Audiocodecs angegeben. In diesem Fall also G.711 alaw vor G.711 ulaw und dies vor
GSM. Üblicherweise verbietet man an dieser Stelle zunächst alle vorhandenen
Codecs, um dann explizit die gewünschten Codecs freizugeben. Um Verständigungsprobleme wegen Codecs mit schlechter Sprachqualität zu vermeiden,
sollte man nur bestimmte Codecs zulassen.
Die Variable srvlookup weist Asterisk an, bei abgehenden Gesprächen nach
SRV-Records (Service Records) zu suchen. Diese sind Teil des DNS und dienen dazu, zusätzliche Informationen über verfügbare Dienste zu geben. Siehe
hierzu auch Kapitel 6.3.3. dtmfmode gibt an, ob das Endgerät des Teilnehmers
DTMF-Töne als Ton im Medienstrom (inband), in speziellen RTP-Paketen
31
(rfc2833) oder als SIP INFO-Nachrichten (info) versendet.
5.4.2 Benutzerspezifische Parameter
Nachdem nun die allgemeinen Parameter für eingehende und abgehende SIPGespräche gesetzt sind, wollen wir nun Benutzer anlegen.
Diese werden in allen anderen Abschnitten der Datei angelegt, wobei der Name des Abschnitts gleichzeitig der Name der Benutzerkennung ist. Bei jeder
Kennung können die globalen Variablen context, disallow, allow und dtmfmode mit lokalen Werten überschrieben werden. Die lokalen Werte sind nur für
den jeweiligen Benutzer gültig.
Ein Beispiel für einen Benutzer könnte wie folgt aussehen:
[1234]
type = friend
username = 1234
secret = xxxx
host = dynamic
defaultip = 192.168.12.34
dtmfmode = rfc2833
mailbox = 1234
callgroup = 1
pickupgroup = 1
qualify = 200
canreinvite = no
context = default
accountcode = 1234
amaflags = documentation
Abbildung 5.8: SIP-Benutzer
Von allen möglichen Parametern sind nur die ersten vier zwingend notwendig,
um einen gültigen Benutzer anzulegen. Die übrigen Werte sind optional und
können bei Bedarf gesetzt werden.
type Gibt an, ob der Benutzer nur angerufen werden kann (user), nur abgehende Gespräche führen kann (peer) oder in beide Richtungen telefonieren kann (friend).
username Benutzername des Teilnehmers. Um Probleme mit diversen Clients zu vermeiden, sollte dieser Wert immer dem Namen der Kennung
entsprechen.
32
5.4. Einrichten der SIP-Teilnehmer
secret Klartext-Passwort des Teilnehmers. Alternativ kann das Passwort
verschlüsselt in der Variable md5secret abgelegt werden.
host IP-Adresse des Teilnehmers oder dynamic
md5secret Verschlüsseltes Passwort des Teilnehmers (s. auch Kapitel 5.8.1).
defaultip Falls das Endgerät des Teilnehmers nicht angemeldet ist, wird
versucht, ankommende Anrufe an diese IP-Adresse zu verbinden.
dtmfmode Gibt an, ob das Endgerät des Teilnehmers DTMF-Töne als Ton
im Medienstrom (inband), in speziellen RTP-Paketen (rfc2833) oder als
SIP INFO-Nachrichten (info) versendet.
mailbox Die Voicemailboxnummer des Teilnehmers. Diese Nummer wird
benötigt, um dem Endgerät des Teilnehmers signalisieren zu können,
dass neue Nachrichten in der Voicemailbox vorhanden sind.
callgroup Ordnet dem Teilnehmer eine oder mehrere callgroups zu. Anrufe zu Teilnehmern, die der callgroup x angehören, können von Teilnehmern, die sich in der pickupgroup x befinden mit der PickUp-Funktion
angenommen werden.
pickupgroup Ordnet dem Teilnehmer eine oder mehrere pickupgroups zu.
qualify Hier kann die maximal zulässige Latenzzeit in Millisekunden eingestellt werden. Wird diese Zeit überschritten, so wird ein Verbindungsaufbau abgelehnt. Sinnvolle Werte liegen zwischen 200 und 300. Größere Latenzen werden i.d.R. als störend empfunden.
canreinvite Gibt an, ob das Endgerät des Teilnehmers REINVITE-Nachrichten korrekt bearbeiten kann. Falls hier no gesetzt wird, so werden
alle Medienströme des Teilnehmers über den Server geleitet. Falls yes
gesetzt wird, wird versucht, die Medienströme direkt zwischen den Clients zu übertragen.
accountcode Gibt das Konto an, dem abgehende Anrufe des Teilnehmers
zugeordnet werden.
amaflags Gibt an, wie die Gesprächsdaten für Gespräche zum Teilnehmer
in den Abrechnungsdatensätzen markiert werden bzw. ob diese überhaupt erstellt werden. Relevante Werte sind:
billing — Datensätze als abrechnungsrelevant markieren
documentation — Datensätze als nicht abrechnungsrelevant markieren
nat Gibt an, ob sich der Teilnehmer evtl. in einem privaten Subnetz befindet.
fromuser Dieser String wird bei Anrufen zu diesem Teilnehmer anstatt der
CallerID als Absenderadresse verwendet.
33
callerid CallerID des Teilnehmers.
restrictid Gibt an, ob die CallerID des Teilnehmers bei abgehenden Gesprächen übermittelt werden soll.
language Gibt die Sprache an, die bei von diesem Teilnehmer ausgehenden
Gesprächen für Ansagen bevorzugt verwendet werden soll. Dieser Wert
wird außerdem dazu verwendet spezielle Signaltöne im für das angegebene Land typischen Format wiederzugeben.
incominglimit Dieser Wert gibt an, wieviele ankommende Gespräche der
Teilnehmer maximal gleichzeitig erhalten darf.
outgoinglimit Dieser Wert gibt an, wieviele abgehende Gespräche der
Teilnehmer maximal gleichzeitig führen darf.
5.4.3 Zugehöriger Rufnummernplan
Damit die jetzt eingerichteten Teilnehmer auch Anrufe tätigen können und
vor allem auch angerufen werden können ist noch ein entsprechender Rufnummernplan notwendig. Dieser wird in der Datei extensions.conf definiert. Der Rufnummernplan (auch Dialplan genannt) stellt die zentrale Stelle
von Asterisk dar, da hier die einzelnen Teilkomponenten wie VoIP-Teilnehmer,
Voicemail, Festnetzanbindung usw. miteinander verknüpft werden und das komplette Verhalten der Telefonanlage für ein- und ausgehende Gespräche definiert
wird.
Die Abschnitte der Datei extensions.conf werden als Kontexte bezeichnet, die jeweils Definitionen von Variablen und Rufnummern (sog. extensions)
enthalten können. Außerdem kann der Inhalt eines Kontextes mit der includeAnweisung in einen anderen eingebunden werden. Jeder Teilnehmer kann nur
die extensions in den Kontexten anrufen, die ihm mittels context zugeordnet
sind. Damit kann man z.B. unterschiedliche Berechtigungsstufen für abgehende Gespräche einrichten.
Nehmen wir an, dass wir neben dem Teilnehmer 1234 auch einen Teilnehmer
2345 angelegt haben und beiden der Kontext “default” zugeordnet wurde. Dies
ist auch der Kontext, wie wir ihn im Abschnitt [general] verwendet haben.
[default]
exten => 1234,1,Dial(SIP/${EXTEN})
exten => 2345,1,Dial(SIP/${EXTEN})
Abbildung 5.9: Einfache extensions.conf
34
5.5. Anbindung an das ISDN-Festnetz
Folglich benötigen wir auch in extensions.conf einen Kontext mit dem
Namen “default” (Abb. 5.9).
Die Bedeutung der einzelnen Parameter ist hierbei wie folgt: exten gibt an,
dass hier eine Rufnummer definiert wird. Danach wird die betreffende Rufnummer, also hier die Benutzerkennung des SIP-Teilnehmers, angegeben. Auf
die Rufnummer folgt eine Zahl, welche die Priorität der Anweisung angibt. Es
ist durchaus möglich und üblich, dass zu einer Rufnummer nacheinander verschiedene Dinge durchgeführt werden, wie z.B. Aktivieren einer Voicemailbox
wenn der Anruf nicht beantwortet wird. In diesem Fall hätte die Voicemailbox
eine höhere Priorität, da diese erst nach dem Anwahlversuch aufgerufen wird.
Zuletzt wird die auszuführende Anwendung angegeben. Hier wird mittels Dial
direkt der Teilnehmer angewählt. Dabei wird Dial über Parameter mitgeteilt,
mit welchem Protokoll (hier SIP) und zu welchem Teilnehmer eine Verbindung
hergestellt werden soll. Die Variable ${EXTEN} speichert automatisch immer
die aktuelle gewählte Rufnummer.
Weitere Funktionen des Dialplans werden in den nachfolgenden Abschnitten
und Kapiteln anhand der jeweiligen Szenarien erläutert.
5.5 Anbindung an das ISDN-Festnetz
Den nun eingerichteten VoIP-Teilnehmern soll auch der Zugang zum Festnetz
gewährt werden. Dabei ist auch auf die entsprechenden Berechtigungen für
abgehende Gespräche zu achten.
5.5.1 Installation
Zur ISDN-Anbindung wird wie bereits erwähnt eine Fritz!CardPCI verwendet, die unter Linux mit den CAPI-Treibern des Herstellers AVM betrieben
wird. Neben der CAPI-Unterstützung im System wird auch ein CAPI-Modul
(chan_capi) für Asterisk benötigt. Dieses wird von Klaus-Peter Junghanns entwickelt [28] und ist – wie Asterisk – unter GPL erhältlich. Mit diesem Modul
ist es möglich, aktive und passive ISDN BRI-Karten die CAPI 2.0-fähig sind,
zu betreiben. Chan_capi wird nach erfolgter Asterisk-Installation kompilieret und installiert. Anschliessend kann die CAPI-Unterstützung in der Datei
capi.conf konfiguriert werden (Abb. 5.10).
Auch hier gibt es wie bereits in sip.conf gesehen einen [general]-Abschnitt,
der die globalen Parameter konfiguriert. Mit den ersten beiden Variablen wird
eine ggf. zu wählende Vorwahl zur Amtsholung (üblicherweise ’0’) konfiguriert. rxgain und txgain können dazu verwendet werden, um mögliche auftretende Echos zu kompensieren.
35
[general]
nationalprefix = 00
internationalprefix = 000
rxgain = 0.8
txgain = 0.8
[interfaces]
msn = 3841
incomingmsn = 3841
context = default
softdtmf = 0
controller = 1
devices = 2
Abbildung 5.10: capi.conf
Die eigentliche Konfiguration des Anschlusses geschieht im Abschnitt [interfaces]. Um die auf der ISDN-Leitung zu verwendende MSN bei abgehenden
Gesprächen zu setzen, wird die Variable msn verwendet. Dabei können auch
mehrere durch Kommata getrennte MSNs angegeben werden. Die eigentliche Rufnummer (MSN) auf der eingehende Gespräche signalisiert werden
und die Asterisk auch entgegennehmen soll wird mittels incomingmsn definiert. Es können hier ebenfalls wieder eine oder mehrere MSNs angegeben
werden oder mittels * alle MSNs entgegengenommen werden. Wie auch in
sip.conf wird mittels context der Defaultkontext für eingehende Gespräche gesetzt. Ob DTMF-Töne von Asterisk (softdtmf=1) oder von der ISDNKarte selbst (softdtmf=0) generiert werden sollen hängt von der verwendeten
ISDN-Karte ab. Zuletzt muss noch die zu verwendende ISDN-Karte (controller) angegeben werden. Da eine ISDN-Karte üblicherweise zwei B-Kanäle hat,
ist devices auf ’2’ gesetzt.
5.5.2 Rufnummernplan mit Berechtigungsstufen
Bevor wir uns mit dem Einrichten der Berechtigungsstufen beschäftigen, werfen wir zuerst einen genaueren Blick auf die Arbeitsweise des Rufnummernplanes.
Die Funktionsweise der extensions
Extensions (d.h. Rufnummern) werden wie bereits gesehen mit der exten-Anweisung definiert. Damit kann einer Extension eine oder mehrere Anwendungen zugeordnet werden, die in einer bestimmten Reihenfolge abgearbeitet wer-
36
den. Die Reihenfolge wird dabei durch sog. Prioritäten festgelegt. Die Syntax
einer exten-Anweisung sieht wie folgt aus:
exten => Extension, Priorität, Anwendung, Argumente
oder
exten => Extension, Priorität, Anwendung (Argumente)
Es müssen jedoch nicht alle Extensions explizit angegeben werden. Statt dessen kann man sog. Patterns verwenden, die mit dem Zeichen ’_’ eingeleitet
werden. Mit diesen Pattern können z.B. festgelegte Ziffernbereiche gebildet
werden, beispielsweise mit [14-6], was eine der Ziffern 1, 4, 5, 6 ergibt.
Weiterhin haben folgende Zeichen besondere Bedeutungen:
X
N
Z
.
Kurzschreibweise für [0-9]
beliebig viele weitere Zeichen (nur am Ende eines Patterns)
Die aktuelle Extension wird in der Variable ${EXTEN} gespeichert und kann
wie bereits gesehen als Argument für eine Anwendung verwendet werden.
Sollten mehrere Patterns mit einer bestimmten Nummer übereinstimmen, wird
immer die exakteste Übereinstimmung verwendet. Abbildung 5.11 zeigt einen
Ausschnitt eines Rufnummernplanes, der Pattern und mehrere Anwendungen
mit verschiedenen Prioritäten verwendet.
[ankommend]
exten => _302123X,1,Busy
exten => _302XXXX,1,Dial(SIP/${EXTEN:3},20)
exten => _302XXXX,2,Voicemail(u${EXTEN:3})
exten => _302XXXX,102,Voicemail(b${EXTEN:3})
exten => 3023830,1,Dial(CAPI/@3841:${EXTEN:3})
Abbildung 5.11: Funktion der Extensions
Hier wurde nun ein Kontext “ankommend” definiert, der Rufnummern behandelt, die mit 302 beginnen und von weiteren vier Stellen gefolgt werden. Bei
ankommenden Anrufen zu Nummern, die dem Pattern 302XXXX entsprechen
und nicht dem Pattern 302123X oder 3023830, wird zuerst versucht den Teilnehmer per SIP zu erreichen.
37
exten => _302XXXX,1,Dial(SIP/${EXTEN:3},20)
Die Dial-Anwendung versucht einen bestimmten Teilnehmer anzuwählen. Das
erste Argument gibt an, mit welchem Protokoll der Teilnehmer zu erreichen ist.
Dabei können auch mehrere Möglichkeiten angegeben werden. Dial versucht
dann alle gleichzeitig anzuwählen. In diesem Beispiel soll ${EXTEN:3} über
SIP angerufen werden. ${EXTEN:3} entspricht dem Inhalt der Variable ${EXTEN}, wobei die ersten drei Zeichen abgeschnitten werden. Verwendet wird
dies beispielsweise, wenn die angewählte Rufnummer ankommend mit voller Länge (wie einer Rufnummer mit Durchwahl) signalisiert wird, man selbst
aber intern nur die Durchwahlen verwendet. Das zweite Argument ist optional.
Es gibt an, nach wie vielen Sekunden Dial den Anwahlversuch abbricht.
Dial beendet sich entweder, wenn das angegebene Timeout abgelaufen ist oder
wenn der Anschluss des angerufenen Teilnehmers besetzt ist. Im ersten Fall
wird die Priorität n+1 angesprungen, bei Besetzt die Priorität n+101.
exten => _302XXXX,2,Voicemail(u${EXTEN:3})
Diese Priorität wird also dann ausgeführt, wenn das Timeout von 20 Sekunden
abgelaufen ist. In diesem Beispiel wird der Anrufer an die Voicemailbox des
Teilnehmers weitergeleitet. Das “u” im Argument von Voicemail gibt hier an,
dass eine Ansage des Typs “unavailable” abgespielt werden soll.
exten => _302XXXX,102,Voicemail(b${EXTEN:3})
Analog funktioniert dies bei Besetzt (Priorität 102), mit dem einzigen Unterschied, dass hier eine andere Ansage vom Typ “b” (“busy”) abgespielt wird.
exten => _302123X,1,Busy
Bei Anrufen zu Nummern, die dem Pattern 302123X entsprechen, wird dem
Anrufer direkt ein Besetzt signalisiert.
exten => 3023830,1,Dial(CAPI/@3841:${EXTEN:3}
Diese Dial-Anweisung wählt über das CAPI-Interface (d.h. ISDN-Karte) aus
dem Server heraus. Wie auch in dem obigen Beispiel ist das erste Argument
das zu verwendende Protokoll, wobei die Syntax bei CAPI etwas unterschiedlich zu den anderen Protokollen ist. Hier kann wie im ISDN üblich noch die
auf der ISDN-Leitung zu verwendende MSN mit angegeben werden, in diesem
38
Beispiel die 3841. Anschliessend folgt wie gewohnt die zu wählende Rufnummer.
Weiterhin gibt es noch einige Extensions mit besonderer Bedeutung (Tabelle
5.1).
Extension
s
Name
start
t
timeout
i
invalid
o
operator
h
hangup
Erklärung
Wird ausgeführt, wenn keine Extension bekannt
ist (z.B. bei Analogleitungen).
Wird ausgeführt, wenn beim Versuch eine
Extension zu erhalten ein Timeout
eingetreten ist.
Wird ausgeführt, wenn die erhaltene Extension
unbekannt ist.
Wird ausgeführt, wenn der Anrufer beim
Voicemail-System die 0 wählt.
Wird ausgeführt nachdem ein Gespräch beendet
wurde.
Tabelle 5.1: Besondere Extensions
Berechtigungsstufen
Je nach Teilnehmer will man diesen unterschiedliche Berechtigungen für abgehende Gespräche zuweisen. Wie bereits gesehen besteht die Möglichkeit,
jedem Teilnehmer einen eigenen context zuzuweisen. Mit deren Hilfe besteht
nun die Möglichkeit durch eine Aufteilung verschiedener Rufnummernbereiche auf verschiedene Kontexte derartige Abstufungen zu erreichen. Angenommen, wir wollen einige Benutzer nur auf saarländische Vorwahlen beschränken
und anderen deutschlandweite Anrufe gestatten. Hierzu legen wir zwei Kontexte [saar] und [dland] an.
Um die Arbeit ein wenig zu erleichtern und auch den Rufnummernplan übersichtlicher zu gestalten, gibt es die Möglichkeit include-Anweisungen zu verwenden. Die einfachste Form dieser Anweisung besteht z.B. in
[dland]
include => saar
include => trunk-dland
include-Anweisungen können aber auch so verwendet werden, dass sie nur zu
bestimmten Uhrzeiten gültig sind. Das Format sieht dann wie folgt aus:
include => Kontext | Wochentage | Uhrzeiten
| Tage des Monats | Monate
39
Hierbei müssen alle Bedingungen erfüllt sein, damit die include-Anweisung
wirksam wird. Die einzelnen Werte können entweder numerisch oder als Abkürzung der entsprechenden englischen Wörter angegeben werden. Mehrere
Werte können entweder durch Kommata getrennt aufgelistet werden oder als
Bereiche angegeben werden (z.B. 1-4). Außerdem kann das Zeichen ’*’ als
Platzhalter für alle Werte verwendet werden.
[ankommend]
include => geschlossen | Sat-Sun | * | *
include => geschlossen | Mon-Fri | 4pm-8am | * | *
include => betriebsferien | * | * | 24-31 | Dec
include => offen | Mon-Fri | 8am-4pm | * | *
Abbildung 5.12: Das Include-Statement
Diese Funktion kann dazu genutzt werden um z.B. außerhalb der Geschäftszeiten eine Ansage abzuspielen, anstatt Anrufer an Telefone durchzustellen.
Außerdem wird es dadurch möglich, abgehende Gespräche nur zu bestimmten
Zeiten zu erlauben bzw. zu bestimmten Zeiten nur nach Eingabe einer PINNummer zu erlauben.
Die Berechtigungsstufen selbst sind nun recht einfach zu erstellen: für jede
benötigte Abstufung erstellt man einen eigenen Kontext der nur Rufnummern
nach bestimmtem Muster akzeptiert. Diese können dann nach Bedarf in weitere Kontexte inkludiert werden.
[trunk-saar]
exten => _0004968.,1,SetAccount(capi-saar)
exten => _0004968.,2,Dial(CAPI/@42:00${EXTEN:5})
exten => _0004968.,3,Congestion
exten => _0004968.,103,Congestion
Abbildung 5.13: Berechtigungsstufen
Damit bei einer ggf. später stattfindenden Abrechnung anhand der Logdateien von Asterisk nachvollzogen werden kann, unter welcher Berechtigung der
Anruf getätigt wurde, wird mit SetAccount ein Bezeichner für den Logeintrag
gesetzt. Im Anschluss wird der Anruf über das CAPI-Interface initiiert, wobei
@42 die auf dem ISDN-Bus zu verwendende MSN angibt.
40
5.6. Voicemail
5.6 Voicemail
Unsere VoIP-Teilnehmer sind nun auch aus dem Festnetz erreichbar – sofern
der Teilnehmer auch angemeldet ist und Anrufe beantwortet. Sollte dies einmal
nicht der Fall sein, so soll jedem Teilnehmer eine Voicemailbox zur Verfügung
stehen, die dann die eingehenden Gespräche entgegennimmt.
Die Verwaltung der Voicemailboxen geschieht in der Datei voicemail.conf.
Asterisk bietet die Möglichkeit, Voicemails entweder nur über eine Mailbox
(d.h. am Telefon) abzurufen oder sie zusätzlich per Email (im .wav oder .gsmFormat) an den betreffenden Benutzer zuzustellen. Auch hier gibt es wieder
einen globalen Konfigurationsabschnitt der die allgemeinen Parameter regelt.
[general]
format = wav
maxmessage = 180
serveremail = [email protected]
attach = yes
fromstring = Voicemail
emailbody = Sie haben eine neue Voicemail.
Abbildung 5.14: Allgemeine Parameter in voicemail.conf
format Dies definiert das zu verwendende Dateiformat, in dem Voicemails
aufgezeichnet werden sollen. Möglich sind wav, gsm und wav49. Es
können auch mehrere durch | (“oder”) getrennte Formate angegeben
werden.
maxmessage Um die maximal mögliche Länge (in Sekunden) einer Nachricht zu beschränken, kann dieser Parameter verwendet werden.
serveremail Absenderadresse für die Benachrichtigung per Email
attach Gibt an, ob der Benachrichtigung auch die betreffende Nachricht als
Anhang beigefügt werden soll.
fromstring Betreff der Benachrichtigungsemail.
emailbody Body der Email. Hier stehen noch weitere Variablen durch Asterisk zur Verfügung, mit denen z.B. die Uhrzeit, Dauer der Nachricht,
Telefonnummer des Anrufers usw. eingefügt werden kann.
Die Definition der einzelnen Mailboxen geschieht in Voicemailkontexten im
Anschluss an diesen Abschnitt. Hierbei wird folgende Syntax verwendet:
41
<Mailbox> => <Passwort>,<Name>,<Email>,<pager_email>,
<Optionen>
Mailbox bezeichnet die Nummer der entsprechenden Mailbox. Diese muss
nicht mit der eigentlichen Rufnummer übereinstimmen, es empfiehlt
sich aber aus Gründen der Übersichtlichkeit hier die gleiche Nummer
zu verwenden.
Passwort ist eine numerische PIN zur jeweiligen Voicemailbox und kann
auch später vom Benutzer im Voicemenu der Mailbox jederzeit geändert
werden.
Name ist der Name des Besitzers der Voicemailbox.
Email An diese Adresse werden Benachrichtigungen über neue Voicemails
versandt.
pager_email Asterisk kann auch Benachrichtigungen über neue Voicemails an einen Pager versenden. Benötigt man diese Funktion nicht, so
kann man das Feld leer lassen.
Optionen Hier können nun weitere Optionen für den jeweiligen Benutzer
gesetzt werden. An dieser Stelle können z.B. auch wieder global gesetzte
Werte für spezielle Benutzer mit neuen Werten überschrieben werden.
Konkret sehen dann die Benutzereinträge wie in Abb. 5.15 aus. Es sind hier
zwei Voicemailboxen für zwei Benutzer angelegt, wobei Mailbox 1234 in der
Benachrichtigungsemail kein Anhang mit der aufgezeichneten Nachricht beigefügt wird.
[default]
1234 => 4242,Maik Schmitt,maik@localhost„attach=no
2345 => 2323,Rainer Jochem,rainer@localhost
Abbildung 5.15: Einrichten der Voicemailboxen
Zu guter letzt werden noch Einträge in der extensions.conf benötigt, die
Anrufe auf die Voicemailbox weiterleiten, sobald der Anschluss des Angerufenen besetzt ist oder der Anruf nicht beantwortet wird. Wie derartige Konfigurationen aussehen wurde bereits in Abbildung 5.11 gezeigt.
5.7 Sonstige Funktionen im Rufnummernplan
Wir verfügen jetzt also über ein System, das mehrere SIP-Benutzer besitzt und
ihnen mit verschiedenen Berechtigungsstufen Zugang zum Festnetz gewährt.
42
5.7. Sonstige Funktionen im Rufnummernplan
Desweiteren hat jeder Teilnehmer eine eigene Voicemailbox und kann Faxe
empfangen.
Zu den verbleibenden Funktionen gehören Konferenzräume, Erreichbarkeit
der Teilnehmer sowie ENUM-Anfragen bei abgehenden Gesprächen. Diesen
Funktionen wollen wir uns nun in diesem Abschnitt widmen.
5.7.1 Konferenzräume
Asterisk bietet die Möglichkeit relativ einfache Konferenzräume einzurichten.
Die Konferenzräume werden in der Datei meetme.conf verwaltet (s. Abb.
5.16) Dabei gibt die erste Zahl die Nummer der Konferenz an und die zweite
eine optionale PIN für die entsprechende Konferenz.
[rooms]
conf => 6589 ; Konferenz ohne PIN
conf => 1234,4321 ; Konferenz mit PIN
Abbildung 5.16: Konferenzräume
Die so generierten Konferenzräume können dann im Rufnummernplan mittels
exten => 4242,1,MeetMe(6589)
einer Rufnummer zugewiesen werden.
5.7.2 Erreichbarkeit der Teilnehmer
Bisher wurde nur beschrieben, wie die SIP-Teilnehmer in das Festnetz anrufen können, eingehende Anrufe aus dem Festnetz wurden jedoch noch nicht
betrachtet. Jeder Teilnehmer ist über eine gültige Nebenstellenrufnummer der
Telefonanlage erreichbar, welche von dieser über eine E1-Leitung zu einem
Asterisk-Server im Rechenzentrum signalisiert wird. Dieser Server setzt die
eingehenden ISDN-Anrufe in VoIP-Gespräche um und leitet diese an den Asterisk-Server des Lehrstuhls weiter (vgl. Abb. 5.2). Die Anbindung zur Telefonanlage über die E1-Schnittstelle wird später eingehend in Kapitel 7 beschrieben. Somit laufen alle eingehenden Gespräche als VoIP-Verbindungen
auf dem Server auf und sind dadurch sehr leicht zu verwalten, da sie direkt zu
den betreffenden Teilnehmern signalisiert werden können.
43
5.7.3 ENUM
An dieser Stelle sei auf Kapitel 7 verwiesen, da die dort verwendete Konfiguration im wesentlichen auch hier zutrifft. Allerdings bedarf es für das Thema
ENUM eines eigenen Kapitels, weswegen hier auf eine Betrachtung verzichtet
wird.
5.8 Asterisk-Patches
Im Verlauf der Nutzung von Asterisk wurden von uns auch Patches und Erweiterungen erstellt, die im folgenden beschrieben werden. Dies ist zum einen die
Verwendung MD5-verschlüsselter SIP-Passwörter in sip.conf, sowie das
Erstellen eines Webinterfaces, das SIP-Teilnehmern ermöglicht ihr Passwort
zu ändern.
5.8.1 Verschlüsselte SIP-Passwörter
Asterisk hatte bisher in der SIP-Konfiguration noch eine sicherheitskritische
Schwachstelle: Die Konfigurationsdatei für die SIP-Benutzer liegt in Form
einer Text-Datei (/etc/asterisk/sip.conf) vor. Hierin werden zum
einen die Benutzerpasswörter im Klartext in der Variablen secret abgelegt und
sind weiterhin auch nicht durch die Benutzer selbst veränderbar.
Eine Lösung für dieses Problem besteht darin, aus MD5-Hashes (bestehend
aus benutzername:asterisk:passwort) gebildete Passwörter (md5secret) zu verwenden. Dies ist aufgrund des im SIP-Protkoll verwendeten Algorithmus (Digest-Authentication, ähnlich zu HTTP) die einzige Möglichkeit, das Passwort
zu verschlüsseln.
[1234]
type = friend
username = 1234
md5secret = 3d8c8fed907f666bg8a226d0f7f53a42
host = dynamic
dtmfmode = rfc2833
mailbox = 1234
canreinvite = no
context = international
Abbildung 5.17: Beispiel für die Verwendung von md5secret
Um nun diese verschlüsselten Passwörter mit Asterisk zu verwenden, wurde
44
5.8. Asterisk-Patches
ein patch für chan_sip.c geschrieben, der eine neue Variable md5secret in der
sip.conf einführt (siehe Abb. 5.17). Die Funktionsweise ist hierbei wie folgt:
Ist lediglich die Variable secret, d.h. ein Klartextpasswort, definiert, so verhält
sich Asterisk wie üblich, ist md5secret definiert, so wird stets dieses benutzt.
Der Patch wurde zwischenzeitlich in das offizielle CVS aufgenommen und ist
somit Bestandteil von Asterisk.
5.8.2 Erstellen eines Benutzerinterfaces
Um schliesslich den Benutzern eine Möglichkeit der Passwortänderung zu geben, wurde ein Webinterface (Abb. 5.18) entwickelt, auf das per https zugegriffen werden kann. Hier kann jeder Benutzer sein Passwort ändern, welches vom Webinterface als MD5-Hash in einer MySQL-Datenbank gespeichert wird. Die Verwendung der Datenbank wurde gewählt, um mögliche Kollisionen beim gleichzeitigen Zugriff mehrerer Benutzer auf das Webinterface
zu vermeiden. Desweiteren wird somit gewährleistet, dass der Webserver (in
diesem Fall apache) keinen direkten Zugriff auf die SIP-Konfigurationsdateien
von Asterisk benötigt. Der durch die Verwendung der MySQL-Datenbank notwenige Datenabgleich mit Asterisk wird durch ein Perl-Skript gewährleistet,
das minütlich von Cron ausgeführt wird. Wird von diesem Skript eine Passwortänderung in der Datenbank festgestellt, erfolgt eine automatische Änderung
der Konfigurationsdatei und es wird ein Reload von Asterisk initiiert. Ein direkter Datenbankzugriff durch Asterisk selbst befindet sich derzeit erst in der
Entwicklung.
Abbildung 5.18: Benutzerinterface
45
Kapitel 6
Studentenserver
6.1 Anforderungen
Ziel ist es, den Studenten als zusätzlichen Service (neben Email, Internetzugang, usw.) auch Voice over IP anzubieten. Hierzu soll jedem Student/-in eine SIP-Adresse zugeordnet werden mit der VoIP-Gespräche geführt werden
können und weiterhin jeder beliebige Uni-interne Telefonapparat angewählt
werden kann. Zusätzlich soll es auch möglich sein, den VoIP-Anschluss eines
Studenten aus dem Festnetz zu erreichen. Zur vereinfachten Nutzbarkeit soll
die bestehende Benutzerkennung, die jeder Student bei der Immatrikulation
erhält, als SIP-Kennung verwendet werden.
Da es sich um eine grosse Anzahl an Studenten handelt und weiterhin keine besonderen Dienste (Konferenzen, Fax, etc.) benötigt werden, ist zu diesem Zweck zusammen mit dem Rechenzentrum der SIPExpress-Router von
iptel.org ausgewählt worden.
6.2 Umsetzung
Um die am SER-Server angemeldeten Benutzer aus dem Festnetz erreichen
zu können, müssen diese über eine ”Telefonnummer” verfügen. Da es derzeit
nicht möglich ist, echte Telefonnummern zu vergeben, bietet sich hier die folgende Lösung an:
Um für jeden Benutzer eine eindeutige ”Rufnummer” zu erhalten, wird die
Alias-Funktion von SER verwendet. Dies bedeutet, dass zu jeder SIP-Adresse
der Form sip:[email protected] ein entsprechender numerischer Eintrag der Form sip:[email protected] existiert.
46
6.2. Umsetzung
Diese numerischen Aliase (z.B. 1234) können nun auch an einem gewöhnlichen Telefonapparat gewählt werden. Benötigt wird aber immer noch eine
Verbindung zwischen dem Festnetz und dem SER-Server, die zum einen den
Festnetzanschluss an sich und die Umsetzung des per Telefon gewählten Alias zu einer gültigen SIP-Adresse (sip:[email protected])
vornimmt.
Hierzu wird ein an die TK-Anlage der Universität angeschlossener AsteriskServer verwendet. Dieser ist über eine öffentliche Durchwahl (68698) aus dem
ISDN erreichbar. Wählt man diese Rufnummer an, so baut man eine Verbindung zu einem IVR-System im Asterisk-Server auf und kann hier nun den
Alias des gewünschten Gesprächpartners am Telefon eingeben. Der AsteriskServer baut dann eine VoIP-Verbindung (über SIP) zum SER-Server auf und
verbindet dann (sofern der Gesprächspartner erreichbar ist) die beiden Teilnehmer miteinander.
Abbildung 6.1: Testaufbau
Ähnlich kann so auch ermöglicht werden, dass am SER-Server angemeldete Benutzer Nebenstellen der universitären TK-Anlage erreichen können: Die
47
KAPITEL 6. Studentenserver
Benutzer brauchen lediglich die Nummer der gewünschten Nebenstelle zu
wählen (z.B. 3841) und der Anruf wird über den Asterisk-Server in die TKAnlage weitergeleitet. Zuvor findet natürlich eine Überprüfung statt, ob es sich
auch um eine gültige Nebenstellenrufnummer handelt, so dass ausschliesslich
diese Anschlüsse erreicht werden können.
Zuletzt wird noch für die Benutzerverwaltung, d.h. Anmelden neuer Benutzer, Ändern des Passwortes, ein geeignetes Webinterface für den SER-Server
benötigt.
6.3 Konfiguration
Um den Studentenserver nutzen zu können, müssen im wesentlichen drei Dinge konfiguriert werden. Zum einen SER selbst, dann der Asterisk-Server der
die ISDN-Anbindung übernimmt und es müssen noch bestimmte Einträge im
Domain-Name-System (DNS) gesetzt werden, damit der Studentenserver erreichbar ist.
6.3.1 SER
Für den Betrieb des Studentenservers wurde ein Debian-basierter Linux-Server
eingerichtet, auf dem neben SER auch MySQL für die Benutzerverwaltung
und Apache-SSL für das Webinterface installiert wurden.
Nach der Installation von SER wurden die benötigten Datenbankbenutzer sowie die Datenbank und Tabellen angelegt. Hierfür müssen die einzelnen Parameter im mitgelieferten Skript (/usr/sbin/ser_mysql.sh) gesetzt werden. Anschliessend kann mit der eigentlichen Konfiguration von SER begonnen werden.
Zunächst sei eine grobe Übersicht über den Aufbau der Konfigurationsdatei
gegeben. SER verwendet eine einzige Datei (ser.cfg), die eine C-ähnliche
Syntax verwendet und im wesentlichen aus vier Abschnitten besteht.
Globale Parameter: Diese bestimmen das allgemeine Verhalten der Servers
wie z.B. Portnummer oder Loglevel.
Module: Hier werden externe Module wie z.B. ENUM oder MySQL eingebunden. Sollten Module voneinander abhängen, so müssen die Module
in der Reihenfolge aufgelistet werden, wie die Abhängigkeiten bestehen.
Modulspezifische Parameter: An dieser Stelle können einzelne Module genauer konfiguriert werden (wie z.B. Datenbankparameter, ENUM-Domain, ...)
48
6.3. Konfiguration
Routing-Blocks: Es können ein oder mehrere Routing-Blocks angegeben werden, die die Logik für ein- und ausgehende Nachrichten beschreiben.
Gegenüber der Default-Konfiguration musste lediglich die Routing-Logik wie
folgt den eigenen Bedürfnissen angepasst werden. Alle übrigen Parameter wurden unverändert übernommen und werden daher hier nicht betrachtet.
Da dieser Server für verschiedene Realms (derzeit stud.uni-saarland.de, rz.unisaarland.de) zuständig ist, muss dies SER mittels des alias-Parameters
(alias="rz.uni-saarland.de") mitgeteilt werden. Weiterhin muss die
Verwendung der Benutzeraliase aktiviert werden. (lookup("aliases");).
Die zweite Änderung betrifft das Wählen von Festnetzrufnummern von SER
aus. Damit dies vom Endgerät (SIP-Telefon) des Benutzers aus möglichst einfach funktioniert (d.h. lediglich die Festnetzrufnummer der Nebenstelle eingegeben werden muss), wird hierzu das ENUM-Modul von SER verwendet.
if (method=="INVITE" or method=="CANCEL" or method=="BYE") {
if (uri=˜"^sip:\+.*" or uri=˜"^sip:\*.*") {
if (enum query("")) {
if (!t relay()) {
sl reply error();
};
break;
};
};
10
if (uri=˜"^sip:[2-5]. . .@.*uni-saarland\.de"
or uri=˜"^sip:7[1-2]. .@.*uni-saarland\.de"
or uri=˜"^sip:6. . .@.*uni-saarland\.de"
or uri=˜"^sip:6. . . .@.*uni-saarland\.de"
or uri=˜"^sip:19@.*uni-saarland\.de"
or uri=˜"^sip:0@.*uni-saarland\.de") {
forward(134.96.6.9);
break;
};
};
20
Abbildung 6.2: ENUM-Routing in ser.cfg
Dabei geschieht folgendes: Wird eine SIP-URI gewählt, die mit + oder *
beginnt, so findet eine ENUM-Anfrage statt. Wenn diese erfolgreich ist ( if
(enum_query(“”)) ), so wird versucht diese URI direkt anzuwählen. Falls diese
Vermittlung fehlschlägt, wird dem Client eine entsprechende Fehlermeldung
signalisiert. Andernfalls wird geprüft, ob es sich bei der gewählten SIP-URI
49
KAPITEL 6. Studentenserver
um eine lokale Rufnummer der TK-Anlage handelt. Ist dies der Fall, so wird
ein SIP-Anruf mit dieser Adresse an den Asterisk-Server (134.96.6.9) eingeleitet. Ansonsten wird versucht, die gewählte URI direkt anzurufen. Zur genauen
Funktionsweise von ENUM sei auf Kapitel 7 verwiesen.
Sonstige Änderungen der Konfigurationsdatei waren nicht erforderlich.
6.3.2 Asterisk
Bei dem hier verwendeten Asterisk-Server handelt es sich um das gleiche System, das auch die ENUM-Anbindung übernimmt. Aus diesem Grund sei für
die Konfiguration der Anbindung zur TK-Anlage auf Kapitel 7 verwiesen.
An dieser Stelle sei lediglich auf den Abschintt des Rufnummernplanes von
Asterisk eingegangen, der für die Verbindung von ISDN und SER dient.
exten
exten
exten
exten
exten
=>
=>
=>
=>
=>
s,1,Answer
s,2,Wait(1)
s,3,DigitTimeout(5)
s,4,ResponseTimeout(10)
s,5,BackGround(durchwahl)
exten
exten
exten
exten
exten
=>
=>
=>
=>
=>
_XXXXX,1,Dial(SIP/[email protected])
_XXXXX,2,PlayBack(nichterreichbar)
_XXXXX,3,Hangup
_XXXXX,102,PlayBack(nichterreichbar)
_XXXXX,103,Hangup
Abbildung 6.3: Einwahl ISDN - SER
Abbildung 6.3 zeigt den entsprechenden Ausschnitt der extensions.conf.
Zunächst wird der vom ISDN eingehende Anruf mit Answer angenommen.
Während im Hintergrund eine Ansage (”durchwahl”) vorgespielt wird, die den
Benutzer auffordert den gewünschten Alias einzugeben, wartet Asterisk auf
die Eingabe der Rufnummer. Dabei gibt DigitTimeout an, wie viele Sekunden
zwischen den einzelnen Ziffern zu warten ist, bis die eingegebene Rufnummer
interpretiert wird. Ist nach 10 Sekunden noch keine Eingabe erfolgt (ResponseTimout), wird die Verbindung beendet.
Wurden vom Benutzer fünf Ziffern eingegeben, tritt das Pattern _XXXXX in
Kraft und Asterisk versucht diese als SIP-Rufnummer am SER-Server anzuwählen. Schlägt dies fehl, weil z.B. der Teilnehmer nicht online ist oder der
Anschluss besetzt ist, so wird eine Fehleransage (”nichterreichbar”) abgespielt
und das Gespräch beendet.
50
6.4. Webinterface
Verbindungen in die ”andere” Richtung, d.h. von SER zur TK-Anlage funktionieren hier wie alle anderen per VoIP vom Inter-/Intranet eingehenden Gespräche auch und sind in Kapitel 7 beschrieben.
6.3.3 DNS
Damit die Benutzer ihre bestehende Email-Adresse auch als SIP-Adresse verwenden können, wurden im SER bereits Server-Aliase für die einzelnen EmailDomains (stud.uni-saarland.de, usw.) eingerichtet. Allerdings ist der eigentliche Server unter einer völlig anderen Domain im Netzwerk sichtbar. Um zu
ermöglichen, dass sich die Benutzer mit ihren Email-Domains trotzdem an
diesem anders lautenden Server anmelden können, werden sog. SRV-Records
im DNS benötigt.
_sip._udp SRV 0 0 5060 iptel.rz.uni-saarland.de.
Abbildung 6.4: SRV-Record
Diese müssen im Nameserver der betreffenden Domain eingetragen werden
und enthalten den Dienst (in diesem Falle SIP), die Portnummer (5060) und
verweisen auf den eigentlichen Server, der für diesen Dienst zuständig ist.
6.4 Webinterface
Iptel.org stellt zwar ein Webinterface für SER zur Verfügung, allerdings hat
sich dies für diesen Einsatzzweck als nicht geeignet herausgestellt.
Wie bereits erwähnt, sollen die bestehenden Email-Adressen als SIP-Adressen
verwendet werden, was zur Folge hat, dass viele unterschiedliche Domains
(z.B. stud.uni-saarland.de oder rz.uni-saarland.de usw.) zu beachten sind. Dies
ist insofern von Bedeutung, da diese Domains als sog. SIP-Realms Verwendung finden (entspricht der Funktion der Domain bei den Email-Adressen).
Leider ist aber das von Iptel.org verfügbare Webinterface nicht in der Lage
mehrere unterschiedliche Realms zu verarbeiten. Auch lässt sich das Webinterface nur sehr schlecht konfigurieren.
Aus diesen Gründen wurde ein eigenes Webinterface geschrieben, das alle
grundlegenden Funktionen bereitstellt: Anmelden, Passwort ändern sowie Anzeigen der Daten des eigenen Accounts. Es handelt sich hierbei um eine Reihe
von PHP-Skripten, die – wie auch das Webinterface von Iptel – auf die SERMySQL-Datenbank zugreifen und dort die Benutzerverwaltung durchführen.
51
Kapitel 7
ENUM
ENUM ist die Abkürzung für tElephone NUmber Mapping (RFC 2916 [29]).
Es definiert eine Vorschrift, mit der einer Telefonnummer in eindeutiger Weise
eine DNS-Domain zugeordnet wird. Anhand dieser Domain kann man mittels DNS-Anfragen ermitteln, auf welchen Wegen der gewünschte Teilnehmer
erreichbar ist.
Dies ist insbesondere für den Bereich der Telefonie interessant, da man hiermit eine Art Least-Cost-Routing (LCR) betreiben kann, bei der der Teilnehmer statt über Festnetz alternativ per VoIP zu wesentlich günstigeren Tarifen
erreicht werden kann.
7.1 public ENUM
Als public ENUM bezeichnet man das in RFC 2916 definierte öffentliche
ENUM-System, das unterhalb der Domain e164.arpa angeboten wird. Dieses
System wird oft auch einfach nur als ENUM bezeichnet. Zuständig für die Vergabe dieser offiziellen ENUM-Einträge sind die NICs des jeweiligen Landes,
für Deutschland also das DENIC [30].
Um eine Telefonnummer in eine public ENUM-Domain umzuwandeln, muss
die Telefonnummer im sogenannten E.164-Format vorliegen, bestehend aus
Vorwahl
Rufnummer .
+ Ländercode
+49 681 3023830
Die Ziffern der Rufnummer werden der Endung .e164.arpa in umgekehrter
Reihenfolge vorangestellt und jeweils durch Punkte getrennt.
0.3.8.3.2.0.3.1.8.6.9.4.e164.arpa
52
7.1. public ENUM
Über DNS-Anfragen kann die so gebildete Domain zu mehreren Naming Authority Pointer Records (NAPTR) aufgelöst werden. Diese Records enthalten
URIs zu den Services, die mit dieser Rufnummer verknüpft sind, sowie eine Abarbeitungsreihenfolge. Die URIs können unter anderem folgende Typen
haben:
mailto - Email Adresse an die z.B. Voicemails gesendet werden können.
http - Adresse einer Homepage, unter der weitere Informationen zu finden sind, wie der gewünschten Teilnehmer erreichbar ist.
sip/h323/iax2 - SIP-/H.323-/IAX2-Adresse, unter der der gewünschte
Teilnehmer direkt erreichbar ist.
tel - E.164-Rufnummer, unter der der gewünschte Teilnehmer erreichbar
ist.
Die URIs, die in den NAPTR-Records enthalten sind, müssen dabei nicht statisch sein. Mit Hilfe von regularären Ausdrücken kann die E.164-Rufnummer
teilweise oder komplett in der URI verwendet werden. Die Universität des
Saarlandes nimmt am ENUM-Testbetrieb des DENIC teil und hat in diesem
Rahmen vom DENIC für alle Rufnummern die mit +49 681 302 beginnen,
d.h. alle Nebenstellen der Universität, NAPTR-Records mit folgendem Inhalt
erhalten:
!
!
!
+49681302(.*)$!iax2:guest
@enum.rz.uni-saarland.de/ 1!
+49681302(.*)$!sip: 1
@enum.rz.uni-saarland.de!
+49681302(.*)$!h323: 1
@h323server.rz.uni-saarland.de!
! .*$!http://www.rz.uni-saarland.de/projekte/!
Bei den hier verwendeten regulären Ausdrücken werden die einzelnen Bestandteile durch Ausrufezeichen voneinander getrennt. Zwischen den ersten
beiden Ausrufezeichen steht der zu bearbeitende Rufnummernteil.
53
KAPITEL 7. ENUM
+49681302(.*)$
Dies betrifft also alle Rufnummern, die auf +49681302 beginnen und mit
beliebig vielen weiteren Stellen enden. Zwischen den nächsten beiden
Ausrufezeichen wird die Ersetzungsregel angegeben.
sip:
[email protected]
Hier wird die mit 1 gekennzeichnete Stelle durch den Teil der Rufnummer
ersetzt, der von (.*) erfüllt wird. Für die Rufnummer +49 681 302 1234 würden
sich daraus folgende URIs ergeben:
iax2:[email protected]/1234
sip:[email protected]
h323:[email protected]
http://www.rz.uni-saarland.de/projekte/
7.2 user ENUM
Als user ENUM bezeichnet man alle ENUM-Systeme die nicht unterhalb der
Domain e164.arpa angeboten werden. Es handelt sich hierbei also um keine
offiziellen, international gültigen ENUM-Einträge. Solche Systeme sind idR.
nur lokal zugänglich und werden hauptsächlich zum Least-Cost-Routing eingesetzt. So kann z.B. zu einer Telefonnummer eine tel-URI zurückliefert werden, die die gleiche Telefonnummer mit vorangestellter Netzbetreibervorwahl
enthält. User ENUM kann außerdem dazu verwendet werden, Durchwahlen
dynamisch auf mehrere Server zu verteilen. Hier wird z.B. zu einer Anfrage
eine sip-URI zurückgegeben aus der der Server, der für die Durchwahl zuständig ist, hervorgeht. Ein solches System ist vor allem bei größeren Installationen sinnvoll, da man damit die Rufnummernpläne nur an einer Stelle verwalten
muss.
Um eine Telefonnummer in eine user ENUM Domain umzuwandeln geht man
genau so vor wie bei public ENUM. Allerdings muss hier die Nummer nicht
im E.164-Format vorliegen und es wird üblicherweise eine andere Endung als
e164.arpa verwendet um Kollisionen mit dem public ENUM System zu vermeiden.
54
7.3. Umsetzung mit Asterisk
7.3 Umsetzung mit Asterisk
Um die Vorzüge von ENUM nutzen zu können wurde eine ENUM-fähige,
VoIP-taugliche Software benötigt, die außerdem in der Lage ist, eine Anbindung zum öffentlichen Telefonnetz möglichst mit E1-Interface herzustellen.
Die einzige Software, die diese Anforderungen derzeit erfüllen kann, ist Asterisk.
Aus diesem Grund wurde ein weiteres Asterisk-System im Rechenzentrum
installiert, das über eine TE410P-Karte [31] an die universitäre TK-Anlage
angeschlossen ist. Diese Karte verfügt über vier E1-Schnittstellen und wurde
von Digium speziell für die Verwendung mit Asterisk entwickelt.
7.3.1 Konfiguration des E1-Interfaces
Zunächst muss die Hardware im System eingerichtet und konfiguriert werden.
Hierzu werden die entsprechenden Kartentreiber benötigt, die separat aus dem
Asterisk-CVS (Modul zaptel) ausgecheckt werden müssen. Ist zaptel installiert, kann mit der Kartenkonfiguration begonnen werden. Die Konfigurationsdatei für die Karte lautet /etc/zaptel.conf und dient dazu, die Einstellungen für die einzelnen Ports der Karte zu setzen.
Die Syntax zur Definiton der einzelnen Ports lautet hierbei wie folgt:
span = <span num>,<timing>,<line build out (LBO)>,
<framing>,<coding>[,yellow]
<span num> bezeichnet die Portnummer und <timing> beschreibt, ob dieser
Port eine Timingquelle für Asterisk darstellt und, falls ja, mit welcher Priorität diese verwendet werden soll. Timingquellen dienen zur Synchronisation
der Kommunikation auf dem PRI-Interface. Mit <LBO> wird die Leitungsdistanz zum Übergabepunkt der PRI-Leitung in Schritten von ca. 40m angegeben. <framing> gibt die Einteilung der vorhandenen Kanäle auf die einzelnen
Zeitschlitze vor – für europäische PRI-Anschlüsse wird fast ausschliesslich ccs
verwendet. Das Übertragungsprotokoll für die jeweilige Leitung wird mit <coding> definiert und ist für E1-Leitungen üblicherweise hdb3,crc4. yellow weist
Asterisk an, bei festgestellten Fehlern auf der PRI-Leitung dies der Gegenstelle
mittels eines sogenannten “Yellow-Alerts” zu signalisieren. Eine vollständige
Zeile für ein E1-Interface sieht dann wie folgt aus:
span = 1,1,0,ccs,hdb3,crc4,yellow
55
KAPITEL 7. ENUM
Danach müssen die B- und D-Kanäle der einzelnen Ports definiert werden. Bei
europäischen E1-Leitungen befindet sich der D-Kanal normalerweise auf Port
16.
bchan=1-15
dchan=16
bchan=17-31
Anschliessend kann das Treibermodul für die E1-Karte geladen werden.
Die Zuordnung der einzelnen in /etc/zaptel.conf konfigurierten Kanälen zu verschiedenen Kontexten und die auf der Leitung zu verwendende Signalisierungsmethode wird in /etc/asterisk/zapata.conf festgelegt.
[channels]
pridialplan = unknown
overlapdial = yes
switchtype = euroisdn
usecallerid = yes
echocancel = yes
callerid = asreceived
signalling = pri_cpe
group = 1
context = vonpri
accountcode = pri
channel => 1-15,17-31
Abbildung 7.1: zapata.conf
pridialplan Bezeichnet die Art der Rufnummernübermittlung.
overlapdial Gibt an, ob Nachwahl von Ziffern auf dem Interface zugelassen wird.
switchtype ist das zu verwendende Signalisierungsprotokoll.
usecallerid Gibt an, ob Informationen über die CallerID zu übertragen
sind.
echocancel Aktiviert oder deaktiviert die Echounterdrückung.
callerid Legt die bei abgehenden Gesprächen zu verwendende CallerID
fest.
signalling Art der Signalisierung, u.a. Netzwerk- oder Kundenseite.
56
group Gruppe, in der die folgenden Kanäle gebündelt werden.
channel Kanäle der Gruppe.
7.3.2 Rufnummernplan
Abgehende Gespräche
Um ENUM mit Asterisk zu verwenden, muss eine entsprechende Logik im
Dialplan implementiert werden (siehe Abb. 7.2).
Abbildung 7.2: Rufablauf bei ENUM-Anfragen
In diesem Beispiel wird vorausgesetzt, dass die Teilnehmer die Ziffer 0 vorwählen müssen, um eine Rufnummer im Festnetz anzurufen.
57
KAPITEL 7. ENUM
[deutschland]
ignorepat => 0
exten => _0Z.,1,Goto(00049681${EXTEN:1},1)
exten => _00Z.,1,Goto(00049${EXTEN:2},1)
exten => _00049.,1,EnumLookup(${EXTEN:3})
Abbildung 7.3: Umformatieren der Rufnummer für ENUM-Anfrage
ignorepat bewirkt, dass weiterhin ein Wählton signalisert wird, wenn der Benutzer eine 0 wählt. Falls der Benutzer eine Nummer im gleichen Ortsnetz ohne Vorwahl bzw. eine Nummer mit nationaler Vorwahl anwählt, wird die Nummer ins internationale Format umgewandelt, um später eine gültige ENUMAnfrage stellen zu können.
EnumLookup sucht zu einer E.164-Rufnummer die passenden NAPTR-Records
und prüft, ob eine verwertbare URI enthalten ist. Falls eine tel-URI gefunden
wird, wird die Priorität n+51 angesprungen. Wird eine sip-, h323-, iax- oder
iax2-URI gefunden, so wird die Priorität n+1 angesprungen. In beiden Fällen
wird die URI in der Variable ${ENUM} gespeichert. Wenn keine verwertbare
URI gefunden werden kann, wird die Priorität n+101 angesprungen.
exten => _00049.,1,EnumLookup(${EXTEN:3})
exten => _00049.,2,Goto(1000)
exten => _00049.,1000,SetCIDNum
(+49681302${CALLERIDNUM}|a)
exten => _00049.,1001,Dial(${ENUM})
Abbildung 7.4: ENUM-Anfrage
EnumLookup hat eine verwertbare URI gefunden (Abb. 7.4). Um den Dialplan
übersichtlicher zu gestalten und Kollisionen bei den Prioritäten zu vermeiden
wird zuerst die Priorität 1000 angesprungen. Nun sollte die CallerID auf die
vollständige Rufnummer inkl. Ländercode gesetzt werden. Ansonsten würde
das angerufene Telefon nur die Durchwahl des Anrufers anzeigen (z.B. 1234
statt +496813021234). Anschliessend kann die gefundene URI angewählt werden.
58
exten => _00049.,1002,SetCIDNum
(${CALLERIDNUM:9}|a)
exten => _00049.,1003,Goto(2000)
exten => _00049.,1102,Busy
Abbildung 7.5: Nicht erfolgreicher VoIP-Anruf
Sollte die URI nicht erreichbar sein (z.B. wegen einer Störung im Netzwerk
oder einer falsch formatierten URI), wird die CallerID wieder auf den alten
Wert zurückgesetzt und es wird versucht, die Nummer direkt über das Festnetz anzurufen (Goto(2000), siehe Abb. 7.6). Sollte der angerufene Anschluss
besetzt sein, so wird dies entsprechend dem Anrufer signalisiert.
exten => _00049.,52,Goto(000${ENUM},2000)
EnumLookup hat eine tel-URI gefunden. Hier könnte man versuchen, einen
ENUM-Eintrag für die neue Rufnummer zu finden. Allerdings würde dies den
Rufaufbau erneut verzögern und es besteht die Möglichkeit, dass so eine Endlosschleife entsteht. Deshalb wird hier die neue Rufnummer direkt über das
Festnetz angerufen, wobei mit der Goto-Anweisung sichergestellt wird, dass
der Anrufer die benötige Berechtigung hat, um die neue Rufnummer anzurufen.
exten => _00049.,102,Goto(2000)
exten => _00049.,2000,Macro(dialout,0${EXTEN:5})
Abbildung 7.6: Anruf über das Festnetz
Hier wird ein Makro aufgerufen, dass die Telefonnummer über das Festnetz
anruft. Die Telefonnummer wird dabei so übergeben, wie sie auf der abgehenden Telefonleitung gewählt wird. Die Nummer enthält also nicht die zusätzliche 0, die der Anrufer wählen muss und außerdem wurde die Ländervorwahl
entfernt, da man deutsche Telefonnummern idR. nicht mit Ländervorwahl erreichen kann.
59
KAPITEL 7. ENUM
[macro-dialout]
exten
exten
exten
exten
exten
=
=
=
=
=
s,1,Dial(Zap/g1/${ARG1})
s,2,Dial(Capi/${ARG1})
s,3,Congestion
s,102,Busy
s,103,Busy
Abbildung 7.7: Wahl von Festnetzrufnummern
Dieses Makro versucht zunächst die Nummer über ein Zaptel-Interface anzurufen (dies könnte z.B. eine S2M-Leitung sein). Sollte diese Leitung gestört sein
oder alle Kanäle belegt sein, wird versucht den Anruf über ein Capi-Interface
durchzustellen. Ist dieser Anschluss ebenfalls gestört bzw. alle Kanäle belegt,
so wird dem Anrufer ein sog. Gassenbesetzt signalisiert.
Bei manchen Verbindungen ist es evtl. nicht erwünscht, dass eine ENUMAnfrage gestellt wird (z.B. bei Störungen im Netz oder bei fehlerhaften ENUMEinträgen). Daher sollte man auch eine Möglichkeit vorsehen, diese zu umgehen.
exten =
_*00*.,1,Goto(${EXTEN:4},2000)
Abbildung 7.8: Vorwahl, um ENUM-Anfrage zu umgehen
Alle Rufnummern, denen *00* vorangestellt wurde, werden direkt über das
Festnetz angewählt, wobei durch die Goto-Anweisung sichergestellt ist, dass
die Rufnummer im korrekten Format gewählt wird.
Ankommende Gespräche
Weiterhin dient dieser Server auch als Anlaufstelle für Gespräche, die über
ENUM per VoIP eingehen – sei es aus dem internen Netz der Universität oder
aus dem Internet. In diesen Fällen muss der Server die Gespräche zu den entsprechenden Teilnehmern, beispielsweise über ISDN in die TK-Anlage, weiterleiten. Auch hier werden wieder Berechtigungsstufen verwendet über die
sichergestellt wird, dass ausschließlich gültige Nebenstellen der Universität
erreichbar sind. Anschließend können diese Anrufe direkt an die TK-Anlage
weitergeleitet werden.
60
7.4. Erweiterung von TK-Anlagen um ENUM
7.4 Erweiterung von TK-Anlagen um ENUM
Bestehende TK-Anlagen haben meist kein Netzwerkinterface und sind daher
auch nicht Voice over IP-fähig. Folglich kann man mit diesen Systemen auch
keine Dienste wie ENUM nutzen.
Abbildung 7.9: Erweiterung einer bestehenden TK-Anlage um ENUMFunktionalität
Um diese Anlagen um ENUM-Funktionalität zu erweitern, muss man ein getrenntes System über die von der Anlage bereitgestellten Interfaces anbinden.
Da für ENUM nur die Anrufe von Interesse sind, die die bestehende Anlage nicht Intern vermitteln kann, verwendet man am besten die Interfaces, die
mit dem öffentlichen Telefonnetz verbunden sind (idR. S2M-Interfaces). Diese
Interfaces verbindet man, wie in Abbildung 7.9 gezeigt, mit einem AsteriskServer und verbindet diesen mit dem öffentlichen Telefonnetz. Um unnötige
Ausfälle des Systems durch Reparatur- und Wartungsarbeiten zu vermeiden,
sollte man mindestens zwei Asterisk-Server verwenden.
Die Asterisk-Server versuchen, abgehende Gespräche per VoIP zu vermitteln.
Dazu können feste Einträge im Dialplan sowie public- und user ENUM verwendet werden. Ankommende Gespräche werden entweder direkt an die TKAnlage weitergeleitet oder per IP vermittelt (auch hierfür kann man feste Einträge im Dialplan und user ENUM verwenden). Sollten bei ankommenden oder
abgehenden Rufen auf der zugehörigen Leitung eines Servers zur TK-Anlage
bzw. zum Festnetz keine Kanäle mehr frei sein und das Gespräch kann nicht
per IP vermittelt werden, so kann das Gespräch zu einem anderen AsteriskServer weitergeleitet werden und von dort aus zur TK-Anlage bzw. zum Festnetz durchgereicht werden.
61
KAPITEL 7. ENUM
7.5 user ENUM mit Bind
Um einen eigenen ENUM-Server einzurichten, benötigt man eine geeignete
Nameserver-Software die in der Lage ist, ENUM-Anfragen zu bearbeiten. Hier
bietet sich z.B. Bind ab Version 9 an.
Zunächst muss die Konfigurationsdatei (named.conf, Abb. 7.10) von Bind
angepasst werden. Hier definiert man seine eigene ENUM-Zone (in diesem
Fall ”myenum”) zu der Bind ENUM-Anfragen beantworten soll.
zone ”myenum” {
type master;
file ”/etc/bind/db.myenum”;
allow-query { 127.0.0.1; asterisk1;
asterisk2; } ;
allow-transfer { 127.0.0.1; dns1; dns2; } ;
} ;
Abbildung 7.10: named.conf
Die eigentlichen Daten für die ENUM-Anfragen befinden sich in der Datei
”db.myenum” (Abb. 7.11). Zu Beginn werden die allgemeinen Parameter für
das DNS definiert. Im Anschluss daran können dann die einzelnen ENUMEinträge in der Form aufgelistet werden wie sie auch vom DNS bei einer
ENUM-Anfrage zurückgeliefert werden.
Nun kann man an diesen Server ENUM-Anfragen der Form
4.3.2.1.2.0.3.1.8.6.9.4.myenum
stellen, die in diesem Fall die folgende VoIP-Adresse zurückliefern würde.
IAX2/[email protected]/1234
62
7.5. user ENUM mit Bind
$TTL 3600
@ IN SOA localhost. root.localhost. (
1 ; Serial
3600 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
NS myenumserver
NS dns1
NS dns2
;uni-sb
*.2.0.3.1.8.6.9.4.myenum.
IN NAPTR
1 1 ”u” ”E2U+IAX2”
”!
+49681302(.*)$!
IAX2/[email protected]/ 1!” .
Abbildung 7.11: db.myenum
63
Kapitel 8
Endgeräte
Zum Betrieb eines VoIP-Systemes gehören natürlich auch die entsprechenden
IP-Telefone. Hier gilt unser besonderer Dank dem Rechenzentrum der Universität des Saarlandes und der Firma Snom, die so freundlich waren uns Testgeräte zur Verfügung zu stellen. Die folgende Übersicht beschränkt sich dabei
auf eine allgemeine Beschreibung der Besonderheiten der einzelnen uns verfügbaren Telefone. Die genauen technischen Daten sind auf den Websites der
jeweiligen Hersteller ersichtlich. Darüber hinaus gibt es noch eine Vielzahl
weiterer Telefone, deren Betrachtung allerdings den Rahmen dieser Ausarbeitung sprengen würde. Auch hier sei auf das Internet verwiesen, wo technische
Daten und Erfahrungsberichte vorzufinden sind.
8.1 Hardphones
Als Hardphones werden alle Hardware-Telefone bezeichnet, d.h. “echte” Telefone, die unabhängig von einem PC funktionieren.
8.1.1 Cisco 7960
Dies ist ein derzeit weit verbreitetes VoIP-Telefon (Abb. 8.1). Es verfügt über
sechs sog. Lines, d.h. man kann damit bis zu sechs verschiedene Rufnummern
auf das Telefon schalten. Zudem verfügt es über ein grosses LCD-Display,
das auch XML-Seiten (die in Cisco-XML geschrieben sind) darstellen kann.
Jedoch werden diese XML-Services in der SIP-Firmware nicht in dem Maße unterstützt, wie in der Skinny-Firware. Die Verarbeitung des Telefons ist
sehr gut und auch die Sprachqualität ist sehr gut. Zu den unterstützten Codecs
gehören G.711 und G.729. Desweiteren ist ein 10/100Mbit-Switch integriert,
so dass das Telefon in eine bereits bestehende Arbeitsplatzvernetzung eingeschleift werden kann. Allerdings ist der Preis relativ hoch (ca. 460 EUR).
64
8.1. Hardphones
Abbildung 8.1: Cisco 7960
8.1.2 Cisco 7905
Dieses Telefon ist relativ neu (Abb. 8.2). Im Vergleich zum 7960 verfügt es
derzeit lediglich über eine einzige Line und kann auch keine XML-Services
darstellen. Zu den unterstützten Codecs gehören wie beim 7960 G.711 und
G.729. Auch hier sind Verarbeitung und Sprachqualität sehr gut. Verfügbare
Firmwares sind Skinny, H.323 und SIP. Benötigt man jedoch ein anderes Protokoll, so muss man das Telefon mit der jeweiligen Firmware neu flashen, was
im übrigen bei allen Cisco-Telefonen der Fall ist. Als weiteres Feature kann es
durch ein Webinterface (Abb. 8.3) konfiguriert werden - allerdings ist dieses
recht kryptisch zu bedienen - ohne Handbuch ist hier kaum eine Konfiguration
möglich. Auch verfügt es über keine echte Freisprecheinrichtung, sondern lediglich über einen Lautsprecher. Dafür ist der Preis allerdings mit ca. 150 EUR
recht günstig.
Abbildung 8.2: Cisco 7905
65
KAPITEL 8. Endgeräte
Abbildung 8.3: Cisco 7905 Webinterface
8.1.3 Snom 100
Das von der Berliner Firma Snom entwickelte Telefon unterstützt G.711, G.729
und GSM (Abb. 8.4). Es zeichnet sich vor allem durch ein sehr übersichtliches und gut bedienbares Webinterface aus (Abb. 8.5). Weiterhin unterstützt
es sowohl H.323 als auch SIP mit der gleichen Firmware. Vom Funktionsumfang reicht es fast an ein 7960 heran, wenn es auch wie das 7905 keine XMLServices (o.ä.) bietet. Das Design mag Geschmackssache sein - allerdings würden wir den Telefonhörer doch zumindest als “ungewöhnlich” bezeichnen. Der
Preis liegt mit ca. 300 EUR im Mittelfeld.
Abbildung 8.4: Snom 100
66
8.2. Analog-IP - Wandler
Abbildung 8.5: Snom 100 Webinterface
8.2 Analog-IP - Wandler
Hierbei handelt es sich um Geräte, die es ermöglichen ein oder mehrere herkömmliche Analogtelefone an ein VoIP-System anzubinden.
8.2.1 Cisco ATA-186
Mit dem ATA-186 können zwei Analogtelefone an ein VoIP-System angeschlossen werden (Abb. 8.7). Von Cisco sind Firwares für Skinny und MGCP
oder H.323 und SIP erhältlich. Auch hier ist wie beim 7905 ein Webinterface
vorhanden (Abb. 8.6), das sich allerdings ebenfalls sehr kryptisch und nur mit
Hilfe des Handbuches bedienen lässt. Der Neupreis liegt bei ca. 130 EUR.
8.2.2 Digium IAXy
Digium bietet mit dem IAXy (Abb. 8.8) einen weiteren Adapter für Analogtelefone an, an den sich allerdings nur ein einziges Gerät anschliessen lässt.
Dafür ist er von der Größe handlicher als ein ATA-186. Wie der Name schon
vermuten lässt, spricht dieses Gerät das Asterisk-eigene IAX-Protokoll. Der
Preis liegt bei ca. 99USD.
67
Abbildung 8.6: Cisco ATA-186 Webinterface
Abbildung 8.7: Cisco ATA-186
8.3 Softphones
Dies sind Software-Clients die auf einem PC/Laptop/PDA betrieben werden.
8.3.1 KPhone
KPhone [32] ist ein SIP-Softphone für Linux (Abb. 8.9), das seit der Version
4.0.0 auch DTMF-Töne versenden kann um z.B. Voicemail abzufragen oder
durch IVR-Menüs zu navigieren.
Verfügbare Audiocodecs sind G.711, GSM und iLBC. Ferner unterstützt Kphone das STUN-Protokoll, womit der Betrieb hinter den meisten Firewalls und
NATs möglich ist. Einziger Nachteil ist die nicht funktionierende Videotelefonie - Kphone sieht zwar Videotelefonie mittels VIC [33] vor, allerdings ließ
sich bei allen bisherigen Versuchen kein Video übertragen.
68
8.4. Headsets
Abbildung 8.8: Digium IAXy
Abbildung 8.9: Kphone
8.3.2 X-Lite
Bei X-Lite handelt es sich um die Gratisversion eines kommerziellen Produktes (X-Pro), das von der Firma Xten Networks [34] hergestellt wird (Abb.
8.10). X-Lite ist z.Z. für Windows und MacOS X erhältlich und soll demnächst
auch in einer Linux-Version verfügbar sein. Auch X-Lite unterstützt STUN um
hinter Firewalls/NATs benutzt zu werden. Zu den unterstützten Codecs zählen
G.711, GSM, Speex und iLBC.
Leider hat auch X-Lite einige Nachteile, die allerdings durch den kommerziellen Hintergrund begründet sind: So ist es z.B. mit dieser Version der Software
nicht möglich Anrufe weiterzuvermitteln.
8.4 Headsets
Will man mit einem Softphone ein Gespräch führen, benötigt man zusätzlich
noch ein am PC angeschlossenes Headset, d.h. Kopfhörer mit Mikrofonbügel.
Hier gibt es verschiedene Alternativen: zum einen recht preisgünstige Headsets zum Anschluss an die (meist vorhandene) Soundkarte des Rechners. Dies
69
Abbildung 8.10: X-Lite
setzt eine Full-Duplex-fähige Soundkarte (idR. alle neueren Modelle), sowie
eine Unterstützung der Soundkarte durch das Betriebssystem voraus. Letzteres
kann bei einigen Soundkarten unter Linux Probleme bereiten. Zudem hat man
meist bereits ein Lautsprechersystem an den Rechner angeschlossen und somit
keinen Platz für die zusätzlichen Steckverbindungen eines Headsets.
Aus diesem Grund bieten sich USB-Headsets an, die einfach an einen freien
USB-Port des Rechners angeschlossen werden können und ihre eigene Soundkarte mitbringen. Leider gibt es auch hier wieder mit manchen Produkten Probleme unter Linux: So werden je nach Headset und verwendetem Soundtreiber (OSS oder Alsa) nicht alle benötigten Samplerates ungerstützt. Weiterhin
gibt es bei Verwendung eines Plantronics USB-Headset (DSP 100) zusammen
mit dem USB-UHCI-Treiber (auf Intel- und VIA-Boards verbreitet) und allen
Alsa-Versionen bis 1.0 das Problem, dass nach wenigen Sekunden die Audioübertragung zusammenbricht.
Eine dritte Möglichkeit stellt die Verwendung von Bluetooth-Headsets dar: Der
Hauptvorteil hierbei ist, dass man keinen ”Kabelsalat” mehr hat und mehr
Bewegungsfreiheit und Komfort geniesst. Leider hat auch dies (zumindest
unter Linux) einen Haken: Alle Softphones erwarten ein Linux-Sounddevice
(/dev/dsp) für den Audio-IO. Für Bluetooth gibt es derzeit erst einen einzigen, noch im alpha-Stadium befindlichen, Alsa-Treiber, der ein solches Device
zur Verfügung stellt. Weiterhin erfordert die Verwendung dieses Treibers Patches an Alsa und dem Kernel, was zumindest für Produktivsysteme (wie einen
Lehrstuhl) inakzeptabel ist.
Die Sprachqualität der von uns getesteten Headsets lässt sich generell als gut
bis sehr gut zu bezeichnen. Die Qualität ist dabei unabhängig von der verwendeten Anschlussart (Klinke, USB oder Bluetooth). Will man sein Headset
unter verschiedenen Betriebssystemen verwenden, ist derzeit ein Headset zum
direkten Anschluss an die Soundkarte zu empfehlen, welche zudem auch meist
recht günstig erhältlich sind.
70
Kapitel 9
Zusammenfassung
Inhalt dieser Arbeit ist der Aufbau einer VoIP-Infrastruktur unter Verwendung
von OpenSource-Komponenten. Zunächst wurde ein Überblick der Funktionsweise von VoIP, sowie der verfügbaren Protokolle gegeben, welche anschliessend auch verglichen und bewertet wurden.
Nach der Schilderung der einzelnen Ziele wurden die derzeit verfügbaren OpenSource-Server vorgestellt und evaluiert, wobei sich zwei Projekte als geeignet herausgestellt haben. Im Anschluss wurde dann die Umsetzung der Ziele
mit der ausgewählten Software und der verwendeten Konfiguration genau erläutert. Dabei aufgetretene Probleme wurden beschrieben und soweit möglich
auch durch eigene Implementierungen/Patches gelöst.
Die Server wurden sowohl in das LAN als auch in das ISDN-Netz der Universität integriert und so konfiguriert, dass die Teilnehmer aller Netze (ISDN und
VoIP) erreichbar sind. Weiterhin wurden auch VoIP-basierte Verbindungen zu
anderen Universitäten eingerichtet und die Erreichbarkeit der Universität des
Saarlandes über VoIP mittels ENUM hergestellt.
Darüber hinaus wurden auch verschiedene Endgeräte (sowohl Hardware als
auch Software) von uns getestet und bewertet.
Abbildung 9.1 zeigt noch einmal den gesamten Testaufbau wie er derzeit vorhanden ist: Neben den bereits vorgestellten Asterisk-Installationen am Lehrstuhl für Computergraphik und im Rechenzentrum der Universität befindet
sich dort weiterhin ein Cisco CallManager (CCM). Diese Installation versorgt
den Lehrstuhl Bioinformatik und befand sich bereits im Rechenzentrum, wo
sie direkt über eine S2M-Schnittstelle mit der TK-Anlage verbunden war. In
diese Leitung wurde dann der Asterisk-Server transparent eingeschleift, so
dass die bisherige Funktionalität weiterhin gewährleistet ist.
71
KAPITEL 9. Zusammenfassung
Abschliessend kann gesagt werden, dass sich die gewählten Komponenten als
überaus tauglich erwiesen haben und auch genügend Potential für weitere, zukünftige Ausbauten und Erweiterungen bieten.
Abbildung 9.1: Gesamter Testaufbau
9.1 Ausblick
Neben den bereits erwähnten Möglichkeiten von VoIP sind für die Zukunft
noch weitere Dienste denkbar. So ließe sich die reine Sprachtelefonie relativ
leicht um Videotelefonie erweitern, da dies schon in den verwendeten Protokollen definiert ist. Allerdings müssten noch geeignete Endgeräte evaluiert
und/oder entwickelt werden.
Ein weiteres Thema, welches zusätzliche Beachtung verdient, ist eine Absicherung der VoIP-Kommunikation – vor allem die Verschlüsselung der Me-
72
9.1. Ausblick
dienströme selbst. Auch hier ist dies zwar schon in den Protokollen definiert,
allerdings mangelt es an geeigneten Implementierungen. Dieser Punkt wird
insofern interessant, wenn man eine flächendeckende Einführung von VoIP
anstreben möchte. Für diese Problemstellung sind mehrere Lösungen denkbar,
diese müssten dann unter den gegebenen Bedingungen evaluiert und getestet
werden.
Davon unbenommen sind auch noch weitere Services wie Unified Messaging
und CTI denkbar, die eine komfortable Integration von Telefoniefunktionen in
den Desktop bieten können. Weiterhin sollten die bisherigen Bestrebungen der
Anbindung zu anderen Universitäten über das DFN fortgesetzt werden und die
so möglichen Kostenvorteile allen Nutzern der Telefonanlage wie in Kapitel
7.4 beschrieben mittels ENUM ermöglicht werden.
73
Anhang A
Verwendete
Konfigurationsdateien
A.1 extensions.conf
[general]
static=yes
writeprotect=yes
[globals]
exten =
h,1,Hangup
[trunk international]
exten =
000Z.,1,EnumLookup(${EXTEN:3})
exten =
000Z.,2,Goto(1000)
exten =
000Z.,52,Goto(000${ENUM},2000)
exten =
000Z.,102,Goto(2000)
exten =
000Z.,1000,SetCIDNum(+49681302${CALLERIDNUM} a)
exten =
000Z.,1001,Dial(${ENUM})
exten =
000Z.,1002,SetCIDNum(${CALLERIDNUM:9 a})
exten =
000Z.,1003,Goto(2000)
exten =
000Z.,1102,Busy
exten =
000Z.,2000,Macro(dialout,${EXTEN})
10
[trunk dland]
exten =
00049Z.,1,EnumLookup(${EXTEN:3})
exten =
00049Z.,2,Goto(1000)
exten =
00049Z.,52,Goto(000${ENUM},2000)
exten =
00049Z.,102,Goto(2000)
exten =
00049Z.,1000,SetCIDNum(+49681302${CALLERIDNUM} a)
exten =
00049Z.,1001,Dial(${ENUM})
exten =
00049Z.,1002,SetCIDNum(${CALLERIDNUM:9 a})
74
20
A.1. extensions.conf
exten =
exten =
exten =
00049Z.,1003,Goto(2000)
00049Z.,1102,Busy
00049Z.,2000,Macro(dialout,00${EXTEN:5})
30
[trunk saar]
exten =
0004968.,1,EnumLookup(${EXTEN:3})
exten =
0004968.,2,Goto(1000)
exten =
0004968.,52,Goto(000${ENUM},2000)
exten =
0004968.,102,Goto(2000)
exten =
0004968.,1000,SetCIDNum(+49681302${CALLERIDNUM} a)
0004968.,1001,Dial(${ENUM})
exten =
exten =
0004968.,1002,SetCIDNum(${CALLERIDNUM:9 a})
exten =
0004968.,1003,Goto(2000)
40
exten =
0004968.,1102,Busy
0004968.,2000,Macro(dialout,00${EXTEN:5})
exten =
[macro dialout]
exten = s,1,Dial(Capi/@3841:${ARG1})
exten = s,2,Congestion
exten = s,102,Busy
[trunk kostenlos]
;Nationale und internationale 800 Nummern
exten =
00800ZXXXXXX,1,SetAccount(capi kostenlos)
exten =
00800ZXXXXXX,2,Macro(dialout,${EXTEN})
exten =
000800ZXXXXXX,1,SetAccount(capi kostenlos)
exten =
000800ZXXXXXX,2,Macro(dialout,${EXTEN})
50
;Statisches Routing zur Uni Ulm (mit Public Key Verfahren)
;mit Fallback ueber ISDN falls der Teilnehmer die entsprechende
;Berechtigung hat
exten =
0004973150XXXXX,1,SetAccount(iax2ulm)
exten =
0004973150XXXXX,2,SetCIDNum(0681302${CALLERIDNUM} a) 60
exten =
0004973150XXXXX,3,Dial(IAX2/uni sb:[reyes]@uni ulm/${EXTEN:10})
exten =
0004973150XXXXX,4,SetCIDNum(${CALLERIDNUM:7} a)
0004973150XXXXX,5,Goto(${EXTEN},2000)
exten =
exten =
0004973150XXXXX,104,Busy
[trunk uni]
;Zentrale (von extern 0, von intern 19)
exten = 19,1,SetAccount(iax2 uni)
exten = 19,2,Dial(IAX2/cogra@rz out/19)
exten = 19,3,Congestion
exten = 19,103,Busy
70
75
ANHANG A. Verwendete Konfigurationsdateien
;Nebenstellen der Uni
exten =
[2 57]XXX,1,SetAccount(iax2 uni)
[2 57]XXX,2,Dial(IAX2/cogra@rz out/${EXTEN})
exten =
exten =
[2 57]XXX,3,Congestion
exten =
[2 57]XXX,103,Busy
exten =
[69]XXXX,1,SetAccount(iax2 uni)
exten =
[69]XXXX,2,Dial(IAX2/cogra@rz out/${EXTEN})
exten =
[69]XXXX,3,Congestion
exten =
[69]XXXX,103,Busy
80
[trunk univonextern]
;Zentrale (von extern 0, von intern 19)
exten = 0,1,SetAccount(iax2 univonextern)
exten = 0,103,Busy
exten = 19,1,SetAccount(iax2 univonextern)
exten = 19,103,Busy
90
;Nebenstellen der Uni
[2 57]XXX,1,SetAccount(iax2 univonextern)
exten =
exten =
[2 57]XXX,2,Dial(IAX2/cogra@rz out/${EXTEN})
exten =
[2 57]XXX,3,Congestion
exten =
[2 57]XXX,103,Busy
exten =
[69]XXXX,1,SetAccount(iax2 univonextern)
exten =
[69]XXXX,2,Dial(IAX2/cogra@rz out/${EXTEN})
[69]XXXX,3,Congestion
exten =
exten =
[69]XXXX,103,Busy
100
[international]
ignorepat = 0
include = dland
include = trunk international
[dland]
ignorepat = 0
include = saar
include = trunk dland
[saar]
ignorepat = 0
include = kostenlos
include = trunk saar
76
110
[kostenlos]
ignorepat =
include =
include =
include =
include =
[uni]
include =
include =
include =
120
0
uni
parkedcalls
trunk kostenlos
trunk iaxtel700
default intern
default
trunk uni
[univonextern]
exten =
.,1,SetCallerID("*ext*${CALLERIDNAME}"
.,2,Goto(univonextern2,${EXTEN},1)
exten =
130
***${CALLERIDNUM}*** )
[univonextern2]
include = default
include = trunk univonextern
[macro stdexten]
;Rufumleitung gesetzt?
exten = s,1,DBget(TARGET=CF/${MACRO EXTEN})
exten = s,2,Goto(1000)
;CallerID aus der internen DB auslesen
exten = s,102,LookupCIDName
exten = s,103,Dial(${ARG1},20)
140
exten = s,104,Answer
exten = s,105,Wait(1)
Voicemail
;Keine Antwort
exten = s,106,Voicemail2(u${MACRO EXTEN})
exten = s,107,Hangup
150
exten =
exten =
;Besetzt
exten =
exten =
exten =
s,204,Answer
s,205,Wait(1)
Voicemail
s,206,Voicemail2(b${MACRO EXTEN})
s,207,Hangup
s,1000,Dial(Local/${TARGET}@default)
160
[default intern]
;Notrufe
exten =
110,1,Dial(${TRUNK}/@3841:0110)
exten =
110,2,Congestion
77
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
exten
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
110,102,Congestion
112,1,Dial(${TRUNK}/@3841:0112)
112,2,Congestion
112,102,Congestion
0110,1,Dial(${TRUNK}/@3841:0110)
0110,2,Congestion
0110,102,Congestion
0112,1,Dial(${TRUNK}/@3841:0112)
0112,2,Congestion
0112,102,Congestion
19222,1,Dial(${TRUNK}/@3841:019222)
19222,2,Congestion
19222,102,Congestion
019222,1,Dial(${TRUNK}/@3841:019222)
019222,2,Congestion
019222,102,Congestion
170
180
;Umwandlung ins E.164 Format
00Z.,1,Goto(00049${EXTEN:2},1)
exten =
exten =
0068.,1,Goto(0004968${EXTEN:4},1)
0Z.,1,Goto(00049681${EXTEN:1},1)
exten =
;Rufumleitung setzen
exten =
*21*.,1,DBput(CF/${CALLERIDNUM}=${EXTEN:4})
exten =
*21*.,2,Wait(1)
exten =
*21*.,3,SayDigits(${EXTEN:4})
exten =
*21*.,4,Playback(vm goodbye)
exten =
*21*.,5,Wait(1)
*21*.,6,Hangup
exten =
190
;Rufumleitung loeschen
exten = *21*,1,DBdel(CF/${CALLERIDNUM})
exten = *21*,2,Wait(1)
exten = *21*,3,Playback(vm goodbye)
exten = *21*,4,Wait(1)
exten = *21*,5,Hangup
200
;VoiceMail Abfrage von einem fremden Anschluss
exten = 9998,1,Answer
exten = 9998,2,Wait(1)
exten = 9998,3,VoicemailMain2
exten = 9998,4,Hangup
;VoiceMail Abfrage ohne CallerID
exten = 9999/,1,Answer
exten = 9999/,2,Wait(1)
78
210
exten =
exten =
9999/,3,VoicemailMain2
9999/,4,Hangup
;VoiceMail Abfrage vom eigenen Anschluss mit CallerID
exten = 9999/ Z.,1,Answer
exten = 9999/ Z.,2,Wait(1)
exten = 9999/ Z.,3,VoicemailMain2(s${CALLERIDNUM})
exten = 9999/ Z.,4,Hangup
220
;Workaround fuer Cisco 7905
exten =
*9999*.,1,Answer
*9999*.,2,Wait(1)
exten =
exten =
*9999*.,3,SetVar(MAILBOX=${EXTEN:6})
exten =
*9999*.,4,VoiceMail2(b${MAILBOX})
exten =
*9999*.,5,Hangup
exten = o,1,VoiceMailMain2(${MAILBOX})
exten = o,2,Hangup
;Direkte Anwahl von iptel.org Teilnehmern
**478.,1,Dial(SIP/${EXTEN:5}@iptel.org)
exten =
230
[default]
;Rufnummern des Lehrstuhls
;Standardmaessig alle Nummern ueber SIP anrufen
exten =
685[7 8]X,1,Macro(stdexten,SIP/${EXTEN})
;Diese Nummer ueber Skinny anrufen
exten = 68587,1,Macro(stdexten,SCCP/${EXTEN})
240
;Konferenz
exten = 68589,1,Answer
exten = 68589,2,Wait(1)
exten = 68589,3,MeetMe
;Konferenz mit Angabe der Raumnummer
;(kann in dieser Form nich von der TK Anlage aus
;oder von extern gewaehlt werden)
exten =
68589.,1,Answer
exten =
68589.,2,Wait(1)
exten =
68589.,3,MeetMe(${EXTEN:5})
250
79
A.2 sip.conf
[general]
port = 5060
bindaddr = 0.0.0.0
context = univonextern
maxexpirey=3600
defaultexpirey=120
disallow=all
allow=alaw
allow=ulaw
allow=gsm
srvlookup=yes
;dtmfmode=rfc2833
dtmfmode=inband
language=de
canreinvite=no
10
;
; Lehrstuhl (6857x + 6858x)
;
[68588]
type=friend
username=68588
mailbox=68588
md5secret=524a1f666a24d42f6ba23da1f58a6e71;68588
host=dynamic
canreinvite=no
dtmfmode=rfc2833
context=international
callgroup=1
callerid="JOCHEM Rainer" 68588
qualify=yes
accountcode=rainer
amaflags=documentation
language=de
80
20
30
A.3. Skript zum Abgleich der sip.conf mit einer MySQL-Datenbank
A.3
Skript zum Abgleich der sip.conf mit einer MySQLDatenbank
#!/usr/bin/perl
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Copyright (C) 2003
Maik Schmitt
[email protected] sb.de
This script is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
by the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
It is distributed in the hope that it will be useful,
10
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111 1307 USA
use DBI qw(:sql types);
20
( e ’/var/lock/md5pws’) and die "Lock file found!";
system("touch /var/lock/md5pws");
$databaseName = "DBI:mysql:asterisk";
$databaseUser = "";
$databasePw = "";
$dbh = DBI connect($databaseName, $databaseUser,
$databasePw)
die "Connect failed: $DBI::errstr n";
unless (open SOURCE, " ", "/etc/asterisk/sip.conf") {
die "Couldn’t open sip.conf";
}
unless (open DEST, " ", "/tmp/md5pws") {
die "Couldn’t open tempfile";
}
30
$changed = false;
40
while ( SOURCE ) {
if(/^md5secret=.*;.*$/) {
$ ine = $ ;
81
($a, $b) = split /=/, $ ine;
($hash, $user) = split /;/, $b;
chomp($user);
$stmt = "SELECT hash FROM sipusers WHERE (user=’$user’)";
die "prepare: $$stmt: $DBI::errstr";
$sth = $dbh prepare($stmt)
$sth execute
die "execute: $$stmt: $DBI::errstr";
@record = $sth fetchrow();
50
$newhash = $record[0];
$sth finish();
if ( $newhash ) {
if ( $newhash =˜ $hash ) {
print DEST $ ;
}
else {
$changed = true;
print DEST "md5secret=$newhash;$user n";
}
}
else {
print DEST $ ;
}
60
}
else {
print DEST $ ;
}
}
$dbh
70
disconnect();
if ( $changed =˜ true ) {
system("mv /tmp/md5pws /etc/asterisk/sip.conf");
system("/usr/sbin/asterisk rx reload /dev/null 2 &1");
}
unlink("/var/lock/md5pws");
82
Anhang B
Glossar
ACD Automatic Call Distribution. Wird meist in Callcentren eingesetzt, um
eine große Anzahl eingehender Anrufe gleichmäßig auf eine Anzahl von
”Agenten” zu verteilen.
BRI Basic Rate Interface. Endkunden ISDN-Anschluss, bestehend aus zwei
64K Übertragungskanälen und einem 16K Kontrollkanal.
CAPI Common Application Programming Interface. Internationale, standardisierte Schnittstelle mit der Anwendungen direkt mit ISDN-Hardware
kommunizieren können.
CTI Computer Telephony Integration. Begriff für Computerunterstütztes Telefonieren.
CVS Concurrent Versioning System, dient zum Zugriff auf Quellcodeverzeichnisse.
DISA Direct Inward System Access. Bietet externen Anrufern die Möglichkeit von aussen mit den Berechtigungen eines internen Benutzers auf
das System zuzugreifen.
DTMF Dual Tone Multi-Frequency. Findet Verwendung im Tonwahlverfahren. Hierbei werden gleichzeitig zwei Töne übertragen, einer für die
Spalte und der andere für die Zeile des Rufnummernblocks des Telefons. Somit kann die gedrückte Taste eindeutig bestimmt werden.
E1 Europäischer Standard für schnelle Digitalübertragungen, definiert mit 2,048
Mbit/s. Eine E1-Leitung besteht aus 31 Kanälen mit jeweils 64k Übertragunsrate.
ENUM Telephone Number Mapping (RFC 2916[29], s. Kapitel 7)
GPL GNU General Public License erlaubt freien Zugriff auf Software, die unter den Bedingungen der GPL veröffentlicht wurde. Sie erlaubt Nutzern,
GPL Software zu kopieren, verändern und weiterzugeben.
83
ANHANG B. Glossar
GUI Graphical User Interface.
H.323 ITU-T Standard zur Übertragung von Multimediainhalten über paketbasierte Netze wie z.B. TCP/IP
IAX / IAX2 Inter Asterisk Exchange. Asterisk-eigenes VoIP-Protokoll. Wurde speziell dazu entwickelt, um Probleme mit Firewalls und NAT zu
vermeiden: verwendet lediglich einen einzigen UDP-Port für Signalisierung und Nutzdaten.
ISDN Integrated Services Digital Network ist ein Standard für digitale Telefonverbindungen. Es gibt zwei Arten von ISDN: BRI und PRI.
IVR Interactive Voice Response. Beschreibt ein automatisches System zur
Anrufbearbeitung, bei dem der Anrufer mit einer vom Computer gesteuerten Stimme interagiert – entweder durch aufgezeichnete Sprache, oder
durch vom Computer generierte Sprache. Die Interaktion findet dabei
meist durch Tastendrücke auf dem Telefon statt. (siehe DTMF)
LCR Least-Cost-Routing. Begriff für das Routing eines Telefonanrufs über
den preiswertesten Weg. Wird üblicherweise durch eine automatisch vor
die gewählte Rufnummer gesetzte Vorwahl eines günstigerern Anbieters
bewerkstelligt.
MD5 Message Digest Algorithm 5. Einweg Hashing-Algoritmus, der zur
Eingabe einen eindeutigen 128bit-langen Hash erzeugt.
MSN Multiple Subscriber Numbering. Ein ISDN-Feature das es erlaubt mehrere Rufnummern auf einer ISDN-Leitung zu vergeben so dass die auf
diesem Bus angeschlossenen Geräte einzeln angerufen werden können.
PBX Private Branch Exchange. Die Telefonanlage des Endkunden.
PRI Primary Rate Interface. ISDN-Anschluss für Grossverbraucher. Besteht
in den USA und in Japan aus 23 64K Übertragungskanälen und einem
64K Kontrollkanal. In Europa besteht ein PRI aus 30 Übertragunskanälen und einem Kontrollkanal.
PSTN Public Switched Telephony Network. Das herkömmliche Telefonnetz.
S2M siehe E1
SCCP Skinny Client Control Protocol. Von Cisco entwickeltes Protokoll, das
in den VoIP-Produkten von Cisco Verwendung findet.
SIP Session Initiation Protocol [6]
T1 Nordamerikanischer Standard für schnelle Digitalverbindungen, definiert
mit 1,544Mbit/s. Besteht aus 24 Kanälen mit je 64k Übertragungsrate.
TK TeleKommunikation
84
TCP/IP Transmission Control Protocol/Internet Protocol. Eine Protokollsuite
die zur Vernetzung von Computern dient. Findet z.B. im Internet verwendung.
URI Uniform Resource Identifier. Standardbezeichnung für Ressourcen im
Internet.
Unified Messaging Beschreibt die Kommunikation über verschiedenste Medien unter Verwendung einer einzigen Applikation. z.B. Verwenden einer Rufnummer für ISDN, VoIP, Fax o.ä.
Zaptel Zapata Telephony [35] Auch Zaptel-Devices. Bezeichnung für die von
Digium produzierte Telefonhardware.
85
Anhang C
Verantwortliche
C.1 Maik Schmitt
Installieren und Testen von openh323gk mit isdn2h323
SER versucht über sip2h323 und isdn2h323 anzubinden
Installieren und testen von VOCAL
Umstellung von ISDN4Linux zu CAPI
Testen von Endgeräten: Cisco 7960, Cisco ATA-186 und kphone
Benutzerverwaltung mit RADIUS für SER getestet
Asterisk-Patch für md5secret
WWW-GUI für Lehrstuhlserver (Backend)
Rufnummernpläne erstellt
DNS-Server für ENUM-Test installiert
Installation und Konfiguration des ENUM-Servers im Rechenzentrum
WWW-GUI für Studentenserver (Backend)
C.2 Rainer Jochem
Installieren und testen von SER
Installieren und testen von Asterisk
Lehrstuhlrechner zum Testsystem umgebaut mit ISDN-Karte zur Aussenanbindung
86
C.2. Rainer Jochem
Anbindung von SER an Asterisk getestet
Testen von Endgeräten: Cisco 7905, Snom 100 und X-Lite
Testen verschiedener Headsets (USB und Bluetooth)
WWW-GUI für Lehrstuhlserver (Frontend)
Software-FAX mit Asterisk getestet
Installation und Konfiguration des Studentenservers im Rechenzentrum
WWW-GUI für Studentenserver (Frontend)
Projektwebseite erstellt
87
Tabellenverzeichnis
88
2.1
Übersicht verbreiteter Audiocodecs
. . . . . . . . . . . . . .
8
2.2
SIP Reply Codes . . . . . . . . . . . . . . . . . . . . . . . .
13
5.1
Besondere Extensions . . . . . . . . . . . . . . . . . . . . . .
39
Abbildungsverzeichnis
2.1
SIP-Request . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
SIP-Response . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
SIP Rufaufbau . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4
SIP Signalisierung
. . . . . . . . . . . . . . . . . . . . . . .
17
2.5
SDP Signalisierung . . . . . . . . . . . . . . . . . . . . . . .
17
5.1
Ursprüngliche Installation
. . . . . . . . . . . . . . . . . . .
26
5.2
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3
Format der Konfigurationsdatei . . . . . . . . . . . . . . . . .
29
5.4
Simple Groups . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5
Inherited Option Object . . . . . . . . . . . . . . . . . . . . .
30
5.6
Complex Entity Object . . . . . . . . . . . . . . . . . . . . .
30
5.7
Globale Parameter in sip.conf . . . . . . . . . . . . . . . . . .
31
5.8
SIP-Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.9
Einfache extensions.conf . . . . . . . . . . . . . . . . . . . .
34
5.10 capi.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.11 Funktion der Extensions . . . . . . . . . . . . . . . . . . . .
37
5.12 Das Include-Statement . . . . . . . . . . . . . . . . . . . . .
40
5.13 Berechtigungsstufen
. . . . . . . . . . . . . . . . . . . . . .
40
5.14 Allgemeine Parameter in voicemail.conf . . . . . . . . . . . .
41
89
ABBILDUNGSVERZEICHNIS
90
5.15 Einrichten der Voicemailboxen . . . . . . . . . . . . . . . . .
42
5.16 Konferenzräume . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.17 Beispiel für die Verwendung von md5secret . . . . . . . . . .
44
5.18 Screenshot SIP-UI . . . . . . . . . . . . . . . . . . . . . . .
45
6.1
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.2
Modifiktion der ser.cfg . . . . . . . . . . . . . . . . . . . . .
49
6.3
Dialplan zur Einwahl ISDN - SER . . . . . . . . . . . . . . .
50
6.4
SRV-Record . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7.1
zapata.conf . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
7.2
Rufablauf bei ENUM-Anfragen . . . . . . . . . . . . . . . .
57
7.3
Umformatieren der Rufnummer für ENUM-Anfrage
. . . . .
58
7.4
ENUM-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . .
58
7.5
Nicht erfolgreicher VoIP-Anruf . . . . . . . . . . . . . . . . .
59
7.6
Anruf über das Festnetz . . . . . . . . . . . . . . . . . . . . .
59
7.7
Wahl von Festnetzrufnummern . . . . . . . . . . . . . . . . .
60
7.8
Vorwahl, um ENUM-Anfrage zu umgehen . . . . . . . . . . .
60
7.9
Erweiterung einer TK-Anlage um ENUM-Funktionalität . . .
61
7.10 named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.11 db.myenum . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.1
Cisco 7960 IP-Telefon . . . . . . . . . . . . . . . . . . . . .
65
8.2
Cisco 7905 IP-Telefon . . . . . . . . . . . . . . . . . . . . .
65
8.3
Cisco 7905 Webinterface . . . . . . . . . . . . . . . . . . . .
66
8.4
Snom 100 IP-Telefon . . . . . . . . . . . . . . . . . . . . . .
66
8.5
Snom 100 Webinterface . . . . . . . . . . . . . . . . . . . . .
67
ABBILDUNGSVERZEICHNIS
8.6
Cisco ATA-186 Webinterface . . . . . . . . . . . . . . . . . .
68
8.7
Cisco ATA-186 . . . . . . . . . . . . . . . . . . . . . . . . .
68
8.8
Digium IAXy . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.9
Kphone Softphone . . . . . . . . . . . . . . . . . . . . . . .
69
8.10 X-Lite Softphone . . . . . . . . . . . . . . . . . . . . . . . .
70
9.1
72
Gesamter Testaufbau . . . . . . . . . . . . . . . . . . . . . .
91
Literaturverzeichnis
[1] Regulierer bereitet das Feld für Internet-Telefonie
Aus: Heise-Newsticker vom 17.01.2004
Autor: Sascha Mattke
http://www.heise.de/newsticker/data/psz-17.01.04-002/
[2] T-Com will Telefon-Festnetz komplett auf Internet umstellen
Aus: Heise-Newsticker vom 17.01.2004
Autor: Sascha Mattke
http://www.heise.de/newsticker/data/psz-17.01.04-003/
[3] Audio Codecs
http://www.cs.columbia.edu/˜hgs/audio/codecs.html
[4] IETF iLBC draft
http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-04.txt
[5] Speex Codec Homepage
http://www.speex.org/
[6] RFC 3261, SIP
http://www.ietf.org/rfc/rfc3261.txt?number=3261
[7] RFC 2327, SDP
[8] RFC 2327, RTP
[9] 3rd Generation Partnership Project (3GPP)
http://www.3gpp.org/
[10] 3GPP TS 24.228 V5.0.0, “Signalling flows for the IP multimedia call
control based on SIP and SDP; Stage 3 (Release 5)”, March 2002.
http://www.3gpp.org/ftp/Specs/archive/24_series/24.228/
[11] RFC 2663 , NAT
[12] International Telecommunication Union (ITU)
http://www.itu.int/
92
LITERATURVERZEICHNIS
[13] Ethereal Packet Sniffer
http://www.ethereal.com
[14] RFC 3489, STUN
[15] GNU Bayonne
http://www.gnu.org/software/bayonne/bayonne.html
[16] Vovida Open Communication Application Library (VOCAL)
http://www.vovida.org/
[17] iptel.org
http://www.iptel.org
[18] FhG Fokus
http://www.fokus.fraunhofer.de/
[19] Free World Dialup
http://www.fwd.pulver.com/
[20] Application Agent
http://www.iptel.org/aa/
[21] Asterisk PBX
http://www.asterisk.org/
[22] Digium Inc.
http://www.digium.com/
[23] Asterisk: A Bare-Bones VoIP Example
Aus: O’Reilly, ONLamp.com vom 03.07.2003
Autor: John Todd
http://www.onlamp.com/pub/a/onlamp/2003/07/03/asterisk.html?page=1
[24] VCORE – Virtual Courseroom Environment
http://graphics.cs.uni-sb.de/VCORE/recordings.html
[25] ISDN2H.323
http://www.telos.de/linux/H323/default_e.htm
[26] AVM Linux-Portal
http://www.avm.de/de/Service/AVM_Service_Portale/Linux/index.php3
[27] Asterisk Software-Fax Modul
http://www.opencall.org
[28] CAPI-Unterstützung für Asterisk
http://www.junghanns.net/asterisk/
[29] RFC 2916, ENUM
93
LITERATURVERZEICHNIS
[30] ENUM-Pilotprojekt des DENIC
http://www.denic.de/de/enum/index.html
[31] TE410P – Vierfach E1-Karte
http://www.digium.com/index.php?menu=wildcard_te410p
[32] KPhone – A voice over internet phone
http://www.wirlab.net/kphone/
[33] VIC - Video Conferencing Tool
http://www-nrg.ee.lbl.gov/vic/
[34] Xten Networks
http://www.xten.com/
[35] Zapata Telephony
http://www.zapatatelephony.org/
[36] IP Telephony Cookbook
Verschiedene Autoren
http://www.informatik.uni-bremen.de/˜prelle/terena/cookbook/main/
[37] VoIP-Info.org
Wiki verschiedener Autoren
http://www.voip-info.org
94

Voice over IP unter Verwendung von OpenSource

Transcription

Similar documents

CONNECT Test Gigaset IP Telefone

Asterisk – ein¨Uberblick

CE-Markt 7/2016 - CE

Das Neue kommt! - Universitätsklinikum Düsseldorf

Das Magazin für Netze, Daten- und Telekommunikation

3 Jahrzehnte Internet E-Mail

MiniQuickinstall Asterisk Open Source PBX _D

Handycam 09.2009

1 Titel 2 Inhaltsverzeichnis

Mobile Anwendungen - best practices in der TIME