Integration eines SIP Stacks in eine Web-Service

Transcription

Technische Universität Kaiserslautern – Integrated Communication Systems
Integration eines SIP Stacks in
eine Web-Service basierte
VoIP-Lösung
Projektarbeit im WS 2003/04 von
Franz-Josef Fink
Betreuer: Prof. Dr. Paul Müller
Dipl.-Inform. Markus Hillenbrand
Ge Zhang
Integration eines SIP Stacks in eine Web-Service basierte VoIP-Lösung
Inhalt
I
Inhalt
Einleitung...............................................................................................................................5
1 Grundlagen..........................................................................................................................6
1.1 VoIP.............................................................................................................................6
1.2 SIP...............................................................................................................................8
1.2.1 Funktionsweise....................................................................................................8
1.2.2 Beispielszenario.................................................................................................15
1.2.3 SDP....................................................................................................................17
1.3 RTP............................................................................................................................19
1.4 Web-Services.............................................................................................................24
1.4.1 XML...................................................................................................................24
1.4.2 SOAP ................................................................................................................26
1.4.3 URI ....................................................................................................................28
1.4.4 WSDL ...............................................................................................................28
1.4.5 UDDI.................................................................................................................31
1.4.6 In der Praxis......................................................................................................32
2 Web-Service basierte VoIP-Lösung..................................................................................33
2.1 Problemstellungen.....................................................................................................33
2.2 Idee............................................................................................................................34
2.3 Projekt Venice...........................................................................................................35
2.4 Aufgabe.....................................................................................................................40
3 Realisierungsaspekte.........................................................................................................41
3.1 Voraussetzungen........................................................................................................41
3.2 SIP-Stack...................................................................................................................42
3.2.1 Nist Jain sip v1.1................................................................................................43
3.2.2 Sip Communicator............................................................................................47
3.3 SIP-Gateway..............................................................................................................50
3.3.1 Anruf von Simple Client nach SIP-Client.........................................................52
3.3.2 Anruf von SIP-Client nach Simple Client.........................................................53
3.3.3 Gesprächsende durch Simple Client..................................................................54
3.3.4 Gesprächsende durch SIP Client........................................................................55
3.3.5 Multiuserbetrieb.................................................................................................56
3.4 Testbetrieb.................................................................................................................56
3.4.1 Weitere SIP Softwaretelefone............................................................................57
3.4.2 Siemens optiPoint 400 standard SIP..................................................................61
4 Zusammenfassung ............................................................................................................64
5 Ausblick.............................................................................................................................65
6 Abkürzungen.....................................................................................................................66
7 Abbildungs- und Tabellenverzeichnis...............................................................................68
8 Quellenangaben.................................................................................................................69
4
Abstract:
Die VoIP-Telefonie setzt sich durch ihre Vorteile im Bereich der Kosten und der Funktionalität langsam, aber sicher immer mehr gegenüber der leitungsgebundenen Telefonie
durch. Die Möglichkeit Internettelefonie über Web-Services anzubieten, ist dabei eine
neue vielversprechende Lösung, die unter anderem von zugrundeliegenden
Signalisierungstechnologien abstrahiert. Um Kompatibilität mit den sehr häufig vorkommenden, auf dem SIP Protokoll beruhenden Systemen zu gewährleisten, wird die Integration eines SIP Stacks auch in die Web-Service basierte Architektur gewünscht. Diese Projektarbeit beschäftigt sich mit der Entwicklung eines Prototyps, des SIP-Gateways, der die
Web-Service basierte Lösung um eine SIP-Schnittstelle erweitert. Dazu werden ebenfalls
die theoretischen Grundlagen erläutert, eine Modellbildung durchgeführt und die Implementierung getestet.
5
Einleitung
Mit der rapiden Verbreitung des Internets weltweit und insbesondere der Einführung
von Internetflatrates mit zeitunabhängigen Tarifen, hat sich auch ein größeres Interesse an
der Internettelefonie, auch Voice over IP (VoIP) genannt, breit gemacht. Diese neue Technologie verwendet zur Übertragung der Sprache anstatt des normalen Telefonnetzes das Internet auch zum Transfer von Telefongesprächen. Internet steht in den meisten Firmen und
auch in privaten Haushalten sowieso schon zur Verfügung. Dadurch können enorme Kosten gespart werden, da keine zusätzlichen Telefonleitungen verwendet werden müssen.
Für den Gesprächsaufbau der Internettelefonie wurden verschiedene Protokolle
entwickelt. Eines davon ist das Session Initiation Protokoll, kurz SIP. Damit ein Telefon
die Verbindung per Internet herstellen kann, muss es also zur Sprachübertragung auch
noch das Internetprotokoll zum Gesprächsaufbau verstehen. Da sich nebeneinander verschiedene Protokolle durchgesetzt haben, ist es günstig, wenn ein IP-Telefon mehrere verschiedene Protokolle verarbeiten kann. Die Protokolle sind oft sehr komplex und entwickeln sich auch weiter. Deshalb wird bei Internettelefonen eine umfangreiche Software benötigt. Im Projekt Venice wird ein Großteil dieser Funktionalität den Telefonen abgenommen und stattdessen von einem Web-Service zur Verfügung gestellt.
Die vorliegende Arbeit beschäftigt sich damit, wie dieses auf Web-Service basierte
VoIP-Telefonsystem um einen Service, der das SIP-Protokoll versteht, erweitert wird.
Im ersten Kapitel werden dazu zuerst alle Grundlagen erläutert. Dadurch wird auf
wichtige Begriffe wie Web-Services, VoIP-Telefonie und SIP Protokoll ausführlich eingegangen.
Daraufhin wird im zweiten Kapitel erklärt, wie die VoIP-Telefonie über Web-Services
funktionieren kann. Dabei wird das Projekt Venice vorgestellt, in dessen Rahmen diese
Arbeit durchgeführt wird.
Im dritten Kapitel wird aufgezeigt, wie das Projekt um die SIP Funktionalität erweitert
wird. Hierzu wird auch der SIP Stack beschrieben, der als Implementierung von SIP die
Basis für die Verwendung des SIP-Protokolls in diesem Projekt bildet, und wie dieser in
Venice eingebaut wird. Dies geschieht mithilfe der Implementierung eines Gateway-Services, der zwischen externen Telefonaten mit dem SIP-Protokoll und dem Web-Service
vermittelt, um ein Gespräch zwischen diesen aufbauen zu können.
Grundlagen
6
1 Grundlagen
1.1 VoIP
Seitdem 1872 das Telefon zur Sprachübertragung erfunden wurde, hat sich vieles
verändert. Während zuerst nur analoge Signale verwendet wurden, stellte sich das Telefonnetz (Public Switched Telephone Network (PSTN)) langsam auf digitale Kommunikation (ISDN) um. Dabei werden die analogen Signale durch Pulse Code Modulation (PCM)
in digitale umgewandelt und dann übertragen [1]. Obwohl Quality of Service (QoS) gewährleistet wird, ist die Bandbreite doch sehr teuer, was hohe Gesprächskosten bewirkt.
Und auch die Kommunikation erfolgt ineffizient, da für jede Verbindung ein eigener Kanal
verwendet werden muss.
Im Februar 1995 stellte die israelische Firma Vocaltec, Inc. als erste eine Lösung für
diese Probleme in Form einer IP Telefonsoftware vor [2]. Mit dieser wurden die analogen
Signale mit speziellen Codecs digitalisiert und komprimiert, wie es auch beim digitalen
Telefonnetz üblich ist. Codec ist eine Abkürzung für Coder/Decoder, also ein Programm
welches einen Datenstrom oder ein Signal in eine codierte Version transformieren kann
und wieder zurück. Anders als bei ISDN werden die kodierten Sprachsignale darauf aber in
IP-Pakete zerlegt und mittels Internet verschickt. Beim Gesprächspartner werden die Daten
wieder aus den Internetpaketen herausgeholt und dann zu Sprachsignalen dekodiert und
ausgegeben. Das Internet bietet den großen Vorteil gegenüber dem normalen Telefonnetz,
dass neben der Sprachübertragung auch Video und andere Daten durch Multiplexen viel
effizienter verschickt werden können, da es aufgrund der Paketvermittlung nicht verbindungsorientiert arbeiten muss. Die schon vorhandene Struktur des Internets kann um
diese Telefonfunktion einfach erweitert werden. Dadurch können auch Kosten enorm
gesenkt werden, insbesondere weil Internetverbindungen ohnehin meistens schon zur
Verfügung stehen und damit kaum zusätzliche Gebühren anfallen. Nicht nur Installation,
sondern auch Wartung und Unterhalt sind günstiger. Deshalb sind nicht nur Privatpersonen, sondern vor allem auch große Firmen an dieser neuen Technik VoIP besonders interessiert.
Anfangs war diese Technologie, wie nicht anders zu erwarten, noch nicht weit ausgereift und hatte einige Probleme, welche die allgemeine Akzeptanz erschwerten. Man konnte nur Telefongespräche mit Gesprächspartnern führen, die auch genau die selbe Software
verwendeten; außerdem war die Sprachqualität sehr gering, da Quality of Service nicht gewährleistet werden konnte. Die Verbindungen waren nur halbduplex, also man konnte
entweder Sprechen oder Hören, aber nicht beides gleichzeitig. Erst später wurde auch auf
Übertragung in Vollduplex gewechselt. Heutzutage gibt es viel schnellere Internetverbindungen, besonders durch die Verbreitung von DSL, und auch Router und Gateways, die
VoIP Pakete bevorzugt behandeln und damit QoS anbieten können. Dadurch kann man in
modernen VoIP Lösungen i. d. R. kaum noch Unterschiede zu normalen TelefongespräIntegration eines SIP Stacks in eine Web-Service basierte VoIP-Lösung
Grundlagen
7
chen feststellen. Zudem benötigt man nicht mehr unbedingt einen Computer mit Multimediaausrüstung, sondern es gibt auch schon Hardware IP-Telefone auf dem Markt, die sich
von klassischen Telefonen kaum unterscheiden und sehr einfach zu bedienen sind. Durch
das Verwenden bestimmter Standardprotokolle wie dem Session Initiation Protokoll (SIP)
oder H.3231 wird auch die Kommunikation verschiedener Produkte möglich gemacht. Des
Weiteren existieren Gateways, die zwischen verschiedenen dieser Protokolle vermitteln
und die sogar Telefongespräche in das normale PSTN ermöglichen oder auch von dem
PSTN durch spezielle Vermittlungsrechner in das Internet. Heutige Heimcomputer sind
fast alle mit Soundkarte und Internetanschluss versehen. Viele kostenlose VoIP-Programme, wie zum Beispiel das H.323 verwendende Netmeeting2, und der SIP verwendende
Microsoft Messenger, welche bei dem verbreiteten Betriebssystem Microsoft Windows
schon mitgeliefert werden, ermöglichen einer großen Masse von Anwendern die IP-Telefonie. Man benötigt dazu lediglich noch ein Mikrofon und einen Kopfhörer. Firmen wie
Indigo Networks3 bieten jedermann eine kostenlose Verwendung für Internettelefonie mittels SIP. Dabei erhält man eine echte Telefonnummer mit ENUM-Eintrag4. ENUM ist ein
System der Internet Engineering Task Force (IETF), das eine Internetadresse auf eine Telefonnummer des PSTN abbildet. Ruft man eine solche Telefonnummer an, wird das
Gespräch erst an ein spezielles Gateway mit dieser Telefonnummer weitergeleitet, dieser
sucht dann die zugehörige IP-Adresse heraus und leitet das Gespräch dahin weiter. So ist
nicht nur die Kommunikation zwischen SIP-Nutzern möglich, sondern man ist auch von
den bisher gebräuchlichen Telefonen aus erreichbar und kann auch kostengünstig in das
PSTN telefonieren. Damit steht der weitgehenden Nutzung von VoIP nicht mehr viel im
Wege, und die Technologie entwickelt sich in dem rasanten Tempo des Internets weiter.
Bei ISDN Telefonen stehen schon viele zusätzliche Funktionen zur Verfügung, die über
das reine Gespräch zweier Teilnehmer hinausgehen: die Übermittlung der Rufnummer,
Rückruf bei Besetzt, Anklopfen, Rückfragen/Makeln, Dreierkonferenz, Rufnummernanzeige (CLIP), Erreichbarkeit unter mehreren Nummern mit flexibler Aufteilung dieser
auf verschiedene Endgeräte, Rückruf bei Nichtmelden, Anrufweiterschaltungsvarianten
und Tarifinformationen. VoIP-Telefone bieten ebenfalls viele dieser Funktionen und es ist
sogar die Erweiterung durch vielfältige neue Leistungsmerkmale möglich. Besonders praktisch ist, dass man VoIP an allen Orten an denen ein Internetanschluss Verfügung steht
verwenden kann. Dadurch kann man auch auf Reisen immer günstig telefonieren oder ist
zum Beispiel zu hause und auch am Arbeitsplatz unter der gleichen Nummer erreichbar.
Besonders vorteilhaft ist ferner die Verschmelzung von Computer und Telefon. Man
vermag außerdem parallel zum Telefongespräch ohne großen Aufwand Dateien, wie Fotos,
Musik, Videoclips oder Berichte mitschicken und es lassen sich einfache Telefonplugins in
1
2
3
4
Standard der International Telecommunication Union (ITU)
http://www.microsoft.com/windows/netmeeting/
www.sipgate.de
E.164 number (rfc2916)
Grundlagen
8
Programme einbauen, zum Beispiel zu einer Service-Hotline. Ein anderer Vorteil besteht
in der Videotelefonie, denn die meisten Telefonprogramme unterstützen die Übertragung
von Videodaten und man benötigt lediglich noch eine Web-Cam. Funktionen, bei denen
hoher Rechenaufwand benötigt wird, wie z. B. Sprachfilter oder Verschlüsselung, kann
auch der Computer übernehmen. VoIP stellt also eine neue Generation des Telefonierens
dar.
Trotzdem sollen hier aber auch nicht die Nachteile verschwiegen werden. Da Internetverbindungen und Netzgeräte nur eine bestimmte Anzahl an Paketen verarbeiten können,
ist es möglich durch Überlastung bestimmter Stellen die Verbindung zu stören oder ganz
zu verhindern. Dies kann böswillig für Denial of Service Attacken (DOS) ausgenutzt
werden, oder solche Störungen können bei einer zu hohen Auslastung des Netzes auftreten
(Congestion). Wenn die Pakete zu langsam ankommen leidet die Qualität5. Bei einer direkten Verbindung erfährt jeder Teilnehmer auch die IP-Adresse des Partners. Diese kann unerwünscht private Informationen preisgeben, z. B. über den Internetprovider und den
Standort. Dadurch sind dann gezielte Angriffe möglich. Ebenso können Nachrichten gefälscht werden, indem sie von einer vorgetäuschten IP-Adresse verschickt werden (IP
Spoofing), oder irgendwo auf dem Weg mitgehört werden (Sniffen). Trotzdem sind ebenso
Telefonate im PSTN nicht komplett sicher und die Nachteile von Internettelefonie halten
sich in Grenzen.
Ein typisches VoIP-Telefonat besteht aus zwei Teilen, erstens dem Verbindungsaufbau,
dem Signaling, und zweitens dem Datentransfer, der meistens per Realtime Transfer Protokoll (RTP) erfolgt. Für das Signaling gibt es viele verschiedene Protokolle, die zueinander
inkompatibel sind. Die beiden häufigsten SIP und H.323 sind auch schon zuvor erwähnt
worden. Das H.323 Protokoll der ITU hat sich aus dem Telefonbereich entwickelt und ist
schon sehr ausgereift, aber auch komplex. SIP vom IETF hingegen ist noch recht neu,
wurde aber speziell im Hinblick auf Internetfunktionalität konzipiert und ist deshalb wohl
das vielversprechendste. Im Moment sind diese zwei Protokolle die dominierenden und sie
koexistieren, da beide ihre Vorzüge haben. Während die meisten Hardware Internet Telefone eher auf H.323 beruhen, zeichnet sich der Trend (besonders bei den mehr an Computer gebundenen Lösungen) zur Verwendung von SIP ab.
1.2 SIP
1.2.1 Funktionsweise
Das SIP Protokoll regelt Aufbau, Abbau und Veränderungen von Telefonverbindungen.
Dieses Application Layer Protokoll wurde von Prof. Hennig Schulzrinne in Berlin entwi5 Siehe Jitter in 1.3
Grundlagen
9
ckelt, erstmals 1999 als ein Standard der IETF für Voice over IP Verbindungen in RFC
2543 vorgestellt und 2002 in RFC 3261 verbessert.
Die von SIP bereit gestellten Dienste sind:
• Benutzerlokalisierung:
Bestimmung der Kommunikationsendpunkte, die für die Kommunikation benötigt
werden
• Anrufaufbau:
Aufbau der Verbindung sowie Bestimmung der Verbindungsparameter
• Verfügbarkeitsprüfung:
Überprüfung, ob die angerufene Partei bereit und willig ist, einen eingehenden Anruf anzunehmen
• Anrufbehandlung:
Der Transfer und der Abbau von Verbindungen
SIP ist ähnlich wie HTTP aufgebaut und basiert genauso auf ASCII-Text. Die Pakete sind also auch von Menschen lesbar.
Hier ein Beispiel einer SIP Message:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 169.130.12.12
Authorization: PGP version=5.0, signature=...
From: A. Bell <sip:[email protected]>
To: T. A. Watson <sip:[email protected]>
Call-ID: [email protected]
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
Abbildung 1: SIP Nachricht
Der obere Teil von Abbildung 1 wird SIP Header genannt. Er gibt die SIP Methode
(hier INVITE), den Empfänger (sip:[email protected]), die Version des
Grundlagen
10
Protokolls (SIP/2.0), das gewählte Transportprotokoll (UDP), einen Proxyserver oder SIPRouter über den die Nachricht geleitet wird (169.130.12.12), den Sender (From: A. Bell
<sip:[email protected]>), einige eindeutige Call-ID ([email protected]) und Informationen zum Inhalt der Nachricht (Content) an. Es gibt
noch eine Vielzahl von Informationen die je nach Art der Nachricht im Header angegeben
werden können:
Header Feld
beschreibt:
Accept
die Medientypen, welche in der Antwort möglich sind
Accept-Encoding
die in der Antwort erlaubten Kodierungen des Inhalts
Accept-Language
bevorzugte Sprache für Status-, Begründungs- und Sitzungsbeschreibungs-Antworten
Allow
welche Methoden erlaubt sind
Authorization
Informationen für eine Autorisierung
Call-ID
eindeutige Identifizierung eines Gesprächs:
Call-ID = ("Call-ID"|"i")":"local-id"@"host
Contact
Kontaktadresse des Benutzers
Content-Encoding
Kodierungsart des Inhalts
Content-Length
Länge des Inhalts in bit
Content-Type
Art des Inhalts, z.B. text/html
CSeq
Ansteigende Kommando-Sequenznummer für jede neue Nachricht mit gleicher Call-ID
Date
Zeit des ersten Sendens einer Nachricht (nach RFC 1123)
Encryption
Art der Verschlüsselung des Inhalts
Expires
Zeitpunkt an dem die Nachricht verfällt oder Lebensdauer in
Sekunden
From
Absender mit SIP-Adresse
Hide
ob die Route der Nachricht geheim gehalten werden soll
Max-Forwards
maximale Anzahl der Weiterleitungen (wird automatisch dekrementiert)
Organization
Zugehörigkeit des Absenders zu einer bestimmten Organisation
Priority
Priorität der Nachricht: emergency, urgent, normal, non-urgent
Proxy-Authenticate
Informationen von einem Proxy zur benötigten Authentifizierung
Proxy-Authentization
Angaben des Clients für eine Authorisierung bei einem Proxy
Grundlagen
11
Header Feld
beschreibt:
Proxy-Require
notwendige Eigenschaften, die ein Proxy haben muss
Record-Route
Speichern der SIP-Adressen aller Stationen auf der Route
Require
notwendige Eigenschaften, die der antwortende Teilnehmer
haben muss
Response-Key
Schlüssel, mit dem die Antwort verschlüsselt werden muss
Retry-After
Zeitspanne bis zum weiteren Sendeversuch, falls voriger nicht
erfolgreich
Route
Route, auf der die Nachricht gekommen ist. Jeder Proxy
nimmt den ersten Eintrag aus der Liste weg und verschickt die
Nachricht an diesen Eintrag weiter.
Server
Informationen über die Software des Servers
Subject
Textinformation über den Zweck des Gesprächs
Timestamp
Zeitstempel mit individueller Zeit des Clients beim Erstellen
der Nachricht
To
Adresse, für die die Nachricht bestimmt ist
Unsupported
Eigenschaften, die vom Server nicht unterstützt werden
User-Agent
Informationen über die Software des Clients
Via
Weg, den die Nachricht bis jetzt gegangen ist
Warning
Warnungen über aufgetauchte Probleme bei einer Nachricht
WWW-Authenticate
Informationen zu einer benötigten Authentifizierung
Tabelle 1: SIP Header Felder nach [3]
Zudem kann es auch noch experimentelle, neue und selbst eingeführte Header geben, die
natürlich nur dann nützlich sind, wenn sie jedem der Teilnehmer bekannt sind.
Der untere Teil der SIP Nachricht aus Abb. 1 ist die sogenannte Payload und gibt weitere Informationen wie z. B. die verfügbaren Audio Codecs an. Dieser Teil ist im Session
Description Protokoll6(SDP) beschrieben.
SIP ist Client/Server basiert. Der Client schickt dabei eine Anfrage (Request), welche
vom Server nach Bearbeitung mit dem Ergebnis beantwortet (Response) wird. Dabei kann
bei einer Kommunikation von zwei Teilnehmern jeder die Rolle von Server und Client
annehmen. Die Teilnehmer werden dabei als User Agents (UA) bezeichnet. Also können
sie je nach Situation entweder die Rolle eines User Agent Client (UAC) oder ein User
Agent Server (UAS) übernehmen. Die Kommunikation beginnend mit einem Request bis
zur engültigen Response wird bei SIP als Transaktion bezeichnet. Das komplette Gespräch
stellt einen Dialog dar. Üblicherweise sind User Agents Hardware- oder Softwaretelefone.
6 siehe Abschnitt 1.2.2
Grundlagen
12
Sie können aber auch spezielle Gateways oder Router sein, die für die SIP-Kommunikation
erweiterte Funktionalität wie beispielsweise die Weiterleitung von Verbindungen
anbieten [4].
Die Requests, die dem UAC zum Senden zur Verfügung stehen, sind [5]:
•
•
•
•
•
INVITE: Einladung zu einem Gespräch, welches mit einem in der in der Payload
angegebenen Codecs kodiert ist
OPTIONS: Setzen von spezielle Optionen (meistens für Router)
BYE: Anruf beenden
CANCEL: Abbruch eines Requests
REGISTER: Anmelden eines neuen Nutzers bei einem Telefonverzeichnis
Als Antwort sind daraufhin sehr viele Responses möglich. Diese wurden, wie auch
von Http bekannt, durchnummeriert. Viele Fehlercodes wurden dabei sogar ganz von
HTTP/1.1 übernommen, wenn ein gleichartiger Fehler auftritt wie dort.
•
Codes zwischen 100 und 199 sind informative Zwischenbemerkungen; 180 ist beispielsweise die Meldung, dass beim Gegenüber jetzt das Telefon klingelt.
•
Antworten 200 bis 299 geben dann einen endgültigen Erfolg durch; 200, ist zum Beispiel die Nachricht, dass das INVITE angenommen wurde
•
Die 300er Codes werden für Weiterleitungsmeldungen verwendet.
•
Mit 4 beginnende Meldungen bedeuten, dass ein Fehler beim Client liegt, wie z. B.
fehlerhafte Syntax.
•
Bei 500 bis 599 kann der Server den Request nicht erfüllen.
•
600 bis 699 sind letztendlich Fehler, die global auftreten, also wenn der Request von
keinem Server erfüllt werden kann.
Grundlagen
13
Folgende Tabelle 2 zeigt nun die exakten Fehlermeldungen:
Type
Status code
Error
100
Trying
180
Ringing
181
Call Is Being Forwarded
182
Queued
Success
200
OK
Redirection
300
Multiple Choices
301
Moved Permanently
302
Moved Temporarily
303
See Other
305
Use Proxy
380
Alternative Service
400
Bad Request
401
Unauthorized
402
Payment Required
403
Forbidden
404
Not Found
405
Method Not Allowed
406
Not Acceptable
407
Proxy Authentication Required
408
Request Timeout
409
Conflict
410
Gone
411
Length Required
413
Request Entity Too Large
414
Request-URI Too Large
415
Unsupported Media Type
420
Bad Extension
480
Temporarily not available
481
Transaction Does Not Exist
482
Loop Detected
483
Too Many Hops
484
Address Incomplete
485
Ambiguous
486
Busy Here
500
Internal Server Error
501
Not Implemented
502
Bad Gateway
503
Service Unavailable
504
Gateway Time-out
505
SIP Version not supported
600
Busy Everywhere
603
Decline
604
Does not exist anywhere
606
Not Acceptable
Informational
Client-Error
Client-Error
Server-Error
Global failure
Tabelle 2: SIP Client Fehlercodes nach [3]
Grundlagen
14
SIP-Nachrichten müssen nicht über direkte Verbindungen erfolgen, sondern können
auch, wie im Internet üblich, von speziellen SIP-Proxies weitergeleitet werden. Anhand der
Email ähnlichen SIP-URL (sip:username@hostname) kann die Nachricht flexibel weiterverschickt oder umgeleitet werden. Normalerweise melden sich User Agents bei einem
Server an, der Registrar genannt wird. Dieser hat dann immer die aktuelle IP-Adresse des
jeweiligen SIP-UA, auch wenn der UA sich an unterschiedlichen Orten aufhält. Registrare
führen eine Liste mit den anwesenden Usern und deren Aufenthaltsadresse7.
SIP-Proxies können entweder direkt weiterleiten, ohne zwischen bestimmten Zuständen
zu unterscheiden (stateless) oder aber intelligent (stateful) sein und unterstützende
Funktionen haben. Solche Funktionen können sein:
• Verteilen von Anrufen auf verschiedene Ziele: Falls es nicht genau feststeht, wo sich
der Adressat im Moment aufhält und verschiedene Orte denkbar sind.
• Traffic und Kostenberechnung
• Anmeldung: Proxies übernehmen oft die Funktion eines Registrars (sie müssen dabei
nicht einmal als Proxy verwendet werden).
Grundsätzlich ist es auch erlaubt, eine bereits bestehende Verbindung durch neue INVITE-Requests zu modifizieren. Diese Möglichkeit wird genutzt, um die Kommunikationsquelle zu ändern oder um im Gespräch eine Pause einzuführen, also den Gesprächspartner
auf "Hold" zu setzen.
Dazu wird einfach als eigene Empfängeradresse die IP-Adresse 0.0.0.0 verwendet.
Selbst wenn der andere Teilnehmer "Hold" nicht versteht, schickt dieser seine Daten dann
an die nicht existierende IP-Adresse. In dieser Zeit wird als neue Quelle zum Beispiel ein
Musikstream angegeben.
Eine Rufumleitung lässt sich mit SIP genauso einfach durchführen. Dazu wird einfach
eine Response 302 (Temporarily Not Available) verschickt. Dabei wird im "Contact"-Feld
eine Liste der alternativen SIP-URLs mitgeschickt. Der Gesprächspartner kann es dann mit
der alternativen Nummer versuchen, normalerweise übernimmt dies aber der Proxy.
Für Sicherheit bietet SIP auch die gängigen Mechanismen wie sie auch bei Http und
Email verwendet werden. Eine Authentifizierung erfolgt dadurch, dass alle Requests mit
dem Code 401 (Authorization Reqired) oder dem Code 407 (Proxy Authentication Required) abgelehnt werden können, falls die Authorisierungsinformationen im Request nicht
genügen. Schutz vor einfachem Sniffen8 der Pakete kann durch Verwenden des Transport
Layer Security Protokolls (TLS)9 anstatt des unverschlüsselten UDP erzielt werden. Auf
der Medienebene bietet sich auch die Möglichkeit Verschlüsselungsalgorithmen wie z. B.
7 Durch die Funktion REGISTER
8 Mitlesen der Internetpakete von Rechnern, die bei der Verbindung zwischen den
Kommunikationspartnern liegen
9 es verwendet Secure Sockets Layer (SSL) 3.0
Grundlagen
15
Triple-DES zu benutzen. Das sogenannte Secure Realtimetime Protokoll (SRTP)10 kann
dabei RTP ersetzen, dadurch wird eine Verschlüsselung in Echtzeit ermöglicht und es
kommt nicht zu störenden zeitlichen Verzögerungen bei der übertragenen Sprache. Der
Austausch der Schlüssel erfolgt hierbei durch TSL geschützte Signalisierung. Durch diese
Methoden oder auch das Verwenden von Pretty Good Privacy (PGP)11 kann (bei genügend
hoher Sicherheitsstufe) ein Unmöglichmachen des Abhörens gewährleistet werden. Eine
"Man in the middle attack", bei der sich ein Belauscher als Gegenstelle für beide
Gesprächspartner ausgibt, kann dadurch verhindert werden, dass ein Teil des öffentlichen
Schlüssels angezeigt wird, um ihn dann dem Gesprächspartner vorlesen zu können. SIP
stellt also alle nötigen Mechanismen für eine sichere Kommunikation bereit. Leider
werden solche Sicherheitsmechanismen derzeit kaum verwendet, was einerseits an dem
geringen Sicherheitsbewusstsein der Endnutzer liegt und auch daran, dass staatliche Sicherheitsbehörden und Geheimdienste dadurch einer der wichtigsten Informationsquellen
beraubt würden [6][7].
Nachdem nun generell auf die Vorteile und Mechanismen von SIP eingegangen wurde,
wird das ganze nochmal mit einem Beispiel vertieft.
1.2.2 Beispielszenario
Ein typischer Verbindungsaufbau mit SIP sieht nun wie folgt aus:
Anrufer
Angerufener
INVITE
100 (Trying)
180(Ringing)
Transaktion
200 (OK)
ACK
Dialog
RTP
BYE
200
(OK)
Abbildung 2: SIP Verbindungsaufbau
10 http://srtp.sourceforge.net/spec.html
11 http://www.gnupg.org/
Grundlagen
16
Nachdem die Teilnehmer über die Register-Methode bei einem Registrar erfolgreich
angemeldet sind, also einen 200 Responsecode zurückbekommen haben (der UA gibt an,
wo er zu erreichen ist und erhält die Bestätigung mit dem Code 200 (Ok)), kann der eigentliche Dialog beginnen. Jeder Request wird zuerst an den zuständigen SIP-Proxy versandt,
der dann das weitere Routing bestimmt. Bei jeder weiteren Station wird dann der VIAHeader um diese Adresse erweitert. Jede Response-Nachricht wird immer an die Adresse
geschickt, welche im ersten Via-Feld aufgeführt ist, wobei dann diese Adresse wieder aus
der Liste gestrichen wird. Dadurch können die Antworten genau die gleiche Route zurück
verfolgen auf der schon der Request gekommen ist.
Die übliche SIP Verbindung ist in Abbildung 2 zu sehen; sie wird folgendermaßen initiiert:
1. Der Anrufer (Caller) schickt eine INVITE-Message an den Angerufenen (Callee).
Diese kann direkt erfolgen, oder über eine Vielzahl von Proxy Servern. In der INVITENachricht stehen auch alle wichtigen Daten für das Kommunikationsmedium.
2. Darauf erfolgt normalerweise eine informative Nachricht 100 (Trying) als Antwort.
Wenn UDP verwendet wird, werden die gleichen Requests grundsätzlich immer wieder
verschickt, bis die Nachricht beantwortet wird oder ein Timeout erfolgt. Bei der Ankunft
von 100 wird also erkannt, dass erfolgreich gesendet wurde und der Request muss nicht
wiederholt abgeschickt werden.
3. Wenn der INVITE-Request beim Gegenüber angekommen ist, muss auf Eingreifen des
Benutzers gewartet werden, der das Telefonat annimmt oder ablehnt. Das Telefon
klingelt. Deshalb wird 180 (Ringing ) zurück gesendet.
4. Nun gibt es eben diese beiden Möglichkeiten:
- Falls das Gespräch abgelehnt wird, schickt man z. B. 603 (Declined) zurück. Damit
endet der Dialog.
- Bei Annahme wird mit einem 200 (Ok) geantwortet, und darin enthalten ist eine
Beschreibung der eigenen Mediendaten, die für die Kommunikation benötigt werden.
5. Wenn diese Daten beim Anrufenden angekommen sind, antwortet dieser mit der Acknowledgement Methode (ACK). Diese Methode wird ausschliesslich bei INVITE
verwendet.
6. Jetzt ist die Verbindung aufgebaut und Daten werden per RTP miteinander ausgetauscht.
7. Wenn einer der Gesprächspartner die Verbindung trennen will, schickt er einen BYERequest.
8. Dieser Request wird dann durch ein einfaches 200 bestätigt und das Gespräch ist beendet.
Um überhaupt ein Gespräch führen zu können, müssen einige Informationen über das
Kommunikationsmedium und die Übertragungsweise ausgehandelt werden. Dies geschieht
Grundlagen
17
in der Payload der INVITE-Message. Sie wird durch das Session Description Protokoll beschrieben, das im nächsten Kapitel erläutert wird.
1.2.3 SDP
Neben SIP benötigt man, wie zuvor schon angesprochen, auch noch das Session Description Protokoll, welches SIP sehr ähnlich ist, aber statt dem Verbindungsaufbau den
Austausch von benötigten Kommunikationsinformationen wie Codecs und Ports durchführt. Die Codecs müssen dabei nicht genau festgelegt werden. Es ist deshalb prinzipiell
sogar möglich, dass beide Parteien mit unterschiedlichen Codecs senden.
Die am wichtigsten auszutauschenden Informationren sind: die IP-Adresse für die Medienverbindung, die Art des Mediums, also Video und Audio, der Port, auf dem der Stream
erwartet wird und alle verschiedenen Codecs, die möglich sind. Folgende Abbildung zeigt
eine typische SDP-Payload, die einer INVITE-Nachricht angehängt ist:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected] (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
Abbildung 3: SDP- Payload [8]
Der Inhalt besteht also immer aus einer Zeile mit einem Buchstaben beginnend, der den
Parameter spezifiziert, gefolgt von der gewünschten näheren Beschreibung des Inhalts
dieses Parameters. Die möglichen Parameter sehen wie folgt aus:
Grundlagen
18
Session description
v=
protocol version
o=
owner and session identifier
s=
session name
i*12=
Session information
u*=
URI of description
e*=
email address
p*=
phone number
c*=
connection information - not required if included in all media
b*=
bandwidth information
t=
time the session is active
r*=
zero or more repeat times
z*=
time zone adjustments
k*=
encryption key
a*=
zero or more session attribute lines
Media description (beliebig viele)
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
Tabelle 3: SDP Parameter [8]
Da die Nachrichten nur beinhalten, an welchem Port und welche Daten erwartet werden,
können unter Umständen Probleme auftreten. Schickt beispielsweise der UAS eine Liste
von Codecs, von denen der UAC keinen beherrscht, so bietet sich keine Gelegenheit mehr,
dies dem UAS zu melden. Deshalb kann der UAC nur das Gespräch aufnehmen und dann
direkt wieder beenden. Der Partner versteht in diesem Fall nicht, warum die Verbindung
fehlschlägt[8].
Anderenfalls ist eine Verbindung erfolgreich aufgebaut und eine RTP-Verbindung wird
aufgebaut, um die Gesprächsdaten zu transportieren.
12 * bedeutet optionale Beschreibung
Grundlagen
19
1.3 RTP
RTP ist das Protokoll, das für die Übertragung der Sprachsignale zuständig ist (und
auch der Videosignale, falls Videoübertragung erfolgen soll). RTP wurde von der AudioVideo Transport Working Group (AVT WG)13 für den Transport von Nutzdaten im
zeitsensitiven Modus entwickelt. Dafür hat es spezielle Eigenschaften wie:
•
•
•
•
Identifizierung des Datentyps
Folgenummerierung
Zeitstempel
Auslieferungsüberwachung
Den genauen Inhalt eines RTP-Headers wird hier in Abbildung 4 dargestellt:
V P
X
CC
M
PT(7Bit)
Sequence Number (16 Bit)
Timestamp (32 Bit)
Synchronisation Source ( SSRC) Identifier (32 Bit)
Contributing Source (SSRC) Identifier (32 Bit)
V: Version (2 Bit)
P: Padding (1 Bit)
X: Extension (1 Bit)
CC: Contributing Source Count (CSRC) (4 Bit)
M: Marker (1 Bit)
PT: Payload Type (7 Bit)
Abbildung 4: RTP-Header[9]
Nachdem Sprache durch Aufnahme, Digitalisierung und Komprimierung durch einen
Codec in Audiodaten umgewandelt wurde, werden diese Audiodaten als Stream versendet.
Die Einheiten sind dabei sehr klein, meistens wird alle 20ms ein Paket verschickt. Jeder
Dateneinheit geht ein RTP-Header voraus. Und RTP-Header und die Audio-Dateneinheit
werden zusammen wiederum in ein UDP-Paket verpackt und dieses schließlich in ein IPPaket (siehe Abbildung 5).
13 im Auftrag der IETF
Grundlagen
20
Realtime-Time-Daten 20-150 Byte
RTP
UDP
IP
12-Byte-Header
8-Byte-Header
20-Byte-Header
Abbildung 5: Audio-Paket mit Header
Der RTP-Header zeigt an, welcher Kodierungstyp verwendet wird, den Payload Type
(PT). Deshalb ist es auch möglich, während des Sendens das Kodierungsverfahren zu
wechseln. Zudem enthält jedes Paket einen Zeitstempel und eine Sequenznummer, da im
Internet beim Verwenden von UDP häufig Pakete verloren gehen und/oder in der falschen
Reihenfolge beim Empfänger eintreffen können. Dadurch können die Pakete beim Empfänger sinnvoll wieder zusammengefügt werden. Der Empfänger erfährt dadurch auch etwas über die Qualität der Verbindung und kann diese dann eventuell anpassen. Dies geschieht dadurch, dass die Datenübertragung vom Realtime Control Protokoll (RTCP) überwacht wird. RTCP basiert auf einem regelmäßigen Kontrollpaketeaustausch zwischen den
Teilnehmern. Dabei wird ein Feedback über die Dienstgüte ausgetauscht und QoS-Parameter werden dann passend gesetzt [9].
Übliche Audio-Kodierungen und deren Payloadtyp zeigt nun Tabelle 4:
PT
Kodierung
0
PCMU
1
reserved
2
reserved
3
sample/fra
me
Sample Rate (Hz)
Kanäle
sample 8,000
1
GSM
frame
8,000
1
4
G723
frame
8,000
1
5
DVI4
sample 8,000
1
6
DVI4
sample 16,000
1
7
LPC
frame
8,000
1
8
PCMA
sample 8,000
1
9
G722
sample 8,000
1
Grundlagen
21
PT
Kodierung
sample/fra
me
Sample Rate (Hz)
Kanäle
10
L16
sample 44,100
2
11
L16
sample 44,100
1
12
QCELP
frame
8,000
1
13
CN14
frame
8,000
1
14
MPA
frame
90,000
variabel
15
G728
frame
8,000
1
16
DVI4
sample 11,025
1
17
DVI4
sample 22,050
1
18
G729
frame
1
8000
Tabelle 4: RTP Audio-Codecs nach [9]
Weitere Codecs wie die G726-xx, G729D, G729E, GSM-EFR, L8, RED und VDVI bekommen dynamische PT-Nummern, die von 96 bis 127 aufwärts vergeben werden können.
Andere Nummern sind dabei entweder reserviert oder für Videokodierungen festgelegt.
RTP wird analog zu der Audioübertragung auch für Videoübertragung verwendet [10].
Da die Sprache nur mit einem Mikrofon aufgenommen wird, reicht ein Kanal (Mono)
bei der Übertragung aus. Stereo Sound und noch mehr Kanäle sind ebenfalls möglich,
werden hier aber nicht näher betrachtet.
Wie die Tabelle 4 zeigt, sind die Kodierungen entweder sample-basiert oder frame-basiert.
Bei der sample-basierten Kodierung ist jede Abtastrate fest durch eine gegebene Größe
in Bits gegeben. Die kodierten Daten sind daraufhin variabel. Samples werden individuell
kodiert, z.B. durch Delta Modulation. Ein RTP-Audio-Paket kann dabei eine beliebige Anzahl von Samples enthalten und die Dauer des Audio-Pakets wird durch die Anzahl der
Samples festgelegt.
Frame-basierte Kodierungen packen einen Audioblock fester Länge in einen anderen
Block komprimierter Daten, der üblicherweise auch eine feste Länge besitzt. Man wendet
also ein Zeitfenster auf den Samplestrom an. Jede Gruppe von Samples nennt man dann
Frame, dieser wird in einen kürzeren Bit-Stream kodiert. Der Sender kann mehrere solcher
14 comfort noise ist kein üblicher Codec, er dient zum Erzeugen von künstlichem Rauschen zur
Unterdrückung von Pausen voller Stille in Gesprächen (näheres siehe RFC3389)
Grundlagen
22
Frames zusammen in einem RTP-Paket verschicken. Für den Empfänger ist es dann leicht
möglich wegen der festen Länge der Frames diese wieder aus dem Paket zu extrahieren,
indem er es einfach in der durch die Kodierung festgelegten Größe teilt. Die Codecs
können also aufeinander folgende Frames in einem Paket direkt bearbeiten ohne die Anzahl der Frames wissen zu müssen. Um den Audiostream später auch wieder richtig zu
erhalten, sind die Frames in einem Paket nach der zeitlichen Reihenfolge sortiert, so dass
das erste Frame immer das älteste ist. Im Gegensatz zu samplebasierten Kodierungen, bei
denen fast keine Verzögerung stattfindet, entsteht bei framebasierten Kodierungen eine
kurze Verzögerung dadurch, dass erst das ganze Frame aufgenommen werden muss, bevor
es kodiert werden kann.
Frame 1 Frame 2 Frame 3
Zeitfenster
Begin n d er
Kod ier u n g
Abbildung 6: framebasierte Kodierung
Im folgenden werden ein paar der wichtigen Codecs genauer betrachtet:
•
PCMU/PCMA:
PCMU, auch als Ulaw oder ?-Law bekannt, und PCMA, ebenso Alaw genannt, wurde
von der ITU in ihrer Empfehlung G.711 spezifiziert. Es handelt sich hierbei um eine sample-basierte Kodierung mit 8 Bits pro Sample. Sie wird mit einer logarithmischen Kennlinie von 12 auf 8 Bit pro Abtastwert komprimiert. Die logarithmische Kennlinie wird
verwendet, da es wahrscheinlicher ist, dass viele Signale bei einer niedrigeren Signalstufe
vorkommen als bei einer hohen. Um die Besonderheiten der menschlichen Wahrnehmung
zu berücksichtigen, wird nur der Frequenzbereich von 300 bis 3400 Hz übertragen. PCMA
wird bei ISDN verwendet und wird deshalb auch von den meisten IP-Telephonen bevorzugt, weil dadurch Sprachdaten an Gateways zum PSTN nicht umcodiert werden müssen,
sondern direkt über ISDN weiterlaufen können. Genauso wie bei ISDN benötigt PCMU
eine Nettobandbreite von 64kBit/s in beide Richtungen, was mit Headern sogar noch bis
auf 80kbit/s ansteigt (vgl. auch Abbildung 4). Während Ulaw in Nord-Amerika und Japan
als Standard gewählt wurde, wird Alaw in Europa und dem Rest der Welt bevorzugt[11].
Grundlagen
23
•
G.729
Deshalb wird häufig G.729 als alternative für PCMU angeboten, falls die Verbindung
schlechter ist. Die benötigte Bandbreite ist dabei mit 8kbit/s um fast 90% geringer als bei
PCMU, bei fast gleicher Sprachqualität, die immer noch viel besser als bei Mobiltelefonen
ist.
• DVI4
DVI415 verwendet Adaptive Differential Pulse Code Modulation16 (ADPCM) und ist
eine sample-basierte Kodierung mit 4 Bit pro Sample. Es verwendet nur die Unterschiede
zwischen den Samples und passt die Skalierung der Kodierung dynamisch bei großen und
kleinen Unterschieden an. Das Verfahren benötigt eine viel geringere Bandbreite als normale PCM und ist einfach zu implementieren, aber es tritt viel weißes Rauschen auf.
Weißes Rauschen nennt man ein Rauschen mit derselben Amplitude in jeder Frequenz.
Akustisch wird dieses Signal so wahrgenommen, als ob die Amplitude mit der Frequenz
anstiege, da im menschlichen Gehör die Empfindlichkeit mit zunehmender Frequenz logarithmisch ansteigt. Der Höreindruck gleicht dem eines stimmlosen "sch" [12].
• G.723
Der frame-basierte Standard G723 wurde in der Empfehlung G.723.1, "Dual-rate speech
coder for multimedia communications transmitting at 5.3 and 6.3kbit/s" von der ITU
vorgestellt. Die Sprache wird dabei also in sehr geringen Bitraten übertragen. Frames
können entweder 24 Oktette (6.3 kb/s frame), 20 Oktette (5.3 kb/s frame) groß oder, falls
in kleinen Geprächspausen die Stille unterdrückt wird, ein sogenanntes Silence Insertion
Descriptor (SID)17 Frame von 4 Oktetten sein. Die Frames können miteinander beliebig
vermischt werden, denn am Anfang jedes Frames werden in 2 reservierten Bits der Typ
und damit die Länge des Frames angegeben. Die Audiolänge der Frames ist immer auf
30ms festgelegt. Durch die framebasierte Kodierung entsteht eine Verzögerung von 7.5ms
wegen des Look-Aheads.
Die Sprachübertragung von all diesen Codecs ist aber immer nur so gut wie es die Internetverbindung hergibt. Bei einer Verzögerung von unter 150ms spricht man nach den Telefonnormen ( ITU Recommendation G.109) von sehr guter Qualität. Bis 400ms ist die
Übertragungsqualität noch akzeptabel, darüber aber ist die Verzögerung schon störend,
weil sich die Gesprächspartner dann gegenseitig ins Wort fallen.
Ein anderes Problem ist eine unregelmäßige Übertragung: der Jitter. Dabei werden Pakete, die nicht schnell genug ankommen, ausgelassen und die Sprache setzt für einen
Moment aus oder Pakete, die zu schnell aufeinander folgen, werden als Knacken hörbar.
Deshalb speichert der Empfänger die Pakete in einem sogenannten Jitter-Puffer. Falls
dieser zu klein ist, kommt es also zu Übertragungsfehlern, ist er zu groß, kommt es zu
15 http://www.cs.columbia.edu/~hgs/audio/dvi/
16 abgeleitet von dem "IMA ADPCM wave type" der Interactive Multimedia Association (IMA)
17 Auch als comfort noise bekannt
Grundlagen
24
einer zu großen Verzögerung. Gehen Pakete komplett verloren und können wegen der Verzögerung nicht neu angefordert werden, muss der Codec diese Pakete ausgleichen. Wenn
maximal 5% Verlust auftritt, ist dies beim Gespräch nicht hörbar [13].
Nachdem nun die wichtigsten Grundbegriffe der VoIP-Telefonie näher erläutert
wurden, geht es in den nächsten Kapiteln um eine ganz andere neue Internet Technologie,
die Web-Services. Dabei handelt sich um ein nicht weniger aktuelles Thema. Verwendung
von Web-Service breitet sich rasant aus. In dieser Projektarbeit werden nun IP-Telefonie
und Web-Services kombiniert.
1.4 Web-Services
Das World Wide Web Consortium W3C definiert Web-Services in der Spezifikation18
von 2002 wie folgt:
Ein Web-Service ist ein durch eine URI festgelegtes Softwaresystem, dessen öffentliche
Schnittstellen und Verbindungen durch XML definiert und beschrieben werden. Diese Definition kann von anderen Softwaresystemen aufgefunden werden. Diese Systeme können
dann mit dem Web-Service in der Art wie sie in dessen Beschreibung definiert wurde auf
Basis von über Internet-Protokollen verschickten XML-Dokumenten kommunizieren.
Web-Services nutzen dabei üblicherweise spezielle Standards wie HTTP, SOAP , XML,
WSDL und UDDI um ihre Dienste zur Verfügung zu stellen. Was man darunter versteht
wird nun im folgenden genauer erklärt.
1.4.1 XML
Extensible Markup Language (XML) ist ein Framework um Dokument Markup
Languages (Auszeichnungssprachen) zu definieren. XML hat sich als System für den Dokumentaustausch über das Internet weitgehend durchgesetzt. Eine Dokument-MarkupLanguage ist ein Satz von Elementen (Tags). Diese Tags haben die üblich verwendeten
Eigenschaften von Dokumenten, wie Struktur, Inhalt und Darstellungsinformationen.
Eine Document Type Definition (DTD) ist eine Datei in Standard Generalized Markup
Language (SGML) oder in XML, in der die Regeln (Grammatik) zum Aufbau einer XMLDatei beschrieben werden. XML Schemata 19 sind die funktionserweiterten Nachfolger von
DTDs und sind selbst in XML definierbar. Wenn sich mehrere Kommunikationspartner auf
18 http://www.w3.org/TR/2002/WD-ws-gloss-20021114/
19 http://www.w3.org/TR/xmlschema-0/
Grundlagen
25
ein solches, für alle Zwecke leicht anpassbares Schema geeinigt haben, können Dokumente
danach erstellt und miteinander ausgetauscht werden. Alle Anwendungen können diese
Dokumente dann verarbeiten. Der Inhalt kann dann auch an andere Formate, wie html oder
pdf, geliefert werden [14].
•
•
•
•
•
•
•
•
•
•
•
Die wichtigsten Vorteile von XML sind:
Mit XML ist es möglich (fast) beliebig strukturierte Daten in einer Textdatei zu speichern.
Die DTD oder das Schema können zentral gehalten werden.
XML gestattet die syntaktische Validierung eines Dokuments.
XML-Werkzeuge (z. B. Parser) sind frei erhältlich.
Einfache Austauschbarkeit von Daten
XML Dateien können dynamisch oder statisch sein.
Formatierung und Programmierung von Dokumenten
erweitertes Linking [15]
XML ist lizenzfrei, plattformunabhängig und von den meisten Systemen unterstützt.
Wegen der Struktur gibt es effiziente Suchroutinen mit erweiterten Funktionen, wie
z. B. der Suche nach Dokumenten mit bestimmten Tags oder Similarity Search.
XML kann die Unicode-Standards UTF20-16 und UTF-8 verwenden und ist deshalb
prinzipiell vom Zeichensatz unabhängig. In der neusten Fassung von 2004 können sogar
Tags in anderen Sprachen definiert werden.
Ein einfaches XML Dokument, das für den Adressenaustausch definiert wurde, kann
dann folgendermaßen aussehen:
20 nach RFC3629
Grundlagen
26
<?xml version='1.0' encoding="ISO-8859-1" standalone="no"?>
<adresse>
<einzeladresse>
<name>Mustermann</name>
<vorn>Max</vorn>
<strasse>Triftstrasse 10</strasse>
<plz>67663</plz>
<ort>Kaiserslautern</ort>
<tel art="priv">0631/2345</tel>
<tel art="off">0631/2346</tel>
</einzeladresse>
Abbildung 7: XML Beispiel
1.4.2 SOAP
Mit dem SOAP wird die interne Struktur der XML-Dokumente beschrieben, die WebServices konsumieren und produzieren. Der Inhalt dieser Dokumente ist in XML verfasst.
SOAP ist ein bekannter Industriestandard der sich durchgesetzt hat21. Er wurde zusammen
von IBM, Microsoft, Userland und DevelopMentor speziell für Remote-Procedure-Calls
und andere Requests über HTTP entwickelt, kann aber ebenso z. B. über FTP, TCP,
SMTP, POP3, MQSeries und Jabber erfolgen. SOAP ist unabhängig vom zugrundeliegenden Transportprotokoll. Der Vorteil von SOAP besteht darin, dass zwei unterschiedliche Anwendungen plattformunabhängig und auch nicht beschränkt auf eine Programmiersprache oder ein Protokoll Informationen durch eine einfache XML-basierte
Nachricht austauschen können [16].
Abbildung 8: SOAP Umschlag
21 http://www.w3.org/TR/SOAP/
Grundlagen
27
Eine SOAP-Nachricht besteht aus einem Umschlag (Envelope), der optional einen
SOAP-Header und danach einen erforderlichen Body enthält (vgl. Abb. 8). Der Header
enthält Information zur Nachrichtverarbeitung, wie Angaben zum Routing, der Authentifizierung oder der Autorisierung. Der Body beinhaltet die eigentliche zu versendende und zu
verarbeitende Nachricht in freier XML-Syntax.
Das folgende Beispiel zeigt eine typische SOAP Anfrage anhand der Abfrage des aktuellen Kurses der IBM Aktie (siehe Abbildung 9). Dabei beruht die XML-Syntax für die
Formulierung auf dem Namensraum http://www.w3.org/2001/06/soap-envelope. Diese
RPC-Anfrage ruft die Funktion getQuote(String symbol) auf dem Server für
"symbol=IBM" auf. Daraufhin sendet der Server eine SOAP Message mit dem Kurs
"98.06" zurück (Abb. 10) [17].
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope">
<s:Header>
<m:transaction xmlns:m="soap-transaction"
s:mustUnderstand="true">
<transactionID>1234</transactionID>
</m:transaction>
</s:Header>
<s:Body>
<n:getQuote xmlns:n="urn:QuoteService">
<symbol xsi:type="xsd:string">
IBM
</symbol>
</n:getQuote>
</s:Body>
</s:Envelope>
Abbildung 9: SOAP Aktienkurs Anfrage
Grundlagen
28
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope">
<s:Body>
<n:getQuoteRespone
xmlns:n="urn:QuoteService">
<value xsi:type="xsd:float">
98.06
</value>
</n:getQuoteResponse>
</s:Body>
</s:Envelope>
Abbildung 10: SOAP Aktienkurs Antwort
1.4.3 URI
Der Uniform Resource Identifier (URI22) ist eine Zeichenfolge um eine virtuelle oder
physikalische Quelle zu identifizieren. Er legt die Eindeutigkeit des Web-Services durch
eine Adresse fest. Ein URI kann ein Uniform Resource Locator (URL) (z. B.
http://www.uni-kl.de) oder ein allgemeiner gefasster Uniform Resource Name (z. B.
URN://www.uni-kl.de) sein. Durch den URI kann ein Web-Service gefunden und seine
Dienste in Anspruch genommen werden. Der noch später genauer erklärte Web-Service
Venice hat zum Beispiel die URL: http://venture.informatik.uni-kl.de:14080/VoiceIPWebService_ICSY-jaxrpc [18].
1.4.4 WSDL
Web-Services sind selbstbeschreibend. Diese Beschreibung erfolgt durch die auf XML
basierende Web Services Definition Language23. Sie ist also aufgrund der XML-Eigenschaften plattform-, programmiersprache- und protokollunabhängig. Sie enthält folgende
Informationen für die Außenwelt über:
22 RFC 2396
23 http://www.w3.org/TR/wsdl
Grundlagen
•
•
•
29
die Schnittstellendefinition: Die Art der Dokumente, die übertragen werden. Die
Funktionsweise und der Zweck des Web-Services und wie dieser von einem Konsumenten benutzt werden kann.
Die URI: eindeutige Adresse des Web-Services
das Binding: welche Transportprotokolle für die Kommunikation verwendet
werden [19]
Zur Veranschaulichung zeigt Abbildung 11 eine gekürzte WSDL-Datei eines einfachen
Web-Services, der eine Temperatur von Fahrenheit in Celsius umrechnet.
Grundlagen
30
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://Walkthrough/XmlWebServices/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://Walkthrough/XmlWebServices/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified" targetNamespace="http://Walkthrough/XmlWebServices/">
<s:element name="ConvertTemperature">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="Fahrenheit" type="s:double" />
</s:sequence>
</s:complexType>
</s:element>
...
</types>
<message name="ConvertTemperatureSoapIn">
<part name="parameters" element="s0:ConvertTemperature" />
</message>
...
<portType name="Service1Soap">
<operation name="ConvertTemperature">
<documentation>This method converts a temperature in degrees Fahrenheit to a temperature in degrees Celsius.</documentation>
<input message="s0:ConvertTemperatureSoapIn" />
<output message="s0:ConvertTemperatureSoapOut" />
</operation>
</portType>
<binding name="Service1Soap" type="s0:Service1Soap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="ConvertTemperature">
<soap:operation soapAction="http://Walkthrough/XmlWebServices/ConvertTemperature" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="Service1">
<documentation>A temperature conversion service.</documentation>
<port name="Service1Soap" binding="s0:Service1Soap">
<soap:address location="http://www.xprogramming.com/webservices/service1.asmx" />
</port>
</service>
</definitions>
Abbildung 11: Beispiel WSDL für Temperaturkonverter 24
24 http://www.xprogramming.com/webservices/service1.asmx?WSDL
Grundlagen
31
Am 15. März 2001 wurde die WSDL Version 1.1 vorgestellt. Sie ist eine W3C Note. In
dem Working Draft Version 2.0 wurden die Sprachdefinition (core language) und die
Nachrichten-Muster (message exchange patterns) weiterentwickelt.
1.4.5 UDDI
Die Universal Description, Discovery and Integration (UDDI) Spezifikation beschreibt
einen Register-Dienst für Web-Services, andere elektronische und auch nicht elektronische
Dienste. Ein solches Register verwaltet Informationen über die Dienstanbieter (Provider)
und die Art und Schnittstellen der Dienste. Deshalb wird auf der einen Seite UDDI
verwenden, um aktiv Dienste anzubieten und dafür zu werben. Und auf der anderen Seite
können Nutzer von Diensten durch UDDI passende Dienste inklusive der zugehörigen Informationen finden und diese dann in Anspruch nehmen. Dazu werden ebenfalls die Standards SOAP, WSDL und XML verwendet. UDDI stellt die folgenden drei Basisfunktionen
zur Verfügung (Abb. 12):
•
•
•
publish: Das Veröffentlichen eigener Web-Services um von anderen leichter gefunden
zu werden.
find: Das Suchen (Query) und Finden (Discovery) von speziellen Web-Services
bind: Das Verbinden zu dem gefundenen Web-Service
UDDI
2. Query
1. Publish
3. Discovery
4. Bind
Service
Requester
Service
Provider
Abbildung 12: UDDI
Grundlagen
32
Die großen öffentlichen UDDI-Register gleichen sich regelmäßig miteinander ab, damit
sie alle auf dem gleichen Stand bleiben. Besonders bekannt ist das Universal Business Register (UBR), das ein Verzeichnis der öffentlich verfügbaren e-commerce Dienste anbietet.
Diese beinhalten Informationen in drei Teilen: Erstens stehen dort Details über Adresse
und weitere Kontaktmöglichkeiten der anbietenden Firma (white pages), zweitens deren
gewerbliche Klassifizierungen (yellow pages) und drittens technische Details, wie die Spezifikation des Web-Services (green pages). Zur Zeit wird das UBR in Zusammenarbeit von
IBM, Microsoft, NTT Com und SAP geleitet.
UDDI hilft also besonders im gewerblichen Bereich beim Auffinden des passenden
Angebots aus Millionen Online Angeboten. Auf der anderen Seite hilft es auch den Firmen
neue Kunden zu gewinnen und den Kontakt zu alten Kunden zu verbessern.
1.4.6 In der Praxis
In der praktischen Anwendung kann man die Definition dann etwas enger fassen.
Definition 2:
Ein Web-Service ist eine Einheit, beschrieben durch ein WSDL-Dokument, die an ihrer
URI existiert und SOAP Dokumente mit der Welt austauscht und in einem UDDI
Verzeichnis eingetragen und gefunden werden kann.
Wie schon der Name sagt, bieten Web-Services Dienste über das World Wide Web
(WWW) an. Eine Anfrage wird geschickt und darauf eine Antwort geliefert. Die Möglichkeiten sind vielfältig. Ein Web-Service kann periodische Sensordaten senden, oder man
kann ebenfalls eine spezielle Anfrage über das aktuelle Wetter an verschiedenen Orten
erfragen. Die Dokumente können also einseitig und asynchron verschickt werden oder synchron in einem Request-Response Modell.
Die meisten Web-Services nutzen einen RPC über XML. Entwickler können so schon
existierende Anwendungen einfach zu Web-Services umwandeln, ohne große Veränderungen durchführen zu müssen. Es gibt Web-Service Entwicklungstools die den Programmierer unterstützen und solche Umwandlungen durch automatische Codegenerierung
erleichtern. WSDL Dokumente werden dadurch direkt aus dem Quellcode generiert. WebServices werden auch häufig für die Interaktion zwischen heterogenen Applikationen eingesetzt, um zwischen diesen ein Interface zu erzeugen.
Web-Service basierte VoIP-Lösung
33
2 Web-Service basierte VoIP-Lösung
2.1 Problemstellungen
In Kapitel 1.1 wurde bereits dargelegt, dass es die verschiedenen Protokolle für VoIP
gibt, die nicht so einfach miteinander kommunizieren können. Insbesondere haben sich die
beiden Standards H.323 und SIP stark durchgesetzt und werden wegen ihren unterschiedlichen Vorteile auch noch lange koexistieren. Die bisherigen VoIP Systeme basieren auf
Clientprogrammen, die fest in den Endgeräten installiert sind und sowohl das Signaling als
auch die Medienverarbeitung übernehmen. Dadurch ist die Software erstens sehr umfangreich und zweitens muss bei Protokolländerungen und Einführen von neuen Features
immer wieder in allen Clients ein Update durchgeführt werden. Das bringt nicht nur viel
Aufwand, sondern auch hohe Kosten mit sich und ist zudem problemanfällig. Diese
Standalone-Software lässt sich auch schwierig in andere Applikationen integrieren, meistens müssen solche dafür komplett neu entwickelt werden.
Oft schützen Firewalls das Intranet vor Zugriffen aus externen Netzen. Das hat zur
Folge, dass ein externer Anrufer ohne weitere Maßnahmen gar nicht die Chance hat, einen
VoIP Anruf zu initiieren, da alle Pakete von der Firewall abgefangen werden.
Auftretende Probleme wie
• verschiedene Protokolle
• Aufwand bei Clientupdates
• Größe der Software
• Integration in andere Systeme
• Firewall
sind sehr störende Faktoren für die weitegehende Ausbreitung und Verwendung von VoIP.
Es wurden schon einige Verbesserungen entwickelt, um diese Probleme zu vermeiden.
Für die verschiedene Protokolle existieren Gateways, die zwischen diesen übersetzen [4].
Um Clientupdates zu vereinfachen, werden VoIP Programme auch als Web-Applikationen angeboten. Der Webbrowser ruft dann immer die aktuelle Version des Programmes
auf, dadurch ist aber eine Integration in eigene Applikationen sehr schwierig. Deshalb
werden für die bessere Integrierbarkeit Programmierschnittstellen (APIs) entwickelt, jedoch benötigen diese trotzdem noch eine enge programmiertechnische Integration der
VoIP-Software in die anderen Applikationen.
Für das Firewall Problem gibt es Lösungen die mit Proxy Servern arbeiten. Zum Beispiel Firewall Controlling Proxies, die dann der Firewall die erlaubten Verbindungen
angeben. Alle diese Lösungen sind mehr oder weniger zufrieden stellend.
34
2.2 Idee
Eine neue Lösung stellt dabei das Anbieten eines VoIP Systems durch Web-Services dar.
Dabei übernimmt ein Web-Service die Kommunikation mit den Signaling Protokollen. Der
Client wendet sich, wenn ein neuer Anruf erwünscht wird, an den Web-Service, der dann
dabei hilft, die Verbindung aufzubauen. Durch dieses Auslagern der Funktionalität des
Signaling von den Clients auf die Web-Services wird die Größe der Clientsoftware enorm
reduziert. Der Client muss nur den Aufruf des Web-Services kennen und später den Datenaustausch über RTP durchführen. Dadurch wird das Updaten der Clientsoftware auch nicht
mehr so oft benötigt, da meistens Updates am Web-Service ausreichen. Diese Simple Clients (SC) kommunizieren über die in der entsprechenden WSDL-Datei angegebenen Protokolle, meist mittels SOAP. Weil Clients für Web-Services leicht zu entwickeln sind, besteht die Möglichkeit solche Lösungen einfach auch in andere Applikationen zu integrieren.
RTP
H.323-Telefon
Simple Client
SOAP
RTP
H323
SIP-Client
VoIP Web-Service
SIP Web-Service
H.323 Web-Service
SIP
Abbildung 13: VoIP über Web-Service
In Abbildung 13 kommuniziert ein Simple Client per RTP mit einem H.323 und einem
SIP Telefon. Nachdem der Simple Client über SOAP die Verbindung über den VoIP WebService angefragt hat, leitet dieser die Anfrage über einen anderen (Web-)Service, der das
benötigte Protokoll versteht, an das externe Telefon weiter. Es werden in dem Modell verschiedene Web-Services verwendet, um eine bessere Modularität zu erhalten, und auch um
ein Verteilen der Web-Services auf verschiedenen Servern zu ermöglichen. Natürlich
35
können Simple Clients auch direkt miteinander kommunizieren, in diesem Fall werden die
Layer 1 Web-Services und die anderen Protokolle gar nicht benötigt.
Das folgende Beispiel zeigt, wie ein Verbindungsaufbau von einem Simple Client zu
einem SIP User Agent prinzipiell aussehen kann:
SC
VoIP Service
SIP Service
SIP UA
Make_Call
Make_Call
Ringing
Ok
Ok
Ringing
Ok
Ok
INVITE
Ringing 180
Ok
200
ACK
Verbindung ist aufgebaut
Abbildung 14: Verbindungsaufbau Simple Client nach SIP UA
Der Simple Client ruft zuerst die Methode makeCall() des Web-Services auf. Damit
meldet er, dass er einen Anruf beginnen will und an wen dieser Anruf gesendet werden
soll. Der Web-Service leitet diesen Aufruf dann an den SIP-Service weiter, welcher ihn in
eine SIP INVITE-Methode übersetzt. Wenn diese bei dem adressierten SIP UA eingetroffen ist, sendet er zuerst mit der Zwischenmeldung 180 zurück, dass der Anruf in Bearbeitung ist. Nach Interaktion des Benutzers wird, falls dieser sich entschlossen hat den
Anruf anzunehmen, eine SIP Antwort 200 geschickt. Diese geht auch wie die Ringing-Antwort den gleichen Weg zurück, den sie gekommen ist. Darauf hin übermittelt der Simple
Client nochmal ein OK, dass der Verbindung nichts mehr im Wege steht (doppelter
Handshake). Nachdem der SIP Web-Service das OK als ACK weitergeleitet hat, beginnt
die Mediendatenübertragung per RTP direkt zwischen den beiden Clients.
Nachdem bis jetzt nur Theorie besprochen wurde, wird nun im Folgenden auch eine
praktische Implementierung gezeigt.
36
2.3 Projekt Venice
In dem Projekt Venice, das dieser Arbeit zugrunde liegt, wird die Umsetzung von VoIP als
Web-Service erforscht und durch eine Implementierung in Java getestet [20].
Unter einer Implemetierungsklasse VoiceIPWeb-Service werden dabei verschiedene Dienste zusammengefasst und als Web-Service nach aussen angeboten. Dort meldet
sich dann ein Client an und der Service hilft bei der Vermittlung von Gesprächen. Für die
Anmeldung benötigt er zuerst die Dienste des AuthenticationService, der die
Benutzer verwaltet. Der AuthenticationService enthält einen Usermanager, der
mit Hilfe in einer XML-Datei oder einer SQL25 Anfrage auf eine Datenbank, in der alle
Benutzer und deren Passwörter gespeichert sind, den Benutzer auf Rechtmässigkeit überprüft. Will ein Simple Client sich an dem Web-Service anmelden, muss er sich erst mit der
Funktion login() registrieren. Ist der Benutzer authentifiziert und autorisiert, bekommt
er vom Web-Service eine eindeutige Anmelde-ID, Lease genannt, die durch die Methode
refreshLease() in bestimmten Zeitintervallen immer wieder verlängert werden muss,
ansonsten gibt es ein Timeout und der Benutzer wird automatisch abgemeldet. Natürlich
gibt es auch eine Funktion logout() zum Abmelden.
Der andere wichtige Dienst, der zur Verfügung steht, ist der VoiceIPService. Er
hat die Verarbeitung von VoIP Telefonaten zur Aufgabe. Im aktuellen Stand der Entwicklung stehen dazu folgende Methoden zur Verfügung:
initCall()
Bereitet ein Gespräch vor
makeCall()
Leitet einen Anruf ein
acceptCall()
Nimmt einen Anruf an
denyCall()
Lehnt einen Anruf ab
endCall()
Beendet einen bestehenden Anruf
Tabelle 5: VoIP Web-Service Methoden
25 Datenbank-Abragesprache
37
Abbildung 15: Venice Web-Services
Jede aufgebaute Verbindung wird dabei von einem sogenannten CallHandler
verwaltet. Dieser wird automatisch vom VoiceIPService erzeugt, wenn ein Gespräch
aufgebaut werden soll und weist der Verbindung eine eindeutige CallID zu, die genauso
wie auch Lease eine Universal Unique Identifier (UUID) ist. Ein CallHandler kann
RemoteCallhandler oder LocalCallHandler sein. Sind die zwei Benutzer an
entfernten Web-Services angemeldet, braucht man den RemoteCallHandler, dieser
verwendet eine WSBridge, welche die Kommunikation zwischen den beiden Web-Services übernimmt. Die CallHandler sind die Klassen, die für das Senden und Empfangen von Nachrichten zuständig sind. Sie besitzen dazu Funktionen wie makeCall(),
acceptCall() und endCall(), durch welche sie Events an die Clients leiten können.
Folgendes Sequenzdiagramm (Abbildung 16) zeigt die zeitliche Reihenfolge und die
beteiligten Komponenten bei einer Kommunikation zweier Simple Clients in Venice:
Abbildung 16: Venice Verbindungsaufbau mit Remote Web-Service
38
39
Abbildung 17: Venice Simple Client
Der Simple Client (Abbildung 17) ist ebenfalls in Java implementiert26, und zwar derzeit
als Java Webstart Applikation, die automatisch bei jedem Neustart den Client auf eine
mögliche neuere Version überprüft. In einer späteren Ausbaustufe wird hierfür ein allgemeiner Software-Verteilungsdienst verwendet[21]. Das Programm ist dabei zustandsorientiert programmiert. Der Client befindet sich je nach aktuellem Status in einem bestimmten Zustand und vermag nur in passende Folgezustände zu wechseln. Das vermeidet
Fehler, denn diese werden bei unzulässigen Zuständen abgefangen. Das Diagramm in Abbildung 18 zeigt die verschiedenen Zustände:
Abbildung 18: Venice Simple Client Zustandsdiagramm
26 auch eine Version in C# existiert
40
Nach Start befindet man sich zuerst im Zustand "LOGIN". Bei einem erfolgreichen Login
erhält der Client eine bestimmte Lease und ist dann im Zustand "PICKUP". Dort kann er
entweder passiv auf einen eingehenden Anruf warten, wodurch er in "INCOMING"
wechselt, oder aktiv jemanden anrufen. Dies geschieht durch Ausführen von initCall(), wodurch der Client in den Zustand "MAKECALL" gelangt und danach erreicht er durch makeCall() den Zustand "CALLING". Bei Annahme eines Gesprächs gerät man in den Zustand "TALKING", ein Ablehnen oder Gesprächsende führt wieder nach "PICKUP" zurück. Das Zustandsmodell ist so ausgelegt, dass zu jeder Zeit neue Zustände integriert oder
alte Zustände ersetzt werden können [22][23].
2.4 Aufgabe
Die Aufgabe dieser Projektarbeit besteht nun darin, Venice zu erweitern. Es müssen auch
die Services der unteren Schicht implementiert werden, insbesondere ein Dienst, der die
Kommunikation mit SIP Clients ermöglicht.
Dazu soll eine Open-Source Software zur Verarbeitung von SIP (SIP Stack) in die Architektur von Venice integriert werden, um Gespräche von SIP Telefonen an Simple Clients des Venice Projektes und in die andere Richtung zuzulassen.
Im Kapitel 3 werden nun zuerst ein paar grundlegende Voraussetzungen und dann die
Entwicklung des SIP Services erläutert.
Realisierungsaspekte
41
3 Realisierungsaspekte
3.1 Voraussetzungen
Im folgenden werden die Bestandteile der Entwicklungsumgebung vorgestellt, die benötigt
werden und auch sehr hilfreich sind.
So wie auch der Venice Web-Service basiert der SIP-Service komplett auf Java27. Zusätzlich zu den Standard Bibliotheken werden aber auch noch spezielle Software-Pakete
verwendet, die nun dargestellt werden.
•
Java Web Services Developer Pack 1.328
Für die Web-Serviceentwicklung benötigt man noch das Java Web Service Developer
Pack. Dieses bietet alle Klassen, Bibliotheken und Werkzeuge, deren ein Java Entwickler
bedarf, um XML Anwendungen, Web-Service und Webanwendungen mit Web-Serviceintegration zu implementieren. Es enthält nicht nur die Java APIs für XML, Java Architektur für XML Binding (JAXB), JavaServer Faces, XML Security, JavaServer Pages
Standard Tag Library (JSTL), Java WSDP Registry Server, sondern auch das Ant Build
Tool von Apache und den Apache Tomcat container in der Version 5. Tomcat ist ein Webserver auf dem die Web-Services liegen und von dort aus ausführbar sind.
•
Java Media Framework 2.1.1e29
Die Java Media Framework API (JMF) hilft dabei Audio, Video und andere zeitbasierten
Medien in Java Programme einzubinden. Dieses Paket kann in verschiedenen Medienformaten senden, empfangen, aufnehmen und abspielen. Es unterstützt viele Codecs
(Tabelle 6). Im Projekt wird das JMF dazu verwendet, um die RTP Verbindung herzustellen und die Sprachdaten beim Telefonieren zu senden und zu empfangen. Sowohl der
Simple Client von Venice, als auch der SIPCommunicator 30 benutzen dieses Softwarepaket, da es sich für solche Java Anwendungen gut anbietet.
27
28
29
30
Sun Java 2 Standard Edition 1.4.2 (Http://java.sun.com/j2se )
http://java.sun.com/webservices/webservicespack.html
http://java.sun.com/products/java-media/jmf/
Mehr dazu später in Abschnitt 3.2.2
42
Media Type
RTP
Payload
JMF 2.1.1
Cross Platform Version
JMF 2.1.1 JMF
Solaris/Li 2.1.1
nux Per- Window
formance s PerPack
formance Pack
Audio: G.711 (U-law) 8 kHz
0 R31,T32
R,T
R,T
Audio: GSM mono
3 R,T
R,T
R,T
Audio: G.723 mono
4 R
R,T
R,T
Audio: 4-bit mono DVI 8 kHz
5 R,T
R,T
R,T
Audio: 4-bit mono DVI 11.025
kHz
R,T
R,T
R,T
16
Audio: 4-bit mono DVI 22.05 kHz
17 R,T
R,T
R,T
Audio: MPEG Layer I, II
14 R,T
R,T
R,T
Tabelle 6: von JMF unterstützte RTP Audio Codecs33
3.2 SIP-Stack
Die Kommunikation zu einem SIP Gerät beruht nun auf einem SIP Stack. Der Stack
stellt eine Implementierung des Protokolls nach den im RFC vorgeschlagenen Eigenschaften dar. Die Funktion des Stacks ist, auf einkommende SIP Nachrichten zu horchen,
solche Nachrichten zu analysieren und zu bestimmen (parsen) und einen Handler aufzurufen, der diese Nachricht passend verarbeitet. Für SIP Stacks gibt es viele Implementierungen. Hier wird eine Open-Source-Lösung benutzt. Im Prinzip ist es unerheblich,
welcher Stack verwendet wird, solange die Implementierung sich an die Standards hält.
Der SIP Stack aus dem vocal sip package34 ist ein bekannter Open-Source Stack. Dieses
Package besteht aus einer sehr umfassenden und ausgereiften, in C++ programmierten
Sammlung von SIP Tools. Ebenfalls beliebt ist das in C programmierte osip35, eine kleine
und effiziente Implementierung des RFC 2543 und das hier verwendete Nist SIP36, welches
einen Java Specification Request (JSR 32) darstellt und sich durch Aktualität und gute
Kompatibilität zu den RFCs auszeichnet.
31
32
33
34
35
36
indicates that the format can be decoded and presented
indicates that media streams can be encoded and transmitted in the format
http://java.sun.com/products/java-media/jmf/2.1.1/formats.html
http://www.vovida.org/protocols/downloads/sip
http://www.gnu.org/software/osip/osip.html
http://dns.antd.nist.gov/proj/iptel/
43
3.2.1 Nist Jain sip v1.1
Nist Sip wurde am National Institute for Standards and Technology (NIST) entwickelt
und JAIN37 zertifiziert. Es bietet nicht nur alles aus getreu RFC 3261, sondern hat sogar
noch Support für die SIP Erweiterungen, die in folgenden RFCs vorgeschlagen sind:
RFC 2976 (Sitzungskontrollinformationen), RFC 3262 (Verarbeitungsinformationen),
RFC 3265 (asynchrone Meldungen), RFC 3311 (aktuellere Sitzungsinformationen),
RFC 3326 (Grund für Request), RFC 3428 (Instant Messages) und RFC 3515 (Quellenreferenz). Diese werden in unserer momentanen Implementation noch nicht benötigt, jedoch können sie später, wenn neue Funktionen hinzukommen, sehr hilfreich sein.
Der Stack enthält Transaktions- und Dialogschicht. Die Transaktionsschicht behandelt
Retransmissionen und die passenden Antworten auf Requests. Die Dialogschicht gruppiert
Dialoge und ist nützlich bei der Entwicklung von zustandsorientierten Komponenten wie
User Agents und Proxy Servern. Diese implementieren die zugehörigen JAIN SIP Schnittstellen direkt. Der Aufbau des Stacks ist übersichtlich und wie für J2SE üblich eventbasiert. Ein Handler erzeugt eine sogenanntes JAIN Event und übergibt es an den registrierten
SIPListener. Eine Anwendung muss dann also immer das Listener Interface implementieren und kann dann dadurch mit dem Stack kommunizieren. Außerdem muss sich die
Anwendung bei dem sogenannten SIPProvider anmelden, um selber auch SIP Nachrichten senden zu können. Alle Meldungen sind also immer in Events gekapselt und
werden asynchron verschickt. Der SIPProvider empfängt Nachrichten aus dem Internet
und schickt sie als Events weiter an den SIPListener. Abbildung 19 zeigt die eventbasierte Architektur des JAIN SIP Stacks.
Abbildung 19: JAIN SIP Architektur
37 http://java.sun.com/products/jain/index.jsp
44
Das NIST SIP Stack Paket besteht dabei aus vielen Klassen. Die Packages die dabei zur
Auswahl stehen, heißen:
•
•
•
•
•
•
•
•
•
•
•
•
gov.nist.core:
Die Basisklassen, auf denen der Rest der Implementation beruht.
gov.nist.javax.sdp:
Implementation von SDP Klassen (nach JSR 141)
gov.nist.javax.sip:
Das Wurzelverzeichnis für die SIP Implementierung. Das SIP Stack Interface verwaltet
Listening Points und Listening Provider. Der Stack ist mit einer IP-Adresse verbunden
und kann mehrere Listening Points besitzen. In einer Anwendung können sich mehrere
Stacks befinden. Ein Stack wird mit der SipFactory erzeugt. Dabei werden spezielle
Eigenschaften des Stacks in der Konfiguration gesetzt.
gov.nist.javax.sip.address:
die adressspezifischen Klassen, wie die Address Factory
gov.nist.javax.sip.header:
die SIP Header Klassen und die Implementierung der JAIN-SIP Header Factory
gov.nist.javax.sip.parser:
Parser für SIP Headers, URL's und Adressen. Der Parser konsumiert entweder einen
Stream, falls TCP verwendet wird, oder den Eingang aus einem Puffer, falls UDP
benutzt wird, und liefert daraus eine analysierte Nachrichtenstruktur.
gov.nist.javax.sip.stack:
Klassen für den Aufbau des SIP-Stacks
javax.sdp:
Klassen für den Stack nach JSR 141.
javax.sip
die wichtigsten Interfaces des SIP Stacks
javax.sip.address
die Interfaces von Adresskomponenten von SIP
javax.sip.header
Header Interfaces
javax.sip.message
Message Interfaces
Die Erzeugung neuer SIP Objekte erfolgt über Factories. Diese Klassen verfügen über
alle Funktionen für Eigenschaften nach den SIP Standards.
Am wichtigsten ist die SipFactory, mit Ihr werden neue SIP Objekte und andere
Factory Objekte erzeugt (siehe Abbildung 20).
45
try
{
Properties properties = new Properties();
properties.setProperty("javax.sip.IP_ADDRESS", "131.246.103.22");
properties.setProperty("javax.sip.OUTBOUND_PROXY",
"131.246.103.26:5070/UDP");
// Other initialization properties.
try
{
sipStack = sipFactory.createSipStack(properties);
}
catch (SipException e)
{
System.err.println(e);
}
}
Abbildung 20: Initialisierung eines neuen Stacks mit Hilfe des SipFactory
Die AddressFactory kann URIs und URLs zusammenbauen, die HeaderFactory dann
die anderen noch benötigten Headerfelder und die MessageFactory schliesslich um die Art
der Message, ob Requests oder Responses und deren Inhalte nach SDP zu erstellen. Dabei
muss der Inhalt kein SDP Objekt sein, sondern kann auch als ein Textstring angegeben
werden.
try
{
SipURI requestURI = addressFactory.createSipURI (toUser, toSipAddress);
// Create other headers
Request request =
messageFactory.createRequest (requestURI, Request.INVITE,
callIdHeader, cSeqHeader, fromHeader, toHeader,
viaHeaders, maxForwards);
}
Abbildung 21: Erstellen eines neuen Requests
•
•
•
•
•
•
•
•
•
•
•
•
•
46
Die vom SIP Stack unterstützen Requests sind die üblichen wie:
INVITE
BYE
CANCEL
OPTIONS
ACK
REGISTER
aber auch neuere Requests werden angeboten wie:
INFO: Kontrollinformation der Sitzung
PRACK: Provisorisches Acknowledgement
UPDATE: Erneuern der Sitzung
SUBSCRIBE: Anmeldung zur automatischen Benachrichtigung bei bestimmten Ereignissen
NOTIFY: Benachrichtigen von bestimmten Ereignissen
MESSAGE: um direkte Textnachrichten zu verschicken
REFER: Referenz auf eine bestimmte Quelle
NIST SIP unterscheidet zwischen Client-Transaktionen und Server-Transaktionen. Eine
neue Transaktion beginnt entweder wenn ein Request empfangen wird, oder ein neuer
Request gesendet wird. Wurde ein neuer Request gesendet muss eine Client-Transaktion
beantragt werden, wird eine empfangen, entscheidet die Anwendung ob eine neue Server
Transaktion benötigt wird. Handelt es sich beim eingegangenen Request um einen dem
schon bestehenden Dialog zugehörigen Request, wird dieser dessen Server-Transaktion
zugewiesen. Kommt eine Response zurück wird diese automatisch der Client-Transaktion
des vorangegangenen Requests zugeordnet. Die Transaktion-ID wird schließlich zum
Senden von neuen Nachrichten verwendet (vgl. Abbildung 22 und 23).
try
{
// Create the client transaction
ClientTransaction inviteTid = sipProvider.getNewClientTransaction(request);
// send the request
inviteTid.sendRequest();
}
Abbildung 22: Senden eines Requests
47
Selbstverständlich unterstützt der Stack auch Dialoge, um im selben Kontext gesendete
Nachrichten miteinander in Verbindung zu bringen. Dialoge werden dabei nie direkt von
der Anwendung erzeugt, sondern bei Transaktionen wie INVITE oder SUBSCRIBE
automatisch initiiert und vom Stack verwaltet. Gelöscht werden können Dialoge jedoch
schon von der Anwendung, was aber besser dem Stack überlassen wird. Für Dialoge gibt
es besondere Zustände, wie Early, Confirmed, Completed und Terminated, die sich je nach
Transaktion ändern. Über Transaktionen kann man den Zustand des Dialogs abfragen und
dann passend behandeln [24].
try
{
public void processRequest(RequestEvent requestEvent) {
Request request = requestEvent.getRequest();
ServerTransaction st = requestEvent.getServerTransaction();
// do request specific processing here
}
}
Abbildung 23: Einkommende Nachricht als Event
3.2.2 Sip Communicator
Der auf dem Jain SIP Package beruhende SIP Communicator38 ist komplett in Java implementiert und benutzt das JMF. Er liegt dem Jain Sip Stack als Beispiel bei und ist auch
Open-Source. Somit eignet er sich gut, um die Kommunikation von einem Simple Client
zu einem SIP Telefon zu testen. Natürlich können auch alle anderen SIP kompatiblen Telefone und Softphones verwendet werden. Folgende Abbildung 24 zeigt das Programm:
38 Http://sip-communicator.dev.java.net
48
Abbildung 24: SIP Communicator
Die bei SIP Telefonen üblichen Parameter werden hier anhand der Konfiguration von
SIP-Communicator gezeigt.
PUBLIC_ADDRESS:
Die eigene SIP-Adresse wie [email protected] oder
[email protected].
Defaultwert
ist
user.name@<local IP address>
DISPLAY_NAME:
Der angezeigte Name, wie z. B. "Franz- Josef Fink"
TRANSPORT:
Welches Transportprotokoll verwendet werden soll.
Möglich sind udp und tcp. Defaultwert ist udp.
PREFERRED_LOCAL_PORT:
Der Port der für den Austausch von SIP
Nachrichten verwendet wird. Defaultwert ist 5060,
falls dieser nicht verfügbar, wird ein verfügbarer
zufällig gewählter Port verwendet.
REGISTRAR_ADDRESS:
Die IP-Adresse eines REGISTRAR-Servers, der
verwendet werden soll.
REGISTRAR_PORT:
Der Port des REGISTRAR-Servers.
REGISTRAR_TRANSPORT:
Welches Transportprotokoll zum REGISTRAR
verwendet werden soll. Möglich sind udp und tcp.
Defaultwert ist udp.
REGISTRATIONS_EXPIRATION: Die Anzahl der Sekunden, für die die Anmeldungen
gültig bleiben sollen. Defaultwert ist 3600.
STACK_PATH:
Der
komplette
Pfad
zu
der
JAIN-SIP
Implementierung. Man kann auch einen anderen
SIP Stack für das Softphone verwenden.
Defaultwert ist "gov.nist".
49
MEDIA_SOURCE:
Als Quelle für Audio und Video kann eine URL
oder eine Datei angegeben werden, die dann per
RTP-Stream
übertragen
wird.
Z.B.
file://home/user/jsphone/lostinspace.mov
VIDEO_PORT:
Der Port, auf dem Video Daten empfangen werden.
Defaultwert ist 22222.
AUDIO_PORT:
Der Port, auf dem Audio Daten empfangen werden.
Defaultwert ist 22224.
Hinzu kommen spezielle Stack Eigenschaften:
IP_ADDRESS:
Die IP-Adresse des Sip-Stack. Defaultwert ist das
Ergebnis
des
Methodenaufrufs
InetAddress.getLocalHost().getHostAddress().
STACK_NAME:
Name, um den Stack zu identifizieren, wobei keine
Leerzeichen erlaubt sind.
ROUTER_PATH:
Gibt den Klassenpfad zu dem Routerobjekt an. Z. B.
com.sun.javax.sip.RouteImpl. Das Objekt muss das
javax.sip.Router
interface
implementieren.
Defaultwert
ist
examples.jsphone.sip.JsPhoneRouter.
OUTBOUND_PROXY:
Gibt den ausgehenden Proxy, falls einer verwendet
werden soll, im Format: "ipaddress:port/transport"
an. Z.B. 129.1.22.333:5060/UDP.
RETRANSMISSON_FILTER:
Das Verhalten, wie Nachrichten wiederholt werden,
hängt davon ab, ob es sich um einen UAS oder einen
UAC handelt. Bei UAC übernimmt die Anwendung
die Wiederholungen von ACKs. Bei UAS
übernimmt die Anwendung die Wiederholungen von
2xx Antworten. Alle anderen Wiederholungen
werden vom SIP-Provider übernommen. Wenn man
den Filter einschaltet, werden keine Wiederholungen
von den Anwendungen, sondern alle vom SIPProvider durchgeführt.
EXTENSION_METHODS:
Erweiterungsmethoden, die neue Dialoge erzeugen
können, werden hier angegeben. Sie werden durch
Doppelpunkte getrennt. Z. B. "FOO:BAR".
Mit dem konfigurierten SIP Communicator Client, sollte jedes andere SIP Telefon erreichbar sein. Um jedoch einen Simple Client zu erreichen bedarf es noch einer speziellen
Software, die einen SIP Stack implementiert und die Nachrichten an den Venice Web-Service übergibt. Dazu wurde das SIP-Gateway entwickelt.
50
3.3 SIP-Gateway
Der SIP Service hat die Funktion eines Gateways. Auf der einen Seite konsumiert er SOAP
Events des VoIP Web-Service, auf der anderen Seite spricht er SIP über einen SIP Stack
an. Die Events von dem Web-Service sind die gleichen, die auch ein Simple Client verarbeitet:
INCOMING_CALL,
CONNECTION_ESTABLISHED,
CONNECTION_DENIED, END_CALL. Diese werden dann in die äquivalenten SIP
Nachrichten INVITE, OK, DECLINE, BYE übersetzt.
Wenn nun ein Simple Client mit einem externen SIP Client telefonieren möchte oder
umgekehrt, muss der SIP Client, ebenso wie ein anderer Simple Client, bei dem VoIP
Web-Service vorher registriert sein. Dazu erhält der SIP Client bei dem SIP-Gateway eine
virtuelle Benutzeridentifikation, mit der er sich dann bei dem Web-Service mit zugehörigem Passwort einloggt und eine weltweit eindeutige Lease zugewiesen bekommt. Das
Gateway bildet dann die Kommunikation zwischen dem virtuellen SIP-Gateway Benutzer
(sip_internal) und dem reellen SIP Client. Der Simple Client ruft den virtuellen Benutzer
an und bemerkt gar nicht, dass es sich nicht um einen anderen Simple Client, sondern um
einen SIP Client handelt. Das SIP-Gateway emuliert dabei einen Simple Client. Ruft ein
SIP Client einen Simple Client an, ruft er eigentlich das SIP-Gateway an, das wie ein normaler SIP Client reagiert und die Nachrichten dann per SOAP an den passenden Simple
Client weiterleitet.
Das SIP-Gateway benötigt deshalb Schnittstellen für beide Protokolle. Auf der VoIP
Web-Service Seite fängt er genauso wie auch ein Simple Client die Nachrichten mit der
wsEventReceived Methode auf. Und er sendet sie mit der WSEventProvider
Klasse durch die Methoden: login, logout, action_acceptCall, action_denyCall, action_endCall, action_makeCall an den Web-Service (siehe Abbildung 25).
Auf der SIP Seite übermittelt er entweder Requests durch die Methode processRequest, falls er als User Agent Client arbeitet, z. B. processInvite, processCancel, processBye, oder das Gateway beantwortet solche Requests mit der
Methode processResponse. Dabei sind alle Responses wie in Tabelle 1 möglich. Die
wichtigsten die von der Anwendung behandelt werden müssen sind aber:
100-Trying
180-Ringing
200-Ok
ACK
486-Busy
603-Declined
51
Abbildung 25: SIP-Gateway Methoden
Um einen SIP Stack zu initialisieren wurden folgende Eigenschaften festgelegt (vgl.
auch Abbildung 20):
properties.setProperty("javax.sip.OUTBOUND_PROXY",
"131.246.103.22:5060/UDP");
properties.setProperty("javax.sip.RETRANSMISSION_FILTER", "true");
properties.setProperty("javax.sip.STACK_NAME", "waitingforsip");
In diesem Beispiel wird ein SIP-Stack "waitingforsip" auf einem Rechner mit der IPAdresse 131.246.103.22 angelegt.
Um eine SIP Request Nachricht zu senden wird dann zuerst ein Request durch die
Klassen addressFactory, headerFactory und messageFactory zusammengebaut. Mit diesem
Request wird dann eine ClientTransaction erzeugt (mit dem Befehl:
sipProvider.getNewClientTransaction(request)). Alle weiteren Nachrichten, die zu dieser Transaktion gehören behalten dann diese eindeutige Transaktions-ID.
52
Daraufhin wird der Request über die Funktion transaktionsid.sendRequest()
verschickt. Kommt ein Requestevent bei dem Gateway an, wird der Request durch die Methode getRequest() extrahiert, und durch getServerTransaction() wird die
Transaktions-ID ausgelesen. Darüber hinaus kann man über die Transaktions-ID auch den
übergeordneten Dialog geliefert bekommen, womit eine eindeutige Zuordnung des Events
zu einem bestimmten Gespräch ermöglicht wird.
Um nun eine Incoming Call-Message weiterzuleiten, muss die genauere Beschreibung
der Eigenschaften des Anrufers in der SIP INVITE-Nachricht mitgeschickt werden. Dazu
wird mithilfe der SDP Factory aus dem Package javax.sdp eine passene SDP Payload zusammengebaut und an den Request angehängt.
Es bestehen die zwei grundlegenden Fälle bei der Kommunikation zwischen SIP Client
und Simple Client, deren Hauptunterscheidungsmerkmal darin liegt, von wem der beiden
das Gespräch initiiert wird.
3.3.1 Anruf von Simple Client nach SIP-Client
In dem ersten Fall wird betrachtet, wie von einem Simple Client ein außerhalb liegender
SIP-Client angerufen wird. Der Simple Client ruft dabei wie auch sonst die Methode
make_Call() auf. Durch die Adresse, die mit sip: beginnt, weiß der VoIP-Service, dass
er den speziellen SIPCallHandler erstellen muss39. Dieser leitet dann das "incoming call"
an den SIP-Gateway-Service weiter. Das Gateway baut aus der Clientkonfiguration des
Simple Client eine INVITE-Message, die die verfügbaren Codecs und die IP-Adresse des
Simple Client für die RTP-Verbindung enthält, wobei die Kontaktadresse aber das SIP
-Gateway bleibt. Das INVITE wird daraufhin entweder direkt an den SIP-Client, oder an
einen zuständigen SIP Proxy verschickt. Wenn die Nachricht dort erfolgreich angekommen
ist, kommt zuerst eine Response 180 zurück und das INVITE muss nicht wiederholt
gesendet werden.
Für den Fall, dass das Gespräch akzeptiert wird, bekommt das Gateway dann eine OK
Nachricht mit den bevorzugten Codecs und den Angaben zur RTP Verbindung vom SIP
Client. Diese Informationen liest er mit der Methode getSDPinfo() aus und updatet die
Clientkonfiguration. Dann schickt er ein acceptCall() an den Web-Service. Der SIPCallHandler übermittelt daraufhin sein "connection_established" an den Simple Client und
das Gateway. Das Gateway leitet diese Bestätigung der Verbindung an den SIP Client
durch ein ACK weiter und die RTP-Verbindung ist erfolgreich aufgebaut. Dieser Ablauf
ist in Abbildung 26 graphisch dargestellt.
39 Zu einem späteren Zeitpunkt des Projekts wird hier eine flexiblere Heuristik eingebaut, die über diverse
Abfragen (Enum, H.323 Gatekeeper, etc.) das zu verwendende Protokoll bestimmt.
Simple Client
53
VoIP-Service/
SIPCallHandler
[1] make call
SIP Client
Gateway
[2] incoming call
[3] INVITE
[4] 180
[5] OK
[6] accept
[7] established
[7] established
[8] OK
[9] RTP
Abbildung 26: Aufbau Simple Client nach SIP
3.3.2 Anruf von SIP-Client nach Simple Client
In dem anderen Fall wird betrachtet, wie von einem außerhalb liegenden SIP-Client ein
Simple Client gerufen wird. In dieser Situation muss das SIP-Gateway des Simple Clients
schon gestartet sein. Dies erfolgt beim Einloggen des Simple Clients automatisch. Zum Login bei dem VoIP-Service verwendet das Gateway immer die interne User-ID
"internal_sip". Bei diesem User weiß der Web-Service, dass es sich nicht um einen
richtigen Benutzer handelt, sondern um das Gateway. Er verwendet deshalb immer den
SIPCallHandler. Das Gateway meldet sich bei einem SIP Registrar Server an, bei dem
dann ein SIP-Client, der den Simple Client Benutzer anrufen will, die Adresse des Gateways abfragen kann. Der SIP-Client schickt dann seine INVITE-Message an das zuständige Gateway, das diese mit einem 100 (Trying) bestätigt. Daraufhin erfolgen vom Gateway zum Simple Client wieder analog zum vorigen Fall makeCall() und acceptCall(). Wenn das Gateway die Nachricht "connection_established" vom SIPCallHandler
empfängt, leitet er ein 200 (Ok) an den SIP Client weiter und hierdurch ist die Verbindung
erfolgreich aufgebaut.
Nach dem Betrachten der Aufbauphase, folgt hier die Erläuterung, wie das Gespräch
wieder beendet wird. Für den Gesprächsabbau gibt es natürlich wieder die beiden Möglichkeiten, je nachdem von welcher Seite der Wunsch zum Trennen der RTP-Verbindung geäußert wird (Abb.27).
54
VoIP-Service/
SIPCallHandler
Simple Client
Gateway
SIP Client
[1] INVITE
[2] make call
[3] 100
[4] incoming call
[5] accept
[6] established
[6] established
[7] OK
[8] ACK
[9] RTP
Abbildung 27: Aufbau SIP nach Simple Client
3.3.3 Gesprächsende durch Simple Client
Wird das Gesprächsende vom Simple Client initiiert, schickt dieser ein endCall().
Dieses kann natürlich nicht verweigert werden und deshalb schickt der SIPCallHandler an
beide Clients das event_end_call. Der Simple Client beendet dann die Verbindung und das
Gateway sendet darauf eine SIP BYE-Message an den SIP Client, wodurch auch dieser
von dem Ende informiert wird.
Simple Client
VoIP-Service/
SIPCallHandler
Gateway
SIP Client
[1] BYE
[2] end call
[3] event end_call [3] event end_call
Abbildung 28: Gesprächsende durch Simple Client
55
3.3.4 Gesprächsende durch SIP Client
Bei der anderen Möglichkeit empfängt das Gateway ein BYE vom SIP Client. Dieses wird
als ein endCall() an den VoIP-Service weitergereicht und vom SIPCallHandler an den
Simple Client weitergegeben, wie auch in Abbildung 29 verdeutlicht wird. Die Verbindung
ist beendet.
Simple Client
VoIP-Service/
SIPCallHandler
SIP Client
Gateway
[1] end_call
[2] event end_call
[2] event end_call
{3} BYE
Abbildung 29: Gesprächsende durch SIP Client
Die daraus resultierenden verschiedenen Möglichkeiten werden durch Zustände im Gateway repräsentiert, dadurch wird eine richtige Behandlung der Events gewährleistet und
Fehler vermieden. Die Zustände sind demnach:
STATUS_UNCONNECTED
STATUS_SIPtoSC,
STATUS_SCtoSIP,
STATUS_BYE_SIPtoSC
STATUS_BYE_SCtoSIP,
STATUS_CONNECTED
3.3.5 Multiuserbetrieb
Soll nun von dem SIP-Gateway nicht nur Kommunikation zwischen zwei festen Partnern
möglich sein, sondern möchten mehrere verschiedene Clients via Gateway kommunizieren, dann ist das Problem nicht viel komplizierter. Verschiedene SIP Clients anzurufen
ist einfach durch die Eingabe der verschiedenen SIP-Adressen möglich. Die SIP-Adresse
wird dabei bei vom SIPCallHandler an das Gateway in dem Event INCOMING_CALL
56
weiter gegeben und bei der Adressierung der INVITE-Message berücksichtigt. Jeder SIP
Client erzeugt dabei seine eigene Instanz des Gateways.
In die entgegengesetzte Richtung funktioniert der Anruf verschiedener Simple Clients
durch die dazugehörigen SIP-Gateways, die beim Login für diese automatisch erzeugt
werden, falls der Benutzer Verbindungen mit SIP wünscht. Die SIP-Gateways melden sich
mit der Methode register() an einem festgelegten REGISTRAR Server an und
warten daraufhin auf einem bestimmten SIP-Port auf eingehende Anrufe. Die richtige
Adresse SIP-Adresse und den Port des gewünschten Venice-Benutzers findet ein externer
SIP-Client dann durch eine Anfrage bei diesem REGISTRAR Server heraus.
3.4 Testbetrieb
Im Rahmen der Software-Entwicklungsarbeiten wurde das System ausgiebig getestet um
Fehler auszuschalten. In der ersten Testphase wurde der Gesprächsaufbau, dessen vorzeitiger Abbruch sowie das Beenden eines Gesprächs durchgeführt und dabei jeweils von dem
Simple Client und dem SIP Client initiiert, um alle Status des Gateways abzudecken. Als
SIP Client wurde dabei immer der SIP Communicator verwendet. Bei den Tests lief der
Venice Web-Service und das SIP-Gateway unter Linux (Suse Linux 9.0) und die Clients
abwechselnd unter Linux und Microsoft Windows XP. Dabei wurde festgestellt, dass die
Sprachqualität unter Windows durch den zur DirectX-Technologie gehörenden
DirectSound, bei dem direkt auf die Soundhardware zugegriffen werden kann, höher als
bei dem unter Linux verwendeten Javasound ist. Bei Linux hingegen blockierte in seltenen
Fällen ein anderes Programm die Soundkarte, wodurch Internettelefonie unmöglich gemacht wurde. Durch Beenden des blockierenden Programmes wird die Ressource wieder
freigegeben und wieder verfügbar.
Andere Fehlerquellen, die auftraten, waren Firewall- bzw. Router-Konfigurationen, welche die Benutzung der benötigten Ports unterbunden haben. Außerdem muss man darauf
achten, dass kein anderes Programm den gleichen Port verwendet. Es ist natürlich möglich
die Standardportwerte zu ändern.
In der Standardkonfiguration werden folgende Ports benutzt:
Simple Client RTP Audio Send Port
Simple Client RTP Audio Recieve Port
Simple Client Notification Port
SIP-Gateway Notification Port
SIP Communicator RTP Port
SIP Message Port
:
:
:
:
:
:
9000
9100
9200
9150
22224
5060
57
Da das SIP-Gateway kompatibel zu RFC 3261 entwickelt wurde, sollte es auch ohne
Anpassungen direkt mit den meisten anderen SIP-Hardware- und Softwaretelefonen
funktionieren. Deshalb wurden in der zweiten Testphase auch noch andere Programme getestet, die nun noch vorgestellt werden.
3.4.1 Weitere SIP Softwaretelefone
Viele SIP-Softwaretelefone sind nicht kostenfrei und/oder erlauben nur das Telefonieren
über eigene Gateways, für die man sich registrieren muss und auf die man dann beschränkt
ist. Deshalb wurden solche Programme nicht getestet. Jedoch lassen manche Anbieter den
zeitbegrenzten Test ihrer Software zu, wie z. B. Adobe Inc. mit ihrem Programm SIPPStar.
SIPPStar40
Der Unterschied zwischen den verschiedenen Programmen besteht meist nur in dem
Funktionsumfang der Software. Über die graphische Benutzeroberfläche (Abb. 30) hinausgehende Features von Sippstar sind hierbei eine kostenlose Anmeldung an den
firmeneigenen Registrarservern und Gatewayservern mit der Möglichkeit, auch weltweit in
das öffentliche Telefonnetz zu kommunizieren. Zudem hat der Client unter anderem auch
einen Anrufbeantworter mit Fernabfrage und eine integrierte optionale Verschlüsselung.
Abbildung 30: SIP Client SIPPStar
40 http://www.sippstar.com
58
Für den Test sind diese Funktionen weniger von Bedeutung. Vielmehr kommt es darauf
an, welche Codecs verfügbar sind, welche Ports verwendet werden, wie der Benutzername
des Telefons festgelegt wird, und zu welchen RFCs der Client kompatibel ist. Eine INVITE-Message, die vom Sippstar an das SIP-Gateway gesendet wurde, sieht dann zum Beispiel folgendermaßen aus:
Via: SIP/2.0/UDP 131.246.103.26:5060;branch=z9hG4bKnp432753-42dc207f131.246.103.26;rport
From: <sip:[email protected]:5060>;tag=19cb4fd5
To: <sip:[email protected]>
CSeq: 1 INVITE
User-Agent: null
Expires: 180
Accept: application/sdp
Contact: <sip:[email protected]:5060>
Max-Forwards: 70
Content-Length: 247
v=0
o=SIPPS 432753612 432753609 IN IP4 131.246.103.26
s=SIP call
c=IN IP4 131.246.103.26
t=0 0
m=audio 30000 RTP/AVP 0 8 97 2 3
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:3 GSM/8000
Abbildung 31: INVITE-Message von SIPPStar
Aus der Abbildung 31 kann man erkennen, dass der Client die Codecs PCMU, PCMA,
iLBC, G726-32 und GSM versteht und dass er auf Port 30000 auf eingehende RTP Daten
wartet. Hier wird die INVITE-Nachricht beispielsweise an die Adresse
"[email protected]" verschickt, wobei der Absender das Windowslogin "hiwi" ist.
59
Da PCMU quasi jeder Client verstehen sollte und damit auch eine hohe Sprachqualität
gewährleistet wird wurde diese Codec für die Tests aller weiterer Programme fest
verwendet.
Die Tests zeigten, wie schon erwartet, dass durch das Wechseln des SIP Clients auch
keine neuen Probleme in der Signaling Phase auftraten. Dies wurde ebenfalls durch Tests
mit dem häufig verwendeten Client Ubiquity belegt.
Ubiquity41
Dieser SIP User Agent benötigt zwar eine zeitlich begrenzte Lizenz, diese wird aber
kostenlos vergeben und kann auch immer wieder verlängert werden. Der Client ist einfach
gestaltet (siehe Abbildung 32) und basiert auf der JAIN SIP Lite API42 und unterstützt damit alle Anforderungen aus RFC 2543.
Abbildung 32: Ubiquity User Agent
Ein Beispiel der von diesem UA gesendeten INVITE-Message kann man in Abb. 33 betrachten:
41 http://www.ubiquity.net/products/SIP/SIP_User_Agent.php
42 http://jcp.org/en/jsr/detail?id=125
60
From: <sip:[email protected]>;tag=624840401
Contact: <sip:[email protected]:5060>
CSeq: 1 INVITE
Via: SIP/2.0/UDP 131.246.103.26:5060;branch=83F6671A13C4000000FCFFA9B4D7-8*0
Content-Length: 125
v=0
o=- 1086621468744 1086621468744 IN IP4 131.246.103.26
s=c=IN IP4 131.246.103.26
t=0 0
m=audio 5006 RTP/AVP 3 0 8
Abbildung 33: INVITE-Message von Ubiquity
Hierbei fällt auf, dass der SIP-Benutzername unabhängig vom login immer "user" ist.
Die erkannten Codecs sind nur PCMU, PCMA und GSM. Die anderen getesteten SIP-Messages (wie BYE, CANCEL, OK ...) unterschieden sich auch nicht von dem Protokollstandard.
Es existiert noch eine Vielzahl anderer SIP User Agents und mit der Beliebtheit von SIP
steigt die Zahl rapide. Unter http://www.iptel.org/info/products/sipphones.php kann man
eine Liste der zahlreichen Alternativen betrachten. Die meisten sollten dabei ohne Probleme mit dem SIP-Gateway funktionieren, es werden dabei lediglich kleine Unterschiede in
Sprachqualität, Codecauswahl und Geschwindigkeit auftreten.
Zuletzt wurde noch das optiPoint 400 Hardwaretelefon von Siemens getestet.
3.4.2 Siemens optiPoint 400 standard SIP
Das optiPoint 400 unterscheidet sich im Aussehen kaum von einem normalen Telefon,
wie in Abbildung 34 zu sehen ist. Jedoch wird es anstatt mit dem Telefonanschluss mit
einem Internetanschluss verbunden. Dazu gibt es auch die Möglichkeit, den internen
Miniswitch des Telefons zu verwenden und damit einen PC an das Telefon anzuschließen.
Somit kann man das Telefon einfach zwischen den PC und das Netz verbinden und benötigt keinen zusätzlichen Anschluss. Üblicherweise erhält das Telefon seine IP-Adresse und
weitere Konfiguration per DHCP.
61
Abbildung 34: optiPoint 400 standard SIP
Trotzdem kann man das Telefon auch auf eine fixe IP-Adresse einstellen. Hat das Telefon dann eine gültige Internetkonfiguration, bootet es und ist über das Netz erreichbar.
Durch den internen Http-Server des Telefons auf Port 8085 ist es möglich, mit einem Internetbrowser komfortabel die restlichen Einstellungen wie Benutzername, Proxies, Gateways
usw. durchzuführen. Daraufhin kann das Telefon per "Benutzername@IP-Adresse" vom
Simple Client aus angerufen werden. Um aber von dem SIP Telefon einen Anruf an eine
SIP-Adresse tätigen zu können, ist es notwendig in den Einstellungen einen SIP Server eingetragen zu haben (auch wenn dieser nicht verwendet werden muss), ansonsten kann man
nur Telefonnummern eingeben. Deshalb wurde der Open-Source SIP Server SIP Express
Router (SER43) verwendet. Er besitzt Registrar-, Proxy- und Redirect-Server Funktionalität. Danach kann man damit komfortabel telefonieren, auch wenn man keinen Computer
hat. Die Eingabe der SIP-Adresse über den Wählblock ist jedoch etwas umständlich.
Auch wenn sich das optiPoint 400 äußerlich sehr von den bisherigen Programmen unterscheidet, beruht es innerlich auf einem üblichen SIP-Stack. Das ist unschwer erkennbar,
wenn man eine von dem SIP-Telefon gesendete INVITE-Message, wie in Abbildung 35
sieht:
43 Http://www.iptel.org/ser
62
Via: SIP/2.0/UDP 131.246.103.163:5060;branch=z9hG4bKb3f07d17e
Max-Forwards: 70
From: "4772" <sip:[email protected]>;tag=2ef6b0bbdc0b277;epid=SC216107
CSeq: 930791426 INVITE
Supported: timer,replaces
Min-SE: 5
Contact: "4772" <sip:[email protected]:5060;transport=udp>
Content-Length: 257
v=0
o=MxSIP 0 1607182229 IN IP4 131.246.103.163
s=SIP Call
c=IN IP4 131.246.103.163
t=0 0
m=audio 5010 RTP/AVP 0 8 4 100
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:188 0-15
a=ptime:20
Abbildung 35: optiPoint 400 INVITE-Message
Obwohl das Endgerät unterschiedlich ist, bleibt die Übertragungsschnittstelle gleich.
Somit wurden auch bei der Verwendung des Hardwaretelefons keine neuen Probleme zu
dem aktuellen Stand der SIP-Gateway Implementierung festgestellt.
Zusammenfassung
63
4 Zusammenfassung
Das Ziel dieser Arbeit war die Integration eines SIP-Stacks in eine Web-Service basierte
VoIP-Lösung. Hierbei wurde der Open-Source Nist SIP Stack in das Web-Service basierte
Venice durch einen SIP-Gateway Service integriert. Der SIP-Gateway ist ein selbstständiger auf den Stack aufgebauter Dienst, der auf der einen Seite mit Hilfe des Nist Stacks
auf einkommende SIP Nachrichten wartet oder SIP Nachrichten senden kann, und der auf
der anderen Seite mithilfe von SOAP mit dem VoIP-Webservice des Projektes Venice
kommunizieren kann. Es wurde der grundlegende Aufbau und die wichtigsten Funktionen
der Implementierung beschrieben und versucht, den Aufbau des Programmes verständlich
zu machen. Details für genauere Funktion des Implementierung sind in Kommentaren im
Quelltext gegeben und können auch mithilfe des Log4J 44 Logging Mechanismus mit definierbarer Tiefe zur Laufzeit des Gateways ausgegeben werden.
44 Http://logging.apache.org/log4j
Ausblick
64
5 Ausblick
IP Telefonie ist erst noch am Anfang seiner Verbreitung. Mit dem rapiden Wachstum
des Internets und der immer weitergehenden Vernetzung (All over IP) hat sie gute Chancen, rasch die normale Telefonie zu verdrängen, so wie die digitale Fotografie mehr und
mehr die analoge verdrängt. Im Moment sind noch nicht alle Voraussetzungen für VoIPTelefonie ideal. Gerade ungesicherte Übertragungsqualitäten (QoS) durch Beanspruchung
unterschiedlicher Dienstleister für den Internetzugang, und geringer Kostenvorteile wegen
Internetverbindungen, die auf normalen Telefonanschlüssen beruhen, behindern einen Umstieg noch sehr. Aber wie Roland Kittel, der Vorstand des Festnetzbereiches der Deutschen
Telekom, in einem Interview in der Zeitschrift Technology Review 02/2004 verriet, besteht der Plan, das deutsche Telefonnetz in den nächsten Jahren komplett auf InternetTechnologie umzustellen. Dieses Ziel soll schon weit vor 2020 erreicht sein. Von den
Telefongesellschaften der meisten anderen Länder ist auch nichts anderes zu erwarten, sind
doch die Kostenvorteile durch effizientere Nutzung der Leitungen erheblich.
Auch Systeme, in denen Menschen mit Mobiltelefonen über VoIP telefonieren, sind
nicht mehr Zukunftsvisionen, sondern es gibt schon gut funktionierende Modelle auf dem
Markt, die auch immer erschwinglicher werden. Bei diesen Angeboten wird auf die jetzt
überall auftauchenden Funknetzwerke gesetzt. Die ersten Modelle kamen schon 1999 von
Symbol Technologies45 mit ihrer auf H.323 basierten Net Vision Serie auf den Markt. Aber
auch viele andere Firmen, wie Zyxel mit ihrem Prestige 2000W bieten gute Lösungen an.
Das Prestige 2000W unterstützt SIP, das sich für VoIP immer weiter
durchsetzt. Dadurch kann man von jedem offenen WLAN46-Hotspot ohne
Zusatzkosten telefonieren.
Für eine gute Sprachqualität bei VoIP müssen die Sprach-Datenpakete Vorrang vor allen anderen erhalten. Die dazu erforderlichen Quality-of-Service-Steuerung befindet sich für WLAN derzeit erst im Standardisierungsprozess (IEEE 802.11e)[25].
Abbildung 36: Zyxel Prestige 2000W
Einen weiteren Ansatz gibt es, den Mobilfunkstandard UMTS für IP Telefonie zu
verwenden, falls dieser sich durchsetzen kann. Auf jeden Fall wird sich in der Technologie
in den nächsten Jahren noch sehr viel verändern.
Gerade für Mobilgeräte, wie Mobiltelefone oder Personal Digital Assistants (PDAs) mit
geringeren Ressourcen bietet sich deshalb eine Web-Service basierte VoIP -Lösung besonders an.
45 http://www.symbol.com/news/pressreleases/pr_wireless_patent.html
46 Wireless Local Area Network
Abkürzungen
65
6 Abkürzungen
ADPC
Adaptive Differential Pulse Code Modulation (adaptive Audio Komprimierung)
API
Application Programming Interface (Programmierschnittstelle)
AVT WG
Audio-Video Transport Working Group
CLIP
Calling Line Identification Presentation (Rufnummernanzeige)
DES
Data Encryption Standard
DTD
Document Type Definition
ENUM
Telefon number mapping mit E.164 Nummer n(siehe rfc2916)
ISDN
Integrated Services Digital Network (das digitale leitungsvermittelte
Telefonnetz)
ITU
International Telecommunication Union
JSR
Java Specification Requests
JWSDP
Java Web Service Developer Pack
NIST
National Institute for standards and technology (eine Abteilung des U.S.
Commerce Departments)
PCM
Pulse Code Modulation
PDA
Personal Digital Assistant
PGP
Pretty Good Privacy (auf öffentliche Schlüssel basiertes Verschlüsselungsverfahren)
PT
Payload Type (Art der Kodierung von RTP Nutzdaten)
PSTN
Public Switched Telephone Network (das Telefonnetz)
QoS
Quality of Service
RTCP
RealTime Control Protokoll
RFC
Request for Comment
SDP
Session Description Protokoll
SID
Silence Insertion Descriptor
SIP
Session Initiation Protokoll
SOAP
Simple Object Access Protokoll
SSL
Secure Sockets Layer
SQL
Structured Query Language
TLS
Transport Layer Security Protokoll
Abkürzungen
66
UAC
User Agent Client
UAS
User Agent Server
UBR
Universal Business Register
UDDI
Universal Description, Discovery and Integration
URI
Uniform Resource Identifier
URL
Uniform Resource Locator
UUID
Universal Unique Identifier
UTF
Unicode Transfer Format nach RFC3629
VoIP
Voice over IP oder auch IP-Telefonie genannt
WSDL
Web Services Definition Language
WWW
World Wide Web
XML
Extensible Markup Language
Abbildungs- und Tabellenverzeichnis
67
7 Abbildungs- und Tabellenverzeichnis
Abbildung 1: SIP Nachricht...................................................................................................9
Abbildung 2: SIP Verbindungsaufbau.................................................................................15
Abbildung 3: SDP- Payload [8]............................................................................................17
Abbildung 4: RTP-Header[9]...............................................................................................19
Abbildung 5: Audio-Paket mit Header.................................................................................20
Abbildung 6: framebasierte Kodierung................................................................................22
Abbildung 7: XML Beispiel.................................................................................................26
Abbildung 8: SOAP Umschlag............................................................................................26
Abbildung 9: SOAP Aktienkurs Anfrage.............................................................................27
Abbildung 10: SOAP Aktienkurs Antwort..........................................................................28
Abbildung 11: Beispiel WSDL für Temperaturkonverter ...................................................30
Abbildung 12: UDDI............................................................................................................31
Abbildung 13: VoIP über Web-Service...............................................................................34
Abbildung 14: Verbindungsaufbau Simple Client nach SIP UA.........................................35
Abbildung 15: Venice Web-Services...................................................................................37
Abbildung 16: Venice Verbindungsaufbau mit Remote Web-Service................................38
Abbildung 17: Venice Simple Client...................................................................................39
Abbildung 18: Venice Simple Client Zustandsdiagramm....................................................39
Abbildung 19: JAIN SIP Architektur...................................................................................43
Abbildung 20: Initialisierung eines neuen Stacks mit Hilfe des SipFactory........................45
Abbildung 21: Erstellen eines neuen Requests....................................................................45
Abbildung 22: Senden eines Requests.................................................................................46
Abbildung 23: Einkommende Nachricht als Event..............................................................47
Abbildung 24: SIP Communicator.......................................................................................48
Abbildung 25: SIP-Gateway Methoden...............................................................................51
Abbildung 26: Aufbau Simple Client nach SIP...................................................................53
Abbildung 27: Aufbau SIP nach Simple Client...................................................................54
Abbildung 28: Gesprächsende durch Simple Client............................................................54
Abbildung 29: Gesprächsende durch SIP Client..................................................................55
Abbildung 30: SIP Client SIPPStar......................................................................................57
Abbildung 31: INVITE-Message von SIPPStar...................................................................58
Abbildung 32: Ubiquity User Agent....................................................................................59
Abbildung 33: INVITE-Message von Ubiquity...................................................................60
Abbildung 34: optiPoint 400 standard SIP...........................................................................61
Abbildung 35: optiPoint 400 INVITE-Message..................................................................62
Abbildung 36: Zyxel Prestige 2000W..................................................................................64
Tabelle 1: SIP Header Felder nach [3].................................................................................11
Tabelle 2: SIP Client Fehlercodes nach [3]..........................................................................13
Tabelle 3: SDP Parameter [8]...............................................................................................18
Tabelle 4: RTP Audio-Codecs nach [9]...............................................................................21
Tabelle 5: VoIP Web-Service Methoden.............................................................................36
Tabelle 6: von JMF unterstützte RTP Audio Codecs...........................................................42
Quellenangaben
68
8 Quellenangaben
1:
Dokey Deanna K., Rushing John S.: Voice over Internet Protocol. 1999.
In http://isds.bus.lsu.edu/cvoc/Projects/TechLibrary/VoiceOver/
2:
Dusch Edith: Internet Telephonie – VoIP. ITA. 7 2002.
3:
Rosenberg, et. al., SIP: Session Initiation Protocol, RFC 2543. 1999.
4:
Rupp S., Siegmund G., Lauterschlager W.: SIP-Multimediale Dienste im Internet,
dpunkt .verlag, Heidelberg, 1. Aufl. 2002.
5:
Rosenberg, et. al., SIP: Session Initiation Protocol, RFC 3261. 2002.
6:
Stredicke Christian: Neuer Standard in der VoIP-Welt, Heft LANline ,
Ausgabe 1. 2002
7:
Session Initiation Protocol (SIP) working group. In
http://www.ietf.org/html.charters/sip-charter.html
8:
Handley, M., Jacobson V., SDP: Session Description Protocol, RFC 2327. 1998.
9:
Schulzrinne, H., Casner, S., Frederick, R., Jacobson V.: RTP: A Transport
Protocol for Real-Time Applications, RFC 3550. 2003.
10:
Schulzrinne H: RTP Profile for Audio and Video Conferences with Minimal
Control. In RFC 3551. 2003.
11:
FAQ: Audio File Formats,
In http://www.vorde.org/compSpeechFAQ/fullAudioFormats
12:
Hui-Hsiung Kuo: White Noise Theory, CRC Press. 1999.
13:
Mansmann Urs: Weltweit wählen, in c't Magazin 9/2004.
14:
Umstätter Walther: XML - Einführung,
In http://www.ib.huberlin.de/~wumsta/sgml/xml.html. 2000.
15:
Bray Tim, Paoli Jean, Sperberger-McQueen: Extensible Markup Language
(XML) 1.1, in http://www.w3c.org/TR/xml11/. 2004.
16:
Gudgin Martin, Hadley Marc, Mendelsohn Noah: SOAP Version 1.2 Part 1:
Messaging Framework, in http://www.w3c.org/TR/soap12-part1/. 2003.
17:
James Snell, Doug Tidwell & Pavel Kulchenko, Webservice-Programmierung mit
SOAP, O'REILLY. 1. Auflage. 2002.
Quellenangaben
69
18:
T. Berners-Lee, Uniform Resource Identifiers (URI): Generic Syntax, in RFC 2396.
August 1998.
19:
Christensen, E., Cubera F., Meredith G.Berners-Lee, T., Fielding, R.,
Weerawarana S.: Web Servoce Description Language (WSDL) 1.1. In
http://www.w3c.org/TR/wsdl. 2001.
20:
Hillenbrand M., Müller P., Müller H.: Voice over IP als Web Service, 18. DFN
Arbeitstagung (Düsseldorf). 2004.
21:
Markus Hillenbrand, Paul Müller und Kristian Mihajloski: A Software Deployment
Service for Autonomous Computing Environments, In: Proceedings of IAWTIC
2004 (Gold Coast Australia). 2004.
22:
Hillenbrand Markus, Zhang Ge: A Web Services Based Framework for Voice over
th
IP, In Proceedings of the 30 Euromico conference 2004, Rennes, France. 2004.
23:
Zhang Ge , Hillenbrand Markus: Implementing SIP and H.323 Signaling as Web
th
Services, In Proceedings of the 30 Euromico conference 2004, Rennes, France.
2004.
24:
O'Doherty Helim, Ranganathan Mudumbai: JAIN SIP Tutorial. Sun Microsystems.
2003.
25:
Produktinformation Zyxel, http://www.zyxel.de/product/overview.php, 2004.

Integration eines SIP Stacks in eine Web-Service

Transcription

Documents pareils

Sound Improvement Disc und Rothwell VK – Preisliste

CN.as COM - SIP Spezifikationen Notruf

Originalarbeit

Sicherheit geht vor

Règlement SIP - Federation of the Swiss watch industry FH

Speed-Stacking-Koffer mit 20 Sets

VoIP-Security

VoIP confguration benutzerhandbuch Thomson st2022 De