ssing the responses received back from the operation. 1.3.2.2 How Does It Work? SIP protocol messages are routed to the SCL as they traverse the IMS control plane from the source (e.g., a user's mobile device) to the intended destination (e.g., another user or an application). On receipt of any message, SCL first determines whether a message belongs to an already active service session, or signifies the start of a new session. When a new service session is established (e.g., SCL receives an SIP initial Request message such as INVITE), SCL identifies the type of service by applying preconfigured service identification rules to the message received. Based on this information, SCL creates Service Delivery Platforms an active instance of a preconfigured state machine to direct subsequent SCL processing activity throughout the life cycle of the service session.* After service and party identification, or on receipt of a subsequent message belonging to an already active service session (e.g., a SIP ACK that acknowledges a session establishment), SCL forwards the message to the appropriate state machine. This leads to a state transition in the active state machine. Preconfigured business rules may be executed during this transition to determine the service control required at this point in the service. Business rules are typically evaluated against data contained within the protocol message-for example, examination of SIP Request Uniform Resource Identifier (URI)-but may also utilize information from external data stores-for example, service and/or user profile information. Service control or enhancement at this stage can be achieved by 1. The Rules Engine instructing an orchestration mechanism to call external business services; and/or 2. The Rules Engine instructing the SIP protocol adaptation module to change the service session from Proxy mode (default) [6] to either B2BUA [6] or TUA mode [6]. In scenario (1), the orchestration mechanism may call one or more external business services based on a "to do" list receive