Badach
Voice over IP Die Technik
www.wiwobooks.com
v
Bleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos und Updates erhalten.
www.wiwobooks.com
Anatol Badach
Voice over IP Die Technik Grundlagen, Protokolle, Anwendungen, Migration, Sicherheit 4., überarbeitete und erweiterte Auflage
www.wiwobooks.com
Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autor und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
www.wiwobooks.com
Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. © 2010 Carl Hanser Verlag München Wien (www.hanser.de) Lektorat: Margarete Metzger Herstellung: Irene Weilhart Umschlagdesign: Marc Müller-Bremer, www.rebranding.de, München Umschlagrealisation: Stephan Rönigk Datenbelichtung, Druck und Bindung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent-Nr. 0748702 Printed in Germany
ISBN 978-3-446-41772-4
Inhalt 1
Vom einfachen Telefon bis zu Next Generation Networks ................. 1
1.1
Vom Telefon bis zum intelligenten Netz............................................................. 2 1.1.1 Erfindung des Telefons ........................................................................... 2 1.1.2 Vom analogen Telefonnetz zum ISDN ................................................... 4 1.1.3 Vom ISDN zum Intelligenten Netz ......................................................... 6
1.2
Ansätze für VoIP ................................................................................................. 8 1.2.1 Allgemeines über Internet-Telefonie....................................................... 9 1.2.2 Erweiterung von ISDN mit einem IP-Netz ........................................... 11 1.2.3 IP-Netz als Backbone für PSTN/ISDN ................................................. 13 1.2.4 Kleines IP-Netzwerk als IP-TK-Anlage................................................ 15
1.3
Evolution der Mobilfunknetze........................................................................... 19 1.3.1 Aufbau der Mobilfunknetze nach GSM ................................................ 20 1.3.2 Aufbau von GPRS................................................................................. 22 1.3.3 Konzept von UMTS .............................................................................. 23 Vereinfachte Architektur von UMTS.................................................... 24 UMTS-Ausbau und IMS ....................................................................... 25
1.4
VoIP und Konvergenz der Netze....................................................................... 26 1.4.1 Von Singleservice-Netzen zum Multiservice-Netz ............................... 26 1.4.2 Integration von Internet mit Intelligent Network .................................. 29 PINT...................................................................................................... 29 SPIRITS ................................................................................................ 31 1.4.3 Gateway-Plattformen und Migration zu NGNs..................................... 32 1.4.4 Konzept von Parlay/OSA ...................................................................... 35 1.4.5 Konzept von JAIN................................................................................. 39
1.5
IMS als Kern von Next Generation Networks................................................... 41 1.5.1 Allgemeines Konzept von IMS ............................................................. 42 1.5.2 Mobilität von Benutzern in NGNs ........................................................ 43 1.5.3 Registrierung der Lokation eines Benutzers.......................................... 45 1.5.4 VoIP-Session zwischen Benutzern........................................................ 47
1.6
VoIP-Aktivitäten bei Standardisierungsgremien, Organisationen und Foren.... 48 1.6.1 IETF und Internet-Standards................................................................. 48 Organisation der IETF........................................................................... 48 Working Groups mit VoIP-relevanten Themen .................................... 49 1.6.2 ITU-T und Telekommunikationsstandards............................................ 51 Organisation des ITU-T ........................................................................ 51 VoIP-betreffende SGs beim ITU-T....................................................... 52
www.wiwobooks.com
VI
Inhalt
1.6.3 1.6.4
ETSI und VoIP ......................................................................................53 Organisationen und Foren mit VoIP-Aktivitäten...................................54
1.7
Schlussbemerkungen..........................................................................................55
2
Signalisierung in Telefonnetzen und ISDN ........................................ 57
2.1
Signalisierung in Telefonnetzen.........................................................................58
2.2
ISDN-Konzept ...................................................................................................60 2.2.1 ISDN-Schnittstellen...............................................................................61 2.2.2 Protokollbereiche im ISDN ...................................................................62
2.3
D-Kanal-Protokoll..............................................................................................63 2.3.1 Schicht 3 des D-Kanal-Protokolls..........................................................64 2.3.2 Auf- und Abbau einer ISDN-Verbindung..............................................66
2.4
Signalisierungssystem Nr.7................................................................................68 2.4.1 Funktionsteile von SS7 ..........................................................................70 2.4.2 Funktionelle Struktur von SS7...............................................................71 2.4.3 SS7-Verlauf beim Auf- und Abbau einer ISDN-Verbindung................73
2.5
Schlussbemerkungen..........................................................................................75
3
TCP/IP- und VoIP-Protokolle............................................................. 77
3.1
Protokollfamilie TCP/IP.....................................................................................78
3.2
Prinzip der Kommunikation im Internet ............................................................80 3.2.1 Bildung von IP-Paketen .........................................................................81 3.2.2 Prinzip der Kommunikation im Internet ................................................82 3.2.3 Interpretation von IP-Adressen..............................................................83 3.2.4 Zweistufige Adressierung ......................................................................84
3.3
Internet-Protokoll IP ..........................................................................................85
3.4
Transportprotokolle in IP-Netzen.......................................................................86 3.4.1 Verbindungsloses Transportprotokoll UDP...........................................87 Nachteil der UDP-Fehlerkontrolle bei VoIP..........................................88 UDP-Lite ...............................................................................................89 3.4.2 Verbindungsorientiertes Transportprotokoll TCP .................................90 TCP-Nutzung.........................................................................................91 Aufbau und Abbau einer TCP-Verbindung ...........................................93
3.5
Einsatz von DNS................................................................................................95 3.5.1 Aufbau des DNS-Namensraums ............................................................96 3.5.2 Resource Records ..................................................................................97 3.5.3 Beispiel für eine Namensauflösung .......................................................98 3.5.4 Ermittlung des SIP-Proxy in einer anderen Domain..............................99
3.6
Protokolle für VoIP – eine Übersicht ...............................................................102
www.wiwobooks.com
Inhalt
3.7
Bedeutung des Protokolls SCTP...................................................................... 105 3.7.1 SCTP versus UDP und TCP................................................................ 105 3.7.2 SCTP-Assoziationen ........................................................................... 106
3.8
ENUM – Konzept und Einsatz ........................................................................ 108 3.8.1 Bildung von ENUM-Domainnamen und NAPTR-RRs ...................... 110 3.8.2 Beispiele für den ENUM-Einsatz........................................................ 112
3.9
Schlussbemerkungen ....................................................................................... 114
4
VoIP und QoS in IP-Netzen ............................................................... 115
4.1
QoS-Anforderungen bei VoIP ......................................................................... 116 4.1.1 Einflussfaktoren auf die VoIP-Qualität ............................................... 116 4.1.2 Ende-zu-Ende-Verzögerung................................................................ 117 4.1.3 Übermittlungszeit über ein IP-Netz..................................................... 121 4.1.4 Jitter-Ausgleichpuffer und Paketverluste ............................................ 123
4.2
Verfahren zur Garantie von QoS-Anforderungen............................................ 124
4.3
Priorisierung von MAC-Frames ...................................................................... 125
4.4
Differentiated Services .................................................................................... 126 4.4.1 Differenzierung der IP-Pakete............................................................. 127 4.4.2 DiffServ-Domäne und -Region ........................................................... 128
4.5
Queue-Management......................................................................................... 130 4.5.1 Priority Queueing ................................................................................ 133 4.5.2 Custom Queueing................................................................................ 134 4.5.3 Fair Queueing...................................................................................... 137 4.5.4 Weighted Fair Queueing ..................................................................... 139 4.5.5 Class-based Weighted Fair Queueing ................................................. 140
4.6
Einsatz von RSVP ........................................................................................... 142
4.7
Schlussbemerkungen ....................................................................................... 145
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP ... 147
5.1
Sprachcodierung bei VoIP............................................................................... 148 5.1.1 Abtastwert-orientierte Sprachcodierung.............................................. 150 5.1.2 Prinzipien der Quantisierung............................................................... 153 5.1.3 Nichtlineare Quantisierung bei PCM .................................................. 154 5.1.4 Nachbildung der Spracherzeugung ..................................................... 157 5.1.5 Segment-orientierte Sprachcodierung ................................................. 159 5.1.6 VoIP-relevante Sprachcodierungsverfahren........................................ 161 5.1.7 Sprachqualität nach MOS-Skala ......................................................... 163
5.2
Protokolle für Sprachübermittlung .................................................................. 164 5.2.1 Bedeutung einer Session ..................................................................... 165 5.2.2 RTP/RTCP und Transportprotokolle der IP-Netze ............................. 168
www.wiwobooks.com
VII
VIII
Inhalt
5.3
Konzept und Funktionen von RTP...................................................................171 5.3.1 Aufbau von RTP-Paketen ....................................................................172 5.3.2 Statische und dynamische Payload-Typen...........................................174 5.3.3 Zeitstempel – Berechnung und Nutzung..............................................176 Berechnung von Zeitstempel für RTP-Pakete .....................................177 Nutzung von Zeitstempel in RTP-Paketen ..........................................178
5.4
Translator und Mixer .......................................................................................180 5.4.1 Translator-Einsatz................................................................................180 5.4.2 Mixer-Einsatz ......................................................................................181
5.5
Protokoll RTCP................................................................................................182 5.5.1 Funktion von RTCP.............................................................................183 5.5.2 Typen der RTCP-Pakete ......................................................................184 5.5.3 Struktur der RTCP-Pakete ...................................................................184 5.5.4 Sender-Report (SR) .............................................................................185 Angaben im SR-Header .......................................................................187 Sender-Informationen ..........................................................................187 Angaben in Report Blocks...................................................................188 5.5.5 Receiver Report (RR) ..........................................................................188 5.5.6 Einsatz von RTCP XR und VoIP-Metriken.........................................189
5.6
Abschätzung von QoS-Parametern ..................................................................191 5.6.1 Garantie der Isochronität .....................................................................192 5.6.2 Abschätzung von Jitter ........................................................................193 5.6.3 Abschätzung des Round-Trip Time .....................................................194 5.6.4 Aussage über die Häufung von Paketverlusten....................................196 5.6.5 E-Modell von der ITU-T .....................................................................197
5.7
Secure Real-time Transport Protocol (SRTP) ..................................................198 5.7.1 Sicherheitsfunktionen von SRTP.........................................................199 5.7.2 Key-Management-Protokoll und SRTP...............................................200 5.7.3 Gesicherte Kommunikation nach SRTP ..............................................202 5.7.4 Prinzip der Integritätsprüfung und Authentifizierung..........................204 5.7.5 SRTP- und SRTCP-Pakete ..................................................................205 5.7.6 Session Keys bei SRTP .......................................................................206 5.7.7 Vorbereitung eines RTP-Pakets zum Senden ...................................... 208 5.7.8 Bearbeitung eines empfangenen RTP-Pakets ...................................... 210 5.7.9 Schritte bei der Bearbeitung eines RTP-Pakets ................................... 211
5.8
Kompression des RTP/UDP/IP-Headers..........................................................212 5.8.1 Bedeutung von CRTP und ROHC .......................................................213 5.8.2 Konzept der Kompression des RTP/UDP/IP-Headers.........................214 5.8.3 Kompression und Dekompression nach CRTP....................................216 5.8.4 Besonderheiten von ROHC .................................................................220
5.9
Schlussbemerkungen........................................................................................221
www.wiwobooks.com
Inhalt
6
VoIP nach dem Standard H.323........................................................ 223
6.1
Systemkomponenten nach H.323 .................................................................... 224 6.1.1 H.323-Domains ................................................................................... 225 6.1.2 Protokollfamilie TCP/IP und H.323.................................................... 226 6.1.3 Sprach- und Videocodierung in H.323-Systemen ............................... 228 6.1.4 Arten von Kanälen bei der Multimedia-Kommunikation.................... 229
6.2
Signalisierung nach H.323............................................................................... 230 6.2.1 Schritte vor der Audio/Video-Übermittlung ....................................... 231 6.2.2 Schritte nach der Audio/Video-Übermittlung ..................................... 232 6.2.3 Fast Connect Procedure....................................................................... 233
6.3
Realisierung von RAS-Funktionen.................................................................. 236 6.3.1 Gatekeeper-Entdeckung ...................................................................... 237 6.3.2 Registrierung und Deregistrierung beim Gatekeeper .......................... 238 6.3.3 Zulassung von Verbindungen.............................................................. 239 6.3.4 Abfrage der IP-Adresse eines Endpunktes .......................................... 241
6.4
Signalisierung der Anrufe nach H.225.0 ......................................................... 242 6.4.1 Struktur von Anruf-SIG-Nachrichten beim H.225.0 ........................... 243 6.4.2 Anrufsignalisierung ohne Gatekeeper ................................................. 243 6.4.3 Direkte Anrufsignalisierung beim Gatekeeper-Einsatz ....................... 245 6.4.4 Über Gatekeeper geroutete Anrufsignalisierung ................................. 246 6.4.5 VoIP im Verbund mit ISDN................................................................ 248
www.wiwobooks.com
6.5
Einsatz des Protokolls H.245........................................................................... 249 6.5.1 Beschreibung von Terminal-Fähigkeiten ............................................ 250 6.5.2 Austausch von Terminal-Fähigkeiten ................................................. 252 6.5.3 Master/Slave-Festlegung..................................................................... 252 6.5.4 Aufbau logischer Kanäle..................................................................... 253 6.5.5 Abbau logischer Kanäle ...................................................................... 254 6.5.6 Änderung von Eigenschaften einer Verbindung ................................. 255 6.5.7 Beispiel für einen Verlauf des Protokolls H.245................................. 256
6.6
Supplementary Services nach H.450.x ............................................................ 257 6.6.1 H.450.1 als Basis für Supplementary Services.................................... 259 6.6.2 Beispiele für Supplementary Services................................................. 260
6.7
Roaming bei VoIP nach H.323........................................................................ 262 6.7.1 Arten von Roaming ............................................................................. 262 6.7.2 Registrierung eines Gast-Teilnehmers ................................................ 264 6.7.3 Ankommender Anruf zu einem Gast-Teilnehmer ............................... 267 6.7.4 Abgehender Anruf aus einer Fremd-Domain ...................................... 269 6.7.5 Deregistrierung eines Gast-Teilnehmers ............................................. 270
6.8
Schlussbemerkungen ....................................................................................... 270
IX
X
Inhalt
7
VoIP mit SIP....................................................................................... 273
7.1
Verschiedene Aspekte des SIP-Einsatzes.........................................................274 7.1.1 SIP und verschiedene Transportprotokolle..........................................274 7.1.2 Wichtige SIP-Besonderheiten..............................................................276 7.1.3 Struktur von SIP-Adressen ..................................................................278 7.1.4 Funktion eines SIP-Proxy ....................................................................280 7.1.5 Trapezoid-Modell von SIP...................................................................282 7.1.6 SIP-Verlauf im Trapezoid-Modell.......................................................284 7.1.7 Unterstützung von Benutzermobilität ..................................................285 7.1.8 Erweiterter SIP-Proxy als B2BUA ......................................................287 7.1.9 Typischer SIP-Verlauf .........................................................................288 Angaben in SIP- Nachrichten ..............................................................290 SIP-Verlauf innerhalb einer Domain ...................................................293 SIP-Verlauf ohne Proxy.......................................................................293
7.2
Beispiele für den Einsatz von SIP ....................................................................294 7.2.1 Typischer Einsatz von SIP-Proxy-Servern ..........................................295 7.2.2 Umleitung einer Session mit Redirect-Server......................................296 7.2.3 Weiterleitung einer Session mit Proxy-Servern...................................298 7.2.4 Anrufverzweigung mit SIP ..................................................................299 7.2.5 Einsatz eines Voice-Mail-Servers........................................................301
www.wiwobooks.com
7.3
SIP-Nachrichten – ihre Bedeutung und Struktur..............................................303 7.3.1 Request-Typen.....................................................................................303 7.3.2 Response-Klassen ................................................................................306 7.3.3 Aufbau von SIP-Nachrichten...............................................................307 Struktur von SIP-Requests...................................................................307 Struktur von SIP-Responses ................................................................309 Wichtige Header-Felder.......................................................................310
7.4
Beschreibung von Sessions mit SDP ...............................................................313 7.4.1 Typischer Einsatz von SDP .................................................................314 7.4.2 Bestandteile der Beschreibung einer Session.......................................316 7.4.3 Beschreibung auf dem Session-Level..................................................320 7.4.4 Zeitspezifische Angaben......................................................................322 7.4.5 Beschreibung von Medien ...................................................................323
7.5
Betriebsarten bei SIP........................................................................................327 7.5.1 Proxy-Mode und Redirect-Mode .........................................................327 7.5.2 Einsatz von Proxy- und Redirect-Server..............................................328
7.6
Registrierung der Lokation von Benutzern ......................................................330
7.7
Sessionbezogene Leistungsmerkmale mit SIP .................................................332 7.7.1 Klassen der Leistungsmerkmale mit SIP .............................................332 7.7.2 Call Hold/Retrieve – Anhalten/Wiederaufnahme ................................336
Inhalt
7.7.3 7.7.4 7.7.5 7.7.6 7.7.7 7.7.8 7.7.9
Consultation Hold – Anhalten mit Rückfrage ..................................... 337 Call Park – Parken einer Session......................................................... 338 Call Pickup – Übernahme einer Session ............................................. 341 Call Forwarding – Weiterleitung einer Session................................... 342 Unattended Call Transfer .................................................................... 343 Attended Call Transfer ........................................................................ 344 SIP-Verlauf bei Rückruf...................................................................... 346
7.8
Response- und Request-Routing...................................................................... 348
7.9
Konvergenz der IP-Netze und ISDN ............................................................... 350 7.9.1 SIP und das D-Kanal-Protokoll........................................................... 351 7.9.2 SIP und Signalisierungssystem Nr. 7 .................................................. 352
7.10
Koexistenz von SIP und H.323........................................................................ 353
7.11
Schlussbemerkungen ....................................................................................... 355
8
VoIP-Gateways: Konzepte und Protokolle ...................................... 357
8.1
VoIP und klassische Systeme für Sprachkommunikation ............................... 358
8.2
Konzept von MGCP ........................................................................................ 360 8.2.1 Grundbegriffe bei MGCP.................................................................... 360 8.2.2 MGCP-Commands.............................................................................. 362 8.2.3 MGCP-Responses ............................................................................... 363 8.2.4 Auf- und Abbau einer VoIP-Session nach MGCP .............................. 364
8.3
Protokoll Megaco ............................................................................................ 368 8.3.1 Konzept von Megaco .......................................................................... 369 8.3.2 Megaco-Commands ............................................................................ 371 8.3.3 Auf- und Abbau einer VoIP-Session nach Megaco ............................ 372 8.3.4 Megaco und Integration von VoIP mit ISDN...................................... 374
8.4
Schlussbemerkungen ....................................................................................... 376
9
IP-Telefonie-Routing und VoIP-Peering .......................................... 377
9.1
Typische Probleme bei VoIP ........................................................................... 378 9.1.1 Routing ankommender Anrufe aus dem ISDN/PSTN......................... 379 9.1.2 Routing abgehender Anrufe ................................................................ 381
9.2
Konzept und Einsatz von TRIP ....................................................................... 382 9.2.1 Bedeutung von TRIP........................................................................... 383 9.2.2 TRIP als Bruder von BGP................................................................... 384
9.3
Vernetzung von VoIP-Zonen mit H.323.......................................................... 385 9.3.1 Routing abgehender Anrufe zwischen H.323-Zonen .......................... 385 9.3.2 Routing der Anrufe aus dem ISDN zu einer H.323-Zone ................... 387
9.4
Vernetzung von VoIP-Zonen mit SIP.............................................................. 388
www.wiwobooks.com
XI
XII
Inhalt
9.4.1 9.4.2
Routing der Anrufe zwischen VoIP-Zonen mit SIP ............................388 Routing der ISDN-Anrufe zu VoIP-Zonen mit SIP.............................389
9.5
Peering bei VoIP mit SIP .................................................................................390 9.5.1 Ziele und Arten von Peering................................................................390 9.5.2 Prinzip von Basic Peering....................................................................392 9.5.3 Integrated Peering versus Decomposed Peering ..................................393 9.5.4 Federation-based Peering.....................................................................394
9.6
Schlussbemerkungen........................................................................................396
10
Migration zum VoIP-Einsatz ............................................................ 397
10.1
Verschiedene Aspekte der Migration zu VoIP.................................................398 10.1.1 Sanfte Migration zu VoIP ....................................................................398 10.1.2 Harte Migration zu VoIP .....................................................................398 10.1.3 Typische Fälle bei der Migration zu VoIP...........................................399 10.1.4 Architekturmodelle der VoIP-Systeme................................................400
10.2
Hybride VoIP-Systemarchitekturen .................................................................402 10.2.1 Hybride VoIP-Systemarchitektur am Einzelstandort...........................402 10.2.2 Arten der Vernetzung von TK-Anlagen ..............................................403 Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung................403 Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung ...............404 10.2.3 Standortübergreifende hybride VoIP-Systemarchitekturen .................404 VoIP-Systemarchitekturen mit zentraler Anrufsteuerung....................404 VoIP-Systemarchitekturen mit verteilter Anrufsteuerung ...................405
www.wiwobooks.com
10.3
Reine VoIP-Systemarchitekturen.....................................................................406 10.3.1 Reine VoIP-Systemarchitektur am Einzelstandort ..............................408 10.3.2 Verkabelung für die Unterstützung von VoIP .....................................410 Getrennte Sprach- und Datenverkabelung ...........................................410 Gemeinsame Sprach- und Datenverkabelung ......................................411 10.3.3 Standortübergreifende reine VoIP-Systemarchitekturen .....................412 VoIP-Systemarchitektur mit zentraler Anrufsteuerung .......................412 VoIP-Systemarchitektur mit verteilter Anrufsteuerung .......................415
10.4
Auswahl einer VoIP-Systemlösung .................................................................416
10.5
Hauptschritte bei der Migration zu VoIP .........................................................417 10.5.1 Ist-Analyse bei der Migration zu VoIP................................................419 Organisatorische Aspekte der Ist-Analyse...........................................420 Technische Aspekte der Ist-Analyse....................................................421 10.5.2 Anforderungen an VoIP-System..........................................................423 Organisatorische Anforderungen .........................................................423 Technische Anforderungen..................................................................424 10.5.3 Komponenten des VoIP-Systemkonzeptes ..........................................425
Inhalt
10.6
VoIP mit SIP in Netzwerken mit NAT ............................................................ 426 10.6.1 Prinzipien von NAT ............................................................................ 427 10.6.2 Probleme mit SIP beim NAT-Einsatz ................................................. 429 10.6.3 Symmetric Response – Hilfe bei der Signalisierung ........................... 432 10.6.4 Symmetric RTP/RTCP – Hilfe beim Medientransport........................ 433 10.6.5 Einsatz von STUN............................................................................... 434 10.6.6 Nutzung von TURN ............................................................................ 437 10.6.7 ICE als Lösung des NAT-Problems .................................................... 439
10.7
Schlussbemerkungen ....................................................................................... 443
11
VoIP-Sicherheit................................................................................... 445
11.1
Probleme der VoIP-Sicherheit......................................................................... 446 11.1.1 Primäre Ziele der VoIP-Sicherheit ...................................................... 446 11.1.2 Verschiedene Aspekte der VoIP-Sicherheit ........................................ 448 11.1.3 Sicherheitsproblembereiche im Netzwerk........................................... 449 11.1.4 Phasen des VoIP-Sicherheitsprozesses ............................................... 451 11.1.5 Vorgehensweise bei der Planung der VoIP-Sicherheit........................ 452
11.2
Bedrohungstypen und Angriffsarten bei VoIP ................................................ 454 11.2.1 Typische Angriffe in Netzwerken ....................................................... 454 11.2.2 Typische Angriffe bei VoIP ................................................................ 456 Angriffe auf dem Anwendungsniveau ................................................ 456 Angriffe auf dem Niveau der Transportschicht................................... 458 Angriffe auf IP-Niveau ....................................................................... 458 Angriffe auf MAC-Niveau .................................................................. 459 Beispiele für einige Angriffe bei VoIP................................................ 459 Klassen der Angriffe auf VoIP-Systeme ............................................. 461 11.2.3 Lauschangriffe bei VoIP und Gegenmaßnahmen................................ 462 11.2.4 Abfangen und Modifikation von VoIP-Anrufen ................................. 463 11.2.5 Beeinträchtigen des VoIP-Dienstes..................................................... 466 11.2.6 Missbrauch des VoIP-Dienstes ........................................................... 466
11.3
Sicherheit bei VoIP mit SIP............................................................................. 468 11.3.1 Gefährdungen in VoIP-Systemen mit SIP........................................... 468 Registration Hijacking ........................................................................ 470 Session Hijacking – Entführung einer Session.................................... 472 Imitation eines SIP-Proxy-Servers ...................................................... 473 11.3.2 SIP Digest Authentication – Einsatz und Konzept.............................. 474 Prinzip der Authentifizierung nach SIP-Digest ................................... 474 Authentifizierung bei Registrierung.................................................... 476 Benutzer-Authentifizierung von einem Proxy..................................... 477 11.3.3 Einsatz von S/MIME bei SIP .............................................................. 478 Asymmetrische Kryptosysteme als Grundlage von S/MINE .............. 478
www.wiwobooks.com
XIII
XIV
Inhalt
Idee des S/MIME-Einsatzes bei SIP ....................................................479 Garantie der Vertraulichkeit bei SIP mit S/MIME ..............................480 Signierung von SIP-Nachrichten .........................................................481 11.4
Ermittlung des Schutzbedarfs bei VoIP ...........................................................482 11.4.1 Beschreibung der Sicherheitsschwachstelle.........................................483 11.4.2 Vorgehensweise bei der Analyse von Bedrohungen............................484 11.4.3 Aussage über den Schutzbedarf ...........................................................487 11.4.4 Risikoanalyse.......................................................................................487 11.4.5 Erfassung des Schutzbedarfs ...............................................................489
11.5
Festlegung von Sicherheitsanforderungen .......................................................490 11.5.1 Darstellung der Sicherheitsschwachstelle............................................490 11.5.2 Katalog von Sicherheitsanforderungen................................................490
11.6
Maßnahmen zur Erhöhung der VoIP-Sicherheit ..............................................491 11.6.1 Spezifikation von Sicherheitsmaßnahmen ...........................................491 11.6.2 Typische Sicherheitsschwachstellen....................................................493
11.7
Schlussbemerkungen........................................................................................495
www.wiwobooks.com
Literatur, Standards, Webquellen .............................................................. 497 Abkürzungsverzeichnis................................................................................ 505 Index .............................................................................................................. 511
Vorwort Die heutige Gesellschaft kann man sich ohne Telefon kaum noch vorstellen. Das Internet ist inzwischen auch zum unabdingbaren Kommunikationsmedium geworden, über das jeder zu jeder Zeit Informationen über fast alles abrufen und E-Mails senden und empfangen kann. Das Internet ist ein weltweites Rechnernetz, in dem die Daten nach dem sog. Internet Protocol (IP) übermittelt werden. Man kann es auch als Dienst für die Übermittlung von Informationen in Form von IP-Paketen ansehen. Vergleicht man diesen Dienst mit dem Briefdienst der Post, so entspricht ein IP-Paket einem Brief und die sog. IPAdresse einer postalischen Adresse. Auch in anderen Netzen werden Daten als IP-Pakete übermittelt. Alle Rechnernetze mit dem Protokoll IP bezeichnet man als IP-Netze und wünscht sich, dass in diesen Netzen auch die Sprachkommunikation stattfinden kann. Die Übermittlung von Sprache in IP-Paketen bezeichnet man als Sprache über IP bzw. kurz VoIP (Voice over IP). VoIP bedeutet nicht nur zwei Telefone und IP dazwischen. Hinter diesem Begriff verbergen sich sehr komplexe Vorgänge. Hierzu gehören sog. Signalisierungsprotokolle, nach denen eine Verbindung zwischen Telefonen vor dem Telefongespräch aufgebaut und danach abgebaut werden kann. Die Signalisierungsprotokolle H.323 und SIP sind in der „IT-Welt“ bereits populär geworden. Ein Telefon für VoIP, d.h. ein IP-Telefon, ist nicht mehr nur ein Telefon, sondern ein Rechner an einem IP-Netz, der eine IP-Adresse hat. Das IPTelefon hat zusätzlich eine VoIP-spezifische Adresse, die eine Telefonnummer sein kann. Eine Telefonverbindung im Telefonnetz wird unter einer Telefonnummer aufgebaut. Bei VoIP wird zwar das Ziel der Verbindung mit einer VoIP-spezifischen Adresse – z.B. einer Telefonnummer – angegeben, aber diese Verbindung kann bei IP nur unter einer IP-Adresse aufgebaut werden. Das ist ein Beispiel für die vielen Probleme bei VoIP.
www.wiwobooks.com
VoIP: nicht nur zwei Telefone und IP
Dieses Buch stellt sowohl die Technik von VoIP als auch die Migration zu Ziel des VoIP und die VoIP-Sicherheit fundiert dar und geht hierfür u.a. auf folgende Buches Themen ein: die Perspektiven der Sprachkommunikation, die Signalisierung im Telefonnetz und im ISDN, die Internetprotokollfamilie, Quality of Service, wichtige Sprachcodierungsverfahren, die Prinzipien der Echtzeitkommunikation mit RTP/RTCP und mit Secure RTP, den Standard H.323 und das Protokoll SIP, VoIP-Gateways, Peering bei VoIP und SIP Security. Das Buch vermittelt die unabdingbaren Informationen, um die Sprachkommunikation in IPNetzen (z.B. im Internet) besser zu verstehen, diese zu nutzen und neue VoIPAnwendungen zu konzipieren bzw. auch entwickeln zu können.
XVI An wen richtet sich das Buch?
Kapitel 1
Vorwort
Das Buch ist so aufgebaut, dass jeweils zunächst die Grundlagen fundiert dargestellt und danach praktische Anwendungen diskutiert werden. Damit eignet es sich nicht nur als Lehrbuch für Studenten und Neueinsteiger, sondern auch als Nachschlagewerk für alle Experten, zu deren Aufgaben die Entwicklung, Planung oder Betreuung verschiedener Netzwerke oder Netzwerkapplikationen gehört. Die praxisorientierte, fundierte und reichlich illustrierte Darstellung der Inhalte sollte allen „Netzwerk-Fans“ die Nutzung dieses Buches im Selbststudium ermöglichen. Ein kompakter Überblick über klassische Netze für Sprachkommunikation, Mobilfunknetze (GSM, UMTS), Ansätze für VoIP sowie eine Einführung in Next Generation Networks (NGN), die durch die Konvergenz der Netze entstehen, enthält Kapitel 1. Die VoIP-Aktivitäten der verschiedenen Standardisierungsgremien, Konsortien und Foren werden hier ebenfalls kurz dargestellt.
Kapitel 2
Den Prinzipien der Signalisierung, also der Übermittlung der Steuerung beim Auf- und Abbau von Telefonverbindungen, widmet sich Kapitel 2. Die Schwerpunkte liegen hier auf einer fundierten Darstellung des D-Kanal-Protokolls aus dem ISDN und des Signalisierungssystems Nr. 7. Diese Inhalte sind das Basiswissen für VoIP.
Kapitel 3
Die Grundlagen der Internetprotokollfamilie (IP, TCP, UDP, SCTP ...), die man bei VoIP benötigt, vermittelt Kapitel 3. Insbesondere wird hier auf die Bedeutung von DNS (Domain Name System) bei VoIP mit SIP eingegangen. In diesem Kapitel wird auch das Konzept ENUM präsentiert, nach dem die Telefonnummern auch bei VoIP verwendet werden können. Hinsichtlich der Qualität der Übermittlung der Sprache in IP-Netzen werden bestimmte Anforderungen an diese Netze gestellt, die man als QoS-Anforderungen bezeichnet. Welche Konzepte es gibt, um diese Anforderungen zu erfüllen, zeigt Kapitel 4. Insbesondere werden die für VoIP wichtigen QoS-Parameter, Differentiated Services, Queue-Management und das Protokoll RSVP für die Reservierung der Bandbreite dargestellt.
Kapitel 4
www.wiwobooks.com
Kapitel 5
Sprachkommunikation ist Echtzeitkommunikation. Um sie zu realisieren, verwendet man die Protokolle RTP und RTCP. Kapitel 5 zeigt zuerst, wie die Sprache nach verschiedenen Verfahren codiert und mit Hilfe von RTP/RTCP übermittelt wird. Dieses Kapitel präsentiert auch das neue Secure RTP sowie die Möglichkeiten der Kompression des RTP/UDP/IP-Headers und erläutert die Bedeutung von VoIP-Metriken.
Kapitel 6
Die ersten VoIP-Systemlösungen basierten auf dem Standard H.323. H.323 ist ein komplexes Rahmenwerk, das regelt, wie weitere Signalisierungsprotokolle wie H.225.0 und H.245 verwendet werden. Kapitel 6 ist dem VoIP-Konzept nach H.323 gewidmet. Hier werden auch die sog. Supplementary Services nach H.450.x und die Möglichkeiten zur Unterstützung der Mobilität von VoIPTeilnehmern präsentiert.
Vorwort
XVII
Das Protokoll SIP (Session Initiation Protokoll), das bei VoIP als Signalisie- Kapitel 7 rungsprotokoll dient, gehört bereits heute zu den wichtigsten Internetprotokollen. Kapitel 7 erläutert, wie SIP konzipiert wurde und zeigt mittels verschiedener SIP-Abläufe, wie es eingesetzt werden kann. Hierbei wird auf verschiedene SIP-Funktionen und Leistungsmerkmale von VoIP mit SIP eingegangen und auch wie SIP mit H.323 koexistieren kann. VoIP-Systeme entstehen nicht auf der „grünen Wiese“, sondern müssen mit Kapitel 8 den bereits vorhandenen Systemkomponenten und Netzen für die Sprachkommunikation integriert werden, damit Sprachkommunikation auch zwischen klassischen Telefonen und IP-Telefonen funktioniert. Hierfür sind verschiedene VoIP-Gateways und Protokolle für die Steuerung dieser Gateways nötig. Auf diese Aspekte geht Kapitel 8 ein. Um VoIP weltweit zwischen beliebigen administrativen Domänen (öffentliche Kapitel 9 Verwaltungen, Unternehmen, …) zu ermöglichen, zeigt Kapitel 9 die Prinzipien, nach denen das sog. Telefonie-Routing realisiert werden kann. Hierbei ist das Konzept TRIP von großer Bedeutung. Dieses Kapitel geht auch auf das Peering bei VoIP mit SIP ein. Ein Einsatz von VoIP wird heute in keinem Netzwerkprojekt außer Acht gelas- Kapitel 10 sen. Die Migration zu VoIP in Unternehmen und in anderen Institutionen führt zu einem komplexen Projekt, bei dem mehrere Aspekte berücksichtigt werden müssen. Kapitel 10 widmet sich diesem Thema und erläutert technische Lösungen wie z.B. STUN, TURN und ICE, um VoIP mit SIP in Netzwerken mit privaten IP-Adressen nutzen zu können.
www.wiwobooks.com
Um VoIP-Sicherheit zu gewährleisten und VoIP-Netzwerke gegen böswillige Kapitel 11 Angriffe zu schützen, sind bestimmte technische Lösungen und Maßnahmen nötig. Einen fundierten Überblick über die Bedrohungen und Sicherheitsmechanismen bei VoIP – insbesondere bei VoIP mit SIP – sowie über die Planung der VoIP-Sicherheit vermittelt Kapitel 11. Entstanden ist dieses Buch zum größten Teil auf der Basis von Skripten zu meiner Vorlesung Integrierte Netze, die ich über mehrere Jahre an der Hochschule Fulda, Fachbereich Angewandte Informatik, im Studienschwerpunkt Telekommunikation gehalten habe. An dieser Stelle möchte ich meinen Dank an alle Personen richten, die mich Danksagung mit ihren Anregungen und Bemerkungen unterstützt haben. Für die sehr gute Zusammenarbeit mit dem Hanser Verlag möchte ich mich bei Frau Margarete Metzger und Frau Irene Weilhart aufrichtig bedanken. Nicht zuletzt möchte ich auch meiner Frau Ingeborg für Ihre Unterstützung während des Schreibens dieses Buches und meiner Tochter Kati für das fleißige Korrekturlesen danken. Fulda, Oktober 2009
Anatol Badach
XVIII
Vorwort
Der Autor Prof. Dr.-Ing. Anatol Badach arbeitet seit über 30 Jahren auf den Gebieten Informatik und Telekommunikation; Promotion (1975) auf dem Gebiet Datenkommunikation; Habilitation (1983) auf dem Gebiet Rechnernetze. Seit 1985 ist er Professor im Fachbereich Angewandte Informatik an der Hochschule Fulda. Zu seinen Schwerpunkten in Lehre und Forschung gehören: Rechnerkommunikation, Netzwerktechnologien und Multiservice Networking. Zur Zeit forscht er im Bereich der Multimedia-Kommunikation über IP-Netze, insbesondere in der Entwicklung intelligenter und multimedialer TK-Dienste auf der Basis von Web Services. Prof. Badach ist Autor zahlreicher Veröffentlichungen und mehrerer Fachbücher; dazu zählen Technik der IP-Netze (Hanser, Mitautor), Web-Technologien (Hanser, Mitautor), Integrierte Unternehmensnetze, Datenkommunikation mit ISDN, High Speed Internetworking (Mitautor).
www.wiwobooks.com
Seine Erfahrung vermittelt Prof. Badach auch als Leiter und Referent bei Fachkongressen und -seminaren. Ihre Kritik, Verbesserungsvorschläge und evtl. Korrekturen nehme ich gerne entgegen:
[email protected] Auch stelle ich Ihnen die Abbildungen gerne für Lehrzwecke zur Verfügung. Bei allen, die mir bereits nette Worte über dieses Werk und Korrekturen zu den vorherigen Auflagen geschickt haben, möchte ich mich an dieser Stelle herzlich bedanken. Über die Herausforderung, die vierte Auflage dieses Werkes zu verfassen und dem Leser die Entwicklungen der letzten drei Jahre auf dem Gebiet von VoIP präsentieren zu können, habe ich mich gefreut. Mangels Platz habe ich auf die Darstellung von einigen Themen – wie z.B. VoIP-Notrufsysteme, Peer-to-PeerLösungen für VoIP – verzichtet. Die Entwicklung auf dem Gebiet der multimedialen Kommunikation über IP-Netze ist einfach rasant. „Mit dem Wissen wächst der Zweifel“ Johann Wolfgang von Goethe
1
Vom einfachen Telefon bis zu Next Generation Networks
Seit der Erfindung des Telefons sind fast 150 Jahre vergangen. Dieses Gerät ist Was ist mittlerweile zum wichtigsten Kommunikationsmittel geworden. Weil die VoIP? Sprachkommunikation für den Menschen von großer Bedeutung ist, kann man sich ein Leben ohne Telefon kaum noch vorstellen. Im Zeitalter des Internet werden Konzepte entwickelt, um menschliche Sprache auch über diese weltweite Kommunikationsplattform zu übermitteln. Im Internet verwendet man das Internet Protocol, kurz IP, nach dem Daten in Form sog. IP-Pakete übermittelt werden. Bei der Übermittlung der Sprache in IP-Paketen spricht man von Voice over IP (VoIP). Ein Telefon, mit dem man über VoIP telefonieren kann, ist kein bloßes Telefon Next mehr, sondern eigentlich ein Rechner. So ist die Telefonie mittels VoIP eine Generation Form der Rechnerkommunikation. Dieses Zusammenwachsen der Sprach- und Network Datenkommunikation bezeichnet man als Konvergenz der Sprach- und Datennetze. Ein Next Generation Network (NGN) mit IMS (IP Multimedia Subsystem) ist ein konvergentes Netz mit dem Protokoll IP, in dem Sprach-, Datenund Videokommunikation gleichermaßen möglich ist.
www.wiwobooks.com
Dieses Kapitel gibt einen Überblick über die bisherige Entwicklung der Netze Überblick für die Sprachkommunikation und erläutert die wichtigsten Trends. Abschnitt über das 1.1 zeigt die Entwicklung vom einfachen Telefon bis zum intelligenten Netz. Kapitel Die Prinzipien von VoIP erläutert Abschnitt 1.2. Die Evolution der Mobilfunknetze zeigt Abschnitt 1.3. Abschnitt 1.4 erläutert die Konvergenz von Netzen. Auf NGNs mit IMS geht Abschnitt 1.5 ein. Abschnitt 1.6 stellt die VoIPAktivitäten bei Standardisierungsgremien und anderen Organisationen dar. In diesem Kapitel werden u.a. folgende Fragen beantwortet: Wie haben sich die Netze für die Sprachkommunikation entwickelt? Wie soll man sich VoIP vorstellen, und welche Ansätze dafür gibt es? Wie werden Mobilfunknetze (GSM, GPRS, UMTS) aufgebaut? Wie erfolgt die Konvergenz von Netzen, und welche Vorteile hat sie? Welche Bedeutung haben die Konzepte Parlay/OSA und JAIN? Worin besteht das Konzept von NGNs, und welche Bedeutung hat IMS? Wie lässt sich die Mobilität von Benutzern in NGNs erreichen? Mit welchen VoIP-betreffenden Entwicklungen befassen sich die Standardisierungsgremien IETF und ITU-T?
Ziel dieses Kapitels
2
1
Vom einfachen Telefon bis zu Next Generation Networks
1.1
Vom Telefon bis zum intelligenten Netz
Das Telefon ist für unsere heutige Gesellschaft ein Mittel der Massenkommunikation geworden. Seine Geschichte begann bereits vor fast 150 Jahren. Im Laufe der Zeit wurde es um verschiedene Zusatzfunktionen erweitert. Das grundlegende Konzept des Telefons ist unverändert, nicht jedoch die Art und Weise, wie die Sprache übermittelt wird. Das Telefonnetz – auch Fernsprechnetz genannt – hat sich stark verändert: es wurde digitalisiert. Dies hat in Europa zur Entstehung von ISDN (Integrated Services Digital Network) geführt. Das digitale Telefonnetz und das ISDN werden laufend um intelligente Funktionen erweitert, sodass man heute vom intelligenten Netz (Intelligent Network) spricht.
1.1.1 Erfindung des Telefons Pioniere der Entwicklung
Eine der bedeutendsten Erfindungen des 19. Jahrhunderts war die Erfindung des Telefons, das schnell zum wichtigsten Kommunikationsmittel wurde. Abbildung 1.1-1 zeigt die Pioniere seiner Entwicklung.
www.wiwobooks.com
Johann P. Reis (1834-1874)
Alexander G. Bell (1847-1922)
Antonio S. G. Meucci (1808-1889)
Elisha Gray (1835-1901)
Abb. 1.1-1: Pioniere der Entwicklung des Telefons
Erste Idee des Telefons von Reis
Bald werden 150 Jahre vergangen sein, seit der aus Gelnhausen bei Frankfurt stammende deutsche Physiker Johann Philipp Reis im Jahre 1861 einen Apparat vorstellte, der die Töne und Sprache mit Hilfe des elektrischen Stroms übertragen konnte. Das war das erste (noch sehr primitive) Telefon der Welt, bei dem ein Holzmodell einer Ohrmuschel verwendet wurde. Reis simulierte das Trommelfell, indem er an einem Ohrmodell ein Stück Wursthaut befestigte, deren Schwingungen von einem feinen Platinstreifen und einer Feder abgetastet wurden. Zwar war die Übertragung nur in eine Richtung möglich und die Leistungsfähigkeit sehr gering, doch stellte man bei den später durchgeführten Tests fest, dass das von Reis entwickelte Telefon die Sprache gut übermittelte. Dennoch wird Philipp Reis nicht als Erfinder des Telefons anerkannt, weil es ihm nicht gelang, seine Idee so zu verbessern, dass sich daraus eine praktische Anwendung ergeben hätte.
1.1 Vom Telefon bis zum intelligenten Netz
3
Erst 1876 gelang es dem US-Amerikaner Alexander Graham Bell, ein kommerziell brauchbares Telefon zu entwickeln. Er erkannte, dass für die Übertragung der Sprache eine kontinuierliche Änderung des Stroms nötig ist. Eine Lösung für die Umsetzung seiner Idee hat Bell in den Erkenntnissen der elektromagnetischen Induktion gefunden. Bell baute einen Apparat, der – ähnlich dem Telefon von Reis – die Schwingungen einer Membran in elektrische Schwingungen umwandelte und den beiden Gesprächsteilnehmern ermöglichte, miteinander zu sprechen. Allerdings waren Mikrofon und Lautsprecher in einem Handstück so eingebaut, dass man den Hörer beim Telefonieren abwechselnd an den Mund oder das Ohr halten musste.
Bell galt lange als Erfinder des Telefons
Bell hatte im Februar 1876 für seine Erfindung ein Patent beantragt. Nur zwei Stunden später am gleichen Tag versuchte auch der US-Amerikaner Elisha Gray, einen ähnlichen Apparat anzumelden. Drei Wochen später, am 7. März, erhielt Bell das Patent für sein Telefon, das jedoch, im Gegensatz zur Erfindung von Gray, erst nach einigen Tagen überhaupt betriebsbereit war. Bell gründete im Jahr 1877 die Firma Bell Telephone Association, die den Bau eines Telefonnetzes in den USA übernehmen sollte. Diese Firma benannte sich 1885 in American Telephone and Telegraph Company (AT&T) um und ist heute der größte Telefonkonzern der Welt.
Zwei Patentanmeldungen in zwei Stunden
Neuesten Erkenntnissen zufolge ist der US-Italiener Antonio Santi Giuseppe Meucci der eigentliche Erfinder des Telefons. Meucci hatte seine Erfindung in der italienischen Ausgabe eines amerikanischen Journals vorgestellt und im Dezember 1871 eine Patentanmeldung beantragt, die allerdings 1874 auslief, da Meucci nicht in der Lage war, die notwendigen Gebühren in Höhe von 250 Dollar zu bezahlen. Die amerikanischen Behörden hatten von 1887 an versucht, das Patent von Bell zu annullieren und ihn wegen Betrugs anzuklagen. Durch den Tod Meuccis im Jahr 1889 und den regulären Ablauf des Patents wurde der ganze Vorgang aber abgeschlossen, ohne rechtliche Klärung, wer der wahre Erfinder des Telefons ist. Erst am 11. Juni 2002 wurde in den USA offiziell beschlossen, Meucci als Erfinder des Telefons anzuerkennen.
Seit 2002 gilt Meucci als Erfinder des Telefons
Das Telefon verbreitete sich schnell, und seit der Erfindung des analogen Telefons hat sich im Telefonapparat viel verändert. Abbildung 1.1-2 soll dies zum Ausdruck bringen. Bis Ende der 60er-Jahre des 20. Jahrhunderts änderte sich an der Funktionsweise der Telefone kaum etwas, hauptsächlich sind die Apparate kleiner geworden. In den 70er-Jahren kam das Tastentelefon auf den Markt, wodurch sich die Bedienbarkeit vereinfachte.
Große Veränderungen im Telefonapparat
www.wiwobooks.com
a)
b)
Siemens-1900
CISCO 7970
Abb. 1.1-2: Zwei Generationen von Telefonen: a) Analoges Telefon vor 100 Jahren, Modell Siemens-1900 von Siemens, b) VoIP-Telefon, Modell 7970 von CISCO
Durch die Digitalisierung des Telefonnetzes, was in Europa zur Entstehung des ISDN geführt hat, konnten digitale Telefone zum Einsatz kommen. Ein ISDN-
4
1
Vom einfachen Telefon bis zu Next Generation Networks
Telefon erzeugt aus dem Sprachsignal einen kontinuierlichen Bitstrom von 64 kbit/s und stellt verschiedene Zusatzfunktionen – die sog. Leistungsmerkmale – zur Verfügung. Die VoIP-Telefone stellen die neueste Generation der Telefone dar und sind heute im Vergleich zu einem Telefon vor 100 Jahren sehr komplizierte Endeinrichtungen. Eine sehr interessante Geschichte der Telefonie ist zu finden unter http://www.sig-telefon.de und http://www.alte-telefone.de
1.1.2 Vom analogen Telefonnetz zum ISDN Besonderheit der analogen Sprachkommunikation
Die menschliche Sprache, die durch ein Mikrophon aufgezeichnet wird, stellt ein analoges Sprachsignal mit den Frequenzen von ca. 300 bis 3400 Hz dar. Die alten Telefonnetze wurden so konzipiert, dass die Übertragung der analogen Signale mit den Frequenzen bis zu 4000 Hz zwischen zwei Telefonen möglich war. In diesem Zusammenhang sprach man auch von einem analogen Sprachkanal mit der Bandbreite von 4 kHz. Abbildung 1.1-3 zeigt die Phasen bei der analogen Sprachkommunikation über ein Telefonnetz.
www.wiwobooks.com A n a lo g e s T e le fo n n e tz
T e iln e h m e r A
T e l-N r = X
F V S t
T V S t
...
F V S t
...
T V S t
V e rb in d u n g s a u fb a u a n a lo g e S p r a c h k o m m u n ik a tio n
T e iln e h m e r B T e l-N r = Y T e le fo n g e sp rä c h
V e rb in d u n g s a b b a u
Abb. 1.1-3: Phasen bei der analogen Sprachkommunikation FVSt: FernVermittlungsStelle, TVSt: TeilnehmerVermittlungsStelle, Tel-Nr: Telefonnummer
Begriff: Signalisierung
Eine Telefonverbindung muss vor dem Telefongespräch aufgebaut und danach abgebaut werden. Hierfür müssen entsprechende Steuerungsangaben (u.a. die Ziel-Rufnummer) an die Vermittlungsstellen als Knoten im Telefonnetz übermittelt werden. Die Übermittlung der Steuerung, um eine Verbindung auf- und 1 abzubauen, bezeichnet man als Signalisierung . Sie wird in analogen Telefonnetzen durch die Übermittlung spezieller Signale realisiert, die u.a. durch Abheben und Auflegen des Hörers erzeugt werden. Da diese Signale über den 1
Der Begriff Signalisierung wird benutzt, weil es sich hier u.a. um die Anzeige – also um die Signalisierung (oft akustisch) – eines ankommenden Anrufes beim Angerufenen handelt.
1.1 Vom Telefon bis zum intelligenten Netz
5
gleichen analogen Kanal übermittelt werden, der auch für die Übermittlung der Sprache dient, bezeichnet man diese Signalisierung als Inband-Signalisierung. Abbildung 1.1-3 zeigt auch, dass das Telefonnetz eine baumartige und hierarchische Struktur besitzt, die sich in der Struktur der Telefonnummern widerspiegelt. Die Knoten der unteren Hierarchiestufen bilden die lokalen Vermittlungsstellen, die sog. Teilnehmer-(VSt) oder Ortsvermittlungsstellen. Die Vermittlungsstellen in den höheren Hierarchiestufen bilden die Fernvermittlungsstellen (FVSt). Das öffentliche Telefonnetz wird kurz PSTN (Public Switched Telephone Network) genannt.
Hierarchische Struktur des Telefonnetzes
Ein wichtiger Schritt in der Entwicklung der Sprachkommunikation war die Digitales Digitalisierung der Übertragungswege zwischen den Vermittlungsstellen und Telefonnetz die Digitalisierung der Vermittlungsstellen im analogen Telefonnetz. Dadurch ist ein digitales Telefonnetz entstanden, in dem die Sprache in digitaler Form als Bitstrom mit 64 kbit/s übermittelt wird. Das ISDN (Integrated Services Digital Network) wurde in Europa als Weiter- Besonderheit entwicklung des digitalen Telefonnetzes eingeführt. Eine Verbindung über das von ISDN ISDN zwischen zwei Telefonen stellt einen digitalen Sprachkanal mit der Bitrate von 64 kbit/s dar. Abbildung 1.1-4 illustriert die Phasen bei der digitalen Sprachkommunikation über ISDN.
www.wiwobooks.com D
T e iln e h m e r A T e l-N r = X
B
F V S t B
T V S t
F V S t
6
S
D
...
...
T V S t
IS D N 0
V e rb in d u n g s a u fb a u (D -K a n a l-P r o to k o ll &
S S S 7 )
d ig ita le S p r a c h k o m m u n ik a tio n V e rb in d u n g s a b b a u (D -K a n a l-P r o to k o ll &
0
B B
T e iln e h m e r B T e l-N r = Y T e le fo n g e sp rä c h
S S 7 )
Abb. 1.1-4: Digitale Sprachkommunikation im ISDN Abkürzungen wie in Abb. 1.1-3
Das ISDN stellt ein universelles digitales Netz dar. Daher können neben Tele- B-Kanal als fonen auch andere Endeinrichtungen wie z.B. Faxgeräte bzw. Datenendeinrich- digitaler tungen angeschlossen werden, die über die ISDN-Schnittstelle S0 verfügen. Sprachkanal Jeder Endeinrichtung werden über die Schnittstelle S0 zwei Nutzkanäle – sog. B-Kanäle – mit je 64 kbit/s bereitgestellt. Darüber hinaus steht ein spezieller Kanal für die Übermittlung der Signalisierung – der sog. D-Kanal mit 16 kbit/s – allen Endeinrichtungen zur Verfügung. Der D-Kanal stellt einen Signalisierungskanal dar (s. Abschnitt 2.3).
6
1
Vom einfachen Telefon bis zu Next Generation Networks
Signalisierung nach D-KanalProtokoll
Um die Sprache zwischen zwei Telefonen über das ISDN zu übermitteln, muss vor dem Telefongespräch eine ISDN-Verbindung zwischen ihnen aufgebaut und danach wieder abgebaut werden. Die Übermittlung der hierfür notwendigen Steuerungsangaben zwischen Telefon und TVSt erfolgt über den D-Kanal nach dem sog. D-Kanal-Protokoll.
Signalisierung nach SS7
Die Übermittlung der Signalisierung zwischen den ISDN-Vermittlungsstellen erfolgt nach dem Signalisierungssystem Nr. 7 (SS7, Signalling System No. 7). Somit erfolgt die Signalisierung nach dem D-Kanal-Protokoll nur im Netzzugangsbereich, also auf der Strecke zwischen einem Telefon und einer Teilnehmervermittlungsstelle (TVSt). Auf SS7 geht Abschnitt 2.4 näher ein. Für Näheres über den Aufbau des Telefonnetzes sei auf [Sieg 07] verwiesen. Das ISDN wird detaillierter in Kapitel 2 dargestellt.
1.1.3 Vom ISDN zum Intelligenten Netz Entstehung eines Intelligenten Netzes
Das ISDN mit seiner Bitrate von 64 kbit/s stellt schon einen bedeutsamen Sprung gegenüber dem analogen Telefonnetz dar. Es handelt sich jedoch um ein reines Übermittlungsnetz. Um „intelligente Dienste“ im ISDN bzw. im öffentlichen digitalen Telefonnetz (PSTN) zu erbringen, können spezialisierte Server an die Vermittlungsstellen angeschlossen werden. Eine derartige ISDN/PSTN-Erweiterung, wie dies Abbildung 1.1-5 zeigt, führt zur Entstehung eines Intelligenten Netzes (Intelligent Network, IN).
www.wiwobooks.com I n te llig e n te s N e tz (I N )
S M P P ro to k o ll IN A P
S M P
S e r v ic e -P la n e
S C P
S C P
S ig n a lis ie r u n g s P la n e
S ig n a lis ie ru n g s n e tz (S S 7 ) S S P
S S P
S S P P S T N /IS D N
...
...
T ln A
...
...
6
T ln B
Z u g a n g s- u n d T r a n s p o r t-P la n e
Abb. 1.1-5: ISDN/PSTN-Erweiterung zum IN – Entstehung einer Multi-Plane-Struktur INAP: Intelligent Network Application Protocol, SCP: Service Control Point, SMP: Service Management Point, SSP: Service Switching Point, Tln: Teilnehmer
Intelligentes Netz
Die „Intelligenz“ des Netzes, die man zur Realisierung der IN-Dienste benötigt, erbringen spezialisierte Server. Die Nutzer der IN-Dienste können sowohl ISDN- und PSTN-Teilnehmer als auch die Teilnehmer von Mobilfunknetzen sein. Für die Unterstützung der IN-Dienste werden die Vermittlungsstellen um ein IN-Modul erweitert, das als SSP (Service Switching Point) bezeichnet wird.
1.1 Vom Telefon bis zum intelligenten Netz
7
SSP enthält die Funktionen, die notwendig sind, um mit weiteren IN-Komponenten zusammenzuarbeiten. Hier wird der Wunsch nach einer Verbindung zu einem spezialisierten Server als Erbringer des IN-Dienstes erkannt. Der Erbringer von IN-Diensten stellt einen SCP (Service Control Point) dar. Für den Betrieb der IN-Dienste wird ein SMP (Service Management Point) als Dienstverwaltungspunkt definiert, um IN-Dienste einzurichten, zu verwalten und zu überwachen. Die Kommunikation zwischen SSP und SCP verläuft nach dem Protokoll INAP INAP zwi(Intelligent Network Application Protocol). Für die Übermittlung von INAP- schen SSP Nachrichten wird das Protokollsystem SS7 verwendet. Somit stellt INAP eine und SCP Anwendung von SS7 dar. Logisch gesehen entsteht in Abbildung 1.1-5 eine hierarchische MultiplaneStruktur. Das ISDN/PSTN stellt hier eine Zugangs- und Transport-Plane dar. SS7 bildet eine Signalisierungs-Plane, und die Server als Erbringer von INDiensten sind der Service-Plane zuzuordnen. Die Rufnummern im ISDN/PSTN werden so strukturiert, dass die ersten vier Rufnummer bzw. fünf Ziffern der Rufnummer als Präfix dienen. Ein IN-Dienst wird durch und Diensteinen Präfix-Wert als Dienstkennzahl in der Rufnummer identifiziert. Bei- kennzahl spielsweise hat der IN-Dienst Televotum, den die Fernsehanstalten zur Zuschauerbefragung während Live-Sendungen verwenden, die Dienstkennzahl 0137. Eine Dienstkennzahl könnte man als Vorwahl eines IN-Dienstes interpretieren. Ein wichtiger IN-Dienst ist das Routing von Telefonverbindungen.
www.wiwobooks.com
Beispiel: Beim IN-Dienst „herkunftsabhängiges Routing“ handelt es sich um die Umleitung ankommender Telefonanrufe, je nachdem, aus welchem Ursprungsgebiet sie kommen. Die Anrufe können von einem Server entsprechend umgeleitet werden. Kriterien für die Umleitung können u.a. sein: Vorwahlnummer, Bundesländer, individuelle Vorgaben. Abbildung 1.1-6 illustriert, wie ein Versandhaus einen derartigen IN-Dienst in Anspruch nehmen kann. R o u tin g T a b e lle S C P V S t A
S S P
In te llig e n te s N e tz
S S P
V S t B
U G Z ie l X A B Y ... ...
6
K u n d e
X F ilia le 6
U rs p ru n g s g e b ie t: A
V e rsa n d h a u s R u f-N r: 0 9 0 0 -5 -x x x x x x
Y F ilia le
6
K u n d e
U rs p ru n g s g e b ie t: B
Abb. 1.1-6: Beispiel für einen IN-Dienst – Herkunftsabhängiges Routing UG: Ursprungsgebiet, VSt: Vermittlungsstelle, weitere Abkürzungen wie in Abb. 1.1-5
Das Versandhaus ist unter einer Rufnummer 0900-5-xxxxxx zu erreichen und besitzt mehrere Filialen für die Auslieferung von Waren an seine Kunden. Um die Lieferkosten zu redu-
8
1
Vom einfachen Telefon bis zu Next Generation Networks zieren, wird herkunftsabhängiges Routing genutzt. Ruft ein Kunde an, so wird sein Anruf zu der Filiale umgeleitet, die seinem Herkunftsort am nächsten ist. So verkürzt sich der Lieferweg für die bestellten Waren, und die Transportkosten reduzieren sich. Beispiel: Andere Routing-Varianten beim Aufbau von Telefonverbindungen: Zeitabhängiges Routing Je nach Tag, Tageszeit und unter Berücksichtigung von Ferienzeiten und Feiertagen werden eingehende Anrufe auf vorgegebene Zielrufnummern umgeleitet. Sequenzabhängiges Routing Es soll nur jeder n-te Anruf weitergeleitet werden – einsetzbar bei telefonischen Gewinnspielen (z.B. jeder 1000-ste gewinnt). Die Gewinner und Nichtgewinner könnten auf entsprechende Standardansagen umgeleitet werden. Lastabhängiges Routing Als Weiterleitungskriterium dient hierbei die Anzahl paralleler Gespräche je Ziel. Falls eine Niederlassung (Filiale) einer Firma mit maximal x Telefonisten besetzt ist, dann werden gleichzeitig nicht mehr als x Telefonverbindungen an dieses Ziel weitergeleitet.
1.2 VoIP als Intranet-/ InternetTelefonie
Ansätze für VoIP
Eines der größten Wachstumspotenziale wird derzeit der Sprach- und Datenintegration auf der Basis des Internet-Protokolls (IP) zugesprochen. Wird Sprache über ein IP-Netz übertragen, bezeichnet man dies als Voice over IP (VoIP). Stellt das IP-Netz das öffentliche Internet dar, spricht man auch von InternetTelefonie. Als Intranet-Telefonie bezeichnet man VoIP innerhalb eines firmeneigenen IP-Netzwerks, also innerhalb eines Intranet.
www.wiwobooks.com
Bemerkung: Das Internet ist kein einzelnes physikalisches Netz, sondern stellt einen Dienst für die Übermittlung der IP-Pakete in einem weltweiten Verbund unterschiedlicher physikalischer Transportnetze dar. Logisch gesehen stellt das Internet eine Nachbildung des weltweiten Briefpostdienstes dar, wobei ein IP-Paket einem Brief und eine IP-Adresse einer postalischen Adresse entsprechen würde. Das Internet kann auch als ein weltweites logisches IP-Netz angesehen werden.
Arten der IP-Telefone
Eine Endeinrichtung für VoIP-Anwendungen nennt man IP-Telefon. Hierbei kann es sich einerseits um einen speziellen Telefonapparat handeln, der de facto ein Rechner ist und an ein IP-Netzwerk angeschlossen wird. Andererseits kann ein „normaler“ PC um bestimmte Funktionskomponenten so erweitert werden, dass er ein sog. Soft-IP-Telefon darstellt. Ein Telefonat kann bei einem Soft-IP-Telefon oft über eine Web-Seite initiiert werden, sodass man in diesem 2 Fall auch von Click-to-Dial spricht.
2
Dadurch – und mit SIP-Hilfe – können intelligente Lösungen für die Unterstützung von ECommerce, Help-Desk-Systemen und Call-Centern angeboten werden. Man spricht hierbei von Third Party Call Control (3PCC) – für weitere Informationen darüber siehe RFC 3725.
1.2 Ansätze für VoIP
9
Ein PC am Intranet/Internet benötigt für VoIP eine Hardware- und SoftwareErweiterung. Die Komponenten für die Ein- und Ausgabe von Sprache (Mikrofon, Headset, evtl. Lautsprecher) werden in der Regel über eine Audio/VideoAdapterkarte (auch Soundkarte genannt) mit dem PC verbunden. Sprache wird durch die Adapterkarte digitalisiert und komprimiert. Eine Software auf dem PC sorgt u.a. für die Verpackung der digitalisierten Sprache in IP-Pakete.
1.2.1 Allgemeines über Internet-Telefonie Telefonieren über das Internet bedeutet, dass Sprache in Echtzeit in IP-Paketen Einsatz von über das Internet übermittelt wird. Das Protokoll TCP (Transmission Control RTP Protocol), das man als Transportprotokoll für die Datenkommunikation nutzt und bei dem Quittungen verwendet werden, um eventuell eine wiederholte Übermittlung von fehlerhaft empfangenen bzw. verloren gegangenen Daten zu veranlassen, kann bei VoIP nicht eingesetzt werden. Stattdessen wird das Protokoll RTP (Real-time Transport Protocol) eingesetzt. Jedes IP-Telefon muss somit das RTP unterstützen. Auf das Konzept und die Nutzung von RTP wird in Kapitel 5 näher eingegangen.
www.wiwobooks.com
Abbildung 1.2-1 illustriert das Prinzip der Internet-Telefonie. Als IP-Telefon dient hier ein Rechner (z.B. ein PC), auf dem VoIP-spezifische Funktionskomponenten (Audio/Video-Adapterkarte, RTP-Protokoll etc.) installiert wurden. In diesem Fall spricht man von PC-zu-PC-Sprachkommunikation. T e iln e h m e r A IP -A d r = X V o IP -S e s s io n R T P -K a n a l R T C P -K a n a l
T e iln e h m e r B
In te rn e t (IP -N e tz )
IP -A d r = Y
S ig n a lis ie r u n g s p r o to k o ll A u fb a u e in e r R T P -S e s s io n S p r a c h ü b e r m ittlu n g in IP -P a k e te n
R T P -P o rt
K o n tr o llk a n a l
A b b a u d e r R T P -S e s s io n S ig n a lis ie r u n g s p r o to k o ll S p ra c h se g m e n t R T P R T P -P a k e t
U D P
R T C P -P o rt IP IP -P a k e t
Abb. 1.2-1: Prinzip der Sprachübermittlung über das Internet
Wie bei der Sprachkommunikation über ein analoges bzw. digitales Telefon- VoIPnetz muss auch bei VoIP vor dem Telefongespräch über das Internet quasi eine Session Telefonverbindung aufgebaut und nach dem Telefongespräch abgebaut werden. Da es sich beim Internet um ein Netz mit Paketvermittlung handelt, wird eine
10
1
Vom einfachen Telefon bis zu Next Generation Networks
Telefonverbindung durch eine Verknüpfung entsprechender Speicherplätze – sog. Ports – in den IP-Telefonen nachgebildet, was man als VoIP-Session bzw. auch kurz als Session bezeichnet. In der Regel werden für eine VoIP-Session in jedem IP-Telefon jeweils zwei Ports reserviert und wie folgt verwendet: Der erste Port wird benutzt, um Sprache in einer digitalen Form nach dem Protokoll RTP zu senden und zu empfangen. So entsteht ein virtueller Sprachkanal – also ein Media-Kanal (Media Channel) – zwischen zwei IPTelefonen. Er wird im Weiteren als RTP-Kanal bezeichnet. Über den zweiten Port werden Reports zwischen den IP-Telefonen übermittelt, mit denen sie sich gegenseitig über den Verlauf – u.a. über die Qualität – der Sprachübermittlung berichten können. Dies erfolgt nach dem Protokoll RTCP (RTP Control Protocol). So entsteht ein Kontrollkanal – im Weiteren RTCP-Kanal genannt. Eine VoIP-Session – als Nachbildung einer physikalischen Telefonverbindung zwischen IP-Telefonen – setzt sich somit aus einem RTP-Kanal als MediaKanal und einem RTCP-Kanal als Kontrollkanal zusammen. Besteht eine VoIP-Session zwischen zwei IP-Telefonen, so kann über diese Session digitali3 sierte Sprache in IP-Paketen zwischen ihnen übermittelt werden.
www.wiwobooks.com
Signalisierungsprotokolle
Um eine VoIP-Session auf- und abzubauen, ist ebenso wie im PSTN/ISDN ein Signalisierungsprotokoll nötig. Man kann hierfür das Protokoll SIP (Session Initiation Protocol) bzw. die Protokolle H.225.0 und H.245 aus der Protokollfamilie H.323 verwenden. H.323 und SIP werden in den Kapiteln 6 und 7 detaillierter dargestellt.
Sprachcodierung
In jedem IP-Telefon erfolgt die Umwandlung der analogen Sprachsignale in eine digitale Form. Man bezeichnet dies als Digitalisierung von Sprache. Hierbei werden komplexe Verfahren zur Sprachcodierung verwendet. Die am häufigsten verwendete Art der Sprachcodierung nach dem Standard G.729 erfordert eine Bandbreite von lediglich 8 kbit/s für ein Telefongespräch mit relativ guter Qualität. Für besonders gute Qualität kann das Sprachcodierungsverfahren PCM (Pulse Code Modulation) nach dem G.711-Standard verwendet werden (s. Abschnitt 5.1.3), wobei hier die Bandbreite von 64 kbit/s benötigt wird. Auf die Prinzipien der Sprachcodierung wird in Kapitel 5 näher eingegangen. In der Situation aus Abbildung 1.2-1 muss beachtet werden, dass die Sprache auf den beiden Seiten nach dem gleichem Prinzip codiert wird. Ein IP-Telefon unterstützt in der Regel mehrere Sprachcodierungsverfahren. Das Prinzip der
3
Zwischen zwei Rechnern kann auch eine Session aufgebaut werden, über die mehrere Echtzeitmedien – wie z.B. Sprache und Video – übermittelt werden. Eine derartige Session ist eine Multimedia-Session. Sie enthält mehrere Media-Kanäle als RTP-Kanäle und auch mehrere RTCP-Kanäle. Darauf geht Abschnitt 5.2.1 näher ein.
11
1.2 Ansätze für VoIP
Sprachcodierung wird beim Aufbau einer VoIP-Session zwischen den IPTelefonen vereinbart. Wie Abbildung 1.2-1 zeigt, wird jedem übertragenen Sprachsegment zuerst ein RTP-Header mit min. 12 Bytes, danach ein UDP-Header mit 8 Bytes und zum Schluss noch ein IP-Header mit min. 20 Bytes vorangestellt. Wird eine Sprachaufnahme von 20 ms beispielsweise als Sprachsegment mit 20 Bytes übermittelt, so wird jedem 20-Byte-Sprachsegment ein RTP/UDP/IP-Header von mindestens 40 Bytes vorangestellt. Der vorangestellte Gesamtheader ist somit länger als das eigentliche Sprachsegment im IP-Paket. Aus diesem Grund ist die Komprimierung des RTP/UDP/IP-Headers in einigen Situationen von großer Bedeutung. Darauf geht Abschnitt 5.8 noch detaillierter ein.
Komprimierung des RTP/UDP/ IP-Headers
Jeder Rechner an jedem IP-Netz besitzt eine IP-Adresse. Jedes Telefon am PSTN/ISDN besitzt eine Telefonnummer. Ein IP-Telefon am Internet bzw. bei einem anderen IP-Netz wird nur dann auch aus dem PSTN/ISDN erreichbar, wenn es eine Telefonnummer besitzt. Im Allgemeinen muss man daher annehmen, dass ein IP-Telefon am IP-Netz auch eine Telefonnummer besitzt. Da eine VoIP-Session nicht zwischen zwei Telefonnummern aufgebaut wird, sondern zwischen zwei IP-Adressen, muss irgendwie bekannt gemacht werden, welche IP-Adresse welcher Telefonnummer entspricht. Dies stellt ein Adressierungsproblem bei VoIP dar. Dieses Problem kann beim Einsatz von H.323 und von SIP auf unterschiedliche Art und Weise gelöst werden – Näheres hierfür findet sich z.B. in den Abschnitten 6.3.4 (H.323), 3.8.2 (SIP) und 7.1.4 (SIP).
Adressierungsproblem bei VoIP
www.wiwobooks.com
VoIP stellt an IP-Netze völlig neue Anforderungen im Vergleich zu Netzen für VoIP und reine Datenkommunikation. Man bezeichnet diese Ansprüche als QoS-Anfor- QoS derungen (Quality of Service). Insbesondere müssen die Zeitabstände zwischen aufeinanderfolgenden IP-Paketen bei einem Telefongespräch auf Sende- und Empfangsseite identisch sein. Dies bedeutet, dass Isochronität bei der Sprachkommunikation garantiert werden muss (s. Abschnitt 5.6.1). Auf die QoSAspekte bei VoIP geht Kapitel 4 ein.
1.2.2 Erweiterung von ISDN mit einem IP-Netz Um zu ermöglichen, dass ein Teilnehmer an einem IP-Netz einen anderen Teilnehmer am PSTN/ISDN anrufen kann, muss das IP-Netz mit dem PSTN/ISDN entsprechend integriert werden. Da ein Rechner am IP-Netz als IP-Telefon fungieren kann, stellt das IP-Netz – funktionell gesehen – eine räumliche Erweiterung von PSTN/ISDN dar. Einem IP-Telefon am IP-Netz, das normalerweise eine IP-Adresse besitzt, muss zusätzlich eine Telefonnummer zugeordnet werden, sodass es aus dem PSTN/ISDN erreicht werden kann. Abbildung 1.2-2 illustriert eine räumliche Erweiterung von ISDN mit einem IP-Netz.
12
1
Vom einfachen Telefon bis zu Next Generation Networks
T e iln e h m e r A IP -A d r = P T e l-N r = X
R T P -K a n a l
T e l-N r = Z
IP -A d r = R IP -N e tz (In te rn e t) S e s s io n s a u fb a u S p r a c h ü b e r m ittlu n g : IP -P a k e te S e s s io n s a b b a u
G W
IS D N
T e iln e h m e r B T e l-N r = Y
V e rb in d u n g s a u fb a u k o n tin u ie r lic h e r B its tr o m V e rb in d u n g s a b b a u
IS D N V e rb in d u n g
Abb. 1.2-2: Prinzip der Erweiterung von ISDN mit einem IP-Netz GW:Gateway, IP-Adr: IP-Adresse, Tel-Nr: Telefonnummer
Eine Erweiterung von ISDN mit einem IP-Netz setzt ein VoIP-Gateway (kurz Gateway) zwischen diesen beiden Netzen voraus. Das Gateway hat seitens des ISDN eine Telefonnummer und seitens des IP-Netzes eine IP-Adresse. Zwischen einem IP-Telefon am IP-Netz und einem Telefon am ISDN muss eine Telefonverbindung vor dem Telefongespräch aufgebaut und danach abgebaut werden. Eine derartige Verbindung setzt sich aus einem RTP-Kanal über das IP-Netz und aus einer ISDN-Verbindung über das ISDN zusammen – vergleiche Abbildung 1.2-1. Der Auf- und Abbau einer Verbindung über das ISDN verläuft nach dem D-Kanal-Protokoll und nach dem Signalisierungssystem Nr. 7 (SS7). Näheres ist in Abschnitt 2.4 zu finden.
www.wiwobooks.com
RTP-Kanal als Verlängerung einer ISDNVerbindung
Eine Telefonverbindung zwischen einem IP-Telefon am IP-Netz und einem Telefon am ISDN könnte man sich so vorstellen, als ob die ISDN-Verbindung zwischen ISDN-Telefon und Gateway mit einem RTP-Kanal bis zum IP-Telefon verlängert wäre. Über den RTP-Kanal zwischen IP-Telefon und Gateway wird die Sprache in IP-Paketen transportiert. Über die ISDN-Verbindung wird die Sprache als kontinuierlicher Bitstrom mit 64kbit/s übermittelt.
Aufgabe des Gateway
Eine Aufgabe des Gateway zwischen ISDN und IP-Netz besteht in der Umwandlung des kontinuierlichen Bitstroms mit der Sprache in IP-Pakete und umgekehrt. Das Gateway muss auch für eine Umsetzung von Adressen sorgen. Bei einem ankommenden Anruf von einem ISDN-Telefon zu einem IP-Telefon muss das Gateway in der Lage sein, zu ermitteln, wohin – also unter welcher IP-Adresse – es eine VoIP-Session aufbauen soll. Hierfür muss das Gateway entweder selbst über eine Zuordnung Telefonnummer IP-Adresse verfügen, oder es muss diese Zuordnung an einer Stelle abfragen können – siehe hierfür z.B. die Abbildungen 1.2-6 und -7.
1.2 Ansätze für VoIP
13
1.2.3 IP-Netz als Backbone für PSTN/ISDN Die VoIP-Dienste können auch von Internet Service Providern (ISP) angeboten VoIPwerden. Bieten einige ISPs die VoIP-Dienste an, besteht die Möglichkeit, IP- Gateway Netze und insbesondere das Internet als eine Art Backbone für das öffentliche bei ISP Telefonnetz (PSTN) zu nutzen. Abbildung 1.2-3 illustriert dies. Es wurde hier angenommen, dass die beiden ISPs entsprechend in Deutschland und in den USA ein Abkommen vereinbart haben und dass die entsprechenden Ressourcen im IP-Netz für die Sprachübermittlung zwischen ihnen reserviert wurden, um eine ausreichende Qualität der Sprachübermittlung zu garantieren. P S T N
T e iln e h m e r A 6
T e l-N r = X D e u ts c h la n d
D lo k a l
G W IS P
In te rn e t (IP -N e tz ) V o IP -S e s s io n s
IP -A d r = A
T e iln e h m e r B G W IS P IP -A d r = B
U S A lo k a l
T e l-N r = Y U S A
Abb. 1.2-3: Bereitstellung der VoIP-Dienste durch die Nutzung von Gateways bei ISPs
www.wiwobooks.com
GW:Gateway, Tel-Nr: Telefonnummer
Möchte der Teilnehmer A in Deutschland den Teilnehmer B in den USA anrufen, wählt er zuerst die Telefonnummer seines ISP aus und gibt eine Ziffer als Kennzahl für den VoIP-Dienst an. Danach erhält er in seinem Telefon einen Freiton, sodass er die Telefonnummer des Teilnehmers B angeben kann. Nach der USA-Vorwahl entscheidet das Gateway beim ISP in Deutschland, unter welcher IP-Adresse, d.h. zu welchem Gateway in den USA die notwendige VoIP-Session aufgebaut werden muss. Beim Aufbau der VoIP-Session wird auch die Telefonnummer von Teilnehmer B an das Gateway in den USA übergeben. Somit kann das Gateway in den USA den ankommenden Anruf zum Teilnehmer B weiterleiten. Die Telefonverbindung zwischen Teilnehmer A und Teilnehmer B setzt sich aus einer Telefonverbindung zwischen Teilnehmer A und ISP in Deutschland, einer VoIP-Session über das IP-Netz und einer Telefonverbindung zwischen ISP und Teilnehmer B in den USA zusammen. Da die Übertragungskosten über das Internet niedrig sind, lassen sich dadurch die Kosten für die internationalen Telefonverbindungen enorm reduzieren. In Abbildung 1.2-3 wurde der Fall gezeigt, bei dem die VoIP-Gateways zwi- VoIP als schen dem IP-Netz und dem öffentlichen Telefonnetz bei ISPs installiert wur- IN-Dienst den. Die VoIP-Gateways können jedoch auch direkt in die Vermittlungsstellen im PSTN bzw. im ISDN integriert werden. Abbildung 1.2-4 illustriert eine derartige Lösung. Sie kann als Erweiterung von PSTN zum Intelligenten Netz (IN)
14
1
Vom einfachen Telefon bis zu Next Generation Networks
angesehen werden (vgl. Abb. 1.1-5). Also handelt es sich hier um einen INDienst, nach dem über ein IP-Netz (wie z.B. Internet) internationale Telefonverbindungen realisiert werden. So kann heute auch Internet-Telefonie – im Rahmen der sog. Flatrate – von verschiedenen ISPs angeboten werden.
T e iln e h m e r A
P S T N
V S t 6
T e l-N r = X D e u ts c h la n d
V S t
G W
In te rn e t (IP -N e tz )
G W
V o IP -S e s s io n s IP -A d r = A
T e iln e h m e r B
IP -A d r = B
T e l-N r = Y U S A
Abb. 1.2-4: VoIP-Dienst als IN-Dienst – Bereitstellung der Internet-Telefonie GW: Gateway, VSt: Vermittlungsstelle
Möchte der Teilnehmer A in Deutschland beispielsweise den Teilnehmer B in den USA anrufen, wählt er einfach wie üblich seine Telefonnummer. Als Folge wird über das Internet zwischen einer Vermittlungsstelle in Deutschland und einer Vermittlungsstelle in den USA eine VoIP-Session für dieses Telefongespräch aufgebaut. Die Gebühren für internationale Verbindungen lassen sich auf diesem Weg stark reduzieren.
www.wiwobooks.com
Wie in Abbildung 1.2-4 ersichtlich ist, tritt hier aber ein Problem auf. Dieses besteht darin, dass die IP-Adresse des Gateway in den USA, über den der Teilnehmer B erreichbar ist, zuerst ermittelt werden muss. Beim Einsatz von SIP als VoIP-Signalisierungsprotokoll – d.h. als Protokoll zum Aufbau einer VoIPSession – wird die gewünschte IP-Adresse mit Hilfe von DNS (Domain Name System, s. Abschnitt 3.5) ermittelt. Das folgende Beispiel erläutert den möglichen Ablauf. Beispiel: Angenommen, der Teilnehmer B in den USA hat z.B. die Telefonnummer 001abcd-vxyz, wobei abcd die Vorwahl – die als Verweis auf die Vermittlungsstelle (VSt) dient – und vxyz die Nummer des Anschlusses an der VSt in den USA darstellt. Durch die Verweise 001 us (USA-Domain) und abcd subdomain (d.h. Subdomain in den USA mit dem richtigen Gateway) kann beim SIP-Einsatz aus der Telefonnummer des Teilnehmers B der URI
[email protected] generiert werden. Dieser URI wird mit Hilfe von DNS auf die gesuchte IP-Adresse des Gateway abgebildet (s. hierfür Abschnitt 3.5 sowie das Beispiel in Abschnitt 7.1.5).
VoIP-Einsatz im Unternehmen
Ist ein Unternehmen an mehreren Standorten angesiedelt und hat noch die klassischen TK-Anlagen in Betrieb, kann ein IP-Netz auch für eine standortübergreifende Vernetzung von TK-Anlagen des Unternehmens genutzt werden. Abbildung 1.2-5 zeigt eine derartige Vernetzung.
1.2 Ansätze für VoIP
... ...
T K A n l G W
IP -N e tz w e rk
T K A n l G W
R
P S T N /IS D N IP -N e tz (In te rn e t) R
... ...
S ta n d o r t B
S ta n d o r t A 6
15
IP -N e tz w e rk
Abb. 1.2-5: Vernetzung von TK-Anlagen über ein IP-Netz und das PSTN/ISDN R. Router, GW:Gateway
Die Sprachkommunikation zwischen den Standorten A und B kann sowohl über das PSTN/ISDN als auch über das IP-Netz abgewickelt werden. Wird das sog. Low Cost Routing in den TK-Anlagen unterstützt, so können die Telefonkosten zwischen den beiden Standorten reduziert werden. Befindet sich ein Standort beispielsweise im Ausland, können die Telefonverbindungen zwischen den Standorten über das IP-Netz realisiert werden, um die anfallenden Telefonkosten zu reduzieren.
www.wiwobooks.com
1.2.4 Kleines IP-Netzwerk als IP-TK-Anlage
Ein lokales IP-Netzwerk – wie in Abbildungen 1.2-6 und -7 illustriert – kann Einsatz auch als TK-Anlage fungieren, sodass alle Rechner zusätzlich zu ihrer ur- eines VoIPsprünglichen Funktion als IP-Telefone dienen können. Ein solches Netzwerk Servers nennt man IP-TK-Anlage, IP-basierte TK-Anlage oder auch IP-PBX (Private Branche Exchange). Bei einer IP-TK-Anlage wird ein VoIP-Server als zentrale Komponente eingesetzt. Wie hier ersichtlich ist, dient der VoIP-Server auch als Gateway zwischen dem IP-Netzwerk und dem öffentlichen PSTN/ISDN. In einem Telefonapparat am PSTN/ISDN kann aber nur eine Telefonnummer Problem bei als Adresse angegeben werden, und somit müssen alle Rechner im IP- der AdressieNetzwerk, die als IP-Telefone dienen können, außer ihren IP-Adressen auch rung Telefonnummern besitzen, damit sie aus dem PSTN/ISDN erreicht werden können. Es muss folglich die Möglichkeit bestehen, auf irgendeine Art und Weise die IP-Adresse Y des Rechners mit der Telefonnummer X zu ermitteln. Dieses Problem wird vom jeweiligen Signalisierungsprotokoll folgendermaßen gelöst: Beim Einsatz von H.323 (s. Kapitel 6) wird eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse auf einer speziellen Systemkomponente – als Gatekeeper bezeichnet – abgespeichert. Beim Einsatz von SIP (s. Kapitel 7) wird aus einer Telefonnummer ein SIPURI – als VoIP-Adresse eines IP-Telefons – gebildet, und die Ermittlung
16
1
Vom einfachen Telefon bis zu Next Generation Networks
der dem SIP-URI entsprechenden IP-Adresse des IP-Telefons erfolgt mit Hilfe von DNS (Domain Name System, s. Abschnitt 3.5). Die hier dargestellten Beispiele (Abb. 1.2-6 und 7) veranschaulichen, wie ein IP-Netzwerk – sowohl beim Einsatz von H.323 als auch von SIP – als IP-TKAnlage dienen kann. Hierbei soll insbesondere der grundlegende Unterschied bei der Adressierung zwischen H.323 und SIP zum Ausdruck gebracht werden. Beispiel: Abbildung 1.2-6 zeigt, wie ein kleines IP-Netzwerk als IP-TK-Anlage beim H.323Einsatz dienen kann. Hier fungiert die zentrale VoIP-Systemkomponente einerseits als VoIPGateway zwischen dem IP-Netzwerk und dem ISDN, andererseits verfügt sie über eine TaIP-Adresse und stellt somit die Gatekeeperbelle mit den Zuordnungen Telefonnummer Funktion zur Verfügung (s. Abschnitt 6.2.1). Im Weiteren wird angenommen, dass der VoIPGateway seitens des ISDN unter der Rufnummer abcd erreichbar ist und dass diese Rufnummer als Vorwahl für das ganze IP-Netzwerk gilt.
X 1
, Y
X
...
Einsatz von H.323
1
n
, Y
T ln B n
V o IP S e rv e r/ G a te w a y
IP -N e tz w e rk
T ln A
IP -A d r = Y
W e lc h e IP -A d r. h a t X
n ?
T ln C
IS D N
0
IP -A d r. v o n X
n
T e l-N r = a c b d
is t Y
n
X p
T a b e lle m it T e l.- N r = > I P - A d r G a te k e e p e r -F u n k tio n
www.wiwobooks.com a )
A u fb a u e in e r S e s s io n T e le fo n g e s p rä c h A b b a u e in e r S e s s io n
b )
W e lc h e IP -A d r. h a t X
c )
p
?
A u fb a u e in e r S e s s io n
IP -A d r. v o n X
A b b a u e in e r S e s s io n X
, ..., X n, X Y 0, Y 1, ..., Y 1
: T e le fo n n u m m e rn n : I P - A d r e s s e n p
p
is t Y
S E T U P 1
A u fb a u e in e r S e s s io n T e le fo n g e s p rä c h A b b a u e in e r S e s s io n
2
0
S E T U P
T e le fo n g e s p rä c h
1 2
1 A u fb a u e in e r IS D N -V e rb in d u n g 2 A b b a u e in e r IS D N -V e rb in d u n g
Abb. 1.2-6: Ein lokales IP-Netzwerk als IP-TK-Anlage – Einsatz von H.323: a) Kommunikation zwischen beiden Teilnehmern am IP-Netzwerk, b) Anruf wird vom ISDN zu einem Teilnehmer am IP-Netzwerk initiiert, c) Anruf wird vom IP-Netzwerk zu einem Teilnehmer am ISDN initiiert. Adr: Adresse, Tln: Teilnehmer
Die einzelnen Fälle in Abbildung 1.2-6 sind wie folgt zu interpretieren:
VoIP zwischen Teilnehmern am Netzwerk
a)
Hier initiiert der Teilnehmer A am IP-Netzwerk einen Anruf zum Teilnehmer B ebenso am IP-Netzwerk. Das IP-Telefon von Teilnehmer A muss nun wissen, unter welcher IPAdresse eine Session für die Sprachübermittlung über das IP-Netzwerk aufgebaut werden soll. Hierfür fragt das IP-Telefon des Teilnehmers A beim Gatekeeper (im VoIPGateway) nach der IP-Adresse des IP-Telefons von Teilnehmer B. Ist dem IP-Telefon von Teilnehmer A diese IP-Adresse bekannt, initiiert es den Aufbau einer VoIP-Session
17
1.2 Ansätze für VoIP nach H.323. Nachdem die Session aufgebaut wurde, kann das Telefongespräch zwischen den Teilnehmern A und B beginnen. Nach dem Beenden des Telefongesprächs wird die Session abgebaut, und damit werden die eventuell für die Sprachübermittlung reservierten Netzwerk-Ressourcen wieder freigegeben. b)
Hier initiiert der Teilnehmer C am ISDN eine Verbindung zum Teilnehmer A am IPNetzwerk. Hierfür wird eine Nachricht SETUP mit der Rufnummer des Teilnehmers A 4 nach dem D-Kanalprotokoll (s. Abbildung 2.3-3) abgeschickt . Weil in der Rufnummer des Teilnehmers A die Vorwahl abcd – als Rufnummer des VoIP-Gateway – enthalten ist, wird SETUP auf dem Weg zum Telefon von Teilnehmer A an das VoIP- Gateway geleitet.
Teilnehmer am ISDN initiiert eine Verbindung
Da das VoIP-Gateway – hier auch als Gatekeeper fungiert – über die Tabelle mit den Zuordnungen Telefonnummer IP-Adresse für alle Teilnehmer im IP-Netzwerk verfügt, wird aus dieser Tabelle die IP-Adresse des IP-Telefons von Teilnehmer A entnommen. Daraufhin kann einerseits mit dem Aufbau einer Session zwischen Teilnehmer A und VoIP-Gateway begonnen und andererseits der Aufbau der ISDN-Verbindung zwischen VoIP-Gateway und Teilnehmer C fortgesetzt werden. Wie dies verlaufen kann, erläutert Abschnitt 6.4.5. Sprache zwischen den Teilnehmern A und C wird im Netzwerk über einen RTP-Kanal und im ISDN über eine B-Kanalverbindung übermittelt (vgl. Abbildung 1.2-2). c)
In diesem Fall initiiert der Teilnehmer A am IP-Netzwerk eine Verbindung zum Teilnehmer C am ISDN. Hierfür muss das IP-Telefon von A wissen, unter welcher IPAdresse eine Session zum Teilnehmer C aufgebaut werden soll. Daher fragt das IPTelefon von A beim Gatekeeper im VoIP-Gateway die IP-Adresse des IP-Telefons von C ab und erhält von ihm die IP-Adresse Y0 – also die IP-Adresse des VoIP-Gateway. Damit dient dieses Gateway als Vertreter aller Teilnehmer am ISDN. Im Weiteren verläuft hier der Aufbau der Session zwischen Teilnehmer A und VoIP-Gateway und der Aufbau einer ISDN-Verbindung zwischen dem VoIP-Gateway und dem Teilnehmer C nach den in Abschnitt 6.4.5 gezeigten Prinzipien.
www.wiwobooks.com
Beispiel: Abbildung 1.2-7 zeigt, wie ein kleines IP-Netzwerk beim SIP-Einsatz als IP-TKAnlage fungieren kann. Hier braucht man keine zentrale Systemkomponente als Gatekeeper mit den Zuordnungen Telefonnummer IP-Adresse, wie dies beim H.323-Einsatz der Fall war. Die Ermittlung der IP-Adresse eines IP-Telefons, an das ein VoIP-Anruf geleitet werden soll, erfolgt bei SIP mit Hilfe von DNS (s. Abschnitt 3.5). In diesem Beispiel ist das VoIP-Gateway seitens des ISDN unter der Rufnummer abcd erreichbar, die als Vorwahl für das ganze IP-Netzwerk gilt. Um DNS nutzen zu können, muss das IP-Netzwerk eine DNS-Domain bilden – z.B. hier die Domain abc.de. Die Nutzung von DNS setzt aber voraus, dass jedes IP-Telefon als Rechner in der Domain abc.de einen Namen – genauer gesagt einen Hostnamen, wie z.B. sonne.abc.de – hat. Als VoIP-Adressen werden bei SIP die SIP-URIs gebildet. Wie Abschnitt 5 7.1.3 zeigt, kann ein SIP-URI in einem kleinen IP-Netzwerk folgende Struktur haben: sip:telefonnummer@hostname, wie z.B. sip:
[email protected]
4
Zwischen den ISDN-Vermittlungsknoten wird das Signalisierungssystem Nr. 7 (SS7) eingesetzt – vgl. Abbildung 2.3-3. Dies wurde hier außer Acht gelassen.
5
In großen IP-Netzwerken ist es sinnvoll, einen SIP-Proxy einzusetzen und die SIP-URIs in der Form sip:telefonnummer@domainname zu verwenden – s. Abschnitt 7.1.3.
Teilnehmer am Netzwerk initiiert eine Session
Einsatz von SIP
18
1
Vom einfachen Telefon bis zu Next Generation Networks Ein SIP-URI dieser Art kann mit Hilfe von DNS einfach auf die IP-Adresse des betreffenden IP-Telefons abgebildet werden. Bei dieser Art von SIP-URIs benötigt man keine zentrale Systemkomponente – wie z.B. einen SIP-Proxy (Abbildungen 7.1-3 und -4).
U
, Y 1
X
T ln A
X
R o u te r
so n n e 1
m o n d
In te rn e t
D N S
1
n
, Y
g a te w a y n
V o IP S e rv e r/ G a te w a y
IP -A d r = Y 0
T ln C IS D N
A b b a u e in e r S e s s io n , ..., X n, X , Y 1, ..., Y
p
2
T e le fo n g e s p rä c h
: T e le fo n n u m m e rn : IP -A d re sse n
p
S E T U P 1
S E T U P
A u fb a u e in e r S e s s io n
c )
X
T e l-N r = a c b d
A u fb a u e in e r S e s s io n T e le fo n g e s p rä c h A b b a u e in e r S e s s io n
b )
1
U
T ln B
IP -N e tz w e rk a b c .d e
D N S
A u fb a u e in e r S e s s io n T e le fo n g e s p rä c h A b b a u e in e r S e s s io n
a )
X
1
1 2
1 A u fb a u e in e r IS D N -V e rb in d u n g
www.wiwobooks.com Y
U
0
1
: X
1
n
@ s o n n e .a b c .d e
U
n
: X
2 A b b a u e in e r IS D N -V e rb in d u n g
n
@ m o n d .a b c .d e
Abb. 1.2-7: Ein lokales IP-Netzwerk als IP-TK-Anlage – Einsatz von SIP: a) Kommunikation zwischen beiden Teilnehmern am IP-Netzwerk, b) Anruf wird vom ISDN zu einem Teilnehmer am IP-Netzwerk initiiert, c) Anruf wird vom IP-Netzwerk zu einem Teilnehmer am ISDN initiiert. DNS: Domain Name System, U: SIP-URI, Tln: Teilnehmer
Die einzelnen Fälle in Abbildung 1.2-6 sind folgendermaßen zu interpretieren:
VoIP zwischen Teilnehmern am Netzwerk
a)
Hier möchte der Teilnehmer A am IP-Netzwerk einen Anruf zu einem anderen Teilnehmer B ebenso am IP-Netzwerk initiieren. Das IP-Telefon von A ermittelt zuerst durch eine DNS-Abfrage die dem SIP-URI
[email protected] entsprechende IPAdresse des IP-Telefons von B – hier des Rechners mond. Anschließend sendet das IPTelefon von A die SIP-Nachricht INVITE an das IP-Telefon von B. Wie der weitere Aufbau einer Session zwischen den IP-Telefonen der Teilnehmer A und B hier verläuft, ist z.B. Abbildung 7.1-12 zu entnehmen. Nach dem Aufbau der Session kann das Telefongespräch zwischen den Teilnehmern A und B beginnen, und nach dem Ende des Telefongesprächs wird die Session abgebaut.
Teilnehmer am ISDN initiiert eine Verbindung
b)
Hier initiiert der Teilnehmer C am ISDN eine Verbindung zum Teilnehmer A am IP-Netzwerk. Hierfür wird eine Nachricht SETUP nach dem D-Kanalprotokoll (s. Abb. 2.3-3) mit der Rufnummer X1 des Teilnehmers A abgeschickt. Weil die Vorwahl abcd als Rufnummer des VoIP-Gateway in der Rufnummer des Teilnehmers A enthalten ist, wird SETUP an das VoIP-Gateway geleitet. Dieses bildet zuerst den SIP-URI
[email protected], ermittelt durch eine DNS-Abfrage die dem SIP-URI entsprechende IP-Adresse und initiiert durch das Absenden der SIP-Nachricht INVITE eine Session zum IP-Telefon von A. Wie der weitere Aufbau einer Session zwischen den IP-Telefonen von A und B verläuft, ist Abbildung 7.9-3 zu entnehmen.
19
1.3 Evolution der Mobilfunknetze c)
Hier möchte der Teilnehmer A am IP-Netzwerk einen Anruf zum Teilnehmer C am ISDN mit der Rufnummer Xp initiieren. Das IP-Telefon von A bildet aus der Rufnummer Xp und aus dem Hostnamen des VoIP-Gateway gateway.abc.de den SIP-URI
[email protected], ermittelt durch eine DNS-Abfrage die dem SIP-URI entsprechende IP-Adresse – als IP-Adresse des VoIP-Gateway – und initiiert anschließend durch das Absenden der SIP-Nachricht INVITE eine Session zum IP-Telefon von Teilnehmer C. Nach dem Eintreffen von INVITE beim VoIP-Gateway initiiert er durch das Absenden von SETUP unter die Rufnummer Xp eine ISDN-Verbindung zum Telefon von Teilnehmer C. Wie der Aufbau einer Session zwischen den IP-Telefonen der Teilnehmer A und C weiter verläuft, ist aus Abbildung 7.9-3 ersichtlich.
Teilnehmer am Netzwerk initiiert eine Session
Die hier dargestellten Beispiele – Abbildungen 1.2-6 und 7 – haben nur einige Einsatz von Möglichkeiten gezeigt, wie ein IP-Netzwerk mit VoIP als TK-Anlage dienen Asterisk kann. Um solche Ideen zu verwirklichen, kann frei verfügbare Software – siehe z.B. http://www.asterisk.org – eingesetzt werden. Mit Asterisk können in einem IP-Netzwerk alle Funktionen einer herkömmlichen TK-Anlage zur Verfügung gestellt werden.
1.3
Evolution der Mobilfunknetze
www.wiwobooks.com
Die Mobilkommunikation ist einer der wichtigsten Trends auf dem Gebiet der Telekommunikation. Die Schwerpunkte ihrer Entwicklung in den letzten 15 Jahren haben sich insbesondere auf die Konzepte der Mobilfunknetze konzentriert. Man unterscheidet heute bereits mehrere Generationen der Mobilfunknetze und bezeichnet sie als 2G, 2.5G, 3G und 4G (G für Generation). Die Mobilfunknetze nach dem Standard GSM (Global System for Mobile GSM als 2G Communications) stellen die zweite Generation (2G) dar. Mit ihrer Hilfe ist nur die Sprachkommunikation und der Austausch von begrenzten Datenmengen möglich. Durch die Bündelung von bis zu 8 Kanälen nach dem Konzept HSCSD (High Speed Circuit Switched Data) ist bei der Datenübertragung eine Bitrate bis zu 115.2 kbit/s (theoretisch) möglich. Die Erweiterung der GSM-Mobilfunknetze um die Möglichkeiten der Paket- GPRS vermittlung wird als Generation 2.5 (kurz 2.5G) angesehen. Diese Bezeichnung als 2.5G sollte darauf verweisen, dass es sich hierbei um eine Stufe zwischen 2G und 3G – also um eine Übergangsvariante – handelt. Diese erweiterte GSM-Variante nennt man GPRS (General Packet Radio Service). Die dritte Generation (3G) der Mobilfunknetze stellt UMTS (Universal Mobile UMTS Telecommunikations System) dar. Es handelt sich hier um ein universelles Mo- als 3G bilfunknetz, das fast 200-mal schneller als heutige GSM-Mobilfunknetze ist. Im UMTS kann die Datenübertragung mit einer Bitrate von bis zu 2 Mbit/s erfolgen.
20
1
Vom einfachen Telefon bis zu Next Generation Networks
4G
Heute spricht man bereits von der vierten Generation (4G) der Mobilfunknetze. Hiermit ist eine integrierte Netzstruktur auf der Basis von UMTS und WLANs (Wireless Local Area Networks) gemeint.
Funktionsbereiche in Mobilfunknetzen
Alle Generationen der Mobilfunknetze werden nach den gleichen Prinzipien aufgebaut. Jedes Mobilfunknetz enthält die folgenden Funktionsbereiche: Funkzugangsnetz als RAN (Radio Access Network), Core Network (CN), auch Kernnetz genannt.
FunkZugangsnetz
Das Funkzugangsnetz stellt eigentlich das vollständige Versorgungsgebiet eines Mobilfunknetzes dar und wird auf eine Vielzahl sog. Zellen aufgeteilt. Jede Zelle enthält eine Station (oft Basisstation genannt) mit Sender und Empfänger, mit deren Hilfe die mobilen Endgeräte (d.h. Handys, PDAs) den Zugang zum Kernnetz haben (s. Abb. 1.3-1, 1.3-2 und 1.3-3).
Core Network
Das Core Network enthält die gesamte „Intelligenz“ des Netzes, hierzu gehören zwei besondere Register – HLR (Home Location Register) und VLR (Visitor Location Register) – sowie die Gateways zum ISDN und zum Internet. Mit HLR und VLR wird die aktuelle Lokation von mobilen Teilnehmern verfolgt, um zwei wichtige Funktionen der Mobilfunknetze zu realisieren – und zwar Roaming und Handover.
www.wiwobooks.com
Im Weiteren werden die Generationen 2G, 2.5G und 3G der Mobilfunknetze kurz dargestellt.
1.3.1 Aufbau der Mobilfunknetze nach GSM Aufbau des Funkzugangsnetzes
Die allgemeine Struktur der Mobilfunknetze nach GSM – also der Generation 2G – zeigt Abbildung 1.3-1. Jede Zelle im Funkzugangsnetz, d.h. im GSM RAN, enthält eine Basisstation, die als BTS bezeichnet wird. Mehrere BTSs, die im Frequenzbereich von 900 MHz bzw. von 1800 MHz arbeiten, werden an einen Base Station Controller (BSC) angeschlossen, über den sie den Zugang zu einer Vermittlungsstelle MSC im Core Network haben. Zu den Aufgaben des BSC gehören die Steuerung und Kontrolle der Funk-Ressourcen von BTSs und die Herstellung von Verbindungen zu einer Vermittlungsstelle MSC. Darüber hinaus fungiert ein BSC als zentraler Steuerungspunkt für Handover. Darunter versteht man den Verlauf der Steuerung, falls ein mobiler Teilnehmer während einer bestehenden Verbindung eine Zelle verlässt und in eine andere aufgenommen werden muss. Hierbei darf die bestehende Verbindung nicht abgebrochen werden.
1.3 Evolution der Mobilfunknetze
R A N
...
V L R
B S C
...
G S M
B S C
...
B T S
M S C G M S C
...
E IR
Z e lle
H L R
IS D N
A C
...
B S C A
b is
...
A
...
B T S
21
B S C
M S C V L R G S M
C o r e N e tw o r k
Abb. 1.3-1: Allgemeine Struktur der Mobilfunknetze nach GSM AC: Authentication Center, BSC: Base Station Controller, BTS: Base Transceiver Station, EIR: Equipment Identification Register, HLR: Home Location Register, GMSC: Gateway MS: Mobile Station, MSC: Message Switching Center, RAN: Radio Access Network VLR: Visitor Location Register
HLR ist ein zentrales Register innerhalb jedes Mobilfunknetzes. Im HLR wer- Bedeutung den alle Informationen über diejenigen Teilnehmer des Mobilfunknetzes als des Registers Teilnehmerdatensätze gespeichert, die einem bestimmten Bereich im Funkzu- HLR gangsnetz zuzuordnen sind. Je nach Größe des Mobilfunknetzes und seiner Teilnehmerzahl sowie nach der Netzorganisation können in einem Mobilfunknetz auch mehrere HLRs vorhanden sein. Die Rufnummer jedes Teilnehmers zeigt an, zu welchem Mobilfunknetz er gehört und in welchem HLR sich seine Teilnehmerdaten befinden.
www.wiwobooks.com
Auf die Teilnehmerdaten im HLR wird u.a. beim Verbindungsaufbau seitens Authentifieines mobilen Teilnehmers zugegriffen, um seine Rechte zu überprüfen. Es zierung handelt sich hierbei um eine Authentifizierung mit Hilfe der Komponente AC (Authentication Center). Jede Vermittlungsstelle MSC enthält ein VLR, in dem aufgelistet wird, welche Bedeutung mobilen Teilnehmer (d.h. Handys) sich in den Zellen aufhalten, die zum Ver- des Registers sorgungsbereich dieser MSC gehören. HLR und VLR sind so miteinander ver- VLR knüpft, dass die Daten jedes Teilnehmers im HLR die Angabe enthalten, in welchem VLR seine aktuelle Lokation im Funkzugangsnetz abgelesen werden kann. Eine besondere Vermittlungsstelle stellt das Gateway GMSC zum ISDN dar. GMSC enthält aber keinen VLR. Für die Kommunikation zwischen den Vermittlungsstellen MSC wird das Pro- SS7-Einsatz tokollsystem SS7 (Signalling System No. 7), also das gleiche Protokollsystem wie zwischen den Vermittlungsstellen im ISDN, eingesetzt (s. Abschnitt 2.4).
22
1
Vom einfachen Telefon bis zu Next Generation Networks
Bedeutung des Registers EIR
Um die Nutzung gestohlener Handys zu verhindern, wurde das Register EIR (Equipment Identity Register) eingeführt. Im EIR werden die eindeutigen Nummern der Endgeräte gespeichert. Sie werden hier in einer schwarzen bzw. in einer weißen Liste geführt. Die schwarze Liste enthält die Nummern gestohlener Endgeräte, sodass ihre Nutzung verhindert werden kann.
Core Network als CS-Domain
In Mobilfunknetzen nach GSM wird nur die Leitungsvermittlung (Circuit Switching) unterstützt. Somit bildet das GSM Core Network eigentlich nur eine Circuit Switched Domain (kurz CS-Domain). Für detaillierte Informationen über die Mobilfunknetze GSM sei auf [Walk 01] verwiesen.
1.3.2 Aufbau von GPRS GPRS (General Packet Radio Service) als Generation 2.5G stellt eine Erweiterung der Mobilfunknetze nach GSM um die Funktionen für die Paketvermittlung dar. Die allgemeine Architektur von GPRS illustriert Abbildung 1.3-2.
www.wiwobooks.com G P R S C o r e N e tw o r k
B T S
...
M S C
M S
Z e lle
H L R
G
...
B S C m
...
U
C S D o m a in
V L R
A
b
S G S N P S D o m a in
... ...
R A N
G M S C
P S T N / IS D N
G G S N
IP -N e tz e (In te rn e t)
A C
... ...
G S M
Abb. 1.3-2: Allgemeine Architektur von GPRS CS: Circuit Switched, PS: Packet Switched, GGSN: Gateway GPRS Support Node, SGSN: Serving GPRS Support Node, weitere Abkürzungen wie in Abb. 1.3-1
Core Network als CS- und PSDomain
Vergleicht man Abbildung 1.3-1 mit Abbildung 1.3-2, so stellt man fest, dass das GPRS Core Network im Vergleich zum GSM Core Network zusätzlich die Komponenten SGSN und GGSN enthält, mit deren Hilfe die Paketvermittlung und die Anbindung an das Internet realisiert werden. Diese Funktionskomponenten bilden eine Packet Switched Domain (kurz PS-Domain).
Aufgabe von SGSN
SGSN stellt die für die Abwicklung des Datenverkehrs nach der Paketvermittlung notwendigen Funktionen zur Verfügung. Zu diesem Zweck leitet SGSN die IP-Pakete an einen BSC weiter, die für mobile Endgeräte in seinem Versorgungsbereich bestimmt sind oder von einem mobilen Endgerät abgeschickt werden. Darüber hinaus sorgt SGSN für die Verschlüsselung und Authentifi-
1.3 Evolution der Mobilfunknetze
23
zierung, das Mobilitätsmanagement sowie für die Verbindungen zu HLR, MSC, BSC innerhalb der CS-Domain und zum Gateway GGSN. GGSN stellt die für die Abwicklung des Datenverkehrs zum Internet notwendi- Aufgabe von gen Gateway-Funktionen zur Verfügung. Dazu gehört u.a. die Bereitstellung GGSN von Schnittstellen zu den Routern in externen IP-Netzen. Aus Sicht eines externen IP-Netzes fungiert GGSN als Router.
1.3.3 Konzept von UMTS Die Entwicklung des Konzeptes für die dritte Generation (3G) der Mobilfunknetze begann bereits 1992, als die ITU das Projekt IMT-2000 (International Mobile Telecommunications 2000) ins Leben rief. Man bezeichnet IMT-2000 auch als International Mobile Telecommunications at 2000 MHz (http://www.itu.int/home/imt.html). Wie der Name schon sagt, handelt es sich um ein Mobilfunksystem, das im Frequenzbereich um 2000 MHz funktioniert. Um allen Nationen wirtschaftlich entgegenzukommen, integrierte man im IMT-2000 mehrere Einzelstandards, um es den verschiedenen Netzbetreibern zu ermöglichen, ihre zum Teil bereits bestehenden 2G- und 2.5GMobilfunknetze in die zukünftigen 3G-Mobilfunknetze integrieren zu können.
IMT-2000 als G3Mobilfunknetz von der ITU
UMTS (Universal Mobile Telekommunications System) stellt ein 3G-Mobilfunknetz dar und ist ein europäisches Konzept, das von ETSI 1998 zuerst spezifiziert wurde. UMTS ist ein Teil des Standards IMT-2000. Die Entwicklung und Einführung von UMTS wird vom 3GPP (3rd Generation Partnership Project) betreut. 3GPP ist ein Zusammenschluss von Unternehmen, Herstellern und Organisationen mit dem Ziel, die technischen Spezifikationen und die organisatorische Realisierung für UMTS voranzutreiben.
UMTS als G3-Mobilfunknetz von ETSI
www.wiwobooks.com
Wie bei GSM und GPRS unterscheidet man auch bei UMTS zwei Bereiche:
FunktionsUTRAN (UMTS Terrestrial Radio Access Network) als UMTS-Funkzu- bereiche bei UMTS
gangsnetz und
Core Network (CN, Kernnetz). Abbildung 1.3-3 zeigt die Funktionsbereiche bei UMTS. Wie hier ersichtlich ist, wird das GSM-Funkzugangsnetz (GSM RAN) mit UMTS integriert, um die Kompatibilität mit 2G-Mobilfunknetzen zu erreichen. Dadurch können GSMHandys auch mit UMTS-Endgeräten kommunizieren. Da das Core Network im UMTS die CS- und PS-Domains enthält, bedeutet Core Netdies, dass UMTS die Leistungsmerkmale der Leitungsvermittlung – also der work GSM-Technik – und der Paketvermittlung – also der GPRS-Technik – in sich integriert. Dadurch schafft UMTS die besten Voraussetzungen für ein universelles Mobilfunknetz. Darüber hinaus enthält UMTS die Komponenten in der
24
1
Vom einfachen Telefon bis zu Next Generation Networks
PS-Domain, die den Transport von Daten auf Basis des IP-Protokolls unterstützen. Sie kann damit als Internet-Zubringer für mobile Endgeräte dienen.
G I
b u C S
...
R N C U T R A N
C S D o m a in
M S C
I
S G S N u P S
G M S C
P S T N / IS D N
G G S N
IP -N e tz e (In te rn e t)
... ...
... ...
...
A
B S C
...
R A N
...
G S M
P S D o m a in
C o r e N e tw o r k (C N )
Abb. 1.3-3: Funktionsbereiche bei UMTS – UTRAN, CS und PS Domains CS: Circuit Switched, PS: Packet Switched, RCN: Radio Network Controller, UTRAN: UMTS Terrestrial Radio Access Network, weitere Abkürzungen wie in Abb. 1.3-1 und 1.3-2
Vereinfachte Architektur von UMTS
www.wiwobooks.com
Erste Ausbaustufe als 3GPP Release 99
Die in Abbildung 1.3-3 dargestellten UMTS-Funktionsbereiche werden in Ab6 bildung 1.3-4 detaillierter veranschaulicht. Es handelt sich hier um die erste Ausbaustufe (sog. 3GPP Release 99). UTRAN besteht hierbei in erster Linie aus den Basisstationen, die als Node B bezeichnet werden, und aus RNCs (Radio Network Controller), an welche die Nodes B angeschlossen sind. Der Funktion nach entspricht ein RNC einem BSC von GSM. Die RNCs kommunizieren untereinander über die Schnittstelle Iur, um u.a. das Handover zwischen den benachbarten Zellen eigenständig durchzuführen. Im Gegensatz dazu wird das Handover in GSM-Mobilfunknetzen über Vermittlungsstellen MSC, also im Core Network, abgewickelt.
CS-Domain
In der ersten Ausbaustufe von UMTS wurde die existierende Vermittlungstechnik im Core Network verwendet. Somit setzt sich das Core Network von UMTS aus einem Leitungsvermittlungs- und einem Paketvermittlungsteil zusammen. Der Leitungsvermittlungsteil stellt eine CS-Domain dar, die mit der CS-Domain bei GPRS vollkommen vergleichbar ist. Die zentrale Komponente in der CS-Domain stellt ein MSC (Mobile Switching Center) dar, das der Funktion nach einer GSM-Vermittlungsstelle entspricht.
PS-Domain
Der Paketvermittlungsteil bei UMTS repräsentiert eine PS-Domain, die der Funktion nach der PS-Domain bei GPRS entspricht. Hier gibt es somit die gleichen zwei Arten von Funktionskomponenten, SGSN und GGSN. Bei UMTS
6
Eine Beschreibung der Technik von UMTS findet man u.a. in [BaTG 04].
1.3 Evolution der Mobilfunknetze
25
werden aber SGSN und GGSN über ein IP-Netz miteinander vernetzt. GGSN dient hier als Gateway zum Internet und zu anderen IP-Netzen.
U
A m
b is
G
I
C S D o m a in
V L R M S C
b
H L R
I R N C
u b is
Z e lle I
U T R A N
G M S C
P S T N / IS D N
G G S N
IP -N e tz e (In te rn e t)
A C
...
N o d e B u
A
B S C
Z e lle
U
R A N
... ...
G S M
B T S
u C S
I
u P S
u r
S G S N
IP -N e tz
P S D o m a in C o r e N e tw o r k
R N C
Abb. 1.3-4: Vereinfachte logische Architektur von UMTS Abkürzungen wie in Abb. 1.3-1, 1.3-2 und 1.3 –3
www.wiwobooks.com
UMTS-Ausbau und IMS
Die in Abbildung 1.3-4 dargestellte Architektur von UMTS wurde in der ersten UMTS nach Ausbaustufe realisiert. UMTS entwickelte man jedoch ständig weiter. Bereits 3GPP 2002 wurde ein 3GPP Release 5 von UMTS spezifiziert. Demzufolge hat die Release 5 Weiterentwicklung von UMTS vor allem zur Erweiterung der Funktionalität der PS-Domain geführt. Sie wird nach 3GPP Release 5 zu einem IP Multimedia Subsystem (IMS) auf Basis des Protokolls IP ausgebaut. Abbildung 1.3-5 zeigt die Struktur der PS-Domain bei UMTS nach 3GPP Release 5.
G I
b u C S
...
R N C U T R A N
C S D o m a in
I
u P S
C o re N e tw o r k
P S T N / IS D N
G M S C
M S C
... ...
... ...
...
A
B S C
G G S N S G S N P S D o m a in
...
R A N
...
G S M
IM S
IP N e tz C S C F
G W IP -N e tz e (In te rn e t) H S S
Abb. 1.3-5: UMTS mit IMS als Erweiterung von PS Domain im Core Network CSCF: Call State Control Function, GW: Gateway, HSS: Home Subscriber Server Abkürzungen wie in Abb. 1.3-1, 1.3-2 und 1.3-3
26
1
Vom einfachen Telefon bis zu Next Generation Networks
SIP-Einsatz
Die PS-Domain bei UMTS nach 3GPP Release 5 wird in IMS integriert. IMS sollte – nach seinem ursprünglichen Konzept – die multimediale Kommunikation über UMTS ermöglichen und eine neue Generation der multimedialen Dienste zur Verfügung stellen. Als Signalisierungsprotokoll für den Verbindungsauf- und -abbau wurde das SIP (Session Initiation Protocol) vorgesehen.
Bedeutung von IMS
Inzwischen wurde IMS von 3GPP (Third Generation Partnership Program) und von der ETSI-Arbeitsgruppe TISPAN (Telecommunication and Internet Converged Services and Protocols for Advanced Networking) weiterentwickelt und bildet heute die Basis zum Aufbau von NGNs – siehe hierzu Abschnitt 1.5. Dank IMS können in NGNs die Dienste auf Web-Technologien basieren und Web-Services hierbei eine große Rolle spielen.
1.4
VoIP und Konvergenz der Netze
Konvergenz der Netze: Netz + Netz = Netz
Netze wie das digitale Telefonnetz (PSTN), ISDN, die Mobilfunknetze GSM und UMTS und private IP-Netzwerke sind digital und dienen hauptsächlich der Übermittlung von Bitströmen. Um die vorhandenen TK- und DV-Ressourcen effektiver ausnutzen zu können, sollte man diese unterschiedlichen Netze nach der Strategie Netz + Netz = Netz integrieren. Eine derartige Integration wird als Konvergenz der Netze bezeichnet. Insbesondere ist dabei die Integration aller digitalen Netze mit dem Internet von großer Bedeutung.
Globales IP-Netz als Netz der Netze
Ein Verbund von mehreren Netzen sollte für alle Endsysteme und insbesondere für PC-basierte Arbeitsplätze an diesen Netzen transparent sein, um offene Kommunikation zwischen allen Endsystemen an verschiedenen Netzen zu ermöglichen. Die Netzinfrastruktur von morgen ist ein globales IP-Netz als Netz der Netze, das Daten und alle Echtzeitmedien – wie Audio/Sprache und Video – gleichermaßen übertragen kann, verschiedene Netze miteinander verbindet und intelligente Dienste zur Verfügung stellt.
www.wiwobooks.com
1.4.1 Von Singleservice-Netzen zum Multiservice-Netz SingleserviceNetze
Netze wie PSTN, ISDN, Mobilfunknetze wie GSM und UMTS sowie private IP-Netzwerke sind im Prinzip reine Übermittlungsnetze. Wie bereits in Abschnitt 1.1.3 gezeigt, lassen sich die TK-Netze (Telekommunikationsnetze) mit spezialisierten Servern so ergänzen, dass man den Teilnehmern intelligente Netzdienste zur Verfügung stellen kann. PSTN und ISDN werden mit Hilfe spezieller Server bereits um intelligente Funktionen erweitert, so dass ein intelligentes Netz (Intelligent Network) entsteht (s. Abb. 1.1-5). Ohne Konvergenz der Netze kann man die einzelnen TK-Netze jedoch nur als Singleservice-Netze betrachten. Abbildung 1.4-1 verdeutlicht dies.
1.4 VoIP und Konvergenz der Netze
27
S e rv e r fü r in te llig e n te N e tz d ie n s te
P S T N /IS D N
G S M
U M T S
IP -N e tz (V o IP )
N e tz s p e z ifis c h e A P Is
Abb. 1.4-1: Intelligente Netzdienste und Singleservice-Netze
Um intelligente Netzdienste entwickeln zu können, muss man auf ein internes und stark vom Netz abhängiges API (Application Programming Interface) als Software-Schnittstelle zugreifen. Demzufolge ist es nicht möglich, dass intelligente Netzdienste durch Software-Häuser und andere Nicht-Netzbetreiber entwickelt werden können. Von großer Bedeutung ist die Integration der TK-Netze mit dem Internet. Hier- Integrationsbei lassen sich die folgenden Ansätze, die auch die Entwicklungsphasen waren, arten der TK-Netze mit unterscheiden:
www.wiwobooks.com
Internet nur als Zubringer zu den Diensten in einzelnen TK-Netzen,
dem Internet
Internet als Zubringer zu den Diensten in einzelnen TK-Netzen und als Erbringer intelligenter Netzdienste. Abbildung 1.4-2 illustriert die erste Entwicklungsphase, d.h. wie das Internet Internet als als Zubringer zu intelligenten Netzdiensten in einzelnen TK-Netzen dienen Zubringer zu TK-Netzen kann.
In te rn e t n u r a ls Z u b rin g e r z u d e n N e tz d ie n s te n
In te rn e t (W e b -D ie n s t) G a te w a y s
P S T N /IS D N
G S M
U M T S
IP -N e tz (V o IP )
N e tz s p e z ifis c h e A P Is
Abb. 1.4-2: Erste Entwicklungsstufe – Internet als Zubringer zu Netzdiensten in TK-Netzen
Bei diesem Ansatz werden verschiedene Gateways zwischen dem Internet und Vielfalt von den einzelnen TK-Netzen installiert. Um PSTN/ISDN bzw. Mobilfunknetze Gateways (GSM, UMTS) als Zubringer zum Internet zu nutzen, müssen zwischen ihnen und dem Internet entsprechende Gateways installiert werden, die einige Beson-
28
1
Vom einfachen Telefon bis zu Next Generation Networks
derheiten dieser Netze berücksichtigen müssen. Um die in Abschnitt 1.4-2 dargestellten Konzepte PINT bzw. SPIRITS zu realisieren, sind wiederum andere Gateways zwischen PSTN/ISDN und Internet nötig. Ein Gateway zwischen dem Internet und einem privaten IP-Netzwerk mit VoIP-Unterstützung ist in der Regel ein Router mit einer VoIP-Gateway-Funktion. Idee vom MultiserviceNetz
Da verschiedene TK-Netze konvergieren, wäre es wünschenswert, die Möglichkeit zu haben, alle TK-Netze seitens des Internet als ein heterogenes TKNetz zu betrachten, intelligente Netzdienste auf Basis des Protokolls IP zu entwickeln und sie den Teilnehmern an allen TK-Netzen über das Internet zugänglich zu machen. Abbildung 1.4-3 illustriert diese Idee, die man als zweite Entwicklungsphase ansehen kann. Sie führt zu einem Multiservice-Netz. Wie hier ersichtlich ist, werden in diesem Fall verschiedene TK-Netze lediglich als Netzwerk-Layer betrachtet. S e rv e r fü r in te llig e n te N e tz d ie n s te
M u ltis e rv ic e L a y e r
In te rn e t (IP -N e tz )
www.wiwobooks.com
A P I
E in h e itlic h e G a te w a y -P la ttfo r m
P S T N /IS D N
G S M
U M T S
IP -N e tz (V o IP )
A P Is N e tw o rk L a y e r
Z u b r in g e r z u M u ltis e r v ic e s
Abb. 1.4-3: Zweite Entwicklungsstufe – Internet als Zubringer zu verschiedenen TK-Netzen und als Erbringer intelligenter Netzdienste
Bedeutung von GatewayPlattform
Um intelligente Netzdienste unabhängig vom TK-Netz entwickeln zu können, müssen verschiedene und netzabhängige APIs auf ein universelles API umgesetzt werden. Diese Aufgabe kann eine Gateway-Plattform übernehmen. Ihre Funktion besteht darin, den Auf- und Abbau von Verbindungen in verschiedenen TK-Netzen anzusteuern. Die Gateway-Plattform kann ein verteiltes System darstellen und auf dem Softswitch-Konzept basieren (vgl. Abb. 1.4-6). Oberhalb der Gateway-Plattform wird ein universelles API zur Verfügung gestellt, über das die Server an privaten IP-Netzen bzw. am öffentlichen Internet auf die Funktionen verschiedener TK-Netze zugreifen können. Alle Server an privaten IP-Netzen und am Internet können als Multiservice Layer betrachtet werden. Es ist hier auch hervorzuheben, dass man mehrere Server einsetzen kann, um einen intelligenten Dienst zu erbringen. Insbesondere bei E-Com-
1.4 VoIP und Konvergenz der Netze
29
merce-Anwendungen ist dies mit Sicherheit der Fall. Ein Dienst kann auch als Basis von Web Services erbracht werden [BaRS 03]. Auf die in Abbildung 1.4-3 dargestellte Art und Weise können unterschiedliche Vorteile des TK-Netze als Zubringer zu Multiservices dienen, die durch verschiedene Ser- Multiservicever an privaten IP-Netzen und am öffentlichen Internet erbracht werden. Ein Netzes derartiger Ansatz führt zur Vereinfachung der Bereitstellung intelligenter Netzdienste durch verschiedene Dienstanbieter und insbesondere durch SoftwareHäuser, die selbst keine Netzanbieter sind. Dies hat zusätzlich den Vorteil, dass die Dienstanbieter ihre Server an ihren privaten IP-Netzen bzw. am Internet betreiben können und diese nicht an bestimmte TK-Netze – wie in Abbildung 1.4-2 der Fall ist – anschließen müssen. Die Server können über ein offenes API mit dem Endgerät eines Teilnehmers an einem Netz wie ISDN, GSM oder UMTS kommunizieren, ohne die Protokolle dieser Zugangsnetze seitens des Multiservice Layer kennen zu müssen. Der in Abbildung 1.4-3 dargestellte Ansatz lässt sich mit Hilfe der Konzepte Parlay/OSA und JAIN verwirklichen, die in den Abschnitten 1.4.4 und 1.4.5 näher entsprechend erläutert werden.
www.wiwobooks.com
1.4.2 Integration von Internet mit Intelligent Network
Bei der Integration des Internet mit dem ISDN bzw. mit dem öffentlichen digitalen Telefonnetz (PSTN) kommen unterschiedliche Konzepte in Frage. Von der IETF werden hierfür die folgenden Ansätze spezifiziert: PINT (PSTN/Internet INTerworking): Konzept, nach dem das Internet als Zubringer zu den wichtigen Diensten in ISDN/PSTN dienen kann – siehe RFCs 2458 und 2848. SPIRITS (Service in the PSTN/IN Requesting InTernet Service): Konzept, nach dem bestimmte Ereignisse aus dem ISDN/PSTN in Servern am Internet bearbeitet werden können – siehe RFCs 3136, 3298 und 3910. PINT Bei dieser Art der Integration nutzt man das Internet nur als Zubringer zu den Idee von Diensten im ISDN/PSTN. Abbildung 1.4-4 illustriert, wie diese Idee im Kon- PINT zept PINT realisiert wird. Für die Integration nach PINT muss eine physikalische Kopplung zwischen Internet und ISDN/PSTN realisiert werden. Hierfür muss man ein als PINT-Gateway bezeichnetes spezielles Gateway installieren. Es enthält einen PINT-Server, auf den ein PINT-Client zugreifen kann. Der PINT-Client ist ein Software-Modul auf dem Rechner am Internet und kann ein Bestandteil eines Web-Browsers sein. Damit lassen sich einige Besonderheiten des Web-Dienstes bei PINT in Anspruch nehmen.
30
1
Vom einfachen Telefon bis zu Next Generation Networks
In te rn e t
P G W P IN T -S e rv e r
P IN T -C lie n t
S S 7 IN A P
S C P
IN b z w . G S M
P IN T IN b z w . G S M D ie n s t
A u fru f d e s D ie n s te s
A u sfü h ru n g d e s D ie n s te s
Abb. 1.4-4: Grundlegende Idee von PINT – Internet als Zubringer zu Diensten in IN und GMS INAP: Intelligent Network Application Part, PGW: PINT-Gateway, SCP: Service Control Point, SS7: Signalling System No 7
PINTProtokoll basiert auf SIP
Ein PINT-Client ermöglicht es einem Internet-Benutzer, einen Dienst aufzurufen, den ein Server am ISDN/PSTN – den man SCP nennt – erbringt. Der Aufruf des Dienstes erfolgt mit Hilfe des PINT-Protokolls. Hierbei werden bestimmte Angaben an den PINT-Server auf dem Gateway übermittelt. Das 7 PINT-Protokoll verwendet einige Nachrichten von SIP (Session Initiation Protocol, s. Kapitel 7). Vom Gateway wird der Aufruf des Dienstes weiter an SCP am ISDN/PSTN übergeben, wo der gewünschte Dienst erbracht wird. Für die Kommunikation zwischen PINT-Gateway und SCP verwendet man das Protokoll INAP (Intelligent Network Application Protocol).
www.wiwobooks.com
Internet als Zubringer zu IN-Diensten
Vergleicht man Abbildung 1.1-5 und Abbildung 1.4-4, so stellt man fest, dass PINT als eine derartige Erweiterung eines Intelligenten Netzes angesehen werden kann, sodass ein Benutzer mit einem Rechner am Internet die Ausführung einiger Dienste im Intelligenten Netz (IN) veranlassen kann.
PINTDienste
Bei PINT können u.a. folgende ISDN/PSTN-Dienste in Anspruch genommen werden: Request to Call – Es handelt sich hier um das Initiieren von Telefonverbindungen im ISDN/PSTN durch Anklicken einer Web-Seite oder einer E-Mail als Klick auf die dort angegebene Web-Adresse. Da mehrere Möglichkeiten der Realisierung derartiger Dienste in Frage kommen, spricht man auch von Click-to-Dial bzw. Click-to-Dial-Back. Request to Fax Content – Dieser PINT-Dienst ermöglicht es, einem Rechner am Internet die Fax-Nachrichten im ISDN/PSTN zu versenden bzw. sie aus einem Fax-Server am ISDN/PSTN abzurufen. Man spricht in diesem Zusammenhang auch von Click-to-Fax bzw. Click-to-Fax-Back. Der PINT-Server dient hierbei als Server für den Fax-Versand. Es ist hervorzuheben, dass es sich hierbei nicht um das Konzept „Fax over IP“ handelt. Request to Hear/Play Content – Hier handelt es sich um die PINT-Dienste, die es ermöglichen, auf einen Sprach/Audio-Server am ISDN/PSTN von einem Rechner am Internet zuzugreifen, um bestimmte Inhalte von dort über das normale Telefon bzw. über VoIP abhören zu können. Bei diesen PINT-Diensten spricht man auch von Request to Hear-Web-Content. Eine Web-Seite mit dem Text lässt sich z.B. auf die Sprache umsetzen und über das PSTN/ISDN sogar vom normalen Telefon abrufen.
7
Insbesondere die SIP-Nachrichten SUBSCRIBE, UNSUBSCRIBE und NOTIFY – s. RFC 2848.
1.4 VoIP und Konvergenz der Netze
31
SPIRITS SPIRITS ist ein Konzept für eine Art der Integration des Internet mit dem Intel- Idee von ligenten Netz (IN). Das IN kann als funktionelle Erweiterung des ISDN, des SPIRITS digitalen Telefonnetzes und der Mobilfunknetze GSM und UMTS angesehen werden (vgl. Abb. 1.1-5). Abbildung 1.4-5 illustriert die Integration des Internet mit dem IN nach SPIRITS. Das Hauptziel dieser Integration besteht darin, bestimmte Ereignisse, die mit den Telefonnummern von Teilnehmern im IN verbunden sind, an die Rechner am Internet zu übermitteln, wo sie entsprechend weiter bearbeitet und angezeigt werden können.
S -S e rv e r
In te rn e t
G W
S -C lie n t S C P
IN b z w . G S M
S P IR IT S -P ro to k o ll A n z e ig e b z w . B e a rb e itu n g d e r E re ig n is s e
Ü b e rm ittlu n g d e r E re ig n is s e in d e r S IP -N a c h ric h t N O T IF Y
E rfa ssu n g d e r E re ig n is s e
www.wiwobooks.com
Abb. 1.4-5: Konzept von SPIRITS – Anzeige und Bearbeitung der Ereignisse am Internet GW: Gateway, IN: Intelligent Network, S-Client: SPIRITS-Client, S-Server: SPIRITS-Server, SCP: Service Control Point
Um das Internet mit dem IN nach SPIRITS zu integrieren, muss eine physikalische Kopplung zwischen Internet und IN mit Hilfe eines speziellen Gateway realisiert werden. Dieses Gateway stellt die Grenze zwischen einem ISP (Internet Service Provider) und dem Betreiber des IN dar. SCP im IN repräsentiert einen Server, d.h. den Erbringer eines IN-Dienstes, SPIRITSund wird um eine Funktionskomponente namens SPIRITS-Client erweitert. Er Client und hat die Aufgabe, bestimmte mit den Telefonnummern verbundene Ereignisse -Server einem SPIRITS-Server im Internet zu übermitteln. Der SPIRITS-Server ist ein Software-Modul auf dem Rechner am Internet, um die Ereignisse aus dem IN zu bearbeiten, und lässt sich auch mit einem Web-Browser integrieren. Das SPIRITS-Protokoll basiert (ebenso wie das PINT-Protokoll) auf dem Protokoll SIP (s. Kapitel 7). Es ist somit sinnvoll, die beiden Konzepte PINT und SPIRITS entsprechend zu integrieren. Im Allgemeinen könnte man SPIRITS als Konzept interpretieren, nach dem der Zugang zu den Anwendungen am Internet seitens des IN erfolgen kann. Beim SPIRITS-Einsatz kommen u.a. folgende Anwendungen in Frage:
Typische Anwendungen von Internet Call Waiting (ICW) – ICW ermöglicht es, einen Telefonanschluss so zu nutzen, dass SPIRITS man über ihn gleichzeitig telefonieren und im Internet surfen kann. Ist der Benutzer mit dem Internet verbunden, werden die ankommenden Anrufe auf dem Bildschirm entsprechend angezeigt. Der Anruf kann dann auf eine Sprachbox umgeleitet oder über einen Rechner am In-
32
1
Vom einfachen Telefon bis zu Next Generation Networks ternet entgegengenommen werden, falls dieser beispielsweise über die VoIP-Funktion verfügt. In diesem Fall wird der Anruf auf ein IP-Telefon am Internet umgeleitet. Internet Caller-ID Delivery – Dem mit dem Internet verbundenen Rechner kann die Identifikation – z.B. die Telefonnummer – des Rufenden übermittelt werden. Ein Benutzer am Internet kann die ankommenden Anrufe von der Caller-ID abhängig „behandeln“. Internet Call Forwarding – Ist der Benutzer mit dem Internet verbunden und wird ihm ein ankommender Anruf auf dem Bildschirm signalisiert, so kann er diesen Anruf entsprechend weiterleiten (umleiten), beispielsweise auf ein IP-Telefon am Internet. SMS-Umleitung zum Rechner am Internet – Ein Mobilfunknetz GSM stellt im Prinzip ein Intelligentes Netz (IN) dar. Hat ein Benutzer sein Handy ausgeschaltet, kann er die auf seinem Handy ankommenden SMS-Nachrichten auf den Rechner am Internet umleiten. Anzeige der Lokation von Teilnehmern in Mobilfunknetzen – In den Mobilfunknetzen wie GSM und UMTS, die sich aus einer Vielzahl von Zellen zusammensetzen, lässt sich zu jeder Zeit ermitteln, in welcher Zelle sich jeder Teilnehmer mit seinem Handy aufhält, vorausgesetzt, sein Handy ist nicht ausgeschaltet. Hat ein mobiler Teilnehmer sich in eine neue Zelle hineinbewegt, kann man dies dem Rechner am Internet mit Hilfe von SPIRITS signalisieren. Auf dem Bildschirm dieses Rechners ließe sich (theoretisch!) die Bewegung jedes mobilen Teilnehmers mit einem eingeschalteten Handy verfolgen. Aus diesem SPIRITS-Einsatz ergeben sich sowohl Vorteile (z.B. Verfolgung von gestohlenen Autos) als auch Nachteile (z.B. Aspekte des Datenschutzes).
Die mit Hilfe der Lokation von mobilen Teilnehmern in Mobilfunknetzen realisierten Dienste bezeichnet man als Location Based Services (LBS).
www.wiwobooks.com
1.4.3 Gateway-Plattformen und Migration zu NGNs NGN – Konvergenz aller Netze mit dem Internet
Die Konvergenz der öffentlichen TK-Netze für die Sprachkommunikation und der Mobilfunknetze aller Generationen mit dem Internet und den privaten IPNetzen (Intranets) bietet nicht nur Möglichkeiten für VoIP, sondern hierbei ergeben sich völlig neue Netzstrukturen auf Basis des Protokolls IP mit offenen Programmierschnittstellen. Diese Idee führt zur Entstehung von sog. Next Generation Networks (NGN), in denen fast uneingeschränkte Möglichkeiten entstehen, neue intelligente Dienste zu entwickeln und sie mit Hilfe von Application Servern am Internet Teilnehmern an allen TK-Netzen zur Verfügung zu stellen. Ein NGN stellt daher keine neue Netztechnologie dar, sondern eine mit dem Internet konvergente Netzstruktur (vgl. Abb. 1.5-1). Die durch NGNs erbrachten Dienste werden auch als Next Generation Services (NGS) bezeichnet. Die Migration zu NGN wird u.a. von MultiService Forum unterstützt – siehe hierfür http://msforum.org.
Migration zu NGN
Ein NGN kann heute nicht mehr auf einer „grünen Wiese“ aufgebaut, sondern muss mit der bestehenden öffentlichen TK-Infrastruktur integriert werden. Abbildung 1.4-6 veranschaulicht eine Migration zu NGN, bei der die bestehenden öffentlichen TK-Netze mit dem Internet „stark“ integriert werden. Es ist hierbei hervorzuheben, dass die Mobilfunknetze (GSM und UMTS) bereits mit den
1.4 VoIP und Konvergenz der Netze
33
terrestrischen Sprachkommunikationsnetzen (PSTN und ISDN) über spezielle Netzübergänge (NÜ) integriert wurden. IP -N e tz e a ls B a s is fü r N G N A S
M M -E E
A S
In te rn e t & In tra n e ts (V o IP )
IP -T e l M G
G S M
&
C o n tro l F u n c tio n (S o fts w itc h ) B
M o b ilfu n k n e tz e
P S T N &
N Ü
U M T S
...
M G
...
6
G a te w a y -P la ttfo rm A
IS D N
...
T e le fo n n e tz e u n d IS D N V e rb in d u n g s s te u e ru n g (S ig n a lis ie ru n g )
Abb. 1.4-6: Migration zu Next Generation Networks – Einsatz einer Gateway-Plattform AS: Applikation Server, MG: Media Gateway, MM-EE: MultiMedia-EndEinrichtung
www.wiwobooks.com
Ein NGN muss u.a. die Möglichkeit bieten, dass:
Was man jeder Benutzer am Internet bzw. an einem privaten Intranet mit allen Benut- von NGN erwartet?
zern an anderen Netzen per VoIP telefonieren bzw. intelligente TK-Dienste nutzen kann;
jeder Benutzer am Nicht-IP-Netz (wie z.B. PSTN/ISDN oder GSM) intelligente, von den Application Servern am Internet erbrachte TK-Dienste nutzen kann. Andererseits sollte jeder Benutzer am Internet bzw. an einem Intranet den Zugang zu den Diensten im Intelligenten Netz (IN) auf Basis von PSTN/ISDN haben (vgl. Abb. 1.1-5). Eine Besonderheit der in Abbildung 1.4-6 dargestellten Integration der IP- GatewayNetze mit den anderen TK-Netzen besteht darin, dass eine verteilte und univer- Plattform selle Gateway-Plattform zum Einsatz kommt. Die Kopplung verschiedener TK-Netze mit dem Internet erfolgt hier mit Hilfe spezieller Funktionskomponenten, die man Media Gateways (MG) nennt. MGA stellt eine physikalische Komponente dar, mit deren Hilfe das PSTN/ISDN an das Internet angebunden wird. MGB kann man als Access Gateway zum Internet für Mobilfunknetze ansehen. Es ist offensichtlich, dass MGA und MGB an unterschiedlichen Stellen physikalisch untergebracht werden können. Die Gateway-Plattform kann daher 8 ein verteiltes System darstellen .
8
Eine Gateway-Plattform wird u.a. durch das IMS zur Verfügung gestellt (Abb. 1.5-1).
34
1
Vom einfachen Telefon bis zu Next Generation Networks Bemerkung: Für die Integration des Internet mit PSTN/ISDN bzw. mit den Mobilfunknetzen sind in der Praxis jeweils mehrere Media Gateways erforderlich. Abbildung 1.4-6 vermittelt somit nur die Idee der Integration.
SoftswitchFunktion
Die Ansteuerung von MGA und MGB und die Abwicklung der Signalisierung beim Auf- und Abbau von Verbindungen zwischen IP-Telefonen am Internet und Telefonen am PSTN/ISDN sowie Handys in den Mobilfunknetzen (GSM, UMTS) wird von einer Funktionskomponente übernommen, die man oft als Softswitch bezeichnet. Sie gilt als zentrale Komponente bei der Migration zum NGN und kann auch als ein verteiltes System realisiert werden. Für weitere Informationen über die Softswitch-Konzepte sei auf [Ohrt 03] verwiesen. Manchmal wird die gesamte Gateway-Plattform auch als Softswitch bezeichnet.
Struktur der GatewayPlattform
Abbildung 1.4-7 zeigt die Struktur der Gateway-Plattform bei der Integration des Internet mit dem Intelligenten Netz (IN, Intelligent Network) auf Basis von ISDN. Hier wurde angenommen, dass SIP (Session Initiation Protocol) als Signalisierungsprotokoll für VoIP im Internet eingesetzt wird (s. Kapitel 7). Wie hier ersichtlich ist, setzt sich die Gateway-Plattform aus einem Softswitch und einem Media Gateway (MG) zusammen.
www.wiwobooks.com S o fts w itc h
G a te w a y P la ttfo r m
S IP
S C
S IP
M G C
S e rv ic e s L a y e r
IS U P
S ig n a llin g L a y e r
M G C P R T P -K a n a l
S IP P ro x y
S IP
IN A P
M e d ia L a y e r
M G
A S S IP
S IG
In te r n e t
V e rm ittlu n g s s te lle
6
IP -T e l S p ra c h ü b e rm ittlu n g
S S P
IS D N -T e l
IS D N
IN A P
S C P
S S 7
IN
IS D N -V e rb in d u n g S te u e ru n g /S ig n a lis ie ru n g
Abb. 1.4-7: Softswitch-basierte Gateway-Plattform für die Integration des Internet mit IN AS: Application Server, INAP: Intelligent Network Application Protocol, ISUP: ISDN User Part, MG: Media Gateway, MGC: Media Gateway Controller, MGCP: Media Gateway Control Protocol, RTP: Real-time Transport Protocol, SC: Service Control, SIG: Signalisierung, SS7: Signalling System No. 7, SCP: Service Control Point, SSP: Service Switching Point
Aufgabe von MGC
MGC stellt eine Funktionskomponente dar, mit der der Auf- und Abbau von Verbindungen zwischen IP- und ISDN-Telefonen gesteuert wird. Vom MGC im Softswitch wird das MG mit Hilfe von MGCP so angesteuert, dass eine Verbindung zwischen IP-Telefon am Internet und ISDN-Telefon zustande kommt.
1.4 VoIP und Konvergenz der Netze
35
Diese Verbindung setzt sich aus einer ISDN-Verbindung seitens des ISDN und einem RTP-Kanal seitens des Internet zusammen (vgl. Abb. 1.2-2). Die Gateway-Plattform muss es ebenfalls jedem Benutzer am Internet ermögli- Integration chen, dass er auf die TK-Dienste im IN (z.B. Routing beim Aufbau von Tele- der Dienste fonverbindungen, vgl. Abb. 1.1-6) zugreifen kann. Andererseits sollten die mit SC durch die Application Server (AS) am Internet erbrachten TK-Dienste für die Teilnehmer am ISDN zugänglich sein. Um diese Anforderungen zu erfüllen, enthält der Softswitch die Funktionskomponente SC (Service Control). Abbildung 1.4-7 zeigt eine vereinfachte Struktur des Softswitches nur für die Integration des Internet mit dem ISDN. Um möglichst alle realen Fälle zu berücksichtigen, müssen die Gateway-Plattform und insbesondere der Softswitch weitere Funktionskomponenten enthalten. Diese können in Form eines 3Layer-Modells dargestellt werden, das enthält: Media-Layer mit verschiedenen Media Gateways, Signalling-Layer mit verschiedenen Protokollen für die Signalisierung für Auf- und Abbau von Verbindungen zwischen dem Internet und anderen Netzen,
www.wiwobooks.com
Service-Layer mit den Komponenten für die Unterstützung des Zugangs zu den Diensten (z.B. Unified Messaging, Instant Conferencing), die durch die Integration des Internet mit anderen TK-Netzen entstehen. Auf die Prinzipien der Integration des Internet mit anderen TK-Netzen geht Kapitel 8 detailliert ein.
1.4.4 Konzept von Parlay/OSA Um intelligente Netzdienste auf Basis eines TK-Netzes zu entwickeln, muss Ziel von man auf bestimmte Software-Schnittstellen, sog. APIs (Application Program- Parlay/OSA ming Interfaces), im Netzkern zugreifen. Da diese Schnittstellen nur für den Netzbetreiber zugänglich sind, war es vorher nicht möglich, dass die Netzdienste durch Dritte, also durch die Nicht-Netzbetreiber, konzipiert und entwickelt werden konnten. Um diesen Zustand zu verändern, wurde ein vom Netz unabhängiges API entwickelt. Es handelt sich hier um Parlay/OSA. Im Jahr 1998 wurde eine herstellerunabhängige „non-profit“ Organisation, die sog. Parlay Group, gegründet, um ein API zu entwickeln, mit dessen Hilfe es möglich wäre, auf die Funktionen eines Netzes zuzugreifen. Damit sollten auch die Nicht-Netzbetreiber die Möglichkeit erhalten, intelligente Netzdienste zu entwickeln, ohne direkt auf die Funktionen des Kernnetzes zugreifen zu müssen. Die wichtigste Anforderung hierbei war, dass dieses API auch vom Netz unabhängig sein musste. Dies sollte den Nicht-Netzbetreibern erlauben, die von den netzspezifischen APIs unabhängigen Netzanwendungen zu entwickeln. Damit sollte eine Möglichkeit geschaffen werden, über verschiedene Netze und über das Internet zugängliche universelle Netzanwendungen zu konzipieren.
Entstehung von Parlay/OSA
36
1
Vom einfachen Telefon bis zu Next Generation Networks
Parallel zu den Aktivitäten der Parlay Group begannen 3GPP und ETSI mit der Entwicklung eines API für die Programmierung von Netzanwendungen auf Basis von UMTS. Man stellte fest, dass das API der Parlay Group weitgehend den Anforderungen von 3GPP und ETSI entspricht. Deshalb beschloss man, die Entwicklungen miteinander zu integrieren, um das Ziel gemeinsam schneller zu erreichen. Da API von 3GPP und ETSI bereits die Bezeichnung OSA (Open Service Architecture) trug, bezeichnete man das gemeinsame API der Parlay Group und von 3GPP und ETSI als Parlay/OSA. Später wurde aus der Bezeichnung OSA Open Service Access. Parlay/OSA API wurde in der UML (Unified Modelling Language) spezifiziert. Für Näheres darüber sei auf http://www.etsi.org/WebSite/Technologies/OSA.aspx verwiesen.
Bedeutung von Parlay/OSA
Wie aus Abbildung 1.4-8 ersichtlich ist, handelt es sich bei Parlay/OSA um eine Software-Schnittstelle, über die man seitens des Internet/Intranet auf die Funktionen aller TK-Netze zugreifen kann. Andererseits können die Teilnehmer verschiedener TK-Netze die durch die Application Server am Internet/ Intranet zur Verfügung gestellten Dienste nutzen. E n tw ic k lu n g d e r N e tz d ie n s te
In tra n e t A p p liS e rv e r
P a rla y /O S A A P I
R o u te r
In te rn e t H o s te d A p p liS e rv e r
S e rv ic e N e tw o rk
www.wiwobooks.com P S T N /IS D N
S e rv ic e C a p a b ility S e rv e r G S M
U M T S
G a te w a y -P la ttfo rm
IP -N e tz (V o IP )
C o re N e tw o rk
Abb. 1.4-8: Bedeutung von Parlay/OSA – auf dem Weg zur konvergenten Netzinfrastruktur Appli-Server: Application Server
Um eine einheitliche und vom TK-Netz unabhängige Software-Schnittstelle zu spezifizieren und damit auch das Parlay/OSA-Konzept verwirklichen zu können, wurde die Funktionskomponente Service Capability Server (SCS) spezifiziert. Mit ihrer Hilfe werden die Funktionen verschiedener Netze auf Parlay/OSA API abgebildet. Diese Netze sind: PSTN und ISDN, Mobilfunknetze nach GSM und UMTS sowie IP-Netze mit VoIP-Unterstützung. SCS als Gateway
SCS fungiert als Gateway zwischen Parlay/OSA API und verschiedenen TKNetzen. Wo SCS realisiert wird, ist offen. Es kann beispielsweise in einem Netz bzw. innerhalb einer Gateway-Plattform untergebracht werden (s. Abb. 1.4-3 und Abb. 1.4-6).
Idee von Parlay/OSA
Die grundlegende Idee von Parlay/OSA besteht darin, dass man verschiedene TK-Netze mit SCS als ein Core Network (Kernnetz) betrachtet. Die Dienste dieses Core Network sind über Parlay/OSA API für die Nicht-Netzanbieter zugänglich. Somit können die Nicht-Netzanbieter die Netzanwendungen entwi-
1.4 VoIP und Konvergenz der Netze
37
ckeln und sie auf speziellen Application Servern installieren. Ein Application Server am Internet bzw. am privaten IP-Netz (Intranet) stellt bestimmte Netzanwendungen zur Verfügung, auf die man über die diversen TK-Netze (PSTN, ISDN GSM, UMTS) zugreifen kann. Solche Netzanwendungen bezeichnet man auch als New Generation Network Services (vgl. Abb. 1.4-6). Bei der Nutzung von Parlay/OSA kann jeder seine Kreativität entfalten, beliebige Netzdienste entwickeln und sie über verschiedene Netze und das Internet zugänglich machen. Die folgenden drei Beispiele, die Location Based Services (LBS) darstellen, sollen das Spektrum an Möglichkeiten verdeutlichen.
Beispiele für Network Services mit Parlay/OSA
Beispiel 1: Mobilität, Lokationsangabe und Informationsabruf – Ein Teilnehmer ist mit seinem UMTS-Handy unterwegs auf einer Autobahn. Er möchte seine Reise abbrechen und in einer nahe gelegenen Stadt übernachten. Nun greift er auf einen ihm bekannten Application Server am Internet zu, von dem er seine aktuelle Lokation abrufen kann. Die Lokation jedes mobilen Teilnehmers lässt sich im UMTS mit der Genauigkeit zu einer Zelle ermitteln. Man ist also in der Lage, herauszufinden, in welcher Zelle ein Teilnehmer sich aktuell aufhält. Der Application Server am Internet übermittelt dem UMTS-Teilnehmer einen kleinen Ausschnitt aus der Landkarte mit der Angabe seiner Position. Er klickt die nahe gelegene Stadt an, und auf seinem UMTS-Handy zeigt sich das Portal dieser Stadt mit Übernachtungsmöglichkeiten, Kulturangeboten etc. Er wählt nun das ihm passende Hotel aus, reserviert dort ein Zimmer und fährt nach der Route dorthin, die ihm vom Application Server auf seinem UMTS-Handy ständig gezeigt wird. Der UMTS-Teilnehmer hat das Hotel problemlos erreicht und kann nun die Session mit dem Applikation Server am Internet beenden.
www.wiwobooks.com
Beispiel 2: Anzeige der Position eines Autos – Ein Teilnehmer ist mit seinem Pkw unterwegs und hat sein GSM-Handy dabei. Seine Familie verfügt über einen Fernsehapparat mit einem Internet-Zugang. Der Ehegatte des Teilnehmers möchte erfahren, wo sich sein Partner gerade aufhält. Er greift auf einen ihm bekannten Application Server am Internet mit dem Service „Lokation von GSM-Teilnehmern“ zu und gibt nun die entsprechende HandyNummer an. Der Server am Internet ruft dann über Parlay/OSA vom GSM-Netz die Lokation des mobilen Teilnehmers ab, nimmt einen Ausschnitt aus der Landkarte heraus und übermittelt ihn mit der Angabe der Position des mobilen Teilnehmers an seinen Ehegatten. Er kann somit die Bewegung seines Partners auf dem Fernsehapparat verfolgen. Beispiel 3: Nutzung von Buddy-Lists (Kumpel-Listen) – Ein Teilnehmer hat in seinem GSM-Handy eine Liste mit den Handy-Nummern seiner Bekannten. Er will sich mit einigen von ihnen treffen, falls sie z.B. von ihm nicht mehr als x km entfernt sind. Er greift auf einen ihm bekannten Applikation Server am Internet mit dem Service „Buddy-Listen“ zu und übermittelt ihm seine Liste mit den Handy-Nummern. Er gibt dem Server zusätzlich an, dass er die Sprachmitteilung „Hallo hier ist ..., Ich möchte mich gerne mit ....treffen“, die nun von ihm aufgesprochen wird, an seine Bekannten aus der Liste verschicken soll, falls sie von ihm nicht mehr als x km entfernt sind. Er kann auch angeben, in welchem Zeitraum dies aktuell ist. Der Application Server am Internet überwacht die Lokation von Handy-Nummern aus der Liste und trägt dazu bei, dass der Teilnehmer sich mit seinen Bekannten treffen kann.
Die allgemeine logische Architektur von Parlay/OSA zeigt Abbildung 1.4-9. Die Hauptkomponente bei Parlay/OSA stellt der Service Capability Server (SCS) dar. Hierbei handelt es sich um eine Sammlung von Funktionen, um die Dienste verschiedener TK-Netze nutzen zu können. Diese lassen sich je nach Bedarf erweitern. SCS enthält mehrere Funktionsmodule, die man als SCF (Service Capability Feature) bezeichnet.
Logische Architektur von Parlay/ OSA
38
1
Vom einfachen Telefon bis zu Next Generation Networks
A p p lic a tio n S e rv e r
... F ra m e w o rk S S P
P S T N /IS D N
A p p lic a tio n P a rla y /O S A
...
... U s e r L o c a tio n
... C a ll C o n tro l
H L R
H L R
G S M
M S C
...
M S C
U M T S
...
A P I
S C F In te rfa c e C la s s
IP -N e tz (V o IP )
S e rv ic e C a p a b ility S e rv e r(s)
Abb. 1.4-9: Allgemeine logische Architektur von Parlay/OSA SSP: Service Switching Point, HLR: Home Location Register, MSC: Message Switching Center
Mit einem SCF wird ein spezieller netzspezifischer Dienst zur Verfügung gestellt, wie z.B.: User Location: Lokation von mobilen Teilnehmern in GSM- und UMTSNetzen Call Controll: Ansteuerung von Verbindungen, Auf- und Abbau von Verbindungen etc.
www.wiwobooks.com
Charging: übergreifende Funktion, die alle Aufgaben des Gebührenprozesses umfasst. Hierzu gehört u.a. Gebührenanzeige AoC (Advice of Charge), Abrechnung (Billing), Pre-Paid-Möglichkeit. Ein CSF wird als „Framework“ bezeichnet und muss in jedem SCS enthalten sein. Das „Framework“ kann als eine Zentrale von Parlay/OSA angesehen werden und enthält einige Management-Funktionen. Beispielsweise muss sich jeder Benutzer bei dem „Framework“ authentifizieren lassen. Parlay/OSA und WebServices
Eine neue Generation von verteilten Anwendungen auf Basis des Web-Dienstes stellen sog. Web-Services dar [BaRS 03]. Ein Web-Service kann durch eine Gruppe von verteilten, über den Web-Dienst aufrufbaren Objekten erbracht werden. Die letzte Spezifikation von Parlay – als Parlay 6.0 (März 2007) – ermöglicht es, dass die Teilnehmer an verschiedenen Netzen, wie z.B. ISDN, GSM und UMTS, auf Web-Services zugreifen können. Um Netzdienste auf Basis von Web-Services entwickeln zu können, wurde die Spezifikation Par9 lay-X veröffentlicht. Parlay-X wird auch von OMA (Open Mobile Alliance) unterstützt, die u.a. die Integration der Mobilfunknetze nach GSM mit dem Internet koordiniert. OMA hat vorher u.a. die Entwicklung von WAP (Wireless Application Protocol) koordiniert [BaRS 03]. 9
Die Spezifikationen von Parlay/OSA APIs und von Parlay X Web Services sind abrufbar unter http://portal.etsi.org/docbox/TISPAN/Open/OSA
1.4 VoIP und Konvergenz der Netze
1.4.5 Konzept von JAIN Java ist zu einer der wichtigsten Programmiersprachen geworden, die sich hervorragend für die Entwicklung von Netzanwendungen und -diensten eignet. Ein ähnliches Konzept wie bei Parlay/OSA verfolgt auch das von der Firma Sun Microsystem ins Leben gerufene JAIN (Java API for Integrated Network). Abbildung 1.4-10 illustriert das Konzept JAIN – für detaillierte Informationen darüber siehe http://java.sun.com/products/jain. E n tw ic k lu n g n e u e r T K -D ie n s te M u ltis e rv ic e L a y e r
J A IN A p p lic a tio n S e rv e r In te r n e t (IP -N e tz )
S ig n a llin g L a y e r
J A IN S o fts w itc h P la ttfo rm A P Is IS U P
IN A P
M A P
H .3 2 3
S IP
M G C P
M e g a c o
N e tw o rk L a y e r
www.wiwobooks.com
IN (P S T N /IS D N )
G S M , U M T S
IP -N e tz (V o IP )
Abb. 1.4-10: Ziel und Konzept von JAIN – Basis für die Entwicklung innovativer TK-Dienste INAP: Intelligent Network Application Part, ISUP: ISDN User Part, MAP: Mobile Application Part, MGCP: Media Gateway Control Protocol, Megaco: Media Gateway Control, SIP: Session Initiation Protocol
JAIN stellte eine Sammlung von APIs dar, die auf der Programmiersprache Idee von Java basieren. Mit JAIN-Hilfe ist es möglich, intelligente TK-Anwendungen zu JAIN entwickeln, ohne auf eine interne und netzspezifische Software-Schnittstelle zugreifen zu müssen. Um JAIN mit Parlay/OSA integrieren zu können, wurde JAIN Parlay API spezifiziert, die als Spezifikation von Parlay-API in der Version 1.2 in der Programmiersprache Java angesehen werden kann. JAIN Parlay API basiert auf den Middleware-Technologien wie CORBA (Common Object Request Broker Architecture) und DCOM (Distributed Component Object Model). Wie aus Abbildung 1.4-10 ersichtlich ist, definiert JAIN die beiden folgenden Systemkomponenten: JAIN Softswitch Plattform und JAIN Application Server. Die JAIN Softswitch Plattform stellt ein universelles Gateway dar, das verschiedene APIs seitens der einzelnen TK-Netze auf ein universelles und netzabhängiges API umsetzt. Für die Realisierung einer Softswitch-Plattform, die der Gateway-Plattform aus Abbildung 1.4-6 weitgehend entspricht, ist allerdings eine komplexe Hardware-Komponente nötig.
39
40
1
Vom einfachen Telefon bis zu Next Generation Networks
Auf das universelle API kann ein Application Server über ein IP-Netz zugreifen, um die Dienste der TK-Netze in Anspruch zu nehmen. Es handelt sich hierbei vor allem um den Auf- und Abbau von Verbindungen in verschiedenen TK-Netzen. Die wichtigste Funktion der Softswitch-Plattform besteht somit in der Abwicklung der Signalisierung (d.h. Call Control). Architektur von JAIN
Abbildung 1.4-11 zeigt eine vereinfachte Architektur von JAIN. Berücksichtigt man hierbei Abbildung 1.4-10, so stellt man fest, dass die JAIN Softswitch-Plattform die Funktionsmodule JCC und JCAT enthält; der JAIN Application Server durch die Funktionsmodule JSPA und JSLEE gebildet wird. T ru s te d th ird -p a rty a p p lic a tio n s 3
J S C E (J A IN S e r v ic e
C r e a tio n E n v in r o m e n t)
J S P A (J A IN S e r v ic e
E n tw ic k lu n g n e u e r T K -D ie n s te
U n tru s te d th ird -p a rty a p p lic a tio n s
S e c u rity In te rfa c e
P r o v id e r A c c e s s )
J S L E E (J A IN S e r v ic e L o g ic E x e c u tio n E n v in r o m e n t)
S e rv ic e L a y e r
www.wiwobooks.com 2
1
J A IN C a ll C o n tr o l IS U P
IN
J C C (J A IN C a ll C o n tr o l) a n d J C A T (J A IN C o o r d in a tio n a n d T r a n s a c tio n )
IN A P
(P S T N /IS D N )
M A P
H .3 2 3
S IP
G S M , U M T S
1 P ro to c o l/C o n n e c tio n A P Is 2
M G C P
M e g a c o
IP -N e tz (V o IP ) C a ll C o n tro l/S e s s io n A P I
S ig n a llin g L a y e r N e tw o rk L a y e r
3 S e rv ic e A P Is
Abb. 1.4-11: Allgemeine logische Struktur von JAIN IN: Intelligent Network, weitere Abkürzungen wie in Abb. 1.4-10
JCC liefert ein einheitliches API für den Zugriff auf verschiedene TK-Netze und sorgt dafür, dass die Software-Entwickler für den Auf- und Abbau von Verbindungen in verschiedenen TK-Netzen nur eine einzige Applikation schreiben müssen. JAIN APIs für den Zugriff auf verschiedene Netze Um eine JAIN Softswitch-Plattform zu realisieren, enthält die JAIN-Spezifikation mehrere APIs, über die man auf die einzelnen TK-Netze zugreifen kann. Diese APIs sind u.a.: •
JAIN ISUP (ISDN User Part) für den Zugriff auf die ISDN-Dienste (s. Kapitel 2).
•
JAIN INAP (Intelligent Network Application Part) für den Zugriff auf die Dienste vom Intelligent Network (s. Kapitel 2). JAIN MAP (Mobile Application Part) für den Zugriff auf die Dienste in Mobilfunknetzen.
•
1.5 IMS als Kern von Next Generation Networks •
JAIN H.323 für den Zugriff auf die VoIP-Systeme, die auf der Protokollfamilie H.323 basieren (s. Kapitel 6).
•
JAIN SIP (Session Initiation Protocol) für den Zugriff auf die VoIP-Systeme, die das Signalisierungsprotokoll SIP verwenden. JAIN SIP wird künftig eine wichtige Rolle spielen. In Zukunft soll die Sprachkommunikation im UMTS nach dem VoIP-Prinzip verlaufen und SIP als Signalisierungsprotokoll dienen (s. Kapitel 7).
•
JAIN MGCP (Media Gateway Control Protocol) für den Zugriff auf die Funktionen eines Media-Gateway, bei dem MGCP verwendet wird. In der Regel stellt ein solches Media Gateway ein privates VoIP-Gateway dar (s. Abschnitt 8.2).
•
JAIN Megaco (Media Gateway Control) für den Zugriff auf die Funktionen eines Media Gateway, bei dem MEGACO verwendet wird. Es handelt sich hier um ein Gateway zwischen einem öffentlichen TK-Netz (z.B. ISDN, Mobilfunknetz) und dem Internet (s. Abschnitt 8.3).
41
JAIN stellt ein Framework dar, das die Voraussetzungen für eine neue Generation von Netzdiensten schaffen soll. Die Spezifikation von JAIN APIs ist unter http://java.sun.com/products/jain/index.jsp abrufbar.
1.5
IMS als Kern von Next Generation Networks
www.wiwobooks.com
Die Konvergenz von öffentlichen TK-Netzen für Sprachkommunikation und Ziel von IMS Mobilfunknetzen mit dem Internet bietet nicht nur zusätzliche Möglichkeiten für multimediale Kommunikation, sondern es ergeben sich völlig neue Netzstrukturen und Möglichkeiten, innovative Dienste zu entwickeln. Um dies zu unterstützen, wurde IMS (IP Multimedia Subsystem) konzipiert. IMS stellt eine Plattform für IP-basierte, multimediale Anwendungen dar, die sich aus einem IP-Transportnetz und allen Festnetzen und Mobilfunknetzen zusammensetzen kann. Wie bereits in Abschnitt 1.3.3 erwähnt, wurde das Konzept von IMS ursprüng- IMSlich entwickelt, um neue IP-basierte Dienste im Mobilfunknetz UMTS einfüh- Entstehung ren und damit auch das UMTS mit dem Internet integrieren zu können (s. Abb. 1.3-5). Die erste Version vom IMS ist somit bei der Entwicklung von UMTS entstanden. Das Konzept von IMS und seine Protokolle wurden im 3GPP (Third Generation Partnership Program) und von der ETSI-Arbeitsgruppe TISPAN (Telecommunication and Internet Converged Services and Protocols for Advanced Networking) weiterentwickelt und in verschiedenen ETSIDokumenten spezifiziert. Diese sind unter http://www.etsi.org/tispan zugänglich. Mit Hilfe von IMS ist es heute möglich, neue IP-basierte – und mit her- NGNs kömmlichen TK-Netzen (PSTN/ISDN, GSM, UMTS) integrierte – Netzstruk- mit IMS turen aufzubauen, die man als Next Generation Networks (NGN) bezeichnet. Die in Abschnitt 1.4.3 dargestellten Lösungen für die Migration zu NGNs – auf
42
1
Vom einfachen Telefon bis zu Next Generation Networks
der Basis von Gateway-Plattformen (Abb. 1.4-6 und -7) – sind also nur die erste Entwicklungsstufe, die darauf folgende Entwicklungsstufe ist der IMS-Einsatz zum Aufbau von NGNs.
1.5.1 Allgemeines Konzept von IMS IMS als Integrationsplattform
IMS stellt eine Plattform für IP-basierte Multimedia-Anwendungen in der konvergenten Netzstruktur dar, die sich aus einem IP-Transportnetz und allen Festnetzen und Mobilfunknetzen zusammensetzen kann. Das IMS bildet eine zentrale Integrationsplattform für die Steuerung der TK-Dienste, die als Signalisierungs- und Steuerungsschicht zwischen einem IP-Transportnetz und den Applikationsservern betrachtet werden kann. IMS führt zur Entstehung von NGNs. Ein NGN stellt eine neue IP-basierte und mit herkömmlichen TKNetzen integrierte Netzstruktur dar. Abbildung 1.5-1 illustriert die allgemeine Struktur von NGN und die Bedeutung von IMS. Nach dem hier gezeigten Prinzip kann jeder Netzanbieter ein NGN für kommerzielle Zwecke aufbauen. IP -b a s ie r te D ie n s te w e ite r e r A n b ie te r
www.wiwobooks.com A p p lik a tio n s P la n e
S ig n a lis ie r u n g s u n d K o n tr o ll-P la n e
Z u g a n g s- u n d T r a n s p o r tP la n e
In te r n e t &
P -C S C F
A S
A S
I M
G S M U M T S
In tr a n e ts
S
S -C S C F
I-C S C F H S S
P S T N
IP -T r a n sp o r tn e tz
...
W L A N s
IS D N
...
In tra n e ts
Abb. 1.5-1: Struktur von NGNs und IMS als einheitliche Plattform für die Integration von Netzen und die Bereitstellung von IP-basierten Diensten AS: Applikationsserver, CSCF: Call Session Control Function, HSS: Home Subscriber Server, I: Interrogating-CSCF, P: Proxy-CSCF, S: Serving-CSCF
Konvergenz aller Netze mit IMS
Das wichtigste Ziel von IMS ist die Integration von Festnetzen für die Sprachkommunikation PSTN/ISDN mit allen Mobilfunknetzen – auf der Basis von Standard GSM und UMTS – und mit verschiedenen WLANs. Mit dem IMS soll die uneingeschränkte Möglichkeit geschaffen werden, alle TK-Netze mit dem Internet so zu integrieren, dass alle Server am Internet – insbesondere Webserver – über sämtliche TK-Netze zugänglich sind. Die Unterstützung multimedialer Kommunikation und der Mobilität von Benutzern steht beim
43
1.5 IMS als Kern von Next Generation Networks
IMS ebenfalls im Vordergrund. Damit wird die bereits seit langer Zeit angestrebte Konvergenz von Fest- und Mobilfunknetzen mit dem Internet Wirklichkeit. Die Konvergenz der Netze wird dadurch erreicht, dass alle Netze – d.h. Festnetze PSTN, ISDN, Mobilfunknetze GSM und UMTS, WLANs (z.B. Hotspots) und Intranets – an ein IP-Transportnetz angebunden sind. Dieses IP-Transportnetz kann auch auf der Basis des Internet eingerichtet werden. Das IMS stellt also eine Integrationsplattform zwischen dem IP-Transportnetz und den Applikationsservern dar, die am Internet angeschlossen sein können und mit deren Hilfe sich neue IP-basierte Dienste – wie z.B. VoIP, IPTV, Collaboration Services – erbringen lassen. Bemerkung: Bereits im ISDN – und damit auch im Intelligent Network (IN) – unterscheidet man eine Transport-Plane, über die B-Kanalverbindungen verlaufen, und eine Signalisierungs-Plane mit dem D-Kanal-Protokoll und dem Signalisierungssystem Nr. 7 (SS7). Vergleicht man die Abbildungen 1.1-5 und 1.5-1, stellt man fest, dass es sich in NGNs um eine ähnliche hierarchische Multi-Plane-Architektur wie im IN handelt. IMS entspricht daher dem SS7. Beim IN erfolgt der Zugriff auf intelligente Dienste nur über Netze für die Sprachkommunikation. Der Zugriff im NGN erfolgt dagegen auf Dienste über alle möglichen Netze.
NGN versus IN
www.wiwobooks.com
Wie Abbildung 1.5-1 zeigt, stellt IMS die Signalisierungs- und Kontroll-Plane Systemkomin einem NGN dar. Im IMS werden verschiedene Server, die als CSCF (Call ponenten von Session Control Function) bezeichnet werden, miteinander vernetzt. Hierbei IMS wird zwischen Proxy-CSCF (P-CSCF), Interrogating-CSCF (I-CSCF) und Serving-CSCF (S-CSCF) unterschieden. Um die Rechte und Profile von Benutzern zu speichern, wird der Server HSS (Home Subscriber Server) eingesetzt. Der Funktion nach entspricht HSS dem zentralen Register HLR (Home Location Register) in GSM und UMTS (Abb. 1.3-1 und -4). Als Signalisierungs- und Steuerungsprotokoll im IMS wird das SIP (Session Initiation Protocol) verwendet – siehe Kapitel 7. So entspricht beispielsweise Proxy-CSCF der Funktion nach dem SIP-Proxy-Server – siehe hierzu Abbil10 dung 7.1-4. Eine wichtige Rolle im IMS spielt das Protokoll Diameter , mit dem die Authentifizierung von Benutzern und das Accounting durchgeführt werden.
SIP und Diameter als Basis für IMS
1.5.2 Mobilität von Benutzern in NGNs Ein Benutzer, der mit einem tragbaren Rechner unterwegs ist, sollte die Mög- Roaming lichkeit haben, das NGN jedes Netzanbieters so zu nutzen, wie er es in seiner Firma bzw. zu Hause gewohnt ist, ohne direkt ein Entgelt für die Netznutzung 10
Das Protokoll Diameter – in RFC 3588 spezifiziert – ist der Funktion nach mit dem Protokoll RADIUS vergleichbar und kann als seine Weiterentwicklung betrachtet werden.
44
1
Vom einfachen Telefon bis zu Next Generation Networks
zahlen zu müssen. Das sog. Roaming ermöglicht die „Wanderung“ von Benutzern zwischen NGNs verschiedener Anbieter. Es handelt sich hier um die gleichen Möglichkeiten, die wir beim Telefonieren mit Handys während eines Aufenthalts im Ausland bereits als selbstverständlich annehmen. In Hinblick darauf ist zwischen den beiden folgenden Fällen zu unterscheiden: Benutzer im HeimatNGN
Ein Benutzer ist im NGN, in dem er sich gerade aufhält, dauerhaft bzw. für eine lange Zeit registriert – d.h. er ist im NGN beheimatet. In diesem Heimat-NGN verfügt er über gewisse Zugangsrechte bzw. über einen noch nicht verbrauchten Account. Nur in seinem Heimat-NGN wird der Benutzer lokal überprüft, ob der Zugang zu bestimmten Diensten – wie z.B. zum Internet – für ihn freigeschaltet werden soll.
Benutzer im FremdNGN
Ein Benutzer hält sich gerade nicht in seinem Heimat-NGN auf, sondern als „Gast“ in einem Fremd-NGN. Dort verfügt er über keine bevorzugten Zugangsrechte. Gilt jedoch eine Vereinbarung zwischen dem Anbieter des Fremd-NGN und dem Anbieter des Heimat-NGN, kann dem Gastbenutzer im Fremd-NGN der Zugang zu Netzdiensten freigeschaltet werden.
Roaming zwischen NGNs
Hält sich ein Benutzer in einem Fremd-NGN auf, wünscht er sich natürlich, das Fremd-NGN so nutzen zu dürfen, als ob er in seinem Heimat-NGN wäre. Diesen Wunsch könnte man dadurch erfüllen, dass die Anbieter beider NGNs eine Roaming-Vereinbarung unterzeichnen. Damit können die bei einem von diesen beiden Anbietern registrierten Benutzer ihre NGNs nutzen, ohne den Unterschied zu bemerken, ob sie sich gerade im Heimat- oder im Fremd-NGN befinden.
www.wiwobooks.com
Abbildung 1.5-2 illustriert die Bedeutung verschiedener IMS-Server beim Zugriff eines mobilen Benutzers auf einen Applikationsserver (AS). Hier ist das NGN des Anbieters A das Heimatnetz des Benutzers Bob und das NGN des Anbieters B das Heimatnetz des Benutzers Alice. Zugriff auf AS vom Heimat-NGN aus
Wie hier zu sehen ist, erfolgt der Zugriff auf einen Applikationsserver AS eines Benutzers, falls er sich in seinem Heimat-NGN aufhält, über den Server P (Proxy-CSCF) und den Server S (Serving-CSCF) im Heimat-NGN. Der Server S kann als zentrale Funktionskomponente in einem IMS angesehen werden, mit der u.a. die Benutzerrechte und die Ressourcen des NGN überwacht werden. Der Funktion nach entspricht der Server P dem Outbound-Proxy (AusgangsProxy) beim SIP – siehe hierfür Abbildung 7.1-4.
Zugriff auf AS vom Fremd-NGN aus
Ist ein Benutzer aber zu Gast in einem NGN, so erfolgt der Zugriff auf einen Applikationsserver AS in seinem Heimat-NGN zuerst über den Server P im Fremd-NGN, von dort über den Server I (Interrogating-CSCF) und über den Server S in seinem Heimat-NGN. Der Funktion nach entspricht der Server I dem Inbound-Proxy (Eingangs-Proxy) beim SIP.
1.5 IMS als Kern von Next Generation Networks
N G N d e s A n b ie te r s A A S
S e rv ic e P la n e C o n tro l P la n e Z u g a n g su n d T ra n sp o rt P la n e
IM S
S P
A S
IP -N e tz B o b
N G N d e s A n b ie te r s B
X
I
S B C
I
S P
Y
IM S
IP -N e tz
N N I
G a st
45
G a st
A lic e
Abb. 1.5-2: Bedeutung verschiedener IMS-Server beim Zugriff auf Netzdienste in NGNs NNI: Network-Network-Interface, SBC: Session Border Controller
Beim IMS spricht man sogar von Seamless Mobility – also von nahtloser Mobi- Nahtlose lität. Der Benutzer soll überhaupt nicht merken, über welches NGN – Heimat- Mobilität oder Fremdnetz – er telefoniert, Daten überträgt oder auf einen Applikationsserver zugreift. Hierbei soll es keine Rolle mehr spielen, mit welchem Endgerät er welche Inhalte abruft oder Dienste nutzt. Dies klingt zwar relativ einfach, doch um es zu realisieren, gibt es ein weiteres Problem zu lösen: der tragbare Rechner eines mobilen Gast-Benutzers muss fähig sein, selbstständig und vollautomatisch einen Server, der als Proxy-CSCF im Fremd-NGN dient, zu entdecken und seine IP-Adresse zu kopieren.
www.wiwobooks.com
1.5.3 Registrierung der Lokation eines Benutzers Wenn ein Benutzer in der Lage ist, sich zwischen verschiedenen NGNs zu be- Registrar wegen, kann man ihn je nach seinem aktuellen Standort mehreren Lokationen in S-CSCF zuordnen, und seine aktuelle Lokation, d.h. die Angabe, welches NGN er als 11 Zugang zu Diensten aktuell nutzt, lässt sich bei einem sog. Registrar in seinem Heimat-NGN anmelden. In diesem Zusammenhang spricht man von Registrierung. Die Registrar-Funktion wird im IMS auf dem Server S-CSCF untergebracht. Durch die Registrierung der Lokation im IMS wird u.a. das Roaming bei der Heimat-IMS Mobilität von Benutzern unterstützt. Ein Benutzer ist normalerweise in seinem Heimat-NGN angemeldet und registriert. Ein mobiler Benutzer kann aber auch über ein fremdes NGN – und somit auch Fremd-IMS über ein fremdes IMS – auf bestimmte Dienste in seinem Heimat-NGN zugreifen. In diesem Zusammenhang ist zwischen Heimat-IMS und Fremd-IMS zu unterscheiden. 11
Die Funktion eines Registrar im IMS entspricht vollkommen der Funktion eines Registrar bei SIP – siehe Abschnitt 7.6.
46
1
Vom einfachen Telefon bis zu Next Generation Networks
Abbildung 1.5-3 illustriert den Verlauf der Kommunikation zwischen einem Benutzer und dem Registrar im Heimat-IMS, falls der Benutzer ein FremdNGN benutzt. H e im a t - I M S d e s G a s t-B e n u tz e r s
F r e m d -IM S P -C S C F G a s tB e n u tz e r
1 8
2
IP -N e tz F re m d -N G N
7
3 I-C S C F
4
5
H S S
6
S -C S C F
R e g is tra r
Abb. 1.5-3: Registrierung eines Benutzers über das IP-Netz eines Fremd-NGN CSCF: Call Session Control Function, I: Interrogating, P: Proxy, S: Serving
Bedeutung von HSS
Die Datenbank HSS im IMS eines NGN enthält die Profile aller Benutzer, die in diesem NGN „beheimatet“ sind. Daher muss bei der Registrierung – also bei einer Eintragung im S-CSCF – immer u.a. die Berechtigung des Benutzers im HSS seines Heimat-IMS abgefragt werden.
Verlauf der Registrierung
Wie aus Abbildung 1.5-3 ersichtlich ist, sind bei der Kommunikation zwischen einem Benutzer, der sich aktuell in einem Fremd-NGN aufhält, und dem Registrar im S-CSCF des Heimat-IMS folgende Schritte zu unterscheiden:
Nomadische Nutzung von NGNs
www.wiwobooks.com
1.
Der Rechner eines Benutzers übermittelt eine SIP-Nachricht REGISTER an den ProxyServer P-CSCF im Fremd-IMS. Dieser stellt fest, dass es sich um einen Gast-Benutzer handelt.
2.
P-CSCF übermittelt demzufolge REGISTER an den Interrogating-Server I-CSCF im HeimatIMS des Gast-Benutzers. Der Interrogating-Server dient u.a. als Eingangs-Proxy für alle Zugriffe aus anderen NGNs (vgl. Abb. 1.5.2).
3.
I-CSCF überprüft durch die Abfrage der Benutzerdatenbank HSS – mit Hilfe des Protokolls Diameter – die Rechte des Benutzers.
4.
Ist das Ergebnis der Überprüfung positiv, wird REGISTER an den Registrar auf dem Server S-CSCF weitergeleitet.
5.
S-CSCF kann hierbei nach Bedarf – mit Hilfe von Diameter – noch die Datenbank HSS mit den Berechtigungen der Heimatbenutzer abfragen.
6.
S-CSCF übermittelt eine Antwort vom Registrar an den Interrogating-Server I-CSCF.
7.
I-CSCF leitet die Antwort an den Proxy-Server P-CSCF weiter.
8.
P-CSCF übergibt die Antwort an den Rechner des Benutzers.
An dieser Stelle ist hervorzuheben, dass es sich in Abbildung 1.5-3 um einen allgemeinen Verlauf der Kommunikation zwischen einem Benutzer, der sich als Gast in einem Fremd-NGN aufhält, und dem Registrar in seinem HeimatIMS handelt. Dass ein Benutzer seine aktuelle Lokation, d.h. sein aktuelles Aufenthaltsnetz und demzufolge seine aktuelle Adresse, beim Registrar in seinem Heimat-IMS hinterlassen kann, führt zu nomadischer Nutzung von NGNs.
1.5 IMS als Kern von Next Generation Networks
1.5.4 VoIP-Session zwischen Benutzern Welche IMS-Systemkomponenten beim Aufbau einer VoIP-Session zwischen Benutzern an verschiedenen NGNs beteiligt sind, zeigt Abbildung 1.5-4. H e im a t-IM S v o n A
A IP -N e tz
H e im a tb zw . F re m d -IM S P C S C F 1 2
A S
H e im a t-IM S v o n B
A S
H S S
3 S C S C F 4
5 IC S C F 6
7 S C S C F 8
H e im a tIM S P C S C F 9
B IP -N e tz
Abb. 1.5-4: Erste Schritte beim Aufbau einer Session zwischen verschiedenen NGNs Die ersten Schritte beim Aufbau einer Session für VoIP zwischen den Benutzern A und B, die sich in verschiedenen NGNs aufhalten, verlaufen wie folgt:
www.wiwobooks.com
1.
Das UE (User Equipment) des Benutzers A übermittelt zuerst eine SIP-Nachricht INVITE an einen Proxy-Server P-CSCF entweder im Heimat-IMS – falls der Benutzer A sein Heimat-IP-Netz nicht verlassen hat – oder im Fremd-IMS – falls er sich übergangsweise in einem Fremd-IP-Netz aufhält.
2.
P-CSCF leitet INVITE an den Server S-CSCF im Heimat-IMS weiter.
3.
Der Applikationsserver AS im Heimat-IMS des anrufenden Benutzers A wird vom S-CSCF mit Hilfe des Protokolls Diameter abgefragt. Hier werden z.B. die Benutzerrechte überprüft.
4.
S-CSCF übermittelt INVITE an den Interrogating-Server I-CSCF im Heimat-IMS des Benutzers B.
5.
Die Benutzerdatenbank HSS wird vom I-CSCF mit Hilfe von Diameter abgefragt, um u.a. den Server S-CSCF zu bestimmen.
6.
I-CSCF übermittelt INVITE an den S-CSCF .
7.
Der Applikationsserver AS wird vom S-CSCF mit Hilfe von Diameter abgefragt, um die aktuelle Lokation des Benutzers B zu bestimmen.
8.
S-CSCF leitet die SIP-Nachricht INVITE an den Proxy-Server P-CSCF weiter.
9.
P-CSCF übermittelt INVITE über ein entsprechendes Zugangsnetz an den Benutzer B.
Nach Schritt 9 hat die SIP-Nachricht INVITE das UE des Benutzers B erreicht. Der weitere Ablauf beim Verbindungsaufbau basiert auf dem Konzept von SIP – siehe Kapitel 7.
Detaillierte Informationen über IMS findet man z.B. in den Büchern [PMKN 06] und [CFPS 07].
47
48
1
Vom einfachen Telefon bis zu Next Generation Networks
1.6
VoIP-Aktivitäten bei Standardisierungsgremien, Organisationen und Foren
Die Aktivitäten, die mit der technologischen Weiterentwicklung und Standardisierung der VoIP-Dienste und -Protokolle zusammenhängen, werden von verschiedenen Standardisierungsgremien, Industrieorganisationen und Foren koordiniert. Insbesondere sind hier folgende Standardisierungsgremien hervorzuheben: IETF: Internet Engineering Task Force (http://www.ietf.org) ITU-T: International Telecommunication Union, Telecommunication Standardization Sector (http://www.itu.int/ITU-T) ETSI: European Telecommunication Standards Institute (http://www.etsi.org)
Die VoIP betreffenden Aktivitäten von Standardisierungsgremien, Industrieorganisationen und Foren werden im Weiteren kurz dargestellt.
www.wiwobooks.com
1.6.1 IETF und Internet-Standards Bedeutung von RFCs
Die IETF-Dokumente werden als sog. RFCs (Requests for Comments) im Internet veröffentlicht. Ein Schlüssel zur raschen Entwicklung des Internet und von verschiedenen IP-Netzen ist vor allem der offene Zugang zu den als RFCs im Internet veröffentlichten IETF-Dokumenten, die als Internet-Standard dienen. Jeder kann einen neuen Internet-Standard vorschlagen (s. RFC 2026).
Datenbank mit RFCs
Zu den RFCs zählen auch sämtliche Standards rund um das VoIP, die insbesondere verschiedene Konzepte und Protokolle festlegen. Die RFCs reichen bis ins Jahr 1969 zum Vorläufer des Internet zurück. Es sind z.Z. (September 2009) bereits über 5700 RFCs veröffentlicht. Alle RFCs sind auf mehreren Rechnern im Internet abgespeichert und kostenlos für alle verfügbar. Eine Datenbank mit RFCs wird vom RFC Editor verwaltet und ist unter folgender Web-Adresse zu finden: http://www.rfc-editor.org/rfcsearch.html Organisation der IETF Der Internet-Erfolg ist teilweise der gut durchdachten Organisation der Zusammenarbeit zwischen der IETF und anderen Institutionen zu verdanken. Welche Institutionen an der Entstehung von Internet-Standards beteiligt sind und wie sie zueinander stehen, zeigt Abbildung 1.6-1.
1.6 VoIP-Aktivitäten bei Standardisierungsgremien, Organisationen und Foren
R F C E d ito r
E G
A re a I
A D
W G
A D
W G
W G
IA N A
A re a S
IR S G
In te r n e tR e g is tr a tu r
W G
a n d e re S ta n d a rd is ie ru n g s g re m ie n : I T U - T , I E E E , E T S I , ...
Abb. 1.6-1: Organisation der IETF – als Schlüssel zum Internet-Erfolg AD: Area Director; IANA: Internet Assigned Numbers Authority; IESG: Internet Engineering Steering Group; IRSG: Internet Research Steering Group; IRTF: Internet Research Task Force; WG: Working Group
Da die Palette von Entwicklungen um das Internet und deren Anwendungs- Area als aspekte herum sehr breit ist, werden bei der IETF bestimmte Themenbereiche Themendefiniert. Ein Themenbereich wird als Area bezeichnet. In jeder Area wird ein bereich Area Director (AD) benannt, der die Aktivitäten innerhalb der Area koordiniert. Die Behandlung von VoIP-relevanten Themen gehört zu den Aufgaben der Real-time Applications and Infrastructure Area. Für die Entwicklung von Standards zu den einzelnen Themen in jeder Area werden mehrere Working Groups (WGs) gebildet. Eine WG übernimmt die Verantwortung für die Entwicklung von Standards, die in der Regel ein Thema (z.B. ein Protokoll, eine Applikation) betreffen. Eine Auflistung von WGs ist unter http://www.ietf.org/dyn/wg/charter.html zu finden.
www.wiwobooks.com
Für die technische Verwaltung von IETF-Aktivitäten ist die Internet Enginee- IESG ring Steering Group (IESG) verantwortlich. Zur IESG gehören die Direktoren von einzelnen Areas, die sog. ADs. Der Entwurf jedes RFC, den man als Internet-Draft bezeichnet, wird innerhalb der IESG diskutiert. Ein Internet-Draft wird nur mit der Zustimmung der IESG als Internet-Standard, also als RFC, veröffentlicht. IESG arbeitet mit dem RFC-Editor zusammen, der für die Veröffentlichung von RFCs zuständig ist (http://www.rfc-editor.org). Eine besondere Rolle unter den Internet-Gremien spielt die Internet Assigned IANA Numbers Authority (IANA). Sie dient als zentrale Stelle für die Registrierung von Internet-Adressen, -Namen, Protokollnummern und anderen Parametern, die weltweit eindeutig sein müssen. Working Groups mit VoIP-relevanten Themen Die aktiven Working Groups12 aus der Real-time Applications and Infrastructure Area, die in irgendeiner Form die Entwicklung von VoIP vorantreiben, sind:
12
Unter http://www.ietf.org/dyn/wg/charter.html werden aktive WGs aufgelistet. http://www.ietf.org/dyn/wg/charter/ gibt alle WGs an, die ihre Aktivitäten bereits
49
50
1
Vom einfachen Telefon bis zu Next Generation Networks Audio/Video Transport (avt): Dieser WG ist u.a. die Entwicklung der Protokolle RTP und RTCP zu verdanken. Sie spezifiziert z.B. auch, wie verschiedene zeitkritische Medien-Arten als Payload in RTP-Dateneinheiten „untergebracht“ werden können. Session Initiation Protocol Core (sipcore) – 2009 ins Leben gerufen, beschäftigt sich mit der Weiterentwicklung von SIP-Kernkomponenten. SIP for Instant Messaging and Presence Leveraging (simple) – konzentriert sich auf den Einsatz von SIP für die Übermittlung dringlicher Nachrichten im Internet. Hierbei wird das Internet mit ISDN/PSTN und mit Mobilfunknetzen (GSM, UMTS) integriert, um auch dringende Ereignisse aus diesen Netzen über das Internet in SIP-Nachrichten zu signalisieren; dabei kommt u.a. XML (eXtensible Markup Language) zum Einsatz. Multiparty Multimedia Session Control (mmusic) – hat u.a. die erste SIP-Version sowie die Protokolle SDP (Session Description Protocol) und RTSP (Real Time Streaming Protocol) spezifiziert. Telephone Number Mapping (enum) – Hier wurde das Konzept ENUM entwickelt, nach dem ein Benutzer mit Hilfe seiner Telefonnummer sämtliche Internet-Dienste adressieren kann. Basic Level of Interoperability for SIP Services (bliss) – seit 2008; entwickelt Standards, um die Interoperabilität zwischen VoIP-Systemen verschiedener Hersteller bei der Unterstützung von SIP-Leistungsmerkmalen zu erreichen. Centralized Conferencing (xcon) – beschäftigt sich mit der Entwicklung von Standards für die Realisierung multimedialer Konferenzen.
www.wiwobooks.com
Peer-to-Peer SIP (p2psip) – 2008 gebildet; beschäftigt sich mit der Spezifikation des Peerto-Peer SIP – d.h. einer serverlosen SIP-Variante. SessionPEERing for Multimedia INTerconnect (speermint) – entstand 2008; Entwicklung von Standards, um technische Voraussetzungen dafür zu schaffen, dass Peering – bezogen auf bilaterale Leistungsabrechnung – zwischen Anbietern von VoIP-Diensten mit SIP einheitlich realisiert werden kann. Dies ist bei der Zusammenschaltung von NGNs verschiedener Anbieter von großer Bedeutung. Emergency Context Resolution with Internet Technologies (ecrit) – 2007 gegründet, um Standards für die Realisierung verschiedener Notrufsysteme auf Internet-Basis zu spezifizieren. Hervorzuheben ist hier das Protokoll LoST (Location-to-Service Translation), um ein URN (Uniform Resource Name) – wie z.B. urn:service:sos:fire – auf den SIP-URI abbilden zu können. LoST führt zur Entstehung eines DNS-ähnlichen verteilten Datenbanksystems. Geographic Location/Privacy (geopriv) – entwickelt Standards, um die Lokation von Benutzern zu bestimmen und sie einheitlich im XML-Format zu beschreiben. Hierbei wird u.a. davon ausgegangen, dass IP-Telefone zukünftig mit einem GPS-Empfänger (Global Positioning System) ausgestattet sein werden. Dies ist von enormer Bedeutung für Internet-basierte Notruf- bzw. Katastrophenschutzsysteme. Die WG geopriv kooperiert daher mit der WG ecrit.
Die Working Groups mit den VoIP-Aktivitäten aus der Transport Area: Transport Area Working Group (tsvwg) aus der Transport Area – an der Entwicklung von STCP beteiligt. Schwerpunkt ist die Weiterentwicklung des Protokolls TCP. Diese WG hat u.a. das Protocol UDP-Lite spezifiziert. abgeschlossen haben. Von ihnen sind die WGs iptel, sip, sipping, spirits, sigtran, impp, megaco zu erwähnen.
51
1.6 VoIP-Aktivitäten bei Standardisierungsgremien, Organisationen und Foren Robust Header Compression (rohc) aus der Transport Area – beschäftigt sich mit der Komprimierung des IP/UDP/RTP-Headers in IP-Paketen mit Echtzeit-Medien. Dies ist bei VoIP von großer Bedeutung (s. Abschnitt 5.8).
1.6.2 ITU-T und Telekommunikationsstandards Die wichtigste Organisation auf dem Gebiet der Telekommunikation ist die ITU (International Telecommunication Union) mit ihrem Sitz in Genf. Die ITU ist eine zwischenstaatliche Organisation, die sich mit technischen und administrativen Problemen der Telekommunikation befasst. Die ITU wurde vorher als CCITT (Comité Consultatif International Télégraphique et Téléphonique) bezeichnet (http://www.itu.int). Die Aktivitäten der ITU sind in folgende drei Sektoren aufgegliedert: Der Sektor ITU-D (ITU Development) für die Telekommunikationsentwicklung hat die Aufgabe, die Telekommunikation auf globaler Ebene und insbesondere in den Entwicklungsländern zu fördern.
ITUSektoren
Der Sektor ITU-R (ITU Radiocommunication) ist für die Nutzung des Funkfrequenzspektrums zuständig. Im ITU-R wird die Verteilung und Zuordnung von Frequenzen weltweit koordiniert.
www.wiwobooks.com
Der Sektor ITU-T (ITU Telecommunication Standardization) ist für die technischen Aspekte der Telekommunikation sowie für Fragen der Tarifierung zuständig. Die wichtigste Aufgabe des ITU-T ist die Entwicklung und Einführung von weltweit gültigen Standards in der Telekommunikation. Organisation des ITU-T Abbildung 1.6-2 zeigt die Organisation des Standardisierungssektors ITU-T. Q u e s tio n s
...
Q a /n
S G n
W P i/n
Q
b /n
...
IT U -T
W o rk in g P a rtie s
...
U
IT U -D
S tu d y G ro u p s
...
T
IT U -R
...
I
Q x /n
S tu d y P e r io d 2 0 0 9 - 1 0 1 2 : n = 2 , 3 , 5 , 9 , 1 1 , 1 2 , 1 3 ,1 5 , 1 6 , 1 7
Abb. 1.6-2: Organisation des Standardisierungssektors ITU-T
Da das Spektrum von Problemen, die der Sektor ITU-T zu bewältigen hat, sehr Organisation breit ist, wird er auf mehrere sog. Study Groups aufgeteilt. Eine Study Group von ITU-T (SG) hat die Aufgabe, ein Teilgebiet der Telekommunikation zu betreuen. Unter http://www.itu.int/ITU-T/studygroups/index.html findet man
52
1
Vom einfachen Telefon bis zu Next Generation Networks
eine Auflistung von SGs. Jede SG setzt sich wiederum aus mehreren sog. Working Parties (WP) zusammen. Eine WP ist für die Entwicklung und Einführung von Standards auf einem engen Teilgebiet verantwortlich. Die im Bereich der Zuständigkeit einer WP zu bewältigenden Probleme werden als Questions bezeichnet. Beschreibung von Questions
Auf der Web-Seite jeder SG ist eine Beschreibung der aktuell untersuchten Probleme (d.h. von aktuellen Questions) zu finden, und diese Beschreibung kann kostenlos abgerufen werden. Auf Basis dieser allgemein zugänglichen Beschreibungen aktueller Questions kann man sich ein Bild über die aktuellen Probleme der Telekommunikation verschaffen. Davon kann jeder, der auf dem TK-Gebiet für Entwicklung verantwortlich ist, sehr profitieren.
Kostenlose ITU-TStandards
Über http://www.itu.int/ITU-T/publications/recs.html sind alle ITU-T-Standards – die sog. ITU-T Recommendations – zugänglich, die auch kostenlos – durch Anklicken einer entsprechenden Standardserie – heruntergeladen werden dürfen. VoIP betreffen insbesondere die Standards der Serie: H – zu nennen sind hier insbesondere: H.248, H.248.k (k= 0,1, ... ,70), H.235, H.235.m (n= 0,1, ... ,9), H.323, H.450.n (n=1, ..., 12) und H.460.p (p=1, ..., 22).
www.wiwobooks.com
G – In dieser Serie sind G.107, G.108, G.72n (n= 3,6,7,8,9) hervorzuheben. P – Hier sind u.a. P.880, P.910, P.911 und P.1010 zu erwähnen.
VoIP-betreffende SGs beim ITU-T Die Standards der H-Serie wie z.B. H.323, die die multimediale Kommunikation und damit auch VoIP betreffen, werden von der SG16 entwickelt. Hier werden auch die Prinzipien für die Sprachcodierung als Standards G.72x festgelegt. Die SGs und ihre WGs mit den Problemen (Questions), die mit VoIP zusammenhängen bzw. die Entwicklung von VoIP in irgendeiner Form beeinflussen, sind u.a.: SG2: Operational aspects of service provision and telecommunications management • WP1/2: Numbering, naming, addressing, routing and service provision Q 2/2: Routing and interworking plans for fixed and mobile networks • WP2/2: Telecommunication management and network and service operations Q 5/2: U.a. NGN and NGN based Services, VoIP metrics, Next Generation Mobile Networks, Convergence of telecommunication and IT environments SG11: Signalling requirements, protocols and test specifications • WP1/11:Application of IN Q 2/11: Application control and signalling requirements and protocols Q 3/11: Emergency Communications within an NGN environment • WP 3/11: Multicast and attachment Q 6/11: Coordination of signalling requirements and protocol development SG12: Performance, QoS and QoE • WG1/12: Terminals and multimedia subjective assessment Q 13/12: U.a. mobile and packet-switched (IP) networks
1.6 VoIP-Aktivitäten bei Standardisierungsgremien, Organisationen und Foren •
•
53
WG2/12: Objective models and tools for multimedia quality Q 8/12: E-Model extension towards wideband transmission and future telecommunication and application scenarios Q 14/12: Development of parametric models and tools for audiovisual and multimedia quality measurement purposes WG3/12: Multimedia QoS and QoE (Quality of Experience) Q 2/12: Multimedia performance considerations for IP gateways Q13/12: QoE, QoS and performance requirements and assessment methods for multimedia including IPTV
SG13: Future networks including mobile and NGN • WG2/13: Service requirements, scenarios and evolution aspects Q13/13: Step-by-step migration to NGN networks • WG4/13: QoS and Security Q16/13: Security and identity management • WG5/13: Future Networks Q7/13: Impact of IPv6 to an NGN Q19/13: Distributed services networking (DSN) SG16: Multimedia coding, systems and applications • WG2/16 - Applications and systems Q 2/16: H.323 real-time multimedia system Q13/16: Multimedia application platforms and end systems for IPTV Q24/16: Multimedia functions in NGN and other networks • WG3/16: Media coding Q 10/16: Speech and audio coding and related software tools
www.wiwobooks.com
1.6.3 ETSI und VoIP ETSI (European Telecommunications Standards Institute) wurde 1987 als Ziel von nichtgewinnorientierte Organisation gegründet (http://www.etsi.org). ETSI Das Ziel von ETSI ist die Verwirklichung eines einheitlichen europäischen Telekommunikationssektors durch die Schaffung und Unterhaltung von einheitlichen europäischen Standards. Mitglied bei ETSI können Verwaltungen, Netzbetreiber, Hersteller, Anwender oder Dienstanbieter werden. Beispiele für ETSI-Standards:
Wichtige GSM (Global System for Mobile Communications) als Basis für bereits ETSIStandards
existierende Mobilfunknetze;
UMTS (Universal Mobile Telecommunications System) für das universelle Mobilfunknetz der Zukunft; OSA (Open Service Access) als API für die Integration der IP-Netze mit TK-Netzen wie PSTN, ISDN, GSM und UMTS (s. Abb. 1.4-8). Im Rahmen des TIPHON (Telecommunications and Internet Protocol Harmonization over Networks) werden Spezifikationen entworfen, die alle wesentlichen Aspekte von VoIP – wie z.B. VoIP-Qualität, -Signalisierungsprotokolle –, sowie VoIP im Verbund mit PSTN/ISDN und mit Mobilfunknetzen (GSM,
54
1
Vom einfachen Telefon bis zu Next Generation Networks
UMTS) betreffen. Hierbei wird auch die Verwirklichung von ENUM (http://www.enum.org)vorangetrieben, um Telefonnummern als einheitliche Adressen für alle Internet-Dienste verwenden zu können. Die ETSIArbeitsgruppe TISPAN (Telecommunication and Internet Converged Services and Protocols for Advanced Networking) koordiniert die Entwicklung und die Spezifikation von IMS (IP Multimedia Subsystem) – s. Abschnitt 1.5.
1.6.4 Organisationen und Foren mit VoIP-Aktivitäten Oft implementieren Hersteller die Protokolle nicht exakt nach den Standards, sondern erweitern sie um herstellerspezifische Funktionen. Dies führt zur Einschränkung der Interoperabilität zwischen Systemen verschiedener Hersteller. Neben den Standardisierungsgremien wie IETF, ITU-T und ETSI existieren verschiedene Organisationen und Foren, die versuchen, verschiedene Richtlinien zu spezifizieren, um die Interoperabilität von Systemen verschiedener Hersteller zu garantieren und dadurch eine breite Einführung von VoIP voranzutreiben. Die Mitglieder der Organisationen und Foren sind hauptsächlich Hersteller, und viele von ihnen gehören auch den Standardisierungsgremien an.
www.wiwobooks.com
Rolle von 3GPP
Eine wichtige Rolle beim VoIP-Einsatz in Mobilfunknetzen hat die Organisation 3GPP (3rd Generation Partnership Project), die im Dezember 1998 gegründet wurde(http://www.3gpp.org). Es handelt sich um einen Zusammenschluss von auf dem TK-Gebiet „aktiven“ Unternehmen und Herstellern, mit dem Ziel, technische Spezifikationen für die sog. dritte Generation (3G) der Mobilfunknetze – also für UMTS – zu entwickeln. 3GPP arbeitet eng mit ITUT und ETSI zusammen. Als Ergebnis dieser Kooperation sind u.a. Spezifikationen entstanden, die das IMS betreffen. An dieser Stelle ist insbesondere die Adresse http://www.tech-invite.com zu empfehlen, wo man verschiedene Informationen über SIP, IMS und NGNs finden kann.
Ziele von IMCT
VoIP ist ein Schwerpunkt der Aufgaben des Konsortiums IMTC (International Multimedia Telecommunications Consortium), das als Industrieorganisation mit dem Ziel gebildet wurde, die Interoperabilität von Systemen für die Unterstützung multimedialer Kommunikation verschiedener Hersteller zu erreichen. Hierzu gehört u.a. auch die Interoperabilität von VoIP-Systemen – siehe hierfür http://www.imtc.org.
VoIPbetreffende Foren
Es gibt mehrere Foren, in denen verschiedene Aspekte von VoIP diskutiert und präsentiert werden. Hierzu gehören u.a.: Deutsches Forum für Internet-Telefonie http://www.ip-phone-forum.de
VoIP-Forum – http://www.voip-forum.com Voice-over-IP & Wireless LAN Forum
1.7 Schlussbemerkungen
55
http://www.expertconfig.de
VoIP-User - the voice of IP telephony – http://www.voipuser.org Wegen der Bedeutung des ITU-T-Standards H.323 und des Protokolls SIP wurden folgende Foren gegründet: H.323-Forum – http://www.h323forum.org SIP-Forum – http://www.sipforum.org Die weiteren VoIP betreffenden Foren sind u.a.: IMS/NGN-Forum – Organisation für die Förderung der Entwicklung neuer Dienste auf der Basis von IMS (http://imsforum.org). MSF (Multiservice Switching Forum) – Hier werden die Lösungen für die Konvergenz der Netze und für Multiservice-Netze präsentiert. Bei MSF können u.a. einige Empfehlungen für die Migration zu NGN abgerufen werden (http://msforum.org).
1.7
www.wiwobooks.com
Schlussbemerkungen
In diesem Kapitel wurde ein Überblick über das ganze Themenspektrum von VoIP – also der Sprachübermittlung über das Internet und über andere Datennetze mit dem Internet-Protokoll (IP) – gegeben. Abschließend sind noch folgende Aspekte hervorzuheben: Bei VoIP handelt es sich um eine Form der Datenkommunikation, die in RTP/RTCP, Echtzeit verläuft. Daher lassen sich die für die „klassische“ Datenkommuni- H.323, SIP kation konzipierten Kommunikationsprotokolle, die keine Besonderheiten der Echtzeit berücksichtigen, für VoIP nicht übernehmen. Für VoIP müssen andere Protokolle zum Einsatz kommen. Hierzu gehört das Transportprotokoll RTP/RTCP (s. Kapitel 5) und ein Signalisierungsprotokoll für den Aufund Abbau von Verbindungen zwischen IP-Telefonen. Die Signalisierung kann bei VoIP nach den Protokollen H.225.0 und H.245 aus dem ITU-TStandard H.323 (s. Kapitel 6) bzw. nach dem Protokoll SIP (s. Kapitel 7) erfolgen. Die Protokolle für VoIP, wie z.B. RTP/RTCP, SIP und der Standard H.323, können auch für die Videokommunikation über das Internet und andere IPNetze übernommen werden. Die VoIP-Prinzipien und -Protokolle stellen die Grundlage für Audio- und Videokommunikation dar, also für multimediale Kommunikation über IP-Netze. Darüber hinaus gewinnt die Integration der Sprach- und Datenkommunikation über IP ständig an Bedeutung.
VoIP und multimediale Kommunikation
56
1
Vom einfachen Telefon bis zu Next Generation Networks
QoSAnforderungen
Bei VoIP müssen die Zeitverhältnisse im Bitstrom, der eine digitalisierte Sprache bzw. ein anderes digitalisiertes Echtzeitmedium repräsentiert, an der Sende- und an der Empfangsseite identisch sein; u.a. dadurch stellt VoIP völlig neue Ansprüche an die IP-Netze. Diese Ansprüche bezeichnet man als QoS-Anforderungen (Quality of Service). Darauf wird in Kapitel 4 ausführlich eingegangen.
Entstehung von NGNs
VoIP führt dazu, dass die Netze für die Sprachkommunikation wie das digitale Telefonnetz (PSTN), ISDN und das Mobilfunknetz GSM mit dem Internet und den privaten IP-Netzen – also den Intranets – integriert werden müssen. Hinzu kommt das universelle Mobilfunknetz UMTS. Die Integration aller TK-Netze mit dem Internet führt zur Entstehung einer konvergenten Netzstruktur mit dem Protokoll IP. Eine derartig konvergente Netzstruktur mit dem Einsatz von IMS und u.a. mit der Unterstützung von QoS wird als Next Generation Network (NGN) bezeichnet (s. Abschnitt 1.5).
VoNGN
Im herkömmlichen Internet ist die Multimedia-Kommunikation wie z.B. Internet-Telefonie und Video-Kommunikation zwar möglich, aber ihre Qualität ist für anspruchsvolle Benutzer oft noch nicht zufriedenstellend. In NGNs – also in Netzen mit QoS-Garantie – wird die Multimedia-Kommunikation und insbesondere Video-Kommunikation mit Sicherheit in ganz anderer Qualität angeboten. Es wird deswegen bereits zwischen Voice over Internet und Voice over NGN (VoNGN) unterschieden.
www.wiwobooks.com
VoIPbasierte Notrufdienste
Eine wichtige Funktion der terrestrischen TK-Netze für die Sprachkommunikation – d.h. PSTN bzw. ISDN – und der Mobilfunknetze ist die Möglichkeit, einen Notruf in einer Notsituation abzusetzen. Uns allen sind die Notrufnummer 110 und 112 gut bekannt. Die öffentlichen Netze für die Sprachkommunikation bieten daher die Notrufdienste. Diese müssen auch durch die öffentlichen VoIP-Systeme angeboten werden. Die VoIP-Notrufdienste können neue Möglichkeiten zur Verfügung stellen, um Menschen in Notsituationen besser zu helfen. Verschiedene Organisationen und Standardisierungsgremien sind in dieser Hinsicht sehr aktiv. Bei der IETF wurde beispielsweise die Arbeitsgruppe ECRIT ins Leben gerufen (s. Abschnitt 1.6.1), um die Konzepte und Protokolle für die Realisierung der VoIP-Notrufdienste zu spezifizieren. Sie werden das Signalisierungsprotokoll SIP verwenden. Um eine breite Palette der Notrufdienste zu ermöglichen, wurde ein URN (Uniform Resource Name) für die Identifikation der Notrufe eingeführt – wie z.B. urn:service:sos.police. Eine besondere Aufgabe eines VoIP-Notrufsystems ist es, ein URN auf den SIP URI – d.h. auf die SIP-Adresse – der zuständigen Notrufleitstelle abzubilden. Hierfür wurde das Protokoll LoST (Location-to-Service Translation) konzipiert, das dem Konzept von DNS sehr ähnlich ist.
2
Signalisierung in Telefonnetzen und ISDN
Telefonnetze und ISDN (Integrated Services Digital Network) dienen hauptsächlich der Sprachkommunikation und funktionieren nach dem Prinzip der Leitungsvermittlung (Circuit Switching). Dies bedeutet, dass mehrere Leitungen in Vermittlungsstellen, die als Netzknoten dienen, so durchgeschaltet werden, dass quasi eine direkte Verbindung zwischen den Telefonen von zwei Teilnehmern entsteht. Man spricht hier von einer Telefonverbindung. Die Sprachsignale zwischen den Telefonen werden wie über eine Leitung übermittelt und dadurch kann die Verzögerung der Sprachsignale im Netz als konstant angesehen werden.
Telefonnetz und ISDN als Netze mit Leitungsvermittlung
Eine Telefonverbindung muss vor dem Telefongespräch aufgebaut und danach wieder abgebaut werden. Daher benötigt man ein entsprechendes weltweit festgelegtes Verfahren, nach dem dies erfolgen kann. Den Verlauf der Steuerung beim Auf- und Abbau sowie der Unterhaltung von Verbindungen bezeichnet man als Signalisierung. Diese Bezeichnung rührt daher, dass es sich um die Signalisierung (Anzeige) ankommender Anrufe handelt. Die Signalisierung muss nach einem weltweit einheitlichen Verfahren – einem Signalisierungsprotokoll – verlaufen.
Steuerung von Verbindungen als Signalisierung
www.wiwobooks.com
Um eine Basis für die Integration von VoIP-Systemen mit Netzen für die Überblick Sprachkommunikation zu geben, erläutert dieses Kapitel in einer komprimier- über das ten Form die Prinzipien und Protokolle, nach denen der Auf- und Abbau von Kapitel Verbindungen in digitalen Telefonnetzen und im ISDN verläuft. Nach der Darstellung in Abschnitt 2.1 der Signalisierung im digitalen Telefonnetz beschreibt Abschnitt 2.2 das ISDN-Konzept. Das D-Kanal-Protokoll von ISDN wird in Abschnitt 2.3 erläutert. Auf das Signalisierungssystem Nr. 7 geht Abschnitt 2.4 ein. Schlussbemerkungen in Abschnitt 2.5 runden das Kapitel ab. Das Kapitel geht u.a. auf folgende Fragestellungen ein:
Ziel dieses Nach welchem Prinzip erfolgt der Auf- und Abbau von Verbindungen in Kapitels
Netzen für die Sprachkommunikation? Nach welchem Konzept wird das ISDN aufgebaut? Wie verläuft die Signalisierung nach dem D-Kanal-Protokoll beim Auf- und Abbau einer ISDN-Verbindung? Welche Aufgabe hat das Signalisierungssystem Nr. 7 (SS7) und wie ist es konzipiert? Wie verläuft das SS7 beim Auf- und Abbau einer ISDN-Verbindung?
58
2
Signalisierung in Telefonnetzen und ISDN
2.1
Signalisierung in Telefonnetzen
Signalisierung und Media Gateway
VoIP-Systeme werden heute nicht mehr auf der „grünen Wiese“ installiert, sondern müssen mit öffentlichen Telefonnetzen und ISDN integriert werden, um die Sprachkommunikation zwischen den klassischen Telefonen und den IPTelefonen an IP-Netzen zu ermöglichen. Hierfür werden sog. Media Gateways, auch als VoIP-Gateways bzw. kurz Gateways bezeichnet, eingesetzt. Sie dienen als Brücken zwischen VoIP-Systemen und klassischen Sprachkommunikationsnetzen (Telefonnetz, ISDN). Ein Media Gateway muss so angesteuert werden, dass eine Telefonverbindung zwischen einem IP-Telefon z.B. am Internet und einem Telefon am Telefonnetz bzw. am ISDN entsteht (vgl. Abb. 1.4-7). Die Steuerung von Media Gateways zwischen dem Telefonnetz und einem IP-Netz muss das Prinzip berücksichtigen, nach dem die Steuerung beim Auf- und Abbau von Verbindungen in den Sprachkommunikationsnetzen verläuft – also die Signalisierung in diesen Netzen.
Teilnehmersignalisierung im Anschlussbereich
An eine digitale Teilnehmervermittlungsstelle werden in der Regel digitale Telefone über digitale Leitungen angeschlossen. Um alte analoge Telefone weiter nutzen zu können, wird eine Analog/Digital-Umwandlung in den Teilnehmervermittlungsstellen zur Verfügung gestellt. Die Signalisierung im Anschlussbereich, d.h. zwischen Telefonen und Teilnehmervermittlungsstellen, verläuft nach einem weltweit festgelegten Schema. Man spricht hierbei von Teilnehmersignalisierung. Im ISDN verläuft diese Signalisierung nach dem sog. DKanal-Protokoll (s. Abschnitt 2.3).
SS7 im Netzkern
In digitalen öffentlichen Telefonnetzen, die man auch PSTN (Public Switched Telephone Network) nennt, wird genau wie im ISDN das sog. Signalisierungssystem Nr. 7 (SS7, Signalling System No. 7) als Protokollsystem für die Abwicklung der Signalisierung zwischen den Vermittlungsstellen – also im Netzkern – verwendet. SS7 wird näher in Abschnitt 2.4 dargestellt.
www.wiwobooks.com
In digitalen Telefonnetzen unterscheidet man daher zwei Signalisierungsbereiche: Teilnehmersignalisierung im Anschlussbereich und Signalisierung nach dem SS7 zwischen den Vermittlungsstellen. Initiieren eines Anrufs
Abbildung 2.1-1 zeigt den Verlauf beim Auf- und Abbau einer Verbindung über ein digitales Telefonnetz. Hier initiiert Teilnehmer A den Aufbau einer Verbindung durch das Abheben des Hörers seines Telefons. Dies wird der Teilnehmervermittlungsstelle (TVSt) als Belegung der Leitung entsprechend signalisiert. Wenn die TVSt diese Belegung akzeptiert, bestätigt sie dies durch Anlegen des Wähltons. Teilnehmer A kann nun die Wahlziffern der Telefonnummer des Teilnehmers B angeben. Nach dem Erhalt der ersten Wahlziffer schaltet die TVSt den Wählton ab. Erst nach dem Erhalt der letzten Wahlziffer
2.1 Signalisierung in Telefonnetzen
59
wird der Anruf über das Netz in der SS7-Nachricht IAM (Initial Address Message) an die TVSt des Teilnehmers B übermittelt.
F V S t
T e iln e h m e r A T e l-N r = X
B e le g u n g W ä h lto n W a h lz iffe r 1
F V S t
T e iln e h m e r B
T V S t
...
T e l-N r = Y
D ig ita le s T e le fo n n e tz
...
A b g e h o b e n (O ff-h o o k )
T V S t
...
V e rb in d u n g s a u fb a u
W a h lz iffe r n
S S 7
IA M A C M
F re ito n
V e rb in d u n g s a b b a u
M e ld e n
A N S
F re ito n a b A u fg e le g t
A n ru f
K lin g e ln (R in g in g ) A b g e h o b e n
V e rb in d u n g (T e le fo n g e s p rä c h ) A u s lö s e n
R E L S S 7
A u s lö s e a n z e ig e A u s lö s e n
A u fg e le g t (O n -h o o k )
www.wiwobooks.com R L C
Abb. 2.1-1: Auf- und Abbau einer Verbindung über ein digitales Telefonnetz FVSt: FernVermittlungsStelle, TVSt: TeilnehmerVermittlungsStelle, Tel-Nr: Telefonnummer
Falls der Anschluss von Teilnehmer B frei ist, wird der ankommende Anruf seinem Telefon durch das Anlegen einer Spannung signalisiert, sodass das „Klingeln“ aktiviert wird. Gleichzeitig wird eine SS7-Nachricht ACM (Address Complete Message) aber an die TVSt des Teilnehmers A übermittelt, um den Freiton in seinem Telefon zu erzeugen.
Anzeige eines ankommenden Anrufs
Nachdem Teilnehmer B den Hörer abgehoben hat, wird dies durch das Schließen der Stromschleife seiner TVSt als Melden signalisiert. Dieses Ereignis wird der TVSt des Teilnehmers A in einer SS7-Nachricht ANS (Answer Message) mitgeteilt. Nach dem Eintreffen der Nachricht ANS schaltet die TVSt des Teilnehmers A den Freiton in seinem Telefon ab. Ab diesem Zeitpunkt steht eine Verbindung zwischen den beiden Telefonen zur Verfügung, und die laufenden Gebühren werden erfasst. Damit kann das Telefongespräch beginnen.
Annahme eines ankommenden Anrufs
Nach dem Telefongespräch muss die bestehende Verbindung abgebaut werden. Abbau einer Dies kann von jeder Seite durch Auflegen des Hörers initiiert werden. Nach- Verbindung dem Teilnehmer A den Hörer aufgelegt hat, sendet sein Telefon das Signal Auslösen an seine TVSt. Sie signalisiert dies der TVSt des Teilnehmers B mit einer SS7-Nachricht REL (Release). Damit wird gleichzeitig die Gebührener-
60
2
Signalisierung in Telefonnetzen und ISDN
fassung gestoppt. Nach dem Eintreffen der Nachricht REL bei der TVSt des Teilnehmers B wird das Signal Auslöseanzeige an das Telefon des Teilnehmers B übergeben. Nach dem Auflegen des Hörers durch Teilnehmer B wird das Signal Auslösen seinerseits an die TVSt übermittelt, und sie bestätigt der TVSt des Teilnehmers A die Nachricht REL mit einer SS7-Nachricht RLC (Release Complete). Damit wurde der Abbau der Verbindung über das Telefonnetz abgeschlossen. Für Näheres über den Aufbau der Telefonnetze sei auf [Sieg 07] verwiesen.
2.2 Was ist ISDN?
ISDN-Konzept
ISDN (Integrated Services Digital Network) kann als universelles Netz angesehen werden, in dem verschiedene TK-Dienste wie z.B. Sprach-, Daten- und Bildkommunikation realisiert werden können. ISDN ist in Folge der Digitalisierung des analogen Telefonnetzes entstanden. Wie im Telefonnetz findet auch im ISDN das Prinzip der Leitungsvermittlung (Circuit Switching) statt. Abbildung 2.2-1 illustriert das allgemeine ISDN-Konzept.
www.wiwobooks.com
E n d e -z u -E n d e -V e rb in d u n g m it 6 4 k b it/s
E n d e in r ic h tu n g e n T e le fo n F a x P C
F V S t
T V S t
T V S t
IS D N
S ig n a lis ie ru n g
E n d e in r ic h tu n T e le fo F a x P
-
g e n n C
Abb. 2.2-1: Allgemeines ISDN-Konzept – getrennte Übermittlung der Signalisierung FVSt: FernVermittlungsStelle, TVSt: TeilnehmerVermittlungsStelle
ISDNVerbindung
Im ISDN wird eine physikalische Ende-zu-Ende-Verbindung (kurz ISDNVerbindung genannt) zwischen zwei Endeinrichtungen nach Bedarf aufgebaut. Auf diese Weise entsteht quasi eine physikalische Leitung zwischen den kommunizierenden Endeinrichtungen.
Signalisierung
Während einer bestehenden ISDN-Verbindung können zusätzliche Steuerungsinformationen, in Bezug auf diese Verbindung, zwischen kommunizierenden Endeinrichtungen parallel übermittelt werden. Wie bereits erwähnt, werden diese Steuerungsinformationen als Signalisierung bezeichnet. Für Signalisierungszwecke wird keine eigene Verbindung zwischen den kommunizierenden Endeinrichtungen aufgebaut, sondern die Signalisierung wird in Form entsprechend strukturierter Nachrichten nach dem Prinzip der Paketübermittlung über das ISDN „transportiert“.
2.2 ISDN-Konzept
61
2.2.1 ISDN-Schnittstellen Um das ISDN zu nutzen, muss der Benutzer zunächst einen ISDN-Anschluss installieren lassen. Hierbei wird zwischen zwei Arten von Anschlüssen unterschieden: Basisanschluss mit der Schnittstelle S0 Primärmultiplexanschluss (PMxA) mit der Schnittstelle S2M
C
n
g e n
a ) S
D B
N T
K 0
IS D N T V S t
b ) S
T K A n l.
2 M
IS D N N T
2 M
T V S t
D
www.wiwobooks.com 1 2
B
1
B D
B -K a n a l
D -K a n a l
2
2 -s p u r ig e D a te n a u to b a h n
B
1
B
2
3 0 -s p u r ig e D a te n a u to b a h n
...
B
0
U
B 1
B 2
...
E n d e in r ic h tu n T e le fo F a x P
E n d e in r i c h . t . u. n g e n
Das Konzept der Schnittstelle S0 zeigt Abbildung 2.2-2a. Die Übertragung von Schnittstelle Sprache, Daten oder Bildern erfolgt hier über sog. B-Kanäle als Nutzkanäle. S0 Jeder Endeinrichtung können zwei B-Kanäle mit je 64 kbit/s bereitgestellt werden. Zusätzlich gehört zu jedem Basisanschluss ein Steuerkanal mit 16 kbit/s als Signalisierungskanal, der als D-Kanal bezeichnet wird.
D B -K a n a l
D -K a n a l
Abb. 2.2-2: Konzept der ISDN-Schnittstelle: a) Schnittstelle S0; b) Schnittstelle S2M NT: Netzabschluss (Network Termination), TVSt: TeilnehmerVermittlungsStelle
Die Struktur der S0-Schnittstelle lässt sich mit einer zweispurigen Autobahn vergleichen. Dabei entsprechen die Fahrspuren auf der Autobahn den B-Kanälen. Die Sicherheitsspur ist von der Funktion her mit dem D-Kanal vergleichbar. Die Übertragung zwischen dem Netzabschluss NT und dem ISDN findet über Schnittstelle die normale 2-Draht-Telefonleitung statt. Die digitale Übertragung über eine UK0 „alte“ Telefonleitung wird als Schnittstelle UK0 festgelegt. Eine (ISDN-)TK-Anlage kann den Zugang zum ISDN entweder über mehrere Schnittstelle ISDN-Basisanschlüsse oder über einen „dicken“ ISDN-Anschluss, einen sog. S2M Primärmultiplexanschluss (PMxA), haben (s. Abb. 2.2-2b). Bei einem PMxA wird die teilnehmerseitige Schnittstelle als Schnittstelle S2M bezeichnet. Hier sind ausschließlich Punkt-zu-Punkt-Verbindungen möglich, d.h. an einem solchen Anschluss kann jeweils nur eine TK-Anlage über ein entsprechendes Kopplungselement angeschlossen werden. Diese Schnittstelle besteht im Ge-
62
2
Signalisierung in Telefonnetzen und ISDN
gensatz zur Schnittstelle S0 aus 30 B-Kanälen mit je 64 kbit/s als Nutzkanäle und einem D-Kanal mit ebenfalls 64 kbit/s als Signalisierungskanal.
2.2.2 Protokollbereiche im ISDN Vor der eigentlichen Kommunikation über das ISDN muss eine Verbindung zwischen zwei Endeinrichtungen aufgebaut und nach dem Ablauf der Kommunikation wieder abgebaut werden. Somit ist es erforderlich, die nacheinander zu durchlaufenden ISDN-Vermittlungsstellen mit Steuerinformationen so zu versorgen, dass die gewünschte Verbindung hergestellt wird. Dies ist Aufgabe der ISDN-Signalisierung. Wie Abbildung 2.2-3 zeigt, wird die Signalisierung im ISDN ebenso wie im Telefonnetz in zwei Bereiche aufgeteilt: Teilnehmersignalisierung zwischen Endeinrichtungen und Vermittlungsstellen nach dem D-Kanal-Protokoll; Signalisierung zwischen den ISDN-Vermittlungsstellen nach dem Signalisierungssystem Nr. 7 (SS7).
www.wiwobooks.com E n d e in ric h tu n g
T V S t
D K a n a l D -K a n a lP ro to k o ll
IS D N
F V S t
E n d e in ric h tu n g
T V S t
IS D N -V e rb in d u n g Z K S ig n a lis ie ru n g s s y s te m N r. 7 B e n u tz e r-B e n u tz e r-S ig n a lis ie ru n g B e n u tz e r-B e n u tz e r-In fo rm a tio n
D K a D -K P ro
n a l a n a lto k o ll
Abb. 2.2-3: Protokollbereiche im ISDN – Netzzugangs- und Netzkernbereich F/TVSt: Fern/TeilnehmerVermittlungsStelle, ZK: Zentral(Signalisierungs-)Kanal
D-KanalProtokoll als DSS1
Die zentrale Aufgabe der Teilnehmersignalisierung ist die Steuerung des Aufund Abbaus von Verbindungen zwischen den Endeinrichtungen und Teilnehmervermittlungsstellen. Diese Signalisierung wird über die D-Kanäle abgewickelt und ist für alle Dienste und alle ISDN-Anschlussarten einheitlich spezifiziert. Die Regeln, nach denen die Teilnehmersignalisierung verläuft, beschreibt das D-Kanal-Protokoll, das in den ITU-T-Dokumenten als DSS1 (Digital Subscriber Signalling System No. 1) bezeichnet wird. Durch die getrennte Übermittlung der Signalisierung im D-Kanal können bestimmte ISDN-Dienstmerkmale (z.B. Dienstwechsel) während einer bestehenden Verbindung in Anspruch genommen werden.
2.3 D-Kanal-Protokoll
2.3
D-Kanal-Protokoll
Das D-Kanal-Protokoll wird entsprechend dem OSI-Referenzmodell strukturiert und durch ITU-T-Standards festgelegt. Abbildung 2.3-1 zeigt das Schichtenmodell des D-Kanal-Protokolls an der ISDN-Schnittstelle S0 . B B 7 4
D
5
E n d e in ric h tu n g 6
3 Q .9 3 0 Q .9 3 1 2 Q .9 2 0 Q .9 2 1 1 I .4 3 0 I .4 3 1 I .4 3 0 I .4 3 1 D
B
I .4 3 0 I .4 3 1 B
IS D N S 0
Abb. 2.3-1: D-Kanal-Protokoll im Schichtenmodell
www.wiwobooks.com
Die Übermittlung der Steuerung über den D-Kanal findet in den unteren drei Schichten statt, die folgende Funktionen beinhalten: Schicht 1: Bitübertragungsschicht Innerhalb dieser Schicht findet die Bitübertragung sowohl in den B-Kanälen als auch im D-Kanal statt. Diese Schicht beschreiben die ITU-T- Standards I.430 und I.431. Schicht 2: Sicherungsschicht Diese Schicht ist für die gesicherte Übermittlung der Signalisierung und der eventuell im D-Kanal übertragenen paketierten Daten zuständig. Das Proto1 koll für diese Schicht legen die ITU-T-Standards Q.920 und Q.921 fest. Die Sicherung der Übermittlung im D-Kanal erfolgt nach der Prozedur LAPD (Link Access Procedure on D-Channel), die eine HDLC-Variante darstellt. Schicht 3: Vermittlungsschicht Innerhalb dieser Schicht wird die eigentliche Teilnehmersignalisierung durch den Austausch von im ITU-T-Standard Q.931 festgelegten Nachrichten des D-Kanal-Protokolls realisiert. Dazu gehören die Funktionen zum Auf- und Abbau von ISDN-Verbindungen und zur Realisierung von ISDN-
1
Unter http://www.itu.int/rec/T-REC-Q.920/en und http://www.itu.int/rec/ T-REC-Q.921/en können Q.920 und Q.921 kostenlos heruntergeladen werden.
63
64
2
Signalisierung in Telefonnetzen und ISDN
Dienstmerkmalen. Die allgemeinen Aspekte des D-Kanal-Protokolls innerhalb der Schicht 3 beschreibt der ITU-T-Standard Q.930. Wie aus Abbildung 2.3-1 ersichtlich ist, wird die Steuerung im B-Kanal nur innerhalb der Schicht 1 bereitgestellt. Für den B-Kanal ist somit nur das Schicht1-Protokoll spezifiziert. Die Protokolle innerhalb der höheren Schichten in BKanälen sind von der Nutzung (Daten-, Sprachübermittlung etc.) dieser Kanäle abhängig und können von vornherein nicht festgelegt werden.
2.3.1 Schicht 3 des D-Kanal-Protokolls Die Schicht 3 des D-Kanal-Protokolls enthält sämtliche Funktionen, die für den Aufbau von ISDN-Verbindungen und die Bereitstellung der ISDN-Dienste erforderlich sind. Zu diesen Funktionen gehören u.a.: Kodierung der Nachrichten entsprechend den technischen Anforderungen, Behandlung des Nachrichtenaustausches nach festgelegten Prozeduren, Realisierung von ISDN-Dienstmerkmalen, wie z.B. Anklopfen (Call Waiting), Anrufweiterschaltung bei Besetzt (Call Forwarding on Busy), Gerätewechsel (Terminal Portability) etc.
www.wiwobooks.com
Den Aufbau von Schicht-3-Nachrichten des D-Kanal-Protokolls zeigt Abbildung 2.3-2. Jede Nachricht enthält einen Nachrichten-Header und zusätzliche Informationselemente. Der Nachrichtenkopf besteht aus dem Protokolldiskriminator, der Angabe Call Reference (CR) und dem Nachrichtentyp (Message Type). Die Länge der Schicht-3-Nachricht ist auf 260 Oktette begrenzt. Der Nachrichtentyp bezeichnet die verwendete Schicht-3-Nachricht (z.B. SETUP, ALERT usw.). Jede Nachricht kann bestimmte Informationselemente (Information Elements) als ihre Parameter enthalten. B its : 8
7 6 1 O k te tt: 5 4 3 2 P ro to k o lld is k rim in a to r 1 0 0 0 0 C R -L ä n g e 2 C a ll R e fe re n c e (C R ) N a c h ric h te n ty p In fo rm a tio n s e le m e n t 1
...
Aufbau von Schicht-3Nachrichten
In fo rm a tio n s e le m e n t n
Abb.2.3-2:
3 , ..., k + 3
N a c h ric h te n H e a d e r
k + 4
k = 0 o d e r 1
In fo rm a tio n s e le m e n te
Struktur von Schicht-3-Nachrichten des D-Kanal-Protokolls
65
2.3 D-Kanal-Protokoll
Der Protokolldiskriminator ermöglicht die Unterscheidung verschiedener Ver- Protokolldiskriminasionen des D-Kanal-Protokolls, z.B.: 2
00001000: internationales D-Kanal-Protokoll nach Q.931 ,
tor
01000001: ehemaliges nationales D-Kanal-Protokoll in Deutschland nach den Richtlinien 1TR6. Innerhalb einer Endeinrichtung (z.B. im PC) können gleichzeitig mehrere Sig- Call nalisierungsvorgänge über einen D-Kanal verlaufen. Deshalb muss bei jedem Reference Signalisierungsvorgang darauf verwiesen werden, auf welchen B-Kanal er sich bezieht. Hierfür werden den einzelnen Signalisierungsvorgängen an beiden Seiten des D-Kanals voneinander unabhängige Call References (CR) zugeordnet. Jede Signalisierungsnachricht muss den CR-Wert enthalten, der ein oder zwei Oktette lang sein kann. Die Informationselemente (IEs) sind als Parameter von Schicht-3-Nachrichten Informazu interpretieren. Sie werden unabhängig vom Nachrichtentyp aufgebaut und tionskönnen in einer Nachricht in beliebiger Reihenfolge zusammengesetzt werden. elemente Damit wird die Bedeutung der Nachricht näher spezifiziert. In einigen Nachrichten sind bestimmte IEs vorgeschrieben (d.h. sie sind obligatorisch).
www.wiwobooks.com
Beim Aufbau von ISDN-Verbindungen werden folgende Schicht-3-Nach- Verbindungsaufbau richten verwendet (s. Abb. 2.3-3): SETUP – wird von einer Endeinrichtung verwendet, um einer Vermitt-
lungsstelle das Initiieren einer Verbindung zu signalisieren. SETUP ACK (SETUP ACKnowledge)– dient als Quittung auf SETUP und
ist optional. Diese Nachricht wird von einer Vermittlungsstelle dann gesendet, falls sie die weiteren Informationen (z.B. weitere Ziffer der Rufnummer) zum Aufbau der Verbindung benötigt. CALL PROC (CALL PROCeeding) – wird von einer Vermittlungsstelle verwendet, um einer Endeinrichtung zu signalisieren, dass der ankommende Anruf bearbeitet wird. Diese Nachricht dient somit als Quittung auf SETUP und wird von einer Vermittlungsstelle gesendet, wenn sie keine weiteren Informationen mehr zum Aufbau der Verbindung benötigt. PROGRESS – wird von einer Vermittlungsstelle verwendet, um einer End-
einrichtung zu signalisieren, dass weitere Signale oder Hinweise im BKanal gegeben werden, wie z.B. Hörtöne oder Ansagen. ALERT (ALERTing)– wird von jeder Ziel-Endeinrichtung verwendet, um einer Quell-Endeinrichtung zu signalisieren, dass alle Kompatibilitäts- und Berechtigungsprüfungen am Ziel zu positiven Aussagen geführt haben. Dies bedeutet, dass der ankommende Anruf entgegengenommen werden kann. 2
Unter http://www.itu.int/rec/T-REC-Q.931/en ist Q.931 kostenlos zugänglich.
66
2
Signalisierung in Telefonnetzen und ISDN
CONN (CONNect) – wird von jeder Ziel-Endeinrichtung verwendet, um einer Quell-Endeinrichtung zu signalisieren, dass der ankommende Anruf entgegengenommen worden ist. CONN ACK (CONNect ACKnowledge) – dient als Quittung auf CONN. Verbindungs- Beim Abbau von ISDN-Verbindungen werden folgende Schicht-3-Nachrichten abbau verwendet (s. Abb. 2.3-3): DISC (DISConnect) – wird von einer Endeinrichtung verwendet, um
den Abbau einer Verbindung zu initiieren. REL (RELease) – dient als Bestätigung der Nachricht DISC. REL COM (RELease COMplete) – dient als Bestätigung von REL. Dienstmerkmale
Für die Realisierung von ISDN-Dienstmerkmalen, wie z.B. Rufumleitung und Rückruf bei Besetzt, mit deren Hilfe die ISDN-Basisdienste sich komfortabler gestalten lassen, werden weitere Schicht-3-Nachrichten verwendet. Die Prinzipien, nach denen der Aufruf und die Steuerung von Dienstmerkmalen erfol3 gen, werden im ITU-T-Standard Q.932 festgelegt.
2.3.2 Auf- und Abbau einer ISDN-Verbindung
www.wiwobooks.com
Das D-Kanal-Protokoll beschreibt die Signalisierung zwischen Endeinrichtungen und Teilnehmervermittlungsstellen (TVSt), also die Teilnehmersignalisierung. Wie im öffentlichen digitalen Telefonnetz (PSTN) wird hier auch das Signalisierungssystem Nr. 7 (SS7) zwischen ISDN-Vermittlungsstellen verwendet. Abbildung 2.3-3 zeigt den Verlauf des D-Kanal-Protokolls beim Aufund Abbau einer ISDN-Verbindung zwischen zwei Telefonen. Tln A initiiert Den Aufbau einer Verbindung initiiert hier das Telefon bei Teilnehmer A. eine Verbin- Nach dem Abheben des Hörers wird eine Nachricht SETUP mit dem Informadung tionselement Bearer Capability, das den vom ISDN geforderten Übermitt-
lungsdienst (d.h. Leitungsvermittlung) spezifiziert, an die TVSt X übermittelt. Das Empfangen von SETUP in der TVSt X wird dem Telefon von Teilnehmer A mit SETUP ACK bestätigt und bei ihm der Wählton erzeugt. Tln A gibt die Zielrufnummer an
Die Zielrufnummer wird in mehreren Nachrichten INFO(INFOrmation)an die TVSt X übermittelt, sodass man auch von overlap sending spricht. Wurde die Zielrufnummer vollständig von der TVSt X empfangen, bestätigt sie dies dem Telefon des Teilnehmers A mit CALL PROC. Gleichzeitig wird der von Teilnehmer A abgehende Anruf mit einer SS7-Nachricht IAM (Initial Address Message) der Vermittlungsstelle von Teilnehmer B (d.h. der TVSt Y) angezeigt
3
Unter http://www.itu.int/rec/T-REC-Q.932/en kann Q.932 heruntergeladen werden.
2.3 D-Kanal-Protokoll
67
(s. Abb. 2.4-7). Falls das Telefon von Teilnehmer B nicht besetzt ist, wird an ihn der ankommende Anruf mit SETUP über den D-Kanal weitergeleitet. T e iln e h m e r A
W ä h lto n V e rb in d u n g s a u fb a u F re ito n A u fg e le g t
O
U P E T U P A C K
...
A b g e h o b e n
T V S t X S E T S IN F IN F C
O A L L P R O C
A L E R T C O N N C O N N A C K D IS C
V e rb in d u n g s a b b a u
Abb.2.3-3:
R E L C O M
T V S t Y 6
T e iln e h m e r B
IS D N S ig n a lis ie ru n g s s y s te m N r. 7 (S S 7 ) IA M A C M A N S
S E T U P A L E R T C O N N C O N N A C K
E s k lin g e lt A b g e h o b e n
IS D N -V e rb in d u n g
R E L
S S 7 R E L R L C
D IS C R E L C O M
R E L
A u fg e le g t
Auf- und Abbau einer ISDN-Verbindung zwischen zwei Telefonen
www.wiwobooks.com
TVSt: Teilnehmervermittlungsstelle
Nach dem Eintreffen von SETUP beim Telefon von Teilnehmer B überprüft Es klingelt dieses, ob der ankommende Anruf entgegengenommen werden kann. Falls die bei Tln B Prüfung zur positiven Aussage führt, wird dies durch Klingeln dem Teilnehmer B signalisiert und der TVSt Y mit der Nachricht ALERT des D-Kanal-Protokolls angezeigt. Nach dem Empfangen von ALERT übermittelt die TVSt Y eine SS7-Nachricht ACM (Address Complete Message) an die TVSt X. Nach dem Eintreffen von ACM bei der TVSt X wird die Nachricht ALERT an das Telefon von Teilnehmer A gesendet, um bei ihm den Freiton zu erzeugen. Hat Teilnehmer B den Hörer abgehoben, wird dies der TVSt Y mit der Nach- Tln B hat richt CONN signalisiert. Sie bestätigt den Empfang von CONN mit CONN ACK abgehoben und sendet eine SS7-Nachricht ANS (Answer Message) an die TVSt X. Nachdem ANS bei ihr eingetroffen ist, sendet die TVSt X die Nachricht CONN des D-Kanal-Protokolls an das Telefon des Teilnehmers A, um bei ihm den Freiton zu beenden. Der Empfang der Nachricht CONN wird mit CONN ACK bestätigt. Ab diesem Zeitpunkt steht eine ISDN-Verbindung zur Verfügung, die laufenden Gebühren werden erfasst, und das Telefongespräch kann beginnen. Der Abbau einer ISDN-Verbindung kann von jedem Telefon durch Auflegen des Abbau einer Hörers veranlasst werden. Damit wird der B-Kanal freigegeben und die Gebüh- ISDNrenerfassung beendet. In Abbildung 2.3-3 wird der Abbau der ISDN-Verbindung Verbindung durch Auflegen des Hörers bei Teilnehmer A initiiert. Dies wird der TVSt X mit der Nachricht DISC (DISConnect) des D-Kanal-Protokolls signalisiert. Die TVSt
68
2
Signalisierung in Telefonnetzen und ISDN
X bestätigt den Empfang von DISC mit REL (RELease). Den Abbau der ISDNVerbindung signalisiert die TVSt X der TVSt Y mit einer SS7-Nachricht REL. Nach dem Eintreffen von REL bei der TVSt Y wird der Verbindungsabbau dem Telefon von Teilnehmer B mit DISC angezeigt. Das Auflegen des Hörers bei Teilnehmer B wird der TVSt Y mit der Nachricht REL des D-Kanal-Protokolls signalisiert. Die TVSt Y signalisiert dies der TVSt X weiter durch Absenden einer SS7-Nachricht RLC (Release Complete). Da sichergestellt werden muss, dass der belegte B-Kanal seitens jedes Telefons und seitens jeder TVSt freigegeben ist, wird der Empfang der Nachricht REL noch mit der Nachricht REL COM (RELease COMplete) bestätigt. Wie bereits erwähnt, ist das ISDN auf Basis des digitalen Telefonnetzes entstanden. Daher stimmt der in Abbildung 2.3-3 gezeigte Verlauf des Auf- und Abbaus einer ISDN-Verbindung mit dem in Abbildung 2.1-1 gezeigten Verlauf des Auf- und Abbaus einer Verbindung über das digitale Telefonnetz überein. Für weitere Informationen über das D-Kanal-Protokoll ist auf die Webquellen [Web 01] zu verweisen.
2.4
www.wiwobooks.com
Signalisierungssystem Nr.7
Wo findet man das Signalisierungssystem Nr.7?
Das Signalisierungssystem Nr.7 (Signalling System No. 7) – kurz SS7 – stellt ein Protokollsystem dar, nach dem die Signalisierung im Kern der digitalen öffentlichen Telefonnetze, des ISDN und der GSM-Mobilfunknetze übermittelt wird. SS7 wurde hauptsächlich in der Zeit von 1973 bis 1980 konzipiert, um die Signalisierung in digitalen Telefonnetzen zu übermitteln. Nach 1980 kamen weitere Anforderungen durch das ISDN hinzu. Insbesondere führten später die GSM-Mobilfunknetze und Intelligenten Netze zu den Erweiterungen von SS7. 4 SS7 wird in den ITU-T-Empfehlungen der Q.7xx-Serie spezifiziert.
Signalisierungskanäle und SS7
In den TK-Netzen für die Sprachkommunikation wie digitale Telefonnetze und ISDN wird die Signalisierung zwischen den Vermittlungsstellen (VSt), die als Knoten in diesen Netzen fungieren, über spezielle Kanäle, sog. Signalisierungskanäle, übermittelt. Die Signalisierungskanäle verlaufen parallel zu den Nutzkanälen, über die die Sprache in digitaler Form übertragen wird. Abbildung 2.4-1 illustriert dies. Insbesondere sollte hier zum Ausdruck gebracht werden, dass der Auf- und Abbau von Verbindungen, d.h. die Kopplung der Nutzkanäle im Koppelfeld, mit dem SS7 angesteuert wird.
4
Unter http://www.itu.int/rec/T-REC-Q/en können die Empfehlungen Q.7xx kostenlos heruntergeladen werden.
2.4 Signalisierungssystem Nr.7
... 6
... S IG E in ric h tu n g
S IG E in ric h tu n g
...
S S 7
V S t B
V S t A 6
...
V S t C
6
S te u e ru n g
V S t A
K o p p e lfe ld
69
S ig n a lis ie ru n g s k a n ä le N u tz k a n ä le
S te u e ru n g
V S t B
K o p p e lfe ld
...
...
Abb. 2.4-1: Signalisierungskanäle und Veranschaulichung der Aufgabe von SS7 SIG: Signalisierung, VSt: Vermittlungsstelle
Logisch gesehen bilden die Signalisierungskanäle ein eigenständiges, völlig von den Nutzkanälen getrenntes Signalisierungsnetz. Die Strukturen von Nutzkanalnetz und Signalisierungsnetz können prinzipiell voneinander unabhängig und damit auch unterschiedlich sein. Zur Verdeutlichung dessen zeigt Abbildung 2.4-2 ein einfaches Netz. Hierbei wird ersichtlich, dass dem Nutzkanalnetz ein Signalisierungsnetz als Signalisierungsebene übergeordnet wird.
www.wiwobooks.com S ig n a lis ie r u n g s n e tz (S S 7 -N e tz ) S T P
S P
W a rtu n g s Z e n tru m
S P
V S t B 6
V S t A
V S t C
N u tz k a n a ln e tz
Abb. 2.4-2: Nutzkanalnetz und Signalisierungsnetz – logische Multi-Plane-Architektur SP: Signalling Point (Signalisierungspunkt), STP: Signalling Transfer Point (Signalisierungstransferpunkt), VSt: Vermittlungsstelle
Die Knoten im Signalisierungsnetz nennt man Signalisierungspunkte. Die Vermaschung der Signalisierungspunkte im Signalisierungsnetz ist oft wesentlich geringer als die Vermaschung von Vermittlungsstellen im Nutzkanalnetz, da ein Signalisierungskanal mit 64 kbit/s im SS7-Netz in der Regel Hunderte von Nutzkanälen ansteuern kann. Zu den wichtigsten Funktionen des Signalisierungsnetzes gehören:
Signalisierungsnetz bzw. SS7Netz
2
Signalisierung in Telefonnetzen und ISDN
Link-by-Link-Signalisierung: Abschnittsweise Übertragung der Steuerung zwischen den Vermittlungsstellen. Ende-zu-Ende-Signalisierung: Übertragung der Steuerung zwischen Quellund Zielvermittlungsstelle für die Realisierung verschiedener Dienstmerkmale. Transaktionsfähigkeit (Transaction Capabilities): Austausch von Informationen zwischen beliebigen Knoten im Signalisierungsnetz für die Realisierung intelligenter TK-Dienste. Dies ist die Basis für sog. Intelligente Netze. Überwachung und Steuerung des Signalisierungsnetzes: Fehlerlokalisierung, Ersatzschaltung von defekten Signalisierungskanälen usw.
2.4.1 Funktionsteile von SS7 SS7 ist ein sehr komplexes Signalisierungssystem und enthält mehrere Funktionsteile, die jeweils als Part bezeichnet werden. Abbildung 2.4-3 zeigt diese Parts, die Zusammenhänge zwischen ihnen sowie deren Zuordnung zu den Schichten des bekannten OSI-Schichtenmodells.
www.wiwobooks.com
N e tw o rk
U P s
...
... IS U P
D U P
A S E s O S I-S c h ic h te n A p p lic a tio n O M A P M A P IN A P P re s e n ta tio n S e s s io n T C A P T ra n sp o rt
T U P
70
S C C P M T P
S c h ic h t 3
D a ta L in k
M T P
S c h ic h t 2
P h y s ic a l
M T P
S c h ic h t 1
M T P
Abb. 2.4-3: SS7-Funktionsteile im Schichtenmodell
Im SS7 sind folgende Parts, die den eigentlichen Kern vom SS7 bilden, zu unterscheiden: MTP (Message Transfer Part) für den Nachrichtentransport, der sich aus drei Modulen zusammensetzt, die drei SS7-Schichten darstellen; SCCP (Signalling Connection Control Part) für den Auf- und Abbau von Ende-zu-Ende-Signalisierungsverbindungen (s. Abb. 2.4-6); TCAP (Transaction Capabilities Application Part) zur Unterstützung von Transaktionsfähigkeiten. TCAP nutzt die SCCP-Dienste.
2.4 Signalisierungssystem Nr.7
Eine andere Klasse von Parts stellen sog. User Parts (UPs) dar. Sie können als eine Art von SS7-Anwendungen angesehen werden, die sowohl direkt auf die MTP-Funktionen zugreifen als auch die SCCP-Funktion nutzen (vgl. Abb. 2.44). Die UPs sind: ISUP (ISDN User Part) für die Signalisierung im ISDN; TUP (Telephone User Part) für die Signalisierung in digitalen Telefonnetzen; DUP (Data User Part) für die Signalisierung in Datennetzen. Eine andere Klasse von SS7-Anwendungen stellen sog. ASEs (Application Service Elements) dar, die nur die TCAP-Dienste nutzen. Hierzu gehören: OMAP (Operations & Maintenance Application Part) für die Kontrolle und Verwaltung des SS7-Netzes; MAP (Mobile Application Part) für die Signalisierung in GSM-Mobilfunknetzen; INAP (Intelligent Network Application Protocol) für die Signalisierung in Intelligenten Netzen (IN).
www.wiwobooks.com
Je nach Bedarf können weitere ASEs entwickelt werden.
2.4.2 Funktionelle Struktur von SS7
T C A P
S C C P
A S E s ... M A P IN A P
A S E s
U P s ... IS U P T U P
U P s
M A P IN A P
E n d e -z u -E n d e -S IG -V e rb in d u n g
M T P S IG -K a n a l
N a c h ric h te n tra n s p o rts y s te m
... IS U P T U P
T C A P
S C C P
S ig n a lis ie ru n g s p u n k t B
S ig n a lis ie ru n g s p u n k t A
Abbildung 2.4-4 zeigt die „Zusammenarbeit“ einzelner User Parts von SS7.
M T P S IG -K a n a l
Abb. 2.4-4: Funktionelle Struktur von SS7 – Abhängigkeiten zwischen einzelnen User Parts ASE: Application Service Element, SIG: Signalisierung, MTP: Message Transfer Part, SCCP: Signalling Connection Control Part, TCAP: Transaction Capabilities Application Part
71 User Parts als SS7Anwendungen
72 MTPFunktion
2
Signalisierung in Telefonnetzen und ISDN
MTP dient als Nachrichtentransportsystem und sorgt für ein fehlerfreies Übertragen von SS7-Nachrichten zwischen den Vermittlungsstellen. Die Hauptfunktionen der einzelnen Schichten von MTP sind (vgl. Abb. 2.4-3): Schicht 1: physikalische Bitübertragung; Schicht 2: gesicherte Übermittlung von SS7-Nachrichten zwischen benachbarten Knoten im SS7-Netz; Schicht 3: Routing von Nachrichten im SS7-Netz.
SCCPFunktion
Während MTP hauptsächlich für die Übertragung von SS7-Nachrichten zwischen den benachbarten Knoten im SS7-Netz verantwortlich ist, sorgt SCCP für den Aufbau von logischen Ende-zu-Ende-Verbindungen, die den Austausch von SS7-Nachrichten zwischen zwei gleichen UPs entsprechend in der QuellVermittlungsstelle und der Ziel-Vermittlungsstelle ermöglichen. Mit SCCPHilfe können aber auch die TCAP-Module in Quell-Vermittlungsstelle und Ziel-Vermittlungsstelle die SS7-Nachrichten über das Netz austauschen.
TCAPFunktion
TCAP stellt sog. Transaktionsfähigkeiten zur Verfügung und dient als „Verpackungs- und Versandinstanz“ für die Übermittlung beliebiger Nachrichten über das SS7-Netz. Diese Fähigkeiten sollen die TCAP-Anwendungen in die Lage versetzen, sich unabhängig von Nutzkanalverbindungen über ein SS7-Netz zu verständigen.
www.wiwobooks.com
SS7Nachrichten
Die Übermittlung von SS7-Nachrichten erfolgt in Form von Paketen, die mit einer Fehler- und Sequenzkontrolle versehen werden. Eine SS7-Nachricht besteht aus dem Adressen-, dem Steuerungs- und einem Informationsteil. Zur Unterscheidung von Nachrichten, zur Zuteilung zu den entsprechenden Parts und zur Übermittlung im SS7-Netz dienen die Angaben im sog. Routing Label.
Signalisierungsarten
Wie Abbildung 2.4-5 zeigt, sind zwei Signalisierungsarten zu unterscheiden: Link-by-Link-Signalisierung – sorgt für die Übermittlung von SS7-Nachrichten zwischen benachbarten Vermittlungsstellen; Ende-zu-Ende-Signalisierung – sorgt für die Übermittlung von SS7-Nachrichten zwischen Quell- und Ziel-Vermittlungsstelle.
Ende-zuEndeSignalisierung
Hinsichtlich der Ende-zu-Ende-Signalisierung ist Folgendes hervorzuheben: sie wird in den Transit-Vermittlungsstellen nur innerhalb von MTP abgewickelt, sodass die SS7-Nachrichten dort nicht interpretiert, sondern nur weitergeleitet werden. Dies bedeutet, dass Transit-Vermittlungsstellen für die Ende-zu-Ende-Signalisierung transparent sind; sie ist vom Vorhandensein des Nutzkanals zwischen zwei Endeinrichtungen unabhängig. Die Notwendigkeit, ohne den Nutzkanal zwischen zwei Vermittlungsstellen gewisse Nachrichten zu übermitteln, entsteht bei der Realisierung bestimmter Dienstmerkmale. Insbesondere kommt dies im ISDN
74
2
Signalisierung in Telefonnetzen und ISDN
erfolgt über den D-Kanal nach dem D-Kanal-Protokoll. Zwischen den Vermittlungsstellen werden Signalisierungsnachrichten vom ISUP (ISDN User Part) als Link-by-Link-Signalisierung übertragen (vgl. Abb. 2.4-5). Hier werden sowohl die ISUP-Nachrichten erläutert, die man zum Auf- und Abbau einer ISDN-Verbindung benötigt, als auch die SCCP-Nachrichten, die für den Aufund Abbau einer parallel zur ISDN-Verbindung verlaufenden Ende-zu-EndeSignalisierungsverbindung dienen.
D -K a n a l-P r o to k o ll
IA M
[C R ]
T V S t Y IA M
C C
[C R ] A C M
A C M
A L E R T C O N N
S E A L C O C O
A N S
A N S IS D N -V e rb in d u n g
D IS C R E L R E L A C K
*
R E L
*
R L C R L S D
R L C
R E L *
T U P E R T N N N N A C K
D IS C R E L R E L A C K
D -K a n a l-P r o to k o ll
F V S t
T V S t X S E T U P C A L L P R O C
www.wiwobooks.com D u rc h s c h a lte n d e s N u tz k a n a ls
R L C
* F re ig a b e d e s N u tz k a n a ls
Abb. 2.4-7: SS7-Verlauf beim Auf- und Abbau einer ISDN-Verbindung FVSt: Fernvermittlungsstelle, TVSt: Teilnehmervermittlungsstelle
Aufbau einer ISDNVerbindung
Beim Aufbau einer ISDN-Verbindung werden folgende SS7-Nachrichten übermittelt: IAM (Initial Address Message) – eine ISUP-Nachricht, die beim Verbindungsaufbau als erste Nachricht zur nächsten Vermittlungsstelle gesendet wird. Sie dient zur Belegung eines Nutzkanals und enthält entweder die vollständige Rufnummer der Gegenseite oder mindestens den Teil der Rufnummer, der nötig ist, um IAM bis zur Ziel-TVSt Y übermitteln zu können. IAM enthält die Angaben aus der Nachricht SETUP des D-Kanal-Protokolls, die direkt beim Aufbau einer ISDN-Verbindung ausgewertet werden müssen (z.B. für die Kompatibilitätsprüfung). IAM überträgt auch eine SCCPNachricht CR (Connect Request), die den Aufbau einer Ende-zu-EndeSignalisierungsverbindung beim Partner-SCCP in der TVSt Y verlangt. CC (Connection Confirmation) – eine SCCP-Nachricht, die den Aufbau ei-
ner Ende-zu-Ende-Signalisierungsverbindung bestätigt. Nach dem Empfang von IAM wird der Aufbau der Signalisierungsverbindung in der TVSt Y abgeschlossen; sie zeigt dies der TVSt X mit CC an. CC wird in der Fernvermittlungsstelle nicht interpretiert (vgl. Abb. 2.4-5).
2.5 Schlussbemerkungen
75
ACM (Address Complete Message) – eine ISUP-Nachricht, mit der mitgeteilt wird, dass die gerufene ISDN-Endeinrichtung frei ist und der ankommende Ruf signalisiert wird. ANS (Answer Message) – teilt mit, dass die gerufene Endeinrichtung die Verbindung entgegengenommen hat. Nach dem Eintreffen von ANS bei der TVSt X beginnt die Gebührenerfassung für die ISDN-Verbindung.
Beim Abbau einer ISDN-Verbindung werden folgende SS7-Nachrichten über- Abbau einer ISDNmittelt: REL (Release) – eine ISUP-Nachricht – leitet den Abbau einer ISDN-Verbindung ein, sobald die lokale ISDN-Endeinrichtung dies mit DISC veran-
Verbindung
lasst. RLC (Release Complete) – eine ISUP-Nachricht – dient als Bestätigung der REL-Nachricht.
Nachdem die Nutzkanalverbindung abgebaut wurde, erfolgt der Abbau der En- Abbau der de-zu-Ende-Signalisierungsverbindung mit Hilfe folgender SCCP-Nachrichten: SignalisierungsverbinRLSD (Released) – leitet den Abbau einer Ende-zu-Ende-Signalisierungs- dung
verbindung ein und kann von SCCP an beiden Seiten der Verbindung abgeschickt werden.
www.wiwobooks.com
RLC (Release Complete) – bestätigt den Abbau einer Ende-zu-Ende-Signa-
lisierungsverbindung. Für weitere Informationen über SS7 ist auf die Webquellen [Web 02] und [Web 03] zu verweisen.
2.5
Schlussbemerkungen
Ziel dieses Kapitels war es, die Protokolle für die Signalisierung in digitalen Telefonnetzen und im ISDN in einer komprimierten Form darzustellen. Eine detaillierte Darstellung der Signalisierung in den Netzen für die Sprachkommunikation würde den Rahmen dieses Kapitels sprengen. Abschließend sind folgende Bemerkungen hinzuzufügen: Für die Sprachkommunikation wurden – noch in den 90er-Jahren – in privaten Unternehmen und in öffentlichen Verwaltungen sog. (ISDN-)TK-Anlagen installiert; sie stellen private Vermittlungssysteme dar. Der Auf- und Abbau von ISDN-Verbindungen in ISDN-TK-Anlagen verläuft nach dem D-Kanal-Protokoll. Durch die Konvergenz der Sprach- und Datennetze und dadurch, dass die Migration zu VoIP-Technologie ihre Reife bereits erreicht hat, werden immer häufiger IP-basierten die klassischen TK-Anlagen durch IP-basierte TK-Anlagen ersetzt. Auf das TK-Anlagen
76
2
Signalisierung in Telefonnetzen und ISDN
Konzept einer IP-basierten TK-Anlage wurde in Abschnitt 1.2.4 bereits kurz eingegangen. Sollte beispielsweise die Signalisierung in der IP-basierten TK-Anlage nach H.225.0 und H.245 aus der H.323-Familie (s. Kapitel 6) realisiert werden, könnte man diese Signalisierung als Realisierung des DKanal-Protokolls über TCP-Verbindungen bezeichnen. Vernetzung von IPbasierten TK-Anlagen
Große Unternehmen werden oft auf verschiedene Standorte aufgeteilt. Das Verlangen nach der unternehmensweiten Kommunikation führt zur Entstehung privater TK-Netze. Noch in den 90er-Jahren hat die Sprachkommunikation in diesen TK-Netzen auf einer Vernetzung von ISDN-TK-Anlagen basiert, die an verschiedenen Standorten des Unternehmens installiert waren (s. Abschnitt 10.2.2). Da ISDN-TK-Anlagen durch IP-basierte TK-Anlagen ersetzt werden, führt diese Entwicklung zur Vernetzung von IP-basierten TK-Anlagen.
Protokoll QSIG
Für die Vernetzung von ISDN-TK-Anlagen wurde ein logischer Referenzpunkt Q eingeführt. Der Punkt Q ist innerhalb der Schicht 3 lokalisiert und stellt eine logische Schnittstelle zwischen ISDN-TK-Anlagen dar. Die wichtigsten Hersteller von ISDN-TK-Anlagen haben die Entwicklung eines Protokolls für die Vernetzung von ISDN-TK-Anlagen vorangetrieben, was zur Entstehung von QSIG (Q-Signalling) geführt hat. QSIG wurde durch ECMA spezifiziert und kann als erweitertes D-Kanal-Protokoll der Schicht 3 zwischen ISDN-TK-Anlagen angesehen werden. Während die Schichten 1 und 2 beim privaten und öffentlichen ISDN identisch sind, stellt die Schicht 3 beim QSIG eine Erweiterung des D-Kanal-Protokolls (DSS1) dar, um verschiedene Features zur Verfügung zu stellen. Auf QSIG beziehen sich mehrere ECMA-Standards. Für Näheres über QSIG sei auf die Webquellen [Web 04] verwiesen.
www.wiwobooks.com
QSIG über IP
Große Unternehmen tendieren dazu, ihre auf Vernetzungen von klassischen ISDN-TK-Anlagen basierenden Netze für die Sprachkommunikation durch Vernetzungen von IP-basierten TK-Anlagen zu ersetzen. Dies führt im Prinzip zur Entstehung einer standortübergreifenden IP-basierten TK-Anlage. Wird hierbei VoIP mit H.323 implementiert, übernimmt H.450.x weitgehend die Funktion von QSIG (s. Abschnitt 6.6). Bei VoIP mit SIP ist die Funktionalität von QSIG nicht nötig. Daher verliert QSIG allmählich an Bedeutung. Ab und zu entsteht aber noch die Notwendigkeit, herkömmliche ISDN-TK-Anlagen mit QSIG über IP-Netze zu vernetzen – also QSIG über IP zu implementieren. Die Ideen hierfür sind im Standard ECMA-355 – siehe [Web 05] – und in den RFCs 3204 und 4497 (Internetworking SIP und QSIG) der IETF enthalten.
3
TCP/IP- und VoIP-Protokolle
Die Rechnerkommunikation verläuft nach bestimmten Regeln, die vor allem Protokolle Datenformate und deren zeitliche Reihenfolge festlegen. Diese Regeln werden für VoIP als Kommunikationsprotokoll (kurz Protokoll) spezifiziert. Die Kommunikation im Internet wird durch mehrere Protokolle aus der Protokollfamilie TCP/IP (Transmission Control Protocol/Internet Protocol) geregelt. Für VoIP sind verschiedene Klassen von Protokollen nötig. Hierzu gehören die Protokolle für die Übermittlung von Sprache, Signalisierungsprotokolle für den Auf- und Abbau von Verbindungen zwischen IP-Telefonen und Protokolle zur Steuerung von VoIP-Gateways. Bei der Nutzung verschiedener Internet-Dienste, wie z.B. Web-Dienst, E-Mail, Internet-Telefonie, verwendet man auch verschiedene Adressen. Sie berücksichtigen die Struktur von DNS (Domain Name System) und können mit Hilfe von DNS auf entsprechende Internet-Adressen, die sog. IP-Adressen, abgebildet werden. Mit Hilfe von ENUM (tElephone Number URI Mapping) ist es sogar möglich, verschiedene Internet-Dienste mit Hilfe einer Telefonnummer zu adressieren und damit auch herkömmliche Netze für die Sprachkommunikation – d.h. ISDN/PSTN, GSM und UMTS – mit dem Internet zu integrieren.
Telefonnummern als Adressen für InternetDienste
www.wiwobooks.com
Nach der Darstellung der wichtigsten Protokolle der Familie TCP/IP im Ab- Überblick schnitt 3.1 erläutert Abschnitt 3.2 die Prinzipien der Kommunikation im Inter- über das net. Einer kurzen Darstellung des Protokolls IP widmet sich Abschnitt 3.3. Die Kapitel Besonderheiten der Transportprotokolle UDP und TCP und ihre Eignung für VoIP werden im Abschnitt 3.4 dargestellt. Auf die Funktionsweise von DNS und seinen Einsatz bei VoIP geht Abschnitt 3.5 ein. Die Protokolle für VoIP präsentiert kurz Abschnitt 3.6. Die Bedeutung von SCTP zeigt Abschnitt 3.7. Das ENUM-Konzept erläutert Abschnitt 3.8. Die Schlussbemerkungen in Abschnitt 3.9 runden dieses Kapitel ab. In diesem Kapitel werden u.a. folgende Fragen beantwortet: Wie wird die Protokollfamilie TCP/IP strukturiert? Nach welchen Prinzipien erfolgt die Kommunikation im Internet? Welche Funktionen erfüllen die Transportprotokolle UDP und TCP? Wie wird das DNS aufgebaut und bei VoIP genutzt? Welche Protokolle sind für VoIP nötig? Welche Bedeutung hat das neue Transportprotokoll SCTP? Wie kann man Telefonnummern zur Adressierung von Internet-Diensten nutzen?
Ziel dieses Kapitels
78
3
TCP/IP- und VoIP-Protokolle
3.1 IP als Netzwerkprotokoll
Protokollfamilie TCP/IP
Abbildung 3.1-1 zeigt die Struktur der Protokollfamilie TCP/IP und die Zuordnung ihrer Protokolle zu den Schichten des berühmten OSI-Schichtenmodells. Das IP wird der Schicht 3 (Netzwerkschicht) zugeordnet, weshalb man es auch Netzwerkprotokoll nennt. Das Protokoll TCP gehört zur Schicht 4 (Transportschicht), sodass es als Transportprotokoll bezeichnet wird. Die Anwendungsprotokolle (auch Applikationen genannt) sind den oberen Schichten zuzuordnen. Die Protokollfamilie TCP/IP beinhaltet außer TCP und IP u.a.: das verbindungslose Transportprotokoll UDP (User Datagram Protocol), die „Hilfs“-Protokolle ARP und ICMP sowie verschiedene Anwendungsprotokolle (HTTP, DHCP,...). V e rb in d u n g s o rie n tie rte A n w e n d u n g s p ro to k o lle H .3 2 3 - S I G
F T P H T T P
V e rb in d u n g s lo s e A n w e n d u n g s p ro to k o lle
S M T P
...
S N M P D N S
M e g a c o
M G C P
D H C P
R T P
www.wiwobooks.com 4
T C P
3 N e tz w e r k s c h ic h t 2 D a ta -L in k -S c h ic h t 1 P h y s ik a lis c h e S c h ic h t
I P N IC
R T C P
...
U D P
T r a n s p o r ts c h ic h t A R P
S IP
IC M P Ü b e rm ittlu n g s n e tz e
Abb. 3.1-1: Wichtige Komponenten der Protokollfamilie TCP/IP im Schichtenmodell NIC: Network Interface Controller (Adapterkarte), SIG: Signalisierung
Die wichtigste Komponente der Protokollfamilie TCP/IP ist das Protokoll IP, das festlegt, wie die Daten in Form eigenständiger, voneinander unabhängiger Datenpakete (sog. IP-Pakete) übermittelt werden. „Hilfs“Protokolle
Dem Protokoll IP stehen die folgenden zwei „Hilfs“-Protokolle zur Verfügung: ARP (Address Resolution Protocol) ARP unterstützt die Adressierung und hat die Aufgabe, für eine IP-Adresse die entsprechende physikalische Adresse des Rechners im Netzwerk (d.h. in LANs die sog. MAC-Adresse) zu bestimmen. ICMP (Internet Control Message Protocol) ICMP wird für die Übertragung von Fehlermeldungen und anderen Steuerungsinformationen verwendet.
3.1 Protokollfamilie TCP/IP
79
Bemerkung: ICMP wird oft der Schicht 3 zugeordnet. Weil die Nachrichten von ICMP in IP-Paketen übermittelt werden, könnte man ICMP nach den im Schichtenmodell geltenden Prinzipien zwar der Schicht 4 zuordnen, doch ist ICMP kein Transportprotokoll.
Die Transportprotokolle, d.h. die Protokolle der Schicht 4, sind u.a.: TCP (Transmission Control Protocol) TCP ermöglicht es, virtuelle Verbindungen zwischen den kommunizierenden Rechnern auf- und abzubauen. Unter einer virtuellen Verbindung ist eine Vereinbarung zwischen zwei Applikationen zu verstehen, die vor der eigentlichen Kommunikation stattfindet und ihren Ablauf regelt. Somit stellt TCP ein verbindungsorientiertes Transportprotokoll dar. Weil es mittels Fehlerkontrolle eine zuverlässige Datenübermittlung gewährleistet, kann TCP als Sicherungsprotokoll zwischen zwei Rechnern, die nicht direkt miteinander verbunden sind, angesehen werden.
Transportprotokolle
UDP (User Datagram Protocol) Im Gegensatz zu TCP übermittelt man bei UDP Daten verbindungslos, d.h. ohne vorher eine virtuelle Verbindung aufzubauen. UDP gibt keine Garantie für die korrekte Übermittlung der Daten.
www.wiwobooks.com
Die beiden Transportprotokolle TCP und UDP können bereits als „klassische Protokolle“ angesehen werden. Seit Oktober 2000 steht ein neues verbindungsorientiertes Transportprotokoll SCTP (Stream Control Transmission Protocol) zur Verfügung, das im Vergleich zu TCP zusätzliche Funktionalität bietet. Der Transport von Daten erfolgt bei SCTP effizienter als bei TCP. Im Allgemeinen kann SCTP als Modifikation und Erweiterung von TCP gelten. Auf SCTP geht Abschnitt 3.7 näher ein. Für die Unterstützung der Echtzeitkommunikation (wie z.B. VoIP und IPTV) über IP-Netze wurde sowohl das neue verbindungslose Transportprotokoll DCCP (Datagram Congestion Control Protocol) im RFC 4340 (März 2006) spezifiziert als auch UDP modifiziert. Die modifizierte UDP-Version heißt UDP-Lite.
Neue Transportprotokolle: SCTP, DCCP und UDP-Lite
Anwendungsprotokolle lassen sich in drei Gruppen aufteilen:
Arten der Anwendungsprotokolle
verbindungsorientierte, verbindungslose und gemischte. Verbindungsorientierte Anwendungsprotokolle sind diejenigen, die das Transportprotokoll TCP nutzen (vgl. Abb. 3.1-1). Die verbindungslosen Anwendungsprotokolle verwenden dagegen das Transportprotokoll UDP. Gemischte Anwendungsprotokolle werden so konzipiert, dass sie sowohl verbindungslose als auch verbindungsorientierte Kommunikation voraussetzen und die beiden Protokolle TCP und UDP nutzen.
80
3
TCP/IP- und VoIP-Protokolle
Verbindungs- Zu den verbindungsorientierten Anwendungsprotokollen gehören u.a.: orientierte HTTP (Hypertext Transfer Protocol) für die Web-Anwendungen; AnwendungsFTP (File Transfer Protocol) für den Transfer von Dateien; protokolle
SMTP (Simple Mail Transfer Protocol) für den Transfer von E-Mails; H.323-Signalisierung (H.323-SIG) Das sind die Protokolle H.225.0 und H.245, nach denen die virtuellen Verbindungen zwischen zwei IP-Telefonen bei VoIP nach dem Standard H.323 auf- und abgebaut werden. Verbindungs- Verbindungslose Anwendungsprotokolle, die das UDP nutzen, sind u.a.: lose DHCP (Dynamic Host Configuration Protocol) für die dynamische ZuordAnwendungsnung (d.h. nach Bedarf) von IP-Adressen zu Rechnern; protokolle
SNMP (Simple Network Management Protocol) für Netzwerk-Management; RTP (Real-time Transport Protocol) für den Transport von Audio und Video über IP-Netze; RTCP (RTP Control Protocol) für die Überwachung des Transports von Audio und Video;
www.wiwobooks.com
SIP (Session Initiation Protocol) für die Realisierung von MultimediaKommunikation im Internet und in privaten IP-Netzen; MGCP (Media Gateway Control Protocol) für die Ansteuerung von VoIPGateways; Megaco (Media Gateway Control), das der Funktion nach dem MGCP entspricht. Gemischte Anwendungsprotokolle
Zur Klasse der gemischten Anwendungsprotokolle, die sowohl das verbindungslose UDP als auch das verbindungsorientierte TCP voraussetzen, gehört z.B. das DNS (Domain Name System), das man als Auskunftsdienst für IPAdressen im Internet ansehen kann. Leider lassen sich hier nicht alle wichtigen Protokolle darstellen. Für ausführliche Informationen über die Protokollfamilie TCP/IP ist z.B. auf das Buch [BaHo 07] zu verweisen.
3.2
Prinzip der Kommunikation im Internet
Das Internet kann als ein Dienst für die Übermittlung von Informationen in Form von IP-Paketen (s. Abb. 3.2-3) angesehen werden. Vergleicht man diesen Dienst mit dem Briefdienst der Post, so entspricht ein IP-Paket einem Brief und die IP-Adresse einer postalischen Adresse.
3.2 Prinzip der Kommunikation im Internet
81
3.2.1 Bildung von IP-Paketen Bei der Nutzung des verbindungslosen Transportprotokolls UDP werden Daten Nutzung von bzw. eine Nachricht eines Anwendungsprotokolls um den UDP-Header er- UDP gänzt, sodass eine UDP-Dateneinheit – auch als UDP-Paket bezeichnet – entsteht. Wie Abbildung 3.2-1 zeigt, wird aus jeder UDP-Dateneinheit durch das Voranstellen eines IP-Headers ein IP-Paket gebildet. Da die IP-Pakete keine Angaben zur Synchronisation enthalten, um sie auf der Leitung zu „markieren“, müssen sie in Frames der Schicht 2 (Data-Link-Schicht) eingebettet werden. Diese Frames bezeichnet man als Data-Link-Frames (kurz DL-Frames). D a te n b z w . N a c h ric h t U D P D a te n e in h e it IP P a k e t D L F ra m e
IP H e a d e r
D L H e a d e r
U D P H e a d e r
U D P -N u tz la s t
U D P -D a te n e in h e it D L T ra ile r
IP -P a k e t
www.wiwobooks.com
Abb. 3.2-1: Verkapselung der Nutzlast beim UDP-Einsatz
In LANs bildet die sog. MAC-Funktion (Media Access Control) den Kern der MACData-Link-Schicht. Wird ein IP-Paket in einem LAN übermittelt, so wird es in Frames einen MAC-Frame eingebettet. Bei der Übermittlung der IP-Pakete über eine in LANs Leitung bzw. über eine Punkt-zu-Punkt-Verbindung wird innerhalb der Schicht 2 häufig das Protokoll PPP (Point-to-Point Protocol) verwendet. In diesem Fall stellen die DL-Frames PPP-Frames dar. Abbildung 3.2-2 illustriert, wie die IP-Pakete aus den Daten bzw. einer langen Nutzung von Nachricht eines Anwendungsprotokolls bei der Nutzung des verbindungs- TCP orientierten Transportprotokolls TCP gebildet werden. D a te n b z w . N a c h ric h t D a te n s e g m e n te T C P - T C P D a te n s e g m e n t H e a d e r IP P a k e t D L F ra m e
D L H e a d e r
IP H e a d e r
N u tz la s t
T C P -D a te n s e g m e n t IP -P a k e t
Abb. 3.2-2: Verkapselung der Nutzlast beim TCP-Einsatz
D L T ra ile r
82
3
TCP/IP- und VoIP-Protokolle
Anders als bei UDP werden die Daten bei TCP in mehrere Datensegmente eingeteilt. Jedes Datensegment wird um einen TCP-Header erweitert, sodass ein sog. TCP-Datensegment entsteht. Aus jedem TCP-Datensegment wird im nächsten Schritt ein IP-Paket gebildet. Zum Senden wird das IP-Paket in einen DL-Frame eingekapselt. Wie aus den Abbildungen 3.2-1 und 3.2-2 ersichtlich ist, werden die IP-Pakete zum Senden in entsprechende DL-Frames der zweiten Schicht eingekapselt, die vom Übermittlungsnetz abhängig sind. Erst in einem DL-Frame kann ein IPPaket über ein Netz zum Ziel gesendet werden.
3.2.2 Prinzip der Kommunikation im Internet Internet als heterogenes IP-Netz
Das Internet stellt eine weltweite Kopplung unterschiedlicher physikalischer Netze dar, in denen das Protokoll IP Anwendung findet. Daher ist das Internet ein heterogenes IP-Netz. Abbildung 3.2-3 illustriert das Prinzip der Kommunikation im Internet anhand eines Beispiels, in dem eine Folge von TCP-Datensegmenten gesendet wird. TCP im Quellrechner teilt die zu sendenden Daten nach Bedarf in kleinere Datensegmente auf. Jedes Datensegment wird als ein IP-Paket gesendet. Im Zielrechner setzt TCP die in IP-Paketen empfangenen Datensegmente wieder zusammen. Gehen einige Datensegmente bei der Übertragung verloren bzw. werden sie verfälscht, so fordert TCP vom Zielrechner ihre wiederholte Übermittlung.
Q u e llr e c h n e r
6
T C P
U D P IP
3 4
5
2
T C P -D a te n s e g m e n te
1
. . .
. . .
T C P
U D P IP N IC
In te r n e t (IP -N e tz )
N IC
S N
R
6
A p p lik a tio n
S N S N
S N
R
4 5
R
R
3
2
S N
Z ie lr e c h n e r
www.wiwobooks.com
1
IP -P a k e t
Abb. 3.2-3: Prinzip der Kommunikation im Internet – Datagram-Prinzip R: Router, SN: IP-Subnetz (IP-Subnetwork), NIC: Network Interface Controller
IP-Pakete wie Briefe
IP ist verbindungslos, was bedeutet, dass die IP-Pakete als sog. Datagramme (d.h. wie Briefe bei der Post) unabhängig voneinander an den Zielrechner gesendet werden. Die wichtigsten Angaben in IP-Paketen sind die IP-Adressen von Quell- und Zielrechner. Logisch betrachtet setzt sich das Internet als IPNetz aus einer Vielzahl von IP-Subnetzen zusammen, die mit Hilfe von Routern miteinander vernetzt sind. Ein Router leitet jedes empfangene IP-Paket ab-
3.2 Prinzip der Kommunikation im Internet
83
hängig von der aktuellen Lage im Netz und unabhängig von anderen Paketen weiter. Dadurch werden die einzelnen IP-Pakete aus einer Reihenfolge in der Regel über unterschiedliche Routen zum Ziel übermittelt. In der Analogie mit dem Briefdienst der Post könnte man ein IP-Subnetz mit einem Postleitzahlengebiet vergleichen und einen Router mit einer Briefverteilungsstelle. Da die einzelnen IP-Pakete unabhängig voneinander verschickt werden, können sie am Ziel in einer anderen Reihenfolge ankommen als die, in der sie abgeschickt wurden. Für die Sortierung der IP-Pakete in ihre korrekte Reihenfolge und deren Zusammensetzung zu einer Datei ist TCP verantwortlich. Die IP-Pakete im Netz können zirkulieren, daher muss die Verweilzeit der IP- Bedeutung Pakete im Netz kontrolliert werden. Der Quellrechner gibt als TTL-Angabe von (Time To Live) an, wie lange das IP-Paket im Netz verweilen darf (s. Abb. 3.3- Time To Live 1). Weil der TTL-Wert in jedem Router um 1 verringert wird, ist er gleichbedeutend mit der maximalen Anzahl von Routern, die ein IP-Paket durchlaufen darf. Fällt der TTL-Wert auf 0, wird das IP-Paket im Router verworfen, und der Quellrechner wird mit einer Meldung des Protokolls ICMP darüber informiert. Bemerkung: Weil die einzelnen IP-Pakete aus einer Reihenfolge oft über unterschiedliche Routen zum Ziel übermittelt werden, sind auch die Übermittlungszeiten einzelner IP-Pakete unterschiedlich. Man hat in diesem Fall mit Schwankungen der Übermittlungszeit zu rechnen. Diese Schwankungen werden auch als Jitter bezeichnet. Jitter gilt als größter Störfaktor bei VoIP-Anwendungen.
www.wiwobooks.com
3.2.3 Interpretation von IP-Adressen Die IP-Adresse eines Rechners kann (logisch gesehen!) einem Kommunikationspuffer zugeordnet werden, der einen Zugangsport zum Protokoll IP darstellt. Dieser Kommunikationspuffer befindet sich an der Grenze zwischen den Protokollen TCP und IP und somit an der Grenze zwischen den Schichten 3 und 4 (s. Abb. 3.1-1). Abbildung 3.2-4 bringt dies zum Ausdruck. R e c h n e r A A p p lik a tio n e n A 1 A m ... P o rts IP -A d r. = x
T C P /U D P
R e c h n e r B D a te n ü b e rm ittlu n g : b e i T C P g e s ic h e rt, b e i U D P u n g e s ic h e rt u n g e s ic h e rte D a te n ü b e rm ittlu n g
IP N IC
In te rn e t a ls I P -P a k e tü b e r m ittlu n g s d ie n s t
Abb. 3.2-4: IP-Adressen als postalische Adressen am IP-Netz
A p p lik a tio n e n A m A 1 ... P o rts T C P /U D P IP -A d r. = y IP N IC
IP-Adresse als postalische Adresse im Internet
84
3
TCP/IP- und VoIP-Protokolle
Wie hier ersichtlich ist, erfolgt die Kommunikation durch den Austausch von IP-Paketen zwischen zwei Kommunikationspuffern an der Grenze zwischen den Schichten 3 und 4 in den kommunizierenden Rechnern. Daher stellen IP und alle darunter liegenden Netzkomponenten – d.h. die ersten drei Schichten – einen IP-Paketübermittlungsdienst zur Verfügung. Notwendigkeit von TCP
IP gibt keine Garantie für die korrekte Zustellung der Pakete an den Zielrechner und kann Verluste bzw. Verfälschungen von IP-Paketen während der Übermittlung nicht entdecken. Deshalb hat TCP die Aufgabe, Datenverluste und -verfälschungen während der Übertragung zu entdecken und gegebenenfalls eine wiederholte Übermittlung zu veranlassen.
Interpretation von Ports
Die Ports in Rechnern sind als individuelle Kommunikationspuffer einzelner Applikationen zu interpretieren. Die Ports für die zu sendenden Daten, d.h. die sog. Quell-Ports, werden den Applikationen im Quellrechner nach Bedarf (dynamisch) zugeteilt. Den Quell-Ports werden in der Regel große Nummern (zur Identifikation) zugeordnet.
3.2.4 Zweistufige Adressierung
www.wiwobooks.com
Physikalische Wie Abbildung 3.2-5 zeigt, sind in IP-Netzen zwei Adressierungsstufen zu unAdressen terscheiden. Einerseits müssen die Hardware-Komponenten (Endsysteme, Rou-
ter) in jedem Subnetz eindeutig identifiziert werden. Hierfür verwendet man „physikalische“ Adressen – auch als Data-Link-Adressen bezeichnet. Die physikalischen Adressen müssen innerhalb jedes IP-Subnetzes eindeutig sein. R e c h n e r A
R e c h n e r B
A p p l. T C P /U D P 4 3
IP
IP 2 1
D L
A p p l.
D a te n a u s ta u s c h R o u te r
S N 1
P h y s ik a lis c h e A d re s s e
D L
R F
T C P /U D P 4
IP D L
3
IP S N 2
D L
2 1
IP -A d re sse
Abb. 3.2-5: Prinzip der zweistufigen Adressierung in IP-Netzen DL: Data Link, RF: Routing-Funktion, SN: IP-Subnetz
IP-Adressen
Andererseits müssen die Daten in IP-Paketen zwischen zwei Kommunikationspuffern in kommunizierenden Rechnern ausgetauscht werden. Hierfür nutzt man weltweit eindeutige IP-Adressen. Diese haben die folgende Struktur: IP-Adresse = (Subnetz-ID, Host-ID), ID: Identifikation
3.3 Internet-Protokoll IP
85
Die Subnetz-ID gibt an, um welches IP-Subnetz es sich handelt. Mit der HostID wird der Host (Rechner, Router) innerhalb eines IP-Subnetzes identifiziert. Wie aus Abbildung 3.2-5 ersichtlich ist, stellt ein Router ein Endsystem an mehreren Subnetzen dar. Die Routing-Funktion wird innerhalb der Schicht 3, d.h. innerhalb der Schicht mit dem IP, angesiedelt. Physikalische Adressen in LANs nennt man MAC-Adressen. Sie werden oft auch als Nummern von LAN-Adapterkarten betrachtet. Der Quellrechner muss die MAC-Adresse im zu sendenden MAC-Frame setzen. Hierfür muss er über eine Tabelle mit den Zuordnungen IP-Adresse MAC-Adresse verfügen. Diese Zuordnung ist Aufgabe des Protokolls ARP (Address Resolution Protocol). ARP legt eine dynamisch organisierte Tabelle mit IP-Adressen und den zugehörigen MAC-Adressen an, die man auch ARP-Tabelle bzw. ARP-Cache nennt.
MACAdressen und Bedeutung von ARP
Beim Absenden jedes IP-Pakets gilt folgendes Prinzip: Wenn der Zielrechner sich im gleichen IP-Subnetz befindet, wird das IP-Paket direkt an den Zielrechner geschickt, d.h. in einem MAC-Frame mit der Ziel-MAC-Adresse des Zielrechners; sonst wird es an einen IP-Router übergeben – also in einem MACFrame mit der Ziel-MAC-Adresse des Routers. Ein IP-Router kann daher als Grenzübergang zu einem anderen IP-Subnetz angesehen werden.
Prinzip beim Absenden jedes IPPakets
3.3
www.wiwobooks.com
Internet-Protokoll IP
Nach dem Protokoll IP werden Daten unabhängig voneinander in IP-Paketen Besonderdem Zielrechner ohne vorherige Vereinbarung übermittelt. Jedes Paket enthält heiten von IP die IP-Adressen des Quell- und des Zielrechners. IP gibt keine Garantie für die korrekte Zustellung der Pakete an den Zielrechner. Die IP-Pakete können am Ziel sogar in einer anderen Reihenfolge ankommen, als sie abgeschickt wurden. Abbildung 3.2-5 zeigt die Struktur des IP-Headers.
2 0 B y te s
B it: 1
8
H -L T o S /D Id e n tifik a tio n T T L P ro to k o Q u Z
V e r.
S
1 6
F la g s IP ll-N r. e ll-IP -A d re ie l-IP -A d re O p tio n e n
. . . O p tio n e n IP -H e a d e r
T C P -/U D P -H e a d e r
IP -P a k e tlä n g e F ra g m e n t O ffse t -H e a d e r-P rü fsu m m e sse sse F ü llz e ic h e n
IP -P a k e t D a te n s e g m e n t
Abb. 3.3-1: Struktur der IP-Pakete und die Angaben im IP-Header H-L: Header Length, Ver.: Version
3 2
86
3
TCP/IP- und VoIP-Protokolle
Der IP-Header besteht aus einer Vielzahl von 32-Bit-Wörtern. Die ersten 5 dieser Wörter sind immer vorhanden, sodass die minimale Länge des IP-Headers 20 Bytes beträgt. Die weiteren 32-Bit-Wörter sind optional. Angaben im IP-Header
Die einzelnen Angaben im IP-Header haben folgende Bedeutung: Version (Versionsnummer) – die Versionsnummer des klassischen Protokolls IP ist 4. Header-Länge (Header Length) in 32-Bit-Worten. ToS/DS (Type of Service bzw. Differentiated Services) – Diese Angabe ermöglicht es, die IPPakete zu differenzieren, d.h. die Art und Weise ihrer Behandlung in Routern zu spezifizieren. Sie wird für die QoS-Unterstützung (Quality of Service) benutzt (s. Kapitel 4). IP-Paketlänge (Total Length) – gesamte Länge des IP-Pakets in Bytes. Identifikation (Identification) der übertragenen Daten. Diese Angabe wird bei der Fragmentierung der IP-Pakete verwendet. Flags – Dieses Feld enthält die Flags DF (Don´t Fragment) und MF (More Fragments), die bei der Fragmentierung des IP-Pakets verwendet werden. Ist das Bit DF = 1, darf dieses IP-Paket nicht fragmentiert werden. Ist das Bit MF = 1, bedeutet dies, dass es sich bei dem Paket um ein Teil-IP-Paket handelt und dass noch weitere Teile folgen. Mit MF = 0 wird das letzte Teil-IP-Paket markiert. Fragment Offset (Fragmentabstand) wird bei der Fragmentierung des IP-Pakets verwendet. Ist MF=1, gibt der Fragmentabstand die relative Position des Teilpakets in Bezug auf den Datenanfang an und ermöglicht es, mehrere Teilpakete aus einem IP-Paket in der richtigen Reihenfolge zusammenzusetzen.
www.wiwobooks.com
TTL (Time to Live) – die maximale Anzahl von Routern, die das IP-Paket unterwegs zum Zielrechner durchlaufen darf. Protokoll-Nr. (Protocol) – Nummer des Protokolls der Schicht 4 (Transportschicht), an das der Inhalt des Pakets übergeben werden muss; z.B. Protocol = 6 (TCP), = 17 (UDP), = 132 (SCTP). IP-Header-Prüfsumme (Checksum), mit der der IP-Header – einschließlich Optionen – auf Übertragungsfehler hin geprüft werden kann. Quell-IP-Adresse (Source IP-Address) – IP-Adresse des Quellrechners. Ziel-IP-Adresse (Destination IP-Address) – IP-Adresse des Zielrechners. Optionen (variable Länge und optional), die eine besondere Nutzung von IP ermöglichen, wie z.B. Bereitstellung von Zeitmarken, Unterstützung von Routing-Funktionen etc. Füllzeichen (Padding), um die Optionen auf eine Länge von n*32 Bits zu ergänzen.
3.4 Notwendigkeit der Transportschicht
Transportprotokolle in IP-Netzen
Die ersten drei Schichten im Schichtenmodell der IP-Netze stellen einen mit dem Briefpostdienst vergleichbaren IP-Paketübermittlungsdienst zur Verfügung – mit einem gravierenden Nachteil: er garantiert nicht die gesicherte Übermittlung von Daten, d.h., dass der Absender von Daten vom Empfänger nicht informiert wird, welche Daten ohne und welche mit Fehlern empfangen wurden bzw. welche überhaupt nicht angekommen sind. Aus diesem Grund
3.4 Transportprotokolle in IP-Netzen
87
wird eine zusätzliche Funktion benötigt, um den Absender darüber zu informieren, welche Daten er eventuell wiederholt an den Empfänger übermitteln muss. Diese Funktion, die man als Fehlerkontrolle bezeichnet, ist die wesentliche Aufgabe der Transportschicht – d.h. der Schicht 4. Neben der Fehlerkontrolle hat die Transportschicht zwei weitere Aufgaben: die Flusskontrolle und die Überlastkontrolle. Für diese Aufgaben wurden verschiedene Transportprotokolle entwickelt. UDP und TCP sind die wichtigsten und auch die bekanntesten von ihnen. Die weiteren Transportprotokolle sind SCTP (Stream Control Transmission Protocol) und DCCP (Datagram Congestion Control Protocol).
3.4.1 Verbindungsloses Transportprotokoll UDP Um kleine Datenmengen bzw. einzelne Nachrichten zwischen Rechnern trans- UDPportieren zu können, ohne eine logische Verbindung dafür aufbauen zu müssen, Besonderwurde das verbindungslose Transportprotokoll UDP (User Datagram Protocol) heiten eingeführt. Abbildung 3.4-1 illustriert die Nutzung von UDP. R e c h n e r A Q u e llP o rt = a
S IP
S N M P
R T P ... ... U D P
Q u e llIP -A d r = X
www.wiwobooks.com
1 7
R e c h n e r B
U D P -A p p lik a tio n e n
S N M P
V e r b in d u n g s lo s e r T r a n s p o r td ie n s t
R T P
... ... U D P
S c h ic h t 4 : V e r b in d u n g s lo s e T r a n s p o r ts c h ic h t
S IP
Z ie lP o rt = b Z ie lIP -A d r = Y
1 7
I P -P a k e tü b e r m ittlu n g s d ie n s t
IP -P a k e t U D P -P a k e t N u tz la s t
U D P -H e a d e r 1
S o u rc e P o rt = a U D P L e n g th
1 6
D e s tin a tio n P o rt = b C h e c k su m
U D P
3 2
IP Q u e ll-IP -A d r = X Z ie l-IP -A d r = Y P ro t-N r = 1 7 (U D P )
Abb. 3.4-1: Prinzip der Übermittlung einer Nutzlast mit UDP Adr: Adresse, Prot-Nr: Protokollnummer
Mit UDP wird Applikationen ein verbindungsloser Transportdienst zur Verfügung gestellt, der keine Flusskontrolle und keine Überlastkontrolle realisiert, sondern nur eine einfache Fehlerkontrolle. Die wesentliche Aufgabe von UDP besteht darin, mehreren Applikationen einen parallelen Zugriff auf den verbindungslosen Transportdienst zu ermöglichen.
88 UDP bei VoIP
3
TCP/IP- und VoIP-Protokolle
Bei UDP werden keine Quittungen verwendet, um beim Quellrechner eine erneute Übermittlung der am Zielrechner mit Fehlern empfangenen und demzufolge verworfenen UDP-Pakete zu veranlassen. Deswegen wird UDP vom RTP für die Übermittlung von Echtzeitmedien wie Audio und Video und vom SIP verwendet. Daher ist UDP bei VoIP ein wichtiges Transportprotokoll. Wie Abbildung 3.4-1 zeigt, enthält ein IP-Paket in sich ein UDP-Paket. Als Nutzlast in einem UDP-Paket können „normale“ Daten, Echtzeitmedien (Audio, Video) oder eine Nachricht enthalten sein. Das UDP hat die Nummer 17; diese Protokollnummer ist im IP-Header eingetragen, um das im Zielrechner empfangene UDP-Paket an die UDP-Instanz übergeben zu können – so als ob das UDP in der „Zugangssteckdose“ zum IP-Paketübermittlungsdienst an die Pin-Nummer 17 angebunden wäre.
UDPHeader
Der UDP-Header enthält folgende Angaben: Source Port (Quell-Port) – Hier wird die Nummer des Ports als Kommunikationspuffer
der Applikation im Quellrechner angegeben. Destination Port (Ziel-Port) – Hier wird die Nummer des Ports – oft des sog. Well Known Ports1 – eingetragen. Dieser Port dient als Identifikation der Applikation im Zielrechner. Damit teilt man dem Zielrechner mit, an welche Applikation die im UDP-Paket enthaltene Nutzlast übergeben werden muss.
www.wiwobooks.com
UDP Length – Hier wird die Länge des UDP-Pakets angegeben.
Checksum (Prüfsumme) – Diese Prüfsumme ermöglicht es, sowohl im UDP-Paket als auch
in einigen Angaben im IP-Header, die den sog. IP-Pseudo-Header (s. Abbildung 3.4-2) bilden, Übertragungsfehler zu entdecken.
Nachteil der UDP-Fehlerkontrolle bei VoIP Für die Übermittlung von Echtzeitdaten wie z.B. Audio und Video über IPNetze verwendet man das verbindungslose Transportprotokoll UDP. Dieses Protokoll hat aber eine Schwachstelle bei der Echtzeitkommunikation, die wir uns nun näher anschauen wollen. Fehlerkontrolle
UDP realisiert zwar eine einfache Fehlerkontrolle und überprüft, ob ein bzw. mehrere Bits in UDP-Paketen fehlerhaft sind. Daraufhin werden fehlerhafte UDP-Pakete einfach verworfen, ohne den Quellrechner darüber zu informieren. Abbildung 3.4-2 illustriert das Prinzip der UDP-Fehlerkontrolle. Wie hier ersichtlich ist, enthält der UDP-Header eine Prüfsumme (Checksum), anhand der man die während der Übermittlung entstandenen Bitfehler innerhalb von IP-
1
Alle Standardapplikationen werden bei IANA registriert und bekommen dort eine Nummer – als Well Known Port der Applikation bezeichnet. Um den Zielrechner darüber zu informieren, an welche Applikation er das empfangene UDP-Paket übergeben muss, wird die Nummer der Applikation als Zielport im UDP-Header – immer im ersten UDP-Paket – eingetragen.
3.4 Transportprotokolle in IP-Netzen
89
2
Pseudo-Header , UDP-Header und UDP-Payload entdecken kann. Ein IP-Pseudo-Header (s. Abbildung 3.4-2) wird aus einigen Angaben im IP-Header gebildet. S o u rc e IP A d d re ss D e s tin a tio n IP A d d re s s P ro to c o l U D P L e n g th Z e ro IP -H e a d e r IP -P H +
U D P -H e a d e r U D P -H e a d e r
IP -P se u d o -H e a d e r (IP -P H ) S o u rc e P o rt U D P L e n g th
D e s tin a tio n P o rt C h e c k su m
U D P -P a y lo a d U D P -P a y lo a d F e h le rp rü fu n g
Abb. 3.4-2: Prüfsumme im UDP-Header und Angaben im IP-Pseudo-Header (IP-PH)
Durch die Fehlerkontrolle bei UDP werden also ganze UDP-Pakete mit Audio oder Video, auch wenn sie nur einen Übertragungsbitfehler haben, einfach verworfen. Dies hat bei VoIP negative Auswirkungen. Bei der Übermittlung von Audio oder Video über Netze (z.B. über Funkverbindungen in WLANs), in denen Übertragungsbitfehler relativ häufig vorkommen, verursacht die Fehlerkontrolle von UDP zwangsweise häufige Verluste von IP-Paketen. Im Gegensatz zur Übermittlung von Daten ist die negative Auswirkung eines einzigen Übertragungsbitfehlers bei der Audio- und Videokommunikation vernachlässigbar. Wird ein UDP-Paket mit nur einem Bitfehler bei Audio bzw. Video aber gleich verworfen, beeinträchtigt dies die Qualität der Kommunikation viel stärker, als wenn es mit einem Bitfehler z.B. in Audio-Daten an die Applikation übergeben würde. Ein Bitfehler in Audio-Daten ist für das menschliche Ohr nicht wahrnehmbar.
www.wiwobooks.com
Nachteile der UDPFehlerkontrolle
UDP-Lite Um empfangene UDP-Pakete mit einzelnen Bitfehlern beim Transport von Wozu dient Audio bzw. Video nicht verwerfen zu müssen und damit die Häufigkeit der UDP-Lite? Verluste von UDP-Paketen mit Echtzeitdaten zu reduzieren, war eine Modifikation von UDP nötig. Die UDP-Fehlerkontrolle wurde so verändert, dass nur die Bereiche in UDP-Paketen überprüft werden, in denen eventuelle Übertragungsbitfehler eine große Auswirkung auf die Qualität der Kommunikation haben können. So entstand das Protokoll UDP-Lite (s. RFC 3828).
2
Die Konstruktion des IP-Pseudo-Headers ist als überholt zu betrachten. Sie verstößt grundlegend gegen das Schichtenprinzip für den Kommunikationsablauf.
90
3
TCP/IP- und VoIP-Protokolle
UDP-Lite stellt folglich eine Modifikation von UDP dar. Der Header von UDPLite hat fast die gleiche Struktur wie der von UDP – siehe Abbildung 3.4-2. Im Unterschied zu UDP enthält der Header von UDP-Lite jedoch anstelle der Angabe UDP Length die Angabe Checksum Coverage. Möglich ist dies, weil UDP Length im UDP-Header redundant ist und die Länge des UDP-Pakets aus den Angaben im IP-Header (d.h. UDP Length = Total Length minus Header Length) berechnet werden kann. Die Nummern der Well Known Ports sind bei UDP-Lite die gleichen wie bei UDP. Aus diesem Grund können die gleichen Applikationen sowohl UDP als auch UDP-Lite nutzen. Idee von UDP-Lite
Die Idee von UDP-Lite besteht darin, dass man im Header mit Checksum Coverage (CC) angeben kann, welcher Teil der UDP-Payload bei der Fehlerprüfung berücksichtigt werden soll. Abbildung 3.4-3 illustriert dies.
IP -H e a d e r
U D P -L -H
P rü fsu m m e F e h le rp rü fu n g IP -P H
A u d io b z w . V id e o
R T P -H e a d e r C C
U D P -L -H
R T P -P a k e t C C : C h e c k su m
C o v e ra g e
U D P -P a y lo a d
www.wiwobooks.com
Abb. 3.4-3: Überprüfung von Bitfehlern bei UDP-Lite
IP-PH: IP-Pseudo-Header, UDP-L-H: UDP-Lite Header
Der Wert von Checksum Coverage wird von der Applikation auf der Sendeseite bestimmt. Diese Angabe besagt, wie viele Bytes, beginnend vom ersten Byte im UDP-Lite-Header an, die Prüfsumme abdeckt. Im transportierten RTPPaket kann somit nur der RTP-Header auf Bitfehler hin überprüft werden.
3.4.2 Verbindungsorientiertes Transportprotokoll TCP Besonderheiten von TCP
Mittels TCP wird Applikationen ein verbindungsorientierter Transportdienst zur Verfügung gestellt. Im Gegensatz zum UDP-Paket, das als reiner Datencontainer aufgefasst werden kann, beinhalten TCP-Pakete im Header – genau genommen im sog. TCP-Header – umfangreiche Steuerungsinformationen, mit denen sowohl eine Fehlerkontrolle als auch eine Flusskontrolle (Flow Control) realisiert wird sowie eine Überlastkontrolle (Congestion Control) möglich ist.
TCPFunktionen
Beim TCP handelt es sich um eine Ende-zu-Ende-Fehlerkontrolle – vergleiche dazu Abbildung 3.2-4. Daher ist TCP ein Sicherungsprotokoll zwischen den kommunizierenden Rechnern und hat das Ziel, eine zuverlässige Übermittlung von Daten zu garantieren. Für den Transport von Daten wird bei TCP eine virtuelle Verbindung – als TCP-Verbindung bezeichnet – aufgebaut.
3.4 Transportprotokolle in IP-Netzen
91
TCP-Nutzung Bei TCP werden spezielle Mechanismen in Form von Quittungen verwendet, Zuverlässige um eine erneute Übermittlung von am Zielrechner mit Fehlern empfangenen Kommunikaund deshalb verworfenen bzw. unterwegs verloren gegangenen TCP-Paketen tion mit TCP beim Quellrechner als Absender von dieser zu veranlassen. Damit wird mit Hilfe von TCP eine zuverlässige Kommunikation garantiert. Deshalb wird TCP für den Transport von Daten zwischen Applikationen – wie z.B. HTTP, SMTP, FTP – verwendet, die eine zuverlässige Kommunikation voraussetzen. Abbildung 3.4-4 illustriert die Nutzung von TCP. R e c h n e r A H T T P Q u e llP o rt = a Q u e llIP -A d r = X
F T P
R e c h n e r B T C P -A p p lik a tio n e n
S M T P
S M T P
V e r b in d u n g s o r ie n tie r te r T r a n s p o r td ie n s t S c h ic h t 4 : V e r b in d u n g s o r ie n tie r te T r a n s p o r ts c h ic h t
... ... T C P
H T T P
F T P
...
Z ie lP o rt = b
...
Z ie lIP -A d r = Y
T C P
www.wiwobooks.com I P -P a k e tü b e r m ittlu n g s d ie n s t
IP -P a k e t
T C P -V e r b in d u n g
T C P -P a k e t IP
T C P
N u tz la s t
Q u e ll-IP -A d r = X Z ie l-IP -A d r = Y P ro t-N r = 6 (T C P )
Q u e ll-P o rt = a Z ie l-P o rt= b 4 1
D O
8
1 6
S o u rc e P o rt D e s tin a tio n P o rt S e q u e n c e N u m b e r A c k n o w le d g e m e n t N u m b e r rs v C o n tro l F la g s W in d o w U rg e n t P o in te r C h e c k su m O p tio n P a d d in g
3 2
C o n tr o l F la g s U R G A C K
E C N
N C W R E C E
C
E U
A P S H R S T
P
S Y N
R
S F F IN
Abb. 3.4-4: Übermittlung einer Nutzlast mit TCP sowie die Struktur des TCP-Headers CF: Control Flags, DO: Data Offset, rsv: reserviert
Wie hier ersichtlich ist, wird ein TCP-Header der transportierten Nutzlast vor- TCP-Pakete angestellt, sodass die beiden Teile ein TCP-Paket bilden. Anschließend platziert man einen IP-Header. Auf diese Weise entsteht ein IP-Paket. Somit befindet sich ein TCP-Paket in einem IP-Paket. Als Nutzlast kann ein TCP-Paket Nachrichten oder Daten von Applikationen, die einen zuverlässigen und verbindungsorientierten Transportdienst benötigen, enthalten.
92
3
TCP/IP- und VoIP-Protokolle
Das TCP hat die Nummer 6. Diese Protokollnummer ist im IP-Header eingetragen, um das empfangene TCP-Paket im Zielrechner an die TCP-Instanz übergeben zu können. TCPVerbindung
Es ist hervorzuheben, dass in Abbildung 3.4-4 eine logische Verknüpfung von Sockets – von Paaren also (IP-Adresse, Port) – in beiden kommunizierenden Rechnern entsteht. Bei UDP (Abb. 3.4-1) war dies nicht der Fall. Die logische Verknüpfung von Sockets in beiden Rechnern stellt eine TCP-Verbindung dar (siehe auch Abbildung 3.4-5).
TCP-Header
Der TCP-Header enthält folgende Angaben: Source Port (Quell-Port) – Hier wird die Nummer des Ports der Applikation im Quellrechner angegeben, welcher die Daten abgeschickt hat. Destination Port (Ziel-Port) – Hier wird die Nummer des Ports der adressierten Applika-
tion im Zielrechner angegeben. Sequence Number (Sequenznummer) – Gilt in der Senderichtung und dient der byteweisen
Nummerierung gesendeter Daten. Acknowledgement Number (Quittungsnummer) – Zur Bestätigung empfangener Daten.
Diese Nummer wird vom Zielrechner gesetzt, um dem Quellrechner mitzuteilen, bis zu welchem Byte die Daten bereits korrekt empfangen wurden.
www.wiwobooks.com
Data Offset (Datenabstand) – Dieses Feld gibt die Länge des TCP-Headers in 32-Bit-
Worten an und damit die Stelle, ab der die Daten beginnen.
Control Flags – legen fest, welche Felder im Header gültig sind, und werden verwendet,
um bestimmte TCP-Steuerungspakete – quasi als TCP-Nachrichten – zu generieren. Auf die Bedeutung einzelner Control Flags gehen wir im Weiteren ein. Window (Fenstergröße) – dient der Flusskontrolle nach dem sog. Fenster-Mechanismus. Checksum (Prüfsumme) – Diese Prüfsumme erlaubt es, den TCP-Header, die Daten und einen Auszug aus dem IP-Header (u.a. Quell- und Ziel-IP-Adresse), der an die TCP-Instanz zusammen mit den Daten übergeben wird, auf das Vorhandensein von Bitfehlern zu überprüfen. Bei der Berechnung der Prüfsumme wird dieses Feld selbst als „Null“ angenommen. Urgent Pointer (Urgent-Zeiger) – TCP ermöglicht es, den gesendeten normalen Daten dringliche und meist kurze Nachrichten hinzuzufügen und an Kommunikationspartner direkt zu übertragen. Auf solche Nachrichten wird mit Urgent Pointer verwiesen. Option – TCP erlaubt es, sog. Service-Optionen anzugeben. Paddding (Füllzeichen) – Sie ergänzen die Optionsangaben auf die Länge von n*32 Bits.
Byteweise Nummerierung von Daten
Mit der Sequenznummer werden die zu sendenden Daten byteweise nummeriert. Beim Aufbau einer TCP-Verbindung generiert jedes TCP-Modul eine Anfangs-Sequenznummer ISN (Initial Sequence Number). Diese Nummern werden ausgetauscht und gegenseitig bestätigt (s. Abb. 3.4-5). Im Quellrechner wird die Sequenznummer jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer werden die empfangenen Daten byteweise bestätigt. Diese Nummer setzt der Zielrechner, um dem Quellrechner mitzuteilen, bis zu welchem Byte die Daten korrekt empfangen wurden.
93
3.4 Transportprotokolle in IP-Netzen Bemerkung: Mit TCP ist der Zielrechner nicht in der Lage, dem Quellrechner genau mitzuteilen, welche Daten fehlerhaft bzw. verloren gegangen sind. Dadurch werden bei TCP oft korrekt empfangene Daten umsonst wiederholt übertragen. Anders als bei TCP ist dies bei SCTP nicht der Fall (s. Abschnitt 3.7). Im TCP-Header – wie Abbildung 3.4-4 illustriert – ist das Feld Control Flags enthalten. Einzelne Bits in diesem Feld legen fest, welche Felder im Header gültig sind. Sie werden verwendet, um spezielle TCP-Nachrichten zu definieren oder besondere Ereignisse zu signalisieren. Zurzeit sind neun Bits als Flags vorgesehen. Die drei Bits N, C(CWR) und E(ECE) wurden erst in RFC 3168 (September 2001) und in RFC 3540 (Juni 2003) spezifiziert und betreffen die Überlastkontrolle nach dem Verfahren ECN (Explicit Congestion Notification), sodass sie oft auch als ECNBits bezeichnet werden. Ist ein entsprechendes Flag-Bit gesetzt, gilt Folgendes:
Typen von Control Flags
N (Nonce, Nonce Sum) – Einsatz bei der Überlastkontrolle nach ECN – Verweis auf das optionale Feld bei ECN, um ein TCP-Paket vor bösartigen Angriffen zu schützen (RFC 3540). CWR (Congestion Window Reduced) – Einsatz bei der Überlastkontrolle nach ECN. ECE (ECN-Echo) – wird wie CWR bei der Überlastkontrolle nach ECN eingesetzt. URG – Der Urgent Pointer (Zeiger im Urgent-Feld) ist vorhanden und gültig. ACK (ACKnowledgment) – Mit ACK=1 wird ein TCP-Paket
identifiziert, in dem eine Quittungsnummer vorhanden ist. PSH (Push-Funktion) – Die Daten sollen sofort an die nächsthöhere Schicht weitergegeben
www.wiwobooks.com
werden, ohne nächste Segmente abzuwarten.
RST (Reset) – Mit RST=1 wird ein TCP-Paket identifiziert, mit dem sich eine TCP-
Verbindung zurücksetzen lässt.
SYN (Synchronize) – Mit SYN=1 wird ein TCP-Paket <SYN> identifiziert, mit dem der Aufbau einer TCP-Verbindung initiiert werden kann. FIN – Mit FIN=1 wird ein TCP-Paket identifiziert, mit dem man den Abbau einer
TCP-Verbindung initiieren kann.
Aufbau und Abbau einer TCP-Verbindung Eine TCP-Verbindung kann als eine virtuelle Straße mit zwei entgegengesetzt verlaufenden Spuren zwischen zwei Rechnern angesehen werden. Diese Interpretation bringt Abbildung 3.4-5 zum Ausdruck. Über diese in entgegengesetzte Richtungen verlaufenden Spuren werden zwischen den Rechnern byteweise Daten übermittelt. Um den Verlauf der Kommunikation kontrollieren zu können, werden die zu sendenden Daten byteweise nummeriert. Mit der Sequenznummer z.B. x im TCP-Paket mit Daten teilt der Quellrechner dem Zielrechner mit, dass den einzelnen Datenbytes in diesem TCP-Paket die Nummern x, x+1,... zuzuordnen sind. Auf diese Weise lassen sich Daten mit Hilfe der Sequenznummer im TCP-Header byteweise nummerieren. In jeder Übermittlungsrichtung werden die Daten unabhängig voneinander nummeriert.
Byteweise Nummerierung von Daten
Die Nummerierung von Daten sollte aber nicht mit 0 beginnen, sondern mit einer AnfangsSequenznummer ISN (Initial Sequence Number) – einer Zufallszahl. Um die gesendeten TCPPakete eindeutig am Zielrechner identifizieren zu können, müssen sich die beiden kommunizierenden Rechner beim Aufbau jeder TCP-Verbindung gegenseitig mitteilen, mit welcher ISN jeder von ihnen die Nummerierung seiner Datenbytes beginnt.
Bedeutung von ISN
Abbildung 3.4-5 illustriert den Aufbau einer TCP-Verbindung für die Kommunikation zwischen einem Web-Browser als Web-Client und einem Web-Server nach dem Protokoll HTTP.
94
3
TCP/IP- und VoIP-Protokolle
a )
R e c h n e r A
R e c h n e r B
W e b -C lie n t
B ro w se r F T P
1 2
B S
H T T P a
...
...
i
b )
T C P
IP -A d r = x
3
R e c h n e r A S o c k e t (x , i)
W e ll K n o w n P o rt V e r b in d u n g s o r ie n tie r te T r a n s p o r ts c h ic h t
T C P 6
B
IP P a k e tü b e r m ittlu n g s d ie n s t
S
S e r v e r d ie n s te
...
5 4
H T T P 8 0
W e b -S e rv e r
j
...
k
...
T C P IP -A d r = y
< S Y N > [Q P = i, Z P = 8 0 , S E G = K ] < S Y N , A C K > [Q P = j, Z P = i, S E G = N , A C K = K + 1 ]
7
H T T P y
H T T P x
< A C K > [Q P = i, Z P = j, S E G = K + 1 , A C K = N + 1 ] T C P -V e r b in d u n g
6
T C P R e c h n e r B 6 S o c k e t (y , j)
Abb. 3.4-5: Aufbau einer TCP-Verbindung, a) interne Schritte im Rechner, b) Ablauf von TCP
www.wiwobooks.com
ACK: ACKnowledgement, QP: Quellport, SEG: SEQuenznummer, ZP: Zielport
Aufbau einer TCP-Verbindung
Beim Aufbau einer TCP-Verbindung sind folgende Schritte zu unterscheiden: 1.
Die Applikation Web-Client im Rechner A wendet sich an das Betriebssystem, um einen Port für die Kommunikation mit einem Web-Server zu erhalten.
2.
Das Betriebssystem ordnet dem Web-Client die Portnummer i zu. Damit wird der aktive Prozess HTTPa an die TCP-Instanz in der Transportschicht über den Port i angebunden.
3.
Um eine TCP-Verbindung zu initiieren, generiert die TCP-Instanz in Rechner A durch das Setzen des Kontroll-Flag SYN auf 1 ein <SYN>-Paket. Durch Absenden dieses Pakets wird hier seitens des Rechners A der Aufbau einer TCP-Verbindung initiiert. Im TCP-Header des 3 <SYN>-Pakets wird als Quellport die Portnummer i eingetragen. Der Well Known Port von HTTP ist 80. Daher wird 80 als Zielport angegeben. Hiermit teilt der Quellrechner A dem Zielrechner B mit, dass die neue „ankommende“ TCP-Verbindung an die HTTPInstanz übergeben werden muss. Im TCP-Header wird als SEQ (Sequence Number) die ISN = K angegeben. Damit erfährt der Zielrechner, dass der Rechner A die Nummerierung von seinerseits gesendeten Datenbytes mit K beginnt.
4.
Die HTTP-Instanz in Rechner B wendet sich an das Betriebssystem, um einen separaten Port für die Kommunikation mit dem Web-Client auf Rechner B zu erhalten.
5.
Das Betriebssystem ordnet den Port j zu. Folglich wird die Kommunikation zwischen dem Web-Client auf Rechner A und dem Web-Server auf Rechner B über den Port j verlaufen. Der Port j wird vom Prozess HTTPx bedient.
6.
Der Prozess HTTPx antwortet dem Web-Client mit dem <SYN,ACK>-Paket, in dem die beiden Kontroll-Flags SYN und ACK auf 1 gesetzt sind – siehe Abbildung 3.4-4. Dieses Paket wird vom Port j (Quellport in Rechner B) zum Port i (Zielport in Rechner A) transportiert.
3
Der Well Known Port dient als Kontakt bzw. als Begrüßungsport eines Anwendungsprotokolls.
95
3.5 Einsatz von DNS Daher fungieren diese beiden Ports als Endpunkte der neuen TCP-Verbindung. Als SEQ im TCP-Header wird nun die ISN = N angegeben. Damit teilt Rechner B dem Rechner A mit, dass er die Nummerierung von seinerseits gesendeten Datenbytes mit N beginnt. Mit der Angabe der Zahl K+1 im Feld Acknowledgement Number – d.h. ACK = K+1 – bestätigt Rechner B die ISN = K von Rechner A. Mit ACK = K+1 teilt Rechner B dem Rechner A mit, dass er nun das Datenbyte mit der Nummer K+1 erwartet.
7. Auf das <SYN,ACK>-Paket antwortet der Rechner A mit dem -Paket, in dem nur das Kontroll-Flag ACK auf 1 gesetzt ist. Mit der Angabe ACK = N+1 bestätigt Rechner A die ISN = N von Rechner B. Mit SEQ = K+1 signalisiert Rechner A dem Rechner B, dass das erste Datenbyte von ihm die Nummer K+1 hat. Nach der Bearbeitung des -Pakets in Rechner B wird der Aufbau der TCP-Verbindung – also eine Verständigung in Bezug auf den Verlauf der Kommunikation zwischen ihnen – abgeschlossen. Die Endpunkte der TCP-Verbindung repräsentieren Paare (IP-Adresse, Port-Nummer) – Sockets genannt. Ein Socket identifiziert weltweit eindeutig eine Applikation. Mit ihm teilt man mit, um welche Applikation (Port-Nr.) es sich handelt und auf welchem Rechner (IP-Adresse) sie sich befindet. Eine TCP-Verbindung zwischen zwei Applikationen ist vollduplex und setzt sich aus zwei entgegengerichteten, unidirektionalen Verbindungen zusammen. Sie stellt eine zweispurige virtuelle Straße dar. Jede Spur beginnt am Quell-Socket und endet am Ziel-Socket.
Interpretation einer TCP-Verbindung
Der Abbau einer TCP-Verbindung wird von einer Seite mit einem TCP-Paket initiiert, in dem das FIN-Flag im TCP-Header auf 1 gesetzt wird, sodass man dieses TCP-Paket als -Paket bezeichnet. Dies wird von der Gegenseite durch ein -Paket mit dem gesetzten ACK-Flag positiv bestätigt. Die positive Bestätigung erfolgt hier durch die Angabe der Quittungsnummer ACK=m+1, d.h. der empfangenen Sequenznummer SEQ=m plus 1. Damit wird eine gerichtete Verbindung vom Rechner A zu Rechner B abgebaut.
Abbau einer TCP-Verbindung
www.wiwobooks.com
Der Verbindungsabbau in der Gegenrichtung wird mit dem TCP-Paket, in dem die beiden FINund ACK-Flags gesetzt sind, d.h. mit dem -Paket, begonnen. Die positive Bestätigung des -Pakets erfolgt hier durch die Quittung ACK=n+1 der empfangenen Sequenznummer SEQ = n. Nach Bestätigung dieses -Pakets durch die Gegenseite wird der Verbindungsabbau beendet.
3.5
Einsatz von DNS
Bei der Nutzung von Internet-Diensten, wie z.B. VoIP mit SIP oder E-Mail, Ziel von gibt der Benutzer nicht die IP-Adresse des Zielrechners an, sondern eine ent- DNS sprechende VoIP-Adresse als SIP-URI (Uniform Resource Identifier) bzw. eine E-Mail-Adresse. In diesen Adressen ist der Name des Ziel-Rechners bzw. der Ziel-Internet-Domain enthalten. Dies erfordert aber, dass irgendwie und irgendwo die Zuordnung Rechnername IP-Adresse abgelegt werden muss. Ein Rechnername – auch als Hostname bezeichnet – muss daher auf seine IPAdresse aufgelöst werden. Um Rechnernamen in IP-Adressen zu „übersetzen“, 4 wurde das DNS (Domain Name System) entwickelt . DNS hat den Vorteil, dass sich Benutzer die IP-Adressen von Rechnern im Internet nicht merken müssen, 4
Dies war zumindest das ursprüngliche Ziel der DNS-Entwicklung. Heute dient DNS fast als „universelles Internet-Auskunftssystem“ – siehe z.B. Abschnitt 3.5.4.
96
3
TCP/IP- und VoIP-Protokolle
sondern stattdessen deren Namen verwenden können. Die IP-Adresse eines Rechners im Internet kann beim DNS abgefragt werden. Client/ ServerPrinzip
Das DNS funktioniert eigentlich nach dem Client/Server-Prinzip. Der DNSClient ist eine Software auf dem Rechner eines Benutzers, mit deren Hilfe DNS-Server – als Nameserver bezeichnet – abgefragt werden, um Rechnernamen in IP-Adressen zu übersetzen. Der DNS-Server ist ein Programm in einem dedizierten Rechner, das auf eine entsprechende Datei – Resource Record (RR) genannt – zugreift, um die Anfragen des Clients zu beantworten. Sämtliche Namen von Rechnern, die in unterschiedlichen und weltweit verteilten Name-Servern gespeichert sind, bilden den sog. DNS-Namensraum.
3.5.1 Aufbau des DNS-Namensraums InternetDomains
Das DNS ist eine baumförmige Vernetzung einer Vielzahl von Nameservern, die eine weltweit verteilte Datenbank bilden. Diese Vernetzung stellt einen DNS-Datenbaum dar. Abbildung 3.5-1 zeigt einerseits das Prinzip der Vernetzung einzelner Nameserver und andererseits das Prinzip der Aufteilung des ganzen Internet auf die sog. Internet-Domains – im Weiteren auch kurz Domains (Domänen) genannt.
www.wiwobooks.com R o o t
a rp a
e 1 6 4
...e d u
ip 6
in -a d d r
c o m
...
o rg
...
ib m
h p ...
...
...
...
a t
F Q D N h s - f u ld a .d e
F Q D N in f o r m a tik .h s - f u ld a .d e
D o m a in s v o n O rg a n is a tio n e n
...
d e ... ...
...
u s
...
...
z w
T o p -L e v e lD o m a in s
h s -fu ld a ... in fo rm a tik ... N a m e se rv e r
D o m a in h s - f u ld a .d e
S e c o n d -L e v e lD o m a in s
S u b d o m a in in f o r m a tik .h s - f u ld a .d e
G e o g ra p h is c h e D o m a in s
Abb. 3.5-1: Prinzip der Aufteilung des ganzen Internet auf Domains und die Domain informatik.hs-fulda.de
Domains und Subdomains
5
Der DNS-Baum besitzt ganz oben eine einzige Wurzel (Root), die man einfach Root nennt. Für den Namen der Root ist „.“(Punkt) reserviert. Wie bei jedem anderen Dateisystem kann der DNS-Baum mehrere Abzweigungen ha5
Die DNS-Root bilden 13 vernetzte Server. Diese werden von unterschiedlichen Organisationen betrieben – siehe http://root-servers.org.
97
3.5 Einsatz von DNS
ben. Jeder Knoten des Baumes repräsentiert eine Domain – genauer gesagt, eine Top-Level-Domain – wie ein Verzeichnis in einem Dateisystem. Jede TopLevel-Domain (so wie jedes Verzeichnis) kann in weitere Teile – die sog. Second-Level-Domains – untergliedert werden. Diese Teile werden im DNS als Subdomains bezeichnet und entsprechen den Unterverzeichnissen eines Dateisystems. Eine Subdomain wird – genau wie ein Unterverzeichnis – als Unterknoten des übergeordneten Knotens interpretiert. Jeder Knoten des Baums wird mit einem einfachen Namen versehen. Der vollständige Domainname, der sog. FQDN (Full Qualified Domain Name), besteht aus den Namen einzelner Knoten bis zur Root. Der Name eines Knotens setzt sich somit aus den einzelnen Namen auf dem Pfad zum Root-Knoten zusammen, wobei die einzelnen Namen durch einen Punkt voneinander getrennt werden. Beispielsweise setzt sich der Domainname hs-fulda.de aus dem Namen hs-fulda und dem Namen der Top-Level-Domain de zusammen.
Der vollständige DomainName als FQDN
Man spricht auch von vollständigen Rechnernamen. Der vollständige Name eines Rechners setzt sich aus seinem Hostnamen und aus dem vollständigen Namen der Domain, in der sich dieser Rechner befindet, zusammen. Beispielsweise bildet mond.informatik.hs-fulda.de den vollständigen Namen des Rechners mond in der Subdomain informatik.hs-fulda.de.
Der vollständige Rechnername
www.wiwobooks.com
Jeder Nameserver SNi muss seinem übergeordneten Nameserver SNi-1 bekannt Baustruktur sein. Hierfür muss die IP-Adresse des Nameservers SNi in einem sog. A- durch Glue Records beim Nameserver SNi-1 abgelegt werden (vgl. Abb. 3.5-2). Auf diese Weise wird die eigentliche Baumstruktur von DNS gebildet. Die in Nameservern in A-Records abgelegten IP-Adressen der untergeordneten Nameserver bezeichnet man als Glue (Leim). Im Root-Server sind beispielsweise die Verweise auf die Nameserver von Top-Level-Domains enthalten.
3.5.2 Resource Records Die Informationen in Nameservern im DNS werden in Form atomarer Einheiten – die sog. Resource Records (RRs) bilden – abgespeichert. Ein Nameserver beinhaltet die RRs des ihm dauerhaft zugeordneten Namensraums, der typischerweise als Zone bezeichnet wird.
Begriff: Zone
Die „klassischen“ RRs haben im Allgemeinen folgende Struktur [RFC 1034]:
Struktur von RRs
[]
Die einzelnen Komponenten sind hier wie folgt zu interpretieren: NAME: Name des Objekts (z.B. vollständiger Rechnername), über das der RR bestimmte Informationen liefert; TTL: Time To Live [sek] als Gültigkeitsdauer des RR (optional); CLASS: Klasse von RR; TYP: Typ als Zuordnungsschema des RR; RDATA: Resource Data als Daten, die der RR als Ergebnis einer Abfrage liefert;
98
3
TCP/IP- und VoIP-Protokolle
Beispiel: Der Nameserver der Domain abc.de kann u.a. folgende RRs enthalten: [] srv1.abc.de. www.abc.de. 7.0.30.172.in-addr.arpa. abc.de. abc.de.
Zuordnung NAME RDATA
IN IN IN IN IN
A CNAME PTR NS MX
172.30.0.7 srv1.abc.de srv1.abc.de namesrv.abc.de mailsrv.abc.de
RDATA enthält. RR kann man als Datensatz in einer Datei ansehen, der die Zuordnung NAME Hier sagt NAME, um welchen RR es sich handelt, und RDATA stellt den Inhalt dar, der als Ergebnis einer RR-Abfrage geliefert wird.
Beispiel: RR vom Typ A mit NAME = sv1.abc.de und RDATA = 172.30.0.7 enthält die Zuordnung srv1.abc.de 172.30.0.7, die besagt, dass der Rechner mit dem Namen sv1.abc.de die IPv4-Adresse 172.30.0.7 hat. Derselbe Rechner kann aber ebenso unter seinem Alias-Namen www.abc.de angesprochen werden. Dies liefert – auf Basis von RRs CNAME und A – die gleiche IP-Adresse: www.abc.de sv1.abc.de 172.30.0.7.
Typen von RRs
Die wichtigsten Typen von RRs sind: A – ordnet eine IPv4-Adresse einem vollständigen Rechnernamen zu. AAAA – ordnet eine IPv6-Adresse einem vollständigen Rechnernamen zu – ähnlich wie A. CNAME (Canonical NAME) – gibt für einen Alias-Namen einen vollständigen Rechnernamen. MX (Mail eXchange) – ordnet den vollständigen Namen eines E-Mail-Servers einem vollständigen Domainnamen zu.
www.wiwobooks.com
NS (Name-Server) – gibt den vollständigen Namen eines autorisierten Nameservers (NS) für
eine Domain. PTR (PoinTeR) – weist einer IP-Adresse bei einer sog. inversen Abfrage einen vollständigen Rechnernamen zu. NAPTR (Naming Authority PoinTeR) – gibt verfügbare Dienste in einer Domain an. NAPTR
nutzt man bei VoIP mit SIP. NAPTR wird u.a. abgerufen, um das Protokoll UDP, TCP oder TLS für den Transport von SIP-Nachrichten zu bestimmen. SRV (SeRVer) – gibt den vollständigen Namen eines speziellen Servers in einer Domain an. SRV nutzt man bei VoIP mit SIP, um den Namen des SIP-(Proxy-)Servers zu bestimmen.
NAPTR und SRV wurden erst im Jahr 2000 spezifiziert und werden bei VoIP mit SIP verwendet.
A-Query
Die wichtigste Frage an das DNS lautet: Welche IP-Adresse existiert für den vollständigen Namen eines Zielrechners? Dies wird als Namensauflösung (name resolution) bzw. als A-Query (A-Abfrage) bezeichnet, weil die Zuordnung Rechnername IP-Adresse in einem DNS-Server in einem Resource Record vom Typ A – kurz A-Record – abgespeichert ist.
3.5.3 Beispiel für eine Namensauflösung Abbildung 3.5-2 illustriert die Ermittlung der IP-Adresse für www.informatik.hs-fulda.de. Der Nameserver NSi ist dem ihm übergeordneten Nameserver NSi-1 bekannt, somit kann ein Nameserver eine Abfrage nach jedem beliebigen Rechnernamen an den Root-Nameserver richten, der ihn danach auf den nächsten Nameserver verweist.
99
3.5 Einsatz von DNS
N S
2
N S
3
A 1
N S
6
5 x
1
N S
4 In tr a n e t
0
D N S S e rv e r
N S
d e ... ... 2
3
R o o t
... ...
D o m a in N a m e S y s te m
h s -fu ld a
in f o r m a tik .h s - f u ld a
N a m e se rv e rs (N S )
Abb. 3.5-2: Ermittlung der IP-Adresse für www.informatik.hs-fulda.de Im vorliegenden Beispiel sind folgende Schritte zu unterscheiden: 1.
Der sog. Resolver in Rechner A leitet eine Abfrage an den lokalen DNS-Server NSx im Intranet: Wie lautet die IP-Adresse für www.informatik.hs-fulda.de?
2.
Sofern der lokale Server NSx in seinem Cache die Antwort nicht enthält, ermittelt er zuerst, welcher Nameserver für die Top-Level-Domain de zuständig ist. Daher leitet er die Anfrage an einen Root-Server NS0. Dieser kennt – aus Glue in seiner Datenbank – den für die TopLevel-Domain de autorisierten Nameserver NS1 und verweist somit auf NS1.
3.
Der NSx sendet nun die Anfrage an den Nameserver NS1 der Top-Level-Domain de. NS1 stellt fest, dass die Domain hs-fulda.de vom Nameserver NS2 betreut wird und gibt diese Information an den NSx weiter.
4.
Der NSx sendet die Anfrage an den NS2 der Domain hs-fulda.de. Dieser stellt fest, dass der NS3 für informatik.hs-fulda.de zuständig ist, und verweist den NSx auf den NS3.
5.
Der NSx sendet die Anfrage an den Nameserver NS3 der Subdomain informatik.hsfulda.de. NS3 stellt aber fest, dass www.informatik.hs-fulda.de ein Alias – d.h. ein
www.wiwobooks.com
CNAME (Canonical NAME) – ist. Daher ermittelt NS3 zuerst aus dem entsprechenden CNAME-Record den vollständigen Rechnernamen srv1.informatik.hs-fulda.de, danach aus dem A-Record die IP-Adresse für diesen Rechnernamen, und anschließend übermittelt er diese an den NSx. Die Ermittlung der IP-Adresse lässt sich vereinfacht so darstellen: www.informatik.hs-fulda.de CNAME srv1.informatik.hs-fulda.de A
6.
IP-Adresse
Der Resolver im Rechner A erhält nun vom lokalen Nameserver NSx die dem Rechner www.informatik.hs-fulda.de zugeordnete IP-Adresse und kann somit ein IP-Paket an den Rechner srv1 in der Subdomain informatik.hs-fulda.de senden.
Die in Abbildung 3.5-2 gezeigte DNS-Abfrage wird als rekursive Abfrage bezeichnet.
3.5.4 Ermittlung des SIP-Proxy in einer anderen Domain DNS spielt eine wichtige Rolle bei VoIP mit SIP als Signalisierungsprotokoll. Wie wir in Abschnitt 7.1.5 näher erläutern, muss ein SIP-Proxy in der Domain des Anrufers, um eine Session für VoIP zum Rechner in einer anderen Domain
Resolver
100
3
TCP/IP- und VoIP-Protokolle
initiieren zu können, zuerst den SIP-Proxy in der Domain des Angerufenen ermitteln. Abbildung 3.5-3 illustriert dieses Problem näher.
D o m a in a b c .d e
W e lc W e lc W e lc Ü b e r
h e n H h e IP h e s T w e lc
o s tn a m e h a -A d re sse h a ra n s p o rtp ro h e n P o rt is t
t d e r S IP -P r t S IP -P ro x y to k o ll s o ll S S IP e rre ic h b
o x in IP a r ?
y in x y z .d e ? x y z .d e ? n u tz e n ?
D o m a in x y z .d e
S IP -P ro x y
S IP -P ro x y
S IP -N a c h ric h t IN V IT E A lic e
B o b
A u fb a u e in e r S e s s io n fü r V o IP
Abb. 3.5-3: Problem bei der Ermittlung des SIP-Proxy in einer anderen Domain
Was muss ein SIPProxy bestimmen?
Der SIP-Proxy aus der Domain abc.de des Anrufers Alice muss wissen, welchen Hostnamen der SIP-Proxy in der Domain xyz.de hat, damit er mit Hilfe der A-Query dessen IP-Adresse beim DNS abfragen kann. Weil SIP außer UDP auch andere Transportprotokolle wie TCP, SCTP und TLS nutzen kann – siehe Abbildung 7.1-1 –, muss der SIP-Proxy aus der Domain abc.de auch ermitteln, welches Transportprotokoll verwendet werden soll. Das in Abbildung 3.53 gezeigte Problem lässt sich mit Hilfe von DNS vollständig lösen und RFC 3263 beschreibt, wie. Falls die SIP-Zieladresse – siehe Abbildung 7.1-2 – das Transportprotokoll nicht explizit angibt, muss zuerst dieses Protokoll bestimmt werden.
www.wiwobooks.com
RRs vom Typ NAPTR
Der SIP-Proxy einer Domain kann mehrere Transportprotokolle unterstützen. Die entsprechende Information lässt sich in Resource Records (RRs) vom Typ NAPTR (Naming Authority PoinTeR) – siehe RFC 3403 – in der sog. Zonendatei der betreffenden Domain abspeichern. Abbildung 3.5-4 zeigt, welche Angaben in NAPTR-RRs in der Domain xyz.de enthalten sein können. S R V -R R m u ss a b g e fra g t w e rd e n $ O R I G I N x y z .d e . IN IN IN
N A P T R N A P T R N A P T R C la s s
O rd e r 1 0 2 0 4 0 T y p e
P re f 5 0 5 0 5 0
S e rv ic e -B e z e ic h n u n g F la g s " s" " s" " s"
S e rv " S IP S " S IP + " S IP +
ic e + D 2 T " D 2 U " D 2 T "
S e rv ic e -S p e z ifik a tio n R e g " " "
e x p "
" "
R _ s ip _ s ip _ s ip
e p la c e m s ._ tc p .x ._ u d p .x ._ tc p .x y
e n t y z .d e . y z .d e . z .d e .
_ S e r v ic e ._ P r o to c o l.D o m a in n a m e
Abb. 3.5-4: RRs vom Typ NAPTR der Domain xyz.de mit VoIP-betreffenden Angaben
Wie hier aus den RRs abzulesen ist, kommen in der Domain xyz.de die folgenden drei Möglichkeiten in Frage: SIP über UDP, SIP über TCP und SIP über TLS (SIPS). Die Angaben in RRs sind wie folgt zu interpretieren:
3.5 Einsatz von DNS
101
Order – gibt an, in welcher Reihenfolge die einzelnen RRs auszuwählen sind. RRs mit kleineren Order-Werten werden bevorzugt. Pref (Preference) – legt die Präferenz des RR unter RRs mit gleicher Order fest. Flag – gibt an, welcher RR als Nächster abgefragt werden soll. s verweist hier darauf, dass im nächsten Schritt ein RR vom Typ SRV abgefragt werden muss. Service – Angabe eines Dienstes. Dieses Feld kann bei VoIP mit SIP die Form SIP+D2X oder SIPS+D2X haben, wobei der Buchstabe X durch U, T oder S ersetzt wird. Ist SIP+D2T, wird das TCP für SIP verwendet. Ist SIP+D2U, ist das UDP zu verwenden. Auf SIP über SCTP wird mit SIP+D2S verwiesen. SIPS verweist darauf, dass TLS – also ein gesicherter Transportdienst – für SIP einzusetzen ist.
SIP über UDP, TCP, SCTP oder TLS
Regexp (Regular expression) – In RRs mit Flag s wird hier " " eingetragen (s. Abb. 3.5-4). In RRs mit anderen Flags kann eine Zeichenkombination eingetragen werden. Replacement – Die hier angegebene Zeichenkette enthält den Service, das Transportproto-
koll und den Domainnamen – also die Service-Spezifikation. Diese Spezifikation ist das Ziel einer NAPTR-Query und wird im nächsten Schritt verwendet, um einen RR vom Typ SRV anzufragen, d.h. eine SRV-Query durchführen zu können – siehe Abbildung 3.5-6.
Nachdem ein RR vom Typ NAPTR abgefragt wurde und damit die Service- RRs vom Typ Spezifikation bekannt ist, kann nun ein RR vom Typ SRV abgefragt werden, SRV um den Namen des SIP-Proxy in dieser Domain zu ermitteln. Abbildung 3.5-5 zeigt, welche Angaben SRV-RRs enthalten kann (s. RFC 2782).
www.wiwobooks.com
$ O R I G I N x y z .d e . _ s ip s ._ tc p .x y z .d e . _ s ip ._ u d p .x y z .d e . _ s ip ._ tc p .x y z .d e
C la s s IN IN IN
T y p e S V R S V R S V R
V o lls tä n d ig e r S e r v ic e -N a m e
P r io 1 0 2 0 4 0
W e ig th 5 0 5 0 5 0
P 5 0 5 0 5 0
o rt 6 0 6 0 6 0
T a r s ip p ro s ip p ro s ip p ro
g e x y x y x y
t .x y z .d e . .x y z .d e . .x y z .d e .
V o lls tä n d ig e r S e r v e r n a m e
Abb. 3.5-5: RRs vom Typ SRV der Domain xyz.de mit VoIP-betreffenden Angaben Im vorliegenden Beispiel unterstützt der SIP-Proxy in der Domain xyz.de als Rechner mit dem vollständigen Rechnernamen sipproxy.xyz.de die drei folgenden Möglichkeiten: SIP über UDP (_sip._udp.xyz.de), SIP über TCP (_sip._tcp.xyz.de) sowie SIP über TLS (_sips._tcp.xyz.de). Die weiteren Angaben in RRs sind wie folgt zu interpretieren: Prio (Priority) – gibt an, in welcher Reihenfolge die einzelnen RRs auszuwählen sind. Nied-
rigere Werte werden zuerst abgefragt. Weigth – Haben mehrere RRs gleiche Priorität, dann legt Weigth ihre Präferenz fest. Port – Angabe des Port von SIP. Target – Hier wird der vollständige Rechnername des SIP-Proxy angegeben. Diese Angabe wird verwendet, um eine A-Query durchzuführen und so die IP-Adresse anzufragen.
Abbildung 3.5-6 zeigt, welche DNS-Abfragen nötig sind, damit der SIP-Proxy Ermittlung in der Domain des Anrufers die SIP-Nachricht INVITE an den SIP-Proxy in des SIPProxy der Domain des Angerufenen weiterleiten kann – vgl. Abbildung 3.5-3.
102
3
TCP/IP- und VoIP-Protokolle
S IP P ro x y
a b c .d e
In te rn e t
IN V IT E E rm ittlu n g d e s T ra n s p o rtp ro to k o lls E rm ittlu n g d e s S e rv e rn a m e n s E rm ittlu n g d e r S e rv e rIP -A d re sse
x y z .d e
B o b
R e s p o n s e [ _ s ip s ._ tc p .x y z .d e , ...] B
C
S IP P ro x y
Q u e r y [ N A P T R , x y z .d e , ...] A
A lic e
D N S
Q u e r y [ S V R , _ s ip s ._ tc p .x y z .d e , ...] R e s p o n s e [ s ip p r o x y .x y z .d e , 5 0 6 0 , ...] Q u e r y [ A , s ip p r o x y .x y z .d e , ...] R e s p o n s e [ I P - A d r e s s e , ...] IN V IT E
IN V IT E
Abb. 3.5-6: Bestimmung des Transportprotokolls und Ermittlung des SIP-Proxy Die in Abbildung 3.5-6 gezeigten DNS-Abfragen sind wie folgt zu interpretieren: A
NAPTR-Query – Mit einer DNS-Nachricht Query mit der Angabe NAPRT und xyz.de in ihrer Question Section wird ein RR vom Typ NAPRT im Nameserver der Domain xyz.de abgefragt. Die Service-Spezifikation _sips._tcp-xyz.de als Ergebnis dieser Abfrage wird in der Answer Section der DNS-Nachricht Response übergeben.
B
SRV-Query – Durch das Absenden von Query mit SRV und _sips._tcp-xyz.de in ihrer Question Section wird ein RR vom Typ SRV in der Domain xyz.de abgefragt. Das Ergebnis dieser Abfrage – d.h. der Name des SIP-Proxy sipproxy.xyz.de und die SIP-Portnummer 5060 – wird in Response übermittelt.
C
A-Query – Nachdem vom SIP-Proxy in der Domain xyz.de der vollständige Name sipproxy.xyz.de ermittelt wurde, wird nun seine IP-Adresse beim DNS abgefragt.
www.wiwobooks.com
3.6
Protokolle für VoIP – eine Übersicht
Wenn man von VoIP spricht, werden oft nur der Standard H.323 von dem ITU-T und das Protokoll SIP (Session Initiation Protocol) von der IETF erwähnt. Für die Realisierung von VoIP sind aber weitere Protokolle erforderlich. Bei VoIP sind folgende Klassen der Protokolle zu unterscheiden: Protokolle zur Sprachübermittlung – Da die Sprachkommunikation in Echtzeit verläuft, sind spezielle Protokolle für die Übermittlung von Sprache über IP-Netze nötig. Signalisierungsprotokolle – Protokolle für den Auf- und Abbau von Verbindungen zwischen zwei IP-Telefonen. Protokolle für die Steuerung von Media Gateways – Diese Protokolle sind nötig, um die klassischen TK-Systeme und -Netze, wie z.B. das ISDN, mittels diverser Gateways mit IP-Netzen zu integrieren.
3.6 Protokolle für VoIP – eine Übersicht
Für die Übermittlung von Sprache in IP-Netzen verwendet man RTP (Real-time Transport Protocol) und RTCP (RTP Control Protocol).
103 Protokolle für die Sprachübermittlung
Nach RTP werden die Dateneinheiten, die sog. RTP-Pakete, aus einem Bitstrom mit der digitalisierten Sprache gebildet und in IP-Paketen transportiert. RTP dient als Transportprotokoll nicht nur für Sprache, sondern für alle Echtzeitmedien, also auch für Video. Da RTP keine Quittungen (Bestätigungen) verwendet, kann der Empfänger dem Sender nicht mitteilen, wie bzw. ob überhaupt die Sprache in Form von IP-Paketen bei ihm ankommt. Das Protokoll RTCP gleicht diesen Nachteil aus. RTCP verwendet man, um bestimmte Informationen in Form von Berichten (Reports) zwischen Empfänger und Sender auszutauschen, um sich gegenseitig darüber zu informieren, wie die Übermittlung der Sprache verläuft. RTCP wird immer parallel zu RTP eingesetzt, um u.a. die Qualität der Sprachübermittlung (sog. Quality of Service) zu überwachen. RTCP kann als Monitoring-Protokoll angesehen werden. Auf RTP und RTCP geht Kapitel 5 detailliert ein. In den klassischen TK-Netzen (Telefonnetze, ISDN) muss vor der Übertragung Signalisievon Sprache zwischen zwei Telefonen zuerst eine Verbindung aufgebaut und rungsnach der Übertragung wieder abgebaut werden. Die Übermittlung der Steue- protokolle rung für diese Zwecke bezeichnet man als Signalisierung der Anrufe. Die Regeln, nach denen eine Signalisierung verläuft, beschreibt ein Signalisierungsprotokoll. Ein Beispiel dafür ist das D-Kanal-Protokoll im ISDN (s. Abschnitt 2.3). In IP-Netzen muss vor der Übertragung von Sprache zunächst eine Verbindung zwischen zwei IP-Telefonen aufgebaut und nach der Sprachübertragung wieder abgebaut werden. Hierfür stehen zwei miteinander konkurrierende Ansätze zur Verfügung:
www.wiwobooks.com
die Protokolle H.225.0 und H.245 aus dem Standard H.323 und das Protokoll SIP (Session Initiation Protocol). Mit diesen beiden Ansätzen sind fast die gleichen technischen Probleme lösbar. H.323 unter dem Titel „Packet-based multimedia communication systems“ H.323 als stellt ein sehr komplexes Rahmenwerk (Framework) dar und wird somit auch Rahmenwerk als „Umbrella-Standard“ bezeichnet. Die wichtigsten Bestandteile von H.323 sind folgende zwei Signalisierungsprotokolle als H.323-SIG: H.225.0: Call signalling protocols and media stream packetization for packet-based multimedia communication systems H.245: Control protocol for multimedia communication Bemerkung: H.323-SIG beschreibt hauptsächlich, wie die ISDN-Signalisierung nach dem D-Kanal-Protokoll über TCP-Verbindungen realisiert werden kann. Bei H.323SIG übernimmt das TCP die Rolle vom LAPD (s. Abb. 2.3-1 und Abschnitt 2.3).
104
3
TCP/IP- und VoIP-Protokolle
Das Konzept und die Einsatzmöglichkeiten von H.323 erläutert Kapitel 6. Multimediale Kommunikation mit SIP
Mit SIP spezifiziert die IETF ein Protokoll, das die Signalisierung der Anrufe für die multimediale Kommunikation in IP-Netzen ermöglicht. SIP ist ein viel einfacheres Protokoll als H.323-SIG. Es basiert auf den gleichen Prinzipien, die man beim Protokoll HTTP (HyperText Transfer Protocol) nutzt. Somit kann SIP als ein Verwandter vom HTTP angesehen werden. Das Konzept und die Anwendungen von SIP werden in Kapitel 7 dargestellt.
IAX bei Asterisk
Bei VoIP mit Hilfe von Asterisk kann das Protokoll IAX (Inter-Asterisk eXchange) eingesetzt werden. Die Version 2 von IAX – kurz IAX2 – wird im Internet-Draft draft-guy-iax spezifiziert. IAX ist ein hybrides Protokoll, d.h. es dient sowohl zur Übermittlung von Echtzeitmedien (Voice, Video) als auch zur Signalisierung. IAX2 nutzt das unzuverlässige Protokoll UDP für den Transport seiner Nachrichten, die man Frames nennt. Bei IAX2 unterscheidet man zwei Kategorien von Nachrichten: zuverlässige und unzuverlässige. Die zuverlässigen Nachrichten – als Full Frames bezeichnet – werden u.a. zur Übermittlung von Signalisierungsangaben verwendet und von der Empfangsseite bestätigt. Die unzuverlässigen IAX2-Nachrichten werden hauptsächlich zum Transport von Echtzeitmedien verwendet und diese stellen sog. Mini-Frames bzw. Meta-Frames dar und werden von der Empfangsseite nicht bestätigt. IAX2 hat viel Gemeinsames mit dem in Abschnitt 3.7 kurz dargestellten Transportprotokoll SCTP.
6
www.wiwobooks.com
Protokolle für Steuerung von Media Gateways
Für VoIP im Verbund von IP-Netzen mit dem ISDN bzw. mit einem digitalen Telefonnetz müssen spezielle Gateways eingerichtet werden (s. Abb. 8.1-1). Sie werden Media Gateways oder VoIP-Gateways genannt. Ein Media Gateway stellt eine Komponente zwischen einem IP-Netz und einem klassischen System bzw. Endgerät für die Sprachkommunikation dar. Ein derartiges Gateway hat u.a. die Aufgabe, bei der Sprachübermittlung in Richtung des IPNetzes die Sprachsignale in IP-Pakete umzuwandeln und bei der Übermittlung der Sprache in die Gegenrichtung aus den empfangenen IP-Paketen mit digitaler Sprache die entsprechenden Sprachsignale zu generieren. Für die Ansteuerung von VoIP-Gateways stehen folgende Protokolle zur Verfügung: MGCP (Media Gateway Control Protocol) Megaco (Media Gateway Control) Für die Sprachübermittlung in Form von IP-Paketen über ein IP-Netz müssen virtuelle Verbindungen zwischen Media Gateways auf- und abgebaut werden. Hierfür kann H.323-SIG bzw. SIP verwendet werden. MGCP und Megaco werden in Kapitel 8 ausführlich dargestellt. 6
Als Asterisk bezeichnet man eine komplett softwarebasierende IP-TK-Anlage auf OpenSource Basis – siehe http://www.asterisk.org oder http://www.freeswitch.org
3.7 Bedeutung des Protokolls SCTP
3.7
105
Bedeutung des Protokolls SCTP
Werden IP-Netze für die Sprachübermittlung genutzt, so müssen sie mit den öffentlichen TK-Netzen (wie z.B. mit ISDN, Mobilfunknetzen GSM und UMTS) entsprechend integriert werden. Hierfür müssen z.B. die Nachrichten des Signalisierungssystems Nr. 7 (SS7) über IP-Netze transportiert werden. Diese Integration stellt besondere Anforderungen an das Transportprotokoll. Weil TCP und UDP diese Anforderungen nicht vollständig erfüllen können, wurde das neue Transportprotokoll SCTP (Stream Control Transmission Protocol) entwickelt und im IETF-Dokument RFC 4960 spezifiziert. SCTP ermöglicht eine gesicherte Übertragung von Nachrichten in mehreren unabhängigen sog. SCTP-Streams. Ein Stream lässt sich als unidirektionale, virtuelle Verbindung interpretieren. SCTP kann als „erweiterte“ Version des TCP angesehen und auch für die Übermittlung „normaler“ Daten verwendet werden. Abbildung 3.7-1 zeigt SCTP innerhalb der Protokollfamilie TCP/IP. V e rb in d u n g s o rie n tie rte A n w e n d u n g s p ro to k o lle D a te n s trö m e , S S .7 - N a c h r ic h te n , ...
T ra n s p o rts c h ic h t
H T T P , S M T P , F T P , H .2 2 .5 , H .2 4 5 , ...
V A n w D H C P , S IP , M G
e rb e n d S N C P
in u M ,
d u n g s n g sp ro P , R T M E C A
lo s e to k o lle P , R T C P , C O , ...
... ... ... www.wiwobooks.com S TC CT PP
N e tz w e rk s c h ic h t
T C P
U D P
I P Ü b e r m ittlu n g s n e tz e ( L A N s , W A N s , ...)
Abb. 3.7-1: Protokollfamilie TCP/IP mit dem Transportprotokoll SCTP
SCTP ist ein verbindungsorientiertes Transportprotokoll. Das Konzept einer SCTPvirtuellen SCTP-Verbindung – als Assoziation bezeichnet – ist jedoch allge- Besondermeiner als eine TCP-Verbindung. Eine SCTP-Assoziation (-Association) um- heiten fasst die gesamte Kommunikation zwischen zwei SCTP-Instanzen mit möglicherweise mehreren IP-Adressen. SCTP beinhaltet Maßnahmen gegen die sog. Denial of Service-Angriffe (DoS-Angriffe), die zum Ziel haben, die Verfügbarkeit eines Dienstes (Systems) zu blockieren bzw. lahmzulegen.
3.7.1 SCTP versus UDP und TCP SCTP wurde entwickelt, um einige Schwächen der beiden klassischen Transportprotokolle UDP und TCP auszugleichen. Um welche Schwächen handelt es sich? UDP ist ein Protokoll, das einen verbindungslosen Transportdienst zur Verfügung stellt, und eignet sich daher für die Übertragung von Nachrichten, die empfindlich gegenüber Verzögerungen
Schwächen von UDP
106
3
TCP/IP- und VoIP-Protokolle
sind. Es bietet jedoch keinen zuverlässigen Transportdienst. Das Erkennen duplizierter Nachrichten, das wiederholte Übertragen verloren gegangener Nachrichten, Reihenfolgesicherung und Ähnliches, muss die jeweilige UDP-Anwendung selbst übernehmen.
Schwächen von TCP
TCP realisiert zwar eine Fehlersicherung und eine Flusssteuerung, hat aber eine Reihe von Nachteilen. TCP ist bei der Übermittlung einer Folge separater Nachrichten nicht effektiv. Bei TCP werden alle Nachrichten als Strom von Bytes gesehen und die zu sendenden Bytes gezählt. Sollte eine Nachricht während der Übertragung verfälscht werden, ist es bei TCP nicht möglich, nur diese eine Nachricht wiederholt zu übermitteln. Darüber hinaus sorgt TCP für eine strikte Sicherung der Reihenfolge von Datensegmenten. Viele Anwendungen erfordern jedoch lediglich eine teilweise Sicherung der Reihenfolge von Nachrichten, z.B. nur für Signalisierungsnachrichten, die zum selben Signalisierungsprozess gehören. Durch die Sicherung der Reihenfolge bei TCP kann unnötigerweise eine Blockierung bereits angekommener Datenpakete durch fehlende Teile von Nachrichten anderer Signalisierungsprozesse oder Transaktionen auftreten, was zu einer unnötigen Verzögerung führt.
Was bringt SCTP?
SCTP ist ein verbindungsorientiertes und nachrichtenbasiertes Protokoll, das eine gesicherte Übertragung von Nachrichten in mehreren unabhängigen SCTP-Streams bietet. Innerhalb einer sog. SCTP-Assoziation (s. Abb. 3.7-2), die ungefähr einer TCP-Verbindung entspricht, jedoch beispielsweise besser gegen DoS-Angriffe gesichert ist, findet eine TCP-ähnliche Flusssteuerung statt. SCTP kann sowohl Nachrichten segmentieren als auch mehrere Nachrichten in einem IPPacket transportieren.
SCTP vereint die Vorteile von UDP und TCP
SCTP versucht die Vorteile von UDP und TCP in Bezug auf die Übermittlung von Nachrichtenströmen zu vereinen. Des Weiteren werden auch die Anforderungen der Signalisierungsprotokolle, wie z.B. des Signalisierungssystems Nr. 7, im SCTP berücksichtigt. SCTP erweitert einerseits den UDP-Dienst um Fehlersicherung und realisiert andererseits TCP-Konzepte. Somit eignet sich das SCTP nicht nur zum Transport von Nachrichtenströmen, sondern kann sich neben UDP und TCP als ein drittes, wichtiges Transportprotokoll für den Transport unterschiedlicher Datenströme über IP-Netze etablieren.
www.wiwobooks.com
3.7.2 SCTP-Assoziationen SCTP ist ein verbindungsorientiertes Transportprotokoll, nach dem eine SCTPAssoziation zwischen zwei SCTP-Endpunkten aufgebaut wird. Abbildung 3.72 illustriert eine SCTP-Assoziation. E S
E S
E S S C T P
S C T P IP
IP S C T P -A s s o z ia tio n S C T P -P a k e t C H n
... C H 2
IP C H 1 G H
IP
...
S C T P IP
IP
S C T P -A s s o z ia tio n IP -Ü b e r m ittlu n g s n e tz S C T P -P o rt
IP -A d re sse
Abb. 3.7-2: Veranschaulichung von SCTP-Assozationen (SCTP-Assocations) ES: Endsystem, CH n: Chunk n, GH: Gemeinsamer Header
3.7 Bedeutung des Protokolls SCTP
107
Eine SCTP-Assoziation ist als Vereinbarung zwischen zwei SCTP-Endpunkten SCTPin Bezug auf den Verlauf der Kommunikation zwischen ihnen zu interpretie- Assoziation ren. Ein SCTP-Endpunkt stellt das folgende Paar dar: SCTP-Endpunkt = (IP-Adresse, SCTP-Port-Nummer) Ein SCTP-Endpunkt kann auch als (SCTP-)Socket betrachtet werden. Im Allgemeinen kann ein Endsystem mit SCTP mehrere IP-Adressen besitzen, d.h., es kann ein Multi-Home-IP-Endsystem sein. Eine SCTP-Assoziation kann man als SCTP-Verbindung ansehen, die sich aus Was ist ein einer Vielzahl sog. Streams zusammensetzt. Ein Stream lässt sich wiederum als Stream? unidirektionale, (gerichtete) virtuelle Verbindung interpretieren (s. Abb. 3.7-3). Die Nachrichten und „normalen“ Daten werden in sog. SCTP-Paketen transportiert. Die Nummer des Protokolls SCTP im IP-Header ist 132. Wie aus Abbildung 3.7-2 ersichtlich ist, setzt sich ein SCTP-Paket aus einem gemeinsamen Header und einer Reihe sog. Chunks zusammen. Ein Chunk stellt eine Art Container dar und kann eine Signalisierungsnachricht, „normale“ Daten bzw. bestimmte Steuerungsangaben enthalten. In einem SCTP-Paket können somit mehrere Nachrichten bzw. mehrere Datenblöcke aus den unterschiedlichen Datenströmen transportiert werden.
Mehrere Nachrichten in einem SCTP-Paket
Über eine SCTP-Assoziation lassen sich parallel mehrere SCTP-Streams übermitteln. Dies illustriert Abbildung 3.7-3. Ein Stream stellt eine Folge zusammenhängender Nachrichten in eine Richtung dar, z.B. Signalisierungsnachrichten für die Ansteuerung einer Verbindung bei VoIP.
Mehrere Streams über eine SCTPAssoziation
www.wiwobooks.com
E S
E S
S C T P
S C T P
IP
IP S C T P -A s s o z ia tio n S tre a m s O S = 3
IP -Ü b e r m ittlu n g s n e tz IS = 2
S C T P -A n w e n d u n g S C T P -P o rt IP -A d re sse
Abb. 3.7-3: Mehrere Streams innerhalb einer SCTP-Assoziation ES: Endsystem, IS: Inbound Stream, OS: Outbound Stream
Man unterscheidet bei SCTP zwischen ausgehenden Streams (Outbound Streams) und ankommenden Streams (Inbound Streams).
108
3
TCP/IP- und VoIP-Protokolle
Beim Aufbau einer Assoziation gibt die initiierende SCTP-Instanz die Anzahl von Outbound Streams als Parameter OS (Number of Outbound Streams) und die zulässige Anzahl von Inbound Streams als Parameter MIS (Maximum of Inbound Streams) in der von ihr initiierten Assoziation an. Da mehrere Streams innerhalb einer SCTP-Assoziation verlaufen, müssen die einzelnen Streams entsprechend gekennzeichnet werden. Hierfür dient der Parameter Stream Identifier. Abbildung 3.7-4 zeigt ein Beispiel für eine Anwendung, in der über eine SCTP-Assoziation mehrere Streams verlaufen.
S tre a m s V o IP In tr a n e t
V G V o IP
S C T P -A s s o z ia tio n IP -N e tz (In te r n e t)
V G
In tr a n e t
Abb. 3.7-4: Beispiel für parallele Streams; Vernetzung von TK-Anlagen über ein IP-Netz
www.wiwobooks.com
Zwischen zwei VoIP-Gateways (VG) besteht eine SCTP-Assoziation, über die vier Streams verlaufen. Mit einem Paar von entgegengerichteten Streams wird z.B. eine VoIP-Verbindung zwischen zwei Telefonapparaten realisiert. SCTPVerbindung als virtuelle Autobahn
Während man sich die TCP-Verbindung (vgl. Abb. 3.4-2) als virtuelle Straße mit zwei entgegengerichteten Spuren vorstellen kann, ist bei der SCTPAssoziation der Vergleich mit einer virtuellen Autobahn und einer beliebigen Anzahl von Spuren in beiden Richtungen möglich. Die Nachrichten (bzw. andere Daten) werden in sog. DATA-Chunks transportiert. Mit dem Parameter Stream Identifier im Chunk DATA wird markiert, zu welchem Stream die übertragene Nachricht gehört. Somit ist es möglich, in einem SCTP-Paket mehrere Chunks DATA mit den Nachrichten aus verschiedenen Streams zu übermitteln. Dies bezeichnet man beim SCTP als Chunk Bundling (Chunk-Bündelung). Für weitere Informationen über SCTP ist auf [BaHo 07] zu verweisen.
3.8
ENUM – Konzept und Einsatz
Bei VoIP müssen Rechnern am IP-Netz, die auch als IP-Telefone dienen, Telefonnummern zugeordnet werden, damit sie von klassischen Telefonen am ISDN bzw. am analogen Telefonnetz erreichbar sind. Der Wunsch, Telefonnummern auch als Adressen für die Nutzung von Internet-Diensten zu verwenden, hat zu ENUM (tElephone Number URI Mapping) geführt. ENUM ist ein
3.8 ENUM – Konzept und Einsatz
109
Standard der IETF, dessen Einführung auch seitens des ITU-T unterstützt wird – siehe http://www.ietf.org/dyn/wg/charter/enum-charter.html ENUM ist ein Dienst, der die Telefonwelt und das Internet zusammenbringen Bedeutung soll. Mit Hilfe von ENUM kann eine Telefonnummer auf mehrere dienstspezi- von ENUM fische Adressen – wie z.B. auf SIP-URI, E-Mail-Adresse oder HTTP-URL – abgebildet werden. Somit lassen sich einer Telefonnummer mehrere dienstspezifische Adressen zuordnen. Dies bedeutet, dass man mit einer einzigen Telefonnummer alle Internet-Dienste adressieren kann. Dank ENUM ist es möglich, IP-Telefonen mit SIP weiterhin Telefonnummern zuzuordnen, damit sie von klassischen Telefonnetzen – sogar von analogen Telefonen mit einer Wählscheibe ohne Buchstaben – adressiert werden können und auch weiterhin erreichbar sind. Daher ist ENUM bei VoIP mit SIP von großer Bedeutung. Wie Abbildung 3.8-1 zeigt, führt die Realisierung von ENUM zu einer Er- Erweiterung weiterung von DNS. Dieser neue DNS-Teil wird im Weiteren ENUM-DNS von DNS für genannt. Die IETF hat hierfür die ENUM-Top-Level-Domain (Tier 0). ENUM e164.arpa7 in der Domain arpa vorgesehen. Für ihre Administration ist RIPE NCC (www.ripe.net/enum) zuständig. Die ENUM-Second-LevelDomains (Tier 1) werden von den nationalen Organisationen verwaltet – z.B. 8 DENIC eG in Deutschland, die als nationale ENUM-Registrare fungieren. Jede nationale ENUM-Domain kann weiter aufgeteilt werden, sodass weitere ENUM-Registrare ihre Dienstleistungen auf dem Tier 2 anbieten können.
www.wiwobooks.com
a rp a
...
... ip 6
in -a d d r
E N U M -D o m a in s
e 1 6 4 .a r p a E N U M D N S
... ... ...
R o o t e d u
...
c o m
...
...
T ie r 0 (R IP E N C C ) T ie r 1 (n a t. R e g is tra re ) T ie r 2
(w e ite re R e g is tra re )
d e ... ... a b c ... ... ijk ...
...
T o p L e v e l D o m a in s S e c o n d L e v e l D o m a in s a b c .d e - S u b d o m a in ijk .a b c .d e - S u b d o m a in
Abb. 3.8-1: Realisierung von ENUM – Erweiterung von DNS um die Domain e164.arpa
Die Idee von ENUM lässt sich wie folgt zusammenfassen: Um eine Telefon- Idee von nummer auf eine Reihe von dienstspezifischen Adressen abbilden zu können, ENUM wird sie auf den Namen einer sog. ENUM-Domain abgebildet. In der ENUMDomain ist ein Eintrag mit mehreren Resource Records (RRs) vom Typ NAPTR 7
Der Domainname e164.arpa wurde vom ITU-T-Standard E.164 abgeleitet, der die Vorwahlnummer einzelner Staaten festlegt.
8
Unter http://www.enum-center.de/cat2152.html findet man eine Auflistung nationaler ENUM-Registrare.
110
3
TCP/IP- und VoIP-Protokolle
(Naming Authority PoinTeR) – vergleiche Abbildung 3.5-4 – enthalten, wobei jeder RR eine entsprechende dienstspezifische Adresse, wie z.B. SIP-URI, angibt und auch eine Priorität hat (sog. Order, s. Abb. 3.8-3). Beim Initiieren einer Kommunikationsbeziehung zu einer Endeinrichtung (z.B. IP-Telefon mit SIP) muss daher zuerst die Telefonnummer dieser Endeinrichtung auf die ENUM-Domain abgebildet und danach ein NAPTR-RR in dieser ENUMDomain abgefragt werden.
3.8.1 Bildung von ENUM-Domainnamen und NAPTR-RRs Das grundlegende ENUM-Konzept besteht in der Abbildung von Telefonnummern – präzise gesagt von E.164-Rufnummern – auf ENUM-Domains, in denen die Einträge in der Form von NAPTR-RRs mit dienstspezifischen Adressen abgespeichert werden können. Bei der Abbildung einer E.164-Rufnummer – z.B +49-69-825362 – sind folgende Schritte zu unterscheiden: ENUMDomainname
1. Alle nichtnumerischen Teile der Rufnummer werden entfernt: 4969825362
www.wiwobooks.com
2. Zwischen allen Ziffern wird ein Punkt („.“) eingefügt: 4.9.6.9.8.2.5.3.6.2
3. Die Reihenfolge des entstandenen Strings wird umgekehrt: 2.6.3.5.2.8.9.6.9.4
4. Am Ende des obigen Strings wird.e164.arpa hinzugefügt; so entsteht der ENUM-Domainname: 2.6.3.5.2.8.9.6.9.4.e164.arpa
Der im letzten Schritt erzeugte ENUM-Domainname muss bei einem Registrar registriert werden, um die Einträge dieser ENUM-Domain in Form von NAPTR-RRs über das Internet zugänglich zu machen. Wie Abbildung 3.8-2 zeigt, dient die aus der E.164-Rufnummer +49-69-825362 abgeleitete ENUM-Domain 2.6.3.5.2.8.9.6.9.4.e164.arpa als „Container“, in dem die NAPTR-RRs mit den der E.164-Rufnummer entsprechenden dienstspezifischen Adressen enthalten sind. Struktur von ENUM-DNS
Wie hier auch ersichtlich ist, wird die ENUM-Top-Level-Domain e164.arpa auf eine Vielzahl von Subdomains aufgeteilt, die den möglichen Werten vom Country Code in E.164-Rufnummern entsprechen. Jede dieser Subdomains wird weiter auf 10 Subdomains aufgeteilt, die jeweils den möglichen Werten der dritten Ziffer der E.164-Rufnummer entsprechen. Schließlich werden die Einträge mit NAPTR-RRs – auf der letzten Aufteilungsstufe – den Knoten zugeordnet, in denen die den jeweiligen E.164-Rufnummern entsprechenden Dienste und deren Adressen enthalten sind.
3.8 ENUM – Konzept und Einsatz
E N U M -D o m a in 2 .6 .3 .5 .2 .8 .9 .6 .9 .4 .e 1 6 4 .a r p a
R o o t
a rp a e 1 6 4 .a r p a
...
...
... ... 1 .4 ( C H ) 0 1
...
9 . 4 ( D . .) .
E N U M -D N S 9 9
...
...
111
0 9 0
9
N A P T R R R s m it A d re s s e n v o n D ie n s te n
Abb. 3.8-2: Struktur von ENUM-DNS – ENUM-Domain als Container für NAPTR RRs
Die Nutzung von NAPTR-RRs bei der Ermittlung des SIP-Proxy beim Initiieren NAPTR-RRs einer Session bei VoIP mit SIP wurde bereits in Abschnitt 3.5.4 erläutert. In bei ENUM Abbildung 3.5-4 wurde auch die Struktur von NAPTR-RRs am Beispiel der Domain xyz.de dargestellt. Die NAPTR-RRs bei ENUM – genauer: einer ENUM-Domain – strukturiert man zwar genauso, doch ihre Inhalte sind anders als die Inhalte von NAPTR-RRs in „normalen“ Domains. Abbildung 3.8-3 zeigt, welche Adressangaben in einer ENUM-Domain enthalten und somit: welche Adressen einer Telefonnummer zugeordnet sein können.
www.wiwobooks.com
$ O R IG IN IN IN IN IN IN
N A N A N A N A N A
P T P T P T P T P T
2 .6 .3 .5 .2 .8 .9 .6 .9 .4 .e 1 6 4 .a r p a . R R R R R
O rd e r
1 0 2 0 1 0 2 1 0 2 1 0 2
P re f
1 0 1 0
1 0 1 0 1 0
F la g s
" u " u " u " u " u
"
"
"
"
"
" E " E " E " E " E
S e r v ic e
2 U 2 U 2 U 2 U 2 U
+ s ip " + s ip " + m sg " + h ttp " + te l"
A d r e s s e n d e r D ie n s te !R e g e x p ! R e p la c e m e n t!
" ! ^ .* $ ! s ip :m o n d @ x " ! ^ .* $ ! s ip :+ 4 9 6 6 1 9 " ! ^ .* $ ! m a ilto :m o n d " ! ^ .* $ ! h ttp ://w w w .s " ! ^ .* $ ! te l:+ 4 9 6 9 8 2 5
y z 5 4 @ o n 3 4
.d e ! " . 5 9 2 @ x y z .d e ! " . x y z .d e ! " . n e .x y z .d e ! " . 0 !"
Abb. 3.8-3: RRs vom Typ NAPTR in der Domain 2.6.3.5.2.8.9.6.9.4.e164.arpa Die Angaben in NAPTR-RRs einer ENUM-Domain: Order – gibt ebenso wie in Abbildung 3.5-4 an, in welcher Reihenfolge die einzelnen RRs auszuwählen sind. Ein RR mit kleinem Order-Wert wird bevorzugt. Pref (Preference) – legt die Präferenz des RR unter RRs mit gleichem Order fest. Flag – u verweist hier darauf, dass im nächsten Schritt ein URI (z.B. sip:[email protected]) –
mit DNS-Hilfe – auf eine IP-Adresse abgebildet werden muss. Service – Angabe eines Dienstes, wie z.B VoIP mit SIP (E2U+sip), E-Mail (E2U+msg); E2U ist als E.164 to URI zu lesen. !Regexp (Regular expression)!Replacement! – „!“ dient als Trennzeichen. In RRs mit Flag u wird „^.*$“ als Regexp eingetragen. Replacement gibt die Adresse eines Dienstes
an.
112
3
TCP/IP- und VoIP-Protokolle
NAPTR-RRs einer ENUM-Domain enthalten daher die Informationen über die einer E.164Rufnummer entsprechenden Dienste. Im gezeigten Beispiel (siehe Abbildung 3.8-3) sind folgende Internet-Dienste unter der E.164-Rufnummer +4969825362 verfügbar: VoIP mit SIP – SIP-URIs: sip:[email protected] und sip:[email protected] mit niedrigerer Priorität E-Mail mit der Adresse mailto:[email protected] Web-Seite; Ihre Adresse: http://[email protected] VoIP unter der Rufnummer +4969825340 (z.B. nach H.323)
3.8.2 Beispiele für den ENUM-Einsatz Die Bedeutung von ENUM besteht für VoIP vor allem darin, dass man die klassischen Telefonnummern für die Adressierung bei VoIP mit SIP weiterhin verwenden kann. Dadurch können einerseits sogar die klassischen Telefone über Gateways an VoIP-Systeme mit SIP angebunden werden, andererseits lassen sich IP-Telefone mit herkömmlichen Rufnummern am Internet sowohl aus dem ISDN als auch aus dem analogen Telefonnetz erreichen. Abbildung 3.8-4 zeigt einige Beispiele für den ENUM-Einsatz.
www.wiwobooks.com
a ) a b c .d e
IS D N /P S T N
G
S P
G
S P
In te rn e t G
x y z .d e
In te rn e t
a b c .d e
1
S P
2
A lic e , T e l-N r A
s ip :a lic e @ x y z .d e 1
E -D N S D N S
1
S P
2
S P
x y z .d e
B o b , T e l-N r B
s ip :b o b @ x y z .d e
E N U M -A b fra g e (E rm ittlu n g v o n S IP -U R I)
a b c .d e
x y z .d e
G
A lic e , T e l-N r A
B o b , T e l-N r B
d ) S P
E -D N S D N S
G
T e l-N r B
c )
a b c .d e
G
T e l-N r A
In te rn e t
b )
In te rn e t
S P
A lic e , T e l-N r A
s ip :a lic e @ x y z .d e
1 2
E -D N S D N S
1 2
IS D N / P S T N
G
T e l-N r B B o b
2 D N S -A b fra g e (E rm ittlu n g d e r IP -A d re s s e )
Abb. 3.8-4: Herkömmliche Telefone am Internet und VoIP zwischen Domains: a) ohne ENUM; b) mit ENUM; IP-Telefone mit Telefonnummer; c) VoIP zwischen verschiedenen Domains; d) Kommunikation zwischen Internet und ISDN/PSTN E-DNS: ENUM-DNS, G: VoIP-Gateway, SP: SIP-Proxy, Tel-Nr: Telefonnummer
Kein ENUM
Welche Bedeutung ENUM hat, zeigt Abbildung 3.8-4a. Hier werden klassische Telefone am Internet ohne ENUM eingesetzt. In diesem Fall muss die Sprachkommunikation zwischen den beiden Domains über das herkömmliche Netz für die Sprachkommunikation – also über ISDN/PSTN – verlaufen. Gehören
3.8 ENUM – Konzept und Einsatz
113
diese Internet-Domains verschiedenen Service-Providern, so können diese von Gebühren in ISDN/PSTN nur profitieren. Wie Abbildung 3.8-4b zeigt, verläuft die Sprachkommunikation zwischen beiden Domains beim Einsatz klassischer Telefone am Internet und bei der Nutzung von ENUM nur über IP-Netze. Initiiert Alice als Anrufer eine Verbindung durch die Angabe der Rufnummer von Bob, wertet der SIP-Proxy der Domain abc.de die angegebene Rufnummer aus, generiert den für diese Rufnummer entsprechenden Namen der ENUM-Domain und führt eine NAPTR-Query – 9 eine ENUM-DNS-Abfrage (Schritt 1) – in dieser ENUM-Domain durch, um den Namen des Anschlusses von Bob in der Domain xyz.de (z.B. [email protected]) abzufragen. Danach wird vom SIP-Proxy der Domain abc.de mit Hilfe von DNS die IP-Adresse des Anschlusses von Bob abgefragt (Schritt 2). Damit lässt sich über das Internet eine VoIP-Session zwischen den beiden Domains, ohne ISDN/PSTN in Anspruch zu nehmen, aufbauen.
Klassische Telefone am Internet – mit ENUMEinsatz
Abbildung 3.8-4c illustriert den Fall, wenn die beiden Benutzer zwar über IPTelefone verfügen, ihre E.164-Rufnummern aber weiterhin als VoIP-Adressen am Internet nutzen. Hier initiiert Alice durch die Angabe der herkömmlichen Rufnummer eine Verbindung zu Bob. Der SIP-Proxy der Domain abc.de führt einen ENUM-Lookup durch (Schritt 1); somit wird der SIP-URI des IPTelefons von Bob beim ENUM-DNS abgefragt. In Schritt 2 wird der SIP-URI auf die IP-Adresse des IP-Telefons von Bob mit Hilfe einer DNS-Abfrage abgebildet. Anschließend kann man eine VoIP-Session über das Internet aufbauen. Hervorzuheben ist in diesem Fall, dass das Ziel der VoIP-Session beim Anrufer zwar als Telefonnummer angegeben wird, die IP-Telefone aber ihre SIPURIs besitzen. Die Abbildung einer Telefonnummer auf einen SIP-URI erfolgt durch eine ENUM-DNS-Abfrage.
IP-Telefone nutzen E.164-Rufnummern
Werden die E.164-Rufnummern den IP-Telefonen am Internet zugeordnet, erleichtert dies die Integration des Internet sowohl mit klassischen Netzen für die Sprachkommunikation (ISDN, PSTN) als auch mit Mobilfunknetzen wie GSM und UMTS. Abbildung 3.8-4d bringt dies näher zum Ausdruck. Hier initiiert Alice eine Verbindung durch die Angabe der Rufnummer von Bob am ISDN/ PSTN. Der SIP-Proxy der Domain abc.de ermittelt im Schritt 1 mittels einer ENUM-DNS-Abfrage und im Schritt 2 mittels einer DNS-Abfrage die IPAdresse des VoIP-Gateway zum ISDN/PSTN. Danach wird eine VoIP-Session zum Gateway aufgebaut und von dort aus zum Telefon von Bob mit einer Verbindung verlängert (s. Abb. 1.2-2). Ebenso kann seitens Bob am ISDN/PSTN eine Verbindung zu Alice am Internet initiiert werden.
Integration des Internet mit ISDN/PSTN
www.wiwobooks.com
9
In diesem Zusammenhang spricht man auch von ENUM-Lookup.
114
3
TCP/IP- und VoIP-Protokolle
3.9
Schlussbemerkungen
Das Ziel dieses Kapitels war es, die notwendigen Grundlagen der Protokollfamilie TCP/IP in kompakter Form darzustellen, die zum Verständnis von VoIPKonzepten notwendig sind. Mangels Platz konnte die Protokollfamilie TCP/IP nicht detaillierter dargestellt werden. Ausführliche Informationen dazu finden sich in [BaHo 07]. Abschließend ist u.a. Folgendes hervorzuheben: RoutingProtokolle
Zur Protokollfamilie TCP/IP gehören u.a. folgende Routing-Protokolle: − RIP (Routing Information Protocol) ist das älteste Routing-Protokoll in IP-Netzen. Es gibt zwei Generationen von RIP. Das alte Protokoll RIP-I wird bei der klassenbasierten IP-Adressierung verwendet. In diesem Fall sind alle IP-Subnetze in einem Netzwerk nach der Anzahl von Rechnern gleich groß. Dies entspricht dem klassischen IP-Subnetting. Das neue Protokoll RIP-II wird bei der klassenlosen IP-Adressierung verwendet. In diesem Fall können die IP-Subnetze in einem Netzwerk je nach der Anzahl der Rechner verschiedene Größen haben. Dies stellt eine moderne Form der Bildung von IP-Subnetzen dar. − OSPF (Open Shortest Path First) wird für das Routing in IP-Netzen verwendet, in denen die WANs als Übertragungsnetze dienen. − BGP (Border Gateway Protocol) wird für die Übermittlung der Routing-Information zwischen jeweils zwei administrativen Domänen verwendet, d.h. zwischen zwei IP-Netzen, die administrativ unterschiedlichen Organisationen bzw. Institutionen gehören (s. Abschnitt 9.2.2).
www.wiwobooks.com
Routing bei VoIP
Bei VoIP mit H.323 innerhalb einer administrativen Domäne werden die Telefonnummern in der Regel auf einem speziellen Server (z.B. Gatekeeper) als Auskunftsstelle abgespeichert. Sollte VoIP zwischen zwei administrativen Domänen realisiert werden, ist ein Routing-Protokoll nötig, das der Funktion nach dem Protokoll BGP entspricht. Ein derartiges Protokoll bei VoIP stellt TRIP (Telephony Routing over IP) dar. Mit Hilfe von TRIP können sich die Domänen gegenseitig mitteilen, wo man die notwendige Information über die Telefonnummern abrufen kann. Auf TRIP wird in Abschnitt 9.2 näher eingegangen.
RessourcenReservierung mit RSVP
Für die QoS-Garantie (Quality of Service) bei VoIP müssen manchmal bestimmte Netz-Ressourcen (z.B. die Bandbreite von Leitungen) reserviert werden. Hierfür kann das Protokoll RSVP (Resource reSerVation Protocol) eingesetzt werden. Die RSVP-Nachrichten werden direkt in die IP-Pakete eingebettet, ohne ein Transportprotokoll zu nutzen. Auf RSVP geht Abschnitt 4.6 kurz ein. Die erweiterte RSVP-Version – als RSVP-TE (Traffic Engineering) bezeichnet – dient als Signalisierungsprotokoll in (G)MPLSNetzen dar (siehe [BaHo 07]).
4
VoIP und QoS in IP-Netzen
Bei VoIP werden bestimmte Anforderungen an IP-Netze hinsichtlich der Qua- QoSlität bei Übermittlung von Sprache gestellt. Diese Anforderungen bezeichnet Anforderunman als QoS-Anforderungen (Quality of Service); sie betreffen vor allem die gen Übermittlungszeit und deren Schwankungen sowie Verluste von IP-Paketen mit Sprache. Eine besonders große Auswirkung auf die Qualität des Telefongesprächs bei VoIP hat die Ende-zu-Ende-Verzögerung des Sprachsignals, d.h. die Zeit, die das Sprachsignal vom Mund des Sprechers bis zum Ohr des Empfängers benötigt. Um die gestellten QoS-Anforderungen erfüllen zu können, kommen verschie- Konzepte dene Konzepte in Frage, wie z.B. Differentiated Services, mehrere Verfahren für QoSfür Management von Warteschlangen mit IP-Paketen vor Leitungen (Queue- Garantie Management) und das Protokoll RSVP (Resource reSerVation Protocol). Im Allgemeinen basieren diese Konzepte auf der Differenzierung von Paketströmen in IP-Netzen. Hierbei werden den IP-Paketen mit Sprache höhere Prioritäten zugeteilt als den IP-Paketen mit Daten. So werden IP-Pakete mit Sprache im IP-Netz vorrangig „behandelt“.
www.wiwobooks.com
Dieses Kapitel gibt einen Überblick über das Thema QoS bei VoIP. Nach einer Überblick Darstellung von Einflussfaktoren auf die VoIP-Qualität in Abschnitt 4.1 folgt über das in Abschnitt 4.2 eine Auflistung von Verfahren zur Garantie von QoS-Anfor- Kapitel derungen. Auf die QoS-Unterstützung in lokalen Netzwerken geht Abschnitt 4.3 ein. Abschnitt 4.4 erläutert das Konzept von Differentiated Services. Verschiedene Verfahren für Queue-Management präsentiert Abschnitt 4.5. Das Protokoll RSVP wird in Abschnitt 4.6 dargestellt. Abschließende Bemerkungen in Abschnitt 4.7 runden das Kapitel ab. In diesem Kapitel findet man u.a. Antworten auf folgende Fragen: Welche Faktoren wirken sich negativ auf die VoIP-Qualität aus? Welche Komponenten enthält die Ende-zu-Ende-Verzögerung des Sprachsignals? Welche Auswirkung für Paketverluste hat ein Jitter-Ausgleichpuffer? Wie ist die QoS-Unterstützung in lokalen Netzwerken und in Weitverkehrsnetzen möglich? Wie funktionieren wichtige Verfahren (CBQ, WFQ, CBWFQ, ...) für Queue-Management? Wie reserviert man die Bandbreite einer virtuellen Verbindung nach dem Protokoll RSVP?
Ziel dieses Kapitels
116
4
VoIP und QoS in IP-Netzen
4.1
QoS-Anforderungen bei VoIP
VoIP als isochrone Kommunikation
Bei der Audio- und Videokommunikation über ein IP-Netz und damit auch bei VoIP wird verlangt, dass die Zeitverhältnisse im Bitstrom an der Sende- und Empfangsseite unverändert bleiben. Damit müssen die Zeitabstände zwischen den aufeinanderfolgenden IP-Paketen in einem Audio/Video-Bitstrom auf Sende- und Empfangsseite identisch sein. In diesem Zusammenhang spricht man von Isochronität. Daher stellt VoIP eine isochrone Kommunikation dar.
Begriff QoS
Die Anforderung an das IP-Netz, eine isochrone Kommunikation in guter Qualität zu ermöglichen, werden als QoS-Anforderungen bezeichnet. Unter QoS (Quality of Service), auch Dienstgüte genannt, wird die Fähigkeit eines IPNetzes verstanden, einer Anwendung oder einer Klasse von Anwendungen eine geforderte Bandbreite einer Verbindung bzw. zusätzlich eine maximale Übermittlungszeit im Netz zu garantieren und hierbei möglichst eine geringe Anzahl von Übermittlungsfehlern und eine geringe Schwankung der Übermittlungszeit einzelner IP-Pakete zu verursachen.
4.1.1 Einflussfaktoren auf die VoIP-Qualität
www.wiwobooks.com
Die wichtigsten QoS-Anforderungen, die VoIP an IP-Netze stellt, betreffen: die Bandbreite von virtuellen Verbindungen zwischen IP-Telefonen, die Ende-zu-Ende-Verzögerung des Sprachsignals (Delay), die Schwankung der Übermittlungszeit (Jitter) und die Paketverlustrate (Packet Loss Rate). Garantie einer bestimmten Bandbreite
Bei VoIP wird die Sprache zuerst digitalisiert und dann entsprechend codiert (s. Abschnitt 5.1). Digitalisierte Sprache stellt ein kontinuierliches Signal mit einer konstanten Bitrate dar. Um ein solches Sprachsignal in guter Qualität über ein IP-Netz zu übermitteln, muss das Netz manchmal eine bestimmte Bandbreite für virtuelle Verbindung zwischen IP-Telefonen – also für eine VoIP-Session, siehe Abbildungen 5.2-1 und -2 – garantieren. Dafür wurden spezielle Verfahren für das Management der Warteschlangen entwickelt (s. Abschnitt 4.5).
Ende-zuEndeVerzögerung
Ein wichtiger Faktor, der die Qualität der Sprache bei VoIP bestimmt, ist die Ende-zu-Ende-Verzögerung des Sprachsignals. Darunter versteht man die Zeitspanne, die ein Sprachsignal vom Mund eines Sprechers bis zum Ohr eines Hörers benötigt. Die Hauptursache dieser Verzögerung ist die Übermittlungszeit der IP-Pakete mit Sprache über ein IP-Netz. Die Verzögerung entsteht vor allem durch die Zwischenspeicherung der IP-Pakete in den Routern, die sie auf ihren Wegen durch das Netz zu durchlaufen haben. Jeder Router benötigt Zeit, um den Header im IP-Paket zu interpretieren und die entsprechende RoutingEntscheidung zu treffen. Trifft ein Paket unterwegs auf einen überlasteten Rou-
4.1 QoS-Anforderungen bei VoIP
117
ter, muss es einige Zeit in der Warteschlange vor der Leitung verbringen und wird im Extremfall sogar ganz verworfen. Eine große Ende-zu-Ende-Verzögerung beeinträchtigt den Charakter eines Telefongesprächs stark. Da die einzelnen IP-Pakete auf einer Verbindung zwischen IP-Telefonen in der Jitter Regel auf unterschiedlichen Wegen übermittelt werden, kann ihre Übermittlungszeit recht unterschiedlich sein. Die Schwankungen der Übermittlungszeit nennt man Jitter. Die Isochronität bei VoIP lässt jedoch kein Jitter zu. Um die Schwankungen auszugleichen, wird beim Empfänger ein spezieller Puffer implementiert. Man bezeichnet einen derartigen Puffer als Jitter-Ausgleichpuffer (Playout Buffer, Dejitter Buffer) – siehe Abbildung 5.6-1. Die Verluste von IP-Paketen mit Sprache während der Übermittlung mindern Paketdie VoIP-Qualität ebenso. Die Anzahl der Paketverluste in einer bestimmten verluste Zeitperiode wird mit dem Parameter Paketverlustrate angegeben. Paketverluste können durch überlastete Router im IP-Netz oder auch durch einen „schlecht“ dimensionierten Jitter-Ausgleichpuffer entstehen (s. Abb. 4.1-1). Im Gegensatz zu reinen Datenanwendungen wie Überprüfungen von Kreditkarten, bei denen der Verlust von nur einem Paket die gesamte Anwendung zum Scheitern bringen kann, ist der Verlust eines IP-Pakets bei der Sprachübertragung nicht besonders tragisch. Zu viele Paketverluste machen sich in einem Telefongespräch allerdings sehr störend als Unterbrechungen bemerkbar.
www.wiwobooks.com
Die hier genannten Störfaktoren werden als VoIP-Metriken erfasst. Ein Emp- Störfaktoren fänger der IP-Pakete mit Sprache kann die Werte einiger VoIP-Metriken wäh- als VoIPrend der Kommunikation ermitteln und diese auch an den Absender der IP- Metriken Pakete mit Hilfe des Protokolls RTCP übermitteln (s. Abschnitt 5.5.6), um ihn so über die Qualität der Kommunikation zu informieren. Um präzise beurteilen zu können, wie die Störfaktoren – wie z.B. Jitter, Paket- E-Modell verluste und Delay – die Sprachqualität beim Empfänger beeinflussen, wurde von der ITU-T das sog. E-Modell im Standard G.107 spezifiziert. Auf das E-Modell gehen wir in Anschnitt 6.4.4 kurz ein.
4.1.2 Ende-zu-Ende-Verzögerung Da die Sprachkommunikation in Echtzeit verläuft, gilt die Wiedergabe eines Sprachsignals am Ziel als qualitativ schlecht, wenn sie nach einem zu großen Zeitverzug erfolgt. Für die Ende-zu-Ende-Verzögerung TEE (End-to-End Delay) des Sprachsignals werden daher Grenzwerte gesetzt. Nach dem ITU-TDokument G.114 wird die VoIP-Qualität wie folgt klassifiziert: TEE kleiner als 150 ms: akzeptabel für alle Benutzer; TEE zwischen 150 ms und 300 ms: akzeptabel, aber mit Einschränkungen (nicht für empfindliche Benutzer);
118
4
VoIP und QoS in IP-Netzen
TEE größer als 300 ms: nicht akzeptabel. Budget von TEE
VoIP mit TEE bis zu 300 ms könnte man als akzeptabel bezeichnen. Bei der Planung eines VoIP-Systems wird eine Qualitätsklasse durch die Festlegung des maximal zulässigen Wertes von TEE festgelegt. Dieser Wert kann als Budget von TEE angenommen und darf nicht überschritten werden. Die Einflussfaktoren auf TEE werden im Folgenden anhand eines Beispiels näher erläutert. Beispiel 1: Abbildung 4.1-1 illustriert die Übermittlung von drei Sprachpaketen P1, P2 und P3 über ein IP-Netz. Es sollen hier alle Komponenten der Ende-zu-Ende-Verzögerung TEE erläutert werden. Es wird hier angenommen, dass die Sprachcodierung nach einem segmentorientierten Verfahren stattfindet (s. Abschnitt 5.1.5) und die Verzögerung im Decodierer vernachlässigbar ist. Daher wird hier der Decodierer nicht gezeigt.
IP -T e l A
S S
S C
e in
T
T 1
0
t
T
1
D
L o o k -a h e a d
T 1
S E
S e g
IP -T e l B
IP -N e tz R
1
S E
a u s
T D
T
www.wiwobooks.com P
S S
2
1
T
0
P
t
1
P P 3
P
S C
t 2
P
1
3
P
t
S p ra c h s e g m e n te z u m
a u s
E rz e u g te S p ra c h s e g m e n te a m S
P
3
e in
C o d ie re r
1
P
S e n d e n S e n d e r
1
2
3
P
3
1 1
P
tÜ
1
T
JP
1
2
P
S *2 3
3
S
Z ie l E
D
0
t
S P
3
P S
P
T 1
E E
0
T
1
P 2
D
1
2
P
C P
0
3
E m p fä n g e r
Abb. 4.1-1: Einflussfaktoren auf die Größe der Ende-zu-Ende-Verzögerung (TEE) τ1: zufällige Zwischenspeicherungszeit (Wartezeit auf das Senden)
Codierungsund Paketierungszeit TCP
Das hier zu sendende Sprachsignal wird fortlaufend abgetastet und in Zeitabschnitte, sog. Segmente, mit der Länge von TSeg (z.B. 30 ms bzw. mit 240 Abtastwerten) zerlegt. Der Codierer im IP-Telefon A muss somit die Zeit TSeg abwarten, bevor er mit der Codierung und Komprimierung des Sprachsegments S1 beginnen kann. Aus S1 wird das Sprachpaket P1 gebildet. Die Zeit, die ein Codierer zum Erzeugen eines Sprachpakets benötigt, bezeichnet man oft als Look-ahead Delay (TLook-ahead). Die Zeit TCP = TSeg + TLook-ahead stellt daher die Codierungs- und Paketierungszeit dar und kann als konstant angenommen werden.
4.1 QoS-Anforderungen bei VoIP
119
Beim Aussenden eines Pakets werden seine einzelnen Bits seriell gesendet. Dies bedeutet die Serialisierung des Pakets, und die hierfür benötigte Zeit wird als Serialisierungsverzögerung (D0) angesehen. Sie kann ermittelt werden wie folgt:
Serialisierungsverzögerung D0
D0 = Paketgröße [Bit] / Übertragungsrate [Bit/s] Die Übertragungszeit von P1 vom IP-Telefon A zum Router beträgt T0. P1 verbringt im Router eine zufällige Zeit τ1 in der Warteschlange vor der Leitung zum IPTelefon B. Die Serialisierungsverzögerung beim Senden durch den Router ist gleich D1, und die Übertragungszeit beträgt hierbei T1. Die gesamte Übermittlungszeit tÜ über das IP-Netz ist eine Zufallsvariable und kann dargestellt werden als tÜ = T0 + τ1 + D1 + T1.
Übermittlungszeit tÜ
P1 wird im IP-Telefon B über die Zeit TJP im Jitter-Ausgleichpuffer (J-AP) gehalten. Diese zusätzliche Zwischenspeicherung am Ziel sollte die Sicherheit bringen, dass jedes Sprachpaket bereits am Ziel empfangen wurde, falls es dekodiert und wiedergegeben werden muss. Aus den Sprachpaketen müssen die Sprachsegmente mit der Länge von TSeg (d.h. 30 ms) synchron generiert werden, um ein analoges Sprachsignal erzeugen zu können.
Zwischenspeicherungszeit TJP im J-AP
Da die Verzögerung TJP im J-AP hier zu klein ausgewählt wurde, ist während der Erzeugung des Sprachsegments S1 das nächste Sprachpaket P2 für die Erzeugung des Sprachsegments S2 noch nicht eingetroffen. P2 gilt hier als verloren gegangen. In diesem Fall muss ein künstliches Segment S2* (z.B. mit einem passenden Geräusch) als Ersatzsegment für S2 erzeugt werden. Die bei Paketverlusten zu treffenden Maßnahmen bezeichnet man als Error Concealment1. Den Einfluss der Zwischenspeicherungszeit im J-AP auf die Paketverluste wird im Weiteren detaillierter dargestellt (s. Abb. 4.1-5).
Folge einer zu kurzen Zwischenspeicherung im J-AP
www.wiwobooks.com
Um überprüfen zu können, ob das Budget von TEE nicht überschritten wurde, braucht man einfache Richtlinien für die Abschätzung von TEE. Abbildung 4.1-2 zeigt daher die wichtigsten Komponenten, die den Wert von TEE bei der PCPC-Kommunikation bestimmen.
Q u e lle
IP -N e tz C P T
S + D
C P
T
E E
Ü b e rm ittlu n g
Z ie l J-A P
+ tÜ + T 0 : E n d e -z u -E n d e -V e rz ö g e ru n g (E n d -to -E n d D e la y )
JP
C P : C o d ie ru n g u n d P a k e tie ru n g , J -A P : J itte r-A u s g le ic h p u ffe r, S : S e n d e r
Abb. 4.1-2: Komponenten der Ende-zu-Ende-Verzögerung bei der PC-PC-Kommunikation
TEE stellt die Summe der Verzögerung TCP beim Codierer und Paketierer, der TEE bei PCSerialisierungsverzögerung D0 beim Aussenden des Pakets bei der Quelle, der PC-KommuÜbermittlungszeit tÜ im IP-Netz und der Zwischenspeicherungszeit TJP im Jit- nikation 1
Mit dem Protokoll RTCP kann ein Empfänger sogar einen Absender – mit Hilfe des Parameters PCL (Packet Loss Concealment) im Feld des XR-Pakets (s. Abb. 5.5-6) – darüber informieren, nach welchen Verfahren verloren gegangene Pakete ersetzt werden.
120
4
VoIP und QoS in IP-Netzen
ter-Ausgleichpuffer am Ziel dar. Da IP-Pakete mit Sprache in der Regel eine höhere Priorität als solche mit Daten besitzen, werden sie in der Warteschlange zum Senden vor die IP-Pakete mit Daten gestellt. Damit kann man die Wartezeit von IP-Paketen mit Sprache auf das Aussenden bei der Quelle außer Acht lassen. Die Verzögerung im Sender der Quelle entsteht daher nur durch die Serialisierung. TCP als algorithmische Verzögerung
Die Verzögerung TCP beim Codierer und Paketierer wird algorithmische Verzögerung (Algorithmic Delay) genannt. Sie nimmt mit der Reduzierung der Bitrate des Sprachbitstroms zu. Erzeugt ein Codierer einen Bitstrom mit niedriger Bitrate, so muss man länger warten, um ein IP-Paket mit einer „vernünftigen“ Länge zu versenden. Die Verzögerung TCP kann bis zu 40 ms betragen. Beispiel 2: Bei der Migration zum VoIP-Einsatz in einem lokalen Netzwerk möchte man die maximale Ende-zu-Ende-Verzögerung (TEE) von 150 ms garantieren. Die PCs verfügen hier über Vollduplex-Ethernet-Anschlüsse mit 10 Mbit/s und sollen zusätzlich als Soft-IPTelefone dienen. Die Sprachcodierung soll nach dem ITU-T-Standard G.723.1 erfolgen. Somit wird hier bei jeder VoIP-Verbindung ein kontinuierlicher Bitstrom von 5.3 kbit/s über das Netzwerk übermittelt. Wie groß darf aber die maximale Übermittlungszeit über das Netzwerk sein, um TEE von 150 ms nicht zu überschreiten?
www.wiwobooks.com
G.723.1 beschreibt das Segment-orientierte Sprachcodierungsverfahren ACELP (s. Abb. 5.18). Die Bitrate 5.3 kbit/s bei ACELP bedeutet, dass ein Sprachsegment mit der Länge von 20 Bytes alle 30 ms übermittelt wird. Benutzt man die in Abbildung 4.1-1 eingeführten Begriffe und Abkürzungen, ergeben sich für diesen Fall folgende Werte: •
Länge von Sprachsegmenten: TSeg = 30 ms
•
Look-ahead Delay TLook-ahead = 7.5 ms (nach ITU-T-Empfehlung G. 114) Somit beträgt die Codierungs- und Paketierungszeit TCP = TSeg + TLook-ahead = 37.5 ms.
•
Serialisierungsverzögerung bei der Quelle D0 = 72 * 8 [Bit] /10 [Mbit/s] < 0.1 ms Die Länge von MAC-Frame mit einem Sprachsegment beträgt min. 72 Bytes; d.h. 12 Bytes MAC-Header, min. 40 Bytes IP/UDP/RTP-Header und 20 Bytes Sprachsegment.
•
Zwischenspeicherungszeit im Jitter-Ausgleichpuffer TJP = 50 ms Oft wird TJP = 2* TSeg (Länge des Sprachsegments) empfohlen. Wegen kurzer Entfernungen im lokalen Netzwerk wurde hier 50 ms (also weniger als 2* TSeg) angenommen.
Die maximale Übermittlungszeit über das Netzwerk sollte den Wert 150 ms – (37.5 ms + 0.1 ms + 50 ms) = 62.4 ms nicht überschreiten. Man kann davon ausgehen, dass die Übermittlungszeiten in lokalen Netzwerken nicht größer als 62.4 ms sind.
Abschätzung von TEE bei PC-TelefonKommunikation
Um die Sprachkommunikation zwischen IP-Telefonen und Telefonen am Telefonnetz (PSTN) bzw. am ISDN zu ermöglichen, werden die VoIP-Systeme mit PSTN und ISDN integriert. Die Ende-zu-Ende-Verzögerung TEE der Sprachsignale bei einer Verbindung zwischen einem IP-Telefon und einem klassischen Telefon – also bei der PC-Telefon-Kommunikation – bestimmt die Qualität des Telefongesprächs. Abbildung 4.1-3 soll eine Hilfe zur Abschätzung von TEE bei dieser Kommunikation geben.
4.1 QoS-Anforderungen bei VoIP
T
+ T
C P
C P
T +
S
S
E E : E n d e - z u - E n d e - V e r z ö g e r u n g tÜ (1 ) + T JP + T U C + tÜ (2 )
Ü b e rm ittlu n g
S p ra c h e
IP -N e tz JP T
JP
Ü b e rm ittlu n g + T
121
E E
U C
JP
G a te w a y S
C P
Ü b e rm ittlu n g P S T N /IS D N
S p ra c h e
Ü b e rm ittlu n g
tÜ (1 ) + T S + T CP + tÜ (2 ) : E n d e -z u -E n d e -V e rz ö g e ru n g
C P : C o d ie ru n g u n d P a k e tie ru n g , J P : J itte r-A u s g le ic h p u ffe r, S :S e n d e r, U C : U m c o d ie ru n g
Abb. 4.1-3: Ende-zu-Ende-Verzögerung bei der PC-Telefon-Kommunikation tÜ(1), tÜ(2): Übermittlungszeit entsprechend im IP-Netz und PSTN/ISDN
Bei der Übermittlung der Sprache vom IP-Telefon am IP-Netz zum Telefon am PSTN/ISDN werden die IP-Pakete mit Sprache im Jitter-Ausgleichpuffer im (VoIP-)Gateway über die Zeit TJP zwischengespeichert. Damit erreicht man, dass die IP-Pakete mit Sprache an den Umcodierer in regelmäßigen Zeitabständen übergeben werden können. Er erzeugt einen kontinuierlichen Bitstrom mit 64 kbit/s und kann hierbei eine kleine Verzögerung TUC verursachen. Die Endezu-Ende-Verzögerung TEE kann als Summe der Verzögerung bei VoIP, d.h. TCP + TS + tÜ(1) + TJP (vgl. Abb. 4.1-2), der Verzögerung TUC durch die Umcodierung und der Übermittlungszeit tÜ(2) im PSTN/ISDN dargestellt werden.
Vom IPTelefon zum klassischen Telefon
Das PSTN/ISDN als Quelle eines digitalen Sprachsignals liefert das Sprachsignal bereits mit einer Verzögerung tÜ(2). Die Verzögerung bei VoIP lässt sich dann nach den gleichen Prinzipien wie die Ende-zu-Ende-Verzögerung TEE bei der PC-PC-Kommunikation ermitteln (vgl. Abb. 4.1-2).
Vom klassischen Telefon zum IP-Telefon
www.wiwobooks.com
4.1.3 Übermittlungszeit über ein IP-Netz Bei den bisherigen Betrachtungen wurde nur angenommen, dass die Übermittlung der IP-Pakete über ein IP-Netz mit einem Zeitaufwand verbunden ist (vgl. Abb. 4.1-2 und 4.1-3). Abbildung 4.1.4 zeigt eine Zusammenstellung der wichtigsten Komponenten dieser Übermittlungszeit. Die Übermittlungszeit tÜ in einem IP-Netz wird bestimmt durch:
EinflussfakVerzögerung durch die Zwischenspeicherung: Da über eine Leitung mehrere toren auf die ÜbermittPaketströme übermittelt werden, müssen die IP-Pakete in Routern und Swit- lungszeit
ches auf das Senden warten. Sie werden daher in Warteschlangen (Queues) eingereiht, in denen sie zufällige Zeiten verbringen.
122
4
VoIP und QoS in IP-Netzen
Verzögerung durch die Serialisierung: Sie stellt den Zeitaufwand dar, der für das Aussenden eines IP-Pakets erforderlich ist (s. Abb. 4.1-1). Signallaufzeit: Um eine Strecke auf einer Leitung zu überbrücken, braucht jedes Signal eine bestimmte Zeit, die man als Signallaufzeit bezeichnet. Somit setzt sich die Übermittlungszeit eines IP-Pakets in einem IP-Netz aus: der Summe τ0 + τ 1 + ... + τ m von zufälligen Verzögerungen des IP-Pakets in den Warteschlangen vor einzelnen Leitungen, der Summe D0 + D1 + ... + D m von Serialisierungsverzögerungen beim Aussenden des IP-Pakets auf einzelne Leitungen sowie der Summe T0 + T1 + ... + Tm von Signallaufzeiten während der Übertragung des IP-Pakets auf einzelnen Leitungen.
t
R 1
t
IP -N e tz 1
R m
m
www.wiwobooks.com D
0
T
D
0
1
T
D
1
T m
m
Q u e u e -M a n a g e m e n t
tÜ =
t 1 + ... +
Z w is c h e n s p e ic h e ru n g
t m
Ü b e rm ittlu n g s z e it + D 0 + D 1 + ... + D
S e ria lis ie ru n g
m
+
T 0
+ T 1
+ ... +
T m
Ü b e rtra g u n g
Abb. 4.1-4: Einflussfaktoren auf die Übermittlungszeit in einem IP-Netz R1, ..., Rm: Router, τ: Verzögerung durch die Zwischenspeicherung, D: Verzögerung durch die Serialisierung (Aussenden), T: Signallaufzeit
Bedeutung von Queue Management
Die Verzögerung des IP-Pakets beim Warten auf das Senden kann durch die Reservierung (z.B. nach dem Protokoll RSVP, s. Abschnitt 4.6) einer entsprechenden Bandbreite innerhalb einzelner physikalischer Leitungen verringert werden. Hierbei kommen zusätzlich spezielle Mechanismen für das Management von Warteschlangen (Queue Management, s. Abschnitt 4.5) zum Einsatz. Die Serialisierungsverzögerung ist von der Länge des IP-Pakets und der Übertragungsbitrate auf der Leitung abhängig (s. Beispiel 1 in Abschnitt 4.1.2).
Verzögerung je km
Die Signallaufzeit ist von der Entfernung abhängig und lässt sich nicht beeinflussen. Für eine grobe Abschätzung dieser Verzögerungsart wird oft der Wert von 5µs/km bzw. 1ms je 200 km angenommen.
4.1 QoS-Anforderungen bei VoIP
123
4.1.4 Jitter-Ausgleichpuffer und Paketverluste Wie bereits erwähnt wurde, stellt die Übermittlungszeit tÜ eine Zufallsvariable TJP als dar (s. Abb. 4.1-4). Die Schwankungen der Übermittlungszeit werden als Jitter Varianz bezeichnet. In der Mathematik wird eine Zufallsvariable durch eine sog. Vertei- von tÜ lungsfunktion genau beschrieben. Abbildung 4.1-5 illustriert die Verteilungsfunktion von tÜ. V e rte ilu n g d e r Ü b e rm ittlu n g s z e it
P V : P a k e tv e rlu s tw a h rs c h e in lic h k e it P a k e tv e rlu s tra te = P V * P a k e tra te
T Ü
T
tÜ
JP
P a k e tv e rlu s tra te : g rö ß e r V e rz ö g e ru n g : k le in e r
k le in e r g rö ß e r
Abb. 4.1-5: Jitter-Ausgleichpuffer und Paketverluste
www.wiwobooks.com
Der Mittelwert TÜ gibt eine Aussage über die Größe der Übermittlungszeit im IP-Netz. Der Parameter TJP als Varianz der Verteilung stellt die Zwischenspeicherungszeit im Jitter-Ausgleichpuffer (J-AP) dar. Durch eine Zwischenspeicherung der IP-Pakete im J-AP versucht man den Zu- Paketverlust stand zu erreichen, dass alle IP-Pakete in denselben Abständen weiter übergeben werden können, in denen sie an der Quelle abgeschickt wurden.2 Falls ein IP-Paket zu dem Zeitpunkt, zu dem es ausgeliefert werden soll, noch nicht eingetroffen ist, sondern erst zu einem späteren Zeitpunkt, wird es am Ziel vernichtet und gilt als verloren. Daher gibt es einen Zusammenhang zwischen der Zwischenspeicherungszeit im J-AP und Paketverlusten. Wie Abbildung 4.1-5 zeigt, stellt die Fläche unter der Verteilungsfunktion für Verzögerung die Werte von tÜ, die größer als TÜ +TJP sind, ein Maß für die Paketverlust- versus Paketwahrscheinlichkeit und damit auch für die Paketverlustrate dar. Mit den zu- verluste nehmenden Werten von TJP verringert sich die Paketverlustrate „auf Kosten“ der zusätzlichen Verzögerung. Mit der Reduzierung der Werte von TJP verringert sich aber die Verzögerung „auf Kosten“ der Paketverluste. Daher gibt es keinen optimalen Wert von TJP, sondern immer nur einen Kompromiss zwischen Verzögerung und Paketverlusten.
2
Hierbei wird die Angabe Timestamp im Header von RTP-Paketen (s. Abb. 5.3-5) verwendet.
124
4
VoIP und QoS in IP-Netzen
4.2
Verfahren zur Garantie von QoSAnforderungen
Um die QoS-Anforderungen in IP-Netzen bei VoIP garantieren zu können, kommen unterschiedliche Ansätze in Frage. Hierzu gehört: Einsatz in lokalen Netzwerken
Einsatz in Weitverkehrsnetzen
Priorisierung von MAC-Frames Den sog. MAC-Frames (Media Access Control) mit IP-Paketen in lokalen Netzwerken werden unterschiedliche Prioritäten zugeordnet. Damit können die MAC-Frames mit Sprache vorrangig vor den MAC-Frames mit Daten im Netzwerk behandelt werden. Die Priorisierung von MAC-Frames kann nur in lokalen Netzwerken auf Basis von Ethernet-Switches zum Einsatz kommen. Auf diesen Ansatz geht Abschnitt 4.3 ein. Priorisierung von IP-Paketen Diese Lösung besteht darin, dass IP-Pakete mit Sprache im Vergleich zu IP-Paketen mit Daten höhere Prioritäten erhalten. Damit können IP-Pakete mit Sprache in Routern vorrangig vor IP-Paketen mit Daten behandelt werden. Weil dies eine Differenzierung der Paketströme darstellt, bezeichnet man den Ansatz als Differentiated Services (Differenzierte Dienste, kurz DiffServ). DiffServ werden in Abschnitt 4.4 detaillierter beschrieben.
www.wiwobooks.com
Wofür QueueManagement?
Bedeutung von RSVP
Queue-Management Um über eine Leitung im IP-Netz mehrere Ströme von IP-Paketen mit verschiedenen Prioritäten zu übermitteln, müssen mehrere Warteschlangen (Queues) von IP-Paketen, die auf das Aussenden warten, organisiert werden. Eine Warteschlange kann man als Kommunikationspuffer ansehen. Für einige Paketströme lässt sich auch eine bestimmte Bandbreite der Leitung reservieren. Dies führt dazu, dass die Warteschlangen mit den wartenden IPPaketen entsprechend organisiert und verwaltet werden müssen. Für dieses sog. Queue-Management wurden verschiedene Verfahren konzipiert, die in Abschnitt 4.5 dargestellt werden. Reservierung von Ressourcen in IP-Netzen Bei VoIP und Videokommunikation müssen kontinuierliche Bitströme in Form von IP-Paketen über IP-Netze übermittelt werden. Dafür können bestimmte Ressourcen im IP-Netz reserviert werden. Dies ist nach dem Protokoll RSVP (Resource reSerVation Protocol) möglich. Mit RSVP kann man eine gewünschte Bandbreite für eine virtuelle Verbindung reservieren. RSVP ist zwar theoretisch ein hochinteressantes Protokoll, in der Praxis hat es jedoch keine große Akzeptanz gefunden. RSVP wird in Abschnitt 4.6 näher erläutert.
4.3 Priorisierung von MAC-Frames
125
Übermittlung der IP-Pakete im „Gänsemarsch“ Die klassischen IP-Netze funktionieren nach dem Datagramm-Prinzip. Dies Situation in bedeutet, dass man die einzelnen IP-Pakete unabhängig voneinander über klassischen das Netz transportiert (vgl. Abb. 3.2-3). Die Folge davon ist, dass die ein- IP-Netzen zelnen IP-Pakete auf einer virtuellen Verbindung für VoIP über unterschiedliche Wege transportiert werden. Handelt es sich bei einer virtuellen Verbindung um eine weite Strecke, sind die Übermittlungszeiten einzelner IPPakete sehr unterschiedlich und breit gestreut. Daher sind die Jitter-Werte groß, und um sie auszugleichen, müssen die empfangenen IP-Pakete in einem Jitter-Ausgleichpuffer entsprechend lang zwischengespeichert werden. Falls die Zwischenspeicherungszeit im Jitter-Ausgleichpuffer zu kurz ist, führt sie zur Steigerung der Paketverlustrate (vgl. Abb. 4.1-5). Ein Ausweg aus dem eben geschilderten Dilemma ist dadurch möglich, dass man vor der Übermittlung der IP-Pakete auf einer virtuellen Verbindung zuerst eine optimale Route zum Ziel findet und danach alle IP-Pakete über diese optimale Route im „Gänsemarsch“ übermittelt. Die Vorteile sind offensichtlich: Die Reihenfolge der IP-Pakete wird garantiert, und alle IPPakete legen den gleichen physikalischen Weg über das Netz zurück, sodass auch die Jitter-Werte reduziert werden. Diesen Ansatz bezeichnet man als MPLS (Multi-Protocol Label Switching). MPLS wird hauptsächlich in Weitverkehrsnetzen eingesetzt. Eine fundierte Beschreibung von MPLS enthält [BaHo 07]. Für weitere Informationen über MPLS sei auf die Webquellen [Web 04] verwiesen.
Übermittlung der IPPakete nach optimaler Route
www.wiwobooks.com
4.3
Priorisierung von MAC-Frames
In lokalen Netzwerken auf Basis der Ethernet-Technik kann die QoS-Unterstützung bei VoIP durch die Vergabe verschiedener Prioritäten für sog. MACFrames (Media Access Control) erfolgen. Einen MAC-Frame kann man als Umschlag für die Übermittlung der IP-Pakete ansehen. Die Priorisierung von MAC-Frames bzw. Layer-2-Priorisierung wird in Abbildung 4.3-1 dargestellt. Wie die MAC-Frames priorisiert werden können, beschreiben die Standards VLAN-Tag IEEE 802.1p und IEEE 802.1Q. Nach diesen Standards kann ein VLAN-Tag in mit Angabe den MAC-Header eingebettet werden. Dieser Tag wurde konzipiert, um sog. der Priorität Virtual Local Area Networks (kurz VLANs) zu bilden. Im VLAN-Tag sind drei Bits als User Priority enthalten, die man zur Priorisierung von MAC-Frames verwenden kann. Den MAC-Frames mit Sprache wird eine höhere Priorität im Vergleich zu den MAC-Frames als denen mit Daten zugewiesen. Damit werden sie in Layer-2-Switches, d.h. in Ethernet-Switches, im lokalen Netzwerk vorrangig behandelt und ihre Übermittlungszeit reduziert.
126
4
VoIP und QoS in IP-Netzen
... L 2 S
...
L 2 S
L 2 -P rio
L a y e r-3 -P rio ris ie ru n g
H T
U s e r P rio
M A C -F ra m e
L 2 S L 2 -P rio
IP -H
IP -P a k e t 3 B its
L 3 S & R
IP -N e tz
...
... L 2 S
L 3 S & R
P a y lo a d A b b ild u n g
T o S /D S IP -P a k e t
H T IP -P a k e t
R T P U D P
A b b ild u n g
U s e r P rio
M A C -F ra m e
Abb. 4.3-1: Beispiel für eine Anwendung der Priorisierung von MAC-Frames DS: Differentiated Services, H: MAC-Header, T: MAC-Trailer, IP-H: IP-Header, L2-Prio: Layer-2-Priorisierung, LxS: Layer-x-Switch, R: Router, ToS: Type of Service
Sollte eine Kommunikation über ein IP-Netz erfolgen, in dem die Layer-3Priorisierung unterstützt wird, kann die Priorität vom MAC-Frame auf die Priorität des IP-Pakets abgebildet werden. Einen derartigen Fall illustriert Abbildung 4.3-1. Die Priorität des IP-Pakets wird in seinem Header entweder im Feld ToS (Type of Service) oder im Feld DS (Differentiated Services) eingetragen (s. auch Abb. 3.3-1). Soll ein priorisiertes und von „außen“ eintreffendes IP-Paket im lokalen Netzwerk übermittelt werden, lässt sich seine Priorität auf die Priorität des MAC-Frame abbilden. Eine derartige Abbildung von Prioritäten unterstützen Netzwerkkomponenten namhafter Hersteller.
www.wiwobooks.com
4.4 DiffServ als Priorisierung von IP-Paketen
Differentiated Services
Um die QoS-Anforderungen bei VoIP zu erfüllen, müssen die Ströme von IPPaketen mit Sprache im IP-Netz mit einer höheren Priorität als IP-Pakete mit Daten behandelt werden. Dies führt zur Differenzierung der übertragenen Datenströme, sodass man von Differentiated Services, kurz DiffServ (DS), spricht. DiffServ wurden im IETF-Dokument RFC 2474 spezifiziert.3 Wie Abbildung 4.4-1 zeigt, wird bei DiffServ ein spezielles Feld, das sog. DS-Feld, definiert, um die zu übertragenden IP-Pakete entsprechend differenzieren zu können. Das DS-Feld kann im Header des Protokolls IP sowohl in der Version 4 (IPv4) als auch in der Version 6 (IPv6) eingekapselt werden. 3
Die Spezifikation von DiffServ in RFC 2474 wurde inzwischen durch RFCs 3168 und 3260 etwas modifiziert.
4.4 Differentiated Services
a )
0
1
2
3 4 D S C P D S -F e ld T o S
5
T C P /U D P
6
7
C U /E C N
D a te n
IP v 4 -H e a d e r
b )
0
1
2
3 4 D S C P D S -F e ld T ra ffic C la s s
T C P /U D P
5
6
127
7
C U /E C N
D a te n
IP v 6 -H e a d e r
Abb. 4.4-1: Angabe für die Differenzierung von: a) IPv4-Paketen, b) IPv6-Paketen ToS: Type of Service, DSCP: DiffServ Codepoint, CU: Currently Unused 4
Für die Realisierung von DiffServ bei IPv4 wird das ToS-Feld (Type of Servi- DiffServ ce) im IPv4-Header genutzt. Wie in Abbildung 4.4-1a ersichtlich ist, wird dabei bei IPv4 das ToS-Feld im IPv4-Header durch das DS-Feld ersetzt. DSCP (DiffServ Code Point) im DS-Feld kann man als Priorität des Pakets ansehen. Bei IPv6 wurde zuerst das Feld Traffic Class im Header vorgesehen, um die DiffServ IPv6-Pakete verschiedenen Verkehrsklassen zuordnen zu können. Dieser An- bei IPv6 satz war mit dem DiffServ-Konzept vergleichbar. Weil aber DiffServ bei IPv4 schnell breite Akzeptanz fand, wurde DiffServ auch bei IPv6 in der gleichen Form realisiert. Somit wird das Feld Traffic Class im IPv6-Header durch das DS-Feld ersetzt (Abb. 4.4-1b).
www.wiwobooks.com
4.4.1 Differenzierung der IP-Pakete Die Markierung der IP-Pakete für die Klassifizierung nach DiffServ durch das KlassifizieSetzen von DSCP-Bits im DS-Feld übernimmt entweder eine Applikation im rung der Quellrechner oder ein Router am Eingang zu einem Transitnetz. Die Klassifi- IP-Pakete zierung kann nach Quell- und Ziel-IP-Adressen oder nach dem Transportprotokoll (TCP, UDP) bzw. nach der Nummer des Ziel-Ports (d.h. nach der Applikation) erfolgen. Zur Klassifikation von Strömen von IP-Paketen dienen die ersten 6 Bits im DSFeld, die man als DSCP bezeichnet. Die IP-Pakete mit gleichem DSCP-Wert bilden einen Strom von IP-Paketen, der auf die gleiche Weise im Netz behandelt wird. Durch DSCP kann man einerseits den zu übertragenden IP-Paketen theoretisch bis zu 64 verschiedene Prioritäten vergeben; andererseits stellen die bestehenden Transportnetze (wie z.B. ATM-Netze) nur bestimmte Netzdienste zur Verfügung, weshalb in der Praxis nur wenige Dienstklassen und somit auch Prioritätsklassen unterstützt werden. Man muss daher angeben, nach welchen Netzdiensten die IP-Pakete mit glei- Behandchen DSCP-Werten transportiert werden sollen. Liegt beispielsweise ein IP- lungsklassen 4
Nach RFC 2474 werden diese Bits nicht verwendet. Gemäß RFC 3168 sollen sie für die Überlastkontrolle nach dem Verfahren ECN (Explicit Congestion Notification) verwendet werden.
128
4
VoIP und QoS in IP-Netzen
Paket mit DSCP = x zum Senden vor, muss irgendwo ablesbar sein, nach welchem Dienst im Transportnetz dieses IP-Paket übermittelt werden soll. Die Art der Behandlung der IP-Pakete in einem Transportnetz bestimmen wiederum die Dienste in diesem Netz. Um die Behandlung der IP-Pakete bei DiffServ zu spezifizieren, werden die Behandlungsklassen, sog. Per Hop Behaviours (PHB), eingeführt. Wie Abbildung 4.4-2 zeigt, ordnet man oft mehrere DSCP-Werte einer Behandlungsklasse zu. D S C P s
P rio ritä t
h o c h
n ie d rig
...
B e h a n d lu n g s k la s s e P H B = a
... ...
C la s s o f S e rv ic e
A T M -D ie n s t
C o S = 1
C B R
P H B = b
C o S = 2
A B R
P H B = c
C o S = 3
U B R
Abb. 4.4-2: Behandlungsklassen von IP-Paketen und Netzdienste A/C/UBR: Available/Constant/Unspecified Bit Rate ATM: Asynchronous Transfer Mode
www.wiwobooks.com
Anhand von DSCP im IP-Paket wird entschieden, welche PHB darauf anwendbar sind. Ein PHB-Wert entspricht einer Dienstklasse CoS (Class of Service) eines Übermittlungsnetzes. Wie Abbildung 4.4-2 zeigt, bestimmt ein PHB-Wert einen Dienst in einem Übermittlungsnetz (wie z.B. ATM-Netz), nach dem die Übermittlung der IP-Pakete erfolgen soll. Zuordnungen DSCP-toCoS
Da die PHB-Werte als Identifikationen der Netzdienste (d.h. von CoS) dienen, müssen die Router in IP-Netzen eine Tabelle mit der Zuordnung DSCP-Wert (e)
PHB-Wert
enthalten, um die Dienstklasse CoS zu bestimmen. Aus dieser Tabelle resultieren die Zuordnungen DSCP-Wert (e)
CoS = x (x = 1, 2,...).
PHB bestimmt das Verhalten eines Routers beim Weiterleiten von IP-Paketen unter Berücksichtigung des DSCP-Wertes. Anhand von DSCP im IP-Paket entscheidet ein Router, welcher PHB (d.h. welcher Dienst im Übermittlungsnetz) angewandt werden soll. Jedem DSCP-Wert entspricht genau ein PHB-Wert.
4.4.2 DiffServ-Domäne und -Region DiffServDomäne
DiffServ wurden entwickelt, um die QoS-Anforderungen in Backbone- bzw. Transit-IP-Netzen zu gewährleisten. Ein IP-Netz mit DiffServ, das eine administrative Einheit darstellt, wie z.B. in einem Unternehmen bzw. bei einem Network Service Provider (NSP), wird als DiffServ-Domäne (bzw. DiffServ-
4.4 Differentiated Services
129
Domain) bezeichnet. Abbildung 4.4-3 zeigt eine DiffServ-Domäne, über die zwei IP-Netze eines Unternehmens verbunden werden. Zwischen dem Unternehmen und dem NSP wurde ein Vertrag abgeschlossen, in dem die Art und Weise der QoS-Unterstützung in Form eines SLA (Service Level Agreement) festgelegt wurde. In jeder DiffServ-Domäne sind folgende Typen von Routern, je nach der „Stelle“ in der DS-Domäne, zu unterscheiden: Eingangs-Router (Ingress Router), Interner Router (Interior Router) und Ausgangs-Router (Egress Router). Die Aufgaben eines Routers bei der QoS-Unterstützung nach DiffServ sind von seinem Typ anhängig. Dies bringt Abbildung 4.4-3 zum Ausdruck. S L A
K la s s ifiz ie ru n g D ro p p in g S h a p in g R o u tin g Q u e u e in g
R
...
R
...
In t-R o u te r
... ...
A u sR o u te r
D S -D o m ä n e
...
R
...
... ...
IP -N e tz A
E in R o u te r
R o u tin g Q u e u e in g
IP -N e tz B
R o u tin g Q u e u e in g S h a p in g
www.wiwobooks.com Abb. 4.4-3: DiffServ-Domäne und Funktionen von Routern (R) Ein/Int/Aus-Router: Eingangs-/Interner/Ausgangs-Router
In einem Eingangs-Router kann man die eintreffenden IP-Pakete zuerst klassi- Eingangsfizieren, sodass mehrere Klassen von IP-Paketen entstehen. Jede Klasse wird Router mit einer Angabe im DS-Feld markiert (s. Abb. 4.4-1). Für jede Klasse von IPPaketen kontrolliert man die mittlere Anzahl der Pakete pro festgelegter Zeiteinheit, sodass die durchschnittliche Datenrate geschätzt wird. Falls diese Datenrate die vereinbarte Datenrate (Bandbreite) überschreitet, werden einige IP-Pakete aus dieser Klasse am Netzeingang entweder direkt verworfen (Dropping) bzw. kurz verzögert und danach weitergeleitet (Shaping). Auf diese Weise realisiert man eine Zulassungskontrolle, um die für eine Klasse von IP-Paketen vereinbarte Bandbreite nicht zu überschreiten. In Transit-Routern findet keine Zulassungskontrolle statt. Nach dem Routing Transitwerden die IP-Pakete zum Absenden gemäß ihrer Klasse in eine Warteschlange Router vor einer Leitung eingereiht (Queueing). In Ausgangs-Routern lässt sich im Vergleich zu den Transit-Routern zusätzlich Ausgangsder Datenverkehr entsprechend formen (Shaping). Beispielsweise kann das Router Shaping des Datenverkehrs im Ausgangs-Router durch den Einsatz eines JitterAusgleichpuffers (s. Abb.5.6-1) dazu führen, dass die IP-Pakete in gleichen Zeitabständen abgeschickt werden.
130 DiffServRegion
4
VoIP und QoS in IP-Netzen
Eine Vernetzung von mehreren DiffServ-Domänen bildet eine DiffServ-Region. Dies illustriert Abbildung 4.4-4. Soll die Kommunikation über eine DiffServRegion erfolgen, müssen die QoS-Anforderungen gleichzeitig in mehreren DiffServ-Domänen erfüllt werden. Somit spricht man von Ende-zu-Ende-QoS. E n d e -z u -E n d e -Q o S D iffS e rv -R e g io n IP N e tz R
D iffS e rv D o m ä n e 1
D iffS e rv D o m ä n e 2
N S P 2 N S P 1 S L S 1 : S L S 2 : B e n u tz e r -N S P 1 N S P 1 -N S P 2
R
IP N e tz
S L S 3 : N S P 2 -Z ie l
Abb. 4.4-4: Veranschaulichung einer DiffServ-Region NSP: Network Service Provider, SLS: Service Level Specification
Werden Quelle und Ziel an verschiedenen DiffServ-Domänen „angeschlossen“, muss jeder NSP mit seinem Nachbar-NSP bestimmte technische Vereinbarungen in Form von SLA treffen, um die Art und Weise der Unterstützung der gewünschten QoS-Anforderungen festzulegen.
www.wiwobooks.com
Falls die Kommunikation über ein IP-Teilnetz verläuft, in dem keine DiffServ unterstützt werden, können die QoS-Anforderungen an der gesamten Ende-zuEnde-„Strecke“ nicht erfüllt werden. Für weitere Informationen über DiffServ sei auf [Web 03] verwiesen.
4.5 Was ist QueueManagement ?
Queue-Management
Die zu übertragenden IP-Pakete müssen in der Regel vor der Leitung auf das Aussenden warten. Daher müssen sie temporär gespeichert werden. Hierfür werden im Speicher entsprechende Warteschlangen (sog. Queues) organisiert, sodass man auch vom Queueing in IP-Netzen spricht. Da IP-Pakete mit Sprache oder Video in Netzknoten vorrangig zu behandeln sind, benötigt man mehrere Warteschlangen, die entsprechend verwaltet werden müssen. Unter dem Begriff Queue-Management fasst man unterschiedliche Verfahren zusammen, die bestimmen, wie die Warteschlangen der zu sendenden IP-Pakete organisiert und die einzelnen Warteschlangen „bedient“ werden. Bemerkung: Queue-Management tritt nicht nur in IP-Netzen auf, sondern auch in anderen Netzen mit Paketvermittlung. Mit Queue-Management hat man auch in Rechnerbetriebssystemen zu tun, wo die einzelnen Aufgaben (sog. Tasks) auf den Prozessor warten müssen.
131
Um mehrere Ströme von IP-Paketen über eine Leitung zu übermitteln, wird ein Multiplexer eingesetzt. Von großer Bedeutung in IP-Netzen sind sog. statistische Multiplexer, in denen die empfangenen IP-Pakete temporär gespeichert werden. Bildet man mehrere Klassen von IP-Paketen nach bestimmten Kriterien, muss man auch mehrere Warteschlangen organisieren. Wie Abbildung 4.5-1 zeigt, findet in einem Multiplexer ein Queue-Management statt.
QueueManagement im Multiplexer
E IN 1
E
E IN
...
...
a n k o m m e n d e IP -P a k e te
4.5 Queue-Management
E k
Q u e u e M a n a g a m e n t S
A U S 1
a b g e s c h ic k te IP -P a k e te
Abb. 4.5-1: Queue-Management in einem Multiplexer EIN/AUS: Ein/Ausgangsleitung, E: Empfänger, S: Sender
www.wiwobooks.com Q M
E IN k
... E
F
A U S
S
Q M
1
S
A U S k
a b g e s c h ic k te IP -P a k e te
E
...
1
...
E IN
...
a n k o m m e n d e IP -P a k e te
Im IP-Netzknoten (Switch, Router) findet Queue-Management immer vor Ausgangsleitungen statt. Dies veranschaulicht Abbildung 4.5-2.
Abb. 4.5-2: Queue-Management (QM) im IP-Netzknoten vor Ausgangsleitungen EIN/AUS: Ein/Ausgangsleitung, E: Empfänger, F: Forwarding, S: Sender
Die in einem IP-Netzknoten empfangenen IP-Pakete werden zum Modul übergeben, wo sie zu einer Ausgangsleitung weitergeleitet werden. Dieses Modul wird im Allgemeinen als Forwarder bezeichnet und realisiert in einem Switch das Switching bzw. in einem Router das Routing. Diese beiden Funktionen bestehen in der Weiterleitung von empfangenen IP-Paketen an die in ihnen enthaltenen Ziel-IP-Adressen. Abbildung 4.5-3 zeigt die Struktur eines Queue-Management-Systems. Beim Funktionen bei QueueQueue-Management unterscheidet man folgende Funktionen: Klassifizierung: Die zu sendenden IP-Pakete werden im Klassifizierer nach bestimmten Kriterien klassifiziert. Als Kriterium kann z.B. der Ziel-Port (d.h. die Anwendung) und/oder die Ziel-IP-Adresse verwendet werden. Queueing: Die einer bestimmten Klasse zugeordneten IP-Pakete werden in die dieser Klasse zugeordnete Warteschlange eingereiht.
Management
132
4
VoIP und QoS in IP-Netzen
E IN k
Q 1
Q Q
2
n
S c h e d u lin g
...
1
...
E IN
K la s s ifiz ie re ru n g
Scheduling: Hierbei handelt es sich um die Regel, nach der die IP-Pakete aus den einzelnen Queues zum Senden übergeben werden. Das Scheduling ist der eigentliche Kern des Queue-Managements.
A U S
Abb. 4.5-3: Struktur eines Queue-Management-Systems EIN/AUS: Ein/Ausgangsleitung, Q: Warteschlange (Queue)
QueueManagementVerfahren
Es werden u.a. folgende Verfahren bei Queue-Management verwendet: FIFO (First In First Out): Hierbei handelt es sich um die einfachste Lösung, bei der man die empfangenen IP-Pakete nicht klassifiziert. Sie werden in der Reihenfolge gesendet, in der sie empfangen wurden. FIFO hat bei VoIP keine Bedeutung.
www.wiwobooks.com
PQ (Priority Queueing): Nach PQ werden die empfangenen IP-Pakete zuerst klassifiziert und anschließend bestimmte Prioritäten den einzelnen Klassen zugeordnet. CQ (Custom Queueing): Dieses Verfahren ermöglicht, mehrere Warteschlangen so zu organisieren, dass sie zyklisch nach einer festgelegten Reihenfolge geleert werden. CBQ (Class-Based Queueing): Die ankommenden IP-Pakete ordnet man verschiedenen Klassen zu. FQ (Fair Queueing): Nach diesem Verfahren werden die einzelnen IP-Pakete aus mehreren Paketströmen in der gleichen Reihenfolge bedient, in der sie eingetroffen sind. Alle Paketströme werden gleich behandelt. WFQ (Weighted Fair Queueing): Im Vergleich zu FQ werden die einzelnen Paketströme bei diesem Verfahren nicht gleich behandelt. CBWFQ (Class-based Weighted Fair Queueing): Dies ist eine Erweiterung des WFQ-Verfahrens. Durch den Einsatz diverser Queue-Management-Verfahren ist es möglich, QoSAnforderungen besser zu erfüllen. Auf die wichtigsten Verfahren gehen wir nun näher ein.
4.5 Queue-Management
4.5.1 Priority Queueing Beim Priority Queueing (PQ) werden mehrere Warteschlangen (Queues) vor einer Ausgangsleitung gebildet, die man als Kommunikationspuffer ansehen kann. Abbildung 4.5-4 illustriert das Prinzip von PQ am Beispiel eines Multiplexers. Hier werden mehrere Ströme von (IP-)Paketen über eine Ausgangsleitung übermittelt. Die empfangenen IP-Pakete werden zuerst im Klassifizierer nach bestimmten Kriterien klassifiziert und anschließend in der Reihenfolge, in der sie empfangen wurden, zum Senden in eine Warteschlange eingereiht.
1 2 3
3 4
4 5 6
5
3 1
K la s s ifiz ie r
2
H o h e P r io r itä t 1
1
1
1
6 2
6
5 1
M u ltip le x e r
1
Q 1
M ittle r e P r io r itä t 6
6 2
2 1
Q 1
2
N ie d r ig e P r io r itä t 1 2
4 1
1 1
1
Q
S c h e d u le r
E in g a n g s le itu n g e n
P a k e ts trö m e : 1 2 1
A u sg a n g sle itu n g
3
www.wiwobooks.com
Abb. 4.5-4: Priority Queueing in einem Multiplexer
Q: Warteschlange (Queue) nach dem FIFO-Prinzip
Bei PQ werden in der Regel drei Warteschlangen Q1, Q2 und Q3 organisiert, die in einer Hierarchie zueinander stehen, nach der sie bedient werden. Diese Warteschlangen „bedient“ man nach dem FIFO-Prinzip. Dabei werden folgende Prioritätsstufen gebildet: hohe Priorität (High Priority) mittlere Priorität (Medium Priority) niedrige Priorität (Low Priority) Die Aufgabe des Schedulers besteht darin, die in den Wartenschlangen „wartenden“ Pakete zum Senden zu übergeben. Die Warteschlange Q1 hat die höchste Priorität und wird zuerst bedient. Ist Q1 leer, wird Q2 mit mittlerer Priorität bedient, falls sie nicht leer ist. Sind beide Q1 und Q2 leer, dann kann man Q3 mit niedriger Priorität bedienen. Ein wesentlicher Vorteil von PQ ist das Aufteilen des Datenverkehrs in bestimmte Klassen, um zu garantieren, dass die IP-Pakete mit Sprache früher als IP-Pakete mit Daten weitergeleitet werden. Falls viele IP-Pakete mit höheren Prioritäten ankommen, müssen IP-Pakete mit niedrigerer Priorität lange auf das Absenden warten. Ist die Leitung mit Paketen höherer Priorität ausgelastet, kann dies dazu führen, dass die Pakete aus den Warteschlangen mit geringeren Prioritäten nie gesendet werden. Dies ist der Nachteil von PQ.
133
4
VoIP und QoS in IP-Netzen
4.5.2 Custom Queueing Nach Custom Queueing (CQ) werden mehrere Warteschlangen vor einer Ausgangsleitung organisiert, von denen jede nach dem FIFO-Prinzip funktioniert. CQ wird hauptsächlich in den IP-Netzen verwendet, die Systemkomponenten der Firma Cisco einsetzen. Für das gleiche Queue-Management-Konzept verwendet man auf den Gebieten Netzwerke und Rechnersysteme auch die Begriffe CBQ (Class-Based Queueing) und WRR (Weighted Round Robin). Abbildung 4.5-5 illustriert CQ am Beispiel eines Multiplexers. Hier werden die empfangenen IP-Pakete zuerst im Klassifizierer nach bestimmten Kriterien klassifiziert und zum Senden in eine Warteschlange eingereiht. Bei CQ werden mehrere Warteschlangen organisiert, die von einem Scheduler zyklisch und nacheinander abgearbeitet werden. Man bezeichnet ein derartiges SchedulingPrinzip als Round Robin. W E
2 E
K la s s ifiz ie re r
IP -P a k e te : 1 E in g a n g s le itu n g e n
1
M u ltip le x e r
W
Q 2
Q
1
www.wiwobooks.com 3
4
E
6
5
E E
W n
Q
2
S c h e d u le r
134
S
A u sg a n g sle itu n g
n
E
Abb. 4.5-5: Einsatz von Custom Queueing in einem Multiplexer E: Empfänger, S: Sender, Q: Warteschlange (Queue), Wi: Gewichtung von Qi
Jeder Warteschlange Qi, i = 1, ..., n, wird eine Gewichtung (Weight) Wi zugeordnet, die oft den Teil der Bandbreite der Leitung repräsentiert, der dieser Warteschlange garantiert werden soll. Die Gewichtung Wi kann entweder in die Anzahl BCi (Byte-Count) von Bytes bzw. in die Anzahl Pi von Paketen umgerechnet werden, die der Scheduler in jeder Runde (in jedem Zyklus) aus der Warteschlange Qi, zum Senden übergeben soll. Bei CQ springt der Scheduler von einer Warteschlange zur anderen und übergibt aus der Warteschlange Qi eine entsprechende Anzahl von Paketen zum Senden, die aus der Gewichtung Wi abgeleitet wird. In Überlastsituationen stellt CQ sicher, dass jede Warteschlange nur den vereinbarten Anteil von der Bandbreite der Leitung erhält. Beispiel 1: Über eine Leitung mit der Bandbreite B werden drei verschiedene Ströme von IPPaketen übertragen. Diesen Paketströmen sollen folgende Teile der Bandbreite B der Leitung zugeteilt werden: • 0.5B dem Paketstrom 1,
4.5 Queue-Management • 0.25B dem Paketstrom 2 und • 0.25B dem Paketstrom 3. Es wird angenommen, dass die Länge der IP-Pakete in allen Paketströmen konstant und identisch ist. Die Zuteilung der Bandbreite zu den einzelnen Paketströmen soll nach CQ realisiert werden. Hierfür wird der Warteschlange Qi (i = 1, 2, 3) eine Gewichtung Wi zugeordnet, die dem Teil der Bandbreite der Leitung entspricht, die für Qi garantiert werden soll. Wie Abbildung 4.5-6 zeigt, werden die Werte W1 = 0.5, W2 = 0.25 und W3 = 0.25 den Warteschlangen Q1, Q2 und Q3 zugeordnet.
E 2
3
n
E
E
= 0 .5 , P 1= 2 1
Q W
Q W 3
2
= 0 .2 5 , P 3= 1 Q
...
1
= 0 .2 5 , P 2= 1 2
3
S c h e d u le r
W E K la s s ifiz ie re r
E in g a n g s le itu n g e n
1
S
4
S c h e d u le r-R u n d e : 3 2 1
R e ih e n fo lg e a u f d e r L e itu n g M u ltip le x e r
Abb. 4.5-6: CQ für Aufteilung der Bandbreite B auf drei Teile: 0.5B, 0.25B und 0.25B Die Länge der Pakete ist konstant. E: Empfänger, S: Sender, Q: Warteschlange (Queue), Wi: Gewichtung von Qi
www.wiwobooks.com
Für den Scheduler müssen die Zahlen P1, P2 und P3 angegeben werden, d.h. die Anzahl von Paketen, die er in jeder Runde aus Q1, Q2 und Q3 zum Senden übergeben muss. Da die Länge der Pakete in allen Paketströmen konstant und gleich ist, können die Zahlen P1, P2 und P3 wie folgt errechnet werden: Dividiere die Gewichtung (d.h. den Teil der Bandbreite der Leitung) durch die kleinste Gewichtung. Danach sollen (nach Bedarf) die einzelnen Resultate zu ganzen Zahlen aufgerundet werden. Für die einzelnen Warteschlangen ergeben sich nun folgende Zahlen: • Q1: 0.5/0.25 = 2 = P1 = P2 • Q2: 0.25/0.25 = 1 • Q3: 0.25/0.25 = 1 = P3 In jeder Runde des Schedulers sollen somit 2 Pakete aus Q1, 1 Paket aus Q2 und 1 Paket aus Q3 zum Senden übergeben werden. Beispiel 2: Es wird angenommen, dass die Bandbreite B einer Leitung wie im Beispiel 1 aufgeteilt werden soll, und dass die Länge der IP-Pakete in allen Paketströmen variabel ist. Die mittlere Länge der IP-Pakete beträgt: 500 Bytes im Paketstrom 1, 300 Bytes im Paketstrom 2 und 100 Bytes im Paketstrom 3. Die Zuteilung der Bandbreite zu den einzelnen Paketströmen soll nach CQ realisiert werden. Wie Abbildung 4.5-7 zeigt, werden folgende Werte W1 = 0.5, W2 = 0.25 und W3 = 0.25 entsprechend Q1, Q2 und Q3 zugeordnet (vgl. Abb. 4.5-6). Für den Scheduler müssen noch die Zahlen P1, P2 und P3 angegeben werden, d.h. die Anzahl der Pakete, die er aus den einzelnen Warteschlangen in jeder Runde zum Senden übergeben soll. Die Berechnung der Angaben P1, P2 und P3 erfolgt in den folgenden Schritten: 1.
Berechne das Verhältnis der maximalen mittleren Paketlänge zu den mittleren Paketlängen in den einzelnen Paketströmen: • Paketstrom 1: 500/500 = 1
135
VoIP und QoS in IP-Netzen Paketstrom 2: 500/300 = 1.65 Paketstrom 3: 500/100 = 5
E in g a n g s le itu n g e n
• •
E 2
E
W
1
3
E
M u ltip le x e r
= 0 .5 , P 1= 2 Q
E
n
1
W 2
1
= 0 .2 5 , P 2= 1
W
Q 3
= 0 .2 5 , P 3= 3
2
Q
S c h e d u le r
4
K la s s ifiz ie re r
136
...
S c h e d u le r-R u n d e : 2 1
S R e ih e n fo lg e a u f d e r L e itu n g
3
Abb. 4.5-7: CQ für Aufteilung der Bandbreite B auf drei Teile: 0.5B, 0.25B und 0.25B Die mittlere Länge der Pakete einzelner Paketströme ist nicht gleich. E: Empfänger, S: Sender, Q: Warteschlange (Queue), Wi: Gewichtung von Qi
2.
Multipliziere das im Schritt 1 errechnete Verhältnis mit dem Anteil der Bandbreite, den man den einzelnen Paketströmen zuteilen möchte: • Paketstrom 1: 0.50 * 1 = 0.50 • Paketstrom 2: 0.25 * 1.65 = 0.4175 • Paketstrom 3: 0.25 * 5 = 1.25 3. Die im Schritt 2 errechneten Werte werden normalisiert. Sie werden nun durch den kleinsten Wert dividiert. Danach werden die Ergebnisse zu ganzen Zahlen aufgerundet. • Paketstrom 1: 0.5/0.4175 = 1.19 2 (P1) • Paketstrom 2: 0.4175/0.4175 = 1 1 (P2) • Paketstrom 3: 1.25/0.4175 = 2.99 3 (P3) Die im Schritt 3 errechneten Werte P1, P2 und P3 ergeben die Anzahl der Pakete, die aus den einzelnen Warteschlangen in jeder Scheduler-Runde zum Senden übergeben werden sollen. Es werden 2 Pakete aus Q1, 1 Paket aus Q2 und 3 Pakete aus Q3 in jeder Scheduler-Runde zum Senden übergeben (Abb. 4.5-7).
www.wiwobooks.com
Bemerkung: In einigen Routern muss die Anzahl von Bytes angegeben werden, die in jeder Scheduler-Runde aus den einzelnen Warteschlangen zum Senden übergeben werden soll.
CQ und Aufteilung der Bandbreite
Bei CQ werden die zu sendenden Pakete zuerst klassifiziert und für jede Klasse von Paketen wird eine Warteschlange organisiert. Jeder Klasse kann hierbei eine bestimmte Bandbreite einer Leitung garantiert werden. Somit eignet sich CQ gut für Anwendungen, bei denen die Bandbreite einer Leitung auf mehrere Ströme von Paketen aufgeteilt werden soll. Eine bestimmte Bandbreite einer Leitung kann einer Klasse von Paketen aber nur (genau!) dann garantiert werden, wenn die Länge der Pakete aller Klassen konstant und gleich ist (vgl. Abb. 4.5-6). Ist die Länge der Pakete der einzelnen Klassen variabel, so lässt sich die Bandbreite der Leitung nur dann aufteilen, wenn die mittlere Länge der Pakete jeder Klasse bekannt ist. Die Aufteilung der Bandbreite erfolgt (statistisch gesehen) nur nach dem Mittelwert (vgl. Abb. 4.5-7).
137
4.5 Queue-Management
4.5.3 Fair Queueing Fair Queueing (FQ) ermöglicht es, in IP-Netzen einige Ressourcen (wie z.B. die Bandbreite von Leitungen) zwischen mehreren Klassen von Anforderungen gerecht (fair) aufzuteilen. Bei FQ werden mehrere Warteschlangen vor den gewünschten Ressourcen gebildet. FQ wird oft in IP-Netzen verwendet. Abbildung 4.5-8 illustriert den Einsatz von FQ in einem Multiplexer.
2
2 2
3 3 4 4
6 6
2
E 1
E E 1
6 1
1 2
2 E
1
1
5 5
1 E
1
E
Q 1
4
4
Q 1
6
3
Q 1
5 2
2
1
3
6
1
Q
2 2
M u ltip le x e r
Q 1
1
S c h e d u le r
E in g a n g s le itu n g e n
2
1
K la s s ifiz ie re r
IP -P a k e te : 1 1 2
Q
5
S
...
S c h e d u le r-R u n d e : 2 2 2
4 1 2 6 1 5 1 R e ih e n fo lg e b e im 1
1 3 1 2 1 1 A b se n d e n 1
6
www.wiwobooks.com
Abb. 4.5-8: Einsatz von Fair Queueing in einem Multiplexer E: Empfänger, Q: Warteschlange (Queue), S: Sender
Hier soll jeder Strom von ankommenden IP-Paketen gerecht behandelt werden. Für jeden Paketstrom wird eine separate Warteschlange organisiert. Die Bandbreite der Ausgangsleitung stellt die Ressource dar, die zwischen den einzelnen Paketströmen gerecht aufgeteilt werden soll. Die empfangenen IP-Pakete werden durch den Klassifizierer aufgrund der Nummer der Eingangsleitung, auf der sie empfangen wurden, in der dieser Eingangsleitung zugeordneten Warteschlange eingereiht. Eine Warteschlange repräsentiert einen Kommunikationspuffer, in der die IP-Pakete temporär gespeichert werden. Bei FQ funktioniert der Scheduler nach dem sog. Round-Robin-Prinzip. Dabei Scheduler werden die Warteschlangen in jeder Scheduler-Runde zyklisch und nacheinan- bei FQ der so abgearbeitet, dass aus jeder Warteschlange, falls sie nicht leer ist, ein IPPaket zum Sender übergeben wird. Bemerkung: Den einzelnen Warteschlangen lassen sich unterschiedliche Gewichtungen zuordnen. Dies führt dazu, dass aus einer Warteschlange in jeder Scheduler-Runde mehrere IP-Pakete zum Sender übergeben werden können. Dieses Prinzip bezeichnet man als Weighted Fair Queueing (WFQ).
Falls n Warteschlangen Q1, ..., Qn vor einer Leitung mit der Bandbreite B aktiv Aufteilung der Band(d.h. dauerhaft nicht leer) sind, ist bei FQ Folgendes hervorzuheben: breite bei
Hätten alle IP-Pakete in allen Warteschlangen eine konstante und gleiche FQ Länge, stünde die Bandbreite B/n jeder Warteschlange und damit auch je-
138
4
VoIP und QoS in IP-Netzen
dem Paketstrom zur Verfügung. Somit wird die Bandbreite in diesem Fall (aber nur in diesem!) auf alle Paketströme gleich verteilt. Falls die IP-Pakete in der Warteschlange Qi, i = 1, ...n, die mittlere Länge Li haben, steht der Warteschlange Qi statistisch gesehen im Mittel die Bandbreite B•Li/(L1+ ...+ Ln) zur Verfügung. Dieser Fall kommt in der Praxis oft vor. Class-based FQ
Werden die IP-Pakete entsprechend differenziert, z.B. bestimmte Service-Klassen gebildet, spricht man in diesem Fall von Class-based Fair Queueing (Class-based FQ). Abbildung 4.5-9 illustriert das Prinzip von Class-based FQ.
Scheduler bei Classbased FQ
Die empfangenen IP-Pakete werden hier zuerst nach von vornherein festgelegten Kriterien klassifiziert, sodass sog. Service-Klassen entstehen. Beispielsweise können die IP-Pakete mit Sprache eine Service-Klasse bilden. Eine andere Service-Klasse bilden beispielsweise die IP-Pakete von E-Mail-Anwendungen etc. Für jede Service-Klasse wird eine separate Warteschlange organisiert. Class-based FQ soll ermöglichen, die Bandbreite der Ausgangsleitung zwischen den einzelnen Service-Klassen gerecht aufzuteilen.
www.wiwobooks.com
1
1
2
2
2 2
3 3
4 4
5
6
2
5 6 2
1
1
K la s s e 1 6 2 4 1
S
S S
1
S 1
S 1
6 1
S
K la s s e 2 6
Q 2
2
1
Q 5
2
M u ltip le x e r
1
1
1
K la s s e 3 3 1 K la s s e 4 1 2
Q
1
1
3
Q
S c h e d u le r
E in g a n g s le itu n g e n
1
K la s s ifiz ie re r
IP -P a k e te :
S
...
S c h e d u le r-R u n d e : 2 3 6 2
1 2
1
3 1 6 1 4 1 2 2 5 1 2 1 1 R e ih e n fo lg e b e im A b s e n d e n 1
4
2
Abb. 4.5-9: Einsatz von Class-based Fair Queueing in einem Multiplexer Abkürzungen wie in Abb. 4.5-8
Bei Class-based FQ (Abb. 4.5-9) funktioniert der Scheduler nach dem gleichen Verfahren wie bei FQ (Abb. 4.5-8). Der Unterschied besteht darin, dass die Service-Klassen bei Class-based FQ aus den empfangenen IP-Paketen gebildet werden und für jede Service-Klasse eine Warteschlange organisiert wird. Die Anzahl der Warteschlangen bei Class-based FQ ist kleiner als bei FQ. Aufteilung der Bandbreite bei Class-based FQ
Bezüglich der Aufteilung der Bandbreite gelten bei Class-based FQ die gleichen Verhältnisse wie bei FQ. Falls K Service-Klassen gebildet werden und ihre Warteschlangen dauerhaft nicht leer sind, gilt bei Class-based FQ Folgendes: Falls alle IP-Pakete jeder Service-Klasse eine konstante und gleiche Länge haben, steht die Bandbreite B/K jeder Service-Klasse zur Verfügung.
139
4.5 Queue-Management
Falls die IP-Pakete der Service-Klasse k (k= 1, ..., K) die mittlere Länge Lk haben, so steht der Service-Klasse k statistisch gesehen im Mittel die Bandbreite B•Lk/(L1+ ...+ LK) zur Verfügung.
4.5.4 Weighted Fair Queueing Weighted Fair Queueing (WFQ) stellt eine Variante von Fair Queueing (FQ) dar, bei der mehrere Warteschlangen gebildet werden und jeder von ihnen eine Gewichtung (Weight) zugeordnet wird (s. Abbildung 4.5-10). Die empfangenen IP-Pakete werden zuerst klassifiziert, sodass mehrere Paketströme (auch als Flow bezeichnet) gebildet werden. Beispielsweise können alle IP-Pakete einer Applikation, einer Quell-IP-Adresse bzw. alle IP-Pakete der gleichen Priorität einen Paketstrom darstellen. Für jeden Paketstrom wird eine Warteschlange eingerichtet. Jeder Warteschlange wird eine Gewichtung zugeordnet, die den Anteil der Bandbreite B der Leitung darstellt, der für diese Warteschlange verfügbar sein soll.
E in g a n g s le itu n g e n
2
2 2
3 3 4 4 5
6
5 6 2
www.wiwobooks.com 5 0 %
E 1
E 1
E 1
E 1
E 1
6 1
B
6
E
2
4
Q
1
1
1
F T : 9 0 , 5 0 , 3 0 Q 3 0 % B 1 2 2 2 6 1 2 1 F T :1 4 0 ,1 0 5 , 8 5 , 7 0 2 0 %
B 5 1
M u ltip le x e r
1
3
Q
2
S c h e d u le r
2
1
K la s s ifiz ie re r
IP -P a k e te : 1 2 1
S
R e ih e n fo lg e a u f d e r A u s g a n g s le itu n g 5 1 1 2 3 1 2 2 6 2 6 1 2 1 4 1 1 1 1 7 5 ,1 4 0 ,1 3 5 ,1 0 5 , 9 0 , 8 5 ,7 0 , 5 0 , 3 0 F T :
3
1
F T : 1 7 5 , 1 3 5
Abb. 4.5-10: Einsatz von Weighted Fair Queueing in einem Multiplexer B: Bandbreite der Ausgangsleitung, E: Empfänger, FT: Finish Time, Q: Queue, S: Sender
Der Funktionsweise des Schedulers liegt bei WFQ ein theoretisches Modell Scheduler zugrunde, nach dem die Variable FT (sog. Finish Time) für die einzelnen IP- bei WFQ Pakete in allen Warteschlangen berechnet wird. Die FT-Werte bestimmen die Reihenfolge, in der die einzelnen Pakete aus allen Warteschlangen dem Sender übergeben werden sollen. Den Finish Time Wert FTi(k, t) des Pakets k aus der Warteschlange Qi zur Berechnung der FTZeit t berechnet man nach der Formel: FTi(k, t) = max{FTi(k-1, t), R(t)} + Pi(k)/Gi wobei: Pi(k):
die Länge des Pakets k in der Warteschlange Qi;
Werte
140
4
VoIP und QoS in IP-Netzen
Gi: R(t):
die Gewichtung der Warteschlange Qi; Anteil der Bandbreite, der dieser Warteschlage zur Verfügung stehen sollte; die sog. Rundenzahl zur Zeit t, die aus dem zugrunde liegenden theoretischen Modell errechnet wird.
Die so berechneten FT-Werte stellen die Zeitpunkte dar, zu denen die einzelnen Pakete theoretisch „abgearbeitet“ werden sollen. Sie bestimmen also die Reihenfolge der IP-Pakete auf der Leitung. Dies bringt Abbildung 4.5-10 zum Ausdruck. Hier ist ersichtlich, dass der Scheduler in einem Schritt mehrere IPPakete (wobei ihre Anzahl variabel sein kann) aus einer Warteschlange dem Sender übergeben kann. Bemerkung: Das dem WFQ-Konzept zugrunde liegende Modell ist ein theoretisches Scheduler-System, das sog. Generalized Processor Sharing (GPS)-System.
Adaptive WFQ
Seit der Veröffentlichung im Jahr 1989 wurde WFQ weiterentwickelt und weitere Varianten sind entstanden. Hierzu gehört z.B. Adaptive WFQ (AWFQ). AWFQ bietet die Möglichkeit, die Gewichtungen der Warteschlangen einzelner Paketströme dynamisch nach Bedarf zu ändern. Damit lässt sich die Zuteilung der Bandbreite zu den einzelnen Paketströmen dynamisch den aktuellen Anforderungen anpassen.
www.wiwobooks.com
4.5.5 Class-based Weighted Fair Queueing Class-based Weighted Fair Queueing (CBWFQ) stellt eine Variante von WFQ dar. Bei CBWFQ handelt es sich um das Management von Warteschlangen für IP-Pakete, die durch die Angabe im IP-Header (im ToS- bzw. im DS-Feld) entsprechend differenziert werden. So entstehen Paketklassen (Class-based). Für jede Klasse von Paketen richtet man eine Warteschlange ein, wobei man ihr einen bestimmten Anteil der Bandbreite der Leitung zur Verfügung stellt. Hierbei kann die Länge der Pakete variabel sein. Der Scheduler bei CBWFQ funktioniert nach dem gleichen Prinzip wie bei WFQ, sodass die Finish-TimeWerte für die Pakete berechnet werden. Konzept von CBWFQ
Wie bei WFQ werden auch bei CBWFQ mehrere Warteschlangen gebildet und jeder von ihnen eine Gewichtung zugeordnet. CBWFQ kommt oft zum Einsatz, wenn ein Strom von IP-Paketen, in dem mehrere Klassen von IP-Paketen enthalten sind, über eine Leitung gesendet wird und jeder Klasse ein bestimmter Anteil der Bandbreite der Leitung zur Verfügung stehen soll. Abbildung 4.5-11 illustriert das Prinzip von CBWFQ.
4.5 Queue-Management
K la s s e n v o n P a k e te n a c a b a P rio ritä t e o v e r IP lic h e D a te n a le D a te n
K la s s ifiz ie re r
a m e h re re c b a , b , a : a : V o iv b : d rin g c : n o rm
Q
1
B
a
a Q
2
3
2
b b
B
1
c
c
Q 3
W F Q -S c h e d u le r
B
141
A u sg a n g sle itu n g
Abb. 4.5-11: Prinzip von Class-based Weighted Fair Queueing Bi: Anteil der Bandbreite der Ausgangsleitung, Q: Warteschlange (Queue)
Die zu sendenden IP-Pakete wurden hier bereits durch die Angabe der Wichtigkeit im DS-Feld differenziert. Somit sind im ankommenden Strom von Paketen mehrere Klassen von Paketen enthalten. Eine Klasse hat hierbei eine bestimmte Wichtigkeit. Für jede Klasse von IP-Paketen wird eine Warteschlange eingerichtet. Jeder Warteschlange wird dann eine Gewichtung zugeordnet, die den Teil der Bandbreite B der Leitung darstellt, der für diese Warteschlange verfügbar sein soll. Der Scheduler funktioniert hier nach dem gleichen Prinzip wie bei WFQ (s. Abb. 4.5-10). Dies bedeutet, dass die Variable FT für die einzelnen IP-Pakete in allen Warteschlangen berechnet werden muss. Die FTWerte bestimmen dann die Reihenfolge, in der die einzelnen Pakete aus allen Warteschlangen zum Senden übergeben werden.
www.wiwobooks.com
Es stellt sich hierbei die Frage: Nach welchen Prinzipien lässt sich die Bandbreite der Ausgangsleitung den einzelnen Klassen von IP-Paketen gerecht zuweisen? Die verfügbare Bandbreite sollte im Allgemeinen aus der Wichtigkeit der Klasse von Paketen abgeleitet werden. Falls die Warteschlangen Q1, ..., Qn, die den Paketklassen 1,..., n entsprechen, eingerichtet werden und die Ausgangsleitung die Bandbreite B hat, kann eine gerechte Aufteilung der Bandbreite folgendermaßen erfolgen: Bi = B•Gi, i = 1, ..., n wobei: Gi = Xi /(X1 + ...+ Xn): Gewichtung der Warteschlange Qi Xi = 1 + Prec (i) Prec (i): Precedence-Wert (Wichtigkeit) der Klasse i im ToS-Feld Stehen die Precedence-Werte für die einzelnen Klassen von Paketen fest, so können die Gewichtungen G1, ..., Gn der Warteschlangen Q1, ..., Qn bestimmt werden. Gn gibt an, welcher Anteil der Bandbreite B für Qi verfügbar sein soll. Beispiel: Garantie der Bandbreite für VoIP Über eine Leitung mit einer Bandbreite von 56 kbit/s sollen vier IP-Paketströme übermittelt werden. Es werden hierbei zwei Klassen von IP-Paketen gebildet: Daten und VoIP. Jedem VoIPPaketstrom sollte eine Bandbreite von mindestens 24 kbit/s zugeteilt werden. Die ankommenden IP-Pakete sind nicht differenziert und enthalten die Angabe „Preference = 0“. Der Klassifizierer bei CBWFQ muss in den Paketen mit VoIP einen entsprechenden Preference-Wert setzen. Der
Zuordnung der Bandbreite einer Klasse von IP-Paketen
142
4
VoIP und QoS in IP-Netzen
benötigte Preference-Wert lässt sich auf Basis der dargestellten Formel für Bi bestimmen. Wie Abbildung 4.5-12 zeigt, muss der Preference-Wert 5 in allen Paketen mit VoIP gesetzt werden. K la s s e n : D a te n ,V o I P 2 4 k b it/s = > V o IP -S tro m C B W F Q
P re c = 5 fü r V o IP P re c = 0 fü r D a te n
2 V o IP -S trö m e : P re c = 0 2 D a te n -S trö m e : P re c = 0 B 1= 2 4 B 2 = 2 4 B 3 = 8 B 4 = 8
B = 5 6 k b it/s
k b it/s k b it/s k b it/s k b it/s
= =
=
=
(6 /1 (6 /1 (1 /1 (1 /1
4 ) * 4 ) * 4 ) * 4 ) *
5 6 k 5 6 k 5 6 k 5 6 k
b it/s b it/s b it/s b it/s
Abb. 4.5-12: Beispiel für die Garantie der Bandbreite für VoIP Der Preference-Wert in allen Paketen mit Daten bleibt weiterhin gleich 0. Im CBWFQ-System werden vier Warteschlangen Q1, Q2, Q3, Q4 mit den Gewichtungen 6/14, 6/14, 1/14 und 1/14 eingerichtet. In diesem Fall steht jedem Strom von Paketen mit VoIP die Bandbreite von 24 kbit/s zur Verfügung. Die restliche Bandbreite von 8 kbit/s wird auf zwei Datenströme gleichmäßig aufgeteilt.
4.6
www.wiwobooks.com
Einsatz von RSVP
RSVP (Resource reSerVation Protocol) ist ein Protokoll, nach dem die Ressourcen in IP-Netzen reserviert werden können, um eine von der Anwendung geforderte QoS (Quality of Service) zu garantieren. Eine Reservierung mit RSVP bezieht sich immer nur auf eine unidirektionale virtuelle Ende-zu-EndeVerbindung. Für eine Vollduplex-Verbindung mit QoS-Garantie sind zwei Reservierungen erforderlich, d.h. eine für jede Kommunikationsrichtung. RSVP kann sowohl für die Reservierung bei Punkt-zu-Punkt- als auch bei Punkt-zuMehrpunkt-Verbindungen eingesetzt werden. RSVP wird in mehreren IETFDokumenten spezifiziert. Diese Dokumente sind zugänglich unter der Adresse: http://www.ietf.org/wg/concluded/rsvp.html TokenBucketModell
Die gesamte Zwischenspeicherungszeit auf einer virtuellen Verbindung (s. Abb. 4.1-4) lässt sich durch die Reservierung einer entsprechenden Bandbreite von einzelnen Leitungen unterwegs verringern. Eine solche Reservierung ist mit RSVP möglich. Die gesamte Zwischenspeicherungszeit auf einer unidirektionalen virtuellen Verbindung kann kontrolliert werden, indem die zu dieser Verbindung gehörigen IP-Pakete in den einzelnen Routern unterwegs nach einer von vornherein festgelegten Regel gesendet werden. Diese Regel basiert auf dem sog. Token-Bucket-Modell (kurz TB-Modell) und liegt dem Scheduler bei RSVP zugrunde. Abbildung 4.6-1 illustriert den Einsatz des TB-Modells im Scheduler vor einer Leitung in einem IP-Netzknoten. Nach diesem Modell kon-
4.6 Einsatz von RSVP
143
trolliert der Scheduler bei RSVP die gesamte Zwischenspeicherungszeit auf einer unidirektionalen, virtuellen Verbindung, um z.B. eine geforderte Bandbreite zu garantieren. u n id ire k tio n a le v irtu e lle V e rb in d u n g Q u e lle
Z ie l
IP -P a k e te
W a rte s c h la n g e
T o k e n m it d e r R a te R
IP -P a k e te
B
B : m a x im a le B u c k e t-G rö ß e
x
B u c k e t
R S V P -S c h e d u le r
IP -N e tz
Abb. 4.6-1: Paket-Scheduler nach dem Token-Bucket-Modell
Das TB-Modell beschreiben die Parameter: R: Token-Rate [Bytes/s] und
www.wiwobooks.com
Parameter des TBModells
B: maximale Bucket-Größe [Bytes].
Der Parameter R stellt die vom Netz unterstützte (garantierte) Datenrate einer virtuellen Verbindung dar und kann daher als garantierte Bandbreite für diese Verbindung angesehen werden. Ein Token stellt eine Dateneinheit dar. Bei RSVP wird angenommen: Token = Byte. Das TB-Modell beschreibt das Verhalten beim Senden der IP-Pakete auf einer Funktionsunidirektionalen, virtuellen Verbindung. Der Behälter (Bucket) wird mit der weise des Rate von R Bytes pro Sekunde gefüllt. Die Variable x beschreibt den aktuellen Schedulers Zustand von Bucket in Bytes und besagt, wie viele Bytes man zu jeder Zeit senden darf. Somit darf ein IP-Paket nur dann gesendet werden, wenn Bucket genügend Bytes enthält. Die Funktionsweise des Schedulers beim Senden eines IP-Pakets mit der Länge von a Bytes lässt sich wie folgt beschreiben: Falls a < x ist, wird das IP-Paket gesendet und der Inhalt von Bucket um a reduziert, d.h. x-a x. Falls x < a bzw. x = 0 ist, muss das IP-Paket so lange warten, bis der Zustand x den Wert a erreicht hat. Erst dann wird das IP-Paket gesendet und der Inhalt von Bucket um a reduziert. Nach dem TB-Modell dürften nicht mehr als R•T + B [Bytes] während eines Zeitintervalls T auf der virtuellen Verbindung gesendet werden. Somit gibt der Parameter B an, um wie viel Bytes die mittlere Datenmenge zusätzlich gemäß der garantierten Datenrate R bei einem unregelmäßigen (burstartigen) Datenverkehr überschritten werden darf.
144
4
VoIP und QoS in IP-Netzen
Um bestimmte Netzressourcen wie z.B. Bandbreite von Leitungen reservieren zu können, definiert RSVP mehrere Nachrichten. Jede Nachricht enthält einen Header und eine Anzahl festgelegter Objekte als Parameter. Die einzelnen RSVP-Nachrichten unterscheiden sich voneinander durch die Zusammensetzung von Objekten und durch die Inhalte dieser Objekte. Für Näheres sei auf [BaHo 07], [DuYa 99] verwiesen. Verbindung mit garantierter Bandbreite
Abbildung 4.6-2 illustriert den Aufbau einer unidirektionalen virtuellen Punktzu-Punkt-Verbindung mit einer garantierten Bandbreite. Die Quelle initiiert hier eine Verbindung zum ausgewählten Ziel durch das Absenden der RSVPNachricht Path, in der angegeben wird, welche Bandbreite diese Verbindung haben soll. Die Nachricht Path wird nach den herkömmlichen Routing-Prinzipien über das IP-Netz übermittelt. Jeder Router unterwegs analysiert Path und kann eventuell über einen externen Policy-Server überprüfen, ob diese Reservierung zulässig ist.
R
Q u e lle
P a th R e sv
R
P a th 1
IP -N e tz R
R
R e sv
P a th 2
R
R e sv
3
P a th
www.wiwobooks.com
V e rfü g b a re B a n d b re ite n V e rla u f d e r R e se rv ie ru n g
R = B
R = B
B
0
B
0
< B
1 1
B
1
B
1
< B
R = B
2
2
B
2
B
2
< B
x
x
B
3
Z ie l R e sv R = B B 3
> B
x x
B x= m in { B 3, B x} B 1= m in { B 1, B 2}
B 2= m in { B 2, B x}
B 1= m in { B 0, B 1}
B x:v o n d e r Q u e lle g e w ü n s c h te B a n d b re ite ; B 1:v o m
IP -N e tz g a ra n tie rte E n d e -z u -E n d e -B a n d b re ite
Abb. 4.6-2: Aufbau einer Punkt-zu-Punkt-Verbindung mit garantierter Bandbreite
Ermittlung optimaler Router mit Path
Vor dem Absenden der Nachricht Path trägt jeder Absender (Quelle, Router) seine IP-Adresse als Objekt RSVP Hop in der Nachricht Path ein. Hat Path das Ziel erreicht, enthält sie die zu diesem Zeitpunkt optimale Route von der Quelle zum Ziel. Diese Path-Route, als Folge von IP-Adressen von ihren Absendern (in Abb. 4.6-2: Quelle, R1, R2 und R3), wird den Verlauf der virtuellen Verbindung bestimmen. Sie wird beim Ziel in die RSVP-Nachricht Resv (Reservierung) kopiert, die das Ziel als Antwort auf Path zur Quelle zurücksendet.
Reservierung der Bandbreite mit Resv
Die eigentliche Reservierung der gewünschten Bandbreite Bx beginnt man mit dem Versenden der Nachricht Resv vom Ziel an die Quelle. Da Resv die Path-Route in sich enthält, wird sie auf der gleichen Route wie Path, doch in umgekehrter Richtung, übermittelt. Der Router Ri auf der Resv-Route (in Abb. 4.6-2: R3, R2, R1 und Quelle) überprüft, ob er die in Resv gewünschte Bandbrei-
4.7 Schlussbemerkungen
145
te auf der Leitung, über die Resv empfangen wurde, garantieren kann. Die Bandbreite wird als Parameter R (Token Rate, s. Abb. 4.6-1) angegeben. Beim Router Ri kommen zwei Möglichkeiten in Frage: 1. Die verfügbare Bandbreite Bi ist größer als R in Resv In diesem Fall reserviert Ri die Bandbreite R und leitet danach den Parameter R ohne Veränderungen weiter. 2. Die verfügbare Bandbreite Bi ist kleiner als R in Resv In diesem Fall wird nur die Bandbreite Bi vom Router Ri garantiert. Ri ersetzt den Wert des Parameters R in der empfangenen Nachricht Resv durch den Wert Bi und leitet Resv mit R = Bi weiter. Hat die Quelle die Nachricht Resv empfangen, verfügt sie über die Ende-zu- Ende-zuEnde-Bandbreite, die auf der unidirektionalen, nach der Path-Route verlaufen- Endeden virtuellen Verbindung von allen Routern unterwegs garantiert wird. Diese Bandbreite Bandbreite stellt den kleinsten Wert aus den verfügbaren Bandbreiten in einzelnen Leitungen auf der Path-Route und aus der gewünschten Bandbreite Bx dar. In Abb. 4.6-2 wird die Ende-zu-Ende-Bandbreite durch den kleinsten Wert aus B0, B1, B2, B3 und Bx bestimmt. Da sich die optimale Route ändern kann, wird der in Abb. 4.6-2 dargestellte Optimierung Vorgang (d.h. das Absenden von Path- und Resv-Nachrichten) in bestimmten der Route Zeitabständen periodisch wiederholt. Dies dient dem Zweck, den Verlauf der Route zu optimieren und die Reservierung der Bandbreite aufzufrischen.
www.wiwobooks.com
Für Näheres über RSVP seien die Webquellen [Web 01] empfohlen.
4.7
Schlussbemerkungen
Das Thema „Quality of Service in IP-Netzen“ ist sehr breit und komplex. In diesem Kapitel wurden nur solche Aspekte angesprochen, die sich auf die Qualität von VoIP auswirken. Für weitere und tiefgreifende Informationen über Quality of Service sei auf [Armi 00], [Black 00] und [JhHa 02] verwiesen.
QoS in IPNetzen – ein breites Thema
Abschließend ist Folgendes hervorzuheben: Die QoS-Unterstützung in IP-Netzen hat an Bedeutung enorm gewonnen, QoS und seit man versucht, die IP-Netze für Audio- und Videokommunikation zu Videokomverwenden, also für die Kommunikation, die in Echtzeit verläuft. VoIP stellt munikation eine derartige Kommunikation dar. Die in diesem Kapitel dargestellten Methoden für die QoS-Unterstützung können auch bei der Videokommunikation über IP-Netze angewandt werden. Eine Störquelle bei der Sprachkommunikation in klassischen Telefonnetzen Echoeffekte sind Echoeffekte. Ein Echo ist der Klang der Stimme eines Sprechers, die bei der über seinen Telefonhörer an sein Ohr zurückkommt. Oft werden Echos durch Sprachkommunikation
146
4
VoIP und QoS in IP-Netzen
eine falsche Impedanzanpassung zwischen analogen Telefonapparaten und dem Übertragungsmedium auf dem Teilnehmeranschluss verursacht. Eine falsche Anpassung kommt besonders bei der Umsetzung von einer Vierdrahtleitung auf eine Zweidrahtleitung vor. Bei der Integration eines VoIPSystems mit dem Telefonnetz wird ein VoIP-Gateway eingesetzt. Die herkömmliche Telefontechnik (Verkabelung, Vermittlungen etc.) jenseits eines VoIP-Gateway stellt eine Art des Teilnehmeranschlusses dar. Somit können Echos im VoIP-System bei der Kopplung mit klassischen Telefonanlagen ein Telefongespräch stören. Die Störungen können schon bemerkbar sein, wenn die Verzögerung des Sprachsignals mehr als 30 ms beträgt. Weitere Verfahren für QueueManagement
Die übertragenen IP-Pakete müssen in der Regel in Netzknoten vor Leitungen auf das Absenden warten. Da die Ströme der IP-Pakete durch die Zuordnung verschiedener Prioritäten differenziert werden, muss man hierfür mehrere Warteschlangen organisieren und entsprechend verwalten. Hierbei entsteht ein zusätzliches Problem, weil bestimmte Bandbreiten auf den Leitungen für die Übertragung der IP-Pakete mit Sprache garantiert werden müssen. Für die Lösung dieses Problems wurden verschiedene Verfahren für Queue-Management entwickelt. Dieses Kapitel erläutert nur kurz die wichtigsten von ihnen. Außerdem ist das Verfahren LLQ (Low Latency Queueing) zu erwähnen. LLQ kommt oft in Netzwerkkomponenten der Firma Cisco vor und stellt eine Kombination von PQ und WFQ dar.
www.wiwobooks.com
Hervorzuheben sind hierbei auch neue Varianten von WFQ, wie z.B.: − Self-Clocking WFQ (SCWFQ), bei dem die Berechnung der Variable Finish Time im Vergleich zu WFQ vereinfacht wurde. − Worst-Case Fair WFQ (WF2Q), bei dem nur die Worst-Case-Werte für die Berechnung von Finish Time angenommen werden.
− Worst-Case Fair WFQ+ (WF2Q+), bei dem die Berechnung von Finish Time im Vergleich zu WF2Q vereinfacht wurde.
Bedeutung von COPS
Um die QoS-Anforderungen in einem IP-Netz zu erfüllen, müssen bestimmte Ressourcen in diesem IP-Netz reserviert werden. Zu diesem Zweck kann man das Protokoll RSVP (s. Abschnitt 4.6) verwenden. Es muss auch möglich sein zu überprüfen, ob das Initiieren einer VoIP-Session mit der Reservierung von Ressourcen überhaupt gestattet ist. Dabei muss eine zentrale Stelle im Netz durch die Netzwerkkomponente, die eine Reservierung durchführen soll, abgefragt werden. Eine solche Abfrage muss nach einem festgelegten Protokoll erfolgen; hier kann das Protokoll COPS (Common Open Policy Service) zum Einsatz kommen – siehe RFC 2748.
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Unter Echtzeitkommunikation versteht man die Übermittlung von Echtzeit- Echtzeitmedien wie Audio/Sprache und Video. Bei dieser Art der Kommunikation ist kommunikadie Fehlerkontrolle mit Hilfe von Quittungen, so wie sie bei der Datenkom- tion mit RTP munikation realisiert wird, nicht möglich. Weil sich die für die Datenkommunikation konzipierten Protokolle für die Übermittlung von Audio und Video über IP-Netze nicht einsetzen lassen, wurde hierfür ein spezielles Protokoll entwickelt – und zwar RTP (Real-time Transport Protocol). Für die Überwachung der Echtzeitkommunikation mit Hilfe von RTP ist ein Kontrollprotokoll nötig – das RTCP (RTP Control Protocol). Dieses Protokoll macht die parallele Übertragung von Kontroll- und Statusinformationen zwischen den Teilnehmern einer VoIP-Session möglich. Der Empfänger von Echtzeitmedien sendet beispielsweise periodisch RTCP-Pakete zum Sender, die als Berichte angesehen werden können, in denen die Information über den aktuellen Zustand des Empfängers selbst und über die aktuelle Qualität der Übertragung an den Sender geliefert wird.
Überwachung der Kommunikation mit RTCP
www.wiwobooks.com
Die Sprache als analoges Signal muss für die Übermittlung über IP-Netze zu- Überblick nächst in eine digitale Form umgewandelt – also codiert – werden. Dafür ste- über das hen mehrere Verfahren zur Verfügung, die in Abschnitt 5.1 kurz erläutert wer- Kapitel den. Abschnitt 5.2 geht kurz auf die Protokolle für Sprachübermittlung über IP-Netze ein. Die Funktionen von RTP beschreibt Abschnitt 5.3. Dem Einsatz von Translator und Mixer widmet sich Abschnitt 5.4. Das Konzept von RTCP wird in Abschnitt 5.5 präsentiert. Abschnitt 5.6 zeigt, wie RTCP zur Abschätzung relevanter QoS-Parameter verwendet werden kann. Das Konzept und die Nutzung von Secure RTP beschreibt Abschnitt 5.7. Auf die Kompression des RTP/UDP/IP-Headers geht Abschnitt 5.8 ein. In diesem Kapitel wird versucht, u.a. folgende Fragen zu beantworten: Welche Verfahren der Sprachcodierung für VoIP gibt es? Welche Probleme entstehen bei der Sprachübermittlung über IP- Netze? Wie wird die Sprache mit RTP-Hilfe übermittelt? Wie lässt sich die Sprachübermittlung über IP-Netze überwachen? Wie können die QoS-Parameter bei VoIP abgeschätzt werden? Wie funktioniert und was ermöglicht Secure RTP? Wie komprimiert man den langen RTP/UDP/IP-Header?
Ziel dieses Kapitels
148
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.1 Digitale Sprachübermittlung
Sprachcodierung bei VoIP
Der Mensch erzeugt Sprache in Form einer akustischen Welle. Beim Telefonieren wird diese akustische Welle vom Mikrophon des Telefons aufgenommen und in ein elektrisches Sprachsignal umgewandelt. Zunächst liegt die Sprache also immer als analoges Signal zum Senden vor. Damit sich die Sprache aber in digitaler Form übermitteln lässt, muss sie auf der Sendeseite in einen entsprechenden Bitstrom umgewandelt werden. Dieser Vorgang wird als Digitalisierung der Sprache bezeichnet und die Übermittlung der Sprache in digitaler Form als digitale Sprachübermittlung. Auf der Empfangsseite wiederum muss die empfangene Sprache aus der digitalen Form in ihre Ursprungsform, d.h. in das analoge Signal zurückgewandelt werden. Abbildung 5.1-1 illustriert das Prinzip der digitalen Sprachübermittlung. S e n d e s e ite
s (i)
s (t)
S p ra c h b its tro m
i 0 1 0 1 0 0 0 0 1 1 0 1 0 t
M P
T ie fp a s s
A b ta s te r
C o d ie re r
www.wiwobooks.com L S
T ie fp a s s
H a lte g lie d
s * (t)
s * (i) t
D e c o d ie re r
IP -P a k e t
S e n d e r
IP -N e tz
E m p fä n g e r
0 1 0 1 0 0 0 0 1 1 0 1 0 i
IP -P a k e t
S p ra c h b its tro m
E m p fa n g s s e ite
Abb. 5.1-1: Grundlegendes Prinzip der Sprachübermittlung über ein IP-Netz MP: Mikrophon, LS: Lautsprecher
Umwandlung der Sprache zu einem Bitstrom
Die Digitalisierung der Sprache erfolgt in mehreren Schritten. Das im Mikrophon erzeugte analoge Sprachsignal wird zuerst in einem Tiefpassfilter geglättet. Damit werden aus dem analogen Sprachsignal die Geräusche beseitigt, die die hohen Frequenzen beinhalten. Das geglättete analoge Sprachsignal – als kontinuierliche Funktion s(t) der Zeit t – wird nun in hinreichend kleinen Abständen regelmäßig in einem Abtaster abgetastet. Dadurch entsteht eine Folge der Abtastwerte s(i), i =0, 1, 2, ..., die im nächsten Schritt im Codierer zu einer Bitfolge umgewandelt wird. Im Codierer werden somit die Abtastwerte gemessen, quantisiert (d.h. entsprechend gerundet) und durch binäre Codeworte dargestellt. So entsteht aus einem analogen Sprachsignal eine Folge binärer Codewörter, also de facto ein Sprachbitstrom. Aus diesem Sprachbitstrom werden nun im Sender die IP-Pakete gebildet und über ein IP-Netz dem Empfänger übermittelt.
5.1 Sprachcodierung bei VoIP
149
Im Empfänger muss nun das ursprüngliche analoge Sprachsignal aus den empfangenen IP-Paketen zurückgewonnen werden. Aus jedem IP-Paket wird das enthaltene Segment des Sprachbitstroms „herausgenommen“ und an den Decodierer übergeben. Im Decodierer wird jedes im Sprachbitstrom enthaltene Codewort in einen analogen Spannungswert umgewandelt. Die so erzeugten Spannungswerte s*(i), i =0, 1, 2, ... stellen eine Nachbildung der Abtastwerte s(i) aus der Sendeseite dar. Jeder Spannungswert s*(i) wird im sog. Halteglied bis zum nächsten Spannungswert gehalten. Dadurch erzeugt das Halteglied eine „Treppenkurve“, die bereits die erste Nachbildung des analogen Sprachsignals darstellt. Diese Treppenkurve wird anschließend mit Hilfe eines Tiefpassfilters geglättet, sodass die scharfen Kanten in dieser Treppenkurve „abgeschnitten“ werden. Aus der Treppenkurve erzeugt das Tiefpassfilter eine Nachbildung s*(t) des ursprünglichen analogen Sprachsignals s(t).
Zurückgewinnung der Sprache aus den IPPaketen
Wie bereits in Abbildung 5.1-1 dargestellt, wird die Amplitude des analogen Sprachsignals im Sender in gleichen Zeitabständen (periodisch) abgetastet. Hierbei stellt sich die Frage, mit welcher Häufigkeit dies geschehen soll, damit das ursprüngliche analoge Sprachsignal später ohne Informationsverluste aus den Abtastwerten zurückgewonnen werden kann. Die Antwort darauf gibt das sog. Abtasttheorem nach Shannon. Demnach muss die Abtasthäufigkeit FA größer sein als das Doppelte der im analogen Signal enthaltenen höchsten Frequenz. Es wird angenommen, dass das Spektrum der analogen Sprachsignale im Frequenzbereich zwischen 300 und 3400 Hz liegt. FA muss somit größer als 6800 sein. Für das Sprachsignal wurde eine Abtasthäufigkeit von 8000-mal pro Sekunde international festgelegt.
Abtastung des analogen Sprachsignals
www.wiwobooks.com
Bemerkung: Die Sprache stellt eine Form von Audio dar. Unter dem Begriff Audio versteht man jede Medienart (Sprache, Musik, Geräusche, ...), die der Mensch über das Ohr wahrnehmen kann. Im Allgemeinen ist das Spektrum eines analogen Audiosignals breiter als das Spektrum des Sprachsignals. Beispielsweise sind in der Musik höhere Töne enthalten als in der Sprache. Ein Audiosignal muss somit bei der Digitalisierung oft mit viel größerer Häufigkeit als 8000-mal pro Sekunde abgetastet werden.
Sprache als eine Form von Audio
Für die Codierung der Sprache bei VoIP gibt es unterschiedliche Verfahren. Im Arten der SprachAllgemeinen ist eine Sprachcodierung entweder Abtastwert-orientiert (sample-based) oder
codierung
Segment-orientiert (frame-based). Wird ein analoges Sprachsignal zuerst – in der Regel 8000-mal je Sekunde – abgetastet und werden dann die einzelnen Abtastwerte (samples) codiert, handelt es sich um eine Abtastwert-orientierte Sprachcodierung, die man auch als Signalform-Codierung oder Signalform-Approximation bezeichnet. Sprachcodierungsverfahren wie PCM (Pulse Code Modulation) bzw. ADPCM (Adaptive Difference PCM) sind Abtastwert-orientiert (s. Abb. 5.1-2). Sie erzeugen Bitströme mit einer Bitrate, die in der Regel größer als 16 kbit/s ist.
Abtastwertorientierte Sprachcodierung
150 Segmentorientierte Sprachcodierung
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Eine andere Art der Sprachcodierung basiert darauf, dass ein Sprachsignal aufgezeichnet und in Zeitsegmente von der Länge 10 ... 30 ms aufgeteilt wird. Man spricht hierbei von Sprachsegmenten. Ein Sprachsegment von 10 ms entspricht beispielsweise 80 Abtastwerten, ein Sprachsegment von 20 ms 160 Abtastwerten usw. Jedes Sprachsegment wird im Sender analysiert, um die Parameter einer Schaltung im Empfänger zur Sprachsynthese auf optimale Weise zu bestimmen. Diese Parameter werden codiert und an den Empfänger übermittelt. Der Empfänger wird somit in die Lage versetzt, ein Sprachsegment synthetisch zu erzeugen (s. Abb. 5.1-7). Man bezeichnet eine derartige Codierungsart als Segment-orientiert. Diesem Ansatz liegt eine Nachbildung der Erzeugung der menschlichen Sprache mit Hilfe eines linearen Filters – als LPC-Filterung (Linear Predictive Coding) bezeichnet – zugrunde (s. Abb. 5.1-5). Die Sprachcodierungsverfahren, die beispielsweise das Konzept LPC (Linear Predictive Coding) bzw. CELP (Code-Excited Linear Prediction) nutzen, sind Segment-orientiert. Sie erzeugen Bitströme mit einer Bitrate, die kleiner als 16 kbit/s ist.
www.wiwobooks.com
5.1.1 Abtastwert-orientierte Sprachcodierung Bedeutung der Quantisierung
Um eine Abtastwert-orientierte Sprachcodierung zu verwenden, wird zuerst das analoge Sprachsignal 8000-mal pro Sekunde abgetastet. Daraus entsteht eine Folge der Abtastwerte s(i), i= 0, 1, 2, ..., die in der Amplitude kontinuierlich sind. Bei der Abtastwert-orientierten Sprachcodierung werden die einzelnen Abtastwerte entsprechend codiert. Hierfür müssen die in der Amplitude kontinuierlichen Abtastwerte zu diskreten Werten gerundet, also quantisiert werden. Wie aus Abbildung 5.1-2 ersichtlich ist, liegt diese Quantisierung der Abtastwert-orientierten Sprachcodierung zugrunde. Bei der Quantisierung entstehen die Quantisierungsfehler, die man auch als Quantisierungsgeräusche bezeichnet (s. Abb. 5.1-3).
PCMCodierer
Die einfachste Form der Abtastwert-orientierten Sprachcodierung stellt das PCM-Verfahren (Pulse Code Modulation) dar. Es ist das populärste und am häufigsten eingesetzte Sprachcodierungsverfahren und wird z.B. in den ISDNTelefonapparaten verwendet. Bei PCM wird zuerst jeder Abtastwert s(i), der in der Amplitude kontinuierlich ist, an der Sendeseite im Codierer quantisiert und somit in einen diskreten Abtastwert umgewandelt. Danach wird jeder diskrete Abtastwert mit einem Codewort von 8 Bits codiert. Da 8000 Abtastwerte pro Sekunde jeweils mit 8 Bits repräsentiert werden, entsteht auf diese Art und Weise ein Bitstrom von 8000 [1/s] • 8[bit] = 64 kbit/s. Wie Abbildung 5.1-2a zeigt, besteht ein PCM-Codierer eigentlich aus einem Quantisierer.
151
5.1 Sprachcodierung bei VoIP
S e n d e s e ite a ) b ) s (i)
Ü b e r m ittlu n g
C o d ie r e r s (i)
D e c o d ie r e r B its tro m 6 4 k b it/s
Q
C o d ie r e r +
d (i)
- s e(i)
B its tro m 4 0 /3 2 /2 4 /1 6 k b it/s Q
P
Q s r( i )
E m p fa n g s s e ite Q
-1
D e c o d ie r e r Q -1 d * ( i )
-1
+
d * (i)
Q : Q u a n tis ie re r Q -1 : in v e rs e r Q u a n tis ie re r P : P rä d ik tio n s filte r
s * (i)
+
s r* ( i )
+
s * (i)
s e* (i) P
Abb. 5.1-2: Sprachübermittlung bei der Abtastwert-orientierten Sprachcodierung: a) Prinzip von PCM (Pulse Code Modulation); b) Prinzip von DPCM (Differential PCM)
Auf Empfangsseite muss eine zur Quantisierung umgekehrte Operation durch- PCMgeführt werden. Aus dem empfangenen Bitstrom müssen die einzelnen 8-Bit- Decodierer Codewörter in die diskreten Werte umgesetzt werden, die eine Nachbildung s*(i) der Abtastwerte s(i) darstellen. Die hierfür notwendige Schaltung bezeichnet man oft als inversen Quantisierer. Ein PCM-Decodierer besteht eigentlich aus einem inversen Quantisierer.
www.wiwobooks.com
Das PCM-Verfahren wird im ITU-T-Standard G.711 spezifiziert. Um die PCM Quantisierungsfehler zu reduzieren, wird bei PCM eine sog. nichtlineare Quan- in G.711 tisierung verwendet. In Abschnitt 5.1.3 wird darauf noch detaillierter eingegangen. Die Sprachsignale weisen stochastische (statistische) Abhängigkeiten auf. Da- DPCMdurch kann man anhand einer grundsätzlichen Analyse des Sprachsignals seine Prinzip zukünftigen Amplitudenwerte mit bestimmter Wahrscheinlichkeit voraussagen (prädiktieren). Eine Folge der Abtastwerte eines analogen Sprachsignals zeichnet sich insbesondere dadurch aus, dass die benachbarten Abtastwerte relativ stark voneinander stochastisch abhängig sind. Somit kann der Abtastwert s(i) aus den Vorgängerwerten s(i-1), s(i-2), ... vorausgesagt (approximiert) werden. Diese Idee liegt dem DPCM-Prinzip (Differential PCM) zugrunde (s. Abb. 5.12b). Ein Schätzwert se(i) (e: estimation) des Abtastwertes s(i) lässt sich als lineare Einsatz eines linearen Prädiktion aufgrund seiner Vorgängerwerte wie folgt darstellen: se(i) = a1 sr(i-1) + a2 sr(i-2) + ...+ aN sr(i-N) Hierbei kann sr(k) als rekonstruierter Wert von s(k) angesehen werden. Die Schaltung zur Berechnung von se(i) stellt einen linearen Prädiktionsfilter dar, den man mit den Parametern a1, a2, ..., aN beschreibt. Diese Parameter können
Prädiktionsfilters
152
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
mit Hilfe eines iterativen Verfahrens errechnet werden. In der Regel ist N nicht größer als 10. DPCMVorteil gegenüber PCM
Anders als bei PCM wird bei DPCM eine Reduktion der Bitrate dadurch erreicht, dass nicht der Abtastwert s(i) codiert und übertragen wird, sondern die Differenz d(i) = s(i) - se(i) zwischen dem Abtastwert s(i) und seiner Prädiktion se(i). Da der Wertebereich dieser Differenzen erheblich kleiner als der Wert des Sprachsignals ist, genügt es, bei DPCM ein kürzeres Codewort zu übertragen als bei PCM, um die gleiche Qualität der Codierung zu erreichen. Dadurch reduziert sich die Bitrate bei DPCM gegenüber PCM.
DPCMDecodierer
Der DPCM-Decodierer an der Empfangsseite enthält den gleichen Prädiktionsfilter wie der Codierer an der Sendeseite. Seine Parameter werden aus dem rekonstruierten Signal sr*(i) = d*(i) + s*(i) abgeleitet. Um den Abtastwert s(i) des Sprachsignals beim Empfänger zu rekonstruieren, wird seine Prädiktion se*(i) im Decodierer berechnet und zur empfangenen Differenz d*(i) addiert, d.h. s*(i) = d*(i) + se*(i). Falls die übertragenen Differenzen fehlerfrei quantisiert und übertragen werden, d.h. d*(i) = d(i), und die Prädiktionswerte an der Empfangs- und an der Sendeseite identisch sind, d.h. se*(i) = se(i), dann stimmt der zurückgewonnene Abtastwert s*(i) = d*(i) + se*(i) mit s(i)= d(i) + se(i) vollkommen überein. Dies ist jedoch der ideale Fall. In realen Situationen stellt se*(i) nur eine Approximation von s(i) dar.
www.wiwobooks.com
ADPCM als Sonderform von DPCM
Wenn die Parameter des Prädiktionsfilters im Codierer und Decodierer konstant sind, handelt es sich um ein reines DPCM-Verfahren. Die stochastischen Eigenschaften eines Sprachsignals sind leider nicht über eine lange Zeitperiode konstant, sondern ändern sich im Laufe der Zeit. Somit müssen die Parameter des Prädiktionsfilters ständig an die „aktuellen“ Eigenschaften eines Sprachsignals angepasst werden. Dies führt zu einer Form von DPCM, die man als Adaptive DPCM bzw. kurz als ADPCM bezeichnet. Die ADPCM-Codierer zerlegen das Sprachsignal in kleinere Zeitabschnitte, die sog. Segmente, von 10 bis 20 ms. Innerhalb der einzelnen Segmente werden die Eigenschaften des Sprachsignals als konstant angenommen. Die einmal zu Beginn des Segments berechneten Prädiktionskoeffizienten bleiben innerhalb des Segments unverändert.
ADPCM in G.726/G.727
Das ADPCM-Verfahren wird in den ITU-T-Standards G.726 und G.727 spezifiziert. Für die Codierung von Differenzen d(i) kann ein Codewort mit einer Länge von 5, 4, 3 bzw. 2 Bits verwendet werden. Beim Codewort mit einer Länge von 5 Bits entsteht ein Bitstrom mit 8000 [1/s] • 5[bit] = 40 kbit/s. Dementsprechend ergeben sich bei Codewörtern mit einer Länge von 4, 3 oder 2 Bits die Bitströme von 32, 24 oder 16 kbit/s.
5.1 Sprachcodierung bei VoIP
153
5.1.2 Prinzipien der Quantisierung Bei der Abtastwert-orientierten Sprachcodierung werden die in der Amplitude Arten der kontinuierlichen Werte zu diskreten Werten quantisiert (gerundet). Im Allge- Quantisierung meinen unterscheidet man zwei Methoden: Quantisierung mit regelmäßigen Quantisierungsstufen, auch unter dem Begriff lineare Quantisierung bekannt. Quantisierung mit unregelmäßigen Quantisierungsstufen bzw. nichtlineare Quantisierung. Diese Art der Quantisierung verwendet man beispielsweise bei PCM und DPCM. Abbildung 5.1-3 zeigt die Digitalisierung eines analogen Signals bei der Quantisierung mit regelmäßigen Quantisierungsstufen. Hierbei wird der Bereich der zulässigen Amplitudenwerte, d.h. der Bereich <-4, 4>, durch die regelmäßig verteilten Quantisierungsstufen -4, -3, ..., 3, 4 gleichmäßig aufgeteilt. x (t), x * (t) 4
A b ta s tz e itp u n k te
3
1 1 0
2
1 0 1
1
www.wiwobooks.com
1 1 1
1 0 0
0
0 0 0
-1
0 0 1
-2
0 1 0
-3
0 1 1
-4
x (t)
x * (t)
Z e it A b ta s tw e rt
1 0 0 1 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 0 1 1 0 E n ts c h e id u n g : 0 2 3 3 2 -1 -3 -3 -3 -1 0 2 Abb. 5.1-3: Digitalisierung eines analogen Signals bei linearer Quantisierung
Den Abstand zwischen zwei benachbarten Quantisierungsstufen bezeichnet man als Quantisierungsintervall. Die Quantisierungsstufen stellen die zulässigen diskreten Werte dar. Jedem diskreten Wert wird ein Codewort von 3 Bits zugeordnet. Das erste Bit verweist darauf, ob die Amplitude positiv oder negativ ist. Man nennt dieses Bit üblicherweise Vorzeichen. Die negativen Werte haben somit das Vorzeichen 0 und die positiven 1. Durch das Vorzeichen wird der Amplitudenbereich auf einen Bereich mit positiven und einen zweiten mit negativen Werten aufgeteilt. Mit den beiden Bits werden die einzelnen Werte in jedem dieser Bereiche codiert.
Quantisierung mit regelmäßigen Quantisierungsstufen
154
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Rundungsfehler als Quantisierungsfehler
Die Quantisierung eines in der Amplitude kontinuierlichen Signals kann man sich so vorstellen, als ob dieses Signal mit einer Treppenkurve approximiert wäre. Die Unterschiede zwischen den in der Amplitude kontinuierlichen Abtastwerten und den diskreten Werten nach der Quantisierung stellen die Rundungsfehler dar und werden als Quantisierungsfehler interpretiert. Diese Fehler bestimmen die Qualität der digitalisierten Sprache und sind bei der Wiedergabe eines zurückgewonnenen analogen Sprachsignals als Quantisierungsgeräusch hörbar. Das Hauptproblem bei der Digitalisierung der Sprache besteht in der Minimierung des Quantisierungsgeräusches. Deswegen verwendet man beim PCM-Verfahren eine sehr komplexe Quantisierung mit einer unregelmäßigen Verteilung von Quantisierungsstufen (s. Abb. 5.1-4).
Warum nichtlineare Quantisierung?
Ein natürlicher Weg, das Quantisierungsgeräusch zu reduzieren, besteht darin, dass man die Anzahl von Quantisierungsstufen vergrößert. Um eine größere Anzahl von Quantisierungsstufen zu codieren, braucht man wiederum mehr Bits im Codewort, sodass ein Bitstrom mit einer größeren Bitrate entsteht. Eine bessere Alternative, das Quantisierungsgeräusch zu reduzieren, besteht darin, dass man die Quantisierungsstufen unregelmäßig verteilt. Dies bedeutet eine nichtlineare Quantisierung; sie liegt dem PCM-Verfahren zugrunde.
Wann lineare Quantisierung?
Eine lineare Quantisierung einzusetzen, ist nur dann sinnvoll, wenn alle Amplitudenwerte eines Signals im ganzen Bereich möglichst mit der gleichen Wahrscheinlichkeit vorkommen, d.h. die Wahrscheinlichkeitsverteilung der Amplitude konstant ist.
Nichtlineare Quantisierung bei PCM
Das Quantisierungsgeräusch ist de facto ein Störsignal der digitalisierten Sprache. Die Qualität der digitalisierten Sprache bestimmt nicht allein die Größe des Quantisierungsgeräusches, sondern das Verhältnis der Leistung des Nutzsignals zur Leistung des Störsignals, also die Stärke des Nutzsignals im Vergleich zum Quantisierungsgeräusch. Man bezeichnet dieses Verhältnis als Signal/Geräusch-Abstand. Die Vergrößerung dieses Abstandes führt zur Qualitätsverbesserung der digitalisierten Sprache. Der Signal/Geräusch-Abstand kann dadurch vergrößert werden, dass man bei den kleinen Amplitudenwerten auch kleine Quantisierungsstufen einsetzt. Diese nichtlineare Quantisierung wird beim PCM-Verfahren verwendet.
www.wiwobooks.com
5.1.3 Nichtlineare Quantisierung bei PCM Besonderheit der Sprachsignale
Bei Sprachsignalen kommen nicht alle Amplitudenwerte mit der gleichen Häufigkeit vor, sondern kleine Amplituden häufiger als große. Die Verteilung der Amplitude von Sprachsignalen ist somit nicht regelmäßig. Beim Einsatz einer linearen Quantisierung ist deshalb mit großen Quantisierungsgeräuschen zu rechnen. Zusätzlich tritt hierbei ein Phänomen auf, demgemäß die Empfind-
5.1 Sprachcodierung bei VoIP
155
lichkeit des menschlichen Gehörs proportional zum Logarithmus der Lautstärke ist. Um die Quantisierungsgeräusche zu minimieren, ist es aus den eben genannten KompandieGründen sinnvoll, bei den Sprachsignalen eine nichtlineare Quantisierung ein- rung zusetzen und die Quantisierungsintervalle einer logarithmischen Aufteilung anzugleichen. Hierfür verwendet man die sog. Kompandierung der Sprachsignale. Dadurch werden die kleinen Amplitudenwerte vergrößert (verstärkt) und die großen verkleinert (gedämpft). Eine Kompandierung kann somit als nichtlineare Verstärkung eines Signals angesehen werden. Eine derartige nichtlineare Verstärkung wird mit einem Kompander (d.h. Kompressor und Expander) durchgeführt. Die Funktionsweise eines Kompanders beschreibt die sog. Kompandierungskennlinie. Nach dem ITU-T-Standard G.711 wird für PCM die in Abbildung 5.1-4 dargestellte Kompandierungskennlinie verwendet. 1
S e g m e n t: + 7
1 /2
V o rz e ic h e n S e g m e n tn u m m e r W e rtc o d ie ru n g a 0 a 1 a 2 a 3 x C o d e w o rt
y
1 /4
+ 6
1 1 1 1 x x x x 1 1 1 0 x x x x
+ 5
1 1 0 1 x x x x
+ 4
1 1 0 0 x x x x
+ 3
1 0 1 1 x x x x
+ 2
1 0 1 0 x x x x
+ 1 b
1 0 0 1 x x x x
+ 1 a
1 0 0 0 x x x x
www.wiwobooks.com x
x
x
1 /8
1 /1 6 1 /3 2 1 /6 4
1
-1 2
0 0 0 0 x x x x
-1 a
0 0 0 1 x x x x
-1 b
0 0 1 0 x x x x
-2
0 0 1 1 x x x x
-3
0 1 0 0 x x x x
-4
0 1 0 1 x x x x
-5
0 1 1 0 x x x x 0 1 1 1 x x x x
-6
C o d e w o rt:
C o d e w o rt:
-7 S e g m e n t:
4
1
1 8 1 8 4
1 2
1
x 1
-1 /6 4 -1 /3 2 -1 /1 6 -1 /8 -1 /4 -1 /2 -1
Abb. 5.1-4: A-Kennlinie für nichtlineare (unregelmäßige) Quantisierung nach G.711
Das Eingangssignal des Kompanders ist das analoge Sprachsignal s(t), y(t) sei das Ausgangssignal des Kompanders. Um die Kompandierungskennlinie zu beschreiben, werden die normierten Werte x = s(t)/Smax und y = y(t)/Ymax einge-
156
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
führt. Hierbei bezeichnet Smax und Ymax die maximale Amplitude entsprechend s(t) und y(t). Die in Abbildung 5.1-4 gezeigte Kompandierungskennlinie wird wie folgt beschrieben:
y =
1 + ln A x , fa lls 1 /A 1 + ln A A x , fa lls -1 /A 1 + ln A 1 + ln A x , fa lls -1 1 + ln A
A-Kennlinie (A-Law)
x
x
x
1 1 /A -1 /A
Diese Kompandierungskennlinie enthält einen konstanten Parameter A = 87.56. Aus diesem Grund spricht man auch von A-Kompandierungskennlinie (auch kurz A-Kennlinie) bzw. von A-Law. Die Kennlinie wird auf mehrere Segmente aufgeteilt (s. Abb. 5.1-4). In jedem Segment wird sie als lineares Teilstück dargestellt. In den ersten Segmenten im positiven und im negativen x-Bereich, d.h. in 1a und 1b sowie in -1a und -1b, ist die Kennlinie eine Gerade mit der gleichen Steigung. Deswegen werden manchmal die Segmente 1a und 1b sowie -1a und -1b jeweils als ein Segment gezählt. Man spricht daher oft von einer 13-Segment-Kennlinie.
www.wiwobooks.com
Quantisierung und Codierung
Jedem Abtastwert eines Sprachsignals wird ein Codewort mit 8 Bits a0, a1, ..., a7 durch den PCM-Codierer zugeordnet (s. Abb. 5.1-4). Das erste Bit a0 gibt das Vorzeichen der abgetasteten Amplitude an und die nächsten drei Bits a1, a2, a3 definieren die Nummer des Segments der Kompandierungskennlinie entsprechend im positiven und negativen Amplitudenbereich. Mit den letzten vier Bits a4, a5, a6, a7 wird die Quantisierungsstufe innerhalb des Segments angegeben. Diese vier Bits ermöglichen somit die Codierung von jeweils 16 Quantisierungsstufen innerhalb jedes Segments. Insgesamt ergeben sich also 256 Quantisierungsstufen. Die 16 Quantisierungsstufen innerhalb jedes Segments sind gleichmäßig verteilt. Also handelt es sich hierbei um eine lineare Quantisierung innerhalb jedes Segments.
Codierung an der Sendeseite
Um einem Abtastwert s(i) eines Sprachsignals s(t) ein Codewort zuordnen zu können, wird zuerst der Abtastwert s(i) normiert: x = s(i)/Smax. Danach wird der ihm entsprechende Wert y nach der Kennlinie (s. Abb. 5.1-4) berechnet und einem Segment der Kennlinie zugeordnet. Damit werden das Vorzeichen und die Segmentnummer, d.h. die ersten vier Bits a0, a1, a2, a3 im Codewort bestimmt. Danach wird der Wert y einer Quantisierungsstufe innerhalb des Segments zugeordnet. Dadurch werden die letzten vier Bits a4, a5, a6, a7 festgelegt. Bei der Sprachcodierung nach PCM gemäß G.711 werden zwar die Quantisierungsstufen innerhalb jedes Segments regelmäßig verteilt, durch die Kompandierung werden die kleinen Amplitudenwerte aber vergrößert und die großen verkleinert. Dies führt im Endeffekt zu einer nichtlinearen Quantisierung.
5.1 Sprachcodierung bei VoIP
Der PCM-Decodierer muss jedem 8-Bit-Codewort einen normierten Abtastwert zuordnen. Hierfür werden zunächst die ersten vier Bits a0, a1, a2, a3 im Codewort interpretiert, um das Segment der Kompandierungskennlinie auszuwählen. Danach wird die Quantisierungsstufe im Segment aus den letzten vier Bits a4, a5, a6, a7 bestimmt. Auf diese Weise lässt sich der quantisierte Wert y* ermitteln.
157 Decodierung an der Empfangsseite
Jeder Quantisierungsstufe auf der y-Achse nach der Kompandierungskennlinie entspricht eindeutig eine Quantisierungsstufe auf der x-Achse. Für jeden Wert y* kann somit der ihm entsprechende Wert x* bestimmt werden. Da x* den normierten Abtastwert des Sprachsignals s(t) darstellt, multipliziert der Decodierer alle Werte x* mit dem Wert Smax (Smax = maximale Amplitude), um die Abtastwerte des Sprachsignals zu bestimmen. Wie Abbildung 5.1-1 zeigt, werden diese Abtastwerte an ein Halteglied übergeben, um den zeitlichen Verlauf des analogen Sprachsignals mit einer Treppen-Kurve zu approximieren. Die A-Kompandierungskennlinie wird überwiegend in Europa eingesetzt. In µ-Kennlinie Amerika und in Japan verwendet man eine andere Kennlinie, die den Parameter (µ-Law) µ enthält. Aus diesem Grunde wird sie als µ-Kompandierungskennlinie (bzw. µ-Kennlinie) oder µ-Law bezeichnet.
www.wiwobooks.com
Im Gegensatz zur A-Kennlinie, die mit 13 Segmenten beschrieben wird, enthält A-Law und die µ-Kennlinie 15 Segmente. Weil sich die beiden Kennlinien in der Codie- µ-Law sind rung geringfügig unterscheiden, sind sie nicht kompatibel. Um dennoch digita- inkompatibel le Sprachverbindungen zwischen Europa und Amerika zu ermöglichen, muss eine Signalumsetzung erfolgen. Die hierfür notwendige Umcodierung zwischen A- und µ-Kennlinien wird im ITU-T-Standard G.711 definiert.
5.1.4 Nachbildung der Spracherzeugung Die Basis für die Segment-orientierte Sprachcodierung stellt eine Nachbildung des Vokaltraktes beim Menschen dar, in dem die Sprache erzeugt wird. Da die Eigenschaften der menschlichen Sprache in kleinen Zeitintervallen von ca. 10 bis 30 ms unverändert bleiben, kann eine Sprachaufnahme in einem kleinen Zeitintervall mit Hilfe einiger konstanter Parameter, die den Vokaltrakt beschreiben, dargestellt werden. Um eine Sprachaufnahme von beispielsweise 20 ms zu übertragen, genügt es, die Werte nur einiger Parameter zu übertragen. Dadurch lässt sich die Menge der zu übertragenden Bits enorm reduzieren.
Basis für Segmentorientierte Sprachcodierung
Abbildung 5.1-5a illustriert die Erzeugung der menschlichen Sprache. Der für Modell des die Erzeugung von Sprachsignalen zuständige Vokaltrakt des Menschen kann Vokaltraktes mit Hilfe eines akustischen Ersatzmodells nachgebildet werden. Dieses Modell wird auch als LPC-Vocoder (Linear Predictive Coding) bzw. kurz als Vocoder bezeichnet.
158
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
N a se n ra u m M u n d ra u m
a ) S p ra c h e
V o k a ltra k t
S tim m b ä n d e r L u ft a u s d e r L u n g e Im p u ls g e n e r a to r P itc h P e rio d e R a u sc h g e n e r a to r
G e n e ra to r v o n s tim m h a fte n L a u te n G e n e ra to r v o n s tim m lo s e n L a u te n
b )
E rze u g u n g d e r A n re g u n g F ilte r L a u ts tä rk e
S p ra c h e
V o k a ltr a k t (A r tik u la tio n )
Abb. 5.1-5: Nachbildung der Spracherzeugung: a) Prinzip der Spracherzeugung, b) Modell der Spracherzeugung
Spracherzeugung
www.wiwobooks.com
Dem Vocoder liegt die Tatsache zugrunde, dass der Mensch beim Sprechen entweder einen stimmhaften oder einen stimmlosen Laut erzeugt. Um die menschliche Sprache nachzubilden, benötigt man einen Impulsgenerator, um die stimmhaften Laute nachzubilden, und einen Rauschgenerator für die Nachbildung von stimmlosen Lauten. Der Impulsgenerator wird mit der Periode der Vibration von Stimmbändern angesteuert. Die Lautformung (Artikulation) im Vokaltrakt lässt sich mit einem linearen Filter nachbilden.
Beschreibung Die Erzeugung der Sprache kann so beschrieben werden: der Sprachstimmhaft/stimmlos als Parameter V/UV (Voiced/Unvoiced); erzeugung
die Periode T der Vibration von Stimmbändern – auch als Pitch-Periode (Pitch Period) bezeichnet; die Lautstärke als Parameter G (Gain); die Artikulation mit Hilfe eines linearen Filters mit Parametern a1, ..., aK. LPCVocoder
Aus dem in Abbildung 5.1-5b dargestellten Modell der Spracherzeugung entsteht der LPC-Vocoder (s. Abb. 5.1-6), der eine Sprachaufnahme innerhalb eines kurzen Intervalls (z.B. von 20 ms) mit Hilfe einiger Parameter beschreibt. Mit einem LPC-Vocoder ist es möglich, eine Folge s(1), ..., s(N) von Abtastwerten eines analogen Sprachsignals durch den folgenden Vektor A = (a1, ..., aK, V/UV, G, T) von Parametern, die den menschlichen Vokaltrakt beschreiben, zu ersetzen. Oft wird der LPC-Filter mit 10 Parametern (d.h. K = 10) verwendet, sodass man auch LPC-10 schreibt.
5.1 Sprachcodierung bei VoIP
T
P itc h - T P e rio d e
Im p u ls G e n e ra to r Im p u ls G e n e ra to r
u (n ): A n re g u n g
s tim m h a ft V
s(n ) = u (n ) -
u (n )
K
Si = 1 a i
159
* s (n -i)
L P C -F ilte r
s(n )
U V s tim m G lo s A m p litu d e
s (n ): n -te r A b ta s tw e rt d e s S p ra c h s ig n a ls
A = ( a 1, a 2, ..., a K , V /U V , G , T )
S p r a c h a u fn a h m e z. B . ü b e r 2 0 m s
Abb. 5.1-6: LPC-Vocoder als Modell der Spracherzeugung LPC: Linear Predictive Coding
Wie Abbildung 5.1-6 zeigt, wird der n-te Abtastwert s(n) des Sprachsignals aus Einsatz der der Anregung u(n) und aus den letzten Abtastwerten s(n-1), ..., s(n-K) ermittelt. linearen Dies bedeutet, dass eine lineare Kombination der letzten K Abtastwerte mit den Prädiktion Koeffizienten a1, ..., aK ermöglicht, den neuen Abtastwert s(n) abzuschätzen. Es handelt sich hier um eine lineare Prädiktion (Linear Prediction).
www.wiwobooks.com
Mit dem Vektor A wird in der Regel eine Sprachaufnahme von ca. 10 – 30 ms Vorteil der repräsentiert. Da das analoge Sprachsignal 8000-mal pro Sekunde abgetastet LPC-Technik wird, kann eine Sprachaufnahme z.B. von 20 ms als Folge der Abtastwerte s(1), s(2), ..., s(160) dargestellt werden. Verwendet man aber den LPC-10Filter (K = 10), so müssen nur 13 Parameter – anstelle der 160 Abtastwerte – codiert und übertragen werden. Dies ist der größte Vorteil der LPC-Technik. Beispiel: Sprachcodierung mit 2.4 bzw. mit 4.8 kbit/s Beim Einsatz eines Filters LPC-10 müssen beispielsweise nur 13 Parameter als Vektor A = (a1, ..., a10, V/UV, G, T) codiert und übertragen werden. Man verwendet nur 48 Bits, um diese 13 Parameter zu codieren. Aus diesen 48 Bits wird ein Frame gebildet, der eine Sprachaufnahme mit Hilfe von 13 Parametern beschreibt. Soll jeder Einzelne dieser Frames eine Sprachaufnahme je: • von 20 ms beschreiben, müssen 50 Frames pro Sekunde übermittelt werden. Dies entspricht der Bitrate von 50 [1/s] • 48[Bit] = 2.4 kbit/s. • von 10 ms beschreiben, müssen 100 Frames pro Sekunde übermittelt werden. Dies erzeugt die Bitrate von 100 [1/s] • 48[Bit] = 4.8 kbit/s.
5.1.5 Segment-orientierte Sprachcodierung Die Segment-orientierte Sprachcodierung ist für VoIP-Anwendungen von sehr Prinzip: großer Bedeutung. Die darauf basierenden Verfahren funktionieren nach dem Analysis-byPrinzip Analysis-by-Synthesis (Analyse-durch-Synthese), kurz AbS (s. Abb. 5.1- Synthesis
160
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
7). Mit diesem Sprachcodierungsverfahren werden derzeit die höchsten Komprimierungsgewinne bei gleichzeitig hoher Sprachqualität erzielt. S e n d e s e ite
Ü b e r m ittlu n g
C o d ie r e r s (i)
E m p fa n g s s e ite D e c o d ie r e r
F P
S F
S A s(n ) +
-
s e(n )
n u r S F -P a ra m e te r
e (n )
e (n ) = > m in 2
e (n ) = s (n ) - s e(n )
S F
F P
s * (i)
F P : F ra m e -P u ffe r S A : S p ra c h a n a ly s e S F : S y n th e s e filte r
Abb. 5.1-7: Sprachübermittlung bei der Segment-orientierten Sprachcodierung nach dem Analysis-by-Synthesis-Prinzip
Sprachanalyse auf der Sendeseite
Beim Codierungsverfahren nach dem AbS-Prinzip wird das Sprachsignal in die Zeitabschnitte, die sog. Segmente, von 10 bis 20 ms zerlegt. Innerhalb der einzelnen Segmente werden die Eigenschaften des Sprachsignals als konstant angenommen. Ein Segment von 20 ms eines Sprachsignals wird durch seine 160 Abtastwerte s(i) dargestellt, die im Frame-Puffer abgespeichert werden. Es wird eine Analyse jedes Segments des Sprachsignals durchgeführt, indem man die Parameter eines LPC-Filters berechnet (s. Abb. 5.1-6), um den menschlichen Vokaltrakt zur Spracherzeugung zu beschreiben. Man bezeichnet diese Sprachanalyse als LPC-Analyse.
Sprachsynthese auf der Sendeseite
Die bei der Sprachanalyse ermittelten Parameter des menschlichen Vokaltraktes dienen als Eingangsparameter für die Sprachsynthese beim Empfänger. Die Aufgabe der Sprachanalyse besteht darin, die Parameter für die Sprachsynthese optimal zu ermitteln. Sie werden so berechnet, dass die Fehler e(i) = s(i) – se(i), i = 1, 2, ... zwischen den Abtastwerten und ihren Approximationen reduziert werden. Mit Hilfe einer Prozedur zur Fehlerminimierung, d.h. e2(i) min, werden die Parameter für die Sprachsynthese im Codierer auf der Sendeseite berechnet, codiert und zum Empfänger übertragen.
Parametrische Verfahren
Bei den Segment-orientierten Sprachcodierungsverfahren werden somit nur die Parameter übertragen, die man benötigt, um auf der Empfangsseite ein Sprachsegment (z.B. von 20 ms) synthetisch zu erzeugen. Aus diesem Grund nennt man derartige Sprachcodierungsverfahren oft parametrisch.
Sprachsynthese auf der Empfangsseite
Ein Sprachcodierer nach dem AbS-Prinzip wandelt ein Sprachsegment in eine Anzahl von Parametern für die Sprachsynthese um, die als Ersatz für das Sprachsignal zum Empfänger übertragen werden. Auf der Empfangsseite erfolgt die Sprachsynthese nach dem gleichen Prinzip, d.h. mit dem gleichen
www.wiwobooks.com
5.1 Sprachcodierung bei VoIP
Synthesefilter, wie im Codierer. Der Decodierer auf der Empfangsseite erzeugt somit ein synthetisches Sprachsignal.
5.1.6 VoIP-relevante Sprachcodierungsverfahren Es gibt mehrere Sprachcodierungsverfahren, die bei VoIP verwendet werden. Abbildung 5.1-8 zeigt eine Gegenüberstellung dieser Verfahren in Abhängigkeit von der Qualität und der Bitrate. Wie bereits in Abschnitt 5.1.1 erwähnt, unterscheidet man zwischen Abtastwert-orientierten und Segment-orientierten Sprachcodierungsverfahren. Die Abtastwert-orientierten Codierungsverfahren erzeugen einerseits die Bitströme mit den Bitraten, die größer als 16 kbit/s sind, und garantieren andererseits eine sehr gute Sprachqualität. Die Segment-orientierten Codierungsverfahren erzeugen die Bitströme mit den geringeren Bitraten als 16 kbit/s. Die Sprachqualität wird bei diesen Verfahren mit zunehmender Reduzierung der Bitrate immer geringer, sodass sie von gut bis schlecht reicht.
6 4 4 0 3 2
B itra te [k b it/s ]
2 4 1 6 8 6 .3
A b ta s tw e rto rie n tie rt
www.wiwobooks.com
P C M A D P C M A C E L P M P -M L Q L D -C E L P C S -A C E L P
= > = > = > = > = > = >
A D P C M L P C 4 .8
G .7 G .7 G .7 G .7 G .7 G .7
A D P C M 1 6 M P -M L Q
A C E L P 5 .3
s c h le c h t
1 1 2 6 2 3 .1 2 3 .1 2 8 2 9
P C M
A D P C M A D P C M
3 2
4 0
S e g m e n to rie n tie rt
2 4
L D -C E L P C S -A C E L P 8 C S - A C E L P 6 .4
Q u a litä t se h r g u t
Abb. 5.1-8: Gegenüberstellung von für VoIP-relevanten Sprachcodierungsverfahren ADPCM: Adaptive Differential PCM, CELP: Code-Excited Linear-Prediction, ACELP: Algebraic-Code-Excited Linear-Prediction, LD-CELP: Low-Delay CELP, LPC: Linear Predictive Coding, MP-MLQ: Multipulse Maximum Likehood Quantization, PCM: Pulse Code Modulation
Die in Abbildung 5.1-8 aufgelisteten Sprachcodierungsverfahren lassen sich wie folgt kurz charakterisieren: PCM (Pulse Code Modulation) Das PCM-Verfahren realisiert eine Abtastwert-orientierte Sprachcodierung und wurde in Abschnitt 5.1.1 bereits kurz präsentiert (s. Abb. 5.1-2a). Das PCM-Verfahren spezifiziert der ITU-T-Standard G.711. Bei PCM wird das analoge Sprachsignal 8000-mal pro Sekunde abgetastet und nach dem in
161
162
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Abschnitt 5.1.3 dargestellten Prinzip quantisiert. Jedem quantisierten Abtastwert wird ein Codewort von 8 Bits zugeordnet. So entsteht ein Bitstrom von 8000 • 8 [Bit] = 64 kbit/s. ADPCM (Adaptive Differential PCM) Das ADPCM-Verfahren realisiert ebenso wie PCM eine Abtastwertorientierte Sprachcodierung, die bereits kurz in Abschnitt 5.1.1 präsentiert wurde (s. Abb. 5.1-2b). ADPCM wird in den Standards G.726 und G.727 spezifiziert. Bei ADPCM werden die Differenzen zwischen den Abtastwerten und ihren Schätzungen mit Hilfe eines adaptiven Prädiktionsfilters berechnet, quantisiert und codiert. Da diese Differenzen in der Regel kleiner als Abtastwerte sind, können sie mit den Codewörtern nur mit einer Länge von 5, 4, 3 und 2 Bits codiert werden, sodass entsprechend die Bitströme mit 40, 32, 24 und 16 kbit/s entstehen. LPC (Linear Predictive Coding) Hierbei handelt es sich um ein Segment-orientiertes Sprachcodierungsverfahren, bei dem die Erzeugung der menschlichen Sprache mit Hilfe eines linearen LPC-Filters nachgebildet wird (s. Abb. 5.1-6). Dadurch lassen sich große Komprimierungsgewinne erzielen und die Bitraten 4.8 bzw. 2.4 kbit/s erreichen. Das LPC-Verfahren liegt allen Segment-orientierten Sprachcodierungsverfahren zugrunde.
www.wiwobooks.com
CELP (Code-Excited Linear-Prediction) und seine Varianten CELP ist ein Segment-orientiertes Codierungsverfahren, das nach dem in Abbildung 5.1-7 gezeigten AbS-Prinzip funktioniert. Bei CELP werden die Parameter des LPC-Filters aus den Referenzsprachsegmenten im Voraus berechnet und im sog. Codebuch (Codebook) als Vektoren abgespeichert. Bei der Codierung eines Sprachsegments wird im Codebuch nach dem „passenden“ Vektor gesucht. Dieser Vektor wird weiter so modifiziert, dass das Sprachsegment möglichst genau durch ein synthetisches Sprachsignal nachgebildet werden kann. Dem Decodierer wird der modifizierte Vektor übermittelt, der daraufhin ein synthetisches Sprachsignal erzeugt. Zu diesen CELP-basierenden Verfahren gehören: − ACELP (Algebraic CELP) mit 5.3 kbit/s aus G.723.1 − LD-CELP (Low-Delay CELP) mit 16 kbit/s aus G.728 − CS-ACELP (Conjugate-Structure ACELP): mit 8 kbit/s und normaler Komplexität aus G.729; mit 8 kbit/s und reduzierter Komplexität aus G.729 Annex A; mit 8 kbit/s und reduzierter Komplexität sowie mit Silence Compression aus G.729 Annex AB; CS-ACELP mit 6.4 kbit/s aus G.729 Annex D. Bemerkung: Bei Silence Compression werden stille Sprachabschnitte entdeckt und einfach unter der Angabe der Länge codiert.
5.1 Sprachcodierung bei VoIP
163
MP-MLQ (Multipulse Maximum Likehood Quantization) MP-MLQ mit 6.3 kbit/s wird im G.723.1 spezifiziert und ist ein Segmentorientiertes Codierungsverfahren, das auf dem in Abbildung 5.1-7 dargestellten AbS-Prinzip basiert.
5.1.7 Sprachqualität nach MOS-Skala Die Qualität der Sprachkommunikation bei VoIP wird durch die Laufzeit (De- Sprachlay) der IP-Pakete über das Netz, die Laufzeitunterschiede (Jitter) und die Ver- qualitätsluste von IP-Paketen im Netz beeinflusst. Diese Quality-of-Service-Parameter kriterien sind relativ leicht zu messen, sagen aber leider nichts über die eigentliche Sprachqualität aus. Sie zeigen nicht an, ob ein Telefongespräch noch verständlich ist oder nicht. Die Sprachqualität ist natürlich ein subjektives Kriterium. Für die Aussage über Sprachqualität sind folgende Aspekte wichtig: Verständlichkeit der Sprache, Akzeptanz der Lautstärke sowie Akzeptanz der Laufzeitschwankungen und Echos.
www.wiwobooks.com
Als objektives Kriterium, mit dem die eben erwähnten Aspekte zum Ausdruck gebracht werden, dient MOS (Mean Opinion Score). Die MOS-Werte werden durch einen standardisierten Testaufbau ermittelt, in Sprachdem vielen repräsentativ ausgewählten Versuchspersonen Sprachproben vorge- qualität und spielt werden und der Höreindruck ermittelt wird. Dadurch entsteht eine allge- MOS-Werte meingültige Aussage über die Sprachqualität. Tabelle 5.1-1 stellt die MOSSkala dar.
Tab. 5.1-1:
MOS-Wert
Bedeutung
5 = excellent
keinerlei Anstrengung zum Verständnis der Sprache notwendig; totale Entspannung möglich
4 = good
keine Anstrengung notwendig, Aufmerksamkeit nötig
3 = fair
leichte, moderate Anstrengung nötig
2 = poor
merkbare, deutliche Anstrengung nötig
1 = bad
trotz Anstrengung keine Verständigung
MOS-Skala für die Beurteilung der Sprachqualität
Die analoge Sprachübertragung kommt hierbei auf einen MOS-Wert von 3.5 Typische bis 4.0. Die Sprachübertragung über das ISDN erzielt mit 4.5 die besten Werte. MOS-Werte Hochwertige VoIP-Implementierungen bieten eine Sprachqualität zwischen 3.8 und 4.4 je nach verwendeter Sprachcodierung. Damit bieten VoIP-Systeme
164
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
mindestens die Qualität eines herkömmlichen analogen Telefonnetzes. Tabelle 5.1-2 zeigt die MOS-Werte von VoIP-relevanten Sprachcodierungsverfahren.
Tab. 5.1-2:
Verfahren
Bitrate [kbit/s]
MOS-Wert
PCM
64
4.3 - 4.5
ADPCM
16/24/32/40
3.4/3.6/3.9/4.2
CS-ACELP
8/6.4
4.0/3.8
LD-CELP
16
4.0 - 4.1
ACELP
5.3
3.5
MP-MLQ
6.3
3.7
MOS-Werte von Verfahren zur Sprachcodierung Abkürzungen wie in Abbildung 5.1-8
Standard PESQ
Es entstand Bedarf nach automatisierten Verfahren für die Ermittlung von MOS-Werten in VoIP-Systemen. Hierfür hat die ITU-T den Standard P.862, kurz PESQ (Perceptual Evaluation of Speech Quality), definiert. Dieser Standard stellt ein automatisches Analyseverfahren zur Bewertung der Sprachqualität in VoIP-Systemen dar.
Faktor R
Um die Sprachqualität bereits während des Verlaufs der Kommunikation abschätzen und die Abschätzung im MOS-Wert angeben zu können, wurde der sog. Faktor R eingeführt. Darauf geht Abschnitt 5.6.5 näher ein (s. Abb. 5.6-7).
www.wiwobooks.com
5.2
Protokolle für Sprachübermittlung
Echtzeitkommunikation mit RTP
Die Übermittlung von Sprache, Audio und Video – also von Echtzeitmedien – über ein IP-Netz verläuft in Echtzeit. In diesem Fall ist der Einsatz der Protokolle für die Datenkommunikation, bei denen man die Quittungen verwendet, um eventuell eine wiederholte Übermittlung von fehlerhaft empfangenen Daten zu veranlassen, nicht möglich. Deshalb wurde RTP (Real-time Transport Protocol) entwickelt und bei der IETF im Januar 1996 als RFC 1889 spezifiziert. Dieser RFC wurde aber im Juli 2003 durch RFC 3550 abgelöst.
Bedeutung von RTCP
Für die Überwachung der Echtzeit-Kommunikation nach RTP ist ein Kontrollprotokoll nötig. Hierfür wird RTCP (RTP Control Protocol), das die parallele Übertragung von Kontroll- und Statusinformationen zwischen den Endpunkten einer Session ermöglicht und auch in RFC 3550 spezifiziert wird. Der Empfänger von Audio/Video beispielsweise sendet dem Absender dieser Medien periodisch RTCP-Pakete, die als Berichte (Reports) angesehen werden können. In ihnen werden die Informationen über den aktuellen Zustand des Empfängers selbst und über die aktuelle Qualität der Audio/Video-Übertragung übermittelt.
5.2 Protokolle für Sprachübermittlung
165
Multimediale Kommunikation über ein IP-Netz ist nur dann sinnvoll, wenn die Bewertung Echtzeitmedien in ausreichender Qualität empfangen werden. Es müssen somit von QoSbestimmte Netzparameter abgeschätzt werden, die eine Aussage über die Qua- Parametern lität der Kommunikation liefern können. Man spricht in diesem Zusammenhang von Quality of Service (QoS) und QoS-Parametern. Sie können mit Hilfe von RTCP während der Kommunikation fortlaufend bewertet werden (siehe Abschnitt 5.6).
5.2.1 Bedeutung einer Session Wie bereits erwähnt, wird Sprache bei VoIP mit Hilfe des Protokolls RTP übermittelt. Haben sich zwei IP-Telefone hinsichtlich der Regeln, nach denen die Sprache mit RTP-Hilfe übermittelt werden soll, verständigt, so kann dies interpretiert werden, als ob zwischen ihnen eine VoIP-Session (-Sitzung) aufgebaut worden wäre (im Weiteren kurz Session). Eine Session für VoIP ist in der Regel eine Singlemedia-Session – s. Abbildung 5.2-1 – und enthält nur einen logischen Medienkanal (Media Channel), über welchen Sprache in RTPPaketen übermittelt wird. Eine Multimedia-Session – s. Abbildung 5.2-2 – enthält dagegen mehrere Medienkanäle nach RTP.
Interpretation einer (VoIP-) Session
www.wiwobooks.com
IP -T e l. A IP -A d r. = p
S p ra c h ü b e rm ittlu n g
IP -T e l. B IP -A d r. = r
IP -N e tz
x x + 1
A u fb a u d e r S e s s io n S e s s io n -B e s c h r e ib u n g R T P
S in g le m e d ia -S e s s io n S p ra c h e M C
R T C P
M C C
R T C P -P a k e te
y y + 1
A b b a u d e r S e s s io n x , y : R T P -P o rts ; g e ra d e Z a h le n
x + 1 , y + 1 : R T C P -P o rts ; u n g e ra d e Z a h le n
Abb. 5.2-1: Phasen bei der Sprachkommunikation über ein IP-Netz MC: Media Channel, MCC: Media Control Channel
Wie Abbildung 5.2-1 illustriert, muss eine Session zuerst aufgebaut werden. Danach findet die Sprachübermittlung statt. Nach Ablauf der Kommunikation muss die bestehende Session wieder abgebaut werden, um die vorher belegten Netzressourcen – z.B. die belegte Kapazität einer Leitung als Bandbreite – freizugeben. RTP dient bei VoIP als reines Transportprotokoll für die Sprachübermittlung Signalisieund stellt keine Mechanismen zum Aufbau einer Session bereit. Deshalb wird rungsein Signalisierungsprotokoll benötigt, nach dem sich die kommunizierenden protokoll
166
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
IP-Telefone auf die Prinzipien der Sprachkommunikation über ein IP-Netz verständigen können. Bevor eine Sprachkommunikation zustande kommt, müssen sich die IP-Telefone mit Hilfe des Signalisierungsprotokolls u.a. auf ein gemeinsames Prinzip der Sprachcodierung – also auf das gleiche Sprachformat – verständigen. Für den Auf- und Abbau von Sessions bei VoIP verwendet man folgende Protokolle: SIP (Session Initiation Protocol): von der IETF entwickelt und in RFC 3261 spezifiziert. Das Konzept und den Einsatz von SIP präsentiert Kapitel 7; H.225.0 und H.245 aus dem Framework H323; stellen H.323-SIG(nalisierung) dar und werden in Kapitel 6 detailliert erläutert. Ein IP-Telefon, das eine Session für die Sprachkommunikation initiiert, muss SDP für Beschreibung in der Lage sein, diese einem anderen IP-Telefon durch die Übermittlung untervon Sessions schiedlicher Angaben näher zu beschreiben. Die Regeln dafür definiert das in RFC 4566 spezifizierte Protokoll SDP (Session Description Protocol). Die Beschreibung einer Session nach SDP wird in SIP-Nachrichten als sog. Body übermittelt (s. Abb. 7.4-1). Das Protokoll H.245 aus dem Framework H.323 enthält bereits die Regeln für die Beschreibung von Sessions. Aus diesem Grund ist H.245 ein sehr komplexes Protokoll.
www.wiwobooks.com
MC als RTPKanal
Wie Abbildung 5.2-1 zeigt, enthält eine Session zwei logische Kanäle, nämlich MC (Media Channel) zur Übermittlung eines Echtzeitmediums (z.B. Sprache) als RTP-Kanal und MCC (Media Control Channel) als RTCP-Kanal zur Kontrolle der Echtzeitkommunikation. Über den MC werden die in den IP-Paketen eingekapselten RTP-Pakete mit der Sprache übermittelt (s. Abb. 5.3-1).
MCC als RTCPKontrollkanal
Die Aufgabe von RTCP besteht in der Überwachung der Sprachübermittlung über den MC. Parallel zum MC wird somit ein MCC als RTCP-Kontrollkanal eingerichtet, in dem man Informationen über den Verlauf der Kommunikation in Form sog. RTCP-Pakete austauscht. Typischerweise hat RTP keine festgelegte Port-Nummer. Die für RTP empfohlene – und bei IANA registrierte – Port-Nummer ist 5004. Sie wird allerdings kaum verwendet. Stattdessen wird die Port-Nummer beim Aufbau einer Session ausgehandelt, d.h. sie ist dynamisch. In der Regel wird dem RTP eine gerade Port-Nummer zugeteilt. Zusätzlich gilt: Hat RTP die Port-Nr. x (gerade Zahl), dann ist x+1 die Port-Nr. von RTCP.
MultimediaSession
Hervorzuheben ist aber, dass die in Abbildung 5.2-1 gezeigte Session mit nur 1 einem Media-Kanal als Singlemedia-Session – normalerweise – die Übermitt1
Ein Media-Kanal kann auch mehrfach genutzt werden, d.h. unter bestimmten Voraussetzungen können mehrere Medien über ihn abwechselnd transportiert werden. Beim SIP-Einsatz ist dies mit Hilfe von SDP möglich.
5.2 Protokolle für Sprachübermittlung
167
lung nur eines Media erlaubt. Wie Abbildung 5.2-2 zeigt, enthält eine Multimedia-Session dagegen mehrere Media-Kanäle, d.h. einen Kanal pro Media. R e c h n e r A IP -A d r. = p 1
x 1+ 1 x
IP -A d r. = r
A u fb a u d e r S e s s io n
x Ü b e rm ittlu n g v o n M e d ie n
R e c h n e r B
IP -N e tz
R T P R T C P
2
x 2+ 1
R T P R T C P
M C
M u ltim e d ia -S e s s io n M e d ia 1 1
M C C M C
R T C P -P a k e te 1
M e d ia 2 2
M C C 2
R T C P -P a k e te
y 1
y 1+ 1 y 2
y 2+ 1
S p ra c h e
V id e o
A b b a u d e r S e s s io n x 1, x 2, y 1, y 2: R T P -P o rts
x 1+ 1 , x 2+ 1 , y 1+ 1 , y 2+ 1 : R T C P -P o rts
Abb. 5.2-2: Übermittlung mehrerer Echtzeitmedien über eine Multimedia-Session MC: Media Channel, MCC: Media Control Channel
Die hier dargestellte Multimedia-Session setzt sich aus zwei Media-Kanälen MC1 und MC2 zusammen, über die zwei Medien – z.B. Sprache als Media 1 über MC1 und Video als Media 2 über MC2 – übermittelt werden. Die Überwachung der Sprachübermittlung über MC1 erfolgt mit RTCP-Hilfe über den Kontrollkanal MCC1 und die Überwachung der Videoübermittlung über den MCC2. Die Kanäle MC1 und MCC1 sowie MC2 und MCC2 bilden jeweils verbundene Kanalpaare einzelner Medien – und zwar von Media 1 und Media 2.
www.wiwobooks.com
Bisher haben wir über eine Kommunikation zwischen zwei Rechnern – also P2P-Session über eine Punkt-zu-Punkt-Session (Point-to-Point-Session) bzw. kurz P2P- versus PMPSession – gesprochen. Oft verläuft die Kommunikation aber gleichzeitig, quasi Session parallel, zwischen mehreren Rechnern wie z.B. eine verteilte Audio- und Video-Konferenz. Für eine solche Gruppenkommunikation braucht man eine Punkt-zu-Mehrpunkt-Session (Point-to-Multipoint-Session) – als PMP-Session bezeichnet. Beispiel: Abbildung 5.2-3 illustriert eine PMP-Session am Beispiel einer Konferenz. Wie hier zum Ausdruck gebracht wird, ist für die Realisierung einer Gruppenkommunikation eine zentrale Komponente – wie z.B. der hier gezeigte Konferenzserver – nötig, um ein aus einem Medienkanal in Paketen eintreffendes Media an die anderen Medienkanäle zu übergeben. Diese zentrale Komponente realisiert demzufolge eine Vermittlungsfunktion. Hier ist auch ersichtlich, dass eine PMP-Session sich aus mehreren P2P-Sessions zusammensetzt, die über einen Konferenzserver miteinander verbunden sind. Zusätzlich ist hervorzuheben, dass die Media-Kanäle in einzelnen P2P-Sessions gerichtet sind. Das heißt, sie sind entweder im Zustand recvonly (receive only) oder sendonly (send only), und ihre Zustände werden während der Konferenz dynamisch so verändert, dass die Sprache und die Videoaufnahme vom Redner an die anderen Teilnehmer der Konferenz übermittelt werden, die nur empfangen können.
Beispiel für eine PMPSession
168
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP Solche dynamischen Veränderungen der Zustände von Media-Kanälen einzelner P2PSessions erfolgen z.B. bei Einsatz von SIP als Signalisierungsprotokoll mit Hilfe des Protokolls SDP (Session Description Protocol). Um den Zustand der Media-Kanäle einer P2PSession zu ändern, benötigt man eine SIP-Nachricht wie z.B. UPDATE, die über entsprechende P2P-Sessions geschickt wird. In deren Body-Teil (s. Abb. 7.3-1) ist für jeden MediaKanal eine entsprechende a-Zeile (Attribut-Zeile) entweder a=sendonly oder a=recvonly enthalten. re c v o n ly
K o n fe re n z se rv e r A
o n A S e ssi
T ln A
V
A
S e s s io n X V
T ln X
s e n d o n ly
A
V re c v o n ly
R e d n e r
S e s s io n Y
T ln Y
Abb. 5.2-3: Illustration einer Mehrpunkt-Session am Beispiel einer Konferenz
www.wiwobooks.com A: Audio, V: Video, Tln: Teilnehmer
PMP-Sessions mit einer Vermittlungsfunktion auf einem zentralen Server – wie in Abbildung 5.2-3 gezeigt – werden z.B. bei der Realisierung eines virtuellen Unterrichtsraums sowie in multimedialen Real-time Collaboration Systemen auf der Basis des Internet realisiert.
5.2.2 RTP/RTCP und Transportprotokolle der IP-Netze Abbildung 5.2-4 illustriert die Einordnung von VoIP-Protokollen im Schichtenmodell der IP-Netze. Wie hier ersichtlich ist, stellt RTP zwar ein Protokoll für den Transport von Echtzeitmedien wie Audio/Sprache und Video dar, dennoch wird es als Anwendung oberhalb der Transportschicht angesiedelt. Für die Überwachung der QoS-Parameter sowie für die zusätzliche Steuerung zwischen Sender und Empfänger wird parallel RTCP verwendet, das ein integraler Bestandteil von RTP ist. Für den Auf- und Abbau einer Session für die Übermittlung von Echtzeitmedien mit RTP – siehe Abbildungen 5.2-1 und -2 – kann sowohl H.323-SIG als auch das Signalisierungsprotokoll SIP eingesetzt werden. SIP über UDP
SIP nutzt in der Regel das verbindungslose Transportprotokoll UDP. Wie in Kapitel 7 gezeigt wird, garantiert SIP eine zuverlässige Übermittlung der Nachrichten selbst. Das Protokoll SDP für die Beschreibung von Sessions kann als Bestandteil von SIP angesehen werden. Für den Transport von SIP-Nachrichten
5.2 Protokolle für Sprachübermittlung
169
über IP-Netze können aber auch weitere Transportprotokolle – darunter DCCP, TCP und sogar auch SCTP – verwendet werden. Darauf geht Abschnitt 7.1.1 detaillierter ein. A u d io /V o ic e - u n d V id e o -A n w e n d u n g e n A u d io /V o ic e , V id e o H .3 2 3 - S I G
S IP
S D P
S IP
R T P
R T C P
U D P
T C P In te rn e t
A n w e n d u n g ss c h ic h t
R T P D C C P
P ro to c o l (IP v 4 , IP v 6 )
T ra n s c h ic V e rm s c h ic
s p o r th t ittlu n g s h t
Ü b e rm ittlu n g s n e tz e
Abb. 5.2-4: RTP/RTCP über die Transportprotokolle UDP, TCP und DCCP SIG: SIGnalisierung, SDP: Session Description Protocol, SIP: Session Initiation Protocol
Die H.323-SIG dagegen nutzt ausschließlich das verbindungsorientierte und H.323-SIG zuverlässige Transportprotokoll TCP. Man kann sich die H.323-SIG als eine über TCP Realisierung des D-Kanalprotokolls von ISDN über TCP-Verbindungen vorstellen. Dies erläutern wir in Abschnitt 6.2 näher.
www.wiwobooks.com
Mit RTP werden sog. RTP-Pakete gebildet (s. Abb. 5.3-1), in denen verschie- Standarddene Echtzeitmedien – bei VoIP Sprache – als sog. Payload (Nutzlast) enthal- mäßig RTP ten sind. Die RTP-Pakete werden dann während einer Session mit Hilfe eines über UDP Transportprotokolls über IP-Netze transportiert. RTP nutzt standardmäßig das verbindungslose Transportprotokoll UDP. Da UDP keine Überlastkontrolle beim Transport von Echtzeitmedien über IPNetze ermöglicht, wurde das neue verbindungslose Transportprotokoll DCCP (Datagram Congestion Control Protocol) entwickelt und in RFC 4340 (März 2006) spezifiziert. DCCP kann für den Transport von RTP-Paketen mit Echtzeitmedien und von RTCP-Paketen mit Kontrollinformationen verwendet werden. Den Einsatz von RTP und von RTCP über DCCP beschreibt der InternetDraft draft-ietf-dccp-rtp-07, der bereits als RFC zur Veröffentlichung übergeben wurde. Falls es nötig ist, Echtzeitmedien über eine zuverlässige virtuelle Verbindung über ein IP-Netz zu transportieren, können RTP und RTCP hierfür das zuver2 lässige und verbindungsorientierte Transportprotokoll TCP verwenden. Da TCP eine Ende-zu-Ende-Fehlerkontrolle zur Verfügung stellt, ist die Funktion von RTCP nicht mehr nötig, sodass bei RTP über TCP das Protokoll RTCP 2
Mit RTP over TCP kann u.a. der Fax-Dienst über das Internet realisiert werden.
RTP über DCCP
RTP über TCP
170
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
„ausgeschaltet“ werden kann. Demzufolge werden dann keine RTCP-Pakete mehr übermittelt. RFC 4571 beschreibt, wie man RTP und RTCP über TCP verwendet – siehe hierfür auch RFCs 4145 und 4572. RTP-Port bei Der offizielle RTP-Port – als Well-Known-Port – für die Transportprotokolle UDP, DCCP UDP, DCCP und TCP hat die gleiche Nummer 5004. Diese Portnummer ist und TCP aber nicht relevant. Wie in Abschnitt 5.2.1 erwähnt, wird in der Praxis dem Protokoll RTP – und somit auch dem RTCP – die Nummer des RTP-Ports in den kommunizierenden Rechnern dynamisch zugeordnet. Die beiden Rechner teilen sich ihre Portnummern beim Aufbau einer Session in ihrer Beschreibung nach dem Protokoll SDP mit (s. Abb. 5.3-2). Angaben für RTP über TCP
Sollte RTP nicht UDP nutzen, sondern TCP oder DCCP, muss darauf in der Beschreibung der initiierten Session explizit hingewiesen werden. Wie man hier das Protokoll SDP verwendet, zeigt das folgende Beispiel. Beispiel: Abbildung 5.2-5 illustriert den Verlauf der Abstimmung zwischen den Rechnern A und B beim Aufbau einer Session mit RTP über TCP. Um die initiierte Session zu beschreiben, wird SDP eingesetzt (s. Abb. 5.3-2 und 7.4-1).
c = IN IP 4 m = a u d io a = s e tu p :a a = c o n n e c b = R S :0 b = R R :0
S D 1 9 2 1 6 1 c tiv tio n
P -O ffe r .0 .2 .1 4 0 2 T C P /R T P /A V P 1 1 e :n e w
A B IN V IT E
S c = IN IP 4 m = a u d io a = s e tu p :p a = c o n n e c b = R S :0 b = R R :0
D P -A 1 9 2 .0 1 4 2 1 a s s iv tio n :n
www.wiwobooks.com T C P -V e r b in d u n g
2 0 0 O K
P T = 1 1 R T P S e s s io n
n sw e r .2 .2 8 6 T C P /R T P /A V P 1 1 e w
Abb. 5.2-5: Abstimmung beim Aufbau einer Session mit RTP über eine TCP-Verbindung IN: Internet, AVP: Audio/Video Profiles
Hier initiiert der Rechner A eine Session zum Rechner B, die auf einer TCP-Verbindung basieren soll, und macht in der SIP-Nachricht INVITE – genauer gesagt im Body-Teil dieser Nachricht (s. Abb. 7.1-9) – als SDP-Offer u.a. folgende Angaben: • In der c-Zeile (c: Connect) c=IN IPv4 192.0.2.14 informiert er den Rechner B darüber, dass seine IPv4-Adresse 192.0.2.14 ist. • In der m-Zeile (m: Media) m=audio 16102 TCP/RTP/AVP 11 teilt er mit, dass er 3 Audio im Format L16 (s. RFC 3551) – mit der festen PT-Nummer 11 – über den RTPPort 16102 senden und empfangen möchte, und mit TCP/RTP/AVP verweist er darauf, dass der Transport von Audio mit RTP über eine TCP-Verbindung erfolgen soll. • Er möchte dafür den Aufbau einer neuen TCP-Verbindung durch das Absenden des TCP-Pakets SYN initiieren, d.h. er möchte hierbei aktiv sein. Dies beschreiben die aZeilen (a: Attribut) a=setup:active und a=connection:new. • In den b-Zeilen (b: Bandwith) b=RS:0 und b=RR:0 gibt man an, dass die für RTCP reservierte RTCP-Bandbreite sowohl für den Sender der RTP-Pakete – d.h. RS (RTCP bandwidth, Sender) – als auch für den Empfänger der RTP-Pakete – d.h. RR (RTCP
3
Das Audioformat L16 ist bei IANA registriert und hat dort die PT-Nummer 11 (Payload Type). Mit dieser PT-Nummer wird dieses Audioformat in RTP-Paketen identifiziert (s. Abb. 5.3-1).
5.3 Konzept und Funktionen von RTP
171
bandwidth, Receiver) – 0 kbit/s sein soll. Auf diese Weise wird das Protokoll RTCP bei RTP über TCP de facto „ausgeschaltet“. Rechner B akzeptiert das Format L16, sodass er Rechner A im Body-Teil der nächsten an ihn gesendeten SIP-Nachricht – hier 200 OK – als SDP-Answer u.a. folgende Angaben macht: • In c=IN IPv4 192.0.2.28 gibt seine IPv4-Adresse 192.0.2.28 an. • Mit m=audio 14216 TCP/RTP/AVP 11 informiert er den Rechner A darüber, dass er das Audio im Format L16 über den RTP-Port 14216 senden und empfangen möchte und RTP über TCP akzeptiert. • Mit a=setup:passiv und a=connection:new wird seitens des Rechners B mitgeteilt, dass er beim Aufbau einer neuen TCP-Verbindung auf das TCP-Paket SYN wartet, d.h. hierbei passiv bleibt. • Mit b=RS:0 und b=RR:0 wird bestätigt, dass er damit einverstanden ist, dass RTCP „ausgeschaltet“ bleibt. Nach dem Eintreffen von SDP-Answer beim Rechner A gilt die Vereinbarung in Bezug auf RTP über TCP zwischen den beiden Rechnern als geschlossen.
5.3
Konzept und Funktionen von RTP
RTP wird in RFC 3550 spezifiziert. Inzwischen wurde diese Spezifikation Besonderheiten von RTP durch RFC 5506 ergänzt. Die wichtigsten Besonderheiten von RTP sind:
www.wiwobooks.com
Übermittlung von Echtzeitmedien in RTP-Paketen Ein Echtzeitmedia (Audio, Sprache bzw.Video) wird mit Hilfe von RTP als eine zusammenhängende Folge von RTP-Paketen über einen Media-Kanal – quasi wie eine virtuelle Verbindung – übermittelt (s. Abb. 5.2-1 und -2). Garantie der Reihenfolge von RTP-Paketen RTP nummeriert die mit Echtzeitmedien übertragenen Pakete, sodass die richtige Reihenfolge – sollte sie durch den Transport über das IP-Netz verändert werden – am Ziel wiederhergestellt werden kann. Garantie der Isochronität RTP vergibt den übertragenen RTP-Paketen mit den Echtzeitmedien einen Zeitstempel (Timestamp), sodass die gleichen Zeitabstände am Ziel wiederhergestellt werden können, wie sie zwischen den RTP-Paketen mit den 4 Echtzeitmedien beim Absenden waren. Damit wird die Isochronität bei der Echtzeitkommunikation garantiert (s. Abschnitt 5.6.1). Transport unterschiedlicher Formate von Echtzeitmedien Die RTP-Anwendungen sind u.a. VoIP, Videokonferenzen und multimediale Kommunikation. RTP übermittelt hierbei unterschiedliche Formate von Audio, Sprache und Video, die durch sog. Profiles genau bezeichnet 4
Isochronität – griechisch iso = gleich und chronos =Zeit – bedeutet die gleichen Zeitabstände an der Sende- und an der Empfängerseite.
172
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
sind. Diese Profiles wurden zuerst im Januar 1996 im RFC 1890 spezifiziert. Im Juli 2003 wurde RFC 1890 von RFC 3551 abgelöst. Translator- und Mixer-Einsatz Bei RTP kann ein Translator eingesetzt werden. Er empfängt die RTPPakete mit einem Echtzeitmedium in einem Format, übersetzt das Mediumformat in ein anderes und schickt die RTP-Pakete mit dem Echtzeitmedium im neuen Format weiter (s. Abb. 5.4-1). Bei RTP kann auch ein Mixer zum Einsatz kommen. Ein Mixer stellt eine Komponente dar, die von verschiedenen Quellen die Echtzeitbitströme empfängt, aus ihnen einen gemischten Bitstrom bildet und ihn weitersendet (s. Abb. 5.4-3).
5.3.1 Aufbau von RTP-Paketen Ein Echtzeitmedium wird nach RTP als Folge von RTP-Paketen übermittelt, die mit dem vorangestellten Header eines Transportprotokolls – in der Regel des UDP, aber auch DCCP und TCP (s. Abb. 5.2-4) – in den IP-Paketen transportiert werden. Jedes RTP-Paket enthält einen RTP-Header und einen Payload-Teil. Abbildung 5.3-1 illustriert dies näher.
www.wiwobooks.com
In d e r R e g e l d a s U D P -H e a d e r; E s k a n n a u c h d a s D C C P - o d e r T C P -H e a d e r s e in
IP
P a y lo a d (A u d io , V id e o )
R T P
T P -H
R T P -P a k e t 0 V
P X
C C
M
8
P T
1 6
S e q u e n c e N u m b e r
3 1
T im e s ta m p S y n c h ro n iz a tio n S o u rc e Id e n tifie r (S S R C ) C o n trib u tin g S o u rc e Id e n tifie rs (C S R C ) (o p tio n a l) H e a d e r E x te n s io n (o p tio n a l) P a y lo a d (A u d io /V id e o -S e g m e n t)
Abb. 5.3-1: RTP-Paket im IP-Paket und die Angaben im RTP-Header TP-H: Transportprotokoll-Header
Angaben im RTP-Header
Die wesentlichen Angaben im RTP-Header: PT: Payload Type (Payload-Typ, Nutzlasttyp), 8 Bits Hier wird angegeben, um welches Format es sich beim als Nutzlast transportierten Medium handelt, d.h. nach welchem Verfahren dieses Medium codiert wurde. Im Verlauf einer Session kann eine dynamische Änderung
5.3 Konzept und Funktionen von RTP
173
des Formats erfolgen. Die möglichen Codierungsarten verschiedener Echtzeitmedien legt RFC 3551 fest (s. Tab. 5.3-1). Timestamp (Zeitstempel), 32 Bits Der Zeitstempel ist vom Payload-Typ abhängig und gibt den Zeitpunkt des Timestamp Beginns des ersten Payload-Oktetts im RTP-Paket an. Auf die Berechnung für Jitterdes Zeitstempels in RTP-Paketen geht Abschnitt 5.3.3 näher ein. Der Zeit- Ausgleich stempel wird benötigt, um beim Empfänger Schwankungen der Übertragungszeit (sog. Jitter) von RTP-Paketen ausgleichen zu können. Bei einer multimedialen Kommunikation werden die einzelnen Medien mit Hilfe des Zeitstempels auch miteinander synchronisiert, sodass man von IntermediaSynchronisation spricht. Sequence Number (Sequenznummer), 16 Bits Jedes RTP-Paket wird mit einer Sequenznummer versehen, die es dem Empfänger erlaubt, den Verlust von Paketen festzustellen bzw. die richtige Reihenfolge der Pakete wiederherzustellen, falls sie in einer falschen Reihenfolge angekommen sind. Der Anfangswert der Sequenznummer wird zufällig ausgewählt, um eine unbefugte Entschlüsselung zu erschweren. Bemerkung: Es gibt mehrere theoretische Verfahren, um mittels Zeitstempel und Sequenznummer die Jitter-Werte (d.h. die Schwankungen der Verzögerungen von RTP-Paketen) abzuschätzen. Die Abschätzung des maximalen Wertes vom Jitter ist nötig, um die Zeitpunkte zu bestimmen, zu denen die RTP-Pakete an eine Anwendung am Ziel übergeben werden sollen – siehe hierfür Abschnitt 5.6.2.
www.wiwobooks.com
SSRC (Synchronization Source Identifier) Alle RTP-Pakete einer Quelle sind Teil des gleichen Raums von Sequenznummern und besitzen das gleiche Prinzip der Vergabe des Zeitstempels (Timing). Beispiele von Quellen sind ein Mikrophon, ein Mixer oder eine Kamera. Der Empfänger gruppiert die ankommenden Pakete zwecks der Wiedergabe nach Quellen. Zur Identifikation der Quelle dient SSRC. Zwei verschiedene Quellen müssen unterschiedliche SSRCs haben, um zu gewährleisten, dass der Empfänger die Bitströme aus verschiedenen Quellen unterscheiden kann (s. Abb. 5.4-3). Die Sequenznummer und der Zeitstempel gelten jeweils für einen Bitstrom mit dem gleichen SSRC-Wert. CSRC (Contributing Source Identifiers) CSRC ist optional und wird verwendet, falls Payload nicht direkt vom „Original“-Sender kommt, sondern von einem Zwischensystem (sog. Mixer) empfangen, verändert und von ihm weitergesendet wurde. CSRC ist eine Liste von „Original“-Quellen der Bitströme, aus denen sich Payload zusammensetzt. CSRC wird von einem Mixer festgelegt (vgl. Abb. 5.4-3). Die weiteren Angaben im RTP-Header: V: Version, 2 Bits Hier wird die verwendete RTP-Version angegeben. Derzeit gilt die im RFC 3550 (Juli 2003) spezifizierte Version 2.
174
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP P: Padding, 1 Bit Falls P = 1 ist, enthält ein RTP-Paket am Ende zusätzliche Füllung (Padding), die nicht zur Nutzlast gehört. Das letzte Padding-Byte gibt an, wie viele Padding-Bytes ignoriert werden müssen. Die Notwendigkeit, einige Padding-Bytes zu übertragen, entsteht, falls ein Verschlüsselungsverfahren eingesetzt wird, das Blöcke einer bestimmten Länge voraussetzt. X: eXtension, 1 Bit Falls X = 1, ist eine Header Extension vorhanden. CC: CSRS Count, 4 Bits Anzahl von im Feld CSRC enthaltenen Quell-Identifikatoren. M: Marker, 1 Bit Die Marker-Bedeutung wird durch die transportierte Nutzlast (Profile) bestimmt. Header Extension Dieses Feld ist optional und von variabler Länge. Mit Hilfe dieses Feldes kann RTP so erweitert werden, dass es sich an eine neue Klasse von Anwendungen anpassen lässt. Die detaillierte Struktur dieses Feldes ist von der übertragenen Nutzlast abhängig.
Größe des RTP/UDP/IP -Headers
Ein IP-Paket mit Audio bzw. Video enthält zunächst einen RTP-Header (mind. 12 Bytes), dann einen UDP-Header (8 Bytes) und innerhalb der Netzwerkschicht noch den IP-Header (mind. 20 Bytes) (s. Abb. 5.3-1). Somit ist der gesamte RTP/UDP/IP-Header mindestens 40 Bytes groß, und deshalb ist oft eine Kompression dieses Headers notwendig (s. Abschnitt 5.8).
www.wiwobooks.com
5.3.2 Statische und dynamische Payload-Typen Echtzeitmedien als Payload
Als Payload (Nutzlast) wird das im RTP-Paket transportierte Segment eines Echtzeitmediums bezeichnet. Bei RTP unterscheidet man zwischen folgenden Arten von Medien: Sprache/Audio, Video und Audio mit Video gemischt (interleaved). RFC 3551, der RFC 1890 abgelöst hat, enthält eine Liste mit festgelegten Nummern zur Angabe der Payload-Typen (PT). Die PT-Nummern dienen zur Identifikation der einzelnen Audio- und Video-Formate. Der Nummernraum in dieser Liste ist nicht komplett belegt, sodass weitere Nummern an neue Audio- bzw. Video-Formate vergeben werden können.
Statische bzw. dynamische PTNummern
Den bereits „klassischen“ und auch standardisierten Audio- bzw. Video-For5 maten sind – durch die Registrierung bei IANA – feste Nummern zugeordnet. Man spricht hier von statischen Payload-Typen. Weiteren bei IANA nicht registrierten Payload-Typen werden – beim Aufbau von Sessions – die Nummern aus dem Bereich 96 bis 127 dynamisch zugeteilt, sodass man von dynamischen PT-Nummern spricht. Diese Payload-Typen sind mit „dyn“ gekennzeichnet. Neben der einfachen Erweiterung vorhandener PT-Nummern bieten dynamische PT-Nummern die Möglichkeit, u.a. nicht allgemein bekannte – und folg-
5
Unter http://www.iana.org/assignments/rtp-parameters findet man die vollständige Auflistung von PT-Nummern der registrierten Medienformate.
175
5.3 Konzept und Funktionen von RTP
lich sogar private – Medienformate zu nutzen. Das Beispiel am Ende dieses Abschnitts soll dies näher erläutern. Eine Auflistung von PT-Nummern einiger Sprachcodierungsverfahren enthält PT-Nummern Tabelle 5.3-1. Wie bereits in Abschnitt 5.1 erläutert wurde, ist eine Sprach- einiger Sprachcodierung entweder Abtastwert- oder Segment-orientiert. formate PT-Nr.
Codierungsname
Codierungsart
0
PCM µ-Law
Abtastwert-orientiert
clock rate (Hz) 8000
Bitrate in kbit/s 64
4
G723
Segment-orientiert
8000
5.3/6.3
8
PCM A-Law
Abtastwert-orientiert
8000
64
12
QCELP
Segment-orientiert
8000
4.7/6.8
15
G728
Segment-orientiert
8000
16
18
G729
Segment-orientiert
8000
8
dyn
G726-32
Abtastwert-orientiert
8000
32
dyn
G726-16
Abtastwert-orientiert
8000
16
Tab. 5.3-1:
Einige Sprachcodierungsverfahren und ihre PT-Nummern LPC: Linear Predictive Coding, PCM: Pulse Code Modulation, QCELP: Qualcomm Code-Excited Linear Prediction
www.wiwobooks.com 6
Bei Audio stellt clock rate – genauer gesagt timestamp clock rate, d.h. die Zeitstempeltaktrate – die Häufigkeit der Abtastung der Amplitude bei der Digitalisierung des Audiosignals dar – also die Abtastrate des analogen Audiosignals. Analoge Sprachsignale werden 8000-mal in der Sekunde abgetastet, was die Abtastrate 8000 ergibt. Bei hochqualitativem Audio – z.B. Musik – und bei Video ist die Zeitstempeltaktrate viel höher, z.B. 90000 bei MPA (MPEG Audio) mit der PT-Nummer 14. Um dynamische PT-Nummern nutzen zu können, müssen sie zwischen den SDP-Einsatz kommunizierenden Rechnern abgestimmt werden, womit die Kompatibilität zwischen ihnen garantiert wird. Wie hierfür das Protokoll SDP (siehe Abschnitt 7.4) verwendet wird, zeigt das folgende Beispiel. Beispiel: Abbildung 5.3-2 illustriert die Abstimmung einer dynamischen PT-Nummer für das Format iLBC (internet Low Bitrate Codec). iLBC hat bei IANA keine feste Identifikation als PT-Nummer. Beim Aufbau einer Session muss ihm daher dynamisch eine PT-Nummer zugewiesen werden. Hierbei kommt SDP zum Einsatz (s. Abb. 7.4-1 und -2), nach dem eine Session beschrieben und damit auch das Sprachformat spezifiziert wird. Hier initiiert Rechner A eine Session zu Rechner B und teilt ihm im Body-Teil der SIPNachricht INVITE (s. Abb. 7.1-9) als SDP-Offer u.a. Folgendes mit:
6
Bei Codierungsverfahren für Audio ist die clock rate – als Abtastrate – viel höher; z.B. bei MPA (MPEG Audio) mit der PT-Nr. = 14 ist die clock rate gleich 90 000 Hz.
Abstimmung dynamischer PT-Nummern
176
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP • •
Dass er über den RTP-Port 50170 Audio (Sprache) senden und empfangen möchte und diesem Medium die PT-Nummer 97 zugeordnet hat. Er spezifiziert dies nach SDP in der m-Zeile als m=audio 50170 RTP/AVP 97. In der a-Zeile (Attribut-Zeile) a=rtpmap 97 iLBC/8000 gibt er an, dass die PTNummer 97 das Format iLBC darstellt und dass die Abtastrate – d.h. clock rate, s. Tab. 5.3-1 – 8000 beträgt. Diese Abtastrate wird während der Session verwendet, um den Zeitstempel für die RTP-Pakete zu berechnen (s. Abb. 5.3.-3).
S D P -O ffe r m = a u d io 5 0 1 7 0 R T P /A V P 9 7 a = rtp m a p : 9 7 iL B C /8 0 0 0
A IN V IT E 5 0 1 7 0 5 0 1 7 1
A
S D P -A n sw e r m = a u d io 4 9 1 7 6 R T P /A V P 9 7 a = rtp m a p : 9 7 iL B C /8 0 0 0
B 1 8 0 R in g in g
P T = 9 7 S e s s io n
R T P R T C P
4 9 1 7 6 4 9 1 7 7
Abb. 5.3-2: Abstimmung einer dynamischen PT-Nummer und Angabe von RTPPortnummern beim Aufbau einer Session A: Audio(Sprach)-Kanal mit RTP, AVP: Audio/Video Profile
Rechner B überprüft nach dem Empfang von INVITE zuerst, ob er das Format iLBC unterstützen kann. Hier ist dies der Fall, sodass er dem Rechner A im Body-Teil der nächsten an ihn gesendeten SIP-Nachricht 180 Ringing als SDP-Answer u.a. Folgendes mitteilt: • Dass er ebenso das Format iLBC unterstützt sowie, dass er Audio mit der PT-Nummer 97 über den RTP-Port 49176 senden und empfangen wird. Dies enthält die m-Zeile
www.wiwobooks.com
•
m=audio 49176 RTP/AVP 97. Mit der a-Zeile a=rtpmap 97 iLBC/8000 bestätigt der Rechner B nochmals, dass iLBC die PT-Nummer 97 hat und dass die Abtastrate 8000 beträgt.
Nach Eintreffen der SDP-Answer bei Rechner A gilt die Abstimmung des Sprachformats iLBC mit der hier dynamisch zugeteilten PT-Nummer 97 als abgeschlossen.
5.3.3 Zeitstempel – Berechnung und Nutzung Nutzung von Zeitstempel
Die Angabe Timestamp – also Zeitstempel – im RTP-Header macht es möglich, dass: ein langer Mediendatenblock – wegen UDP – auf mehrere RTP-Pakete aufgeteilt werden kann (s. Abb. 5.3-4); die Schwankungen der Übertragungszeit (sog. Jitter) von RTP-Paketen beim Empfänger durch den Einsatz eines Jitter-Ausgleichpuffers ausgeglichen werden können. Damit kann die Isochronität garantiert werden (s. Abb. 5.3-5); bei multimedialer Kommunikation die einzelnen Medien miteinander synchronisiert werdne können. Damit lässt sich die Intermedia-Synchronisation garantieren (s. Abb. 5.3-6).
5.3 Konzept und Funktionen von RTP
Berechnung von Zeitstempel für RTP-Pakete Die Berechnung von Zeitstempel soll nun anhand des in Abbildung 5.3-3 gezeigten Beispiels einer Audio-Übermittlung veranschaulicht werden. S
A n a lo g e s S p ra c h s ig n a l A b ta s te n u n d C o d ie re n
... 1
2
n 1 6 0 .
B ild u n g d e r R T P P a k e te
3
4
S n
2 0 m s
...
1 6 0 1
...
2 3
1 6 0 1
2
3
...
T s(n + 1 ) = A + (n + 1 )1 6 0
P 1
S
n + 2
1 6 0 1 2 3
...
n + 3
Z e it
1 6 0
...
Z e it
(n + 3 )1 6 0
(n + 2 )1 6 0
(n + 1 )1 6 0 T s(n ) = A + n .1 6 0
S
n + 1
T s(n + 2 ) = A + (n + 2 )1 6 0
P 2
T s(n + 3 ) = A + (n + 3 )1 6 0
P 3
Z e it P 4
Abb. 5.3-3: Berechnung von Timestamp bei der Bildung von RTP-Paketen mit Sprache Pn: RTP-Paket n, Sn: Audio/Video-Segment n, TS: Timestamp (Zeitstempel)
www.wiwobooks.com
In der Regel werden die Audiosegmente 10, 20 oder 30 ms in einem RTP-Paket übermittelt. Dies betrifft sowohl die Abtastwert- als auch die Segmentorientierte Sprachcodierung. Im hier gezeigten Beispiel ist die Länge des Sprachsegments 20 ms, und die Abtastrate des analogen Sprachsignals – als Zeitstempeltaktrate (clock rate, s. Tab. 5.3-1) – beträgt 8000. Bei der Abtastrate von 8000 [1/s] beträgt der Zeitabstand zwischen zwei benachbarten Abtastwerten 125 µs. Daher wird jedes Sprachsegment mit der Länge von 20 ms durch 160 Abtastwerte repräsentiert, die entsprechend in eine binäre Folge abgebildet (codiert) werden müssen. Mit dem Zeitstempel sollte es beim Empfänger möglich sein, die Stelle in der Zeit der als Payload in RTP-Paketen übermittelten einzelnen Sprachsegmente so zu rekonstruieren, dass diese mit ihrer Stelle in der Zeit beim Absenden übereinstimmen sollte. Daher muss der Zeitstempel nicht die reale Zeit angeben, sondern nur relative Zeitabstände in einer Folge von Sprachsegmenten. Markiert man beispielsweise den Beginn des ersten Sprachsegments mit dem Zeitpunkt 0, könnte man den Zeitpunkt des Beginns des n-ten Sprachsegments als n.160 markieren. Daher könnte man den Wert n.160 schon im ersten Sprachsegment als Timestamp angeben. Um aber mehr Sicherheit der Übermittlung von Echtzeitmedien zu bieten, kam der Vorschlag, den Startwert des Zeitstempels zu verstecken. Daher wird im ersten RTP-Paket eine zufällige Zahl A als Zeitstempel angenommen. Um die zeitliche Position der einzelnen Sprachsegmente zu markieren, berechnet man
177
178
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
den Zeitstempel Ts(n+1)des (n+1)-ten Sprachsegments aus dem Zeitstempel 7 Ts(n)des n-ten Sprachsegments wie folgt: Ts(n+1) = Ts(n) + ΔTs = A + n.160 + 160,
i = 1, 2, …
Wie in Abbildung 5.3-3 gezeigt, ist hierbei das Inkrement ΔTs des Zeitstempels gleich 160 – also gleich der Anzahl der Abtastwerte im Zeitraum 20 ms. Mit dem Zeitstempel in RTP-Paketen werden nur relative Zeitabstände angegeben. Da die realen Zeitabstände durch die Zeitstempeltaktrate (clock rate), die sowohl der Sender- als auch der Empfängerseite bekannt ist – siehe hierzu Tabelle 5.3-1 –, bestimmt werden, können somit auch die realen Zeitabstände zwischen den empfangenen benachbarten RTP-Paketen und insofern auch zwischen Sprachsegmenten abgeleitet werden. Nutzung von Zeitstempel in RTP-Paketen Mediendatenblock in mehreren RTP-Paketen
Die RTP-Pakete werden als Nutzlast in UDP-Paketen transportiert. Die UDPPakete sind aber auf maximal 512 Bytes beschränkt – siehe [BaHo 07]. Deswegen müssen Videosegmente oft auf mehrere RTP-Pakete verteilt werden, damit die UDP-Pakete die Länge von 512 Bytes nicht überschreiten. Der Zeitstempel hat dabei eine wichtige Funktion. Abbildung 5.3-4 illustriert die Aufteilung eines langen Mediendatenblocks auf mehrere RTP-Pakete. Der Zeitstempel vom Original-Mediendatenblock wird hierbei in die einzelnen RTP-Pakete einfach kopiert. Das ist auch selbstverständlich, weil der Zeitstempel den Zeitpunkt des Beginns des langen Original-Mediendatenblocks markiert.
www.wiwobooks.com T s
P a y lo a d - O rig in a l M e d ia d a te n b lo c k F ra g m e n t 1
T s R T P
R T P -P a k e t 1 P a y lo a d P a y lo a d H e a d e r
F ra g m e n t 2
T s R T P
R T P -P a k e t 2 P a y lo a d P a y lo a d H e a d e r
Abb. 5.3-4: RTP- Paket mit einem gemischten Audio- und Video-Bitstrom
Hier wurde zusätzlich zum Ausdruck gebracht, dass nach dem RTP-Header ein zusätzlicher Header – der sog. Payload-Header – vorkommen kann, um einige Angaben zum Payload machen zu können. Darauf wird im RTP-Header mit dem X-Bit verwiesen – siehe hierzu Abbildung 5.3-1. 7
Wäre der Startwert vom Zeitstempel – de facto also der Zeitstempel im ersten RTP-Paket – gleich 0 gewesen, so hätte es der „Angreifer“ einfacher, das Audio bzw. Video aus den unterwegs aufgenommenen RTP-Paketen zurückzugewinnen.
5.3 Konzept und Funktionen von RTP
179
Der Zeitstempel wird verwendet, um am Ziel die Schwankungen der Übertra- Garantie der gungszeit (Jitter) von RTP-Paketen durch den Einsatz eines Jitter-Ausgleich- Isochronität puffers auszugleichen und somit die Isochronität der Kommunikation zu garantieren. Abbildung 5.3-5 illustriert dies. t1
S e n d e n
t3
t2 t1
E m p fa n g e n
t1
t5
t6
t3
t2
A b s p ie le n ti -T im e s ta m p im
t4
t4 t3
t2
t4
t8
t7 t5 t5
t6
t9 t8
t7 t7
t6
t8
k ü n s tlic h e R T P -P a k e te
R T P -P a k e t i
Abb. 5.3-5: Garantie der Isochronität mit Hilfe des Zeitstempels (Timestamp)
Wie hier zu sehen ist, sind die Zeitabstände zwischen den empfangenen Paketen nicht so gleichmäßig wie beim Absenden. Außerdem ist das Paket mit dem Zeitstempel t2 unterwegs verloren gegangen. Das Paket mit dem Zeitstempel t4 wurde zu spät empfangen, sodass es beim Abspielen des Media nicht verwendet werden konnte. Also wurde es am Ziel einfach verworfen.
www.wiwobooks.com
Wie Abbildung 5.3-5 illustriert, werden diese beiden verlorenen Originale – d.h. die Pakete mit dem Zeitstempel t2 und t4 – am Ziel durch künstlich erzeugte Payload-Teile der verlorenen RTP-Pakete ersetzt, um das Medium in Echtzeit abspielen zu können. Außer für die Garantie der Isochronität wird der Zeitstempel während einer Intermediamultimedialen Kommunikation verwendet, um die einzelnen Medien miteinan- Synchronisader zu synchronisieren. Man bezeichnet diese Art der Synchronisation als Inter- tion media-Synchronisation. Abbildung 5.3-6 illustriert sie näher. J itte r P u ffe r
t2 V
V
t2 A
t2
t1 V
t2 t1 A
V
t1 t1
A
J itte r P u ffe r
A u d io b its tro m
S y n c h r o n is a tio n
A
E in tre ffe n d e R T P -P a k e te
tn: T im e s ta m p
A D e c o d
V
t2 t2 t1 t1 V
V
V
t2
A Z G
A u d io
t1 V id e o
V D e c o d
V id e o b its tro m
V Z G
Abb. 5.3-6: Einsatz des Zeitstempels für die Intermedia-Synchronisation A/V-Decod: Audio/Video-Decodierung, A/V-ZG: Audio/Video-Zurückgewinnung
180
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Bei der Synchronisation von Audio und Video spricht man meistens von Lippensynchronisation.
5.4
Translator und Mixer
Um das Format eines Mediums in ein anderes Format umsetzen zu können, spezifiziert RTP die Translator-Funktion. Um mehrere transportierte Bitströme (Medien) zu einem Bitstrom zusammenzuführen (zu mischen), wird die MixerFunktion definiert. Diese beiden Funktionen behandeln wir nun genauer.
5.4.1 Translator-Einsatz Funktion des Translators
Ein Translator ist ein Zwischensystem, das die RTP-Pakete in einem Format empfängt, sie in ein anderes übersetzt und weiterschickt (s. Abb. 5.4-1). Wie hier ersichtlich ist, wird dabei die Identifikation der Quelle, d.h. der Parameter SSRC im RTP-Header, nicht geändert. Die Sendeseite im Translator ist somit eine Vertretung einer Quelle.
www.wiwobooks.com P T = S p ra c h e (C o d ie ru n g s v e rfa h re n A ) Q u e lle
R T P [ ..., S S R C = x ]
P T = S p ra c h e (C o d ie ru n g s v e rfa h re n B ) T ra n s la to r
R T P [ ..., S S R C = x ]
Z ie l
Abb. 5.4-1: Funktion des Translators – Umcodierung von Audio-Daten PT: Payload Type, SSRC: Synchronization SouRCe Identifier
Ein Translator kann eingesetzt werden, um Payload in ein neues Format umzuwandeln, z.B. durch die Umcodierung von Audio-Daten in ein anderes Format. Hierbei ist allerdings nur ein Bitstrom betroffen. Einsatz des Translators
Beispiel: Abbildung 5.4-2 illustriert den Einsatz des Translators in einem VoIP-Server. A m e r ik a , J a p a n
IP -N e tz P C M µ
E u ro p a T ra n s la to r V o IP S e rv e r
Abb. 5.4-2: Beispiel für den Einsatz eines Translators
P C M A
5.4 Translator und Mixer
181
Hier konvertiert der Translator die nach dem Codierungsverfahren PCM A-Law erzeugten Bitströme in die Bitströme des Codierungsverfahrens PCM µ-Law und umgekehrt. Das Verfahren PCM A-Law, d.h. PCM nach der A-Kompandierungskennlinie, wird überwiegend in Europa eingesetzt. In Amerika und in Japan verwendet man das Verfahren PCM µ-Law, d.h. PCM nach der µ-Kompandierungskennlinie (s. Abschnitt 5.1.3).
Der Aufbau von VoIP-Verbindungen zwischen IP-Telefonen – falls sie verschiedene Sprachformate verwenden – kann hierbei über einen speziellen VoIP-Server erfolgen. Er kann feststellen, ob die beteiligten IP-Telefone entweder die gleiche Sprachcodierung unterstützen oder ob die Kommunikation nur durch die Umsetzung des Sprachformats zustande kommen kann. Die Translatoren können eingesetzt werden, um die Vertraulichkeit der Sprach- Garantie der kommunikation über ein öffentliches IP-Netz (z.B. Internet) zwischen zwei VertraulichStandorten eines Unternehmens zu garantieren. Hierfür kann das primäre Sprach- keit format vor der Übertragung an der Grenze zum öffentlichen IP-Netz gezielt in ein sekundäres Sprachformat, das z.B. ein „privates“ Sprachformat ist, umgewandelt werden. Somit ist die über das IP-Netz übertragene Sprache für „Fremde“ unbrauchbar. Am Ziel muss das sekundäre Sprachformat wiederum in das primäre Sprachformat umgewandelt werden.
www.wiwobooks.com
5.4.2 Mixer-Einsatz
In einigen Fällen kann es sinnvoll sein, die Audio/Video-Bitströme von mehre- Aufgabe ren Quellen zu kombinieren und als einen gemischten Audio/Video-Bitstrom eines Mixers weiterzuleiten. Diese Aufgabe übernimmt ein sog. Mixer. Abbildung 5.4-3 veranschaulicht die Mixer-Funktion. Hier werden die ursprünglichen RTP-Pakete vom Mixer nicht weitergeleitet, sondern es wird ein neues RTP-Paket mit dem gemischten Bitstrom erzeugt.
...
S S R C = a Q u e lle 1 Q u e lle n S S R C = x
P T = S p ra c h b its tro m N e tz A
(A ) 1
P T = S p ra c h b its tro m
M ix e r 2
P T = S p ra c h b its tro m 3
S S R C = y
3
N e tz B (B )
R T P [ ..., S S R C = y , C S R C = ( a ,..., x ) ]
1
(A + B ) Z ie l
R T P [ ..., S S R C = a ] 2 R T P [ ..., S S R C = x ]
Abb. 5.4-3: Veranschaulichung der Mixer-Funktion PT: Payload Type, CSRC/ SSRC: Contributing/Synchronization SouRCe Identifiers
Weil der Mixer selbst eine neue Quelle eines gemischten Bitstroms darstellt, trägt er sich selbst als Quelle (Synchronization Source) im RTP-Header jedes RTP-Pakets ein. Um dem Ziel dennoch mitzuteilen, von welchen Quellen die einzelnen ursprünglichen Bitströme stammen, verwendet der Mixer hierfür
182
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
CSRC im RTP-Header (s. Abb. 5.3-1), in dem er eine Liste von Identifikationen (SSRCs) von ursprünglichen Quellen angibt. Damit kann das Ziel erkennen, welche Quellen die einzelnen Bitströme generiert haben. Die Sendeseite im Mixer stellt somit eine Vertretung von auf der CSRC-Liste eingetragenen Quellen dar. Beispiel: Angenommen, es werden zwei Standorte eines Unternehmens über ein IP-Weitverkehrsnetz (IP-WAN) miteinander verbunden. Wie Abbildung 5.4-4 zeigt, wird das VoIPKonzept mit Hilfe einer IP-PBX (Private Branch Exchange) an beiden Standorten realisiert. Jede IP-PBX enthält seitens des IP-WAN die Mixer-Funktion. Dadurch werden mehrere Sprachbitströme zu einem gemischten Bitstrom, der über das IP-WAN übermittelt werden soll, zusammengesetzt. Auf diese Weise können mehrere Sprachverbindungen über das IPWAN über nur einen logischen RTP-Kanal übermittelt werden (vgl. Abb. 5.2-1). Somit fungiert hier der Mixer als Multiplexer logischer RTP-Kanäle. S ta n d o rt A
S ta n d o rt B
...
L A N IP P B X M
R
IP W A N R
L A N IP M P B X
...
Multiplexen logischer RTP-Kanäle
M : M ix e r R : R o u te r
www.wiwobooks.com
Abb. 5.4-4:
Einsatz von Mixern bei VoIP
Ein Mixer kann auch Zeitanpassungen innerhalb der einzelnen Echtzeit-Bitströme vornehmen. Beispielsweise kann er das Mischen von zur gleichen Zeit aufgenommenen Audio-Bitströmen durchführen. Es ist sinnvoll, bei VideoKonferenzen einen Mixer einzusetzen – insbesondere dann, wenn die Teilnehmer so gruppiert sind, dass sich die einzelnen Gruppen an verschiedenen Standorten befinden. MixerEinsatz bei VideoKonferenzen
Beispiel: Man stelle sich das Management-Meeting eines Konzerns vor, bei dem sich zwei Gruppen von Teilnehmern an zwei Standorten aufhalten (s. Abb. 5.4-4). In einer Konferenz mit beispielsweise 6 Teilnehmern an einem Standort, bei der jeder 0,5 Mbit/s an Video erzeugt, muss jeder auch die Videos der anderen Beteiligten am anderen Standort erhalten. Somit muss der Video-Bitstrom von 3 Mbit/s über ein IP-WAN übertragen werden. Wird an jedem Standort ein Mixer eingesetzt, lässt sich die Bitrate vom Video-Bitstrom, den man über das IP-WAN zwischen den Standorten transportieren muss, sehr stark verringern.
5.5
Protokoll RTCP
Zur Überwachung der Übertragungsqualität bei der Audio- und Video-Kommunikation wird das Protokoll RTCP (RTP Control Protocol) verwendet. RTCP dient zur periodischen Übertragung von Kontroll- und Statusinformationen zwischen den beteiligten Endeinrichtungen einer Session. RTCP wurde ursprünglich im RFC 1889, d.h. im gleichen RFC wie RTP, spezifiziert. RFC
5.5 Protokoll RTCP
183
1889 wurde im Juli 2003 durch RFC 3550 ersetzt und ergänzt durch RFC 3611 mit der Spezifikation von RTCP XR (s. Abschnitt 5.5.6) und durch RFC 5506.
5.5.1 Funktion von RTCP RTP wird mit RTCP so ergänzt, dass Informationen über den Verlauf der Kommunikation zwischen Sender und Empfänger, insbesondere über die Qualität der Übertragung, ausgetauscht werden können. Zusätzlich ermöglicht RTCP, die Quellen von Bitströmen eindeutig zu identifizieren. Damit können mehrere Quellen (z.B. Audio- und Video-Quelle) dem Teilnehmer einer Audiound Video-Kommunikation zugeordnet werden. RTCP ermöglicht es, die Informationen über die Teilnehmer (als sog. Metadaten) zu transportieren. Die wichtigsten Aufgaben von RTCP: Überwachung der Übertragungsqualität Sender und Hierfür werden zwischen Sender und Empfänger laufend Informationen Receiver über die Qualität der Übertragung von Echtzeitmedien ausgetauscht. Dies Reports ermöglicht dem Sender beispielsweise, den von ihm generierten Bitstrom an die Netzbedingungen anzupassen (z.B. durch Reduktion der Datenrate bei geringer Qualität der Übertragung) und Fehler einzugrenzen. Für die Realisierung dieser Funktion werden die RTCP-Pakete Sender Reports und Receiver Reports zwischen Sender und Empfänger periodisch ausgetauscht.
www.wiwobooks.com
Identifikation der Quelle Source Hierfür ermöglicht RTCP, eine eindeutige Identifikation der Quelle von Description Echtzeitmedien, d.h. einen sog. kanonischen Namen CNAME (Canonical (SDES) Name), zu übertragen. Im Gegensatz zur Identifikation über SSRC (Synchronization Source) beim RTP, die im Mixer geändert werden kann, bleibt der CNAME immer fest. Für die Realisierung dieser Funktion sendet die Quelle das RTCP-Paket Source Description (SDES). Unterstützung der Mehrpunkt-Kommunikation Diese Funktion eignet sich besonders für die Überwachung von Konferenzen mit mehreren Teilnehmern, die sowohl Sender als auch Empfänger sein können. Dies lässt sich beispielsweise dazu verwenden, die Namen der Teilnehmer einer Konferenz anzuzeigen. Mit RTCP werden hierfür periodisch Statusinformationen ausgetauscht, um die Teilnehmer untereinander über neu hinzukommende und ausscheidende Teilnehmer zu informieren. Z.B. kann die Anzahl der Teilnehmer oder deren Namen angezeigt werden. Dies ist dann nützlich, wenn Teilnehmer ohne vorherige An- oder Abmeldung einer Konferenz beitreten bzw. sie verlassen.
184
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.5.2 Typen der RTCP-Pakete Beim RTCP werden folgende RTCP-Pakete als Nachrichten verwendet: Sender-Report (SR), Receiver Report (RR), Extended Report (XR) Source Description (SDES), Abmeldung (BYE), Applikationsspezifisches Paket (APP). SR-Einsatz
Die wichtigsten RTCP-Pakete sind hierbei SR und RR, weil man diese zur Überwachung der Kommunikationsqualität benötigt. Das RTCP-Paket SR enthält einen Zeitstempel gemäß dem Network Time Protocol (NTP) und beschreibt die Qualität der Übermittlung von Echtzeitmedien aus Sicht eines Senders (s. Abb. 5.5-2). Um beispielsweise die Überlast beim Empfänger zu vermeiden, kann dem Empfänger die Sende-Datenrate mit Hilfe des RTCP-Pakets SR mitgeteilt werden. Damit kann er sich im Voraus auf die ankommende Datenmenge einstellen.
RR-Einsatz
Die Qualität der Kommunikation wird vor allem mit Hilfe von EmpfängerReports überwacht. Ein Empfänger-Report beschreibt die Qualität der Übermittlung von Echtzeitmedien (z.B. geschätzte Paketverlust-, Jitter-Werte) aus Sicht eines Empfängers (s. Abb. 5.5-4).
XR-Einsatz
Das RTCP-Paket XR wurde nachträglich in RFC 3611 spezifiziert, um die Übermittlung verschiedener Parameter und Statistiken für das Monitoring der audiovisuellen Kommunikation zu ermöglichen. Hierzu gehören die sog. VoIPMetriken. Auf XR geht Abschnitt 5.6.6 näher ein.
SDESEinsatz
Die RTCP-Pakete SDES ermöglichen es, die Quellen mit textuellen Namen zu identifizieren. Diese Kennzeichnung der Quelle wird vom Empfänger dazu verwendet, mehrere Bitströme einer Quelle (z.B. Audio und Video), die in getrennten Sessions übertragen werden, wieder zusammenzuführen.
BYE-Einsatz
Das RTCP-Paket BYE dient dazu, das Ende der Teilnahme an einer Kommunikation (z.B. das Verlassen einer Konferenz) anzuzeigen.
www.wiwobooks.com
Weil die RTCP-Pakete SDES, BYE und APP für VoIP keine Funktion haben, werden sie im Weiteren außer Acht gelassen.
5.5.3 Struktur der RTCP-Pakete RTCP-Pakete beginnen immer mit einem Header und werden dann je nach Pakettyp um spezielle Anteile ergänzt. Das Ende eines RTCP-Pakets liegt immer an einer 32-Bit-Grenze. Durch Hinzufügen von Füll-Bytes (sog. Padding) und
5.5 Protokoll RTCP
185
durch die Angabe der Länge im Header können mehrere RTCP-Pakete in einem IP-Paket (sog. Compound Packet) übermittelt werden, ohne dass einzelne RTCP-Pakete explizit von anderen abgetrennt werden müssen. Abbildung 5.5-1 illustriert dies näher. P a k e t
P a k e t IP
U D P H
S R H
S D E C
P a k e t H
B Y E
z u s a m m e n g e s e tz te s R T C P -P a k e t Abb. 5.5-1: Mehrere RTCP-Pakete innerhalb eines IP-Pakets H: Header, SR: Sender-Report, SDES: Source Description
Jedes RTCP-Paket aus einem IP-Paket kann unabhängig von anderen bearbeitet werden. Die Unterscheidung der Pakete wird anhand der Pakettyp-Angabe (Feld PT im Header, s. Abb. 5.5-2 und -4) vorgenommen. Die Reihenfolge der RTCP-Pakete in einem IP-Paket kann im Prinzip beliebig Reihenfolge sein. Empfohlen wird aber folgende Vorgehensweise: Das erste RTCP-Paket der RTCPinnerhalb eines IP-Pakets sollte immer ein Sender oder Receiver Report sein Pakete (unter Umständen gefolgt von einem weiteren Receiver Report, falls ein Paket für die Anzahl der benötigten Berichte nicht ausreicht). Ebenfalls obligatorisch ist ein RCTP-Paket SDES. Andere RTCP-Pakete (z.B. APP) können dann in beliebiger Folge und auch mehrmals angereiht werden. Falls ein RTCP-Paket BYE übertragen wird, sollte es am Ende stehen.
www.wiwobooks.com
5.5.4 Sender-Report (SR) Das RTCP-Paket SR wird periodisch von jedem Sender gesendet, um dem Empfänger die Informationen über die Qualität der Übertragung von Echtzeitmedien mitzuteilen. Abbildung 5.5-2 zeigt die Angaben im SR. Ein RTCPPaket SR enthält: RTCP-Header, der in etwa dem RTP-Header entspricht; Sender-Information, die einen Überblick über die Sendeaktivität des Senders liefert; eventuell mehrere Report Blocks, in denen die Statistiken über die Empfangsqualität von RTP-Paketen einzelner Empfänger übermittelt werden (s. Abb. 5.5-3).
186
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
n V e rs io n n P a d d in g n R e c e p tio n P T = S R n L e n g th : n S S R C : 3
(V ): 2 B (P ): 1 B n re p o r = 2 0 0 : 1 6 B its 2 B its
S R H e a d e r
S R -P a k e t
its it t c o u n t (R C ): 5 B its 8 B its
S e n d e rIn fo rm a tio n n N T n R T n S e n S e
P tim P tim n d e r´ n d e r´
e s e s s p s o
n S S R C _ n : 3 2 B its n F ra c tio n L o s t: 8 B its n C u m u la tiv e n u m b e r o f n E x te n d e t h ig h e s t s e q u e n In te ra rriv a l J itte r: 3 2 B n L a s t S R tim e s ta m p (L S n D e la y s in c e la s t S R (D
R e p o rt B lo c k 1 ta m p : 6 4 ta m p : 3 2 a c k e t c o u c te t c o u n
...
R e p o rt B lo c k n
p a c k e t lo s t: 2 4 B its n c e n u m b e r re c e iv e d : 3 2 B its its R ):3 2 B its L S R ):3 2 B its
...
R e p o rt B lo c k N
B its B its n t: 3 2 B its t: 3 2 B its
E x
P ro file -s p e c ific e x te n s io n s
Abb. 5.5-2: Angaben im RTCP-Paket Sender-Report (SR)
Neben den technischen Informationen wie Version, Padding, Angabe der Länge und Zähler enthält der Header des RTCP-Pakets die eindeutige Identifikation SSRC (Synchronization Source) der Quelle, die diesen Report erzeugt hat.
www.wiwobooks.com
SenderInformations-Block
Hat die Quelle seit dem letzten Absenden eines Sender- bzw. Receiver Reports auch einige RTP-Pakete mit einem Echtzeitbitstrom gesendet, so folgt nach dem Header der Block Sender-Information. Er enthält den Zeitstempel mit der realen Uhrzeit, zu der der Report versandt wurde, und einen äquivalenten Zeitstempel in der von RTP für diesen Echtzeitbitstrom verwendeten Einheit. Außerdem wird die Anzahl der seit Beginn der Kommunikation gesendeten Pakete bzw. Bytes angegeben.
Report Blocks
Nach dem SR-Header können mehrere sog. Report Blocks folgen. Jeder externen Quelle eines Echtzeitmediums, von der dieser Sender seit dem letzten Versand eines Sender-Reports RTP-Pakete empfangen hat, wird ein Report Block zugeordnet. Wie Abbildung 5.5-3 zeigt, ist dies beispielsweise der Fall, wenn der Sender ein Mixer ist. Die Angaben in einem Report Block beziehen sich auf nur eine Quelle. Ein Sender-Report kann bis zu 31 Report Blocks enthalten. Ein Report Block enthält zu jeder (durch ihre SSRC identifizierten) Bitstromquelle den Prozentsatz und die Anzahl der nicht empfangenen RTP-Pakete, die höchste bereits empfangene Sequenznummer, die Varianz des Zeitintervalls zwischen dem Eintreffen von zwei RTP-Paketen, den Zeitstempel des letzten empfangenen Sender-Reports sowie das seitdem verstrichene Zeitintervall. Weitere anwendungsspezifische Felder können in sog. Profile Specifications definiert werden.
5.5 Protokoll RTCP
187
N
S e n d e r-R e p o rt
M ix e r
...
n
...
Q u e lle n 1
R B N
...
R B n
... R B 1
S I
H
Abb. 5.5-3: Sender-Report mit mehreren Report Blocks (RB) H: Header, SI: Sender Informationen
Angaben im SR-Header Die einzelnen Felder im SR-Header haben die folgende Bedeutung: Version (V) (2 Bits) Dieses Feld beinhaltet die Version des Protokolls RTP. Für RTCP nimmt man dieselbe Versionsnummer wie für das RTP. In diesem Fall steht hier also 2. Padding (P) (1 Bit) Wenn dieses Bit auf 1 gesetzt ist, enthält das Paket am Ende zusätzliche Padding (Füll-) Bytes, welche aber nicht zu den Kontrollinformationen gehören.
www.wiwobooks.com
Reception report count (RC), 5 Bits Hier wird die Anzahl der Report Blocks angegeben, die im RTCP-Paket enthalten sind. Packet type (PT), 8 Bits Dieses Feld enthält die Angabe PT = 200 als Identifikation für ein RTCP-Paket SR. Length, 16 Bits Die Länge des RTCP-Pakets in 32-Bit-Worten (inklusive Header und evtl. Padding). SSRC (Synchronization Source), 32 Bits Dieses Feld enthält den Identifikator der Quelle dieses RTCP-Pakets.
Sender-Informationen Der Block Sender-Informationen enthält verschiedene Zeitstempel und Zähler. Die einzelnen Felder haben folgende Bedeutung: NTP timestamp, 64 Bits Hier wird die aktuelle Zeit eingetragen. RTP timestamp, 32 Bits Dieser Zeitstempel korrespondiert mit dem NTP-Eintrag, jedoch in denselben Einheiten, die in den RTP-Paketen benutzt werden. Sender's packet count, 32 Bits Hier wird die Anzahl der bis jetzt gesendeten RTP-Pakete angegeben. Ändert sich die Identifikation SSRC, wird dieser Zähler auf 0 gesetzt.
SenderInformationen in Sender-Reports
188
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP Sender's octet count, 32 Bits Dieses Feld enthält die Anzahl der bis jetzt gesendeten Bytes in RTP-Paketen (ohne Header und Padding). Auch hier wird der Zähler auf 0 gesetzt, wenn sich SSRC ändert.
Angaben in Report Blocks SenderReport von einem Mixer
Die einzelnen Felder im Report Block in Sender-Reports (s. Abb. 5.5-2 und -3) bzw. auch in Receiver Reports (s. Abb. 5.5-4) haben folgende Bedeutung : SSRC-n, 32 Bits Die Identifikation der Datenquelle, die diesem Report Block zuzuordnen ist. Fraction Lost, 8 Bits Dieses Feld enthält die Verlustquote von RTP-Paketen seit dem letzten RTCP-Paket mit SR. Cumulative number of packets lost, 24 Bits Die Zahl aller verlorenen RTP-Pakete seit Beginn der Session. Extended highest sequence number received, 32 Bits Die niederwertigen 16 Bits dieses Feldes enthalten die höchstwertige Sequenznummer aller empfangenen RTP-Pakete der jeweiligen Quelle (der SSRC). Die höherwertigen 16 Bits dieses Feldes enthalten die Anzahl der empfangenen Sequenznummern der Quelle.
Abschätzung von Jitter
Interarrival Jitter, 32 Bits In diesem Feld wird das Ergebnis einer Berechnung eingetragen, die eine Schätzung von Jitter (d.h. eine Aussage über die Zeiträume) zwischen den benachbarten RTP-Paketen darstellt.
Round-Trip Delay
Last SR timestamp (LSR), 32 Bits Der Zeitstempel aus dem letzten empfangenen Sender-Report. Diese Angabe wird verwendet, um die Größe von Round-Trip Delay abzuschätzen (s. Abb. 5.6-3).
www.wiwobooks.com
Delay since last SR(DLSR), 32 Bits Die Verzögerung in 1/65536 Sekunden zwischen dem Empfangen des letzten Sender-Reports und dem Senden des Report Block. Diese Angabe dient zur Abschätzung der Größe von Round-Trip Delay (s. Abb. 5.6-3).
5.5.5 Receiver Report (RR) Wozu RR?
Das RTCP-Paket RR wird ebenso wie das Paket SR periodisch gesendet. Der Empfänger teilt damit dem Sender Informationen über die Qualität der Übertragung von Echtzeitmedien mit. Abbildung 5.5-4 zeigt die Struktur von RR. G le ic h e S tr u k tu r w ie im S R -P a k e t P T = R R = 2 0 1 R e p o rt H e a d e r B lo c k 1
R R -P a k e t
...
R e p o rt B lo c k n
...
R e p o rt B lo c k N
G le ic h e S tr u k tu r w ie im S R -P a k e t
Abb. 5.5-4: RTCP-Paket Receiver Report (RR)
P ro file -s p e c ific e x te n s io n s
5.5 Protokoll RTCP
189
Vergleicht man die Abbildungen 5.5-2 und -4, so ist ersichtlich, dass die Gleicher RTCP-Pakete SR und RR fast die gleiche Struktur haben. Der Unterschied be- Aufbau von steht nur darin, dass SR im Vergleich zu RR Sender-Information enthält. Die SR und RR einzelnen Angaben im Header und im Report Block in SR und RR haben die gleiche Bedeutung. Ein RR kann auch mehrere Report Blocks enthalten.
5.5.6 Einsatz von RTCP XR und VoIP-Metriken Bei der Entwicklung von RTCP – noch vor 1996 – wurden zwar die sog. Re- Notwendigceiver Reports und Sender-Reports für die Übermittlung von Kontroll- und keit von Überwachungsinformationen definiert, es hat sich aber im Laufe der Zeit her- RTCP XR ausgestellt, dass die Überwachung der Qualität audiovisueller Kommunikation über IP-Netze mit Hilfe von RTCP allein nicht ausreichend realisiert werden kann. Deshalb wurde bei der IETF als RFC 3611 eine Ergänzung zum RTCP – das sog. RTCP XR (eXtended Reports) – spezifiziert. RTCP XR ist also eine Erweiterung von RTCP, die dazu dient, verschiedene Was ist Qualitätsparameter zu erfassen und damit den Verlauf audiovisueller Kommu- RTCP XR? nikation zu überwachen. RTCP XR definiert sieben RTCP-Pakete, die sog. Report Blocks (RB), in denen verschiedene Qualitätsparameter für das Monitoring audiovisueller Kommunikation angegeben werden können. In Loss RLE RB können beispielsweise Reports über Paketverluste angegeben werden. Die Reports über Paketduplikate übermittelt Duplicate RLE RB. In Statistic Summary RB sind verschiedene Statistiken enthalten. Um verschiedene Parameter über die VoIP-Qualität – als VoIP-Metriken bezeichnet – zu übermitteln, wurde VoIP Metrics RB eingeführt. In diesem RB ist es u.a. möglich, die Häufungen von Paketverlusten und Paketduplikaten mit Sprache näher zu charakterisieren. Weil die audiovisuelle Kommunikation über IP-Netze – insbesondere über Next Generation (IP-)Networks – immer mehr an Bedeutung gewinnt, ist RTCP XR zukünftig unabdingbar.
www.wiwobooks.com
RTCP XR spezifiziert ein Paket, das sog. XR-Paket (eXtended Report), das als Struktur von Container für verschiedene Report-Blocks angesehen werden kann. Abbildung XR-Paketen 5.5-5 veranschaulicht dies und zeigt die Struktur des XR-Pakets. Das Feld SSRC wird aus dem RTP-Header (s. Abb. 5.3-1) des entsprechenden Pakets mit Echtzeitmedia kopiert und enthält normalerweise eine Identifikation der Quelle, von der das betreffende Media erzeugt bzw. abgeschickt wurde. Jeder Report-Block Blocktyps im Feld (type-specific) schen Angaben der abhängig.
– als Payload im XR-Paket – beginnt mit der Angabe des BT, dann folgen die vom Blocktyp abhängigen Angaben und anschließend die Blocklänge. Welche QoS-spezifiReport-Block übermittelt, ist vom Typ des Report-Blocks
190
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
U D P
IP
X P -P a k e t v o n R T C P 8
0
V P
3 1
1 6
re se rv le n g th P T = X R = 2 0 7 S y n c h ro n iz a tio n S o u rc e Id e n tifie r (S S R C )
R e p o rt B lo c k 0
8
B T
ty p e -s p e c ific
3 1
1 6
Q o S -s p e z ifis c h e A n g a b e n im
b lo c k le n g th R e p o rt B lo c k
Abb. 5.5-5: Struktur des XR-Pakets mit einem Report-Block BT: Block Type, V: Version, P: Padding, PT: Payload Type
Übermittlung von VoIP Metriken
Die Qualität der Sprachkommunikation bei VoIP wird mit Hilfe verschiedener VoIP-Metriken bewertet. Es wurden mehrere Metriken eingeführt u.a., um Häufungen (Bursts) von Paketverlusten (s. Abb. 5.6-4) näher zu spezifizieren und Sprachqualität nach dem sog. E-Modell (s. Abb. 5.6-5) zu beurteilen. Um VoIP-Metriken zu übermitteln, wurde der VoIP Metrics Report Block (VoIPM-RB) eingeführt. Abbildung 5.5-6 zeigt die Struktur des XR-Pakets mit dem VoIP-Metrics-RB.
www.wiwobooks.com 0
B T = 7
8
rs S S d is c a rd lo s s ra te b u rs t d u ra tio n ro u n d trip d e la y n o is e s ig n a l le v e l R fa c to r e x t. R R X c o n fig rsv J B m a x im u m
1 6
v d b lo c k le n g th = 8 R C o f so u rc e ra te b u rs t d e n s ity g a p d e n s ity g a p d u ra tio n e n d s y s te m d e la y le v e l R E R L G m in fa c to r M O S -L Q M O S -C Q J B n o m in a l d JB a b s m a x
3 1
Abb. 5.5-6: Struktur des XR-Pakets mit dem VoIP Metrics Report Block (VoIP-Metrics-RB) Ein VoIP-Metrics-RB kann folgende VoIP-Metriken enthalten: loss rate – mittlere Paketverlustrate discard rate – mittlere Rate, mit der die eintreffenden Pakete am Ziel verworfen werden
Angaben über die Häufung der Paketverluste: burst density, gap density, burst duration und gap duration. Das sind statistische Parameter, mit denen sich eine Folge von Paketen mit Gaps und Bursts charakterisieren lässt – s. Abb. 5.6-4. Verzögerungsangaben: round trip delay (RTD) und end system delay (ESD). Die Abschätzung von RTD – auch als Round Trip Time (RTT) bezeichnet – s. Abb. 5.6-3. Mit ESD wird die Verzögerung in den beiden Endsystemen – als Folge der Codierung, Verzögerung im Jitter-Puffer etc. – angegeben.
5.6 Abschätzung von QoS-Parametern
191
Signalbezogene Metriken: signal level, noise level und residual echo return loss (RERL). Diese Metriken können für die Berechnung einiger Minderungsfaktoren in der Formel für den R-Faktor verwendet werden – s. Abb. 5.6-5. Angaben über die Übertragungsqualität: R factor (s. Abb. 5.6-5), ext.(external) R factor (Faktor aus einem Nicht-IP-Netz, z.B. aus einem Mobilfunknetz), MOS-LQ (Mean Opinion Score for Listening Quality) und MOS-CQ (Conversational Quality). Konfigurationsparameter: Gmin (s. Abb. 5.6-4) und RX config (receiver configuration byte). Das Feld RX config enthält folgende Parameter: − PLC (Packet Loss Concealment) – 2 Bits: Hier kann das Prinzip eingetragen werden, nach dem die verlorenen Pakete verborgen werden – was gemacht wird, wenn ein Paket fehlt und es ersetzt werden muss (s. Abb. 5.3-5). − JBA (Jitter Buffer Adaptive) – 2 Bits: Hier gibt man an, ob die Länge des Jitter-Puffers an die aktuellen Gegebenheiten angepasst werden kann – d.h., ob der Jitter-Puffer anpassungsfähig (adaptiv) ist. − JB Rate (Jitter Buffer rate) – 4 Bits: Hier wird näher spezifiziert, wie die Adaption des Jitter-Puffers erfolgt. JP-Parameter (Jitter Buffer): JB nominal (JB nominal delay), JB maximum (JB maximum delay) und JB abs max (JB absolute maximum delay). Es handelt sich hier um die Beschreibung der Verteilung von Jitter-Werten.
www.wiwobooks.com
Der VoIP-Metrics-RB stellt die Grundlage für eine kontinuierliche Bewertung der Sprachkommunikation in IP-Netzen dar. Diese Möglichkeit ist in NGNs von großer Bedeutung und stellt die Voraussetzung für eine qualitätsabhängige Berechnung der Entgelte für die Sprachkommunikation in NGNs.
5.6
Abschätzung von QoS-Parametern
Die Audio- und Videokommunikation stellt im Vergleich zur Datenkommuni- QoS- Anforkation völlig neue Ansprüche an IP-Netze, die man als QoS-Anforderungen derungen (Quality of Service) bezeichnet. Sie betreffen vor allem die Übermittlungszeit und die Schwankungen der Übermittlungszeit (sog. Jitter) sowie die Verfälschung und Verluste von RTP-Paketen während der Übermittlung. Die Audio- und Videokommunikation bezeichnet man als isochrone Kommuni- Bedeutung kation. Die Isochronität bezieht sich hierbei darauf, dass die Zeitverhältnisse der im Bitstrom an der Sende- und Empfangsseite identisch sein müssen. Bei der Isochronität Sprachkommunikation über IP-Netze müssen somit die Zeitabstände zwischen den aufeinanderfolgenden IP-Paketen aus einem Bitstrom auf Sende- und Empfangsseite identisch sein.
192
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.6.1 Garantie der Isochronität Verlust der Isochronität durch Jitter
Die Isochronität bei der Audio- und Videokommunikation über ein IP-Netz geht dadurch verloren, dass die einzelnen IP-Pakete über verschiedene Wege über das IP-Netz zwischen Sender und Empfänger übertragen werden. Als Folge dessen schwanken ihre Übertragungszeiten. Die Schwankungen der Übertragungszeit der einzelnen Pakete aus einem Bitstrom nennt man üblicherweise Jitter. Um die Isochronität der Audio/Sprach- und Videokommunikation zu garantieren, muss Jitter im Empfänger entsprechend ausgeglichen werden. Hierfür verwendet man in der Regel einen speziellen Puffer, den man als JitterAusgleichpuffer bzw. als Playout Buffer bezeichnet.
JitterAusgleich
Abbildung 5.6-1 veranschaulicht, wie sich die Isochronität mit Hilfe eines Jitter-Ausgleichpuffers im Empfänger erreichen lässt. Man sieht hier, dass der Sender die RTP-Pakete in einer konstanten Größe in regelmäßigen Zeitabständen absendet. Die einzelnen IP-Pakete mit den RTP-Paketen werden während der Übermittlung über das IP-Netz über verschiedene Routen transportiert, sodass ihre Übermittlungszeiten ebenfalls unterschiedlich sind. Die Ankunftszeitpunkte der IP-Pakete beim Empfänger sind deswegen unregelmäßig.
www.wiwobooks.com
P a y lo a d -G rö ß e in R T P -P a k e te n
A n z a h l v o n B its
T T
T
3
2 1
Z e it A b se n d e z e itp u n k te
S e n d e r
A n k u n fts z e itp u n k te v o r d e m J itte r -A u s g le ic h
IP -N e tz
T n: Ü b e rm ittlu n g s z e it d e s n -te n IP -P a k e ts
Ü b e rg a b e z e itp u n k te n a c h d e m J itte r -A u s g le ic h
JA P E m p fä n g e r
Abb. 5.6-1: Garantie der Isochronität mit Hilfe eines Jitter-Ausgleichpuffers (JAP) im Empfänger
Bedeutung des JitterAusgleichpuffers
Die einzelnen RTP-Pakete müssen aber in regelmäßigen Zeitabständen an eine Applikation übergeben werden. Um dies zu erreichen, müssen die RTP-Pakete für die Dauer des maximalen Jitter-Wertes, mit dem man rechnen kann, im Jitter-Ausgleichpuffer zwischengespeichert werden. So kann man sicher sein,
5.6 Abschätzung von QoS-Parametern
193
dass jedes RTP-Paket bereits empfangen wurde, falls es an die Applikation übergeben werden muss. Bemerkung: Abbildung 5.6-1 illustriert das Isochronitätsproblem bei der Übermittlung einer Folge von RTP-Paketen mit konstanter Länge. So konnte man hier Jitter deutlicher zum Ausdruck bringen. Sollte eine Folge von RTP-Paketen mit variabler Länge übermittelt werden, so werden die Zeitpunkte der Übergabe von RTP-Paketen an eine Applikation auf Basis des in ihnen enthaltenen Zeitstempels (d.h. des Absendezeitpunktes) bestimmt.
Um die Isochronität der Audio- und Videokommunikation zu garantieren, stellt RTCP die hierfür notwendigen Funktionen zur Verfügung. Insbesondere ist es mit RTCP-Hilfe möglich, sowohl die Jitter-Werte als auch die Übermittlungszeiten von RTP-Paketen über ein IP-Netz abzuschätzen.
5.6.2 Abschätzung von Jitter Mit Hilfe der in den RTCP-Paketen SR und RR übertragenen Angaben lassen sich Schwankungen der Übermittlungszeit über ein IP-Netz, die als Jitter bezeichnet werden, abschätzen. Abbildung 5.6-2 illustriert die Idee, die der Abschätzung von Jitter zugrunde liegende Idee.
www.wiwobooks.com S
S e n d e r
S i
Z e it j
IP N e tz R
E m p fä n g e r D i
= R i
- S
R i
i
D j
= R j
- S j
j
Z e it
Abb. 5.6-2: Annahmen zur Abschätzung von Jitter Für die Jitter-Abschätzung geht man von folgenden Annahmen aus: Si = Zeitstempel des i-ten RTP-Pakets, d.h. der Zeitpunkt, zu dem das RTP-Paket vom Sender abgeschickt wurde. Ri = Zeitpunkt, zu dem der Empfänger das i-te RTP-Paket empfing. Die Verzögerung des i-ten RTP-Pakets im IP-Netz beträgt: Di = Ri– Si Mit J(j, i) bezeichnet man den Unterschied zwischen der Übermittlungszeit des i-ten RTP-Pakets und der Übermittlungszeit des j-ten RTP-Pakets. Es gilt: J(j, i) = Dj – Di = (Rj – Sj) – (Ri – Si) = (Rj – Ri) – (Sj – Si) Die Jitter-Werte lassen sich nach dem Empfangen einzelner RTP-Pakete rekursiv wie folgt errechnen:
Schritte bei der JitterAbschätzung
194
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
J1 = 0, J2 = J(2, 1), Ji = Ji-1 + (|J(i, i-1)| – Ji-1)/16, i = 3, 4, ... Der Wert Ji stellt die Abschätzung von Jitter nach dem Empfang des i-ten RTP-Pakets dar.
Größe des JitterAusgleichpuffers
Die Abschätzung von Jitter wird dem Kommunikationspartner in den RTCPPaketen SR und RR übermittelt (vgl. Abb. 5.5-2 und 5.5-4). Der Jitter-Wert ist eine der wichtigsten Informationen bei der Überwachung der isochronen Kommunikation über IP-Netze. Wie bereits erwähnt wurde (s. Abb. 5.6-1), verwendet man die Abschätzung von Jitter dazu, um die Größe des JitterAusgleichpuffers im Empfänger zu bestimmen. Wie Abb. 5.6-1 zeigt, wird der Jitter-Ausgleichpuffer eingesetzt, um die Segmente mit Echtzeit-Medien (Audio/Sprache, Video) zu den richtigen Zeitpunkten an eine Applikation übergeben zu können.
5.6.3 Abschätzung des Round-Trip Time Was ist Round-Trip Delay?
Die in den RTCP-Paketen SR und RR übertragenen Angaben ermöglichen, die 8 Größe der Round-Trip Time (d.h. Hin-und-Zurück-Zeit) – kurz RTT – der RTP-Pakete während der Übermittlung über ein IP-Netz abzuschätzen. Abbildung 5.6-3 illustriert die hierfür benötigten Annahmen.
www.wiwobooks.com R R [ ..., L S R , D L S R ]
S e n d e r
A
T S IP N e tz
S R
Z e it R R Z e it
E m p fä n g e r D S R
D L S R
D R R
Abb. 5.6-3: Annahmen zur Abschätzung von Round-Trip Time (RTT) DRR: Delay von RR, DSR: Delay von SR, TS: Zeitstempel (Timestamp) in SR
Der Wert von RTT lässt sich wie folgt errechnen: RTT = DSR + DRR = A – LSR – DLSR Hierbei bedeutet: A: Zeit, zu der das RTCP-Paket RR empfangen wurde. LSR: Last SR in RR. Zeitstempel aus dem letzten empfangenen Paket SR; Zeitpunkt, zu dem das Paket SR abgeschickt wurde. DLSR: Delay since Last SR in RR; Zeitabstand zwischen dem Empfangen des letzten Pakets SR und dem Absenden des Pakets RR.
8
Man bezeichnet diese Zeit auch als Round-Trip Delay (RTD).
5.6 Abschätzung von QoS-Parametern
195
Die Hälfte von RTT kann als ein Maß für die Übermittlungszeit in einer Richtung über das IPNetz angenommen werden.
Bei der Lieferung von Audio/Video nach dem Multicasting-Prinzip – bei- Multicasting spielsweise bei der Realisierung von IP-Radio bzw. IPTV – entsteht oft eine und RTT Baumnetztopologie, in der mehrere und unterschiedlich lange Wege von der Primärquelle von Audio/Video über mehrere Sekundärquellen zu einem Empfänger entstehen. Abbildung 5.6-4a illustriert dies näher.
a )
S e k u n d ä rq u e lle n P rim ä rq u e lle
b ) S S R C =
Z ie le i
x y
R T T u
R T C P X R
Z ie l y
u y
R T C P y
v
R T T
S e k u n d ä rq u e lle S S C R = j
x
j u
x S S R C = a
P rim ä rq u e lle S S C R = a
S S R C = j
k
c )
L R R
R T T = A - L R R - D L R R
S e k u n d ä rq u e lle R R T -R B [L R R ] Z ie l
Z e it
A
D L R R -R B [ L R R , D L R R ]
D L R R
www.wiwobooks.com
Z e it
Abb. 5.6-4: Abschätzung von RTT bei der Lieferung von Audio/Video: a) Baumnetztopologie, b) RTCP versus RTCP XR, c) Abschätzung nach RTCP XR In der hier gezeigten Situation führen zu einigen Empfängern mehrere unterschiedlich lange Wege. RTCP XR (s. Abschnitt 5.5.6) stellt die Report-Blocks zur Verfügung, um die Länge dieser Wege – ausgedrückt in der Laufzeit der Pakete – abschätzen zu können. RTCP XR ermöglicht daher, die RTT abzuschätzen. Abbildung 5.6-4b bringt zum Ausdruck, dass die Abschätzung: von RTTxy zwischen einer Primärquelle x und dem Ziel y mit Hilfe eines Sender Report und eines Receiver Report von RTCP – wie in Abbildung 5.6-3 – gemacht werden kann. von RTTuy zwischen einer Sekundärquelle u und dem Ziel y mit Hilfe von RTCP XR erfolgen kann. Abbildung 5.6-4c illustriert die Abschätzung von RTTuy beim Einsatz von RTCP XR. RTTuy kann bei der Sekundärquelle u wie folgt berechnet werden: RTTuy = A – LRR – DLRR Hier bedeutet: LRR: Die Angabe Last RR im DLRR-RB (Delay since Last Receiver Report – Report Block, BT=5 in Abb. 5.5-5). Das ist Timestamp aus dem im Ziel empfangenen RRT-RB (Receiver Reference Time – Report Block, BT=4). LRR wird an die Sekundärquelle u in DLRR-RB übergeben. DLRR: Die Angabe Delay since Last RR im DLRR-RB. A: Zeitpunkt, zu dem DLRR-RB bei der Sekundärquelle u empfangen wurde.
196
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.6.4 Aussage über die Häufung von Paketverlusten Bei der Übermittlung der Sprache über IP-Netze können sich in bestimmten Situationen die Paketverluste häufen. Daher muss definiert werden, wie eine präzise Aussage über die Häufung von Paketverlusten möglich ist. Wie Abbildung 5.6-5 zeigt, kann eine Folge von Paketen in einer Zeitsequenz als Folge von Gaps (Lücken) und Bursts (Häufungen) dargestellt werden.
G a p
B u rst
G a p L ä n g e
B u rs tL ä n g e
G a p
B u rst
G a p
Z e it G m in = 4 1 1 1 1 0 1 1 1 1 0 1 1 1 1 0 1 1 1 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 1 1 0 1 1 1 1 1 1 1
G a p 1
B u rst 1
G a p 2
B u rst 2
G a p 3
1 : k o rre k t e m p fa n g e n e s P a k e t 0 : v e rlo re n e s b z w . v e rw o rfe n e s P a k e t Abb. 5.6-5: Folge von Paketen als Folge von Gaps und Bursts
www.wiwobooks.com
Als Gap – d.h. als Lücke zwischen zwei aufeinanderfolgenden Häufungen von Paketverlusten – wird eine Paketfolge bezeichnet, in der Paketverluste selten vorkommen. Dagegen stellt ein Burst eine Paketfolge dar, in der die Paketverluste oft vorkommen. Mit den Worten „selten“ und „oft“ werden aber Gap und Burst nicht präzise genug definiert. Um diese Begriffe präziser zu beschreiben, wurde der Parameter Gmin eingeführt. Mit Hilfe von Gmin werden Gap und Burst wie folgt definiert. Begriff Gap
Ein Gap stellt eine Zeitperiode dar, in der zwei aufeinanderfolgende verloren gegangene bzw. verworfene Pakete mit einer Folge von mindestens Gmin korrekt empfangenen Paketen voneinander getrennt sind. Abbildung 5.6-5 illustriert, dass die Paketverluste – als 0-Stellen markiert – z.B. im Gap 1 auch vorkommen. Da Gmin = 4 gilt, sind die Paketverluste hier um mehr als 4 Pakete voneinander getrennt.
Begriff Burst
Ein Burst stellt eine Zeitperiode – d.h. eine Häufungsperiode – dar, die sowohl mit einem Paketverlust beginnt als auch endet und in der die zwei aufeinanderfolgenden verloren gegangenen bzw. verworfenen Pakete mit einer Folge von weniger als Gmin korrekt empfangenen Paketen voneinander getrennt sind. Abbildung 5.6-5 zeigt, dass die Paketverluste im Burst 1 – bei Gmin = 4 – voneinander um weniger als 4 Pakete voneinander getrennt sind.
Gmin = 16 bei VoIP
Aus diesen Definitionen geht hervor, dass Gmin als Kriterium angesehen werden kann, um zu entscheiden, ob es sich um Gap oder um Burst handelt. Es wurde vorgeschlagen, bei VoIP Gmin = 16 anzunehmen. Bei der Übermittlung
5.6 Abschätzung von QoS-Parametern
197
von Video über IP-Netze – also bei IPTV – sollte man den Wert 64 bzw. sogar 128 als Gmin annehmen. Für die Beschreibung einer Folge von Paketen mit Gaps und Bursts definiert Statistische Parameter man folgende statistische Parameter: Gap-Dauer (Gap Duration) – mittlere Dauer [ms] von Gaps Gap-Dichte (Gap Density)– mittlere Paketverlustrate [%] in Gaps Burst-Dauer (Burst-Duration) – mittlere Dauer [ms] von entdeckten Burts Burst-Dichte (Burst Density) – mittlere Paketverlustrate [%] in entdeckten Burts Das in Abbildung 5.6-5 dargestellte Modell kann auch für die Beschreibung der Häufung von Paketduplikaten verwendet werden.
5.6.5 E-Modell von der ITU-T Wie bereits in Abbildung 5.5-6 zeigt wurde, gibt es verschiedene Faktoren, die Ziel von die Qualität der Sprachkommunikation bei VoIP bestimmen und als VoIP- E-Modell Metriken bezeichnet werden. Mit Hilfe von VoIP-Metriken lässt sich die Qualität der Sprachkommunikation über ein IP-Netz automatisch abschätzen. Hierfür wurde von der ITU-T das sog. E-Modell spezifiziert. Nach diesem Modell – siehe den Standard G.107 bzw. die ETSI-Dokumente TS 101 329-5 V.1.1.2 und TS 102 024-5 V.4.1.1 – wird der sog. Faktor R ermittelt, der die Qualität der Sprachkommunikation bestimmt und auch auf MOS-Werte (s. Tab. 5.1-2) abgebildet werden kann (s. Abb. 5.6-7).
www.wiwobooks.com
Im E-Modell werden alle Störfaktoren aufgelistet, die den Wert des Faktors R Inhalt von negativ beeinflussen. In Anlehnung an das E-Modell illustriert Abbildung 5.6-6 E-Modell diese Störfaktoren.
S e n d e rs e ite
R = R
R -F a k to r
0
- I
S
- I
d
- I
e -e ff
D s -F a k to r
D r -F a k to r
IP -N e tz
P s q d u E S D
N
C
P lp
E m p fä n g e rs e ite
+ A
G W
P lp
R T T
P S T N /IS D N R E R L
N
P R
C
P S, P R : H in te rg ru n d g e rä u s c h e (ro o m n o is e ), N C : S c h a ltu n g s g e rä u s c h e (c irc u it n o is e ) q d u : Q u a n tis ie ru n g s s tö ru n g (Q u a n tiz a tio n D is to rtio n U n its ), P lp : P a c k e t lo s s p ro b a b ility R E R L : R e s id u a l E c h o R e tu rn L o s s , E S D : E n d S y s te m D e la y
Abb. 5.6-6: Wichtige Störfaktoren bei VoIP nach dem E-Modell
198
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Einige Störfaktoren aus dem E-Modell werden in VoIP Metrics Report Blocks von RTCP XR übermittelt – siehe Abbildung 5.5-6. Faktor R
Der Faktor R nach G.107 wird wie folgt berechnet: R = R0 – IS – ID – Ie-eff + A Die einzelnen Komponenten im Faktor R haben folgende Bedeutung: R0 repräsentiert das Signal-zu-Rausch-Verhältnis (signal-to-noise ratio) und ist u.a. von den Störfaktoren NC, PR und Ps abhängig. IS stellt den Minderungsfaktor (simultaneous impairment factor) dar, mit dem parallel bei der Sprachkommunikation verlaufende Störereignisse berücksichtigt werden. IS ist u.a. vom Störfaktor qdu abhängig. ID repräsentiert den Minderungsfaktor in Folge der Verzögerung (delay impairment factor). ID ist vom RTT abhängig. Ie-eff stellt den Minderungsfaktor durch Einrichtungen (effective equipment impairment factor) dar. Ie-eff wird u.a. durch die Paketverlustrate Plp beeinflusst. A ist ein Gewinnfaktor durch VoIP. Der A-Wert ist vom Netztyp abhängig. In G.107 werden die A-Werte für verschiedene Netztypen definiert – z.B. wird in terrestrischen Netzen A=0 angenommen, in Mobilfunknetzen kann A=10 sein.
Faktor R und Sprachqualität
Abbildung 5.6-7 zeigt, wie die Werte des Faktors R die Qualität der Sprachkommunikation bei VoIP bestimmen.
www.wiwobooks.com M O S -W e rt
E x e lle n t 5 G o o d F a ir
4 3
P o o r B a d 1
2 0
R -F a k to r 2 0
4 0
6 0
8 0
1 0 0
Abb. 5.6-7: Sprachqualität bei VoIP in Abhängigkeit vom R-Faktor – s. Abschnitt 5.1.7
Auf Basis dieses Faktors können die Gebühren bei VoIP unter Berücksichtigung der Dienstqualität berechnet werden. In Next Generation Networks sollen die Gebühren für die VoIP-Dienste u.a. qualitätsorientiert sein, um Anreize zu Investitionen in diese Netze zu fördern. Der R-Faktor stellt daher die Voraussetzung für die Einführung derartiger Gebühren dar.
5.7
Secure Real-time Transport Protocol (SRTP)
Auf VoIP-Systeme können verschiedene „Angriffe“ vorgenommen werden. Beispielsweise können einige Gespräche abgehört bzw. einige Systemkompo-
5.7 Secure Real-time Transport Protocol (SRTP)
199
nenten lahmgelegt werden. Um die Sicherheitsrisiken bei der Nutzung des Protokolls RTP zu verhindern, wurde ein Konzept entwickelt, das eine Erweiterung von RTP darstellt und als SRTP (Secure Real-time Transport Protocol) bezeichnet wird. SRTP wurde in RFC 3711 spezifiziert. Beim Einsatz von SRTP können die über IP-Netze transportierten Echtzeitmedien verschlüsselt werden. Es besteht auch die Möglichkeit, zu überprüfen, ob die empfangenen RTP-Pakete vom wahren Absender stammen. SRTP setzt ein sog. Key Management Protocol voraus, mit dessen Hilfe die kommunizierenden Endeinrichtungen die einzusetzenden Sicherheitsverfahren und bestimmte Parameter untereinander aushandeln und sich gegenseitig in die Lage versetzen, dass jede Endeinrichtung einen gemeinsamen und geheimen Schlüssel, den sog. Master Key, selbst generieren kann. Der Master Key dient nur als „Schlüsselmaterial“. Jede Endeinrichtung generiert später mit Hilfe des Master Key die weiteren Schlüssel, sog. Session Keys, die man zur Verschlüsselung und Authentifizierung übertragener RTP- und RTCP-Pakete verwendet. Dem SRTP liegt AES (Advanced Encryption Standard) zugrunde.
Key Management Protocol: Wozu?
5.7.1 Sicherheitsfunktionen von SRTP
www.wiwobooks.com
SRTP bietet bestimmte Sicherheitsfunktionen, um RTP-Pakete vertraulich zu Sicherheitsübertragen und unterschiedliche „Angriffe“ auf sie zu unterbinden. Mit SRTP funktionen lassen sich folgende Sicherheitsfunktionen realisieren: Vertraulichkeit durch die Verschlüsselung Mit SRTP erreicht man die Vertraulichkeit während der Sprachübertragung, indem der Inhalt der RTP-Pakete vor der Übertragung verschlüsselt wird. Damit kann die Sprache unterwegs von einem Unbefugten nicht „abgehört“ werden. Authentifizierung des Absenders Die Identität des Absenders bei der Kommunikation über IP-Netze lässt sich natürlich anhand der Quell-IP-Adresse in IP-Paketen prüfen. Die Quell-IPAdresse kann aber leicht durch einen Unbefugten unterwegs vorgetäuscht werden. Bei dieser Fälschungsart spricht man von Identitäts-Spoofing. Mit SRTP ist es möglich festzustellen, ob die RTP-Pakete vom wahren Absender stammen. Überprüfung der Integrität Nachdem ein RTP-Paket von einem Unbefugten empfangen wurde, kann er dieses Paket in einer veränderten Form an das Ziel weiterleiten. Damit können die RTP-Pakete ohne Wissen des Absenders und des Empfängers unterwegs gezielt verändert werden. Mit SRTP ist es möglich, die RTP-Pakete vor unberechtigten Änderungen während der Übertragung zu schützen. Da-
200
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
durch wird sichergestellt, dass die empfangenen RTP-Pakete exakt mit den gesendeten übereinstimmen. Anti-Replay-Schutz (Replay-Verhinderung) Die von einem Unbefugten unterwegs gelesenen RTP-Pakete können unterschiedlich missbraucht werden. Man kann sie beispielsweise verwenden, um eine neue Session einzurichten und illegal auf die Informationen in einer Ziel-Endeinrichtung zuzugreifen. Mit dem Anti-Replay-Schutz lässt sich verhindern, dass man mit Hilfe der aus einem RTP-Paket unterwegs illegal abgelesenen Angaben auf die Informationen in einer Ziel-Endeinrichtung zugreifen kann. Sicherheit bei RTCP
Die Sprachübermittlung nach RTP wird mit Hilfe des Protokolls RTCP überwacht. Die RTCP-Pakete werden auf die gleiche Weise wie RTP-Pakete gesichert.
5.7.2 Key-Management-Protokoll und SRTP Key ManagementProtokoll (KMP): Wozu?
Um SRTP einzusetzen, müssen die kommunizierenden Endeinrichtungen zuerst einige Informationen untereinander austauschen, sowohl um gemeinsame und sicherheitsrelevante Parameter festzulegen, als auch um sich gegenseitig in die Lage zu versetzen, dass jede Endeinrichtung für sich selbst notwendige und geheime Schlüssel generieren kann. Dafür ist ein spezielles Key-ManagementProtokoll (KMP) nötig.
MIKEY als KMP
Ein Beispiel für ein KMP ist IKE (Internet Key Exchange), das man beim Sicherheitsprotokoll IPsec verwendet (s. [BaHo 07]). IKE erfüllt jedoch nicht die besonderen Anforderungen der Echtzeit-Kommunikation. Daher wurde bei der IETF bereits ein neues KMP namens MIKEY (Multimedia Internet KEYing) als RFC 3830 spezifiziert, das speziell für das Schlüsselmanagement bei der Multimedia-Kommunikation über IP-Netze konzipiert wurde. MIKEY dient 9 beim SRTP-Einsatz als KMP. Näheres über MIKEY findet man auf
www.wiwobooks.com
http://www.ietf.org/dyn/wg/charter/msec-charter.html Bedeutung des kryptografischen Kontexts
Kommunizierende Endeinrichtungen verwenden KMP, um einige Parameter für den SRTP-Einsatz zu vereinbaren und bestimmtes „Schlüsselmaterial“ untereinander auszutauschen. Damit erreicht man einen Zustand, in dem jede Endeinrichtung notwendige und geheime Schlüssel für sich selbstständig generieren kann. Ein geheimer Schlüssel darf nie übertragen werden. Die vereinbarten Parameter und generierten Schlüssel für eine Session stellen den sog. kryptografischen Kontext dar, der in jeder Endeinrichtung für die Dauer der Session
9
Internet Draft draft-zimmermann-avt-zrtp spezifiziert ein anderes KMP – als ZRTP bezeichnet (Z: Zimmermann) – für den Einsatz bei SRTP.
5.7 Secure Real-time Transport Protocol (SRTP)
201
abgespeichert und entsprechend mit einer Identifikation der Session verknüpft werden muss. Um beim MIKEY-Einsatz den kryptografischen Kontext für eine Session in Master Key zwei kommunizierenden Endeinrichtungen erzeugen zu können, müssen nur als Schlüszwei Nachrichten gesendet werden. Hierbei fungiert eine Endeinrichtung als selmaterial Initiator der „kryptografischen Verhandlungen“ und die andere als Responder. Abbildung 5.7-1 zeigt den MIKEY-Verlauf zwischen zwei IP-Telefonen im sog. Diffie-Hellman-Modus.
IP -T e l A In itia to r 1 1
IP -T e l B
IP -N e tz G R P = (g , p )
R e sp o n d e r
I_ m sg
R _ m sg
3 In itia to r w b e re c h n e t a n R e sp o n I_ m s g := H
2 3
2
ä h lt e in e z u fä llig e Z a h l x , Z A = g x m o d p u n d se n d e t d e r d r , T , { S P } , g x,..., S ig n ( I _ m s g )
R e s p o n d e r w ä h lt e in e z u fä llig e Z a h l y , b e re c h n e t Z B = g y m o d p u n d se n d e t a n In itia to r R _ m s g := H d r , T , g y, ..., S ig n ( I _ m s g )
www.wiwobooks.com
x y x 3 In itia to r b e re c h n e t: S A = (Z B ) m o d p = g m o d p R e s p o n d e r b e re c h n e t: S B = (Z A )y m o d p = g yx m o d p
S A
=
S B
= S
I_ m g s : In itia to r_ m e s s a g e , R _ m g s : R e s p o n d e r_ m e s s a g e , G R P : D iffie -H e llm a n -G ru p p e , H d r: H e a d e r d e r N a c h ric h t, T : T im e s ta m p , S ig n : S ig n a tu r, S P : S e c u rity P o lic ie s
Abb. 5.7-1: MIKEY-Verlauf im sog. Diffie-Hellman-Modus
Hier soll gezeigt werden, welches „Schlüsselmaterial“ ausgetauscht wird und wie die beiden IP-Telefone sich jeweils den gleichen und geheimen Schlüssel erzeugen können. Bei SRTP dient dieser Schlüssel nur als „Schlüsselmaterial“ und wird als Master Key bezeichnet. Die beiden IP-Telefone „müssen nur wissen“, welche Diffie-Hellman-Gruppe (kurz DH-Gruppe) benutzt wird. Mit der DH-Gruppe legt man eine große Primzahl p (z.B. mit einer Länge von 1024 Bits) und einen Generator g fest. Jedes Sicherheitsprotokoll nutzt eine bestimmte DH-Gruppe. Initiator und Responder kennen somit die Parameter g und p der DH-Gruppe. Bemerkung: Primzahlen sind Zahlen, die nur durch 1 und durch sich selbst ohne Rest dividierbar sind. Primzahlen sind z.B. 2, 3, 5, 7, 11, 13, ... . Für alle ganzen Zahlen i = 1, 2, 3, ..., p-1 muss eine Zahl x existieren, sodass gx mod p = i
Wie erzeugt man geheimes Schlüsselmaterial?
202
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP Das Ergebnis der mathematischen Operation a mod b (a Modulo b) ist der Rest nach der Division a/b; z.B. 7 mod 3 = 1 (7/3 = 2 und der Rest = 1).
Wie Abbildung 5.7-1 zeigt, sind folgende drei Schritte beim MIKEY-Verlauf im sog. Diffie-Hellman-Modus zu unterscheiden: 1. Der Initiator wählt eine große ganze Zufallszahl x, die geheim gehalten werden muss, berechnet ZA = gx mod p und teilt dem Responder den Wert gx mit. 2. Der Responder wählt ebenso eine große ganze Zufallszahl y, die geheim gehalten werden muss, berechnet ZB = gy mod p und teilt dem Initiator den Wert gy mit. Bemerkung: Weil der Modulo-Wert p durch die DH-Gruppe festgelegt wird, braucht der Initiator den Wert gy mod p an den Responder nicht zu übermitteln, sondern nur gx. Genauso muss der Responder nur gy an den Initiator übermitteln.
3. Der Initiator berechnet: SA = (ZB)x mod p = (gy mod p)x mod p = (gy)x mod p = gyx mod p Der Responder berechnet:
www.wiwobooks.com
SB = (ZA)y mod p = (gx mod p)y mod p = (gx)y mod p = gxy mod p Somit ist S = SA = SB = gxy mod p
das geheime Schlüsselmaterial, das Initiator und Responder verwenden können. Dieses Schlüsselmaterial kann bei SRTP als sog. Master Key dienen und wird dazu verwendet, die sog. Session Keys zu erzeugen (s. Abb. 5.7-5).
5.7.3 Gesicherte Kommunikation nach SRTP Wie bereits im Abschnitt 5.2.1 gezeigt wurde (s. Abb. 5.2-1), muss zuerst eine Session zwischen Endeinrichtungen aufgebaut werden, um ein Echtzeitmedium wie z.B. Sprache in RTP-Paketen zwischen ihnen zu übermitteln. Hierfür benötigt man ein Signalisierungsprotokoll, wie z.B. SIP bzw. H.323-Signalisierung. Abbildung 5.7-2 zeigt, welche Phasen bei einer Sprachübermittlung nach SRTP und bei Einsatz von MIKEY zu unterscheiden sind. Phasen bei gesicherter Sprachkommunikation
Die einzelnen Phasen bei gesicherter Sprachkommunikation: 1. Aufbau einer ungesicherten Session Der Aufbau einer Session kann nach dem Signalisierungsprotokoll SIP bzw. nach den Protokollen H.225.0 und H.245 aus der Familie H.323 erfolgen (s. Abschnitt 6.1.4). Dient MIKEY als Key-Management-Protokoll, lassen sich seine Nachrichten einfach in die Nachrichten der Signalisierungsprotokolle einbetten.
5.7 Secure Real-time Transport Protocol (SRTP) Beispiel: Sollte SIP eingesetzt werden und initiiert das IP-Tel A eine Session, wird die MIKEY-Nachricht I_msg vom IP-Tel A zum Tel B im SIP-Request INVITE übermittelt. Die MIKEY-Nachricht R_msg vom IP-Tel B zum Tel B kann die SIP-Antwort 200 OK enthalten (vgl. Abb. 5.7-1).
IP -T e l. A
A u fb a u e in e r S e s s io n 1
M IK E Y
M a s te r K e y , ... 2 3 4
IP -T e l. B
IP -N e tz
E rz e u g e n v o n S e s s io n K e y s x x + 1
g e s ic h e r te S e s s io n
R T P R T C P
M a s te r K e y , ... E rz e u g e n v o n S e s s io n K e y s
S R T P -P a k e te S R T C P -P a k e te
y y + 1
A b b a u d e r g e s ic h e rte n S e s s io n x , y : R T P -P o rts - g e ra d e Z a h le n
x + 1 , y + 1 : R T C P -P o rts
Abb. 5.7-2: Schritte bei gesicherter Sprachübermittlung nach SRTP und beim MIKEY-Einsatz als Key Management Protocol
www.wiwobooks.com
2. Erzeugen von Session Keys nach SRTP Der Ablauf eines Signalisierungsprotokolls in der Phase 1 hat zum Aufbau einer ungesicherten Session geführt. Nach dem MIKEY-Ablauf verfügen die beiden IP-Telefone bereits über ein gemeinsames und geheimes Schlüsselmaterial, das man als Master Key bezeichnet. Nach den in SRTP festgelegten Regeln erzeugen nun die beiden IP-Telefone die notwendigen Schlüssel, um die Übermittlung der Sprache zu sichern. Bei SRTP verwendet man hierfür verschiedene Arten sog. Session Keys (s. Abb. 5.7-5). Ein Session Key wird z.B. für die Verschlüsselung von Payload in RTPPaketen und der andere für die Authentifizierung des Absenders genutzt. 3. Kommunikation über eine gesicherte Session Haben die kommunizierenden IP-Telefone die vereinbarten Session Keys bereits erzeugt, können sie die zu übermittelnden RTP- und RTCP-Pakete entsprechend sichern. Dabei werden die Pakete um die SRTP-Angaben erweitert (s. Abb. 5.7-4), und es entstehen sog. SRTP- und SRTCP-Pakete. Eine gesicherte Session kann man sich als „normale“ Session vorstellen, über die zwischen den kommunizierenden IP-Telefonen SRTP- und SRTCP-Pakete übermittelt werden. 4. Abbau der gesicherten Session Ist die Kommunikation zu Ende, muss die gesicherte Session abgebaut werden. Dies verläuft nach dem Protokoll SIP bzw. nach den Protokollen H.225.0 und H.245 genau wie der Abbau jeder „ungesicherten“ Session.
203
204
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.7.4 Prinzip der Integritätsprüfung und Authentifizierung Einsatz einer Hashoperation HMAC
SRTP ermöglicht, die Integrität der empfangenen RTP-Pakete zu überprüfen, d.h. ob sie unterwegs verändert wurden. Hierfür wird jedem zu übertragenden RTP-Paket eine kryptografische Prüfsumme (eine Art der Signatur) hinzugefügt. Diese Prüfsumme wird nach einer Hashoperation HMAC (Hashing for Message Authentication) aus dem RTP-Paket beim Einsatz eines gemeinsamen geheimen Schlüssels SA für die Authentifizierung errechnet (s. Abb. 5.7-5). Bei SRTP wird ein derartiger Schlüssel SA als Session Authentication Key bezeichnet. Nur der Absender und der Empfänger verfügen über den geheimen Schlüssel SA zur Berechnung dieser Prüfsumme. So lässt sich jedes zu übertragende RTP-Paket signieren. Von großer Bedeutung ist die Überprüfung, ob die empfangenen RTP-Pakete vom „wahren“ Absender stammen. Eine derartige Überprüfung bezeichnet man als Authentifizierung des Absenders. Sie ist mit SRTP möglich und kann auch mit Hilfe einer speziellen Hashfunktion durchgeführt werden. Mit Hilfe dieser Hashfunktion sind die gleichzeitige Prüfung der Integrität und die Authentifizierung möglich. In diesem Fall wird der Hashwert jeweils aus dem zu übertragenden RTP-Paket und aus dem geheimen Schlüssel SA berechnet, der nur den beiden kommunizierenden Partnern (theoretisch!) bekannt ist.
www.wiwobooks.com
Abbildung 5.7-3 zeigt das Prinzip der gleichzeitigen Authentifizierung und Überprüfung der Integrität nach SRTP bei Übermittlung eines RTP-Pakets.
A b g e s c h ic k te s S R T P -P a k e t
Y H a sh w e rt
X = R T P -P a k e t P a y lo a d (S p ra c h e , V id e o )
Y = H M A C ( X ,S A )
R T P -H e a d e r
S A : S c h lü s s e l fü r A u th e n tifiz ie ru n g
E m p fa n g e n e s S R T P -P a k e t A b se n d e r S A
[Y , X ]
E m p fä n g e r
IP -N e tz
[Y * , X * ] S
A
Ü b e r p r ü fu n g
Z = H M A C (X * , S A ) Z = Y * = > X s ta m m t v o m w a h re n A b s e n d e r u n d w u rd e n ic h t m a n ip u lie rt. Z = Y * = > X s ta m m t n ic h t v o m w a h re n A b s e n d e r o d e r w u rd e m a n ip u lie rt.
Abb. 5.7-3: Prinzip der Integritätsprüfung und Authentifizierung nach SRTP
Die beiden Kommunikationspartner verwenden die gleiche Hashfunktion HMAC und nutzen den geheimen Schlüssel SA, der nur ihnen bekannt ist. Hier handelt es sich um eine Hashfunktion, die vom Schlüssel abhängig ist und den
5.7 Secure Real-time Transport Protocol (SRTP)
205
MAC (Message Authentication Code) darstellt. Der Absender berechnet zuerst den Hashwert Y = HMAC(X, SA) aus dem zu übertragenden RTP-Paket X und aus dem geheimen Schlüssel SA. Dann übermittelt er den Hashwert Y am Ende des RTP-Pakets, d.h. nach X, als deren Prüfsumme. Die beiden Teile X und Y bilden somit ein SRTP-Paket (s. Abb. 5.7-4). Dem Empfänger ist SA bekannt, sodass er den Hashwert Z = HMAC(X*, SA) aus dem empfangenen RTP-Paket X* und aus SA berechnet. Um zu überprüfen, ob das empfangene RTP-Paket vom „wahren“ Absender stammt und ob es unterwegs manipuliert wurde, vergleicht er den empfangenen Hashwert Y* mit dem von ihm berechneten Hashwert Z. Zwei Möglichkeiten kommen nun in Frage:
Kriterium Ist Z gleich Y*, stammt das empfangene RTP-Paket vom wahren Absender bei der Überprüfung und wurde unterwegs nicht manipuliert. In diesem Fall ist X gleich X*.
Falls Z nicht gleich Y* ist, stammt das empfangene RTP-Paket X nicht vom wahren Absender, oder es wurde unterwegs manipuliert. In diesem Fall ist X nicht gleich X*. Nach dem gleichen Prinzip werden auch die RTCP-Pakete kontrolliert.
www.wiwobooks.com
Als Hashoperation HMAC bei SRTP soll die in RFC 2104 definierte HMAC- Einsatz von SHA1 (HMAC Secure Hash Algorithm) verwendet werden. Eine wichtige Be- HMACsonderheit jeder Hashoperation ist, dass sie einen Datenblock beliebiger Länge SHA1 auf einen Hashwert immer fester Länge komprimiert. Der Hashwert von HMAC-SHA1 ist 160 Bits lang, was zu einer hohen Sicherheit führt.
5.7.5 SRTP- und SRTCP-Pakete Die Sicherung der zu übermittelnden RTP- und RTCP-Pakete führt dazu, dass sie um bestimmte sicherheitsrelevante Angaben ergänzt werden müssen. Auf diese Weise entstehen sog. SRTP- und SRTCP-Pakete. Abbildung 5.7-4 zeigt ihre Struktur. Ein RTP-Paket wird um folgende Angaben ergänzt: MKI (Master Key Identifier)
SRTP setzt voraus, dass ein Key Management Protocol wie z.B. MIKEY eingesetzt wird, mit dessen Hilfe die kommunizierenden Partner ein bzw. mehrere sog. Master Keys erzeugen können (vgl. Abb. 5.7-1). MKI besagt, welcher Master Key, falls mehrere in Frage kommen, für die Sicherung des betreffenden RTP-Pakets verwendet wurde. Authentication tag
In diesem Feld, das zwar optional ist, aber empfohlen wird, ist der Wert der vereinbarten Hashfunktion HMAC enthalten. Damit ist die gleichzeitige
Angaben im RTP-Paket
206
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
Prüfung der Integrität und die Authentifizierung nach dem in Abbildung 5.7-3 gezeigten Prinzip möglich. Die Länge von Feldern MKI und Authentication tag ist konfigurierbar. a )
S R T P -P a k e t R T P -P a k e t R T P H e a d e r
b )
R P a v e rsc h In te g r itä ts p
T P y lo a d lü s s e lt r ü fu n g
S R T C P -P a k e t R T C P -P a k e t R T P - S R - b z w . R R P a k e t H e a d e r In te g r itä ts p r ü fu n g
S D E S P a k e t
S R T P A n g a b e n M K I
A u th ta g
S R T C P -A n g a b e n E S R T C P in d e x
M K I
A u th ta g
v e r s c h lü s s e lt
Abb. 5.7-4: Struktur: a) des SRTP- Pakets, b) des SRTCP-Pakets
www.wiwobooks.com
E: Encrypted, MKI: Master Key Identifier, Auth tag: Authentication tag
Angaben im RTCP-Paket
Ein RTCP-Paket wird genau wie ein RTP-Paket um MKI und um ein Authentication tag ergänzt. Zusätzlich enthält ein RTCP-Paket folgende zwei Angaben: E-flag (1 Bit, E: Encrypted): Mit diesem Bit gibt man an, ob das RTCPPaket verschlüsselt ist. Falls E = 1, ist das RTCP-Paket verschlüsselt, sonst nicht. SRTCP index (31 Bits): Mit dieser Angabe werden die RTCP-Pakete fort-
laufend nummeriert nach Modulo 231. Diese Angabe soll den Anti-ReplaySchutz bei den RTCP-Paketen ermöglichen (s. Abschnitt 5.7.6).
5.7.6 Session Keys bei SRTP Stromverschlüsselung
Um die zu übertragenden RTP- und RTCP-Pakete zu sichern, verwendet man mehrere Schlüssel. Man bezeichnet sie als Session Keys. Um kontinuierliche Bitströme wie z.B. Sprache zu sichern, muss die Verschlüsselung in Echtzeit durchgeführt werden. Hierfür kommt nur ein sog. Stromverschlüsselungsverfahren (Stream Encryption) in Frage (vgl. Abb. 5.7-6). Ein derartiges Verschlüsselungsverfahren ist einfach zu implementieren, sodass es sich sogar in mobilen IP-Telefonen einsetzen lässt.
207
5.7 Secure Real-time Transport Protocol (SRTP) Für Mobilfunknetze nach dem GSM-Standard wurde der Verschlüsselungsstandard A5 entwickelt, der ebenfalls auf einem Stromverschlüsselungsverfahren basiert. Es wurden spezielle Angriffe auf die Sprachübertragung beim A5-Einsatz veröffentlicht, die man als Time-MemoryTradeoff-Angriffe (kurz TMT-Angriffe) bezeichnet. Die erste Variante des TMT-Angriffs aus der Veröffentlichung von Golic im Jahr 1997 wurde von Biryukow und Shamir Ende 1999 vereinfacht. Die Nachricht, dass man die A5-Verschlüsselung sogar auf einem einfachen PC in Echtzeit entschlüsseln konnte, war sensationell.
TimeMemoryTradeoff Angriffe
Im Allgemeinen benötigt ein Angreifer bei einem TMT-Angriff umso weniger Zeit für die eigentliche Entschlüsselung, je mehr Speicherplatz ihm in seinem Rechner zur Verfügung steht. Für einen TMT-Angriff werden die „denkbaren“ Schlüsselströme nach bestimmten Kriterien im Voraus erzeugt und in einer Datenbank für eventuelle Angriffe abgespeichert. Bei einer großen Festplattenkapazität ist der Angriff sogar in Echtzeit möglich.
Weil man bei SRTP ein Stromverschlüsselungsverfahren verwendet, muss man mit TMT-Angriffen rechnen. Um ihre Wirkung möglichst einzuschränken, nutzt man bei SRTP den sog. Salting Key. Bei SRTP wird vorausgesetzt, dass ein Key Management Protocol, wie z.B. Arten von MIKEY, verwendet wird (vgl. Abb. 5.7-1). Nach dem Ablauf dieses Protokolls Session Keys sind die beiden kommunizierenden Endeinrichtungen jede für sich selbst in der Lage, Master Key und Master Salt zu generieren. Außerdem können die Endeinrichtungen vereinbaren, ob der Master Key während einer Session gewechselt werden soll. Ist dies der Fall, wird vereinbart, wie häufig der Schlüsselwechsel stattfinden soll und was als Parameter Key Derivation Rate angegeben wird. Dieser Parameter hat den Wert 0, falls der Schlüssel für die Dauer einer Session unverändert bleibt.
www.wiwobooks.com
K e y M a n a g e m e n t P ro to c o l M a s te r K M a s te r S K e y D e riv a tio n R P a c k e t In
e y a lt a te d e x
P se u d o R a n d o m F u n c tio n
(d e fa u lt A E S -C M )
S e s s io n E n c ry p tio n K e y S e s s io n A u th e n tic a tio n K e y S e s s io n S a ltin g K e y
Abb. 5.7-5: Generieren von Session Keys
Wie Abbildung 5.7-5 zeigt, werden bei SRTP folgende Session Keys erzeugt: Session Encryption Key zur Ver- bzw. Entschlüsselung; Session Authentication Key, um Authentication tag zu berechnen; Session Salting Key zur Verschlüsselung von SSRC (s. Abb. 5.3-1) und Packet Index bei der Berechnung des Stromschlüssels (Stream Key). Die Session Keys werden von einem Zufallsgenerator, der durch eine Pseudo- Generieren Random Funktion (PRF) spezifiziert wird, getrennt für RTP bzw. RTCP gene- von Session Keys
208
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
riert. Als PRF wurde vorgeschlagen, standardmäßig den Algorithmus AES-CM (Advanced Encryption Standard Counter Mode) zu verwenden. Packet Index für
Anti-ReplaySchutz
Um Anti-Replay-Schutz zu ermöglichen, berechnet man für jedes Paket den Parameter Packet Index. Er stellt eigentlich die laufende Nummer des RTPbzw. des RTCP-Pakets während einer Session dar. Für die Angabe der Sequenznummer eines RTP-Pakets steht in seinem Header das Feld Sequence Number mit der Länge 16 Bits zur Verfügung (s. Abb. 5.3-1). So werden die zu sendenden RTP-Pakete nach Modulo 216 fortlaufend nummeriert. Der Index i eines RTP-Pakets wird somit wie folgt bestimmt: i = ROC * 216 + SEC SEC stellt Sequence Number aus dem RTP-Header in dezimaler Form dar. ROC (Roll-Over Counter) gibt hierbei an, wie oft SEC seit Beginn der Session
von 216 auf 0 zurückgesetzt wurde, d.h. wie oft die Nummerierung nach Modulo 216 von 0 angefangen wurde. Wie man Anti-ReplaySchutz realisiert
Weil der Index eines RTP-Pakets seine laufende Nummer während einer Session darstellt, kann er verwendet werden, um den Anti-Replay-Schutz zu realisieren. Ist der Index des letzten empfangenen RTP-Pakets z.B. gleich x, erwartet man normalerweise, dass das nächste ankommende RTP-Paket die Nummer x+1 hat. Es können eventuell einige darauffolgende Pakete unterwegs verloren gehen. Man kann beispielsweise annehmen, dass nicht mehr als Δ benachbarte RTP-Pakete als ein zusammenhängender Block (Burst) verloren gehen. Somit erwartet man von dem wahren Absender das nächste RTP-Paket nur mit einem Index aus dem Bereich <x+1, ..., x+Δ>.
www.wiwobooks.com
Somit kann man den Anti-Replay-Schutz wie folgt realisieren: Nach dem letzten empfangenen RTP-Paket mit dem Index x werden nur diese empfangenen RTP-Pakete nicht verworfen, deren Index zum Bereich <x+1, ..., x+Δ> gehört. Jedes empfangene RTP-Paket, dessen Index außerhalb dieses Bereichs liegt, wird als fremdes RTP-Paket – d.h. als nicht vom wahren Absender stammendes – betrachtet und muss verworfen werden.
5.7.7 Vorbereitung eines RTP-Pakets zum Senden Vor dem Absenden eines RTP-Pakets wird zunächst sein Payload verschlüsselt und dann der Wert Authentication tag berechnet (vgl. Abb. 5.7-4). Abbildung 5.7-6 illustriert diese Schritte.
5.7 Secure Real-time Transport Protocol (SRTP)
R T P -P a k e t P a y lo a d a ls K la rte x t
E n c ry p tio n S a ltin g P a c k e t I S
K e y K e y n d e x S R C
K e y s tre a m G e n e ra to r
209
H
V e rs c h lü s s e lu n g X O R
(A E S -C M , A E S -f8 )
K e y s tre a m
H : R T P -H e a d e r, K s P : K e y s tre a m -P re fix , A u th : A u th e n tic a tio n ta g
A u th
K sP M K I P a y lo a d a ls G e h e im te x t H H M A C A u th e n tic a tio n K e y
Abb. 5.7-6: Vorbereitung eines RTP-Pakets zum Senden – Stromverschlüsselungsverfahren KsP: Keystream-Prefix, XOR: eXclusive OR
Bei SRTP wird ein Stromverschlüsselungsverfahren verwendet, sodass man Man benötigt einen pseudozufälligen Keystream (Schlüsselstrom) für die Verschlüsselung be- einen nötigt. Dieser Keystream wird durch einen Keystream-Generator, d.h. durch Keystream einen Zufallsfolgengenerator, für jedes Paket erzeugt. Bei der Generierung von Keystream verwendet man als Parameter Session Encryption Key, Session Salting Key, Packet Index und SSRC (s. Abb. 5.3-1). Dem erzeugten Keystream wird ein Keystream-Präfix vorangestellt. Das Authentication tag kann eventuell auch aus diesem Präfix berechnet werden.
www.wiwobooks.com
Der Keystream-Generator funktioniert standardmäßig nach dem Algorithmus AES-CM als AES-CM bzw. nach dem Algorithmus AES-f8, der für die Verschlüsselung im KeystreamUMTS (Universal Mobile Telecommunications System) entwickelt wurde. Der Generator auf diese Weise generierte Keystream kann eine Länge bis zu 223 Bits haben. Somit könnte die Länge des Payload mit Audio bzw. Video in einem RTPPaket ebenfalls so lang sein. Dies ist jedoch in der Praxis nicht der Fall. Für die Verschlüsselung wird Payload vom RTP-Paket als „Klartext“ durch die Operation XOR bitweise mit dem Keystream verknüpft. Damit wird der Payload vom RTP-Paket in einen „Geheimtext“ umgewandelt. Bevor das RTP-Paket übertragen wird, kann eventuell noch das Feld MKI an- HMACgehängt werden. Danach wird der Hashwert Authentication tag aus dem Berechnung Paket berechnet und am Ende hinzugefügt. So entsteht ein SRTP-Paket, das man über ein IP-Netz sicher übermitteln kann. Die Berechnung von Authentication tag erfolgt nach der Hashfunktion HMAC, genauer gesagt HMAC-SHA1. Hierbei kommt auch der Authentication Key zum Einsatz. Die Vorbereitung eines RTCP-Pakets zum Senden verläuft nach dem gleichen Prinzip wie die eines RTP-Pakets (s. Abb. 5.7-6).
210
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
5.7.8 Bearbeitung eines empfangenen RTP-Pakets Authentifizierung und Überprüfung der Integrität
Abbildung 5.7-7 veranschaulicht die Bearbeitung eines empfangenen RTPPakets. Zuerst findet eine Authentifizierung des Absenders und eine Überprüfung der Integrität des Pakets mit Hilfe von Authentication tag statt (vgl. Abb. 5.7-3). Hierfür wird aus dem Paket, ausgenommen Authentication tag, der Hashwert Auth* nach der Hashfunktion HMAC (genau HMACSHA1) berechnet und mit dem Wert Auth im empfangenen Paket verglichen. Ist Auth = Auth*, stammt das empfangene RTP-Paket vom wahren Absender und wurde unterwegs nicht manipuliert. Ansonsten stammt es nicht vom wahren Absender bzw. wurde unterwegs manipuliert. In diesem Fall muss es verworfen werden.
= ?
E m p fa n g e n e s S R T P -P a k e t
A u th
A u th *
H M A C
A u th e n tic a tio n K e y
M K I P a y lo a d a ls G e h e im te x t H
www.wiwobooks.com K e y s tre a m G e n e ra to r
E n c ry p tio n S a ltin g P a c k e t I S
K e y K e y n d e x S R C
H : H e a d e r
P : P re fix
(A E S -C M , A E S -f8 )
E n ts c h lü s - X O R s e lu n g
K e y s tre a m
P a y lo a d a ls K la rte x t H
E n ts c h lü s s e lte s R T P -P a k e t
A u th : A u th e n tic a tio n ta g
Abb. 5.7-7: Bearbeitung eines empfangenen RTP-Pakets XOR: eXclusive OR
Entschlüsselung
Stammt das empfangene RTP-Paket vom wahren Absender und wurde unterwegs nicht manipuliert, wird es zuerst entschlüsselt. Die Entschlüsselung erfolgt nach dem gleichen Prinzip wie die Verschlüsselung auf der Sendeseite (vgl. Abb. 5.7-6). Falls im empfangenen Paket der MKI enthalten ist, wird der richtige Master Key anhand der hier angegebenen Master-Key-Identifikation ausgewählt. Danach werden die notwendigen Session Keys erzeugt (vgl. Abb. 5.7-5) und ein Keystream mit Hilfe des gleichen Keystream-Generators wie auf der Sendeseite generiert. Das im empfangenen RTP-Paket enthaltene Payload wird durch die Operation XOR mit dem für dieses Paket erzeugten Keystream verknüpft. Als Folge dieser XOR-Verknüpfung gewinnt man das Original-RTPPayload zurück. Wie in Abbildung 5.7-7 veranschaulicht, verläuft auch die Bearbeitung eines empfangenen RTCP-Pakets.
211
5.7 Secure Real-time Transport Protocol (SRTP) Beweis für die Entschlüsselung: Es stellt sich nun die Frage, ob das in Abbildung 5.7-7 entschlüsselte Payload als Klartext mit dem in Abbildung 5.7-6 verschlüsselten Payload übereinstimmt. Bezeichnet man das nicht verschlüsselte Payload als A und den Streamkey als Ks, kann das verschlüsselte Payload B dargestellt werden als B = A ⊕ Ks (⊕ = XOR-Operation). Kam während der Übermittlung kein Bitfehler zustande, ist das im empfangenen RTP-Paket enthaltene Payload ebenfalls gleich B. Weil bei der XOR-Operation gilt: (x ⊕ b) ⊕ b = a, kann die Entschlüsselung wie folgt formal dargestellt werden: B ⊕ Ks =(A ⊕ Ks) ⊕ KS = A
Dies begründet, dass das entschlüsselte Payload mit dem Original-Payload übereinstimmt.
5.7.9 Schritte bei der Bearbeitung eines RTP-Pakets Bisher wurden die Schritte vor dem Senden und nach dem Empfangen eines RTP-Pakets nur unabhängig voneinander erläutert. Abbildung 5.7-8 zeigt nun alle Schritte an der Sende- und Empfangsseite im Zusammenhang. B e s tim m u n g d e s K ry p to -K o n te x ts
www.wiwobooks.com P a c k e t-In d e x -B e re c h n u n g
B e s tim m u n g v o n M a s te r K e y u n d M a s te r S a lt
*
*
B e s tim m u n g v o n S e s s io n K e y s R T P 1 2 3 4 5 P a k e t V e rs c h lü s s e lu n g A u th -B e re c h n u n g 6
IP -N e tz S R T P P a k e t
1
2
3 4
5
6
R T P P a k e t
A u th -A u s w e rtu n g E n ts c h lü s s e lu n g
* n u r d a n n , w e n n m a n M a s te r K e y w ä h re n d e in e r R T P -S e s s io n w e c h s e lt
Abb. 5.7-8: Bearbeitung eines RTP-Pakets an der Sende- und Empfangsseite Liegt ein RTP-Paket zum Senden vor, sind im Allgemeinen folgende Schritte vor dem Senden zu unterscheiden: 1.
Bestimmung des Krypto-Kontexts – Mit Hilfe eines Key-Management-Protokolls haben die beiden kommunizierenden Endeinrichtungen bestimmte Verfahren und Parameter vereinbart (s. Abb. 5.7-2). Danach hat jede Endeinrichtung für sich selbst einen bzw. mehrere Master Keys und eventuell auch Master Salt erzeugt. Die vereinbarten Parameter sowie Master Key und Master Salt stellen für jede Endeinrichtung einen kryptografischen Kontext (Cryptographic Context, kurz Krypto-Kontext) dar. Diesem Krypto-Kontext wird eine Identifikation context_id zugeordnet, die man wie folgt definiert: context_id = <SSRC, Ziel-IP-Adresse, Ziel-RTP-Port-Nr> SSRC ist im RTP-Header enthalten und stellt eine Identifikation der Quelle dar (s. Abb. 5.31). context_id kann auch als Identifikation einer Session angesehen werden und dient als Verweis auf einen Speicherplatz, wo der Krypto-Kontext für die Session abgespeichert wurde. Mit context_id wird somit der Krypto-Kontext bestimmt.
Nutzung einer Eigenschaft von XOR
212
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
2.
Packet-Index-Berechnung – Kennt man den Krypto-Kontext, kann der Index des zu sendenden RTP-Pakets bestimmt werden. Der Index des RTP-Pakets wird nicht übermittelt. Die Empfangsseite ist in der Lage, den Index selbst zu berechnen. Im Gegensatz zu RTP wird der Index jedes RTCP-Pakets übertragen (vgl. Abb. 5.7-4). Der Index eines RTP- bzw. eines RTCP-Pakets stellt seine laufende Nummer während einer Session dar.
3.
Bestimmung von Master Key und Master Salt – Im nächsten Schritt werden Master Key und Master Salt bestimmt. Dies geschieht nur dann, wenn der Master Key während einer Session gewechselt wird.
4.
Bestimmung von Session Keys – Sind Packet Index, Master Key und Master Salt bekannt, können die benötigten Session Keys erzeugt werden (vgl. Abb. 5.7-5).
5.
Verschlüsselung – Wurden Session Keys erzeugt, wird das Payload im zu sendenden RTPPaket nach dem in Abbildung 5.7-6 gezeigten Prinzip verschlüsselt.
6.
Auth-Berechnung – Nach der Verschlüsselung wird der HMAC-Wert berechnet und im Feld Authentication tag eingetragen. Danach kann das RTP-Paket über ein IP-Netz übermittelt werden.
Auf der Empfangsseite verläuft die Bearbeitung eines empfangenen RTPPakets in folgenden Schritten: Schritte 1, 2, 3 und 4 – laufen genauso ab wie die entsprechenden Schritte vor dem Senden.
www.wiwobooks.com
Schritt 5: Auth-Auswertung – Auf der Empfangsseite erfolgt zunächst eine Auswertung von Authentication tag (vgl. Abb. 5.7-7) sowie eine Authentifizierung des Absenders und eine Überprüfung der Integrität des Pakets. Schritt 6: Entschlüsselung – Stammt das empfangene RTP-Paket vom wahren Absender und wurde unterwegs nicht manipuliert, wird dieses Paket entschlüsselt. Bei der Bearbeitung eines RTCP-Pakets lassen sich auch die in Abbildung 5.7-8 dargestellten Schritte unterscheiden.
5.8 CRTP und ROHC
Kompression des RTP/UDP/IP-Headers
Wie bereits im Abschnitt 5.1 gezeigt wurde, verwendet man sehr komplexe Verfahren für die Sprachcodierung, um niedrigere Bitraten zu erreichen und damit die notwendige Bandbreite zu reduzieren. Eine Sprachaufnahme von 20 ms kann z.B. als Sprachsegment mit einer Länge von 20 Bytes dargestellt werden. Um dieses 20-Byte-Sprachsegment über ein IP-Netz zu übermitteln, wird ihm ein RTP/UDP/IP-Header mit der Länge von mindestens 40 Bytes vorangestellt. Damit ist der Overhead länger als das Sprachsegment und muss manchmal selbst komprimiert werden. Hierfür stehen die beiden Protokolle CRTP (Compressed RTP, s. RFC 2508) und ROHC (Robust Header Compression, s. RFCs 3095 und 5225) zur Verfügung.
5.8 Kompression des RTP/UDP/IP-Headers
Die Komprimierung ist möglich, weil in den Headern der Protokolle RTP, UDP und IP mehrere Angaben während der Kommunikation unverändert bleiben, d.h. sie sind statisch. Diese Angaben müssen nur einmal übermittelt werden. Es gibt im RTP/UDP/IP-Header außerdem Angaben, die sich nur selten ändern. Beim Einsatz von CRTP kann beispielsweise der RTP/UDP/IP-Header mit der Länge von 40 Bytes sogar bis auf 2 Bytes reduziert werden.
213 Grundlegende Idee der Komprimierung
5.8.1 Bedeutung von CRTP und ROHC CRTP und ROHC werden eingesetzt, um den RTP/UDP/IP-Header bei der Multimedia-Kommmunikation über langsame Übermittlungskanäle zu reduzieren. Solche Situationen kommen bei VoIP-Anwendungen über Funkkanäle in zellularen Netzen oft vor. ROHC wurde insbesondere mit dem Ziel entwickelt, effektive Multimedia-Kommunikation zwischen mobilen Teilnehmern und den Basisstationen in Mobilfunknetzen der sog. vierten Generation zu ermöglichen. Abbildung 5.8-1 illustriert die Bedeutung von ROHC. Ein Kompressionsprotokoll wie ROHC bzw. CRTP ist kein Ende-zu-EndeProtokoll, sondern ein Protokoll zwischen einem Kompressor auf der Sendeseite und einem Dekompressor auf der Empfangsseite und kann nur abschnittsweise auf den langsamen Übertragungsstrecken eingesetzt werden. Abbildung 5.8-1 soll dies noch einmal zum Ausdruck bringen.
www.wiwobooks.com In te rn e t N Ü B S
R O H C
Z e llu la re s IP -N e tz (z. B . U M T S ) R T P /U D P /IP
B S R O H C
Abb. 5.8-1: Bedeutung von ROHC bei der mobilen Multimedia-Kommunikation BS: Basis Station, NÜ: Netz-Übergang
Die Protokolle CRTP und ROHC können im Schichtenmodell zusammen mit dem Protokoll IP der dritten Schicht zugeordnet werden. Wie Abbildung 5.8-2 zeigt, stellt CRTP bzw. ROHC eine Ergänzung zur dritten Schicht dar. Wie hier ebenfalls ersichtlich ist, wird der lange RTP/UDP/IP-Header von einem kurzen CRTP/ROHC-Header ersetzt. Da ein Link-Level-Modul oft als Adapterkarte hardwaremäßig realisiert wird, kann ein Kompressor/Dekompressor nach CRTP bzw. nach ROHC als Kartentreiber implementiert werden.
Kompression und Dekompression im Schichtenmodell
214
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
V o IP -A p p li 5 4 3
R T P
R T C P
Abb.5.8-2:
R T P
R T P
U D P
R T P
U D P
IP
R T P
U D P
K o m p re sso r 1 -2
V o IP -A p p li
P a y lo a d
L in k L e v e l
1 2
8
R T C P U D P
IP
2 0 /4 0
C R T P b z w . R O H C z . B . W ire le s s L in k
IP D e k o m p re sso r L in k L e v e l
Kompression und Dekompression im Schichtenmodell Appli: Applikation
Beim RTP-Einsatz verwendet man auch das Protokoll RTCP als MonitoringProtokoll, um Berichte (Reports) über den Verlauf der Kommunikation zwischen Sender und Empfänger zu übermitteln. Darüber hinaus müssen die Protokolle CRTP und ROHC garantieren, dass auch der gesamte RTCP/UDP/IPHeader (d. h mit RTCP) in Sonderfällen übermittelt wird. Dies erreicht man z.B. bei CRTP mit Hilfe eines sog. FULL_HEADER (vgl. Abb. 5.8-7).
www.wiwobooks.com
5.8.2 Konzept der Kompression des RTP/UDP/IP-Headers Abbildung 5.8-3 zeigt den RTP/UDP/IP-Header mit einer entsprechenden Klassifizierung seines Kontexts. Im RTP-Header wurden hier nur Felder gezeigt, die immer vorkommen (s. Abb. 5.3-1). In diesem Fall hat der RTPHeader eine Länge von nur 12 Bytes. Arten von Angaben im RTP/UDP/IP -Header
Der Inhalt des RTP/UDP/IP-Headers als Kontext (Context) lässt sich wie folgt klassifizieren: Statischer Kontext: Angaben (z.B. IP-Adressen im IP-Header, Port-Nummern im UDP-Header), die während eines Kommunikationsvorgangs immer konstant sind; Ableitbarer Kontext: aus den anderen Angaben ableitbar (z.B. PacketLength im IP-Header); Selten veränderlicher Kontext: Das sind die Angaben (z.B. ToS im IPHeader), die in einer Serie von Paketen konstant sind. Dynamischer Kontext: Diese Angaben (z.B. Identification im IP-Header, Sequence Number im RTP-Header) ändern sich von Paket zu Paket.
5.8 Kompression des RTP/UDP/IP-Headers
0
IP v 4
V e rs
U D P R T P
V
1 6
8
H L e n T o S Id e n tific a tio n (ID ) F la T T L P ro to c o l S o u rc e A d d D e s tin a tio n S o u rc e P o rt L e n g th P X C C = 0 M P T S T im e s ta m p S S R C ID
2 4
P a c k e t L e n g g F ra g m e n H e a d e r C h e c k re ss A d d re ss D e s tin a tio n P C h e c k su m e q u e n c e N u m
th
215
3 1
t O ffse t su m
o rt b e r
P a y lo a d (z . B . e in S p r a c h s e g m e n t) K o n te x t:
s ta tis c h
a b le itb a r
v e r ä n d e r lic h
d y n a m is c h
Abb. 5.8-3: Klassifizierung von Kontext im RTP/UDP/IP-Header
www.wiwobooks.com
Das grundlegende Konzept der Kompression des RTP/UDP/IP-Headers ist wie Konzept der folgt: Der statische und ableitbare Kontext im RTP/UDP/IP-Header muss nicht Kompression ständig gesendet werden, und beim veränderlichen Kontext sollte man nur die Änderungen übermitteln. Zum dynamischen Kontext gehören folgende Angaben: RTP Marker Bit (M), Dynamischer RTP Sequence Number, RTP Timestamp, Identification im IP-Paket und UDP Kontext Checksum. Diese Angaben bzw. ihre Veränderungen müssen immer übermittelt werden. Die optionalen Angaben im RTP-Header sind CSRC und Header Extension (vgl. Abb. 5.3-1). Somit müssen CRTP und ROHC garantieren, dass auch diese optionalen RTP-Angaben übermittelt werden. Bei der Kompression des RTP/UDP/IP-Headers wird zuerst der vollständige Header vom Kompressor zum Dekompressor übermittelt. Beim Dekompressor wird der vollständige RTP/UDP/IP-Header als Referenzheader abgespeichert. Der statische Kontext und andere Informationen, um den veränderlichen Kontext zu rekonstruieren, bezeichnet man als Session-Kontext. Der Referenzheader ist ein Teil des Session-Kontexts. Abbildung 5.8-4 illustriert die Bedeutung von Session-Kontext beim Einsatz von CRTP.
Statischer Kontext als SessionKontext
Die Pakete vom Kompressor zum Dekompressor enthalten hier nur den CRTP- Bedeutung Header, in dem die eventuellen Veränderungen im RTP/UDP/IP-Header und von CID der Parameter CID (Context IDentifier) übermittelt werden. CID gibt an, um welchen Session-Kontext es sich handelt. Damit dient CID beim Dekompressor als Verweis auf den entsprechenden Speicherplatz beim Empfänger.
216
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
S e s s io n K o n te x t
R H
C ID K o m p re sso r R T P U D P
IP
S e s s io n K o n te x t
D e k o m p re sso r C R T P R T P U D P
IP
Abb. 5.8-4: Bedeutung von Session-Kontext beim Dekompressor am Beispiel von CRTP RH: Referenz-RTP/UDP/IP-Header
5.8.3 Kompression und Dekompression nach CRTP Bei CRTP übermittelt der Kompressor dem Dekompressor entweder einen vollständigen RTP/UDP/IP-Header, dem ein CRTP-Header, der sog. FULL_HEADER, vorangestellt wird, oder nur einen kurzen CRTP-Header, in dem nur Änderungen des dynamischen Kontexts übermittelt werden. Differenzen von Angaben
www.wiwobooks.com
Die Änderungen des dynamischen Kontexts werden durch die Differenzen erster und zweiter Ordnung dargestellt. Es sei xi eine Angabe (z.B. RTP Timestamp bzw. Identifikation im IP-Paket) aus dem dynamischen Kontext im Paket, das als i-tes Paket vom Kompressor abgeschickt wurde. Die Differenz erster Ordnung ist Δxi = xi - xi-1 für i = 1, 2, ... Die Differenz zweiter Ordnung wird berechnet als Δ2xi = Δxi - Δxi-1 für i = 2, 3, ... Es ist zu bemerken, dass die Differenzen erster Ordnung von Angaben wie RTP Timestamp, RTP Sequence Number und Identification im IP-Header in der Regel konstant sind. Somit gilt Δ2xi = 0, d.h., die Differenzen zweiter Ordnung sind gleich 0. Diese Tatsache liegt dem Protokoll CRTP zugrunde.
Verlauf von CRTP ohne Aktualisierung von SessionKontext
Den Verlauf von CRTP illustriert Abbildung 5.8-5. Hier wird zum Ausdruck gebracht, wie die Angabe x aus dem dynamischen Kontext vom Dekompressor rekonstruiert werden kann. Zu Beginn sendet der Kompressor den vollständigen RTP/UDP/IP-Header als FULL_HEADER (H0), der beim Dekompressor als Referenz abgespeichert wird. Das nächste Paket als erstes Paket, das man zum Dekompressor übermittelt, enthält nur einen CRTP-Header mit der Differenz Δx1 statt mit dem Wert x1. Der Dekompressor speichert Δx1 als Session-Kontext und berechnet den Wert x1 aus x0 und Δx1 wie folgt: x1 = x0 +Δx1. Damit rekonstruiert der Dekompressor den RTP/UDP/IP-Header (H1) des ersten Pakets. Das zweite, dem Dekompressor übermittelte Paket enthält ebenso nur einen CRTP-Header. Da es sich hier um eine Angabe handelt, bei der Δ2x2 = 0, d.h. Δx2 = Δx1, braucht die Differenz Δx2 nicht übermittelt zu werden, weil Δx1 dem Dekompressor bereits vorliegt. Er berechnet den Wert
5.8 Kompression des RTP/UDP/IP-Headers
217
x2 aus den bereits als Session-Kontext vorhandenen Werten x1 und Δx1 wie folgt: x2 = x1 +Δx2 = x0 +Δx1. Damit wurde der Header H2 rekonstruiert. IP /U D P /R T P -H e a d e r H
H 0
x
x 0
D x
D x 1
H 2
x 1
D x 2
D e k o m p r e s s o r H 3
x
2
H 3
x
3
D x 1
D x 2
D x 2
= 0 2
3
= 0
D 2x
C R T P -H e a d e r
H
4
=
: F U L L _ H E A D E R
+ D x
i-1
i = 1 , 2 , 3 , i
...
Z e it
4
4
0
x i = x
... 4
D x i = D x 0
i-1
+ D 2x
i = 2 , 3 , i
...
Abb. 5.8-5: Verlauf der Kompression und Dekompression der „dynamischen“ Angabe x nach CRTP ohne Aktualisierung des Session-Kontexts beim Dekompressor Auf diese Weise kann der Dekompressor die „dynamische“ Angabe x selbst berechnen und ermitteln, wie lange ihre Differenz der zweiten Ordnung gleich 0 ist, d.h. wie lange Δ2xi = 0 gilt. Ist beim Kompressor Δ2xi nicht gleich 0, d.h. Δxi stimmt mit Δxi-1 nicht überein, muss er an den Dekompressor den Wert Δxi übermitteln. In der Abbildung betrifft dies Δx4.
www.wiwobooks.com
Falls sich eine statische Angabe verändert hat bzw. ein Paket verloren gegangen ist, muss der Session-Kontext beim Dekompressor aktualisiert werden. Wie Abbildung 5.8-6 zeigt, sendet hierfür der Kompressor den vollständigen RTP/UDP/IP-Header als FULL_HEADER (H0). Damit wird der Session-Kontext beim Dekompressor aktualisiert (aufgefrischt). Danach verläuft die Übermittlung von Header-Angaben nach den bereits geschilderten Prinzipien. A k tu a lis ie ru n g d e s S e s s io n -K o n te x ts
IP /U D P /R T P -H e a d e r H
H
x
0
x 0
D x
D x 1
H 2
D x 2
x 1
x 2
D x C R T P -H e a d e r 2
= 0
D 2x 3
D e k o m p re sso r H
3
1
2
Verlauf von CRTP mit Aktualisierung von SessionKontext
H
3
3
...
= 0
S ta tis c h e r K o n te x t im
x
0
x
0
D x 1
1
H 1
...
H 0
x i = x
: F U L L _ H E A D E R i-1
+ D x
i = 1 , 2 , 3 , ... i
Z e it
D x i = D x
i-1
+ D 2x i
i = 2 , 3 , ...
IP /U D P /R T P -H e a d e r h a t s ic h g e ä n d e rt
Abb. 5.8-6: Verlauf der Kompression und Dekompression der „dynamischen“ Angabe x nach CRTP mit der Aktualisierung des Session-Kontexts beim Dekompressor
Während einer Session verwendet man parallel zum Protokoll RTP das Moni- Nutzung von toring-Protokoll RTCP (vgl. Abb. 5.8-2). Weil der RTCP-Header nicht komp- FULL_ rimiert wird, müssen somit die vollständigen RTCP-Pakete übermittelt werden. HEADER Hierfür definiert CRTP den FULL_HEADER. Abbildung 5.8-7 illustriert dessen Nutzung.
218
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
im m e r R T C P U D P
P a y lo a d
IP
a ls e r s te s P a k e t b z w . fa lls d e r S e s s io n -K o n te x t a k tu a lis ie r t w ir d P a y lo a d R T P U D P IP F U L L _ H E A D E R (F _ H ) 0
0 1
G e n e ra tio n 0
1 1
G e n e ra tio n
C ID
C ID
0
S e q S e q
1 5
8 -B itC ID 1 6 -B itC ID
Abb. 5.8-7: Nutzung von FULL_HEADER CID: Context Identification, Seq: Sequence
FULL_HEADER verwendet man:
um das erste und vollständige RTP-Paket auf einer Session zu übermitteln bzw. falls der Kontext beim Dekompresssor z.B. nach einem Paketverlust aktualisiert werden muss (vgl. Abb. 5.8-5 und -6 );
www.wiwobooks.com
um alle RTCP-Pakete zu übermitteln.
Man unterscheidet zwischen einem FULL_HEADER mit 8-Bit-CID und einem mit 16Bit-CID. Im Feld Seq wird die laufende Nummer von FULL_HEADER eingetragen (s. Abb. 5.8-9). Das Feld Generation wird nur in einem Sonderfall bei IPv6 verwendet. COMPRESSED_RTP
Für die Übermittlung der Veränderungen des dynamischen Kontexts in Form von Differenzen erster Ordnung (s. Abb. 5.8-5) definiert CRTP das Paket COMPRESSED_RTP. Abbildung 5.8-8 zeigt die Struktur dieses Pakets.
Bedeutung von Flags MSTI
Eine besondere Rolle spielen hier die vier Bits MSTI, die als sog. Flags dienen und folgende Bedeutung haben: M = RTP Marker Bit, S = RTP Sequence Number, T = RTP Timestamp und I = Identifikation im IPv4-Paket. Wird ein Flag auf 1 gesetzt, signalisiert dies, dass sich die entsprechende Angabe so verändert, dass sich ihre Differenz erster Ordnung ebenfalls verändert hat. Damit ist ihre Differenz zweiter Ordnung nicht gleich 0. In diesem Fall wird die Differenz erster Ordnung in COMPRESSED_RTP übermittelt. Das auf 1 gesetzte Flag zeigt an, dass die Differenz erster Ordnung der ihm entsprechenden „dynamischen“ Angabe im COMPRESSED_RTP enthalten ist. Falls die Differenzen erster Ordnung von allen dynamischen Angaben im RTP/UDP/IP-Header konstant sind, d.h. MSTI = 0000 und UDP-Checksum nicht übermittelt werden, ist der Header im COMPRESSED_RTP nur 2 Bytes lang. In diesem Fall wird also der RTP/UDP/IP-Header auf nur 2 Bytes komprimiert.
5.8 Kompression des RTP/UDP/IP-Headers
0
219
M
8
S
T
fa lls 1 6 -B it-C ID C ID C ID 2 B y te I L in k S e q u e n c e
U D c h e c k M ´ S ´ T ´ I´ D IP v 4 D R T P D R T P
P su m C C ID S e q u e n c e T im e s ta m p
C S R C ID s R T P H e a d e r E x te n s io n
2 B y te fa fa fa fa
lls lls lls lls
M S T I I o d e r S o d e r T o d e r
= I´ S T
1 1 1 1 = 1 ´ = 1 ´ = 1
fa lls M S T I = 1 1 1 1 u n d C C n ic h t g le ic h 0 fa lls X = 1 im S e s s io n -K o n te x t
R T P -P a y lo a d
Abb. 5.8-8: Struktur des Pakets COMPRESSED_RTP CC: CSRC Count (aus RTP-Header), CID: Context Idenetifier, X: 1-Bit-Angabe im RTP-Header (s. Abb. 5.3-1)
www.wiwobooks.com
Link Sequence gibt die laufende Nummer von COMPRESSED_RTP an. Damit Bedeutung kann der Dekompressor feststellen, ob ein COMPRESSED_RTP verloren gegangen ist. von Link Ist dies der Fall, sendet er ein CRTP-Paket CONTEXT_STATE an den Kompressor, um Sequence eine wiederholte Übermittlung des verloren gegangenen Pakets COMPRESSED_RTP zu veranlassen (s. Abb. 5.8-9).
Falls sich der statische Kontext nur im RTP-Header geändert hat und der stati- Nutzung von sche Kontext im IP-Header unverändert geblieben ist, braucht nur der RTP- COMPRESHeader übermittelt zu werden. Hierfür wird das Paket COMPRESSED_UDP bei SED_UDP CRTP definiert. Beispiel: Auswirkung der Paketverluste und langer Signallaufzeit Falls eine multimediale Kommunikation über eine Übertragungsstrecke mit häufigen Paketverlusten und mit langer Signallaufzeit stattfindet, d.h. der sog. Round-Trip Time (RTT) groß ist (s. Abb. 5.6-3), hat CRTP einige „Schwächen“. Abbildung 5.8-9 soll dies verdeutlichen. Nach dem Absenden von FULL_HEADER mit Seq = 0 übermittelt der Kompressor eine Folge von Paketen COMPRESSED_RTP. Hierbei ist aber das Paket mit LS = 2 verloren gegangen. Erst nach dem Empfangen von COMPRESSED_RTP mit LS = 3 stellt der Dekompressor dies fest. Deshalb übermittelt er nun ein Paket CONTEXT_STATE an den Kompressor, um eine wiederholte Übertragung der verlorenen Inhalte zu veranlassen. Inzwischen hat der Kompressor aber weitere Pakete COMPRESSED_RTP abgeschickt. Nach dem Empfangen von CONTEXT_STATE übermittelt der Kompressor an den Dekompressor nicht COMPRESSED_RTP mit LS = 2 wiederholt, sondern den entsprechenden RTP/UDP/IP-Header inkl. RTP-Payload vollständig im FULL_HEADER mit Seq = 1. Nach dem Empfang dieses FULL_HEADER wird der Session-Kontext beim Dekompressor aktualisiert. Die weiteren Pakete mit LS von 3 bis 9, die der Kompressor bereits vor dem Empfangen von CONTEXT_STATE abgeschickt hat, müssen erneut übermittelt werden.
220
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
K o m p re sso r S e q = 0 L S : 0 1 2 3 4 Ü b e rm ittlu n g 5 m u s s w ie d e r6 h o lt w e rd e n 7 8 9 F _ H S e q = 1 L S : 0 1 2 3 4 5 6
D e k o m p re sso r F _ H
S e q = 0 L S = 0 L S = 1 L S = 3 C _ S
[L S = 1 ]
v e rw o rfe n S e s s io n -K o n te x tA k tu a lis ie ru n g
w ie d e rh o lte Ü b e rm ittlu n g
Abb. 5.8-9: Negative Auswirkung eines Paketverlusts und großer RTT C_S: CONTEXT_STATE, F_H: FULL_HEADER, LS: Link Sequence, Seq: Sequence
www.wiwobooks.com
Dieses Beispiel sollte verdeutlichen, dass CRTP nicht effektiv ist, falls die RTP-Pakete über eine Übertragungsstrecke übermittelt werden, auf der die Paketverluste oft vorkommen und der Round-Trip Delay relativ groß ist. Mit derartigen unerwünschten Effekten muss beispielsweise bei VoIP-Anwendungen über Satellitenverbindungen bzw. über Funkkanäle in Mobilfunknetzen gerechnet werden. Enhanced CRTP
In RFC 3545 wurde bereits eine modifizierte Version von CRTP als Enhanced CRTP (E-CRTP) spezifiziert, um die Effizienz von CRTP in solchen Situationen, die Abbildung 5.8-9 zeigt, zu verbessern. Eine wichtige „Neuerung“ bei E-CRTP im Vergleich zum CRTP besteht darin, dass die E-CRTP-Pakete eine Prüfsumme zur Entdeckung von Übertragungsfehlern enthalten können.
5.8.4 Besonderheiten von ROHC Wie bereits gezeigt wurde, funktioniert CRTP auf den Übertragungsstrecken mit relativ häufigen Paketverlusten und mit großem Round-Trip Delay nicht besonders effektiv. Deswegen wurde das Protokoll ROHC (Robust Header Compression) entwickelt und in den IETF-Dokumenten RFCs 3095, 4815 und 5225 spezifiziert. Abbildung 5.8-1 zeigt einen typischen ROHC-Einsatz. Die grundlegenden Prinzipien der Kompression des RTP/UDP/IP-Headers, die bereits bei CRTP erläutert wurden, verwendet man auch bei ROHC. Es sind u. a. folgende Besonderheiten von ROHC zu nennen:
5.9 Schlussbemerkungen
Wie CRTP ist ROHC ein Protokoll zwischen einem Kompressor und einem Dekompressor. Jede dieser Funktionskomponenten wird als ein Automat dargestellt und kann sich in einem von drei Zuständen befinden. ROHC definiert drei Betriebsarten: Unidirectional (U-)Mode, Bidirectional Optimistic (O-)Mode und Bidirectional Reliable (R-)Mode. Im O- und RMode wird vorausgesetzt, dass ein entsprechender Rückkanal vorhanden ist, um positive bzw. negative Quittungen vom Dekompressor zum Kompressor übermitteln zu können. Der ROHC-Ablauf beginnt immer im U-Mode. Erst wenn der Dekompressor über den vollständigen Session-Kontext verfügt (s. Abb. 5.8-4), kann vom U-Mode auf O- bzw. R-Mode gewechselt werden. ROHC definiert unterschiedliche Pakete, die auch von der Betriebsart abhängig sind, in denen der vollständige RTP/UDP/IP-Header und die Differenzen von dynamischen Angaben übermittelt werden. Wie bei CRTP enthalten alle ROHC-Pakete auch CID als Verweis auf einen Session-Kontext (s. Abb. 5.8-4). Alle ROHC-Pakete enthalten jedoch eine Prüfsumme 8-BitCRC (Cyclic Redundancy Check), was einen wesentlichen Unterschied zum CRTP darstellt. Mit Hilfe von CRC kann der Dekompressor selbst feststellen, ob ein empfangenes Paket fehlerfrei ist.
www.wiwobooks.com
Eine bessere Effizienz auf den Übertragungsstrecken mit relativ häufigen Paketverlusten und großem Round-Trip Delay wird bei ROHC im Vergleich zum CRTP insbesondere dadurch erreicht, dass einerseits die Prüfsumme CRC übermittelt und andererseits eine stärkere Rückkopplung vom Dekompressor zum Kompressor im O- und R-Mode genutzt wird.
5.9
Schlussbemerkungen
Abschließend sind folgende Aspekte hervorzuheben: RTP und RTCP als Protokolle für die Echtzeitkommunikation RTP wurde aufgrund der Anforderungen an die Übertragung von Echtzeitmedien über IP-Netze entworfen. RTP stellt einen Transportdienst für Medien mit Echtzeitcharakteristika wie Audio/Sprache und Video zur Verfügung. Mit RTCP-Hilfe wird ein Mechanismus bereitgestellt, mit dem sich Sender und Empfänger während einer Session die Berichte über die Qualität der Kommunikation austauschen können. Spezifikation von RTP und RTCP RTP wurde ursprünglich im Januar 1996 als RFC 1889 spezifiziert. Im Juli 2003 wurde RFC 1889 durch RFC 3550 abgelöst. RTCP als integraler Bestandteil von RTP wird in den gleichen RFCs 1889 bzw. 3550 spezifiziert. Bei RFC 3550 wurden im Vergleich zu RFC 1889 keine Veränderungen in der Struktur von RTP- und RTCP-Paketen eingeführt. Die größten Ände-
221
222
Neue RTPProfile in RFC 3551
5
Sprachcodierung und Echtzeitkommunikation mit RTP/RTCP
rungen betreffen die Regeln, die vorgeben, wann die RTCP-Pakete gesendet werden sollen. Alle Änderungen im Vergleich zu RFC 1889 werden in Appendix B von RFC 3550 aufgelistet. RTCP wird weiterentwickelt – siehe hierzu die RFCs 5485 und 5506. RTP als ein Protokoll-Framework RTP kann als ein Protokoll-Framework angesehen werden, das für neue Multimedia-Anwendungsklassen (sog. RTP Profile) und neue PayloadTypen offen ist (s. Tab. 5.3-1). RTP Profiles wurden ursprünglich in Januar 1996 als RFC 1890 spezifiziert. Im Juli 2003 wurde RFC 1890 von RFC 3551 abgelöst. In RFC 3551 wird u.a. dargestellt, wie die Sprachbitströme nach dem neuen Sprachcodierungsverfahren (wie z.B. ITU-T-Standards G.726, G.728 und G.729) in RTP-Paketen eingebettet werden. In RFC 3551 wird zusätzlich dargestellt, wie die neuen Video-Formate in RTP-Paketen übermittelt werden.
Kein Multiplexen
Kein Multiplexen innerhalb einer Session RTP definiert keine Funktionen, um mehrere Echtzeitbitströme verschiedener Quellen über eine Session nach dem Multiplexerprinzip zu übermitteln. Verschiedene Bitströme (wie z.B. Sprache, Video) müssen über getrennte RTP-Kanäle übertragen werden. In einigen Fällen kann der Mixer als Ersatz für Multiplexing dienen (s. Abb. 5.4-4).
Problem mit RTP bei VoIP
RTP-Effizienz beim VoIP-Einsatz Bei der Übertragung von Sprache mit einer niedrigen Bitrate wie z.B. von 8 kbit/s dürfen die IP-Pakete nicht zu lang sein, sonst wäre eine Verzögerung bei der Bildung der IP-Pakete an der Quelle zu groß. Bei Sprachsegmenten beispielsweise von 40 Bytes in RTP-Paketen ergibt dies einen RTP/UDP/IP-Header mindestens von 40 Bytes, also über 100%, bei Sprachsegmenten von 160 Byte immer noch 25%. Weil ein Bitfehler im Header in der Regel dazu führt, dass das betroffene Paket verworfen werden muss, erhöht sich dieses Risiko bei einem langen Header ( Paketverluste, siehe auch UDP-Lite in Abschnitt 3.4.1). Bei der Übertragung über Leitungen, auf denen die Bitfehlerrate relativ groß ist, führt ein langer Header somit zu Paketverlusten, die wiederum bewirken, dass das Kompressionsprotokoll CRTP bzw. auch ROHC nicht sehr effizient ist (s. Abb. 5.8-9).
www.wiwobooks.com
6
VoIP nach dem Standard H.323
H.323 ist ein ITU-T-Standard und stellt ein Rahmenwerk (Framework) dar, H.323 als in dem festgelegt wird, wie die weiteren Standards H.225.0 und H.245 sowie Rahmenwerk spezielle Protokolle der TCP/IP-Protokollfamilie wie RTP und RTCP für die Übermittlung von Echtzeitmedien (Audio, Video) in IP-Netzen einzusetzen sind. Um Echtzeitmedien in IP-Netzen zu übermitteln, sind unterschiedliche Arten von virtuellen Verbindungen nötig. H.225.0 und H.245 als H.323Signalisierung beschreiben die Regeln, nach denen diese Verbindungen eingerichtet werden können. Für die Kontrolle einer Gruppe von Endeinrichtungen ist in VoIP-Systemen nach H.323 ein sog. Gatekeeper verantwortlich. In VoIP-Systemen nach H.323 können neben der Sprachübermittlung mit Hilfe Bedeutung der Protokolle RTP und RTCP verschiedene ergänzende Dienste als sog. von H.450.x Supplementary Services nach den Standards H.450.x (x = 1, ..., 12) realisiert und H.510 werden. Die Unterstützung der Mobilität von Benutzern in Form von Roaming kann nach dem ITU-T-Standard H.510 erfolgen.
www.wiwobooks.com
Dieses Kapitel erläutert die Prinzipien von VoIP nach H.323. Nach der Darstel- Kapitellung von Komponenten der VoIP-Systeme in Abschnitt 6.1 folgt in Abschnitt überblick 6.2 die Beschreibung der H.323-Signalisierung. Den Verlauf der Steuerung zwischen Endeinrichtungen und Gatekeeper beschreibt Abschnitt 6.3. Signalisierung nach H.225.0 und H.245 präsentieren die Abschnitte 6.4 und 6.5. Auf Supplementary Services bei VoIP nach H.323 geht Abschnitt 6.6 ein. Wie die Mobilität von Teilnehmern unterstützt werden kann, zeigt Abschnitt 6.7. Schlussbemerkungen in Abschnitt 6.8 runden das Kapitel ab. In diesem Kapitel werden u.a. folgende Fragen beantwortet:
Ziel Welche Systemkomponenten und Protokolle sind für die Realisierung von des Kapitels
VoIP-Systemen nach H.323 erforderlich? Welche Konzepte liegen der H.323-Signalisierung zugrunde, welche Protokolle werden eingesetzt, und wie verläuft die Signalisierung? Wie werden die logischen RTP- und RTCP-Kanäle eingerichtet? Was haben VoIP-Systeme mit ISDN gemeinsam, wie passen sie zusammen, und wie lassen sie sich integrieren? Welche Bedeutung hat ein Gatekeeper, und wie wird er eingesetzt? Welche Supplementary Services können in VoIP-Systemen nach H.323 zur Verfügung gestellt werden? Welche Möglichkeiten bestehen, die Mobilität von Teilnehmern zu unterstützen, und wie lassen sie sich in die Praxis umsetzen?
6.1 Systemkomponenten nach H.323
225
nungen von Telefonnummern zu den IP-Adressen aller seiner Kommunikationspartner selbst verwalten. H.323 unterstützt auch Multipoint-Konferenzen. Durch den Einsatz einer MCU Unterstüt(Multipoint Control Unit) wird der Auf- und Abbau von Punkt-zu-Mehrpunkt- zung von Verbindungen sowie die Datenübermittlung bei der Realisierung von Konfe- Konferenzen renzen gesteuert. Eine MCU enthält einen Multipoint Controller (MC) für die Signalisierung und einen bzw. mehrere Multipoint Processors (MPs) zur Behandlung (Mixen, Switching) von übermittelten Echtzeitmedien. Die Integration einer Zone mit einem anderen Netz für die Sprachkommunika- (VoIP-) tion (z.B. Telefonnetz, ISDN) kann mit Hilfe eines entsprechenden Gateway Gateway erfolgen, das man auch als VoIP-Gateway bezeichnet. Beispielsweise können über ein Gateway Verbindungen zu ISDN-Telefonen aufgebaut werden. Die Konzepte von Gateways stellt Kapitel 8 näher dar.
6.1.1 H.323-Domains Innerhalb eines großen Netzes einer administrativen Einheit (z.B. eines Unternehmens, einer Institution), in dem verschiedene Standorte vernetzt werden, ist es sinnvoll, an jedem Standort eine H.323-Zone einzurichten. Das gesamte Netz würde somit mehrere H.323-Zonen enthalten. Wie Abbildung 6.1-2a zeigt, werden dann mehrere H.323-Zonen in einer H.323-Domain zu einer administrativen Einheit vernetzt.
www.wiwobooks.com
S ta n d o r t A Z o n e A R
G K Z o n e D o m a in A Z o n e
G K
...
b )
G K
S ta n d o r t B
D o m a in
B E
IP -N e tz
H .2 2 5 .0 A n n e x G o d e r T R IP
Z o n e B R
G K B E
...
a )
Domain als Vernetzung mehrerer Zonen
G K
G K
Z o n e D o m a in B Z o n e
Abb. 6.1-2: H.323-Domains a) Struktur einer Domain; b) Vernetzung von Domains BE: Border Element, GK: Gatekeeper, R: Router, TRIP: Telephony Routing over IP
Um die Kommunikation zwischen verschiedenen administrativen Einheiten, Vernetzung die auch verschiedene Domains bilden, zu ermöglichen, wird das sog. Border von Domains Element (BE) definiert. BE ist ein Funktionsmodul, das in der Regel mit einem und TRIP Gatekeeper integriert wird. Die Hauptaufgabe von BE besteht vor allem im Austausch der Anrufziele als Vorwahlnummern zwischen den H.323-Domains
226
6
VoIP nach dem Standard H.323
und entsprechender Informationen für die Autorisierung. Für den Austausch der Anrufziele wurde – in Anlehnung an das Protokoll BGP-4 (Border Gateway Protocol) – das Protokoll TRIP (Telephony Routing over IP) entwickelt. Auf TRIP geht Abschnitt 9.2 näher ein. Die Übertragung der Steuerung zum Auf- und Abbau von Verbindungen für Audio- und Videokommunikation zwischen verschiedenen Domains beschreibt der Annex G zum Standard H.225.0. Das Protokoll RAS (Registration, Admission and Status) zwischen den Terminals und dem Gatekeeper enthält u.a. entsprechende Nachrichten (z.B. Location Request) für die Unterstützung der Kommunikation zwischen verschiedenen Domains (s. Abb. 6.3-4). Das Konzept von H.323-Zonen und -Domains entspricht vollkommen dem Konzept von Subnetzen und Domains bei IP-Routing-Protokollen. Eine H.323Zone entspricht somit einem Subnetz. Eine H.323-Domain kann man mit einem Autonomen System vergleichen. BE bei H.323 entspricht einem Border-Gateway beim IP-Routing. Als Routing-Protokoll zwischen zwei Border-Gateways wird BGP-4 eingesetzt (s. Abbildung 9.2-4).
6.1.2 Protokollfamilie TCP/IP und H.323
www.wiwobooks.com
Abbildung 6.1-3 zeigt die Protokollarchitektur für die multimediale Kommunikation nach H.323. Die Audio- und Videokommunikation setzt Verbindungen mit einer bestimmten Bandbreite voraus, sodass hier die QoS-Garantie von großer Bedeutung ist. Für die QoS-Unterstützung bei H.323 kann RSVP (Ressource reSerVation Protocol) eingesetzt werden – siehe Abschnitt 4.6. D a te n a n w e n d u n g T .1 2 0
A u d io -A n w e n d u n g V id e o -A n w e n d u n g V id C o d H .2 H .2
C a ll C o n tro l H .2 2 5 .0
H .2 4 5 C o n tro l
H .3 2 3 - B e r e ic h
H.323Domain als Autonomes System
e o e c : 6 1 , 6 3
R T P
T C P
A u d C o d G .7 G .7
io e c : 1 1 , 2 x
R T C P
U D P In te rn e t
K o m m u n ik a tio n : G a te k e e p e rT e rm in a ls a ls R A S -C o n tro l H .2 2 5 .0 R S V P
P ro to c o l (IP v 4 , IP v 6 )
Ü b e r m ittlu n g s n e tz e ( z . B . L A N s , A T M - , F r a m e - R e la y - N e tz e , ...)
Abb. 6.1-3: Protokollfamilie TCP/IP und H.323-Komponenten – siehe z.B. H.323v6, Fig. VI.1 RAS: Registration, Admission, Status
6.1 Systemkomponenten nach H.323
227
Zum Aufgabenbereich von H.323 gehören folgende Funktionen: RAS-Control (Registration, Admission and Status) Es handelt sich hier um die Steuerung, die zwischen Terminals und Gatekeeper abläuft. Der Gatekeeper stellt quasi eine Zentrale innerhalb einer H.323-Zone dar. Ein Terminal kann nur dann eine Verbindung initiieren, wenn es beim Gatekeeper bereits registriert ist. Beim Verbindungsaufbau muss jedes Terminal jede neue Verbindung beim Gatekeeper anmelden, falls keine sog. pre-granted Admission, also eine „Vorausbewilligung“ vorliegt. Damit wird auch die benötigte Bandbreite beim Gatekeeper angemeldet und kann z.B. mit Hilfe von RSVP reserviert werden.
Steuerung zwischen Terminals und Gatekeeper
Call Control (Anrufsignalisierung) nach H.225.0 Es handelt sich hier um die Prinzipien, nach denen ein Steuerungskanal für das Protokoll H.245, d.h. H.245-Steuerungskanal, zwischen zwei Terminals auf- und abgebaut wird. Der H.245-Steuerungskanal entspricht weitgehend dem D-Kanal bei ISDN. Die Anrufsignalisierung wird im Standard H.225.0 spezifiziert. Die hierfür notwendigen H.225.0-Nachrichten werden vom Standard Q.931 – der das D-Kanal-Protokoll im ISDN spezifiziert – übernommen. Für die Übermittlung von H.225.0-Nachrichten wird das zuverlässige Protokoll TCP verwendet (s. Abb. 6.4-1). Die Spezifikationen von H.225.0 finden Sie auf http://www.itu.int/rec/T-REC-H.225.0.
Auf- und Abbau der H.245Steuerungskanäle
H.245-Control Es handelt sich hier um die Steuerung beim Auf- und Abbau logischer Kanäle für die Audio- und Video-Übermittlung. Diese logischen Kanäle stellen die RTP-Kanäle (Real-time Transport Protocol) dar und entsprechen weitgehend den B-Kanälen im ISDN. Die Steuerung beim Auf- und Abbau logischer Kanäle wird zwischen jeweils zwei Terminals über den H.245Steuerungskanal ausgetauscht. Für die Übermittlung von H.245-Nachrichten verwendet man TCP (vgl. Abb. 6.5-1). Die Spezifikationen von H.245 sind unter http://www.itu.int/rec/T-REC-H.245 abrufbar.
Auf- und Abbau von RTPSitzungen
www.wiwobooks.com
Übermittlung von Echtzeitmedien (Audio/Sprache, Video) EchtzeitDie Übermittlung von Audio und Video erfolgt über RTP-Kanäle (s. Abb. kommunika5.2-1). Als Transportprotokoll wird das verbindungslose UDP verwendet. tion Um die Übermittlung von Echtzeitmedien zu kontrollieren, wird beim RTP ein zusätzliches Hilfsprotokoll RTCP (RTP Control Protocol) eingesetzt. RTP und RTCP wurden bereits in den Abschnitten 5.3 und 5.5 dargestellt. Unterstützung von Datenanwendungen nach T.120 Der ITU-T-Standard T.120 beschreibt die Prinzipien der Datenkommunikation bei den PC-basierten Videokonferenzen und ist integrierbar in H.323. Parallel zur Sprach- und Videokommunikation kann zwischen jeweils zwei Terminals auch die Datenkommunikation nach T.120 stattfinden.
228
6
VoIP nach dem Standard H.323
Unter http://www.packetizer.com/ipmc/h323/doc_status.html ist die Dokumentation bisheriger Entwicklung von H.323 zum Herunterladen verfügbar.
6.1.3 Sprach- und Videocodierung in H.323-Systemen Begriff: Codec
Ein Funktionsmodul, das die Funktionen eines Codierers und Decodierers der Audio/Sprach- bzw. Videosignale in sich integriert, wird bei H.323 als Codec bezeichnet. Werden Audio-, Sprach- bzw. Videosignale codiert und decodiert, spricht man demgemäß vom Audio-, Sprach- bzw. Video-Codec.
AudioCodecs
Beim H.323-Einsatz kann die Sprache nach verschiedenen Verfahren codiert werden. Die Prinzipien und Verfahren der Sprachcodierung wurden bereits in Abschnitt 5.1 dargestellt – siehe hierfür insbesondere Abschnitt 5.1.6. Von besonderer Bedeutung sind bei VoIP nach H.323 die Audio-Codecs gemäß den Standards G.711 und G.72x (x = 3, 6, 8, 9). Der Typ des Audio-Codec definiert das Format der übertragenen Sprache und wird als Payload-Typ im RTPHeader angegeben (s. Abschnitt 5.3.2). Für H.323-Terminals ist ein Audio-Codec gemäß G.711 als Minimalkonfiguration vorgesehen. Weitere Audio-Codecs sind optional und können zusätzlich implementiert sein.
VideoCodecs
www.wiwobooks.com
Bei der Videokommunikation nach H.323 kommen diverse Codierungsverfahren in Frage. Hier werden u.a. die Video-Codecs nach den ITU-T-Standards H.261 und H.263 verwendet. Sofern die Videokommunikation unterstützt wird, ist das Video-Codec nach H.261 mit dem Bildformat QCIF (Quarter Common Intermediate Format) vorgeschrieben. Auch hier sind weitere Codecs (z.B. H.263 mit allen Bildformaten) möglich. In der Regel werden die Audio- und Video-Codecs auf Audio/Video-Adapterkarten untergebracht. Die Video- und Audio-Signale werden durch eine am PC angeschlossene analoge Videokamera und ein externes Mikrofon entsprechend zum Audio- und Video-Codec übertragen und dort schließlich codiert. Bei der Ausgabe wird der Audiobitstrom decodiert und als analoges Signal zum Lautsprecher übergeben. Dementsprechend wird der decodierte Videobitstrom zum Bildschirm übergeben.
Aushandeln des CodecTyps
Da Sender und Empfänger – abhängig von der jeweiligen Implementierung – ggf. über unterschiedliche Audio- und Video-Codecs verfügen können, müssen sie sich vor dem Aufbau einer Verbindung über den zu verwendenden CodecTyp und damit auf das Audio- und Videocodierungsverfahren einigen. Der Codec-Typ wird beim Aufbau einer VoIP-Session zwischen Quell- und ZielTerminal ausgehandelt. Diesen Vorgang bezeichnet man als Capability Exchange (s. Abschnitt 6.5.2).
6.1 Systemkomponenten nach H.323
229
6.1.4 Arten von Kanälen bei der Multimedia-Kommunikation Um Echtzeitmedien in IP-Netzen zu übertragen, sind unterschiedliche Arten von virtuellen Kanälen bzw. Verbindungen nötig. Abbildung 6.1-4 illustriert dies. T e rm in a l A F ü r R A S -S te u e ru n g n a c h H .2 2 5 .0
IP -N e tz R A S -K a n a l
G a te k e e p e r
T e rm in a l B
R A S -K a n a l
A u fb a u e in e s A n ru f-S IG -K a n a ls F ü r A n ru fs ig n a lis ie r u n g n a c h H .2 2 5 .0 F ü r K a n a ls te u e ru n g n a c h H .2 4 5
T C P -V e rb in d u n g a ls A n ru f-S IG -K a n a l A u f b a u e in e s H .2 4 5 - S te u e r u n g s k a n a ls H .2 4 5 - S te u e r u n g s k a n a l A u fb a u R T P - u n d R T C P -K a n ä le A u d io /V id e o -K o m m u n ik a tio n n a c h R T P /R T C P
www.wiwobooks.com A b b a u R T P - u n d R T C P -K a n ä le
A b b a u d e s H .2 4 5 - S te u e r u n g s k a n a ls H .2 4 5 - S te u e r u n g s k a n a l A b b a u d e s A n ru f-S IG -K a n a ls A n ru f-S IG -K a n a l
Abb. 6.1-4: Arten von Kanälen bei der Audio/Video-Übermittlung RAS: Registration, Admission and Status, SIG: SIGnalisierung
Jedes Terminal einer H.323-Zone (vgl. Abbildung 6.1-1) muss bei einem Gatekeeper registriert sein (sog. Registration), bevor es eine Verbindung initiiert. Zwischen Terminal und Gatekeeper wird somit eine „Beziehung“ für die Übermittlung der RAS-Steuerung aufgebaut, die man als RAS-Kanal bezeichnet. Beispielsweise wird eine neue Verbindung und damit die für sie benötigte Bandbreite vom Quellrechner beim Gatekeeper über den RAS-Kanal angemeldet (sog. Admission).
RAS-Kanal zwischen Terminal und Gatekeeper
Um eine Verbindung für die Übermittlung von Echtzeitmedien aufbauen zu können, ist ein Kanal für die Übermittlung der Signalisierung notwendig (wie z.B. der D-Kanal im ISDN). Ein solcher Kanal lässt sich als Anrufsignalisierungskanal (kurz Anruf-SIG-Kanal) ansehen. Als Anruf-SIG-Kanal dient eine TCP-Verbindung zwischen H.225.0-Signalisierungsinstanzen in kommunizie-
TCPVerbindung als AnrufSIG-Kanal
230
6
VoIP nach dem Standard H.323
renden Rechnern. Ein Anruf-SIG-Kanal kann auch als Meta-Signalisierungskanal interpretiert werden. Nutzung des H.245Steuerungskanals
Über einen Anruf-SIG-Kanal werden die Nachrichten nach H.225.0 übertragen, um einen H.245-Steuerungskanal zwischen zwei Terminals einzurichten. Über den H.245-Steuerungskanal werden dann die H.245-Nachrichten übermittelt, um entsprechende logische Kanäle für die Audio-, Video- bzw. Datenübermittlung auf- und abzubauen.
Voraussetzung für bidirektionale Kommunikation
Weil die Übermittlung von Audio und Video mit Hilfe des Protokolls RTP erfolgt, spricht man von einem RTP-Kanal (s. Abb. 5.2-1). Ein RTP-Kanal kann als Nutzlastkanal angesehen werden und entspricht dem B-Kanal im ISDN. Über einen RTP-Kanal kann – bei H.323 – die Übermittlung von Audio bzw. Video nur in einer Richtung stattfinden. Der RTP-Kanal ist somit unidirektional (halbduplex). Für eine bidirektionale (vollduplex) Audiokommunikation müssen zwei unidirektionale RTP-Kanäle eingerichtet werden, die einen bidirektionalen RTP-Kanal bilden (s. Abb. 6.5-5).
Bedeutung des RTCPKanals
Parallel zur Übermittlung von Audio bzw. Video muss ein bidirektionaler Kanal zur Kontrolle dieser Übermittlung eingerichtet werden. Man spricht hierbei vom RTCP-Kanal. Zwischen zwei Terminals müssen somit mehrere logische Kanäle aufgebaut werden (vgl. Abb. 6.5 -5).
Wechsel der Codierung
Über einen H.245-Steuerungskanal werden ebenfalls die Kompatibilitätsangaben zwischen zwei Terminals ausgetauscht, um die einzusetzenden Audiobzw. Video-Codecs, d.h. die Audio- und Videoformate zu bestimmen und auszuwählen. Mit Hilfe des H.245-Steuerungskanals ist es z.B. möglich, während einer bestehenden Sprachverbindung in beiden Terminals das Prinzip der Sprachcodierung zu wechseln. Diese Möglichkeit entspricht dem ISDN-Dienstmerkmal „Dienstwechsel während einer bestehenden Verbindung“.
Abbau der Kanäle
Nach dem Ablauf einer Audio- bzw. Video-Kommunikation müssen die entsprechenden Kanäle abgebaut werden. Zuerst werden die logischen RTP- und RTCP-Kanäle abgebaut, danach der H.245-Steuerungskanal. Zum Schluss wird der Anruf-SIG-Kanal, d.h. die noch bestehende TCP-Verbindung, abgebaut.
www.wiwobooks.com
6.2 H.225.0 und H.245 als H.323-SIG
Signalisierung nach H.323
Die Übermittlung entsprechender Nachrichten, um logische RTP-Kanäle für die Audio- und Videokommunikation auf- und abbauen zu können, bezeichnet man als Signalisierung. Wie bereits in Abschnitt 6.1 dargestellt, kann man die beiden Protokolle H.225.0 und H.245 als H.323-Signalisierungsprotokolle ansehen. Wie Abbildung 6.1-4 zeigt, wird zunächst eine TCP-Verbindung aufgebaut, die als Anruf-SIG-Kanal dient, um die H.225.0-Nachrichten zu übermitteln. Nach dem Protokoll H.225.0 wird dann ein H.245-Steuerungskanal auf-
6.2 Signalisierung nach H.323
231
gebaut, über den die H.245-Nachrichten übermittelt werden, um die logischen RTP- und RTCP-Kanäle aufzubauen. Um die vor der Audio/Video-Übermittlung notwendigen Schritte zu reduzieren, wurde die sog. Fast Connect Procedure bereits bei H.323 Version 2 (1998) eingeführt. Mit ihr können einige H.245-Nachrichten in den H.225.0-Nachrichten übermittelt werden. Damit lassen sich logische RTP- und RTCP-Kanäle einrichten, ohne vorher einen H.245-Steuerungskanal aufbauen zu müssen.
Bedeutung der Fast Connect Procedure
6.2.1 Schritte vor der Audio/Video-Übermittlung Die Schritte, die vor der Audio/Video-Übermittlung über ein IP-Netz zwischen zwei Terminals A und B notwendig sind, illustriert Abbildung 6.2-1. Hier wurde angenommen, dass die Terminals bereits beim Gatekeeper registriert sind. IP -N e tz
T e rm in a l A In itiie re n
G a te k e e p e r A R Q
V e rb in d u n g s z u la s s u n g 1
T e rm in a l B
A C F
www.wiwobooks.com A u fb a u e in e s A n ru f-S IG -K a n a ls
2
3
is s io n u e st is s io n irm a tio n
C a ll P ro c e e d in g 4 A R Q A C F A le rtin g 6 C o n n e c t 7 H .2 4 5 - S te u e r u n g s k a n a l
V e rb in d u n g s z u la s s u n g 5
F re ito n
A R Q : A d m R e Q A C F : A d m C o n F
S e tu p
8
E s k lin g e lt A n ru f w u rd e a n g e n o m m e n
A u fb a u d e r R T P - u n d R T C P -K a n ä le A u d io /V id e o -Ü b e rm ittlu n g n a c h R T P /R T C P
Abb. 6.2-1: Schritte vor der Audio/Video-Übermittlung
Folgende Schritte sind zu unterscheiden:
Zulassung 1. Jede abgehende Verbindung, falls keine pre-granted Admission vorliegt, abgehender Verbindung
muss vom Gatekeeper zugelassen werden (sog. Admission), um den Verbrauch der Bandbreite zu kontrollieren. Hier wird die benötigte Bandbreite für die Übermittlung in die Richtung zum Terminal B beim Gatekeeper in ARQ (Admission ReQuest) angemeldet und von ihm in ACF (Admission ConFirmation) bestätigt bzw. eine niedrigere Bandbreite angeboten oder abgewiesen. Die Kommunikation zwischen Terminal und Gatekeeper – sog. RAS-Control – erfolgt mit Hilfe des Protokolls UDP (s. Abb. 6.1-3).
232 Aufbau eines Anruf-SIGKanals
6
VoIP nach dem Standard H.323
2. Wie aus Abbildung 6.1-3 ersichtlich ist, wird für die Übertragung der Signalisierung nach H.225.0 das zuverlässige Transportprotokoll TCP eingesetzt. Zwischen den Terminals A und B wird eine TCP-Verbindung aufgebaut, die als Anruf-SIG-Kanal (Call Signalling Channel) dient. 3. Das Terminal A initiiert den Aufbau des H.245-Steuerungskanals mit der H.225.0-Nachricht Setup. 4. Setup wird vom Terminal B mit Call Proceeding bestätigt.
Zulassung ankommender Verbindungen
5. Um den Verbrauch der Bandbreite im IP-Netz zu kontrollieren, muss das „angerufene“ Terminal beim Gatekeeper anfragen, ob der ankommende Anruf angenommen werden darf. Somit muss auch die ankommende Verbindung vom Gatekeeper zugelassen werden. Hierfür sendet das Terminal B zum Gatekeeper ARQ, und dieser bestätigt die Zulassung der Verbindung mit ACF. Bei der Zulassung kann das Terminal A auch beim Gatekeeper abfragen, welche IP-Adresse das Terminal B hat (s. Abschnitt 6.3.3).
Prüfung der Kompatibilität
6. Falls die ankommende Verbindung vom Gatekeeper zugelassen wurde, prüft das Terminal B, ob die beiden Terminals kompatibel sind. Hierbei wird geprüft, ob die Kommunikation zustande kommen kann, d.h., ob die beiden Terminals ein gleiches Audio- bzw. Video-Format unterstützen. Ist dies der Fall, bestätigt dies das Terminal B mit der H.225.0-Nachricht Alerting. Der ankommende Anruf wird beim Terminal B z.B. durch das Klingeln signalisiert.
www.wiwobooks.com
7. Der Anruf wurde angenommen. Dies bestätigt Terminal B mit der H.225.0Nachricht Connect. Damit wurde ein H.245-Steuerungskanal aufgebaut und muss nun im Terminal A entsprechend angezeigt werden. 8. Mit der Signalisierung nach H.245 werden die entsprechenden logischen RTP- und RTCP-Kanäle für die Übermittlung von Echtzeitmedien aufgebaut (vgl. Abb. 6.5-5). Diese Kanäle bezeichnet man als Medienkanäle. H.225.0 als D-KanalProtokoll über TCP
Bemerkung: Die Schritte 3, 4, 6 und 7 in Abbildung 6.2-1 entsprechen vollkommen dem Verlauf des D-Kanal-Protokolls beim Aufbau einer ISDN-Verbindung (s. Abb. 2.3-3). Somit könnte man das Protokoll H.225.0 als D-Kanal-Protokoll über TCP-Verbindungen ansehen – genauer gesagt als Schicht 3 des D-KanalProtokolls über TCP-Verbindungen. Die Schicht 2 des D-Kanal-Protokolls (s. Abb. 2.3-1), die u.a. zuverlässige Übermittlung von Schicht-3-Nachrichten garantiert, wird bei H.225.0 durch das zuverlässige Transportprotokoll TCP ersetzt.
6.2.2 Schritte nach der Audio/Video-Übermittlung Nach der Übermittlung von Audio und Video müssen entsprechende Steuerungs- und Medienkanäle abgebaut werden. Wie Abbildung 6.2-2 zeigt, sind folgende Schritte nach der Audio/Video-Übertragung zu unterscheiden:
6.2 Signalisierung nach H.323
233
1. Nach der Audio/Video-Übermittlung müssen zuerst die Medienkanäle, d.h. Abbau der die RTP- und RTCP-Kanäle, abgebaut werden. Dies erfolgt mit Hilfe von MedienH.245-Nachrichten CloseLogicalChannel und CloseLogical Chan- kanäle nelAck. Näheres dazu enthält Abschnitt 6.5.5.
IP -N e tz
G a te k e e p e r
T e rm in a l A A u d io /V id e o -Ü b e rm ittlu n g 1
T e rm in a l B
A b b a u d e r M e d ie n k a n ä le 2
A b b a u d e s H .2 4 5 - S te u e r u n g s k a n a ls H .2 4 5 - S te u e r u n g s k a n a l
3
A b b a u d e s A n ru f-S IG -K a n a ls A n ru f-S IG -K a n a l
V e rb in d u n g s a b m e ld u n g 4 D R Q : D is e n g a g e R e Q u e s t
D R Q
D C F
D C F
D R Q
D C F : D is e n g a g e C o n F irm a tio n
www.wiwobooks.com
Abb. 6.2-2: Schritte nach der Audio/Video-Übertragung
2. Erst nach dem Abbau der Medienkanäle kann der H.245-Steuerungskanal abgebaut werden. Hierfür verwendet man die H.225.0-Nachricht Release Complete. Weitere Informationen über den Abbau des H.245-Steuerungskanals enthält Abschnitt 6.4 (vgl. Abb. 6.4-2, -3 und -4).
Abbau des H.245Steuerungskanals
3. Nach dem Abbau des H.245-Steuerungskanals erfolgt der Abbau des An- Abbau des ruf-SIG-Kanals (d.h. des H.225.0-Kanals). Da der Anruf-SIG-Kanal eine Anruf-SIGTCP-Verbindung darstellt, wird er nach dem gleichen Prinzip wie jede an- Kanals dere TCP-Verbindung abgebaut. 4. Wurden alle Medien- und Steuerungskanäle abgebaut, müssen die beiden Abmeldung Terminals A und B dies ihren Gatekeepern anmelden. Damit wird die ab- der Verbingebaute Audio- bzw. Videoverbindung beim Gatekeeper abgemeldet und dung die reservierte Bandbreite wieder freigegeben. Hierfür wird von jedem Terminal die Nachricht DRQ gesendet. Der Gatekeeper quittiert sie mit ACF, was mit Hilfe des Protokolls UDP erfolgt.
6.2.3 Fast Connect Procedure Wie bereits in Abbildung 6.1-4 dargestellt, müssen mehrere Arten von logischen Kanälen für Audio- bzw. Videokommunikation eingerichtet werden. Ein Anruf-SIG-Kanal ist notwendig, um eine Kommunikation nach H.225.0 zu ini-
234
6
VoIP nach dem Standard H.323
tiieren. Um die Anzahl der Schritte vor der Audio/Video-Übermittlung zu reduzieren, könnte man den Anruf-SIG-Kanal so nutzen, dass die Medienkanäle – d.h. RTP- und RTCP-Kanäle – auch über diesen Kanal aufgebaut werden. Damit könnte man auf den Aufbau des H.245-Steuerungskanals verzichten. Idee der Fast Connect Procedure
Es entsteht hierbei aber noch ein Problem. Der H.245-Steuerungskanal sollte die ganze Zeit während der Kommunikation verfügbar sein, damit die kommunizierenden Terminals parallel zur Übermittlung der Echtzeitmedien bestimmte Steuerungen austauschen können. Um dies auch ohne den H.245-Steuerungskanal zu garantieren, könnte man einige H.245-Nachrichten in die H.225.0Nachrichten einkapseln und sie über den Anruf-SIG-Kanal übermitteln.
Schritte beim FCP-Einsatz
Der eben geschilderten Idee liegt die sog. Fast Connect Procedure (FCP) zugrunde. Abbildung 6.2-3 illustriert ihren Einsatz (vgl. auch Abb. 6.2-4).
IP -N e tz T e rm in a l A 1
A u fb a u e in e s A n ru f-S IG -K a n a ls
T e rm in a l B
T C P -V e rb in d u n g a ls A n ru f-S IG -K a n a l 2
F C P : A u fb a u R T P - u n d R T C P -K a n ä le
www.wiwobooks.com A u d io /V id e o -Ü b e rm ittlu n g n a c h R T P /R T C P
3
4 5
F C P : A b b a u R T P - u n d R T C P -K a n ä le A b b a u d e s A n ru f-S IG -K a n a ls A n ru f-S IG -K a n a l
Abb. 6.2-3: Phasen bei der Audio/Video-Übermittlung mit der Fast Connect Procedure (FCP)
Hierbei sind die folgenden Schritte zu unterscheiden: 1. Aufbau eines Anrufsignalisierungskanals (Anruf-SIG-Kanals) – Hierzu dient eine TCP-Verbindung, über die die H.225-Nachrichten übermittelt werden. 2. Aufbau der RTP- und RTCP-Kanäle nach der FCP – Hierfür werden die H.225.0-Nachrichten um entsprechende Elemente des Protokolls H.245 erweitert und über den Anruf-SIG-Kanal übermittelt. 3. Audio/Video-Übermittlung mit Hilfe von RTP und RTCP – Falls einige Steuerungsangaben nach dem Protokoll H.245 zwischen den kommunizierenden Terminals ausgetauscht werden müssen, werden die entsprechenden H.245-Nachrichten in die H.225.0-Nachrichten eingekapselt und dann übermittelt. Dies bezeichnet man als H.245-Tunneling.
6.2 Signalisierung nach H.323
235
4. Abbau der RTP- und RTCP-Kanäle nach der FCP – Wie im Schritt 2 werden hierfür die H.225.0-Nachrichten um entsprechende Elemente des Protokolls H.245 erweitert und über den Anruf-SIG-Kanal übermittelt. 5. Abbau des Anruf-SIG-Kanals – Dies stellt den Abbau einer TCP-Verbindung dar. Durch den FCP-Einsatz reduziert sich die für den Aufbau der Medienkanäle Ablauf der benötigte Zeit. FCP wird bereits ab der H.323v2 (1998) unterstützt. Abbildung Fast Connect Procedure 6.2-4 illustriert den FCP-Ablauf. IP -N e tz T e rm in a l A
G a te k e e p e r
V e rb in d u n g s z u la s s u n g
T e rm in a l B
A u fb a u e in e s A n ru f-S IG -K a n a ls
1
S e tu p [ f a s tS ta r t ( O L C A , O L C V ) , m e d ia W a itF o r C o n n e c t = T R U E , ...] C a ll P ro c e e d in g 2 V e rb in d u n g s z u la s s u n g A le r tin g [ f a s tS ta r t ( O L C A , O L C V ) , ...] C o n n e c t [ f a s tS ta r t ( O L C A , O L C V ) , ...]
3 4
www.wiwobooks.com A u d io /V id e o -Ü b e rm ittlu n g n a c h R T P /R T C P
5
R e le a s e C o m p le te
A b b a u e in e s A n ru f-S IG -K a n a ls V e rb in d u n g s a b m e ld u n g
V e rb in d u n g s a b m e ld u n g
Abb. 6.2-4: Fast Connect Procedure (FCP) – H.245-Nachrichten in H.225.0-Nachrichten OLC: Open Logical Channel, OLCA: OLC für Audio, OLCV: OLC für Video
Hierbei wurde vorausgesetzt, dass die Terminals A und B bereits beim Gatekeeper registriert sind. Nach der Zulassung der durch das Terminal A initiierten Verbindung vom Gatekeeper und nach dem Aufbau eines Anruf-SIG-Kanals, der eine TCP-Verbindung darstellt, sind folgende Schritte zu unterscheiden: 1. Das Terminal A sendet eine H.225.0-Nachricht Setup, in der die FCP als Angabe fastStart angezeigt wird. Mit mediaWaitForConnect = TRUE wird darauf hingewiesen, dass die Übermittlung von Audio bzw. Video erst nach der Nachricht Connect beginnen darf. Im Element fastStart wird mit OLCA und OLCV angegeben, welche logischen Medienkanäle (d.h. RTP- und RTCP Kanäle) entsprechend für Audio bzw. Video eingerichtet werden sollen. In OLCA und OLCV werden die Portnummern der RTP- und RTCP-Kanäle beim Terminal A angegeben (vgl. Abb. 6.5-5).
236
6
VoIP nach dem Standard H.323
2. Das angerufene Terminal B antwortet mit der H.225.0-Nachricht Call Proceeding und meldet die ankommende Verbindung beim Gatekeeper an, die dieser dann zulässt. 3. Die beiden Terminals sind kompatibel, sodass der ankommende Anruf angenommen werden kann. Dies bestätigt das Terminal B mit Alerting. Hier bestätigt das Terminal B mit OLCA und OLCV im Element fastStart auch, dass die RTP- und RTCP-Kanäle eingerichtet wurden. Zusätzlich teilt Terminal B ihre Portnummern in OLCA und OLCV mit. Die Medienkanäle stehen also bereits zur Verfügung. Aufgrund der Angabe mediaWaitForConnect = TRUE in Setup kann die Übermittlung von Medien erst nach dem Eintreffen der Nachricht Connect beim Terminal A beginnen. Dies ist die Voraussetzung, um mit der Signalisierung im ISDN konform zu sein (z.B. bei der Integration von VoIP mit ISDN). 4. Terminal B hat den Anruf angenommen und bestätigt dies mit Connect. Diese Nachricht übermittelt noch einmal das Element fastStart mit OLCA und OLCV. Nach dem Empfang von Connect beginnt Terminal A die Übermittlung von Audio und Video nach RTP und RTCP. 5. Abbau logischer RTP- und RTCP-Kanäle und Initiieren des Abbaus des Anruf-SIG-Kanals: Dies erfolgt durch das Absenden der H.225.0-Nachricht Release Complete. Danach wird noch der Anruf-SIG-Kanal, d.h. eine TCP-Verbindung, abgebaut und die abgebaute Audio- bzw. Videoverbindung von beiden Terminals beim Gatekeeper abgemeldet.
www.wiwobooks.com
6.3
Realisierung von RAS-Funktionen
Endsystem = Endpunkt
Der Gatekeeper einer Zone ist dafür zuständig, sämtliche Endsysteme oder Endpunkte (wie Terminals, Gateways) seiner Zone zu verwalten. Die Kommunikation zwischen Endpunkten und Gatekeeper erfolgt nach einem Protokoll, das man RAS (Registration, Admission and Status) nennt. Für RAS definiert H.225.0 unterschiedliche Nachrichten, die zwischen Endpunkten und Gatekeeper mit Hilfe des verbindungslosen Transportprotokolls UDP übermittelt werden (vgl. Abb. 6.1-3). In diesem Zusammenhang spricht man von einem verbindungslosen RAS-Kanal zwischen Endpunkt und Gatekeeper.
RASFunktionen
Das Protokoll RAS umfasst u.a. folgende Funktionen: Gatekeeper-Entdeckung (Gatekeeper Discovery); Registrierung und Deregistrierung beim Gatekeeper; Zulassung von Verbindungen (Admission), Änderung und Freigabe der reservierten Bandbreite;
6.3 Realisierung von RAS-Funktionen
237
Abfrage der IP-Adresse eines Endpunktes (Location). Die Kommunikation zwischen Endpunkten und Gatekeeper verläuft nach H.225.0H.225.0. Hierfür definiert H.225.0 bestimmte RAS-Nachrichten. Unter ihnen Nachrichten für RAS lassen sich die folgenden drei Typen unterscheiden: Request(RQ)als Anforderung, Confirm(CF)als positive Bestätigung und Reject(RJ)als Ablehnung.
Die RAS-Nachrichten werden mit Hilfe von ASN.1 (Abstract Syntax Notation No. 1, s. [Gora 98]) spezifiziert. ASN.1 dient als Sprache für die Beschreibung von Nachrichten der Protokolle in den Telekommunikationssystemen.
6.3.1 Gatekeeper-Entdeckung Innerhalb einer Zone können mehrere Gatekeeper eingesetzt werden, um die Ausfallsicherheit zu erhöhen. Jeder Endpunkt einer Zone wird von einem Gatekeeper dieser Zone verwaltet. Somit muss jeder neue Endpunkt bei einem Gatekeeper registriert werden. Hierfür muss zuerst ermittelt werden, welcher Gatekeeper für die Verwaltung des neuen Endpunktes zuständig ist. Jeder neue Endpunkt muss somit seinen Gatekeeper entdecken (auffinden). Abbildung 6.3-1 illustriert die Gatekeeper-Entdeckung.
www.wiwobooks.com
E n d p u n k t
IP -N e tz ( H .3 2 3 - Z o n e ) G R Q
G C F
G K
G K 1
Endpunkt muss beim Gatekeeper registriert werden
2
G R J
Abb. 6.3-1: Entdeckung des zuständigen Gatekeeper (GK)
Um den Gatekeeper zu entdecken, sendet ein Endpunkt eine Multicast-Nach- Alternate richt GatekeeperRequest(GRQ), in welcher er nach der IP-Adresse des Gate- Gatekeeper keepers fragt. Das IP-Paket mit GRQ enthält die Multicast-Adresse 224.0.1.41 als IP-Zieladresse und die Nummer 1718 des Zielports als Well-Known-PortNumber für die Gatekeeper-Entdeckung. Ein oder mehrere Gatekeeper können mit einer Nachricht GatekeeperConfirmation (GCF) antworten, in der sie dem Endpunkt ihre Bereitschaft signalisieren, als dessen Gatekeeper zu fungieren. Das IP-Paket mit GCF enthält die IP-Adresse des Gatekeepers und die PortNummer des RAS-Kanals als Parameter rasAddress. Somit verfügt der neue Endpunkt über die notwendigen Angaben für die Registrierung. In GCF kann
238
6
VoIP nach dem Standard H.323
der Gatekeeper als Angabe alternateGatekeeper eine Liste von alternativen Gatekeepern übermitteln, die das Terminal im Falle eines Ausfalls in Anspruch nehmen kann. Diese Option wird als Alternate Gatekeeper bezeichnet. Der Gatekeeper, der für den Endpunkt nicht zuständig ist, antwortet mit GatekeeperReject (GRJ). Falls mehrere Gatekeeper auf die Anfrage antworten, steht es dem Endpunkt frei, für welchen er sich entscheidet. Assigned Gatekeeper
In H.323 der Version 6 (2006) wurde Assigned Gatekeeper als Erweiterung des Konzepts von Alternate Gatekeeper eingeführt. Ein Assigned Gatekeeper – falls mehrere Gatekeepers redundant eingesetzt werden – wird einer Gruppe von Endpunkten zugeordnet (assigned). Ermittelt ein Endpunkt einen Gatekeeper, sollte er zur Registrierung die im Feld assignedGatekeeper der Antwort GCF ihm mitgeteilte IP-Adresse von Assigned Gatekeeper „nehmen“. Auf diese Weise erfährt der Endpunkt seinen Assigned Gatekeeper. Sollte der Assigned Gatekeeper ausfallen, kann der Endpunkt einen Alternate Gatekeeper in Anspruch nehmen.
Weitere Möglichkeiten der GatekeeperErmittlung
Weil IP-Multicast auf ein Subnetz beschränkt ist, lässt sich das Auffinden des zuständigen Gatekeepers in der Praxis so realisieren, dass man einem Rechner, der als IP-Telefon dienen soll, die IP-Adresse eines Konfigurationsservers angibt, bei dem er sich die IP-Adresse des Gatekeepers abrufen kann.
www.wiwobooks.com
Es besteht auch die Möglichkeit, eine DNS-Domain als Zone zu betrachten. Dem Gatekeeper z.B. der Domain abc.de kann man den sog. H.323 URL (Uniform Resource Locator) in der Form [email protected] zuordnen und diesen in einem IP-Telefon eintragen, damit es sich selbst die IP-Adresse des Gatekeepers mit Hilfe einer DNS-Abfrage abruft. Diese auf den gleichen Prinzipien wie die Ermittlung eines SIP-Proxy basierende Möglichkeit (s. Abschnitt 3.5.4), beschreibt der Annex O zu H.323 der Version 5. In kleinen Netzwerken trägt man oft den Hostnamen (im DNS-Sinne) bzw. die IP-Adresse eines Gatekeepers in einem IP-Telefon bei Konfiguration ein.
6.3.2 Registrierung und Deregistrierung beim Gatekeeper Ziel der Registrierung
Die Registrierung beim Gatekeeper ist der Prozess, in dessen Verlauf ein neuer Endpunkt einer Zone den Gatekeeper über seine Adresse für Audio- und Videokommunikation informiert. Sie wird bei H.323 als Alias-Adresse bezeichnet. Da jedes IP-Telefon über eine Telefonnummer bzw. eine Alias-Adresse – in der Form [email protected] – verfügen muss, handelt es sich hierbei um die Bekanntgabe seiner Alias-Adresse.
Registrierung
Abbildung 6.3-2a illustriert die Registrierung. Ein Endpunkt sendet eine Nachricht RegistrationRequest(RRQ) an den UDP-Port 1719 (als WellKnown-Port für die Registrierung) im Gatekeeper mit der Angabe seiner Alias-
6.3 Realisierung von RAS-Funktionen
239
Adresse als Parameter callSignalAddress. Der Gatekeeper muss bei der Registrierung die Alias-Adresse des Endpunktes seiner IP-Adresse zuordnen und dies in einer speziellen Tabelle mit den Zuordnungen Alias-Adresse IP-Adresse eintragen. Dieser Eintrag kann während der Deregistrierung bzw. nach dem Ablauf der Zeit timeToLive gelöscht werden. IP -N e tz ( H .3 2 3 - Z o n e )
E n d p u n k t a ) b )
R R Q U R Q
R C F o d e r R R J U C F o d e r U R J
G K R e g is trie ru n g D e re g is trie ru n g
Abb. 6.3-2: Ablauf: a) der Registrierung; b) der Deregistrierung
In RRQ informiert der Endpunkt den Gatekeeper mit dem Parameter: terminalType – um welchen Endpunkt (z.B. Terminal, Multipoint Con-
trol Unit, Gateway, ...) es sich handelt; timeToLive – wie lange (in [sec]) die Registrierung gültig sein soll.
www.wiwobooks.com
Der Gatekeeper kann entweder mit RegistrationConfirm (RCF) die Registrierung annehmen oder sie mit RegistrationReject(RRJ) ablehnen. Mit dem Parameter rejectReason in RRJ teilt er den Ablehnungsgrund mit. Wurde der Endpunkt registriert, kann der Gatekeeper mit preGrantedARQ in RCF dem Endpunkt mitteilen, wann er die Verbindungen ohne Zulassung seitens des Gatekeepers initiieren bzw. annehmen darf. Der Gatekeeper kann mit alternateGatekeeper in RCF eine Liste von alternativen Gatekeepern übermitteln, die das Terminal in Anspruch nehmen kann, falls er ausfallen sollte. Wie Abbildung 6.3-2b zeigt, kann sich ein Endpunkt beim Gatekeeper durch DeregistrieAbsenden von UnregistrationRequest(URQ) deregistrieren (abmelden). rung Der Gatekeeper kann die Deregistrierung entweder mit UnregistrationConfirm (UCF) bestätigen oder mit UnregistrationReject(URJ) ablehnen. In URJ kann der Gatekeeper eventuell mit der Angabe altGKInfo auf einen alternativen Gatekeeper verweisen.
6.3.3 Zulassung von Verbindungen Jeder Endpunkt darf nur dann eine abgehende Verbindung für Audio- bzw. Videokommunikation initiieren bzw. eine ankommende Verbindung annehmen, wenn der Gatekeeper dies zulässt (Admission). Damit kann der Verbrauch
240
6
VoIP nach dem Standard H.323
der Übertragungskapazität (Bandbreite) im IP-Netz vom Gatekeeper kontrolliert werden. Nach dem Ablauf der Kommunikation muss eine abgebaute Verbindung beim Gatekeeper abgemeldet werden, sodass er die reservierte Bandbreite für andere Verbindungen freigeben kann. Abbildung 6.3-3 zeigt die Zulassung einer Verbindung für Audio- bzw. Videokommunikation und Freigabe der reservierten Bandbreite nach dem Abbau der Verbindung. IP -N e tz ( H .3 2 3 - Z o n e )
E n d p u n k t A A d m is s io n E n d p u n k t A
A R Q S e tu p
A C F
E n d p u n k t B G a te k e e p e r A C F
A R Q
A d m is s io n E n d p u n k t B
F o rts e tz u n g d e s V e rb in d u n g s a u fb a u s V e rla u f d e r K o m m u n ik a tio n V e rb in d u n g s a b b a u D is e n g a g e E n d p u n k t A
D R Q
D C F
D C F
D R Q
D is e n g a g e E n d p u n k t B
A R Q : A d m is s io n R e Q u e s t A C F : A d m is s io n C o n F irm a tio n D R Q : D is e n g a g e R e Q u e s t D C F : D is e n g a g e C o n F irm a tio n
www.wiwobooks.com
Abb. 6.3-3: Funktionen Admission and Disengage
Ablauf der Zulassung einer abgehenden Verbindung
Falls der bereits beim Gatekeeper registrierte Endpunkt A eine abgehende Verbindung für Audio- bzw. Videokommunikation zum Endpunkt B initiieren möchte, muss die benötigte Bandbreite beim Gatekeeper angemeldet und diese neue Verbindung zugelassen werden. Hierfür sendet der Endpunkt A an den Gatekeeper eine Nachricht AdmissionReQuest (ARQ), die u.a. folgende Parameter enthält: destinationInfo: Alias-Adresse (d.h. Telefon-Nr.) des Endpunktes B; bandWidth: Bandbreite (in beide Richtungen) für die Verbindung; canMapAlias als Variable vom Typ BOOLEAN.
Wurde die Verbindung vom Gatekeeper zugelassen, antwortet er mit der Nachricht AdmissionConFirm (ACF), in der er die dem Endpunkt A genehmigte (maximale) Bandbreite als Parameter bandWidth angibt. Abruf der IP-Adresse des Ziels
Falls die Variable canMapAlias in ARQ vom Endpunkt A auf Eins (TRUE) gesetzt wurde, enthält ACF auch die IP-Adresse des Ziels, d.h. des Endpunktes B. IP-Adresse vom Gatekeeper Somit wird die Zuordnung: Telefonnummer durch den Endpunkt A abgerufen, und es kann mit dem Aufbau einer TCPVerbindung zum Endpunkt B für die Übermittlung von H.225.0-Nachrichten begonnen werden.
6.3 Realisierung von RAS-Funktionen
241
Mit dem Parameter callModel in ACF teilt der Gatekeeper dem Endpunkt mit, Bedeutung ob der Verbindungsaufbau ohne Beteiligung des Gatekeepers, d.h. direkt zwi- von callschen den beteiligten Endpunkten, verläuft oder ob der Gatekeeper beim Ver- Model bindungsaufbau beteiligt werden muss. Sollte der Verbindungsaufbau über den Gatekeeper erfolgen, spricht man von über Gatekeeper gerouteten Verbindungen (vgl. Abb. 6.4-4). Wurde die Verbindung vom Gatekeeper nicht zugelassen, antwortet er dem Absage der Terminal mit AdmissionReject (ARJ). Der Grund hierfür wird als Parame- Zulassung ter rejectReason mitgeteilt. Bemerkung: Ein Endpunkt kann in bestimmten Situationen die abgehenden Verbindungen ohne Zulassung (Admission) initiieren bzw. die ankommenden annehmen. Diese Situationen werden während der Registrierung vom Gatekeeper im Feld pregrantedARQ der Nachricht RCF dem Endpunkt bekannt gemacht.
Falls die abgehende Verbindung vom Endpunkt A durch den Gatekeeper zugelassen wurde, initiiert er mit einer H.225.0-Nachricht Setup den Aufbau eines Signalisierungskanals zum Endpunkt B. Beim Endpunkt B handelt es sich um eine ankommende Verbindung vom Endpunkt A. Da die Bandbreite für die Übermittlung in Richtung zum Endpunkt A auch durch den Gatekeeper überwacht wird, muss die Verbindung seitens des Endpunktes B auch vom Gatekeeper zugelassen werden. Dies erfolgt nach dem gleichen Prinzip, wie dies beim Endpunkt A der Fall ist.
Zulassung einer ankommenden Verbindung
www.wiwobooks.com
Das Ende der Audio- bzw. Videokommunikation und der Abbau der Verbin- Ablauf von dung müssen dem Gatekeeper mitgeteilt werden, um die reservierte Bandbreite Disengage freigeben zu können. Hierbei spricht man von Disengage. Die beiden Endpunkte signalisieren dem Gatekeeper mit DisengageRequest (DRQ), dass die Verbindung bereits abgebaut wurde. Die Nachricht DRQ bestätigt der Gatekeeper mit DisengageConfirm (DCF). Bemerkung: Empfängt ein Gatekeeper z.B. eine Nachricht DRQ von einem unregistrierten Endpunkt, so antwortet er mit DisengageReject (DRJ).
Ein Endpunkt kann mit einer Nachricht BandwidthRequest (BRQ) beim Gate- Änderung keeper eine Änderung (z.B. eine Ausweitung) der ihm genehmigten Bandbreite der Bandfür eine Verbindung anfordern. Der neue Wert der Bandbreite wird als Para- breite meter bandWidth angegeben. Die Änderung der Bandbreite kann vom Gatekeeper mit BandwidthConfirm (BCF) bestätigt oder mit BandwidthReject (BRJ) abgelehnt werden.
6.3.4 Abfrage der IP-Adresse eines Endpunktes Eine der Aufgaben jedes Gatekeepers besteht in der Verwaltung einer Tabelle IP-Adresse. Die Abfrage der IPmit der Zuordnung Alias-Adresse
242
6
VoIP nach dem Standard H.323
Adresse eines Endpunktes wird bei H.225.0 als Location-Prozess bezeichnet. Abbildung 6.3-4 veranschaulicht die Bedeutung dieses Prozesses. H .3 2 3 - D o m a in
E P A
Z o n e 1
G K A R Q
A C F
T ra n s itIP -N e tz
R 1
L R Q
R
Z o n e 2
G K
E P B
2
L C F
Abb. 6.3-4: Verlauf eines Location-Prozesses – Abfrage des Gatekeepers einer fremden Zone EP: EndPunkt, GK: Gatekeeper, R: Router
Abfrage beim Gatekeeper einer fremden Zone
Hier fragt der Endpunkt A seinen Gatekeeper GK1 nach der IP-Adresse des Endpunktes B, d.h. seines Kommunikationspartners, bereits bei der Anmeldung der zu initiierenden Verbindung mit der Nachricht ARQ ab (vgl. Abb. 6.3-3). Befindet sich der Endpunkt B aber in einer anderen (H.323-)Zone, so muss GK1 die IP-Adresse des Endpunktes B vom Gatekeeper dieser Zone abfragen. Hierfür definiert H.225.0 entsprechende Nachrichten (s. Abb. 9.4-1). Wie Abbildung 6.3-4 zeigt, sendet der GK1 der Zone 1 an den GK2 der fremden Zone 2 die Nachricht LocationRequest (LRQ), in der er die Alias-Adresse des Endpunktes B angibt und nach seiner IP-Adresse fragt. Der GK2 antwortet normalerweise mit LocationConfirm (LCF), in der die gewünschte IP-Adresse enthalten ist. Falls der GK2 die gewünschte IP-Adresse nicht liefern kann, antwortet er mit LocationReject (LRJ).
www.wiwobooks.com
6.4 Was ist H.225.0?
Signalisierung der Anrufe nach H.225.0
Um eine Verbindung zwischen zwei Endpunkten für die Übermittlung von Echtzeitmedien (Audio/Sprache, Video) aufbauen zu können, werden zwei Signalisierungsprotokolle H.225.0 und H.245 als H.323-Signalisierung (kurz H.323-SIG) verwendet (vgl. Abb. 6.1-4). H.225.0 definiert ein Anruf-Signalisierungs-Protokoll (Anruf-SIG-Protokoll), nach dem der H.245-Kanal auf- und abgebaut wird. Über den H.245-Kanal werden logische RTP- und RTCPKanäle für die Audio/Video-Kommunikation eingerichtet. H.225.0 nutzt einige Nachrichten des D-Kanal-Protokolls Q.930/Q931 vom ISDN (s. Abschnitt 2.3). Bei H.225.0 handelt es sich im Prinzip um eine Realisierung des D-KanalProtokolls über TCP-Verbindungen.
6.4 Signalisierung der Anrufe nach H.225.0
243
6.4.1 Struktur von Anruf-SIG-Nachrichten beim H.225.0 Als Anruf-SIG-Nachrichten beim H.225.0 werden die Q.931-Nachrichten in erweiterter Form verwendet. Abbildung 6.4-1 zeigt, wie die Anruf-SIG-Nachrichten strukturiert sind und wie sie in IP-Paketen übermittelt werden. T P K T IP
T C P T P K T -H
T P D U H .2 2 5 .0 - S I G - N a c h r ic h t Q .9 3 1 N a c h r ic h t IE s
T P K T -ID (= 3 ) R e se rv e d (= 0 ) P a c k e t L e n g th
U U IE s
P ro to c o l d is c rim in a to r C a ll re fe re n c e M e s s a g e ty p e
Abb. 6.4-1: Anruf-SIG-Nachrichten von H.225.0 in IP-Paketen ID: Identifikation, IE: Information Element, TPDU: Transport Protocol Data Unit
Für den H.225.0-Einsatz werden die Q.931-Nachrichten um zusätzliche und Einsatz von H.225.0-spezifische Angaben erweitert, die man als User-to-User Information TPKT Elements (UUIEs) bezeichnet. UUIEs werden am Ende einer Q.931-Nachricht angehängt. Um die Länge der erweiterten Q.931-Nachricht, die eine H.225.0Anruf-SIG-Nachricht darstellt, angeben zu können, wird der Header des Protokolls TPKT (Transport PacKeT) nach RFC 2126 der Q.931-Nachricht vorangestellt. Somit wird ein TPKT-Paket aus einer H.225.0-SIG-Nachricht gebildet und über eine TCP-Verbindung übermittelt.
www.wiwobooks.com
Jede Q.931-Nachricht enthält immer folgende Angaben (s. Abschnitt 2.3): Message type als Angabe des Nachrichtentyps (Setup, Alerting, ...). Call reference als Identifikation des Anrufs, d.h. auf welchen Anruf sich diese Signalisierung bezieht. Protocol discriminator als Identifikation des Protokolls Q.931, d.h. 08hex. Informationselemente IEs (Information Elements) als Parameter der Nachricht, die oft optional sind. Die Q.931-Nachrichten und UUIEs werden mit Hilfe von ASN.1 spezifiziert.
Angaben in Q.931Nachrichten
6.4.2 Anrufsignalisierung ohne Gatekeeper Der Einsatz eines Gatekeepers ist bei H.323 optional. In kleinen IP-Netzwerken Wann ohne kann die Multimedia-Kommunikation nach H.323 ohne Gatekeeper realisiert Gatekeeper? werden. Ist dies der Fall, muss jedes Terminal die IP-Adresse jedes anderen Terminals kennen, das als potenzieller Kommunikationspartner fungiert. Somit
244
6
VoIP nach dem Standard H.323
müssen die Terminals über die entsprechenden Tabellen mit den Zuordnungen: Alias-Adresse IP-Adresse verfügen. Abbildung 6.4-2 illustriert die Anrufsignalisierung nach H.225.0 ohne Gatekeeper und ohne Fast Connect Procedure .
T e iln e h m e r A
S e tu p
A le rtin g
H .2 4 5 - S te u e r u n g s k a n a l
C o n n e c t
T e iln e h m e r B
A u fb a u R T P - u n d R T C P -K a n ä le A u d io /V id e o -K o m m u n ik a tio n
n a c h H .2 4 5
A b b a u R T P - u n d R T C P -K a n ä le R e le a s e C o m p le te H .2 4 5 - S te u e r u n g s k a n a l
Abb. 6.4-2: H.225.0-Anrufsignalisierung ohne Gatekeeper und ohne Fast Connect Procedure RTP: Real-time Transport Protocol, RTCP: RTP Control Protocol
www.wiwobooks.com
Anruf-SIGKanal muss eingerichtet werden
Für die Übermittlung von H.225.0-Nachrichten wird zuerst zwischen den Terminals beider Teilnehmer eine TCP-Verbindung aufgebaut, die als Anruf-SIGKanal dient (vgl. Abbildung 6.1-4). Dies wurde in Abbildung 6.4-2 außer Acht gelassen. Falls die sog. Fast Connect Procedure (FCP) nicht eingesetzt wird, besteht die Aufgabe der H.225.0-Anrufsignalisierung zusätzlich im Auf- und Abbau eines H-245-Steuerungskanals. Ein H-245-Steuerungskanal stellt de facto eine TCP-Verbindung dar, die man zum Auf- und Abbau der logischen RTPund RTCP-Kanäle verwendet.
Bedeutung von Setup
Eine abgehende Verbindung wird mit einer Nachricht Setup initiiert, die u.a. folgende Angaben als UUIEs enthalten muss: protocolIdentifier: Version des Protokolls H.225.0 ; sourceInfo: Typ des Endpunkts (Terminal, Gateway, MCU, ...), der die
Verbindung initiiert; callType: Art der Verbindung (Punkt-zu-Punkt oder Konferenz).
Eine Nachricht Setup kann auch h245Address enthalten. h245Address ist der Endpunkt eines H.245-Steuerungskanals, d.h. einer neuen TCP-Verbindung seitens des Teilnehmers A, die mit Hilfe von H.225.0 eingerichtet wird. Annahme des Anrufs
Kann das Terminal von Teilnehmer B den ankommenden Anruf annehmen, d.h. ist es kompatibel, erfährt dies Teilnehmer B akustisch (es klingelt) und wird mit der Nachricht Alerting dem Terminal von Teilnehmer A signalisiert. Die Entgegennahme des Anrufs durch den Teilnehmer B, beispielsweise
6.4 Signalisierung der Anrufe nach H.225.0
245
indem er den Hörer abhebt, wird dem Terminal von Teilnehmer A mit Connect signalisiert. Connect kann ebenfalls h245Address enthalten. Damit wird der Endpunkt des H.245-Steuerungskanals seitens des Teilnehmers B angegeben. Nach dem Empfang von Connect steht der H.245-Steuerungskanal zur Verfügung. Nach H.245 werden die logischen RTP- und RTCP-Kanäle für die multimediale Kommunikation aufgebaut. Nach dem Ablauf der Kommunikation werden diese Kanäle gemäß H.245 abgebaut. Danach erfolgt der Abbau des H.245-Steuerungskanals mit einer H.225-0-Nachricht Release Complete.
Aufbau der RTP- und RTCPKanäle
6.4.3 Direkte Anrufsignalisierung beim Gatekeeper-Einsatz Wird in einer H.323-Zone ein Gatekeeper eingesetzt, so wird er am Auf- und Abbau einer Verbindung für Audio- und Videokommunikation beteiligt. Abbildung 6.4-3 illustriert eine Anrufsignalisierung zwischen zwei Zonen mit Gatekeeper-Beteiligung.
R
IP -N e tz
R
www.wiwobooks.com Z o n e A
T e iln e h m e r A T e l-N r = x
A R Q
G K
A C F S e tu p
A
L R Q
Z o n e B G K
L C F
C a ll P ro c e e d in g A le rtin g
H .2 4 5 - S te u e r u n g s k a n a l
T e iln e h m e r B T e l-N r = y
B
A C F
A R Q
C o n n e c t
A u fb a u R T P - u n d R T C P -K a n ä le A u d io /V id e o -K o m m u n ik a tio n
n a c h H .2 4 5
A b b a u R T P - u n d R T C P -K a n ä le R e le a s e C o m p le te H .2 4 5 - S te u e r u n g s k a n a l D R Q D R Q D C F D C F
Abb. 6.4-3: H.225.0-Anrufsignalisierung ohne Gatekeeper-Beteiligung und ohne Fast Connect Procedure R: Router, weitere Abkürzungen wie in Abb. 6.4-2
Bevor das Terminal von Teilnehmer A eine neue Verbindung mit Setup initiieren darf, muss sie vorher von seinem Gatekeeper GKA zugelassen werden (Nachrichtenfolge ARQ, LRQ, LCF und ACF, vgl. Abb. 6.3-4). Es wurde hier angenommen, dass GKA die IP-Adresse des Terminals von Teilnehmer B beim
Zulassung und Abfrage der IPAdresse
246
6
VoIP nach dem Standard H.323
GKA abgefragt hat (Nachrichten LRQ und LCF), und sie wurde dem Terminal von Teilnehmer A in ACF mitgeteilt. Daher kann das Terminal von Teilnehmer A eine TCP-Verbindung zum Terminal von Teilnehmer B zur Übermittlung von H.225.0-Nachrichten aufbauen. Aufbau des H.245Steuerungskanals
Nach dem Aufbau einer TCP-Verbindung zum Terminal von Teilnehmer B sendet das Terminal von Teilnehmer A eine X.225.0-Nachricht Setup. Der Empfang von Setup wird vom Terminal des Teilnehmers B mit Call Proceeding bestätigt. Damit wird dem Terminal des Teilnehmers A signalisiert, dass der Anruf bearbeitet wird. Nach dem Absenden von Call Proceeding fragt das Terminal von Teilnehmer B bei seinem Gatekeeper GKB nach, ob die ankommende Verbindung angenommen werden darf (Nachrichtenfolge ARQ und ACF). Wenn ja, wird dies dem Teilnehmer B akustisch signalisiert und dem Terminal von Teilnehmer A mit Alerting mitgeteilt. Die Annahme des Anrufs durch den Teilnehmer B wird mit Connect bestätigt. Dies führt dann zum Aufbau des H.245-Steuerungskanals.
H.245Nutzung
Über den H.245-Steuerungskanal werden die RTP- und RTCP-Kanäle eingerichtet, sodass die Audio/Video-Kommunikation stattfinden kann. Wurde diese Kommunikation beendet, müssen zuerst die RTP- und RTCP-Kanäle durch die Übermittlung von H.245-Nachrichten über den H.245-Steuerungskanal abgebaut werden. Danach wird der H.245-Steuerungskanal durch das Absenden einer H.225.0-Nachricht Release Complete abgebaut.
www.wiwobooks.com
Abbau des H.245Steuerungskanals
Nach dem Abbau des H.245-Steuerungskanals teilen die beiden Terminals ihren Gatekeepern mit (Nachrichten DRQ und DCF, vgl. Abb. 6.3-3), dass die Verbindung beendet wurde, sodass evtl. reservierte Bandbreiten wieder freigegeben werden können.
6.4.4 Über Gatekeeper geroutete Anrufsignalisierung Bedeutung von callModel
Kommt ein Gatekeeper zum Einsatz, so muss er eine neue Verbindung, falls keine Vorausbewilligung (pre-granted Admission) vorliegt, genehmigen, bevor sie von einem Terminal initiiert wird. In der Nachricht ACF teilt der Gatekeeper dem Terminal mit dem Parameter callModel mit, ob die Verbindung über ihn geroutet werden soll oder nicht (vgl. Abb. 6.3-3). Soll die Verbindung über den Gatekeeper geroutet werden, sendet das Terminal die H.225.0-Nachrichten an seinen Gatekeeper. Abbildung 6.4-4 illustriert eine über einen Gatekeeper geroutete Anrufsignalisierung. Der Gatekeeper (GKA) kann hierbei als Firewall 1 dienen, um bestimmte „Angriffe“ nicht zuzulassen. 1
Falls die Anrufsignalisierung über einen Gatekeeper verläuft, lässt sich diese mit Web-Anwendungen mit Hilfe von HTTP integrieren. Dadurch entstehen neue Möglichkeiten. Das angeru-
6.4 Signalisierung der Anrufe nach H.225.0
247
Hier teilt GKA in ACF dem Terminal von Teilnehmer A mit, dass die zu initiie- Gatekeeper rende Verbindung über ihn geroutet werden soll. Somit sendet dieses Terminal als Zwieine Nachricht Setup nicht an das Terminal von Teilnehmer B, sondern an schensystem GKA. Dieser leitet entsprechend Setup an das Terminal von Teilnehmer B weiter und teilt dem Terminal von Teilnehmer A mit Call Proceeding mit, dass der Verbindungsaufbau fortgesetzt wird.
Z o n e A T e iln e h m e r A T e l-N r = x
A R Q S e tu p
R G K
A C F C a ll P ro c .
IP -N e tz A
L R Q
R
Z o n e B G K
L C F
S e tu p
T e l-N r = y C a ll P ro c .
A le rtin g
A le rtin g C o n n e c t H .2 4 5 - S K
T e iln e h m e r B B
A C F
A R Q
C o n n e c t
H .2 4 5 - S K
A u fb a u R T P - u n d R T C P -K a n ä le
n a c h H .2 4 5
www.wiwobooks.com A u d io /V id e o -K o m m u n ik a tio n
A b b a u R T P - u n d R T C P -K a n ä le
R e l. C o m p l. H .2 4 5 - S K D R Q D C F
R e le a s e C o m p le te H .2 4 5 - S K D C F
D R Q
Abb. 6.4-4: Über den Gatekeeper geroutete H.225.0-Anrufsignalisierung ohne Fast Connect Procedure R: Router, SK: Signalisierungskanal
Wie in Abbildung 6.4-4 ersichtlich ist, werden alle H.225.0-Nachrichten über GKA übermittelt. In diesem Fall setzt sich der H.245-Steuerungskanal zwischen den beiden Terminals aus zwei H.245-Steuerungskanälen zusammen. Außerdem gibt es hier beim Verlauf der Signalisierung keine weiteren Unterschiede mehr im Vergleich zu Abbildung 6.4-3.
fene IP-Telefon kann beispielsweise auf eine Web-Seite verweisen, die automatisch vom anrufenden Soft-IP-Telefon abgerufen wird und auf der man dem Anrufer wichtige Angaben zur Verfügung stellen kann – z.B., dass er die initiierte Verbindung an eine andere Rufnummer umleiten soll. Diese Möglichkeiten präsentiert Annex K – HTTP-based service control transport channel – zu H323.
248
6
VoIP nach dem Standard H.323
6.4.5 VoIP im Verbund mit ISDN Die für den Aufbau der Kanäle für die Audio/Video-Übermittlung benötigte Zeit lässt sich durch den Einsatz von Fast Connect Procedure (FCP) bei H.225.0 reduzieren (s. Abschnitt 6.2.3). Dabei wird kein spezieller H.245-Steuerungskanal aufgebaut, sondern die notwendigen H.245-Nachrichten in den H.225.0-Nachrichten eingekapselt und übermittelt. Abbildung 6.4-5 illustriert den H.225.0-Verlauf beim FCP-Einsatz am Beispiel einer VoIP-Anwendung. Es handelt sich hier um die Sprachkommunikation zwischen einem IP-Telefon und einem ISDN-Telefon. Wie hier ersichtlich ist, bildet das lokale IP-Netz mit der ISDN-TK-Anlage eine H.323-Zone.
T e iln e h m e r A
IP -N e tz H .3 2 3 - Z o n e G K A R Q
A C F
R
In te rn e t
R
H .3 2 3 - Z o n e
IP N e tz
G W
IS D N T K -A n l
A
L R Q
L C F
G K B
S e tu p A le rtin g C o n n e c t
D -K a n a lP ro to k o ll S E T U P A L E R T C O N N
www.wiwobooks.com R T P /R T C P -K a n ä le
R e le a s e C o m p le te D R Q D C F
S p r a c h k o m m u n ik a tio n
B -K a n a l
D IS C D R Q D C F
T e iln e h m e r B
Lokales IP-Netz mit ISDN-TKAnlage eine Zone
R E L
R E L C O M
Abb. 6.4-5: H.225.0-Verlauf zwischen IP-Telefon und ISDN-Telefon beim FCP-Einsatz GK: Gatekeeper, GW: Gateway, R: Router Für die Nachrichten des D-Kanal-Protokolls s. Abschnitte 2.3.1 und 2.3.2.
Ziel-IPAdresse unbekannt
Bevor der Aufbau einer Sprachverbindung initiiert wird, sendet das Terminal von Teilnehmer A die Nachricht ARQ mit der Alias-Adresse von Teilnehmer B und der Variable canMapAlias = TRUE. Damit bittet er seinen Gatekeeper GKA, ihm die IP-Adresse des Terminals von Teilnehmer B zu ermitteln (vgl. Abb. 6.3-4). Teilnehmer B nutzt aber kein H.323-Terminal, sondern ein ISDNTelefon.
Ermittlung der Ziel-IPAdresse
Weil der GKA über keine Zuordnung Alias-Adresse IP-Adresse für die Terminals aus den fremden Zonen verfügt, fragt er mit Hilfe der Nachricht LRQ den GKB als Gatekeeper der Ziel-Zone nach dieser IP-Adresse. Die gewünschte IP-Adresse übermittelt GKB an GKA in LCF, und dieser leitet sie in ACF an das Terminal von Teilnehmer A weiter. Sie stellt aber nicht die IPAdresse des Terminals von Teilnehmer B, sondern die IP-Adresse des Gateways dar. Damit verfügt das Terminal von Teilnehmer A über die IP-Adresse,
6.5 Einsatz des Protokolls H.245
249
zu der eine TCP-Verbindung (als Anruf-SIG-Kanal, s. Abb. 6.1-4) für die Übermittlung von H.225.0-Nachrichten aufgebaut werden soll. Das Terminal von Teilnehmer A initiiert nun den Verbindungsaufbau durch das Verweis auf Absenden von Setup an das Gateway zur ISDN-TK-Anlage. Setup enthält FCP in das Feld fastStart mit dem Parameter OpenLogicalChannel, sodass die Setup logischen RTP- und RTCP-Kanäle über das IP-Netz für die Übermittlung der Sprache gleichzeitig initiiert werden. Die Nachricht Setup nach H.225.0 wird im Gateway auf die Nachricht SETUP des D-Kanal-Protokolls umgesetzt und an das Telefon von Teilnehmer B weitergeleitet. Falls die Überprüfung der Kompatibilität zu einer positiven Aussage geführt hat, Annahme des wird dies dem Teilnehmer B akustisch signalisiert (es klingelt). Dieser Zustand ankommenwird dem Terminal von Teilnehmer A mit Alerting angezeigt. Das Gateway den Anrufs setzt dann die Nachrichten des D-Kanal-Protokolls entsprechend in H.225.0Nachrichten um. Hat Teilnehmer B den ankommenden Anruf angenommen, wird dies dem Terminal von Teilnehmer A mit Connect mitgeteilt. Da man hier FCP verwendet, werden gleichzeitig die für die Übermittlung der Ende-zuSprache notwendigen logischen RTP- und RTCP-Kanäle aufgebaut. Nach dem EndeEintreffen von Connect beim Terminal von Teilnehmer A kann die Übermitt- Nutzkanal lung der Sprache beginnen. Es ist hier zu bemerken, dass sich ein Ende-zuEnde-„Nutzkanal“ für die Sprachübermittlung aus den RTP/RTCP-Kanälen im IP-Netz und aus der ISDN-Verbindung zusammensetzt.
www.wiwobooks.com
Beim Verbindungsabbau wird die H.225.0-Nachricht Release Complete auf Verbindie Nachricht Disconnect des D-Kanal-Protokolls im Gateway umgesetzt dungsabbau (vgl. Abb. 2.3-3). Nach dem Verbindungsabbau teilen das Terminal von Teilnehmer A und das Gateway ihren Gatekeepern mit den Nachrichten DRQ und DCF mit (vgl. Abb. 6.3-3), dass die Verbindung beendet wurde, sodass evtl. reservierte Bandbreiten wieder freigegeben werden.
6.5
Einsatz des Protokolls H.245
H.245 ist ein Signalisierungsprotokoll und stellt die Funktionen zur Verfügung, die man beim Aufbau und Abbau der logischen RTP/RTCP-Kanäle für die Übermittlung von Audio und Video über IP-Netze benötigt. Die wichtigsten Funktionen von H.245: Austausch der Terminal-Fähigkeiten (Capability Exchange) Master/Slave-Festlegung (Master/Slave Determination) Aufbau und Abbau logischer RTP/RTCP-Kanäle für die Übermittlung verschiedener Medien (Audio, Video, Daten) Steuerung logischer Kanäle Öffnung eines logischen Kanals beim Empfänger (Mode Request)
Funktionen von H.245
250
6
VoIP nach dem Standard H.323 Ermittlung des Round Trip Delay zwischen zwei Endpunkten
Um diese Funktionen zu realisieren, definiert das H.245 unterschiedliche Nachrichten. Die einzelnen H.245-Nachrichten werden bei der Erläuterung von H.245-Funktionen näher dargestellt. Für die Spezifikation von H.245-Nachrichten wird ASN.1 verwendet.
H.245-Nachrichten in IP-Paketen
Weil der H.245-Steuerungskanal de facto eine TCP-Verbindung darstellt, werden die H.245Nachrichten als Daten des Protokolls TCP übermittelt. Wie die H.245-Nachrichten in IP-Paketen eingebettet werden, zeigt Abbildung 6.5-1. In einem IP-Paket können mehrere H.245-Nachrichten enthalten sein.
T P K T -P a k e t IP
T P K T -P a k e t
T C P
T C P -N u tz la s t T P K T -H
T P K T -ID (= 3 ) R e se rv e d (= 0 ) P a c k e t L e n g th
H .2 4 5 - N a c h T P K T - H
H .2 4 5 - N a c h
...
H .2 4 5 - N a c h : H .2 4 5 - N a c h r ic h t in A S N .1 P E R
L ä n g e d e s T P K T -P a k e ts
Abb. 6.5-1: H.245- Nachrichten in IP-Paketen – Einsatz des Protokolls TPKT
www.wiwobooks.com ID: Identifikation, TPKT-H: TPKT-Header
Einsatz von TPKT
Jeder zu übertragenden H.245-Nachricht wird der Header des Protokolls TPKT (Transport PacKeT) vorangestellt (vgl. Abb. 6.4-1). Darin wird die Länge des TPKT-Pakets und somit auch die Länge der H.245-Nachricht angegeben.
6.5.1 Beschreibung von Terminal-Fähigkeiten Austausch von Fähigkeiten
Die erste direkt nach dem Aufbau eines H.245-Steuerungskanals realisierte Funktion ist die Festlegung, ob die beiden Terminals kompatibel sind. Hierbei wird überprüft, ob die Kommunikation zwischen diesen beiden stattfinden kann. Insbesondere wird geprüft, ob die beiden Terminals die gleichen Audio- und Videocodierungsverfahren unterstützen. Dieser Prozess besteht im Austausch von Capabilities (Fähigkeiten) der beteiligten Terminals, sodass man hier von Capability Exchange spricht.
Bedeutung der Capability Table (cT)
Bei einem H.323-Terminal kann es sich um eine Vielzahl verschiedener Capabilities, wie z.B. Audio-, Video-, Daten- und Encryption-Capabilities, handeln. Hierbei wird besonders zwischen receiveCapabilities, transmitCapabilities und receiveAndTransmitCapabilities unterschieden. Diese Vielzahl unterschiedlicher Capabilities muss nach einem eindeutigen Schema präzise beschrieben werden. Alle Capabilities eines H.323-Terminals werden nummeriert und in einer sog. capabilityTable (cT) aufgelistet (s. Abbildung 6.5-2), die ASN.1 beschreibt.
Was enthält eine cT?
Jeder Eintrag in cT besitzt seine Nummer, eine sog. CapabilityTableEntryNumber, den Namen der Capability und zusätzliche Parameter der Capability wie z.B. maximale Anzahl der Abtastwerte des Audiosignals im IP-Paket. In dem in Abbildung 6.5-2 gezeigten Beispiel wurden die Parameter in cT außer Acht gelassen. Eine cT stellt somit eine nummerierte Aufzählung von
6.5 Einsatz des Protokolls H.245
251
Capabilities eines Terminals dar und kann als Capability-Raum des Terminals angesehen werden. Sie stellt u.a. eine Liste von nummerierten Audio- und Video-Codecs des Terminals dar. Die Capabilities aus cT können zu Gruppen sog. alternativeCapabilities zusammengefasst werden. Beispiel: Aus der in Abb. 6.5-2 gezeigten cT können folgende Gruppen von alternativeCapabilities definiert werden: A = {1, 2, 3}, B = {4, 5} und C = {6}. Somit enthält: •
A die Auflistung von Audio-Codecs (d.h. von Codecs nach G.711, G.723.1 und G.728),
•
B die Auflistung von Video-Codecs (d.h. von Codecs nach H.261 und H.263) und
•
C ein Element und besagt, dass das Terminal nur die Daten nach dem Protokoll T.120 senden und empfangen kann.
Die Capabilities aus einer Gruppe von alternativeCapabilities beziehen sich auf einen logischen Kanal, z.B. auf einen Kanal für die Übermittlung von Audio bzw. auf einen Kanal für die Übermittlung von Video. a C
c a p a b ility T a b le E n try N u m b e rs
c a p a b ility T a b le (c T ) 1 - G 2 - G 3 - G 4 - H 5 - H 6 - T
.7 1 .7 2 .7 2 .2 6 .2 6 .1 2
1
3 .1
re c e iv e A n d T ra n s m itA u d io C a p a b ilitie s
1
re c e iv e A n d T ra n s m itV id e o C a p a b ilitie s
c D
2
4 2
1
5 3
8 3
a C 1
1
sC a C
www.wiwobooks.com 0
re c e iv e A n d T ra n s m itD a ta C a p a b ility
c D
2
1
6
c D : c a p a b ility D e s c rip to r, a /s C : a lte rn a tiv e /s im u lta n e u s C a p a b ilitie s
sC
Abb. 6.5-2: capabilityTable und capabilityDescriptor eines Terminals Um die Fähigkeiten eines Terminals hinsichtlich der Multimedia-Kommunikation zu definieren, d.h. falls mehrere logische Kanäle eingesetzt werden, verwendet man den Begriff simultaneousCapabilities. Darunter versteht man eine bzw. mehrere Gruppen von alternativeCapabilities. Um die Fähigkeiten eines Terminals zu beschreiben, wird auch ein sog. capabilityDescriptor(cD) gebildet, der simultaneousCapabilities enthält.
Bedeutung von capabilityDescriptor (cD)
Beispiel: Das Terminal mit den in Abbildung 6.5-2 gezeigten Fähigkeiten kann entweder eine gleichzeitige Audio- und Videokommunikation nach cD1 oder nur die Datenkommunikation über T.120 nach cD2 realisieren. cD1 besagt, dass das Terminal gleichzeitig Audio- und Videokommunikation unterstützen kann. Hierbei können bei der Audio-Kommunikation die Audio-Codecs G.711, G.723.1 oder G.728 und bei der Videokommunikation die VideoCodecs H.261 oder H.263 zum Einsatz kommen. Alle Kombinationen von Audio- und VideoCodecs, die man bei der parallelen Audio- und Videokommunikation verwendet, werden durch das Mengenprodukt aC1 X aC2 = {(1,4), (1,5), (2,4), (2,5), (3,4), (3,5)}
von capabilityTableEntryNumbers bestimmt. Die ersten über den H.245-Steuerungskanal zwischen den beteiligten Terminals ausgetauschten H.245-Nachrichten sind terminalCapabilitySet (TCS) mit der Beschreibung ihrer Fähigkeiten in Form von capabilityDescriptors (s. Abb. 6.5-3).
Austausch von Fähigkeiten
252
6
VoIP nach dem Standard H.323
6.5.2 Austausch von Terminal-Fähigkeiten Nachrichten TCS und TCSAck
Wie Abbildung 6.5-3 zeigt, übermittelt ein Terminal seine Fähigkeiten an ein anderes Terminal, mit dem eine Kommunikation stattfinden soll, mit Hilfe der H.245-Nachricht TerminalCapabilitySet(TCS). Falls der Austausch von Fähigkeiten erfolgreich abgelaufen ist, wird dies mit TerminalCapabilitySetAck(TCSAck) vom Empfänger mit der Nachricht TCS bestätigt. T e rm in a l A A u s ta u s c h v o n F ä h ig k e ite n : e r fo lg r e ic h
T C S [se q c a p c a p (c
T e rm in a l B u e a b a b a p s im
a b g e le h n t
T C S
g e s to p p t
T C S
n c e N u m ility T a b ility D e s a b ility D u lta n e u
b e r le , c rip e sc sC a
1 , ... to rs rip to rN u m b e r 1 , p a b ilitie s ( ...) ) , ...] T C S A c k [se q u e n c e N u m b e r 1 ]
T C S R e je c t T C S R e le a s e
Abb. 6.5-3: Übermittlung von Terminal-Fähigkeiten in TCS (TerminalCapabilitySet)
Inhalt der Nachricht TCS
TCS enthält u.a. eine laufende Nummer (sequenceNumber) und folgende Angaben: capabilityTable: Hier werden die Capabilities aufgelistet und nummeriert.
www.wiwobooks.com
CapabilityDescriptors(cDs): Es können mehrere cDs übermittelt werden. In jedem cD werden die sog. simultaneousCapabilities des Terminals aufgelistet. Damit werden alle Codierungsverfahren angegeben, die das Terminal unterstützt. Jeder cD hat seine Nummer. Im Beispiel aus Abbildung 6.5-3 wird nur ein cD mit der Nummer 1 übermittelt.
Um die Antwort der abgeschickten Nachricht TCS eindeutig zuzuordnen, enthält eine Antwort TCSAck auf TCS die laufende Nummer von TCS. Der Empfänger von TCS kann den Austausch von Terminal-Fähigkeiten mit der Nachricht TerminalCapabilityReject(TCSReject)auch ablehnen. Nach dem Absenden der Nachricht TCS wartet der Absender eine festgelegte Zeit auf eine Antwort vom Empfänger. Kommt innerhalb dieser Zeit keine Reaktion vom Empfänger, bricht der Absender durch Absenden des Kommandos TerminalCapabilityRelease (TCSRelease)den Austausch von Terminal-Fähigkeiten ab.
6.5.3 Master/Slave-Festlegung Master und SlaveTerminals
Bei einer Kommunikation können einige Fehler- bzw. Konfliktsituationen auftreten. Beispielsweise möchte ein Terminal einen logischen Kanal für die Übermittlung von Audio nach einem bestimmten Codierungsverfahren einrichten, das von einem anderen Terminal aber nicht unterstützt wird. Um derartige Situationen beim Aufbau logischer RTP/RTCP-Kanäle für die Übertragung verschiedener Arten von Medien (Audio, Video, Daten) zu vermeiden, verständigen sich die beiden Terminals darauf, welches von ihnen die Rolle eines führenden (übergeordneten) Terminals, d.h. eines sog. Master-Terminals, übernimmt. Das andere bleibt diesem als SlaveTerminal untergeordnet, sodass es auf die Anforderungen des Master-Terminals direkt antworten muss.
253
6.5 Einsatz des Protokolls H.245 Die Master/Slave-Festlegung erfolgt in der Regel direkt nach dem Austausch von Capabilities. Da mehrere H.245-Nachrichten in einem IP-Paket übermittelt werden können (vgl. Abb. 6.5-1), kann eine Nachricht für die Master/Slave-Festlegung in einem IP-Paket direkt hinter einer Nachricht terminalCapabilitySet übermittelt werden.
Wann Master/SlaveFestlegung?
Abbildung 6.5-4 zeigt den Ablauf einer Master/Slave-Festlegung. Diese Festlegung wird von einem Terminal mit der H.245-Nachricht MasterSlaveDetermination(MSD) initiiert. Diese enthält zwei Parameter terminalType(tT) und StatusDeterminationNumber(sDNum).
Nachricht
T e rm in a l A
MSD
T e rm in a l B
M S D
[te rm in a lT y p e 5 0 , s ta tu s D e te rm in a tio n N u m b e r 7 9 2 6 1 5 ]
M S D A c k
M S D A c k
[d e c is io n S la v e ]
[d e c is io n M a s te r ]
Abb. 6.5-4: Ablauf einer Master/Slave-Festlegung MSD: MasterSlaveDetermination
Der tT-Wert gibt eine Aussage über die Funktionalität eines H.323-Endsystems. Je umfangreicher die Funktionalität des H.323-Endsystems ist, desto größer ist sein tT-Wert. Beispielsweise hat ein einfaches Terminal als IP-Telefon den tT-Wert 50. sDNum ist eine Zufallsvariable, die lokal bei jedem der beteiligten Terminals generiert wird.
Bedeutung von tT und
Nach dem Empfang einer Nachricht MSD vergleicht das Empfänger-Terminal seinen tT-Wert mit dem tT-Wert des Absender-Terminals. Das Terminal mit dem größten tT-Wert wird als Master ausgewählt. Sind die beiden tT-Werte gleich, generiert das Empfänger-Terminal einen zufälligen sDNum-Wert. Danach vergleicht er seinen sDNum-Wert mit dem des Absender-Terminals. Das Terminal mit dem größten sDNum-Wert wird nun als Master ausgewählt. Sind die beiden sDNumWerte auch gleich, lässt sich der Master nicht bestimmen. Die Master/Slave-Festlegung muss neu gestartet werden.
MasterAuswahl
Wie Abbildung 6.5-4 zeigt, wird MSD mit MasterSlaveDeterminationAck(MSDAck)bestätigt. In MSDAck wird die beim Empfänger von MSD gefallene Entscheidung dem Absender von MSD mitgeteilt. Der Empfänger von MSDAck bestätigt diese Entscheidung ebenfalls mit MSDAck.
Nachricht
www.wiwobooks.com
sDNum
MSDAck
6.5.4 Aufbau logischer Kanäle Der Aufbau eines logischen RTP-Kanals für die Übermittlung eines Medientyps (Audio, Video) wird durch das Absenden der H.245-Nachricht OpenLogicalChannel(OLC) initiiert. Abbildung 6.5-5 illustriert den Aufbau logischer RTP/RTCP-Kanäle für eine bidirektionale Sprachübermittlung. Hierbei werden zwei unidirektionale Kanäle eingerichtet, die einen logischen bidirektionalen RTP-Kanal bilden. Der bidirektionale RTP-Kanal stellt einen mediaChannel dar. Parallel zu diesem Kanal wird ein mediaControlChannel eingerichtet, über den die RTCPNachrichten zwischen Terminals ausgetauscht werden, sodass der Verlauf der Sprachübermittlung kontrolliert werden kann. In der Nachricht OLC wird u.a. angegeben: Die Nummer forwardLogicalChannelNumber des Vorwärtskanals, d.h. des Kanals in Richtung zum Empfänger der Nachricht OLC.
Bedeutung von oLC
Inhalt von OLC
254
6
VoIP nach dem Standard H.323 Die Parameter des Vorwärtskanals forwardLogicalChannelParameters wie: − dataType: Welcher Medientyp wird über diesen logischen Kanal übermittelt. Hier wird ein Eintrag aus dem bereits übermittelten capabilityDescriptor ausgewählt. In Abbildung 6.5-5 handelt es sich um die nach dem Verfahren G.711 µ-Law (64 kbit/s) codierte Sprache (s. Abschnitt 5.1.3). − SessionID: Identifikation der Session. Da alle Kanäle zu einer Session gehören, muss diese Angabe in allen in Abbildung 6.5-5 gezeigten Nachrichten enthalten sein. − MediaControlChannel: UDP-Port-Nummer des logischen RTCP-Kontrollkanals. T e rm in a l A O p e n L o g ic a lC h a n n e l { fo rw a rd L o g ic a fo rw a rd L o g ic a { d a ta T y p e a u S e s s io n ID 1
lC h a n n e lC h a n n e d io D a ta , m e d ia C
lN lP : o
T e rm in a l B
u m b e r 1 , a ra m e te rs g 7 1 1 µ - la w ... n tr o lC h a n n e l 8 0 3 5 , ...} }
O p e n L o g ic a lC h a n n e l { fo rw a rd L o g fo rw a rd L o g { d a ta T y p e S e s s io n ID
ic a lC h a ic a lC h a a u d io D 1 , m e d
n n e n n e a ta ia C
lN u m b e r lP a ra m e te : g 7 1 1 µ o n tro lC h a
2 3 1 , rs la w ..., n n e l 6 5 2 8 7 , ...} }
O p e n L o g ic a lC h a n n e lA c k { fo rw a rd L o g ic a lC h a n n e lN u m b e r 2 3 1 , S e s s io n ID 1 , m e d ia C h a n n e l 8 0 3 4 , m e d ia C o n tr o lC h a n n e l 8 0 3 5 , ...} }
www.wiwobooks.com
O p e n L o g ic a lC h a n n e lA c k
8 0 3 5
N r 1
m e d ia C h a n n e l R T P
m e d ia C o n tro lC h a n n e l
R T C P
N r 2 3 1
U D P P o rts :
U D P P o rts : 8 0 3 4
{ fo rw a rd L o g ic a lC h a n n e lN u m b e r 1 , S e s s io n ID 1 , m e d ia C h a n n e l 6 5 2 8 6 , m e d ia C o n tr o lC h a n n e l 6 5 2 8 7 , ...} }
6 5 2 8 6 6 5 2 8 7
Abb. 6.5-5: Beispiel für den Aufbau logischer RTP/RTCP-Kanäle für die Sprachübermittlung
Nachricht OLCAck
Eine Nachricht OpenLogicalChannelAck (OLCAck) enthält u.a.: Die Nummer forwardLogicalChannelNumber des Vorwärtskanals, auf den sich diese Nachricht bezieht. MediaChannel: UDP-Port-Nummer des logischen RTP-Medienkanals. MediaControlChannel gibt die UDP-Port-Nummer des RTCP-Kontrollkanals an. Die An-
gabe aus OLC lässt sich durch diese Angabe verändern.
6.5.5 Abbau logischer Kanäle CLC und CLCAck
Normalerweise beginnt der Abbau eines logischen Kanals durch Absenden einer H.245-Nachricht CloseLogicalChannel(CLC) über das als Sender fungierende Terminal. CLC enthält die Nummer des betreffenden Vorwärtskanals und die Angabe der Ursache für den Abbau. CLC wird von der Gegenseite mit CloseLogicalChannelAck(CLCAck)bestätigt. Abbildung 6.5-6 illustriert den Ablauf beim Abbau der logischen Kanäle aus Abbildung 6.5-5.
6.5 Einsatz des Protokolls H.245
255
In der Regel initiiert das Terminal den Abbau eines unidirektionalen Kanals, wo es als Sender fungiert. Es kann jedoch vorkommen, dass ein Terminal als Empfänger den Abbau eines unidirektionalen Kanals anstoßen muss. Hierfür verwendet man die H.245-Nachricht RequestChannelClose. Sie wird von der Gegenseite mit RequestChannelCloseAck bestätigt. T e rm in a l A S e n d e r
T e rm in a l B
C lo s e L o g ic a lC h a n n e l
E m p fä n g e r
{ f o r w a r d L o g ic a lC h a n n e lN u m b e r 1 , ..., r e a s o n r e o p e n , ...}
C lo s e L o g ic a lC h a n n e lA c k
{ fo rw a rd L o g ic a lC h a n n e lN u m b e r 1 }
C lo s e L o g ic a lC h a n n e l
E m p fä n g e r
{ f o r w a r d L o g ic a lC h a n n e lN u m b e r 2 3 1 , ..., r e a s o n r e o p e n , ...}
S e n d e r
C lo s e L o g ic a lC h a n n e lA c k
{ fo rw a rd L o g ic a lC h a n n e lN u m b e r 2 3 1 }
Abb. 6.5-6: Abbau logischer Kanäle aus Abbildung 6.5-5
6.5.6 Änderung von Eigenschaften einer Verbindung
www.wiwobooks.com
Typischerweise wird der Aufbau eines unidirektionalen logischen RTP-Kanals vom Terminal angestoßen, das als Sender fungieren wird (vgl. Abb. 6.5-6). Es ist jedoch eine Situation denkbar, in der ein Sender einen unidirektionalen Kanal seitens des Empfängers initiieren will, z.B. wenn ein Sender auf ein anderes Audio/Video-Format wechseln möchte. Er kann vom Empfänger verlangen, auf eine andere Betriebsart (Mode) umzusteigen, um damit die Eigenschaften der bestehenden Verbindung zu ändern. Dies bezeichnet man als Mode Request. Abbildung 6.5-7 illustriert den Ablauf bei der Änderung des Verfahrens für die Sprachcodierung. T e rm in a l A R e q u e s tM o d e
T e rm in a l B L o g ic a lC h a n n e lN u m b e r 1 A u d io g 7 1 1
{ se q u e n c e N u m b e r 1 , R e q u e s te d M o d e s { A u d io M o d e g 7 2 9 , A u d io M o d e g 7 2 8 , .... } }
R e q u e s tM o d e A c k
{ se q u e n c e N u m b e r 1 , w illT ra n s m itM o s tP re fe rre d M o d e }
L o g ic a lC h a n n e lN u m b e r 1 A u d io g 7 2 9
Abb. 6.5-7: Ablauf von Mode Request Das Terminal A als Sender in Richtung Terminal B möchte das Verfahren für die Codierung der in diese Richtung übertragenen Sprache wechseln. Dies initiiert Terminal A durch Absenden der H.245-Nachricht mit der Angabe einer Liste von Sprachcodierungsverfahren als RequestedModes. Diese Verfahren müssen bereits als Capabilities des Terminals A beim Capability Exchange dem Terminal B angezeigt worden sein (s. Abb. 6.5-2 und -3). Das Verfahren an der ers-
Wechseln des Sprachcodierungsverfahrens
256
6
VoIP nach dem Standard H.323
ten Stelle auf der RequestedModes-Liste ist das am häufigsten (MostPreferred) und das an der letzten Stelle entsprechend am seltensten gewählte. Der Empfänger der Nachricht antwortet, welchen Mode, d.h. welches Verfahren er ausgewählt hat. Im vorliegenden Beispiel ist G.729 das meistgewählte Verfahren für die Sprachcodierung.
6.5.7 Beispiel für einen Verlauf des Protokolls H.245 In Abbildung 6.1-4 wurde allgemein bereits gezeigt, an welcher Stelle während der Audio/ Videokommunikation das Protokoll H.245 zum Einsatz kommt. Berücksichtigt man die bisherigen Darstellungen von H.245, so zeigt Abbildung 6.5-8 ein Beispiel für einen vollständigen H.245-Verlauf ohne Fast Connect Procedure (vgl. Abb. 6.2-4) während einer Audio/VideoKommunikation. T e rm in a l B
T e rm in a l A A u fb a u d e s A n ru f-S IG -K a n a ls
H .2 2 5 .0
A n ru f-S IG -K a n a l
S e tu p
A le rtin g
C o n n e c t H .2 4 5 - S te u e r u n g s k a n a l T C S
T C S
A u f b a u d e s H .2 4 5 S te u e ru n g s k a n a ls
www.wiwobooks.com T C S A c k
T C S A c k
M S D
H .2 4 5
O L C
M S D A c k &
O L C
M S D A c k
M a s te r/S la v e D e te rm in a tio n O p e n C h a n n e l P ro c e d u re
O L C A c k
O L C A c k
C a p a b ility E x c h a n g e
A u d io /V id e o -K o m m u n ik a tio n
H .2 4 5 H .2 2 5 .0
C L C
C L C
C L C A c k R e le a s e C o H .2 A b b a u A n r
C L C A c k m p le te 4 5 -S te u e ru n g s k a n a l d e s A n ru f-S IG -K a n a ls u f-S IG -K a n a l
C lo s e C h a n n e l P ro c e d u re A b b a u d e s H .2 4 5 S te u e ru n g s k a n a ls
Abb. 6.5-8: Beispiel für einen H.245-Verlauf während der Audio/Video-Kommunikation TCS: TerminalCapabilitySet, MSD: MasterSlaveDetermination, OLC: OpenLogicalChannel, CLC: CloseLogicalChannel, SIG: SIGnalisierung
In diesem Verlauf sind folgende Schritte zu unterscheiden: Capability Exchange (s. Abb. 6.5-3) Master/Slave Determination (s. Abb. 6.5-4)
6.6 Supplementary Services nach H.450.x
257
Nach dem Verlauf der Open Channel Procedure (s. Abb. 6.5-5) stehen zwei unidirektionale logische RTP-Kanäle und ein bidirektionaler RTCP-Kanal zur Verfügung. Die Audiobzw. Videokommunikation kann nun beginnen. Nach dem Ablauf der Kommunikation werden die Kanäle nach Close Channel Procedure abgebaut. Der Verlauf dieser Prozedur entspricht dem Verlauf in Abbildung 6.5-6. Nach dem Abbau der logischen Kanäle wird der H.245-Steuerungskanal mit der Nachricht Release Complete des Protokolls H.225.0 abgebaut. Zum Schluss muss noch die bestehende TCP-Verbindung als Anruf-SIG-Kanal abgebaut werden.
6.6
Supplementary Services nach H.450.x
Um verschiedene ISDN-Dienstmerkmale auch in VoIP-Systemen beim Einsatz von H.323 realisieren zu können, werden in den Standards H.450.x (x = 2, …, 11) sog. Supplementary Services definiert. Zu solchen ergänzenden Dienstmerkmalen der VoIP-Systeme gehören:
Ergänzende Dienstmerkmale Call Transfer (CT) als Anrufumlegung nach H.450.2 GesprächsDieses Dienstmerkmal erlaubt es, eine bestehende Telefonverbindung zwischen Teilnehmer umlegung A und Teilnehmer B durch den Teilnehmer A auf eine neue Telefonverbindung zwischen Teilnehmer B und Teilnehmer C umzulegen (zu transferieren). Sollte z.B. Teilnehmer A während eines Telefongespräches mit dem Teilnehmer B feststellen, dass dieser noch eine Auskunft von Teilnehmer C benötigt, kann Teilnehmer A bereits während des Gesprächs eine neue Telefonverbindung zwischen Teilnehmer B und Teilnehmer C initiieren. Nach dem Aufbau der Verbindung zwischen Teilnehmer B und Teilnehmer C wird die Verbindung zwischen Teilnehmer A und Teilnehmer B abgebaut (s. Abb. 6.6-2).
www.wiwobooks.com
Call Forwarding (CF) als Anrufweiterleitung nach H.450.3 Die Anrufumleitung ist ein wichtiges Dienstmerkmal im ISDN-Netz und in digitalen Mobilfunknetzen. Dabei werden die bei einem Teilnehmer ankommenden Anrufe an eine andere Rufnummer umgeleitet. Call Forwarding als Call Deflection bzw. als Call Diversion nach H.450.3 Durch die Anrufumleitung werden die bei einem Teilnehmer ankommenden Anrufe an eine andere Rufnummer umgeleitet. Wenn ein Telefon klingelt, kann keine andere Aktion erfolgen als den Anruf anzunehmen oder abzulehnen. Daher ist eine Anrufumleitung während des Klingelns (sog. Call Deflection) mit einem normalen Telefon nicht möglich. Bei VoIP kann ein entsprechender Gatekeeper durch einen Befehl veranlasst werden, einen ankommenden Anruf bereits während des Klingelns an eine bestimmte Rufnummer umzuleiten. Bei Call Diversion wird ein ankommender Anruf an seinem Ziel an eine neue Adresse entweder direkt oder nach Abwarten eines Zeitintervalls umgeleitet. Man unterscheidet somit: • eine sofortige Anrufweiterleitung als unbedingte Anrufweiterleitung CFU (Call Forwarding Unconditional) bzw. als Anrufweiterleitung bei Besetzt CFB (Call Forwarding Busy); • eine verzögerte Anrufweiterleitung als Anrufweiterleitung bei Nichtmelden CFNR (Call Forwarding No Reply) bzw. als Anrufweiterleitung bei der Anrufsignalisierung CD (Call Deflection).
Anrufumleitung
Arten der Anrufumleitung
258
6
VoIP nach dem Standard H.323
Halten einer Verbindung
Call Hold (HOLD); Halten einer Verbindung nach H.450.4
Parken und Anrufwiederaufnahme
Call Park und Call Pickup nach H.450.5
Makeln, Dreierkonferenz
Call Waiting als Anklopfen H.450.6
Anzeige „Nachricht wartet“
Message Waiting Indication (MWI) nach H.450.7
Ein ankommender Anruf während einer bestehenden Verbindung kann durch „Anklopfen“ angezeigt werden, daher kann ein Teilnehmer mit Call Hold das Gespräch auf der bereits bestehenden Verbindung kurz unterbrechen und die neue Verbindung aufnehmen. Nach der Beendigung der neuen Verbindung kann er zur alten Verbindung zurückkehren und das abgebrochene Gespräch fortsetzen. Bei Call Park kann ein Teilnehmer die bestehende Verbindung an einem Terminal parken (d.h. kurz abbrechen) und angeben, von welchem anderen Terminal diese abgebrochene Verbindung wiederaufgenommen wird. Als Call Pickup bezeichnet man oft die Wiederaufnahme einer geparkten Verbindung. Call Park und Call Pickup entsprechen weitgehend dem ISDNDienstmerkmal Umstecken am Bus. Dieses Dienstmerkmal ermöglicht, während einer bestehenden Verbindung einen ankommenden Anruf akustisch oder optisch zu signalisieren. Dadurch ist der Angerufene auch während eines Gesprächs für andere erreichbar. Er kann auf das Anklopfen unmittelbar reagieren, indem er die bestehende Verbindung für einen Moment unterbricht, um das zweite Gespräch anzunehmen. Dieses Hin- und Zurückschalten zwischen bisherigem Gesprächspartner und anklopfendem Teilnehmer nennt man Makeln. Falls der anklopfende Teilnehmer aktiv in die bestehende Verbindung eingeschaltet wird, entsteht eine sog. Dreierkonferenz.
www.wiwobooks.com
Mit MWI kann einem Teilnehmer auf dem Display seines IP-Telefons angezeigt werden, dass seine Mailbox eine E-Mail empfangen hat. Man spricht hier auch von E-Mail Waiting Indication (EWI). Name Identification nach H.450.8 Dieses Dienstmerkmal ermöglicht die Übermittlung der Information (z.B. Rufnummer) über einen Teilnehmer zu einem anderen Teilnehmer.
Rückrufarten
Call Completion (CC) nach H.450.9 Unter CC versteht man die Möglichkeit, dass der rufende Teilnehmer bei Besetzt bzw. bei Nichtmelden des angerufenen Teilnehmers zurückgerufen wird, falls der angerufene Teilnehmer wieder frei bzw. aktiv wird. Bei CC unterscheidet man zwischen • Rückruf bei Besetzt CCBS (Completion of Calls to Busy Subscriber); • Rückruf bei Nichtmelden CCNR (Completion of Calls on No Reply).
Warten bei Besetzt
Call Offer nach H.450.10
Eindringende Anrufe
Call Intrusion als eindringende Anrufe nach H.450.11
Dieses Dienstmerkmal bietet die Möglichkeit, dass der rufende Teilnehmer bei Besetzt des angerufenen Teilnehmers mit seinem initiierten Anruf warten kann, bis der angerufene Teilnehmer wieder frei wird. Ist der angerufene Teilnehmer frei geworden, wird ihm der neue Anruf direkt offeriert. Dieses Dienstmerkmal bietet die Möglichkeit, dass der rufende Teilnehmer A bei Besetzt des angerufenen Teilnehmers B diesen dazu veranlassen kann, entweder die bestehende Verbindung mit dem Teilnehmer C zu deaktivieren (Halten, Hold) und die Verbindung zum Teilnehmer A zu aktivieren oder den Teilnehmer A in eine Dreierkonferenz mit aufzunehmen.
6.6 Supplementary Services nach H.450.x
259
6.6.1 H.450.1 als Basis für Supplementary Services Die Basis für die Realisierung verschiedener Supplementary Services stellt der Standard H.450.1 dar. Abbildung 6.6-1 bringt dies zum Ausdruck.
H .4 5 0 .2
H .4 5 0 .1 2
C I A N S A P D U
H .4 5 0 .1 2
H .2 2 5 .0 T C P IP
H .4 5 0 .1
C T
...
H .4 5 0 .2
H .2 2 5 .0 T C P
H .2 4 5
E n d e in r ic h tu n g B
H .2 4 5
V o IP -A p p lic a tio n
...
H .4 5 0 .1
E n d e in r ic h tu n g A
V o IP -A p p lic a tio n
IP Ü b e rm ittlu n g s n e tz
Abb. 6.6-1: Bedeutung von H.450.1 – Protokolle für Supplementary Services CT: Call Transfer, CI ANS: Common Information Additional Network Service
Wie hier ersichtlich ist, nutzt H.450.1 die Funktionalität des Protokolls H.225.0 und stellt das Signalisierungsprotokoll für Supplementary Services dar. Nach H.450.1 wird eine sog. Call Independent Signalling Connection (CISC) für die Übermittlung sog. APDUs (Application Protocol Data Unit) aufgebaut. In APDUs werden die für die Realisierung von Supplementary Services benötigten Angaben zwischen den beteiligten Endkomponenten ausgetauscht. Eine APDU als UUIE (User-User Information Element) wird in einer H.225.0-Nachricht übermittelt (s. Abb.6.4-1).
www.wiwobooks.com
Die APDUs können in folgenden H.225.0-Nachrichten enthalten sein: in Setup, Call Proceeding, Alerting und Connect beim Verbindungsaufbau, in Facility und Progress während der Verbindung, in Release Complete beim Verbindungsabbau. Um die Kompatibilität zwischen den H.323-Endpunkten bei der Unterstützung von Supplementary Services zu überprüfen, spezifiziert H.450.12 das Protokoll zum Austausch von Common Information zwischen den H.323-Endpunkten. Somit können sie sich gegenseitig über sog. Additional Network Features (ANFs), d.h. über die Art und Weise der Unterstützung von Supplementary Services nach H.450.x (x = 2, ..., 11), informieren.
Funktion von H.450.12
Jeder Standard H.450.x (x = 2, 3, ..., 12) definiert bestimmte APDUs. Es sind hierbei folgende APDU-Typen zu unterscheiden:
Typen von APDUs
xxx.Invoke (Inv) als Aufruf eines Dienstes (xxx = APDU-Name), xxx.ReturnResult (RetRes) als Ergebnis des Aufrufs eines Dienstes, xxx.Reject als Absage des Aufrufs eines Dienstes, xxx.ReturnError als Fehlermeldung.
260
6
VoIP nach dem Standard H.323
6.6.2 Beispiele für Supplementary Services Im Weiteren werden einige Beispiele für den Ablauf der Signalisierungsprotokolle bei der Realisierung wichtiger Supplementary Services gezeigt.
Verlauf von Call Transfer
Beispiel 1: Call Transfer (CT) nach H.450.2 Das Prinzip von CT wird in Abbildung 6.6-2 illustriert. Stellt z.B. Teilnehmer A während eines Telefongesprächs mit Teilnehmer B fest, dass Teilnehmer B noch eine Auskunft von Teilnehmer C benötigt, initiiert Teilnehmer A noch während des Gesprächs eine neue Verbindung zu Teilnehmer C. Nach der Eingabe der Telefonnummer von Teilnehmer C sendet das Terminal von Teilnehmer A an das Terminal von Teilnehmer B die H.225.0-Nachricht Facility mit der APDU ctInitiate.Invoke. Diese APDU enthält die Identifikation der Verbindung zwischen Teilnehmer A und Teilnehmer B sowie die Adresse (Telefonnummer) von Teilnehmer C.
T ln A
V e rb in d u n g F a c ility [ c tI n itia te .I n v ]
A d r. v o n T ln C c a llId e n tity = x
T ln B S e tu p [ ..., c tS e tu p .I n v ]
R e le a s e C o m p le te [ c tI n itia te .R e tR e s ] V e rb in d u n g
T ln C
c a llId e n tity = x
C o n n e c t [ c tS e tu p .R e tR e s ] V e rb in d u n g
www.wiwobooks.com c t: c a ll tra n s fe r, In v : In v o k e , R e tR e s : R e tu rn R e s u lt
Abb. 6.6-2: Prinzip von Call Transfer nach H.450.2 Nach dem Empfang von Facility initiiert das Terminal von Teilnehmer B durch Absenden von Setup mit der APDU ctSetup.Invoke an Terminal von Teilnehmer C eine neue Verbindung. Diese APDU enthält die Identifikation der Verbindung zwischen Teilnehmern A und B. Damit kann die neue Verbindung zwischen Teilnehmer B und Teilnehmer C als Transfer der „alten“ Verbindung zwischen Teilnehmer A und Teilnehmer B angesehen werden. Das Terminal von Teilnehmer C antwortet auf Setup mit Connect, die ctSetup.ReturnResult als Antwort auf ctSetup.Invoke enthält. Mit dem Eintreffen von Connect beim Terminal von Teilnehmer B wird der Aufbau der Verbindung zwischen Teilnehmer B und Teilnehmer C beendet. Zum Schluss sendet das Terminal von Teilnehmer B an das Terminal von Teilnehmer A Release Complete mit ctInitiate.ReturnResult, um die „alte“ Verbindung zwischen Teilnehmer A und Teilnehmer B abzubauen.
Verlauf einer sofortigen Anrufweiterleitung
Beispiel 2: Sofortige Anrufweiterleitung nach H.450.3 Abbildung 6.6-3 zeigt den Verlauf einer sofortigen Anrufweiterleitung. Hier versucht Teilnehmer A eine Verbindung zu Teilnehmer B aufzubauen. Das Terminal von Teilnehmer A sendet hierfür die H.225.0-Nachricht Setup an das Terminal von Teilnehmer B. Nach dem Empfang von Setup antwortet das Terminal von Teilnehmer B mit Facility, wo sich die APDU mit CallRerouting.Invoke befindet. Mit dieser APDU wird dem Terminal von Teilnehmer A mitgeteilt, dass er die initiierte Verbindung ersatzweise zu Teilnehmer C aufbauen soll.
6.6 Supplementary Services nach H.450.x
T ln A
S e tu p
T ln B
F a c ility [ C R .I n v ] F a c ility [ C R .R e tR e s ] R e le a s e C o m p le te S e tu p V e rb in d u n g
261
T ln C
C o n n e c t
A le rtin g
C R :C a llR e ro u tin g , In v : In v o k e , R e tR e s : R e tu rn R e s u lt
Abb. 6.6-3: Verlauf einer sofortigen Anrufweiterleitung Das Terminal von Teilnehmer A bestätigt zuerst dem Terminal von Teilnehmer B den Empfang von Facility ebenfalls mit Facility und teilt ihm dann mit Release Complete mit, dass der begonnene Verbindungsaufbau rückgängig gemacht werden soll. Danach initiiert das Terminal von Teilnehmer A eine neue Verbindung zu Teilnehmer C. Der Aufbau dieser Verbindung verläuft nach H.225.0 (s. Abschnitt 6.4.2). Beispiel 3: Verlauf von Call Park and Call Pickup nach H.450.5 Call Park (Parken einer Verbindung) bedeutet, dass ein Teilnehmer eine bestehende Verbindung an einem Terminal parkt (d.h. abbricht) und dem Terminal des Kommunikationspartners angibt, von welchem anderen Terminal aus er die geparkte Verbindung wiederaufnimmt. Als Call Pickup bezeichnet man die Wiederaufnahme einer geparkten Verbindung. Abbildung 6.6-4 illustriert den Verlauf von Call Park und Call Pickup.
www.wiwobooks.com
T ln A C a ll P a rk
T e rm in a l X
T e rm in a l Y
T ln B
V e rb in d u n g
F a c ility S e tu p [ c p R e q u e s t.I n v ] [ ..., c p S e tu p .I n v ] P ro g re ss R e le a s e C o m p le te [ c p S e tu p .R e tR e s ] [ c p R e q u e s t.R e tR e s ] V e rb in d u n g
V e rb in d u n g g e p a rk t fa c ility
c p : c a ll p a rk , In v : In v o k e , R e tR e s : R e tu rn R e s u lt
C o n n e c t [ p ic k u p .I n v ]
[ p ic k u p .R e tR e s ]
T ln A
C a ll P ic k u p
V e rb in d u n g a k tiv
Abb. 6.6-4: Verlauf von Call Park and Call Pickup Um die Verbindung zu Teilnehmer B zu parken, drückt Teilnehmer A am Terminal X eine spezielle Taste und gibt an, dass er die geparkte Verbindung vom Terminal Y wiederaufnimmt. Hierbei sendet das Terminal von Teilnehmer A die H.225.0-Nachricht Facility an das Terminal von Teilnehmer B. Mit der APDU cpRequest.Invoke in dieser Nachricht wird dem Terminal von Teilnehmer B mitgeteilt, dass die geparkte Verbindung vom Terminal Y wiederaufgenommen wird. cpRequest.Invoke enthält somit die Adresse von Terminal Y.
Verlauf von Call Park and Call Pickup
262
6
VoIP nach dem Standard H.323
Nach dem Empfang von Facility initiiert das Terminal von Teilnehmer B mit der H.225.0Nachricht Setup eine Verbindung zu Terminal Y. Mit cpSetup.Invoke wird dem Terminal Y angegeben, dass es sich um eine geparkte (deaktivierte) Verbindung handelt, die zu einem späteren Zeitpunkt wiederaufgenommen wird. Auf Setup antwortet das Terminal Y mit der H.225.0Nachricht Progress. Hat das Terminal von Teilnehmer B Progress empfangen, besteht eine geparkte Verbindung zwischen dem Terminal von Teilnehmer B und dem Terminal Y. Das Terminal von Teilnehmer B sendet noch Release Complete an das Terminal von Teilnehmer A, um die Verbindung zum Terminal X abzubauen. Aktiviert der Teilnehmer A am Terminal Y die geparkte Verbindung zum Terminal von Teilnehmer B, sendet das Terminal Y die H.225.0-Nachricht Connect an das Terminal von Teilnehmer B. Die APDU pickup.Invoke in dieser Nachricht teilt dem Terminal von Teilnehmer B mit, dass die geparkte Verbindung nun aktiviert wird. Das Terminal von Teilnehmer B antwortet darauf mit Facility, in der pickup.ReturnResult enthalten ist. Damit wurde die geparkte Verbindung am Terminal Y wiederaufgenommen.
6.7 Begriff: Roaming
Roaming bei VoIP nach H.323
Bei VoIP besteht der Wunsch nach uneingeschränkter Mobilität. Ein Teilnehmer sollte daher u.a. die Möglichkeit haben: seinen tragbaren Rechner an jeder Netzwerksteckdose seines Unternehmens als sein IPTelefon und mit der Telefonnummer zu nutzen, die auch an seinem „Stamm“-Arbeitsplatz gilt;
www.wiwobooks.com
die an seiner Telefonnummer ankommenden Anrufe zu dem IP-Telefon umzuleiten, das der Teilnehmer aktuell nutzt; einen fremden Rechner in einer anderen Abteilung, in der er sich vorläufig aufhält, als sein vorläufiges IP-Telefon mit der Telefonnummer von seinem „Stamm“-Arbeitsplatz zu nutzen. Eine derartige Mobilität bezeichnet man als Discrete Mobility, Teilnehmer-Roaming bzw. kurz Roaming. Dies lässt sich in VoIP-Systemen nach H.323 mit Hilfe des Standards H.510 erreichen. Den mit der Mobilität von Teilnehmern verbundenen Sicherheitsaspekten widmet sich Standard H.530.
6.7.1 Arten von Roaming Roaming innerhalb einer Domain
Wie bereits erwähnt wurde, bildet ein Netzwerk einer großen administrativen Einheit aus Sicht von VoIP nach H.323 eine Domäne (Domain), die sich aus mehreren Zonen zusammensetzt (s. Abb. 6.1-2). Daher unterscheidet man bei der Mobilität innerhalb einer Domain zwischen IntraZone-Roaming und Inter-Zone-Roaming. Diese Art der Mobilität innerhalb einer Domain, die man auch als Intra-Domain-Roaming bezeichnet, illustriert Abbildung 6.7-1.
Intra-ZoneRoaming
Beim Intra-Zone-Roaming (s. Abbildung 6.7-1a) bewegt sich Teilnehmer A nur innerhalb einer Zone. Diese Roaming-Art wird bereits bei H.323 unterstützt. Beim Verlassen des IP-Telefons mit der IP-Adresse X muss Teilnehmer A sich zuerst beim Gatekeeper deregistrieren. Damit wird die Zuordnung Telefonnummer IP-Adresse (hier n X) beim Gatekeeper der Zone ZA „gestrichen“. Dies bedeutet, dass Teilnehmer A seine Telefonnummer vorläufig abgemeldet hat. Teilnehmer A bewegt sich nun zum IP-Telefon mit der IP-Adresse Y und lässt sich hier registrieren. Damit wird die Zuordnung: n Y beim Gatekeeper der Zone ZA eingetragen. Somit hat Teil-
6.7 Roaming bei VoIP nach H.323
263
nehmer A seine Telefonnummer n wieder angemeldet. Er ist ab jetzt in der Zone ZA unter seiner Telefonnummer n über die IP-Adresse Y erreichbar.
a )
H e im a tz o n e v o n T ln A
Y
Z
b )
D o m a in G G K
...
A
A
X n
Z
G K N
F re m d zo n e v o n T ln A
Z
N
T ln A
A
D o m a in G G K
... A
Z
n Y
N
G K N
X
T ln A
n : T e le fo n n u m m e r; X , Y : IP -A d re s s e n
H e im a tz o n e v o n T ln A
Abb. 6.7-1: Roaming innerhalb einer Domain: a) Intra-Zone-Roaming; b) Inter-Zone-Roaming GK: Gatekeeper, Tln: Teilnehmer, Z: Zone
Falls es sich um Inter-Zone-Roaming handelt, verlässt Teilnehmer A nun eine Zone und bewegt sich in eine andere Zone hinein (Abb. 6.7-1b). Er bleibt jedoch in der gleichen Domain. Um diese Art der Mobilität zu unterstützen, muss man auf das Konzept von H.510 zugreifen.
Inter-ZoneRoaming
Zwischen administrativen Einheiten, wie z.B. zwischen kooperierenden Unternehmen, kann ein Abkommen, ein sog. SLA (Service Level Agreement), vereinbart werden, um das Roaming zwischen den H.323-Domains dieser Unternehmen zu ermöglichen. Abbildung 6.7-3 illustriert ein derartiges Roaming.
Roaming zwischen Domains
www.wiwobooks.com
U n te r n e h m e n G
... Z
F re m d zo n e v o n T ln A
D o m a in G
G K X
H e im a tz o n e v o n T ln A
S L A
X
L S A
Y
U n te r n e h m e n H
D o m a in H L S
T R IP n
n : T e le fo n n u m m e r, X , Y : IP -A d re s s e n
B
Z
G K Y
Y
...
X T ln A
Abb. 6.7-2: VoIP-Roaming zwischen H.323-Domains LS: Location-Server, Tln: Teilnehmer, TRIP: Telephony Routing over IP
Hier verlässt Teilnehmer A die Domain H und bewegt sich in die Domain G hinein. Also handelt es sich in diesem Fall um Inter-Domain-Roaming. Diese Art der Mobilität lässt sich mit dem Konzept von H.510 verwirklichen. Um VoIP zwischen administrativen Einheiten und damit auch zwischen verschiedenen Domains zu unterstützen, müssen sich die beiden Domains die Anrufziele gegenseitig mitteilen. Hierfür kann das Protokoll TRIP (Telephony Routing over IP) zum Einsatz kommen (s. Abschnitt 9.2). Um Roaming zu unterstützen, müssen in den Domains zusätzliche Komponenten eingesetzt werden. Wie Abbildung 6.7-3 zeigt, werden für Roaming folgende Komponenten definiert:
Komponenten für die Home Location Function (HLF) – Bei HLF handelt es sich um eine Datenbank, die in jeder UnterstütDomain vorhanden sein muss, um Roaming zu ermöglichen. Die HLF einer Domain enthält zung von die Angaben (Name, Telefonnummer,...) über mobile Teilnehmer, die in der Domain behei- Roaming matet sind. Für jeden eingetragenen Teilnehmer enthält HLF auch einen Verweis auf eine Datenbank VLF, wo die aktuelle Lokation des Teilnehmers abgefragt werden kann.
264
6
VoIP nach dem Standard H.323 F re m d -D o m a in
Z G a st
A
H e im a t-D o m a in H L F /A u F
...
F re m d zo n e v o n T ln A
G K B
Z B
B E L S V L F
B E 1
T R IP 1
n
T ln A
L S
H L F /A u F 2
V L F
Z
Z
...
2
X
Y
H e im a tz o n e v o n T ln A
G K Y
Abb. 6.7-3: HLF, VLF und AuF als Komponenten für die Unterstützung von Roaming BE: Border Element, GK: Gatekeeper, LS: Location-Server, Tln: Teilnehmer, Z: Zone
Visitor Location Function (VLF) – VLF ist eine Besucherdatenbank, die in jeder Domain vorhanden sein muss. In der VLF einer Domain werden alle Teilnehmer eingetragen, die sich aktuell in der Domain aufhalten. Das sind die Teilnehmer, die in der Domain zu Gast oder beheimatet sind und die Domain noch nicht verlassen haben. Hält sich ein Teilnehmer in einer Domain auf, bedeutet dies, dass seiner Telefonnummer in der Domain eine IP-Adresse aktuell zugeordnet worden ist. Ein entsprechender Eintrag mit dieser Zuordnung wird bei einem Gatekeeper der Domain abgespeichert. Der Eintrag in VLF über diesen Teilnehmer enthält nur einen Verweis auf den betreffenden Gatekeeper. Bemerkung: Roaming nach H.510 erfolgt nach den gleichen Prinzipien wie in Mobilfunknetzen (GSM, UMTS), sodass HLF mit HLR und VLF mit VLR vergleichbar ist (s. Abb. 1.3-1 und -4).
www.wiwobooks.com
Authentication Function (AuF) – Ein mobiler Teilnehmer wird nur dann in eine Zone aufgenommen, d.h. seiner Telefonnummer eine IP-Adresse zugeordnet, falls er über die notwendigen Zugangsrechte verfügt. Aus diesem Grund müssen zuerst seine Zugangsrechte abgefragt werden, bevor ein mobiler Teilnehmer in eine Zone aufgenommen wird. Hierfür wird die Funktionskomponente AuF genutzt.
6.7.2 Registrierung eines Gast-Teilnehmers Um in einem IP-Netzwerk telefonieren zu können, muss bekannt sein, unter welchen IP-Adressen die einzelnen Telefonnummern erreichbar sind. Hierfür werden die Tabellen mit der Zuordnung Telefonnummer IP-Adresse geführt. Für die Pflege dieser Tabellen sind die Gatekeeper verantwortlich. Ein Teilnehmer kann nur dann Telefonanrufe initiieren bzw. angerufen werden, wenn er bereits bei einem Gatekeeper registriert ist. Erst dann kann er im Netzwerk bekannt geben, unter welcher IP-Adresse seine Telefonnummer zu erreichen ist. Ein Teilnehmer als Gast in einer Fremdzone muss sich also bei einem Gatekeeper registrieren. Hierbei unterscheidet man zwischen: Registrierung in einer Fremdzone der Heimat-Domain Registrierung in einer Fremdzone einer Fremd-Domain
Registrierung in einer Fremdzone der HeimatDomain
Abbildung 6.7-4 illustriert den Verlauf der Registrierung beim Gatekeeper in einer Fremdzone der Heimat-Domain. Es handelt sich in diesem Fall um Mobilität innerhalb einer Domain. Teilnehmer A benutzt hier in der Zone ZA das IP-Telefon mit der IP-Adresse X. Nun hat er die Zone gewechselt und möchte für sich ein IP-Telefon in der neuen Zone ZB einrichten. Hierfür kommen zwei Möglichkeiten in Frage: a)
Teilnehmer A hat in der alten Zone ZA seinen tragbaren Rechner mit einem Telefonset als IP-Telefon benutzt. In der Zone ZA gehörte der Rechner zu IP-Subnetz i, und ihm wurde die
6.7 Roaming bei VoIP nach H.323 IP-Adresse X durch einen DHCP-Server dynamisch zugeordnet. Teilnehmer A hat nun den Netzwerkanschluss gewechselt und seinen tragbaren Rechner mitgenommen. Der neue Netzwerkanschluss gehört zu IP-Subnetz j, und dementsprechend wurde seinem Rechner hier die IP-Adresse Y dynamisch zugeordnet. Dieser Rechner soll nun auch als IP-Telefon dienen. b)
Teilnehmer A hat in der alten Zone ZA ein „stationäres“ IP-Telefon mit der IP-Adresse X benutzt. Er hat nun vorläufig seinen Arbeitsplatz gewechselt und möchte an der neuen Stelle das IP-Telefon mit der IP-Adresse Y benutzen und seine Telefonnummer beibehalten. H e im a t-D o m a in G a st
Z Y 1
R R Q
B
n T ln A
F re m d zo n e v o n T ln A
G K
R IP R C F /R R J
V L F B
H e im a tz o n e v o n T ln A
...
H L F
Z G K
A
A
X
D U
D U D U A c k
D U : D e s c rip to rU p d a te D U A c k : D e s c rip to rU p d a te A c k n : T e le fo n n u m m e r, X , Y : IP -A d re s s e n
2
D U A c k D U
D U A c k
U R Q U C F
Abb. 6.7-4: Registrierung eines Teilnehmers in einer Fremdzone der Heimat-Domain
www.wiwobooks.com
Abkürzungen wie in Abb. 6.7-3
Bei der Registrierung in Abbildung 6.7-4 sind die beiden folgenden Phasen zu unterscheiden: 1.
Anmeldung des Teilnehmers A in einer Fremdzone seiner Heimat-Domain: Die Anmeldung des Teilnehmers A erfolgt durch die Registrierung beim Gatekeeper GKB (s. Abschnitt 6.3.2). Hierfür sendet das IP-Telefon RRQ (RegistrationRequest) mit der Angabe der Telefonnummer n vom Teilnehmer A. GKB bestätigt den Empfang von RRQ mit RIP (Request in Progress) und teilt mit, dass der Request bearbeitet wird. Da GKB die IPAdresse des IP-Telefons ebenfalls kennt (aus dem Header des empfangenen IP-Pakets mit RRQ), wird nun der Eintrag mit der Zuordnung: n Y (Telefonnummer IP-Adresse) bei ihm abgespeichert. GKB muss zusätzlich in der Besucherdatenbank VLF eintragen lassen, dass er ab sofort einen neuen Teilnehmer mit der Telefonnummer n „betreut“. Hierfür sendet GKB eine H.510-Nachricht Descriptor Update (DU) an VLF. Nach dem Empfang dieser Nachricht wird in VLF eingetragen, dass GKB für die Telefonnummer n zuständig ist. VLF sendet nun eine Nachricht DU an die Datenbank HLF mit allen Heimatteilnehmern, um auch dort dieses Roaming zu erfassen. HLF bestätigt für VLF den Empfang von DU mit einer H.510-Nachricht Descriptor UpdateAck (DUAck). Nach Empfang von DUAck bestätigt VLF dem GKB den Empfang von DU ebenfalls mit DUAck. Ist die Registrierung fehlerfrei abgelaufen, wird dies dem IP-Telefon durch den GKB mit der H.225.0-Nachricht RCF (RegistrationConfirm) signalisiert. Konnte die Registrierung aus einem Grund nicht zustande kommen, teilt dies GKB dem IP-Telefon mit RRJ (RegistrationReject) mit. Teilnehmer A muss jetzt noch in seiner Heimatzone abgemeldet werden.
2. Abmeldung des Teilnehmers A in seiner Heimatzone beim Aufenthalt in der HeimatDomain: Die Abmeldung des Teilnehmers A wird von VLF durch das Absenden von DU an den Gatekeeper GKA seiner Heimatzone initiiert. Damit wird dem GKA mitgeteilt, dass der Eintrag mit der Zuordnung n X (Telefonnummer IP-Adresse) ab sofort bei ihm gestrichen werden muss. Teilnehmer A mit der Telefonnummer n ist bereits im IP-Netzwerk un-
265
266
6
VoIP nach dem Standard H.323 ter der IP-Adresse Y registriert. Somit wird nun das IP-Telefon mit der IP-Adresse X in der Zone ZA deregistriert. Hierfür sendet GKA die H.225.0-Nachricht URQ (UnregistrationRequest) an das IP-Telefon. Als Antwort darauf sendet das IP-Telefon UCF (UnregistrationConfirm). Nach dem Empfang von UCF bestätigt GKA die Nachricht DU von VLF mit DUAck. Damit wurde Teilnehmer A in seiner Heimatzone abgemeldet.
Abbildung 6.7-5 zeigt den Verlauf der Registrierung, falls ein Teilnehmer nicht nur seine Heimatzone verlassen hat, sondern auch seine Heimat-Domain.
G a st
Registrierung in einer Fremdzone einer FremdDomain
Z
... ...
R o a m in g F re m d D o m a in A
H L F
X
F re m d zo n e v o n T ln A
1
Z
R R Q
B
G K
R IP R C F /R R J
L S
n
H e im a tD o m a in
T ln A 1
T R IP
V L F
L S
B
D U D U A c k
D U : D e s c rip to rU p d a te D U A c k : D e s c rip to rU p d a te A c k n : T e le fo n n u m m e r
H L F 2
V L F
D U
... Z Y
Z X
H e im a tz o n e v o n T ln A
G K
X Y
D U A c k 2
D U D U A c k D U
U R Q D U A c k
U C F
www.wiwobooks.com
Abb. 6.7-5: Registrierung beim Gatekeeper in einer Fremdzone einer Fremd-Domain LS: Location-Server, RCF: RegistrationConfirm, RRQ: RegistrationRequest, RIP: Request in Progress, Tln: Teilnehmer, TRIP: Telephony Routing over IP, UCF: UnregistrationRequest, URQ: UnregistrationRequest
Die Registrierung beim Gatekeeper in einer Fremdzone einer Fremd-Domain verläuft in den beiden folgenden Phasen: 1.
Anmeldung des Teilnehmers A in einer Fremdzone einer Fremd-Domain: Diese Phase verläuft nach dem gleichen Schema wie in Abbildung 6.7-4. Der einzige Unterschied besteht darin, dass VLF aus der Fremd-Domain nun an HLF in der Heimat-Domain eine Nachricht DU schickt. In DU wird der HLF mitgeteilt, dass Teilnehmer A mit der Telefonnummer n sich aktuell in der Fremd-Domain aufhält. In HLF wird bei der Telefonnummer n die IPAdresse der VLF eingetragen, von der die Nachricht DU darüber empfangen wurde. Sollte HLF in der Heimat-Domain eine Anfrage vom Gatekeeper in der Nachricht AccessRequest (AccRQ) nach der „Lokation“ der Telefonnummer n empfangen haben, kann HLF diese Angabe von der VLF in der Fremd-Domain abfragen (s. Schritt 1 in Abb. 6.7-7). Bemerkung: VLF aus der Fremd-Domain muss die IP-Adresse der HLF in der Heimat-Domain kennen. Dies wäre mit Hilfe von TRIP möglich.
2.
Abmeldung des Teilnehmers A in der Heimatzone beim Aufenthalt in einer Fremd-Domain: Da HLF die Nachricht, dass Teilnehmer A mit der Telefonnummer n seine Heimat-Domain verlassen hat, bereits von VLF aus einer anderen Domain erhalten hat, muss HLF die Abmeldung des Teilnehmers A in seiner Heimat-Domain initiieren. Zuerst teilt HLF dies VLF mit, um Teilnehmer A aus der Besucherliste bei VLF zu streichen. Dann signalisiert VLF dies dem Gatekeeper GKY. Zum Schluss teilt GKY mit der H.225.0-Nachricht UQR dem IPTelefon mit der IP-Adresse X mit, dass er die Zuordnung n X (Telefonnummer IPAdresse) bei sich „gestrichen“ hat. Damit wurde Teilnehmer A deregistriert. Die hier gezeigten Nachrichten haben die gleiche Bedeutung wie in Abbildung 6.7-4.
6.7 Roaming bei VoIP nach H.323
267
6.7.3 Ankommender Anruf zu einem Gast-Teilnehmer Der Ablauf der Protokolle bei einem ankommenden Anruf zu einem Gast-Teilnehmer einer Fremdzone seiner Heimat-Domain zeigt Abbildung 6.7-6.
n
G a st T ln A
Z B
G K
Y
X
T ln A
...
F re m d zo n e v o n T ln A
Z
V L F B
H L F A c c R Q
1
3
A R Q
4 5
L R Q
A
A c c C F
T ln B
H e im a tz o n e v o n T ln A
G K A c c R Q A c c C F
L C F
Z
A
A R Q A C F
S e tu p
2
A C F A le rtin g
C o n n e c t A u fb a u R T P - u n d R T C P -K a n ä le u n d S p a c h k o m m u n ik a tio n R e le a s e C o m p le te
6
A c c R e q : A c c e s s R e q u e s t, A c c C n f: A c c e s s C o n firm a tio n , n : T e le fo n n u m m e r
www.wiwobooks.com
Abb. 6.7-6: Ankommender Anruf zu einem Gast bei Intra-Domain-Roaming GK: Gatekeeper, HLF: Home Location Function, Tln: Teilnehmer, VLF: Visitor Location Function, Z: Zone
Hier sind folgende Schritte zu unterscheiden: 1.
Abfrage der IP-Adresse des Telefons des mobilen Teilnehmers A: Teilnehmer B aus der Heimatzone des Teilnehmers A initiiert eine Verbindung zu Teilnehmer A. Sein IP-Telefon sendet damit eine H.225.0-Nachricht ARQ (AdmissionRequest) an den Gatekeeper GKA mit der Telefonnummer n von Teilnehmer A, um u.a. die IP-Adresse seines IP-Telefons zu ermitteln. Da sich Teilnehmer A bereits in seiner Heimatzone durch die Deregistrierung beim GKA abgemeldet hat, verfügt GKA jedoch nicht mehr über die ihn betreffende Zuordnung Telefonnummer IP-Adresse. GKA fragt somit mit AccessRequest (AccRQ) bei der Datenbank HLF nach der Lokation von Teilnehmer A nach. Da HLF nicht über die Angaben zur Lokation verfügt, sondern nur über die Verweise auf die Besucherdateien VLFs, leitet HLF nun die Nachricht AccReq an VLF weiter. VLF antwortet mit AccessConfirm (AccCF), in der die IP-Adresse des zuständigen Gatekeepers GKB, bei dem die IP-Adresse des Telefons vom Teilnehmer A abgefragt werden kann, enthalten ist. HLF übergibt diese Angabe mit AccCF an den GKA, und dieser fragt beim GKB mit der H.225.0-Nachricht LRQ (LocationReQuest) nach der IP-Adresse des Telefons, dem die Telefonnummer n des mobilen Teilnehmers A aktuell zugeordnet wurde. Die gewünschte IP-Adresse übermittelt GKB in LCF (LocationConfirm). GKA leitet diese Angabe an das IP-Telefon von Teilnehmer B in ACF (AdmissionConfirm) weiter.
2.
Initiieren des Anrufs an den Teilnehmer A: Dem IP-Telefon von Teilnehmer B ist die IPAdresse des IP-Telefons von Teilnehmer A bereits bekannt. Damit initiiert das IP-Telefon von Teilnehmer B einen Anruf an Teilnehmer A durch das Absenden einer H.225.0-
IntraDomainRoaming
268
6
VoIP nach dem Standard H.323 Nachricht Setup an sein IP-Telefon. Damit wurde der Aufbau einer logischen Verbindung zum IP-Telefon von Teilnehmer A initiiert. Um Setup jedoch senden zu können, muss zuerst eine TCP-Verbindung aufgebaut werden, was hier nicht dargestellt wurde.
3.
Zulassen des ankommenden Anrufs für Teilnehmer A: Nach dem Empfang von Setup muss das IP-Telefon von Teilnehmer A die Erlaubnis, den ankommenden Anruf annehmen zu dürfen, bei seinem Gatekeeper GKB einholen. Dies erfolgt mit AdmissionReQuest (ARQ). Falls die Überprüfung beim GKB zu einem positiven Ergebnis geführt hat, antwortet er mit AdmissionConfirm (ACF).
4.
Annahme des ankommenden Anrufs durch den Gast-Teilnehmer A: Nach der Zulassung des ankommenden Anrufs vom GKB und der Prüfung der Kompatibilität (z.B. ob die beiden IPTelefone die gleiche Sprachcodierung unterstützen) kann nun der ankommende Anruf entgegengenommen werden. Die Bereitschaft zur Annahme des Anrufs wird durch das IPTelefon von Teilnehmer B mit Alerting signalisiert und gleichzeitig das Klingeln des Telefons bei Teilnehmer B aktiviert. Hat Teilnehmer B den Anruf entgegengenommen, wird dies dem IP-Telefon von Teilnehmer B mit Connect signalisiert.
5.
Aufbau der RTP- und RTCP-Kanäle und Telefongespräch
6.
Abbau der Verbindung: Wurde das Gespräch beendet, müssen nun die RTP- und RTCPKanäle abgebaut werden. Dies kann von jeder Seite durch Absenden einer H.225.0Nachricht Release Complete veranlasst werden. Zum Schluss muss noch die bestehende TCP-Verbindung abgebaut werden, die noch vor dem Absenden von Setup aufgebaut wurde. Dies wurde hier nicht dargestellt.
www.wiwobooks.com n
Z
G a st
Z B
. . .A
R o a m in g
F re m d D o m a in
...
F re m d zo n e v o n T ln A
G K
T ln A
H e im a tD o m a in
H L F
Z
H L F
T ln A A c c C F 1
Z
V L F V L F
B
H e im a tz o n e v o n T ln A
L C F
A c c R Q L R Q
Y
A c c R Q A c c C F S e tu p
X
...
G K Y
T ln B
A R Q A C F 2
S ig n a lis ie r u n g n a c h H .3 2 3 A c c R e q : A c c e s s R e q u e s t, A c c C n f: A c c e s s C o n firm a tio n ,
n :T e le fo n n u m m e r
Abb. 6.7-7: Ankommender Anruf zu einem Gast-Teilnehmer bei Inter-Domain-Roaming Abkürzungen wie in Abb. 6.7-6
InterDomainRoaming
Nach dem gleichen Prinzip, wie Abbildung 6.7-6 zeigt, verlaufen auch die Protokolle bei einem ankommenden Anruf zu einem „Gast“ in einer Fremdzone einer Fremd-Domain. Eine derartige Situation illustriert Abbildung 6.7-7. Es handelt sich hier um die gleichen Schritte wie in Abbildung 6.7-6 mit einem kleinen Unterschied in Schritt 1, auf den nur hinzuweisen ist. Bei der Abfrage der IP-Adresse des Telefons von Teilnehmer A im Schritt 1 wendet sich nun HLF der Heimat-Domain an VLF der Fremd-Domain, um die Angaben über die Lokation (als IP-Adresse eines Gatekeepers) von Teilnehmer A zu erhalten, bei dem man wiederum die IP-Adresse des IP-Telefons von Teilnehmer A abfragen könnte.
6.7 Roaming bei VoIP nach H.323
6.7.4 Abgehender Anruf aus einer Fremd-Domain Den Ablauf der Protokolle bei einem abgehenden Anruf vom Gast-Teilnehmer in einer FremdDomain zeigt Abbildung 6.7-8. R o a m in g n
Z . . .A
F re m d D o m a in
...
H L F
F re m d zo n e v o n T ln A
G a st
Z
T ln A 1 2
B
A R Q
T ln A
G K B
R o u te ?
S e tu p
Z
H L F L S
L S
V L F
A C F
T R IP
H e im a tD o m a in
V L F
X
...
H e im a tz o n e v o n T ln A
G K Y
Z
Y
T ln B L R Q L C F
S ig n a lis ie r u n g n a c h H .3 2 3
n : T e le fo n n u m m e r
Abb. 6.7-8: Abgehender Anruf von einem Gast-Teilnehmer bei Inter-Domain-Roaming GK: Gatekeeper, HLF: Home Location Function, LS: Location-Server, Tln: Teilnehmer, TRIP: Telephony Routing over IP, VLF: Visitor Location Function, Z: Zone
www.wiwobooks.com
Bei einem abgehenden Anruf aus einer Fremd-Domain unterscheidet man folgende Schritte: 1.
Abfrage der IP-Adresse des Telefons vom Gesprächspartner: Teilnehmer A in einer FremdDomain initiiert eine Verbindung zu Teilnehmer B in seiner Heimat-Domain. Sein IP-Telefon sendet ARQ(AdmissionRequest) an den Gatekeeper GKB mit der Telefonnummer von Teilnehmer B, um u.a. die IP-Adresse seines IP-Telefons zu ermitteln. Die Vorwahl in der Telefonnummer von Teilnehmer B verweist aber auf eine andere Domain. Hier kommt das Protokoll TRIP zum Einsatz. GKB fragt beim Location-Server (LS) seiner Domain nach der Route zum Gatekeeper, der den Teilnehmer B „betreut“. LS liefert dem GKB die IP-Adresse des gewünschten Gatekeepers GKY. GKB fragt den GKY mit der Nachricht LRQ nach der IP-Adresse des Telefons von Teilnehmer B. GKY liefert dem GKB die gewünschte IPAdresse in der Nachricht LCF zurück (vgl. Abb. 6.7-6). GKB übermittelt nun diese IPAdresse dem IP-Telefon von Teilnehmer A.
2.
Aufbau einer virtuellen Verbindung für die Sprachübermittlung: Das IP-Telefon von Teilnehmer A kennt nun die IP-Adresse des IP-Telefons von Teilnehmer B. Somit kann es eine direkte virtuelle Verbindung durch Absenden der H.225.0-Nachricht Setup initiieren.
6.7.5 Deregistrierung eines Gast-Teilnehmers Möchte ein Gast-Teilnehmer eine Zone verlassen, muss er sich beim Gatekeeper dieser Zone abmelden. Nach H.323 bezeichnet man diesen Vorgang als Deregistrierung. Den Verlauf einer Deregistrierung beim Verlassen einer Fremdzone einer Fremd-Domain zeigt Abbildung 6.7-9. Die Deregistrierung initiiert hier das IP-Telefon durch Absenden einer H.225.0-Nachricht URQ (UnregistrationRequest) an den Gatekeeper GKB. Er bestätigt den Empfang von URQ mit der Nachricht RIP (Request in Progress) und teilt mit, dass diese Anforderung bearbeitet
269
270
6
VoIP nach dem Standard H.323
wird. Dies führt nun dazu, dass der Eintrag mit der Zuordnung: n Adresse) beim GKB „gestrichen“ wird.
R o a m in g H e im a tD o m a in
n
Z G a st T ln A
A
F re m d D o m a in
...
H L F
F re m d zo n e v o n T ln A
Z
X
U R Q
B
G K
R IP U C F /U R J
L S
T ln A 1
L S
T R IP
D U
2
V L F
V L F B
D U
D U A c k
X (Telefonnummer
H L F G K
Z
IP-
X
...
H e im a tz o n e v o n T ln A Y
Z
Y
D U A c k
D U : D e s c rip to rU p d a te D U A c k : D e s c rip to rU p d a te A c k n : T e le fo n n u m m e r X : IP -A d re sse
R IP : R e q u e s t in P ro g re s s
Abb. 6.7-9: Deregistrierung eines Teilnehmers in einer Fremdzone einer Fremd-Domain Abkürzungen wie in Abb. 6.7-8
Die Streichung des Eintrags mit der Telefonnummer n von Teilnehmer A wird der VLF der Fremd-Domain mit der H.510-Nachricht DescriptorUpdate (DU) gemeldet. VLF nimmt Teilnehmer A nun aus der Besucherliste und übermittelt die Information darüber weiter an HLF seiner Heimat-Domain. Hier wird im Eintrag, der dem Teilnehmer A entspricht, der Verweis auf die VLF der Fremd-Domain gelöscht und dies der VLF mit der H.510-Nachricht DescriptorUpdateAck (DUAck) bestätigt. VLF signalisiert dies ebenfalls dem GKB mit DUAck und bestätigt damit seine Nachricht DU. Den fehlerfreien Verlauf der Deregistrierung teilt GKB dem ehemaligen IP-Telefon von Teilnehmer A mit der H.225.0-Nachricht UCF (UnregistrationConfirm) mit. Konnte die Deregistrierung aus irgendeinem Grund nicht durchgeführt werden, wird dies dem IP-Telefon mit der H.225.0-Nachricht URJ (UnregistrationReject) signalisiert.
www.wiwobooks.com
Nach der Deregistrierung ist die Telefonnummer n von Teilnehmer A in der HLF seiner HeimatDomain zwar eingetragen, doch ist diese Telefonnummer nicht mehr erreichbar, weil ihr keine IP-Adresse und somit auch kein IP-Telefon zugeordnet ist.
6.8
Schlussbemerkungen
H.323 ist ein Rahmenwerk – auch als Umbrella Standard bezeichnet –, das beschreibt, wie u.a. die Protokolle H.225.0, H.245 sowie RTP und RTCP zusammenwirken müssen, um die Audio- und Video-Kommunikation über IP-Netze zu ermöglichen. Hervorzuheben sind hier die Standards der Reihe H.460.x, in denen diverse Aspekte als H.323-Erweiterungen spezifiziert werden. Weil H.323 ein sehr komplexes Rahmenwerk darstellt, war eine detaillierte Beschreibung von H.323 in diesem Kapitel nicht möglich. Entwicklung von H.323
Die erste Version von H.323 wurde bereits 1996 veröffentlicht. Inzwischen hat man H.323 aber kontinuierlich modifiziert und erweitert, sodass es bereits sieben H.323-Versionen gibt. Die bisherige Entwicklung von H.323 stellen die folgenden Web-Seiten dar:
6.8 Schlussbemerkungen
271
H.323 Forum: http://www.h323forum.org/standards Hier werden die einzelnen Versionen von H.323 aufgelistet. Zu jeder Version erhält man fundierte Informationen, inwiefern sie sich von der Vorversion unterscheidet. Außerdem findet man hier eine Auflistung aller Protokolle (inkl. Annexs) – sowohl der als Bestandteile von H.323 geltenden als auch der in irgendeiner Form mit H.323 zusammenhängenden. von Packetizer: − http://www.packetizer.com/ipmc/h323/standards.html
Hier finden Sie eine Auflistung von Links zu den Spezifikationen sowohl aller Versionen von H.323 als auch der entsprechenden Versionen der Protokolle H.225.0 und H.245 – ein Eldorado für alle, die H.323relevante Dokumente suchen. − http://www.packetizer.com/ipmc/h323/doc-status.html
Hier wird die ganze H.323-Entwicklung fundiert dargestellt. Hervorzuheben ist der „H.323 Implementers Guide“. Die Links zu den Spezifikationen aller Versionen von H.323 inkl. all ihrer Bestandteile laden zum Herunterladen ein. H.225.0 – als Bestandteil von H.323 – beschreibt die Prinzipien für den Entwicklung Auf- und Abbau eines Steuerungskanals für das Protokoll H.245. Eine wich- von H.225.0 tige Besonderheit von H.225.0 besteht darin, dass es die Nachrichten des ISDN-Kanal-Protokolls Q.931 verwendet. Bei VoIP nach H.323 wird somit u.a. das ISDN-D-Kanal-Protokoll über TCP-Verbindungen abgewickelt.
www.wiwobooks.com
Auch H.225.0 wurde ständig modifiziert und erweitert, sodass bereits sieben Versionen von H.225.0 vorliegen. Die Spezifikation der neuesten Version H.225.0v7 sollte im November 2009 freigegeben werden. Die Spezifikation von H.225.0 können Sie auf der Webseite von Packetizer herunterladen. Das Protokoll H.245, nach dem die RTP- und RTCP-Kanäle für den Transport Entwicklung von Echtzeitdaten auf- und abgebaut werden, wurde fast jährlich modifiziert. von H.245 Man unterscheidet bereits vierzehn Versionen von H.245. Die Links zu den Spezifikationen von H.245 finden Sie auch auf der Webseite von Packetizer. Eine Weiterentwicklung von H.323 – s. H.323v5, 2003 (Annex O – Use of H.323 und URL and DNS) – hat dazu geführt, dass DNS für die Zuordnung von Telefon- Nutzung von nummern zu IP-Adressen sowie für die Ermittlung der IP-Adresse eines Gate- DNS keepers in einer anderen Domain (s. Abb. 6.1-2) eingesetzt werden kann. Mit der Einführung von H.323 URL in der Form user@host, wobei user eine Telefonnummer darstellt, lässt sich DNS für die Ermittlung von IP-Adressen der IP-Telefone verwenden. Um die IP-Adresse des Gatekeepers in einer anderen Domain zu ermitteln und damit die VoIP-Kommunikation über mehrere Domains zu ermöglichen, wie dies bei VoIP mit SIP der Fall ist, wurden Mechanismen für die Nutzung der Resource Records (RRs) vom Typ SRV geschaffen
272
6
VoIP nach dem Standard H.323
(s. Abb. 3.5-5). Hierfür wurden folgende Services definiert: Location Service h323ls, Registration Service h323rs, Call Signalling h323cs und Border Element h323bs. Bei der Abfrage der IP-Adresse des Gatekeepers in der Domain xyz.de beispielsweise wird der vollständige Service-Name _h323ls._udp.xyz.de gebildet, danach der RR SRV der Zonendatei der Domain xyz.de abgefragt, um den Hostnamen des Gatekeepers in xyz.de zu ermitteln. Abschließend wird die IP-Adresse für diesen Hostnamen mit Hilfe einer A-Query beim DNS abgefragt (vgl. Abb. 3.5-6). Die Ermittlung der IP-Adresse des Gatekeepers in einer anderen Domain verläuft weitgehend nach den in Abschnitt 3.5.4 dargestellten Prinzipien. H.323 und Sicherheit
Auf VoIP-Systeme nach H.323 kann man unterschiedliche Angriffe vornehmen. Um die damit verbundenen Sicherheitsrisiken zu vermeiden, wurde der Standard H.235 entwickelt. Es liegen bereits drei H.235-Versionen vor. H.235 beschreibt die Prinzipien, nach denen sich die Übermittlung sowohl der Signalisierung nach H.225.0 als auch Echtzeitmedien (Audio,Video) sichern lässt. Hierfür werden in H.235 diverse Sicherheitsverfahren vorgeschlagen. Für ihre Realisierung definiert H.235 mehrere sog. CryptoTokens, in denen die notwendigen Angaben und Parameter für die Sicherheitsvereinbarungen zwischen den kommunizierenden Komponenten übermittelt werden können. H.235 definiert auch mehrere Prozeduren, mit denen die Risiken infolge bestimmter Angriffsarten vermieden werden können. Dem H.235-Konzept liegen digitale Signatur und PKI-Systeme zugrunde.
www.wiwobooks.com
H.323 und NAT
Wie bei VoIP mit SIP (s. Abschnitt 10.6) sind auch bei VoIP mit H.323 bestimmte Lösungen nötig, damit sich IP-Telefone mit H.323 in Netzwerken mit privaten IP-Adressen uneingeschränkt nutzen lassen. Insbesondere entsteht ein Problem beim Transport von H.225.0-Nachrichten mit Hilfe des Protokolls UDP bei der Realisierung von RAS-Funktionen, falls ein auf einen Gatekeeper zugreifendes Terminal eine private IP-Adresse besitzt. Die Lösungen für den Einsatz privater IP-Adressen bei VoIP mit H.323 beschreiben die Standards H.460.18, H.460.19, H.460.23 und H.460.24.
7
VoIP mit SIP
SIP (Session Initiation Protocol) wurde zuerst als Signalisierungsprotokoll für Bedeutung multimediale Kommunikation und somit auch für VoIP konzipiert, d.h. als Pro- von SIP tokoll, nach dem Sessions – wie eine Art virtueller Verbindungen – für die Übermittlung verschiedener Echtzeitmedien (Audio/Voice, Video) aufgebaut werden können. Als SIP im März 1999 veröffentlicht wurde, hätten seine Entwickler sich nicht träumen lassen, dass es heute so einer breiten Palette verschiedener audiovisueller Anwendungen – wie z.B. Instant Messaging, Presence Services, Emergency Services – zugrunde liegen würde. Die Einsatzmöglichkeiten von SIP sind vielseitig. Dies führt dazu, dass SIP ständig weiterentwickelt und um neue Funktionen erweitert wird. Um eine multimediale Session zwischen den kommunizierenden Rechnern ver- Einsatz einbaren zu können, ist ein Protokoll nötig, nach dem sich die beiden Rechner von SDP u.a. darauf verständigen, welche Medien zwischen ihnen übermittelt und wie die einzelnen Medien codiert werden sollen. Für diese Verständigung wird bei SIP zusätzlich SDP (Session Description Protocol) verwendet.
www.wiwobooks.com
Dieses Kapitel präsentiert das Konzept und den Einsatz von SIP. Nach der Dar- Überblick stellung von SIP-Besonderheiten in Abschnitt 7.1 zeigt Abschnitt 7.2 mehrere über Beispiele für den Einsatz von SIP. Die SIP-Nachrichten beschreibt Abschnitt das Kapitel 7.3. Der Spezifikation von Sessions mit SDP widmet sich Abschnitt 7.4. Auf die Betriebsarten bei SIP geht Abschnitt 7.5 ein. Die Registrierung der Lokation von Benutzern stellt Abschnitt 7.6 dar. Wichtige Leistungsmerkmale mit SIP präsentiert Abschnitt 7.7. Wie Request- und Response-Routing erfolgt, zeigt Abschnitt 7.8. Die Konvergenz der IP-Netze mit ISDN beschreibt Abschnitt 7.9 und der Koexistenz von SIP und H.323 widmet sich Abschnitt 7.10. Abschließende Bemerkungen in Abschnitt 7.11 runden dieses Kapitel ab. Dieses Kapitel gibt Antworten u.a. auf folgende Fragen: Welches Konzept liegt SIP zugrunde? Wie werden VoIP-Benutzer bei SIP adressiert? Wie setzt man SIP bei VoIP ein? Welche Systemkomponenten sind nötig, um SIP bei VoIP vielseitig und flexibel einzusetzen? Wie lassen sich multimediale Sessions nach SDP spezifizieren? Wie realisiert man wichtige Leistungsmerkmale bei VoIP mit SIP? Wie kann die Konvergenz der IP-Netze mit SIP und ISDN/PSTN erfolgen?
Ziel dieses Kapitels
274
7
VoIP mit SIP
7.1
Verschiedene Aspekte des SIP-Einsatzes
SIP als Signalisierungsprotokoll
Mit SIP ist es möglich, eine Session (Sitzung) für die Übermittlung von Echtzeitmedien – wie Audio, Video – zwischen kommunizierenden Rechnern über ein IP-Netz aufzubauen. Diese Session kann sogar mehrere logische Kanäle enthalten, über die mehrere Echtzeitmedien mit Hilfe von RTP (Real-time Transport Protocol) parallel transportiert werden (s. Abschnitt 5.2). SIP dient daher u.a. als Signalisierungsprotokoll in VoIP-Systemen. Der Funktion nach entspricht SIP weitgehend dem D-Kanal-Protokoll im ISDN.
Rasante SIPEntwicklung
Als SIP im März 1999 in RFC 2543 veröffentlicht wurde, konnten seine Entwickler sich nicht vorstellen, dass es später einer so breiten Palette verschiedener audiovisueller Anwendungen zugrunde liegen würde. Schon Juni 2002 wurde eine erweiterte SIP-Kernspezifikation als RFC 3261 veröffentlicht und seitdem eine Unmenge von Internet-Standards, die SIP betreffen. SIP gehört heute zu den wichtigsten Internet-Protokollen.
7.1.1 SIP und verschiedene Transportprotokolle Das SIP ist ein Anwendungsprotokoll im Schichtenmodell der IP-Netze, das der Schicht 5 zuzuordnen ist. Abbildung 7.1-1 illustriert dies und zeigt auch die Einsatzmöglichkeiten verschiedener Transportprotokolle – der Schicht-4-Protokolle also – für den Transport von SIP-Nachrichten.
www.wiwobooks.com V o IP -A n w e n d u n g e n S ig n a lis ie ru n g
S c h ic h t 5 W K P s S c h ic h t 4 S c h ic h t 3 S c h ic h te n 1 -2
A u d io , V id e o
B e s c h re ib u n g v o n S e s s io n s n a c h S D P
S I P - S e s s io n In itia tio n P ro to c o l T L S
5 0 6 0 *) 5 0 6 1 S C T P
T L S * )
5 0 6 0 T C P
5 0 6 1
D T L S
R T P
D T L S
5 0 6 1 *) 5 0 6 0 *) 5 0 6 0 D C C P U D P I P - In te rn e t P ro to c o l
5 0 6 1
* )
x
R T C P
x + 1 U D P
R T P y + 1
y
D C C P
Ü b e rm ittlu n g s n e tz e x , y = g e ra d e Z a h le n
Abb. 7.1-1: SIP im Schichtenmodell und der Einsatz verschiedener Transportprotokolle DCCP: Datagram Congestion Control Protocol, DTLS: Datagram TLS, SDP: Session Description Protocol, TLS: Transport Layer Security, WKP: Well Know Port. *) Dieser Port ist noch nicht bei IANA registriert, sondern wird nur in RFCs bzw. in Internet-Drafts genannt.
Bei der Entwicklung von SIP war ursprünglich – noch im Jahr 1999 – vorgesehen, dass es das unzuverlässige und verbindungslose Transportprotokoll UDP nutzen sollte. Daher verfügt SIP über eigene und einfache Mechanismen,
7.1 Verschiedene Aspekte des SIP-Einsatzes
275
um seine Nachrichten über ein IP-Netz zuverlässig zu übermitteln. Im Vergleich zum TCP-Einsatz verläuft der Aufbau einer Session bei der Nutzung von UDP effizienter und viel schneller. Im Laufe der Zeit stellte sich aber heraus, dass es bei einigen Anwendungen – wie z.B. bei Unified Messaging bzw. zwischen verschiedenen VoIP-Anbietern – sinnvoll ist, für das SIP das zuverlässige und verbindungsorientierte Transportprotokoll TCP zu nutzen. Die SIP-Spezifikation in RFC 3261 sieht demzufolge die Nutzung von UDP und TCP vor. Der offizielle Well-Known Port von SIP bei UDP und bei TCP ist 5060. Es ist aber hervorzuheben, dass SIP standardmäßig UDP nutzt. In RFC 4168 wurde der Einsatz des Transportprotokolls SCTP für SIP – also SIP over SCTP – spezifiziert. Nach der Veröffentlichung des verbindungslosen Transportprotokolls DCCP (Datagram Congestion Control Protocol) mit Unterstützung der Überlastkontrolle im RFC 4340 – im März 2006 – wurde die Idee verfolgt, SIP over DCCP zu ermöglichen. Somit lässt sich SIP heute über alle Transportprotokolle implementieren.
SIP über UDP, TCP, SCTP und DCCP
Der bei IANA registrierte Well-Known Port von SIP ist sowohl bei UDP als auch bei TCP 5060. Den Port 5060 auch für SIP über DCCP und über SCTP zu verwenden, ist zwar vorgesehen, aber bei IANA noch nicht registriert – siehe http://www.iana.org/assignments/port-numbers
www.wiwobooks.com
Um den Verlauf von SIP vor bösartigen Angriffen zu schützen, kann SIP über SIP over TLS das Protokoll TLS (Transport Layer Security) auf Dienste der Transportschicht als SIPS 1 zugreifen. Bei dieser Lösung spricht man auch von SIP over TLS oder SIPS (Secure SIP). Ursprünglich war vorgesehen, dass das Sicherheitsprotokoll TLS das verbindungsorientierte Transportprotokoll TCP nutzen würde. TLS kann aber ebenso das Transportprotokoll SCTP verwenden. Es ist also zwischen zwei Möglichkeiten für SIPS – als SIP over TLS – zu unterscheiden, nämlich SIPS über TCP (bereits in RFC 3261 spezifiziert) und SIPS über SCTP (siehe hierfür RFC 4168). Der Well-Known-Port von SIPS bei TCP ist 5061. Für SIPS bei SCTP ist der Port 5061– in Internet-Drafts zwar genannt, aber bei IANA noch nicht registriert.
Das Protokoll TLS kann auch über die verbindungslosen Transportprotokolle SIP over UDP und DCCP eingesetzt werden (RFC 4347). Man bezeichnet dies als DTLS DTLS (Datagram TLS). Wie SIP over DCCP erfolgen kann, beschreibt der InternetDraft draft-jennings-sip-dtls-052. SIP over DTLS kann sowohl beim Einsatz von UDP als auch von DCCP erfolgen. Mit SIP über DTLS und mit 1
Das Protokoll TLS basiert auf dem von der Firma Netscape entwickelten Protokoll SSL (Secure Socket Layer) für die Sicherung von Web-Applikationen. Daher schreibt man oft SSL/TLS und spricht auch von SIP over SSL/TLS.
2
Dieser Internet-Draft wurde aber nicht als RFC angenommen.
276
7
VoIP mit SIP
DTLS über UDP – was als SIPS over UDP zu bezeichnen wäre – entsteht die Möglichkeit, den standardmäßigen SIP-Verlauf über UDP zu sichern. Bisher wurde bei IANA noch kein Well-Known Port für SIP mit DTLS über UDP bzw. über DCCP registriert. Einsatz des Protokolls SDP
Mit Hilfe von SIP werden ankommende Anrufe bei VoIP signalisiert und zwischen zwei IP-Telefonen wird eine Session für Sprachübertragung aufgebaut. Digitalisierte Sprache kann unterschiedlich codiert werden (s. Abschnitt 5.1). Deshalb muss man sicherstellen, dass die kommunizierenden IP-Telefone die gleiche Codierungsart, d.h. die gleichen „Sprachformate“ unterstützen. Um die Art der Sprachcodierung zwischen den IP-Telefonen auszuhandeln, wird das Protokoll SDP (Session Description Protocol) verwendet, das als Bestandteil vom SIP angesehen werden kann (s. Abschnitt 7.4).
SMTP, HTTP und SIP sind ähnlich
SIP definiert bestimmte Nachrichten für den Auf- und Abbau von Sessions. Da SIP in Anlehnung an zwei erfolgreiche Internet-Protokolle, nämlich SMTP (für Übermittlung von E-Mails) und HTTP (für die Übermittlung von Hypertext), entwickelt wurde, verwendet SIP auch ähnlich wie diese textbasierte Nachrichten (s. Abb. 7.3-1 und 7.3-2). Auch die SIP-Adressen sind ähnlich wie E-MailAdressen aufgebaut (s. Abb. 7.1-2).
SIPAbbildung auf andere Protokolle
Zu den Besonderheiten von SIP zählt neben einfacher Integration in die bestehende Internet-Infrastruktur, der Offenheit für zukünftige Erweiterungen und der relativ einfachen Signalisierung der Anrufe auch die einfache SIP-Abbildung auf die anderen Signalisierungsprotokolle wie das D-Kanal-Protokoll und das Signalisierungssystem Nr. 7 (s. Abb. 7.9-3 und 7.9-4). SIP ist nicht nur auf Sprach- und Video-Kommunikation ausgelegt, sondern auch für die mobile Kommunikation in IP-Netzen geeignet, was in Next Generation Networks von großer Bedeutung sein wird (s. Abschnitt 1.5.1).
SIPKomponenten
SIP definiert zwei funktionale Komponenten: den User Agent und den Server. Der User Agent wird seitens des Anwenders als Client implementiert und User Agent Client (UAC) genannt. Der Server heißt dementsprechend User Agent Server (UAS). Die Anrufe werden immer vom UAC initiiert, der UAS antwortet lediglich auf eingehende Anrufe. Daher bezeichnet man auch jede „angerufene“ Komponente als UAS.
www.wiwobooks.com
7.1.2 Wichtige SIP-Besonderheiten Die wichtigsten Besonderheiten von SIP: SIPbetreffende RFCs
SIP ist ein Protokoll von der IETF für die Signalisierung der Anrufe bei audiovisueller Kommunikation und für die Realisierung von VoIP von enormer Bedeutung. SIP wurde zuerst im März 1999 von der IETF als RFC 2543 veröffentlicht. Inzwischen hat SIP eine breite Akzeptanz gefunden und
7.1 Verschiedene Aspekte des SIP-Einsatzes
277
wurde weiterentwickelt. Seit der Spezifikation der neuen SIP-Version im RFC 3261 – Juni 2002 – wurden eine Vielzahl von RFCs veröffentlicht, in denen diverse SIP-Nutzungsaspekte dargestellt werden. Zur Zeit – August 2009 – gibt es bereits über 100 Internet-Dokumente, die in irgendeiner Form SIP betreffen. Für detailliertere Informationen siehe http://www.techinvite.com/Ti-sip-RFCs.html
Über eine mit SIP zwischen zwei Rechnern aufgebaute Session können ver- Protokoll schiedene Medien (Sprache, Video, Daten) mit Hilfe des Protokolls RTP RTP transportiert werden. Zu RTP siehe die Abschnitte 5.2 und 5.3. Bei SIP werden u.a. folgende Eigenschaften der initiierten RTP-Session Protokoll SDP nach dem Protokoll SDP ausgehandelt: − Welche Medien sollen übermittelt werden? − Wie werden die einzelnen Medien codiert? − Welcher Port wurde dem Protokoll RTP zugewiesen? SIP funktioniert nach dem Request/Response-Prinzip. Ein Rechner – als Ini- Request/ tiator der Kommunikation – sendet an einen anderen Rechner – seinen ResponseKommunikationspartner – eine SIP-Nachricht als Request. Dieser antwortet Prinzip dem Initiator mit einer SIP-Nachricht als Response. Daher spricht man auch von SIP-Request und von SIP-Response. Das Request/Response-Prinzip entspricht weitgehend dem Client/Server-Prinzip, sodass man in diesem Zusammenhang von SIP-Client und von SIP-Server spricht.
www.wiwobooks.com
Die Teilnehmer werden bei SIP über einen sog. SIP-URI (Uniform URI als SIPRessource Identifier) adressiert. Ein SIP-URI – als SIP-Adresse – ähnelt ei- Adresse ner E-Mail-Adresse. Die Nutzung von URIs zur Adressierung der IPTelefone hat einen ernormen Vorteil. Ein Benutzer kann nämlich in seiner (DNS-)Domain – und diese Domain kann sich über die ganze Welt erstrecken – wie ein „Nomade“ jeden Rechner als sein IP-Telefon nutzen. Daher spricht man auch von nomadischer Internet-Nutzung. Die SIP-Nachrichten werden nach der gleichen Syntax wie beim Protokoll HTTP/1.1 codiert. Für weitere Informationen zu HTTP siehe [BaRS 03]. Dank der Nutzung von URIs zur Adressierung der IP-Telefone erfolgt die Nutzung von Ermittlung von IP-Adressen der IP-Telefone bei SIP mit Hilfe von DNS DNS (Domain Name System). Dies ist – im Vergleich zu VoIP mit H.323 – ein riesiger Vorteil und hat zur breiten Akzeptanz von SIP beigetragen. Um die Sicherheit der Kommunikation garantieren zu können, wurden mehrere Erweiterungen zu SIP vorgeschlagen – siehe z.B. RFCs 3329, 4474, 4538, 4916 und 5009. SIP ermöglicht u.a. eine gegenseitige Authentifizierung kommunizierender Rechner. Mit SIP lassen sich verschiedene ergänzende Dienstmerkmale – sog. Supplementary Services – realisieren. Zu diesen gehören u.a. Anrufumleitung
SIP und Sicherheit
Supplementary Services
278
7
VoIP mit SIP
(Call Transfer), Anrufweiterleitung (Call Forwarding), das Halten einer Verbindung (Call Hold). Hierfür wurden verschiedene Erweiterungen von SIP in mehreren RFCs spezifiziert. Eine Umleitung der Anrufe – bei „Besetzt“ oder bei Abwesenheit des angerufenen Teilnehmers – ist mit SIP ebenfalls möglich (s. Abb. 7.2-5). Es gab bereits einige Vorschläge, um Gruppenkommunikation – insbesondere multimediale Konferenzen mit SIP – zu realisieren. Von großer Bedeutung sind hier die in RFCs 4353 und 5239 spezifizierten Frameworks für Konferenzen.
Gruppenkommunikation
7.1.3 Struktur von SIP-Adressen SIP-URI als SIP-Adresse
Um einen Benutzer zu einer multimedialen Kommunikation „einzuladen“, muss er entsprechend adressiert werden. Bei SIP erfolgt dies mit Hilfe sog. SIP-URIs (Uniform Resource Identifier). Ein SIP-URI stellt somit eine SIPAdresse dar. SIP gehört inzwischen zu den wichtigsten Internet-Protokollen und wird nicht nur für VoIP eingesetzt, sondern z.B. auch für IPTV, Presence Services, Instant Messaging und Colaboration Services. Dies hat – wie Abbildung 7.1-2 zeigt – die Struktur von SIP-URI stark beeinflusst.
www.wiwobooks.com u s e r | te le p h o n e -s u b s c rib e r
h n a m e = h v a lu e h e a d e r &
u s e r[:p a s s w o rd ]
h e a d e r &
...
s ip :u s e rin fo @ h o s tin fo [;u ri-p a ra m e te r] [? h e a d e rs ] h o s tn a m e | d o m a in | IP v 4 a d d re s s | IP v 6 a d d re s s tra n s p o rt-p a ra m
| ttl-p a ra m
tr a n s p o r t = u d p | tc p | s c tp | tls | ...
| m a d d r-p a ra m
| lr-p a ra m
[ ] o p tio n a l
| ...
| o d e r
Abb. 7.1-2: Vereinfachte Struktur des SIP-URI – in Anlehnung an RFC 3261
Wichtige Arten von SIP-URIs
Ein SIP-URI bei VoIP kann daher beispielsweise folgende Struktur haben:3 sip:user@domain
Beispielsweise stellt sip:[email protected] die Adresse des Benutzers Bob, genauer gesagt seines IP-Telefons, bei VoIP mit SIP in der Internet-Domain xyz.de dar. Ein SIP-URI mit dieser Struktur wird oft verwendet und entspricht vollkommen einer E-Mail-Adresse. Ein SIP-URI dieser Art identifiziert nicht nur einen Benutzer an einem IP-Telefon, sondern auch
3
Unter http://www.tech-invite.com/Ti-uri-abnf.html findet man detaillierte Informationen über URIs.
7.1 Verschiedene Aspekte des SIP-Einsatzes
279
einen Benutzer in einer Internet-Domain. Wie im Weiteren gezeigt wird – siehe Abbildung 7.1-3 –, muss ein sog. SIP-Proxy in der entsprechenden Domain installiert werden, um die Nutzung von SIP-URIs mit dieser Struktur zu ermöglichen. Der Einsatz von SIP-Proxies bringt mehrere Vorteile. sip:user@hostname sip:[email protected] bedeutet, dass der Rechner mit dem Hostnamen sonne in der Domain xyz.de als IP-Telefon des Benutzers Bob dient. Bei der Nutzung von SIP-URIs mit
dieser Struktur ist kein SIP-Proxy mehr nötig. sip:user@hostname;transport=tcp
Mit diesem URI wird zusätzlich zum SIP-URI sip:[email protected] gesagt, dass der Rechner sonne in der Domain xyz.de für die Übermittlung von SIP-Nachrichten das Transportprotokoll TCP verwendet. sip:phone-number@hostname
Beispielsweise besagt sip:[email protected], dass ein Benutzer mit der Rufnummer 1234 über den Rechner mit dem Hostnamen sonne in der Domain xyz.de erreichbar ist. Diese Art von SIP-URIs ermöglicht es, einen SIP-Server als VoIP-TK-Anlage zu verwenden. sip:[email protected]
Beispielsweise verweist sip:[email protected] darauf, dass die Telefonnummer 96404548 über ein VoIP-Gateway der Internet-Domain abc.de erreichbar ist. Das Einkapseln von Telefonnummern in SIP-URIs sollte u.a. die Integration von klassischen ISDN-TK-Anlagen mit IP-Netzen (z.B. mit dem Internet) erleichtern.
www.wiwobooks.com
sip:user@ipv4address
Mit sip:[email protected] wird besagt, dass der Benutzer Bill den Rechner mit der IP4Adresse 192.0.2.3 als sein IP-Telefon nutzt. Diese Art von SIP-URIs ist für kleine „familiäre“ Netzwerke – ohne DNS-Server (Domain Name System) – gut geeignet.
Aus diesen Beispielen geht hervor, dass das Adressierungsschema von SIP an das Konzept der Adressierung im Internet angepasst ist und DNS für die Auflösung von SIP-Adressen in IP-Adressen eingesetzt werden kann. Das ist ein enormer Vorteil im Vergleich zu VoIP mit H.323. Hervorzuheben ist, dass die Angabe password im SIP-URI zwar theoretisch möglich ist, aber sogar im RFC 3261 – wo diese Möglichkeit spezifiziert wurde – wird die Angabe der Benutzerkennung im Klartext nicht empfohlen. Wie bereits in Abbildung 7.1-1 zum Ausdruck gebracht, kann SIP auch das SIPS-URIs Protokoll TLS (Transport Layer Security) nutzen, sodass ein verbindungsorientiertes Transportprotokoll TCP oder SCTP für den Transport von SIP-Nachrichten eingesetzt wird. Diese SIP-Variante bezeichnet man als SIPS (Secure SIP). Bei SIPS werden aber die sog. SIPS-URIs verwendet. Ein SIPS-URI hat die gleiche Struktur wie ein SIP-URI in Abbildung 7.1-2, beginnt aber nicht mit sip:, sondern immer mit sips:. Beispiel: Die SIPS-URIs sind: sips:[email protected] sips:[email protected] sips:phone-number@hostname
280
7
VoIP mit SIP
Zwar sind die Strukturen von SIP-URI und SIPS-URI fast identisch, dennoch handelt es sich hier um verschiedene Adresskonstrukte, was entsprechend mit sip und sips verdeutlicht wird. Die beiden URI-Arten werden u.a. in der ersten Zeile des SIP-Request INVITE, mit dem eine VoIP-Verbindung initiiert wird, angegeben. Beispiel: Die erste Zeile im SIP-Request INVITE kann einen URI – d.h. mit sip: oder mit sips: – enthalten und beispielsweise wie folgt aussehen – vgl. Abbildung 7.3-1: INVITE sip:[email protected] SIP/2.0 oder INVITE sips:[email protected] SIP/2.0
Bemerkung: Im weiteren Verlauf dieses Kapitels – wo dies zu keinen Missverständnissen führen kann – werden URIs auch in der vereinfachten Form – ohne sip: bzw. ohne sips: – im Text bzw. in Abbildungen geschrieben.
7.1.4 Funktion eines SIP-Proxy Innerhalb einer Domain werden IP-Telefone oder andere multimediale Endeinrichtungen oft mit SIP-URIs adressiert, die folgende Struktur haben: sip:user@domain
www.wiwobooks.com
Im Teil domain wird der vollständige Name – als sog. FQDN (Fully Qualified Domain Name) – der Domain eingetragen, in der sich das Ziel einer initiierten Session befindet. Der Teil user enthält die Identifikation des IP-Telefons eines Benutzers innerhalb der betreffenden Domain, welches das Ziel des Anrufs ist. Beispielsweise kann der SIP-URI sip:[email protected] dem IP-Telefon des Benutzers Bob in der Domain xyz.de als SIP-Adresse zugeteilt werden. Diese Struktur von SIP-URI entspricht daher vollkommen der Struktur einer E-MailAdresse. Notwendigkeit von Proxies
Wie Abbildung 7.1-3 zum Ausdruck bringt, entsteht beim Einsatz von SIPURIs für die Adressierung eines IP-Telefons ein Problem. Und zwar muss ein SIP-URI auf die IP-Adresse des Rechners mit einem Soft-IP-Telefon bzw. auf die IP-Adresse eines IP-Telefons als separate Hardware-Komponente abgebildet werden. Hierfür muss man einen spezieller Server in der Domain installieren, der in der betreffenden Domain als Vertretung von Rechnern bzw. von anderen Endeinrichtungen – die als IP-Telefone fungieren – dient. Diesen speziellen Server bezeichnet man als SIP-Proxy. Bei VoIP mit SIP kommen daher die SIP-Proxies zum Einsatz. Ein SIP-Proxy z.B. in der Domain abc.de dient als Vertreter aller Rechner, die in dieser Domain als IP-Telefone mit SIP dienen. Ein SIP-Proxy wird oft in einem SIP-Server untergebracht.
7.1 Verschiedene Aspekte des SIP-Einsatzes
U n te r w e lc h e r IP -A d re s s e is t d a s IP -T e le fo n e rre ic h b a r?
281
W e lc h e IP -A d re s s e h a t d e r S IP -P ro x y in d e r Z ie l-D o m a in ?
Z ie l-D o m a in IP -T e l Y a ls Z ie l
In te rn e t B A
S IP -P ro x y
s i p : u s e r @ < d o m a i n W e lc h e s IP -T e le fo n g ilt a ls Z ie l ?
IP -T e l X
S IP -U R I
In w e lc h e r D o m a in b e fin d e t s ic h d a s IP -T e le fo n ?
A b b ild u n g d e s D o m a in n a m e n s a u f d ie IP -A d re s s e v o n S IP -P ro x y A B
A b b ild u n g d e r Id e n tifik a tio n d e r R e s s o u rc e a u f d ie IP -A d re s s e d e s Z ie l-R e c h n e rs m it d e m S o ft-IP -T e le fo n
Abb. 7.1-3: Einsatz von SIP-URI für die Adressierung bei VoIP mit SIP
Die Abbildung eines SIP-URI auf die IP-Adresse eines Rechners mit dem IP- Ermittlung Telefon wird in zwei Schritten – in Abbildung 7.1-3 den Schritten A und B – der Ziel-IP4 durchgeführt. In Schritt A wird – mit Hilfe von DNS – der Name der Domain Adresse aus dem SIP-URI auf die IP-Adresse des SIP-Proxy abgebildet, sodass der SIPProxy quasi als Zwischenstation bei der Kommunikation zwischen IP-Telefonen dient. In Schritt B wird dann aus dem Teil user in SIP-URI die IPAdresse des Rechners, der hier als IP-Telefon dient, bestimmt, um das Ziel der Kommunikation zu erreichen.
www.wiwobooks.com
Die Adressierung von IP-Telefonen mit SIP-URIs besitzt – im Vergleich zum BenutzerEinsatz von URLs (Uniform Resource Locator) bei Web-Anwendungen – einen mobilität wesentlichen Vorteil. Da im SIP-URI sip:user@domain der Rechnername (Hostname) nicht angegeben wird, sondern nur der Domainname und die Identifikation eines IP-Telefons, kann sich dieses – als z.B. Soft-IP-Telefon – auf jedem beliebigen Rechner innerhalb der betreffenden Domain befinden. Auf welchem Rechner das Soft-IP-Telefon eines Benutzers aktuell installiert ist, kann man im SIP-Proxy bzw. auf einem anderen Server – z.B. auf einem Location-Server, wie bei VoIP mit SIP oft der Fall – entsprechend eintragen. So erreicht man mit SIP bei VoIP eine domainweite Mobilität von Benutzern.
4
Die Abbildung vom Namen einer Domain auf die IP-Adresse ihres SIP-Proxy erfolgt im DNS – gemäß RFC 2052 – mit Hilfe des Resource-Record (RR) vom Typ SRV (SeRVer). Hierfür wird zuerst der SRV-RR abgefragt, womit man den Hostnamen des SIP-Proxy bestimmt. Danach wird der RR vom Typ A mit der IP-Adresse des SIP-Proxy abgefragt. Dies erfolgt nach dem Schema: Domainname SVR-RR SIP-Proxy-Name A-RR IP-Adresse. Weil SIP zwischen Proxies auch andere Transportprotokolle als UDP nutzen kann, muss in diesem Fall zuerst noch das Transportprotokoll ermittelt werden – siehe Abbildung 3.5-6.
282
7
VoIP mit SIP
7.1.5 Trapezoid-Modell von SIP Im Allgemeinen verläuft die Signalisierung bei VoIP und ebenso bei einer anderen audiovisuellen Kommunikation zwischen zwei Domains nach SIP entlang eines Trapezoids, sodass man auch vom SIP-Trapezoid spricht. Abbildung 7.1-4 bringt dies zum Ausdruck. A b fra g e d e r L o k a tio n d e s A n g e ru fe n e n
A b fra g e d e r IP -A d re sse d e s E in g a n g s -P ro x y A u s k u n fts e b e n e
P ro x y -E b e n e A lic e
L S
D N S A u sg a n g sP ro x y
U A S
L S
D N S
S IP
U A S
E in g a n g s P ro x y S IP
S IP
B o b
S IP
U A C s ip :a lic e @ a b c .d e
S e s s io n (Ü b e rm ittlu n g v o n M e d ie n )
D o m a in d e s A n r u fe n d e n a b c .d e
U A C s ip :b o b @ x y z .d e
D o m a in d e s A n g e r u fe n e n x y z .d e
www.wiwobooks.com
Abb. 7.1-4: Darstellung des SIP-Verlaufs in Form eines SIP-Trapezoid-Modells LS: Location-Server, UA: User Agent, UAC: UA Client, UAS: UA Server
UAC und UAC
Im Trapezoid-Modell des SIP-Verlaufs sind zwei Ebenen hervorzuheben, die man als Proxy-Ebene und Auskunfts-Ebene bezeichnen kann. Alle Instanzen – wie IP-Telefone als Endeinrichtungen und Server – mit SIP werden im Allgemeinen User Agent (UA) genannt. Darunter sind Anwendungen (wie z.B. SoftIP-Telefone) in Rechnern mit SIP zu verstehen, die eine Schnittstelle zwischen dem Benutzer und dem Netzwerk bilden. Ein Agent kann entweder als Client oder als Server fungieren. Initiiert ein UA einen Anruf, fungiert er als User Agent Client (UAC), empfängt ein UA einen Anruf, dient er als User Agent Server (UAS). Eine neue Session für multimediale Kommunikation wird immer mit der SIPNachricht INVITE initiiert, in der die SIP-Adresse des Ziels – in Abbildung 7.1-4 ist das sip:[email protected] – enthalten ist. Mit einem SIP-URI identifiziert man einen Zielrechner am IP-Netz beim Aufbau einer Session zu ihm. Ein Zielrechner am IP-Netz wird aber mit einer IP-Adresse adressiert. Da in der Domain des Angerufenen ein SIP-Proxy eingesetzt wurde und dieser als Eingangs-Proxy – d.h. als Vertretung aller Endeinrichtungen mit SIP nach außen hin – dient, muss die SIP-Nachricht INVITE zuerst an ihn weitergeleitet wer-
7.1 Verschiedene Aspekte des SIP-Einsatzes
283
den. Hierfür muss aber erst die IP-Adresse des Eingangs-Proxy auf der Basis von SIP-URI sip:[email protected] mit Hilfe von DNS ermittelt werden. Beispiel: Um bei DNS die IP-Adresse des SIP-Proxy in der Domain xyz.de abzurufen, werden zuerst das Transportprotokoll für SIP und der Name des SIP-Proxy ermittelt. Wie in Abschnitt 3.5 dargestellt (s. Abb. 3.5-6), wird zunächst das Transportprotokoll mit einer NAPTR-Query abgefragt. Danach erfolgt eine SRV-Query. Ihr Ergebnis ist der Name – z.B. proxy.xyz.de – des SIP-Proxy in xyz.de. Daraufhin wird die IP-Adresse des Rechners mit dem Namen proxy.xyz.de mit einer A-Query ermittelt. Hierfür fragt man den diesem Rechnernamen entsprechenden RR vom Typ A im DNS-Server der Domain xyz.de ab. 5
In Abbildung 7.1-4 ist der Rechner von Alice der Initiator der hier bestehenden Session zu Bob für die Übermittlung von Echtzeitmedien. Beim Initiieren einer neuen Session zu einem Ziel außerhalb der eigenen Domain wird eine SIP-Nachricht INVITE mit dem SIP-URI des Ziels an den SIP-Proxy übergeben. Diese SIP-Nachricht muss er weiterleiten. Daher kann man diesen SIPProxy als Ausgangs-Proxy betrachten. Hat der Rechner von Alice die SIPNachricht INVITE mit dem SIP-URI sip:[email protected] an den SIP-Proxy in der Domain abc.de abgeschickt und ist diese dort eingetroffen, muss dieser nun INVITE an den SIP-Proxy in der Domain xyz.de mit dem Rechner von Bob übergeben. Zuerst muss er aber mit Hilfe von DNS die IP-Adresse des SIP-Proxy in dieser Domain ermitteln.
www.wiwobooks.com
Wie Abbildung 7.1-4 illustriert, richtet der SIP-Proxy aus der Domain des Anrufenden hierfür eine Anfrage an einen entsprechenden DNS-Server mit dem Namen xyz.de der Domain des Angerufenen. Hat der SIP-Proxy aus der Domain des Anrufenden die IP-Adresse vom DNS bereits erhalten, leitet er die SIP-Nachricht INVITE mit SIP-URI sip:[email protected] an den SIP-Proxy in der Domain xyz.de weiter. Wie bereits hervorgehoben wurde, ermöglicht der Einsatz von SIP-Proxies in einer Domain uneingeschränkte Mobilität innerhalb dieser Domain, sodass z.B. der SIP-URI sip:[email protected] (fast) jedem Rechner mit SIP innerhalb der Domain xyz.de zugewiesen werden kann. Daher muss der SIP-Proxy der Domain des Angerufenen die IP-Adresse des Rechners, den Bob aktuell als SIP-Endeinrichtung nutzt, ermitteln, um die SIP-Nachricht INVITE an diesen Rechner übergeben zu können. Um diese Mobilität zu unterstützen, wird ein 6 Location-Server eingesetzt. Bei ihm kann der Eingangs-Proxy die aktuelle
5
In fast allen SIP-betreffenden RFCs werden der Anrufer Alice und der Angerufene Bob genannt. Daher verwenden wir diese Namen auch hier.
6
Der Location-Server kann ein Bestandteil der Verzeichnisdienste (Directory Services) im Netzwerk sein. Für die Kommunikation zwischen Proxy-Server und Location-Server kann man das Protokoll LDAP (Lightweight Directory Access Protocol) verwenden.
Ermittlung der IPAdresse von SIP-Proxy
284
7
VoIP mit SIP
Lokation des Angerufenen – in Abbildung 7.1-4 die IP-Adresse des Rechners von Bob – abfragen und danach INVITE an diesen Rechner übergeben. Hat INVITE den Rechner des Angerufenen erreicht, und die gewünschte Session kann zustande kommen, wird dies dem Angerufenen akustisch durch Klingeln (Ringing) und dem Rechner von Alice mit der SIP-Nachricht 180 Ringing signalisiert. Diese Nachricht wird über die beiden SIP-Proxies übermittelt – siehe Abbildung 7.1-5. Nachdem die Session aufgebaut wurde, kann sie direkt zwischen den beiden Rechnern – also von Alice und Bob – verlaufen. Die Übermittlung von SIP-Nachrichten kann zwischen diesen Rechnern auch direkt stattfinden. Abbildung 7.1-4 bringt dies zum Ausdruck.
7.1.6 SIP-Verlauf im Trapezoid-Modell Nachdem das SIP-Trapezoid-Modell bereits dargestellt wurde, soll nun der in Abbildung 7.1-5 illustrierte typische Verlauf von SIP nach diesem Modell ausführlicher am Beispiel einer Session als VoIP-Verbindung – also zwischen zwei IP-Telefonen – erläutert werden.
www.wiwobooks.com 2 :
IN V 1 0 0 7 : 1 8 0 1 0 : 2 0 0 5 :
1 :
IN V 3 : 1 0 0 8 : 1 8 0 1 1 : 2 0 0
a b c .d e
IT E T ry in g R in g in g O K
A -P
1 A lic e
8
2
3
IT E T ry in g R in g in g O K 5 7 1 0
x y z .d e
E -P 6
1 1 1 2
1 2 : A C K
4 9
4 : IN V IT E 6 : 1 8 0 R in g in g 9 : 2 0 0 O K B o b
S e s s io n (Ü b e rm ittlu n g v o n M e d ie n ) 1 3 s ip :b o b @ x y z .d e 1 4 1 3 : B Y E D o m a in d e s A n g e r u fe n e n D o m a in d e s A n r u fe n d e n 1 4 : 2 0 0 O K
s ip :a lic e @ a b c .d e
Abb. 7.1-5: Typischer SIP-Verlauf im SIP-Trapezoid-Modell A-P: Ausgangs-Proxy, E-P: Eingangs-Proxy
Als erste SIP-Nachricht wird der Request INVITE vom (IP-)Telefon des Anrufenden (Alice) – zuerst über den Ausgangs-Proxy der Domain des Anrufenden und dann über den Eingangs-Proxy der Domain des Angerufenen (Bob) – an das Telefon von Bob übermittelt. Den Empfang von INVITE bestätigt jeder 7 Proxy jeweils mit dem SIP-Response 100 Trying.
7
Da man in der Regel für den Transport von SIP-Nachrichten das verbindungslose und unzuverlässige Transportprotokoll UDP verwendet, bei dem man dem Absender keine Bestätigung
7.1 Verschiedene Aspekte des SIP-Einsatzes
Hat INVITE das Telefon von Bob erreicht, wird der ankommende Anruf durch Klingeln bei Bob signalisiert. Kommt die gewünschte Verbindung zustande – was sich durch die Überprüfung der Kompatibilität beider Telefone daraufhin feststellen lässt, ob sie mindestens eine gleiche Sprachcodierungsart unterstützen –, wird dies dem Telefon von Alice durch Absenden der SIP-Nachricht 180 Ringing signalisiert, sodass bei ihm Freitöne – also das akustische Signal, dass die Verbindung zustande kommen kann – erzeugt werden. Hervorzuheben ist hier, dass 180 Ringing über die beiden Proxies – d.h. entlang der Route von INVITE – übermittelt wird. Um dies zu erreichen, bringt INVITE die Beschreibung ihrer Route zu Bobs Telefon mit. Wie dies geschieht, erläutern wir in Abschnitten 7.1.9 und 7.8 (s. Abbildungen 7.1-9 und -10). Nachdem Bob den Hörer abgehoben hat, wird dies dem Telefon von Alice mit der Nachricht 200 OK signalisiert, das als Bestätigung wiederum die Nachricht ACK an das Telefon von Bob schickt. Die letzte Nachricht ACK wird direkt – also nun nicht mehr über Proxies – an das Telefon von Bob übermittelt. Der Abbau einer VoIP-Verbindung wird mit BYE initiiert. Diese Nachricht 8 bestätigt die Gegenseite mit 200 OK .
www.wiwobooks.com
7.1.7 Unterstützung von Benutzermobilität
Ein wichtiges Dienstmerkmal bei Sprachkommunikation ist die Anrufweiterleitung (Call Forwarding). Sie lässt sich relativ einfach realisieren und schafft – theoretisch gesehen – die Möglichkeit, alle Sessions für multimediale Kommunikation und damit auch Verbindungen für VoIP mit SIP weltweit und auch mehrfach von einer Domain zur anderen weiterzuleiten. Der Angerufene kann mit einem tragbaren IP-Telefon weltweit mobil und trotzdem überall auf der Erdkugel unter der gleichen Rufnummer bzw. SIP URI erreichbar sein. Dies nennt man nomadische Nutzung der IP-Netze – und somit auch des Internet. Wie die Unterstützung der Benutzermobilität bei SIP erfolgen kann, veranschaulicht Abbildung 7.1-6. Das SIP-Trapezoid-Modell gilt auch hier, wurde im Unterschied zu Abbildung 7.1-5 jedoch beträchtlich erweitert. Der Benutzer Bob mit dem SIP-URI sip:[email protected] ist in der Domain xyz.de registriert und verfügt somit in ihr über bestimmte auf die Kommunikation bezogene Rechte. Die Domain xyz.de kann als seine Heimat-Domain angesehen werden. Die Domain abc.de ist die Heimat-Domain von Alice mit ihrem SIP-URI sip:[email protected]. zu empfangenen Daten übermittelt, wird die fehlende Bestätigung hier u.a. durch die SIPNachricht Trying ersetzt. Bei SIP kann man aber auch TCP verwenden (s. Abb. 7.1-1). 8
Die Begründung für diese Bestätigung wurde bereits in der Fußnote 6 dargelegt.
285
286
7
VoIP mit SIP
H e im a t-D o m a in v o n A lic e
D N S a b c .d e
L S
L S S IP 2
A -P S IP
A lic e
H e im a t-D o m a in v o n B o b
1 IN V IT E
s ip :a lic e @ a b c .d e
IN V IT E
F r e m d -D o m a in v o n B o b
D N S E P x y z .d e
L S
D N S p r s .c o m
S IP 3
E -P
IN V IT E
4
m o b il
S IP
IN V IT E
S IP S e s s io n (Ü b e rm ittlu n g v o n M e d ie n )
B o b
s ip :b o b @ x y z .d e
Abb. 7.1-6: Benutzermobilität mit SIP – erweitertes SIP-Trapezoid-Modell A-P: Ausgangs-Proxy, E-P: Eingangs-Proxy, LS: Location-Server
Wie Abbildung 7.1-6 zeigt, hat Bob seine Heimat-Domain xyz.de verlassen und hält sich aktuell in der Fremd-Domain prs.com auf. Um hier erreichbar zu sein, hat Bob in seiner Heimat-Domain im SIP-Registrar, der ein integraler Bestandteil des Location-Servers ist, durch die Eintragung des vollständigen Namens der Fremd-Domain die Information hinterlassen, dass er sich in der Domain prs.com aufhält. So hat Bob eine „Anrufweiterleitung“ vom SIPProxy seiner Heimat-Domain xyz.de zum SIP-Proxy der Fremd-Domain prs.com aktiviert. In diesem Fall ist es aber trotzdem sinnvoller, von einer Session-Weiterleitung (Session Forwarding) zu sprechen.
www.wiwobooks.com
Sollte Bob die Fremd-Domain prs.com verlassen und in eine andere FremdDomain hineingehen, so muss er, um in der neuen Fremd-Domain ebenso erreichbar zu sein, nur die vorher im SIP-Registrar seiner Heimat-Domain eingerichtete Session-Weiterleitung nun durch die Eintragung eines neuen Domainnamens aktualisieren. Abbildung 7.1-6 soll auch die ersten Schritte beim Aufbau einer Session zwischen dem Telefon von Alice und dem Telefon von Bob erläutern. Es wurde hier angenommen, dass die Session durch das Telefon von Alice – durch das Absenden der SIP-Nachricht INVITE mit SIP-URI sip:[email protected] von Bob an den SIP-Proxy (1) – initiiert wird. Der SIP-Proxy ermittelt dann mit Hilfe von DNS die IP-Adresse des SIP-Proxy der Heimat-Domain xyz.de von Bob und leitet anschließend INVITE an diesen SIP-Proxy weiter (2). Der SIP-Proxy von Bobs Heimat-Domain fragt nun beim Location-Server nach dem „aktuellen“ Rechner von Bob. Hat Bob in seiner Heimat-Domain bereits die Session-Weiterleitung in die Fremd-Domain prs.com eingerichtet, erhält der SIP-Proxy von Bobs Heimat-Domain nun den Namen der Fremd-Domain prs.com, um die Session dorthin weiterzuleiten. Somit ermittelt der SIP-Proxy
7.1 Verschiedene Aspekte des SIP-Einsatzes
von Bobs Heimat-Domain mit Hilfe von DNS die IP-Adresse des SIP-Proxy der Domain prs.com und übergibt INVITE an ihren SIP-Proxy (3). Hat der SIP-Proxy der Fremd-Domain prs.com die Nachricht INVITE mit dem SIP-URI sip:[email protected] von Bob empfangen, fragt er beim LocationServer nach dem Namen des Rechners, den Bob aktuell nutzt, ermittelt seine IP-Adresse mit Hilfe von DNS und leitet danach INVITE an Bobs Rechner. Damit hat die Nachricht INVITE das Ziel der Session erreicht und die Beschreibung ihrer Router – d.h. über welche Proxies sie übermittelt wurde – mitgebracht (s. Abschnitt 7.1.9 und Abbildung 7.1-9). Somit können die weiteren SIP-Nachrichten zwischen Rechnern von Bob und von Alice entlang dieser Route übermittelt werden, um den Aufbau der Session fortzusetzen. Kehrt Bob in seine Heimat-Domain zurück, muss er die zuvor im LocationServer eingerichtete Session-Weiterleitung nur entsprechend deaktivieren.
7.1.8 Erweiterter SIP-Proxy als B2BUA Wie z.B. aus den Abbildungen 7.1-5 und -6 ersichtlich ist, stellt ein SIP-Proxy einen zentralen Eingangs- und Ausgangsknoten einer (DNS-)Domain mit SIP dar. Eine Domain kann auch von einem VSP (VoIP Service Provider) für kommerzielle Zwecke eingerichtet werden. In diesem Fall muss der beim VSP eingesetzte SIP-Proxy um zusätzliche Funktionen – z.B. für die Erfassung von anfallenden Gebühren – erweitert werden. Dies hat zur Entstehung einer SIPProxy-Art geführt, die man als B2BUA (Back-to-Back User Agent) bezeichnet. Abbildung 7.1-7 veranschaulicht die Bedeutung eines B2BUA.
www.wiwobooks.com
V o IP S e r v ic e P r o v id e r A
D N S
V o IP S e r v ic e P r o v id e r B
L S
B 2 B U A A lic e
U A C U A S
S IP
D N S
L S
a b c .d e S IP S e s s io n
U A C
s ip :a lic e @ x y z .d e
x y z .d e U A C U A S
B 2 B U A S IP U A C
B o b
U A C s ip :b o b @ x y z .d e
Abb. 7.1-7: Beispiel für den Einsatz von B2BUA bei VSPs
Im Unterschied zu einem „normalen“ SIP-Proxy ist B2BUA in der Lage, nicht nur SIP-Responses, sondern auch SIP-Requests zu generieren, zu überarbeiten und hierbei auch ihre Body-Teile (s. Abbildungen 7.3-1 und -2) zu interpretie-
287
288
7
VoIP mit SIP
ren. Daher kann er auch die Medienströme auf eine bestimmte Art und Weise beeinflussen. Ein B2BUA enthält sowohl einen UAC (User Agent Client) als auch einen UAS (User Agent Server) und kann dadurch als UAC und als UAS dienen. Beim Einsatz von B2BUAs bei VSPs verlaufen in der Regel auch die Sessions über die beteiligten B2BUAs. Damit lässt sich der Verlauf der Kommunikation kontrollieren, und die anfallenden Gebühren können erfasst werden. Einsatz von SIPS
Zwischen zwei B2BUAs, die zu verschiedenen VSPs gehören, zwischen denen eine Roaming-Vereinbarung besteht, kann es auch sinnvoll sein, das SIP über das Sicherheitsprotokoll TLS und über eine permanente TCP-Verbindung – d.h. als SIPS, siehe Abbildung 7.1-1 – einzusetzen.
7.1.9 Typischer SIP-Verlauf Schauen wir uns nun den SIP-Verlauf beim Auf- und Abbau einer Session für die Kommunikation zwischen zwei IP-Telefonen genauer an. Abbildung 7.1-8 illustriert diesen SIP-Verlauf. Die beiden Teilnehmer – Alice und Bob – nutzen hier ihre SIP-URIs als VoIP-Adressen.
www.wiwobooks.com s ip :a lic e @ a b c .d e A lic e
S IP P ro x y
a b c .d e 1
IN V IT E 1 0 0 T ry in g 1 8 0 R in g in g
F re ito n 4
IP -N e tz (In te rn e t)
S IP P ro x y
IN V IT E 1 0 0 T ry in g 1 8 0 R in g in g
x y z .d e
B o b K lin g e ln
IN V IT E 1 8 0 R in g in g
2 3
2 0 0 O K
2 0 0 O K
2 0 0 O K
s ip :b o b @ x y z .d e
A b g e h o b e n
A C K S e s s io n (V o IP -V e r b in d u n g )
6
A u fg e le g t B Y E
2 0 0 O K R e q u e st
5
R e sp o n se
Abb. 7.1-8: SIP-Verlauf beim Auf- und Abbau einer Session – als VoIP-Verbindung – zwischen zwei IP-Telefonen in verschiedenen Domains
Request: INVITE
Eine Session wird immer durch das Absenden einer SIP-Nachricht INVITE (s. Abb. 7.1-9) initiiert, die einen Request darstellt und als Einladung zu einer Session (Sitzung) interpretiert werden kann. INVITE enthält in ihrem BodyTeil die Beschreibung der initiierten Session nach dem Protokoll SDP – siehe Abbildung 7.4-1. Hierzu gehören u.a. notwendige Angaben, um feststellen zu
289
7.1 Verschiedene Aspekte des SIP-Einsatzes
können, ob die gewünschte Session zustande kommen kann. Dies bedeutet, dass die Kompatibilität beider Seiten überprüft werden muss – wie, erläutern wir in Abschnitt 7.4.1 näher. Um eine Session zu initiieren, sendet das IP-Telefon von Alice die SIP-Nachricht INVITE – als SIP-Request – mit Bobs SIP-URI sip:[email protected] an den Proxy der Domain abc.de. Dieser Proxy ermittelt nun mit Hilfe von DNS die IP-Adresse des Proxy in der Domain xyz.de (vgl. Abb. 7.1-3), leitet INVITE an ihn weiter und informiert anschließend das IP-Telefon von Alice mit der SIP-Nachricht 100 Trying9 – als SIP-Response.
Schritt1: Übermittlung von INVITE
Nach dem Empfang der Nachricht INVITE ermittelt der Proxy in der Domain xyz.de zuerst mit Hilfe des Location-Servers – siehe hierfür Abbildung 7.1-4 – den Rechner, den Bob aktuell als sein IP-Telefon nutzt, und danach mit Hilfe von DNS die IP-Adresse dieses Rechners, sendet INVITE an das IP-Telefon von Bob und bestätigt dies anschließend dem SIP-Proxy der Domain abc.de mit 100 Trying. Falls das angerufene IP-Telefon von Bob die ankommende Session annehmen Schritt2: kann, d.h. die beiden IP-Telefone kompatibel sind, muss es in diesem IP- 180 RinTelefon klingeln. Damit wird der ankommende Anruf bei ihm akustisch signa- ging lisiert. Wenn es klingelt, antwortet das angerufene IP-Telefon mit dem SIPResponse 180 Ringing,10 die zum IP-Telefon von Alice entlang der Route von INVITE – d.h. über die beiden SIP-Proxies – übermittelt wird. Nach dem Empfang von 180 Ringing beim IP-Telefon von Alice wird bei ihm ein Freiton generiert. Somit erfährt Alice, dass das angerufene IP-Telefon von Bob nicht besetzt ist.
www.wiwobooks.com
Hat Bob den Hörer abgehoben bzw. den Anruf durch Betätigen einer entspre- Schritt3: chenden Taste angenommen, wird der SIP-Response 200 OK (OKay) entlang 200 OK der Route von INVITE an das IP-Telefon von Alice gesendet. Das IP-Telefon von Alice bestätigt den Empfang von 200 OK mit der Nach- Schritt4: richt ACK (ACKnowledgement), die einen SIP-Request darstellt. Mit dem Emp- ACK fang von ACK beim IP-Telefon von Bob ist der Aufbau der Session für VoIP abgeschlossen. Die beiden IP-Telefone werden so verknüpft, als ob ein logi9
Da SIP das unzuverlässige UDP nutzt, werden mit 100 Trying zwei Ziele erreicht. Der Empfänger von 100 Trying wird einerseits darüber informiert, dass seine Nachricht INVITE empfangen wurde – was als Ersatz für die fehlende Bestätigung bei UDP dient, und andererseits, dass die Session durch Absenden von INVITE an den nächsten SIP-Proxy weitergeleitet wurde.
10
Ob eine SIP-Nachricht als Request oder als Response betrachtet werden soll, erkennt man daran, dass jede Response immer mit einer Nummer beginnt, wie z.B. 100 Trying, 180 Ringing, 200 OK.
290
7
VoIP mit SIP
scher Kanal zwischen ihnen aufgebaut wäre. Weil die Übermittlung von Sprache (bzw. allgemeiner von Audio und Video) in diesem Kanal nach dem Protokoll RTP verläuft, wird dieser Kanal bei SIP als RTP-Kanal bezeichnet. Schritt5: BYE
Die bestehende Session kann von beiden Seiten (z.B. durch Auflegen des Hörers) beendet werden. In Abbildung 7.1-8 wird der Abbau der Session vom IP-Telefon von Bob durch Absenden der SIP-Nachricht BYE veranlasst. Hat das IP-Telefon von Alice BYE empfangen, bestätigt es dies mit der Nachricht 200 OK. Mit dem Empfang von 200 OK beim IP-Telefon von Bob wird die Session – und damit auch die Sprachübermittlung – beendet. Angaben in SIP- Nachrichten
Nachrichten INVITE
Die wesentlichen Angaben für den Aufbau einer Session sind in Nachrichten INVITE enthalten. Abbildung 7.1-9 zeigt diese Nachrichten beim SIP-Verlauf in Abbildung 7.1-8. Die SIP-Nachrichten enthalten mehrere Zeilen – als sog. Header-Felder. In der ersten Zeile wird der Name der Nachricht – wie hier INVITE – angegeben. In INVITE enthält die erste Zeile den SIP-URI der Angerufenen als Zieladresse und die SIP-Version – hier SIP/2.0. Die weiteren Header-Felder in INVITE haben folgende Bedeutung (s. Abschnitt 7.3.3): Via – wie im Weiteren erläutert – ermöglicht die Aufzeichnung der Route von INVITE; To – die Angabe der Identität des Angerufenen;
www.wiwobooks.com
From – die Angabe der Identität des Anrufenden mit tag für die Identifikation des Dialogs; Call-ID – Identifikation des Anrufs;
Contact – Angabe der Adresse – als SIP-URI; an diese müssen die Antworten auf INVITE
gesendet werden; Content-Type – als Angabe des Typs von Body (s. Abb. 7.3.1). Beispielsweise sagt application/SDP, dass in Body die Beschreibung der Session nach SDP enthalten ist; Content-Length – Angabe der Body-Länge.
Dialog-ID
Eine Kommunikationsbeziehung zwischen dem Anrufer (From) und dem Angerufenen (To) wird als Dialog bezeichnet. Jedem Dialog wird eine Identifikation (ID) zugewiesen, die ein 3-Tupel bildet, bestehend aus: Call-ID, tag im Feld From und tag im Feld To in der Antwort vom IPTelefon des Angerufenen – siehe z.B. die Responses 180 Ringing in Abbildung 1.7-10. Die Dialog-ID dient als Verweis auf den sog. Call Detail Record mit u.a. gebührenrelevanten Daten.
Route von
Das Header-Feld Via wird in INVITE für mehrere Zwecke verwendet. Es beginnt immer mit der Angabe der SIP-Version und des verwendeten Transportprotokolls – d.h. SIP/2.0/UDP beim UDP-Einsatz – und ermöglicht, die Route von INVITE aufzuzeichnen. Die Aufzeichnung der Route erfolgt dadurch, dass jeder Rechner – sowohl das IP-Telefon des Anrufers als auch jeder Proxy unterwegs, der INVITE abschickt, vorher ein Header-Feld Via mit seinen vollständigen Namen11 bzw mit seiner IP-Adresse vor dem eventuell bereits eingetragenen Feld Via hinzufügt.
INVITE
11
Der vollständige Name eines Rechners im DNS – der sog. FQDN (Full Qualified Domain Name) – setzt sich aus dem Rechnernamen und dem Domainnamen zusammen. Der vollständige Name z.B. des Rechners sonne in der Domain abc.de ist sonne.abc.de.
7.1 Verschiedene Aspekte des SIP-Einsatzes
291
Hat die Nachricht INVITE das IP-Telefon des Angerufenen erreicht, bringt sie in den HeaderFeldern Via die Aufzeichnung ihrer Route mit, d.h. wer sie zuerst abgeschickt hat und über welche SIP-Proxies sie übermittelt wurde. Kennt das IP-Telefon des Angerufenen die Route von INVITE, kann es diese in die Antwort auf INVITE – in der Regel in den Response 180 Ringing (s. Abb. 7.1-10) – eintragen. Damit wird dieser Response über die gleiche Route zum IP-Telefon des Anrufers übermittelt. Auf die Bedeutung von Via geht auch Abschnitt 7.8 ein. I N I V I T E s ip :b o b @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P p x 2 .a b c .d e ;b r a n c h = z 9 h G 4 b K k js h 5 6 V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ; ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ; r e c e iv e d = a .b .c .d M a x -F o rw a rd s: 6 9 I N I V I T E s ip :b o b @ x y z .d e S I P /2 .0 T o : B o b < s ip :b o b @ x y z .d e > F r o m : A lic e < s ip :a lic e @ a b c .d e > V ia : S I P /2 .0 /U D P s p x .x y z .d e ;b r a n c h = z 9 h G 4 b K n p s d r k 4 V ia : S I P /2 .0 /U D P p x 2 .a b c .d e ;b r a n c h = z 9 h G 4 b K k js h 5 6 ; ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e ;r e c e iv e d = p .r .s .t V ia : S I P /2 .0 /U D P s o n n e .a b c .d e C se q : 1 2 3 IN V IT E ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d C o n ta c t: < s ip :a lic e @ a b c .d e > C o n te n t-T y p e : a p p lic a tio n /S D P M a x -F o rw a rd s : 6 8 T o : B o b < s ip :b o b @ x y z .d e > C o n te n t-L e n g th : x x x F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 4 2 7 2 B e s c h r e ib u n g d e r S e s s io n C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n ta c t: < s ip :a lic e @ a b c .d e > C o n te n t-T y p e : a p p lic a tio n /S D P C o n te n t-L e n g th : x x x
I N I V I T E s ip :b o b @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b ra n c h = z 9 h G 4 b K n a s h d s 9 M a x -F o rw a rd s: 7 0 T o : B o b < s ip :b o b @ x y z .d e > F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n ta c t: < s ip :a lic e @ a b c .d e > C o n te n t-T y p e : a p p lic a tio n /S D P C o n te n t-L e n g th : x x x
B e s c h r e ib u n g d e r S e s s io n A lic e
so n n e
S IP -P ro x y
a .b .c .d
IN V IT E
p x 2
sp x
1 0 0 T ry in g
x y z .d e
IN V IT E
1 8 0 R in g in g
1 0 0 T ry in g
2 0 0 O K
S I P /2 .0 1 0 0 T r y in g V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d T o : B o b < s ip :b o b @ x y z .d e > F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n te n t-L e n g th : 0
v = o = s= c : t=
0
A lic S c h IN I 0 0 m = a u d a = rtp m
e 2 8 7 0 5 4 4 3 2 1 2 8 7 0 5 4 4 5 5 5 I N I P 4 s o n n e .a b c .d e o e n e G ru e sse P 4 s o n n e .a b c .d e B e s c h r e ib u n g d e r S e s s io n
io 4 5 1 2 3 R T P /A V P a p :0 P C M /8 0 0 0
S IP -P ro x y u .v .w .x
www.wiwobooks.com
a b c .d e
1 8 0 R in g in g 2 0 0 O K A C K
B e s c h r e ib u n g d e r S e s s io n
p .r .s .t
0
IN V IT E 1 8 0 R in g in g 2 0 0 O K
B o b
m o n d
S I P /2 .0 1 0 0 T r y in g V ia : S I P /2 .0 /U D P p x 2 .a b c .d e ;b r a n c h = z 9 h G 4 b K k js h 5 6 ;r e c e iv e d = p .r .s .t V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d T o : B o b < s ip :b o b @ x y z .d e > F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n te n t-L e n g th : 0
n a c h S D P in I N V I T E
Abb. 7.1-9: Nachrichten INVITE und 100 Trying beim SIP-Verlauf in Abbildung 7.1-8 Jedes Header-Feld Via enthält den Parameter branch als Identifikation einer SIP-Transaktion im Rechner, der das entsprechende Feld Via hinzugefügt hat. Der Parameter branch beginnt immer mit den folgenden sieben Zeichen z9hG4bK. Diese Zeichenkette dient als sog. magic cookie – siehe RFC 3261. Ein Proxy kann den Parameter branch nutzen, um ein INVITE parallel an mehrere IP-Telefone zu verschicken und damit die Verzweigung eines ankommenden Anrufs zu realisieren (s. Abb. 7.2-4). In diesem Fall enthält jede Kopie von INVITE – die zu einer neuen
Bedeutung von branch
292
7
VoIP mit SIP
SIP-Transaktion geführt hat – einen anderen branch-Wert. Auf diese Weise werden die einzelnen Anrufverzweigungen identifiziert.
Bedeutung von received
Jeder Proxy kann im Feld Via, das sein Vorgänger hinzugefügt hat, seine IP-Adresse – als Angabe received – eintragen, nachdem er von ihm eine Nachricht INVITE empfangen hat. Mit dem so ergänzten Feld Via wird INVITE weitergeleitet. Abbildung 7.1-9 illustriert dies. Auf diese Weise wird die Route von INVITE deutlicher spezifiziert. Im Feld Via können weitere Parameter angegeben werden. Mit dem Parameter rport (remote port) kann ein Absender auf einen sog. Symmetric Response verweisen. Auf die Nutzung dieser Möglichkeit geht Abschnitt 10.6.3 genauer ein. Abbildung 7.1-10 zeigt die Nachrichten 100 Trying, 200 OK und ACK beim SIP-Verlauf in Abbildung 1.7-8.
S V T F C C C
S I P /2 .0 1 8 0 R in g in g V ia : S I P /2 .0 /U D P p x 2 .a b c .d e I P /2 .0 1 8 0 R in g in g ;b r a n c h = z 9 h G 4 b K k js h 5 6 ;r e c e iv e d = p .r .s .t ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d o : B o b < s ip :b o b @ x y z .d e > ; ta g = iy v a d 6 d 3 4 s r o m : A l i c e < s i p : a l i c e @ a b c . d e > ; t a g = 1 3 2 4 2 5 4 2 T 7 o2 : B o b < s i p : b o b @ x y z . d e > ; t a g = i y v a d 6 d 3 4 s F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e se q : 1 2 3 IN V IT E C se q : 1 2 3 IN V IT E o n te n t-L e n g th : 0 C o n te n t-L e n g th : 0
A lic e
a .b .c .d
p x 2
p .r .s .t
a b c .d e
sp x
x y z .d e
S I P /2 .0 1 8 0 R in g in g V ia : S I P /2 .0 /U D P s p x .x y z .d e ;b ra n c h = z 9 h G 4 b K n p s d rk 4 ;re c e iv e d = u .v .w .x V ia : S I P /2 .0 /U D P p x 2 .a b c .d e ;b r a n c h = z 9 h G 4 b K k js h 5 6 ;r e c e iv e d = p .r .s .t V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d 4 T 2 7o 2: B o b < s i p : b o b @ x y z . d e > ; t a g = i y v a d 6 d 3 4 s F r o m : A lic e < s ip :a lic e @ a b c .d e > ; ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n te n t-L e n g th : 0
S IP -P ro x y u .v .w .x IN V IT E 1 8 0 R in g in g 2 0 0 O K
www.wiwobooks.com
so n n e
IN V IT E
1 0 0 T ry in g 1 8 0 R in g in g 2 0 0 O K A C K
S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c .d T o : B o b < s ip :b o b @ x y z .d e > ;ta g = iy v a d 6 d 3 4 s F r o m : A lic e < s ip :a lic e @ a b c .d e > ;ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C s e q : 1 2 3 IN V IT E C o n ta c t: < s ip :b o b @ i.j.k .l> C o n te n t-T y p e : a p p lic a tio n /S D P C o n te n t-L e n g th : x x x
B e s c h r e ib u n g d e r S e s s io n
IN V IT E
1 0 0 T ry in g 1 8 0 R in g in g 2 0 0 O K
S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P p x 2 .a b c .d e ;b ra n c h = z 9 h G 4 b K k js h 5 6 ;re c e iv V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b ra n c h = z 9 h G 4 b K n a s h d s 9 ;re c e T o : B o b < s ip :b o b @ x y z .d e > ;ta g = F r o m : A lic e < s ip :a lic e @ a b c .d e > ;ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d C s e q : 1 2 3 IN V IT E C o n ta c t: < s ip :b o b @ i.j.k .l> C o n te n t-T y p e : a p p lic a tio n /S D P C o n te n t-L e n g th : x x x
B e s c h r e ib u n g d e r S e s s io n
A C K s ip :b o b @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 M a x -F o rw a rd s: 7 0 T o : B o b < s ip :b o b @ x y z .d e > ;ta g = iy v a d 6 d 3 4 s F r o m : A lic e < s ip :a lic e @ a b c .d e > ;ta g = 1 3 2 4 2 5 4 2 7 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 A C K C o n te n t-L e n g th : x x x
B o b
m o n d i.j.k .l
S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P s p x .x y z .d e e d = p .r .s .t ;b ra n c h = z 9 h G 4 b K n p s d rk 4 ;re c e iv e d = u .v .w V ia : S I P /2 .0 /U D P p x 2 .a b c .d e iv e d = a .b .c .d ;b r a n c h = z 9 h G 4 b K k js h 5 6 ;r e c e iv e d = p .r .s .t iy v a d 6 d 3 4 s V ia : S I P /2 .0 /U D P s o n n e .a b c .d e ;b r a n c h = z 9 h G 4 b K n a s h d s 9 ;r e c e iv e d = a .b .c T o : B o b < s ip :b o b @ x y z .d e > ;ta g = iy v a d 6 d 3 4 e F r o m : A lic e < s ip :a lic e @ a b c .d e > ;ta g = 1 3 2 4 2 C a ll- I D : a 6 4 b 5 4 3 1 @ s o n n e .a b c .d e C se q : 1 2 3 IN V IT E C o n ta c t: < s ip :b o b @ i.j.k .l> C o n te n t-T y p e : a p p lic a tio n /S D P C o n te n t-L e n g th : x x x s
.x
.d 5 4 2 7 2
B e s c h r e ib u n g d e r S e s s io n
Abb. 7.1-10: 100 Trying, 200 OK und ACK beim SIP-Verlauf in Abbildung 7.1-8 Wie hier ersichtlich ist, erhält der Response 200 OK die Beschreibung der Session – seitens von Bob – und das Header-Feld Contact, mit dem hier bereits im SIP-URI von Bob die IP-Adresse seines IP-Telefons angegeben wurde. Somit kann das IP-Telefon von Alice die Nachricht ACK direkt – ohne vorher das DNS nutzen zu müssen – an das IP-Telefon von Bob senden. Die Struktur von SIP-Nachrichten und die Bedeutung wichtiger Angaben im Header werden in Abschnitt 7.3 detaillierter erläutert.
7.1 Verschiedene Aspekte des SIP-Einsatzes
SIP-Verlauf innerhalb einer Domain Bisher wurde angenommen, dass sich die kommunizierenden Benutzer in verschiedenen Domains befanden und dass die beiden die SIP-URIs mit der Struktur sip:user@domain hatten. Aus dem SIP-Verlauf zwischen zwei IP-Telefonen in verschiedenen Domains kann unmittelbar der SIP-Verlauf zwischen zwei IP-Telefonen innerhalb einer Domain abgeleitet werden. Abbildung 7.1-11 illustriert diesen SIP-Verlauf. s ip :a lic e @ a b c .d e
S IP -P ro x y
A lic e
IN V IT E
S e s s io n -A u fb a u F re ito n
1 0 0 T ry in g 1 8 0 R in g in g 2 0 0 O K
s ip :b o b @ a b c .d e
D o m a in a b c .d e IN V IT E
B o b 1 8 0 R in g in g 2 0 0 O K
K lin g e ln
A C K A u fg e le g t S e s s io n -A b b a u
S e s s io n a ls V o IP -V e rb in d u n g B Y E
2 0 0 O K
Abb. 7.1-11: SIP-Verlauf beim Auf- und Abbau einer Session innerhalb einer Domain
www.wiwobooks.com
SIP-Verlauf ohne Proxy
Falls die beiden IP-Telefone mit SIP-URIs sip:user@ipv4address – also mit der Angabe von IP-Adressen der Rechner mit Soft-IP-Telefonen – adressiert werden, verläuft der Auf- und Abbau einer Session, wie Abbildung 7.1-12 zeigt, direkt zwischen den betreffenden Rechnern, ohne einen SIP-Proxy. Bei der Nutzung von SIP-URIs mit der Form sip:user@ipv4address bzw. sip:user@hostname müssen keine SIP-Proxies eingesetzt werden. Diese Art von SIP-URIs eignet sich daher für VoIP-Anwendungen in kleinen Firmen oder in privaten Home-Networks. A lic e F re ito n
S e s s io n A u fb a u
s ip :a lic e @ 1 0 .1 .5 .6
IN V IT E A C K
s ip :b o b @ 1 0 .1 .2 .3
1 8 0 R in g in g 2 0 0 O K S e s s io n a ls V o IP -V e rb in d u n g
S e s s io n A b b a u
2 0 0 O K
B Y E
B o b K lin g e ln A b g e h o b e n
A u fg e le g t
Abb. 7.1-12: SIP-Verlauf zwischen zwei IP-Telefonen – ohne SIP-Proxy zu nutzen
293
294
7
VoIP mit SIP
Der typische SIP-Verlauf beim Auf- und Abbau einer Session, den Abbildung 7.1-8 zeigt, wird auch in RFC 3261 bei der SIP-Spezifikation beschrieben. Die hier verwendeten SIP-Nachrichten werden im Internet detailliert erläutert unter http://www.tech-invite.com/Ti-sip-CF3261.html
7.2 SIP-Server
Beispiele für den Einsatz von SIP
SIP kann in IP-Netzen vielseitig als Signalisierungsprotokoll bei VoIP eingesetzt werden. Bei SIP werden verschiedene SIP-Server definiert, die bestimmte Aufgaben beim Aufbau einer Session übernehmen. Die SIP-Server sind: Proxy-Server – oft als SIP-Proxy bezeichnet, Redirect-Server und Registrar, der oft auch als Location-Server dient. Alle SIP-Server werden in der Regel als Software-Funktionsmodule implementiert und auf hierfür geeigneten, dedizierten Rechnern untergebracht.
Benutzermobilität mit SIP
Eine wesentliche Aufgabe der Proxy-Server ist die Unterstützung der Mobilität, damit ein Benutzer – der Angerufene – sich zwischen verschiedenen DNSDomains „bewegen“ und trotzdem erreichbar sein kann. Der Angerufene kann seine Heimat-Domain, die dem Anrufenden aus dem SIP-URI des Angerufenen bekannt ist, verlassen und sich als Gast innerhalb einer anderen Fremd-Domain aufhalten, die dem Anrufenden noch nicht bekannt ist. Ist der Angerufene in eine Fremd-Domain „umgezogen“, kommen beim Aufbau einer Session für die VoIP-Kommunikation mehrere SIP-Server zum Einsatz, mit deren Hilfe die ankommenden Anrufe in die Fremd-Domains weitergeleitet werden.
www.wiwobooks.com
Beispielsweise kann der Benutzer Bob mit seinem SIP-URI sip:[email protected] seine Heimat-Domain xyz.de verlassen, sich in der Fremd-Domain prs.de aufhalten und dort weiterhin unter sip:[email protected] erreichbar sein. Eine bereits an den SIP-URI sip:[email protected] initiierte Session kann beim Einsatz eines Redirect-Servers in die Fremd-Domain prs.de umgeleitet (s. Abb. 7.2-2) bzw. beim Einsatz eines Proxy-Servers in die Fremd-Domain prs.de weitergeleitet werden (s. Abb. 7.2-3). Szenarien beim SIPEinsatz
12
Die SIP-Server können in verschiedenen Szenarien eingesetzt werden. Weiteren gehen wir auf die folgenden näher ein:
Im
Typischer Einsatz eines Proxy-Servers (s. Abb. 7.2-1) 12
Die typischen SIP-Abläufe inklusive SIP-Nachrichten stellt RCF 3665 dar. Sie sind unter http://www.tech-invite.com/Ti-sip-CF3665.html abrufbar.
7.2 Beispiele für den Einsatz von SIP
Umleitung einer Session mit einem Redirect-Server (s. Abb. 7.2-2) Weiterleitung einer Session mit einem Proxy-Server (s. Abb. 7.2-3) Anrufverzweigung zu mehreren Endeinrichtungen (s. Abb. 7.2-4); Einsatz eines Voice-Mail-Servers (s. Abb. 7.2-5)
7.2.1 Typischer Einsatz von SIP-Proxy-Servern Die Bedeutung von SIP-Proxies (auch SIP-Proxy-Server) wurde bereits in den Abbildungen 7.1-3 bis 7.1-6 demonstriert. Die Rolle eines Proxy-Servers beim Aufbau einer Session soll nun kurz zusammengefasst und so erklärt werden, dass der Unterschied zur Funktionsweise des Redirect-Servers klar wird. Hierfür zeigt Abbildung 7.2-1 die ersten Schritte zum Aufbau einer Session für VoIP-Kommunikation unter Einsatz von Proxy-Servern.
s ip :a lic e @ a b c .d e
A lic e
P S
IP -N e tz (In te rn e t)
L S
s ip :b o b @ x y z .d e
x y z .d e B o b
www.wiwobooks.com S 1
IN V IT E
1 0 0 T ry in g
F re ito n
P S
a b c .d e
S 2
S 2
1 8 0 R in g in g
IN V IT E
1 0 0 T ry in g
...
1 8 0 R in g in g
S 3
IN V IT E
S 3
1 8 0 R in g in g
S 4
K lin g e ln
(R in g in g )
S e s s io n (V o IP -K o m m u n ik a tio n ) R e sp o n se R e q u e st
Abb. 7.2-1: Einsatz von Proxy-Servern beim Aufbau einer Session LS: Location-Server, PS: Proxy-Server
Weil der SIP-URI sip:[email protected] hier nur den Namen der Domain des Angerufenen Bob enthält, weiß der Anrufer Alice nur, in welcher Domain Bob registriert – also beheimatet – ist. Welchen Rechner Bob aktuell als sein IPTelefon nutzt, d.h. unter welcher IP-Adresse dieser erreichbar ist, kann Alice dem SIP-URI von Bob nicht entnehmen. In diesem Fall kommen zwei SIPServer in der Domain des Angerufenen – von Bob also – zum Einsatz, nämlich ein Proxy-Server und ein Location-Server. Diese beiden Server können auch auf einem Rechner implementiert werden. Die ersten Schritte beim Aufbau einer Session (s. Abb. 7.2-1) haben folgende Bedeutung: S1:
Das IP-Telefon von Alice initiiert eine Session durch Absenden der Nachricht INVITE als SIP-Request an den Proxy-Server in Domain abc.de.
S2:
Dieser Proxy-Server leitet INVITE an den Proxy-Server der Domain xyz.de von Bob weiter und signalisiert dies dem IP-Telefon von Alice mit der Nachricht 100 Trying, die einen SIP-Response darstellt.
295
296
7
VoIP mit SIP
S3:
Der Proxy-Server der Domain von Bob fragt zuerst beim Location-Server dieser Domain, welches IP-Telefon Bob gerade nutzt. Danach sendet der Proxy-Server INVITE an das IPTelefon von Bob weiter und informiert darüber den Proxy-Server der Domain abc.de mit 100 Trying.
S4:
Das IP-Telefon von Bob signalisiert dem IP-Telefon von Alice mit dem SIP-Response 180 Ringing, dass der ankommende Anruf angenommen werden kann. Dieser SIP-Response wird über die beiden Proxy-Server an das IP-Telefon von Alice übermittelt.
Da der in Abbildung 7.2-1 dargestellte Verlauf von SIP dem Verlauf in Abbildung 7.1-8 entspricht, wurde hier auf die Darstellung des weiteren SIP-Verlaufs verzichtet.
Proxy-Server als Weiterleitungsinstanz
Aus dem eben dargestellten Beispiel resultiert, dass ein Proxy-Server wie folgt charakterisiert werden kann: Ein Proxy-Server ist ein SIP-Vermittlungssystem, 13 das SIP-Requests empfängt, diese weiterleitet und eventuell auch beantwortet mit SIP-Responses, wie z.B. 100 Trying (s. Abb. 7.1-1). Hierbei analysiert er in Requests nur den Header und nicht den Body-Teil. Die wesentliche Aufgabe eines Proxy-Servers ist die Weiterleitung empfangener Requests und empfangener Responses sowie das Senden von Responses – als eine Art Bestätigung – an die Absender von Requests. Ein Proxy-Server ist lediglich am Aufbau und Abbruch einer Session beteiligt.
www.wiwobooks.com
7.2.2 Umleitung einer Session mit Redirect-Server Funktion des RedirectServers
Anstelle eines SIP-Proxies ist auch der Einsatz eines sog. Redirect-Servers möglich. Seine Aufgabe kann darin bestehen, den Absender, von dem er den Request INVITE empfangen hat – wie z.B. IP-Telefon, Proxy-Server –, darüber zu informieren, in welcher Fremd-Domain sich der Angerufene aktuell aufhält. Ein Redirect-Server informiert somit den Absender nur darüber, zu welcher Domain die bereits initiierte Session aufgebaut bzw. weitergeleitet werden soll. Um die Funktion eines Redirect-Servers näher zu erläutern, zeigt Abbildung 7.2-2 die ersten Schritte beim Aufbau einer Session, die hier zu einer Fremd-Domain weitergeleitet wird. Die ersten Schritte beim Aufbau einer Session für VoIP sind die folgenden: S1:
Das IP-Telefon von Alice initiiert eine Session durch Absenden des Request INVITE an den Proxy-Server der Domain abc.de.
S2:
Dieser Proxy-Server leitet INVITE an den SIP-Server der Domain xyz.de von Bob weiter und informiert darüber das IP-Telefon von Alice mit dem Response 100 Trying.
S3:
Der SIP-Server der Domain xyz.de, der als Redirect-Server dient, fragt zuerst beim Location-Server an, welchen Rechner Bob gerade als sein IP-Telefon nutzt. Im Location-Server ist aber eingetragen, dass Bob sich aktuell in der Fremd-Domain prs.de aufhält. Daher informiert der Redirect-Server nun den Proxy-Server der Domain abc.de mit dem Response 302 Moved Temporalily darüber, dass der Angerufene momentan umgezogen ist; wohin, wird durch die Angabe des Namens der Fremd-Domain prs.de in der Zeile
13
In bestimmten Fällen kann ein Proxy-Server die SIP-Requests CANCEL und ACK auch generieren – siehe hierfür z.B. Abbildungen 7.2-2 und -4.
7.2 Beispiele für den Einsatz von SIP
297
Contact mitgeteilt. Der Proxy-Server der Domain abc.de bestätigt dem RedirectServer den Empfang von 302 Moved Temporalily mit dem Request ACK.
s ip :a lic e @ a b c .d e
a b c .d e
A lic e S 1
IN V IT E
1 0 0 T ry in g
S 2
3 0 2 M o v e d T e m p o ra rily
... ...
C o n ta c t: s ip :< b o b @ p r s .d e >
P S
IP -N e tz (In te rn e t) S 2 S 4
1 8 0 R in g in g
R S
H e im a t-D o m a in v o n B o b
L S x y z .d e
F re m d -D o m a in v o n B o b
L S
IN V IT E M o v e d S A C K
P S 3
...
p r s .d e B o b
IN V IT E
1 0 0 T ry in g S 1 8 0 R in g in g
s ip :b o b @ x y z .d e
5
S 5
IN V IT E
1 8 0 R in g in g
S 6
S e s s io n (V o IP -K o m m u n ik a tio n ) R e q u e st R e sp o n se
Abb. 7.2-2: Einsatz eines Proxy- und eines Redirect-Servers beim Aufbau einer Session LS: Location-Server, PS: Proxy-Server, RS: Proxy-Server
S4:
Der Proxy-Server der Domain abc.de übermittelt INVITE direkt an den SIP-Server der Fremd-Domain von Bob.
S5:
Der SIP-Server der Fremd-Domain von Bob, der als Proxy-Server fungiert, fragt beim Location-Server dieser Domain, welchen Rechner Bob gerade als IP-Telefon nutzt, ermittelt seine IP-Adresse, sendet INVITE an das IP-Telefon von Bob weiter und informiert danach den Proxy-Server der Domain abc.de darüber mit dem Response 100 Trying.
S6:
Das IP-Telefon von Bob signalisiert nach dem Empfangen von INVITE dem IP-Telefon von Alice mit dem SIP-Response 180 Ringing, dass der ankommende Anruf angenommen werden kann. Dieser SIP-Response wird über die beiden Proxy-Server – d.h. über den Proxy-Server der Fremd-Domain prs.de von Bob und über den Proxy-Server der Domain abc.de – an das IP-Telefon von Alice übermittelt.
www.wiwobooks.com
Dieses Beispiel verdeutlicht, dass ein Redirect-Server wie folgt charakterisiert werden kann: Ein Redirect-Server empfängt einen SIP-Request INVITE und leitet diesen – im Gegensatz zum Proxy-Server – nicht weiter, sondern informiert den letzten Absender von INVITE mit dem SIP-Response 302 Moved Temporarily darüber, in welche Domain die von ihm bereits initiierte Session umgeleitet werden soll. Er kann daher als Session-Umleitungsinstanz angesehen werden.
RedirectServer als Umleitungsinstanz
Mit Hilfe von Redirect-Servern lässt sich somit eine fast uneingeschränkte Mo- Mobilität bilität von Benutzern unterstützen. Ein Benutzer mit seinem immer gleichen von SIP-URI kann seine Heimat-Domain verlassen, sich sogar weltweit zwischen Benutzern verschiedenen Fremd-Domains „bewegen“ und wird dank des Einsatzes von Redirect-Servern weiterhin unter demselben SIP-URI erreichbar sein.
298
7
VoIP mit SIP
7.2.3 Weiterleitung einer Session mit Proxy-Servern Die fast uneingeschränkte Mobilität von Benutzern, die man mit RedirectServern als Umleitungsinstanzen erreicht, lässt sich auch mit Proxy-Servern erreichen. Im Vergleich zu den Redirect-Servern fungieren diese aber als Weiterleitungsinstanzen, und eine Session kann sogar über mehrere Proxy-Server weitergeleitet werden. Diese Möglichkeit stellen wir nun näher dar. Abbildung 7.2-3 illustriert die ersten Schritte beim Aufbau einer Session für die VoIPKommunikation über mehrere Proxy-Server. s ip :a lic e @ a b c .d e
a b c .d e A lic e
S 1
IN V IT E
1 0 0 T ry in g
P S
P S
S 2
1 8 0 R in g in g
IP -N e tz (In te rn e t)
S 2
F re m d -D o m a in v o n B o b
x y z .d e
S 3
1 8 0 R in g in g
S 3
IN V IT E
1 0 0 T ry in g
...
s ip :b o b @ x y z .d e
L S
p r s .d e
P S
IN V IT E 1 0 0 T ry in g
H e im a t-D o m a in v o n B o b
L S
S 4
1 8 0 R in g in g
S e s s io n (V o IP -K o m m u n ik a tio n ) R e q u e st
S 4
IN V IT E
1 8 0 R in g in g
S 5
B o b
K lin g e ln
www.wiwobooks.com R e sp o n se
Abb. 7.2-3: Weiterleitung einer Session durch Proxy-Server aus der Domain des Angerufenen LS: Location-Server, PS: Proxy-Server
An dieser Stelle ist hervorzuheben, dass der angerufene Benutzer seine HeimatDomain verlassen kann und in jede andere Domain „hineingehen“ kann. Um immer erreichbar zu sein, muss er in seiner Heimat-Domain eine Information darüber hinterlassen, in welcher Fremd-Domain er sich aktuell aufhält. Hierfür muss der Benutzer einerseits den Location-Server seiner Heimat-Domain darüber informieren, in welcher Fremd-Domain er sich aktuell befindet, und andererseits dem Location-Server der Fremd-Domain „mitteilen“, welches IP-Telefon innerhalb der Fremd-Domain er aktuell nutzt. Wie aus Abbildung 7.2-3 ersichtlich ist, sind die ersten Schritte beim Aufbau einer Session – und hierbei insbesondere bei der Weiterleitung durch den Proxy-Server der Heimat-Domain des angerufenen Benutzers – die folgenden: S1:
Das IP-Telefon von Alice initiiert eine Session durch Absenden des Request INVITE an den Proxy-Server ihrer Domain abc.de.
S2:
Dieser Proxy-Server leitet INVITE an den SIP-Server der Domain xyz.de von Bob weiter, der als Proxy-Server funktioniert, und informiert das IP-Telefon von Alice darüber mit 100 Trying.
S3:
Der Proxy-Server der Domain xyz.de fragt zuerst beim Location-Server an, welchen Rechner Bob gerade als IP-Telefon nutzt. Im Location-Server ist aber eingetragen, dass Bob sich aktuell in der Fremd-Domain prs.de aufhält. Daher leitet der Proxy-Server der
7.2 Beispiele für den Einsatz von SIP
299
Domain xyz.de den Request INVITE an den SIP-Server der Domain prs.de weiter und signalisiert dies dem Proxy-Server der Domain abc.de mit 100 Trying. S4:
Der Proxy-Server der Domain prs.de fragt beim Location-Server dieser Domain ab, welchen Rechner Bob gerade als IP-Telefon nutzt, ermittelt – mit DNS-Hilfe – seine IPAdresse, leitet INVITE an das IP-Telefon von Bob weiter und informiert darüber den Proxy-Server der Domain xyz.de mit 100 Trying.
S5:
Das IP-Telefon von Bob signalisiert dem IP-Telefon von Alice nach dem Empfang des Request INVITE mit dem SIP-Response 180 Ringing, dass der ankommende Anruf angenommen werden kann. Dieser SIP-Response wird über die drei Proxy-Server, die auf der Route von INVITE liegen, an das IP-Telefon von Alice übermittelt.
Aus dem in Abbildung 7.2-3 dargestellten Beispiel geht hervor, dass ein ProxyServer sich wie ein Zwischensystem verhält, das die SIP-Requests – hier INVITE – zuerst empfängt und dann weitersendet.
7.2.4 Anrufverzweigung mit SIP Bei der Realisierung von VoIP-basierten Konferenzen muss ein ankommender Anruf gleichzeitig an mehrere Ziele weitergeleitet werden. Ein typisches Beispiel dafür ist die sog. Chefsekretärinnen-Funktion, bei der ein Anruf für den Chef in der Regel auch parallel zu einer Sekretärin geführt wird. Ein weiteres Beispiel für eine Verzweigung der ankommenden Anrufe könnte die folgende Situation sein: Ein Benutzer hat mehrere SIP-Adressen als SIP-URIs, eine für sein IP-Telefon zu Hause und die anderen für sein IP-Telefon im Büro und für sein IP-Handy. Die für diesen Benutzer ankommenden Anrufe müssen so – quasi „parallel“ – an seine IP-Telefone übermittelt werden. Hierfür wird im Proxy-Server eine sog. Forking-Funktion realisiert. Man spricht auch von Call Forking bzw. Call Splitting.
www.wiwobooks.com
Wann erfolgt eine Verzweigung der Anrufe?
Mit Hilfe von Call Forking in einem Proxy-Server lassen sich verschiedene Dienstmerkmale realisieren, wie z.B. Umleitung bei Besetzt bzw. Follow-me (Find-me), bei denen nach dem Angerufenen gesucht wird. Abbildung 7.2-4 illustriert die Verzweigung eines ankommenden Anrufs durch Verzweigung den Proxy-Server der Heimat-Domain des Angerufenen. Im vorliegenden der Anrufe Beispiel kennt die Anrufende, Alice, nur einen SIP-URI sip:[email protected] von Bob. Diesem SIP-URI ist aber eine Liste von SIP-URIs – wie z.B. sip:[email protected] und sip:[email protected] – im Location-Server der Heimat-Domain von Bob zugeordnet, sodass der ankommende Anruf nach festgelegten Prinzipien an die einzelnen URIs aus der Liste weitergeleitet werden kann. Die Schritte beim Aufbau einer Session für VoIP lassen sich wie folgt beschreiben: S1:
Das IP-Telefon von Alice initiiert eine Session durch Absenden des Request INVITE mit dem SIP-URI sip:[email protected] an den Proxy-Server ihrer Domain abc.de.
300
7
VoIP mit SIP
Dieser Proxy-Server leitet INVITE an den SIP-Server der Domain xyz.de von Bob weiter – der als Proxy-Server fungiert – und informiert darüber das IP-Telefon von Alice mit 100 Trying.
s ip :b o b @ x y z .d e
s ip :a lic e @ a b c .d e
P S
a b c .d e
IP -N e tz (In te rn e t)
A lic e S 1
IN V IT E
1 0 0 T ry in g
S 2
R in g (A ) R in g (B )
S 2
P S
A
IN V IT E 1 0 0 T ry in g
R in g (A )
S 3
R in g (B )
2 0 0 O K (B )
2 0 0 O K (B )
x y z .d e
L S
S 3 S 4 S 5 S 6
IN V IT E (1 ) R in g (A )
B
IN V IT E (2 )
R in g (B ) 2 0 0 O K (B )
C A N C E L
S 7
A C K
B o b
2 0 0 O K
a b g e h o b e n
S e s s io n (V o IP -K o m m u n ik a tio n ) R e q u e st
R e sp o n se
Abb. 7.2-4: Forking-Funktion im Proxy-Server – Verzweigung ankommender Anrufe LS: Location-Server, PS: Proxy-Server, Ring: 180 Ringing
www.wiwobooks.com
S2:
Der Proxy-Server der Domain xyz.de fragt zuerst beim Location-Server, welchen Rechner Bob gerade als IP-Telefon nutzt. Im Location-Server ist eingetragen, dass Bob sich am IP-Telefon A ([email protected]) oder am IP-Telefon B ([email protected]) aufhalten kann. Daher leitet der Proxy-Server den Request INVITE an diese beiden IP-Telefone von Bob so weiter, als ob mehrere Kopien von INVITE abgeschickt würden, und übermittelt 100 Trying an den Proxy-Server der Domain xyz.de, um ihn darüber zu informieren. Hierbei wird jede der Kopien von INVITE durch eine Angabe im Feld branch der HeaderZeile Via (s. Abb. 1.7-9) entsprechend markiert.
S3:
Die beiden IP-Telefone A und B von Bob signalisieren dem IP-Telefon von Alice mit dem SIP-Response 180 Ringing, dass der ankommende Anruf angenommen werden kann. Dieser SIP-Response übermitteln die beiden Proxy-Server.
S4:
Bob hat den ankommenden Anruf mit dem IP-Telefon B angenommen, was dem IPTelefon von Alice mit dem SIP-Response 200 OK signalisiert wird. Hierbei wird 200 OK über die beiden Proxy-Server übermittelt.
S5:
Der Proxy-Server der Domain xyz.de sendet nun den Request CANCEL an das IP-Telefon A, um den Aufbau der Session zu ihm abzubrechen. Den Empfang von CANCEL bestätigt das IP-Telefon A dem Proxy-Server mit 200 OK.
S6:
Abschließend bestätigt das IP-Telefon von Alice mit dem Request ACK dem IP-Telefon B von Bob den Empfang des Response 200 OK. Damit wird der Aufbau einer Session beendet. Nach dem Eintreffen von 200 OK beim IP-Telefon von Alice ist diesem bereits der „Hostname“ des IP-Telefons B von Bob – und somit dank DNS auch seine IP-Adresse – bekannt. ACK kann nun direkt – an den Proxy-Servern vorbei – an das IP-Telefon B von Bob übermittelt werden.
7.2 Beispiele für den Einsatz von SIP
Aus dem in Abbildung 7.2-4 dargestellten Beispiel, geht hervor, dass sich ein Proxy-Server mit Forking-Funktion wie ein Verteiler von Requests INVITE verhält. Diese Funktion liegt allen Systemen für die Realisierung der Gruppenkommunikation zugrunde, wie z.B. Konferenzsystemen oder virtuellen Klassenräumen.
7.2.5 Einsatz eines Voice-Mail-Servers Ankommende Anrufe können zu einem Voice-Mail-Server umgeleitet werden. Insbesondere ist dies z.B. während der Abwesenheit des angerufenen Benutzers an seinem Telefon sinnvoll. Abbildung 7.2-5 zeigt zwei Beispiele für die Anrufumleitung zum Voice-Mail-Server. Um dies mit SIP realisieren zu können, muss der Proxy-Server der Heimat-Domain des Angerufenen nur entsprechend konfiguriert werden. s ip :a lic e @ a b c .d e
P S
a b c .d e A lic e a )
1 0 0 T ry in g
S 2
1 8 1 F o rw a rd e d
S 5
b )
S 4
2 0 0 O K
IN V IT E
S 1
S IP S e rv e r
V o ic e -M a ilS e rv e r
x y z .d e B o b
www.wiwobooks.com
IN V IT E
S 1
IP -N e tz (In te rn e t)
1 0 0 T ry in g
S 2
1 8 1 F o rw a rd e d 2 0 0 O K
S 7
S 2
S 4
IN V IT E
3 0 2 M o v e d T e m p o r. A C K
S 3
IN V IT E 2 0 0 O K
2 0 0 O K
A C K S e s s io n (V o IP -K o m m u n ik a tio n )
S 2
IN V IT E 1 0 0 T ry in g 1 8 1 F o rw a rd e d
S 3 S 5
S 3
IN V IT E
4 8 6 B u sy
S 5
S 4
A C K
2 0 0 O K
S 4 2 0 0 O K
IN V
S 6
A C K S e s s io n (V o IP -K o m m u n ik a tio n )
Abb. 7.2-5: Beispiele für die Umleitung eines Anrufs zu einem Voice-Mail-Server: a) Umleitung in jedem Fall; b) Umleitung bei Besetzt PS: Proxy-Server
Man unterscheidet die folgenden drei Arten der Umleitung zum Voice-MailServer:
301
302
7
VoIP mit SIP
Umleitung in jedem Fall – Call Forwarding Unconditional (CFU) Bei dieser Art der Umleitung wird ein ankommender Anruf direkt nach seinem Eintreffen beim Proxy-Server zu einem Voice-Mail-Server umgeleitet – siehe Abbildung 7.2-5a. Umleitung bei Besetzt – Call Forwarding Busy (CFB) In diesem Fall wird ein ankommender Anruf vom Proxy-Server zu einem Voice-Mail-Server umgeleitet, falls das Telefon des Angerufenen besetzt ist – siehe Abbildung 7.2-5b. Umleitung bei Nichtmelden – Call Forwarding No Reply (CFNR) In diesem Fall wird ein ankommender Anruf vom Proxy-Server zu einem Voice-Mail-Server umgeleitet, falls der Anruf am Telefon des Angerufenen nicht angenommen wird. CFU mit SIP
Die ersten Schritte bei der Umleitung vom Proxy-Server eines ankommenden Anrufs zum VoiceMail-Server in jedem Fall (CFU)– wie in Abbildung 7.2-5a gezeigt – sind: S1:
Das IP-Telefon von Alice initiiert eine Session durch Absenden von INVITE mit dem SIPURI sip:[email protected] von Bob an den Proxy-Server ihrer Domain abc.de.
S2:
Der Proxy-Server der Domain abc.de leitet INVITE an den SIP-Server der Domain xyz.de von Bob weiter – der als Redirect-Server funktioniert – und informiert darüber das IP-Telefon von Alice mit 100 Trying.
S3:
Dieser SIP-Server teilt dem Proxy-Server der Domain abc.de mit dem Response 302 Moved Temporarily mit, dass die von ihm initiierte Session zum Voice-Mail-Server umgeleitet werden soll. Der Empfang dieses Response wird seitens des Proxy-Servers der Domain abc.de mit dem Request ACK bestätigt.
S4:
Der Proxy-Server der Domain abc.de sendet den Request INVITE an den Voice-MailServer und teilt dem IP-Telefon von Alice mit dem Response 181 Call Is Being Forwarded mit, dass die von ihr initiierte Session zum Voice-Mail-Server umgeleitet wurde.
S5:
Voice-Mail-Server signalisiert dem IP-Telefon von Alice mit 200 OK, dass der ankommende Anruf ersatzweise von ihm entgegengenommen wird.
S6:
Das IP-Telefon von Alice bestätigt dem Voice-Mail-Server den Empfang von 200 OK mit ACK. Damit wurde der Aufbau der Session zum Voice-Mail-Server abgeschlossen. Alice
www.wiwobooks.com
kann nur eine Sprachmitteilung auf dem Voice-Mail-Server speichern lassen.
CFB mit SIP
Abbildung 7.2-5b illustriert die ersten Schritte bei der Umleitung zum Voice-Mail-Server bei Besetzt (CFB). Diese Schritte sind: S1:
Dieser Schritt entspricht dem Schritt 1 in Abbildung 7.2-5a.
S2:
Dieser Schritt hat die gleiche Bedeutung wie Schritt 2 in Abbildung 7.2-5a.
S3:
Der Proxy-Server der Domain xyz.de fragt zuerst beim Location-Server an, welchen Rechner Bob gerade als sein IP-Telefon nutzt, ermittelt mit DNS-Hilfe seine IP-Adresse, leitet INVITE an das IP-Telefon von Bob weiter und informiert mit 100 Trying danach den Proxy-Server der Domain xyz.de darüber.
S4:
Das IP-Telefon von Bob ist zurzeit besetzt, was dem Proxy-Server der Domain xyz.de mit dem Response 486 Busy Here signalisiert wird. Der Proxy-Server bestätigt den Empfang dieses Response mit ACK.
7.3 SIP-Nachrichten – ihre Bedeutung und Struktur S5:
Der Proxy-Server der Domain xyz.de.de leitet danach INVITE an den Voice-MailServer und informiert das IP-Telefon von Alice mit dem Response 181 Call Is Being Forwarded darüber, dass die von ihr initiierte Session bereits zum Voice-Mail-Server umgeleitet wurde.
S6:
Der Voice-Mail-Server signalisiert dem IP-Telefon von Alice mit 200 OK, dass der ankommende Anruf ersatzweise von ihm entgegengenommen wird.
S7:
Das IP-Telefon von Alice bestätigt dem Voice-Mail-Server den Empfang von 200 OK mit ACK. Damit wurde der Aufbau der Session zum Voice-Mail-Server abgeschlossen.
7.3
303
SIP-Nachrichten – ihre Bedeutung und Struktur
Eine SIP-Nachricht stellt entweder einen Request (eine Anforderung) von ei- Arten nem Initiator der Kommunikation an seinen Kommunikationspartner oder des- von SIPsen Response (eine Antwort) an den Initiator dar. Somit gibt es zwei Arten von Nachrichten SIP-Nachrichten: Request und Response. Jeder Request beschreibt eine geforderte Aktion und jeder Response übermittelt die Reaktion auf den Request.
7.3.1 Request-Typen
www.wiwobooks.com
Die SIP-Spezifikation in RFC 3261, die als Basisspezifikation von SIP gilt, definiert folgende sechs Request-Typen – auch als Methoden bezeichnet: INVITE
Mit dem Request INVITE initiiert ein IP-Telefon eine neue Session für die Übermittlung von Echtzeitmedien. INVITE enthält u.a. die SIP-Adressen des Angerufenen und des Anrufenden sowie die Beschreibung der zu initiierenden Session nach dem Protokoll SDP. In der Beschreibung der Session werden – seitens des Initiators der Session – u.a. die Sprachcodierungsverfahren vorgeschlagen, sodass die Kompatibilität beider IP-Telefone überprüft werden kann. BYE
Mit dem Request BYE wird der Abbau der bestehenden Session – de facto der VoIP-Verbindung – zwischen zwei Teilnehmern initiiert. ACK
Der Request ACK (ACKnowledgement) dient als „positive“ Bestätigung. Mit ACK wird u.a. der Aufbau einer Session abgeschlossen (s. Abb. 7.1-8). CANCEL
Der Request CANCEL wird verwendet, um den Aufbau einer bereits initiierten Session – seitens eines IP-Telefons bzw. seines SIP-Servers – abzubrechen und somit vorzeitig zu beenden – siehe z.B. Abbildung 7.2-4.
304
7
VoIP mit SIP
REGISTER
Im Request REGISTER werden dem sog. Registrar u.a. Informationen über die Lokation von Benutzern – d.h., wann sie welche IP-Telefone nutzen – mitgeteilt. Der Registrar kann als Funktionsmodul im Proxy- bzw. RedirectServer oder im dedizierten Location-Server untergebracht werden. OPTIONS
Mit dem Request OPTIONS können die Medien-betreffenden Fähigkeiten (Media Capabilities) des IP-Telefons eines Teilnehmers abgerufen werden. Beispielsweise kann ein IP-Telefon danach abgefragt werden, welche Arten von Medien (Audio, Video) es empfangen kann und welche Verfahren es zur Codierung dieser Medien unterstützt. Darüber hinaus wurden folgende Request-Typen in anderen RFCs spezifiziert: INFO
Mit dem Request INFO können zwischen den kommunizierenden Rechnern zusätzliche Steuerungsangaben bzw. ergänzende Informationen, die sich nicht direkt auf die bestehende Session beziehen, während dieser übermittelt werden. In INFO lassen sich die Nachrichten vom Signalisierungssystem SS7 bei der Vernetzung der ISDN- bzw. der GSM-Systeme über IP-Netze eingebettet übermitteln. Den Request INFO spezifiziert RFC 2976.
www.wiwobooks.com
PRACK (Provisional Response ACKnowledgement) Einige Responses wie z.B. 180 Ringing haben bei SIP einen vorläufigen Charakter – sie sind sog. Provisional Responses –, sodass sie normalerweise vom Empfänger nicht bestätigt werden. Weil SIP das unzuverlässige Transportprotokoll UDP nutzt, kann ein Provisional Response während der Übermittlung verloren gehen. Mit dem Request PRACK wird einfach mitgeteilt „Auf eine endgültige Antwort (Response) wird gewartet“. PRACK kommt beispielsweise beim Aufbau multimedialer Sessions mit Bandbreitenreservierung in Next Generation Networks zum Einsatz. Die Nutzung von PRACK beschreibt RFC 3262. UPDATE
Mit dem Request UPDATE können bestimmte Parameter, die eine Session betreffen, bereits während des Aufbaus dieser Session verändert werden. In UPDATE wird oft eine modifizierte Beschreibung der Session nach dem Protokoll SDP übermittelt. Die Nutzung von UPDATE spezifiziert RFC 3311. MESSAGE
In RFC 3428 wurde der Request MESSAGE spezifiziert, um Instant Messaging (IM) mit Hilfe von SIP zu ermöglichen. Die Informationen (Mitteilungen) in einem IM-System werden hierbei eingekapselt in Requests MESSAGE transportiert. Daher kann MESSAGE als Body die Information im MIME-Format (Multipurpose Internet Mail Extensions) – als eine im IM-
7.3 SIP-Nachrichten – ihre Bedeutung und Struktur
305
System zu transportierende Nachricht – enthalten. Jeder Request MESSAGE wird mit dem Response 200 OK bestätigt. REFER
Ein wichtiges Dienstmerkmal bei der Sprachkommunikation ist die Anrufumlegung – auch als Call Transfer (CT) bezeichnet. Dieses Dienstmerkmal erlaubt es, eine bestehende Session zwischen Teilnehmer A und Teilnehmer B – beispielsweise – durch den Teilnehmer A auf eine neue Session zwischen Teilnehmer B und Teilnehmer C umzulegen (zu transferieren). Um einen derartigen Session Transfer zu initiieren, wurde in RFC 3515 der Request REFER eingeführt. RFC 3892 spezifiziert die Header-Zeile Referred-By als eine Erweiterung zu REFER. Diese Header-Zeile kann z.B. im Request REFER angegeben werden, um darauf zu verweisen, dass im Body bestimmte Angaben – z.B. über den Initiator von Call Transfer – als MIMEObjekt (vgl. Abb. 11.3-10) enthalten sind. SUBSCRIBE und NOTIFY Die Requests SUBSCRIBE, UNSUBSCRIBE und NOTIFY wurden in RFC Präsenz3265 eingeführt, um mit Hilfe von SIP die sog. Präsenzdienste (Presence dienste Service) realisieren zu können. Als Präsenzdienste bezeichnet man Dienste, mit denen Informationen über den Status eines Objektes – wie z.B. eines Gerätes, eines Teilnehmers (besetzt, frei) – an einen bzw. eine Gruppe von Empfängern der Präsenzinformationen geliefert oder von ihnen abgerufen werden können. Mit Präsenzdiensten kann man verschiedene Statusinformationen verschicken bzw. abrufen.
www.wiwobooks.com
Um die Information über ein Objekt von einem Presence-Server abrufen zu dürfen, muss ein Benutzer eine entsprechende Berechtigung besitzen. Diese erwirbt er durch Abonnieren der gewünschten Information. Dafür wurde SIP um die Methode SUBSCRIBE erweitert. Um den Presence-Server in die Lage zu versetzen, Informationen über den aktuellen Status eines Objektes an einen Benutzer übermitteln zu können, wurde die SIP-Methode NOTIFY eingeführt. Die Requests SUBSCRIBE und NOTIFY werden auch in den in Abschnitt Verschiede1.4.2 dargestellten Ansätzen PINT und SPIRITS für die Integration des ne LeistungsInternet mit dem Intelligent Network bzw. bei der Realisierung verschiede- merkmale ner Leistungsmerkmale – wie z.B. Call Park (s. Abb. 7.7-4), Call Pickup (s. Abb. 7.7-5), Rückruf bei Besetzt (s. Abb. 7.7-9) – verwendet. PUBLISH
Der Request PUBLISH wurde in RFC 3903 für die Realisierung von Präsenzdiensten eingeführt. PUBLISH wird verwendet, um Informationen über den aktuellen Status eines Objektes auf dem Presence-Server abzulegen und
306
7
VoIP mit SIP
sie auf diese Weise zu veröffentlichen. Auf diesem SIP-Request basieren somit die Präsenzdienste.
7.3.2 Response-Klassen Jede SIP-Nachricht als Response hat eine ähnliche Struktur wie im Web-Protokoll HTTP/1.1 – siehe hierfür [BaRS 03] –, d.h., sie beginnt immer mit einer Nummer und gehört zu einer der folgenden sechs Response-Klassen: Provisional: Jeder Response dieser Klasse beginnt mit einer Nummer 1xx. Mit ihr wird der Absender eines Request darüber informiert, dass der von ihm abgeschickte Request weiter bearbeitet wird. Die Responses dieser Klasse sind z.B.: − 100 Trying – s. Abb. 7.1-8 − 180 Ringing – s. Abb. 7.1-8 − 181 Call Is Being Forwarded – s. Abb. 7.2-5 und -6 Success: Die Responses dieser Klasse beginnen mit 2xx. Mit ihnen wird dem Absender eines Request mitgeteilt, dass der von ihm abgeschickte Request erfolgreich empfangen bzw. akzeptiert wurde. Diese Klasse enthält die beiden folgenden Responses: − 200 OK – s. Abb. 7.1-8 − 202 Accepted – s. Abb. 7.7-4, -7 und -8
www.wiwobooks.com
Redirection: Die Responses dieser Klasse beginnen mit 3xx und signalisieren dem Absender eines Request, dass weitere Aktionen bei der Bearbeitung und Weiterleitung des Request nötig sind. Zu dieser Klasse gehören u.a. folgende Responses: − 301 Moved Permanently − 302 Moved Temporarily – s. Abb. 7.2-2 und -5 − 305 Use Proxy − 380 Alternative Service
Client Error: Diese Klasse enthält über 40 Responses, die mit 4xx beginnen. Mit einem Response dieser Klasse wird dem Absender eines Request mitgeteilt, dass der Request eine falsche Syntax enthält oder vom SIPServer nicht ausgeführt werden kann. Die Responses dieser Klasse sind u.a.: − 400 − 401 − 406 − 486
Bad Request Unauthorized Not Acceptable Busy Here – s. Abb. 7.7-6 und -9
Server Error: Die Responses dieser Klasse beginnen mit 5xx. Mit einem Response dieser Klasse signalisiert man dem Absender eines Request, dass
7.3 SIP-Nachrichten – ihre Bedeutung und Struktur
der SIP-Server nicht in der Lage ist, den Request auszuführen. Beispiele für Responses dieser Klasse: − 500 Internal Server Error − 501 Not Implemented − 505 SIP Version not supported
Global Failure: Die Responses dieser Klasse beginnen mit 6xx und signalisieren, dass der Request auf keinem SIP-Server ausgeführt werden konnte. Die Responses dieser Klasse sind u.a.: − 600 Busy Everywhere − 604 Does Not Exist Anywhere − 606 Not Acceptable
Eine vollständige Auflistung von Responses aller Klassen findet man unter der Adresse http://www.iana.org/assignments/sip-parameters bzw. unter http://www.tech-invite.com/Ti-sip-abnf.html
7.3.3 Aufbau von SIP-Nachrichten SIP-Nachrichten – d.h. sowohl Requests als auch Responses – sind textbasiert und zeilenweise aufgebaut. Die Text-Codierung erfolgt nach den in RFC 3629 dargestellten Prinzipien. Jede SIP-Nachricht setzt sich aus einer Start-Zeile, einem Message Header und einem Message Body zusammen – s. Abb. 7.3-1 14 und -2. Der Message Body ist optional. In der Startzeile ist der Name (Typ) der Nachricht enthalten, woran man erkennt, ob es sich um einen Request oder um einen Response handelt.
www.wiwobooks.com
Struktur von SIP-Requests SIP-Requests haben die in Abbildung 7.3-1 dargestellte Struktur. M e th o d R e q u e s t-U R I S IP -V e rs io n H e a d e r-F e ld 1 ... M e ssa g e H e a d e r H e a d e r-F e ld n L e e rz e ile [M e ssa g e B o d y ]
R e q u e s t-L in e a ls S ta rt-Z e ile
Abb. 7.3-1: Allgemeine Struktur von SIP-Requests
14
Ausgenommen der Request INVITE, in dem als Body die Beschreibung der initiierten Session nach dem Protokoll SDP enthalten ist.
307
308 Angaben in Request-Line
7
VoIP mit SIP
Jeder SIP-Request beginnt mit einer Request-Line als Start-Zeile, in der folgende Angaben enthalten sind: Method repräsentiert den Request-Typ; wie z.B. INVITE, BYE, ACK, OPTIONS, REFER, UPDATE. Request-URI stellt entweder SIP-URI oder SIPS-URI dar – siehe Abschnitt 7.1.3. Hier wird die Ziel-SIP-Adresse angegeben. SIP-Version mit der Angabe SIP/2.0. Diese drei Angaben sind jeweils mit Leerzeichen voneinander getrennt. Beispiel: Die Startzeile des Request INVITE mit dem Ziel, eine Session zum IP-Telefon von Bob mit dem SIP-URI sip:[email protected] zu initiieren, hat folgende Form: INVITE sip:[email protected] SIP/2.0
Hier stellt INVITE die Methode, sip:[email protected] den SIP-URI als Request-URI und SIP/2.0 die SIP-Version dar.
Message Header
Nach der Request-Line werden unterschiedliche Angaben als sog. HeaderFelder (Header Fields) gemacht, die den Message Header bilden. Jedes Header-Feld hat seinen Namen (header-name) – wie z.B. Via, Route, Call-ID, From, To –, mit dem auf seine Funktion bzw. Bedeutung hingewiesen wird, und danach folgt die Angabe von Header-Feld-Werten (field-value, kurz f-v). Im Allgemeinen kann ein Header-Felder mit mehreren Werten wie folgt dargestellt werden:
www.wiwobooks.com
field-name: f-v 1; f-v 2; ... f-v i
Falls nötig, kann sich ein Header-Feld über mehrere Zeilen erstrecken. Nach dem Header kann der Message Body folgen, der optional ist. Dies symbolisieren die Klammern [...]. Der Message Header wird vom Message Body mit einer Leerzeile getrennt. Beispiel:
Der Request INVITE, den das IP-Telefon von Alice mit SIP-URI sip:[email protected] in Abbildung 7.1-8 an das IP-Telefon von Bob mit SIP-URI sip:[email protected] abgeschickt hat, kann folgende Header-Felder enthalten: Via: SIP/2.0/UDP pc3.abc.de;branch=z8hD4bK556asdhds Max-Forwards: 20 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1748301874 Call-ID: [email protected] CSeq: 284164 INVITE
Message Body
Der Message Body stellt eine Art Nutzlast einer SIP-Nachricht – sowohl von Requests als auch von Responses – dar. In diesem Nachrichtenteil können zwei verschiedene Informationsarten übermittelt werden, nämlich: Informationen, die eine Session betreffen
7.3 SIP-Nachrichten – ihre Bedeutung und Struktur
309
Der Aufbau jeder Session wird mit dem Request INVITE initiiert, daher werden in INVITE als Message Body die Besonderheiten der einzurichtenden Session nach dem Protokoll SDP (Session Description Protocol) spezifiziert, um u.a. die Kompatibilität zwischen den IP-Telefonen zu überprüfen. In einem Request UPDATE als Body können beispielsweise einige Angaben gemacht werden, um die bestehende Session entsprechend zu modifizieren – d.h. ihre Eigenschaften zu ändern. Informationen, die keine Session betreffen Das Protokoll SIP wird auch für die Bereitstellung von Instant-Messagingund Präsenzdiensten verwendet. In diesem Fall können beispielsweise in den Requests MESSAGE, NOTIFY oder PUBLISH Informationen – im S/MIME-Format bzw. als XML-Dateien – über bestimmte Objekte übermittelt werden, die sich nicht auf die bestehende Session beziehen. Struktur von SIP-Responses SIP-Responses werden ähnlich wie SIP-Requests zeilenweise aufgebaut und haben die in Abbildung 7.3-2 dargestellte Struktur.
www.wiwobooks.com
S IP -V e rs io n S ta tu s -C o d e R e a s o n -P h ra s e H e a d e r-F e ld 1 ... M e ssa g e H e a d e r H e a d e r-F e ld n L e e rz e ile [M e ssa g e B o d y ]
S ta tu s -L in e a ls S ta rt-Z e ile
Abb. 7.3-2: Allgemeine Struktur von SIP-Responses
Die Startzeile in Responses wird als Status-Line bezeichnet. Der Status- Angaben in Code in der Status-Line beginnt mit der Angabe von SIP-Version – als Start-Zeile SIP/2.0 –, danach kommt eine dreistellige Zahl als Status-Code, mit der die Bedeutung des Response angegeben wird, und abschließend die Bezeichnung des Response im Klartext als Reason-Phrase. Die erste Ziffer im Status-Code gibt an, um welche Response-Klasse es sich handelt. Beispiel: Die Startzeile des Response mit dem Status-Code 180 hat folgende Form: SIP/2.0 180 Ringing
Hier ist die SIP-Version SIP/2.0, der Status-Code 180 und die Reason-Phrase Ringing
Die Steuerungsangaben im Header von Requests und Responses erfolgen zei- Headerlenweise in Form festgelegter Header-Felder. Jedes Header-Feld (Header Felder Field) hat folgende Struktur: Field-Name: Field-Value
310
7
VoIP mit SIP
Die Bedeutung eines Responses wie z.B. von 100 Trying, 180 Ringing und 200 OK wurde bereits bei der Darstellung des typischen SIP-Verlaufs näher erläutert (in Abb. 7.1-8). Wichtige Header-Felder SIP ist möglicherweise das wichtigste Protokoll für die Unterstützung aller Formen multimedialer Kommunikation. Daher musste SIP an eine breite Palette von Anwendungen angepasst werden, was u.a. durch die Spezifikation immer neuer Header-Felder erreicht wurde. Dadurch enthält die Liste von bei IANA registrierten Header-Feldern im Mai 2009 bereits über 100 Header15 Felder; zu den wichtigsten zählen: Allow – Liste von unterstützten SIP-Requests: Der Absender eines SIPRequests – z.B. INVITE, OPTIONS – kann in diesem Header-Feld die von
ihm unterstützten Requests auflisten: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE Call-ID – Identifikation (ID) des Anrufs (der Session): Diese Identifika-
tion stellt eine Zufallszahl dar. Sie kann sich auch aus einer Zufallszahl (a74b4c76e55710) und aus dem vollständigen Hostnamen (mond.abc.de) des den Anruf initiierenden IP-Telefons wie folgt zusammensetzen:
www.wiwobooks.com
Call-ID: [email protected]
Contact – Die Bedeutung dieses Header-Feldes ist von der SIP-Nachricht,
in der es enthalten ist, abhängig. Hierbei kommt sowohl Request als auch Response in Frage. Mit dem Header-Feld Contact im Response 302 Moved Temporarily kann mitgeteilt werden, in welche DNS-Domain der Angerufene umgezogen ist bzw. auch welchen Rechner er dort als IPTelefon nutzt (s. Abb. 7.2-2). Enthält eine SIP-Nachricht das Header-Feld Contact, gibt es in diesem Feld an, an welche Adresse die Antwort auf diese SIP-Nachricht gesendet werden soll (s. Abb. 7.6-1 und 11.3-2). Beispiel: Soll eine Nachricht an den Rechner pc45 mit der IP-Adresse a.b.c.d – als IPTelefon von Bob – in der Domain prs.de gesendet werden, kann wie folgt angegeben werden: Contact: <sip:[email protected]>
oder Contact: <sip:[email protected]>
CSeq (Command Sequence) – Sequenznummer eines Request: Dieses Header-Feld „dient“ zur Nummerierung von Requests eines Typs, die von einem SIP-Client (z.B. einem IP-Telefon) bzw. einem SIP-Proxy abgeschickt wurden, und setzt sich aus der Sequenznummer und dem Request15
Unter http://www.tech-invite.com/Ti-sip-abnf.html können Sie die vollständige Auflistung von Header-Feldern abrufen.
7.3 SIP-Nachrichten – ihre Bedeutung und Struktur
311
Namen zusammen. CSeq in einem Response gibt an, auf welchen Request sich der Response bezieht. Beispiel: Ein Request INVITE hat z.B. das Header-Feld CSeq: 1435 INVITE
Ein Response auf diesen INVITE muss somit auch CSeq: 1435 INVITE enthalten.
Weil mit dem Absenden eines Request INVITE ein Signalisierungsvorgang – auch SIP-Transaktion genannt – beginnt, kann man CSeq auch als fortlaufende Transaktionsnummer betrachten. Ein IP-Telefon oder ein SIP-Proxy kann während einer SIP-Transaktion mehrere Requests gleicher Art senden. CSeq erlaubt daher, diese voneinander zu unterscheiden. Jeden zweiten Request INVITE – und eventuell auch die weiteren – inner- re-INVITE halb eines Signalisierungsvorgangs bezeichnet man als re-INVITE. Mit einem re-INVITE können einige Parameter der Session neu gesetzt werden. From – Ausgangspunkt einer Session: In diesem Header-Feld wird der Aus-
gangspunkt einer Session – in der Regel der Anrufende – angegeben. Dieses Header-Feld hat folgende Struktur: From: [display-name] <SIP URI>[; tag=random string]
www.wiwobooks.com
Die Teile in [..] sind optional.
Beispiel: Hat das IP-Telefon von Alice mit dem SIP-URI sip:[email protected] die Session initiiert, so kann der Ausgangspunkt der Session wie folgt angegeben werden: From: Alice <sip:[email protected]>;tag=1928174
Der Anrufende Alice kann dem Angerufenen angezeigt werden. Die Angabe tag=1928174 verwendet man, um die Dialog-Identifikation zu erzeugen – siehe Abschnitt 7.1.9.
Will man dem Angerufenen die Identität des Anrufenden nicht übermitteln, muss man Anonymous als display-name angeben. Beispiel: From: Anonymous <sip:[email protected]>;tag=fyg8
Ein Benutzer von VoIP mit SIP kann – außer seines SIP-URI – auch eine normale Rufnummer für die Kommunikation mit klassischen Telefonen am ISDN/PSTN nutzen. Das Header-Feld From in der Kombination mit PAsserted-Identity – siehe RFC 3325 – ermöglicht es, eine klassische Rufnummer an ein Gateway zum ISDN/PSTN zu übergeben. Beispiel: Hat der Benutzer Bob außer seines SIP-URI sip:[email protected] die Rufnummer +49924532, kann das Header-Feld From in einem von seinem IP-Telefon abgeschickten Request INVITE folgende Form haben: From: Bob <sip:[email protected]>;tag=fygdsf8 P-Asserted-Identity:<+49924532>
Max-Forwards – Maximale Anzahl von Proxies unterwegs: Dieses Header-Feld hat eine besondere Bedeutung im Request INVITE. Im Max-
312
7
VoIP mit SIP
Forwards wird die maximale Anzahl von Proxy-Servern angegeben, die der zwischen zwei IP-Telefonen übermittelte Request INVITE durchlaufen 16
darf, wie z.B: Max-Forwards: 20 Via – Angabe des Absenders: Im Header-Feld Via trägt man zusätzlich
Response Routing
das Transportprotokoll und die Information über den Absender der SIPNachricht ein – das ist vor allem in Requests INVITE von großer Bedeu17 tung. Falls ein Request INVITE über mehrere Proxy-Server übermittelt wurde, enthält er am Ziel mehrere Via-Felder in umgekehrter Reihenfolge als ursprünglich von den einzelnen Proxy-Servern abgeschickt. So wird die Route von INVITE aufgezeichnet. Alle Felder Via aus INVITE werden im Response übernommen, um die gleiche Route zu übermitteln. Dieses sog. SIP Response Routing stellt Abbildung 7.8-1 dar. Route – Angabe der Route: In diesem Header-Feld wird die Beschrei-
SIP Request Routing
bung der Route für einen Request – in Form einer Liste vollständiger Namen von Proxy-Servern – angegeben, wie z.B.: Route: <sip: pxy.abc.de>;tag=1928174
Somit wird der Request über die im Voraus festgelegten Proxy-Server übermittelt. Man bezeichnet dies als SIP Request Routing (s. Abb. 7.8-2).
www.wiwobooks.com
Record-Route: Ein Proxy-Server, der z.B. eine Firewall-Funktion für VoIP enthält, erzeugt im empfangenen Request INVITE das Feld RecordRoute, um seinen Namen anzugeben und darauf zu verweisen, dass der weitere Verlauf der Signalisierung über ihn erfolgen muss. Ein INVITE am Ziel kann mehrere Felder Record-Route enthalten. Die Angaben aus diesen Feldern werden im Feld Route eingetragen und bestimmen die Route
der Signalisierung (s. Abb. 7.8-2). To – Zielpunkt der Session: In diesem Header-Feld wird der Zielpunkt
der Session – in der Regel der Angerufene – angegeben. Dieses Header-Feld hat die gleiche Struktur wie das Header-Feld From, nämlich To: [display-name] <SIP URI> [; tag=random string]
Die Teile in [..] sind optional. Die Angabe tag wird verwendet, um die Dialog-Identifikation (Dialog-ID) – also de facto einer Session – zu erzeugen (s. Abschnitt 7.1.9). 16
Die Angabe Max-Forwards hat eine ähnliche Bedeutung wie der Parameter TTL (Time To Live) im IP-Header – siehe Abbildung 7.1-9.
17
Auf die Bedeutung des Header-Felds Via wurde bereits in Abschnitt 7.1.9 bei der Beschreibung der in Abbildung 7.1-9 gezeigten Requests INVITE eingegangen.
7.4 Beschreibung von Sessions mit SDP
313
Beispiel: Ist der Angerufene Bob mit dem SIP-URI sip:[email protected] der Zielpunkt der Session, kann dies wie folgt angegeben werden: To: Bob <sip:[email protected] >;tag=2345244
Jeder Request muss folgende Pflicht-Header-Felder enthalten (s. Abb. 7.1-10): Via, Max-Forwards, From, To, Call-ID und CSeq
PflichtHeaderFelder
Beispiel: Falls Alice mit SIP-URI sip:[email protected] eine Session zu Bob mit SIP-URI sip:[email protected] initiiert, kann der Request INVITE folgende Header-Felder enthalten: INVITE sip:[email protected] SIP/2.0
Startzeile
Via: SIP/2.0/UDP pc3.abc.de;branch=z9hG4bK6ashnds
Protokoll, Info über
den Absender und Transaktions-ID; Max-Forwards: 70 max. Anzahl von Proxies unterwegs From: Alice <sip:[email protected]>;tag=1748301874 Benutzer – Initiator der Session To: Bob <sip:[email protected]> Benutzer – Ziel der Session Call-ID: [email protected]
Identifikation des Anrufs
CSeq: 284164 INVITE
Sequenznummer von INVITE
Contact: <sip:[email protected]>
Kontakt zum Initiator
Content-Type: application/SDP Content-Length: 152
Typ des Body-Inhalts Länge des Body-Inhalts
7.4
www.wiwobooks.com
Beschreibung von Sessions mit SDP
Um die Eigenschaften einer Session – als VoIP-Verbindung – zwischen kom- Was ermögmunizierenden Rechnern vereinbaren zu können, ist ein Protokoll nötig, nach licht SDP? dem sich die beiden Rechner auf die Modalitäten der Kommunikation verständigen können. SDP (Session Description Protocol) ist ein solches Protokoll. Mit Hilfe von SDP ist der Initiator der Kommunikation in der Lage, seinem Kommunikationspartner die Eigenschaften der von ihm gewünschten Session genau zu spezifizieren. SDP ist also ein Protokoll für die formale Beschreibung von Sessions. Mit SDP können verschiedene Arten von audiovisuellen Sessions – also sowohl Punkt-zu-Punkt- als auch Multipoint-Sessions – einheitlich und formal beschrieben werden. Die erste Version von SDP wurde im April 1998 in RFC 2327 veröffentlicht. Spezifikation Bereits im Juni 2002 wurde die erste SDP-Version durch die Spezifikation in von SDP RFC 3266 ergänzt. Da SDP ein Bestandteil von SIP ist, hat die SIP-Weiterentwicklung auch die Entwicklung von SDP vorangetrieben, sodass bereits fast 50 RFCs diversen Erweiterungen von SDP gewidmet sind. Im Juli 2006 wurde die SDP-Spezifikation in RFC 3266 durch die neue Spezifikation in RFC 4566 18 abgelöst. 18
Unter http://www.tech-invite.com/Ti-sdp-abnf.html findet man eine kompakte und formale Darstellung von SDP.
314
7
VoIP mit SIP
7.4.1 Typischer Einsatz von SDP Abbildung 7.4-1 veranschaulicht den Einsatz des SDP beim Aufbau einer Session nach SIP. Hier können die beiden Rechner nicht nur als IP-Telefone dienen, sondern auch als beliebige multimediale Endeinrichtungen (wie z.B. IPBildtelefone).
N a c h ric h te n h e a d e r B o d y : S e s s io n B e s c h r e ib u n g n a c h S D P
R e c h n e r A
. . .
In te rn e t (IP -N e tz ) IN V IT E 1 8 0 R in g in g b z w . 2 0 0 O K
R e c h n e r B S o ft-IP -T e le fo n
. . .
...
S o ft-IP -T e le fo n
...
O ffe r
A n sw e r
...
N a c h ric h te n h e a d e r B o d y : S e s s io n B e s c h r e ib u n g n a c h S D P
Abb. 7.4-1: Typischer SDP-Einsatz – hier beim Initiieren einer neuen Session mit SIP
www.wiwobooks.com
In dem hier gezeigten Beispiel initiiert Rechner A durch das Absenden von INVITE an Rechner B eine Session für VoIP. Dieser SIP-Request (siehe Abb. 7.3-1) setzt sich im Allgemeinen aus zwei Teilen zusammen. Der erste Teil stellt einen Header in Form mehrerer Zeilen als Header-Felder dar, der nach dem Protokoll SIP aufgebaut wird. Der zweite Teil – ebenso in Form von mehreren Zeilen – wird nach dem Protokoll SDP strukturiert und als Message-Body (kurz Body) bezeichnet. Im Body werden die Eigenschaften der gewünschten 19 Session formal nach SDP beschrieben. Kann Rechner B die ankommende Verbindung annehmen, d.h. kann er die von Rechner A geforderten Besonderheiten der Session seinerseits gewährleisten, antwortet er dem Initiator der Session – also Rechner A – mit einem SIPResponse 180 Ringing bzw. 200 OK. Im Body dieses Response beschreibt Rechner B ebenfalls die einzurichtende Session. Er teilt dem Initiator der Session mit, welche seiner Anforderungen, die sich auf die Besonderheiten der Session beziehen, er erfüllen, also akzeptieren kann. OfferAnswerModell
Wie Abbildung 7.4-1 zeigt, übermittelt Rechner A seinem Kommunikationspartner Rechner B die Offerte(Offer), eine Session mit bestimmten Eigenschaften aufzubauen. Nachdem Rechner B überprüft hat, ob er die von Rechner A gewünschten Eigenschaften der Session erfüllen kann, sendet er dem Rechner A 19
In einigen SIP-Requests – z.B. in SUBSCRIBE, NOTIFY – enthält der Body-Teil oft im XMLFormat andere Angaben als Beschreibung einer Session.
7.4 Beschreibung von Sessions mit SDP
eine Antwort (Answer), um ihm mitzuteilen, auf welche Art und Weise er seine Anforderungen erfüllen kann. Die Abstimmung von Eigenschaften einer Session verläuft also nach dem Modell Offerte Antwort (Offer Answer). In diesem Zusammenhang spricht man vom Offer-Answer-Modell des Protokolls SDP – siehe RFC 3264. Abbildung 7.4-1 zeigt, wie sich die beiden Kommunikationspartner beim Aufbau einer multimedialen Session verhalten. Noch ist aber die Frage offen: Welche Angaben, teilen sich die beiden Kommunikationspartner gegenseitig mit, um die Eigenschaften der initiierten Session zu spezifizieren? Abbildung 7.4-2 gibt die Antwort darauf.
n g r, S M b e i
a b e n e s s io e d ia A , M
z u r S e s s io n : n - N a m e n , - I D , ... 1 : e d ia - T y p , - F o r m a t, ...
n
In te rn e t (IP -N e tz )
R e c h n e r A A llg e m e in e A In itia to A n g a b e n z u m R T P -P o rt ... A n g a b e n z u m R T P -P o rt
1
...
M C M C
R e c h n e r A m u ss d e n A u fb a u e in e r m u ltim e d ia le n S e s s io n z u m R e c h n e r B in itiie re n .
R e c h n e r B
IN V IT E O ffe r
www.wiwobooks.com
M e d ia n : b e i A , M e d ia - T y p , - F o r m a t, ...
1 8 0 R in g in g b z w .2 0 0 O K
A sw e r
Z u je d e m M e d ia - O b e s e m p fa n g - W e n n ja : A u f w Im w
a n g e n w e lc e lc h
e b e e rd h e m e m
n : e n k a n n ? R T P -P o rt? , F o r m a t? , ...
Abb. 7.4-2: Austausch von Angaben für die Beschreibung einer multimedialen Session MC: Media-Channel (Medienkanal)
Wie hier zu sehen ist, muss der Rechner A den Aufbau einer multimedialen Session – einer mit mehreren Medienkanälen MC1, ..., MCn also – zum Rechner B initiieren. Hierfür sendet er an den Rechner B den SIP-Request INVITE, in dessen Body er als Offer die Eigenschaften der von ihm initiierten Session beschreibt. Für die Beschreibung einer Session werden u.a. folgende Angaben gemacht: Initiator der Session Identifikation der Session: Jede Session muss eine eindeutige Identifikation erhalten, um sie von den anderen Sessions unterscheiden zu können. Name der Session: Einer Session kann eine Bezeichnung zugeordnet werden, um damit auf das Ziel der Session zu verweisen. Die wichtigsten Angaben der Offer für die Beschreibung jedes Media – und somit jedes Medienkanals:
315
316
7
VoIP mit SIP
RTP-Port – als Endpunkt des Medienkanals beim Initiator der Session (s. Abb. 5.2-1). Falls der RTP-Port die Nummer x (x ist eine gerade Zahl) hat und der RTCP-Port anders als x+1 sein soll, muss man dies dem Rechner B mitteilen. Media-Typ – gibt an, um welches Media es sich handelt und wie es codiert (in welchem Format also) übermittelt wird. Da jedem bei IANA registrier20 ten Format eines Media eine eindeutige Nummer – als seine Identifikation – zugeordnet wurde, wird als Media-Typ nur die entsprechende Nummer angegeben, die der RTP-Header als Angabe PT übermittelt. Die Informationen, die man für die Beschreibung jedes Media angeben kann, besprechen wir in Punkt 7.4.5 ausführlicher (siehe z.B. Abbildung 7.4-5). Modifikation einer Session
Mit SDP ist es auch möglich, eine bestehende Session zu modifizieren, ohne sie unterbrechen zu müssen. Beispiele hierfür sind u.a.: Hinzufügen, Entfernen oder Ändern von Parametern eines Medienkanals, Ändern von RTP- und RTCP-Ports, etc.
re-INVITE
Beim Aufbau einer Session mit SIP wird eine SDP-Offer im SIP-Request INVITE als Body übermittelt (s. Abb. 7.4-1). Um eine bestehende Session zu modifizieren und hierfür eine neue SDP-Offer zu übermitteln, kann erneut der SIP-Request INVITE gesendet werden, der nun entsprechend identifiziert werden muss, damit er von bereits vorher gesendeten Requests INVITE unterschieden werden kann. Dieser erneute Request INVITE wird oft als re21 INVITE bezeichnet. SDP-Offer kann ebenso während einer bestehenden Session in dem SIP-Request UPDATE übermittelt werden. Die Requests re-INVITE bzw. UPDATE werden in der Regel von der Gegenseite mit dem SIP-Response 200 OK bestätigt, in dem eine SDP-Answer enthalten sein kann.
www.wiwobooks.com
7.4.2 Bestandteile der Beschreibung einer Session Kategorien von Angaben
Für die Beschreibung einer Session müssen nicht nur Angaben über einzelne Medienkanäle und über die in diesen Kanälen übermittelten Medienströme – also medienspezifische Angaben – gemacht werden, sondern auch allgemeine 20
Ein Auflistung aller bei IANA registrierten Formate verschiedener Medien findet man unter http://www.iana.org/assignments/sdp-parameters
21
Um INVITE und jeden weiteren re-INVITE der gleichen SIP-Transaktion zuordnen zu können, müssen sie alle die gleiche Dialog-ID – d.h. die gleichen Angaben: Call-ID, tag im Feld From und tag im Feld To (in Response) – enthalten (s. Seite 290 sowie Abbildungen 7.1-10 und -11). Zur Unterscheidung eines INVITE von einem re-INVITE bzw. zwischen mehreren re-INVITE dient die Angabe im Feld Cseq.
317
7.4 Beschreibung von Sessions mit SDP
Angaben über die Session wie z.B. über ihren Initiator, ihre Identifikation, ihr Ziel – also einige sessionspezifische Angaben. Deswegen sind medienspezifische Angaben als Media-Level-Angaben und sessionspezifische als Session-Level-Angaben erforderlich. Wie Abbildung 7.4-3 zeigt, stellen die eben genannten Kategorien der Angaben die Hauptbestandteile der Beschreibung jeder Session dar.
R e c h n e r A
M u ltim e d ia -S e s s io n M C 1
M C 2
A u d io
R e c h n e r B
V id e o
S e s s io n -L e v e l-A n g a b e n M e d ia -L e v e lA n g a b e n
S p e z ifik a tio n v o n M C 1 S p e z ifik a tio n v o n M C 2
M C : M e d ia -C h a n n e l (M e d ie n k a n a l)
Abb. 7.4-3: Hauptbestandteile der Beschreibung jeder multimedialen Session – hier als Beispiel einer Session mit zwei Medienkanälen
www.wiwobooks.com
Zu den Session-Level-Angaben gehören u.a.:
Version des Protokolls SDP, Name der Session und ihr Initiator;
SessionLevelAngaben
optional weitere Informationen (E-Mail-Adresse und/oder Telefonnummer) über den Initiator der Session; zeitspezifische Angaben: Start- und Endzeiten, zu denen die Session stattfindet, und die Abstände für eventuelle periodische Wiederholungen. Als Media-Level-Angaben zur Beschreibung eines Medienkanals und der über MediaLevelihn übermittelten Echtzeit-Medien gehören u.a. folgende Angaben: Angaben
Typ der übertragenen Medien (Video, Audio, ...); verwendete Protokolle (UDP, ...) und die Nummern des RTP Ports;
22
wie die einzelnen Medien codiert werden. Die Beschreibung jeder Session setzt sich aus einer Anzahl von Textzeilen zusammen, die im Allgemeinen wie folgt dargestellt werden können: =
Hierbei verwendet man folgende Notation: 22
Falls dem RTP-Port die Nummer x zugeordnet ist, hat der RTCP-Port in Allgemeinen die Nummer x+1 (was aber nicht die Regel sein muss).
318
7
VoIP mit SIP
wird als Buchstabe (wie z.B. v, o, k ) dargestellt und definiert den
Typ der Angabe in der betreffenden Zeile; repräsentiert den Inhalt der Angabe. Typen von Zeilen auf SessionLevel
Die Beschreibung einer Session auf dem Session-Level kann sich aus den in der Tabelle 7.4-1 aufgelisteten Typen von Zeilen zusammensetzen. v=
protocol version
o=
origin/creator and session identifier
s=
session name
i=* session information u=* URI of description e=* email address p=* phone number c= connection information1) b=* zero or more bandwidth information lines
Tab. 7.4-1:
z=*
time zone adjustments
k=*
encryption key
a=*
zero or more session attribute lines
Auflistung von Zeilen für die Angaben auf dem Session-Level
www.wiwobooks.com Die mit dem Symbol * markierten Zeilen sind optional; falls diese Angaben auf dem Media-Level erfolgen.
Zeitspezifische Angaben
1)
nicht nötig,
Eine Zeitbeschreibung kann folgende Typen von Zeilen enthalten: t= time the session is active r= zero or more repeat times (diese Zeile ist optional)
Auf die zeitspezifischen Angaben gehen wir im Weiteren noch näher ein. Typen von Zeilen auf Media-Level
Die Media-Level-Angaben können mit den in der Tabelle 7.4-2 gezeigten Typen von Zeilen gemacht werden. m= media name and transport address i=* media title c= connection information1) b=* zero or more bandwidth information lines k=* encryption key a=* zero or more media attribute lines
Tab.7.4-2:
Auflistung von Zeilen für Media-Level-Angaben 1)
Einige Zeilen auf Sessionund MediaLevel
nicht nötig, falls diese Angaben auf dem Session-Level gemacht werden
Es ist hervorzuheben, dass die Zeilen c, b, k und a sowohl auf dem Session- als auch auf dem Media-Level vorkommen können. Im Allgemeinen gilt folgendes Prinzip: Falls eine Angabe auf dem Session-Level erfolgt, gilt diese für alle Medien, also auch auf dem Media-Level. Daher ist diese Angabe bei der Be-
319
7.4 Beschreibung von Sessions mit SDP
schreibung einzelner Medien nicht mehr nötig. Wenn alle Medien eine und dieselbe Besonderheit besitzen, kann dies auf dem Session-Level angegeben werden. Die Beschreibung jeder Session beginnt immer mit der Zeile
v-Zeile
v= 0
d.h. mit der Angabe der SDP-Version. Beispiel: Abbildung 7.4-4 zeigt die Beschreibung einer Session mit einem Sprachkanal – d.h. mit einem Medienkanal. Diese Beschreibung setzt sich aus drei Teilen zusammen: • Spezifikation der Session: v-, o-, s- und c-Zeile • Zeitbeschreibung: t-Zeile • Medienbeschreibung: m- und a-Zeilen
S e s s io n L e v e l
v = 0
u sern a m e
o = a ja h n
2 8 9 0 8 4 6 5 2 1 2 8 9 0 8 4 6 8 4 3 I N I P 4 1 2 6 .1 7 .5 4 .6
s = H e rz lic h e G ru e s s e c = IN
Z e ita n g a b e
t= 0 0
n etty p e
n etty p e
a d d rty p e Q u e ll-IP -A d r.
a d d rty p e
Z ie l-IP -A d r.
I P 4 1 2 8 .5 7 .1 6 .2
S e s s io n b e g in n t d ire k t n a c h d e m A u fb a u u n d k a n n je d e rz e it b e e n d e t w e rd e n .
www.wiwobooks.com M e d ia
P o rt
m = a u d io 3 4 5 6 R T P /A V P M e d ia L e v e l
s e s s -v e r s io n
s e s s -id
a = rtp m a p : 0 P C M
/ 8 0 0 0
a = rtp m a p : 2 G 7 2 1 / 8 0 0 0
P ro to k o ll 0 2
P a y lo a d -T y p e n
P a y lo a d -T y p e n A b ta stra ten C o d ie ru n g sv e rfa h re n
Abb. 7.4-4: Spezifikation einer Session mit einem Sprachkanal addr: addresse, sess: session, id: identification
Die o-Zeile enthält folgende Angaben: User-Name (Initiator der Session), Session-ID, Session-Version, Netztyp (IN = Internet), Typ der Quell-IP-Adresse (IP4) und Quell-IP-Adresse. Die c-Zeile enthält u.a. die Ziel-IP-Adresse. In der m-Zeile wird angegeben: • Media-Typ = Audio • RTP-Port, über den das Audio empfangen wird • Protokoll RTP/AVP (Real-time Transport Protocol / Audio Video Profiles) • Payload-Typen, d.h. die Identifikationen von Audiocodierungsverfahren, die der Rechner als Initiator dieser Session zu unterstützen in der Lage ist. Hier gibt man daher an, in welchem Format er das Audio empfangen kann.
Wie in Abbildung 7.4-4 ersichtlich ist, können die Medien mittels a-Zeilen (Attribut-Zeilen) näher erläutert werden. In a-Zeilen können die in der m-Zeile aufgelisteten Payload-Typen (als Codierungsverfahren) des Protokolls RTP beschrieben werden.
320
7
VoIP mit SIP
7.4.3 Beschreibung auf dem Session-Level Die Typen von Zeilen, in denen Angaben auf dem Session-Level gemacht werden können, wurden in der Tabelle 7.4-1 aufgelistet. Bevor auf die Bedeutung der einzelnen Typen von Zeilen eingegangen wird, soll nun die Beschreibung einer Session betrachtet werden, um die Struktur der einzelnen Typen von Zeilen näher zu veranschaulichen. Beispiel: Die Beschreibung einer Session kann beispielsweise sein: v=0 o=aschneider 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP-Schulung i= Eine SDP-Schulung am 31.10.2010 u=http://www.abc.xyz.de/Schneider/sdp.html [email protected] (Alex Schneider) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31
Diese Beschreibung setzt sich aus drei Teilen zusammen:
www.wiwobooks.com
•
Session-Level-Angaben:
v-, o-, s-, i-, u-, e- und c-Zeile
•
Zeitbeschreibung:
t-Zeile
•
Media-Level-Angaben:
m-Zeilen
In diesem Beispiel handelt es sich um eine Multimedia-Session, in der zwei Medien (Audio und Video) übermittelt werden.
Die Bedeutung der Zeilen v, o, s, i, u, e, c und b mit den Session-LevelAngaben sehen wir uns nun detaillierter an. o-Zeile
Die o-Zeile mit dem Initiator und der Identifikation der Session hat nach RFC 4566 folgende Struktur: o=<username> <sess-id> <sess-version> Die einzelnen Angaben haben hierbei folgende Bedeutung: <username> – Login-Name vom Benutzer des Rechners (Hosts), der die Session initiiert,
falls dieser Rechner das Konzept „Benutzer-ID“ unterstützt, sonst „–“. <sess-id> – Eindeutige Session-Identifikation; es wird empfohlen, hier den Zeitstempel
nach dem Protokoll NTP (Network Time Protocol) zu verwenden. <sess-version> – Eindeutige Versionsnummer für die Session-Beschreibung; Sie kann
als Identifikation der Ankündigung einer Session angesehen werden. Es wird eindeutigkeitshalber empfohlen, hier den Zeitstempel nach NTP zu verwenden. – Typ des Netzes: IN = Internet – Typ der IP-Adresse: IPv4 (IP4) oder IPv6 (IP6)
321
7.4 Beschreibung von Sessions mit SDP – IP-Adresse des Rechners, der die Session initiiert hat.
Beispiel: Die o-Zeile o=aschneider 2890844526 2890842807 IN IP4 126.16.64.4
beschreibt Folgendes: der Initiator der Session ist der Benutzer aschneider, die Session hat die ID = 2890844526, die Ankündigung hat die ID =2890842807, die Session erfolgt über das Internet (IN), der Rechner als Initiator der Session hat die IPv4-Adresse (IP4), die IPv4-Adresse des Initiator-Rechners ist 126.16.64.4.
Die s-Zeile – mit dem Namen der Session – kann nur einmal vorkommen und s-Zeile hat die Struktur s= <session name> Beispiel: Der Name der Session – SDP-Schulung – kann folgendermaßen angegeben werden: s=SDP-Schulung
Die i-Zeile ist optional und ermöglicht es, das Ziel bzw. Thema der Session i-Zeile (Konferenz) anzugeben. Sie kann nur einmal vorkommen und hat die Struktur i= <session description> Beispiel: Das Thema der Session – SDP-Schulung am 31.10.2010 – kann wie folgt angegeben werden: i= SDP-Schulung am 31.10.2010
www.wiwobooks.com
Die u-Zeile ist optional und ermöglicht es, eine Web-Adresse als URI an- u-Zeile zugeben, wo die betreffende Session (bzw. ihr Ziel) näher erläutert wird. Sie hat folgende Struktur: u= Beispiel: u=http://www.abc.xyz.de/Schneider/sdp.html
Die e-Zeile
e-Zeile
e=<email-address>
ist optional und ermöglicht es, die E-Mail-Adresse der Person anzugeben, die für das Einrichten der betreffenden Session (Konferenz) zuständig ist. Nach der E-Mail-Adresse in der e-Zeile kann in Klammern (...) der Name der Person angegeben werden. Beispiel: [email protected] (Alex Schneider)
Eine andere Form der e-Zeile ist zulässig. Vor der E-Mail-Adresse in Klammern <...> kann der Name der Person angegeben werden. Beispiel: e= Alex Schneider
Die Telefonnummer der Person, die für das Einrichten der Session zuständig p-Zeile ist, kann in der p-Zeile angegeben werden. Sie ist optional und hat die Struktur
322
7
VoIP mit SIP
p= Beispiel: p=+49-661-36-1234 (Alex Schneider)
c-Zeile
Die Beschreibung jeder Session muss eine c-Zeile entweder bei der Spezifikation der zu übertragenden Medien (Sprache, Video, Daten) oder in den allgemeinen Angaben zur Session enthalten (siehe auch die Tabellen 7.4-1 und 2). Die c-Zeile hat folgende Struktur: c= Die einzelnen Angaben haben folgende Bedeutung: – Typ des Netzes: IN = Internet – Typ der IP-Adresse: IPv4 (IP4) oder IPv6 (IP6)
– Ziel-IP-Adresse; bei der Konferenz wird oft eine Multicast-
Adresse verwendet. b-Zeile
Die Beschreibung einer Session kann in der b-Zeile die Angaben über die benötigte Bandbreite in kbit/s enthalten. Diese Zeile ist optional und hat folgende Struktur: b=: Hierbei bedeutet:
www.wiwobooks.com
– kann als Angabe des Bandbreitentyps (bandwith type) gelten und liefert eine zusätzliche Erklärung zur Angabe . – Angabe der Bandbreite in kbit/s
Zwei Typen von werden definiert: =CT – Conference Total: die summarische Bandbreite für die ganze Konferenz =AS – Application-Specific Maximum: die für eine Applikation benötigte Band-
breite
7.4.4 Zeitspezifische Angaben Für die zeitspezifischen Angaben bei der Beschreibung einer Session stehen die Zeilen t, r und z zur Verfügung. t-Zeile
Die t-Zeile gibt an, wann die betreffende Session stattfindet, und hat die Form t=<start-time>
<stop-time>
Die Angaben haben hier folgende Bedeutung: <start-time> – Beginn der Session <Stopp-time> – Ende der Session
Die Zeitangabe stellt eine dezimale Repräsentation der Zeit in Sekunden nach dem Protokoll NTP dar.
323
7.4 Beschreibung von Sessions mit SDP
Die t-Zeile muss in der Beschreibung jeder Session enthalten sein. Beispiel: t=3034423619
3042462425
Hervorzuheben ist jedoch, dass die folgende t-Zeile
Zeile
t=0 0
t=0 0
oft bei VoIP vorkommt und besagt, dass die Session – also eine VoIP-Verbindung zwischen zwei IP-Telefonen – direkt nach dem Aufbau beginnt, d.h. zu nutzen ist, und jederzeit beendet werden kann. Eine Session kann sich wiederholen. Um dies zu beschreiben, dient die optio- r-Zeile nale r-Zeile. Sie hat folgende Struktur: r= Beispiel: Falls über drei Monate hinweg jede Woche am Montag um 10 Uhr und am Dienstag 11 Uhr eine 4-stündige Session stattfinden soll, enthält die r-Zeile: = 1 Woche • • = 1 Stunde • = 0 und 25 Stunden (relative Zeitabstände vom Beginn der ersten Session ) In diesem Fall sind die Zeilen t und r: t=3034423619 r=604800
www.wiwobooks.com
3042462419
3600
0
90000
Folgende Notation bei der Zeitangabe ist erlaubt: d als ein Tag (86400 sek), g als eine Stunde (3600 sek), m als eine Minute (60 sek) und s als Sekunde. Die oben dargestellte r-Zeile kann nun folgendermaßen aussehen: r=7d
1h
0
25h
Mit einer Angabe in der z-Zeile erfolgt die Anpassung an die Zeitzone. Diese z-Zeile Zeile hat folgende Struktur: z= Die Angaben haben folgende Bedeutung: – Zeitpunkt, zu dem ein Wechsel der Zeitzone (z. B. Übergang von Sommer- zu Winterzeit) stattfindet. Angabe nach dem Protokoll NTP. – Korrektur, die ab dem angegebenen Zeitpunkt durchgeführt werden soll.
7.4.5 Beschreibung von Medien Die Medienbeschreibung setzt sich aus der Spezifikation einzelner Medien (Audio, Video, Daten), die während der Session vorkommen können, zusammen. Die Beschreibung eines Media erfolgt in einer m-Zeile. Somit enthält die Medienbeschreibung mindestens eine m-Zeile in dieser Form (siehe RFC 4566):
324
7
VoIP mit SIP
m=<media>
<port>
<proto>
…
Die einzelnen Angaben haben hierbei folgende Bedeutung: <media> – Hier wird der Media-Typ angegeben. Daher kann hier u.a. audio, video, text, application bzw. message vorkommen. <port> – Ziel-Portnummer – also die Angabe des Ports, zu dem das Media gesendet wird. <proto> – Name des eingesetzten Protokolls zum Transport des betreffenden Media. Für den Transport von Audio und Video wird RTP verwendet. Im RTP-Header wird als Payload Type das Audio/Video-Profil – kurz AVP – angegeben, sodass man auch RTP/AVP schreibt.
Das Audio/Video-Profil stellt hierbei eine Nummer (als Identifikation) des für Audio bzw. Video eingesetzten Codierungsverfahrens dar. RTP verwendet das verbindungslose Transportprotokoll UDP, sodass dies als RTP over UDP bezeichnet wird. An dieser Stelle – als <proto> – kann udp, RTP/AVP bzw. RTP/SAVP vorkommen. − udp bedeutet, dass ein unspezifiziertes Protokoll über UDP zum Einsatz kommt, − RTP/AVP, dass RTP über UDP mit AVP nach RFC 3511 verwendet wird, und − RTP/SAVP, dass SRTP (Secure RTP) über UDP mit AVP im Einsatz ist. ... – Liste zulässiger Formate (fmt) des betreffenden Media-Typs (als Codierungsbzw. Komprimierungs-Verfahren)
Falls mehrere Medienkanäle für den Transport eines Media-Typs eingerichtet werden sollen, kann die m-Zeile folgende Form haben:
www.wiwobooks.com Mit wird die Anzahl der Medienkanäle mit dem Protom=<media>
<port>/
<proto>
…
koll RTP angegeben. An dieser Stelle ist hervorzuheben, dass RTP zusammen mit RTCP eingesetzt wird. Hat RTP die Portnummer x, die eine gerade Zahl ist, dann ist x+1 die Portnummer von RTCP. Das folgende Beispiel veranschaulicht die Nutzung dieser Form der m-Zeile. Beispiel: Die m-Zeile
m= video
49160/2 RTP/AVP
31
besagt u.a., dass zwei Medienkanäle mit RTP eingerichtet werden. Beim ersten Medienkanal wird der Port 49160 dem RTP und der Port 49161 dem RTCP zugewiesen. Beim zweiten Medienkanal belegt RTP den Port 49162 und RTCP den Port 49163.
Eine ausgewählte Liste von Audio/Video-Profilen als Formate (fmt) zeigt die 23 Tabelle 5.3-1. Die fmt-Angabe wird beim Protokoll RTP als Payload Type (PT) bezeichnet und ist in seinem Header enthalten, um darauf zu verweisen, in welchem Format ein Echtzeit-Medium (Audio, Video) die betreffende RTPDateneinheit transportiert.
23
Unter http://www.iana.org/assignments/rtp-parameters findet man eine vollständige Auflistung von Audio/Video-Profilen und PT-Werten.
325
7.4 Beschreibung von Sessions mit SDP Beispiel: Sprache – als eine Audio-Art – wird nach dem PCM-Verfahren (Pulse Code Modulation) codiert. Dieser Media-Typ hat die fmt-Identifikation 0. Soll dieser Media-Typ zum UDP-Port 49232 transportiert werden, hat seine Spezifikation folgende Form: m=audio
49232
RTP/AVP
0
Ein Streaming Media kann hierarchisch codiert werden, sodass die Angabe Angabe mehrerer Ziel-Ports nötig ist. Da bei der Übermittlung zeitkritischer Medien mehrerer nach dem RTP keine Quittungen zur Überwachung der Übermittlung in Frage Ziel-Ports kommen, wird das Protokoll RTCP (Real-Time Transport Control Protocol) verwendet, um den Übermittlungsprozess zu überwachen. Beim Einsatz von RTP mit RTCP gilt folgende Regel: Empfängt das RTP einen Media-Typ über den Port x (eine gerade Zahl), dann empfängt das RTCP seine Nachrichten über den Port x+1 (eine ungerade Zahl). Beispiel: m=audio
49232
RTP/AVP
0
Hier empfängt RTP über den Port 49232 und RTCP über den Port 49233.
Die m-Zeile mit der Angabe mehrerer Ports hat die Struktur: m=<media> <port> / Beispiel: m=video
49170/2
www.wiwobooks.com RTP/AVP
31
Hier empfängt das erste Paar RTP/RTCP über die Ports 49170 und 49171 und das zweite Paar RTP/RTCP über die Ports 49172 und 49173.
Die nähere Beschreibung eines Media-Typs kann mit dem Attribut rtpmap er- Medienbeschreibung folgen. Eine derartige a-Zeile hat die Struktur: a=rtpmap:<payload type> <encoding name> / [/<encoding parameters>]
Der Teil [..] ist optional. Die einzelnen Angaben haben hier folgende Bedeutung: <payload type> – Payload Type im RTP-Header: Dies entspricht der fmt-Identifikation in
der Tabelle 5.3-1. <encoding name> – Codierungsverfahren – Abtastrate (Anzahl der Abtastwerte je Sekunde)
Beispiel: Die Spezifikation m=video
49170/2
RTP/AVP
31
kann mit dem Attribut rtpmap näher erläutert werden: a=rtpmap: 31
H261 / 90000
Beispiel: Mit der Spezifikation m=audio
49232
RTP/AVP
0
2
9
mit Attribut rtpmap
326
7
VoIP mit SIP zeigt ein Rechner, der eine Session initiiert, an, dass er die Audio-Profile 0, 2 und 9 unterstützt (s. Tab. 5.3-1). Dies bedeutet, dass er über den Port 49232 nur die nach einem der folgenden Verfahren codierten Audio-Bitströme empfangen kann: PCM als Profil = 0, G721 (G.721) als Profil = 2 und G722 (G.722) als Profil = 9. Eine detaillierte Spezifikation dieses Audio-Bitstroms kann erfolgen als: m=audio 49232
RTP/AVP
0
2
9
a=rtpmap: 0 PCM/8000 a=rtpmap: 2 G721/8000 a=rtpmap: 9 G722/8000
Die Spezifikation von Medien – und somit von Medienkanälen – soll nun anhand zweier Beispiele – siehe die Abbildungen 7.4.5 und -6 – veranschaulicht werden. Hierbei werden nur die Angaben auf dem Media-Level gezeigt. Beispiel: Das Multimedia-Endgerät von Alice hat drei Audio-Codecs – PCMU (PT=0), PCMA (PT=8) und iLBC (PT =dyn) – und zwei Video-Codecs – H261 (PT=31) und MPV (PT =32). Die Ports im Endgerät von Alice sind: • für Audio 46170 (RTP) und 46171 (RTCP) für Video 52172 (RTP) und 52173 (RTCP) • Das Endgerät von Bob hat nur den Audio-Codec PCMU (PT=0) und den Video-Codec MPV (PT =32). Die Ports im Endgerät von Bob sind: • für Audio 46174 (RTP) und 46175 (RTCP) • für Video 46170 (RTP) und 46171 (RTCP) Abbildung 7.4-5 zeigt den Verlauf von SDP nach dem Offer/Answer-Prinzip und die Eigenschaften der eingerichteten multimedialen Session für Übermittlung von Audio und Video.
www.wiwobooks.com
O m = a = r a = r a = r m = a = r a = r
ffe a u d tp m tp m tp m v id tp m tp m
r io a p a p a p e o a p a p
4 6 :0 :8 :9 5 2 :3 :3
1 7 0 P C M P C M 7 iL B 1 7 2 1 H 2 2 M P
R T U A C R T 6 1 V
P /A /8 0 0 /8 0 0 /8 0 0 P /A /9 0 0 /9 0 0
0
V P 0 8 9 7 0 0
V P 3 1 3 2 0 0 0 0
A lic e
B o b
A
4 6 1 7 0 4 6 1 7 1 5 2 1 7 2 5 2 1 7 3
V
P T = 0
R T P R T C P
4 6 1 7 4 4 6 1 7 5
P T = 3 2
R T P R T C P
4 6 1 7 0 4 6 1 7 1
A n sw m = a u d a = rtp m m = v id a = rtp m
e r io a p e o a p
4 6 :0 4 6 :3
1 7 P C 1 7 2 M
4 R T M U 0 R T P V
P /8 P /9
/A V P 0 0 0 0 /A V P 3 2 0 0 0 0
M u ltim e d ia le S e s s io n
A : A u d io V : V id e o
Abb. 7.4-5: SDP-Verlauf bei der Abstimmung von Eigenschaften einer Session für Audiound Video-Übermittlung Hier ist auch zu sehen, dass für jeden Media-Kanal ein Monitoring-Kanal mit RTCP eingerichtet wird. Ist in einem Rechner die Portnummer des RTP-Kanals x (x = gerade Zahl), hat der ihm entsprechende RTCP-Kanal die Portnummer x+1. Beispiel: Zwischen Alice und Bob wird zuerst eine Session für die Übermittlung von Audio und Video eingerichtet. Zu einem späteren Zeitpunkt werden aber die Ports im Rechner von Bob gewechselt. Abbildung 7.4-6 zeigt den Verlauf von SDP und die modifizierte Session. Um die bestehende Session zu modifizieren, sendet der Rechner von Bob während der bestehenden Session ein re-INVITE an den Rechner von Alice. In re-INVITE werden im SDP-Teil nur die neuen Portnummern der beiden Media-Kanäle angegeben. Als Antwort übermittelt der Rechner von Alice seine Offer – jetzt aber als Answer gemeint – an den Rechner von Bob. Dabei müssen auch die RTCP-Ports entsprechend geändert werden.
7.5 Betriebsarten bei SIP
m = a = r m = a = r
O ffe r a u d io tp m a p v id e o tp m a p
m = a = r m = a = r
B o b
A lic e 4 9 :9 5 1 :3
A n sw e a u d io tp m a p v id e o tp m a p
1 7 0 7 iL B 3 7 2 1 H 2 r 4 9 :9 5 1 :3
R T C R T 6 1
1 7 0 7 iL B 3 7 2 1 H 2
P /A /8 0 0 P /A /9 0 0
R T C R T 6 1
0
IN V IT E
V P 9 7
V P 3 1 0 0
P /A /8 0 0 P /A /9 0 0
0
A
P T = 9 7 P T = 3 1 V
re -IN V IT E
V P 9 7
V P 3 1 0 0 V
A
P T = 9 7 P T = 3 1
327
A n sw e r m = a = r m = a = r
a u d tp m v id tp m
io a p e o a p
4 9 :9 4 9 :3
1 7 4 R 7 iL B 1 7 0 R 1 H 2 6 O ffe
m = a = r m = a = r
a u d tp m v id tp m
io a p e o a p
4 9 :9 4 9 :3
1 7 8 7 iL B 1 8 8 1 H 2
T P C /8 T P 1 /9 r
R T C R T 6 1
P /8 P /9
/A 0 0 /A 0 0 /A 0 0 /A 0 0
0
V P 9 7
V P 3 1 0 0
0
V P 9 7
V P 3 1 0 0
A : A u d io V : V id e o
Abb. 7.4-6: Abstimmung von Eigenschaften einer neuen Session für Audio- und VideoÜbermittlung und ihre spätere Modifikation Die RTCP-Kanäle wurden hier nicht gezeigt.
7.5
Betriebsarten bei SIP
SIP ist ein Client-Server-Protokoll. Ein Client repräsentiert ein IP-Telefon oder eine andere SIP-Endeinrichtung und fordert immer einen Dienst an. Diese Anforderung wird entweder direkt von einem anderen IP-Telefon oder von einem SIP-Server bearbeitet. Wie in Abschnitt 7.2 bereits erläutert wurde, werden bei SIP zwei Arten von SIP-Servern eingeführt: Proxy-Server und Redirect-Server.
www.wiwobooks.com
Wie bereits in den Abbildungen 7.2-1 und -3 gezeigt, nimmt ein Proxy-Server Proxy-Server beim Aufbau einer Session den Request INVITE (als Einladung zu einer Session) eines IP-Telefons (Clients) entgegen, bestimmt, wohin er weitergeleitet werden soll, und leitet ihn anschließend selbst an den nächsten SIP-Server bzw. an das Ziel-IP-Telefon weiter. Daher kann ein Proxy-Server als Anruf- bzw. Session-Weiterleitungsinstanz gelten. Ein Redirect-Server ist für die Unterstützung von „Umleitungen“ zuständig. RedirectWie in Abbildung 7.2-2 zum Ausdruck gebracht, nimmt ein Redirect-Server Server den Request INVITE entgegen und teilt dem letzten Absender von INVITE mit, wohin dieser den Request INVITE senden soll, so als ob INVITE umgeleitet würde. Somit kann man einen Redirect-Server auch als Anruf- bzw. SessionUmleitungsinstanz betrachten.
7.5.1 Proxy-Mode und Redirect-Mode Je nachdem, ob ein Proxy-Server oder ein Redirect-Server eingesetzt wird, unterscheidet man zwischen zwei Betriebsarten von SIP, und zwar zwischen dem Proxy-Mode und
328
7
VoIP mit SIP
dem Redirect-Mode. Proxy-Mode
Ein SIP-Server einer Internet-Domain im Proxy-Mode dient als Proxy-Server dieser Domain und stellt eine Art Weiterleitungsinstanz der ankommenden Anrufe in Form von Requests INVITE dar. Nach dem Erhalten eines solchen Request bestimmt der Proxy-Server die SIP-Adresse, an die der ankommende Anruf weitergeleitet werden soll, und leitet den Anruf entweder direkt zum IPTelefon des angerufenen Teilnehmers oder zum nächsten Proxy-Server weiter.
RedirectMode
Ein SIP-Server im Redirect-Mode dient als Redirect-Server einer InternetDomain und stellt eine Umleitungsinstanz der ankommenden Anrufe dar. Nach dem Empfang eines Request INVITE besteht die Aufgabe des Redirect-Servers in der Bestimmung des SIP-URI, an den der Absender von INVITE den betreffenden Anruf selbst richten – also quasi umleiten – soll. Der Redirect-Server leitet den ankommenden Anruf jedoch nicht direkt an den gewünschten Teilnehmer weiter, sondern informiert den Absender des Request INVITE, wohin er diesen Request selbst weiterleiten soll.
7.5.2 Einsatz von Proxy- und Redirect-Server
www.wiwobooks.com
Den Einsatz von Proxy- und Redirect-Server illustriert Abbildung 7.5-1. Hier initiiert das IP-Telefon von Alice mit SIP-URI sip:[email protected] mit dem Request INVITE eine Session zu Bob mit SIP-URI sip:[email protected] (1). Das IP-Telefon von Alice wird so konfiguriert, dass alle ausgehenden Requests INVITE an den SIP-Server ihrer Domain übergeben werden, der als ProxyServer fungiert. Dieser ermittelt nach dem Empfang von INVITE mit Hilfe von DNS – als Anfrage a bezeichnet – die IP-Adresse des Proxy-Servers der Heimat-Domain von Bob xyz.de, leitet INVITE an den SIP-Server der Domain xyz.de weiter (2) und sendet danach den Response 100 Trying an das IPTelefon von Alice (3). Damit wurde diesem – seitens des Proxy-Servers der Domain abc.de – der Empfang von INVITE bestätigt und auch signalisiert, dass der Aufbau der von ihm initiierten Session fortgesetzt wird. Abfrage des LocationServers
Der SIP-Server der Heimat-Domain xyz.de von Bob dient als RedirectServer. Nach dem Empfang des Request INVITE ermittelt er zuerst mit Hilfe des Location-Servers der Heimat-Domain von Bob – als Anfrage b –, an welchen Rechner der Anruf an Bob nun weitergeleitet werden soll. Bob hat seine 24 Heimat-Domain verlassen, aber vorher dem Registrar seiner Heimat-Domain mit dem Request REGISTER mitgeteilt, dass er sich zur Zeit in der Fremd24
Der Registrar – siehe Abschnitt 7.6 – kann als zusätzliche funktionelle Komponente im Proxy und im Redirect-Server untergebracht oder auch in einem sog. Location-Server implementiert werden.
7.5 Betriebsarten bei SIP
329
Domain prs.de aufhält. Daher erfährt der Redirect-Server vom LocationServer, dass der Anruf in Bobs Fremd-Domain prs.de weitergeleitet werden soll. Welchen Rechner Bob dort als IP-Telefon nutzt, kann man beim LocationServer dieser Domain abfragen.
In te rn e t (IP -N e tz )
s ip :a lic e @ a b c .d e
a b c .d e A lic e
x y z .d e a
IN V IT E 1
1 0 0 T ry in g
2 3
1 1 a u fg e le g t
R S
L S
3 0 2 M o v e d
IN V IT E
p r s .d e
P S
c ´´ 4
1 0 0 T ry in g
1 8 0 R in g in g
1 8 0 R in g in g
2 0 0 O K
2 0 0 O K
B o b
L S
b
IN V IT E
5 A C K 6
F re ito n
s ip :b o b @ x y z .d e
D N S
P S
7 8
c ´ K lin g e ln
IN V IT E
1 8 0 R in g in g 2 0 0 O K
1 0
9 a b g e h o b e n
A C K S e s s io n (V o IP -K o m m u n ik a tio n )
1 2 B Y E
www.wiwobooks.com A C K
1 3
Abb. 7.5-1: Beispiel für den Einsatz von Proxy- und Redirect-Server LS: Location-Server, PS: Proxy-Server, RS: Redirect-Server
Der Redirect-Server leitet den Anruf jedoch nicht direkt in die Domain prs.de weiter, sondern informiert mit dem Response 302 Moved Temporarily – genauer gesagt im Header-Feld Contact: <sip:[email protected]> dieser Response – den Proxy-Server der Domain abc.de darüber (4), dass dieser den Anruf selbst in die Domain prs.de richten soll. Somit wurde der Anruf an Bob in die Domain umgeleitet, in der er sich als Gast aktuell aufhält. Der Proxy-Server der Domain abc.de bestätigt den Empfang von 302 Moved Temporarily mit dem Request ACK (5). Der Proxy-Server der Domain abc.de übergibt nun den Request INVITE an den Proxy-Server der Domain prs.de (6). Nach dem Empfangen des Request INVITE mit dem SIP-URI von Bob weiß der Proxy-Server der Domain prs.de aber nicht, welchen Rechner Bob in dieser Domain gerade als IPTelefon nutzt. Hierfür wird der Location-Server abgefragt (Abfrage c´). Vom Location-Server bekommt der Proxy-Server normalerweise nur den Rechnernamen. Daher ermittelt der Proxy-Server danach zuerst mit Hilfe von DNS (Abfrage c´´) die IP-Adresse von Bobs IP-Telefon und sendet dann den Re-
Umleitung des Anrufs in eine FremdDomain
330
7
VoIP mit SIP
quest INVITE dorthin (7). Anschließend bestätigt der Proxy-Server der Domain prs.de mit dem Response 100 Trying dem Proxy-Server der Domain abc.de (8), dass er INVITE empfangen und weitergeleitet hat. Falls das IP-Telefon von Bob den ankommenden Anruf annehmen kann, wird dieser bei ihm akustisch signalisiert. Dies wird dem IP-Telefon von Alice mit dem Response 180 Ringing angezeigt (9). Hat Bob den Hörer abgenommen, sendet sein IP-Telefon den Response 200 OK an das IP-Telefon von Alice (10). Der Empfang von 200 OK wird seitens des IP-Telefons von Alice mit ACK bestätigt (11). Ist ACK beim IP-Telefon von Bob eingetroffen, ist damit der Aufbau einer Session für VoIP abgeschlossen.
7.6
Registrierung der Lokation von Benutzern
Bedeutung des Registrars
SIP definiert in einer Domain einen speziellen, als Registrar bezeichneten Server. Dieser Server stellt eine funktionelle Komponente dar, die in der Regel in einem Proxy-Server bzw. in einem Redirect-Server untergebracht wird. Der Registrar einer Internet-Domain enthält Angaben hinsichtlich der aktuellen Lokation von Benutzern seiner Domain.
Mobilität von Benutzern
Ein Benutzer sollte (technisch gesehen) die Möglichkeit haben, verschiedene Rechner – nicht nur in seiner Domain, sondern auch in anderen Domains – als sein IP-Telefon nutzen zu können. Um eine derartige Mobilität von Benutzern bei VoIP mit SIP zu unterstützen, kann ein Benutzer einen permanenten SIPURI in seiner Heimat-Domain (als Address of Record (AoR) bezeichnet) und einen vorläufigen SIP-URI – sogar in einer Fremd-Domain – besitzen. Beispielsweise kann die AoR des Benutzers Bob, der in der Domain xyz.de auf die Dauer registriert (also hier beheimatet) ist, [email protected] sein. Hält sich Bob aktuell in der Domain prs.de und nutzt dort der Rechner mit dem Hostname mond als sein IP-Telefon, könnte man ihm z.B. [email protected] als „aktuellen SIP-URI“ zuweisen. Bob muss irgendwie in seiner Heimat-Domain xyz.de darauf verweisen, unter welchem SIP-URI er aktuell erreichbar ist. Hierfür wird eine Registrierung durchgeführt.
www.wiwobooks.com
Unter einer Registrierung (Registration) bei SIP versteht man daher einen VorZiel der Registrierung gang, bei dem ein Benutzer auf dem SIP-Registrar eine Zuordnung AoR aktueller SIP-URI speichern lässt. Damit teilt er dem Registrar mit, dass er aktuell nicht unter seinem AoR erreichbar ist, sondern vorläufig unter dem angegebenen aktuellen SIP-URI – siehe Abbildung 11.3-2. Jeder Benutzer lässt sich somit verschiedenen Rechnern – die potenziell als seine IP-Telefone dienen können – zuordnen und beim Registrar seine aktuelle Lokation, d.h. die Information darüber, welches IP-Telefon er aktuell nutzt,
7.6 Registrierung der Lokation von Benutzern
anmelden. Hierfür verwendet man den Request REGISTER. Mit ihm kann jeder Benutzer die Umleitung der bei ihm an AoR ankommenden Anrufe auf einen aktuellen SIP-URI selbst veranlassen. Beispiel: Den Einsatz des Requests REGISTER veranschaulicht Abbildung 7.6-1. Der Benutzer Bob mit dem SIP-URI sip:[email protected] sitzt aktuell in seiner Heimat-Domain am IP-Telefon saturn.abc.de. Er möchte die für ihn ankommenden Anrufe auf dieses IP-Telefon umleiten und alle Anrufe über den UDP-Port 3890 empfangen. Diese Angaben werden an den Registrar, hier den Rechner registrar.xyz.de, mit dem Request REGISTER übermittelt (1). Der Registrar bestätigt die Registrierung mit dem Response 200 OK. s a tu r n .x y z .d e B o b 1
s ip :b o b @ x y z .d e
2 3
D o m a in x y z .d e R E G IS T E R R E G IS T E R R E G IS T E R
R e g is tra r 2 0 0 O K
L o c a tio n S e rv e r r e g is tr a r .x y z .d e
2 0 0 O K 2 0 0 O K
Abb. 7.6-1: Registrierung der aktuellen Lokation des Benutzers Bob
www.wiwobooks.com
Der Request REGISTER (1) hat folgende Struktur: REGISTER sip:registrar.xyz.de SIP/2.0
Via: SIP/2.0/UDP saturn.xyz.de; branch=z9hG4bKbashed7 Max-Forwards: 70 To: Bob <sip:[email protected]> From: Bob <sip:[email protected]>; tag=543743 Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]: 3890; transport=udp> Expires: 14400 Content-Length: 0
Die einzelnen Header-Zeilen in diesem Request enthalten: • REGISTER: SIP-Adresse des Registrars und die SIP-Version • Via: SIP-Version, Transport-Protokoll, Name des Absender-Rechners (-IP-Telefon) To und From: SIP-URI des Absenders (Bob) • • Call-ID: Identifikation des Registrar-Anrufs; Verknüpfung einer Zufallszahl (71710) mit dem IP-Telefon-Namen (saturn.xyz.de). Die Call-ID dient hier als eine Art Transaktionsnummer. • CSeq: 1-te Nachricht REGISTER innerhalb der Transaktion [email protected] • Contact: Lokation des Benutzers; die Anrufe zu Bob sollen zum IP-Telefon saturn.abc.de und zum UDP-Port 3890 geleitet werden. Expires: Die Registrierung ist im Zeitraum von 14 400 Sekunden (6 Stunden) gültig. • • Content-Length: Mit 0 wird darauf verwiesen, dass die Nachricht keinen Body enthält.
331
332
7
VoIP mit SIP
Der Benutzer Bob ist bereits vor dem Ablauf von 6 Stunden unterwegs und aktuell unter dem SIP-URI sip:[email protected] zu erreichen. Um Anrufe auf diese aktuelle Adresse umzuleiten, wird zuerst die vorher durchgeführte Eintragung beim Registrar mit dem zweiten Request REGISTER (2) für ungültig erklärt. Um Anrufe, die in der Heimat-Domain von Benutzer Bob eintreffen, auf den SIP-URI sip:[email protected] umzuleiten, sendet er nun an den Registrar in seiner Heimat-Domain den nächsten Request REGISTER (3). Im Registrar der Domain xyz.de, in der sich der Benutzer Bob aktuell befindet, muss seine Lokation ebenfalls eingetragen werden.
third-party registration
Die Lokation einer Person kann eine andere Person beim Registrar registrieren. Beispielsweise kann eine Sekretärin die aktuelle Lokation ihres Chefs beim Registrar eintragen (sog. third-party registration).
7.7
Sessionbezogene Leistungsmerkmale mit SIP
Bei Sprachkommunikation sind einige spezielle Funktionen wie z.B. Weiterleitung, Parken bzw. Übergabe eines ankommenden Anrufs an einen dritten Benutzer von großer Bedeutung. Diese zusätzlichen Funktionen, die man als sessionbezogene Leistungsmerkmale, Dienstmerkmale oder Call Features bezeichnet, müssen auch bei VoIP realisiert werden. Dafür wurden in mehreren RFCs zahlreiche Ergänzungen zu SIP spezifiziert. Dieser Abschnitt zeigt, wie man 25 diese sessionbezogenen Leistungsmerkmale mit SIP realisiert.
www.wiwobooks.com
7.7.1 Klassen der Leistungsmerkmale mit SIP Die verschiedenen sessionbezogenen Leistungsmerkmale lassen sich bestimmten Klassen zuordnen. Abbildung 7.7-1 illustriert dies und zeigt, welche Leistungsmerkmale zu den einzelnen Klassen gehören. Die Besonderheiten einzelner Leitungsmerkmale werden im Folgenden kurz erläutert. Call Hold
Als Call Hold (Anhalten einer Session) versteht man bei VoIP die Möglichkeit, eine bestehende VoIP-Session kurz anzuhalten, um in der Zwischenzeit z.B. an einer anderen Session teilzunehmen und die angehaltene Session danach fortzusetzen. Dadurch können Leistungsmerkmale bereitgestellt werden, wie z.B.: Call Hold und Retrieve – Anruf anhalten und wieder aufnehmen Ein während einer bestehenden VoIP-Verbindung ankommender Anruf kann durch „Anklopfen“ angezeigt werden, ein Benutzer hat daher die Möglichkeit, das Gespräch auf der bereits bestehenden Verbindung kurz zu un25
Unter http://www.tech-invite.com/Ti-sip-service-1.html findet man Beispiele, die als Ergänzung der in diesem Abschnitt dargestellten SIP-Abläufe bei der Realisierung wichtiger sessionbezogener Leistungsmerkmale dienen können.
7.7 Sessionbezogene Leistungsmerkmale mit SIP
333
terbrechen – d.h., den Anruf auf „Hold“ zu setzen – und die neue Verbindung aufzunehmen. Nach der Beendigung der neuen Verbindung kann er zur alten Verbindung zurückkehren und das unterbrochene Gespräch fortsetzen. Die Wiederaufnahme einer angehaltenen Verbindung bezeichnet man auch als Call Retrieve. K la s s e n d e r L e is tu n g s m e rk m a le m it S IP A n r u f h a lte n
C a ll H o ld a n d R e trie v e C o n s u lta tio n H o ld M u s ic o n H o ld
C a ll P a rk in g
C a ll P a rk (in g )
C a ll P ic k u p
D ire c te d C a ll P ic k u p G ro u p C a ll P ic k u p
C a ll H o ld
A n ru f p a rk e n A n r u fü b e r n a h m e
C a ll F o rw a rd in g
A n r u fw e ite r le itu n g
C a ll F o rw a rd in g U n ic o n d itio n a l C a ll F o rw a rd in g B u s y C a ll F o rw a rd in g N o A n s w e r
C a ll T ra n s fe r
U n a tte n d e d C a ll T ra n s fe r A tte n d e d C a ll T ra n s fe r
C a ll Q u e u in g
C o m p le tio n o f C a lls to B u s y S u b s c rib e r C o m p le tio n o f C a lls o n N o R e p ly
A n r u fü b e r g a b e
www.wiwobooks.com A n r u f a u f W a r te lis te
Abb. 7.7-1: Klassen sessionsbezogener Leistungsmerkmale mit SIP
Consultation Hold – Anhalten einer Session mit Rückfrage Bei VoIP kann eine bestehende Session zwischen Benutzern A und B beispielsweise durch Benutzer B kurz angehalten werden, damit Letzterer zwischendurch eine neue Session zum Benutzer C für Konsultationszwecke einrichten kann. Nach dem Abbau der Session mit Benutzer C kann er die angehaltene Session mit Benutzer A wieder aktivieren und die Kommunikation mit A wiederaufnehmen.
Consultation Hold
Music on Hold – Musikeinspielung im Haltezustand Falls eine bestehende Session zwischen den Benutzern A und B beispielsweise durch den Benutzer B angehalten wurde, kann dem Benutzer A in der Zwischenzeit – d.h. in seinem Haltezustand – von einem dedizierten Server aus Musik gesendet werden. Unter Call Park – auch Call Parking genannt – versteht man bei VoIP die Call Möglichkeit, eine bestehende Session zwischen den Benutzern A und B bei- Park(ing) spielsweise seitens des Benutzers B auf einem speziellen Park-Server anzuhalten und dem Benutzer A vorübergehend Musik einzuspielen oder eine Ansage zu übermitteln, damit ein anderes IP-Telefon diese geparkte Session später wiederaufnehmen kann. Benutzer B teilt dem Park-Server durch die Angabe
334
7
VoIP mit SIP
von SIP-URI mit, von welchem anderen IP-Telefon aus die geparkte Session wiederaufgenommen werden soll, um von Benutzer B oder einem anderen Benutzer eventuell fortgesetzt zu werden. Call Pickup
Unter Call Pickup versteht man bei VoIP die Möglichkeit, dass eine von Benutzer A zu Benutzer B initiierte VoIP-Verbindung, falls diese beim Klingeln nicht vom angerufenen Benutzer B angenommen werden kann, von einem anderen – vorher festgelegten – Benutzer C übernommen werden kann. In der klassischen Telefonie wird diese Möglichkeit auch als Übernahme bzw. Heranholen eines Anrufs bezeichnet. Bei VoIP ist es aber sinnvoller, von Übernahme bzw. Heranholen einer Session zu sprechen. Die beiden folgenden Leistungsmerkmale basieren auf der Übernahme einer Session: Directed Call Pickup (DCPU) – gezielte Session-Übernahme Mit diesem Leistungsmerkmal ist es möglich, dass eine bei Benutzer B eintreffende VoIP-Verbindung von einem anderen vorher festgelegten Benutzer C übernommen wird, falls sie Benutzer B nicht selbst entgegennimmt. Group Call Pickup (GCPU) – Session-Übernahme durch eine Gruppe Mit GCPU ist es möglich, eine Benutzergruppe – oft als Pickup Group (Anrufübernahmegruppe) bezeichnet – so zu bilden, dass eine bei Benutzer B aus der Pickup Group X ankommende VoIP-Verbindung ein anderer Benutzer aus dieser Gruppe übernimmt.
www.wiwobooks.com
Call Forwarding
Unter Call Forwarding – Anrufweiterleitung bzw. -umleitung – versteht man in der klassischen Telefonie die Möglichkeit, dass ein beim angerufenen Teilnehmer B eintreffender Anruf an einen dritten, vorher festgelegten Teilnehmer C weitergeleitet wird. Bei VoIP ist es sinnvoll, von der Weiterleitung eines VoIP-Anrufs bzw. einer Session zu sprechen. Auf der Weiterleitung einer Session basieren folgende Leistungsmerkmale:
CFU
Call Forwarding Unconditional (CFU) – bedingungslose Weiterleitung eines VoIP-Anrufs CFU bedeutet, dass alle bei einem SIP-URI ankommenden Anrufe bedingungslos an einen anderen SIP-URI weitergeleitet werden, d.h., dass die Anrufweiterleitung ständig aktiv ist.
CFB
Call Forwarding Busy (CFB) – Weiterleitung eines Anrufs bei Besetzt Dieses Leistungsmerkmal bewirkt, dass ein am IP-Telefon des Benutzers B ankommender VoIP-Anruf, falls Benutzer B zu dieser Zeit ein anderes Telefonat von seinem IP-Telefon aus führt, an ein anderes IP-Telefon weitergeleitet wird.
335
7.7 Sessionbezogene Leistungsmerkmale mit SIP
Call Forwarding No Answer/Reply (CFNA/R) – Weiterleitung eines VoIP- CFNA/R Anrufs bei Nichtmelden des Angerufenen Dieses Leistungsmerkmal bedeutet, dass ein am IP-Telefon von Benutzer B ankommender VoIP-Anruf an ein anderes IP-Telefon weitergeleitet wird, falls Benutzer B ihn nicht entgegennehmen kann. Als Call Transfer (Anrufübergabe) versteht man in der klassischen Telefonie Call die Möglichkeit, dass ein beim Teilnehmer B ankommender Anruf von Teil- Transfer nehmer B bzw. auch von Teilnehmer A an einen dritten Teilnehmer C übergeben werden kann. Bei VoIP kann man daher von Übergabe eines VoIP-Anrufs bzw. von der Übergabe einer Session sprechen. Call Transfer ist eines der wichtigsten Leistungsmerkmale in privaten Netzen mit VoIP und erlaubt es, eine bestehende Session zwischen Benutzer A – als Anrufer – und Benutzer B – als Angerufenem – von Benutzer B an Benutzer C zu übergeben (zu transferieren). Dies bedeutet, dass die bestehende Session zwischen den Benutzern A und B auf die Session zwischen den Benutzern B und C transferiert (übergeben) wird. Mit SIP können mehrere Arten von Call Transfer realisiert werden, wie z.B.: Unattended Call Transfer (UCT) – direkte Übergabe eines VoIP-Anrufs UCT ohne Rücksprache
www.wiwobooks.com
Dieses Leistungsmerkmal bewirkt, dass ein von Benutzer A am IP-Telefon des Benutzers B eingehender VoIP-Anruf direkt – bedingungslos – von diesem an einen Benutzer C übergeben wird, ohne mit Benutzer C Rücksprache zu halten. Somit wird die Session zwischen Benutzern A und B auf die Session zwischen den Benutzern B und C transferiert. UCT bezeichnet man manchmal als Blind Call Transfer. Attended Call Transfer (ACT) – Übergabe eines VoIP-Anrufs nach Rück- ACT sprache Im Gegensatz zu UCT wird beim ACT zuerst Rücksprache mit Benutzer C gehalten, bevor die zwischen den Benutzern A und B bestehende Session transferiert wird. Durch eine kurze Zwischenspeicherung von SIP-Requests INVITE, mit denen Call die Session bei VoIP initiiert wird, ist es möglich, folgende SIP-Leistungs- Queuing merkmale vom Typ „Rückruf“ zu realisieren: Call Completion to Busy Subscriber (CCBS) – Rückruf bei Besetzt CCBS ermöglicht es dem anrufenden Benutzer A, der ein besetztes IP-Telefon des Benutzers B anruft, einen automatischen Rückruf bei Freiwerden des besetzten IP-Telefons von B zu aktivieren. Ist das gewünschte IP-Telefon frei geworden, so wird dies dem anrufenden Benutzer A angezeigt. Er
CCBS
336
7
VoIP mit SIP
kann nun entscheiden, ob er eine VoIP-Verbindung zu diesem – ohne erneute Angabe seines SIP-URI – herstellen möchte oder nicht. Call Completion on No Reply (CCNR) – Rückruf bei Nichtmelden
CCNR
Mit diesem Leistungsmerkmal erhält der anrufende Benutzer A die Möglichkeit, bei Nichtmelden des angerufenen Benutzers B das Initiieren der gewünschten VoIP-Verbindung automatisch von einem SIP-Server wiederholen zu lassen. Sollte der Angerufene wieder aktiv werden – dies kann z.B. durch den Aufbau einer eigenen Verbindung erkennbar sein – und wird sein IP-Telefon wieder frei, startet der SIP-Server selbst einen Rückruf an Benutzer A, der dieses Leistungsmerkmal auf dem SIP-Server aktiviert hat. Nimmt er den Rückruf an, wird ohne erneute Angabe des SIP-URI vom Benutzer B die VoIP-Verbindung zum ihm aufgebaut.
7.7.2 Call Hold/Retrieve – Anhalten/Wiederaufnahme Das Leistungsmerkmal Call Hold/Retrieve – als Anhalten/Wiederaufnahme einer Session – ermöglicht es, eine bereits zwischen zwei Benutzern bestehende bidirektionale Session von einem Benutzer aus – in der Regel vom Angerufenen – so anzuhalten, dass sie in der Folge nur noch als unidirektionale und zum anderen Benutzer gerichtete Session bestehen bleibt und zu gegebener Zeit wiederaufgenommen werden kann.
www.wiwobooks.com
Abbildung 7.7-2 illustriert den SIP-Verlauf bei der Realisierung des Leistungsmerkmals Call Hold/Retrieve. Hier wird die zwischen den IP-Telefonen von Alice und Bob bestehende bidirektionale Session von Bob aus so angehalten, dass sie nur noch als unidirektionale und zu Alice gerichtete Session weiter besteht. Während der Zeit, in der die Session angehalten ist, kann zum IP-Telefon von Alice eine Ansage oder Musik gesendet werden. Zu einem späteren Zeitpunkt wird die angehaltene Session von Bob wiederaufgenommen. Beim SIP-Verlauf in Abbildung 7.7-2 sind folgende zwei Phasen zu unterscheiden: A
Aufbau einer Session Die Session zwischen den IP-Telefonen von Alice und Bob wird nach den in Abbildung 7.1-11 dargestellten Prinzipien aufgebaut.
B
Anhalten der Session Hier aktiviert Bob das Leistungsmerkmal Call Hold, um die bestehende Session zum IPTelefon von Alice anzuhalten. Hierfür sendet sein IP-Telefon den Request INVITE mit der gleichen Call-ID, die im vom Initiator der Session in der Phase A abgeschickten Request INVITE enthalten war, um die bestehende Session zu identifizieren. In diesem INVITE wurde der Session jetzt durch Hinzufügen der Zeile a=sendonly im Body-Teil nach SDP das Attribut sendonly zugeordnet. Damit wird die Session zu Alice gerichtet (unidirektional!), sodass nur das IP-Telefon von Bob zu Alice senden darf und nicht umgekehrt. Das IPTelefon von Alice bestätigt INVITE mit dem Response 200 OK, und diesen Response quittiert das IP-Telefon von Bob mit ACK. Danach besteht nur noch eine unidirektionale und
7.7 Sessionbezogene Leistungsmerkmale mit SIP zum IP-Telefon von Alice gerichtete Session weiter, sodass ihr z.B. Musik seitens des IPTelefons von Bob gesendet werden kann. S IP -P ro x y
A lic e
a b c .d e
s ip :a lic e @ a b c .d e
B o b s ip :b o b @ a b c .d e
S e s s io n -A u fb a u A
S e s s io n a ls V o IP -V e rb in d u n g
A n h a lte n d e r S e s s io n
B
I N V I T E [a = s e n d o n ly ] 2 0 0 O K
I N V I T E [a = s e n d o n ly ] 2 0 0 O K
A C K
A C K
S e s s io n a n g e h a lte n ( z .B . M u s ik )
W ie d e r- C a u fn a h m e d e r S e s s io n
IN V IT E 2 0 0 O K
A C K
IN V IT E 2 0 0 O K
A C K
S e s s io n w ie d e ra u fg e n o m m e n D
S e s s io n -A b b a u
Abb. 7.7-2: Call Hold/Retrieve – Anhalten und Wiederaufnahme einer Session mit SIP C
www.wiwobooks.com
Wiederaufnahme der Session
Um die angehaltene Session wiederaufzunehmen, sendet das IP-Telefon von Bob den Request INVITE mit der gleichen Call-ID – wie in der Phase B –, aber diesmal ohne die Zeile a=sendonly im Body-Teil. Damit wird der Session das ursprüngliche Attribut sendresv wieder zugeordnet, sodass sie nun als bidirektional spezifiziert wird. Das IPTelefon von Alice bestätigt den Empfang von INVITE mit 200 OK, und seitens des IPTelefons von Bob wird 200 OK noch mit ACK quittiert. Nun besteht wieder eine bidirektionale Session zwischen den IP-Telefonen von Alice und Bob. D
Abbau der Session Die Session wird nach dem in Abbildung 7.1-11 dargestellten Prinzip abgebaut.
7.7.3 Consultation Hold – Anhalten mit Rückfrage Das Leistungsmerkmal Call Hold bei VoIP – als Anhalten einer Session mit Rückfrage – ermöglicht es, eine bereits zwischen zwei Benutzern bestehende bidirektionale Session von einem Benutzer aus – in der Regel vom Angerufenen aus – so anzuhalten, dass sie weiter nur noch als unidirektionale und zum anderen Benutzer gerichtete Session bestehen bleibt. In der Zwischenzeit kann eine Rücksprache mit einem dritten Benutzer gehalten werden. Nach der Rücksprache wird die angehaltene Session wieder aktiviert und fortgesetzt. Abbildung 7.7-3 zeigt den SIP-Verlauf beim Anhalten mit Rückfrage.
337
338
7
VoIP mit SIP
S IP -P ro x y a b c .d e
s ip :a lic e @ a b c .d e
A lic e
B o b
s ip :b o b @ a b c .d e
S e s s io n -A u fb a u A
S e s s io n a ls V o IP -V e rb in d u n g B
s ip :b ill@ a b c .d e
A n h a lte n d e r S e s s io n d u rc h B o b
B ill
S e s s io n A lic e - B o b a n g e h a lte n IN V IT E U n id ire k S e s s io n z ih r k a n n g e se n d e t
tio n a le u A lic e , M u s ik w e rd e n .
1 0 0 T ry in g C
IN V IT E 1 8 0 R in g in g
1 8 0 R in g in g 2 0 0 O K
2 0 0 O K A C K
K o n s u lta tio n z w is c h e n B o b u n d B ill
A C K
D
S e s s io n B Y E
B Y E
2 0 0 O K E
2 0 0 O K
F
W ie d e ra u fn a h m e d e r S e s s io n d u rc h B o b S e s s io n A lic e - B o b w ie d e ra u fg e n o m m e n S e s s io n -A b b a u
www.wiwobooks.com
Abb. 7.7-3: Realisierung des Leistungsmerkmals Anhalten mit Rückfrage – Consultation Hold In Abbildung 7.7-3 sind folgende Phasen zu unterscheiden: A
Aufbau einer Session zwischen den IP-Telefonen von Alice und Bob Diese Session wird nach den in Abbildung 7.1-11 dargestellten Prinzipien aufgebaut.
B
Anhalten der Session zwischen den IP-Telefonen von Alice und Bob Das Anhalten der Session erfolgt, wie in Abbildung 7.7-2 dargestellt.
C
Aufbau einer Session zwischen den IP-Telefonen von Bob und Bill
D
Abbau der Session zwischen den IP-Telefonen von Bob und Bill
E
Wiederaufnahme der Session zwischen den IP-Telefonen von Alice und Bob Dies erfolgt nach den in Abbildung 7.7-2 dargestellten Prinzipien. Hierbei muss der Request INVITE – mit dem die Wiederaufnahme der Session initiiert wird – die gleiche Call-ID enthalten, die im INVITE enthalten war, mit dem – in der Phase A – der Aufbau der Session durch das IP-Telefon von Alice initiiert wurde.
F
Abbau der Session zwischen den IP-Telefonen von Bob und Bill
7.7.4 Call Park – Parken einer Session Das Leistungsmerkmal Call Park ermöglicht es, eine bereits bestehende bidirektionale Session zwischen den Benutzern A und B auf einen sog. Park-
7.7 Sessionbezogene Leistungsmerkmale mit SIP
Server zu übergeben, sodass sie dort geparkt (gehalten) werden kann, damit ein dritter Benutzer C – der vorher festgelegt und dazu berechtigt wurde – die geparkte Session übernehmen kann. Abbildung 7.7-4 illustriert dies. A lic e
B o b
s ip :a lic e @ a b c .d e
s ip :b o b @ a b c .d e
S e s s io n -A u fb a u S e s s io n A
C a ll-ID : x -c id
R E F E R B
s ip :p a r k @ s e r v e r .a b c .d e
In itiie re n d e s P a rk e n s
2 0 2 A c c e p te d
2 0 0 O K
N O T IF Y
D a s P a rk e n w u rd e b e g o n n e n
IN V IT E
2 0 0 O K C
S IP -S e rv e r (P a rk S e rv e r)
A C K G e p a rk te S e s s io n (M u s ik )
D
B Y E
2 0 0 O K
C a ll-ID : y -c id
E
N O T IF Y
2 0 0 O K
F
D a s P a rk e n w u rd e b e e n d e t 2 0 0 O K N O T IF Y
s ip :b ill@ a b c .d e
B ill
S U B S C R IB E
www.wiwobooks.com IN V IT E
2 0 0 O K
G
2 0 0 O K A C K
S e s s io n A lic e - B ill H
B Y E
2 0 0 O K
C a ll-ID : z -c id
G e p a rk te S e s s io n
Abb. 7.7-4: SIP-Verlauf bei Call Park – das Parken einer Session und ihre Wiederaufnahme
Im hier gezeigten Beispiel wird die bestehende bidirektionale Session zwischen den Telefonen von Alice als Anrufer und Bob als Angerufenem auf dem ParkServer geparkt und danach vom – z.B. von Bob bestimmten und berechtigten – Benutzer Bill übernommen. Damit wird quasi die ursprüngliche Session zwischen Alice und Bob durch die neue Session zwischen Alice und Bill ersetzt. Beim SIP-Verlauf in Abbildung 7.7-4 sind folgende Phasen zu unterscheiden: A
Aufbau einer Session zwischen Alice und Bob
B
Initiieren des Parkens durch Bob Das IP-Telefon von Bob initiiert mit dem SIP-Request REFER auf dem Park-Server das Parken der Session zwischen ihm und dem IP-Telefon von Alice, und dieser signalisiert hierzu seine Bereitschaft mit dem SIP-Response 202 Accepted. Mit REFER wird dem Park-Server durch die Angabe Replaces=x-cid im Header-Feld Refer-To mitgeteilt, dass er die Session mit der Identifikation x-cid – d.h. die Session zwischen Alice und Bob – durch eine
339
340
7
VoIP mit SIP neue Session von ihm zu Alice ersetzen soll. Daher enthält REFER hier u.a. folgende Header-Felder: Call-ID:y-cid gibt die Identifikation der geparkten Session an, • • Refer-To:<sip:[email protected]?Replaces=x-cid> besagt, dass die geparkte Session an den SIP-URI sip:[email protected] führen und die Session mit Call-ID= xcid ersetzen soll. In der Zeile Refer-To wird so angegeben, wohin die Session vom Park-Server führen soll. • Referred-By:<sip:[email protected]> verweist darauf, dass das Parken vom SIP-URI sip:[email protected] initiiert wird. Die Zeile Referred-By gibt somit an, wer das Parken initiiert hat.
C
Parken der Session wurde begonnen Der Park-Server teilt dem IP-Telefon von Bob mit dem SIP-Request NOTIFY mit, dass er versucht, die Session zum SIP-URI sip:[email protected] aufzubauen. Der Empfang von NOTIFY wird seitens des IP-Telefons von Bob mit 200 OK bestätigt. Danach initiiert der Park-Server mit INVITE eine Session zum IP-Telefon von Alice. Dieses bestätigt INVITE mit 200 OK, und der Park-Server quittiert 200 OK noch mit ACK. Damit wurde die Session zwischen Alice und Bob geparkt, an Alice kann nun z.B. vom Park-Server aus Musik gesendet werden.
D
Abbau der Session zwischen Alice und Bob Weil die geparkte Session später von einem anderen dritten Benutzer – hier Bill – übernommen wird, baut das IP-Telefon von Alice die zu Bob bestehende Session ab.
E
www.wiwobooks.com
Parken der Session wurde abgeschlossen
Der Park-Server signalisiert dem IP-Telefon von Bob mit NOTIFY, dass das Parken erfolgreich abgeschlossen wurde, was seitens des IP-Telefons von Bob mit 200 OK bestätigt wird. F
IP-Telefon von Bill ruft die Dialog-Daten ab Das IP-Telefon von Bill muss nun beim Park-Server veranlassen, dass dieser ihm die Dialog-Information – mit dem Ziel der zu initiierenden Session – zukommen lässt. Hierfür sendet er an den Park-Server zuerst SUBSCRIBE mit dem Header-Feld Event: dialog, dieser quittiert SUBSCRIBE mit 200 OK und übermittelt anschließend dem IP-Telefon von Bill in NOTIFY – im Body-Teil als XML-Format – das Ziel der Session, d.h. SIP-URI sip:[email protected] von Alice. Das IP-Telefon von Bill bestätigt NOTIFY mit 200 OK. Da ihm nun das Ziel der Session bekannt ist, kann er mit dem Aufbau einer Session zu Alice beginnen, um damit die von Bob geparkte Session zu übernehmen.
G
Übernahme der Session durch das IP-Telefon Bills. Die geparkte Session zu Alice übernimmt nun das IP-Telefon von Bill. Dies wird seinerseits durch Absenden von INVITE zum IP-Telefon von Alice veranlasst. Den Empfang von INVITE bestätigt das IP-Telefon von Alice mit 200 OK; 200 OK wird außerdem vom IPTelefon Bills mit ACK quittiert. Damit wurde eine Session von Bill zu Alice aufgebaut und die geparkte Session zwischen Alice und Bob somit ersetzt.
H
IP-Telefon von Alice trennt sich vom Park-Server Nachdem die Session vom IP-Telefon von Bill übernommen wurde, trennt sich nun das IPTelefon von Alice vom Park-Server durch das Absenden von BYE. Der Park-Server bestätigt BYE noch mit 200 OK.
7.7 Sessionbezogene Leistungsmerkmale mit SIP
7.7.5 Call Pickup – Übernahme einer Session Mit dem Leistungsmerkmal Call Pickup bei VoIP mit SIP wird die Möglichkeit geschaffen, dass ein anderer Benutzer einen ankommenden Anruf, falls ihn der Angerufene nicht entgegennehmen kann, übernimmt (heranholt). Im Allgemeinen lässt sich eine Gruppe von Benutzern – eine sog. Pickup Group – bilden, sodass jeder Benutzer aus dieser Gruppe die bei anderen Mitgliedern dieser Gruppe ankommenden Anrufe übernehmen kann. Abbildung 7.7-5 illustriert den SIP-Verlauf bei der Realisierung von Call Pickup. Hier initiiert Alice eine Session zu Bob. Da Bob sich an seinem IP-Telefon nicht meldet, wird die Session vom dritten Benutzer – hier Bill – übernommen. Bob und Bill gehören zu einer Pickup-Gruppe der Domain abc.de. A lic e A
s ip :b o b @ a b c .d e
s ip :a lic e @ a b c .d e
IN V IT E
1 8 0 R in g in g B o b m e ld e t s ic h n ic h t.
C
B
B o b
B ill s ip :b ill@ a b c .d e
2 0 0 O K N O T IF Y
S U B S C R IB E 2 0 0 O K
www.wiwobooks.com I N V I T E [R e p la c e s : b o b ]
2 0 0 O K C A N C E L
2 0 0 O K 4 8 7 R e q u e s t T e rm in a te d 2 0 0 O K
D e r A u fb a u d e r S e s s io n z u B o b w ird a b g e b ro c h e n .
A C K
S e s s io n A lic e - B ill
Abb. 7.7-5: Call Pickup – Wiederaufnahme einer Session beim Nichtmelden des Angerufenen Der SIP-Verlauf in Abbildung 7.7-5 umfasst folgende Phasen: A
Alice initiiert eine Session zu Bob Hierfür sendet das IP-Telefon von Alice den SIP-Request INVITE an das IP-Telefon von Bob. Die initiierte Session kann zustande kommen, und es klingelt bei Bob. Dies wird dem IP-Telefon von Alice mit dem SIP-Response 180 Ringing signalisiert. Bob nimmt den ankommenden Anruf aber nicht entgegen – er meldet sich also nicht. Daher wird dieser Anruf von Bill – als Mitglied der Pickup-Group von Bob – entgegengenommen. Die hier initiierte Session hat die Identifikation call-id = [email protected].
B
Abfrage der Dialog-Information durch Bill Bill möchte nun den bei Bob ankommenden VoIP-Anruf übernehmen. Zu diesem Zweck muss er aber vom IP-Telefon von Bob einige Informationen, die den ankommenden Anruf betreffen – die sog. Dialog-Information – abrufen. Hierfür sendet sein IP-Telefon den SIPRequest SUBSCRIBE, um dem IP-Telefon von Bob mitzuteilen, dass er die DialogInformation abrufen möchte. SUBSCRIBE enthält dafür folgende Zeilen: • •
Event:dialog Accept:application/dialog-info+mxl
341
342
7
VoIP mit SIP Das IP-Telefon von Bob übermittelt die Dialog-Information – hierzu gehört u.a. call-id ([email protected]) und der SIP-URI von Alice als target – im XML-Format im Body des SIP-Request NOTIFY.
C
Übernahme der Session durch Bill Nachdem das IP-Telefon von Bill in NOTIFY die benötigte Dialog-Information vom IPTelefon von Bob bekommen hat, beginnt es mit INVITE eine neue Session – mit einer neuen Identifikation – zu Alice zu initiieren. Im Header-Feld Require: replaces in INVITE kommt zum Ausdruck, dass eine Session ersetzt werden soll. Dass es sich hierbei um die vom IP-Telefon von Alice initiierte Session handelt, wird durch das Eintragen von [email protected] als call-id im Header-Feld – d.h. Replaces: [email protected]; ... – mitgeteilt. Das IP-Telefon von Alice bestätigt INVITE mit 200 OK, und anschließend wird mit dem Request CANCEL dem IP-Telefon von Bob signalisiert, dass der Aufbau der bereits initiierten Session – ihre Identifikation ist [email protected] – abgebrochen werden soll. Das IPTelefon von Bob bestätigt den Empfang von CANCEL mit 200 OK und teilt dem IP-Telefon von Alice mit dem Response 487 Request Terminated mit, dass der Aufbau der Session bei ihm bereits abgebrochen wurde. Nach dem Eintreffen des Request ACK vom IP-Telefon von Bill am IP-Telefon von Alice wird der Aufbau der Session zwischen Alice und Bob beendet. Damit wurde auch die Übernahme der von Bill zu Bob initiierten Session abgeschlossen.
7.7.6 Call Forwarding – Weiterleitung einer Session
www.wiwobooks.com
Mit dem Leistungsmerkmal Call Forwarding wird bei VoIP die Möglichkeit bereitgestellt, einen ankommenden Anruf vom IP-Telefon des Angerufenen automatisch an ein anderes IP-Telefon weiterzuleiten. Dies kann entweder bedingungslos oder bei Besetzt bzw. Nichtmelden des Angerufenen erfolgen. Call Forwarding Busy
Abbildung 7.7-6 zeigt den SIP-Verlauf bei der Realisierung des Leistungsmerkmals Call Forwarding Busy – d.h. der Anrufweiterleitung bei Besetzt. A lic e
s ip :a lic e @ a b c .d e
A
IN V IT E
1 0 0 T ry in g
S IP -P ro x y a b c .d e IN V IT E A C K
B A C K
1 8 1 C IB F 1 8 0 R in g in g 2 0 0 O K
4 8 6 B u sy H e re
IN V IT E
s ip :b o b 1 @ a b c .d e
B o b B e s e tz t
1 8 0 R in g in g 2 0 0 O K
A C K S e s s io n A lic e - B o b
Abb. 7.7-6: SIP-Verlauf bei einer Weiterleitung bei Besetzt des Angerufenen CIBF: Call Is Being Forwarded
s ip :b o b 2 @ a b c .d e B o b
7.7 Sessionbezogene Leistungsmerkmale mit SIP
Hier initiiert Alice eine Session zu Bob. Das IP-Telefon von Bob mit dem SIPURI sip:[email protected] ist aber besetzt, und der Anruf wird an das zweite IPTelefon von Bob weitergeleitet. Hier wurde angenommen, dass die Weiterleitungsziele von Bob bereits auf dem SIP-Proxy abgespeichert wurden. Abbildung 7.7-6 zeigt die beiden folgenden Phasen: A
Alice initiiert eine Session zu Bob, und sein IP-Telefon ist besetzt Hierfür wird der SIP-Request INVITE an das IP-Telefon von Bob mit dem SIP-URI sip:[email protected] übermittelt. Der Proxy leitet INVITE an das IP-Telefon von Bob weiter und bestätigt INVITE anschließend dem IP-Telefon von Alice mit 100 Trying. Die initiierte Session kann aber nicht zustande kommen, weil das IP-Telefon von Bob gerade besetzt ist. Dies signalisiert das IP-Telefon von Bob dem SIP-Proxy mit dem Response 468 Here Busy. Den Empfang dieses Response bestätigt der SIP-Proxy mit ACK. Es wird hier angenommen, dass im Proxy eine sog. Anrufweiterleitungstabelle vorhanden ist, in der die Weiterleitungsziele eingetragen worden sind.
B
SIP-Proxy leitet den ankommenden VoIP-Anruf weiter Der SIP-Proxy leitet den Anruf durch das Absenden von INVITE an das zweite IP-Telefon von Bob weiter, und gleichzeitig teilt es dies dem IP-Telefon von Alice mit dem Response 181 Call Is Being Forwarded mit. Das Weiterleitungsziel wurde hierbei der Anrufweiterleitungstabelle entnommen. Der weitere SIP-Verlauf beim Aufbau der Session erfolgt hier nach den bereits in Abbildung 7.1-11 dargestellten Prinzipien.
www.wiwobooks.com
7.7.7 Unattended Call Transfer
Mit dem Leistungsmerkmal Call Transfer (CT) – als Transfer einer VoIP-Verbindung bzw. Transfer einer Session – kann eine bestehende Session von einem der beiden Kommunikationspartner an einen weiteren (dritten) Teilnehmer übergeben werden. Die Übergabe der Session kann hierbei entweder ohne Anfrage (Rücksprache) beim dritten Teilnehmer – Unattended CT – oder nach einer Anfrage bei ihm – Attended CT – erfolgen. Abbildung 7.7-7 illustriert den SIP-Verlauf bei Unattended Call Transfer. Hier besteht bereits eine Session zwischen Alice und Bob, und Alice initiiert nun den Transfer dieser Session zu Bill. Damit soll die Session zwischen Alice und Bob durch die Session zwischen Bob und Bill ersetzt werden. In Abbildung 7.7-7 sind folgende drei Phasen zu unterscheiden: A
Alice leitet den Transfer der Session zu Bill ein Um den Transfer der bereits zu Bob bestehenden Session zu Bill einzuleiten, sendet das IPTelefon von Alice den SIP-Request REFER an das IP-Telefon von Bob, und dieses signalisiert seine Bereitschaft hierzu mit dem SIP-Response 202 Accepted. Mit REFER wird dem IP-Telefon von Bob mitgeteilt, dass die Session zwischen Alice und Bob durch das IPTelefon von Bob auf eine Session zwischen Bob und Bill transferiert werden soll. REFER enthält dafür u.a. folgende Header-Zeilen: Call-ID:y-cid gibt die Identifikation der Session zwischen Alice und Bob an; • • Refer-To:<sip:[email protected]> besagt, dass die neue Session vom Telefon Bobs an den SIP-URI sip:[email protected] – also zu Bill – geführt werden soll;
343
344
7
VoIP mit SIP •
Referred-By:<sip:[email protected]> besagt, dass der Transfer der Session vom SIP-URI sip:[email protected] – also von Alice – initiiert wurde.
Mit dem SIP-Request NOTIFY signalisiert das IP-Telefon von Bob, dass es beginnen wird, eine Session zum IP-Telefon von Bill zu initiieren. Der Empfang von NOTIFY wird seitens des IP-Telefons von Alice mit 200 OK bestätigt. Anschließend leitet das IP-Telefon von Alice mit BYE den Abbau der bestehenden Session zu Bob ein, und dieses quittiert BYE mit 200 OK. Damit wurde die Session zwischen Alice und Bob abgebaut und wird nun durch die Session zwischen Bob und Bill ersetzt.
A lic e
B o b
s ip :a lic e @ a b c .d e
S e s s io n A lic e - B o b
R E F E R A
s ip :b o b @ a b c .d e
[R e fe r-T o : B ill]
2 0 0 O K B Y E
2 0 2 A c c e p te d N O T IF Y
B ill
2 0 0 O K
s ip :b ill@ a b c .d e
IN V IT E
K e in e S e s s io n A lic e - B o b
B
[R e fe rre d -B y : A lic e ]
A C K S e s s io n B o b - B ill
1 8 0 R in g in g 2 0 0 O K
www.wiwobooks.com C
2 0 0 O K
N O T IF Y
Abb. 7.7-7: SIP-Verlauf bei einer Weiterleitung bei Besetzt des Angerufenen CIBF: Call Is Being Forwarded
B
Bob initiiert die Session zu Bill Um eine Session – als Transfer der Session zwischen Alice und Bob – zum IP-Telefon von Bill zu initiieren, sendet das IP-Telefon von Bob den SIP-Request INVITE mit der HeaderZeile Referred-By:<sip:[email protected]>, um darauf zu verweisen, dass der Transfer der Session von Alice eingeleitet wurde. Der weitere SIP-Verlauf beim Aufbau der Session zwischen Bob und Bill erfolgt, wie Abbildung 7.7-7 zeigt.
C
Alice wird über den erfolgreichen Session-Transfer informiert Nachdem der Transfer der Session zu Bill erfolgreich abgeschlossen wurde, informiert das IP-Telefon von Bob das IP-Telefon von Alice mit NOTIFY darüber. Anschließend bestätigt das IP-Telefon von Alice den Empfang von NOTIFY mit 200 OK. Damit wurde die Übergabe der Session vollständig abgeschlossen.
7.7.8 Attended Call Transfer Die Übergabe einer Session bei VoIP an einen dritten Teilnehmer kann erst nach einer Rücksprache – d.h. nach einer Anfrage bei ihm – erfolgen. Ein solches Leistungsmerkmal wird als Attended Call Transfer – kurz Attended CT – bezeichnet. Abbildung 7.7-8 zeigt den SIP-Verlauf bei Attended CT.
7.7 Sessionbezogene Leistungsmerkmale mit SIP
345
In diesem Beispiel wird eine bereits bestehende Session zwischen Alice und Bob von Bob angehalten, um eine Rücksprache mit Bill halten zu können. Dafür wird eine neue Session zwischen Bob und Bill eingerichtet. Nach der Rücksprache mit Bill wird die Session zu ihm von Bob angehalten, um Alice darüber zu informieren, dass die Session zwischen Alice und Bob auf die Session zwischen Alice und Bill transferiert werden soll. Daraufhin initiiert das IPTelefon von Alice eine Session zu Bill. Die Session zwischen Bob und Bill – zur Rücksprache mit Bill – wird nun abgebaut. Über den erfolgreichen Aufbau der Session zwischen Alice und Bill informiert das IP-Telefon von Alice das IP-Telefon von Bob, und dieses leitet den Abbau der noch bestehenden Session zu Alice ein. Mit dem Abbau der Session zwischen Alice und Bob wird der hier beschriebene Session-Transfer abgeschlossen. A lic e
B o b
s ip :a lic e @ a b c .d e
s ip :b o b @ a b c .d e
S e s s io n A lic e - B o b
A
IN V IT E
2 0 0 O K
[a = s e n d o n ly ]
A C K S e s s io n a n g e h a lte n B
S e s s io n w u rd e v o n B o b a n g e h a lte n
B ill
S e s s io n -A u fb a u S e s s io n B o b - B ill S e s s io n w ird a n g e h a lte n
www.wiwobooks.com B o b k ü n d ig t d e n S e s s io n -T ra n s fe r a n
2 0 2 A c c e p te d N O T IF Y D
R E F E R
C
S e s s io n a n g e h a lte n [R e fe r-T o : B ill]
2 0 0 O K
S e s s io n w u rd e v o n B o b a n g e h a lte n
IN V IT E E
2 0 0 O K
A C K
S e s s io n A lic e - B ill F S e s s io n B o b - B ill w ird b e e n d e t G
Abb.7.7-8:
N O T IF Y 2 0 0 O K
B Y E
2 0 0 O K
Attended Call Transfer – Übergabe einer VoIP-Verbindung nach Rücksprache
Der Attended Call Transfer in Abbildung 7.7-8 umfasst folgende Phasen: A
SIP und Attended Um eine Rücksprache mit Bill halten zu können, wird die bestehende Session zu Alice von Call TransBob angehalten. Hierfür sendet das IP-Telefon von Bob an das IP-Telefon von Alice den fer Session zwischen Alice und Bob wird von Bob angehalten
Request INVITE mit der Zeile a=sendonly im Body-Teil. Damit wird dem IP-Telefon von Alice mitgeteilt, dass von Bobs IP-Telefon Musik bzw. eine Ansage gesendet wird. Das IP-Telefon von Alice bestätigt mit 200 OK und anschließend quittiert noch das IP-Telefon
346
7
VoIP mit SIP von Bob das 200 OK mit ACK. Somit wurde die bidirektionale Session zu Alice durch eine unidirektionale, zu Alice gerichtete Session ersetzt.
B
Session zur Rücksprache mit Bill wird aufgebaut
C
Session zu Bill wird angehalten Nach der Rücksprache mit Bill wird die von Bob zu Bill bestehende Session angehalten. Dieser Vorgang verläuft nach dem gleichen, in Phase A erläuterten Prinzip.
D
Alice wird über den Transfer der Session zu Bill informiert Das IP-Telefon von Alice wird vom IP-Telefon Bobs mit dem SIP-Request REFER darüber informiert, dass eine Session – als Session-Transfer gemeint – von Alice zu Bill aufgebaut werden soll. Das IP-Telefon von Alice signalisiert seine Bereitschaft hierzu mit dem SIPResponse 202 Accepted. Dass die Session zwischen Alice und Bob – mit Call-ID gleich z-cid – auf eine Session zwischen Alice und Bill transferiert werden soll, wird in REFER in folgenden Header-Zeilen angegeben: Call-ID:z-cid mit der Identifikation der Session zwischen Alice und Bob, • • Refer-To:<sip:[email protected]> mit der Angabe des Transferziels und Referred-By:<sip:[email protected]> mit der Angabe, wer den Transfer der Session • eingeleitet hat. Mit dem SIP-Request NOTIFY signalisiert das IP-Telefon von Alice, dass es beginnen wird, eine Session zum IP-Telefon von Bill zu initiieren. NOTIFY wird seitens des IP-Telefons von Bob mit 200 OK bestätigt.
E
Aufbau der Session von Alice zu Bill
www.wiwobooks.com
Das IP-Telefon von Alice initiiert mit dem Request INVITE den Aufbau einer Session zu Bill. Diese Session kann als Transfer der Session zwischen Alice und Bob auf die Session zwischen Alice und Bill angesehen werden. F
Abbau der Session zwischen Bob und Bill
G
Bob wird über den erfolgreichen Session-Transfer informiert Nachdem der Transfer der Session von Alice zu Bill erfolgreich abgeschlossen wurde, teilt das IP-Telefon von Alice dies dem IP-Telefon von Bob durch Absenden des Request NOTIFY mit. Das IP-Telefon von Bob bestätigt den Empfang von NOTIFY mit 200 OK. Anschließend leitet es mit dem Request BYE den Abbau der noch zu Alice bestehenden Session ein. Mit dem Abbau der Session zwischen Alice und Bob wurde der hier dargestellte Session-Transfer vollständig abgeschlossen.
7.7.9 SIP-Verlauf bei Rückruf Von großer Bedeutung sind die Leistungsmerkmale Rückruf bei Besetzt bzw. Rückruf bei Nichtmelden des Angerufenen. Bei VoIP mit SIP sind diese Leistungsmerkmale – auch als Call Completion to Busy Subscriber (CCBS) und als Call Completion on No Reply (CCNR) bezeichnet – relativ einfach durch eine kurze Zwischenspeicherung der SIP-Requests INVITE zu realisieren. Um die beiden Leistungsmerkmale CCBS und CCNR zur Verfügung zu stellen, können die ankommenden Anrufe – als Requests INVITE – auf eine Warteliste sowohl im IP-Telefon des Angerufenen als auch im SIP-Proxy bzw. in einem SIPServer eingetragen werden.
7.7 Sessionbezogene Leistungsmerkmale mit SIP
347
Abbildung 7.7-9 illustriert den SIP-Verlauf bei einer Realisierung des Leis- Rückruf bei tungsmerkmals CCBS. Hier versucht Alice eine Session zu Bob aufzubauen, Besetzt während sein IP-Telefon im Zustand besetzt ist. Daher veranlasst Alice, dass ihr das IP-Telefon Bobs anzeigt, wenn es wieder frei ist. Genauer gesagt, hat Alice beim IP-Telefon von Bob das Event call-completion abonniert, sodass ihr signalisiert wird, wann das IP-Telefon von Bob wieder frei ist. Der Anruf von Alice wird nun auf eine Warteliste (Queue) im IP-Telefon Bobs eingetragen. Ist es frei geworden, wird dies dem IP-Telefon von Alice unmittelbar signalisiert und es kann nun mit dem Aufbau einer Session zu Bob beginnen. A lic e
B o b
IN V IT E A
S U B S C R IB E B C
A lic e v e rs u c h t, e in e S e s s io n z u B o b a u fz u b a u e n .
4 8 6 B u sy H e re [E v e n t: c c ]
2 0 0 O K
A lic e h a t d a s E v e n t c a ll-c o m p le tio n a b o n n ie rt.
2 0 0 O K N O T IF Y
B ill v e rs u c h t, e in e S e s s io n z u B o b a u fz u b a u e n .
B ill h a t d a s E v e n t c a llc o m p le tio n a b o n n ie rt.
A *
B
B ill
A n ru f v o n A lic e w u rd e in d ie W a rte lis te e in g e tra g e n .
IN V IT E
*
4 8 6 B u sy H e re
S U B S C R IB E
www.wiwobooks.com A n ru f v o n B ill w u rd e in d ie W a rte lis te e in g e tra g e n .
D E
2 0 0 O K
C
*
2 0 0 O K
N O T IF Y
2 0 0 O K
N O T IF Y
S e s s io n -A u fb a u S e s s io n A lic e - B o b
IP -T e le fo n v o n B o b is t fre i g e w o rd e n .
Abb. 7.7-9: Completion of Calls to Busy Subscriber (CCBS) – Rückruf bei Besetzt cc: call-completion
Die einzelnen Phasen beim SIP-Verlauf in Abbildung 7.7-9 sind wie folgt zu interpretieren: A
Alice versucht eine Session zu Bob zu initiieren Das IP-Telefon von Alice initiiert eine Session zu Bob durch Absenden des SIP-Request INVITE, während das IP-Telefon von Bob besetzt ist. Der Zustand Besetzt wird dem IPTelefon von Alice mit dem SIP-Response 486 Here Busy angezeigt.
B
Alice veranlasst, dass ihr der Zustand frei des IP-Telefons von Bob angezeigt wird Hierfür sendet das IP-Telefon von Alice den SIP-Request SUBSCRIBE, in dem die HeaderZeile Event: call-completion darauf verweist, dass das IP-Telefon von Alice das Event call-completion abonnieren möchte. Dies akzeptiert das IP-Telefon Bobs und wird vom IP-Telefon von Alice mit 200 OK bestätigt.
C
Der Anruf von Alice wurde im IP-Telefon Bobs in die Warteliste eingetragen. Dies wird dem IP-Telefon von Alice vom IP-Telefon Bobs mit dem Request NOTIFY mitgeteilt. Der Empfang von NOTIFY wird seitens Alice mit 200 OK bestätigt. Sollte das IPTelefon von Bob wieder frei werden, wird dies dem Telefon von Alice sofort signalisiert.
SIP-Verlauf bei CCBS
348
7
VoIP mit SIP Bemerkung: Sollte der Benutzer Bill versuchen, eine Session zu Bob aufzubauen, wird sein Anruf ebenso auf die Warteliste im IP-Telefon von Bob eingetragen. In Abbildung 7.7-9 bringen dies die Phasen A*, B* und C* zum Ausdruck.
D
Der Zustand frei des IP-Telefons von Bob wird bei Alice angezeigt Dies erfolgt mit NOTIFY. Das IP-Telefon von Alice bestätigt NOTIFY mit 200 OK.
E
Das IP-Telefon von Alice initiiert den Aufbau einer Session zu Bob Nachdem – in der Phase D – dem IP-Telefon von Alice der Zustand frei des IP-Telefons von Bob angezeigt wurde, beginnt es mit dem Aufbau einer Session zu Bob.
7.8
Um die Mobilität von Benutzern bei SIP zu unterstützen, können die Anrufe mit Hilfe von Proxy-Servern weitergeleitet werden. Dies wurde z.B. in den Abbildungen 7.1-6 und 7.2-2 näher erläutert. Die Signalisierung zwischen zwei Benutzern kann daher über mehrere Proxy-Server verlaufen. Um zu garantieren, dass ein Response auf einen Request über die gleichen Proxy-Server wie der Request übermittelt wird, muss er entsprechend geroutet werden. Man spricht in diesem Fall von Response-Routing, was mit Hilfe des Header-Felds Via unterstützt wird. Abbildung 7.8-1 veranschaulicht das Response-Routing.
www.wiwobooks.com
s o n n e .a b c .d e
I N V I T E ...
P S 1 p s 1 .a b c .d e
V ia : s o n n e .a b c .d e
1 8 0 R in g in g
V ia : s o n n e .a b c .d e
I N V I T E ...
P S 2
V ia : p s 1 .a b c .d e V ia : s o n n e .a b c .d e
x y z .d e
P S 3
m o n d .x y z .d e
p s 3 .x y z .d e
p s 2 .p r s .d e
V ia : p s 1 .a b c .d e V ia : s o n n e .a b c .d e
1 8 0 R in g in g
p r s .d e I N V I T E ...
V ia : p s 2 .p r s .d e V ia : p s 1 .a b c .d e V ia : s o n n e .a b c .d e
1 8 0 R in g in g
V ia : p s 2 .p r s .d e V ia : p s 1 .a b c .d e V ia : s o n n e .a b c .d e
I N V I T E ... V ia V ia V ia V ia
: p s : p s : p s : so
3 .x y z .d e 2 .p r s .d e 1 .a b c .d e n n e .a b c .d e
1 8 0 R in g in g V ia V ia V ia V ia
: p s : p s : p s : so
3 .x y z .d e 2 .p r s .d e 1 .a b c .d e n n e .a b c .d e
s ip :b o b @ x y z .d e
a b c .d e
s ip :a lic e @ a b c .d e
Response Routing mit Via
Response- und Request-Routing
Abb. 7.8-1: Veranschaulichung von Response-Routing
Jeder Absender von Request INVITE fügt ein Header-Feld Via mit seinem vollständigen Hostnamen hinzu – siehe hierfür Abbildung 7.1-9. Somit enthält INVITE am Ziel eine Auflistung aller Absender in der Reihenfolge, in der die Nachricht INVITE von ihnen abgeschickt wurde. Diese Auflistung stellt eine Route dar und wird in den Response (hier 180 Ringing) auf INVITE kopiert (vgl. Abbildung 7.1-10). Der Response enthält somit die Hostnamen aller Systeme, über die er übermittelt wird. Die Ermittlung der IP-Adressen seines Systems (sog. Host), falls sein Name bekannt ist, erfolgt mit Hilfe von DNS (s. Ab-
7.8 Response- und Request-Routing
349
schnitt 3.5). Das Feld Via enthält auch den Namen des Transportprotokolls und die SIP-Version (s. Abb. 7.1-9). Diese Angaben wurden in Abbildung 7.8-1 außer Acht gelassen. In einigen Situationen wird verlangt, dass die Signalisierung über bestimmte Proxy-Server verläuft, z.B. über Proxy-Server, die zusätzlich eine FirewallFunktion realisieren. Ein Proxy-Server kann so konfiguriert werden, dass er in einen weiterzuleitenden Request INVITE ein Header-Feld Record-Route mit seinem Namen hinzufügt, um darauf zu verweisen, dass die Signalisierung über ihn verlaufen muss. Abbildung 7.8-2 illustriert dies näher.
P S 1
s ip :a lic e @ a b c .d e
I N V I T E ...
I N V I T E ... R -R : P S 1
1 8 0 R in g in g ... C o n ta c t: T ln B R -R : P S 3 R -R : P S 1
x y z .d e
P S 3
I N V I T E ... R -R : P S 1
1 8 0 R in g in g ... 2 0 0 O K
C o n ta c t: T ln B R -R : P S 3 R -R : P S 1
A C K P S 3
I N V I T E ... R -R : P S 3 R -R : P S 1
1 8 0 R in g in g ...
2 0 0 O K
C o n ta c t: T ln B R -R : P S 3 R -R : P S 1
A C K T ln B
R : T ln B
R T P -S e s s io n (V o IP -V e rb in d u n g ) B Y E P S 3
B Y E P S 1
R : R o u te
C o n ta c t: T ln B R -R : P S 3 R -R : P S 1
p r s .d e
www.wiwobooks.com
R : P S 3 R : T ln B
R : P S 3 , T ln B
1 8 0 R in g in g ... 2 0 0 O K
2 0 0 O K
A C K P S 1
P S 2
RecordRoute
s ip :b o b @ x y z .d e
a b c .d e
Bedeutung von
2 0 0 O K
R : T ln B
2 0 0 O K
B Y E T ln B 2 0 0 O K
R -R : R e c o rd -R o u te
Abb. 7.8-2: Bedeutung von Record-Route und Nutzung von Route bei Request-Routing PS: Proxy-Server
Hier soll die Signalisierung immer über den Proxy-Server PS1 der Domain Requestabc.de und über Proxy-Server PS3 der Domain xyz.de verlaufen. Somit Routing mit fügt jeder dieser Server in INVITE ein Header-Feld Record-Route mit sei- Route nem Hostnamen hinzu. Die Header-Felder Record-Route aus dem Request INVITE werden im gerufenen IP-Telefon in den Response auf INVITE kopiert und an das rufende IP-Telefon zurückgesendet. Die nächsten Requests werden damit nur über diese Proxy-Server übermittelt, die sich in INVITE mit Record-Route „gemeldet“ haben. Man spricht in diesem Fall von RequestRouting. Um das Request-Routing zu realisieren, wird das Header-Feld Route verwendet. Wie in Abbildung 7.8-2 am Beispiel des Request ACK ersichtlich ist, wird das erste Ziel (PS1) mit URI in der Request-Line angegeben (s. Abb. 7.3-1). Die weiteren Proxy-Server, über die ACK übermittelt werden muss, werden in
350
7
VoIP mit SIP
den einzelnen Header-Feldern Route angegeben. Der Proxy-Server muss den URI in der Request-Line jeweils vor dem Absenden des Request neu setzen. Abbildung 7.8-2 zeigt nur das Prinzip von Request-Routing. Auf die Darstellung der Formate der Felder Record-Route und Route wurde hier verzichtet. Für detaillierte Informationen sei auf RFC 3261 verwiesen.
7.9
Konvergenz der IP-Netze und ISDN
Wie in Abschnitt 2.2 gezeigt wurde, verwendet man für die Signalisierung der Anrufe zwischen Endeinrichtungen am ISDN und Teilnehmervermittlungsstellen das D-Kanal-Protokoll. In privaten ISDN-Systemen, d.h. in den sog. ISDN-TK-Anlagen, werden die Verbindungen ebenfalls nach dem D-Kanal-Protokoll auf- und abgebaut. Eine wichtige Stärke von SIP ist, dass der SIPVerlauf weitgehend dem Verlauf des D-Kanal-Protokolls entspricht. Dadurch können die Requests und Responses von SIP auf die Nachrichten des D-Kanal-Protokolls abgebildet werden. Dies vereinfacht die Integration von VoIP-Systemen mit klassischen ISDN-TK-Anlagen. Abbildung 7.9-1 zeigt die Abbildung des D-Kanal-Protokolls auf SIP. Noch detaillierter wird sie in Abbildung 7.9-3 dargestellt. Weil das klassische ISDN-Telefon nur ISDN-Rufnummern akzeptiert, kann in diesem Fall nur eine besondere Form von SIP-URIs zum Einsatz kommen.
www.wiwobooks.com ... ...
0 6 9 x x x x y y y y
IS D N T K A n la g e
V G
IP -N e tz ( x y z .d e )
D -K a n a l-P ro to k o ll
S IP
IS D N -V e rb in d u n g
V o IP -S e s s io n
9 6 4 0 4 5 4 8 9 6 4 0 4 5 3 2
s ip :9 6 4 0 4 5 3 2 @ x y z .d e
Abb. 7.9-1: ISDN-Konvergenz mit einem IP-Netz, falls das IP-Netz eine Domain bildet VG: VoIP-Gateway
IP-Telefon hat eine TelefonNummer
Jeder SIP-URI, der einem IP-Telefon zugeordnet wird, kann sich aus einer Telefonnummer und aus dem Domainnamen, wie z.B. [email protected], zusammensetzen (s. Abb. 7.1-2). Somit ist ein IP-Telefon von jedem Telefon am ISDN aus adressierbar. Falls alle IP-Telefone sich innerhalb einer Domain befinden, ist es ausreichend, nur den ersten Teil (d.h. nur die Telefonnummer) der SIP-Adresse im Telefonapparat an der ISDN-TK-Anlage anzugeben, um das IP-Telefon am IP-Netz eindeutig zu lokalisieren. Wie aus Abbildung 7.9-1 ersichtlich ist, wird hier eine ISDN-Verbindung – logisch gesehen – mit der VoIP-Session über das IP-Netz bis zum IP-Telefon verlängert. Es kann auch vorkommen, dass die IP-Telefone sich in unterschiedlichen Domains befinden. Dies illustriert Abbildung 7.9-2.
7.9 Konvergenz der IP-Netze und ISDN
IS D N T K A n la g e
... ...
0 6 9 x x x x y y y y
V G
IP -N e tz
D -K a n a l-P ro to k o ll
a b c .d e x y z .d e
S IP V o IP -S e s s io n
IS D N -V e rb in d u n g
351
x x -9 6 4 0 4 5 4 8
y y -9 6 4 0 4 5 3 2 s ip :9 6 4 0 4 5 3 2 @ x y z .d e
x x ( y y ) : V o r w a h l d e r D o m ä n e a b c .d e ( x y z .d e )
Abb. 7.9-2: ISDN-Konvergenz mit einem IP-Netz, falls das IP-Netz mehrere Domains enthält VG: VoIP-Gateway
Falls sich die IP-Telefone in unterschiedlichen Domains befinden, kann man jeder Domain eine eindeutige Vorwahl – also Vorwahl Domainname – zuordnen. Hierfür muss das VoIPGateway in der Lage sein, die IP-Adresse des Proxy-Servers der entsprechenden Domain zu ermitteln. Wie dies geschieht, wurde in Abschnitt 3.5.4 dargestellt (s. Abb. 3.5-6). Es ist hervorzuheben, dass das in den Abbildungen 7.9-1 und -2 gezeigte IP-Netz eine verteilte IP-TK-Anlage darstellen kann (vgl. Abb. 1.2-7). Die gezeigten Beispiele sollen verdeutlichen, dass die Integration von bestehenden privaten ISDN-TK-Anlagen mit den IP-TK-Anlagen mit SIP-Hilfe realisierbar ist.
Ermittlung entsprechender Domain
www.wiwobooks.com
7.9.1 SIP und das D-Kanal-Protokoll
Eine Stärke von SIP besteht darin, dass es einfach auf das D-Kanal-Protokoll abgebildet werden kann. Abbildung 7.9-3 illustriert dies am Beispiel der Anbindung einer ISDN-TK-Anlage an ein IP-Netz. Hier soll eine Verbindung für die Sprachkommunikation zwischen einem IP-Telefon am IP-Netz und einem Telefon an der ISDN-TK-Anlage aufgebaut werden (vgl. Abb. 2.3-3).
In te rn e t (IP -N e tz ) IN V IT E 1 8 0 R in g in g A C K
1 0 0 T ry in g 2 0 0 O K
V o IP -S e s s io n B Y E
2 0 0 O K S IP
V G
IS D N T K A n la g e S E T U P
C O N N A C K
A L E R T C O N N
IS D N -V e rb in d u n g D IS C R E L R E L A C K D -K a n a l-P ro to k o ll
Abb. 7.9-3: Abbildung von SIP auf das D-Kanal-Protokoll VG: VoIP-Gateway
Den Aufbau einer Verbindung initiiert das IP-Telefon am IP-Netz durch Absenden des Request INVITE. Dieser Request wird im VoIP-Gateway an der Grenze zwischen dem IP-Netz und der ISDN-TK-Anlage in die Nachricht SETUP des D-Kanal-Protokolls umgesetzt.
INVITE auf SETUP
352
7
VoIP mit SIP
180 Ringing auf ALERT
Nach dem Empfang von SETUP sendet das ISDN-Telefon die Antwort ALERT(ing). Damit signalisiert es dem VG, dass es bei ihm klingelt. Beim VG wird ALERT auf den SIP-Response 180 Ringing abgebildet.
200 OK auf CONN
Wird der Hörer des ISDN-Telefons abgenommen, sendet es die Antwort CONN(ect), und diese wird im VG auf den SIP-Response 200 OK umgesetzt. Die SIP-Bestätigung ACK wird auf CONN ACK abgebildet. Nach dem Empfang von ACK im VG wird der Verbindungsaufbau beendet. Nach dem Eintreffen der Nachricht CONN ACK beim ISDN-Telefon steht eine ISDN-Verbindung zwischen dem ISDN-Telefon und dem VG zur Verfügung. Die VoIP-Verbindung zwischen IPTelefon und ISDN-Telefon setzt sich aus einer Session über das IP-Netz und aus einer ISDNVerbindung im ISDN-Bereich zusammen.
BYE auf DISC
In Abbildung 7.9-3 initiiert das IP-Telefon den Abbau der Session durch Absenden des Request BYE, der im VG auf die Nachricht DISC(onnect) vom D-Kanal-Protokoll abgebildet wird. Der Empfang von DISC wird mit der Nachricht REL(ease) bestätigt, die im VG auf den SIP-Response 200 OK umgesetzt wird. Nach dem D-Kanal-Protokoll muss der Empfang von REL mit der Nachricht REL COM(plete) bestätigt werden. Damit wird der Abbau einer ISDN-Verbindung beendet. Die Nachricht REL kann auf die SIP-Antwort 200 OK abgebildet werden. Weil der SIP-Verlauf weitgehend dem Verlauf des D-Kanal-Protokolls im ISDN entspricht, erleichtert dies die Integration von IP-Netzen mit den ISDN-Systemen für die VoIP-Anwendungen. Die in Abbildung 7.9-3 dargestellte Systemlösung kann auch die Vernetzung einer IP-TK-Anlage mit einer klassischen ISDN-TK-Anlage darstellen.
www.wiwobooks.com
7.9.2 SIP und Signalisierungssystem Nr. 7
Das Signalisierungssystem Nr. 7 (Signalling System No. 7, kurz SS7) stellt ein Protokollsystem dar, nach dem die Signalisierung zwischen Vermittlungsstellen im digitalen PSTN (Public Switched Telephone Network) und im ISDN verläuft (s. Abschnitt 2.4). Bei der Integration des PSTN/ISDN mit IP-Netzen wird SIP auf SS7 abgebildet. Abbildung 7.9-4 veranschaulicht dies.
In te rn e t (IP -N e tz ) IN V IT E
A C K
1 0 0 T ry in g 1 8 0 R in g in g 2 0 0 O K
N Ü
IS D N IA M A N S
S e s s io n
A C M
S E T U P C O N N A C K
A L E R T C O N N
IS D N -V e rb in d u n g
B Y E 2 0 0 O K S IP
V S t
R E L
R L C S S 7
D IS C R E L C O M
R E L
D -K a n a l-P ro to k o ll
Abb. 7.9-4: Abbildung von SIP auf SS7 (vgl. Abb. 2.2-1 und 2.3-3) NÜ: Netzübergang, ACM: Address Complete Message, ANS: Answer Message, IAM: Initial Address Message, REL: Release, RLC: Release Complete
Da SS7 auch in GSM-basierten Mobilfunknetzen eingesetzt wird, stellt die hier dargestellte Abbildung zwischen SIP und SS7 ein Beispiel dafür dar, wie Verbindungen zwischen Teilnehmern an Mobilfunknetzen und IP-Telefonen an IP-Netzen zustande kommen.
7.10 Koexistenz von SIP und H.323 Der Abbildung von SIP auf SS7 werden mehrere IETF-Dokumente gewidmet. Insbesondere ist hier zu verweisen auf: RFC 3372 – für die Beschreibung der logischen Systemarchitektur und der SIP-Abläufe für die Integration von SS7 mit VoIP-Systemen mit SIP; RFC 3398 – für die Abbildung von SIP auf ISUP von SS7 (s. Abb. 2.4-3). In RFC 3666 werden mehrere Beispiele für den SIP-Verlauf bei der Integration der VoIPSysteme mit ISDN/PSTN gezeigt. Diese Beispiele sind auch abrufbar unter der Web-Adresse http://www.tech-invite.com/Ti-sip-CF3666.html
7.10 Koexistenz von SIP und H.323 Mit SIP und H.323 stehen zwei konkurrierende Ansätze für die Signalisierung bei VoIP zur Verfügung. Die Signalisierung nach H.323 kann im Allgemeinen als Implementierung der Schicht-3 des D-Kanal-Protokolls über TCP-Verbindungen angesehen werden. Weil das D-Kanal-Protokoll auf SIP abgebildet werden kann (s. Abb. 7.9-3), ist eine Koexistenz von H.323 und SIP ebenfalls möglich. Abbildung 7.10-1 zeigt, wie sich die H.323-Signalisierung ohne Fast Connect Procedure (FCP) auf SIP abbilden lässt, falls der Anruf von der H.323-Seite initiiert wird.
IP -N e tz H .3 2 3
G K
R
IP -N e tz S IP
P S
www.wiwobooks.com
A R Q
H .2 2 5 .0
H .2 4 5
A C F A n ru f-S IG -K a n a l S e tu p C a ll P ro c e e d in g A le rtin g C o n n e c t H .2 4 5 - S te u e r u n g s k a n a l T C S & M S D T C S & M S D T C S A c k & M S D A c k T C S A c k & M S D A c k O L C O L C O L C A c k O L C A c k
IN V IT E
1 8 0 R in g in g 2 0 0 O K
H .3 2 3 /S I P T ra n s la to r
A C K
S e s s io n (V o IP -V e rb in d u n g ) H .2 4 5 H .2 2 5 .0
C L C C L C A c k
C L C C L C A c k R e le a s e C o m p le te
B Y E
2 0 0 O K
Abb. 7.10-1: Abbildung der H.323-Signalisierung ohne Fast Connect Procedure auf SIP, s. Abb. 6.5-8: Initiieren der Session seitens H.323 GK: Gatekeeper, PS: (SIP) Proxy-Server
Der hier gezeigte Verlauf der H.323-Signalisierung wurde bereits in Abbildung 6.5-8 dargestellt und in Abschnitt 6.5 näher erläutert. Der Anruf-SIG-Kanal stellt eine TCP-Verbindung dar, und die Nachrichten des Protokolls H.225.0 entsprechen weitgehend den Nachrichten des D-Kanal-
353
354
7
VoIP mit SIP
Protokolls. Somit wird die H.225-0-Nachricht Setup auf den SIP-Request INVITE und entsprechend die SIP-Responses 180 Ringing und 200 OK auf Alerting und Connect von H.225.0 abgebildet (vgl. Abb. 7.9-3). Das Ende des Aufbaus einer Session wird von H.323 mit der H.245-Nachricht OLCAck (s. Abb. 6.5-5) und von SIP mit ACK signalisiert. Der Abbau der Session verläuft seitens H.323 nach dem Protokoll H.245 (s. Abb. 6.5-6). Das Ende des Abbaus nach H.245 wird von SIP mit dem Request BYE initiiert. BYE wird mit 200 OK bestätigt und 200 OK auf die H.225.0-Nachricht Release Complete umgesetzt. Abbildung 7.10-2 zeigt, wie die H.323-Signalisierung auf SIP abgebildet werden kann, falls der Anruf von der SIP-Seite initiiert wird.
IP -N e tz H .3 2 3
H .2 2 5 .0
C a ll P ro c e e d in g A R Q A C F A le rtin g C o n n e c t H .2 4 5 - S te u e r u n T C T C S & M S D T C S A c k & T C S A c k & M S D A
G K R
IP -N e tz S IP
P S
S e tu p
IN V IT E
1 8 0 R in g in g g sk a n a l S & M S D M S D A c k c k O L C
www.wiwobooks.com H .2 4 5
O L C O L C A c k
H .2 4 5 H .2 2 5 .0
C L C C L C A c k
H .3 2 3 /S I P T ra n s la to r
O L C A c k S e s s io n (V o IP -V e rb in d u n g )
2 0 0 O K
A C K
C L C C L C A c k R e le a s e C o m p le te
B Y E
2 0 0 O K
Abb. 7.10-2: Abbildung der H.323-Signalisierung ohne Fast Connect Procedure auf SIP, s. Abb. 6.5-8: Initiieren der Session seitens SIP GK: Gatekeeper, PS: SIP-Proxy-Server
Hier wurde gezeigt, dass die VoIP-Kommunikation z.B. zwischen zwei Unternehmen auch dann stattfinden kann, wenn in einem von ihnen SIP und im anderen H.323 als Signalisierungsprotokoll verwendet wird. Hier können H.323-Gatekeeper und SIP-Proxy-Server als H.323/SIPTranslator dienen. H.323 und SIP sind zwar konkurrierende Ansätze für die Signalisierung in VoIP-Systemen, aber wie hier gezeigt wurde, können sie sich auch gegenseitig ergänzen. Es ist zu erwarten, dass SIP in IP-Weitverkehrsnetzen künftig eine wichtige Rolle spielt. Auf dem Markt sind verschiedene H.323/SIP-Gateways verfügbar, um die H.323-basierten VoIP-Systeme standortübergreifend über ein IP-Netz mit SIP vernetzen zu können. Bemerkung: Verwendet H.323 die Fast Connect Procedure, werden die H.245Nachrichten in H.225.0-Nachrichten übermittelt. Damit vereinfacht sich die Abbildung der H.323-Signalisierung auf SIP.
7.11 Schlussbemerkungen
355
7.11 Schlussbemerkungen SIP ist ein Protokoll, nach dem diverse Verbindungsarten für multimediale Kommunikation über das Internet und andere IP-Netze und somit auch für VoIP auf- und abgebaut werden können. Hierbei sind außerdem folgende Aspekte hervorzuheben: Als SIP im März 1999 in RFC 2543 veröffentlicht wurde, konnten seine Entwickler nicht einmal davon träumen, dass es einer so breiten Palette unterschiedlicher multimedialer Anwendungen zugrunde liegen wird. Schon im Juni 2002 wurde eine neue erweiterte SIPSpezifikation als RFC 3261 spezifiziert. Inzwischen ist eine Reihe weiterer, SIP-betreffender Internet-Standards hinzugekommen. Neben HTTP ist SIP heute das zweitwichtigste Anwendungsprotokoll im Internet. Zurzeit (Dezember 2009) gibt es bereits über hundert SIP-relevante Internet-Dokumente.
Rasante SIPEntwicklung
Der Einsatzradius von SIP ist so groß, dass dieses Protokoll ständig weiterentwickelt wird. Dies führt u.a. zur Entstehung neuer SIP-Funktionen. Wie Abbildung 7.11-1 zeigt, lassen sich diverse Anwendungs- und Problembereiche zu einer „SIP-Uhr“ zusammenfassen.
Anwendungs- und Problemgebiete von SIP
M u ltim e d ia le K o n fe re n z e n R e a lis ie ru n g d e r N o tru fd ie n s te 1 1
S ic h e rh e its m e c h a n is m e n fü r S IP
1 0
B e s c h re ib u n g d e r S e s s io n u n d F o rm a te
1 2 1
S IP K e r n k o n z e p t
A llg e m e in e S IP -E rw e ite ru n g e n 2
www.wiwobooks.com
E v e n t N o tific a tio n F ra m e w o rk
Z u s ä tz lic h e N u tz u n g v o n S IP U R Is
L ö s u n g e n fü r P ro b le m e b e i S IP m it N A T
9
8
7
R F C 3 2 6 1
3
6
5
4
V e rs c h ie d e n e D ie n s tm e rk m a le
G a ra n tie v o n Q u a lity o f S e rv ic e
In s ta n t M e s s a g in g u n d P re s e n c e S e rv ic e s
In te rn e t-In te ro p e ra b ilitä t m it P S T N /IS D N
Abb. 7.11-1: SIP-Uhr als Auflistung der Anwendungs- und Problemgebiete von SIP Weil VoIP mit SIP multimediale Kommunikation ermöglicht, versucht man VoIP in Geschäftsprozesse und Web-Services einzubeziehen. Dadurch können intelligente Lösungen für E-Commerce, Help-Desk-Systeme und Call-Center angeboten werden. Hierfür ist eine zentrale Systemkomponente – die sog. Third Party – für den Auf- und Abbau von Sessions erforderlich. Man spricht in diesem Zusammenhang von Third Party Call Control – kurz 3PCC. Das Konzept von 3PCC kann als Grundlage für den Aufbau von CTI-Systemen (Computer Telephony Integration) der Next Generation dienen – siehe RFC 3725. Eine wichtige Anwendung von 3PCC ist Click-to-Dial auf Web-Seiten. Bild 2 illustriert das Konzept dieser Anwendung. Hier besteht eine HTTP-Session zwischen dem Rechner eines Kunden und dem Web-Server eines E-Commerce-Geschäfts. Der Kunde besucht eine Webseite, trägt dort seine SIP-URI ein, klickt einen entsprechenden Button an und bewirkt damit, dass ein Controller in der Domain xyz.com zwischen ihm und dem zuständigen Kundenbetreuer – als Agent bezeichnet – eine Session für audiovisuelle Kommunikation aufzubauen beginnt. Nun können sich beide – bezogen auf die Inhalte der Web-Seite – unterhalten und parallel dazu eventuell zusätzliche Informationen z.B. als Video austauschen.
Third Party Call Control
356
7
VoIP mit SIP
K u n d e IP T e le fo n
a b c .d e
x y z .c o m
In te rn e t
W e b -B ro w se r
W e b S e rv e r
H T T P -S e s s io n
S e s s io n -A u fb a u T e il A
IN V IT E
E -C o m m e rc e -G e sc h ä ft
A g e n t
C o n tro lle r S e s s io n -A u fb a u T e il B
IN V IT E
S e s s io n : K u n d e -A g e n t Abb. 7.11-2: Beispiel für einen Einsatz von 3PCC bei E-Commerce – Click-to-Dial
Peer-to-Peer SIP
Den heutigen Rechnernetzen liegt die logische Client/Server-Architektur zugrunde. Auf ihrer Basis ist es schwer, die Systemlösungen zu entwickeln, sodass alle Rechner miteinander spontan, ohne Server in Anspruch zu nehmen, kommunizieren können. Solche Systemlösungen setzen aber die sog. P2P-Architekturen (Peer-to-Peer) voraus (also serverlose). Insbesondere bei VoIP gewinnen die P2P-Architekturen enorm an Bedeutung; Skype ist ein Beispiel. Um VoIP mit SIP in P2P-Netzwerken einfach realisieren zu können, wird Peer-to-Peer SIP (P2PSIP) entwickelt – siehe http://www.p2psip.org. Dem allgemeinen Konzept von P2PSIP wurden bereits mehrere Internet-Drafts gewidmet. Abbildung 7.11-3 illustriert grundlegende Ideen von SIP und P2PSIP. SIP stellt eine DNSbasierte Systemlösung dar. Bei P2PSIP werden keine Proxies eingesetzt, und DNS spielt keine große Rolle. Die IP-Telefone bzw. auch andere Endgeräte werden an spezielle Rechner – die als Knoten in einem logischen P2PSIP-Overlay-Netz fungieren – virtuell angebunden.
www.wiwobooks.com b )
a ) S P S P
D N S
In te r n e t
In te r n e t
S P
IP -N e tz S P : S IP -P ro x y
P e e r-K n o te n P 2 P S IP -O v e rla y -N e tz
Abb. 7.11-3: Grundlegende Ideen: a) des herkömmlichen SIP; b) des P2PSIP Die Kernkomponente von P2PSIP stellt das logische Overlay-Netz dar, das als virtuelles und verteiltes SIP-Proxy gelten kann. Die wichtigste Topologie des Overlay-Netzes ist die Ringstruktur, in der jeder Peer-Knoten eine eindeutige Identifikation (ID) besitzt. Diese ID wird als Wert einer Hashfunktion H berechnet. Als Argument dieser Funktion kann die IP-Adresse des Rechners genommen werden – d.h. ID = H(IP-Adresse). Weil die Hashfunktion die Eigenschaft hat, dass es keine zwei Argumente gibt, die zum gleichen Hashwert führen, kann man sicher sein, dass die IDs von Peer-Knoten eindeutig sind. Das Overlay-Netz organisiert sich selbst. Hierfür wird das sog. Peer-Protokoll bei P2PSIP definiert, nach dem die Peer-Knoten bestimmte Nachrichten miteinander austauschen, um das Overlay-Netz einzurichten, zu verwalten und spezielle Routing-Funktionen durchzuführen. P2PSIP ist ein Framework, zu dem mehrere Protokolle gehören. Folgende Protokolle wurden bereits vorgeschlagen: P2PP (Peer-to-Peer Protocol), RELOAD (REsource LOcation And Discovery) und SER (Service Extensible Protocol).
8
VoIP-Gateways: Konzepte und Protokolle
Um zu garantieren, dass ein Teilnehmer mit einem klassischen Telefon am Telefonnetz einen Teilnehmer mit einem IP-Telefon an einem IP-Netz (z.B. am öffentlichen Internet) anrufen kann, müssen die bereits vorhandenen Systemkomponenten und Netze für die Sprachkommunikation mit IP-Netzen entsprechend integriert werden. Hierfür müssen spezielle VoIP-Gateways – auch als Media Gateways bezeichnet – eingerichtet werden.
Notwendigkeit von VoIPGateways
Bei der Vernetzung herkömmlicher Komponenten für die Sprachkommunika- Media tion über ein IP-Netz müssen virtuelle Verbindungen zwischen Media Gate- Gateway ways auf- und abgebaut werden. Hierfür benötigt man spezielle Protokolle, die Protokolle man auch als Media Gateway-Protokolle bezeichnet. Es stehen bereits zwei derartige Protokolle zur Verfügung, nämlich MGCP (Media Gateway Control Protocol) von der IETF und Megaco (Media Gateway Control), das gemeinsam von der IETF und der ITU-T spezifiziert wurde.
www.wiwobooks.com
Die Media Gateways mit ihren Protokollen sind die wichtigsten Bestandteile von Gateway-Plattformen bzw. sog. Softswitches (s. Abschnitt 1.4.3), die bei der Migration zu Next Generation Networks von großer Bedeutung sind. Dieses Kapitel vermittelt die Grundlagen für die Integration von Systemkom- Kapitelponenten und Netzen für die Sprachkommunikation mit IP-Netzen. Nach der überblick Einführung in diese Thematik in Abschnitt 8.1 zeigt Abschnitt 8.2 das Konzept von MGCP in komprimierter Form und präsentiert typische Abläufe von MGCP. Dem Protokoll Megaco wird Abschnitt 8.3 gewidmet. Dieses Kapitel gibt Antworten u.a. auf folgende Fragen:
Ziel dieses Wie integriert man die klassischen Komponenten und Netze für die Sprach- Kapitels
kommunikation mit IP-Netzen (wie z.B. mit Internet)? Welche Funktionen haben die Protokolle für die Steuerung von Media Gateways? Wie wird das Protokoll MGCP konzipiert, und wie werden die Verbindungen mit Hilfe von MGCP auf- und abgebaut? Was ist Megaco, wie funktioniert es, und wie setzt man es ein? Wie entsteht eine netzwerkbasierte IP-TK-Anlage, und welche Funktionen übernehmen hierbei Media Gateways und MGCP bzw. Megaco?
358
8
VoIP-Gateways: Konzepte und Protokolle
8.1
VoIP und klassische Systeme für Sprachkommunikation
Media Gateways (MG)
Die Migration zum VoIP-Einsatz verlangt, dass die bereits vorhandenen Systemkomponenten für die Sprachkommunikation mit einem IP-Netz (z.B. Internet, Intranet) sinnvoll integriert werden müssen. Hierfür spezifiziert man bestimmte Arten von VoIP-Gateways – oft als Media Gateways bzw. kurz Gateways bezeichnet. Um sämtliche Systeme und Netze, die bereits zur Sprachkommunikation verwendet werden, mit IP-Netzen zu integrieren, setzt man unterschiedliche Arten von Media Gateways ein.
Typen von Media Gateways
Die wichtigsten Typen von Media Gateways zeigt Abbildung 8.1-1. T ru n k in g G a te w a y
a ) IP -N e tz
R e s id e n tia l G a te w a y
b ) IP -N e tz
P S T N /IS D N
6
A c c e ss G a te w a y
c ) IP -N e tz
T K A n la g e
www.wiwobooks.com
Abb. 8.1-1: Typen von Media Gateways: a) Trunking Gateway; b) Residential Gateway; c) Access Gateway
Wie hier ersichtlich ist, gehören zu den Media Gateways: Trunking Gateways, um IP-Netze mit dem PSTN (Public Switched Telephone Network) bzw. ISDN zu integrieren; Residential Gateways, um die klassischen Telefone an ein IP-Netz anschließen zu können. Diese Gateways stellen die Schnittstellen zum Anschluss analoger Telefone an IP-Netze zu Verfügung; Access Gateways für den Anschluss klassischer TK-Anlagen an IP-Netze mit VoIP-Unterstützung. Ein Media Gateway (MG) stellt eine Komponente zwischen einem IP-Netz und einem klassischen System bzw. Endgerät für die Sprachkommunikation dar. Ein MG hat u.a. die Aufgabe, bei der Sprachübermittlung in Richtung des IPNetzes die Sprachsignale zu codieren und sie in IP-Pakete zu „verpacken“ und bei der Übermittlung von Sprache in der Gegenrichtung aus den empfangenen IP-Paketen die entsprechenden Sprachsignale zu generieren. MGProtokolle
Für die Sprachübermittlung über ein IP-Netz muss eine Session (s. Abb. 5.2-1) zwischen zwei MGs auf- und abgebaut werden. Eine Ansteuerung von MGs erfolgt mit Hilfe spezieller Kontrolleinheiten. Eine derartige Kontrolleinheit bezeichnet man als Media Gateway Controller (MGC). Die Übermittlung der
8.1 VoIP und klassische Systeme für Sprachkommunikation
359
Steuerung zwischen MG und MGC muss nach einem MG-Protokoll erfolgen – vergleiche auch Abbildung 1.4-7. Hierfür stehen die folgenden Protokolle zur Verfügung: MGCP (Media Gateway Control Protocol) und Megaco (Media Gateway Control). Abbildung 8.1-2 illustriert die Aufgabe eines MG-Protokolls. Ein MG kann als Aufgabe eine Komponente angesehen werden, die es ermöglicht, die klassischen Kom- eines MGponenten für die Sprachkommunikation (wie z.B. Telefone, TK-Anlagen) an Protokolls ein IP-Netz mit VoIP-Unterstützung anzuschließen. a )
M G -P ro t
M G 6
...
V o IP -S e rv e r M G -P ro t M G C IP -N e tz S e s s io n s
b ) M G -P ro t M G
M G 6
S IP
M G C
M G C
IP -N e tz S e s s io n s
...
M G -P ro t M G
T K A n l.
6
Abb. 8.1-2: Veranschaulichung der Aufgaben eines MG-Protokolls: a) Einsatz eines MGC; b) Einsatz mehrerer MGCs MG-Prot: MG-Protokoll wie MGCP oder Megaco, SIP: Session Initiation Protocol
www.wiwobooks.com
Die Lösung in Abbildung 8.1-2a stellt eine IP-TK-Anlage mit einem VoIP- IP-TKAnlage Server dar. Die Funktion eines MGC realisiert hier der VoIP-Server. Ein MG-Protokoll definiert Nachrichten und Regeln, um die entsprechenden MGs so zu „konfigurieren“, dass die Sprache bzw. auch Video mit Hilfe des Protokolls RTP zwischen ihnen übermittelt werden kann. Kommen mehrere MGCs zum Einsatz, müssen sie untereinander bestimmte Steuerungsangaben übermitteln. Hierfür eignet sich das Protokoll SIP sehr gut (s. Kapitel 7). Auch H.323 (s. Kapitel 6) lässt sich einsetzen. Jedem MG muss ein MGC zugeordnet werden. Ein MGC kann mehrere MGs ansteuern. Falls ein IP-Netz (z.B. Internet) mit Hilfe eines MG mit dem PSTN/ISDN integriert ist, kann zwischen Telefonen am IP-Netz und Telefonen am PSTN/ ISDN eine Sprachkommunikation erfolgen. Wie Abbildung 8.1-3 zeigt, realisiert ein MGC mit Hilfe eines MG-Protokolls wie z.B. MGCP bzw. Megaco die hierfür notwendige Ansteuerung von MGs. M G -P ro t
M G 6
...
N ic h t-IP T e le fo n e
M G C
S IP
I P - N e tz ( z . B .I n te r n e t) IP -T e le fo n S e s s io n
S e s s io n
M G
M G C M G -P ro t IS D N IS D N -V e rb in d u n g IS D N -V e rb in d u n g
Abb. 8.1-3: Bedeutung der MG-Protokolle bei der Integration eines IP-Netzes mit dem ISDN
360
8
VoIP-Gateways: Konzepte und Protokolle
Die Komponenten MG und MGC sind die wichtigsten Bestandteile von Gateway-Plattformen (s. Abschnitt 1.4.3, Abb. 1.4-7), die eine Migration zu Next Generation Networks ermöglichen.
8.2
Konzept von MGCP
Die Version 1.0 des von der IETF spezifizierten Protokolls MGCP (Media Gateway Control Protocol) wurde zuerst im RFC 2705 veröffentlicht und später 1 im RFC 3435 modifiziert. Die wichtigsten Besonderheiten von MGCP sind: Bei MGCP wird ein MGC als Call Agent (CA) bezeichnet.
Besonderheiten von MGCP
MGCP funktioniert nach dem Command/Response-Schema und definiert zwei Arten von Nachrichten: Commands und Responses. Commands werden in der Regel vom CA zum MG gesendet. Ein Response dient als Antwort auf einen Command. MGCP nutzt für die Übermittlung seiner Nachrichten das verbindungslose Transportprotokoll UDP. Standardmäßig wird von MGCP in der Richtung − vom CA zum MG der Port 2427 benutzt; − vom MG zum CA der Port 2727 benutzt. Dem MGCP kann auch eine andere Ziel-Port-Nummer zugeordnet werden.
MGCP nutzt UDP
www.wiwobooks.com
Die MGCP-Nachrichten werden textbasiert und zeilenweise dargestellt. Die Übermittlung von Sprache bzw. Video zwischen Media Gateways erfolgt mit Hilfe des Protokolls RTP (Real-time Transport Protocol). MGCP benutzt das Protokoll SDP (Session Description Protocol), die Beschreibung von Sessions zwischen Media Gateways.
8.2.1 Grundbegriffe bei MGCP Mit MGCP werden verschiedene Typen von MGs angesteuert. Um hierfür einen einheitlichen Regelsatz zu spezifizieren, werden bei MGCP bestimmte Begriffe definiert. Hierzu gehören u.a.: Endpoint, Call, Connection, Event und Package – siehe Abbildung 8.2-1. Begriff: Endpoint
Endpoints sind physikalische Schnittstellen im MG. Sie entsprechen den physikalischen Leitungen und sind Quellen und Senken von Sprache, Daten bzw. Video. Die Endpoints sind z.B.: analog lines – Ports für den Anschluss analoger Telefone; digital channels – digitale Kanäle mit einer Bitrate von 64 kbit/s. 1
Siehe http://www.packetizer.com/ipmc/mgcp für MGCP-betreffende Spezifikationen.
8.2 Konzept von MGCP
361
Ein Endpoint in einem MG wird identifiziert durch den Domainnamen des MG und einen lokalen Namen innerhalb des MG. Beispiel: Die Endpoint-Identifikation ist: [email protected]
Es handelt sich hier um das Interface 5 im MG 23 der Domain beispiel.net
...
C a ll a ls A n r u f M e d ia G a te w a y (M G )
C a ll C o n n e c tio n s
C o n n e c tio n s a ls V e r b in d u n g e n C a ll
...
C o n n e c tio n
C a ll
C o n n e c tio n E n d p o in t a ls S c h n itts te lle
...
E n d p o in t
Abb. 8.2-1: Interpretation von Endpoint, Call und Connection
Über einen Endpoint können gleichzeitig mehrere Calls verlaufen. Ein Call kann sich aus mehreren Connections (Verbindungen) zusammensetzen, z.B. aus einer für Sprachkommunikation und einer für Videokommunikation. Um die Signalisierung an allen Typen von Endpoints auf einheitliche Art dar- Spezifikation zustellen, werden Events und Packages definiert. Ein Event stellt eine bestimm- von Events te Folge von Signalen an einem Endpoint dar. Eine Gruppe von Events und in Packages Signalen an einem Endpoint-Typ bildet ein Package. Ein Package enthält somit eine Liste von Ereignissen, die an einem Endpoint-Typ auftreten können.
www.wiwobooks.com
Ein Package kann z.B. alle Events auf einer analogen Leitung definieren. Da- Package H mit wird der Verlauf der Signalisierung auf einer Leitung beschrieben. Als Beispiel zeigt die Tabelle 8.2-1 einen Auszug aus dem sog. Package H (Handset Package) mit der Beschreibung von Events (Signalen) am Endpoint für den Anschluss eines analogen Telefons.
Tab. 8.2-1:
Event (Signal)
Beschreibung
Signalart
hd
Off-hook (Abgehoben)
OO
hu
On-hook (Aufgelegt)
OO
bz
Busy tone (Besetztton)
OO
rg
Ringing (Klingeln)
TO
v
Alerting tone (Freiton)
OO
Dauer
30 sek
Auszug aus dem Package H – Events an analogem Telefonanschluss OO: On/Off Signal, TO: Time-Out Signal
Da unterschiedliche Arten von Leitungen und Systemkomponenten in Frage Weitere kommen, werden bei MGCP weitere Packages wie z.B. Trunk Package (T), Packages Line Package (L) und RTP Package (R) spezifiziert.
362
8
VoIP-Gateways: Konzepte und Protokolle
8.2.2 MGCP-Commands CA = MGC
MGCP funktioniert nach dem Command/Response-Schema und definiert mehrere Commands, wobei diese überwiegend vom Call Agent (CA) genutzt werden. Die Commands von MGCP sind u.a.: EndpointConfiguration (EPCF) – Mit EPCF kann der CA einen Endpoint bei einem MG konfigurieren. NotificationRequest (RQNT) und Notify (NTFY) – Mit RQNT fordert
der CA vom MG eine Meldung über spezielle Ereignisse am Endpoint an. MG liefert die Information mit NTFY an den CA zurück. CreateConnection (CRCX) – Mit CRCX fordert der CA ein MG auf, eine
Verbindung herzustellen. ModifyConnection (MDCX) – Mit MDCX veranlasst der CA ein MG, die
Eigenschaften der Verbindung zu verändern. DeleteConnection (DLCX) – DLCX wird sowohl von CA als auch von
MG verwendet, um eine Verbindung zu beenden. Die MGCP-Nachrichten (d.h. Commands und Responses) werden zeilenweise – wie die Nachrichten bei SIP (s. Abschnitt 7.3.3) also – aufgebaut. Jedes Command hat die in Abbildung 8.2-2 dargestellte Struktur.
www.wiwobooks.com
C o m m a n d L in e V e rb T ra n s a c tio n -ID E n d p o in t V e rs io n P a ra m e te rN a m e : P a ra m e te rV a lu e P a ra m e te rN a m e : P a ra m e te rV a lu e P a r a m e te r L in e s
...
Struktur von Commands
Abb. 8.2-2: Zeilenweise Struktur von MGCP-Commands ID: Identification
Jedes Command beginnt mit einer Command Line, danach folgen mehrere Parameter Lines. Die Command Line enthält: Verb als Command-Name, Transaction-ID, Endpoint als Endpoint-Adresse und (MGCP-)Version. Diese Angaben werden jeweils mit einem Leerzeichen voneinander getrennt. Abbildung 8.2-3 zeigt ein Command CRCX.
C R N : X : R :
C
h
a 3
E n d p o in t V e r s io n V e rb T r a n s a c tio n -ID X 4 5 6 3 e n d p o in t- 2 2 @ tg w - 8 .b e is p ie l.d e M G C P 0 .1 b c @ c a .b e is p ie l.d e : 5 7 7 7 P a r a m e te r L in e s 4 5 6 7 4 5 6 d
Abb. 8.2-3: Beispiel für ein Command von MGCP
8.2 Konzept von MGCP
363
Mit der Transaction-ID kann ein Response einem Command eindeutig zugeordnet werden. Tabelle 8.2-2 zeigt die Verbs wichtiger MGCP-Commands. Command
Verb
Richtung
Bedeutung
EndpointConfiguration
EPCF
CA
MG
Konfiguration eines Endpoints
CreateConnection
CRCX
CA
MG
Aufbau einer Verbindung
ModifyConnection
MDCX
CA
MG
Modifikation einer Verbindung
DeleteConnection
DLCX
CA
MG
Abbau einer Verbindung
NotificationRequest
RQNT
CA MG
Aufford. zur Meldung bestimmter Ereignisse
Notify
NTFY
CA MG
Meldung bestimmter Ereignisse
Tab. 8.2-2:
Verbs von Commands
Verbs wichtiger MGCP-Commands
In MGCP-Nachrichten werden verschiedene Parameter übermittelt. Hierzu ge- Parameter hören u.a.: CallId (C), RequestIdentifier (X), RequestedEvents (R), in MGCPObservedEvents (O), ConnectionParameter (P) und SignalRequests Nachrichten (S). Der Buchstabe in Klammern stellt hier den Code des Parameters dar. Die folgenden Parameter sind hervorzuheben:
www.wiwobooks.com
CallId zur Identifikation von Signalisierungsvorgängen;
ConnectionId zur Identifikation von initiierten Verbindungen; RequestIdentifier zur Identifikation von Commands.
8.2.3 MGCP-Responses Jeder Command wird mit einem Response bestätigt. Die Responses werden Aufbau von Responses ähnlich wie Commands zeilenweise aufgebaut. Abbildung 8.2-4 zeigt dies.
...
...
R e s p o n s e C o d e T ra n s a c tio n -ID R e s p o n s e S trin g R e s p o n s e L in e P a ra m e te rN a m e : P a ra m e te rV a lu e P a r a m e te r L in e s (O p tio n a l) S D P in fo rm a tio n 1 S D P P a y lo a d s S D P in fo rm a tio n n
Abb. 8.2-4: Aufbau von MGCP-Responses ID: Identification
Jeder Response beginnt mit einer Response Line, welche einen ResponseCode, eine Transaktions-ID und eventuell (optional) einen ResponseString als Kommentar enthält. Diese Angaben werden jeweils mit einem
364
8
VoIP-Gateways: Konzepte und Protokolle
Leerzeichen voneinander getrennt. Nach der Response Line folgen eventuell Parameter Lines mit Parameter-Angaben. Beispiel: Die ResponseLine kann sein: 200 1304 OK
Nach den Parameter Lines folgen Zeilen SDPinformation, die eine VoIPSession gemäß dem Protokoll SDP beschreiben. Diese Zeilen werden auch als SDP Payloads bezeichnet. Hier werden u.a. Angaben bezüglich der Sprachcodierung gemacht – siehe beispielsweise Abbildungen 7.4-1 und -2. ResponseCodeBedeutung
Der ResponseCode in einer Response kann einen Return-, Error- bzw. Reason-Code darstellen und als „nummerierte Reaktion“ auf einen Command, die an den Absender des Commands übergeben wird, angesehen werden. Dabei handelt es sich um folgende dreistellige Werte: Werte 1xx für vorläufige Meldungen – Ein Response mit 100 verweist darauf, dass die betreffende Transaktion gerade durchgeführt wird; Werte 2xx für die Anzeige erfolgreich vollendeter Aktionen. Dabei kann es sich z.B. um dern erfolgreichen Abschluss einer Transaktion handeln (200: The requested transaction was executed normally) oder um das Ende einer Verbindung (250: The connection was deleted);
www.wiwobooks.com
Werte 4xx für die Anzeige kurzzeitiger Fehlerzustände – z.B. 401: The phone is already off hook; Werte 5xx für die Anzeige permanenter Fehlerzustände; Werte 8xx für die Angabe von Package-spezifischen Reason Codes; Werte 000 und 9xx für die Angabe von Reason Codes – z.B. 000: Endpoint state is normal; 903: QoS resource reservation is lost.
8.2.4 Auf- und Abbau einer VoIP-Session nach MGCP Aufbau einer VoIP-Session
Abbildung 8.2-5 illustriert den MGCP-Verlauf beim Aufbau einer Telefonverbindung, bei dem die kommunizierenden Media Gateways MG1 und MG2 mit Hilfe eines Call Agent (CA) gesteuert werden. Die Aufgabe des MGCP besteht hierbei im Aufbau einer VoIP-Session zwischen MG1 und MG2, sodass zwischen ihnen Sprache nach dem Protokoll RTP übermittelt werden kann. Die möglichen Signale, die ein Telefon senden und empfangen kann, und deren Reihenfolge werden im Package H spezifiziert. Einen Auszug aus diesem Package enthält Tabelle 8.2-1. In Abbildung 8.2-5 wird angenommen: MG1 gehört zur Domain abc.de und MG2 zur Domain xyz.de.
8.2 Konzept von MGCP
365
Das Telefon bei Teilnehmer A ist am Port 2 (d.h. Endpoint 2) im MG1 angeschlossen. Die Identifikation dieses Endpoints ist: [email protected] a b c .d e
M G 6
1
T e iln e h m e r A 1
A b g e h o b e n (O ff-h o o k )
2 0 0
F re ito n
2 0 0 2
2
T e iln e h m e r B
Z u s ta n d A b g e h o b e n re g is trie rt
N T F Y (O :x x ) C R C X
2 0 0 4
M D C X (s d p 2) 2 0 0 2 0 0
C R C X (s d p 1) 2 0 0 (s d p 2) 5
2 0 0 (s d p 1) R Q N T (R :h u ) 6 2 0 0 R Q N T (S :v ) 7 2 0 0
B e g in n d e r V e rb in d u n g
Abb. 8.2-5:
R Q N T (R :h u )
M G
C A
N T F Y (O :h d )
3
T e l-N r.
x y z .d e
IP -N e tz
7
N T F Y (O :h d ) 2 0 0
1 0
R Q N T (S :rg )
9
M D C X (s d p 1)
K lin g e ln (R in g in g )
2 0 0 8
A b g e h o b e n
2 0 0 (s d p 2) R Q N T (R :h u ) R Q N T (R :h u ) 1 1 1 1 2 0 0 V o IP -S e s s io n (G e s p rä c h )
www.wiwobooks.com
Aufbau einer VoIP-Session beim Einsatz eines Call Agent
CA: Call Agent, MG: Media Gateway, sdp: Session Description Protocol
Bemerkung: Da MGCP das unsichere Transportprotokoll UDP für die Übermittlung von Commands nutzt, wird jeder Command im Regelfall mit Response 200 bestätigt. Somit gilt der Response 200 als positive Bestätigung für Command. Das Abheben des Hörers im Telefon durch den Teilnehmer A wird dem CA mit einem Command NTFY (Notify) signalisiert (1). Dieser Command enthält den Parameter O (ObservedEvents) mit der Angabe hd (Off-hook, s. Tab. 8.2-1) und hat folgende Struktur:
Teilnehmer initiiert eine Verbindung
NTFY 1434 [email protected] MGCP 1.0 X: 4235526 (RequestID) O: hd
Der Response 200 auf NTFY ist: 200 1434 OK
Weil Teilnehmer A zu jeder Zeit den Hörer auflegen kann, fordert CA mit RQNT (NotificationRequest) MG1 auf, ihm dieses Ereignis immer zu melden (2). Somit enthält RQNT den Parameter R (RequestedEvents) mit der Angabe hu (On-hook, Tab. 8.2-1) und hat folgende Struktur: RQNT 1435 [email protected] MGCP 1.0 X: 4235526 (RequestID) R: hu
Die Wahlziffern werden an CA in NTFY als Parameter O (d.h. O:xx) übermittelt (3). Ist die ZielTelefonnummer dem CA bereits bekannt, bestimmt er das Ziel (d.h. MG2). Der CA muss hierbei auf eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse (von MG2) zugreifen.
Wahlinformation
366 CA initiiert eine VoIPSession
8
VoIP-Gateways: Konzepte und Protokolle
Der CA ordnet dem ankommenden Anruf eine Identifikation (CallID) zu und sendet den Command CRCX (CreateConnection) mit dieser ID an MG1, um den Aufbau einer Verbindung zu initiieren (4). Dieser Command hat somit folgende Struktur: CRCX 1436 [email protected] MGCP 1.0 C: 3325991 (CallID) X: 4235526 (RequestID)
MG1 bestätigt CRCX mit Response 200, in dem die vom Telefon des Teilnehmers A vorgeschlagenen Sprachformate (d.h. das Sprachkodierungsverfahren) enthalten sind (sdp1). Die Spezifikation der Formate erfolgt nach dem Protokoll SDP. Nach dem Empfang des Response 200 vom MG1 mit der Spezifikation der Sprachformate sendet CA das Command CRCX an MG2 (5). Als Reaktion darauf erhält er vom MG2 im Response 200 die Angabe der vom Telefon des Teilnehmers B akzeptierten Sprachformate (sdp2). Die von beiden Seiten akzeptierten Sprachformate sind dem CA nun bekannt, sodass er feststellen kann, ob die beiden Telefone kompatibel sind. Ist dies der Fall, wird der Aufbau einer Verbindung zwischen ihnen fortgesetzt. Weil Teilnehmer A nach der Wahl den Hörer auflegen kann (z.B. wenn er eine falsche Telefonnummer gewählt hat), fordert CA mit RQNT das MG1 auf, ihm dies zu melden (6).
CA aktiviert Klingeln und Freiton
Nachdem CA den Response 200 vom MG2 mit der Angabe der vom Telefon des Teilnehmers B akzeptierten Sprachformate (sdp2) empfangen hat (5), sendet er RQNT an MG2 mit der Parameter Line S:rg (S = SignalRequests, rg = Ringing) und auch RQNT an MG1 mit S:v (v = Alerting tone). Dadurch wird das Klingeln im Telefon von Teilnehmer B aktiviert und das Freizeichen im Telefon von Teilnehmer A generiert (7).
Entgegennahme des Anrufs
Hat Teilnehmer B den Hörer abgehoben, sendet MG2 den Command NTFY mit O:hd (hd = Offhook) (8). Nach dem Empfang der Bestätigung von MG2 als Response 200 sendet CA das Command MDCX (ModifyConnection) an MG2 mit der Angabe der unterstützten Sprachformate (sdp1) vom Telefon des Teilnehmers A (9). Damit wird MG2 aufgefordert, die Teilnehmer A akzeptierten Sprachformate (sdp1) zu berücksichtigen und den Aufbau der Verbindung fortzusetzen. Im Response 200 auf MDCX sendet MG2 die ausgewählten Sprachformate (sdp2).
www.wiwobooks.com
Nachdem CA den Response 200 auf MDCX empfangen hat (9), sendet er MDCX an MG1 mit der Angabe der ausgewählten Sprachformate (sdp2) vom MG2 (10). Daraufhin fordert CA die beiden Media Gateways mit RQNT auf (11), ihm das Auflegen des Hörers zu signalisieren. Das Gespräch kann nun beginnen. Die Übermittlung der Sprache zwischen den beiden Media Gateways erfolgt mit Hilfe des Protokolls RTP. Bemerkung: Bevor ein MG vom CA gesteuert werden kann, muss das MG beim CA entsprechend „angemeldet“ werden. Nach der Anmeldung eines MG beim CA fordert der CA das MG mit RQNT(R:hd) auf, ihm das Abheben des Hörers in einem Telefon zu signalisieren. Dies wurde in Abbildung 8.2-6 außer Acht gelassen.
Abbau einer VoIPSession
Den MGCP-Verlauf beim Abbau einer VoIP-Session zeigt Abbildung 8.2-6. Nachdem Teilnehmer A den Hörer aufgelegt hat, signalisiert MG1 dies mit dem Command NTFY mit der Parameter Line O:hu (hu = On-hook, aufgelegt) an den CA (1). Daraufhin fordert der CA mit DLCX (DeleteConnection) die beiden Media Gateways MG1 und MG2 auf, die Telefonverbindung zu beenden (2). Sie bestätigen dies mit Response 250 (the connection was deleted). Das Auflegen des Hörers bei Teilnehmer B signalisiert MG2 dem CA durch das Absenden von NTFY mit der Parameter Line O:hu (3). Zum Schluss fordert der CA noch die beiden Media Gateways mit RQNT(R:dh) auf, ihm das Abheben des Hörers zu signalisieren (4).
8.2 Konzept von MGCP
M G 6
T e iln e h m e r A
IP -N e tz
x y z .d e
C A
M G 2
T e iln e h m e r B
V o IP -S e s s io n (G e s p rä c h ) N T F Y (O :h u ) D L C X 1 2 2 0 0 2 5 0 D L C X 2 N T F Y (O :h u ) 2 5 0 3 2 0 0 R Q N T (R :h d ) R Q N T (R :h d ) 4 4 2 0 0 2 0 0
A u fg e le g t (O n -h o o k )
Abb. 8.2-6:
a b c .d e 1
367
A u fg e le g t
Abbau einer VoIP-Session beim Einsatz eines Call Agent CA: Call Agent, MG: Media Gateway
Im Allgemeinen können die kommunizierenden Media Gateways mit Hilfe unterschiedlicher Call Agents (CAs) gesteuert werden. Für die Übermittlung der Steuerung zwischen CAs eignet sich das Protokoll SIP (s. Kapitel 7). Abbildung 8.2-7 zeigt den Aufbau einer Telefonverbindung, bei dem mehrere CAs eingesetzt werden. Hierbei wurde angenommen, dass die Kommunikation zwischen CAs nach SIP erfolgt. Der hier gezeigte MGCP-Verlauf zwischen MG und CA ist identisch mit dem MGCP-Verlauf in Abbildung 8.2-5 (gleiche Schritte). Daher werden die einzelnen Schritte in Abbildung 8.2-7 nicht erläutert, sondern die „Kooperation“ von MGCP und SIP kurz dargestellt.
www.wiwobooks.com
6
M G
T e iln e h m e r A A b g e h o b e n T e l-N r.
a b c .d e 1
N T F Y 1
2 0 0 3
2 0 0
B e g in n d e r V e rb in d u n g
2 0 0 4
R Q N T R Q N T
M D C X (s d p 2) 2 0 0 2 0 0
1
R Q N T
x y z .d e C A
7
1 0 1 1
2
T e iln e h m e r B
IN V IT E (s d p 1) 5
1 0 0 T ry in g 6
M G
2
S IP
N T F Y C R C X
2 0 0
IP -N e tz
2 0 0 2
R Q N T
2 0 0 (s d p 1) F re ito n
C A
1 8 0 R in g in g (s d p 2)
7 2 0 0
2 0 0 O K (s d p 2) A C K
V o IP -S e s s io n (G e s p rä c h )
9 1 1
C R C X (s d p 1) 2 0 0 (s d p 2) R Q N T N T F Y
2 0 0 8
M D C X (s d p 1) R Q N T
K lin g e ln (R in g in g )
A b g e h o b e n
2 0 0 (s d p 2) 2 0 0
Abb. 8.2-7: Aufbau einer VoIP-Session beim Einsatz mehrerer Call Agents Nach dem Empfang des Response 200 vom MG1 auf CRCX mit der Information sdp1 über die bei Teilnehmer A unterstützten Sprachformate sendet CA1 den SIP-Request INVITE mit sdp1 an
Aufbau einer VoIP-Session bei mehreren Call Agents
368
8
VoIP-Gateways: Konzepte und Protokolle
CA2. Er bestätigt dies mit SIP-Response 100 Trying und sendet CRCX mit der Information sdp1 an MG2 (5). MG2 bestätigt dies mit Response 200 mit der Information (sdp2) über unterstützte Sprachformate bei Teilnehmer B. Nachdem das Klingeln bei Teilnehmer B aktiviert wurde (7), wird dies dem CA1 mit SIP-Response 180 Ringing signalisiert, in dem die Information sdp2 über unterstützte Sprachformate bei Teilnehmer B enthalten ist. Die Information sdp2 über die bei Teilnehmer B ausgewählten Sprachformate, die MG2 in Response 200 an den CA2 übermittelt, wird in SIP-Response 200 OK an den CA1 gesendet. Der CA1 bestätigt dies mit der SIP-Nachricht ACK. Die weiteren Schritte beim MCGP-Verlauf in Abbildung 8.2-7 entsprechen vollkommen den in Abbildung 8.2-5 dargestellten Schritten.
Abbau einer VoIP-Session bei mehreren Call Agents
Abbildung 8.2-8 zeigt den Abbau einer Session (s. Abb. 5.2-1), bei dem mehrere CAs eingesetzt werden. Der hier gezeigte MGCP-Verlauf zwischen MG und CA entspricht vollkommen dem MGCP-Verlauf in Abbildung 8.2-6.
6
M G
a b c .d e 1
C A
T e iln e h m e r A A u fg e le g t (O n -h o o k )
D L C X 2 5 0
R Q N T
1
x y z .d e C A
2 0 0 2
B Y E 2 0 0 O K
2
S IP
2
N T F Y
4
4
R Q N T
2
T e iln e h m e r B
D L C X
www.wiwobooks.com 2 0 0
M G
2
V o IP -S e s s io n (G e s p rä c h )
N T F Y 1
IP -N e tz
2 5 0 2 0 0
A u fg e le g t
2 0 0
Abb. 8.2-8: Abbau einer Session beim Einsatz mehrerer Call Agents Nachdem Teilnehmer A den Hörer aufgelegt hat, signalisiert MG1 dem CA1 dieses Ereignis mit NTFY. Nach dem Empfang von NTFY sendet der CA1 an den CA2 den SIP-Request BYE. Dieser wird vom CA2 mit SIP-Response 200 OK bestätigt. Nach dem Empfang von BYE sendet der CA2 das MGCP-Command DLCX (DeleteConnection) an MG2. Der weitere hier dargestellte MGCP-Verlauf ist identisch mit dem Verlauf in Abbildung 8.2-6.
8.3 IETF und ITU-T unterstützen Megaco
Protokoll Megaco
Bei MGCP gibt es einige Nachteile und Beschränkungen. Dagegen hat sich der von der ITU-T entwickelte konkurrierende Vorschlag als aussichtsreicher herausgestellt, sodass sich die entsprechende Arbeitsgruppe der IETF auch dem von ITU-T entwickelten Vorschlag zugewandt hat und die beiden Gremien sich auf ein gemeinsames MG-Protokoll geeinigt haben, das als Megaco bezeichnet wird. Megaco wurde von der IETF – zuerst als RFC 3015 und später als RFC 2 3 3525 – und auch vom ITU-T als H.248 veröffentlicht. 2
Nach RFC 5125 (2008) ist die Megaco-Spezifikation in RFC 3525 heute nur von historischer Bedeutung.
8.3 Protokoll Megaco
Die wichtigsten Besonderheiten von Megaco sind:
369
BesonderMegaco ist ein Protokoll für die Kommunikation zwischen MG und MGC heiten von Megaco
und entspricht der Funktion nach dem Protokoll MGCP.
Mit Megaco werden jeweils zwei MGs an einem IP-Netz so angesteuert, dass eine Übermittlung von Sprache bzw. von Video zwischen ihnen über das IP-Netz nach dem Protokoll RTP stattfinden kann. Um Kompatibilität zwischen den kommunizierenden MGs zu erreichen, wird das Protokoll SDP benutzt. Mit SDP können sich MGs gegenseitig mitteilen, welche Audio/Video-Formate sie unterstützen, und sich damit auf ein gemeinsames Format einigen. Megaco funktioniert nach dem Command/Reply-Schema und definiert zwei Arten von Nachrichten: Commands und Replys (als Antworten). Die Commands werden in der Regel von MGC zu MG gesendet. Megaco ist vom Transportprotokoll unabhängig. Für die Übermittlung von Megaco-Nachrichten können beide Transportprotokolle, d.h. TCP oder UDP, verwendet werden. Megaco-Nachrichten werden mit Hilfe der ASN.1 (Abstract Syntax Notation One) spezifiziert – siehe http://www.techabulary.com/a/asn1 oder [Gora 98].
www.wiwobooks.com
8.3.1 Konzept von Megaco Beim Protokoll Megaco – auch Gateway Control Protocol genannt – werden einige neue Begriffe verwendet; u.a. Termination, Package, Descriptor und Context. Megaco basiert auf einem Modell des Media Gateway (MG), in dem man sog. Terminations definiert. Abbildung 8.3-1 illustriert dies näher. Wie hier ersichtlich ist, versteht man unter Termination eine Quelle bzw. die Senke eines Bitstroms. Eine Termination stellt daher einen Port in einem MG dar. IP -N e tz 6
M G
6
M G P h y s ic a l T e rm in a tio n E p h e m e ra l T e rm in a tio n
M G 6
M G -in te rn e V e rb in d u n g R T P -S e s s io n
Abb. 8.3-1: Illustration des Begriffs: Termination
3
Siehe http://www.packetizer.com/ipmc/h248 für detaillierte Informationen über Megaco (Gateway Control Protocol). Die letzte Version von Megaco enthält H.248.1 (09/2005).
370
8
VoIP-Gateways: Konzepte und Protokolle
Begriff: Package
Die Beschreibung einer Termination (d.h einen MG-Port) erfordert in der Regel folgende Angaben: allgemeine Eigenschaft (Property), mögliche Ereignisse (Events), mögliche Signale (Signals) und Statistiken (Statistics). Die Spezifikation einer Termination, in der die aufgelisteten Angaben gemacht werden können, wird bei Megaco als Package bezeichnet. Wie Abbildung 8.3-2 zeigt, wird mit Package der Verlauf der Signalisierung auf einer Leitung beschrieben, die an einer Termination beginnt bzw. endet. 1 1 1
M e d ia G a te w a y P ro E v S ig S ta
p e rty e n ts n a ls tis tic
n
...
www.wiwobooks.com 1
n
n
s n
P a c k a g e n
L e itu n g (K a n a l)
P ro p e rty E v e n ts S ig n a ls S ta tis tic
P a c k a g e 1
Ein MG als Residential Gateway (Abb. 8.1-1b) enthält Terminations für den Anschluss der Telefone. Derartige Terminations werden physical Terminations genannt. Terminations seitens eines IP-Netzes, die den Beginn bzw. das Ende einer VoIP-Session darstellen, bezeichnet man als ephemeral Terminations. Sie sind dynamisch und daher nur so lange vorhanden, wie eine VoIP-Session existiert. Damit muss ein Command im Megaco vorhanden sein, mit dem sich eine Termination erzeugen und lösen lässt. Dies ermöglicht den Command ServiceChange (s. Tab. 8.3-1).
T e rm in a tio n
Begriff: Termination
Abb. 8.3-2: Illustration des Begriffs: Package
Einige Terminations lassen sich so konfigurieren, dass sie mehrere Packages unterstützen. Ein Package bei Megaco entspricht vollkommen dem Package bei MGCP (s. Abschnitt 8.2.1). Ein Megaco-Ablauf führt dazu, dass zwei Terminations in zwei verschiedenen MGs so miteinander gekoppelt werden, dass Sprache bzw. Video zwischen ihnen übermittelt werden kann. Falls zwei Terminations miteinander virtuell „verbunden“ werden sollen, müssen sie sich gegenseitig mitteilen, welche Eigenschaften sie besitzen. Descriptor
Die Eigenschaften einer Termination werden zusammengefasst und in Form sog. Descriptors dargestellt. Damit besitzt jede Termination bestimmte Descriptors. Jeder Descriptor besitzt einen Namen, den sog. DescriptorName. Die Übermittlung von Eigenschaften einer Termination erfolgt in Megaco-Commands durch die Angabe von Descriptors, sodass sie als Parameter von Megaco-Commands angesehen werden können.
Begriff: Context
Mit Megaco werden MGs so angesteuert, dass zwei bzw. mehrere Terminations miteinander verbunden werden. In diesem Zusammenhang spricht man von
8.3 Protokoll Megaco
Context. Ein Context stellt eine Assoziation mehrerer Terminations dar. Abbildung 8.3-3 illustriert dies. a ) R T P K a n a l
b )
C o n te x t T T
S C N K a n a l
C o n te x t R T P K a n a l T
T T
S C N -K a n a l S C N -K a n a l
Abb. 8.3-3: Veranschaulichung des Begriffs: Context a) Punkt-zu-Punkt-Context; b) Punkt-zu-Mehrpunkt-Context SCN: Switched Circuit Network, T: Termination
Ein Context spezifiziert sowohl die Topologie der Verbindung zwischen Terminations als auch die übermittelten Media-Formate sowie die Switching-Prinzipien, falls es sich um mehr als zwei Terminations handelt. Jedem Context wird eine eindeutige Identifikation (ContextID) zugeordnet.
8.3.2 Megaco-Commands
www.wiwobooks.com
Megaco funktioniert nach dem Command/Response-Schema und definiert hierfür insgesamt acht Commands, die überwiegend von MGC gesendet werden. Die einzelnen Megaco-Commands: Add – Mit Add wird ein MG von einem MGC aufgefordert, eine Termination einem Context hinzuzufügen (s. Abb. 8.3-3). Add wird beim Aufbau eines Contexts verwendet. Substract – Mit Substract fordert ein MGC ein MG auf, eine Termination aus einem Context zu entfernen. Substract wird beim Abbau eines
Contexts verwendet. Move – Mit Move fordert ein MGC ein MG auf, eine Termination von einem
Context zu einem anderen zu „verschieben“. Notify – Mit Notify meldet ein MG einem MGC die auf einer seiner
Terminations aufgetretenen Ereignisse. Mod (Modify) – Mit Mod fordert ein MGC ein MG auf, bestimmte Eigen-
schaften (Properties) einer Termination zu modifizieren. AuditValue – Mit AuditValue fragt ein MGC bei einem MG aktuelle
Eigenschaften, Ereignisse und Statistiken einer Termination ab. AuditCapabilities – Mit diesem Command fragt ein MGC bei einem MG die zulässigen Ereignisse, Signale und Statistiken einer Termination ab.
371
372
8
VoIP-Gateways: Konzepte und Protokolle
ServiceChange – Mit ServiceChange kann ein MG einem MGC signa-
lisieren, dass eine Termination außer Betrieb ist oder dass sie in Betrieb genommen wurde bzw. dass ihre Fähigkeiten geändert wurden. Vergleich von Megaco mit MGCP
Megaco stellt mehr Funktionen als MGCP zur Verfügung. Tabelle 8.3-1 zeigt eine Gegenüberstellung von Commands bei Megaco und MGCP.
Tab. 8.3-1:
Megaco-Command
Äquivalente(s) MGCP-Command(s)
Add
CRCX: CreateConnection
Mod(ify)
MDCX: ModifyConnection, RQNT: NotificationRequest und EPCF: EndpointConfiguration
Substract
DLCX: DeleteConnection
Move
Kein äquivalentes MGCP-Command
AuditCap(abilities)
Kein äquivalentes MGCP-Command
Notify
NTFY: Notify
ServiceChange
Kein äquivalentes MGCP-Command
Gegenüberstellung von Megaco- und MGCP-Commands
www.wiwobooks.com
8.3.3 Auf- und Abbau einer VoIP-Session nach Megaco Verbindungs- Abbildung 8.3-4 illustriert den Verlauf von Megaco beim Aufbau einer Sesaufbau sion, wenn die kommunizierenden Media Gateways MG1 und MG2 mit Hilfe
eines MGC gesteuert werden.
6
M G
IP -N e tz 1
T e iln e h m e r A
N o tify 1 R e p ly N o tify 2 R e p ly A d d 3 R e p ly M o d ify
A b g e h o b e n (O ff-h o o k ) T e l-N r. F re ito n
R e p ly B e g in n d e r V e rb in d u n g
R e p ly R e p ly
N o tify M o d ify
M G
M G C
2
T e iln e h m e r B Z u s ta n d A b g e h o b e n re g is trie rt
A d d 3 4
M o d ify
5 6 7 8
8
N o tify M o d ify
R e p ly
K lin g e ln (R in g in g )
R e p ly R e p ly
S e s s io n (V o IP -K o m m u n ik a tio n )
A b g e h o b e n
R e p ly
Abb. 8.3-4: Aufbau einer VoIP-Session nach Megaco beim Einsatz eines MGC
8.3 Protokoll Megaco
373
Bemerkung: Falls Megaco das unsichere Transportprotokoll UDP für die Übermittlung nutzt, wird jeder Command immer mit dem entsprechenden Reply direkt bestätigt. Beispielsweise wird der Command: NotifyRequest mit NotifyReply und AddRequest mit AddReply bestätigt. Da jeder Command immer mit dem gleichnamigen Reply bestätigt wird, verzichtet man bei der Darstellung des Ablaufs von Megaco auf die vollständige Angabe von Namen bei Replys. Wie aus Abbildung 8.3-4 ersichtlich ist, wird das Abheben des Hörers im Telefon bei Teilnehmer A dem MGC mit dem Command Notify signalisiert (1). Notify wird direkt mit einem entsprechenden Reply bestätigt. Die Wahlziffern von Teilnehmer A werden an MGC in Notify übermittelt (2). Ist die Telefonnummer des Teilnehmers B dem MGC bekannt, bestimmt er die IP-Adresse des Ziel-MG (d.h. MG2), an den der Command Add abgeschickt werden muss. MGC muss hierbei auf eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse (von MG2) zugreifen. MGC ordnet dem ankommenden Anruf eine Identifikation zu und sendet den Command Add an MG1 und MG2 (3). Nachdem sie Add empfangen haben, verknüpft jedes von ihnen den Port (als Termination bezeichnet), an dem das entsprechende Telefon angeschlossen ist, mit dem Port zum IP-Netz. Somit baut jedes MG für sich einen entsprechenden Context auf (vgl. Abb. 8.3-3). Im Reply auf Add übermittelt jedes MG die Angaben über die akzeptierten Sprachformate. Die Angabe der Formate erfolgt nach dem Protokoll SDP (s. Abschnitt 7.4). Da die von beiden Seiten akzeptierten Sprachformate dem MGC bekannt sind, kann er feststellen, ob die beiden Telefone kompatibel sind. Ist dies der Fall, wird der Aufbau der VoIP-Session zwischen MG1 und MG2 fortgesetzt.
www.wiwobooks.com
Somit sendet MGC den Command Modify an MG2 (4), um das Klingeln im Telefon des Teilnehmers B zu aktivieren. Modify enthält die Information über die seitens des Teilnehmers A vorgeschlagenen Sprachformate. Im Reply auf Modify wird das endgültige und von MG2 bestimmte Sprachformat angegeben. Wurde das Klingeln bei Teilnehmer B aktiviert und hat MGC ein Reply vom MG2 (4) empfangen, sendet er Modify an MG1 (5), um das Generieren des Freitons im Telefon von Teilnehmer A zu veranlassen. In diesem Command wird das seitens des Teilnehmers B ausgewählte Sprachformat angegeben. Hat Teilnehmer B den Hörer abgehoben, sendet MG2 Notify (6). Nach dem Empfang dieses Commands bei MGC sendet er Notify an MG1 (7). Daraufhin fordert MGC die beiden Media Gateways mit Modify auf (8), ihm das Auflegen des Hörers bei einem Telefon zu signalisieren. Das Gespräch kann nun beginnen. Die Übermittlung der Sprache zwischen MG1 und MG2 erfolgt mit Hilfe des Protokolls RTP. Bemerkung: Bevor MG von MGC gesteuert werden kann, muss MG bei MGC entsprechend „angemeldet“ werden. Nach der Anmeldung fordert MGC das MG mit dem Command Modify auf, ihm das Abheben des Hörers an einem Telefon zu signalisieren. Dies wurde in Abbildung 8.3-4 außer Acht gelassen. Abbildung 8.3-5 zeigt den Megaco-Verlauf beim Abbau einer VoIP-Session, bei dem die kommunizierenden MGs mit Hilfe eines MGC gesteuert werden. Nachdem Teilnehmer A den Hörer aufgelegt hat, signalisiert MG1 dieses Ereignis dem MGC mit Notify (1). Als Reaktion darauf fordert MGC mit Substract die beiden Media Gateways MG1 und MG2 auf, die Session zu beenden (2). Die beiden Gateways bestätigen dies mit Reply. Das Auflegen des Hörers bei Teilnehmer B signalisiert MG2 dem MGC mit Notify. Zum Schluss fordert MGC noch die beiden Gateways mit Modify auf, ihm das Abheben des Hörers beim Telefon zu signalisieren (4).
Verbindungsabbau
374
8
VoIP-Gateways: Konzepte und Protokolle
6
M G
T e iln e h m e r A
IP -N e tz 1
S e s s io n (V o IP -K o m m u n ik a tio n )
N o tify
1 R e p ly S u b s tra c t 2 R e p ly M o d ify 4 R e p ly
A u fg e le g t (O n -h o o k )
M G
M G C
2 3
2
T e iln e h m e r B
S u b s tra c t R e p ly N o tify R e p ly
4
A u fg e le g t
M o d ify R e p ly
Abb. 8.3-5: Abbau einer VoIP-Session nach Megaco beim Einsatz eines MGC Abkürzungen wie in Abbildung 8.3-4
8.3.4 Megaco und Integration von VoIP mit ISDN Megaco kann bei der Integration von VoIP mit dem ISDN eingesetzt werden. Abbildung 8.3-6 zeigt die Schritte beim Megaco-Verlauf, die zu einer Verbindung zwischen einem Telefon an einem IP-Netz und einem Telefon an einer ISDN-TK-Anlage führen. Der Netzübergang zwischen dem IP-Netz und der ISDN-TK-Anlage enthält ein MG2 und ein ISDN-Signalling Gateway (SG).
www.wiwobooks.com
6
M G
IP -N e tz 1
T e iln e h m e r A A b g e h o b e n (O ff-h o o k ) T e l-N r.
1 2
M G C
N o tify N o tify A d d
R e p ly R e p ly
R e p ly F re ito n B e g in n d e r V e rb in d u n g
R e p ly
3 3
M o d ify
8
S G
A b g e h o b e n re g is trie rt
4 M o d ify
R e p ly
M G
IS D N T K A n la g e
T e iln e h m e r B
A d d R e p ly
M o d ify
N o tify R e p ly
R e p ly 7 N o tify
1 1 R e p ly S e s s io n (V o IP -K o m m u n ik a tio n ) 1 2
2
K lin g e ln (R in g in g )
5 S E T U P A L E R T 6 C O N N
A b g e h o b e n
9
1 0 C O N N A C K B -K a n a l
Abb. 8.3-6: Aufbau einer Verbindung bei der Integration von VoIP und ISDN MG: Media Gateway; MGC: Media Gateway Controller; SG: ISDN-Signalling Gateway
Der in Abbildung 8.3-6 gezeigte Megaco-Verlauf ist weitgehend identisch mit dem Verlauf in Abbildung 8.3-4. Daher werden hier nicht alle Schritte näher erläutert. Wie hier ersichtlich ist, wird das Abheben des Hörers am Telefon bei Teilnehmer A dem MGC mit Notify signalisiert (1). Die Wahlziffern von Teilnehmer A werden an MGC auch in Notify übermittelt (2). Ist die Telefonnummer von Teilnehmer B dem MGC bekannt, bestimmt er die IP-Adresse des Media
8.3 Protokoll Megaco
375
Gateways (d.h. MG2), an den der Command Add geschickt werden muss. MGC muss hierbei auf eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse von MG zugreifen. MGC sendet Add an die beiden Gateways (3). Im Reply auf Add übermittelt jedes Media Gateway die Angaben über die bei ihm akzeptierten Sprachformate. Danach sendet MGC Modify an MG2 (4), um das Klingeln im Telefon des Teilnehmers B zu aktivieren. Dieser Command enthält die Telefonnummer des Teilnehmers B sowie die Information über die bei Teilnehmer A vorgeschlagenen Sprachformate. Nach dem Empfang von Modify (4) bei MG2 wird die Steuerung an SG übergeben. Daraufhin sendet SG die Nachricht SETUP des D-Kanal-Protokolls zum Telefon von Teilnehmer B (5). Damit wird bei ihm das Klingeln aktiviert. Dieses Ereignis wird dem SG mit der Nachricht ALERT vom D-Kanal-Protokoll angezeigt (6). Mit ALERT wird die Bereitschaft des Telefons bei Teilnehmer B signalisiert, die ankommende Verbindung entgegenzunehmen. Nachdem SG ALERT empfangen hat, meldet MG2 dem MGC mit Notify, dass das Klingeln bei Teilnehmer B aktiviert wurde. Daraufhin übermittelt MGC Modify an MG1, um das Generieren des Freitons im Telefon von Teilnehmer A zu veranlassen. Hat Teilnehmer B den Hörer abgehoben, wird dies dem SG mit der Nachricht CONN des DKanal-Protokolls angezeigt. Diese Nachricht wird vom SC mit CONN ACK bestätigt (10). Nach dem Eintreffen von CONN bei SG meldet MGC dieses Ereignis dem MGC mit Notify (11). Anschließend übermittelt MGC Modify an MG1 (12), um Teilnehmer A die Annahme des Gesprächs durch Teilnehmer B anzuzeigen. Das Gespräch kann nun beginnen. Die Übermittlung der Sprache zwischen MG1 und MG2 verläuft über eine VoIP-Session. Den Megaco-Verlauf beim Abbau der Verbindung zeigt Abbildung 8.3-7. Dieser Verlauf entspricht vollkommen dem aus Abbildung 8.3-5.
www.wiwobooks.com
6
T e iln e h m e r A A u fg e le g t (O n -h o o k )
M G 1
IP -N e tz
M G M G C
S e s s io n (V o IP -K o m m u n ik a S u b s tra M o d ify 1 2 R e p ly S u b s tra c t N o 2 R e p ly R e p ly M M o d ify 7 7 R e p ly
IS D N T K A n l. 2
S G tio n ) c t R e p ly tify 5 o d ify
T e iln e h m e r B
IS D N -V e rb in d u n g
6
3
D IS C
R E L 4
R E L C O M
R e p ly
Abb. 8.3-7: Abbau der Verbindung bei der Integration von VoIP mit ISDN Abkürzungen wie in Abbildung 8.3-6
Das Auflegen des Hörers bei Teilnehmer A signalisiert MG1 dem MGC mit Notify (1). Als Reaktion darauf fordert MGC mit Substract die beiden Media Gateways MG1 und MG2 auf, die Session zu beenden (2). Diese Aufforderung wird dem Telefon vom SG bei Teilnehmer B mit der Nachricht DISC des D-Kanal-Protokolls angezeigt (3). Das Telefon bei Teilnehmer B antwortet dem SG mit REL (4), und SG bestätigt diese Antwort mit REL COM (6). Den Empfang der Nachricht REL und damit das Auflegen des Hörers bei Teilnehmer B zeigt MG2 dem MGC mit dem Command Notify an (5). MGC fordert noch die beiden Media Gateways mit Modify auf, ihm das Abheben des Hörers am Telefon zu signalisieren (7).
Verbindungsabbau
376
8
VoIP-Gateways: Konzepte und Protokolle
8.4
Schlussbemerkungen
Abschließend ist Folgendes hervorzuheben: Für die Integration von herkömmlichen Systemen und Netzen für die Sprachkommunikation mit IP-Netzen werden verschiedene Media Gateways (MG) eingesetzt. Zu deren Steuerung stehen MGCP und Megaco als MG-Protokolle zur Verfügung. Die Steuerung von Media Gateways erfolgt mit einer Komponente, die man oft als Media Gateway Controller (MGC) bezeichnet. Bei MGCP wird MGC Call Agent genannt. Nach einem MG-Protokoll wird für VoIP-Kommunikation zwischen zwei MGs mit Hilfe von MGC eine Session aufgebaut, über die sich Sprache und auch Video übermitteln lassen. Megaco mächtiger als MGCP
MGCP und Megaco haben zwar die gleiche Aufgabe zu erfüllen, unterscheiden sich aber bezüglich ihres Funktionsumfangs. Megaco ist der Funktion nach mächtiger und seine Struktur komplexer als die von MGCP. Während sich MGCP besser für den Einsatz in privaten TK&DV-Infrastrukturen eignet, hat Megaco bei der Integration des Internet mit dem PSTN/ISDN einige Vorteile.
IP-TKAnlage mit klassischen Telefonen
In lokalen Netzwerken werden bereits sog. Telefon-Hubs eingesetzt, um herkömmliche Telefone an das Netzwerk anzuschließen. Ein Telefon-Hub stellt ein Residential Gateway dar (s. Abb. 8.1-1b). Da sich mehrere Gateways mit einem MGC ansteuern lassen, können mehrere Telefon-Hubs mit Hilfe eines MGC so vernetzt werden, dass sie eine netzwerkbasierte IP-TKAnlage mit klassischen Telefonen bilden (vgl. Abbildungen 1.2-6, -7 und 8.1-2a). Die Funktion von MGC wird in einem speziellen Server untergebracht, den man oft als VoIP-Server bezeichnet.
www.wiwobooks.com
Mehrere MGCs können vernetzt werden. Hierfür eignet sich das Protokoll SIP (s. Kapitel 7). Mit Hilfe mehrerer MGCs lassen sich verschiedene IPTK-Anlagen standortübergreifend vernetzen. Die IP-TK-Anlagen können auch mit bestehenden und klassischen TK-Anlagen integriert werden. Damit lässt sich eine standortübergreifende und heterogene TK-Anlage innerhalb eines Unternehmens einrichten (s. Abb. 8.1-2b). Daher können die klassischen ISDN-TK-Anlagen Schritt für Schritt abgebaut werden. Für weitere Informationen über Media Gateways und die Protokolle MGCP und Megaco sei auf die Webquellen [Web 01] und [Web 02] verwiesen.
9
IP-Telefonie-Routing und VoIPPeering
Innerhalb einer administrativen Domäne (Unternehmen, öffentliche Verwal- IP-Telefonietung, ...) mit mehreren Standorten führt VoIP mit H.323 zur Vernetzung sog. Routing „VoIP-Zonen“. Hierbei werden die IP-Adressen von Rechnern, die als IPTelefone dienen, auf speziellen, als Gatekeeper bezeichneten Servern abgespeichert. Initiiert ein klassisches Telefon am ISND/PSTN einen Anruf zu einem IP-Telefon, wird der Anruf über diverse Systemkomponenten zu einer Ziel-IP-Adresse geleitet. Man spricht in diesem Fall von IP-Telefonie-Routing (IP Telephony Routing) bzw. kurz Telefonie-Routing. Um VoIP über das Internet zwischen beliebigen administrativen Domänen zu Bedeutung ermöglichen, ist ein Konzept nötig, nach dem sich diese gegenseitig über sog. von TRIP Telefonie-Routen mitteilen können, wie die bei ihnen als IP-Telefone dienenden Rechner von außen erreichbar sind. Zu diesem Zweck wurde TRIP (Telephony Routing over IP) konzipiert.
www.wiwobooks.com
VoIP mit SIP bieten bereits zahlreiche Service Provider an. Deshalb muss es VoIPmöglich sein, dass eine Session zwischen VoIP-Domains verschiedener Pro- Peering vider nach Bedarf und spontan aufgebaut werden kann. Somit sind technische Lösungen für die Zusammenschaltung von VoIP-Domains verschiedener Provider – d.h. die Konzepte für ein sog. VoIP-Peering – von großer Bedeutung. Dieses Kapitel zeigt, wie sich weltweite Internet-Telefonie nach H.323 bzw. Überblick SIP realisieren lässt. Im Anschluss an die Darstellung typischer Probleme beim über das Routing von Anrufen in Abschnitt 9.1 präsentiert Abschnitt 9.2 das Konzept Kapitel und den Einsatz von TRIP. Auf das Telefonie-Routing zwischen H.323-Zonen und zwischen SIP-Zonen gehen die Abschnitte 9.3 und 9.4 ein. Abschnitt 9.5 zeigt, wie VoIP-Peering zwischen VoIP-Domains mit SIP möglich ist. Dieses Kapitel beantwortet u.a. folgende Fragen: Welche Probleme entstehen, wenn man eine VoIP-Kommunikation zwischen beliebigen administrativen Domänen realisieren möchte? Welche Bedeutung hat das Telefonie-Routing bei VoIP mit H.323, und wie verläuft es nach TRIP? Wie lässt sich VoIP-Kommunikation zwischen beliebigen H.323- bzw. SIPZonen realisieren? Welche Bedeutung hat das Peering bei VoIP mit SIP, welche entsprechenden Möglichkeiten gibt es, und wie sind sie realisierbar?
Ziel dieses Kapitels
378
9
IP-Telefonie-Routing und VoIP-Peering
9.1
Typische Probleme bei VoIP
Bei VoIP sollte es möglich sein, dass jedes IP-Telefon mit jedem anderen Telefon am ISDN bzw. am digitalen oder analogen Telefonnetz eine Verbindung für die Sprachkommunikation aufbauen kann. Um dies zu ermöglichen, müssen einige Probleme gelöst werden, die nun anhand der in Abbildung 9.1-1 gezeigten typischen Situation näher erläutert werden. A d m in is tr a tiv e D o m ä n e X : 0 6 7 ... H .3 2 3
0 6 7 1 ... Z
S IP 0 6 7 2 ... T ln C
H .3 2 3 0 6 7 3 ...
T ln A
? 1
G W Z
A d m in is tr a tiv e D o m ä n e Y : 0 8 5 ... 6
A
IS D N /P S T N
Z
G W
H .3 2 3 0 8 5 1 ... 1
B
Z
2
R A
IP -N e tz (In te rn e t)
3
R B
?
Z 2
H .3 2 3
T ln B
T ln D
0 8 5 2 ...
Abb. 9.1-1: Typische Situation bei VoIP – An welche IP-Adresse wird der Anruf geleitet? GW: Gateway, ISDN: Integrated Services Digital Network, PSTN: Public Switched Telephone Network, R: Router, Z: VoIP-Zone
Mehrere VoIP-Zonen in einer administrativen Domäne
Die Vernetzung von Rechnern einer großen administrativen Domäne wie z.B. eines Großunternehmens, einer Stadtverwaltung, einer Universität usw. erfolgt in der Regel über ein standortübergreifendes IP-Netz. Aus Sicht der Sprachkommunikation kann hierbei ein Standort als VoIPZone angesehen werden. In einer VoIP-Zone lässt sich als Signalisierungsprotokoll entweder H.323 (s. Kapitel 6) oder SIP (Session Initiation Protocol, s. Kapitel 7) verwenden. Bei H.323 ist die VoIP-Zone durch den Begriff H.323-Zone bzw. kurz Zone zu ersetzen. Bei SIP würde eine VoIP-Zone einer Internet-Domain entsprechen. Eine administrative Domäne kann im Allgemeinen mehrere VoIP-Zonen mit verschiedenen Signalisierungsprotokollen enthalten, von denen in einigen H.323 und in anderen SIP als Signalisierungsprotokoll dient.
Jede VoIPZone kann eine Vorwahl haben
Jedes IP-Telefon ist de facto ein Rechner, sodass er über eine IP-Adresse verfügen muss. Um ein IP-Telefon von einem „normalen“ Telefon am ISDN bzw. am PSTN zu erreichen, muss es auch über eine Telefonnummer verfügen, die man in jedem herkömmlichen Telefon angeben kann. Jede administrative Domäne hat normalerweise eine Vorwahl. In Abbildung 9.1-1 hat beispielsweise die administrative Domäne X die Vorwahl 067. Die Vorwahl ist als Präfix der Telefonnummer zu interpretieren. Jede VoIP-Zone hat ebenfalls eine eigene Vorwahl. Beispielsweise hat die VoIP-Zone Z2 in der administrativen Domäne Y die Vorwahl 0852.
www.wiwobooks.com
Die Sprachkommunikation zwischen einem Telefon am ISDN/PSTN und einem IP-Telefon innerhalb einer administrativen Domäne wird über ein entsprechendes (GW) abgewickelt.1 Die Sprachkommunikation zwischen einem externen IP-Telefon am Internet und einem internen IPTelefon einer administrativen Domäne verläuft dagegen immer über einen Router. Wie aus Abbildung 9.1-1 ersichtlich ist, kann die Sprachkommunikation zwischen einem IP-Telefon aus der administrativen Domäne X und einem IP-Telefon der administrativen Domäne Y sowohl über das ISDN/PSTN als auch über das IP-Netz abgewickelt werden. In Abbildung 9.1-1 sind folgende Probleme hervorgehoben: 1
In diesem Kapitel bedeutet VoIP-Gateway ein Media Gateway (s. Kapitel 8) mit bestimmten zusätzlichen Funktionskomponenten.
9.1 Typische Probleme bei VoIP
379
1.
Problem bei ankommenden Anrufen aus dem ISDN/PSTN – Der Teilnehmer A am ISDN/PSTN initiiert beispielsweise einen Anruf zum Teilnehmer B in der administrativen Domäne Y. Weil das IP-Telefon von Teilnehmer B die Signalisierung nach H.323 realisiert, muss das Gateway GWB eine Nachricht SETUP nach dem Protokoll H.225.0 aus der H.323Familie an das IP-Telefon von Teilnehmer B weiterleiten (s. Abb. 6.2-1), um ihm damit den ankommenden Anruf zu signalisieren. Die IP-Adresse des IP-Telefons von Teilnehmer B ist aber dem Gateway GWB nicht bekannt. Oft werden die IP-Adressen den Rechnern und somit auch den IP-Telefonen von DHCP-Servern dynamisch zugeteilt [BaHo 07]. Das Gateway muss unbedingt wissen, wo es die benötigte Zuordnung Telefonnummer IP-Adresse abrufen kann. So erfährt es, welche IP-Adresse das IP-Telefon von Teilnehmer B aktuell hat. Dieses Problem kann beispielsweise mit Hilfe von TRIP (Telephony Routing over IP) gelöst werden (vgl. Abb. 9.1-2 und 9.3-2).
An welche IP-Adresse soll ein ankommender Anruf geleitet werden?
2.
Problem bei abgehenden Anrufen – Teilnehmer C aus der administrativen Domäne X initiiert beispielsweise einen Anruf zu Teilnehmer D in der administrativen Domäne Y. Aus der VoIP-Zone Z3 der Domäne X muss eine H.225.0-Nachricht SETUP an das IP-Telefon von Teilnehmer D aus der Domäne Y abgeschickt werden. Die IP-Adresse des IP-Telefons von Teilnehmer D ist dem IP-Telefon von Teilnehmer C in der VoIP-Zone Z3 aber nicht bekannt. Es muss in Z3 somit eine Stelle vorhanden sein, bei der man die benötigte Zuordnung Telefonnummer IP-Adresse in der administrativen Domäne Y abrufen kann. Dieses Problem kann ebenfalls mit Hilfe von TRIP gelöst werden (vgl. Abbildungen 9.1-3 und 9.3-1).
An welche IP-Adresse soll ein abgehender Anruf geleitet werden?
Hinter beiden Problemen steht eigentlich die gleiche Frage: An welche IP-Adresse muss ein Anruf geleitet werden? Weil der Anruf als IP-Paket über ein IP-Netz übermittelt, also geroutet wird, handelt es sich hierbei um das Routing der Anrufe über IP-Netze. In diesem Zusammenhang spricht man von Telephony Routing over IP bzw. kurz von TRIP – siehe RFCs 2871 und 3219. Auf das Konzept von TRIP geht Abschnitt 9.2 näher ein.
www.wiwobooks.com
Routing der Anrufe als TRIP
9.1.1 Routing ankommender Anrufe aus dem ISDN/PSTN Das in Abbildung 9.1-1 geschilderte Problem bei ankommenden Anrufen aus dem ISDN/PSTN kann mit Hilfe von TRIP – wie dies Abbildung 9.1-2 zeigt – gelöst werden.
A n ru f a n T ln B m it d e r V o rw a h l 0 8 5 1
Z = H .3 2 3 - Z o n e
Z
1
B
G K 2
2
G K -P
IP -A d r? 4 IP -A d r
IT A D Y
H .3 2 3 0 8 5 2 ...
Z 1 0 8 5 1 ...
L S
R o u te ? 2 3
5
IP -A d r?
A n ru f
H .3 2 3 G K 1
T e iln e h m e r B
T e iln e h m e r A
6
A d m in is tra tiv e D o m ä n e Y : 0 8 5 ... ? G W IS D N /P S T N
Abb. 9.1-2: Routing ankommender Anrufe aus dem ISDN/PSTN GK: Gatekeeper, GK-P: GK-Proxy, GW: Gateway, LS: Location-Server, Z: VoIP-Zone
Nach TRIP wird jede administrative Domäne kurz als ITAD (IP Telephony Administrative Domain) bezeichnet. In jeder ITAD wird ein Location-Server (LS) installiert, in dem die sog. TRIPRouten abgespeichert werden. In einer TRIP-Route wird u.a. angegeben,
ITAD, TRIP-Route
380
9
IP-Telefonie-Routing und VoIP-Peering welches Signalisierungsprotokoll in der VoIP-Zone verwendet wird und welche IP-Adresse ein Server in der VoIP-Zone hat, auf dem die Tabelle mit den Zuordnungen Telefonnummer IP-Adresse verfügbar ist.
GatekeeperProxy in ITAD
Wie aus Abbildung 9.1-2 ersichtlich ist, enthält jede H.323-Zone einen Gatekeeper, in dem eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse für alle IP-Telefone dieser Zone enthalten ist. Innerhalb einer ITAD wird zusätzlich ein spezieller Gatekeeper GK-P eingerichtet, der für die von „außen“ kommenden Anrufe als Vertreter für Gatekeeper in allen H.323-Zonen auftritt. Dieser spezielle Gatekeeper kann als Gatekeeper-Proxy angesehen werden. Jeder von außen kommende Anruf, d.h. aus dem ISDN/PSTN, muss zuerst vom GatekeeperProxy zugelassen (akzeptiert) werden. Wird er akzeptiert, hat der Gatekeeper-Proxy die Aufgabe, die IP-Adresse des Ziel-IP-Telefons, dem der ankommende Anruf signalisiert werden muss, für das Gateway zu „besorgen“. Der Gatekeeper-Proxy enthält aber keine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse, sondern wählt aufgrund der Vorwahl in der Ziel-Telefonnummer des ankommenden Anrufs die entsprechende H.323-Zone aus und fragt nach der IPAdresse des Ziel-IP-Telefons beim Gatekeeper dieser Zone.
Beispiel für Routing eines ankommenden Anrufs
In Abbildung 9.1-2 verläuft die Ermittlung der IP-Adresse des Ziel-IP-Telefons bei einem ankommenden Anruf aus dem ISDN/PSTN nach dem folgenden Schema: 1.
Gateway fragt nach der IP-Adresse beim Gatekeeper-Proxy – Das Gateway der administrativen Domäne Y übermittelt an den Gatekeeper-Proxy GK-P die Telefonnummer des IPTelefons von Teilnehmer B (hier mit der Vorwahl 0851) und fragt ihn nach der IP-Adresse seines IP-Telefons. GK-P verfügt jedoch über keine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse für IP-Telefone der Zone Z1 mit der Vorwahl 0851, sondern muss die gewünschte IP-Adresse des IP-Telefons von Teilnehmer B beim Gatekeeper der Zone Z1 abfragen. Hierfür muss GK-P zuerst den Location-Server (LS) der ITAD Y nach der Route zum Gatekeeper der Zone Z1 fragen.
www.wiwobooks.com
Bemerkung: Das Protokoll zwischen Gatekeeper und LS wird bei TRIP nicht spezifiziert. Als LS könnte man einen LDAP-Server (Lightweight Directory Access Protocol) verwenden, somit würde LDAP auch als Protokoll zwischen Gatekeeper und LS dienen. 2.
Gatekeeper-Proxy ermittelt den richtigen Gatekeeper – GK-P übermittelt die Telefonnummer von Teilnehmer B an LS in ITAD Y und fragt ihn nach der Route zum Gatekeeper, bei dem die IP-Adresse des IP-Telefons von Teilnehmer B abgefragt werden kann. Aufgrund IPdes Präfix (Vorwahl 0851) stellt LS fest, dass die Zuordnungen Telefonnummer Adresse für die Telefonnummern mit diesem Präfix beim Gatekeeper GK1 der Zone Z1 vorhanden sind. LS übermittelt somit dem GK-P die Route zum Gatekeeper GK1 (d.h. de facto die IP-Adresse von GK1). Bemerkung: Man könnte GK-P so konfigurieren, dass er die IP-Adressen von anderen Gatekeepern kennt. Damit wäre der Location-Server nicht nötig. Da TRIP auch ein Protokoll zwischen den Location-Servern realisiert, entstehen durch den Einsatz eines Location-Servers ganz neue Möglichkeiten (vgl. z.B. Abb. 9.3-2).
3.
Gatekeeper-Proxy ermittelt die IP-Adresse – Nachdem GK-P die Route zum richtigen Gatekeeper GK1 vom LS erhalten hat, fragt er nun GK1 nach der IP-Adresse des IPTelefons von Teilnehmer B.
4.
Gateway erhält die IP-Adresse von Teilnehmer B vom Gatekeeper-Proxy – Nachdem der GK-P die gewünschte IP-Adresse des IP-Telefons von Teilnehmer B vom GK1 erhalten hat, übermittelt er sie dem Gateway zum ISDN/PSTN.
381
9.1 Typische Probleme bei VoIP 5.
Gateway leitet den ankommenden Anruf weiter – Hat das Gateway die IP-Adresse des IPTelefons von Teilnehmer B vom GK-P erhalten, leitet es den ankommenden Anruf aus dem ISDN/PSTN an das IP-Telefon von Teilnehmer B weiter.
Zwischen dem Telefon von Teilnehmer A und dem IP-Telefon von Teilnehmer B muss eine entsprechende Verbindung aufgebaut werden. Der Aufbau dieser Verbindung zwischen dem Telefon des Teilnehmers A und dem Gateway verläuft im ISDN nach dem D-Kanal-Protokoll (s. Abschnitt 2.3). Zwischen dem Gateway und dem Telefon des Teilnehmers B, d.h. innerhalb des IPNetzes, verläuft der Aufbau dieser Verbindung nach den Protokollen H.225.0 und H.245, die als H.323-Signalisierung angesehen werden können (s. Abschnitt 6.2). Die Ende-zu-Ende-Verbindung zwischen dem Telefon von Teilnehmer A und dem IP-Telefon von Teilnehmer B setzt sich somit aus einer physikalischen Verbindung im ISDN/PSTN zwischen dem Teilnehmer-ATelefon und dem Gateway einerseits sowie einer virtuellen Verbindung zwischen dem Gateway und dem Telefon von Teilnehmer B andererseits zusammen. Die virtuelle Verbindung innerhalb des IP-Netzes stellt eine VoIP-Session dar (s. Abschnitt 5.2-1).
Ende-zuEndeVerbindung
9.1.2 Routing abgehender Anrufe Das in Abbildung 9.1-1 dargestellte Problem bei abgehenden Anrufen aus einer VoIP-Zone einer administrativen Domäne zu einer VoIP-Zone einer anderen administrativen Domäne kann ebenfalls mit Hilfe von TRIP gelöst werden, wie Abbildung 9.1-3 zeigt. A d m in is tr a tiv e D o m ä n e X : 0 6 7 ...
www.wiwobooks.com
IT A D X S IP
0 6 7 2 ... Z
T e iln e h m e r A 1
3
H .3 2 3 Z 0 6 7 1 ...
IP -A d r? IP -A d r
1
L S
R
0 6 7 3 ... G K 3
H .3 2 3
4
2
A d m in is tr a tiv e D o m ä n e Y : 0 8 5 ...
T R IP
A
IP -N e tz (In te rn e t)
IT A D Y
R
2
5
A n ru f
G K 1
G K 2
H .3 2 3 0 8 5 2 ... T e iln e h m e r B
IP -A d r? 3
H .3 2 3 1 0 8 5 1 ...
B
Z R o u te ?
Z
L S
IP -A d r
Abb. 9.1-3: Routing abgehender Anrufe aus einer VoIP-Zone Abkürzungen wie Abbildung Abb. 9.1-2
Wie hier ersichtlich ist, verläuft die Ermittlung der IP-Adresse des IP-Telefons von Teilnehmer B in der administrativen Domäne Y (d.h. in ITAD Y) bei einem vom IP-Telefon des Teilnehmers A in der administrativen Domäne X initiierten Anruf wie folgt: 1.
Lokaler Gatekeeper wird nach der IP-Adresse gefragt – Das IP-Telefon des Teilnehmers A, der eine Verbindung zum IP-Telefon von Teilnehmer B in ITAD Y initiiert, fragt nach der IP-Adresse seines IP-Telefons beim lokalen Gatekeeper GK3 seiner Zone Z3. GK3 verfügt aber nur über eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse für die IPTelefone seiner Zone Z3 in ITAD X, d.h. der Zone mit der Vorwahl 0673, und nicht der Zone mit der „fremden“ Vorwahl 0852. GK3 muss daher beim Location-Server (LS) der ITAD Y die Route zum Gatekeeper der Zone mit der Vorwahl 0852 abfragen.
2.
Lokaler Gatekeeper bestimmt den richtigen Gatekeeper – Der lokale Gatekeeper GK3 übermittelt die Telefonnummer von Teilnehmer B an den LS in ITAD X und fragt ihn nach der
Beispiel
382
9
IP-Telefonie-Routing und VoIP-Peering Route zum Gatekeeper, bei dem er die IP-Adresse des IP-Telefons von Teilnehmer B abfragen kann. Mit Hilfe der Vorwahl 0852 stellt LS fest, dass der Gatekeeper GK2 der Zone Z2 in ITAD Y über die Zuordnungen Telefonnummer IP-Adresse für die Telefonnummern mit der Vorwahl 0852 verfügt. Der LS in ITAD X liefert dem GK3 die IP-Adresse vom Gatekeeper GK2 in ITAD Y.
3.
Lokaler Gatekeeper ermittelt die IP-Adresse – Nachdem der lokale Gatekeeper GK3 aus der Zone Z3 in ITAD X die Route zum Gatekeeper GK2 der Zone Z2 in ITAD Y vom LS erhalten hat, fragt er beim Gatekeeper GK2 der Zone Z3 in ITAD Y nach der IP-Adresse des IPTelefons von Teilnehmer B.
4.
Lokaler Gatekeeper übergibt die IP-Adresse – Nachdem der lokale Gatekeeper GK3 aus der Zone Z3 in ITAD X die IP-Adresse des IP-Telefons von Teilnehmer B vom Gatekeeper GK2 der Zone Z2 in ITAD Y erhalten hat, liefert er diese IP-Adresse an das IP-Telefon von Teilnehmer A.
5. Abgehender Anruf wird initiiert – Hat das IP-Telefon von Teilnehmer A die IP-Adresse des IP-Telefons von Teilnehmer B erhalten, weiß er, wohin er eine entsprechende Nachricht senden soll, um den Anruf zum IP-Telefon von Teilnehmer B zu initiieren.
9.2 TRIP als Protokoll zwischen LocationServern
Konzept und Einsatz von TRIP
Um die Sprachkommunikation zwischen verschiedenen administrativen Domänen uneingeschränkt ermöglichen zu können, muss in jeder Domäne entsprechend bekannt gemacht werden, wie die bei ihr installierten IP-Telefone als Anrufziele von „außen“ erreichbar sind. Diese Angaben können als Telefonie-Routen angesehen werden. Wie Abbildung 9.2-1 zeigt, ist TRIP ein Protokoll, nach dem die Location-Server von administrativen Domänen sich die TelefonieRouten gegenseitig bekannt machen können. Bei TRIP nennt man eine administrative Domäne ITAD (IP Telephony Administrative Domain) und bezeichnet zwei kommunizierende LocationServer als Peers und eine Verbindung zwischen ihnen als Peer-Verbindung.
www.wiwobooks.com
L S IT A D 1 0 0
Abb.9.2-1:
1
T R IP e x te rn a l P e e rs
L S 2
T R IP in te rn a l P e e rs IT A D 2 0 0
L S 3
T R IP e x te rn a l P e e rs
L S 4
IT A D 1 8 0
TRIP als Protokoll zwischen Location-Servern – siehe RFC 3219 ITAD: IP Telephony Administrative Domain, LS: Location-Server
TRIP wurde hauptsächlich für den Einsatz zwischen ITADs konzipiert. Es kann aber auch innerhalb einer ITAD für die Kommunikation zwischen internen Location-Servern eingesetzt werden. Somit kann eine Peer-Verbindung sowohl innerhalb einer ITAD (internal Peers) als auch zwischen unterschiedlichen ITADs (external Peers) aufgebaut werden.
TRIP bei H.323 und SIP
TRIP ist unabhängig vom Signalisierungsprotokoll und kann sowohl bei H.323 als auch bei SIP zum Einsatz kommen. TRIP ist kein Routing-Protokoll, sondern eine Applikation, die das zuverlässige Transportprotokoll TCP nutzt. Damit wird sichergestellt, dass die Garantie für die Übermittlung von TRIP-Nachrichten vom TCP übernommen wird. Zwischen zwei Peers wird daher für den Austausch von Telefonie-Routen eine TCP-Verbindung aufgebaut. Damit ist TRIP der Schicht 5 im Schichtenmodell zuzuordnen. Der Well-Known-Port von TRIP ist 6069.
9.2 Konzept und Einsatz von TRIP
383
Nachdem eine TCP-Verbindung zwischen Location-Servern als Peers aufgebaut wurde, wird zwischen ihnen eine TRIP-Nachbarschaft „geknüpft“. Sie kann als gegenseitige Bereitschaft, Nachrichten auszutauschen, angesehen werden und stellt eine Peer-Verbindung dar. Um eine Nachbarschaft aufzubauen, sendet jeder Peer eine Nachricht OPEN, in der die Identifikation der ITAD (My ITAD) und das „Absender“-Peer angegeben wird. Die Nachricht OPEN wird von der Gegenseite mit KEEPALIVE bestätigt.
Aufbau einer Nachbarschaft zwischen LSn
Nach dem Aufbau der TRIP-Nachbarschaft kündigen die Peers die ihnen bekannten TelefonieRouten zu ihren ITADs mittels der Nachricht UPDATE an. Der Name UPDATE kommt daher, dass es sich im Laufe der Zeit überwiegend um die Aktualisierungen (Updates) von Telefonie-Routen handelt. Falls sich die Lage in ITAD ändert, z.B. ein Anrufziel plötzlich nicht erreichbar ist, informiert ein Peer seinen Nachbarn darüber, dass die ungültig gewordene Route zurückgezogen wurde und eventuell durch eine neue ersetzt bzw. vollkommen entfernt werden soll. Die ungültig gewordenen Routen können in einer Nachricht UPDATE angegeben werden.
Austausch von Telefonie-Routen in UPDATE
Falls keine neuen Telefonie-Routen (keine Veränderungen) vorliegen, wird die Nachricht KEEPALIVE periodisch als Lebenszeichen zwischen den Peers gesendet, um der Gegenseite die Funktionsbereitschaft zu signalisieren. Ein Peer kann eine Nachricht NOTIFICATION senden, um seinem Nachbarn eine Fehlermeldung zu signalisieren. NOTIFICATION wird immer nach der Entdeckung eines Fehlers verschickt und kann zum Abbruch der Peer-Verbindung führen. Falls ein Peer die Verbindung abbauen möchte, sendet er NOTIFICATION, in der er auch den Grund für den Abbau der Verbindung angibt.
„Ich lebe noch“
9.2.1 Bedeutung von TRIP
www.wiwobooks.com
Soll die Sprachkommunikation zwischen zwei IP-Telefonen aus verschiedenen administrativen Domänen stattfinden, muss das IP-Telefon, das die Verbindung initiiert, das Anrufziel in Form einer IP-Adresse in der anderen Domäne kennen, um den Anruf mit einer Nachricht zu signalisieren. Mit jedem Anrufziel ist somit eine Telefonie-Route über das IP-Netz verbunden. Wie Abbildung 9.2-2 illustriert, entsteht folgendes Problem: Wie können die Anrufziele in Form von IP-Adressen in einer Domäne den anderen Domänen bekannt gemacht werden? Es handelt sich hierbei um das gleiche Problem, das beim Routing in IP-Netzen entsteht. Um es zu lösen, könnte man in jeder administrativen Domäne einen Location-Server installieren, auf dem alle Anrufziele in seiner Domäne abgespeichert werden. Die Location-Server einzelner Domänen sollten sich die Anrufziele gegenseitig bekannt machen, wie es beim IP-Routing der Fall ist.
IT A D IT A D
R IP -N e tz (In te rn e t) R L S
L S R : R o u te r L S : L o c a tio n -S e rv e r
IT A D R
IT A D R
L S
T R IP
L S
Abb. 9.2-2: Bekanntmachung von Telefonie-Routen zwischen administrativen Domänen Wie Abbildung 9.2-2 zeigt, ist TRIP das Protokoll, nach dem die Location-Server einzelner Domänen sich die Telefonie-Routen und somit auch die Anrufziele gegenseitig bekannt machen.
Anrufziel als TelefonieRoute
384
9
IP-Telefonie-Routing und VoIP-Peering
Beim TRIP-Einsatz ist der Location-Server jeder ITAD in der Lage, die Telefonie-Routen in anderen ITADs von anderen Location-Servern zu erlernen. Da TRIP das Transportprotokoll TCP nutzt, um die Telefonie-Routen zu übermitteln, müssen zwischen den Location-Servern TCP-Verbindungen aufgebaut werden. Die in Abbildung 9.2-2 dargestellte Lösung hat somit den Nachteil, dass jeder Location-Server zu jedem anderen in den restlichen ITADs jeweils eine TCP-Verbindung haben muss. Eine derartige Lösung in einem „offenen“ System, in dem zu jedem Zeitpunkt eine neue ITAD einfach hinzukommen kann, kommt damit nicht in Frage.
Bedeutung der Koordinationsstelle
Um Skalierbarkeit zu garantieren, könnte man einen übergeordneten Location-Server installieren, der beispielsweise einer Koordinationsstelle zugeordnet wird. Eine derartige Stelle bezeichnet man oft auch als Clearinghouse (s. auch Abschnitt 9.5.4). Wie in Abbildung 9.2-3 zum Ausdruck kommt, fungiert der übergeordnete Location-Server als Verteiler von Telefonie-Routen an die Location-Server in den einzelnen ITADs. Hierbei muss jeder Location-Server nur eine TCPVerbindung zum übergeordneten Location-Server an der Koordinationsstelle einrichten. IT A D R
In te rn e t R
IT A D
IT A D R R
IT A D
6
L S
L S
T R IP
In te rn e t
...
L S
T R IP
L S
L S K o o rd in a tio n s s te lle C le a rin g h o u s e
www.wiwobooks.com R : R o u te r L S : L o c a tio n -S e rv e r
Abb. 9.2-3: Bekanntmachung von Telefonie-Routen zwischen administrativen Domänen (ITADs) über eine Koordinationsstelle
TRIP als Weg zur InternetTelefonie
Die in Abbildung 9.2-3 dargestellte Lösung für die Bekanntmachung von Telefonie-Routen kann als allgemeines Modell für eine offene Vernetzung administrativer Domänen (ITADs) mit VoIP angesehen werden. Hierbei ist Folgendes hervorzuheben: Stellt eine ITAD eine Domäne eines ISP (Internet Service Provider) dar, ist hier ersichtlich, dass die ISPs künftig die klassische Telefonie durch Internet-Telefonie ersetzen können. Ist z.B. eine ITAD ein Unternehmen und steht eine Koordinationsstelle mit einem übergeordneten Location-Server zur Verfügung, können die Unternehmen ihre Telefongespräche über das Internet bzw. ein anderes weltweites IP-Netz abwickeln. Dank dem TRIP-Konzept kann das Internet auch als Plattform zur Sprachkommunikation dienen.
9.2.2 TRIP als Bruder von BGP In Protokollen für die Datenkommunikation über IP-Netze zwischen administrativen Domänen (Unternehmen, öffentliche Verwaltungen usw.) bezeichnet man diese administrativen Domänen als autonome Systeme (AS). Im Allgemeinen besteht ein autonomes System aus einer Vielzahl von IP-Subnetzen und wird von einer Organisation verwaltet. Um eine uneingeschränkte Rechnerkommunikation über das Internet bzw. andere IP-Netze zwischen verschiedenen autonomen Systemen zu ermöglichen, werden spezielle Router, die sog. Border-Gateways(-Router), am „Rande“ einzelner autonomer Systeme eingesetzt. Die Border-Gateways teilen sich nach dem Protokoll BGP (Border Gateway Protocol) gegenseitig mit, welche Routing-Ziele es in den ein-
9.3 Vernetzung von VoIP-Zonen mit H.323 zelnen autonomen Systemen gibt [s. BaHo 07]. BGP wurde bereits im Jahre 1989 eingeführt und seit dieser Zeit mehrfach verbessert. Die BGP-Version 4 (kurz BGP-4) ist die letzte BGPVersion (seit 1993); RFC 4271 enthält ihre aktuelle Spezifikation. Abbildung 9.2-4 zeigt, dass dem TRIP eine ähnliche Idee wie dem BGP zugrunde liegt. A d m in is tra tiv e D o m ä n e Y
S N S N
B G
B G P
Z
S p ra c h e
B G P
S N
B G
L S
T R IP
L S
S N
Y
D a te n S N
IT A G Y
In te rn e t
... ...
Z
B G
B G
IT A G X Z
A u to n o m e s S y s te m
IS P
L S
... ...
S N
IS P
... ...
D a te n
... ...
A d m in is tra tiv e D o m ä n e X A u to n o m e s S y s te m X
T R IP
L S Z
S p ra c h e
Z Z
Abb. 9.2-4: TRIP und BGP als sich gegenseitig ergänzende Ansätze BG: Border-Gateway (-Router); LS: Location-Server; SN: IP-Subnetz; Z: VoIP-Zone
Das TRIP-Protokoll stellt eine Kopie des Protokolls BGP-4 dar, in der einige Anpassungen an die Besonderheiten der Sprachkommunikation vorgenommen wurden. Ein Border-Gateway bei BGP entspricht einem Location-Server bei TRIP. Bei der Beschreibung des Protokolls BGP findet man Begriffe und Nachrichten mit der gleichen Bedeutung wie bei TRIP. Hierzu gehören u.a.: Peers, Nachbarschaft, OPEN, UPDATE, NOTIFICATION und KEEPALIVE. Das TRIP-Protokoll kann somit als „Bruder“ von BGP angesehen werden.
www.wiwobooks.com
Wie Abbildung 9.2-4 zeigt, entspricht ein autonomes System (AS) von BGP einer administrativen Domäne von TRIP (ITAD). Ein AS setzt sich in der Regel aus mehreren IP-Subnetzen zusammen. Eine ITAD kann mehrere VoIP-Zonen (Z) enthalten. Eine VoIP-Zone kann ein bzw. mehrere IP-Subnetze umfassen. Bei BGP senden die Border-Gateways ihre Nachrichten mit Hilfe des verbindungsorientierten Transportprotokolls TCP genau wie bei TRIP. Der Einsatz des Protokolls BGP hat dazu geführt, dass die weltweite Datenkommunikation über das Internet ein normaler, selbstverständlicher Vorgang geworden ist. Man kann erwarten, dass die Idee von TRIP dazu führen wird, dass Internet-Telefonie künftig eine ernsthafte Konkurrenz für die klassische Telefonie sein wird.
9.3
Vernetzung von VoIP-Zonen mit H.323
Eine administrative Domäne kann mehrere VoIP-Zonen enthalten. In jeder von ihnen lässt sich entweder H.323 oder SIP als Signalisierungsprotokoll einsetzen. Bei der Sprachkommunikation zwischen den verschiedenen VoIP-Zonen muss das Telefonie-Routing realisiert werden. Dieser Abschnitt beschreibt das Routing zwischen VoIP-Zonen mit H.323.
9.3.1 Routing abgehender Anrufe zwischen H.323-Zonen Wie ein abgehender Anruf aus einer H.323-Zone zu einer anderen geroutet wird, illustriert Abbildung 9.3-1. Das dargestellte Beispiel zeigt die Sprachkommunikation zweier Unternehmen miteinander, bei denen jeweils ein Location-Server installiert wurde. Die beiden Location-Server
385
386
9
IP-Telefonie-Routing und VoIP-Peering
sind nach dem TRIP-Konzept external Peers (vgl. Abb. 9.2-1) und teilen sich gegenseitig die Telefonie-Routen mit.
0 6 1 6 ...
T e iln e h m e r A
0 6 1 7 ... Z 2 1
G K
6
2
Z 1
Z 2
A R Q A C F
G K
3
L S 1
0 6 1 8 ...
3 5
X
T R IP
U n te r n e h m e n Y IT A D Y 0 1 2 4 ... Z 2 L S Y G K Z
G K 3
L S -A b fra g e
4 S E T U P
IT A D X
3
0 1 2 5 ... G K
0 1 2 3 ... G K
3
L R Q
A u fb a u e in e r T C P -V e rb in d u n g
2
L C F
A u fb a u e in e r V o I P - S e s s io n n a c h H .3 2 3
1
Z 1
T e iln e h m e r B
U n te r n e h m e n X
Abb. 9.3-1: Routing eines abgehenden Anrufs zwischen H.323-Zonen GK: Gatekeeper, LS: Location-Server, ARQ: AdmissionReQuest, ACF: AdmissionConFirm, LRQ: LocationReQuest, LCF: LocationConFirm, Z: (H.323-)Zone
Beispiel für Routing eines abgehenden Anrufs
In Abbildung 9.3-1 initiiert das IP-Telefon von Teilnehmer A in ITAD X eine Verbindung zum IP-Telefon von Teilnehmer B in ITAD Y. Hierbei sind folgende Schritte zu unterscheiden:
www.wiwobooks.com
1.
Lokaler Gatekeeper fragt nach der IP-Adresse des Ziel-IP-Telefons – Das IP-Telefon von Teilnehmer A, der eine Verbindung initiiert, fragt beim Gatekeeper GK2 mit der Nachricht ARQ (AdmissionRequest) des Protokolls H.225.0, ob der abgehende Anruf von ihm zugelassen wird und welche IP-Adresse das IP-Telefon des Teilnehmers B hat (s. Abschnitt 6.3.3). GK2 verfügt aber nur über eine Tabelle mit den Zuordnungen Telefonnummer IP-Adresse für die IP-Telefone der Zone mit der Vorwahl 0617 im eigenen Unternehmen X und nicht der Zone mit der Vorwahl 0123 im Unternehmen Y. GK2 muss somit die Route zum Gatekeeper der Zone mit der fremden Vorwahl 0123 beim Location-Server LS der eigenen ITAD X abfragen.
2.
Lokaler Gatekeeper ermittelt den richtigen Gatekeeper – GK2 übermittelt nun die Telefonnummer von Teilnehmer B an LSX in seiner ITAD X und fragt ihn nach der Route zum Gatekeeper, bei dem er die IP-Adresse des IP-Telefons von Teilnehmer B abfragen kann. Anhand der Vorwahl 0123 in der Telefonnummer von Teilnehmer B stellt LSX in ITAD X fest, dass der Gatekeeper GK1 der Zone Z1 in ITAD Y abgefragt werden soll. LSX aus ITAD X liefert damit dem GK2 die IP-Adresse von GK1 in ITAD Y.
3.
IP-Adresse des Ziel-IP-Telefons wird abgefragt – Nachdem GK2 aus der Zone Z2 in ITAD X die Route zum GK1 der Zone Z1 in ITAD Y vom LSX erhalten hat, fragt er bei GK1 mit der H.225.0-Nachricht LRQ (LocationReQuest) nach der IP-Adresse des IP-Telefons von Teilnehmer B. Er sendet ihm die gesuchte IP-Adresse in der H.225.0-Nachricht LCF (LocationConFirm) zurück (s. Abschnitt 6.3.4).
4.
Lokaler Gatekeeper übergibt die IP-Adresse – Nachdem GK2 in ITAD X die IP-Adresse des IP-Telefons von Teilnehmer B vom GK2 in ITAD Y erhalten hat, liefert er diese IP-Adresse in der H.225.0-Nachricht ACF (AdmissionConFirm) an das IP-Telefon von Teilnehmer A.
9.3 Vernetzung von VoIP-Zonen mit H.323 5.
Aufbau einer TCP-Verbindung – Hat das IP-Telefon von Teilnehmer A die IP-Adresse des IP-Telefons von Teilnehmer B erhalten, initiiert er den Aufbau einer TCP-Verbindung zum IP-Telefon von Teilnehmer B.
6.
Anruf wird weitergeleitet – Nachdem die TCP-Verbindung zum IP-Telefon von Teilnehmer B aufgebaut wurde, leitet das IP-Telefon von Teilnehmer A mit der H.225.0-Nachricht SETUP den abgehenden Anruf zum IP-Telefon von Teilnehmer B weiter.
387
9.3.2 Routing der Anrufe aus dem ISDN zu einer H.323-Zone Abbildung 9.3-2 illustriert, wie ein abgehender Anruf aus dem ISDN zu einer H.323-Zone innerhalb einer administrativen Domäne geroutet wird.
A d m in is tr a tiv e D o m ä n e
6
IS D N
G K 1
Z 1
G W
Z
T e iln e h m e r A
G K -P
S E T U P [ ..., 0 6 8 4 ..., ...]
V e r la u f n a c h d e m D -K a n a l-P r o to k o ll
A R Q 1
A C F 6
IT A D
S ta n d o r t A
0 6 8 1 ...
L S
0 6 8 2 ... 2
G K
L S
S ta n d o r t B Y
0 6 8 4 ... Z G K
3
4
T R IP
2
L S -A b fra g e 2
X
Z
0 6 8 3 ... 3
4
G K 3
4
L R Q
L C F A u fb a u e in e r T C P -V e rb in d u n g
T e iln e h m e r B
www.wiwobooks.com S E T U P
5
A u fb a u e in e r V o I P - S e s s io n n a c h H .3 2 3
Abb. 9.3-2: Routing eines abgehenden Anrufs aus dem ISDN zu einer H.323-Zone GK-P: Gatekeeper-Proxy, GW: Gateway, weitere Abkürzungen wie in Abbildung 9.3-1
In diesem Beispiel handelt es sich um die Sprachkommunikation innerhalb eines großen Unternehmens, das auf zwei Standorte verteilt ist. Der ISDN-Anschluss wurde hier nur am Standort A eingerichtet. Auf jedem Standort werden jeweils mehrere H.323-Zonen eingerichtet. Zusätzlich wird in jedem Standort ein Location-Server installiert. Die beiden Location-Server LSX und LSY machen sich die Telefonie-Routen mit TRIP bekannt. Nach dem Eintreffen der Nachricht SETUP aus dem ISDN beim Gateway GW, mit der ein ankommender Anruf an den Teilnehmer B in der Zone Z4 (Vorwahl 0684) signalisiert wird, muss das Gateway nun SETUP an das IP-Telefon von Teilnehmer B weiterleiten. Wie Abbildung 9.3-2 zeigt, sind hierbei folgende Schritte zu unterscheiden, die weitgehend den Schritten aus Abbildung 9.1-2 entsprechen: 1.
Beispiel für das Routing eines abgehenden Anrufs aus Gatekeeper-Proxy wird nach der IP-Adresse des Ziel-IP-Telefons befragt – Das Gateway dem ISDN (GW) fragt beim Gatekeeper-Proxy (GK-P) mit der Nachricht ARQ (AdmissionReQuest) des Protokolls H.225.0, ob der ankommende Anruf von ihm zugelassen wird und welche IPAdresse das IP-Telefon des Teilnehmers B hat. GK-P muss somit die Telefonie-Route zum Gatekeeper der Zone mit der Vorwahl 0684 beim Location-Server LSX abfragen.
2.
Gatekeeper-Proxy ermittelt den richtigen Gatekeeper – GK-P übermittelt nun die Telefonnummer von Teilnehmer B an den LSX am Standort A und fragt ihn nach der Route zum Gatekeeper, bei dem er die IP-Adresse des IP-Telefons von Teilnehmer B abfragen kann.
9
IP-Telefonie-Routing und VoIP-Peering Nach der Vorwahl 0684 in der Telefonnummer stellt LSX fest, dass der Gatekeeper GK4 der Zone Z4 am Standort B abgefragt werden soll. LSX liefert an GK-P die IP-Adresse von GK4.
3.
IP-Adresse des Ziel-IP-Telefons wird abgefragt – Hat GK-P die Route zum GK4 vom LSX erhalten, fragt er bei GK4 mit LRQ nach der IP-Adresse des IP-Telefons von Teilnehmer B. GK4 sendet dem GK-P die gesuchte IP-Adresse in LCF zurück.
4.
Gatekeeper-Proxy übergibt die IP-Adresse – Nachdem GK-P die IP-Adresse des IP-Telefons von Teilnehmer B vom GK4 erhalten hat, liefert er diese IP-Adresse in der Nachricht ACF an das Gateway (GW).
5.
Aufbau einer TCP-Verbindung – Hat GW die IP-Adresse des IP-Telefons von Teilnehmer B erhalten, initiiert er den Aufbau einer TCP-Verbindung zu seinem IP-Telefon.
6.
Abgehender Anruf wird initiiert – Nachdem die TCP-Verbindung zum IP-Telefon von Teilnehmer B aufgebaut wurde, leitet GW durch Absenden von SETUP den eingehenden Anruf zum IP-Telefon von Teilnehmer B weiter.
9.4
Vernetzung von VoIP-Zonen mit SIP
Eine administrative Domäne kann mehrere VoIP-Zonen enthalten, in denen SIP als Signalisierungsprotokoll eingesetzt wird. SIP definiert einen Location-Server, der weitgehend dem Location-Server bei TRIP entspricht. Bereits in Kapitel 7 wurde mehrmals auf die Bedeutung von Location-Servern eingegangen (s. Abbildungen 7.2-2 und -3). Bei der Sprachkommunikation zwischen verschiedenen VoIP-Zonen mit SIP muss ein entsprechendes Telefonie-Routing realisiert werden, und dieser Abschnitt zeigt, wie dies erfolgen kann.
www.wiwobooks.com
9.4.1 Routing der Anrufe zwischen VoIP-Zonen mit SIP Abbildung 9.4-1 illustriert, wie man das Routing eines Anrufs zwischen verschiedenen VoIPZonen mit SIP realisiert. Das Beispiel illustriert die VoIP-Kommunikation zwischen zwei Unternehmen Sonne und Mond, die nach TRIP entsprechend als ITAD X und ITAD Y identifiziert werden. Das Unternehmen Mond wird beispielsweise auf die beiden Standorte Hamburg und München verteilt, die hier entsprechend als die Internet-Domänen mond-hh.de und mond-m.de dargestellt werden. Diese beiden Internet-Domänen bilden die ITAD Y.
T e iln e h m e r A
1
S IP S e rv
IN V IT E
IT A D X L S
L S -A b fra g e 2
L S
T R IP
Z
T R IP
T R IP X
3
U n te rn e h m e n M o n d
S IP S e rv
m o n d - h h .d e
U n te rn e h m e n S o n n e
L S
m o n d - m .d e
T e iln e h m e r B
Y
S IP S e rv
IN V IT E 4 L S -A b fra g e A u fb a u e in e r V o IP -S e s s io n n a c h S IP
Abb. 9.4-1: Abgehender Anruf beim SIP-Einsatz und TRIP LS: Location-Server, Serv: Server
5
IN V IT E
0 7 3 1 2 3 4 5 @ m o n d - m .d e
IT A D Y
0 4 1 7 8 9 9 @ s o n n e .d e
388
9.4 Vernetzung von VoIP-Zonen mit SIP Das IP-Telefon des Teilnehmers A in ITAD X initiiert eine Verbindung zum IP-Telefon von Teilnehmer B in ITAD Y. Hierbei sind folgende Schritte zu unterscheiden: 1.
389
Verlauf von TelefonierIP-Telefon initiiert eine Verbindung – Das IP-Telefon von Teilnehmer A in ITAD X initiiert Routing
eine Verbindung zum IP-Telefon von Teilnehmer B in ITAD X durch Absenden der SIPNachricht INVITE mit der SIP-Adresse [email protected] an den SIP-Server. Diese Adresse besagt, dass es sich um die Telefonnummer 07312345 in der Internet-Domain mond-m.de handelt. Der SIP-Server des Anruf-Initiators weiß aber nicht, an welche IPAdresse in ITAD Y die Nachricht INVITE weitergeleitet werden soll. Hierfür muss der Location-Server abgefragt werden. 2.
SIP-Server des Anruf-Initiators ermittelt den Ziel-SIP-Server – Der SIP-Server des AnrufInitiators übermittelt nun die SIP-Adresse von Teilnehmer B an den LSX in seiner InternetDomain und fragt ihn nach der Route zum SIP-Server der ZielDomäne, an die er die Nachricht INVITE weiterleiten soll.
3.
SIP-Server des Anruf-Initiators leitet den Anruf weiter – Nachdem der SIP-Server des Anruf-Initiators vom LSX die IP-Adresse vom Ziel-SIP-Server in der Domäne mond-m.de erhalten hat, leitet er INVITE an ihn weiter.
4.
Ziel-SIP-Server ermittelt die Ziel-IP-Adresse – Hat der Ziel-SIP-Server INVITE empfangen, muss er nun die IP-Adresse des Teilnehmers B ermitteln. Hierfür fragt er den LocationServer seiner Domäne nach der IP-Adresse des Ziel-Anrufs.
5.
Anruf wird zum Ziel geleitet – Nachdem der Ziel-SIP-Server die IP-Adresse des IP-Telefons von Teilnehmer B erhalten hat, leitet er die SIP-Nachricht INVITE zum IP-Telefon des Teilnehmers B weiter.
www.wiwobooks.com
9.4.2 Routing der ISDN-Anrufe zu VoIP-Zonen mit SIP
Abbildung 9.4-2 illustriert, wie man einen ankommenden Anruf aus dem ISDN zu einer VoIPZone mit SIP innerhalb einer administrativen Domäne realisiert. Hier handelt es sich um die Sprachkommunikation innerhalb eines großen Unternehmens, das auf drei Standorte verteilt ist. Der ISDN-Anschluss wurde nur am Standort A eingerichtet.
6
IS D N
S E T U P [ ..., 0 6 8 3 ..., ...]
V e r la u f n a c h d e m D -K a n a l-P r o to k o ll
IT A D
S ta n d o r t B 0 6 8 2 - ...
S ta n d o r t A
G W
S IP S e rv
1 IN V IT E
0 6 8 1 - ...
L S L S
L S -A b fra g e 2
Z
T R IP X
3
S IP S e rv L S Y
T e iln e h m e r B
S ta n d o r t C S IP - 0 6 8 3 - ... S e rv
IN V IT E
4 L S -A b fra g e A u fb a u e in e r V o IP -S e s s io n n a c h S IP 5
IN V IT E
0 6 8 3 _ 2 3 4 @ s o n n e .d e
T e iln e h m e r A
A d m in is tra tiv e D o m ä n e S o n n e
Abb. 9.4-2: Routing eines ankommenden ISDN-Anrufs zu einer VoIP-Zone mit SIP GW: Gateway, LS: Location-Server, Serv: Server
Nach dem Empfangen der Nachricht SETUP aus dem ISDN, mit der der ankommende Anruf dem Teilnehmer B am Standort C (Vorwahl 0683) signalisiert wird, muss das Gateway GW nun
390
9
IP-Telefonie-Routing und VoIP-Peering
eine SIP-Nachricht INVITE an das IP-Telefon des Teilnehmers B weiterleiten. Das Gateway weiß aber nicht, welche IP-Adresse das IP-Telefon des Teilnehmers B hat. Vergleicht man die Abbildungen 9.4-1 und -2 miteinander, so erkennt man, dass – aus Sicht von SIP – das Gateway als Anruf-Initiator angesehen werden kann. In diesem Fall vollzieht man beim SIP-Verlauf in den Abbildungen 9.4-1 und -2 die gleichen Schritte mit der gleichen Bedeutung. Sie wurden bereits bei der Darstellung des Verlaufs in Abbildung 9.4-1 näher erläutert.
9.5 SPEERMINT
Peering bei VoIP mit SIP
VoIP mit SIP wird immer öfter von als SSP (SIP Service Provider) bezeichneten Providern angeboten. Daher sind Lösungen dafür notwendig, dass jeder SSP mit einem anderen SSP paarweise kooperieren kann. Man spricht hier von VoIP-Peering. Die entsprechenden Konzepte werden als SPEERMINT (Session PEERing for Multimedia INTerconnect) bezeichnet.2 SPEERMINT stellt ein Framework dar, das festlegt, wie ENUM und DNS miteinander kooperieren sollen, um klassische „Telefoninseln“ mit traditionellen Telefonrufnummern an das Internet anbinden zu können. SPEERMINT spezifiziert u.a. mehrere Peering-Modelle, nach denen verschiedene SSPs miteinander kooperieren können. Hierbei bildet ein SSP eine DNS-Domain.
9.5.1 Ziele und Arten von Peering Ziel von Peering
www.wiwobooks.com
Die klassische „Telefonwelt“ sollte so lange bestehen, wie sie ihre Funktion richtig erfüllt. Aber sie muss so mit dem Internet integriert werden, dass volle Funktionalität der klassischen „Tele3 fonwelt“ weiterhin verfügbar bleibt. Das Peering bei VoIP mit SIP sollte dies ermöglichen. Abbildung 9.5-1 illustriert die grundlegende Idee von Peering.
A
S S P A k
A
6
P
1
D N S /E N U M In te rn e t (IP -N e tz )
P
D o m a in A
P e e rin g -P u n k t
P
D o m a in B
X
P 1
S S P X D o m a in X X
B
S S P B B
1
m
n
Abb. 9.5-1: Grundlegende Idee von Peering bei VoIP mit SIP – Einsatz von DNS/ENUM A1, ..., Ak; B1, ..., Bm; C1, ..., Cn: Telefonnummern, SSP: SIP Service Provider
Wie aus dieser Abbildung hervorgeht, muss die Vernetzung der VoIP-Domains mit SIP über das Internet bzw. ein anderes IP-Netz gewährleisten, dass jeder VoIP-Teilnehmer mit jedem anderen Teilnehmer aus einer beliebigen Domain telefonieren bzw. eine andere multimediale Kommunikation betreiben kann. Peering soll also ermöglichen, dass jeder SSP mit jedem anderen SSP eine entsprechende Vereinbarung in Bezug auf die Sprachkommunikation treffen kann. VoIP-Peering bedeutet somit eine Zusammenschaltung von VoIP-Domains. 2
Die Entwicklung von SPEERMINT koordiniert die gleichnamige Working Group bei der IETF – siehe http://www.ietf.org/dyn/wg/charter/speermint-charter.html
3
Weil es sich hier ausschließlich um VoIP-Peering handelt, wird dieses als Peering abgekürzt.
391
9.5 Peering bei VoIP mit SIP Jeder SSP muss eine Systemkomponente zur Verfügung stellen, über die seine Domain mit der Domain eines anderen SSP verbunden werden soll und in der einerseits die notwendige Zugangsregel (Access Policy) realisiert und andererseits die für gegenseitige Zahlungen benötigten Daten erfasst werden können. Eine derartige Systemkomponente stellt einen sog. Peering-Punkt dar. Als Peering-Punkt kann ein SIP-Proxy bzw. ein sog. Session Border Controller (SBC) eingesetzt werden.
PeeringPunkt
Im Allgemeinen ist zwischen folgenden Arten von Peering zu unterscheiden: Bilaterales Peering – Punkt-zu-Punkt-Verbund von Domains verschiedener SSPs, d.h., die Peering-Punkte in zwei verschiedenen Domains werden direkt miteinander verbunden. Hierfür sieht SPEERMINT folgende Peering-Modelle vor: − Basic Peering – Dieses Modell basiert auf dem Verlauf von SIP über SIP-Proxies. Als Peering-Punkte dienen in diesem Modell die SIP-Proxies beider SSPs. Abbildung 9.5-2 zeigt dies. − Integrated Peering – In diesem Modell fungieren SBCs beider SSPs als Peering-Punkte. Die Besonderheit von Integrated Peering besteht darin, dass jeder SBC zwei Funktionsmodule enthält: SBE (Signaling-path Border Element) und DBE (Data-path Border Element). Sie sind nach außen hin als integriertes Modul sichtbar. Bei Integrated Peering verlaufen die Signalisierung und die Übermittlung von Echtzeitmedien (Sprache, Video) über die beiden SBCs als Peering-Punkte. − Decomposed Peering – Dieses Modell ähnelt weitgehend dem Integrated Peering. Der Unterschied zwischen ihnen besteht darin, dass SBE und DBE im SBC nicht integriert, sondern nur gekoppelt sind, sodass man sie sogar als getrennte Hardware-Komponenten realisieren kann.
Bilaterales Peering
Multilaterales Peering – stellt eine Stern-Topologie dar, in der die Peering-Punkte aller Domains zu einem zentralen Koordinationsknoten, der als Anbieter der Peering-Dienste dient, angebunden sind. Mit Federation Peering soll diese Peering-Art nach SPEERMINT unterstützt werden.
Multilaterales Peering
www.wiwobooks.com
Bei der Kommunikation zwischen zwei Domains gibt es zwei Beteiligte (den SSP des Anrufers und den SSP des Angerufenen), um untereinander die Kosten der Kommunikation in Form eingenommener Gebühren zu begleichen. Bei der Auswahl eines für die Zusammenschaltung von Domains geeigneten Abrechnungsregimes müssen sowohl die Kostenverteilung auf die zusammengeschalteten Domains beider SSPs als auch deren Nutzen entsprechend berücksichtigt werden. Bei VoIP-Peering kommt als Abrechnungsregime in Frage:
Abrechnungsregime bei Peering
CPNP (Calling Party Network Pay) – Bei CPNP übernimmt der Anrufer die Gebühren, und der SSP des Anrufers zahlt ein Terminierungsentgelt an den SSP des Angerufenen;
CPNP
RPNP (Receiving Party Network Pay) – Bei RPNP übernimmt der Angerufene die Gebühren und der SSP des Angerufenen zahlt ein Terminierungsentgelt an den SSP des Anrufers;
RPNP
B&K (Bill & Keep) – kann als Tauschgeschäft zwischen den SSPs angesehen werden, bei dem für die Nutzung der VoIP-Dienste keine Zahlungsströme von einem SSP an einen anderen SSP fließen. Ein reines Abrechnungsregime B&K bei VoIP-Peering basiert somit auf der Vereinbarung, dass die SSPs die gegenseitigen Zusammenschaltungskosten so gegeneinander aufrechnen, dass es zu keinen Zahlungen zwischen ihnen kommt. B&K entspricht dem Peering-Regime im herkömmlichen Internet.
B&K
Beabsichtigen zwei SSPs, ihre Domains zusammenzuschalten, müssen sie ein Peering-Abkommen vereinbaren und unterzeichnen. Bei Basic, Integrated und Decomposed Peering muss jeder SSP mit allen anderen SSPs de facto ein Peering-Abkommen abschließen. Das ist aber ein Nachteil. Bei einer großen Anzahl von SSPs ist das zu aufwendig. Es ist sinnvoller, eine zentrale Stelle einzurichten, die als Peering-Koordinator fungiert und mit der jeder SSP ein Peering-Abkommen abschließt. Diese Idee wird bei Federation-based Peering verfolgt.
PeeringAbkommen
392
9
IP-Telefonie-Routing und VoIP-Peering
9.5.2 Prinzip von Basic Peering Basic Peering setzt voraus, dass der SIP-Proxy in der Domain eines SSP als Peering-Punkt fungiert. Abbildung 9.5-2 illustriert das Prinzip von Basic Peering. S S P A D o m a in A
D N S P ro x y S IG
D N S
D N S E N U M S IG
In te r n e t (S ig n a lis ie ru n g )
P ro x y S IG
S S P B D D o o m m a a i ni n B B S IP -P ro x y
S p ra c h e
Abb. 9.5-2: Basic Peering – Einsatz von SIP-Proxies als Peering-Punkte Bei Basic Peering handelt es sich um einen klassischen SIP-Verlauf. Zu diesem Zweck richtet ein SSP seinen SIP-Proxy als Peering-Punkt ein. Die wichtigste Besonderheit von Basic Peering besteht aber darin, dass nur die Signalisierung über den SIP-Proxy verläuft und Sprache bzw andere Echtzeitmedien über andere Wege übermittelt werden – also in der Regel außerhalb von SIP-Proxies und direkt zwischen den Endeinrichtungen. In diesem Fall kann der eigentliche Datenverkehr an Peering-Punkten vorbei verlaufen. Da die Signalisierung nur über die Peering-Punkte verläuft, eignet sich Basic Peering eigentlich nur für das Abrechnungsregime Bill & Keep, in dem volle Symmetrie des VoIP-Verkehrs herrscht, d.h., in dem sich die beiden SSPs als Peering-Partner verkehrsmäßig gleich stark belasten, sodass Zusammenschaltungsentgelte sowie die Gebühren für den VoIP-Verkehr aus ökonomischer Sicht keinen Sinn haben.
www.wiwobooks.com
SIP-Verlauf beim Basic Peering
Weil die SIP-Proxies beim Basic Peering in den beiden zusammengeschalteten Domains als Peering-Punkte fungieren, wie dies Abbildung 9.5-3 zeigt, verläuft die Signalisierung nach SIP fast unverändert – s. auch Abbildung 7.1-8. Der SIP-Proxy der Domain, in der eine VoIP-Verbindung initiiert wird, muss – nach SPEERMINT – die IP-Adresse des SIP-Proxy der Ziel-Domain allein auf Basis der Telefonnummer des gerufenen Teilnehmers ermitteln können. Daher wird im Allgemeinen angenommen, dass der anrufende Teilnehmer A ausschließlich die Telefonnummer seines gewünschten Kommunikationspartners, Teilnehmer B, kennt. Auf der Basis der Telefonnummer des Angerufenen müssen sowohl der Peering-Punkt in der ZielDomain als auch die IP-Adresse des IP-Telefons bestimmt werden. Hierfür wird auf die DNSund ENUM-Dienste zugegriffen. Im Verlauf von SIP bei Basic Peering sind folgende Schritte zu unterscheiden: A
Initiieren einer VoIP-Session – Diese wird mit der Telefonnummer – z.B. +1451122333 – von Tln A an Tln B initiiert. Hierfür sendet das IP-Telefon von Tln A den Request INVITE mit der gefälschten SIP-URI +1451122333 @abc.de – aus dem Namen der eigenen Domain und der Zielrufnummer aus einer fremden Domain bestehend – als SIP-Zieladresse von Tln B. Das IP-Telefon von Tln A wird so konfiguriert, dass alle ausgehenden Requests INVITE an den SIP-Proxy A seiner Domain übergeben werden.
B
Abfrage von SIP-URI sowie des Namens und der IP-Adresse von Proxy B – Proxy A überprüft den gefälschten SIP-URI +1451122333 @abc.de und stellt fest, dass er den Namen seiner eigenen Domain enthält und die Zielrufnummer +1451122333 fremd ist (entstammt nicht seiner Domain). Daher wird aus dieser Zielrufnummer die ENUM-Domain gebildet (s. Abschnitt 3.8.1) und der Record NAPTR in dieser ENUM-Domain abgefragt (NAPTR Query). So wird der richtige SIP-URI +1451122333 @xyz.de – d.h. die richtige SIP-
9.5 Peering bei VoIP mit SIP
393
Zieladresse – ermittelt. Mit SRV Query (s. Abb. 3.5-6) ermittelt man bei DNS den Namen [email protected] des SIP-Proxy B als Peering-Punkt in der Zieldomain xyz.de. Danach wird mit einer normalen DNS-Abfrage (A-Query) die IP-Adresse des SIP-Proxy B abgefragt. Nun ist dem Proxy A die IP-Adresse des Proxy B bekannt. Das Peering kann beginnen. a b c .d e A T ln A
P e e e r in g -P u n k t S IP P ro x y A D N S /E N U M IN V IT E 1 0 0 T ry in g N A P T R -Q u e ry S R V -Q u e ry B A -Q u e ry
D 1 8 0 R in g in g 2 0 0 O K
C
P e e r in g P h a s e IN V IT E
x y z .d e
S IP P ro x y B
T ln B
n a c h B e d a rf
1 0 0 T ry in g
V o IP -S e s s io n
P e e e r in g -P u n k t
2 0 0 O K
1 8 0 R in g in g
IN V IT E 1 8 0 R in g in g 2 0 0 O K
Abb. 9.5-3: SIP-Verlauf bei Basic Peering – SIP-Proxies als Peering-Punkte C
Peering-Phase – Der Verlauf der Peering-Phase wird bei SPEERMINT nicht definiert. Falls sie nach vorgegebenen Bedingungen durchgeführt werden soll, ist ein spezielles Protokoll nötig; dafür geeignet ist z.B. OSP (s. Abb. 9.6-2).
D
Weiterverlauf – normaler SIP-Verlauf wie z.B. in Abbildung 7.1-8.
www.wiwobooks.com
Hervorzuheben ist, dass es sich bei Basic Peering eigentlich um einen „klassischen Verlauf“ von SIP handelt. Die SIP-Option für Basic Peering besteht nur in der Bildung des gefälschten SIPURI, um den richtigen SIP-URI bei ENUM abfragen zu können.
9.5.3 Integrated Peering versus Decomposed Peering Integrated Peering (kurz IntPeer) setzt als Peering-Punkt eine spezielle Systemkomponente an der Domain-Grenze vom SSP voraus. Die Komponente – als SBC (Session Border Controller) bezeichnet – wird im SIP-Proxy implementiert. Abbildung 9.5-4 veranschaulicht dies näher. S S P A
D N S
D o m a in A
P ro x y S IG
S B E & D B E
D N S E N U M S I G (S ig n a lis ie ru n g ) S p ra c h e , V id e o
S B E & D B E
S S P B D o m a in B P ro x y D o m a in B S IG S IP -P ro x y
D N S
In te r n e t
Abb. 9.5-4: Integrated Peering – Einsatz von SBCs im SIP-Proxy als Peering-Punkte Die wichtigste Besonderheit von IntPeer besteht darin, dass sowohl die Übermittlung der Signalisierung als auch die der Echtzeitmedien über den SBC verläuft. Dieser enthält zwei Funktionselemente: SBE und DBE. Der SBE (Signaling-path Border Element) ist für die Signalisierung
Integrated Peering
394
9
IP-Telefonie-Routing und VoIP-Peering
nach SIP und der DBE (Data-path Border Element) für die Übermittlung von Echtzeitmedien verantwortlich. Weil die Signalisierung und die Übermittlung der Echtzeitmedien über die beiden Peering-Punkte verlaufen, kann die Abrechnung bei IntPeer nach Bill&Keep, CPNP oder RPNP erfolgen. Sowohl bei IntPeer als auch bei Basic Peering – siehe Abbildung 9.5-3 – kommen bei der Ermittlung der IP-Adresse des Ziel-SBC der DNS-Dienst gemeinsam mit ENUM zum Einsatz.
Decomposed Peering
Abbildung 9.5-5 illustriert Decomposed Peering – kurz DecomPeer. Vergleicht man die Abbildungen 9.5-4 und -5, stellt man fest, dass DecomPeer weitgehend nach dem Prinzip von IntPeer funktioniert. Der Unterschied besteht darin, dass sich der als Peering-Punkt fungierende SBC bei DecomPeer aus den Funktionselementen SBE und DBE so zusammensetzt, dass sie als getrennte Hardware-Module realisiert werden können.
S S P A
D N S
D o m a in A
P ro x y
D N S E N U M S B E
S IG
S IG
D B E
S B E
(S ig n a lis ie ru n g )
P e e r in g P u n k t
In te r n e t
S S P B
D N S P e e r in g P u n k t
P ro x y
D o m a in B S IG
D B E
S p ra c h e , V id e o
Abb. 9.5-5: Decomposed Peering – voneinander getrennte Funktionsmodule SBE und DBE
www.wiwobooks.com
SPEERMINT spezifiziert aber keine Schnittstelle bzw. kein Protokoll zwischen SBE und DBE. Ebenso wie bei IntPeer kann bei DecomPeer die Abrechnung nach Bill&Keep, CPNP oder RPNP erfolgen.
9.5.4 Federation-based Peering Nach SPEERMINT können mehrere SSPs zu einer SSP-Föderation gehören. In dieser werden die Domains aller SSPs nach dem gleichen Peering-Modell miteinander zusammengeschaltet und die Ausgleichzahlungen zwischen den SSPs nach dem gleichen Abrechnungsprinzip z.B. nach CPNP erfasst. Diese Art von Peering illustriert Abbildung 9.5-6. Sie wird Federation-based Peering (Interconnection) – kurz FederPeer – genannt. S S P -F ö d e ra tio n s v e rw a ltu n g S S P A 6
P
P
In te rn e t
D o m a in A
P e e rin g -P u n k t
F e d e ra tio n S IP -S e rv e r ... ...
S S P X
P
P
S S P B
D o m a in B
D o m a in X
Abb. 9.5-6: Grundlegende Idee von Federation-based Peering Bei FederPeer wird eine zentrale Peering-Stelle eingerichtet. Diese fungiert als Anbieter der Peering-Dienste bzw. als eine Verrechnungsstelle (Clearinghouse), an der ein zentraler Federation SIP-Server installiert wird. Er ersetzt die Funktion von DNS und ENUM (vgl. Abb. 9.5-5). Daher
9.5 Peering bei VoIP mit SIP
395
werden bei FederPeer die ENUM-Dieste nicht mehr in Anspruch genommen. Dies bestätigt der in Abbildung 9.5-7 gezeigte Verlauf von SIP. FederPeer dient als Modell für die Unterstützung des multilateralen VoIP-Peering. Diese Peering-Art hat einen großen Vorteil gegenüber dem bilateralen VoIP-Peering, der darin besteht, dass jedes Mitglied der SSP-Föderation nur ein Peering-Abkommen mit der Föderationsverwaltung abschließen muss. Die Abwicklung der Abrechnungen zwischen SSPs erfolgt durch die Föderationsverwaltung (siehe auch Abb. 9.6-2). Abbildung 9.5-7 zeigt den Verlauf von SIP bei FederPeer. Die SIP-Proxies dienen hier als Peering-Punkte. Es handelt sich also um eine multilaterale Variante von Basic Peering (s. Abb. 9.53). Eine wichtige Besonderheit von FederPeer besteht darin, dass der zentrale Federation SIPServer als Redirect-Server funktioniert (s. Abb. 7.5-1). So kann man den ENUM-Dienst auf eine spezielle Art und Weise ersetzen. a b c .d e
P e e r in g P u n k t S IP P ro x y A
T ln A IN V IT E 1 0 0 T ry in g
S S P -F ö d e r a tio n s v e r w a ltu n g F e d e ra tio n S IP -S e rv e r
IN V IT E 3 0 2 M o v e d T e m p o ra rily IN V IT E IN V IT E
P e e r in g P u n k t
1 0 0 T ry in g
x y z .d e
S IP P ro x y B
T ln B
V e rw e is a u f d e n P e e rin g -P u n k t in d e r Z ie l-D o m a in IN V IT E 1 8 0 R in g in g
www.wiwobooks.com ...
1 8 0 R in g in g
1 8 0 R in g in g
n o r m a le r S IP -V e r la u f
Abb. 9.5-7: Protokollverlauf beim Federation-based Peering (FederPeer) Bei FederPeer (wie bei Basic Peering) wird angenommen, dass ein Teilnehmer A nur die Telefonnummer (TN) von Teilnehmer B kennt. Das IP-Telefon von Teilnehmer A sendet daher einen SIP-Request INVITE mit dem Ziel-SIP-URI [email protected], der aus dem Namen der eigenen Domain und der Zielrufnummer aus einer fremden Domain besteht und folglich eine gefälschte Ziel-Adresse von Teilnehmer B ist. Der Proxy A überprüft diesen Ziel-SIP-URI und stellt dabei fest, dass die Zieladresse den Namen der eigenen Domain enthält und die TN nicht aus der eigenen Domain abc.de stammt. Daher wird der Request INVITE an den Federation SIP-Server weitergeleitet. Dieser verfügt über eine Tabelle mit den Zuordnungen „Vorwahl in Ziel-TN SIP-Proxy-Name in Zieldomain“ und kann deshalb aus der Vorwahl des angerufenen Teilnehmers den Hostnamen des Peering-Punktes der Ziel-Domain ermitteln und den Proxy A auf diesen verweisen. So lässt sich der ENUM-Dienst durch den Federation SIP-Server ersetzen; SRV Query ist hier auch nicht mehr nötig (s. Abb. 9.5-1). Der Federation SIP-Server teilt dem Proxy A in der SIP-Respsonse 302 Moved Temporarily den Namen des Peering-Punktes der Zieldomain xyz.de mit. Der Name des Proxy B kann z.B. [email protected] sein. Ist dem Proxy A als Peering-Punkt der Name des Proxy B bekannt, so kann er den richtigen Ziel-SIP-URI [email protected] bilden und mit DNS-Hilfe den A-Record mit der IP-Adresse des Peering-Punktes B – also die IP-Adresse für den Hostnamen [email protected] – abfragen. Danach kann Proxy A an den SIP-Proxy B INVITE mit dem ZielSIP-URI [email protected] senden. Der weitere Protokollverlauf in Abbildung 9.5-7 entspricht dem Verlauf von SIP im Redirect-Mode – siehe z.B. Abbildung 7.5-1.
SIP-Verlauf bei FederPeer
396
9
IP-Telefonie-Routing und VoIP-Peering
9.6
Schlussbemerkungen
Die Akzeptanz von VoIP wird immer größer. Deshalb muss ermöglicht werden, dass jedes IPTelefon eine Verbindung mit jedem anderen Telefon am ISDN bzw. am digitalen oder analogen Telefonnetz aufbauen kann. Dafür sind diverse mit dem Telefonie-Routing verbundene Probleme zu lösen. Ihre Lösungen wurden in diesem Kapitel präsentiert. Abschließend sind noch folgende Aspekte hervorzuheben:
TGREP
Ein Location-Server (LS) in einer administrativen Domäne mit VoIP – d.h. in einer ITAD – stellt eine Datenbasis dar, in der die aktuellen in und aus der Domäne erreichbaren Telefonziele abgelegt sind. Bei der Integration von VoIP nach H.323 mit herkömmlichen Telefonnetzen – wie PSTN bzw. ISDN – müssen dem Location-Server die Telefonziele in diesen Telefonnetzen – als Vorwahlangaben – irgendwie mitgeteilt werden. Wie Abbildung 9.6-1 zeigt, steht hierfür TGREP (Telephony Gateway REgistration Protocol) zur Verfügung – siehe RFC 5140.
P S T N
Z
T R E P 1
L S
...
G W
P S T N
G W
Z
Z 2
IT A D 3
Z
L S
T R IP
Z
IT A D x
G W 2
P S T N
1
G W : V o IP -G a te w a y y
Abb. 9.6-1: TREG als Protokoll zwischen Gateway zum Telefonnetz und Location-Server
www.wiwobooks.com
TGREP stellt also ein Protokoll dar, nach dem ein VoIP-Gateway einen Location-Server einer ITAD über die Telefonie-Routen zum herkömmlichen Telefonnetz informieren kann.
Protokoll OSP
Bei VoIP mit SIP müssen auch die anfallenden Gebühren erfasst, zwischen SSPs abgerechnet und Ausgleichszahlungen zwischen ihnen getätigt werden. Um die notwendigen Informationen für die Abrechnungen zu erfassen, ist ein Protokoll nötig. OSP (Open Settlement Protocol) ist ein solches Protokoll. Spezifiziert wurde es bei ETSI. Abbildung 9.6-1 illustriert den Einsatz von OSP bei Federation-based Peering – siehe auch Abbildung 9.5-6.
D o m a in A
S S P A P
S S P -F ö d e ra tio n s v e rw a ltu n g
P
P e e rin g -P u n k t O S P - C lie n t
O S P -S e rv e r
P
In te rn e t
O S P
V e rre c h n u n g ss te lle
O S P
D o m a in B
S S P B
O S P -C lie n t
Abb. 9.6-2: Einsatz von OSP bei Federation-based Peering OSP ist ein Client/Server-Protokoll und regelt die Kommunikation zwischen OSP-Clients und einem OSP-Server. Die Peering-Punkte bei SSPs können als OSP-Clients fungieren. Ein OSPServer kann bei der SSP-Föderationsverwaltung installiert werden.
Infrastructure ENUM
Bei VoIP-Peering nach SPEERMINT kommt eine modifizierte ENUM-Variante zum Einsatz, die man als Infrastructure ENUM bzw. manchmal auch als Provider oder Carrier ENUM bezeichnet. Infrastructure ENUM kann von einem SSP eingesetzt werden, um den Peering-Punkt in seiner Domain zu verweisen. Beim „klassischen“ ENUM liegt die Verantwortung für das Eintragen in der Datenbank einer ENUM-Domain dagegen beim Telefonteilnehmer, sodass man auch von Public User ENUM spricht.
10 Migration zum VoIP-Einsatz Bei keinem Netzwerkprojekt sollte der VoIP-Einsatz heute außer Acht gelassen werden. VoIP wird auch für kleine Büros und private Haushalte immer interessanter. Die Migration zum VoIP-Einsatz führt in Unternehmen zur Konvergenz der Sprach- und Datennetze und stellt ein komplexes Projekt dar. Beim Design konvergenter Unternehmensnetze müssen bestimmte Design-Regeln beachtet werden. Der Schritt zu VoIP setzt die Entscheidung voraus, ob eine klassische TK-Lösung um VoIP-Systemkomponenten erweitert oder ob eine reine VoIPSystemlösung eingesetzt werden soll. Diese Entscheidung hängt insbesondere davon ab, welche innovativen Applikationen zur Verfügung stehen.
Migration zu VoIP als komplexes Projekt
Die Auswahl einer geeigneten VoIP-Systemlösung hängt vor allem davon ab, Aspekte der ob das Unternehmen an nur einem oder an mehreren Standorten angesiedelt ist. Migration Je nachdem kommen unterschiedliche VoIP-Systemarchitekturen in Frage, die davon abhängig sind, ob es sich um eine hybride oder eine reine VoIP-Systemlösung handelt. Bei der Planung und Durchführung einer Migration zum VoIPEinsatz in einem Unternehmen ist eine strukturierte Vorgehensweise erforderlich.
www.wiwobooks.com
Dieses Kapitel gibt einen Überblick über alle Aspekte, die mit der Migration zu Überblick VoIP in Unternehmen verbunden sind. Nach der Darstellung wichtiger Aspekte über das in Abschnitt 10.1 werden in den Abschnitten 10.2 und 10.3 hybride und reine Kapitel VoIP-Systeme präsentiert. Abschnitt 10.4 ist der Auswahl der richtigen Migrationsstrategie gewidmet. Die strukturierte Vorgehensweise bei der Migration zu VoIP erläutert Abschnitt 10.5. Auf die Probleme bei der Verwendung privater IP-Adressen bei VoIP mit SIP geht Abschnitt 10.6 ein. Dieses Kapitel beantwortet u.a. folgende Fragen:
Ziel dieses Welche Arten der Migration zu VoIP kommen für ein Unternehmen in Fra- Kapitels
ge? Welche Systemarchitekturen von VoIP-Lösungen gibt es, und wie können sie eingesetzt werden? Wie konzipiert man hybride bzw. reine VoIP-Systemarchitekturen, und wie setzt man sie ein? Wie sollte die Migration zu VoIP verlaufen, und welche Aspekte sind hierbei zu berücksichtigen? Welche Probleme entstehen bei VoIP mit SIP, falls IP-Telefone private IPAdressen verwenden, und welche Lösungen gibt es?
398
10 Migration zum VoIP-Einsatz
10.1 Verschiedene Aspekte der Migration zu VoIP Arten der Migration
Ein Unternehmen hat grundsätzlich zwei Möglichkeiten, um zum VoIP-Einsatz zu wechseln: eine sanfte oder eine harte Migration.
10.1.1 Sanfte Migration zu VoIP Was bedeutet eine sanfte Migration?
Die erste Möglichkeit der Migration zum VoIP-Einsatz in einem Unternehmen bzw. in einer anderen Institution (z.B. Universität, Stadtverwaltung) kann darin bestehen, dass man die bereits vorhandene TK-Anlage für die traditionelle Telefonie entsprechend um die VoIP-Systemkomponenten ergänzt und VoIP im Netzwerkbereich schrittweise einführt. Damit wird der Fortbestand der „alten TK-Welt“ über eine bestimmte Zeit in den Vordergrund gestellt. Einen derartigen Ansatz bezeichnet man als sanfte Migration zu VoIP. Bei dieser Lösung können beispielsweise einige Mitarbeiter via VoIP telefonieren, während andere Mitarbeiter noch immer die traditionelle TK-Anlage benutzen. Die sanfte Migration zum VoIP-Einsatz in einem Unternehmen ist dann sinnvoll, wenn die vorhandene TK-Anlage noch vollkommen funktionsfähig ist bzw. der Mietvertrag noch über eine relativ lange Zeit besteht. Bei einer sanften Migration zum VoIP-Einsatz wird eine klassische TK-Anlage mit einer VoIPbasierten TK-Anlage, auch IP-TK-Anlage bzw. IP-PBX (Private Branch eXchange) genannt, entsprechend integriert. In diesem Falle spricht man auch von einer Hybridanlage. Eine sanfte Migration zum VoIP-Einsatz führt also zu einer hybriden Systemlösung.
www.wiwobooks.com
Wohin führt eine sanfte Migration?
Die sanfte Migration zu VoIP führt dazu, dass alle Systemkomponenten für die Anrufsteuerung, Vermittlung und Realisierung wichtiger Dienstmerkmale in der Regel in einem Modul als Monolith untergebracht werden. Dieser Monolith stellt eine klassische TK-Anlage bzw. einen Verbund solcher TK-Anlagen dar. Das Ergebnis einer sanften Migration ist oft eine monolithische VoIPSystemlösung. Häufig werden solche Lösungen von Herstellern traditioneller TK-Anlagen bevorzugt. Obwohl die Vorteile reiner VoIP-Lösungen auf der Hand liegen, fällt es ihnen immer noch schwer, ihren mit klassischen TK-Anlagen gewonnenen Marktanteil aufzugeben.
Geringe Bedeutung
Die große Akzeptanz von VoIP in Unternehmen aller Größen hat bereits dazu geführt, dass die „alte TK-Welt“ klein geworden ist. Damit sind klassische TK-Anlagen immer seltener noch im Einsatz. Aus diesem Grund hat die sanfte Migration zu VoIP de facto in der Praxis an Bedeutung verloren.
10.1.2 Harte Migration zu VoIP Besonderheit
Die zweite Möglichkeit der Migration zum VoIP-Einsatz in einem Unternehmen bedeutet, dass ein radikaler Schritt vollzogen wird. Er führt dazu, dass die traditionelle Systemlösung auf Basis einer TK-Anlage für die Sprachkommunikation durch eine reine VoIP-Systemlösung ersetzt wird. Hierbei wird die vorhandene TK-Anlage „schmerzfrei“ und vollständig durch die neue VoIP-Welt ersetzt. Einen derartigen Ansatz bezeichnet man als harte (konsequente) Migration zu VoIP. Diese Art der Migration bevorzugen insbesondere die führenden Hersteller von Netzwerkkomponenten.
10.1 Verschiedene Aspekte der Migration zu VoIP
399
Nach einer harten Migration zu VoIP sollte das verteilte VoIP-System allen Mitarbeitern im Unternehmen ermöglichen, mit allen Teilnehmern am PSTN/ ISDN und an Mobilfunknetzen (GSM, UMTS) per VoIP zu telefonieren. Einige Mitarbeiter sollten auch die Möglichkeit haben, auf sämtliche TK-Dienste im intelligenten Netz auf Basis von PSTN/ ISDN zuzugreifen. Um diese Möglichkeiten zu garantieren, ist eine entsprechende Integration des Bedeutung Unternehmensnetzes mit PSTN/ ISDN notwendig. Diese Integration besteht von Mediadarin, dass eine verteilte und universelle Gateway-Plattform zum Einsatz Gateways kommt. Die Kopplung des Unternehmensnetzes mit PSTN/ISDN bei VoIP erfolgt mit Hilfe von Media Gateways (s. Kapitel 8). In Unternehmen, die auf mehrere Standorte verteilt sind, kann die Anbindung an PSTN/ ISDN über mehrere an verschiedenen Standorten untergebrachte Media Gateways – quasi verteilte Gateway-Plattformen – erfolgen. Die Ansteuerung von Media Gateways und die Abwicklung der Signalisierung Softswitchbeim Auf- und Abbau von Verbindungen zwischen IP-Telefonen und Telefo- Einsatz nen am PSTN/ISDN sowie Handys in den Mobilfunknetzen (GSM, UMTS) übernimmt eine Softswitch genannte Funktionskomponente. Manchmal wird auch die gesamte Gateway-Plattform Softswitch genannt. Eine harte Migration führt also zu einer Softswitch-Lösung (s. Abb. 10.3-1).
www.wiwobooks.com
10.1.3 Typische Fälle bei der Migration zu VoIP
Bei der Migration zu VoIP müssen mehrere Aspekte berücksichtigt werden. Insbesondere ist die VoIP-Systemlösung davon abhängig, ob das Unternehmen an einem oder an mehreren Standorten angesiedelt ist. Wie Abbildung 10.1-1 zeigt, unterscheidet man im Allgemeinen vier typische Fälle bei der Migration zu VoIP in Unternehmen.
F a ll 1 s a n fte M ig ra tio n F a ll 2
E in z e ls ta n d o rt A s p e k te d e r M ig ra tio n z u V o IP in U n te rn e h m e n M e h re re S ta n d o rte
F a ll 3 h a rte M ig ra tio n F a ll 4
Abb. 10.1-1: Typische Fälle bei der Migration zum VoIP-Einsatz in Unternehmen
Bei der Erstellung des Konzepts für die Migration zum VoIP-Einsatz in einem Unternehmen unterscheidet man im Allgemeinen zwischen den folgenden grundlegenden Fällen:
400
10 Migration zum VoIP-Einsatz
Hybride VoIP-Lösung am Einzelstandort
1. Sanfte Migration am Einzelstandort
Standortübergreifende hybride VoIP-Lösung
2. Sanfte Migration an mehreren Standorten
Reine VoIPLösung am Einzelstandort
3. Harte Migration am Einzelstandort
Hierbei handelt es sich um eine hybride VoIP-Systemlösung für ein Unternehmen an einem Standort. Die bestehende TK-Anlage wird um ein auf einem Standort verteiltes VoIP-System erweitert. Das Architekturmodell für eine derartige Systemlösung stellt Abschnitt 10.2.1 näher dar. Dieser Fall entspricht einer hybriden VoIP-Systemlösung im Unternehmen, das an mehreren Standorten angesiedelt ist. Die Sprachkommunikation wird auf Basis einer standortübergreifenden Vernetzung von TK-Anlagen realisiert. Bei einer sanften Migration zu VoIP wird der Verbund von TKAnlagen mit einem über mehrere Standorte verteilten VoIP-System erweitert. Abhängig davon, wie die Steuerung ankommender Anrufe realisiert wird, sind verschiedene Systemlösungen möglich. Auf die entsprechenden Architekturmodelle geht Abschnitt 10.2.3 ein. Eine reine VoIP-Systemlösung für ein Unternehmen an einem Standort; die bestehende TK-Anlage wird vollständig abgelöst und durch ein verteiltes VoIP-System am Einzelstandort ersetzt. Diese Lösung kann auch als Softswitch-VoIP-Lösung angesehen werden (s. Abb. 10.3-1). Das Architekturmodell für eine derartige Systemlösung beschreibt Abschnitt 10.3.1 näher.
www.wiwobooks.com
Standortübergreifende reine VoIP-Lösung
4. Harte Migration an mehreren Standorten Sie entspricht einer reinen VoIP-Systemlösung für ein Unternehmen, in dem bisher die Sprachkommunikation auf Basis eines standortübergreifenden Verbunds von TK-Anlagen realisiert wird. Die harte Migration ersetzt den Verbund von TK-Anlagen durch ein über mehrere Standorte verteiltes reines VoIP-System. Das VoIP-System basiert hierbei in der Regel auf dem Softswitch-Ansatz. Auf die entsprechenden Architekturmodelle geht Abschnitt 10.3.3 ausführlicher ein.
10.1.4 Architekturmodelle der VoIP-Systeme Berücksichtigt man die in Abbildung 10.1-1 dargestellten typischen Fälle bei der Migration zum VoIP-Einsatz in Unternehmen, kann für jeden dieser Fälle ein bestimmtes Architekturmodell des VoIP-Systems erstellt werden. Eine Übersicht dieser Modelle zeigt Abbildung 10.1-2. Die grundlegenden Architekturmodelle der VoIP-Systeme in Unternehmen bzw. anderen Institutionen sind:
10.1 Verschiedene Aspekte der Migration zu VoIP
1. Hybride VoIP-Systemarchitektur am Einzelstandort Eine derartige Systemarchitektur entsteht durch eine Erweiterung einer TKAnlage als Monolith um ein VoIP-System. Eine derartige Erweiterung der TK-Anlage führt zu einem hybriden VoIP-System. Das Architekturmodell eines solchen Systems beschreibt Abschnitt 10.2.1.
F a ll 1 : H y b r id e V o IP -S y s te m a r c h ite k tu r a m E in z e ls ta n d o r t
E in z e ls ta n d o rt
F a ll 2 : S ta n d o r tü b e r g r e ife n d e h y b r id e V o IP -S y s te m a r c h ite k tu r F a ll 2 a : z e n tr a le A n r u fs te u e r u n g F a ll 2 b : v e r te ilte A n r u fs te u e r u n g
Hybride Lösungen
F a ll 3 : R e in e V o IP -S y s te m a r c h ite k tu r a m E in z e ls ta n d o r t
A rc h ite k tu rm o d e lle d e r V o IP -S y s te m e
H y b rid e L ö s u n g
401
R e in e V o IP -L ö s u n g F a ll 4 : S ta n d o r tü b e r g r e ife n d e r e in e V o IP -S y s te m a r c h ite k tu r
M e h re re S ta n d o rte
F a ll 4 a : z e n tr a le A n r u fs te u e r u n g F a ll 4 b : v e r te ilte A n r u fs te u e r u n g
Abb.10.1-2: Die Architekturmodelle von VoIP-Systemen
2. Standortübergreifende hybride VoIP-Systemarchitektur
www.wiwobooks.com
Hier handelt es sich um eine Erweiterung eines Verbunds von an mehreren Standorten installierten TK-Anlagen mit einem verteilten VoIP-System. Ein solches standortübergreifendes System stellt eine verteilte hybride VoIP-Systemlösung dar. In diesem Fall ist zwischen einer verteilten und einer zentralen Anrufsteuerung zu unterscheiden. Die Architekturmodelle für eine derartige Systemlösung werden in Abschnitt 10.2.3 dargestellt. 3. Reine VoIP-Systemarchitektur am Einzelstandort In diesem Fall wird die am Einzelstandort bestehende TK-Anlage vollständig abgelöst und durch ein reines VoIP-System ersetzt. In der Regel führt dies in großen Unternehmen zu einer Softswitch-Lösung. Abschnitt 10.3.1 zeigt das Architekturmodell für ein derartiges VoIP-System. 4. Standortübergreifende reine VoIP-Systemarchitektur Eine solche Systemarchitektur entsteht beispielsweise dann, wenn ein standortübergreifender Verbund von TK-Anlagen vollständig abgelöst und durch ein standortübergreifend verteiltes VoIP-System ersetzt wird. Hierbei können mehrere Softswitches zum Einsatz kommen (s. Abb. 10.3-1). In Abhängigkeit davon, wie die ankommenden Anrufe verteilt werden, ist in diesem Fall zwischen einer verteilten und einer zentralen Anrufsteuerung zu unterscheiden. Die Architekturmodelle für eine derartige VoIP-Systemlösung stellt Abschnitt 10.3.3 dar.
Reine VoIPLösungen
402
10 Migration zum VoIP-Einsatz
10.2 Hybride VoIP-Systemarchitekturen Hybride VoIP-Systemarchitekturen sind davon abhängig, ob ein Unternehmen an einem Standort angesiedelt oder auf mehrere Standorte verteilt ist. Entsprechend ist zu unterscheiden zwischen hybriden VoIP-Systemarchitekturen am Einzelstandort und standortübergreifenden hybriden VoIP-Systemarchitekturen.
10.2.1 Hybride VoIP-Systemarchitektur am Einzelstandort Falls die bestehende TK-Anlage in einem Unternehmen, das an einem Standort angesiedelt ist, durch ein verteiltes VoIP-System ergänzt wird, führt dies zu einer hybriden VoIP-Systemarchitektur am Einzelstandort. Abbildung 10.2-1 illustriert eine derartige Systemarchitektur. Dieses Modell stellt die einfachste Systemlösung für die Einführung von VoIP in einem Unternehmen dar. U n te r n e h m e n a m E in z e ls ta n d o r t T K A n la g e
... ...
T K 6
P S T N /IS D N
www.wiwobooks.com D V
V o IP S y s te m
V o IP S e rv e r
IP -T K -A n la g e
V o IP G a te w a y
IP -L A N
R
IP -W A N (In te rn e t) R : R o u te r
Abb. 10.2-1: Hybride VoIP-Systemarchitektur am Einzelstandort Wie hier ersichtlich ist, wird kein vollständiger Umstieg auf die VoIP-Technik im Unternehmen durchgeführt, sondern die bestehende TK-Anlage nur um ein VoIP-System erweitert. Die „alte“ TK-Anlage fungiert weiter als zentrale Systemkomponente zur Steuerung der ankommenden Anrufe aus dem PSTN/ISDN. Um das lokale Netzwerk (LAN) an die bestehende TK-Anlage anzubinden, wird ein VoIP-Gateway eingesetzt. Die Anbindung erfolgt in der Regel über die ISDNSchnitttstelle S2M.
Aufgabe des VoIPServers
Im VoIP-System ist ebenfalls eine zentrale Systemkomponente nötig, die man oft VoIP-Server nennt. Die Aufgabe des VoIP-Servers ist davon abhängig, nach welchem Standard die Signalisierung im VoIP-System verläuft. Der VoIP-Server kann u.a. zur Verfügung stellen: die Funktion eines Gatekeepers, falls die Signalisierung nach H.323 verläuft (s. Kapitel 6); die Funktion von Proxy-/Redirect-Servern und die Registrar-Funktion beim Einsatz von SIP als Signalisierungsprotokoll (s. Kapitel 7). Die beiden Funktionskomponenten VoIP-Server und VoIP-Gateway können in einer Hardwarekomponente untergebracht werden, sodass man sie zusammen als eine IP-TK-Anlage ansehen kann. Daher ist die in Abbildung 10.2-1 dargestellte Systemlösung für die Sprachkommunikation eine hybride Systemlösung.
10.2 Hybride VoIP-Systemarchitekturen Die Vorteile der hier gezeigten hybriden VoIP-Systemarchitektur: Die vorhandene TK-Infrastruktur wie z.B. Telefonverkabelung, analoge und digitale Telefone an der TK-Anlage können weiter genutzt werden.
403 Vorteile hybrider VoIP-Lösung
Eine Änderung der Organisationsstruktur ist nicht nötig. Im Vergleich zu einer reinen ist eine hybride VoIP-Systemarchitektur jedoch als teuer, unflexibel und schlecht skalierbar zu bewerten.
10.2.2 Arten der Vernetzung von TK-Anlagen Große Unternehmen oder Institutionen wie z.B. Stadtverwaltungen, Hochschuleinrichtungen etc. sind oft auf verschiedene Standorte aufgeteilt. Der Bedarf an einer unternehmensweiten Sprachkommunikation hat in der Vergangenheit zur Entstehung privater TK-Netze auf ISDN-Basis geführt. Sie bestanden in der Regel aus einer Vernetzung von TK-Anlagen, die an verschiedenen Standorten des Unternehmens installiert waren. Bei einer sanften Migration zum VoIP-Einsatz beeinflusst die Art der Vernetzung von an verschiedenen Ortsnetzen installierten TK-Anlagen das Konzept des VoIP-Systems. Gehören die Standorte einzelner TK-Anlagen eines Unternehmens zu verschiedenen Ortsnetzen, so kommen mehrere Vernetzungsarten in Frage. Sie sind oft davon abhängig, ob das ganze Unternehmen unter einer Rufnummer erreichbar sein muss oder nicht. Man unterscheidet zwischen: einer Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung und
Was beeinflusst die Vernetzungsart?
www.wiwobooks.com
einer Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung.
Da die Art der Vernetzung eine Auswirkung auf das Konzept des VoIP-Systems hat, werden diese zwei Typen hier kurz dargestellt.
Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung Abbildung 10.2-2 illustriert eine Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung. Eine TK-Anlage befindet sich – als Hauptanlage – mit ankommenden und abgehenden Amtsleitungen am Hauptstandort des Unternehmens (Zentrale). Die TK-Anlagen an Nebenstandorten sind der Hauptanlage untergeordnet und über Festverbindungen an sie angeschlossen. Die untergeordneten TK-Anlagen an Nebenstandorten haben nur abgehende Amtsleitungen, sodass das ISDN als öffentliches TK-Netz nur eine TK-Anlage „sieht“. Eine derartige Vernetzung garantiert, dass das ganze Unternehmen nur unter der Rufnummer der Haupt-TK-Anlage erreichbar ist. Die ankommenden externen Anrufe werden nur an die TK-Anlage am Hauptstandort geführt und über sie an die einzelnen Nebenstandorte weitergeleitet.
N e b e n s ta n d o r t A 6
T K A n l
T K A n l
H a u p ts ta n d o r t A L
A L F V
IS D N
F V
N e b e n s ta n d o r t B
T K A n l
... ...
6
A L : A m ts le itu n g F V : F e s tv e rb in d u n g
Abb. 10.2-2: Standortübergreifende Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung
Prinzip der Vernetzung
404 Besonderheiten
10 Migration zum VoIP-Einsatz Die Vernetzung mit zentraler Anrufsteuerung ermöglicht u.a. die Mitnahme der Rufnummer beim Umzug innerhalb des Unternehmens. Jeder Teilnehmer hat nur eine Rufnummer, sodass man von außen nicht erkennen kann, an welchem Standort im Unternehmen er sich befindet. Somit kann jeder Teilnehmer nach dem „Umzug“ seine Rufnummer beibehalten.
Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung Abbildung 10.2-3 illustriert eine Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung.
6
S ta n d o r t B 6
T K A n l
T K A n l
S ta n d o r t A A L
A L F V F V
IS D N
F V
S ta n d o r t B
T K A n l
... ...
Prinzip der Vernetzung
A L : A m ts le itu n g F V : F e s tv e rb in d u n g
Abb. 10.2-3: Standortübergreifende Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung Hier sind alle TK-Anlagen gleichberechtigt und vollständig über Festverbindungen paarweise miteinander vernetzt. Jede TK-Anlage hat sowohl ankommende als auch abgehende Amtsleitungen. Sind die TK-Anlagen an einzelnen Ortsnetzen mit verschiedenen Vorwahlnummern installiert, ergibt sich die Frage, ob bei dieser Lösung das ganze Unternehmen unter einer Rufnummer erreichbar ist. Die Antwort fällt nicht eindeutig aus und war in der Vergangenheit von der Art des Anschlusses einzelner TK-Anlagen an die öffentlichen Vermittlungssysteme sowie vom Rufnummernkontingent abhängig.
www.wiwobooks.com
10.2.3 Standortübergreifende hybride VoIP-Systemarchitekturen Eine sanfte Migration zu VoIP-Einsatz in Unternehmen bzw. in anderen Institutionen, die auf mehreren Standorten angesiedelt sind, führt zu hybriden VoIP-Systemarchitekturen. Hierbei kann man unterscheiden zwischen einer VoIP-Systemarchitektur mit zentraler Anrufsteuerung und einer VoIP-Systemarchitektur mit verteilter Anrufsteuerung.
VoIP-Systemarchitekturen mit zentraler Anrufsteuerung Standortübergreifende hybride VoIP-Lösung
Ist ein Unternehmen an mehreren Standorten angesiedelt und unterhält es eine Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung (s. Abb. 10.2-2), führt eine sanfte Migration zum VoIP-Einsatz zu einer standortübergreifenden hybriden VoIP-Systemarchitektur mit ebenfalls zentraler Anrufsteuerung. Abbildung 10.2-4 soll dies näher zum Ausdruck bringen. Im gezeigten Beispiel fungiert die TK-Anlage am Standort A als Hauptanlage mit ankommenden und abgehenden Amtsleitungen. Die TK-Anlage am Nebenstandort ist der Haupt-TK-Anlage untergeordnet und über eine Festverbindung an sie angeschlossen. Bei der Migration zum VoIPEinsatz werden die TK-Anlagen an jedem Standort um entsprechende VoIP-Systeme erweitert.
10.2 Hybride VoIP-Systemarchitekturen
405
An jedem Standort wird hier das Konzept verfolgt, das bereits in Abschnitt 10.2.1 dargestellt wurde (s. Abb. 10.2-1). H a u p ts ta n d o r t A
... ...
A L 6
T K A n la g e
P S T N /IS D N
T K A n la g e
F V
V o IP G & S IP -L A N
A L
V o IP G & S
V P N
R
IP -W A N (In te rn e t)
... ...
N e b e n s ta n d o r t B
R
IP -L A N
V P N
A L : A m ts le itu n g F V : F e s tv e rb in d u n g V o IP -G & S : V o IP -G a te w a y u n d -S e rv e r
R : R o u te r
Abb. 10.2-4: Hybride VoIP-Systemarchitektur mit zentraler Anrufsteuerung Um Vernetzungskosten zu sparen, kann nun eventuell die Festverbindung über das PSTN/ISDN zwischen den beiden TK-Anlagen durch eine emulierte Standleitung über das IP-WAN ersetzt werden. Eine solche Standleitung wird oft auch als VPN (Virtual Private Network) bezeichnet – s. [BaHo 07]. Der Einsatz von VPN als Ersatz für Festverbindungen verlangt aber eine Nachrüstung von TK-Anlagen. Ohne Nachrüstung ist die Ersetzung einer Festverbindung mit einem VPN nicht immer möglich. Bei der Sprachübertragung über VPN können bestimmte Sicherheitsverfahren unterstützt werden, sodass sich VPN als Tunnel interpretieren lässt. Insbesondere besteht die Möglichkeit, die Sprache in verschlüsselter Form zu übermitteln.
Einsatz von VPN
Da die untergeordnete TK-Anlage am Nebenstandort nur abgehende Amtsleitungen hat, „sieht“ das ISDN nur die Haupt-TK-Anlage. Dies garantiert, dass das ganze Unternehmen unter einer Vorwahl der Haupt-TK-Anlage erreichbar ist. Die ankommenden externen Anrufe werden nur an die Haupt-TK-Anlage am Standort A geführt, und von dort werden einige dieser Anrufe über VPN an den Nebenstandort B weitergeleitet.
Eine Rufnummer
www.wiwobooks.com
Wurde die Festverbindung über das PSTN/ISDN zwischen den TK-Anlagen mit VPN ersetzt, erfolgt die Sprachkommunikation zwischen den Standorten A und B nur über das IP-WAN. Damit lassen sich die anfallenden Telefongebühren reduzieren. Zusätzlich kann ein weiteres VPN für den VoIP-Verkehr zwischen den Routern eingerichtet werden.
VoIP-Systemarchitekturen mit verteilter Anrufsteuerung Ist ein Unternehmen an mehren Standorten angesiedelt und unterhält eine standortübergreifende Vernetzung von TK-Anlagen mit verteilter Anrufsteuerung (s. Abb. 10.2-3), führt eine sanfte Migration zum VoIP-Einsatz zu einer hybriden VoIP-Systemarchitektur mit ebenso verteilter Anrufsteuerung. Abbildung 10.2-5 illustriert einen derartigen Fall. Die hier dargestellte Situation entspricht weitgehend der Situation in Abbildung 10.2-4. Der wesentliche Unterschied besteht darin, dass nun die TK-Anlagen an beiden Standorten gleichberechtigt und über ankommende und abgehende Amtsleitungen mit dem öffentlichen Sprachkommunikationsnetz PSTN/ISDN verbunden sind. Falls die Vorwahlnummern an den Standorten A und B unterschiedlich sind, ist das Unternehmen in diesem Falls sowohl unter der Vorwahl des
Mehrere Rufnummern
406
10 Migration zum VoIP-Einsatz Standorts A als auch unter der des Standorts B erreichbar. Um die Vernetzungskosten zu sparen, kann die Festverbindung eventuell durch VPN über das IP-WAN ersetzt werden (s. Abb.10.2-4). S ta n d o r t B
... ...
A L 6
T K A n la g e
P S T N /IS D N
T K A n la g e
F V
V o IP G & S IP -L A N
A L
V o IP G & S
V P N
R
IP -W A N (In te rn e t)
... ...
S ta n d o r t A
R
IP -L A N
V P N
A L : A m ts le itu n g F V : F e s tv e rb in d u n g V o IP -G & S : V o IP -G a te w a y u n d -S e rv e r
R : R o u te r
Abb. 10.2-5: Hybride VoIP-Systemarchitektur mit verteilter Anrufsteuerung
10.3 Reine VoIP-Systemarchitekturen
www.wiwobooks.com
Bei einer reinen VoIP-Systemarchitektur kann ein offenes Konzept verfolgt werden, das sich sowohl auf die Schnittstellen und Applikationen als auch auf Hardware-Komponenten und Protokolle bezieht. Dies bedeutet, dass einige Systemkomponenten innerhalb des IP-Netzwerks (IP-LAN) frei verteilt sein können. Auf diese Weise erreicht man eine hohe Nutzungsflexibilität, Skalierbarkeit und Erweiterbarkeit des VoIP-Systems. Abbildung 10.3-1 erläutert das allgemeine Konzept einer reinen VoIP-Systemarchitektur. MultiplaneArchitektur
Eine reine VoIP-Systemarchitektur stellt eine Multiplane-Architektur dar, in der man – logisch gesehen – folgende Ebenen unterscheidet: Media Transport Plane Call Control Plane Service Control Plane Die Media Transport Plane bilden die Hardware-Komponenten wie IP-Telefone, physikalisches IP-LAN und das Media-Gateway an der Grenze zwischen IP-LAN und dem öffentlichen Sprachkommunikationsnetz. Diese Plane kann als Ebene der Sprachübertragung angesehen werden.
Steuerung der Anrufe mit Call Controller
Für die Übermittlung der Sprache in IP-Paketen müssen virtuelle Verbindungen, d.h. sog. Sessions (s. Abb.5.2-1), zwischen zwei IP-Telefonen auf- und abgebaut werden. Man spricht in diesem Zusammenhang von der VoIP-Signalisierung. Bei der Abwicklung der VoIP-Signalisierung entsteht die Notwen-
10.3 Reine VoIP-Systemarchitekturen
407
digkeit, sowohl die abgehenden als auch die ankommenden Anrufe entsprechend zu steuern und zu überwachen. In großen VoIP-Systemen ist daher eine spezielle Funktionskomponente für die Steuerung und Überwachung der Anrufe nötig. Diese Funktionskomponente bezeichnet man hier als Call Controller (CC). Sie ist in der Regel auf einem speziellen Server untergebracht, den wir im Weiteren VoIP-Server (VS) nennen. Logisch gesehen, kann die Funktion des Call Controller der Call Control Plane zugeordnet werden. S e r v ic e C o n tr o l P la n e
D ire c to ry S e rv ic e
V e r w a ltu n g d e r V o IP -D ie n s te
S C
L D A P
C a ll C o n tr o l P la n e a ls S o fts w itc h V S
V S
M G C
S ig n a lis ie r u n g V o IP -G a te w a y
IP -L A N
M G
IS D N /P S T N
www.wiwobooks.com
M e d ia T r a n s p o r t P la n e : S p r a c h ü b e r tr a g u n g V S : V o IP -S e rv e r S C : S e rv ic e C o n tro l M G : M e d ia G a te w a y M G C : M G C o n tro lle r
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio s n e tz
V S = C a ll C o n tro lle r
Abb. 10.3-1: Reine VoIP-Systemarchitektur mit verteilter Anrufsteuerung LDAP: Lightweight Directory Access Protocol
Bemerkung: Die führenden Hersteller von Systemkomponenten für VoIP verwenden einen anderen Namen für den Call Controller. Beispielsweise bezeichnet ihn die Firma Cisco als Call Manager und die Firma Alcatel als Call Server. Call Controller entspricht daher der Funktion nach sowohl dem Call Manager von Cisco als auch dem Call Server von Alcatel.
Zur Call Control Plane können mehrere VoIP-Server gehören, die als Call Funktion von Controller dienen. Ein VoIP-Server stellt eine zentrale Komponente im VoIP- VoIP-Server System dar. Sie regelt die Anrufverwaltung innerhalb des VoIP-Systems, indem sie unter anderem die Berechtigungen der einzelnen IP-Telefone verifiziert und die Anrufsignalisierung entsprechend steuert. Über den VoIP-Server findet aber keine Sprachübertragung statt, sondern er übernimmt die Vermittlungsaufgaben zwischen jeweils zwei IP-Telefonen. Erfolgt die Signalisierung nach: dem Standard H.323, realisiert der VoIP-Server hauptsächlich die Funktion des Gatekeeper;
408
10 Migration zum VoIP-Einsatz
dem Protokoll SIP, stellt der VoIP-Server sowohl die Funktion eines Proxybzw. eines Redirect-Servers als auch die Funktion eines Registrars zur Verfügung. Bildung eines VoIP-ServerClusters
Um eine hohe Verfügbarkeit des VoIP-Systems zu garantieren und damit auch die Anrufsteuerung nach dem Ausfall eines VoIP-Servers weiter sicher zu ermöglichen, sollte man eine redundante Auslegung von VoIP-Servern implementieren. Je nach Struktur und Größe des IP-Netzwerks können zwei oder mehrere VoIP-Server zu einem sog. VoIP-Server-Cluster gruppiert werden.
VoIPGateway
Wie in Abbildung 10.3-1 ersichtlich ist, setzt sich das VoIP-Gateway aus zwei Funktionskomponenten zusammen, d.h. aus Media Gateway (MG) und Media Gateway Controller (MGC) (vgl. Abb. 8.1-2 und 8.1-3). MG wird der Media Transport Plane und MGC der Call Control Plane zugeordnet.
Aufgabe von Service Control Plane
Die Systemkomponenten innerhalb der Call Control Plane konfigurieren und verwalten in der Regel spezielle Service-Control-Komponenten, die sich auf der sog. Service Control Plane befinden. Dieser Ebene werden auch die sog. Directory Services (Verzeichnisdienste) des Netzwerks zugeordnet, auf die der VoIP-Server mit Hilfe des Protokolls LDAP zugreifen kann.
SoftswitchAnsatz
Die in Abbildung 10.3-1 dargestellte Multiplane-Systemarchitektur entspricht der Architektur von Multiservice Next Generation Networks mit Softswitches (vgl. Abb. 1.4-6 und 1.4-7). Ein Call Controller entspricht der Funktion nach einem Softswitch. Daher kann die Call Control Plane als verteilter Softswitch angesehen werden. Aus diesem Grund spricht man bei der Migration zu einer reinen VoIP-Systemarchitektur mit verteilter Anrufsteuerung oft von einem Softswitch-Ansatz bzw. Softswitch-Lösung.
www.wiwobooks.com
10.3.1 Reine VoIP-Systemarchitektur am Einzelstandort VoIP-Server für Anrufsteuerung
Die harte Migration zum VoIP-Einsatz führt zu einer reinen VoIP-Systemarchitektur auf der Basis eines Netzwerks. Abbildung 10.3-2a illustriert eine derartige Systemarchitektur am Einzelstandort. Für die Realisierung von VoIP wird das Netzwerk über ein VoIP-Gateway an das öffentliche Sprachkommunikatonsnetz (ISDN/PSTN) angeschlossen. Der Anschluss erfolgt in der Regel über die ISDN-Schnittstelle S2M, die 30 Amtsleitungen zur Verfügung stellt (s. Abschnitt 2.2). Da hier die Funktion der klassischen TK-Anlage nicht mehr vorhanden ist, erfolgt die Anrufsteuerung durch einen bzw. mehrere VoIPServer (VS). Um eine hohe Systemverfügbarkeit zu garantieren, installiert man mehrere VoIP-Server in großen Netzwerken redundant und räumlich voneinander getrennt (vgl. Abb. 10.3-1). Damit soll garantiert werden, dass die IP-Telefonie
10.3 Reine VoIP-Systemarchitekturen
409
im Unternehmen beim Auftreten außergewöhnlicher Störungen wie z.B. Brand in „abgeschwächter“ Form weiter verfügbar ist. Es ist vorteilhaft, die Komponenten des VoIP-Systems zu einem logischen VoIPNetzwerk, d.h. zu einem VLAN (Virtual LAN), zusammenzufassen. So entsteht Netzwerk als ein logisches VoIP-Netzwerk, das ein IP-Subnetz bildet. Dies hat den Vorteil, IP-Subnetz dass die privaten IP-Adressen den IP-Telefonen zugeordnet werden können. Ist dies der Fall, muss der Router R* an der Grenze zum Datennetzwerk zusätzlich die Funktion von NAT (Network Address Translation) realisieren – siehe Abschnitt 10.6. Abbildung 10.3-2b veranschaulicht die Anrufsteuerung. Hier wurde angenommen, dass das VoIP-System nach dem Standard H.323 funktioniert. Daher fungiert der VoIP-Server als Gatekeeper und enthält die Tabelle mit den Zuordnungen Telefonnummer IP-Adresse. Er dient damit als Auskunftsstelle, falls eine Anfrage nach der IP-Adresse eines IP-Telefons ankommt.
a )
S ta n d o r t A D S
L D A P
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
V S
S p ra c h -V L A N
VoIP-Server bei H.323 als Auskunftsstelle
A L G W
IS D N /P S T N
www.wiwobooks.com
T ln B
T ln A
R *
D a te n n e tz w e rk R
IP -W A N
A L : A m ts le itu n g e n D S : D ire c to ry S e rv ic e s G W : V o IP -G a te w a y R : R o u te r R * : R o u te r m it N A T T ln : T e iln e h m e r V S : V o IP -S e rv e r
b )
T ln B
A n ru f
IP -A d r? A n ru f
T ln A = > T ln B T ln B = > T ln A
T ln A
G W
V S
IP -A d r? A n ru f
A n ru f
Abb. 10.3-2: Beispiel für eine reine VoIP-Systemarchitektur am Einzelstandort: a) Komponenten der VoIP-Systemarchitektur; b) Veranschaulichung der Anrufsteuerung Anrufsignalisierung nach H.323, LDAP: Lightweight Directory Access Protocol, NAT: Network Address Translation
Bei einem ankommenden Anruf vom externen Teilnehmer A fragt das VoIPGateway (GW) zuerst beim VoIP-Server nach, welche IP-Adresse das Telefon des internen Teilnehmers B hat. Nach dem Eintreffen der Antwort mit der IPAdresse vom VoIP-Server leitet das VoIP-Gateway den ankommenden Anruf an das IP-Telefon des Teilnehmers B weiter.
Steuerung eines ankommenden Anrufs
410 Steuerung eines abgehenden Anrufs
10 Migration zum VoIP-Einsatz
Initiiert das IP-Telefon des internen Teilnehmers B einen abgehenden Anruf an den externen Teilnehmer A, fragt das IP-Telefon zuerst beim VoIP-Server nach der IP-Adresse des Telefons von Teilnehmer A. Dieses Telefon ist aber kein IP-Telefon, sondern ein Telefon am öffentlichen Sprachkommunikationsnetz, das über keine IP-Adresse verfügt. In diesem Fall erhält das IP-Telefon des internen Teilnehmers B vom VoIP-Server die IP-Adresse vom VoIP-Gateway. Der abgehende Anruf an den externen Teilnehmer A wird also zuerst zum VoIP-Gateway übermittelt und von dort an den Teilnehmer A weitergeleitet.
10.3.2 Verkabelung für die Unterstützung von VoIP Eine konvergente Netzwerkstruktur mit der Unterstützung von VoIP kann zwischen den Arbeitsplatzrechnern und den Ethernet-Switches, d.h. im sog. Etagenbereich (Tertiärbereich), eingerichtet werden mit getrennter Sprach- und Datenverkabelung oder gemeinsamer Sprach- und Datenverkabelung. Die Unterschiede zwischen diesen beiden Verkabelungsarten werden nun näher erläutert.
www.wiwobooks.com
Getrennte Sprach- und Datenverkabelung SprachVLAN
Ein Beispiel für eine konvergente Netzwerkstruktur mit getrennter Sprach- und Datenverkabelung im Etagenbereich zeigt Abbildung 10.3-3. Hier werden Arbeitsplatzrechner und IP-Telefone über getrennte Verkabelung im Etagenbereich an Ethernet-Switches angeschlossen, die sich in verschiedenen Etagenverteilern (EV) unterbringen lassen. Um ein Sprach-IP-Subnetz, das als Sprach-VLAN (Virtual LAN) angesehen werden kann, einfacher einrichten zu können, schließt man hier die IP-Telefone an getrennte Ethernet-Switches an. Die einzelnen Ethernet-Switches werden über einen Layer-2/3-Switch mit integrierter Routing-Funktion miteinander vernetzt. Bei einer derartigen Netzwerkstrukturierung kann ein Sprach-IP-Subnetz etagenübergreifend eingerichtet werden.
EthernetSwitches mit PoE
Für den Anschluss von IP-Telefonen können spezielle Ethernet-Switches eingesetzt werden, die die Stromversorgung für IP-Telefone über „Datenleitungen“ liefern. Man spricht dann von Power over Ethernet (PoE). Also handelt es sich hierbei um Ethernet-Switches mit PoE-Bereitstellung.
10.3 Reine VoIP-Systemarchitekturen
S p ra c h V L A N
E V
...
411
n
...
E th e rn e t-S w itc h e s
D
at e
Sp ra
n
ch e
...
...
E V 1
...
L a y e r-2 /3 -S w itc h &
S e rv e r-F a rm
W e b
...
V S
D N S
D M Z
R o u te r
G V
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
G W
IS D N /P S T N
F W
R
IP -W A N
www.wiwobooks.com
E V : E ta g e n -V e rte ile r F W : F ire w a ll
G V :G e b ä u d e -V e rte ile r
G W : V o IP -G a te w a y
R : R o u te r
V S : V o IP -S e rv e r
Abb. 10.3-3: Beispiel für Netzwerkstruktur mit getrennter Sprach- und Datenverkabelung DMZ: DeMilitarisierte Zone, DNS: Domain Name System
Gemeinsame Sprach- und Datenverkabelung Ein Beispiel für eine konvergente Netzwerkstruktur mit gemeinsamer Sprachund Datenverkabelung im Etagenbereich zeigt Abbildung 10.3-4. Im Unterschied zur Struktur in Abbildung 10.3-3 werden hier die Arbeits- IP-Telefon platzrechner nicht direkt an die Ethernet-Switches angeschlossen, sondern über als Switch IP-Telefone. In diesem Fall muss jedes IP-Telefon, über das ein Rechner an das Netzwerk angeschlossen ist, als „kleiner interner Ethernet-Switch“ mit zwei Down-Link-Ports (für den Anschluss eines externen Rechners und des inneren Telefonteils) und einem Up-Link-Port (für die Verbindung mit einem EthernetSwitch) fungieren. Um die Verzögerung der Sprache im IP-Telefon zu reduzieren, müssen die IPPakete mit Sprache beim Senden über den Up-Link-Port vorrangig vor den IPPaketen mit Daten behandelt werden. Daher muss das IP-Telefon bestimmte Verfahren des Queue-Managements unterstützen (s. Abschnitt 4.5).
412
10 Migration zum VoIP-Einsatz
...
E V n
...
D
S p ra c h IP -S u b n e tz
E th e rn e t-S w itc h (L a y e r-2 -S w itc h )
...
Sp ra
at en
ch e
...
E V
...
1
G V
L a y e r-2 /3 -S w itc h &
S e rv e r-F a rm W e b
...
R o u te r
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
D N S
V S D M Z
G W
IS D N /P S T N
F W R
IP -W A N
E V : E ta g e n -V e rte ile r G V :G e b ä u d e -V e rte ile r F W : F ire w a ll G W : V o IP -G a te w a y V S : V o IP -S e rv e r
Abb. 10.3-4: Beispiel einer Netzwerkstruktur mit gemeinsamer Sprach- und Datenverkabelung
www.wiwobooks.com DMZ: DeMilitarisierte Zone, DNS: Domain Name System
10.3.3 Standortübergreifende reine VoIP-Systemarchitekturen In Abschnitt 10.2.2 wurden grundlegende Arten standortübergreifender Vernetzung klassischer TK-Anlagen kurz dargestellt. Jede dieser Vernetzungsarten, d.h. zentrale oder verteilte Anrufsteuerung, entspricht einer Art von standortübergreifender reiner VoIP-Systemarchitektur. Eine Besonderheit dieser Systemarchitektur besteht darin, dass die Steuerung und das Management ankommender und abgehender Anrufe durch mehrere VoIP-Server, die beliebig verteilt sein können, erfolgen kann. VoIP-Systemarchitektur mit zentraler Anrufsteuerung Nebenstandort ohne PSTN/ISDNAnschluss
Ist ein Unternehmen auf mehrere Standorte verteilt und unterhält es eine Vernetzung von TK-Anlagen mit zentraler Anrufsteuerung (s. Abb. 10.2-2), führt eine harte Migration zu VoIP, bei der man auf die Funktion der klassischen TK-Anlage vollkommen verzichtet, zu einer verteilten VoIP-Systemarchitektur mit ebenfalls zentraler Anrufsteuerung. Abbildung 10.3-5a illustriert dies. Hier geht man davon aus, dass die VoIP-Signalisierung nach H.323 verläuft.
10.3 Reine VoIP-Systemarchitekturen
S ta n d o r t X (H a u p ts ta n d o r t)
a )
V S
V S -P X
S p ra c h -V L A N T ln B R
T ln B
V S
G W
V S
P S T N /IS D N
R : R o u te r
R
S p ra c h -V L A N
T ln : T e iln e h m e r
V S -P X
T ln A = > T ln B T ln A = > T ln C
2
D a te n n e tz w e rk Y
V S -P : V o IP -S e rv e r-P ro x y
T ln A A n ru f V S
T ln C Y
A n ru f A n ru f
T ln C = > T ln A
R
V S : V o IP -S e rv e r
G W
IP -A d r? IP -A d r?
R
IP -W A N X
T ln C Y
T ln A
IP -A d r? IP -A d r? IP -A d r = x x x A n ru f
b )
S ta n d o r t Y (N e b e n s ta n d o r t)
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
1
D a te n n e tz w e rk G W : V o IP -G a te w a y
A L
413
A n ru f
IP -A d r = y y y
A n ru f
IP -A d r?
www.wiwobooks.com
Abb. 10.3-5: Verteilte VoIP-Systemarchitektur mit zentraler Steuerung ankommender und abgehender Anrufe: a) Komponenten; b) Veranschaulichung der Anrufsteuerung VoIP-Signalisierung nach H.323, VLAN: Virtual LAN (VLAN = IP-Subnetz)
Die Netzwerke an beiden Standorten werden hier über VoIP-Gateway am Haupt- Nur eine standort mit dem öffentlichen Sprachkommunikationsnetz (PSTN/ISDN) über Vorwahlankommende und abgehende Amtsleitungen verbunden. Daher „sieht“ das öf- nummer fentliche Sprachkommunikationsnetz nur ein VoIP-Gateway. Dies garantiert, dass das ganze Unternehmen nur unter einer Vorwahlnummer des Hauptstandorts erreichbar ist. Die ankommenden externen Anrufe werden nur an das VoIP-Gateway am Hauptstandort geführt und von dort an den Nebenstandort weitergeleitet. An jedem Standort wurde ein VoIP-Server installiert. Daher ist am Hauptstand- Einsatz von ort eine Vertretung von beiden VoIP-Servern nötig, sodass für die ankommen- VoIP-Serverden, externen Anrufe nur die Vertretung sichtbar ist. Eine derartige Vertretung Proxy wird als VoIP-Server-Proxy (VS-P) bezeichnet (vgl. Abb. 9.3-2). Die Aufgabe eines VoIP-Server-Proxy wird in Abbildung 10.3-5b dargestellt. Bei einem ankommenden Anruf des externen Teilnehmers A fragt das VoIPGateway beim VS-P nach, welche IP-Adresse das Telefon des internen Teilnehmers B hat. VS-P stellt in diesem Fall fest, dass es sich um einen Anruf beim internen Teilnehmer am Standort X handelt. Daher übergibt er die Anfrage nach der IP-Adresse des IP-Telefons von Teilnehmer B an den VoIP-Server
Steuerung eines ankommenden Anrufs
414
10 Migration zum VoIP-Einsatz
am Standort X, der die gefragte IP-Adresse dem VoIP-Gateway liefert. Nach dem Empfang dieser IP-Adresse leitet das VoIP-Gateway den ankommenden Anruf direkt an das Telefon des Teilnehmers B weiter. Ist der angerufene Teilnehmer am Nebenstandort, verläuft die Weiterleitung des an ihn ankommenden externen Anrufs nach dem gleichen Prinzip wie zu einem Teilnehmer am Hauptstandort. Abbildung 10.3-5b illustriert dies auch. Aus dem eben gezeigten Beispiel für die Steuerung der ankommenden Anrufe geht hervor, dass die Aufgabe des VoIP-Server-Proxy, falls mehrere VoIPServer eingesetzt und beliebig verteilt werden, in der Auswahl des richtigen VoIP-Servers besteht (s. Abschnitt 9.1.1). Steuerung eines abgehenden Anrufs
Initiiert das IP-Telefon des internen Teilnehmers C am Nebenstandort Y einen abgehenden Anruf an den externen Teilnehmer A, so fragt dieses IP-Telefon zuerst beim VoIP-Server (VSY) nach der IP-Adresse des Telefons von Teilnehmer A. Dieses Telefon ist aber kein IP-Telefon, sondern ein Telefon am öffentlichen Sprachkommunikationsnetz, sodass das IP-Telefon des internen Teilnehmers C nicht die IP-Adresse des Telefons von Teilnehmer A vom VSY erhält, sondern die IP-Adresse vom VoIP-Gateway zum öffentlichen Sprachkommunikationsnetz. Daher wird der abgehende Anruf zuerst zum VoIP-Gateway am Hauptstandort übermittelt und von dort an den externen Teilnehmer A weitergeleitet.
Nebenstandort mit PSTN/ISDNAnschluss für abgehende Anrufe
Der Nebenstandort eines Unternehmens kann über ein VoIP-Gateway mit nur abgehenden Amtsleitungen an das öffentliche Sprachkommunikationsnetz angeschlossen werden. Einen solchen Fall illustriert Abbildung 10.3-6a.
www.wiwobooks.com
S ta n d o r t X (H a u p ts ta n d o r t)
a )
T ln B
V S
V S -P X
S p ra c h -V L A N R
G W
A L
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
P S T N /IS D N
A L
V S
T ln A R
IP -W A N X
A L : A m ts le itu n g e n G W : V o IP -G a te w a y R : R o u te r V S : V o IP -S e rv e r V S -P : V o IP -S e rv e r-P ro x y
G W
T ln A T ln C = > T ln A
A n ru f
T ln C Y
S p ra c h -V L A N
G W
R
1
D a te n n e tz w e rk
b )
S ta n d o r t Y (N e b e n s ta n d o r t)
R Y
2
D a te n n e tz w e rk
T ln : T e iln e h m e r
V S A n ru f
Y
IP -A d r?
T ln C
Abb. 10.3-6: Verteilte VoIP-Systemarchitektur mit zentraler Steuerung ankommender Anrufe: a) Komponenten der VoIP-Systemarchitektur b) Steuerung eines abgehenden Anrufs VoIP-Signalisierung nach H.323, VLAN: Virtual LAN (VLAN = IP-Subnetz)
10.3 Reine VoIP-Systemarchitekturen
415
Vergleicht man Abbildungen 10.3-6b und 10.3-5b, so ist ersichtlich, dass die externen abgehenden Anrufe vom Nebenstandort direkt über das an diesem Standort installierte VoIP-Gateway in das öffentliche Sprachkommunikationsnetz geleitet werden.
VoIP-Systemarchitektur mit verteilter Anrufsteuerung Ein Beispiel für eine reine VoIP-Systemarchitektur mit verteilter Anrufsteuerung zeigt Abbildung 10.3-7a. Zu dieser Systemarchitektur würde beispielsweise eine harte Migration zu VoIP bei der in Abbildung 10.2-3 gezeigten standortübergreifenden Vernetzung von TK-Anlagen führen, falls man auf den Einsatz klassischer TK-Anlagen vollkommen verzichten würde. Die Netzwerke an den beiden Standorten werden hier mit Hilfe von VoIP-Gateways mit dem öffentlichen Sprachkommunikationsnetz über ankommende und abgehende Amtsleitungen verbunden. Sind die VoIP-Gateways an Ortsnetzen mit verschiedenen Vorwahlnummern installiert, kann das VoIP-System an jedem dieser beiden Standorte als eigenständiges VoIP-System betrachtet werden, das unter eigener Vorwahlnummer vom öffentlichen Sprachkommunikationsnetz aus erreichbar ist. Zwar wird ein VoIP-Server an jedem Standort installiert, doch ist ein VoIP-Server-Proxy nicht nötig, wie es in den Abbildungen 10.3-5 und 10.3-6 der Fall war.
www.wiwobooks.com
S ta n d o r t X , V o r w a h l = 0 6 7 1
a )
V S X
S p ra c h -V L A N T ln B R
G W
T ln B
R
V S
A L
G W : V o IP -G a te w a y
R : R o u te r
G W X
IP -A d r?
T ln C Y
S p ra c h -V L A N
G W
R R
IP -W A N X
IP -A d r? A n ru f IP -A d r?
S ta n d o r t Y , V o r w a h l = 0 8 9 2
T ln A
V S
b )
P S T N /IS D N
1
D a te n n e tz w e rk A L : A m ts le itu n g e n
A L
Ö ffe n tlic h e s S p r a c h k o m m u n ik a tio n s n e tz
T ln : T e iln e h m e r
2
D a te n n e tz w e rk Y
V S : V o IP -S e rv e r
T ln A A n ru f
T ln A = > T ln B T ln B = > T ln C
V S
T ln C Y
IP -A d r = x x x
A n ru f
Abb. 10.3-7: Verteilte VoIP-Systemarchitektur mit verteilter Steuerung ankommender und abgehender Anrufe: a) Komponenten der VoIP-Systemarchitektur b) Steuerung eines ankommenden und eines abgehenden Anrufs VoIP-Signalisierung nach H.323, VLAN: Virtual LAN (VLAN = IP-Subnetz)
PSTN/ISDNAnschlüsse an allen Standorten
416
10 Migration zum VoIP-Einsatz
Steuerung eines ankommenden Anrufs
Abbildung 10.3-7b soll die Anrufsteuerung kurz erläutern. Hier wurde angenommen, dass das VoIP-System nach dem Standard H.323 funktioniert. Wie hier gezeigt wurde, fragt das VoIP-Gateway beim VoIP-Server VSX bei einem ankommenden Anruf des externen Teilnehmers A nach, welche IP-Adresse das Telefon des internen Teilnehmers B hat. Nach dem Eintreffen der Antwort vom VSX leitet das VoIP-Gateway den ankommenden Anruf an das IP-Telefon des Teilnehmers B am Standort X weiter.
Steuerung eines Anrufs zwischen internen Teilnehmern
Initiiert das IP-Telefon des internen Teilnehmers B am Standort X einen abgehenden Anruf an den internen Teilnehmer C am Standort Y, fragt das IP-Telefon zuerst beim VSX nach der IP-Adresse des Telefons von Teilnehmer C. Dieses Telefon ist aber nicht am Standort X, sondern am Standort Y. In diesem Fall übergibt VSX die Anfrage nach der IP-Adresse an den VoIP-Server VSY am Standort Y. Dieser übermittelt die gewünschte IP-Adresse direkt an das IPTelefon des Teilnehmers B am Standort X. Dieses IP-Telefon signalisiert danach den Anruf direkt dem IP-Telefon des Teilnehmers C am Standort Y.
10.4 Auswahl einer VoIP-Systemlösung
www.wiwobooks.com
Entscheidung: Harte oder sanfte Migration zu VoIP?
Falls eine vollkommen neue und konvergente Netzwerkstruktur mit VoIP in einem Unternehmen bzw. in einer anderen Institution aufgebaut werden muss, sollte ein reines Softswitch-basiertes VoIP-System für die Sprachkommunikation bevorzugt werden. Ist in einem Unternehmen eine noch vollkommen funktionsfähige TK-Anlage bereits vorhanden und eventuell noch nicht ganz unverzichtbar, ist die Entscheidung Harte oder sanfte Migration zu VoIP? von einigen Kriterien abhängig. Um in einer solchen Situation die richtige Entscheidung zu treffen, sollte man ein wirtschaftlich fundiertes Migrationskonzept mit geschätzten Gesamtkosten erstellen. Je nach Ausgangssituation, vorliegenden Angeboten von Systemkomponenten und Dauer der Migration kann eine – eventuell noch – hybride bzw. eine reine VoIP-Systemlösung in Frage kommen.
Entscheidungskriterien
Bevor man mit der Erstellung eines detaillierten Konzeptes für das VoIP-System beginnt, muss zuerst entschieden werden, ob die VoIP-Systemlösung hybrid oder Softswitch-basiert sein soll. In diesem Zusammenhang müssen mehrere Fragen beantwortet werden, u.a. folgende: Was passiert mit einer vorhandenen und noch funktionsfähigen TK-Anlage? Ist der bestehende Mietvertrag wirtschaftlich und kann er sinnvoll verlängert werden? Was passiert mit vorhandenen und vollkommen funktionsfähigen Telefonen? Sollen sie stufenweise abgebaut oder weiter verwendet werden? Falls sie weiter im Einsatz sein sollen, können sie an das VoIP-System über spezielle Gateways, die sog. Telefon-Hubs, angeschlossen werden (s. Abschnitt 8.1). Was passiert mit Teilnehmern, die noch heute an die klassische TK-Anlage angeschlossen sind? Existieren eventuell spezielle und für die Geschäftsprozesse im Unternehmen wichtige Anwendungen, die nur auf Basis der klassischen TK-Anlage realisierbar sind? Kann IP-Kommunikation den Ablauf der Geschäftsprozesse besser unterstützen? Ist ein Parallelbetrieb der klassischen TK-Anlage und eines VoIP-Systems langfristig wirklich sinnvoll und wirtschaftlich? Kann der Parallelbetrieb langfristig betreut werden? Welches technische Personal benötigt man für die Systembetreuung? Über welches Wissen muss das technische Personal verfügen?
10.5 Hauptschritte bei der Migration zu VoIP
417
Über welchen Zeitraum soll sich die Investition für VoIP amortisieren? Wie stabil ist das heutige Angebot von VoIP-Systemkomponenten? Werden diese Systemkomponenten in der heutigen Form noch in ein paar Jahren existieren? Diese Liste von Fragestellungen ist mit Sicherheit nicht vollständig. Wie man hier leicht erkennen kann, gibt es keine allgemeingültige Migrationsstrategie zu VoIP in großen Unternehmen bzw. anderen Institutionen. Die möglichst optimale Migrationstrategie muss für jeden einzelnen Fall gefunden werden.
10.5 Hauptschritte bei der Migration zu VoIP Die Migration zum VoIP-Einsatz in einem Unternehmen bzw. in einer anderen Organisation stellt ein komplexes Projekt dar. Für die Planung und technische Realisierung dieses Projekts ist die in Abbildung 10.5-1 gezeigte strukturierte Vorgehensweise unabdingbar. Um die Basis für die Einführung von VoIP zu schaffen, ist es zuerst erforderlich, die aktuelle Situation hinsichtlich der Sprachkommunikation im Unternehmen präzise zu analysieren. Diese Projektphase wird Ist-Analyse genannt. Die Einführung von VoIP sollte die aktuelle Sprachkommunikation im Unternehmen verbessern, um die Effizienz bei organisatorischen Abläufen zu steigern. Deswegen soll die Ist-Analyse sowohl das organisatorische als auch das technische Umfeld betreffen. Abschnitt 10.5.1 geht näher auf die Ist-Analyse ein.
Ist-Analyse
Nach der Ist-Analyse erfolgt die Soll-Analyse. Während der Soll-Analyse werden die Anforderungen an das VoIP-System zusammengestellt. Es handelt sich hierbei um sowohl organisatorische als auch technische Anforderungen. Die Soll-Analyse muss somit alle Punkte als Ergebnisse der Ist-Analyse berücksichtigen. Sie wird detaillierter in Abschnitt 10.5.2 dargestellt.
Soll-Analyse
IstO rg a n is a to ris c h e s A n a ly s e U m fe ld
P la n u n g s p h a s e
T e c h n is c h e s U m fe ld
S o ll-A n a ly s e : A n fo rd e ru n g e n a n V o IP -S y s te m O rg a n is a to ris c h e T e c h n is c h e A n fo rd e ru n g e n A n fo rd e ru n g e n
K o s te n /N u tz e n A n a ly s e
E n tw ic k lu n g d e s V o IP -S y s te m k o n z e p ts P flic h te n h e ft
B e s c h a ffu n g v o n S y s te m k o m p o n e n te n T e c h n is c h e R e a lis ie r u n g
In s ta lla tio n u n d
S ta n d a rd s /R ic h tlin ie n u n d E n tw ic k lu n g s tre n d s
www.wiwobooks.com
A b n a h m e
In b e trie b n a h m e u n d S c h u lu n g
Abb. 10.5-1: Allgemeine Vorgehensweise bei der Migration zum VoIP-Einsatz in Unternehmen
418
10 Migration zum VoIP-Einsatz
Entwicklung des Systemkonzeptes
Das Ergebnis der Soll-Analyse soll ein Katalog von Systemanforderungen sein, der als Basis für die Erstellung des VoIP-Systemkonzeptes dient. Die Entwicklung des VoIP-Systemkonzeptes ist der nächste Schritt. Ein konvergentes Unternehmensnetz mit VoIP ist ein sehr komplexes Gebilde, sodass sich dessen Systemkonzept aus mehreren Komponenten, die als Teilkonzepte angesehen werden können, zusammensetzt. Auf diese Komponenten geht Abschnitt 10.5.3 kurz ein.
Kosten/ NutzenAnalyse
Da die einsetzbaren Mittel immer limitiert sind, ist eine kontinuierliche Kosten/Nutzen-Analyse während der Entstehung des VoIP-Systemkonzeptes notwendig. Diese Analyse führt in der Regel zu einem iterativen Prozess der Verbesserung des Systemkonzeptes. Hierbei treten u.a. folgende Schwierigkeiten auf: Ermittlung von repräsentativen Kosten: Die Kosten können meist nur innerhalb eines kleinen Zeitraums ermittelt werden, sodass sie auf längere Sicht oft fragwürdig sind (z.B. als Folge einer neuen Zinslage). Abschätzung der Folgekosten: Risikoabschätzung, Folgeinvestitionen, ... Ermittlung aller Einflussfaktoren: Welche Einsparungen mit VoIP möglich sind und welche anderen Nutzungspotenziale es bietet, lässt sich umso schwerer ermitteln, je mehr Unternehmensbereiche davon betroffen sind. Bei der Kosten/Nutzen-Analyse sind folgende Kosten und Einsparungen zu berücksichtigen: Fixe Kosten: Hierbei handelt es sich um die bei der Durchführung des Projektes einmalig verursachten Kosten. Hierzu gehören u.a.: evtl. Beratungskosten, Kosten für die Durchführung der Ausschreibung, Kosten der Beschaffung von Systemkomponenten, Installationskosten (z.B. Verkabelungskosten).
www.wiwobooks.com
Laufende Kosten: Hierzu zählen alle Kosten, die im Laufe der Zeit immer wieder auftauchen. Die laufenden Kosten werden oft pro Monat angegeben. Zu dieser Kostenart gehören u.a.: Telefon- und Internet-Kosten, Personalkosten (Wartung und Pflege, Netzadministration), Kosten für Hardware- und Software-Update (evtl. Leasing), evtl. Versicherung und Zinsen. Direkte (errechenbare) Einsparungen: Folgende Einsparungen sind eventuell denkbar: Personaleinsparungen, Gebühreneinsparungen, Hardware-Einsparungen (z.B. durch Verzicht auf die TK-Anlage). Indirekte (nicht errechenbare) Einsparungen: Hierzu gehören nicht monetär bewertbare Nutzungspotentiale wie z.B. Erhöhung der Konkurrenzfähigkeit des Unternehmens, verbesserte Kommunikation etc. Eine Kosten/Nutzen-Analyse mit dem Vergleich monetärer Ergebnisse ist zwar oft ein wichtiger Faktor bei der Auswahl der richtigen VoIP-Systemlösung, doch auch die nicht monetär bewertbaren Nutzungspotenziale sind manchmal von entscheidender Bedeutung.
Pflichtenheft
Wurde das Konzept des VoIP-Systems erstellt, wird damit die Planungsphase beendet. Es muss nun im sog. Pflichtenheft dokumentiert werden, wie man die Aufgaben bei der technischen Realisierung des VoIP-Systems verteilt. Das Pflichtenheft ist ein Dokument, in dem die Aufgaben, die bei der Realisierung des erstellten Systemkonzeptes erledigt werden müssen, in der Reihenfolge ihrer Erledigung/Bedeutung und mit der Angabe der zuständigen Person(en) vollständig aufgelistet sind.
Beschaffung
Nach der Erstellung des VoIP-Systemkonzeptes und des Pflichtenheftes erfolgt die Beschaffung von Systemkomponenten. Hierfür ist eine Auflistung aller notwendigen Systemkomponenten mit deren Anzahl und den eventuellen Bemerkungen bzw. den konkreten Anforderungen nötig. Die Beschreibung der einzelnen Komponenten sollte recht ausführlich definiert sein, denn selbst eine geringfügige Eigenart einer Systemkomponente kann demnach zu einer unerwünschten Folge führen. Wurden die notwendigen Systemkomponenten spezifiziert, kann deren Beschaffung er-
10.5 Hauptschritte bei der Migration zu VoIP
419
folgen. Außer der Liste erforderlicher Systemkomponenten müssen weitere Details für die Anbieter präzisiert werden. Hierzu gehören u.a.: Zeitplan für die Realisierung der Ausschreibung und Liefertermin Richtlinien für die Abnahme Wartungskonzept und evtl. Schulungskonzept Diese Angaben mit einer ausführlichen Liste von Systemkomponenten müssen in den Ausschreibungsunterlagen enthalten sein, die an verschiedene Anbieter gesendet werden. Wünschenswert wäre es, die benötigten Systemkomponenten von einem Anbieter zu bekommen. Eine Auswahl von Systemkomponenten, die den technischen Anforderungen genügen, sollte u.a. anhand folgender Bewertungskriterien erfolgen:
Auswertung der Angebote
Vollständigkeit und Richtigkeit des Angebots Direkter Kostenvergleich: Preis des Angebots Langfristiger Kostenvergleich: Folgekosten, Schulungskosten, Update-Kosten, Wartungskosten, Risikoabschätzung etc. Entspricht das Angebot dem Standard? Wie wird die Wartung und Pflege gesichert? Bewertung des Anbieters: Seriosität, Größe der Firma, Erfahrungen, Referenzliste, eigene Werkstatt etc. Nach der Beschaffung von Systemkomponenten erfolgt deren Installation und Abnahme. Nachdem die Systemkomponenten installiert, konfiguriert und alle Sicherheitsdienste eingerichtet wurden, ist es trotzdem nicht vollständig vor unvorhergesehenen Ereignissen geschützt, die sich schnell zu Notfällen entwickeln können.
Installation und Abnahme
Die Migration zu VoIP endet mit der Inbetriebnahme des installierten VoIP-Systems und der eventuellen Schulung von Mitarbeitern, sodass sie in die Lage versetzt werden, das VoIP-System effektiv zu nutzen. Während der Installation von VoIP-Systemkomponenten soll die Dokumentation des Systems entsprechend den gestellten Anforderungen teilweise erstellt werden.
Inbetriebnahme und Schulung
Es ist die ständige Verfügbarkeit des VoIP-Systems gefordert. Um sie so weit wie möglich zu garantieren bzw. bei Störungen so schnell wie möglich wiederherstellen zu können, ist ein Notfallplan nötig. Er muss während der Planungsphase erstellt werden und enthält eine Auflistung von denkbaren Notfällen und Störungen mit einer Angabe von Maßnahmen, die in den einzelnen Fällen ergriffen werden sollen.
Notfallplan
www.wiwobooks.com
Ein wesentlicher Gesichtspunkt bei der Migration zum VoIP-Einsatz in einem Unternehmen ist die Berücksichtigung geltender Standards und Richtlinien sowie Entwicklungstrends, die insbesondere die Systemanforderungen, das Systemkonzept und die zu beschaffenden Systemkomponenten beeinflussen.
10.5.1 Ist-Analyse bei der Migration zu VoIP Zu Beginn der Migration zum VoIP-Einsatz in einem Unternehmen ist es erforderlich, die aktuell vorhandenen Strukturen und Abläufe präzise zu erfassen. Dies stellt eine Ist-Analyse dar. Erst auf der Basis der hier gewonnenen Erkenntnisse kann eine fundierte Planung eines VoIP-Systems erfolgen. Während der Ist-Analyse sollten organisatorische und technische Aspekte analysiert werden. Ziel dieser Ist-Analyse sollte sein, alle Schwachstellen heutiger Sprachkommunikation aufzulisten;
Ziele der IstAnalyse
420
10 Migration zum VoIP-Einsatz alle Verbesserungsvorschläge der Sprachkommunikation zu erfassen; eine Wunschliste innovativer VoIP-Applikationen zu erstellen. Für weitere Informationen darüber siehe auch [BaBe 10].
Organisatorische Aspekte der Ist-Analyse Die Struktur und die Leistungsmerkmale des einzurichtenden VoIP-Systems sollen an die existierenden organisatorischen Strukturen und Abläufe des Unternehmens angepasst werden. Aus diesem Grund sollte man diese Bereiche des organisatorischen Umfelds analysieren, auf die das neue VoIP-System irgendwelche Auswirkungen haben könnte. Abbildung 10.5-2 zeigt eine Auflistung von Schwerpunkten der Ist-Analyse des organisatorischen Umfelds bei der Migration zu VoIP in einem Unternehmen.
I s t-A n a ly s e : O rg a n is a to ris c h e A s p e k te
D a te n s ic h e ru n g in d e r T K -A n la g e , P fle g e v o n T e iln e h m e rd a te n , V o r g e h e n s w e is e b e i S tö r u n g e n , ...
B e tr e u u n g d e r S p r a c h k o m m u n ik a tio n
E rfa ssu n A rt d e r K B ild u n g M o b ilitä U n te rs tü
U n te r s tü tz u n g d e r G e s c h ä fts p r o z e s s e
g d e s u n d e v o n K t v o n tz u n g
K o m m n b e tre o m p e T e iln e v o n E
u n ik u u n g te n z g h m e r -C o m
a tio n s b e d a rfs , ( C T I , ...) , ru p p e n , n , m e r c e , ...
www.wiwobooks.com H e u tig e B e trie b s k o s te n , Ü b e rtra g u n g s g e b ü h re n , B e tr e u u n g s k o s te n , ...
L a u fe n d e K o s te n d e r S p r a c h k o m m u n ik a tio n
N o tfa P e rso B e s te F in a n
v e r s c h ie d e n e R a n d b e d in g u n g e n
llp lä n e , n e lle R a n d b e d in g u n g e n , h e n d e /g e p la n te b a u lic h e S tru k tu r, z ie lle r u n d z e itlic h e r R a h m e n , ...
Abb. 10.5-2: Organisatorische Aspekte der Ist-Analyse bei der Migration zu VoIP
Schwerpunkte der Ist-Analyse
Schwerpunkte der Ist-Analyse des organisatorischen Umfelds: Betreuung der Sprachkommunikation Hierunter fallen alle Tätigkeiten und Abläufe, die heute im Unternehmen nötig sind, um die Sprachkommunikation auf dem geforderten Niveau zu garantieren. Daher sollte man u.a. Folgendes erfassen: − Wie werden die Konfigurationsdaten (z.B. Leistungsmerkmale von Nebenstellen) der vorhandenen TK-Anlage gesichert, und was könnte man hierbei verbessern? − Wie werden die Teilnehmerdaten gepflegt, um Einheitlichkeit und Konsistenz im Telefonverzeichnis des Unternehmens zu gewährleisten? Welche Personen besitzen die Berechtigung, diese Daten zu pflegen? Welche Verbesserungsvorschläge gibt es? − Wie wird die Vorgehensweise bei Störungen der Sprachkommunikation organisiert? Wer ist wofür zuständig? Was könnte man verbessern? Dies sollte dazu dienen, gute Vorschläge für die Betreuung des neuen VoIP-Systems erarbeiten zu können.
10.5 Hauptschritte bei der Migration zu VoIP Unterstützung der Geschäftsprozesse Es sollen die Aspekte der Sprachkommunikation erfasst werden, die bestimmte Auswirkungen auf den Verlauf der Geschäftsprozesse im Unternehmen haben. Hierzu gehört insbesondere die Erfassung des Kommunikationsbedarfs. Dabei sollten auch die Anforderungen des Verkaufs-, des Servicebereichs sowie der Marketingabteilung an das neue VoIP-System erfasst werden. Es sollte u.a. geklärt werden: Welche CTI-Lösungen (Computer Telephony Integration) werden gewünscht? Soll ein IP-basierter Contact Center für die Kundenbetreuung und die Unterstützung der E-Commerce-Prozesse eingerichtet werden? Wie weit soll die Mobilität von Teilnehmern unterstützt werden? Laufende Kosten der Sprachkommunikation Es sollen alle laufenden Kosten der Sprachkommunikation erfasst werden. Hierzu gehören die heutigen Betriebskosten (z.B. Miete der TK-Anlage), Übertragungsgebühren und Betreuungskosten inkl. Personalkosten. Verschiedene Randbedingungen Bei der Migration zum VoIP-Einsatz müssen auch verschiedene organisatorische Randbedingungen berücksichtigt werden. Hierzu gehören u.a.: Notfallpläne, personelle Randbedingungen (Einschränkungen), bestehende bzw. geplante Gebäudestruktur, finanzieller und zeitlicher Rahmen des Projekts.
Technische Aspekte der Ist-Analyse Bei der Einführung eines neuen VoIP-Systems in einem Unternehmen handelt es sich um die Konvergenz eines Datennetzes mit einem Sprachnetz auf Basis einer TK-Anlage. Hierbei müssen somit die beiden Netze entsprechend unter die Lupe genommen werden. Ihre Analyse sollte vor allem dazu beitragen, alle Schwachstellen des heutigen technischen Umfelds aufzulisten sowie eine Liste von Verbesserungsvorschlägen und eine Liste gewünschter innovativer VoIP-Applikationen zu erstellen. Die Ist-Analyse sollte die in Abbildung 10.5-3 aufgelisteten technischen Aspekte berücksichtigen.
www.wiwobooks.com T K -A n la g e u n d T o p o lo g ie d e r S A n a ly s e d e r V e B e s o n d e re D ie n U n te rs tü tz u n g d D o k u m e n ta tio n
I s t-A n a ly s e : T e c h n is c h e A s p e k te
E n d g e rä te (T e le fo n e , F a x g e rä te ), p ra c h n e tz e s , rk a b e lu n g d e s S p ra c h n e tz e s , s tm e rk m a le , e r M o b ilitä t, d e s S p r a c h n e tz e s , ...
A n a ly s e d e s S p r a c h n e tz e s
P h y s ik a lis c h e N e tz s tru k tu rie ru n g , L o g is c h e N e tz s tru k tu rie ru n g , S y s te m k o m p o n e n te n (L 2 /3 -S w itc h e s , R o u te r), In te rn e t-Z u g a n g : B a n d b re ite , U n te rs tü tz u n g d e r M o b ilitä t, N e tz w e rk s ic h e rh e it, D o k u m e n ta tio n d e s I P - N e tz e s , ...
A n a ly s e d e s IP -N e tz e s
T e c h n is c h e R ic P ro file v o n B e n In te g rie rte S p ra S tö ru n g s - u n d A G e b ä u d e m a n a g
v e r s c h ie d e n e R a n d b e d in g u n g e n
h tlin ie n u tz e rg r c h - u n d la rm m e m e n t,
/S ta n d a rd s , u p p e n , D a te n a n w e n d u n g e n , e ld u n g e n , ...
Abb. 10.5-3: Technische Aspekte der Ist-Analyse bei der Migration zu VoIP
421
422 Schwerpunkte der IstAnalyse
10 Migration zum VoIP-Einsatz Die technischen Aspekte der Ist-Analyse sollten u.a. sein: Analyse des Sprachnetzes Die klassischen Sprachnetze in Unternehmen basieren auf TK-Anlagen und sind oft mit Unternehmen gewachsen und genau an ihre Strukturen und Organisation angepasst. Die Analyse des Sprachnetzes sollte u.a. Folgendes erfassen: − Über welche Leistungsmerkmale verfügt die vorhandene TK-Anlage bzw. eine Vernetzung von TK-Anlagen, und welche Leistungsmerkmale werden vom neuen VoIP-System gewünscht? − Welche Arten von Telefonapparaten (analoge Apparate, digitale Apparate, schnurlose DECT-Apparate, Faxgeräte etc.) sind im Einsatz? Welche Leistungsmerkmale benötigt man für die Telefonapparate von Mitarbeitern? − Wie sieht die Topologie und die Verkabelung des Sprachnetzes aus? Über welche Anschlüsse erfolgt die Anbindung an das öffentliche Sprachkommunikationsnetz? Welche Auswirkungen hat die Topologie auf das einzurichtende VoIP-System? Kann die Verkabelung des Sprachnetzes teilweise für VoIP übernommen werden? − Welche besonderen Dienstmerkmale (Anrufumleitung, Parken und Anrufwiederaufnahme, Dreierkonferenz etc.) bietet das vorhandene Sprachkommunikationssystem, und welche Dienstsmerkmale werden vom VoIP-System verlangt? − Wie wird die Mobilität von Teilnehmern unterstützt, und welche Art der Mobilität soll das VoIP-System ermöglichen? − Wie wird das bestehende Sprachkommunikationssystem im Unternehmen dokumentiert, und wie wird diese Dokumentation beurteilt?
www.wiwobooks.com
Analyse des IP-Netzes
Wie die Sprachnetze sind auch die Datennetze in Unternehmen oft mit ihnen gewachsen und daher an ihre Strukturen und Organisation angepasst. Die Analyse des vorhandenen Datennetzes hinsichtlich der VoIP-Einführung sollte u.a. Folgendes erfassen: − Wie wird das Datennetz physikalisch strukturiert (Topologie)? Wie eignet sich die vorhandene Datennetzstruktur für VoIP? Fundamentaler Bestandteil dieser Analyse ist in der Regel eine Verkehrsmessung. − Wie wird das Datennetz logisch strukturiert (Subnetting)? Kann ein Sprach-VLAN eingerichtet werden? − Ermöglichen die Netzwerkkomponenten (L2/3-Switches, Router) die QoS-Unterstützung (s. Kapitel 4)? Ist die Bandbreite des Internet-Zugangs ausreichend? − Wie wird die Mobilität im Netzwerk unterstützt? Kommt das Protokoll Mobile IP zum Einsatz? Wo sind die Schwachstellen hinsichtlich der VoIP-Einführung? − Wie beeinflusst die VoIP-Einführung die Netzwerksicherheit? − Wie wird das bestehende Netzwerk dokumentiert, und welche Erweiterungen müssen bei der VoIP-Einführung vorgenommen werden? Verschiedene Randbedingungen Bei der Migration zum VoIP-Einsatz sind auch bestimmte technische Randbedingungen zu berücksichtigen. Hierzu gehören u.a.: technische Richtlinien, Standards und Profile von verschiedenen Arbeitsgruppen (Abteilungen). Man sollte auch klären, welche integrierten Sprach- und Datenlösungen (z.B. Call Center) vorhanden sind und welche Unterstützung hierbei vom VoIP-System zu erwarten wäre. Wie werden Störungen und Alarme gemeldet, und was könnte hier das VoIP-System leisten? Lässt sich das VoIP-System (z.B. mit Hilfe von SIP) für das Gebäudemanagement einsetzen? Wurde die Ist-Analyse beendet, kann man mit der Spezifikation von Anforderungen an das einzurichtende VoIP-System beginnen.
10.5 Hauptschritte bei der Migration zu VoIP
423
10.5.2 Anforderungen an VoIP-System Das Ziel der Soll-Analyse ist es (siehe hierfür auch [BaBe 10]), festzulegen:
Soll-Analyse
wie weit alle Schwachstellen, – als Ergebnis der Ist-Analyse – zu „beseitigen“ sind; wie weit die Verbesserungswünsche zu erfüllen sind; welche innovativen VoIP-Applikationen eingeführt werden sollen. Die Antworten auf diese Fragestellungen sollen in Form von Anforderungen an das neue VoIPSystem spezifiziert werden. Die organisatorischen Aspekte der Ist-Analyse (s. Abb. 10.5-2) ermöglichen es, organisatorische Anforderungen zu spezifizieren, und dementsprechend entstehen technische Anforderungen infolge der Ist-Analyse technischer Aspekte (s. Abb. 10.5-3). Eine Zusammenstellung sämtlicher Anforderungen an das VoIP-System kann als Katalog von Systemanforderungen angesehen werden.
Katalog von Systemanforderungen
Organisatorische Anforderungen Die Soll-Analyse des organisatorischen Umfelds im Unternehmen bei der Migration zum VoIPEinsatz soll zu einer Liste organisatorischer Anforderungen an das VoIP-System führen. Abbildung 10.5-4 zeigt eine Auflistung von organisatorischen Anforderungen (vgl. Abb. 10.5-2).
D a te n s ic h e ru n g in d e r IP -T K -A n la g e , P fle g e v o n T e iln e h m e rd a te n , V o r g e h e n s w e is e b e i S tö r u n g e n , ...
A n fo r d e r u n g e n a n d ie B e tr e u u n g d e r S p r a c h k o m m u n ik a tio n
E rfü llu n g d e s K o m K u n d e n b e tre u u n g : B ild u n g v o n K o m p M o b ilitä ts a rt v o n T U n te rs tü tz u n g s a rt v
A n fo r d e r u n g e n a n d ie U n te r s tü tz u n g d e r G e s c h ä fts p r o z e s s e
www.wiwobooks.com S o ll-A n a ly s e : O rg a n is a to ris c h e A n fo rd e ru n g e n
m u n ik a tio n s b e d a rfs , IP -C o n ta c t-C e n te r, e te n z g ru p p e n , e iln e h m e rn , o n E - C o m m e r c e , ...
L im itie ru n g v o n B e trie b s k o s te n , L im itie ru n g v o n Ü b e rtra g u n g s g e b ü h re n , L im itie r u n g v o n B e tr e u u n g s k o s te n , ...
L im itie r u n g v o n la u fe n d e n K o s te n d e r S p r a c h k o m m u n ik a tio n
A n A n V o F in
W e ite r e A n fo r d e r u n g e n
fo rd e ru n g fo rd e ru n g IP -B e tre u a n z ie lle r
e n e n n g u n
a n d ie S y s te m d o k u m e n ta tio n , a n N o tfa llp la n , s p e rs o n a l, d z e itlic h e r R a h m e n , ...
Abb. 10.5-4: Organisatorische Anforderungen an das VoIP-System Unter den organisatorischen Anforderungen unterscheidet man folgende Kategorien: Anforderungen an die Betreuung der Sprachkommunikation Diese Anforderungen beziehen sich u.a. auf: Datensicherung in der IP-TK-Anlage bzw. im VoIP-Server, Pflege von Teilnehmerdaten (Berechtigungen, Gebührenerfassung, ...), Vorgehensweise bei Störungen etc. Anforderungen an die Unterstützung der Geschäftsprozesse Hierbei spezifiziert man u.a.: Wie soll der Sprachkommunikationsbedarf erfüllt werden (z.B. wo und welche Telefone und mit welchen Leistungsmerkmalen installiert werden sollen)?
Kategorien von Anforderungen
424
10 Migration zum VoIP-Einsatz Wie soll die Kundenbetreuung mit dem VoIP-System unterstützt werden (z.B. durch Einrichten eines IP-Contact-Centers)? Welche Unterstützung durch das VoIP-System erwarten verschiedene Kompetenzgruppen (Entwicklung, Vorstand, Marketing, ...)? Wie weit soll die Mobilität von Teilnehmern garantiert werden (s. Abschnitte 6.7 und 7.1.7)? Welche Art der Unterstützung von E-Commerce wird vom VoIP-System gefordert? Limitierung von laufenden Kosten der Sprachkommunikation Nach Analyse der laufenden Kosten können die maximalen Grenzwerte für alle Arten dieser Kosten festgelegt werden. Diese Kostenlimitierung sollte durch den Einsatz des VoIP-Systems gewährleistet sein. Weitere Anforderungen Nach der Analyse verschiedener organisatorischer Randbedingungen wird festgelegt, wie diese Randbedingungen zu erfüllen sind. Hierzu gehören u.a. die Anforderungen an: − die Dokumentation des VoIP-Systems (was und wie dokumentiert werden soll); − den Notfallplan (wie man in Notsituationen (Wasser, Feuer) reagieren soll); − das Betreuungspersonal des VoIP-Systems (welches technische Wissen nötig ist); − den finanziellen und zeitlichen Rahmen.
Technische Anforderungen Welche Ziele?
Die Soll-Analyse des technischen Umfelds im Unternehmen bei der Migration zum VoIP-Einsatz soll zu einer Liste technischer Anforderungen an das VoIP-System führen. Abbildung 10.5-5 zeigt eine Auflistung von diesen Anforderungen (vgl. Abb. 10.5-3).
www.wiwobooks.com
S o ll-A n a ly s e : T e c h n is c h e A n fo rd e ru n g e n
A n fo rd e ru n g e n a n : p h y s ik a lis c h e N e tz s tru k tu rie ru n g , lo g is c h e N e tz s tru k tu rie ru n g , S y s te m k o m p o n e n te n , E n d g e rä te , In te rn e t-Z u g a n g : B a n d b re ite , d ie U n te rs tü tz u n g d e r B e n u tz e rm o b ilitä t, d ie N e tz w e r k s ic h e r h e it,...
A n fo r d e r u n g e n a n d a s V o IP -S y s te m
A n fo rd e in te g rie S tö ru n g G e b ä u d
g e fo r d e r te in n o v a tiv e V o IP -A n v e n d u n g e n
ru n g e n rte S p r s- u n d e m a n a
a n d ie U a c h - u n d A la rm m g e m e n t,
n te rs tü tz u n g v o n : D a te n a n w e n d u n g e n , e ld u n g e n , ...
T e c h n is c h e R ic h tlin ie n /S ta n d a rd s , D ie n s tm e rk m a le v o n B e n u tz e rg ru p p e n , F e s tle g u n g d e r R e c h te v o n T e iln e h m e r n , ...
E r fü llu n g v e r s c h ie d e n e r R a n d b e d in g u n g e n
Abb. 10.5-5: Technische Anforderungen an das VoIP-System
Kategorien von Anforderungen
Bei den technischen Anforderungen sind zu unterscheiden: Anforderungen an das VoIP-System Zu diesen Anforderungen gehören u.a.: − Anforderungen an physikalische Netzwerkstruktur: z.B. erforderliche Bandbreite (z.B. zwischen den Switches in Etagen-Verteilern und dem zentralen Switch im GebäudeVerteiler, s. Abb. 10.3-3 und -4); − Anforderungen an die logische Netzwerkstruktur; z.B. an die Größe des Sprach-VLAN;
10.5 Hauptschritte bei der Migration zu VoIP − − − −
Anforderungen an Netzwerkkomponenten (Switches, Router) und Endgeräte: Sind evtl. neue Switches bzw. Router nötig und an welcher Stelle? Welche Telefonapparate mit welchen Leistungsmerkmalen und welche Faxgeräte sollen wo installiert werden? Welche Bandbreite ist am Internet-Zugang nötig? Soll der Internet-Zugang redundant ausgelegt werden? Welche Art der Mobilität von Teilnehmern wird gefordert? Anforderungen an die Sicherheit der Sprachkommunikation.
Geforderte innovative VoIP-Anwendungen Hierbei wird u.a. spezifiziert: Welche integrierte Sprach- und Datenanwendungen soll das VoIP-System erbringen (z.B. soll ein IP-Contact-Center eingerichtet werden)? Welche Störungen und Alarme soll das VoIP-System melden? Soll das Gebäudemanagement mit dem VoIP-System unterstützt werden? Erfüllung verschiedener Randbedingungen Die Analyse technischer Randbedingungen (s. Abb. 10.5-3) führt u.a. zu den folgenden Festlegungen: − Welche technischen Richtlinien und Standards müssen erfüllt werden? − Welche Dienstmerkmale erwarten die Benutzer vom VoIP-System? − Welche Rechte bei der Nutzung des VoIP-Systems sollen verschiedene Benutzergruppen erhalten? Nach der Spezifikation von Anforderungen an das VoIP-System, z.B. in Form eines Katalogs von Systemanforderungen, kann man zur Erstellung des VoIP-Systemkonzeptes übergehen.
www.wiwobooks.com
10.5.3 Komponenten des VoIP-Systemkonzeptes
Aufbauend auf den Angaben aus dem Katalog von Systemanforderungen und den weiteren Erkenntnissen aus der Ist-Analyse wird das Konzept des VoIP-Systems erarbeitet. Das VoIPSystem ist ein sehr komplexes Gebilde, sodass sich dessen Systemkonzept aus mehreren Komponenten, die als Teilkonzepte angesehen werden können, zusammensetzt. Abbildung 10.5-6 zeigt, welche Komponenten ein VoIP-Systemkonzept enthalten soll.
K o n z e p t d e r D o k u m e n ta tio n
K o n z e p t d e r V e rk a b e lu n g
K o n z e p t d e r V e rn e tz u n g
K o m p o n e n te n d e s V o IP -S y s te m k o n z e p te s A d re s s ie ru n g s k o n z e p t
K o n z e p t fü r G e b ü h re n e rfa ssu n g u n d -a b re c h n u n g
S ic h e rh e its k o n z e p t
Abb. 10.5-6: Komponenten des VoIP-Systemkonzeptes Die Komponenten des VoIP-Systemkonzeptes sind: Konzept der Dokumentation des VoIP-Systems Eine zwingende Aufgabe beim Aufbau eines VoIP-Systems ist seine Dokumentation. Sie stellt einen Teil der Netzwerkdokumentation dar. Die Arbeiten an der Dokumentation sollten bereits in der Planungsphase beginnen und im Rahmen der Systeminstallation und -inbetrieb-
425
426
10 Migration zum VoIP-Einsatz nahme fortgesetzt und beendet werden. Insbesondere sind die für das VoIP-System zu installierenden Hardware- und Software-Komponenten entsprechend zu dokumentieren. Konzept der Verkabelung Von großer Auswirkung auf das VoIP-System ist die Netzwerkverkabelung. Sie muss entsprechend strukturiert sein und die benötigte Bandbreite garantieren. Bei Fast-Ethernet im Tertiärbereich, Gigabit-Ethernet im Sekundärbereich und Gigabit- bzw. 10-Gigabit-Ethernet im Primärbereich sind keine Bandbreitenprobleme im Netzwerk mit VoIP zu erwarten. Konzept der Vernetzung von VoIP-Systemkomponenten Der Kern des VoIP-Systemkonzepts ist die Festlegung, welche Systemkomponenten man benötigt, wie sie in das Netzwerk integriert werden und wie ein Sprach-VLAN eingerichtet wird. Dies ist von mehreren Faktoren und insbesondere davon abhängig, welche innovativen Applikationen (wie z.B. VoIP-basierte Call-Center-Funktionen, Unified Messaging) zur Verfügung gestellt werden sollen. Adressierungskonzept Es handelt sich hier um die Festlegung des Rufnummernplans. Dieses Konzept ist davon abhängig, ob es sich um eine standortübergreifende VoIP-Systemlösung handelt oder nicht. Es muss geklärt werden, wie die Adressvergabe und -verwaltung für IP-Telefone erfolgt. Wie weit wird die Mobilität von Teilnehmern unterstützt? Bleibt die Rufnummer des IP-Telefons beim Anschlusswechsel standortunabhängig erhalten? Konzept für Gebührenerfassung und -abrechnung Eine wichtige Aufgabe bei der Einführung eines VoIP-Systems im Unternehmen ist das Konzept für Gebührenerfassung und -abrechnung. Hierbei gilt es folgende Probleme zu klären: Wie werden Amtsgespräche von Mitarbeitern abgerechnet? Werden Einzelverbindungsnachweise erstellt? Wie wird die Gebührenerfassung bei einer standortübergreifenden VoIPSystemlösung organisiert (zentral, dezentral)?
www.wiwobooks.com
Sicherheitskonzept für das VoIP-System Die zentralen Komponenten des VoIP-Systems (wie z.B. VoIP-Server) müssen im Netzwerksicherheitskonzept entsprechend ihre Berücksichtigung finden. Die Benutzer des VoIPSystems müssen authentifiziert werden (siehe hierfür auch Kapitel 11 und [BaBe 10]).
10.6 VoIP mit SIP in Netzwerken mit NAT Bei VoIP hat sich SIP (s. Kapitel 7) als Signalisierungsprotokoll eindeutig durchgesetzt. In Netzwerken werden oft private IPv4-Adressen verwendet, sodass sie im Router an der Grenze zum Internet in offizielle (öffentliche) IPv4Adressen umgewandelt werden müssen. Diese Umsetzung bezeichnet man als NAT (Network Address Translation). Einen Verzicht auf die Nutzung privater IPv4-Adressen in Intranets kann man sich heute kaum vorstellen. Daher ist NAT unabdingbar. Im Folgenden handelt es sich ausschließlich um IPv4Adressen (der Einfachheit halber hier „IP-Adressen“ genannt). STUN, TURN und ICE
Ende der 90er-Jahre – als SIP konzipiert wurde – kannte man nur einfache Lösungen für NAT. Inzwischen wurden bei NAT aber bestimmte Funktionen für Firewalls „eingebaut“, was zu einigen Problemen am Internet-Zugang beim
10.6 VoIP mit SIP in Netzwerken mit NAT
427
Einsatz von SIP führt. Um diese zu lösen, wurden sowohl einige NAT-spezifische Erweiterungen im SIP – hierzu gehören Symmetric Response (s. Abschnitt 10.6.3) und Symmetric RTP/RTCP (s. Abschnitt 10.6.4) – als auch spezielle Protokolle konzipiert. Zuerst wurde das Protokoll STUN (Session Traversal Utilities for NAT) vorgeschlagen (s. Abschnitt 10.6.5). Es stellte sich aber bald heraus, dass die Probleme mit SIP bei NAT mit Hilfe von STUN nicht vollständig lösbar sind. Daher wurde STUN zu TURN (Traversal Using Relays around NAT) „ausgebaut“ (s. Abschnitt 10.6.6). Mit TURN werden die Probleme zwar gelöst, es entstehen jedoch einige Engpässe. Deshalb suchte man weiter nach einer effektiven Lösung, um SIP bei NAT mit Firewalls verwenden zu können. Diese Lösung heißt ICE (Interactive Connectivity Establishment) und hat – wie Abschnitt 10.6.7 zeigt – große Bedeutung bei der audiovisuellen Kommunikation über IP-Netze mit SIP. Ziel dieses Abschnittes ist es, die Lösungen für VoIP mit SIP in Netzwerken mit privaten IPv4-Adressen kurz darzustellen und zu zeigen, wie und wann sie eingesetzt werden können.
10.6.1 Prinzipien von NAT
www.wiwobooks.com
Sehen wir uns zunächst die Ideen von NAT kurz an. Das Paar (IP-Adresse, Port-Nummer einer Applikation), das man auch Socket nennt, ist für die Kommunikation über IP-Netze und auch bei NAT von zentraler Bedeutung. Bezeichnet man ein Socket kurz als (A:b) – d.h. A = IP-Adresse und b = Port –, können die grundlegenden Arten von NAT wie folgt beschrieben werden: Klassisches NAT Eine private IP-Adresse A eines Quellrechners wird durch NAT auf eine offizielle (öffentliche) IP-Adresse X umgewandelt. In einer NAT-Instanz – z.B. im Router am Internet – wird eine Tabelle geführt, in der eingetragen ist, welche offiziellen IP-Adressen welchen privaten IP-Adressen zugeordnet sind. Es handelt sich hierbei also um die Zuordnungen (A:b) (X:b). Einem privaten Socket (A:b) wird an der Grenze zum Netzwerk mit offiziellen IP-Adressen ein offizieller Socket (X:b) zugeordnet. Diese Zuordnung bezeichnet man als Binding. Network Address Port Translation (NAPT)
NAPT, PAT
Dem ganzen Netzwerk mit einer Vielzahl privater IP-Adressen steht nur eine offizielle IPAdresse zur Verfügung, und die NAT-Instanz muss die zahlreichen privaten IP-Adressen auf eine einzige, offizielle IP-Adresse X abbilden. Diese NAT-Variante wird Network Address Port Translation (NAPT) bzw. Port Address Translation (PAT) genannt. Für NAPT hat sich der Begriff IP-Masquerading etabliert. Bei NAPT wird bei Bedarf zuerst jedem privaten Socket (A:b) ein dedizierter Port y im Router zugewiesen – d.h. y=(A:b) – und danach ein offizieller Socket (X:y)zugeordnet. Daher entsteht hier das Binding (A:b) (X:y) (siehe Abbildung 10.6-1). In der Praxis – und damit beim Einsatz von SIP – ist nur NAPT von Bedeutung. Daher wird im Weiteren das klassische NAT außer Acht gelassen. Die NAT-Funktion wird in der Regel im Router am Internet untergebracht. In diesem Router kann auch eine Firewall-Funktion realisiert werden, die bei der Nutzung des verbindungslosen
Arten von NAT
428
10 Migration zum VoIP-Einsatz Transportprotokolls UDP – und somit auch bei SIP over UDP – von großer Bedeutung ist. Die beiden Funktionen NAT und Firewall hängen eng miteinander zusammen, sodass man zwischen verschiedenen Arten von NATs mit Unterstützung von Firewalls unterscheidet. Dabei handelt es sich um folgende Arten von NATs: Full Cone NAT Restricted Cone NAT bzw. Port Restricted Cone NAT Symmetric NAT
Full Cone NAT
Full Cone NAT ist eine Variante von NAPT, die keine Firewall-Funktion realisiert und bei der die Nummer des offiziellen Socket im Router unabhängig von der Ziel-IP-Adresse ist. Abbildung 10.6-1a veranschaulicht die Funktionsweise von Full Cone NAT. Seitens des Internet wurde im Router mit NAT der offizielle Socket (X:y) dem privaten Socket (A:b) im Rechner mit der privaten IP-Adresse A zugeordnet. Infolgedessen besteht das Binding (A:b) (X:y). Bemerkung: Ein privater Socket wird im Weiteren als interner Socket und ein offizieller Socket als externer Socket bezeichnet. Der Rechner kann daher über den externen, offiziellen Socket (X:y) IP-Pakete in das öffentliche Internet senden und solche auch von ihm empfangen. Solange zwischen diesen beiden Sockets bei NAT das Binding besteht, ist der externe Socket (X:y) im Router bei Full Cone NAT immer offen. Jeder externe Rechner am Internet kann seine IP-Pakete an den externen Socket (X:y) senden, und sie alle werden bei Full Cone NAT vom Router an den internen Socket (A:b) weitergeleitet. In diesem Fall realisiert NAT keine Firewall-Funktion.
a )
www.wiwobooks.com
P riv a te s N e tz w e rk (A :b ) B in d in g (A :b )
b )
R
In te rn e t
N A T (X :y ) (X :y )
o n e F u ll C
S o c k e ts
P riv a te s N e tz w e rk
R
N A T
In te rn e t
M o n d S o n n e
v o rh e r (A :b )
(X :y )
B in d in g (A :b ) (X :y )
n a c h h e r
R e s tric te d C o n e
Abb. 10.6-1: Das grundlegende Prinzip von: a) Full Cone NAT; b) Restricted Cone NAT A, X: IP-Adressen; b, y: Ports; R: Router
Die Bezeichnung Full Cone ist damit zu begründen, dass eine Socket-Konstellation entsteht, die an einen vollen Kegel erinnert. Abbildung 10.6-1a bringt dies zum Ausdruck.
Restricted Cone NAT
Bei NAT mit einer zusätzlichen Firewall-Funktion, bei der ein externer Socket von der Ziel-IPAdresse abhängig ist, handelt es sich um Restricted Cone NAT. Abbildung 10.6-1b illustriert die Funktionsweise dieser Art von NAT. Hat der Rechner im Netzwerk mit der privaten IP-Adresse A ein IP-Paket an einen externen Rechner am Internet – z.B. den Rechner Sonne – abgeschickt, wurde sein interner Socket (A:b) auf den externen Socket (X:y) im Router abgebildet. Es besteht hier also das Binding (A:b) (X:y) – wie bei Full Cone NAT (vgl. Abb.10.6-1a). Der externe Rechner Sonne kann als Antwort ein IP-Paket an den externen Socket (X:y) senden, und dieses IP-Paket wird vom Router an den internen Socket (A:b)im privaten Netzwerk weitergeleitet. Hat der Rechner Mond aber z.B. ein IP-Paket an den externen Socket (X:y) abgeschickt, ohne vorher ein IP-Paket von diesem Socket empfangen zu haben, wird dieses IP-Paket in der NAT-Instanz blockiert und nicht an den internen Socket (A:b)weitergeleitet. So realisiert man eine Firewall-Funktion bei NAT.
10.6 VoIP mit SIP in Netzwerken mit NAT
429
Bei Restricted Cone NAT wird ein Paket von einem externen Rechner am Internet nur dann an den internen Socket (A:b)weitergeleitet, wenn an diesen externen Rechner am Internet bereits ein IP-Paket seitens des Rechners mit der privaten IP-Adresse A abgeschickt wurde. Daher werden bei Restricted Cone NAT lediglich die IP-Pakete eines bereits vorher „kontaktierten“ Rechners nicht blockiert und somit zum Rechner mit der privaten IP-Adresse A weitergeleitet. Bei Port Restricted Cone NAT wird ein Paket vom Port j im externen Rechner Sonne nur dann nicht blockiert und somit an den Rechner mit der privaten IP-Adresse A weitergeleitet, wenn vom internen Socket(A:b)bereits vorher ein IP-Paket an den Port j im Rechner Sonne abgeschickt worden ist. Damit werden bei Port Restricted Cone NAT lediglich die IP-Pakete von einem vorher „kontaktierten“ Socket nicht blockiert und zum internen Socket in Netzwerk weitergeleitet. Man kann daher Restricted Cone NAT als erste Sicherheitsstufe und Port Restricted Cone NAT als zweite Sicherheitsstufe bei der verbindungslosen Kommunikation mit Hilfe des Protokolls UDP – und folglich auch bei SIP over UDP – betrachten.
Port Restricted Cone NAT
Sendet ein Rechner im Netzwerk mit privaten IP-Adressen Pakete zu unterschiedlichen Rechnern am Internet und der Router mit der NAT-Funktion leitet diese Pakete – wie dies Abbildung 10.62 illustriert – über verschiedene von Zielrechnern abhängige Ports weiter, realisiert er eine Variante von NAT, die man als Symmetric NAT bezeichnet.
Symmetric NAT
Bei Symmetric NAT verläuft die Kommunikation zu den einzelnen Zielrechnern am Internet über die vom Zielrechner abhängigen Ports im Router. Jeder externe Socket in einer NAT-Instanz im Router entspricht daher genau einem Ziel im Internet. Somit werden nur solche an einen externen Socket gesendeten IP-Pakete nicht blockiert, die von genau dem Zielrechner kommen, der – logisch gesehen – mit diesem externen Socket verbunden ist.
www.wiwobooks.com
P riv a te s N e tz w e rk
(A :b ) (A :b )
B in d in g
R N A T (X :y )
In te rn e t
(C :d )
(X :z ) (X :y )
(C :d )
S o c k e ts
(E :f) (A :b )
(X :z )
(E :f)
B in d in g
Abb. 10.6-2: Veranschaulichung des Prinzips von Symmetric NAT A, X, C, E: IP-Adressen; b, d, f, y, z: Ports; R: Router
Wie Abbildung 10.6-2 zum Ausdruck bringt, wird im gezeigten Beispiel Symmetric NAT in der NAT-Instanz mit den Bindings (A:b) (X:y) (C:d) und (A:b) (X:z) (E:f) erreicht. In diesem Fall wird zusätzlich eine Firewall-Funktion realisiert.
10.6.2 Probleme mit SIP beim NAT-Einsatz Probleme mit SIP werden beim Einsatz von NAT dadurch verursacht, dass der Rechner mit der privaten Adresse A bei der Initiierung einer VoIP-Session diese private Adresse A in der SIP-Nachricht INVITE angibt. Dies verursacht die Probleme sowohl bei der Signalisierung – d.h. beim Aufbau einer VoIPSession – als auch bei der Übermittlung von audiovisuellen Medien.
430 Problem bei der Signalisierung
10 Migration zum VoIP-Einsatz
Das Problem bei der Signalisierung nach SIP beim Einsatz von NAT zeigt Abbildung 10.6-3. Hier befindet sich die NAT-Stelle beispielsweise zwischen SIP-Client und SIP-Proxy. Genau das ist bei der Internet-Telefonie der Fall, wenn der SIP-Proxy bei einem Internet Service Provider installiert ist. Das Problem mit SIP beim Aufbau einer Session und beim Einsatz von NAT wird dadurch verursacht, dass der SIP-Response auf einen SIP-Request immer an den letzten Absender des betreffenden Request gesendet wird. Dies bedeutet, dass der SIP-Response an die IP-Quelladresse gesendet wird, die in der obersten Zeile Via des empfangenen Request spezifiziert wird. Abbildung 10.6-3 illustriert dies. Hervorzuheben ist hier aber, dass die Zeile Via entweder die IP-Adresse oder den Hostnamen des Absenders des letzten Request enthalten kann (vgl. auch die Abbildungen 7.1-9 und -10). P r iv a te s N e tz S IP -C lie n t
U D P S IP -R e q
(A :b )
IP
Z -IP -A Q -IP -A Z -P o rt Q -P o rt
d r = C d r = A = 5 0 6 0 = b
Ö ffe n tlic h e s N e tz
N A T
(X :y ) S IP -R e q I N V I T E s ip :a lic e @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P 1 9 2 .1 6 8 .1 .2 ; b r a n c h = ... ...
A = 1 9 2 .1 6 8 .1 .2
U D P S IP -R e q
IP
Z -IP -A Q -IP -A Z -P o rt Q -P o rt
d r = C d r = X = 5 0 6 0 = y
v e r w o r fe n
www.wiwobooks.com Z -IP -A d r = A Q -IP -A d r = C Z -P o rt = y
IP
S IP P ro x y (C :5 0 6 0 )
S IP -R sp
U D P p riv a te IP -A d re s s e
Abb. 10.6-3: Illustration des Problems mit SIP bei der Signalisierung für VoIP Req: Request, Rsp: Response, A, X: IP-Adressen; b, y: Ports
Hat ein SIP-Client eine private IP-Adresse, wird der SIP-Response vom SIPProxy an die private IP-Adresse des SIP-Clients geschickt. In diesem Fall wird die private IP-Adresse im IP-Header des zu sendenden IP-Pakets mit dem SIPResponse eingetragen. Dieses IP-Paket wird als Folge dessen am Eingang in das öffentliche Netz – d.h. am Eingang in das Netz mit offiziellen IP-Adressen, wie Abbildung 10.6-3 zeigt – verworfen. Das hier dargestellte Problem mit SIP bei der Signalisierung wird mit Hilfe einer kleinen SIP-Erweiterung – als Symmetric Response bezeichnet (s. Abschnitt 10.6.3) – beseitigt. Problem bei der Übermittlung von Medien
Ein Problem beim Einsatz von NAT entsteht auch während einer Session bei der Übermittlung audiovisueller Medien. Abbildung 10.6-4 soll dieses Problem veranschaulichen. Hier initiiert ein SIP-Client mit der privaten IP-Adresse A eine Session durch Absenden der Nachricht INVITE an einen SIP-Proxy. Jede Nachricht INVITE enthält einen sog. Body, in dem in den c- und m-Zeilen nach dem Protokoll SDP u.a. angegeben wird, an welche IP-Adresse und an welchen UDP-Port ein Medium – im gezeigten Beispiel Audio – in RTP-Paketen übermittelt werden soll.
10.6 VoIP mit SIP in Netzwerken mit NAT
S IP In te r n e r S o c k e t C lie n t IN V IT E (A :b ) A = 1 9 2 .1 6 8 .1 .2 b = 5 2 0 0
N A T (X :y )
E x te r n e r S o c k e t
S IP P ro x y
...
IN V IT E
v e r w o r fe n
I N V I T E s ip : 1 2 3 4 5 @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P 1 9 2 .1 6 8 .1 .2 ; b r a n c h = ...
431
(C :5 0 6 0 )
IP { U D P [R T P ]}
Q u e ll- I P - A d r = 2 0 0 .3 .4 .5 Z ie l- I P - A d r = 1 9 2 .1 6 8 .1 .2
....
Q u e ll-P o rt = x x x x Z ie l-P o rt = 5 2 0 0
v = 0 S D P c = I N I P 4 1 9 2 .1 6 8 .1 .2 m = a u d io 5 2 0 0 R T P /A V P 0
U D P
R T P -P a k e t m it A u d io
Abb. 10.6-4: Illustration des Problems mit SIP bei der Übermittlung audiovisueller Medien
In Abbildung 10.6-4 signalisiert der Client dem Proxy im Body von INVITE, dass er das Audio in den IPv4-Paketen an die IP-Adresse A=192.168.1.2 und den Port b=5200 – d.h. an den Socket (A:b) – liefern soll. Diese Angaben können als Endpunkt der virtuellen Verbindung zwischen Client und Proxy angesehen werden. Die IP-Adresse A ist aber keine offizielle, sondern eine private IP-Adresse. Ein IP-Paket mit einer privaten IP-Adresse wird aber in jedem Router im Internet verworfen. Daher kann hier keine Kommunikation zwischen SIP-Client und SIP-Proxy stattfinden.
www.wiwobooks.com
Das in Abbildung 10.6-4 erläuterte Problem mit SIP beim Einsatz privater IP- Das Problem Adressen und bei der Übermittlung eines audiovisuellen Mediums lässt sich – allgemein dargestellt wie Abbildung 10.6-5 zeigt – vereinfacht zum Ausdruck bringen.
(A :b ) (A :n )
S IP C lie n t
N A T IN V IT E (
)
(X :y )
M e in M e d ia -S o c k e t is t (A :n ) (A :b ) - S ig n a lis ie ru n g s -S o c k e t
(A :n ) - M e d ia -S o c k e t
E x te r n e r S o c k e t IN V IT E v e r w o r fe n
S IP P ro x y
...
(C :5 0 6 0 )
IP { U D P [R T P ]}
IP -P a k e t a n d ie p riv a te IP -A d re s s e A
Abb. 10.6-5: Das Problem mit SIP bei der Übermittlung audiovisueller Medien
Es ist also eine spezielle Funktion nötig, um die audiovisuelle Kommunikation bei der Nutzung privater IP-Adressen zu ermöglichen. Diese wird durch die Konzepte von STUN, TURN bzw. von ICE zur Verfügung gestellt. Die NAT-Funktion kann unterwegs bei der Übermittlung von SIP-Nachrichten NAT-Stellen an mehreren Stellen vorkommen. Abbildung 10.6-6 illustriert dies anhand des im SIPTrapezoid Trapezoid-Modells von SIP – siehe Abschnitt 7.1.5.
432
10 Migration zum VoIP-Einsatz
a )
P x a b c .d e C
N A T
x y z .d e R T P -S e s s io n
b )
P x C
a b c .d e C : S IP -C lie n t P x : S IP -P ro x y
C
P x
P x N A T
x y z .d e
R T P -S e s s io n C
Abb. 10.6-6: NAT-Stelle im SIP-Trapezoid – In Domain abc.de nutzen die privaten IPAdressen: a) nur SIP-Clients; b) sowohl SIP-Clients als auch SIP-Proxy
Die beispielsweise in Abbildung 10.6-6a gezeigte Konfiguration entspricht der Situation, in der sich die SIP-Clients als sog. Soft-IP-Telefone in Rechnern mit privaten IPAdressen in privaten Haushalten befinden und der SIP-Proxy beim Internet Service Provider untergebracht ist. Wie Abbildung 10.6-6b zeigt, kann sich eine NAT-Stelle auch zwischen SIP-Proxies befinden. Ein solcher Fall ist z.B. bei der Anbindung eines Netzwerkes mit privaten IP-Adressen an das Internet möglich, wenn sowohl Clients als auch Proxy private IP-Adressen haben.
10.6.3 Symmetric Response – Hilfe bei der Signalisierung Was bringt Symmetric Response?
Wie bereits in Abbildung 10.6-3 gezeigt, wird das Problem mit SIP bei NAT beim Aufbau einer Session für VoIP dadurch verursacht, dass der SIP-Response auf INVITE an die in der Zeile Via angegebene IP-Adresse des Absenders gesendet wird. Falls diese IP-Adresse privat ist, entsteht ein Problem. Dieses lässt sich aber beheben, indem man in der gleichen Zeile Via darauf verweist, dass der SIP-Response an den externen Socket, der dem internen – d.h. dem privaten – Socket in der NAT-Instanz zugeordnet wurde, übergeben werden soll. Diese Idee hat zu einer SIP-Erweiterung geführt, die man Symmetric Response nennt. Abbildung 10.6-7 illustriert diese Idee.
Konzept von Symmetric Response
Wie hier ersichtlich ist, verweist das IP-Telefon von Bob, der eine Session initiiert – durch die Angabe rport (remote port) in der Zeile Via der ersten SIP-Nachricht INVITE (1) – auf Symmetric Response. Der SIP-Proxy fügt in INVITE (2) seine Via-Zeile und in die Via-Zeile von Bobs IP-Telefon den externen Socket (X:y) (als Angaben reveived=218.20.7.1 und rport=4999) ein, der dem internen Socket (A:b) von SIP in der NAT-Instanz zugeordnet wurde.
www.wiwobooks.com
Außer der Via-Zeile fügt der SIP-Proxy eine Zeile Record-Route hinzu (hier nicht gezeigt, siehe hierfür Abb. 7.8-2), damit der SIP-Response (3) von Bobs IP-Telefon über ihn übermittelt wird.
10.6 VoIP mit SIP in Netzwerken mit NAT
N A T B o b
(A :b )
1
A = 1 9 2 .1 6 8 .1 .2 b = 5 2 0 0
(X :y )
4
1
X = 2 1 8 .2 0 .7 .1 y = 4 9 9 9
4 1
I N V I T E s ip :a lic e @ x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P 1 9 2 .1 6 8 .1 .2 ; r p o r t; b r a n c h = z 9 h G 4 b K n 4 m d s c 5 ......... IN V IT V ia : S V ia : S b ra n c h .........
E s ip :a lic I P /2 .0 /U D I P /2 .0 /U D = z 9 h G 4
2
e @ 2 1 8 .1 8 .6 .2 S I P /2 .0 P p r o x y .a b c .d e ; b r a n c h = z 9 h G 4 b K n a s 6 d h P 1 9 2 .1 6 8 .1 .2 ; r e c e iv e d = 2 1 8 .2 0 .7 .1 ; r p o r t = 4 9 9 9 ; b K n 4 m d sc 5
(X :y )
S IP -P ro x y p r o x y .a b c .d e
R o u te r
S I P /2 .0 V ia : S I V ia : S I b ra n c h .........
2 0 0 O P /2 .0 /U P /2 .0 /U = z 9 h G
2
433
(C :5 0 6 0 )
3
A lic e 3
K D P p r o x y .a b c .d e ; b r a n c h = z 9 h G 4 b K n a s 6 d h D P 1 9 2 .1 6 8 .1 .2 ; r e c e iv e d = 2 1 8 .2 0 .7 .1 ; r p o r t = 4 9 9 9 ; 4 b K n 4 m d sc 5
(X :y )
4 S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P 1 9 2 .1 6 8 .1 .2 ; r e c e iv e d = 2 1 8 .2 0 .7 .1 ; r p o r t = 4 9 9 9 ; b ra n c h = z 9 h G 4 b K n 4 m d sc 5 ......... (X :y )
Abb. 10.6-7: Illustration der Idee von Symmetric Response – als Hilfe bei der Signalisierung
Nach dem Empfang des Response (3) entfernt der Proxy die erste Zeile Via und übermittelt den SIP-Response an den in der verbleibenden Via-Zeile angegebenen externen Socket (X:y) in der NAT-Instanz (Symmetric Response!). Da bei NAT das Binding (A:b) (X:y) besteht, wird der SIP-Response von dort an den richtigen privaten Socket (A:b) weitergeleitet. Auf diese Weise kann das Problem bei der SIP-Signalisierung über eine NAT-Stelle gelöst werden. Die Voraussetzung hierfür ist aber, dass – unterwegs – alle SIP-Komponenten die Idee von Symmetric Response unterstützen.
www.wiwobooks.com
10.6.4 Symmetric RTP/RTCP – Hilfe beim Medientransport Bei der Übermittlung eines Echtzeitmediums bei VoIP mit SIP entsteht ein Worin beProblem, weil der private Socket in der Beschreibung der Session nach dem steht das Protokoll SDP in der Nachricht INVITE angegeben wird. Dies wurde bereits in Problem? den Abbildungen 10.6-4 und -5 zum Ausdruck gebracht. Um diese Schwachstelle von SIP bei NAT zu beseitigen, sollte das angerufene IP-Telefon die Socket-Angabe im SDP-Teil von INVITE – siehe Abbildung 10.6-4 – einfach ignorieren und das entsprechende Echtzeitmedium in RTP-Paketen in Gegenrichtung an den Socket senden, von dem er auch das Medium empfängt. Diese Idee hat zu einer SIP-Erweiterung geführt, die man Symmetric RTP nennt. Abbildung 10.6-8 illustriert die Idee von Symmetric RTP. Hier sendet das IP- Idee von Telefon von Bob ein IP-Paket mit einem RTP-Paket nicht an den im SDP-Teil Symmetric von INVITE angegebenen privaten Media-Socket (A:n) (vgl. Abbildung 10.6- RTP 5), sondern an den externen Media-Socket (X:z)in der NAT-Instanz. Da bei NAT das Binding (A:n) (X:z) besteht, wird das IP-Paket mit dem RTP-Paket von dort aus an den richtigen privaten Media-Socket (A:n) im IP-Telefon von Alice weitergeleitet.
434
10 Migration zum VoIP-Einsatz
A lic e (A :n ) A = 1 9 2 .1 6 8 .1 .2 n = 5 2 0 0
B o b
N A T
{ [R T P ]U D P } IP
(X :z ) (A :n )
(X :z ) B in d in g
X = 2 1 8 .2 0 .7 .1 z = 5 9 9 9
IP { U D P [R T P ]} Z ie l-P o rt = z Z ie l-IP -A d r = X
In g o rie rt S D P -A n g a b e n in IN V IT E
Abb. 10.6-8: Illustration der Idee von Symmetric RTP bei der Übermittlung eines Mediums A, X: IP-Adressen; n, z: Ports
Idee von Symmetric RTCP
Bei audiovisueller Kommunikation wird parallel zum RTP-Medienkanal ein logischer RTCP-Kanal eingerichtet (s. Abb. 5.2-1), um den Verlauf der Kommunikation zu überwachen. Der private RTCP-Socket im IP-Telefon von Alice wird bei NAT auf einen externen RTCP-Socket abgebildet. Verwendet man bei RTCP das in Abbildung 10.6-8 gezeigte Prinzip, um das NAT-Problem bei RTCP zu überwinden, spricht man von Symmetric RTCP.
10.6.5 Einsatz von STUN Um eine audiovisuelle Kommunikation in der in Abbildung 10.6-9 gezeigten Situation zwischen einem SIP-Client, der eine private IP-Adresse besitzt, und einem SIP-Proxy mit einer offiziellen IP-Adresse zu ermöglichen, muss der SIP-Proxy die IP-Pakete mit einem audiovisuellen Medium an den externen Media-Socket (X:z)senden. Hierfür muss dem SIP-Client der externe MediaSocket mitgeteilt werden, damit er dem SIP-Proxy im SDP-Teil der SIP-Nachricht INVITE diesen Media-Socket mitteilen kann. Hierfür kann das Protokoll 1 STUN (Session Traversal Utilities for NAT) eingesetzt werden.
www.wiwobooks.com
IP-Telefon muss einen STUNServer kennen
STUN ermöglicht es, einem IP-Telefon mit einer privaten IP-Adresse den seinem internen (privaten) Socket in der NAT-Instanz im Router zugeordneten externen (offiziellen) Socket selbst zu ermitteln. Mit STUN kann ein IP-Telefon daher das Binding bei NAT kennenlernen. Hierfür muss das IP-Telefon aber zuerst die IP-Adresse eines STUN-Servers kennen. Typischerweise wird der Hostname vom STUN-Server im IP-Telefon bei seiner Konfiguration eingetragen. In der Regel können hierbei mehrere STUN-Server angegeben werden, um den Betrieb beim Ausfall eines STUN-Servers weiter zu garantieren. Ist dem SIP-Telefon der Hostname des STUN-Servers bekannt, wird mit Hilfe des DNS-Dienstes seine IP-Adresse ermittelt.
1
STUN wurde zuerst 2003 im RFC 3489 spezifiziert. Im Jahr 2008 wurde RFC 5389 bereits durch RFC 3489 abgelöst.
10.6 VoIP mit SIP in Netzwerken mit NAT P riv a te s N e tz w e rk , p riv a te IP -A d re s s e n In te r n e r S IP S IG -S o c k e t C lie n t
(A :b ) (A :n )
M e d ia In te r n e r M e d ia -S o c k e t
1
R o u te r
B in d in g -E rm ittlu n g : E x te rn e r-S o c k e t?
N A T 2
(X :z ) (A :n )
435
(X :z )
B in d in g
S T U N -S e r v e r
M e d ia E x te r n e r M e d ia -S o c k e t 1 2
S IP P ro x y
B in d in g R e q u e s t B in d in g R e s p o n s e
Abb. 10.6-9: Notwendigkeit und die grundlegende Idee von STUN A, X: IP-Adressen; b, n, z: Ports, SIG: Signalisierung
STUN ist ein Protokoll zwischen einem STUN-Client, der in einem IP-Telefon Besondermit SIP untergebracht ist, und einem STUN-Server, der bei einem ISP bzw. in heiten von einem privaten Netzwerkteil mit offiziellen IP-Adressen installiert ist. In der STUN Regel verwendet STUN für die Übermittlung seiner Nachrichten das verbindungslose Transportprotokoll UDP. Es kann aber auch das verbindungsorientierte TCP – für STUN over TCP bzw. für STUN over TLS – verwendet werden. Der Well-Known-Port von STUN hat sowohl bei UDP als auch bei TCP die Nummer 3478. STUN ermöglicht es einem SIP-Client, die Existenz einer NAT – z.B. an der Grenze zum Internet – automatisch zu entdecken und mit Hilfe eines Tests ihren Typ zu erkennen.
www.wiwobooks.com
Bevor der SIP-Client mit einer privaten IP-Adresse A die erste SIP-Nachricht Ermittlung INVITE an den SIP-Proxy sendet, ermittelt er – wie in Abbildung 10.6-9 dar- von Binding gestellt – zuerst das Binding bei NAT für die Übermittlung des Echtzeitmediums. Hierfür sendet er zuerst eine STUN-Nachricht Binding Request (1) vom Quell-Socket (A:n), der als Media-Socket verwendet werden soll, an den STUN-Server, um mit dessen Hilfe den externen Media-Socket (X:z)und damit die ihm zugewiesene offizielle IP-Adresse X zu ermitteln. Binding Request wird in einem IP-Paket mit UDP übermittelt. Beim Absenden von Binding Request im Router mit NAT wird der interne Socket (A:n) durch einen externen (X:z)ersetzt. Daraufhin wird die offizielle IP-Adresse X als Quell-Adresse im an den STUN-Server gesendeten IP-Paket eingetragen. Hat der STUN-Server Binding Request empfangen, sendet er als Antwort darauf eine Nachricht Binding Response mit der Angabe des externen Socket (X:z)im Feld MAPPED-ADDRESS. Als Folge ist der externe Socket in Binding Response zweifach vorhanden, d.h. einerseits als Adressenangabe in den IP- und UDP-Headern und andererseits als Kopie in MAPPED-ADDRESS. An der Grenze zum privaten Netzwerk wird der externe Socket in der NATInstanz durch den internen Socket ersetzt. Die Kopie des externen Socket (X:z)in MAPPED-ADDRESS wird aber durch NAT „nicht berührt“ und an das IP-Telefon – als STUN-Client – weitergeleitet.
436
10 Migration zum VoIP-Einsatz
Das IP-Telefon kennt daher sowohl seine offizielle IP-Adresse X als auch den externen Port z und kann mit der vom Signalisierungs-Socket(A:b) abgeschickten Nachricht INVITE dem SIP-Proxy mitteilen, dass das betreffende Medium von diesem an den externen Media-Socket (X:z) gesendet werden soll. Vom Router mit NAT wird das Medium dann an den internen MediaSocket (A:n) weitergeleitet. Schwachstelle von STUN = Symmetric NAT
Wie Abbildung 10.6-9 zeigt, verläuft sowohl die Kommunikation mit dem STUN-Server als auch der logische Media-Kanal über den gleichen externen Media-Socket. Das funktioniert aber nur dann, falls kein Symmetric NAT im Router eingesetzt wird, d.h., wenn mehrere Ziele über einen externen Socket erreicht werden können. Bei Symmetric NAT ist das aber nicht der Fall, und die NAT-Instanz legt für jedes Ziel einen externen Socket an (s. Abb. 10.6-2). Abbildung 10.6-10 zeigt, welche Folgen das bei STUN hat.
(A :b ) (A :n )
R o u te r
In te r n e r S IG -S o c k e t
S IP C lie n t
2
1 M e d ia
E x te r n e r S IG -S o c k e t
IN V IT E
B in d in g -E rm ittlu n g : E x te rn e r M e d ia -S o c k e t?
N A T
S T U N -S e r v e r
(X :y ) (X :z )
1
M e d ia
www.wiwobooks.com
In te r n e r M e d ia -S o c k e t A = 1 9 2 .1 6 8 .1 .2 n = 5 2 0 0
I N V I T E s ip : ...... V ia : 1 9 2 .1 6 8 .1 .2 , .... .... v = 0 c = I N I P 1 9 2 .1 m = a u d io 5 2 0 0 R a = a lt:1 1 E 8 F a = a lt:2 3 A C 1
6 8 T 0 0 0 0
(X :z )
(A :n )
.1 .2 P /A V P 0 E 8 A 2 3 6 4 E F A 4 E 8 A 7 6 3 E 4 E F C
B in d in g
E x te r n e r M e d ia -S o c k e t
S IP P ro x y X = 2 1 8 .2 0 .7 .1 z = 8 8 8 8
S D P R T C P -S o c k e t
1 9 2 .1 6 8 .1 .2 5 2 0 0 2 1 8 .2 0 .7 .1 8 8 8 8 2 1 8 .2 0 .7 .1 8 9 8 9
R T P -S o c k e t
Abb. 10.6-10: Symmetric NAT und STUN – nur vom Client ausgehende Sessions sind möglich
Wie hier ersichtlich ist, wird der externe Media-Socket (X:z) für das Protokoll RTP – im Schritt 1 – im Router bei der Abfrage des STUN-Servers angelegt. Die offizielle IP-Adresse X=218.20.7.1 und der Port z=8888 – der externe Media-Socket von RTP also – werden dem SIP-Client in der STUN-Nachricht Binding Response mitgeteilt. Nach dem gleichen Prinzip wird der externe Socket (218.20.7.1, 8989)für das Protokoll RTCP mit STUN ermittelt. Der externe Socket von RTCP wurde in Abbildung 10.6-10 allerdings nicht dargestellt. Im Schritt 2 werden die beiden Sockets – d.h. von RTP und RTCP – dem SIP-Proxy vom SIP-Client im SDP-Teil (Body der Nachricht) der SIPNachricht INVITE bekannt gemacht. Daraufhin kann die Übermittlung des Mediums beginnen. Hervorzuheben ist aber, dass hier der SIP-Client die Session mit einer privaten IP-Adresse initiiert hat.
437
10.6 VoIP mit SIP in Netzwerken mit NAT
Der Router mit Symmetric NAT leitet die IP-Pakete vom SIP-Proxy nur dann Ausgehende an einen internen SIP-Client mit einer privaten IP-Adresse weiter, wenn zuvor Sessions über den Router ein IP-Paket vom SIP-Client an den SIP-Proxy abgeschickt möglich wurde (s. Abb. 10.6-2). Dies bedeutet, dass ein SIP-Client mit einer privaten IP-Adresse immer Anrufe an Ziele außerhalb des Netzwerks mit privaten IPAdressen initiieren kann und diese ausgehenden Anrufe nicht durch die Firewall-Funktion im Symmetric NAT blockiert werden. Das Problem entsteht aber, falls der SIP-Proxy eine audiovisuelle Session an den SIP-Client mit einer privaten IP-Adresse von außen initiiert. Weil zuvor über den Router mit Symmetric NAT seitens des SIP-Clients kein IP-Paket an den SIP-Proxy abgeschickt worden ist, werden die IP-Pakete vom SIP-Proxy nicht an den internen SIP-Client mit einer privaten IP-Adresse weitergeleitet. Ankommende Anrufe zu einem SIP-Client mit einer privaten IP-Adresse sind mit STUN bei Symmetric NAT nicht möglich. Dieses Problem wird mit dem Protokoll TURN behoben.
Ankommende Sessions nicht möglich
10.6.6 Nutzung von TURN 2
Die grundlegende Idee von TURN (Traversal Using Relays around NAT) besteht darin, dass im Internet ein TURN-Server installiert wird, der sowohl für die Übermittlung der Signalisierung als auch für die Übermittlung von Echtzeitmedien als Relay-Station dient. Abbildung 10.6-11 illustriert diese Idee.
www.wiwobooks.com
R o u te r
S C i (A :b )
(X :y )
S IG , M e d ia
In te r n e r S o c k e t (S IG u n d M e d ia )
Abb. 10.6-11:
N A T
(A :b )
B in d in g
(X :y )
S T U N /T U R N -A n fra g e : E x te rn e r S o c k e t?
T U R N S e rv e r
S IG , M e d ia E x te r n e r S o c k e t (S IG u n d M e d ia ) im R o u te r m it N A T
E x te r n e r S o c k e t (S IG u n d M e d ia ) im T U R N -S e r v e r
S C m R e m o te (S IP -)C lie n ts S C n
Die grundlegende Idee von TURN – d.h. TURN-Server als VoIP-Relay-Station A, X: IP-Adressen; b, y: Ports, SC: SIP-Client, SIG: Signalisierung
An dieser Stelle ist hervorzuheben, dass die Kommunikation – d.h. Abfrage Relaydes TURN-Servers, Signalisierung und Übermittlung von Medien – zwischen Station einem SIP-Client – auch als TURN-Client bezeichnet – mit einer privaten IPAdresse und einem TURN-Server über einen einzigen externen Socket verläuft. Die Kommunikationspartner vom SIP-Client SCi – d.h. die Remote SIP-Clients 2
Für die Beschreibung von TURN siehe zurzeit (September 2009) draft-ietf-behaveturn-16. Dieser Draft wurde bereits zur Veröffentlichung als RFC abgegeben.
438
10 Migration zum VoIP-Einsatz
SCm und SCn – kommunizieren über „individuelle Sockets“ nur mit dem TURN-Server, der zwischen ihnen und dem SIP-Client SCi als VoIP-RelayStation dient. Die Strecke zwischen SCi und TURN-Server stellt eine Multiplexstrecke (s. Abb. 10.6-13) dar, auf der SIP-Nachrichten und RTP-Pakete mit Echtzeitmedien in TURN-Nachrichten Data übermittelt werden. Die Systemkonfiguration beim TURN-Einsatz ist der Konfiguration beim STUN-Einsatz ähnlich. Ein SIP-Client als TURN-Client, der sich hinter einem Router mit Symmetric NAT in einem Netzwerk mit privaten IP-Adressen befindet, kommuniziert mit einem externen TURN-Server. Dieser dient als Relay-Station und leitet die IP-Pakete sowohl mit der Signalisierung als auch mit den transportierten Medien zwischen dem SIP-Client mit einer privaten IPAdresse und seinen externen Kommunikationspartnern weiter. Besonderheiten von TURN
Der TURN-Server stellt eine Erweiterung des STUN-Servers dar. Daher besteht die Kommunikation zwischen einem SIP-Client mit einer privaten IPAdresse und dem TURN-Server zuerst darin, dass der SIP-Client eine STUNNachricht Binding Request an den TURN-Server sendet, um von ihm in Binding Response seinen externen Socket im Router seitens des Internet zu erhalten. TURN verwendet die Nachrichten von STUN. Lediglich einige Nachrichtentypen und spezielle Attribute werden von TURN spezifiziert. Für die Kommunikation zwischen einem SIP-Client als TURN-Client im Netzwerk mit privaten IP-Adressen und dem TURN-Server kann sowohl UDP als auch TCP oder TLS (Transport Layer Security) über TCP eingesetzt werden.
www.wiwobooks.com
Wie Abbildung 10.6-12 zeigt, unterscheitet man bei TURN zwei Kommunikationsabschnitte. Je3 der von ihnen wird als sog. 5-Tupel wie folgt beschrieben: 5-Tupel=(Socket S1, Socket S2, Transportprotokoll), was besagt, dass es sich um eine Kommunikation zwischen den Sockets S1 und S2 handelt und nach welchem Transportprotokoll sie verläuft.
T U R N C lie n t (A :b )
N A T (X :y )
T U R N S e rv e r
R o u te r
In te r n a l R e m o te -T A
In te r n a l L o c a l-T A
In te rn a l 5 -T u p e l
Abb. 10.6-12:
E x te r n a l L o c a l-T A
E x te r n a l R e m o te -T A
R e m o te C lie n t
E x te rn a l 5 -T u p e l
Drei Kommunikationsabschnitte beim TURN-Einsatz TA: Transportadresse – d.h. Socket
3
Der Ausdruck 5-Tupel weist darauf hin, dass 5 Komponenten zu diesem Tupel gehören, d.h., 2 IP-Adressen, 2 Ports – in den Sockets S1 und S2 – sowie ein Transportprotokoll.
10.6 VoIP mit SIP in Netzwerken mit NAT
439
Bei der Kommunikation mit dem TURN-Einsatz sind die folgenden drei Abschnitte zu unterscheiden: die Kommunikation zwischen einem TURN-Client – der auch ein SIP-Client ist – mit einer privaten IP-Adresse und einem Router mit NAT an der Grenze zum Internet; die Kommunikation zwischen einem Router mit NAT und einem TURN-Server. Dieser Abschnitt wird mit dem Internal 5-Tupel spezifiziert; die Kommunikation zwischen einem TURN-Server und einem Remote-Client als IP-Telefon. Dieser Abschnitt wird mit dem External 5-Tupel beschrieben. Es ist hervorzuheben, dass beim TURN-Server mehrere Remote-Clients einen einzigen Socket – als External Local Transport Address bezeichnet – für die Kommunikation mit dem TURN-Client nutzen können. Die Signalisierungs- und Media-Kanäle zu den einzelnen RemoteClients werden dann durch die Werte des Parameters CHANNEL-NUMBER identifiziert. Abbildung 10.6-13 illustriert dies. S e s s io n 1 T U R N C lie n t
R o u te r T U R N
(A :b ) C H A N N E L -N U M B E R
(X :y )
T U R N
R e m o te -C lie n ts
E L T A
S e s s io n 2 M e d ia -S o c k e t
www.wiwobooks.com S IG -S o c k e t
Abb. 10.6-13:
T U R N S e rv e r
N A T
S IG : S ig n a lis ie ru n g
Prinzip der Kommunikation zwischen TURN-Client und TURN-Server SIG: Signalisierung, ELTA: External Local Transport Address
Die Kommunikationsstrecke zwischen dem TURN-Client und dem TURN-Server ist eine Multiplexstrecke, auf der SIP-Nachrichten sowie RTP- und RTCP-Pakete quasi parallel in TURNNachrichten Data übermittelt werden. In Abbildung 10.6-13 wurden die RTCP-Sockets nicht dargestellt.
10.6.7 ICE als Lösung des NAT-Problems ICE (Interactive Connectivity Establishment) ist ein Protokoll, nach dem zwi- Bedeutung schen zwei beliebigen Rechnern über IP-Netze eine Verbindung für die Echt- von ICE 4 zeitkommunikation beim Einsatz von SIP aufgebaut werden kann. Diese Rechner – bzw. nur einer von ihnen – können private IP-Adressen verwenden und hinter einer NAT-Komponente mit Firewall installiert werden. ICE ist auch ein Rahmenwerk für die Integration von SIP, NAT, STUN und TURN. ICE kann die beiden Transportprotokolle UDP und TCP nutzen. Bei ICE geht man davon aus, dass ein SIP-Client von einem anderen SIPClient über mehrere Sockets – bei ICE als Transportadressen bezeichnet – er4
Zurzeit (September 2009) wird ICE in draft-ietf-mmusic-ice-19 spezifiziert. Dieser Draft wurde aber bereits zur Veröffentlichung als RFC abgegeben.
440
10 Migration zum VoIP-Einsatz
reicht werden kann. Man kann diese Transportadressen als kandidierende Adressen eines SIP-Clients ansehen; bei ICE tragen sie die Kurzbezeichnung Candidates. Abbildung 10.6-14 veranschaulicht dies. Host Candidate
Enthält ein SIP-Client eine offizielle IP-Adresse, kann sein Kommunikationspartner die IP-Pakete direkt an ihn übermitteln, genauer gesagt, an seine offizielle IP-Adresse A und den Port b – also an die lokale Transportadresse (A:b). Eine derartige Transportadresse nennt man bei ICE Host Candidate. S C i (A :b ) H o s t C a n d id a te (A :b )
Abb. 10.6-14:
N A T
R o u te r
S T U N S e rv e r
T U R N S e rv e r (Z :c )
S C n
(X :y ) S e rv e r R e fle x iv e C a n d id a te (X :y )
R e la y e d C a n d id a te (Z :c )
Mögliche Transportadressen eines SIP-Clients mit einer privaten IP-Adresse SC: SIP-Client, SIG: Signalisierung
Server Reflexive Candidate
Enthält ein SIP-Client aber eine private IP-Adresse und wird im Router zum Internet kein Symmetric NAT realisiert, kann ihm sein Kommunikationspartner die Daten in IP-Paketen nur über eine Transportadresse auf dem Router übermitteln, beispielsweise über die offizielle IP-Adresse X und den Port y – also über die server-reflexive Transportadresse (X:y). Eine solche Transportadresse bezeichnet man bei ICE als Server Reflexive Candidate.
Transportadresse Relayed Candidate
Falls der Rechner eine private IP-Adresse enthält und der Router an der Grenze zum Internet Symmetric NAT realisiert, kann ihm sein Kommunikationspartner die Daten in IP-Paketen nur über eine Transportadresse auf dem TURN-Server übermitteln, der als Relay-Station dient. Beispielsweise ist der SIP-Client in Abbildung 10.6-14 über die IP-Adresse Z und den Port c auf dem TURNServer erreichbar – d.h. über die Relay-Transportadresse (Z:c). Bei ICE wird eine solche Transportadresse Relayed Candidate genannt.
Idee von ICE
Die Idee von ICE ist relativ einfach. Vor dem Initiieren der ersten Kommunikationsbeziehung erfasst jeder SIP-Client alle Transportadressen, über die er erreichbar ist, d.h., die bei ihm als Candidates fungieren können. Man bezeichnet diese Phase als Gathering.
www.wiwobooks.com
Nach der Erfassung der Candidates werden ihnen Präferenzen zugeordnet, das heißt, sie werden nach festgelegten Prinzipien priorisiert. Danach werden die Candidates mit Hilfe des Protokolls SDP in Form einiger Zeilen für die Übermittlung an das Ziel beschrieben – also codiert. Beim Initiieren einer Verbindung werden die Candidates dem Ziel-SIP-Client im Body-Teil der SIPNachricht INVITE übermittelt (s. Abb. 10.6-16). Der Ziel-SIP-Client überprüft unter Berücksichtigung eigener Candidates, welche Transportadresse – von den
10.6 VoIP mit SIP in Netzwerken mit NAT
441
ihm zugeschickten Candidates – die günstigste bzw. effektivste für ihn ist. Daraufhin verläuft die Kommunikation zwischen den beiden kommunizierenden Rechnern über den günstigsten Candidate. Im Verlauf von ICE sind folgende Schritte zu unterscheiden – siehe Abbildung 10.6-15:
ICE-Verlauf
1.
Der SIP-Client SCi erfasst und priorisiert seine Candidates – Um seinen Server Reflexive Candidate zu ermitteln, sendet SCi, der eine Session zum SCn aufbauen möchte, eine Nachricht Binding Request an den TURN-Server, der auch als STUN-Server dient. Die Transportadresse – als Server Reflexive Candidate – erhält er von ihm in der Nachricht Binding Response. Durch das Absenden einer Nachricht Allocate Request an den TURN-Server erhält der Client SCi in der Antwort Allocate Success Response von ihm eine Transportadresse (z.B. Z:c ), die als Relayed Candidate gilt.
2.
Offer: SCi bietet seine Candidates an – Hat SCi seine Candidates – nach SDP – beschrieben und eine Nachricht INVITE erstellt, übermittelt er sie dem Kommunikationspartner – hier dem SIP-Client SCn – im Body-Teil von INVITE (siehe Abbildung 10.6-16).
3.
SCn erfasst und priorisiert seine Candidates – Im Allgemeinen kann sich der angerufene SCn hinter NAT befinden, sodass er überprüfen muss, welche Transportadressen er als Candidates aktuell nutzen kann. Daher entspricht dieser Schritt vollkommen dem Schritt 1.
4.
Answer: SCn übermittelt eigene Candidates – Als Answer (Antwort auf Offer) auf das Angebot des SCi übermittelt der angerufene SCn dem „Anrufer“ SCi seine Candidates. Answer kann in einer SIP-Bestätigung PRACK (RFC 3262) bzw. als eine SIP-Antwort vom Typ 18x (z.B. 180 Ringing bzw. 183 Session Progress) erfolgen.
5.
Überprüfen der Konnektivität und Auswahl von Candidates – Haben die beiden SIPClients ihre Candidates ausgetauscht, so können sie überprüfen, über welche die Kommunikation zwischen ihnen am effektivsten ist. Dies führt zur Überprüfung der Konnektivität.
6.
Fortsetzung des Aufbaus einer Session – Besteht Konnektivität zwischen den beiden SIPClients, so wird der Verlauf der Signalisierung nach SIP fortgesetzt, um eine Session für VoIP aufzubauen.
www.wiwobooks.com
T U R N /S T U N -S e rv e r
R o u te r N A T
S IP C lie n t S C i 1
T /S -S rv
T /S -S rv
A b fra g e v o n C a n d id a te s
2 : O ffe r
IN V IT E
S IP C lie n t
R o u te r N A T
S C n
A b fra g e v o n C a n d id a te s
1 8 x
3
4 : A n sw e r
Ü b e r p r ü fe n d e r K o n n e k tiv itä t 5 6
Abb. 10.6-15:
r e -IN V IT E F o r ts e tz u n g d e r S ig n a lis ie r u n g n a c h S IP
Verlauf von ICE bei Aufbau einer Session für VoIP nach SIP
Hat ein Rechner seine Candidates erfasst und priorisiert, kann er mit der Initiierung eines Anrufs nach SIP beginnen. Hierfür muss er aber – wie Abbildung 10.6-16 zeigt – im Body der SIPNachricht INVITE eine Beschreibung seiner Candidates eintragen. Wie hier ersichtlich ist, wurde für die Unterstützung von ICE das Protokoll SDP (s. Abschnitt 7.4) so erweitert, dass mehrere
Beschreibung von Candidates
442
10 Migration zum VoIP-Einsatz neue SDP-Attribute hinzugefügt wurden. Am wichtigsten ist das Attribut candidate. Für jeden Candidate wird im Body von INVITE eine candidate-Zeile eingetragen. Diese enthält: die IPAdresse und den Port des entsprechenden Candidate sowie seine Priorität und seine Art (Host, Server Reflexiv oder Relayed). Bei jedem Candidate wird auch angegeben, welches Transportprotokoll (UDP, TCP) zum Einsatz kommen soll. b )
a )
R o u te r
N e tz w e r k
(Z :c )
(A :b )
T U R N S e rv e r
N A T
H o s t C a n d i d a t e : (R A : b ) S e r v e r R SS Te e r Uf v l e eN r x - i v e C a n d N i e d R e la y e d C a n d id a te : (Z :c
Abb. 10.6-16:
Überprüfen der Konnektivität
In te r n e t
(X :y )
v = 0 o = .....................I N s = ... t= 0 0 ... m = a u d io y R T P /A a = rtp m a p : 0 P C M a = c a n d id a te : 1 1 a = c a n d id a te : 2 1 a = c a n d id a te : 3 1
IP 4
V P U /8 U D U D U D
B o d y n a c h S D P in I N V I T E A
0
0 0 P P P
0
P rio 1 P rio 2 P rio 3
IP -A d re sse P o rt R e la te d A d o b ty p h o s t y ty p s rflx ra d d A c ty p re la y ra d d X A X Z
d re sse s p tio n a l rp o rt b rp o rt y
T ra n s p o rta d re s s e P rio ritä t T ra n sp o rt C o m p o n e n t-ID F o u n d a tio n
t a z t w e :e r ( k X : y ) B
)
Beispiel für die Beschreibung von Candidates
Nachdem sich die beiden SIP-Clients gegenseitig ihre Candidates mitgeteilt haben, beginnen sie mit der Überprüfung der Konnektivität, d.h., sie prüfen, ob eine Kommunikation zwischen ihnen möglich ist. Ist dies der Fall, wird das beste Candidates-Paar, über die die Kommunikation verlaufen soll, ausgewählt. Die Überprüfung der Konnektivität stellt Abbildung 10.6-17 dar.
www.wiwobooks.com S IP -C lie n t S C i a
a = H o s t C a n d id a te b = S e rv e r R e fle x iv e C a n d id a te d = R e la y e d C a n d id a te
Abb. 10.6-17:
N A T
C a n d id a te = S o c k e t
b d T U R N S e rv e r
In te rn e t
l m T U R N S e rv e r
S IP -C lie n t
N A T k
S C n
k = H o s t C a n d id a te l = S e rv e r R e fle x iv e C a n d id a te m = R e la y e d C a n d id a te
Ausgangslage beim Überprüfen der Konnektivität
Hier wurde angenommen, dass sich die SIP-Clients SCi und SCn hinter Symmetric NAT befinden. SCi ist über folgende drei Transportadressen erreichbar: Host Candidate α, Server Reflexive Candidate β und Relayed Candidate δ. Die einzelnen Candidates des SCn sind hier: Host Candidate κ, Server Reflexive Candidate λ und Relayed Candidate μ.
Auswahl von Candidates
Jeder SIP-Client muss also überprüfen, über welche Candidates er am günstigsten zu erreichen wäre. Daher bildet jeder SIP-Client sinnvolle Paare von Candidates, d.h. jedem eigenen Candidate – als LOCAL CANDIDATE bezeichnet – ordnet er jeweils einen Candidate seines Kommunikationspartners – REMOTE CANDIDATE genannt – zu. Jeder SIP-Client bildet somit alle sinnvollen Candidates-Paare (LOCAL CANDIDATE, REMOTE CANDIDATE) und überprüft für jedes Paar daraufhin, ob Konnektivität besteht. Das Ergebnis ist eine Liste von Candidates-Paaren. Jeder SIPClient berechnet dann die Priorität – sog. Pair Priority – für jedes Candidates-Paar. Diese Priorität wird nach einer Formel berechnet, in der die Prioritäten beider Candidates – LOCAL CANDIDATE und REMOTE CANDIDATE – entsprechend berücksichtigt sind. Auf diese Weise kann
10.7 Schlussbemerkungen
443
das günstigste Candidates-Paar ausgewählt werden; falls mehrere in Frage kommen, wird in der Regel das Paar mit der höchsten Priorität ausgewählt. Nach der Durchführung der Tests und der Auswahl der besten Candidates-Paare ergeben sich die zwei in Abbildung 10.6-18 dargestellten Möglichkeiten der Kommunikation zwischen diesen SIP-Clients. Es handelt sich hier um eine „symmetrische Konstellation“. Das bedeutet: die Kommunikation zwischen SCi und SCn kann über einen ihrer TURN-Server bzw. parallel über die beiden TURN-Server verlaufen. Wie hier ersichtlich ist, besteht die bidirektionale Erreichbarkeit zwischen SCi und SCn.
N A T
S IP -C lie n t
S C i
a b
d
a ó b ó d ó l ó k B in d in g
Abb. 10.6-18:
N A T l
C a n d id a te = S o c k e t
T U R N S e rv e r
k
S IP -C lie n t
m In te rn e t
T U R N S e rv e r
Zwei Möglichkeiten der Kommunikation
S C n
a ó b ó m ó l ó k B in d in g
Konnektivität zwischen SIP-Clients SCi und SCn α, β, δ: Candidates von Sci; κ, λ, μ: Candidates von SCn
Abschließend sei noch hervorgehoben, dass die hier dargestellten Lösungen für die Nutzung privater IP-Adressen bei VoIP mit SIP theoretisch zwar die Beseitigung der gezeigten Probleme ermöglichen, zurzeit aber noch nicht von allen Systemen unterstützt werden. Die universelle Lösung des NAT-Problems bei SIP stellt ICE dar. Es handelt sich hier um ein völlig neues Konzept.
www.wiwobooks.com
10.7 Schlussbemerkungen Die Migration zu VoIP in einem Unternehmen führt zur Konvergenz seiner Sprach- und Datennetze und stellt in der Regel ein komplexes Projekt dar, bei dem unterschiedliche organisatorische und technische Aspekte berücksichtigt werden müssen – siehe beispielsweise [Web 01]. Ziel des Kapitels war es, diese Aspekte und die hierfür notwendigen technischen Grundlagen – z.B. für den Einsatz von VoIP mit SIP bei der Verwendung privater IP-Adressen – fundiert darzustellen. Aus Platzgründen konnten die VoIP-Systemlösungen leider nicht detaillierter erläutert werden. Abschließend seien noch folgende Aspekte hervorgehoben: VoIP als Technik stellt die Basis für konvergente Sprach- und Datennetze Große der Zukunft dar. Auf dem Markt findet man bereits ein reichhaltiges Ange- Akzeptanz bot an Produkten für die Migration zu diesen Netzen. Es sind sämtliche von Asterisk Hardware- und Software-Komponenten vorhanden, um VoIP in Unternehmen und anderen Institutionen einführen zu können. Auch gibt es frei verfügbare VoIP-Software. Hervorzuheben ist hier die freiverfügbare Software
444
10 Migration zum VoIP-Einsatz
Asterisk unter Linux, die bereits in der Praxis eine breite Akzeptanz gefunden hat – siehe z.B. http://www.asterisk.org VoIPHosting, IP-Centrex
Bei keinem Netzwerkprojekt sollte heute VoIP außer Acht gelassen werden. Jedes Unternehmen, dessen Telefonanlage aus Altersgründen abzulösen ist, sollte unbedingt die Migration zu VoIP planen. Neben den in diesem Kapitel dargestellten Möglichkeiten – wie harte bzw. sanfte Migration zu VoIP – ist es auch denkbar, die zentralen VoIP-Komponenten (wie z.B. IP-TKAnlagen) zu spezialisierten VoIP-Providers auszulagern. Man bezeichnet dies als VoIP-Hosting. Dabei handelt es sich um ein Outsourcing-Modell, eine Neubelebung des alten Centrex-Konzepts. Bei Centrex wird die Funktion einer TK-Anlage im Telefonnetz beim Provider untergebracht, sodass man auch von einer virtuellen TK-Anlage spricht. Nachdem Centrex in klassischen Festnetzen nicht den gewünschten Erfolg hatte, ist IP-Centrex als Hosted IP-TK-Anlage bei einem VoIP-Provider viel interessanter.
Wann IPCentrex?
IP-Centrex ist für Unternehmen attraktiv, die über eine Vielzahl von Filialen verfügen. Alle Filialen, die weltweit verteilt sein können, können an eine Hosted IP-TK-Anlage über IP-Netze angebunden werden und sind über eine einzige Vorwahl weltweit erreichbar. Hier liegt der Vorteil von IP-Centrex. Dem steht aber auch ein Nachteil gegenüber. Bei einer eigenen IP-TKAnlage im Unternehmen kann man noch sagen, wo die sicherheitsrelevanten Daten liegen und wer darauf Zugriff hat – wenn diese Daten aber bei einem VoIP-Provider liegen, hat man diese Sicherheit nicht mehr. Daher würde kein Geldinstitut IP-Centrex ernsthaft in Betracht ziehen.
www.wiwobooks.com
IP-Centrex eignet sich deshalb nur für Unternehmen, die bereits NetzwerkOutsourcing praktizieren. Hierzu kommen kleine und mittelständische Unternehmen der Produktionsbranche, die sich vor allem um ihre Produktion „kümmern“ müssen und deren Daten nicht so vertraulich sind, dass sie bei einem VoIP-Provider nicht abgespeichert werden dürfen. Für große Unternehmen, die ohnehin über eine eigene Netzwerkabteilung verfügen, und für Unternehmen aller Größen mit sicherheitsrelevanten Daten kommt nur eine eigene IP-TK-Anlage in Frage. VoIP in Triple-PlayServices
Die Liste der VoIP-Anbieter wird immer länger, und die Angebote wirken sehr verlockend. Zu ihren Kunden zählen vor allem Heimanwender, Heimbüros, kleine Büros und private Haushalte. Sie betreiben in der Regel ein Netzwerk mit privaten IP-Adressen, sodass hier die in Abschnitt 10.6 dargestellten Lösungen für VoIP mit SIP in Netzwerken mit NAT von großer Bedeutung sind. Das Angebot an VoIP-Komponenten ist sehr breit, und privaten Haushalten werden heute über Fernsehkabelanschlüsse Triple-PlayServices zur Verfügung gestellt – als Fernsehen, Video-on-Demand sowie schneller Internet-Anschluss mit VoIP. Der Zug in Richtung VoIP ist also nicht mehr zu stoppen.
11 VoIP-Sicherheit Netzwerke werden immer komplexer, ebenso die auf sie einwirkenden Fakto- Begriff: ren und die Anforderungen, die man an sie stellt. Zudem ist ständig mit unter- VoIPschiedlichen, böswilligen Angriffen auf Rechnersysteme und anderen Gefähr- Sicherheit dungen in Netzwerken zu rechnen. Zur Vermeidung von Unsicherheiten mit hohen Risiken in Netzwerken mit VoIP sind daher besondere Maßnahmen bzw. Lösungen erforderlich, die man unter dem Begriff VoIP-Sicherheit zusammenfasst. Darunter werden alle Maßnahmen zur Planung, Realisierung und Überwachung der Sicherheit beim VoIP-Einsatz verstanden. Bei einer Migration zu VoIP müssen alle Sicherheitsaspekte, die sowohl die Planung Daten- als auch die Sprachkommunikation betreffen, bereits bei der Planung der VoIPvon Maßnahmen für die Sicherheitsgarantie des Netzwerkbetriebs berück- Sicherheit sichtigt werden. Man spricht daher von Sicherheitsplanung. Die Planung der VoIP-Sicherheit ist Bestandteil der Planung der Netzwerksicherheit und kann auf mehrere Phasen aufgeteilt werden. Um die Planung der VoIP-Sicherheit anschaulich darzustellen, wurde hier ein Schweizer-Käse-Modell eingeführt.
www.wiwobooks.com
Dieses Kapitel gibt einen Überblick über mögliche Gefährdungen bei VoIP und Überblick präsentiert die Vorgehensweise bei der Planung der VoIP-Sicherheit. Nach ei- über das ner Einführung in die Problematik der VoIP-Sicherheit in Abschnitt 11.1 geht Kapitel Abschnitt 11.2 darauf ein, mit welchen Bedrohungstypen und Angriffsarten bei VoIP zu rechnen ist. Abschnitt 11.3 widmet sich der Sicherheit bei VoIP mit SIP. In Abschnitt 11.4 wird die Ermittlung des Schutzbedarfs präsentiert. Auf die Spezifikation von Sicherheitsanforderungen und Sicherheitsmaßnahmen gehen wir in den Abschnitten 11.5 und 11.6 ein. Abschließende Bemerkungen in Abschnitt 11.6 runden dieses Kapitel ab. Das Kapitel geht u.a. auf folgende Fragestellungen ein: Welche Ziele sollte man bei der Planung von VoIP-Sicherheit verfolgen? Wie geht man bei der Planung von VoIP-Sicherheit vor? Mit welchen Bedrohungstypen und Angriffsarten ist bei VoIP zu rechnen? Mit welchen Gefährdungen ist bei VoIP mit SIP zu rechnen, und welche Sicherheitsmechanismen lassen sich dagegen einsetzen? Wie spezifiziert man eine Sicherheitsschwachstelle im Netzwerk? Wie lässt sich der Schutzbedarf bei VoIP ermitteln und präzise erfassen? Wie erstellt man einen Katalog von Sicherheitsanforderungen? Wie spezifiziert man die Maßnahmen für die VoIP-Sicherheit?
Ziel dieses Kapitels
446
11 VoIP-Sicherheit
11.1 Probleme der VoIP-Sicherheit Bösartige Angriffe auf Netzwerke und Rechnersysteme nehmen ständig zu, sodass die VoIP-Sicherheit zunehmend an Bedeutung gewinnt. Da es sich hierbei um komplexe Vorgänge und Sachverhalte handelt, ist eine sorgfältige Planung, Realisierung und Überwachung der VoIP-Sicherheit nötig. Sicherheitsziele
Vor der Planung eines Konzepts zur Garantie der Sicherheit beim Einsatz von VoIP in einem Netzwerk ist die Definition von Zielen erforderlich. Hierbei legt man fest, was mit einem solchen Konzept erreicht werden soll. Man spricht in diesem Zusammenhang auch von VoIP-Sicherheitszielen. Letztere werden in Abschnitt 11.1.1 detaillierter erläutert.
Sicherheitsaspekte
Um VoIP-Sicherheit auf einem hohen Niveau zu garantieren, müssen sowohl bestimmte technische Sicherheitskomponenten (wie z.B. Firewalls) eingesetzt als auch diverse Maßnahmen ergriffen werden. Diese Maßnahmen sind keinesfalls nur technischer Natur, sondern müssen darüber hinaus organisatorische, geschäftliche und rechtliche Fragestellungen berücksichtigen. Daher ist zwischen verschiedenen Aspekten der VoIP-Sicherheit zu unterscheiden. Darauf geht Abschnitt 11.1.2 näher ein.
Netzwerkbereiche
Das Netzwerk in einem Unternehmen ist in der Regel ein komplexes Gebilde, das man in mehrere funktionelle und organisatorische Bereiche unterteilen kann. Da die Sicherheitsrisiken beim VoIP-Einsatz in den einzelnen Netzwerkbereichen unterschiedlich sind, sollte man diese Bereiche bei der Entwicklung eines Konzepts für die VoIP-Sicherheit getrennt analysieren. In Abschnitt 11.1.3 wird gezeigt, um welche Bereiche es sich handelt.
VoIPSicherheitsprozess
Um VoIP-Sicherheit zu gewährleisten, müssen das entwickelte Sicherheitskonzept umgesetzt und die eingeführten Sicherheitsmaßnahmen ständig überwacht werden. Dies führt zu einem kontinuierlichen Prozess, den man auch als VoIPSicherheitsprozess bezeichnet und der in Abschnitt 11.1.4 detailliert dargestellt wird.
www.wiwobooks.com
Die Planung der VoIP-Sicherheit stellt einen komplexen Prozess dar, in dem mehrere Schritte zu unterscheiden sind. Diese Schritte werden in Abschnitt 11.1.5 mit Hilfe des Schweizer-Käse-Modells näher erläutert.
11.1.1 Primäre Ziele der VoIP-Sicherheit Bevor man mit der Erstellung von Maßnahmen zur VoIP-Sicherheit beginnt, sollte man die entsprechenden Ziele spezifizieren – die sog. VoIP-Sicherheitsziele. Abbildung 11.1-1 stellt eine Zusammenstellung primärer Ziele dar, die man bei der Erstellung eines Konzepts für die Erhöhung der VoIP-Sicherheit verfolgen sollte.
11.1 Probleme der VoIP-Sicherheit
447
M ö g lic h e A n g riffe : V e rtra u lic h k e it
P rim ä re Z ie le d e r V o IP -S ic h e rh e it
A b h ö re n v o n T e le fo n a te n A u fz e ic h n e n v o n G e s p rä c h e n A b h ö re n fre m d e r V o ic e m a ils ...
In te g ritä t
V e rä n d e ru n g d e r S ig n a lis ie ru n g s in fo rm a tio n M a n ip u la tio n v o n G e s p rä c h e n V e rä n d e ru n g d e s A n ru fs ta tu s ...
A u th e n tiz itä t
V o rtä u s c h e n d e r Id e n titä t d e s A n ru fe rs V o rtä u s c h e n d e r A u th e n tiz itä t v o n S p ra c h d a te n ...
V e rfü g b a rk e it
D e n ia l o f S e rv ic e (D o S ) S p a m o v e r IP T e le p h o n y (S P IT ) A b b ru c h v o n V e rb in d u n g e n (C a ll In te rrru p tio n ) ...
Abb. 11.1-1: Primäre Ziele der VoIP-Sicherheit Zu den primären Zielen der VoIP-Sicherheit gehören: Vertraulichkeit (Confidentiality): Darunter wird der Schutz vor unbefugter Preisgabe der Information verstanden. Die Vertraulichkeit bei VoIP kann durch verschiedene Angriffe verletzt werden, wie z.B. durch das Abhören von Telefonaten durch unbefugte Personen sowie das Abhören fremder Voicemails. Daher sollte sichergestellt sein, dass die entsprechenden Telefonate vertraulich bleiben und nur befugte Personen auf vertrauliche Sprachdaten, z.B. auf Nachrichten eines Voicemail-Servers, zugreifen dürfen. Um die Vertraulichkeit zu garantieren, kommen folgende Maßnahmen in Betracht: − Um Vertraulichkeit bei der Sprachübertragung zu erreichen – also Übertragungssicherheit –, können die zu übertragenden Inhalte der IP-Pakete mit Sprache entsprechend vor dem Absenden verschlüsselt und nach dem Empfangen am Ziel wieder entschlüsselt werden. Dies ist mit Hilfe des Protokolls SRTP möglich (s. Abschnitt 5.7). − Um den Zugriff auf vertrauliche Sprachdaten, z.B. auf einem Voicemail-Server, nur den hierfür berechtigten Personen zu gewähren – also Zugriffssicherheit zu garantieren –, können verschiedene Authentifizierungsverfahren verwendet werden.
Vertraulichkeit
Integrität (Integrity): Darunter versteht man den Schutz vor unbefugter Manipulation (Veränderung) der Information. Da es sich sowohl um die Manipulation von Signalisierungsdaten als auch um die Manipulation der Konfigurationsparameter von VoIP-Systemkomponenten handeln kann, sollte unterschieden werden zwischen: − Integrität von Signalisierungsdaten Es sollte sichergestellt sein, dass die Angaben während des Auf- und Abbaus einer Telefonverbindung nach einem Signalisierungsprotokoll – also die Signalisierungsdaten – unmanipulierbar, d.h. immer korrekt sind und jede unberechtigte Änderung verhindert oder zumindest festgestellt werden kann. Um die Garantie der Integrität von Signalisierungsdaten zu erreichen, müssen die Inhalte der zu übertragenden IP-Pakete mit den Signalisierungsdaten entsprechend verschlüsselt werden. − Integrität von VoIP-Systemkomponenten Es sollte sichergestellt sein, dass die Konfigurationsdaten und -parameter unmanipulierbar sind und jede böswillige Änderung verhindert werden kann. Um die Integrität von VoIP-Systemkomponenten zu erreichen, sollten verschiedene Authentifizierungs- und Autorisierungsverfahren verwendet werden. Bei der Authentifizierung handelt es sich um die Überprüfung der tatsächlichen Identität des Benutzers (Überprüfung: Wer sind
Integrität
www.wiwobooks.com
448
11 VoIP-Sicherheit Sie?). Die Autorisierung findet nach der Authentifizierung des Benutzers statt und entscheidet über die Berechtigungen des Benutzers, auf bestimmte Daten zuzugreifen (Überprüfung: Was wollen Sie?).
Authentizität
Als Authentizität (Authenticity) wird der Beweis der Echtheit verstanden. Es sollte immer sichergestellt sein, dass die Herkunft von Daten bzw. einer Nachricht (z.B. Voicemail) eindeutig festgestellt werden kann. Daher sollte man bei VoIP unterscheiden zwischen: − Authentizität der Signalisierungsdaten: Diese besagt, dass die Signalisierungsdaten tatsächlich von dem wahren Absender stammen. − Authentizität des Anrufenden: Diese besagt, dass der Anrufende tatsächlich derjenige ist, der zu sein er vorgibt. Beide Arten der Authentizität können mit Hilfe digitaler Signaturen und Zertifikate überprüft werden.
Verfügbarkeit
Es sollte einerseits sichergestellt sein, dass auf die notwendigen Daten (z.B. Verbindungsdaten, Sprachdaten als Voicemails) zur richtigen Zeit und am richtigen Ort zugegriffen werden kann. Hierbei kann man von Datenverfügbarkeit (Data Availability) sprechen. Es sollte andererseits sichergestellt sein, dass die wichtigen VoIP-Systemkomponenten, wie z.B. VoIP-Server und -Gateway, durch gezielte Angriffe, wie beispielsweise DoS-Angriffe, nicht lahmgelegt werden können. Daher handelt es sich hier um die Garantie der Systemverfügbarkeit (System Availability). Von den hier genannten primären Sicherheitszielen lassen sich durch Verfeinerung die sekundären Sicherheitsziele ableiten.
www.wiwobooks.com
Die konkreten Sicherheitsmaßnahmen zur Umsetzung der Sicherheitsziele beim VoIP-Einsatz unterscheiden sich natürlich in jedem Unternehmen bzw. in jeder Institution mehr oder weniger. Zu den Sicherheitsmaßnahmen gehören technische (wie z.B. Firewall, Passwortschutz) und organisatorische (wie z.B. Unterrichtung und Sensibilisierung von Mitarbeitern).
11.1.2 Verschiedene Aspekte der VoIP-Sicherheit Wie bereits erwähnt, sind die Maßnahmen zur Garantie der VoIP-Sicherheit keinesfalls nur technischer Natur, sondern müssen auch andere sicherheitsrelevante Fragestellungen, wie z.B. organisatorische oder rechtliche Aspekte, berücksichtigen. Bei der Planung und Realisierung eines Konzepts für die VoIP-Sicherheit sollte das gesamte Netzwerk unter den unterschiedlichen Sicherheitsaspekten analysiert werden. Abbildung 11.1-2 zeigt eine Auflistung typischer Aspekte der VoIP-Sicherheit. Typische Aspekte der VoIP-Sicherheit: Technische Aspekte: Hierbei handelt es sich um sämtliche Sicherheitsaspekte, die mit den technischen Fragestellungen zusammenhängen, wie z.B.: − Wie wird die VoIP-Sicherheit am Internetzugang technisch realisiert? − Wie konfiguriert man die VoIP-Systemkomponenten (wie z.B. VoIP-Gateway), um sie vor diversen Angriffen zu schützen? − Welche Mechanismen kommen beim Zugriffsschutz auf VoIP-Server zum Einsatz? Organisatorische Aspekte: Hierzu gehören alle Fragestellungen, die mit der Organisation der VoIP-Sicherheit verbunden sind, wie z.B.: − Wie wird das Passwort-Management organisiert? − Wie organisiert und verwaltet man die Benutzerrechte?
11.1 Probleme der VoIP-Sicherheit
S ic S ic K o A u
T e c h n is c h e A s p e k te M A s p e k te d e r V o IP S ic h e rh e it
O rg a n is a to ris c h e A s p e k te
P B S
h e rh e it a m In te rn e t-Z u g a n g , F ire w a lls h e r h e its m e c h a n is m e n : Z u g r if f s s c h u tz , M o n ito r in g , ... n fig u ra tio n v o n V o IP -S y s te m k o m p o n e n te n d itin g : R e p o r tin g , E v e n t- L o g g in g , ... o n ito r in g : C h a n g e - , I n tr u s io n - D e te c tio n , ... a s s w o rt-M a n a g e m e n t e n u tz e r- u n d B e re c h tig u n g s v e rw a ltu n g ic h e r h e its - A u d it, - M o n ito r in g , ....
M e n s c h lic h e A s p e k te
K rim in e lle H a n d lu n g e n : M a n ip u la tio n d e r K o n fig u ra tio n H a n d h a b u n g s f e h le r , ....
G e s c h ä ftlic h e A s p e k te
O ffe n P ro d u H a ftu G e b ü B e w e
R e c h tlic h e A s p e k te
449
le g u k tiv n g , h re n is p r
n g itä z .B b e o b
v o n U ts v e rlu . fü r V tru g b e le m a tik
n te rn e h m e n s - b z w . K u n d e n d a te n s te , ... o ic e m a il-In h a lte i V o IP , ...
Abb. 11.1-2: Typische Aspekte der VoIP-Sicherheit Menschliche Aspekte: Ein Mitarbeiter kann einerseits unabsichtlich einen Handhabungsfehler begehen, der zu einer Sicherheitsschwachstelle führt. Andererseits kann er als Innentäter auch absichtlich versuchen, z.B. auf den VoIP-Server mit den für ihn nicht autorisierten Daten zuzugreifen. Derartige Handlungen dürfen beim Konzept für die VoIP-Sicherheit nicht außer Acht gelassen werden. Als menschliche Aspekte der VoIP-Sicherheit solle man u.a. folgende Fragen in Betracht ziehen: − Welche Handhabungsfehler könnten zu gewissen Sicherheitsschwachstellen führen? − Mit welchen kriminellen Handlungen muss gerechnet werden (z.B. Manipulation von Konfigurationsparametern)?
www.wiwobooks.com
Geschäftliche Aspekte: Die Unsicherheiten im Netzwerk mit VoIP können sich auch negativ auf die Unternehmensgeschäfte auswirken. Um diese Aspekte der VoIP-Sicherheit zu berücksichtigen, sollte man u.a. auf folgende Fragestellungen eingehen: − Wie sollen die Voicemails und Verbindungsdaten im Unternehmen geheim gehalten werden, um eine Offenlegung der Unternehmensgeschäfte nicht zuzulassen? − Wie sichert man die sicherheitsrelevanten VoIP-Gespräche, um sie für die „Konkurrenz“ unzugänglich zu machen? − Welche Vertraulichkeitsverluste können zu Produktionsverlusten führen, und welche Maßnahmen sollten ergriffen werden, um solche Verluste ausschließen zu können? Rechtliche Aspekte: Hierbei handelt es sich z.B. um folgende Fragen: − Wie kann die VoIP-Telefonie von Mitarbeitern privat genutzt werden? − Wer haftet im Unternehmen für die Inhalte von Voicemails, die aus dem Unternehmen verschickt werden? − Wie organisiert man die Beweisproblematik bei strittigen Sicherheitsproblemen?
11.1.3 Sicherheitsproblembereiche im Netzwerk Bei der Entwicklung eines Konzepts für die VoIP-Sicherheit müssen alle Bereiche im Netzwerk analysiert werden, in denen bestimmte Sicherheitsprobleme, die man auch als Sicherheitslücken oder Sicherheitsschwachstellen bezeichnet, entstehen können. Diese Sicherheitsproblembereiche lassen sich mit Hilfe des in Abbildung 11.1-3 gezeigten Netzwerkmodells aus Sicht der Sicherheit anschaulich darstellen.
Netzwerkmodell aus Sicht der Sicherheit
450
11 VoIP-Sicherheit
In te rn e K o m m u n ik a tio n
...
E n d s y s te m e
4
...
6
...
U n a u to ris ie rte Z u g riffe
P a s s w ö r te r , C h ip k a r te n , ...
...
M a n ip u la tio n , ...
Z u g r if f s k o n tr o lle , ...
U n a u to ris ie rte Z u g r if f e , D o S , ..
N e tz w e rk s e g m e n tie ru n g , I n tr u s io n D e te c tio n , ...
D o S , V ir e n , ...
V ire n -S c a n n e r, In tru s io n D e te c tio n , M o n ito rin g , P o r ts c h lie ß e n , ...
U n a u to ris ie rte Z u g r if f e , ...
F ir e w a lls ,...
N e tz w e rk in fra s tru k tu r
3
...
...
2
S e rv e r
1 7
...
In te rn e t
V o IP
V o IP
N e tz z u g a n g
R
M a ß n a h m e n
A n g r iffe
B e n u tz e r
5
8 R e m o te A c c e s s
E x te rn e K o m m u n ik a tio n
S ic h e r h e its p r o b le m b e r e ic h :
Ö ffe n tlic h e N e tz e
V G
V e rs c h lü s s e ln , D ig ita le S ig n a tu re n , I P s e c , S R T P , ...
A b h ö re n , P a ra m e te r v e r ä n d e r n , ...
IS D N
Abb. 11.1-3: Logisches Netzwerkmodell aus Sicht der VoIP-Sicherheit Ein Sicherheitsproblembereich kann jeweils einer Schicht zugeordnet werden. Somit entsteht ein 5-Schichten-Modell, das sich gut zur Analyse der Sicherheit beim VoIP-Einsatz in jedem Netzwerk eignet. Außerdem müssen die Sicherheitsprobleme bei den verteilten Netzwerkkomponenten, aber auch bei der internen und externen VoIP-Kommunikation in Betracht gezogen werden. Daher kommen drei schichtübergreifende Sicherheitsproblembereiche hinzu. Dieses Modell ist von der Netzwerktopologie unabhängig und kann als Referenzmodell bei der Planung der Sicherheit beim VoIP-Einsatz dienen.
www.wiwobooks.com
Die einzelnen Schichten im Referenzmodell lassen sich jeder physikalischen Netzwerkstruktur einfach zuordnen. Abbildung 11.1-4 illustriert, wo die in Abbildung 11.1-3 gezeigten Sicherheitsproblembereiche in der typischen physikalischen Netzwerkstruktur zu finden sind.
3
L 2 S
5
L 3 S 6
4
G e b ä u d e N
B a c k b o n e
...
...
L 2 S L 2 S
R e c h e n z e n tru m
L 3 S
7
L 3 S
L 2 S
V o IP
L 2 S
V G R
8 3 IS D N
8
2
Z e n tra le S e rv e r
L 2 S
...
... ...
G e b ä u d e 1
...
Wo sind einzelne Schichten?
1
7 In te rn e t
Abb. 11.1-4: Netzwerktopologie und Sicherheitsproblembereiche aus Abbildung 11.1-3 Lx-S: Layer-x-Switch (x = 2, 3), R: Router, VG: VoIP-Gateway
11.1 Probleme der VoIP-Sicherheit
451
Die einzelnen Sicherheitsproblembereiche: 1.
Netzzugangsbereich: Hier kann die Sicherheit durch den Einsatz von Firewalls erhöht werden. Die Zugriffsrechte auf das VoIP-Gateway und den zugehörigen VoIP-Server sollen nur den Netzwerkadministratoren über bestimmte Management-Rechner eingeräumt werden.
2.
Serverbereich: Die zentralen VoIP-Systemkomponenten (wie z.B. VoIP-Server) müssen im Netzwerksicherheitskonzept entsprechend ihrer Aufgabe Berücksichtigung finden. Die VoIPBenutzer müssen entsprechend authentifiziert werden. Die „normalen“ Benutzer dürfen die Einstellungen auf dem VoIP-Server nicht verändern.
3.
Netzwerkinfrastrukturbereich: Das ist ein komplexes Sicherheitsgebiet, in dem verschiedene Sicherheitsmaßnahmen in Frage kommen. Insbesondere zählen hierzu: eine logische Netzwerkstrukturierung, der Einsatz von Sicherheitsmaßnahmen in Layer-2- und Layer-3-Switches sowie der Einsatz von Lösungen für Intrusion Detection.
4.
Endsystembereich: Hier muss spezifiziert werden, welcher Benutzer welche Telefone bzw. Rechner zum Telefonieren nutzen darf? Dies kann oft mit Hilfe verschiedener Zugangslisten (Access Control Lists) in den Endgeräten entsprechend eingetragen werden.
5.
Benutzerbereich: Hier müssen die Benutzerrechte spezifiziert werden, z.B. welche Dienstmerkmale (z.B. Anrufweiterschaltung) ein Benutzer aktivieren darf? Sollten Benutzer versuchen, auf die Konfigurationsdaten zuzugreifen, für die sie nicht autorisiert sind, können hier Sicherheitsbedrohungen durch unautorisierte Zugriffe entstehen. Als Sicherheitsmaßnahmen lassen sich hier Passwörter bzw. Chipkarten einsetzen.
6.
Lokale Kommunikation: In diesem Bereich müssen Maßnahmen ergriffen werden, um die Vertraulichkeit der internen Sprachkommunikation nach Bedarf zu garantieren.
7.
Remote Access Services: Falls Telearbeit im Unternehmen praktiziert wird, ist dafür zu sorgen, dass die Konfigurationsdaten und -parameter durch externe Angreifer nicht gezielt manipuliert werden können. Hier sind Maßnahmen nötig, um die Integrität von VoIP-Systemkomponenten zu garantieren.
8.
Externe Kommunikation: Hier müssen Maßnahmen ergriffen werden, um die Vertraulichkeit der externen Sprachkommunikation zu garantieren. Diese lässt sich durch eine entsprechende Verschlüsselung der zu übertragenden IP-Pakete mit Sprache als Payload erreichen. Zusätzlich müssen Maßnahmen ergriffen werden, mit denen sich eine gezielte Verfälschung von Signalisierungsangaben beim Auf- und Abbau von Telefonverbindungen aufdecken lässt. Dies sind die Maßnahmen, um u.a. die Garantie der Integrität von Signalisierungsdaten zu gewährleisten.
www.wiwobooks.com
Um eine bestimmte Art von Gefährdungen im Netzwerk ausschließen zu können, wird oft eine sog. DMZ (DeMilitarisierte Zone) im Netzwerk eingerichtet. Hierbei kann man entweder eine einstufige oder eine zweistufige Firewall implementieren. Wird eine DMZ eingerichtet, kann die Schicht „Netzzugang“ im Referenzmodell in Abbildung 11.1-3 entsprechend weiter strukturiert (aufgeteilt) werden.
Einführung einer DMZ
11.1.4 Phasen des VoIP-Sicherheitsprozesses Die Aufrechterhaltung einer angemessenen Stufe der VoIP-Sicherheit kann nur ein geplantes und organisiertes Vorgehen aller Beteiligten gewährleisten. Die Voraussetzung hierfür ist die Umsetzung des gut durchdachten Sicherheitskonzepts und die ständige Überwachung von eingeführten Sicherheitsmaßnahmen. Dies führt zu einem kontinuierlichen VoIP-Sicherheitsprozess mit mehreren Phasen, die zyklisch durchlaufen werden. Wie Abbildung 11.1-5 zeigt, folgen nach der Initiierung des VoIP-Sicherheitsprozesses die vier Phasen, die einen PDCA-Zyklus (Plan-Do-CheckAct) bilden.
VoIPSicherheitsprozess
452
11 VoIP-Sicherheit
P D C A -Z y k lu s
In itiie ru n g d e s V o IP -S ic h e rh e its p ro z e s s e s P la n
A c t V e rb e sse ru n g d e r V o IP -S ic h e rh e it
P la n u n g d e r V o IP -S ic h e rh e it
C h e c k Ü b e rw a c h u n g d e r V o IP -S ic h e rh e it
D o R e a lis ie ru n g d e r V o IP -S ic h e rh e it
Abb. 11.1-5: Phasen beim Verlauf des VoIP-Sicherheitsprozesses Bevor mit der Planung der VoIP-Sicherheit begonnen wird, müssen zunächst die Netzwerkstruktur analysiert und alle VoIP-sicherheitsrelevanten Komponenten erhoben werden, um die Sicherheitsziele festzulegen. Diese Ziele sollen bereits bei der Initiierung des VoIP-Sicherheitsprozesses erfasst werden. Die primären Ziele wurden bereits in Abschnitt 11.1.1 dargestellt.
Planung
Die Planung der VoIP-Sicherheit beginnt mit der Analyse des Schutzbedarfs. Hierfür erfolgt als Erstes eine Analyse von Bedrohungen, danach eine Analyse der daraus resultierenden Risiken. Die Ergebnisse dieser Analysen stellen die Grundlage für die Feststellung des Schutzbedarfs und die Formulierung von Sicherheitsanforderungen dar, die durch das zu erstellende Sicherheitskonzept erfüllt werden sollen. Die Kernaufgabe der Planung der VoIP-Sicherheit ist die Erstellung des VoIP-Sicherheitskonzepts, das u.a. die notwendigen Sicherheitsmaßnahmen spezifiziert.
Realisierung
Nach der Erstellung des VoIP-Sicherheitskonzepts folgt die Umsetzung von vorgesehenen Sicherheitsmaßnahmen. Daher spricht man von Realisierung der VoIP-Sicherheit. Hierbei handelt es sich sowohl um technische Sicherheitssysteme, wie z.B. Firewalls, als auch um organisatorische Maßnahmen.
Überwachung
Um VoIP-Sicherheit im laufenden Netzwerkbetrieb aufrechtzuerhalten, ist ihre ständige Überwachung nötig. In dieser Phase soll die Überprüfung der Wirksamkeit von umgesetzten Sicherheitsmaßnahmen erfolgen. Hierfür sollte man ein geeignetes Monitoringsystem einrichten, das Fehler erkennt und Risikobewertungen entsprechend aktualisiert. Ein wichtiges Instrument der Überwachung stellen hierbei regelmäßige Sicherheits-Audits dar.
Verbesserungen
Während des Netzwerkbetriebs sollte man immer versuchen, die VoIP-Sicherheit zu verbessern. Daher stellt die letzte Phase im Verlauf des Sicherheitsprozesses die Verbesserung der VoIPSicherheit dar. Dies bedeutet, dass eine ständige Kontrolle tatsächlicher und potenzieller Sicherheitsschwachstellen durchgeführt werden muss – eine von mehreren Voraussetzungen, um Sicherheit zu garantieren. Hierbei ist ebenfalls eine Analyse der restlichen Sicherheitsrisiken nötig. Sie kann auch zu eventuellen Verbesserungen des Sicherheitskonzepts führen.
www.wiwobooks.com
11.1.5 Vorgehensweise bei der Planung der VoIP-Sicherheit SchweizerKäse-Modell
Die Phasen und Zustände bei der Planung der VoIP-Sicherheit lassen sich anhand des in Abbildung 11.1-6 gezeigten Schweizer-Käse-Modells gut veranschaulichen.
11.1 Probleme der VoIP-Sicherheit
S c h u tz b e d a rfs e rm ittlu n g B e d ro h u n g e n , G e fä h rd u n g e n
F e s ts te llu n g v o n S ic h e rh e its a n fo rd e ru n g e n S ic h e rh e its ris ik e n
453
E rs te llu n g d e s V o IP S ic h e rh e its k o n z e p ts
S ic h e rh e its a n fo rd e ru n g e n
S ic h e rh e its re s tris ik e n
S ic h e rh e its s c h w a c h s te lle
Abb. 11.1-6: Phasen und Zustände bei der Planung der VoIP-Sicherheit Verschiedene Sicherheitsgefährdungen führen dazu, dass man mit gewissen Unsicherheiten bzw. mit Sicherheitsschwachstellen rechnen muss. Die Sicherheitsschwachstellen in einem Netzwerk repräsentieren die Stellen, wo ein gewisser Schutzbedarf besteht, der durch entsprechende Sicherheitsmaßnamen abgedeckt werden muss. Ordnet man einem Sicherheitsproblembereich im Netzwerk (s. Abb. 11.1-3) ein Stückchen Schweizer Käse zu, könnte man eine Sicherheitsschwachstelle im Netzwerk als Loch im Käse anschaulich darstellen. Ein Loch repräsentiert daher eine Stelle, wo ein Risiko entsteht und dadurch auch ein gewisser Schutzbedarf besteht. Die Phase der Schutzbedarfsermittlung soll somit die Antwort auf die Frage geben: Wo befinden sich überhaupt die Sicherheitsschwachstellen, und welche Risiken sind mit ihnen verbunden? Bildlich gesprochen, lautet diese Frage: Wo sind die Löcher im Schweizer Käse, und wie groß sind sie?
Schutzbedarfsermittlung
www.wiwobooks.com
In der ersten Phase der Planung der VoIP-Sicherheit sind daher die potenziellen Sicherheitsschwachstellen zu ermitteln und vollständig zu erfassen. Für die erfassten Sicherheitsschwachstellen muss dann auch der Schutzbedarf ermittelt und entsprechend spezifiziert werden. Mit jeder Schwachstelle ist ein Risiko verbunden. Daher müssen auch während der Schutzbedarfsermittlung die Risiken analysiert werden. Die Risikoanalyse ist die Grundlage für die „politische“ Entscheidung, wie weit die einzelnen Schwachstellen beseitigt werden sollen. Die Ermittlung des Schutzbedarfs präsentiert Abschnitt 11.4. In der zweiten Phase der Sicherheitsplanung werden auf der Basis der Risikoanalyse und unter Berücksichtigung der verschiedenen (z.B. finanziellen) Rahmenbedingungen Sicherheitsanforderungen definiert, die in das VoIP-Sicherheitskonzept münden. Wenn wir uns noch einmal das Bild vom Schweizer Käse vor Augen halten, so beziehen sich die eine Schwachstelle betreffenden Sicherheitsanforderungen auf ein Loch im Käse und legen fest, wie weit dieses Loch gestopft werden soll. Der Festlegung von Sicherheitsanforderungen widmet sich Abschnitt 11.5.
Festlegung von Sicherheitsanforderungen
Wurden alle Sicherheitsanforderungen spezifiziert, kann man zur dritten Phase der Sicherheitsplanung übergehen, in der das Konzept für die VoIP-Sicherheit erstellt wird. Grundsätzlich gilt: Hundertprozentige Netzwerksicherheit gibt es nie. Daher sollte nach der Erstellung des Sicherheitskonzepts wiederum abgeschätzt werden, wo und welche Sicherheitsrestrisiken noch bestehen oder entstehen können. Die Erfassung von Sicherheitsrestrisiken stellt die zentrale Vorgabe für die Überwachung der Sicherheit während des Netzwerkbetriebs dar. Das Konzept für die VoIP-Sicherheit bestimmt die Art und Weise, wie die einzelnen Sicherheitsschwachstellen beseitigt werden, wie also die einzelnen Löcher im Schweizer Käse gestopft werden sollen. Die Maßnahmen zur Erhöhung der VoIP-Sicherheit präsentiert Abschnitt 11.6.
Maßnahmen zur Erhöhung der VoIPSicherheit
454
11 VoIP-Sicherheit
11.2 Bedrohungstypen und Angriffsarten bei VoIP Auf VoIP-Systeme können unterschiedliche Angriffe erfolgen. Viele von ihnen sind bereits aus dem klassischen Netzwerkumfeld bekannt. Daher erklären wir zunächst diese bekannten Angriffsarten, bevor wir auf spezifische Angriffsarten bei VoIP eingehen. Im Anschluss zeigen wir, welche Bedrohungen als Folge dieser Angriffe entstehen können.
11.2.1 Typische Angriffe in Netzwerken Eine umfassende Darstellung von Angriffen, mit denen man im Netzwerkumfeld rechnen muss, würde sehr umfangreich ausfallen und ist deshalb hier nicht möglich. Für tiefgreifende Informationen sei z.B. auf [BuWo 02 ], [Ecke 09] und [FuHW 01] verwiesen. Es wird hier vor allem auf die Besonderheiten, Ursachen und negativen Auswirkungen der Angriffe eingegangen. Typische Angriffe im Netzwerkumfeld sind:
Schadensprogramme
Einschleusen diverser Schadensprogramme; hierzu gehören Viren, Trojaner (Trojanische Pferde), Würmer, Backdoors, Exploits und Rootkits. Für alle unerwünschten Software-Aktivitäten, mit denen die Sicherheit oder Funktionsfähigkeit von Rechnern und anderen Netzwerksystemkomponenten beeinträchtigt werden kann, verwendet man den Begriff Malware.
Virus
Ein Computervirus (kurz Virus) ist kein eigenständiges Schadensprogramm, sondern eine Befehlsfolge, die ein selbstständiges Programm zur Ausführung voraussetzt, an das es sich anhängen kann. Bei der Ausführung des mit einem Virus infizierten Programms wird auch die Virus-Befehlsfolge ausgeführt, sodass der betreffende Rechner infiziert werden kann. Viren sind in der Lage, sich selbst zu reproduzieren. Ein Virus kann eine Kopie (Reproduktion) oder eine modifizierte Version von sich selbst erzeugen (Infektion). Durch Viren können Schäden, Fehlfunktionen und Störungen auf befallenen Rechnern entstehen. Es gibt unterschiedliche Arten von Viren (z.B. Boot-Viren, Programm-Viren, Daten-Viren). Viren werden oft durch die Weitergabe und das Herunterladen von Dateien verbreitet.
www.wiwobooks.com
Wurm
Ein Wurm ist ein eigenständiges, ablauffähiges Schadensprogramm, das sich selbstreproduzierend in Netzwerken verbreiten kann. Daher benötigt ein Wurm zu seiner Ausführung kein anderes eigenständiges Programm. Ein Wurm verwendet einen sich selbst propagierenden böswilligen Code, der sich automatisch über Netzwerkverbindungen von einem Rechner auf andere verteilen kann. Er kann schädliche Aktionen ausführen. Einige Wurmtypen können sich ohne benutzerseitige Eingriffe ausführen und ausbreiten, während andere die direkte Ausführung des Wurmcodes durch den Benutzer erfordern. Würmer können Schadensroutinen besitzen, die z.B. ein Backdoor einrichten. Sie verbreiten sich meist über E-MailAnhänge.
Trojaner
Der Begriff Trojanisches Pferd geht auf die Sage über den Kampf um die Stadt Troja zurück. Bei diesem Kampf stellten die Griechen als Zeichen des Rückzugs den Trojanern ein großes hölzernes Pferd mit versteckten griechischen Soldaten vor den Toren der belagerten Stadt ab. Daher ist ein Trojanisches Pferd (auch Trojaner genannt) ein eigenständiges Schadensprogramm, das dem Benutzer zunächst als nützliches Programm erscheint, in dem aber eine zusätzliche bösartige Funktionalität verborgen ist. Trojanische Pferde können im Hintergrund aktiv werden und Schaden auf dem Rechner anrichten bzw. sensible Daten sammeln und an seinen Absender (Angreifer) melden. Trojanische Pferde werden meist über E-Mail-Nachrichten zugestellt, in denen der Zweck und die Funktion des Programms falsch dargestellt werden. Ein Trojanisches Pferd kann möglicherweise Ports auf dem befallenen Rechner öffnen, um unbefugte Zugriffe auf ihn zu ermöglichen. Trojanische Pferde können sich nicht selbststän-
455
11.2 Bedrohungstypen und Angriffsarten bei VoIP dig vermehren, sondern müssen kopiert werden, was möglicherweise beim Öffnen eines EMail-Anhangs oder beim Herunterladen einer Software geschieht. Als Backdoor (Hintertür) bezeichnet man einen geöffneten Port in einem Rechner innerhalb eines Netzwerks, von dem der Besitzer des Rechners nichts weiß. Ein Backdoor kann von einem Wurm oder einem Trojanischen Pferd eingerichtet werden. Die Gefahr besteht hier darin, dass ein potenzieller Angreifer bestimmte Rechte auf diesem Rechner nutzen kann und damit sensible Daten abhört bzw. den betroffenen Rechner als Ausgangspunkt für weitere Angriffe im Netzwerk nutzt.
Backdoor
Exploit ist ein kleines Programm, das eine Schwachstelle in einem Netzwerk ausnutzen kann, um sich Zugang zu einem Rechner zu verschaffen. Durch die Verwendung eines Exploits kann eine Schwachstelle im Netzwerk ermittelt werden. Mit Exploits können auch einige böswillige Angriffe vorgenommen werden.
Exploit
Ein Rootkit ist eine Sammlung von Dateien und Programmen, die es einem Angreifer gestatten, auf dem angegriffenen Rechner Administratorrechte (Root-Rechte) zu erlangen. Um einen Rootkit-Angriff durchzuführen, wird zuerst eine Schwachstelle im Netzwerk ermittelt, i.d.R. durch Verwenden eines Exploits. Daher werden Rootkits auch als Root-Exploits bezeichnet. Im Erfolgsfall kann der Angreifer die volle Kontrolle über den Rechner erlangen.
Rootkit
Auf wichtige Netzwerkkomponenten (z.B. Server) können sog. DoS-Angriffe (Denial of Service) vorgenommen werden. Mit einem DoS-Angriff wird versucht, einen Rechner lahmzulegen oder bestimmte Dienste durch Kapazitätsüberlastung einzuschränken. DoS-Angriffe beeinträchtigen daher die Verfügbarkeit eines Rechners bzw. eines Dienstes. Wird die Überlastung eines Rechners durch mehrere verteilte Stellen im Internet erzeugt, spricht man von verteilten DDoS-Angriffen (Distributed DoS). Ein DoS-Angriff auf einen Zielrechner kann von einem Angriffsrechner aus erfolgen, u.a. durch ständiges Senden von Anfragen: − von ICMP-Nachrichten Destination Unreachable mit der Angabe Fragmentation needed and DF set bzw. von ICMP-Nachrichten Source Quench; − von IP-Paketen mit TCP SYN, um ständig den Aufbau einer neuen TCP-Verbindung zu initiieren. Daher kann ein Server durch Aufbau einer übermäßigen Anzahl nicht bestätigter TCP-Verbindungen in die Lage gebracht werden, keine weiteren TCP-Verbindungen mehr aufbauen zu können. Man spricht hier von SYN Flood-Attacke.
(D)DoSAngriffe
Unter Spoofing – genauer gesagt Address Spoofing – versteht man das Benutzen einer falschen Identität des Absenders. Ein Spoofing-Angriff erfolgt somit durch Vortäuschen falscher Quelladressangaben. Um Spoofing-Angriffe zu vermeiden, sollten sich die beiden Kommunikationspartner gegenseitig authentifizieren. Da es sich um verschiedene Angaben über den Quellrechner handeln kann, unterscheidet man folgende Arten von Spoofing: − Bei IP Spoofing (IP Address Spoofing) sendet ein Angreifer die IP-Pakete mit einer vorgetäuschten Quell-IP-Adresse an einen Zielrechner und will damit eine Kommunikationsbeziehung mit diesem Zielrechner aufrechterhalten. Der Angreifer täuscht so dem Zielrechner vor, er sei der wahre Kommunikationspartner. IP Spoofing ist häufig ein Ausgangspunkt für andere Angriffe, wie z.B. DoS-Angriffe bzw. Call Fraud beim Zugang zu einem VoIP-Server. − Bei DNS-Spoofing wird die Zuordnung zwischen IP-Adresse und Rechnernamen verfälscht. − URL-Spoofing (URI-Spoofing) geschieht durch die Vorgabe eines falschen URL. Beispielsweise nutzen die sog. Phishing-Angriffe URL-Spoofing. Als Phishing bezeichnet man Angriffe mit dem Ziel, persönliche Informationen wie Passwörter oder PIN-Nummern des Opfers zu erfahren. Hierbei werden E-Mails versendet – die aussehen, als stammten sie von einer vertrauenswürdigen Institution, werden aber eingesetzt –, um dem Benutzer Nachrichten mit persönlichen Daten zu entlocken. Meist wird in ihnen um eine Antwort gebeten, in der man vertrauliche Daten (PIN- und TAN-Nummern) preis-
SpoofingAngriffe
www.wiwobooks.com
456
11 VoIP-Sicherheit
−
geben soll, oder man wird direkt durch einen Link auf eine gefälschte Web-Seite umgeleitet. Der Angreifer kann dadurch z.B. die Angaben zu Bankverbindungen ausspionieren. MAC-Spoofing entsteht durch Vortäuschen einer falschen Quell-MAC-Adresse.
HijackingAngriffe
Als Hijacking wird ein Angriff auf eine Kommunikationsverbindung bezeichnet, bei dem diese Verbindung vom Angreifer übernommen wird. Beispiele für solche Angriffe: − Browser-Hijacking als Umleitung von Browser-Anfragen auf fremde Webseiten; − TCP-Hijacking als Umleitung einer TCP-Verbindung zu einem Angriffsrechner.
Port Scanning
Port Scanning ist die gezielte Suche mit speziellen Hacker-Tools nach den offenen TCP- und UDP-Ports in Rechnern, um sie zu kompromittieren bzw. zu missbrauchen.
11.2.2 Typische Angriffe bei VoIP Denkbare Angriffe bei VoIP lassen sich übersichtlich darstellen, wenn man sie den einzelnen Niveaus im Schichtenmodell eines Netzwerks zuordnet. Abbildung 11.2-1 illustriert dies.
A n w e n d u n g
S c h a d e n s p r o g r a m m e : V ire n , T ro ja n is c D o S - A n g r if f e b e i S I P : m it IN IV IT E , C C a ll H ija c k in g b e i S I P : m it A n tw o rte n S IP -U R L -S p o o fin g T o ll/C a ll F ra u d (G e b ü h re n b e tru g ) D ie n s tm is s b r a u c h : P h a rm in g , P h re a k in M itM -A n g riff: Ä n d e ru n g v o n A n g a b e n
h e P f e r d e , W ü r m e r , B a c k d o o r s , ... A N C E L , B Y E , A n tw o r te n 6 x x , ... 3 0 1 b z w . 3 0 2
www.wiwobooks.com
T ra n sp o rt T C P /U D P
IP M A C
g , S P I T , ... ( z .B . b e i R T P , S I P , H .3 2 3 - S I G )
D o S - A n g r if f e b e i H .3 2 3 : m it T C P S Y N P o rt S c a n n in g M itM - A n g r if f : Ä n d e r u n g v o n A n g a b e n ( z .B . b e i T C P , U D P ) D o S -A IP -S p o R o u te D H C P M itM -
n g r if f e : m it IC M P -N a c h ric h te n D e s tin a tio n U n re a c h a b le b z w . S o u rc e Q u e n c h o fin g In je c tio n S ta rv a tio n A n g r if f : Ä n d e r u n g v o n A n g a b e n ( z .B . b e i I P , I C M P )
M A C -S p o o fin g
Abb. 11.2-1: Typische Angriffe bei VoIP auf den einzelnen Niveaus im Schichtenmodell DoS: Denial of Service, MAC: Media Access Control, MitM: Man in the Middle
Angriffe auf dem Anwendungsniveau Typische Angriffe bei VoIP auf dem Niveau der Anwendungen sind:
Schadensprogramme
Schadensprogramme wie z.B. Viren, Trojanische Pferde, Würmer, Backdoors und Exploits stellen bei VoIP ebenfalls Bedrohungen dar. Insbesondere Backdoors können eingesetzt werden, um ein VoIP-System z.B. für einen Gebührenbetrug zu missbrauchen bzw. um einen Lauschangriff auf einen Voicemail-Server durchzuführen. Auf Anwendungsniveau können verschiedene DoS-Angriffe durchgeführt werden. Hier sind u.a. folgende Möglichkeiten zu erwähnen:
457
11.2 Bedrohungstypen und Angriffsarten bei VoIP −
Der Aufbau einer VoIP-Verbindung wird bei SIP mit der Nachricht INVITE initiiert (s. Abb. 7.1-8). Für den Transport von SIP-Nachrichten wird das verbindungslose Transportprotokoll UDP verwendet. Falls das IP-Telefon des Angerufenen den ankommenden Anruf annehmen kann, wird dieser bei ihm akustisch signalisiert. Daher kann ein Angreifer INVITEs ständig an ein IP-Telefon senden, um dort ein akustisches Signal zu erzeugen. Mit dieser Belästigung kann man das Ziel verfolgen, den angerufenen Teilnehmer zu zwingen, sein IP-Telefon außer Betrieb zu setzen. Ein IP-Telefon kann von einem Angriffsrechner aus mit INVITE-Nachrichten, in denen fiktive SIP-Adressen als Absender und rechnerintensive Angaben enthalten sind, so überflutet werden, dass es seine Funktion nicht mehr richtig wahrnimmt. Man spricht dann von SIP-Bombing.
DoS mit INVITEs
−
Wurde ein Backdoor in einen VoIP-Server beim SIP-Einsatz eingeschleust, so kann dieses Schadensprogramm die SIP-Nachricht CANCEL verwenden, um jeden bereits begonnenen Verbindungsaufbau bösartig zu unterbrechen. Damit lässt sich das gesamte VoIPSystem lahmlegen.
DoS mit CANCEL
−
Um jeden bereits begonnenen VoIP-Verbindungsaufbau bösartig zu unterbrechen, kann ein Backdoor in einem VoIP-Server beim SIP-Einsatz die Antworten 6xx (wie 600 Busy Everwhere, 603 Decline, 606 Not Acceptable) verwenden.
DoS mit 6xx
−
Ein Backdoor in einem VoIP-Server kann beim SIP-Einsatz die Nachricht BYE verwenden, um jedes begonnene VoIP-Telefonat bösartig zu unterbrechen. Das ganze VoIPSystem kann so lahmgelegt werden.
DoS mit BYE
Ein Backdoor in einem VoIP-Server, der als SIP-Proxy- bzw. SIP-Redirect-Server funktioniert, kann die Antworten 301 Moved Permanently und 302 Moved Temporarily verwenden, um die in ein Netzwerk ankommenden VoIP-Verbindungen auf einen Angriffsrechner umzuleiten. Diese Angriffsart wird als Call Hijacking bezeichnet, was als Übernahme bzw. Entführung des Anrufs angesehen werden kann (s. Abb. 11.3-4).
Call Hijacking
Bei der Integration von VoIP nach SIP mit Web-Anwendungen ist URI-Spoofing analog zu URL-Spoofing bei Phishing-Angriffen möglich. Auf diese Weise könnte ein Angreifer das Opfer dazu veranlassen, VoIP-Telefonate zu einer scheinbar vertrauten Stelle zu initiieren. Der Angreifer könnte eine E-Mail im Namen einer Bank an sein Opfer senden, mit der Bitte, eine bestimmte Abteilung der Bank per Internet-Telefonie zu kontaktieren, indem er einfach dem enthaltenen Link auf einen SIP-URI folgt. Dadurch kommt der Angreifer in den Besitz der SIP-Adresse des Opfers. Die fehlende Überprüfung der Authentizität von Signalisierungsnachrichten macht es dem Opfer unmöglich, die gewünschte Gegenstelle, d.h. seine Bank, zuverlässig zu identifizieren. So sind zukünftig auch Phishing-Anrufe denkbar.
URISpoofing
www.wiwobooks.com
Systemkomponenten wie VoIP-Server und -Gateways sowie andere Netzwerkkomponenten (wie z.B. DNS-Server usw.) laufen in der Regel unter Unix- oder Windows-Betriebssystemen. Daher können auf diesen Systemkomponenten – durch Ausnutzung von Sicherheitslücken in den Betriebssystemen – bestimmte Schadensprogramme (z.B. Backdoor) installiert und ausgeführt werden. Ein Angreifer kann dadurch gezielt die Informationen sammeln, die er benötigt, um einen Gebührenbetrug vorzunehmen. Man spricht hierbei von Call Fraud bzw. Toll Fraud. Darüber hinaus kann der VoIP-Dienst durch SPIT bzw. Pharming missbraucht werden. VoIP ist auch dadurch gefährdet, dass VoIP-Teilnehmer mit unerwünschten Anrufen „bombardiert“ werden können, in denen ihnen Geld, Reisen und andere Vorteile versprochen werden. Diese Angriffe werden als SPIT (Spam over Internet-Telephony) bezeichnet und zählen ebenfalls zum Missbrauch des VoIP-Dienstes. Darauf geht Abschnitt 11.2.6 näher ein.
SPIT
Pharming bedeutet, dass die über VoIP-geführten Gespräche unbemerkt und ohne weitere Interaktion des Benutzers (wie etwa das Klicken auf einen Link in einer E-Mail) über einen Angriffsrechner geleitet werden. Dabei könnten Gespräche, sofern sie nicht verschlüsselt
Pharming
458
11 VoIP-Sicherheit sind, abgehört werden. Es sind daher Angriffe denkbar, bei denen der Benutzer auf eine präparierte und der „Original-Seite“ täuschend ähnliche Seite geleitet wird, auf der man ihn zur Eingabe z.B. seiner Kontoverbindungen mit vertraulichen Daten auffordert (s. Abschnitt 11.2.4). Pharming tauchte erstmals im Frühjahr 2005 auf.
Phreaking
Phreaking (aus phone freak) bezeichnet das illegale Manipulieren von Telefonsystemen, um diese zu missbrauchen bzw. kostenlos zu telefonieren.
Man-in-theMiddleAngriffe
Auf Niveau der Anwendungsschicht ist auch mit den sog. Man-in-the-Middle-Angriffen bei VoIP zu rechnen. Durch passives Monitoring mit Hilfe eines Sniffers kann ein Angreifer die RTP-Pakete mit Sprachinhalt sammeln. Mittels der im Internet frei erhältlichen Tools lassen sich diese Pakete in ein Audio-Format (z.B. wave-Format) wandeln und wiedergeben. Den Verlauf der VoIP-Kommunikation kann der Angreifer dadurch stören, dass er eigene RTPPakete hinzufügt. Man bezeichnet diese Angriffsart als RTP Insertion (s. Abb. 11.2-6a). Ein Angreifer kann hier auch Signalisierungsangaben für bösartige Zwecke sammeln. Die Manin-the-Middle-Angriffe werden oft mit dem Ziel vorgenommen, weitere Angriffe, wie z.B. einen DoS-Angriff, vorzubereiten und durchzuführen.
Angriffe auf dem Niveau der Transportschicht Typische Angriffe bei VoIP:
DoS mit TCP-Paketen SYN
Hier sind DoS-Angriffe auf VoIP-Systeme mit TCP-Paketen SYN beim H.323-Einsatz denkbar. Ein Anruf-SIG-Kanal (s. Abb. 6.1-4) bei H.323 stellt eine TCP-Verbindung dar und muss somit für die Signalisierung jedes Anrufs aufgebaut werden. Die aus dem klassischen Netzwerkumfeld bereits bekannten DoS-Angriffe können daher mit Hilfe von TCP-Paketen SYN vorgenommen werden. Falls die H.323-Signalisierung über einen Gatekeeper verläuft, kann dieser mit den TCP-Paketen SYN bombardiert werden. Weil jedes SYN zum Aufbau einer neuen TCP-Verbindung führt, könnte man den Gatekeeper so auslasten, dass er nicht mehr in der Lage wäre, seine Dienste richtig auszuführen.
www.wiwobooks.com
Port Scanning
Das aus dem Netzwerkumfeld bekannte Port Scanning kann auch beim VoIP-Einsatz sowohl mit H.323 als auch mit SIP dazu führen, dass die geöffneten Ports in VoIP-Systemkomponenten (wie z.B. VoIP-Server und Gateways) von Angreifern entdeckt werden können. Dadurch ist es möglich, bestimmte Schadensprogramme (wie z.B. Backdoors) in diese Komponenten einzuschleusen. Daher kann Port Scanning als Vorbereitungsangriff dienen, um weitere Angriffe durchzuführen.
Man-in-theMiddleAngriffe
Bei VoIP mit H.323 und SIP sind Man-in-the-Middle-Angriffe auch auf dem Transportschichtniveau denkbar. Durch passives Monitoring kann ein Angreifer im Netzwerk lauschen und die Angaben in den TCP- und UDP-Headern gezielt für bestimmte böswillige Angriffe sammeln bzw. diese Angaben gezielt verändern.
Angriffe auf IP-Niveau Typische Angriffe bei VoIP auf dem Niveau der IP-Schicht:
DoS mit ICMPNachrichten
DoS-Angriffe auf VoIP-Systeme mit ICMP-Nachrichten Destination Unreachable und Source Quench sind beim Einsatz sowohl von H.323 als auch von SIP denkbar. − Durch wiederholtes Senden der ICMP-Nachricht Destination Unreachable kann die falsche Meldung verbreitet werden, dass eine bestimmte VoIP-Komponente (Server, IP-Telefon) nicht erreichbar sei. − Durch wiederholtes Senden der ICMP-Nachricht Source Quench (Übertragungsrate reduzieren) kann eine VoIP-Komponente dazu gezwungen werden, dass sie im Endeffekt keine Daten mehr sendet. Diese Komponente wird somit außer Betrieb gesetzt.
11.2 Bedrohungstypen und Angriffsarten bei VoIP
459
Das aus dem klassischen Netzwerkumfeld bekannte IP Spoofing ist auch beim VoIP-Einsatz sowohl mit H.323 als auch mit SIP möglich. Hierbei kann ein Angreifer die IP-Pakete mit einer vorgetäuschten Quell-IP-Adresse an einen Zielrechner senden und damit eine Kommunikationsbeziehung mit ihm aufrechterhalten. Der Angreifer täuscht dabei dem Zielrechner vor, er sei der wahre Kommunikationspartner. Mit IP Spoofing kann somit ein Angriffsrechner einem IP-Telefon z.B. einen VoIP-Server (z.B. SIP-Server, Gatekeeper bei H.323) vortäuschen. IP Spoofing dient bei VoIP häufig als Ausgangspunkt für Call Fraud oder andere betrügerische Angriffe.
IP Spoofing
Ein Angreifer kann in einigen Situationen (keine Autorisierung) auch eine falsche Route in die Routing-Tabelle eines Routers einschleusen. Man spricht hierbei von Route Injection. Durch einen derartigen Angriff können einige VoIP-Datenströme zu einem Rechner umgeleitet werden, in denen der Angreifer z.B. die übermittelten Signalisierungsangaben manipulieren kann.
Route Injection
Die IP-Telefone in einem Netzwerk werden oft von einem DHCP-Server mit IP-Adressen versorgt. Durch Vortäuschung von DHCP-Paketen kann ein Angreifer mit einer beliebigen Anzahl gefälschter MAC-Adressen sämtliche vom DHCP-Server zu vergebenden IP-Adressen an sich binden. Dies kann dazu führen, dass keine IP-Adresse für ein neu angeschlossenes IP-Telefon mehr vorhanden ist, womit dieses dann unbrauchbar wird. Daher handelt es sich hier um einen DoS-Angriff, den man als DHCP Starvation bezeichnet.
DHCP Starvation
Auf dem Niveau der IP-Schicht sind bei VoIP – unabhängig vom Signalisierungsprotokoll – auch Man-in-the-Middle-Angriffe möglich. Ein Angreifer kann im Netzwerk lauschen und die Angaben im Header der IP- und ICMP-Pakete gezielt für andere böswillige Angriffe sammeln bzw. diese Angaben gezielt verändern. Die Folgen dieser Man-in-the-Middle-Angriffe lassen sich im Vorfeld nicht abschätzen.
Man-in-theMiddleAngriffe
www.wiwobooks.com
Angriffe auf MAC-Niveau Beim VoIP-Einsatz können einige Angriffe auf dem Niveau der MAC-Schicht auf dem Wege des aus dem Netzwerkumfeld bekannten MAC-Spoofing vorgenommen werden. Bei MACSpoofing wird einem Rechner eine falsche MAC-Adresse oft beim Ablauf des Protokolls ARP (Address Resolution Protocol) vorgegeben. Ein Angriffsrechner kann mit Hilfe von MACSpoofing für ankommende Anrufe falsche IP-Telefone vortäuschen und eventuell einige Anrufe auf einen falschen Voicemail-Server umleiten. MAC-Spoofing ist oft die Voraussetzung für andere Lauschangriffe.
MACSpoofing
Die ARP-Tabelle eines Rechners lässt sich von einem Angreifer mit nicht vorhandenen MACAdressen abändern (s. Abschnitt 3.2.4), sodass einige IP-Telefone logisch vom Netzwerk abgetrennt werden können. Man bezeichnet diese Angriffsart als ARP-Spoofing.
ARPSpoofing
Die Angriffe auf VoIP-Systeme können sowohl von innen durch interne Benutzer als Innentäter als auch von außen durch externe Benutzer (eigene Mitarbeiter als Außentäter) bzw. durch externe und fremde Angreifer durchgeführt werden. Daher ist zwischen internen und externen Angriffen zu unterscheiden.
Beispiele für einige Angriffe bei VoIP Abbildung 11.2-2 illustriert einige Beispiele für Angriffe bei VoIP, die ein Innentäter vornehmen kann.
460
11 VoIP-Sicherheit
T ln C
V o IP S e rv e r
V o ic e m a ilS e rv e r
5
In te rn e t
R
P S T N /IS D N
5
V G 6
1
3
T ln E T ln D 3 2
4 3
A n g re ife r
T ln B T ln A
1
N e tz w e rk m it V o IP
Abb. 11.2-2: Beispiele für Angriffe bei VoIP von einem Innentäter R: Router, VG. VoIP-Gateway
Die in der Abbildung angezeigten Angriffsszenarien im Einzelnen: 1.
Gebührenbetrug (Call Fraud): Der Angreifer hat in den Rechner, der dem Teilnehmer A als IP-Telefon dient, ein Backdoor eingeschleust mit dem Ziel, auf dessen Kosten zu telefonieren. Der Rechner bei Teilnehmer A soll hier als VoIP-Relay zwischen dem Angreifer und seinen Kommunikationspartnern fungieren.
2.
DoS-Angriff auf IP-Telefon −
SIP-Einsatz: Der Angreifer bombardiert das IP-Telefon von Teilnehmer B mit der SIPNachricht INVITE pausenlos mit verschiedenen Absenderrufnummern, um bei ihm ankommende Anrufe ständig akustisch zu signalisieren (d.h. bei ihm klingeln zu lassen). Teilnehmer B fühlt sich belästigt und schaltet die akustische Signalisierung ab. So kann er bei ihm eingehende Anrufe nicht immer direkt wahrnehmen.
−
H.323-Einsatz: Da bei H.323 eine TCP-Verbindung als Anruf-SIG-Kanal dient (s. Abb. 6.1-4), muss diese immer aufgebaut sein, um die Signalisierung nach H.225.0 zum ZielIP-Telefon zu übermitteln. Um einen DoS-Angriff durchzuführen, sendet der Angreifer daher wiederholt an das IP-Telefon von Teilnehmer B IP-Pakete mit TCP SYN unter der gefälschten Quell-IP-Adresse, um das IP-Telefon in die Lage zu versetzen, den Aufbau einer neuen TCP-Verbindung ständig initiieren zu müssen. Es handelt sich hierbei um einen klassischen DoS-Angriff.
www.wiwobooks.com
3.
Abhören einer Voicemail: Der Angreifer hat in den Rechner von Teilnehmer E ein Backdoor eingeschleust, um die Abwesenheit von Teilnehmer E bzw. den Besetzt-Zustand bei diesem vorzutäuschen und die für ihn ankommenden Anrufe auf eine Box im VoicemailServer umzuleiten, auf den der Angreifer zugreifen kann.
4.
DoS-Angriff auf VoIP-Server: Dem Angreifer ist es gelungen (z.B. nach einem SpoofingAngriff), dem VoIP-Server einen wahren VoIP-Teilnehmer vorzutäuschen, sodass er nun einen DoS-Angriff wie folgt durchführen kann: −
SIP-Einsatz: Der Angreifer kann die Funktion des VoIP-Servers durch die Überflutung mit INVITE (d.h. durch SIP Bombing) beeinträchtigen. Erhält der VoIP-Server die Registrar-Funktion (s. Abschnitt 7.6), kann der Angreifer durch Verfälschen des SIPHeaders Contact versuchen, die Registration Records zu manipulieren und danach Call Hijacking durchzuführen. Man spricht hierbei auch von Registration Hijacking (s. Abb. 11.3-3).
−
H.323-Einsatz: Enthält der VoIP-Server die Funktion eines Gatekeepers und wird die Signalisierung über den Gatekeeper geroutet (s. Abb. 6.4-4), kann der Angreifer den
11.2 Bedrohungstypen und Angriffsarten bei VoIP VoIP-Server mit den IP-Paketen mit TCP SYN so überfluten, dass die Funktion des Gatekeepers beeinträchtigt wird. 5.
Call Hijacking: Umleitung bzw. Abzweigung einer VoIP-Verbindung zu einem Angriffsrechner. −
−
SIP-Einsatz: Dem Angreifer ist es bei einem MitM-Angriff gelungen, eine SIP-Nachricht INVITE abzuhören, sodass er die Antworten 301 Moved Permanently und 302 Moved Temporarily an den Absender von INVITE senden kann (s. Abb. 11.3-4). Auf diese Weise kann der Angreifer die VoIP-Verbindung auf seinen Angriffsrechner umleiten, um das Gespräch abzuhören. Der Angriffsrechner verhält sich hierbei wie eine Relay-Station auf der VoIP-Verbindung und leitet die IP-Pakete zu ihrem wahren Ziel weiter (s. Abb. 11.2-6). H.323-Einsatz: Dem Angreifer ist es bei einem MitM-Angriff gelungen, eine Nachricht SETUP abzuhören. Falls die Signalisierung über den Gatekeeper geroutet wird, kann er
die Funktion des Gatekeepers vortäuschen und die VoIP-Verbindung auf seinen Angriffsrechner umleiten, um das Gespräch abzuhören. 6.
Blockierung von Leitungen: Ein Angreifer als Innentäter kann nach dem Einschleusen eines Backdoor-Programms in das VoIP-Gateway ebenfalls in der Lage sein, die Ausgangsleitungen zu blockieren.
Klassen der Angriffe auf VoIP-Systeme
www.wiwobooks.com
Bei böswilligen Angriffen auf VoIP-Systeme können folgende Ziele verfolgt werden: Lauschen und Abhören, Abfangen und Modifizieren von Verbindungsdaten, VoIP-Dienstbeeinträchtigung oder -Dienstmissbrauch. Hierfür können verschiedene Angriffe durchgeführt werden. Alle Angriffsarten, bei denen das gleiche Ziel verfolgt wird, bilden eine Angriffsklasse. Daher ist zwischen den in Abbildung 11.2-3 gezeigten Angriffsklassen zu unterscheiden.
C a ll H M itM S c h a d P h a rm S IP -U
C a ll H ija c k in g M itM -A n g riffe B a c k d o o rs L a u sc h a n g riffe
A & M -A n g riffe
C a ll /T o ll F ra u d S P IT P h re a k in g
D M -A n g riffe
ija c k in g -A n g riffe e n s p ro g ra m m e : B a c k d o o rs , T ro ja n e r in g R L -, IP , M A C -S p o o fin g D B -A n g riffe D o S -A n g riffe S c h a d e n s p r o g r a m m e : V ir e n , ... V o ic e -B o m b in g C lip p in g
Abb. 11.2-3: Angriffe auf VoIP-Systeme und ihre Zugehörigkeit zu Angriffsklassen A&M: Abfangen und Modifizieren, DB: Dienstbeeinträchtigung, DM: Dienstmissbrauch, MitM: Man in the Middle
Die einzelnen Angriffsklassen: Lauschangriffe: Sie werden mit dem Ziel vorgenommen, die Übertragung von Daten bzw. Sprache abzuhören oder im Netzwerk zu lauschen. Es handelt sich hierbei i.d.R. um Hijacking- und MitM-Angriffe. Um ein Netzwerk für Lauschangriffe vorzubereiten, werden oft Backdoors mit einer Sniffer-Funktion in bestimmte Rechner eingeschleust.
461
462
11 VoIP-Sicherheit Angriffe zum Abfangen und Modifizieren (A&M-Angriffe): Diese Angriffe zielen darauf ab, die übertragenen Daten, insbesondere die Signalisierungsdaten, abzufangen und zu modifizieren. Hier handelt es sich um Hijacking-, Spoofing und MitM-Angriffe. Hinzu kommen Angriffe wie Phishing und Pharming. Angriffe zur Dienstbeeinträchtigung (DB-Angriffe): Das Ziel dieser Angriffe ist es, den Betrieb eines VoIP-Systems zu behindern, d.h. den VoIP-Dienst zu beeinträchtigen. Zu dieser Klasse von Angriffen gehören verschiedene DoS-Angriffe, Voice-Bombing und Clipping. Angriffe zum Dienstmissbrauch (DM-Angriffe): Ziel dieser Angriffe ist es, ein VoIP-System für betrügerische Zwecke zu missbrauchen. Dazu gehören diverse Angriffe (wie z.B. Call Fraud), die einen Gebührenbetrug bezwecken. Dieser Klasse von Angriffen werden auch SPIT und Phreaking zugeordnet.
11.2.3 Lauschangriffe bei VoIP und Gegenmaßnahmen Lauschangriff
Als Lauschangriff wird ein passiver Angriff bezeichnet, der zum Ziel hat, Telefongespräche oder Voicemails abzuhören oder diese aufzuzeichnen, ohne den Verlauf der Kommunikation zu beeinträchtigen bzw. in sie einzugreifen. Bei VoIP muss auch mit Angriffen gerechnet werden, die bezwecken, bestimmte Informationen über den Verlauf der Anrufe zu sammeln, um das Lauschen besser durchführen zu können. Die Ziele der Lauschangriffe können zwar unterschiedlich sein, führen aber immer zum Verlust der Vertraulichkeit. Lauschangriffe werden in der englischen Literatur als Eavesdropping bezeichnet. Abbildung 11.2-4 zeigt eine Auflistung typischer Lauschangriffe bei VoIP.
Abhören von Telefongesprächen
Das häufigste Ziel der Lauschangriffe bei VoIP wird mit Sicherheit darin bestehen, Telefongespräche abzuhören bzw. sie aufzuzeichnen. In der klassischen Telefonie herrscht die Meinung vor, dass das Abhören von Telefongesprächen deshalb so schwierig sei, weil dort die Leitungen schwer zugänglich sind und ein Angreifer sich tatsächlich vor Ort an die Telefonleitung anklemmen müsste. Weil Telefonate bei VoIP jedoch ungeschützt über das öffentliche Internet bzw. ein anderes IP-Netz verlaufen, sei das Abhören bei VoIP sehr viel einfacher. Im Prinzip ist dies zwar richtig, ganz so trivial stellt es sich jedoch nicht dar.
www.wiwobooks.com
L a u s c h a n g riffe b e i V o IP
A b h ö re A b h ö re A u ssp ä V e rfo lg ...
n b z n b z h e n u n g
w . A w . A v o n d e r
u fz e u fz e V e rb A n ru
ic h n e n ic h n e n in d u n g fe b z w
v o n T e le fo n g e s p rä c h e n v o n fre m d e n V o ic e m a ils s d a te n . v o n V o IP -T ra ffic
Abb. 11.2-4: Typische Lauschangriffe bei VoIP
Gefahr durch Backdoor bzw. Trojaner
Ein Lauscher kann mit Hilfe eines installierten Backdoor-Programms oder Trojaners in das System eindringen und mit im Internet frei verfügbaren Tools wie z.B. Ethereal oder Cain&Abel die IP-Pakete mit Sprachinhalt mitschneiden und anschließend in ein Audio-Format wandeln. Im Internet sind bereits Tools verfügbar, um IP-Pakete mit Sprache als wav-Datei abzuspeichern. Die von Backdoor-Programmen mit Sniffer-Funktion ausgehende Gefahr ist derzeit kaum einzuschätzen. Während sicherheitsrelevante Unternehmensdaten meist auf besonders geschützten Servern untergebracht sind, werden Gespräche oft auch von „normalen“ Rechnern geführt, die als IP-Telefone fungieren. Insbesondere Backdoors, über die ein Nachrichtendienst oder ein Wettbewerber praktisch permanent unbemerkt Telefonate mitverfolgen kann, können ernsthafte Bedrohungen darstellen.
11.2 Bedrohungstypen und Angriffsarten bei VoIP Gegen Lauschangriffe können u.a. folgende Maßnahmen ergriffen werden:
463 Maßnahmen
Um VoIP-Telefongespräche vor dem Abhören durch einen Unbefugten zu schützen, sollte die übertragene Sprache verschlüsselt werden. Dies kann durch den Einsatz des Protokolls SRTP erfolgen (s. Abschnitt 5.7). SRTP kann sowohl bei SIP als auch bei H.323 eingesetzt werden. Der Zugriff auf einen Voicemail-Server sollte nur nach einer erfolgreichen Authentisierung des Benutzers (d.h. Überprüfung der Echtheit seiner Identität) und Überprüfung seiner Zugangsberechtigung erfolgen. Damit kann sichergestellt werden, dass nur autorisierte Benutzer entsprechend ihrer Berechtigung auf vorliegende Voicemails zugreifen können. Durch das Ausspähen von Verbindungsdaten lassen sich bestimmte Lauschangriffe besser durchführen. Daher muss sichergestellt sein, dass nur autorisierte Administratoren den Zugriff auf den VoIP-Server mit Verbindungsdaten (Call Records) haben, um das Ausspähen von Verbindungsdaten durch Unbefugte zu verhindern. Um eine Verfolgung von Anrufen bzw. von VoIP-Traffic zu verhindern, sollten die übertragenen Signalisierungsdaten vor Abhörversuchen geschützt werden. Hierfür kann bei SIP das Sicherungsprotokoll TLS (Transport Layer Security) eingesetzt werden (s. Abb. 7.1-1).
11.2.4 Abfangen und Modifikation von VoIP-Anrufen Auf VoIP-Systeme können verschiedene Angriffe mit dem Ziel vorgenommen werden, VoIPAnrufe abzufangen bzw. sie entsprechend zu modifizieren. Abbildung 11.2-5 zeigt, um welche Angriffe es sich dabei handelt.
www.wiwobooks.com
M itM -A n g riffe A b fa n g e n u n d M o d ifik a tio n d e r V o IP -A n ru fe
S p o o fin g -A n g riffe
H ija c k in g S c h a d e n sp ro g ra m m e
V e rä n d e ru n g v o n : S I G - A n g a b e n b e i S I P b z w . b e i H .3 2 3 R T P - u n d R T C P -A n g a b e n , R T P u n d R T C P In s e r tio n V o rtä S IP -A IP -A d M A C
u sc h u n d re sse re sse ; -A d re s
g d e r fa ls c h e n Q u e lla d re s s e : ; S IP -U R L -S p o o fin g IP -S p o o fin g s e ; M A C -S p o o fin g , A R P -S p o o fin g
R e g is tra tio n H ija c k in g b e i S IP C a ll H ija c k in g B a c k d o o r s , T r o ja n e r , ...
P h a rm in g
Abb. 11.2-5: Typische Angriffe zum Abfangen und zur Modifikation von VoIP-Anrufen MitM: Man in the Middle, SIG: SIGnalisierung
Durch das Aufzeichnen der IP-Pakete mit Hilfe eines Sniffers kann ein MitM-Angriff durchgeführt werden. Der Angreifer kann einige IP-Pakete mit Sprache bzw. mit Signalisierungsangaben (nach SIP bzw. nach H.323) lesen und bestimmte Angaben böswillig ändern. Er kann fiktive RTP- oder RTCP-Pakete auf einer VoIP-Session (s. Abb. 5.2-1) hinzufügen, sodass man hier entsprechend von RTP Insertion bzw. von RTCP Insertion spricht. Insbesondere kann RTCP Insertion unterschiedliche negative Auswirkungen haben. Abbildung 11.2-6 zeigt zwei Beispiele für MitM-Angriffe.
MitMAngriffe
464
11 VoIP-Sicherheit
a )
A n g re ife r a b g e h ö rt
T ln A S S R C
R T P
T ln B
b ) T ln A
R T P In s e rtio n R T P
A n g re ife r a b g e fa n g e n
R T P
T s = x
B Y E
T ln B
T s = x R T P
T s : T im e s ta m p
Abb. 11.2-6: MitM-Angriffe: a) RTP Insertion, b) Modifikation von RTP-Angaben RTP Insertion (Abb. 11.2-6a): Hat ein Angreifer ein IP-Paket von Teilnehmer A mit einem eingekapselten RTP-Paket auf einer VoIP-Verbindung abgehört, kann er die RTP Insertion wie folgt durchführen. Er generiert ein neues RTP-Paket (s. Abb. 5.3-1), indem er eine andere Identifikation SSRC der Quelle, also des IP-Telefons von Teilnehmer A, angibt. Das Telefon von Teilnehmer B stellt eine SSRC-Kollision fest, und als Reaktion darauf sendet es an das Telefon von Teilnehmer A das RTCP-Paket BYE. Dies führt zum Abbruch der bestehenden VoIP-Verbindung. Modifikation von RTP-Angaben (Abb. 11.2-6b): Hat ein Angreifer ein RTP-Paket von Teilnehmer A abgefangen, kann er einige Angaben böswillig modifizieren. Insbesondere die Änderung von Timestamp und Sequence Number im RTP-Header kann eine große negative Auswirkung auf die Qualität der VoIP-Verbindung haben. Die Änderung von Payload Type kann z.B. zum Abbruch der Verbindung führen.
DoS-Angriffe auf VoIPVerbindungen
www.wiwobooks.com
MitM-Angriffe dienen oft als Vorbereitungsangriffe, um andere Angriffe wie z.B. DoS-Angriffe bzw. Call Hijacking durchzuführen. Abbildung 11.2-7 illustriert zwei Arten von DoS-Angriffen auf VoIP-Verbindungen.
a )
T ln A IN V IT E
a b g e h ö rt IN V IT E C A N C E L
T ln B
b )
T ln A IN V IT E C A N C E L
a b g e h ö rt
T ln B
IN V IT E
Abb. 11.2-7: Verhinderung a) eines ankommenden sowie b) eines abgehenden Anrufs Verhinderung eines ankommenden Anrufs (Abb. 11.2-7a): Hat ein Angreifer die SIP-Nachricht INVITE vom Telefon des Teilnehmers A abgehört, kann er einen Angriff so durchführen, dass er gleich danach die SIP-Nachricht CANCEL an das Telefon des Teilnehmers B sendet. Dies führt bei Teilnehmer B zum Abbruch des Anrufs. Verhinderung eines abgehenden Anrufs (Abb. 11.2-7b): Hat ein Angreifer INVITE vom Telefon des Teilnehmers A abgehört, kann er unmittelbar danach CANCEL an dieses Telefon senden, um den abgehenden Anruf bei diesem direkt abzubrechen.
Spoofing
Spoofing bei VoIP besteht darin, dass ein Angreifer bestimmte Adressinformationen (wie z.B. MAC- oder IP-Adresse, SIP-URI) über die Quelle dem Ziel (z.B. einem VoIP-Server bzw. einem IP-Telefon) vortäuscht, um auf diese Weise eine Kommunikationsbeziehung aufrechtzuerhalten. Spoofing dient oft als Vorbereitung für einen DoS-Angriff bzw. einen Hijacking-Angriff.
11.2 Bedrohungstypen und Angriffsarten bei VoIP Bei VoIP ist mit den beiden folgenden Arten von Hijacking zu rechnen:
465 Hijacking
Registration Hijacking (Registrierungsentführung) bei SIP: Ein Angreifer fälscht in der Nachricht REGISTER (s. Abschnitt 7.6) die Angabe Contact so, dass er weitere Angriffe durchführen kann – siehe hierfür Abbildung 11.3-3. Call Hijacking (Anrufentführung): Sowohl bei SIP als auch bei H.323 kann eine VoIP-Verbindung über einen Angriffsrechner geführt werden – siehe z.B. Abbildung 11.3-4. Um VoIP-Anrufe abzufangen bzw. sie entsprechend zu modifizieren, können auch Schadensprogramme wie Trojaner bzw. Backdoors in bestimmte Komponenten (VoIP-Server, Soft-IP-Telefone) eingeschleust werden.
Schadensprogramme
Bei VoIP ist mit Pharming zu rechnen. Hierbei handelt es sich um eine Betrugsmethode, bei der die Webanfragen auf Angriffsrechner mit gefälschten Webseiten umgeleitet werden. Pharming stellt eine Weiterentwicklung von Phishing dar. Die Bezeichnung Pharming soll zum Ausdruck bringen, dass Kriminelle hierfür eigene Server-Farmen als Angriffsrechner unterhalten, auf denen gefälschte Webseiten abgelegt sind.
Pharming
Technischer Hintergrund von Pharming: Um einen Namen des Zielrechners auf seine IPAdresse aufzulösen, kann ein DNS-Server benützt werden. Bevor ein DNS-Server jedoch kontaktiert wird (s. Abschnitt 3.5.3), überprüft das Rechnerbetriebssystem zunächst in der hostsDatei, ob bereits die entsprechende Zuordnung Hostname IP-Adresse vorhanden ist. Wenn ja, wird die IP-Adresse abgelesen, ohne den DNS-Server nutzen zu müssen. Die hosts-Datei lässt sich jedoch mit Hilfe eines Trojaners bzw. eines anderen Backdoor-Programms so manipulieren, dass einige Webseiten (z.B. einer Bank) von einem Angriffsrechner als vorgetäuschter Webserver abgerufen werden. Daher erhält der Benutzer trotz Angabe einer korrekten URL eine gefälschte Webseite, ohne es zu bemerken.
www.wiwobooks.com
Beim VoIP mit SIP wird das Zieltelefon als SIP-URI angegeben, um den Namen des Zieltelefons aus dem SIP-URI (z.B. in der Form user@hostname, s. Abschnitt 7.1.3) auf seine IP-Adresse aufzulösen, so wie dies auch bei jeder Webabfrage geschieht. Zunächst wird die hosts-Datei im den Anruf initiierenden Telefon darauf hin gelesen, ob sie die gesuchte Zuordnung Hostname IP-Adresse bereits enthält. Wurde die hosts-Datei jedoch von einem Angreifer bösartig manipuliert, können einige abgehende Anrufe zuerst an einen Angriffsrechner geführt und von dort zum wahren Zieltelefon weitergeleitet werden. So kann ein Anruf über einen Angriffsrechner laufen, ohne dass die beiden Kommunikationspartner etwas davon bemerken. Pharming bei VoIP mit SIP bedeutet also, dass Gespräche abgehört und Signalisierungsdaten aufgezeichnet werden können.
Pharming bei SIP
Bei VoIP mit H.323 ist Pharming ebenfalls denkbar. Bei H.323 verwaltet ein Gatekeeper die Tabelle mit den Zuordnungen: Rufnummer IP-Adresse für das gesamte Netzwerk bzw. für ein Netzwerksegment. Jedes Telefon enthält daher die IP-Adresse seines Gatekeepers, um die IP-Adresse des Zieltelefons abrufen zu können. Wurde die IP-Adresse des Gatekeepers in einem Telefon durch einen Angreifer auf die IP-Adresse eines Angriffsrechners geändert, werden die IPAdressen der Zieltelefone beim Angriffsrechner abgefragt. Kennt der Angriffsrechner die IPAdresse des Gatekeepers, kann er dessen Funktion vortäuschen, indem er als Relay-Station fungiert und die Anfragen an den wahren Gatekeeper weiterleitet. Damit verlaufen abgehende Anrufe vom angegriffenen Telefon über einen Angriffsrechner, ohne dass der rufende Teilnehmer dies bemerkt. Hierbei können alle Signalisierungsdaten aufgezeichnet werden. Verlaufen die RTPSessions zusätzlich über den Gatekeeper, ist es möglich, diese Gespräche auch abzuhören.
Pharming bei H.323
Gegen Pharming kann man als Soft-Telefone dienende Rechner durch den Einsatz von AntiViren-Programmen bzw. mit Hilfe einer lokalen Firewall absichern.
466
11 VoIP-Sicherheit
11.2.5 Beeinträchtigen des VoIP-Dienstes Im klassischen Netzwerkumfeld werden oft verschiedene Angriffe vorgenommen, um die Netzwerkdienste zu beeinträchtigen. Mit solchen Angriffen ist auch beim VoIP-Einsatz zu rechnen. Abbildung 11.2-8 zeigt, um welche Angriffe es sich hierbei handelt.
B e e in trä c h tig u n g d e s V o IP -D ie n s te s
D o S -A n g riffe S c h a d e n sp ro g ra m m e
Ü b e r f lu tu n g : m it I N V I T E s b e i S I P , m it T C P S Y N s b e i H .3 2 3 g e g e n ü b e rtra g e n e M e d ie n s trö m e ... B e e in trä c h tig u n g m it V ire n u n d W ü rm e rn B e e in trä c h tig u n g m it B a c k d o o rs u n d T ro ja n e rn ...
Abb. 11.2-8: Möglichkeiten der Beeinträchtigung des VoIP-Dienstes
DoS-Angriffe
Bei DoS-Angriffen geht es vor allem darum, zentrale Netzwerkkomponenten (wie z.B. Server) lahmzulegen. Es können z.B. folgende VoIP-spezifische DoS-Angriffe durchgeführt werden: Beim SIP-Einsatz: − Überflutung von VoIP-Komponenten (Server, Telefone) mit SIP-Request INIVITE, sodass diese mit ständigen Anrufen bombardiert werden. Hier spricht man auch von VoiceBombing bzw. von V-Bombing. − Abbruch der Anrufe mit SIP-Request CANCEL bzw. mit SIP-Responses 6xx (600 Busy Everwhere, 603 Decline, 606 Not Acceptable) − Abbruch von VoIP-Sessions mit SIP-Request BYE
www.wiwobooks.com
Überflutung von VoIP-Komponenten mit TCP SYN beim H.323-Einsatz Beim SIP- und beim H-323-Einsatz: − Angriffe gegen übertragene Medienströme durch böswillige Modifikationen von RTPAngaben (s. Abb. 11.2-6) − Abbruch von VoIP-Sessions mit RTCP-Paket BYE − Verbreitung von Falschmeldungen mit ICMP-Nachrichten Destination Unreachable über die Unerreichbarkeit von VoIP-Komponenten − Beeinträchtigung von VoIP-Komponenten mit ICMP-Nachrichten Source Quench, sodass sie ihre Datenrate reduzieren Die zentralen VoIP-Komponenten (Server, Gateway) sollen daher als Bastionen aufgebaut werden, auf denen unnötige und angreifbare Dienste deaktiviert sind, ein Virenschutz läuft und Intrusion-Prevention realisiert ist.
Schadensprogramme
VoIP kann zusätzlich durch verschiedene Schadensprogramme beeinträchtigt werden. Insbesondere handelt sich hierbei um Viren und Würmer sowie um Backdoors und Trojaner, die verwendet werden können, um das Netzwerk für weitere Angriffe vorzubereiten.
11.2.6 Missbrauch des VoIP-Dienstes Formen des Missbrauchs
Ein VoIP-System kann unterschiedlich missbraucht werden. Folgende Formen des Missbrauchs sind hervorzuheben: Ausspähen von Verbindungsdaten Gebührenbetrug – auch als Call Fraud bzw. Toll Fraud bezeichnet
467
11.2 Bedrohungstypen und Angriffsarten bei VoIP Gebührenmissbrauch – Phreaking Service-Diebstahl – Service-Theft Vishing (VoIP Phishing) SPIT (Spam over Internet Telephony). Die in der Regel auf einem Accounting-Server gehaltenen Verbindungsdaten enthalten Informationen darüber, wann welche Teilnehmer miteinander telefoniert haben. Es sind also personenbezogene Daten, die dem Datenschutz unterliegen. Diese Daten können nach dem Ausspähen unterschiedlich missbraucht werden.
Verbindungsdaten
Ein Gebührenbetrug entsteht in Folge unberechtigter Nutzung eines VoIP-Systems durch einen Betrüger, der auf Kosten von anderen telefoniert; dabei kann es sich z.B. um einen Außentäter handeln, nachdem er ein Schadensprogramm in das Telefon eines Teilnehmers bzw. in einen VoIP-Server eingeschleust hat (s. Abb. 11.2-2). Ein Gebührenbetrug kann ebenfalls durch einen Benutzer als Innentäter verursacht werden. Letzterer kann z.B. durch das Telefonieren von fremden Apparaten oder durch Auslesen fremder Berechtigungscodes (Passwörter) versuchen, auf Kosten anderer Mitarbeiter bzw. des Arbeitgebers zu telefonieren.
Gebührenbetrug
Das illegale Manipulieren von Parametern eines Telefonsystems, um es zu missbrauchen bzw. kostenlos zu telefonieren, wird als Phreaking bezeichnet. Mit Phreaking ist vor allem bei VoIP zu rechnen. Hierbei entsteht ein Risiko, wenn ein Angreifer z.B. die unverschlüsselt übertragenen Authentifizierungsdaten abfangen kann. Er kann sich unter falscher Identität in das System einschleichen und dann auf Kosten eines Benutzers telefonieren.
Phreaking
Ein Service-Diebstahl kommt oft dann vor, wenn ein unautorisierter Benutzer Zugang zu einem Netzwerk mit VoIP hat, sich ein IP-Telefon eines autorisierten Benutzers zuordnet und z.B. internationale Telefongespräche durchführt. Ein solcher Service-Diebstahl – auch als Service-Theft bezeichnet – kann durch das Einschleusen eines bösartigen Programms in einen Rechner eines autorisierten Benutzers mit einem Soft-IP-Telefon realisiert werden, um auf seine Kosten Telefongespräche führen zu können.
ServiceDiebstahl
Mit Vishing wird die traditionelle Form von Phishing bei VoIP nachgebildet. Darunter versteht man den Versuch, einen VoIP-Nutzer zu betrügen und ihn u.a. dazu zu veranlassen, seine Benutzerdaten (wie z.B. User Name, Passwörter) bzw. persönliche Informationen dem Anrufer zu offenbaren. Der Trick besteht darin, dass der Angerufene aufgefordert wird, z.B. seine Benutzerdaten bei seinem Internet Service Provider oder bei seiner Bank zu verifizieren. Solche Informationen können dann zum Missbrauch von Kreditkarten oder Bankkonten benutzt werden.
Vishing
VoIP kann leider auch für unerwünschte Werbeanrufe missbraucht werden. Man spricht in diesem Zusammenhang von SPIT. Zur Zeit werden verschiedene Ansätze für die SPIT-Abwehr diskutiert – siehe hierfür z.B. RFC 5039. Beispiele für denkbare Anti-SPIT-Lösungen sind:
SPIT
www.wiwobooks.com
Einsatz von Buddylists/Whitelists: Ein Teilnehmer kann eine Liste von Teilnehmern führen, von denen er Anrufe entgegennehmen möchte. Die Anrufe von Teilnehmern, die nicht auf dieser Liste stehen, werden automatisch abgewiesen. Dies ist zwar eine gute Abwehr gegen SPIT, doch werden damit auch Nicht-SPIT-Anrufe blockiert. Einsatz eines zentralen SPIT-Blockers: Alle von außen ankommenden Anrufe zu einem Unternehmen werden zuerst zu einem SPIT-Blocker geführt, der jeden ankommenden Anruf entgegennimmt und ihm eine zufällige Identifikation (z.B. eine zweistellige Zahl) zuordnet. Diese Identifikation wird dem rufenden Teilnehmer vom Sprachautomat im SPIT-Blocker mitgeteilt und soll als Nachwahl dienen. Unmittelbar danach wird die bestehende VoIP-Session vom SPIT-Blocker abgebaut. Der rufende Teilnehmer muss nun den Anruf erneut initiieren und nach dem Ende der Zielrufnummer noch die ihm sprachlich mitgeteilte Identifikation des Anrufs als Nachwahl angeben. Diesen erneuten Anruf leitet der SPIT-Blocker an den angerufenen Teilnehmer nur dann weiter, wenn die empfangene Nachwahl mit der Iden-
468
11 VoIP-Sicherheit tifikation, die dem rufenden Teilnehmer in Sprache mitgeteilt wurde, übereinstimmt. Mit einem derartigen SPIT-Blocker lassen sich die Anrufe durch Anrufautomaten (sog. Dialer) vermeiden, und Nicht-SPIT-Anrufe werden nicht blockiert.
11.3 Sicherheit bei VoIP mit SIP In VoIP-Systemen mit SIP findet man verschiedene Sicherheitsschwachstellen, die durch unterschiedliche böswillige Angriffe extrem gefährdet sind. Die Gefährdungen lassen sich verschiedenen Angriffsklassen zuordnen, die wir in Abschnitt 11.3.1 kurz zusammenfassen.
Sicherheitsmechanismen
Um die Sicherheit zu gewährleisten – d.h., um Vertraulichkeit transportierter Medien und die Verfügbarkeit von Systemen zu garantieren sowie die Integrität und Herkunft (Authentizität) von SIP-Nachrichten überprüfen zu können –, müssen verschiedene Sicherheitsmechanismen eingesetzt werden. Dazu eignen sich SIP-Digest Authentication, S/MIME (Secure/Multipurpose Internet Mail Extension) sowie die Protokolle TLS, DTLS (Datagram TLS) und IPsec. Diese Sicherheitsmechanismen verwendet man bereits in anderen Systemen.
SIP-Digest
SIP-Digest basiert beispielsweise auf dem HTTP-Digest, der ursprünglich mit der Absicht entwickelt wurde, die Herkunft von HTTP-Nachrichten bei Web-Anwendungen zu überprüfen. Das Konzept und die Nutzungsmöglichkeiten von SIP-Digest präsentiert Abschnitt 11.3.2.
S/MIME
S/MIME wurde zur Unterstützung der Sicherheit bei der Übermittlung von E-Mails mit eingekapselten Anhängen (sog. Attachments) entwickelt. Auf den Einsatz von S/MIME in VoIP-Systemen mit SIP geht Abschnitt 11.3.3 ein.
www.wiwobooks.com
11.3.1 Gefährdungen in VoIP-Systemen mit SIP Auf VoIP-Systeme mit SIP als Signalisierungsprotokoll können unterschiedliche Angriffe vorgenommen werden. Viele von ihnen sind – zumindest dem Namen nach – bereits aus dem klassischen Netzwerkumfeld gut bekannt. Die denkbaren böswilligen Angriffsarten und die Angriffsklassen, zu denen sie gehören, listet Abbildung 11.3-1 auf.
Hijacking bei SIP
Die wichtigsten Arten von Hijacking bei SIP: Registration Hijacking – Entführung einer Registrierung: Ein solcher Angriff besteht darin, dass ein Angreifer während einer Registrierung (s. Abb. 11.3-3) den übertragenen SIPRequest REGISTER entführt und dann die Benutzerdaten eines Benutzers – auf dem Registrar – gezielt verfälscht bzw. durch eigene Daten ersetzt. Auf diese Weise kann er später z.B. die für den betroffenen Benutzer eingehenden Anrufe zu sich umleiten – sie also quasi entführen. Session Hijacking – Entführung einer Session: Hier handelt es sich um die Umleitung – also um eine Entführungsart – einer Session zu einem Angreiferrechner. Ein solcher Angriff lässt sich nach einem Registration Hijacking relativ einfach durchführen.
Arten von Spoofing bei SIP
Unter Spoofing versteht man das Vortäuschen einer falschen Identität bzw. der Adresse eines Absenders. Daher spricht man bei SIP von SIP-URI-Spoofing oder von Identity-Spoofing. Sendet ein Angreifer einen SIP-Request mit der vorgetäuschten Adresse des wahren Absenders, spricht man von SIP-Request-Spoofing. Hierbei unterscheidet man zwischen INVITE-, CANCEL- und BYE-Spoofing. INVITE-Spoofing ist mit Session-Spoofing gleichzustellen. Enthält ein SIP-Response eine vorgetäuschte Absenderadresse, handelt es sich um SIP-Response-Spoofing.
11.3 Sicherheit bei VoIP mit SIP
A n g r iffs k la s s e H ija c k in g S p o o fin g Im p e rs o n a tio n
G e fä h rd u n g e n b e i S IP
D o S S e s s io n M o d ifik a tio n L a u s c h a n g riffe D ie n s tm is s b ra u c h
469
A n g r iffs a r t R e g is tra tio n H ija c k in g S e s s io n H ija c k in g S IP -R e s p o n s e S p o o fin g S e s s io n S p o o fin g (IN V IT E -S p o o fin g ) S IP -R e q u e s t S p o o fin g (B Y E /-C A N C E L -S p o o fin g ) S IP -P ro x y Im p e rs o n a tio n S e rv e r Im p e rs o n a tio n IN V IT E -F lo o d in g M a lfo rm e d R e q u e s t/R e s p o n s e S e s s io n -T e a r-D o w n Q o S A b u se C a ll-R e d ire c tio n -A tta c k S IP -M e s s a g e T a m p e rin g T ra ffic A n a ly s is M itle s e n d e r R T P -P a k e te V o IP -S e G e b ü h re S P IT /S P V is h in g
rv ic e T h e ft n b e tru g (C a ll F ra u d , T o ll F ra u d ) IM (V o ic e P h is h in g )
Abb. 11.3-1: Gefährdungsarten in VoIP-Systemen mit SIP
www.wiwobooks.com
Ein Angreifer kann mit seinem Rechner einen SIP-Server imitieren (vortäuschen). Hierfür muss er vorher einen Angriff – als DNS-Spoofing bzw. als DNS-Poisoning bezeichnet – durchführen, um die Zuordnung zwischen dem Hostnamen des betroffenen SIP-Servers und seiner IP-Adresse so zu verfälschen, dass die wahre IP-Adresse des Servers durch die IP-Adresse eines Angreiferrechners ersetzt wird. Als Folge werden SIP-Nachrichten nicht mehr an den wahren SIP-Server übermittelt, sondern an sein Imitat – an den Angreiferrechner also. Man bezeichnet dies als Proxy/Server-Imitation.
SIP-ServerImpersonating
Unter den DoS-Angriffen bei SIP sind u.a. folgende Angriffsarten denkbar:
DoS-Angriffe bei SIP
INVITE-Flooding – auch als Call Flooding bzw. als Überflutung mit INVITE bezeichnet – besteht darin, dass ein Angreifer eine Vielzahl von SIP-Nachrichten INVITE an eine SIPKomponente sendet, um so ihre Funktionalität zu beeinträchtigen. Beispiele hierfür sind: − DoS-Angriff mit INVITE auf einen SIP-Proxy – wird durchgeführt, um bei diesem eine Überlastungssituation zu erzeugen, indem ihm fast ununterbrochen die Nachrichten INVITE übermittelt werden, in denen die SIP-URIs sowohl des Absenders als auch die des Session-Ziels vorgetäuscht sind (s. Abb. 11.2-2). Dies führt dazu, dass der angegriffene SIP-Proxy eine riesige Anzahl von Sessions zu verschiedenen scheinbaren Zielen verwalten muss. Als Folge dessen wird seine Funktionalität stark beeinträchtigt. − SIP-Bombing, Call Bombing: An ein IP-Telefon können seitens vorgetäuschter Anrufer ständig die SIP-Requests INVITE gesendet werden, um ein fast ununterbrochenes Klingeln zu veranlassen und mit diesem den Benutzer zu belästigen. Malformed Request/Response – verfälschte Request/Response: Ein DoS-Angriff, der zum Abbruch bzw. Nichtzustandekommen einer VoIP-Session führt, kann durch das Absenden einer verfälschten SIP-Nachricht – d.h. eines Request bzw Response – durchgeführt werden. Diese Verfälschung kann darin bestehen, dass die Syntax einer SIP-Nachricht so geändert wird, dass die betreffende Nachricht sich nicht mehr interpretieren lässt und demzufolge nach dem Empfang verworfen werden muss.
470
11 VoIP-Sicherheit Session-Tear-Down – Abbruch einer Session: Eine bestehende VoIP-Session kann durch das Absenden eines verfälschten SIP-Request BYE abgebrochen werden. QoS-Abuse – QoS-Missbrauch: Ein DoS-Angriff kann auch zur Minderung der Dienstqualität während einer Session führen. Dies kann z.B. geschehen, wenn ein Angreifer (als Man in the Middle) eine SIP-Nachricht UPDATE sendet, die im Body-Teil – als Session-Beschreibung nach dem SDP – entsprechend deformierte QoS-Attribute der Session enthält.
SessionModifikation
Auf VoIP-Systeme können verschiedene Angriffe mit dem Ziel vorgenommen werden, SIP-Nachrichten abzufangen und sie zu modifizieren, indem einige Session-Eigenschaften mit bösartigen Intentionen verändert werden. Hier ist insbesondere hervorzuheben: Call-Redirection-Attack – boshafte Umleitung einer Session: Eine Session kann bei ihrem Aufbau zum Rechner eines Angreifers umgeleitet werden. Eine solche Umleitung lässt sich nach der Entführung einer Registrierung (s. Abb. 11.3-3) bzw. mit Hilfe eines imitierten SIPProxy (s. Abb. 11.3-5) einfach durchführen. Die boshafte Umleitung einer Session stellt eine Art von Session Hijacking dar (s. Abb. 11.3-4). SIP-Message Tampering – Verfälschen von SIP-Nachrichten: Die Syntax einer SIP-Nachricht – sowohl eines Request als auch eines Response – lässt sich im Header-Teil so manipulieren bzw. verfälschen, dass die betreffende Nachricht nicht mehr interpretierbar ist. Dies kann z.B. zum Abbruch einer VoIP-Session führen. Message-Body Tampering: Hier handelt es sich um eine Variante des SIP-Message Tampering, wobei in diesem Fall die boshafte Manipulation nur im Body-Teil – d.h. im Teil mit der Spezifikation der Session nach SDP – durchgeführt wird.
Lauschangriffe bei SIP
www.wiwobooks.com
Einige Lauschangriffe bei VoIP mit SIP können dazu führen, dass SIP-Verläufe aufgezeichnet und auf diese Weise bestimmte Informationen – wie z.B. IP-Adressen, Hostnamen, SIP-URIs etc. – ausspioniert werden. Zu erwähnen sind folgende Arten der Lauschangriffe: Traffic Analysis – Analyse des VoIP-Datenverkehrs: Ein solcher Lauschangriff wird vor allem durchgeführt, um SIP-Nachrichten abzufangen, aufzuzeichnen und zu untersuchen. Ziel ist es, Informationen – wie z.B. SIP-URIs – zu sammeln oder bestimmte Verbindungsdaten auszuspähen. Mitlesen der RTP-Pakete: Weil die Sprachsegmente in RTP-Paketen transportiert werden, erfolgen solche Angriffe mit dem Ziel, Telefongespräche abzuhören.
Dienstmissbrauch bei SIP
Ein VoIP-System kann auf unterschiedliche Art und Weise missbraucht werden. Die in Abschnitt 11.2.6 dargestellten Möglichkeiten des Missbrauches kommen auch bei SIP in Frage. Zusätzlich muss man beim Einsatz von SIP für Instant Messaging und Presence Services mit SPIM (Spam over Instant-Messaging) rechnen. Dabei werden mit Hilfe der SIP-Nachrichten MESSAGE und NOTIFY unerwünschte Werbeanrufe vorgenommen.
Registration Hijacking Registration Hijacking ist ein Angriff bei SIP, der zu schlimmen Folgen führen kann. Um ihn zu veranschaulichen, gehen wir zunächst kurz auf den Ablauf der Registration bei SIP und eine Sicherheitsschwachstelle von SIP ein.
Ziel einer Registrierung
Um die Mobilität von Benutzern zu unterstützen, kann ein Benutzer einen permanenten und einen vorläufigen SIP-URI besitzen. Der permanente SIP-URI wird Address of Record (AoR) genannt. Beispielsweise kann die AoR des Benutzers Bob, der auf Dauer in der Domain xyz.de beheimatet ist, [email protected] sein. Bob ist aber unterwegs und hält sich in der Domain prs.de auf. Dort nutzt er als sein IP-Telefon den Rechner mit dem Hostnamen mond. Daher kann ihm übergangsweise z.B. [email protected] als sein vorläufiger SIP-URI zugewiesen werden. Bob
11.3 Sicherheit bei VoIP mit SIP
471
muss aber in seiner Heimat-Domain xyz.de darauf verweisen, unter welchem SIP-URI er aktuell erreichbar ist. Hierfür wird eine Registrierung durchgeführt. Unter einer Registrierung (s. Abbildung 11.3-2) versteht man bei SIP einen Vorgang, bei dem ein Benutzer auf einem speziellen Rechner – als SIP-Registrar bezeichnet – eine Zuordnung AoR aktueller SIP-URI speichern lässt. Damit teilt er dem Registrar mit, dass er aktuell nicht unter seinem AoR erreichbar ist, sondern vorläufig unter dem angegebenen, aktuellen SIP-URI. R E G IS T E R
B o b
R e g is tra r d e r D o m a in x y z .d e
2 0 0 O K
R E G I S T E R s ip :r e g is tr a r .x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P b o b te l.x y z .d e :5 0 6 0 ;b ra n c h = z 9 h G 4 b K n a s h d s 2 A o R v o n B o b M a x -F o r w a r d s: 7 0 T o : B o b < s ip :b o b @ x y z .d e > ;ta g = 2 4 9 3 k 5 9 k d F r o m : B o b < s ip :b o b @ x y z .d e > ;ta g = 1 9 2 8 3 0 1 7 7 4 C a ll-I D : 5 4 3 8 1 7 6 3 7 6 8 4 1 2 0 @ x y z s d a s d h 0 9 C S e q : 1 0 5 2 R E G IS T E R C o n t a c t : B o b < s ip :b o b @ m o n d .p r s .d e > ;e x p ir e s 3 6 0 0 C o n te n t-L e n g th : 0 A k tu e lle r S IP -U R I v o n B o b
S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P b o b te l.x y z .d e :5 0 6 0 ;b r a n c h = z 9 h G 4 b K n a s h d s 2 ;r e c e iv e d = 1 9 2 .0 .2 .4 M a x -F o r w a r d s: 7 0 T o : B o b < s ip :b o b @ x y z .d e > ;ta g = 2 4 9 3 k 5 9 k d F r o m : B o b < s ip :b o b @ x y z .d e > ;ta g = 1 9 2 8 3 0 1 7 7 4 C a ll-I D :5 4 3 8 1 7 6 3 7 6 8 4 1 2 0 @ x y z s d a s d h 0 9 C S e q : 1 0 5 2 R E G IS T E R C o n t a c t : B o b < s ip :b o b @ m o n d .p r s .d e > ;e x p ir e s 3 6 0 C o n te n t-L e n g th : 0 A k tu e lle r S IP -U R I v o n B o b a ls B e s tä tig u n g
Abb. 11.3-2: Verlauf einer Registrierung – Wo ist die Sicherheitsschwachstelle?
www.wiwobooks.com
Wie Abbildung 11.3-2 zeigt, sendet der Benutzer Bob einen SIP-Request REGISTER an den Registrar seiner Heimat-Domain xyz.de. Die Zeile To in diesem SIP-Request gibt den AoR an. Die Zeile Contact enthält Bobs aktuellen SIP-URI und die Angabe – expires 3600 – besagt, dass der aktuelle SIP-URI 3600 Sekunden gültig ist. R E G I S T E R s ip :r e g is tr a r .x y z .d e S I P /2 .0 V ia : S I P /2 .0 /U D P b o b te l.x y z .d e :5 0 6 0 ;b r a n c h M a x -F o r w a r d s: 7 0 A o R v o n B o T o : B o b < s ip :b o b @ x y z .d e > F r o m : B o b < s ip :b o b @ x y z .d e > ;ta g = 1 9 2 8 3 0 1 C a ll-I D : 5 4 3 8 1 7 6 3 7 6 8 4 1 2 0 @ x y z s d a s d h 0 9 C S e q : 1 0 5 2 R E G IS T E R C o n t a c t : B o b < s ip :b o b @ m o n d .p r s .d e > ; e x p C o n te n t-L e n g th : 0
B o b
R E G IS T E R
S I P /2 .0 2 0 ......... C o n ta c t: B ;e x p ire s = 3 ......... C o n te n t-L
7 7 4
M itM
ire s 3 6 0 0
R E G I S T E R s ip :r e g is tr a r .x y z .d e S I P /2 .0 ......... C o n t a c t : B o b < s ip :b o b @ 1 9 2 .1 6 8 .1 .3 > ; e x p ir e s 3 6 0 0 ......... IP -A d re sse C o n te n t-L e n g th : 0 d e s A n g r e ife r r e c h n e r s
A k tu e lle r S I P -U R I v o n B o b 2 0 0 O K
x y z .d e
= z 9 h G 4 b K n a sh d s2 b
0 O K o b < s ip :b o b @ m o n d .p r s .d e > 6 0 0 e n g th : 0
M itM
M itM
R E G IS T E R 2 0 0 O K
R e g is tra r d e r D o m a in x y z .d e
S I P /2 .0 2 0 0 O K V ia : S I P /2 .0 /U D P b o b te l.x y z .d e :5 0 6 0 ;b r a n c h = z 9 h G 4 b K n a s h d s 2 ;r e c e iv e d = 1 9 2 .0 .2 .4 M a x -F o r w a r d s: 7 0 T o : B o b < s ip :b o b @ x y z .d e > ;ta g = 2 4 9 3 k 5 9 k d IP -A d re sse F r o m : B o b < s ip :b o b @ x y z .d e > ;ta g = 1 9 2 8 3 0 1 7 7 4 d e s A n g r e ife r C a ll-I D :5 4 3 8 1 7 6 3 7 6 8 4 1 2 0 @ x y z s d a s d h 0 9 re c h n e rs C S e q : 1 0 5 2 R E G IS T E R C o n t a c t : B o b < s ip :b o b @ 1 9 2 .1 6 8 .1 .3 > ; e x p ir e s 3 6 0 0 C o n te n t-L e n g th : 0
Abb. 11.3-3: Registration Hijacking – Verfälschung des SIP-URI im Header-Feld Contact
Ungestörte Registrierung
472
11 VoIP-Sicherheit Mit REGISTER wird dem Registrar in Bobs Heimat-Domain die Zuordnung AoR aktueller SIP-URI übermittelt. REGISTER wird seitens des Registrars mit dem Response 200 OK bestätigt. Hervorzuheben ist hier, dass in diesem Response die beiden Zeilen To und Contact die gleichen Angaben wie im Request REGISTER enthalten. Auf diese Weise wird die Eintragung der Zuordnung AoR aktueller SIP-URI vom Registrar Bobs IP-Telefon bestätigt.
Header-Zeile Contact als Angriffsstelle
Abbildung 11.3-3 zeigt einen Fall von Registration Hijacking. Hier hat ein Angreifer als MitM einen Request REGISTER des Benutzers Bob empfangen und den aktuellen SIP-URI von Bob – in der Zeile Contact – verfälscht, indem er den vollständigen Hostnamen mond.prs.de von Bobs IP-Telefon in der Domain prs.de durch die IP-Adresse seines Rechners ersetzt hat. Das Registration Hijacking besteht darin, dass ein Angreifer die Zuordnung AoR aktueller SIP-URI von Bob so verfälscht hat, dass die für Bob ankommenden Anrufe auf einen Angriffsrechner umgeleitet wurden. Daher stellt Registration Hijacking einen Angriff dar, der als Vorbereitung für andere Angriffe – vor allem Session Hijacking – dienen kann.
Session Hijacking – Entführung einer Session Nachdem ein Angreifer die Registrierung des Benutzers Bob entführt hat – wie in Abbildung 11.3-3 gezeigt –, kann er weitere Angriffe, insbesondere Session Hijacking, durchführen. Zum Beispiel kann er eine von Alice zu Bob initiierte Session entführen. Abbildung 11.3-4 zeigt einen solchen Fall. Bei dieser Entführung gibt der Angreifer vor, der Angerufene Bob zu sein.
www.wiwobooks.com S IP -P ro x y
a b c .d e
S IP -P ro x y
A lic e
IN V IT E
.3 . 0 . 2
1 0 0
IN V IT E 1 0 0
M o v e d T e m p o ra rily
C. . o . n t a c t : < s i p : b o b @ 1 9 2 . 1 6 8 . 1 . 4 >
2 0 0 O K
2 0 0 O K
In te rn e t
x y z .d e B o b
p r s .d e
B o b
x x x .c o m
IN V IT E 3 0 2 M o v e d T e m p o ra rily A C K IN V IT E
A C K
E n tfü h rte S e s s io n A lic e - B o b
2 0 0 O K
M itM
V M S v o n M itM
Abb. 11.3-4: Entführung einer Session – Falscher SIP-URI im Header-Feld Contact Als Folge des Registration Hijacking werden die an Bob in der Domain xyz.de eingehenden Anrufe vom SIP-Proxy in xyz.de an den Rechner des Angreifers – mit der IP-Adresse 192.168.1.3 (s. Abb. 11.3-3) – z.B. in der Domain xxx.com weitergeleitet. Dieser Angreiferrechner täuscht den Proxy-Server der Domain xyz.de. Er signalisiert dem Proxy-Server mit dem SIP-Response 302 Moved Temporarily, dass Bob vorläufig nicht erreichbar ist und der Anruf an den Voice-Mail-Server (VMS) umgeleitet werden soll – also an einen imitierten VMS. Demzufolge wird eine VoIP-Session zwischen dem IP-Telefon von Alice und dem imitierten VMS aufgebaut. Auf diese Weise wurde die Session zum falschen VMS entführt.
11.3 Sicherheit bei VoIP mit SIP
473
Imitation eines SIP-Proxy-Servers Ein Angreifer kann durch einen Angriff auf einen DNS-Server – als DNS-Spoofing bezeichnet – den Resource Record (RR) von Typ A mit der Zuordnung SIP-Proxy-Name IP-Adresse so verfälschen, sodass er anstelle der IP-Adresse des echten SIP-Proxy die IP-Adresse des eigenen Rechners angibt, mit dem er den echten SIP-Proxy imitieren möchte. Abbildung 11.3-5 veranschaulicht einen solchen Angriff. In diesem Beispiel besteht das DNS-Spoofing darin, dass der RR mit der Zuordnung 10.1.1.9 so verändert wurde, dass die wahre IP-Adresse 10.1.1.9 des SIPProxy durch die IP-Adresse 10.10.10.10 des Angreiferrechners ersetzt wurde. Der RR des echten SIP-Proxy wurde somit gezielt verfälscht und hat nun die Form pxy.abc.de 10.10.10.10. Diese Verfälschung hat dazu geführt, dass der echte SIP-Proxy – de facto – logisch abgetrennt und seine Rolle vom Angreiferrechner mit der IP-Adresse 10.10.10.10 übernommen wurde. So einfach lässt sich ein SIP-Proxy entführen! Man spricht in diesem Zusammenhang auch von SIP-Proxy Hijacking. pxy.abc.de
a b c .d e
Q u e r y [ p x y .a b c .d e ] A n s w e r [ 1 0 .1 0 .1 0 .1 0 ] I N V I T E [ s ip :b o b @ x y z .d e ]
D N S -S p o o fin g p x y .a b c .d e 1 0 .1 .1 .9
E c h te r S IP -P ro x y
Im itie rte r S IP -P ro x y 1 0 .1 0 .1 0 .1 0
I P - A d r = 1 9 2 .1 6 8 .1 .4
D N S S e rv e r
A lic e
www.wiwobooks.com
3 0 2 M o v e d T e m p o r a r ily [ C o n ta c t:< s ip :b o b @ 1 9 2 .1 6 8 .1 .4 > ] A C K I N V I T E [ s ip :b o b @ 1 9 2 .1 6 8 .1 .4 ]
S e s s io n
A n sa g e
2 0 0 O K
Abb. 11.3-5: Imitation eines SIP-Proxy – falscher SIP-URI im Header-Feld Contact Bemerkung: Ein IP-Telefon kann die IPv4-Adresse des SIP-Proxy-Servers auch vom DHCPServer – als Option 120 in (s. RFC 3361) – abrufen. Ein Angriff – als DHCP-Spoofing – kann folglich ebenso dazu führen, dass ein IP-Telefon vom DHCP-Server die IPv4-Adresse eines Angriffsrechners – in diesem Fall des imitierten SIP-Proxy-Servers – erhält.
Nach der Entführung des SIP-Proxy kann der Angreifer die Sessions auf seinen Rechner umleiten – also einen als Call-Redirection Attack oder Session Hijacking bezeichneten Angriff durchführen. Ein solcher Angriff kann wie folgt verlaufen: Das IP-Telefon von Alice fragt bei DNS die IP-Adresse des SIP-Proxy mit dem Hostnamen pxy.abc.de ab und erhält die IP-Adresse des SIP-Proxy-Imitats. Um eine Session zu Bob aufzubauen, übermittelt das IP-Telefon von Alice nun den SIP-Request INVITE, aber nicht an den wahren SIP-Proxy, sondern an den imitierten SIP-Proxy beim Angreifer. Dieser informiert das IP-Telefon von Alice mit dem SIP-Response 302 Moved Temporarily – in der Header-Zeile Contact – darüber, dass INVITE an den SIP-URI [email protected] übermittelt werden soll. Als Folge wird INVITE direkt an den Angreiferrechner mit der IPAdresse 192.168.1.4 übermittelt und somit die VoIP-Session zwischen IP-Telefon von Alice und dem Angreiferrechner aufgebaut. Der Angreifer kann sich nun als Bob ausgeben. Enthält INVITE in der Header-Zeile From den Namen Alice, wie z.B. From Alice <sip:[email protected]>, kann der Angreiferrechner sie sogar mit ihrem Namen – z.B. „Liebe Alice ...“ – ansprechen.
Session Hijacking
474
11 VoIP-Sicherheit
11.3.2 SIP Digest Authentication – Einsatz und Konzept Ziele von SIP-Digest
SIP-Digest wird hauptsächlich verwendet, um die Authentizität des Absenders eines SIP-Request REGISTER beim Registrieren bzw. eines SIP-Request INVITE beim Initiieren einer Session zu überprüfen – also um die Identität eines Benutzers festzustellen. Daher spricht man von der Authentifizierung eines Benutzers oder von der Authentifizierung der Herkunft eines SIP-Request. Mit SIP-Digest besteht auch die Möglichkeit, die Integrität eines Request zu überprüfen, um unbefugte Manipulationen entdecken zu können. Mit SIP-Digest kann man einige böswillige Angriffe auf VoIP-Systeme mit SIP bekämpfen, wie z.B. Registration Hijacking oder Session Spoofing.
Allgemeines über SIPDigest
SIP-Digest funktioniert nach dem gleichen Prinzip wie das in RFC 2617 spezifizierte Verfahren HTTP Digest Authentication, das zur Authentifizierung von Benutzern beim Zugriff auf einen Web-Server z.B. mit kostenpflichtigen Inhalten verwendet wird. Bei SIP-Digest unterscheidet man in der Regel zwischen Authentifizierer und Benutzer. Ein Authentifizierer stellt eine Systemkomponente wie z.B. SIP-Registrar und SIP-Proxy dar, dessen Aufgabe u.a. darin besteht, die Identität des Benutzers zu überprüfen. SIP-Digest ist ein Verfahren nicht nur zur Authentifizierung eines Benutzers durch einen Authentifizierer, sondern auch zur Authentifizierung eines Benutzers durch einen anderen Benutzer. Daher spricht man von Benutzer-Benutzer-, Benutzer-Proxy-, oder Benutzer-Registrar-Authentifizierung. Die Authentifizierungsvariante „Benutzer-Benutzer“ ist zwar möglich, wird allerdings in der Praxis in VoIP-Systemen mit SIP kaum verwendet.
Prinzip von Shared Secret
Ein Benutzer verfügt normalerweise über ein geheimes Passwort, mit dem er sich gegenüber dem Authentifizierer ausweisen kann. Somit muss dem Authentifizierer das Passwort eines Benutzers, der berechtigt ist, bestimmte Dienste in Anspruch zu nehmen, bekannt sein. Weil das Passwort ein Geheimnis ist, das nur Benutzer und Authenfizierer kennen, spricht man in diesem Fall von Shared Secret (geteiltes Geheimnis). Dem SIP-Digest liegt das Prinzip von Shared Secret zugrunde. Hervorzuheben ist aber, dass das Password eines Benutzers zwischen ihm und dem Authentifizierer nie im Klartext übermittelt wird, sondern aus diesem und weiteren Angaben des Benutzers eine Hashfunktion – bei SIP-Digest in der Regel MD5 (Message Digest, s. RFC 1321) – berechnet und nur der Hashwert (als Wert dieser Hashfunktion) übermittelt wird.1
www.wiwobooks.com
SIP-Digest bietet zwei Sicherheitsstufen – als Quality of Protection (qop) bezeichnet – an: auth – nur eine Authentifizierung ohne Überprüfung der Integrität auth-int – eine Authentifizierung mit Überprüfung der Integrität des Body-Teils des bei der Authentifizierung übermittelten SIP-Request
Die geforderte Sicherheitsstufe wird mit Hilfe des Parameters qop angegeben.
Prinzip der Authentifizierung nach SIP-Digest Das allgemeine Prinzip von SIP-Digest bei der Realisierung der Sicherheitsstufe auth illustriert Abbildung 11.3-6. Der Verlauf einer Authentifizierung nach SIP-Digest kann hier wie folgt zusammengefasst werden: Der Rechner des Benutzers sendet an einen Authentifizierer einen SIPRequest, z.B. INVITE bzw. REGISTER. Stellt dieser fest, dass der Benutzer noch nicht authentifiziert ist – d.h. Authentizität von ihm also noch nicht überprüft wurde, generiert er eine nonce2, 1
2
Es handelt sich hier um eine Hashfunktion, die eine sog. Einwegfunktion ist; d.h., dass es mit vertretbarem Rechenaufwand nicht möglich ist, anhand des Hashwertes eine Zeichenfolge zu finden, aus der der Hashwert berechnet wurde. Nonce – als Abkürzung für “used only once” oder „number used once“ – stellt eine zufällige Zahlen- und Buchstabenkombination dar, die nach einmaliger Verwendung verworfen wird.
11.3 Sicherheit bei VoIP mit SIP
475
die eine Zufallsfolge darstellt, und antwortet auf den Request mit dem SIP-Response 401 Unauthorized, dessen Header-Feld WWW-Authenticate u.a. die nonce an den Benutzerrechner übermittelt. B e n u tz e r A
C
R E G IS T E R , IN V IT E o d e r B Y E R e q u e st
A u th e n tifiz ie re r
S I P - R e g is tr a r ,- P r o x y , ...
G e n e rie rt e in e n o n c e 4 0 1 U n a u th o riz e d [W W W -A u th e n tic a te : D ig e s t r e a lm , q o p , n o n c e , o p a q u e ] B A C K B e re c h n e t re sp o n se = H (u s n , r e a lm , p a s s w d , n o n c e , m e th o d , S I P -U R I ] R e q u e s t [A u th o r iz a tio n : D ig e s t u s n , r e a lm , n o n c e , S I P -U R I , q o p = a u th , c n o n c e , r e s p o n s e , o p a q u e ] H : H a s h fu n k tio n u sn : u se rn a m e p a ssw d : p a ssw o rd
B e re c h n e t H (u s n , r e a lm , p a s s w d , n o n c e , m e th o d , U R I ] u n d v e rg le ic h t m it e m p fa n g e n e r r e s p o n s e 2 0 0 O K [A u th e n tic a tio n -I n fo : n e x tn o n c e ]
D
Abb. 11.3-6: Prinzip der Authentifizierung nach SIP-Digest – d.h. qop=auth Nach dem Eintreffen von 401 Unauthorized am Rechner des Benutzers wird bei diesem auf die empfangene nonce und weitere Angaben die im Verfahren festgelegte Hashfunktion H angewandt. Der Wert der Hashfunktion H stellt response dar und wird – zusammen mit weiteren Angaben im Header Authorization – im erneut gesendeten SIP-Request an den Authentifizierer übergeben. Dort wird response mit dem vom Authentifizierer durch die Berechnung der gleichen Hashfunktion H erzielten Ergebnis verglichen. Sind beide Ergebnisse identisch, war die Authentifizierung erfolgreich. Dies wird dem Benutzer in SIP-Response 200 OK bestätigt.
www.wiwobooks.com
Wie Abbildung 11.3-6 zeigt, verläuft die SIP-Digest-Authentifizierung in folgenden Schritten: A
Ein Benutzerrechner sendet an einen Authentifizierer, der als SIP-Proxy bzw. als SIP-Registrar fungiert, einen SIP-Request INVITE, REGISTER oder BYE.
B Der Authentifizierer antwortet mit dem Response 401 Unauthorized und übermittelt in seinem Header-Feld WWW-Authenticate an den Rechner des Benutzers folgende Angaben: nonce – als Zufallsvariable, die zur Berechnung von response seitens des Benutzers • dienen soll. Diese stellt eine base64- oder hexadezimal-codierte Zeichenfolge dar. • realm – gibt die DNS-Domain an, in der die Authentifizierung gültig ist. • qop (quality of protection), optional – als qop kann man die Sicherheitsstufe auth (authentication) oder auth-int (authentication with integrity protection) angeben. Der Unterschied zwischen auth und auth-int besteht nur in der Hashfunktion H zur Berechnung der response. opaque – eine Zeichenkette (hexadezimale bzw. im Format base64), die der Rechner • des Benutzers – ohne Änderung – an den Authentifizierer zurücksenden muss. Dieser kann opaque zum Identifizieren des Authentifizierungszustands verwenden. C
Der Benutzerrechner berechnet response und sendet an den Authentifizierer einen neuen SIP-Request mit response und weiteren Angaben wie usernane, realm, nonce, SIPURI, qop, cnonce und opaque im Header Authorization. Seitens des Benutzers erfolgen folgende Angaben: Benutzername (usernane), seine SIP-Adresse (SIP-URI), die von ihm erzeugte Nonce – die sog. client nonce (cnonce) – und der Parameter nc (nonce-count).
Schritte bei SIP-Digest
476
11 VoIP-Sicherheit Mit nc werden wiederholt gesendete SIP-Requests identifiziert. nonce und opaque werden von dem empfangenen SIP-Response 401 Unauthorized übernommen. War die Authentifizierung erfolgreich, wird das dem Benutzerrechner mit 200 OK mitgeteilt. Gleichzeitig wird ihm im Header Authentication-Info eine neue Nonce (nextnonce) übermittelt, sodass er bei der nächsten Authentifizierung an den Authentifizierer einen SIP-Request bereits mit der von ihm berechneten response übermitteln kann.
D
SIP-Digest zusammengefasst
Für die Übermittlung von für die Authentifizierung notwendigen Angaben werden in SIP-Nachrichten die Header-Felder WWW-Authenticate, Authorization und Authentication-Info wie folgt verwendet (s. Abb. 11.3-6): Zuerst übermittelt der Authentifizierer dem Benutzerrechner seine nonce in WWW-Authenticate. Dieser berechnet auf ihrer Basis response und übergibt diese dem Authentifizierer in Authorization, damit er sie mit der von ihm berechneten vergleichen kann, um zu entscheiden, ob der überprüfte Benutzer dem entspricht, der er zu sein vorgibt. Nach erfolgreicher Authentifizierung wird dem Benutzerrechner AuthenticationInfo übermittelt. Dieses Schema liegt allen Varianten der Authentifizierung nach SIP-Digest zugrunde.
Authentifizierung bei Registrierung Nachdem in Abbildung 11.3-6 das allgemeine Prinzip der SIP-Digest-Authentifizierung erläutert wurde, zeigt Abbildung 11.3-7 den Einsatz von SIP-Digest bei einer Registrierung. Hier überprüft ein SIP-Registrar die Authentizität eines Benutzers, um einem eventuellen böswilligen Angriff – wie z.B. der Entführung einer Registrierung (Registration Hijacking) – entgegenzuwirken.
www.wiwobooks.com
A
B o b
C
R e g is tra r R E G I S T E R s ip :r e g is tr a r .x y z .d e S I P /2 .0 x y z .d e ... C S e q : 1 2 3 S I P /2 .0 4 0 1 U n a u t h o r iz e d ..... ... W W W - A u t h e n t ic a t e : D ig e s t r e a lm = " x y z .d e " , q o p = a u th , n o n c e = " v c 9 c 8 e 8 8 d f8 4 f1 c e c 4 3 4 1 a e 6 c b e 5 a 3 1 2 " , o p a q u e = " 5 c c c 0 6 9 c 4 0 3 e b a f9 f0 1 7 1 e 9 5 1 7 f4 0 e 4 1 " ... R E G I S T E R s ip :r e g is tr a r .x y z .d e S I P /2 .0 ... C S e q : 1 2 4 A u t h o r iz a t io n : D ig e s t u s e r n a m e = " b o b " , r e a lm = " x y z .d e " n o n c e = " v c 9 c 8 e 8 8 d f 8 4 f 1 c e c 4 3 4 1 a e 6 c b e 5 a 3 1 2 " ,u r i= " s ip s : b o b @ x y z .d e " , q o p = a u th , n c = 0 0 0 0 0 0 0 1 , c n o n c e = " 0 a s 3 4 3 b 7 " ,r e s p o n s e = " d f e 5 6 1 3 1 d 1 9 5 8 0 4 6 6 8 9 d 8 3 3 0 6 4 7 7 e c c " , o p a q u e = " 5 c c c 0 6 9 c 4 0 3 e b a f9 f0 1 7 1 e 9 5 1 7 f4 0 e 4 1 " ... S I P /2 .0 2 0 0 O K ... A u th e n tic a tio n -I n fo : n e x tn o n c e = " v c 9 c 8 e 8 8 d f8 4 f1 c e c 4 3 4 1 a e 6 c b e 5 a 3 1 2 " ... B
D
Abb. 11.3-7: Verlauf der Authentifizierung bei einer Registrierung Wie in Abbildung 11.3-7 ersichtlich ist, antwortet der Registrar (als Authentifizierer) auf den SIP-Request REGISTER des Benutzers mit dem SIP-Response 401 Unauthorized, indem er ihm nonce übermittelt. Außerdem wird hier mit qop=auth informiert, dass lediglich eine Authentifizierung durchgeführt werden soll. Die Angabe qop=auth bestimmt aber auch die Hashfunktion zur Berechnung von response (s. RFC 2617). Mit realm=“xyz.de“ wird dem Benut-
11.3 Sicherheit bei VoIP mit SIP zer mitgeteilt, dass die Registrierung nur in der Domain xyz.de gültig ist. Die Angabe opaque – die als Markierung des Zustands des Authentifizierungsverlaufs im Registrar dient – muss der Benutzerrechner dem Registrar ohne Veränderung zurückschicken. Der Benutzerrechner berechnet den Wert von response und sendet diesen mit weiteren Angaben – die bereits in Abbildung 11.3-6 erläutert wurden – im erneut an den Registrar gesendeten SIP-Request REGISTER. Es ist hervorzuheben, dass die Sequenznummer CSeq in diesem SIPRequest REGISTER – im Vergleich zu CSeq im vorhergehenden REGISTER – um 1 erhöht wurde. Hat der Registrar response auf die gleiche Art und Weise berechnet, sein Ergebnis mit dem empfangenen Wert von response verglichen und festgestellt, dass die beiden Werte übereinstimmen, so ist die Authentifizierung erfolgreich. Dies wird dem Benutzer mit dem SIP-Response 200 OK mitgeteilt. Gleichzeitig wird ihm eine neue Nonce (als nextnonce bezeichnet) für eine eventuelle nächste Authentifizierung übergeben.
Benutzer-Authentifizierung von einem Proxy Am häufigsten wird SIP-Digest bei der Kommunikation zwischen einem Benutzerrechner und einem SIP-Proxy – wie in Abbildung 11.3-8 illustriert – eingesetzt. Im hier dargestellten Beispiel überprüft der SIP-Proxy der Domain abc.de die Identität des Benutzers Alice.
A A lic e
C
S IP -P ro x y e S I P /2 .0 .0 4 0 7 P r o x y A u t h e n t ic a t io n R e q u ir e d y - A u t h e n t ic a t e : ......]
a b c .d e
www.wiwobooks.com
I N V I T E s ip :b o b @ x y z .d S IP /2 [P r o x A C K I N V I T E s ip :b o b @ x y z .d e
B
IN V IT E s ip :b o b @ x y z .d e S I P /2 .0
S I P /2 .0 [ P r o x y - A u t h o r iz a t io n :....] 1 0 0 T ry in g 1 8 0 R in g in g
S I P /2 .0 2 0 0 O K [ P r o x y - A u t h e n t ic a t io n - I n f o : ......]
D
1 8 0 R in g in g 2 0 0 O K
Abb. 11.3-8: Benutzer-Proxy-Authentifizierung – Überprüfung der Authentizität beim Proxy Vergleicht man die Abbildungen 11.3-7 und -8, sind direkt folgende Unterschiede ersichtlich: Der Empfang des SIP-Response 407 Proxy Authentication Required kann seitens des Benutzerrechners mit dem SIP-Request ACK bestätigt werden. Bei der Benutzer-Proxy-Authentifizierung wird der erste SIP-Request ohne SIP-DigestAngaben seitens des Proxy nicht mit SIP-Response 401 Unauthorized beantwortet, sondern mit 407 Proxy Authentication Required. Damit wird zum Ausdruck gebracht, dass der Proxy eine Authentifizierung verlangt. Bei der Benutzer-Proxy-Authentifizierung werden die Header-Felder Authorization und Authentication-Info entsprechend als Proxy-Authorization und Proxy-Authentication-Info bezeichnet. Der Funktion nach unterscheiden sie sich aber nicht. Abgesehen vom eben erwähnten Unterschied bei der Bezeichnung von Header-Feldern verläuft die Benutzer-Proxy-Authentifizierung in Abbildung 11.3-8 nach dem gleichen und bereits in den Abbildungen 11.3-6 und -7 gezeigten Prinzip. Abbildung 11.3-8 zeigt insbesondere, in welchen SIP-Nachrichten die einzelnen Header-Felder WWW-Authenticate, Proxy-Authorization und Proxy-Authentication-Info während des Aufbaus einer Session übermittelt werden.
477
478
11 VoIP-Sicherheit
11.3.3 Einsatz von S/MIME bei SIP Idee von S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extension) – siehe hierzu RFC 3851 – stellt eine Erweiterung von MIME dar und ermöglicht die Realisierung von Sicherheitsmechanismen wie die Verschlüsselung einer Nachricht, Überprüfung der Nachrichtenintegrität und Authentifizierung (Signierung) der in einer Nachricht – wie z.B. einer E-Mail, einer SIP-Nachricht – eingekapselten Anhänge. Nach S/MIME können im Body-Teil einer SIP-Nachricht mehrere Dateien als sog. MIME-Objekte transportiert werden. Ein MIME-Objekt kann beispielsweise die vom Absender erzeugte Signatur derselben SIP-Nachricht darstellen, in der es transportiert wird. Ein anderes MIME-Objekt kann jene Teile einer SIP-Nachricht enthalten, aus denen die Signatur berechnet wurde. Eine Nachricht kann somit in sich mehrere MIME-Objekte transportieren, die kryptografisch so „verarbeitet“ wurden, dass wichtige Sicherheitsziele – wie z.B. die Überprüfung von Nachrichtenintegrität und -authentizität – erreichbar sind.
Bedeutung von S/MINE
Beim Einsatz von S/MIME handelt es sich um eine Ende-zu-Ende-Sicherheit, also um die Sicherheit zwischen zwei kommunizierenden SIP-Endeinrichtungen. Mit S/MIME lassen sich folgende Sicherheitsziele erreichen: Vertraulichkeit einiger Angaben in SIP-Nachrichten – Einige Header-Felder von SIP-Nachrichten, die in SIP-Zwischensystemen (Proxies) unterwegs nicht interpretiert werden müssen, können in ihrem Body-Teil verschlüsselt übermittelt werden. Der Body-Teil ist dann vom Typ envenloped-data – siehe Abbildung 11.3-12. Garantie der Integrität und Authentizität von SIP-Nachrichten – Beim Einsatz von S/MIME besteht auch die Möglichkeit zu verifizieren, ob der Header einer SIP-Nachricht während der Übermittlung bösartig verändert wurde; dies bedeutet, dass die Nachrichtenintegrität geprüft wird. Hierfür können SIP-Nachrichten seitens des Absenders so signiert werden, dass ihre Integrität (ihre Korrektheit) und Authentizität (ihre Abstammung) beim Empfänger überprüft werden kann. In diesem Fall ist der Body-Teil einer SIP-Nachricht vom Typ multipart/signed – siehe Abbildung 11.3-14.
www.wiwobooks.com
Asymmetrische Kryptosysteme als Grundlage von S/MINE S/MIME basiert auf PKCS#7
S/MIME (Secure MIME) verwendet das asymmetrische Kryptosystem nach dem Standard PKCS (Public Key Cryptography Standard) in der Version 7 – kurz PKCS#7 genannt. Bei der Nutzung von S/MIME haben demzufolge die im Body-Teil der SIP-Nachrichten eingebetteten Dateien die Endung *.p7m. Auf diese Weise wird auf PKCS#7 MIME verwiesen. Wie Abbildung 11.3-9 illustriert, zeichnet sich jedes asymmetrische Kryptosystem dadurch aus, dass jeder Benutzer dieses Systems ein Schlüsselpaar besitzt, das sich aus einem privaten, geheimen Schlüssel (secure Key, KS) und einem öffentlichen und nicht geheimen Schlüssel (public Key, KP) zusammensetzt. Bei der Nutzung eines asymmetrischen Kryptosystems kann eine zu sendende Nachricht sowohl mit dem privaten Schlüssel ihres Absenders als auch mit dem öffentlichen Schlüssel ihres Empfängers verschlüsselt werden.
Bedeutung von PKI
Bei der Nutzung eines asymmetrischen Kryptosystems müssen daher die öffentlichen Schlüssel in einer zugänglichen Datenbank ablegt werden, damit der Empfänger aus ihr den passenden Schlüssel abrufen kann, um eine mit dem privaten Schlüssel eines Absenders verschlüsselte Nachricht mit seinem öffentlichen Schlüssel entschlüsseln zu können (s. Abb. 11.3-9a). Außerdem muss der Empfänger einer mit dem privaten Schlüssel des Absenders verschlüsselten Nachricht sicher sein, dass der öffentliche Schlüssel, den er nutzt, um diese Nachricht zu entschlüsseln, der Schlüssel des authentischen Absenders ist. Man verwendet hierfür sog. Zertifikate von Benutzern, die in vertrauenswürdigen PKI-Systemen (Public Key Infrastructure) – bestehend aus einer Vernetzung sog. Trust Centers, auch Zertifizierungsstellen genannt – verwaltet werden. Weil das Zertifikat eines Benutzers u.a. seinen öffentlichen Schlüssel enthält (s. Abb. 11.3-9),
11.3 Sicherheit bei VoIP mit SIP
479
kann der Empfänger bei dem zuständigen, vertrauenswürdigen Trust Center überprüfen, ob der öffentliche Schlüssel dem Absender gehört, der er zu sein vorgibt. V e rs c h lü s s e lu n g
a )
K S
(A lic e )
T r u s t C e n te r x
T r u s t C e n te r y
Z e rtifik a t v o n A lic e
Z e rtifik a t v o n B o b
N a c h ric h t
K
(A lic e ) P
P :
K P
- 1
K
(B o b )
A
P u b lic K e y (ö ffe n tlic h e r S c h lü s s e l)
K
S :
N a c h ric h t
B o b
A
V e rs c h lü s s e lu n g K
E n ts c h lü s s e lu n g
A
P u b lic K e y In fra s tru c tu re
A lic e b )
v e r s c h lü s s e lt
A
N a c h ric h t
- 1
S
(B o b )
N a c h ric h t
E n ts c h lü s s e lu n g v e r s c h lü s s e lt S e c u re K e y (p riv a te r S c h lü s s e l) A : A lg o rith m u s
Abb. 11.3-9: Verschlüsselung einer Nachricht: a) mit dem privaten Schlüssel des Absenders, b) mit dem öffentlichen Schlüssel des Empfängers Bei der Nutzung eines asymmetrischen Kryptosystems ist auf Folgendes zu verweisen: Eine mit dem privaten Schlüssel eines Absenders verschlüsselte Nachricht kann nur mit seinem öffentlichen – und zu diesem privaten Schlüssel passenden – Schlüssel entschlüsselt werden. Abbildung 11.3-9a illustriert dies. Hier wurde die zu sendende Nachricht mit dem privaten Schlüssen von Alice verschlüsselt. Seitens Bob wird diese mit dem öffentlichen Schlüssel von Alice entschlüsselt. Diese Möglichkeit der Verschlüsselung nutzt man, um die zu sendenden Nachrichte zu signieren (s. Abbildung 11.3-13).
www.wiwobooks.com
Eine mit dem öffentlichen Schlüssel eines Empfängers verschlüsselte Nachricht kann nur mit seinem privaten – und zu diesem öffentlichen Schlüssel passenden – Schlüssel entschlüsselt werden. In Abbildung 11.3-9b wurde die Nachricht seitens Alice mit dem öffentlichen Schlüssel von Bob verschlüsselt, und er entschlüsselt diese mit seinem privaten Schlüssel (vgl. Abbildung 11.3-11).
Idee des S/MIME-Einsatzes bei SIP Das allgemeine Konzept des Einsatzes von S/MIME bei SIP illustriert Abbildung 11.3-10. Nach MIME können im Body-Teil einer SIP-Nachricht mehrere Dateien als sog. MIME-Objekte transportiert werden. Ein MIME-Objekt enthält einen kurzen Header, der die Besonderheiten des Objektinhalts näher beschreibt. S IP -P ro x y
A n ru fe r A lic e
B o d y d e r A u ß e n n a c h ric h t z .B . v e r s c h lü s s e lt
Abb. 11.3-10:
S IP -P ro x y
A n g e ru fe n e r D o m a in x y z .d e
D o m a in a b c .d e S IP -H
S IP -H
B o d y M IM E 1
Konzept des Einsatzes von S/MIME bei SIP
S ig n a tu r M IM E 2
B o b
Verschlüsselungsmöglichkeiten
480 MIMEObjekt
11 VoIP-Sicherheit Ein MIME-Objekt kann eine vollständige SIP-Nachricht oder auch nur einige ihrer Teile enthalten. Ein anderes MIME-Objekt kann die vom Absender berechnete Signatur dieser SIP-Nachricht darstellen. Falls eine Nachricht in sich mehrere MIME-Objekte transportiert, die kryptografisch so „verarbeitet“ wurden, dass man Sicherheitsziele – wie z.B. die Überprüfung der Nachrichtenintegrität und die Authentifizierung des Absenders – erreichen kann, spricht man von Secure MIME – also von S/MIME.
Garantie der Vertraulichkeit bei SIP mit S/MIME Abbildung 11.3-11 veranschaulicht das Prinzip der Garantierung der Vertraulichkeit einiger Angaben bei SIP mit Hilfe von S/MIME. Es handelt sich hier vor allem um das Verbergen der Identität eines Anrufers, die normalerweise aus diversen Header-Feldern der SIP-Nachricht – z.B. aus dem Header-Feld From – direkt erkennbar ist. A lic e
S IP -P ro x y
S IP -N a c h ric h t o u te r p a rt
B o d y
K P
B o b
in n e r p a rt K
(B o b )
V e rs c h lü s s e lu n g
S
(B o b )
B o d y
E n ts c h lü s s e lu n g
www.wiwobooks.com K
Abb. 11.3-11:
S
B o d y
: P riv a te r S c h lü s s e l - S e c u re K e y
K
P
: Ö ffe n tlic h e r S c h lü s s e l - P u b lic K e y
Einsatz von S/MIME zur Verschlüsselung einer SIP-Nachricht
Wie hier ersichtlich ist, verschlüsselt Alice einige Header-Felder der an Bob zu sendenden SIPNachricht mit seinem öffentlichen Schlüssel. Folglich kann Bob die so verschlüsselten Angaben nur mit seinem privaten (geheimen) – also nur ihm bekannten – Schlüssel entschlüsseln. Die verschlüsselten Teile der SIP-Nachricht bilden ein MIME-Objekt, und dieses wird als Content – d.h. als Body-Teil – der SIP-Nachricht übermittelt. Die Struktur dieser SIP-Nachricht illustriert Abbildung 11.3-12 näher. In n e n -S IP -H e a d e r
S IP -H A u ß e n -S IP -H e a d e r
B o d y = M IM E -O b je k t
S IP -H
B o d y
v e r s c h lü s s e lt C o n te n t-T y p e : m e s s a g e /s ip C o n te n t-T y p e : e n v e lo p e d -d a ta ; a p p lic a tio n /p k c s 7 -m im e
Abb. 11.3-12:
Struktur einer SIP-Nachricht mit dem Body als enveloped-data
Auf diese Weise dient eine SIP-Nachricht als Träger für sich selbst. Sie enthält zwei Teile, den Außenteil (outer part) und den Innenteil (inner part). Der Außenteil ist ein SIP-Header im Klartext – das heißt er ist nicht verschlüsselt –, sodass die SIP-Nachricht unterwegs von SIP-Proxies interpretiert und somit weitergeleitet werden kann. Der Innenteil ist hingegen ein MIME-Objekt in einer verschlüsselten Form.
11.3 Sicherheit bei VoIP mit SIP
481
Der Außen-SIP-Header steht im Klartext und enthält u.a. das Feld Content-Type, in dem der Inhalt des Body näher spezifiziert wird. enveloped-data verweist darauf, dass der Body eingekapselte Daten – beispielsweise eine verschlüsselte SIP-Nachricht wie in Abbildung 11.3-12 – enthält. Mit application/pkcs7-mime wird zum Ausdruck gebracht, dass es sich in diesem Fall um eine Anwendung des Standards PKCS#7 handelt. Besonders ist hervorzuheben, dass der Außen-SIP-Header alle Header-Felder, die in verschiedenen SIP-Zwischensystemen (insbesondere in SIP-Proxies) unterwegs interpretiert werden, um INVITE weiterleiten zu können, im Klartext – also nicht verschlüsselt – enthalten muss. Hierzu gehören die Header-Felder To, From, Call-ID, CSeq und Contact. Dagegen enthält der InnenSIP-Header, der verschlüsselt übertragen wird, sämtliche Header-Felder, die nicht in SIP-Zwischensystemen interpretiert werden.
Signierung von SIP-Nachrichten Um Verfälschungen übermittelter Nachrichten erkennen zu können, werden diese vor ihrer Übermittlung signiert. Abbildung 11.3-13 zeigt, wie auf der Empfangsseite die Signierung einer SIP-Nachricht und ihre Überprüfung mit Hilfe von S/MIME erfolgt. Insbesondere soll an dieser Stelle die zweiteilige Struktur vom Body der übermittelten Nachricht näher zum Ausdruck gebracht werden.
A b se n d e r
A lic e
www.wiwobooks.com S IP P ro x y
B o d y -T e il 1
W a s w u r d e s ig n ie r t?
B o d y -T e il 2
S ig n a tu r u n d ih r e B e s o n d e r h e ite n
B o d y
S S i I g G n - i Ae r l e g n
P r iv a te r S c h lü s s e l K
Abb. 11.3-13:
E m p fä n g e r
S IP -N a c h ric h t
S
(A lic e )
B o d y
v e rifiz ie re n S IG -A lg
d 6 a 5 e s c a d 8 y 9 1 v x g fsd s6 a sa 8 s c a c v g 3 a v g a 8 id
S IG -A lg : S ig n a tu r-A lg o rith m u s
B o b
B o d y
K P
(A lic e )
Ö ffe n tlic h e r S c h lü s s e l
Signierung einer SIP-Nachricht mit Hilfe von S/MIME
Um die Integrität einer SIP-Nachricht beim Empfänger überprüfen zu können, d.h. damit sich dort böswillige Veränderungen der Nachricht entdecken lassen, kann der Absender die ganze SIP-Nachricht oder nur einen ihrer Teile mit seinem privaten (geheimen) Schlüssel signieren. Die vom Absender erzeugte Signatur wird dann als Teil des Body der SIP-Nachricht übermittelt. Um dem Empfänger anzuzeigen, welcher Teil der SIP-Nachricht signiert wurde, wird dieser – bzw. die ganze SIP-Nachricht – als Teil des Body transportiert. Der Body-Teil 1 – siehe Abbildung 11.3-13 – gibt an, was signiert wurde, und der Body-Teil 2 enthält die Signatur mit einigen Angaben über ihre Eigenschaften. Im Header-Feld Content-Type der SIP-Nachricht muss einerseits darauf verwiesen werden, dass der Body mehrere Teile enthält – also multipart ist –, andererseits muss angezeigt werden, nach welchem Verfahren die Signatur berechnet wurde (s. Abb. 11.3-14). Trifft eine solche SIP-Nachricht beim Empfänger ein, erkennt er anhand des Header-Felds From den Absender Alice und anhand des Header-Felds Content-Type das zur Berechnung der Signatur angewandte Verfahren PKCS#7. Somit kann der Empfänger Bob die Signatur mit dem öf-
Felder im Außen-SIPHeader
482
11 VoIP-Sicherheit fentlichen Schlüssel des Absenders Alice entschlüsseln.3 Die entschlüsselte Signatur stellt in ihrer ursprünglichen Form die signierten Teile der SIP-Nachricht dar. Um welche es sich dabei handelt, zeigt der Body-Teil 1. Daraufhin kann der Empfänger die signierten und im Klartext übermittelten Teile der SIPNachricht mit der entschlüsselten Signatur vergleichen, um zu verifizieren, ob diese im Klartext übermittelten Teile der SIP-Nachricht verfälscht worden sind oder nicht. Stimmt die entschlüsselte Signatur mit den Nachrichtteilen überein, stellt der Empfänger fest, dass sie unverfälscht sind. Da die Signatur mit dem öffentlichen Schlüssel von Alice entschlüsselt werden konnte, stellt der Empfänger außerdem fest, dass die sie beinhaltende SIP-Nachricht von Alice stammt. So lassen sich sowohl die Integrität einer SIP-Nachricht als auch die Authentizität des Absenders überprüfen.
SIPNachricht mit mehreren MIMEObjekten
Nach MIME können auch SIP-Nachrichten mit mehreren Body-Teilen als MIME-Objekte nach dem Baukastenprinzip strukturiert werden. Abbildung 11.3-14 zeigt eine solche Strukturierung. B -N a m e
In n e re S IP -N a c h ric h t B o d y B o d y -T e il 1
S IP -H
S IP -H
B -N a m e
B -N a m e
B o d y -T e il 1
B o d y
S ig n a tu r
B : B o u n d a ry C -T : C o n te n t-T y p e
C -T : a p p lic a tio n /s d p C -T : a p p lic a tio n /p k c s 7 -s ig n a tu re C -T : m e s s a g e /s ip C -T : m u ltip a r t/s ig n e d ; P ro to c o l= " a p p lic a tio n /p k c s 7 -s ig n a tu re "
www.wiwobooks.com
Abb. 11.3-14:
Struktur einer SIP-Nachricht mit mehreren MIME-Teilen in ihrem Body
Enthält der Body einer SIP-Nachricht mehrere Teile, muss die Grenze zwischen ihnen entsprechend markiert werden. Hierfür wird eine als Boundary bezeichnete Markierung verwendet. Mit Boundary wird sowohl die Grenze zwischen den Body-Teilen als auch der Beginn und das Ende des Body einer SIP-Nachricht markiert.
SIPTunneling
Wie Abbildung 11.3-14 zeigt, kann in einem Teil die ganze SIP-Nachricht enthalten sein. Somit kann eine SIP-Nachricht z.B. sich selbst in verschlüsselter Form enthalten. In diesem Zusammenhang spricht man von SIP-Tunneling.
11.4 Ermittlung des Schutzbedarfs bei VoIP Die erste Phase bei der Planung der VoIP-Sicherheit ist die Ermittlung der Sicherheitsschwachstellen und der mit ihnen verbundenen Risiken (s. Abb. 11.1-6). Da eine Sicherheitsschwachstelle die Stelle repräsentiert, wo ein bestimmter Schutzbedarf besteht, kann die erste Phase bei der Planung der VoIP-Sicherheit als Phase der Ermittlung des Schutzbedarfs bezeichnet werden. Während dieser Phase können als potenzielle Bedrohungen alle Umstände, Möglichkeiten, Aktionen bzw. Ereignisse betrachtet werden, die zur Gefährdung der VoIP-Sicherheit führen können. Eine Bedrohungsart stellen auch Angriffe auf Netzwerke dar. Durch einen Angriff versucht ein Angreifer, die Sicherheit im Netzwerk zu unterwandern und eventuell einige Netzwerkres-
3
Neben der Signatur kann auch das Zertifikat des Absenders übermittelt werden, damit der Empfänger aus dem Zertifikat seinen öffentlichen Schlüssel entnehmen kann.
11.4 Ermittlung des Schutzbedarfs bei VoIP
483
sourcen zu seinem Vorteil auszunutzen. Die Ermittlung des Schutzbedarfs bei VoIP soll dazu führen, alle Sicherheitsschwachstellen als Sicherheitslücken im Netzwerk zu identifizieren. Bei der Analyse des Schutzbedarfs geht es daher um folgende Fragestellungen:
Worum es sich handelt
Welche Sicherheitsschwachstellen können beim VoIP-Einsatz entstehen? Welche Bedrohungen führen zur Entstehung einzelner Sicherheitsschwachstellen? Um diese Frage zu beantworten, ist eine Bedrohungsanalyse nötig. Welche Risiken sind mit den einzelnen Sicherheitsschwachstellen verbunden? Diese Frage kann nur nach einer Risikoanalyse beantwortet werden. Um auf diese Fragestellungen genauer eingehen zu können, wird zuerst in Abschnitt 11.4.1 ein Modell einer Sicherheitsschwachstelle eingeführt. Der Bedrohungsanalyse ist Abschnitt 11.4.2 gewidmet. Nach der Einführung von Schadensstufen in Abschnitt 11.4.3 wird in Abschnitt 11.4.4 gezeigt, wie man eine Risikoanalyse durchführt. Abschließend zeigt Abschnitt 11.4.5, wie der Schutzbedarf in einem Netzwerk erfasst werden kann.
11.4.1 Beschreibung der Sicherheitsschwachstelle Das Ziel eines Konzepts für die VoIP-Sicherheit ist die Beseitigung aller Schwachstellen, die zu Unsicherheiten beim Einsatz von VoIP führen könnten. Um dieses Ziel zu erreichen, muss zunächst eine Ist-Analyse der Sicherheitslage für die betroffenen Netzwerkbereiche durchgeführt werden. Dabei werden alle Sicherheitsschwachstellen erfasst und der Schutzbedarf ermittelt. Hierfür benötigt man jedoch ein Modell, wie eine Sicherheitsschwachstelle spezifiziert werden kann. Abbildung 11.4-1 zeigt ein solches Modell.
www.wiwobooks.com S c h u tz b e d a r f?
S ic h e r h e its p r o b le m b e r e ic h x
B e d r o h u n g (e n ) Id e n tifik a tio n , L e its a tz
F o lg e n ?
S ic h e r h e its s c h w a c h s te lle
...
D e n k b a r e M a ß n a h m e n
S ic h e r h e its r is ik e n
S c h a d e n ?
V e r lu s t d e r : V e rtra u lic h k e it In te g ritä t A u th e n tiz itä t V e rfü g b a rk e it S c h a d e n s s tu fe : se h r h o c h h o c h n ie d rig b is m itte l
Abb. 11.4-1: Modell einer Sicherheitsschwachstelle für die Schutzbedarfsermittlung Jeder Sicherheitsschwachstelle sollten eine eindeutige Identifikation und ein zutreffender Name zugeordnet und darüber hinaus folgende Angaben gemacht werden:
Angaben zu SicherheitsBedrohung(en), die zur Schwachstelle führen können. schwachSicherheitsrisiken, die als Folge der Sicherheitsschwachstelle entstehen können. Bei der Ri- stelle
sikoanalyse muss abgeschätzt werden, zu welchen Folgen (z.B. Vertraulichkeitsverlust, Verfügbarkeitsminderung) die Sicherheitsschwachstelle führen kann und wie hoch der Schutzbedarf ist. Dieser kann durch die Höhe von potenziellem Schaden bzw. durch ihre Einstufung zum Ausdruck gebracht werden. Darauf geht Abschnitt 11.4.3 näher ein. Denkbare Lösungsansätze mit Hardware- und Software-Komponenten bzw. bestimmte Sicherheitsmaßnahmen, mit deren Hilfe die Sicherheitsschwachstelle behoben werden kann.
484
11 VoIP-Sicherheit Beispiel: Sicherheitsschwachstelle: VoIP-Server Name: VoIP-Server Bedrohungen: Schadensprogramme (Viren, Würmer, Backdoors, Trojaner, Exploits), Port Scanning, unautorisierte Zugriffe, ... Risiken, Folgen: Verlust der Vertraulichkeit, Integrität und Verfügbarkeit Schaden: sehr hoch Lösungsansätze: Virenscanner, Firewalls zur Überwachung von TCP- und UDPPorts, Zugriff nur für autorisierte Netzwerkadministratoren, ... Typische Sicherheitsschwachstellen werden in Abschnitt 11.6.2 beschrieben. Die Spezifikation von Sicherheitsschwachstellen aus einem Sicherheitsproblembereich (s. Abb. 11.1-3) kann in tabellarischer Form dargestellt werden. Darauf geht Abschnitt 11.4.5 näher ein.
11.4.2 Vorgehensweise bei der Analyse von Bedrohungen Bevor man mit der Erfassung des Schutzbedarfs beginnt, sollte man eine Analyse möglicher Bedrohungen durchführen. Unter einer Bedrohung in einem Netzwerk versteht man jede mögliche unberechtigte Aktion sowohl von innen als auch von außen, mit der absichtlich oder unabsichtlich die Sicherheit bzw. Funktionalität im Netzwerk negativ beeinflusst werden kann. Für jedes sicherheitsrelevante System bzw. für jede sicherheitsrelevante Applikation sollte jede mögliche organisatorische, technische und benutzerbedingte Ursache untersucht werden, die eine Bedrohung für die VoIP-Sicherheit darstellen und Schaden hervorrufen könnte.
Spezifikation einer Bedrohung
www.wiwobooks.com
Wie Abbildung 11.4-2 zum Ausdruck bringt, sind folgende Angaben bei der Spezifikation der Bedrohung für die VoIP-Sicherheit erforderlich: Wer ist der Verursacher der Bedrohung?
Durch welches böswillige Ziel entsteht die Bedrohung? Wie häufig kann die Bedrohung auftreten?
B e d r o h u n g s m a tr ix E x te rn e r A S c h a d e n s p ro In te rn e r B E x te rn e r B
n g re g ra m e n u e n u
if m tz tz
e r e e r e r
L a u s A b fa D ie n D ie n
c h n g s t s t
e n u n e n u n b e e in m is s b
d A d M trä c ra u
b h ö re n o d ifiz ie re n h tig e n c h e n
b ö s w illig e s Z ie l V e ru rs a c h e r
B e d r o h u n g
h ä u fig ö fte r s e lte n s e h r s e lte n H ä u fig k e it
Abb. 11.4-2: Angaben bei der Spezifikation einer Bedrohung im Netzwerkbereich mit VoIP
Ursprünge von Bedrohungen
Um angemessene Maßnahmen gegen eine Bedrohung entwickeln zu können, muss man wissen, wer diese verursachen kann. Verursacher können externe Angreifer, ein Schadensprogramm oder ein Benutzer (d.h. ein eigener Mitarbeiter) sein. Beim Benutzer kann es sich sowohl um einen internen Benutzer handeln, der auf bestimmte Netzwerkdienste lokal zugreift, als auch um einen externen Benutzer, der auf bestimmte Netzwerkdienste – oft über das Internet – zugreifen darf.
böswillige Ziele
Die böswilligen Ziele von Angriffen auf VoIP-Systeme lassen sich in den folgenden vier Gruppen zusammenfassen (s. Abschnitt 11.2.2 und Abbildung 11.2-3):
11.4 Ermittlung des Schutzbedarfs bei VoIP
485
Lauschen und Abhören: Ein Angriff kann mit dem Ziel vorgenommen werden, im Netzwerk zu lauschen, um wichtige Daten bzw. Passwörter auszuspionieren. Das ist ein passiver Angriff, mit dem keine Veränderungen von Konfigurationsparametern durchgeführt werden. Mit Lauschangriffen ist beim VoIP-Einsatz zu rechnen. Ziele eines solchen Angriffs können das Abhören von Telefonaten, übertragener Daten und insbesondere von Signalisierungsdaten beim Auf- und Abbau von VoIP-Verbindungen sein. Abfangen und Modifizieren: Oft werden verschiedene aktive Angriffe auf VoIP-Systeme mit dem Ziel durchgeführt, die Signalisierungsdaten beim Aufbau von VoIP-Verbindungen abzufangen und einige Angaben, wie z.B. Quell- bzw. Zieladresse, böswillig zu modifizieren. So erfolgen Angriffe wie Spoofing bzw. Hijacking. VoIP-Dienst beeinträchtigen: Ein Angriff kann vorgenommen werden, um ein VoIP-System und damit auch den VoIP-Dienst gezielt negativ zu beeinträchtigen. Hierzu gehören verschiedene DoS-Angriffe, um wichtige Systemkomponenten lahmzulegen. Missbrauchen des VoIP-Dienstes: Es können Angriffe auf VoIP-Systeme vorgenommen werden, um diese zu missbrauchen – z.B. Versuch, auf fremde Kosten zu telefonieren. Abbildung 11.4-3 zeigt typische Sicherheitsbedrohungen, ihre Verursacher und ihre Folgen. A b h ö r M a n ip D o S -A S y s te m
e x te rn e A g re ife r
B e d ro h u n g e n d u rc h :
S c h a d e n sp ro g ra m m e
e n u la n g b e
d e r e x tio n v riffe = e in trä
te o n > c h
rn e n T S ig n a V d V e tig u n g
e le fo n g e s p rä c h e = > V d V e r tr lis ie ru n g s d a te n = > V d V e r tr , V d A u th e n r fü g d u rc h S P IT = > V d V e r fü g
www.wiwobooks.com
in te rn e B e n u tz e r e x te rn e B e n u tz e r
V ir e n , W ü r m e r , T r o ja n e r , B a c k d o o r s , ... = > V d I n te g , V d V e r fü g A b h ö re n d e r in te rn e n T e le fo M a n ip u la tio n v o n S ig n a lis ie U n e rla u b te Ü b e rn a h m e v o n M a n ip u la tio n v o n S ig n a lis ie U n e rla u b te r Z u g riff a u f d e n S y s te m m is s b ra u c h , G e b ü h re
n g e sp rä c h e = > ru n g s d a te n = > A n ru fe n = > V d ru n g s d a te n = > V o IP -S e rv e r = n b e tru g = > V d
V d V d V e V d
V e r tr V e r tr , V d A u th e n r tr , V d In te g , V d A u th e n V e r tr , V d In te g > V d V e r tr , V d In te g In te g , V d A u th e n
V d In te g : V e rlu s t d e r In te g ritä t, V d V e rtr: V e rlu s t d e r V e rtra u lic h k e it V d A u th e n : V e rlu s t d e r A u th e n tiz itä t, V d V e rfü g : V e rlu s t d e r V e rfü g b a rk e it
Abb. 11.4-3: Typische Bedrohungen durch verschiedene Verursacher Mit jeder Bedrohung sind bestimmte negative Folgen als Sicherheitsrisiken verbunden. Es gibt folgende Arten von Sicherheitsrisiken:
Folgen von Bedrohungen
Verlust der Vertraulichkeit, Verlust der Integrität – von Signalisierungsdaten bzw. von VoIP-Systemkomponenten, Verlust der Authentizität – von Signalisierungsdaten bzw. des Anrufenden, Verlust der Verfügbarkeit – eines Systems bzw. einer Applikation. Da jede Bedrohung von einem Verursacher als Quelle stammt und durch sein böswilliges Ziel hervorgerufen wird, lässt sich eine Bedrohungsmatrix erstellen, aus der alle möglichen Kombinationen von Bedrohungen direkt ersichtlich sind. Abbildung 11.4-4 illustriert die Bedrohungsmatrix für die VoIP-Sicherheit. In dieser Matrix repräsentieren die Zeilen die potenziellen Auslöser und die Spalten die von ihnen verfolgten böswilligen Ziele.
Bedrohungsmatrix
Jedes Feld in der Bedrohungsmatrix stellt einen Bedrohungstyp dar. Beispielsweise handelt es sich bei den Bedrohungen vom Typ (1,1) um alle Bedrohungen, die externe Angreifer mit dem Ziel, zu lauschen bzw. abzuhören, verursachen können. Diese Bedrohungen führen zum Verlust
Bedrohungstyp
486
11 VoIP-Sicherheit der Vertraulichkeit. Die Bedrohungen vom Typ (1,4) können externe Angreifer durch SPIT bzw. einen Gebührenbetrug verursachen, was zum Verlust der Integrität, Authentizität sowie der Verfügbarkeit von Systemkomponenten führen kann. L a u sc h e n , A b h ö re n T y p ( 1 ,1 )
A b fa n g e n u n d M o d ifik a tio n T y p ( 1 ,2 )
D ie n s tD ie n s t4 m is s b ra u c h 3 b e e in trä c h tig u n g T y p ( 1 ,4 ) T y p ( 1 ,3 )
V .d . V e r tr a u lic h k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
T y p ( 2 ,1 )
T y p ( 2 ,2 )
T y p ( 2 ,3 )
T y p ( 2 ,4 )
V .d . I n te g r itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . V e r f ü g b a r k e it
1
1 E x te rn e r A n g re ife r 2 S c h a d e n sp ro g ra m m e
V .d . I n te g r itä t V .d . V e r f ü g b a r k e it
V .d . V e r tr a u lic h k e it
T y p ( 3 ,2 )
T y p ( 3 ,3 )
T y p ( 3 ,4 )
V .d . V e r tr a u lic h k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
T y p ( 4 ,1 )
T y p ( 4 ,2 )
T y p ( 4 ,3 )
T y p ( 4 ,4 )
3 In te rn e r B e n u tz e r
T y p ( 3 ,1 )
4 E x te rn e r B e n u tz e r
2
V .d . V e r tr a u lic h k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
V .d . I n te g r itä t V .d . A u th e n tiz itä t V .d . V e r f ü g b a r k e it
www.wiwobooks.com
Abb. 11.4-4: Typen von Bedrohungen für die VoIP-Sicherheit und mögliche Folgen als Verluste der (V.d.) Vertraulichkeit, Integrität, Authentizität oder Verfügbarkeit Eine Auflistung der möglichen böswilligen Ziele und Angriffsarten, die den einzelnen Bedrohungstypen zugeordnet werden können, zeigt Tabelle 11.4-1. Ziel Angreifer Externer Angreifer Schadensprogramme Interner Benutzer
Externer Benutzer
Lauschangriff
Abfangen und Modifikation
Typ (1,1): MitM-Angriffe Call Hijacking Spoofing Abhören Typ (2,1): Backdoors Trojaner
Typ (1,2): MitM-Angriffe Call Hijacking Spoofing Pharming Typ (2,2): Backdoors
Typ (3,1): MitM-Angriffe Call Hijacking Spoofing Abhören
Typ (3,2): MitM-Angriffe Call Hijacking Spoofing Pharming Sabotage Typ (4,2): MitM-Angriffe Call Hijacking Spoofing Pharming
Typ (4,1): MitM-Angriffe Call Hijacking Spoofing Abhören
Dienstbeeinträchtigung
Dienstmissbrauch
Typ (1,3): DoS-Angriffe Bombing Clipping
Typ (1,4): Call/Toll Fraud SPIT
Typ (2,3): Viren, Trojaner, Würmer, Backdoors, Exploits Typ (3,3): DoS-Angriffe Bombing Clipping Sabotage
Typ (2,4): Backdoors Trojaner
Typ (4,3): DoS-Angriffe Bombing Clipping
Typ (4,4): Call/Toll Fraud SPIT
Typ (3,4): Call/Toll Fraud SPIT
Tab. 11.4-1: Bedrohungen durch verschiedene Angreifer und deren Angriffe MitM: Man in the Middle; für die Erklärung der Begriffe sei auf Abschnitt 11.2 verwiesen.
487
11.4 Ermittlung des Schutzbedarfs bei VoIP Um den Grad der Gefährdung durch eine Bedrohung einschätzen zu können, muss man beurteilen, wie häufig diese Bedrohung eintreten kann. In diesem Zusammenhang wird oft von der Wahrscheinlichkeit des Eintretens der Bedrohung gesprochen. Weil sie sich mathematisch gesehen nicht abschätzen lässt, sollten in der Praxis für die Schätzung der Häufigkeit des Eintretens einer Bedrohung bestimmte Häufigkeitsstufen definiert werden. Darauf geht Abschnitt 11.4.4 näher ein.
Häufigkeit einer Bedrohung
11.4.3 Aussage über den Schutzbedarf Ziel der Ermittlung des Schutzbedarfs ist es, für jede potenzielle Sicherheitsschwachstelle festzustellen, wie wichtig es ist, sie zu beheben und sich gegen den Verlust der Vertraulichkeit, der Integrität, der Authentizität und der Verfügbarkeit zu schützen. Der Schutzbedarf orientiert sich an dem potenziellen Schaden, der mit der Sicherheitsschwachstelle verbunden ist. Weil der Schutzbedarf nicht in Form eines Wertes angegeben werden kann, beschränkt man sich in der Praxis auf eine qualitative Aussage durch die Einführung von Schutzbedarfsstufen. Tabelle 11.4-2 zeigt typische Schutzbedarfsstufen. Schutzbedarfsstufe niedrig bis mittel hoch sehr hoch
Bedeutung der Schutzbedarfsanalyse
Schadensauswirkungen begrenzt und überschaubar potenziell beträchtlich potenziell bedrohlich bis katastrophal
www.wiwobooks.com
Tab. 11.4-2: Schadensstufen in Anlehnung an IT-Grundschutzhandbuch des BSI (s. [BSI 03]) Bei der Analyse des Schutzbedarfs sollte man – unabhängig von bereits getroffenen Maßnahmen – vom schlimmsten Fall, d.h. von einem maximal möglichen Schadensumfang, ausgehen. Dies bedeutet, dass die Analyse des Schutzbedarfs als Worst-Case-Analyse angesehen werden sollte.
Schadensarten
Die Schadensfälle lassen sich folgenden Arten zuordnen: Verstoß gegen Gesetze/Vorschriften/Verträge, Beeinträchtigung des informationellen Selbstbestimmungsrechts, Beeinträchtigung der persönlichen Unversehrtheit, Beeinträchtigung der Aufgabenerfüllung, negative Außenwirkungen und finanzielle Verluste. Häufig verursacht ein Angriff gleichzeitig mehrere Arten von Schäden. Ein Ausfall des VoIPServers kann z.B. die Aufgabenerfüllung beeinträchtigen, was direkte finanzielle Einbußen nach sich zieht, und gleichzeitig zu einer negativen Außenwirkung (Imageverlust) führen. Nach der Analyse des Schutzbedarfs für alle potenziellen Sicherheitsschwachstellen werden im nächsten Schritt – während der Risikoanalyse – die Folgen von Bedrohungen untersucht.
11.4.4 Risikoanalyse Unter dem Begriff Risiko versteht man ein Maß für die von einer Bedrohung ausgehende Gefährdung. Das Risiko bestimmen die folgenden Komponenten: die Häufigkeit des Eintretens der Bedrohung und die Höhe von Schäden, die als Folge des Eintretens der Bedrohung entstehen können.
Begriff: Risiko
488
11 VoIP-Sicherheit Risikoanalyse bezeichnet eine Abschätzung aller Risiken, die als Folge aller möglichen Bedrohungen entstehen können. Die Risikoanalyse soll erst nach der Erfassung aller potenziellen Sicherheitsschwachstellen und der Bewertung des Schutzbedarfs beginnen, da man bei der Risikoanalyse, falls dies überhaupt möglich ist, auch die Einschätzung möglicher Motive eines Angreifers bzw. bestimmte Angriffsmodelle berücksichtigen sollte. Für jede Sicherheitsschwachstelle mit der Schutzbedarfsstufe hoch und sehr hoch (s. Tab.11.4-2) sollte eine eigene Risikoanalyse durchgeführt werden.
Risikoabschätzung
Das Risiko aus einer Bedrohung wird durch die Schadenshöhe und die relative Häufigkeit des Eintretens der Bedrohung abgeschätzt, d.h.: Risiko = Schadenshöhe • (relative Häufigkeit) Die relative Häufigkeit der Bedrohung stellt ein Maß für die Wahrscheinlichkeit des Eintretens der Bedrohung dar. Mathematisch ausgedrückt, ist das Risiko der Erwartungswert für Schaden in einem Beobachtungszeitraum. Als Zeitraum kann man die Lebenszeit dieser Systemkomponente im Netzwerk annehmen, mit der die betreffende Sicherheitsschwachstelle zusammenhängt.
Häufigkeitsstufen von Bedrohungen
Um ein Risiko abschätzen zu können, muss zunächst bewertet werden, mit welcher Wahrscheinlichkeit das Eintreten einer Bedrohung zu erwarten ist. Hierfür muss die relative Häufigkeit des Eintretens der Bedrohung als Maß für diese Wahrscheinlichkeit geschätzt werden. Dies ist aber in Form eines Wertes wiederum nicht möglich. In der Praxis kann die Häufigkeit des Eintretens der Bedrohung nur einer Häufigkeitsstufe zugeordnet werden. Tabelle 11.4-3 zeigt einen Vorschlag für die Häufigkeitsstufen von Bedrohungen.
www.wiwobooks.com Häufigkeitsstufen sehr häufig häufig öfter selten
Wahrscheinlichkeit sehr hoch hoch mittel niedrig
Bedrohung kann auftreten: alle paar Tage alle paar Wochen alle paar Monate alle paar Jahre
Tab. 11.4-3: Häufigkeitsstufen von Bedrohungen
Grobeinstufung von Risiken
Auf der Basis der in Tabelle 11.4-2 aufgelisteten Schutzbedarfsstufen und der in Tabelle 11.4-3 eingeführten Häufigkeitsstufen von Bedrohungen kann eine grobe Einstufung von Risiken vorgenommen werden. Abbildung 11.4-5 zeigt einen Vorschlag für eine derartige Grobeinstufung von Risiken. S c h u tz b e d a r fs s tu fe se h r h o c h h o c h
n ie d rig b is m itte l
u n tr a g b a r e R is ik e n h o h e s R is ik o
h o h e s R is ik o
h o h e s R is ik o
h o h e s R is ik o
m ittle re s R is ik o
h o h e s R is ik o
h o h e s R is ik o
h o h e s R is ik o
n ie d rig e s R is ik o
n ie d rig e s R is ik o
m ittle re s R is ik o
m ittle re s R is ik o
H ä u fig k e its s tu fe
tr a g b a r e R is ik e n
s e lte n
ö fte r
h ä u fig
Abb. 11.4-5: Vorschlag für eine Grobeinstufung von Risiken
s e h r h ä u fig
11.4 Ermittlung des Schutzbedarfs bei VoIP Hohe Risiken sollten unbedingt als untragbar eingestuft werden. Somit ist im Allgemeinen zwischen (noch) tragbaren Risiken und untragbaren Risiken zu unterscheiden. Es sollte alles unternommen werden, um alle Sicherheitsschwachstellen, die zu untragbaren Risiken führen können, zu beheben bzw. mindestens einige von ihnen durch zusätzliche Schutzmaßnahmen auf tragbare Risiken zu reduzieren.
11.4.5 Erfassung des Schutzbedarfs Um den Schutzbedarf übersichtlich zu erfassen, müssen alle Sicherheitsschwachstellen im Netzwerk präzise spezifiziert werden. Es ist sinnvoll, dies in tabellarischer Form zu tun. Abbildung 11.4-6 zeigt die Mustertabelle für die Spezifikation von Sicherheitsschwachstellen. Diese Tabelle wurde aus dem in Abbildung 11.4-1 dargestellten Modell einer Sicherheitsschwachstelle abgeleitet und zeigt exemplarisch den Sicherheitsproblembereich Server (s. Abb. 11.1-3). Aus dieser Tabelle ist der Schutzbedarf direkt ersichtlich. Die Sicherheitsschwachstellen in anderen Sicherheitsproblembereichen können ebenfalls in dieser Form spezifiziert werden. S ic h e rh e its p ro b le m b e re ic h : S e r v e r S c h w a c h s te lle B e d ro h u n g sty p e n L e its a tz ID S 1
...
V o IP S e rv e r
( 1 ,2 ( 1 ,3 ( 1 ,4 ( 2 ,1
), ( ), ( ), ( ), (
3 ,2 3 ,3 3 ,4 2 ,3
), ( ), ( ), ( ), (
4 ,2 4 ,3 4 ,4 2 ,3
V e rlu s t d e r:
V e rtra u lic h k e it A u th e n tiz itä t u n tra g b a r In te g ritä t V e rfü g b a rk e it
)
S c h u tz b e d a rf B e m e rk u n g ( 2 ,1 ) , ( 3 ,2 ) , ( 4 ,2 ) = H ija S p o ( 1 ,2 ) , ( 3 ,3 ) , ( 4 ,3 ) = D o S ( 1 ,4 ) , ( 3 ,4 ) , ( 4 ,4 ) = C a ll ( 3 ,2 ) , ( 3 ,3 ) = S a b o ta g e
c k in o fin , B o F ra
g
g ,
www.wiwobooks.com ) ) )
...
...
R is ik o
...
...
m b in g u d , S P IT
...
Abb. 11.4-6: Tabelle für die Spezifikation des Schutzbedarfs eines Sicherheitsproblembereichs ID: Identifikation, für Bedrohungstypen siehe Tabelle 11.4-1
Um Bedrohungen auf kompakte und einheitliche Art und Weise zu beschreiben, kann auf die in Abbildung 11.4-4 dargestellte Bedrohungsmatrix zurückgegriffen werden. Bei der Erfassung des Schutzbedarfs könnte man daher nur den Bedrohungstyp angeben. Welche denkbaren Angriffe und Gefährdungen hierbei in Frage kommen, kann man aus Tabelle 11.4-1 ablesen. S ic h e rh e its p ro b le m b e re ic h : S e r v e r S c h w a c h s te lle ID
B e d ro h u n g sty p e n
L e its a tz
S 1 S 1
V o IP S e rv e r
...
...
( 1 ,2 ( 1 ,3 ( 1 ,4 ( 2 ,1
), ( ), ( ), ( ), (
3 ,2 3 ,3 3 ,4 2 ,3 ...
), ( ), ( ), ( ), (
4 ,2 4 ,3 4 ,4 2 ,3
1
D e n k b a re S ic h e rh e its m a ß n a h m e n 2
( 1 ,2 ) , ( 3 ,2 ) , ( 4 ,2 ) : A n ti- S p o o f in g
)
( 3 ,1 ) , ( 3 ,3 ) , ( 4 ,3 ) : A n ti- D o S ( 2 ,2 ) , ( 2 ,3 ) , ( 2 ,4 ) : M a lw a r e s c a n n e r ( 1 ,4 ) , ( 3 ,4 ) , ( 4 ,4 ) : A n ti- C a ll- F r a u d
)
)
)
...
( 3 ,2 ) , ( 3 ,3 ) : S e n s ib ilis ie r u n g v o n B e n u tz e rn ( 1 ,2 ) , ( 3 ,2 ) , ( 4 ,2 ) : A n ti- C a llH ija c k in g Z u g riffs b e re c h tig u n g e n
...
Abb. 11.4-7: Spezifikation von Sicherheitsmaßnahmen eines Sicherheitsproblembereichs
489
490 Denkbare Sicherheitsmaßnahmen
11 VoIP-Sicherheit Der ermittelte Schutzbedarf verlangt, dass bestimmte technische und organisatorische Sicherheitsmaßnahmen umgesetzt werden müssen. Die denkbaren Sicherheitsmaßnahmen sollten ebenfalls in übersichtlicher Form erfasst werden. Aus der in Abbildung 11.4-6 gezeigten Tabelle lässt sich hierfür eine geeignete Tabelle ableiten. Abbildung 11.4-7 zeigt diese Tabelle.
11.5 Festlegung von Sicherheitsanforderungen Sind die Sicherheitsschwachstellen im Netzwerk bei der Migration zu VoIP bekannt und die daraus resultierenden Risiken abgeschätzt (s. Abb. 11.1-6), können Sicherheitsanforderungen festgelegt werden. Hierbei soll präzise erfasst werden, wie weit die einzelnen Schutzbedürfnisse abzudecken sind. Dafür wird ein Modell der Sicherheitsschwachstelle für die Schutzbestimmung eingeführt.
11.5.1 Darstellung der Sicherheitsschwachstelle Um die Sicherheitsanforderungen im Netzwerk auf einheitliche Art erfassen zu können, zeigt Abbildung 11.5-1 das hierfür geeignete Modell der Sicherheitsschwachstelle. Id e n tifik a tio n , L e its a tz S c h u tz b e d a r f
S ic h e r h e its s c h w a c h s te lle
S ic h e r h e its a n fo r d e r u n g e n
www.wiwobooks.com (S ic h e rh e its ris ik e n )
E in s c h r ä n k u n g e n
fin a n z ie lle p e rs o n e lle
...
T e c h n is c h e M a ß n a h m e n ? O rg a n is a to ris c h e M a ß n a h m e n ?
rä u m lic h e
Abb. 11.5-1: Modell der Sicherheitsschwachstelle für die Schutzbestimmung
Angaben zu Sicherheitsschwachstelle
Die während der Ermittlung des Schutzbedarfs der Sicherheitsschwachstelle zugewiesene Identifikation wird im Modell für die Schutzbestimmung übernommen (s. Abb. 11.4-1). Zu jeder Sicherheitsschwachstelle sollten nun folgende Angaben gemacht werden: Schutzbedarf: Diese Angabe listet die aus der Sicherheitsschwachstelle resultierenden Risiken auf (s. Abb. 11.1-6). Einschränkungen: Da es sich bei der Festlegung von Sicherheitsanforderungen um eine „politische“ Entscheidung handelt, müssen verschiedene Randbedingungen (wie z.B. finanzielle, personelle, räumliche) als Einschränkungen berücksichtigt werden. Sicherheitsanforderungen: Hier muss angegeben werden, wie weit der Schutzbedarf abzudecken ist und welche Sicherheitsmaßnahmen umgesetzt werden sollen. Die Spezifikation von Sicherheitsanforderungen soll festlegen, wie weit die Sicherheitsziele Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit bei jeder Sicherheitsschwachstelle erreicht werden sollen.
11.5.2 Katalog von Sicherheitsanforderungen Die Anforderungen an die VoIP-Sicherheit müssen präzise erfasst werden. Am besten geschieht dies in tabellarischer Form. Abbildung 11.5-2 zeigt die Mustertabelle für Spezifikationen von Anforderungen. Diese Tabelle wurde aus dem in Abbildung 11.5-1 dargestellten Modell der Sicher-
11.6 Maßnahmen zur Erhöhung der VoIP-Sicherheit
491
heitsschwachstelle für die Schutzbestimmung abgeleitet und zeigt exemplarisch den Sicherheitsproblembereich Server (s. Abb. 11.1-3). S ic h e rh e its p ro b le m b e re ic h : S e r v e r S c h w a c h s te lle S c h u tz b e d a rf ID
S 1
...
L e its a tz V o IP S e rv e r
...
V e rlu s t d e r:
R is ik o
V e rtra u lic h k e it
u n tra g b a r
S c h u tz b e s tim m u n g G e fo rd e rte M a ß n a h m e n B e m e rk u n g e n te c h n is c h e o rg a n is a to r. O M
A u th e n tiz itä t
u n tra g b a r
T M
1 , T M
In te g ritä t
u n tra g b a r
T M
1 , T M
V e rfü g b a rk e it
u n tra g b a r
T M
1 , T M
...
...
...
2
O M 3 O M 4 O M
1 2 2 , O M 3 2
...
...
T e c h n is c h e M a ß n a h m e n : T M 1 : E in M a lw a re s c a n n e r s o ll e in g e p la n t w e rd e n . T M 2 : E in e s tre n g e A u th e n tifiz ie ru n g d e r B e n u tz e r s o ll e in g e fü h rt w e rd e n . ... O r g a n is a to r is c h e M a ß n a h m e n : O M 1 : Z u g riff a u f d e n V o IP -S e rv e r m u s s m it P a s s w o rd g e s c h ü tz t s e in . O M 2 : B e n u tz e r m ü s s e n in s tru ie rt w e rd e n , w a s s ie g e g e n S c h a d e n s p ro g ra m m e u n te rn e h m e n k ö n n e n . ...
www.wiwobooks.com
Abb. 11.5-2: Anforderungskatalog für ein Sicherheitsproblembereich (s. Abb. 11.1-3)
organisator.: organisatorische, O(T)M: Organisatorische (Technische) Maßnahme
Die geforderten Sicherheitsmaßnahmen gegen die einzelnen Risiken werden aufgrund der Angaben in der Tabelle mit denkbaren Sicherheitsmaßnahmen (s. Abb. 11.4-7), die während der Erfassung des Schutzbedarfs erstellt wurde, spezifiziert. Somit stellt die Tabelle in Abbildung 11.5-2 eine „Zusammenfassung“ der in den Abbildungen 11.4-6 und -7 gezeigten Tabellen dar. Die Tabelle in Abbildung 11.5-2 kann auch als Katalog der geforderten Sicherheitsmaßnahmen, d.h. als Sicherheitsanforderungskatalog, für den Sicherheitsproblembereich Server angesehen werden. Spezifiziert man nach dem hier dargestellten Muster die Anforderungen für alle Sicherheitsproblembereiche im Netzwerk, ergibt sich fast automatisch der Katalog von Sicherheitsanforderungen für das gesamte Netzwerk. Danach müssen noch die Maßnahmen für die Umsetzung dieser Anforderungen bestimmt werden.
11.6 Maßnahmen zur Erhöhung der VoIP-Sicherheit Das Konzept für die VoIP-Sicherheit besagt, wie der Katalog von Sicherheitsanforderungen unter Berücksichtigung von Kosten und Restrisiken umzusetzen ist. Es umfasst nicht nur Systeme und beteiligte Personen, sondern muss das gesamte Netzwerkumfeld mit einbeziehen.
11.6.1 Spezifikation von Sicherheitsmaßnahmen Abbildung 11.6-1 zeigt ein Modell für die einheitliche Beschreibung der Art und Weise, wie Sicherheitsschwachstellen behoben werden sollen. Die Art der Behebung richtet sich nach den zu
Sicherheitsanforderungskatalog
492
11 VoIP-Sicherheit erreichenden Sicherheitszielen. Diese können daher als Eingangsangaben angesehen werden. Die bereits der entsprechenden Sicherheitsschwachstelle zugewiesenen Identifikation und Name werden hierfür übernommen. Id e n tifik a tio n , L e its a tz S ic h e r h e its z ie le
R e s tr is ik e n ?
S ic h e r h e its s c h w a c h s te lle
T M
T M 1
...
H a rd w a re - u n d S o ftw a re - T e c h n is c h e s K o m p o n e n te n M itte l
2
...
O M
O r g a n is a to r is c h e M a ß n a h m e n
T e c h n is c h e M a ß n a h m e n
...
1
O M 2
...
V e rtra u lic h k e it, In te g ritä t, A u th e n tiz itä t, V e rfü g b a rk e it
S ic h e rh e its v e rfa h re n
T e c h n is c h e s M itte l
Abb. 11.6-1: Modell für die Beschreibung der Behebung einer Sicherheitsschwachstelle OM: Organisatorische Maßnahme, TM: Technische Maßnahme
Mit jeder Sicherheitsschwachstelle sollten folgende Angaben gemacht werden: Sicherheitsziele wie Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit, die als Folge der Behebung der Sicherheitsschwachstelle erreicht werden sollen.
www.wiwobooks.com
Technische Maßnahmen, organisatorische Maßnahmen und Restrisiken.
Sicherheitsmaßnahmenkatalog
Die Tabelle in Abbildung 11.6-2 kann als Sicherheitsmaßnahmenkatalog für den Sicherheitsproblembereich Server angesehen werden. Spezifiziert man nach diesem Muster die Anforderungen für alle Sicherheitsproblembereiche im Netzwerk, entsteht als Ergebnis der Katalog von Sicherheitsmaßnahmen für das gesamte Netzwerk.
S ic h e rh e its p ro b le m b e S c h w a c h s te lle S L e its a tz ID V A S 1 V o IP S 1 S e rv e r I ...
...
re ic h : S e r v e r ic h e rh e its z ie l
U m s e tz u n g v o n g e fo rd e rte n M a ß n a h m e n te c h n is c h e o rg a n is a to ris c h e
e rtra u lic h k e it
T M
1
u th e n tiz itä t
T M
1 , T M
n te g ritä t V e rfü g b a rk e it
T M
1 ,T M
...
T M
1 ,T M
2 3 4
O M
1
O M O M O M
2
...
2 , O M 2
...
3
R e s tris ik o (e v e n tu e ll) v e rn a c h lä s s ig b a r n ie d rig n ie d rig n ie d rig ...
B e m e r k u n g e n ü b e r d ie U m s e tz u n g te c h n is c h e r M a ß n a h m e n : T M 1 : D ie R e a lis ie ru n g d ie s e r M a ß n a h m e w ird in V o IP -S e r v e r -S ic h e r h e it, P k t. x x s p e z ifiz ie rt. ... B e m e r k u n g e n ü b e r d ie U m s e tz u n g o r g a n is a to r is c h e r M a ß n a h m e n : O M 1 : F ü r P a s s w o rd M a n a g e m e n t s ie h e V o IP -S e r v e r -S ic h e r h e it, P k t. z z ...
Abb. 11.6-2: Spezifikation der Umsetzung von Maßnahmen für einen Sicherheitsproblembereich (s. Abb. 11.1-3) O(T)M: Organisatorische (Technische) Maßnahme
11.6 Maßnahmen zur Erhöhung der VoIP-Sicherheit
493
11.6.2 Typische Sicherheitsschwachstellen Abschließend werden typische Sicherheitsschwachstellen aus den einzelnen Sicherheitsproblembereichen (s. Abb. 11.1-3) kurz dargestellt. Bei den jeweils angegebenen Sicherheitsmaßnahmen handelt es sich um keine vollständige Liste, sondern nur um denkbare Maßnahmen. Sicherheitsschwachstelle: Internet-Router und Firewall Bedrohungen: Unautorisierte Zugriffe, Port Scanning, Schadensprogramme, ... Folgen: Verlust der Vertraulichkeit, Integrität und Verfügbarkeit Maßnahmen: Einsatz einer Firewall mit VoIP-Unterstützung, Intrusion Detection, ...
1. Netzzugangsbereich
Ältere Firewalls analysieren nur die Zielports von Datenanwendungen und nicht die VoIP-spezifischen Ports (wie z.B. 5060 für SIP). Daher kommen diese Firewalls mit VoIP meist nicht zurecht. Um VoIP-Verkehr jedoch nicht zu blockieren, müssen VoIP-spezifische Ports freigegeben werden. Daher kann der VoIP-Verkehr völlig an einer älteren Firewall vorbeilaufen. Sicherheitsschwachstelle: VoIP-Gateway Bedrohungen: DoS-Angriffe, Gebührenbetrug, ... Folgen: Verlust der Authentizität, Verfügbarkeit, ... Maßnahmen: Schutz gegen DoS-Angriffe, Einschränkung der Anzahl ausgehender Anrufe von einem IP-Telefon, ... Es können auf ein VoIP-Gateway unterschiedliche DoS-Angriffe seitens des Netzwerks durchgeführt werden, die dazu führen können, dass Amtsleitungen zum PSTN/ISDN blockiert werden. Sicherheitsschwachstelle: VoIP-Server (als Call-Server, SIP-Proxy) Bedrohungen: Schadensprogramme, Port Scanning, DoS-Angriffe, unautorisierte Zugriffe, ... Folgen: Verlust der Verfügbarkeit, Integrität und Vertraulichkeit Maßnahmen: Virenscanner, Intrusion Detection und Prevention, Überwachung von TCP- und UDP-Ports, Audits, Zugriff nur für autorisierte Administratoren, ...
www.wiwobooks.com
Der VoIP-Server stellt die wichtigste Komponente im System dar, sodass hier alles gegen potenzielle Angriffe unternommen werden muss. Abbildung 11.3-5 ist ein Beweis dafür. Sicherheitsschwachstelle: Registrar bei SIP Bedrohungen: Schadensprogramme, DoS-Angriffe, Registration und Session Hijacking, unautorisierte Zugriffe, böswillige Veränderungen von Benutzerdaten, ... Folgen: Verlust der Verfügbarkeit, Authentizität und der Integrität von Signalisierungsdaten Maßnahmen: Zutrittsschutz, Authentisierung von Benutzern, Überprüfung der Zugangsberechtigung, Protokollierung der Registrierung, .... Nach einer böswilligen Änderung von Registrierungsangaben kann Session Hijacking einfach durchgeführt werden – siehe hierfür Abbildungen 11.3-2, -3 und -4. Sicherheitsschwachstelle: Voicemail-Server Bedrohungen: Schadensprogramme, DoS-Angriffe (z.B. mit INVITE bei SIP), Session Hijacking, Abhören und Aufzeichnen von Voicemails, ... Folgen: Verlust der Vertraulichkeit und Verfügbarkeit Maßnahmen: Schutz gegen DoS-Angriffe, Authentisierung von Benutzern, Überprüfung der Zugangsberechtigung, Firewalls und Virenscanner, ... Mit ähnlichen Angriffen auf einen Voicemail-Server ist bei beiden Signalisierungsprotokollen H.323 und SIP zu rechnen. Sicherheitsschwachstelle: Gatekeeper bei H.323 Bedrohungen: Schadensprogramme, DoS-Angriffe, DSN-Spoofing-ähnliche Angriffe, ... Folgen: Verlust der Verfügbarkeit, Integrität von Signalisierungsdaten, ... Maßnahmen: Schutz gegen DoS-Angriffe, Firewalls und Virenscanner, ...
2. Serverbereich
494
11 VoIP-Sicherheit Falls mehrere Gatekeeper eingesetzt werden, können spezielle Angriffe auf den GatekeeperProxy vorgenommen werden. Diese würden somit den Pharming-Angriffen entsprechen.
3. Netzwerkinfrastrukturbereich
Sicherheitsschwachstelle: Layer-2-Switches Bedrohungen: MAC-Spoofing, MAC-Flooting, ARP-Spoofing, VLAN-Angriffe, ... Folgen: Verlust der Authentizität, Vertraulichkeit, ... Maßnahmen: Schutz gegen MAC-Spoofing, Authentifizierung der IP-Telefone, statische MACEinträge für IP-Telefone, Ausschalten von Proxy ARP und Gratuitous ARP, ... Sicherheitsschwachstelle: Layer-3-Switches Bedrohungen: IP-Spoofing,... Folgen: Verlust der Vertraulichkeit, Verfügbarkeit, ... Maßnahmen: Einsatz eines Anti-Spoofing-Filters, ... Sicherheitsschwachstelle: Router Bedrohungen: Route Injection, DoS-Angriffe mit ICMP Destination Unreachable, ... Folgen: Verlust der Vertraulichkeit, Integrität von Signalisierungsdaten, ... Maßnahmen: Schutz gegen ICMP Redirect, gegen Route Injection und DoS-Angriffe, ... Sicherheitsschwachstelle: Netzwerkstruktur Bedrohungen: MitM-, DoS- und Spoofing-Angriffe (IP-, MAC- und ARP-Spoofing), QoSAngriffe, Manipulation von Konfigurationsparametern, ... Folgen: Verlust der Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit Maßnahmen: VoIP-konformes Netzwerkdesign, Bildung eines Sprach-VLAN, Firewalls zwischen Sprach-VLAN und Daten-VLAN, separate DHCP-Server für Sprach-VLANs, ...
www.wiwobooks.com
Im Sprach-VLAN sollte die Nutzung von Soft-IP-Telefonen vermieden werden.
4. Endsystembereich
Sicherheitsschwachstelle: IP-Telefon Bedrohungen: Manipulation von Konfigurationsparametern, Pharming bei Soft-Telefonen, ... Folgen: Verlust der Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit Maßnahmen: Authentisierung von Benutzern, Überprüfung der Zugangsberechtigung, ... Der Zugriff auf IP-Telefone darf nicht uneingeschränkt sein. Die IP-Telefone sollten so abgesichert werden, dass sie nur nach Eingabe einer Geheimzahl für einen Benutzer verfügbar sind. Auf den Soft-IP-Telefonen sollte zumindest eine lokale Firewall installiert werden.
5. Benutzerbereich
Sicherheitsschwachstelle: Benutzer Bedrohungen: Lauschangriffe, Systemmissbrauch, Gebührenbetrug, ... Folgen: Verlust der Vertraulichkeit, Verfügbarkeit, Verstöße gegen Gesetze und Vorschriften, ... Maßnahmen: Schutz gegen Gebührenbetrug, Sensibilisierung von Benutzern, ...
6. Interne Kommunikation
Sicherheitsschwachstelle: Protokolle RTP und RTCP Bedrohungen: Lauschangriffe, DoS-Angriffe auf VoIP-Verbindungen (RTP- und RTCP Insertion), böswillige Modifikation von RTP-Angaben, ... Folgen: Verlust der Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit Maßnahmen: Einsatz von SRTP (s. Abschnitt 5.7), Verschlüsselung der übertragenen Sprache, ... Sicherheitsschwachstelle: Signalisierungsprotokoll SIP Bedrohungen: DoS-Angriffe mit INVITE ( SIP-Bombing), CANCEL, BYE und Antworten 6xx, Session Hijacking mit Antworten 301 und 302, Spoofing, Pharming, ... (siehe Abb. 11.3-1) Folgen: Verlust der Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit Maßnahmen: Authentisierung von SIP-Requests, Schutz einiger Header-Felder in SIP-Nachrichten gegen böswillige Änderungen, ...
11.7 Schlussbemerkungen
495
Sicherheitsschwachstelle: H.323 Bedrohungen: DoS-Angriffe mit TCP SYN, Manipulation der Signalisierung, ... Folgen: Verlust der Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit Maßnahmen: Schutz gegen DoS-Angriffe, Unterstützung von H.235, ... H.235 als Standard für die Garantie der Sicherheit in H.323-Systemen sieht die Möglichkeit der Integritätsprüfung sowie der Verschlüsselung der H.323-Signalisierung vor. Die beteiligten Systeme müssen jedoch die Kommunikation nach H.235 unterstützen. H.235 setzt in der Regel die Nutzung eines PKI-Systems (Public Key Infrastruktur) voraus. Sicherheitsschwachstelle: Remote Access Server (RAS) Bedrohungen: Unautorisierte Remote-Zugriffe auf das VoIP-System über den RAS-Server, ... Folgen: Verlust der Vertraulichkeit, Authentizität und Integrität Maßnahmen: Schutz gegen unberechtigte Remote-Zugriffe auf das VoIP-System, Überprüfung von Remote-Benutzern (wie z.B. Teleworkern), ....
7. Remote Access Services
Bei diesem Sicherheitsproblembereich handelt es sich um Bedrohungen, die bereits im klassischen Netzwerkumfeld mit der RAS-Unterstützung vorkommen. Dieser Sicherheitsproblembereich umfasst die bereits im sechsten Sicherheitsproblembereich (Interne Kommunikation) aufgelisteten Schwachstellen wie Protokolle RTP und RTCP, Signalisierungsprotokoll SIP und H.323, die hier zu berücksichtigen sind. Zusätzlich sollte man eventuelle unerwünschte und massenweise auftretende Werbeanrufe als Sicherheitsschwachstelle erfassen.
8. Externe Kommunikation
Sicherheitsschwachstelle: Unerwünschte und massenweise auftretende Anrufe Bedrohungen: SPIT, V-Bombing Folgen: Verlust der Verfügbarkeit, Beeinträchtigung des VoIP-Dienstes, ... Maßnahmen: Einsatz von Anti-SPIT- bzw. von Anti-V-Bombing-Lösungen
www.wiwobooks.com
11.7 Schlussbemerkungen Ziel diese Kapitels war es, die Bedrohungen und Angriffsarten bei VoIP sowie die Vorgehensweise bei der Planung der VoIP-Sicherheit in kompakter Form darzustellen. Aufgrund des begrenzten Umfangs konnten nicht alle Probleme (wie z.B. die Sicherheit bei Voice over WLANs) und Ansätze (z.B. Standard H.235) dargestellt und keine technischen Systemlösungen präsentiert werden. Abschließend ist u.a. Folgendes hervorzuheben: VoIP ist letztlich nur eine Netzwerkanwendung wie jede andere. Salopp ausgedrückt, sollte man bei VoIP auf alle Sicherheitsprobleme achten, die man bereits aus dem klassischen Netzwerkumfeld kennt. Daher sollte man die VoIP-Sicherheit als Teil der Netzwerksicherheit betrachten, wie es in diesem Kapitel geschehen ist. SIP ist ein elegantes Signalisierungsprotokoll. Weil es jedoch in der Regel (s. Abb. 7.1.-1) das verbindungslose Transportprotokoll UDP verwendet, ist es anfällig und kann an vielen Stellen missbraucht werden (s. Abb. 11.3-1). Um die VoIP-Sicherheit – insbesondere zwischen den SIP-Proxies verschiedener Domains – zu verbessern, könnten SIP over TLS (SIPS) und S/MIME eingesetzt werden. SIPS wurde bereits in der SIP-Spezifikation – RFC 3261 – dargestellt. Auf die Bedeutung von S/MIME wurde in Ab-
SIP als Sicherheitsschwachstelle
496
11 VoIP-Sicherheit
schnitt 11.3.3 eingegangen. Der Einsatz von SIP Digest in Unternehmen ist schon heute fast unabdingbar, um u.a. die Registration Hijacking mit möglichen Folgen (s. Abbildungen 11.3-3 und -4) zu vermeiden. Leider werden die Sicherheitsmechanismen für SIP in den Produkten noch nicht ausreichend unterstützt. Weitere Konzepte zur Verbesserung für VoIP mit SIP sind daher dringend erforderlich. H.235
Um VoIP-Systeme nach H.323 gegen diverse böswillige Angriffe zu schützen, wurde der Standard H.235 von der ITU-T spezifiziert. Bei H.235 werden unterschiedliche Sicherheitsverfahren vorgeschlagen. Da es sich bei H.235 um komplexe Verfahren handelt und der Trend in Richtung SIPEinsatz geht, wurde in diesem Kapitel H.235 außer Acht gelassen.
Bedeutung von IPsec
Um Sicherheit in IP-Netzen auf dem Niveau der IP-Schicht zu realisieren, steht das Protokoll IPsec (IP Security) zu Verfügung. Da VoIP eine Anwendung in IP-Netzen ist, kann IPsec bei VoIP in einigen Situationen (z.B. bei einer standortübergreifenden Vernetzung von IP-PBXs) eingesetzt werden, um Angriffe auf dem IP-Niveau zu verhindern (s. Abb. 11.2-1).
Sicherheitsprobleme bei ENUM
Einige Sicherheitsprobleme bei VoIP können außerdem bei der Nutzung von ENUM entstehen (s. Abschnitt 3.8). Da ENUM ein Teil von DNS ist, muss bei VoIP mit allen DNS-spezifischen Angriffen (wie z.B. DNS-Spoofing) gerechnet werden. DNS-Spoofing ist auch die Basis für Pharming (s. Abschnitt 11.2.4). Daher ist künftig auch mit Pharming-Angriffen zu rechnen, bei denen DNS-Spoofing bei ENUM durchgeführt wird.
Sicherheitsprobleme bei Notrufen
Bei Notrufen über VoIP mit SIP kommen spezielle Sicherheitsprobleme hinzu, wie z.B. Abhörsicherheit oder Absetzen und Weiterleiten von Notrufen aus nicht dedizierten Endgeräten (PCs, Laptops usw.). Da die VoIPProtokolle im Gegensatz zum Mobilfunk keinen Rückschluss auf den Standort des Endgeräts zulassen, lässt sich ein korrektes Routing des Notrufs zum zugehörigen Notrufträger nicht immer sicherstellen.
VOIPSA
Wesentliche Marktteilnehmer aus dem VoIP-Bereich haben sich zu Voice over IP Security Alliance (VOIPSA) zusammengeschlossen. VOIPSA widmet sich der VoIP-Sicherheit und will u.a. das Bewusstsein für mögliche Gefahren durch die Anwendung von VoIP sensibilisieren, Diskussions-Foren etablieren, White Papers veröffentlichen und einschlägige Forschungsprojekte unterstützen (http://www.voipsa.org).
www.wiwobooks.com
