nded destina- tion (whether that is the SCIM or another user). Therefore, it is better to separate these functions when one considers the potential impact that a component failure will have on the network. Another consideration discussed is that the AS can be provided by third parties, and therefore, should not be trusted implicitly [13]. As they will be talking to the SCIM or SCSCF, the exposure of the network to these third-party service providers should be limited. If they manage to overload their point of contact with the network (i.e., the SCIM or SCSCF/SCIM), any damage dealt to the network's operational ability must be limited. Thus, from a threat man- agement point of view, it makes sense to separate the SCSCF/SCIM functionality. By defining the SCIM as a separate functional entity to the SCSCF, it no longer has to operate as a SIP Proxy (the SCSCF is standardized as a SIP Proxy). Thus, the SCIM can operate in another mode, such as a B2BUA. B2BUAs are allowed to cre- ate and terminate SIP dialogues, implying that they are no longer restricted to operating within the SIP boundaries of a proxy. They can use their own timers to control when to terminate or establish sessions, and do not have to rely on the time- out mechanisms built into SIP. Qi et al. [14] follow a more analytical approach to defining their architecture. They investigate the performance implications of having a centralized architecture, and suggest splitting some of the functionality into two separate entities. They Service Delivery Platforms suggest having a module that is integrated with each AS, as well as a central node that informs this module of the next destination for service requests. The core idea they propose is to allow the AS to pass messages between each other without having to send the message back to the SCIM/SCSCF. By bypassing the SCIM and SCSCF their simulations show a large reduction in the load on the SCSCF, as well as decreasing the session setup delay. The benefits of this model are related to how long it takes each s