ur. However, this is not a scalable approach as the graphs or state tables grow larger and more complex as additional services are developed. In addition to this, any time a service is changed or added, these flows need to be updated which Service Delivery Platforms increases the administrative overhead of the system. Resolving all these potential conflicts offline or ahead of run-time implies that the time to detect conflicts is greatly reduced during run-time. A drawback to offline conflict detection resolu- tion is that there might be unpredictable behavior from a service which had not been covered by the offline detection resolution. This could lead to a nondetermin- istic operation of the system resulting in conflicts. While both online and offline conflict detection systems require information about each particular service, online systems do not need to keep a record of all the possible interactions between the different services. Online systems should be able to detect a potential conflict as the session is established, and trigger the necessary recovery mechanisms in real time. This means that there is less maintenance required whenever a new service is added. Another benefit is that the real-time analysis should be able to handle any unexpected interaction as it happens. This real time analysis does increase the time to establish sessions as more processing time is needed to evaluate the required services. Both online and offline systems have their advantages, and are not mutually exclusive. Both approaches should be considered in the design of a service conflict detection and resolution system, and examples of each of these systems will be dis- cussed further on. Regardless of whether offline or online conflict detection is used, some mecha- nism to resolve conflicts needs to exist. This mechanism can either disable the ser- vice with the lowest priority, or manipulate the session SO that the conflict does not occur. This manipulation can take the form of modifying the SIP request to fall within accepta