 a link on a page, and would interact with an AS that would connect him to the called party. Another call control service is Third Party Call Control (3PCC), where the actual call is controlled by a third party that is not necessarily included in the call. If there is not a large degree of call control exhibited by the service, it is classed as a "Coordination Application." Examples of these services include services such as call redirection, call blocking, and SO on. By making this distinction, Nakajima et al. [13] can detect conflicts as only one service from the first group is allowed per ses- sion. Multiple service interactions from the second group are allowed, as they enrich the service and do not terminate the call or session. Qi et al. [14] store information about the possible service interactions and the details of the AS in XML documents. They also store policies which allow the net- work operator to control these interactions. Another offline conflict detection and resolution mechanism has been proposed by Goveas et al. [11]. Here each combined service is stored as an acyclic graph. Each service capability is represented by a node, and different routes through the graph indicate different combined services. They define rules which identify, along which edge the overall service flows (i.e., determining the next service capability to trigger from the current one). These rules take advantage of context-specific data as well as the known information about each service. These routes or service flows are defined statically by the developer of the service before the service provisioning actually takes place, and thus, limits the flexibility of the service. This approach leads to difficulties when trying to integrate services offered by multiple different third parties. An interesting online conflict detection and resolution system is proposed by Kolberg et al. [16]. Here each service is wrapped in a "cocoon," which sits in front of the AS. Each SIP message that is destined for the AS is instead received by th