VRS Revamp Phase 2
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
- Once a call is in progress, Jtapi event details are saved in the database
- Sip event details are saved in the database.
- Free-switch mixes the streams(legs) and saves the call sessions in the file system.
- Free-switch creates rows in the session table for each session with the file name, near-end refci, far-end refci,
- 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
- 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
- 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
- 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. - 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 |
|---|---|---|
| 1 | one 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 |
|---|---|---|
| 1 | multiple 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. |
|