JP3982691B2 - Service triggering framework - 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.

Description

  The present invention relates to management of a plurality of services related to a communication session, and the communication session is controlled by a session protocol that provides session information related to the communication session.

  There is an increasing demand for interactive communication sessions over the Internet, such as IP telephony, multimedia sessions, and video streaming. An interactive communication session is controlled by a session protocol, which includes a Session Initialization Protocol (SIP) that handles session initialization, termination, and modification between users. SIP does not care about the type of session that is the subject of the initial form, that is, it does not care about the substance of the SIP message, but rather about the management of the session. This includes, for example, determination of the location where the connection target user actually exists, distribution of the description of the visiting user's session, negotiation of a common format for describing the session, and the like.

  SIP is based on a request-response paradigm. For example, when initializing a session, the caller sends a request to the user that the caller wants to call, ie, the callee (callee). The request message is typically sent to the called party through several proxy servers that can respond to forward and deliver the message. Next, the receiving side transmits a response indicating whether to accept or reject the incoming call (invitation). This response is returned by following the route of the proxy server in reverse order.

  In addition to standard session management provided by a session protocol such as SIP, additional services can be implemented on the originating side, the terminating side, or any proxy server in between.

  Here, the term service means a unit of function, which is an output form that can be incrementally added to the base system and perceived by a subscriber, administrator or the like. Services such as call forwarding, voice mail, video conferencing, etc. are modules that are extended to a system for session management, such as a basic system such as a SIP system. The process of adding and enabling functions in the basic system is called feature placement.

  During a session, features can be triggered by certain events. The activation, i.e. the action of calling an application given at an event, is usually based on a contractual relationship between the subscriber and the service provider. Feature interaction occurs when one or more features are located in a service network and one or more services can be activated simultaneously for one or more users. Here, the term feature interaction means that one feature affects or changes to another feature. Feature interaction is an inevitable byproduct of module features. There are preferred feature interactions and undesirable feature interactions. However, if feature interactions are not managed properly, there is a problem that the overall behavior of the service network becomes uncontrollable. As a result, with the emergence of new technologies such as UMTS that demand substantial demands on service network capabilities, the problem of feature interaction has also grown as the number and complexity of service applications has increased. These services are developed separately, and the service provider resolves the default behavior actions of the communication protocol used and identifies how the instructions from these services should conflict It needs to be possible.

  When adding a new service to a service network, the behavior of multiple functions can be tested ad hoc or systematically, for example, to prevent feature interaction by testing a set of features. If instances of feature interaction are detected during testing or after deployment, the detected problem can be mitigated, for example, by redesigning one or more embedded service applications.

  The method described above requires a large amount of resources, especially as the number and complexity of services increases. Here, the above-described conventional technology has a problem that the number and complexity of service applications cannot be sufficiently measured.

According to the present invention, the above and other problems are solved by a method for managing a plurality of services activated by a message of a session protocol for controlling a communication session.
Obtaining a number of execution rules each identifying a state for invoking a service;
When the message satisfies the first state, a first execution rule for generating the first service to be called and outputting the first change message, and when the first change message satisfies the second state, Processing the second execution rule for generating the second service to be called in a predetermined order using the change message as an input.

  That is, a service call activated during a communication session is controlled by several execution rules processed in a predetermined order, thereby controlling the order of services to be called. Therefore, a mechanism is provided for launching applications based on service execution rules that avoids any and all behavior due to uncontrolled execution order. Also, by editing the execution rules, various deployment strategies can be easily implemented, thereby providing a flexible, fine-grained service deployment infrastructure, Provides great flexibility in ordering service chains that allow service network performance to be optimized.

  Here, according to the present invention, feature interactions are organized when performing a significant amount of complex services, such as adding, deleting, interrupting, restarting, or relocating services in a service network. A flexible service deployment infrastructure is provided that can be avoided.

  A standardization framework for defining service execution is provided that allows for the distribution of individual custodian service management issues, thereby providing a way to make several services scalable.

  An execution rule includes one or more states for executing one or more actions, for example, calling a service application.

  The term communication session refers to a communication session between users of a communication network, where the communication network is, for example, a TCP / IP network, a local area network, a wide area network, or the Internet. Examples of communication sessions include voice over internet, IP telephony, video conferencing, video streaming, and the like.

  The term session protocol means a protocol for controlling a communication session, in particular session initialization, termination and modification. Preferably, the session protocol is based on request / response messages sent via the nodes of the communication network between the related users of the communication session. An example of such a session protocol is the session initialization protocol (SIP). Other examples include H.C. H.323 protocol suite, related protocols such as MGCP and IPDC, SGCP, H.323 248 etc. are included.

The term service is a unit of feature that is incrementally added to the base system. The service not only provides services to subscribers, but can also provide other services, such as network administrator management. Examples of such services include call forwarding, call waiting, voice mail, statistical functions, callbacks, video conferencing, video on demand, anonymizer services, auto-replies, etc. The service can be realized using various technologies such as OSA, Java (registered trademark) , CGI, Perl, C ++, and XML.

  In the context of the SIP protocol, a service is an application, or some application that is logically executed on a SIP server or executed remotely on an application server that is communicated by a SIP server, for example CGI. -Script or CPL script. In the latter case, the service can be accessed and invoked using several standard naming techniques, namely SIP Request-URIs. Optionally, the service can actually register itself on the SIP server using, for example, the 3GPP OSA API framework. SIP services can be grouped into originating and terminating services, i.e. they are related to the originating and terminating sides.

  A service can be activated in a message header, message body, SPP or the like.

  The SIP server functionality provided to a service application is referred to as a service feature, such as access to some APIs, eg, server-side OSA API, statistical functions, or the like. The service feature can also be a service application that registers and provides services used by other service applications at the SIP server.

  A further advantage of the present invention is that it is a technology used independently for service realization, signaling protocols and platforms. Here, the network operator does not need to know in advance what type of service is deployed in the service network, thereby providing the resilience and scalability of the service deployment infrastructure.

  Scalability is needed as the number of custodians who want to register services they own increases considerably. Also, as the number of subscribers associated with the domain has increased considerably, scalability issues have become important. A service can be triggered by various types of events and can be retrieved based on a number of different states, such as source and destination address matching, time dependencies, or some other precondition. Also, the non-SIP associated with the service can be invoked, for example, when a condition that is a given point is satisfied. Various service technologies can be used, for example CPL. The SIP associated with the service can be invoked with a non-SIP event, eg, an HTTP event. Services that can be provided to 100,000 subscribers can generate 10,000 services from 10,000 services of a third party service provider. That is, the task for managing the service and the service interaction tends to be a complicated and too large task for the administrator who performs the management.

  According to an embodiment of the present invention, the above several execution rules are grouped into several rule modules, each rule module includes several executions, and the method further comprises: Process.

Processing a first rule module of the several rule modules outputting a first cumulative change message;
Calling a second rule module of the several rule modules that provides the first cumulative variable message as an input.

  That is, by grouping execution rules into rule modules, i.e., with a group of execution rules, the feature interaction problem is the same rule module between rule modules and the feature interaction between features invoked within the interaction. Divided into problems. As a result, an advantage of the present invention is that it provides a method for measuring the number of services and managing feature interactions. In particular, when different services are provided by different service providers, eg, different companies or different organizations within a company, a single provider has access to test all the services provided. It is not necessary or cannot be tested. Here, the effect of the present invention is that the analysis task of the feature interaction analysis can be divided according to the rule module and distributed to various providers. This further includes the ability to delegate service management costs to independent parties as the number of subscribers and services increases.

  The custodian who can request upload / registration and management of services on the SIP server can be an owner, a provider or administrator of the SIP server, a network operator, or the like. This can also be various types of retailers, such as virtual telecom operators, Internet service providers, etc. In addition, it can also be various types of service providers such as, for example, application service providers, content service providers, service / feature providers. Private organizations, private companies and subscribers can also be custodians.

  As a result, in accordance with the present invention, flexible, scalable, and scalable custodian contractual relationship management is achieved, including billing, arbitration, policy and security management.

  A further advantage of the present invention is to provide a modular structure of execution rules, thereby enabling embedding of service profiles for users, user groups, subscribers, etc. Furthermore, the modular effect allows the rule module to be reused, thereby further facilitating maintenance of the service environment.

  If a priority indicating the order of processing of the number of rule modules is associated with each rule module, the execution order of the rule modules is determined by simple parameters, which makes it easy for the execution order of the rule modules. And provides transparent control.

  If each rule module corresponds to a rule module owner that is authorized to edit that rule module, administrative rights to the rule module are easily established, which enables editing of the rule module, features within the rule module. It further facilitates the delegation of management authority such as interaction analysis.

  According to an embodiment of the present invention, the first rule module indicates an authority to change a lock flag associated with a predetermined part of the cumulative change message, and the predetermined part of the cumulative change message is called from at least the second rule module. Assign privileges that specify what will be changed by. As a result, a mechanism is provided to explicitly enable or prevent modification of individual attributes or groups of attributes of messages by subsequent services. Here, another service provides an effective tool for preventing feature interaction due to changes in the context of one service. This type of feature interaction is referred to as violating feature assumptions that can result in ambiguity or conflict in service behavior. Since the right to lock and unlock an attribute is related to a predetermined privilege assigned to the rule module, the network operator can detect privilege misuse and thereby unauthenticated Prevent actions and improve the security of the method. Privilege violations can be detected and resolved during operation, for example, by service notification and / or invalidation.

  According to a further embodiment of the present invention, the step of calling the second rule module is further called from the second rule module unless the lock flag is marked unset by the first rule module. A step of setting a lock flag to prevent a predetermined part of the cumulative change message from being changed by the service. As a result, by default, message attributes are locked against the next change when control moves from one rule module to another. Here, the second rule module can only change the message attribute that indicates that the first rule module is explicitly marked as unlocked, and this further Improve control of possible feature interactions and limit feature analysis tasks within individual rule modules. As a result, further scalability is improved.

  If the step of obtaining some execution rules further comprises the step of detecting a predetermined contract relationship based on the header information of the message and selecting a number of rule modules based on the detected contract relationship, A module and scalable method are provided that allow at least one of third party services and / or user defined services to manage support for. When a contract relationship is detected based on the header information, these third party or user-defined services associated with a given message can be identified based on the detected contract relationship.

  According to another embodiment of the present invention, the step of processing the first rule module further comprises a step of calling a predetermined second rule module. As a result, the rule module can call other rule modules, thereby creating a hierarchical rule module and further providing a powerful tool for improving the scalability and flexibility of the deployment infrastructure. An advantage of the present invention is that it allows delegation of one rule module owned by one owner to another rule module owned by another party. One party can call applications in the order that is appropriate by that party and can pass control to another party that can call various applications. The first party can subsequently regain control to check the output from the second party.

  When this delegation is performed, the first party can determine which message properties in the message sent to the next application can be changed by indicating whether it is not overwritten for the action.

  An advantage of the present invention is that it enables hierarchical delegation of administrative authority based on the ability to activate a rule module from within another rule module and lock message properties.

  If the first and second rule modules are associated with first and second access control lists that specify access rights corresponding to the first or second rule module, respectively, an access violation is detected and resolved. This further improves the security of the method.

  If the first and second rule modules are respectively composed of first and second scripts in a predetermined markup language, a simple language for describing the rule module is provided. Here, it is easy for an administrator to understand how a rule is expressed and what the meaning of the rule means, which makes it easy to extend the basic definition of the rule language to owning functions. Provide a mechanism. An example of such a language definition is XML.

  A further advantage of the present invention is to provide an extensible framework, i.e. by easily adding protocols, service technologies and message properties, for example when new methods are added to SIP. is there.

  A further advantage of the present invention is that it provides a scalable framework, i.e. the same way of expressing rules is possible in large ISP networks and small end user terminals, e.g. 3G cell phones. is there.

  According to another embodiment of the invention, the message has first and second attribute sets, and the execution rules are grouped into execution rules of at least first and second processing classes according to corresponding constraints. Here, the second processing class is restricted only to changing the attribute of the second attribute set, and the step of processing the execution rule further processes an arbitrary execution rule of the second processing class. Before, it includes a step of processing the execution rule of the first processing class. As a result, services are grouped into groups with predetermined behavior depending on which part of the signaling message is updated. Here, the service may rely on the first set of message attributes not being changed after execution of the first processing class. This further provides a mechanism for dividing the feature interaction analysis task into manageable subtasks. In the following, processing classes are also referred to as processing points. The set of attributes consists of message header information and a message body with actual session content. The attributes may be further divided into various types of header information such as, for example, signaling attributes.

  A further advantage of the present invention is that it provides a means for specifying how applications are allowed to interact.

  Preferably, processing classes are processed in a predetermined order for requests and responses, and apply to outgoing, incoming and “forwarded by” services.

  According to a further embodiment of the invention, the message has first and second attribute sets, and the execution rules are grouped into execution rules of at least first and second processing classes according to corresponding constraints. Here, the second processing class is limited only to changing the attributes of the second attribute set, and the method further includes processing the first rule module and calling the second rule module. A process for repeating the process, wherein in each iteration, the processing of the first and second rule modules is limited to executing the rules of the corresponding processing class, where each iteration is Output the corresponding cumulative change message used as input for the next iteration. As a result, a combination of divisions on the rule module having the concept of processing class is provided, thereby providing a more finely divided framework for dividing services according to the management ownership and constraints imposed on the service.

  If processing classes are defined separately for execution rules triggered by session protocol requests and responses, the division of services into processing classes is further divided according to the type of message, thereby Provide finely divided divisions.

  According to this embodiment, the processing class corresponding to the predetermined location corresponds to the predetermined location of the restart message flow according to the session protocol, thereby simplifying the analysis of the feature interaction.

  Preferably, the processing class includes an execution rule of the first processing class that provides the signaling property of the message, an execution rule of the second processing class that provides the non-signaling message body content of the message, both the signaling property of the message and the non-signaling message body content. The execution rule of the 3rd processing class which is not given is included. Here, the term signaling property means SIP and SDP message properties that can be matched to the rule module state for invoking a service.

  If a change message is generated when all execution rules of the first and second processing classes are processed, the effect of this method is that a response is returned without having to wait for the service of the third processing class. And improve.

  According to another embodiment of the present invention, the first service to call further outputs a second change message, and the method further includes processing the next execution rule with the first change message as input. And processing the next execution rule with the second change message as an input. Here, if the service returns various outputs, each of which is an input to the next chain of services, a tree of service cascaded chains can be realized.

According to yet another embodiment of the present invention, the method comprises:
Storing information about which services are being executed and in what order the services are being executed;
-Receiving a request from the first service for returning a notification to the first service if a predetermined event has occurred;
-Storing a request associated with the stored information;
A step of notifying the first service according to the stored information in the event occurrence.

  Here, an effective mechanism is provided for requesting notification of feature events by the service application, thereby enabling monitoring of the application or the like.

  If the execution module consists of a computer-readable script and the predetermined processing order of the execution rules is determined by the order of the execution rules on the script, the rule module administrator determines the service execution order and the notification order for the feature event A simple mechanism for controlling is provided.

  Preferably, the cascading order of services is determined by the order of execution rules within the rule module and the order of rule modules.

  Real-time service management is provided when the execution rules are configured to be updated dynamically, i.e. during operation of the service network.

The present invention further relates to a data processing system having a service execution environment module configured to invoke a plurality of services invoked by a session protocol message that controls a communication session, wherein:
The data processing system further includes a storage medium configured to store a plurality of execution rules, each of which specifies a state invoking a service,
Service execution environment module
-Search for some execution rules,
A first execution rule for generating a first service to be called and outputting a first change message if the message satisfies the first state, and a first if the first change message satisfies the second state A rule engine module configured to process a change message as an input and a second execution rule for generating a second service to be called in a predetermined order.

The present invention further relates to a service execution environment module configured to invoke a plurality of services activated by a session protocol message for controlling a communication session in a data processing system, wherein:
Service execution environment module
-Search for several execution rules, each of which identifies the state invoking the service,
A first execution rule for generating a first service to be called and outputting a first change message if the message satisfies the first state, and a first execution rule for outputting the first change message, if the first change message satisfies the second state, A rule engine module configured to process a second execution rule for generating a second service to be called in a predetermined order with one change message as an input.

  The invention further relates to a software program comprising code means adapted to carry out the steps of the method described above and below, when executed on a data processing system.

  The software program can be embedded in a computer readable medium. The term computer readable medium refers to magnetic tape, optical disk, digital video disk (DVD), compact disk (CD or CD-ROM), mini disk, hard disk, floppy disk, ferro-electric memory, electrical erasure. Rewritable read only memory (EEPROM), flash memory, EPROM, read only memory (ROM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), strong Includes magnetic memory, optical storage, electrified coupling elements, smart cards, PCMCIA cards, and the like.

The invention further relates to a method for managing the placement of services in a service network, which comprises:
-Identifying in a computer readable script some privileges and rights granted to the service in operation;
-Analyzing the possibility of occurrence of feature interactions;
Identifying a placement strategy for the service as a set of execution rules stored as a computer readable rule module script.

  The invention further relates to a data record comprising rule modules for use in the methods described above and below.

  FIG. 1 illustrates various types of feature interactions in a SIP service network. With the introduction of SIP, a new range of conversations and real-time services are emerging on the Internet. These services 101-105 can be managed by the end user terminals 106-108, the terminating user agent, or one or more intermediate network servers 109. The intermediate server 109 can provide value-added services 102-103 to at least one of an originating and terminating user agent, as well as related media client and server application (s). These intermediate servers can be proxy servers, redirect servers, dedicated application servers or user agents.

  A communication message transmitted between user agents is transferred by the intermediate server 109 via the Internet 110 or another communication network. The basic challenges of the intermediate SIP server 109 are to satisfy user service level expectations, maintain good network performance, and make new service definitions flexible and scalable. It is to be. Since performance is key issue, the architecture should be able to run on a SIP server for some services. The architecture should also allow the service to run on a remote server, as it may or may not be possible to run a service on a SIP server.

  Since there is a requirement for flexibility in service definition, the functionality of the SIP server should not be defined in advance. In particular, services can be continuously uploaded / registered from a variety of sources including service providers and subscribers.

  The owner of the SIP server can be an administrator and subscriber provider as well as a SIP server provider. This stakeholder is called a network operator, which can be a Telco or ISP type. The network operator can own the domain name of the SIP server and can provide service features to a third party service provider. The network operator installs service applications and rule modules on the SIP server to provide services to subscribers. In this case, the network operator operates as a service provider and service manager. The subscriber has a contractual relationship with the network operator to subscribe and receive subscriber services provided by the SIP server. A subscriber can have a service that allows the subscriber himself to upload service applications and rule modules to the SIP server. The subscriber owns a service for dedicated use, i.e. personalized services. For simplicity, all parties and subscribers other than the network operator (s) have a contractual relationship with the network operator, which is referred to as a third party service provider. Network server owners, network server providers, network server administrators, third party service providers and subscribers are considered as potential platforms for deploying services in intermediate SIP servers, which may be for some reason or another For reasons, it cannot or should not be deployed at the end user agent.

  There are standardized protocol (eg, SIP, SDP, SOAP), language (eg, CPL) and interface (eg, SIP-CGI, 3GPP OSA API) types that handle the control of various purpose services. The service also applies its own control via multiple protocols, network components, languages and interfaces. The SIP server should be extensible to support all of these purposes as needed. These service applications can be owned by various parties, which have various authentication levels and have various contractual relationships with the owner of the SIP server. A service application can add value to the default processing of (but not limited to) SIP requests and responses for various specific origination / session processing points under various conditions.

  The following example shows that it is assumed that multiple services are invoked based on a SIP event. Consider an example where a subscriber named Bob has a SIP subscription with a number of SIP providers named Telco. Bob has the kind of service he wants to exist in the network. There is a service currently in use, such as a terminal-independent service, or whatever Bob's terminal is. There are also services that give Bob security, privacy and reliability. Bob also does not want to manage his services. In addition, Bob described in Corp. Suppose you work for a company named This is what the service is called to manage incoming INVITE messages to Bob.

  Telco can own and manage SIP servers. Telco also provides SIP services to subscribers and acts as a third party service. Telco recognizes that Bob is a subscriber to the incoming INVITE. The first service is a Telco outgoing bearing application that checks if Bob is paying the latest bill. The second service is a service provided by Telco. This simply checks if the originating media codec can be handled by Bob's current location / terminal. If not, the application applies a media stream converter to the media stream flow (using third party outbound control). This transformation is transparent to Bob, and the application monitors the response from Bob and updates the session description as needed. The third service is Bob's own called party preference, for example a CPL script. This application monitors responses to proxied requests and forwards INVITE to multiple destinations based on it as much as possible. The so-called INVITE becomes Bob's current private SIP URL. In “no response”, INVITE is substituted for his wife Alice. In some cases, Bob wants to forward all private calls to his company's SIP URL. The fourth service is Telco's service, which is besafe. provided to Telco from a third party application service provider named com. This service checks the content type of the message body and provides a virus check if necessary, for example if an animated vCard is included. The fifth service is the ISP service, which provides multimedia advertisements for callees that refund Telco charges. If a session is established and it is a video conference session, Bob receives a small streaming bar information at the bottom of the video image. This service is a monitoring application and uses third party outgoing control. The ISP has a Telco SIP server account and can provide services directly to subscribers owned by Telco. Bob subscribes directly to ISP services without going through Telco. The sixth service is a service managed by the company Bob is engaged in. If the call is at Bob's current company's SIP URL, the call is forwarded to Bob based on data known only within the company's private LAN network. The final seventh service is for management purposes when Telco performs some logging (loggin).

  The above example illustrates the diversity of contract relationships associated with various services that are triggered by an event. The service may be owned by various custodians and may be implemented using various technologies.

  Various services deployed in the service network can interact with each other. These interactions may be realized between services related to a single user, multiple users, or between customer service and system service. Interactions can also be realized between services running on the same network component or on different network components. In FIG. 1, different types of interactions are shown, where single user-multiple component (SUMC), consumer-system (CUSY), multi-user-single component (MUSC), multi-user-multiple component ( MUMC) and single user-multiple component (SUMC) interactions.

  There are many causes for feature interactions, including “feature privilege violations” and “feature assumption violations”.

  Feature privilege violation: A feature privilege breaks when a feature is activated excessively or by an unauthorized party. A major problem that arises from violating feature privileges is excessive consumption of resources or unauthorized access to resources. This is usually unintentional or potentially malicious. If a feature privilege violation occurs, there will be a conflict between authenticated or unauthenticated features for access to the resource. If a feature is activated excessively or by an unauthorized party, it can subsequently cause a violation of feature assumptions. Obviously, there is a requirement to avoid violating feature assumptions.

  As described below, in accordance with the present invention, feature privilege violations are resolved by filtering on privileges, rights, contextually, contractually, stately, on access control lists.

  Context filtering relates to conditions that interpret events in a context. The need for this becomes apparent when managing network multimedia services operating on a centralized network.

  Contractual relationship filtering relates to the conditions that map an event to a feature set, which is the one imposed on the contract to handle the event. This issue is particularly important in the uncontrolled market, where not only can network infrastructure and session control service providers provide value-added services to subscribers, but third parties Have a legitimate right to provide

  Access control policy filtering compensates for the fact that only actions for which the event has been authenticated occur at the node.

  State filtering compensates for excessive activation of features when an event occurs and the activated feature is detected based on a contractual relationship and access privilege context. These states may depend on, for example, events, system properties, or network properties.

  Violation of feature assumption: An assumption about feature behavior is broken when the context of the feature is changed to another feature in a way that its function cannot work as intended. Violations of feature assumptions can result in ambiguity or behavioral conflicts.

  A feature is an action in which a service application to be executed can be visually recognized. The commands issued by the service application are issued to control the value added behavior of the SIP node, which is called feature interaction. However, many features may apply their actions to messages before control instructions are sent back to the SIP node. The control command or command set returned to the SIP node is called a service control command. This includes the resulting event context, i.e. the properties of the SIP message, which must be sent upstream or downstream in response to the original event context that launched the service application. Ambiguity behavior occurs when a service control instruction does not depend on a sequence in which a feature performs control via the current event context. Ambiguity commands are not required mutually exclusive.

  As an example, assume that the SIP message body includes a color image in the gif format. S1 is defined as a service application that is activated with the message body content in the gif format. Assume that S1 is a service application that converts from the gif format to the jpg format. Also, S2 is defined as a service application that is activated by the message body content in the gif format. Assume that S2 is a service application that converts a gif image into a monochrome image.

  Assume that S1 is a first application that is called and activated by gif content. S1 converts a gif image into a jpg image and writes it to the current event context. S2 is never called. As a result, the event context includes a color jpg image.

  Here, it is assumed that S2 is a first application that is called and activated by the gif content. S2 converts the color gif image to a black and white image and writes it to the current event context. Subsequently, S1 is called based on the gif content specified by the current event context. S1 converts a gif image into a jpg image and writes it to the current event context. As a result, the event context includes a black and white jpg image.

  Obviously, S1 and S2 result in ambiguous behavior, so the context of one feature is changed by another feature.

  Collision feature commands are commands that are mutually exclusive. Collision commands attempt to ignore each other. In this case, the collision command usually causes ambiguity behavior.

  Also, all feature instructions are a group of potential unapproved instructions unless they are reliably authenticated. Unauthenticated feature instructions can be malicious or buggy service applications. In either case, they should be detected because they can harm the safety and integrity of the system.

  The monitoring service application may have further problems with the problems already described above. The monitoring service applications can optionally issue asynchronous feature instructions to the SIP node if they are running continuously. If they are monitoring future events, they operate on these events and provide more feature instructions. If multiple monitoring service applications exist simultaneously, the feature instructions they generate may depend on the order in which they are notified about the event. This complicates the above problem.

  The detection and analysis of feature assumption violations is considerably more complex than the analysis of feature privilege violations. As will be described below, according to the present invention, means are provided for identifying solutions to ambiguity behavior, means for dividing feature interaction management into separate feature groups and administrative domains, and detection at run time. Simple default rules for resolving feature interaction interferences are provided. Violations of feature assumptions are resolved by feature ordering based on cascaded chain principles and conditional activation, and feature priority based on lock / unlock mechanisms. This will be described in more detail below.

  Another cause of feature interaction is network support limitations, such as protocol capability limitations or user interface limitations, inherent problems in distributed systems such as resource contention, feature co-ordination, timing, or non- Includes atomic operations, system security violations, fraud, tampering or eavesdropping messages, non-cooperative interactions with features with collision targets, etc.

In general, the three solutions to feature interaction are distinguished as follows:
Infrastructure: Infrastructure placement for feature placement integrates feature interaction management, ie, handles the causes of some defined feature interactions. The feature interaction is managed in the feature placement time, that is, the specification such as the rule-based policy, or both before (specification) and after (enforcement) during enforcement. In accordance with the present invention, the rule module script constitutes an infrastructure for placing features, which provides a framework for feature interaction management.

  Service generation: The design of features with respect to the cause of feature interaction, ie the detection of feature interactions during the design phase. Here, feature interactions may be managed prior to feature placement, eg, explicit feature interaction cause analysis, verification tests, and the like. In accordance with the present invention, conditions are imposed by service generation and feature placement strategy specifications.

  Runtime: An analysis of feature interactions when feature interactions occur. Even if feature interactions cannot be identified at all prior to feature placement, they must be detected at runtime, for example, by cryptographic certification, authentication and confidentiality, rule criteria policies, analysis algorithms, AI negotiation, etc. In accordance with the present invention, simple rules are provided on how feature interactions detected at runtime are resolved. These rules include access control list checks related to rule modules, alarm notifications and access violation analysis by obtaining violation rule modules other than operations, script checking for privileges and rights, and alarm notifications and operations. Includes analysis of privilege and rights violations by obtaining non-violating features.

  The general management process according to the present invention includes the following steps.

  1. Feature design specifications that are independent of other features: Services are designed and specified without considering interaction with other features. However, according to embodiments of the present invention, services are designed in relation to the following processing point model.

  2. Contract Negotiation: A party wishing to place a service on the service network negotiates with the administrator of the service network, where privileges and rights are granted for the service. In accordance with an embodiment of the present invention, privilege and rights scripts associated with the service are generated.

  3. Feature interaction analysis: Possible feature interactions are investigated based on experience and possible knowledge about some features located in the service network.

  4). Feature placement strategy specification: The author of a rule module that places a service obtains a management domain. Based on the feature interaction analysis and knowledge about the service, subscribers and users, a feature placement strategy is identified in the rule module script.

5). Feature implementation Verification test Feature introduction and validation 8. Feature runtime behavior and management 9. Feature Invalidation and Deletion According to the present invention, a framework for feature interaction management is provided as follows:-Analyze to specification rules by providing a simple language and framework that can easily understand the principle Makes it easy to map the stages,
-This feature grouping, which defines a clear boundary between feature groups, is known and unknown to a given analytic entity,
Provide rules for control handover between groups of features that are simple, ie easily understood. When handing over from one group of features to another, there is a mechanism to compensate that the next group of features will not interfere with the previous group,
-Simplify the analysis stage by identifying the processing points for event processing where the previous state is guaranteed and the application only allows the server to give certain instructions.

  FIG. 2 illustrates network elements included in a service environment SIP server architecture according to an embodiment of the present invention. The pre-stage SIP client 203 represents an arbitrary client such as a PC capable of SIP action, a wireless terminal, a pre-hop proxy, a SIP / PSTN gateway, or the like. The client generates a request for session service as an incoming request to the SIP server 202. The SIP server 202 represents a proxy, redirect, or dedicated SIP operable application server, and a service support environment 201 is realized here. Optionally, it may be any other SIP-enabled entity that invokes a value-added service, such as a user agent, a register, or the like. Services located in the SIP server service support environment 201 are defined by service applications, which include, for example, SIP-CGI scripts, rule modules, and service features. The SIP node 202 can perform handover control for the service support environment 201 by receiving an event. The service support environment 201 can subsequently call the associated service application according to certain filter criteria and based on the event. The service application returns a feature command or a command group. The service support environment 201 hands back control to the SIP node 202 together with a service control instruction for notifying the SIP node 202 how to process the event. The SIP node sends the request to the next SIP client 204. The response to the request is transferred from the next SIP client 204 to the previous SIP client 203 in the opposite direction via the SIP node 202, and if possible, activates an additional service. The next-stage SIP server 204 represents an arbitrary server, for example, a SIP-enabled PC, a wireless terminal, a next-hop proxy, a SIP / PSTN gateway, or the like. The server processes incoming requests. The remote server 206 executes the remote service in another service support environment, for example. For example, based on performance criteria, the service support environment 201 can initialize the processing of the remote server 206, for example, by using a request / response protocol. In this way, different categories of services can be invoked and managed by different hosts. The protocol used for the remote server may be a support request / response dialog that supports any protocol such as SIP, ICAP, HTTP, OSA, API, etc. The management server 205 executes management tasks in the service environment. This can constitute a service support environment 201 associated with the domain of the SIP node 202. Here, the environment of the service support 201 includes a SIP node, a service application, a remote host, and a management entity.

  FIG. 3 shows a system architecture of a SIP server that supports a service execution rule mechanism according to an embodiment of the present invention. The service support environment 301 implements a deployment infrastructure, ie how one feature interacts with another feature. Here, the service support environment 301 provides a function within the SIP server that supports the value-added service. The service support environment 301 includes a rule engine 303 that manages the rule module 307 stored in the execution rule base 307. The rule engine 303 further includes a rule module execution module 314 that can process the rule module. The rule engine can call the services 309 to 311 via the service execution engine manager 302. The service definition manager 312 provides a rule module management function. The SIP server further implements a SIP protocol stack 304 that includes a SIP default function 306 and a SIP message parser 305. The message parser 305 extracts a message property that supports the SIP protocol and can be interpreted by the rule engine 303. The management server 313 executes a management task on the service environment.

  An important mechanism for realizing the service arrangement policy according to the present invention is to make the specification of the arrangement rule the service execution rule specified by the rule module. The service execution rule specifies the state and action that need to be acquired if the state is satisfied. In accordance with the present invention, a programming language is defined that identifies these rules, which is referred to as a service execution rule language (SERL).

  The rule module 308 is managed and executed by the rule engine 303. The rules engine 303 is the main functional entity that implements the activation 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 and hands over the event to the rule engine 303. The rules engine 303 detects and loads the associated rule module 308 and processes them related to the received events in the correct order. Filtering includes contractual relationship detection. An event defines the context in which the rule module is processed, i.e. the context in which the state is evaluated according to the properties of the SIP message event. The rule engine 303 calls the corresponding action when the rule pattern matches a given message property. Based on the content of these actions, the rules engine 303 can issue a call instruction to the application execution engine manager 302 or another suitable entity in the service support system. The SERL script has no knowledge of the service, which is usually the knowledge that the service calls and manages other than the knowledge of how to call and manage features. The control command received from the called service application is passed to the SIP stack 304 when the latest rule module is processed.

  The rule engine 303 further manages information transmitted between different services. When an event occurs, an event context containing the relevant properties of the event is established in a standard way. Message properties have a name and a value. The value can be determined by the message. For example, an example of a SIP message property is as follows.

Name: sipRequest.Request-URL, Value: sip: bob@corp.com
Name: sipRequest.To, Value: Bob Smith <sip: bob@corp.com>
Name: sipResponce.Status-Code, Value: 301
Examples of SDP message properties are as follows:

Name: sdp.m, Value: video 48232 RTP / AVP 0
The rules engine 303 supports several internal APIs that can be accessed by interfacing with functional entities. These APIs include the following:

  -Message notification API, used by the SIP stack 304 for message notification from the message parser 305 to the rule engine 303.

  A rule base definition API, used by the service definition manager 312.

  -Used by the application execution engine manager 302 for handing over instructions to the rules engine 303 for service instructions API, service applications 309-311.

  -Used by the application execution engine manager 302 to request arming of triggers and transaction events for the arming API, service applications 309-311.

  Application execution engine manager 302 incorporates and manages several application execution engines 315 for various types of service applications, including, for example, OSA engines, CPL engines, CPL interpreters, CGI engines, and serverlets. There is an engine. This supports the interface introduced by the rule engine 303 and provides a mapping between the application API and the rule engine API. From the rules engine 303 perspective, all application execution engines 315 look like one entity, the application execution engine manager 302. The service definition manager 312 can further provide functions to the application execution engine 315.

  The API provided by the application execution engine manager 302 includes:

  Call API, used by the rule engine 303 for call instructions from the rule engine to the application execution engine manager 302.

  -Notification API, used by the rule engine 303 for notification commands from the rule engine to the application execution engine manager 302.

  The default SIP server action 306 has a function of a proxy server, a redirect server, an application server, or a general-purpose user agent. Furthermore, a register or IM & P function may be included. This provides an interface that can be accessed by the rules engine 303 to issue instructions. Optionally, the service application can implement SIP server behavior. Therefore, it is possible to realize a rule engine for calling only a part of the above-described functions in response to a service application request.

  The service definition manager 312 provides an O & M API used by the management server 313, service applications 309 to 311 and the SIP stack 304. The API provides functions for:

-New rule module and service application certification and authentication manual-Rule module and service application rights and privilege configuration manual-Rule module and service application loading manual-Rule module and service application start / stop manual-Rule module valid -Manual for validating service applications implemented using script language-Manual for deleting rule modules and service applications-Manual for listing rule modules and service applications and their status-Manual for changing rule modules Service The definition manager 312 further includes the above-described manual functions and additional functions. This additional function can provide an interface that supports some automated processing of at least one of the additional functions, for example, listing of available service features, obtaining and supporting at least one of the interface and service feature versions Registered execution engines and script languages such as JVM, CPL, Perl, etc., install / uninstall service features, start / stop service features, register service applications that provide services as features to other service applications , Service feature subscription, service feature invocation / termination, statistical operations such as "processor load monitoring" and "outgoing concentrated time zone", account operations , Start / stop of the account record, read, there is a reset, and the like.

  Here, the term service feature means a function provided to a service application. Service features are considered integrated into the service support environment 301 and the SIP stack 304. Both application execution engine manager 302 and service definition manager 312 provide service features to service applications 309-311. However, some of the features provided by the application execution engine manager 302 are processed through the rules engine 303 and the SIP stack 304.

  The service applications 309 to 311 are programs that are compiled or interpreted and operate in the service support environment 301 of the SIP server or operate on a remote server. These applications can be associated or not associated with the basic functions of the SIP server. Service applications can implement SIP server behavior. A service application can provide services to other service applications, i.e., they can be service features. For example, a service application can include several MIME type converters and can provide it as a service feature to other service applications. Other service applications can use this function to perform the service. Preferably, the service application should be movable between SIP servers and can run on a remote server. Service applications can be standardized via global or local naming conventions by using specific file paths to applications, etc., public standard APIs such as SIP-CGI, OSA ASI, HTTP, ICAP, CPL, servlets, etc. You can access the local namespace.

  Standardized mechanisms for accessing service applications are valid for third-party service providers.

  A SIP server does not need to manage remotely located service applications because the SIP server may not have knowledge of them. In this case, the SIP server or application execution engine manager 302 needs the location information provided by activating the information.

  The message parser 305 can interpret the received message, separate predefined elements as message properties, and generate actions that are enabled when appropriate. When an event occurs, a message object is established that includes related properties separated by message parser 305.

  Preferably, any supported protocol has a corresponding message parser. The parser may include a lower level parser corresponding to a lower level protocol, ie, a protocol that is incorporated into another protocol such as SIP. For example, a plurality of parsers that handle various types of media such as SDP, HTML, XML, and XHTML may exist in the SIP message parser. From the rules engine perspective, all parsers look like one engine. The API for message parsers should preferably be defined so that new protocols and content parsers can be added as modules.

  For any protocol supported by the service support environment 301, the interface between the protocol message parser and the rules engine includes:

A property group defined by a message parser, including the property name, the relationship with the message characterizing the property, and the ability of the action to change the property; a processing point where the rule can be validated. Alternatively, each functional entity in the service support environment can be located on a separate host that implements multiple servers, such as SIP, Web, WAP, I-Mode (registered trademark) , RTSP server and For example, there are multiple access application servers such as a database, OSA, Web, and SIP.

  For example, the rule engine 303, the application execution manager 302, and the service definition manager 312 can be arranged on their own hosts, if possible, hosts connected via IP. The interface between the rule engine and various servers can be standardized or dedicated. The interface between the rules engine, application execution engine manager, and service definition manager should preferably be dedicated and packaged. The interface between the service application server and the service support environment is preferably standardized, such as a database API such as OSA API, HTTP, SIP or some SQL-based API. It is clear that in such a distributed configuration, the further effect of the present invention can be obtained, which means that the rules engine not only has many types of events, eg, SIP events, but also HTTP events, SMTP events, It is possible to manage events such as media events such as Wap events, MPEG7 events, 3D virtual reality or game object events.

  Furthermore, referring to FIG. 3, the activation mechanism according to an embodiment of the present invention can be illustrated with a simple example, assuming that only one rule module is associated with an incoming event. Yes. In FIG. 3, the circled numbers refer to the steps of the following startup example.

  1. The SIP request is received by the message parser 305.

  2. The SIP message parser 305 generates a SIP message object. The rule engine 303 converts this into a SIP event context.

  3. The association rule module 308 is arranged in the execution rule base 307 based on the event context, the processing point, and the contract relationship. The mechanism of this embodiment will be described below.

５．起動が行われ、特定されたサービスアプリケーションＹ（３１０）が、呼出コマンドをアプリケーション実行エンジンマネージャ３０２に送信することによって呼び出される。 4). The rule engine 303 loads the rule module 308 detected from the execution rule base 307 to the rule module execution engine 314 and executes it. By way of example, assume that the loaded rule module contains rules that specify the following functions: activation criteria and call actions for service applications 310 and 311.

5). Activation is performed and the identified service application Y (310) is called by sending a call command to the application execution engine manager 302.

  6). The application execution engine manager 302 arranges the application Y (310).

  7. The application execution engine manager 302 loads the associated service application Y (310) into the application execution engine 315 and subsequently validates it for execution.

  8). The instruction obtained from the application 310 is returned to the rule engine 303.

  9. The rule engine 303 resumes the processing of the rule module and starts another application Z (311). The call command is given to the application execution engine manager 302.

  10. The application execution engine manager 302 arranges the application Z (311).

  11. The application execution engine manager 302 loads the associated service application Z (311) into the execution engine 315 that can execute the application and subsequently validates it.

  12 The instruction obtained from the application 311 is returned to the rule engine 303.

  13. The rule engine 303 resumes the processing of the rule module, and detects that there are no more rules to be executed by the rule module and that there are no more rule modules to be loaded.

  14 The SIP default action 306 merges the output from the rule engine 303 and the resulting default output and sends a SIP message to the message parser / converter 305.

  15. The SIP message is proxyed, for example.

  In the case of a plurality of rule modules, the above steps 13 and 14 may be selectively performed as follows.

  13. The rule engine 303 resumes the processing of the rule module and detects that there are no more rules that the rule module executes. The rule engine 303 searches for a rule module having a lower priority than the previously executed rule module.

  14 Proceed to point 3 in the above example. If it is detected that the rule module is executed as in the above example, another callable application, for example, application 309 is called.

  If the rule module or service for controlling the session is not installed, the rule engine 303 hands over control to the SIP server and designates empty output. The SIP server merges the empty output and the server default behavior 306 as much as possible, such as SIP-CGI that follows the default SIP behavior for registers, redirect servers and proxy servers.

  FIG. 4 shows the structure of a rule module according to an embodiment of the present invention. In accordance with the present invention, the rule module 400 is conceptually a tree of a number of service execution rules 401-402, each rule having a number of states 403-404 and 405 and a number of actions. 406-407 and 408 are identified and are required if the corresponding state is satisfied. In the following, the state is called a pattern. At the highest level, the rule module is further as follows:

  -Owner information 409 identifies the owner of the rule module, i.e. the identifiable party that has the SIP node of interest. This party may own multiple rule modules. The owner information may further include information on the contract relationship.

  -Protocol information 410 identifies the context for interpreting the rules module rules. Examples of protocols are SIP, SDP, HTTP, H.264. 323 etc. Preferably, these should define only one protocol per rule module. Otherwise, if some overlap, an ambiguity interpretation is given. For example, both SIP and HTTP have a content type header field.

  The access control information 411 identifies which party has the right to call, manage and read the rule module.

  The rule module may further have auxiliary information that provides further context information for the rule module and index information 414.

  The patterns 403 to 405 are expressions that can be evaluated with respect to the message property in the event context, and expressions that can be evaluated with respect to whether or not the rule matches in order to match the property in the context. Actions 506-408 may identify an application, a built-in service feature, a remote server, a load sharing host, or a next hop SIP server to be called. They can further identify action objects that have been downloaded and placed externally. Rules, states, and actions can have parameters that describe these behaviors, which are attributes of the tree node. The branches have a weight that indicates which branch should be processed first.

  Preferably, each rule module has a prioritized order of priority assigned to it, i.e. a priority order that identifies the sequence in which the rule module is loaded by the rule engine.

  According to an embodiment of the present invention, the nodes of the graphical representation tree are represented by XML elements. A branch from one node to the next node is represented by surrounding an element representing the next node (s) within the element representing the branching node. The weight of the branch is given by the order in which it is expressed by a script. This weight gives the order in which elements are processed when an event is received. In other words, the script is executed from the top to the bottom. That is, in this embodiment, there is no loop in the SERL script. Preferably, the format of the rule module is specified as XML DTD or XML schema.

  The effect of this embodiment is based on a standardized extended language for specifying a language.

  In embodiments of the present invention, policies can be associated with rules that specify authority and rights. Each node of the rule module can have an associated policy node and can include an access control list.

図５は、本発明の実施形態に従って、制約のあるサービスのセットへのサービスのグルーピングを示している。本実施形態に従えば、サービス５０１〜５０８は、フィーチャグループ５０９〜５１０のセットにグループ化されている。図５に示される例では、フィーチャグループ５０９はフィーチャ５０１〜５０４を含み、フィーチャグループ５１０はフィーチャ５０５〜５０８を含んでいる。各フィーチャグループに対し、ある制約が、そのグループのサービスに課されている、即ち、それは、予め定義されているタイプの命令を発行することのみ許容されている。フィーチャグループは、１つのフィーチャがフィーチャグループ内でどのように相互作用を行うことを許可されているかを特定しないばかりか、それらはグループ行動における制約を違反しない。フィーチャグループは、例えば、フィーチャグループを数え上げることによって、連続して順序が付けられる。図５の例では、フィーチャグループ５０９は、フィーチャグループのシーケンスのＫ番目のフィーチャグループであり、かつフィーチャグループ５１０はＫ＋１に数えられる。フィーチャグループの順序付けは、実行順序を課しており、そうすることで、フィーチャグループ５０９のフィーチャは、グループ５１０のフィーチャを実行する前に実行される。好ましくは、フィーチャグループの定義は、例えば、グループインデックスを特定することによって、あるいは直前及び次のフィーチャグループを特定することによって、あるいはその類を特定することによって、グループの順序付けの仕様を示すものである。好ましくは、フィーチャグループの定義は、更に、前の状態、即ち、フィーチャグループのフィーチャの定義が依存する状態の仕様と、フィーチャグループのサービスの行動に従う制約の仕様を示しても良い。ここで、フィーチャグループは、サービスが呼び出される場合に順序付けされたシーケンスを提供することによってフィーチャ相互作用の基本的なタイプを形式化する順序付けメカニズムである。それゆえ、このメカニズムは、フィーチャ相互作用の問題を、制約のあるフィーチャのセットにグルーピングするフレームワークを提供する。このメカニズムは、実際にはこれらのフィーチャグループ間のフィーチャ相互作用を解決する、これは、フィーチャグループの制約によって、あるグループから次のグループへ制御をハンドオーバする場合のフィーチャ仮定が判定され、かつ予め定義されるからである。グルーピングの利点は、フィーチャ相互作用解析の問題を、より小さく個別の問題に分解するメカニズムを提供する、これによって、この問題の管理をより容易にする。また、形式化された問題の部分は個々のパーティに委任することができるので、この問題をよりスケーラブルにする。フィーチャグループのメカニズムは、管理者及びサービスプロバイダに、サービスアプリケーションが呼び出されるべき処理時間中の異なるポイントにサービスアプリケーションをカテゴライズする機能を与える。 The following is an example of an instance of a rule module identified as a SERL script. :

FIG. 5 illustrates the grouping of services into a constrained set of services in accordance with an embodiment of the present invention. According to this embodiment, services 501-508 are grouped into sets of feature groups 509-510. In the example shown in FIG. 5, feature group 509 includes features 501-504, and feature group 510 includes features 505-508. For each feature group, certain constraints are imposed on the service of that group, i.e. it is only allowed to issue predefined types of instructions. Feature groups not only specify how one feature is allowed to interact within a feature group, but they do not violate constraints on group behavior. Feature groups are ordered sequentially, for example by enumerating feature groups. In the example of FIG. 5, feature group 509 is the Kth feature group in the sequence of feature groups, and feature group 510 is counted as K + 1. Feature group ordering imposes an execution order so that features in feature group 509 are executed before executing the features in group 510. Preferably, the definition of a feature group indicates a group ordering specification, for example, by specifying a group index, by specifying the previous and next feature group, or by specifying the kind. is there. Preferably, the definition of the feature group may further indicate a specification of the previous state, i.e. the state on which the feature definition of the feature group depends, and a specification of the constraint according to the service behavior of the feature group. Here, a feature group is an ordering mechanism that formalizes the basic type of feature interaction by providing an ordered sequence when the service is invoked. This mechanism therefore provides a framework for grouping feature interaction problems into a constrained set of features. This mechanism actually solves the feature interaction between these feature groups, because the feature group constraints determine the feature assumptions when handing over control from one group to the next, and in advance Because it is defined. The benefits of grouping provide a mechanism that breaks the problem of feature interaction analysis into smaller, individual problems, thereby making it easier to manage. Also, the formalized problem part can be delegated to individual parties, making this problem more scalable. The feature group mechanism gives administrators and service providers the ability to categorize service applications at different points in the processing time at which the service application should be invoked.

  FIG. 6 illustrates the grouping of services into a constrained set of services at the corresponding location of the service in a recursive SIP message flow according to an embodiment of the present invention. According to this embodiment, a feature group is associated with logical request / response recursive message flow positions P1-P6, which has certain preconditions that are guaranteed for the event context. Here, the service application is invoked based on constraints on whether this behavior is allowed at that location. These feature groups are called processing points.

  Six processing points P1 to P6 are normal groupings of services. Processing points P1-P3 and P4-P6 logically address the corresponding problem. The processing points P1 to P3 include services activated by the request 607, and the processing points P4 to P6 include services activated by the response 608. Logically, process points P1 and P4, process points P2 and P5, and process points P3 and P6 correspond to corresponding constraints.

  SIP messages can be broadly divided into two parts: signaling properties, i.e. properties related to SIP, SDP, etc., and content of the message body not related to signaling, such as gif, html, etc. Therefore, services that are activated by SIP events can be grouped into:

-A group to be embedded in the signaling property-A group to be embedded only in the content of the non-signaling message body-A group to be embedded in neither the signaling property nor the content of the non-signaling message body This includes three processing points P1-P3, Basic grouping of services to the groups 601 to 603 is performed. Similarly, in the response path, the corresponding groups 604-606 are associated with processing points P4-P6, respectively.

  Here, the term signaling property indicates SIP and SDP message properties that can be collated in the state of a rule module for calling a service. Therefore, the application that changes the signaling property may generate another application to be called, and may call another application one after another. The advantage of moving service application processing that does not change signaling properties to processing points after all changes to signaling properties have occurred is that the administrator can easily perform tasks in ordering applications at processing points P2 and P5. .

  In the embodiment of the present invention, the processing points P1 to P6 can be defined as follows.

  Processing point P1—Previous hop client request: A SIP request 607 from the previous hop client is received. For this particular request and a particular subscriber, no rule module has been invoked at any previous processing point. This processing point has a service that embeds SIP / SDP signaling properties of the message (s) obtained outside the message body content.

  -Processing point P2-Request content point: The signaling properties of the resulting SIP / SDP message (s) have been generated and cached, i.e. a part of the SIP message is being sent. Additional updates to outgoing / media control signaling properties should not occur unless explicitly authenticated. The service 602 called at the processing point P2 should not embed the SIP / SDP signaling property generated at the processing point P1. However, these can be other than the rules. For example, the service can embed SIP headers such as alert information, outgoing information, content placement, content encoding, content language, content length, content type and conditions. Great care should be taken if these signaling properties are changed at 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, and the like.

  -Processing point P3-Request batch point: SIP processing message (s) are generated and transmitted. No further updates to the processing message (s) can occur. The processing point corresponds to a service 603 that needs to be invoked but does not generate and output what is needed to process the request. These services only read the processing message (s) and cannot update it.

Processing point,
-P4-Previous hop server response -P5-Response content point -P6-Response batch point can be defined for response message 608, respectively, similar to processing points P1-P3.

  Alternatively or additionally, other processing points can be defined. For example, an additional processing point P0 (not shown) can be defined without any constraints on the feature, which is triggered at any event, ie upon receipt of both requests 607 and 608.

  Preferably, the additional processing point can be associated with one of the higher level processing points. For example, sub-processing points that can be defined for processing point P1 can be indicated by P1.1, P1.2, P1.2.1, P1.2.2, and the like. Preferably, only new processing points should be defined if the processing points define a logical group of services that can be beneficial to be invoked according to the identified previous state.

図７は、本発明の実施形態に従う様々な処理ポイントに属するサービス間の処理フローを示している。図６で説明した実施形態では、ＳＩＰメッセージの様々な部分を埋め込むサービスは、様々な処理ポイントにグループ化されている。これは、サービスを有効に処理するために利用することができる。着信メッセージ７０１のＳＩＰシグナリングプロパティを埋め込むサービスは、処理ポイントＰ１に含まれている。それゆえ、処理ポイントＰ１からの出力は、最終の発信／メディア制御命令７０２を有している。これは、直ちに、可能なＳＩＰサーバデフォルト行動とマージすることができ、発信ＳＩＰメッセージ７０３を用意するメッセージコンバータ７０５へハンドオーバすることができる。加えて、処理ポイントＰ２で呼び出されるサービスは、シグナリングプロパティがこれ以上変化することがないことを信頼することができる、例えば、これらのサービスは、最終的に生成された宛先アドレスに依存するサービスに信頼性を与えることができる。 The following table contains some example services, which can be defined at various processing points at the originating and terminating SIP server.

FIG. 7 shows a processing flow between services belonging to various processing points according to an embodiment of the present invention. In the embodiment described in FIG. 6, services that embed various parts of a SIP message are grouped into various processing points. This can be used to effectively process the service. A service for embedding the SIP signaling property of the incoming message 701 is included in the processing point P1. Therefore, the output from processing point P 1 has a final originating / media control instruction 702. This can be immediately merged with possible SIP server default behavior and handed over to the message converter 705 that prepares the outgoing SIP message 703. In addition, the services invoked at processing point P2 can trust that the signaling properties will not change any further, for example, these services are services that depend on the final generated destination address. Reliability can be given.

  Actually send the resulting outgoing SIP message (s) 703 to the server by aggregating services that embed only non-signaling SIP message body content (and possibly related content header fields) at processing point P2. There is a sufficient output 704 from the processing point P2. Output 704 from processing point P2 is handed over to message converter 705, merged with output 702 from processing point P1, and message 703 is transmitted.

  If there are outputs from processing points P1 and P2, processing P3 is reached. The service at processing point P3 does not embed the content of the resulting SIP message 703, but can trust it. Here, preferably, the SIP messages generated from the processing points P1 and P2 may be transmitted before waiting for the execution of the service for the processing point P3, thereby improving the efficiency of the system.

  Here, the grouping of services according to processing points has the following effect: Processing points simplify the problem of feature interaction. Processing points make feature interaction issues more scalable. Processing points improve processing message latency when using parallel processing, i.e., using multiple processors. The response or proxy request can be handed back faster to the network because a service application that does not specify a command to the SIP server is located at the processing point P3. Here, the response or the proxy request does not need to wait for the service application at the processing point P3 to be called.

  FIG. 8 shows grouping of services into rule modules corresponding to management rights according to an embodiment of the present invention. Since a rule module has a rule module owner associated with it, they correspond to an administrator, i.e., a management domain in which the rule module owner can specify a service placement policy. Within the rule module, the order of actions is assigned by the rule module owner, ie, the author of the SERL script.

  According to an embodiment of the present invention, each rule module has a priority assigned to it. The priority specifies the relationship between rule modules. In a rule module having a higher rule module priority, an earlier rule is applied. FIG. 8 shows two rule modules 801 and 802. The rule module 801 is owned by the administrator A, while the rule module 802 is owned by the administrator B. The rule module priorities of the rule modules 801 to 802 are indicated by the order of the rule modules. Here, the lower order corresponds to the upper priority, and the upper order corresponds to the lower priority. For example, rule order 1 is defined as the highest priority. In the example of FIG. 8, the rule module 801 has a rule module order h, and the rule module 802 has a rule module order h + 1. As a result, the services 803 to 804 called by the rule module 801 are executed before the service 805 of the rule module 802.

  Rule modules with the same owner can have the same ordering priority. Preferably, in this case, they should have different event contexts (e.g. SIP, HTTP, ...) so that one or more rule modules with the same priority have the same event Prevent being called in context. In other words, rule modules that can be called with the same message properties from a given event context have different properties.

  Each management domain is independent of other management domains. This means that one management domain need not have knowledge of services located in other domains. Each administrator can analyze and specify a service placement policy for a given domain.

  If one or more rule modules or service applications are invoked at a given event, each provides a set of feature instructions, which are how this event is handled, eg Specifies whether the event should be processed or ended. Strictly speaking, such feature instructions should not be processed simultaneously, and several feature instructions may invalidate each other. However, in some cases it may not be important in which order the feature instructions are applied or they are applied simultaneously.

  In accordance with the present invention, a mechanism is provided that allows the management domain to protect those feature instructions when control is handed over to another management domain. This means that each management domain can be restricted from handing over control to properties that are not critical to the normal behavior of its features. Objects passed from one service to another are current event contexts 806-807. Preferably, when the control of the event context 806 between service applications belonging to the same management domain is handed over, the default rule does not protect the property of the event context. If several things must be protected, it must be done explicitly. However, between administrative domains, all properties of event context 807 are protected by default. If some need not be protected between administrative domains, it must indicate that it is not explicitly protected. Preferably, the right to indicate protected and / or unprotected properties should be determined by the privileges associated with the rule module.

  In other words, higher level property rule modules can lock their message properties if they have the privilege to lock the message properties, and locked message properties are Unless you have the privilege to unlock properties, you cannot unlock them with a rule module.

本発明の実施形態では、アクション出力は、ルールモジュールで終了することができる、即ち、ダウンストリームアプリケーションは呼び出されない。また、アクションは、カレントイベントコンテキストのメッセージプロパティに明示的に特権を設定することができる、これは、それらがそのような特権を有している場合である。本実施形態の効果は、優先度が一旦割り当てられると、管理ドメインは独立することである。 The following example rule module fragment shows the locking / unlocking of message properties after feature F1 has been executed.

In an embodiment of the invention, the action output can be terminated in the rule module, i.e. no downstream application is invoked. Actions can also explicitly set privileges on the message properties of the current event context, if they have such privileges. The effect of this embodiment is that the management domain is independent once priority is assigned.

  According to the present embodiment, the general manager assigns the rule module property or property range based on the contract relationship of each rule module owner. The general domain administrator is also usually the owner of the top-level property rule module. For example, at the upper level of the hierarchy is a SIP service service provider that owns the domain name and IP address of the host. SIP service providers can provide many services to many parties. SIP service providers can also run applications for their own purposes, for example for logging, accounting, statistical processing, fraud detection, advertising processing, etc. The SIP service provider can place one or more rule modules on the server.

  For example, a SIP service provider can place a rule module for each of its subscribers. When a SIP event is received at a SIP server, the SIP service provider's main rule module can invoke several of its own services and hands over control to the rule module for the appropriate subscriber. In this rule module, there may be a rule for starting a service designed for a specific subscriber. These services may be provided by a SIP service provider or by a SIP service provider transferred from a third party service provider. SIP service providers are preferably able to use SERL to analyze feature interaction issues between these services and to identify order and command priorities between service applications. In this case, both the main rule module and the subscriber rule module are owned and managed by the SIP service provider. These can be said to exist in one management domain. At some point in order priority, the SIP service provider may decide to hand over to a rule module owned by the subscriber himself. Here, it is noted that individual subscribers can write their own SERL scripts or can only update SERL script preferences, eg, generated via HTML format. I want. A subscriber's rule module can call a CPL script, or conversely, call another rule module, some third party service provider's rule module, or the like. If the subscriber's rule module contains more than one action, the subscriber must specify which action should be performed first. Similarly, in a third party rule module, actions must be ordered according to third party requirements.

  In another situation, the subscriber may be an employee of a business consumer. In this case, the SIP service provider's rule module can first be handed over to an enterprise consumer's rule module that can call several applications and then hand over to the individual subscriber's rule module.

  Higher level administrators try to spread the priority order across several rule modules. However, it can be cumbersome to intersperse rule modules in lower priority rule modules of other parties. One solution to this problem is to divide into rule module priorities with sufficient backup scope that can be used later. Optionally, a hierarchical management domain model as described in FIG. 12 can be applied.

  Preferably, the service support environment supports a mechanism for notifying the administrator when an application attempts to change a protected property. Preferably, the application attempting to change the protected property is obtained from the service.

  Note that variations on the above scheme are possible. For example, in the management domain hierarchy, each level of administrator can have an absolute opportunity to place a lower priority level rule module within the assigned priority range. The upper level administrator specifies this opportunity.

  An advantage of this embodiment is that it provides a scalable mechanism for managing and implementing service placement policies. According to this embodiment, the service support environment can handle third party service placement policies without having the domain administrator perform significant extra work. This has the further advantage that some custodians or some contractual relationships between them are limited.

  A further advantage of this embodiment is that the feature interaction analysis task can be subdivided into administrative domains, thereby allowing problems between related parties to be distributed.

  FIG. 9 illustrates an embodiment of the present invention in which services are grouped according to both processing points and administrative rights. FIG. 9 shows a rule module 901 with a priority order h and a rule module 902 with a priority order h + 1. Rule module 901 calls services F1, F2, F5 and F6, while rule module 902 calls services F3, F4, F7 and F8. Services F1-F8 are further associated with processing points 903 and 904. The processing point 903 includes services F1 to F4, and the processing point 904 includes services F5 to F8. Characters are assigned to the processing points 903 to 904 so that the processing point 903 is an index K and the processing point 904 is an index K + 1. This indicates that the processing point 903 is processed before the processing point 904. ing.

  According to this embodiment, the rule is applied to a sequence of processing points. As a result, when processing the rule module, only the service execution rule belonging to the current processing point is executed.

  For each processing point, there is a set of rule modules that are grouped according to priority and called at that processing point. All rule modules with priority 1 are grouped into set 1, all rule modules with priority 2 are grouped into set 2, and so on. However, given an event context, most rule modules are called in each set. The rule module can be distributed over multiple processing points.

  In the example of FIG. 9, first, the service at the processing point 903 is processed according to their rule module priority, that is, the services F1 and F2 are processed before the services F3 and F4. Subsequently, at processing point 904, features h5 and F6 with priority h are called before services F7 and F8.

  The rule modules 901 and 902 shown in FIG. 9 can be expressed as shown in the following example rule module.

ルールモジュール９０２：

図１０は、複数のルールモジュールと複数の処理ポイントの場合の図９の実施形態の処理メカニズムを示している。本実施形態に従えば、Ｐ０からＰ３で示される４つの処理ポイントと、それぞれ優先度１から５を有するＲＭ ＡからＲＭ Ｅの５つのルールモジュールが存在する。図９と併せて説明される処理ルールに従えば、サービスは、番号１から２０と矢印で示される図１０の丸数字によって示されるように、処理される。各丸数字は、いくつかのアクションを呼び出すルールのセットを表している。 Rule module 901:

Rule module 902:

FIG. 10 illustrates the processing mechanism of the embodiment of FIG. 9 for multiple rule modules and multiple processing points. According to the present embodiment, there are four processing points indicated by P0 to P3 and five rule modules RMA to RME having priorities 1 to 5, respectively. According to the processing rules described in conjunction with FIG. 9, services are processed as indicated by numbers 1 to 20 and the circled numbers in FIG. 10 indicated by arrows. Each circle represents a set of rules that invoke several actions.

  FIG. 11 shows another example of the processing rule described in conjunction with FIG. FIG. 11 shows the instances 1111a to 1115a of the rule modules RM A to RM E on the left side 1101, and the instances 1111b to 1115b of the rule modules RM A to RM E on the right side 1102. The rule modules RM A to RM E have rules corresponding to the processing points P0 to P6. Here, the rule module instances on the left side 1101 indicate different sections of the same rule module as the rule module on the right side 1102. As described in FIG. 6, the processing points P1 to P3 are activated by the SIP request, while the processing points P4 to P6 are activated by the response. The processing point P0 is activated by both a request and a response. In this example, the incoming SIP request 1103, for example, the INVITE request, activates the services of the rule modules RMA to RME related to the processing points P0 to P3 in the order indicated by the arrows 1101 on the left side of FIG. . In the example of FIG. 11, it is further assumed that the service 1104 outputs an instruction to generate a response 1105. This response, on the other hand, triggers the processing of the rules in rules module RMA (111b) to RME (1115b) associated with processing points P0 and P4 to P6, as shown on the right 1102 of FIG. Then, starting with service (s) 1106, the outgoing message 1108, eg, the generated provisional response, is output. The processing of the service on the left side 1101 further outputs an outgoing message 1107, for example, an INVITE proxy request.

  FIG. 12 shows hierarchical rule module processing according to an embodiment of the present invention. When the rule engine 1200 receives an event 1201, it identifies related rule modules 1216-1219 of various priorities for this event on a per rule basis. The rule engine 1200 generates a current event context 1202, initializes processing of the rule module 1216 having the highest priority, and passes control to the rule module 1216 via the generated current event context 1202. When the processing of the rule module 1216 having the highest priority is completed, the rule engine 1200 calls the next rule module 1217 according to the rule module priority, and passes the changed current event context 1206 to the next rule module 1214. Similarly, the next rule module 1218-1219 is invoked and control is passed to them via the respective current event contexts 1207 and 1214. The event context 1215 obtained thereby is returned to the rule engine 1200. According to an embodiment of the present invention, each called rule module can call one or more other rule modules in succession. According to this embodiment, the rule modules are divided into two types of rule modules: rule modules 1216-1219 that are called by the rule engine 120 with their own order priority, and rules that are called only by other rule modules. Modules 1220-1225. The latter type of rule module is typically identified by a specific order priority, eg, order priority 0. According to this embodiment, this priority rule module has a special restriction associated with them: a rule module with this priority should not be called by the rule-based processing procedure of the rules engine 1200. Not called, but from another rule module that has explicit privileges to do it. A rule module having an order priority different from 0 is not called by other rule modules, nor is it called by the rule engine. Rule modules with the same owner can have the same order priority (different from 0), but in this case should have different event contexts, eg SIP, HTTP, etc. This means that they should not be called in the same event context. Different owner rule modules can have the same order priority, but in this case they should not be called with the same properties of the same event. In other words, rule modules that can be invoked with the same message properties from a given event context should not have different priorities unless it is zero. The first rule module 1216 is called by the rule engine before any rule module with order priority 0 is called. This rule module is called a route rule module. If the route rule module calls a rule module with a priority 0, they can call another rule module with a priority 0 again. These relationships between rule modules are called rule module hierarchies. The mechanism for calling the rule module from within the rule module gives a hierarchical distribution of management domains, also called a hierarchical management domain model. The advantage of this model is that it is easy to manage and gives a significant amount of control to the master rule module. A further advantage is that additional rule modules can be added to an existing hierarchy without reassigning a significant number of priorities to the next rule module. The rules described above avoid the rule module being triggered twice by an accident of a rule-based processing procedure.

  In the example shown in FIG. 12, the rule module 1216 calls them in the order of the rule modules 1221 and 1222, passes control to the corresponding event contexts 1203-1204, and receives the resulting current event context 1205. Similarly, the rule module 1218 calls the rule modules 1222 to 1223 with the corresponding event contexts 1208 to 1209 and the event context 1213 obtained thereby. Then, the rule module 1223 called by the rule module 1218 further calls the rule modules 1224 to 1225 with the corresponding event contexts 1210 to 1211 and the event context 1212 obtained thereby.

  Here, hierarchical call processing for generating a sequence of current event contexts is executed in the order indicated by event contexts 1202 to 1215.

  Here, if no further processing points are defined, the above rule module processing should not be understood to be processing point units, that is, a corresponding hierarchical rule module is processed for each processing point. Please be careful.

  An important task of the rule-based processing procedure of the rules engine 1200 is to map SIP events to related rule modules. This process is almost dependent on the contractual relationship defined in the domain. A SIP event contains several message properties that can be used to detect possible contractual relationships. These properties are specified in sirequest. from, sirequest. to, sirequest. RequestURI, siresponse. from, siresponse. to, siresponse. contact and siresponse. Via is included. In particular, the From and Request-URI of SIP messages are important properties of events used by network operators or third party service providers to detect contractual relationships. However, other message properties are considered in the contact header and via header, for example. A message property that can be used to detect a contract relationship, i.e., activate a rule module, is called a rule module trigger (RMTrigger).

  When the SIP request message reaches the SIP server, at least one of the From or Request-URI message properties should identify a subscriber that has a contractual relationship with one of the network operators of the SIP server. The message property of From or Request-URI is nettopX. com, or a single IP address of the network operator of the SIP server such as 123.123.123.000. In addition, the From or Request-URI includes a subscriber identifier such as a name or telephone number. This is included in the SIP URL or TEL URL. The SIP-URL also has parameters such as “transport-param”, “user-param”, and “other-param”. These parameters can include information identifying the network operator as an IMSI for identifying mobile terminal subscribers and terminals.

  For example, using the properties described above, a network operator specific to a SIP event is mapped, if each of the SIP server's network operators meets nettopX. com and netopY. com with a unique domain name such as com and when they have different IP addresses. If they share the same IP address, the speculative relationship analysis can be ambiguous such that the From and Request-URIs contain IP addresses but not domain names.

  A third-party service provider that updates / registers a service application in the SIP server has a contractual relationship with a network operator that can be detected. For example, a third party service provider can receive an ID assigned from a network operator with whom the third party service provider is contracted. The network operator may, for example, nettopX. If a domain name such as com and an associated IP address are present, a third party service provider with a unique name partyZ receives an assigned ID following a name convention such as “partyZ.netopX.com”, for example. Can do. Here, From and Request-URI are checked against the related rule module. nettopX. com and partyZ. nettopX. com in either From or Request-URI and netopX. If they are to be called on events that contain com, they should have different explicit ordering priorities. It is understood that other name conventions can be introduced instead.

  It will be appreciated that the order priority and rule module hierarchy mechanisms may be applied independently of one another or in combination with one another as described above in conjunction with FIG.

  FIG. 13 shows an example of SIP message and instruction set flow according to an embodiment of the present invention. The message parser 1304 converts the original message 1306 into an original SIP message object 1303. This is used to call the initial rule module 1301, here the first sequence of service applications. When the rule module 1301 is loaded into the rule engine and activated, it depends on the signaling message object 1303 received from the message parser 1304 and, for example, as described in FIG. One or more actions are reached based on whether 1301 is identified. When an action is reached, the service application 1305 associated with that action is invoked, ie enabled, with parameters, if possible, and with access to the entire signaling message object 1303 that invoked the application, if possible. Enabled. Access privileges to the entire signaling message depend on the function and scope of the service access API used, eg, CGI API vs. OSA API, and the privileges of the owner of the rule module 1301 and the privileges of the service application 1305 to be invoked. It also depends on. The initial signaling message object 1303 represents the entire set of message properties embedded in the original SIP message 1306 that can include multiple media types. The called service application 1305 performs some processing based on the signaling message 1303 and hands back the result 1307 to the rule engine 1303. The result of this is referred to as an instruction set and can potentially include multiple instructions such as CGI instructions, OSA API instructions, etc. When multiple services are invoked based on one signaling message, the rule module processor outputs multiple instruction sets. This set of instruction sets is called an “instruction set base”.

  The rules engine 1302 and application execution engine determine which instructions are passed to the SIP server default action 1308. The instruction set is filtered based on privilege and feature interaction analysis before the instruction is passed to the SIP server default action 1308, where the SIP server default action 1308 further includes an instruction set and a default SIP instruction set 1312. Can be merged. The resulting set of instructions is called an “output (resulting) instruction set”. The output SIP message object (s) 1309 represents the actual SIP message, which is sent downstream or upstream. Here, this results in one or more outgoing SIP message objects 1309 that are sent to the message converter 1310 and subsequently converted to one or more SIP messages 1311 to be sent.

  FIG. 14 illustrates a mechanism for managing multiple instruction sets according to an embodiment of the present invention. According to this embodiment, the event context is a representation of a SIP message object, which includes not only feature interaction information, but also additional information such as the MIME type contained in the SIP message body. The original event context 1401 represents the original SIP message object 1402. The current event contexts 1403a and 1403b are event contexts based on an instruction set generated by the service applications 1404 to 1405. At any given time, one service application is under the control of the current event context. Even when multiple service applications are running and apply control to transaction processing, only one of them arbitrarily controls the current event context. In the example of FIG. 14, two service applications 1404 to 1405 are shown. First, the service application 1404 performs control via the current event context 1403a. If the application 1404 has completed its processing, control via the current event context is handed over to the service application 1405. At this point, the service application 1405 controls the current event context 1403b, i.e. it has the right to read and write the current event context. In an embodiment of the present invention, other service applications may have the right to read the current event context 1403b.

  Here, the start of the next service application is based on the current event context. It is removed against the feature interaction problem that the current event context can take, so that subsequently invoked service applications can trust it. When control is handed over from one service application to the next through a call mechanism provided by the rules engine, ownership of the current event application is handed over. In this manner, the final output event context 1406 is obtained when all service applications have been invoked and their instructions applied. That is, the output event context 1406 represents an output SIP message object (group) 1407. Note that this mechanism does not exclude parallelism, because service applications 1404 and 1405 can be executed in parallel. However, according to the present embodiment, it is applied in the update sequence of the current event context.

  Furthermore, it should be noted that a service application can split a request into multiple destinations. This will generate multiple current event contexts.

  FIG. 15 illustrates a tree of service application cascaded chains according to an embodiment of the present invention. If the services are run on different SIP servers and the services apply control to the session, these services provide a normal ordering of the services even if they do not know each other. This ordering may be called upstream or downstream. Downstream ordering is the ordering of services that are called downstream from the originating client to the destination server. Upstream ordering is the ordering of services that are called upstream from the destination server to the originating client. If services that apply control to an instance of a session are invoked in the order given on the same SIP server, it can be determined that the services are cascaded according to the same ordering principle. This ordering principle is called a cascade service, and a chain of services is called a cascaded chain service.

  When a request is received, an earlier service is invoked based on that event, and that service that is more logically upstream is considered to be a chain of cascaded services. When a response is received, earlier services are invoked based on that event, and services that are more logical downstream are considered to be a chain of cascaded services. Here, the applications are processed as if they were started on different hosts.

  This model is conceptually simple and provides a natural algorithm for resolving conflicts between the instructions of multiple service applications at the same SIP event.

  In receiving a SIP event, actions are performed in the following order of priority: 1) Control is passed to the first application.

  2) Several responses are received from the first application.

  3) Control is passed to the second application.

  4) Some responses are passed to the second application, and so on.

  However, when the first application ends the request, the second application is not called.

  In this way, the decision on whether to call the next application can depend on the output from the previous application. Also, the instruction priority associated with the action is by default ordered according to the cascade principle.

  When an application splits a request, this becomes a tree of cascaded services rather than a simple chain of cascaded services. This is called a “request tree”. The request tree represents several cascaded chain applications. Each path from the root of the request tree to a leaf represents a cascaded chain.

  FIG. 15 shows an example of a request tree, where the service application APP1 is called by the rule module execution module 1501 having the original event context OEC as input. When control is handed over from application APP1 to the next application APP2, application APP2 transfers control to the current event context EC2. The application APP2 divides a request for generating the event context EC3 and the event context EC4. The lower priority action calls application APP3 with one or more properties of event context EC3. Another lower priority action invokes another application APP4 with one or more properties of the event context EC4. This leads to a tree-like structure that represents the process of the called application. In this tree, branches represent event contexts. A node represents a trigger. The root of the tree is the original event context OEC. The leaves of the tree are output event contexts REC1 and REC2.

  If there are no more actions in the rule module, all current event contexts are fed back to the rule-based processing procedure 1502. This procedure calls another rule module that builds more request trees. As a result, the tree can be quite large with many nodes and branches depending on the service being invoked.

  Note that in some cases, the application can send asynchronous feature instructions to the service support environment, i.e. not associated with an existing transaction. In this case, the application initiates a new transaction, which is assumed to be the root of the new cascaded chain tree.

  To allow parallel processing of services, the service support environment can pass control to one or more services simultaneously. This is not a contradiction in the cascaded service model, because instructions from services invoked in parallel should be applied in the cascade order. If more downstream services respond before more upstream services, the rules engine waits for more upstream for response before relaying its instructions. Instructions are routed so that services are invoked one by one. The administrator should be able to specify whether groups of actions should be applied simultaneously in this way.

  FIG. 16 illustrates the software components of the rules engine according to an embodiment of the present invention. The rule base processing procedure 1601 calls the rule modules 1602 stored in the rule base 1603 in the correct order. The rule module processing procedure 1604 executes the rules of the rule module. The service interaction module 1605 includes a set of functions 1700 that includes activation, feature interaction, privilege and rights application. Function 1700 is described in more detail in FIG.

  When a SIP event is notified to the rule engine in the form of an original event context 1609, a rule-based processing procedure 1601 is executed to detect and execute regular rule modules in the correct order. The rule base processing procedure 1601 passes the rule module to be processed and the original event context 1610 to the rule module processing procedure 1604. The rule module ordering along with the rule ordering of each rule module determines the pattern processed by the rule module processing procedure 1604 and the ordering of actions 1606-1608. The action calls the corresponding service application 1611-1613. When calling the service application 1611, the original event context is passed to the service interaction module 1605 as the current event context CEC1, while the event context EC1 is passed to the service application 1611. The service application 1611 obtains a set of feature instructions 1614 that cause an update of the current event context by the service interaction module 1605. This resulting current event context 1615 is returned to the rule module processing procedure 1604. Service applications 1612 and 1613 are invoked in a similar manner, and the resulting corresponding instruction sets 1616-1617 are converted by the service interaction module 1605 to corresponding current event contexts 1618-1619. During this conversion, the service interaction module 1605 performs an authentication check and if the service application 1613 returns an unauthenticated instruction set 1617, the unauthenticated instruction is not converted. Here, the current event context 1619 is not different from the input event context 1620. Preferably, the service application makes a notification 1621 about this failure. Note that a service may result in the occurrence of multiple current event contexts as illustrated in FIGS. When the rule module finishes processing the patterns and actions 1606-1608, the final set of current event contexts 1622 is returned to the rule-based processing procedure 1601. The next call to the rule module depends on this set of current event contexts. Note that a service application may arm / disarm events and triggers for feature events, as described in detail below. Here, the service application can also return an arming request 1623.

  FIG. 17 shows steps performed by the service interaction module between the processing of the service application and the processing of the rule module of the embodiment of FIG. This functionality 1700 includes feature interaction management and privilege checking performed by the rules engine 1702 and application execution engine 1703. If the invocation command and current event context CECa are received from the rule module processor 1601, at step 1704, the privileges of the rule module are checked. The privilege of the rule module is specified in the access control list ACL2 associated with the rule module. If the rule module has the privilege to issue a call command, in step 1705, the rule engine 1702 sends the call command to the application execution engine 1703 via an application execution engine manager (not shown). As indicated by f (CECa), a part of the current event context need not be sent to the application execution engine 1703.

  In step 1706, the application execution engine 1703 converts the received event context f (CECa) into a data format suitable for the service application 1707 to be called. This may also include conversion to an appropriate namespace for calling service applications. In step 1708, the application execution engine 1703 checks the privileges and rights. The access control list ACL3 associated with the service application 1707 can specify the privileges of the service application 1707 to access the value of f (CECa) or part thereof. Also, the rule module is accessing a service application 1707 that depends on another access control list ACL4, which is related to the service application 1707. If access occurs, at step 1709, the service application 1707 is invoked and the relevant portion of the event context g (ECa) is provided as input. Subsequently, the service application 1707 returns control to the rule engine 1702 via the application execution engine 1703 by sending the instruction set 1710 or an intermediate representation of the instruction set. At step 1711, the privileges and rights of the service application 1707 issuing these instructions are checked, for example, based on the access control list ACL5 associated with the service application 1707. If the service application 1707 has the privilege to issue these instructions, the instructions are converted from the intermediate representation (step 1712), and the converted instructions 1713 are passed to the rules engine. An arbitrary arming request 1716 is similarly passed. At step 1714, possible feature interaction problems are resolved with earlier instructions issued from service applications that have already been authenticated and invoked. This solution is based on whether the already invoked application has a message property that is protected in the current event context. The next current event context CECb is generated and returned to the rule module processor 1601. Then, in step 1715, the rule engine stores information about the service being called in memory, for example by building the request tree described in FIG. The request tree is used with future event notifications.

  As mentioned above, some services, such as monitoring applications, are relevant in future events. In order to inform the rules engine about this relationship of future events, the service application needs to make a request for event notification, which is called dynamic arming for event notification.

  According to embodiments of the present invention, dynamic arming of transaction events is tied to the processing of SIP transactions, which are eventually bound. Transactions can typically last for milliseconds to minutes depending on the configuration of the SIP server. Since dynamic arming of transaction events applies only to the lifetime of the transaction, this type of arming is non-permanent and is explicitly disarmed when the transaction ends, thereby providing a fast mechanism I will provide a. If an application arms an event related to a transaction invoked by that application, the application maintains its position in a cascaded service model. Responses are communicated to all applications starting from the leaves of the tree that are arming them, ie most downstream applications. During the lifetime of the transaction, the request tree exists in the rule engine memory. The next event associated with the same transaction is associated with the request tree. Events associated with the request tree can occur from applications, downstream servers, and upstream clients.

  Events from upstream enter the root of the request tree. This means that they are first notified to the application in the request tree root. If not sent further in the original tree, but a new request tree is built, the application can terminate or redirect the event. The request need not be sent to all the same destinations as the original request, or the request needs to be sent to one of the destinations to which the original request is sent. Events from the application are entered into the appropriate nodes of the request tree. Events from the downstream server are input into one of the leaves of the request tree.

  If the rules engine remembers the order of applications to be called, ie the order of the request tree, this leads to a traversal mechanism for the request tree. It is an advantage of this embodiment to provide clear rules for the order in which events are notified within the context of a transaction. This clear rule is a cascaded service model, which is a conceptual and simple rule that can be easily understood by administrators and application designers. This simplifies the API by the application execution engine adding rules to the rule base. Rather than having to arm CANCEL for a particular branch of a rule module, it is easier to arm cancellation of a given call leg.

  There are various ways to perform a request tree traversal.

  For example, the rules engine can accomplish this scanning by using VIA header and branch parameters. In practice, this means that each time the destination address is changed by sending a request to the SIP server, a different instance of the rule engine is created. The DNS lookup performed by the SIP stack determines in seconds whether a request to be processed by the server is returned. When a request is received from a SIP server, it is treated as a new request. The rules engine should have a mechanism to guarantee that service, for example, a service activated on the FROM field will not be accidentally called again.

サービスアプリケーションの論理的カスケーディングのモデルについて検討すると、以下の２つの一般的なルールが、以下のサービス実行環境に対して一般化することができる。 Optionally, in this embodiment, the event is handled at the host for the request tree that includes the entire request tree, ie, all the forwardings until all the leaves of the request tree represent every destination in the network. . This embodiment has the advantage of being more effective when several instances of the signaling state device and manager class are required. For example, the request tree may be realized by having an instruction of a node object that can have a pointer to the immediately preceding and next node of the request tree for each trigger of the application. The following pseudocode fragment shows how the construction of the request tree can be incorporated into algorithms for rule-based processing and rule module processing. This concept indicates that it is associated with each event context that has a RequestTreeNode. This is the RequestTreeNode where the event context is being generated. Each node is the root of the request tree or is associated with action execution.

Considering the service application logical cascading model, the following two general rules can be generalized for the following service execution environment:

  -Upstream scan events should be notified first to many logical downstream applications.

  -Downstream scanning events should be notified first to many logical upstream applications.

  The logical cascading order of services is maintained when delivery event notifications to prevent more complex and unmanageable situations can be notified to cascaded services in any order.

  Preferably, an application that arms such an event is invoked at processing point 1 or 4 and their sub-processing points. Preferably, the network operator can specify in the rule list for processing point 4 the point at which a dynamic arming trigger is to be notified. This means that a logical cascading chain of services established for the request is maintained and new services are activated before or after this chain. The same rule can be applied to the next request associated with an existing transaction. At this point, it exists at processing point 1 and the administrator can specify when to notify the dynamic arming event.

  Alternatively or additionally, another type of arming can be applied, referred to as a dynamic arming trigger, added as a rule to the appropriate rule module in the rule base. Dynamic arming triggers provide a cheaper mechanism for processing power and execution memory for event notifications not related to transactions when the application is launched. Preferably, these requests for event notification should be stored in permanent memory, i.e., they become rule-based rules. These rules can be made permanent by specifying a deadline timer, or they can be made permanent. In the latter case, the service application should explicitly cancel the event notification request for deleting it. Alternatively, they may be armed in a “report-once then disarm” mode. Also, if no time limit is given, a default time, for example 1 hour, can be applied to the rule. When this time elapses, the rule is deleted. This has the advantage of avoiding the server consuming data storage capacity.

  Preferably, the trigger rule is added to the rule module of the application that has the privileges and rights to update. This is usually the same as the rule module in which the application is launched. Of course, where these rules should be added in the priority order within the rule module is determined by the absolute rule priority order, i.e. an integer representing where the rules should be placed within the existing rule module. Can be determined. When a SERL script is added first, the rules are ordered in the order in which the rules appear in the script. If there are N rules, integers from 1 to N are absolutely associated with these rules. Rules can be deleted by referring to these numbers. A rule can be added by referring to the rule that should place the new rule behind it. This has the advantage that the amount of data required to exchange when rules are added to a large rule module is reduced.

  If the location is not specified, the rule module engine follows the following algorithm when adding the following triggers: Search for a rule module for the same property pattern as a new rule. If a pattern is detected, continue searching for any subpattern. If no subpattern is detected, insert the rule into the list of actions as the highest priority rule. If a similar pattern does not already exist in the rule module, it is inserted as the first pattern. This algorithm provides a logically advantageous arrangement for the rules. For example, ensure that the action for the caller with TARGET = FROM is not mixed with the action for the callee with TARGET = RequestURI. This also means that the last added rule will be encountered first when the event occurs. This is the simplest default behavior.

  It can indicate whether the trigger rule is permanent or should be automatically cleared once the event is notified. Which types of rules an application can dynamically add can be related to the privileges and rights assigned to the application.

  In another embodiment, the cascaded request tree is maintained only for the duration of the event. In this case, the latest application in the chain has completed its processing, a SIP event is sent and the cascaded chain is no longer relevant. By that time, it is beneficial for the rules engine to keep a representation of the cascaded chain in memory. This is because the application runs on separate servers and requires some time to answer the call. While the rules engine is waiting for a response, earlier applications in the chain can cancel the request. When this occurs, the rules engine needs to notify the application execution engine of the application that it is waiting. This means that the rules engine should remember which is the next application in the chain. At the time the SIP event is being sent, all applications in the chain should arm the rules for the event of interest, ie more rule engines are needed to store the cascaded chain Absent. The advantage of this solution is that the rules engine itself is simple. This notifies the event based on the rule module at the relevant processing point. However, this solution is complicated to manage and place complex ordering of events into the application, i.e. the application determines at which priority position the rule should be added to the rule module. There is a need to.

  FIG. 18 shows a tree structure of processing of the rule module according to the embodiment of the present invention. When an event is received, the rule base process expands a process pattern referred to as a rule base tree. When the request reaches the SIP server corresponding to the original event context 1801, the associated subscriber can be at least one of the calling party (ie, the calling party) and the called party (ie, the called party). The originator is identified by the From header field. The called party (or current called party) is identified by the Request-URI. The From header field and Request-URI should uniquely identify the subscriber at the SIP server, where these subscribers have a contractual relationship with the network operator and service provider. In the following cascading principle, even if the outgoing and incoming parties are located on the same host, the outgoing service 1802 is called before the incoming service 1803. A third category of services can also be invoked. These are referred to as call-forwarding (forwaded-by) services. This category of services is invoked when a request is sent to a new destination belonging to another subscriber. In this case, the outgoing service needs to be called for the called party. For each party, the service is invoked based on the location of rule modules located at different processing points 1804-1809. For each processing point, a set of rule module priorities 1810-1814 is examined for matching. Within each priority, at most one of the rule modules 1815-1817 is invoked. However, rule module 1817 can be the root of rule module hierarchy 1818 as described in FIG. For simplicity, it is assumed that such a rule module hierarchy is a single rule module. Here, the function of the rule module process 1601, the function 1700 of the service interaction module, and the service application 1819 that are called by the rule module can be assumed as leaves of the rule base tree. Based on the current event context CEC, the rule module 1817 is invoked, which returns the resulting event context REC. This resulting event context REC is considered as the current event context CEC for the next rule module to be called. When all rule modules are invoked and their end returns the resulting event context, the resulting event context is sent to the upstream and / or downstream as a reply to the original incoming SIP message. A set of SIP signaling messages.

サービスアプリケーションは、ＦｒｏｍヘッダフィールドあるいはＲｅｑｕｅｓｔ−ＵＲＩを変更することができることに注意されたい。また、得られるＦｒｏｍヘッダフィールドあるいは得られるＲｅｑｕｅｓｔ−ＵＲＩは、イベントを処理するＳＩＰサーバに対してさえ未知である別の加入者に属することができる。得られるＦｒｏｍ及びＲｅｑｕｅｓｔ−ＵＲＩの少なくとも一方は、ＳＩＰサーバで加入者に知られていない新規なものであり、この加入者に関連するサービスが同様に呼び出される。この場合、ルールベース処理プロシージャは、階層構造のルールベースツリーを再帰的に呼び出すことになる。 The above processing structure illustrated in FIG. 18 can be further illustrated by the following pseudo code fragment.

Note that the service application can change the From header field or the Request-URI. Also, the resulting From header field or the resulting Request-URI can belong to another subscriber that is unknown even to the SIP server that handles the event. The resulting From and / or Request-URI is a new one that is unknown to the subscriber at the SIP server, and the service associated with this subscriber is invoked as well. In this case, the rule base processing procedure calls the hierarchical rule base tree recursively.

  The processing of the rule module includes performing each action in priority order, evaluating whether the closed pattern matches the current event context, and applying the action when matching. In the following, the method according to an embodiment of the present invention will be described in detail.

ここで、enclosingPatternsTrue方法は、アクションを閉じるパターンがトゥルー（真）であるかを示すブーリアン（boolean）である。processAction方法は、以下の擬似コードセグメントで示されるようにして実現することができる：

ここで、ＥＣ［］は、以下のイベントコンテキストのセットである。これが空である場合、サービスは、リクエストあるいは応答を終了する。 The following pseudocode fragment provides a high-level description of the algorithm that processes the rule module.

Here, the enclosingPatternsTrue method is a boolean indicating whether the pattern for closing the action is true. The processAction method can be implemented as shown in the following pseudocode segment:

Here, EC [] is a set of the following event contexts. If this is empty, the service ends the request or response.

  The service application may further issue instructions that are not instructions for sending the event context. Here, it is not shown in the above algorithm. Such instructions can be processed by the rule base manager.

２つのアクションは、２つのパターンに含められ、このパターンは、リクエストがＩＮＶＩＴＥであり、かつＲｅｑｕｅｓｔＵＲＩがドメイン名ｘｃｏｒｐ．ｃｏｍを含んでいる場合に、アクションのみが適用されるべきであることを示している。第１のアクションは、ユーザ供給ＣＰＬスクリプトを呼び出す。ユーザＣＰＬスクリプトがリクエストの宛先を変更しない場合、標準化プロキシ行動が呼び出されて、ユーザを配置し、リクエストのプロキシを行う。宛先を別のホストへ決定することによってＣＰＬスクリプトが宛先を変更する場合、標準化プロキシ行動は呼び出される必要はない。 When executing actions in priority order, the result of the action can change the current event context. After such an action, processing of the current rule module continues. After execution of the current rule module, further rule modules may be executed according to the rule base processing procedure. If the pattern (s) that close the action match the new message property, as specified by the current event context, only the actions in the lower priority order are executed. This is shown by the following fragment pseudo script example that describes the two actions contained in the two patterns.

The two actions are included in two patterns, where the request is INVITE and the RequestURI is the domain name xcorp. com indicates that only actions should be applied. The first action invokes a user-supplied CPL script. If the user CPL script does not change the destination of the request, a standardized proxy action is invoked to place the user and proxy the request. If the CPL script changes the destination by determining the destination to another host, the standardized proxy action need not be invoked.

  If the message property that started the rule module is changed by expressing a new user, the processing of the rule module is stopped. The purpose of this is that the rule module can be assumed to be processed by a single user. This simplifies rule module processing and script authoring.

  FIG. 19 illustrates the recursion processing of the rule module in a situation where a service application generates a new event context according to an embodiment of the present invention. The new event context can change the original rule module trigger, in which case the new rule module can be called recursively. For example, a subscriber's terminating preference, eg, a CPL script, can send a request to a new destination associated with another subscriber on the same SIP server. In this case, the terminating preference of the sending subscriber, eg another CPL script, should be invoked as well.

  As shown in the example of FIG. 19, the initial event context 1901 generates a recursive rule module call when a SIP request message is sent to multiple new destinations associated with other subscriber accounts. In the example of FIG. 19, the application 1914 is activated by the rule module 1903 at the subscriber A. The rule module 1903 is activated by the original event context 1901. Application 1914 creates three event contexts 1904-1906, where the rule module trigger is changed in the two event contexts 1905-1906 associated with the new subscriber account. Event context 1904 is an updated event context but is not associated with the same subscriber having the rule module that was first invoked by application 1914. In this case, the subscriber rule modules 1907 to 1908 associated with the new event contexts 1905 to 1906 are also invoked. On the other hand, the rule module 1907 calls an application 1915 that generates two new event contexts 1909 and 1910, and so on. As a result, a tree processing structure is generated when the leaf corresponds to the resulting set of event contexts 1910-1913. Subsequently, the resulting event context 1910-1913 activates the SIP server to send the SIP message upstream or downstream or both. Note that this shows a simple example in which the example of FIG. 19 assumes that each rule module contains only one action.

  If the five applications 1914-1918 of FIG. 19 require notification of the next reply to the resulting SIP message, according to the cascading principle, the response will first notify most logical downstream applications. Is done. In FIG. 19, the response to the obtained event context 1910 is first notified to the application 1918 and then to the application 1915 and then to the application 1914 as indicated by the line 1919. For the resulting event context 1911, the corresponding sequences are application 1915 and application 1914, as shown by line 1920. For the resulting event context 1912, the sequence is application 1916 and application 1914, as shown by line segment 1921. For the event context 1913 obtained, the sequence is an application 1917 and an application 1914.

  FIG. 20 illustrates a mechanism for performing access control associated with a rule module according to an embodiment of the present invention. Two types of access control are performed. Access to the rule module should be granted only to the certified and authenticated party, and access to the service feature should be granted only to the certified and authenticated rule module. According to this embodiment, this access control can be realized by using a so-called access control list (ACL). Such a list may be embedded in the rule module or placed in the same directory, or may be an XML document associated with the rule module. The access control list includes access control rules. The access control list can count each individual or group authorized to access the rule module. This mechanism can also be used to explicitly specify the privileges and rights of the rule module, eg, which service features are being used by the rule module. Therefore, this mechanism allows the administrator to manage the privileges and rights of the rule module.

  This mechanism can also be used to manage service application privileges and rights. When a subscriber uploads a CPL script, there may be an associated rule module that calls the service at the correct time. In this case, the rule module should continue to have explicit privileges and rights. This can be managed by associating a CPL script with an access control list. This mechanism can further be used to explicitly specify which service applications can be used, such as service application privileges and rights, eg, which service features, APIs, etc. Here, this mechanism allows the administrator to manage the privileges and rights of the service application.

  With reference to the circled numbers in FIG. 20, the following privileges can be checked.

  1) The original event context 2001 is sent to the rule engine after proof of the appropriate subscriber (A is the caller and B is the callee). The rule module and service application are all certified and have the privileges and rights that are granted.

  2) The rule base processor 2002 attempts to access the rule module of the rule base 2003 associated with the certified subscriber A and / or B. The rule base processor 2002 should not be allowed to access the rule module associated with other subscribers when processing this event. The rule base 2003 may be located on a remote server if the rule engine should prove itself.

  3) If it is possible to follow the access control list 2005, the rule base processor 2002 can call the loaded rule module 2004, so-called rule module 1 owned by A.

  4) If it is possible to follow the access control list 2006, the rule module 2004 may attempt to call another rule module 2007 associated with another owner B.

  5) If it is possible to follow the access control list 2008, the rule base processor 2002 can call the loaded rule module 2007.

  6) If it is possible to follow the access control lists 2005 and 2012, the rules module 2004 may attempt to call the service application 2010 if possible. The service application 2010 can access the event context 2013 according to the access control list 2011.

  7) If the service application 2010 can follow the access control list 2015, it can return a set of instructions 2014 to the rule module processor.

  8) If the service application 2010 can follow the access control list 2015, it can arm / not arm for the event.

  9) If the service application 2010 can follow the access control list 2012, it can attempt to give instructions to another rule module 2007 other than the rule module being called.

このポリシーは、加入者アリスがルールモジュールを呼び出すことができるが、それを読み出したりあるいは書き込むことができない場合に、そのルールモジュール全体に適用することができる。 Access control to the rule module can be performed by the policy node of the rule module. An example of a rule module access control list embedded in a rule module is referenced as follows:

This policy can be applied to the entire rule module when subscriber Alice can invoke the rule module but cannot read or write it.

ＳＩＰサーバサービスサポート環境は、更に、例えば、コンテンツ課金、アプリケーション課金、利用課金あるいはその類に対するアカウントレコードを生成するように構成することができることに注意されたい。例えば、このレコードは、ＳＥＲＬスクリプトあるいはＣＰＬスクリプトからのログを介して提供され、ライブラリ機能あるいはサービスアプリケーション等を介して管理される。 Such policy XML scripts can not only be embedded within the rule module, but they can also be associated with data elements. For example, the network operator can associate a policy XML script with the subscriber's rule module and identifies the privileges granted by the network operator to the rule module owner. These privileges can specify services or service features and can invoke rules modules, as shown in the following example service access control list:

It should be noted that the SIP server service support environment can be further configured to generate account records for, for example, content billing, application billing, usage billing, or the like. For example, this record is provided via a log from a SERL script or CPL script, and is managed via a library function or a service application.

  It is also possible for subscribers and third party service providers to upload service applications, as well as instructions on how and when to invoke service applications, including the degree of feature interaction analysis. Even so, the service triggering execution system according to the present invention preferably performs a security measurement to ensure the safety and integrity of the SIP node. Possible security measures include configuration of privileges and rights such as rule modules, service applications, namespace agreement policies, certification mechanisms, authentication mechanisms, access protection, certification and validation of uploaded rule modules, logging and monitoring, etc. It is out.

  Note that the present invention has been described primarily with respect to network services. However, this is also applicable for use with end-user devices.

  It should also be noted that the present invention described primarily in connection with SIP can be used with other signaling protocols as well. SERLs are not limited to invoking services based on SIP events, but can invoke any type of service application based on any type of event in any type of context in the business model. The present invention can be applied to manage services for nodes capable of SIP. By using a SERL script, a service can be called from a node that implements a user agent, a register, a redirect server, or a proxy server.

  It should be noted that in the 3GPP architecture, all subscriber data is managed by a so-called home subscriber server (HSS). The SIP associated with the application is called from a node called serving call state control function (S-CSCF). When a subscriber connects to the network, his user terminal (UE) performs CSCF discovery to select an appropriate S-CSCF. The S-CSCF registers with the HSS to provide service to the target subscriber. The service trigger can be transmitted from the HSS to the S-CSCF in the form of a service execution rule in the SERL format. The HSS may also use a service execution rule associated with the subscriber to determine to assign a different S-CSCF based on the S-CSCF having a successfully installed service. it can. Here, embodiments of the present invention can be used in order for HSS to place subscribers based on triggers at normal processing points and priorities, ie installed in S-CSCF Can be used in normal priority order of fixed services. Here, the mechanism according to the invention can be embedded in the 3GPP IPMM domain.

FIG. 2 illustrates various types of feature interactions in a SIP service network. FIG. 3 illustrates network elements included in a service environment SIP server architecture according to an embodiment of the present invention. FIG. 3 illustrates a system architecture of a SIP server that supports a service execution rule mechanism according to an embodiment of the present invention. It is a figure which shows the structure of the rule module according to embodiment of this invention. FIG. 4 is a diagram illustrating grouping of services into a constrained set of services according to an embodiment of the present invention. FIG. 6 illustrates grouping services into a set of services that are constrained in the location of recursive SIP message flows according to an embodiment of the invention. It is a figure which shows the processing flow between the services which belong to the various processing points according to embodiment of this invention. FIG. 6 is a diagram illustrating grouping of services into rule modules corresponding to management authority according to an embodiment of the present invention. FIG. 6 illustrates an embodiment of the present invention in which services are grouped according to both processing points and management rights. FIG. 10 is a diagram illustrating a processing mechanism of the embodiment of FIG. 9 in the case of a plurality of rule modules and a plurality of processing points. It is a figure which shows another example of the processing rule demonstrated in relation to FIG. It is a figure which shows the hierarchy rule module process according to embodiment of this invention. FIG. 4 is a diagram illustrating an example of a SIP message event context and instruction set flow according to an embodiment of the present invention. FIG. 6 illustrates a mechanism for managing a plurality of instruction sets according to an embodiment of the present invention. FIG. 4 shows a tree of service application cascaded chains according to an embodiment of the present invention. FIG. 3 illustrates software components of a service support environment according to an embodiment of the present invention. It is a figure which shows the process performed by the service interaction module between the process of the rule module of FIG. 16, and the process of a service application. It is a figure which shows the tree structure of the process of the rule module according to embodiment of this invention. FIG. 10 is a diagram illustrating recursion processing of a rule module in a situation where a service application generates a new event context according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a mechanism for performing access control in relation to a rule module according to an embodiment of the present invention.

Claims (26)

A method for managing a plurality of services (309, 310, 311, 1305, 1611, 1612, 1613) activated by session protocol messages (1306, 1609) for controlling a communication session,
Obtaining a number of rule modules each having several execution rules (308, 401, 402, 1606, 1607, 1608 ) that specify the states ( 403, 404, 405) for invoking the service ;
-As a process of the first rule module (1216) of the several rule modules ,
Are at least part of the execution rules of the first rule module ;
A first execution rule (1606) for generating a first service (1611) to be called and outputting a first change message (1615) when the message satisfies the first state;
A second execution rule (1607) for generating a second service (1612) to be called by using the first change message as an input when the first change message satisfies the second state;
Performing a process of outputting a cumulative change message (1206) by processing in a predetermined order;
Performing a calling process of a second rule module (1217) of the several rule modules that provides the cumulative change message as an input;
The first rule module is assigned a privilege indicating an authority to change a lock flag associated with a predetermined portion of the cumulative change message;
The method, wherein the lock flag specifies whether the predetermined portion of the cumulative change message is changed by at least a service called from the second rule module. The method according to claim 1, wherein each rule module is associated with a priority indicating a processing order of the several rule modules. The method according to claim 1 or 2, characterized in that each rule module corresponds to a rule module owner (409) authorized to edit the rule module. The step of calling the second rule module further includes the step of calling the second rule module unless the lock flag is marked unset by the first rule module. The method according to any one of claims 1 to 3, further comprising the step of setting the lock flag in order to prevent a predetermined portion from being changed. The step of obtaining the number of execution rules further comprises a step of detecting a predetermined contract relationship based on header information of the message and selecting a number of rule modules based on the detected contract relationship. The method according to any one of claims 1 to 4, characterized in that: The method according to any one of claims 1 to 5, wherein the step of processing the first rule module (1216) further comprises a step of calling a predetermined third rule module (1220). . The first and second rule modules are respectively associated with first and second access control lists (411) that specify access rights corresponding to the first or second rule modules. The method according to any one of 1 to 6. The method according to any one of claims 1 to 7, wherein the first and second rule modules respectively include first and second scripts in a predetermined markup language. The message has first and second attribute sets, and the execution rules are grouped into execution rules of at least first and second processing classes (903, 904) according to corresponding constraints, and the second The processing class is limited only to changing the attributes of the second attribute set, and the method includes processing the first rule module (901) and calling the second rule module (902). A step of repeating the process of performing processing, wherein in each iteration, the processing of the first and second rule modules is limited to executing the rules of the corresponding processing class, wherein each iteration 9. The process outputs a corresponding cumulative change message that is used as an input for the next iteration process. The method according to claim 1. 10. The method of claim 9, wherein the processing class is defined separately for execution rules triggered by the session protocol request (607) and response (608). It said first attribute set A method according to claim 9 or 10, characterized in that it has a signaling properties of the message. The method according to any one of claims 9 to 11, wherein the processing class corresponds to a predetermined position of a recursive message flow according to the session protocol. The processing class includes an execution rule of a first processing class (P1) that provides a signaling property (702) of the message, an execution rule of a second processing class (P2) that provides a non-signaling message body content (704) of the message, 13. The method according to claim 9, comprising an execution rule of a third processing class (P3) that does not give the signaling properties of the message nor the non-signaling message body content. . 14. The method of claim 13, wherein a change message (703) is generated when all execution rules of the first and second processing classes are processed. The first service to be called further outputs a second change message, and the method further includes processing the next execution rule with the first change message as input, and receiving the second change message as input. The method of any one of Claims 1 thru | or 14 characterized by the above-mentioned. The method further comprises:
Storing information about which services are being executed and information about in which order the services are being executed;
Receiving a request from the first service to return a notification to the first service if a predetermined event has occurred;
Storing the request associated with the stored information;
The method according to claim 1, further comprising: notifying the first service according to the stored information when the event occurs. The execution module includes a computer-readable script, and the predetermined processing order of the execution rules is determined according to the order of the execution rules on the script. The method described. The session is associated with a number of subscribers including a caller and a callee, and a service is configured to be activated by a request from the subscriber, and the method is further requested by the callee 18. A method according to any one of the preceding claims, comprising invoking a service requested by the caller before invoking any service. The method according to claim 1, wherein the session protocol is a session initialization protocol. The method according to any one of claims 1 to 19, wherein the communication session is a multimedia session. The method according to any one of claims 1 to 20, wherein the execution rules are configured to be updated dynamically. A data processing system comprising service execution environment modules (201, 301) configured to call a plurality of services (309, 310, 311) activated by a message of a session protocol for controlling a communication session, The data processing system further includes a storage medium (307) configured to store a plurality of rule modules each having a number of execution rules, each execution rule specifying a state invoking a service. ,
The service execution environment module is
-Search for several rule modules,
-As a process of the first rule module of the rule module ,
Are at least part of the execution rules of the first rule module;
A first execution rule for generating a first service to be called and outputting a first change message if the message satisfies a first state;
When the first change message satisfies the second state, a second execution rule for generating the second service to be called, using the first change message as an input,
By processing in a predetermined order , the first cumulative change message is output,
-A rule engine module (303) configured to perform a call process of a second rule module (1217) of the several rule modules that provides the first cumulative change message as input;
The first rule module is assigned a privilege indicating an authority to change a lock flag associated with a predetermined portion of the cumulative change message, and the lock flag includes at least the second portion of the predetermined portion of the cumulative change message. A data processing system characterized by identifying whether or not it is changed by a service called from a rule module. The data processing system according to claim 22, wherein the rule engine module is configured to interpret a predetermined rule execution specific language. The rule engine module further includes a rule base processor module (1601) configured to search for the execution rule, and a rule module processing module (314, 1604) configured to process the execution rule. 1605) The data processing system according to claim 22 or 23.   22. A software program comprising code means configured to perform the steps of the method according to any one of claims 1 to 21 when executed on a data processing system. The software program according to claim 25, wherein the software program is embedded in a computer-readable medium.

Images