s, every time a new service is configured or added, each service needs to be updated with the new list of priorities. While the work done by Kolberg et al. [16] uses the SIP signaling protocol, it is not specific to the IMS architecture. Chiang et al. [17] extend this solution to the IMS platform by placing the cocoon functionality inside the SCIM. The SCIM caches the original SIP request SO that it can act on the end user's behalf in reestab- lishing the session when service conflicts are detected. The functionality of the ConType header is largely replicated, although it is given a new name in the Service- Indication header. This means that the redundant signaling does not have to travel over the access network, which will reduce the session setup time considerably as well as reducing the bandwidth used. However, it does not eliminate this overhead entirely as it still takes place over the internal core IMS network. Services that will play no part in the final session are still included in the initial session setup, and the session setup is repeated for every combination of services that result in conflicts. 8.3.5 Open Research Areas While progress has been made on the offline mechanisms for detecting service conflicts, an efficient real-time online resolution mechanism that does not incur Service Orchestration in the IP Multimedia Subsystem penalties due to redundant signaling is still required. In both online and offline detection systems, information about the services and their interactions are needed. It is proposed that there should be a mechanism allowing the automatic exchange of this information whenever a new service comes online. This would require a standardized way of capturing all the succinct details of a service in a manner that is compatible with third party developers. Third-party developers could build this into their new services, such that their own service would communicate its needs and requirements to the SCIM. This information could include the details of what SIP headers the service re