3GPP defines the SCC-AS as the first TAS invoked in the originating iFC treatment, and the last in the terminating iFC treatment. The following diagram illustrates having just the SCC-AS and the MMTEL-AS as the only two TAS invoked for a session, and using MMTEL for both originating and terminating treatment:
|For simplicity, both the originating and terminating served-users are in the same network, and happen to be assigned to the same serving CSCF.
Rhino Sentinel VoLTE implements both the SCC-AS and the MMTEL-AS. The session includes four “back-to-back user agent” instances:
mobile originating SCC
mobile originating MMTEL
mobile terminating MMTEL
mobile terminating SCC.
|The phrase “back-to-back user agent” or B2BUA is used to describe each SIP Sentinel instance. This is often the case, as many SCC and MMTEL capabilities are able to be realised based on a routing back-to-back user agent. However it is not entirely accurate, as various capabilities, such as Access Transfer and MMTEL conferencing, require a much more sophisticated structure than a “Routing B2BUA”.
OpenCloud supports co-location of the Sentinel instances in the same cluster, and even Unix process/JVM instance. This means the S-CSCF does not need to be configured for iFC trigger chaining (as shown above). This is an optional configuration: