DE60108725T2 - Architecture for triggering the services - Google Patents

Abstract

Disclosed is a method and a system for managing a plurality of services triggered by a message of a session protocol such as SIP controlling a communications session, the method comprising the steps of obtaining a number of execution rules each of which specifying a condition for invoking a service; and processing the execution rules in a predetermined order, a first execution rule causing a first service to be invoked, if the message fulfils a first condition, resulting in a first modified message; and a second execution rule causing a second service to be invoked with the first modified message as an input, if the first modified message fulfils a second condition specified by a second execution rule. <IMAGE>

Description

These This invention relates to the management of a variety of services which are related to a communication session, wherein the communication session is controlled by a session log, the session information about the Communication session provides.

It There is an increasing demand for interactive communication sessions over the Internet, such as IP telephony, multimedia sessions, video data stream (video streaming) etc. Interactive communication sessions can be through Session logs, such as the session initiation protocol (Session Initiation Protocol, SIP), which initiation, completion and modification of sessions between users. SIP is not concerned with the type of session that initiate is, i. with the actual content rather than managing a session. This includes tasks, such as determining where a user is indeed To be contacted, deliver a description the session to which the user is invited to negotiate one common formats for describing sessions etc.

SIP based on the request-response paradigm. If e.g. a meeting is initiated, a caller sends a request to the user addressed, which the caller wants to call, i. the called party. The request message is sent to the called party, typically via a Set of proxy servers used to forward and deliver Messages are responsible. The called party sends a response, who accepts or rejects the invitation. The answer is through the Sequence of proxy servers returned in the reverse order.

Above that Standard session management provided by a session protocol will, such as SIP, can additional Services in the location of the caller, location of the called party or be implemented in any of the intermediate proxy servers.

Here The term service (service) includes a unit of functionality that is one Basic system can be added incrementally and to one Issue leads, which is perceptible by a user, such as a subscriber, an administrator or the like. Therefore, a service, e.g. Call forwarding, voice mail, videoconferencing, etc. one modular extension to a base system, such as a system for managing sessions, e.g. a SIP system. The process of adding and Enable of features in a base system, feature set up (feature called deployment).

During one Can session Characteristics can be triggered (triggered) by certain events. triggers, i.e. the act of invoking a given application in one given event, is usually based on contractual relationships between subscribers and service providers. If more than one characteristic is placed in a service network, and one or more services simultaneously for one or more users can be activated then feature interactions occur. Here the term encompasses Feature interaction the influence or modification of a feature through another. Feature interaction is an inevitable byproduct of modular features. There may be desirable and undesirable feature interactions give. However, it is a problem that the entire behavior of a Service network can not be controlled if feature interactions not managed properly. Consequently, feature interaction a growing problem, as is the number and complexity of a Service application with the emergence of new technologies, such as UMTS, increased, the skills impose significant requirements on service networks. These services can independently have been developed and service providers must be able to specify how to resolve conflicting instructions from these services and to the default behavior of the communication protocol used to convey.

Around To avoid feature interaction, the behavior of multiple Characteristics are tested ad-hoc or systematically when a new one Added service to a service network is, e.g. by testing pairs of features. If there are cases of Feature interactions during Tests or after installation can be recorded, the detected problems e.g. by transforming one or more of the included service applications solved become.

Of the above approach requires a considerable Amount of resources, especially as the number and complexity of services elevated. Therefore, it is a problem that the above prior art with the Number and complexity not scaled well by service applications.

The article "Programming SIP Services" by Anders Kristensen et al, IP Telephony Workshop 2000, describes a JAVA-based interface between services and a SIP server.

Of the Article "An Architecture for Three Challenging Features "by Pamela Zave, Internet Telephony Workshop 2001, describes an architecture for three specific features within the context of IP telephony, namely "location and identification", "switching and spontaneous Conference "and" Post. "The design taken into account Problems of feature interaction. This article also refers to a distributed feature architecture (Distributed Feature Composition architecture, DFC) and describes a system in the sense of interface boxes and feature boxes, the concurrent Processes are.

It however, is a problem of the above prior art system, improved mechanisms to avoid feature interactions because of the change context of a service by another service.

According to the invention The above and other problems are solved by a method of managing a variety of services through a message of a session log which controls a communication session, as in Claim 1 defined solved.

consequently is the call to services during a communication session is triggered, controlled by a number of execution rules, the processed in a predetermined order, thereby the order of services to be called is controlled. Therefore is a mechanism for triggering applications based on the service execution rules provided that any overall behavior because of an uncontrolled Order of execution avoids. Furthermore, through Editing the execution rules different deployment strategies are easily implemented, where thereby a flexible fine granulated service installation infrastructure is provided, the big one flexibility when arranging the chain of services provides what allows that Optimize service performance of the service network.

Therefore is according to the invention provided a flexible service deployment infrastructure that it allows to systematically avoid feature interactions when a size Number of complex services, e.g. if services within added to a service network, removed, canceled, re-activated or reassigned.

It Provide a standardized framework for defining a service execution, the distribution of the service management problem between independent stakeholders permitting thereby to provide a method compatible with the Number of services is scalable.

A Run rule includes one or more conditions for performing one or more actions, such as calling a service application.

Of the Term communication session involves communication sessions between Users of a communication network, such as a TCP / IP network, a local area network, a wide area network, the Internet or similar. Include examples of communication sessions Voice over Internet (Voice over Internet), IP telephony, videoconferencing, video data stream etc.

Of the Term session log includes a log containing the communication session controls, and in particular the initiation, the conclusion and the Modification of sessions. Preferably, the session log is based on request / response messages over the nodes of the communication network between the participating users of a communication session become. An example of such a session log is the Session Initiation Protocol (SIP).

Other Examples include the H.323, MGCP, and related protocol series Protocols, such as IPDC, SGCP, H.248 etc.

Of the Term service includes a unit of functionality that is one Basic system can be added incrementally. A service may offer services to subscribers, but may also provide other services, how to offer administrative tasks to the network administrator. Examples such services include call forwarding, waiting for one Call, voice mail, statistics, callback, videoconferencing, video on demand, anonymization services, automatic answer etc. A service can be done using a variety of technologies be implemented, e.g. OSA, Java, CGI, Perl, C ++, CPL, XML etc.

In In the context of the SIP protocol, a service is an application or a number of applications running locally on a SIP server, e.g. when a CGI script or a CPL script, or removed on an application server, which is contacted by the SIP server to be executed. In the latter case, the service may be using any Standard naming convention accessible be made or called, i. using SIP request URIs (SIP Request-URI). Alternatively you can the services actually in the SIP server using e.g. register yourself on a 3GPP OSA API framework. SIP services can in inducing and final Services are grouped, i. those with the caller and the Called contact.

services can on conditions in a message header (message header), one Message body, the SDP or the like are triggered.

The functionality SIP server offered to service applications becomes service features called, such as access to any API, e.g. a server-side OSA API, statistical functions or the like. service features can be further service applications that register in the SIP server and subsequently offer their service to be used by other service applications to become.

It another advantage of the invention is that it is technologically the for the implementation of the services is used, the signaling protocol and the platform independently is. Therefore, a network operator needs to know in advance the types of services Do not know that are placed in the service network, thereby a robust and extensible service deployment infrastructure is provided becomes.

There the number of stakeholders who may want their own services to register, be very tall could, there is a need for Scalability. Furthermore, the number of participants who with a domain communicate, be very tall, which makes the question of scalability critical. Services can be through many different types of events triggered and based called on a variety of different conditions be like coincidence source and destination addresses, time-dependent or any other Precondition. Furthermore, you can invoke SIP-related services in SIP events, e.g. if certain conditions are met at a given time. It can different service technologies, such as CPL. SIP related services can in non-SIP related events, e.g. HTTP events. There can be tens of thousands of services, tens of millions of subscribers can be offered by tens of thousands of third party service providers. Consequently, the Task to manage services and service interactions a task to manage for an administrator gets too big and complicated.

• – 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.

According to the invention, the number of execution rules is grouped into a number of rule modules, each rule module including a number of execution rules; and the method further comprises the steps

• Processing a first of the number of rule modules, resulting in a first accumulatively modified message; and
• Calling a processing of a second of the number of rule modules, which provides the first accumulatively modified message as an input.

consequently The problem of feature interaction is by grouping the execution rules in rule modules, i. Groups of execution rules, in the problem of feature interaction between features that are within the same Control modules are called, and interactions between rule modules are split. Consequently, it is an advantage of the invention that a method for Managing feature interaction is provided, which with the Number of services scaled. When different services through different service providers are provided, e.g. different Companies or different organizational entities within a company, In particular, a single provider may not have access to all intended services or not be able to test them. Therefore, it is an advantage of the invention that the task of analyzing split by feature interaction analysis according to rule modules and can be distributed to different providers. This implies Furthermore, the cost of service management on independent sites can be delegated, as the number of participants and services grows.

The stakeholders who may want to upload / register and administer services to a SIP server could be the owner, service provider or administrator of the SIP server, network operator, etc. It could also be different types of retailers, such as virtual telecom operators, Internet service providers, etc. They may also be different types of service providers, such as application service providers, content service providers, service / feature providers. Also, private organizations be possible stakeholders, companies and participants.

consequently is according to the invention a flexible, extensible and scalable management of contract relationships reached between interest groups, including the management billing, settlement, policies and security.

It Another advantage of the invention is that it has a modular structure of execution rules whereby embedding service profiles for users, User groups, participants, etc. is enabled. It is another Advantage of modularity, that it allows reuse of control modules, thereby reducing maintenance the service environment is further facilitated.

If Each rule module has assigned to itself a priority, the one Display the order of processing of the number of rule modules, The order of a rule module execution is given by a simple parameter thereby providing easy and transparent control over the Order of execution is provided by rule modules.

If Each rule module corresponds to a rule module owner who authorizes is to edit the rule module, the administrative authority for a rule module be easily prepared, with the delegation administrative Authority, such as editing rule modules, feature interaction analysis is further facilitated within a control module, etc.

According to the invention the first rule module has assigned to itself a privilege that has a authority indicates to change a blocking flag, which is based on a predetermined part of the accumulatively modified Message refers and specifies whether the predetermined part of accumulatively modified message modified by services can be called by at least the second rule module. Consequently, a mechanism for explicitly allowing or preventing of changes individual attributes or groups of attributes of the messages provided by subsequent services. Therefore, an efficient Tool for preventing feature interactions because of changing the Context of a service provided by another service. This type of feature interaction is called a feature acceptance violation indicates the ambiguous or conflicting behavior of services can cause. As the authority, block and / or release certain attributes with predetermined ones Privileges linked is, the control modules are assigned, the network operator can abuse of privileges and thereby prevent unauthorized behavior, thereby increasing the safety of the process. privileges injury can be detected and resolved at runtime, e.g. by notification or deactivation of services.

According to one another preferred embodiment The invention comprises the step of invoking a processing the second control module further comprises the step of setting the inhibit flag, to a modification of the predetermined part of the accumulatively modified To prevent message through services provided by the second rule module be called unless the blocking flag is through the first Rule module has been marked as not set. Consequently, the message attributes are by default for subsequent changes Locked when controlling from one controller to another is transferred. Therefore, the second rule engine can only modify message attributes that the first rule module has explicitly marked as not locked, where thereby the control possible Feature interactions between rule modules is further improved and a feature analysis task within within each rule module limited becomes. this leads to to a further improved scalability.

If the step of obtaining a number of execution rules further comprises the step for detecting a predetermined contract relationship based on Header information of the message; and selecting a number of rule modules is included based on the recorded contract relationship provided a modular and scalable process that provides support to operators allows Services third and / custom services to maintain. There Contractual relationships based on header information recorded can, can those services third or custom services that are for a given Message are relevant, based on the recorded contractual relationships be identified.

According to another preferred embodiment of the invention, the step of processing the first control module further comprises the step of calling a predetermined third control module. As a result, a rule module can invoke other rule modules, providing a powerful tool for creating a hierarchy of rule modules, and further improving the scalability and flexibility of the deployment infrastructure. It is an advantage of the invention that it involves the delegation of a rule module owned by one page to another rule module owned by another page is allowed. A page can call applications in an order that is deemed appropriate by that page, and then pass the control to another page that can then invoke different applications. The first page may then regain control to check the output from the second page. When this delegation has occurred, the first page can decide which message properties in the forwarded message can change subsequent applications by indicating which message properties for an action can not be overridden.

It One advantage of the invention is that it provides a hierarchical delegation administrative authority based on the ability allows to trigger control modules from within other control modules and lock message properties.

If the first and second control modules relate to respective first and second second access control lists relate the access rights to the can specify corresponding first or second control module the violation of access rights are recorded and resolved, thereby further improving the safety of the process.

If the first and second rule modules have respective first and second scripts in a predetermined markup language, a simple language intended for writing rule modules. Therefore is it for An administrator can easily understand how to express rules and where the meaning of the rules is, thereby making a simpler Mechanism for extending the base definition of the rule language with proprietary Functions is provided. An example of such a language definition is XML.

It Another advantage of the invention is that it is an extensible one Framework, i. it is easy, protocols, service technologies and add message properties, e.g. if SIP is a new method added becomes.

It Another advantage of the invention is that it is a scalable one Framework, i. it's the same way to express Rules in big ISP networks and small end-user devices, e.g. 3G cell phones, possible.

According to one another preferred embodiment According to the invention, the message comprises a first and second set of attributes; the execution rules are in at least a first and a second processing class of execution rules according to appropriate restrictions grouped, with the second processing class being restricted, modify only attributes of the second set of attributes; and the step of processing the execution rules further comprises the step of processing the execution rules of the first processing class before processing any execution rule of the second processing class. Consequently, the services are in groups with predetermined behavior divided in terms of which parts of the signaling messages they update. Therefore, you can the services rely on that the first set of message attributes after the execution the first processing class is not changed. This one sees another mechanism for splitting up the task of feature interaction analysis in manageable subtasks. The following are the processing classes also referred to as processing points. The sets of attributes can Include message header information and a message body, the actual Session content includes. The attributes can also be different Types of header information may be split, e.g. signaling attributes Etc.

It Another advantage of the invention is that it has means for specifying Provides how applications will be allowed to interact.

Preferably the processing classes are in a predetermined order for inquiries and responses processed and applied to initiating, terminating and "forwarded by" services.

According to another preferred embodiment of the invention, the message comprises a first and a second set of attributes; the execution rules are grouped into at least a first and a second processing class of execution rules according to respective constraints, the second processing class being constrained to modify only attributes of the second set of attributes; and the method further comprises the step of repeating the steps of processing the first rule module and invoking processing of the second rule module, wherein in each repetition the processing of the first and second rule modules is limited to execution rules of a corresponding processing class, and wherein each repetition is a corresponding one accumulated modified message leads, which is used as an input for a subsequent repetition. Thus, a combination of subdivision into rule modules is provided with the concept of processing classes, thereby providing a finely granular framework for subdividing the services according to administrative ownership and restrictions imposed on the services.

If the processing classes are defined separately for execution rules, triggered by requests and responses of the session log will be the subdivision of services into processing classes furthermore according to the type split a message, whereby a fine granulated Splitting is provided.

According to one preferred embodiment the processing classes correspond to predetermined locations in a round trip message flow according to the session protocol, wherein this simplifies the analysis of feature interaction.

Preferably the processing classes include a first processing class of execution rules, affect the signaling properties of the message, a second processing class of execution rules containing a non-signaling message body content affect the message, and a third processing class of execution rules, neither the signaling properties nor the non-signaling message body content to influence the message. Here the term includes signaling properties SIP and SDP message properties that are in a rule module condition can be adjusted to call a service.

If a resulting modified message is generated if all execution rules the first and second processing classes are processed The efficiency of the process further increases since answers are returned can be without having to wait for services of the third processing class.

According to one another preferred embodiment the invention leads Calling the first service further to a second modified one Message; and the method further comprises the steps of processing the following execution rules with the first modified message as an input; and processing subsequent execution rules with the second modified message as an input. There a Service can return under different expenses, each of which is an input to a chain of subsequent services therefore implemented a tree of cascaded chains of services become.

• – 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.

According to yet another preferred embodiment of the invention, the method further comprises the steps of

• Storing information about which services are executed and information about the order in which the services are executed;
• Receiving from the first service a request to return a notification to the first service if a predetermined event occurs;
• Storing the request with respect to the stored information; and
• Upon the occurrence of the event, notifying the first service according to the stored information.

Therefore becomes an efficient mechanism for requesting notification of future events provided by a service application, thereby monitoring of applications Etc.

If the execution modules Computer readable scripts include and the predetermined order of a Processing of execution rules by the order of execution rules is determined in the scripts, a simple mechanism for Control the order of a service execution and the order of a Notification regarding future Events provided by an administrator of a rule module.

Preferably is the cascaded order of services by the order of execution rules within a rule module and the order of rule modules certainly.

If the execution rules are adapted to be dynamically updated, i. during a business the service network, a real-time service management is provided.

• – 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.

The invention further relates to a data processing system comprising a service implementation environment module, adapted to invoke a plurality of services triggered by a session log message that controls a communication session;
characterized in that
the data processing system further comprises a storage medium adapted to store a plurality of execution rules, each of which specifies a condition for invoking a service; and
the service execution environment module includes a rule engine module

• - to query a number of execution rules; and
• To process the execution rules in a predetermined order, wherein a first execution rule causes a first service to be invoked if the message satisfies a first condition, resulting in a first modified message; and a second execution rule that causes a second service to be invoked with the first modified message as an input if the first modified message satisfies a second condition.

• – 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.

The invention further relates, in a data processing system, to a service execution environment module, adapted to invoke a plurality of services triggered by a session log message that controls a communication session;
characterized in that
the service execution environment module includes a rule engine module

• To query a number of execution rules, each of which specifies a condition for calling a service;
• To process the execution rules in a predetermined order, wherein a first execution rule causes a first service to be invoked if the message satisfies a first condition, resulting in a first modified message; and a second execution rule causes a second service to be invoked with the first modified message as an input if the first modified message satisfies a second condition.

The The invention further relates to a software program comprising Code means, adapted when executed in a data processing system, the Steps of the method described above and in the following perform.

The Software program may be embodied on a computer readable medium. The term computer-readable medium can include a magnetic one Tape, an optical disk, a digital video disk (DVD), a Compact disc (CD or CD-ROM), a mini disk, a hard disk, a floppy disk, a ferro-electric Memory, an electrically erasable programmable read-only memory (EEPROM), a flash memory, an EPROM, a read-only memory (ROM), a static memory Random Access Memory (SRAM), a dynamic random access memory Access (DRAM), a synchronous dynamic random access memory Access (SDRAM), a ferromagnetic memory, an optical Memory, charge-coupled devices, smart cards, a PCMCIA card, etc.

• – 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.

The invention further relates to a method for managing the establishment of a service in a service network, the method comprising the steps of

• Specifying, in a computer readable script, a number of privileges and rights to be granted to the service during an operation;
• - Analyze potential causes of feature interaction;
• Specifying a deployment strategy for the service as a set of execution rules stored as a computer-readable rule module script.

The The invention further relates to a data set comprising Control module for use in the method described above and in the following.

These and other aspects of the invention will become apparent from FIGS explained with reference to the embodiments and with reference to the drawings, in which:

1 illustrates different types of feature interactions in a SIP service network;

2 illustrates the network elements involved in a service environment SIP server architecture according to one embodiment of the invention;

3 schematically illustrates a system architecture of a SIP server supporting a service execution rule mechanism according to an embodiment of the invention;

4 illustrates the structure of a control module according to an embodiment of the invention;

5 illustrates the grouping of services into limited amounts of services according to an embodiment of the invention;

6 illustrates the grouping of services into restricted sets of services corresponding to locations in the ROI SIP message flow in accordance with a preferred embodiment of the invention;

7 illustrates the flow of processing between services belonging to different processing points according to an embodiment of the invention;

8th illustrates the grouping of services into rule modules according to administrative authority according to an embodiment of the invention;

9 an embodiment of the invention illustrates where services are grouped according to both processing points and administrative authority;

10 the processing mechanism of the embodiment of 9 illustrated in the case of multiple rule modules and multiple processing points;

11 illustrates another example of the processing rules used in conjunction with 9 to be discribed;

12 illustrates hierarchical rule module processing according to a preferred embodiment of the invention;

13 shows an example of the flow of SIP message event contexts and instruction sets according to an embodiment of the invention;

14 illustrates a mechanism for managing multiple instruction sets in accordance with a preferred embodiment of the invention;

15 illustrates a tree of cascaded chains of service applications in accordance with an embodiment of the invention;

16 shows the software components of a service support environment according to an embodiment of the invention;

17 Steps performed by the service interaction module between the processing of the rule module and the processing of the service application in the embodiment of FIG 16 ;

18 illustrates the tree structure of processing rule modules according to an embodiment of the invention;

19 recursive processing of rule modules in a situation where service applications generate new event contexts according to an embodiment of the invention; and

20 illustrates a mechanism for enforcing access control in conjunction with rule modules according to one embodiment of the invention.

1 illustrates different types of feature interactions in a SIP service network. With the introduction of SIP, a new range of conversational and real-time services is emerging on the Internet. These services 101 - 105 can through end user terminals 106 - 108 , also called user agents (UA), or one or more intermediate network servers 109 be managed. between server 109 can value-added services 102 - 103 Provide user agents to initiate and / or terminate, but also to the associated media client and server application (s). These intermediate servers can be proxy servers, redirection servers, dedicated application servers, or even user agents.

Communication messages sent between the user agents are sent by the between server 109 over the internet 110 or another communication network forwarded. A fundamental problem caused by an intermediate SIP server 109 is managed to meet the expectations of a user's service level to maintain good network performance and to allow flexible and scalable definition of new services. Because performance is a key issue, the architecture should allow some services to run on the SIP server. Since it may not be feasible or possible to perform certain services on the SIP server, the architecture should also allow services to be run on remote servers.

It there is a need for flexibility of service definition, since the functionality of the SIP server is not in the should be defined in advance. In particular, services can be continuous from a range of sources, including service providers and subscribers, uploaded / registered.

Of the Owner of the SIP server can at the same time the SIP service provider, administrator and subscription providers. This interest group is called a Network operator; it can be a type of Telco or ISP. The network operator can change the domain name of the SIP server and third-party service providers Provide service features. The network operator installs service applications and rule modules on the SIP server and offers subscribers services at. In this case, the network operator acts as a service provider and service administrator. A participant has a contractual relationship with the network operator to have a subscription and to the subscriber services to receive that offered by the SIP server become. The subscriber may have a service that is available to the subscriber allows to upload service applications and rule modules to the SIP server. The participant owns these services for private use, i.e. personalized services. Simplicity becomes all sides with the exception of the network operator (s) and the subscriber as service provider a third page designates a contractual relationship with the network operator.

Network server owners Network server providers, network server administrators, service providers of one third party and participants look at the intermediate SIP server as a potential platform for setting up services that for one reason or another, not in endpoint user agents can be set up or should.

It gives a range of standardized protocols (e.g., SIP, SDP, SOAP), languages (e.g., CPL), and interfaces (e.g., SIP-CGI, 3GPP OSA API) that handle different aspects of service control. Also, it is likely that services have their control over several Use protocols, network components, languages and interfaces. The SIP server should be extensible to all these aspects like required to assist. These service applications can owned by different sites that have different Authorization levels and different contractual relationships with the owner of the SIP server. The service applications can use the Default processing of SIP requests and responses in different specified call / session processing points, under different conditions, etc. add a value (are but not limited to doing so).

The following example demonstrates that it is likely that multiple services can be called based on a SIP event. Consider an example where a subscriber, say Bob, has a SIP subscription with some SIP provider, say Telco. Bob has a range of services that the user wants to place on the network. Services, such as terminal-independent services or services tailored to whatever terminal Bob is currently using. There may also be services that provide Bob with security, privacy and reliability. Also, Bob does not want to manage his own services. It is also assumed that Bob works in a company, say Corp. The services that are called to manage an incoming INVITE message to Bob can look like this:
Telco can own and administer the SIP server. Telco also provides subscribers with SIP services and third-party services. The Telco recognizes that Bob is a participant in an incoming INVITE. The first service is a Telco call barring application to check if Bob paid his last bill. The second service is a service provided by the Telco. He simply checks that the caller's media codecs can be handled by Bob's current location / terminal. If not, the application will request a media stream converter into the media stream flow (using third page call control). This conversion is transparent to Bob, and the application will monitor Bob's responses and update the session descriptions as necessary. The third service is Bob's own preferences for called parties, eg a CPL script. This application monitors responses to the authorized request and, based on this, may pass the INVITE to multiple destinations. Say, the INVITE is to Bob's current private SIP URL. at "no answer" is given to the INVITE acting on behalf of his wife Alice. In some cases, Bob wants all private calls redirected to his company SIP URL. The fourth service is also a Telco service, but is provided to the Telco by a 3rd party application service provider, say besafe.com. This service checks message body content types and provides a virus scan if needed, eg if an animated vCard is included. The fifth service is an ISP service that offers the called party's multimedia advertising in return for a refund of the Telco billing. If the session is established, and if it is a videoconference session, Bob receives a small flowing bar of information at the bottom of the video image. This service is a monitoring application and uses third-party call control. The ISP has an account on Telco's SIP server and can directly offer services of the subscriber base owned by Telco. Bob subscribed to this service directly with the ISP, without the involvement of Telco. The sixth service is a service managed by the company where Bob works. If the call is directly to Bob's current corporate SIP URL, the call is then forwarded to Bob based on data known only within the Corp's private LAN network. The last and seventh service is for administrative purposes, as Telco may want to do some logging.

The above example illustrates the variety of contractual relationships, that are related to the different services that be triggered by an event. The services can be in the Possession of different interest groups are and can be under Be implemented using different technologies.

Different services set up in a service network can interact with each other. These interactions can occur between services that relate to a single user, multiple users, or between customer services and system services. The interaction may also occur between services running in the same network component or in another network component. In 1 Different types of interactions are illustrated: Interactions Single user multiple components (single user - multiple component, SUMC), customer - system (customer - system, CUSY), multiple users - single user (multiple user - single component, MUSC), multiple users - Multiple user - multiple component (MUMC) and single user - single user - multiple component (SUMC) component.

There are many causes for feature interaction, including "violation of feature privileges" and "violation of feature assumptions":
Feature Privilege Violation: Privileges of features are broken if features are called redundantly or through unauthorized pages. The main problem caused by violating feature privileges is redundant consumption of resources or unauthorized access to resources. This may in essence be unintentional or malicious. If a violation of feature privileges occurs, then there is a struggle between features, authorized or unauthorized, for access to the resources. If features are called redundantly or through unauthorized pages, they can subsequently be the cause of feature property violation. It is clear that avoidance of violation of feature privileges is desirable.

As will be described below, according to the invention injuries of feature privileges by filtering in context, in contractual Relationships, in conditions, in access control lists, privileges and Right dissolved.

Filter in context refers to the need for interpretation an event in a certain context. This must becomes obvious when networked multimedia services are managed that converged in one Network work.

Filter in contractual relations refers to the need to map an event to a set of features that contracted to handle this event. This problem area is particularly important in a deregulated market, where not only the provider of network infrastructure and session control services Offer value added services to subscribers, but where also third Pages have a legal right to make this offer.

Filter in access control policies ensures that an event only causes authorized behavior in the node.

Filtering in conditions ensures that a feature is not called redundantly when an Er event, and features to be retrieved based on the context, on contractual relationships and access privileges. These conditions may depend, for example, on the properties of the event, system properties or network properties.

injury of feature assumptions: assumptions about Feature behaviors are broken if the context of a feature changed by another feature in such a way that the feature can not work as intended. An injury feature assumptions can cause ambiguous or conflicting behavior.

characteristics are the visible behavior of a service application execution. An instruction issued by the service application issues to control the value-added behavior of the SIP node becomes a feature instruction called. Many features can however, apply their behavior to a message before the controlling one Instruction back to the SIP node is sent. The controlling instruction or instruction set, the back to the SIP node is sent, becomes a service control instruction called. It contains a resulting event context, i. the properties of a SIP message that is upstream or in response to the original event context downstream to be sent, which has triggered the service applications. ambiguous Behavior occurs if the service control instruction depends on the sequence in which the features control over the current event context gain, is different. Ambiguous instructions are not necessarily mutually exclusive.

When an example contains a SIP message body a color image in GIF format. S1 is defined to be a service application that resides in a message body content triggered by the GIF format. S1 is a service application that the GIF format in converted a JPG format. Further, S2 is defined, a service application which is also in a news content content from GIF format is triggered. Let S2 be a service application containing the GIF image in a black and white picture converted.

S1 be the first application to call, triggered by the GIF content. S1 will convert the GIF image to a JPG image and write it to the current event content. S2 never becomes called. The resulting event content becomes a JPG color image contain.

Now Let S2 be the first application to call, triggered by the GIF content. S2 will convert the GIF color image to a black and white image and add it to it write to the current event context. S1 is subsequently based called on the GIF content, as by the current event context specified. S1 will convert the GIF image to a JPG image and write it to the current event context. The resulting Event context will contain a JPG black and white image.

S1 and S2 clearly show ambiguous behavior, since the context of a Feature changed by the other becomes.

In Conflicting feature instructions are instructions that arise exclude each other. Conflicting instructions will try to overwrite each other. In this case, conflicting instructions are typically also the cause of ambiguous behavior.

Of Further, all feature instructions are potential unauthorized ones Instruction sets, unless they are explicitly authorized. Unauthorized feature instructions may or may not be malicious the result of a bad service application. In any case can you the security and integrity damage the system and should be recorded.

Watching Service applications can additional Problems to those already discussed cause. Watching Service applications can at any time grant asynchronous feature instructions to the SIP node, because they run continuously. As they monitor future events, can they executed in these events and provide more feature instructions. If there are several simultaneous monitoring Service applications their generated feature instructions depend on the order in she over the event will be notified. This contributes to the complexity of the previously discussed problems at.

The detection and resolution of feature acceptance violations is much more complicated than the resolution of feature privilege violations. As will be described below, in accordance with the invention, means are provided for specifying how to resolve ambiguous behavior, means for subordinating feature interaction management to independent feature sets and administration domains and a simple default rule to resolve feature interaction interference that is detected at run time. Violations of feature assumptions are resolved by feature ordering based on the cascaded chain principle and condition triggering, and feature properties based on the lock / unlock mechanism. This will be described in more detail below.

Other Causes of feature interaction include limitations of network support, e.g. limited protocol functionality or limited user interfaces, inherent problems in distributed systems, such as resource competition, feature coordination, timing or non-atomic operations, violation of system security, fraudulent, manipulated or eavesdropped News, having non-cooperative interactions with features conflicting interests etc.

in the general can distinguished three different types of feature interaction problem solutions Infrastructure: The development of infrastructures for deployment of features that integrate feature interaction management, i. which discuss the causes of some defined feature interactions. Feature interactions are presented both before (specification) and after (enforcing) the feature-up time, i. while Specification or enforcement of rule-based policies etc. According to the invention The rule module scripts form an infrastructure for setting up Features that are a framework for provides a feature interaction management.

Service creation: The design of features related to causes of feature interactions, i. the capture of feature interactions during the design phase. These feature interactions can be managed prior to feature mapping, e.g. about clarity, feature interaction causes analysis, Verification test, etc. According to the invention be the service creation and feature deployment strategy specification Imposed requirements.

Running time: The resolution feature interactions as they occur. Because not all feature interactions before a feature map can be identified, they must be detected at run time, e.g. through cryptographic authentication, Authorization and secrecy, rule-based policies, resolution algorithms, AI negotiation etc. According to the invention become simple rules for that It provides how feature interactions are resolved at run time be recorded. These rules include checking access control lists, which are related to rule modules, the resolution of Access violations due to alarm notification and decommissioning of offending rule modules, the scrutiny of scripts, the privileges and specify rights, and the resolution of violations of privileges and rights by alarm notification and decommissioning of infringing Features.

• 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.

The general management process according to the invention includes the following steps:

• 1. Feature design specification, independent of other features: A service is designed and specified without consideration of interactions with other features. However, according to one embodiment of the invention, the service is designed with respect to the processing point model described below.
• 2. Contract Negotiation The party wishing to establish a service in the service network negotiates with the administrator of the service network what privileges and rights the service can be granted. According to one embodiment of the invention, a privilege and rights script associated with the service is created.
• 3. Feature Interaction Analysis: The possible feature interactions are examined based on experience and possibly knowledge of some of the features set up in the service network.
• 4. Feature Population Strategy Specification: The author of a rule module who must set up the service gains an administrative domain. Based on the feature interaction analysis and knowledge of the service, subscribers, and users, the feature deployment strategy is specified in a rule module script.
• 5. Feature implementation.
• 6. Verification test.
• 7. Feature installation and activation.
• 8. Feature Runtime Behavior and Management.
• 9. Feature deactivation and deinstallation.

• – 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.

According to the invention, a feature interaction management framework is provided which

• The analysis stage allows to be easily mapped to specification rules by providing a simple language and framework with easy-to-understand principles,
• - define clear boundaries between the groupings of features known to a given analysis entity and those that are not,
• - provides simple and thus easy-to-understand rules for the transfer of control between these groups of characteristics. When passing from one set of features to another, there is a mechanism for ensuring that a subsequent set of features does not compromise the previous set, and
• - Simplifies the parsing stage by specifying processing points in the processing of events where preconditions are guaranteed and where applications are only allowed to give certain instructions to the server.

2 illustrates the network elements involved in a service environment SIP server architecture according to one embodiment of the invention. The previous SIP client 203 (previous sip client, PSC) represents any client, such as a SIP shared PC, a wireless terminal, a previous hop proxy, a SIP / PSTN gateway, etc. The client makes requests for session services with incoming requests to the client SIP server 202 by. The SIP server 202 represents the proxy, redirection or dedicated SIP-enabled application server where the service support environment 201 is implemented. Alternatively, it may be any other SIP-enabled entity that triggers value-added services, such as a user agent, archivist, or the like. Services that are in the SIP Server service support environment 201 are defined by service applications such as SIP CGI scripts, rule modules, and service features. The SIP node 202 Control can be to the service support environment 201 (service support environment, SSE) when receiving an event. The service support environment 201 can then invoke a relevant service application according to certain filtering criteria and based on this event. The service application returns a feature instruction or a set of instructions. The service support environment 201 gives control to the SIP node 202 along with service tax instructions back what the SIP node 202 informed about how the event is to be processed. The SIP node forwards the request to the next SIP client (next SIP client, NSC) 204 further. Responses to the request will be in the opposite direction from the nearest SIP client 204 via the SIP node 202 to the previous SIP client 203 forwarded, possibly triggering additional services. The next SIP server 204 represents any server, eg a SIP-enabled PC, a wireless terminal, a proxy of the next hop, a SIP / PSTN gateway etc. The server handles incoming requests. The remote server 206 offers a remote service execution, eg in a different service support environment. Based on, for example, performance criteria, the service support environment may 201 a processing in the remote server 206 initiate, for example, by using request / response logs. In this way different categories of services can be called and managed on different hosts. The protocol used to the remote server can be any protocol that supports request / response dialogs, such as SIP, ICAP, HTTP, OSA API, etc. The Administration Server 205 performs administrative tasks in the service environment. It is for a service support environment configuration 201 responsible with the domain of the SIP node 202 communicates. Therefore, the environment includes the service support environment 201 a SIP node, service applications, remote hosts, and an administrative entity.

3 schematically illustrates a system architecture of a SIP server supporting a service execution rule mechanism according to an embodiment of the invention. The service support environment 301 enforces the deployment infrastructure, ie how one feature interacts with another. Therefore, the service support environment looks 301 the functionality in the SIP server that supports value-added services. The service support environment 301 includes a rule engine (RE) 303 for managing the control modules 308 that are in an execution rule base 307 are stored. The standard drive 303 further comprises a rule module execution module (RMEM) 314 which is responsible for processing rule modules. The variable speed drive can provide services 309 - 311 via the service execution drive manager 302 call. The service definition manager (SDM) 312 provides functionality for the administration of the rule modules. The SIP server also implements a SIP protocol stack 304 , including the SIP default functionality 306 and a SIP message parser (SIP message parser, SIP MP) 305 , The message parser 305 supports the SIP protocol and extracts message properties through the rule engine 303 can be interpreted. The Administration Server 313 performs administrative tasks in the service environment.

An important mechanism for implementing service provisioning policies according to the invention is the specification of deployment rules as service execution rules specified in rule modules. Service execution rules specify conditions and actions that must be taken sen if the conditions are met. In accordance with the invention, a programming language is defined for specifying these rules, which is referred to as a Service Execution Rule Language (SERL).

The rule modules 308 be through the variable speed drive 303 managed and executed. The standard drive 303 is the main functional entity that implements the trigger and feature interaction mechanism and is part of the service support environment 301 , When an event occurs, the message parser calls the rule engine 303 on and passes the event the rule drive 303 , The standard drive 303 finds and loads the relevant rule modules 308 and processes those that are relevant to the received event in the correct order. The filtering includes a recording of contractual obligations. The events define the context in which rule modules are processed, that is, the conditions are evaluated according to the properties of the SIP message events. The standard drive 303 invokes the appropriate actions when the rule pattern matches the given message properties. Based on the content of these actions can be the rule drive 303 the application execution drive manager 302 or any other appropriate entity within the service support system. SERL scripts have no knowledge of the services they call and manage, except knowing how to call them generally and how to manage features. The control instructions received from the called service applications become the SIP stack 304 mediated back when the last rule module has been processed.

The standard drive 303 also manages the information sent between different services. When an event occurs, an event context containing the relevant properties of the event is established in a standardized way. The message properties have a name and a value. The value can be determined by the message. Examples of SIP message properties are:
Name: sipRequest.Request-URI, value: sip: bob@corp.com
Name: sipRequest.To, value: Bob Smith <sip: bob@corp.com>
Name: sipResponse.Status code, value: 301

An example of an SDP message property is:
Name: sdp.m, value: video 48232 RTP / AVP 0.

• – 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.

The standard drive 303 supports a number of internal APIs that can be accessed by the adjoining functional entities. Include these APIs

• - A message notification API passing through the SIP stack 304 to the message announcement from the message parser 305 to the variable speed drive 303 is used,
• A rule base definition API created by the service definition manager 312 is used,
• A service instruction API provided by the application execution drive manager 302 is used to instructions to the rule drive 303 on behalf of the service applications 309 - 311 to surrender, and
• A sharpening API created by the application execution engine manager 302 is used to arming triggers and transaction events on behalf of the service applications 309 - 311 to request.

The application execution drive manager 302 embeds a number of application execution engines (AEE) 315 for various types of service applications and manages them, for example, an OSA drive, a CPL drive, a CPL interpreter, a CGI drive and / or a servlet drive. It supports the interface through the rule drive 303 and maps between the application API and the rule engine API. From the point of view of the standard drive 303 see all the application execution drives 315 like a single entity, ie the application execution drive manager 302 , The service definition manager 312 Can the application execution drivers 315 provide additional functionality.

• – 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.

The APIs generated by the application execution drive manager 302 to be provided, include:

• - a call API, through the rule drive 303 for call instructions from the rule engine to the application execution engine manager 302 is used, and
• - an announcement API by the rule drive 303 for notification instructions from the rule engine to the application execution engine manager 302 is used.

The default SIP server behavior 306 includes the functionality of a proxy server, a redirection server, an application server, or even a user agent. It can also include Archivist or IM & P functions. It provides an interface to that through the variable speed drive 303 can be accessed to place instructions. Alternatively, a service application may implement the SIP server behavior. Therefore, it is possible for the rule drive to call only parts of each of the above functions, as required by the service applications.

• – 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.

The service definition manager 312 provides an O & M API that passes through the Administration Server 313 , Service applications 309 - 311 and the SIP stack 304 be used. The API provides functionality for

• - Manual authentication and authorization of new rule modules and service applications.
• - Manually configure the rights and privileges of rule modules and service applications.
• - Manual loading of rule modules and service applications.
• - Manual activation / deactivation of control modules and service applications.
• - Manual validation of control modules.
• - Manual validation of service applications implemented using scripting languages.
• - Manual deletion of rule modules and service applications.
• - Manual listing of all rule modules and service applications along with their status.
• - Manual modification of control modules.

The service definition manager 312 may further provide an interface that supports automatic handling of some of the above manual functions and / or additional features, such as listing available service features, obtaining interface and / or version of a service feature, listing supported execution engines, and scripting languages such as JVM, CPL , Perl etc., installation / de-installation of service features, activation / deactivation of service features, registration of a service application that will provide service as a service feature to another service application, subscription of service features, invocation / termination of service features, statistical operations such as "monitor processor load", "Busy hours calls", billing operations, activation / deactivation, reading, billing records reset etc.

Here, the term service features includes functions offered to service applications. The service features are considered as in the service support environment 301 and the SIP stack 304 to be integrated. The application execution drive manager 302 and the service definition manager 312 Both provide the service applications 309 - 311 Service features ready. Nevertheless, some of the features provided by the application execution drive manager 302 offered by the variable speed drive 303 and the SIP stack 304 taught.

The service applications 309 - 311 are programs that are compiled or interpreted in the service support environment 301 of the SIP server or on a remote server. Their purpose may or may not refer to the basic functions of the SIP server. Service applications can implement SIP server behavior. Service applications may offer services to other service applications, ie they may be service features. For example, a service application may include any MIME-type converter and offer it as a service feature to other service applications. Other service applications can then use this function to perform a service. Preferably, service applications should be portable between SIP servers and run on remote servers. Service applications may access or be accessed by a global or local naming convention, a standardized or local namespace, by using specified file paths to the applications, etc., an open and standardized API, eg SIP-CGI, OSA API, HTTP , ICAP, CPL, Servlets etc.

One standardized mechanism for accessing a service application is an advantage for service providers a third page.

The SIP server does not necessarily manage remotely placed service applications because it can not know about them. In this case, the SIP server or the application execution drive manager 302 Require location information provided by the triggering information.

The message parser 305 is responsible for interpreting received messages, isolating well-defined elements as message properties, and initiating actions that are appropriate to activate. When an event occurs, a message object is created that contains the relevant properties specified by the message parser 305 be isolated.

Preferably has any supported Log a corresponding message parser. A parser can Subordinate parsers contain the child logs correspond, i. embedded in other protocols like SIP. For example, It can be a separate parser within a SIP message saver to handle different types of media, such as SDP, HTML, XML and XHTML. From the point of view of the propulsion all see Parser like a single drive out. The API for one Message parser should preferably be defined such that Parser for new protocols and content can be added modularly.

• – 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.

For any protocol through the service support environment 301 to support, covers the interface between the message parser of this protocol and the rule drive

• The set of properties defined by the message parser, including the property name, its relationship to the message that characterizes it, and the ability of an action to change it, and
• - The processing points where rules can be activated.

In one embodiment of the invention, the service support environment 301 or each of the functional entities within the service support environment may be placed in separate hosts serving multiple servers, eg, SIP, Web, WAP, I-mode, RTSP servers, and accessing multiple application servers, eg databases, OSA, Web, SIP, etc.

For example, the variable speed drive can 303 , the application execution drive manager 302 and the service definition manager 312 located in each of their hosts, possibly coupled via IP. The interfaces between the rule engine and the various servers can be standardized or proprietary. The interfaces between the rule engine, the application execution drive manager and the service definition manager should preferably be proprietary and packed together. The interfaces between the service application servers and the service support environment are preferably standardized, such as OSA API, HTTP, SIP, or any database API, such as any SQL-based API. In such a distributed configuration, another advantage of the invention becomes apparent because the rule engine is capable of managing many types of events, not only SIP events but HTTP events, SMTP events, Wap events, media events, and so forth. Codec events, such as MPEG7 events or 3D virtual reality or game object events, etc.

• 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:
  
  
• 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).

Still referring to 3 For example, the triggering mechanism according to an embodiment of the invention may be illustrated by a simple example assuming that only a single rule module is relevant to a received event. In 3 refer the numbers in circles to the following steps of a trigger example:

• 1. There will be a SIP request in the message parser 305 receive.
• 2. The SIP message parser 305 generates a SIP message object. The standard drive 303 converts this to a SIP event context.
• 3. The relevant rule modules are in the execution rule base 307 based on the event context, processing points and contractual relationships. An embodiment of this mechanism will be described below.
• 4. The variable speed drive 303 loads the found control module 308 from the execution rule base 307 in the rule module execution drive 314 and execute it. As an example, the loaded rules module contains the following functionality, ie a rule, the trigger criteria and invocation actions for service applications 310 and 311 specified:
  
  
• 5. A trigger is reached and the specified service application Y ( 310 ) is sent by sending a call command to the application execution drive manager 302 called.
• 6. The application execution drive manager 302 locates the application Y ( 310 ).
• 7. The application execution drive manager 302 loads the relevant service application Y ( 310 ) into an application execution drive 315 and then activates it for execution.
• 8. The resulting instruction of application 310 becomes the rule drive 303 returned.
• 9. The variable speed drive 303 resumes processing of the rule module and triggers another application Z ( 311 ). The application execution drive manager 302 a call command is given.
• 10. The application execution drive manager 302 locates the application Z ( 311 ).
• 11. The application execution drive manager 302 loads the relevant service application Z ( 311 ) in an execution drive 315 who can run the application and then activates it.
• 12. The resulting instruction of application 311 becomes the rule drive 303 returned.
• 13. The variable speed drive 303 resumes processing of the rule module and finds out that the rule module no longer has to execute rules and that there are no rule modules to load anymore. Subsequently, the variable speed drive sends 303 the final result of the services to the SIP default behavior 306 ,
• 14. The SIP default behavior 306 unites the output from the variable speed drive 303 with a possible default output and sends the SIP message to the message parser / converter 305 ,
• 15. The SIP message is represented eg (proxied).

In the case of several control modules, the above steps 13-14 may alternatively be as follows
13. The variable speed drive 303 resumes processing of the rule module and finds out that the rule module no longer has to execute rules. The standard drive 303 searches for rule modules with lower order priority than the previously executed rule module.

14. Go to point 3 in the previous example. If a rule module is found, it will be run as in the previous example, possibly by calling other applications, eg the application will 309 called.

If no rule modules or services are installed to control a session, the rule engine passes 303 control to the SIP server, and specify a blank output. The SIP server may receive the blank output with the default behavior 306 of the server, as in SIP CGI, according to default SIP behavior for archivists, redirection servers, and proxy servers.

• – 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.

4 illustrates the structure of a control module according to an embodiment of the invention. According to the invention is a control module 401 conceptually a tree comprising a number of service execution rules 401 - 402 where each rule is a number of conditions 403 - 404 respectively. 405 , and a number of actions 406 - 407 respectively. 408 specified, which must be undertaken if the appropriate conditions are met. In the following, conditions are also referred to as patterns. At a high level, a rule module further includes

• - Owner information 409 indicating the owner of the rule module, ie an identifiable page with an interest in the SIP node. This page can have several control modules. The owner information may further include information about contractual relationships.
• - Protocol information 410 specifying the context in which the rules in the rule module are to be interpreted.

• – 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.

Examples of protocols are SIP, SDP, HTTP, H.323, etc. Preferably, only a single protocol should be defined per rule module. Otherwise, any overlap may provide ambiguous interpretation. For example, both SIP and HTTP have content style fields.

• - Access control information 411 , which specifies which pages have the right to access, administer and read the rule module.
• - a rule module identifier 412 , preferably a unique identifier. In addition, a rule module may include a number of aliases.

A rule module may also contain supplementary information 413 , which provides further context information for a rule module, and index information 414 include.

A pattern 403 - 405 is an expression that can be evaluated with respect to the message properties in an event context, and either the rules will match or fail to match the properties in the context. Actions 406 - 408 can identify applications, built-in service properties, remote servers, load-sharing hosts, or next-hop SIP servers. You can also identify downloaded and externally placed action objects, and so on. Rules, conditions, and actions can have parameters that describe their behavior, they are the attributes of the tree nodes. The branches have a weight that indicates which branch should be processed first.

Preferably Each rule module has an explicit ordering priority given to it is assigned, i. the order priority specifies the sequence, in the control modules are loaded by the variable speed drive.

According to one preferred embodiment of the invention, the nodes of the tree in the graph through XML elements shown. The branch from one node to the next node is by enclosing of the element representing the next node (s) within the Representing element that represents the knot from which branches becomes. The weighting of the branches results from the order, in which they are presented in the script. This weighting results the order in which the elements are to be processed, if one Event is received. In other words, the script is from running down to the top. Thus, there is in this embodiment no loops within a SERL script. Preferably Specifies the format of a rule engine as an XML DTD or XML schema.

It is an advantage of this embodiment, that it is based on a standardized and extensible language, to specify languages.

In an embodiment of the invention Policies associated with rules, the privileges and specify rights. Each node of the rule module can have a associated Have policy nodes that may contain access control lists.

The following is an example of an instance of a rule module specified as a SERL script:

5 illustrates the grouping of services into limited amounts of services according to an embodiment of the invention. According to this embodiment, services 501 - 508 into a set of feature groups (FG) 509 - 510 grouped. In the in 5 example shown contains feature group 509 characteristics 501 - 504 , and feature group 510 contains characteristics 505 - 508 , For each feature group, certain restrictions are placed on the services of this group, ie they are only allowed to give well-defined types of instructions. The feature sets do not specify how individual features are allowed to interact within a feature set, as long as they do not violate group behavior limitations. The feature groups are ordered sequentially, ie by numbering the feature groups. In the example of 5 is a feature group 509 the K-th feature group in a sequence of feature groups, and feature group 510 is numbered by K + 1. The ordering of feature groups imposes an order of execution such that the features of feature set 509 before the execution of the characteristics in group 510 be executed. Preferably, the definition of a feature group comprises a specification of the group order, eg by specifying a group index, by specifying a previous and a next feature group or the like. Preferably, the definition of a feature group further comprises a specification of preconditions, ie conditions on which the features of this feature group may be based, and a specification of constraints enforced in the behavior of the services of that feature set. Therefore, the feature groups are an ordering mechanism that is a fundamental type of feature inter formalized by providing an ordered sequence in which service applications are called. Therefore, this mechanism provides a framework for grouping the problem of feature interaction into restricted sets of features. The mechanism actually solves interactions between these feature sets because, due to the limitations in the feature sets, the feature assumptions when passing control from one group to the next are deterministic and well-defined. It is an advantage of this grouping that it provides a mechanism for breaking the problem of feature interaction analysis into smaller independent problems, thereby making it easier to manage the problem. Furthermore, it is an advantage that formalized problem areas can be delegated to independent pages, making the problem more scalable. The mechanism of feature sets gives the administrator and service provider the ability to categorize the service applications into various points in a processing time where the service applications should be called.

6 Figure 12 illustrates the grouping of services into restricted sets of services corresponding to locations in the round trip SIP message flow according to a preferred embodiment of the invention. According to this embodiment, the feature groups refer to locations P1-P6 in the logical request / response round trip message flow that have guaranteed certain preconditions for the event context, and where a service application is based on the restrictions over which behavior is allowed in that location , can be called. These feature groups are called processing points.

The six processing points P1-P6 are a general grouping of services. Processing points P1-P3 and P4-P6 logically cover corresponding problems. Processing points P1-P3 include services that are in requests 607 and processing points P4-P6 include services that respond 608 be triggered. Logically, processing points P1 and P4, points P2 and P5 and points P3 and P6 correspond to corresponding restrictions.

A SIP message can be roughly divided into two parts, the signaling characteristics, i.e. Properties related to SIP, SDP, etc., and the message body content, not related to signaling, such as GIF, HTML etc.

• – die Signalisierungseigenschaften beeinflussen,
• – nur den Nicht-Signalisierungs-Nachrichtenrumpfinhalt beeinflussen, und
• – jene, die weder die Signalisierungseigenschaften noch den Nicht-Signalisierungs-Nachrichtenrumpfinhalt beeinflussen,

gruppiert werden.Services that are called in a SIP event can therefore be sent to those that:

• - influence the signaling properties,
• - only affect the non-signaling message body content, and
• Those that do not affect the signaling properties nor the non-signaling message body content,

be grouped.

This results in the basic grouping of services into three groups 601 - 603 respectively associated with the three processing points P1-P3. Similarly, in the response run, the corresponding groups 604 - 606 each related to the processing points P4-P6.

Here the term signaling properties includes SIP and SDP message properties, which can be adjusted in a rule module condition to call a service. Consequently, applications that have a Change signaling property, cause another application to be called that still invoke another application, etc. The benefit of a shift the handling of service applications, the signaling properties do not change, to a processing point, after all changes to the signaling properties occurred, is that the administrator a lighter Task when arranging the applications in the processing points P2 and P5 has.

• – 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.

In one embodiment of the invention, the processing points P1-P6 may be defined as follows:

• - Processing point P1 - Client request of a previous jump: It became a SIP request 607 received by a client from a previous jump. For this particular request and for this particular subscriber, no rule modules were invoked at any previous processing point. This processing point includes services that affect the SIP / SDP signaling properties of the resulting message (s), but not the message body content.
• - Processing Point P2 - Inquiry Summary: The signaling properties of the resulting SIP / SDP message (s) have been generated and cached, ie this part of the SIP message is ready to be sent. Additional updates to the call / media control signaling properties are intended not occur unless explicitly authorized. The services 602 which are called in the processing point P2 should not affect the SIP / SDP signaling characteristics as generated in the processing point P1. There may be exceptions to this rule. For example, services may affect SIP headers such as Alert Info, Call Info, Content Disposition, Content Encoding, Content Language, Content Length, Content Type and Requests. Special care should be taken if these signaling characteristics are changed in both processing points P1 and P2. Examples of types of media content that can be processed at this processing point include SOAP, HTML, vXML, SMIL, GIF, MPEG7, au, etc.
• - Processing Point P3 - Request Stack Point: The resulting SIP message (s) have been generated and sent. There will be no updates to the resulting message (s). This processing point corresponds to services 603 which only need to be called, but do not produce an output needed to process the request. These services only need to read the resulting message (s), but not update them.

• – 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.The processing points

• P4 server response of a previous jump,
• - P5 - Answer, and
• - P6 - Response stack point

can for reply messages 608 be defined analogously to each of the processing points P1-P3.

Alternatively or additionally, other processing points may be defined. For example, an additional processing point P0 (not shown) may be defined in the features without restrictions and triggered in any event, ie, receipt of both requests 607 as well as answers 608 ,

Preferably can additional Processing points with one of the high-level processing points keep in touch. For example, can Part processing points for Processing point P1, the P1.1, P1.2, P1.2.1, P1.2.2 etc. can be mentioned. Preferably, new processing points should only be defined if they define a logical group of services that are used by Can be use according to specified Call preconditions.

The The following table includes some examples of services included in the different processing points in an inducing or final SIP server can be defined:

7 illustrates the flow of processing between services belonging to different processing points according to an embodiment of the invention. In the embodiment associated with 6 is described, services that affect different parts of a SIP message are grouped into different processing points. This can be used to provide efficient service processing. Services that provide the SIP signaling properties of an incoming message 701 are included in processing point P1. Therefore, the output from the processing point P1 includes the final call / media control instructions 702 , This can be combined immediately with possible SIP server default behavior and the message converter 705 pass the outgoing SIP message 703 prepared. In addition, the services invoked at processing point P2 can rely on the signaling properties no longer changing, eg, they can trustingly apply services that depend on the final generated destination address.

By concentrating services that only affect the non-signaling SIP message body content (and possibly the related content header fields), at processing point P2 is the output 704 sufficient from the processing point P2 for the server, the resulting outgoing SIP message (s) 703 to actually send. The edition 704 from processing point P2 becomes the message converter 705 pass, with the output 702 from the processing point P2, and the message 703 will be sent.

When the output of processing points P1 and P2 is ready, processing point P3 is reached. The services in processing point P3 do not affect the content of the resulting SIP message 703 but can be based on it. Therefore, preferably, the resulting SIP message generated from the point P1 and P2 may be sent before waiting for the execution of services from the processing point P3, thereby increasing the efficiency of the system.

Therefore has the grouping of services according to processing points the The following advantages: Processing points simplify the problem of feature interaction. Processing points make the problem scalable by feature interaction. Improve processing points Latency of processing messages when parallel processing is used, i. Multiple processors. Answers or proxy requests can returned to the network faster because service applications that are not instructions to the Specify SIP server, located at processing point P3. Therefore the answer or proxy request does not have to wait for the Service applications are called in processing point P3.

8th illustrates the grouping of services into rule modules according to administrative authority according to an embodiment of the invention. Because rule modules have a rule module owner associated with them, they correspond to an administrative domain where an administrator, ie the rule module owner, can specify service setup policies. Within a rule module, the order of actions is assigned by the owner of the rule module, ie the SERL script author.

According to this embodiment of the invention, each rule module has assigned a priority to itself. The priority specifies the relationship between rule modules. The higher the rule module priority, the sooner the rules will be applied in the rule module. 8th schematically shows two control modules 801 and 802 , control module 801 is owned by Administrator A, while the rule module 802 owned by Administrator B. The rule module priorities of the rule modules 801 - 802 are indicated by a rule modulus ordering where a low order corresponds to a high priority and vice versa. For example, regulation 1 may be defined as the highest priority. In the example of 8th has rule module 801 a rule module order h and rule module 802 has an order h + 1. Consequently, the services 803 - 804 by rule module 801 be called before the service 805 from rule module 802 executed.

control modules with the same owner the same order priority to have. Preferably they should be different in this case Have event contexts (e.g., SIP, HTTP, ...) thereby avoiding that is, more than one rule module with the same priority in the same event context is called. In other words, should Rule modules that have the same message property of one given event context can have different priorities.

each administrative domain is independent from other administrative domains. This means that an administrative domain does not know about the Services that are located in other domains. Everyone Administrator is for Analyze and specify service deployment policies in a given domain responsible.

If more than one rule module or service application in a given one Event is called, they will each have a lot of feature instructions which will specify how to process this event is, e.g. whether the event will be forwarded or completed should. Clearly, such feature instructions should not can be processed at the same time, and some feature instructions may be different cancel. In some cases however, it may not be important in what order feature instructions applied or used simultaneously.

In accordance with the invention, a mechanism is provided for allowing administrative domains to protect their feature instructions when transferring control to another administrative domain. This means that any administrative domain can limit the handover of control to properties that are unimportant for the correct behavior of their features. The object that is passed from one service to another is the current event context 806 - 807 , When the control of the event context 806 is passed between service applications belonging to the same administrative domain, preferably the default rule is that no properties of the event context are protected. If anything is to be protected, this must be done explicitly. However, administrative domains are all properties of an event context 807 protected by default. Unless it is necessary to protect anything between administrative domains, it must explicitly be unprotected be marked. Preferably, the right to mark properties protected and / or unprotected should be governed by a privilege associated with a rule module.

With other words can Control modules higher priority Lock message properties if they have the privileges to do this, and locked message properties can be through Rule modules will not be released unless they have the Privileges to do this.

The following example of a fragment of a rule module illustrates locking / unlocking message properties after a feature F1 has been executed:

In an embodiment According to the invention, an action output may terminate the rule module, i. the downstream Applications are not called. Furthermore, actions can explicitly set privileges in message properties in the current Set event context if you have the privileges to do so do. It is an advantage of this embodiment that the administrative domains independently are as soon as they give priority was assigned.

According to this embodiment arranges an overarching Administrator's priorities or areas of priorities the rule modules based on contractual relationships with everyone the rule module owner too. The overarching domain administrator would of course be too the owner of the highest priority rule engine. For example, At the top of the hierarchy is the SIP service provider who runs the domain name and the IP address of the host. The SIP service provider can provide many services to many sites. He can also be for his own applications run applications, e.g. logging, Billing, statistics collection, fraud detection, advertising etc. He can place one or more rule modules on the server.

For example, the SIP service provider may place a rule module for each of its participants. When a SIP event has been received in the SIP server, the main rule module of the SIP service provider may invoke some of its own services and then hand over control to the rule module for the appropriate party. In this rule module, there may be rules to trigger services that are tailor-made for the specific participant. These services may be provided by the SIP service provider itself, or may be purchased by the SIP service provider from third-party service providers. The SIP service provider would be responsible for analyzing feature interaction problems between these services and specifying ordering priorities and instruction priorities between the service applications, preferably by using SERL. In this case, both the main rule module and the subscriber rule module are owned by and administered by the SIP service provider. They are said to be in an administration domain. At some point in the ordering priority, the SIP service provider may decide to hand over to a rule module owned by the subscriber himself. It should be noted that individual participants may be able to write their own SERL scripts, or they may only be able to update preferences, eg via an HTML form, from which a SERL script can be generated. The subscriber's policy module may invoke a CPL script or, in turn, invoke another policy module, any rule module of a third party service provider, or the like. If the participant's rule module includes more than one action, the participant must specify which action should be performed first. Likewise, in the rule module of third parties, the actions should be ordered according to the wishes of the third party.

In In another scenario, the subscriber may be an employee of a Being corporate clients. In this case, the rule module of the SIP service provider first handed over to the rule module of the corporate client, which has any Call applications and then transfer them to the rule module of the individual participant can.

The top-level administrator may wish to merge the order of priority with a number of rule modules. However, it can be cumbersome to mix rule modules with lower priority rule modules from other sites. One solution to this problem is to separate rule engine priorities with sufficient hiding areas that can be used at a later time. Alternatively, a hierarchical administration domain model may be applied as in connection with 12 is described.

Preferably supports the service support environment a mechanism for notifying administrators when An application tries to change a protected property. Preferably An application attempting to change a protected property is taken out of service taken.

It It is noted that modifications of the above scheme are possible. For example, can be in a hierarchy of administrative domains each Administrator of a level have a full scope, to arrange rule modules on lower priority levels, within one assigned priority range. Of the Administrator higher Level would delegate this scope.

It is an advantage of this embodiment, that they have a scalable mechanism for managing and implementing of service listing guidelines. According to this embodiment is the service support environment able to service page a third page without considerable additional Work for the domain administrator to entertain. There is another advantage to that limitations the number of interest groups or the number of contractual relationships be placed between them.

It Another advantage of this embodiment is that the task from feature interaction analysis to administrative domains is broken thereby giving a distribution of the problem between the affected pages is allowed.

9 illustrates an embodiment of the invention where services are grouped according to both processing points and administrative authority. 9 schematically shows a control module 901 with priority order h and a rule module 902 with priority order h + 1st control module 901 calls services F1, F2, F5 and F6 while the rule module 902 Services F3, F4, F7 and F8 calls. The services F1-F8 also refer to processing points (PP) 903 and 904 , processing point 903 includes services F1-F4, and processing point 904 includes services F5-F8. The processing points 903 - 904 are numbered so that the processing point 903 has the index K, and processing point 904 has the index K + 1, indicating that processing point 903 before processing point 904 is processed.

According to this embodiment Rules are applied in a sequence of processing points. Consequently, when rule modules are processed, only the service execution rules become executed that belong to the current processing point.

For each Processing point, there are sets of rule modules grouped according to priority are, and that can be called in this processing point. All Control modules of priority 1 are grouped in set 1, all rule modules are of priority 2 grouped in set of 2, etc. In a given event context becomes however, at most called a rule module in each of these sets. A rule module can over several processing points be distributed.

In the example of 9 First, the services of the processing point 903 processed according to their rule module priority, ie services F1 and F2 are processed before services F3 and F4. Subsequently, the features F5 and F6 of processing point 904 and priority h before services F7 and F8 fen.

The rule modules 901 and 902 , in the 9 are schematically illustrated, can be expressed as indicated in the following examples of control modules.

10 illustrates the processing mechanism of the embodiment of FIG 9 in the case of multiple rule modules and multiple processing points. According to this embodiment, there are four processing points numbered PO to P3 and five control modules RM A to RM E each having priorities 1 to 5. In accordance with the processing rules associated with 9 services are processed as indicated by the circles in 10 displayed, numbered 1 through 20 and connected by arrows. Each numbered circle can represent a set of rules that call a number of actions.

11 illustrates another example of the processing rules associated with 9 to be discribed. 11 illustrates instances 1111a - 1115a from control modules RM A to RM E on the left side 1101 or instances 1111b - 1115b the control modules RM A to RM E on the right side 1102 the Figure. The control modules RM A to RM E include rules corresponding to processing points P0 to P6. Therefore, the instances of rule modules on the left side 1101 may have different sections of the same respective rule modules as the rule modules on the right side 1102 represent. As in connection with 6 has been described, the processing points P1-P3 are triggered by SIP requests, while the processing points P4-P6 are triggered by responses. Processing point P0 is triggered by both requests and responses. Therefore, in this example, an incoming SIP request triggers 1103 , eg an INVITE request, services of rule modules RM A to RM E relating to processing points P0-P3, in the order indicated by the arrows on the left 1101 in 11 is shown. In the example of 11 it is further assumed that a service 1104 Issue an instruction that has an answer 1105 causes. This response in turn triggers the processing of the rules of the control modules RM A ( 111b ) to RM E ( 1115b ) referring to the processing points P0 and P4-P6 as on the right side 1102 from 11 displayed starting with the service (s) 1106 , and an outgoing message 1108 leading, eg a generated preliminary answer. The processing of services on the left 1101 also results in an outgoing message 1107 , eg an INVITE proxy request.

12 illustrates a hierarchical rule module processing according to a preferred embodiment of the invention. When the rule engine (RE) 1200 event 1201 It identifies the relevant control modules 1216 - 1219 different priorities for this event in the rule base. The standard drive 1200 generates a current event context 1202 , initiates processing of the highest priority control module 1216 and passes control over the generated current event context 1202 to this rule module 1216 , If the processing of the highest priority control module 1216 is completed, calls the variable speed drive 1200 the following control module 1217 according to rule module priority and returns the modified current event context 1206 to the next rule module 1214 further. The following control modules become similar 1218 - 1219 called and control over the respective current event contexts 1207 and 1214 will be passed on to you. Eventually the resulting event context becomes 1215 to the variable speed drive 1200 returned. According to this embodiment of the invention, each called control module can then call one or more other control modules. According to a preferred embodiment, control modules are divided into two types of control modules: control modules 1216 - 1219 by the variable speed drive 1200 according to their order priority, and rule modules 1220 - 1225 that can only be called by other rule modules. The latter type of rule module may be formally identified by a particular ordering priority, eg, ordering priority 0. According to this embodiment, rule modules having this priority have specific limitations associated with them: rule modules having this ordering priority should not be governed by the rule base processing procedure of the rule engine 1200 but are called by another rule module with explicit privileges to do so. Rule modules with an ordering priority that differs from 0 are not called by another rule module, but only by the rule driver. Rule modules with the same owner can have the same ordering priority (other than 0), but in this case they should have different event contexts, eg SIP, HTTP, etc. This means that they should not be called in the same event context. Rule modules with different owners can have the same ordering priority, but in that case they should not be called in the same property in the same event. In other words, rule modules that can be invoked in the same message property from a given event context should have different priorities, unless it is null. The first rule module 1216 is called by the rule drive before any rule modules with order priority 0 are called. This rule module is called the root rule module. If the root control module 1216 If you call rule modules with priority 0, you can call other rule modules with priority 0 again. These relationships between rule modules are called the rule module hierarchy. This mechanism for invoking rule modules from within rule engines results in a hierarchical distribution of administrative domains, also called the hierarchical administrative domain model. The advantages of this model are that it is easy to administer and gives the main rule modules a large amount of control. It is a further advantage that additional rule modules can be added to an existing hierarchy without having to again reject a large number of priorities of subsequent rule modules.

The avoid the above rules rule modules in the rule base processing procedure by chance twice be called.

In the example that is in 12 is getting called rule engine 1216 control modules 1221 and 1222 In this order, the controller passes the appropriate event contexts 1203 - 1204 and receives the resulting current event context 1205 , Similarly, rule module calls 1218 control modules 1222 - 1223 with the appropriate event contexts 1208 - 1209 and the resulting event context 1213 on. Finally, the rule module calls 1223 that by rule module 1218 is called, furthermore control modules 1224 - 1225 with the appropriate event contexts 1210 - 1211 and the resulting event context 1212 on.

Therefore, a hierarchical invocation process is performed that generates a sequence of current event contexts by numbering the event contexts 1202 - 1215 is shown.

It it is noted that if defined more than one processing point is the above description of rule module processing as per processing point should be understood, i. For each processing point will have a corresponding hierarchy of Process control modules processed.

An important task of the rule base processing procedure of the rule drive 1200 is the mapping of SIP events to relevant rule modules. This process depends very much on the contractual relationships defined in the domain in question. A SIP event includes a number of message properties that can be used to capture a possible contractual relationship. These properties include siprequest.from (SIP request.from), siprequest.to (SIP request.to), siprequest.RequestURI (SIP request.URI request), sipresponse.from (SIP response.of), sipresponse .to (sipresponse.contact) and sipresponse.via (sipresponse.via). In particular, the From and Request URI of a SIP message are important characteristics of an event used to establish a contractual relationship with a third party network operator or service provider. However, other message properties may be considered, such as contact headers and via headers. A message property that can be used to capture a contractual relationship and thus trigger a rule module is referred to as a rule trigger (RMTrigger).

If a SIP request message arrives in a SIP server should at least one of the From or Request URI message properties Specify participants who have a contractual relationship with one the network operator of the SIP server Has. The message properties of From or Request-URI can be one Domain name like netopX.com, or an IP address from one of the network operators of the SIP server, such as 123,123,123,000. Also included the From or Request URI has a subscriber identifier, such as a Name or phone number. This is in the SIP URL or TEL URL included. The SIP URL also has parameters such as "transport-param", "user-param" and "other-param". These parameters can Include information for a network operator is specific, such as the IMSI, to subscribers a mobile terminal and terminals to identify.

Under Use e.g. The above properties can have a SIP event on one unique network operator, if a number of requirements fulfilled are, e.g. if each of the network operators of the SIP server has a unique domain name has, like netopX.com and netopY.com, and if they are different Have IP addresses. If they share the same IP address, can suspected relationship resolutions be ambiguous, since the message properties of the From and Request URI can contain an IP address and not a domain name.

service provider a third party to upload / register service applications to the SIP server a contractual relationship with the network operator that is captured can. For example, The service provider may assign a assigned value to a third party ID received from the network operator with which the service provider a third party has a contractual relationship. If the network operator a domain name has, e.g. netopX.com, and an associated IP address, may be the service provider assigned a third page with a unique name partyZ Receive IDs that follow a naming convention, e.g. "PartyZ.netopX.com". Now you can From and Request URI are matched to relevant rule modules. Because both netopX.com and partyZ.netopX.com in one event should be called netopX.com in either the From or Contains request URI, they should have different explicit ordering priorities. It is understood that other naming conventions are being introduced instead can.

It will be understood that the order priority and rule module hierarchy mechanisms may be applied independently or in combination with one another, as in connection with 12 has been described.

13 shows an example of the flow of SIP messages and instruction sets according to an embodiment of the invention. The message parser 1304 converts the original SIP message 1306 into an original SIP message object 1303 , This is used to start the initial rule module 1301 and therefore the first sequence of service applications. If a rule module 1301 in the standard drive 1302 is loaded and executed, one or more actions are achieved, depending on the signaling message object 1303 that from the message parser 1304 was received and based on its rule module 1301 has been identified, such as in connection with 12 described. When an action is reached, the service application becomes 1305 which is associated with the action, ie it is activated, possibly with parameters and possibly access to the entire signaling message object 1303 that triggered the application. The access privileges to the entire signaling message depend on the functionality and scope of the service access API used, eg Cgi API versus OSA API, as well as the privileges of the owner of the rule module 1301 and the privileges of the called service application 1305 from. The initial signaling message object 1303 represents the entire set of message properties that are in the original SIP message 1306 embedded, which can include multiple media types. The called service application 1305 performs some processing based on the signaling message 1303 through and gives the result 1307 to the variable speed drive 1302 back. This result is referred to as the instruction set, since it may potentially contain multiple instructions, eg, CGI instructions, OSA API instructions, etc. When multiple services are called based on a signaling message, the rule module processor will come in multiple instruction sets. This set of instruction sets is referred to as the "instruction set basis".

The standard drive 1302 and the application execution engine determine what instructions to the SIP server default behavior 1308 to convey. The instruction set may be filtered based on privilege and feature interaction resolution prior to the SIP server default behavior 1308 what is the instruction set further with a default SIP instruction set 1312 can unite. The resulting set of instructions is called the "resulting instruction set". The resulting SIP message object (s) represents the actual SIP messages to be sent downstream or upstream. Therefore, this results in one or more resulting SIP message objects 1309 leading to the message converter 1310 then send them to one or more SIP messages to be sent 1311 transformed.

14 illustrates a mechanism for managing multiple instruction sets in accordance with a preferred embodiment of the invention. According to this embodiment, an event context is an illustration of a SIP message object, but may include additional information, such as feature interaction information as well as the MIME types included in the message body of the SIP message. The original event context 1401 represents the original SIP message object 1402 , The current event context 1403a -B is an event context based on the instruction set provided by the service applications 1404 - 1405 is generated. At any given time, a service application is in control of the current event context. Even if multiple service applications run concurrently and apply control to handling the transaction, only one of them has control of the current event context at any one time. In the example of 14 become two service applications 1404 - 1405 shown. Initially has service application 1404 the control over the current event context 1403a , If the application 1404 has completed its processing, control over the current event context becomes the service application 1405 to hand over. At this point controls service application 1405 the current event context 1403b ie she has the right to read and write him. In one embodiment of the invention, other service applications may have the right to view the current event context 1403b to read.

Therefore, triggers of subsequent service applications are based on the current event context. The current event context is also purged for potential feature interaction issues so that subsequent invoked service applications can rely on it. When control is passed from one service application to the next through the call mechanism provided by the rule engine, ownership of the current event context is passed. In this way, when all service applications have been invoked and their instructions applied, the final resulting event context will be 1406 reached. Thus, the resulting event context represents 1406 the resulting SIP message object (s) 1407 , It should be noted that this mechanism does not preclude parallel processing as the service applications 1404 and 1405 can be executed in parallel. However, according to this embodiment, a sequence of updating the current event context is enforced.

It It is further noted that a service application requests to can split several goals. This leads to the generation of several current event contexts.

15 illustrates a tree of cascaded chains of service applications in accordance with an embodiment of the invention. When services are run on different SIP servers and apply control to a session, they provide a natural ordering of services, even if they do not know each other. This order can be said to be upstream or downstream. A downstream policy is the ordering of services as they are called downstream from the original client to the destination server. An upstream order is the order of services because they are invoked upstream from the destination server to the original client. When services that apply control to an instance of a session are invoked in a given order on the same SIP server, the services may be assumed to be cascaded according to the same ordering principle. This ordering principle is called cascading services, and the chain of services is called the cascaded chain of services.

If When a request is received, a service becomes all the more likely to be based called on this event, the more logically upstream he in the chain of cascaded services is considered. If an answer is received, the service will be based on this event rather, the more logically downstream it's cascaded in the chain Services is considered. Therefore, the applications are treated as if they were triggered on different hosts.

This Model is conceptually simple and looks natural Algorithm for resolution conflicts between the instructions of multiple service applications in the same SIP event.

• 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.

When a SIP event is received, the actions are performed in order of priority in the following manner:

• 1) Control is passed to the first application.
• 2) Any response from the first application is received.
• 3) Control is passed to the second application.
• 4) Any response from the second application will be received, etc.

If however, the first application completes the request, becomes the second Application not called.

On This way can make a decision about whether to have a subsequent application depends on the output of the previous application. Of others are instruction priorities associated with actions stand by default according to the cascading Arranged principle.

If An application splits a request, there is no simple chain of cascaded services, but rather a tree of cascaded ones Services. This is referred to as the "request tree". One Request tree represents a number of cascaded chains of applications. Every path from The root of the tree to one of the leaves represents a cascaded chain.

15 shows an example of a request tree where a service application APP1 is implemented by the rule module execution module (RMEM). 1501 with the original event context called OEC as an input. When the control is transferred from the application APP1 to the subsequent application APP2, the application APP2 obtains control over the current event context EC2. The application APP2 splits the request, creating event context EC3 and event context EC4. A lower priority action invokes APP3 application because of one or more properties in EC3 event context. Another lower priority action invokes another APP4 application because of one or more properties in the event context EC4. This results in a tree-like structure that is the trail of called applications. In this tree, the branches are representations of event contexts. The nodes are representations of triggers. The root of the tree is the original event context OEC. The leaves of the tree are the resulting event contexts REC1 and REC2.

If there are no more actions in a rule module, all current event contexts become the rule base processing procedure 1502 recycled. This procedure may call another rule module which will build more of the request tree. As a result, the tree with many nodes and branches can become quite large depending on the services being triggered.

It It is noted that in some cases an application an asynchronous feature instruction to the service support environment, i.e. not related to an existing transaction. In this case, the application has started a new transaction and is considered in the root of a new cascaded chain tree to be.

Around Allowing parallel processing of services may be the service support environment for simultaneously transferring the control to more than one Service capable be. This is not inconsistent with the cascaded service model, as the instructions of the parallel services called in the Order of cascading should be applied. If the stromabwärtigere Service before the upstream Service answers, the rule drive is waiting for the upstream Service responds before it can convey the instructions. These Instructions are conveyed as if the services were after the others would be called. The administrator should be capable be to specify if a group of actions in this way and should be applied simultaneously.

16 shows the software components of a variable speed drive according to an embodiment of the invention. The rule base processing procedure 1601 calls the rule modules 1602 that is usually base 1603 stored in the correct order. The rule module processing procedure 1604 executes the rules in the rule module. The service interaction module 1605 covers a lot of functions 1700 including enforcement, feature interaction, privileges, and rights. The functions 1700 be in contact with 17 described in more detail.

If a SIP event is to the rule engine in the form of an original event context 1609 is reported, the rule base processing procedure 1601 executed to find the correct rule modules and execute them in the correct order. The rule base processing procedure 1601 directs the rule modules that are to be processed and the original event context 1610 to the rule module processing procedure 1604 further. The order of the rule modules, together with the order of the rules within each rule module, determines the order of patterns and actions 1606 - 1608 generated by the rule module processing procedure 1604 are processed. The actions call corresponding service applications 1611 - 1613 on. If service application 1611 The original event context is called the current event context CEC1 to the service interaction engine 1605 which, in turn, passes the event context EC1 to the service application 1611 passes. The service application 1611 leads to a lot of feature instructions 1614 An update of the current event context by the service interaction module 1605 cause. The resulting current event context 1615 becomes the rule module processing procedure 1604 returned. The service applications 1612 and 1613 are called in a similar manner, resulting in corresponding instruction sets 1616 - 167 leads through the service interaction module 1605 in corresponding current event contexts 1618 - 1619 be converted. During this conversion, the service interaction module runs 1605 Authorization checks by, and if a service application 1613 an unauthorized instruction set 1617 returns, the unauthorized instructions are not converted. Therefore, the current event context is different 1619 not from the incoming event context 1620 , Preferably, the service application is informed of this error 1621 , It should be noted that a service may result in the generation of multiple current event contexts, as associated with 15 and 18 is described. When a rule module processes the patterns and actions 1606 - 1608 has finished, will be the final set of current event contexts 1622 to the rule base processing procedure 1601 returned. Subsequent calls to rule engines will depend on this set of current event contexts. It is noted that a service application can arm / disarm events and triggers for future events, as described in greater detail below. Therefore, a service application may further request a sharpening request 1623 hand back.

17 shows steps performed by the service interaction module between the processing of the rule module and the processing of the service application in the embodiment of FIG 16 be performed. This functionality 1700 includes feature interaction management and privilege checking, which is provided by the rule engine 1702 and the application execution drive 1703 is carried out. If the call command and the current event context are CECa from the rule engine processor 1601 receive the privileges of the rule module in step 1704 checked. The privileges of the rule module are specified in an access control list ACL2 associated with the rule module. If the rules engine has the privileges to issue invocation commands, send in step 1705 the standard drive 1702 the call command to the application execution drive 1703 via the application execution drive manager (not shown). It may only be necessary to be part of the current one. Event context to the application execution drive 1703 to send, as indicated by f (CECa).

In step 1706 converts the application execution drive 1703 the received event context f (CECa) into a suitable data format for the service application 1707 which is to call. This can include conversion to a suitable namespace for calling this service application. Furthermore, the application execution drive checks 1703 in step 1708 Privileges and rights. An access control list ACL3 associated with the service application 1707 can communicate the privileges of the service application 1707 to access the value of f (CECa) or a part of it. Furthermore, the rule module has access to the service application 1707 depending on another ACL4 ACL that is also associated with the service application 1707 communicates. If access is granted, the service application becomes 1707 in step 1709 and relevant parts of the event context g (ECa) are provided as an input. Then there is the service application 1707 the controller to the variable speed drive 1702 about the application execution drive 1703 by sending the instruction amount 1710 or an internal representation of the instruction set. In step 1711 become privileges and rights of the service application 1707 to give these instructions, checked, for example, based on an access control list ACL5 associated with the service application 1707 communicates. If the service application 1707 the privilege has to give these instructions, the instructions are converted from the internal representation (step 1712 ), and the converted instructions 1713 are forwarded to the rule drive. Furthermore, any arbitrary sharpening requests 1716 forwarded. In step 1714 Possible feature interaction problems are resolved with previously issued instructions from previously authorized and called service applications. This resolution is based on whether previously invoked applications have protected message properties in the current event context. The next current event context, CECb, is generated and passed to the rule engine processor 1601 returned. Finally saves in step 1715 the rule drive information about the called service in the memory, eg by building the request tree, in conjunction with 14 is described. The request tree is used in conjunction with reporting future events.

As previously mentioned, are some services, e.g. Monitoring applications, at future Interested in events. To rule over this interest in future To notify events, the service application must post event reports ask what is also called dynamic arming for event reports becomes.

According to one preferred embodiment The invention is dynamic arming of transaction events tied to the processing of a SIP transaction, which is timed is bound. Transactions can typically from a few milliseconds to a few Take minutes, depending on the configuration of the SIP server. Because dynamic arming of Transaction events only on the lifetime of a transaction is true, this type of arming is not permanent and will defused implicitly, when the transaction is completed, thereby providing a faster mechanism is provided. If an application fires events, the Affecting the transaction in which it was triggered retains the application their place in the cascaded service model. Answers will be all Applications reported that have spiked them, starting with the leaf of the tree, i. the most downstream application. During the Lifetime of a transaction, the request tree exists in the store of the standard drive. Subsequent events that affect the same Transaction, are thus related to the request tree. Events related to the request tree may be from Applications, from downstream Servers and upstream Clients come.

Events from upstream Clients enter the request tree at the root. This means that they are first reported to the application at the root of the tree. This application can complete or redirect the event in which Case it is not sent further in the original tree, but instead a new request tree can be established. A request can also forwarded to all the same goals as the original request Need to become, or the request may need to be sent to one of the destinations, too which the original one Request was forwarded. Enter events of applications the request tree in the appropriate node. Events from downstream servers enter the request tree in one of the leaves.

This leads to the mechanism of request tree traversal in which the rule engine remembers the order in which applications were invoked, ie the request tree. It is an advantage of this embodiment that it provides a clear rule for the order in which events are reported within the context of a transaction. The clear rule is the cascaded service model, which is a conceptually simple rule that can be easily understood by administrators and application designers. This also simplifies the API over which the application execution engines add rules to the rule base. To be able to focus on DELETING a specific branch in a rule module may just arm it to clear the given call section.

It There are several ways to implement the request tree traversal.

For example, The rule drive can do this traversal by using the VIA header and reach branch parameters. In fact, this would create a disconnected one Instance of the rule drive every time the destination address is changed by forwarding the request to the SIP server. DNS lookup, that happens through the sip stack would then determine if the Request returns or not to be processed by the server a second time. If a request is received from the SIP server, it would treated as a new request. The variable speed drive should have a mechanism to ensure that services, e.g. those in the FROM field can not be retried.

Alternatively, in a preferred embodiment, the event is handled in the host for the entire request tree, ie including all forwards, until all leaves of the request tree represent destinations elsewhere in the network. This embodiment has the advantage of being more efficient as fewer instances of signaling state machines and manager classes are required. For example, the request tree may be implemented by instantiating a node object for each trigger of an application, which may have pointers to the previous and next nodes in the tree. The following pseudo code snippet shows how building a request tree can be incorporated into the rule base processing and rule engine processing algorithms. The idea is to connect each event context to a RequestTreeNode. This is the RequestTreeNode in which the event context was created. Each node is either the root of the tree or it is associated with an action execution:

• – 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.

Considering the model of logical cascading service applications, the following two general rules for the service execution environment can be formulated as follows:

• - Events that move upstream should first be reported to the logically most downstream applications.
• - Events moving downstream should first be reported to the most logically upstream applications.

The logical cascaded order of services is maintained When event notifications are distributed to the highly complex and not manageable situation to prevent events in one Any order of cascaded services can be reported.

Preferably The applications which will cause such events to be in Processing point 1 or 4 and its partial processing points. Preferably, the network operator may be in the rule list for processing point 4 Specify a point where the dynamically armed triggers should be reported. This means that the logically cascaded Chain of services for the request is made, maintained, and new services be triggered either before or after this chain. The same Rule may apply to subsequent requests that relate to one refer to an existing transaction. This time it will be in the processing point 1, that the administrator can specify when dynamically spiced Events are to be reported.

alternative or additionally another type of arming can be used, which is considered as dynamically armed trigger is referred to as rules be added to a suitable rule module in the rule base. Dynamically armed triggers see a less elaborate mechanism in the game Meaning of processing power and execution memory for reporting of events that do not affect the transaction in which the application was triggered. Preferably, these requests should stored in a persistent store after event reports are, i. they become rules in the rule base. These rules can be through Specify a drain timer to be non-permanent, or permanent be. In the latter case, the service application should request Explicitly defuse according to event reports to remove them. Alternatively you can she also in a mode "once report, then "defuse". If no expiry time is specified, a default time, e.g. 1 hour to be applied to the rule. When this time has expired, the rule will be deleted. This has the advantage that prevents the server from running out of data storage capacity.

Preferably Trigger rules are added to a rule engine for which the application has the privileges and rights to update. It usually gets the same Rule module from which the application was triggered. Where exactly in the order of priority within a rule module these rules are added can be determined by an implicit rule priority order, i.e. an integer that represents where the rule is within the existing rule module should be placed. If first one Added SERL script the rules are ordered in the order they are placed in appear in the script. If there are N rules, stand the whole Numbers 1 through N implies the rules. A rule can be deleted by referring to these numbers. A rule can be added by referring to the rule after which the new one Usually should be placed. This has the advantage that the amount of data that needs to be exchanged when a rule is a large rule module added is reduced.

If no position is specified, then the control module drive follow the following algorithm when adding these triggers: Search the rule engine for the same property pattern as in the new rule. If a pattern is found, look for any partial pattern, etc. If no partial pattern found will, paste usually the highest as the rule priority in the included list of actions. If no similar Pattern is already in the rule module, paste as the first pattern. This Algorithm provides a logically advantageous placement rule in front. He represents e.g. sure the actions for the caller where TARGET = FROM is NOT to be mixed with actions for called party, where TARGET = RequestURI. It also means that rules that are added last, also the first ones are hit upon when an event happens. This is the simplest default behavior.

It may be possible to indicate whether a trigger rule is permanent or automatic deleted should be as soon as the event is reported. Which type of Rules an application can dynamically add can be used with the privileges and rights linked which are assigned to the application.

In another alternative embodiment becomes the cascaded request tree only for the lifetime of an event maintained. In this case, then, if the last application in the chain has finished processing and the SIP event is sent, the cascaded chain no longer relevant. Until this Point can it for the control drive useful be to keep a representation of the cascaded chain in memory. This is because applications can run on separate servers and It may take some time to respond to the call. During the Control drive waiting for a response, may be an earlier application in the chain delete the request. If this happens, the variable speed drive becomes the application execution drive the application he is waiting for. This means that yourself the governor should remember what the next application was in the chain. By the time the SIP event is forwarded was, all applications in the chain should be sharp-set rules for the Have events for which are of interest, so there is no longer a rule for the Regelantrieb Need to remember the cascaded chain. The advantage this solution is that the variable speed drive itself is easy. He reports simply events based on rule modules in the relevant Processing points. This solution however, it is complex to administer and places the complexity of one Order of events into the applications, i. the applications have to decide in which priority position the rule should be added in a rule module.

18 illustrates the tree structure of the processing of rule modules according to an embodiment of the invention. When an event is received, rule base processing unfolds a processing pattern called the rule base tree. When a request in the SIP server corresponding to a original event context 1801 the associated subscribers can be the originating page (ie, caller) and / or the terminating page (ie, called party). The caller is identified by the From header field. The callee (or current callee) is identified by the request URI. The From header field and the Request URI should uniquely identify a subscriber in the SIP server where these subscribers have a contractual relationship with the network operator and service providers. Following the cascading principle are the initiating services 1802 before final services 1803 even if the originating and terminating pages are in the same host. You can also call a third category of services. These are forwarded the services by (forwarded-by) (not shown). This category of services is invoked if a request is forwarded to a new destination belonging to another subscriber. In this case, initiating services may have to be invoked on behalf of the caller. For each page, the services are called based on the location of the rule modules, as they are in the different processing points 1804 - 1809 are placed. For each processing point, the sets of rule module priorities become 1810 - 1814 examined for a match. Within each priority is at most one rule module 1815 - 1817 called. A rule module 1817 however, can be the root of a rule module hierarchy 1818 be, as in connection with 12 described. For simplicity, such a rule module hierarchy may be considered as a single rule module. Therefore, the function of rule module processing 1601 , the functions 1700 the service interaction module and the service applications 1819 that are called by the rule modules are considered to be a leaf in the rule base tree. Based on the current event context CEC becomes the rule engine 1817 called and there is a resulting event context REC back. This resulting event context REC is considered to be the current event context CEC for the next rule engine being invoked. If all the rule modules have been called and the last of them returned the resulting event context, then the resulting event context is the set of SIP signaling messages sent upstream and / or downstream in response to the original incoming SIP message.

The above processing structure used in 18 is further illustrated by the following example of a pseudo-code fragment:

It It is noted that a service application has the From header field or can change the request URI. Furthermore, you can the resulting From header field or the resulting Request URI belong to another participant, even unknown to the SIP server processing the event can be. If the resulting From and / or the Request URI a new but well-known subscriber in the SIP server is the services associated with this subscriber as well called. In this case, the rule base processing procedure recursively, resulting in a hierarchical structure of rule base trees leads.

To process a rule module includes the step to perform each action turn in priority order, whereby it is evaluated whether the enclosing patterns match the current one Match event context, and if yes, apply the action. The following is a procedure according to a embodiment the invention described in more detail.

The following pseudo code fragment provides a high-level description of an algorithm for processing a rule module:

wobei EC[] die Menge von Weiterleitungen des Ereigniskontextes ist. Falls sie leer ist, hat der Dienst die Anfrage oder Antwort abgeschlossen.Here, the enclosingPatternsTrue method returns a Boolean value that indicates whether the patterns that include the actions are true. The processAction method can be implemented as shown in the following pseudo-code snippet:

where EC [] is the set of event context redirects. If empty, the service has completed the request or response.

The Service application may also issue instructions that are not instructions are to forward the event context. These are in the above algorithm not shown. Such instructions can by the rule base manager.

When actions are performed in order of priority, the result of the action may be to change the current event context. After such an action, the processing of the current rule module continues. After executing the current rule module, further rule modules may be executed according to the rule base processing procedure. The lower priority order actions are executed only if the pattern (s) they include (t) match the new message properties (t) as specified by the current event context. This is illustrated by the following example of a fragment of a pseudo-script describing two actions that are included by two patterns:

The two actions are enclosed by two patterns that indicate that the actions should only be applied if the request is an INVITE and the requestURI contains the domain name xcorp.com. The first action invokes a user-supplied CPL script. If the user CPL script does not change the destination of the request, then called the default proxy behavior to locate the user and treat the request proxy. If the CPL script the goal changes, The default proxy behavior must be that the destination will resolve to another host not be called.

If the message property that triggered the rule engine changes so that she represents a new user, processing this Control module stopped. The purpose of this is that of rule modules can be thought of, processed on behalf of a single user to become. This simplifies rule module processing and script development.

19 illustrates the recursive processing of rule modules in a situation where service applications generate new event texts, according to an embodiment of the invention. The new event contexts can change the original rule modulus trigger, and in this case, new rule modules can be called recursively. For example, preferences for called parties of a subscriber, eg a CPL script, may forward the request to a new destination associated with another subscriber of the same SIP server. In this case, preferences should also be invoked for callers of the party being forwarded to, eg another CPL script.

As by the example of 19 Illustrates generates an initial event context 1901 a recursion of rule module calls when a SIP request message is forwarded to multiple new destinations associated with other subscriber accounts. In the example of 19 becomes the application 1914 through the control module 1903 triggered on behalf of a participant A. The rule module 1903 is through the original event context 1901 triggered. The application 1914 generates three event contexts 1904 - 1906 where the rule modulus trigger is in the two event contexts 1905 - 1906 has changed with new subscriber accounts. The event context 1904 is an updated event context, but it is associated with the same participant whose rule engine is initially running 1914 has called. In this case also the participant rule modules become 1907 - 1908 , each with the new event contexts 1905 - 1906 are called. control module 1907 calls again application 1915 on, the two new event contexts 1909 and 1910 Consequently, a tree structure is created in which the leaves of the set of resulting event contexts 1910 - 1913 correspond. Then, cause the resulting event contexts 1910 - 1913 the SIP server to send SIP messages upstream or downstream, or both. It is noted that the example of 19 shows a simple case assuming that the rule modules each contain only one action.

If the five applications 1914 - 1918 in 19 have asked about subsequent answers According to the cascading principle, responses from the logically most downstream application are first announced, to notify the resulting SIP messages. In 19 will be responses to the resulting event context 1910 first application 1918 , then application 1915 and finally application 1914 announced as through the line 1919 displayed. For the resulting event context 1911 is the appropriate sequence application 1915 and application 1914 as by line 1920 displayed. For the resulting event context 1912 is the sequence application 1916 and then application 1914 as by line 1921 displayed. Finally, for the resulting event context 1913 the sequence application 1917 and then application 1914 ,

20 illustrates a mechanism for enforcing access control in conjunction with rule modules according to an embodiment of the invention. Two types of access control are enforced. Access to rule modules should be granted only to authenticated and authorized pages, and access to features should only be granted to authenticated and authorized rule modules. According to one embodiment, this access control may be implemented by using so-called access control lists (ACL). Such a list may be an XML document, possibly embedded in the rule module or in the same directory as that, or otherwise associated with the rule module. Access control lists include access control rules. The access control list may enumerate any of the individuals or groups granted access to the rule module. The mechanism can also be used to explicitly specify privileges and rights of the rule modules, eg which service features the rule module can use. Therefore, it allows the administrator to manage privileges and rights of rule modules.

Of Further, the mechanism can be used to set privileges and Manage rights of service applications. If a participant enters Upload CPL script, it may be an associated Give rule module this service at the right time calls. In this case, the rules engine should have explicit privileges and rights have to do that. This can be done by connecting access control lists be managed with the CPL script. The mechanism may further used to privileges and rights of the service application to specify explicitly, e.g. which service features, APIs etc. can use the service application. Therefore, he allows the administrator Manage privileges and rights of service applications.

• 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.

Referring to the numbered circles in FIG 20 The following privileges can be checked:

• 1) It becomes an original event context 2001 sent to the rule module after proper authentication of subscribers (A is the caller, B the called). Rule modules and service applications are all authenticated, and given privileges and rights.
• 2) The rule base processor 2002 Attempts to control modules in the rule base 2003 accessing an authenticated subscriber A or B or both. The rule base processor 2002 should not be allowed to access rule modules that are in contact with other participants when this event is processed. The rule base 2003 can be located on a remote server, in which case the rule drive should authenticate itself.
• 3) If according to the access control list 2005 allowed, the rule base processor 2002 the loaded control module 2004 call, say, rule module 1, which is owned by A.
• 4) If according to the access control list 2006 allowed, can rule module 2004 try another rule module 2007 call that is associated with another owner B.
• 5) If according to the access control list 2008 allowed, the rule base processor 2002 the loaded control module 2007 call.
• 6) If applicable, according to the access control lists 2005 and 2012 allowed, can rule module 2004 try service application 2010 call, if allowed. The service application 2010 can according to access control list 2011 on the event context 2013 access.
• 7) The service application 2010 can be a lot of instructions 2014 which is returned to the rule module processor, if according to the access control list 2015 allowed.
• 8) The service application 2010 can arm / disarm events for events, as per access control list 2015 allowed.
• 9) The service application 2010 can try another rule module 2007 as the one she has called to give instructions, if according to access control list 2012 allowed.

Access control to rule engines can be enforced by the policy nodes in a rule engine. An example of a rule module access control list embedded in a rules engine might look like this:

These Directive (policy) could be applied to the entire rule module, in which case it determines that the subscriber Alice can call this rule module, they can do it but not allowed to read or write.

Such policy XML scripts may be embedded within rule modules, but may also be associated with data items. For example, the network operator may associate a policy XML script with the subscriber's policy module specifying the privileges granted to the owner of the policy module by the network operator. These privileges could specify the services or service features that will allow the policy module to invoke, as illustrated by the following example of such a service access control list:

It It is noted that a SIP server service support environment Further, it may be adapted to generate billing records, e.g. for content billing, Application billing, usage billing or the like. For example, can the records via logs provided by SERL scripts or CPL scripts, via library functions or service applications to be managed etc.

Of another implements a system, service triggering according to the invention implements, preferably security measures, to security and integrity of the SIP node, although subscribers and service providers a third party may be allowed, not just service applications but also instructions on how and when to call them are inclusive of any degree of feature interaction resolution. Possible security measures in declare the configuration of privileges and rights of rule modules, Service applications, namespace convention policies, authentication mechanisms, Authorization mechanisms, access protection, authentication and Validation of uploaded rule modules, logging and monitoring Etc.

It It is noted that the invention is primarily related to network services has been described. However, it is also applicable when used in end-user equipment to become.

Of Further, it is noted that the invention, although mainly in Connection with SIP described, as well as other signaling protocols can accept. SERL is not limited to services based can call on SIP events, but can be of any type a service application based on any type of event in the context of any type of business model. The invention can be applied services for any SIP-shared To manage knots. Using SERL scripts, services can called by nodes, the user agents, archivists, redirection servers or implement proxy servers.

Finally will notes that in the 3GPP architecture all subscriber data in the so-called Home Subscriber Server (HSS) to administer. On SIP-related Applications are called by a node that has a serving Call State Control Function (Serving Call State Control Function, S-CSCF). When a subscriber connects to a network, carries his user equipment (User Equipment, UE) performs a CSCF determination to obtain a suitable S-CSCF select. The S-CSCF registers with the HSS it serves upcoming participants.

Service triggers could then pass from the HSS to the S-CSCF in the form of service execution rules be transported in the SERL format. The HSS could also use the service execution rules associated with a subscriber to decide to assign another S-CSCF based on which S-CSCF has installed the correct services. Therefore, one embodiment of the invention may be used to allow the HSS to place the subscriber-based triggers in the correct processing point and priority, and thus in the proper priority order with permanent services installed in the S-CSCF. Therefore, a mechanism according to the invention may be embedded in the 3GPP IPMM domain.

Claims (27)

Method for managing a plurality of services ( 309 . 310 . 311 ; 1305 ; 1611 . 1612 . 1613 ), triggered by a message ( 1306 ; 1609 ) of a session log controlling a communication session, the method comprising the steps of - obtaining a number of rule modules, each of which has a number of execution rules ( 308 ; 401 . 402 ; 1606 . 1607 . 1608 ), each execution rule having a condition ( 403 . 404 . 405 ) for calling a service; - processing a first ( 1216 ) the number of rule modules, the processing comprising processing at least a part of the execution rules of the first rule module in a predetermined order, a first execution rule ( 1606 ), which causes a first service ( 1611 ), if the message meets a first condition, resulting in a first modified message ( 1615 ) leads; and a second execution rule ( 1607 ), which causes a second service ( 1612 ) is to be invoked as an input with the first modified message if the first modified message satisfies a second condition; wherein the processing of the first rule module to a first accumulatively modified message ( 1206 ) leads; Calling a processing of a second ( 1217 ) the number of rule modules, which provides the first accumulatively modified message as an input; characterized in that the first rule module has assigned to itself a privilege indicative of an authority to change a blocking flag related to a predetermined portion of the accumulatively modified message, the blocking flag specifying whether the predetermined portion of the accumulatively modified message passes through Services can be modified, which are called by at least the second rule module. Method according to claim 1, characterized in that that each rule module has a priority associated with it, which is an order indicating processing of the number of rule modules. Method according to Claim 1 or 2, characterized in that each rule module is assigned to a rule module owner ( 409 ), which is authorized to edit the rule module. Method according to any one of claims 1 to 3, characterized in that the step of invoking a processing the second control module further comprises the step of setting the inhibit flag includes a modification of the predetermined part of the accumulative to prevent modified message by services provided by the second rule module are called, unless the lock flag was marked as not set by the first rule module. Method according to any one of claims 1 to 4, characterized in that the step of obtaining a number of execution rules and the step of detecting a predetermined contractual one Relationship based on header information of the message; and selecting one Number of rule modules based on the contracted Relationship includes. Method according to any one of claims 1 to 5, characterized in that the step of processing the first control module ( 1216 ) further comprises the step of calling a predetermined third control module ( 1220 ). Method according to any one of claims 1 to 6, characterized in that the first and second control modules are based on respective first and second access control lists ( 411 ), specify the access rights to the corresponding first or second rule module. Method according to any one of claims 1 to 7, characterized in that the first and second control modules respective first and second scripts in a predetermined markup language include. Method according to any one of claims 1 to 8, characterized in that the message a first and a second set of attributes; the execution rules into at least a first and a second processing class ( 903 . 904 ) are grouped by execution rules according to respective constraints, the second processing class being constrained to modify only attributes of the second set of attributes; and the method further comprises the step of repeating the steps of processing the first control module ( 901 ) and call processing of the second rule module ( 902 In each repetition, the processing of the first and second rule modules is limited to execution rules of a corresponding processing class, and each repetition results in a corresponding accumulatively modified message used as an input for a subsequent repetition. Method according to Claim 9, characterized in that the processing classes are defined separately for execution rules which are determined by queries ( 607 ) and answers ( 608 ) of the session log. A method according to claim 9 or 10, characterized in that the first set of attributes signaling properties includes the message. A method according to any one of claims 9 to 11, characterized in that the processing classes predetermined Locations in a round trip message flow according to the session log. Method according to any one of claims 9 to 12, characterized in that the processing classes comprise a first processing class (P1) of execution rules, the signaling properties ( 702 ) of the message, a second processing class of execution rules (P2) containing a non-signaling message body content ( 704 ) of the message, and include a third processing class (P3) of execution rules that affect neither the signaling properties nor the non-signaling message body content of the message. Method according to claim 13, characterized in that a resulting modified message ( 703 ) is generated when all execution rules of the first and second processing classes are processed. Method according to any one of claims 1 to 14, characterized in that calling the first service further leads to a second modified message; and the method further the steps for processing subsequent execution rules with the first modified message as an input; and processing subsequent execution rules with the second modified message as an input. Method according to any one of claims 1 to 15, characterized in that the method further comprises the steps includes Storing information about which services are running and information about it, in what order the services are executed; Receive from the first service of a request to return a notification to the first service if a predetermined event occurs; to save the request relating to the stored information; and at Occurrence of the event Notify the first service according to the stored Information. Method according to any one of claims 1 to 16, characterized in that the execution modules are computer readable Scripts, and the predetermined order of processing the execution rules by the order of execution rules determined in the scripts. Method according to any one of claims 1 to 17, characterized in that the session on a number subscribers, including a caller and a called party; a service is adapted by a request from a subscriber to be triggered; and the method further comprises the step of calling includes services requested by the caller, before calling any service by the called party is requested. Method according to any one of claims 1 to 18, characterized in that the session log is a session initiation protocol is. Method according to any one of claims 1 to 19, characterized in that the communication session a Multimedia session is. Method according to any one of claims 1 to 20, characterized in that the execution rules are adapted, to be dynamically updated. A data processing system comprising a service execution environment module ( 201 ; 301 ), adapted to a variety of services ( 309 . 310 . 311 ), which are triggered by a message of a session log that controls a communication session; the data processing system further comprising a storage medium ( 307 ) adapted to store a plurality of rule modules, each of which comprises a number of execution rules, each execution rule specifying a condition for invoking a service; and the service execution environment module has a rule engine module ( 303 ) adapted to - interrogate a number of rule modules; - processing a first of the number of rule modules, the processing comprising processing at least a portion of the execution rules of the first rule module in a predetermined order, a first execution rule causing a first service to be invoked if the message satisfies a first condition leads to a first modified message; and a second execution rule that causes a second service to be invoked with the first modified message as an input if the first modified message satisfies a second condition; wherein the processing of the first rule module results in a first accumulatively modified message; and - a processing of a second ( 1217 ) invoking the number of rule modules providing the first accumulatively modified message as an input; characterized in that the first rule module has assigned to itself a privilege indicative of an authority to change a blocking flag related to a predetermined portion of the accumulatively modified message, the blocking flag specifying whether the predetermined portion of the accumulatively modified message passes through Services can be modified, which are called by at least the second rule module. Data processing system according to claim 22, characterized in that the control drive module is adapted to a predetermined one Standard design specification language to interpret. Data processing system according to claim 22 or 23, characterized in that the rule drive module further comprises a rule base processor module ( 1601 ), adapted to query the execution rules; and a rule module processing module ( 314 ; 1604 . 1605 ), adapted to process the execution rules. Software program comprising code means, adapted, when executed in a data processing system, the steps of the procedure from any of the claims 1 to 21. Software program according to claim 25 in that the software program is on a computer readable medium personified is. A record comprising a rule module for use in a method of any one of claims 1 to 21st