Labor für Kommunikationssysteme - Ostfalia
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Labor für Kommunikationssysteme
Leitung: Prof. Dr.-Ing. Diederich Wermser
Versuch:
Session Initiation Protocol (SIP)
Sommersemester 2020
Gruppe: ____________________
Datum: ____________________
Teilnehmer:
Name: ____________________ Matr.-Nr.: ______________
Name: ____________________ Matr.-Nr.: ______________
Name: ____________________ Matr.-Nr.: ______________Laborumdruck Session Initiation Protocol (SIP) Seite | 2 Inhaltsverzeichnis 1. Einleitung ....................................................................................................................... 4 1.1. NGN (Next Generation Networks) ........................................................................... 4 1.2. Protokolle ................................................................................................................ 4 2. Session Initiation Protocol .............................................................................................. 5 2.1. SIP-URI ................................................................................................................... 5 2.2. SIP-Netzelemente ................................................................................................... 5 2.2.1. User Agents ......................................................................................................... 5 2.2.2. ProxyServer ......................................................................................................... 6 2.2.2.1. Stateless Proxy Server ..................................................................................... 6 2.2.2.2. Stateful Proxy Server ....................................................................................... 7 2.2.3. Registrar Server................................................................................................... 7 2.2.4. Redirect Server .................................................................................................... 7 2.3. SIP-Nachrichten ...................................................................................................... 8 2.3.1. Start-Line ............................................................................................................. 9 2.3.2. Header ................................................................................................................. 9 2.3.2.1. General Header................................................................................................ 9 2.3.2.2. Entity Header ..................................................................................................10 2.3.2.3. Request Header ..............................................................................................10 2.3.3. Message Body ....................................................................................................10 2.3.4. SIP Requests......................................................................................................10 2.3.5. SIP Responses ...................................................................................................11 2.4. SIP-Dialoge ............................................................................................................12 2.5. SIP-Transaktionen..................................................................................................12 2.6. Typische SIP-Kommunikationsabläufe ...................................................................13 2.6.1. Registrierung ......................................................................................................13 2.6.2. Verbindungsaufbau.............................................................................................13 2.6.3. Verbindungsabbau..............................................................................................14 2.6.4. Record Routing ...................................................................................................14 2.6.5. Event Subscription ..............................................................................................15 3. Weitere Protokolle .........................................................................................................16 3.1. Session Description Protocol (SDP) .......................................................................16 3.2. Realtime Transport Protocol (RTP) ........................................................................16 3.3. Realtime Control Protocol (RTCP)..........................................................................17 4. Genutzte Programme ....................................................................................................19 4.1. hping3 – der TCP/IP Netzwerkassembler ...............................................................19 4.2. Wireshark ...............................................................................................................20 4.3. Jitsi.........................................................................................................................20 5. Versuchsvorbereitung ...................................................................................................21 5.1. Aufgabe 1: Was ist SIP und wofür wird es verwendet? Wofür wird SIP nicht verwendet? .......................................................................................................................21 5.2. Aufgabe 2: Welche Netzelemente kennt das SIP Model? Beschreiben Sie jeweils kurz deren Funktion. .........................................................................................................21 5.3. Aufgabe 3: Was versteht man unter dem Model des SIP-Trapezoids? ...................21 5.4. Aufgabe 4: Welche AudioCodecs werden bei VoIP typischerweise genutzt? Wie handeln die Gesprächsteilnehmer den Codec aus? ..........................................................22 5.5. Aufgabe 5: HPING Aufruf .......................................................................................22 6. Versuchsdurchführung ..................................................................................................23 6.1. SIP-Protokolluntersuchungen .................................................................................23 6.1.1. Direkte Verbindung .............................................................................................23 6.1.1.1. 2 User Agents .................................................................................................23 6.1.2. Verbindung via Proxy/Registrar ..........................................................................25 6.1.2.1. Registrierung der Clients .................................................................................25 6.1.2.2. 2 User Agents – Session über Proxy ...............................................................26 6.1.2.3. 3 User Agents .................................................................................................27
Laborumdruck Session Initiation Protocol (SIP) Seite | 3 6.2. Hacking ..................................................................................................................28 6.2.1. Fremdes Gespräch beenden ..............................................................................28 6.2.2. Nutzdaten aufnehmen.........................................................................................28 7. Literatur .........................................................................................................................30 Abbildungsverzeichnis Abbildung 1: Verteilung der Zustände "Client" (UAC) und "Server" (UAS) ............................. 6 Abbildung 2: Prinzip der Registrierung .................................................................................. 7 Abbildung 3: SIP Weiterleitung (Redirect).............................................................................. 8 Abbildung 4: Aufbau einer SIP-Nachricht............................................................................... 8 Abbildung 5: SIP Dialog und Transaktionen .........................................................................12 Abbildung 6: SIP-Meldungsfluss bei Regisrierung ................................................................13 Abbildung 7: SIP-Meldungsfluss bei Initiierung einer Session...............................................14 Abbildung 8: SIP-Meldungsfluss bei Verbindungsabbau.......................................................15 Abbildung 9: Abbonement des Online-Status eines Benutzers .............................................15 Abbildung 10: Schichtenmodell ............................................................................................16 Abbildung 11: Bit-Struktur RTP-Protokoll ..............................................................................17 Abbildung 13: SIP-Meldungsfluss bei Registrierung .............................................................25 Abbildung 14: Meldungsfluss für Signalisierung von 2 Teilnehmern über Proxy ...................26 Abbildung 12: Verkehrsbeziehungen zwischen Netzelementen bei einer VoIP-Konferenz ...27
Laborumdruck Session Initiation Protocol (SIP) Seite | 4 1. Einleitung 1.1. NGN (Next Generation Networks) Der Begriff Next Generation Networks steht für eine neue Form von Kommunikationsnetzen, die sich durch die Konvergenz herkömmlicher Netze (Telefonnetze, Mobilfunknetze, etc.) mit IP-basierten Netzen ergibt. Ein Netz, das dem NGN-Konzept genügt, unterstützt Multimedia- Kommunikation, d.h. es ermöglicht Audio-, Text- Stand- und Bewegtbildkommunikation, auch in Kombination. Ein solches Netz arbeitet zumindest in seinem Kern paketorientiert, normalerweise auf Basis des Internet Protocols. Da dieses verbindungslos arbeitet, wurden und werden spezielle Protokolle erarbeitet, die zwar IP nutzen, aber trotzdem dafür sorgen, dass für die eigentliche Kommunikation (via Nutzdaten) die Verbindung aufgebaut wird. 1.2. Protokolle Prinzipiell kommen für die Aufgabe mehrere Protokollfamilien in Frage, vor allem SIP (Session Initiation Protocol) und H.323. Beide sind allerdings nur in den Grundfunktionen miteinander kompatibel. SIP ist zwar das jüngere Protokoll, wurde aber für Release 5 des UMTS (Universal Mobile Telecommunications System) als Standard festgelegt und ist insgesamt leistungsfähiger sowie leichter erweiterbar. Außerdem handelt es sich bei SIP um ein Klartextprotokoll, wodurch eine Dekodierung der ausgetauschten Nachrichten nicht notwendig ist. Dieser Versuch gibt einen Einblick in die technischen Zusammenhänge der Signalisierung mittels Session Initiation Protocol.
Laborumdruck Session Initiation Protocol (SIP) Seite | 5
2. Session Initiation Protocol
Das Session Initiation Protocol (SIP) ist ein Netzwerkprotokoll zur Verwaltung (Aufbau,
Abbau, etc.) einer Kommunikationsverbindung (Session) zwischen zwei und mehr
Teilnehmern. Entwickelt wurde das Protokoll von einer Arbeitsgruppe der IETF, die die
Spezifikationen 1999 veröffentlichten. Die aktuelle Version des Protokolls mit allen
Definitionen kann im Request For Comments: 3261 [RFC3261] nachgelesen werden. SIP ist
ein Protokoll für das Internet und ähnelt in seiner Form dem HTTP Protokoll. Der
Nachrichtenaustausch erfolgt immer zwischen einem Client und einem Server, wobei der
Client Anforderungen (Request) stellt, die der Server beantwortet (Response). Die Rollen
von Client und Server sind nicht festgelegt und können durchaus im Verlauf einer Session
wechseln. SIP selbst ist dabei weitestgehend unabhängig von der genauen Art der Session
(Telefonie, Instant Messaging, etc.) bzw. den darüber ausgetauschten Daten (Audio, Video,
Text, etc.), sondern stellt nur einen Mechanismus bereit, um Informationen über Sessions
auszuhandeln bzw. zu verteilen. Diese mittels SIP verteilten Informationen verwenden die
Benutzer anschließend, um Kanäle für die eigentliche Session aufzubauen. Der Nachrichten-
und Status-Austausch basiert wie bei HTTP ebenfalls auf ASCII-Code. SIP kann auf UDP
oder TCP aufsetzen und verwendet standardmäßig Port 5060. Da SIP eigene Mechanismen
zur Fehlerkontrolle besitzt, setzt man SIP meist auf dem verbindungslosen, unzuverlässigen
UDP auf. Dadurch ist der Overhead geringer und der Rufaufbau ist entsprechend effizienter.
2.1. SIP-URI
Bei SIP werden die Teilnehmer über die so genannte SIP URI (Uniform Resource Identifier,
auch SIP URL, Uniform Resource Locator) adressiert. Eine SIP URI hat die Form
„sip:username@domain“, ähnlich einer e-mail-Adresse. Dies bietet den Vorteil, dass
Benutzern dieselbe e-mail- und SIP-Adresse zugewiesen werden kann, unter welcher der
Benutzer erreichbar ist. Außerdem kann dieselbe Adresse unabhängig vom benutzten Gerät
beibehalten werden, was insbesondere sinnvoll für mobile Benutzer ist.
2.2. SIP-Netzelemente
Die einfachste Konfiguration einer SIP-Kommunikationsinfrastruktur besteht aus zwei User
Agents, die SIP-Nachrichten direkt austauschen. Ein typisches SIP-Netzwerk besteht jedoch
aus mehreren Typen von Netzelementen. Dies sind User Agents, Proxy, Registrar, Redirect
und Location Server, welche in diesem Kapitel kurz beschrieben werden. In der Praxis
werden logische SIP-Netzelemente bzw. deren Funktionen häufig in einer Hardware oder
Software miteinander kombiniert (z.B. SIP Proxy/Registrar Server mit integrierter Location
Server-Funktion).
2.2.1. User Agents
Als „User Agent“ bezeichnet man diejenige Soft- und/oder Hardwarekomponente, die das
Endgerät für eine SIP-basierte Kommunikation darstellt. Z.B. handelt es sich dabei um ein
Software-Telefon (Soft Phone), oder ein Hardware-IP-Telefon, das direkt an ein vorhandenes
IP-Netz angeschlossen wird.
Ein SIP-basiertes Kommunikationsendsystem, das seinem Benutzer die Möglichkeit sowohl
der abgehend als auch der ankommend eingeleiteten Multimedia over IP-Kommunikation
bietet, beinhaltet die logischen Funktionen eines UAC (User Agent Client, abgehende
Einleitung) sowie eines aus (User Agent Server, Annahme ankommender
Verbindungswünsche). So verhält sich der User Agent des Anrufers wie ein UAC, wenn er
ein INVITE Request sendet und Responses darauf erhält und der User Agent des
Angerufenen verhält sich wie ein UAS, wenn er das INVITE empfängt und ResponsesLaborumdruck Session Initiation Protocol (SIP) Seite | 6
versendet. Beendet der Angerufene die Verbindung, so wird dessen User Agent zum UAC
und der des Anrufers zum UAS.
Abbildung 1: Verteilung der Zustände "Client" (UAC) und "Server" (UAS)
2.2.2. ProxyServer
Ein Proxy Server dient dem Routing von SIP-Kommunikationselementen. Proxies können im
Sinne von SIP als Server und als Client agieren, denn sie empfangen Requests (UAS) und
leiten diese weiter (UAC). Sie können die Nachricht mit oder ohne Veränderungen weiter
senden und auch lokal generierte Responses versenden. Um Routing-Schleifen zu
verhindern fügt ein Proxy bei Requests seinen Namen im Via Header an und entfernt ihn bei
Responses wieder aus der Liste. Dies hat auch zur Folge, dass die Response den gleichen
Weg zurücklegt wie der Request auf dem Hinweg. Das kann genutzt werden, wenn z.B. der
Anruf verrechnet werden soll.
Sollen nicht nur Request und Response über denselben Weg geroutet werden, so müssen
die Proxies zusätzlich einen Eintrag im Record Route Header vornehmen. Über sog. Forking
Proxies können Requests an mehrere Endpunkte (Server) verschickt werden, was dann
sinnvoll ist, wenn sich jemand an mehreren Standorten angemeldet hat oder gesucht wird.
Es werden zwei Typen von SIP-Proxy-Servern unterschieden – Stateless und Stateful Proxy.
2.2.2.1. Stateless Proxy Server
Ein Stateless Proxy arbeitet als einfaches Durchgangselement. SIP-
Kommunikationselemente, die er empfängt, leitet er an genau ein SIP-Netzelement weiter,
nachdem er ggf. eine Routing-Entscheidung getroffen hat. Ein Stateless Proxy ist nicht in der
Lage, selbständig SIP-Kommunikationselemente zu erzeugen oder wiederholt zu senden. Er
speichert keinerlei Informationen über weitergeleitete Nachrichten, Zustände von SIP-
Transaktionen und dgl. Stateless Proxies sind i.d.R. schneller als Stateful Proxies.Laborumdruck Session Initiation Protocol (SIP) Seite | 7
2.2.2.2. Stateful Proxy Server
Im Gegensatz zu Stateless Proxy Servern sind Stateful Proxy Server aktive SIP-
Netzelemente im Sinne des SIP-Transaktionsbegriffs. Gegenüber einem als UAC
agierenden SIP-Netzelement wirkt ein Stateful Proxy als UAS, gegenüber einem als UAS
agierendem SIP-Netzelement als UAC. Ein Stateful Proxy speichert den Transaktionsstatus
jeder SIP-Nachricht und kann selbständig bestimmte SIP-Nachrichten erzeugen. Nur Stateful
Proxy Server können als Forking Proxy agieren, um SIP-Nachrichten an mehrere SIP URIs
weiterzuleiten.
2.2.3. Registrar Server
Ein Registrar Server bildet die Grundlage für die komfortable, orts- und
endgeräteunabhängige Erreichbarkeit eines Teilnehmers anhand einer ständigen SIP URI.
Er wertet die in der REGISTER-Nachricht enthaltenen Kontaktinformationen aus, um den
Zusammenhang („Binding“) zwischen der ständigen SIP URI eines Teilnehmers und der
temporären SIP URI des aktuellen Endsystems (abhängig von dessen IP-Adresse) zu
erzeugen. Die mittels SIP-Registrierung erzeugten Bindings sind befristet und müssen durch
wiederholtes Senden von REGISTER-Nachrichten aktuell gehalten werden.
Abbildung 2: Prinzip der Registrierung
2.2.4. Redirect Server
Ein SIP Redirect Server dient prinzipiell der SIP-basierten Weitergabe von
Kontaktinformationen eines SIP User Agents. Geht eine an einen SIP User Agent gerichtete
SIP-Nachricht bei einem Redirect Server ein, beantwortet dieser die Nachricht mit einer
Statusinformation des Typs 3xx (Redirection). Redirect Server können z.B. zur Realisierung
des Dienstmerkmals „Rufumleitung“ genutzt werden, kommen aber vor allem zum Einsatz,
um die Last auf dem Proxy Server zu verringern, indem der Redirect Server die Routing
Informationen direkt an den Anfragenden zurück gibt.Laborumdruck Session Initiation Protocol (SIP) Seite | 8 Abbildung 3: SIP Weiterleitung (Redirect) 2.3. SIP-Nachrichten SIP unterscheidet zwischen zwei Nachrichtentypen, den Request- und den Response- Messages. Beide Typen besitzen den gleichen Aufbau: Abbildung 4: Aufbau einer SIP-Nachricht Die Leerzeile zwischen dem letzten Header und dem Message Body ist zwingend, auch wenn kein Message Body vorhanden ist.
Laborumdruck Session Initiation Protocol (SIP) Seite | 9
2.3.1. Start-Line
Mit der Start-Line kann unterschieden werden, ob die SIP-Message ein Request oder eine
Response ist, denn sie unterscheiden sich in der Syntax. Gemäß [RFC3261] wird die Start-
Line in einer Request Message als Request-Line definiert und die Response Message startet
mit einer Status-Line. Das Format für die beiden Start-Lines sieht folgendermaßen aus:
Request: method SP request-URI SP SIP-Version CRLF
Response: SIP-Version SP status-code SP reason phrase CRLF
Da die SIP-Version stets das Format SIP/X.X hat, kann leicht festgestellt werden, ob es sich
bei einer Nachricht um einen Request oder eine Response handelt, denn es gibt keine
Methode, die mit einem ’S’ beginnt.
2.3.2. Header
Es gibt drei verschiedene Typen von Headern. General Header werden die Kopfzeilen
genannt, die sowohl in Request- als auch in Response-Nachrichten enthalten sind.
Kopfzeilen, die Bezug auf den Message Body haben, werden als Entity Header bezeichnet.
Die Request-Header enthalten zusätzliche Informationen, die ein Client mit einer Request
Message dem Server mitteilen kann. Das Headerformat lautet:
header name : SP header value CRLF
Vor und nach dem Doppelpunkt können beliebig viele Leerzeichen oder Tabulatoren
eingefügt werden. Im Folgenden sind nur die wichtigsten und notwendigen Header erläutert.
2.3.2.1. General Header
Die General Header sind zwingend nötig in den Request- und Response-Nachrichten.
Call-ID: Mit der Call-ID wird eine SIP-Verbindung eindeutig identifiziert. Mit Hilfe dieses
Headers kann eine Message einer Transaktion zugewiesen werden. Es können Duplikate
erkannt werden, die z.B. auf dem Weg durch einen Forking Proxy entstehen. Die Call-ID ist
einmalig und für jeden Anruf neu zu erstellen.
CSeq: Das CSeq Header-Feld besteht aus einer Sequenznummer und dem
Methodennamen. Der Anfangswert der CSeq-Nummer ist beliebig und wird bei jedem neuen
Request inkrementiert. Es sei denn, dass es eine Wiederholung des Requests ist. Einzige
Ausnahmen sind die Methoden ACK und CANCEL, welche die CSeq-Nummer des Request,
den sie bestätigen oder abbrechen, übernehmen.
Der Server kopiert die CSeq von der Request- in die entsprechende Response-Nachricht.
Contact: Dieses Feld liefert eine URI, dessen Bedeutung abhängig vom Request oder der
Response ist. Das Feld kann im Weiteren einen Anzeigenamen, URI und Header-Parameter
aufweisen.
From: Dieses Feld beinhaltet einen optionalen Anzeigenamen und die Adresse des
Erstellers eines Requests. Zusätzlich können Tags angefügt werden. Bei einer Response
wird der From-Header direkt von der Request übernommen und sagt somit nichts über den
Sender der Nachricht aus.
To: Bezeichnet den beabsichtigten Empfänger eines Requests. Der optionale Tag wird
hauptsächlich dann benötigt, wenn die SIP-URI nichteindeutig ist, z.B. im Falle eines
Helpdesks.
Via: Mit Hilfe des Via-Headers kann der Weg der Message über mehrere Hops
zurückverfolgt werden. So wird sichergestellt, dass eine Response denselben Weg wie der
Request, in umgekehrter Reihenfolge, nimmt. Jeder Proxy fügt seine Adresse in diesem
Header-Feld an.Laborumdruck Session Initiation Protocol (SIP) Seite | 10
Damit die Verbindung auch über einen NAT zurückverfolgbar bleibt, sind spezielle Parameter
vorhanden.
2.3.2.2. Entity Header
Zur weiteren Beschreibung des noch folgenden Message-Bodys, dienen diese Kopfzeilen.
Sie weisen auf die Größe oder den Typ hin.
Content-Type: Dieser Header beschreibt das Media-Protokoll, welches im Message Body
verwendet wird (z.B. SDP, HTML etc.).
Content-Length: Gibt die Anzahl Oktette im Message Body an.
2.3.2.3. Request Header
Diese Header sind nicht zwingend notwendig, verringern aber die Anzahl SIP-Messages, die
ausgetauscht werden müssen, um eine gültige Client-Server Verbindung zu erreichen.
Accept: Der optionale Header teilt dem Server mit, welche Typen von Medien in der
Response akzeptiert werden. Somit kann der Server von Anfang an den korrekten Typ
versenden, sofern er ihn unterstützt, und muss seinerseits nicht auch noch eine Auswahl
schicken, die zuerst noch ausgewertet werden müsste.
Subject: Der freie Text, der hier angefügt werden kann, sollte Informationen über den
laufenden Anruf geben
2.3.3. Message Body
Im Message Body sind Informationen enthalten, die die Verbindung genauer beschreiben.
Hier werden z.B. die Verbindungsparameter ausgehandelt, wie Ports und Protokolle der
Medien. Es können verschiedene Protokolltypen zum Einsatz kommen, z.B. SDP, auf das
weiter unten noch eingegangen wird.
2.3.4. SIP Requests
SIP Requests dienen dem Einleiten von für die jeweilige IP-Multimedia-Kommunikation
notwendigen Transaktionen. Es werden sechs Request-Typen im SIP Standard [RFC3261]
definiert:
INVITE: Diese Nachricht dient dem Aufbau einer SIP-Session, also einem
verbindungsorientierten Kommunikationszustand zwischen zwei Endsystemen. In dieser
Nachricht sind bereits wesentliche Verbindungsparameter (z.B. der gewählte Codec) im
Rahmen des speziell für die Übertragung solcher Informationen geeigneten Unterprotokolls
SDP enthalten.
Das Senden einer INVITE-Nachricht im Rahmen einer bereits bestehenden SIP-Session wird
als Re-Invite bezeichnet und dient üblicherweise der Modifizierung der Session (z.B.
Änderung der SDP-Parameter).
BYE: Das Senden dieser Nachricht bewirkt den Abbau einer bestehenden Session.
OPTIONS: Dient dem Erfragen von Eigenschaften eines Endsystems, ohne dass dafür der
Aufbau einer Session nötig ist.
CANCEL: Mit der CANCEL-Nachricht kann die Bearbeitung von SIP-Transaktionen (z.B. das
Einleiten einer Session) noch während der Etablierung abgebrochen werden.Laborumdruck Session Initiation Protocol (SIP) Seite | 11
ACK: Steht für „ACKnowledge“ und dient als Bestätigung des Empfangs einer finalen
Statusinformation, die ihrerseits eine INVITE-Nachricht beantwortet hat. ACK ist die einzige
SIP-Nachricht, deren Empfang niemals mit einer Statusinformation quittiert wird.
REGISTER: Diese Nachricht dient der Registrierung eines SIP User Agents bei einem SIP-
Registrar Server. Im Rahmen der Registrierung übergibt der User Agent sowohl die dem
Endsystem umgebungsabhängig zugeordnete (temporäre) SIP URI als auch die ständige
SIP URI der das Endsystem nutzenden Person.
2.3.5. SIP Responses
Ein SIP-Server antwortet mit einer oder mehreren Response-Messages
(Statusinformationen) auf einen Request. Die Response-Messages haben eine ähnliche
Struktur wie beim Web-Protokoll HTTP/1.1 und sind in folgende sechs Response-Klassen
unterteilt:
1xx Provisional Responses: Teilt dem Absender eines Request mit, dass der Request
weiter bearbeitet wird. Responses dieses Typs sind u.a.:
• 100 Trying
• 180 Ringing
• 181 Call is being forwarded
2xx Successful: Kennzeichnet den Empfang und die erfolgreiche Bearbeitung einer
Nachricht.
• 200 OK
• 202 Accepted
3xx Redirection: Statusinformation konnte nicht vollständig bearbeitet werden.
• 300 Multiple Choices
• 301 Moved Permanently
• 302 Moved Temporarily
• 305 Use Proxy
4xx Request Failure: Dient als negative Rückmeldung, u.a.:
• 400 Bad Request
• 401 Unauthorized
• 402 Payment required
• 404 Not Found
• 407 Proxy Authentication Required
• 408 Request Timeout
• 484 Address incomplete
• 486 Busy Here
5xx Server Failure: Nachricht kann aus Server-bedingten Gründen nicht bearbeitet werden.
• 500 Internal Server Error
• 501 Not Implemented
• 503 Service unavailable
• 504 Server Timeout
• 513 Message too large
6xx Global-Failure: Trotz erfolgreicher Kontaktierung kein Zustandekommen einer
Transaktion.
• 600 Busy Everywhere
• 603 Decline
• 604 Does not exist anywhere
• 606 Not AcceptableLaborumdruck Session Initiation Protocol (SIP) Seite | 12 2.4. SIP-Dialoge Bei einem SIP-Dialog handelt es sich um einen verbindungsorientierten Kommunikationszustand zwischen zwei SIP-Endsystemen, also z.B. um eine bestehende SIP-Session zum Austausch von Sprache oder anderen Medienformen. SIP-Dialoge werden von einem SIP-Endsystem ausgehend durch die Einleitung bestimmter SIP-Transaktionen (siehe folgendes Kapitel) initiiert und können durch den jeweiligen Kommunikationspartner entweder angenommen oder abgelehnt werden. Ein bestehender Dialog kann ausgehend von beiden beteiligten Endsystemen beendet werden. SIP-Nachrichten werden anhand folgender sog. „Dialog Identifier“ einem bestimmten gemeinsamen Dialog zugeordnet: • Wert des Call-ID-Header-Feldes • Wert des tag-Parameters im From-Header-Feld • Wert des tag-Parameters im To-Header-Feld Abbildung 5: SIP Dialog und Transaktionen 2.5. SIP-Transaktionen Ein bestehender SIP-Dialog setzt voraus, dass zuvor SIP-Kommunikationselemente zwischen den Endsystemen ausgetauscht wurden. Der logische Prozess, der sowohl in einem UAC als auch in einem aus durch das Aussenden bzw. Empfangen eines SIP-Requests ausgelöst wird, wird als Transaktion bezeichnet. Eine Transaktion wird üblicherweise durch das Aussenden (UAS) bzw. Empfangen (UAC) einer finalen Statusinformation in beiden beteiligten SIP-Netzelementen abgeschlossen. Eine
Laborumdruck Session Initiation Protocol (SIP) Seite | 13
Transaktion stellt also den verbindungsorientierten Austausch genau eines SIP-
Requests und einer oder mehrerer SIP-Statusinformation(en) zwischen einem UAC
und einem UAS dar, die direkt miteinander kommunizieren.
Empfangene und gesendete SIP-Nachrichten und -Statusinformationen werden
durch SIP-Netzelemente anhand folgender sog. „Transaction Identifier“ einer
bestimmten, gemeinsamen Transaktion zugeordnet:
• Wert des branch-Parameters im Via-Header-Feld
• Wert des CSeq-Header-Feldes
2.6. Typische SIP-Kommunikationsabläufe
Dieser Teil gibt einen kurzen Überblick über typische SIP-Kommunikationsabläufe
und mögliche Anwendungen.
2.6.1. Registrierung
Die Registrierung eines User Agents beinhaltet das Senden einer REGISTER-Nachricht,
gefolgt von einer „200-OK“-Statusinformation, falls die Registrierung erfolgreich war.
Registrierungen erfordern meist eine Authorisation des User Agents, so kann es passieren,
dass eine „407-Proxy Authentication Required“-Statusinformation vom Registrar Server
versendet wird, wenn der Teilnehmer keine Benutzerinformationen übermittelt hat.
Abbildung 6: SIP-Meldungsfluss bei Regisrierung
2.6.2. Verbindungsaufbau
Der Aufbau einer SIP-Session besteht aus dem Dialog, der mit einer INVITE-Nachricht -
meist an einen SIP-Proxy geschickt - eingeleitet wird. Dieser antwortet sofort mit einer „100-
Try-ing“-Statusinformation, um wiederholtes Senden von INVITE-Nachrichten zu verhindern,
und leitet die Anfrage weiter. Alle provisorischen Statusinformationen, die der angerufene
User Agent erzeugt, werden an den Anrufer zurück geschickt.Laborumdruck Session Initiation Protocol (SIP) Seite | 14
Abbildung 7: SIP-Meldungsfluss bei Initiierung einer Session
Wenn der Angerufene die Verbindung annimmt, so erzeugt dessen User Agent eine
„200-OK“-Nachricht und schickt diese so oft, bis der Verbindungsaufbau durch eine
ACKnowledge-Nachricht vom Anrufer bestätigt wird.
2.6.3. Verbindungsabbau
Der Abbau einer SIP-Kommunikationsverbindung wird durch das Senden eines BYE-
Requests von einem der beteiligten User Agents während einer bestehenden
Session eingeleitet. BYE-Nachrichten werden direkt zwischen den User Agents
versandt, es sei denn ein Proxy hat beim Verbindungsaufbau indiziert, dass er in die
Kommunikation mit einzubeziehen ist. Durch eine „200-OK“-Statusinformation wird
der Verbindungsabbau bestätigt (siehe Abbildung 8).
2.6.4. Record Routing
Durch den Einsatz eines speziellen Routing-Mechanismus lässt sich die generelle
Einbeziehung eines oder mehrerer SIP Proxy Server in die SIP-Kommunikation
zwischen zwei User Agents erzwingen. Dies wird durch den/die betreffenden Proxies
selbst durch das Einfügen des Header-Feldes „Record-Route“ in die die erste
Transaktion einleitende SIP-Nachricht verfügt. Record Routing wird z.B. eingesetzt
bei Network Adress Translation (NAT) oder der Abrechnung von Gesprächen.Laborumdruck Session Initiation Protocol (SIP) Seite | 15
Abbildung 8 zeigt die Auswirkung von Record Routing auf den Abbau einer SIP-
Kommunikationsverbindung.
Abbildung 8: SIP-Meldungsfluss bei Verbindungsabbau
2.6.5. Event Subscription
Bei einem Event handelt es sich im Sinne von SIP prinzipiell um ein bestimmtes Ereignis
(z.B. den aktuellen Status einer Verbindung) bzw. um einen bestimmten Zustand (z.B. die
Kommunikationsbereitschaft eines Teilnehmers). SIP bietet die Möglichkeit zur
Überwachung von Ereignissen bzw. Zuständen, jeweils fokussiert auf ein bestimmtes
„Event“. Eine derartige Überwachung erfolgt im Rahmen eines SIP-Dialogs, der zwischen
dem überwachenden und dem überwachten SIP-Endsystem üblicherweise mit der
SUBSCRIBE-Nachricht etabliert wird. Die Meldung von Ereignissen bzw. erfolgt durch das
überwachte Endsystem mit der NOTIFY-Nachricht.
Abbildung 9: Abbonement des Online-Status eines BenutzersLaborumdruck Session Initiation Protocol (SIP) Seite | 16
3. Weitere Protokolle
3.1. Session Description Protocol (SDP)
Das zuvor erwähnte SIP-Protokoll überträgt selbst keine verbindungspezifischen Parameter,
wie zum Beispiel das verwendete Internet-Protokoll, IP-Addresse, Port und die zur
Verfügung stehenden Audio- / Videocodecs. Es fügt hierfür das Session Description Protocol
(SDP) in den eigenen Payload ein.
Abbildung 10: Schichtenmodell
Auch das SDP-Protokoll ist ASCII formatiert, die Parameter werden durch Abkürzungen
eingeleitet:
• v - Protokollversion
• o - Absender und Session-Identifier
• s - Session-Name
• t - Medienzeitstempel
• m - Medienname und -addresse
• i - Session-Information (*)
• u - URI der Session (*)
• e - Emailadresse (*)
• p - Telefonnummer (*)
• b - Bandbreiten-Informationen (*)
• z - Zeitzonen-Einstellungen (*)
• k - Chiffrierungsschlüssel (*)
• a - Session Attribut (*)
(*) - kennzeichnet optionale Parameter
3.2. Realtime Transport Protocol (RTP)
Definition:
Das Realtime Transport Protocol (RTP, [RFC 3550]) dient dazu, Multimedia-
Datenströme (Audio, Video, Text, etc.) über Netzwerke zu transportieren, d.h. die
Daten zu kodieren, zu paketieren und zu versenden. RTP ist ein Paket-basiertes
Protokoll und wird normalerweise über UDP betrieben. Es findet Anwendung in vielen
Bereichen, u.a. wird es bei den IP-Multimedia-Protokollen H.323 und SIP dazu
verwendet die Audio-/Videoströme des Gespräches zu übertragen. (Quelle: [Wiki])Laborumdruck Session Initiation Protocol (SIP) Seite | 17
Nachdem mit den SIP- und SDP-Protokollen die Session eröffnet wurde, ist das RTP-
Protokoll für den eigentlichen Transport der Mediendaten verantwortlich. Im Gegensatz zu
SIP/SDP ist das RTP-Protokoll nicht ASCII formatiert, sondern beschreibt die Eigenschaften
des Streams durch Bits, die an festgelegten Positionen stehen müssen. Vor den eigentlichen
Nutzdaten (Payload) werden dadurch mindestens 96 Bits vorangestellt.
Abbildung 11: Bit-Struktur RTP-Protokoll
Das RTP-Protokoll kennt folgende Header-Felder:
• V - Version (2 Bit). Zeigt die aktuell verwendete RTP-Version an. Seit 1996 bis heute
gilt die Version 2.
• P - Padding (1 Bit). Gibt mit Wert 1 an, dass die Payload zusätzliche Füllung enthält,
die nicht zum Medienstrom gehört. Das letzte Byte der Payload gibt an, wie viele
Füllbytes enthalten sind. Dieses Verfahren wird bei Verschlüsselung des Datenstroms
benötigt.
• X - Extension (1 Bit). Gibt an, ob CSRC Identifier angehängt wurden.
• CC - CSRC Count (4 Bit). Zeigt an, wie viele CSRC Identifier angehängt wurden.
• M - Marker (1 Bit). Wird in manchen Codecs zur Identifikation von fragmentierten
Strömen benutzt, andere Codecs realisieren mit diesem Bit eine ”Silence
Suppresion“. Dabei werden während der Sprachpausen weniger Sprachpakete
übertragen. Wird das Gespräch fortgeführt, so wird das erste Sprachpaket mit
aktiviertem Marker Bit gesetzt. Ansonsten verbleibt es auf null.
• PT - Payload Type (7 Bit). Gibt den verwendeten Kompressionsalgorithmus an. Es ist
dadurch theoretisch möglich, den Codec während der Laufzeit des Medienstroms zu
ändern.
• SequenceNumber (16 Bit). Stellt eine fortlaufende Nummer dar. Sie muss bei
Beginn des Stroms auf einen Zufallswert initialisiert werden.
• Timestamp (32 Bit). Dient zur Synchronisation der Medienströme, die durch die
unterschiedlichen Laufzeiten (Jitter) des Internets entstehen.
• SSRC (32 Bit). Eindeutiger Schlüssel der den Medienstrom identifiziert
• CSRC (0 - 16 Byte). Optionale Angabe falls, die Payload nicht von dem
Originalsystem stammt, sondern durch ein Zwischensystem (z.B. Mixer) verändert
wurde. Es ist dann möglich ein Array aus 32 Bit-Werten anzugeben, die jeweils die
Originalquelle identifizieren. Durch die Limitierung auf 16 Byte ist die Angabe auf 16
Quellen beschränkt.
3.3. Realtime Control Protocol (RTCP)
Definition:
Das RealTime Control Protocol (RTCP) dient der Aushandlung und Einhaltung von Quality of
Service (QoS) Parametern durch den periodischen Austausch von Steuernachrichten
zwischen Sender und Empfänger. Dazu erfolgt eineLaborumdruck Session Initiation Protocol (SIP) Seite | 18 Rückmeldung der bisher erbrachten Dienstqualität, wodurch eine Anpassung der Übertragungsrate erfolgen kann. Identifikation aller Sitzungsteilnehmer, wodurch semantisch zusammenhängende aber getrennt gesendete Medienströme synchronisiert werden können. Steuerung der für RTCP- Pakete verwendeten Bandbreite, damit der Austausch von RTCP- Nachrichten nicht die Übertragung behindert. (Quelle: [Wiki]) Wie in der Definition bereits erwähnt, existieren verschiedene Möglichkeiten, mit RTCP Informationen auszutauschen. Es existieren fünf Arten von RTCP Nachrichten: SR - Sender Report, enthält Statistiken über die Verbindungsqualität aus Sendersicht. Es werden darin Zeitstempel, Anzahl der übertragenen Bytes und Anzahl der übertragenen Pakete vermerkt. RR - Receiver Report, enthält Statistiken aus Empfängersicht, die die Anzahl der verlorenen Pakete, die letzte Sequenznummer und die durchschnittliche Varianz bei Übertragungszeit (Jitter) SDES - Source Description, beschreibt den Teilnehmer (engl. ”Participant“) per Name (”CName“) oder per Email-Adresse. Außerdem können hier beliebige Zusatzinformationen gespeichert werden. BYE - Signalisiert das Ende eines RTP-Stroms (nicht zu verwechseln mit BYE des SIP- Protokolls). APP – Anwendungsspezifische Daten.
Laborumdruck Session Initiation Protocol (SIP) Seite | 19
4. Genutzte Programme
4.1. hping3 – der TCP/IP Netzwerkassembler
Der Netzwerkassembler ist ein konsolenbasiertes Programm, mit dem ein IP-Paket mit
variabler IP-Quelldresse und vielen weiteren Optionen und Parametern gesendet werden
kann. Im folgendem ist ein Auszug aus der Hilfe dieses Programmes gezeigt.
usage: hping3 [options] host //‘host‘ bezeichnet das Ziel des manipulierten IP-Paketes
-h --help show this help
-c --count packet count
-i --interval wait (uX for X microseconds, for example -i u1000)
-I --interface interface name (otherwise default routing interface)
Mode
default mode TCP
-0 --rawip RAW IP mode
-1 --icmp ICMP mode
-2 --udp UDP mode
-8 --scan SCAN mode.
Example: hping --scan 1-30,70-90 -S www.target.host
-9 --listen listen mode
IP
-a --spoof spoof source address
--rand-dest random destionation address mode. see the man.
--rand-source random source address mode. see the man.
-t --ttl ttl (default 64)
-N --id id (default random)
-W --winid use win* id byte ordering
-r --rel relativize id field (to estimate host traffic)
-f --frag split packets in more frag. (may pass weak acl)
-x --morefrag set more fragments flag
-y --dontfrag set dont fragment flag
-g --fragoff set the fragment offset
-m --mtu set virtual mtu, implies --frag if packet size > mtu
-o --tos type of service (default 0x00), try --tos help
-G --rroute includes RECORD_ROUTE option and display the route buffer
--lsrr loose source routing and record route
--ssrr strict source routing and record route
-H --ipproto set the IP protocol field, only in RAW IP mode
UDP/TCP
-s --baseport base source port (default random)
-p --destport [+][+] destination port(default 0) ctrl+z inc/dec
-k --keep keep still source port
-w --win winsize (default 64)
-O --tcpoff set fake tcp data offset (instead of tcphdrlen / 4)
-Q --seqnum shows only tcp sequence number
-b --badcksum (try to) send packets with a bad IP checksum
many systems will fix the IP checksum sending the packet
so you'll get bad UDP/TCP checksum instead.
-M --setseq set TCP sequence number
-L --setack set TCP ack
-F --fin set FIN flag
-S --syn set SYN flag
-R --rst set RST flag
-P --push set PUSH flag
-A --ack set ACK flag
-U --urg set URG flag
-X --xmas set X unused flag (0x40)
-Y --ymas set Y unused flag (0x80)
--tcpexitcode use last tcp->th_flags as exit code
--tcp-timestamp enable the TCP timestamp option to guess the HZ/uptime
Common
-d --data data size (default is 0)
-E --file data from file
-e --sign add 'signature'
-j --dump dump packets in hexLaborumdruck Session Initiation Protocol (SIP) Seite | 20 4.2. Wireshark Wireshark ist ein Netzwerksniffer, mit dem Sie den Netzwerkverkehr auf allen OSI-Schichten aufzeichnen und analysieren können. Mit ihm ist in diesem Versuch der Zeichengabeverkehr zu untersuchen und die Audiodaten mitzuschneiden. Bei dem Menuepunkt CAPTURE -> INTERFACES kann man mit Start des entsprechenden Interfaces den Verkehr mitsniffen. Um nur die SIP-spezifischen Pakete anzuzeigen, müssen Sie einen Filter einrichten. Geben Sie hierzu unter (Analyze > Display Filters > Filter String) „sip“ ein. Über (Telephony > VoIP- Calls) können Sie sich den Sequenzdiagramme der Verbindung erzeugen. Bei weiteren Fragen zu diesem Programm wenden Sie sich bitte Ihren Laborbetreuer. 4.3. Jitsi Jitsi ist eins von vielen verfügbaren Software-Phones (Softphones). Es unterstützt im Bereich SIP sowohl die Telefonie über einen Proxy/Registrar, als auch direkte IP-Wahl. Entsprechende Nutzerprofile für beide Betriebsarten sind für den Laborversuch bereits vorbereitet. Bei Bedarf können Sie die notwendigen Einstellungen in den Profilen in Absprache mit dem Laborbetreuer auch anpassen.
Laborumdruck Session Initiation Protocol (SIP) Seite | 21
5. Versuchsvorbereitung
Für die erfolgreiche Durchführung des Versuchs sind neben dem Verständnis der Funktionen
und Abläufe des SIP-Protokolls Grundlagenkenntnisse bei der Bedienung von grafischen
und Text- basierten Linux-Systemen erforderlich. Bitte beantworten Sie auch die folgenden
Fragen in kurzen Stichworten.
5.1. Aufgabe 1: Was ist SIP und wofür wird es
verwendet? Wofür wird SIP nicht verwendet?
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
5.2. Aufgabe 2: Welche Netzelemente kennt das SIP
Model? Beschreiben Sie jeweils kurz deren Funktion.
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
5.3. Aufgabe 3: Was versteht man unter dem Model
des SIP-Trapezoids?
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________Laborumdruck Session Initiation Protocol (SIP) Seite | 22
5.4. Aufgabe 4: Welche AudioCodecs werden bei VoIP
typischerweise genutzt (Nennen Sie mindestens 3)?
Wie handeln die Gesprächsteilnehmer den Codec
aus?
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
5.5. Aufgabe 5: HPING Aufruf
Sie speichern eine SIP-Nachricht in einer Textdatei ab. Bitte suchen sie die notwendigen
Kommandobefehle bzw. Parameter für das Programm hping3 heraus, um diese Nachricht in
ein IP-Packet zu packen und zu verschicken. Die nötigen Parameter hierzu sind:
• Source-IP-Adresse
• Source-Port
• Destination-IP-Adresse
• Destination-Port
• Transportprotokoll: UDP
• Anzahl der zu verschickenden Pakete: 1 (ohne Fragmentierung)
• Dateiname: Name der Datei, die die zu sendende SIP-Nachricht enthält
• Datasize: Dateigröße in Bytes
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________Laborumdruck Session Initiation Protocol (SIP) Seite | 23
6. Versuchsdurchführung
Der Versuchsaufbau besteht aus 5 gleichen Rechnern (Node A bis E). Node A hat Windows
7 (x64) als Betriebssystem und Node B bis Node E laufen mit Ubuntu 14.04(LTS) (x64). Sie
arbeiten vorwiegend mit „root“-Rechten, da einige Funktionen (Netzwerk-Interfaces
konfigurieren, Netzwerkverkehr mitsniffen, etc.) nur so möglich sind. Das Passwort erhalten
Sie vom Laborbetreuer. Sie können sich mit ‚sudo –s‘ für die Dauer des gesamten
Laborversuches als root anmelden.
Alle Rechner werden in diesem Laborversuch an einem Hub betrieben, um das Mitsniffen zu
vereinfachen. Würde ein Switch zum Einsatz kommen, wäre das Mitsniffen nur durch einen
entsprechenden Monitoring-Anschluss am Switch möglich (soweit dieser dies unterstützt).
Die Rechner haben eine vorbereitete Konfiguration. Gern können Sie aber auch Ihre eigene
Konfiguration durch Anpassung der Interface-Adressen und SIP-Profile einrichten. Sollten
Sie Änderungen an der Konfiguration vornehmen, dokumentieren Sie diese entsprechend.
Rechner Funktion IP-Adresse SIP-URI Telefonnummer
(für Direktverbindung) (über Proxy)
node A Jitsi,Wireshark 10.0.0.1 / 24 a@10.0.0.1 123
node B Jitsi,Wireshark,Hping3 10.0.0.2 / 24 b@10.0.0.2 456
node C Kamailio(SIP-Proxy) 10.0.0.3 / 24 --- ---
node D - 10.0.0.4 / 24 --- ---
node E Jitsi 10.0.0.5 / 24 e@10.0.0.5 789
Bitte dokumentieren Sie Ihre Ergebnisse und Erkenntnisgewinne, wie Sie es für
„ingenieurswürdig“ halten und nutzen Sie dafür die vorbereiteten Diagramme im Umdruck.
6.1. SIP-Protokolluntersuchungen
In diesem Teil wird das SIP-Protokoll unter verschiedenen Szenarien betrachtet.
6.1.1. Direkte Verbindung
In diesem Versuchsteil werden Sie die direkte VoIP-Kommunikation zwischen SIP-User-
Agents untersuchen. Dies ist der einfachste Fall einer SIP-Session, da keine weiteren
Netzelemente wie Proxy- oder Registrar-Server zum Einsatz kommen. Jedoch ist es
erforderlich, dass dem die Verbindung initiierenden Client die SIP-Adresse des Empfängers
bekannt ist. Der VoIP-Client „Jitsi“ muss für die Durchführung der direkten Verbindung
entsprechend konfiguriert sein (Profil für direkte Verbindung (Registrarless) auswählen). Die
Profile sind unter dem Menupunkt „Werkzeuge“ auswählbar.
6.1.1.1. 2 User Agents
• Node B und E werden für die Gespräche genutzt (Headsets sind vorhanden).
Überprüfen Sie die Erreichbarkeit der gewählten Rechner auf IP-Ebene (ping-Befehl).
• Auf Node A nutzen Sie „Wireshark“ für die Aufnahme des Datenverkehrs.
• Starten Sie die Wireshark-Aufnahme, bevor Sie das Telefongespräch beginnen.
• Stoppen Sie nach der Beendigung des Telefonats die Wireshark-Aufnahme.
• Dokumentieren Sie die ausgetauschten SIP-Nachrichten zwischen den beteiligten
Rechnern in einem Sequenzdiagramm (automatisch von Wireshark erstellbar unter
Telephony VoIP-Calls Flow). Schauen Sie sich auch die ausgehandelten
Session-Parameter (Codec etc.) an und dokumentieren Sie diese.Laborumdruck Session Initiation Protocol (SIP) Seite | 24 Ihr ermitteltes Sequenzdiagramm zu 6.1.1.1 (doppelt auftretende PDUs bitte nicht mit aufführen): Notizen zu den ausgehandelten Session-Parametern: __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________
Laborumdruck Session Initiation Protocol (SIP) Seite | 25
6.1.2. Verbindung via Proxy/Registrar
Die SIP-Kommunikation läuft üblicherweise über einen bzw. meist mehrere Proxy-Server ab.
In diesem Teilversuch kommt ein einzelner SIP-Proxy zum Einsatz, an dem sich die
Softphones anmelden.
6.1.2.1. Registrierung der Clients
• Überprüfen Sie auf Node C die Erreichbarkeit auf IP-Ebene (ping-Befehl) und starten
Sie dann den SIP-Proxy „kamailio“ mit root-Rechten.
• Starten Sie erneut eine Aufnahme mit Wireshark.
• Im VoIP-Client der Nodes A und E müssen Sie nun Ihre SIP-Identität einrichten,
indem Sie das Benutzerprofil für den Proxy-Betrieb laden. Wenn dieses Profil noch
nicht erstellt ist oder nicht korrekt konfiguriert ist, nehmen Sie bitte die erforderlichen
Einstellungen selbst vor. Das Passwort für die SIP-Accounts ist in diesem
Laborversuch frei von Ihnen wählbar (der Proxy akzeptiert jede Anmeldung).
• Nehmen Sie den SIP-Meldungsfluss der Registrierung eines Clients mit Wireshark
auf und tragen Sie ihn in das folgende Diagramm ein. Beschreiben sie in kurzen
Stichworten die ausgetauschten SIP-Nachrichten.
Abbildung 12: SIP-Meldungsfluss bei Registrierung
Notizen zu den ausgetauschten Nachrichten:
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________Laborumdruck Session Initiation Protocol (SIP) Seite | 26
6.1.2.2. 2 User Agents – Session über Proxy
• Starten Sie erneut die Wireshark-Aufnahme.
• Stellen Sie nun zwischen Node A und Node E mit Hilfe der eingerichteten
Telefonnummern eine Verbindung her und beenden danach das Gespräch nach
einer beliebigen Dauer wieder.
Tragen Sie den SIP-Meldungsfluss in nachfolgendes Diagramm ein und dokumentieren sie
ggf. auftretende Erkenntnisgewinne. (doppelt auftretende PDUs bitte nicht mit aufführen):
Abbildung 13: Meldungsfluss für Signalisierung von 2 Teilnehmern über Proxy
Notizen (was ist nun anders und was bleibt evtl. gleich?):
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________Laborumdruck Session Initiation Protocol (SIP) Seite | 27
6.1.2.3. 3 User Agents
Für diesen Versuch ist keine praktische Durchführung notwendig!
Stellen Sie in der Theorie wie in vorheriger Durchführung erneut eine Verbindung mit den
zwei Teilnehmern über einen SIP-Proxy her und erweitern Sie nun das Gespräch um einen
weiteren Teilnehmer mittels Konferenz-Modus.
Skizzieren Sie grob die Kommunikationsbeziehungen (VoIP-Signalling und VoIP-Payload)
die zwischen allen beteiligten Netzelementen auftreten müssen.
Kennzeichen Sie die Netzelemente mit ihrer Funktion/Bezeichnung oder IP-Adresse.
Skizzieren Sie mit nummerierten Pfeilen zwischen den Netzelementen die Art der
Kommunikationsbeziehung (VoIP-Signalling und VoIP-Payload).
Abbildung 14: Verkehrsbeziehungen zwischen Netzelementen bei einer VoIP-KonferenzLaborumdruck Session Initiation Protocol (SIP) Seite | 28
6.2. Hacking
In diesem Abschnitt werden die Sicherheitsaspekte von VoIP untersucht. Sowohl in der
Zeichengabe, als auch im Nutzdatenbereich wird jeweils ein Beispiel als praktische Übung
vollzogen, um nahezulegen, wie einfach es ist, unbefugt zu stören und wie wichtig es ist, sich
dagegen zu sichern.
6.2.1. Fremdes Gespräch beenden
In diesem Teilversuch sollen Sie ein laufendes VoIP-Telefonat zwischen zwei Teilnehmern
von anderer Stelle aus beenden, indem Sie einen passenden SIP-BYE-Request versenden,
als ob er von einem der Teilnehmer kommt. Zu diesem Zweck begeben Sie sich hier in die
Rolle des „Hackers“. Der BYE-Request muss bestimmte Anforderungen erfüllen, damit er
vom VoIP-Client (Jitsi) akzeptiert wird und dieser das Telefonat beendet. Die SIP-Parameter
der Session und die IP-Daten müssen entsprechend gewählt sein. Um das IP-Paket
(Source-IP, Source-Port, etc.) zu fälschen, wird das Programm hping3 benutzt.
In der Vorbereitung haben Sie die nötigen Daten zum Fälschen eines IP-Paketes schon
herausgesucht. Was nun gemacht werden muss:
• Mitsniffen des Rufaufbaus zwischen Node A und E (Direktverbindung, nicht über den
Proxy!) mittels Wireshark auf Node B.
• Entnahme der SIP-Session-Parameter aus dem ACK-Response: SIP-Layer im ACK-
Paket markieren; File EXPORT Selected Packet Bytes ack.txt). Beachten Sie
für später unbedingt Absender- und Empfänger-IP des Pakets.
• Erstellen eines BYE-Requests: Ändern der ack.txt zu einer gültigen BYE-Nachricht,
Abspeichern als bye.txt. Hinweis: Sie müssen an drei Stellen Werte verändern, damit
der VoIP-Client die Nachricht akzeptiert.
• Abschicken des BYE-Requestes ausgehend von Node B mittels hping3.
• Überprüfen, ob die Verbindung unterbrochen ist.
Dokumentieren Sie, was wann wo unterbrochen ist, und was noch funktioniert, oder auch
nicht mehr.
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
Welche drei Werte des ursprünglichen ACK-Requests mussten Sie anpassen?
Zeile __ : __________________________________________________
Zeile __ : __________________________________________________
Zeile __ : __________________________________________________Laborumdruck Session Initiation Protocol (SIP) Seite | 29
6.2.2. Nutzdaten aufnehmen
Ziel dieses Teilversuchs ist es, ein VoIP-Telefonat abzuhören. Dazu werden die
übertragenen RTP-Sprachdaten aufgezeichnet und lokal wiedergegeben. Dazu gehen Sie
wie folgt vor:
• Starten Sie erneut die Wireshark-Aufnahme.
• Führen Sie ein Telefonat mit Codec G.711a oder G.711u zwischen zwei beliebigen
Nodes (direkt oder über Proxy). Beenden Sie anschließend wieder das Telefonat und
die Aufzeichnung des Netzwerkverkehrs.
• Mit dem Menüpunkt von Wireshark (Telephony VoIP-Calls) können Sie sich nun
alle Medienströme der aufgezeichneten Telefonate im lokalen Netzwerk anzeigen
lassen. Nutzen Sie den integrierten Player, um die Medienströme ihres Telefonats zu
decodieren und abzuspielen.
• Lassen Sie sich das Ergebnis vom Laborbetreuer bestätigen.
Vielen Dank für die Teilnahme an diesem Laborversuch. Wir hoffen, dass Sie eine Menge
gelernt haben.Laborumdruck Session Initiation Protocol (SIP) Seite | 30 7. Literatur [Trick] U. Trick, F. Weber: SIP, TCP/IP und Telekommunikationsnetze; Oldenbourg Verlag, 2. Auflage, 2005 [Badach] Anatol Badach: Voice over IP - Die Technik; Carl Hanser Verlag, 2004 [RFC 2327] M. Handley, V. Jacobson: Session Description Protocol, RFC2327, Internet Engineering Task Force (IETF), April 1998, Internet: http://www.faqs.org/rfcs/rfc 2327.html [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley und E. Schooler: SIP: Session Initiation Protocol, RFC3261, Internet Engineering Task Force (IETF), Juni 2002, Internet: http://www.faqs.org/rfcs/rfc 3261.html [RFC 3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC3550, Internet Engineering Task Force (IETF), Juli 2003, Internet: http://www.faqs.org/rfcs/rfc3550.html [RFC3665] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers: Session Initiation Protocol (SIP) Basic Call Flow Examples, RFC3665, Internet Engineering Task Force (IETF), December 2003, Internet: http://www.faqs.org/rfcs/rfc3665.html [Wiki] Wikipedia - Die freie Enzyklopädie, Internet: http://www.wikipedia.de
Sie können auch lesen
