Telecommunication Systems 24:2–4, 251–274, 2003  2003 Kluwer Academic Publishers. Manufactured in The Netherlands. Experimenting with Feature Interaction Management in SIP Environment Z. CHENTOUF, S. CHERKAOUI and A. KHOUMSI zohair.chentouf@hermes.usherb.ca, {soumaya.cherkaoui;ahmed.khoumsi}@usherbrooke.ca Department of Electrical and Computer Engineering, Université de Sherbrooke, Sherbrooke, PQ, J1K 2R1 Canada Abstract. This article reports architectural aspects of a solution for detecting and resolving feature inter- actions (FI) in SIP-based IP telephony architectures. The solution takes into account the special context of SIP that permits end user programmability, which means the possibility for end users to design their own tailored services and personalize them as much as they like. Programmability renders more frequent the so called multi-component FI situations, where the conflicting services reside in different network compo- nents. This type of FI is the more complicated one. The authors describe how the different components of the presented SIP architecture operate together in order to run services and avoid this type of interactions. A prototype of the solution has been developed. Keywords: feature interaction detection and resolution, service and preference modeling, SIP, IP telephony, end user programmability 1. Introduction The Feature Interactions (FI) problem may be briefly defined as the undesirable situation that arises when two features or more, running together, interact in such a way that one at least displays an unexpected behavior. The literature does not distinguish between features and services when talking about FI, because services are sets of features. In the following, we mean by FI, any problem of interaction that involves features and/or services. Take, for example, the interaction between the Call Waiting service (CW) and the Automatic Call Back service (ACB). When a user that has CW receives a call while busy, CW automatically sends a special tone to the caller to inform him that he is put on hold. If the caller has ACB, the latter is triggered when the callee is busy in order to initiate call attempts, at a fixed time intervals, until the callee answers the call. The event that triggers ACB is the busy tone. But since CW replaces the busy tone by its own indication signal, ACB will not be triggered. This unexpected behavior violates the caller intention (to trigger ACB if the callee is busy). In order to manage the FI problem, interactions have to be detected and then a solution has to be found. If the FI detection is executed before the services are run in the network, it is called an off-line detection. If it is run, after the services have been deployed in the network, it is called an online detection. Under the same conditions, the resolution is also called off-line and online, respectively. The term FI management is