Overview
External session tracking saves all of the relevant information to track a session across multiple nodes. It saves the information in a Cassandra database. For an architectural view please refer to Session Tracking.
For further information related to use of Cassandra for production purposes please refer to Cassandra Database Configuration.
Data Schema
Cassandra’s tables exist in a 'keyspace', which, for illustrative purposes, can be thought of as a 'database' in SQL implementations. Creating a keyspace is simple, but some considerations are present.
-
The keyspace must be named
opencloud_external_session_tracking -
For a production environment, and for non-functional testing prior to production, the keyspace can be created such that it is replicated. A sample CQL command for creating such a keyspace is:
CREATE KEYSPACE opencloud_external_session_tracking WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 3 };-
When developing features using the SDK against Cassandra, replication may not be necessary. A sample CQL command for creating such a keyspace is:
CREATE KEYSPACE opencloud_external_session_tracking WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 1 };Once a keyspace is created, the required tables can be created. The following CQL statements provide both the structure and insight into the tables that are required.
USE opencloud_external_session_tracking;
//This table contains tracked dialogs
//tracked dialogs may be found by establisheddialogid
//there is one row for each tracked dialog
CREATE TABLE trackeddialog(
establisheddialogid text, //The established dialog ID, in form of Target-Dialog header value
//e.g. fa77as7dad8-sd98ajzz@host.example.com;local-tag=kkaz-;remote-tag=6544
state text, //The state of the call. One of:
//"PARTIAL_DIALOG", "PRE_ALERTING", "ALERTING", "ACTIVE", or "HELD"
asuri text, //The SIP URI of the tracking AS.
//e.g In SCC, the SCC-AS URI of the signalling anchor for this dialog
lastactivetime timestamp, //The last time the call moved into state "active"
lastheldtime timestamp, //The last time the call moved into state "held"
committedsdp text, //The committed SDP for this dialog
committedsdptimestamp timestamp, //The time that the SDP was committed
associateddialogid text, //The associated dialog ID, e.g. in a routing B2BUA this should be set to the
//the other dialog ID
mediafeaturetags set<text>, //The UE's media feature tags received in the initial INVITE (originating)
//or in the dialog-creating response (terminating)
primary key(establisheddialogid)
);
//This table provides a mapping from a trackingkey to the established dialog IDs for that tracking key
//I.e. one tracking key may track multiple dialogs
CREATE TABLE trackeddialogkeys(
trackingkey text, //A tracking key for the tracked dialog
// example 1: cmsisdn=16505550425
// example 2: impu=sip:+16505550386@example.com;user=phone
// example 3: +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
// example 4: impi=john.doe@example.com
establisheddialogid text, //The established dialog ID, in form of Target-Dialog header value
//e.g. fa77as7dad8-sd98ajzz@host.example.com;local-tag=kkaz-;remote-tag=6544
state text, //The state of the call. One of:
//"PARTIAL_DIALOG", "PRE_ALERTING", "ALERTING", "ACTIVE", or "HELD"
asuri text, //The SIP URI of the tracking AS
//e.g. in SCC, the SCC-AS URI of the signalling anchor for this dialog
lastactivetime timestamp, //The last time the call moved into state "active"
lastheldtime timestamp, //The last time the call moved into state "held"
committedsdp text, //The committed SDP for this dialog
committedsdptimestamp timestamp, //The time that the SDP was committed
associateddialogid text, //The associated dialog ID, e.g. in a routing B2BUA this should be set to the
//the other dialog ID
mediafeaturetags set<text>, //The UE's media feature tags received in the initial INVITE (originating)
//or in the dialog-creating response (terminating)
primary key(trackingkey,establisheddialogid)
);|NOTE 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.
