DE60108725T2 - Architektur zum Auslösen der Dienste - Google Patents

Architektur zum Auslösen der Dienste Download PDF

Info

Publication number
DE60108725T2
DE60108725T2 DE60108725T DE60108725T DE60108725T2 DE 60108725 T2 DE60108725 T2 DE 60108725T2 DE 60108725 T DE60108725 T DE 60108725T DE 60108725 T DE60108725 T DE 60108725T DE 60108725 T2 DE60108725 T2 DE 60108725T2
Authority
DE
Germany
Prior art keywords
rule
service
processing
message
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60108725T
Other languages
English (en)
Other versions
DE60108725D1 (de
Inventor
Rico Werni Steenfeldt
Henry Gerard Edge Hill Smith
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of DE60108725D1 publication Critical patent/DE60108725D1/de
Publication of DE60108725T2 publication Critical patent/DE60108725T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H04M3/4217—Managing service interactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5032—Generating service level reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Executing Machine-Instructions (AREA)
  • Communication Control (AREA)

Description

  • Diese Erfindung bezieht sich auf das Management einer Vielzahl von Diensten, die auf eine Kommunikationssitzung bezogen sind, wobei die Kommunikationssitzung durch ein Sitzungsprotokoll gesteuert wird, das Sitzungsinformation über die Kommunikationssitzung vorsieht.
  • Es gibt eine steigende Nachfrage nach interaktiven Kommunikationssitzungen über das Internet, wie etwa IP-Telefonie, Multimediasitzungen, Video-Datenstrom (video streaming) etc. Interaktive Kommunikationssitzungen können durch Sitzungsprotokolle gesteuert werden, wie etwa das Sitzungsinitiierungsprotokoll (Session Intitiation Protocoll, SIP), welches Initiierung, Abschluss und Modifikation von Sitzungen zwischen Benutzern handhabt. SIP befasst sich nicht mit dem Typ einer Sitzung, die zu initiieren ist, d.h. mit dem tatsächlichen Inhalt von SIP-Nachrichten, sondern vielmehr mit dem Managen einer Sitzung. Dies inkludiert Aufgaben, wie etwa Bestimmen, wo sich ein Benutzer tatsächlich befindet, der zu kontaktieren ist, Zustellen einer Beschreibung der Sitzung, zu der der Benutzer eingeladen wird, Verhandeln eines gemeinsamen Formates zum Beschreiben von Sitzungen etc.
  • SIP basiert auf dem Anfrage-Antwort-Paradigma. Wenn z.B. eine Sitzung initiiert wird, sendet ein Anrufer eine Anfrage, die zu dem Benutzer adressiert ist, den der Anrufer anrufen will, d.h. der Angerufene. Die Anfragenachricht wird zu dem Angerufenen gesendet, typischerweise über eine Reihe von Proxy-Servern, die zum Weiterleiten und Zustellen von Nachrichten verantwortlich sind. Der Angerufene sendet eine Antwort, die die Einladung annimmt oder ablehnt. Die Antwort wird durch die Folge von Proxy-Servern in der umgekehrten Reihenfolge zurückgeleitet.
  • Über dem Standardsitzungsmanagement, das durch ein Sitzungsprotokoll vorgesehen wird, wie etwa SIP, können zusätzliche Dienste im Standort des Anrufers, Standort des Angerufenen oder in beliebigen der zwischenliegenden Proxy-Server implementiert werden.
  • Hier umfasst der Begriff Dienst (Service) eine Einheit von Funktionalität, die einem Basissystem inkrementell hinzugefügt werden kann und die zu einer Ausgabe führt, die durch einen Benutzer wahrnehmbar ist, wie etwa einen Teilnehmer, einen Administrator oder dergleichen. Daher ist ein Dienst, z.B. Rufweiterleitung, Sprachpost (voice mail), Videokonferenz etc. eine modulare Erweiterung zu einem Basissystem, wie etwa einem System zum Managen von Sitzungen, z.B. einem SIP-System. Der Prozess zum Hinzufügen und Ermöglichen von Merkmalen in einem Basissystem wird Merkmalsaufstellung (feature deployment) genannt.
  • Während einer Sitzung können Merkmalen durch gewisse Ereignisse getriggert (ausgelöst) werden. Triggern, d.h. die Handlung zum Aufrufen einer gegebenen Anwendung in einem gegebenen Ereignis, basiert gewöhnlich auf vertraglichen Beziehungen zwischen Teilnehmern und Dienstanbietern. Falls mehr als ein Merkmal in einem Dienstnetz aufgestellt ist, und einer oder mehr Dienste gleichzeitig für einen oder mehr Benutzer aktiviert werden können, dann treten Merkmalsinteraktionen auf. Hier umfasst der Begriff Merkmalsinteraktion den Einfluss oder die Modifikation eines Merkmals durch ein anderes. Merkmalsinteraktion ist ein unvermeidliches Nebenprodukt von modularen Merkmalen. Es kann wünschenswerte und nicht erwünschte Merkmalsinteraktionen geben. Es ist jedoch ein Prob lem, dass das gesamte Verhalten eines Dienstnetzes nicht steuerbar werden kann, falls Merkmalsinteraktionen nicht richtig gemanagt werden. Folglich ist Merkmalsinteraktion ein wachsendes Problem, da sich die Zahl und Komplexität einer Dienstanwendung mit der Entstehung neuer Technologien, wie etwa UMTS, erhöht, die den Fähigkeiten von Dienstnetzen erhebliche Anforderungen auferlegen. Diese Dienste können unabhängig entwickelt worden sein und die Dienstanbieter müssen in der Lage sein zu spezifizieren, wie in Konflikt stehende Instruktionen von diesen Diensten aufzulösen und zu dem Vorgabeverhalten des verwendeten Kommunikationsprotokolls zu vermitteln sind.
  • Um Merkmalsinteraktion zu vermeiden, kann das Verhalten von mehreren Merkmalen ad-hoc oder systematisch getestet werden, wenn ein neuer Dienst einem Dienstnetz hinzugefügt wird, z.B. durch Testen von Paaren von Merkmalen. Falls Fälle von Merkmalsinteraktionen während Tests oder nach Aufstellung erfasst werden, können die erfassten Probleme z.B. durch Umgestalten von einer oder mehr der einbezogenen Dienstanwendungen gelöst werden.
  • Der obige Ansatz erfordert eine beträchtliche Menge von Ressourcen, insbesondere da sich die Zahl und Komplexität der Dienste erhöht. Daher ist es ein Problem, dass der obige Stand der Technik mit der Zahl und Komplexität von Dienstanwendungen nicht gut skaliert.
  • Der Artikel "Programming SIP Services" von Anders Kristensen et al, IP Telephony Workshop 2000, beschreibt eine JAVA-basierte Schnittstelle zwischen Diensten und einem SIP-Server.
  • Der Artikel "An Architecture for Three Challenging Features" von Pamela Zave, Internet Telephony Workshop 2001, beschreibt eine Architektur für drei spezifische Merkmale innerhalb des Kontextes von IP-Telefonie, nämlich "Standort und Identifikation", "Umschalten und spontane Konferenz" und "Post". Die Gestaltung dieser Merkmale berücksichtigt Probleme von Merkmalsinteraktion. Dieser Artikel verweist ferner auf eine verteilte Merkmalseinrichtungsarchitektur (Distributed Feature Composition architecture, DFC) und beschreibt ein System im Sinne von Schnittstellenboxen und Merkmalsboxen, die gleichlaufende Prozesse sind.
  • Es ist jedoch ein Problem des obigen Systems des Standes der Technik, verbesserte Mechanismen zum Vermeiden von Merkmalsinteraktionen wegen der Änderung des Kontextes eines Dienstes durch einen anderen Dienst vorzusehen.
  • Gemäß der Erfindung werden die obigen und andere Probleme durch ein Verfahren zum Managen einer Vielzahl von Diensten, die durch eine Nachricht eines Sitzungsprotokolls getriggert werden, das eine Kommunikationssitzung steuert, wie in Anspruch 1 definiert, gelöst.
  • Folglich wird der Aufruf von Diensten, der während einer Kommunikationssitzung getriggert wird, durch eine Zahl von Ausführungsregeln gesteuert, die in einer vorbestimmten Reihenfolge verarbeitet werden, wobei dadurch die Reihenfolge von aufzurufenden Diensten gesteuert wird. Deshalb wird ein Mechanismus zum Triggern von Anwendungen basierend auf den Dienstausführungsregeln vorgesehen, der ein beliebiges Gesamtverhalten wegen einer ungesteuerten Reihenfolge einer Ausführung vermeidet. Des weiteren können durch Editieren der Ausführungsregeln unterschiedliche Aufstellungsstrategien leicht implementiert werden, wobei dadurch eine flexible fein granulierte Dienstaufstellungsinfrastruktur vorgesehen wird, die große Flexibilität beim Ordnen der Kette von Diensten vorsieht, was es erlaubt, das Leistungsverhalten des Dienstnetzes zu optimieren.
  • Daher wird gemäß der Erfindung eine flexible Dienstaufstellungsinfrastruktur vorgesehen, die es erlaubt, Merkmalsinteraktionen systematisch zu vermeiden, wenn eine große Zahl von komplexen Diensten gemanagt wird, z.B. wenn Dienste innerhalb eines Dienstnetzes hinzugefügt, entfernt, aufgehoben, erneut aktiviert oder neu zugeordnet werden.
  • Es wird ein standardisiertes Rahmenwerk zum Definieren einer Dienstausführung vorgesehen, das die Verteilung des Dienstmanagementproblems zwischen unabhängigen Interessengruppen erlaubt, wobei dadurch ein Verfahren vorgesehen wird, das mit der Zahl von Diensten skalierbar ist.
  • Eine Ausführungsregel inkludiert eine oder mehr Bedingungen zum Durchführen einer oder mehr Aktionen, wie etwa Aufrufen einer Dienstanwendung.
  • Der Begriff Kommunikationssitzung umfasst Kommunikationssitzungen zwischen Benutzern eines Kommunikationsnetzes, wie etwa eines TCP/IP-Netzes, eines Lokalbereichsnetzes, eines Weitverkehrsnetzes, des Internet oder dergleichen. Beispiele von Kommunikationssitzungen inkludieren Sprache-über-Internet (Voice-over-Internet), IP-Telefonie, Videokonferenz, Video-Datenstrom etc.
  • Der Begriff Sitzungsprotokoll umfasst ein Protokoll, das die Kommunikationssitzung steuert, und insbesondere die Initiierung, den Abschluss und die Modifikation von Sitzungen. Vorzugsweise basiert das Sitzungsprotokoll auf Anfrage-/Antwortnachrichten, die über die Knoten des Kommunikationsnetzes zwischen den teilnehmenden Benutzern einer Kommunikationssitzung übertragen werden. Ein Beispiel eines derartigen Sitzungsprotokolls ist das Sitzungsinitiierungsprotokoll (SIP).
  • Andere Beispiele inkludieren die Protokollfolge H.323, MGCP und verwandte Protokolle, wie etwa IPDC, SGCP, H.248 etc.
  • Der Begriff Dienst umfasst eine Einheit von Funktionalität, die einem Basissystem inkrementell hinzugefügt werden kann. Ein Dienst kann Teilnehmern Dienste anbieten, kann aber auch andere Dienste, wie administrative Aufgaben, dem Netzadministrator anbieten. Beispiele derartiger Dienste inkludieren Rufweiterleitung, Warten auf einen Ruf, Sprach-Post, Statistikfunktionen, Rückruf, Videokonferenz, Video auf Nachfrage, Anonymisierungsdienste, automatische Antwort etc. Ein Dienst kann unter Verwendung einer Vielheit von Technologien implementiert werden, z.B. OSA, Java, CGI, Perl, C++, CPL, XML etc.
  • In dem Kontext des SIP-Protokolls ist ein Dienst eine Anwendung oder eine Zahl von Anwendungen, die lokal auf einem SIP-Server, z.B. als ein CGI-Skript oder ein CPL-Skript, oder entfernt auf einem Anwendungsserver, der durch den SIP-Server kontaktiert wird, ausgeführt werden. In dem letzteren Fall kann der Dienst unter Verwendung irgendeiner Standardnamenskonvention zugänglich gemacht oder aufgerufen werden, d.h. unter Verwendung von SIP-Anfrage-URIs (SIP-Request-URI). Alternativ können sich die Dienste tatsächlich in dem SIP-Server unter Verwendung z.B. eines 3GPP OSA API Rahmenwerkes selbst registrieren. SIP-Dienste können in veranlassende und abschließende Dienste gruppiert werden, d.h. jene, die mit dem Anrufer und dem Angerufenen in Verbindung stehen.
  • Dienste können auf Bedingungen in einem Nachrichtenheader (Nachrichtenkopf), einem Nachrichtenrumpf, dem SDP oder dergleichen getriggert werden.
  • Die Funktionalität des SIP-Servers, die Dienstanwendungen angeboten wird, wird Dienstmerkmale genannt, wie etwa Zugriff auf irgendeine API, z.B. eine serverseitige OSA-API, auf statistische Funktionen oder dergleichen. Dienstmerkmale können ferner Dienstanwendungen sein, die sich in dem SIP-Server registrieren und anschließend ihren Dienst anbieten, um durch andere Dienstanwendungen verwendet zu werden.
  • Es ist ein weiterer Vorteil der Erfindung, dass sie von der Technologie, die für die Implementierung der Dienste verwendet wird, dem Signalisierungsprotokoll und der Plattform unabhängig ist. Daher muss ein Netzbetreiber im voraus die Typen von Diensten nicht kennen, die in dem Dienstnetz aufgestellt werden, wobei dadurch eine robuste und erweiterbare Dienstaufstellungsinfrastruktur vorgesehen wird.
  • Da die Zahl von Interessengruppen, die wünschen können, ihre eigenen Dienste zu registrieren, sehr groß sein könnte, gibt es eine Notwendigkeit für Skalierbarkeit. Des weiteren kann die Zahl von Teilnehmern, die mit einer Domäne in Verbindung stehen, sehr groß sein, was die Frage von Skalierbarkeit kritisch macht. Dienste können durch viele verschiedene Typen von Ereignissen getriggert und basierend auf einer Vielzahl von unterschiedlichen Bedingungen aufgerufen werden, wie etwa Übereinstimmung von Quell- und Zieladressen, zeitabhängig oder irgendeine andere Vorbedingung. Des weiteren können nicht auf SIP bezogene Dienste in SIP-Ereignissen aufgerufen werden, z.B. falls gewisse Bedingungen zu einem gegebenen Zeitpunkt erfüllt sind. Es können unterschiedliche Diensttechnologien, wie etwa CPL, verwendet werden. Auf SIP bezogene Dienste können in nicht auf SIP bezogenen Ereignissen aufgerufen werden, z.B. HTTP-Ereignisse. Es kann Zehntausende von Diensten geben, die zig Millionen von Teilnehmern angeboten werden können, von Zehntausenden von dritten Dienstanbietern. Folglich ist die Aufgabe zum Managen von Diensten und Dienstinteraktionen eine Aufgabe, die zum Managen für einen Administrator leicht zu groß und kompliziert wird.
  • Gemäß der Erfindung wird die Zahl von Ausführungsregeln in eine Zahl von Regelmodulen gruppiert, wobei jedes Regelmodul eine Zahl von Ausführungsregeln inkludiert; und das Verfahren umfasst ferner die Schritte
    • – Verarbeiten eines ersten der Zahl von Regelmodulen, was zu einer ersten akkumulativ modifizierten Nachricht führt; und
    • – Aufrufen einer Verarbeitung eines zweiten der Zahl von Regelmodulen, was die erste akkumulativ modifizierte Nachricht als eine Eingabe vorsieht.
  • Folglich wird das Problem von Merkmalsinteraktion durch Gruppieren der Ausführungsregeln in Regelmodule, d.h. Gruppen von Ausführungsregeln, in das Problem von Merkmalsinteraktion zwischen Merkmalen, die innerhalb des gleichen Regelmoduls aufgerufen werden, und Interaktionen zwischen Regelmodulen gesplittet. Folglich ist es ein Vorteil der Erfindung, dass ein Verfahren zum Managen von Merkmalsinteraktion vorgesehen wird, welches mit der Zahl von Diensten skaliert. Wenn unterschiedliche Dienste durch unterschiedliche Dienstanbieter vorgesehen werden, z.B. unterschiedliche Firmen oder unterschiedliche Organisationsentitäten innerhalb einer Firma, kann insbesondere ein einzelner Anbieter nicht Zugriff auf alle vorgesehenen Dienste haben oder nicht in der Lage sein, sie zu testen. Daher ist es ein Vorteil der Erfindung, dass die Aufgabe zum Analysieren von Merkmalsinteraktionsanalyse gemäß Regelmodulen gesplittet und auf unterschiedliche Anbieter verteilt werden kann. Dies impliziert ferner, dass die Kosten von Dienstmanagement auf unabhängige Seiten delegiert werden können, wie die Zahl von Teilnehmern und Diensten wächst.
  • Die Interessengruppen, die Dienste auf einen SIP-Server hochladen/registrieren und administrieren wünschen können, könnten der Besitzer, Dienstanbieter oder Administrator des SIP-Servers, Netzbetreiber etc. sein. Es könnten auch unterschiedliche Typen von Einzelhändlern, z.B. virtuelle Telekom-Betreiber, Internet-Dienstanbieter etc. sein. Es können auch unterschiedliche Typen von Dienstanbietern sein, wie etwa Anwendungsdienstanbieter, Inhaltsdienstanbieter, Dienst-/Merkmalsanbieter. Auch können private Organisationen, Unternehmen und Teilnehmer mögliche Interessengruppen sein.
  • Folglich wird gemäß der Erfindung ein flexibles, erweiterbares und skalierbares Management von Vertragsbeziehungen zwischen Interessengruppen erreicht, inkludierend das Management von Abrechnung, Begleichung, Richtlinien und Sicherheit.
  • Es ist ein weiterer Vorteil der Erfindung, dass sie eine modulare Struktur von Ausführungsregeln vorsieht, wobei dadurch die Einbettung von Dienstprofilen für Benutzer, Benutzergruppen, Teilnehmer etc. ermöglicht wird. Es ist ein weiterer Vorteil der Modularität, dass sie Wiederverwendung von Regelmodulen ermöglicht, wobei dadurch die Wartung der Dienstumgebung weiter erleichtert wird.
  • Wenn jedes Regelmodul zu sich eine Priorität zugeordnet hat, die eine Reihenfolge einer Verarbeitung der Zahl von Regelmodulen anzeigt, wird die Reihenfolge einer Regelmodulausführung durch einen einfachen Parameter bestimmt, wobei dadurch leichte und transparente Steuerung über die Reihenfolge einer Ausführung von Regelmodulen vorgesehen wird.
  • Wenn jedes Regelmodul einem Regelmodulbesitzer entspricht, der autorisiert ist, das Regelmodul zu editieren, kann die administrative Autorität für ein Regelmodul einfach hergestellt werden, wobei die Delegierung administrativer Autori tät, wie etwa Editieren von Regelmodulen, Merkmalsinteraktionsanalyse innerhalb eines Regelmoduls etc. weiter erleichtert wird.
  • Gemäß der Erfindung hat das erste Regelmodul zu sich ein Privileg zugeordnet, das eine Autorität anzeigt, ein Sperrflag zu ändern, das sich auf einen vorbestimmten Teil der akkumulativ modifizierten Nachricht bezieht und spezifiziert, ob der vorbestimmte Teil der akkumulativ modifizierten Nachricht durch Dienste modifiziert werden kann, die von mindestens dem zweiten Regelmodul aufgerufen werden. Folglich wird ein Mechanismus zum expliziten Erlauben oder Verhindern von Änderungen einzelner Attribute oder Gruppen von Attributen der Nachrichten durch nachfolgende Dienste vorgesehen. Daher wird ein effizientes Werkzeug zum Verhindern von Merkmalsinteraktionen wegen dem Ändern des Kontextes von einem Dienst durch einen anderen Dienst vorgesehen. Dieser Typ von Merkmalsinteraktion wird als Verletzung von Merkmalsannahme bezeichnet, die mehrdeutiges oder Konfliktverhalten von Diensten verursachen kann. Da die Autorität, gewisse Attribute zu sperren und/oder freizugeben, mit vorbestimmten Privilegien verknüpft ist, die Regelmodulen zugeordnet sind, kann der Netzbetreiber Missbrauch von Privilegien erfassen und dadurch nicht-autorisiertes Verhalten verhindern, wobei dadurch die Sicherheit des Verfahrens erhöht wird. Privilegienverletzung kann zur Laufzeit erfasst und aufgelöst werden, z.B. durch Benachrichtigung oder Deaktivierung von Diensten.
  • Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung umfasst der Schritt zum Aufrufen einer Verarbeitung des zweiten Regelmoduls ferner den Schritt zum Setzen des Sperrflags, um eine Modifikation des vorbestimmten Teils der akkumulativ modifizierten Nachricht durch Dienste zu verhindern, die von dem zweiten Regelmodul aufgerufen werden, es sei denn, dass das Sperrflag durch das erste Regelmodul als nicht gesetzt markiert wurde. Folglich sind die Nachrichtenattribute per Vorgabe für nachfolgende Änderungen gesperrt, wenn die Steuerung von einem Regelmodul zu einem anderen transferiert wird. Daher kann das zweite Regelmodul nur Nachrichtenattribute ändern, die das erste Regelmodul explizit als nicht gesperrt markiert hat, wobei dadurch die Steuerung möglicher Merkmalsinteraktionen zwischen Regelmodulen weiter verbessert wird und eine Merkmalsanalyseaufgabe auf innerhalb der einzelnen Regelmodule eingeschränkt wird. Dies führt zu einer weiter verbesserten Skalierbarkeit.
  • Wenn der Schritt zum Erhalten einer Zahl von Ausführungsregeln ferner den Schritt zum Erfassen einer vorbestimmten Vertragsbeziehung basierend auf Headerinformation der Nachricht; und Auswählen einer Zahl von Regelmodulen basierend auf der erfassten Vertragsbeziehung umfasst, wird ein modulares und skalierbares Verfahren vorgesehen, das die Unterstützung für Betreiber ermöglicht, Dienste dritter und/benutzerdefinierte Dienste zu unterhalten. Da Vertragsbeziehungen auf der Basis von Headerinformation erfasst werden, können jene Dienste dritter oder benutzerdefinierte Dienste, die für eine gegebene Nachricht relevant sind, auf der Basis der erfassten Vertragsbeziehungen identifiziert werden.
  • Gemäß einer anderen bevorzugten Ausführungsform der Erfindung umfasst der Schritt zum Verarbeiten des ersten Regelmoduls ferner den Schritt zum Aufrufen eines vorbestimmten dritten Regelmoduls. Folglich kann ein Regelmodul andere Regelmodule aufrufen, wodurch ein leistungsfähiges Werkzeug zum Erstellen einer Hierarchie von Regelmodulen vorgesehen und die Skalierbarkeit und Flexibilität der Aufstellungsinfrastruktur weiter verbessert werden. Es ist ein Vorteil der Erfindung, dass sie die Delegierung von einem Regelmodul, das im Besitz einer Seite ist, zu einem anderen Regelmodul, das im Besitz durch eine andere Seite ist, erlaubt. Eine Seite kann Anwendungen in einer Reihenfolge aufrufen, die durch diese Seite als geeignet erachtet wird, und dann die Steuerung zu einer anderen Seite weitergeben, die dann unterschiedliche Anwendungen aufrufen kann. Die erste Seite kann anschließend die Steuerung wiedererlangen, um die Ausgabe von der zweiten Seite zu prüfen. Wenn diese Delegierung erfolgt ist, kann die erste Seite entscheiden, welche Nachrichteneigenschaften in der weitergeleiteten Nachricht nachfolgende Anwendungen ändern können, durch Anzeigen, welche Nachrichteneigenschaften für eine Aktion nicht überschrieben werden können.
  • Es ist ein Vorteil der Erfindung, dass sie eine hierarchische Delegierung administrativer Autorität basierend auf der Fähigkeit erlaubt, Regelmodule von innerhalb anderer Regelmodule zu triggern und Nachrichteneigenschaften zu sperren.
  • Wenn sich die ersten und zweiten Regelmodule auf jeweilige erste und zweite Zugriffssteuerlisten beziehen, die Zugriffsrechte auf den entsprechenden ersten oder zweiten Regelmodul spezifizieren, kann die Verletzung von Zugriffsrechten erfasst und aufgelöst werden, wobei dadurch die Sicherheit des Verfahrens weiter verbessert wird.
  • Wenn die ersten und zweiten Regelmodule jeweilige erste und zweite Skripte in einer vorbestimmten Auszeichnungssprache umfassen, wird eine einfache Sprache zum Schreiben von Regelmodulen vorgesehen. Daher ist es für einen Administrator leicht zu verstehen, wie Regeln auszudrücken sind und worin die Bedeutung der Regeln besteht, wobei dadurch ein einfacher Mechanismus zum Erweitern der Basisdefinition der Regelsprache mit proprietären Funktionen vorgesehen wird. Ein Beispiel einer derartigen Sprachdefinition ist XML.
  • Es ist ein weiterer Vorteil der Erfindung, dass sie ein erweiterbares Rahmenwerk vorsieht, d.h. es ist leicht, Proto kolle, Diensttechnologien und Nachrichteneigenschaften hinzuzufügen, z.B. falls SIP eine neue Methode hinzugefügt wird.
  • Es ist ein weiterer Vorteil der Erfindung, dass sie ein skalierbares Rahmenwerk vorsieht, d.h. es ist der gleiche Weg zum Ausdrücken von Regeln in großen ISP-Netzen und kleinen Endbenutzereinrichtungen, z.B. 3G Zellen-Telefonen, möglich.
  • Gemäß einer anderen bevorzugten Ausführungsform der Erfindung umfasst die Nachricht eine erste und zweite Menge von Attributen; die Ausführungsregeln sind in mindestens eine erste und eine zweite Verarbeitungsklasse von Ausführungsregeln gemäß entsprechenden Beschränkungen gruppiert, wobei die zweite Verarbeitungsklasse eingeschränkt ist, nur Attribute der zweiten Menge von Attributen zu modifizieren; und der Schritt zum Verarbeiten der Ausführungsregeln umfasst ferner den Schritt zum Verarbeiten der Ausführungsregeln der ersten Verarbeitungsklasse vor einer Verarbeitung einer jeglichen Ausführungsregel der zweiten Verarbeitungsklasse. Folglich sind die Dienste in Gruppen mit vorbestimmtem Verhalten im Sinne davon unterteilt, welche Teile der Signalisierungsnachrichten sie aktualisieren. Daher können sich die Dienste darauf verlassen, dass die erste Menge von Nachrichtenattributen nach der Ausführung der ersten Verarbeitungsklasse nicht geändert wird. Dies sieht einen weiteren Mechanismus zum Auf splitten der Aufgabe von Merkmalsinteraktionsanalyse in verwaltbare Teilaufgaben vor. Im Folgenden werden die Verarbeitungsklassen auch als Verarbeitungspunkte bezeichnet. Die Mengen von Attributen können Nachrichtenheaderinformation und einen Nachrichtenrumpf umfassen, der den tatsächlichen Sitzungsinhalt umfasst. Die Attribute können ferner in unterschiedliche Typen von Headerinformation gesplittet sein, z.B. Signalisierungsattribute etc.
  • Es ist ein weiterer Vorteil der Erfindung, dass sie Mittel zum Spezifizieren vorsieht, wie Anwendungen erlaubt wird zu interagieren.
  • Vorzugsweise werden die Verarbeitungsklassen in einer vorbestimmten Reihenfolge für Anfragen und Antworten verarbeitet und auf veranlassende, abschließende und "weitergeleitet durch" Dienste angewendet.
  • Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung umfasst die Nachricht eine erste und eine zweite Menge von Attributen; die Ausführungsregeln sind in mindestens eine erste und eine zweite Verarbeitungsklasse von Ausführungsregeln gemäß entsprechenden Beschränkungen gruppiert, wobei die zweite Verarbeitungsklasse beschränkt ist, nur Attribute der zweiten Menge von Attributen zu modifizieren; und das Verfahren umfasst ferner den Schritt zum Wiederholen der Schritte zum Verarbeiten des ersten Regelmoduls und Aufrufen einer Verarbeitung des zweiten Regelmoduls, wobei in jeder Wiederholung die Verarbeitung der ersten und zweiten Regelmodule auf Ausführungsregeln einer entsprechenden Verarbeitungsklasse begrenzt ist, und wobei jede Wiederholung zu einer entsprechenden akkumulativ modifizierten Nachricht führt, die als eine Eingabe für eine nachfolgende Wiederholung verwendet wird. Folglich wird eine Kombination der Unterteilung in Regelmodule mit dem Konzept von Verarbeitungsklassen vorgesehen, wobei dadurch ein fein granuliertes Rahmenwerk zum Unterteilen der Dienste gemäß administrativem Besitz und Einschränkungen, die den Diensten auferlegt sind, vorgesehen wird.
  • Wenn die Verarbeitungsklassen getrennt für Ausführungsregeln definiert sind, die durch Anfragen und Antworten des Sitzungsprotokolls getriggert werden, wird die Unterteilung von Diensten in Verarbeitungsklassen ferner gemäß dem Typ einer Nachricht auf gesplittet, wobei dadurch ein feiner granuliertes Splitten vorgesehen wird.
  • Gemäß einer bevorzugten Ausführungsform entsprechen die Verarbeitungsklassen vorbestimmten Standorten in einem Rundlaufnachrichtenfluss gemäß dem Sitzungsprotokoll, wobei dadurch die Analyse von Merkmalsinteraktion vereinfacht wird.
  • Vorzugsweise inkludieren die Verarbeitungsklassen eine erste Verarbeitungsklasse von Ausführungsregeln, die Signalisierungseigenschaften der Nachricht beeinflussen, eine zweite Verarbeitungsklasse von Ausführungsregeln, die einen Nicht-Signalisierungsnachrichtenrumpfinhalt der Nachricht beeinflussen, und eine dritte Verarbeitungsklasse von Ausführungsregeln, die weder die Signalisierungseigenschaften noch den Nicht-Signalisierungsnachrichtenrumpfinhalt der Nachricht beeinflussen. Hier umfasst der Begriff Signalisierungseigenschaften SIP- und SDP-Nachrichteneigenschaften, die in einer Regelmodulbedingung angepasst werden können, um einen Dienst aufzurufen.
  • Wenn eine resultierende modifizierte Nachricht generiert wird, wenn alle Ausführungsregeln der ersten und zweiten Verarbeitungsklassen verarbeitet sind, wird die Effizienz des Verfahrens weiter erhöht, da Antworten zurückgegeben werden können, ohne auf Dienste der dritten Verarbeitungsklasse warten zu müssen.
  • Gemäß einer anderen bevorzugten Ausführungsform der Erfindung führt Aufrufen des ersten Dienstes ferner zu einer zweiten modifizierten Nachricht; und das Verfahren umfasst ferner die Schritte zum Verarbeiten nachfolgender Ausführungsregeln mit der ersten modifizierten Nachricht als eine Eingabe; und Verarbeiten nachfolgender Ausführungsregeln mit der zweiten modifizierten Nachricht als eine Eingabe. Da ein Dienst unter schiedliche Ausgaben zurückgeben kann, von denen jede eine Eingabe zu einer Kette von nachfolgenden Diensten ist, kann daher ein Baum von kaskadierten Ketten von Diensten implementiert werden.
  • Gemäß noch einer anderen bevorzugten Ausführungsform der Erfindung umfasst das Verfahren ferner die Schritte von
    • – Speichern von Information darüber, welche Dienste ausgeführt werden, und Information darüber, in welcher Reihenfolge die Dienste ausgeführt werden;
    • – Empfangen von dem ersten Dienst einer Anfrage zum Rückgeben einer Benachrichtigung an den ersten Dienst, falls ein vorbestimmtes Ereignis auftritt;
    • – Speichern der Anfrage in Bezug auf die gespeicherte Information; und
    • – beim Auftreten des Ereignisses Benachrichtigen des ersten Dienstes gemäß der gespeicherten Information.
  • Daher wird ein effizienter Mechanismus zum Anfordern einer Benachrichtigung über zukünftige Ereignisse durch eine Dienstanwendung vorgesehen, wobei dadurch Überwachen von Anwendungen ermöglicht wird etc.
  • Wenn die Ausführungsmodule computerlesbare Skripte umfassen und die vorbestimmte Reihenfolge einer Verarbeitung der Ausführungsregeln durch die Reihenfolge von Ausführungsregeln in den Skripten bestimmt wird, wird ein einfacher Mechanismus zum Steuern der Reihenfolge einer Dienstausführung und der Reihenfolge einer Benachrichtigung bezüglich zukünftiger Ereignisse durch einen Administrator eines Regelmoduls vorgesehen.
  • Vorzugsweise wird die kaskadierte Reihenfolge von Diensten durch die Reihenfolge von Ausführungsregeln innerhalb eines Regelmoduls und die Reihenfolge von Regelmodulen bestimmt.
  • Wenn die Ausführungsregeln angepasst sind, dynamisch aktualisiert zu werden, d.h. während eines Betriebs des Dienstnetzes, wird ein Echtzeitdienstmanagement vorgesehen.
  • Die Erfindung bezieht sich ferner auf ein Datenverarbeitungssystem, umfassend ein Dienstausführungsumgebungsmodul, angepasst, eine Vielzahl von Diensten aufzurufen, getriggert durch eine Nachricht eines Sitzungsprotokolls, das eine Kommunikationssitzung steuert;
    gekennzeichnet dadurch, dass
    das Datenverarbeitungssystem ferner ein Speichermedium umfasst, angepasst, eine Vielzahl von Ausführungsregeln zu speichern, jede von denen eine Bedingung zum Aufrufen eines Dienstes spezifiziert; und
    das Dienstausführungsumgebungsmodul ein Regelantriebsmodul umfasst, angepasst
    • – eine Zahl von Ausführungsregeln abzufragen; und
    • – die Ausführungsregeln in einer vorbestimmten Reihenfolge zu verarbeiten, wobei eine erste Ausführungsregel bewirkt, dass ein erster Dienst aufzurufen ist, falls die Nachricht eine erste Bedingung erfüllt, was zu einer ersten modifizierten Nachricht führt; und eine zweite Ausführungsregel, die bewirkt, dass ein zweiter Dienst mit der ersten modifizierten Nachricht als eine Eingabe aufzurufen ist, falls die erste modifizierte Nachricht eine zweite Bedingung erfüllt.
  • Die Erfindung bezieht sich ferner, in einem Datenverarbeitungssystem, auf ein Dienstausführungsumgebungsmodul, angepasst, eine Vielzahl von Diensten aufzurufen, getriggert durch eine Nachricht eines Sitzungsprotokolls, das eine Kommunikationssitzung steuert;
    gekennzeichnet dadurch, dass
    das Dienstausführungsumgebungsmodul ein Regelantriebsmodul umfasst, angepasst
    • – eine Zahl von Ausführungsregeln abzufragen, von denen jede eine Bedingung zum Aufrufen eines Dienstes spezifiziert;
    • – die Ausführungsregeln in einer vorbestimmten Reihenfolge zu verarbeiten, wobei eine erste Ausführungsregel bewirkt, dass ein erster Dienst aufzurufen ist, falls die Nachricht eine erste Bedingung erfüllt, was zu einer ersten modifizierten Nachricht führt; und eine zweite Ausführungsregel bewirkt, dass ein zweiter Dienst mit der ersten modifizierten Nachricht als eine Eingabe aufzurufen ist, falls die erste modifizierte Nachricht eine zweite Bedingung erfüllt.
  • Die Erfindung bezieht sich ferner auf ein Softwareprogramm, umfassend Codemittel, angepasst, wenn in einem Datenverarbeitungssystem ausgeführt, die Schritte des oben beschriebenen Verfahrens und in dem folgenden durchzuführen.
  • Das Softwareprogramm kann auf einem computerlesbaren Medium verkörpert sein. Der Begriff computerlesbares Medium kann inkludieren ein magnetisches Band, eine optische Platte, eine digitale Videoplatte (DVD), eine Kompaktdisk (CD oder CD- ROM), eine Minidisk, eine Festplatte, eine Diskette, einen ferro-elektrischen Speicher, einen elektrisch löschbaren programmierbaren Nur-Lesespeicher (EEPROM), einen Flash-Speicher, einen EPROM, einen Nur-Lesespeicher (ROM), einen statischen Speicher mit wahlfreiem Zugriff (SRAM), einen dynamischen Speicher mit wahlfreiem Zugriff (DRAM), einen synchronen dynamischen Speicher mit wahlfreiem Zugriff (SDRAM), einen ferromagnetischen Speicher, einen optischen Speicher, ladungsgekoppelte Einrichtungen, Smart-Karten, eine PCMCIA-Karte etc.
  • Die Erfindung bezieht sich ferner auf ein Verfahren zum Managen der Aufstellung eines Dienstes in einem Dienstnetz, wobei das Verfahren die Schritte umfasst zum
    • – Spezifizieren in einem computerlesbaren Skript einer Zahl von Privilegien und Rechten, die dem Dienst während einer Operation zu gewähren sind;
    • – Analysieren von potenziellen Ursachen von Merkmalsinteraktion;
    • – Spezifizieren einer Aufstellungsstrategie für den Dienst als eine Menge von Ausführungsregeln, die als ein computerlesbares Regelmodulskript gespeichert werden.
  • Die Erfindung bezieht sich ferner auf einen Datensatz, umfassend ein Regelmodul zur Verwendung in dem oben beschriebenen Verfahren und in dem folgenden.
  • Diese und andere Aspekte der Erfindung werden offensichtlich aus den und erklärt mit Bezug auf die Ausführungsformen und mit Bezug auf die Zeichnungen, in denen:
  • 1 unterschiedliche Typen von Merkmalsinteraktionen in einem SIP-Dienstnetz veranschaulicht;
  • 2 die Netzelemente veranschaulicht, die in einer Dienstumgebungs-SIP-Serverarchitektur gemäß einer Ausführungsform der Erfindung involviert sind;
  • 3 schematisch eine Systemarchitektur eines SIP-Servers veranschaulicht, die einen Dienstausführungsregelmechanismus gemäß einer Ausführungsform der Erfindung unterstützt;
  • 4 die Struktur eines Regelmoduls gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 5 die Gruppierung von Diensten in eingeschränkte Mengen von Diensten gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 6 die Gruppierung von Diensten in eingeschränkte Mengen von Diensten entsprechend Standorten in dem Rundlauf-SIP-Nachrichtenfluss gemäß einer bevorzugten Ausführungsform der Erfindung veranschaulicht;
  • 7 den Verarbeitungsfluss zwischen Diensten, die zu unterschiedlichen Verarbeitungspunkten gehören, gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 8 die Gruppierung von Diensten in Regelmodule entsprechend administrativer Autorität gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 9 eine Ausführungsform der Erfindung veranschaulicht, wo Dienste sowohl gemäß Verarbeitungspunkten als auch gemäß administrativer Autorität gruppiert werden;
  • 10 den Verarbeitungsmechanismus der Ausführungsform von 9 im Fall mehrerer Regelmodule und mehrerer Verarbeitungspunkte veranschaulicht;
  • 11 ein anderes Beispiel der Verarbeitungsregeln veranschaulicht, die in Verbindung mit 9 beschrieben werden;
  • 12 eine hierarchische Regelmodulverarbeitung gemäß einer bevorzugten Ausführungsform der Erfindung veranschaulicht;
  • 13 ein Beispiel des Flusses von SIP-Nachrichtenereigniskontexten und Instruktionsmengen gemäß einer Ausführungsform der Erfindung zeigt;
  • 14 einen Mechanismus zum Managen mehrerer Instruktionsmengen gemäß einer bevorzugten Ausführungsform der Erfindung veranschaulicht;
  • 15 einen Baum von kaskadierten Ketten von Dienstanwendungen gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 16 die Softwarekomponenten einer Dienstunterstützungsumgebung gemäß einer Ausführungsform der Erfindung zeigt;
  • 17 Schritte zeigt, die durch das Dienstinteraktionsmodul durchgeführt werden, zwischen der Verarbeitung des Regelmoduls und der Verarbeitung der Dienstanwendung in der Ausführungsform von 16;
  • 18 die Baumstruktur der Verarbeitung von Regelmodulen gemäß einer Ausführungsform der Erfindung veranschaulicht;
  • 19 die rekursive Verarbeitung von Regelmodulen in einer Situation, wo Dienstanwendungen neue Ereigniskontexte gene rieren, gemäß einer Ausführungsform der Erfindung veranschaulicht; und
  • 20 einen Mechanismus zum Durchsetzen einer Zugriffssteuerung in Verbindung mit Regelmodulen gemäß einer Ausführungsform der Erfindung veranschaulicht.
  • 1 veranschaulicht unterschiedliche Typen von Merkmalsinteraktionen in einem SIP-Dienstnetz. Mit der Einführung von SIP entsteht ein neuer Bereich von Konversations- und Echtzeitdiensten in dem Internet. Diese Dienste 101–105 können durch Endbenutzerendgeräte 106–108, auch Benutzeragenten (UA) genannt, oder einen oder mehrere Zwischennetzserver 109 gemanagt werden. Zwischenserver 109 können Mehrwertdienste 102–103 zu veranlassenden und/oder abschließenden Benutzeragenten vorsehen, aber auch zu dem zugehörigen Medienclient und Serveranwendung(en). Diese Zwischenserver können Proxyserver, Umlenkungsserver, dedizierte Anwendungsserver oder sogar Benutzeragenten sein.
  • Kommunikationsnachrichten, die zwischen den Benutzeragenten gesendet werden, werden durch den Zwischenserver 109 über das Internet 110 oder ein anderes Kommunikationsnetz weitergeleitet. Ein fundamentales Problem, das durch einen Zwischen-SIP-Server 109 gemanagt wird, besteht darin, die Erwartungen einer Dienstebene eines Benutzers zu erfüllen, um gutes Netzleistungsverhalten aufrechtzuerhalten und eine flexible und skalierbare Definition von neuen Diensten zu erlauben. Da Leistungsverhalten ein Schlüsselproblem ist, sollte die Architektur einigen Diensten erlauben, auf dem SIP-Server ausgeführt zu werden. Da es nicht machbar oder möglich sein kann, gewisse Dienste auf dem SIP-Server auszuführen, sollte die Architektur ebenso erlauben, dass Dienste auf entfernten Servern ausgeführt werden.
  • Es gibt eine Notwendigkeit für Flexibilität von Dienstdefinition, da die Funktionalität des SIP-Servers nicht im voraus definiert werden sollte. Insbesondere können Dienste kontinuierlich von einem Bereich von Quellen, inkludierend Dienstanbieter und Teilnehmer, hochgeladen/registriert werden.
  • Der Besitzer des SIP-Servers kann zur gleichen Zeit der SIP-Dienstanbieter, Administrator und Abonnementanbieter sein. Diese Interessengruppe wird als ein Netzbetreiber bezeichnet; es kann eine Art von Telco oder ISP sein. Der Netzbetreiber kann den Domänennamen des SIP-Servers besitzen und Dienstanbietern einer dritten Seite Dienstmerkmale bereitstellen. Der Netzbetreiber installiert Dienstanwendungen und Regelmodule auf dem SIP-Server und bietet Teilnehmern Dienste an. In diesem Fall agiert der Netzbetreiber als ein Dienstanbieter und Dienstadministrator. Ein Teilnehmer hat eine vertragliche Beziehung mit dem Netzbetreiber, um ein Abonnement zu haben und um die Teilnehmerdienste zu empfangen, die durch den SIP-Server angeboten werden. Der Teilnehmer kann einen Dienst haben, der dem Teilnehmer erlaubt, Dienstanwendungen und Regelmodule zu dem SIP-Server hochzuladen. Der Teilnehmer besitzt diese Dienste für einen privaten Gebrauch, d.h. personalisierte Dienste. Zur Einfachheit werden alle Seiten mit Ausnahme des (der) Netzbetreiber(s) und der Teilnehmer als Dienstanbieter einer dritten Seite bezeichnet, die eine vertragliche Beziehung mit dem Netzbetreiber haben.
  • Netzserverbesitzer, Netzserveranbieter, Netzserveradministratoren, Dienstanbieter einer dritten Seite und Teilnehmer betrachten die Zwischen-SIP-Server als eine potenzielle Plattform zum Aufstellen von Diensten, die aus dem einen oder anderen Grund nicht in Endpunktbenutzeragenten aufgestellt werden können oder sollten.
  • Es gibt einen Bereich von standardisierten Protokollen (z.B. SIP, SDP, SOAP), Sprachen (z.B. CPL) und Schnittstellen (z.B. SIP-CGI, 3GPP OSA API), die unterschiedliche Aspekte einer Dienststeuerung handhaben. Auch ist es wahrscheinlich, dass Dienste ihre Steuerung über mehrere Protokolle, Netzkomponenten, Sprachen und Schnittstellen anwenden. Der SIP-Server sollte erweiterbar sein, um alle diese Aspekte wie erforderlich zu unterstützen. Diese Dienstanwendungen können sich im Besitz unterschiedlicher Seiten befinden, die unterschiedliche Autorisierungsstufen und unterschiedliche vertragliche Beziehungen mit dem Besitzer des SIP-Servers haben. Die Dienstanwendungen können der Vorgabeverarbeitung von SIP-Anfragen und Antworten in unterschiedlichen spezifizierten Ruf-/Sitzungsverarbeitungspunkten, unter unterschiedlichen Bedingungen etc. einen Wert hinzufügen (sind aber nicht darauf begrenzt, dies zu tun).
  • Das folgende Beispiel veranschaulicht, dass es wahrscheinlich ist, dass mehrere Dienste basierend auf einem SIP-Ereignis aufgerufen werden können. Es wird ein Beispiel betrachtet, wo ein Teilnehmer, sagen wir Bob, ein SIP-Abonnement mit irgendeinem SIP-Anbieter, sagen wir Telco, hat. Bob hat einen Bereich von Diensten, die der in dem Netz platzieren möchte. Dienste, wie endgeräteunabhängige Dienste oder Dienste, die zu welchem auch immer Endgerät maßgeschneidert werden, welches Bob gegenwärtig verwendet. Es kann auch Dienste geben, die Bob mit Sicherheit, Privatsphäre und Zuverlässigkeit versehen. Auch wünscht Bob nicht, seine eigenen Dienste zu managen. Es wird ferner angenommen, dass Bob in einer Firma arbeitet, sagen wir Corp. Die Dienste, die aufgerufen werden, um eine eingehende EINLADEN-Nachricht an Bob zu managen, können wie folgt aussehen:
    Die Telco kann den SIP-Server besitzen und administrieren. Die Telco stellt auch Teilnehmern SIP-Dienste bereit und un terhält Dienste dritter Seiten. Die Telco erkennt, dass Bob ein Teilnehmer in einem eingehenden EINLADEN ist. Der erste Dienst ist eine Telco-Rufsperranwendung um zu prüfen, ob Bob seine letzte Rechnung bezahlt hat. Der zweite Dienst ist ein Dienst, der durch die Telco bereitgestellt wird. Er prüft einfach, dass die Medien-Codecs des Anrufers durch Bob's gegenwärtigen Standort/Endgerät gehandhabt werden können. Falls nicht, wird die Anwendung einen Medienstromkonverter in den Medienstromfluss anfordern (unter Verwendung einer Rufsteuerung einer dritten Seite). Diese Konvertierung ist für Bob transparent, und die Anwendung wird Antworten von Bob überwachen und die Sitzungsbeschreibungen je nach Notwendigkeit aktualisieren. Der dritte Dienst sind Bob's eigene Präferenzen für Angerufene, z.B. ein CPL-Skript. Diese Anwendung überwacht Antworten auf die bevollmächtigte Anfrage und leitet basierend darauf möglicherweise das EINLADEN zu mehreren Zielen weiter. Sagen wir, das EINLADEN ist zu Bob's gegenwärtigen privaten SIP URL. Bei "keine Antwort" wird das EINLADEN stellvertretend zu seiner Frau Alice gegeben. In einigen Fällen wünscht Bob, dass alle privaten Anrufe zu seinem Firmen-SIP-URL umgelenkt werden. Der vierte Dienst ist auch ein Telco-Dienst, wird aber zu der Telco von einem Anwendungsdienstanbieter einer dritten Seite bereitgestellt, sagen wir besafe.com. Dieser Dienst prüft Nachrichtenrumpfinhalttypen und stellt eine Virusprüfung bereit, wenn benötigt, z.B. falls eine animierte vCard inkludiert ist. Der fünfte Dienst ist ein ISP-Dienst, der die Multimediawerbung des Angerufenen im Gegenzug zu einer Erstattung der Abrechnung der Telco anbietet. Falls die Sitzung hergestellt wird, und falls es eine Videokonferenzsitzung ist, empfängt Bob einen kleinen fließenden Balken von Information unten in dem Videobild. Dieser Dienst ist eine Überwachungsanwendung und verwendet eine Rufsteuerung einer dritten Seite. Der ISP hat ein Konto auf dem SIP-Server der Telco und kann Dienste der Teilnehmerbasis, die im Besitz durch die Telco ist, direkt anbieten. Bob hat diesen Dienst direkt bei dem ISP abonniert, ohne Einbeziehung der Telco. Der sechste Dienst ist ein Dienst, der durch die Firma gemanagt wird, wo Bob arbeitet. Falls der Ruf direkt zu Bob's gegenwärtigem Firmen-SIP-URL ist, wird der Ruf dann zu Bob weitergeleitet, basierend auf Daten, die nur innerhalb des privaten LAN-Netzes der Corp bekannt sind. Der letzte und siebte Dienst dient administrativen Zwecken, da die Telco irgendeine Protokollierung durchführen wollen kann.
  • Das obige Beispiel veranschaulicht die Vielfalt von vertraglichen Beziehungen, die mit den unterschiedlichen Diensten in Verbindung stehen, die durch ein Ereignis getriggert werden. Die Dienste können sich im Besitz unterschiedlicher Interessengruppen befinden und können unter Verwendung unterschiedlicher Technologien implementiert sein.
  • Unterschiedliche Dienste, die in einem Dienstnetz aufgestellt sind, können miteinander interagieren. Diese Interaktionen können zwischen Diensten, die sich auf einen einzelnen Benutzer, mehrere Benutzer beziehen, oder zwischen Kundendiensten und Systemdiensten auftreten. Die Interaktion kann ferner zwischen Diensten, die in der gleichen Netzkomponente oder in einer anderen Netzkomponente laufen, auftreten. In 1 werden unterschiedliche Typen von Interaktionen veranschaulicht: Interaktionen Einzelbenutzer- mehrere Komponenten (single user – multiple component, SUMC), Kunde – System (customer – system, CUSY), mehrere Benutzer – Einzelkomponente (multiple user – single component, MUSC), mehrere Benutzer – Mehrfachkomponente (multiple user – multiple component, MUMC) und Einzelbenutzer – Mehrfachkomponente (single user – multiple component, SUMC).
  • Es gibt viele Ursachen für Merkmalsinteraktion, inkludierend "Verletzung von Merkmalsprivilegien" und "Verletzung von Merkmalsannahmen":
    Verletzung von Merkmalsprivilegien: Privilegien von Merkmalen werden gebrochen, falls Merkmale redundant oder durch nicht-autorisierte Seiten aufgerufen werden. Das Hauptproblem, das durch Verletzen von Merkmalsprivilegien verursacht wird, ist redundanter Verbrauch von Ressourcen oder nicht-autorisierter Zugriff zu Ressourcen. Dies kann im Wesen unbeabsichtigt oder böswillig sein. Wenn eine Verletzung von Merkmalsprivilegien auftritt, dann gibt es einen Kampf zwischen Merkmalen, autorisierten oder nicht-autorisierten, um Zugriff auf die Ressourcen. Falls Merkmale redundant oder durch nicht-autorisierte Seiten aufgerufen werden, können sie anschließend die Ursache einer Verletzung von Merkmalsannahmen sein. Es ist klar, dass Vermeidung von Verletzung von Merkmalsprivilegien wünschenswert ist.
  • Wie nachstehend beschrieben wird, werden gemäß der Erfindung Verletzungen von Merkmalsprivilegien durch Filtern im Kontext, in vertraglichen Beziehungen, in Bedingungen, in Zugriffssteuerlisten, Privilegien und Rechten aufgelöst.
  • Filtern im Kontext bezieht sich auf die Notwendigkeit zum Interpretieren eines Ereignisses in einem gewissen Kontext. Dieses Muss wird offensichtlich, wenn vernetzte Multimediadienste gemanagt werden, die in einem konvergierten Netz arbeiten.
  • Filtern in vertraglichen Beziehungen bezieht sich auf die Notwendigkeit zum Abbilden eines Ereignisses auf eine Menge von Merkmalen, die vertraglich verbunden sind, um dieses Ereignis zu verarbeiten. Dieser Problemkreis ist insbesondere auf einem deregulierten Markt wichtig, wo nicht nur der Anbieter der Netzinfrastruktur und von Sitzungssteuerdiensten Teilnehmern Mehrwertdienste anbieten kann, sondern wo ebenso dritte Seiten ein legales Recht haben, dieses Angebot durchzuführen.
  • Filtern in Zugriffssteuerrichtlinien stellt sicher, dass ein Ereignis nur autorisiertes Verhalten in dem Knoten verursacht.
  • Filtern in Bedingungen stellt sicher, dass ein Merkmal nicht redundant aufgerufen wird, wenn ein Ereignis auftritt, und Merkmale, die auf zurufen sind, basierend auf dem Kontext, auf vertraglichen Beziehungen und Zugriffsprivilegien erfasst werden. Diese Bedingungen können z.B. von den Eigenschaften des Ereignisses, Systemeigenschaften oder Netzeigenschaften abhängen.
  • Verletzung von Merkmalsannahmen: Annahmen über Merkmalsverhalten werden gebrochen, falls der Kontext eines Merkmals durch ein anderes Merkmal auf eine derartige Weise geändert wird, dass das Merkmal nicht wie beabsichtigt arbeiten kann. Eine Verletzung von Merkmalsannahmen kann mehrdeutiges oder Konfliktverhalten verursachen.
  • Merkmale sind das sichtbare Verhalten einer Ausführung einer Dienstanwendung. Eine Instruktion, die durch die Dienstanwendungsausgaben erteilt wird, um das Mehrwertverhalten des SIP-Knotens zu steuern, wird eine Merkmalsinstruktion genannt. Viele Merkmale können jedoch ihr Verhalten auf eine Nachricht anwenden, bevor die steuernde Instruktion zurück zu dem SIP-Knoten gesendet wird. Die steuernde Instruktion oder Instruktionsmenge, die zurück zu dem SIP-Knoten gesendet wird, wird eine Dienststeuerinstruktion genannt. Sie enthält einen resultierenden Ereigniskontext, d.h. die Eigenschaften einer SIP-Nachricht, die als Reaktion auf den ursprünglichen Ereigniskontext stromaufwärts oder stromabwärts zu senden ist, der die Dienstanwendungen getriggert hat. Mehrdeutiges Verhalten tritt auf, wenn die Dienststeuerinstruktion abhängig von der Sequenz, in der die Merkmale Steuerung über den aktuellen Ereigniskontext erlangen, unterschiedlich ist. Mehrdeutige Instruktionen sind nicht notwendigerweise gegenseitig ausschließend.
  • Als ein Beispiel enthalte ein SIP-Nachrichtenrumpf ein Farbbild im GIF-Format. S1 wird definiert, eine Dienstanwendung zu sein, die in einem Nachrichtenrumpfinhalt vom GIF-Format getriggert wird. S1 sei eine Dienstanwendung, die das GIF-Format in ein JPG-Format konvertiert. Des weiteren wird S2 definiert, eine Dienstanwendung zu sein, die auch in einem Nachrichtenrumpfinhalt vom GIF-Format getriggert wird. S2 sei eine Dienstanwendung, die das GIF-Bild in ein Schwarzweißbild konvertiert.
  • S1 sei die erste Anwendung, die aufzurufen ist, getriggert durch den GIF-Inhalt. S1 wird das GIF-Bild zu einem JPG-Bild konvertieren und es zu dem aktuellen Ereignisinhalt schreiben. S2 wird niemals aufgerufen. Der resultierende Ereignisinhalt wird ein JPG-Farbbild enthalten.
  • Nun sei S2 die erste aufzurufende Anwendung, getriggert durch den GIF-Inhalt. S2 wird das GIF-Farbbild in ein Schwarzweißbild konvertieren und es zu dem aktuellen Ereigniskontext schreiben. S1 wird anschließend basierend auf dem GIF-Inhalt aufgerufen, wie durch den aktuellen Ereigniskontext spezifiziert. S1 wird das GIF-Bild zu einem JPG-Bild konvertieren und es zu dem aktuellen Ereigniskontext schreiben. Der resultierende Ereigniskontext wird ein JPG-Schwarzweißbild enthalten.
  • S1 und S2 weisen klar mehrdeutiges Verhalten auf, da der Kontext eines Merkmals durch das andere geändert wird.
  • In Konflikt stehende Merkmalsinstruktion sind Instruktionen, die sich gegenseitig ausschließen. In Konflikt stehende Instruktionen werden versuchen, einander zu überschreiben. In diesem Fall sind in Konflikt stehende Instruktionen typischerweise auch die Ursache von mehrdeutigem Verhalten.
  • Des weiteren sind alle Merkmalsinstruktionen potenzielle nicht-autorisierte Instruktionsmengen, es sei denn, sie sind explizit autorisiert. Nicht-autorisierte Merkmalsinstruktionen können ein böswilliges Wesen aufweisen oder das Ergebnis einer fehlerhaften Dienstanwendung sein. In jedem Fall können sie die Sicherheit und Integrität des Systems beschädigen und sollten erfasst werden.
  • Überwachende Dienstanwendungen können zusätzliche Probleme zu jenen bereits erörterten verursachen. Überwachende Dienstanwendungen können jederzeit asynchrone Merkmalsinstruktionen zu dem SIP-Knoten erteilen, da sie kontinuierlich laufen. Da sie zukünftige Ereignisse überwachen, können sie in diesen Ereignissen ausgeführt werden und mehr Merkmalsinstruktionen vorsehen. Falls es mehrere gleichzeitige überwachende Dienstanwendungen gibt, können ihre generierten Merkmalsinstruktionen von der Reihenfolge abhängen, in der sie über das Ereignis benachrichtigt werden. Dies trägt zur Komplexität der zuvor erörterten Probleme bei.
  • Die Erfassung und Auflösung von Verletzungen von Merkmalsannahmen ist viel komplizierter als die Auflösung von Verletzungen von Merkmalsprivilegien. Wie nachstehend beschrieben wird, werden gemäß der Erfindung vorgesehen Mittel um zu spezifizieren, wie mehrdeutiges Verhalten aufzulösen ist, Mittel, um das Merkmalsinteraktionsmanagement in unabhängige Merkmalsgruppen und Administrationsdomänen zu unterteilen, und eine einfache Vorgaberegel, um Merkmalsinteraktionsinterferenz aufzulösen, die zur Laufzeit erfasst wird. Verletzun gen von Merkmalsannahmen werden durch Merkmalsordnung basierend auf dem kaskadierten Kettenprinzip und Bedingungstriggerung, und Merkmalseigenschaften basierend auf dem Sperr-/Freigabemechanismus aufgelöst. Dies wird nachstehend detaillierter beschrieben.
  • Andere Ursachen von Merkmalsinteraktion inkludieren Begrenzungen von Netzunterstützung, z.B. begrenzte Protokollfunktionalität oder begrenzte Benutzerschnittstellen, in verteilten Systemen innewohnende Probleme, wie etwa Ressourcenwettstreit, Merkmalskoordination, Zeiteinstellung oder nichtatomare Operationen, Verletzung von Systemsicherheit, betrügerische, manipulierte oder abgehörte Nachrichten, nicht-kooperative Interaktionen durch Merkmale mit in Konflikt stehenden Interessen etc.
  • Im allgemeinen können drei unterschiedliche Typen von Lösungen für Merkmalsinteraktionsprobleme unterschieden werden: Infrastruktur: Die Entwicklung von Infrastrukturen für die Aufstellung von Merkmalen, die Merkmalsinteraktionsmanagement integrieren, d.h. die die Ursachen von einigen definierten Merkmalsinteraktionen behandeln. Merkmalsinteraktionen werden sowohl vor (Spezifikation) als auch nach (Durchsetzung) der Merkmalsaufstellungszeit gemanagt, d.h. während Spezifikation oder durch Durchsetzung von regelbasierten Richtlinien etc. Gemäß der Erfindung bilden die Regelmodulskripte eine Infrastruktur zum Aufstellen von Merkmalen, die ein Rahmenwerk für ein Merkmalsinteraktionsmanagement vorsieht.
  • Diensterstellung: Die Gestaltung von Merkmalen in Bezug auf Ursachen von Merkmalsinteraktionen, d.h. die Erfassung von Merkmalsinteraktionen während der Gestaltungsphase. Diese Merkmalsinteraktionen können vor Merkmalsaufstellung gemanagt werden, z.B. über Deutlichkeit, Merkmalsinteraktionsursachen analyse, Verifizierungstest etc. Gemäß der Erfindung werden der Diensterstellung und Merkmalsaufstellungsstrategiespezifikation Anforderungen auferlegt.
  • Laufzeit: Die Auflösung von Merkmalsinteraktionen, wie sie auftreten. Da nicht alle Merkmalsinteraktionen vor einer Merkmalsaufstellung identifiziert werden können, müssen sie zur Laufzeit erfasst werden, z.B. durch kryptografische Authentifizierung, Autorisierung und Geheimhaltung, regelbasierte Richtlinien, Auflösungsalgorithmen, AI-Verhandlung etc. Gemäß der Erfindung werden einfache Regeln dafür vorgesehen, wie Merkmalsinteraktionen aufgelöst werden, die zur Laufzeit erfasst werden. Diese Regeln inkludieren die Überprüfung von Zugriffssteuerlisten, die mit Regelmodulen in Verbindung stehen, die Auflösung von Zugriffsverletzungen durch Alarmbenachrichtigung und Außerbetriebnahme von verletzenden Regelmodulen, die Überprüfung von Skripten, die Privilegien und Rechte spezifizieren, und die Auflösung von Verletzungen von Privilegien und Rechten durch Alarmbenachrichtigung und Außerbetriebnahme von verletzenden Merkmalen.
  • Der allgemeine Managementprozess gemäß der Erfindung inkludiert die folgenden Schritte:
    • 1. Merkmalsgestaltungsspezifikation, unabhängig von anderen Merkmalen: Ein Dienst wird ohne Betrachtung von Interaktionen mit anderen Merkmalen gestaltet und spezifiziert. Gemäß einer Ausführungsform der Erfindung wird der Dienst jedoch in Hinsicht auf das nachstehend beschriebene Verarbeitungspunktemodell gestaltet.
    • 2. Vertragsverhandlung Die Seite, die wünscht, einen Dienst in dem Dienstnetz aufzustellen, verhandelt mit dem Administrator des Dienstnetzes, welche Privilegien und Rechte dem Dienst gewährt werden können. Gemäß einer Ausführungsform der Erfindung wird ein Privilegien- und Rechteskript, das mit dem Dienst in Verbindung steht, erstellt.
    • 3. Merkmalsinteraktionsanalyse: Die möglichen Merkmalsinteraktionen werden basierend auf Erfahrung und möglicherweise Kenntnis über einige der Merkmale, die in dem Dienstnetz aufgestellt sind, untersucht.
    • 4. Merkmalsaufstellungsstrategiespezifikation: Der Autor eines Regelmoduls, der den Dienst aufstellen muss, erlangt eine administrative Domäne. Basierend auf der Merkmalsinteraktionsanalyse und Kenntnis über den Dienst, Teilnehmer und Benutzer wird die Merkmalsaufstellungsstrategie in einem Regelmodulskript spezifiziert.
    • 5. Merkmalsimplementierung.
    • 6. Verifizierungstest.
    • 7. Merkmalsinstallation und Aktivierung.
    • 8. Merkmalslaufzeitverhalten und Management.
    • 9. Merkmalsdeaktivierung und Deinstallation.
  • Gemäß der Erfindung wird ein Rahmenwerk für Merkmalsinteraktionsmanagement vorgesehen, welches
    • – der Analysestufe erlaubt, leicht auf Spezifikationsregeln durch Vorsehen einer einfachen Sprache und eines Rahmenwerkes mit leicht zu verstehenden Prinzipien abgebildet zu werden,
    • – klare Grenzen zwischen den Gruppierungen von Merkmalen, die zu einer gegebenen Analyseentität bekannt sind, und jenen, die es nicht sind, definiert,
    • – einfache und somit leicht verständliche Regeln für die Übergabe einer Steuerung zwischen diesen Gruppen von Merkmalen vorsieht. Wenn von einer Gruppe von Merkmalen zu einer anderen übergeben wird, gibt es einen Mechanismus zum Sicherstellen, dass eine nachfolgende Gruppe von Merkmalen die vorherige Gruppe nicht kompromittiert, und
    • – die Analysestufe durch Spezifizieren von Verarbeitungspunkten in der Verarbeitung von Ereignissen vereinfacht, in denen Vorbedingungen garantiert werden und in denen Anwendungen nur erlaubt wird, gewisse Instruktionen zu dem Server zu geben.
  • 2 veranschaulicht die Netzelemente, die in eine Dienstumgebungs-SIP-Serverarchitektur gemäß einer Ausführungsform der Erfindung involviert sind. Der vorherige SIP-Client 203 (previous sip client, PSC) repräsentiert einen beliebigen Client, wie etwa einen SIP-freigegebenen PC, ein drahtloses Endgerät, einen Proxy eines vorherigen Sprungs, ein SIP-/PSTN-Gateway etc. Der Client führt Anfragen für Sitzungsdienste mit eingehenden Anfragen zu dem SIP-Server 202 durch. Der SIP-Server 202 repräsentiert den Proxy, Umlenkungs- oder dedizierten SIP-freigegebenen Anwendungsserver, wo die Dienstunterstützungsumgebung 201 implementiert ist. Alternativ kann es eine beliebige andere SIP-freigegebene Entität sein, die Mehrwertdienste triggert, wie etwa einen Benutzeragenten, Archivar oder dergleichen. Dienste, die sich in der SIP-Serverdienstunterstützungsumgebung 201 befinden, werden durch Dienstanwendungen definiert, wie etwa SIP-CGI-Skripte, Regelmodule und Dienstmerkmale. Der SIP-Knoten 202 kann die Steuerung zu der Dienstunterstützungsumgebung 201 (service support environment, SSE) bei Empfang eines Ereignisses übergeben. Die Dienstunterstützungsumgebung 201 kann anschließend eine relevante Dienstanwendung gemäß gewissen Filterkriterien und basierend auf diesem Ereignis aufrufen. Die Dienstanwendung schickt eine Merkmalsinstruktion oder eine Menge von Instruktionen zurück. Die Dienstunterstützungsumgebung 201 gibt die Steuerung zu dem SIP-Knoten 202 zusammen mit Dienststeuerinstruktionen zurück, was den SIP-Knoten 202 darüber informiert, wie das Ereignis zu verarbeiten ist. Der SIP-Knoten leitet die Anfrage zu dem nächsten SIP-Client (next SIP client, NSC) 204 weiter. Antworten auf die Anfrage werden in der entgegengesetzten Richtung von dem nächsten SIP-Client 204 über den SIP-Knoten 202 zu dem vorherigen SIP-Client 203 weitergeleitet, wobei möglicherweise zusätzliche Dienste getriggert werden. Der nächste SIP-Server 204 repräsentiert einen beliebigen Server, z.B. einen SIP-freigegebenen PC, ein drahtloses Endgerät, einen Proxy eines nächsten Sprungs, ein SIP-/PSTN-Gateway etc. Der Server handhabt eingehende Anfragen. Der entfernte Server 206 bietet eine entfernte Dienstausführung an, z.B. in einer anderen Dienstunterstützungsumgebung. Basierend auf z.B. Leistungsverhaltenskriterien kann die Dienstunterstützungsumgebung 201 eine Verarbeitung in dem entfernten Server 206 initiieren, z.B. durch Verwendung von Anfrage-/Antwortprotokollen. Auf diese Weise können unterschiedliche Kategorien von Diensten aufgerufen und auf unterschiedlichen Hosts gemanagt werden. Das Protokoll, das zu dem entfernten Server verwendet wird, kann ein beliebiges Protokoll sein, das Anfrage-/Antwortdialoge unterstützt, z.B. SIP, ICAP, HTTP, OSA API etc. Der Administrationsserver 205 führt administrative Aufgaben in der Dienstumgebung durch. Er ist für eine Konfiguration der Dienstunterstützungsumgebung 201 verantwortlich, die mit der Domäne des SIP-Knotens 202 in Verbindung steht. Daher inkludiert die Umgebung der Dienstunterstützungsumgebung 201 einen SIP-Knoten, Dienstanwendungen, entfernte Hosts und eine Administrationsentität.
  • 3 veranschaulicht schematisch eine Systemarchitektur eines SIP-Servers, die einen Dienstausführungsregelmechanismus gemäß einer Ausführungsform der Erfindung unterstützt. Die Dienstunterstützungsumgebung 301 setzt die Aufstellungsinfrastruktur durch, d.h. wie ein Merkmal mit einem anderen interagiert. Daher sieht die Dienstunterstützungsumgebung 301 die Funktionalität in dem SIP-Server vor, die Mehrwertdienste unterstützt. Die Dienstunterstützungsumgebung 301 umfasst einen Regelantrieb (rule engine, RE) 303 zum Managen der Regelmodule 308, die in einer Ausführungsregelbasis 307 gespeichert sind. Der Regelantrieb 303 umfasst ferner ein Regelmodulausführungsmodul (rule module execution module, RMEM) 314, das für eine Verarbeitung von Regelmodulen verantwortlich ist. Der Regelantrieb kann Dienste 309–311 über den Dienstausführungsantriebsmanager 302 aufrufen. Der Dienstdefinitionsmanager (service definition manager, SDM) 312 sieht Funktionalität für die Administration der Regelmodule vor. Der SIP-Server implementiert ferner einen SIP-Protokollstapel 304, inkludierend die SIP-Vorgabefunktionalität 306 und einen SIP-Nachrichtenparser (SIP message parser, SIP MP) 305. Der Nachrichtenparser 305 unterstützt das SIP-Protokoll und extrahiert Nachrichteneigenschaften, die durch den Regelantrieb 303 interpretiert werden können. Der Administrationsserver 313 führt administrative Aufgaben in der Dienstumgebung durch.
  • Ein wichtiger Mechanismus zum Implementieren von Dienstaufstellungsrichtlinien gemäß der Erfindung ist die Spezifikation von Aufstellungsregeln als Dienstausführungsregeln, die in Regelmodulen spezifiziert sind. Dienstausführungsregeln spezifizieren Bedingungen und Aktionen, die unternommen werden müssen, falls die Bedingungen erfüllt sind. Gemäß der Erfindung wird eine Programmiersprache zum Spezifizieren dieser Regeln definiert, die als eine Dienstausführungsregelsprache (Service Execution Rule Language, SERL) bezeichnet wird.
  • Die Regelmodule 308 werden durch den Regelantrieb 303 gemanagt und ausgeführt. Der Regelantrieb 303 ist die Hauptfunktionsentität, die den Trigger- und Merkmalsinteraktionsmechanismus implementiert, und ist Teil der Dienstunterstützungsumgebung 301. Wenn ein Ereignis eintritt, ruft der Nachrichtenparser den Regelantrieb 303 auf und übergibt das Ereignis den Regelantrieb 303. Der Regelantrieb 303 findet und lädt die relevanten Regelmodule 308 und verarbeitet jene, die für das empfangene Ereignis relevant sind, in der richtigen Reihenfolge. Das Filtern inkludiert eine Erfassung von vertraglichen Verpflichtungen. Die Ereignisse definieren den Kontext, in dem Regelmodule verarbeitet werden, d.h. die Bedingungen werden gemäß den Eigenschaften der SIP-Nachrichtenereignisse bewertet. Der Regelantrieb 303 ruft die entsprechenden Aktionen auf, wenn das Regelmuster mit den gegebenen Nachrichteneigenschaften übereinstimmt. Basierend auf dem Inhalt dieser Aktionen kann der Regelantrieb 303 dem Anwendungsausführungsantriebsmanager 302 oder einer anderen geeigneten Entität innerhalb des Dienstunterstützungssystems Aufrufinstruktionen erteilen. SERL-Skripte haben kein Wissen über die Dienste, die sie aufrufen und managen, mit Ausnahme des Wissens, wie sie allgemein aufzurufen sind und wie Merkmale zu managen sind. Die Steuerinstruktionen, die von den aufgerufenen Dienstanwendungen empfangen werden, werden zu dem SIP-Stapel 304 zurück vermittelt, wenn das letzte Regelmodul verarbeitet wurde.
  • Der Regelantrieb 303 managt ferner die Information, die zwischen unterschiedlichen Diensten gesendet wird. Wenn ein Ereignis eintritt, wird ein Ereigniskontext, der die relevanten Eigenschaften des Ereignisses enthält, auf einem standardisierten Weg hergestellt. Die Nachrichteneigenschaften haben einen Namen und einen Wert. Der Wert kann durch die Nachricht bestimmt werden. Beispiele von SIP-Nachrichteneigenschaften sind:
    Name: sipRequest.Request-URI, Wert: sip:bob@corp.com
    Name: sipRequest.To, Wert: Bob Smith <sip:bob@corp.com>
    Name: sipResponse.Status-Code, Wert: 301
  • Ein Beispiel einer SDP-Nachrichteneigenschaft ist:
    Name: sdp.m, Wert: video 48232 RTP/AVP 0.
  • Der Regelantrieb 303 unterstützt eine Zahl von internen APIs, auf die durch die sich anschließenden Funktionsentitäten zugegriffen werden kann. Diese APIs inkludieren
    • – eine Nachrichtenbekanntgabe-API, die durch den SIP-Stapel 304 zur Nachrichtenbekanntgabe von dem Nachrichtenparser 305 zu dem Regelantrieb 303 verwendet wird,
    • – eine Regelbasisdefinitions-API, die durch den Dienstdefinitionsmanager 312 verwendet wird,
    • – eine Dienstinstruktions-API, die durch den Anwendungsausführungsantriebsmanager 302 verwendet wird, um Instruktionen zu dem Regelantrieb 303 im Namen der Dienstanwendungen 309–311 zu übergeben, und
    • – eine Scharfmachungs-API, die durch den Anwendungsausführungsantriebsmanager 302 verwendet wird, um das Scharfmachen von Triggern und Transaktionsereignissen im Namen der Dienstanwendungen 309–311 anzufordern.
  • Der Anwendungsausführungsantriebsmanager 302 bettet eine Zahl von Anwendungsausführungsantrieben (application execution engines, AEE) 315 für unterschiedliche Typen von Dienstanwendungen ein und managt sie, z.B. einen OSA-Antrieb, einen CPL-Antrieb, einen CPL-Interpreter, einen CGI-Antrieb und/oder einen Servlet-Antrieb. Er unterstützt die Schnittstelle, die durch den Regelantrieb 303 veranlasst wird, und bildet zwischen der Anwendungs-API und der Regelantrieb-API ab. Vom Standpunkt des Regelantriebs 303 sehen alle Anwendungsausführungsantriebe 315 wie eine einzelne Entität aus, d.h. der Anwendungsausführungsantriebsmanager 302. Der Dienstdefinitionsmanager 312 kann den Anwendungsausführungsantrieben 315 weitere Funktionalität bereitstellen.
  • Die APIs, die durch den Anwendungsausführungsantriebsmanager 302 vorgesehen werden, inkludieren:
    • – eine Aufruf-API, die durch den Regelantrieb 303 für Aufrufinstruktionen von dem Regelantrieb zu dem Anwendungsausführungsantriebsmanager 302 verwendet wird, und
    • – eine Bekanntgabe-API, die durch den Regelantrieb 303 für Bekanntgabeinstruktionen von dem Regelantrieb zu dem Anwendungsausführungsantriebsmanager 302 verwendet wird.
  • Das Vorgabe-SIP-Serververhalten 306 umfasst die Funktionalität eines Proxyservers, eines Umleitungsservers, eines Anwendungsservers oder sogar eines Benutzeragenten. Es kann ferner Archivar- oder IM&P-Funktionen inkludieren. Es sieht eine Schnittstelle vor, auf die durch den Regelantrieb 303 zugegriffen werden kann, um Instruktionen zu platzieren. Alternativ kann eine Dienstanwendung das SIP-Serververhalten implementieren. Deshalb ist es für den Regelantrieb möglich, nur Teile von jeder der obigen Funktionen aufzurufen, wie es durch die Dienstanwendungen erforderlich ist.
  • Der Dienstdefinitionsmanager 312 sieht eine O&M-API vor, die durch den Administrationsserver 313, Dienstanwendungen 309–311 und den SIP-Stapel 304 verwendet werden. Die API sieht Funktionalität vor für
    • – Manuelle Authentifizierung und Autorisierung von neuen Regelmodulen und Dienstanwendungen.
    • – Manuelles Konfigurieren von Rechten und Privilegien von Regelmodulen und Dienstanwendungen.
    • – Manuelles Laden von Regelmodulen und Dienstanwendungen.
    • – Manuelle Aktivierung/Deaktivierung von Regelmodulen und Dienstanwendungen.
    • – Manuelle Validierung von Regelmodulen.
    • – Manuelle Validierung von Dienstanwendungen, implementiert unter Verwendung von Skriptsprachen.
    • – Manuelle Löschung von Regelmodulen und Dienstanwendungen.
    • – Manuelle Auflistung aller Regelmodule und Dienstanwendungen gemeinsam mit ihrem Status.
    • – Manuelle Modifikation von Regelmodulen.
  • Der Dienstdefinitionsmanager 312 kann ferner eine Schnittstelle vorsehen, die eine automatische Handhabung von einigen der obigen manuellen Funktionen und/oder zusätzlichen Merkmale unterstützt, wie etwa Auflistung verfügbarer Dienstmerkmale, Erhalten von Schnittstelle und/oder Version eines Dienstmerkmals, Auflisten unterstützter Ausführungsantriebe und Skriptsprachen, wie etwa JVM, CPL, Perl etc., Installation/ Deinstallation von Dienstmerkmalen, Aktivierung/Deaktivierung von Dienstmerkmalen, Registrieren einer Dienstanwendung, die einer anderen Dienstanwendung Dienste als Dienstmerkmale bereitstellen wird, Abonnement von Dienstmerkmalen, Aufrufen/Beendigen von Dienstmerkmalen, statistische Operationen, wie "Prozessorlast überwachen", "Besetztstundenrufe", Abrechnungsoperationen, Aktivierung/Deaktivierung, Lesen, Zurücksetzen von Abrechnungsaufzeichnungen etc.
  • Hier umfasst der Begriff Dienstmerkmale Funktionen, die Dienstanwendungen angeboten werden. Die Dienstmerkmale werden betrachtet, als in die Dienstunterstützungsumgebung 301 und den SIP-Stapel 304 integriert zu sein. Der Anwendungsausführungsantriebsmanager 302 und der Dienstdefinitionsmanager 312 stellen beide den Dienstanwendungen 309–311 Dienstmerkmale bereit. Trotzdem werden einige der Merkmale, die durch den Anwendungsausführungsantriebsmanager 302 angeboten werden, durch den Regelantrieb 303 und den SIP-Stapel 304 vermittelt.
  • Die Dienstanwendungen 309–311 sind Programme, kompiliert oder interpretiert, die in der Dienstunterstützungsumgebung 301 des SIP-Servers oder auf einem entfernten Server ausgeführt werden. Ihr Zweck kann sich auf die Basisfunktionen des SIP-Servers beziehen oder nicht beziehen. Dienstanwendungen können SIP-Serververhalten implementieren. Dienstanwendungen können anderen Dienstanwendungen Dienste anbieten, d.h. sie können Dienstmerkmale sein. Z.B. kann eine Dienstanwendung irgendeinen MIME-Typ-Konverter enthalten und ihn als ein Dienstmerkmal anderen Dienstanwendungen anbieten. Andere Dienstanwendungen können dann diese Funktion verwenden, um einen Dienst durchzuführen. Vorzugsweise sollten Dienstanwendungen zwischen SIP-Servern portabel sein und auf entfernten Servern ausgeführt werden können. Dienstanwendungen können zugreifen auf, oder auf sie kann zugegriffen werden durch eine globale oder lokale Namenskonvention, einen standardi sierten oder lokalen Namensraum, durch Verwenden spezifizierter Dateipfade zu den Anwendungen etc., eine offene und standardisierte API, z.B. SIP-CGI, OSA API, HTTP, ICAP, CPL, Servlets etc.
  • Ein standardisierter Mechanismus zum Zugreifen auf eine Dienstanwendung ist ein Vorteil für Dienstanbieter einer dritten Seite.
  • Der SIP-Server managt nicht notwendigerweise entfernt platzierte Dienstanwendungen, da er über sie keine Kenntnis haben kann. In diesem Fall kann der SIP-Server oder der Anwendungsausführungsantriebsmanager 302 Standortinformation erfordern, die durch die triggernde Information bereitgestellt wird.
  • Der Nachrichtenparser 305 ist für Interpretieren von empfangenen Nachrichten, Isolieren gut definierter Elemente als Nachrichteneigenschaften und Veranlassen von Aktionen, die wenn geeignet zu aktivieren sind, verantwortlich. Wenn ein Ereignis eintritt, wird ein Nachrichtenobjekt hergestellt, das die relevanten Eigenschaften enthält, die durch den Nachrichtenparser 305 isoliert werden.
  • Vorzugsweise hat ein jegliches unterstütztes Protokoll einen entsprechenden Nachrichtenparser. Ein Parser kann untergeordnete Parser enthalten, die untergeordneten Protokollen entsprechen, d.h. eingebettet in andere Protokolle wie SIP. Z.B. kann es innerhalb eines SIP-Nachrichtenparsers getrennte Parser zum Handhaben unterschiedlicher Medientypen geben, wie etwa SDP, HTML, XML und XHTML. Vom Standpunkt des Regelantriebs sehen alle Parser wie ein einzelner Antrieb aus. Die API die für einen Nachrichtenparser sollte vorzugsweise derart definiert sein, dass Parser für neue Protokolle und Inhalt modular hinzugefügt werden können.
  • Für ein beliebiges Protokoll, das durch die Dienstunterstützungsumgebung 301 zu unterstützen ist, deckt die Schnittstelle zwischen dem Nachrichtenparser von diesem Protokoll und dem Regelantrieb ab
    • – die Menge von Eigenschaften, die durch den Nachrichtenparser definiert sind, inkludierend den Eigenschaftsnamen, ihre Beziehung zu der Nachricht, die sie charakterisiert, und die Fähigkeit einer Aktion, sie zu ändern, und
    • – die Verarbeitungspunkte, in denen Regeln aktiviert werden können.
  • In einer Ausführungsform der Erfindung können die Dienstunterstützungsumgebung 301 oder jede der Funktionsentitäten innerhalb der Dienstunterstützungsumgebung in getrennten Hosts platziert sein, die mehrere Server bedienen, z.B. SIP, Web, WAP, I-Mode, RTSP-Server, und auf mehrere Anwendungsserver zugreifen, z.B. Datenbanken, OSA, Web, SIP etc.
  • Z.B. können sich der Regelantrieb 303, der Anwendungsausführungsantriebsmanager 302 und der Dienstdefinitionsmanager 312 in jedem ihren Host befinden, möglicherweise über IP gekoppelt. Die Schnittstellen zwischen dem Regelantrieb und den verschiedenen Servern können standardisiert oder proprietär sein. Die Schnittstellen zwischen dem Regelantrieb, dem Anwendungsausführungsantriebsmanager und dem Dienstdefinitionsmanager sollten vorzugsweise proprietär und miteinander gepackt sein. Die Schnittstellen zwischen den Dienstanwendungsservern und der Dienstunterstützungsumgebung sind vorzugsweise standardisiert, wie OSA API, HTTP, SIP oder irgendeine Datenbank-API, wie irgendeine SQL-basierte API. In einer derartigen verteilten Konfiguration wird ein weiterer Vorteil der Erfindung offensichtlich, da der Regelantrieb in der Lage ist, viele Typen von Ereignissen zu managen, nicht nur SIP- Ereignisse, sondern auch HTTP-Ereignisse, SMTP-Ereignisse, Wap-Ereignisse, Media-Codec-Ereignisse, wie MPEG7-Ereignisse oder 3D virtuelle Realität oder Spielobjektereignisse etc.
  • Bezug nehmend noch auf 3 kann der Triggermechanismus gemäß einer Ausführungsform der Erfindung durch ein einfaches Beispiel veranschaulicht werden, wobei angenommen wird, dass nur ein einzelnes Regelmodul für ein empfangenes Ereignis relevant ist. In 3 verweisen die Ziffern in Kreisen auf die folgenden Schritte eines Triggerbeispiels:
    • 1. Es wird eine SIP-Anfrage in dem Nachrichtenparser 305 empfangen.
    • 2. Der SIP-Nachrichtenparser 305 generiert ein SIP-Nachrichtenobjekt. Der Regelantrieb 303 konvertiert dies in einen SIP-Ereigniskontext.
    • 3. Die relevanten Regelmodule befinden sich in der Ausführungsregelbasis 307 basierend auf dem Ereigniskontext, Verarbeitungspunkten und vertraglichen Beziehungen. Eine Ausführungsform dieses Mechanismus wird nachstehend beschrieben.
    • 4. Der Regelantrieb 303 lädt das gefundene Regelmodul 308 von der Ausführungsregelbasis 307 in den Regelmodulausführungsantrieb 314 und führt es aus. Als ein Beispiel enthalte das geladene Regelmodul die folgende Funktionalität, d.h. eine Regel, die Triggerkriterien und Aufrufaktionen für Dienstanwendungen 310 und 311 spezifiziert:
      Figure 00440001
      Figure 00450001
    • 5. Ein Trigger wird erreicht, und die spezifizierte Dienstanwendung Y (310) wird durch Senden eines Aufrufbefehls zu dem Anwendungsausführungsantriebsmanager 302 aufgerufen.
    • 6. Der Anwendungsausführungsantriebsmanager 302 lokalisiert die Anwendung Y (310).
    • 7. Der Anwendungsausführungsantriebsmanager 302 lädt die relevante Dienstanwendung Y (310) in einen Anwendungsausführungsantrieb 315 und aktiviert sie anschließend für eine Ausführung.
    • 8. Die resultierende Instruktion von Anwendung 310 wird zu dem Regelantrieb 303 zurückgegeben.
    • 9. Der Regelantrieb 303 nimmt eine Verarbeitung des Regelmoduls wieder auf und triggert eine andere Anwendung Z (311). Dem Anwendungsausführungsantriebsmanager 302 wird ein Aufrufbefehl gegeben.
    • 10. Der Anwendungsausführungsantriebsmanager 302 lokalisiert die Anwendung Z (311).
    • 11. Der Anwendungsausführungsantriebsmanager 302 lädt die relevante Dienstanwendung Z (311) in einen Ausführungsantrieb 315, der die Anwendung laufen lassen kann, und aktiviert sie anschließend.
    • 12. Die resultierende Instruktion von Anwendung 311 wird zu dem Regelantrieb 303 zurückgegeben.
    • 13. Der Regelantrieb 303 nimmt eine Verarbeitung des Regelmoduls wieder auf und findet heraus, dass das Regelmodul keine Regeln mehr auszuführen hat und dass es keine Regelmodule mehr zu laden gibt. Anschließend sendet der Regelantrieb 303 das Schlussergebnis der Dienste zu dem SIP-Vorgabeverhalten 306.
    • 14. Das SIP-Vorgabeverhalten 306 vereinigt die Ausgabe von dem Regelantrieb 303 mit einer möglichen Vorgabeausgabe und sendet die SIP-Nachricht zu dem Nachrichtenparser/Konverter 305.
    • 15. Die SIP-Nachricht wird z.B. vertreten (proxied).
  • Im Fall von mehreren Regelmodulen können die obigen Schritte 13–14 alternativ wie folgt sein
    13. Der Regelantrieb 303 nimmt eine Verarbeitung des Regelmoduls wieder auf und findet heraus, dass das Regelmodul keine Regeln mehr auszuführen hat. Der Regelantrieb 303 sucht nach Regelmodulen mit Priorität niedrigerer Ordnung als das zuvor ausgeführte Regelmodul.
  • 14. Gehe zu Punkt 3 in dem vorherigen Beispiel. Falls ein Regelmodul gefunden wird, wird es wie im vorherigen Beispiel laufen gelassen, möglicherweise mit Aufruf anderer Anwendungen, z.B. wird die Anwendung 309 aufgerufen.
  • Wenn keine Regelmodule oder Dienste installiert sind, eine Sitzung zu steuern, übergibt der Regelantrieb 303 die Steuerung zu dem SIP-Server, und spezifiziert eine leere Ausgabe. Der SIP-Server kann möglicherweise die leere Ausgabe mit dem Vorgabeverhalten 306 des Servers vereinigen, wie in SIP-CGI, gemäß Vorgabe-SIP-Verhalten für Archivare, Umlenkungsserver und Proxyserver.
  • 4 veranschaulicht die Struktur eines Regelmoduls gemäß einer Ausführungsform der Erfindung. Gemäß der Erfindung ist ein Regelmodul 401 konzeptionell ein Baum, umfassend eine Zahl von Dienstausführungsregeln 401–402, wobei jede Regel eine Zahl von Bedingungen 403–404 bzw. 405, und eine Zahl von Aktionen 406–407 bzw. 408 spezifiziert, die unternommen werden müssen, falls die entsprechenden Bedingungen erfüllt sind. Im Folgenden werden Bedingungen auch als Muster bezeichnet. Auf einer hohen Ebene umfasst ein Regelmodul ferner
    • – Besitzerinformation 409, die den Besitzer des Regelmoduls angibt, d.h. eine identifizierbare Seite mit einem Interesse an dem SIP-Knoten. Diese Seite kann mehrere Regelmodule besitzen. Die Besitzerinformation kann ferner Information über vertragliche Beziehungen inkludieren.
    • – Protokollinformation 410, die den Kontext spezifiziert, in dem die Regeln in dem Regelmodul zu interpretieren sind.
  • Beispiele von Protokollen sind SIP, SDP, HTTP, H.323 etc. Vorzugsweise sollte nur ein einzelnes Protokoll pro Regelmodul definiert sein. Anderenfalls kann irgendeine Überlappung mehrdeutige Interpretation vorsehen. Z.B. haben sowohl SIP als auch HTTP Inhaltstypheaderfelder.
    • – Zugriffssteuerinformation 411, die spezifiziert, welche Seiten das Recht haben, das Regelmodul aufzurufen, zu administrieren und zu lesen.
    • – einen Regelmodulidentifikator 412, vorzugsweise ein eindeutiger Identifikator. Zusätzlich kann ein Regelmodul eine Zahl von Aliasen inkludieren.
  • Ein Regelmodul kann ferner ergänzende Information 413, die weitere Kontextinformation für ein Regelmodul vorsieht, und Indexinformation 414 umfassen.
  • Ein Muster 403–405 ist ein Ausdruck, der mit Bezug auf die Nachrichteneigenschaften in einem Ereigniskontext bewertet werden kann, und entweder werden die Regeln mit den Eigenschaften in den Kontext übereinstimmen oder versagen, mit ihnen übereinzustimmen. Aktionen 406–408 können Anwendungen, eingebaute Diensteigenschaften, entfernte Server, lastteilende Hosts oder aufzurufende SIP-Server eines nächsten Sprungs identifizieren. Sie können ferner heruntergeladene und extern platzierte Aktionsobjekte etc. identifizieren. Regeln, Bedingungen und Aktionen können Parameter haben, die ihr Verhalten beschreiben, sie sind die Attribute der Baumknoten. Die Zweige haben eine Gewichtung, die anzeigt, welcher Zweig zuerst verarbeitet werden sollte.
  • Vorzugsweise hat jedes Regelmodul eine explizite Ordnungspriorität, die ihm zugeordnet ist, d.h. die Reihenfolgeprio rität spezifiziert die Sequenz, in der Regelmodule durch den Regelantrieb geladen werden.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung werden die Knoten des Baums in der grafischen Darstellung durch XML-Elemente dargestellt. Die Verzweigung von einem Knoten zu den nächsten Knoten wird durch Einschließen des Elementes dargestellt, das den (die) nächsten Knoten innerhalb des Elementes darstellt, das den Knoten darstellt, von dem verzweigt wird. Die Gewichtung der Zweige ergibt sich durch die Reihenfolge, in der sie in dem Skript dargestellt werden. Diese Gewichtung ergibt die Reihenfolge, in der die Elemente zu verarbeiten sind, wenn ein Ereignis empfangen wird. Mit anderen Worten wird das Skript von oben nach unten ausgeführt. Somit gibt es in dieser Ausführungsform keine Schleifen innerhalb eines SERL-Skriptes. Vorzugsweise wird das Format eines Regelmoduls als ein XML DTD oder XML-Schema spezifiziert.
  • Es ist ein Vorteil dieser Ausführungsform, dass sie auf einer standardisierten und erweiterbaren Sprache basiert, um Sprachen zu spezifizieren.
  • In einer Ausführungsform der Erfindung können Richtlinien mit Regeln in Verbindung gebracht werden, die Privilegien und Rechte spezifizieren. Jeder Knoten des Regelmoduls kann einen zugehörigen Richtlinienknoten haben, der Zugriffssteuerlisten enthalten kann.
  • Das Folgende ist ein Beispiel einer Instanz eines Regelmoduls, das als ein SERL-Skript spezifiziert ist:
    Figure 00490001
  • Figure 00500001
  • 5 veranschaulicht die Gruppierung von Diensten in eingeschränkte Mengen von Diensten gemäß einer Ausführungsform der Erfindung. Gemäß dieser Ausführungsform werden Dienste 501–508 in eine Menge von Merkmalsgruppen (feature groups, FG) 509–510 gruppiert. In dem in 5 gezeigten Beispiel enthält Merkmalsgruppe 509 Merkmale 501–504, und Merkmalsgruppe 510 enthält Merkmale 505–508. Für jede Merkmalsgruppe werden den Diensten dieser Gruppe gewisse Einschränkungen auferlegt, d.h. ihnen wird nur erlaubt, gut definierte Typen von Instruktionen zu erteilen. Die Merkmalsgruppen spezifizieren nicht, wie einzelnen Merkmalen erlaubt wird, innerhalb einer Merkmalsgruppe zu interagieren, solange wie sie nicht die Beschränkungen in dem Gruppenverhalten verletzen. Die Merkmalsgruppen sind sequenziell geordnet, d.h. durch Nummerieren der Merkmalsgruppen. In dem Beispiel von 5 ist Merkmalsgruppe 509 die K-te Merkmalsgruppe in einer Sequenz von Merkmalsgruppen, und Merkmalsgruppe 510 ist durch K + 1 nummeriert. Die Ordnung von Merkmalsgruppen erlegt eine Reihenfolge einer Ausführung auf, derart, dass die Merkmale von Merkmalsgruppe 509 vor der Ausführung der Merkmale in Gruppe 510 ausgeführt werden. Vorzugsweise umfasst die Definition einer Merkmalsgruppe eine Spezifikation der Gruppenordnung, z.B. durch Spezifizieren eines Gruppenindexes, durch Spezifizieren einer vorherigen und einer nächsten Merkmalsgruppe oder dergleichen. Vorzugsweise umfasst die Definition einer Merkmalsgruppe ferner eine Spezifikation von Vorbedingungen, d.h. Bedingungen, auf denen die Merkmale dieser Merkmalsgruppe beruhen können, und eine Spezifikation von Einschränkungen, die in dem Verhalten der Dienste dieser Merkmalsgruppe durchgesetzt werden. Daher sind die Merkmalsgruppen ein Ordnungsmechanismus, der einen fundamentalen Typ von Merkmalsinteraktion durch Vorsehen einer geordneten Sequenz formalisiert, in der Dienstanwendungen aufgerufen werden. Deshalb sieht dieser Mechanismus ein Rahmenwerk zum Gruppieren des Problems von Merkmalsinteraktion in eingeschränkte Mengen von Merkmalen vor. Der Mechanismus löst tatsächlich Interaktionen zwischen diesen Merkmalsgruppen auf, da wegen den Einschränkungen in den Merkmalsgruppen die Merkmalsannahmen, wenn Steuerung von einer Gruppe zu der nächsten übergeben wird, deterministisch und gut definiert sind. Es ist ein Vorteil dieser Gruppierung, dass sie einen Mechanismus zum Zerlegen des Problems von Merkmalsinteraktionsanalyse in kleinere unabhängige Probleme vorsieht, wobei es dadurch leichter gemacht wird, das Problem zu managen. Des weiteren ist es ein Vorteil, dass formalisierte Problembereiche zu unabhängigen Seiten delegiert werden können, was das Problem skalierbarer macht. Der Mechanismus von Merkmalsgruppen gibt dem Administrator und Dienstanbieter die Fähigkeit, die Dienstanwendungen in verschiedene Punkte in einer Verarbeitungszeit zu kategorisieren, wo die Dienstanwendungen aufgerufen werden sollten.
  • 6 veranschaulicht die Gruppierung von Diensten in eingeschränkte Mengen von Diensten entsprechend Standorten in dem Rundlauf-SIP-Nachrichtenfluss gemäß einer bevorzugten Ausführungsform der Erfindung. Gemäß dieser Ausführungsform beziehen sich die Merkmalsgruppen auf Standorte P1–P6 in dem logischen Anfrage-/Antwort-Rundlauf-Nachrichtenfluss, die gewisse Vorbedingungen für den Ereigniskontext garantiert haben, und wo eine Dienstanwendung basierend auf den Einschränkungen, über die Verhalten in diesem Standort erlaubt ist, aufgerufen werden kann. Diese Merkmalsgruppen werden als Verarbeitungspunkte bezeichnet.
  • Die sechs Verarbeitungspunkte P1–P6 sind eine allgemeine Gruppierung von Diensten. Verarbeitungspunkte P1–P3 und P4–P6 decken entsprechende Probleme logisch ab. Verarbeitungspunkte P1–P3 inkludieren Dienste, die in Anfragen 607 getriggert werden, und Verarbeitungspunkte P4–P6 inkludieren Dienste, die in Antworten 608 getriggert werden. Logisch entsprechen Verarbeitungspunkte P1 und P4, Punkte P2 und P5 und Punkte P3 und P6 entsprechenden Einschränkungen.
  • Eine SIP-Nachricht kann grob in zwei Teile unterteilt werden, die Signalisierungseigenschaften, d.h. Eigenschaften in Bezug auf SIP, SDP etc., und den Nachrichtenrumpfinhalt, der nicht auf Signalisierung bezogen ist, wie etwa GIF, HTML etc.
  • Dienste, die in einem SIP-Ereignis aufgerufen werden, können deshalb in jene, die:
    • – die Signalisierungseigenschaften beeinflussen,
    • – nur den Nicht-Signalisierungs-Nachrichtenrumpfinhalt beeinflussen, und
    • – jene, die weder die Signalisierungseigenschaften noch den Nicht-Signalisierungs-Nachrichtenrumpfinhalt beeinflussen,
    gruppiert werden.
  • Dies ergibt die Basisgruppierung von Diensten in drei Gruppen 601–603, die jeweils mit den drei Verarbeitungspunkten P1–P3 in Verbindung stehen. Ähnlich sind in dem Antwortdurchlauf die entsprechenden Gruppen 604–606 jeweils auf die Verarbeitungspunkte P4–P6 bezogen.
  • Hier umfasst der Begriff Signalisierungseigenschaften SIP- und SDP-Nachrichteneigenschaften, die in einer Regelmodulbedingung angepasst werden können, um einen Dienst aufzurufen. Folglich können Anwendungen, die eine Signalisierungseigenschaft ändern, veranlassen, dass eine andere Anwendung aufgerufen wird, die noch eine andere Anwendung aufrufen kann usw. Der Vorteil einer Verschiebung der Handhabung von Dienstanwendungen, die Signalisierungseigenschaften nicht ändern, zu einem Verarbeitungspunkt, nachdem alle Änderungen zu den Signalisierungseigenschaften aufgetreten sind, besteht darin, dass der Administrator eine leichtere Aufgabe beim Ordnen der Anwendungen in den Verarbeitungspunkten P2 und P5 hat.
  • In einer Ausführungsform der Erfindung können die Verarbeitungspunkte P1–P6 wie folgt definiert sein:
    • – Verarbeitungspunkt P1 – Clientanfrage eines vorherigen Sprungs: Es wurde eine SIP-Anfrage 607 von einem Client eines vorherigen Sprungs empfangen. Für diese bestimmte Anfrage und für diesen bestimmten Teilnehmer wurden keine Regelmodule in einem beliebigen vorherigen Verarbeitungspunkt aufgerufen. Dieser Verarbeitungspunkt umfasst Dienste, die die SIP-/SDP-Signalisierungseigenschaften der resultierenden Nachricht(en) beeinflussen, aber nicht den Nachrichtenrumpfinhalt.
    • – Verarbeitungspunkt P2 – Anfrageinhaltspunkt: Die Signalisierungseigenschaften der resultierenden SIP-/SDP-Nachricht(en) wurden generiert und gecacht, d.h. dieser Teil der SIP-Nachricht ist bereit, gesendet zu werden. Zusätzliche Aktualisierungen zu den Ruf-/Mediensteuersignalisierungseigenschaften sollten nicht auftreten, es sei denn explizit autorisiert. Die Dienste 602, die in dem Verarbeitungspunkt P2 aufgerufen werden, sollten die SIP-/SDP-Signalisierungseigenschaften, wie im Verarbeitungspunkt P1 generiert, nicht beeinflussen. Für diese Regel kann es jedoch Ausnahmen geben. Z.B. können Dienste SIP-Header wie Alarm-Info, Ruf-Info, Inhaltsdisposition, Inhaltskodierung, Inhaltssprache, Inhaltslänge, Inhaltstyp und Anfragen beeinflussen. Es sollte spezielle Sorge getragen werden, falls diese Signalisierungseigenschaften in beiden Verarbeitungspunkten P1 und P2 geändert werden. Beispiele von Typen vom Medieninhalt, die in diesem Verarbeitungspunkt verarbeitet werden können, inkludieren SOAP, HTML, vXML, SMIL, GIF, MPEG7, au etc.
    • – Verarbeitungspunkt P3 – Anfragestapelpunkt: Die resultierende(n) SIP-Nachricht(en) wurde(n) generiert und gesendet. Es können keine Aktualisierungen an der (den) resultierenden Nachricht(en) mehr auftreten. Dieser Verarbeitungspunkt entspricht Diensten 603, die nur aufgerufen werden müssen, aber nicht eine Ausgabe erzeugen, die benötigt wird, um die Anfrage zu verarbeiten. Diese Dienste müssen nur die resultierende(n) Nachricht(en) lesen, sie aber nicht aktualisieren.
  • Die Verarbeitungspunkte
    • – P4 – Serverantwort eines vorherigen Sprungs,
    • – P5 – Antwortinhaltspunkt, und
    • – P6 – Antwortstapelpunkt
    können für Antwortnachrichten 608 analog zu jeweils den Verarbeitungspunkten P1–P3 definiert werden.
  • Alternativ oder zusätzlich können andere Verarbeitungspunkte definiert werden. Z.B. kann ein zusätzlicher Verarbeitungspunkt P0 (nicht gezeigt) ohne Einschränkungen in den Merkmalen definiert werden und der in einem beliebigen Ereignis getriggert wird, d.h. in dem Empfang von sowohl Anfragen 607 als auch Antworten 608.
  • Vorzugsweise können zusätzliche Verarbeitungspunkte mit einem der Verarbeitungspunkte hoher Ebene in Verbindung stehen. Z.B. können Teilverarbeitungspunkte für Verarbeitungspunkt P1 definiert werden, die P1.1, P1.2, P1.2.1, P1.2.2 etc. genannt werden können. Vorzugsweise sollten neue Verarbeitungspunkte nur definiert werden, falls sie eine logische Gruppe von Diensten definieren, die von Nutzen sein können, um gemäß spezifizierten Vorbedingungen aufzurufen.
  • Die folgende Tabelle inkludiert einige Beispiele von Diensten, die in den unterschiedlichen Verarbeitungspunkten in einem veranlassenden bzw. abschließenden SIP-Server definiert sein können:
  • Figure 00560001
  • 7 veranschaulicht den Verarbeitungsfluss zwischen Diensten, die zu unterschiedlichen Verarbeitungspunkten gehören, gemäß einer Ausführungsform der Erfindung. In der Ausführungsform, die in Verbindung mit 6 beschrieben wird, werden Dienste, die unterschiedliche Teile einer SIP-Nachricht beeinflussen, in unterschiedliche Verarbeitungspunkte gruppiert. Dies kann genutzt werden, um eine effiziente Verarbeitung von Diensten vorzusehen. Dienste, die die SIP-Signalisierungseigenschaften einer eingehenden Nachricht 701 beeinflussen, sind in Verarbeitungspunkt P1 inkludiert. Deshalb umfasst die Ausgabe vom Verarbeitungspunkt P1 die Abschlussruf-/Mediensteuerinstruktionen 702. Dies kann unverzüglich mit möglichem SIP-Servervorgabeverhalten vereinigt und dem Nachrichtenkonverter 705 übergeben werden, der die ausgehende SIP-Nachricht 703 vorbereitet. Außerdem können sich die Dienste, die im Verarbeitungspunkt P2 aufgerufen werden, darauf verlassen, dass sich die Signalisierungseigenschaften nicht länger ändern, z.B. können sie mit Vertrauen Dienste anwenden, die von der endgültigen generierten Zieladresse abhängen.
  • Durch Konzentrieren von Diensten, die nur den Nicht-Signalisierungs-SIP-Nachrichtenrumpfinhalt (und möglicherweise die in Beziehung stehenden Inhaltsheaderfelder) beeinflussen, im Verarbeitungspunkt P2 ist die Ausgabe 704 vom Verarbeitungspunkt P2 für den Server ausreichend, die resultierende(n) ausgehende(n) SIP-Nachricht(en) 703 tatsächlich zu senden. Die Ausgabe 704 vom Verarbeitungspunkt P2 wird dem Nachrichtenkonverter 705 übergeben, mit der Ausgabe 702 vom Verarbeitungspunkt P2 vereinigt, und die Nachricht 703 wird gesendet.
  • Wenn die Ausgabe von Verarbeitungspunkten P1 und P2 bereit ist, ist Verarbeitungspunkt P3 erreicht. Die Dienste im Verarbeitungspunkt P3 beeinflussen nicht den Inhalt der resultierenden SIP-Nachricht 703, sondern können auf ihm beruhen. Daher kann vorzugsweise die resultierende SIP-Nachricht, die vom Punkt P1 und P2 generiert wird, gesendet werden, bevor auf die Ausführung von Diensten vom Verarbeitungspunkt P3 gewartet wird, wobei dadurch die Effizienz des Systems erhöht wird.
  • Daher hat die Gruppierung von Diensten gemäß Verarbeitungspunkten die folgenden Vorteile: Verarbeitungspunkte vereinfachen das Problem von Merkmalsinteraktion. Verarbeitungspunkte machen das Problem von Merkmalsinteraktion skalierbarer. Verarbeitungspunkte verbessern Latenz von Verarbeitungsnachrichten, wenn parallele Verarbeitung verwendet wird, d.h. Mehrfachprozessoren. Antworten oder Proxy-Anfragen können zu dem Netz schneller zurückgegeben werden, da sich Dienstanwendungen, die nicht Instruktionen zu dem SIP-Server spezifizieren, im Verarbeitungspunkt P3 befinden. Daher muss die Antwort oder Proxy-Anfrage nicht darauf warten, dass die Dienstanwendungen im Verarbeitungspunkt P3 aufgerufen werden.
  • 8 veranschaulicht die Gruppierung von Diensten in Regelmodule entsprechend administrativer Autorität gemäß einer Ausführungsform der Erfindung. Da Regelmodule einen Regelmodulbesitzer haben, der mit ihm in Verbindung steht, entsprechen sie einer administrativen Domäne, wo ein Administrator, d.h. der Regelmodulbesitzer, Dienstaufstellungsrichtlinien spezifizieren kann. Innerhalb eines Regelmoduls wird die Reihenfolge von Aktionen durch den Besitzer des Regelmoduls, d.h. den SERL-Skriptautor, zugeordnet.
  • Gemäß dieser Ausführungsform der Erfindung hat jedes Regelmodul zu sich eine Priorität zugewiesen. Die Priorität spezifiziert die Beziehung zwischen Regelmodulen. Je höher die Regelmodulpriorität ist, desto früher werden die Regeln in dem Regelmodul angewendet. 8 zeigt schematisch zwei Regelmodule 801 und 802. Regelmodul 801 befindet sich im Besitz durch Administrator A, während sich Regelmodul 802 im Besitz durch Administrator B befindet. Die Regelmodulprioritäten der Regelmodule 801–802 werden durch eine Regelmodulordnung angezeigt, wo eine niedrige Ordnung einer hohen Priorität entspricht und umgekehrt. Z.B. kann Regelordnung 1 definiert sein, die höchste Priorität zu sein. In dem Beispiel von 8 hat Regelmodul 801 eine Regelmodulordnung h und Regelmodul 802 hat eine Ordnung h + 1. Folglich werden die Dienste 803–804, die durch Regelmodul 801 aufgerufen werden, vor dem Dienst 805 von Regelmodul 802 ausgeführt.
  • Regelmodule mit dem gleichen Besitzer können die gleiche Ordnungspriorität haben. Vorzugsweise sollten sie in diesem Fall unterschiedliche Ereigniskontexte haben (z.B. SIP, HTTP, ...), wobei dadurch vermieden wird, dass mehr als ein Regelmodul mit der gleichen Priorität in dem gleichen Ereigniskontext aufgerufen wird. Mit anderen Worten sollten Regelmodule, die in der gleichen Nachrichteneigenschaft von einem gegebenen Ereigniskontext aufgerufen werden können, unterschiedliche Prioritäten haben.
  • Jede administrative Domäne ist unabhängig von anderen administrativen Domänen. Dies bedeutet, dass eine administrative Domäne kein Wissen über die Dienste haben muss, die in anderen Domänen aufgestellt sind. Jeder Administrator ist für Analysieren und Spezifizieren von Dienstaufstellungsrichtlinien in einer gegebenen Domäne verantwortlich.
  • Falls mehr als ein Regelmodul oder eine Dienstanwendung in einem gegebenen Ereignis aufgerufen wird, werden sie je eine Menge von Merkmalsinstruktionen vorsehen, die spezifizieren werden, wie dieses Ereignis zu verarbeiten ist, z.B. ob das Ereignis weitergeleitet oder abgeschlossen werden sollte. Eindeutig sollten derartige Merkmalsinstruktionen nicht gleichzeitig verarbeitet werden, und einige Merkmalsinstruktionen können andere aufheben. In einigen Fällen kann es jedoch nicht wichtig sein, in welcher Reihenfolge Merkmalsinstruktionen angewendet werden oder ob sie gleichzeitig angewendet werden.
  • Gemäß der Erfindung wird ein Mechanismus vorgesehen, um administrativen Domänen zu erlauben, ihre Merkmalsinstruktionen zu schützen, wenn die Steuerung zu einer anderen administrativen Domäne übergeben wird. Dies bedeutet, dass jede administrative Domäne die Übergabe einer Steuerung zu Ei genschaften begrenzen kann, die für das korrekte Verhalten ihrer Merkmale unwichtig sind. Das Objekt, das von einem Dienst zu einem anderen weitergegeben wird, ist der aktuelle Ereigniskontext 806–807. Wenn die Steuerung des Ereigniskontextes 806 zwischen Dienstanwendungen übergeben wird, die zu der gleichen administrativen Domäne gehören, ist vorzugsweise die Vorgaberegel, dass keine Eigenschaften des Ereigniskontextes geschützt sind. Falls irgendetwas zu schützen ist, muss dies explizit geschehen. Zwischen administrativen Domänen sind jedoch alle Eigenschaften eines Ereigniskontextes 807 per Vorgabe geschützt. Falls es nicht notwendig ist, irgendetwas zwischen administrativen Domänen zu schützen, muss es explizit als ungeschützt markiert werden. Vorzugsweise sollte das Recht, Eigenschaften geschützt und/oder ungeschützt zu markieren, durch ein Privileg gelenkt werden, das mit einem Regelmodul in Verbindung steht.
  • Mit anderen Worten können Regelmodule höherer Priorität Nachrichteneigenschaften sperren, falls sie die Privilegien haben, dies zu tun, und gesperrte Nachrichteneigenschaften können durch Regelmodule nicht freigegeben werden, es sei denn, sie haben die Privilegien, dies zu tun.
  • Das folgende Beispiel eines Fragmentes eines Regelmoduls veranschaulicht das Sperren/Freigeben von Nachrichteneigenschaften, nachdem ein Merkmal F1 ausgeführt wurde:
    Figure 00600001
    Figure 00610001
  • In einer Ausführungsform der Erfindung kann eine Aktionsausgabe das Regelmodul abschließen, d.h. die stromabwärtigen Anwendungen werden nicht aufgerufen. Des weiteren können Aktionen explizit Privilegien in Nachrichteneigenschaften in dem aktuellen Ereigniskontext setzen, falls sie die Privilegien haben, dies zu tun. Es ist ein Vorteil dieser Ausführungsform, dass die administrativen Domänen unabhängig sind, sobald ihnen eine Priorität zugeordnet wurde.
  • Gemäß dieser Ausführungsform ordnet ein übergreifender Administrator die Prioritäten oder Bereiche von Prioritäten der Regelmodule basierend auf vertraglichen Beziehungen mit jedem der Regelmodulbesitzer zu. Der übergreifende Domänenadministrator wäre natürlich auch der Besitzer des Regelmoduls mit der höchsten Priorität. Z.B. ist an der Spitze der Hierarchie der SIP-Dienstanbieter, der den Domänennamen und die IP-Adresse des Hosts besitzt. Der SIP-Dienstanbieter kann vielen Seiten viele Dienste bereitstellen. Er kann auch für seine eigenen Zwecke Anwendungen laufen lassen, z.B. Protokollierung, Abrechnung, Statistiksammlung, Betrugserfassung, Werbung etc. Er kann ein oder mehr Regelmodule auf dem Server platzieren.
  • Z.B. kann der SIP-Dienstanbieter ein Regelmodul für jeden seiner Teilnehmer platzieren. Wenn ein SIP-Ereignis in dem SIP-Server empfangen wurde, kann das Hauptregelmodul des SIP-Dienstanbieters einige seiner eigenen Dienste aufrufen und dann die Steuerung zu dem Regelmodul für den geeigneten Teilnehmer übergeben. In diesem Regelmodul kann es Regeln geben, Dienste zu triggern, die für den spezifischen Teilnehmer maßgeschneidert sind. Diese Dienste können durch den SIP-Dienstanbieter selbst bereitgestellt werden, oder können durch den SIP-Dienstanbieter von Dienstanbietern einer dritten Seite eingekauft werden. Der SIP-Dienstanbieter wäre für eine Analyse von Merkmalsinteraktionsproblemen zwischen diesen Diensten und Spezifizieren von Ordnungsprioritäten und Instruktionsprioritäten zwischen den Dienstanwendungen, vorzugsweise durch Verwenden von SERL, verantwortlich. In diesem Fall sind sowohl das Hauptregelmodul als auch das Teilnehmerregelmodul im Besitz durch den SIP-Dienstanbieter und werden durch ihn administriert. Von ihnen wird gesagt, in einer Administrationsdomäne zu sein. In irgendeinem Punkt in der Ordnungspriorität kann der SIP-Dienstanbieter entscheiden, zu einem Regelmodul zu übergeben, das im Besitz des Teilnehmers selbst ist. Es ist zu beachten, dass einzelne Teilnehmer in der Lage sein können, ihre eigenen SERL-Skripte zu schreiben, oder sie können nur in der Lage sein, Präferenzen zu aktualisieren, z.B. über eine HTML-Form, aus der ein SERL-Skript generiert werden kann. Das Regelmodul des Teilnehmers kann ein CPL-Skript aufrufen, oder kann wiederum ein anderes Regelmodul, irgendein Regelmodul eines Dienstanbieters einer dritten Seite oder dergleichen aufrufen. Falls das Regelmodul des Teilnehmers mehr als eine Aktion inkludiert, muss der Teilnehmer spezifizieren, welche Aktion zuerst ausgeführt werden sollte. Gleichermaßen sollten in dem Regelmodul dritter Seiten die Aktionen gemäß den Wünschen der dritten Seite geordnet werden.
  • In einem anderen Szenarium kann der Teilnehmer ein Angestellter eines Firmenkunden sein. In diesem Fall kann das Regelmodul des SIP-Dienstanbieters zuerst zu dem Regelmodul des Firmenkunden übergeben, das irgendwelche Anwendungen aufrufen und dann zu dem Regelmodul des einzelnen Teilnehmers übergeben kann.
  • Der Administrator oberster Ebene kann wünschen, die Prioritätsreihenfolge mit einer Zahl von Regelmodulen zu vermischen. Es kann jedoch umständlich sein, Regelmodule mit Regelmodulen unterer Priorität von anderen Seiten zu vermischen. Eine Lösung für dieses Problem ist, Regelmodulprioritäten mit ausreichenden Sicherungsbereichen zu trennen, die zu einer späteren Zeit verwendet werden können. Alternativ kann ein hierarchisches Administrationsdomänenmodell angewendet werden, wie in Verbindung mit 12 beschrieben wird.
  • Vorzugsweise unterstützt die Dienstunterstützungsumgebung einen Mechanismus zum Benachrichtigen von Administratoren, wenn eine Anwendung versucht, eine geschützte Eigenschaft zu ändern. Vorzugsweise wird eine Anwendung, die versucht, eine geschützte Eigenschaft zu ändern, außer Dienst genommen.
  • Es wird vermerkt, dass Modifikationen des obigen Schemas möglich sind. Z.B. kann in einer Hierarchie von administrativen Domänen jeder Administrator einer Ebene einen vollständigen Geltungsbereich haben, um Regelmodule auf Ebenen mit unterer Priorität anzuordnen, innerhalb eines zugeordneten Prioritätsbereiches. Der Administrator höherer Ebene würde diesen Geltungsbereich delegieren.
  • Es ist ein Vorteil dieser Ausführungsform, dass sie einen skalierbaren Mechanismus zum Managen und Implementieren von Dienstaufstellungsrichtlinien vorsieht. Gemäß dieser Ausfüh rungsform ist die Dienstunterstützungsumgebung in der Lage, Dienstaufstellungsrichtlinien einer dritten Seite ohne beträchtliche zusätzliche Arbeit für den Domänenadministrator zu unterhalten. Es ist ein weiterer Vorteil, dass Begrenzungen auf die Zahl von Interessengruppen oder die Zahl von vertraglichen Beziehungen zwischen ihnen platziert werden.
  • Es ist ein weiterer Vorteil dieser Ausführungsform, dass die Aufgabe von Merkmalsinteraktionsanalyse in administrative Domänen herunter gebrochen wird, wobei dadurch eine Verteilung des Problems zwischen den betroffenen Seiten erlaubt wird.
  • 9 veranschaulicht eine Ausführungsform der Erfindung, wo Dienste sowohl gemäß Verarbeitungspunkten als auch gemäß administrativer Autorität gruppiert sind. 9 zeigt schematisch ein Regelmodul 901 mit Prioritätsordnung h und ein Regelmodul 902 mit Prioritätsordnung h + 1. Regelmodul 901 ruft Dienste F1, F2, F5 und F6 auf, während Regelmodul 902 Dienste F3, F4, F7 und F8 aufruft. Die Dienste F1–F8 beziehen sich ferner auf Verarbeitungspunkte (processing points, PP) 903 und 904. Verarbeitungspunkt 903 inkludiert Dienste F1–F4, und Verarbeitungspunkt 904 inkludiert Dienste F5–F8. Die Verarbeitungspunkte 903–904 sind derart nummeriert, dass der Verarbeitungspunkt 903 den Index K hat, und Verarbeitungspunkt 904 den Index K + 1 hat, was anzeigt, dass Verarbeitungspunkt 903 vor Verarbeitungspunkt 904 verarbeitet wird.
  • Gemäß dieser Ausführungsform werden Regeln in einer Sequenz der Verarbeitungspunkte angewendet. Wenn Regelmodule verarbeitet werden, werden folglich nur die Dienstausführungsregeln ausgeführt, die zu dem aktuellen Verarbeitungspunkt gehören.
  • Für jeden Verarbeitungspunkt gibt es Mengen von Regelmodulen, die gemäß Priorität gruppiert sind, und die in diesem Verar beitungspunkt aufgerufen werden können. Alle Regelmodule von Priorität 1 sind in Menge 1 gruppiert, alle Regelmodule von Priorität 2 sind in Menge 2 gruppiert usw. In einem gegebenen Ereigniskontext wird jedoch höchstens ein Regelmodul in jeder dieser Mengen aufgerufen. Ein Regelmodul kann über mehrere Verarbeitungspunkte verteilt sein.
  • In dem Beispiel von 9 werden zuerst die Dienste des Verarbeitungspunktes 903 gemäß ihrer Regelmodulpriorität verarbeitet, d.h. Dienste F1 und F2 werden vor Diensten F3 und F4 verarbeitet. Anschließend werden die Merkmale F5 und F6 von Verarbeitungspunkt 904 und Priorität h vor Diensten F7 und F8 aufgerufen.
  • Die Regelmodule 901 und 902, die in 9 schematisch veranschaulicht sind, können wie in den folgenden Beispielen von Regelmodulen angezeigt ausgedrückt werden.
  • Figure 00650001
  • Figure 00660001
  • 10 veranschaulicht den Verarbeitungsmechanismus der Ausführungsform von 9 in dem Fall von mehreren Regelmodulen und mehreren Verarbeitungspunkten. Gemäß dieser Ausführungsform gibt es vier Verarbeitungspunkte, die mit PO bis P3 nummeriert sind, und fünf Regelmodule RM A bis RM E, jeweils mit Prioritäten 1 bis 5. Gemäß den Verarbeitungsregeln, die in Verbindung mit 9 beschrieben werden, werden Dienste verarbeitet, wie durch die Kreise in 10 angezeigt, die mit 1 bis 20 nummeriert und durch Pfeile verbunden sind. Jeder nummerierte Kreis kann eine Menge von Regeln darstellen, die eine Zahl von Aktionen aufrufen.
  • 11 veranschaulicht ein anderes Beispiel der Verarbeitungsregeln, die in Verbindung mit 9 beschrieben werden. 11 veranschaulicht Instanzen 1111a–1115a von Regelmodulen RM A bis RM E auf der linken Seite 1101 bzw. Instanzen 1111b–1115b der Regelmodule RM A bis RM E auf der rechten Seite 1102 der Figur. Die Regelmodule RM A bis RM E umfassen Regeln entsprechend Verarbeitungspunkten P0 bis P6. Daher können die Instanzen von Regelmodulen auf der linken Seite 1101 unterschiedliche Sektionen der gleichen jeweiligen Regelmodule wie die Regelmodule auf der rechten Seite 1102 darstellen. Wie in Verbindung mit 6 beschrieben wurde, werden die Verarbeitungspunkte P1–P3 durch SIP-Anfragen getriggert, während die Verarbeitungspunkte P4–P6 durch Antworten getriggert werden. Verarbeitungspunkt P0 wird durch sowohl Anfragen als auch Antworten getriggert. Daher triggert in diesem Beispiel eine eingehende SIP-Anfrage 1103, z.B. eine EINLADEN-Anfrage, Dienste von Regelmodulen RM A bis RM E, die sich auf Verarbeitungspunkte P0–P3 beziehen, in der Reihenfolge, die durch die Pfeile auf der linken Seite 1101 in 11 angezeigt wird. In dem Beispiel von 11 wird weiter angenommen, dass ein Dienst 1104 eine Instruktion ausgibt, die eine Antwort 1105 bewirkt. Diese Antwort wiederum triggert die Verarbeitung der Regeln der Regelmodule RM A (111b) bis RM E (1115b), die sich auf die Verarbeitungspunkte P0 und P4–P6 beziehen, wie auf der rechten Seite 1102 von 11 angezeigt, beginnend mit dem (den) Dienst(en) 1106, und zu einer ausgehenden Nachricht 1108 führend, z.B. einer generierten vorläufigen Antwort. Die Verarbeitung der Dienste auf der linken Seite 1101 führt ferner zu einer ausgehenden Nachricht 1107, z.B. einer EINLADEN-Proxy-Anfrage.
  • 12 veranschaulicht eine hierarchische Regelmodulverarbeitung gemäß einer bevorzugten Ausführungsform der Erfindung. Wenn der Regelantrieb (rule engine, RE) 1200 Ereignis 1201 empfängt, identifiziert er die relevanten Regelmodule 1216–1219 von unterschiedlichen Prioritäten für dieses Ereignis in der Regelbasis. Der Regelantrieb 1200 generiert einen aktuellen Ereigniskontext 1202, initiiert eine Verarbeitung des Regelmoduls höchster Priorität 1216 und übergibt die Steuerung über den generierten aktuellen Ereigniskontext 1202 zu diesem Regelmodul 1216. Wenn die Verarbeitung des Regelmo duls höchster Priorität 1216 abgeschlossen ist, ruft der Regelantrieb 1200 das nachfolgende Regelmodul 1217 gemäß Regelmodulpriorität auf und gibt den modifizierten aktuellen Ereigniskontext 1206 zu dem nächsten Regelmodul 1214 weiter. Ähnlich werden die nachfolgenden Regelmodule 1218–1219 aufgerufen und die Steuerung über die jeweiligen aktuellen Ereigniskontexte 1207 und 1214 wird zu ihnen weitergegeben. Schließlich wird der resultierende Ereigniskontext 1215 zu dem Regelantrieb 1200 zurückgegeben. Gemäß dieser Ausführungsform der Erfindung kann jedes aufgerufene Regelmodul anschließend ein oder mehrere andere Regelmodule aufrufen. Gemäß einer bevorzugten Ausführungsform sind Regelmodule in zwei Typen von Regelmodulen unterteilt: Regelmodule 1216–1219, die durch den Regelantrieb 1200 gemäß ihrer Ordnungspriorität aufgerufen werden können, und Regelmodule 1220–1225, die nur durch andere Regelmodule aufgerufen werden können. Der letztere Typ von Regelmodulen kann formal durch eine spezielle Ordnungspriorität identifiziert werden, z.B. durch die Ordnungspriorität 0. Gemäß dieser Ausführungsform haben Regelmodule mit dieser Priorität spezielle Einschränkungen, die mit ihnen in Verbindung stehen: Regelmodule mit dieser Ordnungspriorität sollten nicht durch die Regelbasisverarbeitungsprozedur des Regelantriebs 1200 aufgerufen werden, sondern werden von einem anderen Regelmodul mit expliziten Privilegien dies zu tun aufgerufen. Regelmodule mit einer Ordnungspriorität, die sich von 0 unterscheidet, werden nicht von einem anderen Regelmodul aufgerufen, sondern nur durch den Regelantrieb. Regelmodule mit dem gleichen Besitzer können die gleiche Ordnungspriorität (verschieden von 0) haben, aber in diesem Fall sollten sie unterschiedliche Ereigniskontexte haben, z.B. SIP, HTTP, etc. Dies bedeutet, dass sie nicht in dem gleichen Ereigniskontext aufgerufen werden sollten. Regelmodule mit unterschiedlichen Besitzern können die gleiche Ordnungspriorität haben, aber in diesem Fall sollten sie nicht in der gleichen Eigenschaft in dem gleichen Ereig nis aufgerufen werden. Mit anderen Worten sollten Regelmodule, die in der gleichen Nachrichteneigenschaft von einem gegebenen Ereigniskontext aufgerufen werden können, unterschiedliche Prioritäten haben, es sei denn, sie ist Null. Das erste Regelmodul 1216 wird durch den Regelantrieb aufgerufen, bevor beliebige Regelmodule mit Ordnungspriorität 0 aufgerufen werden. Dieses Regelmodul wird als das Wurzelregelmodul bezeichnet. Wenn das Wurzelregelmodul 1216 Regelmodule mit Priorität 0 aufruft, können sie erneut andere Regelmodule mit Priorität 0 aufrufen. Diese Beziehungen zwischen Regelmodulen werden die Regelmodulhierarchie genannt. Dieser Mechanismus zum Aufrufen von Regelmodulen von innerhalb von Regelmodulen ergibt eine hierarchische Verteilung von administrativen Domänen, die auch das hierarchische administrative Domänenmodell genannt wird. Die Vorteile bei diesem Modell bestehen darin, dass es leicht zu administrieren ist und den Hauptregelmodulen eine große Menge von Steuerung gibt. Es ist ein weiterer Vorteil, dass zusätzliche Regelmodule einer existierenden Hierarchie hinzugefügt werden können, ohne dass eine große Zahl von Prioritäten nachfolgenden Regelmodulen erneut zurückgewiesen werden muss.
  • Die obigen Regeln vermeiden, dass Regelmodule in der Regelbasisverarbeitungsprozedur zufällig zweimal aufgerufen werden.
  • In dem Beispiel, das in 12 veranschaulicht wird, ruft Regelmodul 1216 Regelmodule 1221 und 1222 in dieser Reihenfolge auf, übergibt die Steuerung der entsprechenden Ereigniskontexte 1203–1204 und empfängt den resultierenden aktuellen Ereigniskontext 1205. Ähnlich ruft Regelmodul 1218 Regelmodule 1222–1223 mit den entsprechenden Ereigniskontexten 1208–1209 und dem resultierenden Ereigniskontext 1213 auf. Schließlich ruft das Regelmodul 1223, das durch Regelmodul 1218 aufgerufen wird, ferner Regelmodule 1224–1225 mit den entsprechenden Ereigniskontexten 1210–1211 und dem resultierenden Ereigniskontext 1212 auf.
  • Daher wird ein hierarchischer Aufrufprozess durchgeführt, der eine Sequenz von aktuellen Ereigniskontexten generiert, die durch die Nummerierung der Ereigniskontexte 1202–1215 angezeigt wird.
  • Es wird vermerkt, dass falls mehr als ein Verarbeitungspunkt definiert ist, die obige Beschreibung von Regelmodulverarbeitung als pro Verarbeitungspunkt verstanden werden sollte, d.h. für jeden Verarbeitungspunkt wird eine entsprechende Hierarchie von Regelmodulen verarbeitet.
  • Eine wichtige Aufgabe der Regelbasisverarbeitungsprozedur des Regelantriebs 1200 ist die Abbildung von SIP-Ereignissen auf relevante Regelmodule. Dieser Prozess hängt sehr stark von den vertraglichen Beziehungen ab, die in der in Frage kommenden Domäne definiert sind. Ein SIP-Ereignis inkludiert eine Zahl von Nachrichteneigenschaften, die verwendet werden können, um eine mögliche vertragliche Beziehung zu erfassen. Diese Eigenschaften inkludieren siprequest.from (SIP-Anfrage.von), siprequest.to (SIP-Anfrage.zu), siprequest.RequestURI (SIP-Anfrage.URI-Anfordern), sipresponse.from (SIP-Antwort.von), sipresponse.to (SIP-Antwort.zu), sipresponse.contact (SIP-Antwort.Kontakt) und sipresponse.via (SIP-Antwort.über). Insbesondere sind die From und Request-URI einer SIP-Nachricht wichtige Eigenschaften eines Ereignisses, die verwendet werden, um eine vertragliche Beziehung mit einem Netzbetreiber oder einem Dienstanbieter einer dritten Seite zu erfassen. Es können jedoch andere Nachrichteneigenschaften berücksichtigt werden, z.B. Kontakt-Header und via-Header. Eine Nachrichteneigenschaft, die verwendet werden kann, um eine vertragliche Beziehung zu erfassen und somit ein Regelmodul zu triggern, wird als ein Regelmodultrigger (RMTrigger) bezeichnet.
  • Wenn eine SIP-Anfragenachricht in einem SIP-Server ankommt, sollte mindestens eine von den From- oder Request-URI-Nachrichteneigenschaften einen Teilnehmer spezifizieren, der eine vertragliche Beziehung mit einem der Netzbetreiber des SIP-Servers hat. Die Nachrichteneigenschaften von From oder Request-URI können einen Domänennamen, wie netopX.com, oder eine IP-Adresse von einem der Netzbetreiber des SIP-Servers, wie 123.123.123.000, enthalten. Außerdem inkludieren die From oder Request-URI einen Teilnehmeridentifikator, wie einen Namen oder eine Telefonnummer. Dies ist in der SIP URL oder TEL URL enthalten. Die SIP-URL hat auch Parameter wie "transport-param", "user-param" ("Benutzer-param") und "other-param" ("andere-param"). Diese Parameter können Information inkludieren, die für einen Netzbetreiber spezifisch ist, wie die IMSI, um Teilnehmer eines mobilen Endgerätes und Endgeräte zu identifizieren.
  • Unter Verwendung z.B. der obigen Eigenschaften kann ein SIP-Ereignis auf einen eindeutigen Netzbetreiber abgebildet werden, falls eine Zahl von Anforderungen erfüllt sind, z.B. falls jeder der Netzbetreiber des SIP-Servers einen eindeutigen Domänennamen hat, wie netopX.com und netopY.com, und falls sie unterschiedliche IP-Adressen haben. Falls sie die gleiche IP-Adresse gemeinsam nutzen, können mutmaßliche Beziehungsauflösungen mehrdeutig sein, da die Nachrichteneigenschaften der From und Request-URI eine IP-Adresse und nicht einen Domänennamen enthalten können.
  • Dienstanbieter einer dritten Seite, die Dienstanwendungen auf den SIP-Server hochladen/registrieren, haben eine vertragliche Beziehung mit dem Netzbetreiber, die erfasst werden kann. Z.B. kann der Dienstanbieter einer dritten Seite eine zuge wiesene ID von dem Netzbetreiber empfangen, mit dem der Dienstanbieter einer dritten Seite eine vertragliche Beziehung hat. Falls der Netzbetreiber einen Domänennamen hat, z.B. netopX.com, und eine zugehörige IP-Adresse, kann der Dienstanbieter einer dritten Seite mit einem eindeutigen Namen partyZ zugewiesene IDs empfangen, die einer Namenskonvention folgen, z.B. "partyZ.netopX.com". Nun können die From und Request-URI auf relevante Regelmodule abgestimmt werden. Da sowohl netopX.com als auch partyZ.netopX.com in einem Ereignis aufgerufen werden sollten, das netopX.com in entweder dem From oder Request-URI enthält, sollten sie unterschiedliche explizite Ordnungsprioritäten haben. Es wird verstanden, dass stattdessen andere Namenskonventionen eingeführt werden können.
  • Es wird verstanden, dass die Mechanismen von Ordnungspriorität und Regelmodulhierarchie unabhängig voneinander oder in Kombination miteinander angewendet werden können, wie in Verbindung mit 12 beschrieben wurde.
  • 13 zeigt ein Beispiel des Flusses von SIP-Nachrichten und Instruktionsmengen gemäß einer Ausführungsform der Erfindung. Der Nachrichtenparser 1304 konvertiert die ursprüngliche SIP-Nachricht 1306 in ein ursprüngliches SIP-Nachrichtenobjekt 1303. Dies wird verwendet, um das Anfangsregelmodul 1301 aufzurufen, und daher die erste Sequenz von Dienstanwendungen. Wenn ein Regelmodul 1301 in den Regelantrieb 1302 geladen und ausgeführt wird, werden eine oder mehr Aktionen erreicht, abhängig von dem Signalisierungsnachrichtenobjekt 1303, das von dem Nachrichtenparser 1304 empfangen wurde und auf der Basis dessen Regelmodul 1301 identifiziert wurde, wie z.B. in Verbindung mit 12 beschrieben. Wenn eine Aktion erreicht wird, wird die Dienstanwendung 1305, die mit der Aktion in Verbindung steht, aufgerufen, d.h. sie wird aktiviert, möglicherweise mit Parametern und möglicherweise mit Zugriff auf das gesamte Signalisierungsnachrichtenobjekt 1303, das die Anwendung getriggert hat. Die Zugriffsprivilegien zu der gesamten Signalisierungsnachricht hängen von der Funktionalität und dem Bereich der verwendeten Dienstzugriffs-API, z.B. Cgi API im Vergleich zu OSA API, ebenso wie den Privilegien des Besitzers des Regelmoduls 1301 und den Privilegien der aufgerufenen Dienstanwendung 1305 ab. Das Anfangssignalisierungsnachrichtenobjekt 1303 repräsentiert die gesamte Menge von Nachrichteneigenschaften, die in der ursprünglichen SIP-Nachricht 1306 eingebettet sind, die mehrere Medientypen inkludieren kann. Die aufgerufene Dienstanwendung 1305 führt einige Verarbeitung basierend auf der Signalisierungsnachricht 1303 durch und gibt das Ergebnis 1307 zu dem Regelantrieb 1302 zurück. Dieses Ergebnis wird als die Instruktionsmenge bezeichnet, da es potenziell mehrere Instruktionen enthalten kann, z.B. CGI-Instruktionen, OSA-API-Instruktionen etc. Wenn mehrere Dienste basierend auf einer Signalisierungsnachricht aufgerufen werden, wird der Regelmodulprozessor zu mehreren Instruktionsmengen kommen. Diese Menge von Instruktionsmengen wird als die "Instruktionsmengenbasis" bezeichnet.
  • Der Regelantrieb 1302 und der Anwendungsausführungsantrieb bestimmen, welche Instruktionen zu dem SIP-Servervorgabeverhalten 1308 zu vermitteln sind. Die Instruktionsmenge kann basierend auf Privilegien und Merkmalsinteraktionsauflösung gefiltert werden, bevor sie zu dem SIP-Servervorgabeverhalten 1308 vermittelt wird, was die Instruktionsmenge ferner mit einer Vorgabe-SIP-Instruktionsmenge 1312 vereinigen kann. Die resultierende Menge von Instruktionen wird die "resultierende Instruktionsmenge" genannt. Das (die) resultierende(n) SIP-Nachrichtenobjekt(e) repräsentiert(en) die tatsächlichen SIP-Nachrichten, die stromabwärts oder stromaufwärts zu senden sind. Daher führt dies zu einem oder mehr resultierenden SIP-Nachrichtenobjekten 1309, die zu dem Nachrichtenkonverter 1310 gesendet werden, der sie anschließend in eine oder mehr zu sendende SIP-Nachrichten 1311 transformiert.
  • 14 veranschaulicht einen Mechanismus zum Managen mehrerer Instruktionsmengen gemäß einer bevorzugten Ausführungsform der Erfindung. Gemäß dieser Ausführungsform ist ein Ereigniskontext eine Darstellung eines SIP-Nachrichtenobjektes, er kann aber zusätzliche Information enthalten, wie etwa Merkmalsinteraktionsinformation ebenso wie die MIME-Typen, die in dem Nachrichtenrumpf der SIP-Nachricht inkludiert sind. Der ursprüngliche Ereigniskontext 1401 repräsentiert das ursprüngliche SIP-Nachrichtenobjekt 1402. Der aktuelle Ereigniskontext 1403a–b ist ein Ereigniskontext basierend auf der Instruktionsmenge, die durch die Dienstanwendungen 1404–1405 generiert wird. In einem beliebigen gegebenen Zeitpunkt ist eine Dienstanwendung in Steuerung des aktuellen Ereigniskontextes. Selbst wenn mehrere Dienstanwendungen gleichzeitig laufen und Steuerung auf die Handhabung der Transaktion anwenden, hat nur eine von ihnen die Steuerung des aktuellen Ereigniskontextes in einem beliebigen Zeitpunkt. In dem Beispiel von 14 werden zwei Dienstanwendungen 1404–1405 gezeigt. Anfangs hat Dienstanwendung 1404 die Steuerung über den aktuellen Ereigniskontext 1403a. Wenn die Anwendung 1404 ihre Verarbeitung abgeschlossen hat, wird die Steuerung über den aktuellen Ereigniskontext zu der Dienstanwendung 1405 übergeben. Zu diesem Punkt steuert Dienstanwendung 1405 den aktuellen Ereigniskontext 1403b, d.h. sie hat das Recht ihn zu lesen und zu schreiben. In einer Ausführungsform der Erfindung können andere Dienstanwendungen das Recht haben, den aktuellen Ereigniskontext 1403b zu lesen.
  • Daher basiert Triggern von nachfolgenden Dienstanwendungen auf dem aktuellen Ereigniskontext. Der aktuelle Ereigniskontext wird ferner für mögliche Merkmalsinteraktionsprobleme bereinigt, so dass anschließend aufgerufenen Dienstanwendun gen auf ihm beruhen können. Wenn die Steuerung von einer Dienstanwendung zu der nächsten durch den Aufrufmechanismus übergeben wird, der durch den Regelantrieb bereitgestellt wird, wird der Besitz des aktuellen Ereigniskontextes übergeben. Auf diese Weise wird, wenn alle Dienstanwendungen aufgerufen wurden und ihre Instruktionen angewendet haben, der endgültige resultierende Ereigniskontext 1406 erreicht. Somit repräsentiert der resultierende Ereigniskontext 1406 das (die) resultierende(n) SIP-Nachrichtenobjekt(e) 1407. Es ist zu beachten, dass dieser Mechanismus parallele Verarbeitung nicht ausschließt, da die Dienstanwendungen 1404 und 1405 parallel ausgeführt werden können. Gemäß dieser Ausführungsform wird jedoch eine Sequenz einer Aktualisierung des aktuellen Ereigniskontextes durchgesetzt.
  • Es wird ferner vermerkt, dass eine Dienstanwendung eine Anfrage zu mehreren Zielen aufspalten kann. Dies führt zur Generierung von mehreren aktuellen Ereigniskontexten.
  • 15 veranschaulicht einen Baum von kaskadierten Ketten von Dienstanwendungen gemäß einer Ausführungsform der Erfindung. Wenn Dienste auf unterschiedlichen SIP-Servern ausgeführt werden und eine Steuerung auf eine Sitzung anwenden, sehen sie eine natürliche Ordnung von Diensten vor, selbst wenn sie einander nicht kennen. Von dieser Ordnung kann gesagt werden, dass sie stromaufwärts oder stromabwärts ist. Eine stromabwärtige Ordnung ist die Ordnung von Diensten, da sie stromabwärts von dem ursprünglichen Client zu dem Zielserver aufgerufen werden. Eine stromaufwärtige Ordnung ist die Ordnung von Diensten, da sie stromaufwärts von dem Zielserver zu dem ursprünglichen Client aufgerufen werden. Wenn Dienste, die eine Steuerung auf eine Instanz einer Sitzung anwenden, in einer gegebenen Reihenfolge auf dem gleichen SIP-Server aufgerufen werden, kann von den Diensten angenommen werden, dass sie gemäß dem gleichen Ordnungsprinzip kaskadiert sind. Dieses Ordnungsprinzip wird Kaskadieren von Diensten genannt, und die Kette von Diensten wird die kaskadierte Kette von Diensten genannt.
  • Wenn eine Anfrage empfangen wird, wird ein Dienst umso eher basierend auf diesem Ereignis aufgerufen, desto mehr logisch stromaufwärts er in der Kette von kaskadierten Diensten betrachtet wird. Wenn eine Antwort empfangen wird, wird der Dienst basierend auf diesem Ereignis umso eher aufgerufen, desto mehr logisch stromabwärts er in der Kette von kaskadierten Diensten betrachtet wird. Daher werden die Anwendungen behandelt, als ob sie auf unterschiedlichen Hosts getriggert wären.
  • Dieses Modell ist konzeptionell einfach und sieht einen natürlichen Algorithmus zum Auflösen von Konflikten zwischen den Instruktionen von mehreren Dienstanwendungen in dem gleichen SIP-Ereignis vor.
  • Bei Empfang eines SIP-Ereignisses werden die Aktionen in der Reihenfolge einer Priorität auf die folgende Art und Weise ausgeführt:
    • 1) Steuerung wird zu der ersten Anwendung weitergegeben.
    • 2) Es wird irgendeine Antwort von der ersten Anwendung empfangen.
    • 3) Steuerung wird zu der zweiten Anwendung weitergegeben.
    • 4) Es wird irgendeine Antwort von der zweiten Anwendung empfangen usw.
  • Falls jedoch die erste Anwendung die Anfrage beendet, wird die zweite Anwendung nicht aufgerufen.
  • Auf diese Weise kann eine Entscheidung darüber, ob eine nachfolgende Anwendung aufzurufen ist, von der Ausgabe von der vorherigen Anwendung abhängen. Des weiteren sind Instruktionsprioritäten, die mit Aktionen in Verbindung stehen, per Vorgabe gemäß dem kaskadierenden Prinzip geordnet.
  • Falls eine Anwendung eine Anfrage aufspaltet, gibt es keine einfache Kette von kaskadierten Diensten, sondern vielmehr einen Baum von kaskadierten Diensten. Dies wird als der "Anfragebaum" bezeichnet. Ein Anfragebaum repräsentiert eine Zahl von kaskadierten Ketten von Anwendungen. Jeder Pfad von der Wurzel des Baums zu einem der Blätter repräsentiert eine kaskadierte Kette.
  • 15 zeigt ein Beispiel eines Anfragebaums, wo eine Dienstanwendung APP1 durch das Regelmodulausführungsmodul (rule module execution module, RMEM) 1501 mit dem ursprünglichen Ereigniskontext (original event context) OEC als eine Eingabe aufgerufen wird. Wenn die Steuerung von der Anwendung APP1 zu der nachfolgenden Anwendung APP2 übergeben wird, erlangt die Anwendung APP2 Steuerung über den aktuellen Ereigniskontext EC2. Die Anwendung APP2 spaltet die Anfrage auf, wobei Ereigniskontext EC3 und Ereigniskontext EC4 erstellt werden. Eine Aktion unterer Priorität ruft Anwendung APP3 wegen einer oder mehr Eigenschaften im Ereigniskontext EC3 auf. Eine andere Aktion unterer Priorität ruft eine andere Anwendung APP4 wegen einer oder mehr Eigenschaften im Ereigniskontext EC4 auf. Dies führt zu einer baumartigen Struktur, die die Spur von aufgerufenen Anwendungen darstellt. In diesem Baum sind die Zweige Darstellungen von Ereigniskontexten. Die Knoten sind Darstellungen von Triggern. Die Wurzel des Baums ist der ursprüngliche Ereigniskontext OEC. Die Blätter des Baums sind die resultierenden Ereigniskontexte (resulting event contexts) REC1 und REC2.
  • Wenn es keine Aktionen mehr in einem Regelmodul gibt, werden alle aktuellen Ereigniskontexte zu der Regelbasisverarbei tungsprozedur 1502 zurückgeführt. Diese Prozedur kann ein anderes Regelmodul aufrufen, welches mehr von dem Anfragebaum aufbauen wird. Folglich kann der Baum mit vielen Knoten und Zweigen abhängig von den Diensten, die getriggert werden, ziemlich groß werden.
  • Es wird vermerkt, dass in einigen Fällen eine Anwendung eine asynchrone Merkmalsinstruktion zu der Dienstunterstützungsumgebung, d.h. nicht bezogen auf eine existierende Transaktion, senden kann. In diesem Fall hat die Anwendung eine neue Transaktion gestartet und wird betrachtet, in der Wurzel eines neuen kaskadierten Kettenbaums zu sein.
  • Um parallele Verarbeitung von Diensten zu erlauben, kann die Dienstunterstützungsumgebung zum gleichzeitigen Weitergeben der Steuerung zum mehr als einem Dienst fähig sein. Dies steht nicht im Widerspruch zu dem kaskadierten Dienstmodell, da die Instruktionen von den parallelen aufgerufenen Diensten in der Reihenfolge der Kaskadierung angewendet werden sollten. Falls der stromabwärtigere Dienst vor dem stromaufwärtigeren Dienst antwortet, wartet der Regelantrieb darauf, dass der stromaufwärtigere Dienst antwortet, bevor er die Instruktionen vermitteln kann. Diese Instruktionen werden vermittelt, als ob die Dienste einer nach dem anderen aufgerufen wären. Der Administrator sollte fähig sein zu spezifizieren, ob eine Gruppe von Aktionen auf diese Art und Weise gleichzeitig angewendet werden sollte.
  • 16 zeigt die Softwarekomponenten eines Regelantriebs gemäß einer Ausführungsform der Erfindung. Die Regelbasisverarbeitungsprozedur 1601 ruft die Regelmodule 1602, die in der Regelbasis 1603 gespeichert sind, in der richtigen Reihenfolge auf. Die Regelmodulverarbeitungsprozedur 1604 führt die Regeln in dem Regelmodul aus. Das Dienstinteraktionsmodul 1605 deckt eine Menge von Funktionen 1700 ab, inkludierend Durchsetzung des Triggerns, Merkmalsinteraktion, Privilegien und Rechten. Die Funktionen 1700 werden in Verbindung mit 17 detaillierter beschrieben.
  • Wenn ein SIP-Ereignis dem Regelantrieb in der Form eines ursprünglichen Ereigniskontextes 1609 gemeldet wird, wird die Regelbasisverarbeitungsprozedur 1601 ausgeführt, um die richtigen Regelmodule zu finden und in der richtigen Reihenfolge auszuführen. Die Regelbasisverarbeitungsprozedur 1601 leitet die Regelmodule, die zu verarbeiten sind, und den ursprünglichen Ereigniskontext 1610 zu der Regelmodulverarbeitungsprozedur 1604 weiter. Die Ordnung der Regelmodule bestimmt gemeinsam mit der Ordnung der Regeln innerhalb jedes Regelmoduls die Ordnung von Mustern und Aktionen 1606–1608, die durch die Regelmodulverarbeitungsprozedur 1604 verarbeitet werden. Die Aktionen rufen entsprechende Dienstanwendungen 1611–1613 auf. Wenn Dienstanwendung 1611 aufgerufen wird, wird der ursprüngliche Ereigniskontext als der aktuelle Ereigniskontext (current event context) CEC1 zu dem Dienstinteraktionsmodul 1605 weitergegeben, das wiederum den Ereigniskontext EC1 zu der Dienstanwendung 1611 weitergibt. Die Dienstanwendung 1611 führt zu einer Menge von Merkmalsinstruktionen 1614, die eine Aktualisierung des aktuellen Ereigniskontextes durch das Dienstinteraktionsmodul 1605 bewirken. Der resultierende aktuelle Ereigniskontext 1615 wird zu der Regelmodulverarbeitungsprozedur 1604 zurückgegeben. Die Dienstanwendungen 1612 und 1613 werden auf eine ähnliche Art und Weise aufgerufen, was zu entsprechenden Instruktionsmengen 1616–167 führt, die durch das Dienstinteraktionsmodul 1605 in entsprechende aktuelle Ereigniskontexte 1618–1619 konvertiert werden. Während dieser Konvertierung führt das Dienstinteraktionsmodul 1605 Autorisierungsprüfungen durch, und falls eine Dienstanwendung 1613 eine nicht-autorisierte Instruktionsmenge 1617 zurückgibt, werden die nicht-autorisierten Instruktionen nicht konvertiert. Daher unterscheidet sich der aktuelle Ereigniskontext 1619 nicht von dem eingehenden Ereigniskontext 1620. Vorzugsweise wird die Dienstanwendung über diesen Fehler informiert 1621. Es ist zu vermerken, dass ein Dienst zur Erzeugung von mehreren aktuellen Ereigniskontexten führen kann, wie in Verbindung mit 15 und 18 beschrieben wird. Wenn ein Regelmodul eine Verarbeitung der Muster und Aktionen 1606–1608 beendet hat, wird die endgültige Menge von aktuellen Ereigniskontexten 1622 zu der Regelbasisverarbeitungsprozedur 1601 zurückgegeben. Nachfolgende Aufrufe von Regelmodulen werden von dieser Menge von aktuellen Ereigniskontexten abhängen. Es wird vermerkt, dass eine Dienstanwendung Ereignisse und Trigger für zukünftige Ereignisse scharfmachen/entschärfen kann, wie nachstehend detaillierter beschrieben wird. Daher kann eine Dienstanwendung ferner eine Scharfmachungsanfrage 1623 zurückgeben.
  • 17 zeigt Schritte, die durch das Dienstinteraktionsmodul zwischen der Verarbeitung des Regelmoduls und der Verarbeitung der Dienstanwendung in der Ausführungsform von 16 durchgeführt werden. Diese Funktionalität 1700 inkludiert Merkmalsinteraktionsmanagement und Prüfung von Privilegien, was durch den Regelantrieb 1702 und den Anwendungsausführungsantrieb 1703 durchgeführt wird. Wenn der Aufrufbefehl und der aktuelle Ereigniskontext CECa von dem Regelmodulprozessor 1601 empfangen werden, werden die Privilegien des Regelmoduls in Schritt 1704 geprüft. Die Privilegien des Regelmoduls sind in einer Zugriffssteuerliste (access control list) ACL2 spezifiziert, die mit dem Regelmodul in Verbindung steht. Falls das Regelmodul die Privilegien hat, Aufrufbefehle zu erteilen, sendet in Schritt 1705 der Regelantrieb 1702 den Aufrufbefehl zu dem Anwendungsausführungsantrieb 1703 über den Anwendungsausführungsantriebsmanager (nicht gezeigt). Es kann nur notwendig sein, einen Teil des aktuellen. Ereigniskontextes zu dem Anwendungsausführungsantrieb 1703 zu senden, wie durch f(CECa) bezeichnet wird.
  • In Schritt 1706 konvertiert der Anwendungsausführungsantrieb 1703 den empfangenen Ereigniskontext f(CECa) in ein geeignetes Datenformat für die Dienstanwendung 1707, die aufzurufen ist. Dies kann die Konvertierung in einen geeigneten Namensraum für den Aufruf dieser Dienstanwendung inkludieren. Des weiteren prüft der Anwendungsausführungsantrieb 1703 in Schritt 1708 Privilegien und Rechte. Eine Zugriffssteuerliste ACL3, die mit der Dienstanwendung 1707 in Verbindung steht, kann die Privilegien der Dienstanwendung 1707 spezifizieren, um auf den Wert von f(CECa) oder einen Teil von ihm zuzugreifen. Des weiteren hat das Regelmodul Zugriff auf die Dienstanwendung 1707 abhängig von einer anderen Zugriffssteuerliste ACL4, die auch mit der Dienstanwendung 1707 in Verbindung steht. Falls Zugriff gewährt wird, wird die Dienstanwendung 1707 in Schritt 1709 aufgerufen, und relevante Teile des Ereigniskontextes g(ECa) werden als eine Eingabe vorgesehen. Anschließend gibt die Dienstanwendung 1707 die Steuerung zu dem Regelantrieb 1702 über den Anwendungsausführungsantrieb 1703 durch Senden der Instruktionsmenge 1710 oder einer internen Darstellung der Instruktionsmenge zurück. In Schritt 1711 werden Privilegien und Rechte der Dienstanwendung 1707, um diese Instruktionen zu erteilen, geprüft, z.B. basierend auf einer Zugriffssteuerliste ACL5, die mit der Dienstanwendung 1707 in Verbindung steht. Falls die Dienstanwendung 1707 die Privilegien hat, diese Instruktionen zu erteilen, werden die Instruktionen von der internen Darstellung konvertiert (Schritt 1712), und die konvertierten Instruktionen 1713 werden zu dem Regelantrieb weitergeleitet. Des weiteren werden ebenso beliebige Scharfmachungsanfragen 1716 weitergeleitet. In Schritt 1714 werden mögliche Merkmalsinteraktionsprobleme mit vorher erteilten Instruktionen von zuvor autorisierten und aufgerufenen Dienstanwendungen aufgelöst. Diese Auflösung basiert darauf, ob zuvor aufgerufene Anwendungen geschützte Nachrichteneigenschaften in dem aktuellen Ereigniskontext ha ben. Der nächste aktuelle Ereigniskontext CECb wird generiert und zu dem Regelmodulprozessor 1601 zurückgegeben. Schließlich speichert in Schritt 1715 der Regelantrieb Information über den aufgerufenen Dienst im Speicher, z.B. durch Aufbauen des Anfragebaums, der in Verbindung mit 14 beschrieben wird. Der Anfragebaum wird in Verbindung mit dem Berichten von zukünftigen Ereignissen verwendet.
  • Wie zuvor erwähnt, sind einige Dienste, z.B. Überwachungsanwendungen, an zukünftigen Ereignissen interessiert. Um dem Regelantrieb über dieses Interesse an zukünftigen Ereignissen mitzuteilen, muss die Dienstanwendung nach Ereignisberichten nachfragen, was auch dynamisches Scharfmachen für Ereignisberichte genannt wird.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung ist dynamisches Scharfmachen von Transaktionsereignissen an die Verarbeitung einer SIP-Transaktion gebunden, was zeitlich gebunden ist. Transaktionen können typischerweise von zwischen einigen Millisekunden bis zu einigen Minuten dauern, abhängig von der Konfiguration des SIP-Servers. Da dynamisches Scharfmachen von Transaktionsereignissen nur auf die Lebensdauer einer Transaktion zutrifft, ist dieser Typ vom Scharfmachen nicht permanent und wird implizit entschärft, wenn die Transaktion beendet ist, wobei dadurch ein schneller Mechanismus vorgesehen wird. Falls eine Anwendung Ereignisse scharfmacht, die die Transaktion betreffen, in der sie getriggert wurde, behält die Anwendung ihren Platz in dem kaskadierten Dienstmodell. Antworten werden allen Anwendungen gemeldet, die sie scharfgemacht haben, beginnend mit dem Blatt des Baums, d.h. der stromabwärtigsten Anwendung. Während der Lebensdauer einer Transaktion existiert der Anfragebaum in dem Speicher des Regelantriebs. Nachfolgende Ereignisse, die sich auf die gleiche Transaktion beziehen, werden somit auf den Anfragebaum bezogen. Ereignisse, die sich auf den Anfragebaum bezie hen, können von Anwendungen, von stromabwärtigen Servern und von stromaufwärtigen Clients kommen.
  • Ereignisse von stromaufwärtigen Clients betreten den Anfragebaum an der Wurzel. Dies bedeutet, dass sie zuerst der Anwendung an der Wurzel des Baums gemeldet werden. Diese Anwendung kann das Ereignis abschließen oder umlenken, in welchem Fall es nicht weiter in dem ursprünglichen Baum gesendet wird, sondern ein neuer Anfragebaum aufgebaut werden kann. Eine Anfrage kann auch zu allen gleichen Zielen wie die ursprüngliche Anfrage weitergeleitet werden müssen, oder die Anfrage kann zu einem der Ziele gesendet werden müssen, zu denen die ursprüngliche Anfrage weitergeleitet wurde. Ereignisse von Anwendungen betreten den Anfragebaum in dem geeigneten Knoten. Ereignisse von stromabwärtigen Servern betreten den Anfragebaum in einem der Blätter.
  • Dies führt zu dem Mechanismus von Anfrage-Baum-Traversal, in dem sich der Regelantrieb die Reihenfolge merkt, in der Anwendungen aufgerufen wurden, d.h. der Anfragebaum. Es ist ein Vorteil dieser Ausführungsform, dass sie eine klare Regel für die Reihenfolge vorsieht, in der Ereignisse innerhalb des Kontextes einer Transaktion gemeldet werden. Die klare Regel ist das kaskadierte Dienstmodell, welches eine konzeptionell einfache Regel ist, die durch Administratoren und Anwendungsgestalter leicht verstanden werden kann. Dies vereinfacht auch die API, über die die Anwendungsausführungsantriebe der Regelbasis Regeln hinzufügen. An Stelle LÖSCHEN eines spezifischen Zweiges in einem Regelmodul scharfmachen zu müssen, kann es einfach zum Löschen des gegebenen Rufabschnittes scharfmachen.
  • Es gibt verschiedene Wege, um das Anfrage-Baum-Traversal zu implementieren.
  • Z.B. kann der Regelantrieb dieses Traversal durch Verwenden des VIA-Headers und Zweigparameters erreichen. In der Tat würde dies Erstellen einer getrennten Instanz des Regelantriebs jedes Mal bedeuten, wenn die Zieladresse durch Weiterleiten der Anfrage zu dem SIP-Server geändert wird. Das DNS-Nachschlagen, das durch den SIP-Stapel geschieht, würde dann bestimmen, ob die Anfrage zurückkommt oder nicht, um durch den Server ein zweites Mal verarbeitet zu werden. Wenn eine Anfrage von dem SIP-Server empfangen wird, würde sie als eine neue Anfrage behandelt. Der Regelantrieb sollte einen Mechanismus haben um sicherzustellen, dass Dienste, z.B. jene, die in dem FROM-Feld getriggert werden, nicht fehlerhaft erneut aufgerufen werden.
  • Alternativ wird in einer bevorzugten Ausführungsform das Ereignis in dem Host für den gesamten Anfragebaum behandelt, d.h. inkludierend alle Weiterleitungen, bis alle Blätter des Anfragebaums Ziele anderswo in dem Netz darstellen. Diese Ausführungsform hat den Vorteil, dass sie effizienter ist, da weniger Instanzen von signalisierenden Zustandsmaschinen und Managerklassen erforderlich sind. Z.B. kann der Anfragebaum implementiert werden, indem er für jeden Trigger einer Anwendung eine Instantiierung eines Knotenobjekts hat, die Zeiger zu den vorherigen und den nächsten Knoten in dem Baum haben kann. Das folgende Pseudocodefragment zeigt, wie das Aufbauen eines Anfragebaums in die Algorithmen für Regelbasisverarbeitung und Regelmodulverarbeitung einbezogen werden kann. Die Idee besteht darin, jeden Ereigniskontext mit einem RequestTreeNode (AnfragenBaumknoten) zu verbinden. Dies ist das RequestTreeNode, in dem der Ereigniskontext erstellt wurde. Jeder Knoten ist entweder die Wurzel des Baums oder er steht mit einer Aktionsausführung in Verbindung:
    Figure 00840001
    Figure 00850001
  • Bei Betrachtung des Modells einer logischen Kaskadierung von Dienstanwendungen können die folgenden zwei allgemeinen Regeln für die Dienstausführungsumgebung wie folgt formuliert werden:
    • – Ereignisse, die sich stromaufwärts bewegen, sollten zuerst den logisch stromabwärtigsten Anwendungen gemeldet werden.
    • – Ereignisse, die sich stromabwärts bewegen, sollten zuerst den logisch stromaufwärtigsten Anwendungen gemeldet werden.
  • Die logische kaskadierte Reihenfolge von Diensten wird beibehalten, wenn Ereignisbenachrichtigungen verteilt werden, um die hoch komplexe und nicht managbare Situation zu verhindern, dass Ereignisse in einer beliebigen Reihenfolge kaskadierten Diensten gemeldet werden können.
  • Vorzugsweise werden die Anwendungen, die derartige Ereignisse scharfmachen, in Verarbeitungspunkt 1 oder 4 und ihren Teilverarbeitungspunkten aufgerufen. Vorzugsweise kann der Netzbetreiber in der Regelliste für Verarbeitungspunkt 4 einen Punkt spezifizieren, wo die dynamisch scharfgemachten Trigger gemeldet werden sollten. Dies bedeutet, dass die logisch kaskadierte Kette von Diensten, die für die Anfrage hergestellt ist, beibehalten wird, und neue Dienste entweder vor oder nach dieser Kette getriggert werden. Die gleiche Regel kann auf nachfolgende Anfragen zutreffen, die sich auf eine existierende Transaktion beziehen. Dieses Mal wird es in dem Verarbeitungspunkt 1 sein, dass der Administrator spezifizieren kann, wann dynamisch scharfgemachte Ereignisse zu berichten sind.
  • Alternativ oder zusätzlich kann ein anderer Typ zum Scharfmachen eingesetzt werden, der als dynamisch scharfgemachte Trigger bezeichnet wird, die als Regeln einem geeigneten Regelmodul in der Regelbasis hinzugefügt werden. Dynamisch scharfgemachte Trigger sehen einen weniger aufwändigen Mechanismus im Sinne von Verarbeitungsleistung und Ausführungsspeicher für das Melden von Ereignissen vor, die nicht die Transaktion betreffen, in der die Anwendung getriggert wurde. Vorzugsweise sollten diese Anfragen nach Ereignisberichten in einem persistenten Speicher gespeichert werden, d.h. sie werden Regeln in der Regelbasis. Diese Regeln können durch Spezifizieren eines Ablauftimers nicht-permanent sein, oder permanent sein. In dem letzteren Fall sollte die Dienstanwendung die Anfrage nach Ereignisberichten explizit entschärfen, um sie zu entfernen. Alternativ können sie auch in einem Modus "einmal berichten, dann entschärfen" scharfgemacht werden. Falls keine Ablauf zeit angegeben ist, kann des weiteren eine Vorgabezeit, z.B. 1 Stunde, auf die Regel angewendet werden. Wenn diese Zeit abgelaufen ist, wird die Regel gelöscht. Dies hat den Vorteil, dass vermieden wird, dass dem Server Datenspeicherkapazität ausgeht.
  • Vorzugsweise werden Triggerregeln einem Regelmodul hinzugefügt, für den die Anwendung die Privilegien und Rechte zum Aktualisieren hat. Es wird normalerweise das gleiche Regelmodul sein, von dem die Anwendung getriggert wurde. Wo genau in der Prioritätsreihenfolge innerhalb eines Regelmoduls diese Regeln hinzugefügt werden sollten, kann durch eine implizite Regelprioritätsreihenfolge bestimmt werden, d.h. eine ganze Zahl, die darstellt, wo die Regel innerhalb des existierenden Regelmoduls platziert sein sollte. Wenn zuerst ein SERL-Skript hinzugefügt wird, werden die Regeln in der Reihenfolge geordnet, wie sie in dem Skript erscheinen. Falls es N Regeln gibt, stehen die ganzen Zahlen 1 bis N impliziert mit den Regeln in Verbindung. Eine Regel kann durch Verweisen auf diese Zahlen gelöscht werden. Eine Regel kann durch Verweisen auf die Regel hinzugefügt werden, nach der die neue Regel platziert werden sollte. Dies hat den Vorteil, dass die Menge von Daten, die ausgetauscht werden muss, wenn eine Regel einem großen Regelmodul hinzugefügt wird, reduziert wird.
  • Falls keine Position spezifiziert ist, dann kann der Regelmodulantrieb dem folgenden Algorithmus folgen, wenn diese Trigger hinzugefügt werden: Durchsuchen des Regelmoduls nach dem gleichen Eigenschaftsmuster wie in der neuen Regel. Falls ein Muster gefunden wird, Suchen nach einem beliebigen Teilmuster usw. Falls kein Teilmuster gefunden wird, Einfügen der Regel als die Regel höchster Priorität in der eingeschlossenen Liste von Aktionen. Falls kein ähnliches Muster bereits in dem Regelmodul ist, Einfügen als das erste Muster. Dieser Algorithmus sieht eine logisch vorteilhafte Platzierung der Regel vor. Er stellt z.B. sicher, dass die Aktionen für den Anrufer, wo TARGET = FROM (ZIEL = VON) ist, nicht mit Aktionen für Angerufene vermischt werden, wo TARGET = RequestURI (ZIEL = AnfrageURI) ist. Es bedeutet auch, dass Regeln, die zuletzt hinzugefügt werden, auch die ersten sind, auf die getroffen wird, wenn ein Ereignis geschieht. Dies ist das einfachste Vorgabeverhalten.
  • Es kann möglich sein anzuzeigen, ob eine Triggerregel permanent ist oder automatisch gelöscht werden sollte, sobald das Ereignis gemeldet ist. Welchen Typ von Regeln eine Anwendung dynamisch hinzufügen kann, kann mit den Privilegien und Rechten verknüpft werden, die der Anwendung zugewiesen sind.
  • In einer anderen alternativen Ausführungsform wird der kaskadierte Anfragebaum nur für die Lebensdauer eines Ereignisses aufrechterhalten. In diesem Fall ist dann, wenn die letzte Anwendung in der Kette ihre Verarbeitung beendet hat und das SIP-Ereignis gesendet ist, die kaskadierte Kette nicht länger relevant. Bis zu diesem Punkt kann es für den Regelantrieb nützlich sein, eine Darstellung der kaskadierten Kette im Speicher zu halten. Dies ist so, da Anwendungen auf getrennten Servern laufen können und es einige Zeit brauchen kann, auf den Aufruf zu reagieren. Während der Regelantrieb auf eine Antwort wartet, kann eine frühere Anwendung in der Kette die Anfrage löschen. Falls dies geschieht, wird der Regelantrieb den Anwendungsausführungsantrieb der Anwendung, auf die er wartet, informieren müssen. Dies bedeutet, dass sich der Regelantrieb daran erinnern sollte, was die nächste Anwendung in der Kette war. Zu der Zeit, zu der das SIP-Ereignis weitergeleitet wurde, sollten alle Anwendungen in der Kette scharfgemachte Regeln für die Ereignisse haben, für die sich interessieren, somit gibt es für den Regelantrieb nicht län ger eine Notwendigkeit, sich an die kaskadierte Kette zu erinnern. Der Vorteil dieser Lösung besteht darin, dass der Regelantrieb selbst einfach ist. Er meldet einfach Ereignisse basierend auf Regelmodulen in den relevanten Verarbeitungspunkten. Diese Lösung ist jedoch komplex zu administrieren und platziert die Komplexität einer Ordnung der Ereignisse in die Anwendungen, d.h. die Anwendungen müssen entscheiden, in welcher Prioritätsposition die Regel in einem Regelmodul hinzugefügt werden sollte.
  • 18 veranschaulicht die Baumstruktur der Verarbeitung von Regelmodulen gemäß einer Ausführungsform der Erfindung. Wenn ein Ereignis empfangen wird, entfaltet die Regelbasisverarbeitung ein Verarbeitungsmuster, welches als der Regelbasisbaum bezeichnet wird. Wenn eine Anfrage in dem SIP-Server entsprechend einem ursprünglichen Ereigniskontext 1801 ankommt, können die zugehörigen Teilnehmer die veranlassende Seite (d.h. Anrufer) und/oder die abschließende Seite (d.h. Angerufener) sein. Der Anrufer wird durch das From-Headerfeld identifiziert. Der Angerufene (oder gegenwärtige Angerufene) wird durch den Request-URI identifiziert. Das From-Headerfeld und der Request-URI sollten einen Teilnehmer in dem SIP-Server eindeutig identifizieren, wo diese Teilnehmer eine vertragliche Beziehung mit dem Netzbetreiber und Dienstanbietern haben. Dem kaskadierenden Prinzip folgend werden die veranlassenden Dienste 1802 vor abschließenden Dienste 1803 aufgerufen, selbst wenn sich die veranlassenden und abschließenden Seiten in dem gleichen Host befinden. Es kann auch eine dritte Kategorie von Diensten aufgerufen werden. Diese werden die Dienste weitergeleitet-durch (forwarded-by) genannt (nicht gezeigt). Diese Kategorie von Diensten wird aufgerufen, falls eine Anfrage zu einem neuen Ziel weitergeleitet wird, das zu einem anderen Teilnehmer gehört. In diesem Fall kann es sein, dass veranlassende Dienste im Namen des Anrufenden aufgerufen werden müssen. Für jede Seite werden die Dienste basierend auf dem Standort der Regelmodule aufgerufen, wie sie in den unterschiedlichen Verarbeitungspunkten 1804–1809 platziert sind. Für jeden Verarbeitungspunkt werden die Mengen von Regelmodulprioritäten 1810–1814 auf eine Übereinstimmung untersucht. Innerhalb jeder Priorität wird höchstens jeweils ein Regelmodul 1815–1817 aufgerufen. Ein Regelmodul 1817 kann jedoch die Wurzel einer Regelmodulhierarchie 1818 sein, wie in Verbindung mit 12 beschrieben. Zur Einfachheit kann eine derartige Regelmodulhierarchie als ein einzelnes Regelmodul betrachtet werden. Daher können die Funktion der Regelmodulverarbeitung 1601, die Funktionen 1700 des Dienstinteraktionsmoduls und die Dienstanwendungen 1819, die durch die Regelmodule aufgerufen werden, als ein Blatt in dem Regelbasisbaum betrachtet werden. Basierend auf dem aktuellen Ereigniskontext CEC wird das Regelmodul 1817 aufgerufen und es gibt einen resultierenden Ereigniskontext REC zurück. Dieser resultierende Ereigniskontext REC wird als der aktuelle Ereigniskontext CEC für das nächste Regelmodul betrachtet, das aufgerufen wird. Wenn alle Regelmodule aufgerufen wurden und das letzte von ihnen den resultierenden Ereigniskontext zurückgegeben hat, dann ist der resultierende Ereigniskontext die Menge von SIP-Signalisierungsnachrichten, die stromaufwärts und/oder stromabwärts als Antwort auf die ursprüngliche eingehende SIP-Nachricht gesendet wird.
  • Die obige Verarbeitungsstruktur, die in 18 grafisch veranschaulicht wird, kann ferner durch das folgende Beispiel eines Pseudocodefragmentes veranschaulicht werden:
    Figure 00900001
    Figure 00910001
    Figure 00920001
  • Es wird vermerkt, dass eine Dienstanwendung das From-Headerfeld oder den Request-URI ändern kann. Des weiteren können das resultierende From-Headerfeld oder der resultierende Request-URI zu einem anderen Teilnehmer gehören, der sogar dem SIP-Server, der das Ereignis verarbeitet, unbekannt sein kann. Falls der resultierende From und/oder der Request-URI ein neuer, aber bekannter Teilnehmer in dem SIP-Server ist, werden die Dienste, die mit diesem Teilnehmer in Verbindung stehen, ebenso aufgerufen. In diesem Fall kann die Regelbasisverarbeitungsprozedur rekursiv aufgerufen werden, was zu einer hierarchischen Struktur von Regelbasisbäumen führt.
  • Verarbeiten eines Regelmoduls umfasst den Schritt zum Ausführen jeder Aktion wiederum in Prioritätsreihenfolge, wobei evaluiert wird, ob die einschließenden Muster mit dem aktuellen Ereigniskontext übereinstimmen, und falls ja, Anwenden der Aktion. Im Folgenden wird ein Verfahren gemäß einer Ausführungsform der Erfindung detaillierter beschrieben.
  • Das folgende Pseudocodefragment sieht eine Beschreibung hoher Ebene eines Algorithmus zum Verarbeiten eines Regelmoduls vor:
    Figure 00930001
    Figure 00940001
  • Hier gibt die Methode enclosingPatternsTrue einen booleschen Wert zurück, der anzeigt, ob die Muster, die die Aktionen einschließen, wahr sind. Die Methode processAction kann wie in dem folgenden Pseudocodefragment angezeigt implementiert sein:
    Figure 00940002
    wobei EC[] die Menge von Weiterleitungen des Ereigniskontextes ist. Falls sie leer ist, hat der Dienst die Anfrage oder Antwort abgeschlossen.
  • Die Dienstanwendung kann ferner Instruktionen erteilen, die nicht Instruktionen sind, um den Ereigniskontext weiterzuleiten. Diese werden in dem obigen Algorithmus nicht gezeigt. Derartige Instruktionen können durch den Regelbasismanager verarbeitet werden.
  • Wenn Aktionen in Prioritätsreihenfolge ausgeführt werden, kann das Ergebnis der Aktion sein, den aktuellen Ereigniskontext zu ändern. Nach einer derartigen Aktion setzt sich die Verarbeitung des aktuellen Regelmoduls fort. Nach Ausführen des aktuellen Regelmoduls können weitere Regelmodule gemäß der Regelbasisverarbeitungsprozedur ausgeführt werden. Die Aktionen unterer Prioritätsreihenfolge werden nur ausgeführt, falls das (die) Muster, das (die) sie einschließ(t)(en), mit den neuen Nachrichteneigenschaften übereinstimm(t)(en), wie durch den aktuellen Ereigniskontext spezifiziert. Dies wird durch das folgende Beispiel eines Fragmentes eines Pseudoskriptes veranschaulicht, welches zwei Aktionen beschreibt, die durch zwei Muster eingeschlossen sind:
    Figure 00950001
  • Die zwei Aktionen werden durch zwei Muster eingeschlossen, die anzeigen, dass die Aktionen nur angewendet werden sollten, falls die Anfrage ein EINLADEN ist und der RequestURI den Domänennamen xcorp.com enthält. Die erste Aktion ruft ein vom Benutzer bereitgestelltes CPL-Skript auf. Falls das Benutzer-CPL-Skript das Ziel der Anfrage nicht ändert, wird das Standard-Proxy-Verhalten aufgerufen, um den Benutzer zu lokalisieren und die Anfrage stellvertretend zu behandeln. Falls das CPL-Skript das Ziel ändert, sodass das Ziel zu einem anderen Host auflösen wird, muss das Standard-Proxy-Verhalten nicht aufgerufen werden.
  • Falls sich die Nachrichteneigenschaft, die das Regelmodul getriggert hat, ändert, sodass sie einen neuen Benutzer darstellt, wird die Verarbeitung dieses Regelmoduls gestoppt. Der Zweck davon ist, dass von Regelmodulen gedacht werden kann, im Namen eines einzelnen Benutzers verarbeitet zu werden. Dies vereinfacht die Regelmodulverarbeitung und Skriptentwicklung.
  • 19 veranschaulicht die rekursive Verarbeitung von Regelmodulen in einer Situation, wo Dienstanwendungen neue Ereig niskontexte generieren, gemäß einer Ausführungsform der Erfindung. Die neuen Ereigniskontexte können den ursprünglichen Regelmodultrigger ändern, und in diesem Fall können neue Regelmodule rekursiv aufgerufen werden. Z.B. können Präferenzen für Angerufene eines Teilnehmers, z.B. ein CPL-Skript, die Anfrage zu einem neuen Ziel weiterleiten, das mit einem anderen Teilnehmer des gleichen SIP-Servers in Verbindung steht. In diesem Fall sollten ebenso Präferenzen für Angerufene des Teilnehmers, zu dem weitergeleitet wird, z.B. ein anderes CPL-Skript, aufgerufen werden.
  • Wie durch das Beispiel von 19 veranschaulicht, generiert ein Anfangsereigniskontext 1901 eine Rekursion von Regelmodulaufrufen, wenn eine SIP-Anfragenachricht zu mehreren neuen Zielen weitergeleitet wird, die mit anderen Teilnehmerkonten in Verbindung stehen. In dem Beispiel von 19 wird die Anwendung 1914 durch das Regelmodul 1903 im Namen eines Teilnehmers A getriggert. Das Regelmodul 1903 wird durch den ursprünglichen Ereigniskontext 1901 getriggert. Die Anwendung 1914 generiert drei Ereigniskontexte 1904–1906, wo sich der Regelmodultrigger in den zwei Ereigniskontexten 1905–1906 geändert hat, die mit neuen Teilnehmerkonten in Verbindung stehen. Der Ereigniskontext 1904 ist ein aktualisierter Ereigniskontext, steht aber mit dem gleichen Teilnehmer in Verbindung, dessen Regelmodul anfangs Anwendung 1914 aufgerufen hat. In diesem Fall werden auch die Teilnehmerregelmodule 1907–1908, die jeweils mit den neuen Ereigniskontexten 1905–1906 in Verbindung stehen, aufgerufen. Regelmodul 1907 ruft wiederum Anwendung 1915 auf, die zwei neue Ereigniskontexte 1909 und 1910 generiert usw. Folglich wird eine Baumverarbeitungsstruktur erstellt, in der die Blätter der Menge von resultierenden Ereigniskontexten 1910–1913 entsprechen. Anschließend veranlassen die resultierenden Ereigniskontexte 1910–1913 den SIP-Server, SIP-Nachrichten stromaufwärts oder stromabwärts oder beides zu senden. Es wird vermerkt, dass das Beispiel von 19 einen einfachen Fall zeigt, der annimmt, dass die Regelmodule jedes nur eine Aktion enthalten.
  • Falls die fünf Anwendungen 1914–1918 in 19 angefragt haben, über nachfolgende Antworten auf die resultierenden SIP-Nachrichten benachrichtigt zu werden, gemäß dem kaskadierenden Prinzip, werden Antworten der logisch stromabwärtigsten Anwendung zuerst bekannt gegeben. In 19 werden Antworten zu dem resultierenden Ereigniskontext 1910 zuerst Anwendung 1918, dann Anwendung 1915 und schließlich Anwendung 1914 bekannt gegeben, wie durch die Linie 1919 angezeigt. Für den resultierenden Ereigniskontext 1911 ist die entsprechende Sequenz Anwendung 1915 und Anwendung 1914, wie durch Linie 1920 angezeigt. Für den resultierenden Ereigniskontext 1912 ist die Sequenz Anwendung 1916 und dann Anwendung 1914, wie durch Linie 1921 angezeigt. Schließlich ist für den resultierenden Ereigniskontext 1913 die Sequenz Anwendung 1917 und dann Anwendung 1914.
  • 20 veranschaulicht einen Mechanismus zum Durchsetzen von Zugriffssteuerung in Verbindung mit Regelmodulen gemäß einer Ausführungsform der Erfindung. Es werden zwei Typen von Zugriffssteuerung durchgesetzt. Zugriff zu Regelmodulen sollten nur authentifizierten und autorisierten Seiten gewährt werden, und Zugriff zu Dienstmerkmalen sollte nur authentifizierten und autorisierten Regelmodulen gewährt werden. Gemäß einer Ausführungsform kann diese Zugriffssteuerung durch Verwenden so genannter Zugriffssteuerlisten (access control lists, ACL) implementiert werden. Eine derartige Liste kann ein XML-Dokument sein, möglicherweise in das Regelmodul eingebettet oder in dem gleichen Verzeichnis befindlich wie das, oder anderweitig verbunden mit dem Regelmodul. Zugriffssteuerlisten inkludieren Zugriffssteuerregeln. Die Zugriffssteuerliste kann jede der Individuen oder Gruppen aufzählen, denen Zugriff auf das Regelmodul gewährt wird. Der Mechanismus kann auch verwendet werden, Privilegien und Rechte der Regelmodule explizit zu spezifizieren, z.B. welche Dienstmerkmale das Regelmodul verwenden kann. Deshalb erlaubt er dem Administrator, Privilegien und Rechte von Regelmodulen zu managen.
  • Des weiteren kann der Mechanismus verwendet werden, um Privilegien und Rechte von Dienstanwendungen zu managen. Falls ein Teilnehmer ein CPL-Skript hochlädt, kann es ein zugehöriges Regelmodul geben, das diesen Dienst in dem richtigen Zeitpunkt auf ruft. In diesem Fall sollte das Regelmodul explizite Privilegien und Rechte haben dies zu tun. Dies kann durch Verbinden von Zugriffssteuerlisten mit dem CPL-Skript gemanagt werden. Der Mechanismus kann ferner verwendet werden, um Privilegien und Rechte der Dienstanwendung explizit zu spezifizieren, z.B. welche Dienstmerkmale, APIs etc. die Dienstanwendung verwenden kann. Deshalb erlaubt er dem Administrator, Privilegien und Rechte von Dienstanwendungen zu managen.
  • Bezug nehmend auf die nummerierten Kreise in 20 können die folgenden Privilegien geprüft werden:
    • 1) Es wird ein ursprünglicher Ereigniskontext 2001 zu dem Regelmodul nach richtiger Authentifizierung von Teilnehmern gesendet (A ist der Anrufer, B der Aufgerufene). Regelmodule und Dienstanwendungen sind alle authentifiziert, und ihnen wurden Privilegien und Rechte gegeben.
    • 2) Der Regelbasisprozessor 2002 versucht, auf Regelmodule in der Regelbasis 2003 zuzugreifen, die mit einem authentifizierten Teilnehmer A oder B oder beiden in Verbindung stehen. Dem Regelbasisprozessor 2002 sollte nicht erlaubt werden, auf Regelmodule zuzugreifen, die mit anderen Teilnehmern in Verbindung stehen, wenn dieses Ereignis verarbeitet wird. Die Regelbasis 2003 kann sich auf einem ent fernten Server befinden, in welchem Fall sich der Regelantrieb selbst authentifizieren sollte.
    • 3) Falls gemäß der Zugriffssteuerliste 2005 erlaubt, kann der Regelbasisprozessor 2002 das geladene Regelmodul 2004 aufrufen, sagen wir Regelmodul 1, das sich im Besitz von A befindet.
    • 4) Falls gemäß der Zugriffssteuerliste 2006 erlaubt, kann Regelmodul 2004 versuchen, ein anderes Regelmodul 2007 aufzurufen, das mit einem anderen Besitzer B in Verbindung steht.
    • 5) Falls gemäß der Zugriffssteuerliste 2008 erlaubt, kann der Regelbasisprozessor 2002 das geladene Regelmodul 2007 aufrufen.
    • 6) Falls gemäß den Zugriffssteuerlisten 2005 und 2012 erlaubt, kann Regelmodul 2004 versuchen, Dienstanwendung 2010 aufzurufen, falls erlaubt. Die Dienstanwendung 2010 kann gemäß Zugriffssteuerliste 2011 auf den Ereigniskontext 2013 zugreifen.
    • 7) Die Dienstanwendung 2010 kann eine Menge von Instruktionen 2014 zurückgeben, die zu dem Regelmodulprozessor zurück vermittelt wird, falls gemäß Zugriffssteuerliste 2015 erlaubt.
    • 8) Die Dienstanwendung 2010 kann für Ereignisse scharfmachen/entschärfen, falls gemäß Zugriffssteuerliste 2015 erlaubt.
    • 9) Die Dienstanwendung 2010 kann versuchen, einem anderen Regelmodul 2007 als dem einen, den sie aufgerufen hat, Instruktionen zu geben, falls gemäß Zugriffssteuerliste 2012 erlaubt.
  • Zugriffssteuerung auf Regelmodule kann durch die Richtlinienknoten in einem Regelmodul durchgesetzt werden. Ein Beispiel einer Regelmodul-Zugriffssteuerliste, die in einem Regelmodul eingebettet ist, kann wie folgt aussehen:
    Figure 00990001
    Figure 01000001
  • Diese Richtlinie (policy) könnte auf das gesamte Regelmodul angewendet werden, in welchem Fall sie festlegt, dass der Teilnehmer Alice dieses Regelmodul aufrufen kann, sie es aber nicht lesen oder schreiben darf.
  • Derartige Richtlinien-XML-Skripte können innerhalb von Regelmodulen eingebettet sein, sie können aber auch mit Datenelementen in Verbindung stehen. Z.B. kann der Netzbetreiber ein Richtlinien-XML-Skript mit dem Regelmodul eines Teilnehmers verknüpfen, das die Privilegien spezifiziert, die dem Besitzer des Regelmoduls durch den Netzbetreiber gewährt werden. Diese Privilegien könnten die Dienste oder Dienstmerkmale spezifizieren, welche dem Regelmodul erlaubt werden aufzurufen, wie durch das folgende Beispiel einer derartigen Dienstzugriffssteuerliste veranschaulicht wird:
    Figure 01000002
    Figure 01010001
  • Es wird vermerkt, dass eine SIP-Server-Dienstunterstützungsumgebung ferner angepasst sein kann, Abrechnungsdatensätze zu generieren, z.B. für Inhaltsabrechnung, Anwendungsabrechnung, Benutzungsabrechnung oder dergleichen. Z.B. können die Datensätze über Protokolle von SERL-Skripten oder CPL-Skripten bereitgestellt, über Bibliotheksfunktionen oder Dienstanwendungen gemanagt werden etc.
  • Des weiteren implementiert ein System, das Diensttriggerung gemäß der Erfindung implementiert, vorzugsweise Sicherheitsmaßnahmen, um Sicherheit und Integrität des SIP-Knotens zu bewahren, obwohl Teilnehmern und Dienstanbietern einer dritten Seite erlaubt sein kann, nicht nur Dienstanwendungen hochzuladen, sondern auch Instruktionen dazu, wie und wann sie aufzurufen sind, inkludierend irgendeinen Grad von Merkmalsinteraktionsauflösung. Mögliche Sicherheitsmaßnahmen in kludieren die Konfiguration von Privilegien und Rechten von Regelmodulen, Dienstanwendungen, Namensraumkonventionsrichtlinien, Authentifizierungsmechanismen, Autorisierungsmechanismen, Zugriffsschutz, Authentifizierung und Validierung von hochgeladenen Regelmodulen, Protokollierung und Überwachung etc.
  • Es wird vermerkt, dass die Erfindung hauptsächlich in Verbindung mit Netzdiensten beschrieben wurde. Sie ist jedoch auch anwendbar, in einer Endbenutzerausrüstung verwendet zu werden.
  • Des weiteren wird vermerkt, dass die Erfindung, obwohl hauptsächlich in Verbindung mit SIP beschrieben, ebenso andere Signalisierungsprotokolle annehmen kann. SERL ist nicht darauf begrenzt, Dienste basierend auf SIP-Ereignissen aufzurufen, sondern kann einen beliebigen Typ einer Dienstanwendung basierend auf einem beliebigen Typ eines Ereignisses in dem Kontext eines beliebigen Typs eines Geschäftsmodells aufrufen. Die Erfindung kann angewendet werden, Dienste für einen beliebigen SIP-freigegebenen Knoten zu managen. Unter Verwendung von SERL-Skripten können Dienste von Knoten aufgerufen werden, die Benutzeragenten, Archivare, Umlenkungsserver oder Proxyserver implementieren.
  • Schließlich wird vermerkt, dass in der 3GPP-Architektur alle Teilnehmerdaten in dem so genannten Heimatteilnehmerserver (Home Subscriber Server, HSS) administrieren werden. Auf SIP-bezogene Anwendungen werden von einem Knoten aufgerufen, der eine bedienende Rufzustandssteuerfunktion (Serving Call State Control Function, S-CSCF) genannt wird. Wenn sich ein Teilnehmer mit einem Netz verbindet, führt seine Benutzerausrüstung (User Equipment, UE) eine CSCF-Ermittlung durch, um eine geeignete S-CSCF auszuwählen. Die S-CSCF registriert bei dem HSS, den sie bedient, den in Frage kommenden Teilnehmer.
  • Diensttrigger könnten dann von dem HSS zu der S-CSCF in der Form von Dienstausführungsregeln in dem SERL-Format transportiert werden. Der HSS könnte auch die Dienstausführungsregeln verwenden, die mit einem Teilnehmer in Verbindung stehen, um zu entscheiden, eine andere S-CSCF zuzuordnen, basierend darauf, welche S-CSCF die richtigen Dienste installiert hat. Daher kann eine Ausführungsform der Erfindung verwendet werden, damit der HSS die teilnehmerbasierten Trigger in dem richtigen Verarbeitungspunkt und Priorität und somit in der richtigen Prioritätsreihenfolge mit permanenten Diensten, die in der S-CSCF installiert sind, platziert. Daher kann ein Mechanismus gemäß der Erfindung in der 3GPP-IPMM-Domäne eingebettet sein.

Claims (27)

  1. Verfahren zum Managen einer Vielzahl von Diensten (309, 310, 311; 1305; 1611, 1612, 1613), getriggert durch eine Nachricht (1306; 1609) von einem Sitzungsprotokoll, das eine Kommunikationssitzung steuert, wobei das Verfahren die Schritte umfasst – Erhalten einer Zahl von Regelmodulen, von denen jedes eine Zahl von Ausführungsregeln (308; 401, 402; 1606, 1607, 1608) umfasst, wobei jede Ausführungsregel eine Bedingung (403, 404, 405) zum Aufrufen eines Dienstes spezifiziert; – Verarbeiten eines ersten (1216) der Zahl von Regelmodulen, die Verarbeitung umfassend Verarbeitung mindestens eines Teils der Ausführungsregeln des ersten Regelmoduls in einer vorbestimmten Reihenfolge, einer ersten Ausführungsregel (1606), die bewirkt, dass ein erster Dienst (1611) aufzurufen ist, falls die Nachricht eine erste Bedingung erfüllt, was zu einer ersten modifizierten Nachricht (1615) führt; und einer zweiten Ausführungsregel (1607), die bewirkt, dass ein zweiter Dienst (1612) mit der ersten modifizierten Nachricht als eine Eingabe aufzurufen ist, falls die erste modifizierte Nachricht eine zweite Bedingung erfüllt; wobei die Verarbeitung des ersten Regelmoduls zu einer ersten akkumulativ modifizierten Nachricht (1206) führt; – Aufrufen einer Verarbeitung eines zweiten (1217) der Zahl von Regelmodulen, was die erste akkumulativ modifizierte Nachricht als eine Eingabe vorsieht; gekennzeichnet dadurch, dass das erste Regelmodul zu sich ein Privileg zugewiesen hat, das eine Autorität anzeigt, ein Sperrflag zu ändern, das sich auf einen vorbestimmten Teil der akkumulativ modifizierten Nachricht bezieht, wobei das Sperrflag spezifiziert, ob der vorbestimmte Teil der akkumulativ modifizierten Nachricht durch Dienste modifiziert werden kann, die von mindestens dem zweiten Regelmodul aufgerufen werden.
  2. Verfahren nach Anspruch 1, gekennzeichnet dadurch, dass jedes Regelmodul mit sich eine Priorität verbunden hat, die eine Reihenfolge einer Verarbeitung der Zahl von Regelmodulen anzeigt.
  3. Verfahren nach Anspruch 1 oder 2, gekennzeichnet dadurch, dass jedes Regelmodul einem Regelmodulbesitzer (409) entspricht, der autorisiert ist, das Regelmodul zu editieren.
  4. Verfahren nach einem beliebigen von Ansprüchen 1 bis 3, gekennzeichnet dadurch, dass der Schritt zum Aufrufen einer Verarbeitung des zweiten Regelmoduls ferner den Schritt zum Setzen des Sperrflags umfasst, um eine Modifikation des vorbestimmten Teils der akkumulativ modifizierten Nachricht durch Dienste zu verhindern, die von dem zweiten Regelmodul aufgerufen werden, es sei denn, das Sperrflag wurde durch das erste Regelmodul als nicht gesetzt markiert.
  5. Verfahren nach einem beliebigen von Ansprüchen 1 bis 4, gekennzeichnet dadurch, dass der Schritt zum Erhalten ei ner Zahl von Ausführungsregeln ferner den Schritt zum Erfassen einer vorbestimmten vertraglichen Beziehung basierend auf Headerinformation der Nachricht; und Auswählen einer Zahl von Regelmodulen basierend auf der erfassten vertraglichen Beziehung umfasst.
  6. Verfahren nach einem beliebigen von Ansprüchen 1 bis 5, gekennzeichnet dadurch, dass der Schritt zum Verarbeitung des ersten Regelmoduls (1216) ferner den Schritt zum Aufrufen eines vorbestimmten dritten Regelmoduls (1220) umfasst.
  7. Verfahren nach einem beliebigen der Ansprüche 1 bis 6, gekennzeichnet dadurch, dass die ersten und zweiten Regelmodule auf jeweilige erste und zweite Zugriffssteuerlisten (411) bezogen sind, die Zugriffsrechte auf das entsprechende erste oder zweite Regelmodul spezifizieren.
  8. Verfahren nach einem beliebigen der Ansprüche 1 bis 7, gekennzeichnet dadurch, dass die ersten und zweiten Regelmodule jeweilige erste und zweite Skripte in einer vorbestimmten Auszeichnungssprache umfassen.
  9. Verfahren nach einem beliebigen von Ansprüchen 1 bis 8, gekennzeichnet dadurch, dass die Nachricht eine erste und eine zweite Menge von Attributen umfasst; die Ausführungsregeln in mindestens eine erste und eine zweite Verarbeitungsklasse (903, 904) von Ausführungsregeln gemäß entsprechenden Beschränkungen gruppiert sind, wobei die zweite Verarbeitungsklasse eingeschränkt ist, nur Attribute der zweiten Menge von Attributen zu modifizieren; und das Verfahren ferner den Schritt zum Wiederholen der Schritte einer Verarbeitung des ersten Regelmoduls (901) und Aufrufen einer Verarbeitung des zweiten Regelmoduls (902) umfasst, wobei in jeder Wiederholung die Verarbei tung der ersten und zweiten Regelmodule auf Ausführungsregeln einer entsprechenden Verarbeitungsklasse begrenzt ist, und wobei jede Wiederholung zu einer entsprechenden akkumulativ modifizierten Nachricht führt, die als eine Eingabe für eine nachfolgende Wiederholung verwendet wird.
  10. Verfahren nach Anspruch 9, gekennzeichnet dadurch, dass die Verarbeitungsklassen getrennt für Ausführungsregeln definiert sind, die durch Anfragen (607) und Antworten (608) des Sitzungsprotokolls getriggert werden.
  11. Verfahren nach Anspruch 9 oder 10, gekennzeichnet dadurch, dass die ersten Menge von Attributen Signalisierungseigenschaften der Nachricht umfasst.
  12. Verfahren nach einem beliebigen der Ansprüche 9 bis 11, gekennzeichnet dadurch, dass die Verarbeitungsklassen vorbestimmten Standorten in einem Rundlaufnachrichtenfluss gemäß dem Sitzungsprotokoll entsprechen.
  13. Verfahren nach einem beliebigen der Ansprüche 9 bis 12, gekennzeichnet dadurch, dass die Verarbeitungsklassen eine erste Verarbeitungsklasse (P1) von Ausführungsregeln, die Signalisierungseigenschaften (702) der Nachricht beeinflussen, eine zweite Verarbeitungsklasse von Ausführungsregeln (P2), die einen Nicht-Signalisierungsnachrichtenrumpfinhalt (704) der Nachricht beeinflussen, und eine dritte Verarbeitungsklasse (P3) von Ausführungsregeln, die weder die Signalisierungseigenschaften noch den Nicht-Signalisierungsnachrichtenrumpfinhalt der Nachricht beeinflussen, inkludieren.
  14. Verfahren nach Anspruch 13, gekennzeichnet dadurch, dass eine resultierende modifizierte Nachricht (703) generiert wird, wenn alle Ausführungsregeln der ersten und zweiten Verarbeitungsklassen verarbeitet sind.
  15. Verfahren nach einem beliebigen der Ansprüche 1 bis 14, gekennzeichnet dadurch, dass Aufrufen des ersten Dienstes ferner zu einer zweiten modifizierten Nachricht führt; und das Verfahren ferner die Schritte zum Verarbeiten nachfolgender Ausführungsregeln mit der ersten modifizierten Nachricht als eine Eingabe; und Verarbeiten nachfolgender Ausführungsregeln mit der zweiten modifizierten Nachricht als eine Eingabe umfasst.
  16. Verfahren nach einem beliebigen der Ansprüche 1 bis 15, gekennzeichnet dadurch, dass das Verfahren ferner die Schritte umfasst Speichern von Information darüber, welche Dienste ausgeführt werden, und Information darüber, in welcher Reihenfolge die Dienste ausgeführt werden; Empfangen von dem ersten Dienst einer Anfrage zum Rückgeben einer Benachrichtigung zu dem ersten Dienst, falls ein vorbestimmtes Ereignis eintritt; Speichern der Anfrage in Bezug auf die gespeicherte Information; und bei Eintreten des Ereignisses Benachrichtigen des ersten Dienstes gemäß der gespeicherten Information.
  17. Verfahren nach einem beliebigen der Ansprüche 1 bis 16, gekennzeichnet dadurch, dass die Ausführungsmodule computerlesbare Skripte umfassen, und die vorbestimmte Reihenfolge einer Verarbeitung der Ausführungsregeln durch die Reihenfolge von Ausführungsregeln in den Skripten bestimmt wird.
  18. Verfahren nach einem beliebigen der Ansprüche 1 bis 17, gekennzeichnet dadurch, dass sich die Sitzung auf eine Zahl von Teilnehmern bezieht, inkludierend einen Anrufer und einen Angerufenen; ein Dienst angepasst ist, durch eine Anfrage von einem Teilnehmer getriggert zu werden; und das Verfahren ferner den Schritt zum Aufrufen von Diensten umfasst, die durch den Anrufer angefordert werden, vor Aufrufen eines beliebigen Dienstes, der durch den Angerufenen angefordert wird.
  19. Verfahren nach einem beliebigen der Ansprüche 1 bis 18, gekennzeichnet dadurch, dass das Sitzungsprotokoll ein Sitzungsinitiierungsprotokoll ist.
  20. Verfahren nach einem beliebigen der Ansprüche 1 bis 19, gekennzeichnet dadurch, dass die Kommunikationssitzung eine Multimediasitzung ist.
  21. Verfahren nach einem beliebigen der Ansprüche 1 bis 20, gekennzeichnet dadurch, dass die Ausführungsregeln angepasst sind, dynamisch aktualisiert zu werden.
  22. Datenverarbeitungssystem, umfassend ein Dienstausführungsumgebungsmodul (201; 301), angepasst, eine Vielzahl von Diensten (309, 310, 311) aufzurufen, die durch eine Nachricht eines Sitzungsprotokolls getriggert werden, das eine Kommunikationssitzung steuert; wobei das Datenverarbeitungssystem ferner ein Speichermedium (307) umfasst, das angepasst ist, eine Vielzahl von Regelmodulen zu speichern, von denen jedes eine Zahl von Ausführungsregeln umfasst, wobei jede Ausführungsregel eine Bedingung zum Aufrufen eines Dienstes spezifiziert; und das Dienstausführungsumgebungsmodul ein Regelantriebsmodul (303) umfasst, das angepasst ist – eine Zahl von Regelmodulen abzufragen; – ein erstes der Zahl von Regelmodulen zu verarbeiten, die Verarbeitung umfassend Verarbeitung mindestens eines Teils der Ausführungsregeln des ersten Regelmoduls in einer vorbestimmten Reihenfolge, einer ersten Ausführungsregel, die bewirkt, dass ein erster Dienst aufzurufen ist, falls die Nachricht eine erste Bedingung erfüllt, was zu einer ersten modifizierten Nachricht führt; und einer zweiten Ausführungsregel, die bewirkt, dass ein zweiter Dienst mit der ersten modifizierten Nachricht als eine Eingabe aufzurufen ist, falls die erste modifizierte Nachricht eine zweite Bedingung erfüllt; wobei die Verarbeitung des ersten Regelmoduls zu einer ersten akkumulativ modifizierten Nachricht führt; und – eine Verarbeitung eines zweiten (1217) der Zahl von Regelmodulen aufzurufen, die die erste akkumulativ modifizierte Nachricht als eine Eingabe vorsieht; gekennzeichnet dadurch, dass das erste Regelmodul zu sich ein Privileg zugewiesen hat, das eine Autorität anzeigt, ein Sperrflag zu ändern, das sich auf einen vorbestimmten Teil der akkumulativ modifizierten Nachricht bezieht, wobei das Sperrflag spezifiziert, ob der vorbestimmte Teil der akkumulativ modifizierten Nachricht durch Dienste modifiziert werden kann, die von mindestens dem zweiten Regelmodul aufgerufen werden.
  23. Datenverarbeitungssystem nach Anspruch 22, gekennzeichnet dadurch, dass das Regelantriebsmodul angepasst ist, eine vorbestimmte Regelausführungsspezifikationssprache zu interpretieren.
  24. Datenverarbeitungssystem nach Anspruch 22 oder 23, gekennzeichnet dadurch, dass das Regelantriebsmodul ferner ein Regelbasisprozessormodul (1601), angepasst, die Ausführungsregeln abzufragen; und ein Regelmodulverarbeitungsmodul (314; 1604, 1605), angepasst, die Ausführungsregeln zu verarbeiten, umfasst.
  25. Softwareprogramm, umfassend Codemittel, angepasst, wenn in einem Datenverarbeitungssystem ausgeführt, die Schritte des Verfahrens von einem beliebigen der Ansprüche 1 bis 21 durchzuführen.
  26. Softwareprogramm nach Anspruch 25, gekennzeichnet dadurch, dass das Softwareprogramm auf einem computerlesbaren Medium verkörpert ist.
  27. Datensatz, umfassend ein Regelmodul zur Verwendung in einem Verfahren von einem beliebigen der Ansprüche 1 bis 21.
DE60108725T 2001-05-07 2001-11-22 Architektur zum Auslösen der Dienste Expired - Lifetime DE60108725T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DKPA200100707 2001-05-07
DK200100707 2001-07-05

Publications (2)

Publication Number Publication Date
DE60108725D1 DE60108725D1 (de) 2005-03-10
DE60108725T2 true DE60108725T2 (de) 2006-04-13

Family

ID=8160475

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60108725T Expired - Lifetime DE60108725T2 (de) 2001-05-07 2001-11-22 Architektur zum Auslösen der Dienste

Country Status (4)

Country Link
EP (1) EP1257129B1 (de)
AT (1) ATE288658T1 (de)
DE (1) DE60108725T2 (de)
ES (1) ES2233590T3 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20012406A (fi) 2001-12-05 2003-06-06 Comptel Corp Menetelmä ja järjestely transaktion prosessoimiseksi mobiilissa telekommunikaatiossa
DE102004030290A1 (de) * 2004-06-23 2006-01-19 Siemens Ag Aufbau einer Verbindung für den Austausch von Daten eines IP-basierten Dienstes
JP4830503B2 (ja) * 2006-01-18 2011-12-07 株式会社日立製作所 個人情報を保護した通信セッション確立仲介システムおよび方法
EP1860844A3 (de) * 2006-05-26 2007-12-05 Vodafone Group PLC Verfahren zur Umwandlung und Verwaltung von Nachrichten von einer SIP-Signalisierung in ein ereignisverwaltetes asynchrones System
WO2010001198A1 (en) * 2008-07-02 2010-01-07 Telefonaktiebolaget L M Ericsson (Publ) Service enablement/disablement based on service relationships
EP2517439B1 (de) * 2009-12-22 2017-03-08 Telefonaktiebolaget LM Ericsson (publ) Verfahren zur koordination der lieferung eines zusammengesetzten dienstes
CN110297675A (zh) * 2019-04-23 2019-10-01 五八有限公司 模块间相互调用的方法、装置、电子设备及存储介质
CN110083342B (zh) * 2019-04-26 2023-04-18 重庆紫光华山智安科技有限公司 一种程序生成方法、装置以及计算机可读存储介质

Also Published As

Publication number Publication date
EP1257129B1 (de) 2005-02-02
ES2233590T3 (es) 2005-06-16
EP1257129A1 (de) 2002-11-13
DE60108725D1 (de) 2005-03-10
ATE288658T1 (de) 2005-02-15

Similar Documents

Publication Publication Date Title
US20030187992A1 (en) Service triggering framework
DE69323675T2 (de) Partner-Mechanismus zum Verbinden von Systemen mit einer Umgebung für verteilte Berechnungen (UVB) und non-UVB Systemen zum Betrieb in einem Netzwerksystem
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
DE60102934T2 (de) Verfahren und system für sitzungsbasierte berechtigung und zugangskontrolle für vernetzte anwendungsobjekte
DE69818008T2 (de) Datenzugriffssteuerung
DE60013227T2 (de) Kommunikationsdienstenanbieten
DE69905705T2 (de) Intelligentes sicherheitsverwaltungsverfahren und -system
DE69929340T2 (de) Verfahren und system für eine intelligente, verteilte netzwerk-architektur
DE69910816T2 (de) Verfahren und gerät um echtzeit rufbearbeitungsdienste in einem intelligenten netzwerk zur verfügung zu stellen
DE60018446T2 (de) Architektur für dienstscriptenausführung und -verwaltung
DE69425318T2 (de) Verfahren und System für Fernausführung von Codes
DE69626127T2 (de) Diensterzeugungsvorrichtung für ein Kommunikationsnetz und entsprechendes Verfahren
DE60020518T2 (de) Verwaltung von Benutzerprofilen
DE69835158T2 (de) Zugriffpunkt zur dienstverwaltung
DE69430942T2 (de) Verfahren zur sicheren Kommunikation mit nicht vertrauenswürdigen Servern
DE102011016864A1 (de) Anwenduingsladen
DE112011102129T5 (de) Sicherheitsmodell für Abläufe, die sichere Fremddienste zusammenführen
DE10295699T5 (de) Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur
DE10311074A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
DE60035348T2 (de) Verlängerbarer Bereitstellungsmechanismus für einen Diensten-gateway
DE60108725T2 (de) Architektur zum Auslösen der Dienste
DE10238546A1 (de) Verfahren zur Bereitstellung von Ressourcen in Kommunikations-Netzwerken
DE10314597A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
EP1010052B1 (de) Verfahren zur steuerung der verteilung und nutzung von software-objekten bei vernetzten rechnern
DE60004216T2 (de) Verbindungskennung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition