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 20042010 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 resourcethe 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 Systems 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

Version 1.0

SIP Server 7.6.0 HA Configuration REVISION HISTORY Revision Date Published

0.1 0.2 0.3 0.4 0.5 0.6 May 04, 2007 May 08, 2007 May 14,2007 May 16,2007 September 28,2007 October 8, 2008

3/49

Author
Timofey Buryi Timofey Buryi Timofey Buryi Timofey Buryi Timofey Buryi Taras Mytropan

Comment
Initial draft Feedback implemented Corrections Add Windows cluster comments in section 1.1 Re: G. Budilovsky Shell control script correction in section 3.3 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 Modified sections 1.1, Added APPENDIX A TROUBLESHOOTING TIPS SIP Server 8.0 improvements section 3 3.4 section is added. NLB logging is added IBM AIX info is added Approved for publication to support site. Updated NLB scripts to support restart of a backup host (3.2.3 and 3.2.4)

0.7 0.8 0.9 0.91 1.0 1.1

October 16, 2008 August 9, 2009 October 23, 2009 March 23, 2010 April 9, 2010 May 13, 2010

Taras Mytropan Taras Mytropan Taras Mytropan Taras Mytropan SIP Server Team Victor Kolesov

Version 1.0

SIP Server 7.6.0 HA Configuration

4/49

TABLE OF CONTENTS
TABLE OF CONTENTS ARCHITECTURE 1.1 1.2 2 WINDOWS PLATFORM UNIX/LINUX PLATFORM 4 6 6 7 9 9 11 13 13 16 16 16 16 20 21 24 26

SWITCHOVER WORKFLOW 2.1 2.2 WINDOWS PLATFORM UNIX/LINUX PLATFORM

CONFIGURATION 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 SIP SERVER APPLICATION CONFIGURATION WINDOWS CONFIGURATION Software requirements Network requirements Windows cluster configuration Cluster Control Script Cluster control Applications configuration Reaction Scripts configuration Alarm Conditions configuration

Verify that cluster control applications, alarms and script configured correctly33 UNIX/LINUX CONFIGURATION Host configuration Virtual IP interface control script Virtual IP interface control Applications configuration Reaction Scripts configuration Alarm Conditions configuration 33 33 34 35 38 40 44 46

VERIFY THAT ANY TELEPHONY FUNCTION CAN BE PERFORMED ON SYNCHRONIZED

CALL AFTER A SWITCHOVER APPENDIX A TROUBLESHOOTING TIPS

Version 1.0

SIP Server 7.6.0 HA Configuration

5/49

Version 1.0

SIP Server 7.6.0 HA Configuration

6/49

ARCHITECTURE
1.1 WINDOWS PLATFORM

Figure 1 Windows Architecture overview

The HA architecture for SIP Server on Windows platform uses a Network LoadBalancing 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

SIP Server 7.6.0 HA Configuration

7/49

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

SIP Server 7.6.0 HA Configuration

8/49

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

SIP Server 7.6.0 HA Configuration

9/49

2 SWITCHOVER WORKFLOW
2.1 WINDOWS PLATFORM

Figure 3 Windows Platform after switchover.

Version 1.0

SIP Server 7.6.0 HA Configuration

10/49

Figure 4 Windows Platform after Primary Server failure.

Version 1.0

SIP Server 7.6.0 HA Configuration

11/49

2.2

UNIX/LINUX PLATFORM

Figure 5 UNIX/Linux Platform after switchover.

Version 1.0

SIP Server 7.6.0 HA Configuration

12/49

Figure 6 UNIX\Linux Platform after Primary Server failure.

Version 1.0

SIP Server 7.6.0 HA Configuration

13/49

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:
Option (TServer section) sip-address Value host uri Description 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 registrar port. Has to be same for Primary and Backup applications 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 When an endpoint the configuration database. 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.

sip-port internal-registrarpersistent

string true

Configure the following Backup SIP Server options critical for HA:

Version 1.0

SIP Server 7.6.0 HA Configuration

14/49

Option (TServer section) sip-address

Value host uri

sip-port internal-registrarpersistent

string true

Description 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 registrar port. Has to be same for Primary and Backup applications 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 When an endpoint the configuration database. 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.

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

Version 1.0

SIP Server 7.6.0 HA Configuration

15/49

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

SIP Server 7.6.0 HA Configuration

16/49

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

SIP Server 7.6.0 HA Configuration

17/49

-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

SIP Server 7.6.0 HA Configuration

18/49

Version 1.0

SIP Server 7.6.0 HA Configuration

19/49

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 wont interfere with the traffic distribution.

Version 1.0

SIP Server 7.6.0 HA Configuration

20/49

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

SIP Server 7.6.0 HA Configuration

21/49

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

SIP Server 7.6.0 HA Configuration

22/49

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

SIP Server 7.6.0 HA Configuration

23/49

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

SIP Server 7.6.0 HA Configuration

24/49

Set Startup timeout to 8 seconds forsipdev1_down and sipdev2_downapplication:

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

SIP Server 7.6.0 HA Configuration

25/49

2. 3. 4.

sipdev1_BkUp to start application sipdev1_down. sipdev2_Primary to start application sipdev2_up. 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

SIP Server 7.6.0 HA Configuration

26/49

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

SIP Server 7.6.0 HA Configuration

27/49

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

SIP Server 7.6.0 HA Configuration

28/49

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

SIP Server 7.6.0 HA Configuration

29/49

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

SIP Server 7.6.0 HA Configuration

30/49

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

SIP Server 7.6.0 HA Configuration

31/49

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

SIP Server 7.6.0 HA Configuration

32/49

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

SIP Server 7.6.0 HA Configuration

33/49

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

SIP Server 7.6.0 HA Configuration Linux:

34/49

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

Look in the directory /etc/sysconfig/network-scripts -- you'll see a file called ifcfgeth0. Copy that file and edit it to create a new ifcfg-eth0:1 (Be sure to edit the

SUN:

that machinefor example:

hostname.hme0:1

hostname.name_of_ethernet_interface:1 Where name_of_ethernet_interface is the actual name of the Ethernet interface on

On each host, inside the /etc directory you should create the file

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

SIP Server 7.6.0 HA Configuration

35/49

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 # # 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 # # Genesys 2007 ifconfig dmfe0:1 down

This file is responsible for setting IP interface down

This file is responsible for setting IP interface 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

SIP Server 7.6.0 HA Configuration

36/49

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

SIP Server 7.6.0 HA Configuration

37/49

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

SIP Server 7.6.0 HA Configuration

38/49

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

SIP Server 7.6.0 HA Configuration

39/49

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

SIP Server 7.6.0 HA Configuration

40/49

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

SIP Server 7.6.0 HA Configuration

41/49

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

SIP Server 7.6.0 HA Configuration

42/49

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

SIP Server 7.6.0 HA Configuration

43/49

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

SIP Server 7.6.0 HA Configuration

44/49

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

SIP Server 7.6.0 HA Configuration

45/49

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

SIP Server 7.6.0 HA Configuration

46/49

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. 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. 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 Check if you can ping Virtual IP: ping sip-address. Check that you can open connection to SIP Server using telnet: telnet sip-address sipport. If you are able to ping Virtual IP but could not connect to sipport, then most likely Virtual IP interface/Cluster control script doesnt 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

(b)

(c)

(d)

(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 doesnt 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

SIP Server 7.6.0 HA Configuration

47/49

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 sipaddress:

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) (c)

Try not to use DNS names to avoid potential resolving problems. Verify that you can ping backup host unique IP (as it configured in Configuration Manager) from primary host and vice verse.

Version 1.0

SIP Server 7.6.0 HA Configuration (d)

48/49

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-44C8BE28-08178C64B1F5-1 Contact: <sip:216.211.232.81:5060;transport=tcp> Session-Expires: 20;refresher=uac Min-SE: 10

Version 1.0

SIP Server 7.6.0 HA Configuration Supported: timer

49/49

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-44C8BE28-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-44C8BE28-08178C64B1F5-2

Version 1.0