Summarising EDRs

Introduction

The N2ACD NiFi dataflow processing is used to summarise ACD EDRs for reporting. The N-Squared N2SVCD engine and associated processes generate EDRs for events, but does not summarise EDRs into CDRs for each call automatically. Instead, the reporting dataflow logic performs this task.

The N2ACD CDR generation from N2SVCD EDRs is done by the N2ACD Service EDR Processing process group running in the associated NiFi installation. Each CDR is stored as a database row in the database table n2acd.summarised_edr and associated tables in the n2reporting database.

More details on the data model itself can be found in the Reporting Data Model documentation.

Processing Logic

The full implementation of the dataflow processing that performs the work required to summarise multiple N2ACD EDRs into single records representing CDRs for each freephone voice call can be found in the NiFi process group implementations installed alongside N2ACD.

The following documentation provides additional details for this implementation.

EDR Selection

Not all EDRs received by the NiFi dataflow implementation will be relevant for N2ACD voice calls. N2ACD service nodes may also perform call control for number portability, call screening, or other N2SNS-like services.

While EDRs with the type ACD can be immediately identified as only relevant to N2ACD, determining whether a general protocol-level EDR is for a N2ACD voice call must be done by correlating the call instance from the INAP INITIALDP or SIP IN-INVITE-ALEG EDR with each subsequent EDR generated by the same session.

The NiFi dataflow implementation uses the reporting database as a transient storage layer to maintain a list of call instances that are considered N2ACD calls. In the unlikely event that an EDR is received out of order and the session ID has not been seen, the EDR is re-queued to be retried later.

EDR Correlation

EDRs are correlated as a single call using the primary call instance. In a N2SVCD EDR a full session ID consists of one or more call instances. E.g. the EDR:

2022-10-21 01:07:42.108<n2-t-acd-scp-01.nsquared.co.nz~SIGTRAN~1665715713~286ebe30,n2-t-acd-scp-01.nsquared.co.nz~SCP~1665715713~6013d468>INITIALDP|CALLED=0800100200|CALLING=063581140|CLD=0800100200:2:0:1|CLG=63581140:3:0:1:0:3|CPC=0a|ET=3|INAP=cs1|LTID=286ebe30|RDI=0:0:0:0:0|RPC=5005|RSSN=106|RTID=47e4adcf|SK=9001|TRIGGER=ORIG

has the session ID:

n2-t-acd-scp-01.nsquared.co.nz~SIGTRAN~1665715713~286ebe30,n2-t-acd-scp-01.nsquared.co.nz~SCP~1665715713~6013d468

which is made up of two call instances:

1. n2-t-acd-scp-01.nsquared.co.nz~SIGTRAN~1665715713~286ebe30
2. n2-t-acd-scp-01.nsquared.co.nz~SCP~1665715713~6013d468

The first call instance is the primary call instance and is generated by the first process that interacts with the network traffic for the call from an external source (whether SIP or INAP).

When correlating EDRs for a single call, the primary call instance (the first) is used for correlation.

Called and Calling Party Numbers

For each CDR, the called party (the freephone number) and the calling party are determined from the initial message triggering the N2ACD call control session. For INAP this will be the INITIALDP received, and in SIP the initial INVITE received.

In both cases, N2SVCD generates a related EDR type (either INITIALDP or IN-INVITE-ALEG). These EDRs determine the called and calling party, and are also used to determine whether the session is a N2ACD session or not.

The called and calling fields of the summarised_edr table are populated.

INAP-based Calls

From INAP call EDRs the CALLED and CALLING EDR field are used. These fields provide phone numbers without additional details (such as the NOA or TON).

SIP-based Calls

From SIP based call EDRs the FROM_URI and TO_URI are extracted and used for the called and calling party numbers. As both URI fields are encoded as URIs, the NiFi dataflow decodes these URIs and extracts the phone numbers, storing only the phone numbers in the summarised_edr table.

Call Completion State

The call completion state provides a single descriptive term to describe the overall result of the call. The terms used by the processing logic are:

Call completion state is stored in the completion_state field.

Call Connection Requests

Freephone calls will generally connect a caller to a new called party number. In some cases multiple phone numbers might be attempted due to target parties being busy or unavailable.

Some freephone calls will not include any connection attempt, with either the call being released or with only IVR interaction occurring.

The summarised_edr.b_party_list column stores a list of the numbers that N2ACD has attempted to connect the caller to. This list may be null if no connection attempts were made (or no EDRs have been processed with connection attempts recorded).

The companion list summarised_edr.b_party_decline_code_list is a list of the results of each connection attempt. If the final connection attempt succeeded, then a result code will not be added to the list.

The decline code values will depend on the protocol.

• For SIP based calls, the decline code will be a number (as a string) representing the HTTP result code sent to the network. For example, 487 indicates no answer by the B party.

• For INAP based calls, the decline code will be a string describing the EDP that ended the call attempt. For example, oCalledPartyBusy_leg2 indicates the called party was busy.

N2ACD Call Logic

The cust_id, flow_id and flow_version fields of the summarised_edr table relate the CDR data to N2ACD service configuration. All summarised EDRs should be matched to N2ACD service data, although it is possible for a summarised EDR to not have matched to a customer or flow - e.g. in the case where the service number did not match one configured in the N2ACD database.

EDRs with the type ACD are generated by the N2ACD call control logic layer of the N2SVCD engine. These EDRs are used to populate these fields.

In addition to linking back to N2ACD service data, the ACD EDRs provide a node list of the nodes executed during the call. The node list is stored in the executed_node_list column:

select executed_node_list from n2acd.summarised_edr WHERE first_instance_guid
= 'n2-t-acd-scp-01.nsquared.co.nz~SIGTRAN~1666739854~25008ea6';

will return a JSON array of objects determining the node ID, node type and exit taken when executed, e.g.:

[
  {
    "id": "3",
    "exit": "3",
    "type": "MENU"
  },
  {
    "id": "2",
    "type": "END"
  }
]

Note that the node exit is a one-based index (so exit 1 is the first exit of the node). This process is equivalent for both SIP and INAP based ACD calls.

Summarising Announcement Usage

Each announcement that is requested to be played by N2ACD to a caller will generate an EDR of type PLAY. From the PLAY EDRs, the dataflow extracts the requested Message ID and stores the play list in a JSON array in the summarised_edr.announcements_played table column.

select announcements_played from n2acd.summarised_edr WHERE first_instance_guid
= 'n2-t-acd-scp-01.nsquared.co.nz~SIGTRAN~1666739854~25008ea6';

will return a JSON array, e.g.:

[1003,500]

indicates two announcements were requested by N2ACD for the call.

This process is equivalent for both SIP and INAP based ACD calls.

The dataflow processing ignores PLAYED EDRs and does not track whether an announcement was played, or the results of any user interaction with the SRF.

Tracking First and Last EDR Timeframes

All processed EDRs have an event timestamp. Processed EDRs are used to update the first_event_timestamp and last_event_timestamp fields of the summarised_edr table.

Note that because of idiosyncrasy EDR generation and call processing, some unprocessed EDRs for a call may occur before or after the captured first/last timestamp. However, timestamps given by these fields should be within a few milliseconds of all EDRs associated with the call.