Internet Draft R.W. Steenfeldt Expires: November, 2001 H. Smith Ericsson Denmark May 7, 2001 SIP Service Execution Rule Language Framework and Requirements Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document presents a framework for a standardized mechanism to manage the invocation and execution of multiple services. It considers trigger and feature interaction management in a SIP context. The mechanism is based on a Service Execution Rule Language (SERL) used to specify service deployment policies. This document specifies the requirements for SERL. Steenfeldt, Smith [Page 1] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 TABLE OF CONTENTS 1. Introduction..................................................3 1.1. The Application of SERL......................................4 1.2. What are the benefits of SERL................................4 1.3. Conventions Of This Document................................4 1.4. Relationship to other IETF Work..............................5 2. Terminology....................................................5 3. Summary of Problem and Solution................................7 3.1. Triggering and Feature Interaction...........................7 3.1.1. Examples of Violation of Feature Privileges................8 3.1.2. Examples of Violation of Feature Assumptions...............9 3.2. Overview of Requirements to SERL............................10 3.2.1. Solving Violation of Feature Privileges with SERL.........11 3.2.2. Solving Violation of Feature Assumptions with SERL........12 4. Problem Domain and Architecture Framework.....................13 5. Solution Models and Mechanisms................................15 5.1. Rule Module and Rule Module Base............................15 5.2. Cascaded Services Model.....................................16 5.3. The Processing Points Model.................................17 5.4. Arming Model. ..............................................19 5.5. Scalable Administration Models..............................19 5.6. Contractual Relationship Detection Model....................22 6. SERL and the Service Support System: Requirements.............24 6.1. Event Context: Requirements.................................24 6.2. Processing Points: Requirements.............................25 6.3. Rule Module: Requirements...................................29 6.4. Conditions: Requirements....................................30 6.5. Actions: Requirements.......................................30 6.6. Rule Base: Requirements.....................................30 6.7. Privileges and Rights: Requirements.........................30 6.8. Ordering And Prioritizing: Requirements.....................31 6.9. Rule Module Hierarchies: Requirements.......................34 6.10. Arming of Service Execution Rules: Requirements............35 7. Examples......................................................36 8. Related Work..................................................39 8.1. Intermediary Rule Markup Language (IRML)....................39 8.2. Call Processing Language (CPL) .............................39 8.3. Application Server Component Architecture For SIP...........39 8.4. A Model for Service Invocation in SIP using ServiceCodes....40 8.5. SIP Servlet API Extensions..................................40 8.6. 3GPP IMS....................................................41 9. Security Considerations ......................................42 10. Future Work..................................................42 11. Acknowledgments..............................................43 12. Intellectual Property Rights Considerations..................43 13. Authors addresses...........................................43 14. References..................................................43 Steenfeldt, Smith Expires November 2001 [Page 2] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 1. Introduction This document describes the framework and requirements of an infrastructure for the deployment of value added sip services (services that are invoked based on SIP events). This infrastructure is specified in terms of SERL scripts (work-in-progress [10,11]. SERL scripts is really the specification of service deployment policies. SERL scripts are required to specify when and how the set of service applications managed in a domain should be invoked, this is also referred to as triggering management, and is implemented by a triggering mechanism. However, much is gained by building this infrastructure so the deployment policies can be managed and implemented in a scalable and secure way. The main problem is that the features of the invoked and executing service applications can interfere and cause undesired behavior in the service network. The problem is known as feature interaction. In effect it is the features of the service applications that is desirable to manage in a scalable and secure way, this is also referred to as feature interaction management. Just as feature interaction has been, and still is, a problem in circuit switched telecommunication networks, feature interaction will also be a problem in SIP based network [27,29]. To quote [29]: "Feature interactions threaten the main advantage of open networks, namely that features and services can be added rapidly and cost effectively by third party vendors". SERL scripts are required to support the management of triggering and feature interactions on intelligent end-user devices or network servers. The goal of this framework and requirements document is to achieve a mechanism that easily and safely can delegate triggering and feature interaction management to independent administration domains. This would be a fundamental step towards a highly dynamic, open and fast evolving service network, with a diversity of service provisioning only seen on the World Wide Web. SERL must not be limited to invoke services based on SIP events, but may in principle be able to invoke any type of service application based on any type of event, in the context of any type of business model. Nevertheless, this framework document has scoped the focus to SIP events. In principle SERL scripts may be used to manage services for any SIP enabled node. Using SERL scripts, services can be invoked from nodes that implement User Agents, Registrars, Redirect Servers, Proxy Servers, PINT/SPIRITS etc. etc.. We put no requirements on where this mechanism should be implemented. It could be integrated with the SIP node, or another node, like an Application Server or Mobile Terminal. It could also be implemented Steenfeldt, Smith Expires November 2001 [Page 3] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 in a stand alone entity. This document puts no requirements on any architecture framework, as SERL is intended to be as technology independent and generic as possible. 1.1. The Application of SERL Many labels can be put on the application of SERL. It is a format for triggers, a programming language for triggering and feature interaction management, an infrastructure for the deployment of value added services or a way to specify service deployment policies. With SERL it must be possible to: 1) trigger multiple services based on any headerfield and value of SIP (be it a request or response), its subordinate protocols and encapsulated media types. 2) trigger originating, terminating and forwarded-by services based on the same event. 3) specify triggers on several independent levels, e.g. trigger Application Servers, trigger a next hop SIP server or trigger named Service Applications on local or remote hosts, as determined by the deployment policy. 4) specify service platform independent triggers. 5) map service platform specific triggers, like Camel triggers, to the SERL format. 6) manage feature interactions (see later what exactly this means). 7) extend the functionality as required. 8) delegate the responsibility of administrating SERL scripts to independent parties. 9) host third party services in an open network. 1.2. What are the benefits of SERL 1) A powerful triggering mechanism as provided by SERL, optimizes the performance of the service network. 2) As SERL provides service platform independent triggers, it allows interworking between service platforms, i.e. the service network does not need to know in advance which type of services that will be deployed in the network. It provides a robust and future proof strategy for service network investments. 3) Management of the services that have to be deployed in the service network can be delegated to independent parties. This makes the management of services scalable. 4) Because of point 3, third party service providers can be hosted in the service network, without the mediation of the administrator of the service network. 1.3. Conventions Of This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9]. Steenfeldt, Smith Expires November 2001 [Page 4] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 1.4. Relationship to other IETF Work This work is inspired by the work-in-progress about a proposed extensible proxy services framework as described in [2,3,4] and by the work-in-progress about the Call Process Language [13,14]. Throughout the document the reader is expected to be familiar with the SIP specification [7]. 2. Terminology action: a named application, routine, function, process etc. etc.. administration domain: an area of responsibility administrated by a single entity. arming: request for an event report for a specified event context. arming a service execution rule: add a service execution rule to the rule base. arming a transaction event: when a rule for re-invoking an application is added to the Rule Engine(and possibly added to the rule base) where the event must occur within the context of the same SIP transaction that triggered the application. constraint: a regulation of what is allowed and what is not allowed. deploy: to install and activate disarming a rule: remove a service execution rule from the rule base. event: an event represents a set of properties, that at a given time in a given context has a given value. event context: an event that represents a SIP message. event report: when a service application is notified about the occurrence of an event. feature: a visible effect of a service application execution. This type of feature is also called a customer feature. feature assumptions: when one feature assumes something about another feature. feature group: a collection of features that can be categorized as belonging to the group. It could be that the features behave in a similar way due to constraints put on the features. Steenfeldt, Smith Expires November 2001 [Page 5] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 feature instruction: an instruction from a service application specifying how the application wishes to perform control of an event. feature interaction: when features interfere in one way or another. feature interaction management (FIM): management of features as to avoid undesired feature interactions. feature privileges: features are restricted to operate within the boundaries of some allocated feature privileges, like access privileges to system resources or API"s. filtering: a selection of objects based on well-defined criteria"s. forwarded-by services: type of originating services invoked by a callee that forwards a session to a new destination. interrupt mode: when the processing of the rule base is put on hold until an invoked service application gives back control. invocation: to activate the execution of an application, routine, function, process, etc. etc.., i.e. to process the action. message property: a named element of a sip message with a value. notify and continue mode: when the processing of the rule base continues even when a service application has been invoked. originating services: services invoked on behalf of a caller. processing point: a well defined location in the round trip SIP message flow, where actions can be performed. rule base: consists of a collection of rule modules. rule engine: an entity that processes a relevant collection of the rule base. rule module [3]: consists of a collection of owner, context and service execution rules. rule module filter: a filter that maps an event context to a subset of the rule modules in the rule base. serl: service execution rule language, a programming language used to specify rule modules. service definition: used in the context of a SIP enabled node that is controlled by a service support system. The service definition Steenfeldt, Smith Expires November 2001 [Page 6] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 of the SIP node describes the value added services mediated through that SIP node. service execution rule: consists of a collection of conditions that points to one or more actions. service support system: a system that implements triggering and feature interaction management. sip service provider: a service provider that owns a SIP service network domain, and offers SIP subscriptions to end-users, i.e. a SIP URL. The SIP service provider may also offer to host third party services in the domain. stakeholder: a person, group or organization whom has an interest, in the SIP node, to protect. terminating services: services invoked on behalf of a callee. third party service provider: a service provider that is independent of a particular service network domain. trigger: is a list of conditions that has to be true before an action can occur. triggering: the process of invoking one or more service applications (and other actions) based on an event. triggering management (TM): management of trigger information. 3. Summary of Problem and Solution This chapter will briefly describe the problem of triggering and feature interaction, and give an overview of the requirements we put on SERL to solves these problems. 3.1. Triggering and Feature Interaction This chapter will shortly discuss the problem of triggering and feature interaction. It is the view of the authors that these two problems are closely related (at least to a certain extend). Currently only the Single-User-Single-Component (SUSC) scenario [28] is considered. Triggering is simply a mechanism for invoking one or more service applications when an event occurs. A minimal implementation of a triggering mechanism that does not care about feature interactions on a SIP enabled node consists of a procedure that invokes all named Service Applications on that node, simultaneously, or in random order, and on any possible event. Steenfeldt, Smith Expires November 2001 [Page 7] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 This of course blows up the problem of feature interactions to unmanageable proportions, as all Service Applications potentially can cause feature interactions at run-time. The problem with this mechanism is that ensuring correct behavior of the node is entirely a problem that has to be solved by the Service Applications invoked on that node. Given an event, the Service Applications must determine if their features are supposed to service that event, and if the conditions to serve it are fulfilled. The Service Applications also have to fight for resources, privileges and rights, i.e. to manage feature interactions in a possible non-deterministic environment. Clearly this mechanism is not desirable to implement in a Service Network. The causes of feature interactions we consider in this document are subset of causes we can term "violation of feature privileges" and "violation of feature assumptions". There are many other causes of feature interactions described in the literature, but they are not considered here. In this document we assume that the stakeholders are properly authenticated before the triggering mechanism is applied. Cause group 1: Violation of Feature Privileges Privileges of features are broken if they are invoked redundantly or by un-authorized parties. Or if features are invoked by authorized parties, but uses un-authorized resources. Cause group 2: Violation of Feature Assumptions [28] Assumptions about feature behavior are broken when a feature"s context is changed by another feature. In the triggering mechanism described above most service applications would cause feature interactions as they would violate feature privileges. Most service applications would likely be invoked redundantly, thus participate in the fight for resources. Unless each service application would be invoked in a separate processor, this would cause a severe performance problem, and the result would be non-deterministic. 3.1.1. Examples of Violation of Feature Privileges The main problem caused by violating feature privileges is redundant consumption of resources, or unauthorized access to resources. This may be un-intended or malicious in nature. When violation of feature privileges occur, there is a fight between features, authorized or non-authorized, for access to the resources. If features are invoked redundantly or by un-authorized parties, they may subsequently be the cause for violation of feature assumptions. Clearly avoidance of violation of feature privileges is desirable. Steenfeldt, Smith Expires November 2001 [Page 8] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Redundancy: This is when a service application with no reason or contractual obligations is invoked. This causes unnecessary performance penalties. Un-authorized Feature Invocation: This is when some party or entity invokes a service application without the authority to do so. This is either an error or a malicious attack to the system that must be detected and prevented. Un-authorized Feature Instructions: All feature instructions are potential un-authorized instruction sets, unless they are explicitly authorized. Un-authorized feature instructions can have a malicious nature or be the result from a buggy service application. In any case they can do damage to the safety and integrity of the system and should be detected. Un- authorized feature instructions could be requests for event reports. 3.1.2. Examples of Violation of Feature Assumptions Features are the visible behavior of executing a Service Application. The instruction the Service Application issues to control the value added behavior of the SIP node is termed a feature instruction. However, many features may apply their behavior to the current event context before the controlling instruction is sent back to the SIP node. The controlling instruction or instruction set that is sent back to the SIP node is termed a service control instruction. It contains a resulting event context, i.e. the properties of SIP messages that have to be sent upstream or downstream in response to the original event context that triggered the Service Applications. Ambiguous Behavior: Ambiguous behavior occurs when the service control instruction is different depending on the sequence in which the features gain control over the current event context. Ambiguous feature instructions are not necessary mutually exclusive. As an example take the original event context, and let the SIP message body contain a color picture in gif format. Define S1 to be a service application that is triggered on message body content of gif format. Let S1 be a service application that converts the gif format into a jpg format. Define S2 to be a service Steenfeldt, Smith Expires November 2001 [Page 9] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 application that also is triggered on message body content of gif format. Let S2 be a service application that converts the gif picture into a black and white picture. Let S1 be the first application to be invoked, triggered by the gif content. S1 will convert the gif picture to a jpg picture and write it to the current event context. S2 will never be invoked. The resulting event context will contain a color jpg picture. Now let S2 be the first application to be invoked, triggered by the gif content. S2 will convert the color gif picture into a black and white picture and write it to the Current Event Context. S1 will subsequently be invoked based on the gif content as specified by the current event context. S1 will convert the gif picture to a jpg picture and write it to the Current Event Context. The resulting event context will contain a black and white jpg picture. Clearly S1 and S2 provides ambiguous behavior, because one features context is changed by the other. Conflicting Behavior: Conflicting feature instructions are instructions that are mutually exclusive. Conflicting instructions will try to override each other. In this case conflicting instructions are typically also the cause of ambiguous behavior. A typical example is when one service application say "proxy" and another say "redirect". Monitoring Service Applications: Monitoring service applications may cause additional problems as those already discussed. Monitoring service applications may issue asynchronous feature instructions towards the SIP node at any time as they are running continuously. As they are monitoring for future events, they may process on these events and provide more feature instructions. If there are multiple simultaneous monitoring service applications then their generated feature instructions may depend on the order in which they are notified about the event. This adds to the complexity of the previously discussed problems. 3.2. Overview of Requirements to SERL This chapter will briefly give an overview of the requirements we put on SERL in order to solve violation of feature privileges and assumptions as described in the previous chapter. Generally SERL MUST be as simple as possible, yet powerful enough to be robust concerning future requirements and extensions. Steenfeldt, Smith Expires November 2001 [Page 10] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 SERL MUST provide a generic solution for specifying triggering criteria"s. It MUST be possible to use any property of a SIP message as criteria for the triggering. It MUST be generic enough so future work can specify trigger criteria"s based on a subordinate protocol embedded in SIP. SERL MUST also be independent of service platforms. SERL MUST be scalable in terms of management, and make it possible for service network domains to host third party services with little or no extra cost for the administrator of the service network domain. Before SERL scripts can be specified the owner of the service applications has to perform an analysis of the features to be deployed, to detect causes of feature interactions. This analysis is not within the scope of this document. However, knowing how to map the analysis results to SERL deployment policies may aid managing the analysis. 3.2.1. Solving Violation of Feature Privileges with SERL Filtering on Context: When an event occurs it must be interpreted in a certain context. This problem is becoming visible when managing networked multimedia services that operate in a converged network. One phase of the feature interaction analysis must detect which event context the feature must trigger on. The SERL MUST support a way to specify a context. Filtering on Contractual Relationships: When an event occurs it must be mapped to a set of features that is contractually obliged to process that event. This problem is becoming critical in a de-regulated market where not only the provider of the network infrastructure and session control services can offer value added services to subscribers, third parties have a legal right to make that offering as well. Another phase of the feature interaction analysis is to detect contractual relationships between all involved parties that have an interest in the feature. The SERL MUST support a way to specify contractual relationships. Filtering on Access Control Policies: When an event occurs it must cause only authorized behavior at the node. Another phase of the feature interaction analysis is to detect which parties explicitly have access to manage the triggering (invocation, notification) of the feature, and who have explicitly access to perform the triggering. The SERL MUST support a way to specify access policies. Filtering on Conditions: Steenfeldt, Smith Expires November 2001 [Page 11] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 When an event occurs and features to be invoked are detected based on the context, on contractual relationships and access privileges, a last filter can be applied as to ensure that the feature is not invoked redundantly. For each feature a condition mask can specify detailed criteria"s as for when to invoke it. These conditions may depend on e.g. the properties of the event, system properties or network properties. The SERL MUST support a way to specify conditions. 3.2.2. Solving Violation of Feature Assumptions with SERL To detect and resolve violations of feature assumptions is much more complicated than to resolve violations of feature privileges. SERL will currently support the means to specify how to resolve ambiguous behavior, means to divide the feature interaction management in independent feature groups and administration domains, and a simple default rule to resolve feature interaction interference detected at run-time. The SERL requirements concerning avoiding violation of feature privileges is closely associated with mapping of events to a proper set of actions, i.e. a proper set of features that is obliged to process that event under the given conditions. The SERL requirements concerning avoiding violation of feature assumptions are different in nature, as it is associated with managing interactions of run-time feature instructions. But also with specifying how to manage this in a scalable way off-line. Avoid Ambiguous Behavior through Feature Ordering: When the management of a feature is added to the triggering mechanism, then it must not be the cause of ambiguous behavior. One phase of the feature interaction analysis is to detect ambiguous behavior between features. The SERL MUST support a way to specify an ordering of feature invocation. Default Feature Interaction Resolution based on Priorities: When the management of a feature is added to the triggering mechanism, then it must not be the cause of conflicting feature instructions. One phase of the feature interaction analysis is to detect conflicting interferences between features. The SERL MUST support a default mechanism to resolve this when it is detected at run-time. Rules for Managing Monitoring Service Applications: When the management of a feature is added to the triggering mechanism by it-self, then it must not be the cause of feature interactions. One phase of the feature interaction analysis is to detect when and Steenfeldt, Smith Expires November 2001 [Page 12] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 why service applications should request for notification of future events. The SERL MUST support a mechanism to manage asynchronous issued requests for event reports. Decompose Feature Interaction Analysis in Independent Feature Groups: When the management of a feature is added to the triggering mechanism, then it must be possible to categorize it according to constraints on its behavior. I.e. to allocate it to a specified feature group. Feature Interactions between these categorized feature groups MUST be deterministic, i.e. feature groups are visited in a specified order and hand over of control from one feature group to the next must be well defined. Internal feature group behavior is not visible between feature groups. One phase of the feature interaction analysis is to detect the behavior of features and categorize them in feature groups. The SERL MUST support a way to specify an association between a given feature and some feature group, and to give the feature groups an ordering. Decompose SERL Management in Independent Administration Domains: When the management of a feature is added to the triggering mechanism, then it must be possible to associate it with an independent Administration Domain with specified privileges. One Administration Domain may administrate features belonging to multiple feature groups. One phase of the feature interaction analysis is to detect the needed privileges needed to administrate properly a given set of features. The SERL MUST support a way to specify an association between a given feature and some Administration Domain, and to give the domain an ordering. 4. Problem Domain and Architecture Framework The problem domain of the SIP SERL framework and requirements is a system that implements triggering management (TM) and feature interaction management (FIM) in a SIP context. This system is termed the Service Support System. The architecture framework is depicted in figure 1. The environment of the Service Support System is one or more SIP Nodes, Service Applications, Remote Hosts and an Administration Entity. The Administration entity is responsible for configuring the Service Support System, which is associated the domain of the SIP Node. The SIP Node can be any SIP enabled entity that needs to trigger value added services. The SIP Node may hand over control to the Service Support System on reception of an event. The Service Support System may subsequently invoke one or more relevant Service Applications according to some trigger criteria based on that event, and receive back a feature instruction or set of instructions. The Steenfeldt, Smith Expires November 2001 [Page 13] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Service Support System will of course at some point hand back control to the SIP Node, mediating the feature instructions as to inform the SIP Node about how to respond to the event. 0 0 -+- -+- /\ /\ Service Appl. Remote Host \ / \ / +-----------------+ 0 | Service Support |-------- -+- | System (SSS) | /\ | | Administration | TM / FIM | Entity | | +-----------------+ | | | 0 -+- /\ SIP Node Figure 1 SSS Context Diagram using UML Notation Based on e.g. system and network performance criteria"s the Service Support System can hand over control to some remote host, which e.g. could be an Applications Server. In this way different categories of services could be invoked and managed at different hosts in a specified order. This document leaves it open where the Service Support System is implemented in the network. Three phases are needed when using SERL to specify service deployment policies. 1) Administration Phase: This is where privileges are negotiated between the Administrator of the Service Support System and the parties that wishes to deploy SERL scripts in the domain. 2) Feature Analysis Phase: This is when an entity either human or non human analyzes all possible scenarios in which features may interact based on its knowledge of the features and how they are implemented. The analysis phase results in possible causes for feature Steenfeldt, Smith Expires November 2001 [Page 14] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 interactions, here in a SIP context. And a feature deployment strategy. 3) SERL Specification Phase: This is where an entity uses the results and deployment strategies from the analysis phase to specify some policies that can be used to mediate between the requirements of the features. This will result in the creation of SERL scripts. The Administration Phase and the SERL Specification Phase is within our scope but not the Feature Analysis Phase as such. 5. Solution Models and Mechanisms Defining, managing and processing SERL is based on some useful models and mechanisms that will be summarized in this chapter. These models are capturing high level requirements for SERL. More precise requirements will be specified in the next chapter "SERL and the Service Support System:Requirements". 5.1. Rule Module and Rule Module Base This section is mainly inspired from [3]. The main model for implementing SERL is the Rule Module. A Rule Module must have a single Owner. By Owner we mean an identifiable party with an interest in the SIP node. This party may own multiple Rule Modules. A Rule Module must also relate to a specified Context, which is relevant in order to process the Rule Module properly, in this document however, the context is SIP. A Rule Module contains Service Execution Rules that specify Conditions, and Actions that need to be taken if the Conditions are fulfilled. The Context specifies how the Conditions must be interpreted, when receiving an event. Access Control Policies must be associated with the Rule Module specifying who can read, write and execute the Rule Module. A Rule Module is conceptually a tree structure, see figure 2. SERL could with advantage specify a Rule Module as an XML [5] application, as this is a standardized and extensible language to specify languages. Rule Modules are managed and executed by an entity termed a Rule Engine. When an event occurs and is handed over to the Rule Engine, the Rule Engine will filter the relevant Rule Modules, and process those that are relevant to handling the event. In other words, based on detection of contractual obligations Rule Modules are invoked by Steenfeldt, Smith Expires November 2001 [Page 15] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 the Rule Engine. The Event define the context in which Rule Modules are processed, i.e. the Conditions are evaluated according to the properties of the SIP message events. If a condition matches the properties of an event, it may fire one or more Actions. Based on the content of these Actions, the Rule Engine may issue invocation instructions to an appropriate entity within the Service Support System. Notice that Rule Modules do not have knowledge about the services that they invoke and manage. The feature instructions received from the invoked service applications are mediated back to the SIP node when the last Rule Module has been processed. +-------------+ +--------+ | Rule Module |------| Policy | +-------------+ + -------+ | +--------------------------------+ | | +-------------+ +-----------+ | | | Service | | | | Execution | | | | Rule | +-------+ +---------+ +-----------+ | Owner | | Context | | +-------+ +---------+ +--------------+ |Conditions(s) | +--------------+ | +-----------+ | Action(s) | +-----------+ Figure 2 Rule Module Structure The collection of Rule Modules that are managed by a Rule Engine is called a Rule Base. 5.2. Cascaded Services Model The Cascaded Services Model is a model that helps with assessing assumptions and has been used widely in Intelligent Networks and Telephony. Basically the model says that triggering of service applications on the same host, shall be performed in the same sequence as if triggering had occurred on different host". This also applies to monitoring applications on the same host, as they should be notified in the same sequence as if they were monitoring applications on different hosts. The sequence of invoked service applications is termed a cascaded chain. Steenfeldt, Smith Expires November 2001 [Page 16] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 In this model when a Request is received at a host then the earlier the service applications is invoked, based on this event, the more logically upstream it is considered to be in the chain of cascaded service applications. In our framework we will not put requirements on when a service application should be able to be invoked. Service applications should in principle also be able to be invoked on responses. When a response is received then the earlier the service application is invoked, based on this event, the more logically downstream it is considered to be in the chain of cascaded service applications. This model provides a natural algorithm for resolving conflicts between the feature instructions of multiple service applications controlling the same event. This is because it is possible to allocate priorities to the feature instructions based on where in the cascaded chain the service applications are located. On reception of a SIP event the service applications are invoked by the Rule Engine in order of priority, as specified in the relevant SERL scripts. In the normal case the next service application is not invoked, before the current service application in control has given back control to the Rule Engine. In this way a decision about whether to invoke a subsequent application can depend on the output from the previous application. It may be that an application forks the request. In this case there is not a simple chain of cascaded service applications but rather a tree of cascaded service applications. We have termed this tree the Cascaded Chain Tree. A Cascaded Chain Tree represents a number of Cascaded Chains of applications. The path from the root of the tree to each of the leaves represents a Cascaded Chain. The leaves of the tree are the resulting event contexts, i.e. the controlling instructions from the service applications that are to be mediated back to the SIP node. If there are multiple Rule Modules that are processed, then the generated event contexts are handed over to the next Rule Module, until there are no more relevant Rule Modules. For each Rule Module that is processed more of the Cascaded Chain Tree is built. In some cases it may be that an application gives an asynchronous Feature Instruction to the Service Support System, i.e. it is not related to an existing transaction. In this case the application has started a new transaction and is considered to be at the root of a new Cascaded Chain Tree. 5.3. The Processing Points Model This is inspired by [3] and is adapted for a SIP context. Steenfeldt, Smith Expires November 2001 [Page 17] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 This model provides a framework for grouping our problem into constrained sets of features. The model actually solves feature interactions between these feature groups, because the feature assumptions when handing over control from one group to the next, is deterministic and well-defined. However, the model does not solve feature interactions within the feature groups. The model is only a part of a solution to manage feature interactions. The main purpose of this model is to provide a mechanism that can decompose the problem of feature interaction analysis into smaller manageable areas. Processing points represent locations in the round trip SIP message flow which have certain pre-conditions guaranteed for the event context. Processing Points also specify constraints on behavior that is allowed by any Service Application (its features) at that location. All Service Aplications must be assigned to one of the Processing Points. In effect, Service Applications associated some Processing Point can only be invoked when the Rule Engine processes Service Execution Rules associated that Processing point. The SIP processing points can roughly be divided into 7 groups. More refined processing points could be defined in future work. The reason for these processing points is that a SIP message can roughly be divided into two parts, the SIP signaling properties and the rest. In addition service applications invoked on a SIP Event Context can be grouped into feature groups that compose: 1) feature groups with no constraints on their behavior. 2) feature groups that are allowed to control the SIP signaling properties for either requests or responses. 3) feature groups that are allowed to control message body content for either requests or responses (including relevant SIP headers like "Content-Length"). 4) feature groups that are not allowed to perform any control of the SIP message for either request or responses. This gives the basic grouping of features into seven groups, associated seven processing points. In each processing points the service applications are adding their control to the current event context. The definition of these processing points is given in the next chapter. Notice that in all processing points, it is possible to trigger on any (visible) property. The constraints specified for processing points are only concerning the scope of control a given feature group is assigned. A SIP message may contain sub-ordinate protocols like SDP. Future work might specify processing points for these sub-ordinate protocols Steenfeldt, Smith Expires November 2001 [Page 18] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 and other media types. For the moment it is the responsibility of the Rule Modules to specify when Service Applications to control SDP should be invoked. 5.4. Arming Model. Service Applications invoked by the Rule Engine may terminate immediately after they have handed over the first feature instruction. Other service applications do not. In addition to giving feature instructions and to create new SIP transactions, applications also need to be able to arm for future events. For example these events could be responses to requests, or end of session indication (BYE). These service applications then become monitoring applications. The mechanism for an application to request for event reports can be tied to the processing of a SIP transaction, which is bounded in time, or to future events, which may be un-bounded in time. For this reason we distinguish between two types of event armings. 1) Arming a Transaction Event. This is the arming of events that are related to an existing SIP transaction, for example responses and CANCEL requests. These armings survive only the length of the transaction, and is automatically disarmed when the transaction terminates. 2) Arming a Service Execution Rule. This is when an application adds a new service execution rule to the rule base. Here the application must specify some conditions for the event report. It seems natural that the conditions are of the same nature as those in the SERL scripts. These armings can be added to the Rule Base in appropriate Rule Modules, for example one owned by the application"s owner. They can be permanent or they can be armed with a specified time-out value. They can also be armed in report once then disarm mode. By combining the arming model and the cascaded services model a solution for the order in which events should be reported to multiple monitoring applications is straight forward. This greatly simplifies the complexity of the Service Support System and the job of SERL script authors. For example, responses can be reported first to the downstream most applications and Cancel Requests first to Upstream most applications. 5.5. Scalable Administration Models To manage and implement Service Deployment Policies must be a scalable administrative task. This means that the time and cost used by the administrator to manage the Rule Base for some domain must not increase, if the relation between added independent and free administration resources grows linear with the size of the Rule Base. Steenfeldt, Smith Expires November 2001 [Page 19] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 The key issue is that the Service Support System must be able to host third party service deployment policies, without extra work for the domain administrator. In addition the Service Support System must not place any limitations on the number of stakeholders or the number of contractual relationships between them. Contractual relationships established directly between subscribers and third party service providers must be possible to enforce without the mediation of the service network domain administrator. On the other hand in order to manage feature interactions there must at some point be feature interaction analysis experts that are responsible for analyzing possible feature interactions and specifying feature interaction resolution strategies. The problem is that no one administrator can analyze all feature interaction problems. The only solution is to distribute the problem between the concerned parties. Some models to handle this are described in the following. Prioritized Administration Domain Model: Rule Modules are the smallest possible administration domain where an administrator (rule module owner) can specify service deployment policies. Rule Modules must have a specified priority in the Rule Base. The priority specifies the relationship between Rule Modules. The higher the Rule module priority, the earlier the service execution rules in the rule module are applied. Service execution rules are applied in sequence of the processing points though, so the Rule Module priority is applied to service execution rules in the context of the current processing point. Before handing-over control to a lower priority Rule Module, the service applications invoked from a rule module must be able to protect (lock, hide) message properties in the event context, if they have the privileges to do so. This is part of the mechanism to hand over control from one domain to the next. The benefits with this model are that the administration domains are totally independent. This technique requires that an overall administrator assigns the priorities of the rule modules based on contractual relationships with each of the rule module owners. The overall domain administrator would naturally also be the owner of the highest priority rule module. It might be that this top-level administrator would like to intersperse the priority order with a number of rule modules. The overall domain administrator is of course free to do this. However there is no obvious way to intersperse rule modules with lower priority rule modules of other parties. This could be a possible draw back of using purely rule module priorities to achieve the hierarchy of administration domains. One solution is to separate Rule Module priorities with sufficient back-up ranges that can be used at a later time, or to use the Hierarchical Administration Domain Model described next. Steenfeldt, Smith Expires November 2001 [Page 20] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Hierarchical Administration Domain Model: At the top of the hierarchy is the SIP Service Provider who owns the domain name and IP address of the SIP Server. The SIP service provider may provide many services to many parties. The SIP service provider may also run applications for own purposes, like logging, accounting, statistics gathering, fraud detection, advertising etc. The SIP service provider, or the domain administrator, may therefore own and deploy one or more rule modules. It would be natural for example for the SIP Service Provider to create a Rule Module for each of the subscribers. When an event occur the SIP Service Provider may have a master Rule Module, that may invoke some system features first and subsequently hand over control to a Rule Module for the appropriate subscriber. This mechanism of invoking Rule Modules from within Rule Modules gives a hierarchical distribution of administration domains, also called the hierarchical administration domain model. The benefits with this model are that it is easy to administer, and gives a high degree of control to the master Rule Modules. This model can of course be interleaved with the prioritized administration domain model. At some point in the order priority of Rule Modules, control may be handed over to a Rule Module owned by the actual subscriber. Note that individual subscribers would not be expected to write SERL scripts, but they may be able to update preferences with e.g. a HTML form, from which a SERL script could be automatically generated. The subscribers Rule Module may subsequently invoke e.g. a CPL script [14]. Inter Administration Domain Model: Each administration domain must be independent of other administration domains, under specified conditions. This means that one administration domain has no knowledge of the services deployed in other domains. If each administrator is responsible for analyzing and specifying service deployment policies in one given domain then how is inter administration domain feature interaction handled? One mechanism is to allow administration domains to protect their feature instructions when handing over control to another administration domain. This means that each administration domain only needs to hand-over control of properties that are unimportant to the correct behavior of its features. The object that is passed from one administration domain to another is the current event context. When handing over the control of the event context between service applications belonging to the same Steenfeldt, Smith Expires November 2001 [Page 21] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 administration domain, the default rule is that no properties of the event context are protected. If something has to be protected, then it has to be done so explicitly. Between administration domains all properties of an event context are protected by default. If something is not necessary to protect between administration domains, then it has to be explicitly marked un-protected. The Service Support System must support some way of notifying administrators when an application attempts to alter a protected property. An application that attempts to alter a protected property should be immediately taken out of service. Delegation of Administrative Authorities Model: Within a given administration domain each administrator must have the responsibility and privileges to define lower priority administration domains within that domain. Subsequently the administrator can delegate administration responsibility and privileges to that domain. 5.6. Contractual Relationship Detection Model The mechanism of mapping SIP events to relevant Rule Modules is the key to processing the Rule Base. This process very much depends on the contractual relationships negotiated between the subscriber on one side and the domain and third party service providers on the other side. Main Principle: The basic principle is to take the owner information from the rule module and match it with some properties in the SIP event. If there is a match then there is also a contractual relationship, and thereby a contractual obligation, that dictates that the identified rule module must process on that event. A SIP event contains some message properties that could be used to detect a possible contractual relationship: siprequest.from siprequest.to siprequest.RequestURI sipresponse.from sipresponse.to sipresponse.contact sipresponse.via Basically it is the From and Request-URI of a SIP message request that is the most important properties of an event used to detect a contractual relationship. Other message properties could be taken into account like contact headers and via headers, but how to use these if at all is for future work. Steenfeldt, Smith Expires November 2001 [Page 22] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 The owner information in a Rule Module, must contain a unique identity. In order to implement the detection mechanism it must be possible to relate this unique identity with some values of the SIP message properties. Subscriber-Domain Contract Detection: Consider a scenario in which the SIP node is a proxy server. If a SIP request message arrives at the proxy at least one of the From or Request-URI message properties must specify a subscriber that has a contractual relationship with one of the SIP service providers of that domain. Here a SIP service provider is the owner and provider of the SIP domain, and possibly also value added SIP services. The message properties of From or the Request-URI will contain either a domain name, like sip.exampleX.com, or an IP address of one of the SIP service providers of the SIP Server, like a.b.c.d. In addition the From and Request-URI will contain a subscriber identifier, like a name R.W.Steenfeldt, or phone number 12345678. This is contained in the SIP URL or TEL URL. The SIP-URL also have parameters like "transport-param", "user-param" and "other-param". These parameters can contain Network Operator specific information, such as the IMSI to identify mobile terminals and subscribers. Each of the SIP service providers of the proxy server must have a unique domain name, like sip.exampleX.com and sip.exampleY.com and so on. They must however have different IP addresses. This is not a problem since a host on the Internet may have multiple IP addresses. If they do share the same IP address like a.b.c.d, then conjectural relationship resolutions may be ambiguous, as the message properties of the From and Request-URI may contain an IP address and not a domain name. If the SIP service provider(s) is also a Telephony Network Operator their unique identity could also contain unique Fixed Telephony Number Series or IMSI ranges if these types of subscribers need to be identified at the proxy server as well. It is now easy to map a subscriber to a unique SIP service provider, indicating a contractual relationship. All of this of course assume the parties are proper authenticated. Subscriber-Third Party Contract Detection: Subscribers may also have a contractual relationship with some third party service providers. How could this be detected? First of all the third party service providers that wish their services to be invoked and managed from a given SIP service providers domain, must have been granted the privileges to upload/register SERL scripts to the domain by the SIP service provider. The third party service provider must have a contractual relationship with the SIP Steenfeldt, Smith Expires November 2001 [Page 23] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 service provider to allow third party service hosting. In our example scenario it must be possible for the third party service provider and some subscriber (in the subscriber base of the SIP service provider) to negotiate and deploy a contract for service provisioning directly without the mediation of the SIP service provider. The third party service provider ABC must receive an allocated and unique identity from the SIP service provider with whom the third party service provider has a contractual relationship. If the SIP service provider has domain name sip.exampleX.com and associated IP address a.b.c.d, then the third party service provider could be given a unique identity like (ABC, sip.exampleX.com, a.b.c.d). Again it is easy to match the From and Request-URI to relevant Rule Modules. As Rule Modules with owner information (sip.exampleX.com, a.b.c.d) or (ABC, sip.exampleX.com, a.b.c.d) both should be invoked on an event containing the resource sip.exampleX.com in either the From or Request-URI. They must of course be invoked in a specified order. It is up to the third party service provider to specify in the Rule Module more accurate conditions as to check if the subscriber also has a contractual relationship with the third party, and not only with the Domain owner. More efficiently perhabs would be to use the SIP-URL parameters like "transport-param", "user-param" and "other-param" to specify the relationship with the third party. E.g. the "other-param" could contain the name "ABC". Other matching mechanism for contract detection could easily be introduced. Groupings of Contractual Relationships: A subscriber account do not necessarily represent a single end-user, but could represent a group of end-users. This could be implemented by creating a special SIP URL for that group, or to specify the group associations in the SIP-URL parameters like "transport-param", "user- param" and "other-param". Alternatively a Rule Module could specify conditions that detect groupings of subscribers. One way to do this would be to have an action in the rule modules of the relevant subscribers that points to a "group" rule module. Common services for the group could then be specified in this "group" rule module. There are no restrictions in a Rule Module as to where service execution rules like this should be placed. It could be both from a Rule Module owned by a SIP service provider, or from a Rule Module owned by a third party service provider, or even from within the Rule Module of a subscriber. 6. SERL and the Service Support System: Requirements This chapter specifies the requirements discussed in the previous chapter. 6.1. Event Context: Requirements Steenfeldt, Smith Expires November 2001 [Page 24] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 When an event occurs, an event context MUST be established containing the relevant properties of the event, in a standardized way. The message properties must be standardized because they are part of the syntax of SERL conditions. Message properties in an Event Context MUST have a name and a value. The value MAY be determined by the message. Examples of SIP message properties: Name: sipRequest.Request-URI Value: sip:Rico@ericsson.com Name: sipRequest.To Value: R.W. Steenfeldt Name: sipResponse.Status-Code Value: 301 It MUST be possible by a privileged feature to lock or unlock a message property, i.e. if the feature has the privileges to do so it can set the access privileges for message properties for subsequent invoked features. Likewise it SHOULD be possible by a privileges feature to hide a certain message property (make it in-visible for non privileged features), and un-hide it (make it visible). 6.2. Processing Points: Requirements Processing points MUST be standardized, and MUST apply the following format. Name: Category: Previous: Next: Purpose: Pre-condition: Constraint: Post-condition: Description: Processing points that invoke service applications as events travel downstream MUST be named D-. Processing points that invoke service applications as events travel upstream MUST be named U- . Processing points that invoke service applications independently of whether events travel downstream or upstream MUST be named UD-. Seven processing points are defined in this document. Steenfeldt, Smith Expires November 2001 [Page 25] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Feature1 Feature2 Feature3 | | | 0: UD-Root | | | 1: D-RequestReceived +-------------------+ 2: D-RequestBody | 1 2 3 | 3: D-RequestBatch | | -1: U-ResponseReceived | 0 SSS 0 | -2: U-ResponseBody | | -3: U-ResponseBatch | -3 û2 -1 | +-------------------+ | +-------------------+ req. | | req. -------->| |--------> | Sip Node | <--------| |<--------| res. | | res. +-------------------+ Downstream (+) ------------------> Upstream (-) <----------------- Figure 3 Processing Points Service Applications that apply control of the SIP Node based on Request events, are invoked at processing points 0,1,2 and 3 respectively. New generated requests begin at processing point 1 and new generated responses begin at processing point û1. Service Applications that apply control of the SIP Node based on Response events, are invoked at processing points 0,-1,-2 and -3 respectively. New generated requests begin at processing point 1 and new generated responses begin at processing point û1. For a SIP Request that is to be proxied, the proxy request event context may traverse Processing Points 0,1,2 and 3 before mediated back to the SIP Node. A 100 Trying provisional response may be generated at Processing Point 1, and is send to Processing Point û1,- 2 and û3 respectively before it is mediated back to the SIP Node. For a SIP Request that is to be redirected, the request event context may traverse Processing Points 0 and 1, before a redirect response is generated. The redirect response event context is handed over to Steenfeldt, Smith Expires November 2001 [Page 26] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Processing Points û1, -2 and û3 respectively before mediated back to the SIP Node. Processing Points Definition: Name: UD-Root Category: Root Previous: None Next: D-RequestReceived Next: U-ResponseReceived Purpose: To invoke/notify service applications on events independently of whether they are travelling upstream or downstream. Pre-condition: Any Event is received. Constraint: No constraints, anything is possible. Post-condition: Request or Response received. Description: - Name: D-RequestReceived Category: Request Previous: UD-Root Next: D-RequestBody Purpose: To invoke service applications that are allowed to control the signaling response to the SIP request message. Pre-condition: A request is received. Constraint: Message body content is locked. Post-condition: SIP signaling headers updated and locked (i.e. they can no longer be updated), except possibly: Alert-Info Call-Info Content-Disposition Content-Encoding Content-Language Content-Length Content-Type Require Description: The invoked service applications can in response to the request either proxy the request, generate new requests or responses. Name: D-RequestBody Category: Request Previous: D-RequestReceived Next: D-RequestBatch Purpose: To invoke service applications that are allowed to control the message body content of the response to the SIP request message. Pre-condition: The SIP signaling headers has been updated and locked (with a few exceptions). Constraint: SIP signaling headers is locked, except possibly: Alert-Info Call-Info Content-Disposition Content-Encoding Steenfeldt, Smith Expires November 2001 [Page 27] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Content-Language Content-Length Content-Type Require Post-condition: SIP message body and related SIP headers updated Description: Possible types of media content that may be processed at this point could be SDP, SOAP, HTML, vXML, SMIL, gif, mpeg7, au, etc. etc.. Name: D-RequestBatch Category: Request Previous: D-RequestBody Next: None Purpose: To invoke service applications that are not allowed to control any aspect of the response to the SIP request message. Pre-condition: The responses to the SIP request message has been generated and locked. Constraint: The responses to the SIP request message MUST NOT be updated, new responses must not be generated. Post-condition: Control is given back to the SIP Node. Description: - Name: U-ResponseReceived Category: Response Previous: UD-Root Next: U-ResponseBody Purpose: To invoke service applications that are allowed to control the signaling response to the SIP response message. Pre-condition: A response is received. Constraint: Message body content is locked. Post-condition: SIP signaling headers updated and locked (i.e. they can no longer be updated), except possibly: Alert-Info Call-Info Content-Disposition Content-Encoding Content-Language Content-Length Content-Type Require Description: The invoked service applications can in response to the SIP response either proxy the response, or generate new requests. Name: U-ResponseBody Category: Response Previous: U-ResponseReceived Next: U-ResponseBatch Purpose: To invoke service applications that are allowed to control the message body content of the response to the SIP response message. Pre-condition: The SIP signaling headers has been updated and locked (with a few exceptions). Steenfeldt, Smith Expires November 2001 [Page 28] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Constraint: SIP signaling headers is locked, except possibly: Alert-Info Call-Info Content-Disposition Content-Encoding Content-Language Content-Length Content-Type Require Post-condition: SIP message body and related SIP headers updated Description: Possible types of media content that may be processed at this point could be SDP, SOAP, HTML, vXML, SMIL, gif, mpeg7, au, etc. etc.. Name: U-ResponseBatch Category: Response Previous: U-ResponseBody Next: None Purpose: To invoke service applications that are not allowed to control any aspect of the response to the SIP response message. Pre-condition: The responses to the SIP response message has been generated and locked. Constraint: The responses to the SIP response message MUST NOT be updated, new responses must not be generated. Post-condition: Control is given back to the SIP Node. Description: - 6.3. Rule Module: Requirements This section is adapted from [3]. A rule base consists of a collection of rule modules. Each rule module consists of a collection of service execution rules. Each service execution rule consists of a collection of conditions and actions. A condition is an expression that can be evaluated with respect to the message properties in an event context, and either the rules will match or fail to match the properties in the event context. Actions identify the object of invocation. The following requirements are put on the Rule Module: 1) Every rule module MUST have a single owner, with a unique identity (may have multiple id"s, i.e. aliases) and a name. 2) An owner MAY be classified as a given "class" with associated privileges. 3) Every rule module MUST have a single context (otherwise some overlap may provide ambiguous interpretation like both SIP [7] and HTTP [6] have content type header fields). 4) Every rule module MUST have an explicit ordering priority (i.e. the order priority specifies the sequence in which Rule Modules are loaded by the Rule Engine). 5) The format of a rule module SHOULD be specified as an XML DTD. Steenfeldt, Smith Expires November 2001 [Page 29] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 The format of a service execution rule, its constituent conditions and actions MUST be specified. 6) Every Service Execution Rule MUST have assigned a processing point. 7) The syntax of a condition MUST include a way to identify and match properties specified by the event context. 8) The syntax of an action MUST contain a name (or reference) and type of an object to be invoked. 6.4. Conditions: Requirements It MUST be possible to express Conditions in AND, OR, NOT and ALWAYS TRUE relationships. 6.5. Actions: Requirements It MUST be possible to invoke both downloaded and external placed action objects from within a Rule Module. It MUST be possible to directly name Service Application, System Features or Rule Modules. It MUST be possible to directly specify in the Action name a next hop SIP server, outbound SIP Server or Application Server. It MUST be possible to directly name an application using HTTP or SIP URL"s. Other protocol naming conventions MAY be used as well. It MUST be possible to specify that NO actions (except the current one) applies to the event, in which case default SIP behavior can be applied directly. 6.6. Rule Base: Requirements The Rule Base MAY be stored outside the Service Support System in persistent data, or in the cache memory of the Service Support System. 6.7. Privileges and Rights: Requirements The Service Support System offers features to and on behalf of multiple independent authenticated and authorized parties. To use a feature the party must have the privileges to do so. Even if the party has the privileges to use a feature, there MAY be restrictions on how the feature can be used. The party will have certain rights when accessing a feature, as specified by that parties allocated privileges. The service support system MUST enforce protection against unauthorized, unintentional or malicious feature interactions between separately authenticated and authorized parties, i.e. between rule modules and between service applications. This gives rise to the following requirements on the Service Support System: Steenfeldt, Smith Expires November 2001 [Page 30] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 1) Rule Modules and Service Applications MUST be authenticated and validated before they are installed or referenced in the Service Support Environment. 2) Rule Modules and referred Service Applications MUST have explicit specified privileges and rights before Rule Modules are activated in the Service Support Environment. 3) Rule Modules authorized to run on the behalf of one party MUST NOT be triggered to run on behalf of another party. 4) Rule Modules owned by a single authorized party, MAY invoke another Rule Module owned by another single authorized party, if the event context is associated both parties. And both parties has privileges to do so. 5) Rule Modules owned by a single authorized party MUST NOT invoke service applications owned by another single authorized party unless both parties has privileges to do so (invoke, allow invocation respectively). 6) Service Applications running on behalf of an authorized party, invoked by a Rule Module associated that party MUST NOT interfere with (e.g. issue instructions, arm/disarm) any processing Rule Modules associated with another separately authorized party connected to another transaction. 7) Rule Modules and/or Service applications MUST only access features and API"s if they explicitly have privileges and rights to do so. The SERL MUST support Access Control to Rule Modules. These could be enforces by some integrated policy node like depicted in figure 2. This policy could be applied to the entire Rule Module. Policy scripts MAY be embedded within Rule Modules, but they MAY also be associated data elements. Say, the SIP service provider may link a policy script to the Rule Module of a subscriber, specifying the privileges granted by the SIP service provider to the Owner of the Rule Module. These privileges could specify the services or system features the Rule Module is allowed to invoke. 6.8. Ordering And Prioritizing: Requirements In order to construct a Cascaded Chain of services there must be some order in which the applications are to be invoked on a given event. Processing points provide part of this ordering. But there might be more than one action to do at a processing point. Ordering of Rule Modules, Service Execution Rules, Conditions and Actions is given by these requirements on how to process a Rule Module: Rule Base Processing: Steenfeldt, Smith Expires November 2001 [Page 31] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 1) Order priorities for Rule Modules, Service Execution Rules, Conditions and Actions MUST be defined. Order priorities MUST be implicit if not specified otherwise. 2) Each Rule Module MUST have a unique owner. 3) The Rule Module MUST have an explicit allocated ordering priority. 4) Each Service Execution Rule within a Rule Module MUST have an allocated ordering priority. 5) When processing a Rule Module only the Service Execution Rules belonging to the current Processing-Point are executed. The processing of the entire Rule Module will continue as the defined Processing-Points are visited. 6) The Rule Modules MUST be executed in the order given by the order priorities. However, a Rule Module MAY decide to invoke another Rule Module. When execution of this Rule Module has ended, then the ordering based on the order priorities MUST be resumed. 7) When a Rule Module is processed due to an originating subscriber, and the event context changes so it no longer represents the originating subscriber, the processing of that Rule Module is stopped. If this SIP node has a contractual relationship with the new originating user, i.e. the user is an originating subscriber then the Rule Base is searched for Rule modules pertaining to the new subscriber. 8) When a Rule Module is processed due to a terminating subscriber, and the event context changes so it no longer represents the original terminating subscriber, the processing of that Rule Module is stopped. The terminating subscriber becomes a type of originating subscriber, called a forwarded-by subscriber. The Rule Base is subsequently searched for Rule modules pertaining to the forwarded-by subscriber. If this SIP node has a contractual relationship with the new terminating user, i.e. the user is a terminating subscriber then the Rule Base is searched for Rule modules pertaining to the new terminating subscriber. Rule Module Processing: 9) Within a Rule Module the Service Execution Rules MUST be executed in the order specified by the Service Execution Rule ordering priorities. 10) A Service Execution Rule MAY contain zero, one or more top-level Conditions. 11) A top-level Condition MAY embed other Conditions. 12) Within a Service Execution Rule the top-level Conditions MUST be examined in the order specified by the Condition ordering priorities. 13) Embedded Conditions MUST be examined in the order specified by the embedded Condition ordering priorities. 14) Embedded Conditions MUST compose a finite list. 15) The last Condition in a list of embedded Conditions MUST contain at least one Action, and MAY contain a list of Actions. 16) Actions MUST be invoked in the order specified by the Action ordering priorities. Steenfeldt, Smith Expires November 2001 [Page 32] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 17) Actions MAY be specified without an enclosing Condition, in which case the implicit Condition is ALWAYS TRUE. 18) An action invoking a Service Application MUST result in a feature instruction. This instruction MAY be EMPTY (meaning continue processing). When more than one rule module or service application is invoked at a given event, then they will provide a set of feature instructions that will specify how this event is to be processed, for example whether the event should be forwarded or terminated. Clearly such feature instructions MUST NOT be processed simultaneously, and some feature instructions MAY override others. In some cases it might not be important in which order feature instructions are applied or whether they are applied "simultaneously". It MAY be the case that action output gives contradicting feature instructions. Maybe one instruction say "redirect" and an other say "proxy". It MAY also be the case that one instruction says "call barred", in which case it hardly makes sense to invoke other call routing services. Instruction prioritizing of Action Output is given by some additional requirements on how to process a Rule Module: 19) Action output MAY terminate the Rule Module, i.e. the downstream applications is not invoked. 20) Instruction priorities associated with Actions are by default ordered according to the cascading principle. 21) Actions MAY explicitly set privileges on message properties in the Current Event Context, if they have the privileges to do so. 22) By default, handing an event context from one administration domain to another (from one Rule module to another where the Rule Modules have different owners) all the message properties MUST be locked. The handing over from domain MUST explicitly state in the SERL which message properties are available for the handed over to domain to change. 23) By default, handing an event context from one administration domain to another all the message properties MUST be visible. 23) Actions MAY specify "Notify and Continue" mode. By default Actions is in "Interrupt" mode. The order of Rule Modules can be assigned according to one of the Scalable Administration Models. The SIP service provider administrates ordering priorities. Within a Rule module the order of Actions must be assigned by the owner of the Rule Module (the SERL script author). Each Rule Module MUST have an explicit Rule Module Ordering priority. Rule Ordering Priority 1 is defined to be the highest priority. Higher numbers have decreasing priority. This ordering priority will be used to process the Rule Modules invoked on some Event Context, in the right order. Steenfeldt, Smith Expires November 2001 [Page 33] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Rule Modules with ordering priority different from 0 MUST NOT be invoked from another Rule Module, but only by the Rule Engine. Rule Module ordering priority 0 is special though and subject to another rule. Define any positive integer value to have a higher priority than 0. Order priority 0 is the lowest possible order priority by definition. As it is difficult to operate with some MAX positive integer as the lowest possible priority, the value 0 fits our purpose. The reason to introduce this zero priority is because Rule Modules with this priority have special restrictions associated with them. Rule Modules with this ordering priority MUST only be invoked from within another Rule Module with higher priority and explicit privileges to do so. Rule Modules with the same owner MAY have the same ordering priority (different from 0), but in that case they MUST have different event contexts (e.g. SIP, HTTP, à). This means that they MUST NOT be invoked on the same event context. Rule Modules with different owners MAY have the same ordering priority, but in that case they MUST NOT be invoked on the same property in the same event, i.e. they MUST be owned by different SIP service providers (domain owners). In other words Rule Modules that can be invoked on the same message property from a given event context MUST have different priorities, unless it is zero. For each Processing Point there is a set of Rule Modules that might be invoked at that Processing Point. The Rule Modules with non-zero priorities are then grouped into sets of priorities. All priority 1 Rule Modules are grouped in set 1, all priority 2 Rule Modules are grouped in set 2, and so on. However, given some event context then at most one Rule Module will be invoked in each of these sets, due to the rules stated in this paragraph. Each of these invoked Rule Modules may subsequently invoke multiple other Rule Modules, but only if they have ordering priority 0. Notice that a Rule Module from one set cannot by definition invoke a Rule Module in another set. Notice that a Rule Module may be distributed over multiple Processing Points. 6.9. Rule Module Hierarchies: Requirements As stated in previous chapter Rule Modules with ordering priority 0 MUST only be invoked from an Action within another Rule Module with higher priority and the privileges to do so. Rule Modules with ordering priority 0 MAY invoke other Rule Modules with ordering priority 0, if they have the privileges to do so. Steenfeldt, Smith Expires November 2001 [Page 34] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 There MUST always be one Rule Module, which is invoked by the Rule Engine, before Rule Modules with ordering priority 0 can be invoked. This Rule Module is termed the Master Rule Module. When the Master Rule Module invokes priority 0 Rule Modules, they MAY again invoke other priority 0 Rule Modules. These relationships between Rule Modules is termed the Rule Module Hierarchy. Rule Modules of class "Subscriber" SHOULD only have allocated ordering priority 0, due to security reasons. Rule Modules of class "subscriber" MAY invoke Rule Modules of another class, if it has an ordering priority 0. The privileges to do so depend on the contractual relationship between the two owners of the Rule Modules. Rule Modules of class "service provider" SHOULD have allocated ordering priority 0 by default, but MAY get allocated higher ordering priorities. Rule Modules SHOULD NOT be allowed to invoke a Rule Module that already belongs to the Rule Module Hierarchy. When a Rule Module is invoked by another Rule Module it only process the Service Execution Rule Bblonging to the current Processing Point. It MUST be re-invoked explicitly if it has to continue processing in a subsequent Processing-Point. 6.10. Arming of Service Execution Rules: Requirements In order to facilitate that service application can request for event reports by arming service execution rules, then SERL and the Service Support System must support the following list of requirements. The trigger that the application arms MUST be represent-able as a SERL service execution rule. This enables administrators to read the asynchronous armed trigger. The SERL script MUST specify who armed the service execution rule, and when. The trigger MAY be an entire SERL service execution rule or simply an action that should be placed in an existing service execution rule. In any case it MUST be possible to specify exactly where in a selected Rule Module that trigger or action is to be added. If the application does not specify a location then the trigger MUST be inserted as the service execution rule with the highest priority order. It means that rules added last are also the first encountered when an event happens. This is the simplest default behavior. If the Service Execution Rule relates to a specific instance of a running application then a Key MUST be given to identify that instance. It MUST be possible to indicate whether an armed trigger is permanent or should be automatically deleted once the event is reported. Which Steenfeldt, Smith Expires November 2001 [Page 35] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 type of service execution rules an application can add dynamically MAY be linked to the privileges and rights assigned to the application. When an application arms a trigger it MUST be possible for the application to indicate an expiry time for the service execution rule. If no expiry time is given then a default time will be applied to the service execution rule. When this time has expired the service execution rule MUST be deleted. This is necessary to avoid that the server runs out of data storage capacity. It is motivated by the fact that there is no guarantee in SIP that requests pertaining to existing sessions will be sent to any particular server. A Service Support System MAY use three ways to arm a trigger: 1) Re-submit a SERL script 2) Submit a delta to a SERL script 3) Add a service execution rule to a special allocated Rule Module after the "last in first notified" principle. 7. Examples To give a better idea of the management problem we are dealing with, here is a concrete example scenario. It is perhaps a little exaggerated but it should illustrate the point. Let Bob have a SIP subscription with some SIP service provider, say sip.example.com. Bob has a range of services he would like to be placed in the network. Services like terminal independent services or services that becomes tailored to whatever terminal Bob is currently using. It would also be services that provide Bob with security, privacy and reliability. Also, Bob is a busy man, so he does not have time to manage his own services. Bob work at a company, say corp.com. The actions that are invoked to manage an incoming INVITE message to Bob, could look like this: 1) Assume that the domain sip.example.com own and administrate a proxy server. The SIP provider also provides SIP value added services to subscribers, and hosts third party services. The proxy server recognizes that Bob is a valid terminating subscriber (callee) on incoming INVITE at the edge of the Service Network, and hands off the request to an appropriate Application Server. 2) The first application to invoke is a Call Barring application or Accounting function owned by the SIP provider, to check if Bob has paid his latest bill and start charging. If everything is okay this application server may hand off the control of the session to yet another Application Server. 3) The second application to invoke is Bob"s own callee preferences, e.g. a CPL script. This application will monitor for responses for the proxied request, and possibly route the INVITE to multiple destinations based on that. Say the INVITE is to Bob"s current Steenfeldt, Smith Expires November 2001 [Page 36] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 private SIP URL. On "no response" the INVITE is proxied to his wife Alice. In some cases Bob wants all private calls to be diverted to his corporate SIP URL. 4) The third application to invoke is a feature provided by sip.example.com. It simply checks that the Caller"s media codecs can be handled by Bob"s current location/terminal. If not the application will invite a media stream converter into the media stream flow (using third party call control [20]). This conversion is transparent for Bob. This application will monitor for responses from Bob, and update the session descriptions as needed. 5) The fourth application to invoke is also a feature provided by sip.example.com, but brought in from a third party application service provider, say besafe.example.com. This service checks for message body content types and provides virus checking when needed, e.g. if there is an animated vCard included. 6) The fifth application to invoke is a third party ISP service that offers the callee multi media advertising in return of reimbursement of the sip.example.com charging. If the session is established, and it is a video- conference session, then Bob will received a small streaming bar of information in the bottom of the video image. This service is a monitoring application and uses third party call control [20]. The ISP has an account in the sip.example.com domain, and can offer services directly to the subscriber base owned by sip.example.com. Bob has subscribed to this service directly with the ISP, without involving sip.example.com. 7) The sixth application to invoke is a service managed by the company where Bob works. If the call is to Bob"s current corporate SIP URL then the call is routed to Bob, based on data only known within the corp.com"s private LAN network. 8) The last and seventh application to invoke is for administration purposes. The sip.example.com might want to do some logging or statistically functions. The example illustrates that it is likely that multiple service applications may be invoked based on one SIP event, and the diversity of contractual relationships associated that event. The services may be owned by different stakeholders, and implemented using different technologies. To enable such a scenario to be provisioned what is needed is a good Triggering mechanism that can be integrated with Feature Interaction Management. This document argues the case for such a triggering mechanism. The general requirement for triggering in this framework is that it must be possible to specify when and how services should be triggered. To set the scene for expanding this consider a more detailed example of triggering from a Service Support System. Single Rule Module Example: Steenfeldt, Smith Expires November 2001 [Page 37] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 1) A SIP Request is received by a SIP proxy server 2) Some message parser generates a SIP Event Context. This is passed over to the Rule Engine. 3) The relevant Rule Modules will be located in the Rule Base based on the SIP Event and Contractual relationships. Actions will be invoked as the Conditions to reach them are fulfilled. Actions are distributed according to the association with Processing Points. 4) The Rule Engine will load the first filtered Rule Module from the Rule Base and process it. As an example let the Rule Module contain the following pseudo functionality (i.e. a Service Execution Rule specifying Conditions and Actions). Rule Module Begin Owner: id = sip.example.com Context: SIP 2.0 rule 1: processing point = D_RequestReceived Condition 1: Request = INVITE Condition 2: SIP URL in From contains "^sip.example.com"> Action 1: invoke application Y Action 2: invoke application Z Rule Module End 5) A first trigger is reached, and the Service Support System will invoke the specified service application Y. 6) The Service Support System will locate the application Y. 7) The Service Support System will subsequently activate it for execution (locally or remotely). 8) The feature instruction A from application Y is handed back to the Rule Engine. 9) The Rule Engine will re-sume processing the Rule Module, and triggers subsequently another Application Z. The task of invoking the application is given to the Service Support System. 10) The Service Support System will locate the application Z. 11) The Service Support System will subsequently activate it for execution. 12) The feature instruction B from application Z is handed back to the Rule Engine. 13) The Rule Engine will re-sume processing the Rule Module, and find out that the Rule Module has no more Service Execution Rules to execute, and no more Rule Modules to load. Subsequently the Rule Engine will send the final result of the Service to the proxy server. 14) The proxy server will merge the output from the Rule Engine with possible default output and send the resulting SIP message out on the network. 15) The SIP message is e.g. proxied. Multiple Rule Modules Example: This example is an alternative ending compared to the previous example. This examples continues after point 12. Steenfeldt, Smith Expires November 2001 [Page 38] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 13) The Rule Engine will re-sume processing the Rule Module, and find out that the Rule Module has no more Service Execution Rules to execute. The Rule Engine will search for Rule Modules with lower order priority than the previous executed Rule Module. 14) Go to point 3 in previous example. If a Rule Module is found it will be run as in previous example, maybe this time only another application X will be invoked. 8. Related Work This paragraph will shortly discuss other architectural frameworks and methods that the authors are aware of, that may embed, complement or provide an alternative to the mechanism described in this document. 8.1. Intermediary Rule Markup Language (IRML) The mechanism in this document is based on, inspired by, extending and complementing in particular work-in-progress IRML [2,3,4]. It is possible that SERL could be an extension to IRML. 8.2. Call Processing Language (CPL) SERL is in a sense also very similar to work-in-progress CPL [13,14]. SERL, IRML and CPL are all languages describing a mechanism to trigger an action under given conditions. It seems, however, that the CPL is not intended to be a language to support a general triggering mechanism. Currently it is not possible to invoke service applications from within the CPL scripts. It is possible that SERL could an extension to CPL. 8.3. Application Server Component Architecture For SIP The work-in-progress in [16] discusses an architecture for decomposing service applications into logically encapsulated parts. It proposes using SIP to initiate sessions between these parts. It proposes resource-naming schemes based on the Request-URI (see also [17,20]). It does not, however, specify a mechanism for administering the application server to trigger the correct applications on reception of a SIP event. This mechanism could be the concepts and proposals in this draft and the SERL, i.e. the SERL Framework is seen as a complementary mechanism to the "Application Server Component Architecture for SIP". The implication of this reference architecture is that all services should be directly identified by the Request URI. We believe that whilst it is very appropriate for many services to be identified by Request URI, it would be too restrictive to make this a MUST. The reason for this is that many parties may wish to invoke applications at the same host based on the same event. It is important that all of these applications can be developed independently. I.e. each Steenfeldt, Smith Expires November 2001 [Page 39] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 application should not have to decide the next application to be invoked. In the case of a hierarchical decomposition of a service into components it is natural for the controlling applications to explicitly know how to address the sub components. If the applications are implementing different services from different parties then the controller is an entity within the Service Support System of the SIP Server (i.e. the Rule Engine). This entity is addressed by a domain name such as sip.example.com. However the entity cannot always invoke services based on the Request URI. It might need to invoke applications based on other message properties e.g. FROM or SDP properties. It also might need to invoke more than one service before the Request URI is changed. For this reason triggering and feature interaction management in a form such as SERL is needed. Another reason is that if the original Request URI needs to be changed to point to, for example, a third party service then the control of this transaction has been completely handed over to this third party service. This may not be desirable if the third party service is invoked from this host. I.E. the owner of the host (the SIP service provider by our definition) may wish to check the output of the third party service and/or invoke another application before sending the Request out on the network. We conclude that the requirements herein cannot be fulfilled by the "Application Server Component Architecture for SIP", but that they necessitate a triggering and feature interaction language such as SERL to work within the context of that architecture. 8.4. A Model for Service Invocation in SIP using ServiceCodes It has been proposed by work-in-progress [22,23] to use servicecodes in SIP as a mean of identifying which services to invoke on INVITE events, and to compose chains of features that span multiple administrative domains. These servicecodes are proposed to be part of the URI in the Request-URI. It is also proposed to use TRIP to propagate the servicecodes between administration domains [23,24]. This model is an alternative mechanism as the one proposed in this document, although more restrictive in its functionality, and it does not specify how policies of a Server is resolved. However, the mechanisms are by no means mutual exclusive. The proposed servicecodes could be part of the conditions on which services are invoked in Rule Modules. In this sense the servicecodes are a standardized naming convention of (standardized) services. 8.5. SIP Servlet API Extensions The work-in-progress about the SIP Servlet API [25] also specifies a mechanism for invoking services, although the mechanism is Java technology dependent. The mechanism makes considerations about Steenfeldt, Smith Expires November 2001 [Page 40] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 interoperability of services that are coupled, i.e. they know some information about each other (e.g. symbolic names). This can to a certain degree be seen as a mechanism for decomposing one service into multiple Servlets. There is some overlap between the mechanism in this document and the SIP Servlet API mechanism. But the mechanism described in this document requires no coupling between services, which is one of the reasons that make it scalable. Our mechanism is also technology (e.g. programming language) independent. However, the mechanisms are by no means mutual exclusive. The Service Dispatcher [25] finds the right services given an event based on some rules. These rules are not specified. These rules could be specified in Rule Modules and the Service Dispatcher could be the Rule Engine. 8.6. 3GPP IMS Concerning concepts and architectures in 3GPP-IMS [8] there is an agreement on the following (comments about SERL and the Service Support Server exclusive): An Application Server (AS) will offer value added IM services, it resides either in the user"s home network or in a third party location, where the third party could be a network or simply a stand- alone AS. The interface between S-CSCF and the AS is used to provide services residing in the AS, which is either an AS in the home network or in an external network like Third Party or visiting network. Besides the Cx interface (between HSS and S-CSCF) the S-CSCF supports only one standardized protocol for service control. This protocol is called SIP+. The protocol will convey the SIP content required and service control between the S-CSCF and AS. The SIP+ protocol is not defined, but one candidate is to embed the SIP content in HTTP. The Application can reside on both a SIP Application Server and an OSA Service Capability Server and shall exhibit the same interface behavior. The SIP Application Server may host and execute services by influencing and impacting the SIP session on behalf of the services. The S-CSCF will decide if a SIP session request is subject to inform a service based on the information received from the HSS or other sources like AS. This information is called filtering, which can be compared to the information specified in SERL scripts (as described in this draft). This information is stored and conveyed on a per application Server basis for each subscriber. The name(s) and address(es) information of the AS are received from the HSS and the S-CSCF shall contact the AS in the order supplied by the HSS. The response from the first AS shall be used as input to the second AS. It is decided that the AS can contain SCIM (Service Capability interaction manager) functionality and other application servers, but the S-CSCF shall not handle Service Interaction Issues. A SCIM may or Steenfeldt, Smith Expires November 2001 [Page 41] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 may not be comparable with the Service Support System (as described in this draft). The interface Sh between AS (SIP Application Server and OSA-SCS) and HSS is an intra-operator interface which shall transport transparent service and user related information. This information may or may not be compared with SERL scripts (as described in this draft). 9. Security Considerations Security issues concerning execution of SERL is described in the previous chapters. Security issues concerning uploading SERL scripts, and managing privileges and rights is not within the scope of this document. 10. Future Work There are many issues still to be investigated in future work: 1) consider relations with a service description language, in order to manage feature interactions within a feature group. 2) mature the definition of processing points and consider how to link the processing of subordinate protocols in SIP to the processing of the SIP event context. 3) elaborate on feature interaction management between inter administration domains, but also between service network domains. I.e. consider if more complex categories of feature interactions like SUMC, MUSC, MUMC and CUSY [28] should be handled by SERL to some extent. 4) this document makes considerations about a simple default rule for resolution of run-time feature interactions based on priorities of feature instructions. Maybe in future work there might be a need for a more advanced feature interaction detection algoritm for SIP. This may be outside the scope of SERL. 5) currently requirements has been put on SERL to manage arming of Service Execution Rules by applications. Maybe applications should also be able to arm for other application, or add Service Execution Rules that invoke other applications at specified Processing Points. 6) it is envisaged that SERL scripts (or a delta) could be uploaded to the Service Support System through different methods like SIP (similar approach like [15]) and HTTP. 7) it is envisaged that SERL scripts could be used to configure remotely end-user terminals. This approach could be part of the solution for a multi-vendor configuration standard as specified in work-in-progress [26]. Steenfeldt, Smith Expires November 2001 [Page 42] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 8) consider similarities with other specification languages like the Policy Core Information Model [12], remote method invocation protocols like SOAP [21] or other XML based service control languages. 11. Acknowledgments This work has been inspired by and is originally based upon IRML [2,3]. Valuable comments have been presented from Steen Thranow, Emil Nannestad, J°rgen Dyst, and Goran Todorovic. Special thanks is given to Steen Thranow for contributing with an update of 3GPP û IMS development. 12. Intellectual Property Rights Considerations Ericsson has filed patent applications that might possibly have technical relations to this contribution. See further: http://www.ietf.org/ietf/IPR/ERICSSON-General 13. Author"s Addresses Rico W. Steenfeldt Ericsson Copenhagen, Denmark EMail: Rico.W.Steenfeldt@ericsson.dk Henry Smith Ericsson Copenhagen, Denmark EMail: Henry.Smith@ericsson.dk 14. References [1] Bradner, S., "The Internet Standards Process û Revision 3",BCP 9, RFC 2026, October 1996 [2] A.Beck/M.Hofmann, "IRML: A Rule Specification Language for Intermediary Services" draft-beck-opes-irml-00.txt, February 2001. Work in progress. [3] Tomlinson, G., et al., "Extensible Proxy Services Framework", Work in progress. [4] Hofmann, M., Beck, A., "Example Services for Network Edge Proxies", draft-beck-opes-esfnep-01.txt, November 2000. Work in progress. [5] Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second Steenfeldt, Smith Expires November 2001 [Page 43] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Edition), http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. [6] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", Request for Comments 2616, June 1999. Work in progress. [7] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; March 1999. [8] 3G TS 23.228 IMS stage 2. ftp://ftp.3gpp.org/ [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments 2119, Harvard University, March 1997 [10] R.W. Steenfeldt/H.Smith, "Service Execution Rule Language (SERL)". Work in progress. [11] R.W. Steenfeldt/H.Smith, "Example Uses of SERL in SIP Enabled Nodes", Work in progress. [12] B. Moore, E. Ellesson, J. Strassner, A. Westerinen, "Policy Core Information Model û Version 1 Specification", RFC 3060, February 2001. [13] J. Lennox/H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, IETF; May 2000. [14] J. Lennox/H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", draft-ietf-iptel-cpl-04.txt, November 2000 Work in progress. [15] J. Lennox/H. Schulzrinne, "Transporting User Control Information in SIP REGISTER Payloads ", draft-sip-reg-payload-01.txt, October 2000 Work in progress. [16] Rosenberg/Mataga/Schulzrinne, "An Application Server Component Architecture for SIP", draft-rosenberg-sip-app-components- 00.txt, November 2000 Work in progress. [17] B. Campbell/R. Sparks, "Control of Service Context using SIP Request-URI", draft-campbell-services-control-00.txt, January 2000 Work in progress. [18] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee Capabilities", draft-ietf-sip-callerprefs-03.txt, November 2000 Steenfeldt, Smith Expires November 2001 [Page 44] INTERNET-DRAFT SIP SERL Framework and Requirements May 7, 2001 Work in progress. [19] J. Lennox/J. Rosenberg/H. Schulzrinne, "Common Gateway Interface for SIP", RFC 3050, IETF; January 2001. [20] Rosenberg/Peterson/Schulzrinne/Camarillo, "Third Party Call Control in SIP", draft-rosenberg-sip-3pcc-01.txt, November 2000 Work in progress. [21] N. Deason, "SIP and SOAP", draft-deason-sip-soap-00.txt, June 2000 Work in progress. [22] J. Peterson, "A Model for Service Invocation in SIP using ServiceCodes", draft-jfp-sip-servicecodes-00.txt, February 2001 Work in progress. [23] J. Peterson, "The ServiceCode Attribute for Trip", draft-jfp- sip-servicecodes-00.txt, February 2001 Work in progress. [24] J. Rosenber, H. Salama, M. Squire, "Telephony Routing over IP (TRIP)", draft-ietf-iptel-trip-03.txt, July 2000 Work in progress. [25] K. Pterbauer, J. Stadler, I. Miladinovic, T. Pudil, "SIP Servlet API Extensions", draft-peterbauer-sip-servlet-ext-00.txt, February 2001 Work in progress. [26] D. Petrie, "Requirements for a SIP USer Agent Configuration framework", draft-petrie-sip-config-framewk-reqs-00.txt, February 2001, Work in progress. [27] J. Lennox, H. Schulzrinne, "Feature Interaction in Internet Telephony". Feature Interactions in Telecommunications and Software Systems VI, IOS Press, pp. 38-50, 2000. [28] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. Schnure, "A Feature Interaction Bechmark for IN and Beyond", Feature Interactions in Telecommunications Systems, IOS Press, pp. 1-23, 1994. [29] S. Tsang, E. H. Magill, B. Kelly, "An Investigation of the Feature Interaction Problem in Networked Multimeda Services", BT Technol J Vol 15 No 1 January 1997. Steenfeldt, Smith Expires November 2001 [Page 45]