This Annex is intended to guide the reader in deployment and real life issues. This specification has provided a set of tools for the application developer and the application integrator to utilize in order to develop and deploy applications and provide services for the IP multimedia core network subsystem. However, practical deployments will need to consider certain scalability issues with the use or misuse of some of the tools specified in this specification. The architecture allows for any number of Application Servers to be connected to any number of S-CSCFs and Transit Functions, and any number of Application Servers to be involved in the initiation of a multimedia session. A scalability issue may arise if there are a large number of S-CSCF, Transit Functions and AS in a network. Consideration should be given to the signalling propagation delays introduced when many Application Servers add themselves to the route to provide originating and terminating services for the calling and called parties. A SIP Application Server may act as gateway function by forwarding an incoming request to external ASs beyond the IM CN subsytem. An external ASs will also send responses to IM CN subsytem via a SIP AS gateway. These other Application Servers can be located externally to the home network, and use the SIP Application Server as a gateway to the ISC interface. The interface between the SIP Application Server acting as a gateway, and other Application Servers is outside the scope of the present document. There is another case where the external AS is connected with S-CSCF (or I-CSCF) via public ISP networks depending on the operators desire for network configuration hiding. S-CSCF or entities outside the S-CSCF may perform the interworking function. Care must also be taken to the priority and order of contact of multiple Application Servers during a session in order to account for feature interaction issues.

Figure A.1 depicts a possible solution that shows how a S-CSCF (S-CSCF1 S-CSCF3) could be connected to a single AS (SIP AS1), while another (S-CSCF2) could be connected to more than one, in this case it is two (SIP AS1, SIP AS2). All S-CSCF will be connected to the HSS via Cx. A SIP AS may be connected to the HSS via Sh. SIP ASs may be connected to the IP network, which could allow them to contact Application Servers (e.g., either SIP ASs, or Other ASs). Care should be taken to the transaction delays resulting of a high number of S-CSCF, Transit Functions and ASs on the session signalling path. A possible application of this architecture is described below (see Figure A.2). While some applications need to discover the registration of a user on an event driven basis, many applications do not. For many applications an access to the HSS or other database to obtain the address of the S-CSCF that serves a user is sufficient to contact and initiate a session to that user, and others (such as basic call feature servers) do not require to be informed of the registration state or necessarily even need to know the identity of the user. It is therefore possible that the filter criteria are set in such a way that S-CSCF3 does not forward or notify SIP AS 3 of REGISTER requests. SIP AS3 would then need to determine registration status via other means (i.e. via IP network) not specified. The number of Application Servers receiving REGISTER requests (i.e., SIP AS3) from an individual S-CSCF should be minimized.