External Call History White Paper

Provided by: Avaya Professional Services

Release 3.8
Issue 1
July 2019
Revision History

Version Date Author Comments

0.1 03/30/2008 Ken Stahl Initial Draft
0.2 03/31/2008 Kate Breece Added:
 Unique identifier section
 Glossary
0.3 04/03/2008 Roger Expanded Section for tracking calls with
Krimstock transfers
Expanded information on UCID.
Updated Section on unique key
1.0 04/28/2008 Kate Breece Finalized document for publication
2.0 04/28/2010 Kenneth C Stahl Updated for R16 changes
2.0.1 07/01/2010 Kenneth C Stahl Corrected max record size for the call_rec
table under section 2.1
3.0 08/01/2012 Kenneth C Stahl Additions for R16
3.1 06/19/2013 Kenneth C Stahl New appendix regarding segment length
calculation
3.2 03/19/2014 Kenneth C Stahl Updates for R17
3.3 07/31/2015 Kenneth C Stahl Updates for R18
3.4 01/07/2016 Kevin Archer Formatting Changes
3.5 02/15/2018 Kevin Archer Minor updates
3.6 1/31/2019 Kevin Archer Changed information on chr file naming
3.7 5/31/2019 Kevin Archer Updates for R18.1 ECD and R19
Formatting Changes
3.8 7/30/2019 Roger Various behaviors observed in ECH
Krimstock

July 2019 2
1 Introduction ......................................................................................... 7
2 The External Call History Record .................................................. 8
2.1 Introduction to ECH ............................................................................... 8
2.2 ECH Records ...................................................................................... 10
2.2.1 Call Record Data........................................................................................10
2.2.2 Segments and Chains ..............................................................................10
2.2.3 File Name Format ......................................................................................10
2.2.4 How Often Files are Generated .............................................................10
2.2.5 ECH Values .................................................................................................11
3 Tracking Call Transfers with ECH ............................................... 12
4 Troubleshooting Reporting Issues with ECH .......................... 13
4.1 Switch Settings .................................................................................... 13
4.2 Third party applications ........................................................................ 13
4.3 Vectoring in the ACD ........................................................................... 13
4.4 UCID ................................................................................................... 14
5 Troubleshooting Reporting Issues with ECH .......................... 15
5.1 Ensure Compatibility Across all Platforms ............................................ 15
5.2 Build a Test Environment ..................................................................... 15
5.3 Set Network Node Number to be Unique .............................................. 15
5.4 Ensure All Trunks are ISDN-PRI .......................................................... 15
6 Appendix A – ECH Record Description ..................................... 16
6.1 ACD (CMS) ......................................................................................... 16
6.2 ACWTIME ........................................................................................... 16
6.3 AGENTSKILLLEVEL (R16+) ................................................................ 16
6.4 AGENTSURPLUS (R16+).................................................................... 16
6.5 AGT_RELEASED ................................................................................ 16
6.6 ANS_ATTRIB_ID (New for R17, implemented in R18) .......................... 17
6.7 ANS_LOCID ........................................................................................ 17
6.8 ANSHOLDTIME .................................................................................. 17
6.9 ANSLOGIN.......................................................................................... 17

July 2019 3
 6.10 ANSREASON ...................................................................................... 17
6.11 ASAI_UUI ............................................................................................ 17
6.12 ASSIST ............................................................................................... 18
6.13 AUDIO ................................................................................................ 18
6.14 CALL_DISP ......................................................................................... 18
6.15 CALLID ............................................................................................... 19
6.16 CALLING_II ......................................................................................... 19
6.17 CALLING_PTY .................................................................................... 20
6.18 CONFERENCE ................................................................................... 20
6.19 CONSULTTIME................................................................................... 20
6.20 CWC1-CWC5 ...................................................................................... 21
6.21 DA_QUEUED ...................................................................................... 21
6.22 DIALED_NUM ..................................................................................... 21
6.23 DISPIVECTOR .................................................................................... 21
6.24 DISPPRIORITY ................................................................................... 21
6.25 DISPSKLEVEL .................................................................................... 21
6.26 DISPSPLIT .......................................................................................... 22
6.27 DISPTIME ........................................................................................... 22
6.28 DISPVDN ............................................................................................ 22
6.29 DURATION ......................................................................................... 22
6.30 ECD_CONTROL ................................................................................. 22
6.31 ECD_INFO .......................................................................................... 22
6.32 ECD_NUM .......................................................................................... 22
6.33 ECD_STR ........................................................................................... 22
6.34 EQ_LOCID .......................................................................................... 22
6.35 EQLOC ............................................................................................... 22
6.36 EVENT1...9 ......................................................................................... 22
6.37 FIRSTVDN .......................................................................................... 23
6.38 FIRSTVECTOR ................................................................................... 23
6.39 HELD .................................................................................................. 23

July 2019 4
 6.40 HOLDABN ........................................................................................... 23
6.41 INTERRUPTEDEL (R16+) ................................................................... 23
6.42 ICRRESENT (R16.3+) ......................................................................... 23
6.43 ICRPULLREASON (R16.3+) ................................................................ 23
6.44 LASTCWC .......................................................................................... 24
6.45 LASTDIGITS ....................................................................................... 24
6.46 LASTOBSERVER................................................................................ 24
6.47 MALICIOUS ........................................................................................ 24
6.48 NETINTIME ......................................................................................... 24
6.49 OBS_ATTRIB_ID (New for R17, implemented in R18).......................... 24
6.50 OBS_LOCID........................................................................................ 24
6.51 OBSERVINGCALL .............................................................................. 25
6.52 ORIG_ATTRIB_ID (New for R17, implemented in R18) ........................ 25
6.53 ORIG_LOCID ...................................................................................... 25
6.54 ORIGHOLDTIME ................................................................................. 25
6.55 ORIGLOGIN ........................................................................................ 25
6.56 ORIGREASON .................................................................................... 25
6.57 PREFSKILLLEVEL (R16+) .................................................................. 25
6.58 QUEUETIME ....................................................................................... 25
6.59 RINGTIME .......................................................................................... 25
6.60 SEGMENT .......................................................................................... 25
6.61 SEGSTART_UTC (R16+) .................................................................... 26
6.62 SEGSTART ......................................................................................... 26
6.63 SEGSTART_UTC (R16+) .................................................................... 26
6.64 SEGSTOP ........................................................................................... 26
6.65 SEGSTOP_UTC (R16+) ...................................................................... 26
6.66 SPLIT1..3 ............................................................................................ 26
6.67 TALKTIME .......................................................................................... 26
6.68 TKGRP ............................................................................................... 27
6.69 TRANSFERRED ................................................................................. 27

July 2019 5
 6.70 UUI_LEN ............................................................................................. 27
6.71 UCID ................................................................................................... 27
6.72 VDN2...9 ............................................................................................. 28
6.73 TENANT.............................................................................................. 28
7 Appendix B – Unique ECH Records ........................................... 29
8 Appendix C – ECH Comparison by CMS Version................... 30
9 Appendix D – Reference Data ...................................................... 35
10 Appendix E – Calculating segment length .................................. 36
11 Appendix F – Comparing ECH to CMS Metrics ........................ 37
12 Appendix F – Glossary .................................................................... 39

July 2019 6
1 Introduction
ECH, External Call History, is a powerful, but often misinterpreted feature of Avaya Call
Management System (CMS). This document represents years of experience working
with ECH in its various releases. It is intended to be a supplement to the CMS Call
History Interface product documentation that is available on Avaya’s support website:
http://support.avaya.com. Where conflicts exist between this document and the Avaya
product documentation, the product documentation should be considered authoritative.
In the sections which follow, various aspects of ECH are discussed to provide a
background to analysis of the data records that are generated by the ECH process. The
appendices contain reference information that details the meaning of each field in the
data set as well as some minor topics on topics that are related to ECH but are not
directly a part of ECH itself.
NOTE: Avaya does not support direct comparisons between CMS call history data
and the aggregated historical data. In most cases the counts of metrics like ACD
calls, abandon calls, transfers, etc. will not tally correctly. This occurs because
the two sets of data are derived independently of each other and there is no intent
by Avaya to ensure that both sets will produce the same totals. Avaya will take no
actions to resolve differences between the data sets.

July 2019 7
2 The External Call History Record
This section will explain the intricacies of ECH, offering a deeper understanding of the
data in ECH as well as the relationships between ECH records. Descriptions for each
data element within the ECH record can be found in appendix A.

2.1 Introduction to ECH

When voice contact activity occurs in the Avaya Communication Manager (CM), every
discrete action performed by the switch generates an event which is sent as binary data
to the CMS. Within CMS there is a series of Switch Protocol Interpreter (SPI) processes
which translate, summarize, and aggregate this data. The data is then made available
for either real-time or historical reporting.
While CMS standard reporting is beyond the scope of this document, there is a SPI
process steam that uses the binary data from the CM to create ECH data records. This
is a different process than is used to create the historical data such as agent, skill, VDN,
trunk and vector data that is used by CMS Supervisor reports.
Since historical data and ECH data are distinct interpretations of the binary data, and
because the fundamental purpose of ECH is different than the historical data, there is
never any guarantee that metric totals from the historical data will match the totals from
ECH and vice versa.
The Call History Interface exists in two forms:
1) Internal Call History (ICH)
Call history data is stored in the CMS call_rec table. Typically, the retention
period for this data is very short and it is not suitable for long-term reporting
purposes.

2) External call history (ECH)

Call history data that is sent to a series of binary files. The CMS add-on ECH
Handler can, optionally, convert these files to ASCII before forwarding the files to
some off-server destination. This is the form of Call History that is used most
frequently since the customer can control how long the data is retained in the
external storage. Once the data is sent to the off-server location, an application
such as Operational Analyst (OA) or Contact Analyzer (CA) can be used to load
the data into an external database which can then be used as a source of data
for reports using tools such as Cognos, SAP Crystal Reports, Reporting
Services, Tableau, SAP Business Object Enterprise, etc.
If OA is used to process the ECH file and load the data into the OA database, all
Extract/Transform/Load (ETL) operations are performed by the OA application. When
customers utilize an in-house database solution, a choice can be made to receive the
ECH files as delimited files in ASCII format or as raw binary files which must be parsed
according to the specification provided in the official ECH documentation.
For Internal Call History (ICH). The usage of these records is much more limited than
ECH data since a maximum of 100,000 call records are stored in the call_rec table in

July 2019 8
the Informix database on the CMS server. This is further limited by the level of activity
on all ACDs within the CMS of about 4,000 calls per 20-minute period (12,000 calls per
hour), divided among all administered ACDs. This table serves as a circular queue and
once the call limit is reached, the earliest records are purged to create space for newer
records.
Access to ICH data is available through the standard report: “Reports > Historical > Call
Record Report.” If External Call History is activated, however, internal call records will
no longer be collected, and this report will not appear in the menu. ECH and ICH are
therefore mutually exclusive – activating one, deactivates the other.
It is technically feasible to approximate ECH records in a manner that is somewhat like
what is stored in the historical data stores. But there are two significant reasons why
ECH data and CMS historical data will not always align: 1) the time of attribution written
in each record may throw off boundary calls within an interval, and 2) CMS summary
data includes non-call-based activity (e.g. agent information, service level calculations),
whereas ECH does not.
ECH is therefore not intended to be used as a primary tool for reporting agent detail
information. Although there is some agent information in ECH, it does not contain
complete agent details. For example, it is not possible to determine if an agent takes a
call on a top skill based solely upon ECH data, nor can the agent staff time on a skill be
determined. OA or CMS interval tables should be used to create a more complete
picture of agent activity over time.

July 2019 9
2.2 ECH Records
This section provides an understanding of what ECH is and how it is created.

2.2.1 Call Record Data

The Switch sends the CMS messages about calls via a binary stream of data that is
interpreted by Switch Protocol Interpreter (SPI) processes. Switch messages are
received by the CMS application to produce call record data, real-time data and
historical data. If the External Call History feature is activated on the CMS, the ECH
data is written to binary files that can then be exported to external systems.

2.2.2 Segments and Chains

Every trunk seizure in CM generates a new call segment. A call segment is a subset of
a complete call chain. The first segment of a call represents the initial trunk seizure.
Additional call segment records are created whenever the call is transferred, rerouted
(e.g. RONA) or conferenced. Once the call has been completed the CMS processes the
call record data and links the segments of the call together using a common CALLID
value.
Calls between Avaya switches (provided UCID has been enabled) can be tied together
via UCID. Segments that are part of the same call will each have discrete start times
(SEGSTART) but all segments in a call chain on the same ACD will share a common
end time (SEGSTOP), which will generally line up with the trunk release time. There is a
256-segment limit imposed by the ACD on the number of segments that can be
contained in single call chain.

2.2.3 File Name Format

When using the ECH Handler software, files are named chrxxxx.yyy ('chr' followed by a
4-digit number and an extension of from one to three digits) on the CMS. These files are
originally generated in the /cms/cmstables directory and are guaranteed to be unique
only for a 24-hour period from 00:00:00 to 23:59:59.
The ECH Handler software has additional functionality to move and uniquely name
these chr files once they are created. Enabling this feature guarantees that each file will
have a unique name. By default, the file name format is:
chrxxxx.YYYYMMDD.HHMMSS.TZ.

2.2.4 How Often Files are Generated

The maximum size of the call record buffer on the CMS is 99,999 call segments across
all administered ACDs. For example, a CMS with three ACDs will typically have a buffer
allocation of 33,333 call segments per ACD. This is initially defined at the time that ECH
is installed but can be modified at any time using administrative features of CMS
Supervisor.
It is possible to balance the number of call records across multiple ACDs by allocating
the records according to the call activity for the individual ACDs. If there are three ACDs
and ACD #2 receives 50% of the call and that the other two ACDs each account for

July 2019 10
25% of the call activity it is possible to set the allocation for ACD #2 at 50,000 and then
divide the remaining 49,999 records between the other two ACDs.
If ECH file generation stopped, the call records will continue to accumulate in the call
record buffer until the configured buffer size is reached. This buffer size allocation
should not be confused with ECH file sizing. As calls are processed, call records will be
recorded in a binary file (one record per call segment) until either the buffer size is
reached or the end of the CMS interval. However, if the buffers have been flushed
within ten minutes of the end of the interval as the result of buffer capacity being
reached, the next flush will not occur with the end of the current interval and then will
occur the next time the buffer limit has been reached or at the end of the next interval,
whichever comes first.
When multiple ACDs are configured, a smaller allocation can cause the buffers to be
flushed more frequently if the allocation of buffers for that ACD fills up more rapidly than
for the other ACDs. For example, if there are three ACDs in a CMS and the settings are
made according the values cited earlier, it would normally be expected that the buffers
for all three ACDs will fill up at about the same rate. But, if something were to happen
that would change the relative proportion of the number of calls handled by each ACD, it
could result in ECH files being produced more frequently because the buffer allocation
for ACD 1 or 3 filled at a faster rate than ACD 2.
The buffer allocation per ACD can be adjusted based on call volume or based on how
often chr files need to be generated. For example, if a customer wants to receive the chr
files more frequently they can decrease the buffer allocation which will in turn decrease
the size of the individual ECH files. In other words, if the buffer allocation is reduced, the
maximum size of the ECH files will be reduced by a corresponding percentage.

2.2.5 ECH Values

There are some general rules of thumb for ECH data items:
For binary value fields, the only possible values in ECH are 0 = false and 1 = true.
NULLS can be signified by a blank, an empty string, or -1. The value -1 is never a
meaningful value in any ECH field, so if the ECH processing method causes a -1 to
occur, it should always be interpreted just as if it were a null.
Times are displayed in seconds in the raw ECH binary record but are converted to
timestamp strings in ASCII. In addition, Operational Analyst will store the timestamps as
datetime GMT while the ASCII version of ECH will have timestamps that are in the time
zone of the ACD.

July 2019 11
3 Tracking Call Transfers with ECH
Transfers are indicated by a value of 1 in the TRANSFERRED field. However, this flag
value does not necessarily indicate a transfer was completed. It means that at some
point the agent initiated a transfer. To verify that a transfer completed, locate a
subsequent segment in the same call chain (i.e. common CALLID value) where a
transfer was received by another agent. If that occurs, the ORIGLOGIN field will have
the PBX logid of the initiating agent and the ANSLOGIN field will contain the PBX logid
of the agent who received the transfer.
The following scenario is an example of what a user will see for a call transferred to an
agent on the same switch, and then transferred to an agent on another switch. The two
call segments within the switch share the same CALLID but have different UCID values.
The 2 segments may or may not have the same UCID, depending upon SA8702 option
(a configuration item in Communication Manager).
When the call is transferred to an agent on a different switch, the call segment where
the transfer is initiated on the originating switch will share the same UCID as the first
call segment on the destination switch. This is easy to detect because the first five
characters of the UCID on the receiving segment will reflect the administered node
number of the originating ACD. By contrast, the CALLIDs for the 2 sets of call
segments will not be the same except by extremely rare coincidence where it just
happens that the algorithm which generates CALLID values just happens to use the
same value – but the chances of this happening must be considered purely
coincidental. But in this case the ACD will be different, so the combination of ACD and
UCID will be distinguishing. After this initial segment in the receiving ACD, any
additional call segments on the destination switch will share the same CALLID. In
practice, call segments within a call chain on the same switch share the same CALLID,
but will not share the same UCID. However, this can change depending upon the
SA8702 option.

July 2019 12
4 Troubleshooting Reporting Issues with ECH
Since the data in ECH is completely dependent on the makeup of a customer’s contact
center architecture and the configuration of each switch, as well as agent behavior, it is
not possible to cover all possible scenarios that may occur in a contact center in this
document. The following items are examples of issues that are known to affect the
ECH contents.

4.1 Switch Settings

ECH is highly sensitive to the Communications Manager (CM) settings. What follows
are some typical configuration issues that may influence ECH contents.
ALL Trunk, Skills, and VDNs should be configured as Measured (external or both) in the
switch. Many inconsistencies in ECH can be traced back to an unmeasured facility in
the switch.

4.2 Third party applications

Non-Avaya applications may not support UCID in the same manner as Avaya platforms.
Specifically, such applications may not pass UCID in the way expected by Avaya
applications.
The Avaya ACD must retain control of the call for ECH tracking purposes. If a third-
party adjunct takes call control at any point during the call, the results in ECH are
unpredictable. Only call handling processed by the ACD is recorded in ECH.

4.3 Vectoring in the ACD

Vector steps can affect ECH data. This might be obvious in some instances (queue to
skill 50 will cause DISPSPLIT to be 50 in the ECH record) and not in others (converse-
on skill 10 causes the ACD to retain control of the call where a route-to may not).
A converse-on vector step produces different ECH records than a queue-to vector step
when sending a call to an IVR.
The use of the VDN Return-to-destination feature may affect the way data is recorded in
ECH. This is especially true if the call is transferred to an ACD other than the one where
it was originally received unless special steps are performed to transfer the call back to
the first switch in the call chain.
The type of transfer performed by an IVR (VOX Transfer or VXML transfer) may affect
the way transfers are recorded in ECH. For non-Avaya IVRs that perform DTMF
transfers, it may not be possible to link all segments in the chain together because
effectively the IVR is starting a new call and then bridging the original call onto the new
call.
If any conference call participant other than the agent who starts the conference adds
additional individuals to the conference, those segments may not be recorded in a way
that can be linked to the original call chain. The only way to ensure that all conference
segments can be identified is for the agent who starts the conference to add new

July 2019 13
participants. Meet-me conferences are entirely different, and it may not be possible to
identify all participants in such a conference.

4.4 UCID
It should be noted that there are cases where a UCID will not be generated for some
call segments, or there will be no call record. It is not feasible to list every possible
situation in which this might occur, but if a call is initially received by an IVR system from
the network, and the call is handled entirely within the IVR, the call will not appear in the
ECH data. This is especially true if the IVR sits in front of the switch. In addition, if the
call traverses a non-Avaya switch, and is terminated at another Avaya switch, the
terminating switch will generate a new UCID and there will be no way to correlate the
original call to the terminating call if the non-Avaya switch does not follow industry
standard and copy the UCID to the call setup data. If a call is routed via Avaya’s Best
Services Routing feature, this may have unpredictable effects on UCID depending on
the BSR plan. It may be possible to discover how BSR is affecting the data through
analysis.
Since the creation of a UCID is related to trunk seizure, it is possible for the actual path
through the network and switch to affect the UCID. For example, if a call arrives over
one trunk from the network to an agent (a UCID is created for this call segment), the
agent then does a consultative transfer to another agent connected via a second trunk
(a second UCID is created for this call segment) and then the transfer is completed, it is
not clear which UCID will be assigned to the call, since it may depend upon the path
replacement algorithm in the switch. In other words, this is customer specific depending
on the configurations on each switch. The same applies to consultative conferencing.
Another scenario, with an anomalous ECH pattern, occurs when a call is sent to an IVR
via the “converse on” step during vector treatment. The resulting pair of ECH segments
share the same UCID, but have different CALLIDs, as if they represented separate call
chains.

July 2019 14
5 Troubleshooting Reporting Issues with ECH
If you are planning to implement a solution using ECH, ensure your site includes the
following criteria. These recommendations cover call data for Avaya switches only. The
following criteria are not comprehensive. Please refer to CMS External Call History
Interface manuals on support.avaya.com for implementation requirements.

5.1 Ensure Compatibility Across all Platforms

It is recommended to run the same versions of CM and CMS at least to the point that
the data available can be consolidated.

5.2 Build a Test Environment

Customers who are interested in ECH need to understand that all call centers are
different. Each routing scenario within a call center can produce different and
sometimes unexpected results in the ECH records. It is highly recommended that a test
environment is used to simulate all call scenarios and extrapolate the corresponding
records before ECH is used in a production environment. The configuration of a test
environment can then be modified to test various settings and vectors that can be
adjusted to produce the desired results in ECH.

5.3 Set Network Node Number to be Unique

Each ACD throughout the entire network must be defined with a unique node number.
The node number becomes the first five digits of the UCID value. It is then possible to
identify exactly which switch generates a discrete UCID value.

5.4 Ensure All Trunks are ISDN-PRI

Only PRI service ensures that complete call setup data is passed between switches.
The ISDN-BRI service may drop some elements of call setup data or may not pass any
call setup data.
However, any call transfers that traverse the PSTN could be affected by any routing
point along the way and call setup data may be incomplete. This is especially true
outside the United States or if the call passes through a private Central Office (CO)
within the United States.

July 2019 15
6 Appendix A – ECH Record Description
In the descriptions which follow, all field names that only exist in the OA table
CMSCALLHISTORY are identified with OA in parenthesis. Conversely, the fields that
are only present in the native ECH fields, but which are not found in OA are marked with
CMS in parenthesis. Otherwise, when differences occur between the ECH manual and
the OA table, the differences are described in the text.
6.1 ACD (CMS)
The ACD number associated with the segment. This does not appear in OA because it
is replaced by the SOURCEID field. The SOURCEID field in OA allows OA to handle
multiple CMSs with multiple ACDs, since each ACD would be assigned a unique
SOURCEID.
6.2 ACWTIME
Records the amount of time spent on after call work during the segment.
6.3 AGENTSKILLLEVEL (R16+)
This is the skill level that is assigned to the agent that handled the call.
6.4 AGENTSURPLUS (R16+)
Indicates whether the call was delivered to the agent under a surplus condition. This
field can have the following values:
0 – N/A
1 – Call surplus
2 – Agent surplus
An agent surplus exists if, at the time the call was delivered to an agent, another agent
with the same skill level was available.
A call surplus exists if, at the time the call was delivered to an agent, other calls remain
in the queue for the skill indicated by DISPSPLIT.
6.5 AGT_RELEASED
This field will have a value of 1 if the agent initiated an action which caused the call to
be released. This may be useful if agent behaviors are being investigated since
generally an inbound call should be terminated by the caller rather than by the agent.
An exception to this would occur if there is an after-call survey where the VDN-Return-
to-Destination feature is used to re-route the call to another adjunct (typically an
IVR/VRU) since in that case the agent must release the call while the caller is still active
on the call.
Another exception occurs when a call is transferred. When that occurs, the agent who
initiates the transfer must drop the call so that the agent receiving the call can take
control of the call.
If neither of those scenarios apply within a call and an agent has a high number of
segments where this field is non-zero, it may indicate that the agent is hanging up on

July 2019 16
callers. One possible motive for this behavior would be an attempt to handle more calls
in an hour.
6.6 ANS_ATTRIB_ID (New for R17, implemented in R18)
This field will contain a string with attributes of the answering agent.
6.7 ANS_LOCID
An identifier assigned to the CM server port number. While this value should remain the
same for a given agent across an agent logged-in session, it should not be used to
identify an agent since the value may change each time the agent logs in. Generally,
this field is seldom used for reporting purposes.
6.8 ANSHOLDTIME
The amount of time in seconds that the segment was in a hold status. Because a call
may be placed on hold multiple times, this field shows the total amount of time spent on
hold. Therefore, it is not possible to know the amount of time for each hold instance.
6.9 ANSLOGIN
The LOGID value for the agent who answered a call while logged into the ACD. The
agent is measured by being logged in and assigned to measured skills. It is possible to
have a null value in this field for an inbound call if the agent is not assigned to any
measured skills or if an agent answers an extension call while not logged in.
6.10 ANSREASON
The reason associated with the agent’s answering mode. If reasons defined in the
switch do not have corresponding entries in the CMS dictionary, the verbose definition
associated with the value cannot be known via the SYNONYMS table and therefore are
not available to reports.
6.11 ASAI_UUI
The ASAI User to User Information stored for the call (maximum of 96 bytes) is passed
to CMS in a message for storage in the ECH call record. This can be used to record
ASAI user data for the Variables in Vectors feature and for other applications. The UUI
data will be sent to CMS every time the call is routed to a measured VDN. Only the last
user data sent will remain stored in the call record. The program that creates the UUI
data may populate this field with virtually any type of data. UUI data can be ASCII,
compressed data, encrypted data, EBCDIC, Unicode, etc. If no UUI data exists, this
field is NULL.
This field should not be confused with call setup data. Those values are passed as a
separate data structure between the CO and a PBX or between PBXs but is not
recorded in its entirety in ECH.
A typical application that would use UUI would be a CTI application that uses with
adjunct routing. ABC Company would like to have a report that shows the account code
for callers. The adjunct, after determining the account code for the caller, will provide
that data to the switch by including a UUI IE with the route-select message in response
to an adjunct routing vector command route-request. The route-select will route the call

July 2019 17
to a measured VDN that provides the remaining processing for the call. CMS will then
receive the account code for the caller via the ASAI UUI data send when the call routes
to that VDN. The account code is then included in the UUI field in the ECH call record.
If the extra cost ASCII conversion ECH Handler feature is purchased, the UUI field will
be converted to Hexadecimal (Hex) notation. Optionally, the UUI field can be converted
to ASCII characters. However, UUI values expressed as ASCII characters may not be
suitable for loading into a database since the field is defined as arbitrary binary data.
UUI fields that contain non-printable control characters will be replaced with the string
“<non-printable value>” or another configurable value. Some printable ASCII characters,
such as a solitary quotation mark, can cause database load utilities to reject the record.
6.12 ASSIST
Indicates that the agent requested assistance during the segment. This does not mean
that any assistance was rendered. Since the value for this field can only be 0 or 1, there
is no indication as to the number of times that assistance was requested. In addition,
this field can only be set if either the hard or soft phone has been provisioned for the
use of this feature.
6.13 AUDIO
If set, this field indicates that there were audio problems experienced during the
segment. The only possible values are 0 and 1. This field is seldom used since it must
be programmed as a feature button on the agent’s phone.
6.14 CALL_DISP
The disposition of the call.
1= Connected. Any Non-ACD call to a measured agent
2=Answered. An ACD call that is routed by skill or is a direct agent call
3=Abandon (prior to first agent)
4=interflow
5=Forced busy
6=forced disconnect
7=other
8=ICR pulled (R16.3+)
If CALL_DISP is 1 or 2 and EQ_LOCID is not null and ANSLOGIN is populated with an
agent LOGID, then the segment represents an inbound call to an agent. If CALL_DISP
is 7 and ORIGLOGIN is populated, then it is an outbound call. If CALL_DISP is 7 and
ORIGINLOGIN is not populated it indicates some type of automated outbound call
processing has occurred – possibly a fax transmission.
A forced disconnect can occur through an explicit disconnect step in a vector, or if a
vector ends without routing the call.
The ICRPULLED value can only occur if ICR 2.0 or greater is configured.
If CALL_DISP is 2 and DA_QUEUED is 1, then DISPSPLIT will be null since the call is
not queued using a skill.

July 2019 18
6.15 CALLID
CMS can correlate call segments based on informational messages received from the
switch. Calls in CMS that are related to the same trunk seizure (e.g., transfers,
conferences, etc.) will be assigned the same CALLID in ECH but have different
sequence numbers (e.g. different SEGMENT values). This field is generated by CMS at
the time the call records are written to the ECH binary file rather than being generated
by the switch.
The CMS will tie segments together that have different UCIDs if it determines those
segments are related to the same call. CMS links call segments deterministically, based
upon switch messages, into a call chain. An example of this would be when a call
adjunct routes to a non-Avaya IVR, a new UCID is created for that segment (generated
by the IVR)
CALLID’s are not necessarily sequential but will be unique until the internal counter
wraps (TBD – the actual wrap limit).
CALLID values are unique per ACD.
CALLID values are generally only guaranteed to unique within a 24-hour period. That is
to say, for the 12-hour period preceding the call and the 12-hour period after the call.
Therefore, queries that attempt to identify all call segments associated with a CALLID
must also include the criteria that the SEGSTOP value must be the same across all of
the segments within a CALLID. For CMSs that have a very high volume, the period of
uniqueness may decrease even further.
6.16 CALLING_II
The Information Indicator value indicates the type of originating line for the call.
Examples would be values that indicate a hospital, jail, or pay phone. The values
generally conform to industry standards but not all central offices (CO) pass these
values downstream in call setup data. The values are always two digits.
Some of the standard values appear in the following table.

Value Meaning
00 POTS
01 Multi-party line (ANI cannot be provided)
02 ANI failure
06 Station level rating or hotel
07 Special Operator handling
20 Automatic Identified Outward Dialing (ANI is the PBX ANI)
23 Coin/Non-coin call from pay phone
24 Toll-free call translated to POTS
25 Toll-free call from pay phone translated to POTS
27 Coin call from pay phone

July 2019 19
 Value Meaning
29 Prison/Inmate
30 Intercept-no such number
31 Intercept-trouble (FBUSY)
32 Intercept-regular (disconnected/changed)
34 Telco Operator assist
52 Outbound WATS
60 TRS
61 Cellular Type 1
62 Cellular Type 2
63 Cellular Roaming
66 TRS from hotel/motel
70 Private pay phone
93 Private virtual network

6.17 CALLING_PTY
For an inbound call this will be the ANI if presented by the CO in call setup data. For an
internal extension call this will be the extension that originated the call. For a transfer,
this will be the extension of the agent performing the transfer. For an inbound call, if the
length of the value in this field corresponds to the number of characters in the dial plan,
it will indicate an internal call. Otherwise it will be an external call.
If an ANI is not passed in call setup data, this field will contain the trunk port on which
the call was received. This field will also be blank for incoming segments if the receiving
trunk is not measured. It will also be blank for outbound segments if the originating
extension is not measured.
Not all ANIs indicate the actual calling number of the call originator. If a caller is calling
from behind a PBX, the PBX itself may only pass the PBX cover number and this can
be any value that is administered on the PBX itself. The implication is that it is not
necessarily possible to make a return call to the ANI value and be connected to the
individual who placed a call.
6.18 CONFERENCE
Indicates that a conference was attempted during the segment. The field is set
regardless of whether the conference was successful. The only possible values are 0
and 1.
6.19 CONSULTTIME
The time an agent talks on an outbound call while in AUX, ACW, or in OTHER with a
call on hold. This includes the time the originating agent spent talking to the destination
party while establishing a conference or transferring a call. (This is the time between
presses of the transfer or conference button.) It includes wait time if the agent is calling
a VDN (Vector Directory Number) or split/skill extension. The wait time can be obtained

July 2019 20
by subtracting the DISPTIME item from CONSULTTIME. For agents that are
conferenced in to a call, all active time will be recorded as CONSULTTIME since only
the conference leader will accumulate TALKTIME.
For inbound calls for which the agent represented by ANSLOGIN does not have call
control (e.g. the portion of a consultative transfer prior to the release of the call by the
transferring agent, active time is accumulated in CONSULTTIME. Once call control has
been passed to the receiving agent, the segment will accrue TALKTIME.
6.20 CWC1-CWC5
When used, these fields indicate the call work codes that occurred during a segment.
Up to nine call work codes can be entered during a call segment, but only the first five
recorded in these fields. If six through nine call work codes are entered, the final call
work code will be recorded in the LASTCWC field. This means that if six call work codes
are entered, the first five will be found in fields CWC1-CWC5 and the last one will be
recorded in LASTCWC. However, if nine call work codes were entered, the codes for six
through eight would not be recorded in ECH, but the ninth one would be recorded in
LASTCWC.
6.21 DA_QUEUED
When set, the call was queued as a direct agent call. The only permissible values are 0
and 1. Agents must be configured for a DID number to receive direct agent queued
calls.
6.22 DIALED_NUM
For inbound vectored calls this is the VDN that was used to send the call to an agent.
Normally this will coincide with DISPVDN. For outbound calls and internal extension
calls this is the actual digits dialed by the agent. If the number of digits match the dialing
plan, the call is an internal extension call. Otherwise it is a call to a location outside the
network.
6.23 DISPIVECTOR
The vector in which the disposition occurred. This would be the vector that contains the
queue or check step
6.24 DISPPRIORITY
Only set when a call is queued to a skill. If the queuing is done within a vector and
switch advocate is not in use, the default value of 4 (medium) is used. If switch
advocate is in use, addition values of 3 (low), 4 (medium) 5 (high) and 6 (Top) can be
assigned within the vector. This field is only populated if the call is queued to a skill.
6.25 DISPSKLEVEL
The level (1-16) associated with the DISPSKILL for the agent who received the call. The
level is specified when the agent is assigned to a skill.
This field is useful in determining whether the agent assigned to the call does not have
the DISPSKILL as one of their top skills. This would tend to indicate that there are
insufficient agents logged in who have DISPSKILL as one of their primary skills.

July 2019 21
6.26 DISPSPLIT
The skill in which disposition occurred. In other words, the skill under which the call
segment was handled. For calls that are queued to an unmeasured skill, this field will be
set to 0.
6.27 DISPTIME
The amount of time spent in vectoring, in queue and ringing until an actual disposition
occurs (see CALL_DISP). This field will always be 0 for any type of direct extension call.
To determine vector time, perform the following calculation: DISPTIME-
(RINGTIME+QUEUETIME).
6.28 DISPVDN
The VDN used to disposition occurred. This field will be blank if a VDN was not used to
disposition the call.
6.29 DURATION
For each segment of a call, this value is the result of SEGSTOP-SEGSTART in
seconds. It does not include ACWTIME since that time would normally occur after the
trunk has been released.
DURATION should not be used to calculate the length of a call segment. For further
explanation of how to calculate a segment length, see Appendix E.
6.30 ECD_CONTROL
Whether the call was sent to the agent by Externally Controlled Distribution in the
Communication Manager. Valid values are 0 = NO and 1 = YES.
6.31 ECD_INFO
Information specific to the Externally Controlled Distribution application.
6.32 ECD_NUM
For future use.
6.33 ECD_STR
For future use.
6.34 EQ_LOCID
The port number of the trunk associated with the call as assigned by the
communications server. This field will be blank if the trunk is not measured.
6.35 EQLOC
The trunk number of the trunk that was used to handle the call. This field will be blank if
the trunk is not measured.
6.36 EVENT1...9
The count of the number of times that a user-defined event occurred during the
segment. These events are typically recorded by a programmed feature button on the
phone. These fields are often informally referred to as “peg counters”.

July 2019 22
6.37 FIRSTVDN
The VDN used by the CO to deliver the call to the switch. It may also be the VDN used
to deliver the call to an extension if there is no explicit vector assigned to the VDN.
6.38 FIRSTVECTOR
The vector assigned to the VDN that was used by the CO to deliver the call. Numerous
VDNs can use the same vector to process incoming ACD calls. The first vector is often
not the vector that actual delivers the call to a queue/agent. Vectors are programming
structures within the switch that contain a variety of instructions, including steps that will
hand off a call to other vectors if needed.
6.39 HELD
The count of the number of times that the call was placed on hold during the segment.
6.40 HOLDABN
If this field is set, it indicates that caller abandoned while on hold. This is different than a
disposition of 3 because HOLDABN can only be set while a call is actually connected to
an agent. The only permissible values are 0 and 1.
6.41 INTERRUPTEDEL (R16+)
This field is set to 1 if an agent became available to handle the call as the result of the
agent being made available from interruptible aux.
0 – An agent was not made available due to interruptible aux
1 – Auto-in-interrupt. The agent was in an interruptible aux state but was forced
into an available state to handle the contact. Upon completion of the call the
agent is automatically available for the next call
2 – Manual-in-interrupt. The agent was in an interruptible aux state but was
forced into an available state to handle the contact. Upon compleltion of the
contact, the agent is placed in after-call work.
3 – Notify-interrupt. The agent was in an interruptible aux state and remains in
that state unless the agent manually takes action to become available.
6.42 ICRRESENT (R16.3+)
If this field is set to 1, the call was re-sent to the CM by ICR. Otherwise the field is set to
0. This field is only meaningful if ICR is in use.
6.43 ICRPULLREASON (R16.3+)
This field indicates the reason that the call was pulled back by ICR.
0 – The call was not pulled back.
1 – The call was pulled back because resources are not available
2 – The call was pulled back due to a drastic increase in wait time
3 – The call was pulled back because the caller was receiving treatment
4 – The call was pulled back due to a network failure recovery condition
5 – The call was pulled back due to voice portal failure recovery
6 – The call was pulled back due to call interaction

July 2019 23
This field is only meaningful if ICR is in use.
6.44 LASTCWC
The last CWC value that was recorded during the segment. See the discussion in the
CWC1-CWC5 section for further information about call work codes.
6.45 LASTDIGITS
Holds the last digits that were entered by the customer in response to prompting in a
vector “collect” step. If multiple collect steps are used while processing the call, only the
last set of digits that are collected will be found in this field. These digits may also be
passed from an IVR if a converse step was used to pass the call to the IVR.
6.46 LASTOBSERVER
When service observing is used, this is the LOGID of the last agent that conducted
service observing during the segment. If there is a value in this field, then there should
be another segment for the call with OBSERVINGCALL=1 and an OBS_LOCID value
set and where ORIGLOGIN matches the LASTOBSERVER value in the segment that
was observed. (Note: Observing is performed by supervisors. However, for the sake of
reporting, supervisors are defined in the same manner as agents– before someone can
be given the role of supervisor, they must first be created as an agent.
It is possible to have multiple observers on a call segment between the time the
segment begins and ends, but there can only be one observer at a time. If there are
multiple observers, only the LOGID of the last observer will be recorded in this field.
However, other observers can be identified using the OBSERVINGCALL field.
6.47 MALICIOUS
Indicates that the agent initiated malicious call trace on this segment. This is a feature
that must be programmed into the phone feature button. CM can be configured to take
specific actions when an agent indicates a malicious call.
6.48 NETINTIME
The amount of time in seconds that the call spent in VDN/Vector processing in another
ACD prior to the call arriving at the current ACD. This is typically associated with Best
Service Routing and switch Advocate, although there are other cases where vector
treatment can cause calls to be redirected.
6.49 OBS_ATTRIB_ID (New for R17, implemented in R18)
This field contains a string identifying attributes of the observing agent. Only used with
service observing.
6.50 OBS_LOCID
The location ID for the location from which service observing took place. The range of
values is 0-250. If this field is populated in a segment, then OBSERVINGCALL should
be set in the same segment.

July 2019 24
6.51 OBSERVINGCALL
If this field is set in a segment, then the agent identified in the ORIGLOGIN of the same
segment performed servicing observing on a segment of the call.
6.52 ORIG_ATTRIB_ID (New for R17, implemented in R18)
This field contains a string identifying attributes of the originating agent.
6.53 ORIG_LOCID
The location ID for the agent originating a call. If this field is populated ORIGLOGIN
should be populated in the same segment to indicate the logid of the supervisor
performing the service observing.
6.54 ORIGHOLDTIME
The total number of seconds that the originating agent had an outbound call on hold.
6.55 ORIGLOGIN
The LOGID of the agent that initiates an outbound call, an internal extension call, or a
transfer.
6.56 ORIGREASON
The reason code associated with an outbound call. One typical usage for this field is to
indicate that the call was made by an outbound dialer application.
6.57 PREFSKILLLEVEL (R16+)
This field indicates whether the call was delivered via the preferred skill level check in a
vector.
0 – N/A
1 – Not preferred. The agent’s skill level for this skill does not match the level
specified in the check vector command. Nevertheless, that call was delivered
because there was no agent available with the preferred skill level or better.
2 – Preferred. The agent’s level for the skill matches the preferred skill level
specified by the check vector command.
6.58 QUEUETIME
The amount of time that the segment spent in queue. More than one segment in a call
can have queue time recorded if an agent transfers a call to a queue.
6.59 RINGTIME
The amount of time that the call spent ringing during the segment.
6.60 SEGMENT
A numeric value representing a segment. The value that appears in this field may not be
related to the order in which the segment occurs in the progression of the call. In most
cases the value of 1 should indicate the first segment, but it is not possible to rely on
this to determine the order of segments. The only method that is reliable to determine
segment order is to sort the segments on the SEGSTART value. However, since that

July 2019 25
field is only granular to the second, two segments in a call can technically have the
same SEGSTART value. In that case it is not possible to determine which segment
occurred first – however, this scenario should be rare for most call centers.
6.61 SEGSTART_UTC (R16+)
The SEGSTART time converted to UTC (Greenwich Mean Time).
6.62 SEGSTART
SEGSTART and SEGSTOP are times that are generated by CM. In the raw format
contained in the ECH binary files, these times are a count of the number of seconds
since January 1st, 1970 12:00:00AM (adjusted for the local time zone of the respective
ACD). This is not to be confused with GMT time and has nothing to do with the CMS
time and/or TIMEZONE. Consider these times to be ACD local time. However, if the
ASCII breakout of ECH is used this field will be represented by a timestamp value that
indicates local time. If the data is sent to Avaya Operational Analyst, the field value is
adjusted to reflect GMT time. SEGSTART records the value for the start of each
segment. SEGSTOP always reflect the time that the call ends in the ACD. Hence,
SEGSTOP will be the same for all segments of a call that occur within an ACD as
opposed to the time that an individual segment ends.
6.63 SEGSTART_UTC (R16+)
The SEGSTART time expressed as UTC (Greenwich Mean Time).
6.64 SEGSTOP
See definition of SEGSTART.
6.65 SEGSTOP_UTC (R16+)
The SEGSTOP time expressed as UTC (Greenwich Mean Time).
6.66 SPLIT1..3
The skills that were used to queue the call in vector processing. Only one of these
values will indicate the actual skill used to deliver the call and the values will be
recorded in the order that vector processing occurs. They are not necessarily the queue
the call was answered in, see DISPSPLIT.
These values are typically dependent on the skills that are assigned to a queuing VDN.
However, that usage is somewhat deprecated in contemporary usage and it is generally
normal to only assign a single skill to a VDN. Therefore, it is rare for SPLIT2 or SPLIT3
to ever have a meaningful value.
6.67 TALKTIME
The amount of time that the call spent in active time when the call was not in queue, on
hold, ringing, etc.
TALKTIME is only accumulated on inbound segments for which the agent has call
control. For inbound segments where the agent represented by ANSLOGIN does not
have call control, any active time is recorded in CONSULTTIME.

July 2019 26
6.68 TKGRP
The identifier for the trunk group for the trunk that delivered the call.
6.69 TRANSFERRED
Indicates that a call transfer was attempted on this segment. It does not indicate that a
transfer was successful or completed. For example, if an agent initiates a consultative
transfer, but decides to cancel the transfer after the destination agent answers and both
agents talk to each other, the TRANSFERRED field is still set even though the agent
retains control of the call. Possible values are 0 and 1.
6.70 UUI_LEN
The length of the actual value in the UUI field.
When Avaya Interaction Center (IC) is present, the ASAI_UUI field will hold the EDUID
associated with the call. If this information is passed to OA, it is converted to a HEX-
encoded value with each EDU id character being converted to the Hex equivalent.
Since EDUID values are always 32 characters long, the value 32 will be found in
UUI_LEN even though the actual number of characters in
CMSCALLHISORY.ASAI_UUI is 64.
Without IC, custom applications can be used to write arbitrary data to the switch UUI
field. This data would then be written to ECH in the same manner as just described,
although the length would be determined dynamically at the time it is extracted.
6.71 UCID
Universal Call ID (UCID) is unique tag that is associated with a call segment. The UCID
uniquely defines a call across compatible products and Avaya sites when enabled and
configured in CM. The first five characters of the UCID normally indicate the node
number associated with the ACD that processed the call except when a transfer occurs.
By default, the UCID uniquely identifies a single call segment. However, when a certain
switch feature is enabled (SA8702, aka UCID re-use), the UCID is extended to identify
the complete call chain, including both internal and external transfers and conferences.
The UCID will be unique for approximately 136 years from January 1st, 1970. At the end
of the 136-year period, the UCID (specifically the timestamp within the UCID) will
recycle. There is a situation, however, that poses a risk of creating duplicate UCIDs
within the 136-year period when the clock on Communication Manager is reset to an
earlier time (i.e., time of day clock changes as a result of daylight savings time). This
can occur if there is clock drift on the PBX and the clock is reset to an earlier time. The
duplication occurs if the combination of UCID Timestamp and Call Sequence Number
equals a UCID Timestamp and Call Sequence Number combination that occurred prior
to the Communication Manager time-of-day clock being reset. This underscores the
need to have the PBX configured to time-sync to a reliable time source. By default, the
PBX will time-sync with the PSTN, but it is possible to configure newer switches to time
sync from a Network Time Protocol (NTP) server.
See section 4.2, Connecting ECH Records for further discussion on UCID.

July 2019 27
6.72 VDN2...9
The successive VDNS that are used during the course of a call as the call is routed prior
to the value in DISPVDN. Some of the entries in these fields may be the direct result of
agent actions, but others may be the result of vector actions when a call is transferred to
a queue. If VDN9 is used it may or may not represent the 9th VDN that is used, however
it will always represent the last VDN used. So, if fifteen VDNS are used, the first vdn will
be recorded in the FIRSTVDN field, VDNs 2-8 will be recorded in VDN2..8 and VDN9
will contain the fifteenth VDN used.
6.73 TENANT
The ID of the Tenant with which the call segment is associated.

July 2019 28
7 Appendix B – Unique ECH Records
Use the combined columns indicated below to insure each record is unique when
querying the CMS Call History (ECH) record to track calls containing transfers.

ACD Int The ACD number for which data was collected.

CallID Int A unique number that is assigned to this call and all of its call
segments. For conferenced and transferred calls, two (or more)
calls are associated with each other. When the entire call is
recorded, one CALLID is used to join all of the associated call
segments. In “meet-me” conferences, this may result in a “later”
segment of the call starting earlier than the first segment.
CALLIDs are not strictly sequential but will be unique for all calls
recorded over the course of a day.

Segment Int The number identifying the call segment. Segment numbers are
from 1 up to the number of segments in the call.

UCID varchar(20) Universal call identifier provided for most call segments from
ECS R6 and newer switches when that feature is enabled.
Some call segments dynamically created by CMS in multiple
party call scenarios may use the default value of all zeroes in
the absence of the appropriate switch information. Defaults to
“00000000000000000000”.

July 2019 29
8 Appendix C – ECH Comparison by CMS Version
Not all versions of CMS produce exactly the same ECH output. In the table below, the
versions of ECH from R3V8 to the current version are listed as well as all fields that can
be found in the most recent release of ECH. An “X” in each a box indicates that the field
is available in that version of ECH.
The order of fields does not correspond to the order that the fields appear in the binary
file. Refer to the product documentation for the exact field order in the binary file.

Field R12 R13 R13.1 R14 R15 R16 R17 R18 R18.1 Comments
ECD
(R19)

ACD X X X X X X X X X Note 1

ACWTIME X X X X X X X X X

AGT_RELEASED X X X X X X X X X

ANS_LOCID X X X X X X X X X

ANSHOLDTIME X X X X X X X X X

ANSLOGIN X X X X X X X X X

ANSREASON X X X X X X X X X

ASSIST X X X X X X X X X

AUDIO X X X X X X X X X

ASAIUUI X X X X X X X X X

AGENTSURPLUS X X X X

AGENTSKILLLEVEL X X X X

CALL_DISP X X X X X X X X X Note 2

CALLID X X X X X X X X X

CALLING_II X X X X X X X X X

CALLING_PTY X X X X X X X X X

CONFERENCE X X X X X X X X X

CONSULTTIME X X X X X X X X X

July 2019 30
Field R12 R13 R13.1 R14 R15 R16 R17 R18 R18.1 Comments
ECD
(R19)

CWC1 X X X X X X X X X

CWC2 X X X X X X X X X

CWC3 X X X X X X X X X

CWC4 X X X X X X X X X

CWC5 X X X X X X X X X

DA_QUEUED X X X X X X X X X

DIALED_NUM X X X X X X X X X

DISPOSITION X X X X X X X X X Note 2

DISPIVECTOR X X X X X X X X X

DISPPRIORITY X X X X X X X X X

DISPSKLEVEL X X X X X X X X X

DISPSPLIT X X X X X X X X X

DISPTIME X X X X X X X X X

DISPVDN X X X X X X X X X

DURATION X X X X X X X X X

ECD_CONTROL X

ECD_INFO X

ECD_NUM X

ECD_STR X

EQ_LOCID X X X X X X X X X

EQLOC X X X X X X X X X

EVENT1 X X X X X X X X X

EVENT2 X X X X X X X X X

EVENT3 X X X X X X X X X

July 2019 31
Field R12 R13 R13.1 R14 R15 R16 R17 R18 R18.1 Comments
ECD
(R19)

EVENT4 X X X X X X X X X

EVENT5 X X X X X X X X X

EVENT6 X X X X X X X X X

EVENT7 X X X X X X X X X

EVENT8 X X X X X X X X X

EVENT9 X X X X X X X X X

FIRSTVDN X X X X X X X X X

FIRSTVECTOR X X X X X X X X X

HELD X X X X X X X X X

HOLDABN X X X X X X X X X

INTERRUPTDEL X X X X

LASTCWC X X X X X X X X X

LASTDIGITS X X X X X X X X X

LASTOBSERVER X X X X X X X X X

MALICIOUS X X X X X X X X X

NETINTIME X X X X X X X X X

OBS_LOCID X X X X X X X X X

OBSERVINGCALL X X X X X X X X X

ORIG_LOCID X X X X X X X X X

ORIGHOLDTIME X X X X X X X X X

ORIGLOGIN X X X X X X X X X

ORIGREASON X X X X X X X X X

PREFSKILLLEVEL X X X X

QUEUETIME X X X X X X X X X

July 2019 32
Field R12 R13 R13.1 R14 R15 R16 R17 R18 R18.1 Comments
ECD
(R19)

RINGTIME X X X X X X X X X

SEGMENT X X X X X X X X X

SEGSTART_UTC X X X X

SEGSTART X X X X X X X X X

SEGSTOP_UTC X X X

SEGSTOP X X X X X X X X X

SPLIT1 X X X X X X X X X

SPLIT2 X X X X X X X X X

SPLIT3 X X X X X X X X X

TALKTIME X X X X X X X X X

TKGRP X X X X X X X X X

TRANSFERRED X X X X X X X X X

UUI_LEN X X X X X X X X X

UCID X X X X X X X X X

VDN2 X X X X X X X X X

VDN3 X X X X X X X X X

VDN4 X X X X X X X X X

VDN5 X X X X X X X X X

VDN6 X X X X X X X X X

VDN7 X X X X X X X X X

VDN8 X X X X X X X X X

VDN9 X X X X X X X X X

ANS_ATTRIB_ID X X

ORIG_ATTRIB_ID X X

July 2019 33
Field R12 R13 R13.1 R14 R15 R16 R17 R18 R18.1 Comments
ECD
(R19)

OBS_ATTRIB_ID X X

TENANT X X

Note 1: In OA, the ACD field is replaced with SOURCEID since OA can accept
input from multiple CMS systems.
Note 2: Beginning with R13, this field is named CALL_DISP in product
documentation. In OA the field is named DISPOSITION for all versions.

July 2019 34
9 Appendix D – Reference Data
Many fields in ECH that have arbitrary values that are defined elsewhere. Some of
these values are defined in the CMS dictionary. If an item such as an agent, skill, VDN,
etc. is defined in the switch but does not have a corresponding entry in the CMS
dictionary, any verbose meaning of the item value would not be known.
The CMS dictionary items are stored in the SYNONYMS table within the Informix
database on the CMS server.
There are three ways to handle reference data:
If ech_handler is configured with the ASCII option, then daily the ech_handler process
will extract the categories of dictionary items and write them to a series of ASCII data
files with names like agname.dat, split.dat, vdn.dat, agroup.dat, etc. These files can be
loaded into external database tables and could then queries could be used to join from
the table where ECH data is stored to the tables where the reference data is stored.
If ECH data is sent to Avaya Operational Analyst, the data will be normalized into tables
that will just hold one type of reference data. For example, agent logins would be found
in the OA table CMSAGENTINFO, skill data would be found in the OA table
CMSSKILLINFO, etc.
If ech_handler just sends raw ECH binary files, it will be necessary to create a process
that will extract the reference data from the Informix SYNONYMS table that can be
loaded into the external database. The exact structure of the SYNONYMS table is
beyond the scope of this document.
Some fields in ECH contain values that have static definitions but the definition of those
items are not stored in CMS database tables. These fields may be defined in product
documents or can be derived by other means. An example is the EQLOC field which is
an intelligent key that can be broken down into its component parts, but that breakout
cannot be performed with reference to data stored in the Informix database. Another
example is the CALLING_II field whose contents are defined within the
telecommunications industry and is beyond the control of Avaya.

July 2019 35
10 Appendix E – Calculating segment length
Calculating the length of a segment may be more difficult than it might appear at first
glance. The DURATION field would appear to contain the segment length, but that field
merely reflects the value derived from SEGSTOP-SEGSTART for that segment so
when there are multiple call segments in a single call, the value is not meaningful.
Therefore, to calculate the length of the segment, the starting value is always
SEGSTART. To this value, several other values can be added depending on the
reporting goals. Therefore, any or all the following fields can be used to calculate
segment length:
TALKTIME – This field reflects the active time of a non-aux call for which the agent has
call control.
CONSULTTIME – This field reflects the time that an agent spends on the segment while
either in an AUX state or a consultative state such that as associated with transfers,
conferences and ACWOUT.
ANSHOLDTIME/ORIGHOLDTIME – These two fields are mutually exclusive. In any
specific segment only one of these two fields can be non-zero. Therefore they can be
logically added together to form a pseudo-field called, simply, HOLDTIME
DISPTIME – This field is complex because it actually represents three distinct values: 1)
System time 2) ring time and 3) queue time. Since QUEUETIME and RINGTIME are
available as separate fields, it is possible to calculate system time with the following
formula:
SYSTIME = DISPTIME – (RINGTIME+QUEUETIME)
Therefore, in reporting if all three should be included in the calculation of the segment
length, the DISPTIME value can be used. However, since system time and queue time
are not reflective of agent utilization, including DISPTIME may not be an accurate
indication of how much time the agent spent on the segment – although it does indicate
the amount of time from when the segment starts until when the call is delivered to an
agent.
RINGTIME – This is the amount of time that the call spent alerting. However, if the
agent is configured for auto-answer, RINGTIME will normally be zero, although in some
cases it may reflect one second just based on timing tolerances. Although if the switch
is configured to present the call in a manner that will allow the call to alert and the agent
must then accept the call, this value will be meaningful. If RONA is also configured,
RINGTIME should never exceed the RONA limit. This is also a component of
DISPTIME. For additional discussion of this field, see DISPTIME above.
QUEUETIME – This is the amount of time that a call is in queue waiting for assignment
to an agent. It is also a component of DISPTIME. See the description of DISPTIME
above.
ACWTIME – This is the amount of time that an agent spends in after call work. While it
is not related to the length of the call segment itself, it is a factor in agent utilization in
that the ACW state will block an ACD call from being routed to the agent. In some

July 2019 36
cases, the switch is configured so that an agent is automatically thrown into an ACW
state at the end of a call (or upon a transfer); If that occurs it is either timed ACW where
the ACW state will continue for a specified amount of time or will continue until the
agent puts themselves into a ready state. However, even if timed ACW is used, the
agent can override the timer by placing themself in a ready state. If automatic timed
ACW is not used, then the agent must initiate a request for ACW while the call is in
progress and then the agent must put themselves back into a ready state at the
completion of ACW.
Based on the explanations above for inbound calls, the calculation of segment time
relative to agent handle time is:
SEGSTART + TALKTIME + ANSHOLDTIME + RINGTIME + ACWTIME
For outbound (either AUXOUT or ACWOUT) calls there is no TALKTIME, so the
calculation becomes:
SEGSTART + DISPTIME + CONSULTTIME + ORIGHOLDTIME + ACWTIME
If overall segment time is desired regardless of agent handle time, the calculation would
be:
SEGSTART + DISPTIME + TALKTIME + ANSHOLDTIME + ORIGHOLDTIME
If calculations are desired for the overall physical call that extends across multiple
segments, and if the details are not needed, then it is simply a matter of subtracting
SEGSTART from SEGSTOP for the first segment of the call (i.e. the segment within a
CALLID that has the lowest SEGSTART value). This will also coincide with DURATION
of that first segment.

11 Appendix F – Comparing ECH to CMS Metrics

The grain of an ECH record is an individual call segment. CMS metrics are summarized
by category (agent, skill, vdn, etc.) and by interval. Due to the differences in how CMS
and ECH interpret SPI messages, Avaya does not guarantee that comparing one data
set will be a subset of the other. The data in the CMS tables is not just aggregated ECH
data. Therefore, a comparison in many cases doesn’t make sense.
The most important thing when comparing call history data with CMS aggregated data
is proper filtering. To compare e.g. ACDCALLS on skill level, you need to filter the call
history data:
- On SEGSTOPTIME to narrow the data for the corresponding CMS time interval
(not SEGSTARTTIME!)
- On DISPSPLIT (not any other skill field)
- On DISPOSITION=2 (i.e. ACD answered calls)

The number of records would be the number of ACDCALLS in the given time interval for
the respective skill. This typically is close or matches exactly the call counts in CMS.

July 2019 37
Not all data items in aggregated CMS tables can be compared to ECH. For some
measures it is impossible. The simple reason is that aggregated CMS tables are
focused on specific measured instances (e.g. agent, skill, vdn), while ECH data just
focuses on a call segment.

July 2019 38
12 Appendix F – Glossary
The following table defines acronyms and specialized terms used within this document.

Term Definition

ACD Automatic Call Distributor

Basic Rate Interface. An ISDN service that provides two 64Kbps

BRI
bearer (voice+digital) channels and 1 16Kbps data channel

Chr files Temporary files used to collect and process call data records.

CO Central Office

CM Communication Manager

Call Management System – administration and reporting

CMS application designed for enterprises that receive a large volume of
calls and have complex contact center operations.

Dual Tone Multi-Frequency – aka Touch Tone. Allows navigation

DTMF
of voice menus as well as other advanced calling services.

EAS Expert Agent Selection

ECH External Call History – historical call record

Extract Transform and Load – industry term for pulling data from a
source, formatting and conforming the data, then inserting into a
ETL destination. Source and destination are usually relational
databases, but can include ASCII files, Excel Spreadsheets as well
as other file formats.

EP Experience Portal

IC Interaction Center

ICR Intelligent Call Routing

Integrated Services Digital Network. A set of communication

ISDN standards enabling telephone lines to carry digitalized voice, digital
network services and digitalized video.

IVR Interactive Voice Response

Operational Analyst – real time and historical reporting database for

OA
call data.

July 2019 39
 Primary Rate Interface. An ISDN service that provides 23 64Kbps
PRI bearer (voice & data) channels and one 64Kbps digital-only
channels over a T1 line

PSTN Public Switched Telephone Network

A feature available on the switch that will override the UCID of the
SA8702
destination portion of the transfer with the parent UCID.

SPI Switch Protocol Interface

VDN Vector Directory Number

A programming construct used within the switch to process a call

Vector
delivered to a VDN

VP Voice Portal

VRU Voice Recognition Unit

Random Observations of ECH Behavior

To gather the call segments in the transfer/conference scenario, follow the ANSLOGIN
to ORIGLOGIN pattern. That is, ANSLOGIN becomes the ORIGLOGIN login of the
next call segment.
Unmeasured resources (trunk group, VDN, skill). The analogous fields in ECH are
NULL/empty. There WILL be a record! Clearly, it’s always best to measure
EVERYTHING if you want to use any CMS data (and that of course includes ECH)
reliably.
All 0s UCID (i.e., 00000000000000000000). When there is no switch data for UCID, the
default is all 0s. This occurs for dynamically created call segments (by CMS) in multiple
party call scenarios. A little more. On a DNEVENT (from the switch), if the R bit is set,
the call is treated as a transfer, which leads to CMS creating a “fake” call segment. In
R12, there was a problem with incorrectly set R12 bit. “Legitimate” reasons for all 0s
UCID (i.e., CMS creates “fake” segment): 1) VDN redirect (R bit set), and 2) path
replacement. “Fake” call segments can be part of “real” calls.
All 0s UCID. Note that an all 0s call segment can be a member of a call chain that
includes other segments with “valid” UCIDs. A call segment with an all 0s UCID can
have a non-NULL ANSLOGIN. And, the segment with all 0s UCID can occur after the
earliest record with a “valid” UCID.
Call chains can include segments with disposition 4 (interflow) and 7 (“outgoing”). They
generally do not indicate call segments with agent involvement. Instead, they typically
result from vector steps that route calls outside the switch (interflow). Conceptually,
they can be “merged”, where the UCID for the disposition 7 may be used as part of a
UCID bridge (on same switch? Or always on another switch? TBD).

July 2019 40
A number of call segment pairs, disposition 4 and 7, but ANSLOGIN, ORIGLOGIN, and
VDN all NULL, and yet the call segments share the same UCID (different CALLID per
pair), and one call segment has TRANSFERRED=1 (disposition 7). We currently don’t
know how these calls get started. It may have to do with trunk/trunk group settings on
the switch. They are not transfers.
LAI & BSR => same UCID, 1 contact, 2 SETUP messages. IQ handles the call until the
trunk goes idle, resulting in 1 record. ECH has 2.
Voice recording includes TSAPI connection to application that monitors stations, and
initiates calls (via API).
• Weird pattern of 2 call segments with the same SEGSTART and SEGSTOP,
same UCID, same ANSLOGIN, but different CALLID. In this case, the WFO
application is notified of a call on a monitored station, and then the application
makes API call to station to conference itself in so that it can record the call. In
the API call, it sends ANSLOGIN (it received via TSAPI) and UCID to the switch,
which then calls the recorder application. This occurs when the recorder
application is set to “stitch” together voice from all the call segments.
• Possibly related. Generally, ACD/UCID/ANSLOGIN should be unique across
ECH call segments. One possibility is for an agent to transfer a call to an agent
with the same logid on a different switch. The pattern is: calls with the same
UCID, different CALLID, same ANSLOGIN, in the same time frame, with
incoming disposition (1 or 2), sometimes the calls overlap, other times they don’t.

July 2019 41