is Service Delivery Platforms cocoon, which saves a copy of the message. It sends the message to the service pro- cessing logic unchanged. When the service has finished executing, it may have made some changes to the SIP message. The original message is compared against the message returned by the service, and a header is injected into the SIP message. This header is called the "ConType" header, and contains information about which service was activated, and any changes that were made to the SIP message. This allows it to detect any conflicts on subsequent service interactions, as each cocoon knows what parameters it requires or modifies. If a cocoon receives a message with a preexisting ConType header, it examines it to detect any conflicts before passing the message on to the service. If a conflict is detected one of the services needs to be disabled. This leads to a problem with this approach, as the lower-priority service (i.e., the service that should be disabled in case of conflicts) could have been the first service to activate, and has hence already spent time processing the message and executing the service logic. This results in the service being terminated, and a SIP 380 Alternative Service message is returned to the originating user. In this message the ConType header is returned, indicating which service needs to be disabled. The original signaling flow for the session set up would then be repeated with this ConType header injected into the original request. When the SIP request reaches the cocoon of the disabled service, the cocoon would detect that it should be dis- abled, and would pass the message on to the next service without triggering its own service. This leads to many redundant signaling messages, as the entire session setup procedure would have to be repeated for every conflict detected. Another drawback to this approach is that every service needs to know the priority of every other ser- vice, SO that each cocoon can know when to disable its service and allow another one to take over. Thu