Computerunterstützte Telefonie

Computerunterstützte Telefonie Lutz Winkler Hochschule für Technik und Wirtschaft Mittweida (FH) Gliederung: 1 MÖGLICHE ANWENDUNGEN 2 2 DAS GRUNDPRINZIP 4 3 DIE KLASSISCHE LÖSUNG 7 4 PC-BASIERTE LÖSUNGEN 13 5 QUELLENVERZEICHNIS 17 Übersicht: Viele Arbeitsplätze in Industrie, Handel, Finanzwirtschaft, Verwaltung, Öffentlichen Dienst usw. sind mit Telefon und Computer ausgerüstet. Die diese Endgeräte umgebende Kommunikationsinfrastruktur wird im privaten Bereich durch TK-Anlagen und Lokale Rechnernetze gebildet. Drei Entwicklungstendenzen sind derzeit erkennbar: 1. Es findet eine Systemintegration durch Zusammenwachsen der lokalen TK- und DV-Welten, beispielsweise durch Anschluß- und Endgeräteintegration, statt. 2. Es werden Corporate Networks zur Schaffung einer einheitlichen, leistungsfähigen Infrastruktur für Sprach- und Datenkommunikation für örtlich verteilte Firmen oder Interessengemeinschaften auch als Fortsetzung der lokalen Systemeintegration geschaffen. 3. Es findet eine Anwendungsintegration durch Multimedia-Anwendungen mit Sprach-, Daten- und Bildkommunikation oder computerunterstützter Telefonie statt. Der vorliegende Beitrag geht auf Grundlagen, Anwendungen und Lösungen für computerunterstützte Telefonie ein.

1 Mögliche Anwendungen Bei der Diskussion von Integrationsansätzen für Telefon und Computer sind zwei Aspekte zu unterscheiden: der Anwendungsaspekt, d.h. wie ergänzen sich die Teledienste, die Endgeräte, die Infrastrukturen, und welche neuen Anwendungen ergeben sich daraus, Der Steueraspekt, d.h. welche sinnvollen Möglichkeiten gibt es, Kommunikationsverbindungen einerseits und Anwendungs- oder Hilfsprogramme andererseits zu steuern. Beide Aspekte sind nicht immer klar zu unterscheiden. Im folgenden sollen vier typische Szenarien, dargestellt in Abbildung 1, in diesem Kontext etwas näher betrachtet werden. A B LAN C Endgeräte- Interface Server/ Host Client/ Terminal D System-Interface für computerunterstützte Telefonie Abbildung 1: Integrationsszenarien für Telefon und Computer Fall A: Dieses Szenario ist der derzeit dominierende Fall. Beide Endgeräte sind an spezialisierte Infrastrukturen angeschlossen. Die Steuerungs- und Anwendungsintegration wird durch den Nutzer realisiert. Beispielsweise ist das Telefonverzeichnis oder eine Anrufliste auf dem Computer gespeichert. Nach zügigem Suchen und Finden wird eine Rufnummer, schon etwas langsamer, vom Bildschirm abgelesen und über Tastatur oder Nummernscheibe der Vermittlung signalisiert. Andererseits startet der Telefonbenutzer bei bestimmten Anrufen Computerprogramme, um Notizen, Telefonnummern usw. zu editieren. Fall B: Dieser Fall wird am besten dadurch beschrieben, daß wahlweise und/oder alternierend die normale Bedienoberfläche des Telefons oder eine Bedienoberfläche implementiert auf 2

dem Computer zur Herstellung, Annahme, Manipulation und Beendigung von Telefongesprächen genutzt werden kann. Dies kann soweit gehen, daß durch Tastendruck auf dem Telefon unterstützende Programme (Telefonbuch, Listen, Notizen, usw.) auf dem Computer aufgerufen werden oder bei ankommenden Gesprächen auf dem Bildschirm Informationen, den Anrufer betreffend, angezeigt werden. Die Realisierung solcher Merkmale erfordert zusätzliche Hard- und Software auf beiden Endsystemen. Eine schnelle Lösung könnte sich dann ergeben, wenn das Telefon Bestandteil des Computers wird, wie dies schon bei einigen Workstations üblich ist. Eine komfortable Bedienoberfläche wird durch den Computer bereitgestellt. Die akustische Oberfläche kann durch ein Handset, durch eine Freisprecheinrichtung oder ein Kopfset gebildet werden. Andererseits kann das herkömmliche Telefon über ein Steuerinterface mit einem Computer verbunden werden und Steuerungsanreize in beide Richtungen ausgetauscht werden. Ein möglicher Ansatz wäre die Nutzung einer V.24-Schnittstelle und des Hayes-Befehlssatzes. Fast jeder Computer hat eine solche Schnittstelle und viele Kommunikations- und Organisationsprogramme unterstützen die Herstellung von Fernsprechverbindungen vermittels des Hayes- Befehlssatzes. Auf Seiten des Telefons muß eine V.24-Schnittstelle und Befehle zum Verbindungsaufbau und -abbau sowie zur Anzeige von kommenden Rufen unterstützt werden. Fall C: Ein Szenario nach Fall C kann beispielsweise die Funktionalität eines Diktiergerätes anbieten oder das Editieren von Sprachinformationen unterstützen. Die Sprachinformation kann zur Erläuterung anderen Dokumenten (Texte, Daten usw.) dienen und wird mit diesen Objekten verbunden oder in ein Gesamtdokument eingebettet. Solche Lösungen werden angeboten, beruhen aber auf speziellen Soundkarten, und es ist eine spezielle Peripherie erforderlich. Das Endgerät Telefon in irgend einer Ausprägung seiner akustischen Oberfläche (Handset, Freisprecheinrichtung, Kopfset) wird dafür bisher nicht verwendet. Ein Szenario nach Fall C könnte aber auch E-Mail-Multimedia-Anwendungen unterstützen. Der derzeitige Trend geht zwar unter dem Einfluß eines künftigen Breitband-ISDN in Richtung Echtzeit-Multimedia-Kommunikation. Ob allerdings eine weltweite Multimedia-Echtzeitkommunikation, beispielsweise zwischen Europa und den USA oder Ostasien, aufgrund der Zeitverschiebung viele Freunde findet, ist zu hinterfragen. Viele Anrufe landen mit zunehmender Tendenz auf Anrufbeantwortern und Sprachboxen, egal ob die Teilnehmer gerade anwesend sind oder nicht. Dies ist ein Indiz dafür, daß viele ihren Arbeitsrhythmus selbst festlegen möchten, d.h. z.b. auch den Zeitpunkt, wo die Post in Gestalt von Text-, Bild- und Sprachinformationen bearbeitet wird. Bisherige Systeme sehen eine Speicherung nur am Zielort vor. Die Aufzeichnung am Entstehungsort und deren zeitversetztes Senden finden derzeit wenig Beachtung. Die menschliche Sprache ist ein bequemes und effektives Verständigungsmittel. Die derzeitigen Verfahren zur Codierung und Redundanzminderung von digitalisierter Sprache haben immer noch große Datenmengen zur Folge. Verwendet man beispielsweise eine übliche Pulscodemodulation nach ITU-G.711, sind pro Sekunde 8000 Byte zu speichern. Auf einer Festplatte mit 200 Mbyte kann man etwa 6 Std. PCM-codierte Sprache speichern. Inhaltsäquivalente Textdokumente sind in aller Regel kürzer. Ihre Herstellung ist aber dafür viel aufwendiger. Fall D: Dieses Szenario ist typisch für Anwendungen im Telemarketing, in kommerziellen Auskunftssystemen sowie in Hotel- und Notrufanwendungen usw. Der Nutzer wird üblicherweise als Agent bezeichnet und der Arbeitsplatz, bestehend aus Computer und Telefon, als Agent-Arbeitsplatz. Einzelheiten für dieses Szenario werden ausführlich im Abschnitt 3 besprochen. 3

2 Das Grundprinzip Wie in Abbildung 1 schon angedeutet wurde, kann der Funktionsverbund zwischen Telefon und Computer über ein Endgeräteinterface und/oder ein Systeminterface unterstützt werden. Unabhängig davon werden zwei Ziele angestrebt: 1. ein Fernsprechsystem soll die computerunterstütze, komfortable Herstellung, Verwaltung und Beendigung von Telefonverbindungen ermöglichen, 2. ein Computersystem soll für ein Fernsprechsystem unterstützende Funktionen bereitstellen, möglicherweise getriggert durch bestimmte Zustände einer Fernsprechverbindung. Zur Realisierung dieser Ziele werden Computersystem und Fernsprechsystem über eine spezielle Schnittstelle gekoppelt, hier Computer Supported Telephony-Interface (CST-Interface) genannt. Die jeweiligen Systeme werden der Einfachheit halber in Abbildung 2 nur durch einen Computer und einen repräsentiert. Anwendung n Anwendung 2 Anwendung 1 Ausführen von Diensten Anwendung x Anwendung b Anwendung a API Anfordern, Quittieren von Diensten API Kommunikation Interface Kommunikationsstack Kommunikationsstack Computer (V.24, X.24, BRI, andere) Abbildung 2: Das Grundprinzip einer CST-Implementation Jede CST-Implementation beruht auf einer Erweiterung der Funktionalität auf beiden Seiten. Wie dargestellt, werden auf beiden Systemen Programme installiert, die einen Anwendungsverbund unterstützen. Diese Erweiterungen sind nicht trivial. Deshalb bieten nicht alle Hersteller von Nebenstellenanlagen CST an und wenn, dann nicht für jeden Typ von. Den Anwendungsprogrammen wird zur Anforderung von Diensten (Services) ein Application Programming Interface (API) bereitgestellt. API s stellen üblicherweise folgende Dienstleistungen bereit: Lokale Verwaltungsfunktionen wie Anmelden und Abmelden von Anwendungen am Interface, Dienste zum Auf- und Abbau von Beziehungen zwischen Anwendungsprogrammen, Formulare und Regularien zum Anfordern, Anzeigen und Quittierung von Diensten. Die Quittierung kann bezüglich der Ausführung oder Nichtausführung von Diensten erfolgen, gegebenfalls mit Angabe von Ergebnissen bei der Ausführung oder Gründen bei Ablehnung. Jede der beiden Seiten kann Client oder Server sein (Abbildung 3) und für seinen Partner Dienste ausführen. Die Kommunikation zwischen den Systemen erfolgt über einen Kommunikationsstack, dessen Funktionalität auf beiden Seiten identisch sein muß. 4

Eine allgemein verwendete Methode ist die Beschreibung des jeweils diensteerbringenden Systems (Server) durch ein Modell. Diese Modelle liefern eine virtuelle Sicht auf eine reale Welt. Diese Sicht soll einfach, aber funktionell auch hinreichend mächtig sein. Zur Modellierung werden Objekte verwendet, die durch Attribute näher beschrieben werden. Objekte und deren Attribute werden durch die Dienste bestimmt, die spezifiziert werden sollen. Computer Client Dienste Objekte: Routingtabellen, Datenbanken, Telefonbücher, Hilfsprogramme Server Server Objekte: Devices, Calls, Connections Dienste Client Abbildung 3: Allgemeiner Modellierungsansatz für CST Anbieter von CST-Anwendungen und Organisationen, die sich mit der Standardisierung selbiger beschäftigen, haben für die Abbildung der Realität unterschiedliche Begriffe, unterschiedliche Ansätze und Methoden verwendet. Sieht man genauer hin, sind aber alle Modelle sehr ähnlich und lassen sich mehr oder weniger einfach ineinander überführen. Typische Objekte auf Seiten des sind: Devices: Endgeräte unterschiedlichster Art, Verbindungsleitungen usw. Calls: Kommunikationsbeziehung zwischen Devices unterschieden in Zweier- und Mehrfachgespräche mit einer endliche Anzahl von Zuständen Connections: Beziehungen eines Devices zu einem Call, beschrieben durch eine endliche Anzahl von Zuständen. Typische Objekte auf Seiten des Computers sind ausführbare Programme und Datenfiles, wie: Routingtabellen, Datenbanken, Hilfsprogramme usw. Objekte erhalten durch Attribute bestimmte Eigenschaften. Attribute lassen sich grob in drei Klassen einteilen: Identifier, wodurch Objekte unterscheidbar und steuerbar werden (Endgerät x,y,z ; Leitung i,j,k ; Call a,b,c ; Connection x,y,z ; File 1,2,3 usw.) Merkmale, wodurch die Nutzungsmöglichkeit bestimmt wird (amts-, halbamtsberechtigt, lesbar/beschreibbar, nur-lesbar usw.) Zustände, wodurch das Objektverhalten sichtbar gemacht werden kann (bereit, aktiv, wartend, verbunden, besetzt, gestört usw.). In Abbildung 4 werden typische Relationen zwischen Diensten und Objekten sowie deren Attributen für den Fall dargestellt, daß der Server ist. Die wesentlichsten Dienste, die der anbietet, sind: Dienste zur Zustandssteuerung, Dienste zur Merkmalssteuerung und Abfrage, Dienste zur Steuerung von Monitoren sowie das Monitorreporting selbst. 5

Server Objekte Identifier Identifier Identifier Merkmale Merkmale Merkmale Zustände Zustände Zustände REQUEST (ID, Dienst) RESPONSE (ID, ACK NACK) REQUEST (ID, Merkmal) RESPONSE (ID, ACK NACK) REQUEST (ID, Monitor) RESPONSE (ID, ACK NACK) REPORT (ID, Ereignis) Client Zustandssteuerung Merkmalssteuerung Merkmalsabfrage Monitorsteuerung Monitorreport Abbildung 4: Relationen zwischen Objektattributen und Diensten Am Beispiel von Computer Supported Telecommunications Applications (CSTA), einem Anwendungsverbund, der durch die ECMA standardisiert wurde [1, 2, 3], sollen exemplarisch typische Dienstgruppen und Dienste aufgeführt werden. 1. ing Function Services dienen zur Herstellung, Manipulation und zum Abbau von Gesprächsverbindungen. Insgesamt stehen bei CSTA 16 Vermittlungsdienste zur Verfügung wie beispielsweise: Make Call Service (Herstellung einer Verbindung von Tln. A zu Tln. B), Make Predictive Call Service (Tln. B wird zuerst gerufen), Consultation Call Service (entspricht einer Rückfrageverbindung), Alternate Call Service (entspricht dem Makeln), Transfer Call Service (entspricht der Rufweiterleitung), Call Completion Service (spezielle Verbindungsvollendung wenn Tln. besetzt ist). 2. Computing Function Services liefern Routing-Dienste für einen Call, wenn der zur Verbindungsherstellung mehr Informationen benötigt. Routing-Dienste sind: Route Request Service ( fordert eine Route mit bestimmten Anforderungen), Route Select Service (Computer übergibt ein Routing-Vorschlag), Re-Route Service (Anforderung eines Re-Routings, wenn Routing nicht möglich ist), Route Used Service ( übergibt an den Computer die tatsächliche Route), Route End Service (Beendigung eines Routing-Dialogs). 3. Status Reporting Services stellen Mittel zur Zustandsüberwachung von Objekten bereit. Folgende Dienste seien genannt: Monitor Start Service (aktiviert die Zustandsüberwachung für einen Call oder ein Device), Event Report Service (liefert Zustandsdaten eines Objektes) Snapshot Call Service (liefert Informationen über momentanen Zustand eines Calls), Snapshot Device Service (liefert Informationen über den momentanen Zustand der Call's, in die ein bestimmtes Device involviert ist). 4. Bi-directional Services beinhalten: Escape Service (dieser stellt einen Mechanismus für herstellerspezifische Erweiterungen von CSTA bereit), System Status Service (informelle Statusinformationen zwischen und Computer). 6

3 Die klassische Lösung C A05 Als klassische Lösung sollen die bezeichnet werden, die seit Anfang der 80-er Jahre von einigen Nebenstellenanlagen-Herstellern in Zusammenarbeit mit Rechnerherstellern entwickelt wurden. Der klassische Ansatz (Abbildung 5) besteht in der Zusammenschaltung eines Computers mit einem. Der ist üblicherweise eine digitale Nebenstellenanlage und der Computer ein sogenannter Host. Die Agentarbeitsplätze bestehen aus Terminals, die an den Host angeschlossen sind und einem Telefon. Sprachserver Computer (Host) Steuerung Terminal Terminal Agent- Plätze Sprachkanäle öffentliches Fernsprechnetz externe Teilnehmer System-CST-Interface Abbildung 5: Klassisches CST-Szenario Der dargestellte Sprachserver dient zur Speicherung und dem gezielten Abruf von Sprachinformationen. Er kann Teil der Vermittlung oder ein extra Gerät sein. Für die Steuerung der Sprachboxen ergeben sich ebenfalls mehrere Varianten. In den nachfolgend besprochenen Beispielen sei der Sprachserver ein externes Gerät mit Sprachkanalverbindungen zum. Die Steuerung erfolgt durch den Computer. 3.1 Basisfähigkeiten In Abbildung 6 sind wesentliche Basisfähigkeiten von CST dargestellt: 1. Abruf und Speicherung von Sprachinformationen Die Fähigkeit, Sprachinformationen aus einem Speicher gezielt abzurufen bzw. gezielt zu speichern, ist Voraussetzung für viele Anwendungen, wie Auskunfts-, Ansage- und Unterhaltungsdienste. Ist beispielsweise momentan kein freier Agent bei einem Kundenanruf verfügbar, kann der Kunde zum Warten aufgefordert oder um Hinterlassung seiner Rufnummer in einer Sprachbox gebeten werden. 2. Verteilung ankommender Anrufe Kunden rufen eine Bank, ein Versandhaus etc. an und wollen eine ganz bestimmte Dienstleistung abfordern. Dazu wählen sie eine bestimmte Rufnummer. Der erkennt diesen speziellen Ruf und meldet diesen an den Computer. Das auf dem Computer laufende Anwendungsprogramm wählt einen geeigneten freien Agent aus und gibt eine Anweisung an den, die Gesprächsverbindung zwischen Agent und Kunden herzustellen. Gleichzeitig kann auf dem Monitor des ausgewählten Agent-Arbeitsplatzes eine kontextbezogene Mitteilung ausgegeben werden. 7

Szenario Sprachserver (SS) öffentliches Netz Computer CST-Interface Agentarbeitsplatz Kunde Steuerung von Ansagen Auswahl der Ansage Schalte Verbindung zu Sprachbox i Meldung an Computer Kunde ruft Ansagedienst an spezieller Ruf? Aktiviere Sprachbox i SS Ansagetext Ankommender Ruf Auswahl eines Agent Schalte Verbindung zu Agent x Meldung an Computer Kundenanruf mit spezieller Nummer spezieller Ruf? gesprächsbezogene Daten Agent x Gespräch Abgehender Ruf Agent x für Gespräch mit Kunden bereit Kunde y Agent frei oder in n sec. frei? Rufe den Kunden y an Auswahl eines Agent Schalte Verbindung zu Agent x Kunde y hat sich gemeldet gesprächsbezogene Daten Agent x Gespräch Abbildung 6: Basisfähigkeiten von CST 3. Steuerung abgehender Rufe Diese Fähigkeit wird vor allem beim Telemarketing benötigt. Hier werden potentielle Kunden, vom Computer gesteuert, angerufen. Diese Anrufe werden initiiert, wenn sich ein Agent bei der Applikation angemeldet hat oder ein Agent in einer bestimmten Zeit mit einer bestimmten Wahrscheinlichkeit frei wird. Die Agents werden von der manuellen Herstellung der Gesprächsverbindungen entlastet. Das Arbeitsvermögen selbiger 8

wird dadurch besser genutzt, da Wahl- und Rufzeiten, bzw. Besetztzustände oder das Nichtmelden von Teilnehmern ihre Zeitfonds nicht belasten. Nach dieser Übersicht zum Prinzip und Grundeigenschaften von CST werden Anwendungen besprochen. In [1] werden u.a. folgende angegeben: Unterstützung beim Telefonieren, Telemarketing, Kundenauskunftssystem, Notrufanwendungen, Datensammlung und -verteilung. 3.2 Anwendungen 3.2.1 Telemarketing Telemarketing-Applikationen unterstützen Kundenbetreuer (als CST-Nutzer) bei der Herstellung von Telefongesprächen. Abbildung 7 zeigt typische Interaktionen bei der Bearbeitung von ankommenden Rufen, die am Beispiel einer Bank näher erläutert werden. Agent- A rbeitsplatz Computer CST- Schnittstelle öffentliches Netz Terminal Sprachendgerät CST- Computerfunktion CST- funktion Kunde Vorbereitung der CIT- Sitzung Anmeldung des Agents Überwachung für bestimmte Anrufe einschalten aktualisiere Bildschirm Meldung (ankommender Ruf) ankommender Ruf Bearbeitung des Kundenanrufes Nachbearbeitungsphase Aktivzeit Rechnerterminal Aktivzeit Telefon aktualisiere Daten; Nachbearbeitung Freimeldung des Agents Tln. A nimmt Ruf an Meldung (Verbindung hergestellt) Gespräch Kunde - Agent Meldung (Tln. B ausgelöst) Kunde legt auf Bearbeitung des nächsten Kundenkontakts Abbildung 7: CST-Szenario für einen ankommenden Ruf Bei Arbeitsbeginn erfolgt die Anmeldung der Kundenbetreuer (Agents) beim Computer der Bank. Daraufhin fordert die CST-Computerfunktion bei der CST-funktion die Überwachung bestimmter Anrufe an. Ab diesem Zeitpunkt wird der Computer über bestimmte vermittlungstechnische Ereignisse informiert. Ein Kunde ruft an und möchte beispielsweise einen Überweisungsauftrag auslösen. Er wählt die Rufnummer der Bank und identifiziert sich z.b. durch die Verwendung einer speziellen Rufnummer oder Rufnummererweiterung (Suffix). Kommt dieses Gespräch in der Nebenstel- 9

lenvermittlung der Bank an, wird der Computer über die CST-Schnittstelle von der Vermittlung darüber informiert. Er identifiziert den Kunden anhand dessen Kennung und sucht die Kundendaten (Name, Konto-Nr., Guthaben, Kontobewegungen, Kredite...) aus einer Datenbank. Der Computer ermittelt einen freien und kompetenten Agent, aktualisiert dessen Bildschirm mit den Kundendaten und weist den an, das ankommende Gespräch mit der Sprechgarnitur des ausgewählten Agents zu verbinden. Mit dieser Methode wird eine konkrete und individuelle Betreuung des Kunden ermöglicht und unnötige Rückfragen sowie Weiterleiten von Gesprächen vermieden. Nach Beendigung des Gespräches bearbeitet der Agent die Kundendatei und meldet dann dem Computer seine Bereitschaft für den nächsten Kundenkontakt. Da die komplette Sprach-Daten-Transaktion wie ein Gespräch (integrierte Anwendung) behandelt wird, kann sie an einen anderen Agent übergeben und Rückfragen oder Konferenzschaltungen realisiert werden. Dabei haben alle Bearbeiter die Kundendaten auf dem Monitor und können z.b. unabhängig im Datenbestand blättern. Ein weiteres Anwendungsprofil ist die Kundenbetreuung in einem Kauf- oder Versandhaus. Will ein Kunde z.b. in einem Kaufhaus eine Bestellung aufgeben, erfolgt die Bearbeitung des Anrufes und die Zuweisung zu einem Agent wie im ersten Beispiel. Werden vom Computer des Kaufhauses die Kaufaktivitäten des Kunden über einen längeren Zeitraum verfolgt, so ist es anhand des Kaufprofils des Kunden und der Angebotspalette des Kaufhauses möglich, dem Kunden Angebote, z.b. über neue Produkte, zu unterbreiten. Hat das Anwendungsprogramm auf dem Computer ein Produkt herausgefunden, an dem der Kunde Interesse haben könnte, so weist er den an, eine Telefonverbindung zu diesem Kunden aufzubauen und bei Erfolg einem Agent zuzuweisen. Dieser Agent bekommt dann auf seinem Terminal die notwendigen Daten angezeigt, um dem Kunden das entsprechende Angebot unterbreiten zu können. Für ein abgehendes Gespräch ist der versuchsweise Verbindungsaufbau (Predictive Dialing) ein wichtiges Leistungsmerkmal. Hierbei wird auf dem Computer eine Anwendung ausgeführt, die nacheinander die Kunden, z.b. eines Versandhauses, aus einer Telefonliste heraus anruft. Kunden, die nicht erreicht werden können, werden dabei wieder neu in die Liste aufgenommen. Das Predictive Dialing bedeutet dabei, daß der Computer die Rufe initiiert, ohne daß momentan ein Agent zugewiesen ist, aber in der Annahme, daß bei einer Antwort des Kunden ein geeigneter Agent verfügbar sein wird. Sollte das nicht der Fall sein, wird der Kunde mit einer Voice Mail Box des Sprachservers verbunden, die Vorabinformationen liefert oder erfragt. Ein freiwerdender Agent erhält dann das Gespräch, gemeinsam mit Kundendaten, die auf dem Display angezeigt werden. Neben einer effektiven Kundenbetreuung liefert diese Anwendung, wie bereits erwähnt, auch eine effektive Auslastung der Agents, da erfolglose Verbindungsversuche nur den Computer und den belasten, nicht aber den Mitarbeiter. 3.2.2 Sicherheits- und Notruf-Anwendungen Sicherheit für Personen, Gebäude, Einrichtungen ist ein wichtiges Gut. Der Markt für solche Anwendungen wird stark expandieren. Ein typisches Szenario wird nachfolgend vorgestellt. Mittels einer aus der Datenbasis erstellten Liste von Rufnummern und in einer Sprachbox ab- 10

gespeicherten Sprachnachrichten werden in Abhängigkeit von der konkreten Art eines Alarmfalles bestimmte Rufnummern angerufen (Polizei, Feuerwehr usw.) und ausgewählte Sprachnachrichten gesendet. Diese Sprachnachrichten können beispielsweise im Falle eines Brandes Informationen über den zu wählenden Anfahrtsweg, über Besonderheiten bei der Brandbekämpfung usw. geben (Abbildung 8). Szenario Computer Notrufdienste Sprachserver (SS) Sensoren Aktoren CST-Interface öffentliches Netz Polizei, Feuerwehr, Wachdienste Was ist zu tun? Alarm x Rufe i an oder Alarm x Alarm x Polizei, Feuerwehr, Wachdienste i hat sich gemeldet Schalte Verbindung zu Sprachbox Aktiviere Sprachbox für Ansagen x, y, z SS Ansagetext(e) Abbildung 8: Notrufanwendungen und Sicherheitsdienste 3.2.3 Einfache Datendienste Gewöhnliche Telefonapparate können genutzt werden, um kleine Datenmengen über den und die CST-Schnittstelle an den Computer zu übergeben. Falls das Fernsprechendgerät über ein Display verfügt, kann dies zur Eingabesteuerung oder Hinweisgabe genutzt werden (Abbildung 9). Das Telefon als Terminal wird durch ein Anwendungsprogramm in der Vermittlung unterstützt. Dieses sammelt eingegebene Daten bis zu einer vereinbarten Menge oder Endekennung. Dann werden diese Daten über das CST-Interface zu einer Computerapplikation transferiert. 11

Szenario C A05 Computer digitale Telefone mit Anzeige CST-Interface Einfache Datendienste Tln. fordert Datendienst k an ACK (NACK) berechtigt? Festplatte Daten an Computer Zeige auf dem Display an (...) Dateneingabe Anzeige (...) Abbildung 9: Realisierung einfache Datendienste Diese Fähigkeit schafft eine breite Palette von möglichen Anwendungen, z.b.: Hotel: Informationen über den Raumzustand, Minibar, Belegung, Fortschritt der Reinigungsarbeiten etc., werden vom Personal per Telefon an den Computer übertragen. Damit ist jederzeit ein Überblick über den Zustand der Zimmer gegeben. Krankenhaus: Über die im Krankenzimmer befindlichen Telefonapparate können Informationen zu Arzneimittelgaben oder Patientendaten eingegeben werden. Sicherungssystem: Ein Wachdienst hat einen festgeschriebenen Weg- und Zeitplan durch mehrere Objekte einer Einrichtung einzuhalten. Dieser Plan ist im Anwendungsprogramm eines Computer abgespeichert, und dieses erwartet zu bestimmten Zeiten Meldungen des Wachdienstes von bestimmten Telefonapparaten. Ist eine Meldung überfällig, kann ein Alarm ausgelöst werden. Der Wachdienst kann vermittels einer Dateneingabe über das Telefon Informationen über den Zustand der Objekte liefern. Das Anwendungsprogramm auf dem Computer kann verschiedene Wegepläne benutzen und dem Wachdienst die nächsten anzulaufenden Objekte per Display- oder Sprachnachricht mitteilen. Rufe von externen Teilnehmern können vom Computer gesteuert auf den nächsten anzulaufenden Apparat umgeleitet werden. 12

4 PC-basierte Lösungen C A05 Klassische Lösungen (siehe Abbildung 5) bestehen aus einem mit CST-Funktionalität und einem Host. Die CST-Anwendung auf dem Host wird durch Softwarehäuser und Rechnerhersteller in Absprache mit dem -Hersteller entwickelt. Bisherige Anwendungen waren zumeist größeren Projekten vorbehalten, vorzugsweise im Bereich Handel und Finanzwirtschaft. In den letzten zwei Jahren ist hier einiges in Bewegung geraten. Microsoft und Intel spezifizierten für das Betriebssystem Windows ein Interface für Telefonieanwendungen und Novell, als Marktführer für Netzsoftware in der DOS-Welt, spezifizierte gemeinsam mit AT&T ein CST-Client/Server-Interface für novellbasierte PC-Netze. Voraussetzung und Antrieb für diese Aktivitäten sind: die fortgeschrittene internationale Standardisierung von CST (z.b. SCAI, CSTA, TASC, diverse Firmenstandards), die zunehmende Rechnervernetzung, die Fähigkeit zur Bereitstellung von digitalen Kanälen durch ISDN-Komponenten, die Möglichkeiten, die sich aus diesem Verbund für die Anwender ergeben. Im folgenden soll auf die Novell/AT&T - und Microsoft/Intel-CST-Konzepte eingegangen werden. 4.1 Novell /AT&T -Ansatz Ziel dieser Aktivitäten ist die Bereitstellung von CST in PC-Netzen unter dem Novell-Netzwerkbetriebssystem NetWare. In Abbildung 10 sind das Grundszenario und die wesentlichen Komponenten auf Seiten der Clients und des Servers dargestellt. Clients LAN Client-Applikation CSTA-Client API NetWare Windows, Macintosh OS, IBM OS/2 basierend auf NetWare Telefon-Server Server-Applikation CSTA-Server API Telefonie-Server NetWare Loadable Module Server firmenspezifisches CST-Interface -Treiber Mapping auf firmenspez. CST, Protokollstack Interface zum treiber Abbildung 10: Novell/AT&T-Ansatz 13

In einem Novell-Netz kann es mehrere Server geben (Fileserver, Faxserver usw.). Der Server, der CST-Anwendungen unterstützt, wird Telephony Server genannt. Der in Abbildung 10 dargestellte Lösungsansatz hat folgende Merkmale: CST-Applikationen können sowohl auf Clients aber auch auf dem Server ablaufen. Läuft die Applikation auf dem Server, liegt der klassische Fall vor. Client-API und Server-API sind identisch, und beide basieren auf dem CSTA-Standard der ECMA [1,2,3]. Der API wird in [4] spezifiziert. Im Falle von Client-Anwendungen realisiert das LAN den Transport von Dienstanforderungen und Quittungen zwischen Client und Server. Der Telephony Server realisiert die Verbindung zum über das CST-Interface. Der treiber ist das Kernstück dieser Lösung. Er bekommt über ein Interface die CSTA-basierten Dienstanforderungen. Diese setzt er in die switchtypischen CST- Befehle um (Mapping). Die switchtypischen Meldungen werden auf entsprechende CSTA-Meldungen abgebildet. Das Interface zum treiber ist offen gestaltet, d.h., daß jeder an dieses Konzept angepaßt werden kann, indem der konkrete -Treiber geschrieben wird und das durch den unterstützte CST auf CSTA-Dienste abbildbar ist. Abbildung 11 verdeutlicht das Prinzip. Vermittels des Dienstelementes cstamakecall( ), wird von einer Client-Anwendung die Herstellung einer Zweierverbindung zwischen dem Teilnehmer A und B angefordert. Diese Dienstanforderung wird im Server auf das Dienstelement Verbinde ( ) gemappt. Der überprüft die Anforderungen auf Richtigkeit und Durchführbarkeit und antwortet im Positivfall mit der Meldung IchVersucheEs. Diese Meldung wird auf die, bei CSTA vorgesehene, in diesem Fall CSTAMakeCallConfEvent, abgebildet. Die Meldung CSTAOriginatedEvent, die vom Server zum Client gesendet wird, hat in diesem Fall keine Entsprechung auf der Server--Seite. Dies weist darauf hin, daß der Server in der Realität nicht nur einfache Abbildungen von Diensten und Meldungen realisieren muß, sondern teilweise auch sehr komplexe Verarbeitungsleistungen erbringen muß, um die Anpassung zwischen CSTA und dem konkreten CST auf dem zu ermöglichen. Client Server cstamakecall ( ) Mapping CSTA-CSTx Verbinde ( ) CSTAMakeCallConfEvent Mapping CSTx-CSTA IchVersucheEs CSTAOriginatedEvent CSTADeliveredEvent CSTAEstablishedEvent Mapping CSTx-CSTA Mapping CSTx-CSTA EsRuft VerbindungHergestellt Abbildung 11: Einfacher Dienstablauf 14

4.2 Microsoft/Intel-Ansatz Klassische Lösungen und auch der Novell/AT&T-Ansatz verfolgen überwiegend das Ziel, sogenannte Third-Parties (3P) zu unterstützen. Der Microsoft/Intel-Ansatz zielt vordergründig auf die Unterstützung von First-Parties (1P). First-Party (1P): Das Endsystem oder die Anwendung, welche den Aufbau einer Verbindung anfordert und steuert, ist auch der Nutzer dieser Verbindung (Abb. 12). Third-Party (3P): Das Endsystem oder die Anwendung, die den Aufbau einer Verbindung anfordert und steuert, tut dies für einen Dritten, den Nutzer der Verbindung. X 1Party connect_in (X) Y connect_rq (X) connect_rs (X) connect_cf (X) Z Kommunikation zwischen Y und X 3Party connect_in (X) connect_rs (X) connect_in (Y) connect_rq (X,Y) connect_rs (X) Kommunikation zwischen Y und X Abbildung 12: Unterschied zwischen First-Party und Third-Party-Call Es sei angemerkt, daß alle vorgestellten Lösungen im Prinzip beide Nutzungen unterstützen, vordergründig aber schon spezialisiert sind. Microsoft will hauptsächlich die Steuerung von Kommunikationsverbindungen für Sprache, Daten, Fax für unterschiedliche Anschlußarten (a/b, ISDN usw.) aus einer Windows-Applikation heraus unterstützen. Zur Erreichung dieses Zieles wird die Windows Open Service Architecture WOSA angewendet, die Ende 1992 öffentlich gemacht wurde. WOSA basiert auf zwei Programmierschnittstellen, dem API (Application Programming Interface) und dem SPI (Service Provider Interface). Das API definiert, welche Dienste eine Applikation nutzen kann. Das zugehörige SPI definiert die Dienste, die ein Service Provider unterstützen muß. Auf diese Weise gelingt es, daß Dienste, angeboten über ein API, durch unterschiedliche Dienstanbieter, auf verschiedene Art und Weise realisiert werden können. Die Verbindung zwischen API und SPI wird durch eine entsprechende Dynamic Link Library (DLL) hergestellt. Microsoft spezifizierte bisher verschiedene API s, beispielsweise WAPI (Wave API), MAPI (Messaging API) und TAPI (Telephony API) und die zugehörigen SPI s (WSPI, MSPI, TSPI). In Abbildung 13 ist die WOSA am Beispiel von TAPI und TSPI dargestellt. 15

Windows Telephony Application x Windows Telephony Application z Telephony API WINDOWS TAPI.DLL Telephony SPI Windows Open Service Architecture COM Telephony Service Provider a Provider b ISDN-PC-Card COM Provider c Line Line Modem Line Abbildung 13: WOSA am Beispiel Telefonie Mit diesem Konzept sollen unterschiedliche Anwendungsszenarien unterstützt werden. Eine Auswahl ist in Abbildung 14 zusammengestellt. Die telefonbasierte Variante könnte beispielsweise die Steuerung von Telefonverbindungen über eine V.24-Schnittstelle unterstützen. Bei der PC-basierten Variante erfolgt die Verbindungssteuerung über eine PC-Karte. Je nach Karte kann man Sprach-, Fax-, Datenübertragungs-, Btx-Dienste usw. realisieren. Mit dem Client/Communication-Server-Konzept kann man von Clients aus im Server zentralisierte Kommunikationszugänge (Modem-Pool, Fax-Server, Btx-Server usw.) nutzen. Das to-host-link-szenario stellt wieder den klassischen Fall für CST-Applikationen dar. Phone-Centric / Network PC-Centric Client/Communication-Server Client -to-host-link Client Server Server Tln.-Leitungen für Fax, Daten, Sprache / Network CST-Interface Abbildung 14: Anwendungsszenarien für Windows Telephony 16

Die TAPI-Dienste sind eingeteilt in Assisted Telephony und Telephony. Assisted Telephony stellt einfache Mechanismen zur Herstellung von Verbindungen für ein Telefon oder ein Modem bereit. Die Annahme und Manipulation von Verbindungen ist damit nicht möglich. Folgende Dienste werden am Assisted TAPI angeboten [5]: tapirequestmakecall: Anforderung einer Telefonverbindung tapirequestmediacall: Anforderung einer Fax-, Daten-, Btx-Verbindung. Der Vollzug oder Fehler werden über eine TAPY_REPLY-Message zurückgegeben. Man beachte, daß die Nutzung der hergestellten Verbindung über einen entsprechenden API erfolgt, aber nicht über TAPI. tapirequestdrop: Beendigung der mit tapirequestmediacall angeforderten Verbindung. Am Telephony API werden folgende Dienstgruppen unterstützt: Dienste zur Anmeldung, Abmeldung, Versionseinstellung bzw. -abfrage am API, Dienste zum Herstellen, Manipulieren und Beenden von Calls, Dienste zur Beobachtung von Calls. Eine ausführliche Beschreibung ist in [5,6] enthalten. Die Dienste werden bezüglich der Devices, auf welche sie anwendbar sind, unterschieden. Es wurden die Devices Phone und Line spezifiziert. Ein Line Device ist beispielsweise ein Modem, eine ISDN-PC-Karte, ein Fax-Karte usw. Das Phone Device kann aus TAPI-Sicht aus einigen oder allen der nachfolgend aufgeführten Elemente bestehen: Hookswitch/Transducer: Handset, Freisprecheinrichtung, Kopfset/ Gabelumschalter in irgend einer Form, Volume Control/ Gain Control/ Mute: Steuerung der Hörerlautstärke/ der Mikrofonverstärkung/Stummschaltung, Ringer, Display: charakterisiert durch die Anzahl der Zeilen und Spalten, Buttons/Lamps: eine Anzahl von Tasten, und Anzeigen. Computerunterstützte Telefonie war bisher eher eine exotische Anwendung. Mit den PC-basierten Lösungen wird sich dies schnell und nachhaltig ändern. Hersteller von Nebenstellenanlagen, auch kleiner Baustufen, sowie Hersteller von Telefonen und PC-Karten sollten diesem Trend die notwendige Beachtung schenken. 5 Quellenverzeichnis [1] ECMA TR/52: Computer Supported Telecommunications Applications, June 1990 [2] Standard ECMA-179: Services for CSTA, June 1992 [3] Standard ECMA-180: Protocol for CSTA, June 1992 [4] AT&T: API Definition and Specification for the R1.0 NetWare Telephony Server, Preliminary DRAFT Issue 1.3, March 1993 [5] Intel/Microsoft: Windows TM Telephony API, May 1993 [6] Intel/Microsoft: Windows TM Telephony SPI, May 1993 Autor: Prof. Dr.-Ing. habil. Lutz Winkler HTW Mittweida (FH), Fachbereich Elektrotechnik 09648 Mittweida, Technikumplatz 17 03727/ 58-1290 FAX 03727/ 58-1420 MAIL win@htwm.de 17