cms_dual

CAB; Reviewed: SPOC 11/15/2006

Solution & Interoperability Test Lab Application Notes ©2006 Avaya Inc. All Rights Reserved.

1 of 40 CMS_Dual.doc

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.




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) • Avaya TN779DP C-LAN Circuit Packs (4) • Avaya TN2602AP Circuit Pack • Avaya TN2501AP VAL Circuit Pack • Avaya TN646HP Circuit Packs (4)

HW 12 FW 031 HW 01 FW 017 HW 02 FW 024 HW 02 FW 010 HW 02 FW 018

Avaya Converged Stackable Switch C363T-PWR 4.5.14 Avaya Call Management System (CMS)

• Sun Blade 150 Workstation • Admin-Sync Software Package

13.1 (r13.1auxcb.e) Solaris OS V9 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 Enterprise Survivable Server (ESS)

Avaya Communication Manager 3.1.2 (R013x.01.2.632.1)

Avaya G650 Media Gateway • Avaya TN2312BP IPSI Circuit Pack • Avaya TN779DP C-LAN Circuit Pack (3) • Avaya TN2602AP Circuit Pack • Avaya TN2501AP VAL Circuit Pack • Avaya TN464HP Circuit Packs (2)

HW 12 FW 031 HW 01 FW 017 HW 02 FW 024 HW 02 FW 010 HW 02 FW 018

Avaya Call Management System (CMS) • Sun Blade 150 Workstation • Admin-Sync Software Package


Avaya Converged Stackable Switch C363T-PWR 4.5.14 Cisco 1841 Router 12.4(5)

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

• MM712 – DCP Media Module • MM710 (2) – T1/E1 Media Module • ANALOG – Integrated Analog 1T + 2L

Module • MM340 – WAN Routing Media Module • MM314 – PoE Expansion Media Module

Version 25.28.0 Vintage 5 Version 7 Vintage 5 Version 15 Version 68 n/a n/a

Avaya Call Management System (CMS) • Sun Netra 210 Server • Admin-Sync Software Package


Cisco 2821 Router 12.4(5)

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 Emulator

R13.0 (Build HC.06)

Avaya Terminals • Avaya 4600 Series IP Telephones • Avaya DCP 2420 Telephones • Avaya 6211 Analog Telephones

2.3 (2.5 for 4625 )

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.

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.

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

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”.

8. Issue the command “save translation all” to save the changes and push the updated translations to the ESS and LSP Media Servers.

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

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.

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

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




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.

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.

After changes

change survivable-processor br3-elsp Page 2 of 3 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 o mis s p 5001 sa-cms3 0 2 2

change survivable-processor br3-elsp 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




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.

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.

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




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.

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.

status processor-channels 2 PROCESSOR-CHANNEL STATUS Channel Number: 1 Session Layer Status: In Service Socket Status: TCP connected Link Number: p Link Type: processor ethernet Message Buffer Number: 0 Last Failure: None At: 10/17/06 13:58




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.

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.

status processor-channels 1 PROCESSOR-CHANNEL STATUS Channel Number: 1 Session Layer Status: In Service Socket Status: TCP connected Link Number: 9 Link Type: ethernet Message Buffer Number: 0 Last Failure: None At: 10/17/06 10:28




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”.

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.

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




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:

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.

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




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”.

2. From the “HA CMS User Menu - PRIMARY” menu, enter “3” to select the “Admin-Sync sub-menu” option and press the Enter key.

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 | | ; | -------------------------------

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 no changed files to send 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 no changed files to send sending Reports Designer files no changed files to send 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.

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

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

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).

6. Choose “q” to exit the ESS Data Merge Menu and return the CMS Main Menu.

Select the ACD number with fragmented data -> 1Testing 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




©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 [email protected]

cms_dual

Documents