Ha Sip Server

Version 1.0

SIP Server 7.6 / HA Configuration

White Paper Version 1.1

April 9, 2010 The information contained herein is proprietary and confidential and cannot be disclosed or duplicated without the prior written consent of Genesys Telecommunications Laboratories, Inc. Copyright © 2004–2010 Genesys Telecommunications Laboratories, Inc. All rights reserved.

Version 1.0

About Genesys Genesys Telecommunications Laboratories, Inc., a subsidiary of Alcatel, is 100% focused on software for call centers. Genesys recognizes that better interactions drive better business and build company reputations. Customer service solutions from Genesys deliver on this promise for Global 2000 enterprises, government organizations, and telecommunications service providers across 80 countries, directing more than 100 million customer interactions every day. Sophisticated routing and reporting across voice, e-mail, and Web channels ensure that customers are quickly connected to the best available resource—the first time. Genesys offers solutions for customer service, help desks, order desks, collections, outbound telesales and service, and workforce management. Visit www.genesyslab.com for more information. Each product has its own documentation for online viewing at the Genesys Technical Support website or on the Documentation Library CD, which is available from Genesys upon request. For more information, contact your sales representative. Notice Although reasonable effort is made to ensure that the information in this document is complete and accurate at the time of release, Genesys Telecommunications Laboratories, Inc., cannot assume responsibility for any existing errors. Changes and/or corrections to the information contained in this document may be incorporated in future versions. Your Responsibility for Your System’s Security You are responsible for the security of your system. Product administration to prevent unauthorized use is your responsibility. Your system administrator should read all documents provided with this product to fully understand the features available that reduce your risk of incurring charges for unlicensed use of Genesys products. Trademarks Genesys, the Genesys logo, and T-Server are registered trademarks of Genesys Telecommunications Laboratories, Inc. All other trademarks and trade names referred to in this document are the property of other companies.. Released by Genesys Telecommunications Laboratories, Inc. www.genesyslab.com

SIP Server 7.6.0 HA Configuration 3/49

Version 1.0

REVISION HISTORY Revision Date Published Author Comment 0.1 May 04, 2007 Timofey Buryi Initial draft 0.2 May 08, 2007 Timofey Buryi Feedback implemented 0.3 May 14,2007 Timofey Buryi Corrections 0.4 May 16,2007 Timofey Buryi Add Windows cluster comments in section 1.1

Re: G. Budilovsky 0.5 September 28,2007 Timofey Buryi Shell control script correction in section 3.3 0.6 October 8, 2008 Taras

Mytropan Version changed to 7.6.0 Modified sections 2.1, 3.1, 3.2,1, 3.2.2 sip-sync-xxx, internal-registrar-persistent,… Added section 3.2.8

0.7 October 16, 2008 Taras Mytropan

Modified sections 1.1, Added APPENDIX A – TROUBLESHOOTING TIPS

0.8 August 9, 2009 Taras Mytropan

SIP Server 8.0 improvements –section 3

0.9 October 23, 2009 Taras Mytropan

3.4 section is added. NLB logging is added

0.91 March 23, 2010 Taras Mytropan

IBM AIX info is added

1.0 April 9, 2010 SIP Server Team

Approved for publication to support site.

1.1 May 13, 2010 Victor Kolesov

Updated NLB scripts to support restart of a backup host (3.2.3 and 3.2.4)


Version 1.0

TABLE OF CONTENTS

TABLE OF CONTENTS 4

ARCHITECTURE 6

1.1 WINDOWS PLATFORM 6

1.2 UNIX/LINUX PLATFORM 7

2 SWITCHOVER WORKFLOW 9

2.1 WINDOWS PLATFORM 9

2.2 UNIX/LINUX PLATFORM 11

3 CONFIGURATION 13

3.1 SIP SERVER APPLICATION CONFIGURATION 13

3.2 WINDOWS CONFIGURATION 16

3.2.1 Software requirements 16

3.2.2 Network requirements 16

3.2.3 Windows cluster configuration 16

3.2.4 Cluster Control Script 20

3.2.5 Cluster control Applications configuration 21

3.2.6 Reaction Scripts configuration 24

3.2.7 Alarm Conditions configuration 26

3.2.8 Verify that cluster control applications, alarms and script configured correctly33

3.3 UNIX/LINUX CONFIGURATION 33

3.3.1 Host configuration 33

3.3.2 Virtual IP interface control script 34

3.3.3 Virtual IP interface control Applications configuration 35

3.3.4 Reaction Scripts configuration 38

3.3.5 Alarm Conditions configuration 40

3.4 VERIFY THAT ANY TELEPHONY FUNCTION CAN BE PERFORMED ON SYNCHRONIZED CALL AFTER A SWITCHOVER 44

APPENDIX A – TROUBLESHOOTING TIPS 46


Version 1.0


Version 1.0

ARCHITECTURE

1.1 WINDOWS PLATFORM

Figure 1 – Windows Architecture overview

The HA architecture for SIP Server on Windows platform uses a Network Load-Balancing cluster. The Network Load-Balancing cluster uses the concept of Virtual IP address. The SIP end points and gateways are configured to send all SIP requests to SIP Server using this single Virtual IP address. The cluster software delivers the requests to only one of the host in the cluster with SIP Server is in Primary mode, and switches over to another SIP Server if it detects a SIP Server failure. Management and configuration layers software and T-Library clients are using unique for the host IP address for communication to SIP Server and LCA. If the Network Load Balancing cluster is configured to operate in unicast mode (the default), two network adapters on each host is required to enable communication among cluster hosts. First adapter handles the network traffic for cluster operations using Virtual IP address. Second adapter handles traffic from


Version 1.0

Management and configuration layers software, T-Library clients and communication between Primary and Backup T-Servers using unique host IP address. Note:

In W2K3 is possible to avoid the need for a second NIC for intra-node communication and it’s turned on by default in W2K8. http://support.microsoft.com/kb/898867

Genesys Management Layer via NLB utility (wlbs.exe or nlb.exe) provides manipulation (enabling or disabling) of particular IP port in such a way that SIP port occupied by SIP Server is enabled on the host where primary SIP server running and is disabled on the host with backup SIP Server. So several SIP Server pairs could be running on the same cluster and role switching between members of the each pair could be made independently.

1.2 UNIX/LINUX PLATFORM

Figure 2 – UNIX/Linux Architecture overview


Version 1.0

Warm/hot standby on UNIX/Linux/IBM AIX platform is achieved by hiding two hosts of primary and backup SIP servers behind one IP address. This method effectively hides server’s switchover (and switchback) from the end points and gateways. Two UNIX/Linux hosts on the same network subnet (in example “siplab6” and “siplab7”) are used. Each host has two logical IP interfaces assigned to a single Ethernet interface. The first IP interface (called “unique” in this example) has the unique IP address of each host. The second IP interface (called “Virtual” in this example, though it is sometimes referred to as “common”) has an address on the same subnet and this address is shared between two hosts. The unique interface should always be activated on each host. Management and configuration layers software and T-Library clients are using that unique interface for communication to SIP Server and LCA. The Virtual IP interface should be activated only if SIP Server is working in primary mode on that host. Otherwise, the Virtual IP interface has to be deactivated. SIP User Agents (end points) and gateways are only aware of the Virtual IP interface. The address and hostname of the common interface, as well as addresses and host names of the unique interfaces, must be known to the DNS server.


Version 1.0

2 SWITCHOVER WORKFLOW

2.1 WINDOWS PLATFORM

Figure 3 – Windows Platform after switchover.


Version 1.0

Figure 4 – Windows Platform after Primary Server failure.


Version 1.0

2.2 UNIX/LINUX PLATFORM

Figure 5 – UNIX/Linux Platform after switchover.


Version 1.0

Figure 6 – UNIX\Linux Platform after Primary Server failure.


Version 1.0

3 CONFIGURATION

3.1 SIP SERVER APPLICATION CONFIGURATION Configuration procedure assumes that Primary application (in example “LinHA_Prime” ) already exists and configured . Using Configuration manager:

a) Create Backup application (in example “LinHA_Backup” ) from SIP TServer template . Configure the following Primary SIP Server options critical for HA:

Configure the following Backup SIP Server options critical for HA:

Option (TServer section) Value Description sip-address host uri Common IP interface host name or IP address (cluster

for Windows and Virtual IP interface for UNIX/Linux ) has to be the same for Primary and Backup host . Used in SIP UA configuration as registrar URI.

sip-port string SIP registrar port. Has to be same for Primary and Backup applications

internal-registrar-persistent

true Note: Not required for version 8.0. SIP Server starting from version 8.0 synchronizes the SIP registration contact header for a particular device across both primary and backup SIP Server instances using the HA link. Enables SIP Server to update the DN attribute contact in the configuration database. When an endpoint registers, SIP Server takes the contact information from the REGISTER request and updates or creates a key called contact in the Annex tab of the corresponding DN. For SIP Server version 7.6 and less that allows updated contact information to be propagated by Configuration Server to the Backup Sip Server. Note: If using Configuration Server Proxy updated contact information will not be propagated by Configuration Server to the Backup Sip Server Note: SIP Server must have Full Control permission for the DN objects in order to update a configuration object. By default, it does not have this permission. You need to grant Full Control permission for the System account for the all DNs on the corresponding switch. It is done for all DNs at once by changing the permissions for the System account on the DN folder in the Switch object. Or, you can start SIP Server under another account that has Change permission on the necessary DNs.


Version 1.0

Put “network” in to “standard” option in “Log” section for both servers and set verbose to the required “all” level:

Option (TServer section) Value Description sip-address host uri Common IP interface host name or IP address (cluster

for Windows and Virtual IP interface for UNIX/Linux ) has to be the same for Primary and Backup host . Used in SIP UA configuration as registrar URI.

sip-port string SIP registrar port. Has to be same for Primary and Backup applications

internal-registrar-persistent

true Note: Not required for version 8.0. SIP Server starting from version 8.0 synchronizes the SIP registration contact header for a particular device across both primary and backup SIP Server instances using the HA link. Enables SIP Server to update the DN attribute contact in the configuration database. When an endpoint registers, SIP Server takes the contact information from the REGISTER request and updates or creates a key called contact in the Annex tab of the corresponding DN. That allows updated contact information to be propagated by Configuration Server to the Backup Sip Server. Note: If using Configuration Server Proxy updated contact information will not be propagated by Configuration Server to the Backup Sip Server Note: SIP Server must have Full Control permission for the DN objects in order to update a configuration object. By default, it does not have this permission. You need to grant Full Control permission for the System account for the all DNs on the corresponding switch. It is done for all DNs at once by changing the permissions for the System account on the DN folder in the Switch object. Or, you can start SIP Server under another account that has Change permission on the necessary DNs.


Version 1.0

Add connections to Message server for both servers:

Connect switch connected to Primary server to Backup SIP Server configuration in Switches tab:

For Primary Server application set Backup server Application:


Version 1.0

3.2 WINDOWS CONFIGURATION

3.2.1 Software requirements a) Microsoft Windows Server 2003 or Windows Server 2008 installed on all computers

in the cluster. b) A name resolution method such as Domain Name System (DNS), DNS dynamic

update protocol, Windows Internet Name Service (WINS), HOSTS, and so on. c) An existing domain model. d) All nodes must be members of the same domain. e) A domain-level account that is a member of the local administrators group on

each node. A dedicated account is recommended.

3.2.2 Network requirements a) A unique NetBIOS name. b) Static IP addresses for all network interfaces on each node.

Note: Server clustering does not support the use of IP addresses assigned from Dynamic Host Configuration Protocol (DHCP) servers.

c) Dedicated network switch or separate VLAN for cluster adapters. That will reduce switch flooding caused by Network Load Balancing

d) Access to a domain controller. If the cluster service is unable to authenticate the user account used to start the service, it could cause the cluster to fail. It is recommended that you have a domain controller on the same local area network (LAN) as the cluster is on to ensure availability.

e) Each node must have at least two network adapters—one for connection to the client public network and the other for the node-to-node private cluster network. A dedicated private network adapter is required for HCL certification.

f) All nodes must have two physically independent LANs or virtual LANs for public and private communication.

g) If you are using fault-tolerant network cards or network adapter teaming, verify that you are using the most recent firmware and drivers. Check with your network adapter manufacturer for cluster compatibility.

3.2.3 Windows cluster configuration On cluster hosts, you must configure the Network Load-Balancing parameters as follows:

• Port Range: Must include port configured as sip-port option in TServer section. • Protocols: UDP and TCP, if required. • Filtering mode: Multiple (for multiple hosts). • Affinity: None or Single. • Load weight: Equal. • Select the "Allow remote control" check box in Cluster Parameters tab.

When selecting Cluster operation mode in Cluster Parameters tab take in consideration the fallowing: - When using unicast method, all cluster hosts share an identical unicast MAC address. Network Load Balancing overwrites the original MAC address of the cluster adapter with the unicast MAC address that is assigned to all the cluster hosts.


Version 1.0

-When using multicast method, each cluster host retains the original MAC address of the adapter. In addition to the original MAC address of the adapter, the adapter is assigned a multicast MAC address, which is shared by all cluster hosts. So network adaptors have to be multiMAC “’friendly”. The incoming client requests are sent to all cluster hosts by using the multicast MAC address.

The unicast method advantages:

- unicast method works in all routing situations.

The unicast method disadvantages:

-A second network adapter is required to provide peer-to-peer communication between cluster hosts.

-If the cluster is connected to a switch, incoming packets are sent to all the ports on the switch, which can cause switch flooding.

The multicast method has the following disadvantages:

-Upstream routers might require a static Address Resolution Protocol (ARP) entry. This is because routers might not accept an ARP response that resolves unicast IP addresses to multicast MAC addresses.

-Without IGMP, switches might require additional configuration to tell the switch which ports to use for the multicast traffic.

-Upstream routers might not support mapping a unicast IP address (the cluster IP address) with a multicast MAC address. In these situations, you must upgrade or replace the router. Otherwise, the multicast method is unusable.


Version 1.0


Version 1.0

Additionally cluster should be configured to have both nodes started in the stopped state. It can be done by setting the ‘Default state’ parameter in the ‘Host Parameters’ tab of the ‘Host Properties’ configuration window to the value of ‘Stopped’. This configuration ensures that if the backup host is restarted and re-registers in the cluster it won’t interfere with the traffic distribution.


Version 1.0

For more information on how to administer Network Load-Balancing technology, see the Windows Advanced Server documentation or online help.

3.2.4 Cluster Control Script This section contains scripts need to be executed when SIP Servers

changes its role to ensure the Primary SIP Server always handles the traffic. The following commands are used: • wlbs start <cluster_name>:<ID_Primary> • wlbs enable XXXX <cluster_name>:<ID_Primary> • wlbs disable XXXX <cluster_name>:<ID_Backup> Where: • wlbs is name of the Windows utility used to control Network Load- Balancing. • start is the command to have a host to register in the cluster. • enable is the command to enable traffic handling for the host on which the primary SIP Server is running. • XXXX is the decimal value number of the port as it is configured in the sipport option. • cluster_name is the virtual IP address of the cluster. • ID_Primary is the unique host ID of the host where the primary SIP Server is currently running. • disable is the command to disable traffic handling for the host on which the backup SIP Server is running. • ID_Backup is the unique host ID of the host where the backup SIP Server is currently running. If these commands are issued at the moment when SIP Server changes its roles, the primary SIP Server always handles the traffic. In files below replace "5060" with actual SIP Serever port number, and "sipcluster" with actual NLB cluster Virtual IP address.


Version 1.0

Scripts should be configured as a "Third Party Server" on host1 and host2 of the NLB cluster. Scripts examples: sipdev1_up.bat @title SIP Server Enable Virtual IP Control Script @echo ********************* sips1 primary ********************** >> vip1.log @echo %time% >> vip1.log wlbs.exe start sipcluster:1 >> vip1.log wlbs.exe enable 5060 sipcluster:1 >> vip1.log wlbs.exe disable 5060 sipcluster:2 >> vip1.log exit sipdev1_down.bat @title SIP Server Disable Virtual IP Control Script @echo ********************* sips1 backup ********************** >> vip1.log @echo %time% >> vip1.log wlbs.exe disable 5060 sipcluster:1 >> vip1.log ping –n 2 127.0.0.1 exit sipdev2_up.bat @title SIP Server Enable Virtual IP Control Script @echo ********************* sips2 primary ********************** >> vip2.log @echo %time% >> vip2.log wlbs.exe start sipcluster:2 >> vip2.log wlbs.exe enable 5060 sipcluster:2 >> vip2.log wlbs.exe disable 5060 sipcluster:1 >> vip2.log exit sipdev2_down.bat @title SIP Server Disable Virtual IP Control Script @echo ********************* sips2 backup ********************** >> vip2.log @echo %time% >> vip2.log wlbs.exe disable 5060 sipcluster:2 >> vip2.log ping –n 2 127.0.0.1 exit

3.2.5 Cluster control Applications configuration 1. Using Configuration Manager Interface, create four Application objects corresponding to four scripts created in 3.2.4. using Third Party Server application template :


Version 1.0

2. On the Server Info tab of two new Application objects installed at Primary Host (marked as “sipdev1_” in example), set the Host to the name of the Primary Host. Set a valid value for the communication port (7777777). Use the default values for all other parameters on this tab.

On the Server Info tab of two new Application objects installed at Backup Host (marked as “sipdev2_” in example), set the Host to the name of the Backup


Version 1.0

Host. Set a valid value for the communication port (7777777). Use the default values for all other parameters on this tab.

On the Start Info tab, set the working directory to the locations of the shell scripts you created in 3.2.4 . For the Command Line parameter for the first application, use the name of shell script enabling SIP port at Primary Host (“sipdev1_UP.bat” in example):

For the Command Line parameter for the second application, use the name of shell script disabling SIP port at Backup Host (“sipdev1_DOWN.bat” in example):

Repeat step 2 for two applications starting scripts installed at Backup Host:


Version 1.0

Set Startup timeout to 8 seconds for“sipdev1_down” and “sipdev2_down”application:

3.2.6 Reaction Scripts configuration

a) Using Solution Control Interface create corresponding Alarm Reaction Scripts, which are responsible for the start of each of the Third Party Servers mentioned above :

1. “sipdev1_Primary” to start application “sipdev1_up”.


Version 1.0

2. “sipdev1_BkUp” to start application “sipdev1_down”. 3. “sipdev2_Primary” to start application “sipdev2_up”. 4. “sipdev2_BkUp” to start application “sipdev2_down”.

b) Using Solution Control Interface Alarm Reaction Wizard configure each Alarm Reaction Scripts created above :

Alarm Reaction Type set “Start a specified application” and point Alarm Reaction Script at corresponding Third Party Servers applications mentioned above:


Version 1.0

3.2.7 Alarm Conditions configuration 1. Using Configuration Manger Interface for each ( Primary and Backup ) application create two Alarm Conditions objects to handle events 4560 and 4562 for Warm Standby or 4561 and 4563 for Hot Standby:


Version 1.0

2. Configure each Alarm Condition object as fallowing:

a.) In General tab for each Alarm Condition object set category as “Critical” and set Cancel Time out to “1”.

b.) In Detect event tab set Log Event ID to 4560,4561,4562,or 4563 according to handling event ,set Selection Mode to “Select By Application” and add corresponding Primary or Backup application :


Version 1.0

c.) In Reaction Script tab add reaction scripts crated in 3.2.6 using rules :

Rule 1. Primary mode for Primary Host For Warm Standby: Alarm Condition linked with Log Event 00-04562 Warm Standby (Primary) mode activated Primary Host for the server that is running on Primary Host starts Alarm Reaction “sipdev1_Primary”. Hot Standby: Alarm Condition linked with Log Event 00-04563 Hot Standby (Primary) mode activated for the server that is running on Primary Host starts Alarm Reaction “sipdev1_Primary”.


Version 1.0

Rule 2. Primary mode for Backup Host For Warm Standby: Alarm Condition linked with Log Event 00-04562 Warm Standby (Primary) mode activated for the server that is running on Backup Host starts Alarm Reaction Scripts “sipdev2_Primary”. For Hot Standby: Alarm Condition linked with Log Event 00-04563 Hot Standby (Primary) mode activated for the server that is running on Backup Host starts Alarm Reaction Scripts “sipdev2_Primary”.


Version 1.0

Rule 3. Backup mode for Primary Host For Warm Standby: Alarm Condition linked with Log Event 00-04560 Warm Standby (backup) mode activated for the server that is running on Primary Host starts Alarm Reaction Script “sipdev1_BkUp”. For Hot Standby: Alarm Condition linked with Log Event 00-04561 Hot Standby (backup) mode activated for the server that is running on Primary Host starts Alarm Reaction Script “sipdev1_BkUp”.


Version 1.0

Rule 4. Backup mode for Backup Host For Warm Standby: Alarm Condition linked with Log Event 00-04560 Warm Standby (backup) mode activated for the server that is running on Backup Host starts Alarm Reaction “sipdev2_BkUp”. For Hot Standby: Alarm Condition linked with Log Event 00-04561 Hot Standby (backup) mode activated for the server that is running on Backup Host starts Alarm Reaction “sipdev2_BkUp”.


Version 1.0

d.) Using Solution Control Interface and telnet connecting to Cluster IP interface test Alarm Conditions and check if Common Interface going up and down as expected on each host:


Version 1.0

3.2.8 Verify that cluster control applications, alarms and script configured correctly

Make sure that Management Layer is up and running. Start Primary SIP Server. Check that it goes in primary mode. Start Backup SIP Server Check if it goes in backup mode. On primary SIP Server machine run the following command: wlbs queryport X X is the SIP Server port. Expect output something like: wlbs queryport 5060 WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. Cluster 192.168.42.76 Retrieving state for port rule 5060 Rule is enabled Packets: Accepted=9055, Dropped=0 Repeat the same command on backup SIP Server machine Expect output something like: wlbs queryport 5060 WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. Cluster 192.168.42.76 Retrieving state for port rule 5060 Rule is disabled Do manual switchover using Solution Control Interface, run wlbs queryport X again, check if Rule is enabled on primary machine and Rule is disabled on backup machine. Stop Primary Sip Server. Verify that only running Sip Server goes into primary mode (check Solution Control Interface). Run wlbs queryport X again, check if Rule is enabled on primary machine and Rule is disabled on machine.

3.3 UNIX/LINUX CONFIGURATION

3.3.1 Host configuration On each host, the /etc/hosts file should contain the record about the

common interface, in the form: <IP_address> <common_name_of_the_host>


Version 1.0

Linux: Look in the directory /etc/sysconfig/network-scripts -- you'll see a file called ifcfg-

eth0. Copy that file and edit it to create a new ifcfg-eth0:1 (Be sure to edit the contents of the file to give it the right address, network and netmask ) It will look something like this:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0:1 DEVICE=eth0:1 BOOTPROTO=static USERCTL=yes TYPE=Ethernet IPADDR=192.168.14.208 NETMASK=255.255.255.0 NETWORK=192.168.14.0 BROADCAST=192.168.14.255 ONPARENT=no SUN: On each host, inside the /etc directory you should create the file hostname.name_of_ethernet_interface:1 Where name_of_ethernet_interface is the actual name of the Ethernet interface on that machine—for example: hostname.hme0:1 This file should contain the hostname of the common interface as it is known to the DNS server and is recorded inside the /etc/hosts file. IBM AIX On IBM AIX management of the state of the common interface is provided by administrative command ifconfig. To bring up the common interface, you must issue the command: ifconfig name_of_ethernet_interface common_ip_address netmask common_ip_netmask alias To bring down the common interface, you must issue the command: ifconfig name_of_ethernet_interface common_ip_address delete This command should be wrapped by shell batch files. Each host must contain two such shell files, one to bring up the common interface, and one to bring down.

3.3.2 Virtual IP interface control script Management of common interface state is done by using administrative command ifconfig. To bring up the common interface, you must issue the fallowing command: ifconfig name_of_ethernet_interface:1 xxx.xxx.xxx.xxx up (where xxx.xxx.xxx..xxx is virtual IF IP address) To bring it down, you must issue command: ifconfig name_of_ethernet_interface:1 down


Version 1.0

Those commands should be wrapped by shell batch files. Each host must contain two such shell files, one to bring the common interface up, and another one to bring it down. Shell scripts example for Linux: #! /bin/bash # # /opt/Genesys/HA/set_ip_up.sh This file is responsible for setting IP # interface up # Genesys 2007 /sbin/ifconfig eth0:1 192.168.14.208 up #! /bin/bash # # /opt/Genesys/HA/set_ip_down.sh This file is responsible for setting IP # interface down # Genesys 2007 /sbin/ifconfig eth0:1 down Shell scripts example for SUN : #! /bin/bash # # set_ip_up.sh This file is responsible for setting IP interface up # # Genesys 2007 ifconfig dmfe0:1 192.168.14.123 up #! /bin/bash # # set_ip_down.sh This file is responsible for setting IP interface down # # Genesys 2007 ifconfig dmfe0:1 down

3.3.3 Virtual IP interface control Applications configuration a. Using Configuration Manager Interface, create four

Application objects corresponding to four scripts created in 3.3.2. using Third Party Server application template :


Version 1.0

b. On the Server Info tab of two new Application objects installed at Primary Host (marked as “Prime” in example), set the Host to the name of the Primary Host. Set a valid value for the communication port (99999). Use the default values for all other parameters on this tab.

On the Start Info tab, set the working directory to the locations of the shell scripts you created in 3.2.2 . For the Command Line parameter for the first application, use the name of shell script setting IP Interface UP (“./set_ip_up.sh” in example):


Version 1.0

For the Command Line parameter for the second application, use the name of shell script setting IP Interface DOWN (“./set_ip_down.sh” in example):

Repeat step 2 for two applications starting scripts installed at Backup Host:


Version 1.0

3.3.4 Reaction Scripts configuration

c) Using Solution Control Interface create corresponding Alarm Reaction Scripts, which are responsible for the start of each of the Third Party Servers mentioned above :

1. Script1 to start application at Primary host to set Virtual IP interface up (“LIN_HA_PRIME_UP”).

2. Script2 to start application at Primary host to set Virtual IP interface down (“LIN_HA_PRIME_DOWN”).

3. Script3 to start application at Backup host to set Virtual IP interface up (“LIN_HA_BACKUP_UP”).

4. Script4 to start application at Backup host to set Virtual IP interface down (“LIN_HA_BACKUP_DOWN”).


Version 1.0

d) Using Solution Control Interface Alarm Reaction Wizard configure each Alarm Reaction Scripts created above :

Alarm Reaction Type set “Start a specified application” and point Alarm Reaction Script at corresponding Third Party Servers applications mentioned above:


Version 1.0

3.3.5 Alarm Conditions configuration 1. Using Configuration Manger Interface for each ( Primary and Backup ) application create two Alarm Conditions objects to handle events 4560 and 4562 for Warm Standby or 4561 and 4563 for Hot Standby:


Version 1.0

2. Configure each Alarm Condition object as fallowing:

In General tab for each Alarm Condition object set category as “Critical” and set Cancel Time out to “1”.

In Detect event tab set Log Event ID to 4560,4561,4562,or 4563 according to handling event ,set Selection Mode to “Select By Application” and add corresponding Primary or Backup application :

In Reaction Script tab add reaction scripts crated in 3.3.4 using rules :

Rule 1. Primary mode for Primary Host For Warm Standby: Alarm Condition linked with Log Event 00-04562 Warm Standby (Primary) mode activated Primary Host for the server that is running on Primary Host starts Alarm Reaction Scripts 1 and 4. Hot Standby: Alarm Condition linked with Log Event 00-04563 Hot Standby (Primary) mode activated for the server that is running on Primary Host starts Alarm Reaction Scripts 1 and 4.


Version 1.0

Rule 2. Primary mode for Backup Host For Warm Standby: Alarm Condition linked with Log Event 00-04562 Warm Standby (Primary) mode activated for the server that is running on Backup Host starts Alarm Reaction Scripts 2 and 3. For Hot Standby: Alarm Condition linked with Log Event 00-04563 Hot Standby (Primary) mode activated for the server that is running on Backup Host starts Alarm Reaction Scripts 2 and 3.

Rule 3. Backup mode for Primary Host


Version 1.0

For Warm Standby: Alarm Condition linked with Log Event 00-04560 Warm Standby (backup) mode activated for the server that is running on Primary Host starts Alarm Reaction Script 1. For Hot Standby: Alarm Condition linked with Log Event 00-04561 Hot Standby (backup) mode activated for the server that is running on Primary Host starts Alarm Reaction Script 1.

Rule 4. Backup mode for Backup Host For Warm Standby: Alarm Condition linked with Log Event 00-04560 Warm Standby (backup) mode activated for the server that is running on Backup Host starts Alarm Reaction Script 4. For Hot Standby: Alarm Condition linked with Log Event 00-04561 Hot Standby (backup) mode activated for the server that is running on Backup Host starts Alarm Reaction Script 4.


Version 1.0

d.) Using Solution Control Interface and telnet connecting to Virtual IP interface test Alarm Conditions and check if Common Interface going up and down as expected on each host:

3.4 VERIFY THAT ANY TELEPHONY FUNCTION CAN BE PERFORMED ON SYNCHRONIZED CALL AFTER A SWITCHOVER

Make sure that Management Layer is up and running. Start Primary SIP Server. Check that it goes in primary mode. Start Backup SIP Server Check that it goes in backup mode.


Version 1.0

Establish the call between two sip end points. Do manual switchover using Solution Control Interface (SCI). Verify that Sip Servers role change reflected by SCI. Check if function as hold, retrieve, transfer can be perform on call established before switchover. Release the call. Establish the new call between two sip end points. Do manual switchover again using Solution Control Interface (SCI). Verify that Sip Servers roles change reflected by SCI. Check if function as hold, retrieve, transfer can be perform on call established before switchover. Release the call. Establish the new call between two sip end points. Stop Primary Sip Server. Verify that only running Sip Server goes into primary mode (check Solution Control Interface). Check if function as hold, retrieve, transfer can be perform on call established before switchover. Release the call.


Version 1.0

APPENDIX A – TROUBLESHOOTING TIPS

(1) SIP Message from end point does not make it to SIP Server. Please check the following if you have this issue.

(a) Please make sure that end point configured to send SIP message to address specified by the configuration option sip-address. The configuration option sip-address identifies the SIP interface address of SIP Server: the Virtual IP address of the NLB cluster for Windows and the Virtual IP interface for UNIX. This option must be configured for both primary and backup servers, and the option value must be the same.

(b) Make sure that end point configured to send SIP message to TCP\IP

port specified by the configuration option sip-port. This option must be configured for both primary and backup servers, and the option value must be the same. Only Primary SIP Server listens for incoming SIP requests.

(c) Check if primary SIP Server has sip-port opened for listening, protocol

TCP and protocol UDP. When log output level set to “all” (configuration option verbose) primary SIP Server log has following lines:

Port sip-port opened for listening, protocol TCP Port sip-port opened for listening, protocol UDP

(d) Check if you can ping Virtual IP: “ping sip-address”. Check that you can open connection to SIP Server using telnet: “telnet sip-address sip-port”. If you are able to ping Virtual IP but could not connect to sip-port, then most likely Virtual IP interface/Cluster control script doesn’t work correctly and SIP Messages not delivered to host with SIP Server in primary mode. For Windows see chapter Verify that cluster control applications, alarms and script configured correctly

(2) SIP Message from end point does not make it to SIP Server after switchover. Verify that Virtual IP/Cluster control applications, alarms and script function correctly. For Windows see chapter Verify that cluster control applications, alarms and script configured correctly.

(3) After switchover SIP Server doesn’t able to perform any functions on calls

existed before switchover. New calls proceeding normally.

Please check the following if you have this issue.

(a) If the Network Load Balancing (Windows) cluster is configured to operate in unicast mode (the default), primary and backup host


Version 1.0

each has to have two Ethernet adapters. First is cluster adapter that has 2 IP addresses: dedicated IP and Virtual IP: Virtual IP represents all hosts in the cluster and has to be used when configuration option sip-address:

Second has unique IP address of host. The unique IP interface should be used to configure SIP Server host in Configuration Manager and should not be used in Network Load-Balancing cluster:

C: >ipconfig Windows IP Configuration Ethernet adapter Internal: Connection-specific DNS Suffix . : ca.int.genesyslab.com IP Address. . . . . . . . . . . . : 192.168.52.64 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.52.1 Ethernet adapter NLB Cluster: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.42.76 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : 192.168.42.74 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.42.1

(b) Try not to use DNS names to avoid potential resolving problems.

(c) Verify that you can ping backup host unique IP (as it configured in Configuration Manager) from primary host and vice verse.


Version 1.0

(d) Verify that connection between primary and backup SIP Servers is established and has not been lost. Look in the primary and backup SIP Servers logs for messages: 20080 Primary/Backup T-Server SIP_TM_BCK connected 20081 Primary/Backup T-Server SIP_TM_BCK disconnected

(e) Check that backup SIP Server call data is synchronized from the primary SIP Server every time call changes it state. Look for the following type of messages in the primary and backup SIP Server logs:

@10:44:27.1180 [BSYNC] Trace: Send to backup (SIP_TM_BCK) [7984]: message EventUserEvent attr_#1005 0 attr_#1004 118 attr_#1003 1224078267 attr_#1002 3 attr_#1001 1 attr_#1000 131072 attr_#16000 1 attr_#16500 [72] 31 3D 31 0D.. AttributeUserEvent [16099]

@10:44:27.1180 [BSYNC] Trace: Received [5892]: message EventUserEvent AttributeUserEvent [16099] attr_#16500 [72] 31 3D 31 0D.. attr_#16000 1 attr_#1000 131072 attr_#1001 1 attr_#1002 3 attr_#1003 1224078267 attr_#1004 118 attr_#1005 0 (f) For SIP Server 7.5 (not applicable for 7.6 and later) check if SIP Stack

synchronization connection is established. Look for following SIP message exchange between Primary and Backup SIP Servers:

INVITE sip:gsipsync SIP/2.0 From: <sip:gsipsync>;tag=25D34670-0282-4483-A649-E66911F641FE-1 To: <sip:gsipsync> Call-ID: 289A0BB2DF73437fA79AD5FB5133C52C@gsipsync CSeq: 1 INVITE Content-Length: 0 Via: SIP/2.0/TCP 216.211.232.81:5060;branch=z9hG4bK55C0D487-B3C0-44C8-BE28-08178C64B1F5-1 Contact: <sip:216.211.232.81:5060;transport=tcp> Session-Expires: 20;refresher=uac Min-SE: 10


Version 1.0

Supported: timer SIP/2.0 200 OK From: <sip:gsipsync>;tag=25D34670-0282-4483-A649-E66911F641FE-1 To: <sip:gsipsync>;tag=E8B0A47F-3C9B-409C-83D0-3D242DA4243B-1 Call-ID: 289A0BB2DF73437fA79AD5FB5133C52C@gsipsync CSeq: 1 INVITE Via: SIP/2.0/TCP 216.211.232.81:5060;branch=z9hG4bK55C0D487-B3C0-44C8-BE28-08178C64B1F5-1;received=216.211.232.81 Contact: <sip:216.211.232.80:5060;transport=tcp> Session-Expires: 20;refresher=uac Min-SE: 10 Require: timer Supported: timer Content-Length: 0 ACK sip:216.211.232.80:5060;transport=tcp SIP/2.0 From: <sip:gsipsync>;tag=25D34670-0282-4483-A649-E66911F641FE-1 To: <sip:gsipsync>;tag=E8B0A47F-3C9B-409C-83D0-3D242DA4243B-1 Call-ID: 289A0BB2DF73437fA79AD5FB5133C52C@gsipsync CSeq: 1 ACK Content-Length: 0 Via: SIP/2.0/TCP 216.211.232.81:5060;branch=z9hG4bK55C0D487-B3C0-44C8-BE28-08178C64B1F5-2

Ha Sip Server

Documents

alarm condition

refresheruac

289a0bb2df73437fa79ad5fb5133c52cgsipsync

alarm conditions

solution control

alarm condition

genesys telecommunications

original mac