Institut für Nachrichtentechnik Labor für Datennetze / Forschungsgruppe QoSSIP. Master Thesis

Transkript

1 Fachhochschule Köln Cologne University of Applied Sciences 07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Information Engineering Institut für Nachrichtentechnik Labor für Datennetze / Forschungsgruppe QoSSIP Master Thesis Thema: Konzeption und Entwicklung einer multimedialen Diensteplattform für Next Generation Networks Student : Dipl.-Ing. Achim Marikar Matr.-Nr. : Referent : Prof. Dr. Andreas Grebe Korreferent : Prof. Dr. Heiko Knospe Abgabedatum : 28. Januar 2008

2 2 Hiermit versichere ich, dass ich diese Master Thesis selbständig angefertigt und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt habe. Achim Marikar

3 Inhaltsverzeichnis 3 Inhaltsverzeichnis Inhaltsverzeichnis...3 Abbildungsverzeichnis...6 Vorwort Einführung All IP-Netze Next Generation Access Next Generation Networks IP Multimedia Subsystem Architektur Session Initiation Protocol DIAMETER Call Session Control Functions Proxy-CSCF Serving-CSCF Interrogating-CSCF Home Subscriber Server Application Server Application Server im IMS Charging Quality of Service Verfügbare Application Server IBM WebSphere IP Multimedia Subsystem Connector Open Cloud Rhino IMS Application Server Ericsson IMS weshare Ericsson IMS Messaging Ericsson IMS Push to Talk Ericsson IMS Multimedia Telephony Fraunhofer Fokus Open IMS Core Bewertung Neue Dienste im IMS Videodienste...30

4 Inhaltsverzeichnis Signalisierungsdienste Vorabüberlegungen Videoformate H Videoübertragung Übertragungsraten Signalisierung SIP-INVITE SIP-INFO SIP-NOTIFY SIP-MESSAGE Anwendungssteuerung Kommunikation über SIP-INFO Implementierung von Videobox Architektur Menüs Hinweis Modul Navigation Verwendete Software Hauptkomponenten des Clients Hauptkomponenten des Servers Hauptanwendung Erzeugung dynamisch generierter Ausgaben Videoausgabe Audioausgabe Signalisierung beliebiger Inhalte Automatische Signalisierung Manuelle Signalisierung Charging Module Video Hinweis Rufumleitung Linkversand Management Interface Integration in das IMS...69

5 Inhaltsverzeichnis 5 8 Implementierung ausgewählter Dienste Anrufbeantworter Videos Spiel Externe Inhalte Travel Agency CCA-Interface Auswertung Erweiterungen...77 Schlussbetrachtung...79 Anhang...80 Abkürzungen...85 Quellen...87

6 Abbildungsverzeichnis 6 Abbildungsverzeichnis Abbildung 1: Next Generation Access...12 Abbildung 2: Verschiedene Möglichkeiten IP-Dienste zu nutzen...13 Abbildung 3: Die einzelnen Layer des IMS...15 Abbildung 4: Architektur des IMS [WIKIPEDIA]...16 Abbildung 5: Möglicher SIP-Verbindungsaufbau (frei nach [IMSCS])...17 Abbildung 6: Anbindung der Application Server [IMSCS]...21 Abbildung 7: Videomenü...31 Abbildung 8: Videokonferenz...32 Abbildung 9: Der Beginn eines Videos...37 Abbildung 10: Originalbilder und komprimiertes Video (vereinfacht)...37 Abbildung 11: Diese Aufnahme beginnt mit einem P-Frame...39 Abbildung 12: Übertragungsraten für Videos (exklusive Audio)...40 Abbildung 13: Verlauf der Videoübertragungsrate während einer IVR-Sitzung...41 Abbildung 14: Re-Invite zu Beginn des Gesprächs...42 Abbildung 15: Unterbrechung eines Gesprächs für eine Videoübertragung...43 Abbildung 16: Übertragung eines Videos parallel zu einem Gespräch...44 Abbildung 17: Tastenbelegung für DTMF...47 Abbildung 18: Struktur der Datenbank (vereinfacht)...52 Abbildung 19: Adressierung über die Rufnummer...52 Abbildung 20: Navigation innerhalb einer Anwendung...54 Abbildung 21: Ablaufplan von Videobox...59 Abbildung 22: Schritte bis zum Abspielen eines Videos...60 Abbildung 23: Schritte bis zur Wiedergabe einer Sprachausgabe...60 Abbildung 24: Flow-based Charging in Videobox...63 Abbildung 25: Management Interface von Videobox - Strukturansicht...66 Abbildung 26: Management Interface von Videobox - Menüansicht...67 Abbildung 27: Management Interface von Videobox - Hinweisansicht...68 Abbildung 28: Management Interface von Videobox - Modulansicht...69 Abbildung 29: Das Hauptmenü von Videobox...71 Abbildung 30: Minigame auf dem Videotelefon...74

7 Abbildungsverzeichnis 7 Abbildung 31: Operator Interface...76

8 Vorwort 8 Vorwort Diese Master Thesis entstand als Beitrag zum Forschungsprojekt QoSSIP (Netzeübergreifende Quality of Service bei SIP basierter VoIP Kommunikation). Das Forschungsprojekt befasst sich mit Quality of Service (QoS) für zeitkritische Datenströme in IP Netzwerken, im Besonderen mit auf dem Session Initiation Protocol (SIP) basierenden Anwendungen. Diese Master Thesis hat das IP Multimedia Subsytem (IMS) als Thema, insbesondere die Dienste, die das IMS ermöglichen kann. Auch wenn diese Arbeit sich somit nicht direkt auf Quality of Service bezieht, ist dieses Thema jedoch im Fokus des Forschungsgebietes. Denn um zu wissen, welche Anforderungen erfüllt werden müssen, müssen die Anwendungen im Netz bekannt sein. Diese Arbeit wendet sich an den erfahrenen Leser. Gute Kenntnisse in den Bereichen VoIP (SIP/RTP, Real Time Transfer Protocol), QoS und PSTN (Public Switched Telephone Network) werden vorausgesetzt. Grundlegende Informationen zu VoIP und QoS finden sich in [TRIWEB]. Weitere Arbeiten aus dem Forschungsprojekt QoSSIP stehen unter [QOSSIP] zum Download bereit.

9 1 Einführung 9 1 Einführung In Zeiten, in denen nicht nur über All IP Netze nachgedacht wird, sondern auch zahlreiche Dienste wie die Telefonie auf IP umgestellt werden, das TV Angebot durch IPTV erweitert wird und die Mobilfunknetze IP Zugänge bereitstellen, ist es an der Zeit, neue Dienste und Verdienstmodelle zu kreieren. Der virtuelle Anrufbeantworter im Netz ist bei vielen Anbietern bereits selbstverständlich, Videotelefonie per PC oder Mobiltelefon für viele Nutzer bereits möglich. Um sich gegenüber der Konkurrenz anzuheben, sind immer wieder neue Dienste notwendig. So kann heutzutage noch nicht einmal mehr ein Free Mail Anbieter neue Kunden gewinnen, wenn er nicht besondere Dienste bereitstellen kann. Ein Brainstorming der Marketingabteilung könnte folgendermaßen aussehen: Lassen Sie uns in unserem Festnetz zusätzlich zur reinen Sprachtelefonie die Videotelefonie vermarkten. Der erfahrene Leser weiß, dass die Videotelefonie in den letzten Jahren bereits mehrfach mit lediglich geringem Erfolg beworben wurde. Selbst in dem heute bereits verbreiteten UMTS Netz ist die aktive Nutzung der Videotelefonie eine Seltenheit, obwohl sie bereits zu den Anfängen des Fernsehens in den 20er Jahren des letzten Jahrhunderts entwickelt wurde. Das reine Übertragen von Livevideobildern reicht also nicht als Anreiz, um einen größeren Markt zu erschließen. Es müssen Anwendungen gefunden werden, die die Videotelefonie noch weiter aufwerten und die sie für den Kunden attraktiver machen.

10 1 Einführung 10 Zusätzliche Funktionen wie ein Videoanrufbeantworter wären wichtig. OnDemand-Angebote mit Videos wie bei Youtube ziehen Jüngere an. Wenn sie für Klingeltöne zahlen, warum nicht auch für Videos. Auf die gleiche Weise kommt man auch schnell auf die Idee, weitere Dienstleitungen wie Instant Messaging, Filetransfer und die Bereitstellung fast beliebiger Dateninhalte zu ermöglichen. In dieser Arbeit geht es nicht direkt um die Videotelefonie an sich, sondern wie man das Vorhandensein des zweiten Mediums Video neben Audio in der modernen Telefonie nutzen und Dienste multimedial erweitern kann. So können Auskunfts und Vermittlungssysteme durch das Hinzufügen von grafischen Menüs anwendungsfreundlicher werden. Zukünftige Telefonielösungen können mit Anwendungen wie IPTV1, VoD (Video on Demand) und Webseiten verschmelzen, sodass nur noch eine gemeinsame Basis zur Verteilung verschiedenster Inhalte benötigt wird. 1 Übertragung eines Fernsehprogramms über das Internet Protokoll

11 2 All IP-Netze 11 2 All IP Netze Nachdem Voice over IP (VoIP) in vielen Bereichen das herkömmliche Festnetz abgelöst hat und die TV Ausstrahlung digitalisiert wurde, liegt es nahe, die verschiedenen Medien über ein einziges Netzwerk zu übertragen. Die Idee, die hinter einem All IP Netz steht, ist die sogenannte Konvergenz der Netze. Durch das Zusammenlegen einzelner Netzwerkstrukturen soll die Verwaltung vereinfacht und zukünftige Investitionen verringert werden. Dies dient einerseits der Kostenersparnis, da nur noch ein einziger Anschluss bei den Kunden benötigt wird und nur noch ein Netz unterhalten werden muss. Andererseits wird eine einfache Erweiterung auf neue Dienste ermöglicht. Vereinfacht bedeutet dies, dass nur die Übertragungskapazität hoch genug sein muss, damit der neue Dienst implementiert werden kann. Von All IP Netzen spricht man, da IP das Protokoll ist, das eine einheitliche Plattform für die unterschiedlichsten Netzwerkanwendungen bieten kann. Zu den am häufigsten in die IP Welt migrierten Anwendungen zählen neben Telefonnetzen Videoübertragungen in Form von IPTV und VoD. Beispiele für All IP Netze werden im Folgenden vorgestellt. 2.1 Next Generation Access Unter dem Begriff Next Generation Access (NGA) versteht man in der Regel den Zugang zum Telefonnetz über die Internetverbindung. Hier wird aus Kostengründen der Telefonanschluss über die Internetverbindung (DSL oder Kabel) realisiert. Teilweise wird auch IPTV über dieselbe Leitung angeboten. Hier handelt es sich jedoch nicht unbedingt um ein echtes NGN (Next Generation Network), da diese Konvergenz der Netze nur beim Zugang besteht und der Kunde weiterhin sein herkömmliches leitungsgebundenes Telefon ohne neue Komfort

12 2 All IP-Netze 12 merkmale nutzt. Des Weiteren kann diese Konvergenz im Netz des Providers wieder aufgelöst werden, ein einheitliches Transportnetz für alle Medientypen ist keine Voraussetzung. Abbildung 1: Next Generation Access 2.2 Next Generation Networks Ein Next Generation Network erweitert den Gedanken eines All IP Netzes zu einer einheitlichen Serviceplattform. Ein NGN ist ein Netzwerk, welches unter anderem folgende Eigenschaften besitzen soll ([ITU T]): IP basiert Unterstützung unterschiedlicher Dienste wie Echtzeitkommunikation, Streaming und Datendienste Trennung von Steuerungs und Mediadaten Unabhängig von der benutzten Transport und Zugangstechnologie (xdsl, Cable, UMTS etc.) Anschluss und providerunabhängige Nutzung der Dienste (Nomadische Nutzung, Roaming) Ende zu Ende QoS über Netzwerkgrenzen hinaus

13 2 All IP-Netze 13 Diese Eigenschaften sollen den Nutzern unterschiedlichste IP basierte Dienste über ein beliebiges IP basiertes Zugangsnetz unabhängig vom Access Provider ermöglichen. Für den Nutzer ist es somit unerheblich, ob er über UMTS, WLAN oder DSL telefoniert. Er kann immer seinen Service Provider nutzen. Abbildung 2: Verschiedene Möglichkeiten IP-Dienste zu nutzen Auch bei der Verwendung von Zugängen und Transportnetzen, die nicht im Einflussbereich des eigenen Service Providers liegen, wird versucht, die gebuchte QoS einzuhalten.

14 3 IP Multimedia Subsystem 14 3 IP Multimedia Subsystem Das IP Multimedia Subsystem, kurz IMS, ist eine Architektur, die Sprach und Datendienste im Festnetz und Mobilfunk (GSM und UMTS) sowie im Internet miteinander vereint. Der Gedanke hinter IMS ist, dass sich ein User mit beliebiger Zugangstechnik nur einmal bei seinem Anbieter registrieren muss, um Dienste wie Sprach und Videotelefonie, Push to Talk, Instant Messaging oder Online Games nutzen zu können. Das IMS ist ein echtes Next Generation Network. Die Standards zu IMS werden vom 3rd Generation Partnership Project (3GPP) entwickelt und herausgegeben. Die 3GPP ist ein Zusammenschluss von Normungs und Standardisierungs gremien aus Europa2, Japan, China, Südkorea und den USA. Die 3GPP verteilt seine Entwicklung auf verschiedene Releases. Die erste für IMS relevante Ausgabe ist Release 5 aus dem Jahr Seitdem folgen in unregelmäßigen Abständen weitere Releases. Aktuell wird an den Releases 7 und 8 gearbeitet. Die 3GPP ist nicht zu verwechseln mit der 3GPP2, welche seit 1998 die Spezifikationen für den UMTS Konkurrenten CDMA2000 entwirft. 3.1 Architektur Als Basistechnik kommen das Internet Protokoll in der Version 6 (IPv6)3, das Session Initiating Protocol (SIP) und DIAMETER zum Einsatz. Für die Nutzung des IMS ist eine IP Konnektivität ausreichend, der lokale Access Provider (ISP) muss kein IMS unterstützen. Des Weiteren ist das Roaming mit anderen IMS Anbietern möglich. Durch die flexible Struktur 2 In Europa ist dies die Abteilung TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks) des European Telecommunications Standards Institute (ETSI) 3 Einige frühe Implementierungen wie Open IMS Core [FHOIC] nutzen noch IPv4

15 3 IP Multimedia Subsystem 15 sollen neue Dienste, auch wenn sie nicht von der 3GPP entwickelt wurden, mit geringem Aufwand in das IMS eingebunden werden können. Damit eine gleichbleibende Übertragungsqualität für die einzelnen Dienste gewährleistet werden kann, sollen allen benötigten Ressourcen zwischen den Teilnehmern reserviert werden. Im IMS soll es so eine Ende zu Ende Quality of Service geben. Der Wechsel zu IMS soll für den Nutzer transparent erfolgen. Die Technik ändert sich, aber der Nutzer kann mit einem äußerlich ähnlichen Telefon oder über einen Adapter mit seinem herkömmlichen Gerät wie gewohnt telefonieren. Mit entsprechender Hard und Software bekommt der Kunde nun jedoch wesentlich mehr Funktionalität geboten. Abbildung 3: Die einzelnen Layer des IMS Das IMS ist in drei verschiedene Ebenen aufgeteilt. Der Transport Layer beschreibt die IP Ebene samt Zugangsnetz zum User Equipment (UE). Auf dem Control Layer, auch IMS Layer genannt, befinden sich die weiter unten genauer beschriebenen Call Session Control Functions (CSCF). Da die CSCFs weit mehr als reine Kontrollfunktionen durchführen, kann man sie teilweise auch zum Application Layer zählen. Dieser Layer ist die Ebene, die die Anwendungen im IMS bereitstellt. Anwendungen dieser Schicht benötigen nur eine abstrakte Darstellung der darunter liegenden Ebenen, die genaue Funktionsweise der unteren Schichten des IMS ist für einen Application Server uninteressant. Er benötigt lediglich APIs zum

16 3 IP Multimedia Subsystem 16 Ansprechen der darunter liegenden Funktionen. Der Fokus dieser Arbeit liegt auf dem Application Layer. Abbildung 4: Architektur des IMS [WIKIPEDIA] Abbildung 4 zeigt, dass die Struktur des IMS sehr komplex ist. Im Folgenden werden die wichtigsten Funktionen erklärt, detailliertere Informationen zum Aufbau des IMS findet der interessierte Leser unter anderem in [IMSCS] und [3GIMS]. 3.2 Session Initiation Protocol Die Signalisierung im IMS wird über das im Internet bereits sehr gängige SIP durchgeführt. Der Vergleich mit herkömmlichen SIP Netzen lässt jedoch einige Unterschiede deutlich

17 3 IP Multimedia Subsystem 17 werden. Die SIP Kommunikation ist wesentlich genauer spezifiziert, was die Kompatibilität erhöht aber auch Flexibilität einbüßen lässt. Die SIP Kommunikation im IMS beinhaltet oft wesentlich mehr Nachrichten als bei herkömmlichen SIP Anwendungen üblich. Ein bedeutender Faktor ist die Aushandlung der QoS Eigenschaften über den Austausch von PRACK Nachrichten (Provisional Acknoledgment). Einen möglichen Verbindungsaufbau im IMS zwischen Teilnehmern eines Providers zeigt Abbildung 5. Abbildung 5: Möglicher SIP-Verbindungsaufbau (frei nach [IMSCS]) Durch die stark gestiegene Anzahl an SIP Nachrichten ist eine Kompression der SIP Pakete vorgesehen. So sollen durchsatzschwache Verbindungen nicht durch einen großen Signalisierungs Overhead zusätzlich belastet werden. Um eine sichere Übertragung der Anmeldeinformationen zu gewährleisten, wird in IMS Netzen für die Passwortübertragung die MD5 Hashfunktion (Message Digest Algorithm) genutzt, anstatt der in herkömmlichen SIP Netzen oft genutzten schwächeren SHA 1 Hashfunktion (Secure Hash Algorithm).

18 3 IP Multimedia Subsystem DIAMETER Ein weiteres wichtiges Protokoll für das IMS ist DIAMETER, die Weiterentwicklung des RADIUS Protokolls. Da DIAMETER erweiterbar ist und wesentlich mehr Werte an den Empfänger übermitteln kann als es RADIUS möglich ist, bietet sich dieses Protokoll für das IMS zur Umsetzung der erweiterten AAA Funktionalität (Authentifizierung, Autorisierung, Accounting) an. Die optionale TLS Verschlüsselung (Transport Layer Security) ermöglicht eine sichere Kommunikation auch außerhalb des lokalen Netzes. 3.4 Call Session Control Functions Für die Registrierung der Nutzer und der Verwaltung der einzelnen Verbindungen gibt es drei verschiedene Call Session Control Functions (CSCF). Diese CSCFs ähneln den gängigen SIP Servern, wie Proxy, Registrar, und Redirect. Die notwendigen Aufgaben sind sehr detailliert zwischen den CSCFs aufgeteilt, um auch in großen Netzen eine effiziente Abwicklung der Anfragen durchführen zu können Proxy CSCF Die Proxy CSCF (P CSCF) ist die Kommunikationsstelle zu den Endbenutzern. Alle Nachrichten der Clients gehen an die P CSCF und die Nachrichten der anderen CSCFs werden über die P CSCF an die Clients weitergeleitet. Auf Wunsch des Users komprimiert der P CSCF die SIP Nachrichten und sichert sie mit IPsec ab. Des Weiteren kommuniziert der Proxy mit der Charging Data Function (CDF) und kann über sie Abrechnungsinformationen bereitstellen. Die P CSCF leitet Nachrichten wie z. B. Registrierungsanfragen und Vermittlungswünsche an die S CSCF (Serving CSCF) weiter. Bei Nutzern, die Kunden in

19 3 IP Multimedia Subsystem 19 einem fremden Netz sind, leitet die P CSCF diese Anfragen an die I CSCF (Interrogating CSCF) des fremden Anbieters weiter. Die notwendigen Kontaktinformationen über die I CSCFs erhält der P CSCF über den HSS (Home Subscriber Server). Notrufe werden vom P CSCF selbstständig erkannt und können ohne Umweg über den S CSCF an den für diesen Notruf zuständigen CSCF weitergeleitet werden Serving CSCF Die S CSCF kümmert sich um die Registrierung des Users und bezieht die Nutzerdaten und das passende Diensteprofil vom HSS. Mit Hilfe des Diensteprofils entscheidet der S CSCF über die Rechte des Nutzers. So ist es möglich, einem Nutzer das Telefonieren zu erlauben, dafür aber das Instant Messaging zu verbieten. Die Vermittlung an andere Nutzer und Anwendungen ist ebenfalls Aufgabe der S CSCF. Über den HSS wird die Kontaktadresse der gewählten Rufnummer oder URI (Uniform Resource Identifier) bestimmt und der Verbindungswunsch über die P CSCF an den entsprechenden Kontakt weitergeleitet. Im Gegensatz zur P CSCF ist die S CSCF in der Lage, dem Online Charging System (OCS) Abrechnungsinformationen zu liefern Interrogating CSCF Die I CSCF ist die Kontaktadresse für Anfragen aus fremden Netzen. Mit ihrer Hilfe wird Roaming und die providerübergreifende Kommunikation im IMS ermöglicht. Eingehende Anfragen werden an eine lokale S CSCF weitergeleitet. Bei einem Verbindungswunsch zu einem lokalen Application Server wird die Nachricht direkt an diesen weitergeleitet und die S CSCF somit entlastet. Den Kontakt des Zielsystems bzw. des nächsten Hops erhält die I CSCF über den HSS.

20 3 IP Multimedia Subsystem Home Subscriber Server Der HSS speichert die Daten inklusive der dazugehörigen Rechte der eigenen Nutzer sowie die Kontaktinformationen für Nutzer aus anderen Netzen (Home Location Register, HLR). Der HSS stellt somit die zentrale Datenbank des IMS dar. Die Abfragen der CSCFs und der Application Server erfolgen über DIAMETER. Bei der Verwendung von mehreren HSS in einem Netz wird noch eine Subscription Locator Function (SLF) benötigt, die die Anfragen der einzelnen CSCFs und Application Server an den für diese Aufgabe zuständigen HSS weiterleitet. 3.6 Application Server Application Server bieten erweiterte Dienste für das IMS Netz. Diese Server müssen nicht direkt im IMS Core stehen. Es wird jedoch davon ausgegangen, dass es im Allgemeinen möglich sein soll, die Nutzung des zur Verfügung gestellten Dienstes abzurechnen sowie die Autorisation des Users für diesen Dienst zu überprüfen. Hierzu ist eine Anbindung an den HSS über DIAMETER notwendig. Mögliche Dienste sind z. B. Push to Talk, Presence (Anzeige der Verfügbarkeit), Konferenzschaltungen, Anrufbeantworter oder dynamische Rufumleitungen. Bei Diensten wie der Rufumleitung ist zu beachten, dass bei jedem gewünschten Rufaufbau an Benutzer mit eingeschalteter Rufumleitung, der Application Server vom S CSFC angesprochen werden muss. Bei Diensten wie Presence muss der Application Server vom HSS permanent über Statusänderungen informiert werden. Die wichtigste Eigenschaft des Application Server ist, dass er SIP Anfragen bearbeiten und beantworten kann. Je nach Dienst muss der Application Server als SIP Proxy Pakete weiterleiten oder als SIP Client Gespräche annehmen. Bei Anwendungen wie Click to Dial,

21 3 IP Multimedia Subsystem 21 Weckruf oder einer Rückruffunktion muss der Application Server in der Lage sein, wie ein Client eine Session von sich aus zu initiieren. Varianten Die 3GPP sieht in der IMS Spezifikation die Weiterverwendung vorhandener Application Server vor. Hierbei handelt es sich um Server mit den Standards OSA SCS (Open Service Access Service Capability Server) oder CAMEL (Customized Applications for Mobile network Enhanced Logic), die in aktuellen Telefonnetzen eingesetzt werden und über OSA API4 (OSA Application Programming Interface) beziehungsweise CAP (CAMEL Application Part) angebunden werden. Abbildung 6: Anbindung der Application Server [IMSCS] Um diese Application Server an den S CSCF anbinden zu können, wurden die Umsetzer IM SSF (IP Multimedia Service Switching Function) und OSA SCS (Open Service Access Service Capability Server) definiert. Diese Dienste kümmern sich um die entsprechende Übersetzung nach SIP und umgekehrt. 4 Die Spezifizierung der API erfolgt durch die Parlay Group [PARLAY]

22 3 IP Multimedia Subsystem Application Server im IMS In der Dokumentation der 3GPP werden bereits einige mögliche Application Server beschrieben. Sie sollen als Beispiel für zukünftige Komfortmerkmale dienen und eine Mindestfunktionalität in zukünftigen Implementationen sichern. Presence Ein Presence Server verteilt Statusinformationen über einen Benutzer an eine Gruppe von weiteren Benutzern. So kann ein Teilnehmer immer erkennen, ob Freunde, Bekannte oder Mitarbeiter angemeldet und verfügbar sind. Auch kann über den Presence Dienst angezeigt werden, wenn ein Teilnehmer beschäftigt ist und nicht gestört werden möchte. Instant Messaging Über Instant Messaging ist es möglich, Textnachrichten unter den Nutzern auszutauschen. Dieser aus dem Internet bereits gut bekannte Dienst ist mit dem Short Message Service (SMS) oder einem einfachen Chat vergleichbar. Ein Instant Messaging Dienst impliziert in der Praxis immer einen Presence Dienst. Group Management Um Listen wie Adressbücher oder Buddylisten für Presence und Instant Messaging zentral zu speichern, ist ein Group Management Server notwendig. Über diesen Server sind beliebige Daten zentral speicherbar und somit unabhängig vom verwendeten Endgerät oder einer Benutzergruppe. Je nach Ausbaustufe können mit einem Group Management Dienst Groupware Funktionalitäten ermöglicht werden. Push to Talk Der sogenannte Walkie Talkie Mode für herkömmliche Telefone wird ebenfalls über einen Application Server ermöglicht. Dieser kümmert sich um die Verteilung des Medienstromes innerhalb der Push to Talk Gruppe und sorgt auf Wunsch dafür, dass immer nur ein Teilnehmer zur selben Zeit sprechen kann.

23 3 IP Multimedia Subsystem 23 Conferencing Um Konferenzen zu ermöglichen, wird ein Server benötigt, der in der Lage ist, mehrere Audiodatenströme zu mischen und an alle Empfänger zu verteilen. In der Praxis werden oft weitere Funktionen wie Autorisierung und eine erweiterte Verwaltung der einzelnen Konferenzräume gefordert. 3.7 Charging Die Abrechnung der im IMS angebotenen Dienste kann auf verschiedenen Wegen erfolgen. Gängig sind das Online Verfahren für Prepaid Kunden und das Offline Verfahren für Kunden, die im Nachhinein eine Rechnung erhalten. Abgerechnet wird meist nach Zeit. Aber auch das Flow Based Verfahren ist möglich. Bei diesem Verfahren können Dienste auf unterschiedliche Weise abgerechnet werden. Ein FTP Download kann nach Übertragungsvolumen, eine Textnachricht nach Zeichenanzahl und ein Telefonat nach Zeit und Entfernung abgerechnet werden. Für das Online Charging werden die notwendigen Informationen über das sogenannte Ro Interface an das Online Charging System übermittelt. Diese Funktion wertet in Echtzeit aus, ob das Konto des Nutzers noch ausreichend gedeckt ist oder ob ein weiteres Nutzen des Dienstes verwehrt werden muss. Informationen für das Offline Charging werden über das Rf Interface an die Charging Data Function weitergereicht, welche die notwendigen Call Detail Records (CDR) erstellt.

24 3 IP Multimedia Subsystem Quality of Service Im derzeitigem IMS Standard ist bereits eine Signalisierung der gewünschten Ende zu Ende QoS definiert. Die Art der Durchsetzung der Dienstgüte wird hierbei jedoch dem Provider überlassen. Dies kann als Definitionslücke angesehen werden. Die 3GPP sieht dies jedoch als Freiheit für die Provider, die Art der Qualitätssicherung selbst zu wählen. Möglich sind so wichtende Verfahren wie DiffServ (Differentiated Services) oder Verfahren wie RSVP (Resource Reservation Protocol), die die benötigte Übertragungskapazität reservieren. Nähere Informationen zu möglichen Verfahren zum Durchsetzten der gewählten Qualität finden sich unter [ABUSALAH].

25 4 Verfügbare Application Server 25 4 Verfügbare Application Server Da viele Unternehmen und Forschungseinrichtungen das IMS als großen Zukunftsmarkt sehen, gibt es bereits mehrere Produkte auf dem Markt, die eine IMS Unterstützung bieten. Diese Produkte sind kommerzielle Entwicklungen oder bestehen aus frei verfügbaren Open Source Anwendungen. Im Folgenden werden einige der bereits erhältlichen Softwarelösungen vorgestellt, mit denen ein Application Server realisiert werden soll. Aufgrund der Aktualität dieses Themas kommen in kurzen Zeitabständen neue Produkte hinzu oder die bereits bekannten Produkte werden erweitert oder abgeändert. Daher kann diese Übersicht nur ein Momentaufnahme sein. 4.1 IBM WebSphere IP Multimedia Subsystem Connector Mit dem WebSphere IMS Connector möchte IBM den bereits häufig eingesetzten WebSphere Application Server um IMS Funktionen erweitern. Die Strategie liegt darin, ein bereits bestehendes Produkt zu nutzen und über einen Adapter an das IMS anzubinden. Der Adapter übernimmt die Übersetzung zwischen den Formaten und bietet die Schnittstellen, die bei dem WebSphere Application Server nicht vorgesehen, aber im IMS notwendig sind. Der IMS Connector unterstützt SIP und HTTP Anwendungen, die über eine standard konforme SIP Anbindung und eine DIAMETER Schnittstelle in das IMS angebunden werden können. Besonders hervorgehoben wird die Möglichkeit Presence Informationen bereit zustellen und Group Management Funktionen zu ermöglichen. Als Einschränkung bietet der IMS Connector lediglich eine Rf Schnittstelle zum Offline Charging. Ein Online oder Flow Based Charging ist bisher noch nicht vorgesehen. [IBM]

26 4 Verfügbare Application Server Open Cloud Rhino IMS Application Server Der Rhino IMS Application Server von Open Cloud soll Mehrwertdienste (Value Added Services) im IMS ermöglichen. Es ist ein Framework, das laut Hersteller sehr gut skaliert und somit große und hochverfügbare Lösungen ermöglichen soll. Dieses Framework soll alle wichtigen Schnittstellen zu einem IMS Core bieten, unter anderem ist auch ein Ro Interface für das Online Charging enthalten. [RHINO] 4.3 Ericsson IMS weshare Ericsson bietet eine ganze Reihe an IMS Lösungen. Für diese Thesis besonders interessant ist Ericssons IMS weshare. Dieses Produkt soll viele neue Anwendungen für das IMS ermöglichen. Der Fokus liegt im Besonderen auf dem Wechsel zwischen den verschiedenen Medientypen während des Gesprächs und der Übertragung unterschiedlicher Daten an den Gesprächspartner. So sollen der Tausch von Bildern sowie beliebiger Dateien möglich sein, als auch das Übermitteln von einem Live Video. Neu im IMS Umfeld ist auch die Möglichkeit, gemeinsam Anwendungen zu nutzen. Möglich sind unter anderem ein Whiteboard oder eine markierbare Straßenkarte. [ERICSSON] 4.4 Ericsson IMS Messaging Mit dem IMS Messaging 2.0 bietet Ericsson eine Software an, die das IMS um einen Messaging Dienst erweitert, der zu den herkömmlichen Standards SMS (Short Message Service) und MMS (Multimedia Messaging Service) kompatibel sein soll. Auch IMPS (Instant Messaging and Presence Service) und einige proprietäre Instant Messaging Dienste

27 4 Verfügbare Application Server 27 sollen unterstützt werden. Für den Nutzer soll ein komplettes Interface mit einer Buddylist inklusive Presence Informationen zur Verfügung stehen. IMS Messaging 2.0 kann auch als Erweiterung anderer Applikationen genutzt werden. Beispielsweise zum Aufbau von Benachrichtigungsdiensten für einzelne Benutzer oder Benutzergruppen (z. B. Wirtschafts oder Sportnachrichten). [ERICSSON] 4.5 Ericsson IMS Push to Talk Ericssons Push to Talk Dienst (PTT) basiert auf dem Push to Talk over Cellular Standard (OMA5 PoC) und bietet User to User und User to Group PTT. Der Dienst soll mit Komfortmerkmalen wie einem Eingangsfilter und temporärer Deaktivierung Business und Privatkunden ansprechen. Ericssons PTT soll sich mit anderen Anwendungen kombinieren lassen, um mit Hilfe von Presence Informationen und Groupmanagement umfangreiche Szenarien kreieren zu können. [ERICSSON] 4.6 Ericsson IMS Multimedia Telephony Ericsson Multimedia Telephony soll etliche Privat und Gruppendienste ermöglichen. Als Beispieldienste werden Videotelefonie, Konferenzen, Groupware Dienste, Presence, Instant Messaging sowie eine Anbindung an Outlook genannt. [ERICSSON] 5 Open Mobile Alliance, erstellt Spezifikationen für den Mobilfunk

28 4 Verfügbare Application Server Fraunhofer Fokus Open IMS Core Der Open IMS Core von Fraunhofer Fokus ist eigentlich ein Core System auf Basis freier Komponenten, das als Testsystem entwickelt wird. Zu diesem IMS Core sind mittlerweile einige Application Server entwickelt worden. Dies sind einmal der Presence Server auf Basis des OpenSER sowie ein IPTV Streaming Server und ein Back to Back User Agent zur Vermittlung von Gesprächsteilnehmern über Funktionen wie Click to Dial. Diese Server haben jedoch momentan nur einen sehr geringen Funktionsumfang und sind als Beispielsoftware mit Prototypcharakter zu verstehen. 4.8 Bewertung Wie man an den oben genannten Beispielen sieht, gibt es bereits einige verfügbare Application Server für das IMS. Die Hersteller versprechen meist auch mehr Funktionalität als im IMS Standard definiert ist, besonders Ericssons IMS weshare bietet sehr interessante neue Ansätze und ermöglicht einen deutlichen Mehrwert des IMS gegenüber herkömmlichen Netzen. Jedoch scheint dieses Konzept eher auf Businesskunden mit geschlossenem Benutzerkreis und einheitlichen Clients ausgerichtet zu sein. Mangels einheitlicher Standards für einen großen Teil der Gruppenfunktionen ist eine starke Verbreitung dieses Konzepts vorerst nicht zu erwarten. Im Allgemeinen sieht man jedoch schnell, dass der Fokus der meisten Implementierungen auf einem guten Backend liegt. So sind meist ausgefeilte Gruppenfunktionen oder ein universelles Rechtemanagement möglich. Im Frontend, also beim Kontakt zum Nutzer, bietet nur Ericsson für das IMS innovative Funktionen an. IBM ermöglicht lediglich, seinen Application Server mit einer Webanwendung zu koppeln.

29 4 Verfügbare Application Server 29 Es sind noch mehr Dienste denkbar als die bereits vorgestellten, besonders im Bereich des Frontends sind noch viele Möglichkeiten offen. Einige neue Dienste werden im folgenden Kapitel genauer beschrieben.

30 5 Neue Dienste im IMS 30 5 Neue Dienste im IMS Die in den beiden vorangegangenen Kapiteln genannten Application Server haben teilweise einen sehr begrenzten Funktionsumfang. Denkbar sind komplexere Systeme, die dem Benutzer völlig neue Möglichkeiten bieten. In diesem Kapitel werden neue Dienste sowie die Kombination bereits bekannter Dienste erläutert. Diese Dienste beinhalten in der Großzahl die Videoübertragung und darstellung als Kernelement. Der Fokus bei diesen Diensten liegt auf der Schnittstelle zum Nutzer, die mehr Funktionsvielfalt ermöglichen soll als bis heute üblich. Die reine Videotelefonie wird hier nicht als gesonderter Dienst, sondern analog zur Sprachtelefonie als Kernelement des IMS betrachtet, für die man keinen Application Server benötigt. 5.1 Videodienste Derzeit ist es möglich, mit einem Gesprächspartner auch über Video zu kommunizieren. In den bestehenden Telefonnetzen ist es allerdings unüblich, die Wiedergabemöglichkeit von Video für weitere Zwecke zu nutzen. Über einen Application Server ist es möglich, Videos wie zum Beispiel Kurzfilme von Youtube über den Client abzuspielen. Ebenfalls sind Videos möglich, die ein Menü oder sonstige Informationen enthalten. Mit der bereits vorhandenen Steuerungsmöglichkeit über DTMF6 (Dual Tone Multiple Frequency) kann interaktiv agiert werden. Mögliche Anwendungen sind videounterstützte Auskunfts oder Reservierungs systeme analog zu einem IVR (Interaktive Voice Response). Ebenso bietet es sich an, herkömmliche IVRs durch die Grafikausgabe zu erweitern. Dies ist besonders für Hörgeschädigte von besonderem Vorteil. Auch alte Menschen können davon 6 Eine Übertragung der bei DTMF ursprünglich verwendeten Tonsignale ist bei SIP nicht mehr zwingend notwendig. Die Eingaben können auch als SIP-INFO Nachricht versendet werden.

31 5 Neue Dienste im IMS 31 profitieren, vor allem da Auskunftssysteme über HTML oder WAP für sie oft keine Alternative darstellen. Abbildung 7: Videomenü Liveübertragung Ähnlich einer Fernsehübertragung können Videos in Echtzeit übertragen werden. Dies können beispielsweise Premiumdienste für Sportfans sein. Die Nutzung dieses Dienstes kann sehr einfach sein. Der Nutzer wählt die Nummer des gewünschten Programms und sieht dann den Live Stream eines aktuellen Ereignisses. Dieser Anruf kann dann wie ein gewöhnlicher Mehrwertdienst abgerechnet werden. Videoüberwachung Die oben genannte Technik lässt sich auch zur Überwachung einsetzen. Hierzu wird eine entsprechend ausgestattete Kamera benötigt, die den Video Stream auf Anfrage zur Verfügung stellt. Diese Technik kann zur individuellen Objektüberwachung genutzt werden oder in einer kostengünstigen Variante als einfaches Babyfon für den Privatgebrauch.

32 5 Neue Dienste im IMS 32 Anrufbeantworter Ein herkömmlicher Anrufbeantworter zeichnet lediglich Audiodaten auf. Über eine Videoaufzeichnung können viele Informationen, wie die Darstellung von Objekten oder auch Emotionen, auf einfache Weise an den Empfänger übertragen werden. In Kombination mit den oben vorgestellten grafischen Menüs ist eine einfache Bedienung möglich. Wecker Ein Weckruf ist ein Basisdienst, welcher nicht direkt etwas mit Videoübertragung zu tun hat. Allerdings kann das Setzen der Weckzeit und weiterer Parameter wie Wiederholungstage über ein Videomenü komfortabler erfolgen als über eine reine Audioverbindung. Videokonferenz Audiokonferenzen entsprechen dem Stand der Technik. Videokonferenzen sind derzeit nur mit proprietären Systemen möglich. Über einen Application Server, der die Videosignale mischt sind Konferenzen mit mehreren Teilnehmern möglich. Die Anzahl ist nur durch die Größe des Bildschirmes begrenzt, da dieser für die einzelnen Teilnehmer aufgeteilt werden muss. Ein einfaches Zusammenfügen der Informationen wie bei Sprachkonferenzen ist in diesem Fall nicht möglich. Abbildung 8: Videokonferenz

33 5 Neue Dienste im IMS Signalisierungsdienste Da es von Interesse sein kann, weitere Informationen wie eine URL (Uniform Resource Locator) oder den Link zu einer Datei zu liefern, ist es denkbar, dass ein Application Server dem Teilnehmer diese Informationen über eine entsprechende Signalisierung zur Verfügung stellt. Diese Informationen können Links zu Diensten mit den Protokollen HTTP, FTP oder auch RTSP (Real Time Streaming Protocol) sein, die den Nutzern zahlreiche neue Möglichkeiten bieten. Ergänzende Informationen, z. B. zu einem Beratungs oder Servicegespräch, können als Link zu einer Webseite übermittelt werden. So kann sich ein Kunde an einer Servicehotline direkt eine zu seiner Anfrage passende Beschreibung auf der Firmenwebseite ansehen. Anstatt auf Webseiten kann die Gegenstelle auch auf andere Inhalte wie Bilder, Videos oder Programme verweisen. Videoübertragung High Quality Die gewöhnliche Videotelefonie ist nur für eine sehr geringe Qualität ausgelegt. So hat man im heutigen Festnetz nur eine sehr geringe Bandbreite und im Mobiltelefon nur wenig Platz für ein größeres Display. Wenn allerdings ein IMS Client genutzt wird, der die obigen Limitierungen nicht aufweist (PC, Set Top Box für den Fernseher), ist es möglich Videos in einer hohen Qualität darzustellen. Ein Application Server kann einen Video on Demand Dienst (VoD) oder eine Live Übertragung in entsprechender Qualität zur Verfügung stellen. Durch die Anbindung an das IMS können die Anbieter separate VoD Dienste im Internet ersetzen und das IPTV in ihr Netz mit einbinden und an ihre Kunden vermarkten. Da lediglich auf einen RTSP Server verwiesen wird, können bereits vorhandene Infrastrukturen verwendet werden.

34 5 Neue Dienste im IMS 34 Gaming Des Weiteren kann der Application Server die Verbindung mit anderen Teilnehmern oder Servern für Spiele herstellen. Für die Spiele benötigte Server können ebenfalls von dem IMS Provider betrieben werden oder werden, bei entsprechenden Vereinbarungen, von den Spieleherstellern zur Verfügung gestellt. Über eine einheitliche Plattform für Onlinegames und das Bilden fester Communities innerhalb des Kundenkreises ist eine zusätzliche Kundenbindung möglich.

35 6 Vorabüberlegungen 35 6 Vorabüberlegungen Vor der Implementierung eines Application Servers müssen einige Dinge betrachtet werden, die für den Server vorausgesetzt werden, definiert werden müssen oder sich als Fallstricke erweisen könnten. Für diese Thesis wurden bereits vor und während der Implementierung zahlreiche Tests durchgeführt und einige Grundlagen betrachtet, um grundlegende Fehler bei der Implementierung zu vermeiden und das Risiko eines negativen Fazits zu minimieren. 6.1 Videoformate Von der 3GPP wurde bereits 2005 das streamingfähige Videokontainerformat.3gp für niedrige Bitraten definiert. Dieses Format ist bereits heute bei Mobiltelefonen ein gängiger Standard zur Videospeicherung und übertragung. Dieses Kontainerformat ist eine Vereinfachung des.mp4 Formats und kann H.263 und MPEG 4 Part 2 als Videostream sowie Audiodaten im Format AAC LC aufnehmen. Im Gegensatz zu.mp4 ist auch AMR (Adaptive Multi Rate) als Audiocodec erlaubt. Hier hat die 3GPP zusätzlich zu dem AMR Format mit 8kHz Samplingfrequenz das Format AMR WB (wide band) mit 16kHz Samplingfrequez spezifiziert. Die vorgesehenen Auflösungen für die Videodaten sind 352x288 (CIF, Common Intermediate Format), 176x144 (QCIF, Quarter CIF) und 128x96 Pixel. Einige Geräte unterstützen jedoch auch 300x180, 320x240 und 640x480 Pixel. Für spezielle Clients sind auch Auflösungen bis 1408x1152 Pixel vorgesehen. Dieses hochauflösende Format ist eher theoretischer Natur. Mittlerweile gibt es die weit verbreiteten Formate für hochauflösende Videos 768i/p7 und 1050i/p. Selbst moderne Flachbildschirme sind bereits an diese beiden Auflösungen angepasst. So ist es zu erwarten, 7 interlaced = Halbbilder / progressive = Vollbilder

36 6 Vorabüberlegungen 36 dass sich diese Formate auch im IMS durchsetzten und auf eine verlustbehaftete Konvertierung verzichtet wird. Des Weiteren wird davon ausgegangen, dass eine Übertragung im aktuellen h.264 Format gesendet wird, da sich so die Datenrate weiter reduzieren lässt H.263 H.263 wurde Mitte der neunziger Jahre von der ITU zur komprimierten Videocodierung spezifiziert und gehört ebenso wie H.264 zu dem MPEG 4 Standard. H.263 wurde speziell für die Übertragung von Videoströmen mit geringer Bewegung über Verbindungen mit niedriger Datenrate entwickelt. Dieses Format eignet sich so vorzugsweise für Videokonferenzen, die sich mit Hilfe von P Frames (predictive coded pictures) stark komprimieren lassen. Für Unterhaltungsmedien wie Videofilme bietet es sich nur bedingt an. Erst seit der Variante H.263+ werden die weiter unter beschriebenen B Frames (bidirectional coded picture) unterstützt [RFC4629]. I Frames I Frames beinhalten sogenannte Intra Coded Pictures, diese Bilder (Frames) sind als Voll oder Standbild zu betrachten. Es gibt keinen Bezug zum vorhergehenden oder nachfolgenden Bild. Solange dieser Frame komplett übertragen wird, ist die Darstellung des Bildes fehlerfrei. Bei der Fragmentierung des Paketes auf mehrere RTP Pakete wird die Darstellung bei Verlust eines oder mehrerer Pakete jedoch gestört. Bei Videoübertragungen ist das erste Bild immer ein I Frame. Abbildung 9 zeigt einen typischen Beginn einer Videoübertragung. Als Erstes wird ein Vollbild mit Hilfe von drei RTP Paketen übertragen, anschließend folgen mehrere Teilbilder.

37 6 Vorabüberlegungen 37 Abbildung 9: Der Beginn eines Videos P Frames Predictive coded pictures enthalten eine Referenz auf das vorhergehende Bild. Lediglich Änderungen gegenüber dem vorangegangenen Bild werden übertragen. Durch P Frames wird die benötigte Bandbreite stark reduziert. Zur Vermeidung von größeren Wiedergabestörungen müssen jedoch regelmäßig I Frames gesendet werden, denn wenn das vorhergegangene Bild fehlerhaft ist, wird es das Folgende ebenfalls sein. Abbildung 10: Originalbilder und komprimiertes Video (vereinfacht)

38 6 Vorabüberlegungen 38 B Frames Modernere Videocodecs, wie auch H.263+ bieten die Möglichkeit der B Frames an. Diese Frames beinhalten eine Referenz auf das vorherige und das folgende Bild. Für die Videotelefonie sind diese Videos allerdings nur bedingt verwendbar, da bei einer Kodierung in Echtzeit kein Bezug auf ein zukünftiges Bild hergestellt werden kann. 6.2 Videoübertragung Der Verlust von Voll oder Teilbildern kann die Wiedergabequalität sehr stark einschränken. Besonders die ersten Pakete einer Videoübertragung gehen oft verloren. Dies passiert bei einem verspäteten Öffnen des Socket zum lesen oder wenn der NAT Router erst nach dem Versenden eines RTP Paketes eingehende Pakete zum Client durchstellt. Zur Abhilfe empfiehlt es sich, besonders am Anfang einer Videoübertragung Vollbilder öfters zu wiederholen. Bei Menüs und anderen wichtigen Hinweisen müssen ebenfalls mehrere I Frames gesendet werden, da sonst eine Lesbarkeit nicht gewährleistet werden kann. Ein Anrufbeantworter beginnt mit der Aufnahme gewöhnlich erst nach dem Abspielen eines Hinweises oder einer Ansage. So kann es auch hier zu Problemen durch ein fehlendes Vollbild kommen.

39 6 Vorabüberlegungen 39 Abbildung 11: Diese Aufnahme beginnt mit einem P-Frame Um dieses Problem zu umgehen, muss das Telefon angewiesen werden, zu Beginn der Aufnahme ein Vollbild zu senden. Das Draft XML Schema for Media Control [MEDIACONTROL] geht genau hierauf ein. Mit Hilfe einer SIP INFO Nachricht soll der Videoencoder des Telefons angesprochen werden. Der Payload im XML Format der folgenden Nachricht weist ein neues Vollbild an: Session Initiation Protocol Request-Line: INFO SIP/2.0 Message Header Via: SIP/2.0/UDP *.*.16.72:5060;branch=z9hG4bK ;rport From: "2000" To: Contact: Call-ID: CSeq: 102 INFO User-Agent: Asterisk PBX Max-Forwards: 70 Content-Type: application/media_control+xml Content-Length: 205 Message body extensible Markup Language <?xml version="1.0" encoding="utf-8"?>

40 6 Vorabüberlegungen 40 <media_control> <vc_primitive> <to_encoder> <picture_fast_update> </picture_fast_update> </to_encoder> </vc_primitive> </media_control> Übertragungsraten Da es auch in Zukunft noch Internetverbindungen geben wird, die nicht mit großen verfügbaren Datenraten aufwarten können, ist es notwendig, die minimal benötigte freie Übertragungskapazität für die Videoübertragung zu ermitteln. Es wurden Messungen mit verschiedenen Inhalten durchgeführt, die jeweils mit CIF und mit QCIF Auflösung übertragen wurden. Die hier verwendeten Messvideos wurden mit dem Programm ffmpeg erzeugt, welches eine möglichst starke Komprimierung vornehmen sollte. CIF (352x288) Menü 30kByte/Menü 100kByte/s QCIF (176x144) 12kByte/Menü 40kByte/s Videochat 8,9kByte/s 7,2kByte/s Videoclip 6,0kByte/s 5,8kByte/s Abbildung 12: Übertragungsraten für Videos (exklusive Audio) Die Videomenüs haben die Besonderheit, dass sie im Wesentlichen nur aus einem Vollbild bestehen. Solange keine Animation oder das Versenden von mehreren I Frames vorgesehen ist, wird das Menü nur einmalig übertragen. Danach sinkt die benötigte Übertragungskapazität. Bei der genauen Betrachtung der Übertragungsrate kann man erkennen, dass es einen deutlichen Burst gibt, die übertragene Datenmenge insgesamt jedoch verhältnismäßig gering ist.

41 6 Vorabüberlegungen 41 Der Videochat wurde mit einer handelsüblichen Webcam aufgenommen, wogegen der Videoclip bereits vorverarbeitet wurde. Hier kann man erkennen, dass während der Vorverarbeitung bereits eine Kompression stattgefunden hat. Diese führt zu einer nochmals reduzierten Datenrate, da das Originalvideo bereits einen verringerten Informationsgehalt hat. Die großen Unterschiede bei den verwendeten Auflösungen der Videomenüübertragung und die geringen Unterschiede bei den restlichen Übertragungen zeigen, dass hauptsächlich die I Frames eine deutlich erhöhte Übertragungsrate benötigen. Durch die gute Kompression der P Frames wirkt sich dies im Mittel kaum aus. Abbildung 13: Verlauf der Videoübertragungsrate während einer IVR-Sitzung Abbildung 13 zeigt den Verlauf der benötigten Übertragungskapazität während einer IVR Sitzung. Es wurden einige Hinweise und Menüs gesendet sowie ein Video während den Sekunden 41 bis 65 abgespielt.

42 6 Vorabüberlegungen Signalisierung Der zu erstellende Application Server soll Inhalte an den Client signalisieren, die bisher im SIP Standard noch nicht vorgesehen sind. Bei SIP sind viele verschiedene Möglichkeiten denkbar, neue Inhalte wie z. B. eine URL zu signalisieren. Die naheliegenden Möglichkeiten werden nun vorgestellt SIP INVITE Bei einem herkömmlichen SIP Gespräch werden die Informationen zur Übertragung der Audio und Videodaten über RTP im SDP Header (Session Description Protocol) der SIP Nachricht angegeben. Es ist prinzipiell möglich, beliebige Inhalte über eine Erweiterung des SDP zu übertragen. Bereits heute ist es gängig, während eines Gesprächs über das Senden einer neuen INVITE Nachricht, dem sogenannten Re Invite, die Parameter der Verbindung zu ändern. Abbildung 14: Re-Invite zu Beginn des Gesprächs

43 6 Vorabüberlegungen 43 Eine Signalisierung über eine INVITE Nachricht kann auf eine der folgenden Weisen geschehen. Gleiche Call ID Unter Beibehaltung der Call ID wird mit einer neuen Nachricht das wiederzugebende Medium (Datenstrom) geändert. So kann ein Voice Call zur Wiedergabe eines Videos einer externen Quelle umgelenkt werden. Nachteil dieser Methode ist, dass die vorherige Verbindung aufgegeben wird. Während der Wiedergabe des Videos wird das Gespräch unterbrochen. Abbildung 15: Unterbrechung eines Gesprächs für eine Videoübertragung Neue Call ID Bei der Verwendung einer neuen Call ID kann eine weitere Übertragung initiiert werden, die unabhängig von der Ursprungsverbindung ist. Diese Unabhängigkeit hat jedoch den Nachteil, dass eine solche Signalisierung nicht immer korrekt zugeordnet werden kann. Mit dieser Methode kann es beispielsweise passieren, dass eine Telefonanlage den neuen

44 6 Vorabüberlegungen 44 Verbindungswunsch an einen anderen Teilnehmer der gleichen Ring Group8 vermittelt. Auch der Bezug zu einer Verbindung bei nur einem Teilnehmer kann nicht sichergestellt werden, da es prinzipiell möglich ist, mehrere Verbindungen gleichzeitig aufrecht zu erhalten. Dies muss bei dieser Signalisierungsmethode zwangsweise unterstützt werden. Abbildung 16: Übertragung eines Videos parallel zu einem Gespräch Bei einem INVITE geht man von einer komplett SIP gesteuerten Abwicklung aus, die einen definierten Anfang und ein definiertes Ende besitzt. Dies ist beispielsweise für eine Webseite ungünstig, hier soll lediglich einmal auf diese verwiesen werden. Wie lange der Nutzer diese betrachtet und welche Verweise auf der Seite benutzt werden, ist für den Applikation Server in der Regel uninteressant. Des Weiteren bricht diese Variante mit einigen Grundprinzipien von SIP, wie dem Re Invite. 8 In einer Ring-Group läuten mehrere Telefone bei einem Anruf an eine bestimmte Nummer.

45 6 Vorabüberlegungen SIP INFO Eine weitere Möglichkeit ist die Signalisierung über SIP INFO Nachrichten. Diese Nachrichten dienen vielen verschiedenen Zwecken, so kann über INFO ein beliebiger Text für ggf. sogar proprietäre Erweiterungen gesendet werden. In der Praxis wird so unter anderem ein Videotelefon zum Senden eines Vollbildes angewiesen. Bei der Verwendung von INFO Nachrichten muss ein Nachrichtenformat definiert werden, das entsprechende Verweise aufnehmen kann. Da bereits DTMF Töne über INFO gesendet werden können, ist der ursprüngliche Verwendungszweck dieses Nachrichtentyps passend. Eine mögliche Implementierung mit INFO Nachrichten wird weiter unten in diesem Kapitel vorgestellt SIP NOTIFY Die SIP NOTIFY Nachrichten dienen unter anderem dazu, Telefonen besetzte Teilnehmer oder Leitungen zu melden, damit diese Statusinformationen bereits vor der Anwahl eines besetzten Teilnehmers dem Nutzer bekannt gegeben werden können. Die NOTIFY Nachrichten haben somit einen eher passiven Charakter, eine weitgehendere Aktion als das Aktivieren oder Deaktivieren einer Leuchtdiode ist nicht vorgesehen. Des Weiteren müssen NOTIFY Nachrichten vom Client abonniert werden, sie werden erst nach einer Beauftragung durch eine SUBSCRIBE Nachricht versendet. Eine Verwendung für den Application Server wäre somit weit weg von der eigentlichen Nutzung.

46 6 Vorabüberlegungen SIP MESSAGE Die MESSAGE Nachrichten werden zum Austausch von Kurznachrichten verwendet. Über MESSAGE sind Instant Messaging und Chaten auch parallel zu einem Telefongespräch möglich. Ein Verweis kann hier in Form einer URL in eine Textnachricht eingebettet werden. Hier ist eine eindeutige Zuordnung durch eine gleichbleibende Call ID möglich. Betrachtet man gängige Chat und Instant Messaging Anwendungen, fällt schnell auf, dass diese eine Übermittlung beliebiger URLs unterstützen. Über eine entsprechende Markierung auf der Senderseite oder über die Erkennung einer URL anhand eines bekannten Protokolls (z. B. kann diese URL grafisch hervorgehoben und anwählbar gemacht werden. Eine Webseite kann so, durch einfaches Anklicken der URL innerhalb des Textes, aufgerufen werden. Die meisten Softphones unterstützen bereits SIP MESSAGE Nachrichten und können oft einen Chat bieten. Somit bietet sich die Möglichkeit über eine einfache Erweiterung dem User URLs zukommen zu lassen. Die URL muss nur noch angeklickt werden oder sie wird vom Softphone automatisch geöffnet. Auch können weitere Informationen wie eine Kurzbeschreibung des Inhaltes mitgeliefert werden. Die Signalisierung ist über jedes standardkonforme SIP Netz möglich. Eine Erweiterung der zwischenliegenden SIP Komponenten ist nicht notwendig, da auch strengere SIP Proxys diese Nachrichten weiterleiten. Da dieselbe Call ID verwendet werden kann, ist auch die Zuordnung eindeutig.

47 6 Vorabüberlegungen Anwendungssteuerung Die Steuerung der Anwendung des Users kann ebenfalls auf mehreren Wegen geschehen. Der klassische Weg ist die Verwendung von DTMF (Dual Tone Multiple Freqency), auch MFV (Mehrfrequenzwahlverfahren) genannt. Hier werden je nach Taste zwei verschiedene Frequenzen überlagert. Den Ursprung im analogen Festnetz erkennt man gut daran, dass die Verteilung der Frequenzen passend zur Anordnung der Tasten gewählt wurde (siehe Abbildung 17). Insgesamt ist die Übermittlung von 16 verschiedenen Zeichen vorgesehen, wovon meist nur 12 Zeichen in der Praxis genutzt werden Hz 1336 Hz 1477 Hz 1633 Hz 697 Hz A 770 Hz B 852 Hz C 941 Hz * 0 # D Abbildung 17: Tastenbelegung für DTMF Auch in digitalen Netzen wie ISDN und auf SIP basierenden Telefonsystemen findet DTMF noch heute Verwendung. Bei SIP Telefonen gibt es drei verschiedene Möglichkeiten, DTMF Signale zu übermitteln. Entweder der Tastendruck wird über eine SIP INFO Nachricht oder über RTP versendet. Bei der Nutzung von RTP gibt es zwei verschiedene Möglichkeiten. Entweder wird die gedrückte Taste im RTP Header angegeben (RFC 2833) oder die Frequenzen werden im RTP Payload versendet (inbound). Die letzte Möglichkeit ist zum PSTN kompatibel, wobei bei den anderen Verfahren das Media Gateway lediglich eine Übersetzung durchführen muss. Die Steuerung über DTMF verlangt von zwischenliegenden

48 6 Vorabüberlegungen 48 Komponenten keine neue Funktionalität. Wenn es nicht notwendig ist, mehr als einige wenige Zeichen an die Anwendung zu senden, reicht DTMF für viele Anwendungen vollkommen aus. Als neue Möglichkeit bietet sich wieder eine SIP MESSAGE Nachricht an. Hier sind vielfältigere Eingabemöglichkeiten vorhanden. Die Beschränkung auf 16 verschiedene Zeichen fällt weg. Analog zur Signalisierung aus der Gegenrichtung ist es möglich, SIP INFO Nachrichten zur Steuerung zu nutzen. Hier ist es jedoch notwendig, wie bei der Signalisierung, einen neuen Payload Typ für diese Nachricht zu definieren. 6.5 Kommunikation über SIP INFO Bei einer Einbindung neuer Steuermöglichkeiten in das IMS während der derzeit noch andauernden Spezifizierungsphase ist eine Implementierung der Kommunikation mit Hilfe von SIP INFO Nachrichten möglich und sinnvoll. Die erweiterte Funktionalität der SIP Info Nachrichten soll zusätzliche Informationen zu einem bereits bestehenden Telefongespräch signalisieren können. Dies können die bereits genannten fremden Inhalte wie Webseiten sein sowie die Steuerung der Anwendung über Tastendrücke oder weitere Aktionen (Mausnavigation, Touchpad etc). Das Besondere an dieser Variante ist, dass die Nachricht direkt an das entsprechende Modul weitergereicht wird und eine direkte Implementierung der Funktion im Telefon nicht notwendig ist. Das Modul, welches die Anfrage dann verarbeiten muss, kann die Steuerlogik im Application Server oder der Mediaplayer beim Client sein. Der Payload kann wie bei der Videoupdatefunktion in XML eingebettet werden. Eine Rückmeldung über einen einzelnen Knopfdruck kann über eine einfache XML Nachricht erfolgen:

49 6 Vorabüberlegungen 49 Content-Type: application/session_navigation+xml <?xml version="1.0" encoding="utf-8"?> <session_navigation> <nav_primitive> <to_application> <button_pressed> 3 </button_pressed> </to_application> </nav_primitive> </session_navigation> Der Content Type signalisiert dem Empfänger, dass eine Session Steuerung im XML Format vorliegt. Über nav_primitive wird angegeben, dass es sich hierbei um eine Grundfunktion zur Steuerung handelt. Mit to_application wird angegeben, dass diese Nachricht für die Steuerlogik vorgesehen ist. Sie sagt aus, dass die Taste 3 gedrückt wurde. Anstatt eines einzelnen Ereignisses wie einem Tastendruck ist auch die Angabe eines Textes möglich: <text_feeded> yes </text_feeded> Der Aufbau der Signalisierungsnachricht erfolgt auf sehr ähnlicher Weise. Lediglich die Tags der Nachricht verweisen auf andere Elemente des Zielsystems: Content-Type: application/content_control+xml <?xml version="1.0" encoding="utf-8"?> <content_control> <link_primitive> <to_application> <show_url> </show_url>

50 6 Vorabüberlegungen 50 </to_application> </link_primitive> </content_control> Eine URL soll an die entsprechende Anwendung des Clients weitergeleitet werden. Dazu wird im Content Type der Typ content_control angegeben. Er besagt, dass für diese Nachricht eine externe Anwendung notwendig ist. Hier handelt es sich um einen Browser, der für die Betrachtung von Webseiten zuständig ist. Es soll die Grundfunktion show_url ausgeführt werden, die in diesem Fall auf die Webseite verweist. Ein Link auf einen VoD Dienst kann über das Tag show_video erfolgen: <show_video> rtsp://video.foo.bar </show_video>

51 7 Implementierung von Videobox 51 7 Implementierung von Videobox Um einige der in Kapitel 5 genannten Application Server zu implementieren, soll eine einheitliche Plattform entwickelt werden. Vereinend für viele Anwendungen kann eine Navigation über grafische Menüs und eine Ausgabe grafischer Hinweise sein. Hierzu muss der Application Server Videos generieren und an den Client senden können sowie Tastendrücke auswerten. Eine dahinter liegende Steuerung ermöglicht, unterschiedlichste Strukturen abzubilden. Über Erweiterungen zur Signalisierung fremder Inhalte sind viele neue Funktionen möglich. Im Folgenden wird ein universelles Framework erstellt, welches die Funktionen eines IVR mit denen der Videoübertragung und der Signalisierung von weiteren Inhalten erweitert. Zusätzlich zu der vollautomatischen Steuerung als IVR, wird es eine Möglichkeit geben, Inhalte manuell durch einen Operator signalisieren zu lassen. 7.1 Architektur Als universelle Architektur des IVRs wurde eine baumartige Menüstruktur ausgewählt. Über das Hauptmenü können Inhalte oder Untermenüs angewählt werden, die wiederum eine weitere Verzweigung erlauben. Die mit dem Framework zu erstellende Anwendung wird in einer Datenbank abgebildet, die alle notwendigen Daten zur Generierung der Ausgaben und der Navigation innerhalb der Anwendung beinhaltet. Die Datenbank basiert auf der in Abbildung 18 zu sehenden einfachen Struktur. Über eine Referenztabelle kann auf ein Menü oder ein Modul verwiesen werden. So ist es möglich gleiche Inhalte in verschiedenen Menüs unter unterschiedlichen Namen einzubinden.

52 7 Implementierung von Videobox 52 Abbildung 18: Struktur der Datenbank (vereinfacht) Um mehrere Dienste über ein einheitliches Interface zuzulassen, soll es möglich sein, die einzelnen Dienste unter verschiedenen Rufnummern zu erreichen und wahlweise das Gesamtsystem über eine übergeordnete Rufnummer. Die Nummern werden dazu mit der Menüstruktur verknüpft. Bei einer direkt anwählbaren Menütiefe von beispielsweise 3 Ebenen kann über eine Nummer mit der Endung 000 das Hauptmenü angewählt werden. Über die Endung 100 wird der erste Menüeintrag erreicht, unter der Endung 230 der dritte Eintrag des zweiten Menüpunktes. Abbildung 19: Adressierung über die Rufnummer Über ein entsprechendes Mapping im Rufnummernplan des Application Servers können beliebige Rufnummern auf diese Verzweigungsrufnummern abgebildet werden, um die externen Rufnummern frei wählen zu können. So kann ein Anbieter mehrere Anwendungen in

53 7 Implementierung von Videobox 53 einen übergeordneten Kontext zusammenfügen und der Kunde hat weiterhin die Möglichkeit, bestimmte Anwendungen über eine vorgegebene Rufnummer direkt zu erreichen Menüs Die wichtigste Komponente von Videobox ist das Menü. Ein Menü ist ein kurzes Video, welches die möglichen Verzweigungen in der Struktur anzeigt. Durch die Wahl eines Menüpunkts kann ein weiteres Menüs oder eine Anwendungen aufgerufen werden. Der Inhalt des Menüs wird in der Datenbank gespeichert. In der entsprechenden Tabelle finden sich die Überschriften, das Hintergrundbild und alle weiteren Optionen Hinweis Ein Hinweis ist ein kurzes Video, das einen frei wählbaren Text enthält. Diese Videos dienen den einzelnen Modulen als einfache Ausgabemöglichkeit. Um personalisierte Hinweise erstellen zu können, werden diese als Template angelegt. Dies bedeutet, dass sie Markierungen enthalten können, die durch einen entsprechenden Text ersetzt werden können. Ein Hinweis mit dem Text welcome {firstname} {lastname} ermöglicht durch Ersetzen der Markierungen {firstname} und {lastname} die individuelle Begrüßung des Anrufers zu Beginn der Anwendung Modul Ein Modul ist der eigentliche Inhalt der Anwendung. Es kann beispielsweise einen Videofilm abspielen, ein Video aufnehmen, dem Nutzer eine URL übermitteln oder komplexere Aufgaben übernehmen. Zu jedem Modul lässt sich ein Hinweis als Vorspann hinzufügen, um

54 7 Implementierung von Videobox 54 auf einfache Weise einheitliche Videos als Vorspann hinzufügen zu können. Während einfachere Module wie die Videowiedergabe bereits Teil des Framworks sind, müssen komplexere Module, wie ein Anrufbeantworter, selbst erstellt und dem Framework hinzugefügt werden Navigation Unterpunkte eines Menüs werden mit Hilfe von DTMF angewählt. Nach Wahl eines Unterpunktes durch Drücken der entsprechenden Taste wird dieser Unterpunkt aufgerufen. Abbildung 20: Navigation innerhalb einer Anwendung

55 7 Implementierung von Videobox 55 Auf Wunsch können Menüs mit nur einem Eintrag automatisch übersprungen werden. In diesem Fall wird der einzige vorhandene Eintrag ausgewählt. Die Videowiedergabe kann durch Drücken der Taste # abgebrochen werden, in diesem Fall wird automatisch zum nächsten Teil der Anwendung gesprungen. Mit Hilfe der Taste 0 begibt man sich zurück in das übergeordnete Menü. Wenn sich der Nutzer bereits im Hauptmenü befindet, wird nachgefragt ob die Anwendung beendet werden soll. 7.2 Verwendete Software Für die Entwicklung der notwendigen Komponenten wurde ausschließlich freie Software verwendet, die unter verschiedenen Open Source Lizenzen steht Hauptkomponenten des Clients Auf der Seite des Client kommt das Softphone Linphone zum Einsatz. Dies ist derzeit das einzige frei erhältliche Softphone mit Videounterstützung, das mit dem Videocodec H.263 gut zurecht kommt und alle weiteren Anforderungen in diesem Projekt erfüllt. Eine Closed Source Anwendung oder ein 3GP Telefon kann nicht verwendet werden, da Erweiterungen auf diesen Systemen nicht ohne Weiteres möglich sind. Linphone erhielt einen einfachen Patch, welcher eintreffende SIP MESSAGE Nachrichten auswertet. Wenn ein bekanntes Protokoll wie HTTP oder RTSP gefunden wird, wird die entsprechende Anwendung angewiesen, die entsprechende Webseite anzuzeigen, beziehungsweise das Video abzuspielen. Das Senden von DTMF Tönen über SIP und RTP ist in der verwendeten Version von Linphone bereits enthalten. Weitere Anforderungen an das Client Equipment sind ein Webbrowser und ein RTSP fähiger Mediaplayer. Da hier ein breites Spektrum an funktionsfähiger Software vorhanden ist, ist die Wahl der verwendeten Anwendungen nicht so bedeutend. Es wurde der Konqueror zum

56 7 Implementierung von Videobox 56 Anzeigen von Webseiten und der Video LAN Client (VLC) zur Wiedergabe von RTSP Videoströmen gewählt. Hier kann jedoch auch jede andere vergleichbare Software genutzt werden Hauptkomponenten des Servers Asterisk Als Basis für den Application Server wurde die Software PBX (Private Branche Exchange) Asterisk gewählt. Momentan ist keine vergleichbare Software erhältlich, die einen ähnlichen Funktionsumfang besitzt. Eine Alternativsoftware, die keinen wesentlich höheren Implementierungsaufwand erfordern würde, konnte nicht gefunden werden. Asterisk lässt sich über mehrere Schnittstellen um fast beliebige Funktionen erweitern. Hier wurde hauptsächlich auf das Asterisk Gateway Interface (AGI) zurückgegriffen, da sich die PBX so einfach über die Standardeingabe (stdin) und die Standardausgabe (stdout) steuern lässt. Zur Nutzung des Asterisk AGI gibt es mehrere Bibliotheken, die eine abstrakte Steuerung des Asterisk ermöglichen. Für dieses Projekt wurde die PHP AGI gewählt, um Funktionen für das PHP CLI9 Skript und für ein PHP Webinterface nutzen zu können. Das PHP Script wird über das Modul AGI im Rufnummernplan aufgerufen. exten => s,1,agi(/pathto/script.php) Das Asterisk Gateway Interface bietet dem aufgerufenen Programm die gleichen Möglichkeiten wie der normale Rufnummernplan der PBX. Die aufgerufene PHP Anwendung kann so alle Aktionen durchführen, die im Rufnummernplan von Asterisk auch möglich sind. 9 Die Command Line Interface (CLI)-Version von PHP ermöglicht eine lokale Ausführung ohne Webserver.

57 7 Implementierung von Videobox 57 #!/usr/bin/php -q <?php set_time_limit(0); // don't stop this script after 30s require('include/phpagi.php'); // include php-agi $agi = new AGI(); $agi->answer(); // answer the call $agi->conlog("playing video"); // log to asterisk-cli $agi->exec('mp4play','demo.mp4'); // play video $agi->hangup(); // end call return 0;?> Zusätzlich können alle weiteren Möglichkeiten von PHP CLI genutzt werden. Über die zahlreichen verfügbaren Bibliotheken sind so sehr viele Funktionen möglich. Standardmäßig kann Asterisk RTP Daten mit Videoinformationen lediglich weiterleiten. Zum Abspielen und Aufnehmen kommt das Modul app_mp4 von Sergio García Murillo [FONTVENTA] zum Einsatz. Diese Asterisk Applikation wurde erweitert. So ist es möglich, das Aufnehmen und Abspielen von Videos durch Senden des DTMF Codes '#' zu unterbrechen. Weitere, meist kleinere, Änderungen wurden in die offizielle Version übernommen oder durch Parallelentwicklung des Autors überflüssig gemacht. Zur Generierung der Videos dienen die Grafikbibliothek gd lib sowie die Komandozeilen programme mencoder und ffmpeg aus dem mplayer Projekt [MPLAYER]. Zur Umwandlung bestehender Videos wird noch das Programm pcm2mp4 benötigt, das auf [FONTVENTA] zu finden ist. Eine Sprachausgabe wird mit Hilfe des Sprachsynthesizers festival [FESTIVAL] und des Audiokonvertierungsprogramms sox [SOX] realisiert. Darwin Streamin Server Des Weiteren findet der Darwin Streaming Server von Apple [APPLE] seine Verwendung. Er dient dazu, Videos über RTSP zu übertragen. Es können nicht nur Liveübertragungen gesendet werden, sondern auch Videos auf Nachfrage (VoD) oder mit einem festen Abspielplan, vergleichbar mit einem TV Programm. Für dieses Framework kann der Server jedoch durch jeden vergleichbaren RTSP Server ersetzt werden.

58 7 Implementierung von Videobox Hauptanwendung Die PHP Anwendung lädt nach dem Start die Einstellungen des Nutzers, sucht den Einstiegspunkt in die Anwendung anhand der Rufnummer aus und beantwortet anschließend den Call. Die Anwendung läuft nach dem Abspielen der Willkommensgrüße und sonstigen einmaligen Informationen in einer Endlosschleife. Zum Abspielen des nächsten Inhalts wird die Funktion show_movie() aufgerufen. Diese Funktion holt sich abhängig von dem Videotyp menu, advice oder content weitere Informationen aus der Datenbank. Bei dem Videotyp content wird das entsprechende Modul aufgerufen. Bei den restlichen Auswahlmöglichkeiten wird die Funktion play_movie() aufgerufen. Diese Funktion erzeugt den Videoclip mit Hilfe der Funktion create_movie() und gibt gegebenenfalls einen Tastencode zurück. Die Funktion create_movie() generiert über das Programm mencoder ein Video von dem Bild, das mit create_image() erzeugt wurde. Dieses Video wird mit ffmpeg in das Zielformat umgewandelt bevor es von play_movie() wiedergegeben wird. Je nach Einstellung in der Datei config.php wird die CIF oder QCIF Auflösung verwendet. Des Weiteren kann play_movie() mit Hilfe von create_audio() eine synthetische Sprachausgabe für das Menü oder den Hinweis erzeugen. Auf Wunsch ist es möglich, die Funktion create_movie() durch das Programm create_movie_in_background zu ersetzen. In diesem Fall veranlasst play_movie die Videogenerierung durch create_movie_in_background und spielt während der Generierung eine animierte Aufforderung zum Warten in Form einer Sanduhr ab. Dies ist besonders bei einer höheren Systemlast und einer dadurch verzögerten Generierung zu empfehlen. Das gewünschte Verhalten ist in den Nutzereinstellungen konfigurierbar.

59 7 Implementierung von Videobox 59 Abbildung 21: Ablaufplan von Videobox 7.4 Erzeugung dynamisch generierter Ausgaben Videoausgabe Zur Generierung der Videos wird der Text aus der MySQL Datenbank ausgelesen und mit gd lib auf dem gewünschten Hintergrundbild aufgezeichnet. Das fertige Bild wird daraufhin mit mencoder in ein Video umgewandelt, welches mit dem Konvertierungsprogramm ffmpeg in das Zielformat H.263 gewandelt wird.

60 7 Implementierung von Videobox 60 Abbildung 22: Schritte bis zum Abspielen eines Videos Audioausgabe Auf Wunsch ist es möglich, den Text eines Menüs oder Hinweises vorlesen zu lassen. Ob dies geschehen soll, ist ebenfalls über die Datenbank einstellbar. Durch den verwendeten Sprachsynthesizer kann ein gewöhnliches IVR gestaltet werden, das bei der Verfügbarkeit einer Videoausgabe seitens des Clients seine Optionen zusätzlich grafisch anzeigt. Ansonsten ist der IVR eine reine Sprachanwendung. Somit kann die Grafikausgabe auch als Untertitel für Hörgeschädigte dienen. Abbildung 23: Schritte bis zur Wiedergabe einer Sprachausgabe