-
GEBIET DER
ERFINDUNG
-
Die
Erfindung betrifft das Gebiet der IP-Telefonie, d.h. Telefonie unter
Verwendung des Internetprotokolls, und sie steht insbesondere in
Beziehung zu der Verwendung von Dienstskripten zur Steuerung der
Rufabwicklung in einem Kommunikationsnetzwerk, das z.B. gemäß dem Internetprotokoll
betrieben wird und nachstehend auch als All-IP-Netzwerk bezeichnet
wird.
-
HINTERGRUND
DER ERFINDUNG
-
Bisher
wurden in einer Kommunikationsumgebung Mehrwertdienste in einem
sogenannten Dienstesteuerungsknoten (SCP: „Service Control Point") unter Verwendung
eines intelligenten Netzwerks (IN) zentral implementiert. Daher
waren Diensterzeugung, -verwaltung und -ausführung am Dienstesteuerungsknoten
SCP als eine spezialisierte Funktionsinstanz zentralisiert.
-
Dienstskripten
stellen ein Hilfsmittel zum Erzeugen und Verwalten von Mehrwertdiensten
auf eine zentralisierte Art und Weise bereit (worin der Vorteil
eines intelligenten Netzwerks besteht), aber verteilen die Dienstausführung vollständig (worin
ein Engpass eines intelligenten Netzwerks besteht).
-
Eine
Dienstlogik wird mit einem Skript definiert, das zwischen Funktionselementen
(FE) in einem nachstehend als All-IP-Netzwerk bezeichneten durchgängig IP-basiertem
Netzwerk bewegt bzw. verschoben werden kann und das in einem geeigneten
FE ausgeführt
wird.
-
Verwendbare
Skriptsprachen können
zum Beispiel CPL ("Call
Processing Language":
Rufverarbeitungssprache), SIP-Servlets
(SIP: "Session Initiation
Protocol", Sitzungseinleitungsprotokoll),
die ausführbare
Anweisungen darstellen, welche SIP-Nachrichten behandeln, oder CGI
("Common Gateway
Interface": Allgemeine
Gatewayschnittstelle) sein. Beispiele können in der WO-00/42760 oder
in der WO-99/20060 gefunden werden. Obwohl sich die vorliegende
Beschreibung auf die vorstehend erwähnten Skriptsprachen bezieht,
geschieht dies jedoch nur zu Erklärungszwecken und beschränkt die Anwendbarkeit
der Erfindung keineswegs auf diese Skriptsprachen. In Verbindung
mit der Erfindung können
natürlich
auch andere Skriptsprachen verwendet werden.
-
Bezug
nehmend auf die Rufverarbeitungssprache (CPL) steht CPL genauer
gesagt mit IP-Telefonie in Beziehung. IP-Telefonie ermöglicht, dass Rufe und Multimediasitzungen,
wie etwa gleichzeitige Video- und Audiorufe, quer durch IP-Netzwerke aufgebaut
werden. Die CPL ist vorgesehen, eine einfache, leichte, effiziente
und einfach zu implementierende Sprache zur Erzeugung von IP-Telefonie-Zusatzdiensten zu
sein. Sie ist vorgesehen, unabhängig von
Betriebssystemen oder Signalisierungsprotokollen zu sein, wie etwa
SIP oder H.323. CPL ist insbesondere für eine vom Endanwender bzw.
-nutzer definierte Erzeugung von Zusatzdiensten vorgesehen. Das
Ziel besteht darin, das diese Skripten auf der Stelle schnell definiert
und bereitgestellt werden können.
Deshalb wurden für
die Erzeugung von CPL-Skripten verschiedene Anwender freundliche Methoden
vorgesehen, wie etwa graphisch-symbolische
Editoren bzw. Bearbeitungsprogramme.
-
CPL
steht nicht mit der Erzeugung von Ende-zu-Ende-Telediensten in Beziehung, wie etwa
von Sprach- oder Videorufen. Stattdessen wird sie vielmehr zur Zusatzdiensterzeugung
verwendet. Mit einem Zusatzdienst ist ein Dienst gemeint, der gesondert
definiert wird, um die Bearbeitung von Rufen einschließlich bestimmter
grundlegender Ende-zu-Ende-Dienste, d.h. Teledienste und Trägerdienste,
im Netzwerk zu verändern.
Zusatzdienste können
zum Beispiel Leitweglenkung von Rufen beeinflussen (z.B. sie an
unterschiedliche Adressen umleiten) oder ankommende oder abgehende
Rufe überprüfen.
-
Die
Skripten der CPL-Sprache werden an die IP-Telefonie-Server verteilt,
die an der Bearbeitung der Rufe beteiligt sind, die unter Verwendung
dieser Zusatzdienste beeinflusst werden müssen. Die Skripten werden durch
das IP-Telefonie-Netzwerkverwaltungssystem, Endanwender bzw. -nutzer
oder Administratoren in diese Server eingebracht. Bei der Bearbeitung
eines bestimmten Rufs können
mehrere CPL-Skript-Vorgänge
beteiligt sein. Die einzelnen Skriptvorgänge werden bei Signalisierungsereignissen
ausgelöst
und ausgeführt,
die vordefinierten Kriterien wie etwa Anrufer- oder Angerufenenidentifikation
entsprechen. Erfolgt zum Beispiel ein ankommender Ruf zu einem Teilnehmer,
der ein Überprüfungsskript
ankommender Rufe definiert hat, wird das Skript ausgeführt, weil
die Angerufenenidentifikation übereinstimmt.
-
Im
Allgemeinen stellen Skripten (Dienstskripten) ein effizientes, portables
bzw. übertragbares
und leistungsfähiges
Instrument zur Ausführung
von Steueranweisungen in einem verteilten Netzwerk bereit.
-
Skripten
werden zum Beispiel auf Internet-Webseiten verwendet, um unterschiedliche
Arten von Effekten für
Anwender zu erzeugen. Ein Skript wird von einem Webserver auf einen
lokalen Computer überführt (heruntergeladen)
und dort ausgeführt.
-
Außerdem war
die Architektur bislang sowohl bei Standardisierung als auch bei
Implementierung offen. Um Skripten zur Dienstimplementierung zu
verwenden, muss jedoch einiges an Architektur und Anordnung bzw.
Ordnung bereitgestellt sein.
-
Darüber hinaus
bedeutet eine Verwendung von CPL-Skripten in Verbindung mit SIP-Einladungsverfahren,
Rufverarbeitungssprache- (CPL-) Skripten in SIP-Einladungsverfahren einzubringen. Diese
können
für eine
Dienstausführung
in Proxy-Knoten sorgen, wie es in einem IN-Netzwerktyp durch den
Anwender bzw. Nutzer festgelegt wird. Bisher hat jedoch ein SIP-Client
(Endgerät)
das Skript an das Einladungsverfahren angefügt, wodurch sich eine erhöhte Signalisierungsmenge
ergeben hat.
-
KURZFASSUNG
DER ERFINDUNG
-
Es
ist eine Aufgabe der Erfindung, eine Architektur und ein Bearbeitungsszenario
zur Verwendung von Dienstskripten innerhalb eines All-IP-Kommunikationsnetzwerks
bereitzustellen.
-
Des
Weiteren ist es eine Aufgabe der Erfindung, die Verwendung von zum
Beispiel CPL-Skripten in Verbindung mit SIP-Einladungsverfahren
zu verbessern.
-
Die
Erfindung zielt auch darauf ab, folgendes bereitzustellen:
- • eine
Lösung
für eine
funktionale Arbeitsteilung in einer All-IP-Architektur für vom Netzwerk
und vom Nutzer stammende Dienstskripterzeugung, -verteilung und
-ausführung,
- • verbesserte
Konzepte dafür,
wie Skripten erzeugt werden können,
und welche Parameter berücksichtigt
werden sollten,
- • verbesserte
Konzepte dafür,
wie Skriptausführung
derart bewerkstelligt bzw. verwaltet werden kann, dass Netzwerkintegrität und -leistungsfähigkeit
nicht in Gefahr sind,
- • verbesserte
Konzepte dafür,
wie Skripten im Netzwerk vorbereitet bzw. scharfgeschaltet und ausgeführt werden
können,
und welche Daten für diese
Zwecke benötigt
werden,
- • verbesserte
Konzepte für
Dienstspeicherung und -lieferung quer durch das Netzwerk, einschließlich Vorschläge für erforderliche
Parameter,
- • verbesserte
Konzepte zum Trennen der Daten und der Logik des Skripts.
-
Zusätzlich ist
es eine Aufgabe der Erfindung, sich unkorrekt verhaltende Nutzer
davon abzuhalten, die Computer eines All-IP-Kommunikationsnetzwerks über das
Netzwerk anzugreifen, wenn sie Dienstskripten innerhalb des Netzwerks
verwenden.
-
Gemäß der Erfindung
werden die vorstehenden Aufgaben und Ziele zum Beispiel erfüllt durch
ein Kommunikationsnetzwerk, wobei das Netzwerk mindestens eine Anwendungsservereinrichtung,
eine Teilnehmerinformationsregistereinrichtung, eine Rufzustandssteuerungs-Funktionsinstanz
und ein Dienstportal aufweist, wobei die Anwendungsservereinrichtung
mit dem Dienstportal und mit der Rufzustandssteuerungs-Funktionsinstanz
verbunden ist, das Dienstportal zusätzlich mit der Teilnehmerinformationsregistereinrichtung
verbunden ist und die Teilnehmerinformationsregistereinrichtung
zusätzlich mit
der Rufzustandssteuerungs-Funktionsinstanz verbunden ist, wobei
die Anwendungsservereinrichtung aufweist: eine Skriptenverwaltungs-Funktionsinstanz,
und wobei die Skriptenverwaltungs-Funktionsinstanz zum Verwalten
von Diensten in einer Skriptendatenbank der Anwendungsservereinrichtung
angepasst ist, wobei die Skriptendatenbank zum Speichern von Vorlagen
von Dienstskripten angepasst ist, wobei die Verwaltungsfunktionalität zumindest
eine der folgenden Funktionalitäten
aufweist: Erzeugen, Empfangen, Testen, Überprüfen, Validieren, Verteilen
und Modifizieren.
-
Gemäß weiteren
technischen Lösungen
- – ist
die Skriptenverwaltungs-Funktionsinstanz ausschließlich durch
den Betreiber des Kommunikationsnetzwerks zugänglich;
- – ist
die Skriptenverwaltungs-Funktionsinstanz zum Verwalten von zu speichernden
und/oder bereits gespeicherten Skripten angepasst;
- – ist
die Skriptendatenbank mit dem Dienstportal und mit einer sekundären Speichereinrichtung
für Dienstskripten
der Rufzustandssteuerungs-Funktionsinstanz verbunden;
- – weist
die Rufzustandssteuerungs-Funktionsinstanz zusätzlich eine Bedienungsprofildatenbank auf
und weist die Teilnehmerinformationsregistereinrichtung mindestens
eine Teilnehmerprofildatenbank auf, und ist die Verbindung zwischen
der Teilnehmerinformationsregistereinrichtung und der Rufzustandssteuerungs-Funktionsinstanz
dabei zwischen den jeweiligen Datenbanken dieser eingerichtet;
- – ist
das Dienstportal über
einen Zugangspfad mit einer Endgerätevorrichtung verbindbar;
- – ist
das Endgerät
eine drahtlose Anwendervorrichtung und ist der Zugangspfad über ein
Mobilkommunikationsnetzwerk wie etwa ein GPRS-Netzwerk eingerichtet;
- – ist
das Endgerät
ein Arbeitsplatzsystem und ist der Zugangspfad über das Internet eingerichtet;
- – stammt
eine Kommunikation von einer Endgerätevorrichtung oder schließt an einer
solchen ab, wobei das Endgerät
mit der Rufzustandssteuerungs-Funktionsinstanz über ein
Zugangsnetzwerk verbunden ist;
- – wird
die Endgerätevorrichtung
basierend auf dem Internetprotokoll betrieben.
-
Gemäß der Erfindung
werden die vorstehenden Aufgaben und Ziele zum Beispiel erfüllt durch eine
Endgerätevorrichtung,
wobei das Endgerät
eine Funktionsinstanz aufweist, die angepasst ist, dem Anwender
des Endgeräts
zu ermöglichen,
Dienstskripten zu verwalten, wobei die Verwaltung zumindest eine
der folgenden Funktionen aufweist: Erzeugen, Testen, Verteilen und
Modifizieren von Dienstskripten.
-
Gemäß weiteren
technischen Lösungen
- – weist
das Endgerät
zusätzlich
einen Speicher zum Speichern der vom Anwender am Endgerät erzeugten
oder modifizierten Dienstskripten auf;
- – ist
das Endgerät
zum Speichern der erzeugten oder modifizierten Dienstskripten in
einem Speicherelement eines Kommunikationsnetzwerks angepasst, wobei
das Endgerät
an diesem Netzwerk registriert ist;
- – ist
das Endgerät
zum Speichern der erzeugten oder modifizierten Dienstskripten in
einem Pufferspeicher der Rufzustandssteuerungs-Funktionsinstanz
des Netzwerks angepasst, falls das Skript für nur eine Kommunikationsverbindung
gültig
ist;
- – ist
das Endgerät
zum Speichern der erzeugten oder modifizierten Dienstskripten in
einer Teilnehmerprofildatenbank einer Teilnehmerinformationsregistereinrichtung
des Netzwerks angepasst, falls das Skript für mindestens eine Kommunikationsverbindung
gültig
ist;
- – ist
das Endgerät
zum Speichern der erzeugten oder modifizierten Dienstskripten im
Anwendungsserver eines Heimatteilnehmerservers des Netzwerks angepasst,
falls das Skript für
mindestens eine Kommunikationsverbindung gültig ist.
-
Es
ist zu beachten, dass es auch denkbar ist, die vorstehenden Aufgaben
und Ziele durch ein Verfahren zu erreichen, gemäß dem der Nutzer bzw. Anwender
die Dienste (Dienstskripten) unter Verwendung einer externen Funktionalität (die keinen
Teil von CSCF, HSS, APSE, Endgerät
bildet) zu erzeugen, wobei die Funktionalität eine flexible Benutzerschnittstelle
zur Dienstskripterzeugung und -prüfung bietet. Der Nutzer bzw.
Anwender definiert den Dienst unter Verwendung der externen Funktionalität und die
Funktionalität
stellt als Ergebnis ein entsprechendes Dienstskript an ihrem Ausgang
bereit (z.B. ein CPL-Skript). Das Dienstskript kann dann entweder über das
Dienstportal an den Anwendungsserver oder an das Endgerät des Anwenders
bzw. Nutzers übertragen
werden.
-
Gemäß der Erfindung
werden die vorstehenden Aufgaben und Ziele zum Beispiel auch erfüllt durch ein
Kommunikationssystem, das ein Kommunikationsnetzwerk wie vorstehend
dargelegt und mindestens ein Endgerät wie vorstehend dargelegt
aufweist.
-
Gemäß der Erfindung
werden die vorstehenden Aufgaben und Ziele zum Beispiel auch erfüllt durch
ein Verfahren zum Bearbeiten von Dienstskripten innerhalb eines
Kommunikationsnetzwerks, wobei das Verfahren die Schritte aufweist:
Erzeugen von Dienstskripten durch den Netzwerkbetreiber unter Verwendung
einer Skriptenverwaltungs-Funktionsinstanz und Speichern der Dienstskripten
in einer Skriptendatenbank, die zum Speichern von Vorlagen von Dienstskripten
angepasst ist.
-
Gemäß weiteren
technischen Lösungen
- – weist
das Verfahren die Schritte auf: Laden, auf Antrag eines jeweiligen
Anwenders zum Verwalten seiner Profile, einer Kopie der Vorlagen
der Skripten von der Skriptendatenbank und einer Kopie momentan
für den
jeweiligen Anwender eingestellter Skripten von einer Teilnehmerprofildatenbank
an ein Dienstportal, Bereitstellen einer Anwenderschnittstelle gemäß momentan
eingestellter Skripteinstellungen an dem Dienstportal, Auswählen eines
geladenen Dienstskripts zum Verändern
der momentanen Einstellung des Profils, und Speichern einer Aktualisierung
der eingestellten Skripteinstellungen in der Teilnehmerprofildatenbank;
- – weist
das Verfahren den Schritt auf: Bereitstellen einer Anwenderschnittstelle
in dem Dienstportal, um von einem Anwender stammende Skripten zur
Speicherung im Anwendungsserver zu empfangen;
- – sind
momentan eingestellte Skripten für
den jeweiligen Anwender in der Teilnehmerprofildatenbank von einem
Netzwerk stammende Skripten, die im Netzwerk vom Netzwerkbetreiber
erzeugt werden, oder sind von einem Anwender stammende Skripten,
die vom Anwender eines Endgeräts
am Endgerät
erzeugt werden oder von einem Anwender unter Verwendung einer externen Funktionalität erzeugt
werden, die zur Dienstskriptenerzeugung bestimmt ist;
- – enthält die Teilnehmerprofildatenbank
für jedes von
einem Anwender ausgewählte
Skript einen Skriptschlüssel
als einen Zeiger auf die Skriptlogik des in der Skriptendatenbank
gespeicherten Skripts und für
den jeweiligen Anwender eindeutige Skriptdaten;
- – wird
der Skriptschlüssel
als ein Bitvektor dargestellt, wobei ein Bit des Bitvektors den
Typ eines Dienstes darstellt und die verbleibenden Bits des Bitvektors
Merkmale des Diensttyps darstellen;
- – weist
das Verfahren zusätzlich
die Schritte auf: Weiterleiten der in der Teilnehmerprofildatenbank enthaltenen
Skriptschlüssel
und Skriptdaten an eine Bedienungsprofildatenbank einer Rufzustandssteuerungs-Funktionsinstanz, Überprüfen, dass
für den
empfangenen Skriptschlüssel
in einer sekundären
Speichereinrichtung für
Dienstskripten der Rufzustandssteuerungs-Funktionsinstanz ein entsprechendes
Skript enthalten ist, Abrufen der entsprechenden Skriptlogik aus
der sekundären
Speichereinrichtung bei Eintritt eines Skriptausführungsereignisses;
- – adressiert
jeder Skriptschlüssel
ein Skriptlogikfragment als ein entsprechendes Skript, und weist das
Verfahren zusätzlich
die Schritte auf Zusammensetzen eines auszuführenden Skripts aus den von
den Skriptschlüsseln
adressierten Skriptfragmenten, und Ausführen der Skriptlogik des zusammengesetzten
Skripts mit den Anwender-spezifischen Skriptdaten.
-
Die
Erfindung ist auch gerichtet auf ein Verfahren zum Bearbeiten von
Dienstskripten innerhalb eines Kommunikationsnetzwerks, wobei das
Verfahren den Schritt zum Zusammensetzen von Dienstskripten innerhalb
des Netzwerks basierend auf Informationen von einem Teilnehmerdatenregister
aufweist.
-
Gemäß weiteren
technischen Lösungen
- – werden
die Dienstskripten in Rufverarbeitungsservern ausgeführt;
- – weisen
die Informationen vom Teilnehmerdatenregister einem Teilnehmer zugeordnete
Merkmale auf und wird mindestens ein Dienstskript unter Verwendung
der Informationen über
die Merkmale zusammengesetzt;
- – werden
die einem Teilnehmer zugeordneten Merkmale auf Coderahmen bzw. -skelette
abgebildet;
- – weisen
die Informationen vom Teilnehmerdatenregister auch mindestens einen
Parameter auf, der mit diesen Merkmalen in Zusammenhang steht;
- – wird
das Teilnehmerdatenregister von den Rufverarbeitungsservern im Netzwerk
abgefragt, um das Zusammensetzen der Dienstskripten zu ermöglichen;
- – sind
die Rufverarbeitungsserver ausgestattet, um Dienstskripten zu anderen
Rufverarbeitungsservern zu senden, um den Gesamtdienst für einen
bestimmten Teilnehmer bereitzustellen;
- – sind
die Rufverarbeitungsserver ausgestattet, um die Löschung der
Dienstskripten in anderen Rufverarbeitungsservern anzufordern;
- – leiten
die Rufverarbeitungsserver die Informationen vom Teilnehmerdatenregister
an eine Instanz in Verbindung mit dem Rufverarbeitungsserver weiter,
der die Dienstskripten zusammensetzt;
- – ist
die Instanz in Verbindung mit dem Rufverarbeitungsserver eine Diensteausführungsumgebung.
-
Die
Erfindung ist auch gerichtet auf ein Computersystem mit einer Ausführungsumgebung
zum Ausführen
einer Anwendung zur Bearbeitung von Dienstskripten innerhalb eines
Kommunikationsnetzwerks, das gemäß dem Internetprotokoll
betrieben wird, gemäß den vorstehenden
Verfahrenschritten; und auf ein Computerprogrammprodukt, das in
den Speicher eines digitalen Computers ladbar ist und Softwarecodeteile
zur Durchführung
der vorstehenden Verfahrensschritte aufweist.
-
Dementsprechend
stellt die Erfindung eine Architektur und ein grundlegendes Bearbeitungsszenario
bereit, die beschreiben, wie
- • Skripten
erzeugt und gespeichert werden,
- • Skripten
für einen
Anwender bereitgestellt werden,
- • Skripten
in einem All-IP-Kernnetzwerk verteilt werden,
- • Skripten
während
einer Rufverarbeitung ausgeführt
werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung und ihre Merkmale sowie Vorteile werden vollständiger ersichtlich,
wenn auf die ausführliche
Beschreibung der zugehörigen
Zeichnungen Bezug genommen wird, bei denen zeigen:
-
1 eine
grundlegende Netzwerkarchitektur eines All-IP-Kommunikationnetzwerks gemäß der Erfindung
und angepasst an die Skriptenbearbeitungsszenarien gemäß der Erfindung,
und
-
2 ein
grundlegendes Signalisierungsszenario in Verbindung mit der Zusammensetzung eines
Skripts.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ZEICHNUNG
-
Im
Anschluss wird zuerst die Architektur des Kommunikationsnetzwerks
beschrieben, wie gemäß 1 veranschaulicht,
bevor zweitens die Skriptenbearbeitungsszenarien innerhalb der Netzwerkarchitektur
erläutert
werden.
-
I. Kommunikationsnetzwerkarchitektur
des IP-basierten Kommunikationsnetzwerks
-
1 veranschaulicht
eine erläuternde
Ansicht der Kommunikationsnetzwerkarchitektur. Es ist zu beachten,
dass die Zeichnungen nur diejenigen Teile des Kommunikationsnetzwerks
darstellen, die in Verbindung mit der Erfindung wesentlich sind,
und dass die dargestellte Anzahl jeweiliger Teile zur Vereinfachung
von Zeichnung und Erläuterung
auf eine minimale Anzahl reduziert ist.
-
Für das dargestellte
Kommunikationsnetzwerk, das als Beispiel verwendet wird, wird angenommen,
dass es gemäß dem Internetprotokoll
(IP) betrieben wird und daher ein sogenanntes All-IP-Netzwerk darstellt.
Grundsätzlich
umfasst das Netzwerk mindestens eine Anwendungsservereinrichtung 1,
eine Heimatteilnehmerservereinrichtung 6 als ein Teilnehmerinformationsregister,
eine Rufzustandssteuerungs-Funktionsinstanz 7 und ein Dienstportal 2.
Die Anwendungsservereinrichtung 1 ist mit dem Dienstportal 2 und
mit der Rufzustandssteuerungs-Funktionsinstanz 7 verbunden,
das Dienstportal 2 ist ferner mit der Heimatteilnehmerservereinrichtung 6 verbunden
und die Heimatteilnehmerservereinrichtung 6 ist ferner
mit der Rufzustandssteuerungs-Funktionsinstanz 7 verbunden.
-
Es
ist zu beachten, dass das Dienstportal 2 eine Dienstportalfunktionalität darstellt.
Obwohl das Dienstportal so dargestellt ist, dass es getrennt vom Anwendungsserver
APSE bereitgestellt ist, ist es natürlich auch möglich, dass
die Dienstportalfunktionalität
im Anwendungsserver enthalten ist. Zu Erklärungszwecken richtet sich die
Beschreibung jedoch auf das Dienstportal als eine separate Funktionalität.
-
Die
Anwendungsservereinrichtung 1 weist eine Skriptenverwaltungs-Funktionsinstanz 1A auf. Die
Skriptenverwaltungs-Funktionsinstanz 1A ist ausschließlich durch
den Betreiber des Kommunikationsnetzwerks zugänglich und sie ist angepasst, Dienstskripten,
die in einer Skriptendatenbank 1B der Anwendungsservereinrichtung 1 zu
speichern sind und/oder bereits gespeichert sind, zu erzeugen, zu
empfangen, zu überprüfen/validieren,
zu testen, zu verteilen und/oder zu modifizieren. Die Skriptendatenbank 1B ist
angepasst, Vorlagen von Dienstskripten zu speichern, die nur von
der Rufzustandsteuerungs-Funktionsinstanz 7 und/oder dem
Dienstportal 2 gelesen werden können. Ein Schreiben von Dienstskripten
in die Skriptendatenbank 1B ist nur von der Skriptenverwaltungs-Funktionsinstanz 1A möglich. Der
Ausdruck Vorlage eines Skripts meint bestimmungsgemäß die Skriptlogik
im Sinne einer Menge von ausführbaren
Anweisungen, ohne dass die einzelnen Daten verarbeitet werden (wobei
die einzelnen Daten zum Beispiel von einem speziellen Nutzer/Endgerät und/oder
im Netzwerk vorherrschenden Bedingungen abhängen), oder die Skriptlogik
einschließlich
der Daten für
das Skript (wobei beide Optionen möglich sind).
-
Insbesondere
ist die Skriptendatenbank 1B mit dem Dienstportal 2 und
mit einer sekundären Speichereinrichtung 7A für Dienstskripten
der Rufzustandsteuerungs-Funktionsinstanz 7 verbunden.
-
Mit
Bezug auf die Rufzustandsteuerungs-Funktionsinstanz 7 weist
diese Instanz ferner eine Bedienungsprofildatenbank 7B auf
und die Heimatteilnehmerservereinrichtung 6 weist mindestens eine
Teilnehmerprofildatenbank 6A auf. Die Verbindung zwischen
der Heimatteilnehmerservereinrichtung 6 und der Rufzustandssteuerungs-Funktionsinstanz 7 ist
zwischen den jeweiligen Datenbanken 6A, 7B dieser
eingerichtet. Auch die Verbindung vom Dienstportal 2 zum
Heimatteilnehmerserver 6 ist eigentlich vom Dienstportal 2 zur
Teilnehmerprofildatenbank 6A des Heimatteilnehmerservers 6 eingerichtet.
-
Zusätzlich ist
das Dienstportal 2 über
einen Zugangspfad 3, 4a, 4b mit einer
Endgerätevorrichtung 5a verbindbar,
die basierend auf dem Internetprotokoll betrieben wird. Bei dem
dargestellten Beispiel, wie es gemäß 1 gezeigt
ist, ist das Endgerät 5a eine
drahtlose Endgerätevorrichtung
(3G UE) und der Zugangspfad
ist über
ein IP-Netzwerk 3, ein Mobilkommunikationsnetzwerk, zum
Beispiel ein aus einem Versorgungs-GPRS-Unterstützungsknoten (SGSN) 4b und
einem Gateway-GPRS-Unterstützungsknoten
(GGSN) 4a gebildetes GPRS-Kernnetzwerk, und ein (nicht gezeigtes)
Funkzugangsnetzwerk eingerichtet. Wahlweise und nicht gemäß 1 gezeigt
kann das Endgerät 5a jedoch
ein Arbeitsplatzsystem sein und der Zugangspfad kann über das Internet
eingerichtet sein (d.h. ohne das Erfordernis, ein GPRS-Netzwerk
zu verwenden).
-
Beim
dargestellten Kommunikationsnetzwerk stammt bzw. entsteht eine Kommunikation
bzw. Übertragung
von/an einer Endgerätevorrichtung 5b oder
schließt
an einer solchen ab, wobei das Endgerät über ein Zugangsnetzwerk (z.B.
ein nicht gezeigtes Funkzugangsnetzwerk) mit der Rufzustandssteuerungs-Funktionsinstanz 7 verbunden
ist.
-
Obwohl
gemäß 1 Endgeräte 5a und 5b gezeigt
sind, ist zu beachten, dass diese Endgeräte identisch sein können. Das
heißt,
dass ein zur Kommunikation über
das Kommunikationsnetzwerk verwendetes Endgerät 5b angepasst sein
kann, zur Modifikation von Dienstprofilen, die von jeweiligen Dienstskripten
für dieses
Endgerät
definiert sind, auf das Dienstportal 2 zuzugreifen (unter
Verwendung von Endgerät 5a veranschaulichte
Situation).
-
Das
Endgerät
weist eine (nicht gezeigte) Funktionsinstanz auf, die angepasst
ist, es dem Anwender bzw. Nutzer des Endgeräts zu ermöglichen, Dienstskripten zu
erzeugen, zu testen, zu verteilen und/oder zu modifizieren. Insofern
ist diese Funktionsinstanz auf der Endgeräteseite ähnlich der Skriptenverwaltungsfunktionalität 1A des
Anwendungsservers 1, während
die bereitgestellte Funktionalität für die Skripten
auf der Endgeräteseite
größtenteils weniger
leistungsfähig
ist (z.B. ist für
den Anwender nur eine begrenzte nicht beschwerdeberechtigt, da nicht
beschwert an Skriptsprachenbefehlen am Endgerät verfügbar). Auch weist das Endgerät ferner
einen Speicher zum Speichern der vom Anwender am Endgerät erzeugten
oder modifizierten Dienstskripten auf. Ohne Rücksicht darauf, ob das Endgerät mit einem
lokalen Speicher zum Speichern der am Endgerät erzeugten Dienstskripten
versehen ist, ist das Endgerät
angepasst, die erzeugten oder modifizierten Dienstskripten in einem
Speicherelement eines gemäß dem Internetprotokoll
betriebenen Kommunikationsnetzwerks zu speichern, wobei das Endgerät an diesem
Netzwerk registriert ist.
-
Das
Endgerät
ist zum Beispiel angepasst, die erzeugten oder modifizierten Dienstskripten
in einem (nicht gezeigten) Pufferspeicher der Rufzustandssteuerungs-Funktionsinstanz 7 des
Netzwerks zu speichern, falls das Skript für nur eine Kommunikationsverbindung
gültig
ist. Wahlweise ist das Endgerät
angepasst, die erzeugten oder modifizierten Dienstskripten in einer
Teilnehmerprofildatenbank 6A eines Heimatteilnehmerservers 6 des
Netzwerks zu speichern, falls das Skript für mindestens eine Kommunikationsverbindung
gültig
ist. Zusätzlich
kann das Endgerät
die erzeugten oder modifizierten Skripten (über das Dienstportal 2)
auch in der Skriptendatenbank 1B eines Anwendungsservers 1 speichern, falls
das Skript für
mindestens eine Kommunikationsverbindung gültig ist.
-
Es
ist auch zu beachten, dass Skripten mit einer externen Funktionalität erzeugt
werden können,
die für
diesen Zweck bestimmt ist, und dass auch derartige extern erzeugte
Skripten über
das Dienstportal im Anwendungsserver gespeichert werden können.
-
Das
Kommunikationsnetzwerk, wie es vorstehend kurz beschrieben ist,
bildet in Kombination mit mindestens einem Endgerät, wie es
vorstehend kurz beschrieben ist, ein Kommunikationssystem.
-
II. Skriptbearbeitungsszenarien
-
Im
Anschluss werden Skriptenbearbeitungsszenarien innerhalb der Netzwerkarchitektur
und des Kommunikationssystems erläutert.
-
Es
ist zu beachten, dass Skripten entweder vom Betreiber im Netzwerk
oder vom Anwender am Endgerät
(oder unter Verwendung einer externen Funktionalität, die zur
Skripterzeugung bestimmt ist) erzeugt werden können. Im Folgenden werden im Netzwerk
(d.h. vom Netzwerkbetreiber) erzeugte Skripten als "Netzwerk-veranlasste
Skripten" bezeichnet
und vom Anwender erzeugte Skripten werden als "Anwender-veranlasste Skripten" bezeichnet.
-
II.1. Erzeugung und Speicherung
Netzwerk-veranlasster Skripten
-
Für eine Kommunikationsumgebung
sollte ein Zugriff auf Netzwerkressourcen auf eine sichere, kontrollierte
Art und Weise erfolgen. Dies bedeutet, dass ein wesentlicher Teil
einer Skriptverwendung in einer All-IP-Kommunikationsumgebung (einem All-IP-Kommunikationsnetzwerk)
darin besteht, sicher zu stellen, dass eine Skriptausführung eine
normale Rufbearbeitung weder gefährdet
noch schädigt.
-
Ein
Weg, dies zu gewährleisten,
besteht darin, es nur dem Betreiber zu erlauben, leistungsfähige Skriptsprachen
(wie etwa zum Beispiel CGI oder SIP-Servlets) unbehindert zu verwenden.
Der Anwender kann dann aus den vom Netzwerkbetreiber bereits erstellten
Skripten eine Skriptvorlage bzw. -schablone auswählen, die er zu verwenden wünscht. Es
könnte
einem Anwender auch gestattet werden, vom Netzwerkbetreiber bereitgestellte "Skriptkomponenten" zu kombinieren und
so ein Skript aus diesen Komponenten zu erzeugen. Dies bedeutet,
dass vom Betreiber im Netzwerk Funktionselemente benötigt werden,
die Skripterzeugung, -prüfung
und -speicherung erledigen. Diese Funktionselemente könnten Teil
eines Anwendungsservers (APSE) 1 sein, wie er gemäß 1 beschrieben
ist, wo sie als Skriptenverwaltungs-Funktionsinstanz (SM) 1A bezeichnet
sind, die zum Erzeugen, Testen, Verteilen und/oder Modifizieren
von Dienstskripten angepasst ist, die in einer Skriptendatenbank (SKRIPT-DB) 1B zum
Speichern der Skriptvorlage zu speichern sind und/oder bereits gespeichert
sind.
-
II.2. Netzwerk-veranlasste
Skriptbereitstellung für
einen Anwender
-
In
einem weiterhin als All-IP-Netzwerk bezeichneten durchgängig IP-basierten
Netzwerk ist es wünschenswert,
dass Anwenderschnittstellen zur Dienstbereitstellung leistungsfähiger und
Anwender-freundlicher sein sollen als momentan existierende.
-
Ein
mögliches
Szenario besteht darin, dass die Dienstbereitstellung und die Dienstanwenderverwaltung
allgemein über
ein Dienstportal (das gemäß 1 mit
Ziffer 2 bezeichnet ist) durchgeführt werden, z.B. einen Web-Server,
der dem Anwender Instrumente und Schnittstellen bietet, die es ihm
ermöglichen,
sein Dienstprofil oder seine Dienstprofile zu verwalten.
-
Auf
dieses Portal könnte
mit einem drahtlosen Endgerät,
das zum Beispiel eine Anwendervorrichtung sein kann, die mit sogenannten
Kommunikationsstandards der dritten Generation im Einklang steht,
beispielsweise von 3GPP erzeugten UMTS-Standards, über einen
Zugangspfad zugegriffen werden, der von einem Funkzugangsnetzwerk gebildet
wird, beispielsweise einem GPRS-Zugangsnetzwerk, einem GSM-EDGE-Zugangsnetzwerk,
einem CDMA/WCDMA-Zugangsnetzwerk,
einem IP-Zugangsnetzwerk oder jedem anderen Funkzugangsnetzwerk,
und zwar ohne die Steuerebene (CSCF) überhaupt auch nur zu konsultieren
(wobei dies bedeutet, dass der Zugang zum Dienstportal eine reine
Datenverbindung ist, ohne dass Sprache benötigt wird). Eine weitere (nicht
gemäß 1 gezeigte)
Möglichkeit
besteht darin, mit einem Arbeitsplatzsystem mittels Internet-Web-Browsing
auf das Portal zuzugreifen.
-
Natürlich ist
eine Autorisierung von Anwendern zum Beispiel über einen Benutzernamen und ein
Passwort erforderlich, um eine konsistente bzw. widerspruchsfreie
Aktualisierung von Anwenderprofilen für einen Anwender eines All-IP-Netzwerks
zu gewährleisten.
Diese Mechanismen werden hier jedoch nicht erläutert, da sie für die Erfindung
nicht entscheidend sind. Vielmehr wird angenommen, dass "erforderliche Autorisierungsangelegenheiten
erledigt werden".
Das Dienstportal und ein Zugriff von einem IP-Endgerät (IPTE) 5a ist
gemäß 1 gezeigt.
-
Das
Dienstportal 2 weist eine Schnittstelle zur Skriptendatenbank 1B des
Anwendungsservers (APSE) 1 auf, um herauszufinden, welche
Art von Skripten oder Skriptvorlagen vom Anwender ausgewählt werden
können.
Außerdem
weist das Dienstportal 2 eine Schnittstelle zur auch mit
Ziffer 6 bezeichneten Teilnehmerdatenbank HSS ("Home Subscriber Server": Heimatteilnehmerserver)
auf, die in einer Teilnehmerprofildatenbank 6A die All-IP-Anwenderprofilinformationen
(einschließlich
einer Liste bereitgestellter Skripten und vielleicht Privilegien bzw.
Vorrechte von Anwendern zur Skriptverwendung) enthält.
-
Will
der Anwender nun neue Skripten bereitstellen oder bestehende Skripten
modifizieren, fordert das Portal 2 am HSS 6 (d.h.
an der Teilnehmerprofildatenbank 6A) All-IP-Anwenderprofile an
und fordert auch an der Skriptendatenbank 1B des Anwendungsservers 1 verfügbare Skripten
an. Als Nächstes
stellt das Dienstportal 2 dem Anwenderendgerät 5a die
Anwenderschnittstelle gemäß momentanen
Profil- und Skriptinformationen bereit. Eine anschließende Anwenderinteraktion
zwischen dem IPTE und dem Portal fährt dann fort, bis die gewünschte Funktionalität vom Endgerät 5a an
das Portal 2 angegeben ist. Wird das Anwenderprofil geändert (neue
Skripten bereitgestellt und/oder alte Skripten geändert),
sendet das Portal 2 eine Anwenderprofil-Aktualisierungsanforderung mit erforderlichen
Skriptinformationen an den HSS 6, genauer gesagt an die
Teilnehmerprofildatenbank 6A von diesen. Der HSS 6 (die
Teilnehmerprofildatenbank 6A) aktualisiert dann die All-IP-Anwenderprofile.
-
II.3. Netzwerk-veranlasste
Skriptverteilung über
die All-IP-Netzwerkelemente
-
Die
Vorlage des Skripts (Skriptlogik) wird in der Skriptendatenbank 1B im
Anwendungsserver 1 (APSE) unterhalten. Das Skriptenverwaltungs-
(SM) Funktionselement 1A, das an der Skriptendatenbank 1B angeschlossen
ist, gewährleistet
Skripterzeugung, -modifikation und auch Skriptverteilung. Das Skriptenverwaltungs-Funktionselement 1A besitzt
Informationen über
die als All-IP-Netzwerkelemente bezeichneten durchgängig IP-basierten
Netzwerkelemente, an die ausschließlich lesbare Kopien der Skriptlogik
verteilt werden müssen.
Die Verteilung kann für
alle Skripten an alle Elemente ausgeführt werden, oder die Skripten
können
zu Verteilungszwecken gruppiert werden. Es ist zu beachten, dass
nur die Skriptlogik (ausführbare
Anweisungen ohne die zu verarbeitenden Daten als solche) in der
Skriptendatenbank 1B gespeichert werden müssen. Skriptdaten
(die Daten, die eigentlich von den Skripten zu verarbeiten sind)
können
zum Beispiel Anwender-spezifisch
sein, und sie könnten
vom Anwenderprofil im HSS bereitgestellt werden. In einigen Fällen kann
es jedoch nützlich
sein, auch die Daten für
das Skript in die Skriptlogik aufzunehmen. Daher ist die Trennung der
Logik und der Daten optional.
-
Das
im Heimatteilnehmerserver 6 (HSS) gespeicherte Anwenderprofil
enthält
Informationen über alle
für einen
bestimmten Anwender bereitgestellten Skripten. Diese Informationen
sind mit einer Identifikation bzw. Kennung eines Skripts gespeichert (Skriptschlüssel als
ein Zeiger auf die Skriptlogik des in der Skriptendatenbank 1B gespeicherten
Skripts), wohingegen das Skript (die Skriptlogik) selbst in der Skriptendatenbank 1B gespeichert
ist.
-
Ein
Anwenderprofil kann auch Skript-spezifische Daten, die entweder
einen Vorgabewert oder einen vom Dienstportal empfangenen Wert (der
möglicherweise
vom Anwender über
das Endgerät 5a während einer
Interaktion mit dem Dienstportal 2 angegeben wurde) aufweisen,
enthalten (aber kann sie auch ausschließen). Diese Daten werden (als
die zu verarbeitenden Daten) benötigt,
wenn das Skript ausgeführt
wird. Der Heimatteilnehmerserver 6 (HSS) liefert das Anwenderprofil
(einschließlich
des Skriptschlüssels
und der vom Skript benötigten
Daten) an eine Bedienungsprofildatenbank 7B (SPD: „Service
Profile Database"),
die am Rufzustandssteuerungs-Funktionselement 7 (CSCF: „Call State Control
Functional Element")
angeschlossen ist, an dem der Anwender momentan registriert ist.
Es ist zu beachten, dass die Skriptdaten einen absoluten Datenwert
oder möglicherweise
einen Verweis auf eine logische System-"Variable" (z.B. einen Ausdruck "Sprachnachricht") aufweisen können, die
während einer
Skriptausführung
umgesetzt bzw. übersetzt werden
kann. Empfängt
die Bedienungsprofildatenbank 7B (SPD) das Anwenderprofil,
kann sie überprüfen, ob
die im Anwenderprofil gefundenen Skripten (die durch den Skriptschlüssel identifiziert
werden) in der lokalen Datenbank 7A (einer sekundären Speichereinrichtung
für Dienstskripte,
d.h. für
Skriptlogik) des Rufzustandssteuerungs-Funktionselements 7 (CSCF)
gefunden werden können
oder nicht.
-
Wird
das durch den Skriptschlüssel
im Anwenderprofil identifizierte Skript nicht im sekundären Speicher
für Skriptlogik 7A gefunden,
kann die Bedienungsprofildatenbank 7B (SPD) den sekundären Speicher 7A auffordern,
eine Skriptanforderung an die Skriptendatenbank 1B im Anwendungsserver 1 (APSE)
zu beginnen. Wird auch in der Skriptendatenbank 1B kein
Skript gefunden, kann die Bedienungsprofildatenbank 7B (SPD)
das entsprechende Skript entweder verwerfen oder eine Fehlerabwicklung
mit dem Heimatteilnehmerserver 6 (HSS) beginnen.
-
II.4. Netzwerk-veranlasste
Skriptausführung
-
Das
Anwenderprofil umfasst Informationen über für den Anwender bereitgestellte
Skripten. Unternimmt der Anwender einen Rufversuch (abgehender Ruf
oder abgehende Kommunikation) oder wird ein Ruf in Richtung des
Anwenders platziert (abschließender
Ruf), wird das Anwenderprofil entweder (im Fall abgehender Rufe)
von der Bedienungsprofildatenbank 7B (SPD) oder (im Fall
abschließender Rufe)
von der Teilnehmerprofildatenbank 6A des Heimatteilnehmerservers 6 (HSS)
zum Rufzustandssteuerungs-Funktionselement 7 abgerufen.
-
Die
im Anwenderprofil gefundenen Skripten (d.h. diejenigen Skripten,
auf die Skriptschlüssel
im Anwenderprofil zeigen) werden gemäß Skript-spezifischen Bedingungen
vorbereitet bzw. scharfgeschaltet. Die Skript-spezifischen Bedingungen
werden entweder durch Anwenderprofildaten oder durch die Skriptlogikinhalte
bereitgestellt (Die in der sekundären Datenbank 7A gespeicherte
Skriptlogik kann bei Bedarf einige Skriptausführungsbedingungen umfassen).
Die vorbereiteten Skripten spezifizieren (mittels Skript-spezifischen
Bedingungen) auch das Ereignis, dessen Eintritt die Ausführung des
Skripts veranlasst. Die Rufbearbeitung des Rufzustandssteuerungs-Funktionselements 7 (CSCF)
muss diese Skriptereignisse überwachen
und das Skript startet, falls und wann dies erforderlich ist. Das
Ausführungsereignis
eines Skripts entspricht dem Erfassungspunkt eines aktivierten Auslösers in
einem intelligenten Netzwerk.
-
Tritt
das Ausführungsereignis
eines Skripts ein, wird die Skriptlogik (falls sie nicht während der Skriptvorbereitung
abgerufen wurde) unter Verwendung des Skriptschlüssels aus dem sekundären Speicher 7A abgerufen.
Die Skriptlogik und die Skript-spezifischen Daten (wobei die Daten
vom Anwenderprofil oder möglicherweise
von Skriptlogikinhalten empfangen werden) werden an eine Dienstanforderungen
bearbeitende Funktionsinstanz in der Rufzustandssteuerungs-Funktionsinstanz 7 übergeben.
Diese Instanz startet entweder direkt die lokale Skriptausführung oder
leitet die Anforderung an eine Funktionsinstanz weiter, die einen
Skriptausführungsmechanismus
enthält.
Die Rufbearbeitungsanweisungen werden von dem Ausführungsmechanismus
intern an die Rufbearbeitungsinstanzen bereitgestellt.
-
II.5. Anwender-veranlasste
Skripterzeugung
-
Die
grundlegenden Eigenschaften der Skripten sind für vom Netzwerk oder vom Anwender
veranlasste Skripten die gleichen. Die folgende Beschreibung dieser
behandelt hauptsächlich
die Unterschiede zwischen diesen.
-
Der
Anwender kann Skripten entweder innerhalb des Endgeräts 5a, 5b oder
unter Verwendung irgendeiner externen Funktionalität (zum Beispiel
einer auf einem Arbeitsplatzsystem laufenden Anwendung) erzeugen,
die für
diesen Zweck bestimmt ist. Da der Anwender selbst Kontrolle über die Skripterzeugung
hat, muss es irgendwie sicher gestellt werden, dass sich erzeugte
Skripten im Netzwerk, wo sie ausgeführt werden, nicht unkorrekt
verhalten.
-
Es
gibt mehrere Ansätze,
um diese Art von Sicherheit zu gewährleisten:
- • Verwendung
einer geeigneten Skriptsprache, die nur eine begrenzte Menge verfügbarer Anweisungen
zur Steuerung der Rufbearbeitung einräumt. CPL ist ein Beispiel einer
derartigen Sprache;
- • Einschränken der
zugelassenen Anweisungen während
einer Skriptausführung
im Netzwerk, d.h. Verwerfen oder Ignorieren von sich unkorrekt verhaltenden
Teilen der Endgeräte-veranlassten Skripten;
- • Überprüfen und
Validieren der Skripten, wenn sie in das Netzwerk hochgeladen werden;
- • Konfigurieren
der im Endgerät
verfügbaren
Anwenderschnittstelle für
eine derartige Skripterzeugung, dass illegale bzw. unzulässige Anweisungen
nicht in die Skripten eingebracht werden können (Dies funktioniert nicht
für die
externe Funktionalität
zur Skripterzeugung, da diese nicht notwendigerweise ein Teil des
Netzwerkbereichs ist).
-
II.6. Anwender-veranlasste
Skriptspeicherung, im Endgerät 5a, 5b erzeugtes
Skript
-
Erzeugt
der Anwender die Skripten im Endgerät (5a, 5b),
können
die Skripten entweder im Endgerät
(5a, 5b) selbst oder im Netzwerk gespeichert werden,
an dem das Endgerät
registriert ist.
-
Ist
die Vorlage des Skripts im Endgerät (5a, 5b)
gespeichert, kann das Skript jederzeit in das Netzwerk hochgeladen
werden, um ausgeführt
zu werden. Wird das Skript im Netzwerk unverzüglich nach Heraufladen ausgeführt, muss
es außerdem überhaupt
nicht im Netzwerk gespeichert werden.
-
Verhindern
die Skriptbedingungen jedoch eine unverzügliche Ausführung des Skripts, muss das
Skript zumindest vorübergehend
im Netzwerk gespeichert werden (obwohl die Vorlage im Endgerät (5a, 5b)
ist).
-
Die
Vorlage eines innerhalb des Endgeräts erzeugten Skripts kann auch
im Netzwerk gespeichert werden. Dies ist insbesondere für Skripten praktisch,
die dauerhaft oder für
mehr als einen Ruf zu verwenden sind. Im Allgemeinen können Skripten, die
für mindestens
einen Ruf zu verwenden sind, im Netzwerk gespeichert werden. Die
Vorlage des Skripts kann im Netzwerk entweder im Anwendungsserver 1 (APSE)
oder im Heimatteilnehmerserver 6 (HSS) gespeichert werden.
-
Wird
die Vorlage des Skripts im Anwendungsserver gespeichert, wird sie
entweder direkt oder über
das Dienstportal dorthin geladen (wobei das Dienstportal eine Anwenderschnittstelle
zum Hochladen von Skripten bieten kann). Wird ein Skript vom Endgerät geladen,
muss der Anwendungsserver das Skript überprüfen und validieren, bevor es
in die Skriptendatenbank 1B hinzugefügt wird. An das gespeicherte
Skript kann irgendeine Identifikation bzw. Kennung angebracht werden,
um zu wissen, dass das Skript vom Anwender/Endgerät stammt.
Es ist zu beachten, dass es wünschenswert
ist, das Skript am Anwendungsserver zu speichern, weil dies es dem Netzwerk
ermöglicht,
das Skript (nach Überprüfung und
Validierung) zumindest in Bezug auf Skriptausführung, -verteilung, -bereitstellung
und -aktivierung auf die gleiche Art und Weise zu bearbeiten wie
die vom Netzwerkbetreiber selbst erzeugten Skripten.
-
II.7. Anwender-veranlasste
Skriptspeicherung, mit externer Funktionalität erzeugtes Skript
-
Erzeugt
der Anwender ein Skript (das im Netzwerk auszuführen ist) unter Verwendung
irgendeiner dedizierten externen Funktionalität (Anwendung und/oder Software),
kann dem Anwender zur Diensterzeugung und -prüfung eine flexible und verständliche
Anwenderschnittstelle hoher Ebene bereitgestellt werden. Die externe
Funktionalität
erzeugt das Skript gemäß einer
Beschreibung, die über die Anwenderschnittstelle
der Funktionalität
vom Anwender angegeben wird. Daher bleibt der externen Funktionalität die Bürde, zum
Erzeugen von z.B. CPL fähig
zu sein.
-
Das
erzeugte Skript wird entweder von der externen Software zum Endgerät (5a, 5b)
heruntergeladen oder die externe Funktionalität (Software) kann zum Hochladen
von Dienstskripten eine Verbindung zum Anwendungsserver 1 entweder über das Dienstportal 2 oder
direkt zum Anwendungsserver haben. Wird das Skript zum Endgerät heruntergeladen,
wird es so weiter bearbeitet, als ob es im Endgerät erzeugt
worden wäre.
Wird (möglicherweise über das
Dienstportal) ein Hochladen zum Anwendungsserver durchgeführt, muss
der Anwendungsserver/das Dienstportal für die Authentisierung und Autorisierung
des Anwenders sorgen, der Skripten hochzuladen versucht, und das
hochzuladende Skript überprüfen/validieren,
um eine arglistige bzw. bösartige
oder unrichtige Skriptspeicherung zu verhindern.
-
II.8. Anwender-veranlasste
Skriptbereitstellung
-
Die
Skriptbereitstellung ist exakt die gleiche wie bei Netzwerk-veranlassten
Skripten, falls die Skriptvorlage im Anwendungsserver 1 gespeichert ist.
Ist die Vorlage im Endgerät
gespeichert, ist keine Bereitstellung erforderlich, da das Skript
durch das Endgerät
zur Ausführung
an das Netzwerk hochgeladen wird.
-
II.9. Anwender-veranlasste
Skriptausführung
-
Die
Skriptausführung
ist grundsätzlich
die gleiche wie bei Netzwerk-veranlassten Skripten: die bereitgestellten
Skripten werden ausgeführt,
wenn die Skript-spezifischen Bedingungen erfüllt sind, und wenn das Ereignis
eintritt bzw. erfasst wird, das die Ausführung des Skripts auslöst. Es ist
zu beachten, dass die Ausführungsbedingungen
auch Ruf-spezifisch bereitgestellt werden können: es ist zum Beispiel möglich, dass
sich eine Skriptausführungsbedingung
auf Daten ein er Aufbaunachricht bezieht: das Skript wird nur dann
ausgeführt,
wenn z.B. im Hauptteil einer SIP-Einladungsnachricht
ein bestimmtes Feld erkannt wird.
-
Wie
vorstehend beschrieben können
Skripten einer Rufverarbeitungssprache von verschiedenen Quellen
in die Rufverarbeitungsserver eingefügt werden. Ein Problem bei
dem Verfahren gemäß den momentanen
CPL-Spezifikationen besteht jedoch darin, dass die CPL-Skripten
als monolithische XML-Dokumente behandelt werden. Dies bedeutet, dass
das gesamte Dokument, das das Skript enthält, vollständig zwischen Netzwerkelementen übertragen werden
muss. Gemäß RFC 2824
erfolgt dies bei Netzwerkregistrierung. Dies bedeutet, dass das Skript
beispielsweise als ein eingebetteter Inhalt innerhalb der SIP-Registrierungsnachricht
hochgeladen wird. Dieses Skript kann unter Verwendung eines Autorenwerkzeugs
innerhalb der Endgerätevorrichtung,
wie etwa eines IP-Telefonie-Endgeräts, aufgebaut
bzw. zusammengesetzt worden sein.
-
Gleichermaßen untersteht
es der Verantwortlichkeit des Anwenders oder der Netzwerkverwaltung,
die benötigten
CPL-Skripten an die unterschiedlichen Netzwerkelemente hochzuladen.
Es untersteht der Verantwortlichkeit des Anwenders, die Server zu
kennen, an die die Skripten hochgeladen wurden.
-
Außerdem wurde
allgemein auf einen Skriptschlüssel
als einen Zeiger auf gespeicherte Skriptlogik Bezug genommen.
-
Gemäß einem
weiteren Aspekt der Erfindung werden auszuführende Skripten basierend auf Skriptlogik
aufgebaut bzw. zusammengesetzt, (auf) die von einem entsprechenden
Skriptschlüssel adressiert
(gezeigt) wird. Ein Skriptschlüssel
wird insbesondere als ein Bitvektor dargestellt, wobei ein Bit des
Bitvektors den Typ eines Dienstes darstellt und die verbleibenden
Bits des Bitvektors Merkmale des Diensttyps darstellen. Daher adressiert
jeder Skriptschlüssel
als ein entsprechendes Skript ein Skriptlogikfragment, und ein auszuführendes
Skript besteht aus den von den Skriptschlüsseln adressierten Skriptfragmenten,
und die Skriptlogik des zusammengesetzten Skripts wird danach mit
den Anwender-spezifischen
Skriptdaten ausgeführt.
-
Mit
anderen Worten besteht der Ausgangspunkt dieses Aspekts der Erfindung
darin, dass das Skript (zum Beispiel ein CPL-Skript) am O-CSCF (veranlassendes
Rufzustandssteuerungs-Funktionselement im Fall eines Netzwerks,
das aufgrund seiner Größe mehrere
Rufzustandssteuerungs-Funktionslemente aufweist) und nicht am Endanwender-Endgerät zusammengesetzt
wird (wie es bisher in Verbindung mit SIP üblich war). Die Idee dieses Aspekts
der Erfindung ist es, in den Registern des Heimatteilnehmerservers
(HSS) (d.h. in seiner Datenbank) Bitvektoren zu definieren, die
die bereitgestellten Dienste und Merkmale z.B. für abgehende Rufe darstellen.
Die Bits stellen den Status bzw. Zustand eines Dienstes dar. Für jeden
im Vektor dargestellten Dienst gibt es ein Codefragment im O-CSCF, das
den Dienst darstellt (zum Beispiel im sekundären Speicher für Skriptlogik 7A wie
gemäß 1 gezeigt).
Das CPL-Skript für
das abgehende Einladungsverfahren wird dann aus den Codefragmenten gemäß den aktiven
Bits im Bitvektor aufgebaut bzw. zusammengesetzt. Erfolgt das Zusammensopiel
der Dienste nicht der Reihe nach bzw. sequentiell, wird wahlweise
eine Menge von Bits auf das Codefragment abgebildet. Ein ganzes
CPL-Skript kann sowohl aus Fragmenten bestehen, die sequentiell
angefügt werden
können,
als auch aus Fragmenten, die abhängig
von einer Kombination von Dienstbits ausgewählt wurden. Des Weiteren kann
das CPL-Skript einen
Schlitz bzw. eine Einschubstelle für vom Anwender bereitgestellte
Fragmente enthalten.
-
Daher
werden in einem großen
IP-Telefonie-Netzwerk SIP-CPL-Skripten
in SIP-Einladungsnachrichten eingekapselt. Dadurch wird einiges
an Signalisierung eingespart und der CPL-Skriptenzusammensetzungsprozess
wird vom Betreiber gesteuert.
-
Um
den vorstehenden, weiteren Aspekt der Erfindung ausführlicher
darzulegen, wird Bezug genommen auf 2.
-
2 veranschaulicht
ein grundlegendes Signalisierungsszenario in Verbindung mit der
Zusammensetzung eines Skripts. Und zwar stellt der Netzwerkbetreiber
in Rufverarbeitungsservern eine Funktionalität zum automatischen Zusammensetzen
von CPL-Skripten
aus Merkmalsbitvektoren bereit.
-
Vorteilhafterweise
reduziert dies bedeutend die Last auf den Endanwender und den Netzwerkbetreiber,
weil CPL-Skripten,
die infolge dessen, dass sie von unerfahrenen Endanwendern geschrieben oder
konfiguriert wurden, ein unerwartetes Verhalten verursachen, nicht
separat ausgetestet bzw. auf Fehler durchsucht und von diesen befreit
werden müssen.
Gleichermaßen
kann vorgesehen werden, dass die Größe der an die Netzwerkelemente
hochzuladenden CPL-Skripten anwächst,
wenn/da die CPL-Skriptsprache über die
Zeit erweitert wird. Die hat im Fall drahtloser Endgeräte eine
Bedeutung dahingehend, dass die Netzwerkbandbreite mit einer Implementierung
des vorliegenden Aspekts der Erfindung nicht verbraucht wird, indem
bei Netzwerkregistrierung große
XML-Dokumente über
die Luft übertragen
werden.
-
Die
Idee der Erfindung besteht darin, für den Rufverarbeitungsserver
nur eine Merkmalsmenge und ihre Parameter zu definieren, was den
Aufbau und den Inhalt des benötigten
Skripts der Rufverarbeitungssprache bestimmt.
-
Dies
bedeutet, dass beispielsweise vom Heimatteilnehmerserver HSS bei
Netzwerkregistrierung oder Standortaktualisierung ein die Ziele
des CPL-Skripts beschreibender Merkmalsvektor an den CPS ("Call Processing Server": Rufverarbeitungsserver)
als ein Netzwerkelement geladen wird, das die Rufzustandssteuerungsfunktionalität CSCF aufweist. Die
Merkmalsvektorbits können
zum Beispiel Rufsperrungsmerkmale, Rufumleitungsmerkmale und Anwenderbenachrichtigungsmerkmale
(z.B. E-mail bei jedem verpassten oder weitergeleiteten Ruf) definieren.
Die Interpretation der Merkmalsvektoren basiert auf gegenseitigem
Einvernehmen von HSS und CPS. Werden daher zum Beispiel Teilnehmerdaten
vom HSS oder einem äquivalenten
Diensteregister an den CPS geladen, untersucht der CPS den mit den
Teilnehmerdaten in Zusammenhang stehenden Merkmalsvektor. Gleichermaßen untersucht er
zusätzlich
zu den Merkmalsvektoren die auch in der Nachricht enthaltenen Parameter.
Ein Parameter oder eine Parametermenge steht mit einem bestimmten
Merkmalsvektor in Zusammenhang. Die Parameter können im Hinblick auf den CPS
undurchsichtig bzw. nicht sichtbar sein.
-
Gemäß dem Merkmalsvektor
wählt der
CPS das geeignetste CPL-Skelett bzw. -Gerüst aus und fügt die Parameter
an den Stellen im Skelett bzw. Gerüst ein, wie sie durch die Vektor-spezifische
Logik festgelegt sind.
-
Es
sollte beachtet werden, dass der HSS oder die Registrierung, von
wo aus die Merkmalsvektoren gewonnen werden, jedes Teilnehmerdatenregister
sein kann, das Informationen wie etwa z.B. Standort oder Dienstdaten
in Bezug auf Teilnehmer speichert. Beispiele solcher Teilnehmerdatenregister sind
z.B. der HSS von UMTS, allgemeine SIP-Standortregister, DHCP- ("Dynamic Host Configuration Protocol": Dynamisches Hostkonfigurationsprotokoll) Server
und LDAP/X.500-Verzeichnisserver.
Die allgemeinen SIP-Standortregister speichern Informationen über Aufenthaltsorte
bzw. Verbleib von Anwendern und sie können nach Leitweglenkungsinformationen
abgefragt werden. Die DHCP-Server
und die LDAP/X.500-Server können
z.B. in kleinen Firmennetzwerken verwendet werden, um Teilnehmerinformationen
an die SIP-Server herunterzuladen, die gerade einen Teilnehmer bedienen.
-
Bei
einer Modifikation dieses Aspekts der Erfindung wird der Merkmalsvektor
derart interpretiert, dass jedes Element die Präsenz oder Absenz eines Merkmals
darstellt. Daher hat jede Bitposition im Bitvektor eine feste Bedeutung.
-
Bei
einer anderen Modifikation der Erfindung stellen die Merkmalsvektorelemente
Merkmalsbezeichner dar, die auf ein bestimmtes Merkmal und möglicherweise
auf bestimmte CPL-Skriptcodegerüste
zeigen.
-
Bei
einem Ausführungsbeispiel
der Erfindung wird die Untersuchung der Merkmalsvektoren und die
Zusammensetzung des CPL-Skripts in einer Diensteausführungsumgebung
(SLEE) durchgeführt, das
sich innerhalb des CPS befindet oder mit diesem über eine Signalisierungsschnittstelle
wie etwa eine IN-Schnittstelle (z.B. basierend auf CAMEL-Spezifikationen)
in Zusammenhang steht. Die Diensteausführungsumgebung könnte z.B.
eine Java-basierte virtuelle Maschine sein. Die Diensteausführungsumgebung
wird bei Registrierung am Netzwerk ausgelöst, vorteilhafterweise von
dem CPS, der die Teilnehmerdaten und den Merkmalsvektor empfängt. Die Diensteausführungsumgebung
erhält
die Teilnehmerdaten vom CPS. Sie baut das CPL-Skript auf, das am
CPS zu speichern oder bei Rufaufbau in die Richtung des CPS der
gerufenen Seite zu senden ist.
-
Die
SLEE ("Service Execution
Environment": Diensteausführungsumgebung)
kann bei Empfang der Merkmalsvektoren und ihrer Parameter eine Vielzahl
von CPL-Skripten zusammensetzen. Es kann separate Untermerkmalsvektoren
für CPL-Skripten geben,
die an Rufverarbeitungsserver eines abgehenden Rufs (in Richtung
der gerufenen Seite) zu senden sind, sowie separate Skripten, die
im die Anwender momentan bedienenden CPS zu speichern sind (CPS
entspricht CSCF gemäß Architektur
von UMTS Version 00).
-
Bei
einer Modifikation der Erfindung können mehrere SIP-Server (CPS: Rufverarbeitungsserver einschließlich einer
CSCF-Funktionalität)
beim Rufaufbauprozess im veranlassenden Netzwerk oder -bereich beteiligt
sein. Dies bedeutet, dass der Rufaufbau im veranlassenden Netzwerk
mehrere Server durchlaufen kann, bevor er schließlich an ein anderes Netzwerk
geleitet wird. Die CPL-Skripten, die basierend auf Informationen
gebildet werden, die von der Registrierung (z.B. HSS) empfangen
werden, können
für unterschiedliche
Server bestimmt sein, über
die der Ruf aufgebaut wird. Nach dem Aufbau der CPL-Skripten können daher
einige der Skripten an unterschiedliche Server verteilt werden,
von denen bekannt ist oder erwartet wird, dass der Ruf über diese
aufgebaut wird. Dies ist z.B. derart möglich, dass mit jedem der aufgebauten
Skripten die Rolle oder Adresse des Servers in Zusammenhang steht
und/oder zugewiesen ist, an dem es installiert werden muss. Der
mit der Registrierung kommunizierende CPS kennt die Bedeutung der
Rollen und der Server, die in diesen Rollen für den Teilnehmer arbeiten.
Der CPS weiß dann,
an welche Server er jedes Skript senden muss, das nicht für ihn bestimmt
ist.
-
Im
UMTS-System (All-IP-Netzwerk der Version 00) verläuft der
Rufaufbau zum Beispiel zuerst über
einen Proxy-Server im momentan besuchten Netzwerk, von wo aus er
an einen Gateway-Server für
ankommende Rufe im Heimatnetzwerk geleitet wird. Der Gateway-Server
für ankommende
Rufe verbirgt die Struktur des Heimatnetzwerks gegenüber dem
besuchten Netzwerk, weshalb der Anknüpfungspunkt für den Proxy
im besuchten Netzwerk immer der gleiche ist, sofern zwischen unterschiedlichen
Servern keine Lastverteilung durchgeführt wird. Dies bedeutet, dass
der Proxy-Server den Aufbau immer an den oder die gleichen Gateway-Server
für ankommende
Rufe (ICG: „Incoming
Call Gateway server")
sendet. Der ICG fragt dann z.B. den HSS mit einer Anruferidentifikation
ab und bestimmt den Server (CPS, bedienende CSCF), der den Anrufer
momentan bedient.
-
Wird
der Merkmalsvektor an dem mit dem HSS interagierenden CPS empfangen,
kann die Analyse des Merkmalsvektors daher zu der Erzeugung mehrerer
CPS- Skripten führen. Diese
Skripten können
dazu bestimmt sein, an unterschiedliche Rufverarbeitungsserver verteilt
zu werden. Die Bestimmung basiert auf entweder auf im Merkmalsvektor
enthaltenen Informationen oder sie basiert auf der im CPS (z.B.
weiter in der an den CPS angegliederten SLEE) getroffenen Entscheidung.
-
Einige
der Skripten können
zum Beispiel für den
Proxy-Server im
besuchten Netzwerk bestimmt sein, einige für den momentan bedienenden
CPS, einige für
den Gateway ankommender Rufe und einige dazu, an die Ziele abgehender
Rufe gesendet zu werden. Wurde der Skriptaufbau in dem mit dem HSS
kommunizierenden CPS durchgeführt,
sendet der CPS die Skripten an die Server, für die die Skripten bestimmt
sind. Der CPS kann die Adresse des Proxy-Servers und die Adresse
des Gateways ankommender Rufe in der Registrierungsanforderung empfangen
haben. In Lastverteilungsfällen
kann eine Kopie des gleichen Skripts an jeden der Server in den gleichen
Rollen (z.B. als Gateway ankommender Rufe) gesendet werden, zwischen
denen die Last verteilt ist.
-
Das
vorstehend dargestellte ermöglicht
zum Beispiel, dass die an den Proxy-Server im besuchten Netzwerk
gesendeten Skripten verursachen, dass bestimmte Rufaufbauanforderungen
im besuchten Netzwerk verweigert werden, bevor das Heimatnetzwerk
bemüht
wird. Der Vorteil der Lösung
besteht darin, dass der Endanwender nicht die bei einem Rufaufbau
beteiligten Server kennt. In einigen Fällen wurde dies vor dem Endanwender
verborgen. Daher wäre
es für
den Endanwender nicht möglich,
die Skripten separat an jedem möglichen
Server zu installieren, der bei einem Rufaufbau beteiligt ist, wie es
bei sehr einfachen IP-Telefonie-Netzwerken der Fall ist.
-
Die
Merkmalsvektoren im HSS oder der Registrierung werden durch irgendeine
Verwaltungsanwendung verwaltet. Der Endanwender kontaktiert das
Verwaltungssystem des Betreibers über irgendeine graphische Anwenderschnittstelle.
Der Endanwender trifft dann einige Merkmalsauswahlen, -aktivierungen
und -konfigurationen (z.B. zum Aktivieren einer Rufsperrung). Es
kann sein, dass keine Eins-zu-Eins-Beziehung zwischen diesen Merkmalen
und den Merkmalen im Merkmalsvektor besteht. Die Anwenderauswahlen
werden durch das Verwaltungssystem interpretiert, das die Merkmalsvektoren im
HSS manipuliert bzw. verarbeitet, die später an die Rufverarbeitungsserver
zu senden sind. Bei der Zurückweisung
bestimmter Merkmale benachrichtigt der HSS oder die Registrierung
den momentanen CPS über
den neuen Merkmalsvektor. Dies bewirkt, dass der CPS eine Löschungsanforderung
an die anderen Rufverarbeitungsserver sendet, an die die nicht mehr
länger
gültigen
Skripten gesendet wurden. Wird ein Anwender vom Netzwerk als unerreichbar
betrachtet, führt
der diese Beobachtung machende CPS eine implizite Trennung bezüglich des
Anwenders durch und benachrichtigt alle Rufverarbeitungsserver,
die Skripten für
den Anwender haben können.
Der die Beobachtung machende CPS kann beispielsweise eine Löschungsanforderung
für die CPS-Skripten,
die für
den Anwender gültig
sind, z.B. an das Netzwerk multicasten oder broadcasten bzw. teilweise
oder vollständig
rundsenden. Dies bewirkt, dass keine anhängigen alten Skripten im Netzwerk verbleiben
können.
-
Die
CPL-Skripten, die an abgehende SIP-Einladungsanforderungen (Rufaufbaunachrichten)
angehängt
sind, können
zum Aktualisieren der Version der mit dem rufenden Anwender in Zusammenhang
stehenden CPL-Skripten in Rufverbeitungsservern in der Richtung
eines abgehenden Rufs verwendet werden (CPS-U gemäß 2).
In diesem Fall ersetzen sie die darin gespeicherte Version. Wahlweise
können
diese Skripten der SIP-Einladungsnachricht
(oder einer ähnlichen
Rufaufbaunachricht) den ganzen Weg zum endgültigen CPS der gerufenen Seite
folgen (CPS-NO gemäß 2), der
direkt den Anwenderagenten der gerufenen Seite kontaktiert (UA,
in IP-Endgerätevorrichtungen
TE implementierte Funktionalität).
Diese Skripten können den
Rufaufbau über
den ganzen Weg in den als Proxy arbeitenden und umleitenden Rufverarbeitungsservern
leiten und zum Beispiel Nachrichten festlegen, die zum Beispiel
im Fall eines Fehlschlagens beim Aufbauen des Rufs an irgendeine
bestimmte festgelegte Seite an verschiedene Empfänger zu senden sind.
-
Schließlich sollte
beachtet werden, dass
- – ein Anwendungsserver APSE
auch ein Dienstesteuerungsknoten SCP oder jedes Element sein kann,
das zum Angeben von Steuerungsanweisungen zur Sitzungsverwaltung
(Rufbearbeitung) verantwortlich ist,
- – ein
Heimatteilnehmerserver HSS als ein Teilnehmerinformationsregister
auch ein Heimatstandortverzeichnis HLR eines GSM-Netzwerks oder
jedes andere Element mit einem Teilnehmerinformationsregister sein
kann,
- – ein
CSCF die Rufsteuerungsfunktion einer MSC oder eines MSC-Servers,
die Rufsteuerungsfunktion von CPS (der eigentlich der CSCF ist),
die Rufsteuerungsfunktion einer Festnetzvermittlung oder ein SIP-Server
sein kann, der zur Leitweglenkung der SIP-Nachrichten zwischen Endpunkten
verantwortlich ist,
- – auf
ein Portal auch über
WAP oder SMS zugegriffen werden kann,
- – ein
Skript sich auf jede portable bzw. übertragbare Dienstlogik PSL
beziehen kann, d.h. jede Form von Logik, die von ihrer Erzeugungs-
und Verwaltungsumgebung zu Ausführungszwecken zu
einem beliebigen anderen Element im Netzwerk übermittelt werden kann. Dieses
Element kann CPS, HSS, APSE, IPTE sein. Sogar die IN-Dienstlogik,
die zum Steuern des Schalters über
traditionelle Protokolle wie etwa INAP, CAMEL, WIN, OSA ausgelegt
ist, kann derart ausgelegt werden, dass die Logik, anstatt die Anweisung
im CPS auszuführen,
an den Schalter verschoben werden kann und INAP, CAMEL, WIN, OSA
als Schnittstelle im Schalter haben kann. Das heißt, dass
ein Dienstskript jede portable Dienstlogik sein kann, nicht nur
die Skriptlogiken, die namentlich als "Skripten" festgelegt sind (CPL, CGI, Servlets).
-
Dementsprechend
schlägt
die Erfindung, wie vorstehend beschrieben ist, ein Kommunikationsnetzwerk
vor, wobei das Netzwerk mindestens eine Anwendungsservereinrichtung,
eine Teilnehmerinformationsregistereinrichtung, eine Rufzustandsteuerungs-Funktionsinstanz
und ein Dienstportal aufweist, wobei die Anwendungsservereinrichtung
mit dem Dienstportal und mit der Rufzustandsteuerungs-Funktionsinstanz
verbunden ist, das Dienstportal zusätzlich mit der Teilnehmerinformationsregistereinrichtung
verbunden ist und die Teilnehmerinformationsregistereinrichtung
zusätzlich
mit der Rufzustandsteuerungs-Funktionsinstanz verbunden ist. In
Zusammenhang mit der vorgeschlagenen Netzwerkarchitektur schlägt die Erfindung
auch Verfahren zum Bearbeiten von Dienstskripten innerhalb des Netzwerks
mit Bezug auf Erzeugung und Speicherung von Dienstskripten, Bereitstellung
der Dienstskripten für
einen Anwender, Verteilung der Skripten im Netzwerk und Ausführung der
Skripten während
einer Rufverarbeitung vor.
-
Es
sollte selbstverständlich
sein, dass die vorstehende Beschreibung und die zugehörigen Zeichnungen
nur zum Veranschaulichen der Erfindung einzig und allein als Beispiel
bestimmt sind. Die bevorzugten Ausführungsbeispiele der Erfindung können daher
innerhalb des Umfangs der zugehörigen
Ansprüche
variieren.