How ICON Works

This page describes basic Interaction Concentrator functioning—how the Interaction Concentrator server (ICON) collects, processes, and stores configuration and interaction data in Interaction Database (IDB). It contains the following sections:

• ICON Processing
• Populating Configuration Data
• Populating Interaction Data
• Identifying Who Released the Call
• Determining Data Availability and Reliability
• Tracking Multi-Site Call Data Via ISCC

ICON Processing

ICON is a client of the data sources that are specified on the Connections tab of the ICON Application—T-Server, Interaction Server, Configuration Server, or Outbound Contact Server (OCS). ICON monitors events from these data sources, and it processes events for the types of data that the ICON instance has been configured to collect, as specified by the ICON role option.

Processing occurs in the in-memory queue (accumulator), as ICON prepares the data for storage in IDB. For all types of data except configuration data, ICON then writes the prepared data to the persistent queue, and from the persistent queue into IDB.

For information about how ICON completes the processing of configuration data, see “Populating Configuration Data” on page 38.

You can configure the size of the in-memory queue or the interval at which data is written from it to the persistent queue. You can also configure the maximum number of keep-in-memory interactions that concurrently reside in an interaction queue or interaction workbin. Memory optimization configuration options on the ICON Application enable this functionality, which requires Interaction Server release 7.6.1 or higher.

For more information about the persistent queue, see “Persistent Queue and Persistent Caches” on page 17. See also the equivalent section in the overview chapter in the Interaction Concentrator 8.1 Deployment Guide, which provides additional information.

For more information about the ICON configuration options, see the Interaction Concentrator Deployment Guide.

Important

ICON monitors the activity of its data sources and other configuration objects in accordance with the role and option settings that are configured for the ICON instance. This means that options or features that are configured on other Genesys components might not be reflected in IDB data. For example, if an endpoint has been disabled in the Configuration Layer by an Administrator, configuration data in IDB will correctly show the disabled state (the STATE field in the GC_ENDPOINT table), but any activity on that DN will continue to generate data in the interaction-related tables (for example, G_PARTY).

Populating Configuration Data

If configured to do so, ICON gathers information about contact center configuration objects from Configuration Server on initial startup, and keeps track of changes made to these objects throughout its operation by monitoring dynamic real-time notifications from Configuration Server.

ICON collects and stores configuration-related data if the value of the role configuration option is set to cfg or all.

Annex Tab Data

Starting in release 8.1.4, Interaction Concentrator can be configured to collect and store data about changes on the Annex tab of the following objects:

• Persons
• Agent Groups
• DNs
• DN Groups
• Switches

This information enables Genesys Interactive Insights to control visibility of certain data and reports based on attributes such as geographical location, business line, or organization structure. This functionality is available only when ICON has the cfg role and the cfg-annex option configured.

To have Interaction Concentrator track Annex tab data, set the value of the cfg-annex option to 1 (the default value is 0).

Interaction Concentrator stores data for the following occurrences:

• Option created
• Option deleted
• Option renamed
• Option value changed
• Section renamed
• Section deleted
• Configuration object deleted

When an Annex tab configuration option is deleted and then created again, the CREATED and LASTCHANGE fields in the GC_ANNEX table are set to the current timestamp.

For efficient processing, Interaction Concentrator collects and stores section and option change data only for certain sections on the Annex tab. See Table 3 for the sections that are tracked.

Monitored Annex Tab Sections

Configuration Object	Monitored Sections
Person	Any section starting with RPT
Agent Group	Any section starting with RPT
DN	gim-etl Any section starting with RPT Any section starting with agg-
DN Group	Any section starting with RPT
Switch	gim-etl Any section starting with agg-

Occasions When ICON Collects Configuration Data

An ICON performing the cfg role collects configuration-related data:

• On startup—This is the first deployment of ICON, when the IDB is empty. For more information, see “Reading the Configuration Database on Startup” on page 40.
• When the persistent cache is unavailable. For more information, see “Persistent Cache Is Not Available” on page 41.
• Through real-time object change notifications. For more information, see “ICON Receives Dynamic Notifications” on page 41.
• Upon receipt of the Configuration Server’s history log file. For more information, see “ICON Reads the Configuration History Log” on page 41.
• Upon user request for resynchronization. For more information, see “User Request For Resynchronization” on page 42.

ICON stores configuration-related data in the following tables in IDB:

• Tables prefixed with GC_—Information about the addition of new objects and the deletion or update of existing objects
• Tables prefixed with GCX_—Information about object relationships

Important

ICON stores information in the GC_APPLICATION table about the following application types only—Outbound Contact Server, CPD Server, T-Server, and Agent Desktop.

For more information about the configuration tables, see the Interaction Concentrator 8.1 Physical Data Model for your RDBMS.

Persistent Cache for Configuration Data

The persistent cache enables ICON to synchronize configuration data in IDB with current Configuration Server information. The ICON instance that performs the cfg role maintains a persistent cache for configuration data. The name of this local file is cfg-sync.db, and it cannot be renamed. Data in the persistent cache survives a shutdown and restart of ICON.

When it receives data from Configuration Server, ICON writes the data from its in-memory queue to the persistent cache, and then from the persistent cache into the configuration tables in IDB.

The persistent cache contains a timestamp for configuration data changes. On startup, ICON requests from Configuration Server all configuration changes that occurred after that timestamp. ICON then updates the persistent cache, transfers the configuration data to IDB, and continues to monitor real-time notifications from Configuration Server.

Reading the Configuration Database on Startup

Upon initial startup, or if the local cache file is not available (see “Persistent Cache Is Not Available”), ICON queries Configuration Server for all active configuration objects and active relationships. ICON loads the persistent cache with the information it gathers about these objects and relationships. It then submits the updated transactions to its persistent queue, from which it updates the configuration-related tables in IDB.

Persistent Cache Is Not Available

If the persistent cache is not available during a routine startup (that is to say, not the initial startup when the IDB is empty), ICON performs a resynchronization of IDB automatically. When it restarts, ICON verifies the content of the IDB using the last processed real-time notification from Configuration Server. If there is no information about the last notification because the persistent cache is not available, ICON requests all configuration-related information from Configuration Server and recovers the persistent cache.

ICON Receives Dynamic Notifications

ICON is a client of Configuration Server. Whenever both applications are operating and changes are made to configuration objects or their relationships to other objects within Configuration Manager, Configuration Server immediately notifies its clients of the change. (Genesys does not support such notification if objects are changed directly within the Configuration Database.) The persistent cache is designed to always be synchronized with Configuration Database. When ICON receives the notification, it immediately sends the information to the persistent cache, and records it in the appropriate IDB table using the actual timestamps when the object was changed in Configuration Server.

ICON Reads the Configuration History Log

Configuration Server maintains a history log for the purpose of enabling clients to restore a session that was terminated by a service interruption and to request any changes to configuration objects that occurred during that the interruption. Dynamic changes made to configuration objects are reported directly by Configuration Server. ICON requests this information from Configuration Server every time it connects to it.

With earlier releases of Configuration Server (prior to 7.6), you must ensure that the Configuration Server’s history-log-active option is set to true. If set to false, configuration changes are not recorded in the history log file. Therefore, if ICON lose connection to Configuration Server during this time, it cannot later retrieve information about configuration changes during the time of the disconnect. Setting this option to false, however, does not prevent resynchronization.

In Configuration Server release 7.6 or later, you can set the following Configuration Server [history-log] configuration options to control the history log functionality:

• all
• expiration
• client-expiration
• max-records
• ctive
• failsafe-store-processing

Important

If failsafe-store-processing is set to false, the history log database may not be wholly preserved.

Refer to the configuration history log section in the Framework Deployment Guide and the history log section in the Framework Configuration Options Reference Manual for more information about these options.

User Request For Resynchronization

On-demand resynchronization occurs when a customer manually runs the resynchronization procedure (see “How to Resynchronize Configuration Data” on page 141 for complete step-by-step instructions). When instructed to start resynchronization, ICON requests all configuration data from Configuration Server and stores it in its persistent cache. At the same time, all other activity—such as dynamic notifications—between ICON and Configuration Server is disabled. ICON then transfers configuration data in the persistent cache to the IDB and begins to monitor real-time notifications from Configuration Server again.

Populating Interaction Data

This section describes aspects of basic ICON functioning to capture information about voice calls.

• For information about how to capture information about multimedia interactions, see Chapter 4 on page 55.
• For information about the way in which ICON handles attached data for voice calls, see “Attached Data Processing for Voice Calls” on page 64.

T-Server TEvents

ICON connects to T-Server and receives notifications, in the form of TEvents, about voice call processing. ICON provides two tracks for operational reporting: call-based and party-based.

Real-time interaction data, such as voice-specific interactions, is stored in the following IDB tables:

G_IR	G_CALL_ACTIVE	G_CALL_USERDATA
G_IR_ACTIVE	G_CALL_HISTORY	G_CALL_USERDATA_CUST
G_IR_HISTORY	G_CALL_STAT	G_CALL_USERDATA_CUST1
G_IS_LINK	G_PARTY	G_CALL_USERDATA_CUST2
G_IS_LINK_HISTORY	G_PARTY_HISTORY	G_USERDATA_HISTORY
G_ROUTE_RESULT	G_PARTY_STAT	G_SECURE_USERDATA_HISTORY
G_CALL

For detailed information about the tables in IDB in which ICON stores interaction data, see the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS.

Extracting Interaction Data

Genesys recommends the following approach to extracting interaction data from IDB:

1. Use records in the G_IR table as the base records for data extraction. Use the value of the IRID field as an identifier to determine which records to extract from the G_IR_HISTORY and G_CALL tables.
2. After data extraction from the G_CALL table, use the value of the CALLID field as an identifier to determine which records to extract from the other interaction-related tables.
3. After data extraction from G_PARTY, use the value of the PARTYID field as an identifier to determine which records to extract from the G_PARTY_HISTORY and G_PARTY_STAT tables.
   

Stuck Records

Stuck records can result when ICON restarts if, during the time that ICON was shut down:

• A change occurred in agent session data (for example, an agent logged in or out).
• Outbound campaign processing completed.
• A call was distributed from a virtual queue.
• A call or party was deleted.

Starting in release 8.1, Interaction Concentrator stores data on active voice interactions in the G_CALL_ACTIVE and G_IR_ACTIVE tables. After restarting, any interactions remaining in either table will be marked as terminated, with the termination timestamp being the time that Interaction Concentrator restarted.

Stuck calls or parties can also result from stuck calls or parties on the T-Server or Interaction Server side. The disconnection of ICON from T-Server or Interaction Server does not in itself result in stuck calls. ICON can retrieve a snapshot of the active calls and compare this to the calls in memory.

Stuck Call Resolution Procedure

When data is incomplete, ICON uses an internal stored procedure to resolve stuck calls and to determine whether to process the available data. This procedure is based on a timeout mechanism. It allows for continued data processing in the event of partial data loss. Within IDB, ICON marks the records it detects to be incomplete as having low reliability. For more information, see the G_IR.GSYS_EXT_VCH2 field description in the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS.

Identifying the DNIS for Outbound Softphone Calls

By default, Interaction Concentrator takes the value of the DNIS (dialed number information service, which is the number that initiates a call) from the AttributeDNIS field in T-Server events and stores it in the CallDNIS field of the G_CALL table. However, because various switches operate differently, the value of the DNIS might be distributed in other attributes and/or in different TEvents. In some cases, the standard AttributeDNIS field may be empty or not present. By appropriately configuring the value of the gts-dnis-detection configuration option in the Application object for the associated switch, you can choose to have ICON take the value of the DNIS from a related subset of TEvents.

Important

Once defined, the value of the DNIS cannot be changed.

Identifying Who Released the Call

Provided that T-Server includes the required attributes in TEvent messaging, ICON stores information in IDB that enables downstream reporting applications to identify the party that released the call. ICON provides two kinds of call-release reporting. The two kinds of call-release reporting are independent from each other. Call-based—In the G_CALL_STAT table, ICON stores information about the device (endpoint), and possibly also the associated party, that initiated termination of the call. For more information, see “Call-Based Reporting”. DN-based—In the G_PARTY_STAT table, ICON stores information that indicates whether termination was initiated locally (on this party’s endpoint) or remotely (on the other party’s endpoint). ICON stores this information only for parties that are associated with endpoints that are monitored by that ICON instance. For more information, see “DN-Based Reporting”. For information about the implications for multi-site deployments, see “Multi-Site Deployments” on page 47. Call-Based Reporting When a call is terminated and ICON receives EventCallDeleted from T-Server, ICON processes the event to obtain the following information: From the AttributeCallUUID attribute, ICON gets the CallID that identifies the call. ICON includes this value in the G_CALL_STAT record. From the AttributeCtrlParty attribute, ICON gets a string that specifies the device (endpoint) that initiated release of the call. ICON stores this string, exactly as T-Server delivered it, in the GSYS_EXT_VCH1 field in the G_CALL_STAT table. If T-Server does not report the AttributeCtrlParty attribute in EventCallDeleted, ICON stores an empty string in the GSYS_EXT_VCH1 field in the G_CALL_STAT table. Based on the value of the AttributeCtrlParty attribute, ICON might be able to identify the party associated with the monitored DN. If it can identify the associated party, ICON stores the PartyID in the GSYS_EXT_VCH2 field in the G_CALL_STAT table. If it cannot identify the associated party, ICON stores an empty string in the GSYS_EXT_VCH2 field in the G_CALL_STAT table. T-Server does not report the AttributeCtrlParty attribute when a consultation call is terminated as the result of a completed two-step transfer or two-step conference. Therefore, in these scenarios, ICON stores an empty string in the GSYS_EXT_VCH1 and GSYS_EXT_VCH2 fields in the G_CALL_STAT table in records that are related to the consultation call.

DN-Based Reporting When a call is terminated and ICON receives EventReleased or EventAbandoned from T-Server, ICON writes a record in the G_PARTY_STAT table. ICON uses the value of the ReleasingParty extension key, in the AttributeExtensions of the event, to populate the GSYS_EXT_INT1 field of the G_PARTY_STAT record with one of the following values: G_PARTY_STAT Values 0—T-Server did not provide ReleasingParty data in EventReleased or EventAbandoned. 1—Local. Call termination was initiated by this party (ThisDN in EventReleased or EventAbandoned), and T-Server sends ReleasingParty = 1 Local in the event. 2—Remote. Call termination was initiated by another party (not ThisDN in EventReleased or EventAbandoned), and T-Server sends ReleasingParty = 2 Remote in the event. 3—Unknown. T-Server was unable to determine the initiator of call termination, and sends ReleasingParty = 3 Unknown in EventReleased or EventAbandoned. If ICON is monitoring the DNs for more than one of the parties involved in a call, there will be multiple G_PARTY_STAT records—one for each party.

The T-Server configuration option releasing-party-report must be enabled on the T-Server Application in order to report this extension. T-Server does not report ReleasingParty information when a consultation call is terminated as the result of a completed two-step transfer or two-step conference. Therefore, in this scenario, ICON stores the value 0 (no data provided by T-Server) in the GSYS_EXT_INT1 field in the G_PARTY_STAT table.

Reporting Summary Table 4 summarizes the values that ICON might report in the G_CALL_STAT table for the party that released various types of calls. For the values that ICON might report in the GSYS_EXT_INT1 field in the G_PARTY_STAT table, see “G_PARTY_STAT Values” on page 45.

Possible Values for Call-Release Reporting, by Call and Releasing Party Type (Continued) Releasing Party* AttributeCtrlParty in EventCallDeleted G_CALL_STAT Table GSYS_EXT_VCH1 GSYS_EXT_VCH2 Call type = Inbound or Outbound External No data Empty string Empty string “External DN” “External DN” <PartyID associated with “External DN” and associated with the call identified by CallID of this call> Internal No data Empty string Empty string “Internal DN” “Internal DN” <PartyID associated with EndpointDN = “Internal DN” and CallID of this call>

Call type = Internal Internal No data Empty string Empty string “Internal DN” “Internal DN” <PartyID associated with EndpointDN = “Internal DN” and CallID of this call>

Call type = Consultation External or Internal No data Empty string Empty string Call type = Conference (one internal party, all other parties external) Internal “Internal DN” “Internal DN” <PartyID associated with EndpointDN = “Internal DN” and CallID of this call>

• Releasing party is in relation to the T-Server or switch monitored by the ICON instance.

Multi-Site Deployments In multi-site configurations, regardless of whether each site is monitored by a separate ICON or by the same ICON instance, the record that reports the initiation of call termination on a site treats endpoints from the other site(s) as external resources (endpoints). In most cases, this external resource is represented and reported by T-Server as an External Routing Point. Example Assume that there are two ICON instances, writing to separate IDBs, for two sites: ICON_1, which writes to IDB_1 and monitors Site 1; and ICON_2, which writes to IDB_2 and monitors Site 2. A call from DN_1 on Site 1 goes to DN_3 on Site 2, and then is released by DN 3. ICON_1 creates two parties: One party is associated with DN_1. The second party is represented as an external party associated with external resource Ext_DN2. Ext_DN2 is usually represented and reported as an External Routing Point. Table 5 summarizes the values that ICON will report for the party that released the call.

Example of Call-Release Reporting in a Multi-Site Deployment IDB G_CALL_STAT Table G_PARTY_STAT Table Data Source GSYS_EXT_VCH1 GSYS_EXT_VCH2 Data Source GSYS_EXT_INT1 IDB_1 AttributeCtrlParty in EventCallDeleted received from the T-Server connected to ICON 1 “Ext_DN2” or “String submitted by T-Server” <PartyID associated with EndpointDN = “Ext_DN2” as represented on this site> ReleasingParty in EventReleased for the party associated with DN_1, received from the T-Server connected to ICON 1 2 IDB_2 AttributeCtrlParty in EventCallDeleted received from the T-Server connected to ICON 2 “DN_3” <PartyID associated with EndpointDN = “DN_3” and CallID of this call> ReleasingParty in EventReleased received from the T-Server connected to ICON 2 1

T-Server Support To implement reporting on which party released the call, ICON relies on T-Server to provide the required data. This feature requires T-Server release 8.0 or higher. Interaction Concentrator 8.0 and higher supports this feature for the Alcatel A4400/OXE switch. Interaction Concentrator 8.0.000.35 and higher also supports this feature for Avaya switches; for Avaya, this functionality requires T-Server for Avaya Communication Manager release 8.0.101.05 or higher. For information about configuring T-Server to support this functionality and for information about the scenarios in which T-Server reports the required attributes, see the section about call release tracking in the Framework 8.1 T-Server Deployment Guide for the applicable T-Server. Limitations ICON is unable to determine the party that released the call in the following situations: If the call was terminated during a time that ICON was down. On restart, ICON reports the releasing party information as if no data was received from T-Server. When a consultation call is terminated after a request to complete the transfer or conference (see the Note on page 45 for call-based reporting, and the Notes on page 46 for DN-based reporting). In these situations, ICON reports an empty string in the GSYS_EXT_VCH1 and GSYS_EXT_VCH2 fields in the G_CALL_STAT table, and the value 0 in the GSYS_EXT_INT1 field in the G_PARTY_STAT table.

Determining Data Availability and Reliability

ICON tracks detailed control data related to connections and events from ICON data sources, and stores the data in G_DSS_*_PROVIDER tables in IDB. For more information about the provider control tables, see “Data Source Session Control Tables” on page 32. Downstream reporting applications can analyze the control data to determine the availability and reliability of reporting data in a particular IDB. Based on the analysis, the downstream reporting applications can adjust the extraction, transformation, and loading (ETL) activities to optimize ETL processes. In high availability (HA) deployments, the downstream reporting application can use the results to identify which IDB is the better data source for a particular time interval. For more information, see “Extracting HA Data” on page 111. For information about the IDB inconsistencies that can result from unavailable data, see “Consequences of Failures” on page 108. Determining ICON Responsiveness Interaction Concentrator supports a mechanism that enables Local Control Agent (LCA) to determine whether the ICON server process has become unresponsive. An unresponsive process is one that appears to be running but for some reason is unable to provide service to its clients or peers. LCA can alert you to ICON’s status and enable you to take corrective action, such as restarting ICON. For more information on unresponsive process detection, see the Framework Management Layer User’s Guide. Determining Data Availability The following example of a typical scenario illustrates how the data in the control tables can be used to identify gaps in the reporting data. The scenario tracks one ICON instance and one T-Server, and considers the connection information that is applicable to only the GCC provider. Table 6 shows scenario values for connection-related fields in the G_DSS_GCC_PROVIDER table for various startup, disconnection, reconnection, and shutdown events that occur at times t0 through t6.

Scenario Example—G_DSS_GCC_Provider Table Field Values Events G_GCC_ Provider Table Record Selected G_DSS_GCC_PROVIDER Table Fields DSCONN_TYPE ICON_STIME DSCONN_STIME ICON_ETIME DSCONN_ETIME ICON starts up at t0, connects to T-Server at t1, and writes some data to IDB. New 1 t0 t1 Null Null ICON disconnects from T-Server at t2 (network failure case). Updated 1 t0 t1 Null t2 ICON reconnects to T-Server at t3 (network failure case). New 2 t0 t3 Null Null T-Server disconnects from the switch at t4. Updated 2 t0 t3 Null t4 T-Server reconnects to the switch at t5. New 4 t0 t5 Null Null ICON shuts down unexpectedly at t6. Or: No change when ICON restarts 4 t0 t5 Null Null ICON shuts down gracefully at t6. Updated when ICON restarts 4 t0 t5 t6 t6

Connection Analysis The history of the connection to the data source indicates the points of interruption in the data flow. In the scenario illustrated in Table 6, the downstream reporting application can determine that, for a particular ICON instance, data from T-Server was not reliably available during the following time intervals: t2–t3 t4–t5 Starting with t6 (in the case of a planned ICON shutdown, or in the case of an unplanned ICON shutdown in an HA deployment) t5–the time that the next new record is created (in the case of an unplanned ICON shutdown) The next new record is created after ICON restarts, reconnects to the data source, and receives the first event (at t7). From the existence of the new record, the ETL can infer that data was not available at some time between t5 and t7. The timestamp of the last processed event (LEVENT_DSTIME and LEVENT_ITIME) can help the downstream reporting application approximate the shutdown time (t6). In an HA deployment, the absence of information after t6 in, say, ICON-1 and the presence of information after t6 in ICON-2 will enable the ETL to reliably determine that data was not available for ICON-1 from t6 to t7. Determining IDB Availability The G_DSS_*_PROVIDER tables for the GCC, GLS, GUD, GOS and CFG roles provide an indirect heartbeat mechanism that enables the downstream reporting application to distinguish between (a) the case in which there is no data for ICON to store and (b) the case in which ICON does not store data in IDB because of a problem between ICON and IDB. If you want the G_DSS_*_PROVIDER tables to be populated, you must set the value of the use-dss-monitor configuration option to true.

No Data to Store For each provider, ICON stores in the persistent queue (.pq file) a timestamp of the last data that was written to the persistent queue. If no new data is written to the queue during a predefined interval, ICON creates a “no data” record for the applicable provider(s), and ICON sends this record to IDB in the usual way. The default value for this interval is 300 seconds; it can be changed if desired. NODATA_IUTC Field When the “no data” record is sent to IDB, the NODATA_IUTC field in the applicable G_DSS_*_PROVIDER tables is updated for all open sessions created by the ICON instance. The value of the NODATA_IUTC field is the time the “no data” record was created—in other words, the timestamp of the ICON confirmation that no data was received from the data source server in the previous period of time set for the “no data” interval. Example ICON-1 performs the gcc role and is connected to three data source servers: T-Server1, T-Server2, and T-Server3.The G_DSS_GCC_PROVIDER table contains records for active sessions for all three data source servers. The value for the “no data” interval is set to the default value of 300 seconds. Starting from time t0, T-Server1 and T-Server2 have no activity. However, T-Server3 continues to send data. No change is made to the value of the NODATA_IUTC field in the record for any of the sessions, because ICON is receiving data from a data source. Starting from time t1, T-Server3 has no activity. T-Server1 and T-Server2 continue to have no activity. No change is made to the value of the NODATA_IUTC field in the record for any of the sessions, because ICON has not yet identified the “no data” situation. At time t1 + 300 seconds, there is still no activity from T-Server1, T-Server2, or T-Server3. ICON creates the “no data” record and sends it to IDB. The NODATA_IUTC field in the record for all three sessions is updated with the timestamp of the “no data” record. IDB Availability Analysis The ETL can evaluate the recent activity of the NODATA_IUTC field value and the LEVENT_ITIME field value (the timestamp for the last event stored on the connection), and use the information to identify if there is a problem between ICON and IDB. Table 7 summarizes the analysis.

Determining IDB Availability Value of IDB Field During Last Two Minutes Conclusion LEVENT_ITIME NODATA_IUTC Changed Not applicable IDB is available, and new data is arriving. Unchanged Changed IDB is available, but there is no new data. Unchanged Unchanged IDB is not available.

Determining Data Reliability Interaction Concentrator provides mechanisms to determine the reliability of available data in two ways: Evaluation by ICON of the reliability of the data it records in IDB (see “Reliability of Data in IDB Records”) Evaluation by the downstream reporting application of the reliability of the data provided by a particular ICON instance (see “Reliability of Data from ICON and IDB”) Reliability of Data in IDB Records Within IDB, ICON uses system fields in various tables to flag the reliability of data in the record. For example, the GSYS_EXT_INT1 field in the G_USERDATA_HISTORY or G_SECURE_USERDATA_HISTORY tables indicates the reliability of the change type that is assigned to the user data record. For more information about the reliability flags in IDB, see the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS. Reliability of Data from ICON and IDB From the information in the provider control tables and the analysis of data availability, ICON users can evaluate the reliability of data from a particular ICON instance. ICON can guarantee the reliability of call data only if the call was visible to ICON for the entire call duration, from the time of call creation until call termination. ICON does not store any data for calls that were created before ICON started up. ICON does store data for calls that were created after ICON started up but that were not visible to ICON for the entire call duration. If the event flow that ICON monitors is incomplete (the call is not yet terminated) and the ETL determines that no new data is expected (IDB is not available), then data for all non-terminated calls should be considered unreliable. For information about further analysis of data reliability to optimize ETL extraction strategies in HA deployments, see “Extracting HA Data” on page 111. For information about the analysis of data availability, see “Determining Data Availability” on page 50.

Tracking Multi-Site Call Data Via ISCC

Multi-site calls are tracked using an intersite link, which enables you to connect the information regarding two calls that originated on two different sites. Intersite link (IS link) data is stored in the G_IS_LINK and the G_IS_LINK_HISTORY tables. It enables ICON to link all multi-site calls, determine the correct TEvent sequence, and check whether a multi-site call is completed. Determining the Correct Event Sequence To track the order in which events come from SIP Server, ICON writes the SIP Server event sequence in the GSYS_EXT_VCH1 field in the G_IS_LINK table. This TEvent sequence can be the same value for different data source sessions (DSSs). ICON also writes the value for LastTransferOrigDN from the TEvent into the GSYS_EXT_VCH2 field in the G_PARTY table and the value for LastTransferHomeLocation into the GSYS_EXT_VCH1 field in the G_PARTY table. ICON populates the TEvent attribute values for the ENDPOINTDN in the GSYS_EXT_VCH2 field and LastTransferHomeLocation in the GSYS_EXT_VCH1 field in the G_PARTY table whenever SIP Server provides this information. As a result, in multi-site interactions, ICON stores the necessary data to link ISCC calls, provide the correct event sequence, and determine when the call is completed. Determining When a Multi-Site Call is Completed A multi-site call is considered to be completed when one of the following occurs: All IS links have a corresponding IS-Link from another site. An IS link has been opened to an unmonitored switch. The timeout for an IS link to arrive from another site has expired, and all corresponding Interaction Roots in the G_IR table are closed. Post-Mortem IS_LINK Capability Post-mortem IS links occur when the information about the external site to which a call was transferred arrives after the call left the switch and ICON deleted it. When ICON receives EventTransactionStatus with the iscc.is-link-creation.post-mortem attribute set to true, ICON creates records in the G_IS_LINK table. The timestamp of the event is recorded as the link creation time, although that might be several seconds after call deletion. ICON creates the new record in the G_IS_LINK table even if the referenced call has not been recorded in IDB. As a result, IDB might store records in the G_IS_LINK table that do not have a matching record in the G_CALL table. The post-mortem IS link functionality can handle even complex scenarios. For example, ICON can correctly link and sequence call records for a consultation call that is transferred to another site and, after the transfer is complete, is merged with the main call.