Labor für Kommunikationssysteme - ostfalia.de · Es werden zwei Typen von SIP-Proxy-Servern unterschieden – Stateless und Stateful Proxy. 2.2.2.1.Stateless Proxy Server Ein Stateless

Labor für Kommunikationssysteme Leitung: Prof. Dr.-Ing. Diederich Wermser

Versuch: Session Initiation Protocol (SIP)

Sommersemester 2017

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


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


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.


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 Responses


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.


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.


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.


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.


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.


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 Acceptable


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


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.


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.


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 Benutzers


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


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 eine


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.


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 [+][+]<port> 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 hex


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.


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?

__________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________


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

__________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________


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

(für Direktverbindung) Telefonnummer

(über Proxy) node A Jitsi,Wireshark 10.0.0.1 / 24 [email protected] 123 node B Jitsi,Wireshark,Hping3 10.0.0.2 / 24 [email protected] 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 [email protected] 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.


Ihr ermitteltes Sequenzdiagramm zu 6.1.1.1 (doppelt auftretende PDUs bitte nicht mit aufführen): Notizen zu den ausgehandelten Session-Parametern: __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________


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: __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________


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?): __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________


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


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 __ : __________________________________________________


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.


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

Documents

Labor für Kommunikationssysteme - ostfalia.de · Es werden zwei Typen von SIP-Proxy-Servern unterschieden – Stateless und Stateful Proxy. 2.2.2.1.Stateless Proxy Server Ein Stateless