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 Metaswitch Rhino installation (for example, to use clustering), it makes sense to refer to other Metaswitch 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.9.0/opencloud/volte/2.9.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 Metaswitch-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 8, update 172 or later

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.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.6.2.0 or later - optional - to be used when installing and configuring Rhino manually

Rhino 2.6.2 SDK from Artifactory

Rhino Documentation

Rhino Element Manager 2.6.2.0 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 3.11.2 or later version from the 3.11.x series. Cassandra is required for multiple functions including the SCC-AS, Rhino’s Session Ownership subsystem and the Rhino Key-value store subsystems.

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.

Know the TAS cluster DNS domain name

The TAS needs to be able to resolve its own domain name as is defined in the IMS Initial Filter Criteria. This must be resolvable on all nodes in the cluster.

DNS is expected to be configured according to DNS SRV configuration.

The TAS domain name is asked for, in the TAS cluster DNS domain name? question during the Sentinel VoLTE application installation. For example, if the Initial Filter Criteria uses the Application Server URI sip:tas-cluster.example.com;transport=tcp, then the value entered should be tas-cluster.example.com. It is recommended that this domain name is resolvable prior to installation. The value can be adjusted after installation has completed, see: SIP SIS RA Network Interface changes.

Session Replication installation checklist

Session Replication is optional and is supported through the use of various Rhino subsystems (first introduced in Rhino 2.6.1), and enhancements to various application components installed into Rhino.

Note In order to install Sentinel VoLTE with Session Replication enabled, specific answers are required during both the Rhino production installation and Sentinel VoLTE application installation.

For the Rhino installation the questions and answers are:

  1. the Session Ownership Facility question answered with value True

  2. the Replicated Storage question answered with value KeyValueDatabase

  3. the Enable remote timer support? question answered with value True

All three of these questions must be answered correctly, as they affect code generation for applications on top of Rhino. Once applications are installed, the generated code cannot change. Hence only a re-install can change these values.

During the Sentinel VoLTE application installation answer Yes to the Session Replicated Enabled question:

  1. this question changes application configuration that can be updated post installation if desired (i.e. answering Yes or No does not preclude a later configuration change to enable/disable)

Note The installer sets a SIP SIS RA configuration property (DynamicSRVNameFormat) if replication is enabled.

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. It is required if using Session Replication. If using Session Replication, read the

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

If the installation is to use Session Replication, see the Session Replication installation checklist.

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.6.1 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.6.1 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 2560m at a minimum. * 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, 640m when the HEAP_SIZE is 2560m).

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 general rule for a production setup and each project installation will require specific analysis.

Recommendations are:

  • The Rhino HEAP_SIZE setting should be set to 6144m at a minimum.

  • TieredCompilation is enabled by default in Java 8. It is recommended Sentinel VoLTE is run with a larger CodeCache. Use the JVM settings -XX:ReservedCodeCacheSize=768m and -XX:InitialCodeCacheSize=768m.

These options will need to be set in environment variables, either in 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 Metaswitch. In order to obtain a license file, please contact Metaswitch. 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

Metaswitch product dependencies

Sentinel VoLTE is built on top of other Metaswitch products. The 2.9.0 series depends on the following series:

Product Series

Rhino

2.6.1.x

REM

2.6.1.x

SIP

2.6.0.x

CGIN

2.0.0.x

SIS

2.6.1.x

SIS-EM

2.6.1.x

Diameter

3.1.1.x

IM-SSF

2.6.1.x

CDR-RA

2.3.0.x

HTTP-RA

2.4.0.x

DB-Query-RA

1.4.0.x

FSM Tool

1.2.0.x

CQL-RA

1.1.0.x

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 configures 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:

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 if you got something wrong the first time. Some of the answers can be reconfigured after installation, as described in the Changing configuration post-installation section. Finally, all questions which might be asked are described below, so that you can prepare any necessary information before performing the installation.

The install program is split into several "phases".

These are:

  • initialisation of the environment

  • question and answer (in interactive mode)

  • several opportunities to review settings (in interactive mode)

  • execution of installation

Tip 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 can be helpful when debugging issues.

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

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.

5

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.6.1/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

6

Review settings

Once the basic SDK configuration 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

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.

7

VoLTE mode

The installer will ask several questions to determine which parts of Sentinel VoLTE to deploy.

VoLTE can be deployed in four different ways: a basic developer mode, MMTel only, SCC only or both MMTel and SCC
VoLTE mode [mmtel-scc] >
Tip The installer supports tab-completion to easily select the desired mode.

The basic developer mode only includes the core Sentinel VoLTE functionality, without any of the MMTel and SCC features. This mode is intended to be a bare-bones environment suitable for development of VoLTE-based applications that do not require any of the MMTel and SCC features.

If the deployment includes SCC, the installer will ask whether to deploy the GSM or CDMA components.

VoLTE SCC can be deployed in either GSM or CDMA mode
SCC mode [gsm] >

Finally, if deploying MMTel only, the installer asks whether to deploy GSM components, so CAP charging and the SubscriberDataLookupFromHLR feature can be used.

VoLTE MMTel can optionally deploy GSM components.
Deploy GSM components? [Y]/n >

8

Review settings

Once the VoLTE mode questions have been answered, the user again gets the opportunity to review.

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


VoLTE mode
==========

  VoLTE mode: mmtel-scc
  SCC mode: gsm
  Deploy module: sentinel-volte-full-gsm-deploy

Accept these values? [Y]/n >

Configuration changes written.

9

Creation of a deployment module

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

10

International and Roaming Network Questions

Home domain >

A domain name for a home network.

Home network prefix >

A corresponding network prefix for that home domain.

Two letter ISO country code for the home network e.g 'SG'
Home network ISO country code >

The ISO country code for the home network.

Home network MCC >

The MCC for the home network

Comma separated list of home network MNCs eg 01,02
Home network MNC list >

A list of MNCs for the home network.

Note that additional networks can be specified through the Determine International and Roaming Status feature configuration profile once setup is complete. See the Changing configuration post-installation section for more details.

11

Play Announcement Questions

Media server URI [sip:annc-audio@localhost:5260;lr;transport=tcp] >

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

12

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 and the user selected a VoLTE mode containing the IM-SSF (any mode including GSM components) during the VoLTE mode step, the installer prompts for online charging options.

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 did NOT select a VoLTE mode containing the IM-SSF.

Using 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 the CAP Charging (IM-SSF) step.

13

Diameter Ro and CCA Questions (only if ro chosen during the online charging questions).

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. More details about configuring Diameter Ro manually can be found in the Diameter Resource Adaptors Guide.

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.

14

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:
[path-to-config-file]/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. More details about configuring Diameter Rf manually can be found in the Rf Control Resource Adaptor Guide.

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.

15

Call Detail Records (CDRs) (only if the VoLTE mode includes MMTel)

If Rf was enabled during the Diameter Rf step interim CDRs will be enabled implicitly.

Enabling interim CDRs implicitly due to Rf Control RA being enabled

Otherwise, an additional question will be asked regaring enabling interim CDRs. The advantages of interim CDRs are described in the Interim CDRs section.

Interim CDRs are written to disk at the Start and End of a session, as well as periodically during the lifetime of a session.
Enable interim CDRs? [Y]/n >

Regardless of whether or not interim CDRs have been enabled, the installer asks next if the user wants to enable session CDRs.

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

16

CAP Charging (IM-SSF) (only if CAP has been chosen during the Online charging questions)

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.

17

Sh Cache Microservice RA Questions

The URL for the Sh Cache Microservice.
Server URL [http://localhost:8088] >

The URL for the Sh Cache Microservice. This is what Sh Cache Microservice requests are sent to.

Whether to use a proxy server.
Proxy Enabled y/[N] >

If yes, the installer will next ask to configure the proxy server.

The hostname of the proxy server.
Proxy Host [localhost] >

Hostname of the proxy server.

The port of the proxy server.
Proxy Port [3128] >

Port of the proxy server.

18

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.

ATU-STI [sip:localhost:5060] >

The Access Transfer Update - Session Transfer Identifier.

Please enter the time (ms) to wait before we consider the ATCF update has failed
ATCF Update Timeout [2000] >

Determines how long we wait before we consider an ATCF update to have failed.

STN-SR [6421999999] >

The Session Transfer Number - Single Radio.

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 [Cassandra] >

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 contact points in the form "host1,host2"
Cassandra Contact Points [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.

19

Cassandra General Questions

Session Ownership uses Cassandra to save session information that can be shared across nodes. Other features also use Cassandra

Please enter a comma separated list of Cassandra contact points in the form "host1,host2"
Cassandra Contact Points [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.

Please enter an optional DNS domain name for the TAS cluster.  This will be set as a virtual address in the SIP SIS RA.
This name must resolve to an address, NAPTR, or SRV record on each cluster node.
Enter "none" if you do not wish to configure this option now.
Example: tas-cluster.example.com
DNS name [none] >

This should be set to the DNS domain name used in IMS Initial Filter Criteria. E.g. tas-cluster.example.com.

21

MMTel Conferencing Questions (only if the VoLTE mode includes MMTel)

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

IMCSI Configuration (only if the SCC mode is GSM and cap is chosen during the online-charging-questions

When using CAP charging and GSM, the IMCSI can be fetched from the HLR and provided to the IMSSF in the originating and/or terminating case
Enable IMCSI fetching in the originating case y/[N] >
Enable IMCSI fetching in the terminating case y/[N] >

24

CDMA HLR Configuration (only if the SCC mode is CDMA)

The following questions concern the HLR configuration. For an overview of Terminating Access Domain Selection (T-ADS) see Terminating Access Domain Selection (T-ADS) and Terminating Access Domain Selection Features.

By default SCC TADS Routing uses the CMSISDN from the HSS, but it can also be configured to use the TLDN from the HLR.
Use MSRN for SCC TADS Routing? y/[N] >

The following questions only get asked if the option above has been chosen.

The SCCP address of the HLR.
Example: type=A7,ri=pcssn,pc=1-1-1,ssn=101,national=true
HLR address [type=A7,ri=pcssn,pc=1-1-1,ssn=101,national=true] >

The SCCP address of the Sentinel VoLTE AS.
Example: type=A7,ri=pcssn,pc=1-1-2,ssn=102,national=true
Originating Sentinel address [type=A7,ri=pcssn,pc=1-1-2,ssn=102,national=true] >

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 dialog with the HLR (in milliseconds).
Invoke timeout [4000] >

The market ID value to be used in the MSCID set on outgoing CDMA requests to the HLR
Market ID [1] >

The switch number value to be used in the MSCID set on outgoing CDMA requests to the HLR
Switch Number [1] >

25

GSM HLR Configuration (only if the VoLTE mode includes the GSM components)

The following questions concern the HLR configuration. For an overview of Terminating Access Domain Selection (T-ADS) see Terminating Access Domain Selection (T-ADS) and Terminating Access Domain Selection Features.

By default SCC TADS Routing uses the CMSISDN from the HSS, but it can also be configured to use the MSRN from the HLR.
Use MSRN for SCC TADS Routing? y/[N] >

The previous question is only asked if the VoLTE mode includes SCC; the next question is asked if the the VoLTE mode includes MMTel.

The HLR can be used to try to determine the roaming status of a subscriber by sending an ATI query to it.
Determine roaming from HLR y/[N] >

The following questions only get asked if the HLR is required by answers to previous questions.

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] >

26

T-ADS Questions (only if the VoLTE mode includes SCC)

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.

27

Session Replication Questions

Session replication can be enabled for two-party MMTel and SCC calls upon receipt of the initial INVITE ACK from the calling party.
Enable session replication? y/[N] >

Answering 'yes' will enable session replication on all established two-party calls on the MMTel and SCC AS instances.

28

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
***************

... 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.

29

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, files called installer.log and installer.rhino.log are created in this directory. If there is a previous installer.log file, that it is moved to installer_date.log (and similarly for installer.rhino.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 need to populate XCAP server settings and MMTel service data. You may optionally enable XCAP authentication using Sentinel AGW.

Populate XCAP server settings and MMTel service data

There are several configuration items for the administrative User Interface (in REM) related to XCAP connectivity and MMTel service data mappings.

These include:

  • the XCAP server configuration, such as

    • Sh Cache Microservice stack configuration

    • XPaths used to map between the UE’s "simservs" document and the HSS "MMTel-Services" document

    • any extension configuration to expand the standard Simservs document

  • the REM Web UI for viewing and editing Transparent Data in the HSS, such as

    • the MMTel-Services document (for example Communication Diversion, Communication Barring etc)

    • the IMS-ODB-Information document used for Operator Determined Barring

This can either be done manually following the admin guide, or more easily using the script sentinel-volte-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.

-s (--serverurl-shcm)

The URL for the Sh Cache Microservice

Optional Arguments

What it specifies

-sph (--shcm-proxy-host)

The proxy host used to connect to the Sh Cache Microservice

-sph (--shcm-proxy-port)

The proxy port used to connect to the Sh Cache Microservice

-x (--xcap-mapping)

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/sentinel-volte-mappings-config -u emadm -pw password -h localhost -p 8080 -r Local -n OpenCloud -s http://localhost:8088/shcache/v1
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

Rhino SAS Configuration

To enable Rhino to send events to MetaView Service Assurance Server (SAS), refer to Enabling VoLTE SAS tracing

Provision Location Based Dialling Data

Tools are provided to provision and verify data mappings for the LocationBasedDialling feature.

lbd-provision and ldb-verify are located in the build/bin directory of the Sentinel VoLTE SDK.

lbd-provision

This tool takes a .csv file as input and populates the location_based_dialling_data_3gpp table in Cassandra with the data.

Mandatory Arguments What it specifies
-c

Comma separated list of Cassandra contact points.

Optional Arguments

What it specifies

-p

Cassandra port (defaults to 9042 if omitted).

-f

Input CSV file.

-d

Dryrun, no data in Cassandra will be modified.

-i

Reset, Cassandra data will be overwritten with input file.

-b

Rollback, second most recent stored data will be restored.

-h

Help

The input CSV file must be comma separated with no header row. Each line should be in the following format <cell-id>,<dialled-number>,<destination-number>. Whitespaces and empty lines are ignored. Valid characters for dialled-number and destination-number entries are: 0-9, #, and *.

lbd-provision will fetch the existing data in cassandra and perform a diff with the content of the input CSV file. New entries in the input file not present in the database are added. Current entries not in the input file are removed. If the -i option is used, all data is overwritten with the content of the input file.

Each time lbd-provision is run the dataset is stored in the location_based_dialling_uploaded_files table. The -b option can be used to rollback to the previous data set. The location_based_dialling_uploaded_files table has to have been loaded with previous runs of lbd-provision before rollback can be used. If -b is run twice, the original record set is returned, so effectively it toggles between the current and previous data sets. If the -b option is not used, -f must be provided.

Here is an example:

$ cat lbd-provision-test-data.csv
testdata0,717,4165550000
testdata1,718,4165550001
testdata2,719,4165550002
$
$ ./lbd-provision -c localhost -f lbd-provision-test-data.csv -i
Saving Cassandra contact points: localhost
Saving input file: /home/ubuntu/lbd-provision-test-data.csv
Setting reset flag
Connected to Cassandra
Sorted file to: /home/ubuntu/work/input-sorted.csv
Processing input file to update Cassandra: /home/ubuntu/work/input-sorted.csv
Creating entry: testdata0,717,4165550000
Creating entry: testdata1,718,4165550001
Creating entry: testdata2,719,4165550002
Removing all data from table: location_based_dialling_data_3gpp
Creating data in: location_based_dialling_data_3gpp
Updated Cassandra with entire input file
Not deleting old rows as less than 3 files saved

SUCCESS
Note The lbd-provisioning tool can provision up to 5 million rows. Functionality beyond this number of rows is not supported.

lbd-verify

This tool queries the existing data in Cassandra and the Vertical Service Code profiles in Rhino and checks that each entry exists in both places.

Mandatory Arguments What it specifies
-c

Comma separated list of Cassandra contact points.

-r

Rhino client directory.

Optional Arguments

What it specifies

-p

Cassandra port (defaults to 9042 if omitted).

-h

Help

Here is an example:

$ ./lbd-verify -c localhost -r RhinoSDK/client
Saving Cassandra contact points: localhost
Saving rhino client: /home/ubuntu/RhinoSDK/client
Connected to Cassandra
Found dialled number: 717
Found dialled number: 718
Found dialled number: 719
Found platformOperator: Metaswitch
Found address: 718
Found address: 717
Found address: 719

SUCCESS: All data in Cassandra and profiles matches

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

Changing configuration post-installation

On this page we explain how the answers given to the various questions asked by the installer affect the configuration of the Sentinel VoLTE SDK, and how this configuration can be changed without reinstalling the Sentinel VoLTE SDK.

Where changes to profile tables do not specify an explicit profile, the change is made to the profile ${platform.operator.name}::::.

Please note that some parts of the installer do not require user input, hence some of the sections below do not appear in the installer.

Basic SDK questions

Property file changes

The following values are written to sdk.properties, based on the answers given to their respective questions:

  • sdk.component.vendor,

  • sdk.component.version,

  • sdk.platform.operator.name,

  • sdk.ivy.org, and

  • sdk.ivy.publish.revision.

Notes

These values are used in various places throughout the remainder of the installer (e.g. when determining profile names). It is therefore not recommended to change any of these values.

Rhino

Property file changes

The following values are written to sdk.properties:

  • client.home is set to the configured Rhino client directory, and

  • rhino.home is set to the parent directory of the configured Rhino client directory.

Notes

These values can be changed after installation.

If using the Sentinel VoLTE SDK installer to install Rhino automatically, Rhino uses the supplied license file.

The Rhino node setup is used later during the installation.

Deploy module

Configuration profile changes

Many, see notes.

Notes

This question determines which features are deployed (this always includes the core features, and can include MMTel and SCC features) and whether the GSM or CDMA features are deployed. Only the chosen features, with their configurations, are deployed. This setting cannot be changed without a reinstall of the Sentinel VoLTE SDK.

Determine international and roaming status

Configuration profile changes

The installer create two profiles, one named DEFAULT and one named after the home network MCC, in:

  • ${platform.operator.name}_DetermineInternationalAndRoamingStatus_AddressListEntryTable, and

  • ${platform.operator.name}_DetermineInternationalAndRoamingStatus_AddressListConfigurationTable.

These profiles are initialised using the configured home network prefix and home network MCC.

Furthermore, it sets the following values in the SipSentinelConfigurationTable profile table:

  • HomeNetworkIDs is set to the home domain,

  • HomeCountryCodeIDs is set to the home network prefix,

  • MCC is set to the home network MCC, and

  • MNCs is set to the home network MNC list.

Finally, the NormalizationFeatureConfigProfileTable is updated as follows:

  • CountryCode is set to the configured home network prefix.

Notes

All values can be changed after installation. Furthermore, more profiles can be added to ${platform.operator.name}_DetermineInternationalAndRoamingStatus_AddressListEntryTable and ${platform.operator.name}_DetermineInternationalAndRoamingStatus_AddressListConfigurationTable, using the installer-created profiles as a prototype.

Play announcements

Configuration profile changes

The installer sets MediaServerURI in the SipAnnouncementResourceProfileTable to the supplied media server URI.

Notes

The media server URI can be changed after installation.

Online charging

Configuration profile changes

If using Diameter Ro online charging, the DestinationRealm in the DiameterMediationOcsConfigurationTable is set to the value chosen for the destination realm during the Diameter configuration.

Resource adaptor configuration changes

If not using Diameter Ro online charging, the diameterro-0 resource adaptor is deactivated.

Notes

The online charging mode can be changed after installation, if the new charging mode is manually configured as detailed below.

Diameter (RO & CCA)

Configuration profile changes

The installer sets Host in the DiameterConfig profile table to the supplied host.

If using the installer to set up a simple configuration, all profiles in the DiameterConfig profile table, except the default profile (the nameless profile), are updated as follows:

  • PeerTable is updated using the supplied peer URI and address,

  • Realm is set to the configured realm name, and

  • RealmTable is updated using the supplied realm name and peer URI.

If setting up a simple configuration, and deploying against a production Rhino (as configured in the Rhino step), we additionally set in the same profiles:

  • EnableMultiNodeConfig is set to the EnableMultiNodeConfig value of the DiameterRoOcsProfile (default false),)

  • NodeIDs is set using the node configuration from the Rhino step, and

  • PerNodeHosts is set using the node configuration from the Rhino step.

Finally, the installer sets DisableCharging in the DetermineChargingConfigProfileTable to false exactly if Diameter Ro online charging was selected in the Online charging step.

Resource adaptor configuration changes

The field 3GPPVersion in the diameterro-0 resource adaptor configuration is set to the configured version.

If Session Replication is enabled, the following diameterro-0 resource adaptor configuration properties are adjusted:

  • ReplicateActivities is set to true

  • ReplicateByDefault is set to false

Notes

The configuration can be changed after installation.

Diameter Rf

Configuration profile changes

The installer sets host in the client profile of the RfControlDiameterConfiguration table to the supplied host.

If using the installer to set up a simple configuration, all profiles in the RfControlDiameterConfiguration profile table are updated as follows:

  • PeerTable is updated using the supplied peer URI and address,

  • Realm is set to the configured realm name, and

  • RealmTable is updated using the supplied realm name and peer URI.

Resource adaptor configuration changes

The rf-control-ra resource adaptor configuration is updated as followed:

  • 3GPPVersion is set to the configured version.

Additionally, if using the installer to set up a simple configuration:

  • DestinationHost is set to the peer host, and

  • DestinationRealm is set to the realm name.

Finally, if not using Diameter Rf, the rf-control-ra resource adaptor is deactivated.

Notes

The configuration can be changed after installation. If enabling Diameter Rf after installation, please also make the required changes in the Call detail records (CDRs) step.

Call detail records (CDRs)

Configuration profile changes

The installer makes the following changes in the DetermineChargingConfigProfileTable profile table:

  • InterimCdrsEnabled is set to true exactly if interim CDRs have been enabled, and

  • SessionCdrsEnabled is set to true exactly if session CDRs have been enabled.

Similarly, the installer makes the following changes to all profiles in the SipInterimCdrProfileTable profile table:

  • UseCdrRa is set to true exactly if interim CDRs have been enabled, and

  • UseRfControlRa is set to true exactly if Diameter Rf has been enabled in the Diameter Rf step.

Notes

These values can be changed after installation, keeping in mind that interim CDRs should be enabled if Diameter Rf is enabled.

CAP charging (IM-SSF)

Property file changes

The properties file imssf-install.properties is updated as follows:

  • imssf.countrycode is set to the supplied country code, and

  • imssf.default.mediaserver.address is set to the supplied default media server address.

Notes

These values can be changed after installation as detailed in the IM-SSF documentation.

Sh Cache Microservice RA

Configuration profile changes

The following values are set in the sh-cache-microservice-ra resource adaptor configuration:

  • serverURL is set to the URL for the Sh Cache Microservice

  • proxy.enabled is set to true if a proxy has been enabled, and

  • proxy.host and proxy.port are set to the configured proxy values (if enabled).

Notes

DestinationRealm can be changed after installation, but changing DestinationHost is not recommended.

Sentinel registrar

Configuration profile changes

The installer sets the following values in the RegistrarConfigurationTable profile table:

  • AtuSti is set to the configured ATU-STI,

  • AtcfUpdateTimeout is set to the configured ATCF update timeout,

  • StnSr is set to the configured STN-SR, and

  • SubscriberDataFacadeType is set to the chosen registration data storage type.

Additionally it will set one value on the VolteServiceConfigProfileTable profile table:

  • RegistrationDataSource will be set to either HSS or CASSANDRA.

Furthermore, a prototype profile ${platform.operator.name}:::::101 is created in the same profile table, with a single entry:

  • AtuSti is set to the configured ATU-STI.

Resource adaptor configuration changes

If Cassandra has been chosen for the registration data storage, the installer enables the cassandra resource adaptor, and sets the following values in the cassandra-third-party-reg resource adaptor configuration:

  • cassandraContactPoints is set to the configured Cassandra contact points, and

  • policy.protocol.port is set to the configured Cassandra port.

If Cassandra has not been chosen for the registration data storage, the installer disables the cassandra-third-party-reg resource adaptor.

Notes

It is not recommended to change the data storage type after installation. However, the details for the chosen storage type can be altered. Furthermore, the ${platform.operator.name}:::::101 profile can be used as a prototype for adding additional nodes.

Cassandra

Resource adaptor configuration changes

The installer sets the following values in the cassandra-general resource adaptor configuration:

  • cassandraContactPoints is set to the configured Cassandra contact points, and

  • policy.protocol.port is set to the configured Cassandra port.

Notes

These values can be changed after installation.

SIP SIS RA

Resource adaptor configuration properties

The sis-sip-ra entity has the following properties set:

  • RFC3263:failover_enabled is set to true

  • RFC3263:failover_timer is set to 10000

  • RFC3263:blacklist_timer is set to 300000

Network Interface changes

The DNS domain name specified during installation will be set:

  • in the VirtualAddresses configuration property for the network interface (named sip-sis-ra-default) of the sip-sis-ra resource adaptor entity.

Additionally, if session replication was specified during installation, the Dynamic SRV Name format will be set:

  • in the DynamicSRVNameFormat configuration property for the network interface (named sip-sis-ra-default) of the sip-sis-ra resource adaptor entity

    • If the TAS domain name is tas.example.com then this is set to the value node-${ip}.tas.example.com.

If the Dynamic SRV Name was not specified at installation time, this resource adaptor entity configuration property will be left blank.

Configuration file changes

The installer records the configured SIP SIS RA hostname in the IPAddress property in sentinel-volte-base-service-components/config.ant.xml.

Notes

Please see the SIP Resource Adaptor documentation for more information about changing the RFC 3263 settings.

Further information on the use of the DNS domain name is available in Non-sharded DNS configuration and SIP default network interface settings.

MMTel conferencing

Configuration profile changes

The installer sets the following values in the MMTelCONFConfigProfileTable profile table:

  • ICSCFURI is set to the configured conference I-CSCF URI,

  • MRFURI is set to the configured MRF URI, and

  • ConfFactoryPSI is set to the configured conference factory PSI.

Furthermore, it sets the following values in the MMTelECTConfigProfileTable profile table:

  • ICSCFURI is set to the configured ECT I-CSCF URI.

It also sets the following values in the SccConfHandlingConfigProfileTable profile table:

  • ConfFactoryPSI is set to the configured conference factory PSI.

Finally, it updates the SentinelMapperSetEntryTable to use the mappers corresponding to the configured MSML vendor.

Notes

These values cannot be changed after installation.

Enable HSS IMS-ODB-Information query

Configuration profile changes

In the IMS-ODB-Information profile of the ${platform.operator.name}_SubscriberDataLookupFromHss2ServiceIndicationProfileTable profile table, DisableQuery is set to true exactly if the HSS query for IMS-ODB-Information has been disabled.

Notes

These values can be changed after installation.

IMCSI Configuration

Configuration profile changes

This step only makes any changes if installing a GSM deploy, and using CAP for online charging. If so the installer sets the following values in the FetchIMCSIConfigProfileTable profile table:

  • FetchImcsiEnabledOnOrigCall determines if the IMCSI should be fetched for originating calls

  • FetchImcsiEnabledOnTermCall determines if the IMCSI should be fetched for terminating calls

Notes

These values can be changed after installation.

Correlation RA

Configuration profile changes

The default profiles (i.e. the profiles without a name) in both the ReoriginationCorrelationIdPools and EtcAriCorrelationIdPools tables are updated in the following way:

  • NodeIds is set using the node configuration from the Rhino step, and

  • PreconfiguredCorrelationIdSet is set using the node configuration from the Rhino step.

Notes

These values can be changed after installation.

CDMA HLR

Configuration profile changes

This step only makes any changes if installing a CDMA deploy, and using TLDN for SCC TADS routing. If so, the installer first makes the following change in VolteServiceConfigProfileTable:

  • RetrieveTLDN is set to true.

Next the installer sets the following values in the CDMAHLRConfigProfileTable profile table:

  • HLRSccpAddressAsString is set to the configured HLR Address,

  • SentinelSccpAddressAsString is set to the configured originating Sentinel address,

  • HLRInvokeTimeout is set to the configured invoke timeout,

  • MarketID is set to the configured market ID, and

  • SwitchNumber is set to the configured switch number.

Notes

The values in CDMAHLRConfigProfileTable can be changed after installation.

HLR GSM

Configuration profile changes

This step only makes any changes if installing a GSM deploy, and using either the MSRN from the HLR for SCC TADS routing, or determining roaming from HLR.

If using the MSRN from the HLR, the installer first makes the following change in VolteServiceConfigProfileTable:

  • RetrieveMSRN is set to true.

If determining roaming from HLR, the installer makes another change in VolteServiceConfigProfileTable:

  • RetrieveHLRRoamingStatus is set to true.

Next the installer sets the following values in the HLRConfigProfileTable profile table:

  • HLRSccpAddressAsString is set to the configured HLR Address,

  • SentinelSccpAddressAsString is set to the configured originating Sentinel address,

  • SentinelSccpMscEndpointAddressAsString is set to the configured originating Sentinel address,

  • SentinelAddressStringAsString is set to the configured MLC address, and

  • HLRInvokeTimeout is set to the configured invoke timeout.

Notes

The values in HLRConfigProfileTable can be changed after installation.

TADS

Configuration profile changes

If configured to allow WLAN access, the following profiles are added to the SCCTADSNetworkTypeConfigProfileTable:

  • ${platform.operator.name}:::::0

    • NetworkType: 0

    • Description: RAT value 0 = WLAN from TS 29.212 section 5.3.31

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::3GPP-WLAN

    • NetworkType: 3GPP-WLAN

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::IEEE-802.11

    • NetworkType: IEEE-802.11

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::IEEE-802.11A

    • NetworkType: IEEE-802.11A

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::IEEE-802.11B

    • NetworkType: IEEE-802.11B

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::IEEE-802.11G

    • NetworkType: IEEE-802.11G

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

  • ${platform.operator.name}:::::IEEE-802.11N

    • NetworkType: IEEE-802.11N

    • Description: P-Access-Network-Info value from TS 24.229 section 7.2A.4

    • TerminatingDomain: PS=WLAN

Notes

This setting can be changed after installation by adding or removing the profiles.

Installing the Sentinel VoLTE Provisioning Module

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

It requires REM 2.6.1 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 sentinel-volte-element-manager-<version>.em.jar into rem_home/plugins.

cd apache-tomcat-<version>
cp /full/path/to/sentinel-volte-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

Edit log4j2.properties and append the following content:

# additional lines to add to the rem.war log4j2.properties file

# the XCAP server only logs when user traffic arrives
# per-request logging is at debug level
logger.xcapserver.name=xcapserver
logger.xcapserver.level=DEBUG

# the diameter stack in the XCAP Server - logs regardless of user traffic
logger.xcapdiameter.name=xcapserver.diameter
logger.xcapdiameter.level=INFO

# transport level logging from the XCAP Server's diameter stack
# set to DEBUG for interoperability diagnostics
logger.xcapdiametertransport.name=xcapserver.diameter.transport
logger.xcapdiametertransport.level=INFO

# part of the XCAP server logging
logger.remxcap.name=rem.server.sentinel.xcap
logger.remxcap.level=DEBUG

# a rolling audit file of Sentinel EM plugin audit logging
appender.sentinelaudit.type=RollingFile
appender.sentinelaudit.name=AUDIT
appender.sentinelaudit.fileName=${sys:catalina.base}/logs/sentinel-audit.log
appender.sentinelaudit.filePattern = ${sys:catalina.base}/logs/sentinel-audit.log.%i
appender.sentinelaudit.policies.type = Policies
appender.sentinelaudit.policies.size.type = SizeBasedTriggeringPolicy
appender.sentinelaudit.policies.size.size=10MB
appender.sentinelaudit.strategy.type = DefaultRolloverStrategy
appender.sentinelaudit.strategy.max = 10
appender.sentinelaudit.layout.type=PatternLayout
appender.sentinelaudit.layout.pattern="%d{yyyy-MM-dd HH:mm:ss,SSS}", "%c{1}", %m{nolookups}%n

# send Sentinel EM plugin audit logging to the AUDIT appender, only
logger.sentinelaudit.name=sentinel.audit
logger.sentinelaudit.level=INFO
logger.sentinelaudit.appenderRef.file.ref=AUDIT
logger.sentinelaudit.additivity=false

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.

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

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

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

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.

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 and/or Diameter Accounting Requests (ACRs) throughout the session.

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

schedules configurable announcements to the subscriber based on Credit-Control-Answers

updates session state when a session’s held status changes

This feature gathers the information required to allow the session tracking system to be used for access transfer procedures.

retrieves CAMEL Subscription Information (CSI) from the HLR for charging purposes

adds proprietary SIP headers to outbound INVITE requests to allow CAP charging of the session.

loads service configuration out of a profile and into session state.

Access Leg Tracking

This feature gathers the information required to allow the session tracking system to be used for access transfer procedures.

Feature Cheat Sheet

Feature Script Name

AccessLegTracking

MMTel or SCC

Both

Call-Type

All

Session Plan

MMTel, SCC, SCC-Term-Anchor

Execution Point

SipAccess_SubscriberCheck, SipAccess_PartyResponse, SipAccess_PartyRequest, SipMidSession_PartyRequest, SipMidSession_PartyResponse

Network Operator Config

None

Subscriber Config

None

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

No

Related features

Feature Statistics

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

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.

TrackingDataOnInitialInvite

Counter

Incremented when the feature updates tracked data due to an initial INVITE.

TrackingDataOnProvisionalResponse

Counter

Incremented when the feature updates tracked data due to a provisional response to the initial INVITE.

TrackingDataOnAck

Counter

Incremented when the feature updates tracked data due to the ACK for the initial INVITE.

TrackingDataOnHoldStatusChange

Counter

Incremented when the feature updates tracked data due to a change in the hold status of a session.

Behaviour

This feature uses the Sentinel SIP Leg API to provide information to the ExternalSessionTracking feature. This allows the Session Ownership Facility to be used for tracking sessions for the purposes of access transfer.

The feature passes through four phases during session processing. Each phase is associated with a particular point in the session plan. At each phase the feature updates different sets of data.

Tracked Data

There are several sets of data that the feature maintains in the session tracking system. Different sets are updated at different times based on where in the session plan the feature is running. The data sets are:

  • Basic Tracking Data

  • Call Setup Data

  • Media State Data

The following sections outline each piece of information that is handled by this feature, and which of the above sets each belongs to.

Tracking Enabled
Data Set Leg API Field

Basic Tracking Data

TrackingEnabled

Flags a leg for tracking be the External Session Tracking feature. The Access Leg Tracking feature will set it to true for all access legs.

WaitForTrackingResultEnabled
Data Set Leg API Field

Basic Tracking Data

WaitForTrackingResultEnabled

Flag that indicates to the External Session Tracking feature that it should wait for the result of any session ownership facility operations relating to this leg before allowing the session to proceed. The Access Leg Tracking feature will set this flag to true for all access legs. This is done to ensure access transfer is prepared to run before the session is allowed to continue.

Owner
Data Set Leg API Field

Basic Tracking Data

Owner

URI of the node that currently owns the session. The feature will always ensure this matches the URI of the node it’s running on.

Additional Tracking Keys
Data Set Leg API Field

Basic Tracking Data

AdditionalTrackingKeys

These are alternative keys (i.e. keys besides the leg’s dialog ID) that can be used to retrieve tracking data for a leg. The feature retrieves these keys from the AccessLegTrackingKeys session state field. The keys present in this session state field are set by various VoLTE features that make use of access leg tracking.

Dialog State
Data Set Leg API Field

Basic Tracking Data

AdditionalTrackedAttributes (with attribute key: dialog-state)

This field describes the current state of the leg. The current dialog state is determined first by how far through call setup the leg is, and once call setup is complete, by whether the call is held or not (as determined by the Detect Hold Resume feature). The field will have one of the following values:

  • PARTIAL_DIALOG

  • PRE_ALERTING

  • ALERTING

  • ACTIVE

  • HELD

Media Feature Tags
Data Set Leg API Field

Call Setup Data

AdditionalTrackedAttributes (with attribute key: media-feature-tags)

These are the media feature tags that have been seen on this session. They are retrieved from the contact header of the initial INVITE for originating access legs, and the initial INVITE response for terminating access legs.

Associated Dialog ID
Data Set Leg API Field

Call Setup Data

AdditionalTrackedAttributes (with attribute key: associated-dialog)

This is the dialog ID of the leg currently linked to the access leg.

Last Active Time
Data Set Leg API Field

Media State Data

AdditionalTrackedAttributes (with attribute key: last-active-time)

This is the timestamp for the last time the session entered the active state (i.e. the time the ACK was received, or the last time the call was resumed after being held).

Last Held Time
Data Set Leg API Field

Media State Data

AdditionalTrackedAttributes (with attribute key: last-held-time)

This is the timestamp for the last time the session entered the held state.

Committed SDP
Data Set Leg API Field

Media State Data

AdditionalTrackedAttributes (with attribute key: committed-sdp)

This is the current negotiated SDP in use on the access leg.

Committed SDP Timestamp
Data Set Leg API Field

Media State Data

AdditionalTrackedAttributes (with attribute key: committed-sdp-timestamp)

This is the time at which the current committed SDP on the access leg was accepted.

Feature Phases

The four phases the feature passes through are:

  • Initial Request Processing

  • INVITE Response Processing

  • ACK Processing

  • Mid-Session Message Processing

Once any type of access transfer has been executed on a session, this feature will no longer attempt to maintain access leg information, and will always end without executing any phase.

Initial Request Processing

Execution Point: SipAccess_SubscriberCheck

This phase is only executed on originating AS instances, and only on the initial INVITE request. This means that the access leg will always be the leg the INVITE was received on, and there will never be any forked access legs.

The feature will skip this phase if the PartialDialogAccessLegTrackingActive session state field is false. This session state field is set by the SCCDetermineExternalSessionTracking feature, based on the presence of a g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag on the INVITE request.

In this phase:

  • The feature will record the media-feature tags present on the initial INVITE.

  • The feature will set the dialog state to PARTIAL_DIALOG.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

INVITE Response Processing

Execution Point: SipAccess_PartyResponse

This phase is executed when the feature receives a provisional response for the initial INVITE request. On terminating AS instances the leg the response is received on is the access leg, and on originating AS instances the leg the response will be forwarded on is the access leg. The access leg may be forked during this phase, so multiple legs could be tracked in a single session at this time.

In this phase:

  • The feature will record the media-feature tags present on the response if the AS is a terminating instance.

  • The feature will set the dialog state to PRE_ALERTING or ALERTING based on whether a 180 Ringing response has been received.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

ACK Processing

Execution Point: SipAccess_PartyRequest

This phase is executed when the feature receives a ACK request for the initial INVITE 2xx response. On originating AS instances the leg the ACK is received on is the access leg, and on terminating AS instances the leg the ACK will be forwarded on is the access leg. Any forked access legs will have ended by the time this message is received, so there will only be one access leg in this phase. The ExternalSessionTracking feature will have automatically cleaned up tracked data for these forks.

In this phase:

  • The feature will record the last active time for the call as now.

  • The feature will set the dialog state to HELD (very unlikely) or ACTIVE based on the hold status of the call.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

  • Media State Data will be updated.

Mid-Session Message Processing

Execution Points: SipMidSession_PartyRequest and SipMidSession_PartyResponse

This phase is executed on receipt of any message after call setup that results in a change to the hold status of the call. The access leg is determined by looking up its name from the CurrentLocalLegName session state field.

In this phase:

  • The feature will set the dialog state to HELD or ACTIVE based on the hold status of the call.

  • Basic Tracking Data will be updated.

  • Media State Data will be updated.

VoLTE Load Service Config

This feature loads service configuration out of a profile and into session state.

Feature Cheat Sheet

Feature Script Name

VolteLoadServiceConfig

MMTel or SCC

Both

Call-Type

All

Session Plan

All

Execution Point

SipAccess_SessionAccept (SIP), DirectAccess_SessionAccept (SS7)

Network Operator Config

Yes

Subscriber Config

None

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

No

Feature Statistics

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

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.

ConfigLoaded

Counter

Incremented when the feature successfully loads configuration data into session state.

Session Input Variables

Variable name Type Comments

SentinelSelectionKey

SentinelSelectionKey

Used to select which profile to load from the configuration table.

Session Output Variables

Variable name Type Comments

RetrieveMSRN

boolean

Determines whether the service will attempt to retrieve an MSRN from the HLR when required.

RetrieveTLDN

boolean

Determines whether the service will attempt to retrieve a TLDN from the HLR when required.

RetrieveHLRRoamingStatus

boolean

Determines whether the service will attempt to determine the subscriber’s roaming status from the HLR when required.

RegistrationDataSource

RegistrationDataSource (enum)

Determines where the service will attempt to retrieve third party registration data from. Possible values are HSS and CASSANDRA.

SubscriberDataSource

SubscriberDataSource (enum)

Determines where the service will attempt to retrieve subscriber data from. Possible values are HSS and HLR.

Configuration

Network configuration is stored in a profile table named VolteServiceConfigProfileTable. Profiles in this table are scoped on Sentinel Selection Key.

Warning Directly modifying values in this profile is not recommended, they should instead be set through the Sentinel VoLTE installer. See Installing Sentinel VoLTE Services and Changing configuration post-installation.
Attribute Type Default Value Description

RetrieveMSRN

boolean

false

Determines whether the service will attempt to retrieve an MSRN from the HLR when required.

RetrieveTLDN

boolean

false

Determines whether the service will attempt to retrieve a TLDN from the HLR when required.

RetrieveHLRRoamingStatus

boolean

false

Determines whether the service will attempt to determine the subscriber’s roaming status from the HLR when required.

RegistrationDataSource

RegistrationDataSource (enum)

CASSANDRA

Determines where the service will attempt to retrieve third party registration data from. Possible values are HSS and CASSANDRA.

SubscriberDataSource

SubscriberDataSource (enum)

HSS

Determines where the service will attempt to retrieve subscriber data from. Possible values are HSS and HLR.

Behaviour

When triggered this feature will attempt to retrieve a profile from the VolteServiceConfigProfileTable using the current Sentinel Selection Key. If it successfully finds a profile it will copy each attribute on the profile into its corresponding session state field. If it fails to find a profile it will raise a configuration error.

DetectHoldResume

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

Feature cheat sheet

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

SCC

No

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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → DetectHoldResume
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.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.

CapLocationHeaders

The CapLocationHeaders feature adds proprietary SIP headers to outbound INVITE requests to allow CAP charging of the session.

The OC-Charging-GT header contains the location of the subscriber to allow roaming to be correctly charged.

The OC-IM-TDP header contains the location of the SCP that IMSSF should send charging requests to.

Feature cheat sheet

Feature Script Name

CapLocationHeaders

MMTel or SCC

Both

Call-Type

Orig or Term

Session Plan

mmtel-orig, scc-tads-only

Execution Points

SipAccess_SubscriberCheck

Network Operator Config

Yes

Subscriber Config

No

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

Yes

RA Entity Links

None

Network Operator Data

The CapLocationHeaders feature depends on configuration in the CapChargingConfigProfileTable to specify how to generate the OC-Charging-GT header.

CapChargingConfigProfileTable

Configuration is stored on a profile table called CapChargingConfigProfileTable.

Data is scoped according to a Sentinel selection key.

Attribute Name Type Default Description
ChargingGTFormatString

String

null

The format template to use when creating Charging GTs. It must be a digit string except for tokens ('{iso}', '{mcc}', '{mnc}) which are substituted in.

UnknownLocationChargingGT

String

null

The Charging GT to use when one could not be generated because the user’s location could not be determined.

OnlyChargeTerminatingCallsIfInternationalRoaming

boolean

false

When true, terminating calls will only be charged if the served user is roaming outside of their home country.

Session Input Variables

Variable name Type Comments

ChargeMode

Enum

The feature will only run if the charge mode is CAP.

SentinelSelectionKey

SentinelSelectionKey

Affects which profiles are loaded from each configuration table.

CallType

Enum

Affects whether CAP headers are added and what values are used for them.

RoamingStatus

Enum

If the call is terminating and not roaming, no headers are added.

VLRNumber

AddressString

If the call is CS terminating then the VLRNumber is used for the OC-Charging-GT.

VMSCAddress

AddressString

If the call is CS terminating and there is no VLRNumber available then the VMSCAddress is used for the OC-Charging-GT.

OcImTdpHeader

String

The value to use for the OC-IM-TDP header.

IsoCountryCode

String

The ISO country code that the subscriber is registered with. It is used for formatting the OC-Charging-GT header.

PaniMccMncs

List<MccMnc>

The MCCs and MNCs that the subscriber is registered with. They are used for formatting the OC-Charging-GT header.

Statistics

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

Statistic

Type

Description

Started

Counter

Incremented when the feature is invoked.

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.

CapLocationHeadersNotRequired

Counter

Incremented when the feature determines that no CAP location headers need to be added.

UsedVlrNumber

Counter

Incremented when the VLR number is used for the OC-Charging-GT header.

UsedVmscNumber

Counter

Incremented when the VMSC address is used for the OC-Charging-GT header.

NoVlrOrVmscNumberFound

Counter

Incremented when no VLR number and no VMSC address could be found.

UsedGeneratedChargingGT

Counter

Incremented when a generated Charging GT is used for the OC-Charging-GT header.

UsedUnknownLocationChargingGT

Counter

Incremented when the unknown location Charging GT is used for the OC-Charging-GT header.

SetOCIMTDP

Counter

Incremented when an OC-IM-TDP header is set on an outgoing request.

SetOCChargingGT

Counter

Incremented when an OC-Charging-GT header is set on an outgoing request.

Installation

CapLocationHeaders is a GSM only feature and as such will only be deployed if GSM mode is selected in the installer.

Behaviour

The behaviour varies depending on whether the call is terminating or not.

Originating Behaviour

The feature attempts to generate a Charging GT using the ChargingGTFormatString and sets the OC-Charging-GT with this. If this fails, the feature uses the UnknownLocationChargingGT for the OC-Charging-GT header.

The feature sets the OC-IM-TDP header to the value stored in session state by the FetchIMCSI feature.

Terminating Behaviour

If the subscriber is not roaming the feature will check the OnlyChargeTerminatingCallsIfInternationalRoaming configuration value to determine whether it should do anything.

If the call is forked then the following occurs for each outgoing forked leg.

If the outgoing leg is CS then the feature attempts to set the OC-Charging-GT to the VLR Number retrieved by FetchMSRN. If there is no VLR Number in session state, the feature attempts to set the OC-Charging-GT to the VMSC address. If that is not present in session state either then the feature returns.

If the outgoing leg is PS then the feature attempts to generate a Charging GT using the ChargingGTFormatString and sets the OC-Charging-GT with this. If this fails, the feature uses the UnknownLocationChargingGT for the OC-Charging-GT header.

The feature sets the OC-IM-TDP header to the value stored in session state by the FetchIMCSI feature.

Generating Charging GTs

The feature uses the CAP Charging Component to generate Charging GTs based on location data.

Determine International and Roaming Status

This feature 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 . The results of this feature are applied by the VoLTE communication barring features (MMTelOCB and MMTelICB).

From the spec

Here’s what 3GPP 24.611 says:

international: This condition evaluates to true when the request URI of the outgoing SIP request:

  • corresponds to a telephone number, i.e. a SIP URI with a “user” URI parameter set to “phone” or a tel URI; and

  • does not point to a destination served by a network within the country where the originating user is located when initiating the call.

international-exHC: This condition for international barring, excluding the home country, evaluates to true when the request URI of the outgoing SIP request:

  • corresponds to a telephone number, i.e. a SIP URI with a “user” URI parameter set to “phone” or a tel URI;

  • does not point to a destination served by a network within the country where the originating user is located when initiating the call; and

  • does not point to a destination served within the served users home network.

Feature cheat sheet

Feature Script Name

DetermineInternationalAndRoamingStatus

MMTel or SCC

Both

Call-Type

Orig or Term

Session Plan

mmtel-orig, mmtel-term, scc-tads-only

Execution Points

SipAccess_SessionCheck or SipAccess_SubscriberCheck

Network Operator Config

Yes

Subscriber Config

No

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

Yes

RA Entity Links

None

Prerequisite features

Sentinel-SIP:

  • SIP Determine Network Operator

  • SND:Determine Call Type Feature

  • SIP Extract Network Info

  • SIP Normalization (recommended)

VoLTE:

Source Code

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

> create-module new-diar-module opencloud#volte-determine-international-and-roaming-status#volte/2.9.0;2.9.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-international-and-roaming-status

Group module for the feature that includes all of the modules listed below.

volte-determine-international-and-roaming-status-address-list

Contains the profile specification for the feature address list profile table.

volte-determine-international-and-roaming-status-profile

Contains the profile specification for the feature configuration profile table.

volte-determine-international-and-roaming-status-feature

Contains the feature itself.

Configuration

Configuration for this feature is in the DetermineInternationalAndRoamingStatusConfigProfileTable. The profiles within this table have the following fields:

Parameter Type Description

EndCallIfNoVisitedNetwork

Boolean

Decide if the feature will end the call if no Visited Network can be determined.

ForceUserEqualsPhone

Boolean

Explicitly add user=phone parameter and value to SIP URI during inspection.

MinLength

int

The minimum length of address that will be checked.

NonInternationalFormatDNIsNational

Boolean

Whether non international format DNs, i.e. with no leading "+", should always be treated as national.

UseMCCSpecificAddressListTables

Boolean

Use a prefix address list table for the subscribers Mobile Country Code.

Behaviour

Get the address string to use in address analysis

The DetermineInternationalAndRoamingStatus feature analyses a digit string that corresponds to the destination (or called) party. Digit strings may be in a Tel URL, or the user part of a SIP URI.

If the number retrieved from the Tel URI or SIP URI user part contains a + sign, the + sign is removed to leave just the digits.

The DetermineInternationalAndRoamingStatus feature uses different properties of the initial INVITE request for originating and terminating treatment:

  • If the session is originating, then it checks the request-uri and To address.

  • If the session is terminating, then it checks the P-Asserted-Identity address, the From address, and the Referred-By address.

Otherwise, the feature execution ends.

If a digit string is not found, then the feature will respond to the sentinel-core with featureCannotStart, and end.

Determine if address international and roaming status should be skipped

The DetermineInternationalAndRoamingStatus feature may decide to not handle the address if either:

  • The address is shorter than the configured MinLength defined in DetermineInternationalAndRoamingStatusConfigProfileTable

  • The address matches an entry in the SkipDIRSAddressList

This allows for short codes and specific longer length numbers to avoid DetermineInternationalAndRoamingStatus. The SkipDIRSAddressList is a configurable address list scoped by the Sentinel selection key; it is only given to the component when used by the SIP normalization component.

Get the visited Mobile Country Code and Mobile Network Code

The prerequisite Extract Network Info Feature attempts to parse the P-Access-Network-Info and P-Visited-Network-Identifier headers to obtain the visited MCC and MNCs, and stores them in session state. The feature first checks if the session state field PaniMccsMncs (obtained from P-Access-Network-Info) contains any entries. If so, it takes the first entries for both the MCC and MNC. Otherwise, the visited MCC and MNCs are retrieved from the session state field PvniMccMnc, obtained by parsing the P-Visited-Network-Identifier according to IETF RFC 3455.

Get the ISO Country Code

The ISO country code is determined by the ExtractNetworkInfo or DetermineLocationFromMSRN feature. It is stored in session state in the IsoCountryCode field. The feature will attempt to retrieve it from this field.

Get the visited-network-id for the served user

The feature first checks if the session state field IMSInformation contains a valid IMS Visited Network Identifier populated by Diameter Per Leg Info Feature.

If no value is present, it extracts the visited network id for the served user as follows:

  • If the session is originating, the P-Visited-Network-Id header is checked in the incoming request.

    • If this header exists, then the visited network id is set to the header value.

  • If the session is terminating, the OC-Term-P-Visited-Network-Id header is checked in the incoming request.

    • If this header exists, then the visited network id is set to the header value.

If the incoming request did not contain the visited network id, and if the served user is logged into the IMS, then Third Party Registration Data is consulted - to find the P-Visited-Network-Id at the time of IMS registration. Third Party Registration data is looked up with an access key of the default public identity for the served user. It is accessed via the Sh Cache Microservice.

If a visited network id cannot be determined, the feature checks the configuration in the DetermineInternationalAndRoamingStatusConfigProfileTable to determine if the call should proceed or not. If EndCallIfNoVisitedNetwork is false, then the feature exits without modifying session state. If EndCallIfNoVisitedNetwork is true then the call is terminated.

Get the prefix address list

An important part of this feature is an address list of prefixes for each MCC or each visited network. Each entry in the list states whether an address with this prefix, for a subscriber of the network operator, registered with a subscriber location network, represents a visited or home network.

The addresses in the list will be used to determine the international status based on the MCC. For originating calls the called party address is used to find the destination MCC, and for terminating calls the calling party address is used to define the MCC from the originating party. This list allows the operator to define how the international status will be resolved by setting the field isVisitedNetwork.

For a session processed by VoLTE:

  • The session is scoped to the network operator by the SIP Determine Network Operator feature (this is the subscriber’s home).

  • The MCC or visited-network-id is found as described above.

  • In addition to a DEFAULT entry, it is possible to add entries for any MCC or visited network in the DetermineInternationalAndRoamingStatus_AddressListConfigurationTable profile. The installer adds the DEFAULT entry, and an entry for the home network MCC. Furthermore, there is an address list of prefixes stored in the DetermineInternationalAndRoamingStatus_AddressListEntryTable for both DEFAULT and each MCC or visited network stored in the DetermineInternationalAndRoamingStatus_AddressListConfigurationTable profile. Both tables are scoped to the Network operator.

The prefix address list to use is now determined as follows:

  • If an MCC was found and the profile field useMCCSpecificAddressListTables is set to false:

    1. The feature will first attempt to use the default prefix address list named DEFAULT.

    2. If the default list could not be found, the feature attempts to use the prefix address list for the visited-network-id.

  • If an MCC was found and the profile field useMCCSpecificAddressListTables is set to true:

    1. The feature will first attempt to use the prefix address list for the specific MCC.

    2. If the prefix address list for the MCC could not be found, the feature attempts to use the prefix address list for the visited-network-id.

  • If an MCC could not be found:

    1. The feature will use the prefix address list for the visited-network-id.

If no prefix address list is found, the feature will respond to the sentinel-core with featureFailedToExecute, and end.

Determine international and international-exHC status

If the original number did not include a + prefix and the profile field nonInternationalFormatDNIsNational is set to true, then the feature determines that the number is national, regardless of the MNC and MCC. Both the international and internationalExHC session state fields are set to false.

The DetermineInternationalAndRoamingStatus feature does a longest-prefix search of the prefix address list with the address string (extracted in step #1).

If a match is found, then the address starts with a prefix of significance within the scope of the MCC or visited network. The feature can set the International session state field in two ways:

  • If an MCC has been determined for the served user and there is an MCC present in the prefix address list entry then 'International' is set to 'true' if the MCCs are different.

  • If either MCC could not be found then 'International' is set to not networkPrefixListEntry.isVisitedNetwork().

The internationalExHC session state field is set to International and not networkPrefixListEntry.isHomeNetwork().

If a prefix address list match is not found, then it must be an international call; so the feature sets the International session state field to true and the internationalExHC session state field to true.

Using MCC specific prefix address lists

The DetermineInternationalAndRoamingStatus feature uses a single prefix address list named DEFAULT unless useMCCSpecificAddressListTables is configured as true in the feature’s profile.

MCC specific prefix address list tables may be needed for more advanced scenarios where different MCCs are desired to not be treated as international.

Determine roaming status

The SIP Sentinel SipSentinelConfiguration profile (scoped on the Sentinel selection key) defines the home Mobile Country Code (MCC), the Mobile Network Codes (MNCs) and the home network ids for the network operator. The home network ids define the home network for the subscriber.

If the feature finds a non-empty MCC for the visited network, it compares that value with the home MCC present in the SipSentinelConfiguration profile.

If they are different the feature sets the RoamingStatus to INTERNATIONAL and the RoamingIndicator session state field is set to true.

If they are equal and the visited MNC is present in the home MNCs, the feature sets the RoamingStatus to NOT_ROAMING and the RoamingIndicator session state field is set to false.

If they are equal and the visited MNC is not present in the home MNCs, the feature sets the RoamingStatus to NATIONAL and the RoamingIndicator session state field is set to false.

If no MCC is present then the feature does the roaming analysis based on the ISO Country Code.

If the ISO country code is equal to the configured home network ISO country code, the feature sets the RoamingStatus to NOT_ROAMING and the RoamingIndicator session state field is set to false.

If they are not equal the feature sets the RoamingStatus to INTERNATIONAL and the RoamingIndicator session state field is set to true.

If no ISO country code is present then the feature does the roaming analysis based on the visited-network-id.

If the visited-network-id is not a member of the set of home network ids, the feature sets the RoamingStatus to NOT_ROAMING and the RoamingIndicator session state field is set to true.

If neither the visited MCC nor the visited network are present, the feature sets the RoamingStatus to UNKNOWN.

OC-Roaming-Status Header

Setting the Header

If the feature is running on a terminating MMTel instance, and CAP charging is enabled, it will attempt to add an OC-Roaming-Status header to the outbound request. The value of the header will be set to match the value of RoamingStatus.

Using the Header

When the feature is invoked, it will check for an OC-Roaming-Status header on the inbound request. If the header is found, the feature will forgo the usual process for determining the roaming status. Instead, the value of the header will be used to set the RoamingStatus field, and if the value is INTERNATIONAL the RoamingIndicator field will be set to true. The international status of the call will not be determined if the header is found, as it should only be present for the SCC AS, which does not need the international status. If the header is absent the feature will go through the usual roaming and international determination procedure as described above.

Session state inputs and outputs

Inputs

Name Type Format Description Behaviour if null/invalid

SentinelSelectionKey

com.opencloud. sentinel.common.SentinelSelectionKey

selection key (for example, <platform>:<network>:::)

For selecting configuration data

Report featureCannotStart, featureHasFinished if the network operator field is not set.

CallType

com.opencloud.sentinel.common.CallType

One of: MobileOriginating, MobileTerminating, MobileForwarded, NetworkInitiated, EmergencyCall

Session type of this call

Report featureCannotStart, featureHasFinished

IMSDefaultPublicID

java.lang.String

tel URL or SIP URI

the default-public-id (set by IMSIDLookup)

Increment statistic SubscriberNotLoggedIn and report featureHasFinished

ImsInformation. ImsVisitedNetworkIdentifier

java.lang.String

recommended format is epc.ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org according to IR65

The visited network id extracted from the Invite request or from the registration data by the Diameter Leg Info feature

Try to extract from the triggered request

PaniMccsMncs

List<MccMnc>

MCC and MNC as String

A list of MCCs and MNCs extracted from the P-Access-Network-Info header from the request or from the registration data by the Extract Network Info Feature

Try to extract from the session state PvniMccMnc

PvniMccMnc

com.opencloud.sentinel.common.MccMnc

MCC and MNC as String

A list of MCC and MNC extracted from P-Visited-Network-Id header from the request or from the registration data by the Extract Network Info feature

Try to use the ISO country code

IsoCountryCode

java.lang.String

Two-letter ISO country code

An ISO country code determined by the Extract Network Info or Determine Location From MSRN feature.

Try to use visited-network-id

ChargeMode

com.opencloud.volte.sentinel.common.sessionstate.types.ChargeMode

ChargeMode enum value

Used to determine whether a OC-Roaming-Status header should be included on the outbound message.

Header will not be included.

Outputs

Name Type Format Description

International

boolean

true or false

the international condition as defined by 3GPP 24.611

InternationalExHC

boolean

true or false

the international-exHC condition as defined by 3GPP 24.611

RoamingIndicator

boolean

true or false

true, if the subscriber is roaming

RoamingStatus

enum

NOT_ROAMING, NATIONAL, INTERNATIONAL, UNKNOWN

  • NOT_ROAMING if served user is in home network.

  • NATIONAL if served user is in home country but not in the home mobile network.

  • INTERNATIONAL if served user is not in his home country.

  • UNKNOWN if there were not enough information to assert roaming.

Error scenarios

These scenarios trigger the following reports.

Scenario Report

Sessionstate SentinelSelectionKey network operator field is not set

featureCannotStart

Sessionstate CallType is null

featureCannotStart

No Called Party Leg available from the LegManager

featureCannotStart

Cannot determine a digit String to analyse in originating case

featureIssuedWarning

Cannot determine a digit String to analyse in terminating case

featureIssuedWarning

There is no prefix address list for a visited-network-id

featureFailedToExecute

No registration data found for default-public-id

featureFailedToExecute

Registration data fetched for default-public-id indicates this id is not a default-public-id

featureFailedToExecute

Statistics

DetermineInternationalAndRoamingStatus 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 → DetermineInternationalAndRoamingStatus
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.9.0].feature.DetermineInternationalAndRoamingStatus"

Parameter Type Description
Started

Counter

Incremented each time the feature runs

FailedToStart

Counter

Incremented when a fatal error occurs before feature execution

IssuedWarning

Counter

Incremented when a non-fatal error occurs during feature execution

FailedDuringExecution

Counter

Incremented when a fatal error occurs during feature execution

TimedOut

Counter

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

VisitedNetworkHeaderFound

Counter

Incremented when the requestURI identity is in RegistrationRecords list of public identities.

AccessNetworkMccFound

Counter

Incremented when the mobile-Country-Code is found in the P-Access-Network-Info header.

DeterminedInternationalUsingAccessNetworkMcc

Counter

Incremented when the MCC prefix address list is used to determine whether the call is international.

DeterminedInternationalUsingVisitedNetworkId

Counter

Incremented when the visited-network-id prefix address list is used to determine whether the call is international.

CouldNotGetPVisitedNetworkID

Counter

Incremented when no visited network ID information could be found.

HomeNetworkIdSetForNetworkOperatorIsEmpty

Counter

Incremented when the Sentinel SIP configuration for the network operator has an empty home-network-id set (the feature cannot determine if the subscriber is roaming).

InternationalRoaming

Counter

Incremented when the feature determines that the served user is roaming in a foreign country.

NationalRoaming

Counter

Incremented when the feature determines that the served user is roaming in their home country.

NotRoaming

Counter

Incremented when the feature determines that the served user is on their home network.

UnknownRoaming

Counter

Incremented when the feature is unable to determine the served user’s roaming status.

AddressNotMinimumLength

Counter

Incremented when destination address is less than the configured minimum length

AddressOnBlackList

Counter

Incremented when destination address matches an entry in the SkipDIRSAddressList

StatusDeterminedFromHeader

Counter

Incremented when the roaming status is determined from a OC-Roaming-Status header on the incoming request.

NoActionRequired

Counter

Incremented when the feature determines that it does not need to do anything for the current invocation.

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. Offline Charging and whether to use CDRs, Diameter Rf or both is controlled by the VoLTE Interim CDR Feature.

Feature cheat sheet

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

Any and All

No

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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → DetermineChargeMode
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.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

Note that the VoLTE Interim CDR Feature is configured to select whether interim CDRs and/or ACRs are used. It is used if Diameter Rf and/or Interim CDRs are selected during installation. It’s settings are independent of the oc-charge-mode Route Header parameter.

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 SAS Support 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

No

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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → DetermineInitialLegNames
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].feature.DetermineInitialLegNames"

Name Description
FeatureStarted

Incremented each time the feature runs

FeatureFailedToStart

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

FeatureIssuedWarning

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

FeatureFailedDuringExecution

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

FeatureTimedOut

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

FeatureCallingLegNameSet

Incremented when calling leg name is found

FeatureCalledLegNameSet

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.

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 SAS Support Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

Any and All

No

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.9.0;2.9.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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → DetermineVoltePlanId
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].feature.DetermineVoltePlanId"

Name Type Description
Started

Counter

Incremented each time the feature runs

FailedToStart

Counter

Incremented when a fatal error occurs before feature execution

IssuedWarning

Counter

Incremented when a non-fatal error occurs during feature execution

FailedDuringExecution

Counter

Incremented when a fatal error occurs during feature execution

TimedOut

Counter

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

NoPlanSelected

Counter

Incremented when the feature fails to select an appropriate plan ID

MmtelOriginatingPlanSelected

Counter

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

MmtelTerminatingPlanSelected

Counter

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

MmtelConferencingPlanSelected

Counter

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

SccOriginatingPlanSelected

Counter

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

SccTerminatingPlanSelected

Counter

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

SccTerminatingTadsOnlyPlanSelected

Counter

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

SccTerminatingAnchorOnlyPlanSelected

Counter

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

SccReoriginationPlanSelected

Counter

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

SccAccessTransferPlanSelected

Counter

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

ConferenceConfigurationNotFound

Counter

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

PlanIDAlreadySet

Counter

Incremented when the feature detects that a plan ID has already been selected

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’.

A Plan ID has already been set on the Sentinel Selection Key

The feature will not attempt to do any analysis or change the plan ID.

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 SAS Support Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

SCC

No

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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → FeatureCapsManagement
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.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.

FetchIMCSI

The FetchIMCSI feature retrieves CAMEL Subscription Information (CSI) from the HLR for charging purposes .

Feature cheat sheet

Feature Script Name

FetchIMCSI

MMTel or SCC

Both

Call-Type

Orig or Term

Session Plan

mmtel-orig, scc-tads-only

Execution Points

SipAccess_SubscriberCheck

Network Operator Config

Yes

Subscriber Config

No

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

Yes

RA Entity Links

sentinel-sis-in-hlr

Prerequisite features

Network Operator Data

The FetchIMCSI feature depends on configuration from four profile tables:

  • The FetchIMCSIConfigProfileTable provides the basic configuration for the feature.

  • The FetchIMCSIFeatureServiceKeyProfileTable provides mapping between orig and term service keys.

  • The HLRConfigProfileTable provides configuration for sending requests to the HLR.

  • The CapChargingConfigProfileTable provides configuration for how the feature should behave on non-roaming terminating calls.

FetchIMCSIConfigProfileTable

Basic feature configuration is stored on a profile table called FetchIMCSIConfigProfileTable.

Data is scoped according to a Sentinel selection key.

Attribute Name Type Default Description
FetchImcsiEnabledOnOrigCall

boolean

false

Enables/Disables the feature for originating calls.

RequestedTdpOnOrigCall

int

1 (orig), 12 (term)

Trigger Detection Point to request on originating calls, determines whether the O-CSI or T-CSI is retrieved from the HLR. (1, 2, or 3 for O-CSI; 12 for T-CSI).

FetchImcsiEnabledOnTermCall

boolean

false

Enables/Disables the feature for terminating calls.

RequestedTdpOnTermCall

int

1 (term), 12 (term)

Trigger Detection Point to request on terminating calls, determines whether the O-CSI or T-CSI is retrieved from the HLR. (1, 2, or 3 for O-CSI; 12 for T-CSI).

FetchIMCSIFeatureServiceKeyProfileTable

This profile table is used to provide mappings between orig and term TDP service keys. These mappings are used when the TDP requested is for a different call type (i.e. originating/terminating) than the session.

Data is scoped according to a Sentinel selection key, with a suffix which corresponds the the service key to map from. A default suffix can be used to define a mapping for keys that do not have specific profiles.

Attribute Name Type Default Description
SourceServiceKey

String

None

The service key to map from, or 'default' to match all service keys that do not have a more specific match for the selection key.

TargetServiceKey

int

None

The service key to map to.

HLRConfigProfileTable

This profile table provides the configuration for connecting to the HLR. It is shared across all features that communicate with the HLR.

For more information refer to HLR MAP Configuration.

CapChargingConfigProfileTable

The feature checks a single field on the OnlyChargeTerminatingCallsIfInternationalRoaming profile table. This is used to determine if the feature needs to do anything on a non-roaming terminating call.

For more information refer to CapChargingConfigProfileTable.

Session Input Variables

Variable name Type Comments

ChargeMode

Enum

The feature will only run if the charge mode is CAP.

CallType

Enum

Affects whether orig or term feature config is loaded, and depending on the TDP, whether the service key is mapped.

SentinelSelectionKey

SentinelSelectionKey

Affects which profiles are loaded from each configuration table.

Session Output Variables

Variable name Type Comments
OcImTdpHeader

String

Contains the data that was retrieved from the HLR, ready for inclusion in a header on the SIP message towards the IMSSF.

Statistics

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

Statistic

Type

Description

Started

Counter

Incremented when the feature is invoked.

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.

ExecutionNotRequired

Counter

Incremented when the feature determines that it does not need to do anything.

RequestSent

Counter

Incremented when an ATSI request is sent to the HLR.

RequestFailed

Counter

Incremented when no result is received after attempting to send a request.

ReceivedATSIResult

Counter

Incremented when an ATSI result is received from the HLR.

DialogOpenRefused

Counter

Incremented when a DialogOpenRefused event is received after attempting to send a request.

UserAbortedDialog

Counter

Incremented when a UserAbortedDialog event is received after attempting to send a request.

ProviderAbortedDialog

Counter

Incremented when a ProviderAbortedDialog event is received after attempting to send a request.

OperationErrorOccurred

Counter

Incremented when a OperationErrorOccurred event is received after attempting to send a request.

InvalidResponse

Counter

Incremented when an ATSI result is received for a request, but it does not contain the requested data.

ServiceKeyMappingFailed

Counter

Incremented when a service key requires mapping, but no mapped value can be found.

FetchedIMCSI

Counter

Incremented when the feature successfully retrieved CSI information from the HLR.

AttachedToMapRequestAci

Counter

Incremented when the feature creates and attaches to the activity for the MAP request.

DetachedFromMapRequestAci

Counter

Incremented when the detaches from the activity for the MAP request.

ResponseLatency

Sample

Time from sending the ATSI request to receiving the ATSI result, sampled on receipt of the result.

Installation

FetchIMCSI is a GSM only feature and as such will only be deployed if GSM mode is selected in the installer. Additionally the feature will only be enabled in its configuration profile if explicitly done so in the installer. The feature is only useful when CAP charging is being used, so the option to enable it will only be given by the installer if CAP charging is selected.

Behaviour

The FetchIMCSI feature retrieves the O-CSI or T-CSI data for a subscriber from the HLR. The data in the response is extracted and put into a format for use in an OC-IM-TDP SIP header, which is sent to the IMSSF when doing CAP charging.

Sending the Request

When initially triggered, the feature will construct a Any Time Subscription Interrogation (ATSI) request in order to retrieve the required data from the HLR.

Execution Conditions

Before creating the request, the feature will check that the following conditions are met:

  1. The enabled flag corresponding to the call type is true in the feature configuration profile.

  2. The charge mode for the call is CAP

  3. If the call is terminating and not international roaming, the OnlyChargeTerminatingCallsIfInternationalRoaming config flag is false.

If any of these conditions is not met, the feature will immediately finish execution without sending a request.

The ATSI Request

If the conditions are met, the feature will create the ATSI request towards the HLR.

The subscriber identity to request information for will be a digit string taken from the default public ID in the served user’s registration data. If a digit string is not found in the default public ID, then the feature will attempt to retrieve one from the Subscriber session state field. If Subscriber field also does not have an appropriate ID, then the feature will abort its attempt to create a request and record an error.

The data the feature requests from the HLR depends on the Requested TDP field corresponding to the call type in the feature configuration profile. The request will either be for the O_CSI or the T_CSI according to the following table:

TDP Value Requested Data

2 or 3

O_CSI

12

T_CSI

Once the request is created, a MAP dialog will be opened to the HLR and the request will be sent. The feature will then enter a waiting state until a response is received.

Processing the Result

On receipt of an ATSI result from the HLR, the feature will attempt to extract the information within, and format it into an OC-IM-TDP header. This header will be put into the OcImTdpHeader session state field.

OC-IM-TDP Header

This header is formatted as a comma separated list of property=value pairs. It has the following data:

Property Name Value
bcsmTriggerDetectionPoint

collectedInfo if the CallType is originating, termAttemptAuthorized if it is terminating.

defaultCallHandling

continueCall or releaseCall based on the DefaultCallHandling field in the requested TDP data in the ATSI result. May be absent if the field was empty in the result.

serviceKey

See below.

scfAddress.address

The address part of the GsmSCF_Address field in the requested TDP data in the ATSI result.

scfAddress.nature

The nature part of the GsmSCF_Address field in the requested TDP data in the ATSI result.

scfAddress.numberingPlan

The numbering plan part of the GsmSCF_Address field in the requested TDP data in the ATSI result.

Service Key

The serviceKey property in the final OC-IM-TDP header has special handling. If the requested information matches the session’s call type (i.e. O_CSI is requested on an originating call, or T_CSI requested on a terminating call), then the final serviceKey value used in the header will match the value of the ServiceKey field in the requested TDP data in the ATSI result. If the requested information does not match the call type, then the feature will attempt to map the service key to a different value based on the service key mapping profile.

To find the mapped value, the feature will search for a profile on the FetchIMCSIFeatureServiceKeyProfileTable profile table. The profile name used will be the sentinel selection key with the service key received in the ATSI result as a suffix. Standard selection key matching will apply, where the profile with the longest matching selection key and a matching service key suffix will be used. If no matching profile with the service key is found, then the feature will reattempt the search with default as the suffix. If still no profile is found, the feature will use the original, unmapped service key in the OC-IM-TDP header. If a profile is found, the value of the TargetServiceKey will be used in the OC-IM-TDP header.

Handling of Request Failure

If the feature fails to retrieve the requested information for any reason, it will increment the feature statistic that best explains why, and report the details to SAS. Beyond that, the feature will abort execution and no further action will be taken.

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 Microservice RA, which connects to the Sh Cache Microservice. For more information refer to Data Stored by the Third Party Registrar in HSS.

Feature cheat sheet

B2BUA Instance SAS Support 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

Yes

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.9.0;2.9.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 ▶ sentinel.volte.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 Microservice.

CacheIndicatedQuerySuccess

Counter

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

CacheIndicatedQueryFailure

Counter

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

SubscriberNotRegistered

Counter

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

RegistrationOutOfSync

Counter

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

ResponseLatency

Sampled

Records elapsed time between requesting data from the Sh Cache Microservice 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.

IMSIDLookupFromCassandraIN

This feature reads Third Party Registration information stored in the Cassandra Database, and writes it into session state. Information is read during InitialDP 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

SCC

Terminating

DirectAccessNetworkCheck

No

No

Stateless

SBB

Prerequisite features

These features must run before IMSIDLookupFromCassandraIN:

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 InitialDP.

Session output variables

Session State variable name Variable type Comments
IsLoggedIn

boolean

True, if the feature was able to find a valid registrarion record for the subscriber.

Statistics

IMSIDLookupFromCassandraIN statistics are tracked by the IMSIDLookupFromCassandraIN feature and can be found under the following parameter sets:

SLEE-Usage ▶ sentinel.volte.ss7 service ID ▶ sentinel.volte.ss7 SBB ID ▶ IMSIDLookupFromCassandraIN feature.

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.

SLEE-Usage ▶ sentinel.volte.ss7 service ID ▶ volte.sentinel.volte-imsid-lookup-cassandra-ss7-feature SBB ID.

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.

CassandraQueried

Counter

Incremented when Cassandra is queried for a subscriber’s registration.

NoSubscriberSpecified

Counter

Incremented when no subscriber is specified for the query.

SubscriberNotRegistered

Counter

Incremented when the returned subscriber from Cassandra is not registered.

IMSIDRetrieveFail

Counter

Incremented when the Cassandra lookup fails.

IMSIDRetrieveSuccess

Counter

Incremented when the Cassandra lookup succeeds.

FeatureError

Counter

Incremented when a feature error occurs.

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. If a valid registration for the subscriber is found, the IsLoggedIn session state field will be set to true. Otherwise it will be set to false.

IMSIDLookupFromCassandraSIP

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 SAS Support 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

No

Originating, Forwarding, and Terminating

SIP Access Session Pre-Credit Check

No

No

Stateless

POJO

Prerequisite features

These features must run before IMSIDLookupFromCassandraSIP:

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the volte-imsid-lookup-cassandra-sip 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-sip#volte/2.9.0;2.9.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-sip

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

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

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.

FeatureError

Counter

Incremented when a feature error occurs.

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 Credit-Control-Answers

The feature schedules charging announcements as defined by TS 32.281 as well as announcements for out-of-credit (4012 CCA result code), low balance (Low-Balance-Indicator AVP), and for custom OC-Play-Announcement-Id AVPs.

The feature runs on every successful and 4012 credit check result and analyses the CCA for announcement triggers:

  • Multiple-Services-Credit-Control AVP containing Announcement-Information AVP;

  • OC-Play-Announcement-Id AVP;

  • low balance AVP; or

  • result code 4012.

If the CCA contains such a trigger then the feature schedules the relevant announcement either immediately or on a timer relative to quota exhaustion. The feature is able to schedule multiple announcements to be played.

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 or whether any timers should be set relative to quota exhaustion to start announcements. The feature runs on timer expiry to start any announcements that were scheduled on timers.

Feature cheat sheet

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

MMTEL.

Yes

Originating, Forwarding, and Terminating

SipAccess_PartyRequest SipAccess_ServiceTimer SipAccess_CreditAllocatedPostCC SipMidSession_CreditAllocatedPostCC SipAccess_CreditLimitReachedPostCC SipMidSession_CreditLimitReachedPostCC

Yes

No

Stateless

POJO

Behaviour

Announcements requested in the Announcement-Information AVP are played in preference to other announcements. Announcements requested in the OC-Play-Announcement-Id AVP are played if no Announcement-Information announcements are present and configured announcement IDs for out-of-credit (4012 CCA result code) or low balance (Low-Balance-Indicator AVP) are only played if no Announcement-Information or OC-Play-Announcement-Id AVPs were present.

Call phase Announcement-Information AVP Low Balance Indicator AVP 4012 Out-of- Credit Behaviour

Early media

Present

Not present

Not present

Charging announcement played, call continues

Early media

Present

Present

Not present

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

Early media

Present

Not present

Present

Charging 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

Charging announcement played, call continues

Mid call

Present

Present

Not present

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

Mid call

Present

Not present

Present

Charging 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 user

It is not possible to play announcements to the terminating subscriber after the initial credit check as the session has not yet been established. Announcements requested by Announcement-Information AVPs to be played to the terminating party in the initial credit check are not played. If other announcements were requested when running as a terminating instance 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.

Charging Announcements

The Announcement-Information AVP and its child AVPs were introduced in 3GPP Rel. 13 but Sentinel does support receiving them in Rel. 12.

Child AVP Behaviour
Announcement-Identifier

Contains the ID for the announcement. This must be present and non-zero.

Variable-Part

Ignored

Time-Indicator

If present and non-zero a timer will be set relative to quota exhaustion and the announcement scheduled on timer expiry. If zero the announcement will be scheduled once the quota is exhausted and the call ended. If a credit check occurs before the timer fires or quota is exhausted then the announcement will not be played. An announcement with Time-Indicator 0 will only be played if the CCA contained a Final-Units-Indication AVP.

Quota-Indicator

If present this determines whether the user will be charged for the announcement. If not present, local announcement configuration will be used instead. This is ignored for early media announcements.

Announcement-Order

If multiple announcements are set in the CCA this should be used to order them.

Play-Alternative

If present determines whether the announcement should be played to the served or remote user. If not present the announcement will be played to the served user. If multiple announcements are present only announcements to the party with the lowest Announcement-Order will be played.

Privacy-Indicator

Ignored. The announcement is only to the requested party.

Language

If present this will be used in the request to the MRF, otherwise the determined language will be used.

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

LowBalanceReauthTimerId

javax.slee.facilities.TimerID

Session state output variables

Attribute Name Type Description
EarlyMediaAnnouncementInfoQueue

List

A List of early dialog announcements to play, if any

MidCallAnnouncementInfoQueue

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.

AnnouncementTimersMapping

Map

A map of TimerID to the SipAnnouncementInformation to be scheduled on the timer firing.

AnnouncementTimersPostponed

Boolean

Set to true if the initial CCA requested an announcement to be played on a timer.

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 ▶ sentinel.volte.sip service ID ▶ sentinel.volte.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.

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.

ScheduledAnnouncementInformation

Counter

Incremented whenever an Announcement-Information AVP announcement is scheduled.

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 SAS Support 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.

No

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.9.0;2.9.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 MAP Configuration.

Statistics

SubscriberDataLookupFromHLR statistics are tracked by the SubscriberDataLookupFromHLR feature and can be found under the following parameter set: SLEE-Usage → sentinel.volte.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.

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 SAS Support 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

Yes

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.9.0;2.9.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

  5. a default value for operator authorized fields

This table, by default, has entries for MMTEL-Services and IMS-ODB-Information, configured by the installer. 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 Sh Cache Microservice.

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 Microservice RA, connected to the Sh Cache Microservice, 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 Microservice 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 Microservice 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.

MMTELServices/complete-originating-identity-presentation/operator-originating-identity-presentation/@authorized

MMTelOIPServiceData.operatorAuthorized

Value read from Configuration

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.

MMTELServices/complete-originating-identity-restriction/operator-originating-identity-presentation-restriction/@authorized

MMTelOIRServiceData.operatorAuthorized

Value read from Configuration

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 present in the XML document, the field is set to true according to 3GPP TS 24.623.

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.

MMTELServices/complete-terminating-identity-presentation/operator-terminating-identity-presentation/@authorized

MMTelTIPServiceData.operatorAuthorized

Value read from Configuration

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.

MMTELServices/complete-terminating-identity-restriction/operator-terminating-identity-presentation-restriction/@authorized

MMTelTIRServiceData.operatorAuthorized

Value read from Configuration

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.

MMTELServices/complete-communication-barring/operator-incoming-communication-barring/@authorized

MMTelICBServiceData.operatorAuthorized

Value read from Configuration

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.

MMTELServices/complete-communication-barring/operator-outgoing-communication-barring/@authorized

MMTelOCBServiceData.operatorAuthorized

Value read from Configuration

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/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/communication-diversion/NoReplyTimer

MMTelCDIVServiceData.noReplyTimeOut

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

MMTELServices/complete-communication-diversion/communication-diversion/ruleset

MMTelCDIVServiceData.rules

No default value specified.

MMTELServices/complete-communication-diversion/operator-communication-diversion/@authorized

MMTelCDIVServiceData.operatorAuthorized

Value read from Configuration

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.

CONF

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

MMTELServices/complete-conference/operator-conference/@authorized

MMTelCONFServiceData.operatorAuthorized

Value read from Configuration

For more information on MMTEL CONF see MMTel Conference.

CW

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

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

MMTelCWServiceData.active

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

MMTELServices/complete-communication-waiting/operator-communication-waiting/@authorized

MMTelCWServiceData.operatorAuthorized

Value read from Configuration

For more information on MMTEL CW see MMTelCW.

HOLD

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

MMTELServices/complete-communication-hold/operator-communication-hold/@authorized

MMTelHOLDServiceData.operatorAuthorized

Value read from Configuration

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

Value read from Configuration

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

Value read from Configuration

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 SAS Support 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

No

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.9.0;2.9.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 “TestOperator”, then the profile table name is TestOperator_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 “TestOperator” then the profile table name is TestOperator_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 → sentinel.volte.sip service ID → SubscriberDataLookupFromHss SBB ID.

Name Description
Invoked

Incremented each time the feature runs.

Failed

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

SubscriberDataRetrieved

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

SessionStatePopulated

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

Misconfigured

Incremented when absent configuration data prevents the feature from running.

SessionStateNotFound

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

Behaviour

This feature uses the Sh Cache Microservice RA, connected to the Sh Cache Microservice, 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 Microservice 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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → SuppressSdpCdr
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].feature.SuppressSdpCdr"

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.

NoPendingSdpCdr

Counter

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

SdpCdrWriteSuppressed

Counter

Incremented each time an SDP CDR is suppressed

SdpCdrWriteAllowed

Counter

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 and/or Diameter Accounting Requests (ACRs) throughout the session.

VolteInterimCdr runs at various key points throughout a session and if any of its write conditions are met it writes either, both, or neither of:

  1. an interim AVP CDR using the cdr-ra

  2. an ACR using the rf-control-ra

Interim AVP CDRs and Diameter Accounting Records (ACRs) have substantially similar content and the same triggering logic hence both are supported by this feature.

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

SAS Support

No

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 the current CDR/ACR.

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, IMSIDLookupFromCassandraSIP feature

CallReferenceNumber

byte[]

Contains the Call Reference Number used in queries to the HLR

FetchMSRN feature

Functionality

This feature can be configured to:

  • write CDRs to the local filesystem (through the cdr-ra), and/or

  • write ACRs using the Diameter Rf protocol (through the rf-control-ra)

  • not write either

This feature uses the information from the session state fields mentioned above and constructs a CDR and/or ACR for output. See AVP CDR Format for the format of the CDRs.

Although the feature runs in many execution points, it inspects various session state fields to decide whether or not to write an interim CDR and/or ACR.

An interim CDR and/or ACR will be written under any of the following conditions:

  • On the initial SIP request on the 'LegForCdrs'

  • On the SipInterimCdr feature timer, if no CDR has been recently written

  • On session end

  • When a feature (e.g. SDP Monitor) sets WriteCdrOnSDPChange to true

When the VoLTE TAS is configured for session replication CDRs will still be written and ACRs will continue to be sent after node failover. The feature maintains a timer for the interim CDR period. This timer may be adjusted according to the Rf accounting interval provided by the CDF. The interim CDR timer is armed redundantly if session replication is enabled.

When the feature is about to write an INTERIM or STOP ACR for a Sentinel Session, if checks if the current Rhino node has an Rf Control Activity for the Diameter Rf session. If it does not, a new Rf Control Activity is started using the same Rf session identifier. This fails over the Rf session. The new session will use `Accounting-Record-Number`s continuing from the last known record number before failover.

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

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

Configuration

These parameters configure the feature:

Parameter Type Description

WriteCdrOnSDPChange

boolean

When a meaningful SDP change occurs on a monitored leg, write a CDR

InterimTimerPeriod

long

The maximum duration in seconds between timer driven interim CDRs. Setting this to zero will disable timer based interim CDRs.

UseCdrRa

boolean

Whether interim CDRs should be written to disk using the cdr-ra

UseRfControlRa

boolean

Whether ACRs should be written using the rf-control-ra

Configuration profile naming

Configuration Profile Table Name Description Profile Naming

SipInterimCdrProfileTable

SipInterimCdr feature configuration parameters

SentinelSelectionKey (typically $PLATFORM_OPERATOR_NAME:::: for example, OpenCloud::::)

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

SAS Support

No

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, IMSIDLookupFromCassandraSIP 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

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

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 and operator determined retargeting

provides call barring rules determined by the operator that take 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.

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

updates the Request URI of a SIP INVITE, based on the location of the calling party and the dialled number

performs a list of predefined HTTP PUT operations to update subscriber data in an XCAP server.

determines whether a received SIP INVITE corresponds to a PSAP callback, and stops any other features that could potentially prevent the call being set up.

The two features here are responsible for identifying appropriate calls as PSAP callbacks and (if required) recording that a PSAP call has occurred.

Call Barring Features

Call Barring Features.

Feature What it does

implements incoming communication barring and anonymous communication rejection

implements outgoing communication barring and operator determined retargeting

provides call barring rules determined by the operator that take 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 SAS Support Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Yes

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.9.0;2.9.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.

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

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 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

In case of a single identity (i.e. a 'one' condition), or in case of an exception (i.e. an 'except' condition), the URI in the condition and the URI to match against are both normalized before they are compared. Normalization is done using the Normalization Component.

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 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 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 sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → MMTelICB
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.9.0].feature.MMTelICB"

Statistic Type Incremented when…​
Started

Counter

the feature runs

FailedToStart

Counter

Sentinel VoLTE encounters an error while attempting to start the feature

IssuedWarning

Counter

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

FailedDuringExecution

Counter

a fatal problem is encountered and the feature cannot execute correctly

TimedOut

Counter

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

CallBarred

Counter

the feature bars a call (including when barring due to ACR)

CallBarredByOdb

Counter

the feature bars a call by Operator Determined Barring rule

PlayAnnouncementTriggered

Counter

the feature requests that an announcement be played to the calling party

ACRTriggered

Counter

a call is barred by ACR

OdbRulesEvaluatedTrue

Counter

a rule was evaluated to be True

RulesEvaluatedTrue

Counter

incremented by the number of rules which evaluated 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.OperatorAuthorized or 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 and operator determined retargeting .

(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

Feature Script Name

MMTelOCB

MMTel or SCC

MMTel

Call-Type

Originating

Session Plan

mmtel-orig

Execution Points

SipAccess_SubscriberCheck, SubscriptionSipRequest

Network Operator Config

Yes

Subscriber Config

Yes

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

Yes

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.9.0;2.9.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

The MMTelOCB feature retrieves configuration from two profile tables:

  • The MMTelOCBConfigProfileTable provides the basic configuration for the feature.

  • The MMTelOdbOperatorSpecificTypeRuleProfileTable provides operator-specific ODB rule configuration.

MMTelOCBConfigProfileTable

Basic feature configuration is stored on a profile table called MMTelOCBConfigProfileTable.

Operator data is scoped according to a Sentinel selection key.

Attribute Name Type Default Description
PlayAnnouncement

boolean

false

If true, MMTelOCB will request an announcement is played when it bars a call.

AnnouncementID

int

0

The ID for the announcement to be played. If set to 0 no announcement will be played.

MMTelOdbOperatorSpecificTypeRuleProfileTable

Operator specific ODB rule configuration is stored on a profile table called MMTelOdbOperatorSpecificTypeRuleProfileTable.

See How to Provision the Operator Specific Barring Rules for details of this profile table.

Session Input Variables

Variable name Type Comments

MMTelOCBServiceData

Complex

OdbServiceData

Complex

Read from the HSS in SubscriberDataLookupFromHSS

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.

EarlyMediaAnnouncementInfoQueue

List<SipAnnouncementInformation>

Feature adds an entry with the value of the announcement ID to be played.

EndSessionAfterAnnouncement

int

The status code used when ending the session if barring has occurred and announcements are used.

RanOcb

boolean

Signal to other features that OCB ran on this session.

MonitorCallOnly

boolean

Set to true if the feature determines that charging should be disabled for the call.

Statistics

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

Statistic Type Description
Started

Counter

Incremented when the feature is invoked.

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.

CallBarred

Counter

Incremented when the feature bars a call.

CallExplicitlyAllowed

Counter

Incremented when the feature finds a rule that explicitly allows the call to go through, thus preventing any barring.

ODBRuleApplied

Counter

Incremented when an ODB rule’s conditions were met and its action was executed.

OCBRuleApplied

Counter

Incremented when an OCB rule’s conditions were met and its action was executed.

PlayAnnouncementTriggered

Counter

Incremented when the feature requests that an announcement be played to the calling party.

RedirectionRequested

Counter

Incremented when an operator specific ODB rule’s conditions were met and it has been configured to redirect the call.

RedirectionFailed

Counter

Incremented when an attempt to redirect the outbound INVITE fails.

RedirectionSuccessful

Counter

Incremented when an attempt to redirect the outbound INVITE is successful.

OdbSpecificTypeRulesNotFound

Counter

Incremented when the subscriber data for the served user indicates that an operator specific ODB rule should be applied, but no configuration could be found for the specified rule.

Supported Barring Rule Conditions

Roaming

This condition evaluates to true if the session state variable RoamingIndicator is true. This is set by the 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

In case of a single identity (i.e. a 'one' condition), or in case of an exception (i.e. an 'except' condition), the URI in the condition and the URI to match against are both normalized before they are compared. Normalization is done using the Normalization Component.

The URI to match against although normalized comes from the inbound request. This means that the URI will not have had number translation features such as SIP Short Code applied. Therefore any condition intended to match a shortcode should take this into account.

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 towards '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 towards 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 towards any user 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 towards any user 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 towards 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 identities 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 towards any user registered in the domain 'example2.com' except for 'sip:charlie@example2.com, for 'sip:alice@example1.com' and sip:bob@example1.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 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 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 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.

Behaviour

Initial Checks

When triggered the feature first undergoes a series of checks to ensure that the conditions for the feature to run are met. The feature enforces the following conditions:

  • The call-type is Originating or Forwarded.

  • OCB service data for the subscriber has been successfully loaded and the OperatorAuthorized flag in the data is set to true.

  • Network operator configuration for the feature is present and has been successfully loaded.

  • The invoking trigger for the feature is an inbound SIP INVITE or REFER request.

If any of those conditions are not met, the feature will terminate immediately and the OCB service will not run.

Barring Rule Evaluation

If all checks passed, then the feature will move on to carry out barring rule evaluation. This occurs in three phases, one for each type of rule:

  1. All operator specific type rules are evaluated. If any of them apply (be they a barring, retarget or explicit allow action), then the feature will execute the appropriate action and then skip the following phases.

  2. The remaining ODB rules are evaluated, again if any of the rules apply, their action will be executed and the final evaluation phase skipped.

  3. Standard OCB rules will be evaluated and the appropriate action applied if one is matched. This final phase will be skipped if the MMTel OCB Active flag is set to false in the service data.

When deciding whether a rule should be applied, the feature will check the set of conditions provided by the rule. The feature will apply the rule if any of the following statements are true:

  • The rule has no set of conditions, i.e. the <conditions> element is absent in the rule definition.

  • The set of conditions for the rule is empty.

  • All of the conditions within the set defined in the rule are met.

If none of those statements are true for any rule, the feature will complete execution and the call will be allowed to continue.

Rule Format

Each rule is expressed as an XCAP cp:rule XML fragment, for example:

<cp:rule id="rule66">
    <cp:conditions>
        <roaming/>
        <media>video</media>
    </cp:conditions>
    <cp:actions>
        <allow>false</allow>
    </cp:actions>
 </cp:rule>

When the allow element is not found, the feature assumes allow is false.

Rule Actions

When a rule is applied, there are three possible actions the feature may have to carry out:

  1. Whitelisting (i.e. call is explicitly allowed to continue)

  2. Call barring

  3. Retargeting (only available with operator specified ODB rules)

Whitelisting

If the action of an applicable rule indicates the call should be allowed, then the feature immediately stops evaluating other rules and allows the call to proceed.

Call Barring

If the action of an applicable rule indicates that the call should be barred, the feature won’t act immediately. It will first evaluate the other rules of the same type to ensure that none of them indicate that the call should be whitelisted. If the call is not whitelisted by another rule, then the feature will execute the call barring procedure as follows:

  1. Set the OCBBarred session state flag to true to limit which features will run after MMTelOCB.

  2. Increment appropriate stats to indicate the call was barred.

  3. Check whether the method for the incoming message is INVITE or REFER, and execute the appropriate procedure as described below.

INVITE barring procedure:

  1. Check the feature configuration to determine if an announcement needs to played.

  2. Depending on the outcome:

    1. If an announcement does not need to be played, instruct sentinel to immediately terminate the call with a 603 Decline response for the INVITE request.

    2. If an announcement is to be played:

      1. Suppress online charging for the call (if applicable).

      2. Queue an announcement for the SipPlayAnnouncement feature, using the announcement ID provided in the feature configuration.

      3. Set the EndSessionAfterAnnouncement session state field to indicate to the SipPlayAnnouncement that it should terminate the session with a 603 Decline response for the original INVITE request after the announcement has been played.

REFER barring procedure:

  1. Send a SIP 403 Forbidden response for the REFER request.

  2. Search for the outbound REFER on the outbound leg’s message queue, and then remove it.

Retargeting

Only operator-specific ODB rules can be used to retarget a call. In the rule XML, the action is still listed with allow being false (i.e. bar the call), but additional configuration on the MMTelOdbOperatorSpecificTypeRuleProfileTable is used to transform the rule action into a retarget. If there are multiple applicable operator-specific ODB rules for a call, and they retarget to different destinations, or one retargets and another bars the call, then the rule with the lowest Type number will take precedence (e.g. the Type2 rule will take precedence over the Type3 rule). However, as always, an operator-specific ODB rule that explicitly whitelists the call will take precedence regardless of its number.

When it is determined that a call should be retargeted, the procedure is as follows:

  1. Retrieve the new target URI from the rule’s configuration profile on the MMTelOdbOperatorSpecificTypeRuleProfileTable.

  2. Release the original outbound leg towards the called party (at this point no signalling should have occurred on this leg, so no message is sent to do this).

  3. Generate a new outbound INVITE request from the original inbound request.

  4. Update the newly created request to retarget it, the procedure for doing this is similar to the one used by unconditional forwarding (CFU) in the MMTelCDIV feature:

    1. The Request-URI is set to the value of the new target URI and a cause=302 parameter is added.

    2. The To header is set to the value of the new target URI.

    3. The History-Info header is modified/added to indicate a diversion has occurred, the original target URI is given the 'privacy=history' parameter.

  5. Create a new outbound leg (named MMTelOCBRetargetedLeg) to send the new INVITE request, and link this leg to the calling party leg.

  6. If the rule’s configuration profile indicates that the redirected call should not be subject to online charging, then suppress online charging for the call.

  7. If the rule’s configuration profile indicates that a retarget announcement should be played, then queue an announcement with the announcement ID provided in the rule’s configuration (note that the standard barring announcement as configured on the MMTelOCBConfigProfileTable will not be played on a retarget action).

If at any point in the procedure there is a problem that prevents retargeting from working, then the feature will fall back to standard call barring behaviour (including playing the standard barring announcement if applicable).

Rule Priority

The behavior described above gives rise to a natural priority that rules will follow when multiple rules with different actions are applicable to a call.

To summarise:

  • There are three types of rules: Operator-specific ODB rules, standard ODB rules, and OCB rules.

  • Operator-specific ODB rules will always take priority over other rule types, regardless of action.

  • Standard ODB rules will take precedence over OCB rules, regardless of action.

  • Within rules of the same type, a whitelisting action will always take precedence over a barring or retargeting action.

  • If multiple operator-specific ODB rules apply and have conflicting retarget or barring actions, then the rule with the lower number will take precedence. (there are four slots available for operator-specific ODB rules, numbered one through four).

Roaming and International Determination

The MMTelOCB feature does not compute whether or not the served user is roaming or international; rather it relies on a session input fields (RoamingIndicator, International, and InternationalExHC). These fields are set by the DetermineInternationalAndRoamingStatus feature. For this reason the DetermineInternationalAndRoamingStatus feature must run before MMTelOCB in the feature execution scripts if international and roaming status need to be considered.

Playing Announcements

The MMTelOCB feature does not play announcements itself; rather it relies on setting data in session output fields (EarlyMediaAnnouncementInfoQueue and EndSessionAfterAnnouncement) if an announcement is to be played. These fields are read by the SIP Play Announcement Feature.

Based on the the data in the fields that feature will:

  • Handle the signalling required to play the announcement to the calling party.

  • Terminate the call after the announcement if instructed to do so.

For this reason the SipPlayAnnouncement feature must run after MMTelOCB in the feature execution scripts if announcements are required.

Operator Determined Barring

Operator Determined Barring provides call barring rules determined by the operator that take 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.

The Sentinel VoLTE TAS provides an extension to standard ODB that allows the operator to retarget outbound calls to an arbitrary destination. See How to provision the Operator Specific Barring rules for details of how to enable this functionality, and MMTelOCB Behaviour for details of how it is executed.

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 the request URI has a "premium-rate" parameter with the value "information".

PremiumRateCommunicationsEntertainment

Bar all outgoing communications where the request URI has a "premium-rate" parameter with the value "entertainment".

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.

The Sentinel VoLTE TAS provides an extension to standard Operator Specific Barring that allows the operator to retarget outbound calls to an arbitrary destination. See How to provision the Operator Specific Barring rules for details of how to enable this functionality, and MMTelOCB Behaviour for details of how it is executed.

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

Definitions for each of the four allowed operator specific barring rules are provided on the MMTelOdbOperatorSpecificTypeRuleProfileTable. Each profile on the table corresponds to one of the four types. Profiles are named with the format: {sentinel-selection-key}:{rule-type}, for example:

Metaswitch:Metaswitch::::Type1

Each profile has the following fields:

Name Type Default Value Description
OperatorSpecificType

String (Enum)

null

Identifies the type of the rule, should match the profile name, must be equal to one of: Type1, Type2, Type3, or Type4.

Rule

String

null

The cp:ruleset XML for the entire OSB rule.

Retarget

boolean

false

A flag to indicate whether this rule should retarget the call when the result of evaluating the cp:ruleset indicates the call should be barred.

RetargetURI

String

null

The new target URI that should be used when retargeting a call. If the Retarget flag is true, this field must contain a valid sip: or tel: URI.

PlayRetargetAnnouncement

boolean

false

A flag that indicates whether an announcement should be played if this rule triggers retargeting. This only applies if the Retarget flag is true.

RetargetAnnouncementID

int

0

The ID of the announcement that should be played if the retarget announcement is triggered. If this is 0 no announcement will be played.

DisableOnlineChargingOnRetarget

boolean

false

A flag that indicates whether online charging should be suppressed if this rule retargets the call.

Note that redirection behaviour only applies to outbound calls on an originating or forwarded TAS instance. When applied to inbound calls on a terminating TAS instance, Operator Specific Barring rules will execute standard barring behavior regardless of any retarget configuration on this profile table.

Examples

The sections below show XML data stored in the Rule field of each profile on the MMTelOdbOperatorSpecificTypeRuleConfigProfileTable. 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.

Bar 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>

Bar 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>

Bar Specific Domain for a One 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>

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 SAS Support Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

MMTel

Yes

Originating, Forwarding, and Terminating

SipAccess_SessionCheck, and SipAccess_PartyResponse

Yes

Yes

Stateless

POJO

Prerequisite features

  • SubscriberDetermination

  • FetchCMSISDN

  • DetermineChargeMode (only required when using CAP charging)

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.9.0;2.9.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

CMSISDN

String

ChargeMode

Enum

Session state output variables

Attribute Name Type Description
RoamingStatus

Enum

UNKNOWN, NATIONAL or INTERNATIONAL

RoamingIndicator

boolean

false if not roaming, true otherwise

AttemptedATI

boolean

true if an AnyTimeInterrogation has been attempted by the feature, false otherwise

DiscoveredAccessNetworkInformation

String

3GPP-GERAN;cgi-3gpp=<mnc><mcc><lac><ci>;network-provided, where <ci> defaults to 0000 when not provided in the ATI response

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 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 ▶ sentinel.volte.sip service ID ▶ sentinel.volte.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.

When invoked on a SIP response the feature checks whether a request to the HLR has not already been made and whether there is an OC-Terminating-Domain present in the SIP responses with value CS. If either is not the case then the feature finishes execution.

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.

If found, the location information is also used to generate a discovered network access information. If no other access network information is available, this will be used in charging content AVPs. The format for the generated information is 3GPP-GERAN;cgi-3gpp=<cgi>;network-provided, where <cgi> is the Cell Global ID, made up of the MCC, MNC, Location Area Code (in hex) and Cell Id (in hex) concatenated. If the Cell Id is not provided by the HLR, it will default to 0000.

OC-Roaming-Status Header

If the feature is running on a terminating MMTel instance, and CAP charging is enabled, it will attempt to add an OC-Roaming-Status header to the outbound request. The value of the header will be set to match the value of RoamingStatus.

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 SAS Support Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

No

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. .