8. Bewertung
8.1. Einleitung
In diesem Kapitel folgt abschließend der Versuch einer kritischen
Bewertung
der erreichten Ergebnisse. Nach einer Aufzählung dessen, was fehlt bzw.
nicht rechtzeitig fertig geworden ist, sollen Call-Server und CPL
in Hinblick auf ihren praktischen Nutzen betrachtet werden. Der
abschließende Abschnitt [ausblick] soll Richtungen für
eine Weiterentwicklung aufzeigen.
8.2. Was fehlt?
Während die Behandlung von ISDN-Anrufen problemlos
funktioniert, wie die Beispiele im letzten Kapitel zeigen,
so ist die Behandlung von SIP-Anrufen nicht fertig geworden.
Dies lag daran, daß die Behandlung von SIP-Anrufen
durch CPL-Skripte ursprünglich nicht vorgesehen war,
und die Implementierung der Anrufbehandlung um die
ISDN-Library herum implementiert wurde. Dies hat zur
Folge, daß die anrufbehandelnden Datenstrukturen
um die entsprechenden Kontextinformationen für
SIP-Anrufe erweitert werden müssen.
Weiterhin gibt es durch einen Fehler in dem der ISDN-Library
zugrundeliegenden Q.921-Modul Probleme mit der
ISDN-Rufumleitung. Beim Verbindungsabbau des zweiten
B-Kanals terminiert der Call-Server abnormal.
Dieser Fehler sollte jedoch relativ
leicht zu finden und beseitigen sein.
Die empfohlene Verwendung
eines CAPI-Interfaces würde dieses Problem
umgehen.
Sehr rudimentär ist die implemenierte Behandlung der
verschiedenen Audioformate: Auf der RTP-Seite werden
lediglich 8kHz A-law oder µ-law Audioströme
unterstützt. Auf der ISDN-Seite wird ein A-law
Audiostrom erwartet.
8.3. Bewertung
Die Beispiele des letzten Kapitels zeigen, daß mit
der Implementierung durchaus sinnvolle und
funktionierende Anwendungen
realisiert werden können.
Die Tatsache, daß Anrufe flexibel mit Hilfe einer
Skriptsprache behandelt werden können, eröffnet
vor allem im Bereich CTI vielfältige Möglichkeiten,
wenngleich diese bereits in zahlreichen kommerziellen
Produkten verfügbar sind.
Im Gegensatz zu diesen bietet die vorgestellte
Implementierung mehrere Vorteile:
- Durch die Verfügbarkeit des Source-Codes und
die Einbeziehung von Tcl ist sie leicht
erweiterbar und auf andere Plattformen portierbar.
- Der Sprachumfang von Tcl gestattet wesentlich
flexiblere Anwendungen, da er nicht auf
einen bestimmten Anwendungsbereich, wie beispielsweise
Call-Center-Anwendungen spezialisiert ist.
- Es werden nicht nur Telefonanrufe sondern auch solche aus
dem Internet berücksichtigt, wodurch sich
vielfältige Kopplungsmöglichkeiten beider Netze
ergeben. So könnte durch eine kleine Erweiterung
des Call-Servers auch das Eintreffen neuer e-Mails
einen Anruf zum Empfänger auslösen, falls dieser
nicht an seiner Workstation anwesend ist.
So kann die geschaffene Lösung in verschiedenen Bereichen
eingesetzt werden:
- Endanwender
-
Der Endanwender kann sich im Heimbereich quasi
sein eigenes elektronisches
Sekretariat mit
intelligentem Anrufbeantworter etc. realisieren.
- Informationsdienste
-
Ein Diensteanbieter kann Informationsdienste mit
Faxabruf, Rufumleitung, Ansagenaufzeichnung u.s.w.
realisieren.
- Internet-Provider
-
Ein Internet-Provider kann allgemein Zugang zu
MBONE-Konferenzen anbieten, oder aber Firmen, Institutionen
bieten Zugang zu internen Konferenzen an.
8.3.1. Der Call-Server
Die Verwendung einer CAPI-Schnittstelle
wäre für eine Portierung auf andere Plattformen sehr hilfreich,
da CAPI für die wichtigsten Plattformen wie OS/2, MS/Windows und UNIX
definiert ist.
Die gegenwärtig
auf der SUN-Plattform eingesetzte ISDN-Library kann relativ
leicht mit einer solchen Schnittstelle versehen werden:
Anstelle der ISDN-Main-Loop kommuniziert ein eigener CAPI-Prozeß
mit dem ISDN-Layer und schreibt alle Events in die
vom CAPI definierten Queues. Anwendungen kommunizieren via
dieser Queues, derer CAPI eine je registrierter Applikation und
eine für das CAPI definiert.
Wie schon in Kapitel [kap5] erwähnt, ist die gewählte
Server-Architektur für die parallele Behandlung mehrerer
Anrufe mit CPL-Skripten ungünstig gewählt: Es sollte vielmehr
eine Trennung von ISDN-Layer und Skript-Interpretation
erfolgen, wie in Abbildung [alt-arch] gezeigt.

Proposed call server architecture
Hierbei gibt es einen Hauptprozeß, der im wesentlichen die
Aufgabe hat, bei eingehenden Anrufen aus ISDN und Internet
für den Tcl-Anweisungsblock des betreffenden Events
einen Thread zu erzeugen.
Beim Eintreffen neuer Events oder bei abgelaufenen
Timern kann der Hauptprozeß den Thread abbrechen.
Bei dieser Architektur muß der Hauptprozeß zu Beginn zwar immer
noch das Skript parsen, jedoch kann dieser Aufwand vernachlässigt werden.
Meine Versuche, in der gegenwärtigen Implementierung die Zeit
für das Compilieren (Erzeugung des P-Codes) eines CPL-Skriptes
mit Hilfe des time-Kommandos sowie dem Profiler zu messen,
scheiterten, da die Meßwerte im Bereich der Timer-Auflösung lagen.
Die Realisierung dieser Architektur setzt jedoch einen
thread-tauglichen Tcl-Interpreter voraus.
Ein weiteres Problem ist die erforderliche Rechenleistung, die
insbesondere durch folgende Dinge recht hoch ist:
- DTMF-Erkennung
- Spracherkennung
- Wandlung der Audioformate
Die für die Implementierung benutzte IPX Sparcstation
war laut vmstat mit der Behandlung eines
Anrufes, eingeschalteter DTMF-Erkennung und bei
gleichzeitigem Abspielen eines Audiofiles schon
zu 50% ausgelastet, wobei die DTMF-Erkennung bereits
etwa 20% der Auslastung ausmachten.
Aus diesem Grunde wird die DTMF-Erkennung nur in solchen
Zuständen eingeschaltet, in denen
bzw. benutzt werden.
Bei der hier nicht praktisch erprobten Spracherkennung
dürfte der Rechenaufwand um ein Vielfaches höher liegen.
Auch sollte nur bei vorhandenen
Definitionen eingeschaltet werden.
Die Wandlung der Audioformate wird vor allem
bei besonders rechenintensiven Algorithmen wie
die für ADPCM [ITU-G726] oder LPC-10E [ITU-G728]
ein Problem,
da sich der Rechenaufwand mit der Anzahl der
parallel behandelten Audioströme multipliziert.
Für die gleichzeitige Behandlung von 30 Anrufen,
wie sie beim S2M-Anschluß (PRI) vorkommt, wäre
dann eine entsprechende Rechenleistung vorzusehen.
8.3.2. Die Skriptsprache
Die Skriptsprache scheint mir bei Einsatz des Tcl-Interpreters
nicht unbedingt verbesserungsbedürftig. Es sind alle
sprachlichen Konstrukte zur Realisierung von Anwendungen
sowohl als State-Machine als auch in Form sequentiell
ablaufender Programme vorhanden.
Mehrere Mediendatenströme
Für die Einbeziehung mehrerer Mediendatenströme wie Audio und
Video, die ja für ISDN-Teilnehmer durchaus realistisch sind,
müßte allerdings noch eine Unterstützung eingebaut werden.
Für Anrufe aus dem ISDN stelle ich mir vor, dem Skript
beim Aufruf die entsprechenden Kanäle in Form von Filedescriptoren
als Parameter mitzugeben.
In einem Skript, in dem nur Video behandelt wird, wäre es z.B.
unsinning stdout immer fest mit dem Audiostrom des eingehenden
Anrufes zu verbinden. Dies erhöht die Existenzberechtigung der schon
infrage gestellten isdn.cfg Konfigurationsdatei.
Zeitangaben bei Timern
Die beim Starten von Timern ursprünglich in Millisekunden
angegebenen Zeiten werden nun, wie in Anhang [app-grammar]
beschrieben in der Notation HH:MM:SS angegeben, was bei
großen Zeitangaben wesentlich lesbarer ist.
Aufgrund der Implementierung können Zeiten
im Millisekundenbereich
ohnehin nicht exakt eingehalten werden.
In der Implementierung ist diese Syntax bis zum
Ende der Arbeit möglicherweise noch nicht berücksichtigt
worden.
Globale Fehlerbehandlung
Die Behandlung von Fehlern könnte durch eine
ereignisorientierte Fehlerbehandlung
bei komplexen Anwendungen wesentlich vereinfacht werden.
Bisher muß hinter jeder CPL-Anweisung, bei der ein Fehler
auftreten könnte, eine Abfrage mit sysStatus stehen.
Ein neues Event könnte global definiert
werden und Fehler behandeln. Spezialfälle in bestimmten
Zuständen könnten wie bei Timern mit einer
lokalen Definition überdeckt werden.
8.4. Ausblick
Neben der zukünftigen Verwendung eines Tcl-Interpreters
wird sicher die Anrufbehandlung Verbesserungen erfahren
müssen. So wäre es denkbar, daß bereits laufende
Skripte weitere eingehende Anrufe behandeln. Hierfür sollte
dann jeder Befehl, der auf einem Mediendatenstrom operiert
mit einer Anruf-Id parametrisiert werden. Generell sollten
diese Befehle flexibler einsetzbar sein.
Derzeit sind Befehle wie oder
auf den Anruferdatenstrom bezogen. So wird z.B. bei einer
bestehenden
ISDN-ISDN-Rufumleitung durch
nicht nur die Umleitung sondern der eingehende
Anruf beendet.
Eingehende und ausgehende Datenströme sollten jedoch
getrennt und gleichbehandelt werden. CPL-Anweisungen müßten hierfür
mit einem Parameter versehen werden, der den
entsprechenden Datenstrom identifiziert. So kann
dann z.B. ein Audiofile nicht nur dem Anrufer sondern
auch anderen Konferenzteilnehmern abgespielt werden.
Weiterhin wäre auf der Netzwerkseite die Einbeziehung
entsprechender Session-Control Protokolle sinnvoll, da
mit SIP derzeit lediglich der Konferenzaufbau unterstützt
wird[Nach Aussagen der Autoren soll SIP in Zukunft
auch den Verbindungsabbau signalisieren können].
Der Netzwerkbenutzer sollte jedoch mindestens über die
gleichen Möglichkeiten verfügen, wie der Telefonanrufer,
d.h. auch er sollte eine Verbindung beenden können und
eine Signalisierungsmöglichkeit analog der
DTMF-Zeichengabe besitzen.
So gesehen stellt die gegenwärtige Implementierung von
Call-Server und CPL nur den Anfang einer universellen
Lösung zur Integration von Telefonnetzteilnehmern in
MBONE-Konferenzen dar.
---------------------
File was created Wed Feb 26 18:31:47 1997 by tex2html