Document toolboxDocument toolbox

.VRS Revamp Phase 2 v13.0

Owned by Former user (Deleted)
Apr 27, 2023
4 min read

Received Events and Correlation (Draft):

JTAPI Events

  • Agent Extension - the near-end address
  • Participants- Active participants of the given Call, with their extensions (in case of normal, the other participant will be the customer)
  • Call States - The current state of the observed call (START, END, HOLD, TRANSFER, CONSULT, CONFERENCE) 
  • Event Times- Each event time stamp.
  • Connection ID - A unique event identifier that can be correlated with a SIP event identifier  (this is the same as SIP Refci)
  • Agent ID - The current  Logged in Agent Identification

SIP Events

  • Refci ID - A unique event identifier that can be correlated with a JTAPI (Connection ID) event.
  • Event Times- Each event time stamp.
  • Agent Extension - the near-end address
  • The fard-end address (customer or another agent)

Correlation Steps

  1. Once a call is in progress, Jtapi event details are saved in the database
  2. Sip event details are saved in the database.
  3. Free-switch mixes the streams(legs) and saves the call sessions in the file system.
  4. Free-switch creates rows in the session table for each session with the file name, near-end refci, far-end refci, 
  5. Based on Time, agent extensions, and ID's (refcis  from sip events and Connection IDs  from jtapi events) the session audio names are saved in the database
  6. Jtapi events are compared against the details on the SIP events Table using the following attributes:
    • agent id
    • timestamp
    • call event state
    • refci id
    • connection id
    • agent extension
    • participants extension
  7. Based on the given attributes from the sip and jtapi table, the sessions are correlated and the audios grouped into a single call on the calls table


  1. A call started → sip event with refci = 1,               jtapi event is received with connection id= 1 (call started the event with call id)
    The call is resumed → sip event with refci = 1,    jtapi event with connection id = 1, call resumed event for call id
    The call is transferred - sip evnet with refci = 3,  jtapi event with connection id = 3, call transfered event
    The is consulted → sip refci = 4,                                jtapi connection id = 4 , call consulted event
                                                                                                  Call end Jtapi event.
  2. Co-relator will pick all connection ids between the start jtapi and the end jtapi event, and fetch the sessions with the same refciIds in the session table.


Simple call

jtapi session id

session table entries

Co-relation mechanism upon jtapi call end event
1one session with near-end refci =1 and far-end refci = 2 jtapi observer will create a row in the call table and then look for sessions in the session table where jtapi session id = near-end refci or far-end refci, this will fetch one session (jtapi session id will match near-end refci). The found session table row call_id column will be updated with the created call row primary key. We will have 1 call and one associated session


Hold resume call

jtapi session id

session table entries

Co-relation mechanism upon jtapi call end event
1multiple sessions with near-end refci =1 and far-end refci = 2 jtapi observer will create a row in the call table and then look for sessions in the session table where jtapi session id = near-end refci or far-end refci, this will fetch multiple session s(jtapi session id will match near-end refci of many session). The found session table rows call_id column will be updated with the created call row primary key. We will have 1 call and many associated sessions


Transfer call

jtapi session id

session table entries

Co-relation mechanism upon jtapi call end event

Since a transfer call is a new call for jtapi, we will get two end events, one for the leg before the transfer and one once the transferred leg is ended.

session id = 1 and 3


two sessions

first: near-end refci =1 and far-end refci = 2

second: near-end refci =3 and far-end refci = 2

The near-end refci gets changed since the call is transferred to another agent while the far-end refci remains same as the far-end is still on the same call.

  1. The observer will fetch far-end refci and near-end refci from the session table where jtapi session_id=near-end refci
    1. for the first leg it will find n-refci=1 and f-refci=2 
    2. for the second leg with jtapi session id = 3, it will find near-end refci = 3 and far-end refci = 2
  2. It will now run query → find sessions where n-refci IN found values in a or b OR f-refci IN found values in a or b
    1. for the first leg, we will get n-refci = 1 and f-refci =2 (jtapi session id 1 = near-end refci 1)
      1. The query will become, find sessions where n-refci IN (1,2) or f-refci IN (1,2). This will return single session row
    2. for send leg, we will get n-refci = 3 and f-refci = 2
      1. The query = find sessions where n-refci in (3,2) or f-refci IN (3,2). This will return two sessions.