Technische Universität Ilmenau Fakultät für Elektrotechnik und

Transcription

Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Medienprojekt
Aufbau eines VoIP-Netzes im Fachgebiet
Kommunikationsnetze
vorgelegt von:
eingereicht am:
Studiengang:
Anfertigung im Fachgebiet:
Sebastian Güttner, Daniel Ruf
29. 5. 2008
Medientechnologie
Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Verantwortlicher Professor:
Wissenschaftlicher Betreuer:
Prof. Dr. rer. nat. habil. Jochen Seitz
Dipl.-Ing. Yevgeniy Yeryomin
Aufbau eines VoIP-Netzes
Der Einsatz der VoIP-Technologie nimmt in den letzten Jahren aufgrund ihrer Vorteile immer mehr zu. Im Rahmen dieses Projektes soll ein VoIP-Netz mit zahlreichen
Zusatzdiensten und mit Anbindungen an andere TK-Netze aufgebaut werden. Das herkömmliche Telefonnetz soll mit der VoIP-Technologie verglichen und die im PSTN verfügbaren Dienste im VoIP-Netz abgebildet werden. Für das aufzubauende VoIP-Netz
soll eine Management- und Entwicklungsumgebung erstellt werden. Die NAT-, QoSund Sicherheitsproblematiken sollen untersucht und die Lösungen dazu konzipiert und
umgesetzt werden. Als nächstes soll die Mobilität in VoIP-Netzen untersucht werden.
Am Ende des Projektes soll ein sicheres und stabiles VoIP-Netz mit Werkzeugen für
das Management und zu Weiterentwicklung des VoIP-Netzes und der neuer Diensten
entstehen!
Dieses Medienprojekt ist für zwei Personen konzipiert und deswegen in zwei Teile gegliedert:
Teil 1:
1. Im ersten Teil des Projektes ist ein VoIP-Netz mit Anbindung an das ISDNNetz und andere VoIP-Netze aufzubauen. Die Anbindungsmöglichkeiten mehrerer VoIP-Server unter Einsatz von SIP und IAX-Protokollen sollen untersucht
werden. Eine Weboberfläche für Asterisk soll installiert werden. Updatemöglichkeiten, Backup des Systems sollen gewährleistet werden.
2. Das herkömmliche PSTN und die VoIP-Technologie sollen bezüglich Zuverlässigkeit, Management- und Wartungsmöglichkeiten, Sicherheit und Zusatzdienste
untersucht und verglichen werden. Die Zusatzdienste (zum Beispiel: Rückruf,
Halten, interaktive Anrufbeantworter, Transfer usw.) sollen im aufzubauenden
VoIP-Netz implementiert werden.
3. Aufbau von VoIP-Netzen für Endkunden und VoIP-Anbieter (öffentlicher VoIPServer, Hosted-PBX) sind zu untersuchen. Die Konzepte des Aufbaus müssen
erstellt werden.
Teil 2:
1. Eine Management- und Entwicklungsumgebung für ein VoIP-Netz soll aufgebaut
werden. Eine Recherche nach Management- und Entwicklungstools für VoIP ist
durchzuführen. Unter anderem sollen SIP, RTP, RTCP, IAX-Analysatoren, Generatoren und Parser betrachtet werden.
2. Die NAT-Problematik, Sicherheit und QoS für VoIP sollen untersucht werden.
Konzepte zur Lösung dieser Problematiken sollen erstellt und umgesetzt werden.
Die Umsetzung soll im aufzubauenden VoIP-Netz erfolgen.
Inhaltsverzeichnis
i
Inhaltsverzeichnis
Abbildungsverzeichnis
vi
1 Einleitung und Motivation
1
2 PSTN - öffentliche Telefonnetze
2.1 Aufbau des öffentlichen Telefonnetzes . .
2.2 ISDN . . . . . . . . . . . . . . . . . . . .
2.2.1 Arten von ISDN-Anschlüssen . .
2.2.2 Signalisierung und Schnittstellen
2.3 ISDN-Dienste . . . . . . . . . . . . . . .
2.4 IN - Intelligente Netze . . . . . . . . . .
2.5 NGN - Next Generation Networks . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 VoIP
3.1 Bestandteile von VoIP-Netzen . . . . . . . . . . . . . . . . . . . . .
3.2 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Übermittlungsprotokolle . . . . . . . . . . . . . . . . . . . .
3.2.1.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.2 SRTP . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.3 RTCP . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.4 RTSP . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Signalisierungsprotokolle . . . . . . . . . . . . . . . . . . . .
3.2.2.1 H.323 . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.2 SIP - Session Initiation Protocol . . . . . . . . . .
3.2.2.3 Vergleich - H.323 und SIP . . . . . . . . . . . . . .
3.2.2.4 IAX - Inter Asterisk eXchange Protocol . . . . . .
3.2.3 Gateway- und Routing-Protokolle . . . . . . . . . . . . . . .
3.2.3.1 H.248/Megaco (Media Gateway Control Protocol) .
3.3 NAT - Network Address Translation . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5
8
9
10
11
14
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
22
25
28
28
31
31
32
33
33
38
49
51
55
55
57
Medienprojekt Sebastian Güttner, Daniel Ruf
Inhaltsverzeichnis
3.3.1
3.4
3.5
3.6
3.7
NAT-Problematik . . . . . . . . . .
3.3.1.1 SIP . . . . . . . . . . . .
3.3.1.2 IAX . . . . . . . . . . . .
3.3.1.3 Skype . . . . . . . . . . .
3.3.2 Firewalls . . . . . . . . . . . . . . .
3.3.3 STUN, TURN und ICE . . . . . .
3.3.4 Application Layer Gateways (ALG)
Codecs . . . . . . . . . . . . . . . . . . . .
3.4.1 Einführung - Was sind Codecs? . .
3.4.2 Funktionsweise eines Audiocodecs .
3.4.3 Einflüsse während der Übertragung
3.4.4 Bandbreitenanforderungen . . . . .
3.4.5 Qualitative Bewertung der Codecs .
3.4.6 Gegenüberstellung der Audiocodecs
Dienste in VoIP . . . . . . . . . . . . . . .
Phänomen ”Skype” . . . . . . . . . . . . .
Problematik SPIT . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Vergleich von VoIP und PSTN
4.1 Signalisierung und Sprachdatenübertragung . . . . . . . . . . . .
4.2 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Einteilung von Diensten . . . . . . . . . . . . . . . . . . .
4.2.2 Definieren von zu betrachtenden Diensten . . . . . . . . .
4.2.2.1 Dienstgruppe ”Rufnummernidentifizierung” . . .
4.2.2.2 Dienstgruppe ”Rufumlenkung” . . . . . . . . . .
4.2.2.3 Dienstgruppe ”Dienste beim Verbindungsaufbau”
4.2.2.4 Dienstgruppe ”Konferenzdienste” . . . . . . . . .
4.2.2.5 Dienstgruppe ”Gebührendienste” . . . . . . . . .
4.2.2.6 Dienstgruppe ”Interessensgruppen” . . . . . . . .
4.2.2.7 Dienstgruppe ”Diensteeinschränkungen” . . . . .
4.2.2.8 Dienstgruppe ”Dienste von Privatanlagen” . . . .
4.2.3 Umsetzung der definierten Dienste in VoIP . . . . . . . . .
4.2.4 Telefax-Dienst . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.1 FoIP - Fax over IP . . . . . . . . . . . . . . . . .
4.2.4.2 ITU-T T.37 . . . . . . . . . . . . . . . . . . . . .
4.2.4.3 ITU-T T.38 . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
59
59
60
60
62
63
63
64
65
67
68
68
69
70
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
75
78
78
80
81
82
82
83
83
83
83
84
84
90
90
91
92
Inhaltsverzeichnis
4.3
4.4
4.5
4.6
4.7
iii
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Definieren von Sicherheitszielen . . . . . . . . . . . . . .
4.3.1.1 Integrität und Authentizität . . . . . . . . . . .
4.3.1.2 Vertraulichkeit . . . . . . . . . . . . . . . . . .
4.3.1.3 Verfügbarkeit . . . . . . . . . . . . . . . . . . .
4.3.2 Klassifizieren von Angriffsszenarien . . . . . . . . . . . .
4.3.2.1 Auswirkungen von Angriffen . . . . . . . . . . .
4.3.3 Relevanz der Angriffsszenarien . . . . . . . . . . . . . . .
4.3.4 Absichern von VoIP-Netzen . . . . . . . . . . . . . . . .
4.3.4.1 Absichern von Systemkomponenten (Hardware)
4.3.4.2 Absichern von Systemkomponenten (Software) .
4.3.4.3 Absichern des Systems . . . . . . . . . . . . . .
4.3.4.4 Absichern der Datenströme . . . . . . . . . . .
Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . .
Management und Wartung . . . . . . . . . . . . . . . . . . . . .
4.5.1 Allgemeine Architektur des Netzmanagements . . . . . .
4.5.2 FCAPS . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3 TMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.4 Netzmanagementsystem Rebell . . . . . . . . . . . . . .
4.5.5 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.6 Das OSI-Netzmanagement . . . . . . . . . . . . . . . . .
4.5.7 Netzmanagement im Vergleich . . . . . . . . . . . . . . .
Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Das ENUM-Verfahren . . . . . . . . . . . . . . . . . . .
Notrufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Konzepte
5.1 SOHO - Small Office / Home Office . . . . . . . . . . .
5.2 Unternehmensnetz mit Anbindung an das PSTN . . . .
5.2.1 Realisierung mit einer LAN-PBX . . . . . . . .
5.2.2 Realisierung mit einer Software-PBX . . . . . .
5.2.3 Hosted-PBX . . . . . . . . . . . . . . . . . . . .
5.2.4 Vergleich LAN-, Soft- und Hosted-PBX . . . . .
5.3 Unternehmensnetz mit verteilten Niederlassungen . . .
5.3.1 Unternehmensnetz mit zentraler Telefonanlage .
5.3.2 Unternehmensnetz mit verteilten VoIP-Anlagen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
94
96
96
96
96
97
100
100
102
103
104
106
111
111
112
113
113
114
114
115
116
117
119
.
.
.
.
.
.
.
.
.
121
121
122
122
124
125
126
127
127
128
Inhaltsverzeichnis
5.4
iv
VoIP aus Providersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6 Einrichten eines VoIP-Netzes auf Basis von ”Asterisk”
6.1 Das Einrichten des Grundsystems . . . . . . . . . . .
6.2 Benutzerprofile und Kommunikationskanäle . . . . .
6.3 Das Einrichten von Diensten . . . . . . . . . . . . . .
6.4 Updates . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
132
133
133
134
135
7 Entwicklungsumgebung
136
7.1 Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Literaturverzeichnis
144
8 Abkürzungsverzeichnis
151
9 Anhang
9.1 Sprachcodecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 ITU-T G.711 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 ITU-T G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.3 ITU-T G.723.1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.4 ITU-T G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.5 ITU-T G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.6 ITU-T G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.8 iLBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.9 Speex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Ergänzende Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Ergänzende Dienste auf Basis von Leistungsmerkmalen des öffentlichen Netzes . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Ergänzende Dienste auf Basis von Leistungsmerkmalen des Intelligenten Netzes . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Ergänzende Dienste auf Basis der PBX . . . . . . . . . . . . . .
9.3 Dokumentation - Einrichten eines VoIP-Netzes . . . . . . . . . . . . . .
9.3.1 Installation eines Grundsystems . . . . . . . . . . . . . . . . . .
9.3.1.1 Betriebssystem . . . . . . . . . . . . . . . . . . . . . .
9.3.1.2 Einbinden der ISDN-Karte in das System . . . . . . .
9.3.1.3 Einrichten eines ”Mail Transfer Agent” . . . . . . . . .
9.3.2 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
157
158
158
158
158
159
159
159
160
160
160
161
161
165
165
169
169
169
170
170
173
Inhaltsverzeichnis
9.4
9.5
9.6
9.7
v
9.3.2.1 Asterisk mit ISDN vertraut machen . . . . . . . . .
9.3.2.2 Deutsche Sprachfiles . . . . . . . . . . . . . . . . .
9.3.3 FreePBX - Die grafische Oberfläche . . . . . . . . . . . . . .
9.3.3.1 Umstellen auf deutsche Sprachfiles . . . . . . . . .
9.3.4 Einrichten von Nutzern . . . . . . . . . . . . . . . . . . . . .
9.3.5 Kommunikation mit der Außenwelt . . . . . . . . . . . . . .
9.3.5.1 Einbinden eines VoIP-Providers . . . . . . . . . . .
9.3.5.2 Anbindung an das öffentliche Telefonnetz via ISDN
9.3.6 Einrichten von Diensten . . . . . . . . . . . . . . . . . . . .
9.3.6.1 Mailbox - Voicemail . . . . . . . . . . . . . . . . .
9.3.6.2 Music on Hold . . . . . . . . . . . . . . . . . . . .
9.3.6.3 Halten, Makeln, und Transfer von Gesprächen . . .
9.3.6.4 Konferenzschaltungen . . . . . . . . . . . . . . . .
9.3.6.5 Parallelruf, Ring Groups . . . . . . . . . . . . . . .
9.3.6.6 Blacklist . . . . . . . . . . . . . . . . . . . . . . . .
9.3.6.7 Tag- und Nachtschaltung . . . . . . . . . . . . . .
9.3.6.8 IVR - digitaler Sekretär . . . . . . . . . . . . . . .
9.3.6.9 Anrufweiterschaltung - Call Forwarding . . . . . .
9.3.6.10 DND - Bitte nicht stören . . . . . . . . . . . . . .
9.3.6.11 Queues - Warteschlangen . . . . . . . . . . . . . .
9.3.6.12 Follow Me . . . . . . . . . . . . . . . . . . . . . . .
Ausgabe von Capiinfo . . . . . . . . . . . . . . . . . . . . . . . . .
Beispielkonfiguration einer Tag/Nachtschaltung . . . . . . . . . . .
Beispielkonfiguration des IVR-Moduls . . . . . . . . . . . . . . . . .
Angriffsmöglichkeiten und bedrohte Sicherheitsziele . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
175
176
178
180
182
184
184
187
190
190
192
193
193
194
195
195
195
196
197
197
198
199
200
201
202
ABBILDUNGSVERZEICHNIS
vi
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
Einfaches Telefonnetz . . . . . . . . . . . . . . . . . . . . . .
Einfaches Telefonnetz mit Switch . . . . . . . . . . . . . . .
Aufbau eines Fernsprechnetzes, [67] Seite 111 . . . . . . . . .
Aufbau Intelligenter Netze, [67] Seite 111 . . . . . . . . . . .
Prinzipielle Struktur eines Next Generation Networks (NGN)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
15
18
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
Komponenten eines VoIP-Netzes auf Basis von SIP . . . . . . . . .
TCP/IP-Protokollfamilie ([2]) . . . . . . . . . . . . . . . . . . . . .
Transport von RTP-Paketen mit UDP und IP . . . . . . . . . . . .
Elemente von H.323 (Abb. von [42]) . . . . . . . . . . . . . . . . . .
Definition eines H.323-Terminals . . . . . . . . . . . . . . . . . . . .
Die H.323-Protokollsuite ([33], S.14) . . . . . . . . . . . . . . . . . .
SIP-Verbindungsauf und -abbau im Detail . . . . . . . . . . . . . .
Beispiel für eine SIP URI . . . . . . . . . . . . . . . . . . . . . . . .
Auszug aus einem SIP/SDP-Header (Sprachkommunikation) . . . .
Sprachverbindung zwischen zwei SIP-User Agents . . . . . . . . . .
IAX-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . .
Evolution der Gateway-Steuerungsprotokolle [53] . . . . . . . . . .
Einsatzbereich von H.248/Megaco [53] . . . . . . . . . . . . . . . .
Auszug aus einem SIP-Header zeigt Fehler bei der NAT-Umsetzung
ITU-Empfehlung G.114 . . . . . . . . . . . . . . . . . . . . . . . .
Struktur eines IP-Telefonie-Pakets . . . . . . . . . . . . . . . . . . .
Aufbau des ”Skype”-Netzwerkes ([3]) . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
25
29
34
35
36
40
40
41
43
53
55
56
58
66
67
71
4.1
4.2
4.3
Struktur des Dienstbegriffes ([74]) . . . . . . . . . . . . . . . . . . . . . 78
Definition von Tele- und Übermittlungsdiensten ([17],S.314) . . . . . . 79
Aufbau eines ENUM-DNS-Eintrages . . . . . . . . . . . . . . . . . . . 118
5.1
5.2
Aufbau eines SOHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Unternehmensnetz mit einer LAN-PBX . . . . . . . . . . . . . . . . . . 123
ABBILDUNGSVERZEICHNIS
vii
5.3
5.4
5.5
5.6
5.7
Unternehmensnetz mit einer Software-PBX . . . . . . . . . . .
Hosted-PBX - Auslagern der Telefonanlage zu einem Provider
Firmenzentrale und Niederlassungen mit zentraler Anlage . . .
Firmenzentrale und Niederlassungen mit eigenen Anlagen . . .
Infrastruktur eines VoIP-Providers . . . . . . . . . . . . . . .
6.1
Hardwaredimensionierung . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.1
7.2
7.4
7.3
7.5
7.6
grundlegender Aufbau der Management- und Entwicklungsumgebung
grafische Darstellung von VoIP-Verbindungen [76] . . . . . . . . . . .
RTP-Stream Analyse (Hervorhebung von Übertragungsfehlern) [76] .
RTP-Stream Überwachung (Latenz, Jitter usw.) [76] . . . . . . . . .
VoIP-Verbindungsübersicht [83] . . . . . . . . . . . . . . . . . . . . .
Abspielen von Mediendaten (z.B. RTP-Streams) [83] . . . . . . . . .
.
.
.
.
.
.
136
138
139
139
139
140
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
Die grafische Oberfläche . . . . . . . . . . . . .
Änderungen übernehmen . . . . . . . . . . . . .
Sprache auf ”deutsch” umstellen . . . . . . . . .
Hinzufügen eines SIP-Nutzers . . . . . . . . . .
Änderungen übernehmen . . . . . . . . . . . . .
Voicemail - Konfiguration . . . . . . . . . . . .
Ausgabe von capiinfo . . . . . . . . . . . . . . .
Beispielkonfiguration für den Tag/Nacht-Modus
Definieren eines ”digitales Sekretärs” . . . . . .
.
.
.
.
.
.
.
.
.
180
181
181
182
182
190
199
200
201
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
124
125
127
128
129
1
Die Kommunikation über große Entfernungen ist eine der größten Errungenschaften
der Menschheit. In der Steinzeit geschah dies mit Hilfe von Rauchzeichen, später wurden Boten eingesetzt:
So gibt es die Legende von Pheidippides, einem Boten, welcher nach der Schlacht von
Marathon um 490 vor Christus zwischen den Persern und Athenern, die Botschaft des
Sieges der Armee Athens direkt nach Athen brachte. Dies über eine Entfernung von
rund 40 km, nach Überbringen der Nachricht brach Pheidippides allerdings vor Erschöpfung tot zusammen ([92]).
Im heutigen Zeitalter der digitalen Kommunikation ist ein solches Szenario undenkbar. Jeden Tag werden unzählige Nachrichten und Informationen rund um den Globus
übertragen: Übertragungszeiten von mehreren Stunden oder Tagen sind nicht akzeptabel!
Den Grundstein für den heutigen hohen Komfort und die hohen Übertragungsgeschwindigkeiten, bei der Übermittlung von beliebigen Nachrichten und Informationen, legten
Pioniere wie Philipp Reis, Alexander Graham Bell oder auch Claude Chappe.
Chappe entwickelte im Jahre 1794 den ersten optischen Telegraphen. Damit wurde
für die Übertragung eines Zeichens von Paris nach Lille (Entfernung 212km), über 23
Postenstationen, eine Zeit von gerade einmal 2 Minuten benötigt! ([17],S.1)
Am 7. März 1876 war es Graham Bell, der das Telefon zum Patent anmeldete. Dies war
der Auslöser einer Revolution: 1877 ging in Boston das erste Telefonnetz in Betrieb, 5
Jahre später war ein solches in fast allen amerikanischen Großstädten etabliert!
Diese analogen Telefonnetze wuchsen zu einem großen weltumspannenden Telefonnetz zusammen und wurden sukzessive erweitert, beispielsweise ab 1975 um das IDN
(Integriertes Text- und Datennetz). Jedoch stiessen sie rasch an ihre Grenzen.
1989 wurde das ISDN (Integrated Services Digital Network) standardisiert, 1993 das
Euro-ISDN in Deutschland eingeführt (siehe 2.2). Das digitale ISDN-Telefonnetz vereint viele Dienste, wie Sprachübertragung, Faxübertragung, sowie leitungs- und paketvermittelte Datenübertragung in ein Netz und hat die analogen Telefonnetze fast
verdrängt.
2
Parallel zu den öffentlichen Telefonnetzen entwickelte sich aus dem 1979 geborenen
ARPANET, einem Projekt der Advanced Research Project Agency (ARPA) des USVerteidigungsministeriums, das Internet. Ursprünglich zur Vernetzung von Universitäten und Forschungseinrichtungen gedacht und mit dem Ziel die knappen Rechenkapazitäten sinnvoll zu nutzen, wurde das Internet in kürzester Zeit ein Netz, über welches
Dienste jeglicher Art angeboten wurden.
Solche Dienste waren anfangs Telnet, FTP und E-Mail, später wurden Dienste wie Onlinespiele, Filesharing, Blogs, Informationsseiten (Wikis, vgl. www.wikipedia.org) und
”Instant Messenger”-dienste integriert.
In der heutigen Zeit sind Multimedia- und soziale Aspekte im Vordergrund: Portale
wie Youtube, Facebook und Co tragen viel zur Wahrnehmung des Internets bei.
Aufgrund der großen Verbreitung und Akzeptanz des Internets liegt es nahe, den
Telefon-Dienst in das Internet zu implementieren.
Im Gegensatz zu den herkömmlichen Telefonnetzen, welche leitungsvermittelt arbeiten, also exklusive Ressourcen zur Verfügung stellen, werden die Daten im Internet
paketorientiert übertragen. Bei der paketorientierten Übertragung teilen sich alle die
verfügbaren Ressourcen, was beim Telefon-Dienst zu einer effizienteren Übertragung
führen kann:
Bei einem Telefongespräch wird nicht durchgehend gesprochen, unter anderem sorgen
Sprachpausen und ”Überlegzeiten” zu einer ineffizienten Auslastung der Ressource ”Leitung”. Im Internet hingegen, werden Sprachpausen beim ”Verpacken” der Sprache in
Pakete berücksichtigt. Die in dieser Zeit freigewordenen Übertragungsressourcen werden anderen Nutzer des Internets zur Verfügung gestellt. Eine effizientere Auslastung
von Ressourcen
Diese Arbeit beschäftigt sich mit VoIP (Sprache über Internet Protokoll), also der
Übertragung von Sprache über paketvermittelte (IP-)Netze wie dem Internet und gliedert sich in 2 Teile:
Im theoretischen Teil, wird auf Aufbau und Funktionsweise der herkömmlichen Telefonnetze und der VoIP-Technik eingegangen, Vor- und Nachteile beider betrachtet
und anschließend beide Techniken anhand wichtiger Kriterien, wie QoS (Quality of
Service), miteinander verglichen.
Der praktische Teil der Arbeit beschäftigt sich mit dem Aufbau eines eigenen VoIPNetzes (auf Basis von Asterisk und SIP) mit Anbindung an andere Netze und einer
Management- und Entwicklungsumgebung.
3
Das erste Telefon
Die Erfindung eines Gerätes zur Übertragung von Sprache und akustischen Signalen
legte den Grundstein der Telefonie, wie wir sie heute kennen.
Graham Bell, ein Lehrer für Taubstumme, arbeitete seit 1873 neben seiner Lehrtätigkeit an einem Apparaten zur Übertragung von Nachrichten, welchen er als ”harmomischen Telegrafen” bezeichnete. Ab 1875 widmete er sich ausschließlich dieser Tätigkeit,
welche am 2.Juni 1875 durch einen Zufall zum Erfolg führte. Zusammen mit Thomas
A. Watson, einem 20-jährige Elektromechaniker, entdeckte er zufällig die elektromagnetische Tonübertragung.
”Mit diesen Erkenntnissen entwarf Bell unmittelbar danach sein erstes Telefon, das
Watson am nächsten Tag baute. Es bestand aus einem Holzrahmen, in dem einer von
Bells Mehrfachtelegrafensendern eingelassen war. Das lose Ende der Metallfeder war
über einen Korken an einer Membran befestigt. Diese Membran war wiederum über
einen Einsprachetrichter gespannt. Analog zu diesem Geber wurde der Hörer aufgebaut, der sich von diesem nur durch die optische Gestaltung unterschied. Allerdings
war mit diesem elektromagnetischen Telefon nur eine sehr unbefriedigende Sprachübertragung möglich.”(zitiert von [7])
Dieser Apparat wurde am 7. März 1876 mit dem Titel ”Improvement in Telegraphy”
unter der Patentnummer 174,465 erteilt.
Auf deutscher Seite ist bei der Entwicklung eines Telefonapparates Philipp Reis zu
nennen, welcher bereits 1861 einen solchen entwickelte. Mit seiner Entwicklung fand
die erste öffentliche Vorführung einer Sprach- und Musikübertragung am 26. Oktober
1861 vor dem Physikalischen Verein in Frankfurt am Main statt.
Als eigentlicher ”Erfinder” des ersten Telefonapparates ist der italienisch-amerikanische
Ingenieur Antonio Meucci. ”Unabhängig von Philipp Reis versuchte Meucci seit 1854
ein Gerät für eine Fernsprechverbindung herzustellen; ein erster Apparat von 1857 ist
bekannt. 1871 meldete Meucci das erste Patent für ein Telefon an, konnte die Patentgebühr aber nur bis 1874 entrichten und musste es somit verfallen lassen. Nach
4
der Patentanmeldung von Bell 1876 entwickelte sich ein langjähriger Rechtsstreit um
die Urheberschaft des Telefons. Die amerikanischen Behörden versuchten daraufhin ab
1887, das bellsche Patent zu annullieren. Mit dem Tod Meuccis (1889) und dem regulären Auslaufen des Patents wurde das Verfahren später eingestellt. Meucci wurde
mit Beschluss des amerikanischen Repräsentantenhauses vom 11. Juni 2002 posthum
als Erfinder des Telefons anerkannt.”(zitiert von [7])
Die Anfänge des öffentlichen Telefonnetzes
Mit der Entwicklung eines Telefons war die Kommunikation zwischen zwei örtlich getrennten Gesprächsteilnehmern möglich, sofern zwischen den Standorten ein physikalisch Kabel verlegt war. Bei mehreren Teilnehmern eines solchen Netzes wurde der
Aufwand der Verkabelung immer gewaltiger, jeder Versuch jeden Menschen auf der
Welt mit jedem möglichen Gesprächsteilnehmers zu vernetzen schier unmöglich.
Um dieses Problem zu umgehen wurde ein Mechanismus entwickelt, welcher eine Vermittlerrolle zwischen den Teilnehmern einnimmt: ein Gesprächsvermittler oder Switch.
Dieser Switch war am Anfang noch ein Mensch, welcher den Anrufer fragte, mit wem
er sprechen wollte und daraufhin die beiden Gesprächsteilnehmer manuell miteinander
verband. Später wurden diese menschlichen Vermittler durch elektronische Switches
ersetzt.
Abbildung 2.1: Einfaches Telefonnetz Abbildung 2.2: Einfaches Telefonnetz mit
Switch
Mit diesem Konzept war das POTS (Plain Old Telephone Service), das analoge Telefonnetz, geboren. Begrifflich wurde später aus dem POTS das PSTN (Public Switched
Telephone Network), das öffentliches leitungsvermitteltes Telefonnetz.
Mittlerweile ist der Begriff PSTN allerdings veraltet; heutzutage wird vom GSTN (General Switched Telephone Network) gesprochen, da neben der Telefonie viele weitere
Dienste in das Netz integriert sind.[91]
5
Die heutigen Telefonnetze sind die technische Basis (hauptsächlich) für die Telefonie
zwischen räumlich getrennten Teilnehmern. Im folgenden Abschnitt wird beschrieben,
wie diese Netze aufgebaut sind. Anschließend wird das weit verbreitete ISDN beleuchtet, auf die im ISDN verfügbaren Dienste eingegangen, sowie IN (Intelligente Netze)
und NGN (Next Generation Networks) beschrieben.
2.1 Aufbau des öffentlichen Telefonnetzes
Wie bereits erwähnt, dient das öffentliche Telefonnetz für das Erbringen von Sprachdiensten (Telefonie). Es besteht aus einer TK-Infrastruktur, welche sich aus Übertragungs- und Vermittlungseinrichtungen zusammensetzt. Die heutigen öffentlichen Fernsprechnetze haben eine hierarchische Struktur, bestehend aus mehreren Teilebenen und
Teilnetzen.
Abbildung 2.3: Aufbau eines Fernsprechnetzes, [67] Seite 111
Die Teilnehmerebene
Die unterste Ebene des Fernsprechnetzes ist die Teilnehmerebene, welche aus der Teilnehmeranschlussleitung und dem Teilnehmeranschluss besteht. Über die Teilnehmeranschlussleitung, welche meist aus einer Kupferdoppelader besteht und auch ”Letzte
Meile” genannt wird, ist der Teilnehmer an die Ortsvermittlungsstelle angebunden.
Der Teilnehmeranschluss, welchem eine eindeutige Nummer zugewiesen ist, ist für den
Teilnehmer die Schnittstelle zum Telefonnetz.
Angeschlossen werden können Endgeräte (Telefone, Faxgeräte) oder Telefonanlagen,
6
welche mehreren Geräten den Zugang zum Telefonnetz bieten.
Mögliche Anschlussarten sind:
• Analoger Anschluss
Analoger Telefonanschluss, 1 Kanal mit 3,4 kHz Bandbreite (56 kbit/s)
• ISDN-Basisanschluss (BRI - Basic Rate Interface)
Besteht aus 2xB-Kanälen mit 64 kbit/s und einem D-Kanal mit 16 kbit/s
• ISDN-Primärmultiplexanschluss (PRI - Primary Rate Interface)
Besteht aus 30 B-Kanälen und einem 64 kbit/s D-Kanal
• DSL
DSL (Digital Subscriber Line) ist eine Technik zur Bereitstellung von BreitbandInternetzugängen über Telefonnetze
Ortsnetz
Ein Ortsnetz, auch als Teilnehmer- oder Zugangsnetz bezeichnet, besteht aus einer
oder mehreren Teilnehmervermittlungsstellen (Ortsvermittlungsstellen), den Endeinrichtungen (zum Beispiel Telefonen) sowie den Leitungen zwischen den Vermittlungsstellen und den Leitungen zur Endeinrichtung ([67], Seite 112). Teilnehmer innerhalb
eines Ortsnetzes können sich durch Wählen der entsprechenden Rufnummer erreichen,
das sich alle im gleichen Nummerierungsbereich befinden. Nur beim Anwählen von Gesprächsteilnehmer in anderen Ortsnetzen muss dies dem Netz durch Vorwählen einer
”Verkehrsausscheidungsziffer” mitgeteilt werden, das Gespräch wird an die nächsthöhere Ebene (hier nationales Fernsprechnetz) weitervermittelt. Jedem Ortsnetz ist eine
eindeutige Ortskennzahl zugewiesen, worüber sich jedes Ortsnetz erreichen lässt.
Weiterhin verwaltet das Ortsnetz die Endeinrichtungen, vermittelt die abgehenden und
ankommenden Gespräche zu den Teilnehmern, vergibt und vermittelt Notrufnummern
und verwaltet die Daten des Teilnehmers (Art des Anschlusses, gebuchte Dienste).
Ortsnetze haben meist einen sternförmigen Aufbau ([64] Seite 88).
Nationales Fernnetz
Das nationales Fernnetz ist die nächsthöhere Hierarchieebene der Orts-/Teilnehmernetze und verbindet diese miteinander, weshalb auch von einem Verbindungsnetz gesprochen wird.
Sie vermitteln Gespräche zwischen Teilnehmern aus verschiedenen Ortsnetzen. Zum
7
Erreichen eines Teilnehmers ausserhalb des eigenen Ortsnetzes muss vor die Teilnehmerrufnummer die Ortsnetzkennziffer (mit ”0” beginnend) gewählt werden.
Fernnetze sind in der Regel aus einer Kombination von Stern- und Maschenstruktur
aufgebaut ([64])
Internationales Fernnetz
Die oberste Ebene des Fernsprechnetzes bildet das ”Internationale Fernnetz”, welches
die verschiedenen nationalen Fernnetze miteinander verbindet. Die internationales Fernebene wird in Europa aus dem Ortsnetz durch die Verkehrsausscheidungsziffer ”00”
erreicht. Ein Teilnehmer in einem europäischen Nachbarland wird durch die Länderkennzahl + Ortskennzahl + Teilnehmernummer erreicht (Beispiel: 0049 + 3677 +
1234). [67]
Wie leicht zu erkennen ist, bilden Vermittlungsstellen die Knotenpunkte im öffentlichen Telefonnetz. Zu ihren Aufgaben zählt unter anderem:
• Erkennen des Verbindungswunsches und Identifizierung der gewünschten Endstelle
• Aufforderung der rufenden Endstelle zur Wahl
• Suchen und Durchschalten des Verbindungsweges
• Anschlußprüfung der gerufenen Endstelle auf Besetztzustand
• Überwachen der Verbindung und Erkennen von Verbindungsabbrüchen
• Erfassen und Zählen der aufkommenden Tarifeinheiten -> Gesprächsentgelte
Zusätzlich zu der Unterteilung in hierarchische Ebenen, wird ein Telefonnetz in verschiedene Unternetze unterteilt. Diese verschiedene Unternetze haben dabei jeweils
spezielle Aufgaben:
• Zugangsnetz
..zur effizienten Anbindung der Teilnehmer an das Verbindungsnetz
• Verbindungsnetz
Dieses Teilnetz besteht aus den einzelnen (Orts-)Vermittlungsstellen und verknüpft diese miteinander. Die Hauptaufgabe besteht darin, die Kommunikationskanäle zwischen den Teilnehmern zu schalten und zu verwalten.
8
• Signalisierungsnetz
Über dieses Netz werden alle Signalisierungsinformationen übertragen. Weitere
Informationen zur ”Signalisierung” in Kapitel 4.1.
2.2 ISDN
In der heutigen Gesellschaft werden, für der Kommunikation untereinander, mehr Möglichkeiten erwartet als reine Telefonie.
Bereits im Jahre 1975 wurde das ”IDN” (Integriertes Text- und Datennetz) eingeführt.
Es basierte auf dem EDS-Vermittlungssystem von Siemens und bildete ein digitales
Fernmeldenetz, welches verschiedene Dienste bündeln sollte. Folgende Dienste wurden
im IDN zusammengefasst:
• das Telex-Netz - für Telegraphie
• das Gentex-Netz - internes Netz der Postverwaltungen für die Telegramm-Übermittlung
• das Direktrufnetz, das Standleitungen bereitstellte, damals mit maximal 9.600
bit/s
• das Datex-L-Netz für leitungsvermittelte digitale Wählverbindungen
• das Datex-P-Netz für paketvermittelte Wählverbindungen
Transportiert wurde das IDN auf Basis des damaligen (analogen) Telefonnetzes.[88]
In den 70er Jahren erreichte die Digitaltechnik auch die Telefonnetze: Die verwendeten
Bauelemente wurden immer leistungsfähiger und der Raumbedarf nahm gleichzeitig
ab. Parallel dazu fielen die Preise der Bauelemente, trotz höherer Leistungsfähigkeit.
([17], S.34) - Zwei Aussagen, die auch heute immer noch zutreffend sind!
Digitale Vermittlungsstellen sollten für mehr Komfort und bessere Auslastung der Leitungen sorgen. ”Die zuständige Organisation, das Comité Consultatif International
Téléphonique et Télégraphique (CCITT, heute Internationale Fernmeldeunion (ITU)),
erarbeitete dazu technische Spezifikationen (Recommendations) für ein digitales Telefonnetz, die, unter dem Namen ISDN, 1980 erstmals verabschiedet wurden ”([89]).
Zusätzlich fiel 1979 die Entscheidung zur Digitalisierung des Fernsprechnetzes ([64],
S.26).
9
1989 haben sich Deutschland, Frankreich, Großbritannien und Italien in einem ”Memorandum of Understanding” dazu verpflichtet einen gemeinsamen ISDN-Standard
einzuführen: ”Euro-ISDN”. Vier Jahre später waren diesem Memorandum 26 ISDNNetzbetreiber in 20 europäischen Staaten beigetreten.
Am 1.Oktober 1993 begann der Euro-ISDN-Start in 20 europäischen Ländern. In einigen Ländern wurde aber bereits vor 1993 ein nationales ISDN eingeführt, beispielsweise
in Deutschland das ”1TR6-ISDN” und in der Schweiz das ”Swiss-Net” ([67], S. 392).
Im Euro-ISDN sind einheitliche Schnittstellen und ein einheitliches D-Kanal-Protokoll
(DSS1) für die Signalisierung festgelegt.
Unterschiede zum analogen Telefonanschluss
• vollständig digitale Übertragung bis zum Endgerät, dadurch wird eine höhere
Sprachqualität erreicht (im Vergleich zur analogen Übertragung)
• 1 Anschluss mit mehreren, von einander unabhängigen, Kanälen möglich
• 1 Anschluss mit bis zu 10 Rufnummern (MSNs)
• seperater Signalisierungskanal (D-Kanal)
• verschiedenste Dienste nutzbar, ohne gegenseitige Einflussnahme (Telefongespräch
und ankommendes Fax auf anderem Kanal beeinflussen sich nicht gegenseitig)
2.2.1 Arten von ISDN-Anschlüssen
ISDN-Basisanschluss (BRI)
Der normale ISDN-Anschluss wird Basisanschluss genannt. Dieser stellt 2, von einander
unabhängige, Nutzkanäle (B-Kanäle) mit einer Übertragungsrate von jeweils 64 kbit/s
für die Übertragung von digitalen Nutzdaten (Sprache, Daten,..) zur Verfügung. Die
Datenrate von 64 kbit/s setzen sich aus dem Produkt der Abtastung des Signals mit
8 kHz und der anschließenden AD-Wandlung zu 8Bit-Worten (PCM-Kodierung, vgl.
G.711 9.1.1).
Zusätzlich, zu den beiden Nutzkanälen, gibt es einen Kanal für die Signalisierung: den
D-Kanal, mit einer Datenrate von 16 kbit/s. Die Auslastung des D-Kanals ist äußert
gering: Ein ISDN-Telefon lastet den D-Kanal nur zu 5 Prozent aus ([67],S.400).
Basisanschlüsse sind verfügbar als:
10
• Mehrgeräteanschluss (Point-to-Multipoint) zum Anschluss von bis zu 8 ISDNEndgeräten
• Anlagenanschluss (Point-to-Point) zum Anschluss einer einzigen Telekommunikationseinrichtung, zum Beispiel einer Telefonanlage
Primärmultiplexanschluss (PRI)
Der Primärmultiplexanschluss kommt bei Einrichtungen mit höheren Anforderungen
an die Übertragungskapazität zum Einsatz, beispielsweise in größeren Firmen.
Er stellt 30 Nutzkanäle mit jeweils 64 kbit/s, einen 64 kbit/s Signalisierungskanal und
einen 64 kbit/s breiten Synchronisationskanal zur Verfügung.
2.2.2 Signalisierung und Schnittstellen
Im ISDN-Teilnehmerbereich sind folgende Schnittstellen standardisiert ([17],S.329):
• S0 - Ist ein Bussystem zum Anschluss von maximal 8 Endgeräten hinter einen
Netzabschluss (NT)
• UK0 - Für die Verbindung vom NT zur digitalen Ortsvermittlungsstelle (DIVO)
• Up0 - Von TK-Anlagen zu angeschlossenen Einzelgeräteanschlüssen
• S2M - Bei Punkt-zu-Punkt-Verbindungen, zum Beispiel eine TK-Anlage an einem
NT
• UK2 - Primärmultiplexanschluss via Kupferleitung an DIVO
• UG2 - Primärmultiplexanschluss via Glasfaser an DIVO
Signalisierung im ISDN
Beim ISDN wird die Signalisierung, d.h. der Austausch von Steuerinformation, über
einen seperaten Kanal (Out-of-Band-Signalisierung) realisiert. Zwischen Teilnehmern
wird dabei der D-Kanal genutzt (D-Kanal-Protokoll DSS1), die Signalisierung zwischen
den Vermittlungsstellen kommt das Signalisierungsverfahren Nr. 7 (SS7) zum Einsatz
(mit 64 kbit/s je Kanal).
Weitere technische Informationen zum Thema ISDN sind hier zu finden:
D-Kanal-Protokolle DSS1 und 1TR6: [64], S.133ff
Schnittstellen: [17], S.329ff
Allgemeine Informationen: [56], [84], [86]
11
2.3 ISDN-Dienste
Der Dienstbegriff ist wie folgt definiert:
Als Dienst bezeichnet man in der Telekommunikation die Fähigkeit eines Telekommunikationsnetzes Informationen einer bestimmten Art zu übertragen und zu vermitteln
([67]).
In diesem Abschnitt wird ein kurzer Überblick über verfügbare Dienste im Netz der
”Deutschen Telekom” gegeben.
Ausführliche Informationen zum Thema ”Dienste” sind in Abschnitt 4.2 zu finden!
Welche Dienstmerkmale sind implementiert?
Basis der folgenden Angaben ist das Angebot der ”Deutschen Telekom” 1 an DienstMerkmalen der angebotenen T-ISDN-Anschlüsse.
Bei allen T-ISDN-Angeboten der Deutschen Telekom sind folgende Dienstmerkmale
realisiert und stehen somit jedem ISDN-Anschluss zur Verfügung ([71]):
• 2 (von einander unabhängige) Leitungen und 3 Rufnummern (MSN)
wobei dies allerdings zu den Grundeigenschaften eines ISDN-Anschlusses gehört
• Anrufweiterschaltung (Call Deflection (CD))
Ankommende Anrufe werden auf einen frei wählbaren Anschluss umgeleitet. Die
Kosten der Weiterleitung trägt der Angerufene. Allerdings sind 4 Setups fest
vorgegeben:
– sofortige Weiterleitung (Call Forwarding Unconditional (CFU))
– Weiterleitung bei Besetzt (Call Forwarding Busy (CFB))
– Weiterleitung nach 20 Sekunden Klingeln (Call Forwarding No Reply (CFNR))
– Nach dem Rufaufbau (Normal Call Transfer (NCT))
• Anklopfen (Call waiting (CW))
Wenn während eines laufenden Gespräches ein zusätzliches Anruf erfolgt, wird
dies durch ein akustisches Signal mitgeteilt. Je nach Fähigkeiten des Endgerätes
kann dieser zusätzliche Anruf angenommen, abgewiesen oder ignoriert werden.
• Halten (Call Hold (HOLD))
Parken einer Verbindung und führen eines zusätzlichen Gespräches am gleichen
Apparat.
1
Quelle: www.telekom.de, Stand April 2008
12
• Makeln
Umschalten zwischen 2 laufenden Gesprächen; keine Dreierkonferenz.
• Dreierkonferenz (Three Party (3PTY))
Telefonkonferenz mit 2 anderen Teilnehmern
• Rufnummernübermittlung (Calling Line Identification Presentation (CLIP))
Übermittlung der eigenen Rufnummer zum Endgerät des gewählten Gesprächspartners, bereits vor der Annahme des Gespräches.
• Rufnummernanzeige
Anzeige der Rufnummer der Anrufers, sofern dieser die Rufnummerübermittlung
aktiviert hat und das eigene Endgerät diese Funktion unterstützt.
• Rückruf bei Besetzt (Completion of Calls to Busy Subscriber (CCBS))
Wenn der angewählte Telefonanschluss besetzt ist, realisiert diese Funktion eine
(akustische) Benachrichtigung, sobald der gewünschte Anschluss wieder frei ist!
• Rückruf bei Nichtmelden (Completion of Calls on No Reply (CCNR))
Realisiert eine Benachrichtigung, wenn ein Teilnehmer wieder telefoniert, welcher
vorher nicht erreicht wurde. Sobald er sein aktuelles Gespräch beendet, erfolgt
die (akustische) Benachrichtigung.
• Rechnung Online
(keine eigentliches Dienstmerkmal)
• SMS/MMS ins Festnetz
• T-Net-Box
Persönlicher Anrufbeantworter im Netz.
Zusätzlich zu diesen Funktionen lassen sich weitere Dienstmerkmale (kostenpflichtig)
zubuchen:
• Sicherheitspaket
– veränderbare Anschlusssperre
Vom eigenen Anschluss kann nur mit Einverständnis telefoniert werden.
Sperren bestimmter Rufnummernblöcke (zum Beispiel nur Ortsgespräche
erlaubt, Rest wird gesperrt).
– veränderbare Rufnummernsperre
Gezieltes Sperren einzelner Rufnummern
13
– zurückweisen unerwünschter Rufnummern
– Annahme erwünschter Anrufer
– Zurücksetzen (Reset und PIN) der Sicherheitsdienste
• Tarifinformation während einer Verbindung (Advice of Charge: charging Information during the call (AOC-D))
• Tarifinformation am Ende einer Verbindung (Advice of Charge: charging Information at the end of the call (AOC-E))
• Selektive Anrufweiterschaltung
Bestimmte Anrufer werden auf eine andere ausgewählte Rufnummer umgeleitet.
• Parallelruf
Signalisieren eines Anrufes an mehreren Endgeräten.
• Telefonkonferenzen (Conference Call (CONF))
mit mehr als 3 Teilnehmern (kostenpflichtig)
• R-Gespräche (Freephone (FPH))
Der Angerufene trägt die Kosten des Gespräches.
ISDN-Telefonanlagen bieten zusätzlich zu diesen Dienstmerkmalen weitere Funktionen
([64]):
• Music on Hold
• Verschiedene Anrufvarianten - Tag/Nachtschaltung
• Heranholen von Anrufen von anderen Apparaten (Pickup)
• Unterschiedliche Rufsignalisierung (zum Beispiel Unterscheidung zwischen internen / externen Anrufen)
• Freie interne Rufnummernvergabe
Wie leicht zu erkennen ist, wird im öffentlichen Telefonnetz ein Menge an Diensten angeboten. Welche dieser Dienste sind auch in VoIP-Netzen verfügbar? Eine ausführliche
Betrachtung dazu im Abschnitt 4.2
14
2.4 IN - Intelligente Netze
Das Intelligente Netz wurde von der ITU-T als Telekommunikationsnetzwerk konzipiert, welches auf die bestehenden Netze aufsetzt und diese um zusätzliche Netzelemente erweitert. Einer der Hauptgründe für die Entwicklung war die Nachfrage nach
mehr Flexibilität beim Integrieren neuer (komplexer) Dienste.
Die eigentliche Intelligenz liegt nicht wie bisher im Core Switching System sondern
in den einzelnen Netzwerkknoten (nodes) des IN.
Dies vereinfacht das Anbieten neuer Dienste sowie das Erweitern und Modifizieren bestehender Funktionen, da Änderungen vorgenommen werden können ohne das Kernsystem zu beeinflussen. Bevor Intelligente Netze entwickelt wurden, mussten neue Dienste
direkt in das Core Switching System implementiert werden.
Um Fehler im Kernsystem auszuschließen, mussten neue Funktionen über einen langen
Zeitraum hinweg intensiv getestet werden bevor man sie veröffentlichen konnte, was
lange Entwicklungs- und Veröffentlichungszyklen zur Folge hatte.
Betreiber Intelligenter Netze können auf die vorhandenen Netze anderer Netzbetreiber
zurückgreifen um Plattformen für Dienstanbieter zu schaffen. Dabei kann jeder Anbieter verschiedene Dienste zur Verfügung stellen ohne in Konflikt mit anderen Anbieter
zu kommen.
Aktuell werden vor allem Zusatzdienste für ISDN und GSM/UMTS über Intelligente
Netze realisiert wie z.B. ”gebührenfreie Rufnummer”, ”persönliche Rufnummer”, ”Rufnummernportabilität” oder ”Virtuelle Private Netzwerke (VPN)”.
Am Beispiel der gebührenfreien 0800-Rufnummer soll die in Abbildung 2.4 dargestellte Struktur des IN verdeutlicht werden.
Nachdem ein Teilnehmer eine 0800-Nummer wählt, wird der Anruf von einer in die Vermittlungsstelle integrierten Software, dem sogenannten Service Switching Point (SSP),
als IN-Ruf erkannt. Die Anfrage wird an einen Service Control Point (SCP) weitergegeben, der für die Dienstesteuerung im IN verantwortlich ist. Im SCP geschieht die
Umsetzung der 0800-Rufnummer und die Weiterleitung des Anrufs.
Weitere Elemente des IN im Überblick:
• Der SMP dient zur Verwaltung und Überwachung der IN-Dienste. Dabei haben
15
Abbildung 2.4: Aufbau Intelligenter Netze, [67] Seite 111
nicht nur IN-Betreiber bzw. IN-Dienstanbieter die Möglichkeit, Änderungen vorzunehmen, auch Kunden können Einstellungen von abonnierten Diensten ändern.
• Über den Specialized Resource Point (SRP) können spezielle Dienste wie z.B.
Spracherkennung, Text-To-Speech, sowie konventionelle Dienste wie Sprachansagen angeboten werden.
• Der Service Creation Environment Point (SCEP) ist letztlich eine grafische Benutzerumgebung, zur schnellen Realisierung neuer Inhalte.Nach Fertigstellung
werden die Inhalte an den SCP weitergereicht.
• SSP, SCP und SRP sind über ein kanalorientiertes 64kbit/s-Netz verbunden.
Signaling Transfer Points (STP) fungieren hierbei als Paketvermittlungstellen.
16
2.5 NGN - Next Generation Networks
Ein Netz der nächsten Generation (NGN) ist ein paketvermittelndes Telekommunikationsnetz, das Telekommunikationsdienste bereitstellt, viele breitbandige, dienstgüteklassenfähige Transporttechnologien nutzt und bei dem
dienstbezogene Funktionen unabhängig von der genutzten Transporttechnologien sind. Es bietet den Nutzern uneingeschränkten Zugang zu Netzen,
zu konkurrierenden Dienstanbietern und/oder Diensten ihrer Wahl. Es unterstützt die allgemeine Mobilität, die eine beständige und allgegenwärtige
Bereitstellung von Diensten für die Nutzer ermöglicht.
ITU-T-Empfehlung Y.2001 [41] (Übersetzung aus dem Englischen)
Gemeint ist damit ein Netzwerk, welches traditionelle leitungsvermittelnde Telekommunikationsnetze durch ein einheitliches paketvermittelndes Netz ersetzt, wobei die
Kompatibilität zu älteren Telekommunikationsnetzen gewährleistet werden soll.
Einige Faktoren haben in den letzten Jahren immer mehr an Bedeutung gewonnen,
weshalb der Ruf nach Next Generation Networks lauter wurde:
• Freier Wettbewerb zwischen Netzbetreibern aufgrund der Deregulierung der Telekommunikationslandschaft
• Explosionsartige Zunahme des Datenverkehrs, z.B. durch die zunehmende Nutzung des Internets
• Steigende Nachfrage nach neuen Multimedia-Diensten
• Generelle Mobilität
• Konvergenz der Netze und Dienste
In der Empfehlung Y.2001 [41] nennt die ITU-T 14 grundlegende Merkmale, die erfüllt sein müssen, damit ein Telekommunikationsnetz als Next Generation Network
angesehen werden kann:
• Paketübertragung
• Aufteilung der Steuerfunktionen in Übermittlungseigenschaften, Ruf/Verbindung
und Anwendung/Dienst
17
• Abkopplung des Diensteangebots vom Netz und Bereitstellung von offenen Schnittstellen
• Unterstützung eines großen Spektrums von Diensten, Anwendungen und Mechanismen auf der Grundlage von Dienste-Bausteinen (Dienste-Modulen) (einschließlich Echtzeit/Streaming/Nicht-Echtzeit-Dienste und Multimedia)
• Breitband-Fähigkeiten mit durchgehender Dienstgüte und Transparenz
• Zusammenarbeit mit vorhandenen Netzen über offene Schnittstellen
• Generelle Mobilität
• Uneingeschränkter Zugang der Nutzer zu verschiedenen Diensteanbietern
• Vielzahl von Identifikationsschemata
• Einheitliche Dienstemerkmale für den gleichen Dienst aus der Sicht des Nutzers
• Konvergenz von Diensten zwischen fest/mobil
• Unabhängigkeit von dienstbezogenen Funktionen von den zugrunde liegenden
Beförderungstechnologien
• Einhaltung aller regulatorischen Anforderungen, z. B. bei Notrufen sowie Sicherheit/Vertraulichkeit usw.
• Übereinstimmend mit allen regulatorischen Anforderungen (z. B. Notfallkommunikation, Sicherheit, Privatsphäre, Lawful Interception usw.)
Der Übergang von den heutigen Telekommunikationsnetzen hinzu NGN kann nicht
von heute auf morgen geschehen. Das Verschmelzen der Netze und das Ersetzen der
bisherigen Infrastruktur ist auch eine Kostenfrage. Netzbetreiber kommen in Zukunft
im Kernnetz mit nur einem Paketnetz für Daten und Sprache aus. Datendienste spielen
hinsichtlich der erforderlichen Bandbreite eine weitaus größere Rolle, was letztlich zu
einer effektiveren Netzauslastung führt.
”Insgesamt wird diese Vorgehensweise zu weniger Netzelementen, homogenerer Technik, einer Vereinheitlichung des Netzmanagements und damit zu Kosteneinsparungen
in der Beschaffung und vor allem im Betrieb führen.”([73], S.33)
Abbildung 2.5 zeigt den grundlegenden Aufbau eines Next Generation Networks.
Das Kernstück bildet ein paketvermittelndes Netz. Den Übergang vom Paketnetz zu
18
Abbildung 2.5: Prinzipielle Struktur eines Next Generation Networks (NGN)
leitungsvermittelnden Telekommunikationsnetzen und Endgeräten geschieht über Gateways. Für Nutzdaten sind dies Media Gateways (MGW). Diese realisieren die Umwandlung von multimedialen Datenströmen von einem Netzwerktyp zu einem anderen
(z.B. ISDN zu IP). Die Steuerung der verschiedenen Media Gateways geschieht über
einen Media Gateway Controller (MGC), der Teil eines zentralen Call Server (CS) ist.
Application Server stellen eine Ablaufumgebung für spezielle Dienste zur Verfügung,
auf die der Call Server zurückgreifen kann.
Analog zum MGW dienen Signaling Gateways (SGW) der Umsetzung von Signalisierungsdaten an Netzübergängen. SGW sind häufig Teil eines Softswitch In VoIPSystemen.
3 VoIP
19
3 VoIP
Dieses Kapitel beschäftigt sich mit relevanten Aspekten von VoIP (Voice over Internet
Protocol) und bildet eine solide Grundlage für den Vergleich mit herkömmlichen Telefonnetzen. Dabei wird unter anderem auf den Aufbau und wichtigen Elementen von
VoIP-Netzen, die Signalisierung für Auf- und Abbau der Kommunikationssitzungen,
die Erzeugung digitaler Sprachpakete mit Hilfe von Codecs und die Übertragung dieser
Sprachpakete durch entsprechende Protokolle eingegangen.
Allgemeines
VoIP heißt wörtlich übersetzt ”Sprache über Internet Protokoll” und ist das Schlagwort
bei Übertragung von Sprache über IP-basierte Kommunikationsnetze, wie beispielsweise dem Internet.
Lange Zeit waren Datennetze und Telefonnetze parallel existierende Elemente bei der
Kommunikation zwischen verschiedenen Kommunikationspartnern. Infolge der steigenden Übertragungsleistung der Datennetze, wozu die Entwicklung von ADSL in den
90er Jahren beigetragen hat, entstanden die ersten Überlegungen einen Telefondienst
über diese (IP-)Datennetze zu realisieren. Erste Grundlagen dafür bildeten das Übertragungsprotokoll RTP (siehe Kapitel 3.2.1.1) und der ITU-T-Rahmenstandard H.323
(siehe Kapitel 3.2.2.1) im Jahre 1996.
Der Hauptunterschied zur klassischen Festnetztelefonie (Analog oder ISDN), bei welcher für jede Übertragung eine ”Leitung” geschalten und fest für die Dauer der Übertragung reserviert ist, ist die paketvermittelte Übertragung der Datenpakete bei der
Telefonie über IP-Netze.
In Telefongesprächen wird allerdings nicht durchgehend gesprochen, so dass Sprachpausen und ”Überlegzeiten” die Ressource ”Leitung” nicht optimal ausnutzen.
Bei VoIP hingegen, wird keine feste Leitung zwischen den Teilnehmern geschalten, alle
nutzen die gleiche ”Leitung”. Dabei wird die Sprache am Sender in ein digitales Signal gewandelt, ”zerstückelt”, in ein IP-Paket verpackt und über das Netzwerk (LAN,
Internet,..) zum Empfänger transportiert. Dieser wandelt die einzelnen Pakete wieder
in Sprache um. Die Übertragung durch das Netzwerk (Internet) geschieht auf nicht
3 VoIP
20
festgelegten Wegen. Dabei spielen aber Faktoren eine Rolle, welche für die Qualität
der Sprachübertragung eine wichtige Rolle spielen: die verfügbare Bandbreite, die Verzögerung (Ende-zu-Ende), Schwankungen der Netzauslastung, Verlustrate der Pakete
und Jitter.
Da sich im lokalen Firmennetzwerk weniger Personen die verfügbaren Ressourcen teilen, ist die (Sprach-)Qualität beim Einsatz von VoIP dort meist höher als im Internet,
wo relativ hohe Übertragungszeiten (dementsprechend höheres Delay) auftreten können.
Bei der klassischen ISDN-Telefonie hingegen, spielen diese Faktoren eine eher untergeordnete Rolle, da dort eine ”Leitung” für die Dauer der Übertragung mit garantierten
Parametern reserviert ist!
Vorteile von VoIP
Der Einsatz von VoIP bringt verschiedenste Vorteile, Potentiale (vor allem im Kostenbereich) und Chancen mit sich.
Dazu gehören folgende, ausgewählte Aspekte ([53]):
• Kosteneinsparungen
Mit dem Einsatz IP-basierter Telefonie lassen sich Kosteneinsparungen erzielen:
– Investitionsschutz
Vorhandene Endgeräte lassen sich weiterhin mit Hilfe so genannter TerminalAdapter weiterverwenden. Zukunftssicherheit der eingesetzten Hardware
sollte durch Updatemöglichkeiten und einfaches Hinzufügen neuer Funktionen durch Softwareupdates gewährleistet sein.
– Anschaffungskosten
Anschaffungskosten für VoIP-Endgeräte unterscheiden sich kaum von herkömmlichen Telefonen. Allerdings sind durch den Einsatz von SoftwareClients die Anschaffungskosten für neue Endgeräte erheblich senken.
Bei Neuinstallationen liegt Einsparpotential bei der entfallenden Verkabelung. Bei Zusammenlegen mehrerer dedizierter TK-Anlagen zu einem zentralen VoIP-System lassen sich weitere Kosteneinsparungen erzielen.
– Betriebskosten
Ein häufiges Argument für die Einführung von VoIP in Unternehmen, ist die
Senkung der Betriebskosten. In das Datennetz wird zusätzlich die Telefonie
integriert; ein seperates Telefonnetz wird somit überflüssig. Zusätzlich dazu
lassen sich in das Netz verschiedenste Dienste (Voicemail, Alarmmeldefunk-
3 VoIP
21
tionen, Telemetriedatenübertragung) integrieren, welche weitere Kosteneinsparungen ermöglichen.
• Leichtere Verwaltung
Eine IP-basierte Telefonanlage (IP-PBX) lässt sich meist bequem durch eine
grafische Oberfläche verwalten. Die Konfiguration proprietärer Telefonanlagen ist
meist kompliziert und erfordert entsprechendes Knowhow (herstellerspezifische
Programmierung).
• Keine seperate Verkabelung
Durch die Verwendung von existierenden IP-Netzen ist keine seperate Verkabelung notwendig. Die verwendeten Endgerätes sind direkt in das Netz eingebunden.
• Herstellerunabhängigkeit
Da die VoIP-Kommunikation mittels standardisierter Verfahren (SIP) realisiert
sind, können Endgeräte verschiedenster Hersteller verwendet werden.
• Skalierbarkeit
Die Anzahl nötiger Clients kann in IP-Netzen beliebig an die Bedürfnisse angepasst werden, falls das Netz noch entsprechende Kapazitäten zur Verfügung
stellen kann. Bei herkömmlichen Telefonanlagen kann das Hinzufügen neuer Nebenstellen durchaus Probleme, wie zum Beispiel die Neuanschaffung einer Telefonanlage, bereiten.
• Schnelles Einrichten neuer Nebenstellen und Heimarbeitsplätzen
Da der Standort der Gesprächsteilnehmer in IP-Netzen nicht durch Raumnummern o.ä. sondern durch IP-Adressen definiert ist, ist dieser relativ flexibel. Somit
lassen sich Wechsel von Arbeitsplätzen einfach und für den Anrufer unbemerkt
realisieren.
Nachteile von VoIP
Allerdings sind mit dem Einsatz von VoIP einige Aspekte verbunden, die sich nachteilig auswirken und deswegen unbedingt Beachtung finden müssen!
Kritikpunkte an VoIP sind beispielsweise die schlechte Sprachqualität bei Telefongesprächen, eng verbunden mit ”QoS” (Quality of Service, Dienstgüte), die noch nicht
ganz ausgereifte Technik, Probleme beim Absetzen von Notrufen , aber auch Aspekte
wie Sicherheit und verfügbare Dienste!
Diese Aspekte sind in Kapitel 4 Gegenstand der Betrachtung!
3 VoIP
22
3.1 Bestandteile von VoIP-Netzen
VoIP bedeutet übersetzt ”Sprachübertragung über Internet Protokoll” und ist meist
dadurch gekennzeichnet, dass VoIP-Netze durch die Integration in bereits existierende
Netze (IP-basiert, beispielsweise LANs) realisiert werden.
Dieser Abschnitt beschäftigt sich mit dem grundsätzlichen Aufbau eines solchen VoIP
Netzes auf Basis von SIP (3.2.2.2) und beschreibt alle vorkommenden Elemente und
Komponenten!
Abbildung 3.1: Komponenten eines VoIP-Netzes auf Basis von SIP
VoIP-PBX
PBX bedeutet ”Private Branch Exchange”, auf deutsch ”Private Telekommunikations/Nebenstellenanlage” und ist das Herz eines VoIP-Netzes. Zu den Aufgaben einer VoIPPBX gehören Signalisierungsfunktion, Weiterleitung und Umsetzung der Sprachdaten
sowie die Nutzerverwaltung.
Ein Beispiel für eine software-basierte VoIP-PBX ist ”Asterisk” (www.asterisk.org).
Auf Basis dieser Software wird in Kapitel 6 ein VoIP-Netz aufgebaut.
3 VoIP
23
VoIP-Proxy
Proxy-Server haben eine wichtige Rolle in SIP-Netzen inne: sie übernehmen das Routing der SIP-Nachrichten zwischen den Endgeräten und sind zudem für das Rechtemanagement zuständig, d.h. sie prüfen, ob Benutzer die Berechtigung besitzen Anrufe
durchzuführen ([53], S.73)([87]). Dabei wird zwischen Stateless und Stateful Proxies
unterschieden:
• Stateless Proxies
Stateless Proxies leiten empfangene Nachrichten einfach weiter. Sie sind deshalb
schneller als Stateful Proxies.
• Stateful Proxies
Stateful Proxies generieren für eine Anfrage einen Zustand und speichern diesen, bis die entsprechende Transaktion beendet ist. Aufgrund der Tatsache, dass
Stateful Proxies diese Zustände für die Dauer der Anfrage aufrecht erhalten müssen, sind an diese höhere Leistungsanforderungen gestellt. Dafür sind sie aber
auch in der Lage, weitergehende Dienste anzubieten und können auch von einem
Endgerät mehrfach versandte Nachrichten abfangen, da sie ja wissen, ob diese
bereits empfangen wurde.
Gateways
Um Verbindungen in andere Netze (ISDN, Internet,..) herstellen zu können sind Gateways nötig. Sie realisieren den Übergang von einem Netz in ein anderes, wobei es zum
”Anpassungen” von Signalisierungsinformationen und der eigentlichen Sprachübertragung kommt, da in den Netzen unterschiedliche Protokolle vorherrschen.
Eine, in einen PC eingebaute, ISDN-Karte ist ein Beispiel für ein Gateway zwischen
dem VoIP-Netz (LAN) und dem öffentlichen Telefonnetz (PSTN).
Endgeräte
Endgeräte sind die ”Schnittstellen” zwischen dem Netz und den Benutzern. Sie ermöglichen die Nutzung von VoIP und lassen sich in 3 Gruppen einteilen:
• VoIP-Telefone
Sind Endgeräte für den direkten Anschluss an das IP-Netzwerk und verfügen deshalb über eine LAN-/WLAN-Schnittstelle. Sie benötigen keinen PC-Anschluss
und werden auch als Hardphones bezeichnet, da es real existierende Endgeräte
sind (vgl. Softphones).
3 VoIP
24
• Softphones
Softphones sind, im Gegensatz zu echten VoIP-Telefonen/Hardphones, Computerprogramme welche die Telefonie ermöglichen. Um Softphones zu nutzen müssen einige Bedingungen erfüllt sein: So wird unbedingt ein PC mit Soundkarte,
Mikrophon und einen entsprechenden Netzwerkzugang benötigt.
Beispiele für Softphones:
– X-Lite (http://www.counterpath.com/)
– Wengophone (http://www.openwengo.org/)
• ISDN/Analog-Telefon, angeschlossen via Terminaladapter
Normale, vorhandene Telefone (Analog- oder ISDN-Telefone) lassen sich problemlos in VoIP-Netze integrieren. Dies geschieht mit Hilfe eines Terminaladapters, welcher quasi als Gateway zwischen den herkömmlichen Endgeräten und
dem VoIP-Netz fungiert!
3 VoIP
25
3.2 Protokolle
[2] Die Kommunikation zwischen Rechnern in Netzen wie dem Internet, verläuft nach
bestimmten Regeln, welche vor allem die Datenformate und deren zeitliche Reihenfolge
festlegen. Diese Regeln werden als Kommunikationsprotokolle, kurz Protokoll bezeichnet. All diese Regeln sind in der Protokollfamilie TCP/IP, welche die Kommunikation
im Internet regelt, abgebildet.
Folgende Abbildung zeigt die Struktur der Protokollfamilie TCP/IP mitsamt der Zuordnung zu den Schichten des OSI-Referenzmodells (Open Systems Interconnection
Reference Model):
Abbildung 3.2: TCP/IP-Protokollfamilie ([2])
Die Grundlage der Protokollfamilie bildet dabei IP (Internet Protocol). IP regelt wie
die Daten mittels eigenständiger, von einander unabhängiger Datenpakete übermittelt
werden. Dabei stehen IP mit ARP und ICMP zwei Hilfsprotokolle zur Verfügung:
• ARP (Address Resolution Protocol)
unterstützt die Adressierung und sorgt für die Zuordnung von Netzwerk zu Hardwareadressen (IP - MAC)
• ICMP (Internet Control Message Protocol)
dient in Netzwerken zum Austausch von Informations-, Steuerungs- und Fehlermeldungen über das IP-Protokoll
3 VoIP
26
In der Transportschicht (Schicht 4 des OSI-Referenzmodells) sind die Transportprotokolle TCP und UDP angesiedelt. Zu den Aufgaben der Transportschicht zählt unter
anderem die Herstellung einer Ende-zu-Ende-Verbindung zum Versenden von Datenströmen:
• TCP (Transport Control Protocol) ist ein transportsicherndes Protokoll, bei dem
der Empfang der Datenpakete sichergestellt wird. Somit ist TCP ein verbindungsorientiertes Transportprotokoll.
• UDP (User Datagram Protocol) im Gegensatz zu TCP ist UDP ein verbindungsloses Transportprotokoll und gibt keine Garantien für die korrekte Übertragung
der Daten.
Im Oktober 2000 wurde von der IETF ein neues Transportprotokoll vorgeschlagen:
SCTP. SCTP steht für Stream Control Transmission Protocol und ist wie TCP ein
transportsicherndes Protokoll, welches den Empfang von Datenpaketen sicherstellt.
SCTP umgeht einige nachteilige Eigenschaften von TCP, weshalb es in Zukunft TCP
in bestimmten Bereichen verdrängen kann.
Auf TCP oder UDP aufbauende Anwendungsprotokolle lassen sich in drei Gruppen
einteilen:
• Verbindungslose, nutzen UDP als Transportprotokoll
• Verbindungsorientiert, TCP als Transportprotokoll
• Gemischte, nutzen je nach Bedarf TCP oder UDP
Zu den verbindungslosen Anwendungsprotokollen gehören unter anderem:
• DHCP (Dynamic Host Configuration Protocol ) für die dynamische Zuweisung
von IP-Adressen in einem Netzwerk
• SNMP (Simple Network Management Protocol ) für Netzwerkmanagementaufgaben
• RTP (Real-time Transport Protocol ) für den Echtzeittransport von Multimediadaten
• RTCP (RTP Control Protocol ) überwacht den Datentransport via RTP
• MGCP (Media Gateway Control Protocol ) für die Ansteuerung von VoIP-Gateways
3 VoIP
27
• Megaco (Media Gateway Control ), siehe MGCP
• SIP (Session Initiation Protocol ) Signalisierungsprotokoll für
Multimedia-Kommunikation
Verbindungsorientierte Anwendungsprotokolle sind u.a:
• HTTP (Hypertext Transfer Protocol ) für Web-Anwendungen
• FTP (File Transfer Protocol ) für den Transfer von Dateien
• SMTP (Simple Mail Transfer Protocol ) für den Versand von E-Mails
• H.323-Signalisierung für VoIP-Verbindungen basierend auf H.323
Ein gemischtes Anwendungsprotokoll stellt DNS (Dynamic Name System) dar und ist
eines der wichtigsten Anwendungsprotokolle im Internet. Es sorgt für die Umsetzung
von Internetadressen in die zugehörigen IP-Adressen. DNS-Anfragen werden normalerweise per UDP Port 53 zum Nameserver gesendet. Der DNS-Standard erlaubt aber
auch TCP.
Der Begriff VoIP wird meist nur mit den Signalisierungsprotokollen SIP und H.323 verknüpft. Bei der Realisierung von Sprachkommunikation über IP-Netze sind allerdings
bedeutend mehr Protokolle involviert ([2]):
• Protokolle für die Übermittlung der (Sprach-)Pakete (RTP, RTCP)
• Signalisierungsprotokolle (SIP, H.323)
• Protokolle für die Steuerung v. Media Gateways (MGCP und Megaco)
Weitergehende Informationen zu diesen Protokollen folgen in den nächsten Kapiteln.
3 VoIP
28
3.2.1 Übermittlungsprotokolle
3.2.1.1 RTP
Wie in 3.2 erwähnt, wird für die Übertragung der einzelnen Multimediapakete durch
IP-Netze ein entsprechendes Protokoll benötigt. Dieses Übertragungsprotokoll ist RTP
und ermöglicht eine Ende-zu-Ende-Übertragung von Sprach- und Videostreams im Internet. Auf RTP-basierende Anwendungungen nutzen typischerweise RTP über UDP,
beide Protokolle leisten zusammen wichtige Beiträge, um den Transport der Datenpakete in IP-Netzen zu gewährleisten.
Das Protokoll wurde erstmals im Januar 1996 im RFC 1889[20] standardisiert. 2003
wurde ein überarbeiteter RFC 3550[29] veröffentlicht, welcher den RFC 1889 ablöste
Die wichtigsten Funktionen von RTP sind:
• Übermittlung von Echtzeitdaten
Echtzeitdatenströme (Audio, Video) werden via RTP in eine zusammenhängende
Folge von RTP-Paketen über eine RTP-Session übermittelt. Die RTP-Session
kann dabei als ein logischer Übertragungskanal angesehen werden
• Garantieren der Paketreihenfolge am Empfänger
Durch Nummerieren der Pakete kann die richtige Reihenfolge am Ziel wiederhergestellt werden, falls diese durch den Transport über das IP-Netz verändert
wurde. Dazu erhält jedes RTP-Paket eine ”Sequence Number” (Sequenznummer)
und einen ”Timestamp” (Zeitstempel).
• Transport unterschiedlicher Formate
Via RTP werden verschiedene Anwendungsdaten übertragen. Dies sind zum Beispiel VoIP, Videokonferenzen und verschiedenste multimediale Kommunikation.
Dabei werden in sogenannten ”Profiles” die unterschiedlichen Formate von Audio, Video und Sprache definiert. Diese Profiles wurde erstmal im Januar 1996
in der RFC 1890[31] definiert und im Juli 2003 durch die RFC 3551[21] ersetzt.
• Translator und Mixer-Einsatz
Ein Translator ist ein Element, welches RTP-Pakete in einem Format empfängt,
sie in ein anderes übersetzt und weiterschickt. Die Umwandlung zweier Audioformate während eines Telefongespräches wird beispielsweise durch einen Translator
realisiert.
Ein Mixer übernimmt, wie der Name schon sagt, eine Kombination mehrerer
3 VoIP
29
Datenströme zu einem neuen Datenstrom. Ein Beispiel dafür ist die Zusammenlegung mehrerer VoIP-Datenströme, um die Übermittlung über einen logischen
Kanal zu ermöglichen (vgl. Multiplexing).
Ein Datenstrom von Echtzeitdaten wird als eine Folge von RTP-Paketen übermittelt,
die mit dem vorangestellten UDP-Header in den IP-Paketen übertragen werden (Encapsulation). Dabei enthält jedes RTP-Paket einen Header- und einen Payload-Teil.
Den Aufbau eines RTP-Paketes verdeutlicht folgende Abbildung:[67][2]
Abbildung 3.3: Transport von RTP-Paketen mit UDP und IP
Folgende Angaben sind im Header eines RTP-Paketes zu finden:
• V - Version, 2Bits
Hier wird die verwendete RTP-Version angegeben. Aktuell ist zur Zeit Version
2[20].
3 VoIP
30
• P - Padding, 1Bit
Falls P=1, dann enthält ein RTP-Paket am Ende zusätzliche Füllungen (Padding), die nicht zur Nutzlast gehört.
• X - eXtension, 1Bit
Falls X=1, dann ist eine Header Extension vorhanden
• CC - CSRS Count, 4Bit
Anzahl von im Feld CSCR enthaltenen Quell-Identifikatoren.
• M - Marker, 1Bit
Die Marker-Bedeutung wird durch die transportierte Nutzlast (Profile) bestimmt.
• PT - Payload Type, 8Bits
Hier wird angegeben, um welches Format es sich bei der Nutzlast handelt.
PT=4 bedeutet beispielsweise, dass die Daten mittels G.723 kodiert wurden.
• Sequence Number - Sequenznummer, 16Bits
Jedes RTP-Paket wird mit einer Sequenznummer versehen, damit der Empfänger
die richtige Reihenfolge der Pakete aber auch den Verlust bestimmter Pakete
ermitteln kann. Der Anfangswert wird zufällig ausgewählt, um eine unbefugte
Entschlüsselung zu erschweren.
• Timestamp - Zeitstempel, 32Bits
Der Zeitstempel dient dazu, den Zeitpunkt der von Payload zu markieren und ist
nötig um Schwankungen bei der Übertragungszeit von RTP-Paketen am Empfänger auszugleichen.
• SSRC - Synchronization Source Identifier
Dient zur eindeutigen Identifikation der Quellen von Datenströmen.
• CSRC - Contributing Source Identifiers
Optionale Angabe, wird verwendet, wenn der Payload nicht direkt vom OriginalSender, sondern von einem Zwischensystem (Mixer) kommt.
Ein IP-Paket mit Audio- oder Videodaten enthält einen RTP-, UDP- und den IPHeader, weshalb der Gesamtheader mindestens 40 Bytes groß ist.
3 VoIP
31
3.2.1.2 SRTP
SRTP steht für Secure Real-Time Transport Protocol und bietet eine Verschlüsselung
und Authentifizierung von RTP über IP-Netze und ermöglicht so eine Absicherung der
VoIP-Kommunikation. Hierbei werden die Daten mit einer symmetrischen Verschlüsselung nach AES (Advanced Encryption Standard) verschlüsselt. Spezifiziert wurde
SRTP in der RFC 3711 im März 2004 ([30]).
SRTP stellt folgende Sicherheitsfunktionen zur Verfügung um eine vertrauliche Übertragung zu realisieren ([33]):
1. Die Verschlüsselung der Sprachübertragung schützt vor unbefugtem Abhören
2. Die Authentifizierung des Absenders unterbindet Identitäts-Spoofing
3. Mit der Überprüfung der Integrität werden unberechtigte Änderungen ausgeschlossen
4. Mit dem Anti-Replay-Schutz wird ein unbefugter Zugriff auf Ziel-End-Einrichtungen
verhindert
3.2.1.3 RTCP
Ein Nachteil von RTP ist die fehlende Übermittlung von Quittungen und Bestätigungen für die erfolgreiche Übertragung von Paketen. Um dieses Manko auszugleichen,
wurde RTP mit RTCP ein Protokoll zur Seite gestellt.
RTCP steht für Real-Time Control Protocol und steuert die eigentliche Nutzdatenübertragung (nicht zu verwechseln mit der Steuerung der Verbindungen - der Signalisierung). RTCP wird benutzt, um ständig Kontrollpakete (Steuerinformationen) zwischen allen Teilnehmern einer RTP-Session auszutauschen. Diese Kontrollpakete beinhalten verschiedene Statistiken, Informationen über die Teilnehmer (Namen, E-MailAdressen,..) aber auch spezielle Kontrollinformation, welche bei bestehenden Telefonkonferenzen das Verlassen oder kurzzeitiges Pausieren eines Teilnehmers signalisieren
([67]).
Beispiele für solche Steuerinformationen sind:
• Rückkopplung über die Qualität der Verbindung (QoS-Feedback)
• Identifikation des Senders
• Anpassung der Senderrate von RTCP-Paketen in Abhängigkeit von Teilnehmerzahl und Netzwerkauslastung
3 VoIP
32
• Übermittlung von Zusatzinformationen (optional), beispielsweise die Name der
Teilnehmer einer Telefonkonferenz
Der Sender kann diese Informationen auswerten und dadurch die Parameter der Übertragung optimieren oder alternative Übertragungsmethoden auswählen. Beispielsweise
wird durch RTCP die Lippensynchronität gewährleisten, wenn Audio- und Videodaten
getrennt übertragen werden.
Um diese Funktionalität zu gewährleisten tauschen alle RTCP-Instanzen Nachrichten
untereinander aus.
Beispiele für solche Nachrichten sind:
• Receiver Report (RR)
Durch diese Nachrichten werden Qualitätsinformationen für die Rückkopplung
zum Sender übertragen. In diesen Nachrichten sind Informationen über die Anzahl verlorener Pakete, den Jitter sowie eine Zeitstempelung zur Berechnung des
Round Trip Delays enthalten
• Sender Report (SR)
Mit den Sender Reports werden Informationen des Senders und über die Anzahl
der gesendeten Pakete übertragen.
• Source Description (SDES)
Damit wird die Informationsquelle beschrieben. Enthalten sind Parameter wie
Alias-Name (Namen, Telefonnummern,..), Adressinformationen oder Informationen über weitere Anwendungen.
• BYE
Ein Ende der Session-Teilnahme wird hiermit signalisiert.
Bei einer Übertragung von Echtzeitdaten übernimmt RTP den Datentransport, während RTCP für die Steuerung der Übertragung zuständig ist.
3.2.1.4 RTSP
Das Real-Time Streaming Protocol (RTSP) ist ein Protokoll für die Steuerung von
Multimediadatenströmen.
RTSP stellt Verbindungen zu einem oder mehreren zeitsynchronisierten audiovisuellen Datenströmen (angeboten von Multimedia-Servern) her und steuert diese. RTSP
überträgt dabei die kontinuierlichen Datenströme nicht selber, eine Verknüpfung mit
3 VoIP
33
dem Datenstrom ist aber möglich. Beispielweise werden die Daten via RTP übertragen, während in diesem Datenstrom ein RTSP-Kontroll-Stream eingebunden ist. Mit
anderen Worten stellt RTSP eine Fernbedienung für Multimediadatenströme bereit.
RTSP ist ein text-basiertes Protokoll, kann über UDP oder TCP übertragen werden
und ähnelt im Aufbau und Verhalten HTTP und wurde im April 1998 in der RFC
2326 von der IETF standardisiert ([28]).
3.2.2 Signalisierungsprotokolle
3.2.2.1 H.323
Der H.323-Standard ist ein von der ITU-T entwickelter Standard und beschreibt die
Übertragung von Echtzeitdatenströmen (Video, Audio, Daten) in paketorientierten
Transportnetzen, welche selbst keine Mechanismen zur Dienstgüte bereitstellen ([42]).
Diese paketorientierten Netzwerke, über welche H.323 kommuniziert, können Punktzu-Punkt-Verbindungen, einzelne Netzwerksegmente oder auch große Netzwerke mit
unterschiedlichen Toplogien sein.
Desweiterem stellt H.323 ein Rahmenwerk (Framework) dar, welches regelt, wie weitere
Standards (H.225 und H.245) und Protokolle (TCP/IP-Protokollfamilie) die Übermittlung der Echtzeitdatenströme realisieren.
”Eine H.323-Verbindung unterteilt sich in Verbindungsaufbau, Verbindungsabbau und
die Datenphase (Versenden der Datenpakete mit Video-, Audio- oder Faxdaten). Audiound Videodaten werden per UDP, Faxdaten per UDP oder TCP übertragen. Vor der
Übertragung von Echtzeitdaten werden so genannte logische RTP- und RTCP-Kanäle
zwischen den Endpunkten (Terminals) aufgebaut.” ([33], S.14)
Das Protokoll wird seit 1996 kontinuierlich weiter entwickelt, die aktuellste Version 6
(H.323v6) wurde 2006 veröffentlicht.
”‘H.323 gilt allgemein als zuweilen kompliziertes und sehr komplexes Protokoll. Dem
unmittelbaren Konkurrent SIP wird hingegen ein wesentlich vereinfachter Aufbau
zugesprochen”’([51]).
Systemarchitektur
In der Empfehlung der ITU-T sind folgende grundlegende Elemente von H.323 in einem paketbasiertem Netzwerk definiert: Terminals, Gateway, Gatekeeper und MCUs,
welche im folgenden beschrieben werden.
3 VoIP
34
Abbildung 3.4: Elemente von H.323 (Abb. von [42])
• Terminals
Ein H.323-Terminal verkörpert ein Endgerät in einem H.323-Netzwerk. Diese
Endgeräte können IP-Telefone und Softphones sein, mit denen Anrufe getätigt
und angenommen werden können.
Optional ist die Übertragung von Video definiert.
Zusätzlich wird neben Punkt-zu-Punkt-Verbindungen auch die Übertragung zwischen drei und mehr Teilnehmern in einer Multipunkt-Konferenz unterstützt.
• Gateways
Ein H.323 Gateway ist ein Endpunkt im Netzwerk, welcher Echtzeit- und ZweiWege-Kommunikation zwischen Teilnehmern in verschiedenen Netzen ermöglicht.
Ein Gateway stellt somit eine Schnittstelle zu anderen Netzwerken dar, was andere VoIP-Netzwerke (SIP- oder H.323) oder verbindungsorientierte ISDN-Netze
sein können.
• Gatekeeper
Gatekeeper sind wichtige Elemente in H.323-Netzen. Sie übernehmen die Kontrolle einer Gruppe von Terminals und Gateways (Bildung von so genannten
H.323-Zonen), sind aber auch für die Unterstützung von QoS (Bandbreitenzuordnung) zuständig.
Eine weitere wichtige Aufgabe ist die Adressverwaltung (Zuordnung von Telefonnummern zu IP-Adressen). Jedes Terminal muss also beim Gatekeeper seiner
Zone registriert sein! Allerdings sind Gatekeeper laut Definition (in kleineren
Netzen) optional, weswegen in kleinen Netzen ohne Gatekeeper jedes Terminal
die Adressverwaltung selbst übernehmen muss.
3 VoIP
35
Abbildung 3.5: Definition eines H.323-Terminals
• MCUs (Multipoint Control Unit)
H.323 unterstützt auch Multipoint-Konferenzen. Für den Auf- und Abbau von
Punkt-zu-Mehrpunktverbindungen sowie der Datenübermittlung bei der Realisierung solcher Konferenzen dienen MCUs. Eine MCU enthält einen Multipoint
Controller (MC) für die Signalisierung und einen oder mehrere Multipoint Processors (MP) zu Behandlung (Mixen und Umschalten) von übermittelten Echtzeitdatenströmen. Typischerweise besteht eine MCU aus einem MC und einem
Audio-, Video- und Daten-MP.
Dabei sind 2 Betriebsarten möglich: Bei der dezentralen Konferenz-Betriebsart
senden die Terminals der Daten selbstständig an andere beteiligte Terminals; bei
der zentralisierten Variante übernimmt der Multipoint Processor die Verteilung
der Datenströme.
Die H.323-Prokollsuite
Wie bereits beschrieben, definiert H.323 ein ganzes Rahmenwerk an (ITU-T)-Protokollen, welche jeweils für spezifische Teilaufgaben zuständig sind ([42], S.14ff):
3 VoIP
36
Abbildung 3.6: Die H.323-Protokollsuite ([33], S.14)
• Multimediaströme - Audiocodecs
– G.711 (siehe 9.1.1)
– G.722 (siehe 9.1.2)
– G.723.1 (siehe 9.1.3)
– G.728 (siehe 9.1.5)
– G.729 (siehe 9.1.6)
• Multimediaströme - Videocodecs
– H.261
– H.263
• H.225 - (Call Control)
ist zuständig für die Rufsignalisierung, Endgerätesynchronisierung und die Paketübertragung in paketorientierten Kommunikationsnetzen und entspricht in
großen Teilen dem ISDN-D-Kanal-Protokoll.
• H.235
ist für die Sicherheit in H.323-Multimediasystemen zuständig
• H.245 - Medienkontrolle und Medientransport (Bearer Control)
(Kanal-)Kontrollprotokoll für die Multimediakommunikation
3 VoIP
37
• H.450 (Supplementary Services)
H.450 realisiert die Implementierung von (ISDN-)Dienstmerkmalen. Zum Beispiel:
– H.450.1 - Call Signalling
– H.450.2 - Call Transfer
– H.450.3 - Call Forwarding
– ...
3 VoIP
38
3.2.2.2 SIP - Session Initiation Protocol
Das Session Initiation Protocol (SIP) ermöglicht das Erstellen, Modifizieren und Beenden von Verbindungen zwischen einem oder mehreren Teilnehmern.
SIP wurde erstmals im Mai 1999 von der Internet Engineering Task Force (IETF)
unter der Bezeichnung RFC 2543 standardisiert. Die heute aktuellen Standards (RFC
3261-3265) beinhalten vor allem Erweiterungen bzw. Verbesserungen des ursprünglichen RFC 2543.
SIP dient in erster Linie als Signalisierungsprotokoll in der Anwendungsschicht zur
Etablierung von Kommunikationsverbindungen für Multimediakonferenzen, Internettelephonie oder generell Multimediaübertragungen. Da SIP selbst lediglich zur Vermittlung, Steuerung und Verwaltung der Verbindungsmodalitäten verwendet werden
kann, kommen für die eigentliche Kommunikation der Daten weitere unterstützende
Protokolle zum Einsatz (z.B. SDP, RTP).
Transport
Als Transportprotokoll kommt üblicherweise UDP zum Einsatz. SIP kann auch über
TCP bzw SCTP transportiert werden, was aber gerade bei der VoIP-Übertragung
zu Einbussen bei Zeit und Datenvekehrsaufkommen führt. UDP bietet zwar nicht die
Massnahmen zur Kommunikationssicherung wie TCP oder SCTP, da SIP selbst aber
verbindungsorientiert arbeitet, erübrigt sich die Verwendung eines verbindungsorientierten Protokolls.
SIP Netzelemente
• User Agent
Als ”User Agent” (UA) bezeichnet man diejenige Software- und/oder Hardwarekomponente, die das Endgerät für eine SIP-basierte Kommunikation darstellt.
Z.B. handelt es sich dabei um ein Software-Telefon (Soft Phone), das - auf einem Computer installiert - eine Schnittstelle zwischen dem Benutzer (User) und
der IP-Kommunikationswelt bildet. Hierdurch wird dem Benutzer eine grafische
Oberfläche zur einfachen Bedienung zur Verfügung gestellt. Die dahinterstehende Software wandelt die vom Menschen getätigten Aktionen in SIP-konforme
Nachrichten um [11].
• Registrar Server
”Ein Registrar Server bildet die Grundlage für die komfortable, orts- und endgeräteunhabhängige Erreichbarkeit eines Teilnehmers anhand einer ständigen
3 VoIP
39
SIP URI” [73]. Der sich anmeldende Teilnehmer sendet eine ”REGISTER” SIPAnfrage an den Registrar Server. Dabei beinhaltet der SIP-Header sowohl die
temporäre (”To”-Feld) als auch die ständige SIP URI (”Contact”-Feld). Der Registrar Server liest die übermittelten Informationen und leitet sie an einen Location
Server weiter, welcher den Zusammenhang speichert.
• Location Server
Ein Location Server dient in einer SIP-Infrastruktur als Datenbank um die vom
Registrar Server gesammelten Informationen zu speichern und diese bei Anfrage
von Vermittlungselementen (z.B. SIP-Proxy) herauszugeben. Die Kommunikation mit einem Location Server findet mittels Serverprotokollen (z.B. Lightweight
Directory Access Protocol (LDAP), Diameter) statt.
• Proxy Server
Ein Proxy Server wird für das Routing von SIP-Nachrichten verwendet. Die Vermittlung geschieht anhand der temporären/ständigen SIP URI, die der Proxy
vom Location Server erfragt. SIP Proxies werden grundsätzlich in zwei Typen
unterteilt: ”Stateless Proxy” und ”Stateful Proxy”.
Ersterer leitet SIP-Nachrichten an genau ein SIP-Netzelement weiter und arbeitet als einfaches Durchgangselement. Dabei ist er nicht in der Lage selbstständig
SIP-Nachrichten zu erzeugen oder wiederholt zu senden [60].
Ein Stateful Proxy speichert hingegen den Transaktionsstatus jeder SIP-Anfrage
um sich bei Bedarf erneut darauf beziehen zu können. Weiterhin kann er als
UAC sowie UAS arbeiten, indem er SIP-Anfragen bzw. Statusinformationen erzeugt und weiterleitet. Dies ermöglicht ihm auch das senden von Nachrichten an
mehrere SIP URI gleichzeitig (”Forking Proxy”). Auch kann ein Stateful Proxy
Nachrichten erneut senden, falls er mit dem Verlust der Original-Nachricht rechnen muss, wobei er dabeu auf die von SIP bereitgestellten Timer zurückgreift.
Peer-to-Peer SIP
SIP ermöglicht prinzipiell den Einsatz in Peer-to-Peer (P2P) Netzwerken. An dieser Stelle sei jedoch auf weiterführende Literatur verwiesen, da die Relevanz für diese
Arbeit nicht gegeben ist. Seit Februar 2007 arbeitet die P2PSIP-Working Group des
IETF [23] an der Thematik. Für die Kombination aus SIP-basierter Kommunikation
und Peer-to-Peer Netzwerken können zwei prinzipielle Ansätze unterschieden werden:
SIP-using-P2P [66] und P2P-over-SIP ([68];[8]).
Client und Server
3 VoIP
40
Die Begriffe Client und Server sind bei einer SIP-Verbindung kontextabhängig. Das
SIP-Endgerät (User Agent), das eine SIP-Anfrage aussendet wird als Client (User
Agent Client (UAC)) bezeichnet. Die antwortende Gegenstelle wird Server genannt
(User Agent Server (UAS)). Diese Bezeichnungen hängen vom jeweiligen Kontext ab
und sind nicht fest an ein Gerät gebunden. So ist ein SIP Proxy Server, der eine SIPAnfrage sendet in dem Fall der Client, unabhängig davon welche Rolle er normalerweise
einnimmt.
Abbildung 3.7 soll die wechselnden Bezeichnung anhand einer typischen SIP-Verbindung
verdeutlichen.
Abbildung 3.7: SIP-Verbindungsauf und -abbau im Detail
Adressierung
Die Adressierung von User Agents erfolgt über den SIP Uniform Resource Identifier (SIP URI). Dessen Funktion ist vergleichbar mit der einer Telefonnummer, der
syntaktische Aufbau gleicht dem einer Email-Adresse.
Abbildung 3.8: Beispiel für eine SIP URI
Die Generierung der SIP URI erfolgt durch den User Agent, sobald dieser an ein
3 VoIP
41
Netzwerk angeschlossen wird. Dabei ist ”User” in der Regel eine frei wählbare Zeichenkette, ”Host” entspricht jedoch der aktuellen IP-Adresse des User Agents. Diese
Adresse wird als temporäre SIP URI bezeichnet, da sich die IP-Adresse auf das aktuelle
Netzwerk bezieht und sich bei einem Netzwechsel ändert.
Um einem Nutzer eine beständige, eindeutige Adresse zu ermöglichen, benötigt man
eine Reihe von Netzelementen. Ein Nutzer erhält dabei eine sogenannte ständige SIP
URI zugewiesen, welche unabhängig vom derzeitigen Standort ist (ähnlich einer EmailAdresse, z.B. sip:[email protected]).
Mithilfe des SIP User Agents stellt der Nutzer nun zu Beginn eine Verbindung mit
einem Registrar Server her. Dieser ermittelt den Zusammenhang zwischen aktuellem
Standort (temporäre SIP URI) und der hinterlegten ständigen SIP URI und gibt diese
Information an den Location Server weiter. Kommt nun eine Anfrage von einem SIP
Proxy oder direkt von einem anderen User Agent, so wird zunächst der Location Server
angesprochen. Dieser hat den Zusammenhang zwischen dem gewünschten Empfänger
und dessen derzeitigem Standort gespeichert und gibt diese Information zurück. Auf
diese Weise können sich Gesprächsteilnehmer an sich ändernden Standorten aufhalten,
ohne dass die Gegenseite davon etwas mitbekommt bzw. ohne eine andere SIP URI
wählen zu müssen.
Session Description Protocol (SDP)
Bevor im nächsten Absatz eine SIP-Verbindung im Detail betrachtet wird, soll an
dieser Stelle auf ein weiteres wichtiges Protokoll eingegangen werden, das eng mit SIP
verbunden ist.
Das Session Description Protocol (SDP) dient zur Beschreibung zuübertragender Mediendaten. Während SIP sich um die Signalisierung und das Zustandegekommen der
Verbindung kümmert, erlaubt es SDP, Mediendaten zu beschreiben bzw. einzubetten,
um sie mittels RTP (siehe Kapitel 3.2.1.1) übertragen zu können.
Beispiel
v=0
o=UserA 289 0 IN IP4 10.1.1.221
s=Voice over IP-Test c=IN IP4 10.1.1.221
t=0 0 m=audio 4970 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000
Abbildung 3.9: Auszug aus einem SIP/SDP-Header (Sprachkommunikation)
Abbildung 3.9 zeigt typische SDP-Parameter innerhalb eines SIP-Headers:
3 VoIP
42
• v (Protocol Version) gibt die SDP-Version an, die zur Beschreibung der Daten
verwendet wird
• o (Origin) benennt den Initiator der Session (hier: UserA) und übergibt eine
generierte Zufallszahl zur Identifizierung der Session (hier: 289). Die zweite Zahl
dient zur Nummerierung der Session-Versionen, da sich die Session im Verlauf
verändern kann. Die letzten 3 Parameter geben den Typ des Netzwerks (IN =
IP-basiertes Netz), den Adresstyp (IP4 (IPv4)) und die IP-Adresse des Initiators
an.
• s (Session Name) beschreibt den Namen bzw. den Betreff der Session an
• c (Connection Data) gibt die Nutzdatenempfangsadresse des Session-Teilnehmers
an (vgl. o)
• t (Timing) ermöglicht die Angabe von festen Start- und Endzeitpunkten
• m (Media Descriptions) spezifiziert ein zuübertragendes Medium. Zunächst
erfolgt die Angabe des Medientyps (hier: audio) sowie des bereitgestellten Ports
(hier: 4970). Es folgt die Benennung und nähere Spezifizierung des verwendeten
Nutzdatenprotokolls (hier: RTP/AVP) sowie eine Formatliste (hier: 0 und 8).
Die Listeneinträge beziehen sich auf die vom Nutzdatenprotokoll unterstützten
möglichen Codecs (vgl. Attribut a), welche für RTP in der sog. rtpmap-Payload
Type Liste stehen.
• a (Attributes) beschreibt die in der ”Media Description” gelisteten Formate.
In diesem Fall werden zwei mögliche Codecs genannt: PCMU/8000 (G.711 µlaw, Abtastrate 8kHz, rtpmap-Payload Type 0) sowie PCMA/8000 (G.711 a-law,
Abtastrate 8kHz, rtpmap-Payload Type 8)
Gemäß SIP-Standard [60] erfolgt der gegenseitige Austausch medienrelevanter Parameter per SDP im Rahmen des SIP-Session-Aufbaus nach dem sog. Offer/AnswerModell [63]. Dabei wird der erste SDP-Anteil den ein Kommunikationsteilnehmer erhält
als ”Offer” bezeichnet. Die darauf bezogene Antwort, die an den Initiator zurückgeschickt wird, als ”Answer”.
Offer (SIP User Agent A)
m=audio 2410 RTP/AVP 0 8 3 4
3 VoIP
43
m=audio 2468 RTP/AVP 0 3
Answer (SIP User Agent B)
Diese mögliche Offer/Answer-Kombination verdeutlicht, wie der Initiator der Gegenseite eine Portnummer mitteilt, über die er die (audio-)Nutzdaten empfangen möchte.
Von Bedeutung ist hier noch die Liste von möglichen Codecs.
Die Gegenseite antwortet auf das Angebot ihrerseits mit einem Wunschport, sowie einer Codec-liste. Diese unterscheidet sich in dem Beispiel aber von dem Angebot, da
Teilnehmer B offensichtlich nicht alle Codecs zur Verfügung stehen. Die Teilnehmer
werden sich auf eine Liste aus Codecs einigen, welche von beiden Seiten unterstützt
wird.
SIP Verbindung
Wie bereits erläutert, ist SIP für diverse Arten von Multimediaverbindungen einsetzbar. Im Folgenden sollen am Beispiel der Audiokommunikation die SIP-Verbindungsmodalitäten
sowie das Zusammenwirken zwischen den Protokollen betrachtet werden.
Abbildung 3.10: Sprachverbindung zwischen zwei SIP-User Agents
3 VoIP
44
Abbildung 3.10 zeigt den prinzipiellen SIP-Verbindungsablauf. Dass es sich, wie angegeben, um eine Sprachverbindung handelt, lässt sich einzig an den SIP-Parametern
innerhalb der SIP-Nachrichten erkennen. Die Verbindung läuft nicht über einen Proxy,
sondern direkt zwischen zwei User Agents ab, wobei vorausgesetzt wird, dass beide
SIP URIs bekannt sind.
Eine SIP-Verbindung beginnt grundsätzlich mit einer ”INVITE”-Anfrage. Im Beispiel wird in diese Anfrage neben den SIP-Formalitäten auch das Aushandeln der
Spezifika für die Mediendatenübertragung integriert. Wie im vorangegangenen Abschnitt über SDP bereits erläutert, teilt der Initiator der Verbindung (hier: SIP User
Agent A) dem Verbindungsteilnehmer (hier: SIP User Agent B) den Port für die Nutzdatenübertragung, das Nutzdatenprotokoll sowie mögliche Codecs mit. Die auf die
”INVITE”-Anfrage folgenden Statusinformationen (”Trying”, ”Ringing”) sind optional
und für einen erfolgreichen Verbindungsaufbau nicht zwingend notwendig.
Als nächstes folgt die Antwort des Teilnehmers B (200 OK (SDP B)) nach dem
Offer/Answer-Modell.
Jetzt wurden die Verbindungsmodalitäten zwischen den Teilnehmern ausgehandelt und
nach einer Bestätigung (ACK) kommt die eigentliche SIP-Session zustande.
Möchte nun ein Teilnehmer die Verbindung beenden, so teilt er dies der Gegenstelle
durch ein ”BYE” mit, welche die Verbindung ihrerseits beendet (200 OK).
Doch wie kann man eigentlich sicherstellen dass am anderen Ende wirklich der gewünschte Gesprächsteilnehmer ist - man also mit dem richtigen Ziel verbunden wurde?
Und wie lässt sich verhindern, dass man von Dritten belauscht wird? Mit diesen Fragen
beschäftigt sich der nun folgende Abschnitt über die Sicherheit von SIP-Verbindungen.
SIP-Sicherheit
Die Sicherheitsbetrachtungen im SIP-Standard (IETF RFC 3261, [60]) beginnen im
Englischen mit der Folgenden Bemerkung:
”SIP is not an easy protocol to secure. Its use of intermediaries, its multifaceted trust relationships, its expected usage between elements with no trust
at all, and its user-to-user operation make security far from trivial.”[60]
Um bei der Verwendung von SIP Sicherheit gewährleisten zu können, gilt es bei
der Implementierung einige Hindernisse zu beseitigen. Im Folgenden wird auf eine
Reihe von Risiken und Sicherheitsproblemen eingegangen sowie Schutzmechanismen
vorgestellt.
3 VoIP
45
Mögliche Bedrohungen für eine SIP-Session [[18]]:
• Call hijacking: Ein Nutzer wählt eine SIP-Nummer, wird aber mit einem anderen
Teilnehmer verbunden
• Registration hijacking: Eingehende Anrufe werden abgefangen und an einen Dritten umgeleitet
• Impersonation: Jemand gibt sich in einer SIP-Session als jemand anderes aus
• Eavesdropping on signaling: Ein Aussenstehender loggt den Signalisierungsverkehr mit
• Eavesdropping on media: Ein Aussenstehender loggt den Mediendatenstrom mit
• Denial of Service: Ein- oder ausgehende Anrufe zu/von einem Nutzer werden
unterbunden
• Session disruption: Unterbrechung einer bestehenden Session
• Bid-down attack: Ein- oder ausgehende Anrufe zu/von einem Nutzer werden
auf eine niedrigere Sicherheitsstufe umgeleitet. Die Verbindung kommt zustande,
jedoch werden die Sicherheitsmechanismen umgangen.
Um diesen potentiellen Bedrohungen entgegnen zu können, stehen eine Reihe von
Sicherheitsmassnahmen zur Verfügung. Zuerst soll auf Möglichkeiten eingegangen werden, die SIP-Sessions sichern können. Weiter unten folgt dann ein kurzer Überblick
über die Sicherung von Mediendatenströmen im speziellen.
Authentifizierung (Authentication)
SIP kann auf bestehende Internet-Authentifizierungsverfahren zurückgreifen. Eines
dieser Verfahren ist HTTP-Digest (RFC 2617 [15], RFC 3261 [60]). Es bietet einen
einfachen Weg um die Authentizität einer Verbindung zu gewährleisten. Dabei wird
zusätzlich zum SIP-Verbindungsaufbau eine Abfrage und Überprüfung von Benutzername und dazugehörigem Passwort implementiert. Das Passwort wird mithilfe des
MD5 Hash-Algorithmus verschlüsselt und nicht im Klartext übertragen. Selbst in diesem Fall wäre theoretisch noch ein nicht-authentifizierter Eingriff möglich, wenn die
Authentifizierungsdaten ausgeschnitten und in zukünftige Nachrichten eingefügt würden um Echtheit vorzutäuschen. Dem Problem kann entgegnet werden, indem man
bei der MD5-Verschlüsselung jedesmal eine einmalige Zeichenkette (sog. nonce) zur
3 VoIP
46
Verschlüsselung verwendet.
Eine weitere Möglichkeit stellen Zertifikate dar, wie man sie von Webbrowsern kennt.
Zertifikate können die Authentizität von Clients und Servern gewährleisten. Dabei kann
ein Client zum Beispiel das Zertifikat eines SIP-Proxy anfordern um sicherzustellen,
dass der Proxy auch auch wirklich dem gewünschten Ziel entspricht.
Desweiteren kann ein User Agent ein Zertifikat selbst erzeugen und auf einen öffentlichen Zertifikatsserver laden, was vom Prinzip her an das bekannte PGP (Pretty Good
Privacy) Verfahren erinnert.
Nicht zuletzt gibt es Entwicklungen, welche die Authentifizierung in die SDP-Daten in
Form eines Attributs einbetten.
Vertraulichkeit (Confidentiality)
Vertraulichkeit sorgt dafür, dass eine SIP-Session privat bleibt. Verschlüsselung kann
auf verschiedenen Ebenen eingesetzt werden um dies zu garantieren. So kann bei der
Kommunikation über WLAN auf die bekannten Mechanismen WPA, WEP etc. zurückgegriffen werden. Sicherheit kann hier aber nur innerhalb der WLAN-Grenzen
gewährleistet werden, erstreckt sich die SIP-Verbindung darüber hinaus, nutzt auch
die WLAN-Verschlüsselung nichts.
Internet Protocol Security (IPSec) setzt auf der IP-Ebene an und ist über Netzgrenzen
hinweg einsetzbar. Der Vorteil ist aber gleichzeitig auch der Nachteil, da IPSec nur
schwer von SIP aus sichtbar ist und somit kann man nicht unbedingt sicher sein, dass
es gerade aktiv ist.
Secure Multipurpose Internet Mail Extensions (S/MIME) kann verwendet werden um
Teile des SIP-Headers oder der SIP-Nachricht, die nicht für das Routing benötigt werden, zu verschlüsseln.
Ein weiterer Ansatz sieht die Verschlüsselung auf der Transportschicht mittels Transport Layer Security (TLS) vor. Der Vorteil gegenüber IPSec ist die Sichtbarkeit für
SIP bzw. Anwendungen. So würde ein SIP User Agent mitbekommen, wenn eine TLSVerbindung nicht zustandekommt. Von besonderem Interesse für den Einsatz mit SIP
ist die Weiterentwicklung DTLS, welche die Unterstützung von Datagram Protokollen
wie z.B. UDP mitbringt.
Secure SIP
Um die TLS-Verschlüsselung über mehrere Proxies hinweg zu ermöglichen, wurde
Secure SIP entwickelt. Dieses sorgt dafür, dass jede Teilverbindung (z.B. User Agent
zu Proxy, Proxy zu Proxy, Proxy zu User Agent) durch TLS gesichert wird.
3 VoIP
47
Integrität (Integrity)
Integrität sorgt dafür, dass ein Empfänger sicher sein kann, dass die empfangene
Nachricht unterwegs nicht manipuliert wurde. Dies kann mittels Digitaler Signaturen
(z.B. S/MIME Signatur) oder Prüfsummen geschehen. In beiden Fällen müssen Sender
und Empfänger von der Sicherheitsmassnahme wissen, ansonsten könnte ein Angreifer
die Schutzmechanismen entfernen, ohne dass der Empfänger merkt, dass die Nachricht
manipuliert wurde.
Identität (Identity)
Identität ist ähnlich zu der bereits besprochenen Authentizität. Dabei soll die Identität der Verbindungsteilnehmer sichergestellt werden. Einige Verfahren, dies zu gewährleisten, wurden bereits erläutert. Neben der Verwendung von Passwörtern für
eine Direktverbindung, ist auch der Einsatz von Servern denkbar, bei denen sich die
Clients einer Domain anmelden müssen. User Agents innerhalb dieser Domain können, sofern sie sich angemeldet haben, untereinander kommunizieren. Am Übergang
zwischen verschiedenen Domains kann mithilfe der Enhanced SIP identity die Teilnehmeridentität kontrolliert werden. Dabei fügt der Proxy, bei dem sich der User Agent
anmeldet, eine verschlüsselte Zeichenkette in das identity - Feld des SIP-Headers, die
aus einer Reihe von anderen Header-Feldern generiert wurde. Andere Proxies können
nun dieses Feld auswerten um die Identität des Teilnehmers zu prüfen.
SIP ist wie zu Beginn dieses Kapitels schon erwähnt, auf eine Reihe weiterer Protokolle zur Kommunikation angewiesen. An dieser Stelle soll ein kurzer Überblick über
verfügbare Massnahmen erfolgen, welche die Übertragung über diese Protokolle sichern
sollen.
SRTP, MIKEY und ZRTP
Secure RTP (SRTP) soll den Nutzdatenstrom über RTP sichern. Dabei kommt der
Advanced Encryption Standard (AES) zum Einsatz um die Integrität und Vertraulichkeit der Daten sicherzustellen. Desweiteren unterstützt SRTP die Authentifizierung mittels HMAC. Eine Besonderheit von SRTP ist die mögliche Verwendung von
Sicherheitsschlüsseln für mehrere Verbindungen und jeweils in beide Richtungen. So
kann eine Audio/Video-Konferenz mit nur einem Schlüssel gesichert werden, was den
Overhead und damit die Datenmenge reduziert. Der Nachteil von SRTP ist die seperate
Übertragung des AES-Schlüssels. Dieser muss über eine andere Verbindung übertragen
werden, wozu in aller Regel die SIP/SDP-Kommunikation dient. Dabei stellt SDP ein
3 VoIP
48
Attribut zur Verfügung um den Schlüssel zu übertragen. Allerdings müssen andere notwendige Parameter (Schlüssellänge, Authentifizierungsparameter, etc.) weiterhin über
SRTP transportiert werden. Aus diesem Grund wurde das Multimedia Internet Keying
protocol (MIKEY) definiert, welches SDP um weitere Attribute zur SRTP SchlüsselÜbertragung erweitert. Eine Alternative zum Schlüsselaustausch per SIP/SDP stellt
ZRTP dar. ZRTP wurde speziell für die Schlüsselaushandlung sowie zur Übermittlung
der SRTP-Parameter entwickelt. Dabei werden nach dem Verbindungsaufbau mittels
SIP/SDP die ZRTP-Daten in RTP-Header-Erweiterugen transportiert, was gleichzeitig
die Kompatibilität mit SIP/SDP gewährleistet.
3 VoIP
49
3.2.2.3 Vergleich - H.323 und SIP
In den Kapiteln 3.2.2.1 und 3.2.2.2 wurden H.323 und SIP bereits im Detail vorgestellt. So lassen sich beide Protokolle prinzipiell für gleiche Anwendungsfälle einsetzen,
direkt vergleichen kann man sie jedoch aufgrund der unterschiedlichen Definitionsbereiche nicht. Vergleichen lassen sie sich jedoch im Bezug auf die Signalisierung.
Tabelle 3.1 stellt die wichtigsten Unterschiede nocheinmal gegenüber.
Eigenschaft
Generelle Eigenschaften
Komplexität
Zusammenarbeit
PSTN-Netzen
mit
H.323
Vollständiger Standard für
Audio-, Video und Datenkonferenzen. Als Dachstandard
werden mehrere Unterstandards referenziert.
Hoch, durch Verwendung
zahlreicher
Unterstandards
(H.225.0, H.245, H.450 usw.)
Direkt möglich, da H.323 Protokolle des PSTN verwendet
(Q.931)
Nachrichten-Kodierung
Nachrichtendefinition
Binär
ASN.1
TeilnehmerAdressierung
Konferenzsteuerung
Rufaufbauverzögerung
(Call Setup Delay)
Round Trip Times
(RTT)
Signalisierungsserver
Signalisierungstransport
URLs, E.164, Alias-Adressen
Direkte Ende-zu-EndeSignalisierung
Ja
1,5 RTT (H.323v4), max ca. 7
RTT
Gatekeeper
Gesichert/ungesichert (z.B.
UDP oder TCP, zukünftig
auch SCTP)
Möglich
SIP
Protokoll für die Signalisierung von MultimediaSitzungen ohne Festlegung
auf bestimmte Anwendungsbereiche; modular einsetzbar.
Niedrig, nur auf Signalisierung spezialisiert, keine Vorschriften zur Verwendung weiterer Protokolle
Keine
direkten
Gemeinsamkeiten, Zusammenarbeit
durch Erweiterungen möglich, die in zusätzlichen
Drafts/RFCs
beschrieben
sind.
Textbasiert, HTML-ähnlich
ABNF (Augmented Backus
Naur Form)
URLs (SIP-URI), kann z.B.
auch Tel-Nr. enthalten
Nein
1,5 RTT
SIP Proxy-Server
Gesichert/ungesichert (z.B.
UDP oder TCP, zukünftig
auch SCTP)
Möglich
Tabelle 3.1: Vergleich von H.323 und SIP (in Auszügen aus [53])
Der H.323 Standard definiert ein komplettes Multimediasystem von der Signali-
3 VoIP
50
sierung über die Paketierung bis hin zur Kodierung. Es ist ein sehr komplexer und
”schwerer” Standard, mit dem sich viele Entwickler heutzutage nicht mehr anfreunden
können. Daher sind in der Praxis, trotz der vollständigen Systemfestlegung durch H.323
nur wenige Produkte zueinander kompatibel. Dies geht soweit, dass einige Hersteller
Listen mit Fremdprodukten veröffentlichen mit denen ihr eigenes System erfolgreich
zusammenarbeitet.[53] Vorteile von H.323 sind die genau definierten Protokolle und die
Beschreibungen bezüglich Erlaubtem und Verbotenem. Den Preis zahlt der Standard
dadurch, dass er aufgrund seiner Komplexität ein rigider Standard ist, der schwer an
zukünftige Anwendungen anzupassen ist.
Im Gegensatz dazu steht SIP als ein ”schlankes”, typisches Internetprotokoll, das
ausschließlich zur Signalisierung dient. Der Austausch von Mediendaten wird nicht
durch SIP geregelt und liegt nicht in dessen Defintionsbereich. Das Protokoll wurde
entwickelt um mit anderen Protokollen sowie Codecs und Anwendungen gut zusammenzuarbeiten.
3 VoIP
51
3.2.2.4 IAX - Inter Asterisk eXchange Protocol
IAX ist ein Peer-to-Peer-Protokoll, das vorwiegend in der Open-Source IP-Telefonanlage
Asterisk zum Einsatz kommt. Neben der Kommunikation zwischen zwei Asterisk IPTelefonanlagen existieren auch Endgeräte, wie Hardware- oder Software-Clienten, die
Gespräche auf Basis des IAX-Protokolls ermöglichen.
IAX ist in erster Linie für die Signalisierung und Übertragung von Sprachdaten ausgelegt, kann jedoch anstatt der Sprachdaten ebenso für den Transport von Multimediadaten (Audio und Video) genutzt werden. Es ist somit das einzige offengelegte Protokoll,
welches die Signalisierung und Übertragung der Sprachdaten innerhalb einer Protokollarchitektur realisiert.
Dies ermöglicht, einen statischen UDP-Port (4569) für die Signalisierung und den
Transport der Sprachdaten zu verwenden. Somit reduziert IAX den Overhead gegenüber einer Realisierung, bei der die Übertragung der Signalisierung und der Sprachdaten durch zwei verschiedene Protokolle erfolgt. Der geringere Overhead und die binär codierte Übertragung der IAX-Nachrichten ermöglichen eine effektivere und damit sparsamere Nutzung der Bandbreite. Zusätzlich werden Sprachverbindungen beim
Einsatz von IAX in einer Verbindung gebündelt (Trunking). Dabei werden in einem
Trunk die Nutzdaten einer oder mehrerer Sprachverbindungen unter Verwendung eines
Trunk-Headers transportiert. Dies ermöglicht es, die zur Verfügung stehende Bandbreite effektiver zu nutzen, da die Anzahl der versendeten Pakete pro Verbindung und somit
der Overhead durch zusätzliche Header reduziert werden kann.
Der Transport der IAX-Nachrichten in einer einzelnen Verbindung erleichtert die Übertragung der Sprachdaten über Netzwerkgrenzen mit NAT und Firewall. Damit ist ein
parsen der Signalisierungsnachrichten nicht notwendig, da eine Vereinbarung der für die
Übertragung der Sprachdaten verwendeten Ports innerhalb der Signalisierung entfällt.
Firewallregeln können so wesentlich genauer und ohne den Einsatz eines Application
Layer Gateway (ALG) defniert werden, wodurch sich die Sicherheit gegenüber einem
nicht vertrauenswürdigen Netzwerk erhöht.
IAX verwendet zur Adressierung von Kommunikationsteilnehmern einen ähnlichen
Aufbau der URI, wie dies bei SIP der Fall ist, allerdings mit der notwendigen Unterscheidung im verwendeten protokollspezifischen Schema. Der schematische Aufbau
einer IAX-URI ist im Folgenden aufgezeigt: iax2:benutzer@hostname
Die Übertragung der IAX-Nachrichten erfolgt in sogenannten Frames. Dabei wird zwischen Full Frames (12 Byte), Mini Frames (4 Byte) und Meta Frames unterschieden.
Während in Mini Frames ausschließlich Sprach- bzw. Mediendaten übertragen werden,
erfolgt innerhalb der Full Frames eine Übertragung der Signalisierungsnachrichten. Me-
3 VoIP
52
ta Frames ermöglichen die Übertragung von Trunk- sowie Videoverbindungen (Meta
Trunk Frames und Meta Video Frames). Zusätzlich erfolgt innerhalb der Spezifizierung
von IAX eine Unterscheidung zwischen zuverlässigem und unzuverlässigem Transport.
Der Transport der Full Frames (Signalisierung) erfolgt zuverlässig, wohingegen Mini
und Meta Frames unzuverlässig übertragen werden. Unzuverlässig bedeutet in diesem
Fall, dass keinerlei Bestätigung über den erfolgreichen Empfang einer Nachricht versendet wird, während bei Full Frames eine Bestätigung durch ein ACK oder eine zum
versendeten Frame Bezug nehmende Nachricht erfolgt.
Bevor ein Kommunikationsteilnehmer für andere Teilnehmer erreichbar ist, muss sich
dieser (Registrant) gegenüber dem Registrar anmelden. Zur Registrierung ist eine Authentifizierung notwendig. Die IAX-Spezifikation sieht dafür die drei Methoden plain,
MD5 und RSA vor. Bei der Methode plain erfolgt eine Authentifizierung im Klartext
und sollte somit nicht verwendet werden. Bei der Verwendung von MD5 erfolgt eine
Übertragung des Passwortes auf Basis eines Challenge-Response-Verfahrens unter der
Verwendung von MD5-Hashverfahren. Wird rsa eingesetzt, werden die Benutzerdaten
auf Basis von Public-Key-Verfahren verschlüsselt, die den Einsatz einer PKI erfordern.
Im Folgenden soll der Verlauf einer Kommunikationsverbindung mit voriger Authentifizierung anhand der Abbildung 3.11 verdeutlicht werden.
Die Anfrage einer Verbindung (call leg) wird vom IAX-Peer A (Alice) durch das Senden einer IAX-Nachricht mit dem Bezeichner NEW (IAX-Event) eingeleitet (1). Dabei
besitzen alle IAX-Nachrichten innerhalb der Signalisierung den Pakettyp Full-Frame.
In dieser Nachricht wird ebenfalls eine Liste mit Codecs übergeben, wobei die von Alice
unterstützten gekennzeichnet sind. Daraufhin fordert IAX-Peer B (Bob) durch Senden
des IAX-Events AUTHREQ (2) eine vorherige Authenti?zierung von Alice an. In dieser Nachricht werde die von ihm unterstützten Methoden zur Authentifizierung (MD-5,
RSA) übergeben sowie einen Zufallswert (Challenge). Alice berechnet daraufhin mit
ihrem Passwort die MD5-Challenge-Response und sendet diese (AUTHREP) an Bob
(3). Dieser bestätigt den erfolgreichen Aufbau der Verbindung mit dem IAX-Event
ACCEPT (4) und übermittelt den für die Codierung der Sprachdaten verwendeten
Codec, der wiederum von Alice durch ein ACK (5) bestätigt wird. Bob signalisiert
dem Anrufenden, dass er über den Wunsch des Verbindungsaufbaus informiert ist
und sein Telefon klingelt. Dazu sendet er die Statusinformation (Control-Frame) RINGING (6), die von Alice wiederum durch das Senden eines ACK (7) bestätigt wird.
Wird die Verbindungsanfrage von Bob angenommen, schickt dieser das Control-Frame
mit dem Bezeichner ANSWER (8), welches ebenfalls durch ein ACK (9) bestätigt
3 VoIP
53
Abbildung 3.11: IAX-Kommunikation
wird. Daraufhin wird der Typ der Verbindung zwischen den beiden Peers verhandelt.
Dazu sendet Alice eine Sprachnachricht (10) an Bob, in dieser der Verbindungstyp
angegeben wird (Voice61). Dieser bestätigt den Erhalt der Nachricht durch ein ACK
(11). Daraufhin werden die Sprachdaten zwischen den beiden Peers unter Verwendung des Pakettyps Mini-Frame ausgetauscht (12). In regelmäßigen Abständen wird
der Zustand der Sprachverbindung (12, 15) durch das Senden einer Sprachnachricht
(13) und der entsprechenden Bestätigung (ACK) überprüft (14). Wird das Gespräch
von Alice beendet, wird ein IAX-Event HANGUP (16) an Bob gesendet, der das Ge-
3 VoIP
54
sprächsende durch ein ACK (17) bestätigt. Weiterhin wird die Verschlüsselung der
Gesprächsdaten ebenfalls unter Verwendung des AES unterstützt. Der Aufbau einer
verschlüsselten Verbindung wird initiiert, indem im IAX-Event NEW der Parameter
ENCRYPTION mit der Angabe der Verschlüsselungsmethode (AES-128) hinzugefügt
wird. Aktuell wird ausschließlich der AES-Algorithmus mit 128 Bit Schlüssellänge unterstützt. Wenn der Angerufene ebenfalls diese Verschlüsselung unterstützt, sendet er
eine Nachricht mit dem IAX-Event AUTHREQ, die ebenfalls den Parameter und die
Methode zur Verschlüsselung enthält. Der Schlüssel zur Verschlüsselung wird erzeugt,
indem der Zufallswert mit dem Passwort verknüpft wird und dann unter Verwendung
des MD5-Algorithmus chiffriert wird. Mit dem Parameter ENCKEY wird zusätzlich
die Möglichkeit gegeben, dass in einer bereits verschlüsselten Verbindung die Schlüssel
für AES-Verschlüsselung gewechselt werden können.
3 VoIP
55
3.2.3 Gateway- und Routing-Protokolle
Im Gegensatz zu den Ende-zu-Ende-Signalisierungsprotokollen wie H.323 oder SIP
verfolgen Gateway-Protokolle einen etwas anderen Ansatz. Hierbei liegt die Intelligenz
nicht bei den Clients sondern zentral bei einer sogenannten Master-Instanz, welche die
Gateways zwischen den Kommunikationspartnern steuert.
Abbildung 3.12: Evolution der Gateway-Steuerungsprotokolle [53]
Im Lauf der Zeit gab es mehrere getrennte Entwicklungen. Wie in Abbildung 3.12
dargestellt entstand Anfang 1998 das Simple Gateway Control Protocol (SGCP). Etwas
später ging aus SGCP und dem neuentwickelten IP Device Control (IPDC) das Media
Gateway Control Protocol (MGCP) hervor.
MGCP wurde von der IETF entwickelt aber nie standardisiert. Dennoch kam es in
zahlreichen Produkten zum Einsatz und ist von daher als Quasi-Standard anzusehen,
zumal es noch immer als RFC 3535 weiterentwickelt und veröffentlicht wird.
3.2.3.1 H.248/Megaco (Media Gateway Control Protocol)
Aus MGCP sowie dem Media Device Control Protocol (MDCP) entstand H.248/Megaco.
Megaco dient wie auch MGCP zur Steuerung von Media-Gateways. Media-Gateways
kommen am Übergang zu PSTN-Netzen zum Einsatz und stellen die Schnittstelle
zu den Endgeräten dar. Media Gateway Contoller (MGC) können nun Sprachkanäle
zwischen Endgeräten und den Gateways bzw. zwischen verschiedenen Gateways (z.B.
Media-Gateway - Signalisierungsgateway) schalten. Megaco arbeitet dabei unabhängig
von der Rufsignalisierung. Zwar bilden die MGCs auch die Schnittstelle zu den Signalisierungsgateways, das Megaco-Protokoll wird aber ausschließlich zwischen Media
Gateway und Media Gateway Controller eingesetzt. Die MGC sind multiprotokollfähig und ermöglichen den Einsatz, verschiedener Signalisierungsprotokolle (z.B. H.323,
SIP).
3 VoIP
56
Abbildung 3.13: Einsatzbereich von H.248/Megaco [53]
Das Verbindungsmodell basiert auf Kontexten und sogenannten Terminierungen.
Letztere stellen den Verbindungsabschluss in einem Netz dar. Sind verschiedene Terminierungen einem gemeinsamen Kontext zugeordnet so kann ein Medienaustausch
zwischen den Verbindungsendpunkten zustandekommen. Beispielsweise kann ein Kontext eine Dreierkonferenz zwischen Clients aus dem PSTN-Netz und dem IP-Netz sein.
3 VoIP
57
3.3 NAT - Network Address Translation
Die 1981 standardisierte (RFC 791)[] Version 4 des Internet Protokolls (kurz IPv4)[]
ermöglicht bis heute die Adressierung von Clients in IP-Netzen. IPv4 benutzt 32-BitAdressen, daher sind maximal 4.294.967.296 eindeutige Adressen möglich. Mit der steigenden Anzahl an Internetnutzern, sowie dem vermehrten Einsatz von Netzwerken in
Privathaushalten und Unternehmen, stieg auch der Bedarf an IP-Adressen. Heutzutage
sind weit mehr IP-Clients im Einsatz als verfügbare Adressen.
An dieser Stelle kommt die sogenannte Network Address Translation (NAT) ins Spiel.
Network Address Translators (NATs) sind Einheiten, welche die IP-Adresse, und
im Fall von Network Address and Port Translators (NAPTs) auch die Portnummer,
von IP-Paketen beim Übergang zwischen Zwei Netzen modifizieren. Am weitesten verbreitet sind NATs in Privatnetzwerken, in denen keine global eindeutigen IP-Adressen
verwendet werden. Sollen nun IP-Pakete aus dem lokalen Netzwerk ins Internet gesendet werden, so wird der NAT benötigt um die lokale Adresse durch eine globale
(”routbare”[1 ]) Adresse zu ersetzen. Der private Adressbereich ist insofern nicht ”routbar” als die Adressen nicht einmalig sind und Internetroutern somit keine eindeutige
Zielzuweisung möglich ist.
Des weiteren werden NATs oftmals als Sicherheitsvorkehrung genutzt, um die interne
Struktur eines Netzwerks nach außen hin zu verstecken. Dabei macht man sich zu nutze,
dass das lokale Netz hinter dem NAT von außen betrachtet nur eine global eindeutige
IP-Adresse besitzt, was Direktzugriffe auf lokale Clients erschwert.
3.3.1 NAT-Problematik
Neben den Möglichkeiten, die Network Address Translation bietet, birgt sie auch Probleme. Die Umsetzung von IP-Adressen in einem NAPT geschieht in Schicht 3 des
OSI-Schichtenmodells, UDP- bzw. TCP-Portnummern werden hingegen in Schicht 4
bearbeitet. Es ist nicht möglich, Informationen aus höheren Schichten auszuwerten
bzw. abzuändern.
3.3.1.1 SIP
Dies stellt für die Übertragung mittels SIP ein Problem dar, da es innerhalb von SIPAnfragen Parameter gibt, die weder auf Schicht 3 noch Schicht 4 übertragen werden.
Abbildung XXX zeigt den Auszug aus einem SIP-Header. Problematische Parameter,
1
”routbar” bezeichnet hier die Eigenschaft von Paketen durch Router vermittelt zu werden.
3 VoIP
58
die vom NAT nicht modifiziert wurden sind fett hervorgehoben.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060;branch=z9hG4bKhjh
From: TheBigGuy <sip:[email protected]>;tag=343kdw2
To: TheLittleGuy <sip:[email protected]>
Max-Forwards: 70
Call-ID: 123456349fijoewr
CSeq: 1 INVITE
Subject: Wow! It Works...
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: ...
v=0
o=UserA 2890844526 2890844526 IN IP4 UserA.customer.com
c=IN IP4 10.1.1.221
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Abbildung 3.14: Auszug aus einem SIP-Header zeigt Fehler bei der NAT-Umsetzung
Aufgrund des Network Address Translators ...
• kann die Antwort auf die obige SIP-Anfrage nicht an den ursprünglichen Absender zurückgeschickt werden, da die problematischen Parameter in einen privaten
Adressbereich zeigen, der vom öffentlichen Netz aus nicht erreichbar ist (fehlerhafter ”Via:” Eintrag).
• würden zukünftige Anfragen während der SIP-Sitzung falsch geroutet werden
(fehlerhaftes ”Contact:” Feld).
• würden RTP-Pakete von UserB falsch geroutet werden (fehlerhafte ”connection
IP address c=” für die Daten im Session Description Protocol ).
Angemerkt sei noch, dass die Portnummern 5060 und 49170 durch einen NAPT verändert werden könnten, was sowohl bei der Signalisierung als auch beim Datentransfer
zum Abbruch führen würde.
Von den drei genannten Problemen kann nur das erste direkt mit SIP selbst gelöst
werden. So kann ein SIP User Agent (UA), der die obige Anfrage erhält, den ”Via:”Eintrag mit der tatsächlichen IP-Adresse des Senders vergleichen. Für den Fall dass die
3 VoIP
59
beiden nicht übereinstimmen kann der User Agent dem ”Via:”-Eintrag den Parameter
”received=” mit der eigentlichen IP-Adresse hinzufügen. In der Folge würde der neue
Wert verwendet werden und das Paket erfolgreich zurückgeschickt werden, unter der
Voraussetzung, dass der NAT die identische Bindung zwischen lokaler und öffentlicher
IP-Adresse beibehält [[18]]. Ein weiterer Ansatz (rport) ist in RFC 3581 [[44]] beschrieben.
Das zweite Problem kann durch SIP Outbound gelöst werden. [[10]]
Der Fehler im SDP-Bereich des SIP-Headers ist das schwerwiegendste Problem. Jedoch gibt es Lösungsansätze mithilfe von Interactive Connectivity Establishment (ICE)
(siehe Abschnitt 3.3.3).
3.3.1.2 IAX
Wie bereits in Abschnitt 3.2.2.4 besprochen, ermöglicht IAX die Übertragung sämtlicher Daten (Signalisierung und Multimediadaten) über ein Protokoll und eine einzelne UDP Verbindung. Standardmäßig kommt dabei der Port 4569 (IAX2) bzw. 5036
(IAX) zum Einsatz. Der Voteil ist, dass IAX damit weit weniger anfällig für NATbzw. Firewall-Konflikte ist. Ist der NAT-Gateway jedoch kein sogenannter ”consistent
NAT”, d.h. dass die Port-Zuweisung durch den NAT nicht immer identisch ist, so kann
auch mit IAX keine Verbindung sichergestellt werden. Das gleiche gilt natürlich wenn
eine vorhandene Firewall die Kommunikation nicht erlaubt.
3.3.1.3 Skype
Beim proprietären Skype-Protokoll stellt sich die Sache etwas anders dar. Da es vom
Hersteller keine detailierten Information darüber gibt, wie die Elemente des SkypeNetzwerks miteinander kommunizieren, wurde 2004 eine Untersuchung an der Columbia University in New York durchgeführt [??? skype analysis ???]. Eine typische
Skype-Verbindung beginnt damit, dass der Client eine Reihe von Versuchen unternimmt eine Verbindung zu einem Host Cache aufzubauen. Dabei beginnt er mit dem
Versuch eine UDP und eine TCP Verbindung herzustellen. Als Port nutzt er eine bei
der Installation der Software zufällig generierte Portnummer. Klappt dies nicht, so
wird als nächstes versucht eine UDP/TCP Verbindung zu Port 80 und im Anschluß
daran eine weitere zu Port 443 aufzubauen. Der Vorteil an dieser Herangehensweise
ist, dass die meisten Firewalls Port 80 (HTTP) und Port 443 (HTTPS) nach außen
3 VoIP
60
hin geöffnet haben. Des weiteren verwendet Skype eine Variante des STUN-Protokolls,
wodurch die Funktionsweise hinter den meisten NAT-Gateways sichergestellt werden
kann (siehe 3.3.3).
3.3.2 Firewalls
Ein weiteres Hindernis für VoIP-Verbindungen stellen Firewalls dar. Firewalls kommen an Netzübergängen zum Einsatz um Datenströme zu kontrollieren und bieten die
Möglichkeit, den Verkehr passieren zu lassen oder gegebenenfalls zu blockieren. Eine Firewall kann prinzipiell sämtlichen Datenverkehr unterbinden, in aller Regel sind
aber eine Reihe von Diensten bzw. Ports zugelassen, die die Kommunikation mit einem anderen NE ermöglichen. Das können z.B. Emailvekehr(SMTP, POP, IMAP),
DNS-Anfragen, HTTP oder FTP Verbindungen sein. Diese Erkenntnis ist insbesondere wichtig, wenn unter XXX auf das Skype Protokoll eingegangen wird. Unabhängig
vom Protokoll bedeutet dies jedoch, dass einzig die Konfiguration der Firewall festlegt,
in welcher Form eine Verbindung zustande kommen kann und welche Fehler auftreten
können.
Im Gegensatz zum NAT kann eine Firewall so konfiguriert werden, dass sie SIP und
andere Multimediadaten durchlässt. Dies erzeugt mitunter aber Sicherheitslücken in
der Firewall, die nur wenige Netzwerkadministratoren bereitwillig zulassen.
An dieser Stelle sollen daher andere Lösungsansätze sowohl für die NAT- als auch
die Firewallproblematik vorgestellt werden.
3.3.3 STUN, TURN und ICE
Die Internet Engineering Task Force (IETF) hat drei Protokolle standardisiert, die bei
der NAT-Problematik zum Einsatz kommen können. Im Folgenden sollen diese kurz
beim Einsatz in der VoIP-Kommunikation mittels SIP vorgestellt werden, dabei sind
die Mechanismen natürlich nicht an SIP gebunden sondern universell einsetzbar.
Das Simple Traversal of UDP through NAT (STUN)[[43]]2 erlaubt es einem SIPUser Agent herauszufinden, ob er sich hinter einem NAT befindet und wenn ja, um
was für eine Art NAT es sich handelt und welche öffentliche IP-Adresse dieser hat.
Dabei kommt ein sogenannter STUN-Server zum Einsatz, der an das öffentliche Netz
angeschlossen ist.[??? Funktionsweise der Tests ???] STUN ermöglicht es Endgeräten,
2
STUN wird zur Zeit von der IETF überarbeitet. In Zukunft soll STUN für ”Session Traversal
Utilities for NAT” stehen, da es nicht mehr nur für UDP, sondern auch für TCP genutzt werden
kann.
3 VoIP
61
die Network Address Translation teilweise in die eigenen Hände zu nehmen und IPAdressen-Übersetzungsfehlern durch das Modifizieren von Header-Daten vorzubeugen.
Dies ist allerdings nicht möglich, wenn sich beide Seiten einer Verbindung jeweils hinter
einem NAT befinden. In diesem Fall kann man auf TURN als Lösungsansatz zurückgreifen.
Traversal Using Relays around NAT (TURN) [45] ist ein Protokoll, dass Clients die
Möglichkeit bietet, Transportadressen von einem TURN Server aus dem öffentlichen
Netz zu erhalten. Zum Einsatz kommt es vor allem im oben genannten Fall, wenn zwei
Clients hinter zwei NATs miteinander kommunizieren wollen. Dabei wird der gesamte
Vekehr umgeleitet über den TURN Server, der sich um korrekte IP-Adressen kümmert.
Für bestimmte Situationen in denen symmetrische NAT oder strenge Firewall-Regeln
benutzt werden, stellt TURN allerdings die einzige Möglichkeit dar, eine Verbindung
aufzubauen.
Interactive Connectivity Establishment (ICE) [62] stellt eine Mischung aus STUN
und TURN dar (STUN- und TURN-Server werden benötigt). Dabei signalisiert ein
SIP-User Agent Client (UAC) dem SIP-User Agent Server (UAS) beim Herstellen
einer Verbindung jede ihm bekannte Transportadresse (IP-Adresse + Portnummer).
So könnte ein UAC zum Beispiel folgende Adressen kennen:
• lokale IP-Adresse
• öffentliche IP-Adresse (mittels STUN erfahren)
• durch TURN erhaltene, sogenannte Media-Relay-Adresse
Im Gegenzug erhält der UAC vom UAS alle Transportadressen mitgeteilt, die dieser
kennt. Daraufhin fangen beide Seiten an, STUN-Pakete an die von der Gegenstelle
erhaltenen Adressen zu senden. Wichtig dabei ist, dass die Pakete von den gleichen IPAdressen aus verschickt und empfangen werden, welche später zur Datenübertragung
(z.B. RTP, RTCP) genutzt werden sollen. Die in Frage kommenden Kandidaten werden
dabei in den SIP-Header integriert [61]. Nach dem Austausch der STUN-Pakete wird
die beste Route ermittelt und der Datenverkehr initiiert. Falls erforderlich kann die
Verbindung jederzeit neu initialisiert werden.
”Die Bedeutung von ICE geht über die reine NAT-, Firewall-Problematik hinaus. So
trägt es zur Sicherheit heutiger SIP-Verbindungen bei, da z.B. der gängigste Denialof-Service (DoS) Angriff ”voice hammer” automatisch unterbunden wird.” [61]
3 VoIP
62
3.3.4 Application Layer Gateways (ALG)
STUN, TURN und ICE haben unter anderem eines gemeinsam. Alle drei sind auf
eine Unterstützung im SIP-User Agent angewiesen. Eine alternative Herangehensweise
bietet der Application Layer Gateway (ALG). Für den Fall dass es eine Firewall zu
passieren gilt, wirkt der ALG als SIP- und RTP-Proxy. Dabei wird die Firewall so
konfiguriert dass SIP- und RTP-Pakete durchgelassen und an den ALG weitergeleitet
werden. Jedoch nur die Pakete, vom ALG kommen oder dorthin gesendet werden
sollen. Der ALG kann die Daten dann verschiedenen Tests wie z.B. Authentifizierung,
Echtheitsprüfung, etc. unterziehen, je nachdem wie er vorher eingerichtet wurde.
Der Umweg über den Proxy hat einen weiteren Vorteil. So ermöglicht er auch den
Einsatz hinter einem NAT, da die Pakete vom Proxy angepasst werden.
Der Nachteil von Application Layer Gateways ist, dass sie keine Ende-zu-Ende Verbindung zwischen SIP-User Agents zulassen. Das hat zur Folge, dass viele der in 3.2.2.2
beschriebenen Sicherheitsmechanismen nicht mehr funktionieren.
• Zum Beispiel würde ein ALG, der nicht Teil des SIP-Signalisierungspfads ??? ist,
von einem TLS aktivierten SIP-User Agent außer acht gelassen werden.
• Bei der Verwendung von S/MIME wäre es dem ALG unmöglich den Header zu
parsen und zu verändern.
• Wird vom ”identity”-Feld im SIP-Header gebrauch gemacht, kann ein ALG den
Header modifizieren und die Signatur damit ungültig machen.
Aus diesem Grund werden im Allgemeinen die in Abschnitt 3.3.3 beschriebenen
STUN-, TURN- und ICE-Mechanismen dem ALG vorgezogen.
3 VoIP
63
3.4 Codecs
3.4.1 Einführung - Was sind Codecs?
Codecs sind Algorithmen, welche für die Umwandlung eines (digitalen) Signals in ein
anderes, entsprechend dem Algorithmus, kodierten Signals zuständig sind. Bei der
Sprachkommunikation, über (große) Entfernungen durch entsprechende Netze, durchläuft die Übertragung der Sprache vom Sender zum Empfänger mehrere Stufen:
• A/D-Wandlung am Sender
• Enkodieren (Sprachkodierung)
• Übertragung durch ein Transportmedium (bei VoIP: IP-Netz)
• Dekodieren (Sprachkodierung)
• D/A-Wandlung am Empfänger
Die Stelle, an welcher Codecs zum Einsatz kommen sind der Enkodier- und der Dekodiervorgang. Da hierbei grundsätzlich Algorithmen für die Erzeugung von digitalen
Audiosignalen zum Einsatz kommen, spricht man bei den eingesetzten Codecs auch
von Audio- oder Sprachcodecs. Alle arbeiten verlustbehaftet, das bedeutet, dass durch
die Kodierung Teile des Ausgangssignals verloren gehen.
Die Datenrate des Signals wird bei dieser Umwandlung, unter anderem durch eine
Redundanz- und Irrelevanzreduktion, verringert. Dabei spielen Faktoren, wie zum Beispiel psychoakustische Gegebenheiten des menschlichen Gehörs oder die zur Verfügung
stehende Bitübertragungsrate des Kanals eine wichtige Rolle. Bei zunehmender Komprimierung nimmt die Sprachqualität ab, der Aufwand für das En- bzw. Dekodieren
wird allerdings größer!
Bei dem Gebrauch des Begriffes Codec muss zwischen ”Bandbreite” und ”Bandbreite”
unterschieden werden:
• ”Audiobandbreite”
..kennzeichnet den übertragenen Frequenzbereich des Audiosignals.
Die Einheit ist Hertz (Hz).
• ”Kanalbandbreite”
..kennzeichnet die durch das Übertragungsmedium bereitgestellte Bitrate.
Die Einheit ist Bit pro Sekunde (bit/s).
3 VoIP
64
Bei ISDN (ITU G.711) wird nur Sprache im Frequenzbereich von 300 bis 3400 Hz in die
Kodierung übertragen, woraus ein Datenstrom mit einer Bitrate von 64 kbit/s erzeugt
wird.
3.4.2 Funktionsweise eines Audiocodecs
Senderseitig wird das gesprochene Wort mittels Mikrophon in eine elektrische Spannung gewandelt. Eine anschließende Analog-Digital-Wandlung (diskrete Abtastung
und Quantisierung) ermöglicht die Weiterverarbeitung durch einen Computer. Der
Audiocodec untersucht diesen, aus der Abtastung zu bestimmten Zeitpunkten und
gleichzeitiger Quantisierung entstandenen, Datenstrom und erzeugt daraus entsprechend seinen Algorithmen einen kodierten digitalen Audiodatenstrom.
Dabei kommen zwei unterschiedliche Kodierungsverfahren zum Einsatz[2]:
• Abtast-orientierte Sprachkodierung
Bei der Abtast-orientierten Sprachkodierung wird das analoge Sprachsignal abgetastet und alle Abtastwerte werden einzeln kodiert. Die einfachste Form stellt
das PCM-Verfahren nach ITU-T-Standard G.711 dar (siehe 9.1.1).
Da Sprachsignale stochastische Abhängigkeiten aufweisen, werden sogenannte
Prädiktionsverfahren eingesetzt, welche aus vorhergegangenen Werten die folgenden Werte ”‘schätzen”’ und nur den Fehler zum tatsächlichen Wert übertragen.
Sender und Empfänger besitzen dabei den gleichen Schätzalgorithmus, wodurch
der Empfänger mit Hilfe der vorgangenen Werten und dem Fehler die aktuellen
Werte bestimmen kann.
ITU-T G.722 (siehe 9.1.2) und ITU-T G.726 (siehe 9.1.4) nutzen solche Prädiktionsalgorithmen.
• Segment-orientierte Sprachkodierung
Die Segment-orientierte Sprachkodierung ist bei VoIP von großer Bedeutung, da
sich hiermit die größten Komprimierungseffekte erreichen lassen.
Die Verfahren nutzen das Prinzip Analysis-by-Synthesis, welches das Sprachsignal in Segmente von 10 bis 20 ms zerlegt und diese analysiert. Basis für diese
Analyse stellt der menschliche Vokaltrakt dar, in dem die menschliche Sprache
erzeugt wird. Da die menschliche Sprache in kleinen Zeitintervallen (10 bis 30ms)
unverändert bleibt, kann in diesen Intervallen der menschliche Vokaltrakt durch
wenige Parameter beschrieben werden. Bei der eigentlichen Übertragung werden
dann nur diese Parameter übertragen, was die zu übertragende Datenmenge erheblich reduziert.
3 VoIP
65
ITU-T G.723.1 (9.1.3), G.728 (9.1.5) und G.729 (9.1.6) basieren auf segmentorientierter Sprachkodierung.
Dieser durch den Codec bereitgestellte, kodierte Audiodatenstrom wird durch nun
ein entsprechendes Protokoll durch das IP-Netz zum Empfänger transportiert. Am
Empfänger werden die gleichen Schritte wie beim Sender durchlaufen, nur in die andere Richtung: Aus dem kodierten Audiostrom erzeugt der Audiocodec einen digitalen
Datenstrom, welcher letztendlich durch Lautsprecher, Kopfhörer oder Headset in ein
analoges Sprachsignal umgewandelt wird.
Ein weiteres Kriterium bei Audiocodecs ist die Komplexität. Sie gibt wieder, welcher
Aufwand bei en- und dekodieren nötig ist und wird in MIPS (Millionen Instruktionen
pro Sekunde) angegeben.
In Abschnitt 3.4.6 sind für verschiedene Sprachcodecs Eckdaten aufgelistet. Wie leicht
zu erkennen ist, steigt mit sinkender Datenrate die Komplexität der Codecs: ”Eingesparte Bandbreite wird mit gestiegenem Rechenaufwand erkauft”!
3.4.3 Einflüsse während der Übertragung
Codecs zur Sprachdigitalisierung müssen, bedingt durch die Struktur des Internets,
Paketverluste (bis zu 5 Prozent) verkraften, Laufzeitunterschiede der einzelnen Pakete
ausgleichen und die Pakete in die richtige Reihenfolge sortieren können (Forward Error
Correction und Jitter Buffering).
Für Paketverluste und Ende-zu-Ende-Verzögerungszeit, auch Delay genannt, gibt es
von der ITU-T mit der Empfehlung G.114 eine Richtlinie, welche eine Aussage zur
Qualität einer Sprachübertragung trifft [53] .
Abbildung 3.15 veranschaulicht den Inhalt der Empfehlung:
Eine Verzögerungszeit bis 150 ms bietet eine akzeptable Sprachqualität. Bis 400 ms
Verzögerungszeit sind vertretbar, wenn alle Gesprächsteilnehmer dies bewusst Inkaufnehmen, beispielsweise bei der Nutzung einer Satellitenverbindung. Hierbei wird eine
Echokompensation aber dringend empfohlen.
3 VoIP
66
Abbildung 3.15: ITU-Empfehlung G.114
Die Verzögerungszeit setzt sich im wesentlichen aus folgenden Komponenten zusammen:
• Kodierungs- und Kompressionszeit (u.a. durch Audiocodecs)
• Paketisierungszeit (Verarbeitungszeit im Protokollstack)
• Serialisierungszeit (”Einspeisungszeit” ins Netzwerk)
• Netzwerkverzögerungszeit (Warteschlangen,..)
• Signallaufzeit
• Pufferzeit
Einen nicht zu unterschätzenden Einfluss auf die Qualität der Sprachübertragung
haben, neben der Übertragung durch das IP-Netz, die eingesetzten Endgeräte! Das
schwächste Glied in der Kommunikationskette bestimmt die Gesamtperformance des
gesamten Systems!
3 VoIP
67
3.4.4 Bandbreitenanforderungen
Die durch einen Codec erzielte Datenrate ist aber nicht die realistische Datenrate,
welche für eine Übertragung durch ein IP-Netz benötigt wird. Zusätzliche zu den reinen
Nutzdaten, kommt ein nicht unerheblicher Anteil von Overhead dazu!
Welche Bandbreite wird tatsächlich benötigt?
Dazu ein Beispiel (Verwendung von RTP (3.2.1.1 und 3.3), Monosignal):
Eckwerte
Datenrate des Codecs
Paketierungszeit (abhängig vom Codec)
Erzeugte Pakete pro Minute
RTP-Nutzlast
IP-Paketgröße
Bandbreite auf IP-Ebene
6,3 kbit/s
30 ms
33,3
24 Byte
64 Byte
rund 17 kbit/s
Tabelle 3.2: tatsächlicher Bandbeitenbedarf bei der Sprachübertragung
Abbildung 3.16: Struktur eines IP-Telefonie-Pakets
Wie leicht zu erkennen ist, wird allein auf IP-Paket-Ebene, in diesem Fall, bereits die
dreifache Bitrate benötigt. Bei der Übertragung über Ethernet oder ATM steigt diese
nochmals an (siehe [49], Seite 100, allerdings mit fehlerhafter Rechnung).
Der Codec ITU-T G.711 mit einer Nettobitrate von 64 kbit/s benötigt allein auf Schicht
3 eine Bruttobitrate von bis zu 84 kbit/s (bei 20ms Paketierungszeit rund 80 kbit/s).
([32],[35])
Eine Möglichkeit die benötigte (Brutto-)Bitrate zu senken, ist der Einsatz von ”cRTP”
(compressed RTP). Dabei wird der Header von 40 Byte pro (IP-)Paket auf 2 bzw.
4 Byte pro (IP-)Paket reduziert. Ausgenutzt wird dabei, dass sich, auf die Dauer einer Übertragung bezogen, der Header nur geringfügig ändert. Am Anfang und in bestimmten Abständen werden Pakete mit einem unkomprimierten Header übertragen,
die Pakete dazwischen haben einen komprimierten Header. ([12], Kapitel 9.2.2)
3 VoIP
68
3.4.5 Qualitative Bewertung der Codecs
Wie wird aber die Sprachqualität des, durch den Codec erzeugten, digitalen Sprachsignals ermittelt und bewertet?
Für die subjektive Bewertung der Sprachqualität bei einer Übertragung von Sprache
wird das MOS-Verfahren eingesetzt. MOS steht dabei für ”Mean Opinion Score”, das
Ergebnis des Verfahrens ist der MOS-Wert eines Codecs.
Der MOS-Wert ist ein dimensionsloser Wert zwischen ”1” (mangelhafte Sprachqualität)
und ”5” (exzellente Sprachqualität, vom Original nicht zu unterscheiden). Eine genaue
Differenzierung der einzelnen Werte ist in Tabelle 3.3 aufgezeigt!
Wert
Qualität
5
exzellent
4
3
2
1
Beschreibung
Es ist keine Anstrengung nötig, um die Sprache zu
verstehen.
gut
Durch aufmerksames Hören kann die Sprache ohne
Anstrengung wahrgenommen werden.
ordentlich Die Sprache kann mit leichter Anstrengung wahrgenommen werden.
mäßig
Es bedarf großer Konzentration und Anstrengung,
um die übermittelte Sprache zu verstehen.
mangelhaft Trotz großer Anstrengung kann man sich nicht verständigen.
Tabelle 3.3: MOS-Qualitätsstufen
Zur Ermittelung des MOS-Wertes wird mit vielen Testpersonen ein definierter Hörtest
durchgeführt, bei dem die Sprachqualität von der Testperson bewertet wird. Anschließend werden die einzelnen Bewertungen gewichtet und die statistischen Ergebnisse ermittelt. Die wichtigsten Kriterien dabei sind Verzögerungszeit (Delays), Bitfehlerraten
(Knackgeräusche), Echos und Jitter (Genauigkeitsschwankungen bei der Übertragung
von digitalen Signalen). Der MOS der einzelnen Codecs ist selten eindeutig. Bei der
Recherche in verschiedenen Quellen können abweichende Angaben auftreten!
3.4.6 Gegenüberstellung der Audiocodecs
In Tabelle (3.4) sind einige der erwähnten Audiocodecs vergleichend gegenübergestellt.
Für weiterführende Informationen bietet www.vocal.com eine gute Anlaufstelle.
Wie in Tabelle (3.4) leicht zu sehen ist, nimmt die benötigte Datenrate der Codecs im
Vergleich zu G.711 ab, allerdings steigt die Komplexität der Codecs.
D.h. dass Elemente von VoIP-Netzen, wie Software-PBXs (”Asterisk”) oder Gateways
3 VoIP
69
Codec
Bitrate
(in
kbit/s)
Übertragener
Frequenzbereich
MOS
Komplexität
(in MIPS)
Delay
(in ms)
G.711
G.721
G.722
G.723.1
64
32
64
6,4
5,3
16-40
16
6,4-11,8
4,75 - 13
2-44
300-3400Hz
300-3400Hz
0-7000Hz
300-3400Hz
300-3400Hz
300-3400Hz
300-3400Hz
300-3400Hz
4,4
4,2
4,5
3,9
3,7
3,3-4,2
3,6
3,9
3,7
3,6-3,8
0
0
10
>30
>30
10
15
25-30
1,5
37,5
37,5
<1
0,625
25
G.726
G.728
G.729
GSM
Speex
variabel
Tabelle 3.4: Vergleich der Audiocodecs ([53])
einen relativen großen Aufwand erbringen müssen, die entsprechenden Datenströme
umzukodieren.
Beispielsweise wenn zwei Gesprächsteilnehmer unterschiedliche Sprachcodecs verwenden, kann eine PBX wie ”Asterisk” die Pakete nicht einfach ”durchreichen”, sondern
muss diese erst ”umkodieren”.
Dieser Aspekt muss bei der Planung eines VoIP-Netzes unbedingt beachtet werden!
3.5 Dienste in VoIP
Im herkömmlichen Telefonnetz hat sich eine Vielzahl von Diensten etabliert. Wie sieht
es aber dazu im Vergleich dazu, in VoIP-Netzen aus?
Eine ausführliche Abhandlung dazu, ist im Kapitel 4.2 zu finden.
3 VoIP
70
3.6 Phänomen ”Skype”
”Skype” ist eine kostenlos erhältliche Software für VoIP-Kommunikation, Instant-Messaging aber auch Videotelefonie. Entwickelt wurde ”Skype” von Niklas Zennström und
Janus Friis, 2 Entwickler welche bereits für die Entwicklung der Tauschbörse Kazaa
mitverantwortlich waren. Version 1.0 der Software wurde im Juli 2003 releast.
Eigentlich ist ”Skype” nur ein klassischer VoIP-Provider, allerdings existieren teils gravierende Unterschiede zu anderen Anbietern:
Klassische Anbieter wie ”AOL”, ”MSN”, ”ICQ” unterhalten leistungsfähige Rechenzentren, in denen die Userdaten gespeichert werden. Wenn ein Anwender sich mit der
entsprechenden Client-Software anmeldet, hinterlegt er seine dynamische IP-Adresse
im Rechenzentrum. Über das Rechenzentrum erfahren andere Anwender, wer aus ihrer
Kontaktliste gerade online ist, ohne die IP-Adressen zu kennen.
Ein Problem hierbei ist, das die VoIP-Verbindung, welche ja zwischen den PCs der Anwender abgewickelt wird, durch die NAT-Problematik und Firewalls häufig erschwert,
wenn nicht sogar unmöglich gemacht wird.
”Skype” hingegen verzichtet auf große Rechenzentren aufgrund des Einsatzes der Peerto-Peer-Technologie, d.h. alle involvierten Rechner stellen einen Teil ihrer Ressourcen
”Skype” zur Verfügung - Je mehr Nutzer online sind, desto mehr Ressourcen stehen
insgesamt zur Verfügung.
Die Netzstruktur ist also relativ dezentral; nur Authentifizierung, Abrechnung und
Gatewayfunktionalitäten werden über zentrale Rechner abgewickelt. Die Nutzer-zuNutzer-Kommunikation findet teilweise über andere Nutzer statt (Peer-to-Peer-Prinzip).
Insgesamt existieren im ”Skype”-Netz 3 verschiedene Komponenten:
• Ordinary Hosts
Jeder normale ”Skype”-Nutzer ist ein Ordinary Host. Mit entsprechenden Ressourcen, kann ein ”Ordinary Host” zu einem ”Supernode” ”aufsteigen”.
• Supernodes
”Supernodes” sind leistungsfähige Rechner und die übergeordnete Instanz der
”Ordinary Hosts”. Die Anmeldelisten (Wer ist gerade angemeldet?, keine Authentifizierung!) der Nutzer werden auf den, untereinander mit geringer Latenz
verbundenen, ”Supernodes” gespeichert. Alle ”Supernodes” haben also Kenntnis
von allen verfügbaren Nutzern und Ressourcen und sorgen aufgrund ihrer Menge
für eine Lastverteilung.
3 VoIP
71
• Login Server
Um sich am Netzwerk anzumelden, muss ein ”Ordinary Host” sich mit einem
”Supernode” verbinden und sich zusätzlich im Netzwerk authentifizieren. Diese
Registrierung erfolgt direkt am ”Login Server”, via Benutzername und Passwort.
Der ”Login Server” speichert Benutzername und Passwort in einer Datenbank
und sorgt somit für die Einmaligkeit der Benutzernamen.
Abbildung 3.17: Aufbau des ”Skype”-Netzwerkes ([3])
NAT-Problematik
Die ”Skype”-Software arbeitet problemlos hinter Firewalls und NAT-Routern, da in
jedem ”Skype”-Knoten eine Variante des STUN-Protokolls ([3]) eingesetzt wird. Für
den Verbindungsaufbau wird ein zufälliger Port genutzt, falls es dabei zu Problemen
kommt wird auf die Ports 80 (HTTP) und 443 (HTTPS) ausgewichen.
Sicherheit
Jede Datenübertragung (Anruf oder Instant Message) wird bei ”Skype” verschlüsselt
übertragen, wobei das AES-Verfahren (Advanced Encryption Standard) mit einem 256Bit Schlüssel zum Einsatz kommt. Jeder Schlüssel wiederum wird mit 1.536 bis 2.048
Bit RSA übertragen. RSA ist ein (asymmetrisches) Verschlüsselungssystem und wird
nach seinen Erfindern Ronald L. Rivest, Adi Shamir und Leonard Adleman benannt.
Sprachübertragung
Die Sprachqualität bei ”Skype” ist unter anderem anhängig vom verwendeten Sprachcodec. Konkrete Aussagen von ”Skype” selbst, lassen sich nicht direkt finden. Verschiedene Quellen sprechen davon, dass ”iLBC” und ”iSAC” eingesetzt werden ([3]). Anders
lautenden Quellen kommen die Codecs ”SVOPC”, ”AMR-WB”, ”G.729” und ”G.711”
zum Einsatz (siehe [79], allerdings nicht durch Quellen belegt).
3 VoIP
72
”Skype” selber spricht davon, dass sich die Software automatisch den besten Codec
anhand der Netzwerkverbindung auswählt und circa 3-16 kByte/s benötigt (Quelle:
Skype FAQ).
Trotz dieser Vorteile ist ”Skype” nicht unumstritten. Es ist ein proprietäres System
und ist mit anderen Standards wie SIP oder H.323 nicht kompatibel. Proprietäre System sind eigenständige Systeme, welche sich nicht an (offene) Standards halten und
sich auch sonst kaum in die Karten schauen lassen. Deswegen wird vom Einsatz von
”Skype” in Unternehmen abgeraten (Quelle: Bundesverband Telekommunikation e.V.).
Weiterführende Informationen zu ”Skype” sind hier zu finden:
www.skype.de, [48], [3], [79]
3 VoIP
73
3.7 Problematik SPIT
Die Abkürzung SPIT bedeutet ”Spam over Internet Telephony” und ist die Bezeichnung
für unerwünschte Werbeanrufe über die Internettelefonie. Bekannt ist Spam bereits aus
dem Bereich E-Mail, wo massenhaft und unerwünscht E-Mails, meist zu Werbezwecken, versandt werden. Die E-Mail-Adressen der Nutzer werden durch Suchagenten im
Internet gesammelt oder einfach durch den Spammer (Versender von Spam) gekauft.
Im Bereich Telefonie hielten sich SPAM-Anrufe meist in Grenzen. Dies aus einem ganz
einfachen Grund: weil sie dem Anrufer Kosten verursachen.
Dies ändert sich mit der Einführung von VoIP: Spam-Anrufe können kostengünstig im
großen Stil durchgeführt werden.
Möglichkeiten zur Absicherung gegen SPIT ([47]):
• Filterung
Klassifizieren von Anrufen anhand Ihrer Kennung. Rufnummern von SPIT-Anrufen
können auf eine Blacklist gesetzt werden.
• Challenges (vgl. 9.3.6.8)
Schutz vor automatischen Dialern durch Stellen einer zu lösenden Aufgabe am
Telefon. Beispielsweise einer einfachen Additionsaufgabe.
• Kombinationen:
Zur Unterscheidung von eingehenden Anrufen kann eine Black- und eine Whitelist eingeführt werden. Nummern, die auf der Blacklist stehen, werden abgewiesen. Auf der Whitelist stehenden Anrufern (und auch alle anderen unbekannten
Anrufer) kann eine Challenge gestellt werden.
• Authentizität
Eine weitere Maßnahme gegen SPIT ist eine Koppelung der Genehmigung von
abgehenden Anrufen an eine vorherige Authentifizierung der Teilnehmer. Provider können dadurch Anrufe in das eigene Netz, durch nicht authentifizierte
Anrufer, verweigern.
• Sichern von Adressen und Rufnummern:
Ähnlich wie bei E-Mails sollten VoIP-Adressen nicht auf Internetseiten ungesichert angegeben werden. Ansonsten können diese durch Address-Bots leicht
ausgelesen und für SPIT-Anrufe verwendet werden.
74
In den Kapiteln 2 und 3 wurden die grundlegenden Funktionsweisen des öffentlichen
Telefonnetzes und von VoIP-Netzen beschrieben.
Grundsätzlich haben beide Netztypen einen sehr ähnlichen Aufbau (siehe 2.1 und 3.1):
Es existieren Nutzer mit Endgeräten, welche an Telefonanlagen angeschlossen sind.
Diese Telefonanlagen ermöglichen mit Hilfe eines Vermittlungsnetzes Gespräche zu anderen Teilnehmern. In öffentlichen Netzen besteht dieses Vermittlungsnetz aus den
Vermittlungsstellen, in VoIP-Netzen besteht es aus einer großen Anzahl von Routern
(Internet!).
Technisch gesehen, arbeiten beide Netztypen allerdings total verschieden. Während
die öffentlichen Telefonnetze leitungsvermittelt arbeiten, basieren VoIP-Netze auf einer paketvermittelten Übertragung der Sprache!
In diesem Kapitel werden beide Netze vergleichend gegenübergestellt und anhand wichtiger Punkte miteinander verglichen.
Auf folgenden Aspekten liegt dabei Fokus, diese bilden somit die Basis für die Gegenüberstellung der öffentlichen Telefonnetze mit VoIP-Netzen:
• Signalisierung und Datenübertragung (4.1)
• Dienste (4.2)
• Sicherheit (4.3)
• Quality of Service (4.4)
• Management und Wartung (4.5)
• Adressierung (4.6)
• Notrufe (4.7)
75
4.1 Signalisierung und Sprachdatenübertragung
Um eine Nachrichtenübertragung zwischen 2 Teilnehmern eines Netzes zu ermöglichen,
muss dem Netz dies durch den Initiator der Kommunikationsverbindung mitgeteilt
werden. Mit Hilfe dieser Informationen kann das Netz dann die gewünschte Verbindung
herstellen.
Jede Kommunikation in Telefonnetzen kann allgemein in 3 Stufen gegliedert werden
([67], S.9):
• Verbindungsaufbau
Auswahl des Kommunikationspartners, Feststellen der Kommunikationsbereitschaft, Herstellen der Verbindung
• Nachrichtenübertragung
Informationsaustausch zwischen den Teilnehmern
• Verbindungsabbau
Beenden der Verbindung und Freigeben von Ressourcen und Kanälen
Der Informationsaustausch für die Steuerung einer Nachrichtenverbindung in einem
Netz wird als Signalisierung, früher auch als Zeichengabeverfahren bezeichnet. Die
Signalisierungsinformationen für die Steuerung der Verbindung müssen zwischen allen
beteiligten Elementen (Endgeräte, Netzelemente) ausgetauscht werden. Dabei wird
grundsätzlich zwischen 2 Arten der Signalisierung unterschieden:
• Inband-Signalisierung
Bei diesem Verfahren werden die Signalisierungsinformationen zusammen mit
den Nutzinformationen in einem Kanal übertragen.
Bekanntes Beispiel ist das Mehrfrequenzwahlverfahren in der analogen Telefontechnik.
• Outband-Signalisierung (Out-of-Band-Signalisierung)
Die Signalisierungsinformationen werden in einem eigenen Kanal, welcher ausschließlich für die Signalisierung bereitsteht, übertragen. Die eigentliche Informationsübertragung findet über einen seperaten Kanal statt.
Diese Art der Signalisierung kommt bei ISDN zur Anwendung.
76
Beispiele für Signalisierungsprotokolle sind unter anderem ([90]):
• Signalisierungsprotokolle für Endgeräte
– Mehrfrequenzwahlverfahren (bei analogen Telefonen heute allgemein üblich)
– Impulswahlverfahren (älteres Signalisierungsprotokoll für analoge Telefone)
– Q.931 des DSS1 (bei ISDN-Telefonen und -Telefonanlagen heute allgemein
üblich)
• Signalisierungsprotokolle für Telefonnetze
– Signalling System No. 7 (SS7) (heute fast ohne Ausnahme verwendet)
• Signalisierungsprotokolle für paketvermittelte Verfahren
– SIGTRAN (Signalling System No. 7 over IP)
– Session Initiation Protocol, kurz SIP (siehe 3.2.2.2)
– Teile des H.323-Protokolls (siehe 3.2.2.1)
– Megaco (siehe 3.2.3.1)
Weiterführende Informationen zum Thema Signalisierung: [12], S.28ff
PSTN-Signalisierung: [53], S.79ff
Nach dem Verbindungsaufbau (mit Hilfe der Signalisierung) kann die eigentliche Nutzdaten-, hier Sprachdatenübertragung erfolgen.
Signalisierungs- und Sprachdatenübertragung im Vergleich zeigen folgende Ausführungen:
Analoge Telefonnetze
Das analoge Telefonnetz ist mittlerweile durch ein digitales Netz abgelöst. Die Informationen werden vollständig ”analog”, also wertekontinuierlich übertragen.
• Signalisierung
Inband-Signalisierung
Beispielsweise: MFV (Mehrfrequenzwahlverfahren) und DTMF (Dual Tone Multiple Frequency)
• Sprachdatenübertragung
Analoge Sprachdatenübertragung im Frequenzbereich von 300-3400 Hz.
77
Digitale Telefonnetze (ISDN)
• Signalisierung
Out-of-Band-Signalisierung
Im ISDN existiert für die Signalisierung der D-Kanal. Er ist unabhängig von den
beiden B-Kanälen und verfügt bei Basisanschlüssen über eine Datenrate von 16
kbit/s, bei Primärmultiplexanschlüssen über 64 kbit/s.
Für die Übertragung der Sprache stehen 2 Sprachkanäle (B-Kanäle) zur Verfügung. Im hierzulande eingesetzten Euro-ISDN kommt das PCM-Verfahren zum
Einsatz (A-law-Kennlinie, ITU-T G.711 (9.1.1), 64 kbit/s). In Amerika, wo das
PCM-Verfahren auf der µ-law-Kennlinie basiert, steht nur eine Datenrate von 56
kbit/s zur Verfügung.
VoIP-Netze
• Signalisierung
Out-of-Band-Signalisierung
Bei auf SIP-basierenden VoIP-Netzen wird die Signalisierung komplett durch
das SIP-Protokoll (3.2.2.2) umgesetzt. In auf H.323-basierenden Netzen (3.2.2.1)
übernimmt das Protokoll H.225 (Call Control) die Signalisierung.
Die Übertragung der Sprachpakete wird durch das RTP-Protokoll realisiert. Informationen zu Erzeugung, Transport und Datenrate der Sprachdatenströme sind
in Kapitel 3 zu finden.
Fazit
Heutige Telefonnetze arbeiten durchgängig digital (ISDN) und haben die analogen Telefonnetze verdrängt. Für die Signalisierung wurde ein eigener Kanal etabliert, aber
auch die Sprachqualität hat sich, im Vergleich zum vorherigen analogen Netz, deutlich
verbessert. VoIP basiert grundsätzlich auch auf einer Trennung von Sprach- und Nutzdaten.
Grundlegend arbeiten herkömmliche und VoIP-Netze hinsichtlich Signalisierung und
Nutzdatenübertragung nach ähnlichen Prinzipien. Es existieren jeweils spezifische Protokolle für beide Netztypen, VoIP hat allerdings keine so strikten Vorgaben an das
Format der Nutzdaten.
78
4.2 Dienste
Über Kommunikationsnetze werden Informationen jeglicher Art übertragen, wobei historische Netze meist nur in der Lage waren, eine bestimmte Art Information zu übertragen: Ein Dienst - Ein Netz!
Diese Vielfalt an Netzen für jeweilige Dienste wurde durch eine Integration von Netzen,
Schnittstellen und Engeräten auf Netzebene in ein Netz aufgelöst - ISDN. Gegenwärtige Trends gehen eher in die Integration, von neuen Diensten, in der Dienst- und nicht
in der Netzebene. Das Netz übernimmt dabei nur noch reine Transportaufgaben! (vgl.
2.2)
Der Dienstbegriff ist wie folgt definiert:
Als Dienst bezeichnet man in der Telekommunikation die Fähigkeit eines Telekommunikationsnetzes Informationen einer bestimmten Art zu übertragen und zu vermitteln
([67]).
Andere Quellen definieren eine Telekommunikationsdienstleistung wie folgt:
Telekommunikationsdienstleistungen sind das gewerbliche Angebot von Telekommunikation einschließlich des Angebots von Übertragungswegen für Dritte. ([74])
4.2.1 Einteilung von Diensten
Mit dem Begriff ”Dienst” sind verschiedene Komponenten verknüpft. Abbildung 4.1
strukturiert die Aufteilung des Dienstbegriffes.
Abbildung 4.1: Struktur des Dienstbegriffes ([74])
79
Basisdienste
Basisdienste übernehmen für den Nutzer den Informationstransport, zwischen zwei
geographisch getrennten Punkten, in definierter Weise.
In der ITU-Empfehlung I.210 erfolgt eine wird bei den Basisdiensten zwischen ”Telediensten” und ”Übermittlungsdiensten” unterschieden. ([74], S.3-4)
Abbildung 4.2: Definition von Tele- und Übermittlungsdiensten ([17],S.314)
Übermittlungsdienste / Bearer Services
Übermittlungsdienste oder auch Bearer Services reichen nur vom Netzzugangspunkt
des Senders bis zum jeweiligen Netzzugangspunktes des Endgeräts des Empfängers und
sind in den Schichten 1-3 des OSI-Referenzmodells angesiedelt. Ihre Hauptaufgabe ist
die Signalübermittlung und die code- und anwendungsunabhängigen Informationsübertragung.
Sie werden in leitungs- und in paketvermittelte Übermittlungsdienste mit Fest- oder
Wählverbindungen unterteilt ([80], [17], [74]):
• leitungsvermittelt:
– 64 kbit/s-Übermittlungsdienst
– 3,1 kHz-a/b-Übermittlungsdienst
– Sprachübermittlung
• paketvermittelt
– Packet Mode im B-Kanal
– Packet Mode im D-Kanal beim Basisanschluß
80
Teledienste / Teleservices
Neben den Übermittlungsdiensten gibt es die Teledienste oder Teleservices, welche auf
die Übermittlungsdienste in den unteren 3 Schichten des ISO/OSI-Referenzmodells
aufsetzen und Anwendungen in den Schichten 4-7 realisieren. Sie definieren Dienste
für die Ende-zu-Ende-Kommunikation und stellen, durch festgelegte Codierung und
Struktur der Nutzinformationen, den Informationsaustausch zwischen entsprechenden
Endgeräten sicher ([17]).
Typische Teledienste sind beispielsweise die Telefonie (Telefondienst) und der Telefaxdienst.
Ergänzende Dienste
Neben den Basisdiensten, gibt es ergänzende Dienste, welche eingeführt wurden, um
die Nutzung von Basisdiensten zu verbessern und zu vereinfachen. Darüber hinaus helfen ergänzende Dienste den gesamten Kommunikationsprozess effektiver zu gestalten.
Ohne Basisdienste gibt es auch keine ergänzenden Dienste.
Eine ausführliche Auflistung von Diensten (u.a. spezifiziert von ETSI und ITU) ist
im Anhang zu finden (9.2). Dabei erfolgt eine Unterteilung in ([74]):
• Ergänzende Dienste auf Basis von Leistungsmerkmalen des öffentlichen Netzes
(9.2.1)
• Ergänzende Dienste auf Basis von Leistungsmerkmalen des Intelligenten Netzes
(9.2.2)
• Ergänzende Dienste auf Basis der PBX (9.2.3)
Eine Auflistung von ergänzenden Diensten für die Telefonie in Abschnitt 4.2.2.
Mehrwertdienste
Mehrwertdienste sind Dienste, die über reine Transport- und Vermittlungsfunktionalitäten hinaus gehen.
Ein Mehrwertdienst ist zum Beispiel der indirekte Nachrichtenaustausch über Zwischenspeicher (E-Mail).
4.2.2 Definieren von zu betrachtenden Diensten
Wie in Abschnitt 9.2 sehr leicht zu erkennen ist, sind für den Dienst ”Telefonie” im
PSTN unzählige Dienste definiert und spezifiziert! Allerdings ist zu bezweifeln, dass
81
diese überhaupt alle, gleich häufig genutzt werden!
Im Rahmen der vergleichenden Untersuchung von Dienstmerkmalen im öffentlichen
Telefonnetz mit denen in VoIP-Netzen, wird eine Auswahl von Diensten getroffen,
diese in Dienstgruppen unterteilt und anschließend hinsichtlich ihrer Umsetzbarkeit in
VoIP-Netzen verglichen.
Folgende Auswahl von Dienstgruppen spielt, im Rahmen dieses Vergleichs, eine Rolle:
• Rufnummernidentifizierung (4.2.2.1)
• Rufumlenkung (4.2.2.2)
• Dienste beim Verbindungsaufbau (4.2.2.3)
• Konferenzdienste (4.2.2.4)
• Gebührendienste (4.2.2.5)
• Dienste für Interessensgruppen (4.2.2.6)
• Diensteeinschränkungen (4.2.2.7)
• Dienste von Privatanlagen (4.2.2.8)
4.2.2.1 Dienstgruppe ”Rufnummernidentifizierung”
Dienste innerhalb der Gruppe ”Rufnummernidentifizierung” bieten Nutzern Zusatzinformationen an, wenn diese Gespräche führen oder empfangen.
Dienste dieser Gruppe sind:
• Übermittlung der Rufnummer des Anrufers zum gerufenen Endgerät (CLIP)
• Unterdrückung der Rufnummernübertragung des Anrufers zum gerufenen Teilnehmer (CLIR)
• Mehrfachrufnummer (MSN)
Ein Anschluss ist unter mehreren Rufnummern erreichbar
• Identifizierung böswilliger Anrufer (MCID)
..anhand ihrer Rufnummer. Ggf. Rückverfolgung durch die Polizei
82
4.2.2.2 Dienstgruppe ”Rufumlenkung”
Mittels Diensten aus der Gruppe ”Rufumlenkung” ist es Teilnehmern möglich, ankommende Verbindungen unter verschiedenen Bedingungen umzuleiten. Dienste dieser
Gruppe sind:
• Anrufweiterleitung/Transfer (CD)
ermöglicht das Weiterleiten eines Gesprächs, nachdem es angenommen wurde
• Anrufweiterschaltung bei Besetzt (CFB)
Ist der gewählte Anschluss besetzt, wird der Anruf an eine, zuvor definierte,
Rufnummer weitergeleitet
• Anrufweiterschaltung bei Nichtmelden (CFNR)
Wird an einem Anschluss der Teilnehmer nicht erreicht, wird der Anruf auf eine,
vorher definierte, Rufnummer weitergeleitet
• Sofortige Anrufweiterschaltung (CFU)
Sofortige Umleitung eines eingehenden Anrufs an einen anderen,vorher definierten, Anschluss
• Anrufumlenkungen zu Ansagen
4.2.2.3 Dienstgruppe ”Dienste beim Verbindungsaufbau”
• Anklopfen (CW)
• Halten, Makeln
• selektive Anrufweiterschaltung anhand der Rufnummer
• Automatischer Rückruf bei Besetzt (CCBS)
Dieses Dienstmerkmal ist eines der komplexestens Merkmale im ISDN. Ein rufender Teilnehmer, der auf einen besetzten Teilnehmeranschluss trifft, kann einen
automatischen, vom Netz initiierten Rückruf veranlassen, sobald der besetzte
Teilnehmer wieder frei ist.
• Automatischer Rückruf bei Nichtmelden (CCNR)
Ein rufender Teilnehmer, der einen Teilnehmer nicht erreicht, kann sich automatischen vom Netz eine Benachrichtigung zukommen lassen, sobald der nicht
erreichte Teilnehmer wieder ein Gespräch führt.
83
• Parallelruf
Signalisiert einen ankommenden Anruf an mehreren Endgeräten, beispielsweise
an allen freien Mitarbeitern eines Call-Centers
4.2.2.4 Dienstgruppe ”Konferenzdienste”
Konferenzdienste bieten Möglichkeiten mit mehr als einem Gesprächspartner zu kommunizieren!
• Dreierkonferenz (3PTY)
• Konferenzen mit mehr als 3 Teilnehmern (CONF)
4.2.2.5 Dienstgruppe ”Gebührendienste”
Gebührendienste dienen der Abrechnung von Gesprächen.
• Gebührenanzeige (AOC)
• Einzelgebührennachweis
• R-Gespräche (FreePhone)
4.2.2.6 Dienstgruppe ”Interessensgruppen”
Diese Gruppe beinhaltet Dienstmerkmale für Gruppenkommunikation.
• Geschlossene Benutzergruppen
Mittels einer geschlossenen Benutzergruppe können alle Mitarbeiter einer Abteilung (beispielsweise der Buchhaltung) unter einer Rufnummer adressiert werden.
Alle Telefone klingeln, bis ein Mitarbeiter das Gespräch annimmt.
• Anrufübernahme (”Pick Up”-Gruppen)
Mitglieder einer Gruppe können Gespräche, für andere Teilnehmer dieser Gruppe,
auf Wunsch an ihrem Apparat entgegennehmen. Beispielsweise innerhalb eines
Büros.
4.2.2.7 Dienstgruppe ”Diensteeinschränkungen”
Definieren von Regeln für abgehende und ankommende Gespräche lassen sich mit
Dienstmerkmalen dieser Gruppe definieren.
84
• Blacklist
Damit kann auf ankommende Gespräche, anhand ihrer Rufnummer, unterschiedlich reagiert werden (zum Beispiel Umleiten oder Abweisen der Gespräche)
• Einschränkungen des abgehenden Verkehrs (Service Restriction in the outgoing
direction)
4.2.2.8 Dienstgruppe ”Dienste von Privatanlagen”
Private TK-Anlage bieten eine Reihe von Zusatzdiensten, welche über Funktionen und
Dienste des öffentlichen Netzes hinaus gehen:
• Sammelanschlüsse (Sammelrufnummern)
vgl. ”Geschlossene Benutzergruppen”
• ”Music on Hold” (MOH)
• Kurzwahl (Abbreviated Dialling)
Abbilden einer Rufnummer auf einer ein- oder zweistelligen Kurzwahlnummer.
Individuelle oder Gemeinsame Kurzwahllisten
• Durchwahl (Direct Dialling-IN, DDI)
• Rufnummernportabilität
• Voicemail
4.2.3 Umsetzung der definierten Dienste in VoIP
In Abschnitt 4.2.2 wurde eine Reihe verschiedenster Dienstmerkmale ausgewählt, welche in öffentlichen Telefonnetzen und herkömmlichen privaten TK-Netzen bereits realisiert sind.
Wie sieht es aber mit der Umsetzung/Umsetzbarkeit in VoIP-Netzen aus?
Hinweis:
Bei der Prüfung der Umsetzbarkeit der einzelnen Dienste, wurde die primär die Umsetzung in ”Asterisk” überprüft. Eine Auflistung der unterstützten Feature in ”Asterisk”
sind hier zu finden:
http://www.asterisk.org/support/features
85
Dienstmerkmal
Umsetzbar?
”Rufnummernidentifizierung”
- Rufnummernübertragung (CLIP)
- Unterdrücken der Rufnummernübertragung (CLIR)
- Mehrfachrufnummer (MSN)
- Identifizierung böswilliger Anrufer (MCID)
”Rufumlenkung”
- Anrufweiterleitung/Transfer (CD)
- Anrufweiterschaltung bei Besetzt (CFB)
- Anrufweiterschaltung bei Nichtmelden (CFNR)
- Sofortige Anrufweiterschaltung (CFU)
- Umlenkung zu Ansagen
”Dienste beim Verbindungsaufbau”
- CW, Halten, Makeln
- selektive Anrufweiterschaltung
- CCBS,CCNR
- Parallelruf
”Konferenzdienste”
- Dreierkonferenz (3PTY)
- Konferenzen (CONF)
”Gebührendienste”
- Gebührenanzeige (AOC)
- Einzelgebührennachweis
- R-Gespräche (FreePhone)
”Interessensgruppen”
- Geschlossene Benutzergruppen
- Anrufübernahme (”Pick Up”-Gruppen)
”Diensteeinschränkungen”
- Blacklist
- Einschränkungen des abgehenden Verkehrs
”Dienste von Privatanlagen”
- Sammelanschlüsse (Sammelrufnummern)
- ”Music on Hold” (MOH)
- Durchwahl (Direct Dialling-IN, DDI)
- Kurzwahl (AD)
- Rufnummernportabilität
- Voicemail
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
*
*
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Tabelle 4.1: Umsetzbarkeit von Diensten in VoIP
86
Dienstgruppe ”Rufnummernidentifizierung”
Rufnummernübertragung (CLIP)
Die Rufnummer wird bei ”Asterisk” beispielsweise standardmässig übertragen.
Unterdrücken der Rufnummernübertragung (CLIR)
Die Unterdrückung der Rufnummernübertragung lässt sich in ”Asterisk” problemlos
realisieren:
http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+SetCallerPres
Mehrfachrufnummer (MSN)
Problemlose Realisierung in VoIP. Einem Anschluss lassen sich bei ”Asterisk” mehrere
Rufnummern zuweisen (Anpassen des Wählplans).
Identifizierung böswilliger Anrufer (MCID)
Die Identifizierung von (böswilligen) Anrufern lässt sich in VoIP einfach realisieren,
da die IP-Adresse des Anrufers mit übertragen wird. Anhand dieser kann der Anrufer
identifiziert werden. Problematisch wird die Identifizierung, wenn das Gespräch über
verschiedene Server (Proxys, andere VoIP-Server) geroutet wurde.
Dienstgruppe ”Rufumlenkung”
Anrufweiterleitung/Tranfer (CD)
Problemlose Umsetzung in VoIP-Netzen. Allerdings muss beachtet werden, dass diese
Funktion in den Endgeräten implementiert ist. Die Softphones ”X-Lite” und ”Wengophone” unterstützen dieses Feature nicht. Softphones wie ”Eyebeam” und ”SJPhone”
(www.sjlabs.com) hingegen schon.
Anrufweiterschaltung bei Besetzt (CFB)
Problemlose Umsetzung in VoIP.
Anrufweiterschaltung bei Nichtmelden (CFNR)
Beispielsweise durch das Softphone ”SJPhone” (www.sjlabs.com).
Sofortige Anrufweiterschaltung (CFU)
Beispielsweise durch das Softphone ”SJPhone” (www.sjlabs.com).
Umlenkung zu Ansagen
Eine Umlenkung zu einer Ansage ist technisch nichts anderes, als die Umleitung zu
einer anderen Rufnummer. Daher ist dieses Dienstmerkmal in VoIP-Netzen möglich.
87
Dienstgruppe ”Dienste beim Verbindungsaufbau”
CW, Halten, Makeln
selektive Anrufweiterschaltung
Problemlose Umsetzung in VoIP. In Asterisk kann der Wählplan so angepasst werden,
dass auf bestimmte, ankommende Rufnummern unterschiedlich reagiert wird (z.B. das
entsprechend der Rufnummer des Anrufers unterschiedlich weitergeleitet wird).
CCBS,CCNR
http://www.ip-phone-forum.de/showthread.php?t=144847
Parallelruf
Problemlose Umsetzung in VoIP. Problemlose Umsetzung in Asterisk (”Ring Groups”).
Dienstgruppe ”Konferenzdienste”
Dreierkonferenz (3PTY)
Problemlose Umsetzung in VoIP. Implementierung oft schon in Endgeräten (”Wengophone” unterstützt beispielsweise das Dienstmerkmal ”Dreierkonferenz” von sich aus)
Konferenzen (CONF)
Problemlose Umsetzung in VoIP. Realisierung in ”Asterisk” durch Konferenzräume!
Dienstgruppe ”Gebührendienste”
Gebührenanzeige (AOC) und Einzelgebührennachweis
Beim Einsatz von VoIP bietet sich eine andere Größe an, auf Basis welcher eine Tarifierung und Abrechnung von Gesprächen realisiert werden kann: die angefallene Datenmenge. Diese zu ”messen” ist nicht immer leicht, spielt in LANs eine eher untergeordnete Rolle. Viele Provider führen deshalb weiterhin eine Abrechnung auf Zeitbasis
durch. In Abhängigkeit der gewählten Rufnummer kann dem Nutzer nach einem Gespräch die Gesprächszeit und die angefallenen Kosten angezeigt werden.
Deshalb sind die Dienste ”Gebührenanzeige” und ”Einzelgebührennachweis” auch in
VoIP umsetzbar.
R-Gespräche (FreePhone)
Der Angerufene übernimmt die Gesprächskosten. Dieses Dienstmerkmal ist problemlos
in VoIP umsetzbar, allerdings muss eine entsprechende Anwendung die Erfassung und
Tarifierung der geführten Gespräche übernehmen!
Angeboten wird solch ein Freephone-Dienst von ”VoIPTalk”, einem britischen VoIPProvider.
88
www.voiptalk.org/products/0800+Freephone+VoIP+Number
Dienstgruppe ”Interessensgruppen”
Geschlossene Benutzergruppen
Benutzergruppen können in VoIP-Netzen leicht implementiert werden.
Anrufübernahme (”Pick Up”-Gruppen)
”Pick-Up” lassen sich auch problemlos einführen. In ”Asterisk” beispielsweise können
Nutzer in ihrem Nutzerprofil einer ”Pick-Up”-Gruppe zugeordnet werden.
Dienstgruppe ”Diensteeinschränkungen”
Blacklist
Problemlose Umsetzung in VoIP-Netzen. ”Asterisk”bietet von Haus aus eine ”Blacklist”Funktion an.
Einschränkungen des abgehenden Verkehrs
Problemlose Umsetzung in VoIP-Netzen.
Dienstgruppe ”Dienste von Privatanlagen”
Sammelanschlüsse (Sammelrufnummern)
Problemlose Umsetzung. Definieren von Ringgroups und Gruppendurchwahlen!
”Music on Hold” (MOH)
Problemlose Umsetzung möglich. In ”Asterisk” können verschiedene MoH-Gruppen
definiert werden, welche anschließend einzelnen Extensions und Nutzergruppen zugewiesen werden können. Jede Extension kann problemlos über ihre eigene MoH-Musik
verfügen.
Durchwahl (Direct Dialling-IN (DDI) und Kurzwahl (AD)
Problemlose Umsetzung. Jeder Nutzer bekommt eine Durchwahl / Extension zugewiesen, über welche er erreichbar ist. Zusätzlich dazu, kann im Endgerät eine beliebige
Anzahl von persönlichen Kurzwahlnummern definiert werden.
Rufnummernportabilität
Rufnummernportabilität bedeutet, dass Nutzer ihre Rufnummer beispielsweise bei einem Umzug mitnehmen können. In VoIP-Netzen geht die Portabilität sogar noch einen
Schritt weiter: Nutzer können sich vollkommen unabhängig vom Anschluss, vom Ort
und sogar vom Endgerät in VoIP-Netze einklinken (sofern vorort Zugang zum Internet
oder LAN möglich ist). Die Einrichtung von Heimarbeitsplätzen stellt absolut keine
Herausforderung für VoIP-Netze und die Netz-Administratoren dar!
Voicemail
”Voicemail” ist ein Dienstmerkmal, welches sich in VoIP-Netzes sehr leicht implemen-
89
tieren lässt. Da das Netzwerk, wie der E-Mail-Dienst auch, auf Basis von IP arbeitet,
tritt kein Medienbruch auf. Das bedeutet, dass für die Realisierung dieses Dienstes kein
zusätzlicher Dienst/Dienstanbieter notwendig ist.
Die Implementierung von ”Voicemail” ist in VoIP-Netzen einfacher zu realisieren, als
in herkömmlichen Telefonnetzen.
Fazit
Beim Umstieg auf VoIP muss auf kein, aus dem herkömmlichen PSTN oder TK-Netzen,
bekanntes Dienstmerkmal verzichtet werden. War anfangs die Umsetzung einzelner
Funktionen auf proprietäre Systeme verschiedener Hersteller beschränkt, sind heute
fast alle VoIP-PBX in der Lage, jedes bekannte Dienstmerkmal zur Verfügung zu stellen. Die Software-PBX ”Asterisk” beispielsweise, bietet von Haus aus ein Menge an
unterstützter Funktionen, welche sich, entsprechende (Programmier-)Kenntnisse vorausgesetzt, nahezu unbegrenzt erweitern lassen!
Allerdings müssen die verwendeten Endgeräte in der Lage sein, mit diesen Funktionen
umzugehen.
Im Vergleich mit Diensten, welche die ”Deutsche Telekom” im öffentlichen Festnetz
anbietet (2.3), muss in VoIP-Netzen kein Abstrich gemacht werden: Alle Funktionen
lassen sich umsetzen, bei einigen bietet die Implementierung in VoIP sogar zusätzliche
Vorteile:
• T-Net-Box (Anrufbeantworter im Netz)
Der Dienst ”Voicemail” geht, im Vergleich zum normalen Anrufbeantworter, noch
einen Schritt weiter. Die auf die Mailbox gesprochenen Nachrichten werden auf
Wunsch per E-Mail zugestellt oder lassen sich bequem via Browser abrufen!
• Telefonkonferenzen
Telefonkonferenzen sind Mehrwertdienste, welche entsprechende Gebühren bei
Nutzung mit sich bringen. In VoIP lassen sich Telefonkonferenzen sehr leicht implementieren, beispielsweise durch das Schaffen von Konferenzräumen. Die Teilnehmerzahl lässt sich, in Abhängigkeit der vorhandenen Ressourcen, beliebig
skalieren. Die anfallenden Kosten sind dabei (relativ) uninteressant, vor allem in
LANs.
90
4.2.4 Telefax-Dienst
Das Wort ”Telefax” ist die Abkürzung für ”Telefacsimile” (”tele”, griechisch für weit
und ”facsimile”, lateinisch für ”naturgetreues” Abbild) und ermöglicht die Übertragung
von Dokumenten über das Telefonnetz.
Dabei werden Faxgeräte in 4 verschiedene Gruppen eingeteilt ([67]):
• Gruppe 1 (G1)
Bei einer Übertragung von 4 Zeilen pro Millimeter erfolgt die Übertragung einer
DIN-A4-Seite ohne Bandbreitenkompression innerhalb von 6 Minuten!
• Gruppe 2 (G2)
Gleiche Auflösung wie Faxgeräte aus Gruppe 1, allerdings dauert die Übertragung
(mit Redundanzreduzierung) einer DIN-A4-Seite nur circa 3 Minuten.
• Gruppe 3 (G3)
Übertragung einer DIN-A4-Seite in circa einer Minute (mit Redundanzreduzierung und Bandbreitenkompression). Die Auflösung beträgt horizontal 8 Bildpunkte pro Millimeter und 4 Bildpunkte vertikal pro Zeile. Übertragungsrate:
bis 14,4 kbit/s
• Gruppe 4 (G4)
Standard für digitales FAX, welches nur bei ISDN zum Einsatz kommt. Die
Übertragung dauert nur circa 10 Sekunden pro DIN-A4-Seite.
Übertragungsrate: 64 kbit/s
Bei allen Geräten wird die Vorlage mittels eines Scanners abgetastet und als digitale Information übertragen. Bei herkömmlichen Faxgeräten (hauptsächlich Gruppe 3)
erfolgt die Kommunikation auf Basis des Standards T.30 der ITU-T!
4.2.4.1 FoIP - Fax over IP
Die Einsatz des Telefax-Dienstes auf Basis von IP-Netzen bringt im Vergleich zum
Einsatz in herkömmlichen Telefonnetzen einige Schwierigkeiten mit sich! Beispielsweise
treten an folgenden Stellen Probleme auf:
• Laufzeitschwankungen
FAX-Modems haben große Probleme mit Laufzeitunterschieden während der
Übertragung, welche in VoIP-Netzen häufig auftreten. Bedingt durch diese Laufzeitschwankungen (Jitter) kann durch die (FAX-)Endgeräte unter anderem, keine
erfolgreiche Echounterdrückung durchgeführt werden!
91
• Paketverluste - ungesicherte Übertragung via UDP
Bei der Übertragung von Sprache, resultieren aus Paketverlusten (bis 5%) nur
sehr geringe, für das Ohr kaum wahrnehmbare Störungen. Bei ”FoIP” (Faxübertragung über Internet Protokoll) sind solche Verluste nicht akzeptabel. Die Resultate der Faxübertragungen sind sehr schlecht, oder die Verbindungen brechen
einfach ab!
• Rauschunterdrückung
Viele verwendete Audiocodecs setzen Algorithmen zum Rauschunterdrückung
ein. Wird ein Fax-Signal mittels eines solchen Codecs kodiert, zerstört der Codecs das eigentliche Fax-Signal, eine erfolgreiche Fax-Übertragung kann nicht
durchgeführt werden!
• kontinuierlicher Datenstrom
Faxgeräte benötigen einen kontinuierlichen Datenstrom, andernfalls ist das Ergebnis ein fehlerhaftes oder gar nicht angekommenes Fax beim Empfänger! In
IP-basierten Netzen kommt es aber durchaus vor, das Pakete in unterschiedlicher Reihenfolge am Empfänger ankommen.
• Signalveränderungen
Veränderungen (Störungen) im FAX-Signal können bei Einsatz eines Codecs (arbeiten verlustbehaftet) aber auch beim Umkodieren (Transkodieren) auftreten
und erschweren FoIP zusätzlich.
Für die Übertragung von Fax gibt es 2 Standards, welche sich mit der Problematik
geschäftigen: ITU-T T.37 und ITU-T T.38.
4.2.4.2 ITU-T T.37
Die Empfehlung T.37, ”Procedures for the transfer of facsimile data via store-andforward on the Internet”, wurde erstmals im Juni 1998 veröffentlicht. Sie beschreibt
die Fax-Übertragung durch ”Store-and-Forward”. Dabei wird das Fax nicht direkt, sondern per als E-Mail-Attachement im TIFF-Format (TIFF=Tagged Image File Format)
übertragen.
Da die Übertragung nicht direkt, sondern über Umwege abgewickelt wird, kann eine
Übertragung (aufgrund verschiedenster Netzwerksituationen, mangelnde Bandbreite,
niedrige Priorisierung) durchaus länger dauern.
92
4.2.4.3 ITU-T T.38
Eine anderen Weg als T.37, welches den Umweg über E-Mail nimmt, geht T.38.
T.38 definiert die Echtzeitübertragung von Fax über IP-basierte Netze wie dem Internet, erfordert aber eine aktive Onlineverbindung der beteiligten Endgeräte. Dabei
werden die Fax-Signale nicht als digitale Sprachsignale, sondern als eigenständiges Datenformat mit eigenem Protokoll (mit eigenem Paketformat und Regeln) übertragen.
Die Pakete heißen IFP (Internet Facsimilé Protocol) und werden direkt in UDP/TCP
und IP eingebettet (Kapselung). ([93])
”T.38 löst damit das Problem der VoIP-Codecs, die Qualitätsparameter Verzögerung,
Jitter und Paketverluste bleiben allerdings bestehen. Verzögerungen sind durch ausreichende Timeout-Zeiten bei der Faxübertragung kein Problem, Jitter lässt sich durch
ausreichend große Puffer auch in den Griff bekommen. Kritisch bei der EchtzeitFaxübertragung bleibt aber die Paketverlustrate. Um sich hier zu behelfen, könnten die
Datenpakete einfach doppelt gesendet werden, was dem Empfangsgerät eine Fehlerbehebung erlauben würde oder es finden ganz einfach Fehler korrigierende Maßnahmen
statt. Letzteres wäre zwar sicherer, erhöht aber die Gesamtverzögerung der Faxübertragung durch erforderlichen Handshake.”, zitiert von [93].
Fazit
Ungefähr 1,5 Prozent der europäischen Haushalten (EU-9-Staaten) verfügen über ein
Faxgerät ([93]). Zusätzlich dazu, ist der Fax-Markt relativ stabil. In Zukunft wird auch
der Fax-Dienst paketvermittelt übertragen werden - die Fax-Industrie kann die beginnende Migration zu VoIP nicht ignorieren. Die Standards T.37 und T.38 der ITU-T
geben die Richtung vor.
Allerdings haben viele Anbieter von Faxgeräten Bedenken und warten erst einmal ab.
Der Fax-Standard T.37 bietet allerdings mehr Komfort als T.38. Zum einen kann ein
PC, mit entsprechender Faxsoftware, das Faxgerät ersetzen. Faxe erreichen den Nutzer bequem als E-Mail-Attachement, womit kein Medienbruch stattfindet. Auch ist die
Realisierung via T.37 weniger zeitkritisch.
Die Implementierung eines Faxdienstes sollte auf Basis von ITU-T T.37 erfolgen!
Weiterführende Informationen zum Thema ”Fax over IP”:
[70], [93], [38], [40], [39]
93
4.3 Sicherheit
Beim Einsatz von VoIP, werden Signalisierungs- und Sprachdaten über standardisierte,
offene Datennetze übertragen. Dadurch bedingt, ergeben sich zahlreiche Bedrohungsszenarien für VoIP-Systeme.
In einer Übertragungskette bestimmt das schwächste Element die Gesamtperformance,
bzw. die in diesem Fall die Gesamtsicherheit. Eine solche Kette besteht in der VoIPKommunikation aus vielen, komplexen und vielschichtigen Einzelkomponenten. Jedes
einzelne Element muss also auf mögliche Angriffsstellen hin untersucht werden.
Basis dieses Kapitels ist die Studie ”VoIPSEC Studie zur Sicherheit von Voice over
Internet Protocol” ([33]) des ”Bundesamtes für Sicherheit in der Informationstechnik”
und eine Diplomarbeit zu diesem Thema ([51])!
4.3.1 Definieren von Sicherheitszielen
Der erste Schritt bei der Klassifizierung verschiedenster Bedrohungen in VoIP-Systemen,
ist das Definieren der gewünschten Sicherheitsziele:
Primäre Sicherheitsziele
In klassischen Kommunikationssystemen wird zwischen 3 primären Sicherheitszielen
unterschieden:
• Integrität (engl. integrity)
Schutz vor unbefugter Veränderung von Informationen
• Vertraulichkeit (engl. confidentiality)
Schutz vor unbefugter Preisgabe von Informationen
• Verfügbarkeit (engl. availability)
Schutz vor unbefugter Vorenthaltung von Informationen
Sekundäre Sicherheitsziele
Sekundäre Sicherheitsziele leiten sich von den primären Sicherheitszielen ab, sie verfeinern diese.
Beispiele für sekundäre Sicherheitsziele:
• Authentizität als ”Integrität von Nachrichteninhalt und Nachrichtenherkunft”
94
• Zurechenbarkeit (engl. accountability) als ”Verfügbarkeit und Integrität von Identitäten (Subjekten) und der von ihnen ausgeführten Aktionen”
Die definierten Sicherheitsziele sind orthogonal zueinander, allerdings bestehen Wechselwirkungen untereinander! Beispielsweise, kann der Diebstahl eines Passworts (Vertraulichkeitsverlust) zum Integritätsverlust eines Servers führen!
Des Weiteren existieren Wechselwirkungen zwischen Sicherheitszielen verschiedener
Netzwerkebenen: Eine ”sichere Kommunikation” (Anwendungsebene) über einen ”unsicheren Server” (Netzwerkebene) ist verständlicherweise nicht zu garantieren.
4.3.1.1 Integrität und Authentizität
Integrität und Authentizität stellen sicher, dass bestimmten Informationen vertraut
werden kann. Dabei lässt sich die Integrität in unzählige Sekundärziele aufspalten:
Das Beispiel ”Authentizität von Nachrichten” bedingt die Integrität der Nachricht selber, aber auch die Integrität des Senders.
Die Integrität tangiert alle involvierten Elemente der VoIP-Kommunikation:
Integrität der VoIP-Systemkomponenten
Die Integrität von Systemkomponenten ist von zentraler Bedeutung, wenn nicht sogar
das wichtigste Sicherheitsziel und wird primär durch interne Angreifer, Malware oder
indirekt durch den Vertraulichkeitsverlust von Credentials (Beglaubigungszertifikate)
wie Zugangspasswörter bedroht.
Ein Angreifer könnte nach ”erfolgreichem Übernehmen” eines Endgerätes die Verschlüsselung deaktivieren, die dadurch ungesicherten Gespräche über einen, durch den Angreifer kontrollierten Server, umleiten und somit Gespräche unter der Identität des
Benutzers initiieren. Der Benutzer merkt davon nichts!
Gravierender ist ein erfolgreicher Angriff auf Komponenten wie VoIP-Server oder Proxies. Damit würde ein Angreifer Zugriff auf eine große Anzahl von Gesprächen (Abhören der Gespräche) bekommen und diese ggf. umleiten oder manipulieren. Dem Stehlen
von Anmelde- und Authentifizierungsinformationen steht in diesem Fall auch nichts im
Wege.
Die Integrität von Systemkomponenten beginnt bei der Integrität der verwendeten
Hardware. Diese muss gegen unbefugten Zugriff gesichert werden (Zugangskontrolle),
beispielsweise durch Positionieren der verwendeten Hardware in speziell gesicherten
Serverräumen.
Darauf aufbauend muss die durchgängige Integrität der Software gewährleistet sein:
95
Beginnend beim Betriebssystem (aktueller Stand, bekannte Sicherheitslücken gefixt)
und der verwendeten Software (Software-PBX, Webserver,..). Aber auch auf Anwenderseite sollten, beispielsweise beim Einsatz von Softphones, eventuelle Schwachstellen
geschlossen werden.
Integrität und Authentizität der Sprachdaten
In Sprachdatenströmen sind durch verschiedene Komponenten (Audiokodierung durch
Codecs, Leitungs- und Kanalkodierung) bereits entsprechende Verfahren integriert,
welche die Integrität und Authentizität in einem gewissen Umfang gewährleisten.
Trotzdem ist in VoIP-Systemen ein Sicherheitsziel, die Integrität und Authentizität
der Sprachdaten zu gewährleisten. Beispielsweise sollten während eines Gesprächs die
Sprachdaten integer sein und nicht Teile früherer Gespräche sein (Metadaten ”Sendezeitpunkt der Sprachdaten eines Gespräches”).
Integrität und Authentizität der Signalisierungsdaten
Mittels Signalisierungsinformationen wird die gesamte VoIP-Kommunikation gesteuert,
sie dienen unter anderem dem Verbindungsauf- und -abbau. Gerade deshalb kommt der
Integrität und Authentizität der Signalisierung besondere Aufmerksamkeit zu. Diese
Informationen müssen fest mit Sicherheitszielen verknüpft werden!
Folgende Aspekte sind dabei besonders relevant:
• Identität des Anrufers und Identität des gerufenen Benutzers
Durch Vorspielen einer falschen Identität kann durch Angreifer großen Schaden
anrichten. Beispielsweise das Nutzen von Kostenpflichtigen Diensten oder das
Erschleichen von wichtigen Informationen.
• Registrierungs- und Lokalisierungsinformationen
Durch Fälschen dieser Informationen kann ein Angreifer die Kommunikation umleiten oder durch einen ”Man-in-the-middle”-Angriff entsprechend seiner Ziele
manipulieren.
Bei fehlender Authentifizierung von Signalisierungsnachrichten kann sich ein Angreifer beispielsweise als VoIP-Server ausgeben (engl. impersonation) und Antworten auf
Client Anfragen fälschen wodurch weitere Sicherheitsziele verletzt werden.
”Fehlende Authentifizierung von Signalisierungsnachrichten ermöglicht das so genannte URI Spoofing (analog zum URL-Spoofing heutiger Phishing Angriffe).”, zitiert von
[33], S.45
96
4.3.1.2 Vertraulichkeit
Mit Vertraulichkeit im Zusammenhang mit VoIP-Systemen, ist die Vertraulichkeit der
Sprachdaten gemeint, was eng mit der ”Abhörsicherheit” bei herkömmlichen Telefonaten verknüpft ist.
Damit ist Abhörsicherheit zurecht eines der zentralen Sicherheitsziele in VoIP-Systemen.
Zusätzlich zur Übertragung der Sprache, muss Vertraulichkeit für Benutzernamen und
Passwörter (Authentifizierung), aber auch persönliche Ruflisten und Telefonbucheinträgen gewährleistet sein.
4.3.1.3 Verfügbarkeit
Verfügbarkeit von VoIP-Systemen kennzeichnet hauptsächlich die eigentliche Verfügbarkeit von Telefonie mit einer hinreichenden Sprachqualität. Der Aspekt Ausfallsicherheit ist eng mit dem dem Begriff Verfügbarkeit verknüpft.
4.3.2 Klassifizieren von Angriffsszenarien
Angriffe auf IT-Systeme zielen meist darauf ab, bestimmte Informationen zu erlangen
(Verletzung der Vertraulichkeit) oder bestimmte Funktionalitäten von Systemen einzuschränken (Verletzung der Verfügbarkeit).
Dabei wird zwischen
• dem Ziel des Angriffs,
• den Eigenschaften des Angreifers (aktiv, passiv beobachtend),
• dem Angriffspunkt (Endgeräte, Server)
• der Ebene des Angriffs (ISO/OSI-Schichten)
unterschieden. Passive Angriffe zielen eher auf das unbemerkte Mitlesen und Auswerten
von Informationen (Sniffing), während aktive Angriffe Pakete manipulieren oder eigene
Nachrichten versenden (beispielsweise durch einen ”Man-in-the-middle”-Angriff).
Eine Übersicht über verschiedene Angriffsmöglichkeiten ist im Anhang 9.7 zu finden.
4.3.2.1 Auswirkungen von Angriffen
Erfolgreiche Angriffe auf VoIP-Systeme können verschiedene Auswirkungen haben. Einige davon werden nicht wahrgenommen, andere hingegen haben massive Auswirkung
auf das gesamte System. Folgende Übersicht beschreibt mögliche Auswirkungen auf
97
angegriffene Telekommunikationssysteme hinsichtlich der in 4.3.1 definierten Sicherheitsziele:
• Unterbindung der Kommunikation
– Störung der Betriebsabläufe (Verfügbarkeit)
– Nichterreichbarkeit der Teilnehmer (Verfügbarkeit)
• Umleitung von Datenströmen:
– Abhören der Sprachdaten (Integrität, Vertraulichkeit)
– Auslesen von Registrierungsvorgängen an VoIP-Servern bzw. Gateways (Integrität, Authentizität, Vertraulichkeit)
– Manipulation bzw. Modifikation der übertragenen Daten (Integrität, Authentizität, Vertraulichkeit)
– Übernahme von Verbindungen bzw. Sitzungen (Authentizität, Integrität)
– Identitätsbetrug (Authentizität, Integrität)
– Verhinderung der Kommunikation (Verfügbarkeit)
– Gebührenbetrug (Authentizität)
• Beeinträchtigung der Dienstgüte:
– Verzerrung der Sprachkommunikation (schlechte Sprachverständlichkeit) (Verfügbarkeit)
– Verlangsamung von Verbindungsauf- und -abbau (Verfügbarkeit)
– Fehlerhafte Gebührenerfassung (Integrität)
– Ausfall einzelner Endgeräte oder Gruppen von Geräten (Verfügbarkeit)
4.3.3 Relevanz der Angriffsszenarien
Im vorherigen Abschnitt wurden die Resultate von erfolgreich durchgeführten Angriffen
auf Telekommunikationssysteme aufgeführt. Ziel solcher Angriffe kann ein beliebiges
System sein, jedes System weist spezifische Schwachstellen auf.
Wie sieht es allerdings in VoIP-Netzen im Vergleich zum herkömmlichen Telefonnetz
aus? Existieren ähnliche Schwachstellen? Oder bietet ein VoIP-Netz einem Angreifer
mehr Ansatzpunkte?
98
Unterbindung der Kommunikation
Diese Gruppe von Angriffe zielt auf das Stören und Unterbinden der Kommunikation,
was jeder Teilnehmer des Netzes zu spüren bekommt. Dies wird unter anderem erreicht,
indem Teilnehmer komplett ”vom Netz genommen werden”, was durch physikalisches
Trennen des Teilnehmers vom Netz erreicht werden kann (Durchtrennen von Kabeln).
In klassischen Telefonnetzen kann ein Teilnehmer kann ein Teilnehmer eigentlich nur
durch Manipulieren seines Netzzugangs vom Netz ausgeschlossen werden (Manipulieren des Endgerätes,des Netzzugangspunktes, Netzanschlussleitungen).
Beim Einsatz von VoIP existieren zusätzlich dazu noch weitere Möglichkeiten die Kommunikation zu stören oder gar zu unterbinden:
• Beeinträchtigen der Gesprächsqualität
Bei VoIP wird für ein Gespräch keine feste Leitung geschalten, womit durch
gezieltes Erzeugen von Traffic das Netz überlastet werden. Bei fehlenden Dienstgüteregelungen (QoS) würde es in diesem Fall zu starken Einschränkungen beim
Telefonieren kommen.
Umleitung / Manipulieren von Datenströmen:
Im Gegensatz zum Angriffsziel ”Unterbinden der Kommunikation”, welches durch den
Nutzer bemerkt wird, zielt diese Art von Angriffen eher auf das Ausnutzen des Netzes zum eigenen Vorteil. Dies wird, vom Nutzer unbemerkt, während des Betriebes
durchgeführt.
• Abhören von Gesprächen
Das Abhören von Gesprächen ist in klassischen Telefonnetzen durch ”Aufschalten” auf die Leitung möglich. Dies bedingt aber einen Zugang zu dieser.
Bei VoIP gibt es keine feste Leitung, die Pakete werden durch das gemeinsame
Netz transportiert. Jedem, der Zugang zu diesem Netz und über die entsprechenden Mittel verfügt, ist ein Abhören (sniffen) der Pakete möglich, das Abhören
von Gespräche, im Vergleich zur klassischen Telefonie, also relativ einfach!
• Auslesen von Registrierungsvorgängen an VoIP-Servern bzw. Gateways
Ähnliches Szenario wie beim Abhören von Gesprächen. Durch ”Abhören” von
Paketen kann an entsprechende Informationen gelangt werden, während dies bei
leitungsgebundener Telefonie bedeutet schwieriger zu realisieren ist.
• Manipulation bzw. Modifikation der übertragenen Daten
In leitungsvermittelnden Netzen und auch in VoIP-Netzen schwer möglich (ohne
dass es der Benutzer es bemerkt).
99
• Übernahme von Verbindungen bzw. Sitzungen
In leitungsvermittelnden Netzen und auch in VoIP-Netzen schwer möglich (ohne
dass es der Benutzer es bemerkt).
• Identitätsbetrug
Identitätsbetrug ist eine Angriffsart, bei welcher Gespräche unter falscher Identität geführt werden. In klassischer Telefonie relativ schwer möglich, da die Rufnummer des Teilnehmers ihn (eindeutig) identifiziert.
Im Vergleich dazu, können in VoIP-Netzen, nach Auslesen von Authentifizierungsdaten, beliebige Gespräche (unter falscher Identität) geführt werden. Die
Anmeldung am Server kann dabei mit einer beliebigen IP-Adresse durchgeführt
werden (Heimarbeitsplätze, DHCP-Server).
• Verhinderung der Kommunikation
Verhindern der Kommunikation (unbemerkt) in klassischen Telefonnetzen durch
Manipulieren von Datenströmen, erfordert Eingriffe in zentrale Elemente wie
TK-Anlagen oder Vermittlungsstellen.In VoIP-Netzen lässt sich dies durchaus
realisieren, beispielsweise, wenn ein Angreifer sich als ”VoIP-PBX” ausgibt und
anschließend alle abgehenden Gespräche sperrt, ankommende aber umleitet. Somit wäre ein Benutzer isoliert!
• Gebührenbetrug
Durch Vortäuschen einer falschen Identität in VoIP-Systemen relativ einfach umzusetzen, in klassischen Netzen eher schwierig zu realisieren, aufgrund der eindeutigen Rufnummer.
Beeinträchtigung der Dienstgüte
Angriffe die auf dieses Ziel ausgerichtet sind, haben in VoIP-Netzen mehr Chancen
dies zu erreichen! In der klassischen Telefonie wird für jede Verbindung eine Leitung
mit fest definierter Dienstgüte geschalten. Ein Angriff hat im Erfolgsfall einen Ausfall
der Verbindung als Resultat. Diese ”feste Leitung” existiert in VoIP-Netzen nicht, ein
Angriff auf das Gesamtnetz beeinflusst somit durchaus die Dienstgüte.
Fazit
Wie leicht zu erkennen ist, bieten VoIP-System bedeutend mehr Angriffsstellen als
herkömmliche Telefonsysteme. Folgende Übersicht stellt beide Netzarten, hinsichtlich
des Bedrohungspotentials vergleichend gegenüber:
Beeinträchtigen der Gesprächsqualität
Manipulieren von Datenströmen
Beeinträchtigung der Dienstgüte
100
klassisches
Telefonnetz
VoIP-Netze
+
+
+
++
+++
+++
Legende:
+++
++
+
sehr hohes Risiko
hohes Risiko
geringes Risiko
Tabelle 4.2: Ergebnisse von Angriffen
Sicherheit in VoIP-Netzen ist ein wichtiger Punkt, welcher bei der Planung und Realisierung unbedingt Beachtung finden muss. Bedingt durch das relativ einfache Abhören
des Netzwerkverkehrs mit entsprechenden Tools, bieten sich viele Angriffsstellen für
potentielle Angreifer. Bei kabelgebundenen IP-Netzen ist die Gefährdung nicht ganz
so hoch, wie in WLAN-Netzen. Dort brauchen Angreifer nicht einmal physischen Zugang zum Netz!
Aufgrund dieser Tatsachen, bedarf es der Implementierung einiger Sicherheitsfunktionen, welche im folgenden Abschnitt näher beschrieben werden!
4.3.4 Absichern von VoIP-Netzen
Im vorherigen Abschnitt 4.3.3 wurde ermittelt, dass VoIP-Netze im Vergleich zu herkömmlichen Telefonnetzen einem deutlich höherem Sicherheitsrisiko ausgesetzt sind.
Bedingt durch die Übertragung durch ”offene” Netze wie dem Internet, wo Angreifer
viele Ansatzpunkte haben, ein solches Netz zu kompromittieren, bedürfen VoIP-Netze
einer besonderen Absicherung.
In den folgenden Abschnitten werden Möglichkeiten aufgezählt, ein VoIP-Netz zu sichern. Dabei ist zu beachten, dass die Aufzählungen keinen Anspruch auf Vollständigkeit haben!
4.3.4.1 Absichern von Systemkomponenten (Hardware)
Sichere Positionierung der Hardwarekomponenten (Server)
Sicherheit von (Hardware-)Systemkomponenten beginnt bei der Wahl eines geeigneten
101
Standortes. Server sollten dazu grundsätzlich in entsprechend klimatisierten (Ausfallsicherheit) und abschließbaren Räumen (Zugangskontrolle) aufgestellt werden!
Redundante Auslegung wichtiger Netzkomponenten
(IP-)Telefonie ist in vielen Unternehmen das wichtigste Mittel bei der internen und
externen Kommunikation. Der Ausfall dieses Kommunikationsmittels in einem Callcenter wäre ein Super-GAU.
Um dieses Ausfallrisiko und Ausfallkosten zu minimieren, gewisse Verfügbarkeitsanforderungen zu erfüllen und um Ausfallzeiten möglichst gering zu halten ist es notwendig
Redundanz zu schaffen. Eine gleiche Verfügbarkeit eines VoIP-Dienstes im Vergleich
zum herkömmlichen Telefon-Dienstes ist nur durch eine entsprechende Redundanz
wichtiger Hardwarekomponenten zu erreichen. Dabei sollten folgende Komponenten
in ein geeignetes Redundanzkonzept integriert werden ([33],S.79):
• Server (DHCP, VoIP-PBX)
• Registrars oder Gatekeeper (Verwaltung, Prüfen von Berechtigungen)
• Billing Server (zur Gebührenabrechnung)
• Firewalls
• Switches, Router
Zusätzlich zur reinen Hardwareredundanz, bieten zwei physikalisch getrennte Verbindungen zum Internet-Service- Provider (ISP) zusätzliche Sicherheit. Falls beide gleichzeitig ausfallen, würden sich Festnetz-Leitungen als Backuplösung anbieten, um den
Telefondienst aufrecht zu erhalten.
Schutz vor Stromausfall
Auf Stromausfälle kann mit einer Hilfe einer USV (Unterbrechungsfreie Stromversorgung) entsprechend reagiert werden. Allerdings lassen sich damit nur zeitliche begrenzte Stromausfälle auffangen.
Trennung von Sprach- und Datennetz
Ein großer Vorteil von VoIP ist die Verschmelzung von Daten- und Telefonnetz. Dies
erhöht allerdings das Ausfallrisiko deutlich: Fällt das Datennetz aus, steht auch kein
Telefondienst zur Verfügung!
Um dem entgegen zu wirken, sollte das Datennetz logisch oder physikalisch vom
102
Sprachnetz getrennt werden. Angenehmer Nebeneffekt: QoS-Mechanismen lassen sich
einfacher und besser implementieren.
Eine logische Trennung lässt sich zum Beispiel durch genannte VLANs (Virtual Local
Area Networks) realisieren, welche im IEEE-Standard 802.1Q ([19]) spezifiziert sind.
Einsatz von IP-Telefonen
Neben dem Einsatz von Softphones bietet sich die Möglichkeit der ausschließlichen
Nutzung von IP-Telefonen (Hardphones). Diese verfügen über eine eigene Netzwerkschnittstelle und basieren meistens auf proprietären Betriebssystemen. Diese Betriebssysteme sind auf die geforderte Funktionalität beschränkt, das Risiko eines direkten
Angriffs ist geringer, da der Angreifer spezielle ”Schadprogramme” einsetzen muss.
4.3.4.2 Absichern von Systemkomponenten (Software)
Einsatz von Softphones
Softphones sind (PC-)Anwendungen (Software) für den Einsatz von VoIP ohne seperate IP-Telefone. Sie kommen häufig aus Kostengründen zum Einsatz, benötigen
allerdings einen PC, während IP-Telefone keinen PC zum Betrieb benötigen.
Softphones sind für Angriffe besonders anfällig, da sie auf weit verbreiteten Betriebssystemen (Windows) basieren und Ressourcen mit anderen Anwendungen teilen. Deswegen sollte der Einsatz von Softphones gut überlegt sein und bekannte Sicherheitslücken
sämtlicher, auf dem PC installierter, Software durch entsprechende Updates geschlossen werden!
Hinweis:
Die Sicherheitsanforderungen an Softphones sind im Vergleich zu reinen IP-Telefonen
(Hardphones) deutlich höher! Softphones sind als Anwendungen auf einem, grundsätzlich als ”unsicher”, einzustufenden System (Windows-PC) angesiedelt.
Die Angriffe auf Endgeräte zielen grundsätzlich auf das unbemerkte Erschleichen von
Diensten und Dienstleistungen, nicht auf die Übernahme eines Servers. Das Übernehmen eines Servers wird in den meisten Fällen sofort erkannt, das ”unbefugte” Nutzen
von Diensten nicht!
103
4.3.4.3 Absichern des Systems
Patchmanagement
Fehlendes Patchmanagement, also das regelmässige Schließen bekannter Sicherheitslücken aller verwendeter Software, stellt ein großes Risiko für jedes Netz dar. Sicherheitslücken sollten zeitnah geschlossen und dokumentiert werden!
Dies betrifft vor allem Server, aber auch PCs mit Softphones.
Absichern der IP-Telefonanlage
Die IP-Telefonanlage (IP-PBX) ist das Herzstück eines VoIP-Netzes und bedarf deshalb einer besonderen Absicherung gegen Angriffe. Fällt sie aus, bricht, falls keine
Redundanz vorhanden, das gesamte Telefonnetz zusammen!
Empfohlene Maßnahmen sind:
• Absichern von Remote-Schnittstellen
Die Verwaltung der Telefonanlage erfolgt meist remote über ein Web-Interface
(HTTP) oder über eine Remote-Verbindung (SSH). Grundlegend sollten nicht
verwendete Remote-Schnittstellen deaktiviert (speziell Telnet und FTP), nur die
tatsächlich benötigten Ports geöffnet werden. Über die entsprechenden Schnittstellen sollte auch nur über sichere Verbindungen zugegriffen werden (verschlüsselte Verbindungen wie HTTPS oder Secure Shell (SSH)).
• Sichere Passwörter
Die für den Zugriff verwendeten Accounts müssen entsprechenden Sicherheitsanforderungen entsprechen. Benutzernamen und Passwörter, welche eine entsprechende Länge haben und aus einer ”zufälligen” Kombination aus Ziffern und
Buchstaben bestehen, reduzieren das Sicherheitsrisiko deutlich.
• Einschränken von Rechten, mit denen Dienste ausgeführt werden
• Einsatz einer Firewall
Authentifizierung von Endgeräten
Zusätzlicher Schutz vor unbefugten Zugang zum Netz, bietet die Authentifizierung der
verwendeten Endgeräte (PCs mit Softphones oder IP-Telefone) anhand ihrer MACAdresse. Nur bekannten und entsprechend registrierten Endgeräten wird der Zugang
zum Netz gewährt.
104
Absichern der Netzwerkbasisdienste
Da VoIP auf dem IP-Protokoll basiert, sind solche System, wie ”normale”IP-Datennetze
auch, anfällig auf Angriffe innerhalb der Schichten 2 und 3 des OSI-Referenzmodells.
Angriffe über diese Schichten zielen auf das Abhören der Übertragungen und das Einschränken der Verfügbarkeit!
Besonderes Augenmerk liegt dabei auf den Diensten ”ARP” und ”DHCP”.
Maßnahmen zur Sicherung dieser Dienste sind hier zu finden: [33], Seite 76ff. und [51],
Seite 81.
Absichern der Netzübergänge
Netzübergänge (Gateways) verbinden das Netz mit anderen Netzen, wie dem öffentlichen Telefonnetz. Diese Netzübergänge müssen auch gegen Angriffe über diese Kanäle
abgesichert werden. Dies kann durch den Einsatz einer ”Firewall” oder durch den Einsatz eines ”Session Border Controller (SBC)” (Kombination aus Firewall, Application
Layer Gateway (ALG, siehe 3.3.4) und Proxy) realisiert werden!
4.3.4.4 Absichern der Datenströme
Verschlüsseln der Sprachdatenströme
Die Übertragung der eigentlichen Sprachdaten wird durch das RTP-Protokoll (3.2.1.1)
über UDP übertragen. Wenn ein Angreifer diese Pakete ”abhört”, kann er mit geringem
Aufwand die Kommunikation abhören.
Um dies zu Verhindern ist das Verschlüsseln der Daten eine effektive Maßnahme! Eine
Verschlüsselung der Sprachdaten wird durch das Schalten von sicheren, verschlüsselten
Tunneln, oder durch das Verschlüsseln der Sprachdaten selber erreicht.
Die Nutzung von sicheren ”Tunneln” kann mit Hilfe von IPSec (Internet Protocol Security) ([25]) oder PPTP (Point-to-Point Tunneling Protocol)([24]) erreicht werden und
hat den Vorteil, dass sowohl Sprach- als auch die Signalisierungsdaten verschlüsselt
werden. IPSec wird meist bei der Verbindung zweier Standorte eingesetzt, wo die Datenübertragung über ”unsichere Netze”, wie dem Internet, erfolgt.
Für die Verschlüsselung der Sprachdaten bietet sich das Protokoll SRTP (3.2.1.2) an.
Verschlüsseln der Signalisierungsdatenströme
Weitaus wichtiger als die Absicherung der Sprachdaten ist eine abgesicherte Übertragung der Signalisierungsdaten. Damit sinkt das Risiko des Abhörens, der Anrufprotokollierung und auch das Risiko der Manipulation.
105
Um eine Verschlüsselung der Signalisierungsdaten zu erreichen, bieten sich verschiedene Möglichkeiten an ([51]):
• TLS (Transport Layer Security) - siehe [27]
Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) ist ein hybrides Verschlüsselungsprotokoll zur Datenübertragung im Internet. Angesiedelt im
OSI-Referenzmodell ist TLS / SSL zwischen der Transport- und der Anwendungsschicht.
• S/MIME (Secure / Multipurpose Internet Mail Extensions) -siehe [26]
S/MIME ist ein Sicherheitsmechanismus für eine Ende-zu-Ende-Verschlüsselung
innerhalb des SIP-Standards.
Spezifiziert in RFC3261 (www.ietf.org/rfc/rfc3261.txt)
• IPSec (Internet Protocol Security) - siehe [25]
IPsec wurde von der IETF als integraler Bestandteil von IPv6 entwickelt, wobei das IPsec-Verfahren und Protokolle auch mit IPv4 kompatibel sind! IPsec
soll die Schutzziele Vertraulichkeit, Authentizität und Integrität gewährleisten.
Zusätzlich dazu soll auch ein Schutz vor sogenannten Replay-Angriffen gegeben
sein. Angesiedelt ist IPSec auf der Vermittlungsschicht (Schicht 3).
Fazit
VoIP-Netze sind ohne Sicherheitsmaßnahmen ein leichtes Ziel für potentielle Angreifer
und bedürfen genau deshalb eines umfassenden Sicherheitskonzeptes. Mit der Umsetzung genannten Sicherheitsmaßnahmen kann zumindest ein Mindeststandard an
Sicherheit für ein aufzubauendes VoIP-Netz erreicht werden!
106
4.4 Quality of Service (QoS)
”Quality of Service (QoS) oder Dienstgüte beschreibt die Güte eines Kommunikationsdienstes aus der Sicht der Anwender, das heißt, wie stark die Güte des Dienstes mit
deren Anforderungen übereinstimmt. Formal ist QoS eine Menge von Qualitätsanforderungen an das gemeinsame Verhalten beziehungsweise Zusammenspiel von mehreren
Objekten.”[78]
An dieser Stelle hätte auch eine beliebige andere Definition von QoS stehen können,
da es noch immer keine allgemein gültige Definition des Begriffs gibt. Dabei ist die
Dienstgüte ein sehr wichtiger Faktor bei der Übermittlung von Informationen in Telekommunikationsnetzen.
Die strukturellen Gegebenheiten der PSTN/ISDN Netze sowie der Einsatz der Leitungsvermittlung bieten eine ideale Grundlage für Quality of Service. Jede Verbindung
erhält die gleiche Dienstgüte. Zusätzlich bieten die traditionellen Telefonnetze eine hohe
Verfügbarkeit [57]. Aus diesen Gründen wird im Folgenden vor allem auf die Möglichkeiten von QoS in IP-Netzen eingegangen.
Die Anforderungen and die Dienstgüte in IP-Netzen unterscheiden sich je nach Anwendung. Während z.B. für einen Datentransfer über FTP eine hohe Datenrate und
eine hohe Zuverlässigkeit am wichtigsten sind, ist bei bei einer Email allein die Zuverlässigkeit von Bedeutung. Die VoIP-Kommunikation hat eine ganze Reihe an Parametern, welche zum einen die Verbindung charakterisieren, zum anderen aber auch als
Bedingung für eine ausreichende Dienstgüte gesehen werden können.
• Verzögerung: Bei Sprachübertragungen ist eine spürbare Verzögerung deutlich
störender als z.B. Knacken aufgrund von Datenverlusten während der Übertragung. Die ITU-T-Empfehlung G.114 [37] geht bei der Sprachkommunikation von
einer guten Qualität aus, wenn die Signalverzögerung in einer Übertragungsrichtung unter 150ms bleibt. Akzeptabel sind noch 150 bis 400ms. Oberhalb von
400ms ist die Verständlichkeit nur noch unzureichend.
Gründe für Verzögerungen sind unter anderem: Signallaufzeit auf Übertragungswegen, Wartezeiten in Vermittlungseinrichtungen (Router, Switches, HUBs), Pufferzeit (Paketierung, Jitterglättung), Performance des Endsystems.
• Laufzeitschwankungen (Jitter): Hohe Laufzeitschwankungen bewirken eine
hohe Paketverlustrate durch den Jitter-Puffer in Gateways oder Endgeräten. Das
107
wiederum resultiert entweder in größeren Verzögerungen oder einem deutlichen
Verlust an Übertragungsqualität. Bei einem Jitter von weniger als 100ms kann
eine Anpassung des Jitter-Puffers für Verbesserung sorgen. Die Erhöhung der
Puffergröße bei einem Jitter >100ms wirkt sich sehr stark auf die Verzögerungszeit aus und sollte daher vermieden werden.
VoIP-Pakete sind mit einer mitleren Größe von 100Byte (in der Regel zwischen
70 und 120 Bytes) deutlich kleiner als traditionelle IP-Pakete, welche im Mittel 250
Byte groß sind. Wobei jedoch 40 Prozent der Pakete rund 40 Bytes und 35 Prozent
der Pakete 1500 Bytes groß sind [52]. Durch eine Verkleinerung der Paketgröße an die
VoIP-Pakete kann eine höhere Datenrate erzielt werden. Eine kleinere Paketgröße kann
wiederum die Auslastung erhöhen, was die Verzögerungszeit von Paketen vergrößert.
An dieser Stelle sei auf die Möglichkeiten von cRTP 3.4.4 verwiesen wodurch der
IP/RTP/UDP-Header von 40 auf 2-4 Bytes komprimiert werden kann.
Weitere Maßnahmen bzw. Techniken zur Realisierung von Quality of Service für die
VoIP-Kommunikation sollen im Folgenden näher betrachtet werden:
• Überdimensionierung der Netze
• Traffic Engineering und Constraint based Routing (Routing mit Randbedingungen)
• Multiprotocol Label Switching(MPLS)
• Asynchronous Transfer Mode (ATM)
• Integrated Services (IntServ)
• Differentiated Services (DiffServ)
Das von der Technik her einfachste Verfahren ist die Überdimensionierung der
Netze. Dabei werden die Netzressourcen so ausgelegt, dass selbst bei maximalem Datenaufkommen die Netzauslastung nicht mehr als 50 Prozent beträgt. Durch die geringe
Auslastung lassen sich die Verzögerungen niedrig und zudem relativ konstant halten.
Das Problem hierbei ist, dass alle Netzelemente überdimensioniert werden müssen um
Flaschenhälse zu vermeiden. Also auch die Elemente, welche normalerweise gar keine
Anforderungen an QoS stellen. Dies erfordert einen hohen finanziellen Aufwand und
ist eher eine mögliche Lösung für überschaubare lokale Netzwerke (LANs).
108
Im Gegensatz zur Überdimensionierung wird bei allen anderen Maßnahmen die Gesamtleistungsfähigkeit der Netze nicht gesteigert. Vielmehr wird versucht die vorhandenen Kapazitäten zwischen allen Nutzern geschickt aufzuteilen. Den unterschiedlichen
Diensten entsprechend wird eine Unterteilung in ”wichtige” und ”weniger wichtige” Datenpakete vorgenommen, wobei verhindert werden muss dass jeder Nutzer nur ”wichtige” Pakete hat. Dieser Vorgang wird ”Policy based Networking” genannt.
Traffic Engineering wird verwendet um Engpässe in einem Netzwerk zu vermeiden.
Dabei wird der aktuelle Zustand des Netzes analysiert, mit den tatsächlichen Anforderungen verglichen und falls nötig optimiert um eine besser Netzauslastung zu erzielen.
Um diesen Prozess zu automatisieren kann Constraint based Routing angewandt
werden. Dieses verwendet einige zusätzliche Parameter beim Routing, um einen geeigneteren Pfad zu ermitteln. Neben der Weglängenoptimierung wird z.B. auch die
verfügbare Bandbreite in betracht gezogen, wodurch ein Paket möglicherweise einen
längeren Weg zugewiesen bekommt, dafür aber einen mit ausreichend Kapazität. Hierdurch können Engpässe vermieden und der Verkehr gleichmäßiger verteilt werden.
Multiprotocol Label Switching (MPLS) wird verwendet um zusammengehörende IP-Pakete mit ”Etiketten” zu versehen und dadurch zu gruppieren. Das erspart
zum einen das Auswerten jedes einzelnen IP-Headers, zum anderen nehmen Pakete
mit dem gleichen Label den gleichen Weg, was das Traffic Shaping vereinfacht.
Der Asynchronous Transfer Mode (ATM) wurde mit dem Hintergedanken entwickelt, verschiedenste Dienste über ein Paketnetz mit der jeweils erforderlichen QoS
anzubieten. Ähnlich wie beim MPLS werden auch beim ATM Pakete gruppiert und
gekennzeichnet, wobei gleiche Kennzeichnung in der Folge wieder gleicher Weg bedeutet. Zusätzlich kennt ATM unterschiedliche Diensteklassen, z.B. Constant Bit Rate
(CBR) für Sprachkommunikation oder Unspecified Bit Rate (UBR) für ”Best Effort”Anwendungen. Die vorher festgelegten Verbindungsparameter eines Dienstes werden
zu Beginn der Verbindung mithilfe der ”Admission Control” auf Zulässigkeit geprüft.
Diese Parameter werden während der Verbindung weiterhin überwacht (Parameter
Control), eventuell wird korrigierend eingegriffen (Policing).
Integrated Services (IntServ) unterstützt absolute QoS, d.h. IP-Pakete die zu
einem ”wichtigen” Dienst gehören werden bevorzugt behandelt und erhalten zusätzlich (sofern vom Netz her möglich) als absolute Größe die gewünschte Dienstgüte.
Damit lässt sich theoretisch eine QoS garantieren.[65]. Um dies gewährleisten zu kön-
109
nen kommt beim IntServ-Verfahren das Resource Reservation Protocol (RSVP) zum
Einsatz, was, wie der Name schon vermuten lässt, die Reservierung von Ressourcen
für einen Dienst aushandelt. Diese Eigenschaft von IntServ ist auch gleich ihr größter
Nachteil, denn es kann zu einem sehr hohen Signalisierungsaufkommen führen, was bei
großen Netzen zu einem erheblichen Aufwand in den Routern führt.
Das ”Differentiated Services (DiffServ)”-Verfahren unterstützt im Gegensatz zu IntServ nur die bevorzugte Behandlung von ”wichtigen” Diensten. Das bedeutet, dass es
bei DiffServ einfach verschiedene Diensteklassen mit unterschiedlicher Anforderung an
die QoS gibt, die in Folge mit unterschiedlicher Priorität behandelt werden. Für die
gewünschte Dienstgüte erhält man daher nur eine relative Garantie, aber keine absolute. Das Problem der Signalisierung hat DiffServ daher nicht. Pakete werden zu Klassen
zusammengefasst und innerhalb dieser von Routern mit gleicher Priorität behandelt.
Bei der Kennzeichnung der Klassen haben sich in der Praxis drei Hauptklassen durchgesetzt:
• ”Expedited Forwarding”
• ”Assured Forwarding”
• ”Best Effort”
Der auch als Premium Service bezeichnete Dienst ”Expedited Forwarding” (beschleunigtes Versenden) ist durch eine geringe Verzögerungszeit, geringen Jitter und geringe
Paketverlustrate sowie eine zugesicherte Bandbreite charakterisiert und eignet sich für
die Echtzeitkommunikation.
”Assured Forwarding” (sicher Versenden) ist in zwölf verschiedene Prioritätsklassen
untergliedert. Jede Klasse besteht aus einem ”Class” sowie einem ”Drop Precedence”
Parameter. Während der Erste für eine zugesicherte Bandbreite steht, beschreibt der
Zweite die Wahrscheinlichkeit, mit der ein Datenpaket bei zuviel Vekehrslast verworfen
wird. Dies ermöglicht eine relativ feine Abstufung für Anwendungen.
Unter ”Best Effort” ist in diesem Fall eine Klasse zu verstehen, welche keinerlei
Garantien und Zugeständnisse hinsichtlich der Übertragung von Paketen macht. In
dieser Klasse sind die meisten IP-Datenpakete zu finden.
Durch den Einsatz von einem sogenannten ”Bandwith Broker” (BB) kann auch DiffServ eine Aushandlung von Dienstgüten und Ressourcen vornehmen. Durch die separate
Anbindung der BBs sind jedoch die Router anders als bei IntServ nicht vom Signalisierungsverkehr der Ressourcen-Reservierung betroffen.
110
In der Empfehlung RFC 2998 wird vom IETF auch eine Mögliche Kombination von
DiffServ und IntServ spezifiziert [5].
Die hier beschriebenen Maßnahmen zur Umsetzung von Quality of Service beziehen
sich vor allem auf die generelle Umsetzbarkeit in IP-Netzen.
Für lokale Netzwerke wie der in dieser Arbeit umgesetzten VoIP-Umgebung sind diese
Maßnahmen in der Regel nicht von Bedeutung. Verzögerungen, Jitter und Paketverluste treten nur minimal auf. Bei zu hoher Auslastung des Netzes wären eine Reihe
von Optionen denkbar, welche das Netz entlasten. So könnte z.B. abhängig von der
verfügbaren Bandbreite ein anderer Sprach-Codec verwendet werden.
Ohne Vermittlungsstellen über die der Netzverkehr geleitet wird, lässt sich dieser jedoch nicht mittels ”Traffic Shaping” formen. Jeder Server/Client im Netz kann den
Verkehr nur innerhalb seiner Grenzen beeinflussen. Auf alles was darüber hinausgeht
hat man wenn überhaupt nur sehr wenig Einfluss.
Wie man sehen kann gibt es eine Reihe von Möglichkeiten, QoS in IP-Netzen zu
ermöglichen. Die hohe Zahl der Unbekannten Elemente auf dem Weg zwischen zwei
Gesprächsteilnehmern erschwert eine einfach Umsetzung jedoch.
111
4.5 Management und Wartung
Um große Telekommunikationsnetze zu verwalten wird ein entsprechendes Netzmanagementsystem benötigt. Das Netzmanagement bietet Informationen über das zu managende Netz an und stellt Methoden zur Steuerung des Netzes zur Verfügung - es bietet
also Möglichkeiten zur Verwaltung, Überwachung und Wartung des zu betrachtenden Netzes und seiner Betriebstechnik (Router, Vermittlungsstellen,..). Der englische
Fachbegriff für dieses Management lautet OAM (Operation, Administration and Maintenance).
In den folgenden Abschnitten wird zuerst auf allgemeine Aspekte des Netzmanagement
eingegangen. Anschließend werden einige Managementkonzepte kurz vorgestellt.Dazu
gehören
• TMN (4.5.3)
..ein allgemeines Managementkonzept für TK-Systeme
• Rebell (4.5.4)
..ein spezielles System der Deutschen Telekom für ihr Übertragungsnetz
• SNMP (4.5.5)
..speziell für TCP/IP-Netze
• das OSI-Netzmanagement 4.5.6
4.5.1 Allgemeine Architektur des Netzmanagements
Netzmanagementsysteme existieren für verschiedene Standards und werden von verschiedenen Herstellern angeboten. Die gemeinsame Basis der verschiedenen Systeme
ist gleich, alle basieren auf 4 verschiedenen Modellen ([17]):
• Informationsmodell
Das Informationsmodell ist ein beschreibendes Regelwerk, für die Definition der
Daten und Informationen des Managementsystems, unabhängig vom verwendeten Netzmana-gement-Protokoll. Dieses Regelwerk ist in ISO 10165 SMI (Structure of Management Information) dargestellt. Die Gesamtheit aller Daten und
Informationen wird als Managementinformation bezeichnet und ist in der MIB
(Management Information Base) zusammengefasst.
112
Der Zustand eines im Netz befindlichen Systems wird durch so genannte ”Managed Objects” (MO) beschrieben. Jedes MO überwacht dabei eine bestimmte
Funktion in einem Netz (beispielsweise den aktuellen Status eines Endgerätes).
• Organisationsmodell
Das Organisationsmodell beschreibt Wer, und vor allem Wie, auf das Netz zugreifen darf.
• Kommunikationsmodell
Das Kommunikationsmodell beschreibt das Managementprotokoll zum Informationsaustausch zwischen Manager und Agent. Über den Agenten greift der Manager auf die ”Managed Objects” zu.
• Funktionsmodell
Durch das Funktionsmodell werden die einzelnen Funktionsbereiche des Netzmanagements definiert. Eng mit den Aufgaben des Netzmanagement ist ”FCAPS”
verbunden. Mehr dazu in Abschnitt 4.5.2
4.5.2 FCAPS
Der Begriff ”FCAPS” steht für die einzelnen Funktionsbereiche des Netzmanagements:
• Fault Management (Fehler- und Störungsmanagement)
Dieses Managementelement beschäftigt sich mit dem Erkennen, Analysieren und
Beheben von Problemen innerhalb des Netzes. Dazu gehört die globale Netzüberwachung, welche Alarme und Störungen erfasst, analysiert und entsprechende
Maßnahmen einleitet.
• Configuration Management (Konfigurationsmanagement)
Das Konfigurationsmanagement beschäftigt sich mit den managebaren Objekten
im Netz. Die Grundaufgaben aus Sicht des Managers sind das Erzeugen und Löschen von Objekten, sowie das Ändern von Namen und Attributen der Objekte.
Die Grundaufgaben aus Sicht des Agenten ist das Weiterleiten von Ereignisse
(betreffen die MO) an den Manager.
• Account Management (Abrechnungsmanagement)
Hier werden die genutzten Dienstleistungen erfasst und entsprechenden Kostenstellen zugeordnet.
113
• Performance Management (Leistungsmanagement)
Das Leistungsmanagement wird eingesetzt, um Dienste effizient bereitzustellen
und zu nutzen. Zusätzlich wird durch die Überprüfung und Überwachung von
Leistungskenngrößen (Durchsatz, Verfügbarkeit) eine Basis für Qualitätssicherungsmaßnahmen geschaffen.
• Security Management (Sicherheitsmanagement)
Das Sicherheitsmanagement sorgt für die Sicherheit in Netzen. Dazu gehören unter anderem Zugangskontrolle, Authentifizierung, die Verschlüsselung von Daten
aber auch das Erfassen von unerlaubten Zugriffen auf das Netz.
4.5.3 TMN
Das Netzmanagementkonzept TMN (Telecommunication Management Network) ist
ein einheitliches und herstellerunabhängiges Netzmanagementsystem für Telekommunikationsnetze. Entwickelt wurde es von der ITU-T und ist in den Empfehlungen der
Serie M.3000 beschrieben. Die TMN-Richtlinien beschreiben somit eine Architektur für
den Betrieb und die Unterhaltung von Kommunikationsnetze. Wie beim Intelligenten
Netz (2.4) handelt es sich nicht um ein eigenes Netz, sondern einem architektonischen
Ansatz, bei welchem alle Elemente der Übertragungs- und Vermittlungstechnik einer
einheitlichen Steuerung unterworfen sind.
Weitere Informationen zum Netzmanagementkonzept TMN:
([67], S.719ff), ([17], S.566ff)
4.5.4 Netzmanagementsystem Rebell
Das Netzmanagementsystem ”Rebell” wurde in den 80er Jahren von der Deutschen
Telekom zur Verwaltung ihres Übertragungsnetzes entwickelt. Rebell steht dabei für
”rechnergestützte Betriebslenkung leitergebundener Übertragung” und ist nach dem
TMN-Modell (siehe 4.5.3) aufgebaut.
Ziele von ”Rebell” sind:
• Unterstützung bei der Konfiguration und Planung der Netzstruktur
• Erhöhung der Dienstgüte und der Verfügbarkeit
• schelle Bereitstellung von Übertragungswegen
• Meldungen über Ereignisse und Störungen im Netz erfassen
114
• Informationen über den Zustand des Netzes sammeln
Rebell ist eines der größten Netzmanagementsysteme seiner Art.
Quelle: [17], Seite 568
4.5.5 SNMP
SNMP (Simple Network Management Protocol) ist ein von der IETF entwickeltes Netzwerkprotokoll für die Verwaltung von TCP/IP-Netzen im Internet. Ziel von SNMP ist
es, Elemente im Netzwerk von einer zentralen Station aus zu überwachen und zu steuern. Der Aufbau und der Kommunikationsablauf bei der Überwachung der Elemente
ist durch SNMP festgelegt, außerdem wurde bei der Entwicklung von SNMP darauf
geachtet, dass jedes netzwerkfähige Gerät in die Überwachung integriert werden kann.
In der ersten Version des SNMP (SNMPv1) wurden dazu verschiedene Typen von
SNMP-Nachrichten definiert. Diese können eingesetzt werden, um Informationen oder
Konfigurationsänderungen anzufordern oder auf solche Anfragen zu antworten. Die
zur Netzüberwachung nötigen Daten erhält der Manager durch Abfragen der SNMPAgenten (Polling-Verfahren). Bei wichtigen oder dringenden Meldungen kann sich der
Agent direkt an den Manager wenden (Trap-Meldungen).
Basis für die Übertragung ist dabei UDP, allerdings kann jedes andere Transportprotokoll eingesetzt werden. Einsatzgebiet für SNMP sind lokale TCP/IP-Netze.
Weitere Informationen zu SNMP:
([51]), ([57]), ([17],S.565)
4.5.6 Das OSI-Netzmanagement
Das OSI-Netzmanagement ist die Standardisierung eines Netzmanagementsystems für
offene Netze, also Netze, welche sich an das OSI-Referenzmodell halten. Dabei werden
2 Managementsituationen unterschieden:
• Die autonome Verwaltung von Betriebsmitteln eines einzelnen offenen Systems
und
• die Kooperation verschiedener offener Systeme zum Zwecke der Verwaltung von
Betriebsmitteln
Dabei besteht das OSI-Netzmanagement aus verschiedenen einzelnen Standards:
• CMIP (Common Management Information Protocols)
115
• CMIS (Common Management Information Services)
• SMFA (Specific Management Functional Areas)
• SMI (Structure of Management Information)
Quelle: ([17])
4.5.7 Netzmanagement im Vergleich
In den vorangegangenen Abschnitten wurden grundlegende Prinzipien des Netzmanagement und einige Managementsysteme vorgestellt. In diesem Abschnitt werden nötige
Managementaufgaben für herkömmliche TK-Netze mit denen für VoIP-Netze verglichen.
Hinweis: Der Fokus dieser Betrachtung liegt auf privaten Netzen!
Welche Information erhalte ich über das jeweilige Netz?
herkömmliche TK-Netze:
• Leitungsbelegung
• Status der Endgeräte (Nutzer angemeldet)
• Störungen im Netzwerk, Leitungsausfälle
VoIP-Netze:
• Netzauslastung
• Status der Endgeräte (am Server angemeldet)
• Status der Netzkomponenten (Router, Server)
• Störungen im Netzwerk (signalisiert durch Timeouts)
• Verzögerung (der Pakete, Gesprächsverzögerung)
• Ressourcenreservierungen (in Routern)
• Sicherheitsaspekt Zugangskontrolle (anhand MAC-Adresse)
• Sicherheitsaspekt Verschlüsselung (anhand mitlesen der Pakete)
Weitere Informationen zum Thema Management sind unter 7 zu finden.
116
4.6 Adressierung
Was ist Adressierung?
Adressierung ist die Zuordnung einer Adresse zu einem bestimmten Objekt. Solch
ein Objekt ist beispielsweise eine bestimmte Person, welcher eine Post- oder eine EMailadresse zugeordnet ist. Mit anderen Worten beschreibt eine Adresse, wie diese
Person erreichbar ist.
Adressierung im öffentlichen Telefonnetz
Im öffentlichen Telefonnetz werden diese Adressen als ”Telefonnummern” bezeichnet.
Diese kennzeichnen eine eindeutige Ziffernfolge zur Identifizierung von Teilnehmern
im öffentlichen Telefonnetz. Innerhalb verschiedener Ortsnetze (vgl. 2.1) können Teilnehmerrufnummern mehrfach vergeben werden, allerdings muss die Kombination von
Ortskennzahl + Teilnehmerrufnummer immer eindeutig sein!
Vergeben werden die Telefonnummer von den Telefongesellschaften (beispielsweise
”Deutsche Telekom”, ”Arcor”), welche allerdings an nationale Nummerierungspläne gebunden sind. Diese Nummerierungspläne werden von von den nationalen Regulierungsbehörden verwaltet, in Deutschland übernimmt die Bundesnetzagentur diese Aufgabe.
Internationale Vorwahlen hingegen verwaltet die ITU (vgl. E.164 [36]).
Eine Adresse für einen Teilnehmer im öffentlichen Telefonnetz ist wie folgt aufgebaut:
Länderkennzahl (LKz) + Ortsnetzkennzahl (ONKz) + Teilnehmerrufnummer (RufNr)
In Deutschland ist die maximale Länge einer Rufnummer auf 13 Ziffern beschränkt,
im internationalen Bereich sind maximal 15 Ziffern erlaubt.
Rufnummern in Mobilfunknetzen setzen sich aus einer (Betreiber-)Vorwahl und einer Rufnummer zusammen. Eine Mobilfunk-Telefonnummer ist anhand ihrer Vorwahl
leicht zu erkennen, welche mit ”01XX” beginnt.
Adressierung bei VoIP
Anders als im öffentlichen Telefonnetz basiert das Internet auf einer anderen Adresse
als das öffentliche Telefonnetz, der ”IP-Adresse”. In Version 4 des Internetprotokolls
besteht eine Adresse aus 4 Blöcken mit je 8 Bit, also insgesamt 32 Bit. In IPv6 besteht
eine Adresse aus 128 Bit.
Allerdings ist echt nicht ohne weiteres möglich jeden Teilnehmer eine ”feste” IP-Adresse
zuzuordnen. Zum einen, weil dazu die Adressen nicht ausreichen, andererseits aus Mobilitätsgründen (ein Nutzer des Internets ist nicht immer am gleichen Ort). Viele Nutzer
des Internets wissen mit dem Begriff ”IP-Adresse” auch nichts anzufangen. Wie sie ihre
117
aktuelle IP-Adresse ermitteln, wissen auch die wenigsten.
Im Moment gibt es eine Reihe von Lösungsansätzen, was die Adressierung / das Erreichen von Teilnehmern in VoIP-Netzen betrifft ([77]):
• Adresse bei SIP-Provider
Für die Kommunikation von Nutzer nur über das Internet (reine Internettelefonie). Beispiel: [email protected]
• Herkömmliche Ortsrufnummern
Anrufe auf diese herkömmlichen Ortsrufnummern, werden an entsprechenden
Nutzer/VoIP-Telefone, via PSTN-VoIP-Gateways weitergeleitet.
In Abschnitt 9.3.5.1 wird SIPGATE als ein VoIP-Provider in das aufzubauende VoIP-Netz integriert. Durch Sipgate werden 2 ”Adressen” zur Verfügung gestellt: Eine herkömmliche Ortsrufnummer (03677/799026) und eine SIP-Adresse
im Format [email protected], unter welche der Nutzer erreichbar ist!
• ENUM-Verfahren
Mehr dazu in Abschnitt 4.6.1.
• Spezielle Internet-Rufnummern
Zuweisen von Rufnummern aus dem ”032”-Rufnummernblock ([9]).
4.6.1 Das ENUM-Verfahren
ENUM steht für Telephone Number Mapping (”Telefonnummernabbildung”), einem
Protokoll zur Integration des klassischen Telefonnummernsystems in das Domain Name System (veröffentlicht im RFC 3761). Entwickelt wurde ENUM von der ENUM
Working Group, einer offiziellen Arbeitsgruppe der IETF und ist ein wichtiges Element für die Verbindung von klassischem Telefonnetz mit dem Internet (VoIP). In der
ENUM-Schreibweise wird nun die gesamte, in internationaler Schreibweise vorliegende
Telefonnummer umgekehrt (vor der Landesvorwahl jegliche landestypische Kennzahl
weggelassen, ”00” oder ”+”) und an die Arpa-Subdomain ”.164.arpa” angehangen :
Aus +4936771234 wird 4321776394.e164.arpa.
Eine Adresse in einem solchen Format kann problemlos in das DNS (Domain Name
System) integriert werden.
”Um ENUM-Einträge in das bestehende Domain Name System zu integrieren, wird ein
besonderer Eintragstyp verwendet, der so genannte NAPTR-Eintrag (Naming Authority Pointer). NAPTR-Einträge werden dazu genutzt, um eine DNS-Adresse zu einem
118
anderen Adresstyp umzuschreiben. Im Falle von ENUM wird ein NAPTR-Eintrag dazu
verwendet, eine Telefonnummer in ENUM-Schreibweise zu einer Adresse umzuwandeln,
die zu einem Rechner zeigt, auf dem eine Telefonieanwendung läuft.” (zitiert von [85])
Ein NAPTR-DNS-Eintrag kann folgendermaßen aussehen:
Abbildung 4.3: Aufbau eines ENUM-DNS-Eintrages
Wird eine Telefonnummer gewählt, hinter welcher sich ein Nutzer im Internet verbirgt,
wird von ENUM-unterstützenden Endgeräten eine DNS-Anfrage durchgeführt. Existiert ein entsprechender ENUM-Eintrag, beginnt die Auflösung der Adresse. In diesem
Fall steht hinter der Telefonnummer eine SIP-Adresse, unter welcher der Nutzer erreicht werden kann.
Für weitere Informationen zu ENUN, sind folgende Internetadressen ein guter Einstiegspunkt: [85], [22]
Fazit
Wie leicht zu erkennen ist, gibt es keine allgemein gültige Lösung für das Problem der
Adressierung in VoIP-Netzen.
Aus Nutzersicht wird in (lokalen) VoIP-Unternehmensnetzen wie gehabt mit internen
Durchwahlen gearbeitet, für die Kommunikation ins öffentliche Festnetz wird entsprechende Festnetznummer gewählt. ”Skype” (3.6),aber auch Netzwerke wie ”ICQ”, gehen einen anderen Weg der Adressierung von Teilnehmern. Mitglieder im Netzwerk
bekommen eine eindeutige Nummer, über welche sie erreichbar sind. Die eigentliche
Adressierung auf IP-Ebene übernimmt das (Skype-)Netzwerk.
119
4.7 Notrufe
Mit einem Notruf wird in einem Notfall professionelle Hilfe (Polizei, Feuerwehr, Rettungsdienste) alarmiert. Ein Notruf kann über verschiedenen Kommunikationskanäle
abgesetzt werden, in der Regel kostenlos.
In allen Staaten der EU sowie in Kroatien, Island, Liechtenstein, Norwegen und der
Schweiz gilt die Notrufnummer 112. In den USA sind die Notrufzentralen über die
”911” erreichbar.
Notrufe in öffentlichen Netzen
Bei Notrufen in öffentlichen Netzen wird immer die Rufnummer übertragen, aus welcher sich Rückschlüsse auf den Aufenthaltsort der Anrufenden ziehen lassen, weil zu
jeder Leitung - und damit Rufnummer - ein Port in der Vermittlungsstelle zugeordnet
ist. ([75])
Werden mittels Mobiltelefon Notrufe abgesetzt, kann bei Bedarf der aktuelle Aufenthaltsort mit Hilfe der Netzbetreiber ungefähr ermittelt werden. Ungefähr deshalb, weil
nur die Funkzelle bestimmt werden kann, in welcher sich der Teilnehmer befindet. Diese
Funkzellen haben allerdings unterschiedliche Dimensionen: In Städten haben Funkzellen eine weitaus geringere Größe (bedingt durch höhere Nutzerzahlen) als auf dem
Land, wo Funkzellen durchaus einen Durchmesser von mehreren Kilometern haben
können!
Notrufe in VoIP-Netzen
Bei VoIP ist der Sachverhalt ein anderer: Jeder Nutzer ist in der Lage, sich von einem
beliebigen Standort, mit Anschluss an das Internet, in ein VoIP-Netzwerk einzuklinken oder sich mit seinem VoIP-Provider zu verbinden. Dies wird auch als ”nomadische
Nutzung” bezeichnet, da Nutzer wie Nomaden relativ ortsungebunden sind!
Gerade diese ”nomadische Nutzung” macht die Ortung schwierig, aus einer IP-Adresse
den Aufenthaltsort zu bestimmen, weshalb einige VoIP-Provider diese kurzerhand verbieten (beispielsweise www.dus.net). Erschwerend kommt hinzu, dass viele Adressen
dynamisch vergeben werden und nur für eine ”Session” gültig sind, d.h. die Adresse
gehört nur solange zum Nutzer, wie dieser online ist. Diese dynamischen Adressen
werden durch die jeweiligen Provider vergeben und verwaltet, nur diese wissen, welcher Anschluss sich im Augenblick hinter einer IP-Adresse verbirgt. Da Internet- und
VoIP-Provider meist unterschiedlich sind und für ein VoIP-Gespräch nur die IP-, nicht
aber die tatsächliche Adresse nötig ist, ist eine Ortung innerhalb gewisser zeitlicher
120
Grenzen schier unmöglich.
Folgende Aussage zum Thema Notruf ist beim VoIP-Provider ”Sipgate” zu finden:
Die Notrufnummern 110 und 112 können über sipgate erreicht werden. Diese sind für
Ihre hinterlegte Adresse aktiviert (siehe in sipgate Account Einstellungen/Persönliche
Daten). (www.sipgate.de/user/emergency call.php)
Ein Lösungsansatz für die Problemstellung ”Notrufe in VoIP” wird derzeit von der
IETF erarbeitet:
Der Ansatz besiert auf dem ECRIT-Protokoll (ECRIT=Emergency Context Resolution with Internet Technologies), bei welchem die Endgeräte selbstständig ihre Position bestimmen sollen. Dazu werden Location Information Server (LIS) eingerichtet,
welche die IP-Adressräume aller Netzanbieter und die physikalischen Standorte der
Anschlüsse mit den zugehörigen IP-Adressen enthalten. In entsprechenden Tabellen
von DNS-Servern werden die zuständigen Notrufstellen vermerkt, die dem Anschluss
geographisch am nächsten gelegen sind. ([75]). Dieses System ähnelt dem ”NENA” (National Emergency Number Accociation) in den USA.
Weiterführende Informationen:
ECRIT:
http://www.ietf.org/html.charters/ecrit-charter.html
NENA (National Emergency Number Accociation):
http://www.nena.org/
Notrufe auf Basis von SIP:
http://tools.ietf.org/id/draft-schulzrinne-sipping-sos-04.txt
5 Konzepte
121
5 Konzepte
VoIP-Netze können in verschiedensten Ausprägungen vorkommen. Entsprechend der
Anforderungen kann ein VoIP-Netz, hinsichtlich Aufgaben, Struktur und der integrierten Komponenten, entsprechend an die Bedürfnisse angepasst werden.
In den folgenden Abschnitten werden einige der häufigsten Szenarien vorgestellt.
5.1 SOHO - Small Office / Home Office
Dieses Einsatzszenario beschreibt ein kleines VoIP-Netz für Heimarbeitsplätze oder
kleine Firmen mit wenigen Mitarbeitern. Die Abkürzung SOHO steht für ”Home Office
Small Office” und bedeutet soviel wie ”Büro zu Hause” oder ”kleines Büro”.
In diesem Szenario verfügt das Heimnetz über einen Breitbandinternetanschluss (DSL)
und über einen ISDN-Anschluss. Die IP-PBX ist durch eine gesicherte Verbindung
(Verschlüsselung der Signalisierungs- und der Sprachdaten, getunnelte Verbindung)
Abbildung 5.1: Aufbau eines SOHO
5 Konzepte
122
über das Internet an die IP-Telefonanlage des Unternehmens angebunden (Szenario
”Home Office”). Alternativ kann anstatt eines Unternehmensnetzes auch ein VoIPProvider über das Internet angebunden sein (Szenario ”Small Office”).
Das Gateway zum Internet ist der DSL-Router, zum öffentlichen Telefonnetz stellt eine
ISDN-Karte die Verbindung her. Telefoniert wird via VoIP, als Fallback-Lösung dient
der ISDN-Anschluss.
Ein wichtiges Element in diesem Konzept (wie in jedem IT-Konzept auch) stellt die
Firewall dar, welche für zusätzliche Sicherheit sorgt! Als Endgeräte in diesem Netz
dienen herkömmliche ISDN-Telefone, IP-Telefone aber auch Softphones.
5.2 Unternehmensnetz mit Anbindung an das PSTN
Im Gegensatz zur SOHO-Lösung, dienen die in diesem Abschnitt vorgestellten Lösungen für kleinere bis mittlere Unternehmen.
Der wichtigste Bestandteil ist dabei eine VoIP-PBX. In Abschnitte 5.2.1 ist dies durch
eine LAN-PBX realisiert, in Abschnitt 5.2.2 durch eine Software-PBX. Beide Realisierungen bieten die gleiche Funktionalität, unterscheiden sich aber leicht: Während
eine LAN-PBX eine herkömmliche TK-Anlage mit LAN-Anschluss darstellt, ist eine
Soft-PBX eine auf einem PC installierte PBX-Software.
Im Szenario 5.2.3 ist die VoIP-PBX aus dem eigenen Netz zu einem professionellen
VoIP-Provider ausgegliedert!
5.2.1 Realisierung mit einer LAN-PBX
Hauptbestandteil dieses Netzes ist eine ”LAN-PBX”. Eine LAN-PBX, oft auch als
”hybride TK-Anlage” bezeichnet, ist eine herkömmliche Telefonanlage mit zusätzlich
integrierter LAN-Schnittstelle (LAN = Local Area Network).
Über die LAN-Schnittstelle wird die Verbindung zum internen IP-Netz hergestellt; ein
Zugang zum öffentlichen Telefonnetz ist durch vorhandene ISDN-Anschlüsse gewährleistet.
Eine LAN-PBX ermöglicht den Parallelbetrieb von leitungsvermittelten Geräten (herkömmliche Telefone und Faxe) und IP-basierenden Endgeräten.
Häufig eingesetzt werden LAN-PBXs in Migrationsumgebungen, wo die Umstellung
auf VoIP schrittweise erfolgt, oder die vorhandene (leitungsvermittelte) Infrastruktur
beibehalten werden soll ([53]).
5 Konzepte
123
Abbildung 5.2: Unternehmensnetz mit einer LAN-PBX
Bestandteile eines solchen Netzes sind:
• IP-Telefone (Hardphones) oder PCs mit Softwareclient (Softphones)
• digitale Telefone und Faxe
• analoge Endgeräte, eingebunden via Terminaladapter
• Gateways (ISDN-Karten)
Nachteile einer LAN-PBX liegen in der relativ beschränkten Skalierbarkeit und Funktionalität.
5 Konzepte
124
5.2.2 Realisierung mit einer Software-PBX
In diesem Szenario liegt, im Vergleich zu 5.2.1, der Hauptunterschied im Einsatz einer
Soft-PBX anstelle einer LAN-PBX. Eine Soft-PBX (Software PBX) übernimmt die
Aufgaben einer TK-Anlage und wird als Anwendung auf einem entsprechend dimensionierten Server installiert (vgl. Kapitel 6).
Telefoniert wird intern über IP, die Kommunikation nach draußen wird über Schnittstellen zum öffentlichen Telefonnetz realisiert.
Eine Soft-PBX kommt häufig dann zum Einsatz, wenn:
• eine bestehende IT/TK-Infrastruktur komplett ersetzt werden soll oder
• bei einer ”Greenfield Installation”, bei welcher auf vorhandene Infrastruktur keine
Rücksicht genommen werden muss, zum Beispiel bei der (Erst-)Einrichtung eines
IT/TK-Netzes
Die klassische Telefonieumgebung wird vollständig ersetzt, IP-Telefone und Softphones kommen zum Einsatz. Analoge Endgeräte können durch wie in 5.2.1 durch einen
Terminaladapter eingebunden werden.
Abbildung 5.3: Unternehmensnetz mit einer Software-PBX
5 Konzepte
125
Ein Vorteil einer Soft-PBX ist die einfache Erweiterung des Funktionsumfangs durch
zusätzliche Anwendungen und Dienste. Dabei tritt kein Medienbruch auf, da Clients,
genau wie die Soft-PBX, über IP kommunizieren!
5.2.3 Hosted-PBX
”Hosted-PBX” bedeutet soviel ”betreute private Telefonanlage” und steht für die Auslagerung der TK-Anlage zu einem Provider, welcher zusätzlich dazu, die Dienste Internet
und Telefonie zur Verfügung stellt. Beim Einsatz einer ”Hosted-PBX” wird somit auf
eine eigene TK-Anlage verzichtet. Der Provider stellt alle Leistungsmerkmale zur Verfügung, die über das IP-Telefon bedient werden können. ”Das Prinzip ähnelt einer
Webhosting-Lösung, bei der der Webserver bei einem Provider steht. Der Kunde muss
dabei keinen eigenen Server betreiben. Das übernimmt der Provider. Der bedient mit
einem System gleich mehrere Kunden, genauso wie beim ”Shared Webhosting”.” ([50])
Ein Nachteil einer solchen Lösung ist die Abhängigkeit von der Internetverbindung:
Ohne Internetanschluss auch kein Telefon! Dies betrifft auch interne Gespräche, da die
Signalisierung komplett über die gehostete PBX abgewickelt wird.
Die eigentliche Sprachdatenübertragung findet allerdings direkt zwischen den Teilnehmern statt.
Abbildung 5.4: Hosted-PBX - Auslagern der Telefonanlage zu einem Provider
Wie in Abbildung 5.4 zu erkennen ist, ist das Unternehmensnetz auf 2 Filialen aufgeteilt. Beide Filialen verfügen über ein eigenes IP-LAN mit breitbandiger Internetanbindung. Über das Internet wird die vom Provider gehostete PBX erreicht (sichere
5 Konzepte
126
Verbindung, getunnelt) welcher auch ein Gateway zum öffentlichen Telefonnetz anbietet. Im Netz des Providers sind natürlich bedeutend mehr Komponenten existent, als
in der Grafik abgebildet.
Um einem Ausfall der Kommunikation zu begegnen, sollten entsprechende FallbackLösungen in Betracht gezogen werden, beispielsweise durch ISDN-Anschlüsse.
5.2.4 Vergleich LAN-, Soft- und Hosted-PBX
LAN-PBX
• Vorteile:
– Integration in bestehendes Netz
• Nachteile:
– Skalierbarkeit und Funktionalität
Soft-PBX
• Vorteile:
– Skalierbarkeit
– Implementierung neuer Dienste und Anwendungen
– Konfiguration via Browser
• Nachteile:
– neue Hardware nötig (Telefone, Terminaladapter)
– entsprechendes Knowhow (bei Eigeninstallation und -Administration)
Hosted-PBX
• Vorteile:
– Sicherheit, Zuverlässig, Kostentransparenz
– Komplette Wartung durch Provider
• Nachteile:
– Abhängigkeit vom Internetanschluss
– Verzögerung (Delay), aufgrund der Entfernung zur PBX
5 Konzepte
127
5.3 Unternehmensnetz mit verteilten Niederlassungen
In diesen Szenarien wird ein Unternehmen mit mehreren verteilten Niederlassungen
betrachtet. Zielgruppen sind dabei mittlere bis große Unternehmen.
Angeschlossen an das firmeninterne Kommunikationsnetz sind nicht nur Niederlassungen oder Filialen in anderen Städten, sondern auch Heimarbeitsplätze.
5.3.1 Unternehmensnetz mit zentraler Telefonanlage
Die Struktur in diesem Szenario ähnelt dem Szenario ”Hosted-PBX” (5.2.3): In der
Unternehmenszentrale ist die VoIP-Anlage angesiedelt, welche dort administriert und
gewartet wird - die Niederlassungen verfügen über keine eigenen VoIP-Anlagen. Das
Hosten und Warten der Anlage wurde in Abschnitt 5.2.3 durch einen externen VoIPProvider übernommen.
Die verschiedenen Niederlassungen sind über das IP-WAN (gesicherte, getunnelte Verbindungen) an die Zentrale angebunden. Alle Verbindungen zwischen Mitarbeitern und
auch Gespräche in das öffentliche Netz laufen über die Zentrale (Verbindungsaufbau)!
Abbildung 5.5: Firmenzentrale und Niederlassungen mit zentraler Anlage
Wie auch im Szenario ”Hosted-PBX” bedeutet ein Ausfall der Verbindung zur Zentrale, oder der VoIP-Anlage selbst, einen Komplettausfall der Kommunikation. Zusätzlich
dazu wirkt sich der Kostenaspekt negativ auf dieses Szenario aus: Aus einen ”Ortsgespräch” wird durch das Routen über die Zentrale (dortiger Zugang zum PSTN) ein
teureres Ferngespräch!
5 Konzepte
128
Abbildung 5.6: Firmenzentrale und Niederlassungen mit eigenen Anlagen
5.3.2 Unternehmensnetz mit verteilten VoIP-Anlagen
Die 2 Hauptnachteile im Szenario 5.3.1 (Abhängigkeit von der Verbindung zur Zentrale,
Kostenfaktor bei Ortsgesprächen) lassen sich durch einfache Maßnahmen ausgleichen!
Dazu wird, in diesem Szenario, jede Filiale mit einer eigenen VoIP-Anlage ausgestattet. Zusätzlich dazu erhalten alle Filialen eine eigene Anbindung an das PSTN (ISDNAnschlüsse). Alle VoIP-Anlagen sind untereinander durch sichere Verbindungen verbunden und verfügen über einen gemeinsamen Wählplan. Dieser Wählplan ermöglicht
gezieltes Routen von Gesprächen und wird ständig unter allen VoIP-Anlagen synchronisiert. Jeder Teilnehmer ist über eine Durchwahl erreichbar, egal an welchem Standort
er sich befindet - die Durchwahlen sollten Aufschluss darüber geben. Teilnehmer am
Standort A erhalten Durchwahlen im Format ”1XX”, Teilnehmer am Standort B die
Durchwahlen beginnend mit ”2XX”, usw.
Durch die eigene VoIP-Anlage in jeder Zentrale sind jederzeit standortinterne Gespräche möglich, sogar beim Ausfall der Internetverbindung. Bei Telefonaten in das
öffentliche Telefonnetz kann über das IP-Netz der geeignete Standort zum Übergang
in das öffentliche Telefonnetz gewählt werden. Dies erfordert allerdings ein genaues
Definieren solcher Wählplanregeln.
5 Konzepte
129
5.4 VoIP aus Providersicht
Alle bisher vorgestellten Einsatzszenarien für VoIP-Umgebungen sind Szenarien aus
der Sicht von Nutzern und Endkunden. Sie dienen dabei beispielsweise dem Zweck, die
Kommunikation innerhalb und zwischen Teilen eines Unternehmens zu gewährleisten.
Dabei kommt meist eine eigene VoIP-Infrastruktur zum Einsatz.
VoIP-Provider hingegen sind Anbieter solcher Dienstleistungen. In Abschnitt 5.2.3
wurde der Einsatz einer Hosted-PBX vorgestellt. Dies ist ein Szenario, bei dem der
VoIP-Dienst vollständig von einem VoIP-Provider erbracht und durch das jeweilige
Unternehmen in Anspruch genommen wird.
Dieser Abschnitt beschäftigt sich mit dem Aspekt des Erbringens und Anbieten von
VoIP-Diensten zu kommerziellen Zwecken. Für beliebige Nutzer wird ein Zugang zur
Verfügung gestellt, zusätzlich dazu bietet ein Provider ein Gateway ins öffentliche Festnetz an. Zu einem Nutzeraccount gehört eine SIP- und eine Festnetzrufnummer. Über
die Festnetznummer ist der Nutzer dann vom öffentlichen Telefonnetz, über die SIPRufnummer über das Internet, aus erreichbar. Das Routing zwischen beiden Rufnummern übernimmt der Provider!
Was macht einen VoIP-Provider aus?
Nach der Einrichtung eines eigenen Netzes (wie in Kapitel 6 beschrieben), kann eigentlich jeder als Anbieter eines VoIP-Dienstes agieren. Was bei einigen wenigen Nutzern
vielleicht noch ganz gut funktioniert, wird bei einer größeren Nutzeranzahl und entsprechend gestiegener Anforderungen mit ”herkömmlichen” Mitteln unmöglich.
Abbildung 5.7: Infrastruktur eines VoIP-Providers
5 Konzepte
130
Ein VoIP-Provider hingegen bietet einer sehr großen Anzahl von Nutzern seine Dienste
an. Dies geht meist über die reine VoIP-Telefonie hinaus, Zusatzdienste, wie das Anbieten von Gateways in das öffentliche Telefonnetz, werden von den Nutzern gefordert.
Das Nutzen dieser Zusatzdienste muss beim Provider auch entsprechend erfasst und
abgerechnet werden.
Allein daraus ergeben sich einige Anforderung an VoIP-Provider, aus welchen sich eine
geforderte IT-Infrastruktur ableiten lässt:
große Anzahl von Nutzern
• große Übertragungskapazitäten (Internet)
Die Anbindung des Providers an das Internet muss sehr hohe Übertragungskapazitäten zur Verfügung stellen. Eine redundante Anbindung über mehrere Carrier
(mehrere Gateways zum Internet) wird empfohlen und schafft zusätzlich eine
Reduzierung von Ausfallrisiken!
• große Übertragungskapazitäten (öffentliches Telefonnetz)
Da ein VoIP-Provider für alle Nutzer auch Gateways zum öffentlichen Telefonnetz zur Verfügung stellt, müssen auch diese über entsprechende Kapazitäten
verfügen! Eine Möglichkeit bieten ISDN-Primärmultiplexanschlüsse, allerdings
kann der VoIP-Provider durchaus auf Angebote anderer Provider zurückgreifen,
indem Gespräche ins Festnetz über andere Provider geroutet werden (allerdings
unter Einhaltung definierter QoS-Regelungen)!
• redundante VoIP-Server
VoIP-Server sind das Herz eines VoIP-Netzes. Um eine gewisse Verfügbarkeit zu
gewährleisten, ist es nötig diese Komponenten redundant auszulegen, d.h. mehrere VoIP-Server laufen parallel. Dies sorgt für eine Lastverteilung, ermöglicht
Skalierbarkeit, schafft Redundanz und bietet somit eine erhöhte Ausfallsicherheit.
Anbieten von Diensten
Zusätzlich zur großen Anzahl von Nutzern, werden Mehrwertdienste gefordert. Mehrwertdienste, angeboten durch VoIP-Provider, sind beispielsweise ein Anrufbeantworter
(Voicemail) oder ein Faxdienst. Diese Dienste müssen durch den Provider bereitgestellt,
die Nutzung erfasst und abgerechnet werden.
Dafür sind zusätzliche Komponenten nötig, welche ebenfalls in ein Sicherheitskonzept
(Ausfallsicherheit, Redundanz) integriert werden müssen.
5 Konzepte
131
• Application Server
Application Server stellen die verschiedenen Dienste zur Verfügung. Um eine
gewisse Verfügbarkeit der Dienste zu gewährleisten müssen diese ebenfalls redundant ausgelegt sein.
• Billing Server
Ein Billing Server ist mit das wichtigste Bestandteil im Netz des Providers. Er
erfasst und speichert die Verbindungsdaten, welche die Basis für die Abrechnung
der genutzten Dienste sind.
Sicherheit und NAT
VoIP-Kommunikation ist bei unzureichender Absicherung leicht zu kompromittieren
(siehe 4.3), weshalb ein gewisser Sicherheitsstandard geboten werden muss. Damit
wird Leistungsmissbrauch oder das Abhören der Kommunikation vermieden.
Ein Problem welches sehr häufig auftritt ist, dass sich Nutzer hinter einem NATRouter befinden (3.3). Auf diese Problematik muss unbedingt Rücksicht genommen
werden und entsprechende STUN/TURN-Server in das Netz integriert werden.
• Security Server
Realisieren die Verschlüsselung der Datenströme (Signalisierung und Sprachdaten) oder Bereitstellen von Tunneln für die Verbindungen. Allerdings muss der
Nutzer über Endgeräte verfügen, die diese Maßnahmen unterstützen.
• STUN/TURN
Komponenten zur Lösung der NAT-Problematik (3.3).
Fazit
Diese vorgestellten Komponenten bieten ein Grundgerüst für den Betrieb eine VoIPNetzes aus Sicht eines Providers. Aufbauend auf diesem Grundgerüst können beliebige
weitere Komponenten oder Funktionen implementiert werden.
Eine Funktion ist beispielsweise die automatische Codec-Anpassung an die verfügbare
Datenrate oder die Implementierung einer Klick-to-Dial-Funktion. Bei der Klick-toDial-Funktion kann ein Nutzer einen automatischen Rückruf, beispielsweise von einem
Unternehmen, durch Anklicken eines entsprechenden Buttons auf einer Webseite anfordern.
Eine weitere Maßnahme zur Performancesteigerung ist die Trennung von Signalisierungs- und Sprachinformationen: Signalisierungsgateways übernehmen die Umsetzung
und Weiterleitung der Signalisierungsinformationen, Mediagateways die Weiterleitung
und Umkodierung der Sprachdaten!
132
6 Einrichten eines VoIP-Netzes auf
Basis von ”Asterisk”
In den vorherigen Kapiteln sind theoretische Aspekte, Grundlagen und technische Prinzipien von VoIP vorgestellt worden. Dieses Kapitel beschäftigt sich im Gegensatz dazu,
mit dem Aufbau eines eigenen VoIP-Netzes auf Basis von Debian (Betriebssystem auf
Linux-Basis), der Software-PBX ”Asterisk” und der grafischen Oberfläche ”FreePBX”
für die Administration über einen Webbrowser.
Das aufzubauende Netz soll interne Kommunikation auf Basis des SIP-Protokolls, die
Kommunikation in andere Netze und verschiedenste Dienste bieten.
Die Anbindung an andere Netze wird zum einen durch eine vorhandene ISDN-Karte
(Anbindung an das öffentliche Telefonnetz) ermöglicht, andere VoIP-Netze hingegen
sind über das Internet angebunden.
Vor dem Aufbau des Netzes muss ein entsprechend dimensionierter Server ausgewählt
werden. Die Entwickler von ”Asterisk” geben dazu folgende Empfehlung ([46]) aus:
Abbildung 6.1: Hardwaredimensionierung
Im Rahmen dieser Dokumentation kommt ein Rechner mit einem 1GHz-Prozessor und
512MB Arbeitsspeicher zum Einsatz!
133
6.1 Das Einrichten des Grundsystems
Nach der Auswahl eines entsprechend dimensionierten Servers für das auszubauende
Netz, wird auf diesem die benötigte Software installiert und die ISDN-Karte in das
System eingebunden.
Folgende Kapitel im Anhang dokumentieren den gesamten Installationsverlauf:
• Installation des Betriebssystems (9.3.1.1)
• Integrieren der ISDN-Karte (9.3.1.2) und (9.3.2.1)
• Einrichten und Konfigurieren eines Mail Transfer Agents (9.3.1.3)
• Installieren der Software-PBX ”Asterisk” (9.3.2)
• Installieren und Einrichten der grafischen Oberfläche ”FreePBX” (9.3.3)
Mit dem Einrichten der grafischen Oberfläche ”FreePBX” sind die Vorarbeiten, also
das Installieren des Servers, abgeschlossen. In den nächsten Schritten wird der Server
eingerichtet.
Die Konfiguration von ”Asterisk” erfolgt normalerweise durch das Anpassen einfacher
Konfigurationsdateien im Ordner ”/etc/asterisk”. Im Rahmen dieser Dokumentation übernimmt ”FreePBX” diese Aufgabe: Alle Einstellung lassen sich leicht in der
grafischen Oberfläche durchführen!
6.2 Benutzerprofile und Kommunikationskanäle
Um verschiedenen Nutzern die Kommunikation über diesen Server zu gestatten, müssen entsprechende Nutzerprofile angelegt werden. Dabei werden wichtige Dinge wie
Rufnummern festgelegt!
• Einrichten von Nutzern auf Basis des SIP-Protokolls (9.3.4)
Der nächste Schritt ist die Anbindung an andere Netze (9.3.5):
• Einbinden eines VoIP-Providers auf Basis von SIP (9.3.5.1)
• Anbindung an das öffentliche Telefonnetz via ISDN (9.3.5.2)
134
6.3 Das Einrichten von Diensten
In den beiden vorangegangenen Abschnitten wurden ein Grundsystem installiert und
eingerichtet, die Anbindung an andere Netze umgesetzt und auch Benutzerprofile angelegt. Mit diesen Schritten ist bereits ein funktionierendes System verfügbar, welches
eine gewisse Grundfunktionalität bietet: es kann bereits mit Hilfe des Systems telefoniert werden!
Aufbauend auf diesem Grundsystem folgt jetzt die Einrichtung verschiedener ergänzender Dienste (siehe 4.2). Die Implementierung von Diensten erfolgt durch das Installieren
von Modulen für FreePBX. Folgende Dienste wurden eingerichtet:
• Mailbox / Voicemail (9.3.6.1)
• Music on Hold (9.3.6.2)
• Halten, Makeln, und Transfer von Gesprächen (9.3.6.3)
• Telefonkonferenzen / Konferenzräume (9.3.6.4)
• Ring Groups, Parallelruf (9.3.6.5)
• Blacklist (9.3.6.6)
• Tag- und Nachtschaltung (9.3.6.7)
• Digitaler Sekretär - Voicemenü 9.3.6.8
• DND - Bitte nicht stören! (9.3.6.10)
• Queues - Warteschlangen (9.3.6.11)
• ”Follow Me” (9.3.6.12)
Dies ist nur eine Auswahl von integrierbaren Diensten. Durch den ”Modul Admin”
können jederzeit weitere Dienste in das Netz implementiert werden!
135
6.4 Updates
Eingespielte Updates sind ein wichtiges Element für ein sicheres System. Sie schließen
Sicherheitslücken, beheben Fehler und fügen neue Funktionen hinzu.
Update des Betriebssystems
Ein Vorteil des eingesetzten Debian-Betriebssystems ist der Paketmanager, welcher
sämtliche auf dem System installierte Software automatisch auf dem neuesten Stand
hält.
Die neuesten Updates können leicht über den Paketmanager installiert werden, oder
per Kommandozeile. Das Updaten installierter Software über die Kommandozeile wird
so durchgeführt:
Zuerst wird ein Update verfügbarer Pakete initialisiert:
”apt-get update”.
Anschließend wird durch den Befehl
”apt-get upgrade” ein Update aller Pakete durchgeführt (sofern neue Versionen verfügbar).
Update von Asterisk
Ein automatisches Update von Asterisk über den Paketmanager ist leider nicht möglich. Abhilfe schafft nur ein manuelles Update.
Weitere Informationen dazu sind hier zu finden:
http://users.pandora.be/Asterisk-PBX/UpdateAsterisk.htm
Update von FreePBX
Sobald ein Update von FreePBX oder seiner Module verfügbar ist, erfolgt eine automatische Benachrichtigung beim Aufrufen des ”FreePBX System Status” durch den
Webbrowser. Installiert werden diese Updates anschließend über den ”Modul Admin”.
136
Dieses Kapitel widmet sich den Möglichkeiten zum Management und zur Wartung
der in dieser Arbeit entstandenen VoIP-Umgebung. Zunächst werden die eingesetzten
Komponenten kurz beschrieben. Darauf folgend wird auf Werkzeuge eingegangen, die
für eine typische Test- bzw. Entwicklungsumgebung benötigt werden. Der letzte Teil
des Kapitels beschäftigt sich mit der Erweiterbarkeit der VoIP-Umgebung durch einen
Application Server.
Abbildung 7.1: grundlegender Aufbau der Management- und Entwicklungsumgebung
Die Basis der VoIP-Umgebung bildet ein Asterisk-Server. Dieser vereint alle notwendigen Netzelemente zur VoIP-Kommunikation unter einem Dach und kann bei Bedarf durch neue Software-Module erweitert werden. Zusätzlich laufen auf dem Server ein Webserver sowie ein Datenbanksystem. Diese werden für den Einsatz der verwendeten Managementanwendung ”FreePBX” benötigt. ”FreePBX” ist eine SoftwareTelefonanlage und setzt auf Asterisk auf. Dabei können über eine grafische Oberfläche
eine Vielfalt von Einstellungen an Asterisk vorgenommen und zum Teil auch überwacht
werden. ”FreePBX” bildet daher den Kern der Managementumgebung.
Zum Testen der VoIP-Umgebung kommt ein handelsüblicher PC bzw. Laptop zum
Einsatz. Dieser verfügt über einen Webbrowser zur Fernwartung des Asterisk-Systems
mit Hilfe von ”FreePBX”. Ausserdem sind eine Reihe von Softphones installiert um
mögliche Unterschiede festzustellen. An dieser Stelle sei gesagt, dass sich die geteste-
137
ten Softphones (Xlite, Wengophone, SJPhone) im Bezug auf VoIP nur im Umfang der
umgesetzten VoIP-Funktionen unterscheiden.
Neben dem Management und der Überwachung des Betriebs der VoIP-Umgebung
ist auch der Einsatz von Diagnosewerkzeugen zu Test- bzw. Entwicklungszwecken interessant.
Im Laufe dieser Arbeit wurden verschiedene Vertreter von Protokollanalyse-Software
getestet.
Protokollanalyse-Programme (auch ”Packet Sniffer” genannt) dienen der Überwachung
und Auswertung von Netzwerkverkehr. Dabei kann der gesamte Verkehr mitgeloggt
und analysiert werden. Je nach verwendeter Software gibt es unterschiedliche Darstellungs- und Analysearten.
Ein Großteil der nicht-kommerziellen Analysewerkzeuge basiert auf dem bereits 1998
entwickelten Ethereal, das nach einem Namenskonflikt seit 2006 unter dem Namen ”Wireshark” [82] weiterentwickelt wird. Vorteile von Ethereal sind unter anderem: dass es
unter der GNU General Public License veröffentlicht wurde und somit kostenlos ist,
die Verfügbarkeit für die gängigsten Betriebssyteme sowie der große Funktionsumfang.
”Packetyzer” [55] ist ein weiteres Programm, welches eine grafische Benutzeroberfläche und diverse Analysefunktionen zur Verfügung stellt, allerdings nur unter Microsoft
R
Windows.
Als Vertreter der kommerziellen Softwarelösungen seien an dieser Stelle noch die Produkte der Firmen ”WildPackets” [81] und ”Empirix” [14] genannt, welche zum Teil auch
auf Ethereal-Funktionen aufbauen.
Die Wahl des Netzwerkanalyseprogramms fiel letztlich auf ”Wireshark”, da das Programm ”Omnipeek” [81] von WildPackets zwar deutlich umfangreicher ist, aber nur
als zeitlich begrenzte Testversion zur Verfügung stand. Gleiches gilt für den ”Hammer
Call Analyzer” [14] von Empirix.
Durch den ”Boom”, den VoIP seit einigen Jahren erfährt, stieg auch das Bedürfnis
nach Komplettpaketen zur VoIP-Netzwerkanalyse. Neben den reinen Paketanalysefunktionen und der grafischen Auswertung der Pakete ermöglichen sie auch Funktionen zur Echtzeitkontrolle und -Überwachung von VoIP-Strömen. Dabei werden wichtige Parameter wie Übertragungsqualität, Jitter, Latenzzeit analysiert und dargestellt.
Auch kann die Netzwerktopologie überwacht und mögliche Probleme schnell eingegrenzt werden. Weitere Details der kommerziellen Lösungen sind den Internetseiten
der Hersteller zu entnehmen [81],[14].
138
Der beim Aufbau des im Zuge dieser Arbeit enstandenen VoIP-Netzes verwendete ”Wireshark” kann vom Umfang her nicht mit den kommerziellen Komplettpaketen
mithalten. Jedoch bietet er gerade zur VoIP-Analyse diverse Funktionen.
Das Hauptaugenmerk liegt dabei auf der Paket- und Protokollanalyse. Es können einzelne Netzwerkinterfaces überwacht werden und eine Auswahl an Protokollen auch
ausgewertet werden. In umfangreicheren VoIP-Umgebungen ist die Analyse einzelner
Verbindungen jedoch nicht ausreichend, hier empfiehlt sich ein Blick auf die bereits
genannten Komplettpakete.
Gerade für das in Abbildung 7.1 betrachtete Netz stellt Wireshark aber eine ganze Reihe an Funktionen zur Verfügung. Genaue Anleitungen zum Analysieren von
VoIP-Verbindungen oder z.B. RTP-Streams mit Hilfe von Wireshark sind unter [83]
zu finden. An dieser Stelle soll daher lediglich auf ausgewählte Funktionen anhand von
Screenshots eingegangen werden.
Abbildung 7.2: grafische Darstellung von VoIP-Verbindungen [76]
139
Abbildung 7.4: RTP-Stream Analyse (Hervorhebung von Übertragungsfehlern) [76]
Abbildung 7.3: RTP-Stream Überwachung (Latenz, Jitter usw.) [76]
Abbildung 7.5: VoIP-Verbindungsübersicht [83]
140
Abbildung 7.6: Abspielen von Mediendaten (z.B. RTP-Streams) [83]
Neben den vorgestellten Netzwerkanalysatoren gibt es noch weitere Programme, die
beim Analysieren und Überwachen behilflich sein können:
• Paketgeneratoren erlauben nicht nur das simulieren von Netzwerkverkehr und
VoIP-Verbindungen zur Analyse von Jitter, Latenz oder Paketverlusten; sie ermöglichen ausserdem Stresstests und sind daher auch im Bezug auf Quality of
Service und die Leistungsfähigkeit von Netzen sehr hilfreich.
• Überwachungs- und Testwerkzeuge kommen vor allem in Verbindung mit
Quality of Service zum Einsatz um Datenrate und Qualität von Verbindung zu
kontrollieren und zu verwalten.
141
• Netzwerksimulatoren können wie der Name schon sagt Netzwerke aber vor
allem auch Netzwerkausstörungen simulieren.
Ein Punkt, der im Bezug auf die Entwicklungsumgebung bisher noch nicht angesprochen wurde, ist das Entwickeln und Anbieten neuer VoIP-Dienste. Ein großer Vorteil
von VoIP gegenüber dem traditionellen PSTN ist ja die Erweiterbarkeit mit neuen
Diensten. Mit relativ geringerm Aufwand können Dienste geändert oder komplett neu
erstellt werden ohne dabei Änderungen an der Netzinfrastruktur vornehmen zu müssen.
7.1 Application Server
Dies wird möglich durch den Einsatz eines ”Application Server”. Grundsätzlich ist ein
Application Server ein Computer, auf dem Anwendungen ausgeführt werden können.
Im erweiterten Sinn kann ein Application Server aber auch eine Software sein, die
verschiedene Dienste ausführt. In beiden Fällen ist aber ein System gemeint, dass
es erlaubt Anwendungen bzw. Dienste auszulagern und nur bei Bedarf zu nutzen. Als
Beispiel wäre hier eine Zeit- oder Wetteransage über das Telefon denkbar. Dabei könnte
der Application Server die Anfrage nach dem morgigen Wetter oder der derzeitigen
Uhrzeit erhalten. Das beschaffen der gewünschten Daten übernimmt in diesem Fall
eine Anwendung oder ein Dienst. Das Ergebnis wird daraufhin zurückgeschickt bzw.
verfügbar gemacht und kann zum Initiator der Anfrage gesendet werden.
Zukünftige Dienste werden sich nicht mehr nur auf reine Telefonie beschränken. Im
Folgenden sind daher die prinzipiellen Anforderungen an diese und die Technik zu ihrer
Entwicklung und Bereitstellung aufgelistet [72]:
• Einfache, schnelle und kostengünstige Entwicklung und Bereitstellung von Diensten
• Multimedia-, Mehrwertdienste
• Neue Dienste, die z.B. in der ”alten” ISDN/GSM-Welt gar nicht möglich sind
• Verknüpfung von Sprach-, Bild-, Video- und Textkommunikation mit beliebigen
Daten
• Eigene Dienste für spezielle Nutzergruppen/einzelne Nutzer
• Mobilität
142
• Quality of Service
• Sicherheit
In einem NGN [2.5] werden bereits eine Reihe von Mehrwertdiensten mit Application
Servern bereitgestellt:
• Click-to-Dial
• E-Mail bei Anruf in Abwesenheit oder im Offline-Zustand
• Terminplaner mit telefonischer Benachrichtigung
• Televoting
• Location based Services wie z.B Restaurantsuche
• Steuerungen im Haushalt
Diese Auslagerung der Dienstintelligenz von den Vermittlungssystemen, den Call
Servern, auf separate Dienstplattformen, die SIP Application Server, führt beispielsweise im Vergleich mit ISDN und IN zu deutlich geringeren Abhängigkeiten zwischen
Netz und Diensten. Damit wird es sehr viel einfacher, schnell neue Dienste einzuführen
[4].
Ein SIP Application Server ist eine Kombination aus SIP User Agent, SIP Proxy
Server und/oder SIP Redirect Server sowie einer Software-Plattform für die Dienste.
Dieses logische Netzelement kann physikalisch als eigenständiger Server realisiert oder
auch in einem Call Server/Softswitch integriert sein. Mittels eines SIP Application Server können schnell und kostengünstig Dienste, speziell multimediale Mehrwertdienste,
aber auch Dienstmerkmale entwickelt und bereitgestellt werden [72].
Ein SIP Application Server besteht aus den folgenden wesentlichen Funktionen [34]
SIP-Schnittstelle zum NGN, zu Call Servern Initiierung und Terminierung von SIPund RTP-Sessions Vermittlung von SIP-Medien-Session-Parametern Steuerung eines
oder mehrerer Media-Server Datenschnittstelle, z.B Web-Oberfläche Application Programming Interface (API) für die Diensteentwicklung Software-Plattform für die Diensteentwicklung und -bereitstellung.
143
Aufruf anderer SIP Application Server, um aufbauend auf die von ihnen bereitgestellten Diensten komplexere Dienste zu realisieren Unterstützung der Protokolle SIP,
HTTP, XML, Diameter u.a. Schnittstellen zu Systemen für Authentifizierung (Authentication), Zugriffssteuerung (Autherization) und Erfassung von Rechnungsdaten
(Accounting), d.h. z.B. zu einem AAA-Server mittels des Diameter-Protokolls.
Praktisch sieht der Ablauf so aus, dass ein Call Server aufgrund von Filterkriterien,
SIP-Nachrichten bei Bedarf an einen geeigneten Application Server weiterleitet. Dieser
entscheidet daraufhin anhand eigener Filterkriterien welche Software für diesen Dienst
zuständig ist und startet die entsprechende Anwendung.
Als Beispiel nehmen wir nochmal die oben erwähnte Wetteransage. Vom Anrufer
wird die Anfrage an den ”Call Server” geleitet, dieser bemerkt die Zuständigkeit des
Application Servers und gibt die Anfrage weiter. Der Application Server versteht die
Anfrage und initiiert den Start einer Anwendung, die z.B die Wetterdaten von einer
Internetseite anfordert. Die in Textform erhaltenen Wetterinformationen könnte der
Application Server nun an einen Media Server leiten, der ein Text-to-Speech-Modul
nutzt und dem ursprünglichen Anrufer die Daten vorliest.
Für die Realisierung der Dienste mittels Software gibt es eine ganze Reihe unterschiedlich komplexer und unterschiedlich leistungsfähiger Möglichkeiten, wobei prinzipiell zwischen zwei Diensterealisierungen unterschieden wird [73]:
• Low Level API (setzt direkt auf dem Application Server auf): z.B. SIP Servlets,
CPL (Call Processing Language), SIP-CGI (CIP-Common Gateway Interface),
Scripting oder Software in C,C++, .NET oder Java, JAIN (lite) (Java APIs
for Integrated Networks), Proprietäre APIs wie z.B. Asterisk Gateway Interface
(AGI), Asterisk Management Interface (AMI)
• High Level API (setzt auf Middleware auf): OSA/Parlay (Open Service Architecture), CSE (CAMEL Service Environment), XML-RPC (Remote Procedure
Call), Web-Services, OMA OSE (Open Mobile Alliance OMA Service Environment)
Zusammenfassend lässt sich sagen, dass die Beschränkungen für Dienste mitlerweile
nicht mehr durch die technischen Möglichkeiten, sondern durch die Kreativität der
Entwickler gegeben sind.
LITERATURVERZEICHNIS
144
Literaturverzeichnis
[1] AVM: Firmware der AVM-B1 ISDN-Karte. URL: ftp://ftp.in-berlin.de/
pub/capi4linux/firmware/b1/3-11-03/b1.t4/.
[2] Badach, Anatol: Voice over IP - Die Technik. Carl Hanser Verlag München,
2004. Grundlagen und Protokoll für Multimedia-Kommunikation.
[3] Baset, Salman A. und Columbia University Henning Schulzrinne: An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. URL:http://www1.cs.columbia.edu/~library/TR-repository/reports/
reports-2004/cucs-039-04.pdf.
[4] Berg, Stefan: Das IP-Multimedia Subsystem - Enabler für ein neues Dienstezeitalter? Wird IMS erfüllen, was Intelligente Netze einst versprachen?, April
2006. Detecon Management Report.
[5] Bernet, Ford, Yavatkar: RFC 2998 - A Framework for Integrated Services Operation over DiffServ Networks. URL: http://www.apps.ietf.org/rfc/
rfc2998.html.
[6] Brandenburg, Prof.: Vorlesungsunterlagen ”Multimedia Standards”, TU Ilmenau, 2006.
[7] Brockhaus: Onlineartikel von Brockhaus. URL: http://www.brockhaus.de/
aktuell/thema.php?t_id=111&jahr=2006.
[8] Bryan, Lowekamp, Jennings: draft-bryan-sipping-p2p-03 - A P2P Approach
to SIP Registration and Resource Location (Work in Progress), October 2006.
IETF.
[9] Bundesnetzagentur: Nationale Teilnehmerrufnummern (NTR). URL:http:
//www.bundesnetzagentur.de/enid/Nummernverwaltung/NTR__32_1i3.html.
145
[10] C. Jennings, Ed., R. Mahy Ed.: Managing Client Initiated Connections in the Session Initiation Protocol (SIP). URL: http://www.ietf.org/
internet-drafts/draft-ietf-sip-outbound-13.txt, March 2008. IETF Internet Draft, work in progress.
[11] Camarillo, Gonzalo: SIP demystified, 2002. McGraw-Hill.
[12] Davidson, Jonathan: Voice over IP Grundlagen. Markt und Technik Verlag,
2000.
[13] Dresden, TU: Übersicht der gebräuchlichsten Videokonferenz-Normen. URL:
http://vcc.zih.tu-dresden.de/vc/grundlagen/normen.php, 2008.
[14] empirix: empirix. http://www.empirix.com/products-services/v-hca.asp.
[15] Franks, Hallam-Baker, Hostetler: RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication, June 1999. IETF.
[16] GmBH, Amooma: Deustsche Sprachbausteine für Asterisk 1.4.x. URL:http:
//www.amooma.de/asterisk/sprachbausteine/index.html.
[17] Haaß, Wolf-Dieter: Handbuch der Kommunikationsnetze. Springer Verlag,
1997.
[18] Henry Sinnreich, Alan B. Johnston: Internet Communications Using SIP.
Wiley Publishing, Inc., 2006. second edition.
[19] IEEE: IEEE Standards for Local and metropolitan area networks - Virtual
Bridged Local Area Networks. URL: http://standards.ieee.org/getieee802/
download/802.1Q-2003.pdf.
[20] IEFT: RTP: A Transport Protocol for Real-Time Applications. URL: http://
www.ietf.org/rfc/rfc1889, January 1996.
[21] IEFT: RTP Profile for Audio and Video Conferences with Minimal Control. URL:
http://www.ietf.org/rfc/rfc3551, July 2003.
[22] IETF: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM). URL:http://www.ietf.org/
rfc/rfc3761.txt.
[23] IETF: P2P. URL: http://tools.ietf.org/html/rfc5128.
146
[24] IETF: Point-to-Point Tunneling Protocol (PPTP). URL: http://tools.ietf.
org/html/rfc2637.
[25] IETF: Security Architecture for the Internet Protocol. URL: http://tools.
ietf.org/html/rfc2401.
[26] IETF: S/MIME Mail Security (smime).
charters/smime-charter.html.
[27] IETF: Transport Layer Security (tls).
charters/tls-charter.html.
URL:http://www.ietf.org/html.
URL: http://www.ietf.org/html.
[28] IETF: Real Time Streaming Protocol (RTSP). URL: http://www.ietf.org/
rfc/rfc2326, April 1998.
[29] IETF: RTP: A Transport Protocol for Real-Time Applications. URL: http://
www.ietf.org/rfc/rfc3550, July 2003.
[30] IETF: The Secure Real-time Transport Protocol (SRTP). URL: http://www.
ietf.org/rfc/rfc3711, March 2004.
[31] IETF: RTP Profile for Audio and Video Conferences with Minimal Control. URL:
http://www.ietf.org/rfc/rfc1890, January 2006.
[32] info.org www.voip: ITU G.711.
view/ITU+G.711.
URL:http://www.voip-info.org/wiki/
[33] Informationstechnik, Bundesamt für Sicherheit in der: VoIPSEC
- Studie zur Sicherheit von Voice over Internet Protocol.
URL: https:
//downloads.bsi-fuer-buerger.de/literat/studien/VoIP/voipsec.pdf,
2005.
[34] IPCC: IPCC: Reference Architecture, June 2002. IPCC, V 1.2.
[35] ITK-Steffens: VoIP-Codecs
itk-steffens.de/codecs.html.
und
Bandbreite.
URL:http://www.
[36] ITU: E.164 : The international public telecommunication numbering plan.
URL:http://www.itu.int/rec/T-REC-E.164/en.
[37] ITU-T: G.114 - One-way Transmission Time. URL: http://www.itu.int/
itudoc/itu-t/aap/sg12aap/history/g.114/index.html.
147
[38] ITU-T: Procedures for document facsimile transmission in the general switched
telephone network. URL: http://www.itu.int/rec/T-REC-T.30.
[39] ITU-T: Procedures for real-time Group 3 facsimile communication over IP networks. URL: www.itu.int/rec/T-REC-T.38.
[40] ITU-T: Procedures for the transfer of facsimile data via store-and-forward on the
Internet. URL: www.itu.int/rec/T-REC-T.37.
[41] ITU-T: Y.2001: General Overview of NGN, December 2004.
[42] ITU-T: ITU-T Recommendation H.323.
T-REC-H.323-200606-I/en, June 2006.
URL: http://www.itu.int/rec/
[43] J. Rosenberg, J. Weinberger, C. Huitema R. Mahy: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators
(NATs), March 2003. RF3489.
[44] J. Rosenberg, H. Schulzrinne: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. URL: http://www.ietf.org/rfc/
rfc3581.txt, August 2003.
[45] J. Rosenberg, R. Mahy, P. Matthews: Traversal Using Relay NAT
(TURN), February 2008. IETF Internet Draft, work in progress.
[46] Jim Van Meggelen, Leif Madsen: Asterisk - The Future of Telephnoy.
URL:http://downloads.oreilly.com/books/9780596510480.pdf.
[47] Johannes Schmitt, Ralf Ackermann, Manuel Görtz: VoIP-Sicherheit Status Quo und neue Aspekte. URL:ftp://ftp.kom.e-technik.tu-darmstadt.
de/pub/papers/SAGS06-1-paper.pdf.
[48] Kaufmann, Joachim: Das Phänomen Skype: Was wirklich dahinter steckt.
URL:http://www.zdnet.de/mobile/tkomm/0,39023192,39128812-1,00.htm,
2004.
[49] Köhler, Rolf-Dieter: Voice over IP. mitp-Verlag/Bonn, 2002.
[50] kompendium.de ://www.elektronik: IP-Centrex / Hosted PBX / Telefonanlage im Netz. URL: http://www.elektronik-kompendium.de/sites/kom/
1105021.htm.
148
[51] Lange, Paul: Entwicklung eines Maßnahmenkataloges und zugehörigem Prüfschema für die Absicherung von Voice over IP Installationen, December 2006.
Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH),
Fachhochschule Brandenburg.
[52] lightreading.com. URL: http://www.lightreading.com/document.asp?
site=testing&doc_id=53864&page_number=6, 2008.
[53] Nölle, Jochen: Voice over IP. VDE Verlag GmbH, Berlin und Offenbach, 2.
Auflage Auflage, 2005. Grundlagen, Protokolle, Migration.
[54] Olivier Hersent, Jean-Pierre Petit, David Gurle: IP Telephony. John
Wiley and Sons, Ltd, March 2005. Deploying Voice-over-IP Protocols.
[55] paglo. http://www.paglo.com/opensource/packetyzer.
[56] Prof. Jürgen Plate, FH München: Weitere Informationen zum Thema
ISDN. URL: http://www.netzmafia.de/skripten/telefon/isdn-a.html.
[57] Prof. Seitz, TU Ilmenau: http://www.tu-ilmenau.de/fakei/Folien-Planungund-V.8349.0.html. URL:http://zack1.e-technik.tu-ilmenau.de/~webkn/
lehre/Folien_PVK_wiwet/Kap06_SNMP_Prot.pdf.
[58] Project, The iLBCfreeware.org.
english/white_papers/iLBC.WP.pdf.
[59] Rohrbacher, Kai: GSM-Technik.
atzear/mf/gsmtechb.htm.
URL: www.gipscorp.com/files/
URL: http://home.arcor-online.de/
[60] Rosenberg, Schulzrinne, Camarillo: RFC 3261 - SIP: Session Initiation
Protocol, June 2002. IETF.
[61] Rosenberg, J.: Interactive Connectivity Establishment. URL: http://www.
isoc.org/tools/blogs/ietfjournal/?p=117, February 2007.
[62] Rosenberg, J.: Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal for Offer/Answer Protocols, October 2007. IETF Internet Draft, work in progress.
[63] Rosenberg, Schulzrinne: RFC 3264 - Session Initiation Protocol (SIP): Locating SIP Servers, June 2002. IETF.
149
[64] Schoblick, Robert: Euro-ISDN im praktischen Einsatz, Band 3. Franzis-Verlag
GmbH, 1996.
[65] Schott, Roland: Quality of Service in IP- und MPLS-Netzen. Telekommunikation Aktuell, 2002.
[66] Shim, Narayanan, Daley: draft-shim-sipping-p2p-arch-00 - An Architecture
for Peer-to-Peer Session Initiation Protocol (P2P SIP), February 2006. IETF.
[67] Siegmund, Gerd: Technik der Netze, Band 5. Hüthig GmbH und Co KG Heidelberg, 2002.
[68] Singh, Schulzinne, Henning: P2P-SIP - Peer to peer internet telephony using
SIP, June 2005. Columbia University New York.
[69] Speex: Webseite - www.speex.org. URL: http://http://www.speex.org/.
[70] switch.org www.soft: Faxing over IP networks. URL: www.soft-switch.
org/foip.html.
[71] Telekom, Deutsche: T-ISDN Handbuch. URL: http://hilfe.telekom.de/
dlp/eki/downloads/t/T-ISDN-HB05.pdf.
[72] Trick, Diehl, Fuhrmann: Application Server und Service Provisioning, November 2006. ITG-Workshop Zukunft der Netze, Bremen.
[73] Ulrich Trick, Frank Weber: SIP, TCP/IP und Telekommunikationsnetze.
Oldenburg, 2007.
[74] V.Jung, J.-J.Warnecke: Handbuch für die Telekommunikation. Springer, 1998.
[75] VoIP-info.de: Notruf mit VoIP.
_Artikel_Allgemein_2011.php.
URL:http://www.voip-info.de/wissen/
[76] Walberg, Sean: Expose VoIP Problems Using Wireshark. URL: http://www.
linuxjournal.com/article/9398, 2007.
[77] Wikipedia: Rufnummernsysteme.
IP-Telefonie#Rufnummernsysteme.
URL:http://de.wikipedia.org/wiki/
[78] wikipedia.org: Quality of Service. URL: http://de.wikipedia.org/wiki/
Quality_of_service.
150
[79] Wikipedia.org: Skype. URL:http://de.wikipedia.org/wiki/Skype.
[80] Wildau, Technische Fachhochschule: Euro-ISDN-Anschluß, Digitale Anschlüsse am öffentlichen T-Net. URL: http://www.tfh-wildau.de/tolkiehn/
material/euroisdn.pdf.
[81] wildpackets. http://www.wildpackets.com/.
[82] wireshark. http://www.wireshark.org/.
[83] Wireshark: VoIP Calls.
2008.
URL: http://wiki.wireshark.org/VoIP_calls,
[84] www.info.electronicwerkstatt.de, Webseite: Weitere Informationen
zum Thema ISDN. URL: http://info.electronicwerkstatt.de/bereiche/
uebertragung/telecom/isdn/isdn.html.
[85] www.netplanet.org: ENUM - Telefonnummern im Domain Name System.
URL:http://www.netplanet.org/adressierung/enum.shtml.
[86] www.protocols.com, Webseite: Weitere Informationen zum Thema ISDN.
URL: http://www.protocols.com/pbook/isdn.htm.
[87] www.voipange.de: H.323 / SIP. URL: http://www.voipango.de/index.php?
shp=1&cl=content&tpl=df14419788ec45166.11076348.
[88] www.Wikipedia.de: IDN - Integriertes Text- und Datennetz. URL: http://
de.wikipedia.org/wiki/Integriertes_Text-_und_Datennetz.
[89] www.Wikipedia.de: ISDN - Integrated Services Digital Network. URL: http:
//de.wikipedia.org/wiki/Integrated_Services_Digital_Network.
[90] www.Wikipedia.de: Signalisierung. URL: http://de.wikipedia.org/wiki/
Signalisierung#Signalisierung_in_der_Telekommunikation.
[91] www.Wikipedia.de: Telefonnetz.
Telefonnetz.
URL: http://de.wikipedia.org/wiki/
[92] www.wikipedia.org: Pheidippides. URL: http://de.wikipedia.org/wiki/
Pheidippides.
[93] www.zdnet.de: Fax over IP. URL: http://www.zdnet.de/mobile/tkomm/0,
39023192,39152201,00.htm.
151
152
3PTY
Three Party
A
ACK
AD
AES
AG
AKA
ALG
API
ANM
AOC
ARQ
AS
ATM
Acknowledgement
Abbreviated Dialling
Advanced Encryption Standard
Access Gateway
Authentication and Key Agreement
Application Layer Gateway
Application Programming Interface
Answer Message
Advice of Charge
Admission Request
Application Server
Asynchronous Transfer Mode
B
BG
Border Gateway
C
CCBS
CCITT
CCNR
CD
CBR
CFB
CFNR
CFU
CGI
CI
CLASS
CLIP
CLIR
CO
CONF
cRTP
CS
CT
CW
Completion of Calls to Busy Subscriber
Commité Consultatif Internationale Télégrafique et Téléfonique
Completion of Calls on No Reply
Call Deflection
Constant Bitrate
Call Forwarding Busy
Call Forwarding No Reply
Call Forwarding Unconditional
Common Gateway Interface
Call Intrusion
Customer Local Area Signalling Services
Calling Line Identification Presentation
Calling Line Identification Restriction
Call Offer
Conference
compressed RTP
Call Server
Call Transfer
Call Waiting
153
D
DDI
DIN
DND
DNDO
DNS
DoS
DS
DSCP
DSL
DTMF
Direct Dialling-IN
Deutsches Institut für Normung e.V.
Do not Disturb
Do Not Disturb Override
Domain Name Service
Denial of Service
Differentiated Services
Differentiated Services Code Point
Digital Subscriber Line
Dual Tone Multiple Frequency
E
ECRIT
ETSI
Emergency Context Resolution with Internet Technologies
European Telecommunications Standards Institute
F
FGNGN
FIN
FoIP
FPH
FTP
Focus Group on Next Generation Networks
Finish
Fax over Internet Protocol
Freephone
File Transfer Protocol
G
GSTN
General Switched Telephone Network
H
HTTP
HTTPS
HyperText Transfer Protocol
HTTP Security
I
ICE
ICID
ICMP
ID
IDN
IDS
IEEE
IETF
IKE
IM
IN
IP
Interactive Connectivity Establishment
Internet Caller-ID Delivery
Internet Control Message Protocol
Identification
Integriertes Text- und Datennetz
Intrusion Detection System
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Internet Key Exchange
Instant Messaging
Intelligent Network, Intelligentes Netz
Internet Protocol
154
IPv4
IPv6
IPsec
ISDN
ISP
ITU
ITU-T
Internet Protocol Version 4
Internet Protocol Version 6
Internet Protocol Security
Integrated Services Digital Network
Internet-Service-Provider
International Telecommunication Union
ITU-Telecommunications Standardizations Sector
J
JAIN
Java APIs for Integrated Networks
L
LAN
LDAP
LOC
LWL
Local Area Network
Lightweight Directory Access Protocol
Location
Lichtwellenleiter
M
MAC
MCID
MCU
MD5
Megaco
MFV
MGC
MGCF
MGCP
MGW
MIME
MO
MOH
MS
MTU
Message Authentication Code
Malicious Call Identification
Multipoint Control Unit
Message-Digest Algorithm 5
Media Gateway Control Protocol
Mehrfrequenzwahlverfahren
Media Gateway Controller
Media Gateway Control Function
Media Gateway Control Protocol
Media Gateway
Multipurpose Internet Mail Extension
Managed Object
Music on Hold
Media Server
Maximum Transmission Unit
N
NAPT
NAT
NENA
NGN
Network Address and Port Translation
Network Address Translation
National Emergency Number Accociation
Next Generation Networks
O
OAM
OSI
Operation, Administration and Maintenance
Open Systems Interconnection
155
P
P2P
PBX
PC
PCM
POP3
POTS
PPP
PPTP
PS
PSTN
Peer-to-Peer
Private Branch Exchange
Personal Computer
Pulse Code Modulation
Post Office Protocol Version 3
Plain Old Telephone Service
Point-to-Point Protocol
Point-to-Point Tunneling Protocol
Packet Switched
Public Switched Telephone Network
Q
QoS
Quality of Service
R
RAM
RSA
RST
RTP
Random Access Memory
Rivest, Shamir, Adleman
Reset
Real-time Transport Protocol
S
SBC
SBC-M
SBC-S
SCE
SCP
SCTP
SDP
SGW
SIP
SLA
SLS
SM
S/MIME
SMS
SMTP
SNMP
SRTCP
SRTP
SSH
SSL
SSP
STP
STUN
SYN
Session Border Controller
Session Border Controller-Media
Session Border Controller-Signaling
Service Creation Environment
Service Control Point
Stream Control Transmission Protocol
Service Delivery Protocol
Signaling Gateway
Session Initiation Protocol
Service Level Agreement
Service Level Specification
Session Management
Security Multipurpose Internet Mail Extension
Short Message Service
Simple Mail Transfer Protocol
Simple Network Management Protocol
Secure RTP Control Point
Secure RTP
Secure Shell
Secure Socket Layer
Service Switching Point
Signaling Transfer Protocol
Simple Traversal of UDP through NAT
Synchronization
156
T
TCP
TIFF
TK
TLS
ToS
TURN
TVSt
Transmission Control Protocol
Tagged Image File Format
Telekommunikation
Transport Layer Security
Type of Service
Traversal Using Relay NAT
Teilnehmervermittlungsstelle
U
u.a.
UA
UAC
UAS
UDP
UPnP
URI
URL
USV
unter anderem
User Agent
User Agent Client
User Agent Server
User Datagram Protocol
Universal Plug and Play
Uniform Ressource Identifier
Uniform Ressource Locator
Unterbrechungsfreie Stromversorgung
V
VLANs
VoIP
VPN
VSt
Virtual Local Area Networks
Voice over IP
Virtual Private Network, Virtuelles Privates Netz
Vermittlungsstelle
W
W3C
WAN
WLAN
WWW
World Wide Web Consortiums
Wide Area Network
Wireless LAN
World Wide Web
Z
ZGS
Zeichengabesystem
9 Anhang
157
9 Anhang
9 Anhang
158
9.1 Sprachcodecs
9.1.1 ITU-T G.711
G.711 ist der Großvater der digitalen Audiocodecs. Es ist ein von der ITU-T im
Jahre 1965 freigegebener Standard. Das Grundprinzip ist eine logarithmische A/DWandlung des analogen Signals mittels A-law (Europa) oder µ-law (Asien, Amerika)Quantisierungskennlinie (13 bzw. 15 Segmente).
Das analoge Signal beim Einsatz von G.711 wird mit 8 kHz (Framelänge = 125 µs)
abgetastet und mittels PCM-Verfahren jedes Samples mit 8 Bit kodiert. Die resultierende Datenübertragungsrate beträgt folglich 64 kbit/s.
Es wird nicht das gesamte für Sprache relevante Frequenzspektrum übertragen; das
übertragene Signal wird den Frequenzbereich von 300 Hz bis 3400 Hz begrenzt. G.711
findet bei ISDN Anwendung, der typische MOS-Wert ist 4,2.
9.1.2 ITU-T G.722
Diese Empfehlung der ITU-T von 1988 beschreibt einen Audiocodec mit höherer Audiobandbreite als G.711 bei gleicher Datenrate (64 kbit/s).
Dabei wird der Frequenzbereich von 50 bis 7000 Hz übertragen (vgl. G.711: 300 bis
3400 Hz), womit sich eine deutlich bessere Sprachqualität erreichen lässt. G.722 verfügt
über keine Fehlerkorrektur und verursacht eine Verzögerung von 1,5 ms, die sich hauptsächlich aus dem Aufteilen der Sprache in zwei Bänder ergibt. Das System unterstützt
3 Betriebsarten: 64, 56 und 48 kbit/s. Die letzten beiden Modi erlauben das Auffüllen
bis 64 kbit/s mit Zusatzdaten. Der Codec nutzt dabei SB-ADPCM (sub band adaptive differential pulse code modulation) und teilt das Frequenzband in 2 Teilbänder,
welche jeweils mit ADPCM kodiert werden. In der optimierten Version G.722.1 wird
bei vergleichbarer Sprachqualität mit 24 oder 32 kbit/s gearbeitet. Die Integration von
Sprachpausenerkennung und variablen Datenrate von 6,6 bis 23,85 kbit/s erfolgte die
Version G.722.2.
G.722.2 wurde von 3GPP als Codierung für Mobilfunknetze ausgewählt, der von allen
Mobilfunksystemen unterstützt werden muss. Er kann ebenso in IP-Netzen eingesetzt
werden. Die Sprachqualität ist sehr hoch und liegt bei MOS-Werten >4,5.
9.1.3 ITU-T G.723.1
G.723.1 wurde 1995 eingeführt und ist ein Audiocodec, welcher musterbasiert arbeitet
und ein lineares Schätzmodell verwendet, um Bandbreite einzusparen. Ursprünglich
9 Anhang
159
G.723.1 wurde für Videotelefonie mit geringen Datenraten entwickelt (Sprache, keine
Musikkodierung) und kann sowohl mit einer Datenrate von 6,4 kbit/s (Multipulse Maximum Likelihood Quantisierung, MP-MLQ) als auch mit 5,3 kbit/s (Algebraic-CodeExcited Linear Prediction, ACELP) arbeiten ([13]). Der übertragene Frequenzbereich
liegt zwischen 300 Hz und 3400 Hz, also vergleichbar mit dem von ISDN. Die typischen
MOS-Werte von G.723.1 sind 3,7 bei 5,3 kbit/s und 3,9 ([54])bei 6,4 kbit/s.
9.1.4 ITU-T G.726
Die ITU-Empfehlung G.726 wurde 1990 eingeführt und nutzt ADPCM mit 2,3 oder 4
Bit großen Bitworten und erzeugt Datenraten von 16, 24, 32 oder 40 kbit/s.
Die Sprachqualität erreicht ein MOS von 4,3 ([54]) bei 32 kbit/s.
9.1.5 ITU-T G.728
G.728 benutzt LD-CELP-Kodierer (Low Delay Codebook Excitation Linear Prediction) und erreicht bei 16 kbit/s ähnliche MOS-Werte wie ITU-T G.726 bei 32 kbit/s.
Diese hohe Qualität des Audiosignals wird allerdings durch eine hohe Komplexität
des Algorithmus erkauft. G.728 besitzt Strategien zum Verbergen von Rahmen- und
Paketverlusten und ist sehr stabil gegenüber Bitfehlern ([13]). Der MOS liegt bei 4,2
([6]).
9.1.6 ITU-T G.729
G.729, die technische Bezeichnung lautet auch ”Conjugate Structure Algebraic” (CSACELP), ist ein hybrides Kompressionsverfahren das sich auf die Untersuchung und
Übertragung von Sprachparametern, mit einem so genannten Vocoder, sowie Differenzinformationen und anschließende Sprachsynthese stützt. Es ist ein gegenüber Paketverlusten relativ unempfindliches Verfahren, dafür aber recht rechenaufwendig. G.729
hat eine Rahmengröße von nur 10 ms, eine Verarbeitungsverzögerung von 10 ms und
arbeitet mit 5 ms Vorschau, was eine Ende-zu-Ende-Verzögerung von 25 ms ergibt.
Sprachpausen werden erkannt um Bandbreite einzusparen, der Empfänger hört dann
ein ”künstliches” Rauschen. Der Codec verwendet üblicherweise eine Datenrate von 8
kbit/s, jedoch sind auch 6,4 kbit/s und 11,8 kbit/s möglich. Das Frequenzspektrum
umfasst dabei 300 bis 3400 Hz. Der typische MOS-Wert ist 4,0 ([54]) .
9 Anhang
160
9.1.7 GSM
Der GSM-Sprachcodec (GSM - Global System for Mobile Communication) stellt technisch eine absolute Herausforderung dar: Die zur Verfügung stehende Bandbreite für die
Sprachübertragung ist gering, die Fehleranfälligkeit auf dem Übertragungsweg ”Luft”
aber bekannterweise sehr hoch.
Im Jahr 1989 wurde der GSM ”Full-Rate Speech Codec” vorgestellt und basierte auf
dem Prinzip Regular Pulse Excitation + Long Term Predictor (RPE-LTP) bei einer
Datenrate 13 kbit/s bei 8 kHz Abtastfrequenz.
Später wurde der ”Half Rate Codec” eingeführt; aus der Halbierung der Datenrate
folgte eine Verdoppelung der Netzkapazität.
Für weitere Information sind folgende Webseiten zu empfehlen:
([59]) und ”http://www.3gpp.org/”.
9.1.8 iLBC
iLBC steht für ”internet Low Bitrate Codec” und ist ein lizenzgebührenfreier Sprachcodec, der hauptsächlich bei VoIP verwendet wird. Die Datenrate beträgt 13,33 kbit/s
bei Blöcken von 30 ms (400 Bits pro Block) oder 15,2 kbit/s bei Blöcken mit 20 ms
(304 Bits pro Block).
Der iLBC-Codec ermöglicht eine verhältnismäßig gute Sprachqualität selbst bei fehlenden Datenblöcken, was durch verlorene oder verzögerte IP-Pakete verursacht werden
kann.
Skype verwendet eine Variation von iLBC.
[58]
9.1.9 Speex
Speex ist ein Open Source, patent-freier Audiocodec für Sprachkodierung, basiert auf
CELP (Code Excitation Linear Prediction) und arbeitet mit Bandbreiten von 2 bis 44
kbit/s.
Dynamischer Bitratenwechsel und variable Datenraten (VBR), Stereofoniekodierung,
Paketverlust-Verschleierung, Echo-Aufhebung und Sprechpausenerkennung sind einige
der unterstützen Features.
Weitere Informationen über ”Speex” sind auf der zugehörigen Webseite zu finden ([69]).
9 Anhang
161
9.2 Ergänzende Dienste
9.2.1 Ergänzende Dienste auf Basis von Leistungsmerkmalen des
öffentlichen Netzes
Die folgenden Dienste werden durch die Vermittlungsknoten des öffentlichen Netzes
realisiert. Viele ergänzende Dienste wurden erst mit der Digitalisierung des Netzes
möglich, weshalb diese nur Teilnehmern an digitalen Netzknoten zur Verfügung stehen
([74]).
• Rufnummernidentifizierung
– Connected Line Identification Presentation (COLP)
Übermittlung der Rufnummer des angerufenen Anschlusses zum Anrufer
um ggf. eine Rufumleitung auf einen anderen Anschluss zu erkennen.
– Connected Line Identification Restriction (COLR)
Unterdrückung der Übermittlung der Rufnummer des angerufenen Anschlusses zum Anrufer.
– Calling Line Identification Presentation (CLIP)
Übermittlung der Rufnummer des Anrufers zum gerufenen Endgerät.
– Calling Line Identification Restriction (CLIR)
Unterdrückung der Rufnummernübertragung des Anrufers zum gerufenen
Endgerät
– Malicious Call Identification (MCID)
Identifizieren böswilliger Anrufer (Fangschaltung)
– Multiple Subscriber Number (MSN)
Realisiert die Zuordnung mehrerer Rufnummern zu einen Teilnehmeranschluss (nur am Mehrgeräteanschluss verfügbar).
– Subaddressing (SUB)
Subadressierung ermöglicht dem Teilnehmer seine Anschlussrufnummer zu
erweitern.
• Rufumlenkung
– Anrufumlenkung zu beliebigen anderen Anschlüssen
∗ Call Deflection (CD)
Anrufweiterschaltung durch den Angerufenen
9 Anhang
162
∗ Call Forwarding Busy (CFB)
Anrufweiterschaltung bei Besetzt
∗ Call Forwarding No Reply (CFNR)
Anrufweiterschaltung bei Nichtmelden
∗ Call Forwarding Unconditional (CFU)
Sofortige Anrufweiterschaltung
– Anrufumlenkungen zu Ansagen
∗ Call forwarding to a fixed announcement without message accepting
capability
Rufumleitung zu einer festen Ansage
∗ Absent subscriber service, diversion to an announcement selected from
an number of predetermined without message accepting capability
Rufumleitung zu einer Gruppe von Ansagen
– Anrufumlenkung zu einer Dienstperson (Call diversion to operator)
– Abfangen von Verbindungsversuchen (Administrative interception of calls)
– Fernsteuerung der Anrufumlenkung (Remote control of call forwarding)
Ändern der Anrufumleitung des eigenen Anschlusses von einem anderen
Anschluss
– Höflichkeitsruf bei Anrufumlenkung (Courtesy call for call forwarding)
• Dienste beim Verbindungsaufbau
– Call waiting (CW)
Anklopfen
– Call Hold (HOLD)
Halten und damit verbunden: Rückfrage/Makeln
– Completion of Calls to Busy Subscriber (CCBS)
Automatischer Rückruf bei Besetzt
– Completion of Calls on No Reply (CCNR)
Automatischer Rückruf bei Nichtmelden
• Konferenzdienste
– Three Party (3PTY)
Dreierkonferenz
9 Anhang
163
– Conference (CONF)
Telefonkonferenzen mit mehr als 3 Teilnehmern (mit ”Moderator”, Berechtigungen)
– Teletreff (Telemeeting)
”offene” Konferenz für jeden zugänglich, Einwahl über veröffentliche Telefonnummer
• Dienste für Interessensgruppen
– Geschlossene Benutzergruppe (Closed User Group)
Begrenzen der Komunikation auf ausgewählte Teilnehmer
• Gebührendienste
– Advice of Charge: charging Information at the end of the call (AOC-E)
Übermittlung von Tarifinformationen zum Ende der Verbindung
– Advice of Charge: charging Information on user request (AOC-R)
Übermittlung von Tarifinformationen auf Abruf durch den Anschlussinhaber
– Advice of Charge: charging Information at call setup-time (AOC-S)
Übermittlung von Tarifinformationen beim Verbindungsaufbau
– Advice of Charge: charging Information during the call (AOC-D)
Übermittlung von Tarifinformationen während der Verbindung
– Gebührenansage
– Gebührenfreie Anrufe (No-charge call)
– Einzelgebührennachweis (Detailed Billing)
– Zählvergleich (Meter Observation (MO))
Aufzeichnung von Verbindundsdaten, bei z.B. um gegen falsche Telefonrechnungen vorzugehen
– Freephone (FPH)
generelle Kostenübername durch den Angerufenen (0130/0800-Rufnummern)
• Übertragen von Zusatzinformationen
– User-to-User-Signalling
Zeichenübermittlung zwischen den Endgeräten beim Verbindungsauf- oder
-abbau (UUS1), während der Rufphase (UUS2) oder während der Verbindung (UUS3)
9 Anhang
164
• Dienste für einen schnellen Verbindungsaufbau
– Kurzwahl (Abbreviated Dialling AD)
– Teilnehmerpriorität (Priority)
– Verbindung ohne Wahl (Fixed Destination Call)
• Diensteinschränkungen
– Einschränkung des abgehenden Verkehrs (Service Restriction in the outgoing direction)
– Kennwort (PIN)
Schutz des Anschlusses vor unberechtigter Anwendung bestimmter Dienste
– Fernsteuerung des Dienstes ”Einschränkung des abgehenden Verkehrs” (Remote Control of Outgoing Restriction)
– Sperren von Teilnehmeranschlüssen (Dial Barring)
– Verkehrseinschränkungen im Katastrophenfall (Preference Category During
Catastrophe)
– Abweisen von R-Gesprächen (Reverse Charge Call Rejection)
• Notrufdienste
– Notrufverbindungen (Emergency Call Service)
• Dienste des öffentlichen Netzes für Privatanlagen
– Umsteuern mit Teilauslösen (Partial Rerouting)
Hat ein Teilnehmer einer ISDN-Nebenstellenanlage eine Rufumleitung auf
eine Rufnummer im öffentlichen Telefonnetz aktiviert, wird bei eingehenden
Anruf gleich im PSTN umgeleitet.
– Sammelanschluss (Line Hunting)
Mehrere Anschlüsse hinter einen Anschluss
– Durchwahl (Direct Dialling-In)
• Dienstunterstützung durch Vermittlungskräfte
– Aufschalten (Trunk Offering)
”Bietet der Dienstperson am Vermittlungsplatz die Möglichkeit sich in ein
bestehendes Gespräch einzuklinken, um dem entsprechenden Teilnehmer ein
ankommendes Ferngespräch anzubieten” ([74]).
9 Anhang
165
• Dienste für deregulierte Netze
– Wahl des Betreibers (Equal access, carrier selection)
Durch Vorwählen der entsprechenden Betreibernummer
– Rufnummernportabilität (Number portability)
Mitnehmen der Rufnummer bei Netzbetreiberwechel / Umzug
• Besondere erweiterte Dienste für analoge Teilnehmeranschlüsse (CLASS Feature)
• Sonstige Dienste
– Centrex (Central Office Exchange Service)
– Langzeitverbindungen (Nailed-Up Connections)
– Wecken (Alarm Call Service))
– Steckdosenwechsel/Endgerätewechsel
– Generelles Deaktivieren aller Dienste
9.2.2 Ergänzende Dienste auf Basis von Leistungsmerkmalen des
Intelligenten Netzes
• Gebührenfreie Rufnummer (Freephone)
vgl. 0130/0800-Rufnummern
• Einheitliche Rufnummer (Universal Access Number)
vgl. 0180-Rufnummern
• Televotum (Televoting)
• Teleinfo-Dienst (Premium Rate)
• Virtuelles Privatnetz (Virtual Private Network (VPN))
9.2.3 Ergänzende Dienste auf Basis der PBX
• Rufnummern-/Namens-Identifizierung
– Anzeige der Rufnummer des gerufenen Teilnehmers (vgl. COLP)
9 Anhang
166
– Anzeige des Namens des gerufenen Teilnehmers (CONP - Connected Name
Identification Presentation)
– Anzeige der Rufnummer des rufenden Teilnehmers (vgl. CLIP)
– Anzeige des Namens des rufenden Teilnehmers (CNIP - Calling Name Identification Presentation)
– Unterdrückung des Anzeige der Rufnummer des rufenden/gerufenen Teilnehmers (vgl. CLIR)
– Unterdrückung des Anzeige des Names des rufenden/gerufenen Teilnehmers
(CNIR - Calling/Connected Name Identification Restriction)
– Subadressierung (SUB - Subaddressing)
• Rufumlenkung
– Rufumlenkung zu beliebigen anderen Anschlüssen
– Abfangen von Verbindungsversuchen
– Anrufweiterschaltung nach Rufzustellung (Call Deflection)
– Fernsteuerung der Anrufumlenkung
– Höflichkeitsruf bei Anrufumlenkung
• Dienste beim Verbindungsaufbau
– Anklopfen (CW - Call Waiting)
– Aufschalten (CI - Call Intrusion)
– Anbieten einer Verbindung (CO - Call Offer) Dieser Dienst ermöglicht es
einem Teilnehmer, eine auf ”Halten” gesetzte Verbindung einem besetzten
Teilnehmer anzubieten. Dieser kann entscheiden, ob er den Anruf annimmt
oder nicht (signalisiert durch Anklopfen!).
– Transfer einer Verbindung (CT - Call Transfer)
Übergeben einer Verbindung an einen anderen Teilnehmer
– Halten/Makeln
– Rückruf bei Besetzt/Nicht-Melden (CCBS, CCNR)
– Anrufschutz (DND - Do not Disturb)
Alle Anrufe werden vom System abgewiesen, wenn der Teilnehmer ”DND”
aktiviert hat. Kann mit ”DNDO” übergangen werden (Do Not Disturb Override).
9 Anhang
167
• Konferenzdienste
Mit 3 oder mehr Teilnehmern.
• Dienste für Intessensgruppen
• Gebührendienste
– Gebührenanzeige (AOC - Advice of Charge)
Beispielsweise für die Telefonabrechnung in Hotels.
• Übertragen von Zusatzinformationen
– User-to-User-Signalling
• Dienste für schnellen Verbindungsaufbau
– Kurzwahl
• Diensteeinschränkungen
– Sperren von Teilnehmeranschlüssen
– Verkehrseinschränkungen im Katastrophenfall
• Notrufdienste
• Dienste des öffentlichen Netzes für Privatanlagen
– Durchwahl
– Sammelanschluss
• Diensteunterstützung durch Vermittlungskräfte
– Wiederanruf
Vermittelte, aber dort nicht beantwortete, Anrufe werden zurückgegeben
(Call Interception and Recall)
– Aufschalten
– Zuweisen von Amtsleitungen
– Nachtschaltung
Umleiten von Anrufen entsprechend der Anrufzeit
• Gruppen- und Team-Leistungsmerkmale
– Anrufübernahme
”Pick-Up”-Gruppen. Anrufe für einen Teilnehmer in einer Pick-Up-Gruppe,
kann durch andere Gruppenmitglieder angenommen werden.
9 Anhang
168
– Direktruf
– Chef/Sekretär-Funktion
Anrufe werden nicht direkt durchgestellt, sondern an eine Zwischenstation
(Sekretär) weitergeleitet, welche dann entsprechend weiterleitet
• Sonstige Dienste
– Wahl des Netzbetreibers
– Rufnummernportabilität
– Wecken
9 Anhang
169
9.3 Dokumentation - Einrichten eines VoIP-Netzes
9.3.1 Installation eines Grundsystems
9.3.1.1 Betriebssystem
Die Basis des einzurichtenden VoIP-Netzes ist ein Server mit einem Linux-BetriebsSystem auf Basis von Debian. Zusätzlich zum vorhandenen Internetzugang verfügt der
Server über eine eingebaute ISDN-Karte (AVM B1) als Zugangspunkt in das öffentliche Telefonnetz. Als Telefonanlagen-Software kommt ”Asterisk” (Software-PBX) zum
Einsatz.
Die Wahl fiel auf ein Debian-Etch-Netzwerkimage, welches ein einfaches Debian-Basissystem installiert und alle zusätzlichen Pakete und Anwendungen aus dem Internet
nachlädt. Anlaufstelle für aktuelle Versionen und Informationen über Debian bietet
die zugehörige Webseite www.debian.org.
Nach dem Brennen des Images wird der Rechner von CD gestartet und die Installation
begonnen. Die relevanten Eingaben betreffen die Netzwerk- und Nutzerdaten:
IP-Adresse: 141.24.93.180
Subnetz: 255.255.252.0
Gateway: 141.24.95.254
DNS: 141.24.4.1
Rechnername: "asterisk-voip"
Root-Passwort: "0bel1x"
Neuer User: "asterix"
Passwort: "1def1x"
Bei der Frage, welche zusätzlichen Pakete bei der Installation installiert werden sollen,
fällt die Wahl auf ”Desktop-Umgebung” und ”Standardsystem”.
Nach der Installation sollten der Verweis auf die Installations-CD in der
/etc/apt/sources.list entfernt werden und anschließend alle verfügbaren Systemupdates eingespielt werden. Zusätzlich zu installierende Pakete sind ”isdnutils” und
”capiutils” für die Einbindung der ISDN-Karte und ”ssh” für den Fernzugriff auf das
System:
apt-get install ssh isdnutils capiutils
9 Anhang
170
9.3.1.2 Einbinden der ISDN-Karte in das System
Der nächste Schritt ist das Einbinden des ISDN-Karte in den Kernel. Dazu muss die
Firmware der Karte in den Ordner /usr/share/isdn kopiert werden. Bezogen werden
kann die Firmware unter folgender Adresse: [1].
Als nächstes erfolgt die Anpassung der Datei /etc/isdn/capi.conf an die Hardware:
Da eine AVM B1 als PCI-Karte zum Einsatz kommt, wird vor ”b1pci” die Auskommentierung entfernt. Jetzt via
capiinit
die Karte initialisieren. Damit ist die Karte in das System eingebunden. Um dies zu
überprüfen, kommt der Befehl ”capiinfo” zum Einsatz, welcher Informationen über die
Karte ausgeben sollte (eine Ausgabe bei fehlerfreier Installation der ISDN-Karte ist im
Anhang zu finden. Siehe 9.4.
9.3.1.3 Einrichten eines ”Mail Transfer Agent”
Ein Mehrwertdienst dieses VoIP-Servers soll das ”VoiceMail”-Feature sein. Dieses Feature, VoiceMail = ”Sprachübertragung per Email”, realisiert das automatische Versenden von Benachrichtigungen per E-Mail, sobald neue ein Nutzer neue Nachrichten auf
seiner Mailbox hat.
Dabei wird der angerufenen, aber nicht erreichten Person eine Benachrichtigung per
E-Mail zugestellt, an welche die auf die Mailbox gesprochene Nachricht optional als
Attachment beigefügt ist.
Die Funktion des automatischen Versands von Benachrichtigungsmails durch das System ist eine Standardfunktion von Asterisk, welche aber Unterstützung des Systems
benötigt, ein Mailserver muss eingerichtet werden. Ein Mailserver ist kein einzelner
Dienst, sondern kann sich aus verschiedenen Komponenten zusammensetzen. Tabelle
9.1 verdeutlicht die Aufgaben der einzelnen möglichen Komponenten.
Für die Realisierung des automatischen Mailversandes durch das System reicht die
Einrichtung eines MTA. Dieser MTA versendet mit Zuhilfenahme eines Mailservers
(SMTP-Server im Netz, z.B. mail.gmx.net oder eigener) die entsprechenden Benachrichtigungen. Der Weg über einen externen SMTP-Server ist nötig, weil im Zeitalter
von Spam kein Email-Server, Emails von Servern ohne feste IP und ohne entsprechende
Zertifikate akzeptiert.
Ein solcher ”Mail Tranfer Agent” ist ”Postfix”. Mit Hilfe von ”Postfix” und eines E-
9 Anhang
171
Dienst
Beschreibung
MTA (Mail Transfer Agent)
Zuständig für den Transport der Mail von einem
System zum Anderen
MDA (Mail Delivery Agent)
Stellt die Post auf dem lokalen System zu
MRA (Mail Retrieval Agent)
Holt Post von einem entfernten Server ab
IMAP-/POP3-Server
Hält die Post für den Endbenutzer bereit, damit
er sie mit seinem Mailprogramm (MUA - Mail
User Agent) abholen und lesen kann.
Tabelle 9.1: Übersicht der Komponenten eines Mailservers
Mailkontos bei GMX (www.gmx.de) ist der automatische Mailversand durch das System möglich.
Die Zugangsdaten für das verwendete E-Mailkonto sind folgende:
Tarif: GMX FreeMail
E-Mail-Adresse: [email protected]
Kundennummer: 39478339
Passwort: asterisk_TUI
POP3-Server: pop.gmx.net
SMTP-Server: mail.gmx.net
Die Installation von Postfix erfolgt problemlos via Eingabe von
apt-get install postfix
an der Konsole. Die nötigen Pakete werden automatisch installiert. Im Anschluss daran
erscheint ein Menü, welches die wichtigsten Parameter von Postfix erfragt:
• Allgemeine Art der Konfiguration
Da Postfix nur für den Versand von Emails zuständig sein soll, fällt die Wahl auf
den Einsatz als ”Satellite System”
• E-Mailname des Systems
Hier ”Asterisk-voip” eintragen.
• SMTP-Relay-Server
Hier den externen SMTP-Server angeben, über welchen die Benachrichtigungen
versandt werden: ”mail.gmx.net”.
9 Anhang
172
Zusätzlich zu Postfix ist die Installation des Paketes ”libsasl2-modules” nötig, welches
für die Authentifizierung am SMTP-Server nötig ist:
apt-get install libsasl2-modules
Im nächsten Schritt muss die /etc/postfix/main.cf angepasst werden, indem folgende Einträge hinzugefügt werden:
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noplaintext noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
sender_canonical_maps = hash:/etc/postfix/sender_canonical
Wie zu erkennen ist, wird auf 2 Dateien im Verzeichnis /etc/postfix/ verwiesen,
welche beide dort erstellt werden müssen:
• sasl_password
In dieser Datei sind die nötigen Daten des E-Mailpostfachs (SMTP-Server, EMailadresse und Kennwort) angegeben.
Der Inhalt dieser Datei lautet:
mail.gmx.net [email protected]:Ehrenbergstrasse
• sender_canonical
In dieser Datei sind die Aliase abgebildet, d.h. welche E-Mailadresse dem entsprechenden Linux-Nutzer zugeordnet ist. Kein Email-Provider akzeptiert Emails
von ”root@asterisk-voip”.
Der Inhalt dieser Datei lautet:
root [email protected]
asterix [email protected]
Nach diesen Einstellungen muss Postfix mit den neuen Einstellungen vertraut und
anschließend neu gestartet werden. Dies erfolgt durch die Eingabe folgender Befehle:
postmap /etc/postfix/sasl_password
postmap /etc/postfix/sender_canonical
/etc/init.d/postfix reload
/etc/init.d/postfix restart
9 Anhang
173
9.3.2 Asterisk
Nachdem ein Grundsystem installiert ist, kann die Installation von Asterisk (SoftwarePBX) und FreePBX (grafische Oberfläche) beginnen.
Vor der eigentlichen Installation sind einige Pakete, welche für den weiteren Installationsverlauf notwendig sind, via ”aptitude install” zu installieren:
aptitude install ssh mc build-essential linux-headers-‘uname -r‘
libxml2-dev libtiff-dev mysql-server apache php4 php4-gd php4-mysql
php5-mysql libapache-mod-php5 bison ncurses-dev libaudiofile-dev
php4-pear sysv-rc-conf curl libcurl-dev libmysqlclient-dev
Anschließend:
pear install DB
Da FreePBX auf dem Apache-Webserver und nicht auf Apache2 läuft, muss der Apache2Webserver abgeschalten und an seiner Stelle der Apache-Webserver dafür gestartet
werden:
sysv-rc-conf apache2 off
apache2ctl stop
apachectl start
Im nächsten Schritt muss die /etc/apache/httpd.conf modifiziert werden:
Aus ”User www-data” wird ”User asterisk”,
aus ”Group www-data” wird ”Group asterisk” und
aus ”DocumentRoot /var/www/” wird ”DocumentRoot /var/www/html/”.
Jetzt wird ein neuer Nutzer im System angelegt, ein Web-Root-Verzeichnis erstellt
und der Apache-Webserver neugestartet:
useradd -c "Asterisk PBX" -d /var/lib/asterisk asterisk
mkdir /var/www/html
chown -R asterisk:asterisk /var/www/html/
apachectl restart
Soweit die nötigen Vorarbeiten. Jetzt kann mit der Installation von Asterisk begonnen
werden!
9 Anhang
174
Vor der Installation sollte sich auf der Webseite ”www.asterisk.org” über aktuelle Versionen informiert werden!
Im nächsten Schritt muss das Arbeitsverzeichnis von Asterisk angelegt und in das
Verzeichnis ”/usr/src/” gewechselt werden:
mkdir /var/run/asterisk
cd /usr/src
In den Ordner ”/usr/src/” werden die Pakete von Asterisk heruntergeladen und von
dort aus installiert.
In Rahmen dieser Dokumentation werden folgende Versionen der einzelnen Pakete
verwendet:
• Asterisk in Version 1.4.19
• Asterisk-addons in Version 1.4.6
• Asterisk-sounds in Version 1.2.1
• Zaptel 1.4.9.2
Beziehen, entpacken und installieren der Pakete:
wget http://downloads.digium.com/pub/asterisk/releases/
asterisk-1.4.19.tar.gz
wget http://downloads.digium.com/pub/zaptel/releases/
zaptel-1.4.9.2.tar.gz
wget http://downloads.digium.com/pub/asterisk/releases/
asterisk-addons-1.4.6.tar.gz
wget http://ftp.digium.com/pub/asterisk/releases/
asterisk-sounds-1.2.1.tar.gz
tar
tar
tar
tar
zxf
zxf
zxf
zxf
asterisk-1.4.19.tar.gz
asterisk-addons-1.4.6.tar.gz
asterisk-sounds-1.2.1.tar.gz
zaptel-1.4.9.2.tar.gz
cd /usr/src/zaptel.1.4.9.2
./configure
make
9 Anhang
175
make install
modprobe ztdumy
cd /usr/src/asterisk-1.4.19
./configure
make
make install
make samples
cd /usr/src/asterisk-addons-1.4.6
. /configure
make
make install
cd /usr/src/asterisk-sounds-1.2.1
make
make install
Soweit die Installation von Asterisk und der nötigen Pakete. Die nächsten Kapitel
beschäftigen sich mit dem Einbinden der ISDN-Karte in Asterisk und dem Einbinden
deutscher Sprachfiles.
9.3.2.1 Asterisk mit ISDN vertraut machen
Die eingebaute ”AVM B1”-ISDN-Karte ermöglicht den Zugang zum öffentlichen Telefonnetz. Diese ist bereits in das Betriebssystem integriert, muss allerdings noch mit
”Asterisk” vertraut gemacht werden, was durch das Modul ”chan-capi” realisiert wird.
Weitere Informationen dazu, sind auf der Homepage ”www.chan-capi.org” zu finden!
Beziehen, Entpacken und Installieren:
cd /usr/src
wget ftp://ftp.chan-capi.org/chan-capi/chan_capi-HEAD.tgz
tar zxf chan_capi-HEAD.tgz
cd /usr/src/chan-capi-HEAD
make
make install
make install_config
9 Anhang
176
Anschließend muss dafür gesorgt werden, dass ”Asterisk” das Modul lädt. Dies wird
durch Hinzufügen folgender Zeilen in der ”"/etc/asterisk/modules.conf” erreicht:
load => chan_capi.so
[global]
Chan_capi.so=yes
Nach einem Neustart von ”Asterisk” wird jetzt durch die Eingabe von ”"capi info"
an der ”Asterisk CLI” die Anzahl der verfügbaren B-Kanäle ausgegeben.
9.3.2.2 Deutsche Sprachfiles
In der Asterisk-Standardinstallation sind alle Sprachfiles, unter anderem verwendet
für die Mailbox, in englischer, spanischer und französischer Sprache vorhanden ([16]).
Sprachfiles in deutscher Sprache lassen sich allerdings leicht nachinstallieren.
Es existieren 2 Anbieter deutscher Sprachbausteine für Asterisk:
• Stadt Pforzheim
Die Stadt Pforzheim nutzt seit 2005 eine VoIP-Lösung auf Basis von Asterisk.
Zusätzlich dazu wurden deutsche Sprachprompts in Auftrag gegeben, welche die
Stadt Pforzheim als Dank an die Open Source Gemeinde allen zur Verfügung
stellt. Allerdings sind diese Sprachbausteine für Asterisk Version 1.2 konzipiert,
weswegen das Paket nicht vollständig mit Asterisk Version 1.4 kompatibel ist
([16]).
www.stadt-pforzheim.de/asterisk
• Amooma GmBH
Die AMOOMA GmbH bietet deutsche Sprachbausteine (Voiceprompts) für Asterisk in Version 1.4 an. Gesprochen wurden diese von Gabi Becker (VOX Nachrichtensprecherin).
www.amooma.de/asterisk/sprachbausteine/index.html
Da die Sprachbausteine der Amooma GmbH für Asterisk 1.4.x geeignet sind, werden
diese installiert.
9 Anhang
177
Runterladen und entpacken:
cd /usr/src
wget http://www.amooma.de/asterisk/sprachbausteine/
asterisk-1.4-de-prompts.tar.gz
tar zxf asterisk-1.4-de-prompts.tar.gz
Zuerst die Ordner für die deutschen Sprachfiles anlegen:
mkdir
mkdir
mkdir
mkdir
mkdir
/var/lib/asterisk/sounds/de
/var/lib/asterisk/sounds/dictate/de
/var/lib/asterisk/sounds/digits/de
/var/lib/asterisk/sounds/letters/de
/var/lib/asterisk/sounds/phonetic/de
Nun die entsprechenden Ordner in die gerade erstellten Asterisk-Soundfile-Ordner kopieren:
cd /usr/src/de
cp *.* /var/lib/asterisk/sound/de
cd/usr/src/dictate/de
cp *.* /var/lib/asterisk/sounds/dictate/de
cd /usr/src/digits/de
cp *.* /var/lib/asterisk/sounds/digits/de
cd /usr/src/letters/de
cp *.* /var/lib/asterisk/sounds/letters/de
cd /usr/src/phonetic/de
cp *.* /var/lib/asterisk/sounds/phonetic/de
Soweit die nötigen Anpassung auf Dateiebene, alles weitere erfolgt später in FreePBX
(9.3.3.1).
9 Anhang
178
9.3.3 FreePBX - Die grafische Oberfläche
Für die Realisierung der grafischen Oberfläche für die Konfiguration und Wartung des
VoIP-Netzes kommt ”FreePBX” zum Einsatz.
Installation
Im ersten Schritt muss die aktuelle Version von ”FreePBX” bezogen werden. In Rahmen
dieser Dokumentation ist dies Version ”FreePBX 2.4.0”:
cd /usr/src
wget http://mirror.freepbx.org/freepbx-2.4.0.tar.gz
tar zxf freepbx-2.4.0.tar.gz
cd freepbx-2.4.0
Nach dem Entpacken von ”FreePBX” müssen nun 2 SQL-Datenbanken angelegt werden, welche für den Einsatz von ”FreePBX” zwingend nötig sind!
mysqladmin create asterisk
mysqladmin create asteriskcdrdb
mysql asterisk < SQL/newinstall.sql
mysql asteriskcdrdb < SQL/cdr_mysql_table.sql
Nach dem Anlegen der Datenbanken werden die Zugriffsrechte darauf einem Nutzer gewährt. In diesem Fall dem Nutzer ”miraculix” mit dem zugehörigen Passwort ”s0l1de”:
mysql
GRANT ALL PRIVILEGES ON asteriskcdrdb.* TO miraculix@localhost
IDENTIFIED BY ’s0l1de’;
GRANT ALL PRIVILEGES ON asterisk.* TO miraculix@localhost
IDENTIFIED BY ’s0l1de’;
flush privileges;
\q
Anschließend muss noch eine kleine Änderung in ”/etc/asterisk/asterisk.conf getätigt werden:
Aus ”astrundir => /var/run” wird ”astrundir => /var/run/asterisk”.
Damit sind die nötigen Vorbereitungsschritte abgeschlossen und die eigentliche Installation kann beginnen. Zunächst muss ”Asterisk” gestartet werden:
asterisk
cd /usr/src/freepbx-2.4.0
./install_amp
9 Anhang
179
Die Installation wird nun gestartet und einige Angaben zum System werden abgefragt:
Enter your Username to connect to the ”asterisk” database:
miraculix
Enter your Password to connect to the ”asterisk” database:
s0l1de
Enter the hostname of the ”asterisk” database:
localhost
Enter a USERNAME to connect to the Asterisk Manager Interface:
miraculix
Enter a PASSWORD to connect to the Asterisk Manager Interface:
s0l1de
Enter the Path to use for your AMP web root:
/var/www/html
Enter the IP ADDRESS or hostname used to access the AMP web-admin
141.24.93.180
Enter a PASSWORD to perform call transfers with the Flash Operator Panel:
passw0rd
Use simple Extensions [extensions] admin or separate Devices and Users [deviceandusers]?
extensions
Enter directory in which to store AMP executable scripts:
/var/lib/asterisk/bin
Enter directory in which to store super-user scripts:
/usr/local/sbin
Jetzt kann FreePBX gestartet werden:
amportal start
Ab sofort kann über einen Webbrowser auf das Web-Portal, durch Eingeben der IPAdresse, zugegriffen werden.
Um die Sicherheit zu erhöhen, sollte eine Anmeldung am Web-Portal erforderlich gemacht werden. Standardmässig ist dies nicht der Fall. Dazu muss eine Änderung in der
Datei ”/etc/amportal.conf” vorgenommen werden:
Aus ”AUTHTYPE=none” wird ”AUTHTYPE=database”.
Der zugehörige Account wurde während der Installation definiert:
”miraculix // s0l1de”
9 Anhang
180
9.3.3.1 Umstellen auf deutsche Sprachfiles
In Kapitel 9.3.2.2 wurden deutsche Sprachfiles, unter anderem für die Mailbox, in das
System eingepflegt. Um dies dem System mitzuteilen, wird via Webbrowser auf den
eingerichteten Server zugegriffen:
Abbildung 9.1: Die grafische Oberfläche
Nach einem Klick auf ”FreePBX Administration” und der Anmeldung am Portal mit
”miraculix//s0l1de” erreicht man die GUI (engl. Graphical User Interface, Abk. GUI)
FreePBX zur Verwaltung des Systems.
Hinweis:
Informationen zum Aufbau der GUI sind auf www.freepbx.org zu finden!
Um die Sprache umzustellen, muss das Modul ”Languages” für FreePBX installiert
werden. Dazu wie folgend beschrieben vorgehen:
1. ”Module Admin” (linke Navigationsseite)
2. ”Ceck for updates online”
3. bei ”Internal Options” - ”Configuration” das Modul ”languages” auswählen und
installieren!
9 Anhang
181
Abbildung 9.2: Änderungen übernehmen
4. Abschließend auf ”Apply Configuration Changes” klicken, damit das System die
Änderungen realisiert.
Nachdem das Modul erfolgreich installiert wurde, erscheint in der linken Navigationsleiste unter ”Internal Options & Configuration” ein neuer Eintrag ”Languages”, über
welchen die Sprache auf ”deutsch” umgestellt werden kann!
Dazu folgende Einstellungen vornehmen: Abschließend auf ”Submit Changes” und er-
Abbildung 9.3: Sprache auf ”deutsch” umstellen
neut auf ”Apply Configuration Changes” klicken, damit das System die Änderungen
realisiert.
9 Anhang
182
9.3.4 Einrichten von Nutzern
Das Einrichten eines Nutzers geschieht durch einen Klick auf ”Extensions” in der linken
Navigationsleiste.
Da das Netz auf Basis von SIP arbeiten soll, wird ”Generic SIP Device” ausgewählt:
Abbildung 9.4: Hinzufügen eines SIP-Nutzers
Ein Klick auf ”Submit” und ein neuer SIP-Nutzer kann angelegt werden. Folgende
Felder sind für einen einfachen Nutzeraccount relevant:
• Add Extension - User Extension
Hier die (interne) Telefonnummer eintragen, unter welcher der Nutzer erreicht
werden soll
• Add Extension - Display Name
Hier den Namen des Nutzers eintragen
• Device Options - Secret
Hier ist das Passwort des Accounts festgelegt
Nachdem alle Eingaben getätigt wurden, erfolgt ein Klick auch ”Submit”. Damit die
Einrichtung eines Nutzers abgeschlossen ist, muss nun auf ”Apply Configuration Changes” geklickt werden, damit das System die Änderungen realisiert:
Abbildung 9.5: Änderungen übernehmen
9 Anhang
183
Der soeben eingerichtete Nutzer, kann sich jetzt via Hard- oder Softphone am Server
anmelden.
Ein solches Softphone ist ”X-Lite”, die für ”X-Lite” notwendigen Einstellungen sind:
• User Name
Hier die unter ”User Extension” definierte Telefonnummer eintragen.
• Password
Hier das festgelegte Passwort eintragen.
• Domain
Hier die IP-Adresse des Servers eintragen.
Weitere Einstellungen sind nicht zu tätigen.
Nach dem Einrichten mehrerer SIP-Nutzer, sind diese jetzt in der Lage, sich innerhalb
des Netzes durch Wählen ihrer Telefonnummer zu erreichen!
Weiterführende Informationen zum Einrichten von Nutzern, sind hier zu finden:
- www.ip-phone-forum.de/showthread.php?t=91217
- www.freepbx.org/support/documentation/administration-guide/adding-extensions
9 Anhang
184
9.3.5 Kommunikation mit der Außenwelt
Die Kommunikation mit anderen Netzen findet über verschiedene Kommunikationskanäle statt. Ob nun über SIP, ISDN oder IAX, die nötige Vorgehensweise dazu ist
sehr ähnlich:
• Hinzufügen eines Trunks
Durch einen Trunk wird ein Kommunikationskanal definiert.
• Definieren einer ”Outbound Route”
Mit dem Erstellen einer ”Outbound Route” wird definiert, wie andere Netze über
diesen Trunk erreicht werden.
• Definieren einer ”Inbound Route”
Eine ”Inbound Route”’ hingegen definiert, wie das eigene Netz von ausserhalb
über diesen Trunk erreicht wird.
9.3.5.1 Einbinden eines VoIP-Providers
VoIP-Provider sind Unternehmen, welche Schnittstellen (Gateways) in andere Netze,
aber auch die VoIP-Kommunikation über das Internet anbieten.
Während die VoIP-Kommunikation über das Internet meist kostenfrei ist, werden bei
der Nutzung von Mehrwertdiensten, wie Anrufe über das Internet in das öffentliche
Telefonnetz, Kosten fällig.
Im Rahmen dieser Dokumentation wird exemplarisch SIPGATE (www.sipgate.de) als
VoIP-Provider über das SIP-Protokoll eingebunden.
Nach der Anmeldung bei SIPGATE, bekommt man unter anderem eine ”SIP-ID”, ein
dazugehöriges Passwort und eine normale Telefonnummer zugewiesen.
In diesem Beispiel ist dies die 03677/799026, über welche unser Netz mit der Aussenwelt kommuniziert.
Um unseren VoIP-Server mit SIPGATE vertraut zu machen, sind wie bereits in 9.3.5
erwähnt, einige Schritte notwendig:
Einen Trunk hinzufügen
Um einen neuen Trunk (Trunk bedeutet soviel wie Kommunikationskanal) hinzuzufügen, wird in der linken Navigationsleiste ”Trunks” ausgewählt; da SIPGATE ein
SIP-Provider ist, wird ein SIP-Trunk hinzugefügt.
9 Anhang
185
Relevante Eingaben sind:
• Outgoing Settings - Trunk Name
Name des Trunks (hier einen beliebigen aussagekräftigen Namen verwenden)
• Outgoing Settings - Peer Details
type=friend
insecure=very
nat=yes
username=SIPID (hier zugewiesene SIPID eintragen)
fromuser=SIPID (hier zugewiesene SIPID eintragen)
fromdomain=sipgate.de
secret=SIPPW (hier zugewiesenes Passwort eintragen)
host=sipgate.de
qualify=yes
• Registration - Register String
register => SIPID:[email protected]/SIPID
Ein Klick auf ”Submit Changes” schließt die Eingabe ab.
Im nächsten Schritt eine ”Outbound Route” der Wählplan modifiziert, d.h. es wird
definiert, wann über SIPGATE telefoniert wird.
Outbound Route
Durch eine ”Outbound Route” wird der Wählplan modifiziert, d.h. es wird festgelegt,
welche Aktion beim Wählen einer bestimmten Extension (Rufnummer) ausgeführt
wird. In diesem Beispiel legen wir fest, dass beim Wählen einer ”0” als erste Ziffer
einer Rufnummer immer über SIPGATE telefoniert wird.
Dazu muss eine entsprechende Regel definiert werden:
Durch einen Klick auf ”Outbound Routes” in der linken Navigationsleiste, lässt sich
eine neue Regel definieren. Relevante Eingaben dabei sind:
• Route Name
Name der Regel
• Dial Patterns
Hier ”0.” eintragen, um auf alle Nummern mit einer ”0” an der ersten Stelle
zu reagieren. Der ”.” hinter der ”0” definiert, dass nach der ”0” die eigentliche
Rufnummer kommt.
9 Anhang
186
• Trunk Sequence
Hier ist eine Priorisierung vorhandener Trunks möglich. In diesem Beispiel wird
der eben angelegte SIPGATE-Trunk ausgewählt.
Inbound Route
Durch eine Inbound Route wird definiert, wie unser Asterisk-Server auf eingehende
Gespräche (hier von SIPGATE) reagieren soll. Durch einen Klick auf ”Inbound Routes”
in der linken Navigationsleiste lässt sich eine neue Regel erstellen. Folgende Eingaben
sind dabei zu tätigen:
• Edit Incoming Route - Description
Eine Beschreibung/Namen der Regel festlegen.
• Edit Incoming Route - DID Number
Hier die SIP-ID von SIPGATE eintragen, damit unser Server weiß, auf welche
SIP-ID er reagieren soll.
• Edit Incoming Route - CID name prefix
Hier kann ein entsprechender Kontext eingetragen werden, welcher dem Angerufenen mitteilt, dass das ankommende Gespräch, über den SIPGATE-Account
ankommt.
Beispiel: ”via Sipgate”. Dem Angerufenen wird ein ankommender Anruf dann wie
folgt signalisiert:
”via SIPGATE - XXXX”, wobei XXXX für die Rufnummer des Anrufers steht!
• Set Destination
Hier wird festgelegt, was mit dem Anruf passiert, beispielsweise kann der Anruf
auf eine bestimmte (vorher definierte) Extension (siehe 9.3.4) geroutet werden.
Ein Klick auf ”Submit” speichert die Änderungen.
Somit wäre ein VoIP-Provider eingebunden, über welchen Gespräche in und aus unserem VoIP-Netz realisiert werden. Abgehende Gespräche sollten nach einen Klick auf
”Apply Configuration Changes” möglich sein.
Wichtiger Hinweis:
Für eingehende Gespräche muss allerdings noch eine Modifikation vorgenommen werden:
In den ”General Setting” müssen anonyme Anrufe erlaubt werden. ”Allow Anonymous
Inbound SIP Calls?” muss auf ”Yes” gesetzt werden.
9 Anhang
187
Weiterführende Informationen zu diesem Kapitel:
- www.sipgate.de
- www.sipgate.de/faq/index.php?do=displayArticle&article=540&id=257
- www.ip-phone-forum.de/showthread.php?t=91217
- www.freepbx.org/support/documentation/
9.3.5.2 Anbindung an das öffentliche Telefonnetz via ISDN
Mit der eingebauten ISDN-Karte existiert eine Möglichkeit, das System mit dem öffentlichen Telefonnetz zu verbinden.
In 9.3.1.2 und 9.3.2.1 wurde die Karte in das System eingebunden, jetzt wird auf Basis
dieser ein Kommunikationskanal eingerichtet:
Einen Trunk hinzufügen
Ein Klick auf ”Trunks” in der linken Navigationsleiste öffnet das Menü zum Hinzufügen
neuer Trunks. Im Vergleich zu 9.3.5.1, ist dies kein SIP-Trunk.
Die ISDN-Karte wird über den installierten CAPI-Treiber angesprochen, weshalb dafür ein ”Custom Trunk” eingerichtet werden muss!
Im folgenden Kontextmenü sind nur 2 Felder auszufüllen:
• General Setting - Outbound Caller ID
Outbound Caller ID : steht für die MSN, die verwendet werden soll. Wird keine
eingetragen, wird die Haupt-MSN verwendet.
• Outgoing Settings - Custom Dial String
Hier folgendes eintragen : ”CAPI/ISDN1/$OUTNUM$”
CAPI - über CAPI wird die Karte angesprochen
ISDN1 - der Kontext ist in der ”/etc/asterisk/capi.conf” definiert
OU T N U M - ist eine Variable und steht für die gewählte Rufnummer (die an
den Trunk übergeben werden soll)
Outbound Route
Hier wird definiert, wann über die ISDN-Karte Gespräche abgehend geführt werden.
Durch einen Klick auf ”Outbound Routes” in der linken Navigationsleiste, lässt sich
eine neue Regel definieren. Relevante Eingaben dabei sind:
• Route Name
Name der Regel
9 Anhang
188
• Dial Patterns
Für diese Dokumentation wird festgelegt, dass nur 2 bestimmte Rufnummern
über die ISDN-Karte erreicht werden dürfen.
Allerdings können hier selbstverständlich beliebige Definitionen getätigt werden!
Also werden nur die zwei folgenden Rufnummern hier eingetragen:
123456
234567
• Trunk Sequence
Unter ”Trunk Sequence” wird definiert, welcher Trunk für die unter ”Dial Patterns” festgelegten Rufnummern benutzt wird.
In diesem Fall soll der eben definierte ”CAPI/ISDN1/$OUTNUM$” verwendet
werden!
Inbound Route
Wie bereits erwähnt, wird durch eine ”Inbound Route” definiert, wie das System auf
eingehende Anrufe reagiert.
Über die ISDN-Karte kommen Gespräche rein, welche einer MSN (Multiple Subscriber
Number) zugeordnet sind. Dies können bei ISDN durchaus mehrere verschiedene MSNs
sein, weshalb in einem solchen Fall für jede dieser MSNs eine entsprechende Regel
definiert werden muss.
Nach einem Klick auf ”Inbound Routes” in der linken Navigationsleiste, lässt sich eine
neue Regel erstellen. Folgende Eingaben sind dabei zu tätigen:
• Edit Incoming Route - Description
Eine Beschreibung/Namen der Regel festlegen.
• Edit Incoming Route - DID Number
Hier muss die entsprechende MSN eingetragen werden, auf welche mit dieser
Regel reagiert werden soll!
• Edit Incoming Route - CID name prefix
Hier kann ein entsprechender Kontext eingetragen werden, welcher dem Angerufenen mitteilt, dass das ankommende Gespräch, über die ISDN-Karte ankommt.
Beispiel: ”via ISDN”. Dem Angerufenen wird ein ankommender Anruf dann wie
folgt signalisiert:
”via ISDN - XXXX”, wobei XXXX für die Rufnummer des Anrufers steht!
9 Anhang
189
• Set Destination
Hier wird festgelegt, was mit dem Anruf passiert, beispielsweise kann der Anruf
auf eine bestimmte (vorher definierte) Extension (siehe 9.3.4) geroutet werden.
Ein Klick auf ”Submit” speichert die Änderungen.
Ein anschließender Klick auf ”Apply Configuration Changes” startet den Server neu
und anschließend sollte die Kommunikation via ISDN funktionieren!
Weiterführende Informationen zu diesem Kapitel:
- https://www.pug.org/index.php/Kategorie:VoIP
- www.freepbx.org/support/documentation
9 Anhang
190
9.3.6 Einrichten von Diensten
9.3.6.1 Mailbox - Voicemail
Ein Mehrwertdienst des eingerichteten VoIP-Netzes soll ein Anrufbeantworter sein,
welcher auf Wunsch die auf die Mailbox gesprochenen Nachrichten dem (nicht erreichten) Nutzer zusendet.
Dabei wird der auf die Mailbox gesprochene Text in eine Audiodatei gewandelt und
der Angerufenen, aber nicht erreichten, Person als Benachrichtigungsmail zugestellt,
an welche diese Audiodatei als Anhang beigefügt ist. Die Funktion des automatischen
Versands von Benachrichtigungsmails durch das System ist eine Standardfunktion von
Asterisk, welche aber Unterstützung des Systems benötigt, ein Mailserver muss eingerichtet werden (realisiert durch die Verwendung von Postfix, siehe 9.3.1.3.
Einrichten von Voicemail in FreePBX
Im ersten Schritt muss das Modul ”Voicemail” über den ”Modul Admin” installiert
werden, sofern dies noch nicht geschehen ist.
Anschließend kann jedem Nutzer eine Mailbox zugeordnet und konfiguriert werden.
Die Dauer, wie lang ein Telefon klingelt, bevor die Mailbox das Gespräch ”übernimmt”,
kann in den ”General Settings” (dort unter ”Voicemail ”) eingestellt werden. Der Standardwert sind 15 Sekunden.
Aktivieren der Mailbox
Die Mailbox jedes Nutzers/jeder Extension kann einfach eingerichtet werden. Dazu
einfach über ”Extensions” klicken und anschließend die entsprechende Extension auswählen. Dort müssen dann folgende Einstellungen getätigt werden:
Abbildung 9.6: Voicemail - Konfiguration
9 Anhang
191
• Status
..auf ”Enabled” setzen, um die Mailbox für diese Extension zu aktivieren
• Voicemail Password
hier das Passwort für die Mailbox eintragen
• Email Address
hier die E-Mail-Adresse eintragen, an welche die Benachrichtigungsmails versandt
werden soll
• E-Mail-Attachement
entscheidet, ob die auf die Mailbox gesprochene Nachricht an die E-Mail angehangen werden soll
Abrufen der Mailbox
Die Mailbox kann bequem per Telefon oder per Webbrowser abgerufen werden:
• per Webbrowser
durch Aufrufen folgender Adresse:
http://xx.xx.xx.xx/recordings/index.php, wobei xx.xx.xx.xx durch die IPAdresse/den Namen des verwendeten VoIP-Servers ersetzt wird.
Dort können auch verschiedene Einstellungen durch den Mailboxinhaber angepasst werden!
• per (SIP)-Telefon
durch Wählen der vorher definierten Strings
Default: ”*98” = allgemeine Mailbox, ”*97” = meine Mailbox, identifiziert anhand
meiner Telefonnummer
Anpassen der System-E-Mail
Nachdem auf der Mailbox eine Nachricht hinterlassen wurde, wird automatisch eine
Benachrichtigung durch das System per E-Mail versandt, an welche die Nachricht optional angehangen ist.
Den Betreff und den Inhalt der E-Mail kann an die eigenen Vorstellungen angepasst
werden. Dazu bedarf es einer Anpassung der Datei /etc/asterisk/voicemail.conf:
• Anpassen des Betreffs der E-Mail durch modifizieren des Tags ”email-subject”
• Anpassen des Inhaltes der E-Mail durch modifizieren des Tags ”email-body”
Weiterführende Links zum Thema ”Voicemail”:
www.asteriskguru.com/tutorials/voicemaile conf.html
www.freepbx.org/support/documentation/module-documentation/voicemail-module
9 Anhang
192
9.3.6.2 Music on Hold
”Music on Hold” (Abkürzung: MoH) ist ein Dienstmerkmal, welches einem Anrufer
Musik vorspielt, sobald er sich zum Beispiel in einer Warteschlange befindet oder ”geparkt” wurde.
Dabei werden Musikstücke im ”.wav” oder ”.mp3”-Format aus einem bestimmten Ordner abgespielt. Dafür muss allerdings ”lame” installiert sein, ein Programm welches die
Musikstücke in einen Audiostream umwandelt, welcher dem Anrufer vorgespielt wird.
Einrichten von ”lame”
cd /usr/src
wget http://garr.dl.sourceforge.net/sourceforge/lame/lame-3.98b8.tar.gz
tar zxf lame-3.98b8.tar.gz
cd lame-3.98b8
./configure
make
make install
Einrichten von ”MoH” in FreePBX
Zunächst wird das Modul ”Music on Hold” über den ”Modul Admin” installiert, sofern
dies noch nicht geschehen ist.
Wenn dies ausgeführt wurde, erscheint, nach einem Klick auf ”Music on Hold” in der
linken Navigationsleiste, das MoH-Konfigurationsmenü. Dort können verschiedene Musikkategorien angelegt und mit entsprechenden Musikstücken ”gefüllt” werden.
Hierbei sollte beachtet werden, dass für das Abspielen bestimmter Musikstücke Gebühren an die GEMA (Gesellschaft für musikalische Aufführungs- und mechanische
Vervielfältigungsrechte) abgeführt werden müssen. Um dies zu umgehen, sollte GEMAfreie Musik verwendet werden, welche leicht im Internet zu finden ist!
Zuweisen von MoH
Nachdem verschiedene MoH-Gruppen definiert und mit Musik ”gefüllt” sind, werden diese Gruppen nun bestimmten Nutzern, Extensions oder Gruppen zugeordnet.
Auch ist es möglich, jedem Nutzer eine eigene MoH-Gruppe (mit ausgewählten Musikstücken) zuzuweisen.
Die Zuweisung erfolgt direkt in den Untermenüs von ”Extensions”, ”Outbound Routes”
und ”Inbound Routes”.
9 Anhang
193
Weiterführende Links zum Thema ”Music on Hold”:
Lame:
http://lame.sourceforge.net/index.php
GEMA:
www.gema.de
Music on Hold:
www.das-asterisk-buch.de/2.0/musiconhold.conf.html
www.freepbx.org/support/documentation/module-documentation/music-on-hold
9.3.6.3 Halten, Makeln, und Transfer von Gesprächen
Halten und Makeln
Halten und Makeln gehören zu den Standardfunktionen vieler Endgeräte (Dienste in
den Endgeräten implementiert). Die im Rahmen dieser Arbeit verwendeten Softphones
(X-Lite, Wengophone, SJphone) unterstützen alle ”Halten” und ”Makeln”.
Transfer, Weiterleiten
Weiterleiten oder Transfer von Gesprächen ist auch von den verwendeten Endgeräten
abhängig. Die Softphones X-Lite und Wengophone unterstützen dies nicht, SJphone
hingegen schon.
9.3.6.4 Konferenzschaltungen
Dreierkonferenz (Three Party (3PTY))
Eine Dreierkonferenz ist eine Konferenzschaltung zwischen 3 verschiedenen Teilnehmern. Viele Endgeräte haben diese Funktion bereits implementiert. Alle verwendeten
Softphones unterstützen dieses Feature!
Telefonkonferenzen
Telefonkonferenzen ermöglichen Gespräche mit mehr als 3 Teilnehmern. Um einen Konferenzdienst zu implementieren, muss das Modul ”Conferences” installiert werden. Anschließend lassen sich im Menüpunkt ”Conferences” Extensions anlegen, hinter welchen
Konferenzräume abgebildet sind.
Hinweis:
Für den Betrieb von Konferenzräumen, ist ein ”Timing Interface” nötig. Ein solches
”Timing Interface” ist das Modul ”ztdummy”. Geladen wird das Modul durch den Be-
9 Anhang
194
fehl ”modprobe ztdummy”. Allerdings muss das Modul nach jedem Neustart manuell
installiert werden. Ein automatisches Laden des Moduls beim Systemstart geschieht
durch Hinzufügen der Zeile ”modprobe ztdummy” in der Datei ”/etc/rc.local”.
Weiterführende Links zum Thema ”Konferenzräume”:
www.freepbx.org/support/documentation/module-documentation/conferences-meetme
www.das-asterisk-buch.de/1.0/applikationen-meetme.html
9.3.6.5 Parallelruf, Ring Groups
Eine ”Ring Group” signalisiert einen Anruf an mehreren Endgeräten, vergleichbar mit
dem Dienstmerkmal ”Parallelruf” der Deutschen Telekom im öffentlichen Telefonnetz.
Nach der Installation durch den ”Modul Admin” kann durch nach einem Klick auf
”Ring Groups” eine solche erstellt werden:
Dabei wird eine Nummer definiert, unter welcher mehrere Extensions addressiert werden. Anschließend muss festgelegt, welche Extensions in dieser ”Ring Group” zugehörig
sind und nach welcher ”Klingelstrategie” vorgegangen wird.
Folgende Klingelstrategien sind auswählbar:
• ringall
Es klingelt an allen angegebenen Extensions, bis der Anruf an einer Extension
angenommen wird!
• hunt
Es klingelt an allen verfügbaren/freien Extensions, bis der Anruf an einer Extension angenommen wird!
• memoryhunt
Es klingelt an allen angegebenen Extensions der Reihe nach, bis der Anruf an
einer Extension angenommen wird!
”Ring Groups” kommen zum Beispiel in kleineren Firmen zum Einsatz, welche eine
Rufnummer geschalten haben um damit einen beliebigen Mitarbeiter einer bestimmten Abteilung zu erreichen.
Weiterführende Links zum Thema ”Ring Groups”:
www.freepbx.org/support/documentation/module-documentation/ring-groups
9 Anhang
195
9.3.6.6 Blacklist
Eine Blacklist sperrt vorher definierte Rufnummern, d.h. Anrufer mit einer Nummer,
welche auf der Blacklist steht, werden abgewiesen.
Zum Einrichten einer Blacklist, einfach das Modul ”Blacklist” über den ”Modul Admin”
installieren. Anschließend können ausgewählte Telefonnummern zur Blacklist hinzugefügt werden.
Weiterführende Links zum Thema ”Blacklist”:
www.freepbx.org/support/documentation/module-documentation/blacklist
9.3.6.7 Tag- und Nachtschaltung
Mit der Tag- und Nachtschaltung kann auf Anrufe, entsprechend der Tages-/Uhrzeit,
unterschiedlich reagiert werden!
Die Einrichtung dieser Funktion wird, wie bereits aus den vorherigen Abschnitten bekannt, über den ”Modul Admin” realisiert. Dort muss das Feature ”Day/Night Control”
ausgewählt und installiert werden.
Anschließend können über das ”Day/Night Control”-Modul bis zu 10 verschiedene Modi
definiert werden, welchen jeweils eine spezifische Tag-/Nachtaktion zugewiesen werden
darf.
Aktiviert werden diese Modi durch den Nutzer durch die Eingabe eines bestimmten
Tastencodes, d.h. durch Eingabe dieses Codes kann zwischen Tag- und Nachtmodus
gewechselt werden.
Im Anhang (9.5) ist eine Beispielkonfiguration abgebildet.
Weiterführende Links zum Thema ”Tag- und Nachtschaltung”:
www.freepbx.org/support/documentation/module-documentation/
day-night-mode-control
www.freepbx.org/news/2007-07-05/using-the-day-night-control-with-a-time-condition
9.3.6.8 IVR - digitaler Sekretär
Das IVR-Modul (IVR=Intelligent Digital Receptionist) stellt nach Installation eine
Möglichkeit zur Verfügung, hinter einer Rufnummer mehrere verschiedene Aktionen
abzubilden. So kann der Anrufer, nach Wählen der bestimmten Rufnummer, in ein
Sprachmenü geleitet und abhängig der anschließend eingegebenen Ziffer entsprechend
weitergeführt werden!
9 Anhang
196
Allerdings bietet das IVR-Modul von sich aus kein Sprachmenü (engl. Voice menu).
Nach dem Erstellen eines entsprechenden Audiofiles, welches die verschiedenen Auswahlmöglickeiten akustisch wiedergibt, kann dieses leicht eingebunden und ein ”echtes
Sprachmenü” erstellt werden!
Ein Einsatzszenario für ein Sprachmenü mit Hilfe des IVR, ist das herausfiltern von
SPIT-Bots. SPIT-Bots sind automatisierte Anrufe an beliebige Rufnummern, mit festen Ansagen und ohne ”Intelligenz”. Vor jede von außen (öffentliches Festnetz) erreichbare Rufnummer kann ein Sprachmenü geschalten werden, was vom Anrufer die
Eingabe einer beliebigen Zahl fordert, um den angewählten Teilnehmer zu erreichen.
Eine Beispielkonfiguration für einen IVR ist im Anhang zu finden (9.6). Dieses Beispiel
bietet die Möglichkeit, nach Anwahl einer Rufnummer, zwischen 2 weiteren Rufnummern zu wählen (1:2 Abbildung).
Nach der Defintion einer IVR-Regel, muss diese einer entsprechenden Rufnummer zugewiesen werden. Dieses geschieht im Menü ”Inbound Routes”, wo nach der Installation
des Moduls ein entsprechendes Kontextmenu für IVR verfügbar ist.
Praktischen Einsatz findet dieses Feature, wenn beispielsweise nur eine Festnetztelefonnummer zur Verfügung steht, aber mehrere Personen ”dahinter” erreicht werden sollen.
Weiterführende Links zum Thema ”IVR - digitaler Sekretär”:
http://www.freepbx.org/support/documentation/
module-documentation/ivr-digital-receptionist
9.3.6.9 Anrufweiterschaltung - Call Forwarding
Mit diesem Leistungsmerkmal wird die (automatische) Weiterleitung von Gesprächen
auf andere Rufnummern ermöglicht.
In Asterisk ist eine Differenzierung zwischen verschiedenen Situationen möglich:
• Generelle Rufumleitung auf eine bestimmte Nummer
Rufumleitung auf eine andere Nummer ist ständig aktiviert.
Standardwerte: ”*72” zum Aktivieren, ”*73” zum Deaktivieren
• Rufumleitung bei Besetzt auf eine bestimmte Nummer
Anruf wird auf eine andere, frei wählbare Rufnummer umgeleitet, falls besetzt
ist.
• Rufumleitung bei Nichterreichen auf eine bestimmte Nummer
Weiterleiten des Anrufs auf einen anderen Anschluss, falls der Anruf nach einer
9 Anhang
197
bestimmten Zeit nicht angenommen wurde.
Die entsprechenden Tastaturcodes können von jedem Anschluss eingegeben und die
Nummer, auf welche umgeleitet werden soll, frei gewählt werden. Unter ”Feature Codes” können diese Tastaturcodes geändert werden.
Weiterführende Links zum Thema ”Tag- und Nachtschaltung”:
www.freepbx.org/support/documentation/module-documentation/feature-codes
9.3.6.10 DND - Bitte nicht stören
Diese Funktion signalisiert dem System, das der Teilnehmer nicht erreichbar ist. Ankommende Anrufe werden automatisch an die Mailbox weitergeleitet. Aktiviert wird
diese durch einen Klick auf den ”DND”-Button des jeweiligen Endgerätes.
Die Softphones X-Lite und SJphone bieten dieses Feature von Haus aus an!
9.3.6.11 Queues - Warteschlangen
Der Queues-Dienst parkt ankommende Anrufe in einer Warteschlange, bis der Anruf
an entsprechende Teilnehmer durchgestellt werden kann. Bekanntestes Beispiel sind
Warteschlangen in Call-Centern. Anrufer werden nach Anwahl einer Nummer (HotlineNummer) in eine Warteschlange einsortiert und an den nächsten freien Mitarbeiter
durchgestellt. Unterschieden wird bei Warteschlangen zwischen ”Anrufern” (Kunden)
und ”Agenten” (Mitarbeiter des Call-Centers), welche die Anrufe entgegennehmen.
Nach der Installation des Moduls ”Queues” über den ”Modul Admin”, kann eine Queue
definiert werden. Wichtige Angaben bei der Definition einer Queue:
• Queue Number:
Rufnummer, unter welcher die Queue erreicht wird
• Queue Name:
Hier kann der Queue ein Name zur besseren Identifikation zugeordnet werden
• Queue Password:
Durch ein hier definiertes Passwort wird die Queue ”geschützt”. Die Eingabe dieses Passworts ist erforderlich, wenn sich ein beliebiger Teilnehmer (Mitarbeiter)
als Agent in die Queue einklinken möchte.
9 Anhang
198
• CID Name Prefix:
Durch diesen Eintrag können beim Agenten ankommende Anrufe bestimmten
Queues zugeordnet werden. Beispielsweise ”Vertrieb” oder ”Marketing”
• Static Agents:
Hier werden Extensions hinzufügt, welche als ”feste Agenten” ständig dieser
Queue zugeordnet sind. Feste Agenten brauchen sich deshalb nicht in die Queue
einwählen.
Neben den ”festen Agenten” kann sich jeder beliebige Mitarbeiter als Agent in die
Queue einwählen:
• Einwählen in die Queue durch Wählen von: ”Queue-Rufnummer+*”
• Verlassen der Queue durch Wählen von: ”Queue-Rufnummer+**”
Weiterführende Links zum Thema ”Queues”:
www.freepbx.org/support/documentation/module-documentation/queues
9.3.6.12 Follow Me
Mit der Funktion ”Follow Me” ist es möglich, eine Liste von Rufnummern zu hinterlegen, unter welcher ein Teilnehmer erreichbar ist. Diese werden bei einem eingehenden
Anruf gleichzeitig oder in einer definierten Reihenfolge angewählt, bis der Teilnehmer
erreicht ist.
9 Anhang
199
9.4 Ausgabe von Capiinfo
Abbildung 9.7: Ausgabe von capiinfo
9 Anhang
200
9.5 Beispielkonfiguration einer Tag/Nachtschaltung
Abbildung 9.8: Beispielkonfiguration für den Tag/Nacht-Modus
Wie leicht zu erkennen ist, wird im Tag-Betrieb ein Anruf an die Extension 200
(Nutzer ”Idefix”) weitergeleitet, während im Nacht-Betrieb der Anruf sofort an die
Mailbox weitergeleitet wird.
Durch den Tastencode ”*281” kann zwischen Tag- und Nacht-Modus umgeschalten
werden.
9 Anhang
201
9.6 Beispielkonfiguration des IVR-Moduls
Abbildung 9.9: Definieren eines ”digitales Sekretärs”
Diese Einstellung mit Namen ”IVR - 2 Nummern” stellt 2 Auswahlmöglichkeiten zur
Verfügung:
Durch drücken der ”1” wird Extension ”201 - Verleihnix” gewählt, bei ”2” die Extension
”200 - Idefix”. Andere Aktionen lassen sich leicht festlegen.
9 Anhang
202
9.7 Angriffsmöglichkeiten und bedrohte
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Verfügbarkeit
Vertraulichkeit
MAC Spoofing
MAC Flooding
ARP Spoofing
STP BPDU-Attacke
STP-Umleitung
VLAN rouge Trunk
VLAN Hopping
IP Spoofing
ICMP Redirect
IRDP Spoofing
Route Injection
HSRP-Angriffe
VRRP-Angriffe
DHCP Starvation
DHCP rouge Server
SYN Flood
Land Flood
Ping Flood
Fragmentierungs Attacken
Authentizität
Datenintegrität
Sicherheitsziele
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabelle 9.2: Angriffsmethoden und bedrohte Sicherheitsziele
Eine ausführliche Beschreibung der aufgeführten Angriffe, ist hier zu finden: [33].
9 Anhang
203
Erklärung:
Die vorliegende Arbeit ist eine Kollektivarbeit.
Von Daniel Ruf wurden folgende Abschnitte bearbeitet:
• ”1 - Einleitung und Motivation” (1)
• ”2 - PSTN - öffentliche Telefonnetze” (2) (außer 2.4, 2.5)
• ”3 - VoIP” (3) (außer 3.2.2.2, 3.2.2.3, 3.2.2.4, 3.2.3, 3.3 )
• ”4 - Vergleich von VoIP und PSTN” (außer 4.4)
• ”5 - Konzepte” (5)
• ”6 - Einrichten eines VoIP-Netzes auf Basis von ”Asterisk”” (6)
Von Sebastian Güttner wurden folgende Abschnitte bearbeitet:
• ”2.4 IN” (2.4), ”2.6 NGN” (2.5)
• ”3.2.2.2, 3.2.2.3, 3.2.2.4,3.2.3,3.3
• ”4.4 - Quality of Service” (4.4)
• ”7 - Entwicklungsumgebung” (7)
Wir erklären, dass wir diese Arbeit selbstständig durchgeführt und abgefasst haben.
Quellen, Literatur und Hilfsmittel, die von uns benutzt wurden, sind als solche gekennzeichnet.
Ilmenau, den 29.Mai 2008

Technische Universität Ilmenau Fakultät für Elektrotechnik und

Transcription

Similar documents

NOTAM der SwissAirways-VA vom 16.01.2011 Aus dem Vorstand

Mobile Systems II - Merlin

deutsch einleitung - JAY-tech

AV-9740

Westfalia Bedienungsanleitung Nr. 109956

Interbook GmbH

Mobile Systems II - Universität Zürich

Karriere im privaten Sicherheitsgewerbe – Wäre dies das Richtige

Heterogene Netze - Universität Paderborn

XCAPI Version 3.4. - te

thesis - LMU München

WTS Review FreePDF XP

- Institut für Telematik

Medienprojekt