r service invocation in the IMS have a number of limita- tions. First, there is no external information used when determining which service to invoke. Only information contained in the original SIP message is used. External information such as the status of the end user, the time of day, or the outcome of Service Orchestration in the IP Multimedia Subsystem SIP AS 2 SIP AS 1 SCSCP SIP AS 3 User agent PCSCF Figure 8.2 Example of chaining services in the IMS. previous decisions cannot be included in this process. Second, handling multiple user interactions is not trivial, as each user has their own profile with an individual set of iFC, which can result in a different chain of services being triggered. This creates a problem when multiple users wish to utilize a service together. As each user's service chain and thus signaling paths are different, their messages will not be routed in the same fashion. This introduces a variable delay in the establishment of a session, as well as potentially losing some control signaling as the different services pass or modify the signaling that flows through them. Currently, the iFCs are only evaluated for initial SIP requests. This needs to be expanded to allow services to be triggered on certain responses as well [8]. There is a feature called "record-routing" which allows an AS to become part of the signal- ing path SO that it can inspect the message flow for a particular response. However, this is not ideal when multiple AS is involved, as the signaling path and hence, the overall delay would increase. Not allowing services to be triggered on responses such as a SIP REINVITE message inside an existing SIP dialogue limits the flexi- bility and type of services that can be offered. For example, the service orchestra- tion system should allow a service to be triggered when the end user receives a notification from a present AS about a change in some monitored state, or it should be possible to trigger another service when the current service ends (i.e., the SCSCF receives a BYE r