Handling feature interactions in the language for end system services

Abstract

One big difference between Internet telephony and the Public Switched Telephony Network (PSTN) is that the PSTN usually assumes dumb endpoints, while Internet telephony has intelligent endpoints that can perform services. Performing services on endpoints may introduce many new communication services, make telecommunication services more distributed, and make the entire telecommunication network more robust and efficient. At the same time, it may also make telecommunication services more difficult to manage and require new techniques to create and compose services. In this paper, we first introduce a new scripting language, called the Language for End System Services (LESS), which we define specifically for end system service creation. LESS is extended from the Call Processing Language (CPL) and uses a tree-like structure to represent telecommunication services. Based on this tree structure, we propose a method based on LESS action conflict tables and a tree merging algorithm to detect potential feature interactions and help to resolve any conflicts detected. We integrated the method for handling feature interactions into our LESS-based end system service creation environment, which is part of our Session Initiation Protocol-(SIP) based user agent, SIPc. SIPc can execute LESS scripts for end system services and contains a service manager that can handle feature interactions.

Introduction

Telecommunication networks are moving from the circuit-switched public switched telephone network (PSTN) to packet-switched Internet telephony. A major difference between Internet telephony and the PSTN is that the PSTN usually assumes dumb endpoints while Internet telephony incorporates intelligent endpoints. In Internet telephony, endpoints usually have CPU and memory, so they are programmable and can perform services such as call forwarding, transfer, and call screening.

Performing services on end systems may introduce many new communication services, make telecommunication services more distributed, and make telecommunication networks more robust and efficient overall. At the same time, it may also make telecommunication services more difficult to manage, thus require new techniques for creating and composing services.

In this paper, we first introduce a new scripting language we defined for end system service creation, the Language for End System Services [1], [2], or LESS. As an extension of the Call Processing Language (CPL) [3], LESS enables comparatively inexperienced end users to create services that run on Internet telephony endpoints. This language is designed to make it impossible for users to do anything more complex (or dangerous) than describe Internet telephony services, but powerful enough to handle many commonly used services. In our technical report on end system service examples [4], we show that LESS can handle a big part of the services defined in AT&T 5ESS switches [5], ITU-T recommendation Q.1211 [6], and CSTA Phase III [7]. We also discuss how to use LESS to describe services involving other Internet applications such as email, web, presence notification, instant messaging, and networked appliance control.

Like PSTN services, Internet telephony end system services also have problems with feature interaction. “Feature interaction is an inevitable by-product of feature modularity” [8]. While modularity enables efficient service creation, it may also cause feature interactions among multiple service scripts running on one or more devices. When users create new services, they often focus on their immediate needs without checking existing services, so feature interactions are likely to arise between newly created scripts and the old ones. One design goal of LESS is to facilitate the easy detection and resolution of feature interactions among LESS scripts.

LESS inherits CPL’s tree-like structure to represent communication services. This structure enables the back-and-forth translation between graphical and textual representations of LESS scripts and makes it easy to handle feature interactions among LESS scripts. In this paper, we introduce a tree-merging algorithm to detect interactions among LESS scripts. The algorithm is based on the LESS action conflict tables, which we carefully define for analyzing LESS-based feature interactions. Once a feature interaction is detected, our algorithm can clearly identify the conditions that may cause the interaction, and our service management system can then guide users in resolving any feature conflicts detected.

Several methods already exists to handle feature interactions in CPL, but because feature interactions in LESS are very different from those in CPL, those methods cannot fully handle the feature interactions in LESS. In Section 1.1, we detail the differences between LESS and CPL in handling feature interactions and discuss the existing methods. We then briefly introduce LESS in Section 2. Section 3 shows the LESS action conflict tables. Section 4 discusses our tree-merging algorithm based on those action conflict tables. In Section 5, we present the implementation of our LESS-based service creation and execution environment for handling feature interactions. Section 6 concludes the paper and discusses our future work.

Most of the work discussed in this paper is based on the Session Initiation Protocol (SIP) [9]. SIP is an IETF standard used to setup Internet telephony call sessions. With extensions, such as those for presence [10] and for instant messaging [11], SIP can also handle functions beyond multimedia session setup. The definition of LESS is based on SIP.

LESS extends CPL and inherits many CPL characteristics, such as the tree-like structure, that avoids user-defined variables and loops, and the inability to run external programs. However, there are many differences between LESS and CPL. CPL was designed to run on network servers such as SIP proxy servers; therefore, CPL focuses on call signaling routing. On the other hand, LESS is designed for endpoints, which are usually at the end of call signal routing paths. Therefore, LESS focuses on initiating, or terminating call sessions and controlling endpoints. Some CPL-defined signaling actions, such as proxy, cannot be used on endpoints, while LESS incorporates many new actions that are not in CPL but are required by endpoints such as call, accept, transfer and user interaction actions. LESS also defines new triggers for user interactions and timer event handling. Furthermore, LESS can handle presence information, instant messaging, and other Internet applications such as networked appliance control. In addition, because LESS runs on endpoints, it can acquire the context information that is only available to endpoints for service handling such as the availability of audio devices. For these reasons, feature interaction handling in LESS is very different from that in CPL.

Several methods exist for handling feature interactions in CPL. Xu et al. [12] proposed to translate CPL into a formal language to check feature interactions. Amyot et al. [13] developed a tool called FIAT for filtering inconsistencies among features, then implemented a translator to convert CPL to the FIAT input language. FIAT has a user-friendly web-based user interface for handling conflicts detected among CPL scripts. Nakamura et al. [14] analyzed possible semantic warnings in an individual CPL script, then extended the analysis to multiple scripts by defining an operator to combine multiple scripts into one. Because LESS is extended from CPL, we can use these approaches to detect and resolve feature interactions. However, because of the many differences between LESS and CPL, the existing work cannot fully handle feature interactions in LESS.

All the existing work focuses on call routing services because they are CPL-based. Thus, they do not handle signaling actions for endpoints such as accept, terminate, and call. These new signaling actions in LESS can introduce many interesting feature interactions that could not occur among CPL scripts. Though the existing work may be extended to handle feature interactions in LESS, the work in this paper, especially the action conflict tables, can be of great help for extending the existing work.

We also noticed that both Nakamura and Xu’s work handle feature interactions among multiple users’ scripts because CPL scripts run on proxy servers that are usually owned by ISPs. ISPs may have the right to access multiple users’ service scripts. However, LESS scripts usually run on endpoints that cannot access other users’ scripts. Thus, in general, we do not expect to handle feature interactions among multiple users’ LESS scripts.

In fact, even if there were a centralized server that could access all the LESS scripts of multiple users, privacy concerns would make it difficult to resolve the detected interactions. For example, user Bob has a script that keeps calling Alice every 10 min, but Alice has a script that rejects all calls from Bob. According to Nakamura’s work, the combined script causes a CRAE (call rejection in all execution paths) semantic warning. But can we inform Bob that his calls to Alice will always be rejected? The answer depends heavily on the social context surrounding Bob and Alice. For example, in an enterprise environment that requires employees to share service information, Bob may be informed about the conflict. In this case, multi-user feature interaction handling is possible and very useful. But in a residential environment, to protect Alice’s privacy, Bob should not be informed. In the latter case, the conflict cannot be resolved.

Neither Nakamura nor Xu addressed how to resolve feature interactions. The FIAT system of Amyot et al provides a viable way to resolve feature interactions. FIAT has a web interface and involves end users in resolving feature interactions. It provides suggestions like Add EXCEPTION, DISABLE, SET PRIORITY, and TOLERATE, as well as human-understandable explanations to guide users in resolving the detected feature interactions. We consider it one practical way to involve end users in resolving feature conflicts. Our implementation also uses a popup dialog that shows users the detected feature conflicts and asks users to make a choice. Our feature interaction detection algorithm can clearly identify the conditions that may cause the detected interactions. We can then present the conditions to users in a human-readable way and ask users to make decisions. The users’ decisions can be saved in our service management system. However, our user interface for resolving feature interactions is different from the FIAT system in that we do not define different suggestions for users, but instead ask users to make a choice among the actions they originally defined in their own services. We then automatically prioritize, disable, or merge services, or tolerate the conflicts based on users’ choices. In addition, we integrated our service learning and service risk management work into our feature interaction handling implementation. Users can receive suggestions that have been inducted from their call histories and have more options for reduced-risk call handling actions. We detail our implementation in Section 5.

There is also some existing work on feature interaction in policies [15], and on using logic programming [16], [17] to detect feature interactions. These efforts can handle event-based call processing, which is also the call processing model for LESS and CPL. But they do not address the feature interactions in endpoints among end user created services, which is the focus of this paper.

Some researchers have proposed using architectural approaches to deal with feature interactions in general. Architectural approaches attempt to clearly define the relationships among features to make feature composition possible. One simple architectural approach statically defines the precedence of all the features, then executes features in order. This approach is insufficient to deal with complex communication services because in many cases, the precedence of features is dynamic when performing communication services.

Other more sophisticated architectural approaches are available to handle interactions among well-modularized features, such as the pipe-and-filter architecture [18], the Distributed Feature Composition (DFC) [19], and the agent-based architecture [20]. We will not describe these architectural approaches in detail but note one fact that makes them unsuitable for end-user-created LESS scripts. All these approaches assume that features are carefully designed and modularized, and thus handle feature interactions based on this assumption. They assume features following the pipe-and-filter architectural style: “Feature components are independent, they do not share state, they do not know or depend on which other feature components are at the other ends of their calls (pipes), they behave compositionally, and the set of them is easily enhanced” [18], [19]. This assumption can be held for many existing PSTN services, which are designed by professional service designers, and are carefully checked to make them compositional.

However, for services created by inexperienced service creators, such as CPL or LESS scripts, this assumption is unlikely to hold. Users may create an ill-formed feature that overlaps with existing features or a monolithic script that should be divided into multiple modules. It is difficult to use architectural approaches to handle these ill-formed features in end systems. Sometimes, architectural approaches may be required to reconstruct the ill-formed features, and compose the reconstructed features to achieve the expected results. The reconstruction certainly gives the features a better format, but it is not the original format the users are familiar with. For example, in Fig. 1, feature1 and feature2 conflict when the time is between 2:00PM and 3:00PM on December 25, 2004. The preferable service shown in the figure takes feature1’s decision if the caller is sip:[email protected], but takes feature2’s decision if not. Defining the precedence between the two services cannot resolve the conflicts. However, merging two trees into one, as the figure shows, can easily resolve the conflicts.

Part of the work in this paper was published in our paper [21] in International Conference on Feature Interactions in Telecommunications and Software Systems (ICFI’05). This paper corrects many errors in the action conflict tables in the ICFI paper. It also illustrates in great detail the relationship between action conflicts and end system capabilities and introduces the concept of using service risk management and service learning to handle feature interactions. In addition, this paper introduces LESS and presents our implementations in much more detail.