Andreas Orthen 2006

x x x x x x
x x x x x
x x x x x
x x x x x
x x x
Fachhochschule Köln
University of Applied Sciences Cologne
07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Elektrotechnik/NT
Institut für Nachrichtentechnik, Labor für Datennetze
Entwicklung einer Messumgebung zur Bewertung der Dienstgüte

(Quality-of-Service QoS) in heterogenen Netzen
Diplomarbeit
von
Andreas Orthen
Referent: Prof. Dr. Andreas Grebe
Korreferent: Dipl.-Ing. Stefan Abu Salah
Köln 2006
INHALTSVERZEICHNIS INHALTSVERZEICHNIS
Inhaltsverzeichnis
1 Danksagung 1
2 Einführung 2
3 Motivation und Aufgabenstellung 3
4 Grundlagen 4
4.1 Internettelefonie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1 Internet Protocol Version 4 (IPv4) . . . . . . . . . . . . . . . . . . . . 6
4.2.2 Internet Protocol Version 6 (IPv6) . . . . . . . . . . . . . . . . . . . . 8
4.3 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . . . . 10
4.4 User Datagramm Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Realtime Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1 Realtime Transport Control Protocol (RTCP) . . . . . . . . . . . . . . 15
4.5.2 Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 Session Initialisation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1 SIP-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.2 SIP-Signalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.3 SIP-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.4 SIP-Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.5 Anmeldung an einem SIP-Server . . . . . . . . . . . . . . . . . . . . . 20
4.6.6 SIP-Verbindungsaufbau und -abbau . . . . . . . . . . . . . . . . . . . 21
4.6.7 Session Description Protocol (SDP) . . . . . . . . . . . . . . . . . . . 25
4.7 Störfaktoren bei VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.1 Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.2 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7.4 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8.1 Priorisierung von MAC-Frames . . . . . . . . . . . . . . . . . . . . . 32
4.8.2 Type Of Service (TOS) . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8.3 Differentiated Services (DiffServ) . . . . . . . . . . . . . . . . . . . . 33
4.8.4 Integrated Services (IntServ) . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Messungen der Sprachqualität . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9.1 Listening Quality und MOS (Mean Opinion Score) . . . . . . . . . . . 35
4.9.2 Conversational Quality und Perceptual Speech Quality Measure (PSQM) 36
4.9.3 ITU E-Modell und VQmon . . . . . . . . . . . . . . . . . . . . . . . . 37
4.9.4 R-Faktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.10 Echtzeitverhalten und Latenzzeiten des Linux-Kernels . . . . . . . . . . . . . 39
1
4.11 Zeitmessung mit Linux unter Verwendung von GNU C . . . . . . . . . . . . . 39
5 Einführung in das Projekt 41

5.1 Verwendete Open Source Software . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1 Debian GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.2 Asterisk Private Branch Exchange (PBX) . . . . . . . . . . . . . . . . 42
5.1.3 SIP Express Router (SER) . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.4 RTP-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.5 Softphone kphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.6 SIPSet Application Programming Interface (API) . . . . . . . . . . . . 45
5.1.7 Gnuplot und gnuplot i C-Schnittstelle . . . . . . . . . . . . . . . . . . 45
5.1.8 Netzwerk-Analysatoren tethereal und ethereal . . . . . . . . . . . . . . 45
5.1.9 Sequence Diagram Generator callflow . . . . . . . . . . . . . . . . . . 46
5.1.10 Webserver Apache und PHP4 . . . . . . . . . . . . . . . . . . . . . . 46
5.1.11 Software Suite ImageMagick . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.12 Weitere Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Entwicklung 48
6.1 Modifikationen im Quellcode von gensend.bin und genrecv.bin . . . . . . . . . 48
6.2 Erweiterungen im RTP-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Auswertungsapplikation calculate . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.1 R-Faktor Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2 MOS-Wert Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Webfrontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 Steuerprogramme client und server . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6 Steuer- und Konfigurationsskripte . . . . . . . . . . . . . . . . . . . . . . . . 65
6.7 Funktionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7 Installation 70
7.1 Systemvoraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2 Debian Zusatzpakete installieren . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 Benutzer einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4 Apache Webserver einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.5 SER einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.6 RTP-Proxy einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.7 Konfigurationsskripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.8 Webbrowser Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8 Bedienung 75
8.1 Eingabemasken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.2 Ausgabemasken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2
9 Messungen 81
10 Kritische Betrachtung 84
11 Fazit 85
12 Abkürzungsverzeichnis 86
13 RFC-Verzeichnis und Software-Internetseiten 89
14 Anhang 93
3
1 DANKSAGUNG
1 Danksagung
Ich möchte mich an dieser Stelle besonders bei meinen Eltern, meinen Großeltern, meiner
Freundin und meinen Freunden bedanken, die mich während meiner Studienzeit und beson-
ders in den schwierigen Phasen während der Diplomarbeit unterstützt haben. Ebenso bedanke
ich mich bei allen Mitarbeitern des Fachbereichs Datennetze sowie bei den Studenten, die mir
Tipps und Ratschläge gegeben haben. Einen besonderen Dank für die gute Zusammenarbeit und
die außerordentliche Hilfsbereitschaft möchte ich den Mitarbeitern und Studenten des QoSSIP-
Projekts aussprechen. Weiterhin möchte ich mich herzlich bei meinem Referenten Prof. Dr.
Andreas Grebe und meinem Korreferenten Dipl.-Ing. Stefan Abu Salah bedanken.
1
2 EINFÜHRUNG
2 Einführung
Der Gedanke, Sprache über Computernetzwerke zu übertragen, stammt aus den 70er Jahren.
1973 fand die erste Sprachübertragung mittels eines paketorientierten Protokolls zwischen Ka-
lifornien und Massachusetts statt. Mitte der 80er Jahren wurde ISDN (Integrated Services Digi-
tal Network)1 als integrierender Dienst für Sprache, Daten, Video und Text eingeführt. Dieser
Ansatz kam aus der Sprachtelekommunikation und basiert auf einer Leitungsvermittlung und
auf 64 kBit/s Datenkanälen. 1995 stellte die Firma Vocaltec ihr Internettelefon Internet Phone
vor. Internet Phone arbeitet im Halbduplex-Verfahren ähnlich wie ein Funkgerät. Dieses Tele-
fon wurde direkt am Computer angeschlossen, um eine bessere Sprachqualität zu erzielen. Zu
dieser Zeit waren Computer jedoch noch nicht in der Lage, Analog-Digital-Wandlungen selbst
durchzuführen. Die von Vocaltec vorangetriebene Idee, Sprache über vernetzte Computer zu
übertragen, wurde von der Entwicklergemeinde euphorisch aufgegriffen. In den darauffolgen-
den Jahren entstand eine Flut von Softphones2 und Gateways3 , welche die Verbindung vom
Computer ins Telefonnetz PSTN (Public Switched Telephone Network) auf einfache Weise
ermöglichten.
Im Zuge der zunehmenden Aufmerksamkeit für dieses Thema wurden alsbald Standards für
Echtzeitdatenübertragung im Internet verabschiedet, welche die Basis paketbasierter Telefonie
bildeten. In diesem Zeitraum wurden auch Begriffe wie Internettelefonie und VoIP (Voice over
IP) geprägt . Bis zum Jahr 2000 hatten alle namhaften Internetfirmen und Institute erste Unter-
suchungen zur Sprachqualität und Realisierung von VoIP in den unterschiedlichsten Szenarien
durchgeführt. Es wurden Messverfahren zur Bestimmung von Sprachqualität in paketvermittel-
ten Netzen standardisiert. Federführend bei der Standardisierung vieler Mess- und Kompressi-
onsverfahren war und ist die ITU (International Telecommunication Union). Die meisten der
entwickelten Verfahren und Auswertungsalgorithmen stehen jedoch unter kommerziellen Li-
zenzen und finden nur Anwendung in teurer professioneller Messsoftware. Im semiprofessio-
nellen Bereich werden jedoch häufig einfache, sich auf die wesentlichen Faktoren stützende
und kostengünstige Lösungen benötigt, die als alleinstehende Applikationen Administratoren
wichtige Netzkenndaten liefern oder den Endanwender eingebettet, in Softphones oder VoIP-
Applikationen, über Qualität der Sprache und Übertragungsstrecke informieren.
1
Im Folgenden werden Fachbegriffe in der Regel in der englischen Sprache geschrieben, da Englisch die Fach-
sprache der IT ist und die Basis für Abkürzungen darstellt. So zum Beispiel ISDN für Integrated Services Digital
Network.
2
Softphone ist ein Telefon, das die Soundkarte des Computers nutzt und aus einer Softwareapplikation besteht.
3
Gateways erlauben Netzwerken, die auf unterschiedlichen Protokollen basieren, miteinander zu kommunizieren.
2
3 MOTIVATION UND AUFGABENSTELLUNG
3 Motivation und Aufgabenstellung

Kann man über die zur Verfügung stehende Internetverbindung ein VoIP-Gespräch in guter
Qualität führen? Diese oder eine ähnliche Frage wird sich jeder stellen, der mit VoIP arbeiten
möchte. Obwohl die Frage im ersten Moment mit Sicherheit recht einfach erscheint, wird bei
genauerer Betrachtung der Funktionsweise von VoIP die Komplexität der möglichen Antworten
deutlich.
Die Faktoren, die bei der Übertragung von Sprache eine Rolle spielen, lassen sich in Grup-
pen einteilen. Bei der Abnahme der Sprache über ein Mikrofon geht es in erster Linie um
akkustische Faktoren. Der Prozess der Umwandlung der analogen Audiosignale in digitale Si-
gnale, die vom Computer weiterverarbeitet werden können, beinhaltet Faktoren, die Störungs-
quellen darstellen können. Heutige Headsets, Soundkarten und DSP4 (Digital Signal Processor)
-Halbleiterbausteine weisen jedoch gute Übertragungskennlinien auf, so dass Qualitätsverluste
durch diese Faktoren vernachlässigbar sind. Haupsächlichen Einfluß auf die Sprachqualität
einer VoIP-Übertragung haben der verwendete Sprachcodec und die Qualität der verwende-
ten Übertragungsstrecke. Ein weiterer sehr wichtiger Faktor ist die Skalierbarkeit paralleler
VoIP-Gespräche bei vorgegebener Übertragungsbandbreite in einem VoIP-Netzwerk. Ab wel-
cher Höhe der Netzauslastung durch VoIP-Telefonie sinkt die Dienstgüte einzelner Gespräche?
In heterogenen Netzwerken, in denen Programme und Dienste Netzlasten unterschiedlichster
Charaktaristik erzeugen, muss die Bandbreite und Netzperformence für VoIP-Datenströme si-
chergestellt sein. Dies geschieht in der Regel durch eine Bevorzugung der übertragenen Sprach-
daten.
Das QoSSIP-Projekt5 , in dessen Rahmen die vorliegende Diplomarbeit erstellt wurde, befasst
sich mit der oben aufgeworfenen Frage. Es behandelt Design- und Konfigurationsempfehlun-
gen, Messmethoden und Abrechungsverfahren für qualitativ steuerbare Kommunikationsdiens-
te in zusammengeschalteten, heterogenen Datennetzen. QoSSIP steht für den Kernbereich des
Projekts, Quality of Service in Netzen die auf SIP (Kap.: 4.6) aufbauen. Es wird vom BMBF
(Bundesministerium für Bildung und Forschung) unterstützt und ist Teil des FH3 -Programms.
Im Rahmen des QoSSIP-Projekts sollte eine benutzerfreundliche Messapplikation entwickelt
werden, welche Daten, die zur Dienstgütebestimmung erforderlich sind, in Echtzeit aufzeich-
net. Dies soll auch für mehrere simultan aufgebaute VoIP-Verbindungen und deren Datenströme
möglich sein. Die Messwerte werden nach Beendigung einer Aufzeichnungsphase in einem
weiteren Schritt ausgewertet und analysiert. Nach der Anlyse der Messdaten und Einschätzung
der Dienstgüte soll dem Anwender das Ergebnis in übersichtlicher Weise präsentiert werden.
Nach der Fertigstellung der Messapplikation soll diese für Messungen an einer 2Mbit MPLS
(Multiprotocol Label Switching)6 Strecke zwischen der Fachhochschule-Köln und der Fach-
hochschule-Frankfurt zur Verfügung stehen. Eine weitere Anforderung an das Messwerkzeug
4
DSP ist die Hardware die der kontinuierlichen digitalen Bearbeitung analoger Signale dient.
5
Die Internetseite des QoSSIP-Projekts ist http://www.qossip.de/.
6
MPLS arbeitet zwischen den Schichten 2 und 3 des OSI-Schichtenmodells. In dieser Schicht werden die Datenpa-
kete mit QoS geroutet.
3
4 GRUNDLAGEN
ist eine einfache Portierbarkeit auf andere Computer.
4 Grundlagen
4.1 Internettelefonie
Unter VoIP (Voice over IP) wird der Transfer von Sprachdaten in Paketen durch das Inter-
net Protokoll (IP) verstanden. Als Übertragungsmedium benutzt VoIP das weltweit verfügbare
Internet. Für den Transfer von Audiodaten sind folgende Punkte wichtig: Die Steuerung der
Verbindungssignalisierung sowie die Übertragung der Sprachdaten in Paketen. Ersteres wird
durch Protokolle wie H.3237 oder SIP (Session Initiation Protocol) erreicht, die für das Routing
zum Gesprächspartner sowie den Verbindungsaufbau verantwortlich sind. Diese werden auch
als Signalisierungsprotokolle bezeichnet. Die Datenübertragung der Audiodaten wird anschlie-
ßend durch ein separates Protokoll, das sogenannte RTP (Real Time Protocol) realisiert.
Eine der größten Anforderungen an das Internet bei der Übertragung von VoIP-Daten ist die
Echtzeitfähigkeit. Das dem Internet zugrunde liegende Internet Protokoll wurde ursprünglich
für reine Datenübertragung konzipiert und besitzt daher keine effizienten Mechanismen, die die
Priorisierung von Datenpaketen oder QoS (Quality of Service) ermöglichen. Dies ist jedoch für
die Übertragung von Audio- und Videodaten unerlässlich.
Im Vergleich zu VoIP, bekommt im PSTN (Public Switched Telephone Network) jeder Teil-
nehmer, nach erfolgreichem Gesprächsaufbau, eine Leitung exklusiv zur Verfügung gestellt.
Dadurch bekommt er eine feste Bandbreite zugeteilt, die wiederum eine gute Sprachqualität
garantiert. VoIP jedoch kann nur durch die Bereitstellung von genügend Bandbreite und die
Priorisierung der Echtzeitpakete durch QoS einen gleichwertigen Standard erreichen.
Einführend zeigt Abbildung 1 eine Übersicht, welche die Protokoll-Hierarchie aufzeigt. Die in
der vorliegenden Diplomarbeit verwendeten Protokolle sind fett umrandet und werden in den
folgenden Unterkapiteln geauer beschrieben.
7
H.323 ist ein Protokoll der ITU-T, welches Q.931 als Signalisierung benutzt.
4
4.2 Internet Protocol (IP) 4 GRUNDLAGEN
Abbildung 1: Protokoll-Hierarchie
4.2 Internet Protocol (IP)

Als eins der Kern-Protokolle (core protocol) des Internets ist IP (Internet Protocol) das Ba-
sisprotokoll für VoIP. IP ist nicht nur wichtig für das Verständnis der Funktionsweise des In-
ternets, sondern dient auch als Grundlage aller in der vorliegenden Diplomarbeit verwendeten
Protokolle. Im Folgenden wird IP in seinen Grundzügen beschrieben.
IP ist ein verbindungsloses Datagramm-Protokoll, das in der Vermittlungsschicht im ISO OSI-
Schichtmodell8 (Abb.: 2) angesiedelt ist. Spezifiziert wurde das IP erstmals im Dokument RFC
7919 und bildet heute eine wichtige technische Grundlage des Internets. Unklarheiten aus der
RFC 791 wurden in der RFC 1122 (Host Network Requirements) beseitigt. Aufgabe von IP ist
es, Daten vom lokalen System entgegenzunehmen und diese über die Bitübertragungsschicht im
OSI-Schichtmodell (Abb.: 2) in Richtung des Ziels zu leiten. Dies geschieht durch einzelne IP-
Datagramme. Ein IP-Datagramm setzt sich aus einem IP-Header und dem IP-Paket, welches die
Nutzdaten enthält, zusammen. Der IP-Header enthält unter anderem Absender- und Zieladres-
se. Aus diesem Grund können IP-Datagramme unabhängig voneinander über unterschiedliche
Wege durch das Internet geroutet10 werden. IP-Pakete können Daten höherer Protokolle wie
beispielsweise TCP (Transmission Control Protocol), UDP (User Datagramm Protocol) enthal-
ten. ICMP spielt unter diesen Protokollen eine gesonderte Rolle. Es wird zur Fehlersuche und
Steuerung eingesetzt. Jede IP-Implementierung enthält stets auch eine ICMP-Implementierung.
Bei der Entwicklung der Netzapplikationen für die vorliegende Diplomarbeit war ICMP be-
sonders bei der Fehlersuche hilfreich. Die im IP-Datagramm enthaltenen Nutzdaten werden
auch als Payload bezeichnet. Der Payload ist damit das IP-Paket und kann weiter verschachtelte
Datagramm-Protokolle mit Header und Payload enthalten.
8
ISO steht für International Organization Standardization, OSI steht für Open Systems Interconnection.
9
RFC ist die Abkürzung für Request for Comments.
10
Als routing bezeichnet man das Festlegen von Wegen für Nachrichtenströme oder IP-Datenpakete.
5
Abbildung 2: ISO OSI-Schichtmodell
Abkürzung Erklärung
AH Application-Header
PH Presentation-Header
SH Session-Header
TH Transport-Header
NH Network-Header
DH Data Link-Header
DT Data Transport-Header
Tabelle 1: Erklärung der Abkürzungen im ISO OSI-Schichtmodell
Aufbauend auf der Grundfunktionalität von IP werden nun die beiden zur Zeit existierenden
Versionen vorstellt. In der vorliegenden Diplomarbeit wird ausschließlich die IP Version 4 be-
nutzt. Mit der Beschreibung des IP Version 6 sollen die Probleme die IP Version 4 hat, verdeut-
licht werden.
4.2.1 Internet Protocol Version 4 (IPv4)
IPv4 (Internet Protocol Version 4, RFC 791 und RFC 1122), früher nur als IP bezeichnet, ist die
erste Version des Internet Protokolls. Diese Version ist zudem weltweit die am meisten verwen-
dete. Da IPv4 32-Bit-Adressen benutzt, sind maximal 232 = 4.294.967.296 eindeutige Adressen
möglich. Die jetzt bereits begrenzte Anzahl der zur Verfügung stehenden IPv4-Adressen stell-
ten unter anderem ein Problem für den wachsenden VoIP und Telekommunikationsmarkt dar, da
immer mehr internetfähige Geräte angeboten werden. Viele Neuentwicklungen in diesen Berei-
6
chen benutzen IP als Übertragungsplattform. Ein Beispiel aus dem Telekommunikationssektor

ist der 3G-Mobilfunk, welcher auf IP-Adressen angewiesen ist. Mechanismen wie PAT11 (Port
Address Translation), auch Masquerading genannt, und NAT12 (Network Address Translation,
RFC 2663) bilden nur eine Übergangslösung zu IPv6 (IP Version 6). Denn eine saubere Tren-
nung der Netzschichten, wie sie im ISO OSI-Schichtmodell (Abb.: 2) gefordert wird, wird hier
nicht eingehalten. Viele Protokolle der Transportschicht funktionieren mit PAT und NAT nur
ungenügend. Dies gilt auch für viele VoIP-Applikationen und die im Rahmen der vorliegenden
Diplomarbeit entwickelten und modifizierten Programme.
Veranschaulicht wird der Aufbau eines IPv4-Datagramms mit der folgenden Abbildung 3. Die
Felder des IPv4-Datagramms werden in Tabelle 2 erläutert. Wichtig sind hierbei zum einen
die Source- und Destination-Address-Felder, und zum anderen das TOS-Feld (Type of Service
Field), welches in Kapitel 4.8.2 genauer betrachtet wird.
Abbildung 3: IPv4-Datagramm (RFC 791)
11
PAT ist ein Verfahren in IPv4-Netzwerken zur Portumsetzung. Der Port und die IP-Adresse einer IPv4-Schnittstelle
wird anhand einer Tabelle auf den Port und die IP-Adresse einer anderen meist lokalen Schnittstelle umgeschrie-
ben.
12
NAT ist ein Verfahren in IPv4-Netzwerken zur Adressumsetzung. Die IP-Adresse einer IPv4-Schnittstelle wird
anhand einer Tabelle auf die IP-Adresse einer anderen meist lokalen Schnittstelle umgeschrieben.
7
Version IP Version. Derzeit Version 4 oder 6.
IHL Internet Header Length. Dieser Wert gibt an, wie lange der gesamte IP-
Header ist.
Type of Service TOS siehe Kapitel 4.8.2.
Total Length Gibt die Länge des gesamten Pakets (inklusive Header) in Bytes an.
Identification Dieses und die beiden folgenden Felder, Flags und Fragment Offset,
steuern die Reassembly (Zusammensetzung von zuvor fragmentierten
IP-Datenpaketen).
Flags Kontroll-Schalter
Fragment Offset Eine Nummer, die bei fragmentierten Paketen besagt, welche Position
das Paket innerhalb der Fragmente einnimmt. Der Offset wird in 64 Bit/
8 Byte-Schritten angegeben, wobei das erste Fragment den Wert null
hat.
Time To Live Ein Wert, der die Lebenszeit“ des Pakets angibt. Bei jedem Hop (Beim
”
(TTL) Routing wird ein Hop als Weiterleitung von einem Router zu einem
anderen Router bezeichnet.) wird die TTL dekrementiert. Hat dieses
Feld den Wert null, muss das Paket verworfen werden.
Protocol Dieses Feld bezeichnet das Folgeprotokoll. Ein IP-Paket enthält bei-
spielsweise ein UDP-Paket, wenn der Wert 0x11 (Dual 17) ausgegeben
wird.
Header Checks- Eine Prüfsumme ausschließlich für den Header (IP selbst hat keine Me-
um chanismen zur Prüfung der Nutzlast auf Korrektheit). Dieser Wert wird
bei jeder Station neu verifiziert und berechnet, weil die TTL bei jedem
Hop verändert wird.
Source Address Enthält die Quelladresse des IP-Pakets in network byte order
Destination Enthält die Zieladresse und hat das gleiche Format wie die Quelladres-
Address se.
Options Die Optionen müssen ein Vielfaches von 32 Bit lang sein. Sind sie das
nicht, werden sie mit 0 Bits aufgefüllt.
Padding Dies ist der Bereich zum Auffüllen der Optionen mit 0 Bits.
Tabelle 2: Erklärung der Felder im IPv4-Datagramm
4.2.2 Internet Protocol Version 6 (IPv6)
Obwohl in der vorliegenden Diplomarbeit IPv6 (Internet Protokoll Version 6, RFC 2460) nicht
verwendet wird, werden in dieser kurzen Einführung die Möglichkeiten, die IPv6 bietet auf-
geführt um einen Ausblick in die Zukunft von IP zu geben. IPv6 ist die neuste Internet Pro-
tokoll Version und verwendet 128 Bit Adressen. Mit 2128 = 3,4 * 1038 (340,28 Sextillionen)
eindeutigen Adressen ist IPv6 in der Lage, den heutigen Ansprüchen zu genügen. Wegen des
hohen Migrationsaufwands und der damit verbundenen Kosten setzt sich IPv6 jedoch nur sehr
langsam durch. Derzeit sind IPv6-Netze eher Insellösungen für größere Firmennetze. Vor allem
große Carrier und Provider halten sich mit dem Angebot von IPv6-Adressen noch sehr zurück.
Dabei bietet IPv6 mehr als nur einen erweiterten Adressraum. Wesentliche Erneuerungen sind
der erweiterte Support für Erweiterungen und Optionen, die Fähigkeit, den Datenfluss zu mar-
kieren und die Möglichkeit der Authentifizierung und Sicherstellung der Datenvertraulichkeit.
8
IPv6 zeigt Methoden zur Lösung von IPv4-Problemen wie Autokonfiguration, Umnumme-
rierung und Unique Local Addresses auf. Des Weiteren wurde eine Erweiterung des IPv6-
Standards unter dem Namen Mobile IPv6 (RFC 3775) in das IPv6-Protokoll integriert, wel-
ches die weltweite Erreichbarkeit einer IPv6-Adresse mit Hilfe eines sogenannten HA (Home
Agent) ermöglicht. Der nähere Aufbau von IPv6 wird in der folgenden Abbildung 4 und der
dazugehörigen Tabelle 3 deutlich.
Abbildung 4: IPv6-Datagramm (RFC 2460)
Version IP-Versionsnummer
Traffic Class Von QoS verwendetes 8-Bit-Feld.
Flow Label Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pake-
te, die ein Flow Label tragen, werden alle gleich behandelt.
Payload Length Länge des IPv6-Paketinhaltes (ohne Header aber inklusive der
Erweiterungs-Header).
Next Header Identifiziert den Typ des nächsten Erweiterungs-Headers.
Hop Limit Entspricht dem TTL-Wert von IPv4, Tabelle 2.
Source Address Adresse des Senders.
Destination Adresse des Empfängers.
Address
Tabelle 3: Erklärung der Felder im IPv6-Datagramm
9
4.3 Transmission Control Protocol (TCP) 4 GRUNDLAGEN
Das IP-Protokoll ist die Grundlage für die Protokolle TCP (Transmission Control Protocol) und
UDP (User Datagramm Protocol). Im Rahmen der vorliegenden Diplomarbeit wird das TCP
zur Signalisierung und Steuerung verwendet, während UDP die Basis für das VoIP RTP bildet.
4.3 Transmission Control Protocol (TCP)

TCP (Transmission Control Protokoll, RFC 793, RFC 1323) ist ein weiteres Kern-Protokoll
für das Internet, das sowohl auf IPv4 als auch auf IPv6 aufbaut. Es ist in die Transportschicht
des OSI-Schichtmodells (Abb.:2) implementiert und bildet eine Art Vereinbarung für den Da-
tenaustausch vernetzter Computer. Es stellt einen virtuellen Kanal zwischen zwei Endpunkten
einer Netzwerkverbindung, den sogenannten Sockets, her. Auf diesem Kanal können in beide
Richtungen Daten übertragen werden. Notwendig zum Identifizieren einer TCP-Verbindung ist
ein Tupel, das aus einer IP-Adresse, die den beteidigten Host13 identifiziert, und aus dem Port
besteht, der die dazugehörige Applikation spezifiziert. Ein Port ist der Teil der Netzadresse, der
die Applikation identifiziert. Für die Portnummern (Port Number) sind 2 Byte reserviert. Der
Portbereich (Port Range) reicht somit von 0 bis 65535. Ports von 0 bis 1023 sind als bekannte
Ports (Well Known Ports) bei der IANA (Internet Assigned Numbers Authority) reserviert und
sollten nur mit den dort spezifizierten Applikationen genutzt werden.
Ein wichtiges Merkmal von TCP ist die Tatsache, dass es Datenverluste erkennt und auto-
matisch behebt. Jedes Datenpaket wird vom Empfänger quittiert. Erreicht diese Empfangs-
bestätigung nicht innerhalb einer festgelegten Zeit den Sender, wird das TCP-Paket erneut
versendet. Diese Eigenschaft wird auch als PAR-Mechanismus bezeichnet (Positive Acknow-
ledgement with Retransmission). Dieser zuverlässige bidirektionale Datentransport wird unter
anderem in den Protokollen HTTP, SSH, FTP und DNS verwendet. Da jede TCP-Verbindung
eindeutig durch zwei Endpunkte definiert wird, besteht die Möglichkeit, dass ein SIP-Server
(Kap.: 4.6) auf Port 5060 mehr als eine Verbindung zu einem Host geöffnet haben kann. Die
Vergabe von Ports auf beiden Seiten ermöglicht ein Verfahren, das als Drei-Wege-Handshake
bekannt ist.
Abbildung 5: TCP-Handshake Abbildung 6: TCP-Teardown
Möchte ein Client eine TCP-Verbindung aufbauen, generiert er einen eigenen Endpunkt aus
seinem Hostnamen und einer noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports
13
Host ist eine netzwerkfähige Komponente.
10
4.3 Transmission Control Protocol (TCP) 4 GRUNDLAGEN
und der IP-Adresse des Servers kann dann eine Verbindung aufgebaut werden. Für den Aufbau
der Verbindung sind insgesamt drei Pakete erforderlich (Abb.: 5).
Während der Datenübertragungsphase (Active Open) sind auf Protokollebene die Rollen von
Client und Server vollkommen symmetrisch. Jeder der beteiligten Hosts kann eine Datenübertragung
einleiten. Während des Abbaus von einer Seite der TCP-Verbindung kann die Gegenseite jedoch
noch weitere Daten übertragen, das heißt die Verbindung kann halb offen sein. Ein 4-Wege-
Handshake, auch TCP-Teardown genannt, wird benutzt, um die Verbindung abzubauen (Abb.:
6). Abbildung 7 gibt einen Überblick über das TCP-Datagramm.
Abbildung 7: TCP-Datagramm (RFC 793)
11
4.4 User Datagramm Protocol (UDP) 4 GRUNDLAGEN
Source Port Gibt die Portnummer der Senderseite an.
Destination PortGibt die Portnummer der Empfängerseite an.
Sequence Num- Sequenznummer des ersten Daten-Oktetts (Bytes) dieses TCP-Pakets
ber oder die Initialisierungs-Sequenznummer, falls das SYN-Flag gesetzt
ist. Nach der Datenübertragung dient sie zur Sortierung der TCP-
Segmente, da diese in unterschiedlicher Reihenfolge beim Empfänger
ankommen können.
Acknowledgement Gibt die Sequenznummer an, die der Sender dieses TCP-Segments als
Number nächstes erwartet. Sie ist nur gültig, wenn das ACK-Flag gesetzt ist.
Data Offset Länge des TCP-Headers in 32 Bit Blöcken, ohne Payload. Hier wird die
Startadresse der Nutzdaten identifiziert.
Reserved Das Reserved-Feld wird derzeit nicht verwendet und muss null sein.
Flags Möglich sind URG-Flag, ACK-Flag, PSH-Flag, RST-Flag, SYN-Flag
und FIN-Flag. Weiterführende Informationen finden sich in der RFC
1323.
Window Ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das
Acknowledgementfeld indizierten Daten-Oktett, die der Sender dieses
TCP-Pakets bereit ist, zu empfangen.
Checksum Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird
über den Header und die Daten berechnet.
Urgent Pointer Zusammen mit der Sequenz-Nummer gibt dieser Wert die genaue Po-
sition der Daten im Datenstrom an. Der Wert ist nur gültig, wenn das
URG-Flag gesetzt ist.
Options Das Options-Feld ist unterschiedlich groß und enthält Zusatzinforma-
tionen. Die Optionen müssen ein Vielfaches von 32 Bit lang sein, sonst
werden sie aufgefüllt (padding). Es werden Verbindungsdaten ausge-
handelt, die nicht im TCP-Header enthalten sind, wie zum Beispiel die
Maximalgröße des Nutzdatenfeldes.
Tabelle 4: Erklärung der Felder im TCP-Datagramm
4.4 User Datagramm Protocol (UDP)

Wie bereits erwähnt, ist UDP (User Datagramm Protocol, RFC768) das zweite in der vorlie-
genden Diplomarbeit verwendete Protokoll neben TCP, das auf IP aufbaut und in die Trans-
portschicht des ISO OSI-Schichtmodells (Abb.:2) implementiert ist. Die Entwicklung von UDP
begann 1977, als man für die Übertragung von Sprache ein einfaches Protokoll benötigte. Es
stellt Mechanismen für Applikationsprogramme bereit, um Daten mit einem minimalen Pro-
tokollaufwand zu senden. Sobald ein System ein IP-Datagramm erhält, das als Protokoll 0x11
(17 Dezimal) (Tab.: 2) gekennzeichnet ist, muss es an den lokalen UDP-Dienst weitergegeben
werden. UDP ist ein verbindungsloses Protokoll und bietet fast keine Sicherheitsmechanismen.
Außerdem benötigt es im Gegensatz zum TCP-Protokoll keine direkten Verbindungen. Daher
ist es möglich, zum Beispiel Multicasts14 an Computer zu senden, ohne wie bei TCP zuerst
14
Multicast bezeichnet eine Daten- oder Sprachübertragung von einem Sender zu einer Gruppe von Empfängern 1:n
Verbindung (n ∈ N).
12
4.4 User Datagramm Protocol (UDP) 4 GRUNDLAGEN
zu jedem einzelnen eine direkte Verbindung aufzubauen. Bei UDP werden solche Datenpakete
gleichzeitig versendet. Genau diese Eigenschaft macht UDP für Audio- und Videoapplikatio-
nen so interessant. Datenpakete werden zum Beispiel bei einem Streaming-Server in einem
Datenstrom übertagen. Geht ein UDP-Paket verloren, wird der User dies höchstens als kurze
Tonstörung wahrnehmen. Läuft dieselbe Applikation beispielsweise über TCP und würde dort
ein Paket verloren gehen, müsste TCP dieses Paket erneut anfordern. Dieser Vorgang kostet
jedoch Zeit und kann bei einer Vielzahl verlorener Pakete zu einem Datenstau führen, der eine
konstante Datenübertragung massiv stört. Für den Anwender würde sich ein solcher Datenstau
als Unterbrechnung im Gespräch bemerkbar machen. UDP hingegen beeinträchtigt ein verlo-
renes Paket kaum und die Darstellung wird mit einer nur kleinen Audiostörung weitergeführt.
UDP ist damit die zu bevorzugende Variante.
Die Abbildung 8 zeigt anschaulich den einfachen Aufbau des UDP-Datagramms im Vergleich
zu TCP (Abb.: 4.3). Das UDP-Datagramm liefert die Ports für die verwendeten VoIP-Programme,
die auf UDP aufbauen.
Abbildung 8: UDP-Datagramm (RFC 768)
Source Port Der Quell-Port gibt die Portnummer der senden Applikation an. Diese
Information wird benötigt, damit der Empfänger auf das Paket antwor-
ten kann. Da UDP verbindungslos ist, ist der Quell-Port optional und
kann auch auf den Wert 0 gesetzt werden.
Destination Port Der Zielport gibt an, welche Applikation das Paket empfangen soll.
Length Das Längenfeld gibt die Größe des Pakets in Bytes an und besteht aus
Header und Daten.
Checksum In dem Prüfsummenfeld kann eine 16 Bit große Prüfsumme mitgesen-
det werden. Die Prüfsumme wird über den Header, den sogenannten
Pseudo-Header, und die Daten gebildet. Die Prüfsumme ist optional.
Data Octetes Im Feld Daten Bytes werden die UDP-Nutzdaten übertragen, exempla-
risch RTP-Datagramme.
Tabelle 5: Erklärung der Felder im UDP-Datagramm
13
4.5 Realtime Transport Protocol (RTP) 4 GRUNDLAGEN
4.5 Realtime Transport Protocol (RTP)

Im Kapitel 4.4 wurde bereits der Vorteil eines verbindungslosen Protokolls für VoIP hervorge-
hoben. Mit RTP (Realtime Transport Protokoll, RFC 3550) soll nun das Protokoll vorgestellt
werden, mit dem kontinuierliche Audio- und Videoströme übertragen werden. RTP wurde von
IETF (Internet Engineering Task Force) entwickelt und bietet Funktionen für den Ende-zu-
Ende-Transport (End To End Transport) von Echtzeitdaten. RTP ist im ISO OSI-Schichtmodell
(Abb.: 2) in der Anwendungsschicht angesiedelt. Es baut dabei hauptsächlich auf UDP als
Transportprotokoll auf und benutzt einen bitorientierten Header. RTP wird in seltenen Fällen
auch über TCP übertragen, worauf aber nicht näher eingegangen werden kann. Des Weiteren
kann RTP keinen Verbindungsaufbau oder -abbau initziieren und ist deshalb auf Protokolle wie
H323 oder SIP angewiesen. Auch besitzt RTP kein Quality of Service, so dass hier Verfahren an-
setzen wie DiffServ (Kap.:4.8.3) oder RSVP15 . Ohne QoS werden RTP-Pakete wie alle anderen
Pakete im Internet nach best effort behandelt. Best effort ist eine minimalistische Dienstgüte-
Zusicherung, die nur die schnellstmögliche Verarbeitung im Rahmen der zur Verfügung stehen-
den Ressourcen zusagt. Paketverluste, zeitliche Paketverzögerung und asymmetrisches Rou-
ten16 werden aber von RTP erkannt. Ein wichtiger Mechanismus in RTP ist der Austausch von
Zeit- und Synchronisierungsmarken zwischen Sender und Empfänger. Außerdem erhalten alle
RTP-Pakete einen Timestamp und eine Sequenznummer. Timestamp und Sequenznummer wer-
den in der vorliegenden Diplomarbeit genutzt, um die IP-spezifischen Parameter zu bestimmen.
Diese sind für Dienstgütebestimmungen notwendig, und werden zu einem späteren Zeitpunkt
näher beschrieben.
Die Abbildung (Abb.: 9) zeigt den genauen Aufbau eines RTP-Datagramms. Informationen zu
den Begriffen können aus Tabelle 6 entnommen werden.
Abbildung 9: RTP-Datagramm (RFC 3550)
15
RSVP (Resource Reservation Protocol, RFC 2205) ist ein weiteres Signalisierungsprotokoll, welches QoS be-
herrscht.
16
Beim asymmetrisches Routen ist der Weg eines Datenpakets durch das IP-Netz unterschiedlich.
14
V Versionsnummer, Standard ist hier die Version 2 nach RFC 1889.Versi-
on 0 und 1 wurden von dem Audiotool vat benutzt.
P Padding, wird benutzt wenn dem Header ein oder mehrere Padding oc-
tets folgen. Das Flag wird benutzt da, Padding vom Payload abgegrenzt
werden muss.
X Extension, ist dieses Flag gesetzt, folgt genau eine Header-Erweiterung.
CC CSRC Count, gibt die Anzahl der CSRC-Intifier wieder.
M Unspezifiziert
PT Payload Type, gibt das Format der Palyload Daten an. Es sind 7 Bit als
PT reserviert. Der PT enthält Informationen wie der Payload dekodiert
wird. Es existieren schon definierte PT, aber auch eine frei PT-Wahl ist
möglich.
Sequence Number Die Sequenz Nummer ist für jedes RTP-Paket eindeutig und wird fort-
laufend inkrementiert. Die Sequenz Nummer ist wichtig für die Bestim-
mung der Reihenfolge der Pakete.
SSRC Synchronization Source Identifier, kann die Senderidentifikation enthal-
ten. Ist in der Übertragungsstrecke ein Mixer zwischengeschaltet, so
wird SSRC überschrieben.
CSRC Contributing Source Identifiers, definiert die Liste der Empfänger. Es
müssen genau so viele Listeneinträge vorhanden sein, wie im CC ver-
merkt. Da das CC Feld optional ist, kann auch der Wert 0 existieren.
Tabelle 6: Erklärung der Felder im RTP-Datagramm
4.5.1 Realtime Transport Control Protocol (RTCP)
Das RTCP (Realtime Transport Control Protocol, RFC 1890) hat die Hauptaufgabe, aktuelle
Informationen über die Qualität der Datenverteilung im Netzwerk zu liefern. Dieses Feedback
ermöglicht den Applikationen, den von ihnen generierten Datenstrom an die Netzbedingun-
gen anzupasssen, beispielsweise durch Reduktion der Datenrate bei geringer Dienstgüte, und
so Fehler einzugrenzen. Deshalb wird RTCP auch als Steuerungsprotokoll für RTP bezeich-
net. Es werden dazu periodisch SR (Sender Reports) und RR (Receiver Reports) übertragen.
Die zweite wichtige Aufgabe ist die Übertragung einer konstanten und eindeutigen Kennzeich-
nung, dem CNAME (Canonical Name). Optional kann jeder Teilnehmer via SDES (Source
Description) grundlegende Informationen über sich selbst versenden, welche unter anderem in
der Anwendung der Empfängerseite angezeigt werden können. In der vorliegenden Diplomar-
beit kann nicht näher auf das Protokoll eingegangen werden, da es in dem verwendeten RTP-
Protokollstack17 nicht genutzt wurde.
17
Protokollstack ist eine konzeptuelle Architektur von Netzprotokollen.
15
4.5.2 Codec
Datenstöme aus Audio- und Videodaten werden in der Regel zwischen den Endpunkten kodiert
versendet. Codec ist ein Akronym aus den englischen Begriffen coder und decoder. Codieren
ist in diesem Fall nicht mit Verschlüsseln zu verwechseln, vielmehr besteht die Aufgabe des
Codierens in der Reduktion des Nutzdatenaufkommens. Dadurch verringert sich die für die
Übertragung des digitalen Signals notwendige Bandbreite. Mittlerweile gibt es eine Vielzahl
an Codecs mit unterschiedlichen Zielsetzungen und Anwendungsfeldern. Der in der ISDN-
Festnetz-Telefonie gängige Sprachcodec G.711 wird hier oft als Referenzcodec genutzt. G.711
benutzt PCM (Puls Code Modulation) und die Audiodaten werden nicht komprimiert. Ein Vor-
teil von G.711 bei der Verwendung in VoIP-Netzen ist, dass keine Umkodierung bei der Ver-
mittlung ins PSTN notwendig ist.
Das Verhältnis von Frequenz und Abtastrate wird in der Regel durch das Nyquist-Theorem
beschrieben. Die Abtastrate muss mindestens doppelt so hoch angesetzt werden wie die höchste
abzutastende Frequenz. Der Frequenzbereich der menschlichen Sprache liegt unterhalb einer
Schwelle von 4000 Hz. Daraus ergibt sich eine Abtastrate von 8000 Hz. Da jeder Tastwert in
acht Bit gespeichert wird, ergibt sich hieraus eine Bandbreite von 64 kBit/s. Das entspricht auch
der Bandbreite, die G.711 benötigt.
Kriterien, nach denen ein Sprachcodec für VoIP-Anwendungen ausgesucht wird, sehen wie
folgt aus:
• Welche Bandbreite soll pro VoIP-Verbindung belegt werden?
• Welchen Rechenaufwand benötigt der Codec zum Kodieren und Dekodieren?
• Welchen Frequenzbereich soll der Codec abdecken und wie viele Kanäle werden benutzt?
• Welche Mechanismen wendet der Codec an, wenn Pakete verlorenen gehen?
In Tabelle 7 ist eine Liste von ITU-T-Sprachcodecs, die quelloffen und frei benutzbar sind, dar-
gestellt. Alle hier beschriebenen Codecs haben einen MOS-Wert (Mean Opinion Score Value,
Kap.: 4.9.1), der größer als 4,0 ist, da bei der Verwendung von VoIP im kommerziellen Einsatz
die Qualität eines Codecs den Ansprüchen von ISDN-Telefonie genügen muss.
Codec Sampling Bandwidth Payload MOS Komprimierung

Rate (kHz) (kbps) Size
(ms)
G.711, a/u- 8 64 20 4,4 keine (PCM)
law
G.722 16 54-64 30 4,5 ADPCM
G.726 8 16-40 20 4,2 ADPCM
G.728 8 16 4,2 LD-CELP
Tabelle 7: Freie Audio Codecs mit einem MOS-Wert grösser 4 (Lit.:(2))
16
4.6 Session Initialisation Protocol (SIP) 4 GRUNDLAGEN
4.6 Session Initialisation Protocol (SIP)

Nachdem die grundlegenden Vermittlungs- und Transportprotokolle beschrieben wurden, wird
im Folgenden mit SIP (Session Initialisation Protocol, RFC 3261) das erste Signalisierungs-
Protokoll vorgestellt, das ausschließlich für VoIP und Multimedia Daten entwickelt wurde.
SIP wird, wie bereits erwähnt, zur Signalisierung benutzt (Kap.: 4.1). Unter Signalisierung ver-
steht man in diesem Zusammmenhang den Verbindungsaufbau einer Multimediakommunikati-
on zwischen zwei oder mehr Teilnehmern. SIP ist in Hinsicht auf das Internet und die zum Ent-
wicklungszeitpunkt bereits bestehenden Protokolle von ITEF entwickelt worden. Durch seine
HTTP (Hyper Transfer Protocol) ähnliche Struktur und die Teilnehmeridentifikation im URI-
Format (Uniform Resource Identifier) ist es sehr leicht zu verstehen. Erweiternd hat die Firma
Nokia den in RFC2806 (URLs for Telephone Calls) beschriebenen Adressmechanismus ein-
gebracht, welcher den Umgang mit Telefonnummern als URI beschreibt. In diesem Zusam-
menhang ist auch die DNS-Erweiterung (Domain Name Server Extension) ENUM (Telephone
Number Mapping, RFC 3761) zu erwähnen, die für SIP als VoIP-Signalisierungsprotokoll im-
mer wichtiger wird. Leichte Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibi-
lität sind maßgebliche Anforderungen, die das ITEF an das zu entwickelnde Protokoll gestellt
hat.
Nach dem Verbindungsaufbau einer sogenannten Session, die eine 1:1 ,1:n, n:n (n ∈ N ) Verbin-
dung darstellt, können beliebige Medienströme übertragen werden. Dies können beispielsweise
reine Audiodaten und Videodaten sein. Auch Medienströme wie Computerspiele, die Steuerda-
ten beinhalten, können übertragen werden.
Vorteile von SIP sind der offene Standard, der mittlerweile sehr große Verbreitung gefunden
hat, und die dezentrierte Struktur, die SIP unempfindlicher gegenüber Störungen im Internet
und Ausfällen von einzelnen SIP-Knotenpunkten macht. Ein weiterer Vorteil von SIP ist die
Möglichkeit der Modifizierung von etablierten Sitzungen. Dieses Verfahren wird im allgemei-
nen als Re-INVITE bezeichnet.
SIP hat jedoch auch einige Nachteile. Herkömmliche Telefon-Dienste werden in SIP nicht
vollständig abgebildet. Daraus resultiert ein weiteres Problem. Viele Hardware- und Softpho-
nehersteller implementieren Dienste, die in SIP laut RFC noch nicht vorgesehen sind. Die-
se Dienste werden dann meist von Geräten anderer Hersteller nicht unterstützt. Ein weiterer
Nachteil von SIP ist das verwendete RTP, welches wie schon beschreiben zur Übertragung der
Sprachdaten genutzt wird. RTP benutzt dabei im Allgemeinen UDP-Ports, die dynamisch ver-
geben werden. Dies erschwert die Verwendung von SIP in Verbindung mit Firewalls oder NAT
(Network Address Translation), da diese die dynamisch vergebenen Ports nicht der Signalisie-
rungsverbindung zuordnen können. Trotz dieser Nachteile wird SIP zunehmend benutzt. Dieser
Sachverhalt ist wohl hauptsächlich auf die Einfachheit und Übersichtlichkeit des Protokolls
zurückzuführen.
Da der SIP-Aufbau ein wesentlicher Bestandteil einer VoIP-Verbindung ist, wird im Folgenden
die Funktionsweise von SIP anhand eines einfachen Beispiels dargestellt. Der in der vorliegen-
den Diplomarbeit verwendete RTP-Generator benutzt SIP in ähnlicher Weise zum Sessionauf-
17
bau.
4.6.1 SIP-Elemente
Die Endpunkte einer SIP-Verbindung werden allgemein als UA (User Agent) bezeichnet. Ein
UA nimmt die Eingabe von einem Benutzer entgegen und baut eine Multimediasitzung auf oder
ab. Als UAC (User Agent Client) wird die Seite bezeichnet, die einen Request generiert und
versendet. Die Gegenstelle, die den Request annimmt und einen Response sendet, ist als UAS
(User Agent Server) bekannt. Ein UA muss beide Anwendungsformen beherrschen. Requests
und Responses werden mit Hilfe eines Proxy-Servers geroutet. Ein Proxy-Server nimmt Re-
quests von einem UAC oder Responses von einem UAS an und leitet sie weiter. Ein SIP-Proxy
muss dabei den SIP-Request nicht interpretieren können, um ihn weiterzuleiten.
4.6.2 SIP-Signalisierung
In der SIP-Signalisierung existieren sechs SIP-Methoden: INVITE, REGISTER, BYE, ACK,

CANCEL und OPTIONS. In Tabelle 8 sind jeweils kurze Beschreibungen der einzelnen Metho-
den dargestellt. Sieben weitere Methoden kommen durch RFC-Erweiterungen hinzu. Es handelt
sich dabei um die in Tabelle 9 genannten Methoden.
Beschreibung Aktion
INVITE Aufbau oder Modifizierung einer Session
REGISTER Registrierung eines Teilnehmers
BYE Beenden einer Session
ACK Bestätigung für eine Session
CANCEL Annulieren einer vorläufigen Session
OPTIONS Erfragen der Fähigkeiten eines UAs
Tabelle 8: Erklärung der SIP-Methoden
Methode Request for Comment (RFC)

INFO Erweiterung in RFC 2976
NOTIFY Erweiterung in RFC 2848
SUBSCRIBE Erweiterung in RFC 2848
UNSUBSCRIBE Erweiterung in RFC 2848
UPDATE Erweiterung in RFC 3311
MESSAGE Erweiterung in RFC 3428
REFER Erweiterung in RFC 3515
PRACK Erweiterung in RFC 3262
Tabelle 9: RFC der SIP-Erweiterungen
18
4.6.3 SIP-Request
Ein SIP-Request ist wie schon erwähnt die Anfrage eines SIP-Teilnehmers an einen anderen
Teilnehmer oder an einenen Proxy-Server. Bei diesem Vorgang werden die in Tabelle 8 be-
schriebenen Methoden genutzt.
4.6.4 SIP-Response
Ein SIP-Response ist die Antwort eines UAS- oder SIP-Servers auf den Request eines UAC. Ein
Response kann zusätzliche Header beinhalten, die vom UAC benötigt werden, oder er kann ei-
ne einfache Bestätigung sein, um dem UAC mitzuteilen, dass er den Request nicht noch einmal
senden muss. Viele Response-Nachrichten veranlassen den UAC zu weiteren Schritten. Respon-
ses werden in insgesamt sechs verschiedene Klassen eingeteilt. Die ersten fünf davon sind dem
HTTP entnommen, die sechste existiert nur für das SIP. Sie sind in Tabelle 10 aufgelistet (Lit.:
(24)).
Klasse Beschreibung Aktion

1xx Informational Request wurde empfangen und wird weiter verarbeitet.
2xx Success Request wurde erfolgreich empfangen.
3xx Redirection Server antwortet von einem anderen Aufenthaltsort. Der Client
sollte es mit der neuen Adresse wieder versuchen.
4xx Client Error Request kann nicht erfolgreich versendet werden auf Grund eines
Fehlers beim Client. Der Client muss an Hand des Fehlercodes
entscheiden, ob er den Request nochmal versendet.
5xx Server Failure Request konnte nicht erfolgreich versendet werden auf Grund ei-
nes Fehlers beim Server. Es kann versucht werden den Request
über einen anderen Server zu versenden.
6xx Global Failure Request konnte nicht erfolgreich versendet werden und sollte auf
keinen Fall nochmals über einen anderen Server versendet wer-
den.
Tabelle 10: Erklärung der SIP-Response Klassen
19
Abbildung 10: Struktur einer SIP-Nachricht
4.6.5 Anmeldung an einem SIP-Server
Im folgenden Beispiel ist die Anmeldung des Teilnehmers han@192.168.0.66 an den SIP-
Server dargestellt. Der SIP-Server prüft hier keine Authentifizierung.
Listing 1: SIP-Client Registrierungsanfrage am SIP-Server

1 S i p C l i e n t : Sending : 08:19:47.419
2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 REGISTER s i p : 1 9 2 . 1 6 8 . 0 . 6 6 SIP / 2 . 0
4 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 6 6 ; b r a n c h =z9hG4bK7F52986
5 CSeq : 5515 REGISTER
6 To : <s i p : han@192 . 1 6 8 . 0 . 6 6 >
7 E x p i r e s : 900
8 From : <s i p : han@192 . 1 6 8 . 0 . 6 6 >
9 C a l l −ID : 1003772897@192 . 1 6 8 . 0 . 6 6
10 C o n t e n t −L e n g t h : 0
11 User−Agent : kphone / 4 . 2
12 Event : r e g i s t r a t i o n
13 Allow−E v e n t s : p r e s e n c e
14 C o n t a c t : <s i p : han@192 . 1 6 8 . 0 . 6 6 ; t r a n s p o r t =udp >;
15 m e t h o d s =” INVITE , MESSAGE, INFO , SUBSCRIBE , OPTIONS , BYE, CANCEL, NOTIFY , ACK, REFER”
20
Die Antwort des SIP-Servers auf die Anmeldungsanfrage ist die Methode OK. Damit ist die
Anmeldung am Server erfolgreich abgeschlossen.
Listing 2: Antwort des SIP-Servers auf Registrierungsanfrage

1 S i p C l i e n t : Received : 08:19:47.423
2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 SIP / 2 . 0 200 OK
4 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 6 6 ; b r a n c h =z9hG4bK7F52986
5 CSeq : 5515 REGISTER
6 To : <s i p : han@192 . 1 6 8 . 0 . 6 6 > ; t a g = d 2 2 2 d 7 f 0 9 9 5 3 7 7 6 2 b c 9 4 f 7 b 1 8 9 1 8 c 6 3 0 . e2b8
7 From : <s i p : han@192 . 1 6 8 . 0 . 6 6 >
8 C a l l −ID : 1003772897@192 . 1 6 8 . 0 . 6 6
9 C o n t a c t : <s i p : han@192 . 1 6 8 . 0 . 6 6 ; t r a n s p o r t =udp >; e x p i r e s =900
10 S e r v e r : Sip EXpress r o u t e r ( 0 . 9 . 4 ( i386 / l i n u x ) )
11 C o n t e n t −L e n g t h : 0
4.6.6 SIP-Verbindungsaufbau und -abbau
Im folgenden Diagramm 12 ist beispielhaft der Verbindungsaufbau und -abbau zweier Soft-
phones (kphone) über den SIP-Server SER (SIP Express Router) des Fraunhofer Fokus Insti-
tuts18 zu sehen. In diesem Beispiel (Abb.: 11) ruft der am SIP Express Router (IP-Adresse
192.168.0.2) angemeldete Teilnehmer han@192.168.0.66 den Teilnehmer lea@192.168.0.103
an. Der Verbindungsaufbau beginnt mit Zeile 3396 der tethereal Aufzeichnung (Abb.: 12) und
endet in Zeile 21257. Im Bereich von 21267 bis 32411 ist die SIP-Verbindung aufgebaut und
die Kommunikation wird über RTP abgehandelt. Dies ist in dem Diagramm nur durch die UDP
Bestätigung zu vermuten. Ab Zeile 32412 der tethereal Aufzeichnungsdatei ist der Verbindungs-
abbau, der durch den Teilnehmer lea@192.168.0.103 initialisiert wurde, dargestellt. Der SIP-
Verbindungsabbau endet ordnungsgemäß in Zeile 32430 durch die OK Bestätigung des BYE.
18
Das Fraunhofer Institut für offene Kommunikationssysteme FOKUS ist eine Einrichtung der Fraunhofer Gesell-
schaft zur Förderung der angewandten Forschung e.V.
21
Abbildung 11: SIP und RTP -Datenstrom einer VoIP-Verbindung
Abbildung 12: SIP-Verbindungsaufbau und -abbau, erstellt mit callflow
Die folgenden Listings sind Auszüge aus dem SIP-Verbindungsaufbau. Es ist die Kommunika-
tion zwischen dem Anrufer han@192.168.0.66 (UAC) und dem SIP-Server 192.168.0.2 (UAS).
Die Auszüge beinhalten der Übersicht halber die SDP (Session Discription Protocol) Nachrich-
ten auf die im nächsten Unterkapitel noch genauer eingegangen wird. Weiter ist zu erkennen wie
der SIP-Server die Nachrichten unverändert an den angerufenen Teilnehmer lea@192.168.0.2
weiterleitet. Die Kommunikation zwischen dem SIP-Server 192.168.0.2 (UAC) und dem ange-
rufenen Teilnehmer lea@192.168.0.2 (UAS) verläuft analog zu den beschriebenen Methoden.
Es wurde deshalb auf das Listing verzichtet. Die Zeilenangaben beziehen sich auf die Abbil-
dung 12.
22
Listing 3: Methode INVITE (Zeile 3396)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 INVITE s i p : lea@192 . 1 6 8 . 0 . 1 0 3 SIP / 2 . 0
4 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 6 6 ; b r a n c h =z9hG4bK7CDAE767
5 CSeq : 973 INVITE
6 To : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 >
7 C o n t e n t −Type : a p p l i c a t i o n / s d p
8 From : <s i p : han@192 . 1 6 8 . 0 . 2 > ; t a g =29DAE0F5
9 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
10 S u b j e c t : s i p : han@192 . 1 6 8 . 0 . 6 6
11 C o n t e n t −L e n g t h : 228
13 C o n t a c t : <s i p : han@192 . 1 6 8 . 0 . 6 6 ; t r a n s p o r t =udp>
14
15 v=0
16 o= u s e r n a m e 0 0 IN I P 4 1 9 2 . 1 6 8 . 0 . 6 6
17 s =The Funky Flow
18 c=IN I P 4 1 9 2 . 1 6 8 . 0 . 6 6
19 t =0 0
20 m= a u d i o 32790 RTP / AVP 0 97 8 3
21 a= r t p m a p : 0 PCMU/ 8 0 0 0
22 a= r t p m a p : 3 GSM/ 8 0 0 0
23 a= r t p m a p : 8 PCMA/ 8 0 0 0
24 a= r t p m a p : 9 7 iLBC / 8 0 0 0
25 a= f m t p : 9 7 mode=30
Listing 4: Response 100 trying (Zeile 3415)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 SIP / 2 . 0 100 t r y i n g −− y o u r c a l l i s i m p o r t a n t t o u s
5 CSeq : 973 INVITE
6 To : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 >
7 From : <s i p : han@192 . 1 6 8 . 0 . 6 6 > ; t a g =29DAE0F5
8 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
9 S e r v e r : Sip EXpress r o u t e r ( 0 . 9 . 4 ( i386 / l i n u x ) )
10 C o n t e n t −L e n g t h : 0
Listing 5: Response 180 Ringing (Zeile 3473)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 SIP / 2 . 0 180 R i n g i n g
6 CSeq : 973 INVITE
7 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
8 To : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 > ; t a g =6556E8B6
9 C o n t e n t −L e n g t h : 0
11 C o n t a c t : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 ; t r a n s p o r t =udp>
12 Record−R o u t e : <s i p : 1 9 2 . 1 6 8 . 0 . 2 ; f t a g =29DAE0F5 ; l r =on>
Listing 6: Response 200 Ok (Zeile 21218)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 SIP / 2 . 0 200 OK
23

6 CSeq : 973 INVITE
7 C o n t e n t −Type : a p p l i c a t i o n / s d p
8 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
9 To : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 > ; t a g =6556E8B6
10 C o n t e n t −L e n g t h : 230
13 Record−R o u t e : <s i p : 1 9 2 . 1 6 8 . 0 . 2 ; f t a g =29DAE0F5 ; l r =on>
14
15 v=0
16 o= u s e r n a m e 0 0 IN I P 4 1 9 2 . 1 6 8 . 0 . 1 0 3
18 c=IN I P 4 1 9 2 . 1 6 8 . 0 . 1 0 3
19 t =0 0
20 m= a u d i o 32784 RTP / AVP 0 97 8 3
21 a= r t p m a p : 0 PCMU/ 8 0 0 0
22 a= r t p m a p : 3 GSM/ 8 0 0 0
23 a= r t p m a p : 8 PCMA/ 8 0 0 0
24 a= r t p m a p : 9 7 iLBC / 8 0 0 0
25 a= f m t p : 9 7 mode=30
Listing 7: Methode ACK (Zeile 21257)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 ACK s i p : lea@192 . 1 6 8 . 0 . 1 0 3 ; t r a n s p o r t =udp SIP / 2 . 0
5 CSeq : 973 ACK
6 To : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 > ; t a g =6556E8B6
8 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
9 R o u t e : <s i p : 1 9 2 . 1 6 8 . 0 . 2 ; f t a g =29DAE0F5 ; l r =on>
10 C o n t e n t −L e n g t h : 0
Der SIP-Sessionaufbau ist hiermit beendet. Der RTP-Datenstrom zwischen Anrufer

han@192.168.0.66 und angerufenem Teilnehmer lea@192.168.0.103 überträgt die Audioda-
ten des VoIP-Telefonats. lea@192.168.0.103 beendet nach einiger Zeit das Telefongespräch. Es
folgt der SIP-Verbindungsabbau.
Listing 8: Methode BYE (Zeile 32412)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 BYE s i p : han@192 . 1 6 8 . 0 . 6 6 ; t r a n s p o r t =udp SIP / 2 . 0
4 Max−F o r w a r d s : 12
5 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 2 ; b r a n c h =z9hG4bKc962 . b72208d . 0
6 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 1 0 3 ; b r a n c h =z9hG4bK589C2F2F
7 CSeq : 802 BYE
8 To : <s i p : han@192 . 1 6 8 . 0 . 6 6 > ; t a g =29DAE0F5
9 From : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 > ; t a g =6556E8B6
10 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
11 C o n t e n t −L e n g t h : 0
24
Listing 9: Response Ok (Zeile 32430)

2 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
3 SIP / 2 . 0 200 OK
4 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 2 ; b r a n c h =z9hG4bKc962 . b72208d . 0
5 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 1 0 3 ; b r a n c h =z9hG4bK589C2F2F
6 From : <s i p : lea@192 . 1 6 8 . 0 . 1 0 3 > ; t a g =6556E8B6
7 CSeq : 802 BYE
8 C a l l −ID : 1064804091@192 . 1 6 8 . 0 . 6 6
9 To : <s i p : han@192 . 1 6 8 . 0 . 6 6 > ; t a g =29DAE0F5
10 C o n t e n t −L e n g t h : 0
Die SIP Verbindung wurde ordnungsgemäß abgebaut.
4.6.7 Session Description Protocol (SDP)
Bei SDP (Session Description Protocol, RFC 2327) handelt es sich nicht um ein eigenständiges
Protokoll, sondern vielmehr ist SDP in SIP eingebettet. In Listing 3 ist zu erkennen, dass SDP-
Daten im SIP eingebettet sind. SDP hat die Aufgabe, die zwischen den Endpunkten zu verwen-
denden Codecs, Transportprotokolle und Übertragungsparameter auszuhandeln. Das folgende
Listing ist ein Auszug aus dem Listing 3 und führt die SDP-Flags auf.
Listing 10: SDP-Flags aus Listing 3

15 v=0
16 o= u s e r n a m e 0 0 IN I P 4 1 9 2 . 1 6 8 . 0 . 6 6
18 c=IN I P 4 1 9 2 . 1 6 8 . 0 . 6 6
19 t =0 0
20 m= a u d i o 32790 RTP / AVP 0 97 8 3
21 a= r t p m a p : 0 PCMU/ 8 0 0 0
22 a= r t p m a p : 3 GSM/ 8 0 0 0
23 a= r t p m a p : 8 PCMA/ 8 0 0 0
24 a= r t p m a p : 9 7 iLBC / 8 0 0 0
25 a= f m t p : 9 7 mode=30
Die Informationen des SDP werden vom SIP-Server verarbeitet. Darüber hinaus umfassen die
SDP-Nachrichten den Sitzungsnamen, Informationen über den Empfang der Sitzung und me-
dienunterstützende Informationen.
25
In den folgenden Tabellen werden die SDP-Felder beschrieben:
Flag Beschreibung
v Protokoll Version
o Ersteller der Session und Session-Identifizierung
s Name der Session
i zusätzliche Session-Informationen (optional)
u URI mit der weiterführenden Beschreibung (optional)
e E-Mail-Adresse (optional)
p Telefon Nummer (optional)
c Verbindungsinformation (wird nicht benötigt, falls bei allen Medien angegeben, op-
tional)
b Information über die Bandbreite (optional)
Eine oder mehrere Zeit-Beschreibungen (Tab.: 12)
z Zeitzonen-Anpassungen (optional)
k Verschlüsselungsschlüssel (encryption key) (optional)
a ein oder mehrere Session Attribute (optional)
Keine oder mehrere Medien-Beschreibungen (Tab.: 13)
Tabelle 11: Medien-Flags im SDP-Feld (RFC 2327)
Flag Beschreibung
t Zeit, während der die Session aktiv ist
r keine oder mehr Wiederholungen (optional)
Tabelle 12: Beschreibung der möglichen SDP-Zeit-Flags (RFC 2327)
Flag Beschreibung
m Medienname und Adresse für den Medientransport, in der Regel IP-Adresse und
Port
i Titel des Mediums (optional)
c Verbindungs-Informationen, optional wenn diese nicht in der Session definiert sind
(s. o, optional)
b Information über die Bandbreite (optional)
k Verschlüsselungsschlüssel (encryption key, optional)
a ein oder mehrere Session-Attribute (optional)
Tabelle 13: Beschreibung der möglichen SDP-Medien-Flags (RFC 2327)
26
4.7 Störfaktoren bei VoIP 4 GRUNDLAGEN
4.7 Störfaktoren bei VoIP

Im folgenden Kapitel wird auf die Störfaktoren eingegangen, die bei der paketorientierten
Sprachübermittlung über das Internet auftreten können. Die Faktoren Delay, Jitter und Packet
Loss können auf IP-Ebene ermittelt werden. Echos können im Gegensatz dazu nur im Audioda-
tenstrom gemessen werden.
Eine schematische Übersicht über die Störfaktoren kann der Abbildung 13 entnommen werden.
Anhand dieser Vereinfachung soll der Zusammenhang zwischen den Störfaktoren dargestellt
werden. Als Vergleich dient ein Rohr, das die Datenleitung darstellt.
Abbildung 13: Schaubild der IP-spezifischen Parameter
4.7.1 Echo
Jeder Teilnehmer eines Gesprächs kann seine Stimme hören – zum einen direkt durch die Luft
vom Mund zum Ohr, und zum anderen durch die Resonanz des Schädels. Bei einem Telefon-
oder VoIP-Gespräch kommen noch zwei weitere Möglichkeiten hinzu. Eine ist die gedämpfte
Rückkopplung des vom Mikrofon aufgezeichneten Signals auf den Kopfhörer oder die Hör-
muschel. Diese Sprachrückkopplung ist gewollt. Die zweite tritt durch die Übertragung der
Stimme im technischen System auf und ist meistens mit einer bemerkbaren Laufzeitverzögerung
verbunden. Diese wird in der Regel als sehr störend empfunden und wird als Echo bezeichnet.
Man unterscheidet zwischen Sprecherecho (talker echo) und Hörerecho (listener echo).
Bei dem Sprecherecho hört der Sprecher seine eigene Stimme verzögert und stark gedämpft.
Dieses Echo wird durch die Reflektion der Sprache beim Gesprächspartner erzeugt. Bei Über-
gängen zwischen Telefonnetzen, zum Beispiel VoIP auf analoges PSTN, wird das Echo in der
Richtungstrenneinheit (Gabelschaltung oder Hybrid genannt) erzeugt. Ursache ist die physikali-
sche Drahtwandlung in der Vermittlungsstelle. Diese ist nicht genau auf den Wellenwiderstand
angepasst und erzeugt Leitungsreflektionen, die sich für den Hörer als Echo bemerkbar ma-
chen. Das ursprüngliche Signal ist allerdings stark gedämpft. Viel größere Echo-Quellen sind
beispielsweise Freisprechanlagen bei Mobiltelefonen oder die Verwendung eines im Laptop
27
eingebauten Lautsprechers und Mikrofons, welches ebenfalls eine Art Freisprecheinrichtung

darstellt. In diesem Fall wird das Signal rückgekoppelt und erreicht den Sender nach circa dop-
pelter Sender-Empfänger-Laufzeit (Kap.: 4.7.2) erneut. Dies wird als sehr störend empfunden,
lässt sich aber leicht durch die Verwendung von Headsets vermeiden.
Als Hörerecho wird das Hören des Kommunikationspartners und dessen verzögertes und gedämp-
ftes Echo bezeichnet. Dies wird ebenfalls als sehr störend wahrgenommen, und lässt sich nur
sehr schwer vermeiden.
4.7.2 Delay
Als Delay wird die Verzögerung von Datenpaketen und damit die Verzögerung der in den Pa-
keten enthaltenen Sprachdaten bezeichnet. Delay ist ein wichtiger Faktor bei der Bestimmung
der Dienstgüte in VoIP-Netzen und kann in die folgenden Kategorien unterteilt werden:
• Algorithmische Verzögerung, die durch Eigenschaften des zur Verarbeitung oder Übertragung des
Signals verwendeten Kodier-Algorithmus entsteht.
• Verarbeitungsverzögerung, die durch die zur Weiterverarbeitung des Signals benötigte Zeit be-
stimmt ist.
• Serialisierungsverzögerung, die Zeit, die notwendig ist, um eine Dateneinheit komplett auf das
Medium zu schicken.
• Ausbreitungsverzögerung, die durch Signallaufzeiten in Leitungen oder Luft entsteht.
In der vorliegenden Diplomarbeit werden ausschließlich Paketlaufzeiten gemessen. Die Paket-

laufzeit setzt sich aus der Summe der Verarbeitungs- und der Ausbreitungsverzögerung zusam-
men. Algorithmische und Serialisierungsverzögerung können vernachlässigt werden. In diesem
Zusammenhang ist zu erwähnen, dass Verarbeitungsverzögerungen sowohl auf der Sende- und
Empfangsseite auftreten wie auch im Netzwerk, wenn zum Beispiel Jitter Buffer19 (Queueing
Delay) zur Zwischenspeicherung der Pakete verwendet werden. Ausbreitungsverzögerung und
Verarbeitungsverzögerung im Netzwerk werden als Transportverzögerung zusammengefasst.
Auf die Verarbeitungsverzögerungen, die durch die einzelnen Prozesse hervorgerufen werden,
wird im Kapitel 6 noch einmal genauer eingegangen.
Da VoIP im Telekommunikationsbereich immer mit dem herkömmlichen PSTN-Netz vergli-
chen wird, lohnt ein Blick auf die dort festgelegten Richtwerte. Für die nationalen Festnetze
wurde die Ende-zu-Ende-Verzögerung auf einen Wert von 25 ms festgelegt. Der internationale
Verkehr ist mit 100 ms standardisiert, da dort die Ausbreitungsverzögerung, wie zum Beispiel
bei einer Satellitenverbindung, wesentlich größer ist. Bei der Sprachübertragung über das In-
ternet sind allein die Paketlaufzeiten und somit auch die Delay-Zeiten schon deutlich höher,
wie man mit einem einfachen Test mit dem Befehl ping schon erkennen kann. Dabei ist die
Paketverzögerung eines ping-Aufrufs jedoch nicht mit der Sprachverzögerung zu verwechseln.
19
Jitter-Buffer ist ein Speicher, in dem IP-Pakete zwischengespeichert und anhand des Timestamp geordnet werden.
28
Bei der Verwendung von Sprachcodecs ist auch von Bedeutung, wie lange ein RTP-Paket
benötigt, bis der Payload mit Sprachdaten gefüllt ist. Bei dem Codec G.711 ist diese Zeit bei
einer Paketgröße von 160 Byte 20 ms. Steigt jedoch der Grad der Komprimierung, steigt auto-
matisch auch die Aufzeichnungszeit, die pro Datenpaket übertragen wird. Bei der Verwendung
kleiner Datenpakete hingegen steigt der Overhead des Protokoll-Headers proportional zum Pay-
load an und setzt der Paketgröße eine wirtschaftliche Untergrenze.
Im Kapitel 4.9 wird auf die Interaktion von Gesprächspartnern und die daraus folgenden Forde-
rungen an die Delay-Zeiten bei VoIP-Übertragungen näher eingegangen. Abbildung 14 veran-
schaulicht den Zusammenhang zwischen Verarbeitungsverzögerung und Transportverzögerung.
Die Abbildung enthält außerdem weitere Informationen, auf die zu einem späteren Zeitpunkt
noch näher eingegangen wird.
Abbildung 14: Verarbeitungsverzögerung und Transportverzögerung
Flag Beschreibung
round trip delay in host time Beschreibt die Paketumlaufzeit wie sie von der Ap-
plikation aufgezeichnet wird und beinhaltet alle Ver-
arbeitungszeiten
round trip delay in wire time Paketumlaufzeit ohne Enpfangs- und Verarbeitungs-
zeiten
one way delay in wire time Zeitspanne, die zwischen der Sendeprozessverarbei-
tung und dem Eintreffen des Pakets beim Empfänger
vergeht
T Delay Zeiten (host time)
Tabelle 14: Erklärung der Felder der Grafik Verarbeitungsverzögerung und Transport-
verzögerung
29
4.7.3 Jitter
Jitter wird als die Varianz der Latenzzeit bei der Übertragung von Datenpaketen bezeichnet,
oder anders ausgedrückt, als die durchschnittliche Schwankung der Verzögerungszeiten in pa-
ketvermittelten Übertragungssystemen. Ursache für Jitter können Schwankungen bei der Verar-
beitung in einem Netzelement sein oder unterschiedliche Paketwege durch das Übertragungs-
netzwerk. Da die paketvermittelte Übertragung über das Internet auch das Überholen von Pa-
keten (Sequenzfehler)20 zulässt, muss spätestens am Ende der Übertragungsstrecke die Pake-
treihenfolge wieder hergestellt werden. Dies geschieht durch einen Jitter-Buffer, der die Da-
tenpakete zwischenspeichert und anhand ihrer Sequenznummern sortiert. Wird ein zeitlicher
Schwellwert überschritten, wird das Paket verworfen. Oft ist es schon im Netzwerk nötig, den
Jitter zu begrenzen. Aus diesem Grund besitzen viele aktive Netzkomponenten, wie unter an-
derem Router, einen Jitter-Buffer, der in vordefinierten Grenzen konfiguriert werden kann. Eine
typische Konfiguration ist 30 ms bis 50 ms. In anpassungsfähigen Netzen kann der Jitter-Buffer
auch 100 ms bis 200 ms betragen. Ein Jitter von bis zu 100 ms wird als akzeptabel angenommen.
Zu beachten ist aber, dass Jitter-Buffer signifikant die Verzögerungszeiten beinflussen.
In der RFC 3550, in der RTP (Kap.: 4.5) beschrieben wird, ist auch eine Berechnung für Jitter
aufgeführt. Zuerst muss das Delay (Kap.: 4.7.2) D bestimmt werden:
D(i, j) = (Rj − Ri) − (Sj − Si) = (Rj − Sj) − (Ri − Si)
Si ist der RTP-Zeitstempel für das Paket i. Ri ist der RTP-Zeitstempel für das Paket i bei der
Ankunft. j ist das Folgepaket von i. Nach der Berechnung von D kann der Jitter J bestimmt
werden:
(|D(i − 1, i)| − Jalt )

J = Jalt +
16
In dieser Formel ist i − 1 das vorherige Paket und i das aktuelle Paket. Diese Formel dient als
Berechnungsgrundlage für die Jitterberechnung in der vorliegenden Diplomarbeit. Anzumerken
ist, dass das VQmon-Modell (Kap.: 4.9.3) eine erweiterte Jitter-Berechnung enthält.
4.7.4 Packet Loss
Unter Paketverlust (Packet Loss) versteht man den Verlust einzelner Datenpakete eines zusam-
menhängenden Datenstroms. Ursachen für den Paketverlust können Netzstörungen, Ablauf der
TTL (Time To Live) oder das Verwerfen des Pakets durch einen Jitter-Buffer sein. Das TCP
kann Paketverluste wahrnehmen und fordert das Neuversenden des verlorengegangenen Pakets
vom Sender an. UDP bietet für Paketverluste keine Schutzmaßnahmen. Da Sprachübertragung
in UDP-Netzen fast ausschließlich über RTP, das auf UDP basiert, stattfindet, ist es wichtig, den
Paketverlust so gering wie möglich zu halten.
20
Sequenzfehler treten auf, wenn die Pakete beim Empfänger nicht, in der durch die Sequenznummer vorgegebenen
Reihenfolge, ankommen.
30
Wird bei der Sprachübertragung ein Codec benutzt, der Sprachdaten komprimiert, steigt die Ge-
wichtung eines verlorengegangenen Pakets. Entsteht bei einem G.711 Codec durch den Verlust
eines Datenpakets eine Lücke von 20 ms in der Sprachwiedergabe, sind diese bei der Verwen-
dung von Codecs mit Komprimierung circa drei- bis sechsmal so groß. Bei manchen Codecs
werden die verlorenen Datenpakete durch künstliche Datenpakete mit Zufallswerten ersetzt, um
das sehr störende Knacken im Hörer des Empfängers zu vermeiden. Paketverluste wirken sich
in starkem Maß auf die Dienstgüte der Sprachverbindung aus. Dies wird im weiteren Verlauf
der vorliegenden Diplomarbeit noch verdeutlicht.
31
4.8 Quality of Service (QoS) 4 GRUNDLAGEN
4.8 Quality of Service (QoS)

Bei der Übertragung von VoIP-Daten über das Internet bauen die verwendeten Protokolle und
Dienste auf der Transportschicht des ISO OSI-Schichtmodells (Abb.: 2) auf. Um die Qualität
der Dienstgüte beurteilen zu können, müssen sowohl die Übertragungsgüte der Sprache als auch
die IP-spezifischen Parameter berücksichtigt werden. Innerhalb eines Übertragungskanals kann
es erforderlich sein, die QoS für bestimmte Datenströme zu Lasten anderer zu erhöhen. Dies
gilt auch für Datenströme gleicher Art. Ermöglicht wird es beispielsweise durch die Priorisie-
rung von IP-Datenpaketen anhand bestimmter Merkmale und Eigenschaften. In diesem Kapitel
werden Möglichkeiten zur Priorisierung von Datenströmen näher beschrieben. Eigenschaften
der Priorisierung im Übertragungsnetz können dann mit der zu entwickenlnden Applikation
gemessen werden.
4.8.1 Priorisierung von MAC-Frames
In lokalen Netzen ist es möglich, auf Ethernet-Basis, ISO OSI-Modell Schichtebene 2 (Abb.:
2), verschiedene Prioritäten für sogenannte MAC-Frames (Media Access Control Frames) zu
setzen. Es können 3-User-Priority-Bits im VLAN-Tag des MAC-Header (RFC 1042) gesetzt
werden, um eine Priorisierung der MAC-Frames zu erreichen. Beschrieben wird das Priorisieren
von MAC-Frames in den Standards IEEE 802.1p und IEEE 802.1Q.
Die als Sprache priorisierten Frames bekommen in Switchen des lokalen Netzwerks Vorrang,
und ihre Übermittlungszeit wird reduziert. Sollen Daten über das lokale Netzwerk hinaus über-
tragen werden, müssen die Prioritäten des MAC-Frames im TOS/DS-Feld des IP-Datagramms
abgebildet werden.
4.8.2 Type Of Service (TOS)
Hinter dem TOS (Type Of Service, RFC 1349) -Konzept steht der Gedanke, Wege durch das
Internet als mehr oder weniger rentabel zu bezeichnen. Die Rentabilität einer Strecke hängt
stark von der verwendeten Applikation ab. Strecken, die viele Netzwerkkomponenten haben,
benutzen oft Zwischenspeicher, um den Jitter (Kap.: 4.7.3) zu minimieren. Das hat jedoch fol-
genden Nachteil: Durch die Jitter-Buffer steigt automatisch die Verzögerungszeit. Das ist für
Echtzeitanwendungen sehr störend. Die Internetkomponenten selbst können aus diesem Grund
nicht automatisch, das heißt eigenständig, die günstigste Strecke herausfinden, sondern man
muss anhand der Applikation auf höherer Ebene bereits abwägen, welche Anforderungen an
das Netz gestellt werden.
Die Möglichkeit, TOS zu verwenden, war in der IP-Spezifikation von Beginn an vorgesehen,
wurde aber in der Vergangenheit kaum genutzt. Routing-Protokolle wie OSPF und IS-IS bein-
halten schon lange die Option, Pakete anhand ihrer TOS zu routen.
Die Idee, die TOS zugrunde liegt, ist, dass der Endanwender nicht die Möglichkeit hat, den
TOS-Wert zu ändern. Sonst würden sicherlich in kürzester Zeit alle Benutzer die höchste Prio-
rität für ihre Internetdienste wählen. Dies würde dem Gedanken einer dienstorientierten Prio-
32
risierung entgegenwirken und ein Güteklassenkonzept innerhalb eines Diensts fast unmöglich
machen.
Für TOS sind 8 Bit im IPv4-Datagramm re-
serviert, die in drei Felder unterteilt sind. Die
ersten 3 Bit sind als Precedence definiert. Vor-
gabewerte sind der Tabelle 15 zu entnehmen.
Das Precedence-Feld bezeichnet die Dring-
lichkeit des IP-Datagramms. Das zweite Feld
Abbildung 15: TOS-Datagramm (RFC 1349)
ist als TOS gekennzeichnet und ist das Haupt-
feld des TOS-Oktetts. Es gibt Auskunft über das Abwägen von Datendurchsatz (Throughput),
Verzögerung (Delay), Ausfallsicherheit (Reliability) und Kosten (Cost). In der Vergangenheit
gab es einige Unklarheiten über die Größe dieses TOS-Felds. RFC 791 deklariete es als 3-Bit-
Feld. Nach RFC 1349 besitzt das TOS-Feld heute 4 Bit. Das dritte Feld wird als MBZ (Must
Be Zero) definiert und wird derzeit nicht genutzt.
HEX Wert Bit Matrix Deklaration

0x1 001 Priority
0x5 101 Internetwork Control
0x6 110 Traffic Routing
0x7 111 Network Control
Tabelle 15: Vordefinierte Precedence-Werte
HEX Wert Bit Matrix Deklaration Beispielprotokoll

0x10 1000 minimiere Verzögerung ftp, telnet, ssh, VoIP
0x08 0100 maximiere Durchsatz ftp-data, www
0x04 0010 maximiere Rentabilität snmp, dns
0x02 0001 minimiere Kosten nntp, smtp
0x00 0000 normaler Service (default) andere
Tabelle 16: Zuordnung und vordefinierte TOS-Werte und mögliche Anwendungsprotokolle
Die in Tabelle 16 angezeigten binären Werte werden als TOS-Werte bezeichnet. 0000 kommt
die Sonderrolle des Default-Werts zu. TOS ist als Integer-Wert festgelegt. Logische AND und
OR Operatoren auf zwei TOS-Werte sind nicht zulässig. In TOS sind auch alle weiteren, hier
nicht aufgeführten Kombinationen zulässig.
4.8.3 Differentiated Services (DiffServ)
DiffServ (Differentiated Services, RFC 2474 und 2475) beschreibt ein weiteres QoS-Verfahren
zur Priorisierung von IP-Datenpaketen. Die Daten werden hierbei nur am Eingang des DiffServ-
Netzes bearbeitet und in festgelegte QoS-Klassen eingeteilt. Dazu wird das DSCP-Feld (Abb.:
16) (Differentiated Services Code Point Field) im DiffServ-Header entsprechend markiert.
33
DiffServ nutzt zur Signalisierung der Priorität die ersten 6 Bit des schon vorhandenen TOS-
Byte im IP-Datagramm des IPv4 (Abb.: 3) oder das Traffic Class Field im IP-Datagramm des
IPv6 (Abb.: 4). Die Priorisierung dient dazu, die einzelnen Datenströme eines Verkehrsbündels
auseinander zu halten. Das DSCP-Feld hat im Gegensatz zu TOS eine Länge von 6 Bit und
kann daher 26 =64 Klassen repräsentieren. Diese werden in der Regel aber nicht alle ausge-
nutzt, da bestehende Transportnetze, wie beispielsweise ATM-Netze (Asynchronous Transfer
Mode Networks)21 Bei DiffServ sind die Dienste in wenige QoS-Klassen unterteilt, wobei jeder
Dienstklasse ein Satz an Regeln zur Verfügung steht.
Die Klassifizierung der IP-Pakete nach DiffServ geschieht durch das Setzen der DSCP-Bits.
Dies kann entweder durch eine Applikation im Quell-Rechner geschehen, oder es kann durch
einen Router am Eingang des Transitnetzes vorgenommen werden. IP-Pakete mit gleichem
DSCP-Wert bilden einen Strom von IP-Paketen, der im Netz gleich behandelt wird. Es muss
eine Instanz geben, die eine Zuweisung von DSCP-Wert und Netzdienst übernimmt. Um die
Behandlung der IP-Pakete nach DiffServ zu spezifizieren, werden Behandlungsklassen, die
sogenannten PHB’s (Per Hop Behaviours), eingeführt. Oft werden einer Behandlungsklasse
mehrere DSCP-Werte zugeordnet. Ein PHB-Wert entspricht einer CoS (Class of Service) ei-
nes Übermittlungsnetzes. PHB bestimmt das Verhalten eines Routers beim Weiterleiten der
IP-Pakete unter Berücksichtigung des DSCP-Werts.
DiffServ wurde entwickelt, um QoS-Anfor-
derungen in Backbone- bzw. Transit-IP-Netzen
sicherzustellen. Ein DiffServ IP-Netz, beispiels-
weise ein Unternehmensnetz oder das Netz
eines NSP (Network Service Provider), bildet
eine DiffServ-Domäne (DiffServ-Domain). In
Abbildung 16: DiffServ-Datagramm (RFC
dieser Domäne ist die Art und Weise der QoS-
2474)
Unterstützung in Form eines SLA (Service
Level Agreement) festgelegt. Es sind folgen-
de Typen von Routern zu unterscheiden: Eingangsrouter, interner Router und Ausgangsrouter.
Eingangsrouter (Ingress Router) übernehmen die Unterteilung in Klassen. Jede Klasse wird
mit einer Angabe im DS-Feld markiert. Die durchschnittliche Datenrate wird über die mittlere
Anzahl der Datenpakete pro festgelegter Zeiteinheit abgeschätzt. Sobald die vereinbarte Band-
breite überschritten wird, werden einige IP-Pakete am Netzeingang direkt verworfen (dropping)
oder kurz verzögert (shaping). Auf diese Weise wird eine Zugangskontrolle realisiert, um die für
die Klasse von IP-Paketen vereinbarte Bandbreite zu gewährleisten. Im internen Router (Interi-
or Router) findet keine Zugangskontrolle statt. Pakete werden gemäß ihrer Klasse in leitungs-
abhängige Warteschleifen eingereiht (queueing). Ausgangsrouter (Egress Router) können den
Datenverkehr formen (shaping). Hier kann zum Beispiel ein Jitter-Ausgangszwischenspeicher
dazu führen, dass die IP-Pakete die DiffServ-Domäne im gleichen Abstand verlassen.
Eine Vernetzung von mehreren DiffServ-Domänen bildet eine DiffServ-Region. Zu erwähnen
ist noch, dass die QoS-Anforderungen an die gesamte Ende-zu-Ende-Strecke nicht erfüllt wer-
21
ATM ist eine Technik, bei der der Datenverkehr in kleinen Pakete, auch Zellen genannt, übertragen wird. Die
Pakete haben eine feste Länge von 53 Byte.
34
4.9 Messungen der Sprachqualität 4 GRUNDLAGEN
den, sobald die Kommunikation über ein IP-Teilnetz verläuft, in dem kein DiffServ unterstützt
wird.
4.8.4 Integrated Services (IntServ)
IntServ (Integrated Services, RFC 1633) ist ein weiteres Verfahren zur Parameterisierung von
IP-Datenpaketen und somit zur QoS-Sicherstellung. Um dies zu erreichen, wird bei dem IntServ-
Modell davon ausgegangen, dass die zur Verfügung stehenden Ressourcen explizit verwaltet
werden müssen, so dass keine Dienstgarantien ohne Ressourcen-Reservierung erfolgen kann
und dass die Ende-zu-Ende-Verzögerungen begrenzt werden müssen. Bei IntServ fragt der Host
bei den Routern im Internet oder im Intranet an, ob die Ressourcen für einen Verkehrsfluss vom
Sender zum Empfänger vorhanden sind. Danach stellen die Vermittlungssysteme die Verbin-
dung in der gewünschten Qualität her und halten sie bis zum Übertragungsende aufrecht. Das
Konzept sieht mehrere Prioritätsklassen vor, die unterschiedlichen QoS-Klassen entsprechen.
4.9 Messungen der Sprachqualität

Für eine genaue Qualitätsbestimmung von Sprache ist ein Grundverständnis über die Messtech-
niken, wie Sprache analysiert wird, notwendig. Wie schon erwähnt, unterliegen IP-Sprachüber-
tragungen Fehlerquellen wie Verzerrung, zu hohe, oder niedrigem Signalpegel, Lücken in der
Sprachübertragung und eine Vielzahl anderer Probleme. Messungen der Sprachqualität kann
man in drei Kategorien unterteilen. Listening Quality bezieht sich auf die Qualitätsbeurteilung
eines Teilnehmers, der einer VoIP-Übertragung zuhört. Dies kann zum Beispiel auch ein Ra-
diostream sein. Conversational Quality ist die vom Teilnehmer eingeschätzte Qualität eines
VoIP-Gesprächs. Es beinhaltet jegliche Form von Echo oder Delay-ähnlichen Störungen, die
während der Übertragung auftreten. Transmission Quality stellt die Netzwerkqualität dar und
ist schon mehrfach als IP-spezifische Parameter bezeichnet worden. Hier wird die Fähigkeit des
verwendeten Netzwerks, Sprachsignale zu übertragen, beurteilt.
Um eine objektive Aussage über die Sprachqualität machen zu können, ist die Abschätzung
einer oder mehrerer dieser Kategorien notwendig. Diese kann über objektive oder subjektive
Messmethoden stattfinden.
4.9.1 Listening Quality und MOS (Mean Opinion Score)
Die zeitaufwendigste Messmethode ist die subjektive Vorgehensweise. In diesem Verfahren

werden einer statistisch repräsentativen Anzahl von Teilnehmern Audiodateien vorgespielt. Die
Messungen müssen nach den Hauptgütekriterien Reliabilität22 und Validität23 stattfinden, so
dass eine Messreihe beliebig oft mit unterschiedlichen Probanden wiederholt werden kann.
22
Die Reliabilität beschreibt die Genauigkeit, mit der ein Test eine Merkmalsdimension erfasst, und zwar unter der
Vernachlässigung des Umstandes, ob es sich dabei auch um die Merkmalsdimension handelt, deren Erfassung
intendiert ist.
23
Allgemein bezeichnet die Validität das Maß an Genauigkeit, mit dem der Test dasjenige Persönlichkeits- oder
Verhaltensmerkmal misst, das er messen soll oder zu erfassen vorgibt.
35
Die Teilnehmer beurteilen dann die Listening Quality der vorgespielten Audiosamples. Diese
Form subjektiver Messung wird als ACR (Absolute Category Rating) bezeichnet. Dabei wird
die Sprachqualität in fünf Beeinträchtigungsstufen unterteilt, welche in Tabelle 17 vorgestellt
werden. Der Mittelwert jeder Sample-Messung bildet den MOS-Wert. Zur Bestimmung des
MOS-Werts sollten mindestens 16 Probanden beiden Geschlechts herangezogen werden.
Rating Sprachqualität Störungswahrnehmung

5 excellent nicht wahrnehmbar
4 good kaum wahrnehmbar, nicht störend
3 fair wahrnehmbar, leicht stören
2 poor störend
1 unsatisfactory sehr störend, unangenehm
Tabelle 17: MOS-Qualitätsklassen
Bei der Bestimmung eines Werts wie dem MOS-Wert ist zu bedenken, dass dieser Wert subjek-
tiv ist. Die Messergebnisse können deshalb deutlich schwanken. Wie schon im Kapitel 4.5.2 in
der Tabelle 7 aufgeführt, wird einem Codec oft ein MOS-Wert zugeordnet.
Die von der Industrie zur Bestimmung des MOS-Werts benutzen Sprachsamples basieren auf
phonetisch ausgeglichenen Texten. Sie beinhalten Laute, die typisch für die jeweilige Spra-
che sind. Außerdem werden Aufzeichnungsgeräte mit 16 Bit oder mehr verwendet, welche auf
normierte Pegel und Signalcharakteristik geeicht sind. Das ITU und OSR (Open Speech Repo-
sitory) stellen solche Sprachsamples zur Verfügung.
Als Ergänzung zu ACR werden andere subjetive Messmethoden benutzt. DCR (Degradation
Category Rating) und CCR (Comparison Category Rating) sind Beispiele dafür. DCR bewer-
tet den Grad der Veränderung der beeinträchtigten Audiosamples und liefert den sogenannten
DMOS-Wert. CCR vergleicht zwei Dateien vor und nach der Übertragung mittels VoIP und bil-
det daraus den CMOS-Wert. D und C vor MOS stehen jeweils für das verwendete Messverfah-
ren DCR und CCR. Um zwischen Listening und Conversational Auswertungen unterscheiden
zu können, führte das ITU die Bezeichnungen MOS-LQ für MOS Listening Quality und MOS-
CQ für MOS Conversation Qualtity ein. Zusätzlich wurde noch der Suffix S, O und E etabliert,
die für (S)ubjective, (O)bjective und (E)stimated stehen.
4.9.2 Conversational Quality und Perceptual Speech Quality Measure (PSQM)
Zur Bestimmung der Sprachqualität während einer Konversation müssen Probanden typische
Kommunikationsszenarien durchspielen. Kommunikationsszenarien können Gespräche mit Mo-
nologcharakter, aber auch schnelle Wortwechsel mit vielen Sprachüberschneidungen sein. Eine
Qualitätsausage über diese Gespräche ist natürlich ungemein schwieriger und ungenauer als
die Bestimmung von MOS-LQ-Werten (16). Ein Beispiel ist der Delay-Effekt. Während eines
längeren Monologs fällt ein Delay von mehreren hundert Millisekunden kaum auf. Bei einer
hohen Anzahl von Wortwechseln zwischen den Gesprächspartnern hingegen kann schon ein
kurzes Delay das Gespräch stark beeinträchtigen. Ein weiterer wichtiger Faktor bei interaktiven
36
Gesprächen ist die Interpretation der Gesprächsqualität. Vergleicht man die Aussagen über die
Qualität der Sprachkommunikation zweier Geschäftspartner über ein Gespräch mit den Aussa-
gen zweier Freunde über ein Gespräch, das über das gleiche Übertragungssystem geführt wur-
de, wird man feststellen, dass das Ergebnis sehr unterschiedlich ausfallen kann. In der Regel
wird bei einem Geschäftsgespräch die Toleranz gegenüber Qualitätseinbußen zu der gewohnten
ISDN-Qualität sehr gering sein. Das heißt, schon bei geringen Verzögerungen und Störungen
wird die Qualität als schlecht eingestuft. Freunde, die die Wortwahl und Redewendung des an-
deren kennen, bezeichnen die Sprachqualität des Gesprächs hingegen als gut. Vielleicht spielt
auch das Wissen eine Rolle, dass in der Regel eine VoIP-Verbindung günstiger ist als ein Te-
lefongespräch. Dies wiederum lässt die Akzeptanz gegenüber einer nicht so guten Verbindung
subjektiv steigen.
Das ITU unternahm Anstrengungen, ergänzend zu subjektiven Qualitätsmessungen kostengüns-
tige objektive Messverfahren zu entwickeln. Dabei entstand PSQM (Perceptual Speech Quality
Measure, P.862). Diese Messtechnik misst die Verzerrungen einer Sprachübertragung in Bezug
auf ein Referenzsample. Audiodaten, die über ein Netzwerk übertragen und beim Empfänger
gespeichert werden, werden mit den Referenzdaten, die beiden Seiten vorliegen, verglichen. Bei
der anschließenden Analyse werden die empfangenen Daten in kleine, überlappende Blöcke
unterteilt und durch eine Fourier-Transformation der einzelnen Blöcke ausgewertet.
Der daraus resultierende PESQ-Wert hat wie MOS einen Wertebereich von 0 bis 5, ist aber
nicht mit dem MOS-Wert gleichzusetzen, da die Skalierung unterschiedlich ist. Für PSQM-
Messungen benötigt man immer sowohl die Quell- oder Referenzdatei, als auch die empfangene
Datei, um die relative Verzerrung zu bestimmen.
Ein weiterer ITU-Standard ist der P.563, welcher nur mit der empfangenen Audiodatei aus-
kommt. Da die Messergebnisse aber im Vergleich zu P.862 weiter auseinanderliegen, ist es
notwendig, aus einer Vielzahl von Messungen den Mittelwert zu bilden. Dadurch erhält man
eine aussagekräftige Qualitätsmetrik, die aber nicht für einzelne Messungen aussagekräftig ist.
Die vorgestellten Algorithmen P.861, P.862 und P.563 benötigen einen großen Rechenaufwand
von circa 100 MIPS24 pro VoIP-Gespräch. Für viele Anwendungsbereiche ist dies unpraktika-
bel. Außerdem stehen die Algorithmen unter kommerziellen Lizenzen und dürfen daher nicht
frei verwendet werden.
4.9.3 ITU E-Modell und VQmon
Das E-Modell wurde ursprünglich vom ETSI (European Telecommunications Standardizati-

on Institute) als ein Werkzeug zur Planung für Telekommunikationsnetzwerke entwickelt und
basiert auf einer Reihe älterer Modelle. Heutzutage wird es aber auch als ein weitverbereite-
tes Werkzeug zur VoIP-Qualitätsmessung genutzt. Das ITU stellte das E-Modell 1998 als Re-
commendation G.107 vor und es wurde später von der Telchemy Inc. erweitert. Das E-Modell
ermöglicht VoIP-Qualitätsmonitoring.
VQmon (Voice Quality Monitoring) ist eine erweiterte Version des E-Modells. Es vereint die
24
MIPS bedeutet Million Instructions Per Second.
37
Effekte von Beeinträchtigungen in sich zeitlich verändernden IP-Netzwerken und ermöglicht

ein genaueres Einschätzen der Benutzerbewertung. Außerdem sind Erweiterungen für Breit-
band Codecs implementiert. Die vorliegende Diplomarbeit bezieht sich aber ausschließlich auf
das E-Modell nach ITU-T Recommendation G.107.
Eine Berechnung auf der vom ITU in der G.107 beschriebener Grundlage erreicht einen MOS-
Wert von 4.4 für einen R-Faktor (siehe Kapitel 4.9.4) von 93 bei der Verwendung des G.711
Codec. Neue ACR-Testdaten deuten aber eher auf einen MOS-Wert von 4.1 bis 4.2 für den
unkomprimierten G.711 Codec hin. Außerdem wird die Umwandlung des R-Faktors in den
MOS-Wert in anderen Ländern unterschiedlich vorgenommen. Das japanische TTC (Telecom-
munication Technology Committee) entwickelte beispielsweise eine Umrechnungsmethode, bei
der das Ergebnis deutlich niedriger liegt als bei der in Europa oder Amerika benutzen Methode.
Dies zeigt noch einmal, dass der MOS-Wert sehr subjektiv ist und nur in Verbindung mit dem
verwendeten Messverfahren, zum Beispiel ITU R-CQ, ITU MOS-CQ oder einer Kombinati-
on aus ITU MOS-LQ und Delay, angegeben werden sollte. Des Weiteren ist es notwendig,
zwischen Schmal- und Breitband-Codecs zu unterscheiden, da ein Breitband-Codec durch den
erweiterten R-Faktor-Bereich einen schlechteren MOS-Wert erhalten kann, obwohl die Qua-
lität offensichtlich besser ist. Das Ziel des E-Modells ist die theoretische Beschreibung einer
VoIP-Übertragung.
4.9.4 R-Faktor
Anhand des sogenannten R-Faktors soll die Dienstgüte einer Verbindung beschrieben werden.
Der R-Faktor beschreibt die Mund-zu-Ohr (mouth to ear) Charakteristik der Sprache, die über
ein digitales Kommunikationsnetzwerk übertragen wird. Der Wertebereich des R-Faktors liegt
zwischen 0 und 120. 50 bis 94 ist ein typischer Wertebereich für schmalbandige Telefonie25
und 50 bis 110 für Breitbandtelefonie. Der R-Faktor kann in den MOS-LQ- und MOS-CQ-
Wert umgerechnet werden. Die Berechnung der R-Faktoren basiert auf der Annahme, dass die
Sprachstörungseffekte aufaddiert werden können.
Da die Ermittlung des R-Faktors ein Grundbestandteil der zu entwickelnden Applikation zur
Bestimmung der Dienstgüte ist, wird die Berechnung des R-Faktors in Kapitel 6.3.1 genau-
er beschrieben. Ein vereinfachtes E-Modell beschreibt das ITU-T Dokument TD43 der Study
Group 12. In diesem Dokument wird ausführlich auf die Zusammenhänge der Audiofaktoren
eingegangen.
Diese verwendeten ITU-T Dokumente dürfen nicht elektronisch kopiert werden. Nach einer
kostenlosen Anmeldung können die Dokumente aber direkt von der ITU-T Internetseite
http://www.itu.int/home/ heruntergeladen werden. Dies betrifft die Dokumente Recommenda-
tion G.107, Dokument TD43 und Supplement 3 der P-Serie. Eine Kopie des Inhalts in nicht
elektronischer Form und die Verwendung der mathematischen Formeln ist ausdrücklich erlaubt.
25
In vielen Literaturangaben wird der schmalbandige Wertebereich auch von 0 bis 100 angegeben.
38
4.10 Echtzeitverhalten und Latenzzeiten des Linux-Kernels 4 GRUNDLAGEN
4.10 Echtzeitverhalten und Latenzzeiten des Linux-Kernels

Bei der Untersuchung der Dienstgüte von Echtzeitdatenströmen ist es erforderlich, genaue
Messwerte aufzunehmen. Aus diesem Grund ist ein Abschätzen der Latenz- und Reaktionszei-
ten für das verwendete Bretriebssystem notwendig. Der Linux-Kernel ist ohne weitere Modifi-
kationen nur Soft-Realtime fähig. Garantierte Verarbeitungszeiten von 2ms reichen für normale
VoIP-Übertragungen jedoch aus. Da in der vorliegenden Diplomarbeit eine Messapplikation
entwickelt werden soll, wird das Echtzeit- und Latenzverhalten des Linux-Kernels genauer un-
tersucht.
Es werden im Folgenden zwei Möglichkeiten vorgestellt, die das Echtzeitverhalten des Ker-
nels verbessern. Generell sollte im Linux-Kernel ab der Version 2.6 die Funktion Preemptible26
Kernel, aktiviert sein. Dies erlaubt Kernel-Systemdiensten Prozesse zu unterbrechen, um einen
höherpriorisierten Prozess auszuführen. Aber auch bei eingeschalteter Preemptible-Option kann
es im Kernel zu Verzögerungen für zeitkritische Prozesse kommen, beispielsweise wenn zwei
Prozesse auf denselben Mutex zugreifen. Ist der Linux-Kernel preemptiv, lässt sich bis auf die
kritischen Abschnitte, die durch die Preemtionssperre geschützt sind, eine zeitliche Auflösung
von 1ms erreichen.
Ebenfalls wichtig bei der geplanten Zeitmessung ist der I/O-Scheduler27 , den das System ver-
wendet, da in der vorliegenden Diplomarbeit große Datenmengen zeitnah auf die Festplatte
geschrieben werden sollen. Schreibprozesse auf der Festplatte sind im Vergleich zur CPU-
Verarbeitungszeit sehr langsam. Der No-Op-Scheduler28 ist im Linux-Kernel fest einkompi-
liert, aber seit der Kernelversion 2.6.10 ist es möglich, den I/O-Scheduler für jedes Blockgerät
separat auszuwählen. Hier empfiehlt es sich, den Anticipatory-Scheduler29 zu aktivieren, da der
Scheduler die Latenzzeiten und Datenträger-Zugriffszeiten deutlich verringert.
4.11 Zeitmessung mit Linux unter Verwendung von GNU C

Seit der Kernelversion 2.6 arbeitet Linux mit 100, 250 oder 1000 Hz also 10, 4 oder 1 Milli-
sekunden Abstand zwischen zwei Timer-Interups. Im Standard Linux-Kernel30 ist der Default-
Wert 250 Hz. Gespeichert wird der Takt in der globalen Variablen jiffies, die vom Typ unsigned
long ist. Dementspechend kommt es je nach eingestellter Timer-Interupt-Frequenz zu einem
Speicherüberlauf – bei einem Systemtakt von 250 Hz alle 196 Tage. Eine Bestimmungsgenau-
igkeit von 4 ms ist in der Regel aber zu ungenau. Abhilfe schafft die vom Kernel bereitgestellte
Variable xtime, die von Timer-Interupts bis zu Nanosekunden genau aktualisiert wird. xtime
26
Ist der Kernel preemptible, können laufende Programme unterbrochen werden. Dies hat Auswirkungen auf das
Echtzeitverhalten.
27
Der I/O-Scheduler ist ein elementarer Teil von Betriebssystemen, die Multitasking unterstützen. Er verwaltet den
Zugriff auf Ein- und Ausgabegeräte.
28
Der No-Op-Scheduler ist unter Linux der Standard Scheduler und verwaltet den Zugriff von Programmen auf die
Computerresourcen.
29
Der Anticipatory-Scheduler ist neuer im Vergleich zum No-Op-Scheduler und verwaltet Hardware in vielen Fällen
besser.
30
Der Linux-Kernel bildet das Kenprogramm des von Linus Torvalds entwickelten Betriessystems. Der Kernel bildet
die hardwareabstrahierende Schicht, auf die Programme aufbauen können.
39
4.11 Zeitmessung mit Linux unter Verwendung von GNU C 4 GRUNDLAGEN
zählt dabei die Sekunden und Nanosekunden, die seit dem 1.1.1970 verstrichen sind. Da die
Speicherung dieser Variablen mehr als 32 Bit benötigt, führt der Zugriff aber zu einem kriti-
schen Abschnitt. xtime bedient sich außerdem der Hardware moderner Prozessoren, die einen
Taktzyklenzähler, den TSC (Time Stamp Counter), haben. Dieser wird mit jedem Taktsignal
inkrementiert. Bei Prozessoren größer 1 GHz erreicht der TSC eine Auflösung im Nanosekun-
denbereich.
Für das Auslesen des Zeitwertes mit xtime gibt es zwei Möglichkeiten. Eine ist die Funktion
current kernel time(), welche die Zeit in der Struktur timespec zurückgibt:
Listing 11: Beispiel 1

1 struct timespec {
2 time t tv sec ;
3 long t v n s e c ;
4 }
Die andere Möglichkeit stellt die Funktion do gettimeofday() dar, welche eine Zeitrückgabe in
die Struktur timeval macht:
Listing 12: Beispiel 2

1 struct timeval {
2 time t tv sec ;
3 suseconds t tv usec ;
4 }
Prozessoren, die Frequenzscaling unterstützen, wie die meisten Mobile-Prozessoren, ändern die
Taktfrequenz während des laufenden Betriebs. Da in der Entwicklungsphase ein Notebook mit
Pentium Mobile Prozessor benutzt wurde, der Frequenzscaling unterstützt, soll im Folgenden
erklärt werden, warum Frequenzscaling keinen Einfluss auf die Echtzeitmessung hat. Wenn
eine Taktfrequenzänderung von der CPU initiiert wird, stellt dies kein Problem für die TSC-
Zeitmessung dar. Über den Notifer-Mechanismus wird die Funktion cpufreq register notifier()
aufgerufen. Über diese Funktion kann der Programmierer Taktfrequenzänderungen erkennen
und angepassen. Die Funktion xtime übernimmt diese Anpassungen automatisch. Auf das di-
rekte Auslesen des TSC unter Linux kann an dieser Stelle nicht näher eingegangen werden.
40
5 EINFÜHRUNG IN DAS PROJEKT
5 Einführung in das Projekt

Zu Beginn der vorliegenden Diplomarbeit wurde die Frage aufgeworfen, wie die Messung von
Dienstgüte-Parametern verwirklicht werden kann. Dabei galt es, zuerst sowohl zwischen den IP-
spezifischen Parametern als auch zwischen der Übertragungsgüte der Sprache zu differenzieren.
Die IP-spezifischen Parameter bilden die Grundlage für die Dienstgütebestimmung. Zu den Pa-
rametern gehören die one way trip time31 und round trip time32 , Packet Loss und Jitter. Werden
diese Parameter durch ein heterogenes Netz an zwei unterschiedlichen Standorten, beispiels-
weise an zwei Computern im Internet, ausgelesen, müssen beide Computer zeitsynchronisiert
sein. Das unter Linux zur Zeitsynchronisation oft verwendete NTP (Network Time Protocol)
kann diese Genauigkeit nicht garantieren. Eine weitere Möglichkeit ist die Verwendung von
GPS33 , DCF77-34 oder TDF-35 Zeitgebern, die eine Auflösung von bis zu einer Mikrosekunde
haben.
Ein Kriterium des zu entwickelnden Analysewerkzeug ist die Benutzbarkeit auf einem PC (Per-
sonal Computer), die durch kostspielige Hardwarevoraussetzungen wie die oben genannten
Zeitgeber nicht mehr gegeben ist. Entschieden wurde sich daher für eine andere Möglichkeit.
Sender- und Empfängerprogramm laufen auf dem gleichen Rechner; somit ist das Problem der
Zeitsynchronisation gelöst. Alle Programme, die Messdaten aufzeichnen, werden vom gleichen
Zeitgeber synchronisiert. Als Gegenstelle36 für die bidirektionale Übertragung muss nun ei-
ne Applikationslösung gefunden werden, die sowohl den geforderten SIP-Verbindungsaufbau
beherrscht als auch die gesendeten RTP-Datagramme unverändert zurückschickt. Eine weitere
Anforderung an die zu suchende Applikation ist das unveränderte Weiterleiten der Sequenz-
nummer. Nachteil dieser Methode ist, dass alle Daten als round trip time aufgezeichnet werden.
Da die round trip time für die Messung der Dienstgüte nicht so gut geeignet ist, liegt der Ge-
danke nahe, die round trip time zu halbieren, um somit das one way delay zu bestimmen.
Diese Symmetrieannahme kann jedoch durch unterschiedliche Faktoren außer Kraft gesetzt
werden, so dass die tatsächliche one way delay Zeit stark von der halben round trip time ab-
weicht. Bedingungen für eine Messung mit der zu entwickelnden Applikation sind somit der
gleiche Hin- und Rückweg der Datenpakete über dieselben Netzkomponenten und das Verwen-
den einer symmetrischen Datenleitung. Dies schließt asynchrone Datenübertragungsverfahren
wie ADSL (Asymmetric Digital Subscriber Line) aus.
Um ein geeignetes Messwerkzeug zu entwickeln wurden in der Planungsphase eine Vielzahl
von Softwareprojekten auf ihre Verwendbarkeit getestet. Die wichtigsten werden im Kapitel
5.1 vorgestellt.
31
Die one way trip time ist die Laufzeit eines Datenpakets im Netzwerk vom Sender zum Empfänger.
32
Die round trip time ist die Laufzeit eines Datenpakets im Netzwerk vom Sender zum Empfänger und zurück.
33
Zur Bestimmung der Zeit über GPS (Global Positioning System) ist der Empfang von mindestens 3 Satellitensi-
gnalen notwendig. Die Auflösung ist mindestens 1/1000 s.
34
DCF77 ist die Landsespezifische Zeitsynchronisation der Physikalisch Technische Bundesanstalt Braunschweig
und Deutsche Telekom AG. Es ist die gesetzliche Zeit in Deutschland.
35
TDF ist ein dem Radiosignal aufmoduliertes Zeitsignal. Betreiber ist das LPTF (Laboratoire Primaire du Temps et
des Frequences).
36
Im weiteren Verlauf wird die Gegenstelle als Echo-Server oder RTP-Proxy bezeichnet.
41
5.1 Verwendete Open Source Software 5 EINFÜHRUNG IN DAS PROJEKT
5.1 Verwendete Open Source Software

Grundbedingungen für die zu verwendende Software sind die Möglichkeit und die rechtli-
che Grundlage zur Modifizierung des Quellcodes. Es wurden deshalb in der Planungsphase
primär Programme aus dem Bereich der GNU/Linux-Community37 gesucht, zum Beispiel auf
den Webseiten http://www.freshmeat.net und http://www.voip-info.org. Die dort vorgestellten
Programme stehen meist unter einer freien Lizenz und liegen im Quellcode vor. Die im Fol-
genden vorgestellten Programme wurden alle näher untersucht und mit Ausnahme des Asterisk
PBX-Servers verwendet.
5.1.1 Debian GNU/Linux
Debian GNU38 /Linux ist ein OS (Operating System), das sich durch eine hohe Performance
und Stabilität auszeichnet. Eine Besonderheit gegenüber anderen Linux-Distributionen ist das
Paketmanagement apt, mit dem eine Vielzahl von Programmen sehr einfach installiert werden
kann. Dabei wird zwischen vorkompilierten Programmen und dem Quellcode unterschieden.
Debian ist eine kostenlose GNU/Linux-Distribution. Es liefert alle Entwicklungswerkzeuge,
die für die Entwicklung der Applikation nötig sind.
5.1.2 Asterisk Private Branch Exchange (PBX)
Asterisk ist eine PBX-Software (Private Branch Exchange Software), die ursprünglich von der
Firma Digium entwickelt wurde. Da Asterisk alle Funktionalitäten einer herkömmlichen Tele-
fonanlage abdeckt, der Quellcode unter der GPL (GNU Public License) Version 2 offengelegt
ist und Asterisk eine Vielzahl von Protokollen unterstützt, wird das Projekt von kommerziellen
Firmen sowie von der Community aktiv weiterentwickelt.
Wichtige Protokolle, die Asterisk unterstützt, sind hier aufgelistet:
• IAX (Inter-Asterisk Exchange)
• SIP (Session Initiation Protocol)
• H.323
Außerdem wird eine Vielzahl von Codecs bereitgestellt:
• ADPCM (Adaptive Differential Pulse Code Modulation)
• G.711 (a/u-Law)
• G.723.1 (pass through)
• G.726
37
Die Community ist eine Vielzahl freiwilliger Mitarbeiter, die in der ganzen Welt an Open Source Projekten arbei-
ten.
38
GNU bedeutet GNU is Not Unix.
42
• G.729 (Lizenz, Digium)
Asterisk kann zwischen den unterschiedlichen Protokollen und Codecs vermitteln und bietet
Gateway-Möglichkeiten ins PSTN-Netz. Zudem ermöglicht Asterisk einen Echo-Modus, wel-
cher gesendete Audiodaten zeitverzögert spiegelt. Leider ist Asterisk nicht für die Aufzeich-
nung der IP-spezifischen Parameter geeignet, da Datenpakete von der Asterisk Software bis zum
RTP-Payload entpackt und Software intern weiterverarbeitet werden. Mit neuen Zeitstempeln
und Sequenznummern versehen werde diese anschließend vom Asterisk zum Zielhost weiter-
geleitet. Da die neuen Zeitstempel und Sequenznummern keinen Bezug zu den ursprünglichen
Zeitstempeln im RTP-Header haben, eignet sich der Asterisk-Server nicht für die Messung der
IP-spezifischen Parameter.
5.1.3 SIP Express Router (SER)
Der schon im Kapitel 4.6 erwähnte Signalisierungsserver SER (SIP Express Router) ist hoch-
performat und kann sowohl als
• Registrar-Server
• Redict-Server
• Proxy-Server
betrieben werden. Die Installation und Konfiguration unter Debian-GNU/Linux ist sehr einfach.
SER ist im Gegensatz zum Asterisk-Server ein reiner Signalisierungsserver. Über das Erweite-
rungsmodul Nathelper kann der SER mit einem Zusatzprogramm, dem RTP-Proxy, Signalisier-
ungs- und Steuerdaten austauschen. Dies ermöglicht dem SER nach dem Sessionaufbau als
RTP-Proxy für VoIP-Daten, die über RTP übertragen werden, zu agieren. Im folgenden Unter-
kapitel wird der RTP-Proxy näher beschrieben.
5.1.4 RTP-Proxy
Der von Maxim Sobolev für die Firma PortaOne entwickelte RTP-Proxy ist ein eigenständiges
Programm, das über die Nathelper-Schnittstelle des SER angesprochen wird. Da der RTP-
Proxy im Gegensatz zu dem eben vorgestellten Asterisk-Projekt nur RTP-Datenströme entge-
gennimmt und diese an einen Zielhost weiterleitet, ist die Funktionsweise kaum zu vergleichen.
Der RTP-Proxy öffnet einen Socket SOCK DGRAM 39 auf UDP-Ebene; somit wird der RTP-
Header (Abb.: 9) nicht verändert. Sequenznummer und Timestamp, die bei der Erzeugung eines
RTP-Pakets generiert werden, können auf der Empfangsseite ausgewertet und als Messgrößen
herangezogen werden. Der Socket SOCK DGRAM ist in IPv4 und IPv6 für verbindungslose
und unzuverlässige Datagramme mit fester Paketgröße, wie dem UDP, implementiert.
Im Folgenden wird auf die Funktionsweise des RTP-Proxy näher eingegangen. Der RTP-Proxy
reagiert auf INVITE Nachrichten, die den SER erreichen. Die Caller-ID wird ausgelesen und an
39
Der SOCK DGRAM ist ein spezieller Socket für dsa verbindungslose Protokoll UDP.
43
den RTP-Proxy per Socket Kommunikation weitergegeben. Der RTP-Proxy überprüft darauf-
hin, ob dieser Caller-ID bereits eine UDP-Sitzung zugeordnet wurde. Ist dies nicht der Fall, wird
für eine neue Sitzung ein UDP-Port reserviert und die Portnummer an den SER zurückgeliefert.
Der SER ersetzt daraufhin im SDP das m-Flag (Tab.: 11) mit der IP-Adresse und Port des RTP-
Proxys.
Wird nun vom SER ein sogenannter non-negative SIP-Reply mit SDP-Daten empfangen, wird
die Caller-ID vom Nathelper-Modul des SER erneut an den RTP-Proxy gesendet. Der RTP-
Proxy prüft anhand einer internen Liste, ob für diese Caller-ID schon eine Session zugewiesen
ist und gibt einen Fehlercode zurück, wenn keine Session existiert. Wird ein positive SIP-Reply
am SER empfangen, werden die SDP-Daten in den Ursprungszustand zurückgesetzt. Nach dem
Erzeugen einer neuen Sitzung horcht der RTP-Proxy an dem für diese Sitzung vorgemerkten
Port.
Zu erwähnen ist auch, dass für jede der beiden UA’s eine Session erstellt wird. Werden nun Da-
tenpakete an einen der UDP-Ports geschickt, füllt sich eine Datenstruktur im RTP-Proxy. Sind
die Datenstrukturen beider Sockets voll, werden diese untereinander ausgetauscht. Der RTP-
Proxy speichert die Leerlaufzeit der einzelnen Sessions und löscht ungenutzte Verbindungen
per Default nach 60 Sekunden.
Nach einigen Funktionstests am SER mit RTP-Proxy und dem Softphone kphone als UA, das im
folgenden Unterkapitel näher beschrieben wird, und der Datenauswertung durch das Programm
ethereal, hat sich der SER mit RTP-Proxy als geeignetes Serverprogramm für den Verbindungs-
aufbau und die Übertragung der RTP-Daten herausgestellt.
5.1.5 Softphone kphone
Das einfache KDE (K Desktop Environment) Softphone kphone, mit dem schon der Verbin-
dungsaufbau zum Asterisk und SER realisiert wurde, steht unter der GPL Version 2 und ist in
der Programmiersprache C++ geschrieben. Der SIP UA kphone verwendet die Codecs G.711 a-
/u-law, GSM, iLBC und spexx. Durch Tests und die Analyse des Quellcodes stellte sich heraus,
dass kphone keine Möglichkeit besitzt, mehrere Sessions gleichzeitig aufzubauen. Außerdem
ist es nicht möglich, mehrere Instanzen von kphone parallel auf einem Computer auszuführen.
Ein weiterer Nachteil ist, dass kphone auf dem QT-Toolkit40 basiert. Aus diesem Grund ist ein
Einsatz auf Computern ohne X-Server41 nicht möglich.
Auch Softclients wie linphone, twinkle oder ekiga weisen die gleichen negativen Aspekte auf,
die sie für die Verwendung in dem Projekt unbrauchbar machen. Lediglich für Tests und Feh-
leranalysen, zum Beispiel um die Funktion des RTP-Proxys zu prüfen, werden die Softphones
als UA verwendet.
40
QT (QT-Toolkit) ist ein Entwicklungstool für grafische Oberflächen und wurde von der Firma Tolltech entwickelt.
41
Der X-Server ist ein Dienst auf einem Computer, der eine grafische Oberfläche dem X-Client zur Verfügung stellt.
Auf den X-Server baut das X-Window-System auf.
44
5.1.6 SIPSet Application Programming Interface (API)
Der SIP- und RTP-Stack der Firma Vovida, welcher unter der Vovida Software License steht und
die Veränderung des Quellcodes für nicht komerzielle Zwecke zulässt, stellt ein API (Applica-
tion Programming Interface) für SIP basierte Applikationen in der objektorientierten Program-
miersprache C++ dar und ist voll kompatibel zur RFC 2543. Der Quellcode ist sehr übersichtlich
in Aufgabengruppen unterteilt. SIPSet bietet eine breite Palette an Beispielprogrammen, unter
anderem ein SIP-UA GUI (Graphical User Interface). Der Vovida RTP-Stack unterstützt die
ITU-T Codecs G.711 u/a-law, G.723, G.726 und G.728.
Mit Hilfe der SIPSet API wurde im gleichen Zeitraum von Kim Ernst im Rahmen einer Di-
plomarbeit ein RTP-Lastgenerator entwickelt, welcher SIP zum Sessionaufbau nutzt. Aus die-
sem Grund konnte schon bei der Entwicklung des Lastgenerators auf die weitere Verwendung
in diesem Projekt Einfluss genommen werden. Außerdem konnten Synergien genutzt werden,
da die Projekte aufeinander aufbauen und somit die gleichen Applikationen verwendet werden.
Der RTP-Lastgenerator besteht aus einem Sendeprogramm (gensend) und einem Empfangspro-
gramm (genrcv). In der vorliegenden Diplomarbeit wird der Lastgenerator als RTP-Generator
bezeichnet, da der Generator für Messungen nicht mit der Last Option gestartet wird. Des Wei-
teren heißen die Programme gensend.bin und genrcv.bin, um zu verdeutlichen, dass es sich um
Binärprogramme handelt.
5.1.7 Gnuplot und gnuplot i C-Schnittstelle
Gnuplot (Version 4.0, GPL Versinon 2) ist ein Kommandozeilen gesteuerter interaktiver Daten-
und Funktionsplotter, der ursprünglich für die Visualisierung von mathematischen Funktionen
und Gleichungen entwickelt wurde. Gnuplot bietet eine große Auswahl an Funktionen, die es
dem Benutzer sehr einfach machen, Funktionen zu visualisieren. Außerdem bietet Gnuplot die
Möglichkeit, Dateien mit Messdatensätzen zu lesen und diese anhand einer komplexen Syntax
zu visualisieren. Gnuplot wird in der vorliegenden Diplomarbeit zur visuellen Aufarbeitungen
der gemessenen Daten als 2D-Plotter benutzt.
gnuplot i ist ein ANSI (American National Standards Institute) C-Interface für Gnuplot. Es bie-
tet Applikationen, die in der Programmiersprache C geschrieben sind, die Möglichkeit, Gnuplot
interaktiv zu nutzen. Viele Gnuplot Funktionen wurden in gnuplot i abgebildet. Außerdem las-
sen sich im Quellcode von gnuplot i sehr einfach neue Funktionen implementieren.
5.1.8 Netzwerk-Analysatoren tethereal und ethereal
Das Programm tethereal ist ein Kommandozeilen-Echtzeit-Netzwerk-Analysator (GPL Versi-

on 2) mit einer Vielzahl von Filtern und Einstellungsmöglichkeiten. Das Programm arbeitet
im promiscuous-Modus der Netzwerk-Schnittstelle im ISO OSI-Protokoll (Abb.: 2) in der Si-
cherunsschicht und kann aufgezeichnete Daten im Capture-Format speichern. Das Capture-
Format, das unter Linux in der libcapture definiert ist und die Dateiendung .cap benutzt, ist zu
ethereal voll kompatibel. Ein großer Vorteil von tethereal gegenüber vielen anderen Netzwerk-
45
Analysator-Tools ist, dass man es als normaler Benutzer über das sogenannte sticky Bit“ auf-
”
rufen kann. Normalerweise müssen Programme dieser Art explizit als Benutzer root42 aufge-
rufen werden. Beispiele hierfür sind Programme wie ifconfig oder tcpdump. Dies hätte jedoch
neue Probleme in der Entwicklungsphase hervorgerufen. In der vorliegenden Diplomarbeit wird
tethereal einerseits von dem im nächsten Kapitel beschriebenen Programm callflow und ande-
rerseits zum Aufzeichnen der one way Datensätze auf dem RTP-Proxy-Computer verwendet.
Ethereal ist ebenfalls ein Netzwerk-Protokoll-Analysator, der unter der GPL Lizenz 2 steht. Er
besitzt aber im Gegensatz zu tethereal ein GUI (Graphical User Interface)43 . Es erlaubt, die
Daten eines Netzwerks in Echtzeit einzusehen und zu analysieren. Dabei können die Daten
ebenfalls im Capture-Format gespeichert werden. Jedes Paket kann annähernd in Echtzeit (live)
angezeigt werden. Zahlreiche Zusatzfunktionen machen das Programm zu einem sehr guten
Analysetool. Ethernet-Dateien im Capture-Format liefern im Rahmen der Entwicklung eine
gute Vergleichsreferenz zu den gemessenen Daten.
5.1.9 Sequence Diagram Generator callflow
Das Programm callflow ist ein Sequence Diagram Generator. Basierend auf einer Sammlung
von Shell-Skripten unter der Verwendung des Programms awk ist callflow in der Lage, tethereal
und ethereal Capture-Dateien auszulesen. Für die Visualisierung benutzt callflow das in der
Programmiersprache Java geschriebene Framework batik.
Resultat von callflow ist ein übersichtliches Sequenz-Diagramm einer Datei mit Aufzeich-
nungsdaten im Capture-Format. Über Filter ist callflow besonders gut geeignet für die Visua-
lisierung der SIP-Signalisierung. Es ermöglicht eine schnelle Fehleranalye, wenn beim SIP-
Verbindungsaufbau und -abbau Fehler auftreten. In der Abbildung 12 wurde zur Verdeutlichung
eine callflow Ausgabe verwendet.
5.1.10 Webserver Apache und PHP4
Der Apache Webapplikationsserver ist ein robuster und sehr verbreiteter Webserver, der unter
der Apache Lizenz steht. Er ist unter dem verwendeten Betriebssystem einfach einzurichten
und wird in der vorliegenden Diplomarbeit zur Bereitstellung des Webinterface genutzt. PHP
ist dabei eine effiziente Programmiersprache, da sie direkt in HTTP eingebettet wird und daher
oft in Webapplikationen Anwendung findet. Über das Modul php module wird PHP in den
Apache Webserver eingebunden.
5.1.11 Software Suite ImageMagick
ImageMagick ist eine Software Suite, die das Erstellen und Bearbeiten von Bildern ermöglicht.
Die Programmsammlung ist quelloffen und steht unter einer eigenen Lizenz. ImageMagick un-
terstützt eine Vielzahl von Programmiersprachen, unter anderem auch C, C++ und PHP. Image-
42
Der Benutzer root ist der administrative Benutzer unter Linux und hat vollen Systemzugriff.
43
Ein GUI ist eine grafische Benutzeroberfläche.
46
Magick wird in diesem Zusammenhang verwendet, um Übersichtsbilder zu erstellen und Bilder

zu verschmelzen (merge).
5.1.12 Weitere Software
Im Rahmen der Planungsphase wurden viele weitere Projekte untersucht, die für Teilgebiete
der Aufgabenstellung gut geeignet sind. Benutzt wurde jedoch lediglich iperf, da mit diesem
Programm eine Netzlast ähnlich der des Lastgenerators erstellt und verglichen werden kann.
• iperf ist ein leistungsfähiger Netzwerk-Performence-Tester, der auf dem Client/Server-Prinzip ba-
siert. Das Programm iperf benutzt jedoch keinen SIP zur Signalisierung und kann nur eine Instanz
aufbauen. Des Weiteren kann es Jitter und Delay in Echtzeit anzeigen.
• sipp ist ein Konsole SIP UA zum Testen von SIP-Verbindungen. Das Programm sipp kann sehr
viele Signalisierungen gleichzeitig durchführen und Ausgabedateien im CSV-Format generieren.
Da aber Programme wie kphone zum Testen des SIP-Verbindungsaufbaus einfacher zu bedienen
sind, wurde sipp lediglich in der Planungsphase verwendet, um die Skalierbarkeit des SER-Servers
zu testen.
• rat ist ein Softphone, das in der Ursprungsversion nur über die Konsole gesteuert werden konnte.
Da rat ansonsten die gleichen Defizite wie kphone hat, wurde es nur in der Testphase als UA auf
Computern ohne X-Server verwendet.
• live555 ist ein API für Multimediastandards wie RTP, RTCP, RTSP und SIP mit einer großen
Anzahl an Beispiel-Quellcode und Demonstrationstools. Softwareprojekte wie der Linux mplayer
benutzten die livelib für Streaming-Applikationen. Für weitere Projekte, besonders für die Analyse
von Audio- und Videodaten, ist dieses API ebenfalls sehr gut geeignet.
47
6 ENTWICKLUNG
6 Entwicklung
In diesem Kapitel wird die Entwicklung der Applikationen näher beschrieben. Dabei kann zwi-
schen zwei Entwicklungsphasen unterschieden werden: Die Entwicklung der Echtzeitapplika-
tionen und die Entwicklung der Auswertungs- und Anzeigeapplikationen. Abbildung 17 gibt
eine Übersicht über die Prozesse, die während einer VoIP-Verbindung in der Echtzeit-Phase ak-
tiv sind. Als Entwicklungsplattform wurde für die C/C++ Programme Kdevelop 3.3.2 mit dem
Kompiler gcc 4.0.3-3 verwendet. Die Web- und PHP-Applikationen wurden mit dem Quanta
3.5.2 HTML-Editor erstellt. Für Shell-Skripte und die Programmierung auf einem entfernten
Computer (remote programming) wurde der Konsolen-Editor vim in der Version 7.0 benutzt.
Abbildung 17: Prozesse während der VoIP-Verbindung
Als einer der ersten Schritte war es wichtig, die IP-spezifischen Messdaten auszulesen und in
Dateien zu sichern. Die Daten müssen in Echtzeit aus dem jeweiligen Protokoll-Header während
der offenen RTP-Verbindung entnommen werden. Eine Überlegung war, die Daten vor dem Ver-
senden durch das Programm gensend.bin und direkt nach dem Empfangen durch das Programm
genrecv.bin zu sichern. Dies muss für alle Sessions gelten, die aufgezeichnet werden sollen.
Außerdem muss dies unter Berücksichtigung der Echtzeitkriterien realisiert werden.
6.1 Modifikationen im Quellcode von gensend.bin und genrecv.bin

Im Sender gensend.bin werden die RTP-Pakete über die Funktion RtpSession::transmit gesen-
det und auf der Empfängerseite genrcv.bin über RtpSession::receive wieder empfangen. Die
beiden Funktionen sind im Quellcode der jeweiligen Applikation in der Datei RtpSession.cxx
48
6.1 Modifikationen im Quellcode von gensend.bin und genrecv.bin 6 ENTWICKLUNG
deklariert. In der Datei RtpTransmitter.cxx im Quellcode von gensend werden die zu speichern-
den Parameter ausgelesen und an eine Message-Queue übergeben (Listing 13). Eine Message-
Queue ist ein asynchrones Protokoll, das zur IPC (Inter Process Communication) verwendet
wird. Die Message-Queue wird in der Funktion main.cpp initialisiert (Listing 14). Das Gene-
rieren der Zeitstempel, die an die Message-Queue als Sendezeitstempel übergeben werden, ist
ebenfalls in der Datei RtpTransmitter.cxx realisiert. Dazu wird die in Kapitel 4.11 vorgestellte
Funktion do gettimeofday() benutzt. In der Datei main.cpp werden die über die Message-Queue
empfangenen Daten in eine Datei mit dem festen Dateinamen /tmp/sender-output.csv durch
Kommas getrennt geschrieben (Listing 14). Dieses Format hat den Vorteil, dass Datensätze je
nach Wunsch auch in Applikationen wie beispielsweise Open Office zur Weiterverarbeitung
geöffnet werden können. Eine Liste der aufgezeichneten Werte kann der Tabelle 18 entnommen
werden.
Listing 13: Message Queue in TrpTransmitter.cxx

1 ...
2 i n t msgID ;
3 s t r u c t myMsg {
4 l o n g mtype ;
5 char m t e x t [ MSGSIZE ] ;
6 } dataMsg ;
7 l o n g msgTyp = 0 ;
8 msgID = m s g g e t ( 2 4 0 4 1 1 , IPC CREAT | 0 6 6 6 ) ;
9 ...
10 / / A u s l e s e n d e r W e r t e und B e r e c h n u n g d e r Z e i t s t e m p e l
11 ...
12 s p r i n t f ( dataMsg . m t e x t , ”%i ,% i ,% i ,% s ,% i ,% i ,% i ,% i ”
13 , seqnum2 , t i m e , h e a d e r −>t y p e , p l t i m e , s e s s i o n , i p T o s , l c l R t p P o r t , r m t R t p P o r t ) ;
14 i f ( msgID >= 0 )
15 {
16 dataMsg . mtype = 1 ;
17 i f ( msgsnd ( msgID , &dataMsg , MSGSIZE , 0)== −1)
18 {
19 p e r r o r ( ” msgsnd ” ) ; / ∗ F e h l e r ∗ /
20 }
21 else
22 {
23 / ∗ Wir s i n d d u r c h g e l a u f e n ∗ /
24 }
25 }
26 else
27 {
28 p e r r o r ( ” msgget ” ) ;
29 }
30 ...
49
Wert Programmvariable
Sequenznummer seqnum2
TOS ipTos
Sende-Port lclRtpPort
Empfangs-Port rmtRtpPort
Zeitstempel time
Zeitstempel pltime
Session session
Tabelle 18: Aufgezeichnete Daten
Listing 14: Message Queue in main.cpp

1 msgID = m s g g e t ( 2 4 0 4 1 1 , IPC CREAT | 0 6 6 6 ) ;
2 d a t a c o l l e c t o r = 1;
3 collector pid =fork ( ) ;
4 i f ( c o l l e c t o r p i d ==0)
5 {
6 i n t x=−1;
7 s t r u c t myMsg
8 {
9 l o n g mtype ;
10 char m t e x t [ MSGSIZE ] ;
11 }
12 dataMsg ;
13 }
14 ....
15 do
16 {
17 i f ( msgID >= 0 )
18 {
19 / / Warte a u f N a c h r i c h t e n
20 i f ( msgrcv ( msgID , &dataMsg , MSGSIZE , msgTyp , 0)== −1)
21 {
22 p e r r o r ( ” msgrcv ” ) ; / / Fehler
23 m s g c t l ( msgID , IPC RMID , ( s t r u c t m s q i d d s ∗ )NULL ) ;
24 exit (6);
25 }
26 else
27 {
28 / / Daten e m p f a n g e n
29 f i l e << dataMsg . m t e x t << ’ \ t ’ <<e n d l ; / / Daten i n D a t e i s c h r e i b e n
30 alarm ( 5 ) ; / / A b b r u c h b e d i n g u n g neu s e t z e n 5 s e c
31 }
32 }
33 else
34 {
35 p e r r o r ( ” msgget ” ) ;
36 exit (6);
37 }
38 }
39 w h i l e ( x <0); / / do w h i l e b i s A b b r u c h b e d i n g u n g e r f u e l l t
Die für die Sendedaten verwendete Datei /tmp/sender-output.csv beinhaltet dabei die Daten
aller Sessions, die zum Aufnahmezeitpunkt gestartet wurden. Die Datei wird zu Beginn einer
Messung gelöscht und neu angelegt.
50
Die Aufzeichnung der Daten beim Empfangen im Prozess receiver.bin gestaltet sich ähnlich.
In der Quellcode-Datei RtpReceiver.cxx des Empfängerprogramms genrecv.bin werden die Da-
ten ausgelesen und an eine Message-Queue weitergereicht. Diese ist im Programm main.cpp
der Empfängerapplikation definiert. Der Unterschied zur Sendeapplikation ist, dass die zu spei-
chernden Daten aus dem Socket ausgelesen werden müssen und der von gensend.bin gene-
rierte Timestamp durch einen neuen Timestamp, der lokal generiert wird, überschrieben wird.
Somit ist sichergestellt, dass alle anderen Aufzeichnungswerte des empfangenen RTP-Pakets
unverändert bleiben und nicht vertauscht werden. Es wird lediglich ein neuer Timestamp hin-
zugefügt.
Genauer erklärt bedeutet dies, dass das Feld pltime auf der Empfängerseite mit einem loka-
len Timestamp, der beim Empfangen des Pakets über die Funktion do gettimeofday() erzeugt
wird, überschrieben wird. Im Quellcode von main.cpp wird das Format der festgelegten Ausga-
bedatei /tmp/receiver-output.csv beschrieben, in die die von der Message-Queue übergebenen
Aufzeichnungsdaten gespeichert werden. Das Format der beiden Aufzeichnungsdateien ist da-
bei gleich. Die Listings 15 und 16 zeigen das verwendete Format an. In Tabelle 19 werden die
aufgezeichneten Daten erklärt.
Spalte Bezeichnung
1 Paketnummer
2 Sequenznummer
3 nicht genutzt
4 Zeitstempel gekürzt
5 Sessionnummer
6 TOS-Wert
7 Sender-Port
8 Empfänger-Port
Tabelle 19: Beschreibung der aufgezeichneten Daten-Felder
Listing 15: Beispielausgabe der Datei sender-output.csv

1 1 ,612121425 ,0 ,1150373510487126 ,0 ,0 ,28000 ,35020
2 1 ,1856883376 ,0 ,1150373510487484 ,1 ,0 ,28001 ,35028
3 1 ,1344681739 ,0 ,1150373510488053 ,3 ,0 ,28003 ,35022
4 1 ,21468264 ,0 ,1150373510488397 ,4 ,0 ,28004 ,35024
5 1 ,953369895 ,0 ,1150373510488790 ,5 ,0 ,28005 ,35026
6 1 ,126313438 ,0 ,1150373510489179 ,6 ,0 ,28006 ,35030
7 1 ,444268468 ,0 ,1150373510489859 ,8 ,0 ,28008 ,35034
8 1 ,1886964647 ,0 ,1150373510490303 ,7 ,0 ,28007 ,35032
9 2 ,953369895 ,0 ,1150373510492559 ,5 ,0 ,28005 ,35026
10 3 ,953369895 ,0 ,1150373510496547 ,5 ,0 ,28005 ,35026
11 4 ,953369895 ,0 ,1150373510500570 ,5 ,0 ,28005 ,35026
12 2 ,444268468 ,0 ,1150373510500610 ,8 ,0 ,28008 ,35034
13 5 ,953369895 ,0 ,1150373510504985 ,5 ,0 ,28005 ,35026
14 2 ,612121425 ,0 ,1150373510507553 ,0 ,0 ,28000 ,35020
15 6 ,953369895 ,0 ,1150373510508549 ,5 ,0 ,28005 ,35026
51
6.2 Erweiterungen im RTP-Proxy 6 ENTWICKLUNG
Listing 16: Beispielausgabe der Datei receiver-output.csv

1 1 ,612121425 ,0 ,1150373510490213 ,0 ,23000 ,0
2 1 ,1856883376 ,0 ,1150373510490262 ,1 ,23001 ,0
3 1 ,444268468 ,0 ,1150373510499993 ,8 ,23008 ,0
4 1 ,1886964647 ,0 ,1150373510500255 ,7 ,23007 ,0
5 1 ,126313438 ,0 ,1150373510500891 ,6 ,23006 ,0
6 1 ,953369895 ,0 ,1150373510501209 ,5 ,23005 ,0
7 2 ,953369895 ,0 ,1150373510503944 ,5 ,23005 ,0
8 3 ,953369895 ,0 ,1150373510503964 ,5 ,23005 ,0
9 1 ,21468264 ,0 ,1150373510503992 ,4 ,23004 ,0
10 1 ,1344681739 ,0 ,1150373510504035 ,3 ,23003 ,0
11 2 ,444268468 ,0 ,1150373510510874 ,8 ,23008 ,0
12 2 ,126313438 ,0 ,1150373510512783 ,6 ,23006 ,0
13 4 ,953369895 ,0 ,1150373510513183 ,5 ,23005 ,0
14 5 ,953369895 ,0 ,1150373510513371 ,5 ,23005 ,0
15 6 ,953369895 ,0 ,1150373510513969 ,5 ,23005 ,0
Des Weiteren ist anzumerken, dass die Message-Queue eine Größe von 500 Byte hat und somit
automatisch auch einen Datenpuffer zwischen der Netzwerkkarte und dem langsam schreiben-
den I/O-Scheduler darstellt.
Um Fehler schneller erkennen zu können, wurde eine Ausgabeschnittstelle hinzugefügt. So-
wohl die Sende- aus auch die Empfängerapplikation schreiben Informationen auf die Konsole.
Außerdem generieren die Programme jeweils eine HTML Datei, die im Webfrontend später
angezeigt wird.
Applikation Dateiname Typ

gensend.bin /tmp/gensend.bin.log TXT
gensend.bin /tmp/sender-output.html HTML
genrecv.bin /tmp/receiver.bin.log TXT
genrecv.bin /tmp/receiver-output.html HTML
Tabelle 20: Log Files
6.2 Erweiterungen im RTP-Proxy

Bei dem im Kapitel 5.1.4 vorgestellten RTP-Proxy wurde bei einer näheren Analyse des Da-
tenverkehrs auf Protokollebene festgestellt, dass das für QoS wichtige TOS-Feld im IP-Header
nicht wie erwartet übertragen wird, sondern vom RTP-Proxy im Normalfall auf den Hex-Wert
0x0 gesetzt wird. Der Grund für das Überschreiben der TOS-Felder durch den RTP-Proxy ist mit
dem verwendeten Socket und dem Aufbau der IP-Datagramme zu erklären. Da der RTP-Proxy,
wie schon beschrieben, einen Socket vom Typ SOCK DGRAM öffnet, können die darunter
liegenden Protokoll-Header nicht ausgelesen werden. Zur Verdeutlichung wird an dieser Stelle
auf die Abbildung 18 hingewiesen. In dieser Abbildung werden die einzelnen Protokoll-Header
noch einmal aufgeführt. Die umklammerten Werte zeigen die Headergröße des jeweiligen Pro-
tokolls in Bytes an. Wie schon im Kapitel 5.1.4 erwähnt, kann ein Socket immer nur auf den
Header- und Paketinhalt der für ihn vorgesehenen Protokollebene zugreifen. So kann exem-
plarisch ein SOCK DGRAM auf den UDP-Header und auf weitere verschachtelte Header im
52
Payload zugreifen, aber nicht auf den IP-Header. Protokoll-Header unterhalb von UDP werden
in diesem Beispiel ausschließlich vom Betriebssystemkern (OS kernel) verwaltet.
Abbildung 18: Header-Aufbau eines RTP-Pakets mit 20 ms Payload.
Ein möglicher Grund für die Verwendung des Sockets SOCK DGRAM ist neben der einfa-
cheren Programmierung, da der Betriebssystemkern viele Aufgaben übernimmt, sicherlich das
Sicherheitskonzept von Linux. Wird ein Socket auf unterer Protokollebene initialisiert, muss
dieser mit root Rechten ausgeführt werden. Dies ist für ein Programm wie den RTP-Proxy, der
angreifbare Sockets direkt zum Internet verwaltet, nicht empfehlenswert.
Der SOCK DGRAM kann, wie beschrieben Datenpakete lediglich bis zum UDP-Header öffnen.
Im RTP-Proxy ist zwar eine Möglichkeit implementiert, die über den Funktionsaufruf set-
sockopt den Wert des TOS-Felds überschreibt, dieser Wert kann aber nur beim Starten des
RTP-Proxys übergeben werden und gilt für alle initialisierten Sessions gleichermaßen.
Es galt nun, den Quellcode des RTP-Proxys so zu modifizieren, dass die TOS-Werte der Sen-
destruktur gleich den TOS-Werten der Empfangsstruktur sind. Ein Ansatz war das Ersetzen
des SOCK DGRAM durch einen Socket vom Strukturtyp PF INET, der einen Zugang zum
IPv4-Header ermöglicht hätte. Grundgedanke war das Verschieben des vom PF INET erstellten
Socketzeigers um den Wert des IP-Headers, der dann in einem neuen Socketzeiger gespeichert
werden sollte. Im weiteren Verlauf sollte das Programm dann den geänderten Socketzeiger
benutzen, um auf der Header-Struktur eines SOCK DGRAM zu arbeiten. Die Daten des IP-
Headers sollten vor dem Verschieben des Socketzeigers in einer IPv4 entsprechenden Struktur
gespeichert werden. Damit hätte man sehr elegant Zugriff zu den Werten des IP-Headers er-
langt, und der Ablauf des Programms hätte nur an einer Stelle geändert werden müssen. Leider
war dieser Ansatz nicht realisierbar, da der RTP-Proxy, wie in Kapitel 5.1.4 beschrieben, eine
Session als Sessionpaar aufbaut. Dies scheint mit dem modifizierten Socket vom Typ PF INET
nicht zu funktionieren, denn IP-Header und RTP-Header der einzelnen Sessions werden dabei
willkürlich vertauscht.
Eine weitere Lösungsmöglichkeit für das Auslesen der TOS-Werte im RTP-Proxy war das
Benutzen eines externen Programms, das ansich schon einen Socket vom Typ PF INET be-
nutzt. Netzwerk-Analysatoren benutzen oft Socket-Verbindungen auf unterer Protokollebene
und wären für diese Aufgabe gut geeignet. Ein sogenanntes Sniffer-Programm sollte den TOS-
Wert auslesen und über eine Message-Queue oder eine andere IPC an den RTP-Proxy weiter-
leiten. Zum Auslesen wurde das Programm dietsniff benutzt, das ebenfalls in der Programmier-
53
sprache C geschrieben ist, und um eine Message-Queue ergänzt. Im RTP-Proxy wurde ebenfalls
eine Message-Queue implementiert, die die vom modifizierten Programm dietsniff aufgezeich-
neten TOS-Werte empfängt und über die bekannte Funktion setsockopt den TOS-Wert der
ausgehenden RTP-Pakete setzt. Nach einigen Tests stellte sich jedoch heraus, dass dieser An-
satz nur dann praktikabel ist, wenn der RTP-Proxy lediglich ein Sessionpaar geöffnet hat. Für
mehrere Sessions ist die IPC über eine Message-Queue zu langsam und zu störempfindlich, so
dass die TOS-Werte im RTP-Proxy zu langsam oder falschen Sessions zugeordnet werden. Für
die vorgesehene Applikation ist dieser Lösungsansatz daher unbrauchbar.
Da der Zeitaufwand für die beschriebenen Lösungsversuche sehr hoch war, wurde nun eine ein-
fache und schnell zu implementierende Lösung gesucht. Gesucht wurde eine Verbindung zwi-
schen dem Sessionaufbau über SIP/SDP und dem RTP-Proxy. Der Gedanke, der diesem Ansatz
zugrunde liegt, ist die Verwendung der SIP-Signalisierung als einer Art Steuerkanal zwischen
dem sendenden UAC gensend.bin, welcher den TOS-Wert setzt, und dem SER. Dies bietet die
Möglichkeit, den TOS-Wert immer in Verbindung mit der aufgebauten SIP-Session dem RTP-
Proxy zu übergeben. Hierfür bot sich die call id im SIP-Verbindungsaufbau an. Diese wird
beim SIP-Aufbau im Sender gensend.bin über einen Zufallswert generiert. Die ursprüngliche
Caller-ID, zum Beispiel 855655123@192.168.0.103, wurde um die folgenden Zeichen ergänzt:
855655123tos5@192.168.0.103. Aus der Tabelle 21 ist zu entnehmen, wie sich der genaue Er-
weiterungssyntax zusammensetzt.
Bezeichnung Struktur
Zufallszahl Zufällige Zahlenfolge
Identifier tos
TOS-Wert 1-3 Felder
Endmarker @
Hostname IP / Hostname
Tabelle 21: Caller-ID Erweiterung
Im RTP-Proxy ist die caller id in der Struktur rtpp session gespeichert. Diese ist in der Da-
tei rtpp session.h definiert. In der Quelldatei main.c wird diese Struktur über den Zeiger sp
angesprochen. sp → f ds[sidx] spricht die jeweilige Speicherstruktur zum Versenden der RTP-
Daten an. sidx ist hierbei der Sessiondeskriptor, der die einzelnen Sessions identifiziert. Über
die Variable sp → calli d wird die Caller-ID der jeweiligen Session ausgelesen und in einem
weiteren Schritt ausgewertet. Der TOS-Wert, der aus der Caller-ID extrahiert wird, kann dann
über den Funktionsaufruf setsockopt gesetzt werden.
54
6.3 Auswertungsapplikation calculate 6 ENTWICKLUNG
Listing 17: TOS-Wert auslesen und neu setzen

1 f o r ( t p = 0 ; t p < 3 0 ; t p ++)
2 {
3 h i l f e = (& sp−>c a l l i d [ s i d x ] ) [ t p ] ; / / c a l l e r i d in h i l f e speichern
4 i f ( h i l f e == 1 1 5 ) s = t p ; / / nach ASCII s =115 s u c h e n
5 i f ( h i l f e == 6 4 ) a= t p ; / / nach ASCII @=64 s u c h e n
6 }
7 f o r ( g i = s +1 , gh = 0 ; g i<a ; g i ++) neu [ gh ++]=(& sp−>c a l l i d [ s i d x ] ) [ g i ] ; / / TOS−Wert i n c h a r a r r a y neu
8 z a h l = s t r t o l ( neu , NULL, 1 0 ) ; / / c h a r i n l o n g umwandeln
9 p r i n t f ( ” \nTOS : %d ” , z a h l ) ; / / K o n s o l e Ausgabe
10
11 s x=& z a h l ; / / I f S e g m e n t i o n f a u l t u s e s x=&z a h l ;
12 s e t s o c k o p t ( sp−>f d s [ s i d x ] , IPPROTO IP , IP TOS , sx , s i z e o f ( ∗ s x ) ) ;
Die Änderungen im Quelltext der Sendeapplikation gensend.bin, die für die Übertragung der
modifizierten Caller-ID notwendig sind, sind geringfügig. Bei der Erstellung der Caller-ID wird
nach der generierten Zufallszahl die weitere Syntax aus Tabelle 21 eingefügt.
6.3 Auswertungsapplikation calculate

Die aufgezeichneten Daten sollen in einem Schritt ausgewertet werden, der vom Datenerfassen
abgekoppelt ist. Zu diesem Zweck wurde in der Programmiersprache-C das Programm calcu-
late erstellt. Es kann beliebige Dateien des gleichen Typs wie sender-output.csv und receiver-
output.csv auswerten. Die Syntax, mit der calculate von der Konsole aufgerufen werden kann,
lautet wie folgt:
calculate SENDEDATEI EMPFANGSDATEI AUSGABEDATEI
Das Programm lässt sich in folgende Funktionsblöcke unterteilen:
• Einlesen der Datendateien in Strukturen
• Ermitteln der Sessioninformationen
• Separieren jeder Session in eine Struktur
• Sessionspezifische Auswertung und Berechnung der Daten
• Abspeichern der sessionspezifischen Datensätze
• Erstellen der Ausgabegrafiken mit gnuplot und ImageMagick
Die wichtigsten Strukuren und deren Aufgaben sind in Tabelle 22 aufgeführt. Die Datenstru-
kuren sind für die maximale Anzahl von zehn Aufzeichnungs-Sessions mit einer maximalen
Anzahl von 216 Paketen ausgelegt.
Als nächstes werden die Funktionen, die im Programm calculate verwendet werden und deren
Aufgabe vorgestellt. Diese sind in Tabelle 23 dargestellt.
Um einen genaueren Überblick über die Funktionsweise des Programms calculate zu geben,
wurde ein Programmablaufplan erstellt, der die wichtigsten Programmabschnitte verdeutlicht.
55
Datensatz Struktur Struktutyp Beschreibung

E-Modell emodel emodelstruct E-Modell-Werte, die bei der Be-
rechnung verwendet werden sollen.
Sender srecord daten Alle aufgezeichneten Daten von
gensend.bin
Empfänger rrecord daten Alle aufgezeichneten Daten von
genrecv.bin
Session Information sessioninfo sessioninfostruct Informationen über die jeweilige
Session
Session session sessionsort Beinhaltet die sortierten und ge-
ordneten Datensätze von Sender
und Empfänger nach Sessionnum-
mer und Paketnummer sortiert.
Tabelle 22: calculate Datenstrukturen und deren Funktionen
Funktionsname Funktionsbeschreibung
shorttime Diese Funktion kürzt die Timestamps um die führenden 7
Stellen und speichert die Werte in Variablen des Typs unsi-
gned long ab.
Rfactor Berechnet den R-Faktor aus den vorgegebenen E-Modell
Parametern und den ermittelten Messwerten.
mosfactor Rechnet den ermittelten R-Faktor in den MOS-Faktor um.
Tabelle 23: calculate Funktionen
Abbildung 19 und 20 geben dabei einen Überblick über den Ablauf des Programms. In der
Abbildung sind deutlich die Ein- und Ausgabedateien zu sehen, die als Schnittstellen zu wei-
teren Programmen der Applikation dienen. Die Variable x (x ∈ N) entspricht der ermittelten
Sessionnummer. Außerdem ist in dem Ablaufplan aufgezeigt, zu welchem Zeitpunkt externe
Programme wie ImageMagick und Gnuplot aufgerufen werden.
56
Abbildung 19: Programmablaufplan Teil 1 des Programms calculate
Die Abbildung 21 verdeutlicht den Funktionsblock, Session basierte Berechnung, aus Abbil-
dung 19. Der Programmablauf, wie also die Datensätze einer Session ausgelesen in Strukturen
gespeichert und verarbeitet werden, soll daraus ersichtlich werden.
In den Programmablaufplänen wurden Teilblöcke des Programms in Funktionsblöcken des Ab-
laufplans zusammengefasst. Auf Zwischenstufen wie die Berechnung oder die Ermittlung von
Hilfsvariablen wird nicht näher eingegangen.
Da die von calculate verwendeten Funktionen Rfactor und mosfactor dem Quellcode nicht ver-
ständlich entnommen werden können, werden in den folgenden Unterkapiteln 6.3.1 und 6.3.2
die Funktionen anhand der zugrunde liegenden Formeln beschrieben.
57
Abbildung 20: Programmablaufplan Teil 2 des Programms calculate
58
Abbildung 21: Programmablaufplan des sessionbasierten Auswertungsteils
6.3.1 R-Faktor Berechnung
Der R-Faktor wurde bereits im Kapitel 4.9.4 vorgestellt. Da die vom ITU-T in der Recommen-
dation G.107 präsentierten Formeln als Berechnungsgrundlage dienen, wird an dieser Stelle
noch einmal auf den Zusammenhang der im Webfrontend auszuwählenden Stellgrößen und de-
ren Gewichtung in den Formeln des E-Modells eingegangen. Basierend auf dem OPINE-Modell
(Overall Performance Index Model), welches im ITU-T Supplement 3 der P-Serie beschrieben
wird, wurde das E-Modell vom ITU-T entwickelt und wird durch im Folgenden beschriebenen
Formeln konkretisiert.
Grundgedanke des Modells ist die Annahme, dass die Übertragungsparameter der zu betrach-
tenden Verbindung ebenso wie die psychologischen Faktoren aufaddiert werden können. Die
59
psychologischen Faktoren wurden mit subjektiven Messmethoden bestimmt und in Näherungs-

formeln mathematisch beschrieben. Diese führt zu der Grundformel des E-Modells:
R = Ro − Is − Id − Ie − ef f + A
• Ro repräsentiert in dieser Formel das Verhältnis zwischen Sprachsignal und Störgeräuschen

(signal to noise). Es beinhaltet die Störgeräuschquellen, die sich zum Beispiel aus den
Schaltungsgeräuschen und Raum-Hintergrundgeräuschen zusammensetzen.
• Is beschreibt alle Störungen, die bei der aktiven Sprachübertragung, beispielsweise bei
einem VoIP-Gespräch, auftreten.
• Id beinhaltet eine Auswertung der Störungen, die sich aus der Verzögerung und der ver-
wendeten Hardware ermitteln lassen.
• Ie − ef f beschreibt Störungen, die durch den Codec hervorgerufen werden. Besonders

ausschlaggebend sind dabei Codecs mit niedrigen Bit-Raten. Außerdem fließen Beein-
trächigungen duch Paketverluste in Ie − ef f mit ein.
• Der A Faktor ist ein Kompensations-Faktor, der vom Benutzer für eine Messumgebung
festgelegt werden kann.
Die Faktoren Ro, Is und Id sind aufgegliedert in weiterführende Störungskenngrößen, die im

Weiteren anhand der vom ITU-T ermittelten Formeln erklärt werden.
Signal zu Geräusch Berechnung: Ro

Ro ist definiert als:
Ro = 15 − 1, 5[SLR + N o]
SLR = Sender Loudness Rating

Der Ausdruck N o setzt sich aus der Addition der Signalleistungen unterschiedlicher Geräusch-
quellen zusammen. Einheit von N o ist dB, gemessen zum 0 dBr-Punkt (29 )
Nc N os N or Nfo
N o = 10log[10 10 + 10 10 + 10 10 + 10 10 ]
N c ist die Summe der Signalleistungen der Schaltungsgeräusche bezogen auf den 0dBr Punkt.
N os ist das equivalente Schaltungsgeräusch am 0dBr-Punkt, welches durch das Raumgeräusch
P s auf der Senderseite verursacht wird.
N os = P s − SLR − Ds − 100 + 0.0004[P s − OLR − Ds − 14]2
OLR = SLR + RLR, mit RLR = Receive Loudnes Rating
60
Das senderseitige Raumgeräusch wird genauso wie das Raumgeräusch der Empfängerseite be-
stimmt und in den zu N os gleichwertigen Schaltungsgeräusch-Faktor N or umgewandelt, der
sich wiederum auf den 0 dBr Punkt bezieht.
N or = RLR − 121 + P re + 0.008 ∗ [P re − 35]2
P re ist der effektive Raumgeräuschpegel, der durch die Erweiterung von P r durch die Neben-
geräusche des Hörerweges hervorgerufen wird. P r ist das Raumgeräusch auf der Empfängerseite.
(10−LST R
P re = P r + 10log[1 + 10 10 ]
N f o repräsentiert den Hintergrundgeräuschpegel (noise floor) beim Empfänger und ist als
N f o = N f or + RLR definiert. N f or ist fest auf einen Pegel von -64dB zum 0dBr-Punkt
gesetzt.
Simultane Störfaktoren: Is
Is ist der Störfaktor , der die Summe aller Störungen, die mehr oder weniger simultan bei der
Sprachübertragung auftreten, erfasst. Is ist unterteilt in drei weitere spezifizierte Störfaktoren.
Is = Iolr + Ist + Iq, wobei Iolr die Verminderung der Sprachqualtität bei niedrigen OLR
Werten repräsentiert.
Xolr 8 1 Xolr
Iolr = 20[[1 + ( ) ]8 − ]
8 8
Xolr = OLR + 0.2(64 + N o − RLR)
Ist spiegelt in dieser Formel die Störungen wieder, die durch nicht optimale Nebengeräusche
verursacht wurden:
SRo − 13 8 1 SRo + 1 35 1 SRo − 3 13 1

Ist = 12[1 + ( ) ] 8 − 28[1 + ( ) ] 35 − 13[1 + ( ) ] 13 + 29
6 19, 4 33
SRo = ST M Ro
−T T ELR
ST M R
+e 4 ∗10 10
ST M Ro = −10log[10 10 ]
Dabei ist ST M R das sogenannte sidetone masking rating und T ELR das talker echo loud-
ness rating. Der Störfaktor Iq ist ein Maß für die Störungen und Verzerrungen, welche durch
die Quantisierung hervorgerufen werden.
Iq = 15log[1 + 10Y + 10Z ]
61
Ro − 100 46 G
Y = + −
15 8.4 9
46 G
Z= −
30 30
G = 1.07 + 0.258Q + 0.0602Q und Q = 37 − 15log(qdu)

qdu ist die Anzahl der Quantisierungsstörquellen zwischen der Sender- und Empfängerseite.
Der qdu-Wert 1 beschreibt eine A/D- und D/A-Umwandlung. Er wird in der Messung immer
als 1 angenommen. Wird in einer Berechnung der Störfaktor Ie für einen Teilbereich genutzt,
darf kein qdu für den selben Teilbereich genutzt werden.
Verzögerungs-Störfaktor: Id
Id repräsentiert alle Störsignale, die eine Verzögerung der Sprache hervorrufen und wird in die
Faktoren Id = Idte + Idle + Idd unterteilt.
Dabei ist Idte eine Abschätzung der Störungen, die durch das Sprachecho des Sprechers (talker
echo) erzeugt werden.
r
Roe − Re Roe − Re2
Idte = [ + + 100 − 1](1 − e−T )
2 4
Roe = −1, 5(N o − RLR) und Re = 80 + 2.5(T ERV − 14)
T
1 + 10 2
T ERV = T ELR − 40log T
+ 6e−0,3∗T
1 + 150
Für Werte von T < 1 ms bleibt das Sprachecho unbeachtet und wird als Wert 0 angenommen.
Die Berechnungsalgorithmen kombinieren außerdem den Einfluß von ST M R mit dem Spra-
checho. Bei Gesprächen mit einem hohen ST M R-Wert bekommt das Sprachecho eine höhere
Bedeutung. T ERV und Idte sind auf einen ST M R-Wert von < 9 dB angeglichen. Trifft der
Fall ein, dass ST M R < 9 dB ist, muss in der Gleichung für T ERV , T ERV durch T ERV s
ersetzt werden, wenn T ERV s = T ERV + Ist 2
ist.
Für den Fall, dass 9 dB≤ ST M R ≤ 20 dB ist, muss in den vorangegangenen Gleichungen die
ursprüngliche Berechnung für T ERV angewendet werden.
√
Ist ST M R > 20dB, muss Idte durch Idtes = Idte2 + Ist2 ersetzt werden.
Der Faktor Ide repräsentiert die Hörer-Echo-Störungen:

r
Ro − Rle (Ro − Rle)2
Ide = + + 169
2 4
Rle = 10.5(W EP L + 7)(T R + 1)−0,25

Der Faktor Idd repräsentiert Störungen, die durch lange Verzögerungszeiten (T a) entstehen.
Wenn T a < 100 ms, ist Idd = 0. Ist T a > 100 ms, wird Idd mit der folgenden Formel berech-
62
net:
1 x 1
Idd = 25[(1 + x6 ) 6 − 3(1 + [ ]6 ) 6 + 2
3
Ta
log( 100 )
x=
log(2)
Ausrüstungs-Störfaktor: Ie
Ie ist ein Faktor, der den verwendeten Codec wiederspiegelt. Dieser ist von den für den Co-
dec ermittelten MOS-Test-Ergebnissen und den Netzerfahrungen mit diesem Codec abhängig.
Tabellen, denen Ie in Abhängigkeit vom Paketverlust und Codec entnommen werden konnte,
dienten früher zur Bestimmung des Werts. Ie ist heute der Störfaktor bei einem Paketverlust
von 0%. Bpl wird als packet loss robustness Faktor bezeichnet und gibt die Unempfindlichkeit
des verwendeten Codecs gegenüber Paketverlusten an. Da die Bestimmung der Dienstgüte in
der vorliegenden Diplomarbeit mit dem G.711 (PCM) Codec durchgeführt wird, ist Ie = 0 und
Bpl = 1, wie es im Webfrontend als Default-Wert eingetragen ist. P pl ist der zu erwartende
Paketverlust in Prozent. Der neue Ie-Wert in dieser aufgeschlüsselten Form wird Ie − ef f ge-
nannt (effective equipment impairment factor).
P pl
Ie − ef f = Ie + (95 − Ie) ∗ P pl
BurstR
+ Bpl
BurstR ist der sogenannte Burstquotient (Burst Ratio) und ist folgendermaßen definiert: BurstR
ist der Quotient aus der durchschnittlich beobachteten Burst-Länge beim Empfänger und der
mittlere Länge der Bursts, die für ein Netzwerk bei zufälligem Verlust erwartet werden.
Ist der Paketverlust in einem Netzwerk zufällig, wie in der vorliegenden Diplomarbeit angenom-
men, nimmt BurstR den Wert 1 an. Bei einer Anhäufung von Paketverlusten nimmt BurstR
den Wert > 1 an. Ist der Wert größer 1, ist der Paketverlust Burst abhängig. Eine Absicherung
des Netzwerks gegenüber burstartigem Packet Loss bieten Verfahren wie das Interleaving. Ge-
nauere Informationen zum Ie Faktor finden sich in Appendix I/ITU-T G.113[5].
Vorteils-Faktor: A
A ist ein gegebener Wert, der für verschiedene Gesprächsszenarien jeweils einen Vorteilsfaktor
darstellt. Mobiltelefonieren in einem Gebäude zum Beispiel wird A mit dem Wert 5 gewichtet.
Auch in diesem Fall sollte der Default-Wert 0, der für ein konventionelles Gespräch reserviert
ist, genutzt werden.
6.3.2 MOS-Wert Berechnung
Wie bereits mehrfach erwähnt, lässt sich der MOS-Wert aus dem R-Faktor berechnen. Zu Be-
ginn muss eine Fallunterscheidung gemacht werden, da der MOS-Wert aus einem positiven
R-Faktor ermittelt werden muss. Für R-Werte kleiner null wird der MOS-Wert auf 1 gesetzt. Ist
63
6.4 Webfrontend 6 ENTWICKLUNG
der ermittelte R-Faktor größer null, wird zur Berechnung des MOS-Werts die unten stehende
Formel die dem ITU-T G.107 E-Modell entnommen ist, verwendet. Die Variable R ist der mit
der Grundformel des E-Modells R = Ro − Is − Id − Ie − ef f + A ermittelte R-Faktor. Für die
weiteren Berechnungen werden die vom ITU-T vorgegebenen Default-Werte verwendet, die im
Webfrontend (Kap.: 6.4) übernommen wurden und in Tabelle 29 ersichtlich sind.
M OS = 1 + 0, 035 ∗ R + R ∗ (R − 60) ∗ (100 − R) ∗ 0, 000007
6.4 Webfrontend
Um eine möglichst einfache Bedienung der Applikation gewährleisten zu können, wurde eine
Webapplikation mit den Programmiersprachen HTML, JavaScript und PHP Version 4 entwi-
ckelt. Der Aufbau dieser Applikation ist recht übersichtlich gehalten. Im Wesentlichen besteht
das Webfrontend aus den in Tabelle 24 vorgestellten Dateien.
Das Zusammenspiel der einzelnen PHP-Dateien wird im Programmablaufplan (Abb.: 22) dar-
gestellt. Um eine gute Übersicht zu gewährleisten, wurden Eingriffe durch den Benutzer mit
gestrichelten Linien markiert, die vom vorhergesehenen Programmablauf abweichen.
Ein wichtiges Hilfsmittel für den Benutzer stellen die Informationsschaltflächen bei Eingabe-
oder Auswahlfeldern dar. Hier wird dem Benutzer jeweils eine kurze Information über die Funk-
tion und die Grenzwerte des einzustellenden Werts angezeigt. Die Informationsschaltflächen
sind in der Programmiersprache JavaScript realisiert worden (Anhang Listing: 20).
6.5 Steuerprogramme client und server

Die beiden Programme client (Anhang Listing: 21) und server (Anhang Listing: 22) sind als
Steuerprogramme für das zusätzliche Aufzeichnen der Messdaten über tethereal vorgesehen.
Die Programme sind notwendig, da beim Starten einer Messung durch das Webfrontend auch
Daten der Gegenseite für eine one way Auswertung aufgezeichnet werden sollen. Wie die Pro-
grammnamen schon suggerieren, sind client und server Programme, die nach dem Client/Server-
Prinzip arbeiten. Die Programme bauen eine bidirektionale TCP-Verbindung (Kap.: 4.3) über
einen beliebigen Port auf. Voreingestellt ist Port 1112, da dieser vom IANA nicht als ein well
known Port reserviert ist. Da die Verbindung nicht verschlüsselt ist, ist es zum Schutz vor
Missbrauch notwendig, zu überprüfen, ob die übertragenen Befehle gültig sind. Würde diese
Überprüfung nicht stattfinden, würde jeder übertragene Befehl über den Funktionsaufruf sys-
tem() ausgeführt werden. Das Shell-Skript regulator.sh übernimmt auf der Seite des RTP-Proxys
die Befehlsüberprüfung. Das Skript kann um eine beliebige Anzahl von Befehlen erweitert wer-
den.
64
6.6 Steuer- und Konfigurationsskripte 6 ENTWICKLUNG
Dateiname Funktionsbeschreibung
index.html Ist die Haupseite, welche die Größe und Form des Rahmens
setzt und das Projekt Logo lädt.
generatorsettings.php Ist die Konfigurationsseite für sessionunabhängige Ein-
stellungen. Außerdem können die tethereal-Parameter ein-
gestellt werden. Auf dieser Seite kann eine theoretische
Abschätzung des R-Faktors vorgenommen werden. Die ein-
gestellten Daten fließen dann in die Messung mit ein.
action.php Zeigt die eingestellten Werte von generatorsettings.php an
und prüft diese Werte auf Fehler. Sollte eine falsche Ein-
stellung erkannt werden, erscheint diese rot.
session.php Wird in die Datei action.php eingebunden und ist die Ein-
stellungsmaske für die sessionspezifischen Werte. sessi-
on.php wird genauso oft eingebunden wie in der Datei ge-
neratorsettings.php im Feld Sessions angegeben.
action2.php In action2.php werden die Einstellungen von session.php
geprüft. Außerdem werden an dieser Stelle die Messun-
gen gestartet. Dies geschieht durch das Aufrufen von
Shell-Skripten, welche die Steuerung der Binärprogramme
übernehmen.
config.php Konfigurationsdatei für index.php
index.php Gibt die Messergebnisse auf dem Bildschirm aus. Dabei
wird die Anzahl der Spalten automatisch bestimmt. Über
die Datei config.php muss index.php angegeben werden,
wieviele Zeilen benötigt werden.
stopgen.php Wird der Generator im Last-Modus gestartet, muss er über
ein extra Programm gestoppt werden. Dieses PHP-Skript
ruft das Programm auf, das den Generator unterbricht.
Tabelle 24: Dateien des Webfrontends und deren Funktion
6.6 Steuer- und Konfigurationsskripte

Eine Vielzahl von Konfigurationsskripten wird in dem Projekt als Mittler zwischen dem Aus-
wertungsteil und dem Echtzeitteil verwendet. Außerdem hat es sich wegen der Komplexität
des Programms und der großen Zahl enthaltener Einzeldateien als notwendig erwiesen, ein
Installations- und Konfigurtionsskript zu erstellen. Die Funktionsweise des Konfigurationss-
kripts wird in der Abbildung 23 verdeutlicht.
Hierdurch wird die nötige Flexibilität für das Einrichten der entwickelten Applikation auf einem
anderen Computer gewährleistet. In der Tabelle 25 werden die verwendeten Skripte vorgestellt
und beschrieben. Eine Ausnahme bildet die Datei .qossip config, die als Konfigurationsdatei
für alle Skripte dient.
65
6.7 Funktionstest 6 ENTWICKLUNG
Abbildung 22: Ablaufplan des Webfrontends
6.7 Funktionstest
Schon während der Entwicklung der Applikationen wurden Teilfunktionen getestet. So wur-
den die von gensend.bin und genrcv.bin aufgezeichneten Zeitstempel mit denen einer ethereal-
Aufzeichnung verglichen. Die Übertragung der TOS/DSCP-Werte wurde bei der Erweiterung
des RTP-Proxys eingehend getestet.
Nach der Fertigstellung des Programms calculate wurden Messungen über einen langen Zeit-
raum aufgezeichnet und mit den Ergebnissen aus Messungen mit dem Programm iperf ver-
glichen, um Aussagen über Packet Loss, Jitter und Delay zu erhalten. Zur Generierung von
Package Loss, Jitter und Delay diente in diesem Fall das Programm NetSim, das im Rahmen
des FH3 -Projekts von Stefan Abu Salah entwickelt wurde. Mit dem Programm NetSim können
DSCP-Klassen angelegt werden. Der Netzverkehr einer DSCP-Klasse kann dann mit definier-
tem Package Loss, Jitter und Delay belegt werden, um so künstlich Netzstörungen zu erzeugen.
Vom RTP-Generator aufgezeichnete Messungen wurden auf auffällige Merkmale wie Package
Loss und Sequenzfehler die duch Jitter hervorgerufen werden untersucht. Diese markanten Wer-
te wurden dann mit den Ausgabegrafiken des Webfrontends und einer ethereal-Aufzeichnung
verglichen.
66
Abbildung 23: Ablaufplan des Konfigurationsskripts
Außerdem wurde untersucht, ob die CPU-Auslastung Einfluß auf die Aufzeichnungsgenauig-

keit der Messdaten hat. Mit dem Programm stress wurde die CPU-Last (CPU-Load)44 mehrerer
Computer von 1 bis 10 skaliert. Dies hatte jedoch keine messbare Auswirkung auf die Ergeb-
nisse.
Wichtig für eine genaue Messung ist die Unabhängigkeit der einzelnen Aufzeichnungssessions.
Da bei der Entwicklung des RTP-Generators Lasterzeugung im Vordergrund stand, galt es zu
überprüfen, ob sich mehrere RTP-Sessions beim Senden oder Empfangen gegenseitig beein-
flussten.
Zwei Computer wurden mit einem Crossed-Twisted-Pair-Kabel45 miteinander verbunden. Die
Übertragungsrate von 100 MBit/s fullduplex ist für diese Messung mehr als ausreichend, da bei
44
Mit Load bezeichnet man die momentane Auslastung eines Computersystems. Ein Load von 1 entspricht 100%
CPU-Auslastung bei einem Prozessor.
45
Ein Crossed-Twisted-Pair-Kabel ist ein Netzwerkkabel, das zum direkten Vebinden von zwei Netzwerkkarten be-
nuzt werden kann.
67
Shell-Skript Funktionsbeschreibung
config.sh Erfragt vom Benutzer für die Installation notwendige Einstellun-
gen und speichert diese. Außerdem kopiert config.sh das Web-
frontend in das Webserver-Verzeichnis und passt die PHP-Dateien
an. Es ist optional möglich, die C/C++ Applikationen neu zu kom-
pilieren. Siehe auch Abbildung 23.
compile generator.sh Wird von config.sh aufgerufen und kompiliert die Programme
gensend.bin und genrcv.bin neu.
generator.sh Ist das Hauptskript zum Aufrufen des Generators. Es bereitet
das System auf das Starten des Generators durch Löschen al-
ter Datensätze und das Beenden noch laufender Prozesse vor.
Danach startet generator.sh die Programme genreceive.bin und
gensend.bin mit den vom PHP-Skript übergebenen Parametern.
Nach der Aufzeichnungsphase führt das Skript das Programm
calculate aus und kopiert die Ausgabedateien in das Webserver-
Verzeichnis.
steuer.sh Steuert die tethereal Aufrufe.
output.sh Kopiert die Log-Dateien in das Webserver-Verzeichnis.
regulator.sh Überprüft, ob das Programm server einen gültigen Befehl erhalten
hat.
generate-callflow.sh In diesem Skript wird das Programm callflow aufgerufen.
generate-callflow.sh übergibt callflow Filterregeln (filter) und
Aufträge (order), welche in den lokalen Dateien filter und order
gespeichert sind.
callflow.sh Ist das Hauptskript von callflow und steuert das Extrahieren der
benötigten Datensätze aus der tethereal Capture-Datei. Zu diesem
Zweck startet callflow.sh eine Vielzahl von grep, awk und sed
Aufrufen. Ergebnis ist die Ausgabe der Diagramme im Bildfor-
mat .svg und .jpeg.
Konfigurationsdatei Funktionsbeschreibung
.qossip config Beinhaltet systemspezifische Variablen, die von den Shell-
Skripten verwendet werden.
Tabelle 25: Steuer- und Konfigurationskripte
100 parallelen Sessions nur circa 9 MBit/s ( G.711, 89 kbit/s mit Overhead im LAN * 100 Ses-
sions) Netzlast erwartet werden. In der ersten Messung wurde bei einer Aufzeichnungssession
die Anzahl der Generatorsessions erhöht und das Delay gemessen.
Abbildung 24: Versuchsaufbau
68
Abbildung 25: Generatorsessionabhängige Delay-Messung
Im Auswertungsdiagramm ist zu erkennen, dass die Delay Zeiten bei zunehmender Generator-
sessionzahl leicht ansteigen. Erklärt werden kann dies mit der zunehmende Verarbeitungszeit in
der Netzwerkschnittstelle. Für die Bestimmung des R-Faktors ist diese Abweichung jedoch so
gering, dass sie vernachlässigt werden kann. Der Einbruch bei der 5 Sessions lässt sich durch
die Messungenauigkeit erklären, da nur eine Messreihe verwendet wurde.
In einer weiteren Messung wurde die Anzahl der Aufzeichnungssessions erhöht. Die Anzahl
der Generatorsessions ist pro Aufzeichnungssession zehn. Bei gleichem Versuchsaufbau wurde
jeweils die erste Aufzeichnungssession ausgewertet.
Bei steigender Anzahl der Aufzeichnungssessions ist auch hier ein leichter Anstieg der De-
lay Zeit zu erkennen. Die Größenordnung ist aber annähernd gleich wie bei der Messung mit
nur einer Aufzeichnungssession. Die Aufzeichnung der Messdaten hat somit bis 100 Sessions
keinen Einfluss auf die Messergebnisse. Zu beachten ist, dass in den Diagrammen 25 und 26
Messungenauigkeit von 1 ms angenommen werden muss.
69
7 INSTALLATION
Abbildung 26: Messsessionabhängige Delay Messung
7 Installation
7.1 Systemvoraussetzungen
Die Installation setzt ein Debian GNU/Linux System voraus, das auf den stabilen Zweig des
Debian Repositories aufbaut. Das Netzwerk muss eingerichtet sein und als Default-Konsole
sollte die bash-Konsole vorhanden sein.
7.2 Debian Zusatzpakete installieren

Programme aus dem Debian Repositories werden mit dem Programm apt-get oder einem der
auf diesem Progamm aufbauenden GUI wie beispielsweise aptitude oder synaptic installiert. Da
das JRE (Java Runtime Environment) nicht im offiziellen Debian Repositories zur Verfügung
steht, muss zu Beginn die Datei /etc/apt/sources.list um die unten folgenden Einträge ergänzt
werden. Als Editor kann das Programm vi benutzt werden, das fast in jeder Linux Distribution
vorinstalliert ist. In den folgenden Zeilen sind die Debian-Sourcen aufgeführt die hinzugefügt
werden müssen:
deb http://ftp.debian-unofficial.org/debian sarge main

contrib non-free restricted
deb-src http://ftp.debian-unofficial.org/debian sarge main
contrib non-free restricted
70
7.2 Debian Zusatzpakete installieren 7 INSTALLATION
Nach der Änderung muss die Paketdatenbank aktualisiert werden. Mit dem Befehl
apt-get update
werden die Paketlisten erneuert.

Mit der folgenden Befehlszeile werden die benötigten Debianpakete nachinstalliert:
apt-get install gawk sed apache apache-common php4-common

libapache-mod-php4 php4-common vim modconf
sun-j2se6.0-jre-binary libbatik-java imagemagick
bash grep tethereal ssh gnuplot automake
autoconf libstdc++6 libstdc++6-dev gcc g++
Eventuelle Systemnachfragen können mit dem Default-Wert, den das Debian-Konfigurations-

skript vorschlägt, bestätigt werden. Sollten zur Installation noch weitere Programme nötig sein,
werden diese von dem Installationsprogramm apt-get automatisch rekursiv aufgelöst und nachin-
stalliert.
Wenn der Computer, auf dem der RTP-Generator installiert werden soll, die nötige Rechenleis-
tung für einen X-Server besitzt, ist es sinnvoll, einen Windowmanager mit einem Webbrowser
zu installieren. Dies ist zwar nur eine optionale Möglichkeit, hat aber viele Vorteile. Beispiels-
weise kann das Programm ethereal benutzt werden, um weitere Auswertungen des aufgezeich-
neten Datenverkehrs zu bekommen. Die im nächsten Abschnitt aufgeführte Befehlszeile be-
wirkt das Installieren des X-Servers mit dem X-Window-System46 xfce4 (The Cholesterol Free
Desktop Environment Version 4)47 . Außerdem werden der Webbrowser Firefox und das Pro-
gramm ethereal installiert.
apt-get install x-window-system xfce4 mozilla-firefox ethereal
Auf dem Computer, der später als SER-Server und RTP-Proxy arbeiten soll, müssen ebenfalls
einige Programme nachinstalliert werden. Die folgende Befehlszeile erweitert das System um
die benötigten Programme:
apt-get install ser gcc bash vim tethereal ssh mc
Nach der Installation der Debian-Pakete müssen einige Konfigurationsdateien angepasst wer-
den. Außerdem müssen Voraussetzungen geschaffen werden, damit die programmierten Appli-
kationen eine möglichst homogene Systemumgebung benutzen können.
46
Das X-Window-System ist eine Sammlung von Protokollen, Programmen und Standards zur Ansteuerung grafi-
scher Bildschirme.
47
xfce4 ist ein ressourcenschonender Fenstermanager.
71
7.3 Benutzer einrichten 7 INSTALLATION
7.3 Benutzer einrichten

Es empfiehlt sich, einen neuen Benutzer anzulegen, da Webserver, Shell-Skripte und Binär-
Programme vom selben Benutzer aufgerufen werden müssen. Das Einrichten eines neuen Be-
nutzers ist sehr einfach. Auf der Konsole wird der Befehl adduser aufgerufen. Als Default-
Benutzername wird in der vorliegenden Diplomarbeit qossip benutzt. Aus diesem Grund ist es
sinnvoll, eben diesen als Benutzernamen zu verwenden. Jeder andere Benutzername ist jedoch
auch möglich.
adduser qossip
7.4 Apache Webserver einrichten

Der Webserver läuft nach der Installation mit den lokalen Rechten des Benutzers www-data und
den Gruppenrechen der Gruppe www-data. Da dieser Benutzer kein home-Verzeichnis hat und
nicht die Systemrechte hat, andere Programme auszuführen, muss in der Konfigurationsdatei
des Apache Webservers der für diesen Zweck angelegte Benutzer eingetragen werden. In einem
weiteren Konfigurationsschritt muss das PHP-Modul eingerichtet werden. Beginnend wird die
Datei /etc/apache/http.conf mit einem Editor geöffnet. In der Konfigurationszeile User www-
data muss www-data durch den in Kapitel 7.3 eingerichteten Benutzernamen geändert werden.
Danach müssen in der Datei /etc/apache/http.conf die folgenden Zeilen auskommentiert werden,
damit der Webserver auch PHP-Seiten anzeigen kann:
AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps
Damit sind die Änderungen der Konfigurationsdatei des Apache Webservers beendet. Der Auf-
ruf des Befehls
dpkg-reconfigure apache
gibt dem Benutzer jetzt die Möglichkeit, Module, die dem Webserver zur Verfügung stehen, zu
aktivieren. Das Modul mod php4 kann über das Konfigurations-GUI sehr leicht eingebunden
werden, ohne dass weitere Konfigurationsdateien editiert werden müssen.
Abschließend wird mit dem Befehl
/etc/init.d/apache restart
der Webserver neu gestartet. Die Änderungen der Konfiguration werden übernommen. Über ein
einfaches PHP-Skript kann nun überprüft werden, ob der Webserver ordnungsgemäß funktio-
niert. Im Editor wird eine Datei mit dem Namen info.php erzeugt, die den Inhalt von Listing
18 hat. Diese Datei wird im Hauptverzeichnis (Document root) des Webservers abgelegt. Das
Hauptverzeichnis des Webservers ist bei dem Apache Webserver in der Version 1.3 per Default
/var/www/.
72
7.5 SER einrichten 7 INSTALLATION
Listing 18: PHP Informationsabfrage

1 <?php
2
3 / / Show a l l i n f o r m a t i o n , d e f a u l t s t o INFO ALL
4 phpinfo ( ) ;
5
6 / / Show j u s t t h e module i n f o r m a t i o n .
7 / / phpinfo (8) yields i d e n t i c a l r e s u l t s .
8 p h p i n f o ( INFO MODULES ) ;
9
10 ?>
Über die URL http://localhost/info.php48 kann die PHP-Seite aufgerufen werden. Die Funkti-
on phpinfo() gibt Auskunft über PHP und die Funktion phpinfo(INFO MODULES) zeigt dem
Benutzer die geladenen PHP-Module.
7.5 SER einrichten

Auf dem Computer, der als SIP- und RTP-Proxy dienen soll, müssen ebenfalls Änderungen
vorgenommen werden. In der vorliegnden Diplomarbeit wurde der SER als vorkompiliertes
Programm aus dem Debian Repositories installiert. Das Kompilieren des Programms aus dem
Quellcode ist nicht notwendig. Es müssen lediglich die Konfigurationsdateien des SER an-
gepasst werden. Die zu editierende Datei /etc/ser/ser.cfg muss um die folgende Zeile ergänzt
werden, die das Nathelper-Modul lädt:
loadmodule "/usr/lib/ser/modules/nathelper.so"
Erhält der SER eine SIP-Nachricht mit der Methode INVITE, müssen die Sessioninformatio-
nen, die für den RTP-Verbindungsaufbau notwendig sind, an den RTP-Proxy übermittelt wer-
den. Listing 19 enthält den zu ändernden Teil der SER-Konfigurationsdatei:
Listing 19: SER-Konfiguratinsdatei ser.cfg

1 ...
2 i f ( method == ” INVITE ” ) {
3 i f ( lookup ( ” l o c a t i o n ” ) ) {
4 i f ( a f == i n e t )
5 i f ( f o r c e r t p p r o x y ( ” FAII ” ) )
6 t o n r e p l y ( ”1” ) ;
7 }
8 else {
9 s l s e n d r e p l y ( ” 403 ” , ” U s e r n i c h t e r r e i c h b a r o d e r u n b e k a n n t ! ” ) ;
10 break ;
11 };
12 };
13 .....
14 onreply route [1] {
15 i f ( ! ( s t a t u s = ˜ ” 183 ” | | s t a t u s = ˜ ” 200 ” ) )
16 break ;
17 f o r c e r t p p r o x y ( ”FA” ) ;
18 }
19 ...
48
Beim Zugriff von einem entfernten Computer muss anstatt localhost die IP-Adresse oder der FQDN (Fully Quali-
fied Domain Name) angegeben werden.
73
7.6 RTP-Proxy einrichten 7 INSTALLATION
Der SER muss wie der Apache Webserver nach Abschluss der Konfiguration mit dem Befehl
/etc/init.d/ser restart
neu gestartet werden, damit die Konfigurationsänderungen übernommen werden.
7.6 RTP-Proxy einrichten

Nach dem Aufspielen des Programms auf den Zielrechner von CD oder über das Konfigurations-
Skript kann der RTP-Proxy der sowohl direkt als Binary ausgeführt werden als auch auf dem
Zielsystem kompiliert werden. Dies geschieht mit einem einfachen make-Aufruf. Das Binary
findet sich dann im Hauptverzeichnis des RTP-Proxys wieder. Das Shell-Skript rtpproxy im Ver-
zeichnispfad /etc/init.d/ startet den RTP-Proxy als Systemdienst. Ein Soft-Link in das jeweilige
Runlevel-Verzeichnis startet den RTP-Proxy beim Booten des Computers.
ln -s /etc/init.d/rtpproxy /etc/rc2.d/S20rtpproxy
7.7 Konfigurationsskripte
Die Datei mit den gepackten Programmen muss zuerst in das home-Verzeichnis des Benutzers
kopiert werden. Danach müssen die Daten mit dem folgenden Befehl entpackt werden:
tar -xvzf measure-all.tar.gz
Nach dem Entpacken kann im Unterverzeichnis generator das Konfigarationsskript aufgerufen

werden. Das Skript wird mit folgendem Befehl gestartet:
./config.sh
Das Shell-Skript erfragt beim Anwender in der ersten Phase die Systemeinstellungen und spei-
chert diese in der Datei .qossip config im home-Verzeichnis des Benutzers. In einer zwei-
ten Phase können die benötigten Programme neu kompiliert werden. Die dritte Phase bietet
zusätzlich noch die Möglichkeit, den RTP-Proxy neu zu kompilieren und diesen über scp (secu-
re copy) in das Zielsystem zu kopieren. Das Vorkompilieren ist aber nur bei der Verwendung von
Computern mit gleicher Prozessorarchitektur möglich. Sollte das Zielsystem eine abweichende
Rechnerarchitektur vorweisen, ist es notwendig, den RTP-Proxy lokal neu zu kompilieren.
Alle PHP-Webseiten werden von dem aufgerufenen Skript auf die Systempfade, die in der Datei
.qossip config gespeichert wurden, angepasst. Außerdem werden die Datei- und Gruppenrechte
der verwendeten Webseiten, Skripte und Programme auf den angegebenen Benutzer angepasst.
Nachdem das Konfigurationsskript erfolgreich beendet wurde, kann im Webbrowser das Web-
frontend über folgende URL aufgerufen werden.
http://localhost/calculate/
74
7.8 Webbrowser Information 8 BEDIENUNG
7.8 Webbrowser Information

Das Webfrontend ist mit dem Webbrowser Mozilla, Mozilla Firefox und Konqueror getestet
worden. Es ist notwendig, dass im verwendeten Browser HTTP-Proxy und Cashing deaktiviert
sind. Die Bildschirmauflösung sollte mindestens 1024x768 Pixel betragen. Optimal ist jedoch
eine Auflösung von 1280x1024 Pixel.
8 Bedienung
Das Webfrontend wird im Browser über die URL http://localhost/calculate/ aufgerufen. Auf
dem Bildschirm erscheint die Startseite (Abb.: 27) mit der sessionunabhängigen Eingabemaske.
8.1 Eingabemasken
Über die Informationsschaltfelder erhält der Benutzer jeweils eine kurze Information über das
ausgewählte Eingabefeld. Zudem ist eine Vielzahl von Werten vorkonfiguriert, so dass für einen
Funktionstest nur die Sender IP-Adresse und die RTP-Proxy IP-Adresse eingegeben werden
müssen. Da diese Einstellungen in der Regel für eine ganze Messreihe gelten, werden die IP-
Adressen im Browser in einem Cookie gespeichert und werden, solange der Browser geöffnet
bleibt, wieder verwendet.
Das Eingabefeld, Number of Generator Calls, gibt, wie auch im Informationsfeld zu lesen
ist, die Anzahl der Aufzeichnungssessions an. Der Schalter (switch) Load-Flag kann für eine
Langzeit- oder Lastmessung genutzt werden. Wird die Load-Flag Option genutzt, werden keine
Messdaten aufgezeichnet. Um den Generator im Load-Modus zu stoppen, wird ein Zusatzfens-
ter, siehe Abbildung 28, geöffnet. Wird der Button Stop Generator gedrückt, wird der RTP-
Generator unterbrochen. Der Schalter Direct-Mode und das Verändern des Ausgabedateinamen
für tehereal im Eingabefeld von Capture-File konnten leider im Zeitrahmen der Diplomarbeit
nicht verwirklicht werden und müssen auf dem Default-Wert belassen werden.
Im unteren Bereich befindet sich die Eingabemaske für das E-Modell, das zur Berechnung des
R-Faktors und des MOS-Werts benötigt wird. Für nicht konkretisierte Messungen sollten hier
die Default-Werte genutzt werden. Eine theoretische Vorhersage über ein zu erwartendes Mes-
sergebnis ist über das E-Modell möglich. Der Button Calculate berechnet den R-Faktor mit
den für das E-Modell eingegebenen Werten. Die Werte Tr, T, Ta, Delay Configuration und Ppl
dienen hier nur für eine theoretische Berechnung.
75
8.1 Eingabemasken 8 BEDIENUNG
Abbildung 27: Webfrontend Startseite
Wird nun der Button Next Step ausgewählt, werden die eingestellten Werte für die darauf-
folgende Messung verwendet. Daraufhin erscheint eine zweite Eingabemaske (Abb.: 29). Im
oberen Bereich sieht der Benutzer die wichtigen Eingaben von der Startseite. Außerdem fin-
det eine Fehlerkontrolle statt. Rot markierte Felder wurden von dem Programm als falsch oder
nicht eingegeben identifiziert und müssen erneut auf der Startseite eingegeben werden. Über
den Button Go Back gelangt der Benutzer wieder zur Startseite.
Im Bereich Advanced Generator Settings werden von dem Benutzer die für jede Session in-
dividuellen Werte erfragt. Informationen zu den Eingabefeldern können wie auf der Startseite
76
8.1 Eingabemasken 8 BEDIENUNG
Abbildung 28: Generator im Load-Modus stoppen
durch das Auswählen der jeweiligen Informationsschaltfelder entnommen werden. Die Eingabe
wird durch den Button Next Step bestätigt. Eine Wichtige Anmerkung betrifft das Feld Inter-
valtime. Duch einen Verarbeitungsfehler im RTP-Generator ist die tasächliche Intervallzeit um
1 ms erhöht. Dies ist in der Ausgabegrafik ersichtlich. Durch das Abzielen des Wertes 1000 von
gewünschten Intervallzeit wird dies korregiert.
Abbildung 29: Eingabemaske für sessionbasierte Werte
Als nächstes erscheint eine Webseite (Abb.: 30) mit Informationen über die Sessioneinstellun-
77
8.2 Ausgabemasken 8 BEDIENUNG
gen. Im Hintergrund wird die Messung gestartet. Die Messung ist beendet, wenn am unteren
Ende der Webseite, die nach der Messung erweitert wird, der Button Show Results erscheint.
Dies kann abhängig von den Einstellungen mitunter sehr lange dauern. Durch Aufrufen des
Button Show Results wird die Webseite mit der Messauswertung angezeigt.
Abbildung 30: Verarbeitungs Maske
8.2 Ausgabemasken
Auf der Ausgabe-Webseite (Abb.: 31) sieht der Benutzer zu jeder Messung fünf Ausgabegrafi-
ken. Die erste Grafik ist eine Zusammenfassung der Messsession und der Messergebnisse dieser
Session. Außerdem wird dem Benutzer über das Emoticon-Smilie eine einfache optische Qua-
litätsbeurteilung gegeben. Die Einstufung der Emoticons in Bezug auf den R-Faktor und den
MOS-Wert wird durch das Betätigen des Informationsschalters auf der Ausgabeseite angezeigt.
In der zweiten Grafik wird die Varianz der Sendepaketgenauigkeit in rot angezeigt. Der Mittel-
wert aus den Daten ist grün dargestellt und sollte der eingestellten Intervallzeit entsprechen. Die
dritte Grafik stellt dem Anwender die Empfangsvarianz der Pakete dar, in der der Mittelwert in
grün angezeigt ist. Treten bei einer Messung Sequenzfehler auf, werden diese Pakete in der Far-
be Lila markiert. Gehen bei der Übertragung Pakete verloren, wird die erwartete Position des
Pakets mit einem blauen Kasten der Höhe 1 umrahmt. Die vierte Grafik gibt die Paketlaufzeit
78
Abbildung 31: Ausgabe der Messergebnisse
round trip time an. In grün ist der Mittelwert dargestellt. Die fünfte Grafik stellt den Jitter dar.
Berechnet wird der Jitter wie in Kapitel 4.7.3 beschrieben. Auch hier ist der Mittelwert in grün
dargestellt.
79
Ergänzend zu den Messwerten ist es möglich, den Verbindungsaufbau von bis zu zehn aufge-
bauten Sessions anzusehen. Über den Link Callflow gelangt man zu dem Sequenz-Diagramm
(Abb.: 32). Über die Links Receiver Output und Sender Output kann überprüft werden, ob alle
gensend.bin und genrcv.bin Sessions ordnungsgemäß auf- und abgebaut wurden.
Abbildung 32: Ausgabe des Sequenz-Diagramms
80
9 MESSUNGEN
9 Messungen
In diesem Kapitel wird anhand einiger exemplarischer Messungen die Funktionsweise der ent-
wickelten Applikation veranschaulicht. Dabei werden Störfaktoren im Netzwerk von dem Pro-
gramm NetSim simuliert. In dem Versuchsaufbau, der in Abbildung 33 dargestellt ist, befinden
sich die Computer in demselben Netzsegment49 . Der Computer, auf dem das Programm Net-
Sim gestartet ist, hat drei Netzwerkkarten. Die Netzwerkschittstellen eth1 und eth2 arbeiten
auf der ISO OSI-Schichtebene 2 im Bridging-Modus50 . Dabei wird eth0 wird zur Steuerung
von NetSim genutzt und ist für die Messung irrelevant. Während auf dem Notebook mit dem
Hostnamen jabba die Messapplikation läuft, stellt der Computer mit dem Hostnamen alert den
SER mit RTP-Proxy. Wie bereits im Kapitel 6.7 beschrieben, ist die Rechenleistung heutiger
Computer mehr als ausreichend und hat daher keinen Einfluss auf die Messergebnisse. Deshalb
wird auf eine genaue Hardwarebeschreibung verzichtet.
Abbildung 33: Versuchsaufbau
In der ersten Messung wurden im Programm NetSim zwei DSCP-Klassen definiert. Die Klasse
mit dem DSCP-Wert 0x0 ist dabei die Default-Klasse, dessen Datentransfer im Verlauf der
Messreihe gestört wurde. 0x3 ist die zweite Klasse und wurde nicht durch NetSim beeinflusst.
49
Netzsegment bedeutet an dieser Stelle, dass die Computer sich in demselben Subnetz befinden.
50
Eine Bridging verbindet in einem Computernetz zwei Segmente auf der Sicherungsschicht im ISO OSI-
Schichtmodell.
81
9 MESSUNGEN
Ziel der Messung war, zu bestimmen, wie stark NetSim die IP-spezifischen Parameter der
DSCP-Klasse 0x0 verschlechtert und ob die gemessenen Werte mit den in NetSim eingestellten
Werten übereinstimmen. Über die priorisierten Datenkanäle in NetSim wurden für beide Klas-
sen VoIP-Verbindungen aufgebaut, und mit Hilfe der Messapplikation wurde die Qualität der
Verbindung gemessen.
Übertragen auf ein reales Netzwerk mit der Möglichkeit für QoS wäre die Default-Klasse 0x0
das Netzwerk ohne Priorisierung. Die Klasse 0x3 wäre im Vergleich zur Default-Klasse bevor-
zugt, da eine quasi-Priorisierung der Klasse 0x3 vorliegt.
Zuerst wurde eine Messung ohne Last und einem Delay von 100 ms auf der Klasse 0x0 durch-
geführt. Da jedes Datenpaket zweimal NetSim durchläuft, ist die eingestellte Verzögerung mit
zwei zu multiplizieren, um einen theoretischen Erwartungswert zu erhalten. Danach wurde die
Verzögerung unter Netzlast gemessen. Zur Lasterzeugung dienten in diesem Fall mehrere flood
ping51 und ein Dateitransfer über scp. Diese Messung wurde dann mit doppelter Delay Zeit für
die Klasse 0x0 wiederholt. Das Ergebnis ist in Abbildung 34 grafisch dargestellt.
Abbildung 34: Messergebnisse 1
Die Verzögerung der Klasse 0x0 ist deutlich zu erkennen. Die Klasse 0x3 hingegen wird weni-
ger beeinflusst. Die gewählten Intervallzeiten decken dabei einen Bereich ab, der von gängigen
Codecs verwendet wird. Der MOS-Wert52 liegt bei der Verzögerung von 530 ms bei 3,9. Dies
entspricht immer noch einer zufriedenstellenden“ Sprachqualität (Anhang Abb.: 37). Die Er-
”
gebnisse aus der Messung für die Klasse 0x3 liegen in allen Messungen bei einem MOS-Wert
von 4,4.
51
Ein flood ping sendet so viele ICMP-Pakete wie möglich zur Empfängerseite und erzeut somit Netzlast.
52
Wird im Folgenden von MOS-Wert gesprochen, so bezieht sich das auf den MOS-LQ-Wert.
82
9 MESSUNGEN
In einer weiteren Messung werden zwei weitere DSCP-Klassen zu den bestehenden hinzu-
gefügt. Die vorgenommene Einstellung der Klassen ist der Tabelle 26 zu entnehmen. Nun wur-
de ein theoretischer Erwartungswert mit dem Berechnungswerkzeug für das E-Modell aus dem
Webfrontend ermittelt. Diese theoretischen Werte können ebenfalls der Tabelle 26 entnommen
werden. Es wurden wie bei der ersten Messung Sessions mit 1000 Paketen in den Intervall-
grenzen von 10 ms bis 30 ms aufgezeichnet. Die Auswertung der Messergebnisse ist in der
Abbildung 35 dargestellt. Zu erkennen ist, dass der theoretisch ermittelte Wert mit der Messung
beinahe übereinstimmt.
DSCP-Klasse Delay Jitter Packet Loss Erwartungswert

für den R-Faktor
0x0 250 ms 0% 0% 79
0x3 0 ms 0% 0% 93
0x5 500 ms 10 % 0% 54
0x7 500 ms 10 % 1% 0
Tabelle 26: Angelegte DSCP-Klassen und deren IP-spezifischen Parameter
In der folgenden Messung wird das Verhältnis von MOS-Wert und Packet Loss verdeutlicht. Es
wurden zwei DSCP-Klassen angelegt mit identischen Parametern. In der Klasse 0x3 wurde im
Verlauf der Messung der Packet Loss, den das Programm NetSim erzeugt, skaliert. Das Resultat
ist in Abbildung 36 dargestellt und zeigt deutlich das Verhältnis von MOS-Wert zum Packet
Loss. Schon ein Packet Loss von 1% führt zu einem MOS-Wert, der mit nicht empfohlen“
”
bewertet wurde.
83
10 KRITISCHE BETRACHTUNG
10 Kritische Betrachtung
Aufgrund der Tatsache, dass die zu entwickelnden Applikationen Teil eines Forschungsprojekts
sind, konnte zu Beginn das Aufgabenfeld nicht genau abgesteckt werden. Erst im Verlauf der
Entwicklung konnten die Ziele konkretisiert und zeitlich abgeschätzt werden. Daraus ergeben
sich einige Kritikpunkte.
Zu Beginn der Planungsphase stand die Idee im Vordergrund, existierende freie VoIP-Mess-
programme zusammenzufassen und aus einer Vielzahl von Messungen deren Dienstgüte zu
bestimmen. Da es kaum geeignete Tools gibt, die lediglich hätten konfiguriert werden müssen,
änderte sich das Grundkonzept hin zur Entwicklung einer eigenständigen Applikation. Da die
Entwicklung und Programmierung sehr viel zeitaufwendiger ist, konnte auf Aspekte der prak-
tischen Analyse von Audiodaten leider nicht näher eingegangen werden. Die zeitgleiche Ent-
wicklung des RTP-Generators hatte zwar einerseits den Vorteil, dass Synergien bei der Ent-
wicklung an den Programmen des RTP-Generators genutzt werden konnten, andererseits aber
den Nachteil, dass funktionsfähige Generatorversionen erst in einem fortgeschrittenen Stadium
der Entwicklungsphase zur Verfügung standen.
Da sehr viele unterschiedliche Applikationen angepasst werden mussten, konnte keine einheit-
liche Programmiersprache verwendet werden. Aus diesem Grund mussten viele Schnittstellen
auf Kosten der Übersichtlichkeit geschaffen werden. Diese dienten einzig dem Datenaustausch
zwischen den Programmen. Weiter konnten nur exemplarische Messungen durchgeführt wer-
den, da die für die Messungen vorgesehene MPLS-Verbindung, welche über QoS-Merkmale
verfügt, zum Zeitpunkt der Fertigstellung der vorliegenden Diplomarbeit noch nicht zufrieden-
stellend funktioniert.
84
11 FAZIT
11 Fazit
Die entwickelten Applikationen bieten die Möglichkeit, die Dienstgüte einer oder mehrerer par-
alleler VoIP-Verbindungen anhand der RTP-Datenströme zu bestimmen. Theoretischer Anker
für die Dienstgütebestimmung (QoS) bildet in der vorliegenden Diplomarbeit das E-Modell,
und die vom RTP-Generator aufgezeichneten Messwerte bilden die Berechnungsgrundlage.
Für Messungen, die quantitativen Charakter haben, ist das Programm in der jetzigen Version
sehr gut geeignet. Die Applikationen arbeiten zuverlässig innerhalb der getesteten Grenzen.
Bedienung und Ausgaben sind übersichtlich und gut verständlich. Qualitative Messwerte sollten
allerdings erst nach einigen Referenzmessungen mit geeichten Messgeräten wie beispielsweise
Data Network Analyzer DA3400 von der Firma JDSU (Lit.: (23)) vorgenommen werden.
Die Erweiterung des RTP-Generators um die Möglichkeit, Audiodateien zu übertragen, um Au-
dio-Messungen in die Dienstgütebestimmung einfließen zu lassen, und die Entwicklung einer
erweiterten Steuereinheit zwischen RTP-Generator und RTP-Proxy wäre ein wünschenswerter
Ausblick in die Zukunft des Projekts.
Die in der vorliegenden Diplomarbeit erstellten Programme, Skripte und Konfigurationsdatei-
en wurden nur auszugsweise oder gar nicht dargestellt. Da circa 16 KByte Shell-Skripte, 78
KByte HTTP-,PHP- und JavaScript-Code, 110 KByte C/C++-Code und 40 KByte teilweise
veränderte Konfigurationsdateien erstellt wurden, wird auf eine Ausgabe im Anhang verzich-
tet. Der vollständige Quellcode befindet sich auf der CD, die der vorliegenden Diplomarbeit
beigelegt ist.
85
12 ABKÜRZUNGSVERZEICHNIS
12 Abkürzungsverzeichnis
Abkürzung Beschreibung
ACK Acknowledge
ACR Absolute Category Rating
ADPCM Adaptive Differential Pulse Code Modulation
ADSL Asymmetric Digital Subscriber Line
ANSI American National Standards Institute
API Application Programming Interface
ATM Asynchronous Transfer Mode
BMBF Bundesministerium für Bildung und Forschung
CCR Comparison Category Rating
CMOS CCR MOS
CNAME Canonical Name
CoS Class of Service
CPU Central Processing Unit
CSV Comma Separated Values
dB Dezibel
DCF77 D für Deutschland, C für Langwellensender, F wegen der Nähe zu
Frankfurt und 77 entsprechend der Trägerfrequenz
DCR Degradation Category Rating
DiffServ Differentiated Services
DMOS DCR MOS
DNS Domain Name Server
DS DiffServ
DSCP Differentiated Services Code Point
DSP Digital Signal Processor
ENUM Telephone Number Mapping
ETSI European Telecommunications Standardization Institute
FTP File Transfer Protocol
FQDN Fully Qualified Domain Name
GNU GNU is Not Unix
GPL GNU General Public License
GPS Global Positioning System
GUI Graphical User Interface
HA Home Agent
HEX Hexadezimalsystem
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
Hz Hertz
86
I/O Input/ Output
IANA Internet Assigned Numbers Authority
IAX Inter-Asterisk Exchange
ICMP Internet Control Message Protocol
ID Identification
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IHL Internet Header Length
IntServ Integrated Services
IP Internet Protocol RFC 791
IPC Inter Process Communication
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IPX Internetwork Packet Exchange
IS-IS Intermediate System to Intermediate System Protocol
ISDN Integrated Services Digital Network
ISO International Organization for Standardization
ISP Internet Service Provider
ITU International Telecommunication Union
ITU-T International Telecommunication Union, Abteilung Telekommunika-
tion
JRE Java Runtime Environment
KDE K Desktop Environment
MAC Media Access Control
MBZ Must Be Zero
MIPS Million Instructions Per Second
MOS Mean Opinion Score
MOS-CQ MOS Conversation Qualtity
MOS-LQ MOS Listening Quality
MPLS Multiprotocol Label Switching
ms Millisekunde
NAT Network Address Translation
NSP Network Service Provider
NTP Network Time Protocol
OPINE Overall Performance Index Model for Network Evaluation
OS Operating System
OSI Open Systems Interconnection Reference
OSPF Open Shortest Path First
87
OSR Open Speech Repository
PAR Positive Acknowledgment with Re-transmission
PAT Port Address Translation
PBX Private Branch Exchange
PCM Puls Code Modulation
PCMA PCM A-Law
PCMU PCM U-LAW
PHB Per Hop Behaviours
PSQM Perceptual Speech Quality Measure
PSTN Public Switched Telephone Network
QoS Quality of Service
QoSSIP Projektname: Quality of Service Session Initiation Protocol
QT Firma Trolltech (früher Quasar Technologies)
R-CQ R-Faktor-Conversational Quality
RFC Requests for Comments
RR Receiver Reports
RSVP Resource Reservation Protocol
RTCP Realtime Transport Control Protocol
RTP Realtime Transport Protocol
RTSP Realtime Transport Streaming Protocol
SDES Source Description
SDP Session Description Protocol
SER SIP Express Router
SIP Session Initiation Protocol
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SPX Sequence Packet Exchange
SR Sender Reports
SSH Secure Shell
SYN Synchronize
TCP Transmission Control Protocol
TDF Télédiffusion De France
TOS Type of Service
TSC Time Stamp Counter
TTC Telecommunication Technology Committee
TTL Time To Live
UA User Agent
UAC User Agent Client
88
13 RFC-VERZEICHNIS UND SOFTWARE-INTERNETSEITEN
UAS User Agent Server
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VLAN Virtual Local Area Network
VoIP Voice over Internet Protocol
VQmon Voice Quality Monitoring
13 RFC-Verzeichnis und Software-Internetseiten
RFC Bezeichnung
RFC 768 User Datagram Protocol
RFC 791 TRANSMISSION CONTROL PROTOCOL
RFC 1042 Standard for the Transmission of IP Datagrams over IEEE 802 Net-
works
RFC 1122 Requirements for Internet Hosts – Communication Layers
RFC 1323 TCP Extensions for High Performance
RFC 1349 Type of Service in the Internet Protocol Suite
RFC 1633 Integrated Services in the Internet Architecture: an Overview
RFC 1889 RTP: A Transport Protocol for Real-Time Applications
RFC 1890 RTP Profile for Audio and Video Conferences with Minimal Control
RFC 2205 Resource ReSerVation Protocol (RSVP)
RFC 2327 SDP: Session Description Protocol
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers
RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations
RFC 2806 URLs for Telephone Calls
RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access
to Telephone Call Services
RFC 2976 The SIP INFO Method
RFC 3261 SIP: Session Initiation Protocol
RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol
(SIP)
RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method
RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC 3550 RTP: A Transport Protocol for Real-Time Applications
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)
RFC 3775 Mobility Support in IPv6
Tabelle 27: In der Diplomarbeit verwendete Request for Comments
89
13 RFC-VERZEICHNIS UND SOFTWARE-INTERNETSEITEN
Software URL
Debian GNU/Li- http://www.debian.org/
nux
Asterisk PBX http://www.asterisk.org/
SIP Express Rou- http://www.iptel.org/ser
ter (SER)
RTP-Proxy http://www.portaone.com/resources/downloads
SIPSet API http://www.vovida.org
kphone http://sourceforge.net/projects/kphone
linphone http://www.linphone.org/
Twinkle http://www.twinklephone.com/
Ekiga http://www.gnomemeeting.org/
Gnuplot http://www.gnuplot.info/
Gnuplot i http://ndevilla.free.fr/gnuplot/
Tethereal http://www.ethereal.com
Ethereal http://www.ethereal.com
Callflow http://callflow.sourceforge.net/
Apache http://www.apache.de/
PHP http://www.php.net/downloads.php
ImageMAgick http://imagemagick.sourceforge.net/
Dietsniff http://www.ularx.de/dietsniff/
Iperf http://www.noc.ucf.edu/Tools/Iperf/default.htm
SIPP http://sipp.sourceforge.net/
RAT http://www.vrvs.org/
Live555 http://www.live555.com/
Gawk http://www.gnu.org/software/gawk/gawk.html
Sed http://sed.sourceforge.net/
Vim http://www.vim.org/
Bash http://www.gnu.org/software/bash/
Grep http://www.gnu.org/software/grep/
Xfce4 http://www.xfce.org/
Firefox http://www.firefox-browser.de/
x.org http://www.x.org/
Icon URL
Pinguin http://gallery.osdn.org.ua/photos/kleinhoern-de/headset.jpg
Emoticons http://commons.wikimedia.org/wiki/Category:Smilies
Tabelle 28: Internetseiten der verwendeten Software
90
LITERATUR LITERATUR
Literatur
[1] Adrian E. Conway, Yali Zhu: Analyzing Voice-over-IP Subjective Quality as a Functi-
”
on of Network QoS: A Simulation-Based Methodology and Tool“, Computer Science De-
partment, Worcester Polytechnic Institute, 100 Institute Road and Verizon Laboratories, 40
Sylvan Road, Waltham, MA 02451, USA
[2] Badach, Anatol: Voice over IP Die Technik“, Carl Hanser Verlag, 2005, 3-446-40304-3
”
[3] Gräfe, Martin: C und Linux“, Hanser, 2005, ISB N 3-446-22973-6
”
[4] Domenico Papaleo und Stefano Salsano: ”The Linux Traffic Generator”, INFOCOM De-
partment Report, 1999, University of Rome La Sapienza“
”
[5] Hein, Mathias: TCP/IP“, mitp-Verlag, 2003, ISBN 3-8266-4094-2
”
[7] ITU-T Study Group 12: ITU-T Recommendation G.107 The E-model, a computational
”
model for use in transmission planning“, 2005, ITU-T
[7] ITU-T Study Group 12: ITU-T Recommendation Dokument TD43“, 2005, ITU-T
”
[8] Jarmo Prokkola, Mikko Hanski: QoS Measurement Methods and Tools“ 2003, VTT
”
TECHNICAL RESEARCH CENTRE
[9] Siegmund, Gerd: Next Generation Networks“, Hüchtig, 2002, 3-7785-3963-9

”
[10] Stefan Brunner, Akhlaq A. Ali Understanding VoIP Networks“, 2004, Juniper Networks
”
White Paper
[11] Cisco, QoS for Voice over IP Solutions Guide“, 2003, Cisco Systems, Inc
”
[12] Trick, U., Weber, F.: SIP, TCP/IP und Telekommunikationsnetze“, Oldenburg-Verlag,
”
2005, 3-486-57796-4
[13] Rubini, Alessandro: Linux Device Drivers“, O‘Reilly & Associates, INC, 1998, 1-56592-
”
292-1
[16] Rupp, S., Siegmund, G. and Lautenschlager, W.: SIP - Multimediale Dienste im Internet”,
”
dpunkt-Verlag, 2002, 3-89864-167-8
[15] FH-Koeln, Entwicklung eines Lastgenerators für SIP-gesteuerte RTP-Datenströme mit

”
Unterstützung von DiffServ-Klassen“ Kim Ernst, QoSSIP-Projekt, Stand Juni 2006
[16] Telchemy Inc., Voice quality measurement: Understanding VoIP“,Alan Clark, Juni 2006
”
[17] http://www.zotteljedi.de/doc/socket-buch/socket-buch.pdf, Fe-
lix Opatz, Stand Juni 2006
91
LITERATUR LITERATUR
[18] http://www.fh-wedel.de/∼si/seminare/ws01/Ausarbeitung/6.
linuxrt/LinuxRT0.htm, Echtzeit für Linux, Stand Juni 2006
[19] http://www.linux.com/guides/nag2/x-087-2-firewall.tos.
manipulation.shtml, TOS Bit Manipulation, Stand Juni 2006
[20] http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito doc/

qos.pdf, Quality of Service Networking, Stand Juni 2006
[21] http://www.voip-info.org/wiki/index.php?page=How+to+debug+
and+troubleshoot+VoIP, Debug and Troubleshoot VOIP, Stand Juni 2006
[26] http://man.he.net/, Linux Manpages, Stand Juni 2006
[23] http://www.coadm.com/test and measurement/products/

descriptions/DA-3400/product literature.html, JDSU DA3440, Stand
Juni 2006
[24] http://www.voip-wiki.de/tiki-index.php?page=Sip+Response+
Code, SIP Response Code, Stand Juni 2006
[25] http://www.ietf.org/rfc.html, RFC Request for Comments“,Stand Juni

”
2006, IETF
[26] http://man.he.net/, Linux Man Pages Online“, Stand Juni 2006

”
92
14 ANHANG
14 Anhang
Abbildung 37: Umrechnungs- und Zufriedenheitstabelle
93
E-M odell K onfigurations-Referenz
Sender Seite Empfänger Seite
OL R Dr - Faktor
Ds - Faktor
SL R s R L SR
0 dB r Punkt
Schaltungsgeräusche Nc bezogen auf 0

dBr
Codieren / Codieren /
Quantisierungs- Dekodieren Dekodieren
V erzerrung QDU
94
Übertragungsnetzwerk
Quantisierungs-
V erzerrung QDU
Raum-Hintergrundgeräusche
Pr
Raum-Hintergrundgeräusche Ps Rückkopplungsfaktoren
STM R , L STR und TEL R
Paketverlust Wahrscheinlichkeit Ppl K oppelpunkt zum Netzwerk Paketverlust auf der

Paketverlust Robustheit Bpl Übertragungsstrecke
A usrüstungsbeeinträchigungs-Faktor le
Erwartungswert-Faktor A
14
gensend.bin RTP-Proxy
round trip time Tr genrecv.bin
M ittlere „Einweg“ V erzögerung T, A bsolute V erzögerung Ta
ANHANG
Abbildung 38: E-Modell Konfigurations-Referenz, nach ITU-T G.107

Parameter (DE) Parameter (ENG) Kürzel Einheit Wert Werteber. Anm.
Sendelautstärke Send Loudness Rating SLRs dB +8 0 bis +18 *1
Empfangslautstärke Receive Loudness Rating RLRr dB +2 -5 bis +14 *1
Nebengeräusch Rate Sidetone Masking Rating STMR dB 15 10 bis 20 *2
Höhrer Nebengeräusch Rate Listener Sidetone Rating LSTR dB 18 13 bis 23 *2
Sender D-Wert des Telefons D-value of telephone, send side Ds 3 -3 bis +3
Empfänger D-Wert des Telefons D-value of telephone receive side Dr 3 -3 bis +3 *2
Sprecher Echo Lautstärke Talker Echo Loudness Rating TELR dB 65 5 bis 65
Gew. Echo bei verlor. Pfad Weighted Echo Path Loss WEPL dB 110 5 bis 110
Mittl. einweg Verz. des Echo-Weges Mean one-way delay of the echo path T ms 0 0 bis 500
Round Trip Verz. in einer 4-Weg-Schleife Round trip delay in a 4-wire loop Tr ms 0 0 bis 1000
Abs. Verz. bei Echofreier Verb. Absolute delay in echo free connections Ta ms 0 0 bis 500
Quantisierungsverzerrung Number of Quantization distortion units QDU 1 1 bis 14
95
Ausrüstungs-Beeinträchtigungs-Faktor Equipment impairment factor Ie 0 0 bis 40
Robustheit bei Paketverlust Packet-loss Robustness Factor Bpl 1 1 bis 40 *3
Wahrscheinlichkeit von Paketverlust Random Packet-loss Probability Ppl 0 0 bis 20 *3
Schaltungsgeräusche Circuit noise referred to 0 dBr-point Nc dBm0p -70 -80 bis -40
Empfängerseitiger Geräuschpegel Noise floor at the receive Side Nfor dBmp -64 *3
Senderseitiges Raum Hingergrundger. Room noise at the send side Ps dB(A) 35 35 bis 85
Empfängerseitiges Raum Hintergrundger. Room noise at the receive side Pr dB(A) 35 35 bis 85
Erwartungswert-Faktor Advantage factor A 0 0 to 20
*1 Absolut-Werte zwischen dem Empfänger und dem 0 dB Punkt *1 Total values between microphone or receiver and 0 dBr-point
*2 Feste Relation: LSTR = STMR + D *2 Fixed relation: LSTR = STMR + D
*3 wird z.Z. noch untersucht *3 Currently under study
14
Tabelle 29: E-Modell Parameter-Referenz, nach ITU-T G.107

ANHANG
14 ANHANG
Listing 20: Informations Button mit Javascript

1 <head>
2 .....
3 < s c r i p t t y p e =” t e x t / j a v a s c r i p t ” l a n g u a g e =” J a v a S c r i p t ”>
4 <!−−
5 function quelltext () {
6 window . l o c a t i o n = ’ view−s o u r c e : ’ + window . l o c a t i o n . h r e f ;
7 return
8 }
9 −−>
10 </ s c r i p t >
11 < s t y l e t y p e =” t e x t / c s s ”>
12 <!−−
13 td {
14 f o n t −f a m i l y : a r i a l , helvetica ;
15 f o n t −s i z e : 1 2 px ;
16 color :#000000;
17 }
18 −−>
19 </ s t y l e >
20 < s c r i p t t y p e =” t e x t / j a v a s c r i p t ” l a n g u a g e =” J a v a S c r i p t ”>
21 <!−− I n f o −−>
22 <!−− B e g i n
23
24 // : : : : : : : : welcher Browser ? : : : : : : : :
25 i f ( document . l a y e r s ) { n a v i g a t o r . f a m i l y = ” nn4 ” }
26 i f ( document . a l l ) { n a v i g a t o r . f a m i l y = ” i e 4 ” }
27 i f ( window . n a v i g a t o r . u s e r A g e n t . t o L o w e r C a s e ( ) . match ( ” g e c k o ” ) ) { n a v i g a t o r . f a m i l y = ” g e c k o ” }
28
29 d e s c a r r a y = new A r r a y (
30
31 −−−− s n i p −−−−
32 ” Hier wird der I n f o r m a t i o n s t e x t eingegeben ”
33 −−−− s n a p −−−−
34 );
35 .....
36 <\head>
37
38 <body>
39 .....
40 <d i v i d =” o b j e c t 1 ” s t y l e =” p o s i t i o n : a b s o l u t e ;
41 b a c k g r o u n d−c o l o r : FFFFDD ; c o l o r : b l a c k ;
42 b o r d e r −c o l o r : b l a c k ; b o r d e r −w i d t h : 2 0 ;
43 v i s i b i l i t y : show ; l e f t : 2 5 px ; t o p : −100 px ;
44 z−i n d e x : + 1 ” o n m o u s e o v e r =” o v e r d i v = 1 ;
45 ” o n m o u s e o u t =” o v e r d i v = 0 ;
46 s e t T i m e o u t ( ’ h i d e L a y e r ( ) ’ , 1 0 0 0 ) ”>
47 pop up d e s c r i p t i o n l a y e r
48 </ d i v>
49 .....
50 <IMG s r c =” p i c s / i n f o . j p e g ” w i d t h =” 20 ” h e i g h t =” 20 ” a l i g n =” l e f t ” b o r d e r =” 0 ”
51 onMouseOver=” p o p L a y e r ( 4 ) ” onMouseOut=” h i d e L a y e r ( ) ”>
52 .....
53 <\head>
96
14 ANHANG
Listing 21: tethereal Steuerprogramm client.c

1 # include < s t d i o . h>
2 # include <s y s / t y p e s . h>
3 # include <s y s / s o c k e t . h>
4 # include < n e t i n e t / i n . h>
5 # include <n e t d b . h>
6
7 # d e f i n e FALSE 0
8 # d e f i n e TRUE 1
9
10 void
11 e r r o r ( char ∗msg )
12 {
13 p e r r o r ( msg ) ;
14 exit (0);
15 }
16
17 int
18 main ( i n t a r g c , char ∗ a r g v [ ] )
19 {
20 i n t sockfd , portno , n ;
21 struct sockaddr in serv addr ;
22 struct hostent ∗server ;
23
24 char b u f f e r [ 2 5 6 ] ;
25 i f ( argc < 3)
26 {
27 fprintf ( stderr ,
28 ”ERROR : u s a g e : . / c l i e n t HOST PORT . / t e t h e r e a l [PARMETER1] [PARAMETER2] . . . \n ” ,
29 argv [ 0 ] ) ;
30 exit (0);
31 }
32 portno = a t o i ( argv [ 2 ] ) ;
33 s o c k f d = s o c k e t ( AF INET , SOCK STREAM , 0 ) ;
34 i f ( sockfd < 0)
35 e r r o r ( ”ERROR o p e n i n g s o c k e t ” ) ;
36
37 s e r v e r = gethostbyname ( argv [ 1 ] ) ;
38 i f ( s e r v e r == NULL)
39 {
40 f p r i n t f ( s t d e r r , ”ERROR, no s u c h h o s t \n ” ) ;
41 exit (0);
42 }
43
44 int option = 0;
45 b z e r o ( ( char ∗ ) &s e r v a d d r , s i z e o f ( s e r v a d d r ) ) ;
46 s e r v a d d r . s i n f a m i l y = AF INET ;
47 bcopy ( ( char ∗ ) s e r v e r −>h a d d r ,
48 ( char ∗ ) &s e r v a d d r . s i n a d d r . s a d d r , s e r v e r −>h l e n g t h ) ;
49 serv addr . s i n p o r t = htons ( portno ) ;
50 i f ( c o n n e c t ( s o c k f d , &s e r v a d d r , s i z e o f ( s e r v a d d r ) ) < 0 )
51 e r r o r ( ”ERROR c o n n e c t i n g ” ) ;
52 p r i n t f ( ” Message w i l l be send , s o o o o o n ” ) ;
53 bzero ( buffer , 256);
54
55 int x ;
56 / / p r i n t f (”\ n a r g c : %d ” , a r g c ) ;
57 s t r c p y ( b u f f e r , a r g v [ 3 ] ) ; / / command
58
59 i n t i =4;
60 w h i l e ( ( o p t i o n = g e t o p t ( a r g c , a r g v , ” waik : ” ) ) >= 0 )
97
14 ANHANG
61 switch ( option )
62 {
63
64 case ’ i ’ :
65 s t r c a t ( buffer , ” ” );
66 s t r c a t ( buffer , argv [ i ] ) ;
67 s t r c a t ( buffer , ” ” );
68 s t r c a t ( buffer , argv [ i + 1 ] ) ;
69 s t r c a t ( buffer , ” ” );
70 i = i +2;
71 break ;
72 case ’ a ’ :
73 s t r c a t ( buffer , ” ” );
75 s t r c a t ( buffer , ” ” );
77 s t r c a t ( buffer , ” ” );
78 i = i +2;
79 break ;
80 c a s e ’w ’ :
81 s t r c a t ( buffer , ” ” );
83 s t r c a t ( buffer , ” ” );
85 s t r c a t ( buffer , ” ” );
86 i = i +2;
87 break ;
88
89 case ’k ’ :
90 s t r c a t ( buffer , ” ” ) ;
92 s t r c a t ( buffer , ” ” ) ;
93 i = i +1;
94 break ;
95
96 case ’ ? ’ :
97 break ;
98 }
99
100 / / fgets ( buffer ,255 , stdin );
101 n = w r i t e ( sockfd , buffer , s t r l e n ( b u f f e r ) ) ;
102 i f ( n < 0)
103 e r r o r ( ”ERROR w r i t i n g t o s o c k e t ” ) ;
104 bzero ( buffer , 256);
105 n = read ( sockfd , buffer , 255);
106 i f ( n < 0)
107 e r r o r ( ”ERROR r e a d i n g from s o c k e t ” ) ;
108 p r i n t f ( ”%s \n ” , b u f f e r ) ;
109 close ( sockfd ) ;
110 return 0;
111 }
98
14 ANHANG
Listing 22: tethereal Steuerprogramm server.c

1 # include < s t d i o . h>
2 # include <s y s / t y p e s . h>
3 # include <s y s / s o c k e t . h>
4 # include < n e t i n e t / i n . h>
5
6 char f i n a l b u f f e r [ 2 5 6 ] ; / / Command B u f f e r
7
8 v o i d e r r o r ( char ∗msg )
9 {
10 p e r r o r ( msg ) ;
11 exit (1);
12 }
13
14 i n t main ( i n t a r g c , char ∗ a r g v [ ] )
15 {
16 i n t s o c k f d , newsockfd , p o r t n o , c l i l e n ;
17 char b u f f e r [ 2 5 6 ] ;
18 struct sockaddr in serv addr , cli addr ;
19 int n ;
20 i f ( argc < 2) {
21 f p r i n t f ( s t d e r r , ”ERROR, no p o r t p r o v i d e d \n ” ) ;
22 exit (1);
23 }
24 s o c k f d = s o c k e t ( AF INET , SOCK STREAM , 0 ) ;
25 i f ( sockfd < 0)
26 e r r o r ( ”ERROR o p e n i n g s o c k e t ” ) ;
27 b z e r o ( ( char ∗ ) &s e r v a d d r , s i z e o f ( s e r v a d d r ) ) ;
28 portno = a t o i ( argv [ 1 ] ) ;
29 s e r v a d d r . s i n f a m i l y = AF INET ;
30 s e r v a d d r . s i n a d d r . s a d d r = INADDR ANY ;
31 serv addr . s i n p o r t = htons ( portno ) ;
32 i f ( b i n d ( s o c k f d , ( s t r u c t s o c k a d d r ∗ ) &s e r v a d d r ,
33 s i z e o f ( s e r v a d d r ) ) < 0)
34 e r r o r ( ”ERROR on b i n d i n g ” ) ;
35 l i s t e n ( sockfd , 5 ) ;
36 clilen = sizeof ( cli addr );
37 do {
38 newsockfd = a c c e p t ( sockfd ,
39 ( s t r u c t s o c k a d d r ∗ ) &c l i a d d r ,
40 &c l i l e n ) ;
41 i f ( newsockfd < 0)
42 e r r o r ( ”ERROR on a c c e p t ” ) ;
43 bzero ( buffer , 2 5 6 ) ;
44 n = r e a d ( newsockfd , b u f f e r , 2 5 5 ) ;
45 i f ( n < 0 ) e r r o r ( ”ERROR r e a d i n g from s o c k e t ” ) ;
46
47 p r i n t f ( ”\ n S h e l l s c r i p t : . / r e g u l a t o r . sh ” ) ;
48 p r i n t f ( ” \nCommand : %s \n ” , b u f f e r ) ;
49 s p r i n t f ( f i n a l b u f f e r , ” . / r e g u l a t o r . s h %s ” , b u f f e r ) ;
50 system ( f i n a l b u f f e r ) ;
51 n = w r i t e ( newsockfd , ” . . . Message r e c e i v e d ! ” , 2 4 ) ;
52 } w h i l e ( f i n a l b u f f e r ! = ’STOP\n ’ ) ;
53
54 i f ( n < 0 ) e r r o r ( ”ERROR w r i t i n g t o s o c k e t ” ) ;
55 close ( sockfd ) ;
56 return 0;
57 }
99
14 ANHANG
Funktionsmessungen
Variierende Generatorsessions
Packetsize: 160
Number of Packets: 1000
Intervaltime: 20000
Messungen: 5
Packet Loss: 0
Sessions 1
Sender Avarage Empfänger Average round trip time
1 21 21,04 0,74
2 21 21,05 0,59
3 21 21,02 0,47
4 21 21,02 0,53
5 21 21,04 0,87
SUM/5 21 21,03 0,64
Sessions 3
1 21 21,03 5,93
2 21 21,99 2,02
3 21 21 0,8
4 21 21 2,05
5 21 21,01 0,74
SUM/5 21 21,21 2,31
Sessions 5
1 21 21 0,75
2 21 21 1,85
3 21 21,03 1,37
4 21 21 1,47
5 21 21 3,92
SUM/5 21 21,01 1,87
Sessions 10
1 21 21 1,74
2 21 21 1,7
3 21 21 3,2
4 21 21 1,76
5 21 21 1,66
SUM/5 21 21 2,01
100
14 ANHANG
Sessions 20
1 21 21 4,5
2 21 21 4,51
3 21 21 2,09
4 21 21 5,03
5 21 21 5,03
SUM/5 21 21 4,23
Sessions 50
1 21 21 6,18
2 21 21 5,13
3 21 21,12 7,21
4 21 21,7 7,33
5 21 21,14 7,23
SUM/5 21 21,19 6,62
Sessions 100
1 21 22,5 9,37
2 21 21,76 9,81
3 21 21,77 9,31
4 21 21,33 9,44
5 21 22 9,77
SUM/5 21 21,87 9,54
Auswertung:
Sessions 1 3 5
Sender Avarage 21 21 21
Empfänger Average 21,03 21,21 21,01
round trip time 0,64 2,31 1,87
Jitter 0,07 0,18 0,14
Auswertung: 20 50 100
Sessions 21 21 21
Sender Avarage 21 21,19 21,87
Empfänger Average 4,23 6,26 9,45
Jitter
101
14 ANHANG
Variierende Aufzeichnungssessions
Packetsize: 160
Number of Packets: 1000
Intervaltime: 20000
Messungen: 5
Packet Loss: 0
Sessions 1
1 21 21,04 0,74
2 21 21,05 0,59
3 21 21,02 0,47
4 21 21,02 0,53
5 21 21,04 0,87
SUM/5 21 21,03 0,64
Sessions 3
1 21 21 1,22
2 21 21 0,81
3 21 21 1,18
4 21 21 0,42
5 21 21 0,64
SUM/5 21 21 0,85
Sessions 5
1 21 21 2,75
2 21 21 3,4
3 21 21 2,25
4 21 21 3,21
5 21 21 0,98
SUM/5 21 21 2,52
Sessions 9
1 21 21 3,21
2 21 21 1,59
3 21 21 0,95
4 21 21,17 3,3
5 21 21 3,37
SUM/5 21 21,03 2,48
Auswertung:
Sessions 1 3 5
Sender Avarage 21 21 21
Empfänger Average 21,03 21 21
Jitter 0,07 0,1 0,23
102
Messungen
Begriffserklärungen: Generator Host SER HOST
SA = Sender Average [ms] Jabba <---- level one ---- CentreCOM ----> ALERT
RA = Receiver Average [ms] 2X 100 MBit Switch
R = R-Faktor
MOS = Mean Opinion Score
RTT = Round Trip Time [ms]
Pl = Package Loss
DSCP = Differentiated Services Code Point
P = Packet
0x = Hexadezimal
I = Intervaltime [ms]
J = Jitter [ms]
E = Berechneter Erwartungswert
103
Einstellungen:
Befehl: netsim -s eth1 -d eth2 -I 2000 -L 0 -J 1 -D 100 -I 2000 --C1 0x3 --L1 0 --D1 1
DSCP 0x0 0x3

Interval 2000 2000
Delay 100 0
Jitter 1 1
Packet Loss 0 0
Netzlast 0 0
Messung ohne Last:

DSCP1 DSCP2 P I R1 R2 MOS1 MOS2 RTT1 RTT2 PL1 PL2
0x0 0x3 1000 10 91 93 4,4 4,4 210,37 9,93 0 0
14
1000 15 91 93 4,4 4,4 211,05 9,54 0 0

1000 20 91 93 4,4 4,4 206,82 9,69 0 0
1000 25 91 93 4,4 4,4 205,43 6,33 0 0
1000 30 91 93 4,4 4,4 205,02 7 0 0
E 91 93
ANHANG
Messungen mit Last:
Netzlast 2x ping -f 1xscp
0x0 0x3 1000 10 81 93 4,1 4,4 267,51 68,08 1 0
1000 15 83 93 4,2 4,4 245,18 43,29 0 0
1000 20 89 93 4,2 4,4 243,04 36,52 0 0
1000 25 86 93 4,2 4,4 234,79 35,24 0 0
1000 30 84 93 4,2 4,4 238,04 31,27 0 0
Berechnete Erwartungswerte 91 93
Befehl: netsim -s eth1 -d eth2 -I 2000 -L 0 -J 1 -D 250 -I 2000 --C1 0x3 --L1 0 --D1 0 -J1 1
Messungen mit Last und doppelter RTT:
Netzlast 2x ping -f 1xscp
104
0x0 0x3 1000 10 77 93 3,9 4,4 527,33 30,69 0 0
1000 15 77 92 3,9 4,4 527,35 25,91 0 0
1000 20 77 93 3,9 4,4 519,34 21,45 0 0
1000 25 77 93 3,9 4,4 518,2 20,15 0 0
1000 30 78 93 3,9 4,4 517,4 19,34 0 0
E 79 93
14
ANHANG
Messung mit Last und 4 DSCP-Klassen:
DSCP 0x0 0x3 0x5 0x7
Interval 2000 2000 2000 2000
Delay 500 0 500 500
Jitter 1 1 10000 10000
Packet Loss 0 0 0 1000
Netzlast 0 0
netsim -s eth1 -d eth2 -I 2000 -L 0 -J 1 -D 250 -I 2000 --C1 0x3 --L1 0 --D1 0 -J1 1
... --C2 '0x5' --L2 0 --D2 500 -J2 10000 --C3 '0x5' --L3 1000 --D3 500 -J3 10000
Netzlast 2x ping -f1x scp
0x0 def
0x3 c1
0x5 c2
105
0x7 c3
P I R1 R2 R3 R4 MOS1 MOS2 MOS3 MOS4 RTT1 RTT2 RTT3 RTT4
1000 10 54 66 31 0 2,8 3,4 1,7 1 548,54 44,5 1045,3 1027,9
1000 15 76 93 53 0 3,9 4,4 2,8 1 536,84 31,08 1032,81 1007,74
1000 20 77 93 53 0 3,9 4,4 2,8 1 523,8 24,58 1027,64 1004,35
1000 25 77 93 54 0 3,9 4,4 2,8 1 525,52 22,52 1026,24 1008,92
1000 30 77 93 54 0 3,9 4,4 2,8 1 522,67 18,53 1027,01 1012,78
E 79 93 54 0
PL1 PL2 PL3 PL4 J1 J2 J3 J4

3 4 3 19 34,42 2,8 65,59 65,5
0 0 0 24 33,59 1,94 64,62 64,6
14
0 0 0 24 32,77 1,54 64,29 64,38

0 0 0 18 32,88 1,41 64,22 64,28
0 0 0 15 32,7 1,16 64,25 64,33
ANHANG
DSCP 0x0 0x3
Interval 2000 2000
Delay 0 0
Jitter 1 1
Packet Loss 0 variabel
Netzlast 0 0
P L R1 R2 MOS1 MOS2 RTT1 RTT2 P1 P2 J1 J2

1000 0,01 93 92 4,4 4,4 10,32 6,43 0 0 0,65 0,4
1000 0,025 93 84 4,4 4,1 5,6 11,54 0 1 0,35 0,72
1000 0,05 93 71 4,4 3,6 5,69 11,81 0 3 0,36 0,74
1000 0,10 93 66 4,4 3,4 11,45 5,7 0 4 0,72 0,36
1000 0,25 93 57 4,4 3 5,56 11,09 0 6 0,35 0,7
1000 0,50 93 45 4,4 2,3 5,64 11,52 0 10 0,35 0,73
106
1000 1,00 93 38 4,4 2 10,46 6,8 0 14 0,65 0,43
1000 2,00 93 19 4,4 1,2 5,57 11,19 0 34 0,36 0,72
1000 3,00 93 11 4,4 1,1 11,06 12,1 0 64 0,35 0,45
1000 4,00 93 8 4,4 1 5,57 10 0 86 0,35 0,68
1000 5,00 93 8 4,4 1 5,46 9,67 0 86 0,34 0,66
14
ANHANG

Andreas Orthen 2006

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Andreas Orthen 2006

Diunggah oleh

Hak Cipta:

Format Tersedia

x x x x x x

07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Elektrotechnik/NT

Institut für Nachrichtentechnik, Labor für Datennetze

Entwicklung einer Messumgebung zur Bewertung der Dienstgüte

Referent: Prof. Dr. Andreas Grebe

Korreferent: Dipl.-Ing. Stefan Abu Salah

3 Motivation und Aufgabenstellung 3

4.11 Zeitmessung mit Linux unter Verwendung von GNU C . . . . . . . . . . . . . 39

5 Einführung in das Projekt 41

13 RFC-Verzeichnis und Software-Internetseiten 89

3 Motivation und Aufgabenstellung

ist eine einfache Portierbarkeit auf andere Computer.

4.2 Internet Protocol (IP)

Abbildung 2: ISO OSI-Schichtmodell

4.2.1 Internet Protocol Version 4 (IPv4)

chen benutzen IP als Übertragungsplattform. Ein Beispiel aus dem Telekommunikationssektor

Abbildung 3: IPv4-Datagramm (RFC 791)

4.2.2 Internet Protocol Version 6 (IPv6)

Abbildung 4: IPv6-Datagramm (RFC 2460)

4.3 Transmission Control Protocol (TCP)

Abbildung 5: TCP-Handshake Abbildung 6: TCP-Teardown

Abbildung 7: TCP-Datagramm (RFC 793)

4.4 User Datagramm Protocol (UDP)

Abbildung 8: UDP-Datagramm (RFC 768)

4.5 Realtime Transport Protocol (RTP)

Abbildung 9: RTP-Datagramm (RFC 3550)

4.5.1 Realtime Transport Control Protocol (RTCP)

• Welche Bandbreite soll pro VoIP-Verbindung belegt werden?

• Welchen Rechenaufwand benötigt der Codec zum Kodieren und Dekodieren?

Codec Sampling Bandwidth Payload MOS Komprimierung

4.6 Session Initialisation Protocol (SIP)

In der SIP-Signalisierung existieren sechs SIP-Methoden: INVITE, REGISTER, BYE, ACK,

Methode Request for Comment (RFC)

Klasse Beschreibung Aktion

Abbildung 10: Struktur einer SIP-Nachricht

4.6.5 Anmeldung an einem SIP-Server

Listing 1: SIP-Client Registrierungsanfrage am SIP-Server

Listing 2: Antwort des SIP-Servers auf Registrierungsanfrage

4.6.6 SIP-Verbindungsaufbau und -abbau

Abbildung 11: SIP und RTP -Datenstrom einer VoIP-Verbindung

Abbildung 12: SIP-Verbindungsaufbau und -abbau, erstellt mit callflow

Listing 3: Methode INVITE (Zeile 3396)

Listing 4: Response 100 trying (Zeile 3415)

Listing 5: Response 180 Ringing (Zeile 3473)

Listing 6: Response 200 Ok (Zeile 21218)

4 Via : SIP / 2 . 0 / UDP 1 9 2 . 1 6 8 . 0 . 6 6 ; b r a n c h =z9hG4bK7CDAE767

Listing 7: Methode ACK (Zeile 21257)

Der SIP-Sessionaufbau ist hiermit beendet. Der RTP-Datenstrom zwischen Anrufer

Listing 8: Methode BYE (Zeile 32412)

Listing 9: Response Ok (Zeile 32430)

Die SIP Verbindung wurde ordnungsgemäß abgebaut.

4.6.7 Session Description Protocol (SDP)

Listing 10: SDP-Flags aus Listing 3

In den folgenden Tabellen werden die SDP-Felder beschrieben:

Tabelle 12: Beschreibung der möglichen SDP-Zeit-Flags (RFC 2327)

4.7 Störfaktoren bei VoIP

Abbildung 13: Schaubild der IP-spezifischen Parameter

eingebauten Lautsprechers und Mikrofons, welches ebenfalls eine Art Freisprecheinrichtung

• Ausbreitungsverzögerung, die durch Signallaufzeiten in Leitungen oder Luft entsteht.

In der vorliegenden Diplomarbeit werden ausschließlich Paketlaufzeiten gemessen. Die Paket-

Abbildung 14: Verarbeitungsverzögerung und Transportverzögerung

D(i, j) = (Rj − Ri) − (Sj − Si) = (Rj − Sj) − (Ri − Si)

(|D(i − 1, i)| − Jalt )