Features of the instance architecture of the Sentinel VoLTE include:
iFC triggering chaining and the SCC and MMTEL
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”. |
Co-location using the Rhino SIS
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:
