3. Problemanalyse


3.1. Einleitung

Die im vorherigen Kapitel aufgestellten Anforderungen beinhalten also eine Kopplung von ISDN und Internet. Benötigt wird eine Instanz, die beide Netze miteinander verbindet, Anrufe von beiden Seiten behandelt und die Mediendatenströme entsprechend umwandelt, Abbildung [pic-switch] skizziert dies.

Internet-ISDN Kopplung allgemein


3.2. Internet Multimediakonferenz

Zur Übertragung von Multimedia-Konferenzen im Internet findet inzwischen vorwiegend das Real-Time Transport Protocol RTP [RFC1889] Anwendung. Dabei können in einem RTP-Strom mehrere Mediendatenströme (z.B. Audio und Video) transportiert werden. Da auch im ISDN die Möglichkeit besteht, verschiedene Mediendatenströme über eine Verbindung zu transportieren, ist eine Teilnahme per Telefon auch an solchen Internet-Konferenzen sinnvoll, in denen nicht nur Audio sondern auch Video benutzt wird. Lediglich die Formate von RTP-Strom und B-Kanal müssen angepaßt werden, sofern sie unterschiedlich sind. Während im europäischen ISDN Audiodaten A-law codiert (in den U.S.A. µ-law) mit einer Abtastrate von 8kHz übertragen werden, findet für die Audiodatenübertragung im MBONE eine breite Palette von Formaten wie GSM, lineare PCM, A-law, µ-law, DVI oder LPC bei unterschiedlichen Abtastraten Anwendung.

Wenngleich derzeit die Mehrheit der Telefonanschlüsse noch analoger Natur sind und die Preise für Bildtelefonie-Endgeräte ihrer flächendeckenden Verbreitung noch im Wege stehen, sollte die zu realisierende Architektur die Konferenzteilnahme mit mehreren Mediendatenströmen prinzipiell unterstützen. Alle weiteren Betrachtungen in dieser Arbeit beschränken sich jedoch nur auf Audiodatenströme.


3.3. Telefonische Konferenzteilnahme

Während also die Kopplung der Mediendatenströme von ISDN und Internet lediglich eine Frage der Formatwandlung ist, stellt sich die Frage, welche Signalisierungsmöglichkeiten nötig sind, um telefonisch an einer Internet-Konferenz teilzunehmen bzw. was sonst noch benötigt wird.

Generell (also nicht nur telefonisch) erfordert die passive Teilnahme an einer unverschlüsselt per RTP übertragenen Konferenz, die Kenntnis von IP-Gruppen-Adresse (bei einem Multicast-Datenstrom) sowie der UDP-Portnummer. Passive Teilnahme soll bedeuten, daß der Anrufer selbst keine Teilnehmer einlädt, sondern von sich aus oder aufgrund einer Einladung der Konferenz beitritt. IP-Adresse und Portnummer können prinzipiell erlangt werden durch:

  1. Einen anderen Teilnehmer, der in einem Einladungswunsch die Konferenzparameter überträgt, z.B. in einem SIP-INVITE-Request,
  2. durch ein Session Directory, ein Dienst, der Informationen über aktuelle oder angekündigte Konferenzen ähnlich einer Programmzeitschrift sammelt, oder aber
  3. über andere Kommunikationswege, wie Telefon oder Fax.

Im ersten Fall ist das Problem bereits gelöst, da der Anrufer aus dem Internet die Kopplung von RTP-Strom und ISDN-Strom bereits vollzogen hat; dem Anrufer kann es egal sein, mit welchen Parametern der Datenstrom in irgendeinem Teil des Übertragungsweges geführt wird.


3.4. Zugang zum Session Directory (SD)

Session Directories sind Programme, die im Internet übertragene Konferenzankündigungen sammeln und über eine entsprechende Schnittstelle einem Netzwerkbenutzer anbieten. Einem Anrufer steht dieser Dienst also zunächst nicht zur Verfügung. Da aber außer dem dritten Weg, keine anderen Möglichkeiten existieren, die Konferenz-Parameter zu erlangen, wäre es für den Anrufer sehr hilfreich, auf diese Informationen zugreifen zu können.

Konferenzankündigungen werden mit kommerziellen Programmen wie IP/TV[http://www.precept.com] oder frei erhältlichen wie SDR[http://ugwww.ucs.ed.ac.uk/mice/archive/sdr.html] via IP-Multicast [RFC1112] periodisch[bei meinen Messungen in der GMD alle 7 bis 13 Minuten] im MBONE verschickt. Als Protokoll hat sich hierfür SDP durchgesetzt. Im folgenden SDP-Paket wird durch den Benutzer "Andrew Patrick" eine Session mit Audio und Video angekündigt:

v=0
o=andrew 3059744132 3059744250 IN IP4 131.136.234.103
s=CBC Newsworld Online
i=NEWSWORLD is Canada's 24-hour all news and information
specialty network. If you view this session, PLEASE
complete the questionnaire at
\url{http://debra.dgbt.doc.ca/mbone/newsworldq.html}.
NEWSWORLD is a non-profit service dedicated wholly
to news and inf...
u=http://debra.dgbt.doc.ca/mbone/newsworld.html
e=Andrew Patrick <andrew@spiff.crc-mcast.drenet.dnd.ca>
p=Andrew Patrick +1 613 990-4675
c=IN IP4 224.2.222.241/127
t=3059742600 3062161800
a=tool:sdr v2.2a22
a=type:broadcast
m=audio 24992 RTP/AVP 0
c=IN IP4 224.2.222.241/127
a=ptime:40
m=video 64512 RTP/AVP 31
c=IN IP4 224.2.221.77/127

Auskunft über den Inhalt der angekündigten Session geben die Felder s= (session name) und i= (session information). Das Feld m= (media name and transport address) enthält die für die Konferenzteilnahme erforderlichen Medienparameter, in dem gezeigten Beispiel also Audio (m=audio) und Video (m=video), das Feld t= gibt Start- und Stoppzeit der Session gemäß [RFC1305] an.

Aufgrund der Tatsache, daß sich die Session-Informationen ständig ändern, bleibt die Sprachsynthese der einzige Weg, einem Anrufer diese Informationen aktuell zu präsentieren. Da die Ankündigungen in relativ großen Abständen (mehrere Minuten) ausgeschickt werden, müssen diese für einen potentiellen Anrufer in einer Art Cache gesammelt werden, sofern dieser nicht minutenlang am Telefon warten will.

Bei Messungen bei FOKUS GMD konnte ich an einem Tag zwischen 09{48 und 16{20 Uhr also innerhalb von 61/2h 1364 Session-Announcements empfangen. In diesen wurden 24 verschiedene Konferenzen angekündigt, im Mittel wurde also jede Konferenz 56 mal, also 7 mal pro Stunde, d.h. alle 8 bis 9 Minuten angekündigt.

Angesichts der relativ geringen Zahl von 24 Konferenzen könnte man meinen, daß einem Anrufer einfach alle aufgefangenen Ankündigungen vorgelesen werden. Mittels Telefontastatur (siehe [dtmf-rec]) kann er dann die gewünschte Konferenz wählen. Natürlich sollte sich das Vorlesen auf den Inhalt der s= Felder beschränken. Nur auf Wunsch (Tastendruck) sollten i=, t= und m= Felder vorgelesen werden. An anderen Orten, vor allem solchen, an denen das MBONE besser ausgebaut ist als in Deutschland, sind größere Zahlen zu erwarten. Geht man aufgrund des Ausbaus von Internet und MBONE auch bei uns von einer Zunahme der Announcements aus, so scheint das Vorlesen aller Ankündigungen nicht zweckmäßig.

Die Menge der Konferenzankündigungen kann reduziert werden, indem nur solche Sessions vorgelesen werden, an denen eine telefonische Teilnahme sinnvoll möglich ist. Also reine Video-Sessions (ohne Audio) sollten nicht vorgelesen werden, wenn der Anrufer nur einen Audiokanal benutzt. Auch sollten nur gegenwärtig oder in naher Zukunft (z.B. nur am gleichen Tage) stattfindende Sessions vorgelesen werden.

Eine weitere Selektionsmöglichkeit bietet das TTL-Feld in der c= Zeile, mit dem der Verbreitungsbereich der Konferenz festgelegt wird. So könnte man sich vorstellen, bei einem Anruf in der Uni nur die Teilnahme an internen Konferenzen (TTL < 16) zuzulassen.

Eine weitere Möglichkeit, an diese Informationen zu gelangen besteht darin, sie sich zufaxen zu lassen. Auf dem Fax sind die angekündigten Sessions mit einer zwei- oder dreistelligen Nummer versehen, die der Anrufer eingeben muß, wenn er verbunden werden will.


3.5. Signalisierungsmöglichkeiten

Für eine telefonische Konferenzteilnahme benötigt der Anrufer also:

  1. Einen Telefonanschluß und ein Endgerät, das die Teilnahme an dem gewünschten Mediendatenstrom unterstützt.
  2. Die Telefonnummer eines Service-Providers, der die zu realisierende Internet-Anbindung möglichst kostengünstig bereitstellt.
  3. Die IP-Adresse sowie die Portnummer der gewünschten Konferenz.
  4. Eine Möglichkeit, beide Parameter am Telefon einzugeben.

Letzteres wird hier als Signalisierung bezeichnet und wird z.B. auch dann gebraucht, um während des Gespräches weitere Teilnehmer hinzuzubeten oder die Konferenz zu wechseln. Für die in [cti-appl] geforderte Realisierung allgemeiner Telefonieanwendungen wird eine generelle Möglichkeit benötigt, mit der ein Anrufer Eingaben am Telefonapparat vornehmen kann, z.B. um aus einer Liste von Möglichkeiten eine Auswahl zu treffen.

3.5.1. DTMF-Ton-Erkennung

Dem Anrufer, der telefonisch an einer Multimedia-Konferenz teilnehmen will, steht für die Signalisierung letztendlich nur die Tastatur des Telefons sowie die Sprache zur Verfügung. An modernen Telefonapparaten werden die während einer Verbindung gedrückten Tasten in Mehrfrequenztöne nach ITU-T Q.23/Q.24 [ITU-Q23] [ITU-Q24] umgewandelt und über den Sprachkanal zur Gegenstelle geschickt. Diese muß dann die Töne aus dem Datenstrom des Sprachkanals herausfiltern bzw. erkennen. Es handelt sich hierbei also um eine In-Band-Signalisierung. Um eine hohe Erkennungswahrscheinlichkeit zu gewährleisten, sind die Frequenzen so gewählt, daß sie möglichst nicht durch Sprache o.ä. imitiert werden können. Ein Ton wird dabei aus zwei Frequenzen gebildet, die jeweils aus einer Gruppe zu je vier Frequenzen entstammen (daher auch Dual-Tone Multiple-Frequency, kurz DTMF). Nach Q.23 muß ein Ton eine Mindestlänge von 40 ms haben, der Abstand zwischen zwei Tönen muß mindestens 20 ms betragen. Tabelle [tab-dtmf] zeigt die Frequenzen für die 16 definierten Tasten. Neben den zehn Zifferntasten sowie Stern und Raute gibt es vier weitere Tasten A bis D, die für allgemeine Steuerungszwecke gedacht, auf den meisten Telefontastaturen jedoch nicht zu finden sind.

1209 Hz 1336 Hz 1477Hz 1633 Hz
697 Hz 1 2 3 A
770 Hz 4 5 6 B
852 Hz 7 8 9 C
941 Hz * 0 \# D

Frequenz-Tastenzuordnung nach ITU-T Q.23

Für die Erkennung der Töne beim Empfänger wird aus Effizienzgründen oft Hardware basierend auf digitalen Signalprozessoren (DSPs) eingesetzt. Für den Einsatz in einem reinen Software-System ist dies wenig geeignet. In [Ars96][http://ptolemy.eecs.berkeley.edu/papers/96/dtmf\_ict/www/paper.html] werden verschiedene Algorithmen zur Erkennung von DTMF-Tönen vorgestellt und in Hinblick auf Implementierungsaufwand und Normkonformität untersucht. Einer der untersuchten Algorithmen ist der Goertzel-Algorithmus, der aufgrund seiner einfachen Implementierung in dieser Arbeit in einem DTMF-Dekoder zum Einsatz kommt.

3.5.2. Spracherkennung

Die sicher natürlichste Art der Signalisierung bietet die Spracherkennung, welche in zahlreichen kommerziellen Produktion heute bereits Anwendung findet. Ein Beispiel hierfür ist das Produkt VoiceType von IBM, das u.a. auch in dem Betriebssystem OS/2 der gleichen Firma zum Einsatz kommt. Während die Erkennungsgenauigkeit und -Geschwindigkeit als ausreichend bezeichnet werden kann, verhindert die bei diesem Produkt erforderliche Lernphase der Software den Einsatz in einer Telefonieanwendung. Bei der Suche nach frei verfügbarer Spracherkennungs-Software bin ich leider nur auf kommerzielle Produkte gestoßen, wie den folgenden:

Eine auf einem DSP basierende Hardware-Lösung namens Antares, wird von Dialogic[http://www.dialogic.com/] angeboten. Auf dieser Plattform können mit Hilfe verschiedener Toolkits Telekommunikationslösungen realisiert werden. Zur Sprachsynthese wird hierfür beispielsweise von PureSpeech die Entwicklungsumgebung ReCite[http://www.speech.com./recite.html] angeboten.

Da mir kommerzielle Produkte jedoch nicht zur Verfügung standen und die Komplexität eine eigene Implementierung ausschließt, findet Spracherkennung in dieser Arbeit keine praktische Anwendung. Ihr Einsatz wird jedoch in meiner Implementierung berücksichtigt.


3.6. Sprachsynthese

Da für den Dialog mit einem Anrufer aus dem Telefonnetz die Audioverbindung als einziger Kommunikationskanal existiert, müssen alle Informationen verbal ausgegeben werden. Soll der Anrufer z.B. nach der Konferenz gefragt werden, an der er teilnehmen will, so muß ein entsprechender vorab aufgenommener Text abgespielt werden. Während dies für einfache Dialoge wie die bei einem Anrufbeantworter ausreicht, so genügt dies für die Realisierung komplexer Informationsdienste, wie dem geplanten MBONE-Informationsservice nicht mehr. Die Aktualität der dem Anrufer gebotenen Informationen kann nur gewahrt werden, wenn die Sprachausgabe spontan, also mittels Sprachsynthese erzeugt wird. Hierfür gibt es zahlreiche kommerzielle und nicht-kommerzielle Produkte, von denen stellvertretend einige aufgezählt werden sollen:

Das Angebot an frei erhältlicher Software ist im Gegensatz zur Spracherkennungs-Software besser, und so konnte ich einige Programme ausprobieren. In der Sprachqualität zeigen sich sehr große Unterschiede, die besten Ergebnisse erzielte ORATOR II eine Entwicklung von Bellcore, die allerdings nicht frei erhältlich ist. Die freie Verfügbarkeit des Quellcodes des Rsynth-Paketes gestattete eine Portierung auf die zur Entwicklung benutzte AIX-Umgebung und kam somit versuchsweise zum Einsatz. Die Sprachqualität dieses Paketes ist erwies sich jedoch als ungenügend. Der Einsatz anderer Pakete scheiterte an der Nichtverfügbarkeit des Sourcecodes. Meine Implementierung unterstützt jedoch den Einsatz beliebiger Sprachsynthese-Software, da für die Synthese lediglich eine Kommandozeile ausgeführt wird, in der letztendlich jedes beliebige Programm oder Shell gestartet werden kann.


3.7. Eingabe von e-Mail-Adressen per Telefon

Um wie in [net-call] gefordert, Netzwerkbenutzer per Telefon anrufen, also zu einer Konferenz einladen zu können, bedarf es einer entsprechenden Teilnehmeradressierung. Für Einladungen soll das bereits erwähnte Session Invitation Protocol SIP zum Einsatz kommen. Im Gegensatz zum Telefonnetz unterstützt SIP eine personenbezogene Adressierung bei der eine Kombination aus User-Id und Rechner- bzw. Domain-Name [RFC1034], [RFC1034] verwendet wird, so wie sie in Form von e-Mail-Adressen im Internet seit langem in Gebrauch ist [RFC822]. Mittels eines SIP-INVITE-Requests kann ein Benutzer also durch Angabe seiner e-Mail-Adresse zu einer Konferenz eingeladen werden. Die e-Mail-Adresse kann sowohl in der Form username@host.domain als auch username@domain angegeben werden.

Dem Anrufer, der mittels SIP einen Netzwerkbenutzer anrufen will, muß also eine Möglichkeit erhalten, die e-Mail-Adresse des Teilnehmers per Telefon einzugeben. Soll dies nicht per Spracherkennung sondern per Tastatur geschehen, so muß die bereits erwähnte DTMF-Tonerkennung zum Einsatz kommen, welche jedoch nur 16 Zeichen unterstützt. Wie e-Mail-Adressen trotz des wesentlich größeren Zeichenvorrates mittels DTMF-Tasten am Telefon eingegeben werden können, sollen die folgenden Überlegungen zeigen.

RFC 822 [RFC822] erlaubt folgende Zeichen in einem Adressfeld:

atom     ::= 1*<any CHAR except specials, SPACE and CTLs>
char     ::= <any ASCII character>
specials ::= "(" | ")" | "<" | ">" | "@" | "," | ";" |
             ":" | """ | "." | "[" | "]"
ctl      ::= <any ASCII control>

Von den 128 im ASCII-Zeichensatz definierten Zeichen bleiben also 84 Zeichen übrig (127 - 31 controls - 1 space - 12 specials). Demnach wird in einer e-Mail-Adresse also auch zwischen Groß- und Kleinschreibung unterschieden[Wovon in der Praxis allerdings selten Gebrauch gemacht wird, da z.B. UNIX-User-Ids grundsätzlich aus Kleinbuchstaben bestehen], außerdem sind auch so ungewöhnliche Zeichen wie zugelassen. Die 84 Zeichen müssen nun auf die 16 in ITU Q.23 definierten DTMF-Tasten gemapped werden. Da die meisten Telefone nur über die Tasten 0 bis 9 sowie * und \#, also nur 12 Tasten verfügen, sollten nur diese für die Umsetzung herangezogen werden. Rechnerisch ergibt sich, daß jede der 12 Tasten des Telefonapparates neben der jeweiligen Ziffer mit sieben (!) weiteren Zeichen belegt sein müßte (84 / 12).

Würde man also im trivialen Fall auf jede Taste sieben Zeichen legen, so wären für die Eingabe einer üblichen Adresse wie "foertel@ibm.net" bei 15 Zeichen und 3.5 durchschnittlichen Tastendrücken insgesamt 52.5 Tastendrücke nötig, was offensichtlich nicht praktikabel ist. Neben der Spracheingabe bleiben folgende Alternativen:

Automatisierung des Wählvorgangs
Mit einer einfach handhabbaren Hardware, etwa im Format eines Touch-Tone-Dialers, gibt der Benutzer auf einer miniaturisierten ASCII-Tastatur die gewünschte e-Mail-Adresse wie gewohnt ein. Das Gerät nimmt dann die Umsetzung in DTMF-Tones vor. Da eine umfangreichere Tastatur zwangsläufig zu größeren Geräteabmessungen führt, verringert sich allerdings auch hier die praktische Einsetzbarkeit. Außerdem dürfte eine flächendeckende Verbreitung derartiger Geräte schwer sein. Eine Alternative stellen Geräte dar, die bereits verbreitet sind, wie etwa Notebook-Rechner oder noch besser (weil kleiner) sog. Personal Digital Assistants (PDAs). Neben einer ASCII-Tastatur verfügen diese meist auch über eingebaute Lautsprecher und sind programmierbar, so daß lediglich eine Umsetzungs-Software gebraucht wird.
Reduzierung des Zeichenvorrates
Eine Reduktion des erlaubten Zeichenvorrates, wie sie z.B. durch eine Gleichstellung von Groß- und Kleinbuchstaben erreicht werden könnte, würde die Mehrfachbelegung der 12 Telefontasten deutlich verringern.

Der ersten Möglichkeit weiter nachzugehen, scheint mir angesichts der sich auf dem Telekommunikationsmarkt abzeichnenden Entwicklungen wenig sinnvoll: Von Nokia wird beispielsweise ein Mobilfunktelefon (Nokia Communicator 9000[http://www.nokia.com/com9000/n9000.html]) mit eingebautem Fax-Gerät, WWW-Browser, e-Mail-Client und Telnet-Emulation angeboten. Es dürfte wohl nur eine Frage sehr kurzer Zeit sein, bis man mittels eines solchen Gerätes auch direkt Internet-Telefonie betreiben kann.

Die zweite Möglichkeit, den Zeichenvorrat zu reduzieren, scheint mir der sinnvollere Weg. Beschränkt man sich beispielsweise auf die ausschließliche Verwendung von Buchstaben (ohne Unterscheidung von Groß- und Kleinbuchstaben) in e-Mail-Adressen,

1 2 ABC 3 DEF 1 QZ 2 ABC 3 DEF
4 GHI 5 JKL 6 MNO 4 GHI 5 JKL 6 MNO
7 PQRS 8 TUV 9 WXYZ 7 PRS 8 TUV 9 WXY
* 0 \# * 0 \#

Telefontastaturen nach ITU-T E.161

so böte sich eine der in ITU-T E.161 [ITU-E161] vorgeschlagenen Tastenbelegungen an (siehe auch [tab-e161]). Dieser Standard ist seit langem etabliert und dementsprechend auch auf den Tastaturen zahlreicher Endgeräte aufgedruckt, wobei sich die Option A der vorgeschlagenen Belegung durchgesetzt hat. Ein Buchstabe wird hier durch mehrmaliges Drücken der betreffenden Taste erzeugt. Soll beispielsweise ein E eingegeben werden, so muß die 3-Taste zweimal gedrückt werden. Natürlich setzt dies voraus, das sich das Endgerät in einem alphanumerischen Modus befindet, ansonsten erzeugt das Drücken der Zifferntasten die jeweilige Ziffer. Auf die nächste Zeichenposition wird jeweils geschaltet wenn:

  1. Automatisch nach ca. 1 s nachdem eine der Tasten 2 bis 9 das erstemal gedrückt wurde.
  2. Nachdem eine andere Taste gedrückt wurde.

Werden also in kurzer Folge die Tasten 2 2 8 eingegeben, so wird sofort nach dem Drücken der 8 der Buchstabe B erzeugt und auf die nächste Zeichenposition geschaltet (also ohne das Timeout von ca. 1 s abzuwarten). Mit dem Drücken der 8 beginnt das Timeout von 1 s erneut, so daß nun ein T erzeugt wird, wenn innerhalb des Timeouts keine weitere Taste gedrückt wurde. Für die Eingabe von "foertel@ibm.net" wären dann

Zeichen: f o e r t e l @ i b m . n e t
Taste: 3 6 3 7 8 3 5 \# 4 2 6 * 6 3 8
Anzahl: 3 3 2 3 1 2 3 1 3 2 1 1 2 2 1

immerhin noch 30 Tastendrücke erforderlich. Die Punkte werden hierbei mit der *-Taste und das at-Sign mit der \#-Taste eingegeben. Zusätzlich müßte die Eingabe mit irgendeiner Taste z.B. \# abgeschlossen werden.

Aufgrund der fehlenden Anzeige der eingetippten Zeichen am Telefonapparat ist eine Kontrolle der Eingabe durch den Benutzer nur schwer möglich, so daß auch diese Methode bei längeren Zeichenketten unbefriedigend ist. Zudem fehlt noch die Definition einer Korrekturtaste. Spätestens bei längeren Adressen wie "schulzrinne@cs.columbia.edu"(27 Zeichen) wird die Unbrauchbarkeit dieses Verfahrens deutlich.

Weitere Überlegungen führen zu der Frage, ob überhaupt alle Zeichen der e-Mail-Adresse erforderlich sind um den Teilnehmer eindeutig zu adressieren. So ist denkbar, daß bei einem Anruf z.B. bei FOKUS das Weglassen des Host-/Domain-Teils einen Default-Wert (z.B. fokus.gmd.de) impliziert. In diesem Fall wäre also die ausschließliche Angabe der User-Id eindeutig. So wären für "foertel" nur noch 14 und für "schulzrinne" immerhin noch 31 Tastendrücke erforderlich (bei Anwendung von Option A der ITU-T E.161 Empfehlung).

Diese Zahlen scheinen mir gerade noch akzeptabel, vor allem angesichts der fehlenden Eingabekontrolle. Natürlich würde man jedes auf die oben beschriebene Art erkannte Zeichen per Sprachsynthese o.ä. quittieren, aber dennoch würde der Anrufer bei langen Zeichenketten (> 25 Zeichen) schnell den Überblick verlieren. Aus diesem Grunde scheint mir eine manuelle Eingabe von e-Mail-Adressen am Telefon nur in Ausnahmefällen sinnvoll, eben in solchen, wo die alleinige Angabe der User-Id eindeutig ist.

Da die Eingabe von Zeichenketten auch für andere Dinge als e-Mail-Adressen sinnvoll sein kann, unterstützt die in dieser Arbeit vorgestellte Implementierung die Eingabe von Zeichenketten nach ITU-T E.161 in der beschriebenen Art und Weise.


3.8. Computer Telephony Standards

Da die angestrebte Integration von Telefonteilnehmern in Internet-Konferenzen mit dem Thema Computer-Telephony-Integration (CTI) zu tun hat, liegt der Gedanke nahe, einen Blick auf existierende CTI-Standards zu werfen, siehe auch [Carl96:CTI][http://www.dialogic.com/company/whitepap/carlieee.htm]

und [Mes96:CTI]. Hier spielen vor allem Microsofts Windows Telephony Application Programming Interface (TAPI) und TSAPI [Cro96:TSAPI], das u.a. von Novell entwickelt wurde, eine Rolle. Weiterhin gibt es von der European Computer Manufacturers Association (ECMA) Computer-Supported Telecommunications Applications (CSTA) Standards, in denen die hardware-unabhängige Steuerung von Telefoniegeräten (Telefone, Tk-Anlagen) behandelt wird. Im TSAPI sind hierfür entsprechende Primitiven realisiert. So gibt es Funktionen zum Auf- und Abbau von Verbindungen zwischen Geräten (cstaMakeCall(), cstaClearCall()) sowie Zusatzfunktionen wie cstaHoldCall() und cstaTransferCall() um Merkmale wie Makeln oder Rufweiterleitung zu realisieren.

Network telephony system architecture

Die genannten Standards gehen von einer Client-Server Architektur aus, in der sog. Telephony-Server über einen CTI-Link mit Tk-Anlagen (PBX) verbunden sind und deren Steuerung übernehmen (siehe Abb [pic-nettel]). Ein Client kann über eines der o.g. APIs die Dienste des Servers in Anspruch nehmen. Hierbei wird jedoch nach wie vor der Telefonapparat zur Sprachübertragung benutzt, lediglich seine Steuerung sowie die der Tk-Anlage erfolgt mittels des APIs. Sprach- oder Bilddatenübertragung bleiben von diesen Standards unberücksichtigt. Ein typisches kommerzielles Produkt, in dem diese Schnittstellen zum Einsatz kommen ist CT-Connect[http://www.dialogic.com/PRODUCTS/D\_SHEETS/1741WEB.HTM] von Dialogic. Dabei handelt es sich um eine Call-Control-Server-Software mit deren Hilfe sich Telefonanlagen, die über die oben genannten Schnittstellen verfügen, in Datennetze einbinden lassen. Die Software unterstützt "...call control and monitoring through links to many popular telephone switches", so der Hersteller. Vereinfacht kann man sagen, daß mit Hilfe dieser APIs der PC bzw. die Workstation zum Komforttelefon werden. Da dies nicht Ziel dieser Arbeit ist, kommen CTI-Standards hier nicht zur Anwendung.


File was created Wed Feb 26 18:31:46 1997 by tex2html