Diplomarbeit. Entwicklung einer Vorgehensweise zur Einführung von Voice over IP am Beispiel der GeTIK mbh.

Transkript

1 Diplomarbeit Thema: Entwicklung einer Vorgehensweise zur Einführung von Voice over IP am Beispiel der GeTIK mbh. Vorgelegt am: Von: Tobias Meinel Studienrichtung/ Studiengang Informationstechnik/Netzwerk- und Medientechnik Seminargruppe: IT06/2 Matrikelnummer: Praxispartner: GeTIK mbh Rudolf-Breitscheid-Straße Zschopau

2 Inhaltsverzeichnis Abbildungsverzeichnis... III Abkürzungsverzeichnis... IV 1 Einleitung Problemstellung Zielstellung Aufbau der Arbeit Grundlagen zu Voice over IP Geschichtlicher Abriss Protokolle RTP RTCP SRTP SDP H SIP MGCP Megaco Funktionsweise Unterschiede zur normalen Telefonie CTI Qualitätsmerkmale der Verbindung Verwendbare Codecs Planung Vorgehensweise Ist-Analyse Standort Chemnitz Standort Zschopau Standort Meißen Soll-Analyse Standort Chemnitz Standort Zschopau Standort Meißen Bedarfsanalyse Mitglieder Leitersitzung Migration Hybride VoIP-Architektur am Einzelstandort Verteilte hybride VoIP-Architektur mit zentraler Anrufsteuerung Verteilte hybride VoIP-Architektur mit verteilter Anrufsteuerung Reine VoIP-Architektur am Einzelstandort Verteilte reine VoIP-Architektur mit zentraler Anrufsteuerung Verteilte reine VoIP-Architektur mit verteilter Anrufsteuerung Microsoft Office Communication Server Konzept Dokumentation Verkabelung Vernetzung Adressierung I

3 3.6.5 Gebührenerfassung und abrechnung Sicherheit Pflichtenheft Must have Nice to have Not to have Umsetzung Anbietervergleich Marktanalyse Leistungen Alcatel-Lucent Cisco Siemens Auswertung Fazit Anhang 1: Checkliste... VII Anhang 2: Bedarfsanalyse Frank Irmscher (Geschäftsführer)... VIII Anhang 3: Bedarfsanalyse Hermann Förster (Leiter IT)... IX Anhang 4: Bedarfsanalyse Simone Gerlach (Rechnungswesen)... X Anhang 5: Bedarfsanalyse Norbert Richters (Teamleiter EB-Services)... XI Literaturverzeichnis... XIII II

4 Abbildungsverzeichnis Abbildung 2.1: Einordnung H.323 in das TCP/IP-Modell... 8 Abbildung 2.2: Rufaufbau und -abbau unter H Abbildung 2.3: Einordnung SIP in das TCP/IP-Modell Abbildung 2.4: Rufaufbau und -abbau unter SIP Abbildung 2.5: Struktur SIP-Request Abbildung 2.6: Struktur SIP-Response Abbildung 2.7: Verbindungsaufbau mittels Proxy-Server Abbildung 2.8: Verbindungsaufbau mittels Redirect-Server Abbildung 2.9: Overhead durch Header-Einkapselung Abbildung 2.10: Abhängigkeit Übertragungsqualität und Nutzerzufriedenheit Abbildung 2.11: Abhängigkeit Nutzerempfinden und MOS-Wert Abbildung 2.12: Zusammensetzung der Ende-zu-Ende-Verzögerung Abbildung 2.13: Übersicht der VoIP-relevanten Sprachcodierungsverfahren Abbildung 2.14: VoIP-relevante Sprachcodierungsverfahren Abbildung 2.15: MOS-Skala Abbildung 3.1: allgemeine Vorgehensweise bei der Migration zu VoIP Abbildung 3.2: Trunking Gateway Abbildung 3.3: Residential Gateway Abbildung 3.4: Access Gateway Abbildung 3.5: Standortübergreifende TK-Anlage mit zentraler Anrufsteuerung Abbildung 3.6: Standortübergreifende TK-Anlage mit verteilter Anrufsteuerung Abbildung 3.7: Hybride VoIP-Architektur am Einzelstandort Abbildung 3.8: Verteilte hybride VoIP-Architektur mit zentraler Anrufsteuerung Abbildung 3.9: Verteilte hybride VoIP-Architektur mit verteilter Anrufsteuerung Abbildung 3.10: Reine VoIP-Architektur am Einzelstandort Abbildung 3.11: VoIP-Architektur mit getrennter Sprach- und Datenverkabelung Abbildung 3.12: VoIP-Architektur mit gemeinsamer Sprach- und Datenverkabelung 51 Abbildung 3.13: Verteilte VoIP-Architektur; zentrale Anrufsteuerung Abbildung 3.14: Verteilte VoIP-Architektur; zentrale Anrufsteuerung nur für kommende Rufe Abbildung 3.15: Verteilte reine VoIP-Architektur mit verteilter Anrufsteuerung Abbildung 3.16: Komponenten des VoIP-Konzeptes III

5 Abkürzungsverzeichnis ACELP Algebraic Code-Excited Linear-Prediction ACF Admission ConFirmation ACK ACKnowledgement ADPCM Adaptive Differential Pulse Code Modulation ADSL Asymmetric Digital Subscriber Line AES Advanced Encryption Standard ARPANET Advanced Research Projects Agency Network ARQ Admission ReQuest BA Berufsakademie CELP Code-Excited Linear-Prediction CS-ACELP Conjugate-Structure Adaptive Differential Pulse Code Modulation CTI Computer Telephony Integration DCF Disengage ConFirmation DECT Digital Enhanced Cordless Telecommunications DHCP Dynamic Host Configuration Protocol DiffServ Differentiated Services DNS Domain Name System DRQ Disengage ReQuest DSL Digital Subscriber Line EDV Elektronische Datenverarbeitung ENUM Telephone Number Mapping FoIP Fax over Internet Protocol GeTIK mbh Gesellschaft für Technologie, Information und Kommunikation mbh IETF Internet Engineering Task Force IFP Internet Facsimilé Protocol IP Internet Protocol IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 ISDN Integrated Services Digital Network IT Informationstechnik IV

6 ITU-T LAN LD-CELP LS MAC Megaco MGC MGCP MOS MP-MLQ OCS PCM PoE PSTN QoS RAS RTCP RTP SDP SIP SMTP SRTP TCP TIFF TK ToS UAC UAS UDP URL USV VLAN International Telecommunication Union; Telecommunication Standardization Sector Local Area Network Low-Delay Code-Excited Linear-Prediction Location Server Media Access Control Media Gateway Control Media Gateway Controllern Media Gateway Control Protocol Mean Opinion Score Multipulse Maximum Likehood Quantization Office Communication Server Pulse Code Modulation Power over Ethernet Public Switched Telephone Network Quality of Service Registration, Admission, Status Realtime Transport Control Protocol Realtime Transport Protocol Session Description Protocol Session Initiation Protocol Simple Mail Transfer Protocol Secure Realtime Transport Protocol Transmission Control Protocol Tagged Image File Format Telekommunikation Type of Service User Agent Client User Agent Server User Datagram Protocol Uniform Resource Locator Unterbrechungsfreie Stromversorgung Virtual Local Area Network V

7 VoIP VPN WAN WLAN Voice over IP Virtual Private Network Wide Area Network Wireless Local Area Network VI

8 1 Einleitung 1.1 Problemstellung Im Rahmen der Einrichtung eines neuen Standortes der Gesellschaft für Technologie, Information und Kommunikation mbh, im Folgenden GeTIK genannt, soll eine Vorgehensweise entwickelt werden, die die Einführung von Voice over IP (VoIP) behandelt. 1.2 Zielstellung Ausgehend von dem Ist-Zustand sind notwendige Planungsschritte zu überlegen, um eine Konzeption zu erstellen, die nachfolgend eine Einführung von Voice over IP ermöglicht. Beachtung ist dabei neben der Funktionsweise auch den zugehörigen Protokollen zu schenken. Nach einer erfolgten Analyse von Infrastruktur und Netz, sind die benötigten Änderungen für eine Migration zu erörtern. 1.3 Aufbau der Arbeit Die vorliegende Arbeit ist in folgende Punkte gegliedert: Kapitel 2 behandelt die Grundlagen zu Voice over IP. Neben einer geschichtlichen Einordnung spielen die verschiedenen Protokolle und die Funktionsweise eine Rolle. Weiterhin werden die Unterschiede zwischen herkömmlicher und IP-basierter Telefonie (IP= Internet Protocol) herausgearbeitet. Kapitel 3 stellt eine Vorgehensweise der Planung nach dem Top-Down-Modell vor. Darin enthalten sind die notwendigen Analyseschritte und das Erarbeiten einer Konzeption. Ferner stellen die Mitglieder der Leitungssitzung der GeTIK ihre Anforderungen und Wünsche an das neue System vor. Als weiteren Schwerpunkt in diesem Kapitel erweist sich die Vorstellung verschiedener Migrationsmöglichkeiten und des Microsoft Office Communication Servers. Kapitel 4 zeigt in einem Pflichtenheft die Wünsche und Anforderungen an das neue System auf. 1

9 Kapitel 5 bietet einen Vergleich über die infrage kommenden Hersteller von Voice over IP Technologien. Kapitel 6 beendet die vorliegende Arbeit und zieht ein kurzes Resümee. 2

10 2 Grundlagen zu Voice over IP 2.1 Geschichtlicher Abriss Die erste digitale Sprachübertragung fand 1973 im ARPANET (Advanced Research Projects Agency Network) mittels des Network Voice Protocols statt. Die Datenübertragungsrate betrug bit/s folgte die Einführung von ISDN (Integrated Services Digital Network) mit einer Bandbreite von 64 kbit/s und somit einer verbesserten Sprachqualität. Später, im Jahre 1995, begannen die ersten Projekte auf dem Gebiet der Internet- Telefonie. Man kann diese allerdings nicht mit den heutigen Standards von Voice over IP vergleichen. Es war zwar eine neue, innovative Technik, aber nicht für die breite Masse verwendbar. Telefongespräche über das Internet konnten nur bei eingeschaltetem PC geführt werden und auch nur zwischen Teilnehmern, die Internet- Telefonie nutzten. Übergänge in das Fest- oder Mobilfunknetz waren nicht möglich, aufgrund nicht vorhandener Gateways, die einen solchen Übergang unterstützten. Der heute weitverbreitete DSL-Anschluss (Digital Subscriber Line) war damals noch nicht verfügbar. Man ging mit einem analogen Telefonanschluss oder ISDN online. Beides stellte nur eine stark begrenzte Bandbreite zur Verfügung. Somit mussten die Sprachdaten stark verlustbehaftet komprimiert werden, um überhaupt eine Übertragung in den Netzen mit geringer Bandbreite zu ermöglichen. Dadurch war die Qualität der Sprachübertragung oftmals schlechter als die in Mobilfunknetzen. Verbindungsabbrüche und Aussetzer während der Übertragung waren die Regel. Die israelische Firma VocalTec stellte im Februar 1995 ihre Software Internet Phone vor, mit der eine Halbduplexverbindung 1 zweier PCs möglich war. Es fehlten einheitliche Standards. So war es beispielsweise nur möglich, mittels der gleichen Software zu telefonieren. Weiterhin wurden die Verbindungen meist nach Zeit oder Volumen abgerechnet, sogenannte Flatrates gab es noch nicht. Voice over IP in der ersten Generation war 1 Eine Halbduplexverbindung ermöglicht den Datenaustausch auf einem Medium in zwei Richtungen, allerdings nur nacheinander. Dieses Vorgehen entspricht einem wechselseitigen Senden. 3

11 kein Erfolg, entwickelte aber wichtige Grundlagen, wodurch es später erfolgreich starten konnte wurde von der ITU-T (International Telecommunication Union; Telecommunication Standardization Sector) die Rahmenempfehlung H.323 standardisiert. Im gleichen Jahr entwickelte die IETF (Internet Engineering Task Force) das Realtime Transport Protocol (RTP). Ein Jahr später wurden die ersten Gateways auf der Grundlage der standardisierten Norm H.323 entwickelt. Dies ermöglichte eine Kommunikation über PC-zu-PC- Verbindungen hinaus auch zwischen PC und Telefon oder zwischen zwei Telefonen. So konnte diese neue Errungenschaft genutzt werden, um teure Festnetzverbindungspreise zu umgehen. Im darauffolgenden Jahr waren zwar Softphones und Gateways im Einsatz, aber es fehlte noch an Telefonie-Servern. Deshalb galt das Hauptaugenmerk 1998 der Entwicklung von H.323-Gatekeepern 2, den Telefonie-Servern. Im Jahr 1999 kam mit dem standardisierten Session Initiation Protocol (SIP) der IETF ein Konkurrenzprodukt zu H.323 auf den Markt. Das allgemeine Interesse an VoIP sank allerdings, da die Verbindungspreise im Festnetz reguliert wurden und fielen. Auch eine Verfügbarkeit von 99,99% blieb bei Voice over IP ein theoretischer Wunschtraum. Das sind Gründe dafür, dass VoIP seinen Erfolgskurs vorerst nicht weiter fortsetzen konnte. Den Tiefpunkt erreichte VoIP im Jahr Es war kaum mehr gefragt und teure Komponenten schreckten viele Firmen davon ab, zu migrieren. Einige wenige Unternehmen setzten bereits auf die IP-basierte Telefonie, aber nur mit wenigen Nebenstellen. Trotz der geringen Nachfrage wurde im gleichen Jahr das Protokoll ENUM 3 (Telephone Number Mapping) standardisiert. 2 Erklärungen zu Gatekeepern, siehe Kapitel ENUM ist die Abkürzung für TElephone NUmber Mapping und beruht auf dem Standard E.164 der ITU-T. Durch ENUM kann man sowohl im Internet als auch im herkömmlichen Telefonnetz unter einer Telefonnummer erreichbar sein. 4

12 2001 war eine Realisierung in Unternehmensumgebungen mit bis zu 700 Endgeräten möglich. Im privaten Umfeld wurde VoIP noch nicht eingeführt. Im darauffolgenden Jahr wuchs das Interesse an der VoIP-Technik wieder an. Von der IETF wurde die zweite Version von SIP entwickelt. Nach einem schwierigen Jahr 2003, indem wenig investiert wurde, begann 2004 der Aufbruch im Privatkundenmarkt. Zum Jahresende schätzte man Kunden bei immer mehr werdenden Anbietern. Ebenso wurde die Technik immer weiter entwickelt und ausgeklügelter. Die Preise lagen bei einigen Cent für weltweite Verbindungen. Innerhalb eines Netzes oder Anbieters waren die Gespräche oft sogar kostenfrei. Mit dem Aufkommen von DSL-Anschlüssen inklusive Flatrate-Tarifen erlebte auch die Entwicklung von VoIP einen weiteren Aufschwung. Dank der breitbandigeren Übertragungswege erreichte die Sprachqualität ein deutlich besseres Niveau und die Verbindungsabbrüche wurden weniger ermöglichten technische Neuerungen das bequeme Telefonieren auch bei ausgeschaltetem PC. Im Endkundenbereich wurden Geräte vertrieben, in denen neben einem DSL-Modem, Router und WLAN-Accesspoint (Wireless Local Area Network) eine kleine Telefonanlage integriert war, die IP-Telefonie ermöglichte. Die Anzahl der VoIP-Anbieter im Endkundenbereich hatte die Zahl 50 überschritten geht ENUM in Deutschland in den Produktivbetrieb über. Außerdem können VoIP-Anbieter, die einen Zugang ins Fernsprechnetz anbieten, Telefonnummern aus den Ortsnetzen beziehen. Experten schätzen, dass innerhalb der nächsten drei bis vier Jahre alle Gespräche über IP-Netze geführt werden und damit das klassische Telefonnetz ausgedient hätte. Viele Telefonanbieter verwenden selbst schon länger die VoIP-Technik zur Übertragung der Gespräche innerhalb ihres eigenen Netzes. 5

13 2.2 Protokolle RTP Da Echtzeitmedien keine Fehlerkontrolle über Quittungsbestätigungen unterstützen und die, für die Datenübertragung entwickelten, Protokolle nicht für eine Audio- bzw. Videoübertragung zu gebrauchen sind, wurde ein spezielles Protokoll entwickelt. Das Realtime Transport Protocol (RTP) dient der kontinuierlichen Übertragung von Audiound Videodaten über ein IP-Netz. Eine RTP-Session kann als logischer Übertragungskanal für VoIP angesehen werden. Nach dem Aufbau der Session findet die eigentliche Sprachübertragung statt. Ist diese beendet, wird die Session abgebaut, um damit belegte Netzwerkressourcen freizugeben. RTP ist ein reines Transportprotokoll für die Sprachdaten bei VoIP. Es ist Paket-basierend und baut auf das unsichere Protokoll UDP (User Datagram Protocol) auf, wie man Abbildung entnehmen kann. Bevor die Sprachdaten während einer Sitzung ausgetauscht werden können, muss eine Verständigung der Gesprächspartner 5 über den zu verwendenden Sprachcodec mittels eines Signalisierungsprotokolls erfolgen. RTP garantiert die Paketreihenfolge, da die Pakete eine Nummerierung erhalten. Somit können sie auch am Ziel in die richtige Reihenfolge gebracht werden, wenn auf dem Transportweg etwas durcheinander gerät. Ebenso erhalten die RTP-Pakete einen Zeitstempel. Dies ermöglicht die Wiederherstellung der ursprünglichen Zeitabstände am Ziel (Forderung der Isochronität 6 ) RTCP Für die Überwachung von RTP wurde das Realtime Transport Control Protocol (RTCP) entwickelt. Parallel zum RTP-Kanal überträgt RTCP Kontroll- und Statusinformationen zwischen den Gesprächspartnern. In periodischen Zeitabständen sendet es RTCP-Pakete mit Berichten über die aktuelle Verbindungsqualität und den Status des Senders selbst. Dementsprechend bestimmt RTCP die Übertragungsqualität der 4 Siehe Seite 8 5 z.b. H.323 oder SIP 6 Isochronität fordert konstante Zeitabstände zwischen zwei IP-Paketen, sowohl auf Sende- als auch auf Empfangsseite. 6

14 Sprachkommunikation. Es überwacht und sichert die Parameter des Quality of Service (QoS). Des Weiteren ist RTCP in der Lage, eindeutig die Quelle von Echtzeitmedien zu identifizieren. Darüber hinaus wird eine Mehrpunktkommunikation unterstützt. Durch die periodisch versendeten Statusreports ist es möglich, in einer Konferenz das Hinzukommen oder Ausscheiden von Teilnehmern zu vermelden. Abbildung lässt eine Einordnung in das TCP/IP-Modell erkennen SRTP Das Secure Realtime Transport Protocol (SRTP) stellt eine Erweiterung von RTP dar, mit dessen Hilfe man Echtzeitmedien in IP-Netzen verschlüsselt. Es garantiert Vertraulichkeit während der Sprachübertragung durch Verschlüsselung des Inhalts der RTP-Pakete. Der Absender eines Paketes kann anhand seiner IP-Adresse geprüft werden. Da die IP-Adresse durch Identity-Spoofing veränderbar ist, soll SRTP feststellen, ob die Pakete wirklich vom angegebenen Absender stammen. Weiterhin stellt SRTP Integrität sicher, d.h. es garantiert, dass die gesendeten Daten unterwegs nicht von einem Dritten verändert worden sind. Als weiteren Punkt gilt es den Anti-Replay-Schutz zu nennen. Er verhindert den Aufbau einer neuen Session mit Daten, die ein Dritter unterwegs abgefangen und mitgelesen hat. Zur Verschlüsselung wird der Advanced Encryption Standard (AES) angewandt. Auf gleiche Weise erfolgt auch die Überwachung von RTCP mittels SRTCP SDP Zur Übermittlung diverser Angaben einer RTP-Session wird das Session Description Protocol (SDP) verwendet. Das Signalisierungsprotokoll H.245 der H.323-Familie enthält schon einige Regeln zur Beschreibung einer RTP-Session. Bei SIP hingegen erfolgt die Beschreibung innerhalb einer SIP-Nachricht im Body mittels SDP. Es wird 7 Siehe Seite 8 7

15 dabei ausgehandelt, welche Medien übermittelt werden sollen und wie diese zu codieren sind. Eine Einordnung in das TCP/IP-Modell nimmt Abbildung vor H.323 Der ITU-T Standard H.323 ist ein Rahmenwerk, das für die Übermittlung von Echtzeitmedien weitere Standards und Protokolle einsetzt. Als Echtzeitmedien sind Video und Audio zu betrachten. Es erfolgt vor allem eine Beschreibung von Aufbau und Funktionsweise in diesem Standard. Die Signalisierung erfolgt durch die zwei Protokolle H und H.245, die zusammen H.323-Sig bilden. Abbildung 2.1 illustriert die Einordnung von H.323 in die TCP/IP-Familie. Daten- Anwendung T.120 Audio-Anwendung H.245 H G.711 G.72x Kommunikation Gatekeeper- Terminals als RAS-Control H RTP RTCP TCP UDP IP Abbildung 2.1: Einordnung H.323 in das TCP/IP-Modell 9 Endgeräte bezeichnet man als H.323-Terminals, oder kurz nur als Terminals. Eine Gruppe dieser Terminals bildet eine H.323-Zone (kurz: Zone), sozusagen ein Subnetz. Verantwortlich für eine Zone ist der Gatekeeper. Er kontrolliert die Terminals und verwaltet die Zuordnungstabelle von Telefonnummern, bzw Siehe Seite 13 9 Nach [BA05, S. 199] 8

16 Adressen, zu IP-Adressen der Terminals innerhalb seiner Zone. Daneben überwacht er die Bandbreite der Amtsleitung. Daraus folgt, dass sich jedes Endgerät registrieren muss, sobald es ins Netz kommt und auch wieder abmelden, damit Anrufe immer korrekt zustellbar sind. Aus Sicherheitsgründen sollten Gatekeeper in einer Zone redundant eingesetzt werden, um einem Ausfall vorzubeugen. Mehrere bilden zusammen einen logischen Gatekeeper, eine sogenannte Gatekeeper-Wolke. In kleineren Netzen kann der Gatekeeper auch entfallen, dann müssen die Terminals selbst die Zuordnungstabelle mit den Daten aller Kommunikationspartner pflegen. Analog zu Subnetzen in großen LAN-Umgebungen (Local Area Network) kann eine H.323-Domain in mehrere Zonen unterteilt sein. Die Verbindung dieser Zonen übernehmen Border Elemente, die meist im Gatekeeper integriert sind. Sie übernehmen den Austausch der Adressen oder Telefonnummern zwischen den Zonen. Die Kommunikation zwischen Gatekeeper und Terminal erfolgt mittels des Protokolls UDP. Der Aufgabenbereich von H.323 umfasst mehrere Gebiete: RAS-Control, H Control, H.245 Control und Übermittlung von Echtzeitmedien. RAS (Registration, Admission, Status) enthält die Steuerung zwischen Terminals und Gatekeepern. Ein neues Terminal muss sich erst beim Gatekeeper registrieren, um eine Verbindung aufbauen zu können. Ebenso ist es erforderlich, jede neue Verbindung anzumelden, damit der Bandbreitenbedarf geklärt ist und reserviert werden kann. Ziel der Anrufsignalisierung nach H ist der Auf- und Abbau von Verbindungen. Dazu wird ein Steuerungskanal, ähnlich dem D-Kanal bei ISDN, zwischen zwei Terminals auf- und nach dem Gespräch wieder abgebaut. Den Auf- und Abbau von logischen Kanälen, den RTP-Sitzungen, übernimmt das Control Protocol H.245. Die logischen Kanäle entsprechen weitestgehend den B- Kanälen des ISDN. 9

17 Die Übermittlung der Echtzeitmedien (hier interessant: Audio) erfolgt über RTP- Sessions. Zum Transport wird UDP verwendet. RTCP übernimmt die Kontrollfunktion. Für die Audioübertragung in H.323 ist der Codec G.711 als Standard vorgesehen und wird immer unterstützt. Weitere Codecs sind optional. Eine Auflistung und Erläuterung, zu einsetzbaren Standards und Codecs in der IP-Telefonie, findet sich in Kapitel Durch die Möglichkeit, verschiedene Codierungen einsetzen zu können, muss dieser im Vorfeld der Verbindung, im Zuge des Aufbaus der RTP-Session, zwischen den zwei kommunizierenden Terminals ausgehandelt werden. Der Aufbau eines Gesprächs ist in mehrere Schritte unterteilt. Abbildung 2.2 stellt den Ablauf dar. Wie schon erwähnt, muss ein Terminal, bevor es ein Gespräch beginnen kann, beim Gatekeeper um Erlaubnis fragen, da dieser die zur Verfügung stehende Bandbreite verwaltet. Dieser Schritt kann nur umgangen werden, wenn eine allgemeine Genehmigung vorliegt. Das Terminal meldet also seine benötigte Bandbreite mittels der Nachricht ARQ (Admission ReQuest) beim Gatekeeper an. Dieser bestätigt die Anfrage entweder mit ACF (Admission ConFirmation), schlägt eine niedrigere Bandbreite vor oder weist die Anfrage ab. Im Falle einer positiven Bestätigung wird zwischen den zwei Terminals eine TCP- Verbindung (Transmission Control Protocol) nach H aufgebaut, die als Anruf- SIG-Kanal dient. Nun sendet das rufende Terminal die H Nachricht Setup, um den Aufbau des H.245-Steuerkanals einzuleiten. Das angerufene Terminal bestätigt diese Nachricht mit Call Proceeding. Im nächsten Schritt fragt das angerufene Terminal beim Gatekeeper an, ob er das Gespräch annehmen darf. Dazu werden die bekannten Nachrichten ARQ und, als Antwort des Gatekeepers, ACF verwendet. Ist auch diese Bestätigung positiv, überprüft das angerufene Terminal, ob es mit dem rufenden Terminal kompatibel ist, d.h. ob z.b. der gleiche Codec verwendet wird. Wenn dies ebenfalls übereinstimmt, sendet das Terminal die H Nachricht Alerting aus und signalisiert den ankommenden Anruf durch Klingeln. Das rufende Terminal erhält das Freizeichen als Signalisierung. Nach der Anrufannahme wird eine Bestätigungsmeldung Connect vom angerufenen Terminal ausgesendet. Mit die- 10

18 sem Vorgang ist der H.245-Steuerungskanal aufgebaut und dem rufenden Terminal entsprechend angezeigt. Nun sind die logischen RTP- und RTCP-Kanäle hergestellt und die Übertragung der Gesprächsdaten kann erfolgen. IP-Netz Terminal 1 Terminal 2 Initiieren ARQ ACF Gatekeeper Aufbau eines Anruf-SIG-Kanals Setup Call Proceeding Freiton Verbindungsabmeldung Verbindungszulassung Verbindungszulassung Alerting Connect ARQ ACF Es klingelt Anruf wurde angenommen H.245-Steuerungskanal Aufbau der RTP- und RTCP-Kanäle Audioübermittlung nach RTP/RTCP Abbau der Medienkanäle Abbau des H.245-Steuerungskanals H.245-Steuerungskanal Abbau des Anruf-SIG-Kanals Anruf-SIG-Kanal DRQ DCF DRQ DCF Abbildung 2.2: Rufaufbau und -abbau unter H Nach [BA05, S. 203 und S. 205] 11

19 Nachdem die Übertragung der Sprachdateien beendet ist, müssen die Steuerungsund Medienkanäle wieder abgebaut werden. Auch dazu sind einige Schritte nötig. Mit Hilfe der H.245-Nachrichten CloseLogicalChannel und CloseLogical ChannelAck beginnt der Abbau der RTP- und RTCP-Kanäle. Im Anschluss wird der H.245- Steuerungskanal beendet. Dies erledigt die Nachricht Release Complete. Als Nächstes erfolgt der Abbau des Anruf-SIG-Kanals nach dem Schema einer normalen Beendigung einer TCP-Verbindung. Sind nun alle Kanäle abgebaut, müssen sich die Terminals beim Gatekeeper abmelden und die reservierte Bandbreite wieder freigeben. Jedes Terminal sendet dazu die Nachricht DRQ (Disengage ReQuest), die vom Gatekeeper mit DCF (Disengage ConFirmation) bestätigt wird. Mit der Nutzung von VoIP ist auch der Wunsch nach uneingeschränkter Mobilität aufgekommen. Man möchte auch unter seiner bekannten Telefonnummer erreichbar sein, wenn man nicht gerade an seinem Schreibtisch, sondern z.b. in einer anderen Abteilung, sitzt. Der Begriff Roaming fasst diese Wünsche zusammen. Es wird zwischen verschiedenen Arten von Roaming unterschieden. In der einfachsten Variante, dem Intra-Zone-Roaming, bewegt sich der Teilnehmer nur innerhalb seiner Zone. Diese Möglichkeit ist mit H.323 schon gegeben. Der Teilnehmer muss sich beim Gatekeeper abmelden, damit seine Zuordnung von IP- Adresse und Telefonnummer gelöscht wird und er vorerst nicht mehr telefonisch erreichbar ist. Am neuen Arbeitsplatz angekommen, registriert er sich wieder beim Gatekeeper und eine neue Zuordnung von IP-Adresse und seiner bisherigen Telefonnummer wird vorgenommen. Infolgedessen ist er mit seiner bekannten Telefonnummer an einem anderen Arbeitsplatz erreichbar. Wechselt ein Teilnehmer innerhalb einer Domain von einer Zone in eine andere, so ist das Protokoll H.510 anzuwenden. Diese Variante ist unter dem Begriff Inter-Zone- Roaming bekannt. Eine dritte Variante stellt das Inter-Domain-Roaming dar. Dabei wechselt ein Teilnehmer über die Domaingrenze hinaus. Auch dieses Konzept wird durch H.510 realisiert. 12

20 2.2.6 SIP Das von der IETF entwickelte Protokoll SIP dient der Signalisierung von Anrufen in IP-Netzen. Die Funktionsweise der Signalisierung entspricht weitestgehend der von ISDN. Zwischen zwei kommunizierenden Partnern wird eine Session aufgebaut, der Datenaustausch erfolgt über RTP. Man spricht daher auch von einer RTP-Session. Wenn Daten verschlüsselt ausgetauscht werden sollen, ist SRTP zu verwenden. Um Nachrichten im IP-Netz zu versenden, wird das unsichere und verbindungslose UDP verwendet, da SIP selbst eine sichere Übertragung garantiert. Dieses Vorgehen ermöglicht einen schnelleren und effizienteren Datenaustausch. Alternativ wäre aber auch eine Übertragung über TCP möglich. Eine Einordnung in die TCP/IP-Familie ist Abbildung 2.3 zu entnehmen. Abbildung 2.3: Einordnung SIP in das TCP/IP-Modell 11 In SIP ist ein weiteres Protokoll eingebettet: SDP (Session Description Protocol). Somit sind die Protokolle zum Aushandeln der Sitzungsparameter und der Medienwahl voneinander getrennt. SIP besteht aus zwei Komponenten, dem User Agent Client (UAC) von dem die Anrufe immer ausgehen, und dem User Agent Server (UAS), der angerufen wird. 11 Nach [BA05, S. 248] 13

21 Ein einfacher Rufaufbau (dargestellt in Abbildung 2.4) läuft z.b. über die - Adressen der Gesprächspartner. Der Rufende sendet als Request eine SIP- Nachricht INVITE an den Partner 2, welche die -Adresse von Gesprächspartner 2 als Zieladresse beinhaltet. Dies soll als Einladung zu einer Session aufgefasst werden. Aufgebaut ist die SIP-Nachricht nach dem Protokoll SDP und enthält die RTP-Beschreibung, eine Kompatibilitätsprüfung angesichts des verwendeten Sprachcodec. Ist die Kompatibilität gegeben, so kann der Partner 2 das Gespräch annehmen und sein IP-Telefon klingelt. Dabei sendet es den SIP-Response 180 Ringing an den rufenden Teilnehmer, der daraus resultierend ein Freizeichen signalisiert bekommt. Dies schließt gleichzeitig aus, dass der gerufene Anschluss besetzt ist. Nimmt der Gesprächspartner 2 das Gespräch an, so sendet sein Telefon den SIP-Response 200 OK, welcher wiederum vom rufenden Apparat mit einer Nachricht ACK (ACKnowledgement) bestätigt wird. Sobald die Bestätigung (ACK) bei Teilnehmer 2 eingeht, ist die Verbindung (RTP-Session) zwischen beiden Gesprächspartnern hergestellt. Abbildung 2.4: Rufaufbau und -abbau unter SIP 12 Beide Teilnehmer sind dann in der Lage das Gespräch, z.b. durch Auflegen des Hörers, zu beenden. Dabei sendet das IP-Telefon eine SIP-Nachricht BYE an den Ge- 12 Nach [BA05, S. 250] 14

22 sprächspartner, der diese mit 200 OK bestätigt. Wenn die Bestätigung bei dem IP- Telefon ankommt, das den Abbau eingeleitet hat, wird die RTP-Session beendet. SIP-Nachrichten sind textbasiert und zeilenweise aufgebaut. Nach einer Startzeile folgen ein Message Header und danach ein optionaler Message Body. Die Startzeile enthält den Typ der Nachricht. Somit ist erkennbar, ob es sich um einen Request oder einen Response handelt. Die Struktur von Request und Response ist verschieden. Die Startzeile bei einer Request-Nachricht wird auch Request-Line genannt. Sie enthält nach der Methode (z.b. INVITE, BYE, ACK) die Ziel-SIP-Adresse (Request-URI) und die SIP-Version. Beispielsweise könnte sie folgendermaßen aussehen: INVITE SIP/2.0. Der Request-Line folgt der Message Header, welcher aus Header-Feldern aufgebaut ist. Nach einer Leerzeile folgt der optionale Message Body. Abbildung 2.5 zeigt den Aufbau eines SIP-Requests. Abbildung 2.5: Struktur SIP-Request 13 Ein Response ist ähnlich aufgebaut (siehe Abbildung 2.6). Die Startzeile ist als Status-Line bezeichnet. In ihr stehen nach der SIP-Version eine dreistellige Zahl als Status-Code und die Reason-Phrase. Die erste Zahl im Status-Code gibt dabei die Response-Klasse an. Als Beispiel ist eine Status-Line nachfolgend zu sehen: SIP/ Ringing. Auch beim Response folgt der Startzeile ein Block von Header-Feldern und nach einer Leerzeile der optionale Message Body. 13 Nach [BA05, S. 262] 15

23 Abbildung 2.6: Struktur SIP-Response 14 Der Message Body beschreibt eventuelle Besonderheiten der Kommunikation während einer RTP-Session. So kann beispielsweise die Kompatibilität von IP-Telefonen geprüft werden. Eine SIP-Adresse ist ähnlich einer -Adresse aufgebaut. Die Adressierung wird über diese SIP-Adresse, auch SIP-URL (Uniform Resource Locator) genannt, vorgenommen und arbeitet nach dem gleichen Schema wie die Adressierung im Internet. Folglich kann auch DNS (Domain Name System) zur Auflösung von SIP-Adressen zu IP-Adressen verwendet werden. Unterschiedliche Strukturen der Adresse sind möglich. Beispielsweise Alle Varianten erhalten noch den Präfix sip: für unverschlüsselte bzw. sips: für verschlüsselte Verbindungen. Die Variante erleichtert vor allem die Erreichbarkeit in gekoppelten, hybriden Systemen, d.h. wenn ein herkömmliches System an die IP- Telefonie angebunden ist. Ebenso gibt es die Möglichkeit des Präfix tel:, gefolgt von der Telefonnummer. Dies erleichtert ebenfalls die Umsetzung zwischen IP- und herkömmlicher Telefonie. Dadurch, dass sich - und SIP-Adresse im Aufbau ähneln, erkennt der rufende Teilnehmer, innerhalb welcher Domain sich der gerufene Teilnehmer befindet. Dabei 14 Nach [BA05, S. 263] 16

24 ist aber nicht erkennbar, welchen Anschluss, d.h. welche IP-Adresse, er gerade benutzt. Aus diesem Grund sind zwei Server im Einsatz, die dem rufenden Teilnehmer Auskunft geben können: Proxy- und Location-Server. Abbildung 2.7: Verbindungsaufbau mittels Proxy-Server 15 Im Schritt (1) von Abbildung 2.7 wird der Wunsch eines Gesprächsaufbaus von Partner 1 an den Proxy-Server der Ziel-Domain weitergegeben. Dieser fragt beim Location-Server 16 der Domain nach, welche IP-Adresse das gewünschte Ziel (Partner 2) gerade verwendet. Hat er diese erhalten, leitet der Proxy im Schritt (2) den Verbindungswunsch an den Ziel-Anschluss weiter und übermittelt auch die IP- Adresse von Partner 1. Partner 2 signalisiert dem Proxy-Server in Schritt (3), dass der Ruf angenommen wurde, der wiederum die Signalisierung an Partner 1 weitergibt (Schritt (4)). Damit kann die Kommunikation über das IP-Netz beginnen. Die Signalisierung verläuft in diesem Fall nicht direkt, sondern über den Proxy-Server. 15 Nach [BA05, S. 252] 16 Abkürzung: LS; Ist eine Datenbank, in der die Zuordnung Name zu IP-Adresse gepflegt ist. 17

25 Abbildung 2.8: Verbindungsaufbau mittels Redirect-Server 17 Eine andere Variante besteht darin, statt eines Proxy-Servers einen Redirect-Server zu installieren. Der Ablauf des Verbindungsaufbaus ist in Abbildung 2.8 dargestellt. Die Aufgabe des Redirect-Servers ist es, dem rufenden IP-Telefon die aktuelle IP- Adresse des angerufenen Telefons zu übermitteln. Im Schritt (1) teilt Partner 1 dem Redirect-Server der Zieldomain seinen Verbindungswunsch mit. Dieser erkundigt sich zuerst beim Location-Server der Domain nach der aktuellen IP-Adresse von Partner 2. Hat er diese Aussage bekommen, leitet er die Information in Schritt (2) an Partner 1 weiter. Im Schritt (3) kann Partner 1 direkt den Verbindungswunsch an Partner 2 äußern. Die Bereitschaft zur Kommunikation wird Partner 1 signalisiert, sodass die Kommunikation beginnen kann. Folglich verläuft die Kommunikation ab dem Zeitpunkt, an dem Partner 1 die IP- Adresse von Partner 2 erhalten hat, direkt zwischen den beiden Usern und nicht über den Proxy- oder Redirect-Server MGCP MGCP (Media Gateway Control Protocol) dient zur Steuerung eines Media Gateways und ist nach dem Command/Request-Schema definiert. Spezifiziert wurde dieses Protokoll von der IETF. Die Übermittlung von Nachrichten erfolgt über das verbindungslose UDP. Sprachdaten werden zwischen Media Gateways mittels RTP über- 17 Nach [BA05, S. 253] 18

26 tragen. Zur Beschreibung der RTP-Sitzung dient das Protokoll SDP. Die verschiedenen Arten von Media Gateways werden in Kapitel 3.4 vorgestellt Megaco Megaco (Media Gateway Control) ist als Standard von der ITU-T und IETF gemeinsam entwickelt worden. Die Kommunikation zwischen Media Gateways läuft über SDP, wobei unter anderem ein gemeinsames Format festgelegt wird, und arbeitet nach dem Command/Reply-Schema. Unabhängig vom Transportprotokoll ist sowohl der Einsatz von UDP als auch TCP möglich. Megaco hat einen größeren Funktionsumfang und komplexeren Aufbau als MGCP. Mit Hilfe von Megaco kann auch eine Integration von VoIP mit ISDN vorgenommen werden. Eine Übersicht der Gateways findet sich in Kapitel Funktionsweise Unterschiede zur normalen Telefonie Um menschliche Sprache gut verständlich zu übertragen, wird ein Frequenzspektrum von 3,1 khz benötigt. Dabei sind Frequenzen zwischen 300 und Hz von Interesse. Darüber- und darunterliegende Frequenzen können abgeschnitten werden, da sie nicht zwangsläufig nötig sind, um den Gesprächspartner zu verstehen. Durch diese Vorgehensweise kann man Übertragungsbandbreite einsparen. Einige Codecs verwenden auch erweiterte Frequenzbandbreiten, sodass 7 khz oder mehr zustande kommen können. Wie auch beim ISDN wird der Schall der Sprache zuerst über das Mikrofon in ein analoges, kontinuierliches, elektrisches Signal umgewandelt, welches im Nachgang ein Analog-Digital-Umsetzer abtastet. Nach Nyquist und Shannon ist die Abtastfrequenz auf das Zweifache der höchsten verwendeten Frequenz festgelegt, damit das abgetastete Signal wieder möglichst genau rekonstruiert werden kann. Danach erfolgt eine Quantisierung der Abtastung auf festgelegte Werte. Bei dem Telefonie-Standard für ISDN (G.711) werden 8 Bit für das Quantisieren verwendet, wodurch 256 verschiedene Werte gegeben sind. 19

27 Entstanden ist damit ein digitaler Datenstrom, dessen benötigte Datenrate sich aus dem Produkt der Abtastwerte pro Sekunde und den Quantisierungsstufen in Bit zusammensetzt. Die höchste zu übertragende Frequenz liegt im Standard G.711 bei 3,4 khz. Damit würden sich Abtastungen pro Sekunde ergeben. International hat sich durchgesetzt, die oberste Frequenz etwas höher anzusetzen (4 khz). Dies entspricht einer Abtastrate von Werten pro Sekunde. Multipliziert mit den 8 Quantisierungsbit erhält man eine Datenrate von 64 kbit/s. Eine anschließende Komprimierung ist durch einen entsprechenden Codec möglich. Meist wird ein verlustbehaftetes Verfahren eingesetzt, bei dem für das menschliche Gehör nicht wahrnehmbare Informationen weggelassen werden. Allerdings darf das Verfahren nicht zu viele Daten entfernen, da sich sonst der Höreindruck merklich verschlechtert. Wenn die Daten codiert wurden, muss der Empfänger über einen passenden Decoder verfügen, um die Sprache verstehen zu können. Bei der herkömmlichen Telefonie setzt man auf eine leitungsvermittelte Übertragung. Für jedes Gespräch wird exklusiv eine Verbindung zwischen den beiden Gesprächspartnern hergestellt. Dieser Kanal bleibt auch bestehen, wenn zwischenzeitlich keine Daten ausgetauscht werden. Als Vorteil erweist sich dabei die konstante Bandbreite. Da der Verbindungsweg schon vor der eigentlichen Datenübertragung hergestellt ist, bleibt auch die Latenzzeit 18 während der Übertragung konstant, weil immer der gleiche Weg benutzt wird. Ebenso ändert sich auch die Reihenfolge der übertragenen Pakete aus den genannten Gründen nicht. Allerdings kann ein Kanal nur für eine Verbindung genutzt werden. Bei der Nutzung von IP-basierter Telefonie kommt hingegen eine paketvermittelte Übertragung zum Einsatz. Im Allgemeinen ist dieses Verfahren verbindungslos, d.h. es wird vorher keine Übertragungsroute festgelegt. Längere Nachrichten teilt man in einzelne Datenpakete. Dank der Paketierung können mehrere Teilnehmer gleichzeitig auf einem Übertragungsmedium senden, wodurch das Netz eine bessere Auslastung erfährt. Da kein konkreter Weg durch das Netz festgelegt ist, kann die Reihenfolge der gesendeten Pakete durcheinander geraten, wenn verschiedene Wege ein- 18 Verzögerungszeit zwischen zwei IP-Paketen 20

28 geschlagen werden. Es könnte auch vorkommen, dass bestimmte Knotenpunkte überlasten. Allerdings besteht die Möglichkeit schnell zu reagieren, wenn ein Knoten ausfällt. Dann ist ein anderer Weg durch das Netz zu wählen. Nachteilig ist, dass keine Garantie für eine konstante Bandbreite besteht. Bevor eine Übertragung der Sprachdaten stattfinden kann, muss eine Signalisierung erfolgen, die Quelle und Ziel der Kommunikation enthält. Realisiert wird dies bei der herkömmlichen Telefonie entweder direkt über die Sprechkreise (In-Band) bei der analogen Variante, bzw. Out-Of-Band über einen eigenen Kanal (D-Kanal) beim ISDN. Nutzt man die IP-Telefonie, kommt man an speziellen Signalisierungsprotokollen 19 nicht vorbei. Ein weiterer Aspekt, bei dem sich herkömmliche und IP-Telefonie unterscheiden, ist die Ausfallsicherheit. Durch das Zusammenlegen von Telefon- und Datennetz kann es zu Single Point of Failure 20 kommen. Früher war die Kommunikation in Büroumgebungen nach dem Ausfall einer Netzwerkkomponente noch über das Telefonnetz möglich. Durch die Konvergenz der Netze fällt diese Möglichkeit jedoch weg und die Mitarbeiter sind nur noch über eventuell vorhandene Mobiltelefone erreichbar. Deswegen sollten das Netz, bzw. wichtige Punkte, redundant ausgelegt sein. Auch gegen Stromausfälle müssen erweiterte Vorsorgemaßnahmen getroffen werden. In der analogen Telefonie wurden die Endgeräte von der Vermittlungsstelle mit der benötigten Spannung versorgt. Bei dem nachfolgend entwickelten ISDN, welches bei einem Stromausfall ebenfalls eine Notspeisespannung von der Vermittlungsstelle erhielt, reichte diese aber nur zum Betreiben eines berechtigten Telefons aus. In größeren Umgebungen, wenn eine Telefonanlage zum Einsatz kommt, ist diese mit einer unterbrechungsfreien Stromversorgung (USV), Batterien oder Notstromaggregaten zu sichern, um auch bei einem Stromausfall telefonieren zu können. Im Falle eines ISDN-Netzes ist die USV-Absicherung einfacher zu realisieren, da die Endgeräte in den meisten Fällen kein eigenes Netzteil benötigen und somit ein Telefonge- 19 z.b. H.323 oder SIP 20 Abkürzung: SPOF; Ausfall eines Elementes zieht einen Ausfall des gesamten Systems nach sich. Redundanzen beugen einem SPOF vor. 21

29 spräch möglich ist, solange die TK-Anlage über eine funktionierende Stromversorgung verfügt. Nutzt man hingegen Telefonie über das IP-Netz, erfordern die Telefonapparate eine gesonderte Anbindung an das Stromnetz. Dies kann über externe Netzteile für die Telefone oder mittels Power over Ethernet (PoE) realisiert werden. Einfacher in der Umsetzung wird sich Variante zwei erweisen. Damit sind nur die Telefonie-Server und aktiven Komponenten der Netzwerkstruktur, wie Switches und Hubs, über die USV abzusichern. Anderenfalls müsste sich die USV-Absicherung über jedes Zimmer im Gebäude erstrecken, in dem sich ein IP-Telefon befindet. PoE liefert eine Spannung von 48 V direkt auf dem Netzwerkkabel, bei einer maximalen Stromaufnahme von 350 ma im Dauerbetrieb. Nach Leistungsverlusten ergibt sich aus den 15,4 W maximaler Leistungsaufnahme pro Gerät eine Nutzleistung von ca. 12,95 W. Gespeist werden die Ethernet-Netzwerkkabel entweder von speziellen PoE-Switches, oder die Kabel werden von einem normalen Switch an einen PoE- Hub oder ein PoE-Patchfeld geführt, das die Speisung vornimmt. Besonders zu beachten ist die Problematik der Notrufe, die immer an die nächstgelegene Rettungsleitstelle übermittelt werden müssen. Diese wird im PSTN (Public Switched Telephone Network), dem herkömmlichen Telefonnetz, über die Vorwahl der anrufenden Telefonnummer bestimmt. In Deutschland sind Anbieter von Telekommunikationsdiensten verpflichtet, Notrufe an die nächstgelegene Leitstelle zu übermitteln. Teilweise stellen die Anbieter der Notrufzentrale Listen mit den, bei der Bestellung des Anschlusses angegebenen, Adressen zur Verfügung. Dies verbietet aber eine Nutzung derselben Rufnummer an unterschiedlichen Anschlüssen. Ein weiteres Problem stellt der Faxversand dar. Während bei analogen oder ISDN- Anschlüssen das Protokoll T.30 verwendet wird, gibt es für die IP-Telefonie mehrere Möglichkeiten der Umsetzung. In den herkömmlichen Telefonnetzen ist eine gesicherte Übertragung gewährleistet. Im Gegensatz dazu wird in IP-Netzen die Sprache meist mittels RTP über das ungesicherte UDP übertragen. Dabei kommt es vor, dass Pakete verloren gehen. Für die 22

30 Sprachübertragung ist eine Paketverlustrate von bis zu fünf Prozent tolerierbar. Nutzt man für die Faxübertragung solche, für den Sprachtransport optimierte, Codecs, kann es zu Informationsverlusten oder Verbindungsabbrüchen kommen. Somit ist darüber keine verlässliche Verbindung möglich. Eine Variante der Übertragung eines Faxes über IP-Netze ist die Nutzung des Protokolls T.37 der ITU-T. Es arbeitet im Store-and-Forward-Modus. Dabei wird das Fax als TIFF-Datei mittels SMTP (Simple Mail Transfer Protocol) in einer übertragen. Eine zweite Möglichkeit bietet das Protokoll T.38, ebenfalls von der ITU-T, welches auch als Fax over Internet Protocol (FoIP) bekannt ist. Hierbei wird das Fax nicht mittels Tönen, wie bei herkömmlicher Telefonie, übertragen, sondern mit dem auf TCP/UDP und IP aufsetzenden Protokoll Internet Facsimilé Protocol (IFP). Es handelt sich hierbei um eine Echtzeitübertragung ohne Verzögerungen. Soll ein Fax aus dem IP-Netz heraus an ein herkömmliches Faxgerät gesendet werden, muss ein Gateway die Übermittlung zwischen den Protokollen vornehmen CTI Unter CTI (Computer Telephony Integration) versteht man die Verbindung zwischen PC und Telefon zur Effizienzerhöhung. Dies kann unmittelbar geschehen, wenn das Telefon in den Rechner integriert, oder direkt mit ihm verbunden ist. In diesem Fall spricht man von einer Einzelplatzlösung (First Party Call Control). Bei Mehrplatzlösungen (Third Party Call Control) ist meist ein Server zwischen Daten- und Telefonnetz oder Telefonanlage geschalten. Dieser übernimmt dann die Steuerung der Telefonie. In den meisten Telefonanlagen wird CTI als Leistungsmerkmal unterstützt. Es findet damit z.b. eine Realisierung von Verbindungsauf- und -abbau statt oder man kann Telefonbuch- und Weiterverbindungsfunktionen nutzen. Vor allem für Call Center ist die Journalfunktion von Vorteil. Dabei wird nicht nur erfasst, wer an der Verbindung beteiligt war, sondern auch Notizen und Informationen zum Gespräch können gespeichert werden. 23

31 2.3.3 Qualitätsmerkmale der Verbindung Um eine gute Verbindung und Verständlichkeit zu erreichen, sind Qualitätsmerkmale definiert. Es sollten die ausgesendeten Sprachpakete genau so beim Empfänger ankommen, wie sie ausgesendet wurden. Zu den QoS-Anforderungen, wie die Qualitätsmerkmale auch genannt werden, gehören die Übermittlungszeit sowie deren Schwankungen, die Paketverlustrate und die Ende-zu-Ende-Verzögerung. Ebenso muss der Datendurchsatz und die Verfügbarkeit Berücksichtigung finden. Ein Netz kann noch so gut ausgebaut und konfiguriert sein. Wenn aber nach einem Knotenpunktausfall das gesamte Netz zusammenbricht und deswegen keine Verbindung mehr aufgenommen werden kann, nützt auch der beste Ausbau nichts. Aus diesem Grund hängt die Verfügbarkeit von Voice over IP in erster Linie von der Verfügbarkeit des zugrunde liegenden IP-Netzes ab. Hier gilt es auf die redundante Auslegung von wichtigen Komponenten zu achten. Der Datendurchsatz ist in erster Linie von dem eingesetzten Codec abhängig. Für ein unkomprimiertes Gespräch werden 64 kbit/s 21 benötigt. Inklusive des Overheads macht dies maximal 80 bis 90 kbit/s pro Verbindung aus. Der Overhead setzt sich aus der Summe der eingekapselten Header zusammen, wie in Abbildung 2.9 erkennbar ist. Ein Sprachpaket hat eine Länge von 20 ms. Daraus ergeben sich 50 Pakete pro Sekunde. Im Beispiel aus Abbildung 2.9 kommen 320 Bit pro Paket als Summe der Header zusammen. Multipliziert mit 50 ergibt dies einen Overhead von 16 kbit/s. Abbildung 2.9: Overhead durch Header-Einkapselung Abtastungen pro Sekunde bei 8 bit Quantisierung = 64 kbit/s; Standard G Eigene Darstellung 24

32 Somit ist sicherzustellen, dass in jede Richtung, also sowohl für Up- und Downlink, ungefähr 100 kbit/s pro Verbindung zur Verfügung stehen, da andere Gespräche oder Datenverbindungen die Leitung zusätzlich belasten. Außerdem muss beachtet werden, dass im Falle eines ADSL-Anschlusses (Asymmetric Digital Subscriber Line) der Uplink deutlich kleiner ist als der Downlink. Die Ende-zu-Ende-Verzögerung, auch als Delay bezeichnet, ist die Zeit, die ein Sprachpaket für die Strecke vom Mund des Senders bis zum Ohr des Empfängers benötigt. Dabei spielen die Verzögerungen, die durch die Übertragung im IP-Netz zustande kommen, eine große Rolle. Vor allem durch Zwischenspeicherung in Routern wird die Übertragung verzögert. Ist ein Router überlastet, so muss das IP-Paket warten oder es wird gar verworfen. Abbildung 2.10 illustriert die Abhängigkeit der Nutzerzufriedenheit von der Übertragungsqualität. Von der ITU-T ist die Ende-zu-Ende-Verzögerung in drei Teile klassifiziert. Abbildung 2.11 zeigt eine Einteilung in diese Klassen, sowie einen zugehörigen MOS-Wert (Mean Opinion Score) und die Nutzerzufriedenheit einer Verbindung. Bis zu einer Verzögerung von 150 ms sind keinerlei Einschränkungen gegeben. Im Bereich von 150 bis 300 ms kann die Qualität noch als akzeptabel angesehen werden, empfindliche Nutzer stören sich jedoch schon daran. Eine Verzögerung größer als 300 ms wird von immer mehr Nutzern als störend empfunden und ist daher nicht akzeptabel. 25

33 Abbildung 2.10: Abhängigkeit Übertragungsqualität und Nutzerzufriedenheit 23 Bewertung Übertragungseigenschaften Nutzer Zufriedenheit MOS R Nutzer sehr zufrieden Nutzer zufrieden einige Nutzer unzufrieden viele Nutzer unzufrieden fast alle Nutzer unzufrieden nicht empfehlenswert erstrebenswert akzeptabel nicht akzeptabel Abbildung 2.11: Abhängigkeit Nutzerempfinden und MOS-Wert 24 Bei der Planung eines Netzwerkes, wobei die Empfehlung G.114 der ITU-U berücksichtigt wird, darf eine maximale Verzögerung von 400 ms nicht überschritten werden. 23 Nach [WEB01, S. 9] 24 Nach [WEB02, S. 2] 26

34 C Codierer T 0 Übertragungszeit Telefon A zum Router D 0 Serialisierungsverzögerung beim Senden von Telefon A T 1 Übertragungszeit Router zu Telefon B D 1 Serialisierungsverzögerung beim Senden des Routers T CP Summe aus Codierungs- und Paketierungszeit E Empfänger T EE Ende-zu-Ende-Verzögerung P 1 P n Sprachpakete T JP Zeit im Jitter-Ausgleichspuffer R Router T Look-ahead Zeit für das Codieren S Sender T Seg Länge eines Segmentes S ein Sprachsegmente zum Senden t Ü Übermittlungszeit über das IP-Netz S aus erzeugte Sprachsegmente am Ziel τ 1 zufällige Wartezeit in Warteschlange vor Router Abbildung 2.12: Zusammensetzung der Ende-zu-Ende-Verzögerung 25 Die Ende-zu-Ende-Verzögerung setzt sich als Summe von verschiedenen Einflüssen zusammen. In Abbildung 2.12 ist dies schematisch dargestellt. Ein zu sendendes Signal wird in Segmente zerlegt. Bevor die Codierung eines solchen Abschnittes beginnen kann, muss erst die Zeitspanne vergehen, bis dieses Segment vollständig gesprochen und aufgenommen ist (T Seg ). Dazu addiert sich die Zeit für den Codier-Vorgang (T Look-ahead ). Diese Codierungs- und Paketierungszeit (T CP ) bleibt für die gesamte Übertragung konstant, da sie mit Hilfe der gleichen tech- 25 [BA05, S. 102] 27

35 nischen Möglichkeiten realisiert wird. Danach erfolgt das Senden der einzelnen Bits, genannt Serialisierungsverzögerung (D 0 ). Diese berechnet sich aus dem Quotient der Paketgröße in Bit geteilt durch die Übertragungsrate in Bit. Dazu wiederum addieren sich die Übertragungszeit zwischen Sender und Router (T 0 ) sowie eine zufällige Verweilzeit in der Warteschlange vor dem Router (τ 1 ). Hat das Paket den Router durchlaufen, fungiert dieser als Sender. Zur Verzögerungszeit summieren sich nachfolgend noch die Serialisierungsverzögerung des Sendevorgangs Router Empfänger (D 1 ), sowie die Übertragungszeit auf dieser Strecke (T 1 ). Abschließend beeinflusst ein letzter Wert die Verzögerungszeit: der Jitter-Ausgleichspuffer (T JP ). Die ausschlaggebenden Komponenten sind somit Codierung und Paketierung, die Übermittlungszeit 26 (t Ü ) im IP-Netz und der Jitter-Ausgleichspuffer. Eine Schwankung der Übermittlungszeit wird auch als Jitter bezeichnet. Da für die Übertragung von Sprachdaten bei VoIP eine möglichst gleichmäßige Verzögerung gefordert ist, sind Jitter-Ausgleichspuffer im Einsatz, welche die Pakete zwischenspeichern und in den zeitlichen Abständen wieder aussenden, in denen sie ihre Quelle verlassen haben. Sollte ein Paket zu dem Zeitpunkt, an dem es weitergeschickt werden soll, noch nicht eingetroffen sein, so wird es, wenn es später ankommt, am Ziel vernichtet und gilt als verloren. Diese Problematik ist ebenfalls in Abbildung 2.12 ersichtlich. Durch einen zu klein dimensionierten Jitter-Ausgleichspuffer ist P 2 zu dem Zeitpunkt der Sprachsegmenterzeugung noch nicht eingetroffen und gilt als verloren. Daher ist ein Zusammenhang zwischen der Paketverlustrate und der Zwischenspeicherungszeit im Jitter-Ausgleichspuffer zu erkennen. Je länger der Puffer die Pakete zwischenspeichert, umso niedriger die Paketverlustrate. Soll jedoch eine möglichst kurze Verzögerung realisiert werden, steigt die Wahrscheinlichkeit von Paketverlusten. Ein optimales Verhältnis zwischen den beiden Werten gibt es nicht, es ist immer ein Kompromiss. 26 Die Übermittlungszeit setzt sich aus den beiden Übertragungszeiten, der zufälligen Zeit in der Warteschlange vor dem Router und der Serialisierungsverzögerung beim Senden des Routers zusammen. t Ü = T 0 + τ 1 + D 1 + T 1 28