Diplom arbeit lotfi_faik_2005

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.


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.


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.


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


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.


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


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


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


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.


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.


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.


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.


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).


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.


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


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).


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


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


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)


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.


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


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


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


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


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


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


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


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


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),


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]


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.


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.


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.


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.


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.


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.


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


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

sip:[email protected]

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.


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)


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


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


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


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)


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.


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.


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.


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.


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


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.


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.


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


es+Secret)


Access-Challenge

Code: 11

copy of the

Identifier field of

the Access-Request

MD5(Code+ID+Length


es+Secret)


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


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.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


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]


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/ ))


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"


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.


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


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


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


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


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:


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.


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"


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.


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


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


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 &


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

Diplom arbeit lotfi_faik_2005

Documents

Transcript of Diplom arbeit lotfi_faik_2005