August 2011

August 2011
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version
of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED "AS IS" WITH ALL
FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON INFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR
ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at
http://www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are
shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
Cisco Unified ICM ACD Supplement for Avaya Communication Manager
Copyright 2010 Cisco Systems, Inc.
All rights reserved.
iii
Contents
Preface .......................................................................................... vii
1. Overview ................................................................................. 11
1.1. Avaya ACD Interface Requirements ................................................... 12
1.1.1. Avaya ACD with CVLAN Service
running on Avaya AES ............................................................... 12
1.1.2. Call Management System (CMS) .............................................. 13
1.1.3. Avaya CMS-less Interface ....................................................... 14
1.1.4. Busy Hour Call Rates for Ethernet CTI link ............................... 15
1.2. Hardware and Software Requirements .............................................. 15
1.3. Supported Unified ICM Software Features ........................................ 17
2. ACD Configuration ................................................................. 19
2.1. Monitored VDNs and Inbound ACD Calls .......................................... 20
2.2. Monitored Splits on CMS ..................................................................... 20
2.3. Terminal Endpoint Identifier (TEI) Values .......................................... 20
2.4. Configuring the AES ............................................................................ 20
2.4.1. Setting up the CTI Links on AES Server .................................... 21
2.4.2. Changing/ displaying a CTI Link ................................................ 22
2.4.3. Setting Up Hunt Groups/Skill Groups ........................................ 23
2.4.4. Defining a Hunt Group/Skill Group for Agents ........................... 25
2.4.5. Modifying the Agent Login ID ..................................................... 26
2.4.6. Creating a Station Record for Phantom Lines ........................... 26
2.4.7. Setting up Call Routing .............................................................. 27
2.4.8. Create a Vector Directory Number ............................................. 29
2.4.9. Sharing Information .................................................................... 30
2.4.10. Recording Avaya ACD Information ............................................ 31
2.5. Configuring Return Destination
VDN on Avaya Switch ......................................................................... 32
2.6. Ethernet Busy Hour Call Rates ........................................................... 34
2.6.1. Post-Routing, Station Monitoring,
Third-Party Call Control ............................................................. 34
2.6.2. Active Association Limit ............................................................. 34
iv Contents

2.6.3. Maximum Agent and BHCA ....................................................... 35
2.7. Call Handling Methods to Avoid ......................................................... 36
2.8. Universal Call ID ................................................................................... 37
2.9. CTI Link Configuration ......................................................................... 37
2.10. CMS Cisco Real-Time Report ............................................................ 37
2.10.1. CMS Minimum Refresh Rate ..................................................... 38
2.10.2. Configuring the CMS Report ...................................................... 39
2.11. Avaya Configuration for CMS-less PGs ....................................... 39
2.12. ACD Notes and Restrictions.............................................................. 40
2.13. Multiple PGs ........................................................................................ 41
2.13.1. Dual PG Setup ........................................................................... 41
2.14. Maintaining Your Configuration ........................................................ 43
2.15. Configuring High Availability CMS ................................................... 43
3. Unified ICM Software Configuration ..................................... 45
3.1. Peripheral Configuration ..................................................................... 46
3.1.1. Peripheral Skill Group Mask ...................................................... 46
3.1.2. Peripheral Call Control Variable Map ......................................... 47
3.1.3. Peripheral Configuration Parameters ......................................... 48
3.2. Peripheral Targets ................................................................................ 54
3.2.1. Configuring VDN and Hunt Group
Extensions as Peripheral Targets .............................................. 54
3.3. Peripheral Monitor Table ..................................................................... 55
3.3.1. Monitoring Stations .................................................................... 55
3.3.2. VDN Timed ACW Settings ......................................................... 55
3.3.3. Configuring the Return Destination
VDN on Unified ICM ................................................................... 57
3.4. PIM Configuration ................................................................................. 59
3.5. Trunk Groups ........................................................................................ 61
3.6. Trunks .................................................................................................... 62
3.7. Services ................................................................................................. 62
3.8. Skill Groups........................................................................................... 63
3.8.1. Skill Group Subgroups ............................................................... 64
3.8.2. Using Skill Group Priorities without
Configuring Sub-skill Groups ..................................................... 65
3.8.3. Available Hold Off Delay ............................................................ 69
Contents v

v
3.9. Service-to-Skill Group Mappings ........................................................ 69
3.10. Agents .................................................................................................. 70
3.10.1. Agent States ............................................................................... 70
3.11. Skill Group Members .......................................................................... 71
3.12. Translation Routes ............................................................................. 72
3.13. Routes .................................................................................................. 72
3.14. Routing Client ..................................................................................... 72
3.15. Unified ICM Configuration for CMS-less PGs .............................. 73
3.16. Maintaining Your Configuration ........................................................ 73
3.17. Registry Keys ...................................................................................... 73
4. Post-Routing ........................................................................... 76
4.1. Route Request ...................................................................................... 77
4.1.1. Route Request Elements ........................................................... 77
4.1.2. Route Request Peripheral Variable Usage ................................ 77
4.1.3. Call Control Variable Map .......................................................... 78
4.2. Route Select .......................................................................................... 80
4.2.1. Route Select Message ............................................................... 80
4.2.2. Restrictions on Digit Collection .................................................. 81
4.2.3. Route Select Peripheral Variable Usage ................................... 81
4.2.4. Digit Collection/Dial Ahead ........................................................ 81
4.2.5. Trunk Access Code .................................................................... 82
4.2.6. User-User Information ................................................................ 82
4.2.7. Label Syntax .............................................................................. 83
5. Unified ICM Web Interaction .................................................. 87
5.1. Monitoring VDNs Used for Phantom Calls ......................................... 88
5.2. VDNs Used for Predictive Calls .......................................................... 88
5.3. Configuring Multiple CMB Call Types ................................................ 89
Index .................................................................................... Index-1

vi Contents

Tables
Table 1: Avaya RequirementsWith CMS ......................................................... 16
Table 2: Avaya ACD RequirementsCMS-less .............................................. 17
Table 3: Unified ICM Compatibility for Maximum Agent and
BHCA ................................................................................................. 35
Table 4: Avaya-to-Unified ICM Skill Group Mapping ........................................... 63
Table 5: Impact on Unified ICM Reports .............................................................. 67
Table 6: ACD-to-Unified ICM Agent Mapping ...................................................... 70
Table 7: Agent State Definitions ......................................................................... 70
Table 8: Unified ICM-Avaya Agent State Derivation ........................................... 71
Table 9: MaxActiveAssocPerCTILink Values...................................................... 74
Table 10: Route Request Peripheral Variable Map ............................................ 79
Table 11: Route Select Peripheral Variable Map ................................................ 81
Table 12: Label Identifiers and Capabilities ........................................................ 83
Figures
Figure 1: Avaya ACD Interface ........................................................................... 13
Figure 2: CTI Link Setup Screen .......................................................................... 21
Figure 3: Add CTI Client IP Screen ...................................................................... 22
Figure 4: Change or Display a CTI Link (Tab 1) .................................................. 23
Figure 5: Change or Display a CTI Link (Tab 2) .................................................. 23
Figure 6: Defining Agent Hunt Groups ................................................................. 25
Figure 7: Modifying Agent LoginID ....................................................................... 26
Figure 8: Station Record for Phantom Lines ........................................................ 27
Figure 9: Creating Call Vector .............................................................................. 27
Figure 10: Example: Phantom Call ...................................................................... 28
Figure 11: Example: Predictive Call ..................................................................... 29
Figure 12: GUI for Vector Directory Number ........................................................ 29
Figure 13: Return Destination: 3606 .................................................................... 33
Figure 14: Return Destination: 3001 .................................................................... 34
Figure 15: Dual PG Overview .............................................................................. 41
Figure 16: Set Sub Group Mask Window ............................................................ 46
Figure 17: Call Control Variable Map Field ......................................................... 47
Figure 18: Configuration Parameters Field ......................................................... 48
Figure 19: Agent Auto-Configuration .................................................................. 52
Figure 20: Enable agent reporting ...................................................................... 53
Figure 21: Peripheral Monitor Param Field ......................................................... 56
Figure 22: Return Destination feature on ICM ..................................................... 57
Figure 23: Return Destination Logs ..................................................................... 58
Figure 24: Peripheral Gateway Component Properties ....................................... 59
Figure 25: Avaya ECS PIM Configuration ........................................................... 60
Figure 26: Peripheral Number and Service Fields .............................................. 63
Figure 27: Skill Group Configuration Fields ........................................................ 64
Figure 28: Peripheral Configuration .................................................................... 66
Figure 29: Skill Group Configuration ................................................................... 67
Figure 30: Router Scripts .................................................................................... 68
Figure 31: Configuration Parameters Field ......................................................... 72
Figure 32: Call Control Variable Map Field ......................................................... 78
Figure 33: Peripheral Monitor Configuration ........................................................ 88
Figure 34: Peripheral Target Configuration .......................................................... 89

vii
Preface
Purpose
This document contains the specific information you need to maintain an
Avaya Peripheral Gateway (PG) in a Unified Intelligent Contact
Management (Unified ICM) environment. It is intended to be used as the
Avaya-specific companion to the Unified ICM software documentation set.
While the other Unified ICM documents cover general topics such as
configuring an overall Unified ICM system and writing scripts to route
contact center requests, the ACD Supplement for Avaya provides specific
information on configuring an Avaya PG and making any necessary
adjustments to the Avaya ACD configuration.
Audience
This document is intended for Unified ICM system managers. The reader
should understand Unified ICM functions as described in the following
documents:
Installation and Configuration Guide for Cisco Unified Contact Center
Enterprise
Installation and Configuration Guide for Cisco Unified Contact Center
Enterprise
Scripting and Media Routing Guide for Cisco Unified ICM/Contact
Center Enterprise & Hosted
The reader should also have specific knowledge about the Avaya and CMS
systems.
Organization
Chapter 1, Overview
Provides an overview of the ACD interface along with the hardware and
software requirements for both CMS and non-CMS environments.
Chapter 2, ACD Configuration
Describes items in the Avaya configuration that must be checked to
ensure compatibility with the system software.
Chapter 3, Unified ICM Software Configuration
Describes the relationships between the Avaya database objects and the
Unified ICM database objects. This chapter also describes Avaya-
specific settings that must be confirmed in Unified ICM configuration.
viii Overview

Chapter 4, Post-Routing
Describes the features of Unified ICM Post-Routing available with the
Avaya PG.
Chapter 5, Unified ICM Web Interaction
Describes the special configuration issues related to Unified ICM Web
Option configuration and Avaya.
Typographic Conventions
This manual uses the following conventions:
Boldface type is used for emphasis.
For example: Real-time information is not stored in the central database.
Italic type indicates one of the following:
A newly introduced term; for example:
A skill group is a collection of agents who share similar skills.
A generic syntax item that you must replace with a specific value;
for example:
IF (condition, true-value, false-value)
A title of a publication; for example:
For more information, see the Database Schema Guide for Cisco
Unified ICM/Contact Center Enterprise & Hosted.
Sans serif type with small caps is used to represent keys on your
keyboard; for example:
Press the SHIFT key to select a range of items.
An arrow (>) indicates an item from a drop-down menu.
For example, the Save command from the File menu is referenced as
File > Save.
Other Publications
For more information on Unified ICM software, see the following documents:
Administration Guide for Cisco Unified ICM/Contact Center Enterprise &
Hosted
Installation Guide for Cisco Unified ICM/Contact Center Enterprise &
Hosted
Configuration Guide for Cisco Unified ICM/Contact Center Enterprise &
Hosted
Scripting and Media Routing Guide for Cisco Unified ICM/Contact Center
Enterprise & Hosted
For information on Cisco Network Applications Manager (NAM), see the
following documents:
Product Description Guide for Cisco Unified ICM Hosted
Multiple-NAM Setup and Configuration Guide for Cisco Unified ICM
Hosted
Avaya ACD Interface Requirements ix

ix
Obtaining Documentation and Submitting a Service
Request
For information on obtaining documentation, submitting a service request, and
gathering additional information, see the monthly Whats New in Cisco Product
Documentation, which also lists all new and revised Cisco technical
documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the Whats New in Cisco Product Documentation as a Really
Simple Syndication (RSS) feed and set content to be delivered directly to your
desktop using a reader application. The RSS feeds are a free service and Cisco
currently supports RSS Version 2.0.
Documentation Feedback
You can provide comments about this document by sending email to the
following address:
[email protected]
We appreciate your comments.
11
1. Overview
The Cisco Unified Intelligent Contact Management (Unified ICM) Peripheral
Gateway (PG) supports Avaya ACD using CVLAN Service, running on Avaya
Application Enablement Services (AES). This is the preferred method to
interface to the Avaya ACD.
CVLAN is an Avaya software option that allows the Unified ICM PG to
communicate with the Avaya ACD. CVLAN provides the PG with real-time call
events and allows the PG to query the ECS/MultiVantage/Avaya about splits,
trunk groups, and agents. For more information about the supported ACD
switches, see Cisco ICM Software Supported Switches (ACDs) available at
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_technical_refe
rence_list.html.
CVLAN also allows the PG to perform Post-Routing, station monitoring, and
third-party call control. The CVLAN software can be purchased from Avaya.
The Call Management System (CMS) is the Avaya ACD Management
Information System (MIS). It provides the PG with real-time agent state data for
non-station-monitored agents.
This chapter describes the options for connecting the Avaya ACD to the Unified
ICM PG. To work with the system software, the Avaya ACD must meet several
hardware and software requirements. This chapter lists the requirements for both
CMS and non-CMS environments.
Note: Avaya ACD is used across this document to represent the different names used
by Avaya for their platform, such as Avaya Aura Communication Manager,
Avaya Communication Manager, MultiVantage, and Definity.
12 Overview

1.1. Avaya ACD Interface Requirements
A basic, simplexed Unified ICM PG has the following interface requirements:
You can have at least one CTI link on the Avaya ACD. Up to eight CTI
links can be supported for higher call loads.
If CMS is used, the PG requires one Ethernet connection to the CMS system
that is connected to the Avaya ACD.
If CMS is used, the PG requires a Unified ICM Real-Time Adherence
(RTA) custom report. This report is developed and provided by Avaya for
the Unified ICM system.
Note: A configuration without the CMS may be possible, subject to the
restrictions listed in Avaya ACD CMS-less Interface, later in this
chapter. If a CMS-less solution is possible, all references to CMS
requirements in this document do not apply.
1.1.1. Avaya ACD with CVLAN Service running on Avaya AES
The AES interface allows the PG and Avaya ACD to communicate directly. In
this configuration, CVLAN Service is running on Avaya AES software. The PG
connects directly to the Avaya ACD via an Ethernet LAN. The PG acts as a
client while the Avaya ACD acts as the server. An adjunct processor platform is
not required in this configuration. Figure 1 shows an example of AES interface
with Avaya ACD.
Avaya ACD Interface Requirements 13

13

Figure 1: Avaya ACD Interface
The CMS, if used, connects to Unified ICM visible LAN via a single Ethernet
connection. A Cisco CMS custom report is installed on the CMS platform (one
for each Peripheral Interface Manager).
Figure 1 shows a two-ACD site. Some sites may have a single ACD only.
Avaya and Cisco strongly recommend that the PG and Avaya ACD be on the
same LAN.
See also: For specifics on AES Server installation and SCO UNIX patch requirements, see
the Configuring AES section.
1.1.2. Call Management System (CMS)
The Avaya CMS provides snapshots of the real-time agent login/logout and non-
ACD related agent state data to the PG via the CMS Ethernet connection
1
. In
configurations that use CMS, a custom report is required to ensure that real-time
call and agent data is available to the system software.
CMS Report Versions
Avaya has Unified ICM RTA custom reports in Expert Agent Selection (EAS)
and non-EAS versions. The Avaya CMS Professional Services Group installs
the proper Unified ICM custom report (EAS or non-EAS) on the CMS. To
support EAS, the custom report must have a major revision of at least 3 (for
example: 3.x.x).

A CMS-less version of the PG is available; however, certain restrictions apply. See

Avaya CMS-less Interface, later in this section.
14 Overview

Single- and Multiple-PIM Configurations
One custom report must be installed on the CMS for each Peripheral Interface
Manager (PIM) on the PG. A PIM is a system software module that allows
communication between a peripheral and the PG. For example, if you have one
Avaya ACD and a duplexed PG, each PG has one PIM. Therefore, the CMS
requires two custom reports. If you have two ACDs and a duplexed PG, each PG
has two PIMs. The CMS would therefore require four custom reports (two for
each PG).
Even though two CMS reports are installed in a single Avaya ACD duplexed PG
environment, only one of the CMS reports is actively providing agent state data
to the PG at any given time. In other words, only one CMS report is running at
any given time per Avaya ACD. From a resource utilization perspective on
CMS, a single CMS report (when running) is equivalent to one additional
Supervisor running a real-time report.
See also: For more information on CMS report requirements, see the CMS Cisco Real-
Time Report section.
Note: Customers who are using CMS with Unified ICM, upgrading to ICM 4.1,
and have over 1,000 agents/high call loads, may want to change certain ICM
4.1 ACD PIM default settings. Changing settings may improve agent station
visibility but can also result in a possible increase in message traffic to the
Avaya ACD, switch CPU load, and network traffic between the PG and
Central Controller (CC). Customers should work with the Cisco Content
Security and Control (CSC) to evaluate and mitigate any possible issues.
Cisco CSC should refer to internal documents on PIM registry configuration.
1.1.3. Avaya CMS-less Interface
ICM software Releases 4.1 and greater support Avaya ACD configurations that
do not use the Avaya CMS. Typically, this configuration is available only when
agent count is less than 1,000 agents. However, the suitability of a CMS-less
installation for a site may depend on a number of factors, including agent
counts, Busy Hour Call Rate (BHCR), third-party activity, post-routing, and
other Avaya CTI applications (if any).
Note: If a CMS-less solution is used, all references to CMS requirements in this
document do not apply.
In a CMS-less environment, both Unified ICM and Avaya ACD systems must
meet several additional configuration requirements:
Additional Unified ICM Software Configuration
The following changes are possible using the Configure ICM tools.
You must configure all agents in Unified ICM database.
You must map agents to skill groups in Unified ICM database. The
agent-to-skill-group mapping must match the Avaya ACD configuration. In
addition, the subgroup must correctly map to the agents priority.
You must configure monitored instruments in the Peripheral Monitor table
of Unified ICM database. Agent stations should be monitored.
You must configure Peripheral Targets in Unified ICM database for all
Vector Directory Numbers (VDNs) through which monitored calls flow.
Hardware and Software Requirements 15

15
Additional Avaya Requirements
Third-Party Domain Control (3PDC) must be provided for all skill groups
that will be monitored or routed to by the system software. If a skill group is
not monitored through 3PDC, no agents will be logged in to that skill group.
3PDC allows the PG to track login and logout events for the skill group.
Avaya currently restricts one application to 3PDC of a skill group.
You must enable Event Minimization for the CTI links used by the PG.
For optimal performance, external applications that alter agent state on the
Avaya ACD ECS should use the Enterprise CTI interface. (Contact your
Cisco Unified ICM representative for complete and up-to-date information
on recommended configurations.)
1.1.4. Busy Hour Call Rates for Ethernet CTI Link
Each Avaya Ethernet CTI link can support a BHCR of approximately 32,000 in
normal use by the PG (That is without Post-Routing or third-party call control).
This value is an approximation and can be affected by the number of agents,
anticipated peak busy hour call rate, average number of CTI events/calls, and the
number of splits, trunk groups, and VDNs. Cisco recommends provisioning a
dedicated Ethernet CTI link for Unified ICM application.
See also: For more information on Ethernet BHCRs, see the Ethernet Busy Hour Call
Rates section.
1.2. Hardware and Software Requirements
In order to work with Unified ICM software, the Avaya ACD must meet the
hardware and software requirements listed in Table 1. (Note that this table
shows the requirements for a configuration that uses CMS.)
Table 2 shows the requirements for the CMS-less configuration.
16 Overview

Table 1: Avaya RequirementsWith CMS
Releases Supported Avaya ACD

CVLAN
For specific release information on Avaya ACD and
CVLAN, see the Cisco ICM Software Supported
Switches (ACD) document available at
http://www.cisco.com/en/US/products/sw/custc
osw/ps1001/prod_technical_reference_list.html.
Features Required Call Management System (CMS)
For specific release information for CMS, see the
Cisco ICM Software Supported Switches (ACD)
matrix available at
Call Vectoring
CTI Monitoring
CTI Host-Based Routing (only for systems using
Unified ICM Post-Routing)
Cisco Unified ICM real-time adherence custom
report (developed and provided by Avaya for Cisco).
The CMS requires one report for each PIM in
service on the PG.
Performance CMS minimum refresh rate: 3 seconds

Supported Unified ICM Software Features 17

17
Table 2: Avaya ACD RequirementsCMS-less
Releases Supported
Avaya ACD
CVLAN
For specific release information for Avaya
and CVLAN, see the Cisco ICM Software
Supported Switches (ACD) matrix available
at
Features Required
Call Vectoring

CTI Monitoring

CTI Host-Based Routing (only for systems
using Unified ICM Post-Routing)

Note: Please Contact Avaya for information regarding the following:
Latest hardware and software requirements for AES Server
Avaya ACD to AES Server upgrade
1.3. Supported Unified ICM Software Features
The Avaya PG supports the following Unified ICM software features:
Pre-Routing
Post-Routing
Enterprise CTI (includes third-party call control)
Agent reporting
Duplexed PG implementation
Unified ICM Web Option
Note:
The Avaya PG does not support Unified ICM integration with the Avaya
ProLogix System.
PIM supports a maximum of eight CTI links per CVLAN and a
maximum of two CVLANs.

18 Overview

19
2. ACD Configuration
No changes are required to the actual Avaya ACD configuration beyond the
changes mentioned in the Chapter 1: Avaya ACD Interface Requirements.
However, some ACD-specific settings must be confirmed. This chapter
describes these settings and provides guidelines that will help you maintain your
Avaya ACD and Unified ICM configurations.
20 ACD Configuration

2.1. Monitored VDNs and Inbound ACD Calls
While it is important that all VDNS involved in ICM call flow are monitored to
ensure that there are no stale calls, all inbound ACD calls are initially handled
by a monitored VDN. A monitored VDN is equivalent to a configured Unified
ICM Peripheral Target. For example, do not specify a Hunt Group Extension as
the destination for inbound ACD calls. Hunt Groups that are vector-controlled
(which is true for all skill groups in an EAS environment) cannot be monitored
for calls.
The inability to monitor vector-controlled hunt groups is a restriction imposed
by Avaya. An unmonitored call that reaches a Hunt Group or Agent cannot be
tracked and will not be accounted for properly in Unified ICM contact or agent
statistics.
Important: It is extremely important that all VDNs to be monitored are properly configured
as Peripheral Targets in the Unified ICM database.
2.2. Monitored Splits on CMS
The Avaya Hunt Group configuration screen for each monitored split on CMS
must have its Measured field set to either both or external, in order for the
CMS to receive Hunt Group (split) data.
2.3. Terminal Endpoint Identifier (TEI) Values
When you configure the Avaya ACD, the TEI value for an Avaya LAN or
Avaya ACD should be 1.
2.4. Configuring AES
Application Enablement Services (AES) software runs on an external server that
communicates to Avaya Aura Communication Manager (or Avaya ACD) via
TCP/IP, and exposes a set of APIs that allows external applications like Cisco
ICM to perform third-party call control and receive event notifications. The ICM
PG uses the CVLAN API, which is a client/service software.
To best understand the configuration of the AES switch, begin with the Avaya
documentation that shipped with your switch. The information provided here is
meant to supplement but not replace the Avaya documentation. We provide a
limited amount of information to help you configure the switch to work with
Cisco Media Blender.
The following tasks are described:
Setting Up the CV/LAN Links
Setting Up the CTI Station
Setting Up Agents and Hunt Group
Creating a Station Record for Phantom Lines
Setting Up Call Routing
Configuring AES 21

21
2.4.1. Setting Up the CTI Links on AES Server
This section describes how to set up the CTI links on an AES Server.
To establish the link:
1. Open the AES OAM home page.
2. Choose Administration > CTI Link Admin > CVLAN Links.
3. On the CVLAN Link administration screen, click Add Link and perform
the following:
Select the Signal
Uncheck the Proprietary check box
Select the Switch Connection
Select the Switch CTI Link Number
Select the CTI link version
Check the Heartbeat check box
4. Click Apply Changes.

Figure 2: CTI Link Setup Screen
Adding CTI Client IP for a CTI Link
1. Open the AES OAM home page.
2. Choose Administration > CTI Link Admin > CVLAN Links.
3. Select the CVLAN link for which the client IP needs to be added and click
Edit Client.
4. Enter the IP address and click Add Client. (In case of Cisco Media Blender
[CMB] application, use the CMB machine address.)

Figure 3: Add CTI Client IP Screen
2.4.2. Changing or Displaying a CTI Link
This section describes how to change or display a CTI link to the CMB.
To change or display CTI-link (1-8):
1. Log in to the Avaya system.
2. From the drop-down menu, select:
change cti-link <Link No>: To change the number of CTI links.
display cti-link<Link No>: To display the number of CTI links.
Configuring AES 23

23

Figure 4: Change or Display a CTI Link (Tab 1)
3. Press Enter.

Figure 5: Change or Display a CTI Link (Tab 2)
2.4.3. Setting Up Hunt Groups/Skill Groups
On the Avaya switch, a hunt group is a group of extensions to which similar
calls are routed. A hunt group might include all agents who have a particular
skill (for example, the ability to speak Spanish) or all agents who cover a
geographical territory (for example, Boston sales). A hunt group is sometimes
referred to as a skill group.
Note: The Avaya PG supports extensions of up to seven digits the agent can login to
a Softphone that has an extension up to seven digits. This seven-digit support

applies to VDNs, Hunt Groups and Agent Login IDs. ICM 5.0 users must install
Service Release 7 (SR7), and ICM 6.0 users, SR1, for seven-digit support. For
earlier ICM releases, the Avaya PG limits support to five digit.
Configuring AES 25

25
In order to use a six-digit, or a seven-digit extension, the config PIM registry
EnableSevenDigitExtension must be set to 1 in following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,
Inc.\ICM\<cus01>\<PGXX>\PG\CurrentVersion\PIMS\pim1\ATTData\Config\
To ensure proper call routing to agents having access to the Cisco Unified Web
Interaction Manager (Unified WIM), establish a hunt group for these agents.
You can also use existing hunt groups as long as you establish vectors to ensure
that calls are routed to specific agents. If you use existing hunt groups, be sure
that there is no other CTI application monitoring that group. To see a list of
existing hunt groups, enter the command list hunt-group.
Some ACD systems provide a feature called EAS. For a variety of reasons, you
might want certain agents to handle specific types of calls. For example, you
might want only your most experienced agents to handle your most important
customers. You might have multilingual agents who can serve callers in a
variety of languages. EAS allows you to classify agents according to their
specific skills and then to rank them by ability or experience within each skill.
Avaya uses these classifications to match each call with the best available agent.
2.4.4. Defining a Hunt Group/Skill Group for Agents
To set up agents you must define a hunt group by completing the following
steps:
1. Enter the command add hunt-group next and press Return. (You can also
enter add hunt-group xxx, where xxx is the hunt group number.) The first
Hunt Group screen appears.

Figure 6: Defining Agent Hunt Groups
2. Complete screens 1 through 2 of the hunt group record as described in the
Avaya documentation.
3. Press Enter. The hunt group is successfully created.

2.4.5. Modifying the Agent Login ID
For each agent using Unified WIM, add the Unified WIM hunt group to the
Agent login ID form.
To modify the Agent login ID.
1. Enter the command change agent-loginID <agent login ID number>. The
Agent Login ID screen appears.

Figure 7: Modifying Agent LoginID
2. If this is a new agent, type the hunt group number that indicates Unified
WIM agents in the Direct Agent Skill field. If this is an existing agent, add
the hunt group that indicates Unified WIM agents in the SN (Skill Number)
field in the table at the bottom of the screen.
3. Complete the remaining fields as described in the Avaya documentation.
2.4.6. Creating a Station Record for Phantom Lines
If your site uses any of the phantom line CTI strategies to handle call flows, set
up a pool of phantom lines and create a station record for each phantom line. For
information on how to create a pool of phantom lines and determine your
phantom line requirements, see the Cisco Media Blender Administration Guide.
Phantom lines are phone lines that are set aside for use by CMB to make phone
calls. The phone lines you use do not need to have actual phones; you must
configure them as you would an agent in your contact center. If you have the
AES switch Version 6.3 or later, you can set up phantom lines without hardware
using the Administration Without Hardware (AWOH) feature. Earlier versions
required actual phones for your phantom lines.
To create a station record for a phantom line:
1. Enter the command add station next. You can also enter add station xxx,
where xxx is the actual station number you want to assign to the phantom
line. The first station screen appears.
Configuring AES 27

27

Figure 8: Station Record for Phantom Lines
2. Enter x in the Port field. This configures the phantom line without
hardware.
3. Complete all station screens to configure each phantom line. See the Avaya
documentation for information on completing these screens.
2.4.7. Setting Up Call Routing
After you have set up your Unified WIM agents and the phantom lines, ensure
that the Avaya switch routes calls to them correctly by:
Writing a vector to route calls
Creating a VDN to access the vector
Write a Vector to Route Calls
A vector is a set of instructions the switch follows to ensure the right call gets to
the right agent. Whether you use predictive or phantom CTI strategies, you must
write a vector that routes appropriate incoming calls to a Unified WIM agent
hunt group. You must write a vector for each group to which you want to route
calls, and you need the hunt group number established for Unified WIM agents
when setting up a vector to route calls to those agents.
To create a vector:
1. Enter the command change vector xx (where xx is the vector number) and
press Return. The Call Vector form appears.
Figure 9: Creating Call Vector
2. Complete the Call Vector screens 1 through 3. Instructions for completing
these screens are provided in the Avaya documentation.

If you are using both predictive and phantom CTI strategies, create a separate
vector for each strategy.
Note: When creating vectors for phantom lines, avoid using prompts or
announcements. The caller is not actually on the call when the phantom line
calls the vector.
Example of a Vector for a Phantom Call
Following is an example of a phantom call vector. No announcements are
played. If no agents are available, the vector disconnects the phone call. CMB
then serves an error page informing the caller that no agents are available.

Figure 10: Example: Phantom Call
Configuring AES 29

29
Example of a Vector for a Predictive Call
Following is an example of a predictive call vector. Note that this vector plays
an announcement if no agents are available.

Figure 11: Example: Predictive Call
2.4.8. Create a Vector Directory Number
After setting up a vector for Unified WIM calls, set up Vector Directory
Numbers (VDNs) to direct incoming calls to that vector. You can create several
VDNs that refer to the same vector, ensuring that calls from a variety of sources
can be routed to the same skill group.
To create a VDN, complete the following steps:
1. Enter the command add VDN xxxx (where xxxx indicates the VDN). The
Vector Directory Number screen appears.

Figure 12: GUI for Vector Directory Number

2. Complete this form based on the instructions in the Avaya documentation.
Make sure you enter the number of the vectors set up for Unified WIM calls
in the Vector Number field.
Identifying Call Classes
You can set up a VDN-of-origin announcement to let the agent know the call
class if you are using multiple call classes. For instance, you can create an
announcement for chat calls so that the agent knows to start a chat session. You
can set up multiple VDNs to the same vector, each identifying an individual call
class.
Reporting
If you choose to use an existing vector, you might want to create a separate
VDN for Unified WIM calls. This enables you to create reports based on those
calls.
2.4.9. Sharing Information
Ensure proper call flow by recording and sharing the following information with
the Unified WIM administrator and the CMB administrator:
The Unified WIM administrator needs switch configuration information in
order to set up agents on Unified WIM.
The Media Blender administrator needs values for the CMB property files.
Unified WIM Administrator
The switch administrator sets up agents on the ACD and the Unified WIM
administrator sets up agents on the Unified WIM Administration desktop. The
Unified WIM administrator should enter the Voice Agent ID when setting up an
agent. This Voice Agent ID should be the same as the logical ID (agent ID) used
on the ACD. For more information, see the Cisco Unified Web and E-Mail
Interaction Manager, Administration Console User Guide - for Unified Contact
Center Enterprise, Hosted and ICM available at:
http://www.cisco.com/en/US/products/ps7233/prod_installation_guides_list.htm
l.
For the basic CMB configuration, agents must be set up in two places. The
switch administrator sets up agents on the ACD and the Unified WIM
administrator sets up agents on the Unified WIM Administration desktop using
the Agents: Create node. The Unified WIM administrator must enter the Voice
Agent ID when setting up an agent. This Voice Agent ID must be the same as
the logical ID (agent ID) used on the ACD.
If agents must be able to log in to the ACD and Unified WIM at the same, time,
blended login capability must be configured on Unified WIM. How the Unified
WIM administrator sets up blended login depends on whether the agent will
frequently change phones. The Unified WIM administrator might also need the
terminal ID (the identifier of the phone on the ACD system) and the ACD
password for each agent.
Media Blender Administrator
The CMB administrator is responsible for creating a phantom pool file,
phantoms.properties, which lists the phantom physical ID on the ACD or the
agents permanent extension with the phantom line type (D is the only phantom
Configuring AES 31

31
line type because CMB supports only digital line types). To set up phantom
agents, the administrator must also configure two other files:
The phantomagents.properties file, which maps a phantom agents logical
ID to a specific physical phone ID
The phantompasswords.properties file, which maps a phantom agents
logical ID to a specific phantom password
See the Cisco Media Blender Administration Guide for details about the
property files.
For AES, the administrator needs the station IDs for the phantom phones, as
well as the link, host-name, and hunt group extension number to configure the
ACD.asai.properties file. The Avaya administrator also configures the
skills.properties file, which maps routing addresses to ACD routing logic. For
example, the AES, the administrator needs the VDN or the hunt group extension
number.
2.4.10. Recording Avaya ACD Information
The following tables describe the information you need to record when
configuring the Avaya switch. Please share the information with the Unified
WIM and CMB administrators.
For the Unified WIM Administrator
Collect the information in the following table for each agent you configure on
the switch and share this information with the Unified WIM administrator:

Agent Name Logical ID Password Station ID

For the CMB Administrator
The CMB administrator needs four types of information:
Phantom phone
CTI link
Vector Directory Number
Hunt Group Extension

Phantom Phone Information
The CMB administrator needs the Station IDs in order to configure the
phantom.properties file and set up phantom phones. Record the information in
the following table and share this information with the CMB administrator.

Station ID

2.5. Configuring Return Destination VDN on Avaya Switch
The Return Destination automatically redirects a call from one VDN to another
VDN for continuous call processing, after an agent disconnects the call.
If the call flow involves two post-route VDNs, the call variables are preserved
from the first route request to the second route request when call gets
automatically redirected from a post-route VDN to another post-route VDN for
continued call processing (after an agent disconnects from the call). (This is
according to the return destination feature enabled on Avaya ACD.)
If the call flow involves a first post-route VDN and then a non post-route VDN
after return destination, the call variables are still preserved from the first call
(post-route request) to the second call after return destination.
After return destination, the last agent also has the call variables which were set
in the first call prior to return destination.
The Avaya PIM detects whether the return destination is configured on a VDN,
by verifying the parameter string of that VDN in the Peripheral Monitor tab of
the PG Explorer. PIM then sends a NEW_TRASACTION_IND" to OPC,
allowing the OPC to preserve the call variables in the second route select.
The Return Destination can be configured on the Avaya Switch. The following
example explains the configuration of this feature:
1. Click Tab 1 on the VECTOR DIRECTORY NUMBER screen and set the
following field:
a. Allow VDN Override: Set this field as y.
Here, VDN 3606 is the return destination VDN.
Configuring Return Destination VDN on Avaya Switch 33

33

Figure 13: Return Destination: 3606

2. Click Tab 2 on the VECTOR DIRECTORY NUMBER screen to set the
return destination VDN for 3606. Set the Return Destination field as 3001.
This value is configured as return destination VDN for 3606. When an agent
on VDN 3606 drops the call, it is automatically redirected to VDN 3001.

Figure 14: Return Destination: 3001
To configure Return Destination VDN on Unified ICM, see the section
Configuring the Return Destination on Unified ICM.
See the section ACD Notes and Restrictions for known caveats for Return
Destination VDN.
2.6. Ethernet Busy Hour Call Rates
Each Avaya Ethernet CTI link can support a BHCR of approximately 32,000 in
normal use by the PG (that is, without Post-Routing or third-party call control).
This value is an approximation and may be affected by the number of agents,
anticipated peak busy hour call rate, average number of CTI events/calls, and the
number of splits, trunk groups, and VDNs. Cisco recommends provisioning a
dedicated Ethernet CTI link for Unified ICM application.
2.6.1. Post-Routing, Station Monitoring, Third-Party Call Control
If Post-Routing, station monitoring, or third-party call control is performed on
the same Ethernet CTI link, the link supports up to 20,000 BHCR due to
additional message traffic. Depending on your configuration, Cisco may
recommend provisioning an additional Ethernet CTI link to be used exclusively
for Post-Routing, station monitoring, or third-party call control.
An Ethernet CTI link dedicated exclusively to Post-Routing (that is, no event
monitoring) can handle approximately 64,000 BHCR. Calculating throughputs
for third-party use is dependent upon the number of stations involved and
anticipated usage. In general, third-party usage on the CTI link will use some of
the CTI bandwidth.
2.6.2. Active Association Limit
Active associations are used for all requests made of the switch. Some of the
requests made of the switch remain open for an indefinite period of time (for
example, event notification requests, monitoring VDNs). Other requests end
Ethernet Busy Hour Call Rates 35

35
when the switch returns the response (e.g., value query for time-of-day). The
indefinite requests include VDN event monitoring, station monitoring, and skill
group monitoring.
Set the Registries for MDS bufferlimit to 16,000 (decimal) in the following
paths:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cus01>\<PG1A>\MDS\CurrentVersi
on\Clients\pim1
on\Clients\opc
on\Clients\pgag
on\Process

Set the dynamic PIM registry BriMaxOutstandingMessages to 100 (decimal)
in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cus01>\<PG1A>\PG\CurrentVersio
n\PIMS\pim1\ATTData\Dynamic
ASAI_TEST utility
ASAI_TEST is a utility that allows you to check the connectivity between
Unified ICM
1
PG and the Avaya ACD (Avaya ACD can include either Avaya
ACD card or AES Server).
Before running the ASAI_TEST, ensure the IP connectivity between the PG and
the Avaya ACD card. To do so, initiate a ping test from the PG to the Avaya
ACD card. If the ping test passes, you can proceed with the ASAI_TEST.
To run ASAI_TEST, use this command syntax:
<Directory>:\icr\bin>asai_test
usage: asai_test [-m hostname/IP address] node_id
Note: The node_id is also referred to as the CTI link number. The maximum number
of CTI links can be 8.
2.6.3. Maximum Agent and BHCA
Unified ICM software (CC, PG, CTI server) currently supports 3000 Agents and
60000 BHCA.
Table 3: Unified ICM Compatibility for Maximum Agent and BHCA
Hardware, Software, and
Tools
Software Component and Version
Unified ICM software 5.0 SR11, 6.0 and 7.0
ACD Switch Avaya 3.0 with CMS RTA 5.0.5 Std
PG, CTI Server For complete and current information on the PG Server

1
The ASAI_TEST utility works on Cisco ICM 4.6.2 and later.

Hardware, Software, and
Tools
Software Component and Version
Configuration Configuration, see the Hardware & System Software
Specification (Bill of Materials) for Cisco Unified
ICM/Contact Center Enterprise & Hosted (for all ICM
versions) available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/
products_user_guide_list.html.

To support such configuration, set the Registries in the following paths for MDS
bufferlimit" => to 0x8000 (32768 decimal):
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cus01>\<PG1A>\MDS\CurrentVer
sion\Clients\pim1
on\Clients\opc
on\Process

To support such configuration, set the Registries in the following paths for MDS
bufferlimit" => to 0x40000 (262144 decimal):
on\Clients\pgag
Set the dynamic PIM registry BriMaxOutstandingMessages" to 100 (decimal)
in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cus01>\<PG1A>\PG\CurrentVersio
n\PIMS\pim1\ATTData\Dynamic
2.7. Call Handling Methods to Avoid
Following are the call handling methods you need to avoid:
1. Avoid setting up station coverage paths where all internal calls
1
are marked
to go to coverage.
2. Avoid having agents transfer calls directly to other agent stations or to other
agent IDs. Instead, the calls can be transferred to a hunt group (or split). The
calls can also be transferred to a VDN to ensure proper call monitoring.

1
Normally, an internal call is a call that is on-switch. An internal call may or may not
be related to an ACD call. However, in the case of an Avaya PIM, an internal call can
be defined as any on-switch or off-switch call that is non-ACD call related. In the
case of an Avaya PIM, depending on the telephony protocols used, there may be
conditions where the PIM does not have sufficient information to determine whether an
outbound call is off-switch or not, while in AUX mode. However on the switch side,
because the switch has all the relevant call information, it reports call statistics
accurately. To avoid such inconsistent reporting between the PIM and the switch, the
Avaya PIM treats the non-ACD call=related on-switch or off-switch calls as internal
calls.
CMS Cisco Real-Time Report 37

37
2.8. Universal Call ID
If the Avaya Universal Call ID (UCID) is desired, the field Send UCID to
ASAI should be set to Yes. You can do this through the Feature-Related
System Parameters form on the Avaya.

Starting with ICM 7.5(9), the Avaya PIM is enhanced to use UCID information
from the Avaya Switch to clean up old calls in the Avaya PIM. To enable the
UCID feature on the Avaya Switch you must change the following system-
parameters features:
Create Universal Call ID(UCID) ? y
UCID Network Node ID ? <any value_unique to a switch>
Send UCID to ASAI ? y
2.9. CTI Link Configuration
CTI link configuration should be set up to have Event Minimization set to
Yes. This is especially important if you are using third-party functionality.
To set Event Minimization to Yes:
1. Stop the PG.
2. Busy-out and release the CTI link. This will activate this CTI link attribute.
3. Restart the PG.
When Event Minimization is enabled, the Unified ICM PG CTI links must be
dedicated to the PG (that is, no other applications should be using those CTI
links). In a duplexed environment, both PG sides can use the same CTI links.
2.10. CMS Cisco Real-Time Report
The guidelines in this chapter are intended for Avaya installers of the CMS
Cisco RTA report:
Skillnums argument. The CMS report should use the skillnums argument.
The Unified ICM PG started supporting skillnums in Unified ICM software
Release 2.5 (August, 1998). Therefore, any installation of Unified ICM
software 2.5 or later should use skillnums. This applies to all the new
installations and upgrades to ICM software 2.5 or later.
Agent login. For CMS report version 3.5 or later, the PIM will not log
agents into a skill group unless the skill group is monitored by CMS. This is
a requirement because CMS will not pass agent state data or logout events
for non-monitored skill groups. The lack of this CMS data can cause agent
count and agent state mismatches. Conversely, if the CMS report is a pre-
3.5 version, the PIM will still log agents into all groups provided in the
agent login event, but CMS will not provide logout events for the non-
monitored skill groups.
Because no logout record (or any agent state record, for that matter) is
provided by CMS for these non-monitored skills, and because the version of
the CMS report is pre-3.5, the PIM may leave agents in their last state. For
this reason, it is strongly recommended that customers use a CMS report
that is version 3.5 or later.

Note: The Avaya PG currently supports 20 skills per agent. The enhanced
RTA 5.0.5, which supports 60 skills per agent, is not supported by
Unified ICM.

Noskillnum flag. Make sure that the noskillnum flag is set to skillnums (that
is, CMS provides the list of monitored skills) in the following list of files.
Split/Skill numbers need to be in the CMS startup header provided to the
PG. The files affected are:
Startrta
testrta
skills1
skills2, and so on
These are files on the CMS machine.
Multiple CMS reports on one PIM. If multiple CMS reports are
configured for a single PIM on a PG, the CMS report must use the
timestamp argument. The timestamp argument causes the CMS report to
include a UNIX timestamp in each of the CMS records sent to the PG. The
PG requires the timestamp to properly order the incoming CMS records
from the multiple reports.
Agent-skill pairs. Cisco strongly recommends that you upgrade to the
newest CMS report if you find you need increased agent-skill pairs. The
newer CMS reports can be configured to support up to 10,000 agent-skill
pairs (default 2,400). Using this single (increased) agent-skill pair capability
should eliminate any need for using multiple CMS reports (and therefore
not require timestamps in the CMS reports).
Note: In later CMS reports, the arguments (for example, noskillnums) described
above may have changed. Therefore, Avaya installers should check for the
correct arguments to achieve the desired functionality as described above.
2.10.1. CMS Minimum Refresh Rate
The CMS report is installed to run as an administrator in order to allow a
minimum refresh rate of three seconds. You need to ensure that the refresh rate
used for the custom CMS report is allowed for an administrator CMS login. In
addition, you should administer the CMS report via the appropriate login (e.g.,
CMS). Using another login to administer the report will not work. The Avaya
Professional Services group can provide the details on which login should be
used to administer the report.
If agents are being dynamically re-skilled (logged into and out of skill groups
with some frequency), it is possible that the CMS report will not see an agent
logout/login sequence for a skill group. For example, if the agent is logged into
skill 1 and is logged out of and back into skill 1 within the CMS refresh rate
period (that is, in between CMS snapshots of data), then CMS will not see this
logout/login transition.
Dynamic re-skilling of agents is not supported by CMS when the agent is on
call That is either in Talking or Reserved state. If you re-skill an agent
using CMS, the following logs are displayed:
Avaya Configuration for CMS-less PGs 39

39
05:41:13 pg7A-pim1 Trace: AgentRecord::HashIn: CMS[0] Record:
301204 80 0 0 0 232 0 1 801326 232 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Where 80 is CMS Work mode for reserved state.
05:41:13 pg7A-pim1 Trace: AgentRecord::HashIn: CMS[0] Record:
301204 32 0 0 0 232 0 1 801326 232 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Where 32 is CMS Work mode for talking state.
Dynamic re-skilling is supported only when the agent is in Available or
AUX state. If the re-skilling is attempted for an agent who is on call, the re-
skill record is held by CMS until the agent completes the call and changes the
state to Available or AUX.
2.10.2. Configuring the CMS Report
When configuring the CMS report the following data items are required:
ACD Number. The ACD number is the Avaya ACD number as known to
the CMS system.
Refresh Rate. The refresh rate is the rate at which the report will snapshoot
the agent data and pass it on to the PG. The minimum refresh rate is 3
seconds. A typical refresh rate is 10 seconds.
Splits to Monitor. The splits to monitor are the ACD skill groups that are to
be monitored by the PG. It is mandatory to update the list of CMS monitored
splits periodically.
Avaya type. For example, Non-EAS or EAS.
PG LAN Information. This includes IP address, netmask, and hostname. It
is recommended (but not necessary) that the CMS and PG be on the same
LAN. The PG LAN information is required by the Avaya Professional
Services engineer to properly configure the CMS report so it may connect to
the PG. This normally will never be changed after the initial installation.
Important: If any of the above CMS information is changed (for example: Monitored splits
or the refresh rate), the CMS report and PG must be stopped and restarted in
order for the changes to take effect.
2.11. Avaya Configuration for CMS-less PGs
In a PG configuration that does not use CMS, additional configuration is
necessary on the Avaya.
3PDC must be provided for all skill groups that will be monitored or routed
to by the Unified ICM software. If a skill group is not monitored through
3PDC, no agents will be logged into that skill group. Third-Party Domain
Control allows the PG to track login and logout events for the skill group.
Avaya currently restricts one application to third-party domain control of a
skill group.
You must enable Event Minimization for the CTI links used by the
Peripheral Gateway.

For optimal performance, external applications that alter agent state on the
Avaya ECS should use the Enterprise CTI interface. Contact your Cisco
Unified ICM software representative for complete and up-to-date
information on recommended configurations.
2.12. ACD Notes and Restrictions
Following are the notes and restrictions applicable to Avaya:
Monitoring VDNs. It is extremely important that all VDNs to be
monitored are properly configured as Peripheral Targets in the Unified ICM
database.
CTI links and BHCC. Each CTI link can support approximately 8,000
BHCC using a BRI CTI link; approximately 32,000 BHCC on a G3r using
an Ethernet CTI link; and approximately 20,000 BHCC on a G3i or G3s
using an Ethernet CTI link. These link specifications are derived from
Avaya-provided data and are subject to change.
The Avaya PG supports Agent IDs, Agent Extensions, Hunt Group
Extensions and VDNs that start with a zero. This is supported for both CMS
and CMS-less environments.
The Avaya PG does not support Hunt Group Numbers that start with a
leading zero.
Intermittent Failure of Network Transfer. There is occasionally a timing
issue in the set of events involved in a Network Transfer and, due to this,
the NIC Call ID is not populated in the transfer call, resulting in call failure.
To avoid this problem, introduce a delay of 1 second in the Vector for the
post-route number (VDN); that is,

01 wait-time 1 secs hearing silence
02 adjunct routing link 1
Avaya ECS PIM Failure. The ECS PIM stops functioning when the AES
link on the Avaya switch sends a Busyout command.
VDN Return Destination.
The Return Destination VDN feature does not support the call
conference before agent drops the call (expecting return destination
to set in). That is, the PG will lose track of the VDN to which the
call was originally delivered and call variables are not retained post
Return Destination. However, this feature supports call transfer
before agent drops the call (expecting return destination to set in).
That is, the PG will keep track of the VDN to which the call was
originally delivered and call variables are retained post return
destination.
Return destination cannot be executed multiple times. That is,
Return Destination can occur only once for a call in Avaya.
See sections Configuring Return Destination VDN on Avaya Switch
and Configuring the Return Destination on Unified ICM for configuring
the Return Destination VDN on Avaya and Unified ICM respectively.
Multiple PGs 41

41
2.13. Multiple PGs
The Avaya ACD allows connections from multiple PGs. However, while using
such a configuration, the resources (like Stations, Agents, VDNs, Splits and any
other resources) used by each PG should be maintained as separate
configurations.
Multiple PG deployment on a single ACD can be used to split the load on the
PG or have a dedicated PG to service a business line in the contact center.
To deploy multiple PGs on a single ACD, you need to have distinct
configuration between the PGs. Section 2.13.1 describes the configuration of
two PGs on a single ACD. You can follow the same steps to to configure
multiple PGs to the same ACD.
Note: Please contact the ACD vendor for ACD-related issues or limitations on
connecting multiple PGs to a single ACD.
2.13.1. Dual PG Setup
Note: Ensure that you adhere to the requirements provided in this section while
deploying multiple PGs. The performance and functionality of the PG will be
impacted if you do not follow the requirements listed in this section.
When two PGs are deployed, ICM routing effectively sees the Avaya system
as two independent peripherals. As such, there are some specific configuration
and operational requirements that need to be put in place. The following figure
describes the overview of Dual PG setup.

Figure 15: Dual PG Overview
For the same Avaya ACD to behave as an independent peripheral to Unified
ICM, you should avoid having one skill group monitored by the two PGs. To
achieve this, you will need to determine which Avaya skill numbers will be
associated with PG1 and PG2, respectively. For example, skill groups 1-1000
and 1001-2000 would be two separate sets monitored by each instance.

When two PGs share the load of a single PG, it is recommended to have a
logical correlation between the skill numbers associated with the different PGs.
For example, the pre-paid sales skill associated with PG1 might be 500, and
the one associated with PG2, 1500 (just added the digit 1 in front). The
supervisor needs to look at a report that combines the information from the two
corresponding skills to understand the overall skill performance. After the
correlation is defined, each agent can be assigned only the skill numbers that
belong to the same PG (considering the above example, an agent must not have
skills 500 and 1502 at the same time).
Because the PGs also monitor Avaya stations, the agents associated with that PG
must log in to the stations monitored by that PG only. All stations and agent-IDs
at a given physical site need to be defined at only one PG. You can avoid having
one site with entities from two PGs. It is also recommended to assign stations
sequentially for every PG.
The VDNs (that are monitored by Unified ICM) should be independent,
regardless of whether they are used by calls when they first enter the
environment or for translation routes. The CTI links used by these VDNs
(through the vectors they point to) should also be separated; there will be CTI
links established with PG1 A and B, and with PG2 A and B. You can also define
dial-plan ranges for VDNs in each PG to make the configuration simpler (but it
is not required).
The calls within the a PG can be dialed directly using normal dial plan numbers
such as VDNs, Agent IDs, extensions, and hunt groups. Ideally, the calls should
not cut across two PGs. However, in such scenarios, the call has to be translation
routed to the target PG over trunk, which is equivalent to routing to a PG
connected to a different switch. To achieve this kind of a routing, loop back
trunks need to be provisioned on the switch and used for routing calls to dial
plan numbers of another PG.
When the call is routed from PG1 to PG2, the target PG2 will see the call as an
inbound call and the ICM reporting will reflect the same. To prevent
inappropriate agent behavior, the Avaya system can be programmed to block
incorrect call flows (COR and/or tenant settings). It is recommended to design
the system to avoid or minimize the call between the two PG groups.
Cisco mandates that trunk groups monitored by each PG be separate. If two PGs
are used to monitor the same trunk group, Unified ICM software will not be able
to understand that the feeds it gets are duplicated.
Other Avaya resources such as announcements, classes of restriction, CMS
reporting, recording, and so on, are not affected with dual PG implementation.
Note: Although two PGs can provide scalability from a Cisco Unified ICM
perspective, you should also consult Avaya about how the ACDs will handle
increased CTI traffic taking into consideration all other applications currently
used, such as recording and virtual hold. These thresholds are associated with a
large number of CTI-enabled agents in the Avaya ACDs, not with the fact that
two PGs are being used.
Configuring High Availability CMS 43

43
2.14. Maintaining Your Configuration
Accomplish the changes made to your configuration first on the Avaya/CMS,
then in the Unified ICM database. This will ensure that the PG sees the
configuration updates on the Avaya/CMS systems.
It is imperative that the Avaya, CMS, and Unified ICM database configurations
are kept synchronized (that is, up-to-date with each other). Inaccurate or
incomplete data could result in inaccurate agent and/or call data.
2.15. Configuring High Availability CMS
The high availability CMS configuration minimizes the down time in the event
of Avaya CMS failure. If you want to have such configuration in your call
center environment, configure the PGs as follows:
Duplex PG configuration: Both CMSs (CMS no.1 and CMS no.2) should
use both PGs IP addresses (that is, IP addresses of PG-A and PG-B) for
connections exactly the same as they do in a single CMS configuration.
However, at any given time, only one CMS can connect to the active PG.
The other PG is always in standby mode. So if PG-B is currently active,
PG-A will be in standby mode (and vice versa).
When running the Web Setup tool, ensure that the CMS Hostname field in
the AvayaPIM Configuration pop-up menu is blank. This allows the PIM to
accept a connection from either HA CMS server. If one HA CMS server
goes down, the other will initiate a connection to the PIM on the active PG.
Note: Irrespective of this being a High Availability CMS configuration or
not, a CMS Data Feed failure will result in a failover from one side
of a duplexed PG to the other.
Simplex PG configuration: Both CMSs should use the PGs IP address for
connection. But only one CMS can connect to the PG at any given time.
Also, be sure when running Web Setup tool that the CMS Hostname field in
the AvayaPIM Configuration pop-up menu is blank. This allows the PIM to
accept a connection from any one CMS server. If one CMS server goes
down, the other should initiate a connection to the PIM.
Note: The HA CMS server going down will lead to CMS Data Feed
failure; this will result in a brief outage on a simplex PG.


45

3. Unified ICM Software
Configuration
In order to properly configure and maintain the Unified ICM database, you need
to understand the relationships between the Avaya database objects and the
Unified ICM database objects. Some Unified ICM objects (for example, Unified
ICM Services) do not correspond directly to a specific object on the Avaya.
Other Unified ICM objects, such as trunks, correspond directly to objects on the
ECS/MultiVantage/Avaya.
By understanding the relationships between the database objects of the Avaya
and Unified ICM systems, it will be easier to keep the Avaya
ECS/MultiVantage, CMS, and Unified ICM databases synchronized (that is, up-
to-date with each other).
This chapter describes how objects map between the Avaya and Unified ICM
software. It also provides Avaya-specific information that may assist you in
configuring the PG through the Configuration Manager tools.
See also: For detailed information on the Configuration Manager tool user interface, see
the Configuration Guide for Cisco Unified ICM/Contact Center Enterprise and
Hosted available at:
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/products_installatio
n_and_configuration_guides_list.html.
46 Unified ICM Software Configuration

3.1. Peripheral Configuration
In Unified ICM terms, the Avaya itself corresponds to a peripheral. Unified ICM
software treats all contact center devices (e.g., ACDs, PBXs, IVR systems) as
peripherals.
No special peripheral configuration parameters are required for Unified ICM
software. However, there are certain items within the Unified ICM configuration
that you may want to check.
3.1.1. Peripheral Skill Group Mask
The Peripheral (default) Skill Group Mask, which is available from the PG
Explorer tool, should be checked and set appropriately. The Skill Group Mask is
used when configuring all skill groups for the peripheral.
If your peripheral is an EAS type, ensure that all appropriate check boxes (that
is, those that identify the sub-groups or skill levels created for each skill group)
are appropriately checked/unchecked. Figure 16 shows an example of the Set
SubGroup Mask window.

Figure 16: Set Sub Group Mask Window
The default setting is that Skill Level 1 (primary) and Skill Level 2 (secondary)
are checked, all other boxes (by default) are unchecked. The existence of the
sub-skill groups can affect agent counts and call reporting. The Peripheral Skill
Group Mask can be overridden on a skill group by skill group basis as required.
Peripheral Configuration 47

47
3.1.2. Peripheral Call Control Variable Map
The mapping of route request elements to Peripheral Variables is controlled by
the Call Control Variable Map field, which is found on the PG Explorer tool.

Figure 17: Call Control Variable Map Field
The Call Control Variable Map field can be used to configure which peripheral
variables should be reserved for a CTI application, and which ones the PG can
use. Following are the ways to control variable usage via the
CallControlVariableMap:
Direct the PIM. The PIM can be directed on which call variables can be
accessed. For example, the following setting allows the PIM to set call
variable 1 and call variables 5 through 10 while preserving the existing
values of call variables 2 through 4 (that is, the PIM will not set call
variables 2 through 4).
Note: This argument is from the perspective of the PIM.
/PIM=ynnnyyyyyy


Direct the CTI portion of the PG. The CTI portion of the PG can be
directed to allow the CTI Client to override any PIM Call Variable setting.
For example, the following setting allows a CTI Client to set call variable 1
and call variables 5 through 10 while preserving the peripheral-determined
values of call variables 2 through 4.
/CTI = ynnnyyyyyy
See also: For details on Route Request Elements, see Chapter 4, Post-Routing. For more
details on Unified ICM CTI capabilities and interaction with the PG, see the
ICM Software Enterprise CTI Interface Specification.
3.1.3. Peripheral Configuration Parameters
Several default settings can be entered in the Configuration Parameters field of
the PG Explorer tool, including default work-mode, default login skill level,
reserved agent preference levels, and station monitoring of logged-in agents.

Figure 18: Configuration Parameters Field
1. Default Work-Mode
The default work-mode used by the PIM when setting an agent to the
READY state via a CTI application can be configured via the
Configuration Parameters field. The keyword /defworkmode, followed by
manual or auto, will set the default work-mode to the Avaya equivalent
of Manual-In and Auto-In respectively.

49
The following example will set the default work-mode to AUTO-IN:
/defworkmode auto
This default work-mode is used by the PIM in the case where a CTI
application does not provide a proper work-mode when setting the agent to
the READY state. If unspecified, the PIM default is MANUAL-IN.
2. Default Login Skill Level
The default login skill level (that is, priority or skill level) used by the PIM
can be configured via the Configuration Parameters field. The default login
skill is used when an agent logs in and no agent skill group member can be
found for that agent in Unified ICM Configuration. The keyword
/defskilllevel followed by a numeric skill level sets the default skill level.
The following example sets the default login skill level to 3:
/defskilllevel 3
If unspecified, the PIM default is 16.
3. Reserved Agent Preference Levels
Reserved agent preference levels (in ICM software, Release 4.0 and greater)
can be configured via the Configuration Parameters field. The reserved
agent 1 and agent 2 preference levels (represented as preference level 51
and 52, respectively, in CMS) can be remapped to a valid preference level.
The PIM will default the values to the highest valid preference level. The
keywords /r1pref and /r2pref are used to re-map reserve preference level 1
and 2 respectively. The following example will cause the PG to re-map
reserve agent 1 and reserve agent 2 preference levels to preference level 15
and 16, respectively.
/r1pref 15 /r2pref 16
Setting a preference value of zero (0) causes the PIM to ignore that reserve
agent skill login and preference level (that is, the agent will not be
considered to have logged into that reserved skill and no metrics will be
collected for that agent for that skill).
4. Station Monitoring of Logged-In Agents
Station monitoring of logged-in agents can be automatically configured via
the Configuration Parameters field. The keyword /monitoragent followed by
a y or n causes the PG to automatically monitor or not monitor a
logged-in agent. The following example causes the PG to automatically
monitor a logged-in agent:
/monitoragent y
With a setting of y, the PG, at the time of an agent login, will automatically
monitor that agents station even if that station is not in the Peripheral
Monitor list. If station monitoring is enabled, the PG will default to
automatically monitoring logged-in agents. If station monitoring is disabled,
the PG will not monitor any agent stations.

Notes:
/monitoragent is set to y in PIM by default.
If you want to monitor only specific extensions on Avaya (For example, if
you are using a shared configuration on the ACD and there are other
applications monitoring the extensions which are not used by Unified ICM),
then you can set /monitoragent to n (use /monitoragent n) and configure the
extensions to be monitored by Avaya PG in the Peripheral Monitor Table of
the PG Explorer.
If you do not want to monitor specific extensions and you need to monitor
all the logged agents, set /monitoragent to y (use /monitoragent y).
Configuring the extensions in the Peripheral Monitor Table of the PG
Explorer is not needed. In such configurations, PIM will monitor only those
extensions where agents are logged in.
If you are using CMS with Unified ICM and have over 1000 agents, it is
recommended to disable the station monitoring of logged-in agents.
Monitoring agent stations (That is providing visibility to all station activity)
results in increased message traffic to the A, increased switch CPU load,
and increased network traffic between the PG and Central Controller.
5. Use Encoded Trunk Information over ANI in Calling Field
With a setting of y, the PIM will report events in the calling field populated
with encoded trunk information rather than ANI. The default mode is to
populate the calling field with ANI. This argument defaults to n. If the
argument is not specified or is specified as
/UseTrunkOverANIInCallingField n an example of one event may be:
19:31:20 pg1A-pim1 Trace: CSTA DELIVERED,
PrivData=[UU=None Consult[CID 603 Dev 6505 DevType 0] II 0
Alert[Handle -1 Type LT_UNKNOWN] ANI 6505
dnis_chars [] UCID 0x0
TG 7 Tk 5 Mult 1]
LoginDigits [] CallPrompt []
CallID = 604 DeviceID = 6505 DeviceType = Static
Alerting = 3501
Calling = 6505
Called = 3501
Redirection = 6505
LocalState = INITIATE
Cause = EC_NEW_CALL
If the argument is specified as /UseTrunkOverANIInCallingField y that
same event may appear as:
19:31:20 pg1A-pim1 Trace: CSTA DELIVERED,
PrivData=[UU=None Consult[CID 603 Dev 6505 DevType 0] II 0
Alert[Handle -1 Type LT_UNKNOWN] ANI 6505
dnis_chars [] UCID 0x0
TG 7 Tk 5 Mult 1]
LoginDigits [] CallPrompt []
CallID = 604 DeviceID = 6505 DeviceType = Static
Alerting = 3501
Calling = 229381 <= decimal equivalent of encoded trunk
Called = 3501
Redirection = 6505
LocalState = INITIATE

51
Cause = EC_NEW_CALL
Note: The scheme for trunk information encoding is such that the upper
17 bits represent the Trunk Group and the lower 15 bits represent
the Trunk. From the above example: For a Trunk Group value of
7 and a trunk value of 5, the binary representation for the encoded
value is
00000000000000111 000000000000101. The decimal equivalent is
229381.
/UseTrunkOverANIInCallingField y
6. Use Encoded Trunk Information over ANI in Calling Field for
Outbound Calls
To support the selecting of trunk data or ANI in calling device field for
outbound calls, use the configuration parameter:
/UseTrunkOverANIInCallingFieldForOutboundCalls.
The flag-usage is as follows:
1. Set the configuration parameter to y, if the trunk information is
required in the calling device field for outbound calls.
/UseTrunkOverANIInCallingFieldForOutboundCalls y
2. Set the configuration parameter to n, if the trunk information is not
required in the calling device field for outbound calls.
/UseTrunkOverANIInCallingFieldForOutboundCalls n

Notes:
1. When the value of this flag is n, ANI appears in the calling device
field. Also, the default value of this flag is n.
2. This flag controls the value of calling device field in CSTA
DELIVERED and CSTA ESTABLISHED messages for outbound calls.
3. This flag is available from Releases ICM 6.0(0) SR9, and ICM
7.1(3) onwards.


7. Display the Caller Entered Digits (CEDs) on the Agent Desktop
To ensure that the CEDs are populated on the agent desktop, set the
following parameters in the PG Explorer:
In the Advanced tab, ensure that the Agent auto-configuration check box
is checked, as shown in the Figure 19.

Figure 19: Agent Auto-Configuration


53
In the Agent Distribution tab, ensure that the Enable agent reporting, check
box is checked, as shown in the Figure 20.

Figure 20: Enable agent reporting

If you do not select them together, the CEDs will not be populated on the agent
desktop. These settings apply only to the Avaya PG with the CMS mode
enabled.

3.2. Peripheral Targets
A Unified ICM Peripheral Target is equivalent to the combination of DNIS
(VDN extension or Hunt Group Extension) and the trunk groups through which
incoming calls arrive. VDNs are equivalent to the DNIS (e.g., VDN 1100 would
be DNIS 1100).
A Peripheral Target can be either of the following:
A Network Target, identified by a Trunk Group and DNIS (VDN) that
terminates on the Avaya. A Network Target is a target that Unified ICM
software identifies as a termination for calls routed through the network.
These trunk group-DNIS pairs are typically associated with labels
provisioned by a long distance carrier.
An Internal Target, identified by the DNIS (VDN) alone. An Internal Target
is a VDN or Hunt Group extension used as a destination for internal call
transfers, tie lines, and so on.
All Peripheral Targets, both internal (e.g., transfer points) and network, should
be configured as Peripheral Targets in Unified ICM database. This is done by
using the Configure ICM tool. It is not necessary to enter every
TrunkGroup/VDN combination in Unified ICM database unless you require
them for call routing. In other words, a VDN needs to be entered only once in
the Unified ICM database as a Peripheral Target in order for the PG to monitor
the calls on that VDN.
You can configure Peripheral Targets by using the Peripheral Target
Configuration window within the Configure ICM tool.
3.2.1. Configuring VDN and Hunt Group Extensions as Peripheral
Targets
All VDN and Hunt Group extensions that are in any way connected with the
handling of an incoming call must be configured in Unified ICM database as
Peripheral Targets. This will ensure complete call monitoring. The PG will
monitor only those VDNs and, optionally, Hunt Groups that are configured as
Peripheral Targets.
VDNs or Hunt Group Extensions that are not accessed directly via a Trunk
Group (that is, ones that are only used internally), should use the default Trunk
Group 9999. (See Trunk Groups later in this chapter.)
Note: The Avaya PG supports extensions of up to seven digits the agent can login to
a Softphone that has an extension up to seven digits. This seven digit support
applies to VDNs, Hunt Groups and Agent Login IDs. ICM 5.0 users must install
Service Release 7 (SR7), and ICM 6.0 users, SR1, for seven digit support. For
earlier ICM releases, the Avaya PG limits support to five digit.
In order to use a seven digit extension, the config PIM registry
EnableSevenDigitExtension needs to be set to 1 in following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,
Inc.\ICM\<cus01>\<PGXX>\PG\CurrentVersion\PIMS\pim1\ATTData\Config\
Peripheral Monitor Table 55

55
3.3. Peripheral Monitor Table
Unified ICM Peripheral Monitor table is used to configure stations for station
monitoring and VDNs that have Timed ACW values. A Peripheral Monitor table
VDN entry is used only to indicate any Timed ACW value as configured on the
switch. This Peripheral Monitor VDN entry does not replace a Peripheral Target
for VDN monitoring.
Note: VDNs must also be configured as Peripheral Targets in order to be
monitored for reporting.
You can configure the Peripheral Monitor Table by choosing Peripherals >
Peripheral Monitor within Configure ICM to display the Peripheral Monitor
table.
Click the Insert button to add records using the Peripheral Monitor
Configuration window.
3.3.1. Monitoring Stations
The Peripheral Monitor table is used to specify which station, or range of
stations, should be monitored by the PG. Multiple peripheral monitor entries are
allowed. Set the Peripheral Monitor Type to Station. When specifying a single
station (e.g., 1100), use the Extension field. When specifying a range of stations
(e.g., 1100-1200), use the Param String field.
3.3.2. VDN Timed ACW Settings
VDNs that have a Timed ACW value on the Avaya should be added as a
Peripheral Monitor table entry with a Type of VDN. The Peripheral Monitor
Param Field should indicate the Timed ACW value, as shown in Figure 21.

Figure 21: Peripheral Monitor Param Field

For VDNs that do not have the VDN override set, specify the Timed ACW
value in the Peripheral Monitor table parameter string using the following
format:
acw=N

Notes:
1. The acw keyword must be in lower-case. Replace the N with the number of
Timed ACW seconds. For example, a VDN with a Timed ACW of 30
seconds that does not have VDN override set would specify a Timed ACW
value in the Peripheral Monitor table as:
acw=30
For VDNs that do have VDN override set, specify the Timed ACW value in
the Peripheral Monitor table parameter string using the following format:
ACW=NNNN
2. The ACW keyword must be in upper-case. Replace N with the number of
Timed ACW seconds. For example, a VDN with a Timed ACW of 180
seconds which does not have VDN override set would specify a Timed
ACW value in the Peripheral Monitor table as:
Peripheral Monitor Table 57

57
3. Only those VDNs that are monitored and for which the Avaya generates
call events on their behalf, are considered as being in the call path by the
PG when determining the correct Timed ACW value. In other words, if the
PG is not notified by the switch that the call has passed through a VDN, the
PG cannot consider that VDN when determining the Timed ACW value.
The PG will endeavor to use the same rule set as documented for the switch
in determining the Timed ACW value to use (including VDN override).
3.3.3. Configuring the Return Destination VDN on Unified ICM
The Return Destination feature is configured in the PG Explorer Tool for a
particular VDN for which the Return Destination is enabled on Avaya
Switch.
In PG Explorer > Peripheral Monitor tab, set the Parameter string for the
return destination VDN as returndestination (See Figure 22).
Here, 3606 is the Return Destination VDN.

Figure 22: Return Destination feature on ICM

The following figure shows the Return Destination logs:

Figure 23: Return Destination Logs

To configure Return Destination VDN on Avaya Switch, see the section
Configuring Return Destination VDN on Avaya Switch.
See the section ACD Notes and Restrictions for known caveats for Return
Destination VDN.
PIM Configuration 59

59

3.4. PIM Configuration
The number of ASAI links supported by the Avaya PG is determined by
checking/unchecking the Using MAPD check box (as shown in Figure 24),
during the Avaya PG setup process. Using MAPD option does not indicate if
MAPD is used with the setup or not.
If Using MAPD check box is:
Checked: Avaya PG supports up to eight ASAI links (1 to 8).
Unchecked: Avaya PG supports up to four links (1 to 4)

Figure 24: Peripheral Gateway Component Properties
The Avaya ECS PIM Configuration Setup window is shown in Figure 25. This
window is displayed by using the Web Setup tool.

Figure 25: Avaya ECS PIM Configuration
The following points describe the Avaya ECS PIM Configuration Setup
window:
1. Check the Enabled check box to enable the PIM.
2. Check the CMS Enabled check box if the Avaya PG is used with CMS
Server. If you are using CMS-less configuration, do not check this check
box.
3. If the CMS Enabled check box is checked:
a) Specify the Port number to listen on as specified in the CMS Server
against the PG entry. This is the port number on which the Avaya PG
listens for the CMS connection.
b) CMS Hostname is optional. If specified, it should be the host name
of the CMS Server.
4. For Host1:
Trunk Groups 61

61
a) Check the Enabled check box under CVLAN/MAPD Configuration.
b) Specify the Avaya ACD hostname/IP address in Hostname field.
c) Select the CTI link number as configured in the Avaya ACD. Monitor
CTI links is the CTI link on which Avaya PIM receives all the events
except the post-route requests and heartbeat requests. Post-Route
CTI links is the CTI link on which Avaya PIM receives all the post-
route requests.
5. Heartbeat Maintenance is the CTI link on which Avaya ACD sends
heartbeat requests to the Avaya PIM. Select the appropriate link if the
heartbeat option is configured in the Avaya ACD. If not, leave this field
unchecked.
6. Specify the details for Host 2 similar to Host 1, if a duplexed Avaya ACD is
used.
7. Leave the rest of the fields with default values.

Default Timed ACD Value
The value set here is used as the default if a Skill Group or VDN Timed ACW
value has not been configured and cannot be found for the call path. Note,
however, that the agent must have a work-mode of AUTO-IN in order for the
Timed ACW value to apply. Any configured Timed ACW value found that is in
the call path will be used.
Note: The configuration of Avaya PG for Avaya ACD and AES Server is the same.

3.5. Trunk Groups
An Avaya Trunk Group is equivalent to a Unified ICM Trunk Group. The
Avaya Trunk Group Number (For example, trunk group 5) is Unified ICM
Trunk Group Peripheral Number. The Trunk Group Access Code (TAC) is
Unified ICM Trunk Group Extension (For example, 500). TrunkGroupTimer is
the value in the Registry that specifies the interval (in seconds) in which the PIM
generates trunk group value requests. In other words, the TrunkGroupTimer
specifies the timer period at which the PIM will issue a Trunk Group query for
each configured ICR trunk group. The default value for TrunkGroupTimer in the
Registry should be set to 10 seconds.
The PG uses the Trunk Group Extension to value query the Avaya and monitor
Trunk Group trunk utilization. The PG also uses the Trunk Group Extension to
properly identify an incoming call on translation route applications. The Trunk
Group Extension is set in the Trunk Group Configuration window of Configure
ICM.
For example, Trunk Group 11 with Trunk Access Code 111 would be entered in
the Unified ICM database as Trunk Group 11 with Trunk Group Extension 111.
Create a default trunk group 9999 for use in those instances where a physical
Trunk Group does not exist. For example, Hunt Groups or VDNs that are
internal transfer points for agents, and therefore not accessible via an external
trunk group, should use the default trunk group 9999 to allow the creation of the
Peripheral Target. The default Trunk Group extension (that is, TAC) can either
be left blank or specify 9999.

The NT Registry should be configured to allow the PG to Map Peripheral
Targets without Trunk Group.
Note: During a translation route, you need not configure the Network Trunk Group
(NTG) if Unified ICM trunk reports are not required. A dummy NTG
configuration, with a dummy peripheral number, can be configured and
associated with the configured translation routes.
3.6. Trunks
Individual trunks may or may not be monitored on the Avaya.
No special configuration information is required on an individual trunk basis.
However, you must specify the number of trunks in the Trunk Group in the
Trunk Group configuration Trunk Count field. Because the switch provides only
the number of trunks-in-use and the trunks-idle, this count allows the Avaya
PIM to determine the number of out-of-service trunks.
3.7. Services
A Unified ICM Service is the combination of call type (known by the VDN) and
call treatment (that is, vector). There is no direct correlation of Unified ICM
Service to a specific Avaya object. However, a service does fit with what users
typically identify as the call treatment on the Avaya.
The Service Peripheral Number is equivalent to the VDN extension number. The
Peripheral Service Level is equivalent to the VDN service level.
Note: The Avaya PIM does not support the updating of Peripheral Service Level.
Using the Service Explorer tool, set the Peripheral Service Level to Computed
By Call Center. The Unified ICM Peripheral Service Level corresponds to the
VDN Service Level (Figure 21).
Skill Groups 63

63

Figure 26: Peripheral Number and Service Fields
3.8. Skill Groups
The Avaya-to-Unified ICM Skill Group mapping is as follows:
Table 4: Avaya-to-Unified ICM Skill Group Mapping
Unified ICM Software
Avaya
Skill Group Skill Group
Skill Group Peripheral Number Skill Group Number
Skill Group Extension Skill Group Extension
Subgroups Skill Group and Skill Levels
1
Note: Unified ICM Skill Group Peripheral Number is the Avaya Skill Group Number.
The Unified ICM Skill Group Extension is the Avaya Skill Group Extension.
For example, if the Spanish skill group has a group number of 11 and an
extension of 1100, then the Unified ICM Skill Group Peripheral Number will be
11 and the Skill Group Extension will be 1100 (see Figure 26).

These are the skill group and skill levels supported for agent login on the DEFINITY
ECS in EAS configurations.

Figure 27: Skill Group Configuration Fields
Important: The Unified ICM Skill Group Peripheral Number and Skill Group Extension are
important and must be kept synchronized (that is, up-to-date) with the Avaya
skill group configuration. Failure to keep the skill group information
synchronized between the Avaya and the Unified ICM database may result in
incomplete (or worst case, inaccurate) call and agent statistics.
3.8.1. Skill Group Subgroups
When created, a single Unified ICM skill group may cause more than one skill
group to be created in the Unified ICM database. These other skill groups are
sub-skill groups, or subgroups, for the created base
1
(priority 0) skill group. A
subgroup has a unique priority and is associated with the base skill group.
Note: For every base skill group created, at least one sub-group must be created
under it.
Important: The PGs need to be cycled every time new subgroups are created.
The creation of these subgroups is determined on which subgroup mask is used
at the time of the base skill group creation. The subgroup mask can have one of
two settings: Peripheral Default or Specified. These settings are specified in the
Skill Group Explorer tool.

1
The "base" skill group is a Unified ICM skill group created by selecting Save in the
Skill Group Explorer. Any sub-groups (sub-skills) created by checking the "mask"
check box are also created and mapped to the "base" Unified ICM skill group.
Skill Groups 65

65
If the subgroup mask is Peripheral Default, then the Peripherals Skill Group
Mask is used to determine which subgroups will be created; otherwise, the Sub
Group Mask for the Skill Group is used.
A subgroup is created for each checked box in the Sub Group Mask. The
subgroups are used by the PG to properly log in the agent to the appropriate
subgroup based on the agents skill group skill level. For example, in an EAS
type switch configuration, agents may be logged into a skill group with a
PRIMARY or SECONDARY skill level. In order to properly account for agent
counts and roll up call statistics properly, the subgroup for the agents skill
group should be configured in the Unified ICM database.
Note: In order for AutoLoginBase to work correctly and provide consistent LAA
stats for agents in all priorities, at least one agent must be logged in to the base
skill group.
For CMS Configurations:
The Avaya Hunt Group configuration screen for each split must have the
Measured Field set to either both or external in order for the CMS to receive
Hunt Group (split) data.
Agent configurations on an Avaya EAS switch can use any of the valid skill-
types (1-16) if the Cisco CMS report that is installed and running is an EAS
report. Likewise, the agent configurations on an Avaya EAS, is limited to 1-2
skill-types.
If you configure agents with a skill type greater than 2 for a Non-EAS or EAS
CMS report, the PG will not be able to properly activate.
Note: When working with ICM Version 4.5(x) and later, while activating the ACD
PIM if you get an error message that contains the term C_NOENT, do the
following:
Add the name and IP address of the ACD PIM to the host file.
Restart the PG ICM Services.
For CMS-less Configurations:
The subgroups are used to associate an agent with the correct skill group and
skill level. For example, if an agent is configured on the ACD switch to be
logged into skill 1 priority 3, then you would configure that agent in Unified
ICM database to be a skill group member of skill group 1 subgroup 3.
See also: See the section CMS Cisco Real-Time Report, for more information on CMS-
related skill group issues related to configuration and CMS report revision.
3.8.2. Using Skill Group Priorities without Configuring Sub-skill
Groups
In Unified ICM, sub-skill groups are created when configuring the skill group
priority. Each sub-skill group creates a target ID in Unified ICM database. This
target ID is used by all Unified ICM processes during the real-time messaging.
The PG needs to send constant real-time messages and reports to the Central
Controller for each of the configured skill groups. The PG also needs to save the
reports on the disk so that they are available to the Central Controller at any
time. These operations can be very demanding when a large number of Unified
ICM skill groups are configured.

If the number of ACD skill groups and skill group priorities is large, it is not
recommended to use sub-skill groups because this causes increased data flow
between the PG and the Central Controller. When the sub-skill group is not
configured, the PG reports only the skill group peripheral number defined in the
ACD to the Central Controller without the skill group priority. In this case,
Unified ICM reports contain only the skill group defined by the ACD peripheral
number.
Note: This feature is applicable from ICM 6.0 SR7 and 7.1(2) with Avaya PG.
1. Peripheral Configuration:
To avoid the base and sub-skill groups from being created, you must not
have a skill group mask selected (see Figure 24).

Figure 28: Peripheral Configuration
2. Skill Group Configuration:
When configuring the skill group, do not select a skill group mask. The
peripheral number should match the ACD skill group number without the
skill group priority (See Figure 25).
Skill Groups 67

67

Figure 29: Skill Group Configuration
3. Impact on Unified ICM Reports:
Table 5: Impact on Unified ICM Reports
Report Type Impact
Agent Skill Group
Half Hour

When you do not configure a skill group priority in
Unified ICM, the Agent Skill Group Half Hour report will
add all the statistics of the ACD priorities to a single skill
group.
If you configure the ACD priority in Unified ICM, the
reports will display the statistics for each priority.
Skill Group Half Hour

The reports will display all the configured Unified ICM
skill groups. When using ACD priority, the Unified ICM
reports display a skill group for each of the priorities
configured (called Unified ICM sub-skill group) and one
base skill group.
When you use a skill group with no priority configured,
the reports will display one Unified ICM skill group
configured for each ACD skill group.
Termination Call
Detail

The Termination Call Detail for calls for the ACD skill
groups with priority configured will contain the Unified
ICM skill group defined by the ACD peripheral number
(base skill group).

4. Migrating from Sub-skill Groups to Skill Groups with no ACD Priority
Configured:
To migrate from sub-skill groups to skill groups with no ACD priority
configured, you need to remove Unified ICM sub-skill groups. To do this,
complete the following steps:
1) Remove all references to sub-skill groups in the router scripts and agent
skill group membership. (See Figure 26)

Figure 30: Router Scripts
2) Clear the Override peripheral default mask check box in the
Subgroup Mask tab in the skill group configuration (See Figure 25).
3) Clear all check boxes in the Skill Group Mask tab in the Peripheral
Explorer configuration (see Figure 24).
4) Restart the PGs to reflect the change in the peripheral configuration.
Agents 69

69
5. Impact on WebView Reporting:
After the sub-skill group migration, the base skill group reporting continues
to work the same way and there is no impact on historical reporting.
Once the migration is complete, the sub-skill groups are not permanently
deleted from the database and are available for historical reporting until they
are permanently deleted. The sub-skill group records before the migration
process was completed are available for historical reporting.
6. Disabling PIM Configuration Warning Messages:
Add the dynamic PIM registry DisableSkillGroupConfigWarnings
manually. To disable the skill group configuration warning messages from
being written to the PIM logs, set the registry value to one (decimal).
Add the registry to the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\<ICM
Instance >\PG Instance\PG\CurrentVersion\PIMS\pim1\ATTData\Dynamic
The default value is 0 (decimal).
3.8.3. Available Hold Off Delay
The Available Hold Off Delay configuration parameter in the Skill Group
Explorer Tool should be set to the Timed ACW value on the ACD for this skill
group.
3.9. Service-to-Skill Group Mappings
Since VDNs typically correspond to Unified ICM Services, the service-to-skill
group mapping is equivalent to the skill groups used by the vector for the VDN.
In order to ensure accurate call and agent reporting, be sure to include all skill
groups used by the VDN in the service-to-skill group mapping for that VDN.
Service-to-skill group mappings are made in the Service Member window of
Configure ICM.

3.10. Agents
The ACD-to-Unified ICM Agent mapping is as follows:
Table 6: ACD-to-Unified ICM Agent Mapping
Unified ICM Software ACD
Agent Agent
Agent Peripheral Number Agent ID
Agent Extension Agents Physical Extension
Important: For PGs using CMS, agents are dynamically configured by the PG. They do not
need to be added individually via the Configure ICM tool. For CMS-less PG
installations, agents must be configured via the Configure ICM tool. Further,
agent skill group member assignments must be completed to match the switch
configuration.
The Agent Peripheral Number is equivalent to the ACD Agent ID. Note the
following considerations for CMS and non-CMS environments:
For CMS configurations, agent configuration data is not required in
Unified ICM database.
For CMS-less configurations, the agents must be configured in Unified ICM
database. This is done through the Agent Configuration window of
Configure ICM.
Note: Reporting and routing issues may be seen in Unified ICM if the agent is not
logged into a station before handling (making/receiving) calls.
3.10.1. Agent States
Table 7 lists the Avaya agent states and their definitions. Some agent states have
an optional call direction, [IN/OUT], in case a call comes in or is initiated while
in that state.
Table 8 shows how Unified ICM agent states are derived from the Avaya states.
Table 7: Agent State Definitions
Avaya Agent State Definition
ACD IN/OUT Agent is on an incoming/outgoing ACD call
DACD Agent is on a direct agent ACD call.
ACW [IN/OUT] Agent is bookkeeping, doing data entry, or is at any other
work related to the previous call, and is not available to
receive another ACD call. Includes times an agent is on
incoming and outgoing calls during ACW.
If on a call, IN/OUT specifies the call direction.
DACW Agent is in the ACW state for a direct agent ACD call.
AUX [IN/OUT] Agent is doing non-ACD work, on break, or in a meeting.
Agents initially login in AUX mode until they AUTO-IN or
MANUAL-IN. Includes times an agent is on incoming and
Translation Routes 71

71
Avaya Agent State Definition
outgoing calls during AUX. Agent is not available to receive
an ACD call.
If on a call, IN/OUT specifies the call direction.
AVAIL Agent is available to receive calls.
RINGING Call is ringing at the agents extension.
OTHER Agent is doing other work (e.g., the call is on hold, the agent
is dialing to place a call or access a feature, the agent is
handling a personal call, or DACD is ringing with no
answer.)
UNKNOWN Agent is in an unknown state (e.g., when CMS link to G3
switch is not operational).
Table 8: Unified ICM-Avaya Agent State Derivation
Unified ICM Agent
State
Derivation from Avaya Agent States
Logged_On Logged_In
1
Logged_Off Logged_Out
1

Ready All states other than AUX and UNKNOWN
Available AVAIL
WrapUp ACW, DACW
TalkingIn ACD-IN, DACD
TalkingOut ACD-OUT (not in AUX)
TalkingOther AUX IN/OUT, ACW IN/OUT
Other OTHER

Note: Support for AUX reason code change in Not Ready state is available from
ICM 8.5(3) onwards.
3.11. Skill Group Members
For CMS-less configurations, the agent skill levels for their logged-in skill
groups can only be determined via Unified ICM configuration. That is, Avaya
does not yet provide skill level information over the CTI link for agent logins.
Therefore, you must preconfigure and associate the agent with the correct
subgroup in order to properly identify the agents skill level.

Logged_In and Logged_Out are not CMS agent states


3.12. Translation Routes
Translation routes are supported on the Avaya PG. Translation routes can be
used to pass caller information to the Avaya (for example, ANI or Network
CED).
No special Unified ICM configuration is required for the Avaya.
3.13. Routes
A Unified ICM Route is one or more Unified ICM Peripheral Targets. A Unified
ICM Peripheral Target is a Network Target identified by a trunk group and
DNIS that terminate on the Avaya. A Peripheral Target is equivalent to the
combination of DNIS (VDN extension or Hunt Group extension) and the trunk
groups through which the incoming calls arrive.
No special Unified ICM configuration is required for the Avaya.
3.14. Routing Client
The Routing Client Configuration Parameters field should be null-terminated.
The field delimiter, -DEFROUTE, must be specified as shown in Figure 27.

Figure 31: Configuration Parameters Field
Order and case are not significant. However, all fields must be separated by
spaces. The following example shows a default Post-Route (Avaya Extension)
to be used if, for any reason, the PG does not get a route response from the
Router:
Registry Keys 73

73
-DEFROUTE 3214
If a default route is not configured, the PG will give a negative
acknowledgement (NAK) to the Avaya causing vector processing to proceed.
The NAK may be the desirable action, depending on how the Avaya vectors are
written.
3.15. Unified ICM Configuration for CMS-less PGs
In a PG configuration that does not use CMS, some additional configuration is
necessary in Unified ICM software. Each of the following changes can be made
by using the Configuration Managers PG Explorer tool.
You must configure all agents in Unified ICM database.
You must map agents to skill groups in Unified ICM database. The agent-
to-skill group mapping must match the Avaya configuration. In addition, the
subgroup must correctly map to the agents priority.
You must configure monitored instruments in the Peripheral Monitor table
of Unified ICM database. Agent stations should be monitored.
You must configure Peripheral Targets in Unified ICM database for all
VDNs through which monitored calls flow.
3.16. Maintaining Your Configuration
It is preferred that changes made to your configuration be accomplished first on
the Avaya/CMS, then in Unified ICM database. This will ensure that the PG
sees the configuration updates on the Avaya/CMS systems.
It is imperative that the Avaya, CMS, and Unified ICM Database configurations
are kept synchronized (that is, up-to-date with each other). Inaccurate or
incomplete data could result in inaccurate agent and/or call data.
3.17. Registry Keys
This section provides the recommended values for the PIM dynamic registry
keys and PIM config registry keys.
The recommended values for the PIM dynamic registry keys are:
BriCheckMeters = 0 (for CMS), 1 (for CMS-less)
This value indicates whether the PIM should throttle the ASAI/ CTI message
rates or not. 1 indicates that it should enable message metering (that is,
throttle outgoing messages).
Note: The dynamic registry field BriMaxOutstandingMessages is used along with
BriCheckMeters registry field to indicate the number of outstanding ASAI/
CTI messages (that is, messages waiting for a response from the CVLAN
Server). After the PIM has reached the maximum number of outstanding
messages, it will not send messages until one pending ASAI/ CTI message has
been received.
During the startup of the PIM process, the PIM will send the ASAI/ CTI
messages at a faster rate until the limit controlled by the
BriMaxOutstandingMessages field. The high priority outgoing messages
take precedence over the normal priority outgoing messages.

The PIM also uses message metering to ensure that it does not exceed the
maximum number of active associations per CTI link (see the dynamic
registry field, MaxActiveAssocPerCTILink).
BriMaxOutstandingMsgs = 100
SmartAgentStateTimer = 1800 (for CMS), 10 (for CMS-less)
BriCheckMessageRates = 0 (for CMS), 1 (for CMS-less)
This value indicated whether the PIM should measure the ASAI/ CTI
message rates or not. 1 indicates that the ASAI/ CTI message rates should
be measured.
The recommended values for the PIM config registry keys are:
MaxActiveAssocPerCTILink key should be set depending on the version of
CVLAN server. (The MaxActiveAssocPerCTILink refers to the maximum
active association per CTI link)

Table 9: MaxActiveAssocPerCTILink Values
CVLAN server MaxActiveAssocPerCTILink
6.1.0
8.2.1
9.1
AES Server
2048
4096
8192
8192

Note: It is not required to cycle (restart) the PG, for the changed dynamic registry
values to be effective; however, for the changed config registries to be effective,
you need to cycle the PG.

Registry Keys 75

75
76
4. Post-Routing

The Avaya PG supports Post-Routing and can therefore be considered a routing
client. The PG can route to any valid dialed number.
This chapter describes the features of Unified ICM Post-Routing available with
the Avaya PG. It also discusses any considerations you should be aware of when
using Post-Routing or Translation Routing on the PG.
Route Request 77

77

4.1. Route Request
To initiate a post-route, the Avaya vector that is handling the incoming call must
include an adjunct route request step with the correct ASAI/CTI extension
specified.
A wait time should be specified after the adjunct route request to allow for
Unified ICM software to route the call. Although Unified ICM post-route
destination decision is virtually instantaneous, a typical wait time of four to six
seconds in the vector is appropriate. The wait time may need to be adjusted
depending on anticipated call volumes.
Vector writers should consider what should happen to the call if the Avaya
cannot properly route the post-routed call, or if the CTI link is down. For
example, if the label (call destination) returned from the CallRouter is not valid
(e.g., incorrect Trunk Access Code, extension destination is busied-out, Class of
Restriction (COR) does not allow the call to complete), you should consider
how you want the call handled.
4.1.1. Route Request Elements
The Avaya sends a route request to the PG containing the following Route
Request Elements.
Calling number (CLID)
Called number (typically the VDN)
User-user information (32 bytes maximum, where the data type is (a) user
defined or (b) ASCII)
Last set of Avaya collected digits (CED) (if any)
Digit collection timeout (seconds)
Call priority level (values: not_used, not_in_queue, low, medium, high,
top)
Interflow type (that is., cause of interflow; values: all, threshold, vector)
Time (time the routed call is to spend in the queue before interflow)
DNIS chars (optional)
Call ID
Trunk group number and trunk number (optional; mutually exclusive with
calling number)
II-digits
4.1.2. Route Request Peripheral Variable Usage
If the Route Request Peripheral Variable is allowed, the PG will map the Route
Request elements (such as CLID and Called Number) into Peripheral Variables.
Unified ICM script writer can then use the information in the Peripheral
Variables to create scripts that determine which destination best suits the callers
needs. All Peripheral Variable data types are ASCII.
78 Post-Routing

The mapping of Route Request Elements to Peripheral Variables is controlled
by the Call Control Variable Map field, which is found on the Peripheral
Configuration window of the Configure ICM tool (Figure 28).

Figure 32: Call Control Variable Map Field
4.1.3. Call Control Variable Map
The Call Control Variable Map field can be used to configure which peripheral
variables should be reserved for a CTI application, and which ones can be used
by the PG. There are two ways to control variable usage via the Call Control
Variable Map field:
Direct the PIM. The PIM can be directed on which call variables can be
accessed. For example, the following setting (made in the Call Control
Variable Map field) allows the PIM to set call variable 1 and call variables 5
through 10 while preserving the existing values of call variables 2 through 4
(That is, the PIM will not set call variables 2 through 4). Note that, this
argument is from the perspective of the PIM.
/PIM=ynnnyyyyyy

Route Select 79

79
Direct the CTI portion of the PG. The CTI portion of the PG can be
directed to allow the CTI Client to override any PIM Call Variable setting.
For example, the following setting allows a CTI Client to set call variable 1
and call variables 5 through 10 while preserving the peripheral-determined
values of call variables 2 through 4.
/CTI = ynnnyyyyyy
See also: For more details on Unified ICM CTI capabilities and interaction with the PG,
see the ICM Software Enterprise CTI Interface Specification.
Table 10 shows the Peripheral Variable numbers, the Route Request Elements
those numbers represent, and the possible values contained in the Route Request
Elements.
Table 10: Route Request Peripheral Variable Map
Peripheral
Variable
Route Request Element Possible Values
1 CallPriorityLevel CP_UNUSED, CP_NOT_IN_QUEUE,
CP_LOW, CP_MEDIUM, CP_HIGH,
CP_TOP
2 InterflowType IT_UNUSED, IT_ALL, IT_THRESHOLD,
IT_VECTOR
3 TimeInQBeforeInterflow ASCII char string (empty string if unused),
units = Seconds
4 DNIS ASCII char string (empty string if unused)
5 User-User Information See Note 1.
6 CED Caller Entered Digits (empty string if
unused)
7 II-digits II-digits (ASCII form) (empty string if
unused)
8 Trunk Information Format (if provided by switch):
TrunkGroup Number, Trunk Number,
Trunk Direction
9 Calling Number If provided by switch (e.g. if on ISDN
trunks or on-switch call)
10 VDN Vector Directory Number
Note 1: The UUI will be limited to ASCII characters (null-terminated ASCII character
string). That is, any non-ASCII UUI data received will not be stored in the Peripheral
Variable. It is anticipated that all UUI data (ASCII and non-ASCII) will be stored in Unified
ICM database. Those details are not presented in this document.

80 Post-Routing

4.2. Route Select
The PG receives the selected route information from the CallRouter and
converts it to a Route Select message for the Avaya. The Route Select message
can be used to set call attributes, request digit collection from the switch,
provide dial-ahead digits to the switch for collection, or specify user-user
information to be included in the call.
You can specify the Route Select functionality through the Peripheral Variables
or the syntax used in the Label. Unified ICM script can be used to set the
Peripheral Variable contents. Where the setting of Route Select functionality
overlaps, the Peripheral Variable setting takes precedence. Refer to the Avaya
documentation to determine when any of the Route Select features can be used.
For example, it may not make sense to have call priority ON if the destination is
a VDN or Split. As another example, direct agent calling would not make sense
if the destination is a VDN.
4.2.1. Route Select Message
The Avaya Route Selection Message has the following elements:
Destination route select. On-switch or off-switch called number.
User-user information. This consists of:
DataType: (a) UU_TYPE_USER (user defined); or (b) UU_TYPE_IA5
(ASCII)
Length: number of bytes (40 bytes maximum)
Data
Call priority (ON or OFF). If ON, this parameter represents a special type of
call that carries three burst distinctive ringing and will not go to the
covering point for coverage or send all calls.
Direct agent call. This consists of:
Agent extension.
ACD Split extension, which specifies which queue to place the waiting
call in. The agent must be logged into this split.
User data. Used for digit collection or to specify dial-ahead digits:
User data type:
a) COLLECT, which specifies digits are to be collected
b) COLLECTED, which specifies dial-ahead digits
The PIM default is COLLECTED.
Digit collection timeout (0-63 seconds): Specifies the number of
seconds tone detector will continue to collect digits after the first digit is
received. The PIM default is no timeout.
Data: If the user data type is COLLECT, this field is interpreted as a
binary integer specifying the number of digits to collect. If the user data
type is COLLECTED, this field is an ASCII string specifying the dial-
ahead digits.
Route Select 81

81
Use external trunk identified by Trunk Access Code (TAC). The TAC
can be prefixed in the called_number field.
4.2.2. Restrictions on Digit Collection
The Avaya restrictions that apply to digit collection include:
Only incoming trunks of any type, including ISDN, MFC, and R2MFC, are
eligible for ASAI/CTI-requested digit collection.
Incoming disconnect supervision must be administered on the incoming
trunk to allow a call prompter/tone detector to connect.
4.2.3. Route Select Peripheral Variable Usage
The PG maps the Peripheral Variables received in the CallRouters Route Select
message as shown in Table 9. All Peripheral Variable data types are ASCII.
Peripheral Variables 1-4 and 6-10 are unassigned and can be used for the Route
Select elements shown in Table 11.
Table 11: Route Select Peripheral Variable Map
Peripheral Variable Route Select element Possible Values
1-4, 6-10 Call Priority CP_ON, CP_OFF (default)
1-4, 6-10 Digit Collection/Dial Ahead (See the Digit
Collection/Dial Ahead
section that follows.)
1-4, 6-10 Trunk Access Code (See the Trunk Access
Code section that follows.)
5 User-User Information (See the User-User
Information section that
follows.)
A Peripheral Variable can only be used for one Route Select element at a time.
If a Peripheral Variable syntax is invalid or the Peripheral Variable is an empty
string, the Peripheral Variable is ignored. The only fixed Peripheral Variable is
PV 5, designated for UUI.
4.2.4. Digit Collection/Dial Ahead
The Digit Collection/Dial Ahead peripheral variable string has the following
syntax:
COLLECT NUMBER_OF_DIGITS_TO_COLLECT TIMEOUT
DIGIT_COLLECTION_TIMEOUT
or
DIAL DIAL_AHEAD_DIGITS
COLLECT, TIMEOUT, and DIAL are keyword delimiters and must be specified
as shown (case is not important). The fields
NUMBER_OF_DIGITS_TO_COLLECT, DIGIT_COLLECTION_TIMEOUT, and
DIAL_AHEAD_DIGITS are supplied by the customer. The number of digits to
collect must be between one (1) and 24, inclusively. All fields must be
82 Post-Routing

separated by spaces. Every # and * count as one digit each. The digit collection
timeout must be between one (1) and 31, inclusively.
The following example indicates that four digits are to be collected with a digit
collection timeout of ten seconds:
COLLECT 4 TIMEOUT 10
The next example indicates that the digits 3, 2, 1 should precede the route
selection:
DIAL 321
With proper configuration using translation routes, the DIAL syntax can allow
you to provide the callers ANI (or any set of digits) to the Avaya and
subsequently have it displayed on an agents console.
4.2.5. Trunk Access Code
The Trunk Access Code Peripheral Variable has the syntax:
TAC TRUNK_ACCESS_CODE
TAC is a keyword delimiter and must be specified as shown (case is not
important). The TRUNK_ACCESS_CODE field should specify a valid Trunk
Access Code extension for the Peripheral. The TAC can also be
pre-pended in the Label. All fields must be space separated.
The following example indicates a Trunk Access Code of 111 for the route
selection:
TAC 111
4.2.6. User-User Information
This is a null-terminated ASCII character string. The UUI data is stored in
Peripheral Variable 5 for both the Route Request and Route Select messages
only if the protocol format of the UUI data is C_UU_IA5. Therefore, unless
modified, all UUI data received for a call will be included when sent to the calls
destination. UUI data is limited to 40 bytes.
Avaya PIM was designed to support the User-to-User information (UUI) up to
32 bytes inline with the older switch version supportability, which was 32 bytes.
Avaya CVLAN Server Release 8, and link version 4 and beyond, ASAI now
supports UUI up to 96 bytes.
With this enhancement Avaya PIM supports 40 bytes for the UUI field, but the
CTIOS Agent Desktop takes a maximum of only 39 characters of a 40 character
string for call variables.
Route Select 83

83
4.2.7. Label Syntax
The Unified ICM Label can be used to specify additional Route Select
1

functionality. Incorrect or incomplete Route Select data may result in the Avaya
denying the Route Selection and proceeding with vector processing.
A special label type to support the incorporation of dial-ahead digits into the
label is supported. The string DTMF within the label indicates the presence of
these dial-ahead digits. The format of this label type is as follows:
XXXXXDTMFYYYYY
The XXXXX is required and is the destination where the post-routed call will be
directed. YYYYY, maximum 16 digits (can include * and #), will be included as
dial-ahead digits when the route response is sent to the switch for the post-
routed call. This label type can be used for post-routed or translation-routed
calls. A label using this special label type cannot use any of the other special
label formatting capabilities listed in the following table. Peripheral Variables
can still be used.
Table 12: Label Identifiers and Capabilities
Label
Identifiers
Definition Example
! An exclamation point (!) at the
beginning of the label indicates that
Call Priority should be turned ON.
The default is Call Priority OFF.
(See Note 1.)
!1234 indicates that the call directed
to extension 1234 will have call priority
ON.
@

The at sign (@) at the beginning of
the label indicates that this should be
a DACD call. The call destination
must be an agents extension. The
default is No DACD call. (See Note
1.)
@2345 indicates that the call directed
to the agent at extension 2345 should be
a DACD call. Since no agent group or
agent group extension was specified in
this example, the PIM will attempt to
select the first known agent group login
for the agent. Both the agent and the
destination agent group must have been
previously known to the PIM for this to
be successful.
& The ampersand (&) used within the
Label is used to specify the Agent
Group Peripheral Number. The
Agent Group Peripheral Number
must immediately follow the
ampersand and must be configured
in Unified ICM software. The PIM
will determine the correct Agent
Group extension.
@2345 &11 indicates that the call
directed to the agent at extension 2345
should be a DACD call and the agents
group number is 11. Using the Agent
Group Peripheral number may be
convenient if the agent group extension
should ever change.

1
ICM 5.0 SR13 supports star (*) as a valid routing label for translation routing and post-
routing in ECS Avaya PIM. For example, *173001 is a valid routing label where *17
can be the Trunk Access Code and 3001 indicates the extension/VDN to which the call
would be directed. The post-route label containing the star (*) character should be
configured in Service explorer.
84 Post-Routing

# The pound sign (#) used within the
Label is used to specify the Agent
Group Extension number. The
Agent Group Extension must
immediately follow the pound sign.
The Agent must be a logged-in
member of that agent group.
@2345 #1000 indicates that the call
directed to the agent at extension 2345
should be a DACD call and the agents
agent group extension is 1000.

%1
%2
.
%10
The percent sign % at the
beginning of the label indicates that
the call destination is contained in
the specified Peripheral Variable
number.
(See Note 2.)
%1 indicates that the call destination
is contained in Peripheral Variable 1
(PV1). This is useful if you want to
specify the destination in the PVs or to
place CEDs in a PV as a destination.
Note 1: All Label Identifiers can be used together unless otherwise noted. Label Identifiers
designated to be at the beginning of the label cannot be preceded by any digits. For example,
!%1 indicates a Priority call to the agent specified in Peripheral Variable 1.
Note 2: Peripheral Variable 5 is reserved for User-User Information (UUI) only.

Route Select 85

85
87
5. Unified ICM Web Interaction
This chapter describes some special configuration issues relating to Trailhead/
Unified ICM configurations and the Avaya. Specifically, this chapter covers the
following topics:
Ensuring that Unified ICM software monitors the VDNs used for phantom
calls.
Ensuring that the VDNs used for predictive calls are not monitored by
Unified ICM software.
Configuring multiple Cisco Media Blender call types.
88 Unified ICM Web Interaction

5.1. Monitoring VDNs Used for Phantom Calls
Unified ICM software must monitor the phantom lines used with Media
Blender. If they are not monitored, when the Avaya PG is first started, the first
call on each phantom line is not assigned to Media Blender or the Unified WIM.
To ensure that Unified ICM software monitors the phantom lines, add the
instrument IDs of all phantom lines to Unified ICM Peripheral Monitor table:
1. From the Administration & Data Server, click the Configure ICM icon in
the Administration & Data Server Group.
2. Choose Peripherals > Peripheral Monitor. The Peripheral Monitor
window appears.
3. Click the Insert button to add the phantom instrument IDs. The Peripheral
Monitor Configuration window appears:

Figure 33: Peripheral Monitor Configuration
4. Update the Peripheral Monitor Configuration screen as follows:
Peripheral. Select the appropriate peripheral.
Extension or Param String. To enter one phantom line, type the
instrument ID in the Extension field. To add multiple phantoms, enter
the range of instrument IDs in the Param String field using a hyphen for
a delimiter (for example, 24698-24699).
Type. Choose Station.
5. Click Done. The phantom lines are added to the monitor table.
5.2. VDNs Used for Predictive Calls
By default, Unified ICM script monitors all VDNs configured as Peripheral
Targets in Unified ICM database. When using phantom calling on the Avaya,
this is the desirable behavior. Be aware, however, that on the Avaya, predictive
calls cannot be placed by a VDN that is being monitored.
You must therefore ensure that the VDNs set up to place predictive calls are not
monitored by Unified ICM software. This requires configuration changes in
Unified ICM software as well as the Avaya:
In Unified ICM Software:
When creating Peripheral Targets for predictive calls, ensure that the DNIS
entered in the Peripheral Target window is not the actual VDN you want to
Configuring Multiple CMB Call Types 89

89
place the predictive call. Instead, specify the VDN that will place the call in the
label associated with the Peripheral Target.
Consider the following example:

Figure 34: Peripheral Target Configuration
The value in the DNIS field here (6002) will be monitored by Unified ICM
script. Therefore, this should not be the routing address you use when creating
labels. Instead, the label should contain the VDN that will be used on the Avaya
to place predictive calls, in this case 6900.
On Avaya:
For predictive calls, you must maintain two VDNs: one that can be monitored
by Unified ICM script, but will not place the call, and another to actually place
the predictive call.
5.3. Configuring Multiple CMB Call Types
You can configure CMB to recognize requests for different call types. Based on
information from the callback form submitted by the caller, Media Blender can
determine the type of call (PSTN, chat ,and so on) placed by the caller. Media
Blender uses the call type to determine the CTI strategy that should be used to
place a return call to the customer.
Important: Do not confuse the CMB call types with the call type used in Unified ICM.
Unified ICM call types are simply combinations of the DN, CED, and ANI, used
to select scripts.
If you are using only one call type, you need only establish a call back strategy
using the ctistrategy property in ACD.ciscocti.properties.
Using multiple call types, however, requires additional configuration:
On Avaya:
Maintain separate VDNs for predictive and phantom calls.

On the Trailhead Server:
For more information on creating entry points and queues, see the Cisco Unified
Interaction Manager System Administration Guide available at:
http://www.cisco.com/en/US/products/ps7233/prod_maintenance_guides_list.ht
ml.
On the Media Blender Server:
Set up a file called a call type table on the Media Blender server. The call type
table maps different call types to predictive or phantom CTI strategies used
when placing the outbound call to the caller. (See the Cisco Media Blender
Configuration Handbook for more information.)
In Unified ICM Software:
You must ensure that Unified ICM script evaluates the value entered in the call
type field on the callback form. The script should then route the call to the
appropriate peripheral target.

Index-1

91
Index
A
ACD IN/OUT, 70
ACD number, 39
ACM Agent ID, 70
ACM agent states, 70
ACM ECS type, 39
ACM Skill Group Extension, 63
ACM Skill Group Number, 63
ACW [IN/OUT], 70
Agent
configuration, 70
login events, 37
mapping, 70
skill pairs, 38
state derivation, 70
Agent Peripheral Number, 70
Agent Skill Group Half Hour, 67
Agent states, 70
ASAI Station configuration, 37
AUX [IN/OUT], 70
Avail, 71
Available, 71
Available Hold Off Delay, 69
B
Busy Hour Call Rate (BHCR), 34
Ethernet ASAI, 15
C
Call Control Variable Map field, 47, 77
Call ID, 76
Call Management System (CMS), 13
configuring high availability, 42
minimum refresh rate, 38
reports
multiple, 38
Call Priority, 76, 80
Call treatment, 62
Call types, 87
Called Number, 76
Caller-Entered Digits (CED), 76
Calling Line ID (CLID), 76
Calling Number, 76, 78
CallPriorityLevel, 78
CED, 78
CMS. See Call Management System.
CMS-less installation, 14
CMS-less PG, 73
CMS-less requirements, 15
Configuration maintenance, 73
Creating Station Records, 26
CTI Client, 48
D
DACD, 35, 70
DACW, 70
Default login skill level, 49
Default work-mode, 48
Defining Hunt Group for Agents, 25
Dialed Number Identification Service
(DNIS), 76
Digit collection, 76, 80
Digit Collection/Dial Ahead, 80
DNIS, 78
E
Enterprise CTI interface, 39
Establishing ASAI/CTI link, 22
Event Minimization, 15, 37, 39
Expert Agent Selection, 13
H
Hardware requirements, 15
Hunt group, 54
Hunt Group Extension, 54
I
ICM
Peripheral Service Level, 62
Skill Group Extension, 63
Skill Group Peripheral Number, 63
ICM agent states, 70
ICM feature support, 17
II-digits, 76, 78
Inbound ACD calls, 20
Interflow type, 76
InterflowType, 78
Internal Target, 54
L
Label syntax, 81
Logged_Off, 71
Logged_On, 71
M
Measured field, 65
Media Blender, 86, 87
Monitored splits, 20

N
Network Target, 54
Noskillnum flag, 38
O
Other, 71
P
Peripheral
Default skill group mask, 46
Peripheral configuration parameters, 48
Peripheral Configuration window, 48
Peripheral Interface Manager (PIM), 14, 47
Peripheral Monitor Configuration window,
86
Peripheral Monitor table, 55
Peripheral object mapping, 46
Peripheral Service Level, 62
Peripheral Target, 54
Peripheral variables, 76, 78
PG LAN information, 39
Phantom lines, 86
PIM. See Peripheral Interface Manager.
Post-Routing, 75
Predictive calls, 86
Priorities, 64
R
Ready, 71
Real-time adherence (RTA) reports, 13
Refresh rate, 39
Registry Keys, 73
Reserved agent preference levels, 49
Ringing, 71
Route, 72
Route request, 76
Route request elements, 78
Route Select
peripheral variable map, 80
RouteSelect, 79
Routing Client, 72, 75
S
Service, 62
Peripheral Number, 62
Service-to-skill group mapping, 69
Set SubGroup Mask window, 46
Setting up Hunt Groups, 23
Skill group, 63
members, 71
Skill Group, 64
Skill Group Extension, 63
Skill Group Half Hour, 67
Skill group mapping, 63
Skill Group Peripheral Number, 63
Skillnums argument, 37
Software requirements, 15
Splits
to monitor, 39
Station monitoring, 55
of logged-in agents, 49
Sub-skill groups, 64
T
TalkingIn, 71
TalkingOther, 71
TalkingOut, 71
TEI value, 20
Termination Call Detail, 67
Third-Party Domain Control (3PDC), 15, 39
Time in queue, 76
Timed ACW value, 55
TimeInQBeforeInterflow, 78
Timestamp, 38
Trailhead, 85
Translation routes, 72
Trunk Access Code, 80, 81
Trunk Group, 61
Trunk Group Extension, 61
Trunk group number, 76
Trunk Information, 78
Trunk number, 76
Trunks, 62
U
Universal Call ID (UCID), 37
UNIX timestamp, 38
Unknown, 71
Use encoded trunk information over ANI in
calling field, 50
User-User Information, 76, 78, 80, 81
Using Skill Group Priorities without
Configuring Sub-skill Groups, 65
V
VDN, 78, See Vector Directory Number
VDN Service Level, 62
Vector, 62
Vector Directory Number (VDN), 54, 62, 76
inbound ACD calls, 20
Vector writers, 76
W
Web integration, 85
WrapUp, 71

August 2011

Uploaded by

Copyright:

Available Formats

August 2011

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

August 2011

Uploaded by

Copyright:

Available Formats

August 2011

A CMS-less version of the PG is available; however, certain restrictions apply. See

Logged_In and Logged_Out are not CMS agent states

You might also like