This document covers procedures for deploying, configuring, and managing Sentinel VoLTE:

Tip Read this document in conjunction with the Sentinel VoLTE Architecture document.

Getting Started

This section explains how to set up a standalone version Sentinel VoLTE on a Rhino SDK.

In this section…​

Preparing to Install Sentinel VoLTE

Before you install Sentinel VoLTE, you need to download the SDK package, get other required software.

You can then either:

  • let the built-in installer install both the Rhino SDK and Sentinel VoLTE, or

  • install and configure Rhino and the JVM manually, then use the installer to install Sentinel VoLTE into your Rhino

In both cases you need to get a license.

Allowing the installer to install both the Rhino SDK and Sentinel VoLTE software is recommended for functional testing or experimentation with Sentinel VoLTE. For production installs and/or load testing it is recommended to manually install and configure Rhino and the JVM.

Finally, if you are planning to install Sentinel VoLTE on an existing OpenCloud Rhino installation, it makes sense to refer to other OpenCloud product dependencies

Download the Sentinel VoLTE SDK package

To get the latest Sentinel VoLTE SDK package go to https://repo.opencloud.com/artifactory/opencloud-sentinel-volte-2.7.0/opencloud/volte/2.7.0/sentinel-volte-sdk/ Choose the version with the highest release number.

The SDK package contains an installer, that can install Sentinel VoLTE as an out-of-the-box system. It is also an SDK allowing customisation of the product.

Warning You will need OpenCloud-supplied credentials to download the package.

Get required software

You’ll need the following software to run Sentinel VoLTE:

Software Download Link Documentation Link

Java JDK 7

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

Apache Tomcat 7.0.39 or greater (7.0.x series or 8.5.x series, not 9.x.x series)

http://tomcat.apache.org

Rhino 2.5.0.0 or later - optional - to be used when installing and configuring Rhino manually

Rhino 2.5.0 SDK from Artifactory

Rhino Documentation

Rhino Element Manager 1.5.0.4 or later

REM Download Page

REM Documentation

Sentinel VoLTE SDK including out of the box installer

Sentinel VoLTE SDK, from Artifactory

Sentinel VoLTE SDK

Cassandra Database, version 2.1.17 or later version from the 2.1.x series. Cassandra is required for SCC-AS functionality

http://cassandra.apache.org/download/

http://cassandra.apache.org/doc/latest/getting_started/index.html

Note that it is not necessary to configure auto-start (e.g. systemctl or init.d) for Cassandra or Tomcat.

Install and configure Rhino and the JVM

Optionally you can install and configure Rhino and the JVM for use with Sentinel VoLTE. This is recommended for production deployments, and clustered setups.

Alternatively for Proof of Concept and lab functional testing it is recommended to use the Installer documented in Installing Sentinel VoLTE Services

Install Rhino

1

Start by choosing a location to extract the contents of the Rhino package.

We’ll refer to this directory as RHINO_HOME.

2

Rhino must be started at least once to generate the necessary configuration files. To start Rhino, in the RHINO_HOME directory, execute:

./start-rhino.sh

3

Wait until Rhino is ready. It prints the following message in its log when ready:

SLEE successfully started on node(s) [101]

4

Stop Rhino by executing in the RHINO_HOME directory:

./stop-rhino.sh --node 101

(specifying the node ID of the local node)
Tip For more about installing and configuring the Rhino TAS, please see the Rhino v2.5 Documentation.

Configure Rhino and the JVM

If you want to install Sentinel VoLTE in top of an already running Rhino then this step must be performed. If you are letting the installer configure the Rhino SDK for you, this step can be skipped.

The following settings are needed:

Setting Configuration

Management database size

For a full Sentinel VoLTE install, the default Rhino 2.5 management database size is insufficient and should be increased to at least 400MB. To do this, edit RHINO_HOME/config/rhino-config.xml on all nodes, increasing the <committed-size> in the following section:

    <memdb>
      <jndi-name>ManagementDatabase</jndi-name>
      <message-id>10003</message-id>
      <group-name>rhino-db</group-name>
      <committed-size>400M</committed-size>
      <stripe-count>1</stripe-count>
      ...
    </memdb>

JVM

You’ll also need to configure the JVM:

For RhinoSDK: * The Rhino HEAP_SIZE setting should be set to 2048m at a minimum (for Java 7). For Java 8 use 2560m (to account for various changes in Java heap layout) * The recommended MAX_NEW_SIZE and NEW_SIZE setting for a Rhino node running Sentinel VoLTE is 1/4th of the total heap size (for example, 512m when the HEAP_SIZE is 2048m). * The MaxPermGen size should be increased from its default, to at least 512MB (for Java 7 only). To do this in Rhino 2.5, modify the flags -XX:MaxPermSize= and -XX:PermSize= in RHINO_HOME/config/jvm_args. For Java 8 this value is deprecated.

All of these settings can be found in RHINO_HOME/config/config_variables after running Rhino for the first time.

For Rhino Production:

The configuration will depend on the expected traffic characteristics and the hardware configuration. There is no rule of thumb for production setup and each project installation will require specific analysis. The only requirement is the MaxPermGen set to at least 512MB. Since there is no jvm_args file on Rhino Production, this option will need to be set in environment variables, the config_variables file, or the read_config_variables script.

Socket permissions

If running the installer remotely, you will need to add the host address where the installer is running to the mlet configuration file. In addition, you’ll need to add the address of any Rhino Element Manager hosts and any remote hosts from which you might access the Rhino console.

  • For RhinoSDK the configuration file is RHINO_HOME/config/mlet.conf

  • For Rhino Production the configuration file is RHINO_HOME/node-xxx/config/permachine-mlet.conf

  • In the configuration file look for the xmltag <security-permission-spec> and add the following entry, replacing <IP ADDRESS> with your installer’s IP address:

<mlets>
    <mlet enabled="true">
        <classpath>
            <jar-url>$${rhino.dir.base.url}/lib/jmxr-adaptor.jar</jar-url>
            <security-permission-spec>
		.... other entries

		permission java.net.SocketPermission "<IP ADDRESS>", "accept,resolve";

		.... other entries
 	    </security-permission-spec>
        </classpath>
    </mlet>
</mlets>
Important
Start Rhino to load the new configuration

To start Rhino, in the RHINO_HOME directory run ./start-rhino.sh.

This applies the Rhino and JVM configuration.

Get a license

Warning To install Sentinel VoLTE you need a license to run SIS, CGIN, and Sentinel VoLTE from OpenCloud. In order to obtain a license file, please contact OpenCloud. A full overview of license requirements can be found of this page: License Requirements.

If you allow the installer to install both Rhino SDK and Sentinel VoLTE for you, it will prompt you for the location of the license file.

If you prefer to set up Rhino manually, then you need to install the license file prior to installing Sentinel VoLTE.

To install your license file:

1

Make sure Rhino is started and running.

2

Go to the RHINO_HOME/client/bin directory.

3

In this directory, start the Rhino Console with the rhino-console script (or rhino-console.bat in Microsoft Windows).

4

In the Rhino Console execute, this command:

installlicense [PATH_TO_LICENSE_FILE]

([PATH_TO_LICENSE_FILE] should be relative to the RHINO_HOME/client/bin directory.)

Ports

If using the standard configuration, the following ports need to be open on the VoLTE TAS host’s firewall.

Port Purpose

5060

SIP traffic

5061

Secure SIP traffic

8080

REM GUI

1199-1203

RMI Access

If using other configuration the firewall should be configured for those non-standard ports. Other ports may be opened as needed. For example if ssh is used to administer a node, then port 22 would be opened

OpenCloud product dependencies

Sentinel VoLTE is built on top of other OpenCloud products. The 2.7.0.x series depends on the following series:

Product Series

Rhino

2.5.0.x

REM

1.5.0.4 or later

SIP

2.4.1.x

CGIN

1.5.4.x

SIS

2.5.4.x

SIS-EM

1.2.0.1 or later

Diameter

3.1.0.x

IM-SSF

1.4.6.x

CDR-RA

2.3.0.x

HTTP-RA

2.2.0.x

DB-Query-RA

1.4.0.x

FSM Tool

1.1.0.x

CQL-RA

1.1.0.1

Installing Sentinel VoLTE Services

Sentinel VoLTE is installed through the use of an installer program.

The installer can run in interactive and non-interactive modes - suitable for manual and automated installs respectively. When running in interactive mode it will prompt you for various necessary settings and save them.

Tip The installer will offer to install the Rhino SDK for you, or allow you to specify an existing Rhino installation. Once either a new Rhino SDK install, or an existing installation is selected the installer will install Sentinel VoLTE into your Rhino or Rhino SDK.

The installer prepares configures for a single node Sentinel VoLTE system, with a single peer for various other network elements such as:

  • Media Resource Function (MRF)

  • Interrogating Call Session Control Function (I-CSCF)

  • Home Subscriber Server (HSS)

  • Online Charging System (OCS), and/or Prepaid Service Control Point (SCP)

  • Alternative options for storage of the Third Party Registration data

For more advanced configurations, such as clustering, or multiple signalling peers, it is recommended becoming familiar with the Rhino platform, SIS and Sentinel VoLTE products.

To install Sentinel VoLTE services in interactive mode:

  1. Unzip sentinel-volte-sdk-VERSION.zip

  2. Run the installer

For further information on installation read:

1. Unzip sentinel-volte-sdk.zip

To unzip sentinel-volte-sdk.zip:

1

Copy the downloaded install zip file to a machine where Rhino and Sentinel VoLTE will run.

Tip It’s easiest if you create a new directory in the home directory. 
user@machine$ mkdir ~/sentinel-volte

2

Unzip.

user@machine$ cp ~/sentinel-volte-sdk.zip ~/sentinel-volte
user@machine$ cd ~/sentinel-volte
user@machine$ unzip sentinel-volte-sdk.zip

2. Run the installer

Tip The installer prompts you for various configuration settings, such as the SIP URI for the MRF. You can review and change settings prior to installation so don’t worry if you got something wrong first time.

The install program is split into several "phases".

These are:

  • initialisation of the environment

  • question and answer (in interactive mode)

  • review settings (in interactive mode)

  • execution of installation

NB: the installer captures full logging from the various tools that it uses, and writes these logs into the sentinel-volte-sdk/build/target/log directory.

NB: Before installing, if the host requires a proxy to access Artifactory then it must be configured in sdk.properties. sdk.properties can be found in the top-level directory of the unzipped package. Find the section marked with # Proxy settings and change it to the following:

# Proxy settings
#
sdk.http.proxyHost=<proxy hostname here>
sdk.http.proxyPort=<proxy port here>
sdk.https.proxyHost<proxy hostname here>
sdk.https.proxyPort=<proxy port here>
#
# These properties are used for both http and https.
sdk.http.nonProxyHosts=localhost|127.0.0.1

To run the installer:

1

The installer command is in the build/bin directory of the extracted Sentinel VoLTE SDK.

testuser@machine$ cd ~/sentinel-volte/sentinel-volte-sdk
testuser@machine$ build/bin/installer

The installer first initialises the environment. It typically shows output similar to the following

Initialising the SDK ...
Retrieving Installer dependencies ... done.

You may be prompted for Artifactory credentials, which should have been supplied to you by OpenCloud.

2

Question and answer to determine necessary settings

The installer will prompt the user for various values. A value inside square brackets, if present, is the default answer for that question. When the user presses the Enter key without entering any value the default is used if it is present. If the default isn’t present, the prompt will be repeated. In subsequent runs of the installer, the default will reflect the values that the user has previously entered.

Explanations of all of the questions the installer will ask are laid out over the next few steps. Note that some of the questions will only appear under certain circumstances, so not all of them will be seen in a given installer run.

3

Taking the SDK offline

The user is prompted whether or not they want to take the SDK offline.

You can optionally take the SDK offline by creating a local repository. This will take several minutes depending on connection speed, but will make subsequent retrievals much faster and remove the need for an internet connection.
Do you want to take the SDK offline? y/[N] >

If the user presses the Enter key then the default of N is applied by the installer. This means that the SDK remains online, and will connect to the OpenCloud repositories on an as-needs basis. Answering yes will create a local Ivy repository that includes all of the remote artifacts required to build the SDK.

The user is then presented with progress information related to the downloading of artifacts necessary to take the SDK offline. This process can take more than 30 minutes.

4

HSS or HLR

The user can choose to use the HSS or HLR for various functionality.

You can choose to use the HSS or the HLR. If you select HSS, then supplementary service data will be read from the HSS, and the CMSISDN will be used for SCC TADS Routing. If you select HLR, then supplementary service data will be read from the HLR, and the MSRN will be used for SCC TADS Routing.
Use HSS or HLR? [hss] >

If the user enters hlr then Sentinel VoLTE will be installed with support for querying the HLR for the supplementary service data and SCC TADS Routing. For an overview of Terminating Access Domain Selection (T-ADS) see Terminating Access Domain Selection (T-ADS) and Terminating Access Domain Selection Features.

5

Option for use of an external Prepaid Service Control Point for Online Charging

You can have the option of using CAP-based online charging instead of Diameter Ro-based online charging in your installation. This will deploy additional components.
Deploy optional CAP-based online charging components? y/[N] >

If the user press the key y then Sentinel VoLTE will install OpenCloud’s IM-SSF Service. This means that when online charging is used, there can be an option for selection of either CAP (to the Prepaid SCP) or Diameter Ro (to the OCS). For more information on this option please refer to the Session Processing section.

6

Creation of a deployment module

The installer will now create a suitable deployment module. This may take several minutes.

7

Basic SDK Questions

Your organization's name, e.g. Rocket Communications Inc.
sdk.component.vendor [UNSET] >

This value will be used for the vendor portion of the SLEE Component ID for all SLEE components published by the SDK.

sdk.component.version [1.0] >

This value will be used for the version portion of the SLEE Component ID for all SLEE components published by the SDK.

The name of the platform operator, e.g. Rocket.
sdk.platform.operator.name [UNSET] >

The name of the platform operator for the system. It is used extensively throughout configuration profiles.

An Ivy organization field, recommended lower case with no whitespace e.g. "rocket".
sdk.ivy.org [UNSET] >

This value is used as the org value for all Ivy artifacts created by the SDK.

sdk.ivy.publish.revision [1.0.0] >

This value is used as the base of the revision value for all Ivy artifacts created by the SDK. Additional letters and numbers will be appended to it to identify specific releases, snapshots and milestones when an artifact is actually published.

8

Install Rhino Questions

You can either have the installer set up a Rhino SDK for you or point it at an existing Rhino installation, SDK or production.
Note: If you want to use an existing Rhino installation it has to be running and a proper license has to be installed when finishing the installation after the configuration. Also make sure that you have adjusted the memory settings and created a tcapsim-gt-table.txt file as detailed in the documentation.
Set up a Rhino SDK installation automatically? y/[N] >

If you allow the installer to set up a new Rhino SDK installation, it will prompt for a license file.

Enter the path to your Rhino license file > /home/testuser/Downloads/opencloud.license

It then installs the Rhino SDK and starts it.

If you instruct the installer to use an existing Rhino, the installer will prompt for the path to the Rhino client directory.

Enter the path to your Rhino client directory > /home/testuser/rhino/2.4/client

If the associated installation is a Rhino production then additional information is required to complete configuration.

You can either have the installer deploy against Rhino SDK or production.
Does the specified client point to a production installation? y/[N] >

If you choose Yes, then the installer prompts for details of the cluster nodes and hosts.

Enter your Rhino node setup.
It has to be formatted like this: {nodeId,nodeId}host,{nodeId}host
Examples:
  {101}localhost
  {101,102}host1,{103}host2
Node setup [{101}localhost] > {101}hostname1,{102}hostname2

9

International and Roaming Network Questions

Home domain [example.com] >

A domain name for a home network.

Home network prefix [65] >

A corresponding network prefix for that home domain.

Home network MCC [525] >

The MCC for the home network

Note Home network MCC added in 2.7.0.2 
Comma separated list of home network MNCs eg 01,02
Home network MNC list [01,02,07] >

A list of MNCs for the home network.

Note Home network MNC list added in 2.7.0.2 
Roaming domain [roaming.com] >

A domain name for a visited network.

Roaming network prefix [65] >

A corresponding network prefix for that roaming domain.

Note that additional home and roaming networks can be specified through the MMTel Determine International and Roaming Status feature configuration profile once setup is complete.

10

Play Announcement Questions

Media server URI [sip:mrf@mrfhost.example:5060] >

The URI of the Media Resource Function (MRF). The hostname part should either be a resolvable name or the IP address of the MRF.

11

Online Charging Questions

Online charging involves realtime communication with an external charging system, e.g. to an OCS via Diameter Ro
Enable online charging? [Y]/n > y

If the user enters y, then the installer prompts for online charging options when the user selects CAP-based online charging in step 5.

This install allows online charging using either Diameter Ro or CAP. Enter the type you want with "ro" or "cap".
Charging type [ro] >

The installer uses Diameter Ro by default if the user does NOT select CAP-based online charging in step 5.

This installation will use Diameter Ro for online charging.

If the user chooses Yes and ro, then the installer prompts for details of Diameter Ro and CCA Questions in next step. Or if the user chooses Yes and cap, then the installer prompts for details of CAP Charging Questions in step 15.

12

Diameter Ro and CCA Questions - if ro chosen at step 11

This value is placed into the Origin-Host AVP.
Host [diameterclient] >

The Diameter hostname for Sentinel VoLTE. It is used in the Origin-Host AVP of outgoing diameter messages.

The Diameter Ro release used for online charging can be configured to one of the following release versions: V8d0, V960, Va00, Vb80, Vcb0
Diameter Ro release [Vcb0] >

The Diameter release e.g (rel 12.11.0,Vcb0) used for online charging.

This installer allows setting up a simple configuration with a single peer for the OCS. If you need a configuration with multiple peers, you can either do so after the installation finishes by following the Diameter documentation, or editing the following file now:
[path-to-config-file]/DiameterConfig.xml
Do you want to set up a simple configuration? [Y]/n >

If yes, the installer will provide a series of prompts for setting up a basic diameter configuration (where there is a single OCS server); if no, you will need to manually configure diameter peers for the charging system.

Peer URI [aaa://diameterserver:3868;transport=tcp] >

URI of the online charging server.

Diameter peer address [diameterserver] >

Diameter address of the online charging server.

Realm name [example.com] >

Diameter Realm for the online charging system.

13

Diameter Rf

The Rf Control RA is used by interim CDR features to send accounting data to the CDF during offline charging interactions. Enabling this RA will implicitly enable interim CDRs.

Disabling the Rf Control RA will prevent interim CDR features from interacting with the CDF, but they may still be configured to write interim CDRs to disk.
Enable Rf Control RA? [Y]/n >
This value is placed into the Origin-Host AVP.
Host [diameterclient] >

The Diameter hostname for Sentinel VoLTE. It is used in the Origin-Host AVP of outgoing diameter messages.

The Diameter Rf release used for offline charging can be configured to one of the following release versions: V8d0, V960, Va00, Vb80, Vcb0
Diameter Rf release [Vcb0] >

The Diameter release e.g (rel 12.11.0,Vcb0) used for Rf.

This installer allows setting up a simple configuration with a single peer for the CDF. If you need a configuration with multiple peers, you can either do so after the installation finishes by following the Diameter documentation, or editing the following file now:
/home/user/akendall/repos/sentinel-volte/sentinel-volte-sdk/target/artifacts/sentinel-volte-sdk/deploy-volte/config/sentinel-rf-control-ra-deploy/rf-control-ra-config.yaml
Do you want to set up a simple configuration? [Y]/n >

If yes, the installer will provide a series of prompts for setting up a basic diameter configuration (where there is a single CDF); if no, you will need to manually configure diameter peers for the Rf system.

Peer URI [aaa://RfCDF:5898;transport=tcp] >

URI of the CDF.

This address is only necessary if the host in the peer URI specified above is not resolvable. If it is then you can just accept the default value here.
Peer address [RfCDF] >

Peer address of the CDF.

Realm name [opencloud] >

Realm of the CDF.

14

Call Detail Records (CDRs)

Enabling interim CDRs implicitly due to Rf Control RA being enabled

Session CDRs are written to disk only at the end of a session.
Enable session CDRs? y/[N] >

If Rf was not enabled in step 13 then an additional question will be asked regarding enabling Interim CDRs

15

CAP Charging (IM-SSF) - if cap chosen at step 11

Country code [65] >

The country code for the home network.

Default media server address [sip:mrf@mrfhost.example:5060]>

Address of the media server (MRF) to be used by the IM-SSF.

16

Sh Cache Diameter Questions

This value is placed into the Origin-Host AVP.
Host [diameterclient] >

The Diameter host for Sentinel VoLTE. It is used in the Origin-Host AVP of outgoing diameter messages.

This installer allows setting up a simple configuration with a single peer for the HSS. If you need a configuration with multiple peers, you can either do so after the installation finishes by following the Diameter documentation, or editing the following file now:
[path-to-config-file]/sh-cache-ra-config.yaml
Do you want to set up a simple configuration? [Y]/n >

If yes, the installer will provide a series of prompts for setting up a basic diameter configuration (where there is a single HSS server); if no, you will need to manually configure diameter peers for the HSS.

Peer URI [aaa://diameterserver:3888;transport=tcp] >

URI of the HSS.

This address is only necessary if the host in the peer URI specified above is not resolvable. If it is then you can just accept the default value here.
Peer address [diameterserver] >

Diameter address of the HSS.

Realm name [example.com] >

Diameter Realm for the HSS.

17

Sentinel Registrar Questions

The registrar allows configuration to be specific to a particular node, which may be necessary for some settings like
the ATU-STI. If a certain property is not found in a node-specific profile, or no profile exists for the current node,
the registrar will fall back on the standard profile. This installer will configure the standard profile and add a
node-specific profile for node 101. If you are using more than one node then you can edit the file
[path-to-config-file]/RegistrarConfigurationTable.yaml after finishing the configuration in the installer, but before
proceeding with the actual installation.

Destination realm [example.com] >

Diameter realm for the Home Subscriber Server (HSS)

ATU-STI [sip:localhost:5060] >

The Access Transfer Update - Session Transfer Identifier.

Registration Data Storage can use either the HSS, or a Cassandra database. Specify the type you want with either "HssCache" or "Cassandra".
Registration Data Storage type [HssCache] >

Determines where the registrar will store third party registration data. Data can be stored in either the HSS, or a Cassandra database.

Please enter a comma separated list of Cassandra hosts in the form "host1,host2"
Cassandra Hosts [localhost] >

Comma separated list of hostnames for the Cassandra database.

Please enter the port Cassandra is listening on
Cassandra Port [9042] >

The destination port for the Cassandra database server.

18

Sentinel VoLTE Shared Config Questions

Sentinel VoLTE shared configuration can be specific to a particular node, which may
be necessary for some settings like the MMTel and SCC AS URI's. If a certain property is not
found in a node-specific profile, or no profile exists for the current node, then Sentinel VoLTE
shared config will fall back on the standard profile. This installer will configure the standard
profile and add a node-specific profile for node 101. If you are using more than one node then you can edit the file
[path-to-config-file]/VoLTESharedConfigProfileTable.yaml
after finishing the configuration in the installer, but before proceeding with the actual installation.

MMTel AS URI [sip:mmtel@127.0.0.1:5060] >

The URI that identifies this MMTel AS

SCC AS URI [sip:scc@127.0.0.1:5060] >

The URI that identifies this SCC AS

19

External Session Tracking Questions

External Session Tracking uses Cassandra to save session information that can be shared across nodes.

Please enter a comma separated list of Cassandra hosts in the form "host1,host2"
Cassandra Hosts [localhost] >

Comma separated list of hostnames for the Cassandra database.

Please enter the port Cassandra is listening on
Cassandra Port [9042] >

The destination port for the Cassandra database server.

20

SIP SIS RA Questions

SIP SIS RA Host [localhost] >

The hostname for the server hosting Sentinel VoLTE.

21

MMTel Conferencing Questions

The URI of the Interrogating Call Session Control Function. The Conf and ECT features will automatically add an "lr" parameter to it. The hostname part should either be a resolvable name or the IP address of the I-CSCF.
Example: sip:127.0.0.1:5054;transport=tcp
I-CSCF URI [sip:icscf@icscfhost.example:5060] >

The URI of the Interrogating Call Session Control Function (I-CSCF).

The URI of the Media Resource Function. The hostname part should either be a resolvable name or the IP address of the MRF.
Example: sip:msml@127.0.0.1:5060
MRF URI [sip:mrf@mrfhost.example:5060] >

The URI of the Media Resource Function (MRF) to be used as the conference bridge.

Conference Factory PSI [sip:conf-factory@example.com] >

A Public Service Identifier that can be used by a subscriber to establish a conference call.

The Conference MSML Schema Vendor Name. Used by the Conf feature to determine mapper selection when creating MSML documents for interaction with the MRF.
Conference MSML Schema Vendor Name [Dialogic] >

The name of the vendor providing the conference MSML schema.

22

ODB Questions

Enable HSS IMS-ODB-Information query
====================================
The SubscriberDataLookupFromHss feature does NOT query the Operator Determined Barring information (IMS-ODB-Information) by default.
Enable HSS query for IMS-ODB-Information: y/[N]

Answering Yes will enable The Operator Determined Barring (ODB) by this option.

23

HLR Configuration

The following questions concern the HLR configuration. They are only asked if the user has chosen to use the HLR - a question asked near the beginning of the install.

The SCCP address of the HLR.
Example: type=C7,ri=pcssn,pc=6,ssn=143,national=false
HLR address [type=C7,ri=pcssn,pc=6,ssn=143,national=false] >
The SCCP address of the Sentinel VoLTE AS.
Example: type=C7,ri=gt,digits=653333333,gti=4,nature=international,numbering=isdn,tt=0,national=true
Originating Sentinel address [type=C7,ri=pcssn,pc=7,ssn=157] >
The address of the MLC (Sentinel).
Example: address=222,nature=INTERNATIONAL,numberingPlan=ISDN
MLC address [address=653333333,nature=INTERNATIONAL,numberingPlan=ISDN] >
The timeout value for opening the MAP dialog with the HLR (in milliseconds).
Invoke timeout [5000] >

24

T-ADS Questions

LTE (E-UTRAN) is an allowed PS access network technology. You can also configure WLAN to be an allowed access network.
Allow WLAN access? y/[N] >

Answering 'yes' will allow subscribers to use WiFi as an access network.

25

Review settings

Once all questions have been answered, the user is provided the opportunity to review and if happy, accept the settings. TIP: settings are saved to disk, so that they can be read later.

Review settings
***************


Basic SDK properties
====================

  sdk.component.vendor: Rocket Communications Inc
  sdk.component.version: 1.0
  sdk.platform.operator.name: Rocket
  sdk.ivy.org: rocket
  sdk.ivy.publish.revision: 1.0.0

... edited for brevity


MMTel Conferencing
==================

  I-CSCF URI: sip:192.168.10.1:5054;transport=tcp
  MRF URI: sip:192.168.10.17
  Conference Factory PSI: sip:conf-factory@example.com


Play Announcements
==================

  Media server URI: sip:annc@192.168.10.17:5060

Accept these values? [Y]/n > y

... edited for brevity

Configuration changes written.

If the user presses the n key then the questions are asked again. Note that the list of configuration files that have been modified are printed out by the configuration portion.

26

Execution phase

Now that the installer has gathered all necessary information it provides the user with the option to install the VoLTE TAS now.

Install now? [Y]/n >

If the user wants to install at a later time, they can press the n key. The installer exits having saved settings that the user has entered. I.e. the installer can be run later if desired.

Installing Rhino ... done.
Starting Rhino in the background ... done.
Publishing deployment module deploy-volte ... done.
Deploying; this is going to take a while ... done.
Binding; this is going to take a while ... done.
Configuring; this is going to take a while ... done.
Running post-installation tasks ... done.
Installation completed successfully in 32 minutes and 19 seconds. Rhino has been left running to finish applying configuration changes.

The configuration has been saved to the file {sdk-path}/install.properties. This file can be used to re-run the installation non-interactively with the same settings.

The installation has now completed successfully.
Important A properties file is automatically created when the interactive installer is run. This file is located in the sentinel-volte-sdk directory and named install.properties. In this way an interactive installations settings are saved, and can be distributed through the install.properties file. You can later use this file for a new installation using the Non-interactive mode. Save this file for future upgrade procedure as instructed here and here.

Non-interactive mode

To run the installer in non-interactive mode a properties file is passed to the installer program

testuser@machine$ cd ~/sentinel-volte/sentinel-volte-sdk
testuser@machine$ ./build/bin/installer -p my-install.properties

SIS and CGIN

During installation SIS and CGIN versions are extracted into the SDK directory structure. This is so that SIS can be configured as necessary.

The CGIN connectivity pack is extracted into the sentinel-volte-sdk/cgin/cgin-connectivity-full-CGIN_VERSION directory. The SIS is extracted into the sentinel-volte-sdk/sis/SIS_VERSION directory. Here CGIN_VERSION and SIS_VERSION are the release versions for each product respectively (e.g. 1.5.2.8 and 2.5.2.7)

The SIS console command is located at sentinel-volte-sdk/sis/SIS_VERSION/admin/sis-console.

Background information

The installer sits on top of the Sentinel VoLTE SDK infrastructure

The installer works by creation of a "deployment module" for Sentinel VoLTE. This module name is "deploy-volte" and it is located in the root of the Sentinel VoLTE SDK directory.

A deployment module can be created through the use of the sdkadm create-deployment-module command. The values that the user enters (or passes in when using non-interactive mode) are written into the various configuration files in this deployment module.

The deployment module is then published, and the deployer, binder and configurer are invoked in order to install/bind/configure the application in Rhino.

This means that the the installer is part of the Sentinel VoLTE SDK, and that there is no technology difference between the SDK and an "off the shelf install". Therefore custom configurations can easily be made through modification of the deployment module, and publishing it, and running the configurer.

Installer log files

The installer captures full logging from the various tools that it uses, and writes these logs into the sentinel-volte-sdk/build/target/log directory. This output is more verbose than the user sees when running the installer.

Each time an install is done, a file called install.log is created in this directory. If there is a previous install.log file, that it is moved to install_date.log. The value of "date" is the time of the last write timestamp in the file.

Therefore running the installer three times results in three installer log files.

Post-Installation Instructions

Update XCAP server

To configure the XCAP Server for Sentinel VoLTE, you can change the Diameter peer connection to the HSS and populate XCAP server settings and MMTel service data. You may optionally enable XCAP authentication using Sentinel AGW.

Diameter peer connection to the HSS

For the Diameter peer connection to the HSS, a file called VolteHssDiameterConfig.xml must be present in a folder called rem_home in Tomcat. If this folder does not exist, create it:

1

2

Change the values for the HSS hostname and port. There are two CDATA sections in the file which contain XML. They both need adjustment.

  • The first one has an element called peer which contains an element called uri.

    • This element has a hostname and port value which must be updated to be that of the HSS server.

    • Just below that is an element called address whose hostname also needs updating.

  • The second CDATA section contains two elements called hostname. These need the same adjustment as well.

Populate XCAP server settings and MMTel service data

There are several configuration pages in REM for XCAP connectivity and MMTel service data mappings that must be populated. This can either be done manually following the admin guide, or more easily using the script volte-sentinel-mappings-config. This file is located in the build/bin directory of the Sentinel VoLTE SDK.

This can be executed from your VoLTE TAS’s command line, provided the Java Runtime Environment (v 7+) is installed. The command must be given these arguments:

Mandatory Arguments What it specifies 
-u (--username)

Your Rhino Element Manager (REM) username.

 
-pw (--password)

Your Rhino Element Manager (REM) password.

 
-h (--hostname)

The hostname or IP address of your Rhino Element Manager (REM).

 
-p (--port)

The port of your Rhino Element Manager (REM).

 
-n (--network-operator)

The network operator name.

 
-r (--rhino-instance-id)

The Rhino Instance ID.

 
-dh (--hss-destination-host)

The destination host of the HSS.

 
-dr (--hss-destination-realm)

The destination realm of the HSS.

Optional Arguments

What it specifies

 
-x (--xcap-mapping)

Additional XCAP Simservs mappings.

Must be in the format -x "<simservsPath>;<mmtelPath>".

Can be specified multiple times. e.g. -x "<simservsPath1>;<mmtelPath1>" -x "<simservsPath2>;<mmtelPath2>"

Here is an example command:

cd ~/sentinel-volte/sentinel-volte-sdk
./build/bin/volte-sentinel-mappings-config -u emadm -pw password -h localhost -p 8080 -r Local -n OpenCloud -dh hss-instance -dr example.com -x "extensions/operator-flexible-alerting-group;complete-flexible-alerting/operator-flexible-alerting-group" -x "extensions/flexible-alerting-group-members;complete-flexible-alerting/operator-flexible-alerting-group/members"
Tip To see a listing of the required arguments, from the command line, execute the JAR file without any arguments.

Enable XCAP authentication using Sentinel AGW

By default the XCAP Server assumes that requests will be authenticated externally using an Authentication Proxy (AP). If this is the case, no further configuration is required.

If an AP is not suitable or available, the XCAP server can be configured to authenticate requests itself using OpenCloud Sentinel AGW. Sentinel AGW provides an implementation of 3GPP GAA (Generic Authentication Architecture) procedures.

For more information, and instructions on configuring the XCAP Server with Sentinel AGW, see the Sentinel AGW Guide.

OpenIMS HSS

If you’re using the OpenIMS HSS, you’ll need to specify the interface (IP address and port values) that it uses:

1

Edit the DiameterPeerHSS.xml file in the /path/to/HSS/FHoss/deploy directory.

2

Find the Acceptor XML element.

3

Change its binding to the desired IP address (or host name).

4

Change its port values to the desired port.

Create init.d scripts

There are two init.d scripts for Ubuntu Linux which make starting and stopping Rhino and REM easier (linked below):

  • rhino — for Rhino

  • rem — for REM running on Apache Tomcat

Note: These are illustrative and useful for Proof of concept rather than production environments.

To set these up:

1

Copy the script to the host server’s /etc/init.d/ folder:

sudo cp rhino /etc/init.d

2

Make the script executable:

sudo chmod +x /etc/init.d/rhino

3

Refresh, with the update-rc.d command:

sudo update-rc.d rhino defaults 99

Restart Rhino

Finally, restart Rhino by executing the following commands in a terminal, from the Rhino install directory.

./stop-rhino.sh --node 101
./start-rhino.sh
Tip If you chose to set up the Rhino init.d script, you can use these commands to stop and start it.

Init.d Sample Scripts for VoLTE

Note These sample scripts are illustrative init.d scripts for Rhino and REM

For production installations use production Rhino’s own init.d scripts rather than these.

Sample Rhino script

#!/bin/bash
#
# Manage the Rhino SLEE.
# Put this file in /etc/init.d and symlink that in /etc/rc?.d

RHINO_HOME=/home/ubuntu/sentinel-volte-sdk/rhino-sdk/RhinoSDK
RHINO_USER=ubuntu

case "$1" in
start)
	# This command will fail nicely if that file is not there, so
	#  checking for that file's existence is not necessary.
        echo "Starting the Rhino SLEE"
	sudo su - ${RHINO_USER} -c ${RHINO_HOME}/start-rhino.sh > /dev/null 2>&1 &
        # logs will be in ${RHINO_HOME}/work/log
	;;

stop)
        echo "Stopping the Rhino SLEE"
        [ -d ${RHINO_HOME} ] && [ -x ${RHINO_HOME}/stop-rhino.sh ] \
	    && ${RHINO_HOME}/stop-rhino.sh --nice
	;;

*)
	echo "Usage: $0 { start | stop }"
	exit 1
	;;
esac
exit 0

Sample REM script

#!/bin/sh
#
# Rhino Element Manager start/stop script.
#
#

# Location of the Rhino Element Manager
REM_HOME=/home/ubuntu/sentinel-volte-sdk/rhino-sdk/RhinoSDK/apache-tomcat-*
RHINO_USER=ubuntu

usage()
{
    echo "Usage: $0 {start|stop}"
    exit 1
}

#
# Main
#

# Parameter check

[ $# -gt 0 ] || usage

case "$1" in
  start)
        # Start REM
        sudo su - "$RHINO_USER" -c "$REM_HOME/bin/catalina.sh start"
        echo "REM Starting"

        ;;

  stop)
        # Stop REM
        sudo su - "$RHINO_USER" -c "$REM_HOME/bin/catalina.sh stop"
        echo "REM Stopping"
        ;;

  *)
        usage
        exit 2
        ;;

esac

exit 0

Sample VolteHssDiameterConfig XML for VoLTE

Note This sample script is for updating the XCAP server configuration when carrying out post install instructions for Sentinel VoLTE. 
<exported-profile-data table="VolteHssDiameterConfiguration">
    <attributes>
        <attribute-desc name="productVendorId" type="long" serialised="false"/>
        <attribute-desc name="applicationVendorId" type="long" serialised="false"/>
        <attribute-desc name="host" type="java.lang.String" serialised="false"/>
        <attribute-desc name="applicationId" type="long" serialised="false"/>
        <attribute-desc name="realm" type="java.lang.String" serialised="false"/>
        <attribute-desc name="peerTable" type="java.lang.String" serialised="false"/>
        <attribute-desc name="realmTable" type="java.lang.String" serialised="false"/>
        <attribute-desc name="product" type="java.lang.String" serialised="false"/>
        <attribute-desc name="version" type="int" serialised="false"/>
        <attribute-desc name="enableMultiNodeConfig" type="boolean" serialised="false"/>
        <attribute-desc name="nodeIDs" type="int[]" serialised="false"/>
        <attribute-desc name="perNodeHosts" type="java.lang.String[]" serialised="false"/>
        <attribute-desc name="perNodeListenAddresses" type="java.lang.String[]" serialised="false"/>
        <attribute-desc name="perNodePorts" type="int[]" serialised="false"/>
        <attribute-desc name="perNodeSecondaryAddresses" type="java.lang.String[]" serialised="false"/>
    </attributes>
    <profile name="xcapserver" action="create">
        <attribute-value name="productVendorId">19808</attribute-value>
        <attribute-value name="applicationVendorId">0</attribute-value>
        <attribute-value name="host">xcapserver</attribute-value>
        <attribute-value name="applicationId">0</attribute-value>
        <attribute-value name="realm">example</attribute-value>
        <attribute-value name="peerTable">
            <![CDATA[<?xml version="1.0" encoding="UTF-8"?>
                     <!DOCTYPE peer-table PUBLIC "-//Open Cloud Ltd.//DTD Diameter Peer Table Configuration 1.1.0//EN"
                     "http://www.opencloud.com/dtd/diameter-peer-table-1.1.0.dtd">
                     <peer-table>
                        <default-options>
                            <option>
                                <option-name>TCP_NODELAY</option-name>
                                <option-type>java.lang.Boolean</option-type>
                                <option-value>true</option-value>
                            </option>
                        </default-options>
                        <peer connectAtStartup="true">
                            <uri>aaa://hss-instance:3868;transport=tcp</uri>
                            <address>hss-instance</address>
                            <option>
                                <option-name>TCP_NODELAY</option-name>
                                <option-type>java.lang.Boolean</option-type>
                                <option-value>false</option-value>
                            </option>
                         </peer>
                     </peer-table>]]>
        </attribute-value>
        <attribute-value name="realmTable">
        <![CDATA[<?xml version="1.0" encoding="UTF-8"?>
                 <!DOCTYPE realm-table PUBLIC "-//Open Cloud Ltd.//DTD Diameter Realm Table Configuration 1.0//EN"
                 "http://www.opencloud.com/dtd/diameter-realm-table-1.0.dtd">
                 <realm-table>

                 <realm>
                    <realm-name>example.com</realm-name>
                    <application-route>
                        <application>
                            <application-id>4</application-id>
                            <vendor-id>0</vendor-id> <!-- optional, default is zero -->
                        </application>
                        <action>LOCAL</action>
                        <peer-ref>
                            <hostname>hss-instance</hostname>
                            <metric>1</metric>
                        </peer-ref>
                    </application-route>
                 </realm>

                 <default-route>
                    <peer-ref>
                        <hostname>hss-instance</hostname>
                        <metric>1</metric>
                    </peer-ref>
                 </default-route>

                 </realm-table>]]>
        </attribute-value>
        <attribute-value name="product">OpenCloud Diameter</attribute-value>
        <attribute-value name="version">1</attribute-value>
        <attribute-value name="enableMultiNodeConfig">false</attribute-value>
        <attribute-value name="nodeIDs" content-type="null"/>
        <attribute-value name="perNodeHosts" content-type="null"/>
        <attribute-value name="perNodeListenAddresses" content-type="null"/>
        <attribute-value name="perNodePorts" content-type="null"/>
        <attribute-value name="perNodeSecondaryAddresses" content-type="null"/>
    </profile>
</exported-profile-data>

Installing the Sentinel VoLTE Provisioning Module

The Sentinel VoLTE provisioning module is distributed as a Rhino Element Manager (REM) plugin.

It requires REM 1.5.0 or compatible. REM can be installed with Jetty or Apache Tomcat. For Sentinel VoLTE, the Apache Tomcat method is required.

To install the Sentinel VoLTE Provisioning module you will need:

Below are the procedures to:

Important
REM restart required

After installing and configuring the plugin, you will need to restart REM, for example by restarting the Tomcat webapp it is running in:

${CATALINA_BASE}/bin/catalina.sh stop
${CATALINA_BASE}/bin/catalina.sh start

Set up Tomcat

To set up Apache Tomcat for the Sentinel VoLTE Provisioning module:

1

Follow the instructions for running REM on Apache Tomcat in the REM Guide.

2

Create the rem_home/plugins directory.

cd apache-tomcat-<version>
mkdir -p rem_home/plugins

3

If running Apache Tomcat using Java 1.7, you will need to increase the PermGen size.

Add JAVA_OPTS to bin/setenv.sh.

JAVA_OPTS="-XX:PermSize=512m -XX:MaxPermSize=512m"

This step should be skipped if running Apache Tomcat on Java 1.8 or higher.

Install the REM plugin

To install the REM plugin for the Sentinel VoLTE Provisioning Module:

1

Copy volte-sentinel-element-manager-<version>.em.jar into rem_home/plugins.

cd apache-tomcat-<version>
cp /full/path/to/volte-sentinel-element-manager-<version>.em.jar rem_home/plugins/

2

(Optional) Copy sis-em-<version>.em.jar into rem_home/plugins.

cd apache-tomcat-<version>
cp /full/path/to/sis-em-<version>.em.jar rem_home/plugins/

Customize plugin logging

1

Unzip log4j2.properties from rem.war:

cd apache-tomcat-<version>
mkdir rem-tmp
cd rem-tmp
unzip ../webapps/rem.war WEB-INF/classes/log4j2.properties

2

Edit WEB-INF/classes/log4j2.properties with this content:

log4j.rootLogger=INFO, FILE, CONSOLE

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %-5p <%t> [%c] %m%n

log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=${rem.home}/rem.log
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p <%t> [%c] %m%n

log4j.logger.rem=INFO
log4j.logger.openjpa=INFO
log4j.logger.org.apache.wink=INFO

# Uncomment for subscriberdata cache eviction logging
#log4j.logger.rem.server.sentinel.subscriberdata.cache=TRACE

log4j.logger.sentinel.audit=INFO, AUDIT
log4j.additivity.sentinel.audit=false

log4j.appender.AUDIT=org.apache.log4j.FileAppender
log4j.appender.AUDIT.File=${rem.home}/sentinel-audit.log
log4j.appender.AUDIT.layout=org.apache.log4j.PatternLayout
log4j.appender.AUDIT.layout.ConversionPattern="%d{yyyy-MM-dd HH:mm:ss,SSS}", "%c{1}", %m%n

3

Replace WEB-INF/classes/log4j2.properties in rem.war:

zip ../webapps/rem.war WEB-INF/classes/log4j2.properties

4

Remove temporary files:

cd ..
rm -rf rem-tmp

Import Rhino trust certificate

This can also be done using the REM web UI.

1

Import a Rhino Trust Certificate into REM:

"${JAVA_HOME}/bin/keytool" -importcert -file ${RHINO_HOME}/rhino-trust.cert -keystore "${TOMCAT_HOME}/rem_home/rhino-ems.ks" -storepass changeit -noprompt

Security considerations

Below are recommendations for securely running the Sentinel VoLTE Provisioning Module.

Use https

Be aware that the Sentinel VoLTE machine API uses HTTP BASIC authentication. This passes the username and password with every request.

To prevent your credentials going over the network unencrypted, run REM over https.

Set up SSL

See the Tomcat 7 - SSL How-To docs for help setting up SSL in Apache Tomcat 7.

Virtualized Deployment Requirements

Sentinel VoLTE is supported in a virtualized environment, details presented here provide a guide to the scope of that support and how Sentinel VoLTE should be setup in that environment.

VMWare Supported

VMWare vSphere ESXi 5.1 and 6 is supported and certified. vCenter is not a mandatory requirement.

Operating System Support

Please refer to the Platforms section of the Rhino Compatibility Guide for supported operating systems.

Hyper-threading support

Hyper-threading is supported and used to maximize performance throughput.

Uncontended RAM Required

Sentinel VoLTE does make use of Uncontended RAM.

Uncontended disk I/O Required

Sentinel VoLTE does not require Uncontended disk I/O.

Dedicated Storage Array Required

Sentinel VoLTE does not require dedicated storage. CDR files and Rhino logs should be partitioned separately and managed to avoid failure or data loss due to space utilization.

CPU Contention Supported

CPU Contention is supported, however %ready numbers should be kept below 5% to avoid significant impact on overall application performance. It is strongly recommended that VMs are bound to physical CPU sockets to ensure predictable latency.

Fault Tolerance

A rhino cluster provides support for both high availability and fault tolerance internally. Sentinel VoLTE does not make use of the Rhino replication but does use the high availability systems. The cluster as a whole can tolerate failure of individual nodes with no support from the virtual machine. Live replication of virtual machines (FT Model) will interfere with Rhino’s internal clustering mechanisms.

VMWare Fault Tolerance

Sentinel VoLTE does not support VMWare Fault Tolerance.

VMWare vSphere High Availability

Sentinel VoLTE provides is own HA clustering based upon the Rhino SLEE Architecture.

VMWare vSphere App High Availability

Sentinel VoLTE does not support App High Availability.

VMWare vMotion

VMWare vMotion is not supported

VMWare vSphere Data Protection

Sentinel VoLTE supports Data Protection with the exception of RAM.

Stretched Clustering

Sentinel VoLTE supports Stretched Clustering.

VMWare VM Suspend/Resume

Sentinel VoLTE does not support Suspend/Resume.

VMWare VM Snapshots

Sentinel VoLTE does not support Snapshots.

VMWare VM Clone

Sentinel VoLTE does not support Cloning.

VMWare power management options supported

Sentinel VoLTE supports all power management.

VMWare clock synchronization

Sentinel VoLTE does not require clock synchronization.

SR-IOV

Sentinel VoLTE does not require SR-IOV.

Test Lab Minimum Virtual Host Requirements

1 vCPU, 8Gb RAM, 30Gb HD, 0 IOPS (Disk I/O is not normally a significant requirement as it’s not used except for logging and installation/configuration changes. Under normal operation a rhino node produces very little logging, but can use > 100Mb/s during severe error conditions under load).

Production Minimum Virtual Host Requirements

1 Rhino node per VM, 1 CPU (bound) @2.4+Ghz, 12Gb java heap, 30Gb HD, 0 IOPS. A quorum node is much lighter weight, and would require a vm with 1 vcpu, 512Mb ram, 0 IOPS.

System capacity/performance for each production system

1.08M BHCA, + 10.8K Conference attempts.

Scalability

Linear to 2.4Ghz, No scaling improvement over 2.4Ghz. (At Maximum load @ 2.4GHz, we reach saturation of Java CMS collector).

Virtual host resource changes while running

Sentinel VoLTE does not support host resource changes while running.

Virtual network interface requirements

VoLTE Sentinel requires 1 network interface for each mgmt/signalling interface.

Signalling bandwidth requirements

Sentinel VoLTE requires 500kbps/BHCA.

Latency added by signalling

Sentinel VoLTE adds 20ms at 50th percentile.

Features

This page presents summaries and links to more detailed descriptions of features installed with the Sentinel VoLTE product.

SIP features

The SIP features can be thought of as building blocks for any SIP-AS functionality, regardless of whether it is MMTel-AS, SCC-AS or any other SIP-AS.

General VoLTE features

The General VoLTE Features are used by both the MMTel-AS and SCC-AS functionality of the Sentinel VoLTE product. They can be thought of as building blocks for MMTel-AS and SCC-AS.

MMTel features

The MMTel Features implement MMTel-AS functionality.

SCC features

The SCC Features implement SCC-AS functionality.

Third Party Registration features

The Third Party Registration features implement the necessary Third Party Registration functionality for the MMTel-AS and SCC-AS.

External Session Tracking features

The External Session Tracking Features are used to track sessions in a cassandra database

CAMEL features

The CAMEL features can be thought of as building blocks for SCP functionality.

General features

The General Features are essentially utility features that are installed out-of-the-box.

The Sentinel VoLTE product does not use the Subscriber Data Lookup and Subscriber Validity features as the General VoLTE features are used instead. These features may be used when customising Sentinel VoLTE.

SIP features

The SIP Features are not specific to SCC or MMTel or even VoLTE installations. They are installed out-of-the-box with Sentinel VoLTE.

General VoLTE Features

These features are neither MMTel specific nor SCC specific.

Feature What it does

The set of features used for External Session Tracking in Cassandra

uses information from the incoming INVITE request to determine whether Ro Online charging should be applied to the session,

uses the Leg Manager to get the names of the original SIP legs established during call set up, and saves the values

uses information from an incoming INVITE, MESSAGE or SUBSCRIBE request, and from session state to set the plan ID in the Sentinel selection key

reads Third Party Registration information stored in the HSS as Transparent Data, and writes it into session state.

reads Third Party Registration information stored in the Cassandra Database, and writes it into session state.

is responsible for reading data from the HSS and writing it into Sentinel session state fields.

is responsible for reading data from the HSS and writing it into Sentinel session state variables fields.

is responsible for reading subscriber data from the HLR and writing it into Sentinel session state variable fields.

is responsible for building a Call Detail Record that reflects the actions taken whilst processing a session.

is a system feature which prevents SDP-change initiated CDRs from being written by the VolteInterimCdr feature for non-roaming Mobile Terminating calls.

is a system feature that is responsible for writing interim Call Detail Records throughout the session.

is responsible for building a Call Detail Record that reflects the actions taken whilst processing a session.

sets values for the Feature-Caps header on outgoing messages based on data from the session’s FeatureCapsManager

is responsible for reading subscriber location data from the HLR and writing it into Sentinel session state variable fields.

schedules configurable announcements to the subscriber based on indicators in OCS answers

External Session Tracking Features

The set of features for External Session Tracking. All of these features make use of the external session tracking Cassandra schema. For an overview of External Session Tracking refer to Session Tracking.

Feature What it does

creates the cassandra entries for external session tracking before the call is answered

deletes the cassandra entries for forked sessions once the dialog is confirmed

keeps entries updated in the external session tracking database

removes entries in the external session tracking database

updates session state when a session’s held status changes

performance testing results for SCC External Session Tracking

TrackSessionPreAnswer

This feature creates the cassandra entries for external session tracking before the call is answered .

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Any and All

Originating and Terminating

SCC_Post_SipAccess_PartyResponse

No

No

Stateless

POJO

Session input variables

Session State variable name Variable type Comments

ExternalSessionTrackingActive

boolean

Set by SCCDetermineExternalSessionTracking. If this is not true the feature will not execute

ExternalSessionTrackingKeys

Set<String>

The list of tracking keys to save the current session against

Session output variables

Session State variable name Variable type Comments

PreAlertingLegs

Set<String>

A list of legs that are in the Pre-Alerting state

AlertingLegs

Set<String>

A list of legs that are in the Alerting state

Statistics

TrackSessionPreAnswer statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → TrackSessionPreAnswer
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.TrackSessionPreAnswer"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
AddedTrackedDialog

Incremented when the feature adds a TrackedDialog insert statement to the cassandra batch query

 
AddedTrackedDialogKeys

Incremented when the feature adds a TrackedDialogKeys insert statement to the cassandra batch query

 
SentQueryToCassandra

Incremented when the feature executes an asynchronous query to cassandra

 
CassandraSuccess

Incremented when the feature receives a cassandra success result

 
CassandraError

Incremented when the feature receives a cassandra error result

 
CassandraTimeout

Incremented when the feature receives a cassandra timeout result

 
SavedDialogStatePartialDialog

Incremented when the feature receives the initial INVITE, and the partial dialog-ID is written to Cassandra

 
SavedDialogStatePreAlerting

Incremented when the feature receives a dialog-creating non-180 provisional response, and updates Cassandra

 
SavedDialogStateAlerting

Incremented when the feature receives the first 180 Ringing response, and updates Cassandra

 
SavedDialogStateActiveAwaitingAck

Incremented when the feature receives the 2xx response to the initial INVITE, and updates Cassandra

 
DeletedPartialDialog

Incremented when the full dialog-ID is known and the partial dialog entry is deleted from Cassandra

 
CassandraAsyncQueryTimeSuccess

Samples the elapsed time between starting a query and a success response arriving from Cassandra

 
CassandraAsyncQueryTimeFailure

Samples the elapsed time between starting a query and a failure response arriving from Cassandra

Behaviour

This feature runs on 18x responses to the initial INVITE, it saves information about the current session to the cassandra database. It writes the following:

Name Type Comments

Established Dialog Id

String

A normalised string that identifies the current session, in the form of '<call-id>;local-tag=<to-tag>;remote-tag=<from-tag>' for Originating calls, and '<call-id>;local-tag=<from-tag>;remote-tag=<to-tag>' for Terminating calls

State

DialogState (enum)

The current state of the session. Values are PreAlerting or Alerting

AS URI

String

The URI of the serving AS

Associated Dialog Id

String

A normalised sting that identifies the associated dialog for the current session, in the form of '<call-id>;local-tag=<from-tag>;remote-tag=<to-tag>' for Originating calls, and '<call-id>;local-tag=<to-tag>;remote-tag=<from-tag>' for Terminating calls

Tracking Keys

Set<String>

The set of tracking keys to save against the current session

TrackSessionClearForks

This feature deletes the cassandra entries for forked sessions once the dialog is confirmed .

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Any and All

Originating and Terminating

SCC_Pre_SipAccess_PartyResponse

No

No

Stateless

POJO

Session input variables

Session State variable name Variable type Comments

ExternalSessionTrackingActive

boolean

Set by SCCDetermineExternalSessionTracking. If this is not true the feature will not execute

Statistics

TrackSessionClearForks statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → TrackSessionClearForks
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.TrackSessionClearForks"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
DeletedTrackedDialog

Incremented when the feature adds a TrackedDialog delete statement to the cassandra batch query

 
DeletedTrackedDialogKeys

Incremented when the feature adds a TrackedDialogKeys delete statement to the cassandra batch query

 
SentQueryToCassandra

Incremented when the feature executes an asynchronous query to cassandra

 
CassandraSuccess

Incremented when the feature receives a cassandra success result

 
CassandraError

Incremented when the feature receives a cassandra error result

 
CassandraTimeout

Incremented when the feature receives a cassandra timeout result

 
CassandraAsyncQueryTimeSuccess

Samples the elapsed time between starting a query and a success response arriving from Cassandra

 
CassandraAsyncQueryTimeFailure

Samples the elapsed time between starting a query and a failure response arriving from Cassandra

Behaviour

This feature runs on final responses to the initial INVITE, it removes all forked entries from the database now that we have a single dialog confirmed with a final response. It uses a cassandra batch statement to send multiple 'DELETE' statements in a single asynchronous query.

TrackSessionRefresh

This feature keeps entries updated in the external session tracking database .

The external session tracking database entries for an access leg are set to expire automatically. To guard against expiring entries too soon, this feature periodically refreshes the entries when SIP activity is detected on the leg. This feature also updates the database entries when the session’s held status changes.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO or SBB Feature Other notes

SCC

Both Originating and Terminating

 
SIP Access PartyRequest,
SIP Mid Session Party Request,
SIP Mid Session Party Response,

None

None

Stateful

POJO

Sets a session output variable.

Prerequisite features

Session input and output variables

Session input variables

Session State variable name Type Comments 
ExternalSessionTrackingActive

Boolean

Set by the SCCDetermineExternalSessionTracking feature

 
ASURI

String

Set by the SCCDetermineSessionType feature

 
ExternalSessionTrackingKeys

Set<String>

Set by the SCCDetermineExternalSessionTracking feature

 
AccessLegMediaFeatureTags

Set<String>

Set by the SCCBindEnhancedSRVCC or TrackSessionPreAnswer features

 
HeldStatusChanged

Boolean

Set by the DetectHoldResume feature, triggers a database update if true

 
LastHeldTime

Long

Set by the DetectHoldResume feature

 
SessionIsHeld

Boolean

Set by the DetectHoldResume feature

Session output variables

Session State variable name Type Comments 
LastTrackSessionRefreshTime

Long

The time at which the last successful refresh was performed

 
TrackedSessionDialogID

String

The dialog ID (in Target-Dialog format) of the access leg session being tracked

Statistics

TrackSessionRefresh statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → TrackSessionRefresh
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.TrackSessionRefresh"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
TrackedDialogRefreshStarted

Incremented when the feature starts a TrackedDialog Cassandra refresh

 
TrackedDialogRefreshSuccess

Incremented when a TrackedDialog refresh returns successfully from Cassandra

 
TrackedDialogRefreshError

Incremented when a TrackedDialog refresh fails with a Cassandra error

 
TrackedDialogRefreshTimeout

Incremented when a TrackedDialog refresh fails with a Cassandra timeout

 
CassandraAsyncQueryTimeSuccess

Samples the elapsed time between starting a query and a success response arriving from Cassandra

 
CassandraAsyncQueryTimeFailure

Samples the elapsed time between starting a query and a failure response arriving from Cassandra

Behaviour

The TrackSessionRefresh feature keeps entries updated in the Cassandra external session tracking table. These entries are added with a Time-To-Live (TTL), so will automatically expire at some point, ensuring the table does not fill up with out of date sessions. This feature ensures the Cassandra TTLs are refreshed on access leg sessions that are still active, so they don’t expire too soon.

In addition, the feature also updates the tracked session entries when the call’s held status changes. See Hold and resume procedures below.

The feature only runs when the session state variable ExternalSessionTrackingActive is true, as determined by the SCCDetermineExternalSessionTracking feature.

Determining the Cassandra TTL to use

The Cassandra TTL for tracked sessions is derived from the SessionRefresh feature’s configuration. The SessionRefresh feature’s RefreshPeriod parameter specifies the time (in seconds) after which feature will send a session refresh request (re-INVITE) to keep the session open. So a request will be sent on the session at least this often.

The TrackSessionRefresh feature uses the value RefreshPeriod ✕ 1.5 as the Cassandra TTL.

Call setup procedures

The feature is first triggered by the initial ACK request during call setup (originating and terminating), at the SipAccess_PartyRequest execution point. It updates the tracked dialog entries (created by TrackSessionPreAnswer) with state=ACTIVE and a new TTL. The LastTrackSessionRefreshTime and TrackedSessionDialogID session state variables are set at this point.

Mid-call procedures

The feature is triggered on the SipMidSession_PartyRequest and SipMidSession_PartyResponse execution points. However no action will be performed if the tracked session database entries have been refreshed recently, to avoid unnecessary database queries.

To determine if a refresh is necessary, the feature calculates how much time has passed since LastTrackSessionRefreshTime. If the elapsed time is more than halfway through the TTL period, or within 60s of the TTL expiry time, then a refresh is initiated.

The refresh operation reads the access leg’s entry in the trackeddialog table, then updates this entry and any related trackeddialogkeys entries with a new TTL, but otherwise unchanged.

Hold and resume procedures

If the DetectHoldResume feature indicates that the call’s held status has changed, this triggers an immediate refresh of the tracked session entries. The TrackSessionRefresh feature checks if the HeldStatusChanged flag is set in session state, and if so, updates the tracked session entries with the current held status.

End-of-call procedures

The feature takes no action at the end of the call. A separate feature, DeleteTrackedSession, runs at the SipEndSession execution point to remove the database entries. If this feature was not triggered for any reason, the entries would expire naturally at the end of the TTL period.

DeleteTrackedSession

This feature removes entries in the external session tracking database at the end of a session.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO or SBB Feature Other notes

SCC

Both Originating and Terminating

 
SIP End Session

None

None

Stateless

POJO

Prerequisite features

Session input and output variables

Session input variables

Session State variable name Type Comments 
ExternalSessionTrackingActive

Boolean

Set by the SCCDetermineExternalSessionTracking feature

 
TrackedSessionDialogID

String

Set by the TrackSessionRefresh

Session output variables

None.

Statistics

DeleteTrackedSession statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → DeleteTrackedSession
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.DeleteTrackedSession"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
TrackedDialogDeleteStarted

Incremented when the feature starts a TrackedDialog Cassandra delete

 
TrackedDialogDeleteSuccess

Incremented when a TrackedDialog delete returns successfully from Cassandra

 
TrackedDialogDeleteError

Incremented when a TrackedDialog delete fails with a Cassandra error

 
TrackedDialogDeleteTimeout

Incremented when a TrackedDialog delete fails with a timeout

 
CassandraAsyncQueryTimeSuccess

Samples the elapsed time between starting a query and a success response arriving from Cassandra

 
CassandraAsyncQueryTimeFailure

Samples the elapsed time between starting a query and a failure response arriving from Cassandra

Behaviour

The DeleteTrackedSession feature runs at the SipEndSession execution point, and removes any tracked session database entries for the access leg.

The feature looks up the access leg’s trackeddialog entry using the dialog ID from the TrackedSessionDialogID session state variable. If found, the trackeddialog and all related trackeddialogkeys entries are removed.

The feature only runs when the session state variable ExternalSessionTrackingActive is true, as determined by the SCCDetermineExternalSessionTracking feature.

DetectHoldResume

This feature updates session state when a session’s held status changes .

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO or SBB Feature Other notes

SCC

Both Originating and Terminating

 
SIP Mid Session Party Request,
SIP Mid Session Party Response

None

None

Stateless

POJO

Session input and output variables

Session input variables

None.

Session output variables

Session State variable name Type Comments 
HeldStatusChanged

Boolean

Indicates that the current message has changed the held status of the session.

 
SessionIsHeld

Boolean

Indicates whether the session is currently on hold.

 
LastActiveTime

Long

The time that the session last changed from held to active.

 
LastHeldTime

Long

The time that the session last changed from active to held.

Statistics

DetectHoldResume statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → DetectHoldResume
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.DetectHoldResume"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
DetectSessionHold

Incremented when the feature detects a transition from active to held

 
DetectSessionResume

Incremented when the feature detects a transition from held to active

Behaviour

The DetectHoldResume feature updates session state when the session’s held status changes.

The feature runs on the SIP Mid-Session Party Request and SIP Mid-Session Party Response execution points. If a message containing an SDP offer arrives, the SDP is compared to the session’s previous SDP.

The feature looks for changes in directionality attribute in the session description, for example a=sendrecv or a=sendonly, to determine if the session is being put on hold or resumed. If the held status has changed, session state is updated with the new held status.

External Session Tracking Cassandra Schema

Overview

External session tracking saves all of the relevant information to track a session across multiple nodes. It saves the information in a Cassandra database. For an architectural view please refer to Session Tracking.

For further information related to use of Cassandra for production purposes please refer to Cassandra Database Configuration.

Data Schema

Cassandra’s tables exist in a 'keyspace', which, for illustrative purposes, can be thought of as a 'database' in SQL implementations. Creating a keyspace is simple, but some considerations are present.

  • The keyspace must be named opencloud_external_session_tracking

  • For a production environment, and for non-functional testing prior to production, the keyspace can be created such that it is replicated. A sample CQL command for creating such a keyspace is:

CREATE KEYSPACE opencloud_external_session_tracking WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 3 };

  • When developing features using the SDK against Cassandra, replication may not be necessary. A sample CQL command for creating such a keyspace is:

CREATE KEYSPACE opencloud_external_session_tracking WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 1 };

Once a keyspace is created, the required tables can be created. The following CQL statements provide both the structure and insight into the tables that are required.

USE opencloud_external_session_tracking;

//This table contains tracked dialogs
//tracked dialogs may be found by establisheddialogid
//there is one row for each tracked dialog
CREATE TABLE trackeddialog(
    establisheddialogid text,           //The established dialog ID, in form of Target-Dialog header value
                                        //e.g. fa77as7dad8-sd98ajzz@host.example.com;local-tag=kkaz-;remote-tag=6544

    state text,                         //The state of the call. One of:
                                        //"PARTIAL_DIALOG", "PRE_ALERTING", "ALERTING", "ACTIVE", or "HELD"

    asuri text,                         //The SIP URI of the tracking AS.
                                        //e.g In SCC, the SCC-AS URI of the signalling anchor for this dialog

    lastactivetime timestamp,           //The last time the call moved into state "active"
    lastheldtime timestamp,             //The last time the call moved into state "held"
    committedsdp text,                  //The committed SDP for this dialog
    committedsdptimestamp timestamp,    //The time that the SDP was committed
    associateddialogid text,            //The associated dialog ID, e.g. in a routing B2BUA this should be set to the
                                        //the other dialog ID

    mediafeaturetags set<text>,         //The UE's media feature tags received in the initial INVITE (originating)
                                        //or in the dialog-creating response (terminating)

    primary key(establisheddialogid)
);

//This table provides a mapping from a trackingkey to the established dialog IDs for that tracking key
//I.e. one tracking key may track multiple dialogs
CREATE TABLE trackeddialogkeys(
    trackingkey text,                   //A tracking key for the tracked dialog
                                        // example 1: cmsisdn=16505550425
                                        // example 2: impu=sip:+16505550386@example.com;user=phone
                                        // example 3: +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
                                        // example 4: impi=john.doe@example.com

    establisheddialogid text,           //The established dialog ID, in form of Target-Dialog header value
                                        //e.g. fa77as7dad8-sd98ajzz@host.example.com;local-tag=kkaz-;remote-tag=6544

    state text,                         //The state of the call. One of:
                                        //"PARTIAL_DIALOG", "PRE_ALERTING", "ALERTING", "ACTIVE", or "HELD"

    asuri text,                         //The SIP URI of the tracking AS
                                        //e.g. in SCC, the SCC-AS URI of the signalling anchor for this dialog

    lastactivetime timestamp,           //The last time the call moved into state "active"
    lastheldtime timestamp,             //The last time the call moved into state "held"
    committedsdp text,                  //The committed SDP for this dialog
    committedsdptimestamp timestamp,    //The time that the SDP was committed
    associateddialogid text,            //The associated dialog ID, e.g. in a routing B2BUA this should be set to the
                                        //the other dialog ID

    mediafeaturetags set<text>,         //The UE's media feature tags received in the initial INVITE (originating)
                                        //or in the dialog-creating response (terminating)

    primary key(trackingkey,establisheddialogid)
);

|NOTE Setting the tombstone deletion strategy to a shorter interval than the default is strongly recommended for third-party registration tables. The default interval causes increased load on the Cassandra servers during compaction, and particularly during recovery after failover. 1 hour is sufficient for proper management of registration and session data.

External Session Tracking Performance

Overview

This page details performance testing results for SCC External Session Tracking . The cassandra database activity involved in session tracking results in an increase in CPU usage for the Rhino host.

Two scenarios - SCC Simple and SCC Provisional - were both run twice with session tracking (SRVCC) enabled or disabled to demonstrate the change in CPU usage.

Software used

  • Rhino: 2.5.0.2

  • VoLTE: 2.6.0.8

  • Cassandra: 2.1.17

Test Parameters

Each test was run at 100sps for 1 hour

Cassandra Activity

Test Cassandra Record Created

SCC Simple - No SRVCC

None

SCC Simple - With SRVCC

SCC Provisional - No SRVCC

None

SCC Provisional - With SRVCC

External Session Tracking Performance Scenarios

Test Scenarios

SCC-Simple - No SRVCC

This scenario mimics a simple SCC call. SRVCC is disabled, so no external session tracking occurs.

scc orig simple no srvcc

SCC-Simple - With SRVCC

This scenario is identical to SCC-Simple - No SRVCC, except SRVCC is enabled, so external session tracking occurs when the call set-up is complete (message 7).

scc orig simple

SCC-Provisional - No SRVCC

This scenario mimics a SCC call with provisional responses. SRVCC is disabled, so no external session tracking occurs.

scc orig with provisional no srvcc

SCC-Provisional - With SRVCC

This scenario is identical to SCC-Provisional - No SRVCC, except SRVCC is enabled, so external session tracking occurs twice; firstly when the 183 is received (Message 5/6) and again when the call set-up is complete (message 23).

scc orig with provisional srvcc

External Session Tracking Performance Results

Scenario Results

CPU Usage

Test Average CPU usage

SCC Simple - No SRVCC

190%

SCC Simple - With SRVCC

240%

SCC Provisional - No SRVCC

310%

SCC Provisional - With SRVCC

380%

SCC Simple - No SRVCC

Test Results

Rhino CPU

rhino cluster 101 cpu

Rhino Heap

rhino cluster 101 heap

Rhino Activities

rhino cluster 101 stats activities

SCSCF A Rate

scscfA sim 1 rate

SCSCF B Rate

scscfB sim 1 rate

SCSCF Latency

scscfA sim 1 scc orig simple no srvcc latency

SCSCF Latency Over Time

scscfA sim 1 scc orig simple no srvcc latency over time

SCC Simple - With SRVCC

Test Results

Rhino CPU

rhino cluster 101 cpu

Rhino Heap

rhino cluster 101 heap

Rhino Activities

rhino cluster 101 stats activities

SCSCF A Rate

scscfA sim 1 rate

SCSCF B Rate

scscfB sim 1 rate

SCSCF Latency

scscfA sim 1 scc orig simple latency

SCSCF Latency Over Time

scscfA sim 1 scc orig simple latency over time

SCC Provisional - No SRVCC

Test Results

Rhino CPU

rhino cluster 101 cpu

Rhino Heap

rhino cluster 101 heap

Rhino Activities

rhino cluster 101 stats activities

SCSCF A Rate

scscfA sim 1 rate

SCSCF B Rate

scscfB sim 1 rate

SCSCF Latency

scscfA sim 1 scc orig with provisional no srvcc latency

SCSCF Latency Over Time

scscfA sim 1 scc orig with provisional no srvcc latency over time

SCC Provisional - With SRVCC

Test Results

Rhino CPU

rhino cluster 101 cpu

Rhino Heap

rhino cluster 101 heap

Rhino Activities

rhino cluster 101 stats activities

SCSCF A Rate

scscfA sim 1 rate

SCSCF B Rate

scscfB sim 1 rate

SCSCF Latency

scscfA sim 1 scc orig with provisional srvcc latency

SCSCF Latency Over Time

scscfA sim 1 scc orig with provisional srvcc latency over time

DetermineChargeMode

This feature uses information from the incoming INVITE request to determine whether Ro Online charging should be applied to the session, by setting the MonitorCallOnly session state variable. The MonitorCallOnly variable affects whether Sentinel VoLTE should perform online charging through Diameter Ro, or only monitor the call. Online Charging through CAP is handled by a separate service composition, see Service Compositions for more details about this.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Any and All

Originating and Terminating

SIPAccess_SessionAccept

No

No

Stateless

POJO

Session output variables

Session State variable name Variable type Comments 
MonitorCallOnly

boolean

True if the feature finds the Route Header “oc-charge-mode” Parameter set to cap or offline.

 
ChargeMode

ChargeMode (enum)

The charge mode determined by the feature.

Statistics

DetermineChargeMode statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → DetermineChargeMode
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.DetermineChargeMode"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
MonitorOnly

Incremented when the feature has set the MonitorCallOnly Session State field to true

 
NonMonitorOnly

Incremented when the feature has set the MonitorCallOnly Session State field to false

 
Error

Incremented when the feature was unable to determine the charge mode

Behaviour

This feature checks information from the incoming SIP request in order to set a Session State variable which affects Sentinel VoLTE’s charging behaviour.

Values examined

Value Name Source Notes

Route Header “oc-charge-mode” Parameter

Incoming SIP request

This is a custom parameter on the URI of the top-most route header. It is expected that this will be added by the S-CSCF based on iFCs.

Charge mode selection circumstances

Route Header “oc-charge-mode” Parameter Resulting Charging behaviour

oc-charge-mode=ro

MonitorCallOnly set to false, Diameter Ro charging will be applied, ChargeMode set to RO

oc-charge-mode=cap

MonitorCallOnly set to true, Diameter Ro charging will not be applied, ChargeMode set to CAP

oc-charge-mode=offline

MonitorCallOnly set to true, Diameter Ro charging will not be applied, ChargeMode set to OFFLINE

oc-charge-mode has any other value

MonitorCallOnly set to false, Diameter Ro charging will be applied, ChargeMode set to DEFAULT

oc-charge-mode parameter absent

MonitorCallOnly set to false, Diameter Ro charging will be applied, ChargeMode set to DEFAULT

DetermineInitialLegNames

This feature uses the Leg Manager to get the names of the original SIP legs established during call set up, and saves the values to a set of session state fields that may be used by other VoLTE features when they need to access a specific leg by name.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Both or either of MMTEL or SCC

Originating and Terminating

SIPAccess_*PreCreditCheck AND SIPAccess_PartyResponse

No

No

Stateless

POJO

Prerequisite features

These features must run before DetermineInitialLegNames:

  • DetermineCallType

Session input and output variables

Session input variables

Session state variable name Variable type 
CallType

Enum

Session output variables

Session state variable name Variable type Comments 
CurrentLocalLegName

String

The name of the leg towards the local UE (that is, the calling party on an originating instance, or the called party on a terminating instance)

 
CurrentRemoteLegName

String

The name of the leg towards the remote UE (that is, the called party on an originating instance, or the calling party on a terminating instance)

 
CurrentCallingLegName

String

The name of the leg towards the calling party

 
CurrentCalledLegName

String

The name of the leg towards the called party

Statistics

DetermineInitialLegNames statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set: SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB.

Name Description 
DetermineInitialLegNamesFeatureStarted

Incremented each time the feature runs

 
DetermineInitialLegNamesFeatureFailedToStart

Incremented when sentinel VoLTE encounters an error while attempting to start the feature

 
DetermineInitialLegNamesFeatureIssuedWarning

Incremented when a non-fatal problem is encountered and the feature and issues a warning

 
DetermineInitialLegNamesFeatureFailedDuringExecution

Incremented when a fatal problem is encountered and the feature cannot execute correctly

 
DetermineInitialLegNamesFeatureTimedOut

Incremented when the feature takes too long to complete and Sentinel VoLTE aborts execution

 
DetermineInitialLegNamesFeatureCallingLegNameSet

Incremented when calling leg name is found

 
DetermineInitialLegNamesFeatureCalledLegNameSet

Incremented when called leg name is found

Behaviour

Network pre-credit check

When invoked at the SipAccess_NetworkPreCreditCheck execution point the feature will do the following:

  • Retrieve the leg that the initial INVITE arrived on and get its name.

  • Set the CurrentCallingLegName session variable to the leg’s name.

  • On an originating instance, set the CurrentLocalLegName session variable to the leg’s name;
    on a terminating instance, set the CurrentRemoteLegName session variable to the leg’s name.

SIP access party response

When invoked at the SipAccess_PartyResponse execution point the feature will do the following:

  • Retrieve the leg that the response arrived on and get its name.

  • Verify that the response is to an INVITE and has a 2XX status. (If it isn’t, the feature will stop here.)

  • Set the CurrentCalledLegName session variable to the leg’s name.

  • On an originating instance, set the CurrentRemoteLegName session variable to the leg’s name;
    on a terminating instance, set the CurrentLocalLegName session variable to the leg’s name.

DetermineRoamingFromHlr

DetermineRoamingFromHlr is responsible for reading subscriber location data from the HLR and writing it into Sentinel session state variable fields.

The data it reads from the HLR is accessed through the AnyTimeInterrogation MAP operation. The Application Context used is anyTimeInfoEnquiryContext_v3_ac

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

Both or either of MMTEL or SCC.

Originating, Forwarding, and Terminating

SipAccess_SessionCheck

Yes

Yes

Stateless

POJO

Prerequisite features

  • SubscriberDetermination

  • FetchCMSISDN

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-determine-roaming-from-hlr module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-hlr-module opencloud#volte-determine-roaming-from-hlr#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new module; once completed the original source for the feature can be found in the new module.

The module-pack consists of a single module, volte-determine-roaming-from-hlr, containing the feature’s code. It does rely on the volte-map-event-handler which contains the shared event handler for MAP features and also publishes a module pack, however the event handler will not require modification unless a new feature name is introduced.

Session state input variables

Attribute Name Type 
Subscriber

String

 
CMISDN

String

Session state output variables

Attribute Name Type 
Description

RoamingStatus

 
Enum

UNKNOWN, NATIONAL or INTERNATIONAL

 
RoamingIndicator

boolean

Note: The default values for both RoamingStatus and RoamingIndicator are UNKNOWN and false respectively. If this feature is unable to determine the roaming status for any reason, it will leave the pre-set values.

Configuration

The feature uses configuration data from both the HLR CGIN MAP Configuration and SIP Sentinel Configuration.

Statistics

DetermineRoamingFromHlr statistics are tracked by the DetermineRoamingFromHlr feature and can be found under the following parameter set:
SLEE-Usage ▶ volte.sentinel.sip service ID ▶ volte.sentinel.sip SBB ID ▶ DetermineRoamingFromHlr.

Name Type Description 
Started

Counter

Incremented each time the feature runs

 
FailedToStart

Counter

Incremented when sentinel VoLTE encounters an error while attempting to start the feature

 
IssuedWarning

Counter

Incremented when a non-fatal problem is encountered and the feature issues a warning

 
FailedDuringExecution

Counter

Incremented when a fatal problem is encountered and the feature cannot execute correctly

 
TimedOut

Counter

Incremented when the feature takes too long to complete and Sentinel VoLTE aborts execution

 
RequestSent

Counter

Incremented when the feature receives subscriber data from the HLR

 
RequestSuccessful

Counter

Incremented after the feature successfully processes the data it received, and loads it into session state fields

 
RequestFailed

Counter

Incremented when absent configuration data prevents the feature from running

 
ResponseLatency

Sampled

Records elapsed time between sending the request to the HLR and getting a response (in milliseconds).

 
InternationalRoaming

Counter

Incremented when the feature determines that the subscriber is roaming internationally

 
NotRoaming

Counter

Incremented when the feature determines that the subscriber is not roaming

 
NationalRoaming

Counter

Incremented when the feature determines that the subscriber is national roaming

 
RoamingDataMissingFromHlrResponse

Counter

Incremented whenever an ATI result comes back from Hlr with missing or invalid location information

 
DialogOpenRefuseEvent

Counter

Incremented whenever the ATI fails due to a dialog open refuse

 
DialogUserAbortEvent

Counter

Incremented whenever the ATI fails due to a dialog user abort

 
DialogProviderAbortEvent

Counter

Incremented whenever the ATI fails due to a dialog provider abort

 
OperationErrorEvent

Counter

Incremented whenever the ATI fails due to an operation error

Behaviour

This feature uses the CGIN MAP RA to query the HLR with an ATI for subscriber location information.

Each time the feature is invoked, it checks the call type and determines the subscriber number that it should use to query the HLR.

The feature attempts to extract "phone number digits" from the CMSISDN session state field set by FetchCMSISDN, and if it cannot, from the Subscriber field set by SubscriberDetermination. If the feature cannot form a MSISDN it raises a Feature Error and finishes execution.

The feature then requests subscriber location info by sending a AnyTimeInterrogation request to the configured HLR.

In order to form the ATI request the feature:

  1. sets the GSM SCF address to the SentinelSCCPAddress configuration value

  2. sets the destination SCCP address to the HlrSCCPAddress configuration value

  3. sets the RequestedInfo indicator field to request Location Information

If a successful result is received, it retrieves location information from the ATI result. The location information can be in either of the CellGlobalIdOrServiceAreaIdFixedLength or LaiFixedLength fields. If neither field is present, the feature increments the RoamingDataMissingFromHlrResponse stat and finishes.

If the location information is found, the MCC and MNC are compared against the configured home network information to determine whether the subscriber is roaming or not. The RoamingStatus and RoamingIndicator session state fields are then set accordingly. Their default values in the case of incomplete information or feature failure are UNKNOWN and false respectively.

DetermineVoltePlanId

This feature uses information from an incoming INVITE, MESSAGE or SUBSCRIBE request, and from session state to set the plan ID in the Sentinel selection key . The plan ID affects which features will run for the call on the current AS instance. It also will set some Session State fields.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Any and All

Originating and Terminating

SIPAccess_SessionAccept, SubscriptionAccept, SipTransaction_Accept

Yes

No

Stateless

POJO

Prerequisite features

These features must run before DetermineVoltePlanId:

  • DetermineCallType

  • SCCDetermineSessionType (Only required on SCC AS)

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-determine-plan-id module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-planid-module opencloud#volte-determine-plan-id#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

volte-determine-plan-id

Contains all of the code for this feature.

Session input variables

Session State variable name Variable type 
CallType

Enum

 
SCCSessionType

Enum

 
SentinelSelectionKey

SentinelSelectionKey

Session output variables

Session State variable name Variable type Comments 
SentinelSelectionKey

SentinelSelectionKey

Updated by the feature based on factors described in the Behaviour section.

 
RequestIsForMmtelTransfer

Boolean

Set to true if request is targeted at configured Session-Transfer-To-Own-Device special URI.

Network operator data

This feature reads part of the feature configuration profile table for MMTel Conference to determine the PSI for the conferencing service.

Parameter Type Description Default 
ConfFactoryPSI

String

SIP or TEL URI for conferencing service PSI

none

 
MmtelTransferNumber

String

SIP or TEL URI for special Session-Transfer-To-Own-Device

none

Statistics

DetermineVoltePlanId statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → DetermineVoltePlanId
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.DetermineVoltePlanId"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
NoPlanSelected

Incremented when the feature fails to select an appropriate plan ID

 
MmtelOriginatingPlanSelected

Incremented when the feature selects the plan ID as “mmtel-orig”

 
MmtelTerminatingPlanSelected

Incremented when the feature selects the plan ID as “mmtel-term”

 
MmtelConferencingPlanSelected

Incremented when the feature selects the plan ID as “mmtel-conf”

 
SccOriginatingPlanSelected

Incremented when the feature selects the plan ID as “scc-orig”

 
SccTerminatingPlanSelected

Incremented when the feature selects the plan ID as “scc-term”

 
SccTerminatingTadsOnlyPlanSelected

Incremented when the feature selects the plan ID as “scc-term-tads”

 
SccTerminatingAnchorOnlyPlanSelected

Incremented when the feature selects the plan ID as “scc-term-anchor”

 
SccReoriginationPlanSelected

Incremented when the feature selects the plan ID as “scc-reorigination”

 
SccAccessTransferPlanSelected

Incremented when the feature selects the plan ID as “scc-access-transfer”

 
ConferenceConfigurationNotFound

Incremented when the feature is unable to find a valid conference PSI from configuration profiles

Behaviour

This feature checks a series of values from session state, feature configuration, and the incoming SIP request in order to select the appropriate session plan to run, and possibly set some Session State fields.

Values examined

Value Name Source Notes

Custom Route Header oc-mode Parameters

Incoming SIP request

These are custom parameters on the URI of the top-most route header. It is expected that these will be added by the S-CSCF based on iFCs.

SCCSessionType

Session State

This is set by the SCCDetermineSessionType feature when it detects the incoming request is for Access Transfer or Reorigination, as these requests do not come from the S-CSCF there should never be a oc-mode parameter on the route header.

Call Type

Session State

Set by the DetermineCallType feature.

Request URI

Incoming SIP request

Matched against the configured conference PSI to determine when a conference call is being requested.

Custom Route Header Parameters

Sentinel VoLTE supports specific custom headers and header parameters to indicate or propagate certain conditions between nodes in the network.

Plan ID selection circumstances

Route Header oc-mode Parameter SCCSessionType Call Type SIP Request-URI Matches Conference PSI Resulting Plan ID

(Not Present)

Access Transfer

(Ignored)

(Ignored)

scc-access-transfer

(Not Present)

Reorigination

(Ignored)

(Ignored)

scc-reorigination

oc-mode=mmtel

(Ignored)

Originating

(Ignored)

mmtel-orig

oc-mode=mmtel

(Ignored)

Terminating

No

mmtel-term

oc-mode=mmtel

(Ignored)

Terminating

Yes

mmtel-conf

oc-mode=scc

(Ignored)

Originating

(Ignored)

scc-orig

oc-mode=scc

(Ignored)

Terminating

(Ignored)

scc-term

oc-mode=scc-tads

(Ignored)

Terminating

(Ignored)

scc-term-tads

oc-mode=scc-anchor

(Ignored)

Terminating

(Ignored)

scc-term-anchor
Note
If Then …​

The route header oc-mode parameter is not present

and

the SCCSessionType is not ‘Access Transfer’ or ‘Reorigination’

The feature will proceed as if the route header oc-mode parameter was set to ‘mmtel’.

FeatureCapsManagement

This feature sets values for the Feature-Caps header on outgoing messages based on data from the session’s FeatureCapsManager

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

SCC

Originating and Terminating

SipAccess_SubscriberCheck, SipAccess_PartyRequest, SipAccess_PartyResponse, SipAccess_ServiceTimer, SipInstructionExecutionFailure, SipMidSession_PartyRequest, SipMidSession_PartyResponse, SipEndSession

No

No

Stateless

POJO

Session input variables

Session State variable name Variable type Comments 
FeatureCapsManager

FeatureCapsManager

Contains information about which Feature-Caps header values should be applied to outgoing messages on each SIP leg

Statistics

FeatureCapsManagement statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → FeatureCapsManagement
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.FeatureCapsManagement"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
StrippedValuesFromMessage

Incremented when the feature removes Feature-Caps parameter values from a message

 
AddedValuesToMessage

Incremented when the feature adds Feature-Caps parameter values to a message

Behaviour

This feature interacts with the session’s FeatureCapsManager interface and its associated LegFeatureCapsHandler interfaces. These interfaces are documented in the Sentinel VoLTE SPI Javadoc.

When invoked, the FeatureCapsManagement feature iterates over all SIP legs associated with the current session. For each leg, the feature will check if there is a LegFeatureCapsHandler for that leg in the session’s FeatureCapsManager. If there is a LegFeatureCapsHandler for the leg, the feature will look for SIP INVITE requests and responses in the leg’s outgoing message queue. Each INVITE request or response found in the queue will be processed as described below. Each individual message in the queue will only be processed once (i.e. if the feature is invoked multiple times before a given message is sent, that message will only be processed on the first time that it is seen).

Values to Strip

When a message is processed, the feature will first determine if the LegFeatureCapsHandler has any Feature-Caps values to strip. If so, the feature will look for those values on any existing Feature-Caps header on the message. If the values are found, they will be removed from the given header.

Values to Add

After stripping values, the feature will check the LegFeatureCapsHandler for Feature-Caps values to add to the message. If values are found, then a new Feature-Caps header will be appended to the message. The new header will contain all of the values to add.

It is possible for the LegFeatureCapsHandler to indicate that new Feature-Caps values are currently suppressed for the leg. If this is the case, the feature will forgo adding any new Feature-Caps values to the outgoing message.

IMSIDLookup

This feature reads Third Party Registration information stored in the HSS as Transparent Data, and writes it into session state. Information is read during INVITE processing. It reads the Third Party Registration information via the Sh Cache RA. For more information refer to Data Stored by the Third Party Registrar in HSS.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Both or either of MMTEL or SCC

Originating, Forwarding, and Terminating

SIP Access Session Pre-Credit Check

No

No

Stateless

SBB

Prerequisite features

These features must run before IMSIDLookup:

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-imsid-lookup module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-imsid-module opencloud#volte-imsid-lookup#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes a single module:

Module Name Description

volte-imsid-lookup

Contains the feature’s code.

Session input and output variables

Session input variables

Session State variable name Variable type

Subscriber

String
Note This is the IMS Public Identity for the Served User, and is extracted from the SIP INVITE.

Session output variables

Session State variable name Variable type Comments 
RegistrationRecords

List<RegistrationRecord>

The list of registration records for the subscriber

 
IsLoggedIn

boolean

True, if the feature was able to set both IDs

 
CMSISDN

String

The correlation MSISDN registered for the subscriber

 
HasCMSISDN

boolean

True if the CMSISDN is set

Statistics

IMSIDLookup statistics are tracked by the IMSIDLookup SBB and can be found under the following parameter set:
SLEE-Usage ▶ volte.sentinel.sip service ID ▶ IMSIDLookup SBB ID.

Name Type Description 
Invoked

Counter

Incremented when the feature runs.

 
FeatureError

Counter

Incremented when a fatal error occurs during feature execution.

 
NoSubscriberSpecified

Counter

Incremented when the feature is unable to determine which subscriber to retrieve IDs for.

 
IMSIDRetrieveSuccess

Counter

Incremented when IDs are successfully retrieved and decoded.

 
IMSIDRetrieveFail

Counter

Incremented when ID retrieval or decoding fails.

 
CacheQueried

Counter

Incremented when a query is made to the Sh-Cache.

 
CacheIndicatedQuerySuccess

Counter

Incremented when a success response is received from the Sh-Cache.

 
CacheIndicatedQueryFailure

Counter

Incremented when a failure response is received from the Sh-Cache.

 
SubscriberNotRegistered

Counter

Incremented when the searched subscriber is not present in the Sh-Cache or has no valid registration.

 
RegistrationOutOfSync

Counter

Incremented when the searched subscriber information is not consistent between the network and the Sh-Cache.

 
ResponseLatency

Sampled

Records elapsed time between requesting data from the Sh-Cache RA and getting a response (in milliseconds).

Behaviour

The feature queries the HSS using an Access Key of the IMS Public Identity of the Served User and the Service Indication of opencloud-3rd-party-registrar.

User logged in

The RegistrationRecords session state field is set to a List of RegistrationRecord. Each element in the list indicates a device, with public and private IDs, that the subscriber is registered on. If the subscriber is registered on only one device, there is only one element in the list. If the subscriber is simultaneously registered on (say) four devices, there will be four elements in the list.

The CMSISDN field will be set if it is present in the data registered for the user. If the subscriber is simultaneously registered on multiple devices, this value will not be set.

User not logged in

If the user is not logged in, the feature finishes execution without modifying any state.

IMSIDLookupFromCassandra

This feature reads Third Party Registration information stored in the Cassandra Database, and writes it into session state. Information is read during INVITE processing. It reads the Third Party Registration information via the Cassandra CQL RA. For more information refer to Cassandra storage.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Both or either of MMTEL or SCC

Originating, Forwarding, and Terminating

SIP Access Session Pre-Credit Check

No

No

Stateless

POJO

Prerequisite features

These features must run before IMSIDLookupFromCassandra:

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-imsid-lookup-cassandra module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-imsid-cassandra-module opencloud#volte-imsid-lookup-cassandra#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes a single module:

Module Name Description

volte-imsid-lookup-cassandra

Contains the feature’s code.

Session input and output variables

Session input variables

Session State variable name Variable type

Subscriber

String
Note This is the IMS Public Identity for the Served User, and is extracted from the SIP INVITE.

Session output variables

Session State variable name Variable type Comments 
RegistrationRecords

List<RegistrationRecord>

The list of registration records for the subscriber

 
IsLoggedIn

boolean

True, if the feature was able to set both IDs

 
CMSISDN

String

The correlation MSISDN registered for the subscriber

 
HasCMSISDN

boolean

True if the CMSISDN is set

Statistics

IMSIDLookupFromCassandra statistics are tracked by the IMSIDLookupFromCassandra feature and can be found under the following parameter set:
SLEE-Usage ▶ volte.sentinel.sip service ID ▶ volte.sentinel.sip SBB ID ▶ IMSIDLookupFromCassandra.

Name Type Description 
Started

Counter

Incremented when the feature runs.

 
FailedToStart

Counter

Incremented when Sentinel VoLTE encounters an error while attempting to start the feature.

 
IssuedWarning

Counter

Incremented when a non-fatal problem is encountered and the feature and issues a warning.

 
FailedDuringExecution

Counter

Incremented when a fatal problem is encountered and the feature cannot execute correctly.

 
TimedOut

Counter

Incremented when the feature takes too long to complete and Sentinel VoLTE aborts execution.

 
NoSubscriberSpecified

Counter

Incremented when the feature is unable to determine which subscriber to retrieve IDs for.

 
IMSIDRetrieveSuccess

Counter

Incremented when IDs are successfully retrieved and decoded.

 
IMSIDRetrieveFail

Counter

Incremented when ID retrieval or decoding fails.

 
CassandraQueried

Counter

Incremented when a query is made to Cassandra.

 
MultipleDevicesRegistered

Counter

Incremented when multiple registered devices have been detected.

 
SubscriberNotRegistered

Counter

Incremented when could not find an active subscriber.

 
RegistrationOutOfSync

Counter

Incremented when the searched subscriber information is not consistent between the network and the database.

 
ResponseLatency

Sampled

Records elapsed time between querying the Cassandra database and getting a response (in milliseconds).

Behaviour

The feature queries the Cassandra Database using a Primary Key of the IMS Public Identity of the Served User.

User logged in

The RegistrationRecords session state field is set to a List of RegistrationRecord. Each element in the list indicates a device, with public and private IDs, that the subscriber is registered on. If the subscriber is registered on only one device, there is only one element in the list. If the subscriber is simultaneously registered on (say) four devices, there will be four elements in the list.

The CMSISDN field will be set if it is present in the data registered for the user. If the subscriber is simultaneously registered on multiple devices, this value will not be set.

User not logged in

If the user is not logged in, the feature finishes execution without modifying any state.

SetOcsAnnouncementID

SetOcsAnnouncementID schedules configurable announcements to the subscriber based on indicators in OCS answers

The feature enqueues OCS announcements for out-of-credit (4012 CCA result code), low balance (Low-Balance-Indicator AVP) and general use (OC-Play-Announcement-Id) including welcome announcements.

The feature runs on every credit check result and checks if the CCA meets certain criteria (i.e.presence of OC-Play-Announcement-Id AVP, low balance AVP or on 4012 result). If the CCA matches the criteria the feature schedules announcements based off of them. The feature also runs on each party request for a terminating call to determine whether the session has been established and so if a reauthorization request should be triggered.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

Both or either of MMTEL or SCC.

Originating, Forwarding, and Terminating

SipAccess_PartyRequest SipAccess_ServiceTimer SipAccess_CreditAllocatedPostCC SipMidSession_CreditAllocatedPostCC SipAccess_CreditLimitReachedPostCC SipMidSession_CreditLimitReachedPostCC

Yes

No

Stateless

POJO

Behaviour

Announcement IDs set in the OC-Play-Announcement-Id AVP are always played. Configured announcement IDs for out-of-credit (4012 CCA result code) or low balance (Low-Balance-Indicator AVP) are only played if no OC-Play-Announcement-Id AVPs were present.

Call phase

OC-Play-Announcement-Id-AVP

Low Balance Indicator AVP

4012 Out-of- Credit

Behaviour

 
Early media

Present

Not present

Not present

OCS announcement played, call continues

 
Early media

Present

Present

Not present

OCS announcement played, call continues (configured low balance announcement not played)

 
Early media

Present

Not present

Present

OCS announcement played, call ends

 
Early media

Not present

Present

Not present

Low balance feature configured announcement played, call continues

 
Early media

Not present

Present

Present

Out of credit feature configured announcement played, call ends

 
Mid call

Present

Not present

Not present

OCS announcement played, call continues

 
Mid call

Present

Present

Not present

OCS announcement played, call continues (configured low balance announcement not played)

 
Mid call

Present

Not present

Present

OCS announcement played, call ends

 
Mid call

Not present

Present

Not present

Low balance feature configured announcement played, call continues

 
Mid call

Not present

Present

Present

Out of credit feature configured announcement played, call ends

Announcements for terminating calls

It is not possible to play announcements to the terminating subscriber after the initial credit check as the session has not yet been established. If the initial credit check requested announcements then a reauthorization request will be sent once the session is established. Any announcements in the response to this subsequent reauthorization request will be played. The reauthorization request can be delayed for a number of milliseconds using the ChargingReauthDelayMillis configuration field.

Mid call announcements to the terminating subscriber will be played immediately.

Low Balance Announcements

If the LowBalanceIndicator AVP is set in a successful CCA-I or CCA-U then a low balance announcement will be played (either configured or via the OC-Play-Announcement-Id-AVP) and a session state field is set to mark that a low balance announcement has been played. Subsequent credit checks will not trigger another low balance announcement unless the previous credit check response did not have the LowBalanceIndicator AVP set.

Out of Credit Announcements

If a credit check response contains a 4012 result code then:

  • For early originating sessions, the feature will schedule the configured early dialog announcement if an announcement was not supplied in the CCA and then end the session with the appropriate sip error response according to the CCA result code.

  • For early terminating and forwarding sessions, the feature will not schedule an announcement and will end the session with a 480 Temporarily Unavailable response.

  • For confirmed originating and terminating sessions, the feature will schedule the configured mid session announcement if an announcement was not supplied in the CCA and then end the session.

Session state input variables

Attribute Name Type 
LatestOcsAnswer

org.jainslee.resources.diameter.ro.types.vcb0.CreditControlAnswer

 
LegForCdrs

String

 
CallType

com.opencloud.sentinel.common.CallType

Session state output variables

Attribute Name Type Description 
AnnouncementID

int

The ID of the early dialog announcement to play, if any

 
EarlyMediaAnnouncementQueue

List

A List of early dialog announcements to play, if any

 
MidCallAnnouncementId

int

The ID of the mid call announcement to play, if any

 
MidCallAnnouncementQueue

List

A list of the mid call announcements to play, if any

 
EndSessionAfterAnnouncement

int

The Sip response error code for the SipPlayAnnouncement feature to use on endSession.

 
EndSessionWithAnnouncement

boolean

Set to true if session should end after announcement is played.

 
MidCallAnnouncementPlayedParty

String

Leg name indicating which party the announcement will be played to

 
MidCallEndSessionWithAnnouncement

boolean

Set to true if session should end after announcement is played.

 
UserEndSessionCause

int

The Sip response error code to use on endSession, if applicable.

 
LowBalanceAnnouncementPlayed

boolean

Set to true when a low balance announcement has been scheduled. Set to false when a CCA is received without a Low-Balance-Indicator AVP.

 
OcsAnnouncementPlayed

boolean

Set to true when OC-Play-Announcement-Id announcements have been scheduled. Set to false when a new CCA is received.

Configuration

SetOcsAnnouncementID uses two JSLEE configuration profile tables: LowBalanceAnnouncementConfigProfileTable and SetOutOfCreditAnnouncementIDConfigProfileTable.

Attribute Name Profile Table Type Description 
EarlyDialogLowBalanceAnnouncementID

LowBalanceAnnouncementConfigProfileTable

int

The ID of the early dialog announcement to play, if any

 
MidSessionLowBalanceAnnouncementID

LowBalanceAnnouncementConfigProfileTable

int

The ID of the mid call announcement to play, if any

 
ChargingReauthDelayMillis

LowBalanceAnnouncementConfigProfileTable

long

When a terminating call is ACKed and the latest CCA indicates a low balance, a delayed credit check will be performed to postpone playing an announcement. The reauth will be delayed by the amount specified here (0 triggers an immediate reauth.) This allows time for the ACK to propagate through the network to ensure the played party is fully connected before triggering the announcement after receiving another CCA-U with low balance indicator.

 
OutOfCreditAnnouncementID

SetOutOfCreditAnnouncementIDConfigProfileTable

int

The ID of the early dialog announcement to play, if any

 
MidSessionOutOfCreditAnnouncementID

SetOutOfCreditAnnouncementIDConfigProfileTable

int

The ID of the mid call announcement to play, if any

Statistics

SetOcsAnnouncementID statistics are tracked by the SetOcsAnnouncementID feature and can be found under the following parameter set:
SLEE-Usage ▶ volte.sentinel.sip service ID ▶ volte.sentinel.sip SBB ID ▶ SetOcsAnnouncementID.

Name Type Description 
Started

Counter

Incremented each time the feature runs.

 
FailedToStart

Counter

Incremented when sentinel VoLTE encounters an error while attempting to start the feature.

 
IssuedWarning

Counter

Incremented when a non-fatal problem is encountered and the feature issues a warning.

 
FailedDuringExecution

Counter

Incremented when a fatal problem is encountered and the feature cannot execute correctly.

 
TimedOut

Counter

Incremented when the feature takes too long to complete and Sentinel VoLTE aborts execution.

 
TimerEventReceived

Counter

Incremented whenever a ChargingReauthDelay timer event is received.

 
InvalidExecutionPoint

Counter

Incremented whenever the feature is invoked in an invalid execution point. Indicates misconfigured feature scripts.

 
IgnoringRepeatLowBalance

Counter

The feature will not trigger a second announcement for ongoing low balance indicators.

 
ClearLowBalancePlayed

Counter

If a CCA is received with no low balance indicator, any subsequent low balance will trigger another announcement.

 
StartReauthTimer

Counter

Incremented when a terminating call is ACKed but the latest CCA indicates an announcement is requested.

 
LowBalanceReauthTimerEventReceived

Counter

Incremented whenever a reauthorization timer event is received.

 
DoCreditReauth

Counter

Incremented whenever the feature issues a credit reauth.

 
ScheduledOcPlayAnnouncementId

Counter

Incremented whenever an OC-Play-Announcement-Id announcement is enqueued.

 
EarlyDialogLowBalanceAnnouncementIDSet

Counter

Incremented whenever a configured early media Low Balance Announcement ID is enqueued.

 
MidSessionLowBalanceAnnouncementIDSet

Counter

Incremented whenever a configured mid call Low Balance Announcement ID is enqueued.

 
EarlyDialogOutOfCreditAnnouncementIDSet

Counter

Incremented whenever a configured early media Out of Credit Announcement ID is enqueued.

 
MidSessionOutOfCreditAnnouncementIDSet

Counter

Incremented whenever a configured mid call Out of Credit Announcement ID is enqueued.

 
EndSessionCauseSet

Counter

Incremented whenever a session is terminated due to running out of credit.

 
NoOutOfCreditAnnouncementID

Counter

Incremented whenever an early media Out of Credit Announcement cannot be played as there is no configured announcement ID.

 
NoMidSessionOutOfCreditAnnouncementID

Counter

Incremented whenever a mid call Out of Credit Announcement cannot be played as there is no configured announcement ID.

 
UnableToDetermineEndSessionCause

Counter

Incremented whenever the end of session cause code could not be determined.

 
MissingLegForCdrs

Counter

Incremented whenever the leg to play announcements too could not be determined.

Provisioning interfaces

The feature is provisioned using the Sentinel REST API or web interface.

SubscriberDataLookupFromHLR

SubscriberDataLookupFromHLR is responsible for reading subscriber data from the HLR and writing it into Sentinel session state variable fields.

The data it reads from the HLR is accessed through the AnyTimeSubscriberInterrogation MAP operation. The Application Context used is anyTimeInfoHandlingContext_v3_ac

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

Both or either of MMTEL or SCC.

Originating, Forwarding, and Terminating

SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

POJO

Prerequisite features

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-hlr-subscriber-data-lookup module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-hlr-module opencloud#volte-hlr-subscriber-data-lookup#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new module, once completed the original source for the feature can be found in the new module.

The module-pack consists of a single module, volte-hlr-subscriber-data-lookup, containing the feature’s code. It does rely on the volte-map-event-handler which contains the shared event handler for MAP features and also publishes a module pack, however the event handler will not require modification unless a new feature name is introduced.

Session input variables

Attribute Name Type 
Subscriber

String

 
RegistrationRecords

List<RegistrationRecord>

Configuration

The feature uses the HLRConfigProfileTable to access its configuration. For more information refer to HLR CGIN MAP Configuration.

Statistics

SubscriberDataLookupFromHLR statistics are tracked by the SubscriberDataLookupFromHLR feature and can be found under the following parameter set: SLEE-Usage → volte.sentinel.sip service ID → SubscriberDataLookupFromHLR.

Name Type Description 
Started

Counter

Incremented each time the feature runs

 
FailedToStart

Counter

Incremented when sentinel VoLTE encounters an error while attempting to start the feature

 
IssuedWarning

Counter

Incremented when a non-fatal problem is encountered and the feature issues a warning

 
FailedDuringExecution

Counter

Incremented when a fatal problem is encountered and the feature cannot execute correctly

 
TimedOut

Counter

Incremented when the feature takes too long to complete and Sentinel VoLTE aborts execution

 
RequestSent

Counter

Incremented when the feature receives subscriber data from the HLR

 
RequestSuccessful

Counter

Incremented after the feature successfully processes the data it received, and loads it into session state fields

 
RequestFailed

Counter

Incremented when absent configuration data prevents the feature from running

 
ResponseLatency

Sampled

Records elapsed time between sending the request to the HLR and getting a response (in milliseconds).

Behaviour

This feature uses the CGIN MAP RA to access the HLR.

Each time the feature is invoked, it checks the call type and determines the subscriber number that it should use to query the HLR.

The feature attempts to extract "phone number digits" from the Default Public ID, and if it cannot, from any other registered IMS Public User Identity. The first IMS Public User Identity that has "phone number digits" has its digits extracted to form the MSISDN for the AnytimeSubscriptionInterrogation query. If the feature cannot form an MSISDN it raises a Feature Error and finishes execution.

The feature requests the subscriber data by sending a AnyTimeSubscriptionInterrogation request for all Supplementary Services. If the triggering attempt is a terminating trigger, the feature sends two queries in order to gather the Call Forwarding information.

In order to form the ATSI request the feature:

  1. sets the GSM SCF address to the SentinelSCCPAddress configuration value

  2. sets the destination SCCP address to the HlrSCCPAddress configuration value

  3. sets the indicator fields to request CLIP, CLIR, CW, ODB and may request Forwarding information for unconditional forwarding

If the session is a terminating session, a second request is sent where Forwarding information is requested for conditional forwarding.

Once the query(s) are successful, it sets the session state fields for the supplementary services according the mapping below.

Supplementary Service Session State Mappings

GSM Service MMTel Service

CLIP

OIP

COLP

TIP

CLIR

OIR

COLR

TIR

ODB

ICB

ODB

OCB

Call Forwarding

CDIV

Call Waiting

CW

Call Hold

HOLD

GSM ASN.1 Schema to Session-State Fields

The mapping below describes how the AnyTimeSubscriptionInterrogation result is mapped into the MMTel Subscriber Data Representation.

ss-Status ASN.1 field

The field ss-Status is used by almost all supplementary services and defines the service state. Each service defines a set of possible values based on ss-Status, so called State Vectors. A state vector is formed of 4 variables: Provisioning State, Registration State, Activation State and HLR Induction State. This feature only reads the Activation State, i.e. "A and Q" bits.

For more information see 3GPP TS 23.011 - Technical realization of Supplementary Services.

CLIP

ASN.1 Field (From) Session-State Field (To) Mapping Rules

ClipData.ss-Status

MMTelOIPServiceData.active

true if ss-Status=Active and Operative else false.

OverrideCategory

MTelOIPServiceData.override

No default value. It is an obligatory field from HLR response.

CLIR

ASN.1 Field (From) Session-State Field (To) Mapping Rules

ClirData.ss-Status

MMTelOIRServiceData.active

true if ss-Status=Active and Operative else false.

n/a

MMTelOIRServiceData.mode

the same default for IMS OIR

ClirData.CliRestrictionOption

MMTelOIRServiceData.defaultBehaviourType

No default value. It is an obligatory field from HLR response.

COLP

ASN.1 Field (From) Session-State Field (To) Mapping Rules

n/a

MMTelTIPServiceData.active

true.

n/a

MMTelTIPServiceData.override

the same default for IMS TIP

COLR

ASN.1 Field (From) Session-State Field (To) Mapping Rules

n/a

MMTelTIRServiceData.active

true.

n/a

MMTelTIRServiceData.mode

the same default for IMS TIR

ODB - Incoming calls

ASN.1 Field (From) Session-State Field (To) Mapping Rules

n/a

MMTelICBServiceData.active

true.

ODB-Info.ODB-Data.ODB-GeneralData

MMTelICBServiceData.ruleset

see Ruleset Conditions for barring incoming calls

Ruleset Conditions for barring incoming calls

ODB Data Value Condition

allIC-CallsBarred

Unconditional

n/a

Anonymous

roamingOutsidePLMNIC-CallsBarred

Roaming

roamingOutsidePLMNICountryIC-CallsBarred

Roaming and International ExHC

ODB - Outgoing calls

ASN.1 Field (From) Session-State Field (To) Mapping Rules

n/a

MMTelOCBServiceData.active

true

ODB-Info.ODB-Data.ODB-GeneralData

MMTelOCBServiceData.ruleset

see Ruleset Conditions for barring outgoing calls

Ruleset Conditions for barring outgoing calls

ODB Data Value Condition

allOG-CallsBarred

Unconditional

internationalOGCallsBarred

International

internationalOGCallsNotToHPLMN-CountryBarred

International-exHC

roamingOutsidePLMNOG-CallsBarred

Roaming

Call Forwarding

ASN.1 Field (From) Session-State Field (To) Mapping Rules

callForwardingData.forwardingFeatureList[x].ss-Status

MMTelCDIVServiceData.active

true if ss-Status=Active and Operative else false.

callForwardingData.forwardingFeatureList.forwardingOptions

MMTelCDIVServiceData.ruleset

No default value defined.

callForwardingData.forwardingFeatureList.noReplyConditionTime

MMTelCDIVServiceData.noreplytimeout

No default value defined.

Ruleset Conditions for Call Forwarding

ASN.1 value in bits 4 and 3 of Octet 1 of Ext-ForwardOptions Condition 00

Not Reachable

01

Busy

10

No reply

11

Call Waiting

ASN.1 Field (From) Session-State Field (To) Mapping Rules

CallWaitingData.ss-Status

MMTelCWServiceData

true if ss-Status=Active and Operative else false.

Call Hold

ASN.1 Field (From) Session-State Field (To) Mapping Rules

CallHoldData.ss-Status

MMTelHOLDServiceData.active

true if ss-Status=Active and Operative else false.

SubscriberDataLookupFromHSS

SubscriberDataLookupFromHSS is responsible for reading data from the HSS and writing it into Sentinel session state fields.

The data it reads from the HSS must be accessed from TransparentUserData in the HSS.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

Both or either of MMTEL or SCC

Originating, Forwarding, and Terminating

SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

SBB

Prerequisite features

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-hss-subscriber-data-lookup-2 module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-hss2-module opencloud#volte-hss-subscriber-data-lookup-2#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

volte-hss-subscriber-data-lookup-2

Contains the feature’s code.

volte-hss-subscriber-data-lookup-2-service-indication-profile

Contains the profile specification for the feature configuration profile table.

Session input variables

Attribute Name Type 
Subscriber

String

 
RegistrationRecords

List<RegistrationRecord>

Configuration

This feature has an out-of-the-box configuration ensuring the MMTel features work. The configuration may be extended to

  • support additional MMTel features that use the MMTel services XML schema

  • support additional features that use a different XML schema

This configuration extensibility is supported through the profile table named ${PlatformOperatorName}_SubscriberDataLookupFromHss2ServiceIndicationProfileTable. If the platform operator name is RocketInc then the profile table name is RocketInc_SubscriberDataLookupFromHss2ServiceIndicationProfileTable.

The profile table contains one profile for each Service Indication that shall be queried in the HSS. Each profile defines:

  1. the Service-Indication

  2. the fully qualified class name of the Transparent Data Codec class - used to parse the returned XML into a Java Object

  3. a list of adaptor class names (fully qualified class names)

  4. an option to enable or disable the query

This table, by the default, has entries for MMTEL-Services and the IMS-ODB-Information. The MMTEL-Services query is enabled by default, while IMS-ODB-Information is disabled. The query can be enabled or disabled by setting the value of DisableQuery field to true or false. A value of true disables the query.

Statistics

SubscriberDataLookupFromHss statistics are tracked by the SubscriberDataLookupFromHss2 SBB and can be found under the following parameter set: SLEE-Usage → volte.sentinel.sip service ID → SubscriberDataLookupFromHss2 SBB ID.

Name Type Description 
Invoked

Counter

Incremented each time the feature runs.

 
Failed

Counter

Incremented if a fatal error occurs while the feature is running.

 
SubscriberDataRetrieved

Counter

Incremented when the feature receives subscriber data from the HSS or Sh-Cache.

 
SessionStatePopulated

Counter

Incremented after the feature successfully processes the data it received, and loads it into session state fields.

 
AdaptorClassError

Counter

Incremented when Adaptor class is not of type SimservsSessionAdaptor or the feature fails to retrieve adaptor class.

 
CodecClassError

Counter

Incremented when Codec class is not of type ServiceDataCodec or the feature fails to retrieve codec class.

 
Misconfigured

Counter

Incremented when absent configuration data prevents the feature from running.

 
SessionStateNotFound

Counter

Incremented when the session state field the feature requires for operation is missing.

 
ResponseLatency

Sampled

Records elapsed time between sending the request to the HSS and getting a response (in milliseconds).

Behaviour

This feature uses the Sh Cache RA to access the HSS.

Each time the feature is invoked, it determines the IMS public identity that it should use to query the HSS.

If the session input variable DefaultPublicID of the first RegistrationRecord in the RegistrationRecords list is present, this field is used as the IMS public identity in the HSS query. Otherwise, the the session input variable subscriber is used as the IMS public identity in the HSS query.

The feature requests the Sh Cache RA to fetch the transparent user data for the IMS Public Identifier and Service Indication. This data is stored in the corresponding session-state fields.

The feature can be configured to fetch multiple Service Indications, i.e. to retrieve different documents. The out-of-the-box configuration looks for the MMTel Services document.

For each profile in the feature’s configuration

  1. the feature requests the Sh Cache RA to fetch the transparent user data document

  2. Once a result is available, each adaptor in the list of adaptors is invoked in order to populate session state

MMTel Schema to Session-State Fields

The MMTel Services schema is configured into this feature in all out-of-the-box installations. This section describes the source of a variable (from within the returned document), and the destination session state field name and attribute for the out-of-the-box configuration.

OIP

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-originating-identity-presentation/originating-identity-presentation/active

MMTelOIPServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete-originating-identity-presentation/operator-originating-identity-presentation/restriction-override

MMTelOIPServiceData.override

If not present in the XML document, the field is set to override-not-active according to 3GPP TS 24.607. This is the default from the XML schema.

For more information on MMTEL OIP see MMTelOIP.

OIR

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-originating-identity-restriction/originating-identity-presentation-restriction/active

MMTelOIRServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete-originating-identity-restriction/operator-originating-identity-presentation-restriction/mode

MMTelOIRServiceData.mode

If not specified the field is set to temporary according to 3GPP TS 24.607.

MMTELServices/complete-originating-identity-restriction/originating-identity-presentation-restriction/default-behaviour

MMTelOIRServiceData.defaultBehaviourType

If not specified the field is set to presentation-restricted according to 3GPP TS 24.607. This is the default from the XML schema.

For more information on MMTEL OIR see MMTelOIR.

TIP

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-terminating-identity-presentation/terminating-identity-presentation/active

MMTelTIPServiceData.active

If not specified the field is set to false.

MMTELServices/complete-terminating-identity-presentation/operator-terminating-identity-presentation/restriction-override

MMTelTIPServiceData.override

If not specified the field is set to override-not-active according to 3GPP TS 24.608. This is the default from the XML schema.

For more information on MMTEL TIP see MMTelTIP.

TIR

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-terminating-identity-restriction/terminating-identity-presentation-restriction/active

MMTelTIRServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete-terminating-identity-restriction/operator-terminating-identity-presentation-restriction/mode

MMTelTIRServiceData.mode

If not specified the field is set to temporary according to 3GPP TS 24.608. This is the default from the XML schema.

For more information on MMTEL TIR see MMTelTIR.

ICB

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-communication-barring/incoming-communication-barring/active

MMTelICBServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete/communication-barring/incoming-communication-barring/ruleset

MMTelICBServiceData.ruleset

No default value specified.

For more information on MMTEL ICB see MMTelICB.

OCB

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-communication-barring/outgoing-communication-barring/active

MMTelOCBServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete-communication-barring/outgoing-communication-barring/ruleset

MMTelOCBServiceData.ruleset

No default value specified.

For more information on MMTEL OCB see MMTelOCB.

Operator Determined Barring

For more information see Operator Determined Barring.

CDIV

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-communication-diversion/active

MMTelCDIVServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

MMTELServices/complete-communication-diversion/NoReplyTimer

MMTelCDIVServiceData.noReplyTimeOut

No default value specified.

MMTELServices/complete-communication-diversion/ruleset

MMTelCDIVServiceData.rules

The default value is specified in Network operator data for MMTEL CDIV CDIVNoReplyTimeout.

Ruleset Conditions for CDIV. Ruleset is a collection of rules.

XPath in document (From) Session-State Field (To) Default values

MMTELServices/common-policy/conditions

MMTelCDIVServiceData.rules[].conditions

No default value specified.

MMTELServices/complete-communication-diversion/forward-to

MMTelCDIVServiceData.rules[].forwardToAction

No default value specified.

For more information on MMTEL CDIV see MMTelCDIV.

CW

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-communication-waiting/communication-waiting/active

MMTelCWServiceData

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

For more information on MMTEL CW see MMTelCW.

HOLD

Sh Field (From) Session-State Field (To) Default values

n/a

MMTelHOLDServiceData.active

If not present in the XML document, the field is set to true according to 3GPP TS 24.623.

For more information on MMTEL Hold see MMTelHold.

Flexible-Alerting

XPath in document (From) Session-State Field (To) Default values

MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/group-type

MMTelFAGroup

single-user or multiple-users.

MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/membership

MMTelFAMembership

demand or permanent.

MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/members

MMTelFAServiceData.members[]

No default value.

MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/identity

MMTelFAServiceData.identity

The Pilot Number. No default value.

MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/@authorized

MMTelFAServiceData.authorized

Default value true.

For more information on MMTEL FA see Flexible Alerting.

ECT

XPath in document (From) Session-State Field (To) Default values

MMTelServices/complete-explicit-communication-transfer/operator-explicit-communication-transfer/@authorized

MMTelECTServiceData.authorized

Default value false.

For more information on MMTEL ECT see MMTelECT

SubscriberDataLookupFromHSSOld

SubscriberDataLookupFromHSSOld is responsible for reading data from the HSS and writing it into Sentinel session state variables fields.

Note: this feature is deprecated in favour of the new SubscriberDataLookupFromHSS feature. This deprecated feature is installed by default, but is not referenced in any feature execution script. The feature remains in case external developers used it as an extensibility mechanism. All out-of-the-box product features have been migrated away from this feature. In previous releases of the Sentinel VoLTE product, this feature was named SubscriberDataLookupFromHss, but it has now been renamed to SubscriberDataLookupFromHssOld. I.e. there is a new feature with the name SubscriberDataLookupFromHss.

The data it reads from the HSS must be accessed from TransparentUserData in the HSS.

The session state fields that are written to, and the locations in the XML documents retrieved from the HSS, are configurable.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

Both or either of MMTEL or SCC

Originating, Forwarding, and Terminating

SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

SBB

Prerequisite features

  • SubscriberDetermination

  • IMSIDLookup

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-hss-subscriber-data-lookup module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-hss-module opencloud#volte-hss-subscriber-data-lookup#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

volte-hss-subscriber-data-lookup

Contains the feature’s code.

volte-hss-subscriber-data-lookup-service-indication-profile

Contains the profile specification for configuring the service indications the feature should request.

volte-hss-subscriber-data-lookup-field-mapping-profile

Contains the profile specification for configuring the session state fields the feature should populate.

Network operator data

This data is stored in two JSLEE configuration profile tables. Both are scoped by Sentinel selection key. (However, unlike various other features, each operator has a profile table with multiple profiles within the table.)

  • The first is for mapping transparent user data service indications to Java codec classes.

  • The second configures the mapping between sections of the decoded document and session state variables/fields.

Service indications and codecs

Different applications use transparent user data in the HSS. To distinguish the format of the data, individual applications get unique service indications.

To enable flexibility, this feature allows a new XML schema to be introduced, alongside Java classes to parse (turn the XML into Java objects) and generated XML (turn Java objects back into XML for storage in the HSS).

The Java classes are called “codecs”, as they encode and decode between XML and Java.

This is stored in the profile table named $NetworkOperator_SubscriberDataLookupFromHssServiceIndicationProfileTable.

For example, if the network operator is “OpenCloud”, then the profile table name is OpenCloud_SubscriberDataLookupFromHssServiceIndicationProfileTable.

Each profile in the table has the following attributes.

Attribute Name Type Comments 
ServiceIndication

String

This is the value of the Service Indication. For example, for MMTEL this is MMTEL-Services

 
CodecFQCN

String

This is the fully qualified class name of the codec class. For example, for Sentinel VoLTE MMTEL, this is com.opencloud.mmtel.feature.hssdata.MmtelServiceDataCodec

Field definition profile

For the XML document to be entered into session state (so that other features can read these variables), the XML document must be broken down into relevant variables.

This is fulfilled by use of a field definition profile. Each field definition profile defines one session state variable, and where it comes from in the XML document.

Attribute Name Type Comments 
SessionStateFieldName

String

The name of the session state field to write to.

 
XPath

String

The location in the XML document to read from.

 
ServiceIndication

String

The service indication in transparent user data in the HSS.

 
RootElementName

String

The name of the root element of the document; if non-empty it is chopped off the XPath.

This is stored in the profile table $NetworkOperator_SubscriberDataLookupFromHssFieldDefinitionProfileTable; for example, if the network operator is “OpenCloud” then the profile table name is OpenCloud_SubscriberDataLookupFromHssFieldDefinitionProfileTable.

Communication diversion active example

As an example, MMTEL supplementary service settings are read by using the “MMTEL-Services” service indication.

Within the returned document, the XPath for the CDIV feature being active is /complete-communication-diversion/communication-diversion/@active.

The session state variable name is determined by the feature in question. In this case, the MMTelCDIV feature looks for a session input variable called CDIVActive.

So we end up with the following configuration for this field:

Attribute Name Value 
SessionStateFieldName

CDIVActive

 
XPath

/complete-communication-diversion/communication-diversion/@active

 
ServiceIndication

MMTEL-Services

 
RootElementName

An alternative (using RootElementName) is:

Attribute Name Value 
SessionStateFieldName

CDIVActive

 
XPath

MMTelServices/complete-communication-diversion/communication-diversion/@active

 
ServiceIndication

MMTEL-Services

 
RootElementName

MMTelServices

Session input variables

Attribute Name Type 
Subscriber

String

 
RegistrationRecords

List<RegistrationRecord>

Statistics

SubscriberDataLookupFromHss statistics are tracked by the SubscriberDataLookupFromHss SBB and can be found under the following parameter set: SLEE-Usage → volte.sentinel.sip service ID → SubscriberDataLookupFromHss SBB ID.

Name Description 
SubscriberDataLookupFromHssInvoked

Incremented each time the feature runs.

 
SubscriberDataLookupFromHssFailed

Incremented if a fatal error occurs while the feature is running.

 
SubscriberDataLookupFromHssSubscriberDataRetrieved

Incremented when the feature receives subscriber data from the HSS or Sh-Cache.

 
SubscriberDataLookupFromHssSessionStatePopulated

Incremented after the feature successfully processes the data it received, and loads it into session state fields.

 
SubscriberDataLookupFromHssMisconfigured

Incremented when absent configuration data prevents the feature from running.

 
SubscriberDataLookupFromHssSessionStateNotFound

Incremented when the session state field the feature requires for operation is missing.

Behaviour

This feature uses the Sh Cache RA to access the HSS.

Each time the feature is invoked, it checks the call type and determines the IMS public identity that it should use to query the HSS.

If the session input variable DefaultPublicID of the first RegistrationRecord in the RegistrationRecords list is present, this field is used as the IMS public identity in the HSS query. Otherwise, the the session input variable subscriber is used as the IMS public identity in the HSS query.

For each service indication profile, the feature requests the Sh Cache RA to return the transparent user data for the IMS public identifier and service indication.

Next, the document is queried once for each field definition profile. The results of each XPath query are written into the session state variable. If any error occurs, the session state variable is not modified.

Examples of errors include:

  • Cannot decode the XML document.

  • The session state variable name does not correspond to a session state variable (for example, it was mistyped).

  • The Java type for the session state variable, and the type of the object returned by the XPath query are incompatible.

  • The XPath query did not return any data.

Recommended minimum configuration for MMTEL

In order to provide MMTEL, according to IR.92 it is recommended that:

  • the service indication profile includes the pre-built MMTel codec

  • all session input variables for the out-of-the-box MMTel features are included.

Minimum service indication profiles for MMTEL

ServiceIndication CodecFQCN 
MMTEL-Services

com.opencloud.mmtel.feature.hssdata.MmtelServiceDataCodec

Minimum field definition profiles for MMTEL

SessionStateFieldName XPath ServiceIndication RootElementName 
CDIVActive
 
/complete-communication-diversion/communication-diversion/@active
 
MMTEL-Services
 
CDIVRuleset
 
/complete-communication-diversion/communication-diversion/ruleset
 
MMTEL-Services
 
CDIVSubscriberNoReplyTimeout
 
/complete-communication-diversion/communication-diversion/NoReplyTimer
 
MMTEL-Services
 
CWActive
 
/complete-communication-waiting/communication-waiting/@active
 
MMTEL-Services
 
ICBActive
 
/complete-communication-barring/incoming-communication-barring/@active
 
MMTEL-Services
 
ICBRuleset
 
/complete-communication-barring/incoming-communication-barring/ruleset
 
MMTEL-Services
 
OCBActive
 
/complete-communication-barring/outgoing-communication-barring/@active
 
MMTEL-Services
 
OCBRuleset
 
/complete-communication-barring/outgoing-communication-barring/ruleset
 
MMTEL-Services
 
OIPActive
 
/complete-originating-identity-presentation/originating-identity-presentation/@active
 
MMTEL-Services
 
OIRActive
 
/complete-originating-identity-restriction/originating-identity-presentation-restriction/@active
 
MMTEL-Services
 
OIRDefaultBehaviourType
 
/complete-originating-identity-restriction/originating-identity-presentation-restriction/default-behaviour
 
MMTEL-Services
 
TIPActive
 
/complete-terminating-identity-presentation/terminating-identity-presentation/@active
 
MMTEL-Services
 
TIRActive
 
/complete-terminating-identity-restriction/terminating-identity-presentation-restriction/@active
 
MMTEL-Services
 
TIRDefaultBehaviourType
 
/complete-terminating-identity-restriction/terminating-identity-presentation-restriction/default-behaviour
 
MMTEL-Services

SuppressSdpCdr

SuppressSdpCdr is a system feature which prevents SDP-change initiated CDRs from being written by the VolteInterimCdr feature for non-roaming Mobile Terminating calls.

Statistics

SuppressSdrCdr statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → SuppressSdpCdr
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.SuppressSdpCdr"

Name

Description

 
Started

Incremented each time the feature runs

 
NoPendingSdpCdr

Incremented when the feature runs but there is no pending SDP CDR to suppress

 
SdpCdrWriteSuppressed

Incremented each time an SDP CDR is suppressed

 
SdpCdrWriteAllowed

Incremented each time the feature runs but doesn’t suppress a pending SDP CDR

Functionality

This feature uses information available in session state to suppress interim CDRs from being written in response to SDP changes for non-roaming Mobile Terminating calls. The mechanism it uses to suppress the CDRs from being written by the VolteInterimCdr feature is to unset the WriteCdrOnSDPChange session state field.

When this feature runs, if the session state variable RoamingIndicator is False, and CallType is MobileTerminating, the WriteCdrOnSDPChange session state field will be set to False.

VoLTE Interim CDR Feature

VolteInterimCdr is a system feature that is responsible for writing interim Call Detail Records throughout the session.

VolteInterimCdr runs at various key points throughout a session and if any of its write conditions are met, it will create a new interim CDR based on session state, and write it out using the cdr-ra.

Tip

By default, Sentinel runs VolteInterimCdr as the very last feature in the post phase of almost every Sip or Charging related feature execution script and EndSession. For example:

featurescript SipEndSession-SysPost-Default {
    run VolteInterimCdr
    run MaxCallDuration
    run SessionRefresh
}

Details

Feature script name

VolteInterimCdr

Applicable contexts

SIP service

Prerequisite features

None, but information from various features is used if available

Session state inputs and outputs

Inputs

If any of these fields are unset the feature will skip writing them to the CDR file.

This feature uses the same session state fields as the Sentinel Interim CDR feature. This page will only discuss the additions to the fields described there.

Name Type Description Where set

TerminatingDomain

String

The accepted terminating domain in a T-ADS scenario

MMTelWifiChargingFinalisation feature, SCCTADSParallelRouting feature

MMTelInformation

org.jainslee.resources.diameter .ro.types.vcb0.MmtelInformation

The MMTel-Information Diameter AVP

DiameterMMTelInfo feature

RegistrationRecords

List<com.opencloud.sentinel.state.RegistrationRecord>

Contains subscriber information retrieved from the Registrar and HSS or Cassandra

IMSIDLookup feature, IMSIDLookupFromCassandra feature

CallReferenceNumber

byte[]

Contains the Call Reference Number used in queries to the HLR

FetchMSRN feature

Functionality

This features uses the information from the session state fields mentioned above and constructs a protobuf message out of it for output. See AVP CDR Format for the format of these messages.

Also see Charging Information for general information about the contents of CDRs and CCRs.

Note This feature only supports writing binary CDRs. If the cdr-ra is configured to write string CDRs the feature will fail to execute.

Feature responses

Response Reason

featureHasFinished

feature has finished

VoLTE SIP AVP CDR Feature

This feature is responsible for building a Call Detail Record that reflects the actions taken whilst processing a session.

It runs once when a session is ending and creates a CDR based on information gathered from session state, and then writes it out using the cdr-ra.

Tip

By default, Sentinel runs VolteSipAvpCdr in the post SIP end session feature execution script. For example:

featurescript SipEndSession-SysPost-Default {
    run VolteSipAvpCdr
    run MaxCallDuration
    run SessionRefresh
}

Details

Feature script name

VolteSipAvpCdr

Applicable contexts

SIP service

Prerequisite features

None, but information from various features is used if available

Session state inputs and outputs

Inputs

If any of these fields are unset the feature will skip writing them to the CDR file.

This feature uses the same session state fields as the Sentinel SIP AVP CDR feature. This page will only discuss the additions to the fields described there.

Name Type Description Where set

TerminatingDomain

String

The accepted terminating domain in a T-ADS scenario

MMTelWifiChargingFinalisation feature, SCCTADSParallelRouting feature

MMTelInformation

org.jainslee.resources.diameter .ro.types.vcb0.MmtelInformation

The MMTel-Information Diameter AVP

DiameterMMTelInfo feature

RegistrationRecords

List<com.opencloud.sentinel.state.RegistrationRecord>

Contains subscriber information retrieved from the Registrar and HSS or Cassandra

IMSIDLookup feature, IMSIDLookupFromCassandra feature

CallReferenceNumber

byte[]

Contains the Call Reference Number used in queries to the HLR

FetchMSRN feature

Functionality

This features uses the information from the session state fields mentioned above and constructs a protobuf message out of it for output. See AVP CDR Format for the format of these messages.

Also see Charging Information for general information about the contents of CDRs and CCRs.

Note This feature only supports writing binary CDRs. If the cdr-ra is configured to write string CDRs the feature will fail to execute.

Feature responses

Response Reason

featureHasFinished

feature has finished

VoLTE SIP Legacy CDR Feature

This feature is responsible for building a Call Detail Record that reflects the actions taken whilst processing a session.

It runs once when a session is ending and creates a CDR based on information gathered from session state, and then writes it out using the cdr-ra.

Warning This feature is deprecated and not enabled by default. It has been superseded by the VoLTE SIP AVP CDR feature

Details

Feature script name

VolteSipLegacyCdr

Applicable contexts

SIP service

Prerequisite features

None, but information from various features is used if available

Session state inputs and outputs

Inputs

If any of these fields are unset the feature will skip writing them to the CDR file.

This feature uses the same session state fields as the Sentinel SIP Legacy CDR feature. This page will only discuss the additions to the fields described there.

Name Type Description Where set

TerminatingDomain

String

The accepted terminating domain in a T-ADS scenario

MMTelWifiChargingFinalisation feature, SCCTADSParallelRouting feature

Statistics

VolteSipLegacyCdr statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → VolteSipLegacyCdr
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.VolteSipLegacyCdr"

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when a fatal error occurs before feature execution

 
IssueWarning

Incremented when a non fatal error occurs while the feature is executing

 
FailedDuringExecution

Incremented when a fatal error occurs while the feature is executing

 
TimedOut

Incremented when feature execution does not complete within a reasonable time frame

 
CDRwritten

Incremented when a CDR is written successfully

 
CDRnotWritten

Incremented when a CDR is not written successfully due to an error

Functionality

This features uses the information from the session state fields mentioned above and constructs a protobuf message out of it for output. See Legacy CDR Format for the format of these messages.

Also see Charging Information for general information about the contents of CDRs and CCRs.

Note This feature only supports writing binary CDRs. If the cdr-ra is configured to write string CDRs the feature will fail to execute.

Feature responses

Response Reason

featureHasFinished

feature has finished

MMTel Features

These features are MMTel specific.

Feature What it does

a logical representation of supplementary service data as a group of POJO objects. It allows MMTel services/features to execute independently of any concrete schema for the supplementary service data. Therefore it can be loaded from the HSS or the HLR using the MMTel-Services XML schema or 3GPP MAP ASN.1 schema.

lets users create multi-party sessions between two or more parties

provides a means for UEs to subscribe to “conference” event package notifications for a conference

enables a ‘diverting user’ to divert communications addressed to the ‘diverting user’ to another destination

lets a UE be informed that no resources are available for an incoming communication

determines if the SIP session is roaming and if it represents an international, or international ex HC call, based on the location of the calling party and the destination address

lets a user suspend reception of the media stream(s) of an established IP multimedia session, and resume the media stream(s) at a later time

implements incoming communication barring and anonymous communication rejection

implements outgoing communication barring

are barring conditions determined by the operator that takes precedence over MMTelICB and MMTelOCB

implements the Originating Identification Presentation (OIP) service

implements the Originating Identification Restriction (OIR) service

implements the Terminating Identification Presentation (TIP) service

implements the Terminating Identification Restriction (TIR) service

handles the finalisation of charging when a call is answered over WiFi.

records charging information about MMTel supplementary services invoked on a call.

determines if and how the Flexible Alerting features will execute based on feature configuration and the HSS Subscriber Data.

implements the Flexible Alerting service, by alerting the group members in parallel

implements the Flexible Alerting service, by sequentially alerting the group members.

connects the IMPU acquired from the subscriber registration to the existing ACI for the session transfer

checks if the subscriber has the STOD service provisioned

handles the transfer request and route it to the previous bound session

intercepts the transfer INVITE routed by the MMTelStodTriggerAnchor feature and connects the existing called led to the new calling leg and releases the previous calling leg

enables a party involved in a communication to transfer their role in that communication to a third party

adds the geo-local value to the Tel URI phone-context parameter for local numbers that should not be translated to international format.

Call Barring Features

Call Barring Features.

Feature What it does

implements incoming communication barring and anonymous communication rejection

implements outgoing communication barring

are barring conditions determined by the operator that takes precedence over MMTelICB and MMTelOCB

are 4 operator defined rules that are stored in the AS. The ODB data indicates which of them should be evaluated and, like all others ODB conditions, they take precedence over MMTelICB and MMTelOCB

MMTelICB

The MMTelICB feature implements incoming communication barring and anonymous communication rejection . (The MMTelOCB feature implements outgoing communication barring.)

What is ICB?

3GPP defines Communication Barring in TS 24.611, including Incoming Communication Barring (ICB), Anonymous Communication Rejection as a special case of ICB, and Outgoing Communication Barring (OCB):

The incoming communication barring (ICB) is a service that rejects incoming communications that fulfil certain provisioned or configured conditions on behalf of the terminating user.

The anonymous communication rejection (ACR) is a particular case of the ICB service, that allows barring of incoming communications from an anonymous originator on behalf of the terminating user.

The incoming communication barring (ICB) service makes it possible for a user to have barring of certain categories of incoming communications according to a provisioned or user configured barring program and is valid for all incoming communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. Examples of conditions are whether the asserted originating public user identity matches a specific public user identity or whether the originating public user identity is restricted (anonymous). The action part could specify for a rule that contains a matching condition that the specific incoming communication is barred.

The inhibition of incoming forwarded calls is a special case of the ICB and allows the served user to reject incoming communications from users or subscribers who have diverted the communication towards the served user. The communication history information will be used to trigger the service.

The anonymous communication rejection (ACR) service allows the served user to reject incoming communications on which the asserted public user identity of the originating user is restricted. In case the asserted public user identity of the originating user is not provided then the communication is allowed by the ACR service. It is highlighted here because it is a regulatory service in many countries.

Feature Cheat Sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Terminating

SipAccess_SubscriberPreCreditCheck

Yes

Yes, comes from the HSS

Stateless

POJO

Prerequisite Features

Note For announcements, SIPPlayAnnouncement is a dependent feature; but it is not a prerequisite.

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-communication-barring module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-cb-module opencloud#mmtel-communication-barring#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules relevant to this feature:

Module Name Description

mmtel-communication-barring

Group module for the feature that includes all of the modules listed below.

mmtel-communication-barring-library

Contains code shared by both communication barring features.

mmtel-icb-profile

Contains the profile specification for the feature configuration profile table.

mmtel-icb

Contains the feature itself.

Interaction with OIP

According to section 4.6.4 of 3GPP TS 24.611, MMTelICB must run before MMTelOIP.

Network Operator Data

This data is stored in a JSLEE Configuration Profile Table, called MMTelICBConfigProfileTable.

Operator data is scoped according to a Sentinel selection key. There is one profile in the ProfileTable for each network operator.

Attribute Name Type Default Value Description 
PlayAnnouncement

Boolean

 
false

If true, ICB will request an announcement is played in the case that it bars the session setup.

 
ACRAnnouncementID

int

 
0

The ID for the announcement to be played in the case of Anonymous Call Rejection. If set to zero there is no announcement.

 
AnnouncementID

int

 
0

The ID for the announcement to be played in all other ICB cases. If set to zero there is no announcement.

 
InternationalRulesActive

Boolean

 
false

If false, ICB will ignore International and International-exHC rules.

Session Input Variables

Variable name Type Comments 
MMTelICBServiceData

Complex

 
RoamingIndicator

Boolean

 
International

Boolean

 
InternationalExHC

Boolean

Session Output Variables

Variable name Type Comments 
ICBBarred

Boolean

Set to true if the ICB feature bars the call. It exists so that feature execution scripts can read the variable and take action

 
ICBBarredWithAnnouncement

Boolean

Set to true if the ICB feature bars the call, and the feature is configured to request an announcement as part of barring

 
AnnouncementID

int

The announcement ID to be used if an announcement is configured as part of barring

 
EndSessionAfterAnnouncement

int

The status code used when ending the session — if barring has occurred and announcements are used.

 
RanIcb

Boolean

Signals to other features that ICB ran on this session.

Supported Barring Rule Conditions

Barring rule conditions that are evaluated include:

Anonymous

To comply with the requirements as set for simulation of the ACR service, the anonymous element only evaluates to true when the conditions as set out in subclause 4.5.2.6.2 for asserted originating public user identity apply.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for anonymous calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="anonymous">
        <cp:conditions>
            <anonymous/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Roaming

This condition evaluates to true if the session state variable RoamingIndicator is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for roaming calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="roaming">
        <cp:conditions>
            <roaming/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Media

This condition evaluates to true when the value of this condition matches the media field in one of the "m=" lines in the SDP message body offered in an INVITE request.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for calls offering specific media:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="no_video">
        <cp:conditions>
            <media>video</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Combinations of media types may be expressed as multiple conditions within the same rule. For example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="no_video_and_text">
        <cp:conditions>
            <media>video</media>
            <media>text</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Identity

This condition evaluates to true if the identity of the other party in the communication matches that which is expressed in the condition. Identities within the condition can be expressed in different ways:

  • a single, fully expressed identity (e.g. sip:alice@example.com)

  • a whole domain (e.g. example.com)

  • a whole domain, but with exceptional identities or domains (e.g. example.com except for alice@example.com)

  • all identities (may also have exceptions)

  • any combination of the above

The following XML snippets show how to configure the user’s Subscriber data for each of the above cases.

A single, fully expressed identity (the identity 'sip:alice@example.com' is matched)

This example, without any other rule, blocks any session from 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="bar-alice">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A domain (all identities at 'example.com' are matched)

This example, without any other rule, blocks any session from domain 'example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="bar-domain">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional identity (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session from domain 'example.com' except if originated from 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domain-with-exception">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except id="sip:alice@example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional domain (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session from domain 'example.com' except if originated from the subdomain 'callcentre.example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domain-except-callcentre">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except domain="callcentre.example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Important Note the attribute of the 'except' element is now 'domain'.
All identites (all identities are matched)

This example, without any other rule, blocks all sessions from any user.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-all">
        <cp:conditions>
            <cp:identity>
                <many />
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A more complex Identity condition expression (all identies at 'example2.com' match except for 'sip:charlie@example2.com'. Also the identities 'sip:alice@example1.com' and 'sip:bob@example1.com' match.)

This example, without any other rule, blocks any session from all users registered in the domain 'example2.com', from the user 'sip:alice@example1.com' and from the user sip:bob@example1.com, except from 'sip:charlie@example2.com.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-some">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example1.com"/>
                <one id="sip:bob@example1.com"/>
                <many domain="example2.com">
                    <except id="sip:charlie@example2.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Another more complex Identity condition expression with more than one rule.

This example, always blocks some domains, always allow other domains and a set of sip URIs.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="always-allow-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="emergency.org"></many>
                <many domain="police.org"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>true</allow>
        </cp:actions>
    </cp:rule>

    <cp:rule id="always-barr-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="fakelotery.org"></many>
                <many domain="dhueb!.org"></many>
                <many domain="fakeprize.com"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

   <cp:rule id="always-barr-these-identities">
        <cp:conditions>
            <cp:identity>
                <one id="sip:john@example.com"/>
                <one id="sip:marc@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

</cp:ruleset>
Tip Depending on the value of the 'allow' element of the rule, the rule can essentially become a 'whitelist' or a 'blacklist'.

International

This condition evaluates to true if the session state variable International is true and 'InternationalRulesActive' is true. 'International' is set by the MMTel Determine International and Roaming Status feature. 'InternationalRulesActive' is configured in the ICB feature profile and defaults to false. This is because it is not possible to accurately determine whether the calling party is international in all circumstances.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for international calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international">
        <cp:conditions>
            <international/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

International-exHC

This condition evaluates to true if the session state variable InternationalExHC is true and 'InternationalRulesActive' is true. 'International' is set by the MMTel Determine International and Roaming Status feature. 'InternationalRulesActive' is configured in the ICB feature profile and defaults to false. This is because it is not possible to accurately determine whether the calling party is international in all circumstances.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for international-exHC calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international-exHC">
        <cp:conditions>
            <international-exHC/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Unconditional

An empty conditions element is used to represent unconditional.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for all calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="anonymous">
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Communication Diverted

This condition evaluates to true when the incoming communication has been previously diverted.

Diverted communication can be recognised by the presence of the History header field, as specified in 3GPP TS 24.604

Use this XML in the REM HSS Subscriber Data Page to configure ICB for diverted calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="diverted">
        <cp:conditions>
            <communication-diverted/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Validity

This condition evaluates to true if the current time is within the times specified by the validity period Time is based on the Home Network time; that is, the time of the MMTel Server.

Use this XML in the REM HSS Subscriber Data Page to configure ICB for a validity period:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="validity">
        <cp:conditions>
            <cp:validity>
                <cp:from>2000-01-01T00:00:00</cp:from>
                <cp:until>2099-12-31T23:59:59</cp:until>
            </cp:validity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Rule Deactivated

This condition always evaluates to false. Generally used to disable a rule that has other conditions without removing the rule entirely.

The rule is re-enabled by removing this condition.

Use this XML in the REM HSS Subscriber Data Page to configure a deactivated rule:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="deactivated">
        <cp:conditions>
            <rule-deactivated/>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Barring Rule Actions

Barring rule actions are a string. There could be many actions defined, but the only one that makes any sense is the allow action.

The allow action has a Boolean attribute, with meaning as follows:

  • true — allow session setup to proceed

  • false — deny session setup from proceeding.

Any other rule action (in other words, an action that is not set to allow) will result in us treating the action as the following:

  • allow rule action with value of true.

Statistics

MMTelICB statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB

Statistic Incremented when…​ 
MMTelICBFeatureStarted

the feature runs

 
MMTelICBFeatureFailedToStart

sentinel VoLTE encounters an error while attempting to start the feature

 
MMTelICBFeatureIssuedWarning

a non-fatal problem is encountered and the feature and issues a warning

 
MMTelICBFeatureFailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 
MMTelICBFeatureTimedOut

the feature takes too long to complete and Sentinel VoLTE aborts execution

 
MMTelICBFeatureCallBarred

the feature bars a call (including when barring due to ACR)

 
MMTelOCBFeatureCallBarredByOdb

the feature bars a call by Operator Determined Barring rule

 
MMTelICBFeaturePlayAnnouncementTriggered

the feature requests that an announcement be played to the calling party

 
MMTelICBFeatureACRTriggered

a call is barred by ACR

 
MMTelICBFeatureOdbRulesEvaluatedTrue

a rule was evaluated to be True

Behaviour

If operator data is not present, the ICB feature:

  1. Increments an error statistic.

  2. Logs a message at the Fine level.

  3. Informs the Sentinel core that the feature is not configured appropriately (Invalid Configuration).

  4. Exits.

If MMTelICBServiceData.Active is false, the feature finishes execution without modifying any state.

If the rules do not parse, then the feature:

  • instructs Sentinel core that the feature has failed due to configuration problems

  • finishes execution without modifying any state.

When the feature processes a set of rules:

For each rule, if then

  • the rule has no <conditions> element;

  • the rule has an empty <conditions> element; or

  • conditions are present and they all evaluate to true;

the rule matches.

The actions from all matching rules are combined.

If…​ then the combined result for the rule set is:

any matching rules had the action allow=true

allow=true

all matching rules had the action allow=false

allow=false

no rules matched

allow=true
Tip When a rule contains multiple conditions, they all must match for the whole rule to match. This is essentially a logical 'AND' between the conditions. To express a logical 'OR' of conditions, the conditions must be placed in different rules.

If the combined result is allow=false, then the ICB feature sets the session output variable ICBBarred to true. Otherwise the ICB feature sets the session output variable ICBBarred to false and finishes without modifying any further state.

If network configuration has PlayAnnouncement set to true (MmtelICBConfig.PlayAnnouncement == true), and ICB has decided to bar the communication, then the ICB feature sets session output variable AnnouncementID to MmtelICBConfig.AnnouncementID.

Finally, if the communication is to be barred, ICB rejects the call with the appropriate SIP error response code:

If any matching rule contains the “anonymous” condition, use 433 Anonymity Disallowed. This is to provide ACR functionality. (See section 4.5.2.6.1.)

Otherwise use 603 Decline.

Roaming Determination

The ICB feature does not compute whether or not the served user is roaming; rather it relies on a session input variable (isRoaming). This is set by Sentinel’s DetermineIfRoaming feature.

Example feature execution script fragment:

run DetermineInternationalAndRoamingStatus
run MMTelICB

Playing Announcements

The MMTelICB feature does not play announcements itself; rather it relies on setting of session output variables (AnnouncementID, ICBBarredWithAnnouncement, EndSessionAfterAnnouncement). These are set by the MMTelICB feature if an announcement is to be played. They are used by the out-of-the-box feature execution scripts such that if announcements are desired to be played prior to the barred call being terminated, it is played using the SIPPlayAnnouncement feature.

This is an example feature execution script, taken from a fragment of the out-of-the-box execution scripts.

run MMTelICB
if (session.ICBBarredWithAnnouncement) {
   run SIPPlayAnnouncement
}

The SIPPlayAnnouncement feature checks session state for the AnnouncementID field, and if the value is non-zero will play an announcement. When the announcement is played using the SIPPlayAnnouncement feature, it is played to the calling party.

Finally, when the announcement is complete the SIPPlayAnnouncement feature ends the session with the appropriate SIP error response (provided by MMTelICB during its execution). The SIP error response code is set in the EndSessionAfterAnnouncement session output variable.

Graceful Handling of Originating Access

ICB is a terminating feature. It will finish execution without modifying any state if it is invoked in an originating attempt.

Background Information on Format of Barring Rules

Each rule is expressed as an XCAP cp-rule.

That is, it is an XML fragment:

<cp:rule id="rule66">
        <cp:conditions>
		condition1
		condition2
        </cp:conditions>
        <cp:actions>
          <allow>false</allow>
        </cp:actions>
 </cp:rule>

In case that the allow element is not found, the feature assumes allow = false.

MMTelOCB

The MMTelOCB feature implements outgoing communication barring .

(The MMTelICB feature implements incoming communication barring and anonymous communication rejection.)

What is OCB?

3GPP defines communication barring in TS 24.611, including Incoming Communication Barring (ICB), Anonymous Communication Rejection as a special case of ICB, and Outgoing Communication Barring (OCB):

The Outgoing Communication Barring (OCB) is a service that rejects outgoing communications that fulfil certain provisioned or configured conditions on behalf of the originating user.

The Outgoing Communication Barring (OCB) service makes it possible for a user to have barring of certain categories of outgoing communications according to a provisioned or user configured barring program and is valid for all outgoing communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. An example condition is whether the request uri matches a specific public user identity. The action part can specify for a rule that contains a matching condition that the specific outgoing communication it to be barred. The complete set of conditions and actions that apply to this service and their semantics is described in subclause 4.9.Incoming.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO or SBB Feature Other notes

MMTEL

 
OriginatingSipAccess_SubscriberPreCreditCheck
 
SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

POJO

Prerequisite features

Note For announcements, SIPPlayAnnouncement is a dependent feature; but it is not a prerequisite.

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-communication-barring module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-cb-module opencloud#mmtel-communication-barring#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules relevant to this feature:

Module Name Description

mmtel-communication-barring

Group module for the feature that includes all of the modules listed below.

mmtel-communication-barring-library

Contains code shared by both communication barring features.

mmtel-ocb-profile

Contains the profile specification for the feature configuration profile table.

mmtel-ocb

Contains the feature itself.

Network operator data

This data is stored in a JSLEE configuration profile table, called MMTelOCBConfigProfileTable.

Operator data is scoped according to a Sentinel selection key. There is one profile in the profile table for each network operator.

Attribute Name Type Description 
OCBPlayAnnouncement

Boolean

If true, MMTelOCB will request an announcement is played in the case that it bars the session setup.

 
OCBAnnouncementID

int

The ID for the announcement to be played. If set to zero there is no announcement.

Defaults for network operator data

Attribute Name Default Value 
OCBPlayAnnouncement
 
false
 
OCBAnnouncementID
 
0

Session input variables

Variable name Type Comments 
MMTelOCBServiceData

Complex

 
RoamingIndicator

Boolean

 
International

Boolean

 
InternationalExHC

Boolean

Session output variables

Variable name Type Comments 
OCBBarred

Boolean

Set to true if the OCB feature bars the call. It exists so that feature execution scripts can read the variable and take action.

 
OCBBarredWithAnnouncement

Boolean

Set to true if the OCB feature bars the call, and the feature is configured to request an announcement as part of barring

 
AnnouncementID

int

The value of the announcement ID to be played. Zero has a special meaning — that no announcement is to be played.

 
EndSessionAfterAnnouncement

int

The status code used when ending the session — if barring has occurred and announcements are used.

 
RanOcb

Boolean

Signals to other features that OCB ran on this session.

Supported barring rule conditions

Roaming

This condition evaluates to true if the session state variable RoamingIndicator is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for roaming calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="roaming">
        <cp:conditions>
            <roaming/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Media

This condition evaluates to true when the value of this condition matches the media field in one of the "m=" lines in the SDP message body offered in an INVITE request.

Use this XML in the REM HSS Subscriber Data Page to configure OCB for calls offering specific media:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="no_video">
        <cp:conditions>
            <media>video</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Combinations of media types may be expressed as multiple conditions within the same rule. For example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="no_video_and_text">
        <cp:conditions>
            <media>video</media>
            <media>text</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Identity

This condition evaluates to true if the identity of the other party in the communication matches that which is expressed in the condition. Identities within the condition can be expressed in different ways:

  • a single, fully expressed identity (e.g. sip:alice@example.com)

  • a whole domain (e.g. example.com)

  • a whole domain, but with exceptional identities or domains (e.g. example.com except for alice@example.com)

  • all identities (may also have exceptions)

  • any combination of the above

The following XML snippets show how to configure the user’s Subscriber data for each of the above cases.

A single, fully expressed identity (the identity 'sip:alice@example.com' is matched)

This example, without any other rule, blocks any session torwards 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-alice">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A domain (all identities at 'example.com' are matched)

This example, without any other rule, blocks any session torwards any user in the 'example.com' domain.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional identity (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session torwards all users in the 'example.com' domain, except for 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domains-with-exceptions">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except id="sip:alice@example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional domain (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session torwards all users in the 'example.com' domain, except for users within the domain 'callcentre.example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domain-except-callcentre">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except domain="callcentre.example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Important Note the attribute of the 'except' element is now 'domain'.
All identites (all identities are matched)

This example, without any other rule, blocks all sessions torwards any user.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-all">
        <cp:conditions>
            <cp:identity>
                <many />
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A more complex Identity condition expression (all identies at 'example2.com' match except for 'sip:charlie@example2.com'. Also the identities 'sip:alice@example1.com' and 'sip:bob@example1.com' match.)

This example, without any other rule, blocks any session torwards all users registered in the domain 'example2.com', for 'sip:alice@example1.com' and sip:bob@example1.com, except for 'sip:charlie@example2.com.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-some">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example1.com"/>
                <one id="sip:bob@example1.com"/>
                <many domain="example2.com">
                    <except id="sip:charlie@example2.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Another more complex Identity condition expression with more than one rule.

This example, always blocks some domains, always allow other domains and a set of sip URIs.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="always-allow-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="emergency.org"></many>
                <many domain="police.org"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>true</allow>
        </cp:actions>
    </cp:rule>

    <cp:rule id="always-barr-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="fakelotery.org"></many>
                <many domain="dhueb!.org"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

   <cp:rule id="always-barr-these-identities">
        <cp:conditions>
            <cp:identity>
                <one id="sip:john@example.com"/>
                <one id="sip:marc@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

</cp:ruleset>
Tip Depending on the value of the 'allow' element of the rule, the rule can essentially become a 'whitelist' or a 'blacklist'.

International

This condition evaluates to true if the session state variable International is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international">
        <cp:conditions>
            <international/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

International-exHC

This condition evaluates to true if the session state variable InternationalExHC is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international-exHC calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international-exHC">
        <cp:conditions>
            <international-exHC/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

International when roaming

This condition evaluates to true if the session state variable International is true and RoamingIndicator is true. These are set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international when roaming calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international">
        <cp:conditions>
            <roaming/>
            <international/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Unconditional

Use this XML in the REM HSS Subscriber Data page to configure OCB for all calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Validity

This condition evaluates to true if the current time is within the times specified by the validity period.

Time is based on the Home Network time (that is, the time of the MMTel Server).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions>
            <cp:validity>
                <cp:from>1970-01-01T00:00:00</cp:from>
                <cp:until>1970-01-01T00:00:00</cp:until>
            </cp:validity>
        </cp:conditions>
    </cp:rule>
</cp:ruleset>

Rule deactivated

This condition always evaluates to false. Used to disable a rule without removing the rule entirely. The rule is re-enabled by removing this condition.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions>
            <rule-deactivated/>
            <cp:validity>
                <cp:from>1970-01-01T00:00:00</cp:from>
                <cp:until>1970-01-01T00:00:00</cp:until>
            </cp:validity>
        </cp:conditions>
    </cp:rule>
</cp:ruleset>
Barring rule actions

Barring rule actions are a string. There could be many actions defined, but the only one that makes any sense is the allow action.

The allow action has a Boolean attribute, with meaning as follows:

  • true — allow session setup to proceed

  • false — deny session setup from proceeding.

Any other rule action (that is, an action that is not set to allow) will result in us treating the action as the following:

  • allow rule action with value of true.

Statistics

MMTelOCB statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB.

Statistic Incremented when…​ 
MMTelOCBFeatureStarted

the feature runs

 
MMTelOCBFeatureFailedToStart

sentinel VoLTE encounters an error while attempting to start the feature

 
MMTelOCBFeatureIssuedWarning

a non-fatal problem is encountered and the feature and issues a warning

 
MMTelOCBFeatureFailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 
MMTelOCBFeatureTimedOut

the feature takes too long to complete and Sentinel VoLTE aborts execution

 
MMTelOCBFeatureCallBarred

the feature bars a call

 
MMTelOCBFeatureCallBarredByOdb

the feature bars a call by Operator Determined Barring rule

 
MMTelOCBFeaturePlayAnnouncementTriggered

the feature requests that an announcement be played to the calling party

 
MMTelOCBFeatureOdbRulesEvaluatedTrue

a rule was evaluated to be True

Behaviour

If operator data is not present, the OCB feature:

  1. Increments an error statistic.

  2. Logs a message at the Fine level.

  3. Informs the Sentinel core that the feature is not configured appropriately (Invalid Configuration).

  4. Exits.

If MMTelOCBServiceData.Active is false, the feature finishes execution without modifying any state.

If the rules do not parse, then the feature:

  • instructs Sentinel Core that the feature has failed due to configuration problems

  • finishes execution without modifying any state.

When the feature processes a set of rules, it does each in turn:

For each rule, if: then

  • the rule has no <conditions> element;

  • the rule has an empty <conditions> element; or

  • conditions are present and they all evaluate to true.

the rule matches

The actions from all matching rules are combined.

If…​ then the combined result for the rule set is:

any matching rules had the action allow=true

allow=true

all matching rules had the action allow=false

allow=false

no rules matched

allow=true
Tip When a rule contains multiple conditions, they all must match for the whole rule to match. This is essentially a logical 'AND' between the conditions. To express a logical 'OR' of conditions, the conditions must be placed in different rules.

If the combined result is allow=false, then the OCB feature sets the session output variable OCBBarred to true. Otherwise the OCB feature sets the session output variable OCBBarred to false and finishes without modifying any further state.

If THE network configuration has OCBPlayAnnouncement set to true, and OCB has decided to bar the communication, then the OCB feature sets the session output variable AnnouncementID to MmtelOCBConfig.OCBAnnouncementID.

Finally, if the communication is to be barred, OCB rejects the call with the appropriate SIP error response code: 603 Decline.

Roaming determination

The MMTelOCB feature does not compute whether or not the served user is roaming; rather it relies on a session input variable (RoamingIndicator). This is set by Sentinel’s DetermineIfRoaming feature.

Here is an example feature execution script fragment:

run DetermineIfRoaming
run MMTelOCB

Playing announcements

The MMTelOCB feature does not play announcements itself; rather it relies on setting session output variables (AnnouncementID, OCBBarredWithAnnouncement, EndSessionAfterAnnouncement). These are set by the MMTelOCB feature if an announcement is to be played. They are used by the out-of-the-box feature execution scripts such that if announcements are desired to be played prior to the barred call being terminated, it is played using the SIPPlayAnnouncement feature.

This is an example feature execution script, taken from a fragment of the out-of-the-box execution scripts.

run MMTelOCB
if (session.OCBBarredWithAnnouncement) {
   run SIPPlayAnnouncement
}

The SIPPlayAnnouncement feature checks session state for the AnnouncementID field, and if the value is non-zero will play an announcement. When the announcement is played using the SIPPlayAnnouncement feature, it is played to the calling party.

Finally, when the announcement is complete the SIPPlayAnnouncement feature ends the session with the appropriate SIP error response (provided by MMTelOCB during its execution). The SIP error response code is set in the EndSessionAfterAnnouncement session output variable.

Graceful handling of terminating access

MMTelOCB is an originating feature. It will finish execution without modifying any state if it is invoked in an terminating attempt.

Background information on format of barring rules

Each rule is expressed as an XCAP cp-rule — as an XML fragment:

<cp:rule id="rule66">
        <cp:conditions>
		condition1
		condition2
        </cp:conditions>
        <cp:actions>
          <allow>false</allow>
        </cp:actions>
 </cp:rule>

In case that the allow element is not found, the feature assumes allow = false.

Operator Determined Barring

The Operator Determined Barring are barring conditions determined by the operator that takes precedence over MMTelICB and MMTelOCB .

What is ODB?

Operator determined barring is specified for IMS in the 3GPP specifications TS 24.315 and TS 22.041:

from TS 24.315

The network feature Operator Determined Barring (ODB) allows a network operator or service provider to regulate access to IMS subsystem services, by the barring of certain categories of incoming or outgoing communications, the barring of certain categories of roaming and the barring of certain categories of supplementary services configuration and invocation.

ODB Data

The ODB data is stored as transparent data in the HSS. The SubscriberDataLookupFromHSS feature is responsible to retrieve the ODB data from the HSS. The SubscriberDataLookupFromHSS Configuration should contain the service indication as IMS-ODB-Information and the proper codec. The SubscriberDataLookupFromHSS queries the HSS and if the operator had configured any ODB rules for that subscriber then user data will be returned, parsed and then stored in a session state field MMTelODBServiceData. The MMTelICB and MMTelOCB will use the session state field MMTelODBServiceData to evaluate the ODB conditions before the subscriber defined conditions.

Enabling ODB

ODB can be enabled using the DisableQuery option in the SubscriberDataLookupFromHSS. The sdk installer provides an option for setting DisableQuery on IMS and DisableQuery on MMTel.

Supported Barring Rule Conditions

The sections below show XML data stored in the HSS for the supported conditions. The outgoing conditions are evaluated by the MMTelOCB feature, the incoming conditions are evaluated by MMTelICB and the operator type conditions are evaluated by both features.

Enabling ODB

The HSS IMS-ODB-Information query can be enabled using the DisableQuery option in the SubscriberDataLookupFromHSS.

Bar all outgoing communications

Bar all of the outgoing communications, The OutgoingBarring tag is set to "0".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <OutgoingBarring>0</OutgoingBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar all outgoing international communications

Barring of all outgoing communications to international destinations. The OutgoingBarring tag is set to "1".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <OutgoingBarring>1</OutgoingBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar all outgoing communications when international ex-hplmnc

Barring of all outgoing communications to international destinations excluding home network. The OutgoingBarring tag is set to "2".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
           <OdbForImsMultimediaTelephonyServices>
            <OutgoingBarring>2</OutgoingBarring>
           </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar all outgoing communications when roaming

Barring of all outgoing communications roaming outside the home PLMN country. The OutgoingBarring tag is set to "3".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <OutgoingBarring>3</OutgoingBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar all incoming communications

Barring of all international communications, the IncomingBarring tag is set to "0".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
           <IncomingBarring>0</IncomingBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar all incoming communications when roaming

Barring of all incoming communications roaming outside the home PLMN country. The IncomingBarring tag is set to "0".

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
           <IncomingBarring>1</IncomingBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar Outgoing Premium-Rate Communication

The premium-rate barring options can be described as follows:

Option Description

PremiumRateCommunicationsInformation

Bar all outgoing communications where "premium-rate" for "information" is indicated.

PremiumRateCommunicationsEntertainment

Bar all outgoing communications where "premium-rate" for "entertainment" is indicated.

PremiumRateCallsInformationWhenRoamingOutsideHplmnCountry

The same as 'PremiumRateCommunicationsInformation' but only for communications that are roaming outside of the Home PLMN Country.

PremiumRateCallsEntertainmentWhenRoamingOutsideHplmnCountry

The same as 'PremiumRateCommunicationsEntertainment' but only for communications that are roaming outside of the Home PLMN Country.

Example XML:

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
           <OutgoingPremiumRateBarring>
               <PremiumRateCommunicationsInformation>
                    true
               </PremiumRateCommunicationsInformation>
               <PremiumRateCommunicationsEntertainment>
                    true
               </PremiumRateCommunicationsEntertainment>
               <PremiumRateCallsInformationWhenRoamingOutsideHplmnCountry>
                    true
               </PremiumRateCallsInformationWhenRoamingOutsideHplmnCountry>
               <PremiumRateCallsEntertainmentWhenRoamingOutsideHplmnCountry>
                    true
               </PremiumRateCallsEntertainmentWhenRoamingOutsideHplmnCountry>
           </OutgoingPremiumRateBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Operator Specific Barring Rules

The Operator Specific Barring Types conditions specifies 4 types of user defined rules. The rules are stored in the VoLTE profiles and follow the same schema for Simservs RuleSet. The information on ODB data in the HSS just indicates which rule type should be evaluated.

The example below indicated that all 4 rules should be evaluated.

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
           <OperatorSpecificBarring>
	      <Type1>true</Type1>
	      <Type2>true</Type2>
	      <Type3>true</Type3>
	      <Type4>true</Type4>
    	  </OperatorSpecificBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar Invocation of communication transfer

This condition prevents the Explicit Call Transfer feature MMTelECT from running. The conditions are:

Condition Description

SimpleInvocationOfCommunicationTransferBarring

Prevents user-invoked call transfers from happening. Has three options:

  • Barring of Invocation of Communication Transfer (0)

  • Barring of Invocation of Communication Transfer Where at least one leg is charged (1) Not Supported

  • Barring of Invocation of Communication Transfer Where at least one leg is charged at international rates (2) Not Supported

InvocationOfChargeableCommunicationTransferBarring

Prevents user-invoked call transfers when both calls are charged to the served user. Not Supported

MultipleInvocationOfCommunicationTransferBarring

Prevents a user-invoked call transfer when there is an existing transferred call for the served user.

 
<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <SimpleInvocationOfCommunicationTransferBarring>
               0
            </SimpleInvocationOfCommunicationTransferBarring>

    	    <InvocationOfChargeableCommunicationTransferBarring>
               true
            </InvocationOfChargeableCommunicationTransferBarring>

   	    <MultipleInvocationOfCommunicationTransferBarring>
               true
            </MultipleInvocationOfCommunicationTransferBarring>

          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar Management of Supplementary Services

This condition is evaluated during provisioning time when the subscriber tries to change its own supplementary services configuration via XCAP Interface. If the condition is set to true the XCAP servers will deny any change to subscriber change attempt.

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <BarringOfSupplementaryServicesManagement>
               true
            </BarringOfSupplementaryServicesManagement>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Bar Registration of Diverted To Address

This condition is evaluated during provisioning time when the subscriber tries to change the target to address of the supplementary services via XCAP Interface. Currently the diverted to address is present at the Communication Diversion (CDIV) settings. It is the <target> sub-element of the <forward-to> element in a CDIV rule’s actions.

The bar condition can have the following values:

  • 0 Barring of Registration of any communication diverted-to address

    • currently supported

  • 1 Barring of Registration of any international communication diverted-to address

    • not supported yet

  • 2 Barring of Registration of any international communication diverted-to address EXHPLMNC

    • not supported yet

<?xml version="1.0" encoding="utf-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>IMS-ODB-Information</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
         <OdbForImsOrientedServices xmlns="odb.mmtel.sentinel.volte.opencloud.com">
          <OdbForImsMultimediaTelephonyServices>
            <DivertedToAddressRegistrationBarring>
               0
            </DivertedToAddressRegistrationBarring>
          </OdbForImsMultimediaTelephonyServices>
         </OdbForImsOrientedServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Operator Specific Barring Types

The Operator Specific Barring Types are 4 operator defined rules that are stored in the AS. The ODB data indicates which of them should be evaluated and, like all others ODB conditions, they take precedence over MMTelICB and MMTelOCB .

What is Operator Specific Barring?

The 3GPP specifications TS 24.315 defines:

The Operator specific barring definition for type 1, type 2, type 3, and type 4 is locally configured in the AS providing the ODB service. For operator specific barring the criteria that can be used by the operator to define conditions that are used to determine whether the category applies may be based on any signalling information from the incoming request. Examples of such criteria are: 1) destination type e.g. international numbers or specific numbers; 2) media used in the communication, e.g. audio, video, or text.

The scope definition of what kind of conditions can be present in those rules is not specified. The OpenCloud implementation of those rules follows the simservs RuleSet definition (TS 29.364 ) for MMTelICB Supported Barring Rule Conditions and MMTelOCB Supported barring rule conditions. This way the operator can define the same MMTel barring conditions supported by the MMTelOCB and MMTelICB features.

ODB-Specific Conditions

There are conditions that are unique to ODB. These are:

Incoming Communications

To make a rule match on any communications that are 'incoming', add the <incoming /> element to its set of conditions.

Example:

<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
    <cp:rule id="barr-alice-incoming">
        <cp:conditions>
            <incoming />
            <cp:identity>
                <one id="sip:alice@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Outgoing Communications

To make a rule match on any communications that are 'outgoing', add the <outgoing /> element to its set of conditions.

Example:

<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
    <cp:rule id="barr-alice-outgoing">
        <cp:conditions>
            <outgoing />
            <cp:identity>
                <one id="sip:alice@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

How to provision the Operator Specific Barring rules

The operator can include the rules in the profile MMTelOdbOperatorSpecificTypesConfigProfileTable.

Attribute Name

Type

 
Default Value

Description

 
Type1

String

 
null

The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type1 is true

 
Type2

String

 
null

The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type2 is true

 
Type3

String

 
null

The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type3 is true

 
Type4

String

 
null

The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type4 is true

Examples

The sections below show XML data stored in the VoLTE profile MMTelOdbOperatorSpecificTypesConfigProfileTable. The values can be applied for type 1 to type 4. The fact that the <incoming\> and <outgoing\> are not present, means that those rules will be applied to both directions.

barr video

<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
    <cp:rule id="no_video">
        <cp:conditions>
            <media>video</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

barr identity

<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
    <cp:rule id="barr-alice">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

barr specific domain for a 1 month period

<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
    <cp:rule id="barr-domain">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com"></many>
            </cp:identity>
            <cp:validity>
                <cp:from>2016-01-01T00:00:00</cp:from>
                <cp:until>2016-01-31T23:59:59</cp:until>
            </cp:validity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Diameter MMTel Information

This feature records charging information about MMTel supplementary services invoked on a call.

The feature name is DiameterMMTelInfo, as it is based on 3GPP TS 32.299 v12.11.0 (vcb0).

Feature cheat-sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Originating and Terminating

  • SipAccess_PartyRequest

  • SipAccess_PartyResponse

  • SipAccess_SubscriberCheck

  • SipAccess_ServiceTimer

  • SipMidSession_PartyRequest

  • SipMidSession_PartyResponse

  • SipMidSession_CreditAllocatedPostCC

  • SipMidSession_CreditLimitReachedPostCC

  • SipMidSession_OCSFailurePostCC

  • SipLegEnd

  • SipEndSession

No

No

Stateless

POJO

Session state inputs and outputs

Inputs

Name Type Purpose

CallType

Enum

Used to set the Subscriber-Role AVP.

RanOip

boolean

If true, adds Supplementary-Service AVP indicating that OIP was used on the call.

RanOir

boolean

If true, adds Supplementary-Service AVP indicating that OIR was used on the call.

RanTip

boolean

If true, adds Supplementary-Service AVP indicating that TIP was used on the call.

RanTir

boolean

If true, adds Supplementary-Service AVP indicating that TIR was used on the call.

RanIcb

boolean

If true, adds Supplementary-Service AVP indicating that ICB was used on the call.

RanOcb

boolean

If true, adds Supplementary-Service AVP indicating that OCB was used on the call.

RanCW

boolean

If true, adds Supplementary-Service AVP indicating that CW was used on the call.

RanHOLD

boolean

If true, adds Supplementary-Service AVP indicating that HOLD was used on the call.

LastDiversionType

Enum

Used to populate the CDIV Supplementary-Service AVP.

DiversionCounter

int

Used to populate the CDIV Supplementary-Service AVP.

Subscriber

String

Used to populate the Associated-Party-Address AVP in the CDIV Supplementary-Service AVP.

Outputs

Name Type Description

MMTelInformation

MmtelInformation

The MMTel-Information AVP that will be written to a CDR, or sent in a Credit-Control-Request. This AVP is defined in 3GPP TS 32.299 v12.11.0 §7.2.111. Contains information about the MMTel supplementary services invoked during the call.

Behaviour

The DiameterMMTelInfo feature populates the Diameter Ro MMTel-Information AVP with information about supplementary services used in the call. The feature stores an MMTel-Information AVP in session state, and updates it at various feature execution points when other supplementary services have run. The resulting MMTel-Information AVP is used by the VolteSipAvpCdr feature when writing a CDR. The MMTel-Information AVP is also sent in the final Credit-Control-Request to the OCS.

Flexible Alerting Features

Flexible Alerting Features

Feature What it does

determines if and how the Flexible Alerting features will execute based on feature configuration and the HSS Subscriber Data.

implements the Flexible Alerting service, by alerting the group members in parallel

implements the Flexible Alerting service, by sequentially alerting the group members.

MMTel Determine Flexible Alerting Mode

The MMTelDetermineFlexibleAlertingMode feature determines if and how the Flexible Alerting features will execute based on feature configuration and the HSS Subscriber Data. .

The Determine Flexible Alerting Mode feature runs before the Flexible Alerting features. It reads subscriber data and configuration profile tables to determine the flexible alerting mode and supplies this information to the MMTelParallelFA and MMTelSequentialFA features as a session state field.

Feature cheat sheet

B2BUA Instance Originating/Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

All

Terminating

Subscriber Check

Yes

Yes

Stateless

POJO

Prerequisite features

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-flexible-alerting module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-mmtel-flexible-alerting opencloud#mmtel-flexible-alerting#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

mmtel-determine-flexible-alerting-mode

Group module for the Determine Flexible Alerting Mode feature.

mmtel-determine-flexible-alerting-mode-profile

The profile for this feature

mmtel-determine-flexible-alerting-mode-library

The common library for this module pack

mmtel-parallel-fa

The flexible alerting parallel feature.

mmtel-sequential-fa

The flexible alerting sequential feature.

Network Operator Data

The data present in JSLEE profile table MMTelDetermineFAConfigProfileTable is used to configure the behaviour of the Flexible Alerting features: MMTelParallelFA and MMTelSequentialFA. This profile table is scoped by the sentinel key and the Pilot Number.

Here is an example of a profile entry:

'SomeOperatorName::::sip:callcentre@someoperator.com':
            ModeIsParallel: true
            ParallelMaxWaitTimeout: 5000
            SequentialAnyResponseTimeout: 2000
            SequentialFinalResponseTimeout: 5000

The default profile entry is not scoped by a Pilot Number:

'SomeOperatorName::::':
            ModeIsParallel: true
            ParallelMaxWaitTimeout: 5000
            SequentialAnyResponseTimeout: 2000
            SequentialFinalResponseTimeout: 5000
Variable Name Type Comments 
ParallelMaxWaitTimeout

int

Set the amount of time in milliseconds that the MMTelParallelFA waits for a final response before canceling the session for a pilot number.

 
ModeIsParallel

boolean

Set the mode to parallel (true) or sequential (false).

 
SequentialAnyResponseTimeout

int

Set the amount of time in milliseconds that the MMTelSequentialFA waits for a any response from the INVITE before start alerting the next member.

 
SequentialFinalResponseTimeout

int

Set the amount of time in milliseconds that the MMTelSequentialFA waits for a final response from the INVITE before start alerting the next member.

Session Input Variables

Variable Name Type Comments 
MMTelServiceData

Complex

Service data read from HSS

Session Output Variables

Variable Name Type Comments 
FlexibleAlertingMode

Enum

Determines whether the FA Group will be alerted in sequential or parallel way or if none of the flexible alerting features will run. Possible values are: NONE, PARALLEL or SEQUENTIAL.

 
FlexibleAlertingGroupMode

Enum

Determines whether the FA Group is of type single-user or multiple-users. Possible values are: GROUP_NONE, SINGLE_USER or MULTIPLE_USERS

Statistics

MMTelDetermineFAMode statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB

Statistic Incremented when…​ 
MMTelDetermineFAModeFeatureFAModeStarted

each time the feature runs

 
MMTelDetermineFAModeFeatureFailedDuringExecution

a fatal error occurs while the feature is executing

 
MMTelDetermineFAModeFeatureFailedToStart

sentinel VoLTE encounters an error while attempting to start the feature.

 
MMTelDetermineFAModeFeatureIssuedWarning

a non-fatal problem is encountered and the feature and issues a warning.

 
MMTelDetermineFAModeFeatureTimedOut

the feature takes too long to complete and Sentinel VoLTE aborts execution.

 
MMTelDetermineFAModeFeatureFAModeNoFA

the feature fails to trigger Flexible Alerting under FA mode

 
MMTelDetermineFAModeFeatureFANoProfile

no valid profile is loaded for poilt subscriber

 
MMTelDetermineFAModeFeatureFAValidPilotNumber

subscriber data equals the requestUri header.

Behaviour

When the feature starts, it tries to load the configuration profile for the pilot number present in the flexible alerting subscriber data. The table MMTelDetermineFAConfigProfileTable is expected to contain a profile with name scoped by the sentinel selection key and the Pilot Number, i.e, SomeOperatorName::::sip:callcentre@someoperator.com.

If there is no profile for the pilot number the feature try to get the configuration from the default profile: SomeOperatorName::::.

When there is no suitable profile the FlexibleAlertingMode is set to NONE and the FlexibleAlertingGroupMode is set to GROUP_NONE. It means that the neither MMTelParallelFA nor MMTelSequentialFA will run.

When there is a suitable profile, the feature checks if the flexible-alerting is active by checking the authorized field in the flexible-alerting Subscriber Data. If the service is not active, i.e authorized="false", neither MMTelParallelFA nor MMTelSequentialFA will run. The HSS schema for flexible alerting defines two sets of services that can contain the key authorized: operator-flexible-alerting and operator-flexible-alerting-group. The feature checks both to define if the service is authorized. The table below shows the logic:

operator-flexible-alerting authorized
 
operator-flexible-alerting-group authorized
 
service status
 
true
 
true
 
active
 
true
 
null
 
active
 
null
 
true
 
active
 
false
 
any
 
inactive
 
any
 
false
 
inactive
 
null
 
null
 
inactive

When flexible alerting is active, the group type in the Subscriber Data (single-user or multiple-users) is written into the Session State variable FlexibleAlertingGroupMode. The FlexibleAlertingMode Session State field is set according to the value in the configuration profile (ModeIsParallel attribute).

Subscriber data examples

MULTIPLE_USERS

HSS Subscriber Data

<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices
                xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"
                xmlns:cp="urn:ietf:params:xml:ns:common-policy">
                <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                        <identity>sip:friends@home1.opencloud.co.nz</identity>
                        <group-type>multiple-users</group-type>
                        <membership>permanent</membership>
                        <members>
                            <member active="true">sip:bob@home1.opencloud.co.nz</member>
                            <member active="true">sip:charlie@home1.opencloud.co.nz</member>
                            <member active="true">sip:daisy@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Profile configuration

ModeIsParallel: true
ParallelMaxWaitTimeout: 20000
SequentialAnyResponseTimeout: 2000
SequentialFinalResponseTimeout: 5000

In the example above, the group sip:friends@home1.opencloud.co.nz has three active members. The FlexibleAlertingGroupMode is set to MULTIPLE_USERS , the FlexibleAlertingMode is set to PARALLEL, and the timeout is set to 20 seconds.

SINGLE_USER

HSS Subscriber Data

<Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices
                xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"
                xmlns:cp="urn:ietf:params:xml:ns:common-policy">
                <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                        <identity>sip:bob@home1.opencloud.co.nz</identity>
                        <group-type>single-user</group-type>
                        <membership>permanent</membership>
                        <members>
                            <member active="true">sip:bob@home1.opencloud.co.nz</member>
                            <member active="true">sip:bob-mobile@home1.opencloud.co.nz</member>
                            <member active="true">sip:bob-desk@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Profile configuration

ModeIsParallel: false
ParallelMaxWaitTimeout: 5000
SequentialAnyResponseTimeout: 2000
SequentialFinalResponseTimeout: 5000

In the example above, the group sip:bob@home1.opencloud.co.nz has three active members. The FlexibleAlertingGroupMode is set to SINGLE_USER, the FlexibleAlertingMode is set to SEQUENTIAL and the timeout is for receiving any response from a member is set to 2 seconds and the timeout for receiving a final response from a member is 5 seconds.

MMTelParallelFA

The MMTelParallelFA feature implements the Flexible Alerting service, by alerting the group members in parallel

Feature Cheat Sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Terminating

Sip_Access_Subscriber_Check, Sip_Access_Party_Request, Sip_Access_Party_Response, Sip_Access_Service_Timer, SipMidSession_Party_Request, Sip_Mid_Session_Party_Response, SipLegEnd

Yes

Yes

Statefull

POJO

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-flexible-alerting module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-mmtel-flexible-alerting opencloud#mmtel-flexible-alerting#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

mmtel-determine-flexible-alerting-mode

Group module for the Determine Flexible Alerting Mode feature.

mmtel-determine-flexible-alerting-mode-profile

The profile for this feature

mmtel-determine-flexible-alerting-mode-library

The common library for this module pack

mmtel-parallel-fa

The the flexible alerting parallel feature.

mmtel-sequential-fa

The the flexible alerting sequential feature.

Statistics

Name Increments when …​

ProcessingRequest

processing a request message.

ProcessingResponse

processing a response from the downstream forked legs.

InviteRequestReceived

the original INVITE is received.

CancelRequestReceived

a CANCEL message is received.

ProvisionalResponseReceived

a 1xx message is received.

SuccessResponseReceived

a 200 (OK) message is received.

BusyErrorResponseReceived

a 486 (Busy Here) message is received.

NonBusyErrorResponseReceived

a 4xx message is received that is not a 486 (Busy Here).

GroupMemberAlerted

an INVITE request is sent to a group member.

LegReleased

a dialog leg is released.

UpstreamForkCreated

the feature creates a new leg towards the calling party. It happens on the provisional responses.

TriggeredOnResponse

the feature is triggered on a response message.

TriggeredOnRequest

the feature is triggered on a request message.

TriggeredOnTimer

the feature is triggered on a timmer.

TimeoutTimerCancelled

the feature cancel the timer.

TimeoutTimerSet

the feature sets the timer. The timer is set before the INVITE is sent to the first group member.

ExitedEarlyNoMembersToAlert

there is just one member in the group and it is the pilot number.

Received480

receives a 480 (Temporarily Unavailable) response from a member

Received486

receives a 486 (Busy Here) response from a member

Received408

receives a 408 (Timeout) response from a member

Received404

receives a 404 (Not found) response from a member

ReceivedSuccess

receives a 200 (OK) response from a member

RespondedUpstreamWith480

the feature sends a 480 (Temporarily Unavailable) to the calling party.

RespondedUpstreamWith486

the feature sends a 486 (Busy Here) to the calling party.

RespondedUpstreamWith408

the feature sends a 408 (Timeout) to the calling party.

RespondedUpstreamWith404

the feature sends a 404 (Not found) to the calling party.

RespondedUpstreamWithSuccess

the feature sends a 200 (OK) to the calling party.

Interaction with other MMTel Services

CDIV Unconditional

If CDIV Unconditional is active for the Pilot Identity, CDIV Unconditional procedures will be applied and no FA group member will be alerted.

CDIV Busy

If CDIV Busy is active for the Pilot Identity, CDIV Busy procedures will be applied if the pilot number is considered busy. The definition of Busy for the pilot number depends on the group type: single-user or multiple-users. For single-user, when one member is busy the pilot number is busy, while for multiple-uses all group members have to be busy for the pilot number to be considered busy.

CDIV No Reply and CDIV Not Reachable

If the FA Pilot Number is considered in a state of No Reply or Not Reachable then the CDIV procedures for those MMTel services will be applied.

CDIV Not Logged-in

If the FA Pilot Identity has CDIV Not Registered active, the procedures for CDIV Not Registered will be applied.

MMTelOIP

OIP applied to any FA group member when OIP is active for the FA Pilot Identity.

MMTelTIP

If the FA Pilot Identity did not apply TIR, the termination identification is the FA Pilot Identity.

MMTelTIR

If the FA Pilot Identity has TIR activated, the termination identification is not presented.

MMTelICB

If the FA Pilot Identity has ICB activated, the procedures for ICB will be applied.

MMTelOCB

If any FA group member has OCB activated, the procedures for OCB will be applied for that member.

Network Operator Data

The data present in JSLEE profile table MMTelDetermineFAConfigProfileTable is used to configure the behaviour of the Parallel Flexible Alerting feature.

Variable Name Type Comments 
ParallelMaxWaitTimeout

int

Set the amount of time in milliseconds that the MMTelParallelFA feature waits before canceling the session for a pilot number.

Session Input Variables

Variable Name Type Comments 
MMTelFAServiceData

Complex

Service data read from the HSS

 
FlexibleAlertingGroupMode

Enum

Determines whether single user or multi-user Flexible Alerting is used.

Session Output Variables

Variable Name Type Comments 
SuppressCdiv

Boolean

Indicates whether response should be ignored by the MMTel CDIV feature.

 
ParallelFATimerID

int

Indicates the MMTelParallelFA timer identification.

Behaviour

The MMTelParallelFA implements the Flexible Alerting in parallel. It reads the MMTelFAServiceData session variable for the group information and issues INVITE requests towards all members in parallel using SIP parallel forking.

The INVITE request URI will have two parameters added to it.

When a member answers the call with 200 (OK) the feature cancels all other sessions towards the other members and finishes the call setup procedures between the calling party and the member that answered.

It also controls the state of the FA Pilot Identity regarding busy, not reachable and no reply states. The determination of those states, depends on the members responses and on the FA group type: single-user or multiple-users. For further information regarding the state of a Pilot Identity see Flexible Alerting.

Parallel Flexible Alerting and MMTelCDIV interaction

The CDIV feature runs before the Flexible Alerting feature on INVITE path. This way, the CFNL and CFU conditions can be applied to the Pilot Number before alerting any FA-Group member.

On the Response path, the CDIV feature runs after the Flexible Alerting feature. CDIV applies the conditions CFB, CFNR, and CFNRc based on the final response that the MMTelParallelFA feature sends to the caller. To avoid the CDIV feature being triggered on any final FA-Group members response, the MMTelParallelFA feature suppresses the CDIV feature execution by setting the session state variable SuppressCdiv. MMTelParallelFA will allow the CDIV feature to execute only after the the state of the Pilot Number is defined by receiving all members final responses or by timing out.

CDIV and MMTelParallelFA are both triggered on each other timers. This guarantees that the MMTelParallelFA feature cancels the ongoing downstream dialogs and that the CDIV feature can execute the CFNR and CFNRc conditions properly.

When the CDIV timer fires first, the MMTelParallelFA feature cancels the downstream dialogs and sends a 408 (Timeout) response towards the caller party. When CDIV executes, it will identify the 408 response and do the proper re-targeting towards the diverted subscriber.

When the MMTelParallelFA timer fires first, the MMTelParallelFA feature stops the CDIV timer and cancels the downstream dialogs and sends a 408 (Timeout) response towards the caller party. When CDIV executes, it identifies the trigger is the MMTelParallelFA timer, identifies the 408 response and do the proper re-targeting towards the diverted subscriber.

In the case when no timer has been fired, CDIV feature uses the sip response sent from the MMTelParallelFA feature to evaluate and execute the proper MMTelCDIV conditions.

HSS Subscriber Data Examples

single user group type

In the first example the Subscriber Data configures a flexible alerting group with type single-user. The group has three active members and the flexible alerting service is authorized or active.

<?xml version="1.0" encoding="UTF-8"?>
  <Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
       <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices  xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
                <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                        <identity>sip:bob@home1.opencloud.co.nz</identity>
                        <group-type>single-user</group-type>
                        <membership>permanent</membership>
                        <members>
                            <member active="true">sip:bob@home1.opencloud.co.nz</member>
                            <member active="true">sip:bobmobile@home1.opencloud.co.nz</member>
                            <member active="true">sip:bobdesk@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

multiple-users group type

The following example shows a group of multiple-users type with four members. The flexible alerting service is authorized or active.

<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"   xmlns:cp="urn:ietf:params:xml:ns:common-policy">
               <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                       <identity>sip:office@home1.opencloud.co.nz</identity>
                       <group-type>multiple-users</group-type>
                        <membership>demand</membership>
                        <members>
                            <member active="true">sip:desk1@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk2@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk3@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk4@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

MMTelSequentialFA

The MMTelSequentialFA feature implements the Flexible Alerting service, by sequentially alerting the group members.

Feature Cheat Sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Terminating

Sip_Access_Subscriber_Check, Sip_Access_Party_Request, Sip_Access_Party_Response, Sip_Access_Service_Timer, SipMidSession_Party_Request, Sip_Mid_Session_Party_Response, SipLegEnd

Yes

Yes

Stateless

POJO

Source Code

The source code for this feature is available in the Sentinel VoLTE SDK in the mmtel-flexible-alerting module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-mmtel-flexible-alerting opencloud#mmtel-flexible-alerting#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

mmtel-determine-flexible-alerting-mode

Group module for the Determine Flexible Alerting Mode feature.

mmtel-determine-flexible-alerting-mode-profile

The profile for this feature

mmtel-determine-flexible-alerting-mode-library

The common library for this module pack

mmtel-parallel-fa

The flexible alerting parallel feature.

mmtel-sequential-fa

The flexible alerting sequential feature.

Statistics

Name Increments when …​

ProcessingRequest

processing a request message.

ProcessingResponse

processing a response from a downstream forked leg.

InviteRequestReceived

the original invite is received.

CancelRequestReceived

a CANCEL message is received.

ProvisionalResponseReceived

a 1xx message is received.

SuccessResponseReceived

a 200 (OK) message is received.

GroupMemberAlerted

an INVITE message was sent to a group member.

GroupMemberAddedToQueue

a group member was queued for alerting.

MemberLegReleased

a dialog leg is released.

RespondedUpstreamManually

the feature created an upstream response.

TriggeredOnResponse

the feature is triggered on a response message.

TriggeredOnRequest

the feature is triggered on a request message.

TriggeredOnTimer

the feature is triggered on a timer event.

TriggeredOnLegEndEvent

the feature is triggered on a SIP leg end event.

AnyResponseTimerSet

the feature set a timer to wait for a response on a downstream leg.

FinalResponseTimerSet

the feature set a timer to wait for a final response on a downstream leg.

AnyResponseTimerCancelled

the timer waiting for a response on a downstream leg was cancelled.

FinalResponseTimerCancelled

the timer waiting for a final response on a downstream leg was cancelled.

TimerFired

the feature handled a timer event.

ExitedEarlyNoMembersToAlert

there is just one member in the group and it is the pilot number.

Interaction with other MMTel Services

CDIV Unconditional

If CDIV Unconditional is active for the Pilot Identity, CDIV Unconditional procedures will be applied and no group member will be alerted.

CDIV Busy

If CDIV Busy is active for the Pilot Identity, CDIV Busy procedures will be applied if the pilot number is considered busy. The definition of Busy for the pilot number depends on the group type: single-user or multiple-users. For single-user, when one member is busy the pilot number is busy, while for multiple-uses all group members have to be busy for the pilot number to be considered busy.

CDIV No Reply and CDIV Not Reachable

If the FA Pilot Number is considered in a state of No Reply or Not Reachable then the CDIV procedures for those MMTel services will be applied.

CDIV Not Logged-in

If the FA Pilot Identity has CDIV Not Registered active, the procedures for CDIV Not Registered will be applied.

MMTelOIP

OIP applied to any FA group member when OIP is active for the FA Pilot Identity.

MMTelTIP

If the FA Pilot Identity did not apply TIR, the termination identification is the FA Pilot Identity.

MMTelTIR

If the FA Pilot Identity has TIR activated, the termination identification is not presented.

MMTelICB

If the FA Pilot Identity has ICB activated, the procedures for ICB will be applied.

MMTelOCB

If any FA group member has OCB activated, the procedures for OCB will be applied for that member.

Network Operator Data

The data present in the JSLEE profile table MMTelDetermineFAConfigProfileTable is used to configure the behaviour of the Sequential Flexible Alerting Feature.

Variable Name Type Comments 
SequentialAnyResponseTimeout

int

Set the amount of time in milliseconds that the MMTelSequentialFA feature waits for a response before cancelling the dialog with that group member.

 
SequentialFinalResponseTimeout

int

Set the amount of time in milliseconds that the MMTelSequentialFA feature waits for a final response before cancelling the dialog with that group member.

Session Input Variables

Variable Name Type Comments 
MMTelFAServiceData

Complex

Service data read from the HSS

 
FlexibleAlertingGroupMode

Enum

Determines whether single user or multi-user Flexible Alerting is used.

Session Output Variables

Variable Name Type Comments 
SuppressCdiv

Boolean

Indicates whether response should be ignored by the MMTel CDIV feature.

Behaviour

The MMTelSequentialFA implements Flexible Alerting sequentially. It reads the MMTelFAServiceData session variable to get the group information and will alert each active group member one at a time, using SIP sequential forking.

The INVITE request URI will have two parameters added to it.

If a member responds with a final response other than a 200 (OK) or a timer event occurs the feature will end the dialog for that member and alert the next member in the queue. When a member answers the call with a 200 (OK) the feature will finish the call setup procedure between the calling party and the member that answered.

The feature also controls the state of the FA Pilot Identity regarding the busy, not reachable and no reply states. The determination of those states depends on the responses of the members and the FA group type: single-user multiple-users. For further information regarding the state of a Pilot Identity see Flexible Alerting.

Sequential Flexible Alerting and MMTelCDIV interaction

The CDIV feature runs before the Flexible Alerting feature on INVITE path. This way, the CFNL and CFU conditions can be applied to the pilot number before alerting any group member.

On the Response path, the CDIV feature runs after the Flexible Alerting feature. CDIV applies the conditions CFB, CFNR, and CFNRc based on the final response that the MMTelSequentialFA feature sends to the caller. To avoid the CDIV feature being triggered on any final response from a group member, the MMTelSequentialFA feature suppresses the CDIV feature execution by setting the session state variable SuppressCdiv. MMTelSequentialFA will allow the CDIV feature to execute only after the state of the pilot number is defined by receiving all members final responses or by timing out.

HSS Subscriber Data Examples

single user group type

In the first example the Subscriber Data configures a flexible alerting group with type single-user. The group has three active members and the flexible alerting service is authorized or active.

<?xml version="1.0" encoding="UTF-8"?>
  <Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
       <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices  xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
                <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                        <identity>sip:bob@home1.opencloud.co.nz</identity>
                        <group-type>single-user</group-type>
                        <membership>permanent</membership>
                        <members>
                            <member active="true">sip:bob@home1.opencloud.co.nz</member>
                            <member active="true">sip:bobmobile@home1.opencloud.co.nz</member>
                            <member active="true">sip:bobdesk@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

multiple-users group type

The following example shows a group of multiple-users type with four members. The flexible alerting service is authorized or active.

<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
    <RepositoryData>
        <ServiceIndication>MMTEL-Services</ServiceIndication>
        <SequenceNumber>1</SequenceNumber>
        <ServiceData>
            <MMTelServices xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap"   xmlns:cp="urn:ietf:params:xml:ns:common-policy">
               <complete-flexible-alerting>
                    <operator-flexible-alerting authorized="true"/>
                    <operator-flexible-alerting-group authorized="true">
                       <identity>sip:office@home1.opencloud.co.nz</identity>
                       <group-type>multiple-users</group-type>
                        <membership>demand</membership>
                        <members>
                            <member active="true">sip:desk1@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk2@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk3@home1.opencloud.co.nz</member>
                            <member active="true">sip:desk4@home1.opencloud.co.nz</member>
                        </members>
                    </operator-flexible-alerting-group>
                </complete-flexible-alerting>
            </MMTelServices>
        </ServiceData>
    </RepositoryData>
</Sh-Data>

Geo Local Normalization

The GeoLocalNormalization service adds the geo-local value to the Tel URI phone-context parameter for local numbers that should not be translated to international format.

The GeoLocalNormalization feature includes the geo-local value in case the served user is in roaming and request URI is not in international format or already contains the geo-local value. If geo-local value is added to the phone-context parameter the feature sets the session state GeoLocalNormalizationApplied to true. This value is used to suppress the SIP Normalization Feature, that is executed afterwards.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO or SBB Feature

MMTEL

Both Originating and Terminating

  • MMTel_SipAccess_SessionCheck

No

No

Reads Session State

SBB Feature

Prerequisite features

  • DetermineInitialLegNames

  • DetermineInternationalAndRoamingStatus

Session input variables

The roaming indicator is set by the DetermineInternationalAndRoamingStatus feature.

Session output variables

The session state GeoLocalNormalizationApplied.

Statistics

statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → GeoLocalNormalization
or with rhino-stats:
SLEE-Usage → [volte.sentinel.sip service name] → [volte.sentinel.sip SBB name] → .feature.GeoLocalNormalization

Name Description 
Started

Incremented each time the feature runs

 
FailedToStart

Incremented when Sentinel VoLTE encounters an error while attempting to start the feature

 
FailedDuringExecution

Incremented when a fatal error occurs during feature execution

 
IssuedWarning

Incremented when a non-fatal error occurs during feature execution

 
ContainsPhoneContext

Incremented when the requestURI contains the phone-context

 
ProcessingSipRequest

Incremented when the incoming SIP request is an INVITE

 
ProcessingSipURI

Incremented when the requestURI is a SIP URI

 
ProcessingTelURL

Incremented when the requestURI is a TelURL

Source

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-geo-local-normalization module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-geoloc-module opencloud#mmtel-geo-local-normalization#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new module, once completed the original source for the feature can be found in the new module.

Specification Reference

  • IR.65 version 12.0

  • IR.92 version 9.0

  • 3GPP TS 24.229 version 13.

Identity Presentation and Identity Restriction Features

Identity Presentation and Identity Restriction Features.

Feature What it does

implements the Originating Identification Presentation (OIP) service

implements the Originating Identification Restriction (OIR) service

implements the Terminating Identification Presentation (TIP) service

implements the Terminating Identification Restriction (TIR) service

MMTelOIP

The MMTelOIP feature implements the Originating Identification Presentation (OIP) service .

What is OIP?

From 3GPP 24.607:

The Originating Identification Presentation (OIP) service provides the terminating user with the possibility of receiving identity information in order to identify the originating user.

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

In addition to the trusted identity information, the identity information from the originating user can include identity information generated by the originating user and in general transparently transported by the network. In the particular case where the “no screening” special arrangement does not apply, the originating network shall verify the content of this user generated identity information. The terminating network cannot be responsible for the content of this user generated identity information.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Terminating

SipAccess_SubscriberPreCreditCheck

 
Yes

Yes

Stateless

POJO

Prerequisite features

These features must run before OIP:

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-id-presentation-restriction module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-idpr-module opencloud#mmtel-id-presentation-restriction#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules relevant to this feature:

Module Name Description

mmtel-id-presentation-restriction

Group module for the feature that includes all of the modules listed below.

mmtel-id-presentation-restriction-library

Contains code shared by all ID presentation and restriction features.

mmtel-oip-profile

Contains the profile specification for the feature configuration profile table.

mmtel-oip

Contains the feature itself.

Statistics

MMTelOIP statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → MMTelOIP

Name Type Description 
Started

Counter

Incremented when the feature is triggered.

 
FailedToStart

Counter

Incremented when the feature fails to start.

 
FailedDuringExecution

Counter

Incremented when the feature fails while executing.

 
IssuedWarning

Counter

Incremented when the feature issues a warning.

 
TimedOut

Counter

Incremented when the feature times out during execution.

 
Misconfigured

Counter

Incremented when a fatal error if the feature configuration can not be loaded.

 
ReceivedMalformedPrivacyHeader

Counter

Incremented when a non-standard ‘Privacy’ header is found in an incoming SIP message.

 
FromHeaderAnonymized

Counter

Incremented when the feature anonymizes the ‘From’ header in an outgoing SIP request.

 
ContactHeaderAnonymized

Counter

Incremented when the feature anonymizes the ‘Contact’ header in an outgoing SIP message.

 
ReferredByHeaderAnonymized

Counter

Incremented when the feature anonymizes the ‘Referred-By’ header in an outgoing SIP message.

 
PerformedUserLevelAnonymization

Counter

Incremented when the feature applies user-level privacy to an outgoing SIP message.

 
PerformedHeaderLevelAnonymization

Counter

Incremented when the feature applies header-level privacy to an outgoing SIP message.

 
PerformedSessionLevelAnonymization

Counter

Incremented when the feature applies session-level privacy to an outgoing SIP message.

 
PerformedCustomHeaderAnonymization

Counter

Incremented when the feature finds and evaluates custom header privacy rules for a message.

 
OverrideCategoryTriggered

Counter

Incremented when the feature disregards requested privacy settings on an incoming SIP message (due to the subscriber having override category status).

 
CriticalPrivacyCannotBeFulfilled

Counter

Incremented when the feature refuses an incoming request due to a Privacy header including both the value critical and an unrecognised value.

Network Operator Data

This data is stored in a JSLEE Configuration Profile table called MMTelOIPConfigProfileTable. The operator data is scoped according to a Sentinel selection key. In the profile table, there is one profile for each network operator.

Attribute Name Type Default Value Description 
AnonymizeFromPolicy

Enum (ANONYMIZE, DO_NOT_ANONYMIZE)

 
DO_NOT_ANONYMIZE

When set to ANONYMIZE the from header of the INVITE will always be anonymized if the OIP feature is not active for the subscriber.

 
PrivacyHeaderRemovalPolicy

Enum (USE_IETF, USE_3GPP)

 
USE_3GPP

This value is deprecated and no longer used by the feature.

 
Override

Enum (OVERRIDE_ACTIVE, OVERRIDE_NOT_ACTIVE)

 
OVERRIDE_NOT_ACTIVE

This value is deprecated and has been replaced by subscriber level data, see MMTelOIPServiceData.

 
AllowHistoryInfoDeletion

boolean

 
false

Flag to allow History-Info header deletion.

Additionally, the feature reads a second profile table that contains custom rules for removing additional headers under specified circumstances. See Custom Header Privacy Rules below.

Session input variables

Variable name Type Comments 
MMTelOIPServiceData

Complex

Session output variables

Variable name Type Comments 
RanOip

boolean

Signals to other features that OIP ran on this session.

Behaviour

If operator data is not present, the OIP feature:

  1. Increments an error statistic.

  2. Logs a message at the Fine level.

  3. Informs the Sentinel core that the feature is not configured appropriately (Invalid Configuration).

  4. Exits.

Graceful handling of originating access

As OIP is a terminating feature. It will finish execution without modifying any state if it is invoked in an originating attempt.

OIP Override Category

The OIP override category overrides OIR’s requests for privacy, and provides as much identity information as is available to the terminating party.

It is extracted from the operator data in HSS or from HLR field ClipData.OverrideCategory field in ASN.1.

Critical Privacy Request

If the incoming request includes a Privacy header with the value critical, then the OIP feature will check to ensure that it can fulfill the privacy request. If another Privacy header value is present in the request that is not recognised by the OIP feature, it will assume that it can not fulfill the privacy request and refuse the incoming request with 500 Server Internal Error. If all of the Privacy header values are recognised by the feature, then the request will be handled as per normal behaviour.

Recognised privacy header values are: header, user, session, history, id, none, critical.

SIP Header Manipulation

The primary purpose of MMTelOIP is to remove and anonymize headers that the originating UE and the OIR service requested to be removed or anonymized.

MMTelOIP Active
Table 1. SIP header manipulation when MMTelOIP is active

SIP Header [1]

Originating Subscriber’s Privacy Setting

User

Header

Session

Id

History

None [2]

Outgoing Requests to the Terminating Subscriber

Call-Info

Removed

Contact

Anonymized

From

Anonymized

History-Info [3]

Removed

Removed

Removed

In-Reply-To

Removed

Organization

Removed

Privacy

Preserved

Preserved

Preserved

Preserved

Preserved

Preserved

Reply-To

Removed

Subject

Removed

User-Agent

Removed

Outgoing Responses to the Terminating Subscriber

Call-Info

Removed

History-Info [3]

Removed

Removed

Removed

Organization

Removed

Privacy

Preserved

Preserved

Preserved

Preserved

Preserved

Preserved

Reply-To

Removed

Server

Removed

Warning

Anonymized
MMTelOIP Not Active
Table 2. SIP header manipulation when MMTelOIP is not active.

SIP Header [1]

Originating Subscriber’s Privacy Setting

User

Header

Session

Id

History

None [2]

Outgoing Requests to the Terminating Subscriber

Call-Info

Removed

Contact

Anonymized

From

Anonymized

Anonymized if the Network Operator Setting AnonymizeFromPolicy is set to ANONYMIZE

History-Info [3]

Removed

Removed

Removed

In-Reply-To

Removed

Organization

Removed

Privacy

Removed

Removed

Removed

Removed

Removed

Removed

Reply-To

Removed

Subject

Removed

User-Agent

Removed

Outgoing Responses to the Terminating Subscriber

Call-Info

Removed

History-Info [3]

Removed

Removed

Removed

Organization

Removed

Privacy

Removed

Removed

Removed

Removed

Removed

Removed

Reply-To

Removed

Server

Removed

Warning

Anonymized

Custom Header Privacy Rules

The MMTelOIP feature has support for configuring custom rules that instruct the feature to remove additional headers depending on the message type and the value of the Privacy header. These rules are defined in a profile table called MMTelCustomHeaderPrivacyRules. Alternatively, the rules can be controlled per network operator by prefixing the network operator name followed by an underscore to the profile table name (e.g. Metaswitch_MMTelCustomHeaderPrivacyRules). Each profile in the profile table represents a single rule for the feature to evaluate. The profile name is cosmetic, it can be any string. The profiles have the following fields:

Field Name Type Description 
HeaderName
 
String

The name of the header that should be removed when this rule is applied to a message.

 
ApplicableMessageTypeAsString
 
Enumeration

One of three values based on what type of message this rule should be applied to. Value must be one of: REQUEST, RESPONSE, or BOTH.

 
ApplicablePrivacyHeaderValues
 
String Array

A list of Privacy header values that will trigger this rule.
Note HeaderName matching is case-insensitive. Wildcards are not supported.
Black Listed SIP Headers

The following SIP headers can not be removed by MMTelOIP custom header privacy rules:

  • From

  • Call-ID

  • Contact

  • Content-Length

  • CSeq

  • Max-Forwards

  • Record-Route

  • Request-URI

  • Route

  • To

  • Via

Rule Evaluation

Whenever the feature is processing a message, it will look for this profile table and check if there are any rules defined. If it finds rules, it will iterate through them and evaluate each one to determine if it should be applied to the message. For each rule, the evaluation process is as follows:

1. Check the Message Type

The ApplicableMessageType field indicates what type of SIP message the rule should be applied to: REQUEST indicates the rule should be applied to SIP requests. RESPONSE indicates the rule should be applied to SIP responses. BOTH indicates the rule should be applied to all SIP messages.

2. Check the Privacy Header

The feature will look at the value(s) of the Privacy header on the message and compare them to the ApplicablePrivacyHeaderValues for the rule. If any one value of the Privacy header matches any one value in the ApplicablePrivacyHeaderValues field, the rule applies.

3. Apply Rule

If the previous two checks both indicate the rule should be applied, the feature will strip all headers from the message that match the HeaderName field of the rule.

MMTelOIR

The MMTelOIR feature implements the Originating Identification Restriction (OIR) service .

What is OIR?

From 3GPP 24.607:

The Originating Identification Restriction (OIR) service enables the originating user to prevent presentation of its identity information to the terminating user.

When the OIR service is applicable and activated, the originating network provides the destination network with the indication that the originating user’s identity information is not allowed to be presented to the terminating user. In this case, no originating user’s identity information shall be included in the requests sent to the terminating user. The presentation restriction function shall not influence the forwarding of the originating user’s identity information within the network as part of the supplementary service procedures.

Feature cheat sheet

B2BUA Instance Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Originating

 
SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

POJO

Prerequisite features

These features must run before OIR:

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-id-presentation-restriction module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-idpr-module opencloud#mmtel-id-presentation-restriction#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules relevant to this feature:

Module Name Description

mmtel-id-presentation-restriction

Group module for the feature that includes all of the modules listed below.

mmtel-id-presentation-restriction-library

Contains code shared by all ID presentation and restriction features.

mmtel-oir-profile

Contains the profile specification for the feature configuration profile table.

mmtel-oir

Contains the feature itself.

Network operator data

OIR Network Operator Data is present in a JSLEE configuration profile table named MMTelOIRConfigProfileTable. The operator data is scoped according to a Sentinel selection key. There is one profile in the profile table for each network operator.

Attribute Name Type Description 
OIRMode (deprecated, present in MMTelOIRServiceData)

An enum with two values: PERMANENT and TEMPORARY.

Fully qualified type name is com.opencloud.volte.sentinel.simservs.xcap.IdentityPresentationModeType

 
OIRPresentationRestrictionType

An enum with two values: ONLY_IDENTITY and ALL_PRIVATE_INFORMATION.

Fully qualified type name is com.opencloud.volte.sentinel.simservs.xcap.IdentityPresentationRestrictionType.

Use of ALL_PRIVATE_INFORMATION means the Privacy header is set to Privacy:header

Use of ONLY_IDENTITY means that the Privacy header is set to Privacy:id.

 
OIRUserPolicy

An enum with three values: NONE, ANONYMIZE_FROM, and ADD_USER_PRIVACY.

Fully qualified type name is com.opencloud.mmtel.sentinel.feature.common.IdentificationRestriction.UserPolicy.

Default for network operator data

Attribute Default value 
MMTelOIRServiceData.Mode
 
TEMPORARY
 
OIRPresentationRestrictionType
 
ONLY_IDENTITY
 
OIRUserPolicy
 
NONE

Session input variables

Variable name Type Comments 
MMTelOIRServiceData

Complex

Stored from the HSS or HLR in SubscriberDataLookupFromHSS or SubscriberDataLookupFromHLR

Session output variables

Variable name Type Comments 
RanOir

boolean

Signals to other features that OIR ran on this session.

Statistics

MMTelOIR statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB

Statistic Increments when…​ 
MMTelOIRFeatureStarted

the feature runs

 
MMTelOIRFeatureFailedToStart

sentinel VoLTE encounters an error while attempting to start the feature

 
MMTelOIRFeatureIssuedWarning

a non-fatal problem is encountered and the feature and issues a warning

 
MMTelOIRFeatureFailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 
MMTelOIRFeatureTimedOut

the feature takes too long to complete and Sentinel VoLTE aborts execution

 
MMTelOIRFeatureMisconfigured

a fatal error if the feature configuration can not be loaded

 
MMTelOIRFeatureReceivedMalformedPrivacyHeader

a non-standard Privacy header is found in an incoming SIP message

 
MMTelOIRFeatureFromHeaderAnonymized

the feature anonymizes the From header in an outgoing SIP message

 
MMTelOIRFeaturePrivacyHeaderChanged

the feature changes the contents of the Privacy header on an outgoing SIP message

Behaviour

If operator data is not present, the OIR feature:

  1. Increments an error statistic.

  2. Logs a message at the Fine level.

  3. Informs the Sentinel core that the feature is not configured appropriately (Invalid Configuration).

  4. Exits.

If MMTelOIRServiceData.Active is false, the feature finishes execution without modifying any state.

The rest of the behaviour section assumes that MMTelOIRServiceData.Active is true.

Temporary mode vs permanent mode

OIR behaves in temporary mode if the network configuration for MMTelOIRServiceData.Mode is set to TEMPORARY

It behaves in permanent mode if the network configuration for MMTelOIRServiceData.Mode is set to PERMANENT.

The UE signals its request for privacy through use of the Privacy header.

Adjustments to identity headers in temporary mode

When in temporary mode, the OIR feature will apply header manipulation related to privacy, based on: