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

Both

  • SipAccess_SessionCheck

Yes

No

Stateless

POJO

Will only run if indicated by Vertical Service Code

Cassandra storage

The feature utilises the Cassandra database to store the destination number to forward to.

Data Schema

The Cassandra table for Location Based Dialling exists in a keyspace named opencloud_location_based_dialling

  • For a production environment, the keyspace can be created such that it is replicated. A sample command for creating this keyspace is:

CREATE KEYSPACE IF NOT EXISTS opencloud_location_based_dialling WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 3 };
  • For testing purposes, replication may not be necessary. A sample CQL command for creating such a keyspace is:

CREATE KEYSPACE IF NOT EXISTS opencloud_location_based_dialling WITH REPLICATION={'class' : 'SimpleStrategy', 'replication_factor' : 1};

Once the keyspace is created, the required tables can be created. The following CQL statements provides the structure of the required table.

USE opencloud_location_based_dialling;

CREATE TABLE IF NOT EXISTS opencloud_location_based_dialling.location_based_dialling_data_3gpp (
  dialled_number text,
  cell_id text,
  destination text,
  identifier text,
  PRIMARY KEY (cell_id, dialled_number, identifier)
);

CREATE TABLE IF NOT EXISTS opencloud_location_based_dialling.location_based_dialling_uploaded_files (
  name text,
  upload_time timestamp,
  data blob,
  identifier text,
  PRIMARY KEY (name, upload_time, identifier)
) WITH CLUSTERING ORDER BY (upload_time DESC);

Configuration

Configuration for this feature is stored in an address list with address list ID DefaultActions, and can be configured in the LocationBasedDialling_AddressListEntryTable profile table. The profiles within this table have the following fields:

Parameter Type Description

Address

String

The digit string that this configuration is for (e.g.: '611').

FailCall

boolean

Fail the call if no destination number can be determined for any reason.

PlayAnnouncement

boolean

Play an announcement if no destination number can be determined for any reason.

AnnouncementId

Integer

The ID of the announcement to play if no destination number can be determined, if 'Play Announcement' is enabled.

DefaultDestination

String

The default phone number to forward to if no destination number can be determined, and 'Fail Call' is disabled.

Session Input Variables

Session State variable name Type Comments
PerformLocationBasedDialling

boolean

Set by the Vertical Service Code feature. Indicated whether or not the feature should run.

SentinelSelectionKey

SentinelSelectionKey

Determines which configuration to use.

CallType

CallType

Determines whether or not to update the To header.

Session Output Variables

Session State variable name Type Comments
EarlyMediaAnnouncementQueue

List<Integer>

Updated announcement queue with default action announcement ID, if any.

Statistics

LocationBasedDialling 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 → LocationBasedDialling
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.LocationBasedDialling"

Statistic Incremented when…​
 Started

the feature runs

 FailedToStart

Sentinel VoLTE encounters an error while attempting to start the feature

 IssuedWarning

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

 FailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 TimedOut

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

 PlayingAnnouncement

an announcement is scheduled

 EndedCall

a call is ended without playing an announcement

 PerformedDefaultAction

no destination could be determined and the configured default action is performed

 UpdatedRequestUri

the Request URI of the outgoing INVITE is updated

 RetrievedCellIdFromAccessNetworkInfo

a usable location is extracted from P-Access-Network-Info

 RetrievedCellIdFromCellularNetworkInfo

a usable location is extracted from Cellular-Network-Info

 CassandraQueried

Cassandra is queried for the destination address

 CassandraResponseReceived

a success response is received from Cassandra

 CassandraErrorReceived

an error response is received from Cassandra

 CassandraEmptyResultSetReceived

an empty result set is received from Cassandra

 FeatureInitiated

the feature is initiated and PerformLocationBasedDialling is set to true

 InternationalNumberIgnored

the extracted address string starts with a +, but it is not followed by the configured country code

 StrippedHomeCountryCode

the + and country code are stripped from the extracted address string

 ResponseLatency

time from sending the Cassandra request to receiving the Cassandra result, sampled on receipt of the result

Data Provisioning

Rhino Profiles

This feature requires a VerticalServiceCode profile for each dialled number that will have the location based dialling feature applied.

This feature can optionally use a default profile for a dialled number. The default profile is invoked when no matches are found in the Cassandra table for the dialled number.

These default profiles can be created in REM on the feature configuration menu, Location Based Dialling page, or they can be provisioned via the console in the LocationBasedDialling_AddressListEntryTable profile table.

Note If creating profiles via the console, make sure to increment the Version number on the LocationBasedDialling:DefaultActions profile in LocationBasedDialling_AddressListConfigurationTable in order for the new profiles to be recognized in rhino.

Cassandra Database Entries

Database entries for each dialled number can be provisioned with the lbd-provision tool.

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

Behaviour

Get the address string to use in address analysis

The feature first checks whether the PerformLocationBasedDialling session state field has been set to true by the Vertical Service Code feature. If not, the feature returns without making any changes.

Next, the feature extracts from the Request URI 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 followed by the configured country code, the + sign and the country code are removed.

Get the location

The feature extract the 3GPP Cell ID from the SIP INVITE. First, it tries to parse all P-Access-Network-Info headers until it can extract a 3GPP Cell ID as follows:

  • If the access network is 3GPP-GERAN, use the cgi-3gpp value.

  • If the access network is 3GPP-UTRAN-FDD or 3GPP-UTRAN-TDD and network-provided is set, use the utran-sai-3gpp value.

  • If the access network is 3GPP-UTRAN-FDD or 3GPP-UTRAN-TDD and network-provided is not set, use the utran-cell-id-3gpp value.

  • If the access network is 3GPP-UTRAN or 3GPP-HSPA, use the utran-sai-3gpp value.

  • If the access network is 3GPP2-1X, use the ci-3gpp2 value.

  • If the access network is 3GPP-1X-HRPD, use the ci-3gpp2 value.

  • If the access network is 3GPP-1X-UMB, use the ci-3gpp2 value.

  • If the access network is 3GPP-1X-FEMTO, use the ci-3gpp2-femto value.

  • If the access network is 3GPP-E-UTRAN-FDD or 3GPP-E-UTRAN-TDD, use the utran-cell-id-3gpp value.

  • If the access network is 3GPP-E-UTRAN, use the utran-cell-id-3gpp value.

  • If the access network is 3GPP-E-UTRAN-ProSe-UNR, use the utran-cell-id-3gpp value.

  • If the access network is 3GPP-NR-FDD or 3GPP-NR-TDD, use the utran-cell-id-3gpp value.

If no 3GPP Cell ID can be determined from the P-Access-Network-Info headers (for example when the user is on WLAN), the feature next parses the Cellular-Network-Info headers in the same way.

If still no location can be determined, the default action is performed.

Find the destination address and update the outgoing INVITE

The feature performs a Cassandra lookup using the number extracted from the Request URI and the location extracted from the P-Access-Network-Info or Cellular-Network-Info headers. If Cassandra returns a destination address, the Request URI and (in the case of a MobileOriginating or MobileForwarded call) the To header field are updated to the new destination, and the feature finishes execution. If a + sign and the country code were previously stripped from the dialled number, they are now re-added.

If no destination address can be found, the default action is performed.

Default action if destination cannot be determined

If, for any reason, the destination cannot be determined, a default action is performed according to the configuration detailed above. The call is either rejected with a 403 error code, or is forwarded to a configured default destination. In either case, a configured announcement can be played to the calling party. This announcement is scheduled and is played by the SipPlayAnnouncement feature. If no address list entry can be found, the feature issues a warning and does not perform any other actions, and call processing continues as normal.

Previous page Next page
Sentinel VoLTE Version 4.1