This document covers procedures for deploying, configuring, and managing Sentinel VoLTE:
-
Features — the behaviour and configuration of each feature
-
Mappers — the behaviour of mappers
-
Mapping of GSMA IR.92 to Sentinel VoLTE Features — features that provide support for GSMA’s IR.92 specification
-
Provisioning — how to provision and configure the Sentinel VoLTE product
-
Sentinel VoLTE and Data — the various data sources for Sentinel VoLTE and how VoLTE is configured to use them
-
Session Processing — how Sentinel VoLTE processes sessions, including Initial Filter Criteria, use of the HSS via Sh, and related topics
-
Charging Information — describes the format and content of CDRs, and AVPs present in the Diameter Ro interface
-
DNS Redundancy — how to configure DNS to provide a redundant configuration
-
Resource Adaptors — interfaces used by Sentinel VoLTE to communicate with external systems
-
System Statistics — statistics defined for Sentinel VoLTE features
-
License Requirements — license requirements for running Sentinel VoLTE
![]() |
Read this document in conjunction with the Sentinel VoLTE Architecture document and see the Sentinel AGW Guide. |
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 |
|
analyses the request-uri of an originating trigger to determine if the dialed digits match the dial plan |
|
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. |
|
reads the IMS user state from the HSS, and updates session state. |
|
This feature is responsible for playing an announcement when a subscriber is making an international call. It can also bar an international call (with an optional announcement) if the subscriber does not dial a number in the international format or with an international escape code. |
|
is responsible for reading data from the HSS and writing it into Sentinel session state 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. |
|
The VoLTE Network KPI feature ( |
|
is a system feature which prevents SDP-change initiated CDRs from being written by the |
|
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. |
|
optionally strips preconditions information from initial INVITEs |
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.
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
orALERTING
based on whether a180 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) orACTIVE
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
orACTIVE
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 |
---|---|---|
|
Counter |
Incremented when the feature is triggered. |
|
Counter |
Incremented when the feature fails to start. |
|
Counter |
Incremented when the feature fails while executing. |
|
Counter |
Incremented when the feature issues a warning. |
|
Counter |
Incremented when the feature times out during execution. |
|
Counter |
Incremented when the feature successfully loads configuration data into session state. |
Session Input Variables
Variable name | Type | Comments |
---|---|---|
|
|
Used to select which profile to load from the configuration table. |
Session Output Variables
Variable name | Type | Comments |
---|---|---|
|
|
Determines whether the service will attempt to generate a CSRN from HLR data when required (using MSRN for GSM networks or TLDN for CDMA networks). |
|
|
Determines whether the service will attempt to determine the subscriber’s roaming status from the HLR when required. |
|
|
Determines where the service will attempt to retrieve third party registration data from. Possible values are |
|
|
Determines where the service will attempt to retrieve subscriber data from. Possible values are |
Configuration
Network configuration is stored in a profile table named VolteServiceConfigProfileTable
. Profiles in this table are scoped on Sentinel Selection Key.
![]() |
Directly modifying values in this profile is not recommended, they should instead be set through the Sentinel VoLTE installer. |
Attribute | Type | Default Value | Description |
---|---|---|---|
|
|
|
Determines whether the service will attempt to generate a CSRN from HLR data when required (using MSRN for GSM networks or TLDN for CDMA networks). |
|
|
|
Determines whether the service will attempt to determine the subscriber’s roaming status from the HLR when required. |
|
|
|
Determines where the service will attempt to retrieve third party registration data from. Possible values are |
|
|
|
Determines where the service will attempt to retrieve subscriber data from. Possible values are |
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 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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 IM-SSF should send charging requests to.
The OC-Replication-Information
header contains instructions on how the IM-SSF should handle session tracking and replication.
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.
It also reads the RefreshPeriod
in the SessionRefresh configuration profile table to determine the refresh period to include on the OC-Replication-Information
header when replication is enabled.
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 |
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 |
VMSCAddress |
AddressString |
If the call is CS terminating and there is no VLRNumber available then the VMSCAddress is used for the |
OcImTdpHeader |
String |
The value to use for the |
IsoCountryCode |
String |
The ISO country code that the subscriber is registered with. It is used for formatting the |
PaniMccMncs |
List<MccMnc> |
The MCCs and MNCs that the subscriber is registered with. They are used for formatting the |
SessionUACLegReplicationTrigger |
Enum |
Used to determine if replication should be indicated as enabled on the |
SessionUASLegReplicationTrigger |
Enum |
Used to determine if replication should be indicated as enabled on the |
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 |
UsedVmscNumber |
Counter |
Incremented when the VMSC address is used for the |
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 |
UsedUnknownLocationChargingGT |
Counter |
Incremented when the unknown location Charging GT is used for the |
SetOCIMTDP |
Counter |
Incremented when an |
SetOCChargingGT |
Counter |
Incremented when an |
SetOCReplicationInformation |
Counter |
Incremented when an |
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.
The feature sets the OC-Replication-Information
as described below in the Replication Information section.
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.
The feature sets the OC-Replication-Information
as described below in the Replication Information section.
Generating Charging GTs
The feature uses the CAP Charging Component to generate Charging GTs based on location data.
Replication Information
The feature includes an OC-Replication-Information
header on the request towards the IM-SSF which indicates whether replication behaviour is required.
The header value is determined based on the values of the SessionUASLegReplicationTrigger
and SessionUACLegReplicationTrigger
session input fields. If either of the fields indicated DISABLED
then the the header value will be set to disabled
, otherwise it will be set ot enabled
.
When the header value is set to enabled
, a refreshPeriod
parameter will be added as well. This parameter is used to determine the TTL value the IM-SSF should use for session ownership records when doing session tracking. It is set equal to the value of the RefreshPeriod
field in the SessionRefresh configuration profile table.
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), and also by the InternationalCallManagement feature
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:
international-exHC: This condition for international barring, excluding the home country, evaluates to true when the request URI of the outgoing SIP request:
|
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:
-
DetermineChargeMode (only required when using CAP charging)
Configuration
Configuration for this feature is in the DetermineInternationalAndRoamingStatusConfigProfileTable
. The profiles within this table have the following fields:
Parameter | Type | Description |
---|---|---|
|
Boolean |
Decide if the feature will end the call if no Visited Network can be determined. |
|
Boolean |
Explicitly add user=phone parameter and value to SIP URI during inspection. |
|
int |
The minimum length of address that will be checked. |
|
Boolean |
Whether non international format DNs, i.e. with no leading "+", should always be treated as national. |
|
Boolean |
Use a prefix address list table for the subscribers Mobile Country Code. |
|
Boolean |
Whether, when home/visited and access MCCs are found but differ, finding matching ISO CCs sets roaming to national. |
The feature will also query the Sentinel SIP Configuration profile to retrieve the home network ISO 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
andTo
address. -
If the session is terminating, then it checks the
P-Asserted-Identity
address, theFrom
address, and theReferred-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 inDetermineInternationalAndRoamingStatusConfigProfileTable
-
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.
The format of the SkipDIRSAddressList
is described by a standard address list configuration table. See Address List Configuration Profile for more information. The SkipDIRSAddressList
configuration is found in its profile within ${PLATFORM_OPERATOR_NAME}_Sentinel_AddressListConfigurationTable
.
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 visited network 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 theDetermineInternationalAndRoamingStatus_AddressListConfigurationTable
profile. There is an address list of prefixes stored in theDetermineInternationalAndRoamingStatus_AddressListEntryTable
for bothDEFAULT
and each MCC or visited network stored in theDetermineInternationalAndRoamingStatus_AddressListConfigurationTable
profile. Both tables are scoped to the Network operator.
The DetermineInternationalAndRoamingStatus_AddressListConfigurationTable
is a standard address list configuration table, see Address List Configuration Profile for more information.
The DetermineInternationalAndRoamingStatus_AddressListEntryTable
profile format is outlined by the following:
Parameter | Type | Description |
---|---|---|
|
String |
|
|
String |
The prefix address this address list entry is for — a sequence of characters matching: 0 … 9, a … f, A … F, #, *, . |
|
String |
The list id is a string that identifies the address list this entry belongs to. It has the following form: <selectionkey>:<schemaName>:<listname> |
|
String |
Name of the country for where the subscriber is located. |
|
String |
The ISO country code for the subscriber’s location. |
|
String[] |
The list of MCCs for this prefix. |
|
boolean |
Is true if and only if this prefix represents a home network. |
|
boolean |
Is true if and only if this prefix represents a visited network. |
The prefix address list to use is now determined as follows:
-
If an MCC was found and the profile field
useMCCSpecificAddressListTables
is set tofalse
:-
The feature will first attempt to use the default prefix address list named
DEFAULT
. -
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 totrue
:-
The feature will first attempt to use the prefix address list for the specific MCC.
-
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:
-
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 status
The DIRS feature can determine both whether the call is international, and whether it is international-exhc.
The has two ways for determining the international status of a call. The first does so by looking at ISO country codes, the second by looking at MCCs. ISO country codes are the preferred method, however the full set of codes required for this method is only available in specific circumstances.
If the original number did not include a +
prefix, and the profile field nonInternationalFormatDNIsNational
is set to true, then international status determination is skipped and both the International
and InternationalExHC
session state fields are set to false.
From ISO country codes
In order to determine international status from ISO country codes, three separate codes must be available:
-
The country code for the home network, which is is a part of Sentinel’s configuration and should always be available.
-
The country code for the visited network, which is retrieved as described above.
-
The country code for the destination number, which is currently only available for numbers within the North American number plan that also have geographic area codes. It will only be derived on originating calls that use the North American Numbering Plan feature.
When all three of the required country codes are available, the international status of the call will be determined based on the relationship of the three codes according to the following table:
Visited Network ISO CC | Destination Number ISO CC | International? | International-ExHC? |
---|---|---|---|
Same as home network |
Same as home network |
No |
No |
Same as home network |
Different from home network |
Yes |
No |
Different from home network |
Same as visited network |
No |
No |
Different from home network |
Same as home network |
Yes |
No |
Different from home network |
Different from both home and visited network |
Yes |
Yes |
From MCC and number prefix
The DetermineInternationalAndRoamingStatus
feature does a longest-prefix search of the prefix address list with the address string.
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 a list of MCCs present in the prefix address list entry, then 'International' is set to 'true' if the served user MCC is not present in the address list entry.
-
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 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 MCCs using the PLMN ID Analyser Component.
If it is not a home MCC and the profile field fallbackToISOCCRoamingIdentification
is set to false, the feature sets the RoamingStatus to INTERNATIONAL
and the RoamingIndicator
session state field is set to true
.
If it is not a home MCC and the profile field fallbackToISOCCRoamingIdentification
is set to true, then the feature compares the ISO Country Codes of the home and visited networks. If they match, the feature sets the RoamingStatus to NATIONAL
and the RoamingIndicator
session state field to false
. If they do not match, RoamingStatus is set to INTERNATIONAL
and the RoamingIndicator
session state field is set to true
.
If the MCCs are equal and the PLMN ID is a home PLMN ID, the feature sets the RoamingStatus to NOT_ROAMING
and the RoamingIndicator
session state field is set to false
.
If the MCCs 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 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 false
.
If the visited-network-id
is not a member of the set of home network ids, the feature sets the RoamingStatus to INTERNATIONAL
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, |
For selecting configuration data |
Report featureCannotStart, featureHasFinished if the network operator field is not set. |
CallType |
com.opencloud.sentinel.common.CallType |
One of: |
Session type of this call |
Report |
IMSDefaultPublicID |
java.lang.String |
tel URL or SIP URI |
the |
Increment statistic |
ImsInformation. ImsVisitedNetworkIdentifier |
java.lang.String |
recommended format is |
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 |
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. |
NANPNumberInfo |
com.opencloud.sentinel.numbers.NANPNumberInfo |
Data Structure |
Used to retrieve the destination ISO country code. |
ISO country code based international determination will not be used. |
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 |
|
|
Error scenarios
These scenarios trigger the following reports.
Scenario | Report |
---|---|
|
|
|
|
No Called Party Leg available from the |
|
Cannot determine a digit String to analyse in originating case |
|
Cannot determine a digit String to analyse in terminating case |
|
There is no prefix address list for a |
|
No registration data found for |
|
Registration data fetched for |
|
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=4.1].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=4.1].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. |
DeterminedInternationalUsingIsoCC |
Counter |
Incremented when ISO country codes are 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 |
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 |
AddressOnSkipList |
Counter |
Incremented when destination address matches an entry in the |
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 |
|
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 |
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 |
oc-charge-mode=cap |
MonitorCallOnly set to true, Diameter Ro charging will not be applied, ChargeMode set to |
oc-charge-mode=offline |
MonitorCallOnly set to true, Diameter Ro charging will not be applied, ChargeMode set to |
oc-charge-mode has any other value |
MonitorCallOnly set to false, Diameter Ro charging will be applied, ChargeMode set to |
oc-charge-mode parameter absent |
MonitorCallOnly set to false, Diameter Ro charging will be applied, ChargeMode set to |
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 |
|
No |
No |
Stateless |
POJO |
Session input and output variables
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 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 theCurrentRemoteLegName
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 theCurrentLocalLegName
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 |
|
Yes |
No |
Stateless |
POJO |
Prerequisite features
These features must run before DetermineVoltePlanId:
-
DetermineCallType
-
SCCDetermineSessionType (Only required on SCC AS)
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. |
ConferenceFactoryPSI |
String |
Set if the SIP request URI is a conference factory PSI supported by the platform. |
Network operator data
Parameter | Type | Description | Default |
---|---|---|---|
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 |
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 |
Analysed to determine if it corresponds to a supported conference factory PSI (when a conference call is being requested). |
![]() |
If the Request URI of the incoming sip request is a supported conference factory PSI, the PSI is stored in session state. |
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 |
![]() |
|
DialPlanEnforcement
This feature analyses the request-uri of an originating trigger to determine if the dialed digits match the dial plan
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 |
---|---|---|---|---|---|---|---|
MMTEL |
Yes |
Originating |
|
No |
No |
Stateless |
POJO |
Prerequisite features
DialPlanEnforcement should run after the DetermineVoltePlanId feature.
Session input and output variables
Session input variables
Session state variable name | Variable type | Comments |
---|---|---|
SentinelSelectionKey |
SentinelSelectionKey |
|
Session output variables
Session state variable name | Variable type | Comments |
---|---|---|
RejectedCallAsDialPlanDoesNotMatch |
boolean |
The call is being rejected |
AnnouncementID |
int |
The announcement to play (for SipPlayAnnouncement) |
EndSessionAfterAnnouncement |
int |
End the session with this sip response, after playing an announcement (for SipPlayAnnouncement) |
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 → DialPlanEnforcement
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.DialPlanEnforcement"
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 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 |
IgnoringAddress |
Incremented when analysis is not required |
DialPlanMatched |
Incremented when the call is allowed as the dialed digits match the dial plan |
DialPlanIsNotMatched |
Incremented when the call is rejected as the dialed digits do not match the dial plan |
Configuration
The DialPlanEnforcement feature uses configuration data from the DialPlanEnforcementConfigProfileTable
and the NormalizationFeatureConfigProfileTable
.
DialPlanEnforcementConfigProfileTable
The profiles within this table have the following fields:
Parameter | Type | Description |
---|---|---|
|
boolean |
Whether a session should be ended with an announcement if the dialed digits do not match the dial plan |
|
int |
The announcement to play if the dialed digits do not match the dial plan. The announcement ID should correspond to an ID that has been configured for SipPlayAnnouncement |
|
int |
The SIP response code to use when ending the session |
|
String[] |
Set of prefixes to check for in the dialed digit string. PrefixesToCheck may be empty. The length of PrefixesToCheck, MinimumNumberOfDigitsPerPrefix and MaximumNumberOfDigitsPerPrefix must be the same |
|
int[] |
Minimum allowed length of dialed digits (after the prefix) per prefix. Must have the same number of elements as PrefixesToCheck. The value of each element may be 0 and must be less then the corresponding element in MaximumNumberOfDigitsPerPrefix |
|
int[] |
Maximum allowed length of dialed digits (after the prefix) per prefix. Must have the same number of elements as PrefixesToCheck. The value of each element in MaximumNumberOfDigitsPerPrefix must be greater than the corresponding element in MinimumNumberOfDigitsPerPrefix |
|
int |
The required length of dialed digits if there are no prefixes configured or matched. The value must be within the range 7 .. 20. |
![]() |
DialPlanEnforcement checks for prefixes in order from the longest prefix first. |
NormalizationFeatureConfigProfileTable
The DialPlanEnforcement uses the following fields from profiles within this table:
Parameter | Type | Description |
---|---|---|
|
String |
National dialling prefix (for example, 0) |
|
String |
Escape code for dialing international numbers (for example, 00) |
|
Integer |
The minimum length of an address for it to be normalizable |
Behaviour
The first step is to determine if DialPlanEnforcement should be applied to the incoming trigger. The following conditions must be satisfied:
-
the sentinel selection key plan ID field is MMTEL_ORIG
-
the request-uri is a phone number (either a Tel URL or a SIP URI with a phone number in the user part)
-
the DialPlanEnforcement feature is enabled (
config.EndSessionOnEnforcement
is true) -
the number of dialed digits is greater than, or equal to, the minimum number for analysis
![]() |
The minimum number for analysis is the minimum value of these properties:
|
If DialPlanEnforcement should be applied, then the following analysis of the request-uri is conducted.
-
If the dialed digits is an international number, starts
normalizerconfig.NationalPrefix
or starts withnormalizerconfig.InternationalEscapeCode
then accept the trigger otherwise continue analysis. -
Check for prefixes in the dialed digit string in order from the longest prefix first. If there is a prefix match, then compare the number of digits after the prefix to the allowed minimum and allowed maximum configured for that prefix. If the number of digits in within range accept the trigger, otherwise reject the trigger by requesting an announcement to be played (
config.EndSessionAnnouncementID
) and ending the session. -
If no prefix match is made, compare the number of dialed digits to
config.DefaultMaximumNumberOfDigits
. If the number of digits is less than, or equal to,config.DefaultMaximumNumberOfDigits
then accept the trigger otherwise reject the trigger by requesting an announcement to be played (config.EndSessionAnnouncementID) and ending the session.
![]() |
A SAS event is generated when DialPlanEnforcement accepts a trigger or rejects a trigger. |
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 |
|
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 |
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 |
CallType |
Enum |
Affects whether |
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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:
-
The enabled flag corresponding to the call type is
true
in the feature configuration profile. -
The charge mode for the call is
CAP
-
If the call is terminating and not international roaming, the
OnlyChargeTerminatingCallsIfInternationalRoaming
config flag isfalse
.
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 |
|
defaultCallHandling |
|
serviceKey |
See below. |
scfAddress.address |
The address part of the |
scfAddress.nature |
The nature part of the |
scfAddress.numberingPlan |
The numbering plan part of the |
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.
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:
-
SIP Subscriber Determination — in order to know who the subscriber is for the call.
Session input and output variables
Session input variables
Session State variable name | Variable type |
---|---|
Subscriber |
String |
![]() |
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.
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.
![]() |
From Sentinel 3.1.0 if several registration records are present for the IMPU the feature will select the valid (newest) registration per UE based on private identity, +sip.instance, and the creation time of the record. Prior to 3.1.0 it was not guaranteed that the correct registration would be used. |
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 |
Network operator data
This feature reads registrar configuration from the Registrar Configuration Table.
The data is scoped according to a Sentinel selection key.
Session input and output variables
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 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 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. |
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. |
ImsUserStateSourceNotApplicable |
Counter |
Incremented when Sentinel VoLTE is configured to determine the IMS user state from the HSS |
ResponseLatency |
Sampled |
Records elapsed time between querying the Cassandra database and getting a response (in milliseconds). |
Behaviour
The feature reads the RegistrarConfiguration
to determine which one of the assocuris
or the assocuris_v2
tables to query. See Registrar Configuration Table for more information. If the private-id
is being used as the registrar primary key, then assocuris_v2
is queried. It then queries the chosen table in 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:
-
SIP Subscriber Determination — in order to know who the subscriber is for the call.
Network operator data
This feature reads registrar configuration from the Registrar Configuration Table.
The data is scoped according to a Sentinel selection key.
Session input and output variables
Session input variables
Session State variable name | Variable type |
---|---|
Subscriber |
String |
![]() |
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 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 reads the RegistrarConfiguration
to determine which one of the assocuris
or the assocuris_v2
tables to query. See Registrar Configuration Table for more information. If the private-id
is being used as the registrar primary key, then assocuris_v2
is queried. It then queries the chosen table in 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.
IMSUserStateLookupFromHSS
This feature reads the IMS user state from the HSS, and updates session state. Information is read during InitialDP processing. It reads the IMS user state via the Sh Cache Microservice. For more information about the Sh Cache Microservice see Sh Cache Microservice architecture.
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 |
Session input and output variables
Statistics
IMSUserStateLookupFromHSS statistics are tracked by the IMSUserStateLookupFromHSS feature and can be found under the following parameter sets:
SLEE-Usage ▶ sentinel.volte.ss7 service ID ▶ sentinel.volte.ss7 SBB ID ▶ IMSUserStateLookupFromHSS 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 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.scc-lookup-ims-user-state-hss-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 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. |
SubscriberNotRegistered |
Counter |
Incremented if the subscriber is not registered in the IMS. |
ImsUserStateQueried |
Counter |
Incremented when the ShCM is queried for a subscriber’s IMS user state. |
ImsUserStateRetrieveSuccess |
Counter |
Incremented when the ShCM lookup succeeds. |
ImsUserStateRetrieveFail |
Counter |
Incremented when the ShCM lookup fails. |
ImsUserStateUnknownSubscriber |
Counter |
Incremented when the ShCM lookup fails, as the subscriber in unknown in the IMS. |
ImsUserStateRetrieveSuccessNoData |
Counter |
Incremented when the ShCM lookup succeeds, but no IMS user state data is returned. |
ImsUserStateSourceNotApplicable |
Counter |
Incremented when Sentinel VoLTE is configured to determine the IMS user state from Third Party Registration |
Behaviour
The feature queries the ShCM for the IMS user state of the Served User (as identified by the IMS Public Identity that is extracted from the InitialDP). The IsLoggedIn
session state field is set to true if the IMS user state returned indicates the server user is registered in the IMS. Otherwise the IsLoggedIn
session state field is set to false.
InternationalCallManagement
This feature is responsible for playing an announcement when a subscriber is making an international call. It can also bar an international call (with an optional announcement) if the subscriber does not dial a number in the international format or with an international escape code.
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 |
---|---|---|---|---|---|---|---|
MMTEL |
Yes |
Originating |
SipAccess_SessionCheck |
Yes |
No |
Stateless |
POJO |
Behaviour
The InternationalCallManagement (ICM) can enforce that when making an international call, the user actually dialled the country code for that country. If that requirement is not met, the feature can bar the call with an announcement. A call is a valid international call if it is in the international format, contains an international escape code, and the special case for 1+10 digit number if part of the North American Dial Plan (NANP). ICM’s behaviour is configurable; specific parts of ICM’s behaviour are determined by the InternationalCallManagementConfigProfile (ICMCP) Profile Table.
ICM will check if the call is an international call. If it an international call, ICM will continue otherwise if not an international call, will do nothing more.
If the DestinationCountryIsoCC session state field is populated, the feature will retrieve the ICMCP profile with the corresponding ISOCountryCode. If the corresponding ICMCP profile is not found, the feature will use the default profile.
Using the loaded ICMCP configuration, the feature will determine whether an announcement is needed and if the call needs to be barred. ICM will check if the AnalysedDialledNumber session state field matches one of the following: contains the International_Escape_Code, is dialled in the International_Format or if NANP is enabled, matches the special case handling for to allow international calls within the North American Numbering Plan when dialled as 1+10 digit. If the AnalysedDialledNumber does not match any of the checks that validate it as an international number, the call will be barred and the loaded ICMCP profile’s MissingInternationalCallDialPrefixAnnouncement will be queued (if configured).
If the call is not barred, then the announcement set by the loaded ICMCP profile’s InternationalCallAnnouncementID value will be queued (if configured).
If NANP is enabled, then the behaviour of ICM can be optionally configured per country - the behaviour is only supported in the NANP.
Relationship with number translation features
When deciding whether to bar a call based on whether it was dialled in an international format, the ICM feature considers the dialled number as it was originally received by Sentinel.
This means that if a number translation feature such as Location Based Dialling or SIP Short Code modifies the number and that results in the call being considered international, then the call will be barred if the original number was dialled without a country code.
International status determination
The international status of a call is identified by the DetermineInternationalAndRoamingStatus (DIRS) feature. As the ICM feature acts on all international calls, it becomes particularly important that the DIRS feature is configured correctly. Any numbers or number prefixes that are being erroneously classified as international should be added to prefix address list for that feature.
Prerequisite features
The feature must run after the DetermineInternationalAndRoamingStatus and VerticalServiceCodes features.
Session state input variables
Variable name | Variable type | Description |
---|---|---|
International |
Boolean |
Describes whether or not the call is an international call |
AnalysedDialledNumber |
TaggedNumber |
Tagged number contains details about the number dialled and is check if the dialled number is in an international format or has been dialled with an international escape code. |
DestinationCountryIsoCC |
String |
The two letter ISO country code the destination area code corresponds to. Set by the DetermineInternationalAndRoamingStatus feature |
SentinelSelectionKey |
SentinelSelectionKey |
For selecting configuration data |
Session state output variables
Variable name | Variable type | Description |
---|---|---|
ICMCallBarred |
boolean |
Describes whether the call was barred |
ICMAnnouncementQueued |
boolean |
Describes whether an announcement was queued to be played |
EarlyMediaAnnouncementInfoQueue |
List<SipAnnouncementInformation> |
List of all the Early Media info announcements to be played for the call |
EndSessionAfterAnnouncement |
int |
If enabled, will end the call session once the set announcement with the specified BARRING_RESPONSE_CODE response |
Configuration
This feature reads the configuration in the feature configuration profile table InternationalCallManagementProfileTable
to determine specific parts of the InternationalCallManagement feature’s behaviour.
InternationalCallManagementProfileTable
Feature configuration is stored on the InternationalCallManagementProfileTable
.
Data is scoped according to a Sentinel Selection Key; however the profile does support using an ISO country code as additional data on the key.
Parameter | Type | Description | Default |
---|---|---|---|
ISOCountryCode |
String |
The two letter ISO country code |
DEFAULT |
MissingInternationalCallDialPrefixCallBarring |
boolean |
If enabled, bar the call if it is international but the number was not dialled with an international escape code or in international format. |
false |
MissingInternationalCallDialPrefixAnnouncementID |
int |
The ID of the announcement to play when a call is barred due to the Missing International Call Dial Prefix Call Barring setting (0 disables the announcement). |
0 |
InternationalCallAnnouncementID |
int |
The ID of the announcement to play when a call is international and is not barred by this feature (0 disables the announcement). |
0 |
Statistics
InternationalCallManagement 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 → InternationalCallManagement
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.InternationalCallManagement"
Name | Type | Description |
---|---|---|
IncrementCallBarred |
Counter |
Incremented each time a call is barred |
IncrementPlayingCallBarredAnnouncement |
Counter |
Incremented when aan international call barred announcement has been queued. |
IncrementPlayingInternationalCallAnnouncement |
Counter |
Incremented when an international call announcement has been queued. |
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 containingAnnouncement-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 |
|
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 |
OcsAnnouncementPlayed |
boolean |
Set to true when |
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. |
StripPreconditions
This feature optionally strips preconditions information from initial INVITEs .
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 |
Terminating |
|
Yes |
No |
Stateless |
POJO |
Behaviour
When SIP forking occurs, this may cause issues with upstream devices that cannot properly handle preconditions negotiation on multiple early dialogs. If this is a problem, then this can be worked around by stripping preconditions from the initial INVITE, if requested by another feature that is performing SIP forking. The StripPreconditions feature detects whether any other features have requested this behaviour, and removes preconditions from the outbound initial INVITE.
The StripPreconditions feature works as follows.
Features that execute prior to the StripPreconditions feature add legs to a session state variable variable called StripPreconditionsLegNames
. Currently only MMTelParallelFA and SCCTADSParallelRouting features add legs to the collection, although any custom feature is permitted to add legs. When the StripPreconditions feature runs, it checks the StripPreconditionsLegNames
session state variable and performs the following.
-
check if feature’s
EnabledFlag
istrue
. If not selected the feature ends -
strip precondition attributes a=curr, a=des, and a=conf from the SDP of the INVITE. If there are no attributes to strip the feature ends.
-
strip the "preconditions" option tag in the Supported header from the INVITE
The feature supports the removal of preconditions from initial INVITEs and retarget INVITEs.
Prerequisite features
The feature must run before SDPMonitor mode "post" and DiameterPerLegInfo features.
Session state input variables
Variable name | Variable type | Description |
---|---|---|
StripPreconditionsLegNames |
Set<String> |
Collection of leg names that will have preconditions information stripped from initial INVITEs. |
Network operator data
This feature reads the EnabledFlag
in the feature configuration profile table StripPreconditions
to determine if the feature will strip preconditions.
Parameter | Type | Description | Default |
---|---|---|---|
EnabledFlag |
boolean |
true or false |
false |
Statistics
StripPreconditions 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 → StripPreconditions
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.StripPreconditions"
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 |
RemovePreconditionsFields |
Counter |
Incremented when the feature strips preconditions attributes from INVITE SDP |
InviteNotFoundInQueue |
Counter |
Incremented when the feature is unable to find the INVITE from an internal system queue |
MessageQueueEmpty |
Counter |
Incremented when the feature is unable to find any SIP messages from an internal system queue |
InvalidSDP |
Counter |
Incremented when the feature fails to parse the SDP |
Values examined
Value Name | Source | Notes |
---|---|---|
StripPreconditionsLegNames |
Session State |
Collection of leg names that will have preconditions stripped. The collection can be updated by any feature that has access to the session state variable |
SDP |
Outgoing INVITE request |
Check if precondition attributes a=curr, a=des, and a=conf are present in the SDP of the INVITE. If yes strip, if no then don’t execute any further. |
Supported Header |
Outgoing INVITE request |
Remove 'preconditions' option tag from the Supported header unless there are no preconditions attributes present in the SDP. |
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 |
|
Yes |
Yes |
Stateless |
POJO |
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:
-
sets the GSM SCF address to the
SentinelSCCPAddress
configuration value -
sets the destination SCCP address to the
HlrSCCPAddress
configuration value -
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 |
|
COLP |
|
CLIR |
|
COLR |
|
ODB |
|
ODB |
|
Call Forwarding |
|
Call Waiting |
|
Call Hold |
GSM ASN.1 Schema to Session-State Fields
The mapping below describes how the AnyTimeSubscriptionInterrogation
result is mapped into the MMTel Subscriber Data Representation.
ss-Status ASN.1 field
The field ss-Status
is used by almost all supplementary services and defines the service state. Each service defines a set of possible values based on ss-Status, so called State Vectors
. A state vector is formed of 4 variables: Provisioning State, Registration State, Activation State and HLR Induction State. This feature only reads the Activation State
, i.e. "A and Q" bits.
For more information see 3GPP TS 23.011 - Technical realization of Supplementary Services.
CLIP
ASN.1 Field (From) | Session-State Field (To) | Mapping Rules |
---|---|---|
ClipData.ss-Status |
MMTelOIPServiceData.active |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
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 |
|
Yes |
Yes |
Stateless |
SBB |
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:
-
the Service-Indication
-
the fully qualified class name of the Transparent Data Codec class - used to parse the returned XML into a Java Object
-
a list of adaptor class names (fully qualified class names)
-
an option to enable or disable the query
-
a default value for operator authorized fields
This table, by default, has entries for MMTEL-Services
, IMS-ODB-Information
, and Metaswitch-TAS-Services
configured. The MMTEL-Services
query is enabled by default, while IMS-ODB-Information
and Metaswitch-TAS-Services
are 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
-
the feature requests the Sh Cache Microservice RA to fetch the transparent user data document
-
Once a result is available, each adaptor in the list of adaptors is invoked in order to populate session state
MMTel-Services 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 |
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 |
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 |
MMTELServices/complete-originating-identity-restriction/operator-originating-identity-presentation-restriction/mode |
MMTelOIRServiceData.mode |
If not specified the field is set to |
MMTELServices/complete-originating-identity-restriction/originating-identity-presentation-restriction/default-behaviour |
MMTelOIRServiceData.defaultBehaviourType |
If not specified the field is set to |
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 |
MMTELServices/complete-terminating-identity-presentation/operator-terminating-identity-presentation/restriction-override |
MMTelTIPServiceData.override |
If not specified the field is set to |
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 |
MMTELServices/complete-terminating-identity-restriction/operator-terminating-identity-presentation-restriction/mode |
MMTelTIRServiceData.mode |
If not specified the field is set to |
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 |
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 |
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.
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 |
MMTELServices/complete-communication-diversion/communication-diversion/NoReplyTimer |
MMTelCDIVServiceData.noReplyTimeOut |
The default value is specified in Network operator data for MMTEL CDIV |
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 |
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 |
|
MMTELServices/complete-flexible-alerting/operator-flexible-alerting-group/membership |
MMTelFAMembership |
|
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 |
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
IMS-ODB-Information Schema to Session-State Fields
The IMS-ODB-Information schema is configured (but disabled) 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.
Operator Determined Barring
For more information see Operator Determined Barring.
Metaswitch-TAS-Services Schema to Session-State Fields
The Metaswitch-TAS-Services schema is configured (but disabled) 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.
Basic Services
XPath in document (From) | Session-State Field (To) | Default values |
---|---|---|
Metaswitch-Services/basic-settings/additional-attributes |
MetaswitchBasicSettings.additionalAttributes |
If not present in the XML document, the field is set to an empty map. |
Location Based Dialling
XPath in document (From) | Session-State Field (To) | Default values |
---|---|---|
Metaswitch-Services/location-based-dialling/group-id |
MetaswitchLocationBasedDialling.groupId |
If not present in the XML document, the field is set to |
Metaswitch-Services/basic-settings/additional-attributes |
MetaswitchLocationBasedDialling.additionalAttributes |
If not present in the XML document, the field is set to an empty map. |
For more information on location based dialling see Location Based Dialling
Forward To Voicemail
XPath in document (From) | Session-State Field (To) | Default values | Notes |
---|---|---|---|
metaswitch-services/complete-forward-to-voicemail/forward-to-voicemail/voicemail-server |
MetaswitchForwardToVoicemail.voicemailServer |
If not present in the XML document, the field is set to |
|
metaswitch-services/complete-forward-to-voicemail/forward-to-voicemail/additional-attributes AND Metaswitch-Services/complete-forward-to-voicemail/operator-forward-to-voicemail/additional-attributes |
MetaswitchForwardToVoicemail.additionalAttributes |
If not present in the XML document, the field is set to an empty map of String → String. |
Where there is an attribute with the same name in the operator and user sections of the document, the value in the user section takes precedence. |
metaswitch-services/complete-forward-to-voicemail/forward-to-voicemail/active |
MetaswitchForwardToVoicemail.active |
If not present in the XML document, the field is set to |
For more information on forwarding to voicemail see:
Companion Device
XPath in document (From) | Session-State Field (To) | Default values | Notes |
---|---|---|---|
metaswitch-services/complete-companion-device/companion-device/@active |
CompanionDeviceData.active |
|
|
metaswitch-services/complete-companion-device/operator-companion-device/@authorized |
CompanionDeviceData.operatorAuthorized |
Value read from Configuration |
|
metaswitch-services/complete-companion-device/operator-companion-device/radio-access |
CompanionDeviceData.radioAccess |
If not present in the XML document, the field is set to |
Value is a |
metaswitch-services/complete-companion-device/operator-companion-device/msisdn |
CompanionDeviceData.msisdn |
If not present in the XML document, the field is set to |
|
metaswitch-services/complete-companion-device/operator-companion-device/additional-attributes AND metaswitch-services/complete-companion-device/companion-device/additional-attributes |
CompanionDeviceData.additionalAttributes |
If not present in the XML document, the field is set to an empty map of String → String. |
Where there is an attribute with the same name in the operator and user sections of the document, the value in the user section takes precedence. |
Example Radio Access field value
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<radio-access xmlns="http://metaswitch.com/XMLSchema/tas">
<network>PS</network>
</radio-access>
For more information on companion device support, see Companion Devices.
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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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:
-
an interim AVP CDR using the
cdr-ra
-
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.
![]() |
By default, Sentinel runs 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 |
|
RegistrationRecords |
List<com.opencloud.sentinel.state.RegistrationRecord> |
Contains subscriber information retrieved from the Registrar and HSS or Cassandra |
|
CallReferenceNumber |
byte[] |
Contains the Call Reference Number used in queries to the HLR |
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.
![]() |
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 |
UseRfControlRa |
boolean |
Whether ACRs should be written using the |
VoLTE Network KPI Feature
The VoLTE Network KPI feature (VolteNetworkKPI
) increments the "Call Success" and "Post Dial Delay" counters, which you can combine with other stats to gauge network traffic.
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 |
---|---|---|---|---|---|---|---|
SCCOrig, SCCTerm, MMTelOrig, MMTelTerm |
No |
Originating and Terminating |
|
Yes |
No |
Stateless |
POJO |
Prerequisite features
You must run these features before VolteNetworkKPI
:
-
RecordTimestamps, which stores
initialRingingResponseTimestamp
-
StoreHeaderInfo, which sets
isOCTerminatingDomainPresent
-
DetermineCauseCode. The causeCode is used to check
Success Response Codes
Behaviour
The VolteNetworkKPI
feature is used to increment the "Call Success" and "Post Dial Delay" counters. The feature uses information collected by Sentinel during the call session to increment the relevant counters in the SipEndSession
execution point.
Call Success
Call Success is determined by comparing the initial INVITE final response code with a list of "Success" codes. The term success is from the perspective of Sentinel VoLTE where it has "successfully" processed the call according to a list of response codes.
The default list of response codes is
SuccessResponseCodes: [200,486,487,404,603]
Internally the VolteNetworkKPI
feature uses the value set in the DetermineCauseCode feature that in turn uses the final response code from the downstream leg, or an error code in case of an internal error.
![]() |
The |
The VolteNetworkKPI
feature further categorizes calls into 'onNet' and 'Unknown'. If the call is triggered in SCC-Orig
or MMTel-Orig
then the feature checks if OC-Terminating-Domain
header is present via isOCTerminatingHeaderPresent
flag. If the flag is present, then the call is considered onNet
.
If the flag isOCTerminatingHeaderPresent
is false, or the feature is executed in the MMTel-Term
or SCC-Term
, then InterOperatorIdentifier
sessionState’s OriginatingInterOperatorIdentifier
(orig-ioi) and TerminatingInterOperatorIdentifier
(term-ioi) are evaluated. A call is considered onNet
if both the orig-ioi
and term-ioi
values are the home plmn (via PLMNAnalyser). Otherwise, the call is Unknown
.
Success Example
-
486
is configured as a success response code. -
Home network VoLTE subscriber calls a non VoLTE subscriber, which triggers a
SCC-Orig
plan on Sentinel VoLTE. -
The non VoLTE subscriber returns a
486
. -
The DetermineCauseCode feature sets the cause code to
-486
. -
The
VolteNetworkKPI
feature incrementsKPISccOrigUnknownSuccess
andKPISccOrigUnknownAttempt
due to-
486
is a success response code. -
The
onNet
status is unknown as there is noOC-Terminating-Domain
header and no location information that isorig-ioi
andterm-ioi
is present inP-Charging-Vector
header.
-
Non Success Example
-
404
is not configured as a success response code. -
A non VoLTE subscriber calls a home network VoLTE subscriber calls a non VoLTE subscriber, which triggers a
MMTel-Term
plan on Sentinel VoLTE. -
The home network VoLTE subscriber returns a
404
. -
The DetermineCauseCode feature sets the cause code to
-404
. -
The
VolteNetworkKPI
feature incrementsKPIMMTelTermUnknownAttempt
due to.-
404
is not a success response code. -
The
onNet
status is unknown as there is location information present in theP-Charging-Vector
header, butorig-ioi
indicates it’s a non-home network.
-
Post Dial Delay
Post Dial Delay is the time difference between the initial INVITE
(sessionInitiated) and the first 180 Ringing
or ACK
(sessionEstablished). The VolteNetworkKPI
feature uses these values to calculate the delay and then increment the time interval counters.
![]() |
Provisional |
Post Dial Delay is calculated in SCCOrig
, MMTelOrig
, MMTelTerm
, and SCCTerm
execution points. Therefore an onNet
call could potentially increment four time interval counters, one for each planId.
The counter uses the format postDialDelay<planId><time interval counter>
. So for example if a 180
is received in the SCCOrig
execution point 1400 ms after the session is initiated, then the postDialDelaySCCOrig1000to1500ms
counter is incremented.
Session state inputs and outputs
Inputs
Name | Type | Format | Description | Behaviour if null/invalid |
---|---|---|---|---|
SentinelSelectionKey |
SentinelSelectionKey |
selection key + for example, |
For selecting 'success' response codes from |
Increment InputParameterErrors common cleanup actions |
DiameterCauseCode |
Integer |
null or a integer |
Either final SIP response code or internal error set by the DetermineCauseCode feature. |
If the value is null, the |
InitialRingingResponseTimestamp |
Long |
null or a long |
Timestamp recorded by the RecordTimestamps feature on first 180 Ringing. |
If the value is null, the |
SessionEstablished |
long |
0 or non 0 |
Timestamp recorded by the B2BUA feature when on ACK is received from the Calling Party. |
If 0, the |
SessionInitiated |
long |
0 or non 0 |
Timestamp recorded by Sentinel when an initial INVITE is received from the Calling Party. |
If 0, the |
OriginatingInterOperatorIdentifier |
String |
null or String |
|
If the value is null, the |
TerminatingInterOperatorIdentifier |
String |
null or String |
|
If the value is null, the |
Statistics
VolteNetworkKPI
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.VolteNetworkKPI
Name | Type | Description |
---|---|---|
kPISccOrigOnNetAttempts |
counter |
Incremented on every 'onNet' SCCOrig call. |
kPISccOrigOnNetSuccess |
counter |
Incremented on 'success' 'onNet' SCCOrig call. |
kPISccOrigUnknownAttempts |
counter |
Incremented on every 'unknown' SCCOrig call. |
kPISccOrigUnknownSuccess |
counter |
Incremented on 'success' 'unknown' SCCOrig call. |
kPIMmtelTermOnNetAttempts |
counter |
Incremented on every 'onNet' MMTelTerm call. |
kPIMmtelTermOnNetSuccess |
counter |
Incremented on a 'success' 'onNet' MMTelTerm call. |
kPIMmtelTermUnknownAttempts |
counter |
Incremented on every 'unknown' MMTelTerm call. |
kPIMmtelTermUnknownSuccess |
counter |
Incremented on every 'unknown' 'success' MMTelTerm call. |
postDialDelayMMTelOrig0to500ms |
counter |
Incremented if the delay ⇐ 500 ms. |
postDialDelayMMTelOrig501to1000ms |
counter |
Incremented if the delay > 500 ms and ⇐ 1000 ms. |
postDialDelayMMTelOrig1001to1500ms |
counter |
Incremented if the delay > 1000 ms and ⇐ 1500 ms. |
postDialDelayMMTelOrig1501to2000ms |
counter |
Incremented if the delay > 1500 ms and ⇐ 2000 ms. |
postDialDelayMMTelOrig2001to2500ms |
counter |
Incremented if the delay > 2000 ms and ⇐ 2500 ms. |
postDialDelayMMTelOrig2501to3000ms |
counter |
Incremented if the delay > 2500 ms and ⇐ 3000 ms. |
postDialDelayMMTelOrigOver3000ms |
counter |
Incremented if the delay > 3000 |
postDialDelayMMTelTerm0to500ms |
counter |
Incremented if the delay ⇐ 500 ms. |
postDialDelayMMTelTerm501to1000ms |
counter |
Incremented if the delay > 500 ms and ⇐ 1000 ms. |
postDialDelayMMTelTerm1001to1500ms |
counter |
Incremented if the delay > 1000 ms and ⇐ 1500 ms. |
postDialDelayMMTelTerm1501to2000ms |
counter |
Incremented if the delay > 1500 ms and ⇐ 2000 ms. |
postDialDelayMMTelTerm2001to2500ms |
counter |
Incremented if the delay > 2000 ms and ⇐ 2500 ms. |
postDialDelayMMTelTerm2501to3000ms |
counter |
Incremented if the delay > 2500 ms and ⇐ 3000 ms. |
postDialDelayMMTelTermOver3000ms |
counter |
Incremented if the delay > 3000 |
postDialDelaySCCOrig0to500ms |
counter |
Incremented if the delay ⇐ 500 ms. |
postDialDelaySCCOrig501to1000ms |
counter |
Incremented if the delay > 500 ms and ⇐ 1000 ms. |
postDialDelaySCCOrig1001to1500ms |
counter |
Incremented if the delay > 1000 ms and ⇐ 1500 ms. |
postDialDelaySCCOrig1501to2000ms |
counter |
Incremented if the delay > 1500 ms and ⇐ 2000 ms. |
postDialDelaySCCOrig2001to2500ms |
counter |
Incremented if the delay > 2000 ms and ⇐ 2500 ms. |
postDialDelaySCCOrig2501to3000ms |
counter |
Incremented if the delay > 2500 ms and ⇐ 3000 ms. |
postDialDelaySCCOrigOver3000ms |
counter |
Incremented if the delay > 3000 |
postDialDelaySCCTerm0to500ms |
counter |
Incremented if the delay ⇐ 500 ms. |
postDialDelaySCCTerm501to1000ms |
counter |
Incremented if the delay > 500 ms and ⇐ 1000 ms. |
postDialDelaySCCTerm1001to1500ms |
counter |
Incremented if the delay > 1000 ms and ⇐ 1500 ms. |
postDialDelaySCCTerm1501to2000ms |
counter |
Incremented if the delay > 1500 ms and ⇐ 2000 ms. |
postDialDelaySCCTerm2001to2500ms |
counter |
Incremented if the delay > 2000 ms and ⇐ 2500 ms. |
postDialDelaySCCTerm2501to3000ms |
counter |
Incremented if the delay > 2500 ms and ⇐ 3000 ms. |
postDialDelaySCCTermOver3000ms |
counter |
Incremented if the delay > 3000 |
Configuration
The VolteNetworkKPIProfileTable
profile table stores SIP response codes that determine whether the call was a Success
.
Parameter | Type | Description |
---|---|---|
SuccessResponseCodes |
Integer[] |
A list of SIP response codes |
An example DefinitelyNotOpenCloud::::
profile:
SuccessResponseCodes: [200,486,487,404,603]
![]() |
The = VoLTE SIP AVP CDR Feature :toc: macro :toclevels: 4 :toc-title: On this page… 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 |
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 |
|
RegistrationRecords |
List<com.opencloud.sentinel.state.RegistrationRecord> |
Contains subscriber information retrieved from the Registrar and HSS or Cassandra |
|
CallReferenceNumber |
byte[] |
Contains the Call Reference Number used in queries to the HLR |
== 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.
![]() |
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 :indexpage: :sortorder: 30
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 |
|
manages writing the conference view state to Cassandra DB for consumption by the MMTel Conference Subscription feature. |
|
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 |
|
uses information from a SIP |
|
replaces the undisclosed identity with the shared identity for an originating call from a companion device where such hiding has been requested |
|
is responsible for reading subscriber location data from the HLR and writing it into Sentinel session state variable fields. |
|
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. |
|
sets the companion device headers to the initial INVITE when the subscriber has been provisioned with companion devices. |
Additionally, the MMTel AS provides support for a number of Vertical Service Code Features.
Feature | What it does |
---|---|
updates the Request URI of a SIP INVITE, based on the location of the calling party and the dialled number |
|
redirects the calling party to their voicemail server. |
|
performs a list of predefined HTTP PUT operations to update subscriber data in an XCAP server. |
= Call Barring Features :indexpage:
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 |
|
provides a mechanism for an operator to augment the implicit or explicit condition of a MMTelOCB barring rule, so that the rule will also apply when the called party number matches some prefix with optional length criteria |
|
provides a mechanism for preceding features to bar a call on behalf of the terminating user. It takes precedence over ODB and MMTelICB |
= General Feature Barring :toc: macro :toclevels: 4 :toc-title: On this page…
General Feature Barring provides a mechanism for preceding features to bar a call on behalf of the terminating user. It takes precedence over ODB and MMTelICB .
== What is General Feature Barring
General Feature Barring is an enhancement to Incoming Call Barring, to enable other features to trigger barring.
General Feature barring uses the BarIncomingCall
session state field to signal that another feature wishes a call to be barred.
When BarIncomingCall
is True
then the call will be barred.
General Feature Barring takes precedence over ODB and ICB rules.
= MMTelICB :toc: macro :toclevels: 4 :toc-title: On this page…
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
-
DetermineCallType
-
SubscriberDetermination
-
Determine International and Roaming Status (used for Roaming, International and International-exHC detection)
![]() |
For announcements, SIPPlayAnnouncement is a dependent feature; but it is not a prerequisite. |
== Interaction with OIP
== 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 |
bxref:mmtel-subscriber-data-representation#mmtelicbservicedata[MMTelICBServiceData] |
Complex |
Read from the HSS or HLR in SubscriberDataLookupFromHSS or SubscriberDataLookupFromHLR |
RoamingIndicator |
Boolean |
Set by the Determine International and Roaming Status feature. |
International |
Boolean |
Set by the Determine International and Roaming Status feature. |
InternationalExHC |
Boolean |
Set by the Determine International and Roaming Status feature. |
BarIncomingCall |
Boolean |
Set by other preceding features to trigger General Feature Barring. |
== 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. The identity of the other party is taken from the P-Asserted-Identity
and From
headers from the incoming SIP message, and the condition will evaluate to true if either of those values matches it.
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.
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>
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>
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>
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>
![]() |
Note the attribute of the 'except' element is now 'domain'. |
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>
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>
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>
![]() |
Depending on the value of the 'allow' element of the rule, the rule can essentially become an 'allowlist' or a 'blocklist'. |
=== 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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 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 |
FallbackToNetworkDefaultServiceConfig |
Counter |
incremented when the feature uses the network default service configuration as the session state does not contain the feature specific subscriber service data. |
== Behaviour
=== Determination
If operator data is not present, the ICB feature:
-
Increments an error statistic.
-
Logs a message at the
Fine
level. -
Informs the Sentinel core that the feature is not configured appropriately (
Invalid Configuration
). -
Exits.
If General Feature Barring determines that a call should be barred - [Barring Action] below proceeds.
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.
Incoming ODB [Rule Processing] occurs as below.
If no ODB rules match, ICB [Rule Processing] occurs as below.
If either rule set determines allow=false
, the [Barring Action] is performed as below.
If either set determines allow=true
or no rules are matched, the ICB feature sets the session output variable ICBBarred
to false
and finishes without modifying any further state.
=== Rule Processing When the feature processes a set of rules (either ODB or ICB):
For each rule, if | then |
---|---|
|
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 |
|
all matching rules had the action |
|
![]() |
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. |
=== Barring Action
If a ruleset determines allow=false
or GFB bars the call then…
The ICB feature sets the session output variable ICBBarred
to true
.
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 :toc: macro :toclevels: 4 :toc-title: On this page…
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 is 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
-
DetermineCallType
-
Determine International and Roaming Status (used for Roaming, International and International-exHC detection)
![]() |
For announcements, SIPPlayAnnouncement is a dependent feature; but it is not a prerequisite. |
== Network Operator Data
The MMTelOCB feature retrieves configuration from three profile tables and an address list:
-
The
MMTelOCBConfigProfileTable
provides the basic configuration for the feature. -
The
MMTelOdbOperatorSpecificTypeRuleProfileTable
provides operator-specific ODB rule configuration. -
The
${platform.operator.name}_PrefixBarring_AddressListEntryTable
maps dialled numbers to prefix barring classifications. -
The
PrefixBarringClassificationsTable
defines matching criteria and the barring treatment for classes of dialled prefixes.
=== 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 |
=== 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.
=== ${platform.operator.name}_PrefixBarring_AddressListEntryTable
An address list called ${platform.operator.name}_PrefixBarring_AddressListEntryTable
is used to classify the called number for prefix based barring.
=== PrefixBarringClassificationsTable
The prefix barring address list references one or more classifications for calls to addresses that match the prefix.
Details of how each classification is treated are stored in PrefixBarringClassificationsTable
profile table.
== Session Input Variables
Variable name | Type | Comments |
---|---|---|
Complex |
Read from the HSS or HLR in SubscriberDataLookupFromHSS or SubscriberDataLookupFromHLR |
|
Complex |
Read from the HSS in SubscriberDataLookupFromHSS |
|
RoamingIndicator |
Boolean |
Set by the Determine International and Roaming Status feature |
International |
Boolean |
Set by the Determine International and Roaming Status feature |
InternationalExHC |
Boolean |
Set by the Determine International and Roaming Status feature |
== Session Output Variables
Variable name | Type | Comments |
---|---|---|
OCBBarred |
boolean |
Set to |
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 |
== 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=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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. |
PrefixBasedRuleApplied |
Counter |
Incremented when a rule was applied due to prefix barring. Either |
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 |
RedirectionSuccessful |
Counter |
Incremented when an attempt to redirect the outbound |
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. |
ClassifiedNumberByPrefix |
Counter |
Incremented when prefix barring classifies the dialled number as triggering some barring treatment(s). |
FoundMultipleNonConflictingPrefixBarringClassifications |
Counter |
Incremented when prefix barring classifies the dialled number and selects multiple classifications, all with separate treatments. |
FoundConflictingPrefixBarringClassifications |
Counter |
Incremented when prefix barring classifies the dialled number and selects multiple classifications, with some duplicate treatments. Such as
|
FallbackToNetworkDefaultServiceConfig |
Counter |
Incremented when the feature uses the network default service configuration as the session state does not contain the feature specific subscriber service data. |
== 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. The identity of the other party is taken from the Request-URI
and To
(or Refer-To
, for REFER messages) headers from the incoming SIP message, and the condition will evaluate to true if either of those values matches it.
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.
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>
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>
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>
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>
![]() |
Note the attribute of the 'except' element is now 'domain'. |
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>
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>
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>
![]() |
Depending on the value of the 'allow' element of the rule, the rule can essentially become an 'allowlist' or a 'blocklist'. |
=== 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
orForwarded
. -
OCB service data for the subscriber has been successfully loaded and the
OperatorAuthorized
flag in the data is set totrue
. -
Network operator configuration for the feature is present and has been successfully loaded.
-
The invoking trigger for the feature is an inbound SIP
INVITE
orREFER
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:
-
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. Prefix barring interacts with this step as described in Prefix Based Barring Behaviour
-
The remaining ODB rules are evaluated, again if any of the rules apply, their action will be executed and the final evaluation phase skipped.
-
Prefix based premium-rate communication barring options are evaluated as described in Prefix Based Barring Behaviour
-
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:
-
Allowlisting (that is, call is explicitly allowed to continue)
-
Call barring
-
Retargeting (only available with operator specified ODB rules)
==== Allowlisting
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 allowlisted. If the call is not allowlisted by another rule, then the feature will execute the call barring procedure as follows:
-
Set the
OCBBarred
session state flag totrue
to limit which features will run afterMMTelOCB
. -
Increment appropriate stats to indicate the call was barred.
-
Check whether the method for the incoming message is
INVITE
orREFER
, and execute the appropriate procedure as described below.
INVITE
barring procedure:
-
Check the feature configuration to determine if an announcement needs to played.
-
Depending on the outcome:
-
If an announcement does not need to be played, instruct sentinel to immediately terminate the call with a
603 Decline
response for theINVITE
request. -
If an announcement is to be played:
-
Suppress online charging for the call (if applicable).
-
Queue an announcement for the SipPlayAnnouncement feature, using the announcement ID provided in the feature configuration.
-
Set the
EndSessionAfterAnnouncement
session state field to indicate to theSipPlayAnnouncement
that it should terminate the session with a603 Decline
response for the originalINVITE
request after the announcement has been played.
-
-
REFER
barring procedure:
-
Send a SIP
403 Forbidden
response for theREFER
request. -
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 allowlists the call will take precedence regardless of its number.
When it is determined that a call should be retargeted, the procedure is as follows:
-
Retrieve the new target URI from the rule’s configuration profile on the
MMTelOdbOperatorSpecificTypeRuleProfileTable
. -
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).
-
Generate a new outbound
INVITE
request from the original inbound request. -
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:
-
The
Request-URI
is set to the value of the new target URI and acause=302
parameter is added. -
The
To
header is set to the value of the new target URI. -
The
History-Info
header is modified/added to indicate a diversion has occurred, the original target URI is given the 'privacy=history' parameter.
-
-
Create a new outbound leg (named
MMTelOCBRetargetedLeg
) to send the newINVITE
request, and link this leg to the calling party leg. -
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.
-
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 different types of rules: Prefix based
OperatorAllow
, Prefix basedOperatorBar
, Operator-specific ODB rules, Prefix based premium-rate communication barring, standard ODB rules, and OCB rules. -
The overall priority is
-
Prefix based
OperatorAllow
-
Operator-specific ODB rules that allowlist a call, regardless whether applied by matching their defined condition, or by prefix based treatment
-
Prefix based
OperatorBar
-
Operator-specific ODB rules that bar a call, regardless whether applied by matching their defined condition, or by prefix based treatment
-
Prefix based premium-rate communication barring
-
Standard ODB rules
-
OCB rules
-
-
Within rules of the same type, an allowlisting 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 SipPlayAnnouncement 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 :toc: macro :toclevels: 4 :toc-title: On this page…
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.
== 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 incoming 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 when roaming outside the home PLMN country. The IncomingBarring 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> <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. |
Certain prefix-based Barring Treatments will also affect the matching of these premium-rate barring options.
The information on ODB data in the HSS indicates which options should be evaluated.
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 types 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:
|
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 :toc: macro :toclevels: 4 :toc-title: On this page…
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: |
Rule |
String |
null |
The |
Retarget |
boolean |
false |
A flag to indicate whether this rule should retarget the call when the result of evaluating the |
RetargetURI |
String |
null |
The new target URI that should be used when retargeting a call. If the |
PlayRetargetAnnouncement |
boolean |
false |
A flag that indicates whether an announcement should be played if this rule triggers retargeting. This only applies if the |
RetargetAnnouncementID |
int |
0 |
The ID of the announcement that should be played if the retarget announcement is triggered. If this is |
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>
= Prefix Based Barring :toc: macro :toclevels: 4 :toc-title: On this page…
Prefix Based Barring provides a mechanism for an operator to augment the implicit or explicit condition of a MMTelOCB barring rule, so that the rule will also apply when the called party number matches some prefix with optional length criteria .
== What is Prefix Based Barring
Prefix Based Barring is an enhancement to Outgoing Call Barring, to trigger certain barring treatments based on the dialled number.
== How to Configure Prefix Based Barring
=== ${platform.operator.name}_PrefixBarring_AddressListEntryTable
An address list called ${platform.operator.name}_PrefixBarring_AddressListEntryTable
is used to classify the called number for prefix based barring.
It is an extension of the standard Address List Entry Profile and has the same structure with the following additional field.
Parameter | Type | Description |
---|---|---|
… |
… |
… |
NumberClassification |
String[] |
A list of 1 or more items where each is the name of a |
=== PrefixBarringClassificationsTable
The prefix barring address list references a classification for the matching prefixes.
Details of how that classification is treated are stored in PrefixBarringClassificationsTable
profile table.
Attribute Name | Type | Default | Description |
---|---|---|---|
ClassificationID |
String |
n/a |
The identifier of this classification, and the name of this profile. |
DisplayName |
String |
n/a |
User readable name for the classification that will be used to select it in the address list. |
MatchMinLength |
Integer |
no minimum length criteria |
The minimum number of digits in dial string to match this classification. |
MatchMaxLength |
Integer |
no maximum length criteria |
The maximum number of digits in dial string to match this classification. |
MatchInternational |
boolean |
false |
When true, this classification will only match international targets. |
BarringTreatment |
String |
n/a |
How to treat matching calls. See below. |
OverrideOCBAnnouncement |
boolean |
n/a |
When set to true |
AnnouncementID |
int |
n/a |
An announcement to be played when a matching number is called and barred and |
=== Barring Treatments
BarringTreatment | Description |
---|---|
OperatorAllow |
The call will not be barred. |
OperatorBar |
The call will be barred if no OSB rules or |
OSBType1 |
Operator Specific barring rules will be processed as though the |
OSBType2 |
Operator Specific barring rules will be processed as though the |
OSBType3 |
Operator Specific barring rules will be processed as though the |
OSBType4 |
Operator Specific barring rules will be processed as though the |
PremiumRateInformation |
Premium-rate communication barring options will be processed as though the call was classified with |
PremiumRateEntertainment |
Premium-rate communication barring options will be processed as though the call was classified with |
=== Configuring an OSB rule to only be triggered by a prefix
![]() |
If an OSB rule is being configured solely to be triggered by prefix barring then use <rule-deactivated/> as the rule’s condition so that it is not inadvertently triggered otherwise. |
== Behaviour
Before other OCB rules are applied, the feature extracts the target from the Request URI. The target consists of the dialled digit string, and any international number indicator. If no digits can be found ODB and OCB proceed as normal.
The target will have had normalisation applied.
If the target is international but within the home country code, the home country code prefix is stripped from the digits, and the target is treated as national.
The feature attempts longest prefix matching of the target’s digits in the address list. If no address list entry is found ODB and OCB proceed as normal.
If an address list entry is found the NumberClassification
values are used to retrieve corresponding profiles from the PrefixBarringClassificationsTable
.
For each of these classification profiles in specified order:
-
If the national/international indicator of the target conflicts with the classification’s
MatchInternational
value, that profile is discarded. -
If the number of digits in the target conflicts with the
MatchMinLength
orMatchMaxLength
values in the profile, that profile is discarded.
If there are no remaining profiles ODB and OCB proceed as normal.
If more than one remaining profile has the same BarringTreatment
value, the stats counter FoundConflictingPrefixBarringClassifications
is incremented and all except the first of those profiles are discarded. This avoids having more than one applicable announcement configuration for an applied rule.
If one of the remaining profiles has a treatment of OperatorAllow
, the call is allowed and the OCB feature completes.
If the subscriber has ODB data provisioned, then Operator-specific ODB rules are applied, except the condition of each rule is assumed true if any of the remaining profiles has a BarringTreatment
value corresponding to the OSB rule type. If any of the remaining profiles has a treatment of OperatorBar
that takes precedence over any Operator-specific ODB rules that bar, but not those that whitelist. The classification with OperatorBar
treatment may override the announcement settings.
If an OSB rule bars the call due to a prefix barring treatment, and does not retarget it, then the profile may override the announcement settings.
Premium-rate communication barring options are then evaluated against PremiumRateInformation
and/or PremiumRateEntertainment
BarringTreatment
values. If the call is barred due to any of these, then the profile may override the announcement settings.
See Bar Outgoing Premium-Rate Communication for more information on premium-rate communication barring.
If the subscriber has no ODB data, then any profiles with a treatment of OperatorBar
will be applied, but profiles with OSB rule types or premium-rate communication barring will have no effect.
If the call has not been barred or allowed, ODB and OCB proceed as normal.
= Determine Shared And Undisclosed Identities :toc: macro :toclevels: 4 :toc-title: On this page…
This feature uses information from a SIP INVITE
and session state to determine if the call includes shared or undisclosed identity information associated with a companion device. The feature is run in both originating and terminating session execution plans.
== 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 |
---|---|---|---|---|---|---|---|
MMTEL |
Yes |
Originating and Terminating |
|
Yes |
Yes |
Stateless |
POJO |
== Prerequisite features
These features must run before DetermineSharedUndisclosedIdentities:
-
SubscriberDataLookupFromHlr/SubscriberDataLookupFromHss
== Session input variables
Session State variable name | Variable type |
---|---|
SentinelSelectionKey |
SentinelSelectionKey |
MetaswitchCompanionDevice |
CompanionDeviceData |
Subscriber |
String |
== Session output variables
Session State variable name | Variable type | Comments |
---|---|---|
SharedIdentitySip |
String |
SIP shared identity used by the companion device. |
SharedIdentityTel |
String |
TEL shared identity used by the companion device. |
UndisclosedIdentity |
String |
The undisclosed identity of the companion device. |
HideUndisclosedIdentities |
Boolean |
Set to true if call is to the undisclosed identity of the companion device. Used by the HideUndisclosedIdentity feature. |
BarIncomingCall |
Boolean |
Set to true if the call is made to undisclosed identity and configuration is set to bar. |
== Network operator data This feature reads HideUndisclosedIdentities
in the feature configuration profile table HideUndisclosedIdentityConfigProfileTable
to determine if the feature should execute.
Parameter | Type | Description | Default |
---|---|---|---|
HideUndisclosedIdentities |
Boolean |
Determines if calls to Undisclosed Identities should be hidden. |
true |
== Statistics
DetermineSharedUndisclosedIdentities 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 → DetermineSharedUndisclosedIdentities
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.DetermineSharedUndisclosedIdentities"
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 |
UnableToDetermineUndisclosedIdentity |
Counter |
Incremented when the feature fails to find the subscriber id, sharedIdentitySip, and sharedIdentityTel when determining if undisclosed and shared identity logic should be applied. |
SubscriberIsUndisclosedIdentity |
Counter |
Incremented if the subscriber is a companion device undisclosed identity. |
SubscriberIsSharedIdentity |
Counter |
Incremented if the subscriber is a companion device shared identity. |
HideUndisclosedIdentities |
Counter |
Incremented if the subscriber is undisclosed and the call will be barred. |
== Behaviour
The feature checks session state, feature configuration, and the incoming SIP request in order to set session state fields, which are subsequently used by downstream features associated with companion calls.
-
If triggered in the originating execution plan the feature sets session state fields to hide the companion device number from the callee.
-
If triggered in the terminating execution plan, when the call is made to an undisclosed identity, then the feature sets the
BarIncomingCall
session state field. This is used by the General Barring feature to bar the incoming call.
=== Values examined
Value Name | Source | Notes |
---|---|---|
MetaswitchCompanionDevice |
Session State |
Store information used to determine if the call is from or to a companion device. |
SharedIdentitySip |
Session State |
Set by the DetermineSharedUndisclosedIdentities feature which is used by the HideUndisclosedIdentity feature. |
SharedIdentityTel |
Session State |
Set by the DetermineSharedUndisclosedIdentities feature which is used by the HideUndisclosedIdentity feature. |
UndisclosedIdentity |
Session State |
Set by the DetermineSharedUndisclosedIdentities feature. |
HideUndisclosedIdentities |
Session State |
Flag set by the DetermineSharedUndisclosedIdentities feature to indicate to the HideUndisclosedIdentity feature to "hide" the identity of the caller by replacing SIP headers with the shared identity of the companion device. |
BarIncomingCall |
Session State |
Set by the DetermineSharedUndisclosedIdentities feature which is used by the GeneralBarring Feature to bar the call. |
= DetermineRoamingFromHlr :toc: macro :toclevels: 4 :toc-title: On this page…
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 |
|
Yes |
Yes |
Stateless |
POJO |
== Prerequisite features
-
SubscriberDetermination
-
FetchCMSISDN
-
DetermineChargeMode (only required when using CAP charging)
== Session state input variables
Attribute Name | Type |
---|---|
Subscriber |
String |
CMSISDN |
String |
ChargeMode |
Enum |
== Session state output variables
Attribute Name | Type | Description |
---|---|---|
RoamingStatus |
Enum |
|
RoamingIndicator |
boolean |
|
AttemptedATI |
boolean |
|
DiscoveredAccessNetworkInformation |
String |
|
SubscriberLocationMscAddress |
AddressString |
MSC Address extracted from |
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 the HLR MAP Configuration, the SIP Sentinel Configuration and the Determine International and Roaming Status 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:
-
sets the GSM SCF address to the
SentinelSCCPAddress
configuration value -
sets the destination SCCP address to the
HlrSCCPAddress
configuration value -
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. It will then check whether the MAPLocationInformation
contains an MSC number, and if so, it will write this to the session state field SubscriberLocationMscAddress
.
If the location information is found, the MCC and MNC are evaluated using the PLMN ID Analyser Component to determine whether the subscriber is roaming or not. If the fallbackToISOCCRoamingIdentification
field of the Determine International and Roaming Status Configuration table is set to true
and the PLMN ID Analyser finds that the MCC does not match the home MCC, then the feature falls back to an ISO CC comparison. If the home and visited ISO CCs match then the RoamingStatus
is set to NATIONAL
and the RoamingIndicator
is set to false
. If the ISO CCs do not match then the RoamingStatus
is set to INTERNATIONAL
and the RoamingIndicator
is set to true
. If the fallbackToISOCCRoamingIdentification
field is set to false
then mismatching MCCs immediately sets RoamingStatus
to INTERNATIONAL
. When the MCCs do match the MNCs are compared by the PLMN ID Analyser Component and the RoamingStatus
and RoamingIndicator
session state fields are set accordingly. The default values of RoamingStatus
and RoamingIndicator
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 :toc: macro :toclevels: 4 :toc-title: On this page…
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 |
|
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 :indexpage:
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 :toc: macro :toclevels: 4 :toc-title: On this page …
The MMTelDetermineFlexibleAlertingMode
feature determines if and how the Flexible Alerting features will execute based on feature configuration and the HSS Subscriber Data. .
The Determine Flexible Alerting Mode feature runs before the Flexible Alerting features. It reads subscriber data and configuration profile tables to determine the flexible alerting mode and supplies this information to the MMTelParallelFA and MMTelSequentialFA features as a session state field. |
== Feature cheat sheet
B2BUA Instance | SAS Support | Originating/Terminating | Point(s) in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature |
---|---|---|---|---|---|---|---|
All |
No |
Terminating |
Subscriber Check |
Yes |
Yes |
Stateless |
POJO |
== Prerequisite features
== Network Operator Data
The data present in JSLEE profile table MMTelDetermineFAConfigProfileTable
is used to configure the behaviour of the Flexible Alerting features: MMTelParallelFA and MMTelSequentialFA. This profile table is scoped by the sentinel key
and the Pilot Number
.
Here is an example of a profile entry:
'SomeOperatorName::::sip:callcentre@someoperator.com': ModeIsParallel: true ParallelMaxWaitTimeout: 5000 SequentialAnyResponseTimeout: 2000 SequentialFinalResponseTimeout: 5000 AddHistoryInfoHeader: false AddMpParam: false
The default profile entry is not scoped by a Pilot Number
:
'SomeOperatorName::::': ModeIsParallel: true ParallelMaxWaitTimeout: 5000 SequentialAnyResponseTimeout: 2000 SequentialFinalResponseTimeout: 5000 AddHistoryInfoHeader: false AddMpParam: false
Variable Name | Type | Comments |
---|---|---|
ParallelMaxWaitTimeout |
int |
Set the amount of time in milliseconds that the MMTelParallelFA waits for a final response before canceling the session for a pilot number. |
ModeIsParallel |
boolean |
Set the mode to parallel (true) or sequential (false). |
SequentialAnyResponseTimeout |
int |
Set the amount of time in milliseconds that the MMTelSequentialFA waits for a any response from the INVITE before start alerting the next member. |
SequentialFinalResponseTimeout |
int |
Set the amount of time in milliseconds that the MMTelSequentialFA waits for a final response from the INVITE before start alerting the next member. |
AddHistoryInfoHeader |
boolean |
Determines whether to add |
AddMpParam |
boolean |
If adding |
== Session Input Variables
Variable Name | Type | Comments |
---|---|---|
bxref:mmtel-subscriber-data-representation#mmtelfaservicedata[MMTelFAServiceData] |
Complex |
Read from the HSS in SubscriberDataLookupFromHSS |
== Session Output Variables
Variable Name | Type | Comments |
---|---|---|
FlexibleAlertingMode |
Enum |
Determines whether the |
FlexibleAlertingGroupMode |
Enum |
Determines whether the |
== Statistics
MMTelDetermineFAMode 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 → MMTelDetermineFAMode
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.MMTelDetermineFAMode"
Statistic | Type | Incremented when… |
---|---|---|
Started |
Counter |
each time the feature runs |
FAModeStarted |
Counter |
each time the feature runs |
FailedDuringExecution |
Counter |
a fatal error occurs while the feature is executing |
FailedToStart |
Counter |
Sentinel VoLTE encounters an error while attempting to start the feature. |
IssuedWarning |
Counter |
a non-fatal problem is encountered and the feature issues a warning. |
TimedOut |
Counter |
the feature takes too long to complete and Sentinel VoLTE aborts execution. |
FAModeNoFA |
Counter |
the feature fails to trigger Flexible Alerting under FA mode |
FANoProfile |
Counter |
no valid profile is loaded for poilt subscriber |
FAValidPilotNumber |
Counter |
subscriber data equals the requestUri header. |
FallbackToNetworkDefaultServiceConfig |
Counter |
incremented when the feature uses the network default service configuration as the session state does not contain the feature specific subscriber service data. |
== Behaviour
When the feature starts, it tries to load the configuration profile for the pilot number present in the flexible alerting subscriber data. The table MMTelDetermineFAConfigProfileTable
is expected to contain a profile with name scoped by the sentinel selection key
and the Pilot Number
, i.e, SomeOperatorName::::sip:callcentre@someoperator.com
.
If there is no profile for the pilot number the feature try to get the configuration from the default profile: SomeOperatorName::::
.
When there is no suitable profile the FlexibleAlertingMode
is set to NONE
and the FlexibleAlertingGroupMode
is set to GROUP_NONE
. It means that the neither MMTelParallelFA nor MMTelSequentialFA will run.
When there is a suitable profile, the feature checks if the flexible-alerting is active by checking the authorized
field in the flexible-alerting Subscriber Data. If the service is not active, i.e authorized="false"
, neither MMTelParallelFA nor MMTelSequentialFA will run. The HSS schema for flexible alerting defines two sets of services that can contain the key authorized
: operator-flexible-alerting
and operator-flexible-alerting-group
. The feature checks both to define if the service is authorized. The table below shows the logic:
operator-flexible-alerting authorized |
operator-flexible-alerting-group authorized |
service status |
true |
true |
active |
true |
null |
active |
null |
true |
active |
false |
any |
inactive |
any |
false |
inactive |
null |
null |
inactive |
When flexible alerting is active, the group type in the Subscriber Data (single-user
or multiple-users
) is written into the Session State variable FlexibleAlertingGroupMode
. The FlexibleAlertingMode
Session State field is set according to the value in the configuration profile (ModeIsParallel
attribute).
== Subscriber data examples === MULTIPLE_USERS
HSS Subscriber Data
<?xml version="1.0" encoding="UTF-8"?> <Sh-Data> <RepositoryData> <ServiceIndication>MMTEL-Services</ServiceIndication> <SequenceNumber>1</SequenceNumber> <ServiceData> <MMTelServices xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy"> <complete-flexible-alerting> <operator-flexible-alerting authorized="true"/> <operator-flexible-alerting-group authorized="true"> <identity>sip:friends@home1.opencloud.co.nz</identity> <group-type>multiple-users</group-type> <membership>permanent</membership> <members> <member active="true">sip:bob@home1.opencloud.co.nz</member> <member active="true">sip:charlie@home1.opencloud.co.nz</member> <member active="true">sip:daisy@home1.opencloud.co.nz</member> </members> </operator-flexible-alerting-group> </complete-flexible-alerting> </MMTelServices> </ServiceData> </RepositoryData> </Sh-Data>
Profile configuration
ModeIsParallel: true ParallelMaxWaitTimeout: 20000 SequentialAnyResponseTimeout: 2000 SequentialFinalResponseTimeout: 5000
In the example above, the group sip:friends@home1.opencloud.co.nz
has three active members. The FlexibleAlertingGroupMode is set to MULTIPLE_USERS
, the FlexibleAlertingMode is set to PARALLEL
, and the timeout is set to 20 seconds.
=== SINGLE_USER
HSS Subscriber Data
<Sh-Data> <RepositoryData> <ServiceIndication>MMTEL-Services</ServiceIndication> <SequenceNumber>1</SequenceNumber> <ServiceData> <MMTelServices xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy"> <complete-flexible-alerting> <operator-flexible-alerting authorized="true"/> <operator-flexible-alerting-group authorized="true"> <identity>sip:bob@home1.opencloud.co.nz</identity> <group-type>single-user</group-type> <membership>permanent</membership> <members> <member active="true">sip:bob@home1.opencloud.co.nz</member> <member active="true">sip:bob-mobile@home1.opencloud.co.nz</member> <member active="true">sip:bob-desk@home1.opencloud.co.nz</member> </members> </operator-flexible-alerting-group> </complete-flexible-alerting> </MMTelServices> </ServiceData> </RepositoryData> </Sh-Data>
Profile configuration
ModeIsParallel: false ParallelMaxWaitTimeout: 5000 SequentialAnyResponseTimeout: 2000 SequentialFinalResponseTimeout: 5000
In the example above, the group sip:bob@home1.opencloud.co.nz
has three active members. The FlexibleAlertingGroupMode is set to SINGLE_USER
, the FlexibleAlertingMode is set to SEQUENTIAL
and the timeout is for receiving any response from a member is set to 2 seconds and the timeout for receiving a final response from a member is 5 seconds.
= MMTelParallelFA :toc: macro :toclevels: 4 :toc-title: On this page…
The MMTelParallelFA feature implements the Flexible Alerting service, by alerting the group members in parallel
== Feature Cheat Sheet
B2BUA Instance | Originating / Terminating | SAS Support | Point(s) in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature |
---|---|---|---|---|---|---|---|
MMTEL |
No |
Terminating |
Sip_Access_Subscriber_Check, Sip_Access_Party_Request, Sip_Access_Party_Response, Sip_Access_Service_Timer, SipMidSession_Party_Request, Sip_Mid_Session_Party_Response, SipLegEnd |
Yes |
Yes |
Statefull |
POJO |
== Statistics
MMTelParallelFA 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 → MMTelParallelFA
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].feature.MMTelParallelFA"
Name | Type | Incremented when … |
---|---|---|
Started |
Counter |
each time the feature runs |
FailedDuringExecution |
Counter |
a fatal error occurs while the feature is executing |
FailedToStart |
Counter |
Sentinel VoLTE encounters an error while attempting to start the feature. |
IssuedWarning |
Counter |
a non-fatal problem is encountered and the feature issues a warning. |
TimedOut |
Counter |
the feature takes too long to complete and Sentinel VoLTE aborts execution |
ProcessingRequest |
Counter |
processing a request message. |
ProcessingResponse |
Counter |
processing a response from the downstream forked legs. |
InviteRequestReceived |
Counter |
the original INVITE is received. |
CancelRequestReceived |
Counter |
a CANCEL message is received. |
ProvisionalResponseReceived |
Counter |
a 1xx message is received. |
GroupMemberAlerted |
Counter |
an INVITE request is sent to a group member. |
LegReleased |
Counter |
a dialog leg is released. |
UpstreamForkCreated |
Counter |
the feature creates a new leg towards the calling party. It happens on the provisional responses. |
TriggeredOnResponse |
Counter |
the feature is triggered on a response message. |
TriggeredOnRequest |
Counter |
the feature is triggered on a request message. |
TriggeredOnTimer |
Counter |
the feature is triggered on a timmer. |
TimeoutTimerCancelled |
Counter |
the feature cancel the timer. |
TimeoutTimerSet |
Counter |
the feature sets the timer. The timer is set before the INVITE is sent to the first group member. |
ExitedEarlyNoMembersToAlert |
Counter |
there is just one member in the group and it is the pilot number. |
Received480 |
Counter |
receives a 480 (Temporarily Unavailable) response from a member |
Received486 |
Counter |
receives a 486 (Busy Here) response from a member |
Received408 |
Counter |
receives a 408 (Timeout) response from a member |
Received404 |
Counter |
receives a 404 (Not found) response from a member |
ReceivedSuccess |
Counter |
receives a 200 (OK) response from a member |
RespondedUpstreamWith480 |
Counter |
the feature sends a 480 (Temporarily Unavailable) to the calling party. |
RespondedUpstreamWith486 |
Counter |
the feature sends a 486 (Busy Here) to the calling party. |
RespondedUpstreamWith408 |
Counter |
the feature sends a 408 (Timeout) to the calling party. |
RespondedUpstreamWith404 |
Counter |
the feature sends a 404 (Not found) to the calling party. |
RespondedUpstreamWithSuccess |
Counter |
the feature sends a 200 (OK) to the calling party. |
== Interaction with other MMTel Services
If CDIV Unconditional is active for the Pilot Identity, CDIV Unconditional procedures will be applied and no FA group member will be alerted.
=== CDIV Busy
If CDIV Busy is active for the Pilot Identity, CDIV Busy procedures will be applied if the pilot number is considered busy. The definition of Busy for the pilot number depends on the group type: single-user
or multiple-users
. For single-user
, when one member is busy the pilot number is busy, while for multiple-uses
all group members have to be busy for the pilot number to be considered busy.
=== CDIV No Reply and CDIV Not Reachable
If the FA Pilot Number is considered in a state of No Reply
or Not Reachable
then the CDIV procedures for those MMTel services will be applied.
If the FA Pilot Identity has CDIV Not Registered active, the procedures for CDIV Not Registered will be applied.
=== MMTelOIP
OIP applied to any FA group member when OIP is active for the FA Pilot Identity.
=== MMTelTIP
If the FA Pilot Identity did not apply TIR, the termination identification is the FA Pilot Identity.
=== MMTelTIR
If the FA Pilot Identity has TIR activated, the termination identification is not presented.
=== MMTelICB
If the FA Pilot Identity has ICB activated, the procedures for ICB will be applied.
=== MMTelOCB
If any FA group member has OCB activated, the procedures for OCB will be applied for that member.
== Network Operator Data
The data present in JSLEE profile table MMTelDetermineFAConfigProfileTable
is used to configure the behaviour of the Parallel Flexible Alerting feature.
Variable Name | Type | Comments |
---|---|---|
ParallelMaxWaitTimeout |
int |
Set the amount of time in milliseconds that the MMTelParallelFA feature waits before canceling the session for a pilot number. |
AddHistoryInfoHeader |
boolean |
Determines whether to add |
AddMpParam |
boolean |
If adding |
== Session Input Variables
Variable Name | Type | Comments |
---|---|---|
MMTelFAServiceData |
Complex |
Service data read from the HSS |
FlexibleAlertingGroupMode |
Enum |
Determines whether single user or multi-user Flexible Alerting is used. |
== Session Output Variables
Variable Name | Type | Comments |
---|---|---|
SuppressCdiv |
Boolean |
Indicates whether response should be ignored by the MMTel CDIV feature. |
ParallelFATimerID |
int |
Indicates the MMTelParallelFA timer identification. |
StripPreconditionsLegNames |
<Set>String |
The MMTelParalleFA adds each parallel legname to this Set which is used by the StripPreconditions feature to remove preconditions (if StripPreconditions EnabledFlag is selected). |
== Behaviour
The MMTelParallelFA implements the Flexible Alerting in parallel. It reads the MMTelFAServiceData
session variable for the group information and issues INVITE requests towards all members in parallel using SIP parallel forking.
The INVITE request URI will have two parameters added to it.
-
The first is the Cause Parameter with the value always set to
cause=302
. -
The second is the MMTel Service Type Parameter with the value set to
mmtel-service-type=11
for flexible alerting.
When a member answers the call with 200 (OK) the feature cancels all other sessions towards the other members and finishes the call setup procedures between the calling party and the member that answered.
It also controls the state of the FA Pilot Identity regarding busy, not reachable and no reply states. The determination of those states, depends on the members responses and on the FA group type: single-user
or multiple-users
. For further information regarding the state of a Pilot Identity see Flexible Alerting.
== OC-Retarget Header
The OC-Retarget header is added by MMTel Flexible Alerting to communica