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:

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:

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