Sentinel VoLTE includes a capability to store information related to ongoing SIP Sessions in a Cassandra Database.
This enables global access from various Sentinel VoLTE cluster nodes to the same information. Session Tracking is accessible to features through an API. It is primarily used by the SCC-AS supporting implementation of various Access Transfer mechanisms.
Sessions are said to be Tracked Sessions if their existence and meta-data is stored in the Cassandra Database. Not all sessions are tracked. The SCC-AS tracks any originating or terminating session where the served user’s identity is registered by a UE that has a UE-SRVCC-Capability indicator.
In order to enable the Re-INVITE Based Three-party conference setup
the SCC-AS will track every originating or terminating session if the EnableSCCConfHandling attribute is set to true.
For further information refer to SCC Conference Handling Configuration
and Reuse of Access Transfer procedures for conferencing.
Tracked Session Information
A Tracked Session is a session where Session Tracking is enabled. A session can have its tracking enabled at various "points".
These are:
-
Half dialog - A SIP INVITE request has been sent, and no dialog-creating 1xx response has been received yet. This corresponds to the "Trying" and "Proceeding" states in RFC 4235.
-
Early - a SIP dialog is in the "early" state. This means that the INVITE request has received a dialog-creating 1xx response. Forks of this dialog may exist due to SIP forking.
-
Confirmed - a SIP dialog exists that has both local and remote tags, its INVITE request has been responded to with a 2xx, and the ACK for the 2xx has arrived at the TAS.
In the case of the SCC-AS, session tracking is enabled for "Confirmed" if the UE is SR-VCC capable. Session tracking is enabled for "Early" and "Confirmed" if there is a terminating attempt and the UE indicates support for alerting access transfer. Session tracking is enabled for "Half dialog", "Early", and "Confirmed" if the SCC-AS is triggered for an originating session, and the UE indicates support for PS to CS SRVCC for originating calls in the pre-alerting state.
A tracked session writes information related to the SIP dialog(s) for the served user. In the case of an originating B2BUA, this is the dialog(s) towards the originating user. In the case of a terminating B2BUA this is the dialog(s) towards the terminating user.
| State of Tracked Session | Input to session tracking | Session tracking behaviour |
|---|---|---|
Does not exist |
Initial INVITE request received and a feature enables half dialog session tracking |
Session tracking creates appropriate rows in the Database. Each row is in the half dialog state. |
Half dialog |
A dialog creating 1xx response is received |
Each half dialog row is removed from the database. A 'PRE_ALERTING' row is created if the Early Dialog was established with a 183. An 'ALERTING' row is created if the Early Dialog was established with a 180. |
Early |
A dialog creating 1xx response with a different remote-tag (a fork) is received |
New rows representing the Early dialog for the fork are created in the database. |
Early |
An ACK to the 2xx-INVITE is received at the TAS |
Any rows representing forked dialogs that did not receive the final response to the INVITE are removed from the database. The rows representing the established dialog are updated to be state 'ACTIVE' in the database. |
Confirmed |
A 2xx response to a hold request is received at the TAS |
Any rows representing the confirmed dialog are updated to be state 'HELD' in the database. |
Confirmed |
A 2xx response to a resume request received at the TAS |
Any rows representing the confirmed dialog are updated to be state 'ACTIVE' in the database. |
Confirmed |
A BYE request is sent/received on the Served User’s Dialog |
Any rows representing the confirmed dialog are removed. |
Use of Cassandra Database
The Cassandra database is used by session tracking due to its high availability, and replication capabilities.
Each site runs a TAS cluster, and a Cassandra cluster. The minimum number of nodes per-site for the Cassandra cluster is three, and for the TAS cluster is two. Each site should essentially repeat this structure.
Row Time-to-Live
Each row that is created in Cassandra has a "Time-to-Live" (TTL) set. When a row’s TTL expires, the row is no longer visible in the database and its disk storage is eventually removed. Row TTLs are used to ensure that in various failure cases (such as communication failure between the TAS and Cassandra, TAS failure, or Cassandra failure) that Cassandra does not "fill up" and then "overflow" its storage.
Tracked Sessions in different states have different TTL values set, as the expected frequency of signalling changes in different session phases.
| State of tracked session | Default row TTL | Configuration location |
|---|---|---|
Half dialog |
60s |
Not configurable |
Early |
60s |
Not configurable |
Confirmed |
1.5 × session refresh period |
As per SessionRefresh configuration |
Consistency Level
Session Tracking uses a consistency level of LOCAL_QUORUM for reads and writes.
This means that:
-
reads in a site will return the most recently written data in that site
-
to survive a single database failure, a minimum of three Cassandra database instances must be configured per site
-
database replication occurs synchronously within a site, and asynchronously between sites
-
there will be a replication lag between sites due to inter-site communication latency.
Cassandra Schema
Session Tracking uses two tables to represent a Tracked Session.
Each tracked session has one or more rows present in the Cassandra Database.
These are the trackeddialog table, and the trackeddialogkeys table.
The trackeddialog table has the fully-formed Dialog ID of the SIP dialog as the primary key.
The trackeddialogkeys table uses a Cassandra capability of a two part primary key, essentially to provide "Additional keys" to look up data, as Cassandra does not provide an optimal secondary key mechanism.
The primary key for the trackeddialogkeys table is a composite of the trackingkey (text), and the fully-formed dialog ID.
The schema itself can be viewed in External Session Tracking Cassandra Schema
Minimising the impact of Database issues on Session processing
As the SCC-AS is involved in potentially all originating IMS INVITE sessions, and all terminating IMS sessions, care is taken to reduce the impact of a database failure.
When tracking sessions the TAS uses the following strategies:
-
Write-only statements for session tracking - session tracking only writes to the Cassandra Database. All data necessary to be written is held in local session state. Application features (such as SCC features) then add a read path as necessary. This enables global access to session tracking state.
-
Batch statements - any query that affects multiple rows is executed as a batch statement.
-
Asynchronous queries - threads used for processing signalling messages are not blocked waiting for a response from the database.
-
Signaling visibility after database transaction - signalling is only written "on the wire" after the database transaction has completed, or a guard timer has fired.
-
Per-query guard timeout - the TAS arms an internal timer for each Cassandra query, and if it fires before there is a response from Cassandra, signalling continues and the session is marked as "not tracked" so that further tracking of that session is disabled.
The effect of the guard timeout firing is that the user’s session setup can be successful, albeit with a small delay (the guard timer value). However if PS to CS SR-VCC is attempted, the access transfer may fail as when reading from the Cassandra Database the SCC-AS is likely to obtain either:
-
no tracked session information - as rows may not have been created, or may have been removed due to TTL, or
-
out-of-date information - as there may have been successful queries prior to a query hitting its guard timer
Session Tracking Features
Session Tracking is implemented by the External Session Tracking Features in the Sentinel VoLTE Administration Guide.
|
Setting the tombstone deletion strategy to a shorter interval than the default is strongly recommended for third-party registration tables. The default interval causes increased load on the Cassandra servers during compaction, and particularly during recovery after failover. 1 hour is sufficient for proper management of registration and session data. Set the gc_grace_seconds configuration parameter to 3600 to delete tombstone records after 1 hour. Other compaction configuration parameters may assist in the timely deletion of tombstone records but are usually not required. |
To set the gc_grace_seconds parameter for REGISTRATIONDATA run the CQL command
ALTER TABLE REGISTRATIONDATA WITH gc_grace_seconds = 3600;
