CMS Dual

Avaya Solution & Interoperability Test Lab
How to Configure and Utilize the High Availability and

Survivable Offers of Avaya Call Management System with
Avaya Communication Manager – Issue 1.0
Abstract
These Application Notes describe how to configure and utilize Avaya Call Management
System (CMS) R13.1 with the Survivable Server offers of Avaya Communication Manager
3.1 in a High Availability and Survivable (Dual) Avaya CMS configuration. The Dual CMS
configuration provides redundancy and continuous call data collection during periods of WAN
failover.
CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 1 of 40

SPOC 11/15/2006 ©2006 Avaya Inc. All Rights Reserved. CMS_Dual.doc
1. Introduction
Important considerations for an enterprise design are its robustness and ability for the enterprise
to recover from disasters and events that disrupt normal business operation. An enterprise may
have a main data center location controlling the entire enterprise and a duplicate backup data
center location serving as a “hot standby” to provide redundancy. The main and backup data
centers are interconnected via the WAN as well as other locations with enterprise resources.
Avaya Communication Manager provides enterprise communications with configuration options
for failover and survivability using multiple and distributed Media Servers. During normal
operation, Avaya Communication Manager runs on a pair of redundant Media Servers that
handle call processing for the entire enterprise. These designated main Media Servers are
located in the main data center. The Enterprise Survivable Server (ESS) and Local Survivable
Processor (LSP) are Survivable Server offers of Avaya Communication Manager. A redundant
pair of Media Servers configured as an ESS provides call processing failover for all or a portion
of the enterprise when the main Media Servers are unavailable. The ESS Media Servers are
located in the backup data center. A Media Server configured as an LSP, provides local or
regional call processing capability only when the ESS Media Servers and main Media Servers
are unavailable. An LSP Media Server may be located at any location that requires survivability
in case a WAN failure prohibits connectivity to either data center location.
For enterprises that have contact centers, Avaya Call Management System (CMS) is an integral
part that provides real-time and historical reporting on the Automatic Call Distribution (ACD)
performance of the contact centers. CMS also provides supervisors the ability to perform contact
center administration. CMS receives real-time ACD call data from the main Media Servers. The
Media Servers utilize a C-LAN board to establish a Management Information System (MIS)
communication-interface link (also referred to as a CMS link) between Avaya Communication
Manager and CMS. Multiple and distributed Avaya CMS servers integrated with the ESS and
LSP offers of Avaya Communication Manager provide the ability for ACD call data redundancy
and CMS survivability.
1.1. High Availability Call Management System

For CMS operation and ACD call data redundancy, an enterprise can have two separate CMS
servers (Primary and Secondary) that collect data independently from the main Media Servers,
referred to as the High Availability (HA) CMS offer. Both HA CMS receive the exact same data
from the main Media Servers utilizing different C-LAN boards for separate MIS communication-
interface links. If one HA CMS experiences a failure, the other HA CMS continues to receive
ACD call data and provide contact center administration for CMS operation redundancy. When
the failed HA CMS becomes operational again, ACD call data and CMS administrative data for
the period of the failure are copied from the other HA CMS in order to restore historical data
redundancy.
If the Primary and Secondary HA CMS were to be split between the main and backup data
centers, the Secondary CMS would utilize a C-LAN board in Media Gateway located in the
backup data center to establish the MIS communication-interface link to Avaya Communication
Manager. During normal operation, the Media Gateways at the main and backup data center
locations are controlled by the main Media Servers (main data center). However, during a WAN

failure between the main and backup data center locations, the HA CMS servers would receive a
different subset of ACD call data. The main data center location with the Primary HA CMS
would receive ACD call data from the main Media Servers, and the backup data center location
with the Secondary HA CMS would receive different ACD call data from the active ESS Media
Servers. The active ESS inherits the MIS link configuration from the main Media Servers and
establishes a CMS Link utilizing the local Media Gateway (with a C-LAN board) to send ACD
call data to the local Secondary HA CMS.
After the WAN failure, the HA CMS pair would have two sets of historical ACD call data.
Therefore, a need exists for the aggregation of the two different set of ACD call data onto the
Primary CMS. The aggregated ACD call data would have to be copied to the Secondary CMS
for historical ACD call data redundancy.
1.2. Survivable Call Management System

Avaya Communication Manager Release 3.1 introduced the capability to configure the active
ESS or LSP to inherit the MIS link configuration from the main Media Servers, or to overwrite it
with different parameters that establish a new MIS link to a local Survivable CMS. A location
with an ESS with a S8700 Series Media Server pair utilizes a C-LAN and a unique CMS IP
address to establish a MIS link between Avaya Communication Manager and the local
Survivable CMS. Similarly, a location with an ESS or LSP with a S8500 or S8300 Media Server
utilizes the Media Server’s Processor Ethernet and a unique CMS IP address to establish a MIS
link between Avaya Communication Manager and another local Survivable CMS.
Note: Before Avaya Communication Manager Release 3.1, the MIS communication-interface
link configuration was static and therefore did not allow the ESS or LSP to send ACD
call data to a different CMS during failover periods.
During normal operation, the Survivable CMS operates in a “standby mode” and only collects
ACD call data during a failover from the surviving environment controlled by the active ESS or
LSP. Any ACD call data collected by the Survivable CMS during the failover would need to be
combined with all other CMS that may be located elsewhere in the enterprise. For this reason,
the Avaya Communication Solutions and Integrations (CSI) team provides a new version of an
add-on software package called Admin-Sync available with Avaya CMS R13.1. The new
version of Admin-Sync now allows the aggregation of call data collected during the failover
from multiple Survivable CMS throughout the enterprise into the Primary CMS providing
complete ACD call data records for the entire enterprise.
1.3. Dual Call Management System

With Avaya Communication Manager 3.1 and the new version of Admin-Sync available with
Avaya CMS R13.1, it is now possible to combine the roles of the Survivable CMS and the
Secondary HA CMS together to function as the Dual “role” CMS. The Primary HA CMS
resides in the main data center location and the Secondary Dual CMS resides in the backup data
center location. During normal operation, both the Primary HA CMS and the Secondary Dual
CMS receive the exact same data from the main Media Servers utilizing different C-LAN boards
for separate MIS communication-interface (i.e. normal HA operation). If a WAN failure occurs
between the main and backup data center locations, the Primary HA CMS would receive a

different set of ACD call data than the Secondary Dual CMS operating in survivable mode. The
active ESS inherits the MIS link configuration from the main Media Servers and establishes a
CMS Link utilizing the local Media Gateway to send ACD call data to a local Secondary Dual
CMS. The Primary HA CMS would receive ACD call data from the main Media Servers that
control the Media Gateways in the main data center location, and the Secondary Dual CMS
would receive ACD call data from the active ESS Media Servers that control the local Media
Gateways in the backup data center location.
After the return to normal operations, the ACD call data collected by the Secondary Dual CMS,
and other Survivable CMS in the enterprise, will be aggregated onto the Primary HA CMS using
the new version of Admin-Sync software provided by the Avaya CSI team. The same Admin-
sync software is utilized on the Primary HA CMS to send (push) the updated ACD call data to
the Secondary Dual CMS in order to maintain and provide historical ACD call data redundancy.
If either the Primary HA CMS or Secondary Dual CMS experiences a failure (during normal
operation), the other will continue to receive ACD call data and provide contact center
administration for CMS operation redundancy. When the failed system becomes operational
again, the ACD call data and CMS administrative data for that period is copied from one system
to the other in order to restore historical data redundancy (i.e. normal HA operation).
The Secondary Dual CMS has the following provision requirements:

• The MIS link for the Secondary Dual CMS must have its MIS link connected via a C-
LAN board in a G650 Media Gateway or Port Network.
• Since LSP does not support Port Network connectivity or G650 Media Gateways, only an
ESS can provide a MIS link to the Secondary Dual CMS in survivable mode.
• The Secondary Dual CMS, the ESS and the G650 Media Gateway or Port Network must
reside in the same physical location.
• The same C-LAN board is utilized for the CMS link during survivable mode as in normal
operation (the ESS inherits the MIS link configuration from the main Media Servers).
These Application Notes cover the following topics:

1. The configuration of Avaya Communication Manager in an ESS environment supporting
a co-located Secondary Dual CMS.
2. The configuration of Avaya Communication Manager in a LSP environment supporting a
co-located Survivable CMS.
3. Steps performed by the Avaya CSI team for implementation of the Avaya Dual CMS
solution.
4. Steps to verify the Avaya Dual CMS solution, including call data integrity and restoration
after a failover.
Note: These Application Notes assume the pre-existing configuration of an Avaya CMS (non-
HA) that collects ACD call data for the entire enterprise.

1.4. Reference Network Configuration
The configuration depicted in Figure 1 is utilized to verify these Application Notes. Figure 1
represents an enterprise with contact center (single ACD) in multiple locations. The Main Office
is the main data center location for the enterprise, which also serves as a main contact center
location. The Main Office contains a redundant Avaya S8720 Media Server pair (main), an
Avaya G650 Media Gateway and an Avaya Primary HA CMS. Site 2 is the backup data center
location for the enterprise, which also serves as a contact center. Site 2 contains an Avaya ESS
S8710 Media Server pair, an Avaya G650 Media Gateway, and an Avaya Secondary Dual CMS.
Site 3 is a smaller contact center location with survivability requirements. Site 3 contains an
Avaya G350 Media Gateway with an Avaya LSP S8500 Media Server and an Avaya Survivable
CMS. All Media Gateways and IP endpoints (not shown in Figure 1) register to the C-LANs
located in the Main Office G650 Media Gateway. Each site has Public Switched Telephone
Network (PSTN) assess via Time Division Multiplexed (TDM) trunks and private WAN access.
Figure 1: Reference Network Configuration (Sunny Day Scenario)
1.5. Operation Scenarios

The following are the various operation scenarios for the sample configuration covered in these
Application Notes.

1.5.1. Normal Operation – Sunny Day Scenario
During normal operation, the active Main Office S8720 Media Server controls all Media
Gateways enterprise wide. The Main Office Primary HA CMS has an established and active
CMS link via the C-LAN in the Main Office as shown in Figure 1. The Main Office Primary
HA CMS collects ACD call data for the entire enterprise. CMS Supervisors at every location
utilize the Main Office Primary HA CMS for real-time and historical reporting, including contact
center administration.
Note: An established CMS link refers to an operational but idle MIS communication-interface
link. An active CMS link refers to the transmission of ACD call data sent to the CMS
from Avaya Communication Manager in real-time.
At Site 2 Secondary Dual CMS has an established and active CMS link via the C-LAN in the
Site 2 Media Gateway as shown in Figure 1. The Site 2 Secondary Dual CMS collects ACD call
data for the entire enterprise. CMS Supervisors at every location can also utilize the Site 2
Secondary Dual CMS for real-time and historical reporting, including contact center
administration. The ESS contains the MIS communication-interface link configuration inherited
from the main Media Servers to establish the CMS links between the Site 2 Secondary Dual
CMS and either the C-LAN located in the Site 2 and/or Main Office Media Gateway upon
failover.
At Site 3, the Survivable CMS is in “standby mode”. It has an established but not active CMS
link as shown in Figure 1. The LSP Media Server contains a Processor Ethernet that remains
active regardless of the operating mode (standby or active). Therefore, the Site 3 Survivable
CMS maintains an established CMS link to the LSP Media Server. However, since the LSP
Media Server is in “standby mode”, it does not control the Site 3 Media Gateway. The Site 3
LSP Media Server does not have any ACD call data to send to the Site 3 Survivable CMS.
CMS administrative data, such as Supervisor logins, Custom and Designer Reports, VDN and
Skill Call Profiles, and permissions are synchronized automatically between all CMS in the
enterprise thru the use of the Avaya CSI Admin-Sync software. The Admin-Sync software
package has an automated process for the synchronization of CMS administrative data that runs
on daily basis. It eliminates the need for CMS administrators to make the same changes to each
CMS in the enterprise and provides uniform access for CMS Supervisors.
1.5.2. Failover Operation - WAN Failure Scenario

A WAN failure affects network connectivity between locations within the enterprise. This
scenario assumes a core WAN failure that affects network connectivity to each location as shown
in Figure 2. The following happens at each location when the WAN failure occurs:
Main Office – The (main) Media Server continues to control the Main Office Media Gateway
and the CMS link to the Main Office Primary HA CMS remains in service collecting ACD call
data for the Main Office location only. The CMS Supervisors at the Main Office remain logged
into the Main Office Primary HA CMS. The CMS Supervisors running Real-time Skill Status
report will notice that the ACD agents from Site 2 and Site 3 have dropped off the report. A
CMS Supervisor may also observe a drop in calls in queue (assuming calls were queuing) if the
incoming ACD calls utilized the trunks at Site 2 or Site 3. CMS Supervisors continue to use the

Main Office Primary HA CMS to perform reporting and contact center administration for the
Main Office only.
Site 2 – The Site 2 Media Gateway looses connectivity to the active Media Server at the Main
Office. Incoming calls and calls in progress fail (on trunks at Site 2 and/or Site 4). The Media
Gateway Controller (MGC) contains a list of alternate sources for registration and control. The
MGC configuration in the Site 2 Media Gateway has the ESS Media Servers as the first alternate
and begins to register to the active ESS Media Server for control. The Secondary Dual CMS link
drops and then becomes established and active again after the Media Gateway registers to the
ESS Media Server, as shown in Figure 2.
When the WAN failure first occurs, the CMS Supervisors at Site 2 who are logged into the
Secondary Dual CMS remained connected. However, the CMS Supervisors who are logged into
the Primary HA CMS at the Main Office receive an error message because they have lost
connectivity with the Main Office and (as instructed by the CMS Administrator) would know to
now log into the Secondary Dual CMS. All CMS Supervisors at Site 2 must wait several
minutes for the ESS Media Server to become active. ACD agents must log in again to receive
ACD calls. CMS Supervisors use the Secondary Dual CMS to perform real-time reporting and
contact center administration (for Site 2 only).
While it is possible to make (Avaya Communication Manager) administration changes on an
ESS during failover, these changes will not persist after return to normal operations (i.e. when
control is reverted to the main Media Server at the Main Office). This is also true for
administration changes (i.e. Vector, VDNS, Agent Skill Profiles, etc.) performed on the
Secondary Dual CMS only during the period when the active ESS is controlling the Site 2 Media
Gateway.
Note: The ESS is set up to take over control of all available resources during an outage. Which
resources the ESS controls depends on the network connectivity. The Secondary Dual
CMS would collect only ACD call data received from the ESS during the outage.
Site 3 - The Site 3 Media Gateway looses connectivity to the active main Media Server at the
Main Office. Only the calls in progress from the PSTN (utilizing the Site 3 TDM trunks)
directly to Site 3 agents will remain connected since the Site 3 Media Gateway supports call
preservation. The MGC configuration in the Site 3 Media Gateway has the ESS Media Servers
as the first alternate source for registration and control. However, network connectivity between
Site 2 and Site 3 is not available and the Media Gateway utilizes the second alternate, the local
LSP Media Server, for registration and control. The Survivable CMS link becomes active once
the local Media Gateway registers to the LSP Media Server as shown in Figure 2.
When the WAN failure first occurs, the CMS Supervisors at Site 3 receive an error message
because they have lost connectivity with the Primary HA CMS at the Main Office. The CMS
Supervisors (as instructed by the CMS administrator) know to now log into the Secondary Dual
CMS at Site 2, but fail to connect due to the WAN failure. Then, the CMS Supervisors at Site 3
log into the local Survivable CMS and wait several minutes for the LSP Media Server to become
active. ACD agents must log in again to receive ACD calls. CMS Supervisors use the
Survivable CMS to perform reporting and contact center administration (for Site 3 only).
While it is possible to make (Avaya Communication Manager) administration changes on an
LSP during failover, these changes will not persist after return to normal operations (i.e. when

control is reverted to the main Media Server at the Main Office). This is also true for the
Survivable CMS (i.e. administrative changes made to any Survivable CMS will not persist).
Figure 2: WAN Failure Scenario
1.5.3. Returning to Normal Operation and Performing ACD Call Data

Aggregation and Recovery
When call processing control is reverted to the main S8720 Media Servers at the Main Office,
the following occurs:
• The Secondary Dual CMS link drops and then becomes established and active after the
Media Gateway at Site 2 registers to the main Media Servers at the Main Office. CMS
Supervisors at Site 2 can log off the Secondary Dual CMS or remained logged in and
resume normal operations. The ACD agents must log in again to receive ACD calls.
Normal Primary HA CMS and Secondary Dual CMS operation resumes.
• The Survivable CMS at Site 3 will cease to collect ACD call data and return to “standby
mode”. CMS Supervisors at Site 3 log off the Survivable CMS, log into the Primary HA
CMS at the Main Office, and resume normal operations. The ACD agents must log in
again to receive ACD calls.

The ACD call data that was collected during the period of segmentation (due to the WAN
failure) by each CMS (Primary, Secondary, and Survivable), must be aggregated together and
restored to both the Primary HA CMS at the Main Office and Secondary Dual CMS at Site 2 as
shown in Figure 3. In order to aggregate the collected data, CMS Administrators must manually
run the data aggregation and restoration tool using the Admin-Sync software package provided
by the Avaya CSI team. Only the CMS interval data will be aggregated onto the Primary HA
CMS. The CMS interval is a configurable period where at the end real-time collected ACD call
data becomes historical ACD call data. The ACD call data collected by the Survivable CMS will
remain on that Survivable CMS and will aged off (Interval Æ Daily Æ Weekly Æ Monthly)
during normal CMS archiving processes.
After the aggregation and restoration of ACD call data onto the Primary HA CMS and
Secondary Dual CMS, CMS Supervisors will have access to historical reports for the entire
enterprise on both CMS servers. The aggregated and restored ACD call data will include the
WAN failover period, except for the following:
• The partial CMS interval at the beginning of a WAN failure when the ESS assumes
control of Media Gateway with the dedicated C-LAN board.
• The partial CMS interval when normal operation is restored when the main Media Server
reassumes control of the same Media Gateway.
Note: Only the ACD call data collected by the Primary HA CMS for the CMS intervals
mentioned above will be kept which results in some ACD call data loss for the enterprise.
The aggregated ACD call data permanently replaces the collected ACD call data on both
the Primary HA CMS and Secondary Dual CMS.

Figure 3: Call Data Recovery

2. Equipment and Software Validated
The following equipment and software were used for the sample configuration provided:
Equipment – Main Office Software
Avaya S8720 Media Server Avaya Communication Manager
3.1.2 (R013x.01.2.632.1)
Avaya G650 Media Gateway (2)
• Avaya TN2312BP IPSI Circuit Packs (2) HW 12 FW 031
• Avaya TN779DP C-LAN Circuit Packs (4) HW 01 FW 017
• Avaya TN2602AP Circuit Pack HW 02 FW 024
• Avaya TN2501AP VAL Circuit Pack HW 02 FW 010
• Avaya TN646HP Circuit Packs (4) HW 02 FW 018
Avaya Converged Stackable Switch C363T-PWR 4.5.14
Avaya Call Management System (CMS) 13.1 (r13.1auxcb.e)
• Sun Blade 150 Workstation Solaris OS V9
• Admin-Sync Software Package Version 5.1.1
Cisco 6506 Switch Router 12.4(5)
Cisco 2950 Switch (2) 12.4(5)
Cisco 3725 Router 12.4(5)
Table 1: Main Office
Equipment Software
Avaya S8710 Media Server Avaya Communication Manager
Enterprise Survivable Server (ESS) 3.1.2 (R013x.01.2.632.1)
Avaya G650 Media Gateway
• Avaya TN2312BP IPSI Circuit Pack HW 12 FW 031
• Avaya TN779DP C-LAN Circuit Pack (3) HW 01 FW 017
• Avaya TN2602AP Circuit Pack HW 02 FW 024
• Avaya TN2501AP VAL Circuit Pack HW 02 FW 010
• Avaya TN464HP Circuit Packs (2) HW 02 FW 018
• Sun Blade 150 Workstation Solaris OS V9
Avaya Converged Stackable Switch C363T-PWR 4.5.14
Table 2: Site 2

Equipment Software
Avaya S8500 Media Server (LSP) Avaya Communication Manager
3.1.2 (R013x.01.2.632.1)
Avaya G350 Media Gateway Version 25.28.0
• MM712 – DCP Media Module Vintage 5 Version 7
• MM710 (2) – T1/E1 Media Module Vintage 5 Version 15
• ANALOG – Integrated Analog 1T + 2L Version 68
Module n/a
• MM340 – WAN Routing Media Module n/a
• MM314 – PoE Expansion Media Module
• Sun Netra 210 Server Solaris OS V9
Table 3: Site 3
Equipment Software
Avaya Call Center 3.1
Avaya Call Management System Supervisor R13.1 (Build HC.06)
Avaya Call Management System Supervisor Terminal R13.0 (Build HC.06)
Emulator
Avaya Terminals
• Avaya 4600 Series IP Telephones 2.3 (2.5 for 4625 )
• Avaya DCP 2420 Telephones
• Avaya 6211 Analog Telephones
Cisco 3845 WAN Router 12.4(5)
Table 4: Common Use Equipment and Software

3. Configure Avaya Communication Manager
These Application Notes assume the completed administration of the equipment in Table 1
through Table 4, except for the configuration parameters required for the following:
• Site 2 - the MIS communication-interface link to the Secondary Dual CMS at Site 2
utilizing a dedicated C-LAN board in the local Media Gateway
• Site 3 - the MIS communication-interface link to the Survivable CMS at Site 3 utilizing
the Processor Ethernet on the local LSP Media Server
Note: It is assumed that the (non HA) CMS at the Main Office is pre-existing including the
administration for the MIS communication-interface link utilizing a dedicated C-LAN
board in the local Media Gateway.
The following Sections 3.1 & 3.2 detail systematic instructions on how to administer the
required configuration parameters for the exceptions mentioned above.
3.1. Avaya Communication Manager Administration for Site 2 ESS

Media Server with Secondary Dual CMS
All commands were entered on an Avaya Communication Manager System Access Terminal
(SAT) connected to the active Media Server at the Main Office. Use a login and password with
the appropriate access permissions.
Step Description
1. Issue the command “display system-parameters features” to display the feature-related
system parameters. On Page 12, verify that the “Reporting Adjunct Release” field is set
to “R13.1” in order to support Dual CMS.
display system-parameters features Page 12 of 17

FEATURE-RELATED SYSTEM PARAMETERS
AGENT AND CALL SELECTION

MIA Across Splits or Skills? n
ACW Agents Considered Idle? y
Call Selection Measurement: predicted-wait-time
Service Level Supervisor Call Selection Override? n
Auto Reserve Agents: all
ASAI
Copy ASAI UUI During Conference/Transfer? y
Call Classification After Answer Supervision? y
Send UCID to ASAI? y
CALL MANAGEMENT SYSTEM
Reporting Adjunct Release: R13.1
BCMS/VuStats LoginIDs? y
BCMS/VuStats Measurement Interval: hour
BCMS/VuStats Abandon Call Timer (seconds):
Validate BCMS/VuStats Login IDs? n
Clear VuStats Shift Data: on-login
Remove Inactive BCMS/VuStats Agents? n

Step Description
2. Issue the command “change node-names ip” to administer node names and IP addresses
for the dedicated C-LAN resource and Secondary Dual CMS at Site 2. Enter a descriptive
name in the “Name” column and the IP Address in the “IP Address” column. In this case,
“clan-2a10-cms2” and “10.2.1.21” are entered for the dedicated C-LAN resource, and “sa-
cms2” and “10.2.1.53” are entered for the Secondary Dual CMS. Submit these changes.
change node-names ip Page 1 of 1
IP NODE NAMES
Name IP Address Name IP Address
clan-1a02 10 .1 .2 .21 clan-2a10-cms2 10 .2 .1 .21
clan-1a09 10 .1 .2 .29 sa-cms2 10 .2 .1 .53
clan-1a10-cms1 10 .1 .1 .21 . . .
clan-1b02 10 .1 .2 .25 . . .
clan-2a02 10 .2 .2 .21 . . .
clan-2a09 10 .2 .2 .29 . . .
clan-trading 5 .1 .1 .4 . . .
default 0 .0 .0 .0 . . .
g150 10 .20 .16 .10 . . .
g700-hong 172.16 .255.20 . . .
icg1 10 .2 .2 .131 . . .
medpro-1a03 10 .1 .2 .22 . . .
medpro-1b03 10 .1 .2 .26 . . .
medpro-2a03 10 .2 .2 .22 . . .
procr 10 .1 .2 .11 . . .
sa-cms 10 .1 .1 .53 . . .
( 16 of 33 administered node-names were displayed )
Use 'list node-names' command to see all the administered node-names
Use 'change node-names ip xxx' to change a node-name 'xxx' or add a node-name

Step Description
3. Issue the command “add ip-interface c”, where c = “02a10” in this case, and is the
available slot number for the new C-LAN board. The required parameters are specific to
the configuration in Figure 1 and are shown below:
1. Enter the IP Node Name assigned to the C-LAN board from Step 2 in the “Node
Name” field.
2. Set the appropriate subnet mask in the “Subnet Mask” field.
3. Set the default gateway in the “Gateway Address” field.
4. Set the “Enable Ethernet Port” field to “y”.
5. Set the IP network region number in the “Network Region” field.
6. Set the VLAN number (if unique VLANs have been assigned) in the “VLAN” field.
7. Set the “Allow H.323 Endpoints” field to “n” to disallow this C-LAN board as a
H.323 registration resource.
8. Set the “Allow H.248 Gateways” field to “n” to disallow this C-LAN board as
resource for media gateway registration.
9. Set the “Auto?” field to “y” to allow the C-LAN board to auto negotiate Ethernet
port settings with the CMS.
10. Submit the changes
add ip-interface 02a10 Page 1 of 1
IP INTERFACES
Type: C-LAN
Slot: 02A10
Code/Suffix: TN799 D
Node Name: clan-2a10-cms2
IP Address: 10 .2 .1 .21
Subnet Mask: 255.255.255.0 Link:
Gateway Address: 10 .2 .1 .1
Enable Ethernet Port? y Allow H.323 Endpoints? n
Network Region: 1 Allow H.248 Gateways? n
VLAN: 1
Target socket load and Warning level: 400

Receive Buffer TCP Window Size: 8320
ETHERNET OPTIONS
Auto? y

Step Description
4. Issue the command “add data-module ext”, where ext is an available extension for the
Ethernet data module.
1. Enter “ethernet” in the “Type” field.
2. Enter “02a1017” in the “Port” field for the Ethernet Port of the new C-LAN board
assigned in step 3.
3. Enter an available link number for the “Link” field. In this case, “9” is entered as
an available link number.
4. Enter a descriptive name for the Ethernet data module in the “Name” field. In this
case, “clan-2a10-cms2” is entered (does not have to match the name entered in step
2).
5. Submit the changes.
add data-module 4340009
DATA MODULE
Data Extension: 4340009 Name: clan-2a10-cms2

Type: ethernet
Port: 02a1017
Link: 9
Network uses 1's for Broadcast Addresses? y

Step Description
5. Issue the command “change communication-interface processor-channels” to assign a
MIS communication-interface link for the Secondary Dual CMS.
1. Set the “Enable” field to “y” to enable this processor channel on the main S8720
Media Servers at the Main Office.
2. Set the “Appl.” field to “mis” for a CMS adjunct connection.
3. Set the “Mode” field to “s” to run an active (server) IP session.
4. Set the “Interface Link” field to the C-LAN board link number “9” that was
assigned in Step 4.
5. Set the “Interface Chan” field to “5001”. The Interface Channel entry here must
match the “switch TCP port number” in the Site 2 Secondary Dual CMS software
configuration described in Section 4. The Interface Channel number may be
different from the entry for Processor Channel 1 (Primary HA CMS link).
6. Set the “Destination Node” field to the IP Node Name “sa-cms2” assigned in Step
2 for the Site 2 Secondary Dual CMS.
7. Set the “Destination Port” field to “0” to indicate that any destination port may be
used.
8. Set the “Session Local” and “Session Remote” port number equal to the “Proc
Chan” number (in this case “2”). The port number assigned here must match the
“local port” and “remote port” in the Site 2 Secondary Dual CMS software
configuration described in Section 4.
9. Submit these changes.
change communication-interface processor-channels Page 1 of 24
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session
Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
1: y mis s 8 5001 sa-cms 0 1 1
2: y mis s 9 5001 sa-cms2 0 2 2
6. Issue the command “list survivable-processor” to reference the configured Survivable

Processor names and information. Note the name “cc-ess1” and “cc-ess2” for the Site 2
ESS Survivable Processors.
list survivable-processor
SURVIVABLE PROCESSORS
Name Type IP Address Reg LSP Translations Net
Act Updated Rgn
cc-ess1 ESS 10 .2 .2 .11 y 11:22 8/3/2006 1

cc-ess2 ESS 10 .2 .2 .12 n 11:22 8/3/2006 1
br3-elsp LSP 10 .14 .2 .9 y n 11:22 8/3/2006 4

Step Description
7. Issue the command “display survivable-processor x”, where x is the survivable processor
name. In this case, “cc-ess1” is the name for one of the ESS Media Servers at Site 2. The
fields are populated with the MIS communication-interface link information for the Primary
HA CMS and Secondary Dual CMS shown below. The “Enable” fields are set to “i” by
default, so that the MIS communication-interface link information for the Primary HA
CMS Link and Secondary Dual CMS Link are inherited by the Site 2 ESS Media Servers
when active. If the active ESS Media Server controls both the Site 2 Media Gateway and
the Main Office Media Gateway (depending on WAN connectivity), then this will allow for
the establishment of both CMS Links. If the WAN failure isolates Site 2 from the rest of
the enterprise, then this will allow for the establishment of the Secondary Dual CMS Link
(Processor Channel 2).
Note: Issuing the command above for the survivable processor name “cc-ess2” (the other
ESS S8710 Media Server at Site 2) will have identical MIS communication-interface link
information as shown below for survivable processor name “cc-ess1”.
display survivable-processor cc-ess1 Page 2 of 4
SURVIVABLE PROCESSOR - PROCESSOR CHANNELS
Proc Interface Destination Session

Chan Enable Appl. Mode Link/Chan Node Port Local/Remote
1 i mis s 8 5001 sa-cms 0 1 1
2 i mis s 9 5001 sa-cms2 0 2 2
8. Issue the command “save translation all” to save the changes and push the updated
translations to the ESS and LSP Media Servers.
save translation all
SAVE TRANSLATION
Command Completion Status Error Code
Success 0

3.2. Avaya Communication Manager Administration for Site 3 LSP
Media Server with Survivable CMS
All commands were entered on an Avaya Communication Manager System Access Terminal
(SAT) connected to the active Media Server at the Main Office. Use a login and password with
the appropriate access permissions.
Step Description
1. Issue the command “display system-parameters features” to display the feature-related
system parameters. On Page 12, verify that the “Reporting Adjunct Release” field is set
to “R13.1” in order to support Survivable CMS.
display system-parameters features Page 12 of 17
FEATURE-RELATED SYSTEM PARAMETERS
AGENT AND CALL SELECTION

MIA Across Splits or Skills? n
ACW Agents Considered Idle? y
Call Selection Measurement: predicted-wait-time
Service Level Supervisor Call Selection Override? n
Auto Reserve Agents: all
ASAI
Copy ASAI UUI During Conference/Transfer? y
Call Classification After Answer Supervision? y
Send UCID to ASAI? y
CALL MANAGEMENT SYSTEM
Reporting Adjunct Release: R13.1
BCMS/VuStats LoginIDs? y
BCMS/VuStats Measurement Interval: hour
BCMS/VuStats Abandon Call Timer (seconds):
Validate BCMS/VuStats Login IDs? n
Clear VuStats Shift Data: on-login
Remove Inactive BCMS/VuStats Agents? n

Step Description
2. Issue the command “change node-names ip” to administer node the name and IP address
for the Survivable CMS at Site 3. Enter a descriptive name in the “Name” column and the
IP Address in the “IP Address” column. In this case, “sa-cms3” and “10.14.1.53” are
entered for the Survivable CMS. Submit these changes.
change node-names ip Page 1 of 1
IP NODE NAMES
Name IP Address Name IP Address
default 0 .0 .0 .0 sa-cms3 10 .14 .1 .53
g150 10 .20 .16 .10 . . .
g700-hong 172.16 .255.20 . . .
icg1 10 .2 .2 .131 . . .
medpro-1a03 10 .1 .2 .22 . . .
medpro-1b03 10 .1 .2 .26 . . .
medpro-2a03 10 .2 .2 .22 . . .
procr 10 .1 .2 .11 . . .
sa-cms 10 .1 .1 .53 . . .
sa-cms2 10 .2 .1 .53 . . .
sa-ir 10 .1 .1 .54 . . .
val-01a06 10 .1 .2 .31 . . .
val-02a06 10 .2 .2 .31 . . .
. . . . . .
. . . . . .
. . . . . .
( 13 of 35 administered node-names were displayed )
Use 'list node-names' command to see all the administered node-names
Use 'change node-names ip xxx' to change a node-name 'xxx' or add a node-name
3. Issue the command “list survivable-processor” to reference the configured Survivable

Processor names and information. Note the name “br3-elsp” for the Site 3 LSP Survivable
Processor.
list survivable-processor
SURVIVABLE PROCESSORS
Name Type IP Address Reg LSP Translations Net
Act Updated Rgn
cc-ess1 ESS 10 .2 .2 .11 y 11:22 8/3/2006 1

cc-ess2 ESS 10 .2 .2 .12 n 11:22 8/3/2006 1
br3-elsp LSP 10 .14 .2 .9 y n 11:22 8/3/2006 4

Step Description
4. Issue the command “change survivable-processor x”, where x is survivable processor
name. In this case, “br3-elsp” is the name for the LSP Media Server at Site 3. The fields
are populated with the MIS communication-interface link information for the Primary HA
CMS and Secondary Dual CMS shown below in the Before changes screen.
change survivable-processor br3-elsp Page 2 of 4

1 i mis s 8 5001 sa-cms 0 1 1
2 i mis s 9 5001 sa-cms2 0 2 2
Before changes
Change the following fields for Processor Channel 2 as shown below in the After changes
screen. (The information for Processor Channel 1 is irrelevant to the active LSP)
1. Set the “Enable” field to “o” so that the MIS communication-interface link
information is over-written when software translations are sent to the Site 3 LSP
Media Server after executing the “save translation all” command (Step 5). This
will allow the establishment of the Site 3 Survivable CMS Link to the Processor
Ethernet of the LSP Media Server. The “Interface Link” field switches to “p”
automatically so that the LSP Media Server utilizes its Processor Ethernet
(emulating C-LAN) for the MIS communication-interface link.
2. Set the “Interface Chan” field to “5001”. The Interface Channel entry here must
match the “switch TCP port number” in the Site 3 Survivable CMS software
configuration described in Section 4. The Interface Channel number may be
different from the entries for the Primary HA CMS or Secondary Dual CMS shown
in the “Before changes” screen above.
3. Set the “Destination Node” field to the IP Node Name “sa-cms3” assigned in Step
2 for the Site 3 Survivable CMS.
4. Submit these changes.
Note: While the Survivable Processor screen is administered on the active main server, the
information entered applies only to the Site 3 LSP Media Servers. In addition, the standard
provisioning procedure is to set the “Session Local” and “Session Remote” port number
equal to the “Proc Chan” number (in this case “2”). The port number assigned here must
match the “local port” and “remote port” in the Site 3 Survivable CMS software
configuration described in Section 4.
change survivable-processor br3-elsp Page 2 of 3

1 i mis s 8 5001 sa-cms 0 1 1
2 o mis s p 5001 sa-cms3 0 2 2
After changes

Step Description
5. Issue the command “save translation all” to save the changes and push the updated
translations to the LSP and ESS Media Servers.
save translation all
SAVE TRANSLATION
Command Completion Status Error Code
Success 0

4. Avaya Call Management System Configuration
In order to implement and configure a Dual CMS solution, all CMS (new or existing) must be on
a consistent software release of R13.1 or later. The Primary HA CMS and Secondary Dual CMS
must be the same size and share a common hardware platform. However, a Survivable CMS
does not have to be on the same hardware platform or size as the Primary HA CMS or Secondary
Dual CMS. The Avaya Technology and Consulting (ATAC) Helpdesk determines the sizing of
the Survivable CMS.
The installation and setup of a Dual CMS or Survivable CMS does not differ from a regular
CMS. The configuration of the Avaya CMS software is based on the information configured in
Avaya Communication Manager as illustrated in Sections 3.1 for the Site 2 Secondary Dual
CMS and Section 3.2 for the Site 3 Survivable CMS. For detailed instructions on how to
configure the Avaya CMS software, refer to reference [4] in Section 7 of these Application
Notes. There are no additional configuration changes required on the CMS servers to function in
High Availability mode.
The Avaya Communication Solutions and Integrations (CSI) team performs the following for a
Dual CMS implementation:
• Remotely installs and configures the Admin-Sync software package on each CMS
(primary, secondary and survivable).
• Changes the root user’s prompt to distinguish each CMS.
• Configuration of Network Time Protocol (NTP) on each CMS (Refer to Appendix A).
• Provides the Admin-Sync Users Guide, which explains the supported features and
functionality of the “Survivable CMS Supplemental Package for Admin-Sync”.
To contact the Avaya CSI team, use the following:
• To order Admin-Sync, please call the Avaya Services Center at (866) 282-9266, prompts
1-1-1.
• To schedule the installation of Admin-Sync please call the Avaya Services Center at
(866) 282-9266, prompts 1-1-4, then press 0.

5. Verification Steps
The following sections provide detailed verification steps for the Sunny Day and WAN Failover
scenarios covered in Section 1.5. The ACD configuration consists of a single split/skill x with
agents resources in each location. ACD calls for split/skill x terminate from the Public Switched
Telephone Network (PSTN) via Vector Directory Number (VDN)s for each location.
5.1. Normal Operation – Sunny Day Scenario

Perform the following procedure to test the Secondary Dual CMS and Survivable CMS solution
during normal operation. Refer to Section 1.5.1 of these Application Notes for information on
the “Sunny Day” scenario.
5.1.1. Verifying Site 2 Secondary Dual CMS Link during Normal Operation
Step Description
1. Log in to the active Media Server at the Main Office with the appropriate access
permissions.
2. Issue the command “status processor-channels x”, where x is the configured processor
channel number for the MIS communication-interface link (refer to step 5 in Section 3.1).
Verify that the “Session Layer Status” is in the “In Service” state and that the “Socket
Status” is in the “TCP connected” state as shown below.
status processor-channels 2
PROCESSOR-CHANNEL STATUS
Channel Number: 2
Session Layer Status: In Service
Socket Status: TCP connected
Link Number: 9
Link Type: ethernet
Message Buffer Number: 0
Last Failure: Link went down

At: 10/17/06 16:11
3. Using a CMS Supervisor client, log into the Secondary Dual CMS at Site 2 and perform
Real-time Skill Status report on split/skill x. Verify that the Site 2 Secondary Dual CMS is
receiving the ACD call data as the Main Office Primary HA CMS for the Main Office, Site
2 and Site 4 locations.
5.1.2. Verifying CMS Link Operation for Site 3 Survivable CMS during
Normal Operation
Step Description
1. Log in to the Site 3 LSP Media Server with the appropriate access permissions.

Step Description
2. Issue the command “status processor-channels x”, where x is the configured processor
channel number for the MIS communication-interface link (refer to step 4 in Section 3.2).
Verify that the “Session Layer Status” is in the “In Service” state and that the “Socket
Status” is in the “TCP connected” state as shown below.
Channel Number: 1
Link Number: p
Link Type: processor ethernet
Last Failure: None

At: 10/17/06 13:58
3. Using a CMS Supervisor client, log into the Site 3 Survivable CMS and perform real-time
reports for logged-in agents at Site 3. Verify that the Site 3 Survivable CMS is not
receiving any ACD data (All real-time reports should be blank).
4. Using a CMS Supervisor client, log into the Main Office CMS and perform the same real-
time reports for logged-in agents at Site 3. Verify that the Main Office CMS is receiving
ACD data for Site 3.
5.1.3. Verifying the automatic synchronization of CMS Administrative Data

The Admin-Sync package automatically synchronizes selective CMS administrative data
overnight between the Main Office Primary HA CMS, the Secondary Dual CMS at Site 2, and
the Survivable CMS at Site 3 via the WAN.
Note: Changes involving VDN assignments, VDN Skill Preference, Vectors, and Agent skills
using CMS Supervisor are automatically synchronized between each CMS because these
are actually changes to Avaya Communication Manager software translations.
However, certain CMS administrative data are not automatically synchronized via the Admin-
Sync package. For a list of the CMS administrative data that can be automatically synchronized,
please reference the Admin-Sync Users Guide that is provided by the Avaya CSI team as part of
the Survivable CMS implementation.
The following procedure demonstrates how to verify the automatic synchronization of a new
CMS user that has been administered on the Primary HA CMS at the Main Office, to the
Secondary Dual CMS at Site 2, and Survivable CMS at Site 3. The Admin-Sync package
performs the CMS administrative data synchronization process at 3:15 AM (administrable). The
label Day 1 references the period before 3:15 AM, and Day 2 references the period after 3:15
AM when the CMS administrative data has become synchronized.

Step Description
1. Day 1 - Log in to the Main Office Primary HA CMS utilizing CMS Supervisor and a login
with administrative privileges. Create a new user ID with non-administrative permissions.
Verify and initiate the new user ID by logging into the Main Office Primary HA CMS.
2. Day 1 - Use the new user ID to log into the Secondary Dual CMS at Site 2 and Survivable
CMS at Site 3. Verify the systems do not recognize the new user ID.
3. Day 2 - Log in to the Main Office Primary HA CMS with CMS Terminal Emulator using a
login with the appropriate permissions to access the CMS Main Menu. From the CMS
Main Menu, select “Admin-Sync” and then enter the number associated with the “Admin-
Sync sub-menu” option. Then enter the number associated with the “View Log” option
(Use the Appendix B in Section 8 for reference). Verify that the system completed the
automated CMS administrative data synchronization process (3:15 AM).
4. Day 2 - Use the new user ID to log into the Secondary Dual CMS at Site 2. Verify the
system now allows successful login using the newly created User ID.
5. Day 2 - Use the new user ID to log into the Survivable CMS at Site 3. Verify the system
now allows successful login using the newly created User ID.
5.2. Failover Operation and Data Recovery

Perform the following procedure to test the Secondary Dual CMS and Survivable CMS solution
during failover operation. For detailed description of these scenarios, refer to Section 1.5.2 and
Section 1.5.3 of these Application Notes. The procedure span over two days because the data
aggregation process must be performed a day after the period of failover when the Secondary
Dual CMS and Survivable CMS collected ACD call data.
Supervisor A in the Main Office, Supervisor B in Site 2, and Supervisor C in Site 3 are logged in
to the Primary HA CMS at the Main Office utilizing CMS Supervisor to perform real-time Skill
Status reports on split/skill x. Split/skill x consists of logged-in Agent resources at the Main
Office, Site 2 and Site 3 locations. Calls are evenly distributed to each location (Total 15 calls
per 30-minute interval for all locations combined).
Step Description
1. Day 1 (first 30 minute interval) - From the PSTN place 2 calls using a specific VDN (for
split/skill x) that routes to each location (2 calls to the Main Office, Site 2, and Site 3).

Step Description
2. Day 1 (first 30 minute interval) - Disconnect the WAN links to the Main Office, Site 2,
and Site 3.
a. Verify that Supervisors B and C receive the error message shown below due to their
CMS Supervisor clients loosing connectivity with the Primary HA CMS at the Main
Office.
b. Verify that calls to Site 2 drop.

c. Verify that the calls to Site 3 do not drop (The Site 3 Media Gateway is a H.248
Gateway that provides connection-preserving failover).
d. Verify that Supervisor A continues to view updated information via CMS
Supervisor.
e. Verify that the CMS Link for the Main Office Primary HA CMS is still in service
and that the CMS Link for the Site 2 Secondary Dual CMS drops.
f. Verify that Supervisor A notices the Agents from Site 2 and Site 3 are no longer
shown in the Skill Status report for split/skill x.
g. The ESS at Site 2 should become active after a short period of time (implementation
specific). Log into the ESS with the appropriate login and permissions, and issue the
command “status health” (screen not shown) to verify that it has become active.
h. The LSP at Site 3 should become active after a short period of time (implementation
specific). Log into the LSP with the appropriate login and permissions, and issue the
command “status media gateways” (screen not shown) to verify that it has become
active.

Step Description
3. Day 1 (first 30 minute interval) - Log in the Agents at Site 2 and Site 3 again. Log in
Supervisor B to the Site 2 Secondary Dual CMS and Supervisor C to the Site 3 Survivable
CMS using CMS Supervisor. Verify that the CMS Link for Site 2 Secondary Dual CMS re-
establishes by logging into the active ESS Media Server using the SAT terminal. Issue the
command “status processor-channels x”, where x is the configured processor channel
number for the MIS communication-interface link (refer to step 6 in Section 3.1). Verify
that the “Session Layer Status” is in the “In Service” state and that the “Socket Status” is
in the “TCP connected” state as shown below.
Channel Number: 1
Link Number: 9
Link Type: ethernet
Last Failure: None

At: 10/17/06 10:28
4. Day 1 - (first 30 minute interval) From the PSTN, use a VDN (for split/skill x) that routes
to the specific location (Main Office, Site 2, and Site 3) and place 2 to the Main Office, 3
calls to Site 2, and 4 calls to Site 3. Using CMS Supervisor to view the Real-time Skill
Status report for split/skill x, verify the following:
a. Supervisor A can only view Agents for Main Office, and the report shows 2 calls
answered.
b. Supervisor B can only view Agents for Site 2, and the report shows 3 calls answered.
c. Supervisor C can only view Agents for Site 3, and the report shows 4 calls answered.
5. Day 1 (second 30 minute interval) - Repeat step 4.

Step Description
6. Day 1 (after the second 30 minute interval) – Restore the WAN links to the Main Office,
Site 2, and Site 3. Restore control of the Media Gateway at Site 2 back to the main Media
Server using the command “get forced-takeover ipserver-interface all”.
get forced-takeover ipserver-interface all
TEST RESULTS
Port Maintenance Name Alt. Name Test No. Result Error Code
PN 01 IPSV-CTL 1605 PASS

PN 02 IPSV-CTL 1605 IN-PROGRESS
Restore control of the Media Gateway at Site 3 back to the main Media Server by logging
into the LSP Media Server at Site 3 and rebooting it using the command “reset system 4”.
Note: A manual recovery, using the command “reset system 4”, is recommended versus an
automated recovery approach for the Media Gateway at Site 3. The reboot of the LSP
Media Server causes the instantaneous log-out of any agents that remain logged on.
7. Day 1 (after the second 30 minute interval) - Verify that the main Media Server has
regained full control of the Media Gateway at Site 2 using the command “status health”
and the Media Gateway at Site 3 using the command “status media gateways” (screens not
shown).
8. Day 2 - Log into the Main Office Primary HA CMS using CMS Supervisor and run a
historical Skill Summary Interval report for split/skill x for the intervals during the outage.
Verify the report shows 8 ACD calls for the first 30-minute interval and 2 ACD calls for the
second 30-minute interval.
9. Day 2 - Log into the Site 2 Secondary Dual CMS using CMS Supervisor and run a historical
Skill Summary Interval report for split/skill x for the intervals during the outage. Verify the
report shows 3 ACD calls for the first 30-minute interval and 3 ACD calls for the second
30-minute interval.
10. Day 2 - Log into the Site 3 Survivable CMS using CMS Supervisor and run a historical
Skill Summary Interval report for split/skill x and the interval during the outage. Verify the
report shows 4 ACD calls for the first 30-minute interval and 4 ACD calls for the second
30-minute interval.
11. Day 2 - Log in to the Main Office Primary HA CMS with CMS Terminal Emulator using a
login with the appropriate permissions to access the CMS Main Menu. Follow the
procedure in Appendix C to aggregate and restore the ACD call data from all CMS servers
for the intervals during the failover onto the Primary HA CMS at the Main Office and
Secondary Dual CMS at Site 2.

Step Description
12. Day 2 - After completing the ACD call data aggregation and recovery procedure, perform a
historical Skill Summary Interval report for split/skill x on the Main Office Primary HA
CMS and verify the following:
a. The report shows 8 ACD calls for the first 30-minute interval and 9 ACD calls for
the second 30-minute interval.
b. The ACD call data from the Secondary Dual CMS and Survivable CMS for the first
30-minute interval is not aggregated.
c. The ACD call data reflects the correct total number of ACD calls taken at the Main
Office, Site 2 and Site 3 for the second 30-minute interval during the outage.
d. The historical Skill Summary Interval reports for skill set x are identical on both the
Main Office Primary HA CMS and Site 2 Secondary Dual CMS.
13. Day 2 – Repeat step 2 using the Site 2 Secondary Dual CMS.

6. Conclusion
These Application Notes described how to configure and utilize Avaya Call Management System
R13.1 with the Survivable Server offers of Avaya Communication Manager 3.1 in a High
Availability and Survivable (Dual) Avaya CMS configuration. The Dual CMS configuration
provides redundancy and continuous call data collection during periods of WAN failover. In
addition, Appendix C provided detailed instructions on how to utilize the add-on Admin-Sync
software package to aggregate ACD call data from the multiple CMS in the enterprise, and to
restore ACD data redundancy on the Primary HA CMS and Secondary Dual CMS.
7. References
Product documentation for Avaya products may be found at http://support.avaya.com.
1. “Avaya Call Management System, Switch Connections, Administration, and

Troubleshooting”, February 2006, Comcode: 70-300739
2. “Administrator Guide for Avaya Communication Manager”, Issue 2, February 2006,
Comcode: 03-300509
3. “Using the Avaya Enterprise Survivable Servers (ESS)”, Issue 2, February 2006,
Comcode: 03-300428
4. “Avaya Call Management System, Release 13, Software Installation, Maintenance, and
Troubleshooting Guide”, May 2006, Comcode: 07-600954
5. “Installing and Configuring the Avaya S8700-Series Media Server, Release 3.1”, Issue 5,
February 2006”, Comcode 03-300145
6. “How to Configure and Utilize a Standard Avaya Survivable Call Management System
Solution”, Issue 1.0, October 2006

Appendix A
The synchronization of time on each Avaya CMS and Avaya Communication Manager Media
Server is highly recommended to ensure accurate ACD call data aggregation. The Avaya CSI
team can initially configure NTP on each CMS; however, Avaya CSI requires the IP addresses of
the NTP server(s) and for NTP to be previously configured on each Avaya Media Server. The
following sections describe how to configure NTP on the Avaya CMS and Avaya
Communication Manager Media Servers to utilize a timeserver for clock synchronizations.
Configuring Network Time Synchronization on Avaya Communication

Manager Media Servers
For detailed instructions on how to configure the NTP service on Avaya Communication
Manager Media Servers, refer to reference [5] (Chapter 4 “Media Server Configuration”) in
Section 7 of these Application Notes.
Configuring Network Time Synchronization on Avaya Call

Management Systems
The following details how to configure NTP service on the Avaya CMS (Avaya CMS utilizes the
Sun Solaris UNIX Operating System). Log in to the CMS with the administrative User ID and
the appropriate access permissions. Enter the following sequence of commands shown in bold:
sa-cms (Primary)# cd
sa-cms (Primary)# crontab -l > cronjobs
sa-cms (Primary)# echo "15 * * * * /usr/sbin/ntpdate -s <IP addresses of NTP servers>"
>> cronjobs
sa-cms (Primary)# crontab cronjobs
sa-cms (Primary)# crontab -l
#ident "@(#)root 1.20 01/11/06 SMI"
#
# The root crontab should be used to perform accounting data collection.
#
# The rtc command is run to adjust the real time clock if and when
# daylight savings time changes.
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
0,5,10,15,20,25,30,35,40,45,50,55 * * * * LD_LIBRARY_PATH=/usr/lib: /opt/cc/ahl/
bin/start_ahl
0,15,30,45 * * * * /opt/cc/aot/bin/disk_watch
17 5 * * 0 /etc/cleanup > /dev/null 2>&1
15 3 * * * /export/home/pserv/HAcms/nightly_push > /dev/null 2>&1
0 * * * * /olds/chkDisks > /dev/null 2>&1
0 * * * * /etc/init.d/sendmail start; /usr/lib/sendmail -Ac -qI clientmqueue; sl
eep 15; /etc/init.d/sendmail stop
* * * * * /export/home/pserv/HAcms/update_call_pro >/dev/null 2>&1
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/aom start > /dev/null
15 * * * * /usr/sbin/ntpdate -s 10.20.1.1
The crontab –l command verifies that the crontab cronjobs command added the line shown
highlighted above (“10.20.1.1” is the NTP server IP address) to the cronjob for the user.

Appendix B
Synchronizing Administrative Data on Demand
The synchronization of CMS administrative data, such as Supervisor logins, Custom and
Designer Reports, VDN and Skill Call Profiles and permissions are synchronized automatically
each day between all CMS in the enterprise, as part of the Admin-Sync software. The Admin-
Sync software also allows the ability to synchronize CMS administrative data on demand. For
additional information, please reference the Admin-Sync Users Guide that is provided by the
Avaya CSI team as part of the High Availability and Survivable CMS implementation.
Step Description
1. Log in to the Primary HA CMS using CMS Terminal Emulator with the appropriate login
and password. From the “Main Menu”, select “Admin-Sync”.
8/10/06 12:53 Avaya(TM) CMS Windows: 0 of 10 ^
-MainMenu----------------------
| Reports> |
| Dictionary> |
| Exceptions> |
| Agent Administration> |
| Call Center Administration> |
| Custom Reports> |
| User Permissions> |
| System Setup> |
| Maintenance> |
| Admin-Sync> |
| Logout |
| ; |
-------------------------------
2. From the “HA CMS User Menu - PRIMARY” menu, enter “3” to select the “Admin-
Sync sub-menu” option and press the Enter key.
HA CMS User Menu - PRIMARY
for
Interface Software Activation/Deactivation
1) Configure this system as active (for external data feeds)
2) Configure this system as inactive (for external data feeds)
3) Admin-Sync sub-menu
0) Exit
===================================================
Selection? 3

Step Description
3. From the “Admin-Sync for HA CMS and Survivable CMS” menu, enter “3” to select the
“Synchronize Administrative Data Now” option. Press the Enter key to begin the data
synchronization process from the Primary HA CMS to each Survivable CMS.
Admin-Sync for HA CMS

and Survivable CMS
1) Schedule Admin-Sync
2) Un-Schedule Admin-Sync
3) Synchronize Administrative Data Now
4) Transfer & Restore a Day's Call Data, (pull) FROM Secondary HA CMS
5) Transfer & Restore a Day's Call Data, (push) TO Secondary HA CMS
6) Transfer & Restore Interval Call Data, (pull) FROM Secondary HA CMS
7) Transfer & Restore Interval Call Data, (push) TO Secondary HA CMS
8) Merge Login/Logout Records (for a Day)
9) Display Admin-Sync Version
10) View Log
11) Aggregate Call Data from Survivable CMS's
0) Exit
=============
Choice ==> 3

Step Description
4. The system begins the data synchronization process between all CMS as shown below.
When the process completes, the system prompts the user to “Press Enter to continue”.
Note: The Avaya CSI team assigns the CMS names shown in the output below.
SENDING non-Informix data to CMS: secondary...

sending passwd and shadow files
sending changed user's home directories...
Changed: copying /export/home/solar to secondary...
setting file ownership and permissions...
sending Screen Painter files
no changed files to send
sending Reports Designer files
calling sync_custrpts on secondary
calling mod_profiles on secondary
mod_profiles on secondary finished
DONE sending non-Informix data to CMS: secondary
Doing housekeeping on CMS: secondary
SENDING non-Informix data to CMS: survivable1...
sending passwd and shadow files
sending changed user's home directories...
Changed: copying /export/home/solar to survivable1...
setting file ownership and permissions...
sending Screen Painter files
sending Reports Designer files
calling sync_custrpts on survivable1
calling mod_profiles on survivable1
mod_profiles on survivable1 finished
DONE sending non-Informix data to CMS: survivable1
Doing housekeeping on CMS: survivable1
Doing housekeeping on the Primary
DONE - Administrative data synchronized.
Press Enter to continue:

Appendix C
Aggregating and Restoring ACD Call Data on Primary HA CMS and
Secondary Dual CMS
All data restoration processes are originated from the Primary HA CMS using the Admin-Sync
Menu (The Admin-Sync Menu is only available from the Primary HA CMS).
Note: It is important to mention the following in regards to call data restoration.
1. The intervals (with ACD call data) at the beginning of the WAN failure period (when the
ESS assumed control of Media Gateway with the dedicated C-LAN board) and when
normal operation is restored (when the main Media Server reassumes control of the same
Media Gateway), will not be aggregated.
2. Additional integration work will be necessary for Third-party systems to receive CMS
data from the Secondary Dual CMS (if multiple CMS are supported).
3. A CMS Administrator manually initiates various automated data restoration processes.
Please refer to Section 1.5.3 for more information on ACD call data aggregation and recovery.
For additional information, please reference the Admin-Sync Users Guide that is provided by the
Avaya CSI team as part of the Dual and Survivable CMS implementation.
Step Description
1. Log in to the Primary HA CMS using CMS Terminal Emulator with the appropriate login
and password. From the “Main Menu”, select “Admin-Sync”.
8/10/06 12:53 Avaya(TM) CMS Windows: 0 of 10 ^
-MainMenu----------------------
| Reports> |
| Dictionary> |
| Exceptions> |
| Agent Administration> |
| Call Center Administration> |
| Custom Reports> |
| User Permissions> |
| System Setup> |
| Maintenance> |
| Admin-Sync> |
| Logout |
| ; |
-------------------------------

Step Description
2. From the “HA CMS User Menu - PRIMARY” menu, enter “3” to select the “Admin-
Sync sub-menu” option and press the Enter key.
HA CMS User Menu - PRIMARY
for
Interface Software Activation/Deactivation
1) Configure this system as active (for external data feeds)
2) Configure this system as inactive (for external data feeds)
3) Admin-Sync sub-menu
0) Exit
===================================================
Selection? 3
3. From the “Admin-Sync for Survivable CMS” menu, enter “11” to select the “Aggregate
Call Data from Survivable CMS’s” option.
Admin-Sync for HA CMS
and Survivable CMS
1) Schedule Admin-Sync
2) Un-Schedule Admin-Sync
3) Synchronize Administrative Data Now
4) Transfer & Restore a Day's Call Data, (pull) FROM Secondary HA CMS
5) Transfer & Restore a Day's Call Data, (push) TO Secondary HA CMS
6) Transfer & Restore Interval Call Data, (pull) FROM Secondary HA CMS
7) Transfer & Restore Interval Call Data, (push) TO Secondary HA CMS
8) Merge Login/Logout Records (for a Day)
9) Display Admin-Sync Version
10) View Log
11) Aggregate Call Data from Survivable CMS's
0) Exit
=============
Choice ==> 11

Step Description
4. From the “Avaya CMS ESS Data Merge Menu” enter “1” to select the “Aggregate
interval data and merge agent login/logout data” option.
Avaya CMS ESS Data Merge Menu

============================================
Enter "q" and a return at any prompt to exit.
When aggregating historical data (option 1), you will be prompted to enter
the date and time when CMS data became fragmented, the date and time when
the enterprise returned to normal operations, and the ACD number for the
data you wish to process.
When merging agent login and logout data (option 2), you will be prompted
to enter the date when CMS data became fragmented, the date when the
enterprise returned to normal operations, and the ACD number for the
data you wish to process.
Agent login and logout data for the current calendar day will not be
processed (any new agent logins or logouts are omitted from the merged
data if they occur during the time period that agent login and logout data
is being processed and fragmented data is being replaced with merged data).
1) Aggregate interval data and merge agent login/logout data.

2) Merge agent login/logout data only.
q) Exit ESS Data Merge Menu.
============================================
Select 1 or 2 (or q to quit) -> 1

Step Description
5. Enter the ACD number with the fragmented data. In this case, “1” is entered for the ACD
number assigned for the entire enterprise. The Primary HA CMS then performs network
connectivity tests to the Secondary Dual CMS and Survivable CMS. If the test is
successful, the system responds with “Okay” and continues. Enter the dates and times the
Secondary Dual CMS or Survivable CMS entered survivable mode and returned to normal
operation (example below shows entries and subsequent output).
Select the ACD number with fragmented data -> 1
Testing network connectivity ... Okay
Date remote host(s) entered survivable mode (mm/dd/yyyy) -> 10/17/2006
Time remote host(s) entered survivable mode (hhmm) -> 1600
Date remote host(s) returned to normal mode (mm/dd/yyyy) -> 10/17/2006
Time remote host(s) returned to normal mode (hhmm) -> 1700
10/17/2006 14:03:28 - Start 08/09/2006 ESS data for table hcwc, ACD 1
10/17/2006 14:03:30 - Complete 08/09/2006 ESS data for table hcwc, ACD 1
10/17/2006 14:03:30 - Start 08/09/2006 ESS data for table hsplit, ACD 1
10/17/2006 14:03:31 - Complete 08/09/2006 ESS data for table hsplit, ACD 1
10/17/2006 14:03:31 - Start 08/09/2006 ESS data for table htkgrp, ACD 1
10/17/2006 14:03:32 - Complete 08/09/2006 ESS data for table htkgrp, ACD 1
10/17/2006 14:03:32 - Start 08/09/2006 ESS data for table htrunk, ACD 1
10/17/2006 14:03:34 - Complete 08/09/2006 ESS data for table htrunk, ACD 1
10/17/2006 14:03:34 - Start 08/09/2006 ESS data for table hvdn, ACD 1
10/17/2006 14:03:34 - Complete 08/09/2006 ESS data for table hvdn, ACD 1
10/17/2006 14:03:34 - Start 08/09/2006 ESS data for table hvector, ACD 1
10/17/2006 14:03:36 - Complete 08/09/2006 ESS data for table hvector, ACD 1
10/17/2006 14:03:36 - Start 08/09/2006 ESS data for table haglog, ACD 1
10/17/2006 14:03:40 - Complete 08/09/2006 ESS data for table haglog, ACD 1
10/17/2006 14:03:44 - Queuing daily archiver on host cms_sec for 10/17/2006
10/17/2006 14:03:44 - Queuing daily archiver on host cms_pri for 10/17/2006
6. Choose “q” to exit the ESS Data Merge Menu and return the CMS Main Menu.

©2006 Avaya Inc. All Rights Reserved.
Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by ® and ™
are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the
property of their respective owners. The information provided in these Application Notes is
subject to change without notice. The configurations, technical data, and recommendations
provided in these Application Notes are believed to be accurate and dependable, but are
presented without express or implied warranty. Users are responsible for their application of any
products specified in these Application Notes.
Please e-mail any questions or comments pertaining to these Application Notes along with the
full title name and filename, located in the lower right corner, directly to the Avaya Solution &
Interoperability Test Lab at interoplabnotes@list.avaya.com


CMS Dual

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

CMS Dual

Uploaded by

Copyright:

Available Formats

Avaya Solution & Interoperability Test Lab

How to Configure and Utilize the High Availability and

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 1 of 40

1.1. High Availability Call Management System

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 2 of 40

1.2. Survivable Call Management System

1.3. Dual Call Management System

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 3 of 40

The Secondary Dual CMS has the following provision requirements:

These Application Notes cover the following topics:

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 4 of 40

Figure 1: Reference Network Configuration (Sunny Day Scenario)

1.5. Operation Scenarios

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 5 of 40

1.5.2. Failover Operation - WAN Failure Scenario

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 6 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 7 of 40

Figure 2: WAN Failure Scenario

1.5.3. Returning to Normal Operation and Performing ACD Call Data

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 8 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 9 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 10 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 11 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 12 of 40

3.1. Avaya Communication Manager Administration for Site 2 ESS

display system-parameters features Page 12 of 17

AGENT AND CALL SELECTION

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 13 of 40

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 14 of 40

Target socket load and Warning level: 400

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 15 of 40

Data Extension: 4340009 Name: clan-2a10-cms2

Network uses 1's for Broadcast Addresses? y

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 16 of 40

6. Issue the command “list survivable-processor” to reference the configured Survivable

cc-ess1 ESS 10 .2 .2 .11 y 11:22 8/3/2006 1

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 17 of 40

Proc Interface Destination Session

Command Completion Status Error Code

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 18 of 40

AGENT AND CALL SELECTION

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 19 of 40

3. Issue the command “list survivable-processor” to reference the configured Survivable

cc-ess1 ESS 10 .2 .2 .11 y 11:22 8/3/2006 1

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 20 of 40

Proc Interface Destination Session

Proc Interface Destination Session

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 21 of 40

Command Completion Status Error Code

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 22 of 40

To contact the Avaya CSI team, use the following:

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 23 of 40

5.1. Normal Operation – Sunny Day Scenario

Last Failure: Link went down

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 24 of 40

Last Failure: None

5.1.3. Verifying the automatic synchronization of CMS Administrative Data

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 25 of 40

5.2. Failover Operation and Data Recovery

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 26 of 40

b. Verify that calls to Site 2 drop.

CAB; Reviewed: Solution & Interoperability Test Lab Application Notes 27 of 40

Last Failure: None