Sentinel VoLTE Architecture

This document is intended for:

Find out here about:

Rhino Sentinel delivers complete suites of fully-featured telecom applications for GSM (Sentinel Express) and VoLTE (Sentinel VoLTE) networks. And, unlike other solutions, Rhino Sentinel is completely open. It allows customers and their partners to extend and complement the application set using Sentinel Create, to go beyond the plain vanilla — quickly, cost-effectively, and safely.

The Sentinel VoLTE solution implements the Multimedia Telephony Application Server (MMTEL-AS) and the Service Centralisation and Continuity Application Server (SCC-AS) on the Rhino TAS. It includes built in support for multiple Charging systems.

The main benefits of the solution are:

The OIP service provides the terminating user with the possibility of receiving trusted (network-provided) identity information in order to identify the originating user.

The OIR service is a service offered to the originating user that restricts presentation of the originating user’s identity information to the terminating user. Both permanent and temporary modes are supported.

This service is implemented by the features:

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving trusted information in order to identify the terminating party.

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the terminating party to prevent presentation of the terminating identity information to the originating party. Both permanent and temporary modes are supported.

This service is implemented be the features:

The Communications Diversion (CDIV) service enables the diverting user to divert the communications addressed to the diverting user to another destination. This includes the following services:

The CDIV service also checks and adds to the SIP history-info header as required, for example to determine if the diversion limit has been exceeded.

This service is implemented by the feature MMTelCDIV.

The Communication Hold supplementary service enables a user to suspend the reception of media stream(s) of an established IP multimedia session, and resume the media stream(s) at a later time.

This service is implemented by the feature MMTelHold.

The Communication Barring (CB) service offers the following services:

The following conditions are supported:

These services are implemented by the features:

The Operator Determined Barring (ODB) is not part of GSMA IR.92, but we include it here because it is related to barring conditions. ODB conditions are evaluated by the following services:

Note 1: The indication of a "Premium Rate Communications Information or Entertainment" is defined on TS 24.315 Release 12.1.0 on Section 3.1:

For more information see Operator Determined Barring.

The Explicit Communication Transfer (ECT) service enables a transferor to transfer the call to a transfer target. The Explicit Call Transfer service uses 3PCC Call Transfer Procedures in case the transferee can not handle the transfer request. There is more discussion of this service in the Explicit Communication Transfer page.

This service is implemented by the feature MMTelECT.

The Communication Waiting (CW) service enables a terminating party to be informed at the time that a new communication is requested. The user then has the choice of accepting, rejecting, or ignoring the incoming communication.

This feature is implemented by the feature MMTelCW.

Sentinel VoLTE supports three party conferencing (3PTY) as part of this service. The following operations are supported:

This service is implemented by the features:

There are two scenarios in which a transfer can be initiated:

Consultative ECT using the 3pcc procedure does not support reusing the existing leg between the AS and the transfer-target, instead a new leg is created to link to the transferee.

Under certain circumstances the standard signalling flows may be interrupted and the feature will set up the new dialogue using Third Party Call Control (3pcc) procedures.

For feature details see MMTelECT.

VoLTE creates several instances according to which user the AS is serving. Those instances could also be spread across multiple nodes depending on the production environment. For simplicity we consider the transferor, the transferee and the transfer target being served by the same node and some IMS core elements are not shown.

The diagram below shows the MMTel instances when a communication transfer happens among A, B and C, where A is the transferor, B is the transferee and C is transfer target.

When A initiates a dialog towards B, the INVITE request traverses the IMS network until it reaches the S-CSCF serving the user. The S-CSCF based on the registration data and the iFC in HSS forwards the messages to the VoLTE AS serving as MMTel AS. On receiving the INVITE request, the AS creates a session to process the call (A-orig) and apply the business rules including the MMTel services. After applying the business rules the AS forwards the INVITE request towards S-CSCF according to the B2BUA procedures.

The S-CSCF identifies a terminating call for B and forwards the signalling to AS again after checking the registration records for B and determining the AS serves B. This time the AS will create another session to deal with the call (B-term). This session will apply the business rules for the terminating call for B.

Now A and B are in communication. When A, acting as transferor, sends a SIP REFER message to B to refer to C, the ECT feature running in the A-orig instance changes the Refer-to-target header to a generated URI (ECT URI) and stores the information in the database. This change occurs to maintain the AS in the signalling path. The REFER message traverses all the existing instances until it reaches the B party. When B receives the REFER message, it initiates a new dialog towards the generated ECT URI.

The INVITE request sent by B creates a new MMTel instance for B originating (B-orig), that will apply the proper business rules for this session. When the INVITE request reaches the AS again, a terminating instance is created (ect-term in the picture). This instance will change the ECT URI to the proper target destination stored in the database and send the INVITE request towards C. On receiving the INVITE request for C, the S-CSCF determines that C is served by the same AS and so forwards the INVITE request to the AS. When the AS receives the INVITE request to C, it creates a terminating instance for C (C-term). This instance will apply the business rules for this terminating call and forward the INVITE request to C. C accepts the call and eventually the call session between A and B will finish.

The diagram below is similar to the one above, but B is the transferor, A is the transferee and C is transfer target.

For this scenario, when B sends a REFER to A to refer to C, the new ECT URI is generated on the B-term instance. When A sends the INVITE to the ECT URI, a new instance is created for A (A-orig'). The signalling then proceeds identically to the previous example.

The indication that the Explicit Communication Transfer service was triggered is present on the charging procedures (Online charging and CDR generation). The MMTel-SService-Type AVP set to 20 indicates the ECT service was used. This information is set on the instances where possible to identify the ECT service: A-orig, ect-term and B-term when acting as transferor.

The MMTel-SService-Type AVP is present in MMTel-Information AVP. For more information see Populated AVPs in the MMTel-Information AVP.

3GPP defines Flexible Alerting in TS 24.239 and the flexible alerting subscriber data schema is defined in TS 24.239 and TS 29.364. The service allows the creation of a group of member identities bound to a single number, called the Pilot Number. When a call to the Pilot Number is identified, VoLTE will alert all the members of the group and the caller is bound to the first member of the group that answers the call.

The group of identities that may be contacted by the Flexible Alerting feature is called the FA Group.

There can be two types of FA Group:

These groups have different rules for dealing with SIP responses.

For single-user

For multiple-users

There are two alerting modes for FA. These are:

In the sequential alerting mode the group members are alerted in order, with each member sending a final response or timing out before the next is alerted. In the parallel alerting mode all group members are alerted at once.

Flexible Alerting allows the call to continue after final responses on one or more group members.

OpenCloud’s Flexible Alerting supports both Parallel or Sequential alerting mode by a configuration under MMTelDetermineFAConfigProfileTable. The configuration table can be accessed through REM and is specified using the MMTelDetermineFAConfigProfileTable profile table name. The feature profile is scoped by the sentinel key and the pilot number, meaning that each Pilot Number requires a profile, otherwise VoLTE will fallback to a default profile not scoped by the Pilot Number.

A subscriber with 2 registered devices (UE1 and UE2) under the same IMPU makes a call to another device B from UE1. Once the call between UE1 and B is established, the subscriber can use the registered UE2 to pull the call to that device. The user calls a special URI previously configured in the AS (see DetermineVoltePlanId). The AS will verify the called URI is a Session Transfer to Own Device URI service and pull the call to the UE2. The UE1 will be disconnected as soon as the session between UE2 and B is established.

The service also works for the terminating case, which means that the subscriber B receiving a call can also use another registered device (B') under the same IMPU to pull the call.

The flow below shows a basic call flow with a simple transfer.

The service is composed of several features:

The interactions among the features are show below:

The DetermineVoltePlanId sets the session to mmtel and also checks if the request URI is for the STOD service.

The TrackSessionPreAnswer feature is used to process the session tracking information from session state.

The MMTelStodEnabled checks its profile to assert that the user is allowed to trigger the service and if allowed it will set the proper procedures to cause the session to be tracked and the MMTelStodBind feature will bind the session to an ACI name. It also creates an external tracking key for the session and adds it to the set in session state.

This ACI name will be reconstructed by the MMTelStodDetermineTargetSession feature on receiving a transfer INVITE and the MMTelStodTriggerAnchor will route the transfer INVITE to the existing session.

The MMTelStodProcessHandover intercepts the transfer INVITE and do the procedures to connect the existing called party to the new calling party.

Support of multiple OCSs is a key requirement for the session control element, for several reasons:

Sentinel is designed to provide session control on behalf of multiple OCSs. Sentinel determines which OCS to send the charging messages to in real time at session initiation. Different schemes may be utilised to determine the correct OCS. For example, it might be done by subscriber location, or attached network, or a real-time lookup to an external real-time database, or based on the APN used by the subscriber.

In the middle of a SIP session, media streams may be added and removed, as well as having their codecs changed. When codecs change, Sentinel VoLTE consults its SDP codec configuration to determine if the change was a “meaningful” change from a charging perspective (for example, if an audio call was changed to an audio and video call).

If a change is deemed meaningful, Sentinel performs client-initiated re-authorization towards the Online Charging System. If a change is not meaningful, the current credit reservation remains valid. This is explained in more detail in the Charging support section.

Rhino Sentinel writes a CDR for all charging session attempts, whether the session was successfully completed or could not be completed due to some error.

CDRs generated by Sentinel may also be used for offline charging situations.

The CDRs are written to a file in a configurable location and contain all the parameters that are available to the Rhino Sentinel. More detail on Sentinel VoLTE CDRs can be found in the Charging Information section of the Sentinel VoLTE Administration Guide.

VoLTE sends charging information to a configured Charging Data Function via Diameter Rf interface.

The Rf Control Resource Adaptor receives request from VoLTE charging features and ensure the messages are persisted in the CDF or in a local disk buffer is case the CDF is not available. As soon as the CDF is available it will send the messages stored locally until the buffer is empty.

For more information see Rf Control Resource Adaptor Architecture.

Sentinel VoLTE can be installed to use a Prepaid Service Control Point as the OCS, rather than communicating via Diameter Ro to the OCS. The use of Ro, CAP or neither for online charging is enabled through the Selection of charging mode. In all cases, Sentinel VoLTE will write a CDR for the session.

True ICS rely on either enhanced handsets (ICS UEs) or enhanced MSC Servers (e-MSS).

The ICS approach stated in GSMA IR.64 is based on the e-MSS, and therefore ICS UEs are not currently considered in Sentinel VoLTE. However this support can easily be added to the solution.

Sentinel VoLTE currently supports a non-ICS enhanced solution based on a combination of existing CS services within the MSC, and CAMEL based routing of CS-originated calls into IMS, as described in GSMA IR.64.

This is shown in the diagram below.

In this diagram:

In a CDMA network, the IN SCP role is supported with a dedicated service that receives an OriginationRequest or AnalyzedInformation trigger and returns an IMS Routing Number (IMRN).

For sessions that terminate in the IMS domain, the SCC-AS is responsible for deciding whether to route the session to the CS network or the PS network — depending on registration, network characteristics, and subscriber preferences. This is called T-ADS.

Out of the box, Sentinel VoLTE supports a standard algorithm for T-ADS, which is fully extensible and customisable by a third party:

In addition to the standard T-ADS algorithm, Sentinel VoLTE supports different strategies for routing signaling towards PS or CS domains. These include:

For further details refer to the Terminating Access Domain Selection Features section of the Administration Guide.

Sentinel VoLTE supports enhanced Single Radio Voice Call Continuity (eSRVCC — from 3GPP Rel 10); providing bi-directional transfer of sessions between the IMS packet-switched and GSM circuit-switched networks. This mechanism relies on the presence of an ATCF (Access Transfer Control Function) in the operator’s network.

ATCF and ATGW were introduced as an enhancement to the base SRVCC specification as a means to localise media transfer. Previously, the new SDP offer from the MSC-S/MGCF had to be negotiated hop-by-hop to the remote UE, which incurred a delay. Using the ATCF, which architecturally sits in the Serving/Visited network — alongside the MSC-S/MGCF — normally entails a single hop of SDP Offer/Answer, which represents a significant optimisation of the session transfer.

Currently, Sentinel VoLTE supports PS to CS transfer of sessions in the following cases:

Other sessions for a transferring device’s C-MSISDN are treated as superfluous sessions.

Service Continuity and Access Transfer in Sentinel VoLTE relies on both Session Tracking, and a Shared ATU-STI.

Features that implement Access Transfer are documented in the Packet Switched to Circuit Switched Access Transfer Features section of the administration guide.

In the diagram below, the components OpenCloud provides are in green.

VoLTE includes the ‘session processing’ parts:

It provides web-server based infrastructure for:

It also provides Online Charging Support by either using the Ro interface or CAP interface with IM-SSF Protocol Translator and Offline Charging Support via Rf interface and CDRs. For more information see the Charging Support.

The diagram below shows where Sentinel VoLTE fits into an LTE network.

The B2BUA architecture includes:

VoLTE supports either HSS or HLR for storing Subscriber Data. The data from the HLR and HSS is normalized in VoLTE and used by MMTEL and SCC services. This means that the Operator can use either data source without changing the service logic.

The subscriber’s supplementary services data is stored in the HSS as transparent data. Sentinel VoLTE TAS queries the HSS via the Sh interface to read and store the data.

The data is stored in XML format and can have the standard service data and extensions or even proprietary data sets.

The Media Resource Function (MRF) is responsible for providing multimedia-related functions, such as mixing of streams of audio and audio/video conferences, controlling Interactive Voice Response (IVR) sessions, and playing back multimedia.

The MRF can be invoked by single-purpose protocols, such as NETANN, when the TAS does not need to have further control of the session. This is useful for actions such as post-call announcements where the TAS hands over the control of the session to the MRF. The single-purpose protocols can be used together with the VoiceXML protocol to specify the interaction script that the MRF executes for the call (TAS forwards the SIP INVITE message with the VoiceXML URI in a SIP URI parameter).

For more complex scenarios, the TAS uses other XML-based protocols to control the MRF, such as MSML. The TAS forwards the SIP INVITE with the SDP information to the MRF. The MRF establishes a RTP stream with the UE. After that, the TAS sends MSML documents inside SIP INFO messages with the actions that MRF should execute (for example, play announcement).

Sentinel VoLTE supports NETANN and the MSML interface. A H.248 interface is not supported, so the MRF is expected to provide both the MRFC and MRFP elements.

An MRF is not included within Sentinel VoLTE; however, Rhino TAS has been integrated multiple times with MRFs and media servers from all major vendors (including RadiSys, Dialogic, and Alcatel-Lucent).

Sentinel VoLTE is well-suited to cloud deployment. Find out more at the cloud and virtualisation page.

The following diagram illustrates Sentinel VoLTE’s XCAP architecture within the IMS:

The Ut interface provides a user’s device with the ability to manipulate a configuration document. This document may contain user specific service settings such as privacy setting, communication barring and forwarding rules. TS 33.222 does not define how the MMTel-AS stores this document. However, 3GPP TS 29.364 defines a standardised XML schema for representing both the User and Operator settings for these services. TS 29.364 also defines the XML schema for transporting the user specific settings via the XCAP interface. This is called the "simservs" document. TS 29.364 also defines that an Application Server can store this service data on the HSS through the Sh interface as transparent data.

Sentinel VoLTE provides an XCAP server web application that implements the XCAP protocol towards the UE, and supports the XML schemas for user and operator data defined in TS 29.364, and stores and retrieves this information according to 29.364 in the HSS using Sh Transparent Data.

The diagram above shows several XCAP servers, as MMTEL-AS and Other-AS. Sentinel VoLTE provides the XCAP Server rather than the Authentication Proxy (AP) in the 3GPP architecture.

Sentinel VoLTE’s XCAP server application requires that the Ut/HTTP Requests have been Authenticated before reaching the XCAP application. Un-authenticated requests are rejected. Authentication may be achieved through use of the Sentinel Authentication Gateway product, or by using a separate Authentication Proxy.

The Sentinel Authentication Gateway is co-located with the XCAP server application rather than being a discrete AP. See Sentinel Authentication Gateway’s Architecture Overview for further information.

There is a subtlety worth noting with respect to the per-service "active" attribute in the User portion of each MMTel Service.

The active attribute is specified as an optional boolean attribute in the XML schema for the simservs and MMTel-Services documents.

In an XML document, this means they can have three possible values:

The specifications assign special meaning to these ‘active’ attributes when the attribute in the document does not exist:

Regardless of the active flag’s state (nonexistent, true, or false) a request can configure other portions of the service. For example, if Communication Diversion has no ‘active’ attribute, a request can configure communication diversion rules.

In summary, if an active flag is nonexistent this means that the user equipment cannot disable the feature. If the operator wants the user equipment to be able to enable or disable the feature, then the ‘active’ attribute should exist (and therefore be either true or false).

If a user’s MMTel-Services document does not contain a named service (for example, <communication-diversion>) the UE cannot indirectly or directly create this element. Child elements of a named service can be modified/created/removed, provided that the named service is present.

The IMS Operator Determined Barring service has both session processing and XCAP related behaviour. The XCAP related Operator Determined barring behaviour enables the operator to disallow a user’s capability to view and change their service settings.

The Sentinel XCAP server is a layer on top of the existing provisioning services and runs alongside the Sentinel REST machine API. XCAP is defined using REST principles and the implementation uses much of the same technology as the Sentinel REST API. It can be co-deployed with the Sentinel REST Provisioning API, and web human user interface, like this:

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:

Rhino Sentinel VoLTE implements both the SCC-AS and the MMTEL-AS. The session includes four “back-to-back user agent” instances:

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:

All components that need access to any data from the HSS, including both transparent data and non-transparent data, access it through the Sh Cache Microservice component.

This includes:

For more information on the Sh Cache Microservice see Sh Cache Microservice architecture.

All components that need access to data from the HLR, access it through the CGIN MAP component.

This includes:

For information about the components that use the HSS and/or HLR for accessing supplementary Service Data refer to Supplementary Service Data Access

All components that need access to any data from the HSS, including both Transparent and Non-transparent data, access it through the Sh Cache Microservice component. Components that use Supplementary Service Data in the HSS include:

For more information about the Sh Cache Microservice see Sh Cache Microservice architecture

All components that need access to data from the HLR, access it through the CGIN MAP component. Components that use Supplementary Service Data in the HLR include:

The following image shows the three key types of charging instances. Each is a Sentinel VoLTE B2BUA.

The diagram shows the three key concepts:

Forwarded Sessions may be forwarded, and then forwarded, and so on, infinitely. To stop infinite forwarding, the History-Info header is used.

MMTEL’s CDIV Service (a feature in Sentinel VoLTE) is responsible for stopping infinite forwarding.

Let us assume that Online Charging is used for every session:

Therefore, each Instance is creating Online Charging requests. So for a session that is forwarded once, and only once, and answered, the OCS will see four sessions:

In the Terminating case — typically if the B party is not roaming — then the B party is often not charged.

In order to disable Online Charging for the B-party’s Terminating Instance (for example, when not roaming), you can:

All instances within a network can be tied to the same “real world session” through the IMS Charging Identifier (ICID).

Under the SIP protocol, media streams may be added and removed, as well as having their codecs changed.

When codecs change, Sentinel may consult its SDP codec configuration to determine if the change was a “meaningful” change from a charging perspective.

Below is a screen showing Sentinel VoLTE’s default codec configuration:

Codecs in the same equivalence class are treated as “equivalent” from a charging perspective; so changes between codecs in the same class do not cause client-initiated re-authorization.

The table in the image above can be found by navigating through REM to Management ▶ Profiles and scrolling to select “SdpMediaCodecProfileTable”. This table can be edited, and new codecs and equivalence classes introduced.

Sentinel VoLTE has support for allowing sessions to terminate in WiFi networks (Voice over WiFi). When a session is answered, the Terminating Access Domain Selection (T-ADS) Features on the SCC AS will analyse the response to determine the type of network that the call is terminating in. Once the network type has been determined, the T-ADS features will attach a proprietary header to the response before forwarding it upstream. This header is called the OC-Terminating-Domain Header, and when a session is answered over a WiFi network, the header will be given the value PS=WLAN.

When Sentinel VoLTE is configured to use online charging this header will be consumed at the MMTel AS serving the terminating user. A feature on the MMTel AS called MMTelWifiChargingFinalisation will read the header and, if the value matches PS=WLAN, the feature will issue an instruction to any active online charging instances to finalise charging for the terminating user, before stripping the header from the upstream forwarded response. When Sentinel VoLTE is not configured to use online charging, the header will not be stripped by the MMTel AS. This allows it to be read by upstream charging functions.

The IM-SSF contains support for the OC-Terminating-Domain header. It terminates the IN dialog towards the Prepaid SCP if it is processing a terminating session, and the terminating 2xx response to the INVITE contains the OC-Terminating-Domain header with value PS=WLAN. In this case it strips the header before forwarding the 2xx response upstream.

The Rf Control Resource Adaptor allows VoLTE to persist offline charging information in the Charging Data Function (CDF). The principle is the same as writing a CDR, but instead of storing the information in a local disk, the Call Detail Records are sent via Diameter Rf interface to any CDF connected.

The AVPs that are populated on the Diameter Rf interface are documented on the Rf Interface AVPs section of the Sentinel VoLTE Administration guide.

For more information on Rf Control Resource Adaptor see Rf Control Resource Adaptor Architecture.

The AVPs that are populated on the Diameter Ro interface are documented on the Ro Interface AVPs section of the Sentinel VoLTE Administration guide.

When configured for both online and offline charging, it may be desirable to allow sessions to proceed when there is a communications outage with the OCS.

This can be achieved using the procedure at Fault Tolerant Online Charging.

Note that when configured this way, conference calls will still fail when the OCS connection fails or times out mid-session, and there will be no CCR-T for calls that experience an outage.

This deployment corresponds to the volte-registrar-full-deploy module.

This deployment gives you the Third Party Registrar as a standalone service.

This deployment is just the Third Party Registration features.

This deployment corresponds to the sentinel-volte-basic-dev-deploy module.

This is intended to be a lightweight deploy that has only the core features required for basic call flows.

This deployment has the same content as Registrar with the addition of General features, SIP features, and General VoLTE features.

This deployment corresponds to the sentinel-volte-mmtel-deploy module.

This deployment allows the MMTel Services to be run. It does not include any features that make use of CGIN.

This deployment has the same content as Basic Dev with the addition of MMTel features.

This deployment corresponds to the sentinel-volte-mmtel-gsm-deploy module.

This deployment has the same content as MMTel but includes features that make use of CGIN, and the IM-SSF.

This deployment corresponds to the sentinel-volte-scc-cdma-deploy module.

This deployment allows the SCC-AS Services to be run using CDMA for the MAP messages.

This deployment has the same content as Basic Dev with the addition of SCC features and the CDMA Reorigination Service, but excludes GSM features.

This deployment corresponds to the sentinel-volte-scc-gsm-deploy module.

This deployment allows the SCC-AS Services to be run using GSM for the MAP messages.

This deployment has the same content as Basic Dev with the addition of SCC features, but excludes CDMA features and CDMAFetchTLDN.

This deployment corresponds to the sentinel-volte-full-cdma-deploy module.

This deployment gives you a complete VoLTE that does both MMTel and SCC using CDMA. It has everything from the MMTel and SCC CDMA deployments.

This deployment corresponds to the sentinel-volte-full-gsm-deploy module.

This deployment gives you a complete VoLTE that does both MMTel and SCC using GSM. It has everything from the MMTel GSM and SCC GSM deployments.

The Sentinel VoLTE SCC-AS may detect SDP conflicts when forwarding SDP between a pair of legs on a session. This capability is currently only enabled in access transfer features. Other features may also access it through the sentinel-sip-spi API, see Using SDP conflict management in a feature below.

Conflicts arise when there is an existing media session established, and the SCC-AS receives an SDP offer from another source, that must replace the existing media. The new SDP offer must use the correct session ID and version, as well as having the same number of media (m=) lines that the previous offer had, otherwise the new offer will be rejected. If the new offer comes from a different entity to the previous offer, then there will almost certainly be a conflict. This situation occurs in many access transfer scenarios.

The conflict management system is defined in terms of source and destination legs:

When a feature detects that SDP conflict management is required, it sets up an SDP rewriting association between the source and destination legs. Classification of source and destination is up to the feature, but for access transfer cases, "source" means the new access leg, and "destination" means the remote leg.

When the SDP association is created, Sentinel VoLTE determines a set of transformations that apply the appropriate changes to the SDP, based on the previous and new SDP offers. The possible types of transformations are described in SDP conflict types below. From this point, for the remainder of the session, SDP rewriting is performed in both directions automatically, by the SDPRewriter system feature.

When performing access transfer, it is sometimes necessary for the SCC-AS to send a new SDP offer so that the remote party can handle the new media streams, enabling session continuity. The SCC-AS must ensure that any new SDP offer is compatible with previous SDP offers sent to the remote party. If not, the remote party UE will reject the new offer, and the access transfer will fail.

The figure below shows an example call between UEs A and B, with the call anchored in the originating SCC-AS. UE-A initially requests audio and video streams. For brevity assume both streams are accepted by UE-B (SDP answer not shown).

UE-A moves out of coverage range, triggering a PS-CS access transfer. The access transfer INVITE sent by the ATCF has different content to the previous SDP offer from A. This may be because the media was not anchored in the ATGW, so the ATCF must send a completely new SDP offer to the SCC-AS.

The SCC-AS can see that the new offer is different to the previous one; the session IDs and versions differ, and also there is only one media description (no video). The SCC-AS must perform a remote update re-INVITE with UE-B, so that UE-B knows about the media change.

If the SCC-AS just sent the new SDP offer to UE-B verbatim, UE-B would have to reject it, because the offer uses a different session ID (45678, not 12345), and the version is out of sequence. UE-B would expect the next offer to have session ID 12345 and version 12346 (incremented by one from the previous SDP offer 1).

To resolve this conflict, the SCC-AS adjusts the SDP offer so that it uses the correct session ID and version, and also sets the video media description’s port to zero so that UE-B knows it is no longer in use (media (m=) lines in SDP cannot be removed during a session, only changed or added).

With the adjusted SDP offer 2a, UE-B can process it correctly, switching to the new audio stream and stopping the video stream. Conversely when the SDP answer 2a arrives at the SCC-AS, the disabled video media description must be removed. This is so that the number of media descriptions in the answer matches what was in the ATCF’s original SDP offer 2.

The new media is now established between UE-A and UE-B, so the call can continue, with audio at least.

The Sentinel VoLTE SCC-AS handles most types of SDP conflicts that may occur when using access transfer, as described below.

A feature may enable SDP conflict management for a pair of legs using the SdpRewriting class from sentinel-sip-spi:

This sets up the SDP association between the legs named newAccessLegName and remoteLegName. This association is persisted in session state, and includes the set of transformations to correctly update the SDP in both directions.

The feature does not need to do any more work; the actual processing of the SDP is performed by the SDPRewriter system feature, after user features have run. Over the lifetime of the session, either party may change the set of media descriptions. The SDPRewriter system feature ensures that the SDP transformations are updated accordingly to account for new and updated media descriptions.

The SCC-AS tracks any originating or terminating session where the served user’s identity is registered by a UE that has a UE-SRVCC-Capability indicator. This occurs regardless of whether or not Session Replication is enabled.

In order to enable the Re-INVITE Based Three-party conference setup the SCC-AS will track the access leg for every originating or terminating session if the EnableSCCConfHandling attribute is set to true. For further information refer to SCC Conference Handling Configuration and Reuse of Access Transfer procedures for conferencing.

When Session Replication is enabled all SIP Dialogs in the replicated Session are tracked - not just the access leg.

A Tracked Session is a session where Session Tracking is enabled. A session can have its tracking enabled at various "points".

These are:

In the case of the SCC-AS, session tracking is enabled for "Confirmed" if the UE is SR-VCC capable. Session tracking is enabled for "Early" and "Confirmed" if there is a terminating attempt and the UE indicates support for alerting access transfer. Session tracking is enabled for "Half dialog", "Early", and "Confirmed" if the SCC-AS is triggered for an originating session, and the UE indicates support for PS to CS SRVCC for originating calls in the pre-alerting state.

A tracked session writes information related to the SIP dialog(s) for the served user. In the case of an originating B2BUA, this is the dialog(s) towards the originating user. In the case of a terminating B2BUA this is the dialog(s) towards the terminating user.

Session Tracking is implemented by the Access Leg Tracking and External Session Tracking features.

Rhino’s Session Ownership Subsystem provides support for integration to various Key/Value "NoSQL" Databases. Out-of-the-box support for the Cassandra database is provided for Session Ownership due to its high availability, and replication capabilities.

Each site runs a TAS cluster, and a Cassandra cluster. The minimum number of nodes per-site for the Cassandra cluster is three, and for the TAS cluster is two. Each site should essentially repeat this structure.

A device may participate in several sessions at once. For example, it may have an ACTIVE session, and several HELD sessions; or it may have an ACTIVE session and an ALERTING session; and so-on. The SCC-AS signalling anchor instances for each of this device’s sessions may reside on different TAS cluster members, and possibly different TAS clusters. When multiple TAS nodes (regardless of which cluster) share an ATU-STI, a Handover INVITE may arrive at any of the nodes. Yet different nodes may be serving that device’s sessions. Therefore there is a need to co-ordinate Access Transfer between the nodes sharing the ATU-STI.

The following diagram shows a four node TAS cluster, where all nodes share a single ATU-STI. There are four sessions in progress. Three sessions share the same Correlation-MSISDN (C-MSISDN) (12345) and so are for the same device. Each session’s signalling anchor is located on different TAS cluster members. The Session Tracking Database (Cassandra) is storing the location and other meta-data (e.g. the SCC-AS-URI, and state fields) related to each of these sessions.

The ATCF addresses the SCC-AS nodes via the ATU-STI. A common DNS configuration for the ATU-STI is to allow all cluster members to be resolved through the ATU-STI. So a single Handover INVITE with a Request-URI set to the ATU-STI will route to one of the four cluster members. A second Handover INVITE with the Request-URI set to the ATU-STI may route to the same, or another cluster member.

Handover INVITEs from the ATCF include the C-MSISDN in the P-Asserted-Identity header. The C-MSISDN is used by the SCC-AS in order to determine the Transferable Set. The Transferable Set includes any session to transfer, as well as any session that will not be transferred and is considered superfluous.

Assume that the system state is as described in the diagram above.

A Handover INVITE is sent from the ATCF with the Request URI set to the ATU-STI and a C-MSISDN equal to 45678. It is routed to the TAS cluster node SCC-AS-102. This node consults the Session Tracking Database, and observes that C-MSISDN 45678 has a single ACTIVE session, and that session resides on node SCC-AS-104. Therefore it proxies the INVITE request to the AS-URI SCC-AS-104. The TAS cluster node SCC-AS-104 then receives the proxied Handover INVITE and is able to perform SCC-AS procedures for transferring a single active session. In this case, the co-ordination is simply the proxying of an INVITE request.

Assume that the system state is as described in the diagram above.

A Handover INVITE is sent from the ATCF with a Request URI set to the ATU-STI and a C-MSISDN equal to 12345. This Handover INVITE is routed to the TAS cluster node SCC-AS-104. The SCC-AS reads the Session Tracking Database and observes that C-MSISDN 12345 has three sessions. An ACTIVE session on node SCC-AS-101, a HELD session on node SCC-AS-102, and an ALERTING session on node SCC-AS-103. Now, the SCC-AS determines that the Transferable Set has a single ACTIVE session, and two superfluous sessions. Therefore the Handover INVITE is proxied to node SCC-AS-101.

Once the node SCC-AS-101 has performed the appropriate procedures to transfer the ACTIVE session, it then signals nodes SCC-AS-102 and SCC-AS-103 instructing them to clean up a superfluous session. It uses a SIP MESSAGE request, containing an OC-Access-Transfer-Procedure Header with an instruction to remove a superfluous session, and a Target-Dialog header indicating which session is superfluous.

The following call flow diagram illustrates this example.

This diagram shows a cluster of two Rhino nodes. The cluster is not limited to two nodes. Each node runs in a single multi-threaded Process.

Applications and their components store Session State into the Local Session State Database. The SIS (a component providing the SIP interface) is configured to write state for established dialogs into the Local Session State Database. The Local Session State Database is configured to write data to a Key/Value Store

For further information related to Session State handling, refer to Storage of Session State.

When Session Replication is enabled, a record of which Rhino SLEE node is processing a particular protocol session (e.g. SIP Dialog) is stored by Session Tracking in the Session Ownership Subsystem.

DNS is used to route requests to a preferred node, with other cluster nodes acting as a backup. This mechanism scales horizontally as cluster size increases. For further information refer to DNS Redundancy and Record Route to enable fail-over of sticky sessions.

Session related information is stored in the Rhino platform’s Local Memory Database (MemDB local). This is resident in the JVM heap. Session related information contains variables such as:

The Local Memory Database is the master for the data, and is configured to write data externally to a "key-value store" post transaction commit. In non-failure cases, the key-value store is only written to. Reads are served from the Local Memory Database.

In failure cases, a read-miss in the Local Memory Database causes a read to occur in the key-value store. Once the key and it’s value have been read they are then mastered in the Local Memory Database of the reading JVM process.

The "key-value store" is an external database. It is plugged into the data-storage layer of Rhino’s Memory Database (MemDB).

Rhino 2.6.1 includes out-of-the-box support for the Cassandra Database as the "key-value" store. For further information see Key/Value Stores.

In order to avoid inconsistency of the data, where multiple JVMs are accessing local data and not reading the "key-value store" a mechanism called Session Ownership is used.

The Local Memory Database delays local writes before pushing the modified data to the external key-value store. This is because Sessions typically undergo short periods of multiple signalling transactions, followed by relatively long idle periods.

Before failure shows a two node Rhino cluster, communicating with the CSCF via SIP, and with a Cassandra cluster shown as the "Cassandra State Store". The Rhino nodes contain all necessary components, including the Sentinel VoLTE application, SIS, and resource adaptors. Rhino is configured with a Session Ownership Store and Key Value store, both using the Cassandra cluster.

A call has begun, and is answered. The call is stick to Rhino node 1. As the call has been answered, it’s session state is marked for persistence - and so the session state is written out to the Key Value store ("Cassandra State store" in the diagram). A session ownership record for each SIP dialog related to the call is written into the Session Ownership store ("Cassandra State Store" in the diagram).

Node 1 fails shows that node 1 fails some time after the call is answered.

Session failover shows signalling after node 1 has failed. As an example a user places the call on hold. The CSCF uses DNS procedures as per RFC 3263 and the DNS Redundancy design. It finds that node 1 is not responsive and selects node 2, and sends the mid-dialog request to node 2. Node 2 consults the Session Ownership subsystem, and notices that node 1 (the owner of the SIP Dialog) is no-longer part of the cluster. Node 2 then takes over ownership of the SIP dialog and entire Session. It then retrieves session state from the "key-value" store.

Once all session failover handling has completed, the session is now stuck to node 2. This is shown in Post failover.

If a call lasts long enough it is possible that Node 1 restarts while the call is still open it is possible that Node 1 can receive SIP requests related to the call. This is due to the DNS Redundancy design. When this happens node 1 will recognise that it does not have state for the SIP dialog and proxy the request to node 2 through the use of the Session Ownership subsystem. This is shown in Node 1 restarts.

The following are documented limitations with Session Replication:

Each Rhino cluster stores it’s configuration in Profiles that are backed by a disk based SQL database, PostgreSQL. Each site runs one or more clusters. A cluster does not span sites.

No subscriber data is stored in the platform.

Companion device behaviour is enabled for a subscriber when the operator provisions companion device information in the subscriber’s Metaswitch-TAS-Services document in HSS transparent data. See Provisioning Companion Devices below.

The Metaswitch-TAS-Services document is read by the MMTel SubscriberDataLookupFromHSS feature. If companion device information is present, it is saved in session state for use by subsequent features.

A subscriber’s companion device information must be provisioned in HSS transparent data, using the Metaswitch-TAS-Services service indication.

The document’s XML schema is shown in the MetaswitchServicesType API documentation.

Below is an example XML fragment showing that the user has a companion device capable of PS radio (VoLTE/VoWifi), which is currently the only supported type of companion device.

If the selected charging mode is Diameter Ro/Rf, there is no impact on charging when a companion device is in use. The calling and called party numbers are those of the primary device.

If CAMEL online charging is used via the IM-SSF service, and the SCC T-ADS forks an INVITE creating multiple outbound legs, then an IM-SSF service instance (and SCP dialog) is created for each outbound leg. Only one leg will be answered, and CAMEL charging will be performed as usual for that leg. The unused legs will terminate, and record zero-length calls on their SCP dialogs.

The terminating MMTel instance’s SubscriberDataLookupFromHSS feature reads the Metaswitch-TAS-Services document from HSS transparent data. If companion device information is found, this is added to session state. The SetCompanionDeviceHeaders feature adds the X-Msw-Companion-Device header to the outgoing INVITE. This header will be used in the terminating SCC-AS instance to trigger companion device behaviour.

If the INVITE is retargeted by the MMTel-AS, then the X-Msw-Companion-Device header is automatically removed. This is because the terminating subscriber has changed, and the TAS does not know if the new subscriber has a companion device. The INVITE will return to the S-CSCF, which will trigger a new terminating MMTel instance if necessary. When the new terminating MMTel instance runs, SubscriberDataLookupFromHSS will read Metaswitch-TAS-Services for the new subscriber.

The terminating SCC instance’s SCCTADSDataLookup feature checks for the X-Msw-Companion-Device header. If found, then the T-ADS routing mode is set to "parallel", overriding the configured default routing mode. This means the SCCTADSParallelRouting feature will be used to send the INVITE to the called party, so that the primary and companion devices will be alerted simultaneously. This includes the primary device whether it is attached to a CS or PS access network. Companion devices are currently only supported on PS access networks. Companion devices on CS networks will be supported in a future release.

If the companion device is registered then it will automatically be included in the determination of outbound routes. If a CSRN can be determined then T-ADS will automatically fork to the CS network. This means the primary device will be alerted if it is currently attached to CS.

If T-ADS is configured with EnableSipInstanceRouting = true, then it will fork the INVITE towards the available PS contact addresses, including the companion device, if any.

If EnableSipInstanceRouting = false then T-ADS will create a single outbould PS leg, and let the S-CSCF perform the forking to all available PS contacts, which will include the companion device if it has registered with the S-CSCF.

If configured with VoiceOverPSSupportRequired = true, then before determining the outbound PS routes, T-ADS will query the HSS T-ADS Information data reference to confirm that the subscriber is currently attached to the PS network.

More information about how outbound CS and PS routes are determined can be found in the SCCTADSDataLookup feature documentation.

If a companion device is in use, then SIP forking is more likely to occur. SIP forking may cause issues with upstream devices that cannot properly handle preconditions negotiation on multiple early dialogs. If this is a problem, then this can be worked around by enabling the StripPreconditions feature.

When this feature is enabled, Sentinel VoLTE features that create parallel forks (currently SCCTADSParallelRouting and MMTelParallelFA) can request that preconditions are stripped from outbound INVITEs, so that the called party UE will not try to use preconditions.

In this flow, T-ADS is configured with EnableSipInstanceRouting = false. This means that for the PS leg, T-ADS will forward the INVITE normally to the S-CSCF. The S-CSCF sees that there are multiple registrations for the user, so forks the INVITE to both devices.

In this flow, T-ADS is configured with EnableSipInstanceRouting = true. This means that T-ADS will perform the forking itself, and create separate PS legs towards each registered device. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.

In this flow, T-ADS is configured with EnableSipInstanceRouting = true and VoiceOverPSSupportRequired = true. This means that T-ADS will perform the forking itself, but will only create an outbound PS leg if the HSS can detect that the device is currently attached to the PS network. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.