Fachhochschule Köln Cologne University of Applied SciencesFachhochschule Köln Cologne University...

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. : 11027686

Referent : Prof. Dr. Andreas Grebe

Korreferent : Prof. Dr. Heiko Knospe

Abgabedatum : 28. Januar 2008

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

Inhaltsverzeichnis 3

Inhaltsverzeichnis

Inhaltsverzeichnis..........................................................................................................3

Abbildungsverzeichnis...................................................................................................6

Vorwort...........................................................................................................................8

1 Einführung..................................................................................................................9

2 All IP-Netze...............................................................................................................11

2.1 Next Generation Access....................................................................................11

2.2 Next Generation Networks................................................................................12

3 IP Multimedia Subsystem.........................................................................................14

3.1 Architektur.........................................................................................................14

3.2 Session Initiation Protocol.................................................................................16

3.3 DIAMETER........................................................................................................18

3.4 Call Session Control Functions.........................................................................18

3.4.1 Proxy-CSCF...............................................................................................183.4.2 Serving-CSCF............................................................................................193.4.3 Interrogating-CSCF....................................................................................19

3.5 Home Subscriber Server...................................................................................20

3.6 Application Server.............................................................................................20

3.6.1 Application Server im IMS..........................................................................223.7 Charging............................................................................................................23

3.8 Quality of Service..............................................................................................24

4 Verfügbare Application Server..................................................................................25

4.1 IBM WebSphere IP Multimedia Subsystem Connector....................................25

4.2 Open Cloud Rhino IMS Application Server.......................................................26

4.3 Ericsson IMS weShare......................................................................................26

4.4 Ericsson IMS Messaging...................................................................................26

4.5 Ericsson IMS Push to Talk................................................................................27

4.6 Ericsson IMS Multimedia Telephony.................................................................27

4.7 Fraunhofer Fokus Open IMS Core....................................................................28

4.8 Bewertung.........................................................................................................28

5 Neue Dienste im IMS................................................................................................30

5.1 Videodienste......................................................................................................30


5.2 Signalisierungsdienste......................................................................................33

6 Vorabüberlegungen..................................................................................................35

6.1 Videoformate.....................................................................................................35

6.1.1 H.263..........................................................................................................366.2 Videoübertragung..............................................................................................38

6.2.1 Übertragungsraten.....................................................................................406.3 Signalisierung....................................................................................................42

6.3.1 SIP-INVITE................................................................................................426.3.2 SIP-INFO...................................................................................................456.3.3 SIP-NOTIFY...............................................................................................456.3.4 SIP-MESSAGE..........................................................................................46

6.4 Anwendungssteuerung......................................................................................47

6.5 Kommunikation über SIP-INFO........................................................................48

7 Implementierung von Videobox................................................................................51

7.1 Architektur.........................................................................................................51

7.1.1 Menüs........................................................................................................537.1.2 Hinweis......................................................................................................537.1.3 Modul.........................................................................................................537.1.4 Navigation..................................................................................................54

7.2 Verwendete Software........................................................................................55

7.2.1 Hauptkomponenten des Clients................................................................557.2.2 Hauptkomponenten des Servers...............................................................56

7.3 Hauptanwendung..............................................................................................58

7.4 Erzeugung dynamisch generierter Ausgaben...................................................59

7.4.1 Videoausgabe............................................................................................597.4.2 Audioausgabe............................................................................................60

7.5 Signalisierung beliebiger Inhalte.......................................................................61

7.5.1 Automatische Signalisierung......................................................................617.5.2 Manuelle Signalisierung.............................................................................61

7.6 Charging............................................................................................................62

7.7 Module...............................................................................................................64

7.7.1 Video..........................................................................................................647.7.2 Hinweis......................................................................................................657.7.3 Rufumleitung..............................................................................................657.7.4 Linkversand................................................................................................65

7.8 Management Interface......................................................................................66

7.9 Integration in das IMS.......................................................................................69


8 Implementierung ausgewählter Dienste...................................................................71

8.1 Anrufbeantworter...............................................................................................72

8.2 Videos...............................................................................................................73

8.3 Spiel..................................................................................................................73

8.4 Externe Inhalte..................................................................................................74

8.5 Travel Agency....................................................................................................75

8.5.1 CCA-Interface............................................................................................759 Auswertung...............................................................................................................77

9.1 Erweiterungen...................................................................................................77

Schlussbetrachtung.....................................................................................................79

Anhang........................................................................................................................80

Abkürzungen...............................................................................................................85

Quellen........................................................................................................................87

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

Abbildungsverzeichnis 7

Abbildung 31: Operator Interface................................................................................76

Vorwort 8

Vorwort

Diese Master Thesis entstand als Beitrag zum Forschungsprojekt QoSSIP (Netzeübergreifende

QualityofService bei SIPbasierter VoIPKommunikation). Das Forschungsprojekt befasst

sich mit Quality of Service (QoS) für zeitkritische Datenströme in IPNetzwerken, 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, RealTime 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.

1 Einführung 9

1 Einführung

In Zeiten, in denen nicht nur über AllIPNetze nachgedacht wird, sondern auch zahlreiche

Dienste wie die Telefonie auf IP umgestellt werden, das TVAngebot durch IPTV erweitert

wird und die Mobilfunknetze IPZugä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 FreeMail 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.

1 Einführung 10

Zusätzliche Funktionen wie ein Videoanrufbeantworter wären wichtig. On-

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

2 All IP-Netze 11

2 All IPNetze

Nachdem Voice over IP (VoIP) in vielen Bereichen das herkömmliche Festnetz abgelöst hat

und die TVAusstrahlung digitalisiert wurde, liegt es nahe, die verschiedenen Medien über ein

einziges Netzwerk zu übertragen.

Die Idee, die hinter einem All IPNetz 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 IPNetzen 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 IPWelt

migrierten Anwendungen zählen neben Telefonnetzen Videoübertragungen in Form von IPTV

und VoD. Beispiele für All IPNetze 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

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.

2.2 Next Generation Networks

Ein Next Generation Network erweitert den Gedanken eines All IPNetzes zu einer

einheitlichen Serviceplattform. Ein NGN ist ein Netzwerk, welches unter anderem folgende

Eigenschaften besitzen soll ([ITUT]):

● IPbasiert

● 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

Abbildung 1: Next Generation Access

2 All IP-Netze 13

Diese Eigenschaften sollen den Nutzern unterschiedlichste IPbasierte Dienste über ein

beliebiges IPbasiertes 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.

Auch bei der Verwendung von Zugängen und Transportnetzen, die nicht im Einflussbereich

des eigenen Service Providers liegen, wird versucht, die gebuchte QoS einzuhalten.

Abbildung 2: Verschiedene Möglichkeiten IP-Dienste zu nutzen

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 2002. 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 UMTSKonkurrenten 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 IMSAnbietern 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


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.

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 IMSLayer

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

Abbildung 3: Die einzelnen Layer des IMS


Ansprechen der darunter liegenden Funktionen. Der Fokus dieser Arbeit liegt auf dem

Application Layer.

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 SIPNetzen lässt jedoch einige Unterschiede deutlich

Abbildung 4: Architektur des IMS [WIKIPEDIA]


werden. Die SIPKommunikation ist wesentlich genauer spezifiziert, was die Kompatibilität

erhöht aber auch Flexibilität einbüßen lässt. Die SIPKommunikation im IMS beinhaltet oft

wesentlich mehr Nachrichten als bei herkömmlichen SIPAnwendungen üblich. Ein

bedeutender Faktor ist die Aushandlung der QoSEigenschaften über den Austausch von

PRACKNachrichten (Provisional Acknoledgment). Einen möglichen Verbindungsaufbau im

IMS zwischen Teilnehmern eines Providers zeigt Abbildung 5.

Durch die stark gestiegene Anzahl an SIPNachrichten ist eine Kompression der SIPPakete

vorgesehen. So sollen durchsatzschwache Verbindungen nicht durch einen großen

SignalisierungsOverhead zusätzlich belastet werden.

Um eine sichere Übertragung der Anmeldeinformationen zu gewährleisten, wird in IMS

Netzen für die Passwortübertragung die MD5Hashfunktion (MessageDigest Algorithm)

genutzt, anstatt der in herkömmlichen SIPNetzen oft genutzten schwächeren SHA1

Hashfunktion (Secure Hash Algorithm).

Abbildung 5: Möglicher SIP-Verbindungsaufbau (frei nach [IMSCS])


3.3 DIAMETER

Ein weiteres wichtiges Protokoll für das IMS ist DIAMETER, die Weiterentwicklung des

RADIUSProtokolls. 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 AAAFunktionalität (Authentifizierung, Autorisierung,

Accounting) an. Die optionale TLSVerschlü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.

3.4.1 ProxyCSCF

Die ProxyCSCF (PCSCF) ist die Kommunikationsstelle zu den Endbenutzern. Alle

Nachrichten der Clients gehen an die PCSCF und die Nachrichten der anderen CSCFs werden

über die PCSCF an die Clients weitergeleitet. Auf Wunsch des Users komprimiert der P

CSCF die SIPNachrichten und sichert sie mit IPsec ab. Des Weiteren kommuniziert der

Proxy mit der Charging Data Function (CDF) und kann über sie Abrechnungsinformationen

bereitstellen. Die PCSCF leitet Nachrichten wie z. B. Registrierungsanfragen und

Vermittlungswünsche an die SCSCF (ServingCSCF) weiter. Bei Nutzern, die Kunden in


einem fremden Netz sind, leitet die PCSCF diese Anfragen an die ICSCF (Interrogating

CSCF) des fremden Anbieters weiter. Die notwendigen Kontaktinformationen über die I

CSCFs erhält der PCSCF über den HSS (Home Subscriber Server). Notrufe werden vom P

CSCF selbstständig erkannt und können ohne Umweg über den SCSCF an den für diesen

Notruf zuständigen CSCF weitergeleitet werden.

3.4.2 ServingCSCF

Die SCSCF kümmert sich um die Registrierung des Users und bezieht die Nutzerdaten und

das passende Diensteprofil vom HSS. Mit Hilfe des Diensteprofils entscheidet der SCSCF

ü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 SCSCF. Über

den HSS wird die Kontaktadresse der gewählten Rufnummer oder URI (Uniform Resource

Identifier) bestimmt und der Verbindungswunsch über die PCSCF an den entsprechenden

Kontakt weitergeleitet. Im Gegensatz zur PCSCF ist die SCSCF in der Lage, dem Online

Charging System (OCS) Abrechnungsinformationen zu liefern.

3.4.3 InterrogatingCSCF

Die ICSCF 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 SCSCF weitergeleitet. Bei einem

Verbindungswunsch zu einem lokalen Application Server wird die Nachricht direkt an diesen

weitergeleitet und die SCSCF somit entlastet. Den Kontakt des Zielsystems bzw. des nächsten

Hops erhält die ICSCF über den HSS.


3.5 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 IMSNetz. Diese Server müssen nicht

direkt im IMSCore 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 SCSFC 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 SIPAnfragen bearbeiten und

beantworten kann. Je nach Dienst muss der Application Server als SIPProxy Pakete

weiterleiten oder als SIPClient Gespräche annehmen. Bei Anwendungen wie Click to Dial,


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 IMSSpezifikation die Weiterverwendung vorhandener Application

Server vor. Hierbei handelt es sich um Server mit den Standards OSASCS (Open Service

AccessService 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.

Um diese Application Server an den SCSCF anbinden zu können, wurden die Umsetzer IM

SSF (IP Multimedia Service Switching Function) und OSASCS (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]

Abbildung 6: Anbindung der Application Server [IMSCS]


3.6.1 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 PresenceDienst 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 MessagingDienst impliziert in der Praxis

immer einen PresenceDienst.

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 ManagementDienst

GroupwareFunktionalitä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 TalkGruppe und sorgt auf Wunsch dafür, dass immer nur ein

Teilnehmer zur selben Zeit sprechen kann.


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 OnlineVerfahren für Prepaid Kunden und das OfflineVerfahren für Kunden,

die im Nachhinein eine Rechnung erhalten. Abgerechnet wird meist nach Zeit. Aber auch das

FlowBasedVerfahren ist möglich. Bei diesem Verfahren können Dienste auf unterschiedliche

Weise abgerechnet werden. Ein FTPDownload kann nach Übertragungsvolumen, eine

Textnachricht nach Zeichenanzahl und ein Telefonat nach Zeit und Entfernung abgerechnet

werden.

Für das OnlineCharging 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 OfflineCharging werden über das Rf

Interface an die Charging Data Function weitergereicht, welche die notwendigen Call Detail

Records (CDR) erstellt.


3.8 Quality of Service

Im derzeitigem IMSStandard 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].

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 IMSUnterstützung bieten.

Diese Produkte sind kommerzielle Entwicklungen oder bestehen aus frei verfügbaren Open

SourceAnwendungen. 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 IMSFunktionen 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 HTTPAnwendungen, die über eine standard

konforme SIPAnbindung und eine DIAMETERSchnittstelle in das IMS angebunden werden

können. Besonders hervorgehoben wird die Möglichkeit PresenceInformationen bereit

zustellen und Group ManagementFunktionen zu ermöglichen. Als Einschränkung bietet der

IMS Connector lediglich eine RfSchnittstelle zum OfflineCharging. Ein Online oder Flow

BasedCharging ist bisher noch nicht vorgesehen. [IBM]


4.2 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 IMSCore bieten, unter anderem ist auch ein RoInterface

für das OnlineCharging enthalten. [RHINO]

4.3 Ericsson IMS weShare

Ericsson bietet eine ganze Reihe an IMSLö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 LiveVideo. Neu im IMSUmfeld 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


sollen unterstützt werden. Für den Nutzer soll ein komplettes Interface mit einer Buddylist

inklusive PresenceInformationen 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 TalkDienst (PTT) basiert auf dem Push to Talk over CellularStandard

(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

PresenceInformationen 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, GroupwareDienste, Presence, Instant

Messaging sowie eine Anbindung an Outlook genannt. [ERICSSON]

5 Open Mobile Alliance, erstellt Spezifikationen für den Mobilfunk


4.7 Fraunhofer Fokus Open IMS Core

Der Open IMS Core von Fraunhofer Fokus ist eigentlich ein CoreSystem 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 IPTVStreaming Server und ein BacktoBack 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 IMSStandard 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.


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.

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.


profitieren, vor allem da Auskunftssysteme über HTML oder WAP für sie oft keine

Alternative darstellen.

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

LiveStream 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 VideoStream 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.

Abbildung 7: Videomenü


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


5.2 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 (RealTime 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 HighQuality

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 IMSClient genutzt wird, der die obigen

Limitierungen nicht aufweist (PC, SetTopBox 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 VoDDienste im Internet

ersetzen und das IPTV in ihr Netz mit einbinden und an ihre Kunden vermarkten. Da lediglich

auf einen RTSPServer verwiesen wird, können bereits vorhandene Infrastrukturen verwendet

werden.


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.

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 .mp4Formats und kann H.263 und MPEG4 Part 2 als Videostream sowie

Audiodaten im Format AACLC aufnehmen. Im Gegensatz zu .mp4 ist auch AMR (Adaptive

MultiRate) als Audiocodec erlaubt. Hier hat die 3GPP zusätzlich zu dem AMRFormat mit

8kHz Samplingfrequenz das Format AMRWB (wideband) 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 i nterlaced = Halbbilder / progressive = Vollbilder


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.264Format gesendet wird, da sich so die Datenrate weiter reduzieren lässt.

6.1.1 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 MPEG4Standard. 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 PFrames (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 BFrames (bidirectional

coded picture) unterstützt [RFC4629].

IFrames

IFrames 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 RTPPakete wird die Darstellung bei Verlust

eines oder mehrerer Pakete jedoch gestört.

Bei Videoübertragungen ist das erste Bild immer ein IFrame. Abbildung 9 zeigt einen

typischen Beginn einer Videoübertragung. Als Erstes wird ein Vollbild mit Hilfe von drei

RTPPaketen übertragen, anschließend folgen mehrere Teilbilder.


PFrames

Predictive coded pictures enthalten eine Referenz auf das vorhergehende Bild. Lediglich

Änderungen gegenüber dem vorangegangenen Bild werden übertragen. Durch PFrames wird

die benötigte Bandbreite stark reduziert. Zur Vermeidung von größeren Wiedergabestörungen

müssen jedoch regelmäßig IFrames gesendet werden, denn wenn das vorhergegangene Bild

fehlerhaft ist, wird es das Folgende ebenfalls sein.

Abbildung 10: Originalbilder und komprimiertes Video (vereinfacht)

Abbildung 9: Der Beginn eines Videos


BFrames

Modernere Videocodecs, wie auch H.263+ bieten die Möglichkeit der BFrames 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 NATRouter erst nach dem

Versenden eines RTPPaketes 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.


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 SIPINFONachricht soll der

Videoencoder des Telefons angesprochen werden. Der Payload im XMLFormat der folgenden

Nachricht weist ein neues Vollbild an:

Session Initiation Protocol

Request-Line: INFO sip:300@*.*.16.71:5060 SIP/2.0

Message Header

Via: SIP/2.0/UDP *.*.16.72:5060;branch=z9hG4bK41324350;rport

From: "2000" <sip:300@*.*.16.72>;tag=as472b763b

To: <sip:300@*.*.16.71>;tag=1404114038

Contact: <sip:300@*.*.16.72>

Call-ID: 2032668576@*.*.16.71

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"?>

Abbildung 11: Diese Aufnahme beginnt mit einem P-Frame


<media_control>

<vc_primitive>

<to_encoder>

<picture_fast_update>

</picture_fast_update>

</to_encoder>

</vc_primitive>

</media_control>

6.2.1 Ü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 QCIFAuflösung

übertragen wurden. Die hier verwendeten Messvideos wurden mit dem Programm ffmpeg

erzeugt, welches eine möglichst starke Komprimierung vornehmen sollte.

CIF (352x288) QCIF (176x144)

Menü 30kByte/Menü 100kByte/s 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 IFrames 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.


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

Abbildung 13: Verlauf der Videoübertragungsrate während einer IVR-Sitzung


6.3 Signalisierung

Der zu erstellende Application Server soll Inhalte an den Client signalisieren, die bisher im

SIPStandard 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.

6.3.1 SIPINVITE

Bei einem herkömmlichen SIPGespräch werden die Informationen zur Übertragung der

Audio und Videodaten über RTP im SDPHeader (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 INVITENachricht, dem sogenannten ReInvite, die Parameter der Verbindung zu

ändern.

Abbildung 14: Re-Invite zu Beginn des Gesprächs


Eine Signalisierung über eine INVITENachricht kann auf eine der folgenden Weisen

geschehen.

Gleiche CallID

Unter Beibehaltung der CallID wird mit einer neuen Nachricht das wiederzugebende

Medium (Datenstrom) geändert. So kann ein VoiceCall 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.

Neue CallID

Bei der Verwendung einer neuen CallID 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

Abbildung 15: Unterbrechung eines Gesprächs für

eine Videoübertragung


Verbindungswunsch an einen anderen Teilnehmer der gleichen RingGroup8 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.

Bei einem INVITE geht man von einer komplett SIPgesteuerten 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 ReInvite.

8 In einer Ring-Group läuten mehrere Telefone bei einem Anruf an eine bestimmte Nummer.

Abbildung 16: Übertragung eines Videos parallel

zu einem Gespräch


6.3.2 SIPINFO

Eine weitere Möglichkeit ist die Signalisierung über SIPINFONachrichten. 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 INFONachrichten muss ein Nachrichtenformat definiert werden,

das entsprechende Verweise aufnehmen kann. Da bereits DTMFTöne über INFO gesendet

werden können, ist der ursprüngliche Verwendungszweck dieses Nachrichtentyps passend.

Eine mögliche Implementierung mit INFONachrichten wird weiter unten in diesem Kapitel

vorgestellt.

6.3.3 SIPNOTIFY

Die SIPNOTIFYNachrichten 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

NOTIFYNachrichten vom Client abonniert werden, sie werden erst nach einer Beauftragung

durch eine SUBSCRIBENachricht versendet. Eine Verwendung für den Application Server

wäre somit weit weg von der eigentlichen Nutzung.


6.3.4 SIPMESSAGE

Die MESSAGENachrichten 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 CallID 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. http://) 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 SIPMESSAGENachrichten 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 SIPNetz möglich. Eine Erweiterung der

zwischenliegenden SIPKomponenten ist nicht notwendig, da auch strengere SIPProxys diese

Nachrichten weiterleiten. Da dieselbe CallID verwendet werden kann, ist auch die Zuordnung

eindeutig.


6.4 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.

1209 Hz 1336 Hz 1477 Hz 1633 Hz

697 Hz 1 2 3 A

770 Hz 4 5 6 B

852 Hz 7 8 9 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 SIPTelefonen gibt es drei verschiedene Möglichkeiten, DTMF

Signale zu übermitteln. Entweder der Tastendruck wird über eine SIPINFONachricht 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 RTPPayload versendet (inbound). Die letzte Möglichkeit ist zum

PSTN kompatibel, wobei bei den anderen Verfahren das MediaGateway lediglich eine

Übersetzung durchführen muss. Die Steuerung über DTMF verlangt von zwischenliegenden


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 SIPMESSAGENachricht 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, SIPINFONachrichten zur

Steuerung zu nutzen. Hier ist es jedoch notwendig, wie bei der Signalisierung, einen neuen

PayloadTyp für diese Nachricht zu definieren.

6.5 Kommunikation über SIPINFO

Bei einer Einbindung neuer Steuermöglichkeiten in das IMS während der derzeit noch

andauernden Spezifizierungsphase ist eine Implementierung der Kommunikation mit Hilfe

von SIPINFONachrichten möglich und sinnvoll.

Die erweiterte Funktionalität der SIPInfoNachrichten 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 XMLNachricht

erfolgen:


Content-Type: application/session_navigation+xml


<session_navigation>

<nav_primitive>

<to_application>

<button_pressed>

3

</button_pressed>

</to_application>

</nav_primitive>

</session_navigation>

Der ContentType signalisiert dem Empfänger, dass eine SessionSteuerung im XMLFormat

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


<content_control>

<link_primitive>

<to_application>

<show_URL>

http://www.qossip.de

</show_URL>


</to_application>

</link_primitive>

</content_control>

Eine URL soll an die entsprechende Anwendung des Clients weitergeleitet werden. Dazu wird

im ContentType 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 http://www.qossip.de verweist. Ein Link auf einen

VoDDienst kann über das Tag show_VIDEO erfolgen:

<show_VIDEO>

rtsp://video.foo.bar

</show_VIDEO>

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.


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.

Ü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

Abbildung 18: Struktur der Datenbank (vereinfacht)

Abbildung 19: Adressierung über die Rufnummer


einen übergeordneten Kontext zusammenfügen und der Kunde hat weiterhin die Möglichkeit,

bestimmte Anwendungen über eine vorgegebene Rufnummer direkt zu erreichen.

7.1.1 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.

7.1.2 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.

7.1.3 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


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.

7.1.4 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


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.

7.2.1 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 3GPTelefon kann nicht verwendet werden, da Erweiterungen auf diesen

Systemen nicht ohne Weiteres möglich sind.

Linphone erhielt einen einfachen Patch, welcher eintreffende SIPMESSAGENachrichten

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 DTMFTönen über SIP und RTP ist

in der verwendeten Version 1.7.1 von Linphone bereits enthalten.

Weitere Anforderungen an das Client Equipment sind ein Webbrowser und ein RTSPfä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


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.

7.2.2 Hauptkomponenten des Servers

Asterisk

Als Basis für den Application Server wurde die SoftwarePBX (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 PHPAGI gewählt, um

Funktionen für das PHPCLI9Skript und für ein PHPWebinterface nutzen zu können. Das

PHPScript 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 PHPAnwendung

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.


#!/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 PHPCLI genutzt werden. Über die

zahlreichen verfügbaren Bibliotheken sind so sehr viele Funktionen möglich.

Standardmäßig kann Asterisk RTPDaten mit Videoinformationen lediglich weiterleiten. Zum

Abspielen und Aufnehmen kommt das Modul app_mp4 von Sergio García Murillo

[FONTVENTA] zum Einsatz. Diese AsteriskApplikation wurde erweitert. So ist es möglich,

das Aufnehmen und Abspielen von Videos durch Senden des DTMFCodes '#' 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 gdlib sowie die Komandozeilen

programme mencoder und ffmpeg aus dem mplayerProjekt [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 TVProgramm. Für dieses Framework kann der Server

jedoch durch jeden vergleichbaren RTSPServer ersetzt werden.


7.3 Hauptanwendung

Die PHPAnwendung 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 QCIFAuflö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.


7.4 Erzeugung dynamisch generierter Ausgaben

7.4.1 Videoausgabe

Zur Generierung der Videos wird der Text aus der MySQLDatenbank ausgelesen und mit

gdlib 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.

Abbildung 21: Ablaufplan von Videobox


7.4.2 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 22: Schritte bis zum Abspielen eines Videos

Abbildung 23: Schritte bis zur Wiedergabe einer

Sprachausgabe


7.5 Signalisierung beliebiger Inhalte

7.5.1 Automatische Signalisierung

Über die Funktion sendText() des Asterisk kann ein beliebiger String wie eine URL über eine

SIPMESSAGENachricht versendet werden. Die CallID entspricht der des Telefongesprächs,

wodurch eine eindeutige Zuordnung gewährleistet werden kann. Soll die Anwendung einen

Link zur Webseite www.qossip.de versenden, geschieht dies durch folgenden Aufruf im Ruf

nummernplan:

sendText('http://www.qossip.de')

Die AsteriskAnwendung sendURL() kann Links an Telefone übermitteln, die ein Protokoll

nutzen, in dem diese Art der Signalisierung bereits vorgesehen ist. Im Gegensatz zu dem

VoIPProtokoll Inter Asterisk Exchange (IAX) unterstützt SIP diese Signalisierung nicht,

weswegen diese Funktion leider nicht verwendet werden kann.

7.5.2 Manuelle Signalisierung

Für Operatoren und Call Center Agents (CCA) sollen Anwendungen möglich sein, die die

Übermittlung der zusätzlichen Informationen zum Anrufer ausführen lassen. So kann der Call

Center Agent während eines Beratungsgesprächs ergänzende Informationen in Form von

Multimediadateien oder Webseiten an den Kunden übermitteln, was bisher nur durch den

vollautomatischen IVR möglich ist.

Um diesen neuen Dienst zu ermöglichen, muss eine Schnittstelle geschaffen werden, die den

Versand der Nachrichten über eine externe Anwendung, wie z. B. ein webbasiertes Operator

Interface oder ein CRM (Customer Relationship Management), ermöglicht. Die Initiierung


der Nachricht kann durch den Application Server, einer zwischengeschalteten PBX oder durch

den Client erfolgen. Wichtig ist hier nur eine sinnvolle Verknüpfung mit einem eventuell

vorhandenen CRM. Da es bei Asterisk nur mit viel Aufwand möglich ist, eine Nachricht durch

ein Modul versenden zu lassen, das nicht im Kontext des Telefongesprächs läuft, wurde das

Hilfsprogramm sendtext entwickelt. Dieses Programm benötigt die Angabe der SIPURI des

Zielsystems sowie die IP des vermeintlichen Absenders und die eigentliche Nachricht.

achim@lyon:/var/videoapplications/resources/bin$ ./sendtext

usage ./sendtext hostname port user realm message

Die originale CallID wird in diesem Fall nicht verwendet, da sonst die folgenden

Sequenznummern im Application Server abgeändert werden müssen. Aus diesen Gründen ist

dieses Programm als reiner Prototyp zu verstehen. Eine echte Einbindung dieser Funktion in

Asterisk wird ausdrücklich empfohlen.

7.6 Charging

Um die verschiedenen Abrechnungsmodelle des IMS unterstützen zu können, müssen

zusätzliche Informationen an das ChargingModul des Application Server übergeben werden

können. So sollen neben dem Start und Endzeitpunkt noch inhaltsabhängige Informationen

versendet werden können.

Für das Charging wird ein parallel im QoSSIPProjekt entwickeltes DIAMTERModul

verwendet. Aus der Datenbank wird für jedes Menü und jedes Modul ausgelesen, ob und

welche Events an das DIAMETERModul gesendet werden sollen. Mit Hilfe dieser

Informationen ist die Charging Trigger Function (CTF) des Moduls in der Lage, Offline und

FlowBasedCharging zu ermöglichen.


Es können Events zu Beginn und Ende der Wiedergabe eines Moduls gesendet werden oder

nur einmalig. Die Initiierung von regelmäßigen Events oder des Gesprächsendes bei einem

Programmabbruch, etwa durch auflegen, wird von dem Chargingmodul durchgeführt.

Innerhalb des Rufnummernplans wird das Charging über die Anwendung

sendChargingEvent() gesteuert, welche die Events an das Chargingmodul weiterleitet. Der

folgende Aufruf teilt den Beginn eines einfachen Videos, wie einer Nachricht auf dem

Anrufbeantworter, mit.

Abbildung 24: Flow-based Charging in Videobox


sendChargingEvent('START','Video','LQ');

Auf diese Weise kann der Beginn oder das Ende der Sitzung oder eines Teilabschnittes

abstrakt an das Chargingmodul übermittelt werden. Genauere Informationen zur Abrechnung

werden dann von der CTF erzeugt.

7.7 Module

Das Framework beinhaltet bereits einige Module, die Standardfunktionen enthalten. In vielen

Fällen reichen die Standardfunktionen zur Realisierung des gewünschten IVRs bereits aus.

Ansonsten können auch selbst erstellte Module diese Funktionen einbinden, was die

Entwicklung vereinfacht.

Für alle Standardfunktionen gilt, dass sie Abrechnungsinformationen an die CTF versenden

können. Die einzelnen Modultypen werden über Angabe des Namens ausgewählt. Über die

Angabe der Optionen werden die individuellen Konfigurationen des Moduls angegeben

7.7.1 Video

Eine sehr wichtige Funktion für Videobox ist das Modul video. Dieses Programm ermöglicht

das einfache Abspielen eines Videos. Mit einem vorangestellten Hinweis können bereits viele

Anwendungsszenarien abgedeckt werden. Als Option wird dem Modul der Pfad zu der

abzuspielenden MP4Datei angegeben.


7.7.2 Hinweis

Möchte man nach der Wahl eines Menüpunktes lediglich einen Hinweis anzeigen, eignet sich

dazu das Modul advice. Dieses Programm empfiehlt sich auch zum Abspielen einfacher

Meldungen, aufgerufen aus anderen Modulen. Als Option muss lediglich die ID des

gewünschten Hinweises angegeben werden.

7.7.3 Rufumleitung

Um den Anrufer mit einem Teilnehmer oder einer anderen Applikation zu verbinden, kann das

Modul dial genutzt werden. Dieses Modul ruft die in den Optionen angegebene Nummer an.

Über die Angabe des gewünschten Channels des Asterisk können alle von Asterisk

unterstützten Telefonsysteme angerufen werden. Ein Anruf an das SIPTelefon mit der

Nummer 302 erfolgt über die Option "SIP/302|20". Nach Beenden des Telefonats durch den

anderen Gesprächspartner oder nach Erreichen des Timeouts nach 20 Sekunden Klingeln wird

der Teilnehmer wieder an Videobox zurückgereicht.

7.7.4 Linkversand

Über das Modul sendlink können beliebige URLs an den Client versendet werden. Über die

Angabe http://www.qossip.de öffnet der Client die Webseite der Forschungsgruppe QoSSIP,

über rtsp://video.foo.bar/video.mp4 einen Videostream. Es ist ebenfalls möglich, einen

beliebigen Text an den Teilnehmer zu senden, die Angabe eines Protokolls ist in der Option

nicht zwingend nötig.


7.8 Management Interface

Da die Informationen zu einer Anwendung hauptsächlich in einer Datenbank gespeichert

werden, liegt es nahe, ein ManagementInterface für den Administrator der Anwendung zu

implementieren, welches die komfortable Erstellung von Strukturen mit Menüs, Hinweisen

und den Grundanwendungen ermöglicht. Dieses Interface wurde mit Hilfe von PHP und

HTML erstellt. So können Funktionen wie create_image() problemlos wiederverwendet und

für die Webseite genutzt werden.

Über die Strukturansicht des Management Interface ist es möglich, durch die komplette

Menüstruktur zu navigieren, neue Menüpunkte anzulegen sowie alte zu löschen. Im

Editiermodus für die Menüs lassen sich die Überschriften einstellen, der direkte Zugriff über

Abbildung 25: Management Interface von Videobox - Strukturansicht


die Rufnummer freigeben, das Abspielen bei nur einem Unterpunkt erzwingen, das

Hintergrundbild auswählen und die Sprachausgabe aktivieren.

Über die Verwaltung der Hinweise können Texte eingegeben werden, die eine voreingestellte

Zeit lang abgespielt werden. Wenn Tastendrücke erlaubt sind, da z. B. ein Modul diesen

Hinweis für eine Abfrage verwenden möchte, können diese ebenfalls definiert werden. Wie im

Menü können das Hintergrundbild ausgewählt und die Sprachausgabe aktiviert werden. Die

Hinweise können wahlweise vier oder fünf Zeilen lang sein, damit eine zentrierte Darstellung

aller Nachrichten möglich ist.

Abbildung 26: Management Interface von Videobox - Menüansicht


Die Konfigurationsseite für die Module ermöglicht das Setzen der einheitlichen Einstellungen.

Auf Wunsch kann man über die Angabe der ID eines Hinweises diesen vor Aufruf eines

Programmes abspielen lassen. So kann vor dem Modul video beispielsweise ein Hinweis zum

Abbruch des Videos angezeigt werden. Die Angabe zu den Optionen hängt von dem

verwendeten Programmtyp ab. Das Modul video benötigt hier den Namen des abzuspielenden

Videos.

Wenn das gewählte Modul kein individuelles Abrechnungsmodell benötigt, kann eine der

vordefinierten Abrechnungsmodelle verwendet werden. Die Variante unique sendet zu Beginn

eine einmalige Nachricht an die CTF, die Variante startstop jeweils eine zu Beginn und Ende

des Moduls. Über den Abrechnungstyp und die Optionen können die für die CTF benötigten

weiteren Information angegeben werden.

Abbildung 27: Management Interface von Videobox - Hinweisansicht


7.9 Integration in das IMS

Da der entwickelte Application Server als Dienst für das IP Multimedia Subsystem gedacht

ist, soll die Funktion dieses Servers innerhalb eines IMS überprüft werden. Hierzu wurde der

Fraunhofer Fokus Open IMS Core in der SubversionRevision 444 verwendet. Dieser IMS

Core hat bereits einige Application Server integriert, dessen Beispielkonfigurationen für

Videobox übernommen werden können. Leider ist die Art der Anbindung der Application

Server unglücklich gewählt. Anstatt den Diensten Rufnummern oder Namen zuweisen zu

können, wird für die Adressierung eine komplette URI in Form von sip:dienst@application

server als Zieladresse benötigt. Um fremde Domains adressieren zu können, ohne dass der

IMS Core umgangen wird, muss bei Linphone der IMS Core als Outboundproxy angegeben

werden. Videobox kann dann über die URI sip:[email protected]koeln.de

angewählt werden, anstatt über die eigene Domain imscore.dn.fhkoeln.de. Der folgende

Ausschnitt der Konfigurationsdatei ~/.gnome2/linphone zeigt die notwendigen Einträge zur

Zusammenarbeit mit dem IMS Core.

Abbildung 28: Management Interface von Videobox - Modulansicht


[proxy_0]

reg_proxy=sip:imscore.dn.fh-koeln.de

reg_identity=<sip:[email protected]>

reg_expires=900

reg_sendregister=1

publish=0

reg_route=<sip:imscore.dn.fh-koeln.de>

8 Implementierung ausgewählter Dienste 71

8 Implementierung ausgewählter Dienste

Um die Leitungsfähigkeit und Flexibilität des Frameworks Videobox aufzuzeigen, wurde eine

Beispielanwendung erstellt.

Die gleichnamige Anwendung beinhaltet mehrere Dienste, die unter einer Anwendung

zusammengefasst werden. Diese Anwendung soll auf einem IVR basieren, das um einige

Funktionen erweitert wurde. Hierzu wurden einige individuelle Funktionen in den IVR

eingebaut, die hauptsächlich aus neuen Modulen bestehen. Lediglich die sequenzielle

Abarbeitung einiger Anzeigen am Anfang der Anwendung mussten manuell eingefügt werden.

Zu Beginn der Anwendung werden die Nutzerdaten aus der Datenbank geladen und temporär

gespeichert. Dieser Weg dient dazu, dass man diese Funktion durch eine einmalige Abfrage

des HSS ersetzen kann, sobald ein solches Modul für den Asterisk verfügbar ist. Nach dem

Beantworten des Anrufes wird der Anrufer persönlich begrüßt. Dies geschieht durch das

Senden von zwei kurzen Videos um einen eventuellen Verlust des ersten IFrames zu

kompensieren. Nach dem Abspielen einer kurzen Werbebotschaft und der Meldung über die

Anzahlt der neuen Nachrichten in der Videomailbox steht dem Nutzer das Hauptmenü zur

Verfügung. Hier kann sich der Nutzer für eine Unterkategorie entscheiden.

Abbildung 29: Das Hauptmenü von Videobox


8.1 Anrufbeantworter

Über eine AGIAnwendung wird ein Anrufbeantworter mit Videofunktion realisiert. Dieser

Anrufbeantworter speichert die Aufnahmen und schreibt die Telefonnummer des Anrufers,

Datum, Uhrzeit und den Dateinamen in die Datenbank.

Über das Modul videomail können diese Nachrichten dann abgerufen werden. Nach der

Anzeige der Anrufdaten wie Rufnummer und Datum werden die Nachrichten abgespielt und

in der Datenbank als bereits abgerufen markiert.

<?php

function videomail()

{

// Abfrage der Datenbank und laden der notwendigen Umgebungsvariablen

[...]

// Anzeige der Anzahl neuer Nachrichten

$button=play_movie(3,'advice?NUM='.mysql_num_rows($result),'','3');

while($row = mysql_fetch_array($result))

{

// Anzeige der Informationen zu einer Nachricht

$dtmf=play_movie(8,'advice?CALLER='.$row['caller'].'?DATE1='.date("d.m.Y",$row['time']).'?DATE2='.date("H:i",$row['time']),'','3');

// Anzeige der Nachricht

$agi->exec('mp4play',mail.$callerid.'/incomming/'.RESOLUTION.'-videomail-'.$row['message_id'].'.mp4');

$time=$row['time'];

}

// Alle Nachrichten als gelesen markieren

[...]

}

?>

In dem oben zu sehenden Ausschnitt des Skripts kann man erkennen, dass individuelle

Hinweise einfach über play_movie() abgespielt werden können sowie bereits passend

vorliegende Videos über $agi>exec().


8.2 Videos

Zur Unterhaltung wurden weitere Module in die Anwendung Videobox eingebunden. Über ein

externes Skript10 werden stündlich die fünf beliebtesten Videos von Youtube heruntergeladen

und in das .mp4Format konvertiert.

Über Module, die nur aus der Grundfunktionalität von Videobox bestehen und keine

Erweiterung benötigen, können diese Videos angesehen werden. Diese Module lassen sich

durch Auswahl der Sektion Youtube in der Kategorie Fun abrufen.

8.3 Spiel

Als weiteres Unterhaltungsprogramm wurde das einfache Frage und AntwortSpiel questions

game entwickelt und in die Kategorie Fun eingebunden. Dieses Spiel zeigt dem Spieler

nacheinander fünf Fragen in verschiedenen Schwierigkeitsstufen an, bei denen eine von drei

möglichen Antworten gewählt werden muss. Ist die Antwort richtig, wird die nächste Frage

gestellt, ist sie falsch, darf es der Spieler noch einmal versuchen, bis er die richtige Antwort

ausgewählt hat. Die Anzahl der benötigten Versuche bestimmt das Ergebnis, welches am Ende

in Punkten angegeben wird. Die Fragen werden, nach Schwierigkeitsgrad sortiert, in der

Datenbank gespeichert und können auf diese Weise einfach um neue Fragen ergänzt werden.

10 Skript siehe Anhang Seite 82


8.4 Externe Inhalte

Ohne direkten Bezug zu den anderen Inhalten von Videobox ist es möglich, Webseiten über

den Browser anzeigen zu lassen oder ein hochauflösendes Video über einen Mediaplayer

abzuspielen. Da dies zur Grundfunktionalität gehört, sind hierfür einfache Einträge in der

Datenbank ausreichend. Das entsprechende Untermenü findet sich im Bereich examples.

Abbildung 30: Minigame auf dem Videotelefon


8.5 Travel Agency

Zur Demonstration der Fähigkeiten von Videobox für eine ServiceHotline wurde der Verweis

auf eine Servicehotline eingebunden. Der unter shop zu findende Menüpunkt stellt den

Anrufer zu einem Servicetelefon durch.

8.5.1 CCAInterface

Für diese Servicehotline wurde ein Interface für einen Call Center Agent eines Reisebüros

oder Reiseunternehmers erstellt. Dieses Interface basiert ebenfalls auf PHP und HTML und

wurde mit Hilfe von Javascript zu einer AjaxAnwendung erweitert.

Die Webseite zeigt dem Call Center Agent nach der Annahme eines Anrufes die verfügbaren

Informationen über den Anrufer an. Zeitgleich ermöglicht diese Webseite, dem Anrufer Links

zu Seiten des firmeneigenen Webservers oder zu Videos über die verfügbaren Reiseziele zu

senden. Hierzu bekommt der CCA alle wichtigen Verweise auf die Firmenwebseite zu einem

ausgewählten Objekt angezeigt. Einen Ausschnitt des Interfaces zeigt Abbildung 31.


Abbildung 31: Operator Interface

9 Auswertung 77

9 Auswertung

Nach einigen intensiven Tests des Frameworks zeigt sich, dass dieses einfach erweiterbar ist

und zuverlässig funktioniert. Bei der Verwendung eines Videotelefons erleichtert die Anzeige

der Auswahlmenüs die Navigation erheblich. Für ältere oder beeinträchtigte Menschen kann

dies eine große Vereinfachung sein. Auch für den durchschnittlichen Nutzer ist ein Navigieren

schneller möglich als bisher, da alle Optionen auf einem Blick eingesehen werden können und

das Aufsagen aller Menüpunkte nicht abgewartet werden muss. Auch die Möglichkeit, Videos

abzuspielen, hebt den Unterhaltungswert einer solchen Anwendung an. Das erdachte Konzept

eines IVRs mit Videounterstützung geht somit auf.

Über den Verweis auf Webseiten und andere Dienste ist es Hotlines möglich, den Anrufern

auf einfachste Weise URLs zukommen zu lassen. Ein fehlerträchtiges Diktieren der Adresse

kann entfallen. Auch die Integration von IPTV und VoD ist einfach möglich.

Durch die Beachtung der Bedürfnisse der Videotelefonie sind Wiedergabestörungen selten.

Lediglich bei der Aufnahme von Videos kann es zu Störungen kommen, wenn die

Synchronisation zu einem Vollbild bei Beginn der Aufnahme verpasst wird. Die benötigte

Übertragungskapazität ist gering genug, damit aktuelle Internetanschlüsse diese Datenmengen

problemlos bewältigen können.

9.1 Erweiterungen

Nach der Implementierung der Grundfunktionalität des Frameworks sind zahlreiche

Erweiterungen denkbar. Um unnötige Datenübertragungen zu sparen, sollte eine Abfrage zu

Beginn der Anwendung überprüfen, ob der Client überhaupt Videos darstellen kann. Ist dies

nicht der Fall, kann auf die Videogenerierung und Übertragung verzichtet werden. Wenn die

Sprachsynthese wahlweise durch aufgenommene Sprachdateien ersetzt werden kann, ist eine

9 Auswertung 78

wesentlich bessere Sprachqualität möglich. Auch der Text kann in diesem Fall völlig frei

gewählt werden. Generell empfiehlt es sich, generierte Video und Audiodateien zwischen

zuspeichern, um eine wiederholte Generierung eines identischen Inhaltes zu vermeiden.

Als weitere Ergänzung ist ein Modul für den Asterisk zu empfehlen, welches eine SIP

MESSAGENachricht an einen beliebigen Channel verschicken kann. Somit ist eine korrekte

Signalisierung aus dem CCAInterface möglich.

Über eine Anbindung an den HSS fällt die doppelte Nutzerverwaltung weg. Für einen

produktiven Einsatz ist dies unverzichtbar. Ebenso ist das von Videobox unterstütze

Chargingmodul nicht OnlineCharging fähig. Hier müssen Videobox und das Modul um eine

Überprüfung erweitert werden, die bei einem nicht mehr ausreichenden Guthaben, die

Nutzung der Anwendung verweigert.

Schlussbetrachtung 79

Schlussbetrachtung

Über die Implementierung einer universellen Videoanwendung als Application Server ist es

möglich, viele neue Dienste anbieten zu können. Zusammen mit der Signalisierung beliebiger

Inhalte sind fast unbegrenzte Möglichkeiten für neue Anwendungen gegeben. Durch diese

Neuerung ist es möglich, seinen Kunden Anwendungen anzubieten, die die Konkurrenz nicht

hat und über kostenpflichtige Premiumdienste neue Geschäftsfelder aufzubauen.

Dennoch ist zu beachten, dass das hier vorgestellte Framework nur eine kleine Auswahl der

denkbaren Dienste ermöglichen kann. Diese Beispielapplikationen sollen nur einen Anreiz für

mögliche neue Dienste bieten und zeigen, wie man das Medium Video in Anwendungen

einbinden kann und was die Signalisierung von weiteren Inhalten an Möglichkeiten bietet.

Anhang 80

Anhang

Aufruf von Videobox in der extensions.conf von Asterisk

; Videobox

exten => _2XXX,1,AGI(/var/videoapplications/php/main.php|${CALLERID(num)}|${EXTEN}|${CHANNEL})

Skript11 zum Erstellen eines Videos aus Einzelbildern

#!/bin/sh

# Aufruf über: makemovie.sh Name Auflösung

# wobei Name der Zielname des Videos ist (z. B. video.mp4)

# und die Auflösung cif oder qcif lauten sollte.

filename=$1

# Die Dateien müssen chronologisch als anfang.png bis ende.png vorliegen.

fmt=png

tmp_video=$filename".avi"

new_video=$2"-"$filename".mp4"

echo Creating $new_video

obr=`expr 320 \* 240 \* 50 \* 25 / 256`

opt="vbitrate=$obr:mbd=2:keyint=132:vqblur=1.0:cmp=2:subcmp=2:dia=2:mv0:last_pred=3"

codec="msmpeg4v2"

# Erstelle Video

mencoder -ovc lavc -lavcopts vcodec=$codec:vpass=1:$opt -mf type=$fmt:w=320:h=240:fps=25 -nosound -o /dev/null mf://$filename\*.$fmt

mencoder -ovc lavc -lavcopts vcodec=$codec:vpass=2:$opt -mf type=$fmt:w=320:h=240:fps=25 -nosound -o $tmp_video mf://$filename\*.$fmt

# Räume auf

rm -f divx2pass.log

11 basierend auf einem Skript von: http://forum.ubuntuusers.de/topic/26215/?highlight=

Anhang 81

# Konvertiere Video

ffmpeg -i $tmp_video -an -vcodec h263 -r 10 -s $2 -b 40k -g 50 $new_video

# Erstelle Hinttrack

/usr/local/bin/mp4creator -hint=1 $new_video

# Zeige Videooptionen an

/usr/local/bin/mp4info $new_video

echo "Video erstellt!"

Skript zum Konvertieren eines beliebigen Videos in das MP4Format

#!/bin/sh

# Aufruf über: convert.sv Source Destination Auflösung

# wobei Source das Originalvideo ist (z. B. video.avi),

# Destination der Zielname des Videos ist (z. B. video.mp4)

# und die Auflösung cif oder qcif lauten sollte.

# Konvertiere Video

ffmpeg -i $1 -an -vcodec h263 -r 10 -s $3 -b 40k -g 50 tmp-video.mp4

# Erstelle Hinttrack

/usr/local/bin/mp4creator -hint=1 tmp-video.mp4

# Extrahiere Video

/usr/local/bin/mp4creator -extract=1 tmp-video.mp4

# Extrahiere Audio

ffmpeg -i $1 -vn -acodec pcm_mulaw -ar 8000 -ac 1 -f mulaw tmp.mulaw

# Konvertiere Audio in 3gp

/var/videoapplications/resources/bin/pcm2mp4 tmp.mulaw tmp.3gp

# Benenne Video um

mv tmp-video.mp4.t1 tmp-video.263

# Füge Streams zusammen

/usr/local/bin/mp4creator -create=tmp-video.263 tmp.3gp

/usr/local/bin/mp4creator -hint=3 tmp.3gp

mv tmp.3gp $2

Anhang 82

# Lösche temporäre Dateien

rm tmp-video.* tmp.3gp audiodump.wav tmp.mulaw

# Zeige Videooptionen an

/usr/local/bin/mp4info $2

Laden und Konvertieren der beliebtesten Videos von Youtube

#!/usr/bin/php -q

<?php

// Configuration:

require('../../php/include/config.php');

// MySQL

require('../../php/include/db.php');

set_time_limit(0);

if($argv[1]=="daily")

{

shell_exec ('rm '.video.'cif-youtube_*.mp4');

shell_exec ('rm '.video.'qcif-youtube_*.mp4');

shell_exec ('rm '.tmp.'*.flv');

}

shell_exec ('rm '.tmp.'members?*');

shell_exec ("cd ".tmp." 2>&1;

wget 'www.youtube.com/members?s=mv&t=t&g=2' 2>&1");

$fp = fopen(tmp.'members?s=mv&t=t&g=2','r');

flock($fp,2) or die('Datei kann nicht geöffnet werden');

$file = fread($fp,100000);

// Extrahieren der benötigten Zeilen:

$tmpline=strstr($file,'<div class="memberBoxList">

<div class="user-thumb-large">');

$array['Video1']['line']

=substr($tmpline,24,strpos($tmpline,'</div>')-24);

$tmpline=strstr(substr($tmpline,24,100000),'<div class="memberBoxList">






Anhang 83











$i=1;

foreach ($array as $key => $values)

{

$array[$key]['file']

=substr(strstr($array[$key]['line'],'"'),

strpos($array[$key]['line'],

'<img src="http://i.ytimg.com/vi/')+31,11);

$tmp1=strpos($array[$key]['line'],'"><img');

$tmp2=strpos($array[$key]['line'],'<a href="/')+10;

$tmp3=$tmp1-$tmp2;

$array[$key]['name']=substr($array[$key]['line'],$tmp2,$tmp3);

$array[$key]['videofile']=$array[$key]['file'];

if(!file_exists(tmp."".$array[$key]['videofile'].".flv"))

{

shell_exec ("cd ".tmp.";

".bin."youtube-dl ".$array[$key]['file'].' 2>&1');

shell_exec ("cd ".tmp.";

".bin."convert.sh ".$array[$key]['videofile'].".flv youtube_".$array[$key]['videofile'].".mp4 cif 2>&1; mv youtube_".$array[$key]['videofile'].".mp4 ".video.'/cif-youtube_'.$array[$key]['videofile'].'.mp4 2>&1');

shell_exec ("cd ".tmp."; ".bin."convert.sh ".$array[$key]['videofile'].".flv youtube_".$array[$key]['videofile'].".mp4 qcif 2>&1; mv youtube_".$array[$key]['videofile'].".mp4 ".video.'/qcif-youtube_'.$array[$key]['videofile'].'.mp4 2>&1');

}

$array[$key]['name']=strtr($array[$key]['name'],"'"," ");

$array[$key]['name']=strtr($array[$key]['name'],'"'," ");

$array[$key]['name']=trim($array[$key]['name']);

$query='UPDATE `link` SET `title` = "'.$array[$key]['name'].'" WHERE `link`.`name` = "youtube_top_'.$i.'";';

$result = mysql_query($query);

$query='UPDATE `content` SET `option` = "youtube_'.$array[$key]['videofile'].'.mp4" WHERE `content`.`name` = "youtube_top_'.$i.'" LIMIT 1;';

Anhang 84

$result = mysql_query($query);

$i++;

}

fclose($fp);

?>

Abkürzungen 85

Abkürzungen

Die wichtigsten verwendeten Abkürzungen im Überblick:

AAA Authentication Authorization Accounting

AGI Asterisk Gateway Interface

API Application Programming Interface

CCA Call Center Agent

CDR Call Detail Records

CRM Customer Relationship Management

CSCF Call Session Control Function

HLR Home Location Register

HSS Home Subscriber Server

ICSCF InterrogatingCSCF

IAX InterAsterisk eXchange

IMPS Instant Messaging and Presence Service

IMS IP Multimedia Subsystem

IVR Interactive Voice Response

MD5 MessageDigest Algorithm 5

MMS Multimedia Messaging Service

MPEG Moving Picture Experts Group

NGA Next Generation Access

NGN Next Generation Network

Abkürzungen 86

OCS Online Charging System

PCSCF ProxyCSCF

PBX Private Branch eXchange

PHP PHP Hypertext Preprocessor

PRACK Provisional Acknoledgment

PSTN Public Switched Telephone Network

QoS Quality of Service

RTP RealTime Transport Protocol

SCSCF ServingCSCF

SHA Secure Hash Algorithm

SIP Session Initiation Protocol

SLF Subscription Locator Function

SMS Short Message Service

TLS Transport Layer Security

URL Uniform Resource Locator

URI Uniform Resource Identifier

Quellen 87

Quellen

Literatur

[3GIMS] Camarillo, Gonzalo / García-Martín, Miguel A. (2006): The

3G IP Multimedia Subsystem (IMS). West Sussex: John

Wiley & Sons Ltd.

[IMSCS] Poikselkä, Miikka / Mayer, Georg / Khartabil, Hisham /

Niemi, Aki (2006): The IMS, IP Multimedia Concepts and

Services, Second Edition. West Sussex: John Wiley &

Sons Ltd.

Standardisierung

[MEDIACONTROL] XML Schema for Media Control

http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-

media-control-12.txt

[RFC4629] RTP Payload Format for ITU-T Rec. H.263 Video

http://www.ietf.org/rfc/rfc4629.txt

Web

[ABUSALAH] Abu Salah, Stefan (2008): Analyse und Bewertung von

Quality of Service in Next Generation Networks.

http://www.abusalah.com

[ANDERSEN] http://www.net-im-web.de/pdf/2007_01s31.pdf

[ERICSSON] http://www.ericsson.com/solutions/products/hp/IMS_Multi

media_Telephony_bs.shtml

http://archive.ericsson.net/service/internet/picov/get?

DocNo=18/28701-

FGB101165&Lang=EN&HighestFree=Y

http://www.ericsson.com/solutions/products/hp/IMS_weSh

are_bs.shtml

http://www.ericsson.com/ericsson/press/facts_figures/doc/

weshare.pdf

http://www.ericsson.com/solutions/learning/marketing_inf

ormation/ims/ims_weshare_4_0/presentation.pdf

Quellen 88

[FESTIVAL] http://www.cstr.ed.ac.uk/projects/festival/

[FHOIC] http://www.openimscore.org/

[FONTVENTA] http://sip.fontventa.com/

[IBM] http://www-142.ibm.com/software/dre/ecatalog/Detail.wss

?locale=de_DE&synkey=M209950J71084S08

[ITU-T] http://www.itu.int/ITU-T/ngn/definition.html

[MPLAYER] http://www.mplayerhq.hu

[PARLAY] http://www.parlay.org

[PHPAGI] http://phpagi.sourceforge.net/

[QOSSIP] http://www.qossip.de

[RHINO] http://www.opencloud.com/products/rhino-products/ims-

app.html

[TRICK] http://www.e-technik.org/aufsaetze_vortraege/aufsaetze/

lehmann_trick_oehler_itg_mobilfunk_5_07.pdf

[SOX] http://sox.sourceforge.net

[WIKIPEDIA] http://de.wikipedia.org/wiki/3gp

http://en.wikipedia.org/wiki/3GPP

http://de.wikipedia.org/wiki/MPEG-1

http://de.wikipedia.org/wiki/Next_Generation_Network

Fachhochschule Köln Cologne University of Applied SciencesFachhochschule Köln Cologne University...

Documents

Transcript of Fachhochschule Köln Cologne University of Applied SciencesFachhochschule Köln Cologne University...