diplom arbeit lotfi_faik_2005
DESCRIPTION
Voice over IP - Accounting - SIP - RADIUSTRANSCRIPT
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.
Lotfi Faik
Inhaltsverzeichnis i
i
Inhaltsverzeichnis 1. Einleitung .......................................................................................................... 1
1.1 Begriffserklärung ............................................................................................................. 2 1.2 Motivation und Zielsetzung ............................................................................................. 3 1.3 Aufbau der Arbeit............................................................................................................. 3
2. VoIP (IP-Telefonie)........................................................................................... 5
2.1 Grundsätzliche Unterschiede zu PSTN ............................................................................ 5 2.2 VoIP-Varianten ................................................................................................................ 6
2.2.1 PC-zu-PC-Telefonie .................................................................................................. 6 2.2.2 PC-zu-Telefon-Verbindungen................................................................................... 7 2.2.3 Telefon-zu-Telefon-Verbindungen ........................................................................... 8
2.3 Funktionsweise der IP-Telefonie ..................................................................................... 9 2.3.1 Netzaufbau ................................................................................................................ 9 2.3.2 Komponenten .......................................................................................................... 10 2.3.3 Anrufsignalisierung................................................................................................. 12 2.3.4 Medienübertragung ................................................................................................. 13 2.3.5 Transportprotokolle ................................................................................................. 13
2.4 Quality of Service........................................................................................................... 15 2.4.1 Verzögerung (Latency) ........................................................................................... 15 2.4.3 Jitter ......................................................................................................................... 18 2.4.4 Echo......................................................................................................................... 19 2.4.5 Paketverluste (Packet Loss) .................................................................................... 20 2.4.6 Sprach-Aktivitäts-Entdeckung (Voice Activity Detection) .................................... 21
2.5 Codecs ............................................................................................................................ 22 2.5.1 Kodierungsverfahren............................................................................................... 24 2.5.2 Sprachdaten-Komprimierung .................................................................................. 26 2.5.3 Standards der Sprachkodierung............................................................................... 27 2.5.4 Qualität der Codecs ................................................................................................. 28
2.6 H.323-Standard .............................................................................................................. 30 2.6.1 Architektur .............................................................................................................. 30 2.6.2 H.323-Protokollsuite ............................................................................................... 31
2.6.2.1 RAS-(Registration Admission Status) Signalisierung ..................................... 31 2.6.2.2 Anruf-Kontroll-Signalisierung (H.225) ........................................................... 35 2.6.2.3 Medien-Kontroll-Signalisierung (H.245)......................................................... 35 2.6.2.4 Anruf-Signalisierung (Q.931) .......................................................................... 35 2.6.2.5 Unterstützung von Datenanwendungen nach T.120 ........................................ 36 2.6.2.6 Struktur von Anruf-SIG-Nachrichten beim H.225.0........................................ 36
2.6.3 H.323-Verbindungsablauf ....................................................................................... 37 2.6.4 Zusammenfassung................................................................................................... 38
2.7 SIP (Session Initiation Protocol) .................................................................................... 39 2.7.1 SIP-Protokollhierarchie........................................................................................... 39 2.7.1 SIP-Architektur ....................................................................................................... 39 2.7.2 Grundlegende Funktionsweise ................................................................................ 42
2.7.2.1 Adressierung..................................................................................................... 42
Inhaltsverzeichnis ii
ii
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
2.7.3 SIP-Message............................................................................................................ 43 2.7.3.1 SIP-Request ...................................................................................................... 48 2.7.3.2 SIP-Response ................................................................................................... 49
2.7.4 SIP-Registrierung .................................................................................................... 50 2.7.4 SIP-Verbindungsablauf ........................................................................................... 52
2.8 SIP im Vergleich zu H.323 ............................................................................................ 53 2.8.1 Auf- und Abbau einer Verbindung.......................................................................... 53 2.8.2 Komplexität ............................................................................................................. 53 2.8.3 Erweiterbarkeit ........................................................................................................ 54 2.8.4 Skalierbarkeit .......................................................................................................... 54
3. AAA (Authentication, Authorization, Accounting) und Billing .................... 55
3.1 AAA-Komponenten ....................................................................................................... 57 3.1.1 AAA-Clients............................................................................................................ 57 3.1.2 AAA-Server ............................................................................................................ 57 3.1.3 AAA-Proxies........................................................................................................... 57
3.2 AAA-Architektur ........................................................................................................... 58 3.3 AAA-Protokolle ............................................................................................................. 60
3.3.1 RADIUS.................................................................................................................. 60 3.3.2 TACACS ................................................................................................................. 60 3.3.3 DIAMETER ............................................................................................................ 60
4. RADIUS .......................................................................................................... 62
4.1 Einführung...................................................................................................................... 62 4.2 Radius-Eigenschaften..................................................................................................... 62 4.3 RADIUS-Spezifikationen............................................................................................... 64
4.3.1 Paketformat ............................................................................................................. 64 4.3.2 Pakettypen ............................................................................................................... 65 4.3.3 Attributformat.......................................................................................................... 66 4.3.4 Proxying .................................................................................................................. 67
4.4 Arbeitsablauf der RADIUS-Authentifizierung .............................................................. 67 4.5 RADIUS-Accounting ..................................................................................................... 69
4.5.1 Wie funktioniert Radius-Accounting? .................................................................... 69 4.5.2 Accounting-Pakettypen ........................................................................................... 69 4.5.3 Arbeitsablauf des RADIUS-Accounting................................................................. 70
5. Entwicklungsumgebung.................................................................................. 72
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.2.4 Anwendung ............................................................................................................. 77 5.2.4.1 SER starten....................................................................................................... 77 5.2.4.2 Benutzer anlegen .............................................................................................. 77 5.2.4.3 Registrierte Benutzer ansehen.......................................................................... 78
5.2.5 SERWEB (Web-Interface von SER)....................................................................... 78
Inhaltsverzeichnis iii
iii
5.2.5.1 Installation........................................................................................................ 78 5.2.5.2 Konfiguration ................................................................................................... 78 5.2.5.3 Anwendung ...................................................................................................... 79
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. Implementierung ............................................................................................. 88
6.1 Erweiterungsanforderungen ........................................................................................... 88 6.2 Mobilität ......................................................................................................................... 89
6.2.1 Nomaden-IP-Adresse .............................................................................................. 89 6.2.1 Anschluss-IP-Adresse ............................................................................................. 91
6.3 Verbindungsdauer .......................................................................................................... 91 6.4 Type of Service .............................................................................................................. 93 6.5 Quality of Service........................................................................................................... 93
6.5.1 Verwendete Codecs................................................................................................. 93 6.5.2 Bandbreite ............................................................................................................... 94
6.6 Übertragenes Volumen................................................................................................... 95 6.7 Instant Messaging........................................................................................................... 96 6.8 Konferenz ....................................................................................................................... 98
7. Fazit ............................................................................................................... 100
Abbildungs- und Tabellenverzeichnis............................................................... 102
Literaturverzeichnis........................................................................................... 104
Abkürzungenverzeichnis................................................................................... 106
Anhang 1: SIP Status Code ............................................................................... 110
Anhang 2: Dictionary File................................................................................. 111
Anhang 3: RADIUS-Attribut-Typen................................................................. 117
Anhang 4: Quell-Code-Änderungen ................................................................. 119
1. Einleitung
1
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
Abrechnungslösungen genügend Accounting-Daten anzubieten.
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
synthetisches Sprachmodell abschätzt. [18]
2.4.6 Sprach-Aktivitäts-Entdeckung (Voice Activity Detection)
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
auswählen kann.
Codec Nutzdatenrate
(Kbps) Verzögerung
ms Prozessorlast
MIPS26 MOS
G.711 (PCM) 64 0,125 0 4,1 G.726 (ADPCM) 32 0,125 6,5 3,85 G.728 (LD-CELP) 15 2 37,5 3,61 G.729 (CS-ACELP) 8 20 34 3,92 G.729a (CS-ACELP) 8 20 17 3,7 G.723.1 (MP-MLQ) 6,3 70 25 3,9 G.723.1 (ACELP) 5,3 70 25 3,65
Tabelle 2: Vergleich von Qualität und Komplexität verschiedener ITU-Codecs [18]
26 MIPS: Million Instructions per Second
2. VoIP (IP-Telefonie)
30
2.6 H.323-Standard Der H.323 Standart (Packet Based Multimedia Communications Systems) ist eine
Rahmenempfehlung der ITU-T27 von 1996 bzw. 1998 (Rev. 2) welche auf ca. 50 Standards
verweist. Diese legen die technischen Voraussetzungen für die multimediale Kommunikation
über nonguaranteed QoS-Netzwerke fest. Wobei besonders auf Beschreibung der
Komponenten, Verarbeitung der Medienströme (Audio, Video, Daten),
Verbindungsmanagment und Interworking verschiedener Netzwerke eingegangen wird.
2.6.1 Architektur
H.323 beschreibt die Architektur und die Funktionen von einzelnen Systemkomponenten für
die Übermittlung von Audio und Video in IP-Netzen. Die Summe aller Elemente (H.323
Entities) in einem Netzwerk wird als H.323 Netzwerk bezeichnet.
H.323 unterscheidet zwischen folgenden Komponenten
Terminal Ein H.323 Terminal ist ein Endgerät, mit dem eine bidirektionale Echtzeitkommunikation mit
anderen Terminals bzw. Gateways oder einer MCU möglich ist.
Gateway Wie Terminals, so sind auch Gateways Endgeräte in einem H.323 Netzwerk. Gateways
ermöglichen die Verbindung eines H.323 Netzwerks zu anderen Netzwerken, wie z. B. dem
SCN.
MCU (Multipoint Controler) Eine MCU ermöglicht den Aufbau einer Konferenzschaltung (Multipoint-Konferenz)
zwischen mehreren Endgeräten.
Gatekeeper Als zentrale Stelle in einem H.323 Netzwerk übernimmt der Gatekeeper verschiedene
Kontroll- und Verwaltungsaufgaben für alle registrierten Endgeräte. Eine Gruppe von
Terminals, die von einem Gatekeeper kontrolliert wird, bildet eine H.323-Zone (kurz Zone).
27 ITU-T: Telecommunication Standardization Sector of ITU
2. VoIP (IP-Telefonie)
31
Abbildung 17: H.323-Komponenten
2.6.2 H.323-Protokollsuite
Die H.323-Protokollsuite basiert auf mehreren Protokollen, die in Abbildung 18 gezeigt sind.
Die Protokollfamilie unterstützt Erlaubnis, Aufbau, Zustand, Trennung, Medienströme und
Meldungen vom Anrufen in H.323-Systemen.
Abbildung 18: H.323-Protokollhierarchie
2.6.2.1 RAS-(Registration Admission Status) Signalisierung
Es handelt sich hier um die Steuerung, die zwischen Terminals und Gatekeeper abläuft. Der
Gatekeeper stellt quasi eine Zentrale innerhalb einer H.323-Zone dar. Ein Terminal kann nur
2. VoIP (IP-Telefonie)
32
dann eine Verbindung initiieren, wenn es beim Gatekeeper bereits registriert ist. Beim
Verbindungsaufbau muss jedes Terminal jede neue Verbindung beim Gatekeeper anmelden,
falls keine sog. pre-granted Admission, also eine „Vorausbewilligung“ vorliegt. Damit wird
auch die benötigte Bandbreite beim Gatekeeper angemeldet.
Dafür wird ein RAS-Kanal zwischen Endpunkten und dem Gatekeeper über ein IP-Netzwerk
eingerichtet. Diese unzuverlässige UDP-Verbindung überträgt die RAS-Meldungen, die die
Registrierungs-, Erlaubnis-, Bandbreitenänderungs- und Zustandsprozeduren ausführen.
Gatekeeper-Entdeckung Innerhalb einer Zone können mehrere Gatekeeper eingesetzt werden, um die Ausfallsicherheit
zu erhöhen. Jeder Endpunkt einer Zone wird von einem Gatekeeper dieser Zone verwaltet.
Somit muss jeder neue Endpunkt bei einem Gatekeeper registriert werden. Hierfür muss
zuerst ermittelt werden, welcher Gatekeeper für die Verwaltung des neuen Endpunktes
zuständig ist. Jeder neue Endpunkt muss somit seinen Gatekeeper entdecken (auffinden).
Abbildung 19 illustriert die Gatekeeper-Entdeckung.
Um den Gatekeeper zu entdecken, sendet ein Endpunkt eine Multicast-Nachricht
GatekeeperRequest (GRQ). Ein oder mehrere Gatekeeper können mit einer Nachricht
GatekeeperConfirmation (GCF) antworten, in der sie dem Endpunkt ihre Bereitschaft
signalisieren, als dessen Gatekeeper zu fungieren. Falls mehrere Gatekeeper auf die Anfrage
antworten, steht es dem Endpunkt frei, für welchen er sich entscheidet. Der Gatekeeper, der
für den Endpunkt nicht zuständig ist, antwortet mit GatekeeperReject (GRJ).
Abbildung 19: Endeckung des zuständigen Gatekeeper (GK) [1]
Registrierung Die Registrierung beim Gatekeeper ist der Prozess, während dessen Ablauf ein neuer
Endpunkt einer Zone den Gatekeeper über seine Adresse für Audio- und
Videokommunikation informiert. Sie wird bei H.323 als Alias-Adresse bezeichnet.
Da jedes IP-Telefon über eine Telefonnummer bzw. eine Alias-Adresse, in der Form
2. VoIP (IP-Telefonie)
33
[email protected], verfügen muss, handelt es sich hierbei um die Bekanntgabe seiner Alias-
Adresse.
Abbildung 20 illustriert die Registrierung. Ein Endpunkt sendet eine Nachricht
RegistrationRequest (RRQ) zum Gatekeeper mit der Angabe seiner Alias-Adresse. Der
Gatekeeper muss bei der Registrierung die Alias-Adresse des Endpunktes zu seiner IP-
Adresse zuordnen und dies in einer speziellen Tabelle mit den Zuordnungen Alias-Adresse
=> IPAdresse eintragen.
Der Gatekeeper kann entweder mit RegistrationConfirm (RCF) die Registrierung annehmen
oder mit RegistrationReject (RRJ) die Registrierung ablehnen. Wie Abbildung 20 zeigt, kann
sich ein Endpunkt beim Gatekeeper durch das Absenden von UnregistrationRequest (URQ)
deregistrieren (abmelden). Der Gatekeeper kann die Deregistrierung entweder mit
UnregistrationConfirm (UCF) bestätigen oder mit UnregistrationReject (URJ) ablehnen.
Abbildung 20: Ablauf: a) der Registrierung, b) der Deregistrierung [1]
Lokalisierung der Endpunkte Eine Aufgabe jedes Gatekeepers besteht in der Verwaltung einer Tabelle mit der Zuordnung
Alias-Adresse => IP-Adresse. Die Abfrage der IPAdresse eines Endpunktes wird bei H.225.0
als Location-Prozess bezeichnet. Abbildung 21 veranschaulicht die Bedeutung dieses
Prozesses.
Hier fragt der Endpunkt A seinen Gatekeeper GK1 nach der IP-Adresse des Endpunktes B,
d.h. seines Kommunikationspartners, bereits bei der Anmeldung der zu initiierenden
Verbindung mit der Nachricht ARQ ab.
Befindet sich der Endpunkt B aber in einer anderen (H.323-)Zone, so muss GK1 die IP-
Adresse des Endpunktes B vom Gatekeeper dieser Zone abfragen. Hierfür definiert H.225.0
entsprechende Nachrichten.
Wie Abbildung 21 zeigt, sendet der GK1 der Zone 1 an den GK2 der fremden Zone 2 die
Nachricht LocationRequest (LRQ), in der er die Alias-Adresse des Endpunktes B angibt und
nach seiner IP-Adresse fragt. Der GK2 antwortet normalerweise mit LocationConfirm (LCF),
2. VoIP (IP-Telefonie)
34
in der die gewünschte IPAdresse enthalten ist. Falls der GK2 die gewünschte IP-Adresse nicht
liefern kann, antwortet er mit LocationReject (LRJ).
Abbildung 21: Verlauf eines Location-Prozesses [1]
Zulassung von Verbindungen Jeder Endpunkt darf nur dann eine abgehende Verbindung für Audio- bzw.
Videokommunikation initiieren bzw. eine ankommende Verbindung annehmen, wenn dies
vom Gatekeeper zugelassen wurde (Admission). Damit kann der Verbrauch der
Übertragungskapazität (Bandbreite) im IP-Netz vom Gatekeeper kontrolliert werden. Nach
dem Ablauf der Kommunikation muss eine abgebaute Verbindung beim Gatekeeper
abgemeldet werden, sodass er die reservierte Bandbreite für andere Verbindungen freigeben
kann. Abbildung 22 zeigt die Zulassung (Admission) einer Verbindung für Audio- bzw.
Videokommunikation und Freigabe der reservierten Bandbreite (Disengage) nach dem
Abbau der Verbindung.
Abbildung 22: Funktionen Admission und Disengage [1]
2. VoIP (IP-Telefonie)
35
2.6.2.2 Anruf-Kontroll-Signalisierung (H.225) Um eine Verbindung zwischen zwei Endpunkten für die Übermittlung von Echtzeitmedien
(Audio/Sprache, Video) aufbauen zu können, werden zwei Signalisierungsprotokolle H.225.0
und H.245 als H.323-Signalisierung (kurz H.323-SIG) verwendet. H.225.0 definiert ein
Anruf-Signalisierungs-Protokoll (Anruf-SIG-Protokoll), nach dem der H.245-Kanal aufgebaut
und abgebaut wird. Über den H.245-Kanal werden logische RTP- und RTCP-Kanäle für die
Audio/Video-Kommunikation eingerichtet. H.225.0 nutzt einige Nachrichten des D-Kanal-
Protokolls Q.930/Q931 vom ISDN. Bei H.225.0 handelt es sich im Prinzip um eine
Realisierung des D-Kanal-Protokolls über TCP-Verbindungen.
2.6.2.3 Medien-Kontroll-Signalisierung (H.245) Es handelt sich hier um die Steuerung beim Auf- und Abbau logischer Kanäle für die Audio-
und Video-Übermittlung. Diese logischen Kanäle stellen die RTP-Sitzungen (Real Time
Transport Protocol) dar und entsprechen weitgehend den B-Kanälen im ISDN. Die Steuerung
beim Auf- und Abbau logischer Kanäle wird zwischen jeweils zwei Terminals über den
H.245-Steuerungskanal ausgetauscht. Für die Übermittlung von H.245-Nachrichten wird das
Protokoll TCP verwendet
Die wichtigsten Funktionen von H.245 sind:
Austausch der Terminal-Fähigkeiten (Capability Exchange),
Master/Slave-Festlegung28 (Master/Slave Determination),
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
entsprechenden Nachricht zurückgesandt.
Abbildung 27: Interaktion verschiedener SIP-Server
2. VoIP (IP-Telefonie)
42
2.7.2 Grundlegende Funktionsweise
2.7.2.1 Adressierung Alle Objekte, die von SIP adressiert werden können, werden mit einem so genannten SIP
Uniform Resource Locator (URL) identifiziert. Das Format einer derartigen URL entspricht
der Form sip:user@host, was im Wesentlichen mit einer E-Mail Adresse vergleichbar ist. Der
User-Teil der URL ist frei wählbar. Es kann sich dabei entweder um eine Person bzw. eine
Telefonnummer, um eine Gruppe von Personen oder um einen allgemeinen Dienst handeln,
dem keine bestimmte Person zugeordnet werden kann. Der Hostteil kann aber ein
Domänename oder eine Netzwerkadresse sein. Die folgenden Beispiele zeigen zwei mögliche
SIP-URLs:
sip:snom1@ serserver.dn.fh-koeln.de
Welche SIP URL ein Benutzer verwenden will, spielt grundsätzlich keine Rolle. Jedoch sollte
beachtet werden, dass die Verwendung einer URL, welche aus dem Benutzernamen abgeleitet
werden kann (z.B. sip:[email protected]), die Anonymität einer reinen
Telefonnummer untergräbt.
2.7.2.2 Das Auffinden eines Servers Ein Client kann eine SIP-Anfrage entweder direkt an einen lokal konfigurierten Proxy-Server
senden oder an die IP-Adresse und den Port der zugehörigen SIP-URL. Das Senden einer
direkten SIP-Anfrage ist relativ einfach, da die Applikation des Endsystems den Proxy-Server
kennt. Das Senden einer SIP-Anfrage auf die zweite Weise ist aus den folgenden Gründen
etwas komplizierter:
- Der Client muss die IP-Adresse und Portnummer des Servers bestimmen, für den die
Anfrage bestimmt ist.
- Wenn die Portnummer in der angefragten SIP-URL nicht angegeben ist geben ist, ist
der Standardport 5060.
- Wenn der Protokolltyp in der Anfrage-SIP-URL nicht geben ist, muss der Client erst
versuchen sich mit dem User Datagram Protocol (UDP) zu verbinden und
anschließend mit dem Transmission Control Protocol (TCP).
- Der Client fragt den Domain-Name-System (DNS-)Server nach der Host-IP-Adresse.
Wenn dieser keine Adresse bestimmen kann, kann der Client den Server nicht finden
und damit nicht mit der Anfrage fortfahren.
2. VoIP (IP-Telefonie)
43
2.7.2.3 SIP-Transaktionen Nachdem die Adressen aufgelöst sind, sendet der Client eine oder mehrere SIP Anfragen und
empfängt eine oder mehrere Antworten von dem angegebenen Server. Alle mit dieser
Aktivität verbundenen Anfragen und Antworten werden als Teil einer SIP-Transaktion
betrachtet. Aus Gründen der Einfachheit und Konsistenz stimmen die Headerfelder in allen
Anfrage-Meldungen mit Headerfeldern in allen Antwort-Meldungen überein.
SIP-Transaktionen können entweder per UDP oder per TCP übertragen werden. Im Falle des
TCP können alle Anfrage und Antwort-Meldungen in Bezug auf eine einzige SIP Transaktion
über dieselbe TCP Verbindung übertragen werden. Über dieselbe TCP-Verbindung können
auch separate SIP-Transaktionen zwischen den beiden Einheiten übertragen werden. Bei der
Verwendung des UDP wird die Antwort an die Adresse gesendet, die im Headerfeld der
Anfrage angegeben wurde.
2.7.2.4 Das Auffinden eines Benutzers Die angerufene Seite könnte sich mit der Zeit von einem zu mehreren Endsystemen bewegen.
Er oder sie könnte während der Teilnahme an einer Konferenz vom Local-Area-Netzwerk
(LAN) der Firma in das eigene Büro zu Hause wechseln, das über den eigenen Internet
Service Provider (ISP) oder über eine öffentliche Internet Verbindung mit dem Internet
verbunden ist. Um Standort-Dienste zu ermöglichen muss SIP daher Platz für die Flexibilität
und Mobilität der IP Endsysteme bieten. Die Standorte dieser Endsysteme könnten über den
SIP-Server registriert werden oder auch über andere Standort-Server, die sich außerhalb des
SIP befinden. Im letzteren Fall speichert der SIP-Server die Standliste mit Hilfe des externen
Standort-Servers, der mehrere Möglichkeiten zurückgibt.
Die Aktion und das Ergebnis einer Benutzerlokalisierung hängen vom verwendeten SIP-
Servertyp ab. Ein SIP Redirect-Server gibt einfach die vollständige Standortliste zurück und
bietet dem Client damit die Möglichkeit, den Benutzer direkt aufzufinden. Ein SIP-Proxy-
Server kann die Adressen parallel durchprobieren, bis der Anruf erfolgreich ist.
2.7.3 SIP-Message
Wie erwähnt gibt es zwei Typen von Nachrichten, eine Request und eine Response. Beide
haben eine gleich aufgebaute Struktur. (Abbildung 28)
2. VoIP (IP-Telefonie)
44
Abbildung 28: Aufbau einer SIP-Message
Die Leerzeile (Blank Line) zwischen dem letzten Header und dem Message ist zwingend,
auch wenn kein Message Body vorhanden ist.
Jede Zeile, sei das eine Start-Line, eine Headerzeile oder eine Zeile aus dem Message Body,
wird mit einem CRLF32 (Carriage Return Line Feed) abgeschlossen.
Start-Line Mit der Start-Line kann unterschieden werden, ob die SIP-Message ein Request oder ein
Response ist, denn sie unterscheiden sich in der Syntax.
Per [rfc3261] wird die Start-Line in einer Request Message als Request-Line definiert und die
Response Message startet mit einer Status-Line. Das Format für die beiden Start-Lines sieht
folgendermaßen aus:
Request: method SP33 request-URI SP SIP-Version CRLF
Response: SIP-Version SP status-code SP reason phrase CRLF
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
im Klartext vor.
34 HTML: Hyper Text Markup Language
2. VoIP (IP-Telefonie)
47
START-LINE INVITE sip:[email protected] SIP/2.0
HEADER
Via: SIP/2.0/UDP 1CSeq: 799 INVITE To: <sip:[email protected]> Content-Type: application/sdp From: "snom1" <sip: [email protected] >;tag=64ACEA4F Call-ID: [email protected] Subject: Important Call Content-Length: 183 User-Agent: KPhone/3.11 Contact: "snom1" <[email protected];transport=udp>
BODY
v=0 o=root 0 0 IN IP4 139.6.19.49 s=call c=IN IP4 139.6.19.49 t=0 0 m=audio 32820 RTP/AVP35 0 97 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000
Abbildung 29: Beispiel einer SIP-Request (INVITE) mit SDP-Beschreibung
In der Abbildung 29 ist ein Beispiel für eine SDP-Nachricht zu sehen. Jede Zeile dieser
Nachricht besitzt die Form type=value. Der type besteht dabei immer aus genau einem
Buchstaben. Für den Inhalt des value ist kein bestimmtes Format vorgeschrieben. Jedoch sind
die Interpretationsmöglichkeiten des value vom angegebenen type abhängig.
Die Sitzungsbeschreibung setzt sich aus 3 Teilen zusammen:
- Spezifikation der Sitzung (v-,o-,s- und c-Zeile)
- Zeitbeschreibung (t-Zeile)
- Medienbeschreibung (m- und a-Zeile)
Am Anfang der Beispielnachricht ist in Zeile 1 die verwendete Protokollversion zu sehen. Die
Zeile 2 enthält Informationen über den Besitzer bzw. Initiator der Sitzung und eine
Identifikationsnummer für die Sitzung selbst, dessen Bezeichnung in Zeile 3 zu finden ist.
Jede SDP-Nachricht muss Informationen über die Netzwerkverbindung der Sitzung
beinhalten. In der Beispielnachricht wird diese Information in der Zeile 4 angegeben. Sie
besteht aus dem Netzwerktyp (IN = Internet), dem Adresstyp und der IP-Adresse, welche für
die Sitzung verwendet wird. Üblicherweise wird diese IP-Adresse in Form einer Multicast-
Adresse vorliegen.
In der Zeile 5 wird eine Zeitspanne angegeben, in der die Sitzung gültig ist.
In der Zeile 6 wird ein Attribut für das verwendete Medium angegeben, es wird ein
Audiokanal definiert, welcher auf Port 32820 über RTP gesendet wird, dabei beherrscht das
Endgerät die Audiocodecs deren Parameter 0, 97 und 3 sind. 35 RTP/AVP: Realtime Transport Protocol/Audio Video Profiles)
2. VoIP (IP-Telefonie)
48
In den Zeilen 7, 8 und 9 werden die Audiocodecs durch das Attribut rtpmap näher erläutert, es
handelt sich um die Codecs PCM µ-law, GSM und iLBC mit den Abtastraten (8000 Hz).
In der folgenden Tabelle sind sämtliche SDP-Parameter kurz beschrieben.
Tabelle 3: SDP-Parameter [7]
2.7.3.1 SIP-Request SIP Requests werden vom Client zum Server geschickt. Die Methoden unterscheiden die
Nachrichten und lösen beim Server entsprechende Responses aus. Die sechs verschiedenen
Methoden werden nachfolgend erläutert.
ACK: Der Client bestätigt mit einem ACK, dass er vom Server eine Final-Response
(z.B. 200 OK).
BYE: Um einen Anruf zu beenden wird entweder vom Anrufer oder vom
Angerufenen eine BYE-Request versendet.
2. VoIP (IP-Telefonie)
49
CANCEL: Hat der Server nicht mit einer Final-Response auf eine Request geantwortet,
kann der Client den Request mit einem CANCEL abbrechen.
INVITE: INVITE wird benützt, um einen Anruf zu initialisieren
OPTIONS: Der Client kann mit dieser Methode mehr über die Kapazitäten und die
unterstützten Methoden des Servers erfahren.
REGISTER: Clients können ihre aktuelle Position und damit die aktuelle Adresse
registrieren lassen. SIP Server, welche REGISTER Requests behandeln
können, werden Registrar genannt.
2.7.3.2 SIP-Response Jeder Request außer ACK muss mit einer geeigneten Response beantwortet werden.
START-LINE SIP/2.0 200 OK
HEADER
From: <sip:[email protected]>;tag=43w10q722k
CSeq: 4 NOTIFY
Call-ID: 3c26700938ef-3fdv4sj9oz7m@139-6-19-49
To: <sip:139.6.19.49:5060>;tag=pq7h13pek3
Content-Length: 0
User-Agent: kphone/4.0
Contact: "snom1" <[email protected];transport=udp>
Abbildung 30: Beispiel einer SIP-Response
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
Skalierungsproblem.
Eigenschaft H.323 SIP Herausgeber ITU-T IETF Philosophie
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
Port 1812 (Authentication Port) gesendet.
51 CHAP: Challenge Handschake Authentication Protocol
4. RADIUS
65
Code Type of RADIUS-Message
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server (under continued development) 13 Status-Client (under continued development) 255 Reserved
Tabelle 6: RADIUS-Codes
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
(kompilierte Version: (Download aus: ftp://ftp.berlios.de/pub/ser/0.8.12/bin/ ))
5. Entwicklungsumgebung
75
5.2.3 Konfiguration
a) Konfigurationsdatei SERs Konfigurationsdatei ser.cfg ist in vier Hauptabschnitte geteilt:
o Globale Parameter: Hier werden die globalen SER-Einstellungen festgelegt.
In unserer ser.cfg habe ich folgendes vorgenommen:
#debug=9 #Auskommentieren für Debug-Modus
fork=no #Andernfalls ( fork=yes ) erzeugt SER eigene
#Kinderprozesse und läuft im Hintergrund
log_stderror=yes
#log-messages zu standard error weiterleiten
listen=139.6.19.65
#SER kann mehrere IP-Adressen im Normalmodus
#benutzen, aber nur eine im Debug-Modus, hier
#wird sie festgelegt
o Laden externer Module: Hier werden die gebrauchten externen Module geladen.
Manche Module müssen nach einer gewissen Reihenfolge geladen werden.
Durch Aufruf vom Modul „auth_db.so“ wird SER darauf hingewiesen bei der
Authentifizierung der User die User-Daten aus einer Datenbank zu holen, so muss ein
Datenbank-Modul z.B. „mysql.so“-Modul davor geladen werden.
Dieser Abschnitt sieht bei uns so aus:
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/exec.so"
5. Entwicklungsumgebung
76
loadmodule "/usr/local/lib/ser/modules/group.so"
loadmodule "/usr/local/lib/ser/modules/msilo.so"
loadmodule "/usr/local/lib/ser/modules/print.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/jabber.so"
loadmodule "/usr/local/lib/ser/modules/uri.so"
loadmodule "/usr/local/lib/ser/modules/vm.so"
Funktionen und Abhängigkeiten der Module sind in http://www.iptel.org/ser/doc/module
erleäutert.
o Modulparameter: Parameter werden den Modulen durch den „modparam“-
Ausdruck angepasst.
- modparam("usrloc", "db_mode", 2))
#Datenbankzugriffsmodus
- modparam("auth", "calculate_ha1", yes)
#Der Server gewinnt Passwörter aus Berechnung von
#HA1-Strings54
- modparam("auth_db", "password_column", "password")
#Name der Tabellenspalte „password“, die die
#Benutzerpasswörter enthält
o Routing-Blöcke
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
in /usr/lib zu erstellen:
Shell>ln –s libmysqlclient.so.12.0.0 libmysqlclient.so.10
In der Datei /etc/ld.so.conf muss auch /usr/lib hinzugefügt werden
5.2.4 Anwendung
5.2.4.1 SER starten Bei laufendem MySQL-Server55
Shell> ser restart
an der Konsole eingeben.
Die Umgebungsvariable SIP_DOMAIN dürfen wir nicht vergessen, damit das serctl-Tool
benutzt werden kann
Shell> export SIP_DOMAIN="139.6.19.65”
Shell> serctl moni
Durch den letzen Befehl wird die Funktionalität des SER-Servers überprüft.
5.2.4.2 Benutzer anlegen Benutzer „snom1“ (Snom-Telefon) wird zur Datenbank wie folgt hinzugefügt:
Shell> serctl ul add snom1 1234 sip:[email protected]
Benutzername: snom1
55 Kurze Beschreibung der Installation und Bedienung wird in Kapitel 5.5 geschehen
5. Entwicklungsumgebung
78
Passwort: 1234
Realm (Domäne): 139.6.19.65
Bei der Eingabe wird das admin-Passwort gefragt, und es lautet „heslo“
Und ähnlich Benutzer snom2:
Shell> serctl ul add snom2 1234 sip:[email protected]
5.2.4.3 Registrierte Benutzer ansehen Shell> serclt show user
Es werden dann alle registrierten Benutzer angezeigt.
5.2.5 SERWEB (Web-Interface von SER)
SERWEB ist die Web-Toolbox vom SIP-Express-Router (SER) und sie kann für folgende
Zwecke benutzt werden:
Registrieren neuer Benutzer
Verwaltung von Users-Accounts
Ansehen von verpassten Anrufen
Senden von sofortigen Kurzmitteilungen (IM: Instant Messages)
Ansehen von gespeicherten IMs und Voicemail-Messages
5.2.5.1 Installation Packet entpacken
Shell> tar -zvxf serweb_2004-01-04.tar.gz
5.2.5.2 Konfiguration Es werden folgende Änderungen vorgenommen:
• In der Datei config.php
//configure database
/* these are the defaults with which SER installs; if you
changed the SER account for MySQL, you need to update
here*/
$this->db_host="139.6.19.65"; //database host
$this->db_name="ser"; //database name
$this->db_user="ser"; //database conection user
$this->db_pass="heslo"; //database conection password
• In der Datei /etc/php.ini
short_open_tag = On
5. Entwicklungsumgebung
79
register_globals = On
• Apache (http-Server):
Standard-Rechner: /serweb_2004-01-04/html/admin
P.S.: Linux_Neustart erforderlich
• Das Layout kann wie folgt definiert werden
echo "<body><h1>" > html/prolog.html
echo "</h1><hr>" > html/separator.html
echo "</body>" > html/epilog.html
• Auf den SER-fifo (named Pipe) darf jeder zugreifen Shell> chmod 777 /tmp/ser_fifo
5.2.5.3 Anwendung Hierunter steht ein Screenshot vom Anmeldefenster von SERWEB:
Abbildung 43: Screenshot von SERWEB-Anmeldefenster
5. Entwicklungsumgebung
80
Hier ein Screenshot vom User-Profil:
Abbildung 44: Screenshot von SERWEB-Userprofil
Und Hierbei wird ein IM an [email protected] versendet:
Abbildung 45: Screenshot von SERWEB-Send-IM
5. Entwicklungsumgebung
81
5.3 Freeradius
5.3.1 Was ist Freeradius?
Freeradius ist eine Open Source RADIUS-Variante und steht unter der GPL (Genaral Public
License). Das Freeradius-Projekt wurde 1999 gestartet und wird immer noch
weiterentwickelt.
Im Sommer 2004 hat Freeradius seine erste Vollversion 1.0 erreicht.
Freeradius zeichnet sich den Entwicklern zufolge durch hohe Skalierbarkeit, vom Embedded-
System bis hin zu großen Installationen mit mehreren Millionen Nutzern aus. Zudem lässt
sich die Software über diverse Module erweitern.
Insgesamt bringt Freeradius mehr als 50 herstellerspezifische Dictionary-Dateien mit
unterstützt mehr Protokolle zur Authentifzierung als die meisten kommerziellen Produkte.
Volle Unterstützung so wie alle Freeradius-Versionen findet man in der Web-Site:
www.freeradius.org.
5.3.2 Installation und Grundkonfiguration
In den folgenden Unterabschnitten werde ich die Installation und Grundkonfiguration vom
Radiusclient und Radiusserver schrittweise erklären.
a) Radiusclient Die Datei “radiusclient-0.3.2.tar.gz” auspacken
Shell> tar xvfz radiusclient-0.3.2.tar.gz
Shell> cd radiusclient-0.3.2
Die Library Kompilieren und installieren
Shell>./configure
Shell> make all
Shell> make install
Bei Default-Konfiguration (Shell>./configure ohne Parameter) werden alle
Konfigurationsdateien von der Radiusclient-Library ins Verzeichnis:
/usr/local/etc/radiusclient gelegt.
Danach müssen diese Änderungen in den folgenden Dateien durchgeführt werden:
5. Entwicklungsumgebung
82
• radiuclient.conf-File
authserver 139.6.19.65
acctserver 139.6.19.65
Authentifizierungs- und Accounting-Server ist der mit der angegebenen IP-Adresse.
• servers-File
Aus dieser Datei holt sich der Radiusclient den Namen oder IP-Adresse der Server,
mit denen er kommunizieren darf, und den dafür notwendigen Schlüssel.
#Server Name or Client/Server pair Key #------------------------------------------- localhost/localhost mimia
139.6.19.65 mimia
• dictionary-File
Folgende Schritte müssen hier gefolgt werden:
Die Datei „dictionary.ser“ aus :
http://www.iptel.org/ser/doc/ser_radius/ser_radius.html
downloaden und in /etc/radiusclient
speichern.
Inhalt der Datei „dictionary.ser“ an die Datei „dictionary“
anhängen:
Shell> cat dictionary.ser >> dictionary
b) Radiusserver Ähnlich wie bei Radiusclient wird auch die Radiusserverinstallation durchgeführt
Shell> tar -zxvf freeradius.tar.gz
Shell> cd freeradius-1.0.0
Shell> ./configure
Shell> make
Shell> make install
Bei unserer Konfiguration (Shell> ./configure ohne Parameter) werden alle
Konfigurationsdateien vom Radiusserver ins Verzeichnis: /usr/local/etc/raddb
hingelegt.
5. Entwicklungsumgebung
83
Hätte man ein anderes Verzeichnis für die Radiusserver-Dateien gewollt (z.B. /etc), dann
hätte man
Shell>./configure --sysconfdir=/etc
eingeben müssen.
Um die Grundfunktionalität sicherzustellen, müssen diese Einträge in die folgenden Dateien
erfasst werden.
• clients.conf-File
client 139.6.19.65 {
secret = mimia
shortname = localhost
}
Dadurch erfährt der Radiusserver, dass ein Radiusclient aus dem Host mit der
eingegeben IP-Adresse mit ihm kommunizieren darf. Dem Radiusclient gelingt dies
nur wenn er das eingetragene „secret“ (mimia) bei einer Authentifizierungs-
Request mitschickt.
• dictionary-File
Die SER-Bibliothek wird hierdurch dem Radiusserver bekannt gemacht
$INCLUDE /etc/radiusclient/dictionary.ser
• radiusd.conf-File
In Abschnitte „authorize“ und „authenticate“ den Eintrag „digest“
auskommentieren.
Der Radiusclient wird dadurch eine Digest-Authentifizierung zulassen.
• users-File
In dieser Datei werden die Benutzer eingetragen.
Zu Testzwecken wird der Benutzer „test“ mit dem Passwort „test“ erstellt.
Der Benutzer Test benutzt die Authentifizierungsmethode „Digest“ und nach einer
am Server erfolgreichen Authentifizierung bekommt er die Antwort, dafür folgender
Eintrag:
test Auth-Type := Digest, User-Password == "test"
Reply-Message = Authenticated, Mr TEST"
Ähnlich werden die im Labor zur Verfügung gestellten SIP-Telefone eingetragen.
[email protected] Auth-Type:=Digest,User-Password=="1234"
Reply-Message="Authenticated, Mr SNOM1"
5. Entwicklungsumgebung
84
[email protected] Auth-Type:=Digest,User-Password=="1234"
Reply-Message="Authenticated, Mr SNOM2"
5.3.4 Radius-Server starten und testen
Wir starten den Radiusserver, indem wir den Dämon „radiusd“ an der Konsole aufrufen
Shell> radiusd -X
Um den Server zu testen wird eine Datei „digest“ erstellt, deren Inhalt wie folgt aussieht:
User-Name = "test",
User-Password = "test"
Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7",
Digest-Realm = "testrealm",
Digest-Nonce = "1234abcd",
Digest-Method = "INVITE",
Digest-URI = "sip:[email protected]",
Digest-Algorithm = "MD5",
Digest-User-Name = "test"
Der „radclient”-Testtool wird benutzt, um eine „Authentication-Request“ (auth) mit dem
Inhalt aus dem File „digest” (-f digest) mit dem secret „mimia“ zum dem
Radiusserver am Host 139.6.19.65 zuzuschicken.
Shell> radclient -f digest 139.6.19.65 auth mimia
Falls der Server richtig funktioniert, dann bekommt der Client folgendes:
Received response ID 8, code 2, length = 61
Reply-Message = Authenticated, Mr TEST"
Somit ist der Radiusserver richtig installiert, konfiguriert und getestet.
5. Entwicklungsumgebung
85
5.4 SER und Freeradius
Bei der SER-Binärdistribution sind die Radius-notwendigen Module nicht vorhanden.
Man muss die SER-Quelldistributionsalternative nehmen, und die notwendigen Einstellungen
vor dem Kompilieren durchführen, um die SER-Radius-Interoperabilität sicherzustellen.
Die MySQL-Bibliethek- und Headerfiles werden auch benötigt, damit SER in der Lage ist,
Daten mit einer MySQL-Datenbank austauschen zu können.
Bei einer SuSe-Linux-Maschine (Version 9.1) begegnete ich ein unbehebbares Problem bei
der Radiusclient-Radiusserver-Kommunikation, dabei hatte das System den zuletzt erwähnten
Radius-Server-Test nicht bestanden. Alternativ griff ich auf Red-Hat-Linux zu (Version 3.1).
Dies war ein Rat von Herrn Jan Janak, einem der SER-Entwickler, um dem Problem
auszuweichen.
Die Installations- und Konfigurationsschritte bei der Red-Hat-Maschine wurden wie folgt
vorgenommen
• SER- und Freeradius-Packete downloaden und auspacken
Shell> tar -zxvf ser_0.8.12_src.tar.gz
(Datei-Download aus: ftp://ftp.berlios.de/pub/ser/0.8.12/src/)
Shell> tar -zxvf freeradius.tar.gz
(Datei-Download aus: www.freeradius.org)
• mysql-devel-packet installieren (bibliothek und Headerfiles)
Shell>rpm –ihv –nodeps –force
MySQL-devel-3.22.25-1.i386.rpm
• in /freeradius-1.0.0/src/modules/rlm_sql/drivers
/rlm_sql_mysql/Makefile
Den Eintrag:
RLM_SQL_CFLAGS = -I'/usr/include' $(INCLTDL)
ändern zu
RLM_SQL_CFLAGS = -I'/usr/include/mysql' $(INCLTDL)
• SER-0.8.12 erkennt die MySQL-Bibliothek unter den Namen libmysqlclient.so.10,
dafür in /usr/lib/mysql den Symbolischen Link erstellen
Shell> ln -s libmysqlclient.so.10 libmysqlclient.so
5. Entwicklungsumgebung
86
• 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
[mysqld] eingetragen werden: max_connections = 500
Zum Starten des MySQL-Servers:
Redhat: Shell> /usr/bin/safe_mysqld --user=root &
SuSe: Shell> /usr/bin/mysqld_safe --user=root &
5. Entwicklungsumgebung
88
6. Implementierung
6.1 Erweiterungsanforderungen
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“:
[email protected] Auth-Type := Digest,User-Password=="1234"
Framed-IP-Address = 139.6.19.58
Reply-Message = "Authenticated, Mr 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:
/freeradius-1.0.0/src/modules/rlm_detail/rlm_detail.c nötig:
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.
Message-BODY
v=0 o=root 0 0 IN IP4 139.6.19.49 s=call c=IN IP4 139.6.19.49 t=0 0 m=audio 32820 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 5434 RTP/AVP 97 a=rtpmap:97 H263/90000
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.
3c2675a6de14-rttgarwmf051@139-6-19-48 1109008763 64000 3c267ce1a8fb-ap7h2tplb3et@139-6-19-49 1109010616 8000
Nach Beenden der Verbindung kann das übertragene Volumen aus berechneter
Verbindungsdauer und aus der Start-Zeit-Datei abgelesener Bandbreite ermittelt werden.
Abbildung 51: Ermittlung des übertragenen Volumens
6.7 Instant Messaging
Instant Messaging (IM) ist ein Protokoll für die Echtzeit-Kommunikation von
Textnachrichten über das Internet zwischen Instant Messaging Systemen, das von der IEFT
standardisiert wurde und dem TCP oder das SIP-Protokoll zugrunde liegen. Bezog sich
Instant Messaging zuerst auf stationäre, PC-basierte Systeme, so wird dieser Dienst
zwischenzeitlich auch für Mobilfunknetze geboten: das mobile Instant Messaging.
Mittels Instant Messaging, adäquat einem Echtzeit-Chat, können E-Mails und Nachrichten,
aber auch Bilder, Audio- und Video-Files ausgetauscht werden. Der Nachrichtenaustausch ist
unmittelbar und verkürzt die Kommunikationsprozesse. [26]
6. Implementierung
97
Der SIP-Express-Router unterstützt das Instant Messaging, betrachtet es aber nicht als
Accounting-pflichtigen Dienst.
Bei der Erweiterung des SIP-Protokolls, wird der SIP-Server so implementiert, dass
Accounting-relevante IM-Daten in eine SIP-Server-Datenbank eingetragen werden (siehe
Quell-Code-Zeilen 654 bis 725)
Abbildung 52: Instant-Message-Accounting Accounting-relevante IM-Daten sind das Datum, die Sende-Uhrzeit, der Sender, der
Empfänger, die Call-ID, die Zeichenlänge der Instant Message und der User-Agent mit dem
die Message erstellt und versendet wurde.
Darunter steht ein Auszug aus dem Message-File.
INSTANT MESSAGE Mit Feb 2 18:21:35 CET 2005 From: <sip:[email protected]>;tag=4FE0978E To: <sip:[email protected]> Call-ID: [email protected] Content-Length: 17 User-Agent: KPhone/3.13
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]"
Sip-Translated-Req-ID = "sip:[email protected];transport=udp"
Acct-Session-Id = "[email protected]" Sip-To-Tag = "638D80A1" Sip-From-Tag = "1624369D" Sip-Cseq = "4478" NAS-IP-Address = 139.6.19.65 NAS-Port = 5060 Acct-Delay-Time = 0 Client-IP-Address = 139.6.19.65 Acct-Unique-Session-Id = "551487c889f2bd8b" # NEU # Anschluss-IP-Adresse = 139.6.19.51 Timestamp = 1105372649 Mon Jan 10 16:57:36 2005 Acct-Status-Type = Stop Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = 8 User-Name = "[email protected]" # NEU # Nomaden-IP-Adresse = 139.6.19.144 Calling-Station-Id = "sip:[email protected]" Called-Station-Id = "sip:[email protected]" Sip-Translated-Req-ID = "sip:[email protected]" Acct-Session-Id = "[email protected]" # NEU # Gespraechsdauer = 0 Std 0 Min 7 Sek ( = 7 Sek) # NEU # Uebertagenes Volumen = 1.81 MByte Sip-To-Tag = "1624369D" Sip-From-Tag = "638D80A1" Sip-Cseq = "7293" NAS-IP-Address = 139.6.19.65 NAS-Port = 5060 Acct-Delay-Time = 0 Client-IP-Address = 139.6.19.65 Acct-Unique-Session-Id = "ba5589a8f4a60683" Timestamp = 1105372656
Verzeichnisse
102
Abbildungs- und Tabellenverzeichnis
Abbildung 1: IP-Netz-PSTN-Migration..................................................................................... 2
Abbildung 2: PC-zu-PC-Verbindungen ..................................................................................... 6
Abbildung 3: PC-zu-Telefon-Verbindungen.............................................................................. 7
Abbildung 4: Telefon-zu-Telefon-Verbindungen ...................................................................... 8
Abbildung 5: IP-Telefonie-Netzaufbau.................................................................................... 10
Abbildung 6: Anrufbeispiel von PSTN nach IP....................................................................... 11
Abbildung 7: Anrufsignalisierung............................................................................................ 12
Abbildung 8: TCP und UDP im TCP/IP-Protokollstack.......................................................... 13
Abbildung 9: Type of Servise des IP-Headers des RFC 791 (IPv4) [16] ................................ 17
Abbildung 10: Delay und Jitter im paketbasierten Netzwerk [15]........................................... 18
Abbildung 11: Durch nicht abgestimmte Impedanzen erzeugtes Echo [16]............................ 19
Abbildung 12: Verschlechterung der Sprachqualität durch Paketverluste............................... 21
Abbildung 13: Sprach-Aktivitäts-Entdeckung [16] ................................................................. 22
Abbildung 14: Sprachkodierung für die Internetübtragung [27] ............................................. 23
Abbildung 15: Sampling und 8-Bit-Kodierung eines Analogsignals [15] ............................... 24
Abbildung 16: Signalverdeckung............................................................................................. 27
Abbildung 17: H.323-Komponenten........................................................................................ 31
Abbildung 18: H.323-Protokollhierarchie................................................................................ 31
Abbildung 19: Endeckung des zuständigen Gatekeeper (GK) [1] ........................................... 32
Abbildung 20: Ablauf: a) der Registrierung, b) der Deregistrierung [1] ................................. 33
Abbildung 21: Verlauf eines Location-Prozesses [1] .............................................................. 34
Abbildung 22: Funktionen Admission und Disengage [1]....................................................... 34
Abbildung 23: H.225.0-Anruf-SIG-Nachrichten in IP-Paketen [1] ......................................... 36
Abbildung 24: H.323-Verbindungsablauf [16] ........................................................................ 38
Abbildung 25: SIP-Protokollhierarchie.................................................................................... 39
Abbildung 26: User Agent ....................................................................................................... 40
Abbildung 27: Interaktion verschiedener SIP-Server .............................................................. 41
Abbildung 28: Aufbau einer SIP-Message............................................................................... 44
Abbildung 29: Beispiel einer SIP-Request (INVITE) mit SDP-Beschreibung........................ 47
Abbildung 30: Beispiel einer SIP-Response ............................................................................ 49
Abbildung 31: Ablauf einer SIP-Registrierung........................................................................ 51
Abbildung 32: SIP-Verbindungsablauf.................................................................................... 52
Verzeichnisse
103
Abbildung 33: AAA-Client, Server und Proxies ..................................................................... 57
Abbildung 34: AAA-Architektur ............................................................................................. 58
Abbildung 35: AAA-Architektur ohne und mit Broker ........................................................... 59
Abbildung 36: UDP und RADIUS-Paket................................................................................. 63
Abbildung 37: Struktur des RADIUS-Pakets........................................................................... 64
Abbildung 38: Attributenformat............................................................................................... 67
Abbildung 39: Authentifizierung durch Challenge/Response-Schema ................................... 68
Abbildung 40: RADIUS-Accounting [9] ................................................................................. 71
Abbildung 41: VoIP-Testnetz im Experimentiernetz der FH-Köln ......................................... 72
Abbildung 42: Screenshot der Internetseite www.iptel.org ..................................................... 74
Abbildung 43: Screenshot von SERWEB-Anmeldefenster ..................................................... 79
Abbildung 44: Screenshot von SERWEB-Userprofil .............................................................. 80
Abbildung 45: Screenshot von SERWEB-Send-IM ................................................................ 80
Abbildung 46: Nomaden-IP-Adresse (CHIP) .......................................................................... 90
Abbildung 47: Anschluss-IP-Adresse (PLIP) .......................................................................... 91
Abbildung 48: Verbindungsdauerermittlung ........................................................................... 92
Abbildung 49: Beispiel eines SIP-Message-Body ................................................................... 93
Abbildung 50: Type of Service-/Quality of Service-Accounting .......................................... 95
Abbildung 51: Ermittlung des übertragenen Volumens........................................................... 96
Abbildung 52: Instant-Message-Accounting ........................................................................... 97
Abbildung 53: Konferenz-Verbindungsaufbau........................................................................ 99
Tabelle 1: Typische Verzögerungszeiten durch klassische Netzwerkhardware ...................... 16
Tabelle 2: Vergleich von Qualität und Komplexität verschiedener ITU-Codecs .................... 29
Tabelle 3: SDP-Parameter [7] .................................................................................................. 48
Tabelle 4: SIP Status Codecs ................................................................................................... 50
Tabelle 5: Vergleich von H.323 und SIP ................................................................................. 55
Tabelle 6: RADIUS-Codes .......................................................................................................... 65
Tabelle 7: RADIUS-Authentifizierungspakettypen ................................................................. 66
Tabelle 8: RADIUS-Accounting-Pakettypen........................................................................... 70
Tabelle 9: Codecs-Tabelle der MySQL-Datenbank „sip_ser“ ................................................. 94
Verzeichnisse
104
Literaturverzeichnis [1] Anatol Badach; Voice over IP - Die Technik,
Hanser-Verlag, ISBN 3-446-22697-4
[2] Cisco Systems; Cisco Voice over IP, Volume 1, Version 4.1
[3] ComputerBase Online Lexikon; www.computerbase.de
[4] Erich Stein; Taschenbuch Rechnernetze und Internet, Fachbuchverlag Leipzig, 2. Auflage
[5] GEOVIPA, TECON Technologies AG Ausgabe vom 19.11.04, Version 0.0.3
[6] GNU Radius Reference Manual, version 1.2, Dezember 2003
[7] Handley, M., Jacobson V., SDP: Session Description Protocol, RFC 2327. 1998.
[8] Helmut Herold; UNIX-Systemprogrammierung Addison-Wesley, 1996, ISBN 3-89319-958-6
[9] HP-UX AAA Server A.06.00, Administration and Authentication Guide, HP-UX 11.0, 11i v1
[10] Internet Telephonie – VoIP, www.it-academy.cc
[11] IP-Telefonie, Sprachkodierung und Kompression; ; http://swyx.de
[12] Jens Junghänel; Workshop 20. April 1999, www.tu-chemnitz.de
[13] Jiri Kuthan, Jan Janak, Bogdan Iancu; iptel.org SIP Express Router v0.8.8 - Devloper's Guide, 2002 FhG Fokus
[14] Jiri Kuthan, Jan Janak, Yacine Rebahi; iptel.org SIP Express Router v0.11.0 - Admin's Guide, 2002 FhG Fokus
[15] Jochen Nölle; Voice over IP Grundlagen, Protokolle, Migration VDE – Verlag, 2. Aufl. 2005, ISBN 3800728508
[16] Jonathan Davidson, James Peters; Voice over IP Grundlagen Markt+Technik, 2002, ISBN 3-8272-5800-6
[17] Jonathan Hassel; RADIUS O’Reilly Media, Oktober 2002, First Edition, ISBN 0-596-00322-6
[18] M. Hein / M. Reisner / Dr. Antje Voß; Voice over IP Sprach-Daten-Konvergenz richtig nutzen Franzis’, 2002, ISBN 3-7723-6686-4
Verzeichnisse
105
[19] Mathias Hein; TCP/IP Internet-Protokolle im professionellen Einsatz International Thomson Publishing Company, 3.Auflage 1996 ISBN 3-8266-4000-4
[20] PC- und IT-Lexikon; Computer Zeitschriften GmbH, 2000, ISBN 3-7723-1874-6
[21] Peter Winkler; M+T Computerlexikon Markt + Technik, 2001, ISBN 3-8272-6176-7
[22] RADIUS for UNIX Adminstrator’s Guide, Lucent Technologies, Februar 1999
[23] Robert Sedgewick; Algorithmen in C Addison-Wesley, 1992, ISBN 3-8939-376-6
[24] Rolf-Dieter Köhler; Voice over IP, Mitp-Verlag/Bonn, 1.Auflage 2002, ISBN 3-8266-4067-5
[25] Rosenberg, et. al.; SIP: Session Initiation Protocol, RFC 2543. 1999.
[26] Simens Online Lexikon; http://networks.siemens.de
[27] Thomas Niepraschk; Voice over IP- ein Überblick zur Vorlesung " Konzepte interaktiver Medien" WS04/05
[28] Uwe Dettmar, Hilfsblätter zur Vorlesung Telekommumikationssysteme Teil A; Version 1.0, 13 September 2001
Verzeichnisse
106
Abkürzungenverzeichnis A
AAA Authentification, Autorisation, Accounting
ACELP Algebraic Code Excitation Linear Predictive Coding
ACF Admission ConFirm
ADPCM Adaptive Differential Puls Code Modulation
ARQ Admission ReQuest
ASN.1 Abstract Syntax Notation No. 1
AVP Attribute Value Pair
AVP Audio Video Profiles
B
Bps Bit pro Sekunde
C
CELP Code Excitation Linear Predictive Coding
CHAP Challenge Handschake Authentication Protocol
CRLF Carriage Return Line Feed
CS-CELP Conjugate Structure Code Excitation Linear Predictive Coding
CSMA/CD Carreir Sense Muliple Access with Collision Detection
D
DCF Disengage ConFirm
DNS Domain-Name-System
DPCM Differential Puls Code Modulation
DRQ Disengage ReQuest
DSP Digital Signal Processor
ETSI European Telecommunications Standards Institute
F
FIR Finite Impulse Response
G
GCF Gatekeeper ConFirmation
GEOVIPA geographische Verzonung von VoIP zur Authentifizierung der Verkehrsursprünge
GK GateKeeper
GRJ Gatekeeper ReJect
GRQ Gatekeeper ReQuest
Verzeichnisse
107
GSTN General Switched Telefone Network
GUI Graphical User Interface
H
HTML Hyper Text Markup Language
HTTP Hyper Text Transfer Protocol
I
IE Information Element
IEEE Institute of Electrical and Electonicss Engineers
IETF Internet Engineering Task Force
IM Instant Messaging
IOS Internetwork Operating System
IP Internet Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ITSP Internet Telephony Service Provider
ITU International Telecommunications Union
J
K
L
LAN Local Area Network
LD-CELP Low Delay Code Excitation Linear Predictive Coding
M
MD5 Message Digest Algorithm
MGCP Media Gateway Control Protocol
MIPS Million Instructions per Second
MOS Mean Opinion Score
MPMLQ Multiple Maximum Likelihood Quantization
MTU Maximum Transfer Unit
N
NAS Network Access Server
O
P
PAP Password authentication Protocol
PAP Password Authentication Protocol
Verzeichnisse
108
PBX Private Branch eXchange
PCM Pulse Code Modulation
PDA Personal Digital Assistent
PLC Packet Loss Concealment
PLMN Public Land Mobile Network
POTS Plain Old Telephone Service
PPP Point to Point Protocol
PSTN Public Switched Telephne Network
Q
QoS Quality of Service
R
RADIUS Remote Authentication Dial-In User Service
RAS Ragistration, Admission, Status
RAS Remote Access Server
RCF Registration ConFirm
RFC Request for Comments
RRJ Registration ReJect
RRQ Registration ReQuest
RTCP Real Time Control Protocol
RTP Real Time Transfer Protocol
S
SCN Switched Circuit Network
SCTP Stream Control Transmission Protokoll
SDP Session Description Protocol
SGCP Simple Gateway Control Protocol
SIP Session Initiation Protocol
SQL Structured Query Language
T
TACACS Terminal Access Controller Access Control System
TCP Transmission Control Protocol
TELR Talker Echo Loudness Rating
TIPHON Telecommunications and Internet Protocol Harmonization Over Networks
TPDU Trasport Protocol Data Unit
TPKT Transport PacKeT
Verzeichnisse
109
U
UAC User Agent Client
UAS User Agent Server
UCF Unregistration ConFirm
URJ Unregistration ReJect
URL Uniform Resource Locator
URQ Unregistration ReQuest
UUIEs User-to-User Information Elements
V
VAD Voice-Activity-Detection
VoIP Voice over Internet Protocol
W
X
Y
Z
Anhänge
110
Anhang 1: SIP Status Code Tabelle nach [25]
Anhänge
111
Anhang 2: Dictionary File # # Updated 97/06/13 to livingston-radius-2.01 [email protected] # # This file contains dictionary translations for parsing # requests and generating responses. All transactions are # composed of Attribute/Value Pairs. The value of each attribute # is specified as one of 4 data types. Valid data types are: # # string - 0-253 octets # ipaddr - 4 octets in network byte order # integer - 32 bit value in big endian order (high byte first) # date - 32 bit value in big endian order - seconds since # 00:00:00 GMT, Jan. 1, 1970 # # Enumerated values are stored in the user file with dictionary # VALUE translations for easy administration. # # Example: # # ATTRIBUTE VALUE # --------------- ----- # Framed-Protocol = PPP # 7 = 1 (integer encoding) # # Following are the proper new names. Use these. # ATTRIBUTE User-Name 1 string ATTRIBUTE Password 2 string ATTRIBUTE CHAP-Password 3 string ATTRIBUTE NAS-IP-Address 4 ipaddr ATTRIBUTE NAS-Port-Id 5 integer ATTRIBUTE Service-Type 6 integer ATTRIBUTE Framed-Protocol 7 integer ATTRIBUTE Framed-IP-Address 8 ipaddr ATTRIBUTE Framed-IP-Netmask 9 ipaddr ATTRIBUTE Framed-Routing 10 integer ATTRIBUTE Filter-Id 11 string ATTRIBUTE Framed-MTU 12 integer ATTRIBUTE Framed-Compression 13 integer ATTRIBUTE Login-IP-Host 14 ipaddr ATTRIBUTE Login-Service 15 integer ATTRIBUTE Login-TCP-Port 16 integer ATTRIBUTE Reply-Message 18 string ATTRIBUTE Callback-Number 19 string ATTRIBUTE Callback-Id 20 string ATTRIBUTE Framed-Route 22 string ATTRIBUTE Framed-IPX-Network 23 ipaddr ATTRIBUTE State 24 string ATTRIBUTE Session-Timeout 27 integer
Anhänge
112
ATTRIBUTE Idle-Timeout 28 integer ATTRIBUTE Termination-Action 29 integer ATTRIBUTE Called-Station-Id 30 string ATTRIBUTE Calling-Station-Id 31 string ATTRIBUTE Acct-Status-Type 40 integer ATTRIBUTE Acct-Delay-Time 41 integer ATTRIBUTE Acct-Input-Octets 42 integer ATTRIBUTE Acct-Output-Octets 43 integer ATTRIBUTE Acct-Session-Id 44 string ATTRIBUTE Acct-Authentic 45 integer ATTRIBUTE Acct-Session-Time 46 integer ATTRIBUTE Acct-Terminate-Cause 49 integer ATTRIBUTE NAS-Port-Type 61 integer ATTRIBUTE Port-Limit 62 integer ATTRIBUTE Connect-Info 77 string # # Experimental Non Protocol Attributes used by Cistron-Radiusd # ATTRIBUTE Huntgroup-Name 221 string ATTRIBUTE User-Category 1029 string ATTRIBUTE Group-Name 1030 string ATTRIBUTE Simultaneous-Use 1034 integer ATTRIBUTE Strip-User-Name 1035 integer ATTRIBUTE Fall-Through 1036 integer ATTRIBUTE Add-Port-To-IP-Address 1037 integer ATTRIBUTE Exec-Program 1038 string ATTRIBUTE Exec-Program-Wait 1039 string ATTRIBUTE Hint 1040 string # # Non-Protocol Attributes # These attributes are used internally by the server # ATTRIBUTE Expiration 21 date ATTRIBUTE Auth-Type 1000 integer ATTRIBUTE Menu 1001 string ATTRIBUTE Termination-Menu 1002 string ATTRIBUTE Prefix 1003 string ATTRIBUTE Suffix 1004 string ATTRIBUTE Group 1005 string ATTRIBUTE Crypt-Password 1006 string ATTRIBUTE Connect-Rate 1007 integer # # Integer Translations #
Anhänge
113
# 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
Anhänge
116
ATTRIBUTE Sip-Uri-User 208 string # Proprietary ATTRIBUTE Sip-Rpid 213 string # Proprietary ATTRIBUTE Digest-Realm 1063 string # Sterman ATTRIBUTE Digest-Nonce 1064 string # Sterman ATTRIBUTE Digest-Method 1065 string # Sterman ATTRIBUTE Digest-Uri 1066 string # Sterman ATTRIBUTE Digest-Qop 1067 string # Sterman ATTRIBUTE Digest-Algorithm 1068 string # Sterman ATTRIBUTE Digest-Body-Digest 1069 string # Sterman ATTRIBUTE Digest-Cnonce 1070 string # Sterman ATTRIBUTE Digest-Nonce-Count 1071 string # Sterman ATTRIBUTE Digest-User-Name 1072 string # Sterman ### group_radius ### VALUE Service-Type Group-Check 12 # Proprietary ATTRIBUTE Sip-Group 211 string # Proprietary ### uri_radius ### # Call-Check service type is already define in auth_radius
Anhänge
117
Anhang 3: RADIUS-Attribut-Typen The type field is a single octet which is one of the following:
Type Description Attribute Length 1 User-Name =3 2 User-Password =18 3 CHAP-Password =19 4 NAS-IP-Address 6 5 NAS-Port 6 6 Service-Type 6 7 Framed-Protocol 6 8 Framed-IP-Address 6 9 Framed-IP-Netmask 6 10 Framed-Routing 6 11 Filter-Id =3 12 Framed-MTU 6 13 Framed-Compression 6 14 Login-IP-Host 6 15 Login-Service 6 16 Login-Port 6 17 (unassigned) N/A 18 Reply-Message =3 19 Login-Callback-Number =3 20 Framed-Callback-Id =3 21 (unassigned) N/A 22 Framed-Route =3 23 Framed-IPX-Network 6 24 State =3 25 Class =3 26 Vendor-Specific =7 27 Session-Timeout 6 28 Idle-Timeout 6 29 Termination-Action 6 30 Client-Port-DNIS =3 31 Caller-ID =3 32 NAS-Identifier =3 33 Proxy-State =3 34 Login-LAT-Service =3 35 Login-LAT-Node =3 36 Login-LAT-Group 34 37 Framed-AppleTalk-Link 6
Anhänge
118
38 Framed-AppleTalk-Network 6 39 Framed-AppleTalk-Zone =3 40 Acct-Status-Type 6 41 Acct-Delay-Time 6 42 Acct-Input-Octets 6 43 Acct-Output-Octets 6 44 Acct-Session-Id =3 45 Acct-Authentic 6 46 Acct-Session-Time 6 47 Acct-Input-Packets 6 48 Acct-Output-Packets 6 49 (reserved for future accounting) N/A 192 - 223 (reserved for experimental use) N/A 224 - 240 (reserved for implemention-specific use) N/A 241 - 255 (reserved: DO NOT USE) N/A
Anhänge
119
Anhang 4: Quell-Code-Änderungen //--------------------------------------------------------------------------------------------------------------- 1 //############################ RADIUS-Server ############################## 2 //--------------------------------------------------------------------------------------------------------------- 3 4 //* In Datei /freeradius-1.0.0/src/include/libradius.h 5 6 //Neue Struktur definieren: 7 8 typedef struct daten { 9 10 char acctdir[50]; 11 char abr_ip[20]; 12 int start_zeit, stop_zeit, verbindungsdauer; 13 14 }DATEN; 15 16 DATEN faik; 17 18 //A) REGISTRIERUNG: 19 20 //* In Datei /freeradius-1.0.0/src/modules/rlm_detail/rlm_detail.c 21 22 //Accountdirectory in faik.acctdir koppieren: 23 24 strcpy(faik.acctdir, buffer); 25 char bbr[14]; 26 if (strcmp(pair->name, "Framed-AppleTalk-Zone") == 0){ 27
if ((pair->strvalue[0] == 'b')&&(pair->strvalue[1] == 'b')){ 28 for(m=0; m<13; m++) 29 bbr[m]=pair->strvalue[m+2]; //Bandbreite in bbr kopieren 30 } 31 else{ 32 //Attr. wird im SIP-Server (sterman.c und acc.c) erstellt (für Anschluss-Ip-Adresse) 33 fputs("# NEU # ", outfp); 34 fprintf(outfp,"%s", pair->strvalue); 35 fputs("\n", outfp); 36 } 37 else { if (pair->attribute == PW_FRAMED_IP_ADDRESS){ 38 //Attr. wird in acct.c erstellt 39 fputs("# NEU # ",outfp); //Attr. 40 fprintf(outfp,"Nomaden-IP-Adresse (CHIP) = %s", pair->strvalue); 41 42 fputs("\t\n", outfp); 43 } 44 else{ 45 fputs("\t", outfp); // 46 vp_print(outfp, pair); // 3 Ursprüngliche Zeilen 47 fputs("\n", outfp); // 48
Anhänge
120
} 49 } 50 51 52 //* In Datei /freeradius-1.0.0/src/lib/radius.c 53 //Nach: 54 debug_pair(reply); 55 56 char *a; 57 FILE *myfile; 58 59 myfile = fopen(faik.acctdir, "a"); 60 //myfile = fopen("/usr/local/var/log/radius/radacct/139.6.19.65/auth-detail-20041103", "a"); 61 if(strcmp(reply->name, "Framed-IP-Address") == 0){ 62 fprintf(myfile, "# Neu #"); 63 64 //aus print.c 65 //Framed-IP-Address ablesen und in auth-detail-20041103 schreiben 66 67 if (reply->strvalue[0]) 68 a = (char *)reply->strvalue; 69 else 70 a = ip_hostname((char *)reply->strvalue, 71 sizeof(reply->strvalue), 72 reply->lvalue); 73 fprintf(myfile, "Nomaden-IP-Adresse (CHIP) = %s\n\n", a); 74 75 } 76 fclose(myfile); 77 78 79 //B) ACCOUNTING: 80 81 //* In Datei /freeradius-1.0.0/src/modules/rlm_files/rlm_files.c 82 83 //IP-Adresse des UAs in faik.abr_ip koppieren 84 strcpy(faik.abr_ip, pl->reply->strvalue); 85 86 //* In Datei /freeradius-1.0.0/src/main/acct.c 87 88 VALUE_PAIR *my_vp; 89 90 my_vp = paircreate(PW_FRAMED_IP_ADDRESS, PW_TYPE_STRING); 91 strcpy(my_vp->strvalue, faik.abr_ip); 92 pairadd(&request->packet->vps, my_vp); 93 94 * In Datei /freeradius-1.0.0/src/modules/rlm_detail/rlm_detail.c 95 96 // start-time Datei anlegen (mit aktuellem Datum) in Variable se 97 int ifstart = 0, ifstop = 0; 98 FILE *time_file; 99
Anhänge
121
int stunden=0, minuten=0, sekunden=0; 100 struct tm *TM, s_TM; 101 char tmpdt[10]="Null"; /* For temporary storing of dates */ 102 char tmpdt_gestern[10]="Null"; 103 int gestern_zeit; 104 int x,ad,m; 105 char sd[100]="Null", se[100]="Null", se_gestern[100]="Null"; 106 107 ad= strlen(faik.acctdir); 108 strcpy(sd, faik.acctdir); 109 110 for(x=0; x<(ad-15); x++){ 111 se[x] = sd[x]; 112 se_gestern[x] = sd[x]; 113 } 114 115 TM = localtime_r(&request->timestamp, &s_TM); 116 strftime(tmpdt,sizeof(tmpdt),"%Y%m%d",TM); 117 118 gestern_zeit=request->timestamp; 119 gestern_zeit=gestern_zeit-86400; //=24std*3600s in der start-time datei von gestern 120 zu suchen 121 // (Mittenachtproblem) 122 TM = localtime_r(&(gestern_zeit), &s_TM); 123 strftime(tmpdt_gestern,sizeof(tmpdt_gestern),"%Y%m%d",TM); 124 125 strcat(se, "start-time-"); 126 strcat(se, tmpdt); 127 128 strcat(se_gestern, "start-time-"); 129 strcat(se_gestern, tmpdt_gestern); 130 131 //Speichern der Verbindungs-Startzeiten 132 133 if (strcmp(pair->strvalue, "Start") == 0) ifstart = 1; 134 if (strcmp(pair->strvalue, "Stop") == 0) ifstop = 1; 135 136 if ((strcmp(pair->name, "Acct-Session-Id") == 0) && ifstart == 1){ // Für 137 Verbindungsstart 138 139 //time_file = fopen("/usr/local/var/log/radius/radacct/139.6.19.65/start-time-140 20041203", "a"); 141 time_file = fopen(se, "a"); 142 143 fprintf(time_file, "%s\n",pair->strvalue); 144 for(m=0; m<(37-strlen(pair->strvalue)); m++){ // Wenn A-S-Id kurz ist < 37 145 fprintf(time_file, " "); 146 } 147 fprintf(time_file, "\n%ld \n", request->timestamp); 148 // 27 Leerzeichen gilt bis timestamp 149 // 11-Stellig wird, dann 26 Leerzeichen 150
Anhänge
122
fprintf(time_file, "%s",bbr); //Bandbreite 151 for(m=0; m<(37-strlen(bbr)); m++){ // Wenn bbr kurz ist < 37 152 fprintf(time_file, " "); 153 } 154 fprintf(time_file, "\n"); 155 156 ifstart = 0; 157 fclose(time_file); 158 } 159 //Ablesen der start-time-Datei 160 161 if ((strcmp(pair->name, "Acct-Session-Id") == 0) && ifstop == 1){ 162 163 int lrecl=38,hi,gef=0,suche=0; 164 long length; 165 int startzeit, stopzeit, dauer; 166 char b[40]="nul", c[40]="nul", r[40]="nul", y[40]="nul"; 167 double bandbreite, bandw; 168 169 //time_file = fopen("/usr/local/var/log/radius/radacct/139.6.19.65/start-time-170 20041203", "r"); 171 while((suche<2))&&(gef==0){ //in der star-time-dateien von heute und gestern 172 suchen 173 174 if (suche == 0) time_file = fopen(se, "r"); 175 if (suche == 1) time_file = fopen(se_gestern, "r"); 176 177 strcpy(b, pair->strvalue); 178 179 fseek(time_file, 0L, SEEK_END); 180 length = ftell(time_file); //fseek und ftell zur Bestimmung der Laenge der Datei 181 182 hi= length/lrecl; //Anzahl der Datensaetze ind der Datei 183 184 //sequenziele Suche 185 for(m=0; m<=hi; m++){ 186 fseek(time_file, m*lrecl, SEEK_SET); 187 printf("%d * lrecl = %d\n", m, m*lrecl); 188 fscanf(time_file, "%s", c); 189 if (strcmp(b,c) == 0){ 190 gef=1; 191 fseek(time_file, (m+1)*lrecl, SEEK_SET); 192 fscanf(time_file, "%s", r); 193 //fscanf(time_file, "%d", &d); 194 printf("\n#### Der dazugehoerige Timestamp = %s\n", r); 195 break; 196 } 197 } 198 sscanf(r, "%d", &startzeit); 199 sscanf(y, "%lf", &bandw); //Konvertierung string -> integer 200 stopzeit = request->timestamp; 201
Anhänge
123
dauer = stopzeit - startzeit; 202 suche++; 203 } 204 205 stunden = dauer/3600; 206 minuten = (dauer%3600)/60; 207 sekunden = (dauer%3600)%60; 208 209 if (gef != 1){ 210 fputs("# NEU # ",outfp); 211 fprintf(outfp,"Gespraechsdauer = nicht berechenbar, weil Startzeit nicht gefunden 212 wurde\n"); 213
} 214 else{ 215 fputs("# NEU # ",outfp); 216 fprintf(outfp,"Gespraechsdauer = %d Std %d Min %d Sek ( = %d Sek)\n", stunden, 217 minuten ,sekunden,dauer); 218 219
fputs("# NEU # ",outfp); 220 221 bandbreite= bandw * dauer / 8 ; //Volumen in Byte 222
//bandbreite= bandbreite / 1000; // in KByte 223 //if (bandbreite<1000) fprintf(outfp,"Uebertagenes Volumen = %.2lf KByte\n",bandbreite); 224 //else fprintf(outfp,"Uebertagenes Volumen = %.2lf MByte\n",bandbreite/1000); 225 226 fprintf(outfp,"Uebertagenes Volumen = %.2lf Byte\n",bandbreite); 227 } 228 229 ifstop = 0; 230 fclose(time_file); 231 } 232 233 234 //--------------------------------------------------------------------------------------------------------------- 235 //############################# SER-Server ############################### 236 //--------------------------------------------------------------------------------------------------------------- 237 238 //* Datei erstellen /ser-0.8.12/extern_variables.h mit Inhalt 239 240 char anschluss_auth[50]; 241 char anschluss_acc[50]; 242 char sip_methode[4]; 243 char used_audio_codec[20]; 244 char used_video_codec[20]; 245 int neu_message_id ; 246 int alt_message_id ; 247 248 //A) Registrierung: 249 250 //* In Datei /ser-0.8.12/msg_translator.c 251 #include "extern_variables.h" 252
Anhänge
124
int ns = strlen(name->s), zeichen, buchstabe, y; 253 char mfl[ns+1]; 254 char sip_methode[4]="nul"; 255 256 strcpy(mfl, name->s); 257 258 for(zeichen = 0; zeichen <= ns; zeichen++){ 259 //printf("%c",mfl[zeichen]); 260 261 if ((mfl[zeichen] == 'C') && (mfl[zeichen+1] == 'S') && 262 (mfl[zeichen+2] == 'e') && (mfl[zeichen+3] == 'q') && 263 (mfl[zeichen+4] == ':') && (mfl[zeichen+5] == ' ') ){ // "CSeq: " ? 264 265 for(buchstabe=0; buchstabe <= 10; buchstabe++){ 266 if (mfl[buchstabe+zeichen+6] == ' '){ 267 for(y=0 ; y<3 ; y++){ 268 sip_methode[y]=mfl[buchstabe+zeichen+y+7]; //SIP-Methode 269 } 270 } 271 } 272 } 273 } 274 // Anschluss-Ip-Adresse in Variable anschluss kopieren 275 if(strcmp(sip_methode, "REG") == 0){ 276 strcpy(anschluss_auth,s); 277 } 278 if((strcmp(sip_methode, "INV") == 0)){ 279 strcpy(anschluss_acc,s); 280 } 281 282 //* In Datei /ser-0.8.12/modules/auth_radius/sterman.c 283 284 #include "/ser-0.8.12/extern_variables.h" 285 286 char anschluss2[70]="Null"; 287 strcpy(anschluss2,""); 288 strcat(anschluss2, "Anschluss-IP-Adresse (PLIP) ="); 289 strcat(anschluss2, anschluss_auth); 290 291 //Paket send wird um ein Valuepair erweitern, das die Anschluss-Ip-Adresse enthält 292 if (!rc_avpair_add(&send,PW_DIGEST_REALM , &anschluss2, 0)) { 293 LOG(L_ERR, "sterman(): Unable to add PW_DIGEST_REALM attribute\n"); 294 rc_avpair_free(send); 295 return -20; 296 } 297 298 //Das Attribut wird als Framed-AppleTalk-Zone 299 //erstellt und zu Radius geschickt. 300 //Deshalb in rlm_detail die Änderung: (siehe oben). 301 302 //B) Accounting: 303
Anhänge
125
304 //* In Datei /ser-0.8.12/modules/acc/acc.c 305 // Auf message zugreifen und daraus gesuchte Daten (Type of Service) ablesen 306 307 int zeichen, buchstabe, zaehler=0, y, n=0, p=1, m1=0, m2=0, if_INVITE=0 ; 308 int msg_length = strlen(rq->first_line.u.request.method.s); 309 char mfl[msg_length+1]; //messege first line 310 311 char media_type[20]="Null", media_type1[20]="Null", media_type2[20]="Null"; 312 char med_codecs[300]="Null", med_codecs1[300]="Null", 313 med_codecs2[300]="Null"; 314 char codec[80]="Null"; 315 char codecs[200]="Null", codecs1[200]="Null", codecs2[200]="Null"; 316 317 strcpy(mfl, rq->first_line.u.request.method.s); 318 strncpy(sip_methode,mfl, 3); 319 320 if(strcmp(sip_methode, "INV") == 0) { 321 if_INVITE=1; 322 323 for(zeichen = 0; zeichen <= msg_length; zeichen++){ 324 //printf("%c",mfl[zeichen]); 325 if ((mfl[zeichen] == 'm') && (mfl[zeichen+1] == '=')){ 326 zaehler++; 327 if(zaehler==1) m1 = zeichen; 328 if(zaehler==2) m2 = zeichen; 329 for(buchstabe = 0; buchstabe <= 5; buchstabe++){ 330 media_type[buchstabe] = mfl[buchstabe+zeichen+2]; 331 332 if(media_type[buchstabe] == ' '){ 333 if (zaehler==1) strcpy(media_type1, media_type); 334 if (zaehler==2) strcpy(media_type2, media_type); 335 //printf("\n######### acc.c Z.583 #### media_type= %s\n", 336 media_type); 337 //break; 338 } 339 } 340 } 341 } 342 343 buchstabe = y = 0; 344 strcpy(codecs, ""); 345 strcpy(codecs1, ""); 346 strcpy(codecs2, ""); 347 348 FILE *c_file; 349 char kommando[30]="/root/DB/test2/datenbank "; 350 351 char bandbreite[10]="Null"; 352 353 for(zeichen = 0; zeichen <= msg_length; zeichen++){ 354
Anhänge
126
//printf("%c",mfl[zeichen]); 355 356 if ((mfl[zeichen] == 'a') && (mfl[zeichen+1] == '=') && 357 (mfl[zeichen+2] == 'r') && (mfl[zeichen+3] == 't') && 358 (mfl[zeichen+4] == 'p') && (mfl[zeichen+5] == 'm') ){ // a=rtpm ?359 360 361 if (m2 != 0){ 362 if ((m1<zeichen) && (zeichen<m2)){ 363 364 for(buchstabe=0; buchstabe <= 20; buchstabe++){ 365 if (mfl[buchstabe+zeichen] == ' '){ 366 for(y=0,p=n ; y<20 ; y++,p++){ 367 if(mfl[buchstabe+zeichen+y+1] == '/'){ 368 n=n+y+1; 369 //codecs1[p]='/'; 370 break; 371 } 372 codec[y]=mfl[buchstabe+zeichen+y+1]; 373 374 } 375 376 strcpy(kommando,"/root/DB/test2/datenbank "); 377 strcat(kommando, codec); 378 system(kommando); 379 380 c_file = fopen("/root/DB/test2/cfile", "r"); 381 fseek(c_file, 0L, SEEK_SET); 382 fscanf(c_file, "%[^\n]", bandbreite); 383 384 fclose(c_file); 385 386 strcat(codecs1, codec); 387 strcat(codecs1, "("); 388 strcat(codecs1, bandbreite); 389 strcat(codecs1, ")"); 390 strcat(codecs1, "/"); 391 392 printf(" / Codec:%s,Bandbreite: %s\n", codec, bandbreite); 393 break; 394 } 395 } 396 n=0; 397 } 398 if ((zeichen)>m2){ 399 400 for(buchstabe=0; buchstabe <= 20; buchstabe++){ 401 if (mfl[buchstabe+zeichen] == ' '){ 402 for(y=0,p=n ; y<20 ; y++,p++){ 403 if(mfl[buchstabe+zeichen+y+1] == '/'){ 404 n=n+y+1; 405
Anhänge
127
//codecs2[p]='/'; 406 break; 407 } 408 codec[y]=mfl[buchstabe+zeichen+y+1]; 409 } 410 411 strcpy(kommando,"/root/DB/test2/datenbank "); 412 strcat(kommando, codec); 413 system(kommando); 414 415 c_file = fopen("/root/DB/test2/cfile", "r"); 416 fseek(c_file, 0L, SEEK_SET); 417 fscanf(c_file, "%[^\n]", bandbreite); 418 fclose(c_file); 419 420 strcat(codecs2, codec); 421 strcat(codecs2, "("); 422 strcat(codecs2, bandbreite); 423 strcat(codecs2, ")"); 424 strcat(codecs2, "/"); 425 426 printf(" / Codec:%s,Bandbreite: %s\n", codec, bandbreite); 427 break; 428 } 429 } 430 } 431 } 432 else { 433 434 for(buchstabe=0; buchstabe <= 20; buchstabe++){ 435 if (mfl[buchstabe+zeichen] == ' '){ 436 for(y=0,p=n ; y<20 ; y++,p++){ 437 if(mfl[buchstabe+zeichen+y+1] == '/'){ 438 n=n+y+1; 439 //codecs[p]='/'; 440 break; 441 } 442 codec[y]=mfl[buchstabe+zeichen+y+1]; 443 } 444 445 strcpy(kommando,"/root/DB/test2/datenbank "); 446 strcat(kommando, codec); 447 system(kommando); 448 449 c_file = fopen("/root/DB/test2/cfile", "r"); 450 fseek(c_file, 0L, SEEK_SET); 451 fscanf(c_file, "%[^\n]", bandbreite); 452 453 fclose(c_file); 454 455 strcat(codecs, codec); 456
Anhänge
128
strcat(codecs, "("); 457 strcat(codecs, bandbreite); 458 strcat(codecs, ")"); 459 strcat(codecs, "/"); 460 461 printf(" Codecs: %s", codecs); 462 printf(" / Codec:%s,Bandbreite: %s\n", codec, bandbreite); 463 break; 464 } 465 } 466 } 467 } 468 } 469 if (zaehler==1){ 470 //strcpy(med_codecs, "Type of Service // Quality of Service = "); 471 strcpy(med_codecs, " "); 472 strcat(med_codecs, media_type1); 473 strcat(med_codecs, " // Codecs(Bandbr.): "); 474 strcat(med_codecs, codecs); 475 } 476 477 if (zaehler==2){ 478 strcpy(med_codecs1, " "); 479 strcat(med_codecs1, media_type1); 480 strcat(med_codecs1, " // Codecs(Bandbr.): "); 481 strcat(med_codecs1, codecs1); 482 483 strcpy(med_codecs2, " "); 484 strcat(med_codecs2, media_type2); 485 strcat(med_codecs2, " // Codecs(Bandbr.): "); 486 strcat(med_codecs2, codecs2); 487 488 } 489 490 } //alles in "INVITE"? 491 492 . 493 . 494 . 495 496 //#define PW_ANSCHLUSS_IP_ADDRESS 224 497 #define PW_DIGEST_REALM 1063 /* string */ 498 #define PW_DIGEST_URI 1066 /* string */ 499 #define PW_DIGEST_METHOD 1065 /* string */ 500 501 char anschlussIP[20]="null"; 502 char tos_qos[50]="Type of Service // Quality of Service"; 503 char tos1_qos[50]="Type of Service (1) // Quality of Service"; 504 char tos2_qos[50]="Type of Service (2) // Quality of Service"; 505 strcpy(anschlussIP, ""); 506 strcat(anschlussIP, "Anschluss-IP-Adresse = "); 507
Anhänge
129
strcat(anschlussIP, anschluss_auth); 508 509 if (if_INVITE==1){ 510 511 if_INVITE=0; 512 513 if (zaehler==1){ //Ein Medientyp 514 rc_avpair_add(&send, PW_DIGEST_REALM, &anschlussIP, 0); 515 rc_avpair_add(&send, PW_DIGEST_REALM, &tos_qos, 0); 516 rc_avpair_add(&send, PW_DIGEST_REALM, &med_codecs, 0); 517 } 518 519 if (zaehler==2){ //Zwei Medientypen 520 rc_avpair_add(&send, PW_DIGEST_REALM, &anschlussIP, 0); 521 rc_avpair_add(&send, PW_DIGEST_REALM, &tos1_qos, 0); 522 rc_avpair_add(&send, PW_DIGEST_REALM, &med_codecs1, 0); 523 rc_avpair_add(&send, PW_DIGEST_REALM, &tos2_qos, 0); 524 rc_avpair_add(&send, PW_DIGEST_REALM, &med_codecs2, 0); 525 } 526 } 527 528 else{ 529 rc_avpair_add(&send, PW_DIGEST_REALM, &anschlussIP, 0); 530 } 531 532 //PW_SIP_SOURCE_IP_ADDRESS 533 534 //* Die Datei /root/DB/test2/datenbank.c 535 536 #include <mysql/mysql.h> 537 #include <stdio.h> 538 #include <string.h> 539 540 char query[100],codec[10]; 541 int t,r; 542 543 void to_file(char codec[10]){ 544 FILE *c_file; 545 546 c_file = fopen("/root/DB/test2/cfile", "w"); 547 fprintf(c_file, "%s",codec); 548 549 fclose(c_file); 550 } 551 552 main(int argc, char **argv){ 553 void to_file(); 554 MYSQL *my; 555 MYSQL_RES *res; 556 MYSQL_ROW row; 557 mysql_init(my); 558
Anhänge
130
if (!mysql_real_connect(my,"localhost","root", 559 "","sip_ser",0,NULL,0)) 560 { 561 printf( "Error connectin ot database: %s\n",mysql_error(my)); 562 } 563 //else printf("Connected...\n"); 564 565 strcpy(query,"select bandbreite from codecs where codecs='"); 566 strcpy(codec,argv[1]); 567 strcat(query,codec); 568 strcat(query,"'"); 569 570 t=mysql_real_query(my,query,(unsigned int) strlen(query)); 571 if (t) 572 { 573 printf("Error making query: %s\n", 574 mysql_error(my)); 575 } 576 else printf("Query made...\n"); 577 578 res=mysql_use_result(my); 579 for(r=0;r<=mysql_field_count(my);r++){ 580 row=mysql_fetch_row(res); 581 if(row<0) break; 582 for(t=0;t<mysql_num_fields(res);t++){ 583 //printf("%s ",row[t]); 584 to_file(row[t]); 585 } 586 printf("\n"); 587 } 588 mysql_close(my); 589 590 return 0; 591 592 593 //* Die Datei /root/DB/test2/datenbank_bb.c 594 595 #include <mysql/mysql.h> 596 #include <stdio.h> 597 #include <string.h> 598 599 char query[100],codec[10]; 600 int t,r; 601 602 void to_file(char codec[10]){ 603 FILE *c_file; 604 605 c_file = fopen("/root/DB/test2/cfile", "w"); 606 fprintf(c_file, "%s",codec); 607 608 fclose(c_file); 609
Anhänge
131
} 610 611 main(int argc, char **argv){ 612 void to_file(); 613 MYSQL *my; 614 MYSQL_RES *res; 615 MYSQL_ROW row; 616 mysql_init(my); 617 if (!mysql_real_connect(my,"localhost","root", 618 "","sip_ser",0,NULL,0)) 619 { 620 printf( "Error connectin ot database: %s\n",mysql_error(my)); 621 } 622 else printf("Connected...\n"); 623 624 strcpy(query,"select bb from codecs where codecs='"); 625 strcpy(codec,argv[1]); 626 strcat(query,codec); 627 strcat(query,"'"); 628 629 t=mysql_real_query(my,query,(unsigned int) strlen(query)); 630 if (t) 631 { 632 printf("Error making query: %s\n", 633 mysql_error(my)); 634 } 635 else printf("Query made...\n"); 636 637 res=mysql_use_result(my); 638 for(r=0;r<=mysql_field_count(my);r++){ 639 row=mysql_fetch_row(res); 640 if(row<0) break; 641 for(t=0;t<mysql_num_fields(res);t++){ 642 //printf("%s ",row[t]); 643 to_file(row[t]); 644 } 645 printf("\n"); 646 } 647 648 mysql_close(my); 649 650 return 0; 651 } 652 653 * Die Datei /ser-0.8.12/main.c 654 655 #include "/ser-0.8.12/extern_variables.h" 656 //Wichtig für SMS 657 658 neu_message_id = alt_message_id = 0; 659 660
Anhänge
132
661 * Die Datei /ser-0.8.12/parser/msg_parser.c 662 663 #include "/ser-0.8.12/extern_variables.h" 664 665 // Instant Message 666 // Message-Daten in die Datei einemessage schreiben 667 668 int msg_length = strlen(msg->first_line.u.request.method.s); 669 char mfl[msg_length]; //message first line 670 char sip_methode[4]="nl"; 671 672 FILE *m_file; 673 FILE *m_file2; 674 FILE *m_file3; 675 FILE *leerzeile; 676 677 strcpy(mfl, msg->first_line.u.request.method.s); 678 679 strncpy(sip_methode, mfl, 3); 680 if(strcmp(sip_methode, "MES") == 0) { //MESSAGE 681 682 neu_message_id = msg->id; 683 684 if (neu_message_id != alt_message_id){ 685 686 m_file = fopen("/ser-0.8.12/parser/einemessage", "w"); 687 m_file2 = fopen("/ser-0.8.12/parser/einemessage2", "w"); 688 m_file3 = fopen("/ser-0.8.12/parser/xmessagefile", "a"); 689 leerzeile = fopen("/ser-0.8.12/parser/leerzeile", "w"); 690 691 fprintf(m_file, "%s", mfl); 692 fprintf(leerzeile, "\n\tINSTANT MESSAGE\n"); 693 694 fclose(m_file); 695 fclose(m_file2); 696 fclose(m_file3); 697 fclose(leerzeile); 698 } 699 } 700 701 * Die Datei /ser-0.8.12/parser/msg_translator.c 702 703 #include "/ser-0.8.12/extern_variables.h" 704 705 // Instant Message 706 707 if (neu_message_id != alt_message_id){ // Wenn neue Message eintrifft 708 709 //Relevante Daten herausfiltern 710 711
Anhänge
133
system("sed -n '/From/ p' /ser-0.8.12/parser/einemessage >> /ser-.8.12/parser/einemessage2"); 712 system("sed -n '/To/ p' /ser-0.8.12/parser/einemessage >> /ser-0.8.12/parser/einemessage2"); 713 system("sed -n '/Call-ID/ p' /ser-0.8.12/parser/einemessage >> /ser-714 0.8.12/parser/einemessage2"); 715 system("sed -n '/Content-Length/ p' /ser-0.8.12/parser/einemessage >> /ser-716 0.8.12/parser/einemessage2"); 717 system("sed -n '/User-Agent/ p' /ser-0.8.12/parser/einemessage >> /ser-718 0.8.12/parser/einemessage2"); 719 720 system("cat /ser-0.8.12/parser/leerzeile >> /ser-0.8.12/parser/xmessagefile"); 721 system("date >> /ser-0.8.12/parser/xmessagefile"); //Datum und Uhrzeit hinzufügen 722 system("cat /ser-0.8.12/parser/einemessage2 >> /ser-0.8.12/parser/xmessagefile"); 723 724 alt_message_id = neu_message_id; 725