Diplomarbeit. Titel. Anpassung und Erweiterung des NIST SIP-Servers an IMS 3.0. Betreuung: Prof. Dr. Georg Schneider

Transkript

1 Diplomarbeit Titel Anpassung und Erweiterung des NIST SIP-Servers an IMS 3.0 Daniel Demmer Sommersemester 2005 Betreuung: Prof. Dr. Georg Schneider In Kooperation mit der Firma Siemens AG, München Fachbereich Design und Informatik Fachhochschule Trier University of Applied Sciences

2 FACHOCHSCHULE TRIER UNIVERSITY OF APPLIED SCIENCES Fachbereich DESIGN UND INFORMATIK Autor: Daniel Demmer Titel: Anpassung und Erweiterung des NIST SIP-Servers an IMS 3.0 Studiengang: Angewandte Informatik Betreuung: Prof. Dr. Georg Schneider In Kooperation mit der Firma Siemens AG, München Sommersemester 2005 Unterschrift des Autors Demmer, 2005

3 Kurzfassung Diese Diplomarbeit beschäftigt sich mit der Anpassung und Erweiterung des NIST 1 SIP 2 Servers an IMS Im Rahmen dieser Arbeit wurde das vorhandene System an den IMS 3.5 Client angepasst, ein 2-Party Chat in das System integriert und die Funktionalität mit dem IMS 3.5 Client getestet. Außerdem wurde das vorhandene HTML 4 -Frontend an die geänderte Datenbankstruktur des IMS 3.0 angepasst und die Funktionalität erweitert. Abstract The topic of this diploma thesis is the adaptation and the extension of the NIST SIP server, which is framework for signalling IP-based communication on IMS 3.0, the current standard for multimedia services. The existing system has been adapted to an IMS 3.5 reference client. Furthermore a 2-Party chat functionality has been integrated into the system and the functionality has been tested with this IMS 3.5 client. Additionally the existing HTML-Frontend has been readjusted to the modified database structure of the IMS 3.0 standard and advanced functions have been added. 1 (National Institute of Standards and Technology) 2 (Session Initiation Protocol) 3 (IP Based Multimedia Subsystem) 4 Hyper Text Markup Language

4 INHALT 1 EINLEITUNG ZIELE DER ARBEIT GRUNDLAGEN SIP SESSION INITIATION PROTOCOL Aufbau der SIP-Nachrichten SIP Nachrichten Funktionsabläufe in SIP User Agents SDP SESSION DESCRIPTION PROTOCOL NIST SIP-SERVER Proxy Server Registrar Server Presence Server Redirect Server Location Server Instant Messaging Server Group and List Management Server ANPASSUNG DES SIP-SERVER AN DEN IMS CLIENT VORSTELLUNG DES IMS CLIENT DETAILLIERTE ÄNDERUNGEN AN DEM SIP-SERVER FUNKTIONALITÄTSTEST DES NIST SIP SERVERS INTEGRATION DER CHATFUNKTIONALITÄT UNTERSCHIED ZWISCHEN MESSAGE UND CHAT Message-Flow beim Senden von Message-Nachrichten Message-Flow beim Senden von Chat-Nachrichten INTEGRATION DES 2-PARTY CHAT IM NIST SIP SERVER Änderungen am Server und dem nist-sip-1.2.jar-file Erläuterungen und Funktionsweise des 2-Party Chat ANPASSUNG DES HTML-FRONTEND DER HTML-FRONTEND ADMINISTRATIONSBEREICH... 47

5 5.1.1 Ändern eines Benutzerpasswort Neuen Benutzer dem System hinzufügen Vorhanden Benutzer aus dem System entfernen DER HTML-FRONTEND BENUTZERBEREICH Die Kontaktlistenverwaltung Eine Kontaktliste bearbeiten Neuen Benutzer zu einer Gruppe hinzufügen ÜBERSICHT DES HTML-FRONTEND BEISPIEL FÜR 2-PARTY CHAT ZUSAMMENFASSUNG AUSBLICK LITERATURVERZEICHNIS ABBILDUNGS- UND TABELLENVERZEICHNIS ANHANG A... 69

6 1 Einleitung 6 / 69 1 Einleitung Mit der weltweiten, rapiden Verbreitung des Internets hat sich auch ein großes Interesse an Internetservices entwickelt. Gründe hierfür liegen vor allem in: stetige Weiterentwicklung der Technologie (wachsende Übertragungsgeschwindigkeiten) zeitunabhängige und günstige Tarife (Flaterates) ständig wachsender Bedienungskomfort der Services zunehmende Verfügbarkeit Ein aktuelles Beispiel für solch einen Internetservice ist die Internettelefonie (Voice over IP (VoIP) genannt). Diese neue Technologie (VoIP) verwendet zur Übertragung der Sprache anstatt des normalen Telefonnetzes das Internet. Für die Nutzung von VoIP spricht das damit verbundene Kosteneinsparungspotential, da der Service nicht über das vorhandene Telefonnetz erfolgt und zur Zeit kostengünstige Preise für Telefoneinheiten anbietet. Für den Gesprächsaufbau der Internettelefonie, sowie den Aufbau von Sessions (zum Chat), Datentransfer oder anderer Multimediasitzungen werden spezielle Protokolle verwendet. Eines davon ist das Session Initiation Protocol, kurz SIP. SIP ist ein Signalisierungsprotokoll, welches in der Lage ist Verbindungen in IP Netzen zwischen zwei Hosts aufzubauen, zu modifizieren und abzubauen. Durch die Verwendung von SIP mit anderen Protokollen sind komplexe Anwendungen wie zum Beispiel Onlinespiele, Multimediakonferenzen, usw. möglich. Durch diese Vielfalt an Möglichkeiten und durch die Plattformunabhängigkeit weckt dieses Protokoll das Interesse vieler Firmen und steigt damit zum Protokoll der Zukunft auf.

7 1 Einleitung 7 / 69 In vorherigen Diplomarbeiten (siehe [Bredtmann 05], [Surgiel 04] und [Wirtz 04]) wurde ein Testserver aufgebaut, der den Normen und Vorgaben des IMS Standard (siehe [PoC 05]) entsprachen. Dieser Testserver basiert auf dem National Institute of Standards and Technology (NIST) SIP-Server und wurde in diesen Arbeiten den IMS Standards angepasst und weiterentwickelt. Gegenstand dieser Diplomarbeit ist die Erweiterung und Anpassung des Testservers an den Referenzclient (IMS Client 3.5) von Siemens. Im zweiten Kapitel werden die zum Verständnis notwendigen Grundlagen erläutert. Unter anderem wird auf wichtige Begriffe vom Session Initiation Protokoll (SIP), sowie vom Session Description Protokoll (SDP) eingegangen und der Aufbau des NIST SIP-Servers genauer vorgestellt. Die im Zuge dieser Arbeit vorgenommenen Änderungen an dem NIST SIP-Server zur Anpassung des Systems an den IMS Client 3.5 werden im dritten Kapitel ausführlich dokumentiert. Im vierten Kapitel wird gezeigt, wie die Chatfunktionalität eines 2-Party Chats dem NIST SIP Server hinzugefügt wurde und was der Unterschied einer Chat- und Messagenachricht ist. Das fünfte Kapitel veranschaulicht die Anpassung des HTML-Frontend an IMS 3.0. Dabei wurde hauptsächlich das HTML-Frontend an die neue Datenbankstruktur angepasst.

8 1 Einleitung 8 / Ziele der Arbeit Die Ziele der vorliegenden Arbeit lassen sich wie folgt beschreiben: Anpassung des System an den Referenzclient IMS 3.5 Das vorhandene System, das auf einen NIST SIP Server aufbaut, wird an den Referenzclient IMS 3.5 von Siemens angepasst. Daher soll der NIST SIP Server so erweitert bzw. geändert werden, dass er alle Funktionen des Referenzclient unterstützt. Integration des 2-Party Chat in den NIST SIP Server Der NIST SIP Server wird um die Funktionalität des 2-Party Chat erweitert und angepasst. Ein 2-Party Chat ist eine Direktverbindung zwischen zwei Clients. Über diese Verbindung können die Teilnehmer Nachrichten austauschen (die Funktionalität eines Chat). Anpassung des HTML-Frontend an IMS 3.0 Das vorhandene HTML-Frontend, welches in einer vorherigen Diplomarbeit implementiert wurde, wird an IMS 3.0 angepasst. Diese Anpassung ist erforderlich, da sich die Datenbankstruktur durch die Umstellung von IMS 2.0 auf IMS 3.0 komplett geändert hat.

9 2 Grundlagen 9 / 69 2 Grundlagen 2.1 SIP Session Initiation Protocol Das Session Initiation Protocol (kurz SIP) ist ein Netzwerkprotokoll zum Aufbau einer Kommunikationssitzung zwischen zwei und mehreren Teilnehmern und wurde 1999 durch die IETF (Internet Enginieering Task Force (siehe [IETF 05])) genormt. Grundsätzlich wird das Protokoll in den RFC 3261 (siehe [RFC ]) spezifiziert und ist ein für die IP-Telefonie sehr häufig verwendetes Protokoll. Die Architektur von SIP ist vergleichbar mit der Architektur von HTTP (Client-Server Protokoll). Anfragen werden von dem Client generiert und an den Server gesandt. Der Server bearbeitet die Anfrage und schickt die Ergebnisse zurück an den Client. Eine Anforderung (Request) und die Antwort (Response) bilden zusammen eine Transaktion. Das Session Inititiation Protocol verwendet zum Beispiel die INVITE und die ACK Nachrichten, um eine sichere Verbindung aufzubauen mit der Kontrollnachrichten gesendet werden. SIP stellt nur minimale Anforderungen an das darunter liegende Transportprotokoll. Es stellt selbst eine Sicherung zur Verfügung und ist nicht von dem darunter liegenden TCP-Protokoll abhängig. SIP basiert auf dem Session Description Protocol (SDP) (siehe Kapitel 2.2), um die Informationen über den verwendeten Codec auszutauschen. Ein Codec ist ein Kompressionsalgorithmus, der zur Reduzierung der Größe eines Streams benutzt wird. Alle Objekte die von SIP adressiert werden können, werden mit einer sogenannten SIP URL (Uniform Ressource Locator) identifiziert. Eine SIP URL hat immer folgendes Format: sip:user@host Dieses Format kann mit dem Format einer adresse verglichen werden. Der User-Teil der URL ist frei wählbar. Dabei kann es sich um den Namen einer Person, eine Telefonnummer, den Namen einer Gruppe oder den eines Dienstes handeln.

10 2 Grundlagen 10 / 69 Die folgenden Unterkapitel erläutern den genaueren Aufbau und die Funktionalität des Session Initiation Protocols Aufbau der SIP-Nachrichten Jede Nachricht besteht aus einer ersten Zeile, die den Nachrichtentyp angibt, gefolgt vom Rest des Headers und einem Body. Es gibt dabei zwei Nachrichtentypen: Requests und Responses. Die Request-Nachrichten dienen dazu, eine Session zu initiieren oder dem Empfänger Nachrichten zu übermitteln. Durch die Responses wird der Empfang eines Requests bestätigt und der Status der Bearbeitung mitgeteilt. Beispiel: SIP-Request Abbildung 1 : Veranschaulichung eines SIP Request Einen typischen SIP-Request zeigt die obige Abbildung 1. Die erste Zeile beinhaltet den Nachrichtentyp - in diesem Fall ein INVITE-Request. Dieser dient dazu, eine Session zu eröffnen. VIA-Felder geben den Weg an, über den die SIP-Responses später geroutet werden sollen.

11 2 Grundlagen 11 / 69 From und To dienen dazu, den Sender und Empfänger der Nachricht zu spezifizieren (vgl. ). Über die Call-ID können die zum gleichen Anruf gehörenden Nachrichten identifiziert werden. Die CSeq gibt die Reihenfolge der Requests an. Mittels des Contact-Feldes gibt der Sender an, wo er die Antworten des Empfängers erwartet. Die übrigen Header sind von untergeordneter Bedeutung. Header und Body sind durch eine Leerzeile voneinander getrennt. Der Body eines INVITE-Requests enthält u.a. die in SDP (siehe Kapitel 2.2) kodierte Beschreibung der vom Sender unterstützten Medientypen. In diesem Beispiel beherrscht das Endgerät z.b. die Audiocodecs PCM law, GSM und ilbc. Alle weiteren Requests sind in ähnlicher Form aufgebaut. Zu diesen zählen ACK, BYE, CANCEL und REGISTER. Beispiel: SIP Responses Jeder Request - außer ACK - muss mit einer geeigneten Response beantwortet werden. Abbildung 2 : Auszug einer SIP Response Bis auf die erste Zeile ist der Aufbau der Response dem eines Requests ähnlich. Im Beispiel von Abbildung 2 befinden sich in der ersten Zeile die SIP-Version und ein Reply-Code (der ähnlich wie bei HTTP aufgebaut ist und im Kapitel erläutert wird).

12 2 Grundlagen 12 / SIP Nachrichten SIP übernimmt das Client/Server-Modell von HTTP. Es gibt verschiedene Arten von Anfragen, die mit einer Meldung beantwortet werden. Die Meldungen bestehen aus einer dreistelligen Zahl, die Aufschluss über die Art der Meldung gibt. Wie bei HTTP gibt es mehrere Klassen von Meldungen. Die sechs Klassen und einige Meldungen innerhalb dieser Klassen sind im Folgenden aufgelistet: Informational 1xx Dies sind Informationen des Servers über den Zustand der aktuell bearbeiteten Nachricht. 100 Trying 180 Ringing 181 Call Is Being Forwarded 182 Queued Successful 2xx Die Meldungen im 200er-Bereich signalisieren eine erfolgreiche Beendigung einer Aufgabe. Viele Nachrichten werden bei Erfolg mit der Meldung 200 OK beantwortet. Redirection 3xx Weiterleitung der Nachricht an andere Zielpunkte. Diese Art von Nachrichten wird von einem Redirect Server versendet, der in Kapitel genauer erläutert wird. Die am häufigsten auftretenden Meldungen sind: 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily

13 2 Grundlagen 13 / 69 Request Failure 4xx Diese Meldung deutet auf einen Fehler in der Anfrage hin, der durch die Syntax, die Semantik oder eine fehlende bzw. ungültige Autorisierung hervorgerufen wurde. Eine mögliche Meldung wäre der Versuch einen Benutzer zu erreichen, den es nicht gibt. Hierbei würde als Meldung ein 404 not found versendet werden. Server Failure 5xx Fehler des Servers. Es ist davon auszugehen, dass dieser Fehler temporär ist und die gleiche Anfrage später bearbeitet werden kann. Global Failures 6xx Dies sind Fehler die in keine der anderen Klasse passen.

14 2 Grundlagen 14 / Funktionsabläufe in SIP SIP stellt mehrere Dialogmöglichkeiten zur Verfügung, um Sitzungen zwischen Teilnehmern aufzubauen. Für alle Dialoge gilt, dass sie aus zwei Komponenten bestehen, der Anforderung (Request) und einer Antwort (Response). Fehlt einer der beiden Punkte ist die Herstellung einer Sitzung/Verbindung nicht möglich Die Sitzungsabläufe können direkt zwischen den SIP-Clients ablaufen. Allerdings ist nicht immer gewährleistet, dass ein Client erreichbar ist und immer dieselbe IP-Adresse hat. Daher meldet sich ein SIP-Client in der Regel an einem SIP-Server an, der als Proxy (siehe Kapitel 2.3.1) fungiert. Der SIP-Server registriert die IP-Adresse. Wenn ein Anruf auf die SIP- Adresse des SIP-Clients erfolgt wird die SIP-Adresse aufgelöst und ermittelt, wo und wie der Client erreichbar ist. Anschließend wird der Anruf und alle anderen Anfragen an den Client weitergeleitet. Dadurch kann der Benutzer (Client) sein Endgerät wechseln und ist immer erreichbar. Die SIP Spezifikation des RFC 3261 (siehe [RFC ]) unterscheidet zwischen sechs verschiedenen Methoden, die in SIP Nachrichten verwendet werden können. Zu diesen Methoden zählen: INVITE Mit diesem Befehl wird eine Gegenstelle zu einer Sitzung eingeladen. Der Vorgang entspricht in der Telefonie der Signalisierung bei einem Gesprächspartner dessen Telefon klingelt. Aus diesem Grund ist das INVITE der wichtigste Request. ACK Mit diesem Befehl wird eine Verbindung bestätigt. BYE Dies ist ein Request der ausgeführt wird, sobald einer der Verbindungsteilnehmer die Verbindung beendet. Sind mehrere Teilnehmer aktiv gilt dieser Request natürlich nur für jenen, der die Verbindung auch tatsächlich beendet hat.

15 2 Grundlagen 15 / 69 CANCEL Wenn eine Verbindung nach einer gewissen Zeit abgebrochen wird kommt dieser Request zum Tragen. Vergleichbar ist dies mit einem Timeout des normalen HTTP-Protokolls bei dem schlussendlich auch eine Verbindung beendet wird. OPTIONS Dieser Request bietet die Möglichkeit Zusatzinformationen des einzelnen Anwenders zu übermitteln. REGISTER Hiermit werden alle Standortinformationen des Client an den Server übergeben. Damit wird gewährleistet, dass der Server den Client bei einem Aufruf auch finden kann. Grundsätzlich besteht die Möglichkeit, Sitzungen direkt zwischen SIP-Clients ablaufen zu lassen. Das Problem ist allerdings, dass einerseits nicht immer gewährleistet ist, dass ein Client erreichbar ist, andererseits muss es nicht so sein, dass ein Client immer dieselbe IP-Adresse hat. Dies ist der Grund dafür, dass sich ein SIP-Client im Normalfall an einem SIP-Server anmeldet, der dabei die Funktion eines Proxy übernimmt. Ein Proxy (deutsch: Stellvertreter) leitet Anfragen als Stellvertreter weiter. Der SIP-Server registriert in diesem Fall die IP-Adresse. Erfolgt ein Aufruf der SIP-Adresse des Clients, löst der Server die SIP-Adresse auf und ermittelt, wo der Client erreichbar ist und vor allem, ob er erreichbar ist. Ist diese Abfrage positiv wird der Aufruf und alle anderen Anfragen an den Client weitergeleitet.

16 2 Grundlagen 16 / User Agents Ein User Agent (UA) ist ein System, welches für den Benutzer agiert. Es besteht aus zwei Teilen: einem Client und einem Server. Der Client-Teil wird User Agent Client (UAC), der Server-Teil User Agent Server (UAS) genannt. Der UAC wird verwendet, um eine SIP-Anforderung zu initiieren, während der UAS die Anforderung bearbeitet und die Antwort sendet. Bei einem UA wird meist noch eine (rein logische) Aufteilung in User Agent Client und User Agent Server vorgenommen, wobei jedoch jeder UA immer aus einem UAC und einem UAS besteht. Erstere dienen dazu, Anfragen zu stellen und Antworten zu verarbeiten. Ein UAS empfängt Anfragen und versendet Antwortnachrichten. In der folgenden Abbildung 3 sind die beiden Zustände illustriert, die ein User Agent annehmen kann. Abbildung 3 : Veranschaulichung eines User Agent

17 2 Grundlagen 17 / SDP Session Description Protocol Das Session Description Protocol (SDP) ist ein von der IETF veröffentlichtes Protokoll für multimediale Multicast-Konferenzen über das Internet, das in RFC 2327 (siehe [RFC ]) beschrieben ist. Das Session Description Protocol beschreibt die Inhalte von Multimedia- Sitzungen Die Informationen des Session Description Protocols können auch vom SIP-Protokoll verarbeitet werden, da diese u.a. die Codierungen und Übertragungsparameter beinhalten. Darüber hinaus umfassen die SDP- Nachrichten den Sitzungsnamen, Informationen über den Empfang der Sitzung und medienunterstützende Informationen. SDP wird verwendet um Multimedia-Sitzungen zu beschreiben. Der Sinn von SDP ist es, Informationen über Medienströme zu transportieren, was den Empfängern einer Sitzungsbeschreibung die Teilnahme an der Sitzung erlaubt. SDP liefert die folgenden Informationen: Sitzungsname und -grund Adresse und Portnummer Anfangs- und Endzeiten Informationen, die zum Empfang der Medien notwendig sind Informationen über die von der Konferenz verwendete Bandbreite Informationen über die für die Sitzung verantwortliche Kontaktperson Diese Informationen werden einfach im Textformat transportiert. Wenn eine Verbindung über SIP aufgebaut wird enthält die INVITE-Nachricht ein SDP-Feld, welches die für die anrufende Partei akzeptablen Sitzungsparameter enthält. Die Antwort des Angerufenen enthält eine SDP-Nachricht, die seine Fähigkeiten beschreibt. Allgemein müssen SDP-Nachrichten genügend

18 2 Grundlagen 18 / 69 Informationen enthalten, um einer Sitzung beizutreten und die erforderlichen Resourcen zu reservieren. Die Medieninformationen, die von SDP gesendet werden sind: Typ des Mediums (Audio oder Video), Transportprotokoll (RTP, UDP, TCP, usw.) und das Medienformat (MPEG-Video, H.263, usw.). Eine SDP Beschreibung besteht aus mehreren Textzeilen von der Form <name>=<wert>, wobei <name> aus einem Buchstaben besteht. Der <wert> ist eine strukturierte Zeichenfolge, dessen Form vom <name> abhängt. Leerzeichen vor und nach dem = sind nicht erlaubt. Eine SDP Nachricht hat immer folgende Struktur: Session description v= (protocol version) o= (owner/creator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* ( address) p=* (phone number) c=* (connection information not required if included in all media) b=* (bandwidth information) One or more time descriptions z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero ore more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times)

19 2 Grundlagen 19 / 69 Media description m= (media name and transport address) i=* (media title) c=* (connection information optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) * optional item (Quelle: [RFC ]) Wie so eine SDP-Nachricht aussehen kann, zeigt das folgende Beispiel: 1 v=0 2 o=demmerd IN IP s=sdp Diplombeispiel 4 i= 5 e=daniel Demmer <demmerd@fh-trier.de> 6 p= t= m=audio RTP/AVP 0 9 c=in IP m=video RTP/AVP c=in IP /15 In Zeile 1 der obigen Beispielnachricht wird die verwendete Protokollversion angegeben. Die Zeile 2 enthält Informationen über den Sender bzw. Besitzer sowie eine Identifikationsnummer. Zeile 3 gibt die Bezeichnung der Sitzung an. Die Zeilen 4, 5 und 6 beinhalten optionale Angaben. Wobei in Zeile 4 weiterführende Informationen zur Session stehen, die Zeile 5 die adresse des Senders beinhaltet und Zeile 6 die Telefonnummer angibt.

20 2 Grundlagen 20 / 69 Zeile 7 enthält eine Zeitspanne, in der die Verbindung gültig ist. Im obigen Beispiel ist dies eine Zeitspanne von 7200 Sekunden, was 120 Minuten darstellt. Die Zeile 8 und 9 enthalten Angaben über die zu verwendenden Medien. In Zeile 8 handelt es sich dabei um einen Audiokanal, welcher über RTP auf Port und in Zeile 10 um einen Videokanal, welcher über RTP auf Port übertragen wird. In den Zeilen 9 und 11 werden jeweils Netzwerktyp, Adresstyp und IP-Adresse genannt, wobei beim Netzwerktyp IN für Internet steht.

21 2 Grundlagen 21 / NIST SIP-Server Der SIP-Server, der für diese Diplomarbeit benutzt wird, baut auf den SIP- Server des amerikanischen Standardisierungsinstitut NIST auf (siehe [NIST 05]). Dieser NIST SIP-Server wurde im Rahmen von vorherigen Diplomarbeiten an der Fachhochschule Trier mehrfach erweitert (siehe [Bredtmann 05], [Surgiel 04] und [Wirtz 04]). Die Erweiterungen bzw. Veränderungen des NIST SIP-Server dienen dazu, diesen NIST SIP-Server IMS Standardkonform zu machen (siehe [PoC 05]). Der Zusammenhang zwischen der Client-Anwendung und den Kernfunktionen des Servers werden in der folgenden Abbildung 4 schematisch veranschaulicht. Abbildung 4 : Der Aufbau des SIP-Server In den folgenden Kapiteln werden die einzelnen Komponenten des SIP- Server genauer betrachtet und deren Funktionalität beschrieben.

22 2 Grundlagen 22 / Proxy Server Der Proxy Server spielt eine zentrale Rolle in einem SIP-Framework. Die Aufgabe dieses Servers ist es, das Routing der SIP-Nachrichten zum Aufbau einer SIP-Verbindung zu übernehmen. Die Verbindungsgesuche eines Anrufers können über mehrere Proxies bis zum Aufenthaltsort des Angerufenen geleitet werden. Der Proxy Server übernimmt also die Weiterleitung von Nachrichten. Wenn eine Einladung bei einem Proxy-Server eingeht, leitet er sie an die Adressen weiter, an denen er die Zielperson vermutet. Hierbei kann die Nachricht auch verschiedene Wege nehmen, falls der Proxy Server mehrere mögliche Zielpunkte kennt (Forking-Proxy). Diese Zielpunkte können selbst wieder Proxy Server sein. Ein Proxy-Server muss von anderen Servern außerhalb der Domain gefunden werden, damit diese die Anfrage weiterleiten können. Hierfür schlägt der RFC den Rechnernamen sip innerhalb der Domain vor, beispielsweise sip.fh-trier.de. Der Standard Port für SIP ist Eine weitere Möglichkeit ist ein DNS-Eintrag um den SIP Server mit einem DNS- Lookup zu lokalisieren. Im folgendem wird die Funktionsweise eines Proxy Servers am Beispiel einer INVITE Nachricht verdeutlicht. Beispiel: INVITE sip:dmeyer@fh-trier.de SIP/2.0 Via: SIP/2.0/UDP rahmen.fh-trier.de From: Crunchy<sip:crunchy@tzi.de> To: Dirk<sip:dmeyer@fh-trier.de> Call-ID: 31415@rahmen.fh-trier.de CSeq: 1 INVITE Der Proxy Server sucht mit Hilfe des Location Servers (siehe Kapitel 2.3.5) den Benutzer dmeyer aus der Datenbank. Anschließend wird die Nachricht an diese Adresse weitergeleitet. Der Proxy Server trägt seinen Namen in einem neuen Via-Feld in der Nachricht ein. Mit Hilfe der Via-

23 2 Grundlagen 23 / 69 Felder kann die Antwort den gleichen Weg zurück nehmen und es können Schleifen erkannt werden. INVITE sip:dmeyer@fh-trier.de SIP/2.0 Via: SIP/2.0/UDP sip.fh-trier.de; branch=1 Via: SIP/2.0/UDP rahmen.fh-trier.de.de From: Crunchy<sip:crunchy@fh-trier.de > To: Dirk<sip:dmeyer@fh-trier.de> Call-ID: 31415@rahmen.fh-trier.de CSeq: 1 INVITE Ein Proxy Server nimmt Anfragen von SIP User Agents entgegen und agiert für die Dauer des Verbindungsaufbaus als deren Stellvertreter. Die Aufgabe des Proxy Server ist es dabei, den jeweils gewünschten Teilnehmer zu lokalisieren und die Rufsignalisierung in Form einer so genannten Einladungsnachricht an diesen zu übermitteln. Im Verlaufe der Lokalisierung reicht er dazu die Anfragen gegebenenfalls unter Angabe der eigenen Absenderadresse an weitere SIP-Server weiter. Sobald die Lokalisierung abgeschlossen ist und der Ruf erfolgreich signalisiert werden konnte, erfolgt die Sitzung weitgehend ohne Proxy Server Registrar Server Damit ein Proxy Server weiß, wo der betreffende Benutzer zu finden ist, muss sich sein User Agent (UA) an einem Registrar angemeldet haben. Dieser speichert dann den derzeitigen Aufenthaltsort (d.h. IP-Adresse, Port und Benutzername) in einer sog. ''location database''. Auf diese kann dann der Proxy Server des Angerufenen zugreifen, um den Aufenthaltsort herauszufinden.

24 2 Grundlagen 24 / 69 Bei einem Registrar kann sich ein Endpunkt registrieren. Diese Funktionalität ist typischerweise in einem Proxy Server oder Redirect Server (siehe Kapitel 2.3.4) integriert, damit dieser auf die Registrierungsdaten zugreifen kann. Die Adresse des Registrars muss dem Endpunkt entweder vorgegeben werden oder die Registrierung wird per Multicast versendet. Beispiel: REGISTER sip:fh-trier.de SIP/2.0 Via: SIP/2.0/UDP krone.fh-trier.de From: dmeyer@fh-trier.de To: dmeyer@fh-trier.de Call-ID: 70710@krone.fh-trier.de CSeq: 1 REGISTER Contact: <sip:dmeyer@fh-trier.de:3890; transport=udp> Expires: 7200 Bei diesem Beispiel meldet sich der Benutzer dmeyer@fh-trier.de von Rechner krone.fh-trier.de an. Anhand des CSeq-Feldes ist erkennbar, ob es sich um die erste Anmeldung des Endpunktes oder eine Auffrischung der Registrierungsinformationen handelt. Die Transportadresse des SIP-Clients ist im Feld Contact angegeben. Nach 7200 Sekunden verliert die Registrierung ihre Gültigkeit und muss erneuert werden. Bei Erhalt der Nachricht überprüft der Registrar zuerst die Korrektheit der Daten und trägt den Benutzer dmeyer@fh-trier.de als neue Registrierung mit der Transportadresse krone.fh-trier.de/3890 Protokoll UDP in seine Datenbank ein. Als Antwort versendet er ein 200 OK um die erfolgreiche Verarbeitung der Daten zu signalisieren.

25 2 Grundlagen 25 / Presence Server Die Netzwerkkomponente Presence Server dient der Bereitstellung und Distribution von Benutzerdaten, welche anderen Benutzern zur Einsicht zur Verfügung gestellt werden sollen. Ein Benutzer kann über die Anwesenheitsdaten anderer Benutzer informiert werden, indem er diese Informationen abonniert. Benutzerdaten werden ausschließlich an Abonnenten bereitgestellt, welche vom Benutzer hierzu autorisiert wurden. Die Autorisierung erfolgt durch den Eintrag des potentiellen Abonnenten in eine oder mehrere Kontaktlisten jenes Benutzers, welcher seine Anwesenheitsinformationen an die Einträge der Kontaktliste veröffentlichen möchte. Die Kontaktlisten werden zentral gespeichert. Für jeden Abonnenten aller Benutzer wird in der Server-Anwendung Presence Server eine Präsenzliste geführt. In dieser Präsenzliste werden alle Benutzerkontaktlisten aufgelistet, die von dem Benutzer abonniert werden können. Die Benachrichtigung der Abonnenten wird zentral von der Komponente Presence Server gesteuert. Diese Komponente unterstützt somit den Signalisierungsdienst user availability. Ein Presence Server ist in der Lage SUBSCRIBE, NOTIFY und PUBLISH Methoden zu verarbeiten. Diese Methoden sind in der RFC 3265 (siehe [RFC ]) beschrieben. Die SUBSCRIBE Methode wird verwendet um sich an einem Presence Server als Watcher anzumelden. Die PUBLISH Methode dient dazu, dem Server seinen aktuellen Status mitzuteilen. Der Presence Server verwendet dann die NOTIFY Methode um den Watchern den aktuellen Status des Benutzers mitzuteilen, auf den sie die SUBSCRIBE Methode angewandt haben.

26 2 Grundlagen 26 / 69 Diese Funktionalität des Presence Servers ermöglicht es den SIP User Agents Buddylisten zu verwalten. Dadurch hat der Benutzer die Möglichkeit zu sehen, ob ein anderer Benutzer online oder offline ist Redirect Server Aufgabe dieses Servers ist es, bei eingehenden Anfragen den gewünschten Empfänger in der location database nachzuschlagen. Die gefundenen Aufenthaltsorte - es ist bei SIP möglich, dass man sich zur gleichen Zeit mit verschiedenen Endgeräten von verschieden Orten aus mit dem gleichen Benutzer anmelden kann - werden dann dem Sender der Anfrage mit einer entsprechenden Nachricht zurückgesandt. Ein Redirect Server nimmt wie ein Proxy Server Nachrichten an, leitet sie aber nicht weiter. Stattdessen gibt er die Adressen der Zielpunkte zurück und derjenige, der die Anfrage gestellt hat muss sich selbst an die neuen Zielpunkte wenden Location Server Bei einem Location Server können andere Server Endpunkte einen registrierten Benutzer anhand der SIP-Adresse suchen. Diese Funktionalität ist das Gegenstück zu einem Registrar Server und innerhalb eines Proxy Server oder Redirect Server realisiert. Ein Location Server kann daher von SIP Redirect Servern oder Proxy Servern verwendet werden, um zusätzliche Informationen über den gewünschten Empfänger zu erhalten. Der Location Server stellt den anderen Servern zusätzliche Routing Informationen zur Verfügung.

27 2 Grundlagen 27 / Instant Messaging Server Der Instant Messaging Server kann für die Steuerung der Kommunikation mit einzelnen Benutzern oder Benutzergruppen verwendet werden. Der Instant Messaging Server wurde in einer vorherigen Diplomarbeit erweitert bzw. angepasst und dient der korrekten Behandlung aller MESSAGE Nachrichten (siehe [Wirtz 04]) MESSAGE Nachrichten sind eine Erweiterung zum Session Initiation Protocol. Sie sind definiert in der RFC 3428 (siehe [RFC ]) und dienen zum Versenden von Instant Messages über SIP Group and List Management Server Diese HTTP-Schnittstelle ist nach vordefinierten Schnittstellenspezifikationen (siehe [PoC 05]) in einer vorherigen Diplomarbeit erstellt worden (siehe [Bredtmann 05]). Die Schnittstelle dient zur Verwaltung von Benutzerlisten und deren Zustände. Die Benutzerlisten werden in der Schnittstellenspezifikation (siehe [PoC 05]) als XML-Dokumente bezeichnet. Die XML-Dokumente können von der Client-Applikation über die HTTP-Schnittstellen angefordert werden. Bei jeder Anforderung von XML-Dokumenten werden diese dynamisch generiert. Die Inhalte der Dokumente bezieht der Server aus einer Datenbank.