Fachhochschule Köln University of Applied Sciences Cologne 07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Elektrotechnik/NT Institut für Nachrichtentechnik Labor für Datennetze Diplomarbeit Erweitertes Accounting in VoIP-Netzen auf der Basis von SIP und RADIUS Student: Lotfi Faik Matrikelnummer: 11023333 Abgabedatum: 25.02.2005 Referent: Prof. Dr.-Ing. Andreas Grebe Korreferent : Dr. Andreas Kumpf
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Fachhochschule Köln University of Applied Sciences Cologne
07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Elektrotechnik/NT
Institut für Nachrichtentechnik Labor für Datennetze
Diplomarbeit
Erweitertes Accounting in VoIP-Netzen auf der Basis von SIP und RADIUS
Student: Lotfi Faik
Matrikelnummer: 11023333 Abgabedatum: 25.02.2005
Referent: Prof. Dr.-Ing. Andreas Grebe
Korreferent : Dr. Andreas Kumpf
Hiermit versichere ich, daß ich die Diplomarbeit selbständig angefertigt und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt habe.
2.7.2.2 Das Auffinden eines Servers ............................................................................ 42 2.7.2.3 SIP-Transaktionen............................................................................................ 43 2.7.2.4 Das Auffinden eines Benutzers ........................................................................ 43
5.1 VoIP-Netz....................................................................................................................... 72 5.1 SER (SIP-Express-Router) ............................................................................................. 73
5.2.1 Was ist SER?........................................................................................................... 73 5.2.2 Installation............................................................................................................... 74 5.2.3 Konfiguration .......................................................................................................... 75
a) Konfigurationsdatei.................................................................................................. 75 b) Datenbank und Datenbankbibliothek erstellen ........................................................ 77
5.3 Freeradius ....................................................................................................................... 81 5.3.1 Was ist Freeradius? ................................................................................................. 81 5.3.2 Installation und Grundkonfiguration....................................................................... 81
a) Radiusclient.............................................................................................................. 81 b) Radiusserver............................................................................................................. 82
5.3.4 Radius-Server starten und testen ............................................................................. 84 5.4 SER und Freeradius........................................................................................................ 85 5.5 MySQL-Datenbank ........................................................................................................ 86
6.3 Verbindungsdauer .......................................................................................................... 91 6.4 Type of Service .............................................................................................................. 93 6.5 Quality of Service........................................................................................................... 93
1. Einleitung Der in der ganzen Menschengeschichte unvergleichbare Fortschritt der Wissenschaft und
Technik im letzten Jahrhundert ist ohne die explosionsartige Entwicklung der
Kommunikation nicht vorzustellen.
Sichere und zuverlässige Kommunikation ist eines der wichtigsten Bestandteile der heutigen
Gesellschaft. Dabei handelt es sich sowohl um die verbale Kommunikation als auch um den
Austausch von Informationen über Fax oder Internet.
Auf das Telefon kann man heutzutage nicht mehr verzichten. Es bietet eine schnelle
Möglichkeit, direkt zu einer Person Kontakt aufzunehmen, und durch den Einsatz des mobilen
Telefons ist das Wissen des Aufenthaltsorts irrelevant geworden.
In den letzten zwanzig Jahren nahmen die technischen Möglichkeiten im Telefonieumfeld in
sehr kurzen Abständen rasant zu. So bietet z.B. ISDN1 vielfältige technische Möglichkeiten
neben dem „Nur-Telefonieren“.
Für die Übermittlung von nonverbalen Informationen bietet die Telefonie-Infrastruktur den
Fax-Service an, der jedoch primär für Texte, und nicht für Bilder geeignet ist.
Parallel dazu hat das Internet auch in den vergangenen zwanzig Jahren immer mehr an
Bedeutung gewonnen, vor allem beim nonverbalen Informationsaustausch.
Telefon und Internet sind jedoch zwei voneinander unabhängige Netzinfrastrukturen, die
getrennt gepflegt werden müssen.
Seit einigen Jahren bietet IP-Telefonie Sprachübertragung über IP2-basierte Netze, also über
das Internet, mit dem langfristigen Ziel, das separate Telefonnetz einsparen zu können.
Zunächst wird die Migration beider Netze nötig, wobei sich Komponenten beider Netze (IP-
Netz und PSTN3) gemeinsam nutzen lassen.
1 ISDN: Integrated Services Digital Network: Digitale Variante des herkömmlichen Telefonnetzes. ISDN stellt die Integration vieler einzelner Dienste wie Telefonie, Fax, Telex, typische leitungs- oder paketvermittelte Datendienste etc. in ein einheitliches Mehrdienstenetz dar. Die Vorteile liegen in einer besseren Sprachqualität, einer höheren Datendurchsatzrate und ein schnelleres Anwählen andere Telefonnummern. Die Telekomfirmen bieten in der Regel bei einem ISDN-Anschluss eine zweite Leitung sowie drei Rufnummern und weitere Serviceleistungen an. 2 IP: Internet Protocol: Die Aufgabe des Internet-Protokolls (IP) besteht darin, Datenpakete von einem Sender über mehrere Netze hinweg zu einem Empfänger zu transportieren. Die Übertragung ist paketorientiert, verbindungslos und nicht garantiert. IP garantiert weder die Einhaltung einer bestimmten Reihenfolge noch eine Ablieferung beim Empfänger. Empfangsquittungen gibt es auf IP-Schicht nicht. Die maximale Länge von IP-Datenpaketen ist auf 65.535 Bytes beschränkt. 3 PSTN: Public Switched Telephne Network. Öffentliches Telefonnetz, oft mit digitalen Vermittlungsstellen (Switches).
1. Einleitung
2
Abbildung 1: IP-Netz-PSTN-Migration
Legende: PSTN: Public Switched Telephone Network, POTS4: Plain Old Telephone Service, SIP5: Session Initiation Protocol, IP Phone: Internet-Protocol-Telefon.
Gateway: Verbindungseinrichtung zur Kopplung von Netwerken unterschiedlichster Art.
1.1 Begriffserklärung Bevor eine eindeutige Zielsetzung für diese Arbeit formuliert werden kann, sind grobe
Erklärungen der im gewählten Diplomarbeitstitel vorkommenden Begriffe unerlässlich.
Ganz am Anfang ist der Begriff „AAA“ kurz zu erklären, damit andere von ihm abhängige
Begriffe deutlich werden.
„AAA“ (Authentication, Authorization, Accounting) bezieht sich auf die Aufgaben
Authentication: Authentifikation, Echtheit des Benutzers feststellen,
Authorization: Autorisierung, Zugriffsberechtigung zu den gewünschten Diensten/Inhalten
prüfen und
Accounting: Kontierung/Leistungserfassung, also die Protokollierung von Art und Umfang
der genutzten Leistungen.
4 Unter POTS ist die analoge Telefonie zu verstehen, die eine Bandbreite von 3,1 kHz hat, die im Frequenzbereich von 300 Hz bis 3,4 kHz liegt. Dieser Frequenzumfang ist so gewählt, dass die Sprachübertragung verständlich ist und der Sprechende mit seinen Stimmcharakteristiken erkannt werden kann. 5 Das SIP-Protokoll ist ein Signalisierungsprotokoll für die IP-Telefonie, das im Rahmen dieser Diplomarbeit noch tiefer behandelt wird.
1. Einleitung
3
„VoIP“ ist die Abkürzung von „Voice over IP“ und wird auch auf Deutsch IP-Telefonie
genannt.
„SIP“ ist das „Session Initiation Protocol“: Protokoll zur Verbindungssteuerung für VoIP.
„RADIUS“ kürzt „Remote Authentication Dial-In User Service“ ab, und ist das wichtigste
AAA-Protokoll.
„Billing“ Unter diesem weit gefassten Begriff versteht man die Abrechnung der IT-
Leistungen für die Nutzung unterschiedlicher Netze und Dienste. Das Billing umfasst die
Sammlung der Verbindungs- und Übertragungsdaten, die Zuordnung der Daten, das so
genannte Accounting, das Rating mit der Zuordnung der verschiedenen Tarife, die
Rechnungsstellung, das Controlling und das Inkasso.
Für die Bezahlung von Einkäufen im Web bietet sich das Online-Billing an, von dem es
mehrere Bezahlsysteme gibt.
1.2 Motivation und Zielsetzung Diese Diplomarbeit ist eine Zusammenarbeit der Fachhochschule Köln mit der Firma TECON
Systems AG.
Diese entwickelt eigene Produkte und Software-Lösungen im Kundenauftrag, wobei das IT-
Accountig einer der Schwerpunkte ist.
Im IP-Telefonie-Bereich hat TECON ein Verfahren entwickelt (GEOVIPA), das ursprünglich
für die geographische Verzonung von VoIP-Verbindungen erdacht wurde und während der
Entwicklung verbessert und erweitert werden dürfte.
Mit neuen und innovativen Abrechnungslösungen für VoIP will TECON für die zukünftigen
Anforderungen im internationalen Markt „Akzente setzen“.
Da das Billing Ziel aller Prozesse ist, gerade bei Service Providern, die für ihre Leistungen
schließlich vergütet werden wollen, beabsichtigt TECON ihnen bei den neuen
Dies war der Hintergrund der Unterstützung dieser Diplomarbeit durch die Firma TECON.
Ihrerseits wurde das RADIUS-Protokoll als Basis der Entwicklung vorgeschlagen, um im
Rahmen dieser Arbeit detaillierte Accounting-Daten gewinnen zu können.
1.3 Aufbau der Arbeit Im ersten Teil dieser Diplomarbeit wird das nötige theoretische Wissen vorgestellt:
Kapitel 2: Voice over IP und seine Standards,
Kapitel 3: AAA, seine Architektur und seine Protokolle,
1. Einleitung
4
Kapitel 4: Die Funktionalität von RADIUS und deren Attribute, sowie das RADIUS-
Accounting und deren Konfigurationsoptionen.
Im Zweiten Teil wird die Entwicklungsumgebung vorgestellt, dies erfolgt in dem Kapitel 5.
In diesem Kapitel wird die Realisierung im Rahmen der Arbeit zusammengefasst, dabei
wurde eine Open-Source6-RADIUS-Variante (freeradius) installiert und in Betrieb
genommen.
Einen Open-Source-SIP-Server7, der eine einwandfreie Interoperabilität mit dem Freeradius-
Server zeigt, wurde ebenfalls installiert und konfiguriert. Hier wurde der SIP-Express-Router
eingesetzt.
Im Dritten Teil (Kapitel 6) wurden die eigentlichen Entwicklungen und der Kern dieser
Diplomarbeit vorgestellt. Die Arbeit umfasst insgesamt über 700 Zeilen selbst geschriebenen
Quellcode.
Kapitel 7 fasst die wesentlichen Ergebnisse zusammen und schließt mit einem Ausblick auf
weiterführende Arbeiten.
6 Der englische Ausdruck Open Source steht für quelloffen, einerseits in dem Sinne, dass der Quelltext eines Programms frei erhältlich ist, andererseits für 'offene Quelle', also dass ein Werk frei zur Verfügung steht. 7 SIP-Server ist eine Vermittlungsstelle der Teilnehmer im VoIP-Netz
2. VoIP (IP-Telefonie)
5
2. VoIP (IP8-Telefonie)
Unter IP-Telefonie im klassischen Sinn wird die Übertragung von Gesprächen direkt über das
Internet durch die Nutzung des Internet-Protokolls (IP) verstanden. Man verwendet dafür
verschiedene Begriffe, wie Internet Telefonie, IP Telefonie, Packet Voice und auch Voice
over IP.
Die erste Lösung für die Sprachübertragung über das IP-Daten-Netz führte die israelische
Firma VocalTec im Jahr 1995 vor.
2.1 Grundsätzliche Unterschiede zu PSTN Im klassischen Telefonnetz wird die Sprache in Form von unterschiedlich starken
elektrischen Impulsen über eine Leitung von einem Teilnehmer zum anderen übermittelt,
dabei wird ein Kanal während der Kommunikation durchgehend durchgeschaltet und nach
Kommunikationsende wieder für andere Teilnehmer freigegeben.
Bei VoIP wird die analoge Sprache in digitale Signale umgewandelt, die zu Paketen
zusammengefasst und an den Telefonpartner verschickt werden. Zwischen zwei Paketen ist
die Leitung frei für anderweitige Nutzung. Im Vergleich zur Telefonleitung, die für die Dauer
des gesamten Gesprächs belegt ist, können so Kapazitäten gewonnen werden.
Außerdem ist grundsätzlich von der Digitalisierung der Sprachsignale eine im Vergleich zur
analogen Telefontechnik Verminderung der Sprachqualitätsverlusten zu erwarten.
Doch in der Praxis macht das Telefonieren über das Internet die User noch nicht ganz
glücklich, da die Qualität der Audioübertragung und die Fähigkeit des Internets
Audioübertragung zu bieten, noch zu wünschen lässt. Das Problem liegt dabei vor allem in
der „veralteten“ Internet-Infrastruktur. Trotzdem ist das Interesse der Industrie an dieser Art
der Kommunikation sehr hoch. Organisationen rund um die Erde suchen Lösungen, um die
Kosten der immer wachsenden Kommunikation zu reduzieren. Viele Firmen suchen auch
Lösungen die Daten- und Audioübertragung auf ein Netzwerk zu legen und dadurch Kosten
zu sparen. Dies kann erreicht werden, wenn ein paketvermitteltes Netzwerk wie IP verwendet
wird, welches Daten und zur gleichen Zeit auch Audiodaten übertragen kann. Auch die
Video-Kommunikation im IP-Umfeld wird erleichtert.
Durch Softwarelösungen lassen sich noch zusätzliche Funktionen sehr einfach realisieren. An
Kosten wird auch gespart, da nicht in neue Hardware investiert werden muss. Individuelle
8 IP: Internet Protocol, eines der Basisprotokolle des Internet. Es gehört zu den verbindungslosen Protokollen, d.h. zwischen dem Sender und Empfänger der Daten muss keine direkte Verbindung bestehen.
2. VoIP (IP-Telefonie)
6
Kundenanforderungen sind ebenso leichter zu realisieren, da durch modulare
Programmierung Arbeitsabläufe und Strukturen leichter verändert werden.
2.2 VoIP-Varianten Es lassen sich drei VoIP-Varianten unterscheiden: Computer-zu-Computer, Computer-zu-
Telefon und Telefon-zu-Telefon.
Als das Thema Internet-Telefonie Ende 1994 aufkam, wurde darunter nur die Möglichkeit
verstanden, kostengünstige Telefonate zwischen zwei Computern über das Internet zu führen.
VoIP-Gateways ermöglichen seit 1996 Gespräche zwischen Computern und herkömmlichen
Telefonen. Sie verbinden das Telefonnetz (PSTN) mit einem IP-Netz und integrieren
Computer und Telefone in einem System.
2.2.1 PC-zu-PC-Telefonie
Die Sprachdaten werden zwischen zwei Computern ausgetauscht, die über das Internet bzw.
ein anderes IP-Netz miteinander verbunden sind. Bei dieser Variante müssen beide
Teilnehmer online sein, damit ein Gespräch zustande kommen kann.
Abbildung 2: PC-zu-PC-Verbindungen Als weitere Voraussetzung müssen beide Computer „sprachfähig“ sein, was gewisse
Anforderungen an Hard- und Software stellt. Neben einem Zugang zu einem IP-Netz und der
notwendigen IP-Telefonie-Software wird im Allgemeinen lediglich vorausgesetzt, dass die
Computer über eine Soundkarte, ein Mikrophon und die Möglichkeit zur Sprachausgabe
verfügen.
Anstelle der Kombination von Mikrophon und Lautsprecher wird sehr gerne ein Headset
eingesetzt. Dadurch steigt die Verständlichkeit der Kommunikation, der Benutzer hat mehr
Kopffreiheit und die Gefahr der Rückkopplung wird geringer.
Ein schneller Netzzugang, ein schneller Prozessor (einige Verfahren zur Sprachcodierung
benötigen diese Leistungsfähigkeit zur Echtzeitcodierung9) sowie spezielle DSP10-Karten
9 Dabei muss das Signal mit minimaler Verzögerung kodierbar und dekodierbar sein.
2. VoIP (IP-Telefonie)
7
tragen ebenfalls zur Verbesserung der Qualität bei. Diese Karten sind speziell für IP-Telefonie
entwickelt worden. Es lässt sich ein normales Telefon anschließen, um über das Internet zu
telefonieren, und die Karte verfügt über einen DSP-Chip zur Schnellen Codierung und
Decodierung der Sprache.
2.2.2 PC-zu-Telefon-Verbindungen
Um PC-zu-Telefon-Verbindungen oder Telefon-zu-Telefon-Verbindungen mit VoIP
realisieren zu können, sind auf jeden Fall VoIP-Gateways notwendig, da sie das
leitungsvermittelte Telefonnetz mit dem paketorientierten Internet verbinden.
Abbildung 3: PC-zu-Telefon-Verbindungen VoIP-Gateways lösen das Problem der Kontaktaufnahme, da sie nur noch die Eingabe der
herkömmlichen Telefonnummer des Gesprächspartners erwarten. Ein Gateway verfügt über
eine Schnittstelle zum Anschluss an das TCP/IP-Netz sowie eine ISDN-oder
Analogschnittstelle für den Anschluss an das Telefonnetz oder eine Nebenstellenanlage
(PBX11).
Auf der einen Seite erhält das Gateway das Telefonsignal, digitalisiert dieses, komprimiert es
(wenn nötig), teilt es in Paketen auf und überträgt es über das IP-Netz. Beim Empfang von
Daten aus dem IP-Netz führt der Gateway die Aufgaben in umgekehrter Reihenfolge aus.
Komprimierte Sprachdaten werden dekomprimiert und dann an das Telefonnetz geleitet.
Die Anwendung (Application) eines Gateways verwaltet die Verbindungen und sorgt für die
Umwandlung zwischen Telefonnummer und IP-Adresse.
10 DSP: Digital Signal Processor, spezieller Chip, der sinusförmige Signale (z.B. Sprache, Musik) durch mehrfaches Abtasten digitalisiert. Er wird z.B. in Soundkarten eingesetzt. [20] 11 PBX: Private Branch Exchange: ist eine Nebenstellenanlage, die via Telefonleitungen das öffentliche Telefonnetz mit den Endgeräten (Telefone, Faxgeräten) einer Firma oder eines großen Hauses verbindet, für Privathaushalte sind solche Lösungen oft überdimensioniert. Mit solchen Anlagen kann man viele Endgeräte gezielt miteinander verschalten und so ein eigenes Telefonnetz aufbauen. Speziell die Möglichkeit, innerhalb der Telefonanlage kostenlos telefonieren zu können, ist gerade für Firmen sehr interessant.
2. VoIP (IP-Telefonie)
8
Weitere Aufgaben, die von der Anwendung übernommen werden können, sind die
Organisation von Datenbankzugriffen, die Gebührenverwaltung, das Führen von
Verbindungsnachweisen und das Protokollieren von Fehlern.
2.2.3 Telefon-zu-Telefon-Verbindungen
Bei dieser Variante werden die Gespräche zwischen zwei herkömmlichen Telefonen geführt.
An den Übergangspunkten zwischen Internet und Telefonnetz arbeiten jeweils Telefon-
Gateways.
Abbildung 4: Telefon-zu-Telefon-Verbindungen
Bei Internet-Telefonaten zwischen Telefonen werden die Daten zunächst über das
Telefonnetz an einen VoIP-Gateway in der Nähe des Empfängers übertragen. Die Auswahl
des Zielgateways kann nach unterschiedlichen Kriterien erfolgen (Zuverlässigkeit,
Geschwindigkeit oder Kosten der Verbindung). Der Zielgateway stellt die Verbindung in das
öffentliche oder private Telefonnetz her und leitet die Daten zum Empfänger weiter.
Die deutsche Telekom ermöglichte Ende 1997 in einem Pilotprojekt ausgewählte Kunden das
Führen von Telefonaten über das Internet. Bei diesem Projekt arbeitete die Deutsche Telekom
mit dem Internet-Telefonie-Pionier VocalTec zusammen. Das Projekt wurde nach einer
Testphase wieder eingestellt.
Die deutsche ABC Bücherdienst GmbH in Regensburg setzte ein VoIP-Gateway-System des
amerikanischen Unternehmens Lucent Technologies ein, um Telefongespräche zwischen
Standorten in Deutschland und den USA über das Internet zu leiten. Die Qualität der
Verbindungen wird von Seiten des deutschen Unternehmens positiv beurteilt.
Wie bei allen Varianten, steht auch bei der Telefon-zu-Telefon-Variante mögliche
Kosteneinsparungen im Vordergrund. Potentielle Dienstanbieter sind neben den traditionellen
Telefongesellschaften Unternehmen wie IDT, Global Exchange oder Delta Three, die als so
2. VoIP (IP-Telefonie)
9
genannt Internet Telephony Service Provider (ITSP) VoIP-Dienste anbieten und sich zu den
Telefongesellschaften der nächsten Generation entwickeln könnten. Als in Betracht
kommende Kunden für deren Dienste sieht die ITU12 die über 700 Millionen
Telefonteilnehmer.
Alle drei verschiedenen VoIP-Varianten (PC-zu-PC, PC-zu-Telefon und Telefon-zu-Telefon)
können in einem integrierten Kommunikationssystem kombiniert werden. Ein System, in dem
mehrere Gateways zu einem großen System verbunden sind, wird auch als Virtual Unified
Network bezeichnet.
2.3 Funktionsweise der IP-Telefonie Dieser Abschnitt erläutert einige Begriffe aus der IP-Telefonie und stellt den Netzaufbau und
verschiedene Komponenten vor. Ferner wird erläutert, wie Endpunkte kontaktiert und
Mediendaten übertragen werden.
Grundsätzlich müssen zwei Arten von Datenströmen unterschieden werden:
• Signalisierungsdaten dienen zum Verbindungsaufbau, Steuerung von
Verbindungseigenschaften und zum Verbindungsabbau.
• Mediendaten enthalten die eigentlichen Sprachinformationen.
Für beide Datenströme werden separate Verbindungen verwendet.
2.3.1 Netzaufbau
Abbildung 5 zeigt ein Beispiel für ein IP-Telefonie-Netz mit einem Telefonie-Server,
Arbeitsplatz-Rechnern, die über IP-Telefonie-Software verfügen und IP-Telefonen. Über
einen Gateway kann eine Verbindung in das PSTN hergestellt werden.
12 ITU: International Telecommunications Union (Sitz in Genf): seit Jahrzehnten bestehende internationale Organisation von Herstellern und staatlichen Einrichtungen im Bereich der Telekommunikation, die auch Standards und Normen definieren.
2. VoIP (IP-Telefonie)
10
Abbildung 5: IP-Telefonie-Netzaufbau Anders als bei der herkömmlichen Telefonie kann bei der IP-Telefonie ein Endpunkt direkt
eine Verbindung zu einem anderen Endpunkt aufbauen. Den Endpunkten ist es freigestellt, ob
sie den Telefonie-Server nutzen oder nicht. Wenn sie es tun, müssen sie sich dort registrieren.
Eine Registrierung enthält unter anderem Informationen über den Endpunkt und dessen
Benutzer. Eine der wichtigsten Informationen ist die Adresse für die Anrufsignalisierung.
2.3.2 Komponenten
Endpunkt An einem Endpunkt kann ein Benutzer ein Telefonat annehmen oder initiieren.
Ein Endpunkt für Benutzerinteraktion kann ein IP-Telefon, also ein Telefon mit
Netzanschluss
und IP-Telefonie-Software, oder ein Rechner mit einer solchen Software sein. Endpunkte
verwenden eine Hierarchie von Protokollen zur Anrufsignalisierung, Medienaushandlung und
Mediendatenerzeugung und -Paketisierung. Über ein GUI (Graphical User Interface) kann
Benutzerinteraktion stattfinden.
Telefonie-Server Ein Telefonie-Server ist eine zentrale Instanz einer IP-Telefonie-Umgebung. Endpunkte
können sich bei ihm registrieren und erhalten Dienste von ihm wie z. B. die Lokalisierung
2. VoIP (IP-Telefonie)
11
eines Benutzers. Dies ist wichtig, da nicht immer klar ist, an welchem Rechner sich der
Benutzer gerade aufhält, da er eine IP-Telefonie-Anwendung auf jedem Rechner verwenden
kann. Für die Benutzerlokalisierung befragt der Server eine Datenbank. Bei einer
Registrierung teilt der Benutzer einem Telefonie-Server mit, unter welchen Aliasnamen er
erreichbar sein möchte. Ein Benutzer kann über eine Menge von Aliasnamen verfügen, die in
der Regel ein Name gefolgt von einer Domäne, z. B. [email protected], sind. Ein Anrufer
kann bei einem Telefonie-Server erfragen, wo sich der gewünschte Gesprächspartner
befindet. Der Server ist in der Lage, einem Aliasnamen eine entsprechende Transportadresse
zuzuordnen. In einem IP-Telefonnetz können mehrere Telefonie-Server parallel arbeiten.
Sollte der gewünschte Benutzer bei einem anderen Server registriert sein, so kann der erste
Server bei dem anderen die Transportadresse des Benutzers erfragen, da er selber keine
Informationen über den Benutzer besitzt. Für den Anrufer bleibt dieser Vorgang verborgen.
Ein Telefonie-Server kann Anrufe genehmigen oder ablehnen. Die Entscheidung kann von
unterschiedlichen Faktoren abhängig sein. Denkbar sind Faktoren wie:
- Wer ist der Benutzer? Hat dieser spezielle Privilegien?
- Wie stark ist das Netz ausgelastet? Überschreitet ein weiteres Gespräch die Kapazität
des Netzes?
- Verursacht das Gespräch Kosten, die nicht entstehen dürfen?
Gateway Ein Gateway verbindet verschiedene Netze miteinander, wodurch z. B. ein Telefonat von
einem IP-Netz in das PSTN möglich ist. Ein Gateway übersetzt dazu die Anrufsignalisierung
des einen Netzes in die des anderen. Auch die Datenströme werden aufeinander abgebildet
und übersetzt.
Abbildung 6: Anrufbeispiel von PSTN nach IP
2. VoIP (IP-Telefonie)
12
Abbildung 6 zeigt ein Anrufbeispiel von einem Anschluss im PSTN zu einem Rechner mit IP-
Telefonie-Software. Betrachtet wird dabei nur die Anrufsignalisierung. Der Anrufer wählt die
gewünschte Nummer. Da er von einem normalen Telefon anruft, stehen ihm nur Ziffern zur
Verfügung. Die Nummer 218-9999 ist einem Gateway des Betreibers des IP-Netzes
zugeordnet. Dort wird festgestellt, dass der Benutzer mit dem Aliasnamen 2800 gewünscht
wird. Der Gateway wendet sich an einen Telefonie-Server, der feststellt, dass die Nummer
2800 dem Benutzer „bunti“ zugeordnet ist, und dass dieser sich an dem Rechner mit der IP-
Adresse 134.102.218.70 befindet. Daraufhin wird die Verbindung hergestellt.
2.3.3 Anrufsignalisierung
Bei der Anrufsignalisierung baut der anrufende Endpunkt eine Verbindung zum angerufenen
Endpunkt auf. In erster Linie geht es dabei darum, dass der angerufene Endpunkt weiß, dass
eine Gesprächsverbindung aufgebaut werden soll. Er kann dabei zusätzliche Informationen
über den anrufenden Endpunkt erfahren, z. B. den Namen oder die Telefonnummer des
Anrufers. In der IP-Telefonie ist der Kanal für die Anrufsignalisierung getrennt von dem
Kanal für die Mediendaten.
Abbildung 7: Anrufsignalisierung
Abbildung 7 zeigt vereinfacht, wie der Verbindungsaufbau abläuft. Der anrufende Endpunkt
(Endpunkt 1) signalisiert dem angerufenen Endpunkt (Endpunkt 2) seinen Verbindungs-
Wunsch. Endpunkt 2 signalisiert Endpunkt 1, dass er den Wunsch verstanden hat (Ringing)
und jetzt reagiert. Sobald der Benutzer das Gespräch angenommen hat, signalisiert Endpunkt
an Endpunkt 1, dass die Verbindung zustande gekommen ist (Connect). Nachdem Endpunkt 2
2. VoIP (IP-Telefonie)
13
über den Verbindungswunsch Bescheid weiß, handeln die beiden Endpunkte den Codec13 aus,
mit dem die Sprachinformationen übertragen werden. Anders als im PSTN können bei der IP-
Telefonie verschiedene Kodierungsverfahren verwendet werden.
Wenn die Anrufsignalisierungsphase beendet ist, bleibt der Kanal dennoch bestehen, da
Steuerinformationen für das Gespräch weiterhin über diesen Kanal ausgetauscht werden.
Diese Steuerinformationen können z. B. Übergabe an einen anderen Gesprächspartner oder
Beenden des Gespräches sein.
2.3.4 Medienübertragung
Die Verbindung für die Mediendaten wird nach der Codec-Aushandlung geöffnet und erst
beim Beenden des Gespräches oder bei einer Änderung des Codecs wieder geschlossen.
Bei der herkömmlichen Telefonie gibt es nur einen Kanal für die Mediendaten, der
leitungsorientiert ist. VoIP ist hingegen - wie vorhin erwähnt - paketorientiert, wobei die zu
übertragenen Daten (Pakete) verschiedene Wege nehmen.
2.3.5 Transportprotokolle
Die Nutzer von TCP/IP-Netzwerken haben grundsätzlich die Wahl zwischen TCP
(Transmission Control Protocol, RFC14 793) und UDP (User Datagram Protocol, RFC 768)
als Transportprotokoll.
Abbildung 8: TCP und UDP im TCP/IP-Protokollstack15
Der Unterschied zwischen den Transportprotokollen TCP und UDP liegt darin, dass das TCP
ein verbindungsorientiertes Protokoll ist. Das heißt, beim TCP-Protokoll wird zwischen zwei
13 Codec: Abkürzung für Coder/Decoder oder Compressor/Decompressor [20] (siehe Kapitel 2.5) 14 RFC: Die Requests for Comments (kurz RFCs; zu Deutsch etwa „Bitten um Kommentare“) sind eine Reihe von technischen und organisatorischen Dokumenten zum Internet, die am 7. April 1969 begonnen wurde. 15 Standard von IEEE zum Aufbau lokaler Netzwerke, IEEE (Institute of Electrical and Electonicss Engineers) ist der weltweit größter professioneller Zusammenschluss von Ingenieuren.
2. VoIP (IP-Telefonie)
14
Sockets (Verbindungsendpunkten) eine Verbindung aufrechterhalten, solange die
Kommunikation zwischen Client und Server anhält.
Beim UDP-Protokoll muss keine schon aufgebaute Verbindung zwischen Client und Server
bestehen, sondern dem so genannten Datagramm (Nutzinformation) wird nur der Endadressat
mitgegeben, ob dieser nun erreichbar ist oder nicht.
Es ist somit direkt eingeplant, dass das Datagramm seinen Kommunikationspartner gar nicht
erreicht, falls dieser zurzeit nicht bereit ist, Daten zu empfangen.
TCP ist zur Übertragung von Datenströmen gut geeignet und effizient, solange der
Datentransport nicht an Zeitgrenzen gekoppelt ist. Eine eigentlich positive Eigenschaft des
TCP-Protokolls, nämlich nicht eingetroffene Datenpakete erneut anzufordern, hat eine
zeitverzögernde Wirkung auf den Datentransport, so dass man zumeist das UDP-Protokoll bei
VoIP-Applikationen einsetzt.
TCP wird dagegen in den meisten VoIP-Signalisierungsprotokollen für den Anrufaufbau
verwendet.
Da aber UDP ohne weitere Mittel zur Übertragung von isochronen16 Audio- und Videodaten
nicht ausreicht, benutzt man z.B. die IETF17-Empfehlungen RTP (Real Time Transfer
Protocol, RFC 1889) bzw. RTCP (Real Time Control Protocol).
RTP und RTCP wurden als Echtzeit-Transportprotokolle entwickelt und dienen dem Ende-zu-
Ende-Transport von Echtzeitdaten. Innerhalb des RTP-Headers befindet sich unter anderem
ein Datenfeld, das einen Zeitstempel (Timestamp) enthält, um die Echtzeitdaten zu
synchronisieren.
Die im folgenden kommenden Abschnitte 2.7 und 2.8 stellen zwei verschiedene Standards der
IP-Telefonie vor: H.323 und SIP. Beide Standards definieren eine Anrufsignalisierung für IP-
basierte Netze. Für den Transport der Mediendaten verwenden beide Standards RTP.
16 Eine isochrone Übertragung zeichnet sich dadurch aus, dass die vom Sender zu übertragenden Datenpakete in einem gleichmäßigen Abstand gesendet werden und beim Empfänger in gleichmäßigem Abstand ankommen. Die Verzögerung der zu übertragenden Daten muss in so engen Grenzen liegen, dass dies zu keinem Fehlverhalten der Anwendung führt. Isochrone Anwendungen sind z.B. Sprach und Videoübertragungen von Live-Ereignissen. 17 IETF ist eine internationale Organisation, die Standards für Internetprotokolle definiert. Die von der IETF festgeschriebenen Standards werden in so genannten RFC’s veröffentlicht.
2. VoIP (IP-Telefonie)
15
2.4 Quality of Service Den Begriff Quality of Service (QoS) kann man definieren als die Fähigkeit, eine gewisse
Sicherheit bezüglich der Erfüllung von Dienstanforderungen (z.B.: Verständlichkeit der
Sprache, kein Echo etc) bieten zu können. Hinsichtlich der Sprachqualität könnte man QoS
als eine Anzahl der folgenden Bedingungen für eine ausreichende Verständlichkeit der
Sprache definieren:
Die Bandbreite muss ausreichend sein und dauerhaft zur Verfügung stehen
Zeitdingungen wie Verzögerung (Delay) und Verzögerungsschwankung (Jitter)
müssen eingehalten werden
Geringer Prozentsatz an verloren gegangenen Daten und gute Sprachkodierer
Diese Bedingungen gelten sowohl für kanalorientierte GSTN-Netze18 als auch für die
paketorientierte IP-Telefonie. Eine QoS sollte immer Ende zu Ende zwischen zwei
kommunizierenden Partnern zur Verfügung stehen. Das bedeutet, dass QoS auf dem gesamten
Weg durch das Netz von allen Netzelementen unterstützt werden muss. Die paketoreintierte
IP-Telefonie hat spezielle Eigenschaften wie lange Verzögerungen, Jitter und Paketverluste.
Das Thema QoS ist einerseits durch viele ITU-Empfehlungen, Arbeiten von ETSI TIPHON19
(Work Group 5) bzw. in der IETF und durch viele Forschungsprojekte abgedeckt. [18]
2.4.1 Verzögerung (Latency)
Ein großes Problem bei der Übertragung von Audio- oder Videodaten sind die Verzögerungs-
(delay time) oder Wartezeiten des Empfängers während der er auf gesendete Daten warten
muss.
Es gibt zwei arten von Verzögerungen: die Ausbreitungsverzögerung (Propagation-Delay)
und die Verarbeitungszögerung (Handling-Delay). Die Ausbreitungs-Verzögerung wird durch
die Lichtgeschwindigkeit in Glasfaser oder kupferbasierte Netzwerken verursacht.
Die Verarbeitungsverzögerung, auch Prozess-Verzögerung genannt, umfasst viele
verschiedene Verzögerungsursachen (momentane Paketrate, Komprimierung und Paket-
Switching) und wird durch Geräte verursacht, die den Frame durch das Netzwerk
18 GSTN: General Switched Telefone Network, Bezeichnung für kanalorientierte Telefonnetze. Diese gliedern sich in das öffentliche Festnetz (PSTN) und das öffentliche Mobilfunknetz, das Public Land Mobile Network PLMN. 19TIPHON: Abkürzung für Telecommunications and Internet Protocol Harmonization Over Networks. Projekt des ETSI (European Telecommunications Standards Institute) zur Erarbeitung von Schnittstellen und Rahmenvereinbarungen für die Architektur der Zusammenschaltung von leistungsvermittelnden und paketorientierten öffentlichen Netzen. Dies dient v.a. der Internet-Telefonie auf der Basis der H.323-Protokollfamilie.
2. VoIP (IP-Telefonie)
16
weiterleiten.
Für die Sprachübertragung im klassischen Telefonnetz wurden maximale Ende-zu-Ende-
Laufzeiten definiert, die für den nationalen Bereich 25 ms und für den internationalen Bereich
150 ms betragen dürfen.
Innerhalb eines normalen TCP/IP-Netzwerks kommt es bei der Datenübertragung zu
Verzögerungen von bis zu mehreren 100 ms, die auf der Einteilung der Nutzinformationen in
einzelne Datenpakete sowie auf dem Zusammensetzen einzelner Datenpakete zu einem
Ganzen basieren.
Auch aktive Netzwerkkomponenten, wie z.B. Switches oder Router beeinflussen die
Verzögerungszeiten der zu übertragenden Datenpakete innerhalb eines TCP/IP-Netwerks
sehr.
Netzwerk-Hardware Verursachte Verzögerung
Bemerkungen
Netzwerkkarte 0,2 – 1 ms Abhängig vom Netzwerk-karten-Typ (1000 – 10 MBit/s)
Router 35 – 200 ms Abhängig vom Router-Typ
Switch (Layer 2) 35 – 100 ms Abhängig vom Switch-Typ
Switch (Layer 3) 70 – 250 ms Hardware-basierter Switch
Switch (Layer 3) > 120 ms Software-basierter Switch
Firewalls oder Proxy-Server > 400 ms
Tabelle 1: Typische Verzögerungszeiten durch klassische Netzwerkhardware Dagegen übertrug Cisco den Hauptteil des Framing und der Paketformung auf den DSP
(siehe Kapitel 2.2.1), um den Router-Overhead möglichst gering zu halten. Der Real Time
Transport-Protokoll-(RTP)Header wird z.B. im DSP auf den Frame gesetzt, anstatt dem
Router diese Aufgabe zu überlassen.
Kommt es wegen mangelnder Bandbreite innerhalb eines TCP/IP-Netzwerks zu erhöhten
Kollisionen20 und somit zu einer erhöhten Anzahl von Datenpaketen, die wiederholt vom
20 Grund für Kollisionen ist es, dass bei dem CSMA/CD-Verfahren (Carreir Sense Muliple Access with Collision Detection) eine sendwillige Station im Netzwerk horcht, ob Datenpakete übertragen werden. Ist dies nicht der Fall, so fängt sie an, ihre Daten auf das Netzwerk zu geben. Tut dies gleichzeitig eine andere Station, kommt es zu einer Kollision, die zu einer Verwerfung der zu übertragenen Daten und zu einem Abbruch der Übertragung führt, sowie zu einer weiteren Verzögerung, bis die Stationen erneut versuchen, ihr Daten zu übertragen.
2. VoIP (IP-Telefonie)
17
Sender zum Empfänger übertragen werden müssen, so wird die gesammte Verzögerungszeit
rasant anwachsen.
Die einfachste Art, für ausreichende Bandbreite zu sorgen, ist die Überdimensionierung des
Netzes. Sie ist heute kurzfristig durchaus einsetzbar, in der Zukunft bei immer höher
werdenden Zugangsdatenraten und bei der hohen Konkurenzsituation zwischen den
Betreibern allerdings teuer.
Weiter Grund für die Verzögerung der Datenübertragung ist das Queuing. Wenn Pakete
wegen Datenstau an einer ausgehenden Schnittstelle in eine Queue (Warteschlange) gesetzt
werden, resultiert daraus eine Queuing-Verzögerung. Die Queuing-Verzögerung tritt auf,
wenn mehr Pakete ausgesendet werden, als die Schnittstelle in einem bestimmten Zeitraum
verarbeiten kann. Dagegen werden Bandbreitenreservierungen und Verkehrspriorisierungen
eingesetzt.
Um eine Bandbreite reservieren zu können, benötigt man eine Einteilung des Verkehrs in
verschiedene Qualitätsklassen. Dazu dienen Protokollfelder von TCP/IP wie das Type-of-
Service-Feld im IPv4-Header bzw. das Trafic-Class-Feld im IPv6-Header. Abbildung 9 zeigt
das Type-of-Service (TOS)-Feld von IPv4.
Precedence: Rangordnung
D: Deley, Verzögerung
Normal (0), Low (1)
T: Throughput,
Datenübertragungsbandbreite,
Normal (0), High (1)
R: Reability, Zuverlässigkeit
Normal (0), High (1)
C: Cost, Kosten
Normal (0), Minimale Kosten (1)
Abbildung 9: Type of Servise des IP-Headers des RFC 791 (IPv4) [16] Der Precedence-Bereich erlaubt es Routern in Zeiten großen Datenaufkommens, diejenigen
Daten herauszufiltern und als erste weiterzutransportieren, die den höchsten Rang oder die
höchste Priorität haben. Der Bereich Type of Service beschreibt die Eigenschaft der
gewünschten Datenübertragung.
Es ist auch notwendig verschiedene Prioritätsklassen in Routern zu realisieren, dafür besitzen
moderne Router hardwaremäßig eine bestimmte Anzahl von Warteschlangen (Queues).
2. VoIP (IP-Telefonie)
18
Außerdem erfolgt die Steuerung der einzelnen Warteschlangen über einen Mechanismus, der
entscheidet, welche Pakete welcher Warteschlangen für die Einhaltung der QoS-
Anforderungen als Nächstes nach einer festgelegten Regel gesendet werden (Scheduling).
Man muss Scheduling-Methoden einsetzen, die den Spachverkehr bevorzugen. Dazu gehört
LLQ21, die von vielen genutzt wird, die VoIP-Netzwerke in Umgebungen mit geringen
Bandbreiten einsetzen (weniger als 768 Kbps).
2.4.3 Jitter
Einfach ausgedrückt ist Jitter die Zeitschwankung zwischen der Ankunft einzelner Pakete.
Jitter tritt nur in paketbasierten Netzwerken auf. In einer Paket-Sprach-Umgebung wird
erwartet, dass der Sender die Sprachpakete zuverlässig in einem regelmäßigen Intervall
überträgt (z.B. alle 20 ms ein Frame). Diese Sprachpakete können verzögert werden und nicht
im selben regelmäßigen Intervall an der empfangenden Station ankommen. Der Unterschied
zwischen dem Zeitpunkt, wann das Paket erwartet und dem Zeitpunkt, zu dem es wirklich
empfangen wird, ist Jitter. [16]
Daher wird ein Jitter-Puffer benötigt, der diese dynamische Paketverzögerung verschleiert.
Abbildung 10: Delay und Jitter im paketbasierten Netzwerk [15]
Viele Hersteller haben sich für den Einsatz von statischen Jitter entschieden, im Gegensatz zu
Cisco. In der Cisco IOS22-Software werden RTP-Zeitstempel verwendet, um zu bestimmen,
wie groß der Jitter innerhalb des Netzwerks ist. Der Jitter-Puffer von Cisco wächst oder
21 LLQ: Low Latency Queuing, dieser Queuing-Mechanismus wurde entwickelt, um Sprachverkehr absolute Priorität vor jedem anderen Verkehr auf einer Schnittstelle einzuräumen. 22 IOS: Internetwork Operating System ist das Betriebssystem von Cisco-Routern und Switches. Dieses wird beim Einschalten des Gerätes aus dem nichflüchtigen Flash-Speicher in den Hautspeicher geladen und stellt die grundlegenden Funktionen des Routing und/oder Switching zur Verfügung.
2. VoIP (IP-Telefonie)
19
schrumpft dynamisch, je nach Verzögerungsvarianz der letzten empfangenen Paketen und ist
somit ein dynamischer Jitter-Puffer.
2.4.4 Echo
Unter Echo versteht man das zeitversetzte Hören seiner eigenen Stimme durch Verzögerung
auf der Übertragungsleitung und Rückkopplung beim Empfänger. Alle heutigen
Sprachdienste reflektieren einen gewissen Anteil des Signals zurück zum Sender.
Man kann drei Arten von Echo unterscheiden:
• Das elektrische Echo stammt aus einer Fehlanpassung der Impedanzen beim Übergang
vom vieradrigen Netzwerk-Switch auf die Zweiadrige lokale Schleife (wie in
Abbildung 11 gezeigt). Eine Impedanzanpassung ist wegen der unbekannten
Impedanz der Zweidrahtleitung nicht möglich.
• Das akustische Echo stammt aus der akustischen Rückkopplung zwischen
Lautsprecher und Mikrofon.
• Das einzige erwünschte Echo ist der so genannte „Sidetone“, der das Hören der
eigenen Sprache im Lautsprecher des Telefons mit geringer Verzögerung
bezeichnet.[18]
Abbildung 11: Durch nicht abgestimmte Impedanzen erzeugtes Echo [16]
Das Echo beeinflusst ganz wesentlich die Sprachqualität, wobei diese negative Beeinflussung
von der Verzögerung im Hin und Rückrichtung und dem Amplitudenunterschied zwischen
dem Ursprungs- und Echosignal ab. Dieser Amplitudenunterschied wird durch den Faktor
TELR (Talker Echo Loudness Rating) in der ITU G.122 beschrieben.
Maßnahmen zur Echokompensation sind ab einer Echo-Verzögerung von 20 – 30 ms
unausweichlich; eine billige Variante zur Echokompensation sind Echounterdrücker (Echo
Supressors), die eine hohe Dämpfung in den Sendepfad einschalten, wenn der andere
Teilnehmer spricht. Diese Methode wird vor allem in billigen Endgeräten bei
2. VoIP (IP-Telefonie)
20
Freisprecheinrichtungen angewendet und hat den Nachteil einer Sprachunterdrückung, wenn
beide Teilnehmer gleichzeitig sprechen.
In der öffentlichen Telefonie werden Echosperren (Echo Cancellers) eingesetzt, die viel
komplexer als Echounterdrücker sind, Echosperren schätzen den Echoanteil des Empfängers
im Retoureweg zum Sender und subtrahieren diesen Anteil vom tatsächlichen Signal. Dazu
wird ein mathematisches Model zusammen mit dem Ursprungssignal dazu verwendet, das
Echo abzuschätzen. Moderne Echosperren können sich an das Signal und die Empfänger-
Eigenschaften anpassen und werden mit digitalen Signalprozessoren (DSP’s) realisiert.
Grundsätzlich sind Echosperren adaptive digitale Filter (FIR: Finite Impulse Response). Beim
Beginn eines Gesprächs benötigt der Echokompensierer eine gewisse Zeit, um sich optimal
einzustellen. Für eine Echofreie Verbindung in beide Richtungen ist eine Echosperre an
beiden Enden notwendig.
2.4.5 Paketverluste (Packet Loss)
Verluste von Sprachpaketen sind in TCP/IP-Netzen keine Besonderheiten und haben zwei
Ursachen:
Die erste Ursache sind Verstopfungen im Netz, die zu einem hohen Füllgrad der
Warteschlangen in den Routern und damit zu einem Verwurf von Paketen führen. Bei der
Verwendung von TCP führ ein Paketverlust zu einer Wiederholung der Übertragung. Bei der
Übertragung der Sprache über TCP/IP würde eine wiederholte Übertragung nichts nützen, da
nur ein kleines Zeitfenster zu Rekonstruktion der Sprachinformation zu Verfügung steht und
daher UDP ohne Übertragungssicherheit verwendet wird. Um Paketverluste zu vermeiden,
sind Mechanismen wie beispielsweise DiffServe für den hochprioren Sprachverkehr
erforderlich, die einen garantierten Durchsatz bei minimalen Paketverlusten für priorisierten
Verkehr ermöglichen.
Die zweite Ursache für den Verlust von Sprachpaketen sind hohe Verzögerungen, wodurch
die Pakete außerhalb des Jittebufferbereichs verzögert eintreffen und daher verworfen werden.
Eine Verbesserung kann durch einen genügend großen Jitterbuffer erzielt werden, was
allerdings die Gesamtverzögerung vergrößert. [18]
Verluste, die 5 – 10 Prozent aller Sprachpakete überschreiten, können die Sprachqualität
signifikant verschlechtern wie folgende Abbildung 12 zeigt, dabei ist MOS (Mean Opinion
Score) eine Größe zur Bewertung der Sprachqualität (1: Schlecht bis 5: exzellent), (siehe
Kapitel 2.5.3).
2. VoIP (IP-Telefonie)
21
1
2
3
4
5
1 3 5 7 9 11 13 15 17 19
Verlust von Sprachdaten [%]
MO
S
Abbildung 12: Verschlechterung der Sprachqualität durch Paketverluste [18]
Wie aus der Abbildung ersichtlich ist, führen schon geringe Paketverlustraten kleiner 5
Prozent zu Qualitätseinbußen. Daher ist ein geringer Paketverlust kleiner 2 Prozent
anzustreben.
Für die Erkennung von verloren gegangenen Paketen verwenden die Gateways die
Sequenznummer im RTP-Headers. Die verlorenen Sprachpakete können zur Verbesserung
der Sprachqualität rekonstruiert oder versteckt werden (Packet Loss Concealment – PLC).
Die einfachste PLC-Methode ist die Stummschaltung (Silence Substitution) für Verlustraten
unter 1 Prozent, indem bei Paketverlust einfach stumm geschaltet wird. Eine bessere,
ebenfalls einfache Methode ist die Wiederholung des letzten Pakets (Packet Repetition), bei
der bei Paketverlust das letzte korrekt empfangene Sprachpaket wiedergegeben wird. Auch
dieses häufig verwendete Verfahren ist nur bei geringeren Paketverlusten anwendbar.
Bei höheren Paketverlusten sind ausgeklügeltere Maßnahmen notwendig: Eine Möglichkeit
ist die Paketinterpolation (Packet Interleaving), die die verlorenen Sprachpakete durch ein
Bei normalen Gesprächen spricht eine Person und die andere hört zu. Die heutigen
gebührenpflichtigen Netzwerke enthalten einen bidirektionalen Kanal mit 64000 Bit pro
Sekunde (Bps), ganz gleich, ob irgendjemand spricht. Das bedeutet, dass bei einem normalen
Gespräch etwa 50 Prozent der gesamten Bandbreite verschwendet wird. Die Menge der
2. VoIP (IP-Telefonie)
22
verschwendeten Bandbreite kann in Wahrheit noch viel höher sein, wie sich herausstellt,
wenn Sie eine statistische Aufzeichnung der Unterbrechungen und Pausen im normalen
Sprachmuster einer Person vornehmen.
Beim Einsatz des VoIP man diese „verschwendete“ Bandbreite für andere Zwecke nutzen,
wenn die Sprach-Aktivitäts-Entdeckung (VAD: Voice-Activity-Detection) aktiviert ist. Wie
in Abbildung 13 gezeigt, funktioniert VAD durch eine Messung der Sprachstärke in Dezibel
(dB) und durch die Entscheidung, wann die Sprache nicht mehr in Frames eingebunden wird.
Abbildung 13: Sprach-Aktivitäts-Entdeckung [16] Wenn die VAD einen Abfall der Sprachamplitude bemerkt, wartet sie gewöhnlich eine
bestimmte Zeitdauer, bevor sie aufhört, die Sprachframes in Pakete zu verpacken. Diese feste
Zeitdauer wird als Überhang {Hangover) bezeichnet und beträgt in der Regel 200 ms.
Bei jeder Technologie treten Nachteile auf. VAD erfährt bestimmte innere Probleme bei der
Bestimmung, wann Sprache endet bzw. beginnt und bei der Unterscheidung zwischen
Sprache und Hintergrundrauschen. Wenn sich ein Gesprächsteilnehmer also in einem Raum
voller Geräusche befindet, kann VAD nicht zwischen Sprache und Hintergrundrauschen
unterscheiden. Dies wird auch als Signal/Rausch-Grenzwert (Signal-to-Noise Threshold;
siehe 13) bezeichnet. In diesen Szenarien deaktiviert sich die VAD zu Beginn des Anrufs
selbständig.
Ein weiteres Problem der VAD ist die Erkennung, wann die Sprache einsetzt. Gewöhnlich
wird der Beginn eines Satzes abgeschnitten. Dieses Phänomen wird als Front-End-Speech-
Clipping bezeichnet. Normalerweise bemerkt die zuhörende Person das Front-End-Speech-
Clipping nicht. [16]
2.5 Codecs
2. VoIP (IP-Telefonie)
23
In Kapitel 2.1 wurde schon darauf hingewiesen, dass bevor ein Telefongespräch über das
Internet geführt werden kann, muss das analoge Audiosignal in ein digitales Signal
umgewandelt werden.
Dieser Prozess, sinnigerweise „Digitalisierung“ genannt, unterteilt sich in drei Schritte:
Abtastung (oder auch Sampling), Quantisierung und Kodierung.
Beim Sampling wird das analoge Signal in einer bestimmten Frequenz über die Zeit
abgetastet und nur die zu diesen diskreten Zeitpunkten gemessenen Werte werden weiter
berücksichtigt, alle anderen verworfen. Somit haben wir eine endliche Anzahl von Werten,
die aber immer noch potentiell beliebig genau sein können. Dieses Problem wird durch den
zweiten Schritt, die Quantisierung, gelöst. Die beliebig genauen Werte werden schlicht auf
den nächsten diskreten Wert gerundet, die so genannten Quantisierungsintervalle. Bei diesem
Runden entstehen natürlich Fehler, da nicht der exakte, sondern nur der gerundete Wert
abgespeichert wird. Sind zu wenig Quantisierungsintervalle vorhanden, kann dieser Fehler zu
hörbaren Qualitätseinbußen führen. Man nennt diesen Effekt daher auch
Quantisierungsrauschen oder Quantisierungsfehler.
Unter Kodierung versteht man ganz einfach die Beschreibung der Quantisierungsintervalle
durch bestimmte binäre Codewörter. Dies schließt den Prozess analog-digital-Wandlung ab
und wir haben nun ein rein digitales Signal vorliegen. Das Wiederherstellen der analogen
Signale aus den digitalen wird als Dekodierung bezeichnet.
Ein Codec (Coder/Decoder) ist ein Algorithmus, der die Aufgabe der Kodierung und
Dekodierung erfüllt. Die Abkürzung Codec steht aber auch für (Compressor/Decompressor).
Abbildung 14: Sprachkodierung für die Internetübtragung23 [27] Da oft nur eine geringe Bandbreite zur Verfügung steht, ist auch eine entsprechende
Komprimierung des Signals notwendig. Dabei wird eine möglichst hohe Sprachqualität bei
23 De-Jitter-Buffer zur Paketverzögerungsverschleierung (Kapitel 2.4.3)
2. VoIP (IP-Telefonie)
24
einer möglichst niedrigen Datenrate angestrebt. Wählt man dabei ein Kodierverfahren mit
niedriger Bitrate und hoher Kompression, so ist beim Kodieren und Dekodieren viel
Rechenleistung notwendig. Steht diese nicht zur Verfügung, so muss zwangsläufig ein
Verfahren verwendet werden, bei dem die Bitrate höher ist.
Das Sprachsignal wird beim Sender kodiert, über das Internet übertragen und beim
Empfänger dekodiert, also für die Wiedergabe in ein analoges Signal umgewandelt. Die
wichtigste Forderung an das verwendete Kodierungsverfahren ist: das Signal muss in
Echtzeit, das heißt mit minimaler Verzögerung, kodierbar und dekodierbar sein.
Taugliche Verfahren lassen sich in den im kommenden Kapitel folgenden Hauptgruppen
einteilen.
Abbildung 15: Sampling und 8-Bit-Kodierung eines Analogsignals [15]
2.5.1 Kodierungsverfahren
• Signalformkodierung Dabei wird das Analogsignal mit einer geeigneten Quantisierung, um die Originalform
des Signals möglichst fehlerfrei zu reproduzieren. Die einfachste und am weitesten
verbreitete Möglichkeit zur Realisierung dieses Verfahrens ist die Pulse Code Modulation
(PCM).
Das Nyquist-Theorem besagt, dass bei einer Aufnahme eines analogen Signals mit der
doppelten Rate der höchsten noch interessanten Frequenz dieses Signals aus der
Aufnahme heraus wieder genau in seiner analogen Form rekonstruiert werden kann. Da
der meiste Sprachinhalt unter 4000 Hz liegt, ist eine Aufzeichnungsrate von 8000
Aufnahmen pro Sekunde (125 ms zwischen den Aufnahmen) erforderlich.
2. VoIP (IP-Telefonie)
25
PCM benutzt diese Abtastrate und eine 7- oder 8-Bit-Quantisierung. Das Ergebnis ergibt
eine Datenrate von 56 Kbit/s (7Bits/Abtastung * 8 kHz) oder 64 Kbit/s (8Bits/Abtastung *
8 kHz). Bei PCM wird auf eine Komprimierung der Daten verzichtet, wodurch man auf
breitbandige Übertragunswege angewiesen ist. Allgemein werden zwei grundlegende
Varianten der PCM verwendet: µ-law (Nordamerika) und a-law (Europa). Diese
Methoden erzielen eine Komprimierung durch eine logarithmische Einteilung der
Quantisierungsintervalle.
Eine andere häufig verwendete Möglichkeit der Signalkodierung ist die Differential Puls
Code Modulation (DPCM). Im Unterschied zur PCM werden bei DPCM nicht die
Amplituden der Sprachsignale kodiert, sondern die Unterschiede der Amplitude. Bei den
Differenzen der Amplituden ist der Wertebereich naturgemäß kleiner, was zu weniger
Datenaufkommen gegenüber der Standard-PCM führt. Nachteil dieses Verfahrens ist, dass
bei schnellen Signalschwankungen schwerwiegende Quantisierungsfehler auftreten
können. Durch anpassen der Schrittgröße des Quantisierers erreicht man eine
Verbesserung der Sprachqualität, und dies ist das Prinzip der Adaptive Differential Puls
Code Modulation (ADPCM).
• Quellenkodierung (Analyse-Synthese-Verfahren)
Quellenkodierer werden auch als Vocoder bezeichnet. Sie Versuchen das Eingangssignal
durch Generierung eines künstlichen Signals in der Form zu reproduzieren, dass es sich
dem Eingangssignal annähert. Dabei werden nur die Parameter eines Sprachmodels
übertragen, somit sind die Datenraten extrem niedrig.
Die leistungsfähigsten Vocoder sind die LPC-Vocoder (Linear Predictive Coding), sie
arbeiten im Allgemeinen mit Bandbreiten von 2,4 Kbit/s.
Quellenkodierer haben den niedrigsten Bandbreitenbedarf, werden in der IP-Telefonie
jedoch nicht eingesetzt, da sie eine künstlich klingende Sprache erzeugen.
• Hybride Verfahren
Stellen eine Mischung aus den beiden oben genannten Verfahren dar und vereinen die
Vorteile von Signalform- und Quellenkodierern.
Die bekanntesten Methoden der hybriden Verfahren sind die CELP-Kodierung (Code
Excitation Linear Predictive Coding), die ACELP (Algebraic Code Excitation Linear
Predictive Coding), die auf kurze Verzögerungszeiten (<5 ms) optimierte LD-CELP
(Low Delay Code Excitation Linear Predictive Coding), die CS-CELP (Conjugate
2. VoIP (IP-Telefonie)
26
Structure Code Excitation Linear Predictive Coding) und die MPMLQ (Multiple
Maximum Likelihood Quantization).
Die Bandbreiten erreichen zwischen 5,3 und 16 Kbit/s, die erzeugten Sprachqualitäten
liegen zwischen „akzeptabel“ und „sehr gut“.
2.5.2 Sprachdaten-Komprimierung
Die Komprimierung (Reduktion der Datenmenge) der kodierten Daten ist unumgänglich, um
eine vertretbare Übertragungszeit oder gar Streaming24 sicherzustellen.
Man unterscheidet Grundsätzlich zwei Arten der Audiokomprimierung: Die verlustfreie
Komprimierung und die verlustbehaftete Komprimierung.
Verlustfreie Komprimierung: Bei dieser Komprimierungsart ist das Ursprungssignal
auch nach der Komprimierung noch eindeutig widerherstellbar und es treten keinerlei
qualitätsmindernde Effekte auf. Das Grundprinzip der verlustfreien Komprimierung ist
die Differenzkodierung mit linearer Prediktion. Differenzkodierung wurde schon in
Kapitel 2.5.1 erläutert. Unter Prediktion versteht man das Nutzen des Wissens über
das bereits kodierten Signals zur Vorhersage des Folgesignals. Auch hier speichert
man nur die Differenz zwischen dem Signal und seiner Vorhersage. Wendet man nun
noch eine Hufmann-Kodierung25 an, kann man auf diese Weise eine Kompressionsrate
von immerhin 1:2 erreichen. Auch wenn diese Datenreduktion bereits beachtlich ist,
reicht sie jedoch nicht aus um eine effiziente Übertragung über das Internet zu
ermöglichen.
Verlustbehaftete Komprimierung: Bei dieser Methode verringert man die Qualität
gezielt, um sehr hohe Kompressionsraten zu erreichen. Das Grundprinzip: Nicht oder
kaum wahrnehmbare Anteile der Audiodaten müssen nicht mitkodiert werden. Wie
bereits eher erwähnt hat das menschliche Gehör einen Wahrnehmungsbereich von ca.
20 bis 22 kHz. Das heißt, Signale die außerhalb dieses Bereiches liegen, müssen gar
nicht erst mitkodiert werden. Aber auch Signale, die innerhalb dieses
Frequenzbereiches liegen können unter Umständen vom Menschen nicht
wahrgenommen werden. Ein solches Phänomen ist die so genannte „Verdeckung“.
24 Streaming: Echtzeitübertragung (man hört, während man gleichzeitig noch herunterlädt) 25 Häufig vorkommende Kodewörter werden kürzer kodiert als selten vorkommende
2. VoIP (IP-Telefonie)
27
Allgemein versteht man unter Verdeckung die Überlagerung eines leisen Signals
durch ein lautes Signal, so dass das leise Signal nicht mehr wahrnehmbar ist (man sagt
auch, das Signal liegt unter der so genannten Verdeckungsschwelle).
Abbildung 16: Signalverdeckung
2.5.3 Standards der Sprachkodierung
Im diesem Unterkapitel werden die populärsten VoIP-Kodierungsstandards erläutert und kurz
beschrieben (nach [16]).
– G.711 – Beschreibt die bereits angesprochene PCM-Sprachkodierungstechnik. Die
G.711-kodierte Sprache ist bereits in der korrekten Form für die digitale
Sprachübertagung im öffentlichen Telefonnetzwerk oder durch Private Branch
Exchanges (PBX’s)
– G.726 – ADPCM-Kodierung mit 40, 32, 24 und 16 Kbps. Der Austausch der
ADPCM-Sprache ist auch zwischen Paket-Sprach- und öffentlichen Telefon- oder
PBX-Netzwerken unter der Voraussetzung möglich, dass Letztere über ADPCM-
Fähigkeiten verfügen.
– G.728 – Beschreibt eine 16 Kbps-Variante der CELP-Sprachkomprimierung mit
geringer Verzögerung.
– G.729 – Beschreibt die CELP-Komprimierung, mit der Sprache in 8 Kbps-
Strömen kodiert werden kann. Zwei Varianten dieser Standards (G.729 und
2. VoIP (IP-Telefonie)
28
G.729a) unterscheiden sich stark in Hinsicht auf die Komplexität der Berechnung
und beide ermöglichen im Allgemeinen Sprachqualitäten, die mit der 32 Kbps-
ADPCM vergleichbar sind.
– G.723.1 – Beschreibt eine Komprimierungstechnik, mit der Sprache mit einer
geringen Bitrate komprimieren werden kann. Zwei Bitraten sind mit dieser
Kodierung verbunden: 5,3 und 6,3 Kbps. Die höhere Bitrate basiert auf der MP-
MLQ-Technologie und bietet eine bessere Qualität, Die geringere Bitrate basiert
auf CELP, sie bietet gute Qualität und verleiht Systemdesignern zusätzliche
Flexibilität.
2.5.4 Qualität der Codecs
Die Qualität der Codecs lässt sich nach den folgenden Qualitätsmerkmalen beurteilen.
• Datenrate
Die Datenrate ist ein wichtiges Qualitätsmerkmal, da eine Leitung nur eine begrenzte
Bandbreite besitzt und bei einer geringen Datenrate entsprechend mehr Kapazität anderen
Teilnehmern oder Anwendungen zur Verfügung steht.
• Sprachqualität
Ein Maß für die Sprachqualität wurde als Mean Opinion Score (MOS) definiert. Er
beschreibt das statische Empfinden der Sprachqualität eines Benutzers als Zahlenwert
(von 1: Schlecht bis 5: exzellent).
Die Sprachqualität soll möglichst verständlich und natürlich klingen, sodass der Sprecher
nicht nur verstanden, sondern auch anhand der Stimme identifiziert werden kann.
• Verzögerung
Das Dekodieren und Enkodieren ist je nach Verfahren mehr oder weniger aufwändig.
Entsprechend wird Zeit zum Dekodieren und Enkodieren benötigt, wobei eine
wahrnehmbare Verzögerung beim Telefonieren nicht akzeptabel ist. Insgesamt dürfen
nicht mehr als 150 ms inklusive Transport benötigt werden.[18]
Je aufwändiger ein Codec ist, desto länger dauern Encodieren wie auch Decodieren, und
desto größer ist die Verzögerung. Es gibt auch einen Zusammenhang mit der Datenrate. Je
2. VoIP (IP-Telefonie)
29
stärker ein Signal komprimiert wurde, desto kleiner ist das Datenaufkommen und somit
die Datenrate.
• Komplexität des Verfahrens
Das Verfahren darf nicht so komplex sein, dass der Aufwand, der betreiben werden muss,
um einen Codec zu implementieren, die Grenze des Wirtschaftlichen übersteigt.
Normalerweise ist dies kein Hindernis, das Hardware nicht teuer ist und ständig durch
billigere und leistungsfähigere Nachfolger abgelöst wird.[18]
In der Praxis gibt es keinen idealen Codec, der all diesen Erfordernissen am besten gerecht
wird. Jeder Codec hat seine Vor- und Nachteile, so dass man nur den optimalen
Aufbau und Abbau logischer RTP/RTCP-Kanäle für die Übermittlung verschiedener
Medien (Audio, Video, Daten),
2.6.2.4 Anruf-Signalisierung (Q.931) Der Q.931 Standard der ITU beinhaltet Prozeduren für den Auf- und Abbau einer Verbindung
im ISDN. Die Signalisierung verläuft dabei über den D-Kanal des ISDN-Anschlusses.
Für die Signalisierung in H.323 wird ebenfalls Q.931 verwendet. Diese Designentscheidung
ist historisch bedingt, da zu Beginn von H.323 versucht wurde, Standards und Protokolle aus
dem ISDN (bzw. von H.320) zu übernehmen.
28 Mit der Master/Slave-Festlegungsprozedur wird für einen bestimmten Anruf bestimmt, welcher Endpunkt der Master und welcher der Slave ist. Die Beziehung bleibt für die Dauer des Anrufs bestehen und sie ist zuständig für die Auflösung von Konflikten zwischen den Endpunkten. Die Master/Slave-Regeln kommen zum Einsatz, wenn beide Endpunkte zum selben Zeitpunkt ähnliche Aktionen anfordern.
2. VoIP (IP-Telefonie)
36
2.6.2.5 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.
2.6.2.6 Struktur von Anruf-SIG-Nachrichten beim H.225.0 Als Anruf-SIG-Nachrichten beim H.225.0 werden die Q.931-Nachrichten in einer erweiterten
Form verwendet. Abbildung 23 zeigt, wie die Anruf-SIG-Nachrichten strukturiert sind und
wie sie in IP-Paketen übermittelt werden.
Abbildung 23: H.225.0-Anruf-SIG-Nachrichten in IP-Paketen [1]
Für den H.225.0-Einsatz werden die Q.931-Nachrichten um zusätzliche und H.225.0-
spezifische Angaben erweitert, die man als User-to-User Information 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.0-Anruf-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.
2. VoIP (IP-Telefonie)
37
Jede Q.931-Nachricht enthält immer folgende Angaben:
Message type als Angabe des Nachrichtentyps (Setup, Alerting, ...).
Call reference als Identifikation des Anrufes, d.h. auf welchen Anruf sich diese
Signalisierung bezieht.
Protocol discriminator als Identifikation des Protokolls Q.931.
Informationselemente IEs (Information Elements) als Parameter der Nachricht, die oft
optional sind.
Die folgenden Q.931-Meldungen sind die am häufigsten verwendeten Signalisierungs-
Meldungen in H.323-Netwerken:
Setup: (Einrichtung) wird von der anrufenden Einheit zur angerufenen gesendet. Mit
„Setup“ wird versucht, eine Verbindung einzurichten.
Call-Proceeding:
(Anruffortschritt)
wird von der angerufenen Einheit zur anrufenden gesendet. Mit
Call-Proceeding wird angezeigt, dass die Prozeduren zur
Anrufeinrichtung gestartet wurden.
Alerting: (Alarmierung)
wird von der angerufenen Einheit gesendet, um mitzuteilen,
dass das Klingeln an der angerufenen Seite gestartet wurde.
Connect: (Verbinden) wird von der anrufenden Einheit zur angerufenen gesendet, die
anzeigt, dass die angerufene Seite den Anruf beantwortete.
Die Q.931-Nachrichten und UUIEs werden mit Hilfe von ASN.1 spezifiziert. ASN.1
(Abstract Syntax Notation No. 1) spezifiziert. ASN.1 dient als Sprache für die Beschreibung
von Nachrichten der Protokolle in den Telekommunikationssystemen.
2.6.3 H.323-Verbindungsablauf
Abbildung 24 stellt ein Beispiel eines Verbindungsablaufes dar, bei dem die H.323-
Protokollfamilie die Einrichtung eines Anrufs zwischen zwei Endpunkten erreicht. Wir gehen
davon aus, dass es sich um einen Sprachanruf handelt und dass beide Endpunkte die
Registrierung beim Gatekeeper bereits abgeschlossen haben.
2. VoIP (IP-Telefonie)
38
Abbildung 24: H.323-Verbindungsablauf [16]
2.6.4 Zusammenfassung
H.323 ist ein hybrides System, das aus zentralisierten intelligenten Gatekeepern, MCUs und
weniger intelligenten Endpunkte zusammengesetzt ist. Obwohl der H.323-Standard in
neueren Veröffentlichungen vervollständigt wurde, sind Probleme aufgetreten, wie z.B. lange
Anruf Einrichtungszeiten, Overhead29 bei einem mit allen Features ausgestatteten Konferenz-
Protokoll viele erforderliche Funktionen in jedem Gatekeeper und Skalierungsprobleme bei
Implementierungen, bei denen Anrufe durch Gatekeeper geroutet werden. Wenn High-
Density-Gateways für die Anbindung ans PSTN benötigt werden, werden Alternativen wie
das Simple Gateway Control Protocol (SGCP) und das Media Gateway Control Protocol
(MGCP) entwickelt. Diese Anruf-Kontroll-Systeme ermöglichen eine effektivere und
skalierbarere Lösung, um Implementierungen für Carrier befriedigen zu können.
Entsprechend löst SIP (Session-lnitiation-Protokoll) einige Probleme des H.323 für
intelligente Endpunktkonfiguration und es wird als Alternative zu H.323 eingesetzt. SIP wird
ausführlich in Kapitell 2.7 diskutiert. 29 In der Kommunikation werden mit Overhead alle Informationen bezeichnet, die zusätzlich zu den Nutzdaten übertragen werden. Das sind Daten, die technisch erforderlich sind, wie Header in Datenpaketen, Routing- und Kontrolldaten, Prüfzeichen usw.
2. VoIP (IP-Telefonie)
39
2.7 SIP (Session Initiation Protocol) Das Session Initiation Protocol (SIP, RFC 2543, RFC 3261) wurde 1999 durch die IETF
(Internet Engineering Task Force) standardisiert und wird zur Kommunikation zwischen SIP
fähigen Endgeräten und Servern oder zwischen Endgeräten genutzt.
SIP wurde in Anlehnung an die Struktur des Internets entwickelt. Die Architektur ist verteilt
beziehungsweise modular. Das Protokoll ist im Klartext kodiert und der Aufbau ähnelt HTTP
oder SMTP. Dadurch ist SIP im Gegensatz zu H.323 besser skalier- und erweiterbar (siehe
Kapitel 2.9)
SIP wurde nicht ausschließlich für die Verwendung bei VoIP vorgesehen. Ziel bei der
Entwicklung von SIP war die Definition eines umfassenden Kommunikationssystems. SIP
kann beispielsweise auch bei der Steuerung von Geräten, zum Versenden von
Kurznachrichten oder auch zum Verbindungsaufbau bei Onlinespielen zum Einsatz kommen.
2.7.1 SIP-Protokollhierarchie
Das Versenden von SIP Nachrichten erfolgt bevorzugt über UDP; TCP ist jedoch optional
möglich. Dabei wird zur Kommunikation zwischen Endgerät und Server standardmäßig der
Port 5060 verwendet. Bei Sprachverbindungen werden die Audiodaten mittels Real Time
Transport Protocol RTP transportiert, dieses Protokoll versendet seine Pakete über UPD.
Das Session Description Protocol (SDP) ist schwieriger einzuordnen. Es setzt auf dem SIP
und dem RTP Protokoll auf, indem es seine Informationen im Body einer SIP-Nachricht
verpackt bzw. das RTP Protokoll ansteuert.
Abbildung 25: SIP-Protokollhierarchie
2.7.1 SIP-Architektur
Gegenüber H.323-Systemen werden für SIP-Systeme nur zwei Komponenten benötigt: User
Agent und SIP-Server, wobei SIP drei Server-Typen unterscheidet: Proxy-Server, Location
Server und Redirect Server.
2. VoIP (IP-Telefonie)
40
User Agent Als User Agent (UA) werden alle SIP-fähigen Endgeräte (d.h. Softwaretelefon am PC,
PDAs30, SIP-Telefone, aber auch PSTN-Gateways etc.) bezeichnet. Dabei wird meist noch
eine (rein logische) Aufteilung in User Agent Client (UAC) und User Agent Server (UAS)
vorgenommen, wobei jedoch jeder UA immer aus einem UAC und einem UAS besteht. Diese
haben folgende Aufgaben:
- UAC’s stellen Anfragen und verarbeiten Antworten
- UAS’s empfangen Anfragen und versende Antwortnachrichten
Abbildung 26: User Agent
Proxy Server
Diese spielen eine zentrale Rolle in einem SIP-Netzwerk. Ihre Aufgabe ist es, das Routing der
SIP-Nachrichten zum Aufbau einer SIP-Verbindung zu übernehmen. Verbindungsgesuche
eines Anrufers können über mehrere Proxies bis zum Aufenthaltsort des Angerufenen geleitet
werden.
Es wird dabei zwischen Stateless und Stateful Proxies unterschieden. Stateless Proxies leiten
empfangene Nachrichten einfach weiter. Sie sind deshalb schneller als Stateful Proxies und
finden vor allem Verwendung als Loadbalancer und einfache Router. Allerdings sind sie nicht
in der Lage, anspruchvolleres Routing wie z.B. Call Forking (mehrere Endgeräte können
gleichzeitig angerufen werden) zu betreiben.
Stateful Proxies generieren für eine Anfrage einen Zustand (''State'') und behalten diesen, bis
die entsprechende Transaktion31 beendet ist. Dies kann im Falle einer INVITE (Einladung)-
Nachricht relativ lang dauern (nämlich so lange, bis der Angerufene den Anruf annimmt oder
30 Unter dem Begriff PDA (Personal Digital Assistent) werden handliche elektronische Geräte mit Kalender-, Adress-, Notiz- und ähnlichen Funktionen zusammengefasst 31 Transaktion: Kompletter Zyklus einer Datenverarbeitung.
2. VoIP (IP-Telefonie)
41
abweist). Aufgrund der Tatsache, dass Stateful Proxies diese Zustände für die Dauer der
Anfrage aufrecht erhalten müssen, sind an diese höhere Leistungsanforderungen gestellt.
Dafür sind sie aber auch in der Lage, weitergehende Dienste anzubieten und können auch von
einem Endgerät mehrfach versandte Nachrichten abfangen, da sie ja wissen, ob diese bereits
empfangen wurde.
Location Server (Registrar) Damit ein Proxy weiß, wo der betreffende Benutzer zu finden ist, muss sich sein UA an
einem Location Server angemeldet haben. Dieser speichert dann den derzeitigen
Aufenthaltsort (d.h. IP-Adresse, Port und Benutzername) in einer sog. ''location database''.
Auf diese kann dann der Proxy-Server des Angerufenen zugreifen, um den Aufenthaltsort
herauszufinden. Bei einem Registrar handelt es sich allerdings für gewöhnlich nur um eine
logische Einheit - wegen der engen Verzahnung von Registrar und Proxy sind diese meist in
einem Gerät (Soft- oder Hardware) zusammengefasst.
Redirect Server Aufgabe dieses Servers ist es, bei eingehenden Anfragen den gewünschten Empfänger in der
location database nachzuschlagen. Die gefundenen Aufenthaltsorte - es ist bei SIP möglich,
dass man sich zur gleichen Zeit mit verschiedenen Endgeräten von verschieden Orten aus mit
dem gleichen Benutzer anmelden kann - werden dann dem Sender der Anfrage mit einer
Da die SIP-Version stets das Format SIP/X.X hat, kann mit Leichtigkeit festgestellt werden,
ob es sich nun um eine Request oder Response handelt, denn es gibt keine Methode, die mit
einem ’S’ beginnt.
Auf die Methode in der Request sowie den Status-Code und die Reason Phrase in der
Response wird in noch kommenden entsprechenden Kapiteln eingegangen. 32 Carriage Return: Ein Formatsteuerzeichen, das zur Rückbewegung der Schreibeinrichtung auf die erste Schreibposition in derselben Zeile. Line Feed: Neue Zeile 33 Space
2. VoIP (IP-Telefonie)
45
Header Es gibt drei verschiedene Typen der Headers. Gewisse Kopfzeilen sind sowohl in der Request
als auch in der Response Message enthalten. Diese Header werden auch General Header
genannt. Kopfzeilen, die Bezug auf den Message Body haben, werden im Entity Header
berücksichtigt. Die Request-Header enthalten zusätzliche Informationen, die ein Client mit
einer Request Message dem Server mitteilen kann.
Das Headerformat lautet: header name : SP header value CRLF
Vor und nach dem ’:’ dürfen beliebig viele Leerzeichen oder Tabulatoren eingefügt werden.
Es sind nur die wichtigsten und notwendigen Header erläutert.
• General Header:
General Headers sind zwingend nötig in der Request und der Response.
Call-ID: Mit der Call-ID wird eine SIP-Verbindung eindeutig identifiziert. Mit Hilfe
dieses Headers kann eine Message einer Transaktion zugewiesen werden. Es
können Duplikate erkennt werden, die z.B. auf dem Weg durch einen Forking
Proxy entstehen. Die Call-ID ist einmalig und für jeden Anruf neu zu
erstellen.
CSeq: Das CSeq Header-Feld besteht aus einer Sequenznummer und dem
Methodennamen. Der Anfangswert der CSeq-Nummer ist beliebig und wird
bei jedem neuen Request inkrementiert. Es sei denn, dass es eine
Wiederholung des Request ist.
Einzige Ausnahmen sind die Methoden ACK und CANCEL, welche die
CSeq-Nummer des Request, den sie bestätigen oder abbrechen, übernehmen.
Der Server kopiert die CSeq von der Request in die entsprechende Response.
Contact: Mittels des Contact-Feldes gibt der Sender an, wo er die Antworten des
Empfängers erwartet.
From: Dieses Feld beinhaltet einen optionalen Anzeigenamen und die Adresse des
Erstellers eines Requests. Zusätzlich können Tags angefügt werden.
Bei einer Response wird der From-Header direkt von der Request
übernommen und sagt somit nichts über den Sender der Nachricht aus.
To: Bezeichnet den beabsichtigten Empfänger eines Requests.
Via: Mit Hilfe des Via-Headers kann der Weg der Message über mehrere Hops
zurückverfolgt werden. So wird sichergestellt, dass eine Response denselben
2. VoIP (IP-Telefonie)
46
Weg wie der Request, in umgekehrter Reihenfolge, nimmt. Jeder Proxy fügt
seine Adresse in diesem Header-Feld an.
• Entity Header:
Zur weiteren Beschreibung des noch folgenden Message Bodys, dienen diese Kopfzeilen.
Sie weisen auf die Größe oder den Typ hin.
Content-Type: Dieser Header beschreibt das Medium, welches im Message Body
verwendet wird (z.B. SDP, HTML34 etc.).
Content-length: Gibt die Anzahl Oktette im Message Body an.
• Request Header:
Diese Header sind nicht zwingend notwendig, verringern aber die Anzahl der SIP-
Messages, die ausgetauscht werden müssen, um eine gültige Client-Server Verbindung zu
erreichen.
Accept: Der optionale Header teilt dem Server mit, welche Typen von Medien in
der Response akzeptiert werden. Somit kann der Server von Anfang an den
korrekten Typ versenden, sofern er ihn unterstützt, und muss seinerseits
nicht auch noch eine Auswahl schicken, die zuerst noch ausgewertet
werden müsste.
Subject: Der freie Text, der hier angefügt werden kann, sollte Informationen über
den laufenden Anruf geben Message Body
Im Message Body sind Informationen enthalten, die die Verbindung genauer umschreiben.
Hier können verschiedene Protokolltypen zum Einsatz kommen. Unter anderem sind diese
SDP (Session Description Protocol), verschlüsselte SDP, HTML etc.
Das SDP ist, wie der Name schon vermuten lässt, ein Protokoll zur Beschreibung von
multimedialen Sitzungen, welches in der RFC 2327 spezifiziert ist. Jede SDP-Nachricht liegt
Mit einer Final-Response, deren Status Code 200-699 ist, wird eine SIP Transaktion beendet.
Mit einer provisorischen Response, Status Code 1xx, wird die Transaktion nicht beendet. In
einer Start-Line, genauer Status-Line, wird einem Status Code eine Reason Phrase angefügt,
die den Status Code in Worten beschreibt. Jeder Status Code hat seine eigene Reason Phrase.
Der Server kopiert größtenteils den Header, den er in einer Request erhält, in den Header
seiner Response. Falls der Server dem Client noch zusätzliche Informationen schicken will,
fügt er den betreffenden Header an.
Es wird zwischen sechs verschiedenen Klassen beim Status Code unterschieden (Siehe
Tabelle 3 und auch Anhang 1). Das erste Zeichen bezeichnet die Kategorie.
2. VoIP (IP-Telefonie)
50
Code Bedeutung
1xx Provisional. Der Request wurde empfangen und wird nun verarbeitet
2xx Success. Die Anfrage wurde erfolgreich empfangen und verarbeitet
3xx Redirection. Der Anruf wird an einen anderen Server weitergeleitet
4xx Client Error. Es ist ein Fehler auf der Clientseite aufgetreten
5xx Server Error. Es ist ein Fehler auf der Serverseite aufgetreten
6xx Global Failure. Die Anfrage kann von keinem Server erfüllt werden
Tabelle 4: SIP Status Codecs
Falls vom Client ein spezifischer Status Code Cxx nicht verstanden wird, soll er ihn wie ein
C00 Code behandeln. Somit können auch ältere Terminals auf neuere Status Codes richtig
reagieren und der User kann anhand der Beschreibung auf das Problem schließen.
2.7.4 SIP-Registrierung
Für eine Registrierung schickt ein Endpunkt eine REGISTER-Nachricht an den Registrar. In
der Nachricht enthalten sind Informationen, unter welchen URL der Benutzer erreichbar ist
und wie lange die Registrierung gültig sein soll. Da sich ein Benutzer als ein anderer angeben
kann, ist es bei SIP möglich, dass ein Registrar oder ein Proxy die Authentisierung
eines Benutzers verlangen kann.
SIP unterstützt zwei Methoden der Authentisierung: Basic und Digest. Bei der Basic-
Authentisierung wird das Benutzerkennwort im Klartext vom Endpunkt an den Proxy
geschickt.
Da die Nachrichten abgefangen werden können, bietet diese Methode nur geringfügig mehr
Sicherheit als das Auslassen eines Kennwortes. Aus diesem Grund wird die Basic- Methode
in neueren SIP-Versionen nicht mehr unterstützt. Bei der Digest-Authentisierung bekommt
der Endpunkt vom Server einen Wert mitgeteilt, den er mit dem Benutzerkennwort
verknüpfen soll. Über diesen verknüpften Wert wird ein MD536-Hash erstellt, der dann als
Kennwort zum Server geschickt wird, in dessen Datenbank das Kennwort im Klartext
36 MD5 (Message Digest Algorithm 5) ist ein in Authentifikationsprotokollen verwendeter Algorithmus, der auf einer Einwegübertragung mittels Hashfunktion (kryptografische Prüfsumme) und einem Schlüssel basiert. Daher können aus dem Ergebnis keine Rückschlüsse auf den Schlüssel erfolgen. Dem Verfahren nach wird aus einer beliebig langen Nachricht eine 128 Bit lange Information, der Message Digest gebildet, der an die unverschlüsselte Nachricht angehangen wird. Der Empfänger vergleicht den Message Digest mit dem von ihm aus der Information ermittelten Wert.
2. VoIP (IP-Telefonie)
51
vorliegen muss, damit er dieselbe Operation wie der Endpunkt durchführen kann.
Der Registrar kann ebenfalls über ein ausgelagertes Policy37-Modul verfügen. Um eine
benutzerabhängige Politik zu betreiben, muss er nun das Policy-Modul befragen, ob der
Benutzer autorisiert ist, sich zu registrieren. Im Rahmen dieser Diplomarbeit wird ein
RADIUS-Server eingesetzt, der u.a. die Aufgabe eines Policy-Moduls bei der Registrierung
übernimmt.
Abbildung 31: Ablauf einer SIP-Registrierung
Nach Erhalt der Register-Nachricht muss der Registrar entscheiden, ob er den Benutzer sofort
annimmt oder ablehnt, oder ob er weitere Informationen benötigt. Der Registrar fordert den
Benutzer auf, sich zu authentisieren. In dieser Aufforderung ist der Initialwert für das Digest-
Authentisierungsverfahren. Der Benutzer gibt seine Authentisierungsinformationen ein, und
der Endpunkt übermittelt diese in einer neuen Register-Nachricht.
Nachdem die Authentizität des Benutzers festgestellt worden ist, wendet sich der Registrar an
das Policy-Modul, um herauszufinden, ob der Benutzer sich registrieren darf. Das Policy-
Modul bestätigt die Registrierung und erteilt die Erlaubnis, die der Registrar an den Benutzer
weiterleitet.
Das Digest-Authentisierungsverfahren stellt sicher, dass Kennwörter nicht im Klartext
übertragen werden. Auch aus abgehörten Nachrichten lässt sich das Kennwort nicht
berechnen.
37 Policy: Politik: Ein Registrar betreibt eine gewisse Politik, wenn er Benutzer anhand verschiedener Kriterien annimmt oder ablehnt.
2. VoIP (IP-Telefonie)
52
2.7.4 SIP-Verbindungsablauf
Im folgenden Beispiel von Abbildung 32 sind zwei Benutzer (snom1 und snom2) an einem
SIP Proxy angemeldet. Wenn snom1 snom2 anrufen möchte, schickt der UA von snom1 eine
INVITE-Nachricht an den Proxy, der diese, da er vom Registrar den gegenwärtigen
Aufenthaltsort von snom2 kennt, an den UA von snom2 weiterschickt. Gleichzeitig informiert
er snom1 über den versuchten Verbindungsaufbau (TRYING) Der UA von snom2 schickt als
Antwort auf die INVITE-Nachricht über den Proxy ein RINGING zurück. Hebt snom2 nun
den Hörer ab, wird eine OK-Nachricht versandt, die von snom1 mit ACK bestätigt wird.
Ab diesem Zeitpunkt läuft die Verbindung direkt zwischen den UAs von snom1 und snom2,
die einen RTP-Kanal für die Sprachdaten aushandeln und aufbauen und sich die Nachrichten
zum Verbindungsabbau auch direkt zusenden.
Legt snom2 am Ende des Telefonats auf, wird eine BYE-Nachricht zu snom1 versandt, dieser
antwortet darauf mit einer OK-Nachricht. So ist die Verbindung abgebaut.
Abbildung 32: SIP-Verbindungsablauf
2. VoIP (IP-Telefonie)
53
2.8 SIP im Vergleich zu H.323 Hinter H.323 und SIP stecken zwei völlig unterschiedliche Ansätze, um IP-Telefonie zu
betreiben. Der grundlegende Unterschied zwischen H.323 und SIP liegt in der Herkunft der
Standards: H.323 kommt aus der TK(Telekommunikation)-Welt und ist stark an ISDN
angelehnt, SIP hingegen entstammt der IP-Welt und stützt sich entsprechend auf
internettypische Festlegungen.
Dieser Abschnitt soll daher die wesentlichsten Unterschiede zwischen H.323 und SIP
aufzeigen und einige Vergleiche anstellen.
2.8.1 Auf- und Abbau einer Verbindung
Die Signalisierung für den Verbindungsaufbau basiert bei H.323 Version 2 auf einem
zuverlässigen Transportprotokoll, wie z. B. TCP. Für den Aufbau eines Gesprächs sind somit
zwei Phasen notwendig: Der Aufbau der TCP-Verbindung und die Übertragung der
notwendigen Signalisierung für den Aufbau des Gesprächs.
Erst bei H.323 Version 3 besteht die Möglichkeit, auch UDP für den Signalisierungskanal zu
verwenden. Was die Signalisierung für einen Verbindungsaufbau betrifft, ist H.323 Version 3
somit in etwa äquivalent mit SIP. Der Abbau einer Verbindung erfolgt ebenfalls auf ähnliche
Weise, da die H.323 ReleaseComplete Message ein Äquivalent zum BYE Request von SIP
darstellt.
2.8.2 Komplexität
In der Spezifikation von H.323 sind viele andere Protokolle involviert. Dazu gehören H.225.0
als Signalisierungsprotokoll, H.245 für verschiedene Kontrollmechanismen, H.450 für die
Spezifikation von zusätzlichen Diensten (Supplementary Services), H.235 für Aspekte der
Sicherheit und Verschlüsselung und H.246 für die Interoperabilität mit Diensten aus dem
SCN (Switched Circuit Network). Auf Grund der engen Verzahnung der soeben genannten
Protokolle ergibt sich eine hohe Komplexität von H.323. So benötigt man z. B. für die
Weiterleitung eines Telefongesprächs (Call Forwarding) Teile aus dem H.450, H.225.0 und
dem H.245 Standard. Ein weiterer Unterschied ist die Anzahl der definierten Elemente. H.323
spezifiziert einige hundert verschiedener Elemente, wobei SIP mit der Definition von 37
verschiedenen Headern auskommt. Daher ist es auch nicht verwunderlich, dass die
Spezifikationen der genannten Standards aus der H-Serie zusammen über 700 Seiten dick
sind. Im Gegensatz dazu beträgt die Anzahl der Seiten aller notwendigen Spezifikationen für
SIP etwa 128.
2. VoIP (IP-Telefonie)
54
Ein weiterer Unterschied ist die Syntax der verwendeten Messages. Alle H.323 Messages
liegen in einem Binärformat vor, das auf der Abstract Syntax Notation One (ASN.1) basiert.
Als Ausgangsmaterial für Softwareentwicklungen auf der Basis von H.323 ist also zuerst
einmal ein ASN.1-Parser notwendig, um aus den ASN.1-Definitionen aller Messages
entsprechenden Quellcode generieren zu können. Im Gegensatz dazu liegen alle Nachrichten
für SIP als Text vor. Auch was die Fehlersuche betrifft ist eine Klartextdarstellung zu
bevorzugen, da keine externen Hilfsmittel benötigt werden, um Daten in eine für den
Menschen lesbare Form zu konvertieren.
2.8.3 Erweiterbarkeit
Als Bewertungskriterium für ein Signalisierungsprotokoll spielt die Erweiterbarkeit eine
wesentliche Rolle. Denn schließlich hat die Einführung der IP-Telefonie gerade erst
begonnen. Und in Zukunft sind noch viele Erweiterungen und neue Forderungen zu erwarten,
die vor allem Einflüsse auf die Signalisierungsprotokolle haben werden.
H.323 verfügt über Erweiterungsmöglichkeiten. Diese liegen meist in Form von
nonstandardParam Feldern in der ASN.1-Definition der Messages vor. Diese Felder enthalten
einen herstellerspezifischen Code, gefolgt von einem Wert, welcher der Erweiterung
entspricht. Dieser Ansatz erlaubt jedem Hersteller die Einführung von eigenen Erweiterungen,
wobei jedoch zwei essentielle Nachteile existieren. Erstens können Erweiterungen nur an den
Stellen vorgenommen werden, die explizit mit nonstandardParam Feldern versehen sind. Und
zweitens reduzieren Erweiterungen die Interoperabilität zwischen Produkten unterschiedlicher
Hersteller, da H.323 keine Möglichkeit vorsieht, Informationen über die vorhandenen
Erweiterungen auszutauschen.
SIP verfügt ebenfalls über Erweiterungsmöglichkeiten mit neuen Features, wobei der große
Vorteil ist, dass es nicht festlegt, welche Erweiterungen obligatorisch sind.
2.8.4 Skalierbarkeit
Unter Skalierbarkeit versteht man die flexible und exakte Anpassung einer Hardware oder
Softwarelösung an die Kundenanforderungen.
Die Serverbelastung ist ein wichtiges Merkmal, an dem die Skalierbarkeit gemessen werden
kann. Die Signalisierungen bei SIP sind zustandslos und können bei Bedarf über UDP
erfolgen. Speziell für Backbone38-Server ist die daraus resultierende Minimierung des
Protokolloverhead eine Quelle für hohe Skalierbarkeit. Ein H.323 Gatekeeper benötigt
38 Unter Backbone versteht man die breitbandigen Hauptdatenleitungen im Internet.
2. VoIP (IP-Telefonie)
55
hingegen für jeden Signalisierungskanal eine eigene TCP-Verbindung. In zukünftigen
Versionen von H.323 ist geplant, die Signalisierung alternativ auch über UDP zu
ermöglichen. Da ein Gatekeeper jedoch weiterhin für die gesamte Dauer eines Gesprächs
dessen Status überwachen muss, ergibt dies für Gatekeeper in größeren Systemen ein
Genau definierte Systemarchitektur und Implementierungsrichtlinien. Regelung von Anrufaufbau, -abbau, Steuerung und Medium.
Auf- und Abbau einer Sitzung von zwei oder mehreren Teilnehmern. Nur das Nötigste zum Verbindungsaufbau ist festgelegt.
Anforderung Telekommunikationstechnik Internet Rückwärtskompatibilität Leistungsmerkmale werden als
Ergänzung zu den vorhandenen hinzugefügt.
Ältere und überholte Leistungsmerkmale werden durch neue ersetzt.
Architektur Steuerung durch einen Server. Steuerung durch den Client. Nachrichtenkodierung Binär Textbasiert Konferenzsteuerung Ja Nein Signalisierungsserver Gatekeeper SIP Proxy Server Medientransportprotokoll RTP/RTCP RTP/RTCP Codec-Unterstützung ITU-Codecs Beliebig Open-Source-Projekte www.openh323.org www.iptel.org
Tabelle 5: Vergleich von H.323 und SIP
3. AAA (Authentication, Authorization, Accounting) und Billing
3. AAA
56
AAA ist die englische Abkürzung für Authentication (Authentifizierung), Authorization
(Autorisierung) und Accounting (sinngemäß Buchhaltung/Buchführung), während Billing der
Prozess der Rechnungslegung ist.
• Authentication
Authentication ist, aus Sicht des Nutzers, der Prozess, bei dem festgestellt wird, wer der
jeweilige Nutzer ist, zum Beispiel durch Überprüfung des vom Nutzer angegebenen Namens
und des dazugehörigen Passwortes.
• Authorization
Authorization ist der Prozess, in welchem dem Nutzer bestimmte Rechte zugewiesen werden.
Hier wird festgestellt, welche Aktivitäten, Ressourcen oder Dienste ein Nutzer in Anspruch
nehmen darf.
Authentication und Authorization gehen meist Hand in Hand. Sobald ein Nutzer
authentifiziert ist, wird er auch (unabhängig vom Systemstatus) autorisiert, bestimmte Dienste
zu nutzen.
• Accounting
Accounting ist das Erfassen von Daten mit dem Inhalt, welche Dienste von wem, wann und
wie lange (Zeitpunkte Dienstbeginn und Dienstende) in Anspruch genommen wurden. Diese
Daten werden durch das Speichern (so genanntes Logging) von Verbindungen (auch als
Sessions bezeichnet) im Zusammenhang mit den Nutzerinformationen erhoben.
Die Accounting-Daten werden für verschiedene Zwecke ausgewertet. Zum einen primär zur
Rechnungsstellung (Fachbegriff: Billing), aber auch zur Kontrolle der
Authentifizierungsvorgänge, Analyse des Nutzerverhaltens (zum Beispiel für ISP’s39
Ermittlung von so genannten Power-Usern bei Flatrate-Angeboten), Erfassung der
Systemauslastung über einen bestimmten Zeitraum, um dadurch die Planung von
Kapazitätserhöhungen zu ermöglichen und ähnliches.
• Billing
Billing (Rechnungslegung) ist der Prozess, aus den angefallenen Accounting-Daten die
Inanspruchnahme eines Dienstes (zum Beispiel Internetzugang) über einen bestimmten
Zeitraum (zum Beispiel Monat) von einem bestimmten Nutzer herauszufiltern, diese Daten
nach dem zugrunde liegenden Tarifsystem in einen entsprechenden Betrag umzurechnen und
dem Nutzer in Rechnung zu stellen.
39 ISP: Internet Service Provider
3. AAA
57
3.1 AAA-Komponenten
3.1.1 AAA-Clients
AAA-Clients nehmen die Zugangsanforderung vom Benutzer entgegen. Hierbei handelt es
sich oft um Network Access Server (NAS), die Nutzern beispielsweise die Modemeinwahl
ermöglichen.
Der AAA-Client gibt die Authentifizierungsanforderung an den lokalen AAA-Server weiter.
3.1.2 AAA-Server
AAA-Server beantworten die Anfragen der Clients. Anhand einer Benutzerdatenbank
entscheidet der Server, ob dem Nutzer die gewünschten Rechte gewährt werden. Kann der
Server eine Anfrage nicht bearbeiten, da er die Identität des Benutzers nicht kennt, so leitet er
die Anfrage an einen ihm bekannten AAA-Server weiter.
3.1.3 AAA-Proxies
AAA-Proxies sind AAA-Server, die AAA-Anfragen weiterleiten.
Abbildung 33: AAA-Client, Server und Proxies
3. AAA
58
3.2 AAA-Architektur
Abbildung 34: AAA-Architektur
Die AAA-Aufgaben (Authentication, Authorization, Accounting) fallen an, wenn Benutzer,
die nicht fest mit einem Netz verbunden sind, Zugang über mobile40 und bewegliche41
Endgeräte verlangen.
AAA definiert einen Rahmen für die genannten Aufgaben.
Die AAA-Architektur (Abbildung 34) sieht einen AAA-Server vor, der eine Datenbank mit
benutzerspezifischen Informationen enthält.
Die Benutzer kommunizieren mit AAA-Clients, die sich auf Netzwerkkomponenten wie
NAS (Network Access Server) oder Routern befinden.
Will ein Benutzer verschiedene Dienste nutzen (insbesondere Zugang zu einem Rechnernetz),
so stellt er – möglicherweise per Modem, WLAN-Adapter oder auch durch eine
Terminalsitzung – eine Verbindung zum jeweiligen Network Access Server her. Er meldet
sich mit seiner Benutzerkennung und eventuell einem Passwort. 40 Mobile Endgeräte können an verschiedenen Zugangspunkten an ein Netz angeschlossen werden 41 Bewegliche Endgeräte: Roaming, der Zugangspunkt ändert sich während einer bestehenden Verbindung
3. AAA
59
Der NAS agiert gegenüber dem lokalen AAA-Server als AAA-Client und übermittelt die
Authentifizierungsanforderung mit einer Benutzerkennung. Kennt der Server die Identität des
Nutzers, befindet sich der Nutzer also in seiner heimischen Verwaltungszone, so kann der
Server nach Prüfung des Passwortes die Nutzung der Dienstleistungen gestatten.
Ist dem Server der Benutzer nicht bekannt, leitet er die Anforderung des Clients an ihm
bekannte AAA-Server weiter. Dies setzt voraus, dass der Server möglichst viele weitere
Server kennt und auch stets eine sichere Kommunikation zwischen den Servern gewährleistet
ist, eine so genannte Security Association muss zwischen den Servern bestehen.
Damit Nutzer über Verwaltungszonen hinweg und auch außerhalb ihrer Heimatdomäne
Dienstleistungen nutzen können, werden Broker eingeführt (Abbildung 35).
AAA-Server besitzen Security Associations mit Brokern, die wiederum Securtiy Associations
mit sehr vielen weiteren Servern besitzen. Der Broker kann eingehende Anforderungen an den
entsprechenden Server weiterleiten.
Die AAA-Architektur entspricht einem klassischen Client-Server-Modell. Dabei fordert stets
der Client die Dienste eines Servers an. Dies bedeutet insbesondere, dass der Server dem
Client nicht willkürlich Nachrichten senden kann, einer Nachricht an den Client geht immer
eine Anforderung des Clients an den Server voraus.
Abbildung 35: AAA-Architektur ohne und mit Broker
3. AAA
60
3.3 AAA-Protokolle
Konkrete Protokolle für AAA sind RADIUS, TACACS und Diameter.
3.3.1 RADIUS
RADIUS (Remote Authentication Dial-In User Service, RFC 2058, RFC 2138 und 2139) ist
das wichtigste AAA-Protokoll.
RADIUS legt eine Client-Server-Architektur zu Grunde, ein RADIUS-Server kann auch als
Proxy-Client für einen anderen RADIUS-Server stehen.
Die Kommunikation zwischen Clients und Servern wird authentifiziert, Passwörter werden
bei der Übertragung verschlüsselt.
Auch Authentifikationsmechanismen können unter anderem PAP42 und CHAP 43 verwendet
werden. [4]
3.3.2 TACACS
TACACS (Terminal Access Controller Access Control System, RFC 1492) ist ein Cisco-
Protokoll für AAA.
Es gab neuere Versionen von TACACS, XTACACS und zuletzt TACACS+.
TACACS+ erfüllt ähnliche Aufgaben wie RADIUS.
TACACS+ nutzt TCP als Transportprotokoll, während RADIUS auf UDP aufsetzt.
In TACACS+ wird die gesamte Nutzlast verschlüsselt.
Authentifikation und Autorisierung können in TACACS+ unabhängig voneinander gelöst
werden, während RADIUS die beiden Aufgaben zusammen behandelt. [4]
3.3.3 DIAMETER
Diameter ist (im Gegensatz zu RADIUS und TACACS+) für große Netze konzipiert.
Es verwendet viele der in RADIUS enthaltenen Mechanismen, erweitert aber gleichzeitig die
von RADIUS gegebenen Grenzen. Diameter ist für Benutzer ausgelegt, die im Netz ihres ISP
42 PAP: Password Authentication Protocol, dabei werden die User-ID und das Passwort ohne Sicherheit übertragen. 43 CHAP: Challenge Handshake Authentication Protocol, der Client authentifiziert sich durch die Korrekte Ausführung einer kryptographischen Operation auf einem vom Server vorgegeben Wert.
3. AAA
61
mobil (Dial-In-User44) sind oder auch über Netze fremder ISP zugreifen wollen (Roaming-
User45).
Dazu wird zwischen dem Heimat- und dem Fremdnetz ein Diameter Broker eingesetzt, der
AAA-relevante Nachrichten zwischen den beiden Netzen austauscht. [4]
44 Benutzer wählt sich in das Netz seines Heimat-ISP ein 45 Benutzer wählt sich in ein Fremnetz (Netz eines fremden ISP) ein, solange er sich im Bereich dieses Netzes befindet. Die Verbindung zum Heimatnetz erfolgt über das Internet, die Authentifikation im Fremdnetz.
4. RADIUS
62
4. RADIUS
4.1 Einführung Remote Authentication Dial-In User Service (RADIUS) ist ein Protokoll, welches unter der
IETF (Internet Engineering Task Force) geführt wird und in den RFC's 2138 (RADIUS
Authentication) und 2139 (RADIUS Accounting) beschrieben ist. Durch diesen Ansatz gilt
das Protokoll als Standard und wird von allen führenden Herstellern von Remote Access
Hard- und Software unterstützt. Diese Unterstützung beruht auf einem zweiteiligen Konzept.
Sämtliche Informationen, die der RADIUS-Server benötigt um alle Funktionen eines Remote
Access Servers anzusprechen, werden in dem so genannten Dictionary File46 im ASCII
Format beschrieben. Es gibt ein Dictionary, welches die Grundfunktionen für den RADIUS-
Support beschreibt. Ein Remote Access Server muss diese Funktionen verstehen und
verarbeiten können, um RADIUS kompatibel nach RFC zu sein.
Zusätzlich kann ein Hersteller von Remote Access Hardware, Firewall oder auch VPN
Software ein eigenes, herstellerbezogenes Dictionary47 bereitstellen, welches dem RADIUS-
Server die erweiterten Funktionen zur Verfügung stellt.
Somit steht eine flexible, genormte Schnittstelle zur Verfügung, die es ermöglicht, nahezu
jedes Gerät oder jede Software - die einen Remote-Zugang zum Netzwerk bereitstellt - in ein
zentrales RADIUS gestütztes System einzubeziehen.
4.2 Radius-Eigenschaften
• Client/Server-Modell
Ein Network Access Server (NAS) fungiert als RADIUS-Client. Der Client ist dafür
verantwortlich die benötigten Benutzerinformationen an den RADIUS-Server zu übermitteln
und auf der Grundlage der Antwort des Servers weiter mit der Anfrage zu verfahren. Der
RADIUS-Server besitzt also die nötige Logik Benutzeranfragen zu bearbeiten, die Benutzer
zu authentifizieren und autorisieren und anschließend alle notwendigen
Konfigurationsinformationen an den Client zu senden, damit dieser den Dienst für den Nutzer
starten kann.
46 Siehe Anhang 1: SIP Status Code. 47 Im Rahmen dieser Diplomarbeit wird ein Dictionary vom SIP-Express-Router (Die Datei dictionary.ser (Anhang 2)) angewendet.
4. RADIUS
63
• UDP als Transportprotokoll
RADIUS ist ein zustandsloses48 (stateless) Protokoll, daher werden die RADIUS-Pakete
zwischen Client und Server per UDP statt TCP übertragen. Dabei verzichtet man bewusst auf
die Transportsicherheit von TCP. Ursache ist, dass die TCP-Mechanismen, die einem sicheren
Transport dienen, nicht den Anforderungen von RADIUS genügen. Ist beispielsweise ein
RADIUS-Server nicht erreichbar, so soll der Client die Anfrage nach einigen wiederholt
fehlgeschlagenen Versuchen sofort einem alternativer Server zustellen. Um jedoch nicht von
den Verzögerungen und Zeitbegrenzungen von TCP abhängig zu sein und selbst diese in
weiten Grenzen manipulieren zu können, entschied man sich für UDP.
Beim Transport wird genau ein RADIUS-Paket in einem UDP-Datenfeld gekapselt.
Abbildung 36: UDP und RADIUS-Paket
• Netzwerksicherheit
Alle Transaktionen zwischen dem Client und einem RADIUS-Server werden durch
symmetrische Verschlüsselung (shared secret) authentifiziert. Der gemeinsame geheime
Schlüssel wird dabei niemals im Klartext über das Netzwerk übertragen. Zusätzlich werden
alle Benutzerpasswörter, die zwischen den Clients und einem Server übertragen werden,
verschlüsselt. Damit wird versucht zu verhindern, dass ein Angreifer aus dem Mitlesen des
Netzwerkverkehrs Rückschlüsse auf die verwendeten Passwörter ziehen kann.
• Flexibler Authentifizierungsmechanismus
RADIUS arbeitet mit einer Vielzahl von möglichen Benutzerauthentifizierungsmechnismen
zusammen. Dazu gehören PPP49, PAP50 oder CHAP51, UNIX login etc.
48 Zustandsloses Protokoll: Bei dieser Art der Kommunikation werden keine Daten abgespeichert, die den Zustand der Verhandlungen zwischen Client und Server konservieren. D. h., jede Unterhaltung zwischen den Beteiligten beginnt bei Null, und alle relevanten Daten müssen erneut ausgetauscht werden. Das bekannteste Beispiel ist HTTP (Hyper Text Transfer Protocol) , das diese Zustandslosigkeit durch Cookies oder Session-IDs kompensiert, die die Daten entweder auf dem lokalen System oder beim Seitenanbieter abspeichern. 49 PPP: Point to Point Protocol 50 Password authentication Protocol
4. RADIUS
64
• Erweiterbares Protokoll
Alle Nachrichten im RADIUS-System umfassen Attribut-Länge-Wert 3-Tupel mit variabler
Länge. Neue Attribute-Value-Paare (AVP) können leicht hinzugefügt werden, ohne
bestehende Implementierungen dieses Protokolls zu stören.
4.3 RADIUS-Spezifikationen
4.3.1 Paketformat
Das Radius-Protokoll setzt wie erwähnt auf UDP auf. Die Struktur eines Radius-Pakets ist
ausgesprochen einfach. Es besteht aus fünf grundlegenden Elementen: einem Radius-Code,
einem Identifier, einer Angabe zur Paketlänge, einem Authenticator und gegebenenfalls aus
einer Reihe von Attributen.
Abbildung 37: Struktur des RADIUS-Pakets
Der Radius-Code beschreibt die Aufgabe des Datenpakets. Die Codes 1, 2 und 3 verwalten
den reinen Access vom Request bis zur Bestätigung oder Abweisung. Die Codes 4 und 5
dienen dem Accounting, ihre Pakete werden zum Port 1813 (Accounting Port) anstatt dem
Der Identifier ist acht Bit lang und dient der Zuordnung von Anfragen und Antworten.
Das sicherheitstechnisch wichtigste Feld eines Radius-Rahmens ist der Authenticator, der eine
Länge von 16 Oktetts beziehungsweise vier 32-Bit-Worten hat. Dabei wird zwischen dem
Request Authenticator und dem Response Authenticator unterschieden. Inhalt des Request
Authenticators ist eine Zufallszahl, die das gesamte Feld ausfüllt. Die Länge dieser
Zufallszahl gewährleistet mit einer sehr hohen Wahrscheinlichkeit die Einmaligkeit dieses
Wertes. Damit bietet das System einen gewissen Schutz vor Hackerattacken. Mit dem
Versand des Request Authenticators werden die Zugangsdaten des Nutzers, der sich im
gesicherten Netzwerk anmelden möchte, als Attribute übergeben. Der Radius-Server wird
diese Anfrage entweder mit einer Access-Accept-, Access-Reject- oder Access-Challenge-
Nachricht beantworten, die ihrerseits mit einem 16 Oktett langen Response Authenticator
versehen ist. Dieser ist ein MD5-Hash-Fingerprint setzt sich zusammen aus dem empfangenen
Radius-Paket einschließlich der Attribute sowie den geheimen Zugangsdaten, die auf dem
Server abgelegt sind, zusammensetzt. Die Attribute eines Radius-Pakets beinhalten alle
wichtigen Informationen, die zwischen dem RAS und dem Radius-Server ausgetauscht
werden müssen.
4.3.2 Pakettypen
Für die Authentifizierung definiert RADIUS vier Pakettypen, deren Elementinhalte in der
folgenden Tabelle erläutert werden. Das Length-Element beinhaltet immer die Länge:
Headers + Payload.
4. RADIUS
66
Element
Packet type
Identifier
Authenticator
Attributes
Access-Request
Code: 1
Unique per
Request
unique over the lifetime
of a secret
- User-Name
- User-Password or CHAP-Password
- NAS-IP-Address
- NAS-Port
- Optional Attributes
Access-Accept
Code: 2
copy of the
Identifier field of
the Access-Request
MD5(Code+ID+Length
+RequestAuth+Attribut
es+Secret)
Zero or more Attributes
Access-Reject
Code: 3
copy of the
Identifier field of
the Access-Request
MD5(Code+ID+Length
+RequestAuth+Attribut
es+Secret)
Zero or more Attributes
Access-Challenge
Code: 11
copy of the
Identifier field of
the Access-Request
MD5(Code+ID+Length
+RequestAuth+Attribut
es+Secret)
Zero or more Attributes
Tabelle 7: RADIUS-Authentifizierungspakettypen
4.3.3 Attributformat
Attribute werden in einer Liste mit variabler Länge im Anschluss an den Authenticator
übertragen. In den Attributen können natürlich Nutzernamen und Passwörter, aber auch IP-
Adresse, Service-Typen, Status-Meldungen, Filter-IDs und - wichtig beim CHAP - ein
entsprechender Challenge-Wert übergeben werden. Attribute werden in Datensätzen variabler
Länge übertragen, die jeweils aus drei Feldern bestehen. Das erste aus acht Bit bestehende
Feld benennt die Art des Attributes (siehe Anhang 3). Da nicht nur die Liste aller Attribute,
sondern auch jeder einzelne Datensatz selbst in der Länge variabel ist, gibt das zweite Oktett
die Länge des Attributes an. Erst ab dem dritten Oktett werden die eigentlichen Informationen
übertragen.
4. RADIUS
67
Abbildung 38: Attributenformat
4.3.4 Proxying
Der Proxy-Mechanismus erlaubt es mehrere RADIUS-Server für die Validierung der
Benutzer einzusetzen. Dies hat den Vorteil, dass die Verwaltung von Benutzerkennzeichen
und Passwörter dezentral erfolgen kann.
Im Unterschied zur Authentifizierung ohne Proxy-Server sendet der RADIUS-Client die
Benutzerdaten nicht direkt an einen RADIUS-Server, sondern zuerst an den Proxy-Server.
Dieser verhält sich als RADIUS-Client gegenüber dem zuständigen RADIUS-Server und
leitet die Daten an ihn weiter. Welcher Server zuständig ist, wird durch die Domäne
(RADIUS-Realm) festgelegt, die der Benutzer beim Login in der Form Kennung@Domäne
mit angeben muss. Ein Realm ist im Prinzip eine Gruppe von User, der im Radius gewisse
Rechte hat.
Zum Proxying benutzt RADIUS den UDP-Port 1814 (Proxy-Port).
4.4 Arbeitsablauf der RADIUS-Authentifizierung
Wenn ein Client dafür konfiguriert ist, das RADIUS-Protokoll zu benutzen, fordert er seinen
Nutzer dazu auf, sich gegenüber dem System zu identifizieren. Dies geschieht in der Regel
dadurch, dass der Benutzer durch ein Login-Prompt angewiesen wird einen Benutzernamen
und ein Passwort einzugeben. Durch die hohe Flexibilität von RADIUS können auch
Mechanismen wie PPP, PAP oder CHAP etc. zum Einsatz kommen.
Anschließend erzeugt der Client einen „Access-Request“, den er an den RADIUS-Server
sendet. Der „Access-Request“ enthält als Attribute den Benutzernamen, das Passwort, die
Client-ID und die Port-ID, auf die der Benutzer zugreift. In dem Fall, dass ein Passwort mit
dem „Access-Request“ übertragen werden soll, wird dieses mit einem Digest-Algorithmus
(MD5)-basiertem Chiffre verschlüsselt.
Der „Access-Request“ wird anschließend über das Netzwerk an den RADIUS-Server
übertragen. Falls innerhalb einer Timeout-Zeitspanne nicht auf die Client-Anfrage
geantwortet wird, so findet eine Wiederholung der Anfrage vom Client an den Server statt,
solange bis der Client den Verbindungsversuch abbricht.
4. RADIUS
68
Weil RADIUS Proxying unterstützt, kann ein RADIUS-Server als Proxy auftreten und
Access-Nachrichten an andere RADIUS-Server weiterleiten.
Hat der gewünschte RADIUS-Server letztendlich den „Access-Request“ erhalten, validiert er
den Client, von dem er die Nachricht erhalten hat. Validierung heißt in diesem Fall, dass der
RADIUS-Server anhand der Client-ID überprüft, ob er sich mit diesem Client ein Geheimnis
teilt, sprich ob ein gemeinsamer Schlüssel zur Dechiffrierung der Nachricht vorhanden ist.
Erhält ein Server eine Nachricht von einem Client, der keine Bekannte ID hat, so muss diese
Nachricht ohne eine Antwort vernichtet bzw. ignoriert werden.
Wenn festgestellt wurde, dass der Client dem Server bekannt ist, kann der Server den
„Access-Request“ bearbeiten. Zu diesem Zweck fragt der Server eine interne Datenbank ab,
ob die Informationen zu dem anfragenden Benutzer lokal verfügbar sind. Wird ein solcher
Datensatz gefunden, erhält der Server eine Liste mit Bedingungen, die erfüllt sein müssen, um
dem Benutzer Zutritt zu gewähren. Dieses beinhaltet immer die Überprüfung des Passworts.
Jetzt besteht noch die Möglichkeit, dass der Server einen weiteren Authentifikationsschritt
durch ein Challenges/Response-Schema verlangt. Dies geschieht dadurch, dass der Server mit
einem „Access-Challenge“ auf den „Access-Request“ antwortet. Ein Challenge/Response-
Schema ist eine weitaus sicherere Methode, da der Server eine dynamische Herausforderung
(Challenge) erzeugt, die (eigentlich) nur der Benutzer selber durch z.B. eine Chipkarte oder
einen nur ihm zugänglichen Algorithmus bewältigen bzw. beantworten kann.
Abbildung 39: Authentifizierung durch Challenge/Response-Schema Nach Eingabe der Benutzerantwort erzeugt der Client eine neue „Access-Request“ Nachricht,
in dem er die originale „Access-Request“ Nachricht mit einer neuen Request-ID ausstattet
und das User-Passwort-Attribut durch die (verschlüsselte) Challenge-Response ersetzt. Diese
Nachricht wird nun an den Server zurückgeschickt.
4. RADIUS
69
Wenn eine der Bedingungen nicht erfüllt sein sollte, sendet der Server ein „Access-Reject“,
um dem Benutzer mitzuteilen, dass er keinen Zugriff auf das System bekommt.
Wenn alle Bedingungen an den Benutzer erfüllt sind, wird die Liste der
Konfigurationsvariablen in eine „Access-Accept“ Nachricht verpackt. Diese Variablen
definieren den Service-Typ (z.B. SLIP, PPP, Login User) und alle nötigen Informationen, um
den Dienst zu starten. Zu diesen Informationen gehören bei z.B. einer PPP- oder SLIP-
Verbindung die zugewiesene IPAdresse (Framed-IP-Address), Subnetzmaske, MTU52 etc.
4.5 RADIUS-Accounting
4.5.1 Wie funktioniert Radius-Accounting?
Accounting ist kein Bestandteil des ursprünglichen RADIUS-Protokolls. RADIUS-
Accounting wurde später in einer Erweiterung dem RADIUS-Protokoll hinzugefügt.
Diese Protokollerweiterung beschreibt die Übertragung von Accounting-Informationen von
einem Network Access Server (NAS) zu einem RADIUS-Accounting-Server.
Identisch zu den Merkmalen des ursprünglichen RADIUS-Protokolls fungiert auch bei
RADIUS-Accounting der NAS als Client. Er hat die Aufgabe einem speziellen Accounting-
Server die gesammelten Informationen zum Ressourcenverbrauch der Nutzer zukommen zu
lassen. Der RADIUS-Accounting-Server hat im Gegenzug die Aufgabe diese Informationen
zu empfangen und zu speichern und dem Client die eingegangenen Accounting-Nachrichten
zu quittieren.
Auch in dieser Architektur kann ein Accounting-Server als Proxy auftreten und Accounting-
Nachrichten an andere Accounting-Server weiterleiten.
Ebenfalls identisch ist, dass jegliche Transaktionen zwischen einem RADIUS-Client und
einem RADIUS-Accounting-Server durch einen symmetrischen Schlüssel authentifiziert und
gesichert werden.
4.5.2 Accounting-Pakettypen
Für das Accounting definiert RADIUS zwei Pakettypen, deren Elementinhalte in der
folgenden Tabelle erläutert werden. Das Length-Element beinhaltet immer die Länge:
Headers + Payload.
52 MTU: Maximum Transfer Unit: Ein Wert, der die maximale Größe der gesendeten Pakete bestimmt.
4. RADIUS
70
Element
Packet type
Identifier
Attributes
Accounting-Request
Code: 4
Unique per Request
- Acct-Status-Type
- User-Name
- Acct-Session-ID
- NAS-IP-Address
- NAS-Port
- Optional Attributes
Accounting-Response
Code: 5
copy of the Identifier field of the
Access-Request
Zero or more Attributes
Tabelle 8: RADIUS-Accounting-Pakettypen
4.5.3 Arbeitsablauf des RADIUS-Accounting
Wenn ein Client für die Benutzung von RADIUS-Accounting konfiguriert wurde, dann
geschieht folgendes, wenn ein Benutzer einen Dienst in Anspruch nehmen möchte und dieser
Dienst dann auch gestartet wird: Der NAS generiert beim Start des Dienstes eine Accounting-
Start Nachricht. Innerhalb dieser Nachricht übermittelt er, welcher Dienst gestartet wurde und
welcher Benutzer diesen Dienst in Anspruch nimmt.
Nachdem die Nachricht zum Accounting-Server übertragen wurde generiert dieser als
Antwort eine Quittung (Accounting-Response), die bescheinigt, dass die Accounting-
Nachricht angekommen ist.
Wenn der Nutzer den Dienst nicht länger in Anspruch nehmen möchte oder der Dienst aus
irgendeinem anderen Grunde gestoppt wurde, sendet der NAS eine Accouting-Stop Nachricht
an den Accounting-Server. Inhalt dieser Nachricht ist der Typ des Dienstes der „verbraucht“
worden ist. Der Accounting-Server generiert wiederum eine Quittung, die den korrekten
Erhalt der Nachricht bestätigt.
4. RADIUS
71
Abbildung 40: RADIUS-Accounting [9]
Die Accounting-Start bzw. Stop-Nachrichten werden, wie die anderen RADIUS-Nachrichten
auch, über möglicherweise verlustbehaftete Kanäle übertragen.
Da, wie schon in den Anforderungen an Accounting definiert, eine korrekte Abrechnung
verbrauchter Ressourcen ein extrem wichtiger und finanzkritischer Bereich ist, sollten auf
jeden Fall Retransmission-Timer eingesetzt werden, damit die Accounting-Nachrichten
solange gesendet werden, bis der Accounting-Server den Erhalt quittiert und keine
Nachrichten verloren gehen.
Die Clients haben ebenfalls die Möglichkeit ihre Accounting-Pakete an alternative Server zu
schicken, falls der primäre Accounting-Server nicht zur Verfügung stehen sollte. Ein
alternativer Server kann entweder nach einer gewissen Anzahl von Fehlversuchen an den
primären Server ausgewählt werden, oder es wurde von vorne herein eine Ringstruktur von
Backup-Servern vorgesehen, die alle nacheinander abgefragt werden können.
5. Entwicklungsumgebung
72
5. Entwicklungsumgebung
5.1 VoIP-Netz In der folgenden Abbildung wird dargestellt, wo die VoIP-Test-Architektur im
Experimentiernetz der Fachhochschule Köln aufgebaut wurde.
Abbildung 41: VoIP-Testnetz im Experimentiernetz der FH-Köln
5. Entwicklungsumgebung
73
5.1 SER (SIP-Express-Router)
5.2.1 Was ist SER?
SER (SIP Express Router) ist ein Open-Source SIP-Proxy-, Redirect- und Registrarserver von
dem Fraunhofer-Institut FOKUS.
SER, entwickelt von der FOKUS-Gruppe iptel.org, ermöglicht sowohl Voice-over-IP-Dienste
als auch Videokonferenz-, Messaging- und Voice-Mail-Dienste.
Diese Dienste und andere sind auf iptel.org schnell und kostengünstig umzusetzen und in
vielen Ländern von nationalen Regulierungen ausgenommen, was sie für viele Unternehmen
sehr attraktiv macht. Vor allem branchenfremde Unternehmen haben die Möglichkeit,
unkompliziert in den Telekommunikationsmarkt einzusteigen.
"SER" ist das zurzeit erfolgreichste auf dem Session Initiation Protocol (SIP, RFC3261)
basierende Produkt im kommerziellen Internet-Telefonie-Einsatz.
"Unsere Technologie SER trägt entscheidend dazu bei, dass in der Telekommunikations-
branche neue Player mit neuen Geschäftsmodellen erfolgreich sind" kommentiert Dr.
Dorgham Sisalem, Leiter der Gruppe iptel.org bei Fraunhofer FOKUS die aktuelle
Entwicklung im weltweiten Telekommunikationsmarkt.
Der SIP Express Router ist eine freie Software und unterliegt der GNU-GPL53 General Public
License.
Sowohl für die Einrichtung als auch für die Weiterentwicklung der Software findet man auf
der Website von iptel.org eine enorme Unterstützung.
53 GNU: Abkürzung für GNU’s Not UNIX. Softwaresammlung, die von der Free Software Foundation angelegt wurde und gepflegt wird. Es handelt sich fast ausschließlich um UNIX- bzw. LINUX-Software, die weitgehend kostenlos und ohne Copyright verbreitet wird. [20] GPL: Abkürzung für General Public License. Lizenz zur freien Nutzung von Software entsprechend Regeln von GNU. [20]
5. Entwicklungsumgebung
74
Abbildung 42: Screenshot der Internetseite www.iptel.org
5.2.2 Installation
Am komfortabelsten nimmt man die Binärdistribution von SER, so ist er direkt nach dem
Entpacken der Datei auf dem Rechner installiert.
SER kann auf die verschiedenen Varianten von Linux und SUN Microsystem's Solaris
installiert werden.
In diesem Abschnitt wird die Installation der SER- Binärdistribution auf einen SuSe-Linux-
Rechner (Version 9.1) beschrieben. Shell> tar -zxvf ser_0.8.12_linux_i386.tar.gz
Hier wird das wichtigste Konzept jedes SIP-Servers bearbeitet, nämlich das Request-Routing.
Dies legt den nächsten „Sprung“ (auf Englisch Hop) einer Request fest.
In diesem Abschnitt wird unter anderem folgendes realisiert:
- Erzwingen des statischen Routings über einen PSTN-Gateway,
- Bestimmen des dynamischen Routings zu registrierten Benutzern und
- Festlegen der Authentifikationsmethode.
Zu dem letzen Punkt habe ich folgendes in diesem Abschnitt eingetragen:
- if (!www_authorize("139.6.19.65", "subscriber")){
www_challenge("139.6.19.65", "0");
54 HA1-String ist ein MD5-Hash von Benutzername, Passwort und Realm, HA1-Strings sind sicher, denn der Server braucht nicht den Passwortvolltext zu wissen, und das Passwort kann nicht direkt aus dem HA1-String gewonnen werden.
5. Entwicklungsumgebung
77
break;
};
#Für Autorisierung wird auf den Host 139.6.19.65
zugegriffen, Benutzernamen und
#Passwörter werden in der Datenbanktabelle „subscriber“
#gefunden.
b) Datenbank und Datenbankbibliothek erstellen Zum Erstellen der SER-Datenbank reicht es folgendes einzugeben:
Shell> /usr/sbin/ser_mysql.sh create
und schon ist die DB mit allen Tabellen erstellt.
Erstellt wird auch der Benutzer „admin“ in der Tabelle „user“ mit dem Passwort
„heslo“.
Notwendig ist es auch der symbolische Link auf die DB-Bibliothek libmysqlclient.so
• Um einen Kompilierfehler zu verhindern musste ich in /freeradius-1.0.0/src/modules/rlm_sql/drivers
“lib” umbenennen.
Shell> mv lib Lib
• SER muss den Pfad kennen, wo sich die Radiusclient-Library befindet, dafür in
der Datei /etc/ld.so.conf den Pfad eingeben: /usr/local/lib/ und
dann
Shell> ldconfig –v
• Für SER-Radius-Funktionalität muss im /ser_0.8.12/Makefile im
Abschnitt „exclude_modules“ die Zeile:
„auth_radius“, „group_radius“ und „uri_radius“
gelöscht oder auskommentiert werden.
Diese enthält nämlich die SER-Radius-Module.
• Um das Radius-Accounting zu aktivieren, muss man in der Datei
/ser-0.8.12/modules/acc/Makefile beide Zeilen auskommentieren:
DEFS+=-DRAD_ACC
LIBS=-L$(LOCALBASE)/lib -lradiusclient
• Erst nach diesen Einstellungen konnte ich SER und Freeradius auf Red-Hat-Linux
fehlerfrei kompilieren und installieren, dies geschieht wie es in den Abschnitten
5.2.2, 5.2.3 und 5.3.2 beschrieben wurde.
5.5 MySQL56-Datenbank
Eine Datenbank ist zur Speicherung und Verwaltung von Daten, vor allem bei größeren
Datenmengen, eine Notwendigkeit.
Aus diesem Grunde wird im Rahmen dieser Diplomarbeit, wie in Kapitel 5.2.4 zum
Benutzererstellen, auf relationale Datenbanken zugegriffen. In Gebrauch sind MySQL-
Datenbanken. Dafür muss ein MySQL-Server installiert werden, diesen kann man sowohl bei
Redhat als auch bei SuSe bei der Distribution in den Installations-CDs finden.
Nach der Installation muss die Basis-Datenbank „mysql“ erstellt werden:
Shell> /usr/bin/mysql_install_db
56 MySQL: ist eine SQL(Structured Query Language)-Datenbank. Wie auch Oracle, DB2 oder PostgreSQL ist MySQL eine relationale Datenbank. Die Daten werden daher in zweidimensionalen Tabellen gespeichert. Michael „Monty“ Widenius schuf MySQL 1994 für die schwedische Firma TcX. Heute wird MySQL von der Firma MySQL AB weiterentwickelt. MySQL ist mit mehr als 4 Millionen Installationen und über 35.000 Downloads pro Tag die populärste Open-Source-Datenbank der Welt
5. Entwicklungsumgebung
87
Sämtliche Datenbanken und deren Tabellen werden nachher in /var/lib/Mysql zu finden
sein.
Folgendes muss auch in die MySQL-Konfigurationsdatei /etc/my.cnf im Abschnitt
Im Hinblick auf sichere Abrechnungsszenarien zu VoIP sind von der Firma Tecon folgende
Anforderungen an die im Rahmen dieser Diplomarbeit durchgeführten SIP- und RADIUS-
Protokoll-Erweiterungen gestellt.
• Must
- A-Rufnummer/IP-Adresse/URL/Mailadress etc. - B-Rufnummer/IP-Adresse/URL/Mailadresse etc. - Startzeit und Dauer der Verbindung - Übertragenes Volumen (Datenpakete) - Type of Service Kennzeichnungen (Voice, Fax, Konferenz, Video,
SMS/MMS, etc.) - Quality of Service Parameter (Codecs, Bandbreiten etc.)
• Should
- A-Provider (ISP/Carrier) • Anschluss • Nomade
- B-Provider (ISP/Carrier) • Anschluss • Nomade
- MAC-Adresse des Gerätes des Nutzers und des Anschlusses - Roaming Informationen, d. h. Erkennung von Nomaden am fremden
Anschluss
• Nice-to-have
- Gateway Nutzung (Netzübergänge und Transit) IP ↔ PSTN - Informationen zu Carrier und ISP
In den folgenden Abschnitten wird vorgestellt, wie die neuen Authentifizierungs- und
Accountig-Daten gewonnen werden konnten. Die kompletten Quell-Code-Änderungen
werden zwar nicht in diesen Kapiteln aufgeführt, sind aber in Anhang 4 ausführlich und
kommentiert vorgestellt.
6. Implementierung
89
6.2 Mobilität
Wichtiges und entscheidendes Konzept bei den neuen Kommunikationssystemen ist die
Mobilität. Doch um Authentifizierungs-, Autorisierungs- und Accounting-Probleme zu
überwältigen schreibt GEOVIPA57 vor, zwei IP-Adressen für eine Verbindung registrieren zu
müssen: Die Anschluss-IP-Adresse oder Physical Line IP-Address (kurz PLIP) und die
Nomaden-IP-Adresse oder Charging IP-Address (kurz CHIP).
Schließt ein Nomade sein VoIP-Endgerät an einem fremden Anschluss, so muss sowohl bei
der Registrierung als auch bei einem Verbindungsaufbau neben der Anschluss-IP-Adresse -
was für die Lokalisierung des Anrufers z.B. bei Notrufen wichtig ist - auch die Nomaden-IP-
Adresse mit den Accounting-Daten festgehalten werden.
6.2.1 Nomaden-IP-Adresse
Die Nomaden-IP-Adresse hängt direkt mit einem Kunden zusammen. Beispielsweise
bekommt der Kunde „Faik“ von seinem ISP einen User-Name z.B. [email protected], mit dem er
sich in Verbindung mit einem Passwort an dem ISP-Server anmelden kann. Der Kunde „Faik“
bekommt auch eine Nomaden-IP-Adresse, die ihn kennzeichnet, auch wenn er an einem
fremden Anschluss die Dienste seines ISP nutzen möchte. Um die Kosten muss sich der
Kunde Faik auch nicht kümmern, denn die Nomaden-IP-Adresse heißt schließlich auch
Abrechnungs-IP-Adresse, sie dient auch dazu, dass die Kosten demjenigen, der die ISP-
Dienste genossen hat, abgerechnet werden.
Um die Nomaden-IP-Adresse in unserem System (SIP- und Radius-Server) zu
implementieren, wird das Prinzip der Framed-IP-Address bei RADIUS genutzt (siehe Kapitel
4.4). Bei einer Registrierung bekommt der Benutzer eine für ihn spezifische IP-Adresse
zugeteilt. Dies wird durch Einfügen der Framed-IP-Address-Zuweisungs-Zeile in der „users-
Datei“ von Radius realisiert, z.B. für den User „snom1“:
Bei einer Registrierung holt der RADIUS-Server die Framed-IP-Adresse von seiner Benutzer-
Datenbank (in unserem Falle die users-Datei) und fügt sie an die Attribut-Liste des Access-
Accept-Pakets. Die Authentifizierungsdaten wurden aber davor in die Log-Datei eingetragen. 57 GEOVIPA ist eine Verfahrensbeschreibung der Fa. Tecon für die geographische Verzonung von VoIP zur Authentifizierung der Verkehrsursprünge zur Abrechnung und der Erkennung von Verbindungsursprüngen für Notrufe und Mehrwertdiensten.
6. Implementierung
90
Bevor das Access-Accept-Paket zum SIP-Server mit der Framed-IP-Adresse zurückgesendet
wird, wird diese aus dem Paket abgelesen und in die Log-Datei als Nomaden-IP-Adresse
eingetragen (siehe Quell-Code-Anhang-Zeilen 53 bis 77).
Abbildung 46: Nomaden-IP-Adresse (CHIP)
Bei einer Verbindung ist ein anderes Vorgehen notwendig.
Um überhaupt die Framed-IP-Address bei einer Verbindung zur Verfügung zu stellen, müssen
folgende Einträge in der RADIUS-Konfigurations-Datei „acct_users“ erfasst werden:
[email protected] Acct-Status-Type == Start Framed-IP-Address = 139.6.19.58, Exec-Program = "/path/to/exec/acct/start" [email protected] Acct-Status-Type == Stop Framed-IP-Address = 139.6.19.58, Exec-Program = "/path/to/exec/acct/stop" Der zweite und entscheidende Schritt ist es, ein RADIUS-Value-Pair zu erstellen, mit dem
Wert der Framed-IP-Adresse zu füllen und schließlich an die Liste der Paket-Attribute
anzuhängen. So wird die Nomaden-IP-Adresse Bestandteil des noch von RADIUS zu
bearbeitenden Accounting-Requests. (siehe Quell-Code-Anhang-Zeilen 89 bis 93).
Damit das neue Value-Pair als Nomaden-IP-Adresse und nicht als Framed-IP-Adresse in die
Accounting-Log-Datei eingetragen wird, ist folgende Code-Änderung in der Datei:
if (pair->attribute == PW_FRAMED_IP_ADDRESS){ fputs("# NEU # ",outfp); //Attr. fprintf(outfp,"Nomaden-IP-Adresse=%s", pair->strvalue);
6. Implementierung
91
fputs("\t\n", outfp); So kommt folgender Eintrag in der Log-Datei zustande:
# NEU # Nomaden-IP-Adresse = 139.6.19.58
6.2.1 Anschluss-IP-Adresse
Die Anschluss-IP-Adresse hängt nicht mit einem User, sondern mit einem Gerät zusammen,
und daher der Name Physical Line IP-Address (PLIP).
Die Geräte-IP-Adresse ist dem RADIUS-Server nicht bekannt, denn dieser kann nur anzeigen,
was ihm von dem SIP-Proxy-Server zur Verfügung gestellt wird, und in Log-Dateien
eintragen.
Aus diesem Grund muss auch das SIP-Protokoll erweitert werden.
Der SIP-Server bekommt von dem User sowohl bei einer Registrierung als auch bei einem
Verbindungswunsch die IP-Adresse des Geräts, so dass diese beim Bearbeiten der Anfragen
im SIP-Server zur Verfügung steht.
Das zum RADIUS-Server zu sendende Register- oder Accounting-Paket wird dann um ein
Attribut mit dem Wert der Anschluss-IP-Adresse erweitert (siehe Quell-Code-Anhang-Zeilen
292 bis 297).
Abbildung 47: Anschluss-IP-Adresse (PLIP) Und Schon steht die Anschluss-IP-Adresse auch dem RADIUS-Server zur Verfügung und sie
kann in die Log-Datei eingetragen werden (siehe Quell-Code-Anhang-Zeilen 34,35 und 36).
6.3 Verbindungsdauer
Das Bestimmen der Dauer einer VoIP-Verbindung erscheint am einfachsten zu
implementieren, denn ein RADIUS-Server registriert jeden Request-Eintreff-Zeitpunkt, den
so genannten Zeitstempel (Time Stamp). Es würde also reichen die Differenz beider
Zeitstempel zu berechnen, um die Verbindungsdauer zu erhalten.
Doch RADIUS ist ein zustandsloses Protokoll, bei dem keine Daten abgespeichert werden,
die den Zustand der Verhandlungen zwischen Client und Server konservieren. Ein RADIUS-
6. Implementierung
92
Server behandelt z.B. ein ankommendes Accounting-Stop-Packet nicht in direktem
Zusammenhang mit dem davor eingetroffenen Accounting-Start-Paket.
Diese Zustandslosigkeit kann durch Verwendung der Session-ID58 kompensiert werden,
indem die Zeitstempel der Accounting-Stop- und Accounting-Start-Pakete einer Verbindung
mit der dazugehörigen Session-ID gespeichert werden.
Bei der Implementierung wurde der Source-Code so geändert, dass die Session-ID und
Zeitstempel nach dem Zugriff auf dem Accounting-Start-Paket (Schritt (1) aus Abbildung 48)
in eine Datei (Starttime-File) als nacheinander folgenden Datensätze gespeichert werden (2)
(siehe Quell-Code-Anhang-Zeilen 144 bis 158). Beim Eintreffen des Accounting-Stop-Pakets
(3) mit derselben Session-ID wird eine sequenzielle Suche in der Starttime-Datei
durchgeführt, aus der das Finden vom Zeitstempel des mit dem Stop-Paket
zusammenhängenden Start-Pakets resultiert (4). Erst danach kann die Verbindungsdauer aus
der Differenz der beiden Zeitstempel berechnet werden und in die Log-Datei eingetragen (5)
(siehe Quell-Code-Anhang-Zeilen 199 bis 226).
Abbildung 48: Verbindungsdauerermittlung
58 Eine Identifikations-Zeichenfolge, die eine Session kennzeichnet. Sie ist die Selbe bei Zwei oder mehrere Requests, die bei einer Session gesendet wurden.
6. Implementierung
93
6.4 Type of Service
Die IP-Telefonie bietet Lösungen an, Daten-, Audio-, Bilder und Videoübertragung auf ein
Netzwerk zu legen. Das Accounting dieser vielfältigen VoIP-Dienste wird im Rahmen dieser
Diplomarbeit realisiert.
Der Message-Body wird analysiert, um die gebrauchten Daten aus ihm herauszufiltern.
In den Quell-Code-Zeilen 301 bis 322 wird das Bestimmen des Medientyps implementiert.
Abbildung 49: Beispiel eines SIP-Message-Body Der SIP-Server teilt dem RADIUS-Server nicht mit, um welchen Medientyp es sich bei einer
Verbindung handelt, so dass es auch hier nötig ist, das zu sendende Paket um ein Attribut zu
erweitern.
Damit die Paketgröße durch Attributanhänge nicht unnötig groß gemacht wird, wird ein
Attribut für den Medientyp, den verwendeten Codec und die Bandbreite erstellt (siehe Code-
Zeilen 470 bis 491 und Zeilen 510 und 530).
6.5 Quality of Service
6.5.1 Verwendete Codecs
Die zur Kodierung und Komprimierung der Sprach- oder Videodaten verwendeten Codecs
sind bei VoIP von großer Bedeutung, denn sie bestimmen einerseits die Qualität des Dienstes
und andererseits die dafür in Anspruch zu nehmenden Ressourcen, wie Bandbreite und
Hardwareeigenschaften.
Wie aus Abbildung 49 klar zu sehen ist, kommen die verwendeten Audio- und Video-Codecs
im Message-Body in entsprechenden Zeilen als Parameter der Medientypen vor. In diesem
Beispiel wird zur Audiodatenübertragung der PCMU-Codec und zur Videodatenübertragung
der H263 verwendet.
Auch hier muss eine SIP-Paketerweiterung vorgenommen werden, damit die verwendeten
Codecs von RADIUS als Accountig-Daten registriert werden können.
6. Implementierung
94
6.5.2 Bandbreite
Verwendet ein Benutzer einen Codec für die Kodierung seiner Daten, dann muss eine für den
Codec spezifische Bandbreite für die Übertragung der kodierten Daten zur Verfügung gestellt
werden. Je besser die Qualität der Übertragung ist, desto größer ist die dafür reservierte
Bandbreite. Dies macht die von einem Dienst-Benutzer in Anspruch genommenen Bandbreite
unter den wichtigsten Accounting-Daten.
Im Rahmen dieser Diplomarbeit wird eine Codecs-Tabelle in einer selbst definierten MySQL-
Datenbank (sip_ser) erstellt, die verschiedene Codecs mit den dazugehörigen Bandbreiten
enthält. Die in der Tabelle vorkommenden Codecs-Bezeichnungen entsprechen den von den
benutzten User-Agents zum SIP-Proxy-Server gesendeten Bezeichnungen.
Codecs Bandbreite
g729 8 kbps
gsm 15 kbps
gsma 15 kbps
H261 2 Mbps
H263 64 kbps
iLBC 15 kbps
pcma 64 kbps
PCMU 64 kbps
GSMU 15 kbps
Tabelle 9: Codecs-Tabelle der MySQL-Datenbank „sip_ser“
Implementiert wurde ein SIP-Server-Zugriff auf diese Datenbank, um Bandbreiten zu den aus
dem SIP-Message-Body herausgefilterten Codecs zuordnen zu können (Code-377 bis 385,
412 bis 419 und 446 bis 454). Zu diesem Zweck wurde ein separates Modul (datenbank.c)
implementiert (Code-Zeilen 535 bis 564).
Ein String, der den Medientyp, die verwendeten Audio- und Video-Codecs und deren
Bandbreiten enthält, wird erstellt und als Erweiterungsattribut an das zu RADIUS zu
sendende Paket angehängt.
6. Implementierung
95
Der RADIUS-Server kann schließlich die neuen Accounting-Daten in die Log-Datei
eintragen.
Hierunter steht ein Auszug aus einer RADIUS-Log-Datei, der Type-of-Service- und Quality-
of-Service-Accounting-Daten darstellt.
# NEU # Type of Service (1) // Quality of Service # NEU # audio // Codec(Bandbr.): PCMU(64 kbps)/ # NEU # Type of Service (2) // Quality of Service # NEU # video // Codec(Bandbr.): H261(2 Mbps)/
Abbildung 50: Type of Service-/Quality of Service-Accounting
6.6 Übertragenes Volumen
Mit dem übertragenen Volumen (Traffic) ist die Nutzdatenmenge gemeint, die während einer
Verbindung zwischen den Benutzern übertragen wird.
Bei der Implementierung vom Accounting des übertragenen Volumens werden zwei Größen
gebraucht, die Bandbreite und die Verbindungsdauer. Das übertragene Volumen ist das
Produkt dieser beiden Größen.
Wieder stellt die Zustandslosigkeit der SIP- und RADIUS-Protokolle ein Problem dar, denn
die Bandbreite der verwendeten Codecs wird bei einem Accounting-Start-Paket zum
RADIUS-Server gesendet, während die Verbindungsdauer erst nach dem Ende der
Verbindung ermittelt werden kann. Dagegen muss hier auch, wie bei der Ermittlung der
Verbindungsdauer, eine Speicherung der Bandbreite mit der Session-ID erfolgen, so dass die
Bandbreite am Ende der Verbindung zur Verfügung steht. Zur Vereinfachung der
Implementierung wird die Start-Zeit-Datei zu diesem Zweck benutzt, indem nach der Session-
6. Implementierung
96
ID und Timestamp die Bandbreite eingetragen wird (Codezeilen 151 bis 155). Im folgenden
steht ein Auszug aus der Start-Zeit-Datei für zwei Verbindungen.
Um diese relevante Daten aus der Message herauszufiltern, wurde das „sed“-Linux-Befehl
eingesetzt. Hierunter stehen zwei Beispielzeilen zur Ermittlung des Senders und Empfängers
der Instant Message.
system("sed -n '/From/ p' einemessage >> einemessage2"); system("sed -n '/To/ p' einemessage >> einemessage2");
6. Implementierung
98
6.8 Konferenz
Das SIP-Protokoll realisiert eine Konferenz durch Aufbau von zwei Verbindungen, wobei die
erste angehalten werden muss, bevor die zweite aufgebaut wird. Dabei spielt ein
Konferenzteilnehmer die Rolle einer H.323-MCU.
Eine Konferenz wird sonst durch das SIP-Protokoll nicht gekennzeichnet, so dass
Accounting-Daten von Konferenzen grundsätzlich nicht direkt aus SIP-Messages gewonnen
werden können.
6. Implementierung
99
Abbildung 53: Auszug aus einem Konferenz-Verbindungsaufbau Wie mit den Betreuern besprochen wurde, konnte im Rahmen dieser Diplomarbeit das
Accounting von Konferenzen leider nicht implementiert werden. Die Implementierung wurde
aber entworfen.
Eine Konferenz ist, wie aus Abbildung 53 zu schließen ist, durch eine Folge von Requests und
Responses, auf deren Sender, Empfänger und Reihenfolge geachtet werden muss,
gekennzeichnet. Der Algorithmus muss als Hauptkriterium zur Erkennung einer Konferenz
das Versenden von mindestens drei INVITES vom selben Sender und zu verschiedenen
Empfängern haben, ohne ein BYE oder ein CANCEL zu senden oder zu erhalten. Dies
bedeutet, dass ein Benutzer zwei Verbindungen gleichzeitig benutzt. Weitere Kriterien
können bei Notwendigkeit während der Tests bestimmt und implementiert werden.
7. Fazit
100
7. Fazit
Ziel dieser Diplomarbeit war, neue Accounting-Daten für VoIP-Dienste durch Erweiterung
von vorhandenen Protokollen zu gewinnen.
VoIP bietet eine Menge von Vorteilen gegenüber dem herkömmlichen Telefonnetz, ihm ist
das letztere noch an Sprachqualität überlegen.
Um eine gute Qualität bei der IP-Telefonie gewährleisten zu können, ist eine ganze Reihe von
Problemen zu lösen. Durch innovative Algorithmen insbesondere zur Minimierung des
Delays und Echos sowie durch Unterstützung von existierenden Standards bei Codecs und
QoS-Maßnahmen kann aber schließlich eine Sprachqualität erreicht werden, die derjenigen im
Festnetz in nichts nachsteht.
Die bekanntesten VoIP-Standards sind SIP und H.323. Diese wurden im theoretischen Teil
der Diplomarbeit ausführlich vorgestellt und verglichen, so dass man daraus schließen kann,
welcher Standard sich in Zukunft stärker durchsetzen wird. Mit der zunehmenden Ablösung
der Telekommunikationsinfrastruktur durch das IP-Netzwerk scheint es nahe liegend, dass
dabei der aus der IP-Welt kommende Standard, nämlich SIP, gute Karten hat.
Für Authentifizierung-, Autorisierung- und Accounting-Aufgaben in VoIP-Netzen ist das
RADIUS-Protokoll vor allem dank seiner Flexibilität und Erweiterbarkeit sehr geeignet.
Daher stellten zwei Open-Source-Varianten von SIP und RADIUS (SER und Freeradius) die
Basis der Entwicklung im Rahmen dieser Diplomarbeit dar, wobei ein wichtiges Kriterium für
die Wahl der SIP- und RADIUS-Varianten die einwandfreie Interoperabilität ist.
Das weit verbreitete RADIUS-Protokoll zeigt allerdings ein paar Schwächen, zu denen die
Limitierung der Attribut-Datenwerte und die fehlenden Flusskontrollmechanismen des
Transport-Protokolls gehören.
Der RADIUS-Nachfolger DIAMETER bietet Lösungen für zahlreiche Probleme an.
DIAMETER ist ein sitzungsorientiertes Protokoll, seine Pakete sind größer, es arbeitet über
SCTP (Stream Control Transmission Protokoll) anstatt UDP und ihm liegt eine Peer-to-Peer
Kommunikationsstruktur zugrunde.
Deshalb ist eine auf dieser Diplomarbeit basierende Weiterentwicklung der AAA-Funktionen
auf Basis von DIAMETER leichter und rentabler.
Zum Schluss werden auf der folgenden Seite die Endergebnisse der Accounting-Erweiterung
anhand von Accounting-Einträgen einer Video-Konferenz vorgestellt.
7. Fazit
101
Mon Jan 10 16:57:29 2005 Acct-Status-Type = Start Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = 1 User-Name = "[email protected]" # NEU # Nomaden-IP-Adresse = 139.6.19.144 # NEU # Type of Service (1) // Quality of Service # NEU # audio // Codec(Bandbr.): PCMU(64 kbps)/ # NEU # Type of Service (2) // Quality of Service # NEU # video // Codec(Bandbr.): H261(2 Mbps)/ Calling-Station-Id = "sip:[email protected]" Called-Station-Id = "sip:[email protected]"
# User Types VALUE Service-Type Login-User 1 VALUE Service-Type Framed-User 2 VALUE Service-Type Callback-Login-User 3 VALUE Service-Type Callback-Framed-User 4 VALUE Service-Type Outbound-User 5 VALUE Service-Type Administrative-User 6 VALUE Service-Type NAS-Prompt-User 7 # Framed Protocols VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 # Framed Routing Values VALUE Framed-Routing None 0 VALUE Framed-Routing Broadcast 1 VALUE Framed-Routing Listen 2 VALUE Framed-Routing Broadcast-Listen 3 # Framed Compression Types VALUE Framed-Compression None 0 VALUE Framed-Compression Van-Jacobson-TCP-IP 1 # Login Services VALUE Login-Service Telnet 0 VALUE Login-Service Rlogin 1 VALUE Login-Service TCP-Clear 2 VALUE Login-Service PortMaster 3 # Status Types VALUE Acct-Status-Type Start 1 VALUE Acct-Status-Type Stop 2 VALUE Acct-Status-Type Accounting-On 7 VALUE Acct-Status-Type Accounting-Off 8 # Authentication Types VALUE Acct-Authentic RADIUS 1 VALUE Acct-Authentic Local 2 VALUE Acct-Authentic PowerLink128 100 # Termination Options VALUE Termination-Action Default 0 VALUE Termination-Action RADIUS-Request 1
Anhänge
114
# NAS Port Types, available in 3.3.1 and later VALUE NAS-Port-Type Async 0 VALUE NAS-Port-Type Sync 1 VALUE NAS-Port-Type ISDN 2 VALUE NAS-Port-Type ISDN-V120 3 VALUE NAS-Port-Type ISDN-V110 4 # Acct Terminate Causes, available in 3.3.2 and later VALUE Acct-Terminate-Cause User-Request 1 VALUE Acct-Terminate-Cause Lost-Carrier 2 VALUE Acct-Terminate-Cause Lost-Service 3 VALUE Acct-Terminate-Cause Idle-Timeout 4 VALUE Acct-Terminate-Cause Session-Timeout 5 VALUE Acct-Terminate-Cause Admin-Reset 6 VALUE Acct-Terminate-Cause Admin-Reboot 7 VALUE Acct-Terminate-Cause Port-Error 8 VALUE Acct-Terminate-Cause NAS-Error 9 VALUE Acct-Terminate-Cause NAS-Request 10 VALUE Acct-Terminate-Cause NAS-Reboot 11 VALUE Acct-Terminate-Cause Port-Unneeded 12 VALUE Acct-Terminate-Cause Port-Preempted 13 VALUE Acct-Terminate-Cause Port-Suspended 14 VALUE Acct-Terminate-Cause Service-Unavailable 15 VALUE Acct-Terminate-Cause Callback 16 VALUE Acct-Terminate-Cause User-Error 17 VALUE Acct-Terminate-Cause Host-Request 18 # # Non-Protocol Integer Translations # VALUE Auth-Type Local 0 VALUE Auth-Type System 1 VALUE Auth-Type SecurID 2 VALUE Auth-Type Crypt-Local 3 VALUE Auth-Type Reject 4 # # Cistron extensions # VALUE Auth-Type Pam 253 VALUE Auth-Type None 254 # # Experimental Non-Protocol Integer Translations for Cistron-Radiusd # VALUE Fall-Through No 0 VALUE Fall-Through Yes 1
Anhänge
115
VALUE Add-Port-To-IP-Address No 0 VALUE Add-Port-To-IP-Address Yes 1 # # Configuration Values # uncomment these two lines to turn account expiration on # #VALUE Server-Config Password-Expiration 30 #VALUE Server-Config Password-Warning 5 # # $Id: dictionary.ser,v 1.2 2003/09/11 22:05:08 janakj Exp $ # # SIP RADIUS attributes # # Schulzrinne indicates attributes according to # draft-schulzrinne-sipping-radius-accounting-00 # # Sterman indicates attributes according to # draft-sterman-aaa-sip-00 # # Standard indicates a standard RADIUS attribute # which is missing in radiusclient dictionary # # Digest indicates attributes according to # # Proprietary indicates an attribute that hasn't # been standardized # ### acc ### ATTRIBUTE Sip-Method 101 integer # Schulzrinne ATTRIBUTE Sip-Response-Code 102 integer # Schulzrinne ATTRIBUTE Sip-Cseq 103 string # Schulzrinne ATTRIBUTE Sip-To-Tag 104 string # Schulzrinne ATTRIBUTE Sip-From-Tag 105 string # Schulzrinne ATTRIBUTE Sip-Branch-Id 106 string # Schulzrinne ATTRIBUTE Sip-Translated-Req-ID 107 string # Schulzrinne ATTRIBUTE Sip-Source-Ip-Address 108 ipaddr # Schulzrinne ATTRIBUTE Sip-Source-Port 109 integer # Schulzrinne VALUE Service-Type Sip-Session 15 # Schulzrinne ### auth_radius ### # Sip-Session service type is already defined in acc section VALUE Service-Type Call-Check 10 # Standard VALUE Service-Type Emergency-Call 13 # Proprietary ATTRIBUTE Digest-Response 206 string # Sterman ATTRIBUTE Digest-Attributes 207 string # Sterman