This feature updates the Request URI of a SIP INVITE, based on the location of the calling party and the dialled number . The destinations are stored in a Cassandra table by a provisioning tool.
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 |
|
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 |
---|---|---|
|
String |
The digit string that this configuration is for (e.g.: |
|
boolean |
Fail the call if no destination number can be determined for any reason. |
|
boolean |
Play an announcement if no destination number can be determined for any reason. |
|
Integer |
The ID of the announcement to play if no destination number can be determined, if 'Play Announcement' is enabled. |
|
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 |
RetrievedCellIdFromCellularNetworkInfo |
a usable location is extracted from |
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 |
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.
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.
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 thecgi-3gpp
value. -
If the access network is
3GPP-UTRAN-FDD
or3GPP-UTRAN-TDD
andnetwork-provided
is set, use theutran-sai-3gpp
value. -
If the access network is
3GPP-UTRAN-FDD
or3GPP-UTRAN-TDD
andnetwork-provided
is not set, use theutran-cell-id-3gpp
value. -
If the access network is
3GPP-UTRAN
or3GPP-HSPA
, use theutran-sai-3gpp
value. -
If the access network is
3GPP2-1X
, use theci-3gpp2
value. -
If the access network is
3GPP-1X-HRPD
, use theci-3gpp2
value. -
If the access network is
3GPP-1X-UMB
, use theci-3gpp2
value. -
If the access network is
3GPP-1X-FEMTO
, use theci-3gpp2-femto
value. -
If the access network is
3GPP-E-UTRAN-FDD
or3GPP-E-UTRAN-TDD
, use theutran-cell-id-3gpp
value. -
If the access network is
3GPP-E-UTRAN
, use theutran-cell-id-3gpp
value. -
If the access network is
3GPP-E-UTRAN-ProSe-UNR
, use theutran-cell-id-3gpp
value. -
If the access network is
3GPP-NR-FDD
or3GPP-NR-TDD
, use theutran-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.