This feature 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. This is achieved by setting the session plan to mmtel-term-psap-callback. This session plan contains no MMTel features which could result in the call not reaching the intended subscriber (for example Incoming Call Barring).

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

Terminating

SipAccess_SessionCheck

No

Yes

Stateless

POJO

Prerequisite Features

Cassandra storage

The feature can be configured to access a Cassandra database, to determine whether terminating calls to the served subscriber should be treated as possible PSAP callbacks.

Data Schema

If the SIP MESSAGE mechanism is used to record PSAP calls and identify possible PSAP callbacks then the following Cassandra configuration is required.

The Cassandra table for PSAP callbacks exists in a keyspace named opencloud_psap_callback

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

CREATE KEYSPACE  IF NOT EXISTS opencloud_psap_callback 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_psap_callback 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_psap_callback ;

CREATE TABLE IF NOT EXISTS opencloud_psap_callback.psapcalls(
    subscriber_id text,
    primary key(subscriber_id)
)
WITH gc_grace_seconds = 172800; // 2 days

Configuration

Configuration for this feature is stored in the MMTelPSAPCallbackConfigProfileTable profile table, containing only one profile, which has the following fields:

Parameter Type Description

UsePriorityHeader

boolean

Flag to use the contents of the Priority header in the initial INVITE to determine whether the call is a PSAP callback.

UseSIPMessages

boolean

Flag to use the SIP MESSAGEs mechanism to determine whether the call is a PSAP callback

ExpiryTime

int

When using the SIP MESSAGEs mechanism the time in seconds after a SIP MESSAGE notifying a PSAP call is received during which any call to the subscriber is assumed to be a PSAP callback.

TerminateMessage

boolean

When using the SIP MESSAGEs mechanism the flag to determine whether we reply to received SIP MESSAGEs notifying a PSAP call, or allow them to propagate further through the network.

Session Input Variables

Session State variable name Type Comments

SentinelSelectionKey

SentinelSelectionKey

Determines which configuration to use, also used when setting the Plan Id.

CallType

CallType

Use to determine whether the call is Mobile Terminating.

Subscriber

String

Subscriber value is used as the primary key in the Cassandra database.

DeterminePSAPCallbackCassandraSessionACI

ActivityContextInterface

Used for detaching from the ACI when the feature has finished.

DeterminePSAPCallbackCassandraSessionRequestSendTime

Long

Used to determine and log latency of Cassandra queries.

Session Output Variables

Session State variable name Type Comments

SentinelSelectionKey

SentinelSelectionKey

Used when setting the Plan Id.

DeterminePSAPCallbackCassandraSessionACI

ActivityContextInterface

Stored off so that the feature can detach from the ACI when finished.

DeterminePSAPCallbackCassandraSessionRequestSendTime

Long

Used to determine and log latency of Cassandra queries.

Statistics

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

Statistic Incremented when…​

Started

The feature runs

FailedToStart

Sentinel VoLTE encounters an error while attempting to start the feature

FailedDuringExecution

A fatal problem is encountered and the feature cannot execute correctly

Misconfigured

The feature doesn’t have any config.

DeterminedPSAPCallback

The feature has determined that a call is possibly a PSAP callback.

DeterminedPSAPCallbackFromPriorityHeader

The feature has used the Priority header method to determine that a call is a PSAP callback.

DeterminedPSAPCallbackFromCassandra

The feature has queried the Cassandra database and determined that the call is possibly a PSAP callback.

UpdatedPlanId

The Plan Id has been updated as a result of the call being identified as a possible PSAP callback.

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

CassandraResponseLatency

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

Behaviour

The feature’s behaviour depends on the trigger. There are 3 supported triggers, a SipRequest, CassandraQueryResultEvent, and CassandraErrorEvent.

Invoked by a SipRequest

If invoked by a SipRequest trigger, the first things the feature does is perform some checks, to ensure that call is Mobile Terminating, and that the SipRequest is an initial INVITE. It then proceeds to determine whether the call is a PSAP callback.

If configured via the UsePriorityHeader value in the profile, the feature first checks for the presence of the Priority header in the INVITE. If that header has a value of psap-callback, then the call is determined to be a PSAP callback. The feature then updates the PlanId to have a value of mmtel-term-psap-callback, before finishing.

If a positive result is not found using the Priority header, and if configured using the UseSIPMessages value in the profile, the feature then checks for an entry in the Cassandra database, using the contents of the Subscriber session state variable as a primary key. The feature then waits for a response.

Invoked by a CassandraQueryResultEvent

This is the event the feature was waiting for after it sent a Cassandra query when invoked with a SipRequest. If the result returns a row, then a PSAP call was made by the subscriber within a configured number of seconds, and the call is assumed to be a PSAP callback. This isn’t expected to be true on every occasion. This timing window is configured using the ExpiryTime value in the profile, and is used as the TTL for the row created in the Cassandra database when a PSAP call is made by the subscriber.

If determined to be a possible PSAP callback, the feature updates the PlanId to have a value of mmtel-term-psap-callback, before finishing.

This method uses SIP MESSAGES to notify that a PSAP call has been made by the subscriber, and is explained in MMTelRecordPSAPCall feature doc.

Invoked by a CassandraErrorEvent

This means that the Cassandra query sent by the feature when it was invoked by a SipRequest went wrong. The error is logged, both to rhino logs and to SAS, before the feature finishes.

Previous page Next page
Sentinel VoLTE Version 4.1