M a s t e r - T h e s i s

Transkript

1 M a s t e r - T h e s i s Extraktion und Analyse von Signalisierungs- und Mediendaten zur Abwehr von Telefon-Spam in Voice-over-IP-Netzen Dipl.-Ing. (FH) Bernhard Mainka Institut für Nachrichtentechnik Labor für IT-Sicherheit 3. April 2013

2

3 M a s t e r - T h e s i s Extraktion und Analyse von Signalisierungs- und Mediendaten zur Abwehr von Telefon-Spam in Voice-over-IP-Netzen Student: Dipl.-Ing. (FH) Bernhard Mainka Matrikelnummer: Referent: Prof. Dr. Heiko Knospe Korreferent: Prof. Dr. Christoph Pörschmann Hiermit versichere ich, dass ich diese Master-Thesis selbständig angefertigt habe und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel verwendet habe. Köln, den 3. April 2013 Bernhard Mainka

4

5 Inhaltsverzeichnis 1. Einleitung 1 2. Grundlagen SPIT-Erkennung und -Abwehr Arten von Telefon-Spam Grundlegende Verfahren Black-, White- und Greylisting Consent-Based Communications Inhaltsfilterung Reputationssysteme Turing-Tests, CAPTCHAs Integrative Ansätze VoIP Secure Application Layer Firewall (VoIP SEAL) Spam over Internet Telephony Detection Service (SPIDER) Multistage SPIT Detection in Transit VoIP You can SPIT, but you can t hide Entwicklung und Integration von signalisierungsbasierten Verfahren zum Schutz vor Telefon-SPAM PALLADION Verfahren zur Identifikation und Abwehr von Telefon- Spam (VIAT) Connecting VIAT and PALLADION Extraktion von Daten aus SIP-basierten VoIP-Netzwerken Aktive Extraktion Passive Extraktion Passiver SIP-Stack Verwandte Arbeiten und Produkte zur passiven Extraktion Praxisteil Aufgabenstellung Umsetzung Erforderliche Funktionalität Analyse der Signalisierung Programmiertechnische Grundlagen Smart Pointer v

6 Inhaltsverzeichnis Scoped Locking Move Semantik und Rvalue Referenzen Singleton in Multithreading-Umgebungen Softwarearchitektur Schnittstellen Config LIBPCAP File System TCP Client OutputHandler TCP Server Console Datenspeicher ThreadFriendlyMap ThreadFriendlyQueue Prozesse, Threads PcapHandler TlayerDispatcher UdpHandler SipProcessor SigBasedAna AudioHandler OutputHandler Watchdog Console Softwaretest Testumgebung Signalisierungsverarbeitung SIPp Testszenario Dateien und Verzeichnisse Durchführung der Tests Anpassungen an Asterisk B Zweiteilung der Tests der Signalisierungsverarbeitung Test-1: Beschaffung und Verarbeitung von Signalisierungsinformationen Test-2: Signalisierungsbasierte Analyse Audioverarbeitung Bewertung der Testergebnisse Zusammenfassung und Ausblick 87 A. Palladion 91 B. SipProcessor 95 B.1. Klassendiagramme vi

7 Inhaltsverzeichnis B.2. Aktivitätsdiagramme C. SigBasedAna 109 C.1. Klassendiagramme C.2. Aktivitätsdiagramme D. AudioHandler Klassendiagramme 117 E. OutputHandler Klassendiagramme 119 F. Console Klassendiagramme 121 G. Softwaretest 123 G.1. Konfiguration von callx II G.2. SIPp G.2.1. Szenario XML Datei G.2.2. Szenario Datendatei Literatur 133 vii

8

9 Abbildungsverzeichnis 2.1. Erweiterter VIAT-Prototyp II Komponenten und Informationsfluss der Kombination von VIAT und PAL- LADION Klassendiagramm CallxConfig Datenflussdiagramm Callx II Klassendiagramm CallxConfig Klasse ThreadFriendlyMap Klasse ThreadFriendlyQueue Klasse CallxThread Aktivität des Threads PcapHandler Aktivität der Methode PcapHandler::callback() Klassendiagramm PcapHandler Klasse PcapWrapper Klassendiagramm TlayerPacket Klasse SocketAddress Aktivität des Threads TlayerDispatcher Aktivität des Threads UdpHandler Transaktionsautomaten des passiven SIP-Stacks Klassendiagramm SipProcessor (Übersicht) Aktivität des Threads SipProcessor, Methode SipProcessor::worker() Sequenzdiagramm Erzeugung von Events: Verbindungsauf- und Abbau Sequenzdiagramm Erzeugung von Events: Abbruch des Verbindungsaufbaus Aktivität des Threads SigBasedAna Klassendiagramm AudioHandler (Übersicht) Aktivität des Threads AudioHandler Aktivität des Threads OutputHandler Aktivität des Threads Watchdog Aktivität des Threads Console Aufbau der Testumgebung A.1. PALLADION Webinterface A.2. Konfigurationsdialog der Verhaltensanalyse im PALLADION Webinterface 92 A.3. Benutzerschnittstelle der PALLADION-VIAT Anbindung A.4. Komponenten und Protokolle der Anbindung von PALLADION an VIAT 93 ix

10 Abbildungsverzeichnis B.1. Klasse SipProcessor B.2. Klasse SipPacket B.3. Klasse Call B.4. Klasse RtpSink B.5. Klasse Dialog B.6. Klasse Transaction B.7. Aktivität create call B.8. Aktivität handle initial request B.9. Aktivität handle initial request B.10.Aktivität handle INVITE B.11.Aktivität process Session Description B.12.Aktivität handle ACK on success B.13.Aktivität confirm RtpSink objects B.14.Aktivität handle BYE B.15.Aktivität handle OPTIONS B.16.Aktivität handle CANCEL B.17.Aktivität handle ACK on NON-SUCCESS B.18.Aktivität annul RtpSink objects B.19.Aktivität handle PROVISIONAL response B.20.Aktivität handle PROVISIONAL on INVITE B.21.Aktivität handle SUCCESS response B.22.Aktivität handle SUCCESS on INVITE B.23.Aktivität handle RESPONSE on BYE B.24.Aktivität handle RESPONSE on OPTIONS B.25.Aktivität handle RESPONSE on CANCEL B.26.Aktivität handle NON-SUCCESS response B.27.Aktivität handle NON-SUCCESS on INVITE B.28.Aktivität create and push event C.1. Klasse SigBasedAna C.2. Klassen InviteEvent, CancelEvent, ByeEvent, OptionsEvent; Schnittstelle SbaEvent C.3. Klasse SbaIncident C.4. Aktivität analyze call attempts C.5. Aktivität analyze calls concurrent C.6. Aktivität analyze call completion C.7. Aktivität analyze call duration average C.8. Aktivität analyze calls cumulitive duration C.9. Aktivität analyze calls closed by callee D.1. Klasse AudioHandler D.2. Klasse PcmAudio D.3. Klassen AudioDecoderInterface, G711Decoder, GsmDecoder x

11 Abbildungsverzeichnis E.1. Klasse OutputHandler E.2. Klassen WaveFileWriter, RawFileWriter, FileWriterInterface E.3. Klasse ViatDb F.1. Klasse Console xi

12 xii

13 Kapitel 1. Einleitung Diese Master-Thesis entstand im Rahmen des Projekts VIAT 1 (Verfahren zur Identifikation und Abwehr von Telefon-SPAM). Dabei handelt es sich um ein vom BMBF (Bundesministerium für Bildung und Forschung) gefördertes Forschungsprojekt 2 mit einer Laufzeit von Juli 2009 bis Dezember Die Projektpartner sind IPTEGO GmbH, Sirrix AG und Prof. Dr. Fingscheidt (Technische Universität Braunschweig). Das Projekt VIAT verfolgt das Ziel, Spam over Internet Telephony (SPIT) in der Form von mehrfach eingespieltem Audiomaterial, auch Robocalls genannt, zu identifizieren und zu blockieren. Gegenüber bisherigen Verfahren, die meistens auf der Analyse von Signalisierungsdaten beruhen, basiert das im Projekt VIAT entwickelte auf der Analyse des Inhalts von Telefonverbindungen. Dieser Fingerprint ist robust gegenüber Rauschen, Sprachkodierung und anderen Veränderungen. Die Aufgabenstellung dieser Arbeit besteht aus zwei Teilen. Die erste Teilaufgabe ist die Erweiterung des VIAT-Systems um eine passive Extraktion von Daten aus dem VoIP-Netzwerk. Dazu ist die Verarbeitung einer Kopie des Netzwerkstroms erforderlich. Eine besondere Herausforderung der passiven Extraktion ist die Zuordnung von Signalisierungs- und Mediendaten. Zu diesem Zweck wird ein eigener SIP-Stack entwickelt. Gegenüber dem bisher eingesetzten Verfahren bietet die passive Extraktion den Vorteil, dass keine direkt an der Telefonverbindung beteiligten Systeme involviert sind. Diese Unabhängigkeit erlaubt außerdem eine problemlose Integration in vorhandene VoIP-Umgebungen. Die zweite Teilaufgabe ist die Verringerung der Anzahl der zu analysierenden Verbindungen, ohne dass die Erkennungsleistung von Robocalls negativ beeinflusst wird. Bislang ist das VIAT-System darauf ausgelegt sämtliche Telefonverbindungen zu analysieren. Da es sich bei der Mehrzahl der Verbindungen nicht um SPIT handelt, besteht beträchtliches Potential zur Reduzierung der benötigten Ressourcen. Die Umsetzung erfolgt durch die Implementierung einer signalisierungsbasierten Klassifizierung von Teilnehmern, die zur Vorselektion von zu analysierenden Telefonverbindungen genutzt wird Förderkennzeichen 1736X09 1

14 Kapitel 1. Einleitung Der Autor hat im Vorfeld dieser Arbeit bereits Erfahrungen mit der passiven Extraktion gesammelt [Mai10]. Die von ihm zuvor entwickelte Anwendung callx wurde bereits im Projekt Connecting VIAT and PALLADION 3 eingesetzt. PALLADION ist ein NGN- Monitoring-System des Projektpartners IPTEGO. In dem Projekt wurde die signalisierungsbasierte Analyse des PALLADION-Systems mit der inhaltsbasierten Analyse des VIAT-Systems kombiniert. Mit der Anwendung callx wurde ein funktionierendes System zur passiven Extraktion von Daten aus VoIP-Netzwerken entwickelt. Es stellte sich heraus, dass das singlethreaded Design der Anwendung callx nicht die nötige Performanz für den vorgesehenen Einsatz in High-Traffic-Umgebungen liefern kann. Zur Umsetzung der genannten Aufgaben wird ein neues Software-Design entwickelt. Mit diesem Design ist es möglich eine hohe Anzahl paralleler Verbindungen zu extrahieren. Die Extraktion wird dazu in mehrere Arbeitsschritte unterteilt, wobei jeder von einem eigenen Thread bearbeitet wird. Basis der Extraktion ist ein neu entwickelter SIP-Stack nach RFC 3261 [Ros02]. Im Vergleich zum SIP-Stack aus [Mai10] bietet dieser eine umfassendere Umsetzung des RFC, eine größere Robustheit gegenüber Paketverlust und eine Weitergabe von Daten an die signalisierungsbasierte Analyse. Die zur Entwicklung verwendeten neuen Sprachelemente des ISO Standards C++11 unterstützen die Effizienz und Robustheit der Anwendung. Diese Arbeit besteht aus fünf Kapiteln. Das auf die Einleitung folgende Kapitel 2 geht auf die Grundlagen der SPIT-Erkennung und -Abwehr ein. Neben VIAT werden einige weitere Verfahren und Frameworks vorgestellt. Weiterhin wird die Extraktion von Daten aus VoIP-Netzwerken kurz beschrieben. Dieses Thema wurde bereits in [Mai10] detailliert behandelt. Der Praxisteil wird in Kapitel 3 vorgestellt. Nach der Definition der Aufgabenstellung folgt ein Überblick über die entwickelte Software callx ii. Weiterhin wird auf besondere Merkmale des Software-Designs eingegangen. Es folgt eine detaillierte Beschreibung der Implementierung unter Verwendung von Klassen-, Aktivitätsund Datenflussdiagrammen. Der Softwaretest in Kapitel 4 umfasst mehrere Testfälle zur Überprüfung der Funktionalität von callx ii. Das Kapitel 5 schließt die vorliegende Arbeit mit einer Zusammenfassung und einem Ausblick ab. 3 Eine Projektarbeit des Autors im Rahmen des Masterstudiengangs Technische Informatik. 2

15 Kapitel 2. Grundlagen Dieses Kapitel besteht aus zwei Teilen. Der erste Teil gibt einen Überblick zum Stand der Technik von SPIT-Erkennung und -Abwehr. Dazu wird unter anderem RFC 5039 [Ros08] herangezogen, der eine Einführung in das Thema Telefon-Spam bietet und in dem diverse Techniken zur Abwehr von Spam diskutiert werden. Danach werden einige integrative Ansätze vorgestellt, wovon die meisten auf der Analyse von Signalisierungsdaten basieren. Am Ende des ersten Teils wird das Projekt VIAT vorgestellt und das dort entwickelte Verfahren, eine inhaltsbasierte Analyse zur Erkennung von wieder eingespieltem Audiomaterial, erläutert. Dazu zählt die Generierung eines robusten Fingerprints der Audiodaten sowie die effiziente Suche ähnlicher Fingerprints in einer großen Anzahl (größer eine Million) bereits existierender. Der zweite Teil erläutert zwei unterschiedliche Verfahren zur Datenextraktion aus SIPbasierten VoIP-Netzwerken. Dazu wird insbesondere auf ein Verfahren eingegangen, das eine Kopie des Netzwerkstroms verarbeitet und bereits in [Mai10] vorgestellt wurde SPIT-Erkennung und -Abwehr In diesem Abschnitt werden zuerst die verschiedenen Arten von Telefon-Spam beschrieben. Danach werden grundlegende Verfahren vorgestellt, die zur Erkennung und Abwehr von Telefon-Spam genutzt werden können. Darauf aufbauend werden einige integrative Ansätze vorgestellt. Darunter fällt auch das Forschungsprojekt VIAT, in dessen Rahmen diese Arbeit erstellt wurde Arten von Telefon-Spam [Ros08] geht allgemein auf Spam in SIP-basierten Netzen ein. Dabei wird zwischen folgenden Formen von Spam unterschieden: 3

16 Kapitel 2. Grundlagen Call Spam Mit Call Spam wird der massenhafte Versuch bezeichnet, eine vom Angerufenen zu bestätigende Mediensitzung aufzubauen, um anschließend eine Nachricht in der Form von Audio, Video oder Text zu übertragen. IM Spam Bei Instant Messaging Spam handelt es sich um unerwünschte Textnachrichten, die mittels der SIP-Anfrage MESSAGE versendet werden. Eine weitere Möglichkeit Spam in Form von Textnachrichten zu versenden bietet die INVITE Anfrage. Dabei kann eine Textnachricht über den SIP-Header subject oder den -Body übertragen werden, sofern der angesprochene User Agent die Anzeige dieser Art Nachrichten unterstützt. Presence Spam Als Presence Spam wird das massenhafte Versenden von unerbetenen SUBSCRIBE Anfragen bezeichnet, um auf die Buddy-List oder die White-List eines Benutzers zu gelangen und dadurch die Möglichkeit zu erhalten Textnachrichten zu senden oder andere Formen der Kommunikation zu nutzen Grundlegende Verfahren In [Ros08] werden einige bereits aus anderen Bereichen bekannte Verfahren zur Lösung des SPIT Problems diskutiert, unter anderem Blacklisting und Whitelisting, Consent- Based Communications, Inhaltsfilterung, Reputationssysteme und Turing-Tests Black-, White- und Greylisting Blacklisting Eine Black-List enthält Adressen von Absendern, die bereits als Spam- Versender auffällig wurden. Neue Verbindungsversuche dieser Absender werden blockiert. Dieses Verfahren wird unter anderem bei Kommunikation eingesetzt und kann auch in VoIP-Netzwerken genutzt werden. Es bietet jedoch alleine keinen vollständigen Schutz, da Identitätswechsel und -fälschung sowohl bei der -Kommunikation als auch in SIP-basierten Netzwerken möglich sind. Whitelisting Die White-List kann aus einer teilnehmerspezifischen Liste von Absendern bestehen, von denen der Teilnehmer Nachrichten entgegen nimmt oder Kommunikationsverbindungen zulässt. Im VIAT-Prototyp (Abschnitt ) ist hingegen eine zentrale White-List implementiert. Darin können optional Absenderadressen hinterlegt werden, die nicht blockiert werden dürfen. White-Lists sind nicht anfällig für Identitätswechsel, jedoch für Identitätsfälschung. 4

17 2.1. SPIT-Erkennung und -Abwehr Ein Netzwerk, das teilnehmerspezifische White-Lists einsetzt, benötigt eine Lösung für das erstmalige Kontaktieren eines Teilnehmers (Introduction-Problem). Im Bereich Instant Messaging werden White-Lists erfolgreich eingesetzt. Hier handelt es sich meistens um abgeschlossene administrative Domänen mit authentifizierten Identitäten und es werden keine Nachrichten aus anderen Domänen zugelassen. Greylisting Als Erweiterung von Black-Lists und White-Lists können Grey-Lists verwendet werden, wenn die Vertrauenswürdigkeit eines Absenders nicht binär definierbar ist beziehungsweise definiert werden soll. Im Bereich der -Kommunikation stellt Greylisting eine verbreitete Methode zur Spam-Reduktion ([Har03]) dar. Es ist keine Erweiterung des Simple Mail Transfer Protocol (SMTP) ([Kle01; Kle08]), sondern ein darauf beruhendes Verfahren. Mail-Beziehungen werden durch ein Tupel bestehend aus der IP-Adresse des sendenden Mailservers, der -Adresse des Absenders sowie der -Adresse des Adressaten beschrieben (auch Triplet genannt). Ein Mail Transfer Agent (MTA), lehnt bei erstmaligem Auftreten eines Triplets und für eine gewisse Zeitspanne danach alle Zustellversuch mit einer temporären Fehlermeldung ab. Nach Ablauf dieser Zeitspanne ist ein erneuter Zustellversuch erfolgreich. Das Verfahren vertraut darauf, dass Programme zum Spam-Versand einen reduzierten Funktionsumfang besitzen und keine erneuten Zustellversuche unternehmen (Fire-and-Forget). Weiterhin kann zusätzlich eine White-List geführt werden, in der bereits bekannte Triplets dynamisch hinterlegt werden. Durch das Verfahren der verzögerten Zustellung ist es außerdem möglich eine Spam-Welle zu erkennen und die Absender mittels Black-List zu blockieren, bevor die Zustellung der Mails erfolgreich war. Im Bereich VoIP schlagen die Autoren von [Shi06] ein Verfahren namens Progressive Multi Gray-Leveling (PMG) zur Bestimmung eines Short-term Gray Level sowie eines Long-term Gray Level vor, das auf einer statistischen Auswertung von Anrufmustern mit Hilfe von Signalisierungsdaten beruht. Ein Verbindungsaufbau wird blockiert, sobald die Addition dieser beiden Werte einen vorher festgelegten Schwellwert überschreitet Consent-Based Communications Es werden White-Lists oder Black-Lists verwendet. Ein erstmalig anfragender Teilnehmer wird initial abgelehnt. Der angefragte Teilnehmer wird darüber informiert und kann seine Zustimmung oder Ablehnung für zukünftige Anfragen des gleichen Teilnehmers erteilen. Dabei handelt es sich um ein gängiges Verfahren in Instant-Messaging und Presence-Netzen. 5

18 Kapitel 2. Grundlagen Inhaltsfilterung Beim Schutz gegen -Spam wird häufig die Filterung auf Basis einer inhaltsbasierten Analyse vorgenommen (beispielsweise Bayesscher Filter und Markov Filter), was durch den asynchronen Charakter der -Kommunikation möglich ist. Das synchrone Medium Telefonie lässt diese Art der Filterung ohne Weiteres nicht zu. Ein Vorschlag zur inhaltsbasierten Filterung in SIP-basierten Netzen wird in [Reb10] vorgestellt. Anstatt die Verbindung zum ursprünglich angewählten Adressaten aufzubauen, wird ein Interactive Voice Response (IVR) System vorgeschaltet, das dem Anrufer die Bearbeitung des Verbindungsaufbaus bestätigt. Bei einem automatisiert ausgeführten Anruf kann der Automat dies als Grußformel auffassen und die Übertragung der Audiodaten starten. Diese werden zur Berechnung einer Signatur aufgezeichnet, die danach zum Auffinden gleicher Audiodaten mit allen vorher erzeugten Signaturen verglichen wird. Wenn die Signatur bereits vorhanden ist, wird der Anruf als SPIT deklariert und nicht zum Adressaten weitergeleitet. Dieses Verfahren ist Teil des SPIDER-Projekts, auf das in Abschnitt näher eingegangen wird. Das Projekt VIAT stellt in [Len11] ein Verfahren vor, bei dem die ersten Sekunden der Audiodaten des Anrufers einer inhaltsbasierten Analyse, vergleichbar zu [Reb10], unterzogen werden. Handelt es sich um SPIT, können zukünftige Verbindungsversuche des Absenders blockiert werden. In Abschnitt wird näher auf das Projekt VIAT eingegangen Reputationssysteme Jedem Teilnehmer des Kommunikationsnetzes wird ein Reputationswert zugeordnet, der seine Vertrauenswürdigkeit beschreibt. Der Reputationswert wird dynamisch berechnet. Andere Teilnehmer können Verbindungsversuche von nicht vertrauenswürdigen Teilnehmern automatisiert blockieren. Es werden verschiedene Berechnungsgrundlagen vorgeschlagen, beispielsweise die Einbeziehung von Feedback anderer Teilnehmer ([Reb06; Reb08]) oder das soziale Netzwerk des Teilnehmers ([Aza12; Pat08]) Turing-Tests, CAPTCHAs Zur Abwehr von Spam werden häufig Turing-Tests verwendet. Diese Turing-Tests, in diesem Zusammenhang auch CAPTCHA 1 oder HIP 2 genannt, sind dazu da, um zwischen Mensch und Maschine zu unterscheiden. Es handelt sich um Aufgaben, die in der 1 CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart 2 HIP: Human Interaction Proof 6

19 2.1. SPIT-Erkennung und -Abwehr Form von Bild-, Ton- oder Videomaterial gestellt werden und im besten Fall vom Menschen einfach und maschinell gar nicht oder zumindest nur mit sehr hohem Aufwand zu lösen sind. CAPTCHAs werden unter anderem dazu eingesetzt die automatisierte Kontenerstellung bei -Diensten zu erschweren, die sonst zum Spam-Versand genutzt werden. In [Ahm10] wird vorgeschlagen Bild-CAPTCHAs in SIP-basierten Netzwerken zu nutzen. Entscheidende Fragen, insbesondere über welchen Kanal die Antwort des CAPTCHAs gesendet wird, bleiben jedoch ungeklärt. Dieser Vorschlag setzt Änderungen an allen SIP-Endgeräten voraus. Die Autoren von [Qui07] stellen zur Abwehr von Telefon-Spam einen versteckten Turing- Test vor. Es wird ein Konservationsmodell ([Ham04]) genutzt, um Abweichungen vom üblichen Konversationsverhalten in Telefongesprächen zu erkennen Integrative Ansätze Die Erfahrungen mit -Spam haben gezeigt, dass ein einzelnes Verfahren zur Abwehr von Spam nicht ausreicht. Im Folgenden werden einige integrative Ansätze vorgestellt VoIP Secure Application Layer Firewall (VoIP SEAL) Das von NEC Laboratories Europe vorgeschlagene mehrstufige System VoIP SEAL wurde zum Schutz vor verschiedenen Arten von Angriffen in VoIP-Netzen konzipiert. [See08; Qui08] In Stage 1 werden signalisierungsbasierte Auswertungen ohne Teilnehmerinteraktion durchgeführt: statistische Analysen, Abgleich mit Black-Lists und White-Lists, Mustererkennung sowie Erkennung deformierter Nachrichten. Stage 2 besteht aus einem zweistufigen Turing-Test, durch den analysiert wird, ob es sich beim Anrufer um einen Menschen oder einen Automaten handelt. Dieser Test wird in [Qui07] genauer erläutert. Bevor in Stage 3 der Anruf an den Angerufenen weitergeleitet wird, kann dieser in einem Verfahren vergleichbar mit Consent-Based Communications den Verbindungsaufbau bestätigen oder ablehnen. Während der laufenden Verbindung in Stage 4 können Angerufene Feedback über Wählziffern geben, was der Kalibrierung des Gesamtsystems dient. Nach Beendigung der Verbindung in Stage 5 ist es nochmals möglich den Anruf als unerwünscht zu deklarieren. 7

20 Kapitel 2. Grundlagen Spam over Internet Telephony Detection Service (SPIDER) Es handelt sich um ein durch die Europäische Union gefördertes Projekt mit dem Ziel ein Framework für sichere VoIP-Telefonie zu entwickeln und aufzubauen [Spi07]. Die Architektur ist in zwei Ebenen unterteilt. Der Detection Layer kann mit einem Modul oder mehreren Modulen zur Erkennung von SPIT bestückt werden. Der Decision Layer kombiniert und klassifiziert die Ergebnisse des Detection Layers. [Reb07] Im Abschlussbericht [Sou08] sind die folgenden sechs Module des Detection Layers beschrieben: Authentication: Überprüfung der nach RFC 4474 ([Pet06]) authentifizierten Anruferidentitäten. Proxy Check: Prüft, ob der Verbindungsaufbau über einen vertrauenswürdigen Proxy initiiert wird. Challenge/Response: Prüft mittels Audio CAPTCHA, ob es sich beim Anrufer um einen Automaten oder einen Menschen handelt. Audio Analysis: Überprüfung auf Gleichheit der Audiodaten durch einen der eigentlichen Telefonverbindung vorgeschalteten Test. Reputation: Prüft die Vertrauenswürdigkeit des Anrufers. White/Black-List Multistage SPIT Detection in Transit VoIP In [Aza11] stellen die Autoren ein System zur SPIT-Erkennung in Transitnetzen vor. Das System besteht aus drei Modulen: Black-List, Statistik und Vertrauen. Das Statistikmodul basiert auf einer Signalisierungsanalyse. Das Vertrauensmodul kommt ohne manuelles Feedback aus. Das Vertrauensverhältnis zwischen Anrufer und Angerufenen wird abgeleitet von der Verbindungsdauer, der Verbindungsrate, einer Analyse fehlgeschlagener Verbindungen sowie dem Vertrauensverhältnis zu gemeinsamen Bekannten. Weiterhin werden Vorschläge zur Integration der einzelnen Module im Netz des VoIP- Operators gemacht. 8

21 2.1. SPIT-Erkennung und -Abwehr You can SPIT, but you can t hide Die Autoren von [Bok11] haben anonymisierte Daten einer großen nordamerikanischen Telefongesellschaft ausgewertet und schlagen drei Algorithmen zur SPIT-Erkennung vor. Loose Tie Detection (LTD) Es werden die Bezeichnungen Strong Ties (starke Bindungen) und Weak Ties (schwache Bindungen) als Maß der Bindungsstärke eingeführt. Die Stärke einer Bindung wird über die kumulierte Gesprächszeit definiert. Die Auswertung der Daten hat gezeigt, dass in den meisten Fällen die summierten Verbindungszeiten zu einer geringen Anzahl N von Gesprächspartnern eines Teilnehmers den Großteil seiner gesamten Kommunikationszeit ausmachen. Diese Eigenschaft wird als Strong Ties bezeichnet. Weiterhin wird das Interesse eines Angerufenen über die kumulierte Verbindungszeit definiert. Ein Teilnehmer hat die Eigenschaft Weak Ties, wenn der Anteil an Angerufenen mit geringem Interesse hoch ist. Ausreißer beider Berechnungen werden als verdächtig eingestuft. Enhanced Progressive Multi Gray-Leveling (EPMG) Es wird davon ausgegangen, dass es sich bei reziproken Verbindungen nicht um unerwünschte Verbindungen handelt. Das Verfahren PMG wird erweitert, in dem reziproke Verbindungen bei der Berechnung der Gray Level nicht berücksichtigt werden. SymRank Dieser Algorithmus basiert auf PageRank ([Pag99]). Mittels PageRank wird das Ranking eines Knotens (hier: Teilnehmers) unter Berücksichtigung der eingehenden Verbindungen berechnet. SymRank erweitert dieses Verfahren, indem ein- und ausgehende Telefonverbindungen berücksichtigt werden. Das ermittelte Ranking wird als Reputationsmaß verwendet. Die Evaluation zeigt, dass es sich bei LTD um das praktikabelste der drei Verfahren handelt. Das System ist relativ einfach umzusetzen und erreicht eine hohe Genauigkeit bei der Identifizierung von SPIT-Versendern Entwicklung und Integration von signalisierungsbasierten Verfahren zum Schutz vor Telefon-SPAM Im Rahmen einer Master-Thesis an der Fachhochschule Köln ([Mar11]) wurde ein aus mehreren statistischen Analysen bestehendes System zur Identifikation von auffälligem Signalisierungsverhalten entwickelt und umgesetzt. Das System analysiert die Häufig- 9

22 Kapitel 2. Grundlagen keit von INVITE und OPTIONS Anfragen mittels Progressive Multi Gray-Leveling sowie die Varianz der Klingel- und Anrufdauer. Anhand eines Hypothesentests mit der Binomialverteilung werden die Ereignisse aktives/passives Auflegen und etablierte/fehlgeschlagene Anrufversuche untersucht. Außerdem wird die maximale Anzahl paralleler Verbindungen ermittelt. Die Analyseergebnisse werden zu einem Vektor zusammengefasst. Auf Basis dieses Vektors können auffällige Teilnehmer identifiziert werden PALLADION Das von Oracle/Acme Packet vertriebene Produkt PALLADION dient der Analyse von VoIP-Netzwerken. Es enthält eine Missbrauchserkennung auf Basis einer Verhaltensanalyse. Die Verhaltensanalyse basiert unter anderem auf der Anzahl paralleler Verbindungen, zeitabhängigen Verkehrsmustern und vom normalen Verhalten abweichenden Absender- und Zieladressen. Die gesammelten Informationen werden mit unterschiedlicher Gewichtung zu einem teilnehmerspezifischen Wert zusammengefasst. Bei Überschreitung eines statischen oder vom bisherigen Benutzerverhalten dynamisch abgeleiteten Grenzwertes wird ein Alarm ausgelöst. Zudem ist die automatisierte Aktualisierung einer Black-List möglich. Das System arbeitet passiv, das heißt es verarbeitet eine Kopie des Netzwerkstroms. [Acm13] Verfahren zur Identifikation und Abwehr von Telefon-Spam (VIAT) Im Projekt VIAT wurde ein modulares System zur Abwehr von SPIT entwickelt. Es zeichnet sich durch eine effiziente inhaltsbasierte Analyse zur Erkennung mehrfach eingespielten Audiomaterials (Robocalls) aus. Dabei handelt es sich nicht um die Filterung von SPIT, sondern um die Klassifizierung von den Audiodaten der Absender. Zukünftige Verbindungsaufbauversuche von als SPIT-Versender deklarierten Absendern können effektiv blockiert werden. Das System ist für den Einsatz im Netzwerk eines VoIP- Providers vorgesehen und kommt ohne Benutzer-Feedback aus. Die Audioanalyse basiert auf der Generierung eines Fingerprints der Audiodaten des Anrufers. Zur Erstellung des Fingerprints werden die ersten Sekunden dieser Audiodaten in einzelne, sich stark überlappende Fenster unterteilt. Die einzelnen Audioabschnitte werden in den Frequenzbereich transformiert und je nach Version des Fingerprints durch verschiedene Verfahren zu einer Folge von Subhashes verarbeitet. Die aktuelle Version des Fingerprints ist in [Gru12] detailliert beschrieben. In [Len11] wird das System zur Abwehr von SPIT und dessen Umsetzung als Prototyp I erläutert. Jeder neue Fingerprint wird mit allen vorherigen verglichen. Bei ausreichender Ähnlichkeit zweier Fingerprints kann von gleichen Audiodaten ausgegangen und der Ab- 10

23 2.1. SPIT-Erkennung und -Abwehr Asterisk A Call Generation Kamailio SIP Proxy with viat_blacklist Module Call Flow Asterisk B Call Termination Compare Caller & Callee Addresses Audio Files Caller Address Match List Analyzer Match List Values Black List Values Database Match List, Black List, White List, Callee White List Match List Values Audio Analyzer Fingerprint Calculation & Comparison Abbildung 2.1.: Erweiterter VIAT-Prototyp II sender als SPIT-Versender deklariert werden. Der Vergleich des aktuellen Fingerprints mit einer großer Anzahl vorhandener erfordert ein effizientes Suchverfahren. Die Suche mittels invertiertem Index und die Umsetzung des Systems als Prototyp II werden in [Str12] beschrieben. Der Fingerprint wurde für dieses Suchverfahren optimiert. Die durchgeführten Tests des Prototyp II bescheinigen eine signifikante Leistungssteigerung der Suche. Weitere Optimierungen des Fingerprints sowie der Suche werden in [Gru12] erläutert. Es wurden verschiedene Varianten des Fingerprints in Bezug auf Trefferquote, Falsch-Positive und Suchgeschwindigkeit untersucht. Die Varianten unterscheiden sich in der Bit-Länge der Subhashes, die zwischen 20 und 64 Bits liegt. Mit Ausnahme der 20-Bit-Variante liegt die Suchzeit für einen Fingerprint in einer Datenbank mit einer Million enthaltenen Elemente bei unter einer Millisekunde. Dabei bietet die 32-Bit-Variante bei einer Falsch-Positiv-Rate von 0.05 Prozent eine akzeptable Trefferquote von über 94 Prozent. In Abbildung 2.1 ist ein erweiterter Prototyp II dargestellt. Beim Vergleich mit den Abbildungen 1 und 2 in [Str12] wird ersichtlich, dass die Fingerprints nach deren Berechnung nicht mehr in der Datenbank zwischengespeichert werden. Der Fingerprint wird zum Erweitern des invertierten Index verwendet und im Anschluss daran verworfen. Die beiden Server Asterisk A und B dienen der Erzeugung eines Call Flows. Dabei dient Asterisk A der Generierung von Anrufen und Asterisk B der Terminierung. Asterisk B leitet die Audiodaten aller Anrufe an das Modul Audio Analyzer weiter. Im Audio Analyzer wird der zuvor beschriebene Fingerprint berechnet und mit allen bereits vorhandenen Fingerprints verglichen. Das Ergebnis wird in der Match List (Database) gespeichert. Das Modul Match List Analyzer wertet die Match List kontinuierlich aus und aktualisiert die Black List. Der SIP-Proxy Kamailio prüft bei jeder Verbindungsanfrage die drei in der Datenbank enthaltenen Listen Callee White List, White List und Black List. Diese Listen haben folgende Auswirkungen: Black List In dieser Liste enthaltene Absenderadressen werden beim Versuch eine Verbindung 11

24 Kapitel 2. Grundlagen aufzubauen blockiert. Es sei denn, die Absenderadresse ist in der White List oder die Zieladresse in der Callee White List enthalten. Ausnahmen sind in der White List enthalte Absenderadressen und Zieladressen, die in der Callee White List enthalten sind. White List Diese Liste enthält Absenderadressen, die nicht blockiert werden sollen. Callee White List Verbindungsaufbauten zu in dieser Liste enthaltenen Adressaten werden von weiteren Überprüfungen ausgenommen. Die Verbindung wird aufgebaut, selbst wenn die Adresse des Absenders in der Black List enthalten ist. Der erweiterte Prototyp II wird in im Rahmen dieser Arbeit um eine passive Extraktion der Signalisierungs- und Audiodaten sowie um eine signalisierungsbasierte Analyse zur Vorauswahl von verdächtigen Absendern erweitert Connecting VIAT and PALLADION Im Projekt Connecting VIAT and PALLADION, eine Projektarbeit im Rahmen des Masterstudiums des Autors, wurden PALLADION (Version 2.16) und VIAT (Prototyp II) kombiniert. Dabei dient PALLADION zur Vorauswahl auffälliger Teilnehmer sowie zur Extraktion der Audiodaten dieser Teilnehmer. Die Audiodaten werden vom VIAT System der inhaltsbasierten Analyse unterzogen. PALLADION Signaling-based Analysis Call Recording RTP Record List, BA Incident List PallConnUI PALLADION Connection User Interface Controlling PALLADION's Call Recording BA Incidents, Recorded Calls Call Infos, Similarity Scores PallConnD PALLADION Connector Daemon Recorded Calls VIAT Content-based Analysis Abbildung 2.2.: Komponenten und Informationsfluss der Kombination von VIAT und PALLADION In Abbildung 2.2 sind die Komponenten und der zwischen ihnen stattfindende Informationsfluss dargestellt. Im Rahmen des Projekts wurden die Komponenten CallConnD und PallConnUI entwickelt. Die Komponente PallConnD liest die Ergebnisse der PALLA- DION-Verhaltensanalyse aus und legt mit Hilfe dieser Informationen fest, von welchen 12

25 2.2. Extraktion von Daten aus SIP-basierten VoIP-Netzwerken Teilnehmern die Audiodaten (PCAP-Format) zukünftiger Telefonverbindungen gespeichert werden sollen. Sobald PCAP-Dateien vorhanden sind, werden diese zur inhaltsbasierten Analyse an das VIAT-System weitergeleitet. Der VIAT-Prototyp II verarbeitet Audiodaten im WAVE-Format, ist jedoch nicht in der Lage Audiodaten im PCAP- Format entgegen zu nehmen. Daher wurde die Anwendung callx [Mai10] um eine Dateischnittstelle erweitert und in den Prototyp II integriert. Bei der Komponente PallConnUI handelt es sich um ein Webinterface zur Gegenüberstellung der Ergebnisse der signalisierungsbasierten Analyse von PALLADION mit den Ergebnissen der inhaltsbasierten Analyse von VIAT. Ein Screenshot des Webinterfaces sowie ein weiteres Diagramm der Komponenten, das die verwendeten Protokolle zeigt, befinden sich im Anhang (Abbildungen A.3 und A.4) Extraktion von Daten aus SIP-basierten VoIP-Netzwerken Die Extraktion von Signalisierungs- und Mediendaten aus VoIP-Netzwerken wird in verschiedenen Bereichen eingesetzt. In [Mai10, Kapitel 3] werden die Anforderungen an ein System zur Datenextraktion in den Bereichen Lawful Interception und Callcenter Monitoring sowie für das Projekt VIAT näher betrachtet. Ein weiterer Bereich ist Quality of Service Monitoring. Es wird zwischen aktiver Extraktion und passiver Extraktion unterschieden. [Mai10, Kapitel 3] Aktive Extraktion Sofern entsprechende Module oder Schnittstellen zur Verfügung stehen, kann die Datenextraktion an Netzelementen, die ohnehin die benötigten Daten verarbeiten, durchgeführt werden. Genannt seien die beiden Elemente SIP Proxy, der Signalisierungsdaten verarbeitet und SIP (Back-to-Back) User Agent, der Signalisierungs- und Mediendaten verarbeitet. 3 Beispielsweise basiert das in Absatz beschriebene System auf aktiver Extraktion durch ein eigens dafür entwickeltes Kamailio-Modul. Im erweiterten VIAT-Prototyp II (Abbildung 2.1) wird ebenfalls aktive Extraktion verwendet. Die Signalisierungs- und Mediendaten werden über den als User Agent konfigurierten Asterisk B extrahiert. 3 Genau genommen sind Proxy und User Agent keine Netzelemente, sondern es sind in RFC 3261 definierte Rollen, die ein Netzelement einnehmen kann. Ein Netzelement kann - sofern implementiert und je nach Konfiguration - verschiedene Rollen einnehmen. 13

26 Kapitel 2. Grundlagen Passive Extraktion Eine andere Möglichkeit ist die Extraktion durch Auswertung einer Kopie der Netzwerkdaten. Diese können über einen Monitoring Port eines Switches ([Cis07]) bereitgestellt werden. Die passive Extraktion bietet den Vorteil, dass keine direkte negative Beeinflussung eines signalisierungs- oder medienverarbeitenden Elements (Überlast, Fehlerfall) befürchtet werden muss. Insbesondere die nachträgliche Integration in ein vorhandenes VoIP-Netzwerk ist damit ohne größeren Aufwand möglich. Nachteilig ist aber, dass die eigentliche Extraktion ein speziell dazu entwickeltes System benötigt. [Mai10, Kapitel 3] geht im Detail auf die Herausforderungen der passiven Extraktion ein. In [Mai10, Kapitel 4] wird die Umsetzung der passiven Extraktion anhand einer in der Programmiersprache C++ entwickelten Applikation beschrieben Passiver SIP-Stack Ein wesentlicher Bestandteil der in [Mai10] entwickelten Software ist der passive SIP- Stack. Dieser verarbeitet SIP-Nachrichten nach der Spezifikation RFC 3261 ([Ros02]) und kann daher den Zustand der Transaktionsautomaten der beteiligten Systeme feststellen. Durch die vollständige Interpretation von Transaktionen ist ebenso der Zustand eines eventuell zwischen den Systemen aufgebauten Dialogs bekannt. Weiterhin erkennt der SIP-Stack die Konfiguration einer Mediensitzung. Dazu wird zusätzlich zum SIP- Header der SIP-Body verarbeitet. Eine Mediensitzung wird im SIP-Body durch das Session Description Protocol (SDP) ([Han06]) beschrieben. Damit werden unter anderem die Medien-Endpunktadressen bekannt gegeben, die zur Zuordnung von RTP Paketströmen zum SIP-Dialog benötigt werden. Die IP-Adressen von Signalisierungs- und Mediendaten stimmen in den meisten Fällen nicht überein. [Mai10, Kapitel 3] Verwandte Arbeiten und Produkte zur passiven Extraktion Dem Autor sind keine relevanten zu [Mai10] verwandten Arbeiten bekannt. Jedoch werden einige kommerzielle Produkte angeboten. Zwei Unternehmen, die sich auf die passive Extraktion spezialisiert haben, sind SIPfish 4 mit dem gleichnamigen Produkt und Call- Copy 5 mit dem Produkt Call Recording. 4 [Stand ] 5 [Stand ] 14

27 Kapitel 3. Praxisteil In diesem Kapitel wird zu Anfang die Aufgabenstellung definiert. Es folgt ein Überblick zur Umsetzung der entwickelten Anwendung callx ii. Die danach folgenden programmiertechnischen Grundlagen beschreiben Besonderheiten des Software-Designs. Dazu zählen unter anderem die mit dem C++11-Standard eingeführten Funktionalitäten Smart-Pointer und Move-Semantik, die den Entwickler bei der Erstellung robuster und leistungsstarker Software unterstützen. Dieses Kapitel wird durch eine umfassende Dokumentation der Softwarearchitektur und -implementierung abgeschlossen. Die Dokumentation basiert auf den UML- und Datenflussdiagrammen aus der Designphase der Anwendungsentwicklung. Der ausführlich dokumentierte Quelltext befindet sich auf der beiliegenden DVD Aufgabenstellung Die Aufgabenstellung dieser Arbeit ist zweigeteilt. Zum einen ist ein System zur effizienten, passiven Extraktion von Signalisierungs- und Mediendaten aus SIP-basierten VoIP-Netzwerken zu entwickeln. Das Systemdesign ist so zu entwerfen, dass eine hohe Anzahl von parallelen Telefonverbindungen verarbeitet werden kann. Die extrahierten Audiodaten sind über einen Netzwerk-Socket der Analyse durch VIAT zu übergeben. Zum anderen ist eine Filterung basierend auf einer signalisierungsbasierten Analyse umzusetzen, so dass nur die Audiodaten von auffälligen Teilnehmern an die inhaltsbasierte Analyse durch das VIAT-System weitergeleitet werden. 15

28 Kapitel 3. Praxisteil 3.2. Umsetzung In diesem Abschnitt wird allgemein auf die Umsetzung der im vorherigen Abschnitt besprochenen Aufgabenstellung eingegangen. Eine detaillierte Beschreibung der Softwarearchitektur befindet sich in Abschnitt 3.4. Die Implementierung der Datenextraktion baut auf der Diplomarbeit des Autors auf ([Mai10]). Dort wurden bereits die Herausforderungen an ein System zur passiven Datenextraktion aus VoIP-Netzwerken diskutiert. Allerdings lässt sich die in der Diplomarbeit entwickelte Anwendung callx aufgrund des single-threaded Designs nicht in High- Traffic Umgebungen einsetzen. Die in der vorliegenden Arbeit unter Verwendung der Programmiersprache C++ entwickelte Anwendung callx ii parallelisiert die Extraktion von Signalisierungs- und Audiodaten mit insgesamt neun Threads. Es wird ein passiver SIP-Stack implementiert, der im Vergleich zu callx eine umfassendere Unterstützung des SIP-Standards RFC 3261 ([Ros02]) umsetzt. Weiterhin liefert dieser die Daten für die signalisierungsbasierte Analyse. Darüber hinaus besitzt callx ii eine höhere Toleranz gegenüber Paketverlust Erforderliche Funktionalität Die folgenden Funktionen werden in der Anwendung callx ii realisiert: Übernahme einer Kopie des Netzwerkstroms Der Netzwerkstrom wird unter Umgehung des im Betriebssystem vorhandenen TCP/IP-Stacks mit Hilfe der Bibliothek LIBPCAP ([tcpdmp]) von einer Ethernet Schnittstelle übernommen. Detaillierte Paketfilterregeln sind über die Konfiguration einstellbar. Parsen und Verteilen der Netzwerkpakete Die unter Nutzung der PCAP-Schnittstelle erhaltenen Ethernet-Daten werden bis zur Transportschicht (UDP) geparst und zur weiteren Verarbeitung an die entsprechenden Module verteilt. Verarbeitung der Signalisierung SIP-Pakete werden geparst und von vom SIP-Prozessor, bestehend aus einem passiven SIP-Stack, verarbeitet. Dabei werden die Dialoge und Transaktionen gemäß dem Standard RFC 3261 ([Ros02]) der an einer Telefonverbindung beteiligten Endgeräte erkannt. Die Medienendpunkte werden zur Zuordnung der RTP- Paketströme registriert. Analyse der Signalisierung 16

29 3.2. Umsetzung Die Signalisierungsbasierte Analyse dient der Klassifikation von Anrufern. Die gesamte Analyse besteht aus mehreren Einzelanalysen. Ein Anrufer gilt als auffällig, wenn Analyseergebnisse vorher definierte Schwellwerte überschreiten. Abschnitt geht näher auf die Signalisierungsanalysen ein. Vorfilterung der zu extrahierenden Audiodaten Basierend auf der Analyse der Signalisierung werden lediglich die Audiodaten der Verbindungen von auffällig gewordenen Anrufern weiterverarbeitet. Dekodieren der Audiodaten Nach der Beendigung eines Anrufs wird der Payload aller vorhandenen RTP- Paketströme dekodiert und im PCM-Format dem Ausgabemodul übergeben. Ausgabe der Audiodaten Es wurden zwei Möglichkeiten zur Ausgabe im PCM-Format vorliegenden Daten realisiert: Export als RIFF-WAVE-Datei. Übergabe an TCP-Socket: Es werden Informationen zum Anruf in der VIAT-Datenbank hinterlegt. Die ID dieses Datenbankeintrags wird zusammen mit den PCM-Daten an einen TCP-Socket gesendet. Im VIAT-Prototyp stellt der Feature-Extractor diesen Socket zur Verfügung. Der Feature-Extractor erzeugt aus diesen Audiodaten einen Fingerprint. Watchdog Es wurde ein Watchdog entwickelt der, parallel zur laufenden Verarbeitung des Netzwerkstroms, gebundene Ressourcen überprüft und eventuell freigibt. Er ist für die Einhaltung der konfigurierbaren maximalen Aufnahmedauer zuständig. Konsole Mittels Terminal-Client ist es möglich eine Verbindung zu callx ii herzustellen. Dazu stellt die Anwendung einen TCP-Socket an einer konfigurierbaren Portnummer bereit. Durch Eingabe von Kommandos lassen sich aktuelle Informationen wie Füllstatus von Queues und Ergebnisse der signalisierungsbasierten Analyse anzeigen. Log-Datei Es wird eine Log-Datei mit hohem Detailgrad erstellt. 17

30 Kapitel 3. Praxisteil Analyse der Signalisierung Die Signalisierungsanalyse besteht aus mehreren Einzelanalysen. Diese verarbeiten Events, die vom SIP-Stack erzeugt und nach Benutzern gruppiert werden. Für jeden Benutzer werden alle Einzelanalysen durchgeführt. In der Konfigurationsdatei wird für jede Einzelanalyse die Länge des Analysezeitfensters definiert. Call Attempts Es werden alle Versuche eine Verbindung aufzubauen gezählt. Call Completion Alle erfolgreichen und nicht erfolgreichen Versuche eine Verbindung aufzubauen werden gezählt. Das Ergebnis ist das Verhältnis erfolgreicher zu nicht erfolgreichen Verbindungen in Prozent. Call Duration Average Die Zeitdauer aller Verbindungen wird addiert und durch die Anzahl der erfolgreichen Verbindungen dividiert. Call Duration Cumulative Hierbei handelt es sich um die kumulierte Zeitdauer aller Verbindungen. Calls Closed by Callee Alle Verbindungsbeendigungen durch den Anrufer werden summiert und durch die Anzahl der erfolgreichen Verbindungen dividiert. Das Ergebnis wird in Prozent angegeben. Calls Concurrent Die maximale Anzahl gleichzeitiger Verbindungen. In der Konfiguration des Systems lassen sich Schwellwerte definieren. Bei Überschreitung wird für den aktuellen Benutzer ein Incident generiert, der weitere Informationen zum Vorfall enthält. Gleichzeitig wird dieser Teilnehmer als möglicher SPIT-Versender deklariert. Die Audiodaten zukünftiger Verbindungen dieses Anrufers werden an das VIAT-System zur Analyse weitergeleitet. Von allen anderen Verbindungen werden keine Audiodaten aufgezeichnet. Durch diese Vorfilterung hat das VIAT-System ein geringeres und im Kontext des Verfahrens höherwertiges Anrufvolumen zu verarbeiten. Höherwertig bedeutet hier, dass die Wahrscheinlichkeit, dass es sich bei den zu analysierenden Audiodaten um SPIT handelt, höher ist, als ohne Vorfilterung. Dabei ist die Wahl der Schwellwerte entscheidend für die Leistung des Gesamtsystems: Sind die Werte zu niedrig, werden zu viele Anrufer als mögliche SPIT-Versender eingestuft, so dass das System zur Audioanalyse sehr viele Audiodaten zu verarbeiten hat. Sind die Werte zu hoch, ist die Wahrscheinlichkeit groß, dass SPIT-versendende Teilneh- 18

31 3.2. Umsetzung mer nicht als solche erkannt werden (Falsch-Negative). Die Audiodaten dieser Teilnehmer werden nicht an die inhaltsbasierte Analyse weitergeleitet und daher kann die Gleichheit der Audiodaten nicht erkannt werden. 19

32 Kapitel 3. Praxisteil 3.3. Programmiertechnische Grundlagen Es wurde modulares Programmdesign erarbeitet. Der gesamte Verarbeitungsprozess wurde in mehrere parallele Threads aufgeteilt. Die gemeinsam genutzten Ressourcen wurden so entworfen und eingebunden, dass sich die Threads gegenseitig möglichst wenig blockieren. Die Anwendung wurde in der Programmiersprache C++ entwickelt. Dabei wurde durchgängig die Programmiertechnik RAII (Ressource Acquisition is Initialisation) eingehalten, mit der die Belegung und Freigabe von Ressourcen an den Gültigkeitsbereich von lokalen Variablen geknüpft ist Smart Pointer Ressourcen, deren Gültigkeitsbereich sich über mehrere Objekte erstreckt, müssen außerhalb des erzeugenden Objekts auf dem Heap abgelegt werden. So bleibt diese Ressource bei Zerstörung des erzeugenden Objekts erhalten. Dies erfordert jedoch eine sehr genaue Planung der Verantwortlichkeit für die Freigabe der Ressource. Zudem ist bei Exception-Behandlungen darauf zu achten, dass eventuell Ressourcen freizugeben sind, was mitunter komplex und fehleranfällig ist. Der Einsatz von Smart-Pointern zur Verwaltung der Ressource ist an dieser Stelle hilfreich. Ein Smart-Pointer wird als lokales Objekt erzeugt, dessen Destruktor für die Freigabe der verwalteten Ressource zuständig ist. Im C++11-Standard wurden drei Smart-Pointer definiert, die den bisherigen Smart-Pointer std::auto_ptr des Standards C++98 ersetzen ([Wil12]): std::unique_ptr Ein Zeiger auf eine Ressource existiert - richtige Anwendung vorausgesetzt - nur in einem einzigen Unique-Pointer. Bei Verwendung als Übergabeparameter oder Rückgabewert wird auf die ebenfalls in C++11 eingeführte Move-Semantik zurückgegriffen. Dabei wird die Zuständigkeit auf den neuen Unique-Pointer übertragen und der bisherige ungültig. std::shared_ptr Es können mehrere Shared-Pointer auf die selbe Ressource verweisen. Dabei wird ein Referenz-Zähler eingesetzt. Der Destruktor der verwalteten Ressource wird aufgerufen, sobald kein Verweis mehr auf die Ressource vorhanden ist. std::weak_ptr Wird ein Zeiger auf die Ressource eines Shared-Pointers benötigt, aber die Zerstörung der Ressource soll nicht an den Gültigkeitsbereich dieses Zeigers gebunden sein, kann ein Weak-Pointer verwendet werden. Dieser erhöht den Referenzzähler für diese Ressource nicht. Vor der Verwendung der Ressource sollte mit der Methode std::weak_ptr::lock() temporär ein Shared-Pointer generiert werden. Damit 20

33 3.3. Programmiertechnische Grundlagen wird der Referenzzähler erhöht und die Ressource kann während der Verwendung nicht zerstört werden. Mit Hilfe von Weak-Pointern werden zirkuläre Abhängigkeiten zweier Objekte unterbunden. Zwei Shared-Pointer, deren Ressourcen sich gegenseitig als Member besitzen, würden niemals gelöscht werden, da die Referenzzähler beider Shared- Pointer immer größer gleich 1 sind Scoped Locking Die in callx ii von mehreren Threads gleichzeitig genutzten Ressourcen besitzen einen Mutex, der für die exklusive Nutzung der Ressource blockiert wird. Es wurde ausschließlich das Software Muster Scoped-Locking verwendet. Dieses verwendet ein lokales Objekt zur Verwaltung des Mutex. Bei Erzeugung dieses Objekts wird der Mutex gesperrt. Beim Verlassen des Gültigkeitsbereichs wird im Destruktor des lokalen Objekts der Mutex freigegeben. Dies geschieht unabhängig von der Bedingung, die zum Verlassen des Gültigkeitsbereichs führt, beispielsweise eine return-anweisung oder das Auftreten einer Exception Move Semantik und Rvalue Referenzen Die Move-Semantik bezeichnet ein Konzept zur Vermeidung von unnötigen Objekt- Kopien. Seit C++11 wird dieses Konzept mit der Einführung von Rvalue-Referenzen (eine Spracherweiterung) und der umfangreichen Anpassung der C++ Standard Library unterstützt. Als Rvalue werden temporäre Werte bezeichnet, die nicht über den Rahmen des Ausdrucks hinaus existieren. Ein Ausdrücke ohne Variablenname ist ein Rvalue. Das Pendant zum Rvalue ist der Lvalue. Alle Ausdrücke mit Namen sind Lvalues. Bei Zuweisungen dürfen Lvalues links sowie rechts vom Gleichheitszeichen stehen, Rvalues können nur links vom Gleichheitszeichen existieren Singleton in Multithreading-Umgebungen Es gibt Fälle, in denen von einer Klasse nur eine einzige Instanz existieren darf, diese jedoch mehreren Teilen der Anwendung zur Verfügung stehen muss. Statt globaler Variablen wurde in dieser Anwendung das Entwurfsmuster Singleton gewählt. Bei diesem Muster wird die Ressource an eine globale Variable gebunden, der Zugriff und ihre Erzeugung sind jedoch an die Methode getinstance() gebunden. 21

34 Kapitel 3. Praxisteil Type CallxSingleton -m_instance: Type* -m_once_flag: boost::once_flag -CallxSingleton() +~CallxSingleton() +CallxSingleton(const CallxSingleton&) {delete} +operator=(const CallxSingleton&): CallxSingleton& {delete} +getinstance(): Type* -createinstance(): void Abbildung 3.1.: Klassendiagramm CallxSingleton In einer Multithreading-Umgebung müssen Maßnahmen getroffen werden, damit die Methode getinstance() bei parallelem Zugriff nicht mehr als eine Instanz der Klasse erzeugt. Dazu wird oft das Muster Double-Checked Locking verwendet. Hier wurde ein anderer Ansatz gewählt. C++11 garantiert mit der Methode std::call_once() in Verbindung mit der Hilfsklasse std::once_flag, dass die Methode createinstance() zur Erzeugung des Objekts nicht mehrfach ausgeführt wird. In Abbildung 3.1 ist die in der Anwendung callx ii verwendete Template-Klasse Callx- Singleton dargestellt. 22

35 3.4. Softwarearchitektur 3.4. Softwarearchitektur Das Datenflussflussdiagramm aus Abbildung 3.2 bietet eine Übersicht der Anwendungsarchitektur inklusive der Anbindung an die VIAT-Module Feature Extractor und Index Daemon. Die folgenden Abschnitte wird auf die Schnittstellen, Datenspeicher und Prozesse eingegangen Schnittstellen Die Anwendung callx ii verfügt über die Schnittstellen Config, LIBPCAP, File System, TCP Client OutputHandler und TCP Server Console Config Die Konfigurationsdatei der Anwendung callx ii dient zur Übergabe von Parametern. Die Pfeile in Abbildung 3.2 deuten an, dass Informationen von dieser Schnittstelle an viele Objekte weitergegeben werden. Die Abbildung 3.3 zeigt das zugehörige Klassendiagramm LIBPCAP LIBPCAP [tcpdmp] ist eine eigenständige Bibliothek, welche für die Bereitstellung der Netzwerkdaten zuständig ist. LIBPCAP wird angewiesen die Netzwerkschnittstelle im Promiscuous Mode zu betreiben. Somit werden nicht nur direkt an diese Schnittstelle adressierte Netzwerkpakete verarbeitet, sondern alle, die an dieser Schnittstelle anliegen. Üblicherweise werden geswitchte Netzwerke verwendet, so dass weitere Vorkehrungen nötig sind, um den gewünschten Datenverkehr zu erhalten. Dies kann durch einen Monitoring Port an einem Switch erreicht werden. [Cis07] Zur Vorfilterung des Netzwerkverkehrs kann ein Filter konfiguriert werden. Eine ausführliche Übersicht über die Syntax sogenannter TCPDUMP filters hat Marios Iliofotou 1 in [tcpflt05] zusammen gestellt. Wenn nur UDP-Pakete verarbeitet werden sollen, die aus dem Netzwerk /24 stammen, kann der Filter wie folgt lauten: udp and src net mask Department of Computer Science & Engineering, University of California, Riverside 23

36 Kapitel 3. Praxisteil LIBPCAP UdpPacketQueue SipPacketQueue CallMap CallDecode Queue PcapData (Ethernet) TlayerPacket (UDP Packet) SipPacket Call Call Call Pcap Handler Tlayer Dispatcher UdpHandler SipProcessor Audio Handler TlayerPacket (PCAP Packet) TlayerPacket (RTP Packet) RtpSink Incident Event PcmAudio PcapPacketQueue RtpSink RtpSinkMap SbaIncidentMap SbaEventMap PcmAudio Queue TlayerPacket Incident Event PcmAudio TlayerPacketQueue Config SigBasedAna TlayerPacket Recycling File System Index Daemon Matchlist Record WaveFile Watchdog Fingerprint VIAT Database Call Record Output Handler Console Inverted Index Feature Extractor TCP Server FeatureX PCM Data TCP Client OutputHandler Command Result TCP Server Console Network Layer 2-4 Processing SIP/SDP Processing Signaling Based Analysis Audio Decoding and Output Abbildung 3.2.: Datenflussdiagramm der Software Callx II mit Anbindung an VIAT Content Based Analysis & Search. Notation nach Tom DeMarco: Datenspeicher - zwei parallele Linien, Datenfluss - Pfeil, Prozess - Kreis, Schnittstelle - Rechteck 24

37 3.4. Softwarearchitektur Config -m_cfgmap: std::map<std::string, std::string> +Config() +~Config() +readconfig(const std::string&): bool +getstr(const std::string&, std::string = ""): std::string +getint(const std::string&, int = 0): int +getbool(const std::string&, bool = false): bool CallxConfig CallxSingleton CallxConfig -m_config: Config +CallxConfig() +~CallxConfig() +init(): bool -ensureslash(std::string&) +logfile: std::string +pcap_device: std::string +pcap_filter: std::string +min_sip_size: int... config values Abbildung 3.3.: Klassendiagramm CallxConfig Die von LIBPCAP zu verwendende Netzwerkschnittstelle und der PCAP-Filter werden in der callx ii Konfigurationsdatei definiert File System Die Audiodaten können als RIFF-Wave-Datei im Format 8kHz 16-Bit mono ausgegeben werden. Diese Ausgabe ist optional und wird über die Konfigurationsdatei gesteuert TCP Client OutputHandler Über die Schnittstelle TCP Client OutputHandler werden die dekodierten Audiodaten an den Feature Extractor gesendet. Die bisherige Implementierung des TCP-Servers im Feature Extractor verlangte pro Übertragung der Daten eines Anrufs einen erneuten TCP-Verbindungsaufbau. Mehrere Client-Verbindungen zur gleichen Zeit wurden nicht unterstützt. Der Server wird neu konzipiert und erlaubt jetzt das Senden beliebig vieler Datensätze von mehreren Clients gleichzeitig. Dabei wird das folgende einfache Protokoll zur Synchronisation verwendet: 25

38 Kapitel 3. Praxisteil Type ThreadFriendlyQueue ThreadFriendlyMap #m_map: std::map<key, Type> #m_mutex: mutex #m_sizemax: size_t Key, Type +ThreadFriendlyMap() +~ThreadFriendlyMap() +insert(std::pair<const Key&, Type>&&): void +find(const Key&, Type&): bool +erase(const Key&): size_t +size(): size_t +sizemax(): size_t Abbildung 3.4.: Klasse ThreadFriendlyMap #m_queue: std::deque<type> #m_mutex: std::mutex #m_cond: std::condition_variable #m_activated: bool #m_sizemax: size_t +ThreadFriendlyQueue() +~ThreadFriendlyQueue() +push(type&&): void +waitandpop(type&): bool +trypop(type&): bool +empty(): bool +size(): size_t +sizemax(): size_t +activate(): void +deactivate(): void Abbildung 3.5.: Klasse ThreadFriendlyQueue <Start Sequenz> <Daten> <Ende Sequenz> Die Startsequenz besteht aus den vier 16-Bit-Werten 1, 10, 100 und Demgegenüber besteht die Endsequenz aus den gleichen vier 16-Bit-Werten, jedoch in umgekehrter Reihenfolge (1000, 100, 10 und 1) TCP Server Console Die Schnittstelle TCP Server Console kann mittels Terminal-Client oder Telnet genutzt werden. Über diese Konsole lassen sich Informationen zu Füllständen von Datenspeichern und teilweise auch deren Inhalte ausgeben. In der Konfigurationsdatei wird der Port definiert, den der TCP-Server nutzen soll. Aus Sicherheitsgründen handelt es sich immer um einen lokalen, nicht direkt von außen erreichbaren TCP-Socket am Loopback- Interface, da keine Zugangskontrolle existiert. Der Zugriff von außen kann über einen SSH-Tunnel ermöglicht werden Datenspeicher Die verschiedenen Prozesse (Threads der Anwendung) verwenden Maps (assoziative Arrays) und Queues (FIFO-Prinzip) als gemeinsame Datenspeicher. Aus der C++ Standard Library werden die Container std::map und std::deque 2 verwendet. Diese sind nicht thread-sicher. Es liegt nahe von diesen Containern zu vererben, um die kritischen 2 Double-ended queue; std::queue wäre auch möglich, ist jedoch selber ein Adapter von std::deque. 26

39 3.4. Softwarearchitektur Methoden zu überschreiben und wechselseitigen Ausschluss zu implementieren. Da die STL-Container jedoch keinen virtuellen Destruktor besitzen würde bei Nutzung von Polymorphie der Destruktor der vererbten Klasse nicht aufgerufen, was unweigerlich zu Ressourcen-Lecks führt. Statt einer is-a-beziehung wird daher eine has-a-beziehung mittels Wrapper-Klassen entwickelt, die den jeweiligen STL-Container als Member-Variable enthält. Das Design dieser Wrapper-Klassen (Template-Klassen) ist angelehnt an das der STL-Container. Der konkrete Funktionsumfang orientiert sich an den Anforderungen der Anwendung. Die neuen Klassentemplates heißen ThreadFriendlyMap und ThreadFriendlyQueue. Objekte dieser Klassen sind thread-sicher. Sie implementieren feingranulares Locking, so dass sich wechselseitige Zugriffe nur möglichst kurz blockieren. Sind jedoch aufwendigere Aktionen auf mehreren oder gar sehr vielen Objekten des Containers notwendig, stellen die vorhandenen Methoden zu wenig Flexibilität zur Verfügung. Beispielsweise bietet die Schnittstelle keine Iteratoren an. Die Vererbung von diesen Klassen-Templates ist aufgrund der virtuellen Destruktoren ohne Seiteneffekte möglich. Alle Membervariablen sind als protected deklariert, so dass die abgeleitete Klasse darauf vollen Zugriff hat, beispielsweise auf das STL-Containerund das Mutex-Objekt. In neuen Methoden der abgeleiteten Klassen-Templates ist die Synchronistion von Zugriffen entsprechend zu implementiert. Daher beinhalten die Bezeichner der neuen Klassen-Templates den Zusatz ThreadFriendly und nicht Thread- Safe. Die Abbildungen 3.4 und 3.5 zeigen die beiden Wrapper-Klassen ThreadFriendlyMap und ThreadFriendlyQueue, die Grundlage von insgesamt 10 gemeinsamen Ressourcen dieser Anwendung sind. Alle diese Ressourcen sind nicht direkte Instanzen dieser Klassen, sondern Instanzen von Klassen, die entweder von ThreadFriendlyMap oder von ThreadFriendlyQueue und zusätzlich von CallxSingleton erben ThreadFriendlyMap Über den Templateparameter Type wird wie bei STL-Containern der Typ der aufzunehmenden Objekte festgelegt. Zum Hinzufügen von Elementen steht die Methode insert(std::pair<const Key&, Type>&&) zur Verfügung. Ein Element ist ein Paar (std::pair) bestehend aus Schlüssel und Wert. Sowohl std::pair als auch die Übergabe dieses Paars unterstützen Move- Semantic, so dass im Falle eines Rvalues weder eine unnötige Kopie von Key und Type erfolgt, noch eine unnötige Kopie des Paars. Der Kompiler führt bei Übergabe eines Rvalues die Methode std::map::insert(std::pair<const Key&, Type>&&) aus. Wird ein Lvalue übergeben, führt der Kompiler statt dessen die Methode std::map::insert( 27

40 Kapitel 3. Praxisteil const std::pair<const Key&, Type>&) 3 aus. Die explizite Definition von std::map ::insert(const std::pair<const Key&, Type>&) ist nicht notwendig. 4 Zum Auffinden von Elementen wird die Methode find(const Key&, Type&) verwendet. Dabei stellt Key den Schlüssel dar, über den das Element eindeutig im Container indentifiziert werden kann. Ist das Element vorhanden, wird davon eine Kopie im zweiten Übergabeparameter (Type&) gespeichert. In dieser Anwendung handelt es immer um Shared-Pointer, die auf das eigentliche Objekt zeigen. Die Methode erase(const Key&) löscht das Element, das über den Schlüssel Key aufzufinden ist ThreadFriendlyQueue Wie bei ThreadFriendlyMap wird der Typ der aufzunehmenden Elemente per Template- Parameter angegeben. Die folgenden Methoden zum Hinzufügen von Elementen (push) und Entnehmen von Elementen (pop) unterstützen Move-Semantik. Die Methode push(type&&) fügt dem Container ein Objekt hinzu. Handelt es sich bei dem Objekt um ein Rvalue, ruft der Compiler std::deque::push(type&&) auf. Handelt es sich um ein Lvalue, wird die Methode std::deque::push(const Type&) aufgerufen. Die explizite Definition von ThreadFriendlyQueue::push(const Type&) ist nicht notwendig. Im Falle eines Rvalues wird keine temporäre Kopie des Objekts erzeugt. Es werden zwei Methoden zum Entnehmen von Objekten aus dem Container implementiert: bool waitandpop(type&) Die Methode blockiert, falls die Warteschlange leer ist. Es wird kein Polling verwendet. Die Methode push(type&&) teilt einem in waitandpop(type&) wartenden Thread über ein Objekt vom Typ std::condition_variable mit, dass dem Container ein Element hinzugefügt wurde. bool trypop(type&) Die Methode blockiert nicht und gibt bei Erfolg (es befindet sich mindestens ein Objekt im Container) true zurück, sonst false. Die Methoden bool empty(), size_t size() und size_t sizemax() geben Auskunft über den Füllstatus des Containers. Die Methoden activate()/deactivate() dienen zum setzen/zurücksetzen des Flags 3 Lvalue-Referenz auf const statt Rvalue-Referenz 4 Perfect-Forwarding 28

41 3.4. Softwarearchitektur m_activated. Zusätzlich werden beim Deaktivieren alle in waitandpop() blockierten Threads mit der Methode m_cond.notify_all() aufgeweckt Prozesse, Threads CallxThread #m_callxconfig: CallxConfig* #m_thread: std::thread #m_stoprequested: bool #m_stopped: bool +CallxThread() +~CallxThread() +start(): void +stop(): void +join(): void +worker(): void = 0 +workerstopped(): bool Abbildung 3.6.: Klasse CallxThread Im Datenflussdiagramm (Abbildung 3.2) sind 11 Prozesse dargestellt. Die beiden farblich grau gestalteten Prozesse (VIAT Content Based Analysis & Search) werden hier nicht näher betrachtet. Bei den verbleibenden 9 Prozessen handelt es sich aus Betriebssystemsicht in ihrer Gesamtheit um den callx ii Prozess, der aus 9 einzelnen Threads besteht. Alle Threads sind von der abstrakten Elternklasse CallxThread (Abblidung 3.6) abgeleitet. Diese bietet eine einfache Schnittstelle mit den folgenden Methoden zur Steuerung: start() Startet den Thread. stop() Setzt das Flag m_stoprequetsted und blockiert, bis sich die Methode worker() beendet, oder wenn eine Zeitüberschreitung auftritt. join() Blockiert so lange, bis der Thread stoppt. worker() Dies ist die einzige Methode, die von Kindklassen implementiert werden muss (abtrakte Methode). Sie wird ausgeführt, wenn der Thread gestartet wird und sollte die folgende Konvention einhalten: Wenn das Flag m_stopprequetsted gesetzt ist, muss sich die Methode nach eventuellen Aufräumarbeiten baldmöglichst beenden. 29

42 Kapitel 3. Praxisteil create PcapWrapper object set PCAP device and filter call PcapWrapper loop() [ loop ] stop [ requested ] call PcapWrapper readstats() Abbildung 3.7.: Aktivität des Threads PcapHandler, Methode PcapHandler::worker() PcapHandler::callback() PCAP subsystem PCAP data get TlayerPacket from TlayerPacketQueue fill TlayerPacket object move TlayerPacket into PcapPacketQueue Abbildung 3.8.: Aktivität der Methode PcapHandler::callback() bool workerstopped() Gibt true zurück, wenn die Methode worker() nicht gestartet ist PcapHandler Wie alle Threads der Anwendung callx ii erbt die Klasse PcapHandler von der abstrakten Basisklasse CallxThread. Die Aufgabe einer PcapHandler-Instanz ist es Netzwerkpakete anzufordern, entgegenzunehmen, in ein Objekt zu verpacken und diese zur weiteren Verarbeitung in eine Warteschlange zu verschieben. Die Abbildungen 3.7 und 3.8 zeigen den Ablauf als Aktivitätsdiagramme. Die Methode PcapHandler::callback() wird vom PCAP-Subsystem aufgerufen, während die Methode PcapHandler::worker() bei der Ausführung von PcapWrapper::loop() blockiert. Dies wird nachfolgend im Detail beschrieben. Zum Anfordern der Netzwerkpakete wird die in Abbildung 3.10 dargestellte Klasse Pcap- Wrapper verwendet. Jedes eintreffende Netzwerkpaket wird in einem Objekt der Klasse TlayerPacket (Abbildung 3.11) gespeichert, das danach in die Warteschlange vom Typ PcapPacketQueue abgelegt wird. Es wurde eine statische Callback Methode PcapHandler::staticCallBack() implementiert, die von der unter dem PcapWrapper liegenden Bibliothek LIBPCAP beim Eintreffen eines Netzwerkpakets ausgeführt wird. Diese kopiert den PCAP-Header sowie die PCAP-Daten in TlayerPacket Objekte. 30

43 3.4. Softwarearchitektur PcapPacketQueue TlayerPacketRecycler -m_tlayerpacketqueue: TlayerPacketQueue* +TlayerPacketRecycler() +operator() () CallxThread TlayerPacketQueue 1 * TlayerPacket PcapWrapper PcapHandler -m_pcapwrapper: PcapWrapper -m_pcappacketqueue: PcapPacketQueue* -m_tlayerpacketqueue: TlayerPacketQueue* -m_tlayerpacket: std::unique_ptr<tlayerpacket, TlayerPacketRecycler> +PcapHandler() +~PcapHandler() +worker(): void +stop(): void +staticcallback(u_char*, const pcap_pkthdr*, u_char*): void -callback(const pcap_pkthdr*, u_char*): void Abbildung 3.9.: Klassendiagramm PcapHandler PcapWrapper -m_pcaphandle: *pcap_t -m_fp: bpf_program -m_errbuf[pcap_errbuf_size] -Max_Capture_Bytes: u_int -m_pcapstats: pcap_stat -m_dropped:long -m_received: long +PcapWrapper() +~PcapWrapper() +opendevice(std::string): bool +openfile(std::string): bool +setfilter(std::string): bool +getnextpacket(struct pcap_pkthdr**, u_char const**): int +dispatch(void*, int, pcap_handler): int +loop(void*, int, pcap_handler): int +geterrormessage(): std::string +readstats(): void +getreceived(): long +getdropped(): long Abbildung 3.10.: Klasse PcapWrapper 31

44 Kapitel 3. Praxisteil PcapPacket TlayerPacket SocketAddress +header: pcap_pkthdr +payload: u_char[pcap_max] +payloadlen: size_t +pacppacket: PcapPacket +ethernetpacket: EthernetPacket +ippacket: IpPacket +udppacket: UdpPacket +tcppacket: TcpPacket +srcsocket: SocketAddress +dstsocket: SocketAddress +TlayerPacket() +~TlayerPacket() +fill(pcap_pkthdr, const u_char*) +parsenetworklayer() +parsetransportlayer() 1 2 EthernetPacket IpPacket UdpPacket TcpPacket +header: ether_header* +header: ip* +version: u_short +header: udphdr* +header: tcphdr* GenericPacket +header: void* +headerlen: size_t +payload: u_char* +payloadlen: size_t Abbildung 3.11.: Klassendiagramm TlayerPacket 32

45 3.4. Softwarearchitektur PcapWrapper Die Klasse PcapWrapper bietet eine Schnittstelle zur Nutzung der C- Bibliothek LIBPCAP. Neben Methoden zur Auswahl der Netzwerkschnittstelle, zum Festlegen und Kompilieren des PCAP-Filters sowie zur Weitergabe der PCAP-Paket- Statistik stehen verschiedene Methoden zur Übergabe von Netzwerkpaketen bereit: PcapWrapper::getNextPacket() nutzt pcap_next_ex() und speichert bei Erfolg einen Zeiger auf Header und Daten. Hierbei wird keine Callback Methode genutzt. Da für jedes Packet ein Funktionsaufruf benötigt wird, ist diese Methode für hohe Packetraten nicht geeignet. PcapWrapper::dispatch() nutzt pcap_dispatch(). Diese Methode blockiert und ruft eine Callback Methode für jedes eintreffende Paket auf. Der zweite Parameter (siehe Abbildung 3.10) die maximale Anzahl zu erfassender Pakete an. Dabei handelt es sich nicht um die minimale Anzahl, sondern um die maximale. Bei hohen Paketraten erfolgen auch hier erfahrungsgemäß sehr viele Funktionsaufrufe. PcapWrapper::loop() nutzt die Methode pcap_loop(), die ähnlich wie pcap_dispatch() funktioniert. Der einzige Unterschied ist der zweite Parameter (siehe Abbildung 3.10), der hier die minimale Anzahl an Paketen angibt. In dieser Anwendung wird pcap_loop() verwendet, da die CPU-Auslastung und die Verlustrate bei hohen Paketraten am geringsten ist. Die Callback Methode PcapHandler::staticCallback() muss statisch sein, da LIBP- CAP als C-Bibliothek die Objektinstanz nicht berücksichtigt. Problematisch ist, dass statische Methoden nicht direkt auf Daten der Objektinstanz zugreifen können. Die von LIBPCAP verwendeten Methoden erlauben jedoch einen Zeiger auf eine benutzerdefinierte Variable, der beim Aufruf der statischen Callback Methode übergeben wird. Zur Lösung des Problems wird ein Zeiger auf die Objektinstanz übergeben, so dass die statische Methode daraufhin die Methode PcapHandler::callback() der Instanz adressieren kann. Dies wird anhand der folgenden Quelltextausschnitte verdeutlicht: Der PcapHandler führt die Methode loop() des PcapWrapper Objekts aus: m_pcapwrapper. loop ( this, // Pointer to the current instance. 1000, // Number of packets to fetch before returning. staticcallback // The static callback function pointer. ); Implementierung der Methode PcapWrapper::loop(): int PcapWrapper :: loop ( void * user, // PcapHandler instance pointer int cnt, // number of packets pcap_ handler callback ) // static callback function 33

46 Kapitel 3. Praxisteil { return pcap_ loop ( m_pcaphandle, cnt, callback, } ); // The user part ( pointer to the PcapHandler instance ). // Unfortunately it has to be type of u_char *. // That is subject to interpretation... reinterpret_ cast < u_char * >( user ) Die Methode pcap_loop() führt für jedes eingehende Paket die nachfolgende statische Methode aus, die wiederum die Callback Methode PcapHandler::callback() der Instanz ausführt: static void staticcallback ( u_char * instance, // PcapHandler instance pointer const struct pcap_ pkthdr * header, // pcap header const u_char * data ) // pcap data { // Calls the method callback (...) of the particular // PcapHandler instance. (( PcapHandler *) instance ) -> callback ( header, data ); } TlayerPacket Aus den PCAP-Daten erzeugt die Callback-Methode der PcapHandler- Instanz Objekte der Klasse TlayerPacket (Abbildung 3.11). Tlayer ist hier die Abkürzung für Transaport Layer. Der Name ergibt sich aus den in dieser Klasse vorhanden Möglichkeiten die von der LIBPCAP übergebenen Daten bis hin zur Transportschicht zu verarbeiten. Die Klasse TlayerPacket besteht aus der Klasse PcapPacket, die zur Speicherung der Rohdaten genutzt wird. Die Methode PcapHandler::callback() kopiert eine zur Kompilierzeit festgelegte Anzahl Byte in das Array m_pcappacket.payload 5. Zusätzlich besteht sie aus den Klassen EthernetPacket, IpPacket, UdpPacket und TcpPacket, die Spezialisierungen der Klasse GenericPacket sind. Eine Instanz der Klasse TlayerPacket wird mittels der Methode fill() mit PCAP Daten befüllt. Folgende Anforderungen werden erfüllt: Minimierung der Anzahl der Speicherallokationen Eine Objekt der Klasse TlayerPacket besitzt keine dynamisch allozierten Speicherbereiche. Für die Aufnahme der PCAP-Daten steht ein Array mit entsprechender Größe zur Verfügung. 5 Die Größe wurde in PcapWrapper.hpp per #define auf 1536 Byte festgelegt. Die Festlegung über die Konfigurationsdatei würde aufwendigere, dynamische Allokation erfordern. 34

47 3.4. Softwarearchitektur Minimierung der Kopieroperationen Es wird lediglich einmal die Methode memcopy(..) verwendet und zwar zum Kopieren der PCAP-Daten aus dem Speicher der LIBPCAP in die Membervariable PcapPacket. Die meisten Ergebnisse der nachfolgenden Verarbeitung beziehen sich auf diesen Speicherbereich. Die Member-Objekte m_ethernetpacket, m_ippacket, m_udppacket und m_tcppacket besitzen lediglich Zeiger für Header und Payload, die auf die entsprechenden Positionen im Speicherbereich von Pcap- Packet.payload verweisen. Parallele Verarbeitung ermöglichen Die Verarbeitung bis zur Transportschicht wurde dreigeteilt. Dadurch können drei Threads die PCAP Daten sukzessive und parallel verarbeiten: Initialisierung PCAP-Header und -Daten werden in das Objekt kopiert. (Ausführung im Thread PcapHandler) Parsen bis zur Netzwerkschicht Die Methode TlayerPacket::parseNetlayer() parst den Ethernet-Header und den IP-Header. Die beiden SocketAddress Objekte werden mit den Quell- und Ziel-IP-Addressen beschrieben. (Ausführung im Thread Tlayer- Dispatcher) Parsen der Transportschicht Die Methode TlayerPacket::parseTransportlayer() parst den UDP-Header 6 und aktualisiert die SocketAddress Objekte mit Protokoll- und Port- Informationen. (Ausführung im Thread UdpHandler) TlayerPacketQueue Die Anwendung soll mit vielen gleichzeitigen Calls (hohe Paketraten), zurecht kommen. Bei 500 gleichzeitigen, G711 codierten Calls ergibt sich folgende RTP Paketrate, die vom PcapHandler verarbeitet werden muss (die Signalisierung wird vernachlässigt): R = n s r = = P akete/s mit: n = 500 Calls s = 2 Streams r = 50 RT P P akete/s/stream R = P aketrate [1/s] 6 Andere Transportprotokolle außer UDP werden hier nicht unterstützt, könnten jedoch nachgerüstet werden. 35

48 Kapitel 3. Praxisteil Damit nicht erst beim Eintreffen eines Netzwerkpakets ein TlayerPacket Objekte erzeugt werden muss, wurde mit der Klasse TlayerPacketQueue ein Repository implementiert. Darin werden in std::unique_ptr gekapselte TlayerPacket Objekte gespeichert. Die TlayerPacketQueue erbt von den Templateklassen ThreadFriendlyQueue und CallxSingleton. Eine Besonderheit ist die Wiederverwendung der TlayerPacket Instanzen, so dass nur einmal beim Start des Programms das Repository mit einer konfigurierbaren Anzahl an TlayerPacket Objekten bestückt wird. Jeweils ein Unique-Pointer verwaltet ein TlayerPacket Objekt. Wird der Unique-Pointer gelöscht, so wird durch dessen Destruktor der TlayerPacket-Destruktor aufgerufen. An dieser Stelle ist es möglich einen Custom- Deleter anzuhängen, der das Aufräumen der Ressource übernimmt. In der Standardeinstellung werden eine Million Objekte erzeugt. Dazu werden ca. 1,8 GB Arbeitsspeicher benötigt, die sich aus 1880 Bytes pro TlayerPacket-Objekt ergeben. Die Größe eines TlayerPacket Objekts wurde über sizeof(tlayerpacket) bestimmt. Darin enthalten ist der 1536 Byte große Puffer für PCAP-Daten. Die Größe des Objekts kann je nach Kompiler geringfügig variieren, hier wurde GCC Version verwendet. TlayerPacketRecycler Die Klasse TlayerPacketRecycler dient zum Recyclen von TlayerPacket-Instanzen. Sie wird beim Parametrisieren des Templates std::unique _ptr zur Verwaltung von TlayerPacket Objekten als Custom-Deleter angegeben: std::unique_ptr<tlayerpacket, TlayerPacketRecycler> Das Vorhandensein eines Custom-Deleters ändert das Verhalten des Unique-Pointers, wenn dieser gelöscht wird. Statt den Destruktor der zu verwaltenden Ressource aufzurufen, wird die Methode TlayerPacketRecycler::operator()() ausgeführt. Diese erzeugt ein neues Objekt vom Typ std::unique_ptr, das auf die ursprünglich zu löschende TlayerPacket-Instanz zeigt und hängt es dem Repository TlayerPacketQueue zur Wiederverwendung an. Das Unique-Pointer-Objekt kann nicht erhalten werden, da bereits dessen Destruktor aufgerufen wurde. Dieses Vorgehen spart die Erzeugung eines relativ großen Objekts ein und dies mindestens Mal pro Sekunde bei 500 gleichzeitigen G711 codierten Calls. SocketAddress Die Klasse SocketAddress (Abbildung 3.12) definiert einen Netzwerk- Socket, der aus IP-Adresse, Port und Protokoll besteht. In dieser Anwendung wird bisher nur IP in der Version 4 unterstützt. Die Klasse SocketAddress ist jedoch durch Verwendung der Bibliothek boost::asio::ip unabhängig von der Version des IP Protokolls. Die Klasse SocketAddress bietet Methoden zum Lesen und Schreiben der Socketda- 36

49 3.4. Softwarearchitektur SocketAddress -m_ipaddress: boost::asio::ip::address -m_port: u_short -m_transportprotocol: transportprotoenum +SocketAddress() +~SocketAddress() +setipaddress(boost::asio::ip::address): void +setport(unsigned short): void +settransportproto(transportprotoenum): void +setdata(boost::asio::ip::address, u_short, transportprotoenum) +getipaddress(): boost::asio::ip::address +getport(): u_short +gettransportprotocol(): transportprotoenum +gettransportprotocolstr(): std::string +isvalid(): bool +operator<(const SocketAddress&): bool +operator>(const SocketAddress&) : bool +operator==(const SocketAddress&): bool +operator!=(const SocketAddress&): bool +operator<<(std::ostream&, SocketAddress*): std::ostream& {friend} +operator<<(std::ostream&, SocketAddress): std::ostream& {friend} Abbildung 3.12.: Klasse SocketAddress ten, sowie Vergleichsoperatoren, die zumindest teilweise für die Speicherung in STL- Containern notwendig sind und Stream-Operatoren zur Ausgabe der Socketinformationen im Format <IP>:<Port> <Protokoll>. Die Stream-Operatoren müssen außerhalb der Klasse definiert werden. Damit diese trotzdem Zugriff auf private Eigenschaften der Klasse haben, sind sie als friend der Klasse definiert. 37

50 Kapitel 3. Praxisteil [ is UDP ] [ loop ] move TlayerPacket into UdpPacketQueue stop [ requested ] pop TlayerPacket from PcapPacketQueue parse TlayerPacket network layer [ is... ] move... [ is TCP ] move TlayerPacket into TcpPacketQueue Abbildung 3.13.: Aktivität des Threads TlayerDispatcher. Methode TlayerDispatcher ::worker() TlayerDispatcher Der Thread TlayerDispatcher nimmt die Netzwerkpakete vom PcapHandler über die PcapPacketQueue entgegen, prüft das Protokoll der Transportschicht und verteilt die Pakete in die für die entsprechende Transportschicht vorgesehene Warteschlange. Dazu werden der Warteschlange PcapPacketQueue Objekte vom Typ std::unique_ptr <TlayerPacket, TlayerPacketRecycler> entnommen und es wird die Methode TlayerPacket::parseNetlayer() ausgeführt, siehe Abbildung Danach steht fest, um welches Transportlayer-Protokoll es sich handelt und der Unique-Pointer wird zur weiteren Verarbeitung in die entsprechende Queue verschoben. callx ii unterstützt UDP, eine Erweiterung zur Unterstützung anderer Protokolle ist möglich. Handelt es sich um ein UDP Paket, wird der Unique-Pointer in den gemeinsamen Datenspeicher UdpPacketQueue verschoben und vom UdpHandler weiterverarbeitet. Pakete nicht relevanter Protokolle werden nicht weiter verarbeitet. Der Unique-Pointer räumt das nicht mehr verwendete TlayerPacket Objekt automatisch auf, wie bereits in Abschnitt (Paragraph TlayerPacketRecycler) beschrieben. In der Klasse TlayerDispatcher wird die die Methode stop() der Elternklasse Callx- Thread überschrieben, da das baldige Beenden des Threads durch eventuelles Blockieren der Methode ThreadFriendlyQueue::popAndWait() nicht sichergestellt ist. Die Methode TlayerDispatcher::stop() deaktiviert zuerst die PcapPacketQueue (siehe Basisklasse ThreadFriendlyQueue, Abschnitt ) und ruft danach CallxThread:: stop() auf. 38

51 3.4. Softwarearchitektur [ loop ] pop TlayerPacket from UdpPacketQueue parse TlayerPacket Transport Layer test RTP stop [ requested ] [ else ] found [ RTP Version ] number find RtpSink in RtpSinkMap test SIP [ else ] available [ RtpSink ] move TlayerPacket into RtpSink [ else ] [ is SIP ] create SipPacket object move SipPacket into SipPacketQueue Abbildung 3.14.: Aktivität des Threads UdpHandler. Methode UdpHandler::worker() UdpHandler Der Thread UdpHandler erhält TlayerPacket Objekte vom Thread TlayerDispatcher über die Warteschlange UdpPacketQueue. Der Payload jedes UDP-Pakets wird untersucht. Handelt es sich um SIP oder RTP, wird das Paket zur weiteren Verarbeitung durch den SipProcessor in die Warteschlange SipPacketQueue beziehungsweise an ein RtpSink Objekt weitergeleitet. Der SipProcessor (Abschnitt ) erstellt pro zu erwartenden Audiostrom (RTP-Paketstrom, unidirektional) ein RtpSink Objekt, das zur Zwischenspeicherung eingehender RTP-Pakete dient. Der Ablauf der Methode UdpHandler::worker() ist in Abbildung 3.14 dargestellt. Identifikation und Verteilung von SIP und RTP Transportschichtprotokolle besitzen meist keine Information über das im Payload enthaltene Protokoll, so auch UDP. Da SIP- und RTP-Pakete den entsprechenden Einheiten zugeführt werden, ist eine Vorverarbeitung des Payloads jedes UDP-Pakets notwendig. Da sehr hohe Paketraten (siehe Abschnitt , Paragraph TlayerPacketQueue auf Seite 35) verarbeitet werden, bedarf es einer effizienten Identifizierung des Transportschichtprotokoll-Payloads. Folgender Algorithmus wird umgesetzt. Dabei wird berücksichtigt, dass es sich in einem VoIP Netzwerk bei den meisten Paketen um RTP-Pakete handelt: 39

52 Kapitel 3. Praxisteil 1. Test auf RTP-Version Die RTP-Version ist die einzige Konstante in einem RTP-Paket, die zur Zeit immer 2 ist. Dieser Test alleine bietet keine zuverlässige Aussage darüber, ob es sich um RTP-Payload handelt, dient jedoch einer schnellen Vorfilterung. Bei Nichtvorhandensein der Versionsnummer 2, wird der folgende Schritt 2 übersprungen. 2. Suche eines RtpSink Objekts Es wird ein RtpSink Objekt gesucht dessen Socket-Adresse gleich des UDP-Ziel- Sockets ist. RtpSink Objekte sind mit dem Ziel-Sockets als Schlüssel in der globalen RtpSinkMap hinterlegt. Ist das gesuchte RtpSink Objekt vorhanden, wird diesem der Unique-Pointer auf das TlayPacket Objekt mittels Move-Semantik übergeben und der Algorithmus ist damit beendet. 3. Test der Payload-Länge bezogen auf SIP Die in der Konfiguration hinterlegte minimale Länge eines SIP-Pakets (min_sip _size) wird mit der Größe des UDP-Payloads verglichen. Bei Unterschreitung wird das Paket verworfen, da es sich nicht um ein relevantes SIP-Paket handelt. Der Algorithmus endet hier und startet mit dem nächsten Paket von vorne. 4. Suchen der Zeichenfolge SIP/2.0 Innerhalb der minimalen Länge eines SIP-Pakets wird die Zeichenfolge SIP/2.0 gesucht. Diese ist in jedem SIP-Packet in der Start-Line (erste Zeile des SIP-Headers) enthalten. Die Position ist jedoch unterschiedlich. Bei SIP-Requests steht sie am Ende der Start-Line, bei SIP-Responses steht sie am Anfang. Wenn die Zeichenfolge vorhanden ist, wird ein SipPacket Objekt erzeugt und der aktuelle Unique- Pointer des TlayerPacket Objekts im Konstruktor übergeben. Das SipPacket Objekt wird zur weiteren Verarbeitung durch den Thread SipProcessor der Sip- PacketQueue hinzugefügt. Spätestens an dieser stelle endet der Algorithmus und beginnt mit dem nächsten TlayerPacket Objekt von vorne. Die Schritte 2 und 4 sind relativ aufwendig, da sehr hohe Paketraten verarbeitet werden. Durch die gewählte Reihenfolge und durch einfache Vorfilterung gelingt es, den gesamten Ressourcenaufwand gering zu halten. 40

53 3.4. Softwarearchitektur SipProcessor Der Thread SipProcessor verarbeitet die Signalisierungsnachrichten, die vom UdpHandler an die Warteschlange SipPacketQueue angefügt werden. Seine Aufgabe ist es SIP- Nachrichten zu parsen, auszuwerten und damit Auf-, Abbau sowie Konfiguration von Kommunikationsbeziehungen zu erkennen. Dazu enthält die Klasse SipProcessor einen passiven SIP-Stack. SIP-Nachricht SIP-Nachrichten sind in Objekte der Klasse SipPacket gekapselt. Die Definition der Klasse SipPacket ist in Abbildung B.2 dargestellt. Der Konstruktur nimmt einen Unique-Pointer auf ein Objekt der Klasse TlayerPacket entgegen. Die Referenz auf das TlayerPacket Objekt verbleibt im SipPacket Objekt. Damit sind Erweiterungen möglich, die es dem Applikationsschicht verarbeitenden Thread SipProcessor ermöglichen Informationen der darunter liegenden Netzwerkschichten zu verarbeiten. Die Klasse SipPacket besitzt einen SIP-Parser, nach dessen Ausführung Zugriff auf alle relevanten Informationen der SIP-Nachricht möglich ist. SIP-Parser Bevor eine SIP-Nachricht vom SIP-Stack interpretiert werden kann, wird die Nachricht geparst. Der dazu verwendete SIP-Parser ist in der Methode SipPacket::parse() implementiert. Das Parsen beinhaltet das Bereitstellen von Informationen der SIP-Start-Line, des SIP-Headers und bei Vorhandensein das Parsen und Bereitstellen der SDP-Daten des SIP-Bodys. Zuerst wird die SIP-Start-Line zerlegt. Danach wird die gesamte Nachricht in Zeilen aufgeteilt und in Maps, jeweils eine für SIP und eine für SDP, gespeichert. Danach werden die Zeilen mit regulären Ausdrücken zerlegt und die einzelnen Informationen in Variablen gespeichert, die über die get-methoden nach Außen zur Verfügung stehen. Passiver SIP-Stack Der passive SIP-Stack interpretiert die zwischen zwei SIP-Teilnehmern (SIP-Endgeräte oder -Server) ausgetauschten SIP-Nachrichten und verfolgt Auf-, Abbau sowie Konfiguration von Kommunikationsbeziehungen. In RFC 3261 [Ros02] sind vier Transaktionsautomaten definiert. Für Client- und Servertransaktionen sind jeweils die beiden Anfragen INVITE und non-invite definiert. Der passive SIP-Stack verarbeitet den Client- und den Serverzustand gleichzeitig, so dass sich diese jeweils zusammenfassen lassen. Die Unterscheidung zwischen INVITE und non-invite wird beibehalten, so dass zwei Automaten übrig bleiben, siehe Abbildung Im Folgenden wird das vereinfachte SipProcessor Klassendiagramms aus Abbildung 3.16 erläutert. 41

54 Kapitel 3. Praxisteil INVITE request Client Server <CALLING> <PROCEEDING> Timeout 1xx 2xx non-invite request client server Client Server <PROCEEDING> <PROCEEDING> <TRYING> <TRYING> 2xx or Timeout Timeout 1xx 2xx or client server Client Server <TERMINATED> ACK or Timeout <COMPLETED> Timeout <PROCEEDING> 2xx or <PROCEEDING> Client Server client server <TERMINATED> <TERMINATED> <TERMINATED> <TERMINATED> (a) INVITE-Transaktion (b) non-invite-transaktion Abbildung 3.15.: Im passiven SIP-Stack werden die Transaktionsautomaten von Clientund Servertransaktion aus RFC 3261 zusammengefasst. Unterschieden wird weiterhin zwischen (a) INVITE- und (b) non-invite-transaktion. 42

55 3.4. Softwarearchitektur SbaEventMap SipProcessor SbaIncidentMap SipPacketQueue RtpSinkMap CallMap 1 * Call * 1 CallDecodeQueue Dialog... LocalRtpSinkMap... SIP/SDP Processing... TransactionMap Signaling Based Analysis Abbildung 3.16.: Klassendiagramm SipProcessor (Übersicht), vollständige Beschreibungen der Klassen: SipProcessor (B.1), Call (B.3), Dialog (B.5), Transaction (B.6). Maps und Queues wie in Abschnitt beschrieben. Darüber assoziierte Klassen: RtpSink (B.4), SipPacket (B.2), SbaEvent (C.2), SbaIncident (C.3) Es werden Call Objekte erzeugt, die Dialog- und Transaktionsobjekte verwalten. Da innerhalb eines Dialogs mehrere Transaktionen gleichzeitig vorhanden sein können, werden Transaktionsobjekte in einem Container vom Typ std::map, der TransactionMap hinterlegt. Call Objekte werden in einem Thread-übergreifenden Speicher, der CallMap als Shared-Pointer hinterlegt. Die bereits im Abschnitt (UdpHandler) angesprochenen RtpSink Objekte zum Zwischenspeichern des codierten und paketierten Audiostroms werden erzeugt und Referenzen darauf jeweils in einer lokalen Map (LocalRtpSinkMap) und der globalen RtpSinkMap hinterlegt. Für die parallel vom Thread SigBasedAna durchgeführte signalisierungsbasierte Analyse werden SbaEvent Objekte erzeugt und in die SbaEventMap verschoben. Der Thread SigBasedAna wertet diese Events aus und hinterlegt in der SbaIncidentMap SbaIncident Objekte. Diese Informationen nutzt der SipProcessor um zu entscheiden, ob die Audiodaten eines Anrufs aufgenommen werden. Dieses Verhalten ist über die Konfigurationsdatei (Parameter record_if_incident_only) zu beeinflussen. Das Aktivitätsdiagramm in Abbildung 3.17 zeigt die worker() Methode des SipProcessor Threads. In einer Schleife werden SipPacket Objekte aus der SipPacketQueue entnommen und wie folgt verarbeitet: Nach dem Parsen der SIP-Nachricht wird anhand der Call-ID geprüft, ob sie zu einem bereits vorhandenen Call Objekt gehört. Wenn der Call nicht existiert, wird ein neues Call Objekt angelegt und in der CallMap gespeichert. Danach wird geprüft, ob diese Nachricht zu einer aktuellen Transaktion gehört. Wenn nein, wird im Falle eines SIP-Requests die Methode handleinitialrequest() ausgeführt. Existiert zur Nachricht eine Transakti- 43

56 Kapitel 3. Praxisteil get SipPacket from SipPacketQueue parse SIP message get Call object from CallMap exists [ Call ] get lock Call update Call activity timestamp [ else ] [ else ] INVITE or [ OPTIONS ] request create Call object get lock Call error log SIP packet not processable exists [ Transaction ] update Transaction activity timestamp [ else ] [ else ] [ else ] [ is request ] is [ request ] is [ response ] [ else ] error log response does not match any transaction handle initial request handle ACK request on NON-SUCCESS handle response [ loop ] release lock Call stop [ requested ] Abbildung 3.17.: Aktivität des Threads SipProcessor, Methode SipProcessor:: worker(). Weiterführende Aktivitätsdiagramme: create Call object (3.13), handle initial request (B.1), create Call object (3.13), handle initial request (B.1) 44

57 3.4. Softwarearchitektur on, wird im Falle eines Requests die Methode handleackonnonsuccess() 7, ausgeführt und im Falle einer Response die Methode handleresponse() aufgerufen. SBA-Events Im SIP-Stack werden Ereignis-Objekte vom Typ SbaEvent zur Verarbeitung durch die signalisierungsbasierte Analyse (SigBasedAna) erzeugt und als Shared- Pointer in der SbaEventMap abgelegt. Abbildung C.2 zeigt die Klassendefinitionen der verschiedenen Event-Arten, die nach den SIP-Methoden INVITE, CANCLE, BYE und OPTIONS benannt sind. Alle speziellen Event-Klassen erben von der allgemeinen Klasse SbaEvent. In den Events werden die aktuellen Informationen einer Transaktion gespeichert. Dazu gehört bei allen Event Typen die finale Antwort. Bei INVITE Transaktionen wird zusätzlich festgehalten, ob es sich um ein reinvite handelt, ob ein ACK gesendet wurde oder ob die Anfrage durch CANCEL vom Caller abgebrochen wurde. Das ByeEvent Objekt enthält die Zeitdauer der Verbindung. Bei OPTIONS Transaktionen wird festgehalten, ob es sich um einen Request in einem vorhandenem Dialog oder außerhalb handelt. Die Abbildungen 3.18 und 3.19 stellen dies ihn Form von Sequenzdiagrammen dar. Im ersten Sequenzdiagramm ist ein Verbindungsauf- und Abbau zu sehen. Die Dialog aufbauende INVITE Transaktion erzeugt drei InviteEvent Objekte I 1, I 2, I 3. Das erste besitzt keine zusätzlichen Informationen. Das zweite InviteEvent wird beim Auftreten der finalen Antwort 200 OK erzeugt. Die finale Antwort wird im InviteEvent gespeichert. Bei Empfang eines ACK Requests wird I 3 erzeugt, das zusätzlich auch die finale Antwort enthält. Dies erleichtert die spätere Auswertung der Ereignisse. A B INVITE 100 Trying 180 Ringing 200 OK ACK Media Session BYE 200 OK I 1 I 2 I 3 B 1 B 2 I 1 : InviteEvent I 2 : InviteEvent (with final response) I 3 : InviteEvent (with final response and ACK flag) B 1 : ByeEvent (with Call duration) B 2 : ByeEvent (with Call duration and final response) Abbildung 3.18.: Das Sequenzdiagramm zeigt die Erzeugung von Events am Beispiel von Verbindungsauf- und Abbau. 7 Ein Request innerhalb einer laufenden Transaktion kann nur ein ACK Request in Folge eines negativ beantworteten INVITE Requests sein. 45

58 Kapitel 3. Praxisteil A B INVITE 100 Trying 180 Ringing CANCEL 200 OK 487 Terminated ACK I 1 C 1 C 2 I 2 I 3 I 1 : InviteEvent C 1 : CancelEvent C 2 : CancelEvent (with final response) I 2 : InviteEvent (with final response and CANCEL flag) I 3 : InviteEvent (with final response, CANCEL flag and ACK flag) Abbildung 3.19.: Das Sequenzdiagramm zeigt die Erzeugung von Events am Beispiel des Abbruchs eines Verbindungsaufbaus. 46

59 3.4. Softwarearchitektur next [ caller ] iterate through SbaEventMap sleep some seconds no more [ caller in ] SbaEventMap get SbaEventDeque analyze call attemps analyze calls concurrent [ loop ] stop [ requested ] analyze call duration average analyze calls duration cumulative analyze call completion analyze calls closed by callee Abbildung 3.20.: Aktivität des Threads SigBasedAna, Methode SigBasedAna:: worker(). Weitere Analysen als Aktivitätsdiagramme: call attempts (C.4), calls concurrent (C.5), call completion (C.6), call duration average (C.7), call duration cumulative (C.8), calls closed by callee (C.9) SigBasedAna Der Thread SigBasedAna führt signalisierungsbasierte Analysen durch. Die Grundlage der Analysen stellen die vom Thread SipProcessor erzeugten Ereignisobjekte (Abbildung C.2) dar, die in der SbaEventMap nach Caller gruppiert gespeichert sind. Analyseergebnisse werden in Form von Incident Objekten (Abbildung C.3) in der SbaIncidentMap gespeichert. Die Methode SigBasedAna::worker() führt für alle Caller die im Aktivitätsdiagramm (Abbildung 3.20) dargestellten Analysen durch. Alle Analysen werden über ein Zeitfenster ausgeführt, das beim Start der Analyse endet und eine in der Konfiguration einstellbare Ausdehnung besitzt. Die Fenstergröße wird individuell pro Analyse festgelegt. Aufeinanderfolgende Fenster einer Analyse besitzen eine starke Überlappung. Analyze Call Attempts Es werden alle InviteEvent Objekte mit finaler Antwort (200 OK oder andere Antwort > 200) gezählt, die kein reinvite Flag gesetzt haben. Bei Überschreitung des in der Konfiguration festgelegten Schwellwerts sba_call_attempts_ max wird ein Incident Objekt erzeugt und in der SbaIncidentMap in der Queue des 47

60 Kapitel 3. Praxisteil Callers gespeichert. Analyze Calls Concurrent Um das größte Vorkommen paralleler Anrufe eines Teilnehmers zu bestimmen, werden die Variablen call_counter, calls_concurrent sowie eine Liste zur Speicherung von Call-IDs laufender Verbindungen genutzt. Ein InviteEvent, das kein reinvite Flag, jedoch ein ACK Flag besitzt, erhöht den call_counter (neue aktive Verbindung). Die Call-ID wird in der Liste gespeichert. Wenn der call_counter größer als calls_concurrent ist, wird calls_concurrent gleich dem Wert von call_counter gesetzt. Ein ByeEvent ohne finale Antwort (initiale BYE Nachricht) erniedrigt den call_counter um eins, wenn es sich um eine laufende Verbindung handelt. Die Call-ID wird aus der Liste entfernt. Handelt es sich jedoch um eine bisher unbekannte Verbindung, wird die Variable calls_concurrent um 1 erhöht, da eine Verbindung beendet wird, deren Aufbau vor diesem Analysefenster liegt. Analyze Call Completion Es geht um das Verhältnis aufgebauter Verbindungen zu Verbindungsaufbauversuchen. Als Aufbauversuche werden InviteEvent Objekte gezählt, die keine finale Antwort (provisorische Antworten erzeugen kein Ereignis) besitzen. Eine Verbindung gilt als aufgebaut, wenn die finale Antwort 200 OK ist und der Aufbauende dieses OK mit einer ACK Nachricht bestätigt hat. Ein dazu passendes InviteEvent Objekt besitzt den finalen Antwortcode 200 und das ACK Flag ist gesetzt. Ist das Verhältnis von aufgebauten Verbindungen zu Verbindungsversuchen geringer, als der in der Konfiguration angegebene minimale Wert (sba_call_completion_min), wird ein SbaIncident Objekt erzeugt und in der SbaIncidentMap dem Caller angehangen. Die Berechnung wird nur bei ausreichender Zahl an Verbindungsversuchen (sba_call_ completion_attempts_min) ausgeführt. Analyze Call Duration Average Die durchschnittliche Verbindungsdauer berechnet sich aus der kumulierten Dauer aller erfolgreichen Verbindungen geteilt durch deren Anzahl. Die Dauer einer Verbindung ist in ByeEvent Objekten dieser Verbindung enthalten. Es werden nur die Objekte ohne finale Anwtwort (entspricht initialen BYE Nachrichten) zur Berechnung verwendet. Analyze Call Duration Cumulative Die Berechnung der kumulativen Verbindungsdauer wird wie bei der durchschnittlichen Verbindungsdauer mit Hilfe von ByeEvent Objekten ohne finale Antwort durchgeführt. Bei der Erzeugung eines ByeEvent Objekts wird bereits die Zeitdifferenz zwischen INVITE Nachricht und BYE Nachricht gespeichert, so dass diese lediglich zu addieren sind. 48

61 3.4. Softwarearchitektur Analyze Calls Closed by Callee Das Verhältnis der Verbindungsbeendigungen durch den Anrufer zur Gesamtzahl der erfolgreichen Verbindungen wird berechnet, indem die initialen BYE Nachrichten (ohne finale Antwort) verarbeitet werden. Das ByeEvent Objekt enthält das FROM-Tag aus dem Header der SIP-Nachricht der verbindungsaufbauenden INVITE Transaktion. Ist dieses nicht identisch mit dem FROM-Tag des Headers der BYE Nachricht, handelt es sich um den Angerufenen, der die Verbindung beendet. 49

62 Kapitel 3. Praxisteil G711Decoder AudioDecoderInterface GsmDecoder * 1 AudioDecoderMap... PcmAudioQueue... 1 *... AudioHandler... RtpPacketDeque... PcmAudio CallDecodeQueue RtpSink Audio Decoding and Output 1 1 * * * 1... MemChunk... Call LocalRtpSinkMap... SIP/SDP Processing Abbildung 3.21.: Klassendiagramm AudioHandler (Übersicht), vollständige Beschreibungen der Klassen: Call (B.3), RtpSink (B.4), AudioHandler (D.1), AudioDecoderInterface & G711Decoder & GsmDecoder (D.3), PcmAudio & MemChunk (D.2) AudioHandler Der AudioHandler entnimmt Call Objekte aus der CallDecodeQueue, decodiert die enthaltenen Audiodaten und speichert diese zur Weiterverarbeitung durch den Output- Handler in der PcmAudioQueue (Abbildung 3.2, Seite 24). Das Klassendiagramm in Abbildung 3.21 zeigt eine Übersicht über die im Thread AudioHandler verwendeten Objekte. Die Methode AudioHandler::worker() stellt den Thread dar. Die RtpPacketDeque enthält alle Pakete eines RTP-Paketstroms und ist Bestandteil der Klasse RtpSink. Pro bidirektionaler Audioverbindung existieren zwei solcher Objekte, mehrere Audioverbindungen (uni- oder bidirektional) können vorhanden sein. Alle RtpSink Objekte eines Anrufs sind in der LocalRtpSinkMap des Call Objekts hinterlegt. Der AudioHandler enthält eine Map, in der Verweise auf Audiodecoder Objekte anhand des RTP-Payload Typs hinterlegt sind. Es wurden die beiden Audiodecoder G711Decoder und GsmDecoder aus [Mai10] übernommen, das AudioDecoderInterface wurde angepasst. Decodierte Audiodaten werden in Segmenten (MemChunk Objekte) als 16-Bit- Integer-Werte gespeichert (16 Bit PCM Samples, 8 khz Abtastrate), die Teil der PcmAudio Klasse sind. Die Größe der Segmente lässt sich über die Konfiguration mit dem Parameter mem_chunk_size einstellen. 50

63 3.4. Softwarearchitektur [ else ] RtpSink [ available ] get RtpPacketDeque from RtpSink create MemChunk object push MemChunk into PcmAudio object create PcmAudio object decode RTP payload and add PCM data into MemChunk not enough [ free space ] get Call from CallDecodeQueue get RtpSink from RtpSinkMap create MemChunk object space [ available ] get RtpSinkMap from Call get TlayerPacket from RtpPacketDeque [ loop ] [ else ] Call [ available ] declare OutBufSize in MemChunk stop [ requested ] push PcmAudio into PcmAudioQueue get AudioDecoder and OutBufSize push MemChunk into PcmAudio object [ else ] TlayerPacket [ available ] get RTP payload type and data from TlayerPacket Abbildung 3.22.: Aktivität des Threads AudioHandler, Methode AudioHandler:: worker() 51

64 Kapitel 3. Praxisteil Der Ablauf der Methode AudioHandler::worker() ist in Abbildung 3.22 als Aktivitätsdiagramm dargestellt: Es wird ein Call Objekt aus der CallDecodeQueue entnommen. Aus diesem werden alle RtpSink Objekte verarbeitet. Die RtpPacketDeque wird aus dem RtpSink entnommen und ein PcmAudio Objekt sowie ein MemChunk Objekt werden erstellt. Danach wird in einer Schleife jedes einzelne RTP-Paket der RtpPacketDequeue verarbeitet. Da sich die Audiocodierung innerhalb des RTP-Stroms ändern kann, wird der Payload-Typ des Pakets ausgelesen. Danach wird überprüft, ob das MemChunk Objekt über genügend Platz verfügt, um die decodierten Audiodaten dieses Pakets aufzunehmen. Die nötige Größe wird vom entsprechenden Audiodecoder ausgelesen und für das Anmelden der Daten im MemChunk Objekt mittels MemChunk::declare(size_t size, void** buffer) genutzt. Steht genügend Platz zur Verfügung, wird die Methode Audiodecoder::decode(void* inbuf, void* outbuf) mit einem Zeiger auf die Nutzdaten des RTP-Pakets und einem Zeiger auf die mit declare() ermittelte Stelle im MemChunk Objekt, an welche die Audiodaten geschrieben werden, aufgerufen. Ist nicht ausreichend Platz vorhanden, wird das bisherige MemChunk Objekt an das PcmAudio Objekt übergeben und ein neues erzeugt. Dieses Vorgehen ermöglicht den schnellen und direkten Zugriff auf den Speicher, wobei die Verwaltung des Speichers durch das MemChunk Objekt erfolgt. 52

65 3.4. Softwarearchitektur OutputHandler Der Thread OutputHandler dient der Ausgabe der Audiodaten. Es wird eine Dateischnittstelle zur Ausgabe als Wave-Datei sowie eine Socketschnittstelle zum Feature Extractor implementiert. In Abbildung 3.23 ist der Ablauf der Methode Outputhandler::worker() als Aktivitätsdiagramm dargestellt. Die Definition der Klasse OutputHandler befindet sich im Anhang, siehe Abbildung E.1. Der OutputHandler entnimmt die vom AudioHandler erzeugten PcmAudio Objekte aus der PcmAudioQueue. Für jedes Objekt wird mit Hilfe einer Instanz der Klasse ViatDb (Abbildung E.3) ein Eintrag in der VIAT Datenbank (Tabellen caller, call) vorgenommen. Die von der Datenbank erzeugte Call-ID wird für die weitere Verarbeitung der Daten im VIAT-System (Feature Extractor, Index Daemon) zur Identifikation genutzt. In der Konfiguration können über die Parameter use_wavefile_output_interface und use_socket_output_interface die zu verwendenden Ausgabeschnittstellen gewählt werden. Das PcmAudio Objekt enthält einen Container, der die PCM-Daten in MemChunk Objekten enthält. Wave-File Zur Ausgabe als Wave-File wird ein Objekt der Klasse WaveFileWriter erstellt. Die Inhalte aller MemChunk Objekte werden diesem Objekt übergeben. Der WaveFileWriter erstellt und beschreibt zuerst eine temporäre Datei. Der Destruktor benennt diese danach in <DB-Call-ID>.wav um. Sollte eine Datei mit dieser Datenbank-Call-ID bereits bestehen, wird eine Fehlermeldung im Logfile ausgegeben. Die temporäre Datei wird nicht gelöscht. Die Klasse WaveFileWriter ist von der Klasse RawFileWriter abgeleitet, die das Interface FileWriterInterface implementiert, siehe Abbildung E.2. Eine Instanz der Klasse RawFileWriter schreibt die Daten ohne Header. Der Konstruktor der Klasse WaveFile- Writer schreibt zu Anfang einen Dummy RIFF-WAVE-Header, den der Destruktor mit den zum Zeitpunkts seiner Ausführung bekannten Daten (Chunk Größe) überschreibt. Dieses Vorgehen macht das Kopieren der bis dahin geschriebenen Daten zum Anhängen des Headers überflüssig. Socket Zur Anbindung des Feature Extractor Prozesses wird eine TCP-Verbindung aufgebaut. Der Feature Extractor bindet beim Start einen Socket, an den die PCM-Daten gesendet werden. Die TCP-Verbindung wird geprüft, gegebenenfalls aufgebaut und bleibt bestehen nach der Übertragung der PCM-Daten bestehen. Zur Synchronisation wird ein einfaches Protokoll verwendet. Zuerst wird eine Startsequenz, bestehend aus vier 16-Bit-Werten gesendet. Danach wird die DB-Call-ID gesendet und dann werden die PCM-Daten der ein einzelnen MemChunk Objekte übertragen. Zum Abschluss wird eine 53

66 Kapitel 3. Praxisteil push PCM data to file insert call record into VIAT database Wave File [ output ] get MemChunkDeque from PcmAudio create WaveFileWriter get PcmAudio from PcmAudioQueue PcmAudio [ available ] config [ no wavefile ] output get MemChunk from MemChunkDeque [ else ] MemChunk [ available ] write PCM data to wavefile get MemChunk from MemChunkDeque [ loop ] [ else ] push PCM data to socket Socket [ output ] get MemChunkDeque from PcmAudio check connection Feature Extractor socket stop [ requested ] config [ no socket ] output write database call id to socket write start sequence to socket get MemChunk from MemChunkDeque write PCM data to socket MemChunk [ available ] get MemChunk from MemChunkDeque [ else ] write end sequence to socket Abbildung 3.23.: Aktivität des Threads OutputHandler, Methode OutputHandler:: worker() 54

67 3.4. Softwarearchitektur Endesequenz gesendet, die wie die Startsequenz aus vier 16-Bit-Werten besteht. Die Socket-Schnittstelle wurde bereits in Abschnitt auf Seite 25 erläutert. 55

68 loop TempCallQueue Kapitel 3. Praxisteil get lock CallMap make snapshot of CallMap unlock CallMap stop [ requested ] main loop sleep some milliseconds create TempCallQueue [ loop ] unlock Call no Call [ object left ] no Call [ object left ] next [ Call ] loop CallMap snapshot [ OK ] get lock Call [ OK ] recording_time [ exceeded ] deactivate all RtpSink objects in Call object delete Call from CallMap max_call [ rtp_inactivity ] exceeded push Call object into TempCallQueue push Call object into CallDecodeQueue get Call object from TempCallQueue [ OK ] [ OK ] max_call_age [ exceeded ] push Call object into TempCallQueue Abbildung 3.24.: Aktivität des Threads Watchdog, Methode Watchdog::worker() Watchdog Der Thread Watchdog dient zur Umsetzung der Vorgabe der maximalen Anrufaufnahmedauer und räumt ungültig gewordene Call Objekte auf. Objekte können bei fehlerhafter Signalisierung, beispielsweise durch Paketverlust, ungültig werden. In Abbildung 3.24 ist das Aktivitätsdiagramm der Methode Watchdog::worker() dargestellt, die als Thread gestartet wird. Da eine Schleife über alle Call Objekte der CallMap ausgeführt werden muss, wird die gesamte Prozedur vom Watchdog in die CallMap ausgelagert. Hier kann der Mutex gesperrt werden, um mit dem gesamten Call-Container zu arbeiten. Um Sperre nicht zu lange zu halten, wird ein Snapshot der CallMap erstellt. Dies ist effizient möglich, da die CallMap Shared-Pointer auf die eigentlichen Call Objekte enthält. Diese werden dabei in eine neue Map kopiert. Zusätzlich wird eine temporäre Queue (TempCallQueue) angelegt, in die alle Call Referenzen kopiert werden, die nach dem Durchlauf zum Decodieren in die CallDecodeQueue weitergereicht werden. 56

69 3.4. Softwarearchitektur Eine Schleife über alle Call Objekte führt folgende Aktionen aus: Überprüfen der Aufnahmedauer In der Konfigurationsdatei ist mit dem Parameter recording_time die maximale Aufnahmedauer angegeben. Dieser Wert wird mit dem Alter des Call Objekts verglichen. Ist der Call älter als die maximale Aufnahmezeit, werden alle darin enthaltenen RtpSink Objkete deaktiviert. Ab diesem Zeitpunkt werden keine RTP- Pakete mehr von den RtpSink Objekten angenommen. Überprüfen der RTP-Inaktivität Objekte der Klasse RtpSink registrieren, ob ein RTP-Strom existiert. Wird der in der Konfiguration angegebene Wert für maximale RTP-Inaktivität (max_call_ rtp_inactivity) überschritten, wird die Referenz auf das Call Objekt in die TempCallQueue kopiert. Dabei wird die minimale RTP-Inaktivität aller dem Call zugeordneten RtpSink Objekte herangezogen. Überprüfen des Call Objekt Alters In der Konfiguration ist das maximale Alter eines Call Objekts angegeben. Es wird überprüft, ob das Alter des aktuellen Call Objekts diesen Wert überschreitet. Ist das der Fall, wird eine Referenz auf dieses Call Objekt in die TempCallQueue kopiert. Für alle Objektreferenzen in der TempCallQueue wird folgendes durchgeführt: 1. Löschen der Call Referenz aus der CallMap. 2. Kopieren der Call Referenz in die CallDecodeQueue. Danach startet die Prozedur von vorne, es sei denn der Thread hat einen Stop-Request erhalten. 57

70 session Kapitel 3. Praxisteil create TcpServer object create Session object create CommandServer object wait for connection or stop request disconnect all sessions stop [ requested ] async accept [ connected] read user data request [ help ] write help message [ else ] request [ status ] get information about queues and maps write status message [ else ] request [... ] get information write message [ else ] request [ quit exit ] Abbildung 3.25.: Aktivität des Threads Console, Methode Console::worker() Console Der Thread Console dient dazu Informationen über das System abzurufen. Es werden nur Verbindungen auf Localhost zugelassen. Der TCP-Port lässt sich in der Konfiguration mit dem Parameter console_port festlegen. Es wird kein spezielles Verbindungsprotokoll oberhalb von TCP genutzt. Die Verbindung ist mit einem Telnet-Client möglich. Die Konsole basiert auf der Bibliothek Boost Asio. Das Klassendiagramm im Anhang (Abbildung F.1) zeigt die Definitionen und den Zusammenhang zwischen den hier besprochenen Klassen. Die Methode Console::worker() wird als Thread gestartet. Darin wird ein TcpServer Objekt erzeugt, das wiederum ein Session Objekt erzeugt. Das CommandServer Objekt ist Teil des Session Objekts. Es wird auf eine eingehende Verbindung gewartet. Nach einem Verbindungsaufbau wird wiederum ein Session Objekt erstellt und auf eine weitere, neue Verbindung gewartet. 58

71 3.4. Softwarearchitektur Innerhalb einer bestehenden Session kann der Benutzer Befehle übertragen, auf die das System entsprechend reagiert. Folgende Kommandos werden unterstützt: help Zeigt die Befehlsreferenz an. status Es wird eine Übersicht über den Füllstand aller gemeinsamen Datenspeicher ausgegeben. Außerdem wird die Anzahl der aufgetretenen RTP Sequenznummer Fehler angezeigt. CallMap Zeigt alle momentan vorhandenen Call Objekte an, die als Referenz in der Call- Map existieren. SbaEventMap Es werden alle in der SbaEventMap vorhandenen SbaEvent Objekte angezeigt. SbaIncidentMap Alle SbaIncidents werden ausgegeben. ClearSba Alle Elemente der SbaEventMap sowie der SbaIncidentMap werden gelöscht. quit Die Konsole wird beendet. Das Session Objekt nimmt die an den Socket gesendeten Daten entgegen und führt die entsprechenden Methoden des CommandServer Objekts aus. Die Rückgabewerte werden über den Socket zurück an den anfragenden Client gesendet. Einige Anfragen verlangen die Iteration über alle Objekte eines Containers. Wie bereits in Kapitel dargestellt, ist dies nur durch container-eigene Methoden möglich, da die ThreadFriendlyMap bzw. ThreadFriendlyQueue Schnittstelle aus den bereits dort genannten Gründen keinen Iterator nach außen durchreicht. Daher wurden den betroffenen Containern (CallMap, SbaEventMap und SbaIncidentMap) entsprechende Methoden hinzugefügt. 59

72

73 Kapitel 4. Softwaretest Call Flow Asterisk A SIPp Network SIP Proxy (Kamailio) Asterisk B asta-d Copy of Network Stream ser-d astb-d callx II extract-d Abbildung 4.1.: Aufbau der Testumgebung 4.1. Testumgebung Der Aufbau der Testumgebung ist in Abbildung 4.1 dargestellt. Dabei handelt es sich um einen Teil des VIAT-Prototyps. Es sind vier Debian 6 Systeme beteiligt. Direkt am Call Flow beteiligt sind die Systeme asta-d6, astb-d6 sowie ser-d6. Das System asta-d6 ist für die Call Generierung zuständig. Ein Asterisk Server (Asterisk A) wird zusammen mit dem Call Generator aus [Len10] für den Test der Audioverarbeitung eingesetzt. Die Call Erzeugung für die Tests der signalisierungsbasierten Verarbeitung wird mit der speziell für den Test von SIP-Endgeräten und Servern entwickelten Anwendung SIPp 1 durchgeführt. Die Terminierung der Anrufe übernimmt Asterisk B auf dem System astbd6. Beide Asterisk Systeme haben die Version Im Signalisierungsverlauf ist das System ser-d6 eingebunden, auf dem der SIP Proxy Kamailio (Version 3.1.4) installiert wurde. Die hier entwickelte und zu testende Anwendung callx ii wird auf dem System extract-d6 ausgeführt. 1 (Version 3.3) 61

74 Kapitel 4. Softwaretest Alle Systeme sind auf XEN Servern virtualisiert. Die virtuellen Maschinen asta-d6 und extract-d6 befinden auf dem gleichen XEN Server. Beide sind über die gleiche Netzwerkbrücke xenbr1 angebunden. Mittels brctl setageing xenbr1 0 wurde die Ageing Time auf Null gesetzt, so dass xenbr1 wie ein Hub arbeitet. Damit liegen an der Netzwerkschnittstelle des Systems extract-d6 die gleichen Daten an, wie an der Netzwerkschnittstelle des Anruf-generierenden Systems asta-d6. Dies ist vergleichbar mit einem Monitoring-Port eines Swichtes. Die hier gewählte Lösung bot für den Aufbau und die Erweiterung des VIAT-Prototyps eine höhere Flexibilität. Der Test der Software unterteilt sich in die beiden Abschnitte Signalisierungsverarbeitung und Audioverarbeitung Signalisierungsverarbeitung SIPp Testszenario Zum Testen der Signalisierungsverarbeitung wird SIPp verwendet. Es wurde ein flexibles SIPp Szenario erstellt (siehe Anhang G.2.1) und für alle signalisierungsbasierten Tests eingesetzt. Es beherrscht vier verschiedene Verbindungsvarianten: 1. Verbindung aufbauen und warten bis die Gegenstelle die Verbindung beendet. 2. Verbindung aufbauen, warten, Verbindung beenden. 3. Verbindungsversuch senden und danach den Verbindungsversuch abbrechen. 4. Verbindungsversuch senden und negative Antwort der Gegenstelle empfangen. Das Szenario wird über Aufrufparameter sowie über eine Datendatei im CSV-Format parametrisiert. Die Datendatei enthält in der ersten Zeile entweder den Wert SEQUEN- TIAL für die sequenzielle Verarbeitung der folgenden Datenzeilen, den Wert RANDOM für die zufällige Auswahl der zu nutzenden Datenzeile(n), oder den Wert USER zur Angabe von Anmeldeinformationen, sofern dies im Szenario vorgesehen ist. Danach folgen eine oder mehrere Datenzeilen, die aus den folgenden per Semikolon getrennten Werten bestehen: 1. <local user> 2. <local displayname> 62

75 4.2. Signalisierungsverarbeitung 3. <remote user> 4. <remote displayname> 5. <remote ip> 6. <remote port> 7. <hangup [ms]> <cancel> Jede Zeile enthält Daten für einen Verbindungsaufbau. Der letzte Parameter einer Zeile legt die Art des Anrufs fest. Von den vier zuvor aufgezählten Verbindungsvarianten lassen sich die ersten drei über diesen letzten Wert einer Datenzeile steuern. Ist der Wert 0, wartet SIPp auf das Auflegen der Gegenseite. Ein Wert größer 0 wird als die Anzahl Millisekunden interpretiert, die SIPp warten soll, um den Anruf selber zu beenden. Handelt es sich um die Zeichenkette cancel, startet SIPp einen Verbindungsaufbau, wartet auf die erste provisorische Antwort und bricht den Verbindungsaufbau danach ab. Bei der vierten Variante lehnt die Gegenstelle die Verbindung ab. Ein Beispiel inklusive Erläuterungen ist im Anhang G.2.2 dargestellt. Anhand des folgenden Beispiel-Kommandos werden die Aufrufparameter von SIPp erläutert: sipp -r 5 -l 10 -m 50 -sf callx-test.xml -inf example.csv ser-d6 In diesem Beispiel werden maximal 5 Calls pro Sekunde aufgebaut (Parameter r). Die Anzahl gleichzeitiger Calls ist 10 (Parameter l). Die gesamte Anzahl zu erzeugender Calls beträgt 50 (Parameter m). Die XML Datei callx-test.xml beschreibt das Szenario. ser-d6 ist die Adresse des SIP-Services (DNS-Name oder IP-Adresse), mit dem auf Netzwerkebene kommuniziert wird. In diesem Fall handelt es sich um einen SIP Proxy. Es kann auch direkt die Adresse des User Agent angegeben werden, mit dem die SIP- Verbindungen aufgebaut werden sollen. Wenn kein vermittelnder SIP-Server genutzt wird, muss diese Adresse mit den Adressinformationen der CSV Datei (<remote ip>, <remote port>) übereinstimmen. Wenn eine größere Anzahl Verbindungen aufgebaut werden sollen, als Zeilen in der Eingabedatei vorhanden sind, wird beim sequentiellen Lesen nach Verwendung der letzten Zeile mit der ersten Zeile fortgefahren. Da SIPp selbständig eindeutige Call IDs erzeugt, kann schon mit einer einzigen Datenzeile ein hohes Verkehrsaufkommen simuliert werden. 63

76 Kapitel 4. Softwaretest Dateien und Verzeichnisse Testsystem und Heft-DVD Auf dem System asta-d6 befindet sich im Heimatverzeichnis des Users viat das Verzeichnis sipp-3.3/scenario. Darin befinden sich alle nachfolgend genannten Dateien und Verzeichnisse. Das Verzeichnis scenario befindet sich in Kopie auf der Heft-DVD im Verzeichnis /Softwaretest/SIPp/. Szenario Dateien Das für die folgenden Tests verwendete SIPp Szenario wurde in der Datei callx-test.xml definiert. Pro Testfall existiert ein Verzeichnis mit dem Namen test-<x>.<y>. Darin ist ein Bash Skript do-test-<x>.<y>.sh zum Starten des Szenarios enthalten. Außerdem befindet sich dort die für das Szenario benötigte Datendatei input-<x>.<y>.csv. SIPp Logdateien Im aktuellen Testfall-Verzeichnis erzeugt SIPp eine Logdatei callxtest_<pid>_messages.log, die alle gesendeten und empfangenen SIP-Nachrichten enthält. Eine weitere Logdatei callx-test_<pid>_screen.log enthält den finalen Scenario Screen sowie den Statistics Screen. Die letztgenannte Logdatei wird immer im Verzeichnis des XML Scenarios erstellt, das jedoch eine Verzeichnisebene höher liegt. Um dies zu umgehen, erzeugt das Bash Skript vor dem Aufruf von SIPp einen symbolischen Link der Szenario Datei im aktuellen Testfall Verzeichnis. Seit dem Jahr 2010 existiert ein Patch zur Angabe des Zielverzeichnisses ([Kvi10]), der jedoch in der hier genutzten Version 3.3 nicht enthalten ist. callx II Logdatei Nach jedem Testlauf wird die callx ii Logdatei (callx.log) in das Test-Verzeichnis kopiert. Da diese Datei sehr detaillierte Informationen zum Ablauf enthält, wurden diverse Filterskripte entwickelt. Diese liegen in den jeweiligen Testfall- Verzeichnissen und setzen voraus, dass sich die callx ii Logdatei mit dem Namen callx.log im gleichen Verzeichnis befindet. Die Dateinamen dieser Skripte haben den Aufbau show_<what>.sh. callx II Konsole Relevante Ausgaben der callx ii Konsole werden in Dateien mit den Namen callx-console_<command>.log gespeichert. <command> ist der für die Ausgabe verantwortliche Konsolen Befehl Durchführung der Tests 1. asta-d6: Wechsel in das Verzeichnis des Testfalls test-<x>.<y> 64

77 4.2. Signalisierungsverarbeitung 2. extract-d6: callx ii wird - sofern es bereits läuft - neu gestartet, damit das Logfile sowie die Datenspeicher SbaEventMap und SbaIncidentMap keine Einträge enthalten. 3. asta-d6: Das Skript do-test-<x>.<y>.sh wird ausgeführt und auf Beendigung gewartet. SIPp zeigt während dessen den Scenario Screen mit aktuellen Werten an. 4. extract-d6: Mit dem Befehl telnet wird die Verbindung zur Konsole aufgebaut, um relevante Daten ausgeben zu lassen (der entsprechende Befehl wird im eigentlichen Testfall erläutert) und um diese in die Datei callxconsole_<command>.log zu kopieren. 5. asta-d6, Auswertung: Die Erwartungen werden je nach Testfall mit den tatsächlichen Werten des SIPp Scenario Screen, mit den Ausgaben der Skripte zur Filterung der callx ii Logdatei, mit dem SIPp Message Log und mit der Ausgabe der callx ii Konsole verglichen. Genauere Angaben dazu befinden in den einzelnen Testfall-Abschnitten Anpassungen an Asterisk B Für die signalisierungsbasierten Tests wird der Konfigurationsdatei extensions.conf des Asterisk B der nachfolgende Abschnitt hinzugefügt. Mit der Definition dieser sogenannten Extensions wird unterschiedliches Callee Verhalten simuliert: ; Anruf nicht annehmen. Astersik sendet "603 Decline". exten => 1000,1,NoOp() ; Anruf annehmen, 3 Sekunden warten, auflegen. exten => 1003,1,Answer() exten => 1003,n,wait(3) exten => 1003,n,Hangup() ; Anruf annehmen, 5 Sekunden warten, auflegen. exten => 1005,1,Answer() exten => 1005,n,wait(5) exten => 1005,n,Hangup() ; Anruf annehmen, 7 Sekunden warten, auflegen. exten => 1007,1,Answer() exten => 1007,n,wait(7) exten => 1007,n,Hangup() ; Anruf annehmen, 10 Sekunden warten, auflegen. exten => 1010,1,Answer() exten => 1010,n,wait(10) exten => 1010,n,Hangup() ; Anruf annehmen, 60 Sekunden warten, auflegen. 65

78 Kapitel 4. Softwaretest exten => 1060,1,Answer() exten => 1060,n,wait(60) exten => 1060,n,Hangup() ; Eine Sekunden warten, Anruf annehmen, 60 Sekunden warten, auflegen. ; Durch die Waretzeit vor dem Annehmen des Anrufs ist es dem Caller ; möglich den Verbindungsaufbau mittels CANCEL abzubrechen (CANCEL ; muss vor der finalen Antwort auf den Request gesendet werden). exten => 1100,1,wait(1) exten => 1100,n,Answer() exten => 1100,n,wait(60) exten => 1100,n,Hangup() Zweiteilung der Tests der Signalisierungsverarbeitung Der Test der Signalisierungsverarbeitung gliedert sich in zwei Bereiche: 1. Beschaffung und Verarbeitung von Signalisierungsinformationen Dabei bezeichnet Beschaffung die Extraktion und das Parsen von SIP-Nachrichten. Die Verarbeitung der gewonnenen Signalisierungsinformationen findet im SIP- Stack statt, der damit Transaktionen und Dialoge verwaltet. Beides lässt sich anhand der callx ii Logdatei nachvollziehen und überprüfen. Weiterhin erzeugt der SIP-Stack Signalisierungsereignisse in Form von SbaEvent Objekten. Über die callx ii Konsole lassen sich die erzeugten Objekte anzeigen und auf Richtigkeit überprüfen. 2. Signalisierungsbasierte Analyse Die Algorithmen der Signalisierungsanalyse verarbeiten SbaEvent Objekte und erzeugen bei Schwellwertüberschreitungen SbaIncident Objekte. Diese lassen sich zur Überprüfung über die callx ii Konsole anzeigen Test-1: Beschaffung und Verarbeitung von Signalisierungsinformationen In diesem Abschnitt werden die folgenden Tests durchgeführt: 1.1 Verbindungsauf- und Abbau 1.2 Abgelehnter Verbindungsaufbau 1.3a Abgebrochener Verbindungsaufbau (mit Proxy) 1.3b Abgebrochener Verbindungsaufbau (ohne Proxy) 66

79 4.2. Signalisierungsverarbeitung Test 1.1: Verbindungsauf- und Abbau Für den ersten Test wird eine einzelne Verbindung zum Asterisk B Teilnehmer 1005 aufgebaut. Asterisk B nimmt den Anruf entgegen, wartet 5 Sekunden und baut die Verbindung ab. Im Verzeichnis test-1.1 wird das Skript do-test-1.1.sh ausgeführt. Die für diesen Testfall verwendete Datendatei input-1.1.csv enthält folgenden Inhalt: SEQUENTIAL SIPp;test-1.1;1005;astb; ;5060;0 Nachfolgend der zugehörige SIPp Scenario Screen (callx-test_6404_screen.log): Scenario Screen [1-9]: Change Screen -- Timestamp: Mon Mar 18 03:37: Call-rate(length) Port Total-time Total-calls Remote-host 10.0(0 ms)/1.000s s :5060(UDP) Call limit reached (-m 1), s period 0 ms scheduler resolution 0 calls (limit 1) Peak was 1 calls, after 0 s 0 Running, 2 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE > < < < < ACK > 1 0 BYE < > 1 0 Pause [ $hangup] 0 0 BYE > < CANCEL > < < < ACK > Waiting for active calls to end. Press [q] again to force exit Es ist ein erfolgreicher Auf- und Abbau einer Verbindung zu erkennen. Es wird eine INVITE Nachricht gesendet, daraufhin wird eine provisorische 100 Trying Antwort sowie eine finale 200 OK Antwort empfangen. Der SIP-3-Wege Handshake wird mit der nachfolgenden ACK Nachricht abgeschlossen. Danach legt Asterisk B durch Senden einer BYE Nachricht auf, was von SIPp mit 200 OK beantwortet wird. Da das SIPp Szenario für verschiedene Tests ausgelegt ist, sind weitere Nachrichten-Zeilen vorhanden, die jedoch hier keine Rolle spielen. Die Anzahl der Nachrichten in der Spalte Messages ist bei diesen Zeilen 0. 67

80 Kapitel 4. Softwaretest Im Folgenden werden die Ausgaben des SIP- und SDP-Parsers (Methode SipPacket:: parse()) überprüft. Die Ausgaben sind in der callx ii Logdatei zu finden. Eine Übersicht wird durch das herausfiltern der SIP Start Lines erzeugt. Dazu wird im Verzeichnis test-1.1 das Bash-Skript show_sip-parser_start-lines.sh gestartet, das die folgende Ausgabe generiert: #./show_sip-parser_start-lines.sh [../src/sip/sippacket.cpp:89] INVITE SIP/2.0 [../src/sip/sippacket.cpp:89] SIP/ trying -- your call is important to us [../src/sip/sippacket.cpp:89] SIP/ OK [../src/sip/sippacket.cpp:89] ACK SIP/2.0 [../src/sip/sippacket.cpp:89] BYE SIP/2.0 [../src/sip/sippacket.cpp:89] SIP/ OK Die Ausgabe entspricht den Informationen des SIPp Scenario Screen. Es wurden alle SIP-Nachrichten erkannt. Sämtliche Ausgaben des Parsers lassen sich durch Ausführung des Skripts show_sipparser_messages.sh ausgeben: #./show_sip-parser_messages.sh [../src/sip/sippacket.cpp:89] INVITE SIP/2.0 [../src/sip/sippacket.cpp:101] Request, method: INVITE [../src/sip/sippacket.cpp:184] From: test-1.1 [../src/sip/sippacket.cpp:205] To: astb [../src/sip/sippacket.cpp:224] Call ID: [../src/sip/sippacket.cpp:243] CSeq fields: 1 INVITE [../src/sip/sippacket.cpp:268] Branch: z9hg4bk [../src/sip/sippacket.cpp:324] SDP socket address: :6000 UDP [../src/sip/sippacket.cpp:89] SIP/ trying -- your call is important to us [../src/sip/sippacket.cpp:117] Response, status: 100 trying -- your call is important to us [../src/sip/sippacket.cpp:184] From: test-1.1 <sip:sipp@ :5061>;tag= [../src/sip/sippacket.cpp:205] To: astb <sip:1005@ :5060> [../src/sip/sippacket.cpp:224] Call ID: @ [../src/sip/sippacket.cpp:243] CSeq fields: 1 INVITE [../src/sip/sippacket.cpp:268] Branch: z9hg4bk [../src/sip/sippacket.cpp:89] SIP/ OK [../src/sip/sippacket.cpp:117] Response, status: 200 OK [../src/sip/sippacket.cpp:184] From: test-1.1 <sip:sipp@ :5061>;tag= [../src/sip/sippacket.cpp:205] To: astb <sip:1005@ :5060>;tag=as799836df [../src/sip/sippacket.cpp:224] Call ID: @ [../src/sip/sippacket.cpp:243] CSeq fields: 1 INVITE [../src/sip/sippacket.cpp:268] Branch: z9hg4bk [../src/sip/sippacket.cpp:324] SDP socket address: :14180 UDP [../src/sip/sippacket.cpp:89] ACK sip:1005@ :5060 SIP/2.0 [../src/sip/sippacket.cpp:101] Request, method: ACK [../src/sip/sippacket.cpp:184] From: test-1.1 <sip:sipp@ :5061>;tag= [../src/sip/sippacket.cpp:205] To: astb <sip:1005@ :5060>;tag=as799836df [../src/sip/sippacket.cpp:224] Call ID: @ [../src/sip/sippacket.cpp:243] CSeq fields: 1 ACK [../src/sip/sippacket.cpp:268] Branch: z9hg4bk [../src/sip/sippacket.cpp:89] BYE sip:sipp@ :5061;transport=udp SIP/2.0 [../src/sip/sippacket.cpp:101] Request, method: BYE [../src/sip/sippacket.cpp:184] From: astb <sip:1005@ :5060>;tag=as799836df [../src/sip/sippacket.cpp:205] To: test-1.1 <sip:sipp@ :5061>;tag= [../src/sip/sippacket.cpp:224] Call ID: @

81 4.2. Signalisierungsverarbeitung [../src/sip/sippacket.cpp:243] CSeq fields: 102 BYE [../src/sip/sippacket.cpp:268] Branch: z9hg4bk49a3.3b9a825.0 [../src/sip/sippacket.cpp:89] SIP/ OK [../src/sip/sippacket.cpp:117] Response, status: 200 OK [../src/sip/sippacket.cpp:184] From: astb [../src/sip/sippacket.cpp:205] To: test-1.1 [../src/sip/sippacket.cpp:224] Call ID: [../src/sip/sippacket.cpp:243] CSeq fields: 102 BYE [../src/sip/sippacket.cpp:268] Branch: z9hg4bk49a3.3b9a825.0 Der SIP- und SDP-Parser geben nur die grundlegenden Informationen zu einer SIP- Nachricht aus. Die Ausgabe passt zu den detaillierteren Informationen der SIPp Logdatei callx-test_6404_messages.log, die hier aufgrund ihres Umfangs nicht abgedruckt wird. Die geparsten SIP-Nachrichten werden vom SIP-Stack verarbeitet. Die entsprechend gefilterte Logdatei (Ausgabe durch das Skript show_sip-stack.sh) zeigt die richtige Verarbeitung der eingehenden Nachrichten: #./show_sip-stack.sh [../src/sip/sipprocessor.cpp:26] C tor [../src/sip/sippacket.cpp:101] Request, method: INVITE [../src/sip/sipprocessor.cpp:100] Call not in CallMap. [../src/sip/sipprocessor.cpp:106] Request is INVITE [../src/sip/sipprocessor.cpp:111] Creating and inserting Call object into CallMap. [../src/sip/sipprocessor.cpp:113] Call ID: @ [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/sipprocessor.cpp:257] Handling INVITE request. [../src/sip/transaction.hpp:85] Changing state to (client / server): CALLING / PROCEEDING [../src/sip/sipprocessor.cpp:739] Processing Session Description. [../src/sip/sipprocessor.cpp:793] Inserting RtpSink Object into local and into global RtpSinkMap. [../src/sip/sipprocessor.cpp:796] Size of local RtpSinkMap is now: 1 [../src/sip/sippacket.cpp:117] Response, status: 100 trying -- your call is important to us [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): CALLING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): PROCEEDING / PROCEEDING [../src/sip/sippacket.cpp:117] Response, status: 200 OK [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): PROCEEDING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/sipprocessor.cpp:739] Processing Session Description. [../src/sip/sipprocessor.cpp:793] Inserting RtpSink Object into local and into global RtpSinkMap. [../src/sip/sipprocessor.cpp:796] Size of local RtpSinkMap is now: 2 [../src/sip/sippacket.cpp:101] Request, method: ACK [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/sipprocessor.cpp:459] Found the INVITE transaction to this ACK request. [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/transaction.hpp:40] D tor [../src/sip/transaction.hpp:40] D tor [../src/sip/sippacket.cpp:101] Request, method: BYE [../src/sip/sipprocessor.cpp:91] Found call in CallMap. 69

82 Kapitel 4. Softwaretest [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/transaction.hpp:85] Changing state to (client / server): TRYING / TRYING [../src/sip/sippacket.cpp:117] Response, status: 200 OK [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): TRYING / TRYING [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/sipprocessor.cpp:856] Call reference deleted from CallMap. [../src/sip/sipprocessor.cpp:858] Call ID: @ [../src/sip/transaction.hpp:40] D tor Die Ausgabe ist wie folgt zu interpretieren: Durch die initiale INVITE Nachricht wird ein neues Call Objekt erzeugt und im Container CallMap hinterlegt. Es wird ein Objekt vom Typ Transaction erzeugt und der kombinierte Status der Client- sowie Server- Transaktion auf CALLING / PROCEEDING gesetzt. Sämtliche Änderungen des kombinierten Transaktionsstatus wurden anhand der Transaktionsautomaten in Abbildung 3.15 nachvollzogen. Die INVITE Nachricht enthält außerdem einen Body mit Session-Informationen (SDP). Daraufhin wird ein RtpSink Objekt erzeugt und zur lokalen RtpSinkMap des Call Objekts sowie zur globalen RtpSinkMap hinzugefügt. Die Anzahl der dem Call Objekt zugeordneten RtpSink Objekte ist eins. Die beiden Antworten 100 trying und 200 OK werden dem Call Objekt und der laufenden INVITE Transaktion zugeordnet, wobei die finale 200 OK Antwort einen SIP-Body mit SDP Inhalt besitzt. Ein weiteres RtpSink Objekt wird erstellt. Die ACK Anfrage, die von SIPp versendet wird, kann dem Call Objekt zugeordnet werden, jedoch keiner laufenden Transaktion. Das ist richtig, denn bei positiver Antwort auf eine INVITE Anfrage, erfolgt die nachfolgende ACK Anfrage in einer eigenen, in sich abgeschlossenen Transaktion. Der Verbindungsabbau durch die BYE Anfrage und die daraufhin gesendete positive Antwort führen zum Löschen der Referenz auf das Call Objekt aus der CallMap. Bei der Verarbeitung durch den SIP-Stack werden SbaEvent Objekte erzeugt, die von der signalisierungsbasierten Analyse verarbeitet werden. In der Konsole können diese Objekte durch Eingabe des Befehls SbaEventMap oder des Shortcuts e ausgegeben werden. Die Ausgabe wurde in die Datei callx-console_sbaeventmap.log kopiert: callx> SbaEventMap Caller: sip:sipp@ :5061 Event Type: INVITE Call ID: @ Timestamp: Mon Mar 18 03:37: Initiator: sip:sipp@ :5061 Final rsponse: N/A flags [ack/reinvite/cancel]: 0/0/0 Event Type: INVITE Call ID: @ Timestamp: Mon Mar 18 03:37:

83 4.2. Signalisierungsverarbeitung Initiator: Final rsponse: 200 OK flags [ack/reinvite/cancel]: 0/0/0 Event Type: INVITE Call ID: Timestamp: Mon Mar 18 03:37: Initiator: Final rsponse: 200 OK flags [ack/reinvite/cancel]: 1/0/0 Event Type: BYE Call ID: Timestamp: Mon Mar 18 03:37: Initiator: Final rsponse: N/A Call duration: 0 minutes 5 seconds Event Type: BYE Call ID: @ Timestamp: Mon Mar 18 03:37: Initiator: sip:1005@ :5060 Final rsponse: 200 OK Call duration: 0 minutes 5 seconds Die erzeugten SbaEvent Objekte stimmen mit den Erwartungen überein. Das erste Objekt wurde durch die initiale INVITE Anfrage erzeugt (Event Type INVITE). Danach folgt ein Ereignis des gleichen Typs, jedoch ist hier die finale Antwort 200 OK vorhanden. Provisorische Antworten werden beim Erzeugen von Ereignissen nicht berücksichtigt, so dass die Statusantwort 100 trying (siehe Ausgabe der SIP-Start- Lines) hier nicht zu sehen ist. Der dritte Eintrag vom Typ INVITE besitzt zusätzlich ein ACK Flag. Man sieht, dass der 3-Wege Handshake INVITE OK - ACK erfolgreich erkannt wurde. Die beiden BYE Ereignisse spiegeln die BYE Anfrage sowie die finale Antwort darauf wider. BYE Ereignisse enthalten die Anrufdauer, hier 5 Sekunden. Diese stimmt mit der tatsächlichen Anrufdauer überein. Test 1.2: Abgelehnter Verbindungsaufbau Es wird ein Verbindungsversuch zu Asterisk B Teilnehmer 1000 unternommen. Asterisk B ist so konfiguriert, dass an diesen Teilnehmer gesendete Verbindungsanfragen mit der Antwort 603 Decline abgelehnt werden. Diese Variante einer abgelehnten INVITE Anfrage wurde beispielhaft für alle SIP-Antworten größer gleich 300 gewählt. Das Verhalten des User Agent Clients ist in diesem Falle immer gleich. Der 3-Wege Handshake wird mit einer ACK Anfrage abgeschlossen, die im Kontext der INVITE Transaktion gesendet wird. Wie im vorherigen Test 1.1 werden die Inhalte der von SIPp und callx ii erzeugten Logdateien sowie die Ausgaben der callx ii Konsole miteinander verglichen und bewertet. Zur Ausführung des Tests wird im Verzeichnis test-1.2 das Skript do-test-1.2.sh ausgeführt. Als Parametrisierung dieses Testfalls wird die Eingabedatei input-1.2.csv mit dem folgenden Inhalt verwendet: 71

84 Kapitel 4. Softwaretest SEQUENTIAL SIPp;test-1.2;1000;astb; ;5060;0 Der von SIPp erzeugte Scenario Screen (callx-test_6590_screen.log) zeigt folgendes: Scenario Screen [1-9]: Change Screen -- Timestamp: Mon Mar 18 03:45: Call-rate(length) Port Total-time Total-calls Remote-host 10.0(0 ms)/1.000s s :5060(UDP) Call limit reached (-m 1), s period 0 ms scheduler resolution 0 calls (limit 1) Peak was 1 calls, after 0 s 0 Running, 2 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE > < < < < ACK > 0 0 BYE < > 0 0 Pause [ $hangup] 0 0 BYE > < CANCEL > < < < ACK > Waiting for active calls to end. Press [q] again to force exit SIPp sendet eine eine INVITE Anfrage und empfängt daraufhin eine provisorische Anwort 100 sowie die verbindungsablehnende finale Antwort 603. Daraufhin sendet SIPp eine ACK Anfrage. Im Scenario Screen ist diese ACK Nachricht unten zu finden, da die Reihenfolge der Nachrichten von der Reihenfolge der Definitionen in der SIPp Scenario XML Datei abhängt. Es handelt sich nicht wie in Test 1.1 um die in sich abgeschlossene ACK Anfrage in Folge einer positiv beantworteten INVITE Anfrage, sondern um eine zur INVITE Transaktion gehörende Nachricht. Zu Überprüfung der Erkennung der Nachrichten durch den SIP-Parser werden die SIP- Start-Lines durch das Bash Skript show_sip-parser_start-lines.sh ausgegeben. Sie entsprechen den Nachrichten des Scenario Screens von SIPp: #./show_sip-parser_start-lines.sh [../src/sip/sippacket.cpp:89] INVITE sip:1000@ :5060 SIP/2.0 72

85 4.2. Signalisierungsverarbeitung [../src/sip/sippacket.cpp:89] SIP/ trying -- your call is important to us [../src/sip/sippacket.cpp:89] SIP/ Declined [../src/sip/sippacket.cpp:89] ACK SIP/2.0 Die vollständige Ausgabe des SIP-Parsers durch das Skript show_sip-parser_messages.sh wurde mit der SIPp Logdatei callx-test_6590_messages.log verglichen und entspricht den Erwartungen. Die Ausgabe ist mit der des Tests 1.1 vergleichbar und wird wegen des Umfangs hier nicht abgedruckt. Die Verarbeitung der SIP-Nachrichten durch den SIP-Stack wird anhand der Ausgabe des Skripts show_sip-stack.sh überprüft: #./show_sip-stack.sh [../src/sip/sipprocessor.cpp:26] C tor [../src/sip/sippacket.cpp:101] Request, method: INVITE [../src/sip/sipprocessor.cpp:100] Call not in CallMap. [../src/sip/sipprocessor.cpp:106] Request is INVITE [../src/sip/sipprocessor.cpp:111] Creating and inserting Call object into CallMap. [../src/sip/sipprocessor.cpp:113] Call ID: @ [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/sipprocessor.cpp:257] Handling INVITE request. [../src/sip/transaction.hpp:85] Changing state to (client / server): CALLING / PROCEEDING [../src/sip/sipprocessor.cpp:739] Processing Session Description. [../src/sip/sipprocessor.cpp:793] Inserting RtpSink Object into local and into global RtpSinkMap. [../src/sip/sipprocessor.cpp:796] Size of local RtpSinkMap is now: 1 [../src/sip/sippacket.cpp:117] Response, status: 100 trying -- your call is important to us [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): CALLING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): PROCEEDING / PROCEEDING [../src/sip/sippacket.cpp:117] Response, status: 603 Declined [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): PROCEEDING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / COMPLETED [../src/sip/sippacket.cpp:101] Request, method: ACK [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): TERMINATED / COMPLETED [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/sipprocessor.cpp:856] Call reference deleted from CallMap. [../src/sip/sipprocessor.cpp:858] Call ID: @ [../src/sip/transaction.hpp:40] D tor Die Ausgabe des SIP-Stack entspricht den Erwartungen: Die initiale INVITE Nachricht wird erkannt, und ein neues Call Objekt wird erstellt. Wie zu erwarten enthält diese Nachricht einen SIP-Body mit SDP Informationen, so dass ein RtpSink Objekt erstellt und der lokalen sowie der globalen RtpSinkMap hinzugefügt wird. Die provisorische Antwort 100 trying sowie die finale Antwort 603 Declined werden der laufenden INVITE Transaktion dieses Call Objekts zugeordnet. Die niemals beantwortete ACK Anfrage besitzt den Kontext der abgelehnten INVITE Anfrage. Daher 73

86 Kapitel 4. Softwaretest erkennt der SIP-Parser korrekterweise die zugehörige Transaktion. Der Verbindungsaufbauversuch ist damit beendet. Die Referenz auf das Call Objekt wird aus der CallMap entfernt. Im Folgenden werden die vom SIP-Stack erzeugten SbaEvent Objekte überprüft. Die Ausgabe des callx ii Konsolen Befehls SbaEventMap wurde in der Datei callx-con sole_sbaeventmap.log gespeichert: callx> SbaEventMap Caller: Event Type: INVITE Call ID: Timestamp: Mon Mar 18 03:45: Initiator: Final rsponse: N/A flags [ack/reinvite/cancel]: 0/0/0 Event Type: INVITE Call ID: Timestamp: Mon Mar 18 03:45: Initiator: Final rsponse: 603 Declined flags [ack/reinvite/cancel]: 0/0/0 Event Type: INVITE Call ID: Timestamp: Mon Mar 18 03:45: Initiator: Final rsponse: 603 Declined flags [ack/reinvite/cancel]: 1/0/0 Es wurden drei INVITE SbaEvent Objekte erzeugt. Das erste spiegelt das Ereignis der initialen INVITE Anfrage wieder. Das zweite besitzt zusätzlich die finale, negative Antwort des User Agent Servers. Mit dem dritten SbaEvent Objekt gleichen Typs ist der 3-Wege Handshake der nicht erfolgreichen INVITE Anfrage abgeschlossen, was am ACK Flag zu erkennen ist. Die erzeugten SbaEvent Objekte entsprechen den Erwartungen. Test 1.3a: Abgebrochener Verbindungsaufbau (mit Proxy) In diesem Test wird eine Verbindungsanfrage an den Asterisk B Teilnehmer 1100 ausgeführt und abgebrochen. Asterisk B wartet vor der abschließenden Verarbeitung der INVITE Anfrage eine Sekunde, so dass SIPp genügend Zeit hat, diese durch eine parallele CANCEL Anfrage abzubrechen ([Ros02, S ]). Eine SIP-Anfrage kann nur abgebrochen werden, wenn darauf noch keine finale Antwort erfolgt ist. In einem realen Verbindungsaufbau entspricht dies der Zeit, bis der Angerufene den Hörer abhebt. Die Parametrisierung des SIPp Szenarios (Datei input-1.3a.csv) ist folgende: SEQUENTIAL SIPp;test-1.3;1100;astb; ;5060;cancel 74

87 4.2. Signalisierungsverarbeitung Der Test wird durch Ausführung des im Verzeichnis test-1.3a befindlichen Skripts dotest-1.3a.sh gestartet. Der SIPp Scenario Screen (callx-test_2162_screen.log) zeigt Folgendes: Scenario Screen [1-9]: Change Screen -- Timestamp: Sun Mar 17 15:53: Call-rate(length) Port Total-time Total-calls Remote-host 10.0(0 ms)/1.000s s :5060(UDP) Call limit reached (-m 1), s period 0 ms scheduler resolution 0 calls (limit 1) Peak was 1 calls, after 0 s 0 Running, 2 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE > < < < < ACK > 0 0 BYE < > 0 0 Pause [ $hangup] 0 0 BYE > < CANCEL > < < < ACK > Waiting for active calls to end. Press [q] again to force exit Nach dem Versenden der INVITE Anfrage wartet SIPp bis zum Eintreffen einer provisorischen Antwort (100 Trying / 180 Ringing) und sendet daraufhin eine CANCEL Anfrage. Der User Agent Server beendet die INVITE Transaktion mit einer negativen Antwort 487 Request Terminated und die CANCEL Transaktion mit einer positiven Antwort 200 OK. Das SIPp Szenario berücksichtigt, dass die Antworten der beiden parallelen Transaktionen vertauscht sein können. Dazu existiert im Scenario Screen jeweils vor und hinter der Antwort 487 eine Antwort 200. Die Anzahl der Nachrichten in der Spalte Messages darf jedoch nur bei einer der beiden positiven Antworten eine 1 enthalten. Dieses für den User Agent Client nicht direkt vorhersehbare Verhalten liegt in der Hop-by-Hop Charakteristik der CANCEL Anfrage ([Ros02, S. 53]): Ein User Agent Server beantwortet eine CANCEL Anfrage zu einer laufenden INVITE Transaktion sofort mit der finalen Antwort 487 Request Terminated. Ein Stateful Proxy hingegen (hier Kamailio), beantwortet erst die CANCEL Anfrage mit 200 canceling, bevor er seine eigene INVITE Transaktion zwischen ihm und dem nächsten Transaktions- 75

88 Kapitel 4. Softwaretest terminierenden Stateful SIP-Element (User Agent oder Proxy) mit einer eigenen CANCEL Anfrage beendet. INVITE Anfragen besitzen keine hop-by-hop Charakteristik. Daher wird die Antwort 487 Request Terminated von einem User Agent (in diesem Scenario der Ziel User Agent) erzeugt und bis zum anfragenden User Agent Client transportiert. Abschließend sendet SIPp eine ACK Anfrage im Kontext der INVITE Transaktion. Der Vergleich der von callx ii erkannten SIP-Nachrichten (Ausgabe von show_sipparser_start-lines.sh) mit dem SIPp Scenario Screen fällt positiv aus:./show_sip-parser_start-lines.sh [../src/sip/sippacket.cpp:89] INVITE SIP/2.0 [../src/sip/sippacket.cpp:89] SIP/ trying -- your call is important to us [../src/sip/sippacket.cpp:89] CANCEL SIP/2.0 [../src/sip/sippacket.cpp:89] SIP/ canceling [../src/sip/sippacket.cpp:89] SIP/ Request Terminated [../src/sip/sippacket.cpp:89] ACK SIP/2.0 Die Ausgabe des hier aus Gründen der Übersichtlichkeit nicht dargestellten Filterskripts show_sip-parser_messages.sh zeigt im Vergleich mit der SIPp Logdatei callx-test _2162_messages.log, dass die Nachrichten korrekt geparst wurden. Die Ausgabe des SIP-Stacks (Filterskript show_sip-stack.sh) entspricht den Erwartungen und ist folgende:./show_sip-stack.sh [../src/sip/sipprocessor.cpp:26] C tor [../src/sip/sippacket.cpp:101] Request, method: INVITE [../src/sip/sipprocessor.cpp:100] Call not in CallMap. [../src/sip/sipprocessor.cpp:106] Request is INVITE [../src/sip/sipprocessor.cpp:111] Creating and inserting Call object into CallMap. [../src/sip/sipprocessor.cpp:113] Call ID: @ [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/sipprocessor.cpp:257] Handling INVITE request. [../src/sip/transaction.hpp:85] Changing state to (client / server): CALLING / PROCEEDING [../src/sip/sipprocessor.cpp:739] Processing Session Description. [../src/sip/sipprocessor.cpp:793] Inserting RtpSink Object into local and into global RtpSinkMap. [../src/sip/sipprocessor.cpp:796] Size of local RtpSinkMap is now: 1 [../src/sip/sippacket.cpp:117] Response, status: 100 trying -- your call is important to us [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): CALLING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): PROCEEDING / PROCEEDING [../src/sip/sippacket.cpp:101] Request, method: CANCEL [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:173] Not matching an ongoing transaction. [../src/sip/sipprocessor.cpp:180] Initial request. [../src/sip/transaction.hpp:34] C tor [../src/sip/sipprocessor.cpp:354] Found the INVITE transaction to be canceled. [../src/sip/transaction.hpp:85] Changing state to (client / server): TRYING / TRYING [../src/sip/sippacket.cpp:117] Response, status: 200 canceling 76

89 4.2. Signalisierungsverarbeitung [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): TRYING / TRYING [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/transaction.hpp:40] D tor [../src/sip/sippacket.cpp:117] Response, status: 487 Request Terminated [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): PROCEEDING / PROCEEDING [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / COMPLETED [../src/sip/sippacket.cpp:101] Request, method: ACK [../src/sip/sipprocessor.cpp:91] Found call in CallMap. [../src/sip/sipprocessor.cpp:153] Found transaction. [../src/sip/sipprocessor.cpp:155] Current state is (client / server): TERMINATED / COMPLETED [../src/sip/transaction.hpp:85] Changing state to (client / server): TERMINATED / TERMINATED [../src/sip/sipprocessor.cpp:856] Call reference deleted from CallMap. [../src/sip/sipprocessor.cpp:858] Call ID: @ [../src/sip/transaction.hpp:40] D tor Wie eingangs dieses Tests bereits erläutert, handelt es sich bei der CANCEL Nachricht um eine neue Transaktion, die parallel zur INVITE Transaktion stattfindet. callx ii erkennt dies: Not matching an ongoing transaction Die zugehörige INVITE Transaktion wird gesucht und da sie existiert auch gefunden. Die mit 487 negativ beantwortete INVITE Anfrage wird mit einer ACK Anfrage abgeschlossen, die im selben Transaktionskontext gesendet wird. Die Erzeugung der SbaEvent Objekte entspricht den Erwartungen: callx> SbaEventMap Caller: sip:sipp@ :5061 Event Type: INVITE Call ID: @ Timestamp: Sun Mar 17 15:53: Initiator: sip:sipp@ :5061 Final rsponse: N/A flags [ack/reinvite/cancel]: 0/0/0 Event Type: CANCEL Call ID: @ Timestamp: Sun Mar 17 15:53: Initiator: sip:sipp@ :5061 Final rsponse: N/A Event Type: INVITE Call ID: @ Timestamp: Sun Mar 17 15:53: Initiator: sip:sipp@ :5061 Final rsponse: N/A flags [ack/reinvite/cancel]: 0/0/1 Event Type: CANCEL Call ID: @ Timestamp: Sun Mar 17 15:53: Initiator: sip:sipp@ :5061 Final rsponse: 200 canceling Event Type: INVITE 77

90 Kapitel 4. Softwaretest Call ID: Timestamp: Sun Mar 17 15:53: Initiator: Final rsponse: 487 Request Terminated flags [ack/reinvite/cancel]: 0/0/1 Event Type: INVITE Call ID: Timestamp: Sun Mar 17 15:53: Initiator: Final rsponse: 487 Request Terminated flags [ack/reinvite/cancel]: 1/0/1 Die initiale INVITE Nachricht ist für das erste SbaEvent Objekt verantwortlich. Die CANCEL Anfrage erzeugt zwei SbaEvent Objekte. Eins vom Typ CANCEL und zusätzlich eins vom Typ INVITE mit gesetztem CANCEL Flag. Danach folgen wiederum ein CANCEL sowie ein INVITE Ereignis, dieses mal mit finaler Antwort 200 beziehungsweise 487. Das abschließende ACK erzeugt ein INVITE Ereignis, in dem alle Informationen enthalten sind: Die finale Antwort auf die INVITE Anfrage, ein gesetzte CANCEL Flag sowie ein gesetztes ACK Flag. Test 1.3b: Abgebrochener Verbindungsaufbau (ohne Proxy) In Test 1.3a wurde das unterschiedliche Verhalten von Proxy und User Agent in Bezug auf CANCEL Anfragen erläutert. Das Skript do-test-1.3b.sh im Verzeichnis test-1.3b startet das zum Test 1.3a gleiche SIPp Szenario mit den gleichen Eingabedaten. Lediglich der SIPp Aufrufparameter <remote_host> wurde von ser-d6 (SIP Proxy) in astb-d6 (User Agent) geändert. Das ist der User Agent, der auch bei den anderen Testfällen den Dialog terminiert. SIPp kommuniziert in diesem Fall direkt mit dem Ziel User Agent und nicht mit einem Proxy. Die Ausgabe des SIPp Scenario Screen zeigt im Vergleich zu Test 1.3a die vertauschten Antworten 487 und 200: Scenario Screen [1-9]: Change Screen -- Timestamp: Sun Mar 17 16:20: Call-rate(length) Port Total-time Total-calls Remote-host 10.0(0 ms)/1.000s s :5060(UDP) Call limit reached (-m 1), s period 0 ms scheduler resolution 0 calls (limit 1) Peak was 1 calls, after 0 s 0 Running, 2 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE > < < < <

91 4.2. Signalisierungsverarbeitung ACK > 0 0 BYE < > 0 0 Pause [ $hangup] 0 0 BYE > < CANCEL > < < < ACK > Waiting for active calls to end. Press [q] again to force exit callx ii verarbeitet die SIP-Nachrichten richtig. Bis auf die erwartete Änderung der Reihenfolge bei Bearbeitung der Antworten 200 und 487, die durch die andere Reihenfolge des Eingangs der SIP-Nachrichten hervorgerufen wird, stimmen die Inhalte der Logdateien dieses Testfalls mit denen des Tests 1.3a überein. Daher wird hier nicht näher auf die Ausgaben von callx ii eingegangen. Die Logdateien befinden sich im Verzeichnis test-1.3b Test-2: Signalisierungsbasierte Analyse Zum Test der signalisierungsbasierten Analyse wird ein umfangreicher Testfall erstellt. Das bisher genutzte SIPp Szenario wird auch hier verwendet. Die Parametrisierung soll jedoch einen möglichen Spam Versender simulieren. Alle Daten und Skripte dieses Tests befinden sich im Verzeichnis test-2. Das Skript do-test-2.sh erzeugt die SIPp Instanz mit folgendem Kommando: sipp -r 50 -l 200 -m sf callx-test.xml -inf input-2.csv -trace_msg -trace_screen ser-d6 Daraufhin erzeugt SIPp insgesamt 1200 Verbindungsversuche. Pro Sekunde werden maximal 50 neue Calls erstellt. Das Maximum gleichzeitiger Calls wird auf 200 begrenzt. Die Eingabedatei input-2.csv hat folgenden Inhalt: SEQUENTIAL # # 9 x Callee hangup SIPp;test-2.1;1003;astb; ;5060;0 SIPp;test-2.1;1003;astb; ;5060;0 SIPp;test-2.1;1003;astb; ;5060;0 SIPp;test-2.1;1005;astb; ;5060;0 SIPp;test-2.1;1005;astb; ;5060;0 SIPp;test-2.1;1005;astb; ;5060;0 SIPp;test-2.1;1007;astb; ;5060;0 SIPp;test-2.1;1007;astb; ;5060;0 SIPp;test-2.1;1007;astb; ;5060;0 # 79

92 Kapitel 4. Softwaretest # 1 x Caller hangup --> SIPp;test-2.1;1060;astb; ;5060;30000 # # 5 x 603 Decline (404 or other negative response # would be possible to) SIPp;test-2.1;1000;astb; ;5060;0 SIPp;test-2.1;1000;astb; ;5060;0 SIPp;test-2.1;1000;astb; ;5060;0 SIPp;test-2.1;1000;astb; ;5060;0 SIPp;test-2.1;1000;astb; ;5060;0 Insgesamt beinhaltet die Eingabedatei 15 Einträge. Bei 1200 Verbindungsversuchen werden diese 15 Einträge 80 mal durchlaufen. Die ersten 9 Verbindungen werden von Asterisk B beendet, wobei jeweils drei Verbindungen zu drei unterschiedlichen Teilnehmern aufgebaut werden. Es handelt sich um die Extensions 1003, 1005 und 1007, bei denen der Asterisk die Verbindung nach 3, 5 beziehungsweise 7 Sekunden beendet. Die Konfiguration der Asterisk B Teilnehmer ist auf Seite 65 dargestellt. Der zehnte Eintrag erzeugt eine Verbindung zu Teilnehmer Dabei würde Asterisk nach 60 Sekunden auflegen. Jedoch bedeutet die Zahl am Ende der Zeile die Anzahl Millisekunden, nachdem SIPp auflegt. In diesem Fall legt also der Caller nach 30 Sekunden auf. Bei den letzten 5 Einträgen kommt keine Verbindung zu Stande. Asterisk ist so konfiguriert, dass der Verbindungsaufbau sofort mit einer negativen Antwort, in diesem Fall 603 Decline, abgelehnt wird. Diese Antwort steht stellvertretend für alle nicht positiv beantworteten Verbindungsanfragen, zum Beispiel für 404 Not Found. Erwartungen wird, werden Da die Eingabedatei bei 1200 Verbindungsversuchen 80 mal durchlaufen = 800 erfolgreiche Verbindungen aufgebaut. Die restlichen 400 Versuche werden abgelehnt. In Prozent ausgedrückt führen 66,7 Prozent der Verbindungsversuche zum Erfolg. Weiterhin werden 9 von 10 (90 Prozent) der erfolgreichen Verbindungen vom Angerufenen beendet. Die abgelehnten Verbindungen werden dabei nicht berücksichtigt. Die kumulative Verbindungsdauer beträgt (3 3s + 3 5s + 3 7s + 30s) 80 = 6000s was 100 Minuten entspricht. Die durchschnittliche Verbindungsdauer der erfolgreichen Verbindungen errechnet wie folgt: 6000s/800 = 7, 5s 80

93 4.2. Signalisierungsverarbeitung Die Parametrisierung der signalisierungsbasierten Analyse in callx ii wurde über die Konfigurationsdatei (/etc/viat/callx.cfg) vorgenommen. Das Logfile callx.log enthält die beim Start von callx ii gelesenen Konfigurationswerte. Diese können über das Bash Skript show_sba-config.sh angezeigt werden: #./show_sba-config.sh [../src/main/callx.cpp:123] sba_call_attempts_period: 60 [../src/main/callx.cpp:125] sba_call_attempts_max: 100 [../src/main/callx.cpp:127] sba_calls_concurrent_period: 60 [../src/main/callx.cpp:130] sba_calls_concurrent_max: 10 [../src/main/callx.cpp:132] sba_call_completion_period: 60 [../src/main/callx.cpp:135] sba_call_completion_attemps_min: 20 [../src/main/callx.cpp:138] sba_call_completion_min: 70 [../src/main/callx.cpp:140] sba_call_duration_average_period: 20 [../src/main/callx.cpp:143] sba_call_duration_average_min_completed: 20 [../src/main/callx.cpp:146] sba_call_duration_average_min: 10 [../src/main/callx.cpp:149] sba_call_duration_cumulative_period: 100 [../src/main/callx.cpp:152] sba_call_duration_cumulative_max: 100 [../src/main/callx.cpp:155] sba_closed_by_callee_period: 60 [../src/main/callx.cpp:158] sba_closed_by_callee_min_completed: 60 [../src/main/callx.cpp:161] sba_closed_by_callee_max: 80 Ergebnisse Das Verzeichnis test-2 enthält alle erzeugten Logdateien sowie die Ausgabe der callx ii Konsole. Der SIPp Scenario Screen (callx-test_19815_screen.log) zeigt Folgendes: Scenario Screen [1-9]: Change Screen -- Timestamp: Tue Mar 19 17:57: Call-rate(length) Port Total-time Total-calls Remote-host 50.0(0 ms)/1.000s s :5060(UDP) Call limit reached (-m 1200), s period 0 ms scheduler resolution 0 calls (limit 200) Peak was 200 calls, after 6 s 0 Running, 274 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE > < < < < ACK > BYE < > Pause [ $hangup] 80 0 BYE > < CANCEL > < <

94 Kapitel 4. Softwaretest 200 < ACK > Waiting for active calls to end. Press [q] again to force exit Es wurden 1200 INVITE Anfragen versendet. Diese wurden 400 mal mit der Nachricht 603 Decline abgewiesen und 800 mal mit der Nachricht 200 OK positiv beantwortet. Das gleiche spiegelt sich bei den von SIPp erzeugten ACK Nachrichten wieder. Es werden 800 ACK Nachrichten als eigene Transaktionen gesendet (oben) und 400 Nachrichten im Kontext der INVITE Transaktion (unten). Der Unterschied der beiden ACK Einträge wurde bereits in Test 1.2 erläutert. Von den 800 erfolgreich aufgebauten Verbindungen wurde 720 mit einer BYE Anfrage des Angerufenen beendet und 80 mit einer BYE Anfrage von SIPp. Diese Angaben entsprechen den Erwartungen. Das Skript show_sig-based-ana.sh filtert aus der callx ii Logdatei die Ergebnisse eines Analyselaufs heraus: #./show_sig-based-ana.sh [../src/sba/sigbasedana.cpp:24] C tor [../src/sba/sigbasedana.cpp:38] Analyzer starting. [../src/sba/sigbasedana.cpp:41] Analyzer stopped. [../src/sba/sigbasedana.cpp:38] Analyzer starting. [../src/sba/sigbasedana.cpp:115] CALL_ATTEMPTS: 1200 call attempts in period of 60 minutes [../src/sba/sigbasedana.cpp:186] CALLS_CONCURRENT: 183 concurrent calls in period of 60 minutes [../src/sba/sigbasedana.cpp:239] CALL_COMPLETION: 67% call completion in period of 60 minutes [../src/sba/sigbasedana.cpp:296] CALL_DURATION_AVERAGE: 8 seconds average call duration in period of 20 minutes [../src/sba/sigbasedana.cpp:344] CALL_DURATION_CUMULATIVE: 106 minutes cumulative duration in period of 100 minutes [../src/sba/sigbasedana.cpp:403] CALLS_CLOSED_BY_CALLEE: 90% of the calls are closed by the callee [../src/sba/sigbasedana.cpp:41] Analyzer stopped. Der Analyselauf startet alle zwei Minuten, was bisher noch nicht über die Konfigurationsdatei einstellbar ist. Diese Ergebnisse stimmen mit der Ausgabe der callx ii Konsole bei Eingabe des Befehls SbaIncidentMap überein. Die Ausgabe wurde in die Datei callx-console_sbaeventmap.log kopiert: callx> SbaIncidentMap Worst incidents per caller: caller: sip:sipp@ : CALL_ATTEMPTS (Tue Mar 19 17:58: ) 1200 call attempts in period of 60 minutes CALL_COMPLETION (Tue Mar 19 17:58: ) 67% call completion in period of 60 minutes 82

95 4.2. Signalisierungsverarbeitung CALL_DURATION_AVERAGE (Tue Mar 19 17:58: ) 8 seconds average call duration in period of 20 minutes CALLS_CLOSED_BY_CALLEE (Tue Mar 19 17:58: ) 90% of the calls are closed by the callee CALL_DURATION_CUMULATIVE (Tue Mar 19 17:58: ) 106 minutes cumulative duration in period of 100 minutes CALLS_CONCURRENT (Tue Mar 19 17:58: ) 183 concurrent calls in period of 60 minutes Da sich die Analyseläufe stark überlappen (alle zwei Minuten ein Lauf, je nach Konfiguration werden die Analysen über eine Periode erstellt), werden für einen Caller oft sehr viele SbaIncident Objekte erzeugt. Auf der Konsole wird für jede Einzelanalyse nur das SbaIncident Objekt mit dem auffälligsten Wert dargestellt. Vergleich mit den Erwartungen Insgesamt entsprechen die Ergebnisse den Erwartungen. Bei allen Einzelanalysen wurden die Schwellwerte überschritten, so dass ein SbaIncident Objekt erzeugt wurde. Die Anzahl Verbindungsversuche wurde richtig erfasst. Vom Rundungsfehler abgesehen stimmt auch der Prozentsatz der erfolgreichen Verbindungen (Call Completion) mit den Erwartungen überein. Auch die durchschnittliche Verbindungsdauer unterliegt lediglich einem Rundungsfehler. Die Abweichung der kumulierten Verbindungsdauer (106 Minuten statt 100 Minuten) kann nicht durch Rundungsfehler erklärt werden, denn es wird jeweils die Dauer der Verbindung in Millisekunden addiert und erst zum Schluss in Minuten umgerechnet. Eine wahrscheinliche Erklärung ist der von callx ii mitgezählte Overhead für Auf- und Abbau der Verbindung. Die Verbindungsdauer wird über die Differenz der Zeitpunkte der INVITE Anfrage und der Antwort auf die BYE Anfrage ermittelt. Ähnlich sieht es mit der Ermittlung der Anzahl gleichzeitiger Verbindungen aus. SIPp hat 200 gleichzeitige Verbindungen ermittelt, was auch als Obergrenze angegeben war. callx ii hat nur 183 gleichzeitige Verbindungen erkannt. Es wird vermutet, dass die interne Verarbeitung der Calls in SIPp eine Rolle spielt. Diese Verarbeitung macht die Calls länger, so dass mehr Überschneidungen vorhanden sind. Unterstützt wird die Vermutung durch die hohe Anzahl an sehr kurzen Verbindungen. Bei Test-Szenarien mit längeren Verbindungsdauern wurden keine Abweichungen festgestellt. 83

96 Kapitel 4. Softwaretest 4.3. Audioverarbeitung Es wird die Extraktion und Dekodierung der Audiodaten überprüft. Dazu wird der Call Generator genutzt, den Dirk Lentzen für den ersten Prototypen [Len10] im Projekt VIAT implementiert hat. Der Call Generator überträgt die Audiodaten im Format G.711 A- law. Auf dem System astb-d6 wird der Call Generator über das Skript do-calls-htkeinmal.sh gestartet. Folgende Ausgabe wird erzeugt: # do-calls-htk-einmal.sh Konfigurationsdatei: /home/viat/scenario/htk-mfcc-id2-corpus1/config-make-calls-htk-einmal.pl Konfiguration: verbose: 3 rand_factor: 0 busyhour_calls: 4 hour_loads: ARRAY(0x ) outpath: /var/spool/asterisk/outgoing inpath: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles random: 0 mitzuruecklegen: 0 ticktime: 30 tmppath: /home/viat/scenario/htk-mfcc-id2-corpus1/tmp starttime: T11:00:00 call_files: call ticklength: 30 Found 600 Callfiles. Simulation: Simulationszeit: :00:00 Loadfaktor für Stunde 11=1 Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Simulationszeit: :00:30 Loadfaktor für Stunde 11=1 Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call Call: /home/viat/scenario/htk-mfcc-id2-corpus1/callfiles/no_spit call ^C Nach dem 8ten Call wurde das Szenario manuell abgebrochen. Es wurden 8 Verbindungen aufgebaut und es wurden die entsprechenden Audiodaten übertragen. callx ii hat für alle Verbindungen die Audiodaten des Anrufers extrahiert und in die folgenden Dateien geschrieben: wav 84

97 4.4. Bewertung der Testergebnisse wav wav wav wav wav wav wav Der Name einer WAVE Datei besteht aus der ID des Eintrags der Datenbanktabelle call, der für diese Verbindung von callx ii angelegt wurde. Die WAVE-Dateien befinden sich auf der beiliegenden DVD. Die Hörprobe der WAVE-Dateien fiel positiv aus Bewertung der Testergebnisse Die durchgeführten Testfälle bestätigen die fehlerfreie Funktionalität der signalisierungsbasierten Analyse und der passiven Extraktion. Ein vollständiger Softwaretest der Anwendung callx ii geht über den Rahmen der vorliegenden Arbeit hinaus. Die nachfolgenden Testfälle werden zur umfassenden Evaluierung der Anwendung callx ii empfohlen: Übergabe der Audiodaten vom OutputHandler an den Feature Extractor Während der Entwicklung wurde diese Funktionalität bereits überprüft. Die Audiodaten wurden richtig übertragen. Es wurde jedoch kein Testfall erstellt. Lasttest Während der Entwicklung wurden verschiedene Lasttests durchgeführt. Bei 250 parallelen Telefonverbindungen wurden vom call-generierenden System Asterisk A aufgrund von Überlastung nicht alle Mediensitzungen aufgebaut. In einem der Tests wurden die Audiodaten von mehr als 200 parallelen Telefonverbindungen in Form von WAVE-Dateien extrahiert. Die manuelle Überprüfung von mehr als 20 WAVE-Dateien fiel positiv aus. Der Autor geht davon aus, dass sich die Virtualisierung der Betriebssysteme negativ auf die Performanz des Gesamtsystems auswirkt. Um die Leistungsfähigkeit der Anwendung callx ii zu bestimmen, sollten Lasttests auf nicht virtualisierten Betriebssystemen durchgeführt werden. Audiodekodierung Die Tests während der Entwicklung und der Test Audioverarbeitung (vorangegangener Abschnitt) wurden mit G.711 A-law-kodierten Audiodaten durchgeführt. Weitere Testfälle mit G.711 µ-law- und GSM-FR-kodierten Audiodaten sollten durchgeführt werden, da diese beiden Audiodekodierungen in callx ii implementiert sind. 85

98

99 Kapitel 5. Zusammenfassung und Ausblick Die Aufgaben dieser Arbeit wurden durch die Entwicklung der Anwendung callx ii mit Erfolg umgesetzt. Bei callx ii handelt es sich um eine leistungsstarke Anwendung zur passiven Extraktion von Signalisierungs- und Mediendaten aus VoIP-Netzwerken. Die implementierte signalisierungsbasierte Vorfilterung verringert das von der inhaltsbasierten Analyse zu verarbeitende Datenvolumen. Das multi-threaded Design der Anwendung ermöglicht die Verarbeitung einer hohen Anzahl paralleler Telefonverbindungen. Eine besondere Herausforderung der Anwendungsentwicklung war die Verwaltung von 9 Threads und 10 gemeinsam genutzten Ressourcen. Um die Parallelität im Softwaresystem zu maximieren, wurden die Bereiche des wechselseitigen Ausschlusses möglichst klein gehalten. Die Robustheit des Systems wird durch die konsequente Anwendung des Designprinzips RAII (Resource Acquisition Is Initialization) unterstützt, wodurch Ressourcen automatisiert freigegeben werden. Der in callx ii implementierte passive SIP-Stack bietet eine umfangreiche Unterstützung des RFC 3261 ([Ros02]). Dazu zählen abgebrochener Verbindungsaufbau, Anrufweiterleitung und Neukonfiguration der Mediensitzung. Zudem ist sichergestellt, dass sich fehlerhafte Signalisierung, beispielsweise durch Paketverlust, nicht negativ auf die Funktionalität der Anwendung auswirkt. Zur Implementierung der signalisierungsbasierten Analyse hat sich der Autor an der Verhaltensanalyse des Monitoring-Systems PALLADION orientiert. Analysiert wird unter anderem die Anzahl der Verbindungsversuche, paralleler Verbindungen und Verbindungsbeendigungen durch den Angerufenen. Bei Überschreitung konfigurierbarer Schwellwerte werden zukünftige Anrufe des Absenders an die inhaltsbasierte Analyse weitergeleitet. Die Kombination mit der inhaltsbasierten Analyse hat den Vorteil, dass in der signalisierungsbasierten Analyse niedrige Schwellwerte gewählt werden können, ohne dass die Anzahl der Falsch-Positiven der inhaltsbasierten Analyse steigt. 87

100 Kapitel 5. Zusammenfassung und Ausblick Für den Softwaretest der Anwendung callx ii wurden verschiedene Testfälle definiert und durchgeführt. Durch diese wurde die fehlerfreie Funktionalität der signalisierungsbasierten Analyse und der passiven Extraktion bestätigt. Die vorliegende Arbeit umfasst eine umfangreiche Dokumentation der Anwendung. Die Dokumentation basiert auf den während der Designphase entworfenen UML- und Datenflussdiagrammen. Der ausführlich dokumentierte Quelltext der Anwendung wird im Rahmen des Projekts VIAT auf GitHub 1 veröffentlicht. Die Anwendung callx ii ist nicht auf die Verwendung in Kombination mit dem VIAT- System limitiert. Der Einsatz ist in allen Bereichen möglich, in denen Signalisierungsund Mediendaten aus VoIP-Netzwerken benötigt werden. Die passive Extraktion bietet die Möglichkeit einer einfachen Integration in vorhandene VoIP-Strukturen

101 89

102

103 Anhang A. Palladion Abbildung A.1.: PALLADION Webinterface 91

104 Anhang A. Palladion Abbildung A.2.: Konfigurationsdialog der Verhaltensanalyse im PALLADION Webinterface 92