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.
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.
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:
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.
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.
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.
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 |
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.
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.
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.
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:
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 | \# |
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:
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.
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.
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.