DE60008483T2

DE60008483T2 - Telefondiensten in einem Kommunikationsnetzwerk

Info

Publication number: DE60008483T2
Application number: DE60008483T
Authority: DE
Inventors: Larry Dolinar; Jinchi Chu; Michel Kallas
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1999-11-09
Filing date: 2000-10-16
Publication date: 2004-06-24
Anticipated expiration: 2020-10-17
Also published as: US20050080905A1; US7433954B2; EP1102498B1; EP1102498A2; EP1102498A3; DE60008483D1

Description

Die Erfindung bezieht sich auf die Bereitstellung von Telefoniediensten in Kommunikationsnetzen.
Datennetze werden in weitem Umfang zur Verbindung verschiedener Arten von Knoten verwendet, wie z. B. Personalcomputern, Servern, Überleiteinrichtungen, Netzwerk-Telefonen, usw. Netzwerke können private Netze, wie z. B. Ortsbereichsnetze und Weitbereichsnetze und öffentliche Netze, wie z. B. das Internet einschließen. Die gestiegene Verfügbarkeit derartiger Datennetze hat die Zugänglichkeit zwischen Knoten verbessert, die mit den Datennetzen verbunden sind. Populäre Formen von Kommunikationen über derartige Datennetze hinweg schließen elektronische Post, Dateiübertragung, die Suche im weltweiten Datennetz und andere Austauschmöglichkeiten von digitalen Daten ein.
Mit der zunehmenden Kapazität und Zuverlässigkeit von Datennetzen wurden Sprache- und Multimedia-Kommunikationen über Datennetze möglich. Derartige Formen von Kommunikationen schließen Telefongespräche über die Datennetze, Videokonferenzen und die Verteilung von Multimedia-Daten (beispielsweise durch Sammelsendung) ein.
Es wurden verschiedene Normen für Sprache- und Multimedia-Kommunikationen über Datennetze vorgeschlagen. Beispielsweise wurde eine Multimedia-Daten- und Steuerarchitektur von der Internet Engineering Task Force (IETF) entwickelt. Die Protokolle, die einen Teil der IETF-Multimedia-Daten- und Steuerarchitektur bilden, schließen ein Sitzungs-Initialisierungsprotokoll (SIP) zum Aufbau von Gesprächssitzungen, ein Ressourcen-Reservierungsprotokoll (RSVP) zur Reservierung von Netzressourcen; ein Echtzeit-Transportprotokoll (RTP) zum Transport von Echtzeitdaten und zur Lieferung einer Dienstgüte- (QoS-) Rückführung; ein Echtzeit-Datenstromprotokoll (RTSP) zur Steuerung der Zustellung von Medien-Datenströmen; ein Sitzungsankündigungsprotokoll (SAP) zur Ankündigung von Multimedia-Sitzungen durch Sammelsendung; und ein Sitzungsbeschreibungsprotokoll (SDP) zur Beschreibung von Multimedia-Sitzungen ein. In einem Kommunikationssystem, das Sprache- oder andere Datenstrom-Kommunikationen bereitstellt, kann es erforderlich sein, verschiedene Arten Telefonie- oder Gesprächsdiensten zu definieren, um Verbindungs- oder Gesprächsanforderungen zu verarbeiten und auf diese anzusprechen. Ein Kommunikationsnetz kann verschiedene Elemente, wie z. B. ein Sprachpostsystem, ein integriertes Sprachantwort-(IVR-)System, Medien-Überleiteinrichtungen usw. einschließen, die an einer vorgegebenen Gesprächssitzung beteiligt sind. Die Schaffung von Anwendungen zur Abwicklung verschiedener Dienste, die einen Teil einer Gesprächssitzung sein können, muss Wechselwirkungen zwischen den Netzwerkelementen berücksichtigen. Daher besteht ein Bedarf an einem zweckmäßigen und effizienten Verfahren und einer Vorrichtung zur Bereitstellung von Telefoniediensten in einem Kommunikationsnetzwerk.
Die WO 99/20058, Alcatel, offenbart ein Verfahren zur Verwendung in einem Kommunikationsnetz, das Netzwerkelemente zur Durchführung von Telefoniediensten aufweist, mit den folgenden Schritten: Bereitstellung einer Schnittstelle zu den Netzwerkelementen; Empfang von Anforderungen durch die Schnittstelle, Festlegen des Betriebsverhaltens von Telefoniediensten; und Senden von Befehlen an eines oder mehrere Netzwerkelemente, die bei der Ausführung der gewünschten Telefoniedienste beteiligt sind, als Antwort auf derartige Anforderungen.
Die vorliegende Erfindung ist dadurch gekennzeichnet, dass die Anforderungen von einem Software-Modul empfangen werden, und dass die Befehle über ein Paketbasiertes Netzwerk ausgesandt werden.
Einige Ausführungsformen der Erfindung können einen oder mehrere der folgenden Vorteile haben. Es wird ein effizienteres und bequemeres Verfahren und eine effizientere und bequemere Vorrichtung zur Schaffung oder Erzeugung von Telefoniediensten in einem Kommunikationsnetzwerk geschaffen. Eine Technik wird bereitgestellt, um Realisierungseinzelheiten von Bauteilen (beispielsweise in Form von Netzwerkelementen) zu abstrahieren, die verschiedene Telefoniedienste durch Software-Routinen, Module oder Skripten ausführen, die von Benutzern geschaffen werden, um Telefoniedienste bereitzustellen. Eine derartige Abstraktion ermöglicht einen wesentlich effizienteren Mechanismus zur Schaffung von Telefoniediensten.
Weitere Merkmale und Vorteile werden aus der folgenden Beschreibung, aus den Zeichnungen und den Ansprüchen ersichtlich.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockschaltbild einer Ausführungsform eines Kommunikationssystems, das paketbasierte Datennetze einschließt.
2 zeigt Schichten, die die Architektur eines Telefoniesystems gemäß einer Ausführungsform darstellen.
3 ist ein Blockschaltbild, das eine alternative Ansicht von Komponenten des Kommunikationssystems nach 1 zeigt.
4 erläutert einen Prozess zur Schaffung und Ausführung von Telefoniediensten in dem Kommunikationssystem nach 1 gemäß einer Ausführungsform.
5A bis 5B bilden ein Zustandsdiagramm eines Ausführungsbeispiels eines Softwaremoduls, das einen Sprachpostabfragedienst bereitstellt.
6 ist ein Blockschaltbild einer weiteren Ausführungsform eines Systems, das CORBA- (Common Object Request Broker Architecture-) Komponenten und ein Software-Modul zur Realisierung von Telefoniediensten enthält.
7 ist ein Blockschaltbild eines integrierten Sprachausgabe- (IVR-) Systems, das einen Objektanforderungs-Vermittler (ORB) gemäß einem Ausführungsbeispiel einschließt.
8 ist ein Blockschaltbild von Komponenten eines Netzwerkelementen-Beispiels in dem Kommunikationssystem nach 1.
Ausführliche Beschreibung
Gemäß 1 schließt ein Kommunikationssystem 10 verschiedene Knoten oder Netzwerkelemente ein, die in der Lage sind, miteinander zu kommunizieren. Die Beispiele der Netzwerkelemente und die Art und Weise, wie sie miteinander verbunden sind, dienen lediglich zu Erläuterungszwecken. Viele andere Anordnungen und Architekturen sind in weiteren Ausführungsformen möglich.
Das Kommunikationssystem 10 kann ein privates Netz 21, das sich in einer Gemeinschaft 20 befindet, und ein öffentliches Netz 12 (beispielsweise das Internet) einschließen. Eine „Gemeinschaft" kann sich auf irgendeine vorgegebene Gruppe von Elementen oder Benutzern beziehen, die über ein Netzwerk miteinander verbunden sind. Ein „privates Netzwerk" bezieht sich auf ein Netzwerk, das gegen einen nicht autorisierten allgemeinen Zugang geschützt ist. Ein „Netzwerk" oder „Netz" kann sich auf ein oder mehrere Kommunikationsnetze, Verbindungsstrecken, Kanäle oder Pfade sowie auf Routen oder Überleiteinrichtungen beziehen, die zur Weiterleitung von Daten zwischen Elementen über derartige Netzwerke, Verbindungsstrecken, Kanäle oder Pfade verwendet werden. Obwohl in dieser Beschreibung auf „private" und „öffentliche" Netze Bezug genommen wird, können weitere Ausführungsformen Netze ohne derartige Bezeichnungen oder Festlegungen einschließen. Beispielsweise kann sich eine Gemeinschaft auf Knoten oder Elemente beziehen, die über ein öffentliches Netz oder eine Kombination von privaten und öffentlichen Netzen miteinander gekoppelt sind.
Bei einer Ausführungsform kann das in den verschiedenen Netzen verwendete Protokoll das Internetprotokoll (IP) sein, wie es in der Kommentaraufforderung (RFC) 791 mit dem Titel „Internet Protocol" vom September 1981 beschrieben ist.
Andere Versionen von IP, wie z. B. IPv6 oder andere Paket-basierte Normen können ebenfalls in weiteren Ausführungsformen verwendet werden. Eine Version von IPv6 ist im RFC 2460 mit dem Titel „Internet Protocol, Version 6-(IPv6-) Specification) vom Dezember 1998 beschrieben. Paketbasierte Netze, wie z. B. IP-Netze kommunizieren mit Paketen, Datagrammen oder anderen Dateneinheiten, die über die Netze ausgesandt werden. Im Gegensatz zu leitungsvermittelten Netzen, die eine dedizierte Ende-zu-Ende-Verbindung oder einen physikalischen Pfad für die Dauer einer Verbindungssitzung bereitstellen, ist ein Paket-basiertes Netz ein Netz, bei dem der gleiche Pfad von verschiedenen Netzwerkelementen gemeinsam genutzt werden kann.
Ein paketbasiertes Netzwerk kann ein paketvermitteltes Netzwerk, wie z. B. ein IP-Netzwerk sein, das auf einer verbindungslosen Verbindungsnetz-Schicht beruht. Pakete oder andere Dateneinheiten, die in ein paketvermitteltes Datennetz eingeleitet werden, können unabhängig über irgendein Netz (und möglicherweise über unterschiedliche Netze) zu einem Ziel-Endgerät wandern. Die Pakete können sogar in einer geänderten Reihenfolge ankommen. Die Leitweglenkung von Paketen beruht auf einer oder mehreren Adressen, die in jedem Paket übertragen werden. Andere Arten von paketbasierten Netzen schließen verbindungsorientierte Netze, wie z. B. asynchrone Übertragungsbetriebsart-(ATM-)Netze oder Frame Relay-Netze ein, die auf einem virtuellen Verbindungsmodell beruhen.
Die Gemeinschaft 20 kann Knoten oder Elemente einschließen, die es Benutzern ermöglichen, an Audio-(beispielsweise Sprache-) und Multimedia-(beispielsweise Audio- und Video-)Kommunikationssitzungen teilzunehmen. Beispiele derartiger Kommunikationssitzungen schließen Telefongespräche, Videokonferenzen und andere Sitzungen ein, bei denen Datenströme ohne Unterbrechung ausgetauscht werden. In dieser Beschreibung werden derartige Kommunikationssitzungen als Telefonie- oder Gesprächssitzungen bezeichnet. Verschiedene Telefonie- oder Gesprächsdienste können in einer Telefonie-Sitzung ausgeführt werden. Beispielsweise kann eine Ankündigung abgespielt werden, eine Mitteilung kann aufgezeichnet werden, ein Ton kann abgespielt werden, die Detektion eines Zweiton-Mehrfrequenz-(DTMF-)Signals kann ausgeführt werden, ein Gespräch kann von einem Endgerät zu einem weiteren Endgerät weitergeleitet werden, eine aufgezeichnete Sprache-Mitteilung kann rückgewonnen werden, usw. Ein „Telefoniedienst" kann als irgendeine Aktion oder ein Dienst definiert werden, der einer Telefonie- oder Gesprächssitzung zugeordnet ist.
Eine „Telefonie-Sitzung" oder eine „Anruf-Sitzung" bezieht sich allgemein auf entweder eine Audio- (beispielsweise Sprache-) Sitzung, eine Multimediasitzung oder irgendeine andere Art von Sitzung, bei der ununterbrochene Datenströme zwischen zwei oder mehr Netzwerkelementen oder Endgeräten ausgetauscht werden, die mit einem Datennetz gekoppelt sind. Eine „interaktive" Telefonie- oder Anruf-Sitzung bezieht sich auf eine Telefonie- oder Anruf-Sitzung, bei der zwei oder mehr Parteien an einem Austausch von Audio- und/oder Videodaten in einer eingeleiteten Sitzung zwischen zwei oder mehr Netzwerkelementen beteiligt sind. Eine interaktive „Echtzeit"-Telefonie- oder Anruf-Sitzung bezieht sich auf einen Austausch von Daten im Wesentlichen auf Echtzeit-Basis zwischen zwei Endgeräten. Eine Sitzung erfolgt im Wesentlichen in Echtzeit, wenn eine Wechselwirkung zwischen zwei Endpunkten oder Teilnehmern erfolgt, wobei eine Kommunikation von einem Endpunkt relativ schnell von einer Antwort oder einer anderen Kommunikation von dem anderen Endpunkt gefolgt wird, typischerweise innerhalb von Sekunden, um ein Beispiel zu nennen.
Interaktive Anruf-Sitzungen stehen beispielsweise im Gegensatz zu elektronischen Post-Mitteilungen, bei denen ein erster Teilnehmer eine Mitteilung über ein Datennetz an einen zweiten Teilnehmer sendet, wobei üblicherweise keine Bestätigungsanzeige zurück an den ersten Teilnehmer dafür geliefert wird, dass der zweite Teilnehmer empfangen hat oder dass sich der zweite Teilnehmer sogar an seinem oder ihrem Endgerät befindet. Im Gegensatz hierzu beinhaltet eine interaktive Sitzung eine Anforderung, auf die eine gewisse Bestätigung folgt, dass ein angerufener Teilnehmer die Anrufaufforderung beantwortet hat, um die Herstellung der interaktiven Sitzung zu ermöglichen, in der die Teilnehmer Daten austauschen (beispielsweise Sprache, Video und/oder Text). Die Ausdrücke „Telefonie-Sitzung" und „Anruf-Sitzung" werden hier austauschbar verwendet.
Gemäß einiger Ausführungsformen schließt eine Architektur oder ein Rahmenwerk für die Schaffung von Telefoniediensten und Anwendungen für Telefonie-Sitzungen über paketbasierte Netze, wie z. B. ein IP-Netz, eine untere Schicht, die Netzwerkelemente zur Durchführung von Telefoniediensten einschließt, eine obere Schicht, die Softwaremodule einschließt, in denen Telefoniedienste dargestellt sind, und eine Schnittstellenschicht (oder Middleware-Schicht) zwischen den oberen und unteren Schichten ein. Die Schnittstellenschicht kann zur Abstrahierung der Funktionalität der Netzwerkelemente verwendet werden, die einen Teil des Kommunikationssystems 10 bilden. Dies ermöglicht eine zweckmäßige Technik zur Schaffung von Software-Modulen zur Bereitstellung von Telefoniediensten, weil ein Software-Entwickler Code oder Skripten schaffen kann, um Telefoniedienste bereitzustellen, ohne dass er sich um die Realisierungseinzelheiten (Standort des Gerätes, Programmiersprache, usw.) von Geräten kümmern muss, die den angeforderten Dienst tatsächlich ausführen. Bei der Architektur oder bei dem Rahmenwerk gemäß einiger Ausführungsformen wird eine gemeinsame Schnittstellenschicht zwischen mehrfachen Diensten in der oberen Schicht (Software-Module) und mehrfachen Netzwerkelementen in einer unteren Schicht bereitgestellt.
Das Vorhandensein der oberen Schicht zur Bereitstellung von Telefoniediensten erstreckt in Netzelementen verfügbare Merkmale über einfache Anrufdienste hinaus, um eine Rufweiterleitung, eine Konferenzschaltung, eine Weiterleitung und andere Telefoniedienste einzuschließen, die Benutzer wünschen können. Jedes Software-Modul schließt Elemente ein, die verschiedene auszuführende Telefoniedienste darstellen. Derartige Elemente können Subroutinen, Verfahren, Objekte oder irgendein anderes Element sein, die vom Benutzer geschaffen werden können. Beispielsweise kann das Software-Modul allgemein in Form von Zustandsdiagrammen mit kundenspezifisch anpassbaren Flusspfaden und Eigenschaften dargestellt werden. Jeder Zustand kann einem Telefonie-Vorgang oder -dienst zugeordnet werden, und ein Trigger oder Auslöseereignis, der bzw. das einen Übergang zwischen Zuständen hervorruft, kann eine Benutzereingabe oder ein Status einer laufenden Telefonie-Sitzung sein.
Beispiele von Kommunikationsgeräten, die in der Lage sind, an Telefonie-Sitzungen über das Netzwerk 21 teilzunehmen, schließen übliche Telefone 34 und Faxmaschinen 35 ein, die mit einer Medien-Überleiteinrichtung 32 gekoppelt sind. Die Medien-Überleiteinrichtung 32 verbindet Nicht-Netzwerk-Endgeräte, wie z. B. die Telefone 34 und die Faxmaschine 35 mit dem Netzwerk 21. Die Medien-Überleiteinrichtung 32 kann in Verbindung mit einer Medien-Überleiteinrichtungs-Steuerung 28 arbeiten, um Daten zwischen dem Netzwerk 21 und dem mit der Medien-Überleiteinrichtung 32 gekoppelten Endgeräten zu lenken. Obwohl sie als getrennte Komponenten gezeigt sind, können die Medien-Überleiteinrichtung 32 und die Medien-Überleiteinrichtungs-Steuerung 28 auf der gleichen Plattform realisiert werden. Die Medien-Überleiteinrichtungs-Steuerung 28 steuert einzelne Aufgaben und Ressourcen der Medien-Überleiteinrichtung 32. Zusätzlich steuert die Medien-Überleiteinrichtungs-Steuerung 28 Kommunikationen mit den mit der Medien-Überleiteinrichtung 32 gekoppelten Endgeräten.
Die Gemeinschaft 20 kann weiterhin Netzwerk-Telefone 33 einschließen, die Telefone mit Netzwerk-Schnittstelleneinheiten sind, um Kommunikationen über das Netzwerk 21 zu ermöglichen. Andere Kommunikationseinrichtungen schließen Computer 26 ein, die Sprach- und/oder Bildverarbeitungsfähigkeiten haben. Ein Benutzer an einem der Kommunikationsgeräte kann einen Benutzer an einem anderen Kommunikationsgerät anrufen, wobei Sprache und/oder Videodaten über das Netzwerk 21 übertragen werden. Das Netzwerk 21 kann mit Elementen außerhalb der Gemeinschaft 20 über ein Überleitsystem 30 verbunden sein.
Ein Anruf- oder Verbindungsserver 24 kann ebenfalls mit dem Netzwerk 21 gekoppelt sein, um den Aufbau, die Verwaltung und die Beendigung von Kommunikationssitzungen zwischen Endgeräten zu verwalten, die mit dem Netzwerk 21 gekoppelt sind. Der Anrufserver 24 kann mit einem Datenbanksystem 22 (das sich auf einer getrennten Plattform oder auf der gleichen Plattform wie der Anrufserver 24 befinden kann) gekoppelt sein, das ein Teilnehmerverzeichnis und ein Netz-Verzeichnis einschließt. Weiterhin können Richtlinien für ankommende und abgehende Anrufe von dem Anrufserver 24 verwaltet werden.
Das Teilnehmerverzeichnis in dem Datenbanksystem 22 speichert statische und dynamische Informationen über Benutzer in der Gemeinschaft 20. Der Anrufserver 24 führt einen Zugriff auf das Teilnehmerverzeichnis aus, um Anrufe an Benutzer zu lokalisieren und diese zu lenken. Der laufende Standort eines Benutzers kann durch Registrieren von einem unterschiedlichen Standort aus geändert werden. Das Netzwerk-Verzeichnis in dem Datenbanksystem führt statische und dynamische Informationen über Netzwerkelemente und bevorzugten Merkmalen. Das Netzwerk-Verzeichnis ermöglicht es dem Anrufserver 24, die am besten geeignete Netzwerk-Ressource oder Ressourcen zu bestimmen, die bei seinen Operationen zu verwenden sind. Andere Netzwerkelemente, die mit dem Netzwerk 21 gekoppelt sein können, schließen einen Web-Server 36 zur Bereitstellung von Web-Seiten ein, die für Benutzer innerhalb und außerhalb der Gemeinschaft 20 zugänglich sind. Ein weiteres System in der Gemeinschaft 20 kann ein Sprache-Speicher-Server 23 sein, in dem Sprachedaten, wie z. B. diejenigen, die einer Sprachpost zugeordnet sind, gespeichert werden können.
Von einem Endgerät ausgehende Anrufe zu einem anderen Endgerät werden von dem Anrufserver 24 abgewickelt. Der Anrufserver empfängt einen Anruf, und auf der Grundlage der Identifikationsinformation in dem Anruf (unter Einschluss von Informationen, die die Quellen- und Zielpunkte identifizieren) führt der Anrufserver 24 eine entsprechende Leitweglenkung des Anrufs aus. In anderen Fällen kann eine Peer-zu-Peer-Sitzung zwischen zwei Endgeräten ohne Durchlaufen des Anrufservers 24 ausgebildet werden.
Der Anrufserver 24 kann in verschiedene Komponenten aufgeteilt werden, unter Einschluss eines SIP-Proxy, einer Diensteplattform, eines Telefonieservers und anderer Elemente. Die Diensteplattform kann das Netzwerk überwachen, um zu bestimmen, ob ein Telefoniedienst in Gang gesetzt werden muss. Wenn dies der Fall ist, so kann die Diensteplattform die Skript-Maschine aufrufen, um den Telefoniedienst zu starten. Der Telefonieserver kann ein Hauptprogramm sein, das Nebenstellenanlagen-(PBX-)Funktionen in der erforderlichen Weise startet. Bei einer Ausführungsform können der Anrufserver 24 und einige der anderen Netzelemente den Aufbau, die Verwaltung und die Beendigung von Telefonie-Sitzungen gemäß der Multimedia-Daten- und Steuerarchitektur von der Internet Engineering Task Force (IETF) durchführen. Die IETF-Multimedia-Daten- und Steuerarchitektur schließt eine Protokollfamilie oder einen Protokollstapel ein, der das Sitzungs-Initialisierungsprotokoll (SIP) einschließt, wie dies in RFC 2543 mit dem Titel „SIP: Session Initiation Protokoll" vom März 1999 beschrieben ist. SIP kann dazu verwendet werden, Kommunikationssitzungen einzuleiten sowie Mitglieder zu Sitzungen einzuladen, die durch einen anderen Mechanismus, wie z. B. elektronische Post, News-Gruppen, Web-Seiten und anderes angekündigt wurden. SIP ermöglicht die Bestimmung des Endsystems, das für die Telefonie-Sitzung zu verwenden ist. SIP ermöglicht weiterhin die Bestimmung der Medien, und Medien-Parameter, die zu verwenden sind, sowie die Feststellung der Bereitschaft des angerufenen Teilnehmers, an Telefonie-Kommunikationen teilzunehmen.
Verschiedene Einheiten können durch das SIP definiert werden. Ein Klient entsprechend dem SIP-Protokoll ist ein Anwendungsprogramm, das SIP-Aufforderungen aussendet, wie z. B. zur Ausführung von Anruf-Aufforderungen. Ein Server kann gemäß SIP ein Anwendungsprogramm sein, das SIP-Anforderungen akzeptiert, um Anrufe mit Diensten zu versorgen und um Antworten auf SIP- Anforderungen zurückzusenden. Ein SIP-Proxy oder Proxy-Server kann ein zwischenliegendes Programm sein, das sowohl als ein Server als auch ein Klient wirkt, um Anforderungen für andere Klienten durchzuführen.
Die IETF-Multimedia- und Steuerarchitektur schließt weiterhin ein Ressourcen-Reservierungsprotokoll (RSFP), wie es im RFC 2205 beschrieben ist, zur Reservierung von Netzwerk-Ressourcen; das Echtzeit-Transportprotokoll (RTP), wie es im RFC 1889 beschrieben ist, zum Transport von Echtzeitdaten und zur Lieferung einer Dienstegüte-(QoS-)Rückführung; das Echtzeit-Datenstromprotokoll (RTSP), wie es im RFC 2326 beschrieben ist, um die Zustellung von Datenstrom-Medien zu steuern; das Sitzungsankündigungsprotokoll (SAP) zur Ankündigung von Multimedia-Sitzungen durch Sammelsendung; und das Sitzungsbeschreibungsprotokoll (SDP) ein, wie es in RFC 2327 beschrieben ist, um Multimedia-Sitzungen zu beschreiben.
Die beschriebenen Protokolle stellen lediglich Beispiele von Protokollen dar, die für Kommunikationssitzungen zwischen Netzwerkelementen verwendet werden können. In weiteren Ausführungsformen können andere Arten von Protokollen verwendet werden, wie z. B. Protokolle für Kommunikationssitzungen, die anders als Sprache- oder Multimedia-Kommunikationssitzungen sind. Ein anderes Protokoll schließt die H.323-Empfehlung der internationalen Telekommunikationsunion (ITU) ein. In dieser Beschreibung stellt ein Kommunikationssystem, das SIP und andere verwandte Protokolle realisiert, ein Beispiel einer Umgebung dar, in der Module gemäß mancher Ausführungsformen verwendet werden können, um Telefoniedienste zu realisieren. Es wird jedoch in Betracht gezogen, dass in anderen Ausführungsformen Module zur Schaffung von Telefoniediensten verwendet werden können, die mit anderen Protokollen oder Normen arbeiten.
Das öffentliche Netz 12 kann mit verschiedenen Elementen unter Einschluss eines Endgerätes 12 gekoppelt sein, das ein Netzwerktelefon oder ein Computer sein kann, der Sprache- und/oder Bildverarbeitungsfähigkeiten hat. Das Netzwerk 12 kann weiterhin über eine Medien-Überleiteinrichtungs-Steuerung 16 mit einer Überleiteinrichtung 18 für ein öffentliches wählvermitteltes Telefonnetz (PSTN) gekoppelt sein, die die Schnittstelle zwischen einem PSTN 40 und einem Paketbasierten Datennetz, wie z. B. dem Netzwerk 12 bildet. Das PSTN 40 ist mit drahtgebundenen Telefonen 42 sowie mit ortsbeweglichen Telefonen oder anderen mobilen Einheiten über Funknetzwerke verbunden.
Gemäß 2 schließt eine Darstellung der Architektur oder des Rahmenwerkes gemäß einiger Ausführungsformen drei Schichten ein: eine Telefoniedienst- oder Anwendungsschicht 100, eine Schnittstellenschicht 102 und eine Netzwerkelementen-Schicht 104. Die Netzwerkelementen-Schicht 104 schließt verschiedene Netzelemente ein, die Telefoniedienste bereitstellen. Einige Beispiele für Netzwerkelemente schließen die in 1 gezeigten Elemente sowie andere Elemente ein: eine Bedienungsperson-Konsole (Hardware oder Software), eine Handapparate-Überleiteinrichtung, Stationsgeräte (mit oder ohne eigene Intelligenz), Teilnehmer-Datenbanken (Personen, Beziehungen, usw.), Netzwerk-Datenbanken (Komponenten-Konfiguration und Information) Medienserver (Aufzeichnung, Brücken, usw.), Medienspeicher, eine PSTN-Überleiteinrichtung, ein Firewall-System, eine CDR-Datenbank, einen Webserver, einen E-Mail-Server, eine Anwendungsstation, eine Echtzeit-Statusbox, einen SIP-Proxy-Server, eine SIP-Domänenverwaltung, einen Registrierungsserver, einen Authentifizierungsserver, ein Datenbank-Verwaltungsverzeichnis, eine Server-Entwicklungs-Benutzerschnittstellen-(UI-)Plattform und andere Elemente.
Die Schnittstellenschicht 102 schließt verschiedene Komponenten unter Einschluss von Übersetzungskomponenten 110 zur Übersetzung, Interpretation oder Kompilation von Skripten oder Code, Kommunikationskomponenten 112 zur Ermöglichung von Kommunikationen mit Netzwerkelementen; und Darstellungskomponenten ein, die Darstellungen oder Beschreibungen der Netzwerkelemente liefern, so dass die Funktionalität der Netzwerkelemente an höheren Schichten abstrahiert werden kann. Die Schnittstellenschicht 102 kann in einem oder mehreren Elementen in dem Netzwerk realisiert werden. Beispielsweise können viele der Komponenten in einem SIP-Proxy-Server realisiert werden (wie ein Server, der in dem Anruf-Server 24 realisiert ist).
Die Übersetzungskomponenten 110 können eine Skript-Maschine (zur Interpretation und Ausführung von Skripten) und/oder Compiler oder andere Übersetzer oder Interpreter einschließen. Die Darstellungskomponenten 114 können Bibliotheks-Dateien einschließen, die die Funktionen, Aufgaben und andere Einzelheiten beschreiben, die mit den Netzwerkelementen verbunden sind.
Die Kommunikationskomponenten 112 können Netzwerk-API's (Anwendungsprogramm-Schnittstellen) und Prozeduren einschließen, die es Mechanismen für Netzwerkelemente ermöglichen, andere Netzwerkelemente aufzurufen, wie z. B. das einfache Objekt-Zugangsprotokoll (SOAP), wie es in einem Internet-Entwurf mit dem Titel „SOAP: Simple Object Access Protocol" vom September 1999 beschrieben ist. Die Kommunikationskomponenten 112 können weiterhin eine Common Object Request Broker Architekture (CORBA-) Komponente einschließen, die es Anwendungen ermöglicht, miteinander unabhängig davon zu kommunizieren, wo sie sich befinden oder wer sie entwickelt hat. CORBA ist in der CORBA/IIOP 2.3.1-Spezifikation vom 7. Oktober 1999 beschrieben. Die Kommunikationskomponenten 112 können weiterhin Komponenten-Objekt-Modell-(COM-)Objekte einschließen.
Die Dienste- und Anwendungsschicht 100 kann verschiedene Software-Module einschließen, die Elemente (in der Form von Code oder Skripten) enthalten, die Telefoniedienste, die ausgeführt werden sollen, darstellen oder spezifizieren. Telefoniedienste können Sprache-Telefonie, Sprachdienste (beispielsweise Weiterleitung usw.), Sprachpost (Aufzeichnungsteil), vereinheitlichte Mailbox-Dienste (Sprache, Fax, E-Mail, Wiedergabe), Anrufzentralen, integrierte Sprachbeantwortungseinrichtungen (automatische Begrüßung), e-Commerce (auf der Grundlage von Web und Telefonie) Konferenzschaltungen und Gruppenware (Zusammenarbeits-Anwendungen) einschließen, um nur Beispiele zu nennen.
In 3 ist eine Darstellung des Kommunikationssystems nach 1 gezeigt, in dem API's realisiert sind. Die mit dem Netzwerk 21 gekoppelten Elemente unter Einschluss der Medien-Überleiteinrichtungs-Steuerung 28, des Anrufservers 24, des Sprache-Speicher-Servers 23, des Datenbanksystems 22, des Web-Servers 36 usw. können eine entsprechende Netzwerk-API 210, 212, 214, 216 und 218 einschließen, die jeweils Funktionen oder Routinen definiert, die die Skript-Maschine 100 aufrufen kann, um Aktionen auszuführen, die während der Ausführung eines Skript-Moduls spezifiziert sind. Telefoniedienste sind als Skript-Module bei dieser Ausführungsform realisiert. Die aufgerufene API-Funktion oder Routine wird dann in dem jeweiligen Element ausgeführt, um die angeforderte Aktion auszuführen. Die in jedem Netzwerkelement residierende API hängt von Aufgaben ab, die von diesem Netzwerkelement auszuführen sind. So kann beispielsweise der Anrufserver 24 eine Art von API einschließen, während das Datenbanksystem 22 eine andere Art von API einschließen kann, wie z. B. die Lightweight Directory Access Protocol-(LDAP-)Spezifikationen von der IETF. Es kann irgendeine Art von API in irgendeinem vorgegebenen Netzwerkelement verwendet werden, vorausgesetzt, dass die Skript-Maschine 200 Kenntnisse über die API hat und Aufrufe von Funktionen oder Routinen in der API machen kann.
Die Skript-Module 204, die sich in ein oder mehreren Speichermedien befinden, die für die Dienste-Skript-Maschine 200 zugänglich sind, können durch ein Skript-Erzeugungs-Dienstprogramm 206 und/oder eine Benutzerschnittstelle (UI) 208 geschaffen werden. Bei einer Ausführungsform kann eine Telefonie-Skript-Sprache (TSL) verwendet werden, um die Skript-Module zu erzeugen. Für Dienste, die nicht durch Skripte gemäß TSL realisierbar sind, können andere Module 220, die in einer weiterentwickelten Programmiersprache geschrieben sind, verwendet werden, um diese Dienste zu realisieren. Derartige Programmiersprachen können C++, Java und andere einschließen.
Gemäß einer Ausführungsform kann TSL eine textbasierte Sprache entsprechend einer erweiterten Auszeichnungssprache (XML()) sein, wobei eine Version in der „Extensible Markup Language (XML(), 1.0, „World Wide Web Consortium (W3C) Empfehlung vom Februar 1998 beschrieben ist. XML() ermöglicht es, eine kundenspezifische Auszeichnungssprache für viele Klassen von Dokumenten zu definieren. XML kann zur Codierung vieler unterschiedlicher Arten von Informationen unter Einschluss der Skript-Module verwendet werden, wie sie hier zur Schaffung von Telefoniediensten gemäß einiger Ausführungsformen beschrieben werden. Jedes Skript-Modul kann als eine Zustandsmaschine dargestellt werden, die eine Anzahl von Zuständen und Triggern aufweist, die Übergänge zwischen unterschiedlichen Zuständen steuern. In jedem Zustand oder in Übergängen zwischen Zuständen können bestimmte Aktionen, die Telefoniediensten entsprechen, spezifiziert werden. Trigger sind grundsätzlich Testbedingungen, die bewirken, dass die Zustandsmaschine, die ein TSL-Skriptenmodul bildet, von einem Zustand zu einem anderen übergeht. Aktionen sind die Aufgaben, die auszuführen sind, wobei dies Telefonie-Aufgaben sein können.
Als Beispiele können Trigger folgendes einschließen: eine Anrufidentifikation (zur Identifikation des anrufenden Teilnehmers oder Endgerätes); eine Identifikation des angerufenen Teilnehmers (um den Teilnehmer oder das Endgerät zu identifizieren, das angerufen wird); eine Zeitanzeige (zur Anzeige der Zeit des Anrufes); einen Anruffortschritts-Zustandsanzeiger (um anzuzeigen, ob ein Anruf belegt ist, die Anzahl von Anrufvorgängen, die abgelaufen sind, ob es eine Antwort gab, usw.); eine Anzeige für die Feststellung von DTMF-Signalen; Informationen, die in Programmnotizen entfernter Telefongeräte gespeichert sind; eine Anzeige für einen Datenbank-Test; eine Anzeige für die Feststellung von Sprache-Daten; und andere Trigger Telefon-Programmnotizen oder Cookies werden zur Speicherung von Informationen über Telefonie-Sitzungen zwischen Endgeräten verwendet.
In 4 ist der Prozess der Schaffung und Ausführung von Telefoniediensten gemäß einer Ausführungsform erläutert. Eine grafische Benutzerschnittstelle (GUI) 300 kann an einer Arbeitsstation 302 bereitgestellt werden, die für einen Benutzer zugänglich ist. In der grafischen Benutzerschnittstelle 300 kann eine grafische Darstellung (beispielsweise in Form von Zustandsdiagrammen) von Telefoniediensten oder Anwendungen erzeugt werden. Als Alternative können anstelle einer grafischen Benutzerschnittstelle Dienste als Befehlszeilen oder in einem Dienstprogramm realisiert werden. Die Darstellung des gewünschten Dienstes kann dann in ein Skript (bei 304), beispielsweise gemäß TSL oder einer anderen Skript-Sprache umgewandelt werden. Die grafische Darstellung von Telefoniediensten oder Skripten kann an die Übersetzungskomponente 110 der Schnittstellenschicht 102 (2) übertragen werden, wo sie interpretiert, übersetzt oder kompiliert werden, wie dies passend ist.
Das Skript kann dann (bei 306) auf Objekte, wie z. B. Java, Objecte oder C++-Objekte oder andere Elemente, wie z. B. XML, Tcl oder Perl-Elemente in der Schnittstellenschicht 102 interpretiert oder übersetzt werden. Skripte können von einer Skript-Maschine 200 auf verschiedene Objekte oder Elemente interpretiert werden. Eine direkte Übersetzung kann ebenfalls (bei 307) von dem grafisch dargestellten Modul auf ein oder mehrere Objekte durchgeführt werden. Bei der Ausführung der Objekte oder Elemente in der Schnittstellenschicht 102 können Anweisungen, Befehle, Mitteilungen, Anforderungen usw. (die allgemein als „Befehle" bezeichnet werden) an der Schnittstelle 102 erzeugt und an geeignete Netzwerkelemente (bei 308) gesandt werden, um gewünschte Telefoniedienste auszuführen. Die Befehle werden auf der Grundlage der Darstellungen der Netzwerkelemente durch die Darstellungskomponente 114 in der Schnittstellenschicht 102 erzeugt. Die Befehle können in Form von SIP-Mitteilungen, MEGACO-Anweisungen oder anderen Befehlen aufweisen. MEGACO ist in dem IETF-Internet-Entwurf mit dem Titel „Megaco Protocol" vom April 2000 beschrieben und wird auch als das H.248-Protokoll bezeichnet, das von der ITU verbreitet wird.
Die SIP-Mitteilungen oder MEGACO-Anweisungen können über Server 312, wie z. B. die Medien-Überleiteinrichtung, die Medien-Überleiteinrichtungs-Steuerung, den Proxy-Server oder den Umlenkungsserver an andere Netzwerkelemente weitergeleitet werden.
In den 5A und 5B ist ein Beispiel eines Zustandsdiagramms eines Sprachpost-Mitteilungs-Abfragemoduls angegeben, wobei jeder Zustand verschiedene Eigenschaften einschließt. Die Eigenschaften in einem Ausführungsbeispiel können das Folgende einschließen: eine Zustandidentifikation (ID) kann eine eindeutige Zeichenkette zur Identifikation eines Zustandes einschließen. Eine ActionBefore-Eigenschaft stellt eine Aktion dar, die vor einer Benutzereingabe durchgeführt werden muss (wie z. B. das Öffnen einer Datenbank). Eine MediaBefore-Eigenschaft kann Tonsignale darstellen, die vor einer Benutzereingabe abgespielt werden (wie z. B. eine Begrüßung). Eine MedaAfter-Eigenschaft stellt Audiosignale dar, die nach der Benutzereingabe jedoch vor dem nächsten Zustand abgespielt werden. Eine ActionAfter-Eigenschaft stellt eine Aktion dar, die nach der Benutzereingabe jedoch vor dem nächsten Zustand ausgeführt werden muss (beispielsweise um eine Mitteilung zu speichern). Eine DigitMap-Eigenschaft stellt akzeptable DTMF-(Zweiton-Mehrfrequenz-)Ziffern oder Worte dar. Eine ASR-Eigenschaft ermöglicht oder sperrt eine automatische Spracherkennung. Eine Zeitablauf-Eigenschaft stellt die maximalen Zeitperioden dar, über die vor einer ersten Eingabe und zwischen Eingängen zu warten ist. Eine Restart-State-Eigenschaft stellt den Zustand dar, auf den zurückzukehren ist, wenn irgendeine ungültige Eingabe gemacht wird. Die Vorgabe besteht in der Wiederholung des derzeitigen Zustandes. Derartige Zustandseigenschaften werden lediglich als Beispiele geliefert, weil unterschiedliche Realisierungen unterschiedliche Techniken verwenden können.
Wie dies in 5A gezeigt ist, ist die Identifikation ID des Zustandes 400 gleich „Wait for Extension" (warte auf Anschlussnummer). Die MediaBefore-Eigenschaft des Zustandes 400 kann eine Zeichenkette einschließen, die eine Begrüßung „geben Sie Ihre Anschlussnummer ein oder sagen Sie diese" anzeigt. Die DigitMap-Eigenschaft schließt irgendeine vorgegebene DTMF-Ziffer oder ein Wort ein. ASR wird eingeschaltet, um die Spracherkennung zu aktivieren (um das Sprachpost-System zu aktivieren, damit dieses gesprochene Ziffern erkennt). Die Timeouts-Eigenschaft schließt eine maximale Anzahl von Sekunden (beispielsweise 10) bevor einer ersten Eingabe und die maximale Anzahl von Sekunden (beispielsweise 3) zwischen Eingaben ein. Die RestartState-Eigenschaft schließt den Wert („error.wav", 0) ein, worin „error.wav" eine Audio-Datei ist, die eine dem Benutzer angesagte Fehlermitteilung enthält und 0 den Vorgabezustand darstellt (beispielsweise Zustand 900), auf den bei Auftreten eines Fehlers übergegangen wird.
Das Modul geht auf den Zustand 402 bei Empfang einer Rufnummer als Benutzer-Eingabe über. Der Zustand 402, der eine ID von „waitForPasscode" (warte auf Zugangscode) hat, ist der Zustand, in dem das System zur Eingabe eines Zugangscodes auffordert und auf diesen wartet. Die MediaBefore-Eigenschaft schließt die Zeichenkette „geben Sie Ihren dreistelligen Zugangscode ein oder sagen Sie diesen" ein. Die ActionAfter-Eigenschaft schließt ein Authenticate-(Authentifizierungs-)Verfahren ein, das zur Authentifizierung des eingegebenen Passwortes verwendet wird. Wenn keine Authentifizierung erfolgt, kehrt die Zustandsmaschine zum Zustand 400 zurück. Wenn die Authentifizierung erfolgt, geht die Zustandsmaschine zum Zustand 404 über, der eine ID von „waitForRead" (warte auf Lesen) hat. Die ActionBefore-Eigenschaft schließt das NumMessage()-Verfahren ein, das die Anzahl von Mitteilungen bestimmt, die an der Rufnummer gespeichert sind. Die MediaBefore-Eigenschaft schließt die Zeichenkette „Sie haben eine neue Mitteilung. Geben Sie 1 ein oder sagen dies, um Sie zu hören" ein. Die ActionAfter-Eigenschaft schließt ein Choose()-(wähle)-Verfahren ein, das die abzuhörende Mitteilung auf der Grundlage der Benutzer-Eingabe wählt. Die DigitMap-Eigenschaft schließt eine Zeichenkette „12" ein, um entweder eine 1 oder eine 2 als die DTMF-Ziffer oder das Wort zu akzeptieren.
Wenn entweder eine 1 oder eine 2 empfangen wird, geht die Zustandsmaschine auf den Zustand 406 über, der eine ID von „waitForRead" aufweist. Die ActionBefore- Eigenschaft schließt das GetMedia()(hole Medium)-Verfahren ein, das einen Zugriff auf das Speichermedium ausführt, das zur Speicherung der Mitteilung verwendet wird. Die MediaBefore-Zeichenkette kann „hallo, dies ist Joe" einschließen. Die ActionAfter-Eigenschaft schließt das Choose()-Verfahren ein, und die DigitMap-Eigenschaft schließt „*" ein, was die Annahme eines „*" als eine DTMF-Ziffer darstellt.
Wenn „*" empfangen wird, geht die Zustandsmaschine auf den nächsten Zustand 408 über, der eine ID von „waitForSaveDelete" (warte auf Speichern/Löschen) hat. Die MediaBefore-Eigenschaft schließt die Zeichenkette „gebe 1 zum Speichern, 2 zum Löschen, # zum Abhören der nächsten Mitteilung ein" ein. Die ActionAfter-Eigenschaft schließt das Choose()-Verfahren ein, und die DigitMap schließt die Zeichenkette „12 #" ein. Wenn „#" empfangen wird, so geht die Zustandsmaschine zurück zum Zustand 406, um die nächste Mitteilung auszuwählen. Wenn „1" empfangen wird, so wird die Mitteilung im Zustand 410 gespeichert. Wenn „2" empfangen wird, so wird die Mitteilung im Zustand 412 gelöscht.
Der Zustand 410 hat die ID „waitForSave" (warte auf Speicherung). Die ActionBefore-Eigenschaft schließt das Save()-(Speichern)-Verfahren zum Speichern der Mitteilung ein. Die MediaAfter-Eigenschaft schließt die Zeichenkette „Mitteilung gespeichert, drücke Rautenzeichen für nächste Mitteilung" ein. Die ActionAfter-Eigenschaft schließt das Choose()-Verfahren ein, und die DigitMap-Eigenschaft schließt den „#"-Wert ein. Wenn „#" im Zustand 410 empfangen wird, so geht die Zustandsmaschine auf einen Zustand zur Rückgewinnung der nächsten Mitteilung über.
Der Zustand 412 hat die „waitForDelete" (warte auf Löschen)-Zeichenkette, und die ActionBefore-Eigenschaft schließt ein Delete()-(Löschen-)Verfahren zum Löschen der Mitteilung ein. Die MedaAfter-Eigenschaft schließt die Mitteilungs-Zeichenkette „Mitteilung gelöscht. Drücke Rautenzeichen für nächste Mitteilung" ein, und die ActionAfter-Eigenschaft schließt Choose() ein. Die DigitMap-Eigenschaft schließt den „#"-Wert ein, auf den die Zustandsmaschine wartet, um auf die Verarbeitung der nächsten Mitteilung überzugehen.
Das Modul, wie es in den 5A bis 5B erläutert ist, enthält Elemente, die bestimmte Telefoniedienste angeben, die ausgeführt werden sollen. In dem Beispiel sind die Dienste einem IVR-System zugeordnet. Das Modul befasst sich nicht mit der Frage, mit welchem Netzwerkelement tatsächlich ein angegebener Dienst ausgeführt wird, so dass die Aufgabe des Software-Entwicklers wesentlich bequemer gemacht wird.
In 6 ist ein Beispiel eines Systems, das CORBA-Komponenten zur Realisierung von Telefoniediensten einschließt, gezeigt. Skript-Module 502, die verschiedene Telefoniedienste bereitstellen, können entsprechend TSL geschrieben werden. Die Skript-Module können in einem Beispiel durch eine Skript-Maschine in JAVA-Objekte 504 interpretiert werden. Die JAVA-Objekte 502 werden als Klienten-Anwendungen betrachtet, die Telefoniedienste auf verschiedenen Netzwerkelementen einleiten können. Die JAVA-Objekte 502 wissen nichts über die physikalischen Positionen der Netzwerkelemente, das Protokoll (beispielsweise die Sprache der Software, die auf dem Netzwerkelement abläuft) und andere Gesichtspunkte des Netzwerkes.
Um die Schnittstelle zwischen den Klienten-Objekten 504 und den Netzwerkelementen zu schaffen, sind ein Objekt-Anforderungs-Broker (ORB) 506 und andere CORBA-Elemente in dem System realisiert. Der ORB 506 ist eine Middleware oder ein Emulator, der die Klienten-Server-Beziehungen zwischen den Klienten-Anwendungen (JAVA-Objekte 502) und den Server-Objekten (Netzwerkelementen) festlegt. Unter Verwendung des ORB 506 kann jedes Klienten-Objekt 502 in transparenter Weise ein Verfahren auf einem Server-Objekt aufrufen, das sich auf der gleichen Maschine oder über das Netzwerk hinweg befinden kann. Der ORB 506 fängt einen Verfahrensaufruf von einem Klienten-Objekt 504 auf, findet das passende Server-Objekt, leitet passende Parameter weiter, ruft das Verfahren auf dem Server-Objekt auf und liefert die Ergebnisse an das Klienten-Objekt zurück. Der ORB 506 führt einen Zugriff auf eine Schnittstellen-Bibliothek 512 aus, um Anforderungen auszuführen.
Eine dynamische Aufruf-Schnittstelle (DII) 508 ermöglicht es einem Klienten-Objekt 502, einen direkten Zugriff auf die grundlegenden Anforderungsmechanismen auszuführen, die von dem ORB 506 bereitgestellt werden. Klienten-Objekte 504 haben einen Zugriff auf CORBA-Dienste 514 und CORBA-Anwendungen 516 über die DII 508. Eine oder mehrere Datenbanken 518 sind für die Schnittstellen-Bibliothek 512, die CORBA-Dienste 514 und die CORBA-Anwendungen 516 zugänglich. Die Elemente 512, 514 und 516 können sich auf einem oder mehreren Netzwerkservern befinden.
Die von den Klienten-Objekten 504 und den CORBA-Komponenten realisierten Telefoniedienste können für eine Gerätestation 520 über verschiedene Protokolle zugänglich sein, wie z. B. SIP (Sitzungs-Initialisierungsprotokoll), RTP (Echtzeitprotokoll) oder HTML (Hypertext-Auszeichnungssprache).
In 7 ist ein Beispiel gezeigt, wie ein IVR-Dienst in dem System nach 6 realisiert werden kann. Ein Skript-Modul kann die folgende Codezeile zur Rückgewinnung einer Eingabe von einem Anrufer durch ein IVR-System 602 enthalten: String UserInput = ivrServer.getInput (mediaServer.getAudio („mainMenu"), „#", null). Der Code kann von der Skript-Maschine 501 in ein Klienten-Objekt 504 interpretiert werden. Das Klienten-Objekt 504 ruft das getAudio-Verfahren in einem Medienserver (mediaServer) auf, das in dem IVR-System realisiert ist. Der „mainMenu" (Hauptmenü) Parameter wird an das getAudio-Verfahren weitergeleitet, um die Hauptmenü-Aufzeichnung abzuspielen, die über eine Speicherschnittstelle 604 zurückgewonnen und dem Klienten-Objekt 504 als ein RTP-Wiedergabestrom von einem Gerät 606 zurückgeliefert wird (das sich auf der gleichen Plattform wie die Speicherschnittstelle 604 oder auf einer anderen Plattform befinden kann).
Ein weiteres Verfahren, das von dem Klienten-Objekt 504 aufgerufen wird, ist ein getInput-(hole Eingabe-)Verfahren zur Anforderung einer Benutzer-Eingabe. Irgendeine Eingabe, die von dem Benutzer eingegeben wird (von der angenommen wird, dass sie eine Tastatureingabe ist), wird von dem DTMF-Decodierer 608 verarbeitet, wobei der der empfangenen Ziffer entsprechende Ton von einem RTP-Aufzeichnungselement 610 zurückgespielt wird. Eine weitere Verarbeitung kann auf der Grundlage der empfangenen Benutzer-Eingabe ausgeführt werden, wobei beispielsweise das IVR-System auf ein anderes Menü für eine weitere Benutzer-Eingabe oder auf die Weiterleitung des Anrufs zu einer Rufnummer übergeht.
Somit wurde ein Verfahren und eine Vorrichtung beschrieben, das bzw. die eine bequemere und effizientere Schaffung von Telefoniediensten ermöglicht. Eine Schnittstellenschicht, die Übersetzungskomponenten, Kommunikationskomponenten und Darstellungskomponenten einschließt, wird zum Zusammenwirken mit vom Benutzer geschaffenen Modulen (beispielsweise Skripten oder anderen Formen von Darstellungen) verwendet, um Telefoniedienste auszuführen. Bei Ausführung der Module werden Befehle geschaffen und an Netzwerkelemente übertragen, um die Telefoniedienste auszuführen. Um die Schaffung von Telefoniediensten zu erleichtern, können Darstellungen von Netzwerkelementen in der Schnittstellenschicht gespeichert werden, wobei ein Zugriff auf derartige Darstellungen erfolgt, um passende Befehle an Netzwerkelemente zu erzeugen, um Telefoniedienste auszuführen.
Die verschiedenen Software-Module, Routinen oder andere Schichten (die allgemein als 708 in 8 dargestellt sind), die hier erläutert wurden, können auf Steuereinheiten, wie z. B. der einen oder mehreren Steuereinheiten 712 in einem System 700 ausgeführt werden. Die Steuereinheit oder die Steuereinheiten 712 können einen Mikroprozessor, einen Mikrocontroller, eine Prozessorkarte (die einen oder mehrere Mikroprozessoren oder Mikrocontroller einschließt) oder andere Steuer- oder Recheneinrichtungen einschließen. Die Steuereinheit oder die Steuereinheiten 712 können mit einer oder mehreren Speichereinheiten 514 gekoppelt sein, die eine oder mehrere maschinenlesbare Speichermedien zum Speichern von Daten und Befehlen einschließen können. Die Speichermedien können unterschiedliche Formen von Speicher einschließen, unter Einschluss von Halbleiter-Speicherbauteilen, wie z. B. dynamischen oder statischen Speichern mit wahlfreiem Zugriff (DRAM's oder SRAM's), löschbare und programmierbare Festwertspeicher (EPROM's), elektrisch löschbare und programmierbare Festwertspeicher (EEPROM's) und Flash-Speicher; Magnetplatten, wie z. B. Festplatten, Floppys und auswechselbare Platten; andere magnetische Medien unter Einschluss von Bändern; und optische Medien, wie z. B. Kompaktdisks (CD's) oder digitale Video-Disks (DVD's). Befehle, die die verschiedenen Software-Routinen, Module oder andere Schichten bilden, können in jeweiligen Speichereinheiten gespeichert werden. Die Befehle bewirken bei ihrer Ausführung durch eine jeweilige Steuereinheit, dass der entsprechende Knoten oder das entsprechende Element programmierte Aktionen ausführt.
Die Befehle der Software-Routinen oder Module können in einer von vielen unterschiedlichen Arten in dem Knoten oder das Element geladen oder zu diesem transportiert werden. Beispielsweise können Codesegmente, die auf Floppy-Disks, CD- oder DVD-Medien, einer Festplatte gespeicherte Anweisungen oder Anweisungen einschließen, die über eine Netzwerk-Schnittstellenkarte, ein Modem oder anderen Schnittstelleneinrichtungen transportiert werden, in das System geladen und als entsprechende Software-Routinen oder Module ausgeführt werden. Bei dem Lade- oder Transportprozess können Datensignale, die als Trägerschwingungen verwirklicht werden (die über Telefonleitungen, Netzwerkleitungen, drahtlose Verbindungsstrecken, Kabel und dergleichen übertragen werden) die Codesegmente unter Einschluss von Anweisungen und Befehlen an dem Netzknoten oder das Element übertragen. Derartige Trägerschwingungen können die Form von elektrischen, akustischen, elektromagnetischen oder anderen Arten von Signalen aufweisen.
Wie dies in 8 gezeigt ist, schließt das System 700 weiterhin eine Netzwerk-Schnittstelle ein, um dem System eine Kommunikation über das Datennetz zu ermöglichen. Oberhalb der Netzwerk-Schnittstelle 702 befinden sich ein Netzwerk-Treiber 704, ein Netzwerk-Protokollstapel 706 (beispielsweise ein TCP/IP- und/oder ein UDP/IP-Stapel) und Protokollstapel 710 (beispielsweise ein SIP-Stapel, ein RTP Stapel usw.).

Claims

Verfahren zur Verwendung in einem Kommunikationsnetzwerk (10) mit Netzwerkelementen (16, 23, 24, 26, 30, 32, 33) zur Durchführung von Telefoniediensten, mit den folgenden Schritten: Bereitstellen einer Schnittstelle (102) an die Netzwerkelemente; Empfang von Anforderungen durch die Schnittstelle, die die Ausführung von Telefoniediensten spezifizieren; und Senden, als Antwort auf die Anforderungen, Befehle an eines oder mehrere Netzwerkelemente, die bei der Ausführung der gewünschten Telefoniedienste beteiligt sind, dadurch gekennzeichnet, dass: die Anforderungen von einem Software-Modul (100) empfangen werden; und die Befehle über ein Paket-basiertes Netzwerk (12, 21) ausgesandt werden.
Verfahren nach Anspruch 1, bei dem die Bereitstellung der Schnittstelle die Bereitstellung von Darstellungen (114) der Netzwerkelemente umfasst, wobei das Verfahren weiterhin einen Zugriff auf die Darstellungen zur Erzeugung der Befehle an das eine oder mehrere Netzwerkelemente umfasst.
Verfahren nach Anspruch 1, bei dem der Empfang der Anforderungen von dem Software-Modul den Empfang von Anforderungen von Skript-Modulen (502, 504) umfasst.
Verfahren nach Anspruch 3, bei dem die Bereitstellung der Schnittstelle die Bereitstellung einer Skript-Maschine (501) umfasst.
Verfahren nach Anspruch 3, bei dem die Bereitstellung der Schnittstelle die Bereitstellung einer Skript-Maschine (501) und einer Anwendungsprogrammierschnittstelle (508) umfasst.
Verfahren nach Anspruch 1, bei dem die Bereitstellung der Schnittstelle die Bereitstellung einer einfachen Objekt-Zugriffsprotokoll-(OAP-)Komponente (112) umfasst.
Verfahren nach Anspruch 1, bei dem die Bereitstellung der Schnittstelle die Bereitstellung einer gemeinsamen Objektanforderungs-Vermittler-(CORBA-) Komponente (112) umfasst.
Verfahren nach Anspruch 1, das weiterhin die Darstellung des Software-Moduls als eine Zustandsmaschine mit einer Vielzahl von Zuständen umfasst, die jeweils eine Aktion darstellen, die einem Telefoniedienst entspricht.
Verfahren nach Anspruch 1, das weiterhin den Empfang einer Benutzereingabe durch das Software-Modul umfasst, aus der die Anforderungen erzeugt werden.
Verfahren nach Anspruch 1, bei dem das Senden der Befehle das Senden der Befehle an eines oder mehrere Netzwerkelemente umfasst, die aus der Gruppe ausgewählt sind, die aus einem integrierten Sprachbeantwortungssystem, einem DTMF-Decodierer, einem Sprachpostsystem und einem Aufzeichnungssystem besteht.
Vorrichtung (16, 23, 24, 26, 30, 32, 33) zur Bereitstellung von Kommunikationsdiensten in einem Kommunikationsnetzwerk, das Netzwerkelemente (16, 23, 24, 26, 30, 32, 33) aufweist, mit: einem Software-Modul (100), das Befehle enthält, die Ausführungen von Telefoniediensten in dem Kommunikationsnetzwerk spezifizieren, gekennzeichnet durch: eine Schnittstellen-Schicht (102), die eine oder mehrere Komponenten umfasst, die auf die Ausführung der Module zur Lieferung von Befehlen über ein paketbasiertes Netzwerk (12, 21) an entsprechende Netzwerkelemente zur Ausführung der Telefoniedienste anspricht, die durch das Software-Modul spezifiziert sind.
Vorrichtung nach Anspruch 11, bei der die Schnittstellen-Schicht Darstellungen (114) der Netzwerkelemente umfasst.
Vorrichtung nach Anspruch 11, bei der die Schnittstellen-Schicht eine Kommunikationskomponente (112) zum Senden der Befehle an die Netzwerkelemente umfasst.
Vorrichtung nach Anspruch 13, bei der die Kommunikationskomponente einen Objektanforderungs-Vermittler (ORB) umfasst.
Vorrichtung nach Anspruch 13, bei der die Kommunikationskomponente eine Anwendungsprogrammier-Schnittstelle umfasst.
Vorrichtung nach Anspruch 13, bei der die Befehle Sitzungsinitialisierungsprotokoll-Mitteilungen einschließen können.
Vorrichtung nach Anspruch 11, bei der das Software-Modul ein Skript umfasst.
Vorrichtung nach Anspruch 11, bei dem das Software-Modul ein JAVA-Objekt (504) umfasst.
Computerprogramm-Produkt, das die Schritte des Verfahrens nach einem der Ansprüche 1 bis 10 ablaufen lassen kann.
Computerprogramm-Produkt nach Anspruch 19, bei dem das Verfahren das Senden von Befehlen gemäß einem gemeinsamen Objektanforderungs-Vermittlungs-Architektur- CORBA-) Protokoll umfasst.
Computerprogramm-Produkt nach Anspruch 19, bei dem das Verfahren die Ausführung einer oder mehrerer der Aufgaben umfasst, die aus der Gruppe ausgewählt sind, die aus dem Abspielen von Aufzeichnungen, dem Empfang von Zweiton-Mehrfrequenzsignalen, dem Empfang von Sprachedaten, dem Zugang an Sprachpost und die Weiterleitung eines Anrufs besteht.