JBoss.orgCommunity Documentation

Chapter 5. Clustering and High Availability

5.1. Mobicents SIP Servlets for JBoss: Clustering Support
5.1.1. SIP Servlets Server Cluster: Installing, Configuring and Running
5.2. Mobicents SIP Servlets for JBoss: Transparent Failover
5.2.1. MSS for JBoss Cluster: Installing, Configuring and Running
5.3. Load Balancer
5.3.1. SIP Load Balancing Basics
5.3.2. HTTP Load Balancing Basics
5.3.3. Pluggable balancer algorithms
5.3.4. Distributed load balancing
5.3.5. Implementation of the Mobicents Load Balancer
5.3.6. SIP Message Flow
5.3.7. SIP Load Balancer: Installing, Configuring and Running
5.3.8. IP Load Balancing

Mobicents supports the clustering of SIP Servlets-enabled JBoss Application Servers for performance, reliability and failover purposes. Note that only MSS for JBoss Servers can be used as cluster nodes; MSS for Tomcat Containers are not supported.

The SIP Servlets Server uses the JBoss Application Server as its servlet container, and takes advantage of its capabilities, including clustering and failover. For detailed background information about JBoss Application Server clustering refer to the JBoss Application Server Clustering Guide.

Software Prerequisites

A SIP Servlets-enabled JBoss Application Server

Before proceeding, ensure you have correctly configured your JBoss Application Server, according to SIP Servlet Server requirements:

The easiest way to set up a cluster of SIP Servlets-enabled JBoss Application Servers is to install, configure and test the binary distribution on one machine, and then copy the entire installation (directory) to the other machines in the cluster. This is the approach taken in this chapter.

Install a SIP Servlets Server with JBoss by following the instructions detailed in Section 2.1, “SIP Servlet-Enabled JBoss Application Server: Installing, Configuring and Running”.

Afer meeting the requirement you can begin to configure the server Section 5.1.1.2, “Configuring” below.

Once installed, the MSS for JBoss binary distribution requires only minor configuration in order to enable clustering.

SIP, and HTTP session state clustering is pre-configured straight out of the binary distribution. However, to enable session replication in a node, you must tag it as <distributable/> in the web.xml descriptor. This can be done either individually per application or globally for all applications.

To change the correct profile, open the web.xml configuration file, which is stored in the <install_directory>/server/all/deploy/jboss-web.deployer/conf/ directory,

Add the empty element <distributable/> as a child of the root element <web-app>.

This one configuration change is sufficient for enabling clustering capabilities in MSS for JBoss servers for all applications. For further information on session replication and clustering with JBoss, refer to Enabling session replication in your application in the JBoss Application Server Getting Started Guide.

Example 5.1. Enabling Node Session Replication in the Default web.xml Descriptor


<?xml version="1.0" encoding="utf-8"?><?xml version="1.0" encoding="ISO-8859-1"?>
<web-app
 xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
 version="2.4">
  <!-- ======================== Introduction ============================== -->
  <!-- This document defines default values for *all* web applications      -->
  <!-- loaded into this instance of Tomcat.  As each application is         -->
  <!-- deployed, this file is processed, followed by the                    -->
  <!-- "/WEB-INF/web.xml" deployment descriptor from your own               -->
  <!-- applications.                                                        -->
  <!--                                                                      -->
  <!-- WARNING:  Do not configure application-specific resources here!      -->
  <!-- They should go in the "/WEB-INF/web.xml" file in your application.   -->
  <!-- =========== Common Context Params ================================== -->
  <!-- JBossInjectionProvider provides resource injection for managed beans. -->
  <!-- See JSF 1.2 spec section 5.4 for details.                             -->
  <distributable/>
 <context-param>
  <param-name>com.sun.faces.injectionProvider</param-name>
  <param-value>org.jboss.web.jsf.integration.injection.JBossInjectionProvider</param-value>
 </context-param>

Clustering with MSS for JBoss nodes requires running all of the nodes using the "all" Server Configuration Profile, which is specified when you invoke run.sh or run.bat.

Running MSS for JBoss with the "all" Configuration Profile, on Linux

To run the server on Linux using the "all" Configuration Profile, start the server with the following command:

MSS-jboss-<version>]$ ./bin/run.sh -c all
Running MSS for JBoss with the "all" Configuration Profile, on Windows

To run the server on Windows using the "all" Configuration Profile, open the Command Prompt, change your folder to the topmost folder of your MSS for JBoss installation, and issue the following command:

C:Usersuser\<username>My DownloadsMSS-jboss-<version>>binrun.bat -c all
Distributing requests between nodes

Together with the application server nodes, it is advised to run a SIP load-balancer or an IP load-balancer. The IP load balancer will distribute the traffic evenly between the nodes. A load-balancer is a single entry-point to all nodes. All calls should be made through the load balancer if High Availability is required. For more information about load balancing, refer to Section 5.3.5, “Implementation of the Mobicents Load Balancer”.

By default, the servers are configured with one SIP load-balancer set to the IP address 127.0.0.1. This is specified in the balancers attribute in the server.xml configuration file as follows:


<Service name="jboss.web" 
      className="org.mobicents.servlet.sip.startup.failover.SipStandardBalancerNodeService"
  balancers="127.0.0.1"  
  sipApplicationDispatcherClassName="org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl"
concurrencyControlMode="None" 
  darConfigurationFileLocation="conf/dars/mobicents-dar.properties">

Multiple load balancers can be specified and all of them will be updated on the health status of the node. The complete syntax for the balancers string is the following:


<Service name="jboss.web" 
      ...
  balancers="ipAddress1:sipPort1:rmiPort1;ipAddress2:sipPort2:rmiPort2;..3...4.."  
  ...>

If the RMI port is omitted port 2000 is assumed, and if the SIP port is omitted 5065 is assumed.

Warning

The SIP port specified in the balancers string for each balancer refers to the internal SIP port of the SIP balancer. That is because the internal port faces the cluster nodes directly. Requests coming through the internal port will go to the external port and vice versa. If you put the external port in the balancers string, then the SIP LB will assume that the requests comes from outside the cluster and it will route it back to some cluster node instead of routing it outside the cluster as expected. Always use the SIP internal port in the balancers string. Exception to this rule is when a single port is used for internal and external ports in the SIP load balancer. In that case the direction analysis is done based on Via headers and the requests are routed correctly without extra settings.

When multiple SIP load balancers are specified, the outgoing requests will always go through the first one, or an IP load balancer can be used and the requests will be distributed based on the IP balancer policy. To route the outgoing requests to a particular IP address (the IP load balancer address for example) the outboundProxy property can be used:


<Service name="jboss.web" 
      ...
  balancers="127.0.0.1:5060:2000;127.0.0.1:5160:2100"  
outboundProxy="127.0.0.1:5500"
  ...>

In this example configuration all outbound requests will go through 127.0.0.1:5500, while the node will perform the health checks against two SIP load balancers. If the 127.0.0.1:5500 machine is an IP load balancer it should be configured to spray the SIP load balancers and they will route the requests outside the cluster reliably.

The outboundProxy attribute overrides the default effect of specifying a SIP port for SIP load balancers in the balancers string.

A Mobicents SIP Servlets Server for JBoss cluster does not employ any standby nodes. Typically, therefore, proxies and registrars must share the user location table by using a database cluster.

The Mobicents SIP load balancer, which is a SIP Call ID-aware load balancer, is used as the intermediary. The SIP load balancer forwards stateful transaction requests to cluster nodes based on its provisioning algorithm. The SIP load balancer acts as an entry-point to the cluster and distributes the incoming requests between nodes. It is always advised to use a SIP load balancer or an IP load balancer in a cluster configuration.

The SIP Stack used by the Mobicents SIP Servlets for JBoss supports ESTABLISHED SIP DIALOG failover. This means that failover will occur only on established calls (SIP Dialogs which are in the CONFIRMED state as per RFC 3261) and calls that are in the process of being setup will not be failed over (SIP Dialogs which are in the EARLY state as per RFC 3261).

Testing a cluster

This choice of implementation has many benefits:


The Mobicents SIP load balancer is used to balance the load of SIP service requests and responses between nodes in a SIP Servlets Server cluster. Both MSS for JBoss and MSS for Tomcat servers can be used in conjunction with the SIP load balancer to increase the performance and availability of SIP services and applications.

In terms of functionality, the Mobicents SIP load balancer is a simple stateless proxy server that intelligently forwards SIP session requests and responses between User Agents (UAs) on a Wide Area Network (WAN), and SIP Servlets Server nodes, which are almost always located on a Local Area Network (LAN). All SIP requests and responses pass through the SIP load balancer.

All User Agents send SIP messages, such as INVITE and MESSAGE, to the same SIP URI (the IP address and port number of the SIP load balancer on the WAN). The load balancer then parses, alters, and forwards those messages to an available node in the cluster. If the message was sent as a part of an existing SIP session, it will be forwarded to the cluster node which processed that User Agent's original transaction request.

The SIP Servlets Server that receives the message acts upon it and sends a response back to the SIP load balancer. The SIP load balancer reparses, alters and forwards the message back to the original User Agent. This entire proxying and provisioning process is carried out independent of the User Agent, which is only concerned with the SIP service or application it is using.

By using the load balancer, SIP traffic is balanced across a pool of available SIP Servlets Servers, increasing the overall throughput of the SIP service or application running on either individual nodes of the cluster. In the case of MSS for JBoss's </distributed> capabilities, load balancing advantages are applied across the entire cluster.

The SIP load balancer is also able to fail over requests mid-call from unavailable nodes to available ones, thus increasing the reliability of the SIP service or application. The load balancer increases throughput and reliability by dynamically provisioning SIP service requests and responses across responsive nodes in a cluster. This enables SIP applications to meet the real-time demand for SIP services.

In addition to the SIP load balancing, there are several options for coordinated or cooperative load balancing with other protocols such as HTTP. Typically, a JBoss Application Server will use apache HTTP server with mod_jk, mod_proxy, mod_cluster or similar extension installed as an HTTP load balancer. This apache-based load balancer will parse incoming HTTP requests and it will look for the session ID of those requests in order to ensure all requests from the same session arrive at the same application server. By default, this is done by examining the jsessionid HTTP cookie or GET parameter and looking for the jvmRoute assigned to the session. The typical jsessionid value is of the form <sessionId>.<jvmRoute> (e.g. mysessionid323424.node1 where node1 is the jvmRoute component). The very first request for each new HTTP session do not have any session ID assigned, thus apache routes the request to a random application server node. When the node responds it assigns a session ID and jvmRoute to the response of the request in a HTTP cookie and this response goes back to the client through apache, which keeps track of which node owns which jvmRoute. Once, the very first request is served this way, the subsequent requests from this session will carry the assigned cookie and the apache load balancer will always route the requests to the node, which advertised itself as the jvmRoute owner.

Instead of using apache, an integrated HTTP load balancing is also available. The SIP load balancer has an HTTP port where you could direct all incoming HTTP requests. The integrated HTTP load balancer behaves exactly like apache by default, but this behaviour is extensible and can be overridden completely with the pluggable balancer algorithms. The integrated HTTP load balancer is much easier to configure and generally requires no effort, because it reuses most SIP settings ans assumes reasonable default values.

Unlike the native apache, the integrated HTTP load balancer is written completely in Java, thus a performance penalty should be expected when using it. However, the integrated HTTP balancer has an advantage when related SIP and HTTP requests must stick to the same node.

The SIP/HTTP load balancer exposes an interface to allow users to customize the routing decision making for special purposes. By default there are three built-in algorithms. Only one algorithm is active at any time and it is specified with the algorithmClass property in the configuration file.

It is completely up to the algorithm how and whether to support distributed architecture or how to store the information needed for session affinity. The algorithms will be called for every SIP and HTTP request and other significant events to make more informed decisions.

The following is a list o the built-in algorithms:

The Mobicents SIP load balancer appends itself to the Via header of each request, so that returned responses are sent to the SIP Balancer before they are sent to the originating endpoint.

The load balancer also adds itself to the path of subsequent requests by adding Record-Route headers. It can subsequently handle mid-call failover by forwarding requests to a different node in the cluster if the node that originally handled the request fails or becomes unavailable. The SIP load balancer immediately fails over if it receives and unhealthy status, or irregular heartbeats from a node.

The SIP Servlets Server extends the SipStandardService class, which extends the Tomcat StandardService class. The StandardService class is responsible for implementing the Tomcat Service interface.

In Tomcat architecture, a service is an intermediate component which resides inside a server, and binds one or more Connectors to exactly one Engine. When the service is started, the new SipStandardBalancerNodeService looks up its configuration information and obtains the SIP load balancer address. The heartbeat and health status is sent to the SIP load balancer address to identify the service as an available node of the cluster.

The node parameters are configurable through their MBean interfaces; information on their configuration is provided in the following sections.

In advanced configurations, it is possible to run more than one SIP load balancer.

Figure 5.3, “Basic IP and Port Cluster Configuration” describes a basic IP and Port Cluster Configuration. In the diagram, the SIP load balancer is the server with the IP address of 192.168.1.1.


Configuring the SIP load balancer and the two SIP Servlets-enabled Server nodes is described in Configuring the Mobicents SIP Load Balancer and Servlet Server Nodes.

Procedure 5.1. Configuring the Mobicents SIP Load Balancer and Servlet Server Nodes

  1. Configure lb.properties Configuration Properties File

    Configure the SIP load balancer's Configuration Properties file by substituting valid values for your personal setup. Example 5.2, “Complete Sample lb.properties File” shows a sample lb.properties file, with key element descriptions provided after the example. The lines beginning with the pound sign are comments.

    Example 5.2. Complete Sample lb.properties File

    # Mobicents Load Balancer Settings
    # For an overview of the Mobicents Load Balancer visit http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm
    
    # The binding address of the load balancer
    host=127.0.0.1
    
    # The RMI port used for heartbeat signals
    rmiRegistryPort=2000
    
    # The SIP port used where client should connect
    externalPort=5060
     
    # The SIP port from where servers will receive messages
    # delete if you want to use only one port for both inbound and outbound)
    # if you like to activate the integrated HTTP load balancer, this is the entry point
    internalPort=5065
     
    # The HTTP port for HTTP forwarding
    httpPort=2080
    
    #Specify UDP or TCP (for now both must be the same)
    internalTransport=UDP
    externalTransport=UDP
    
    # If you are using IP load balancer, put the IP address and port here
    #externalIpLoadBalancerAddress=127.0.0.1
    #externalIpLoadBalancerPort=111
     
    # Requests initited from the App Servers can route to this address (if you are using 2 IP load balancers for bidirectional SIP LB)
    #internalIpLoadBalancerAddress=127.0.0.1
    #internalIpLoadBalancerPort=111
    
    # Designate extra IP addresses as serer nodes
    #extraServerNodes=222.221.21.12:21,45.6.6.7:9003,33.5.6.7,33.9.9.2
    
    # Call-ID affinity algortihm settings. This algorithm is the default. No need to uncomment it.
    #algorithmClass=org.mobicents.tools.sip.balancer.CallIDAffinityBalancerAlgorithm
    # This property specifies how much time to keep an association before being evitcted.
    # It is needed to avoid memory leaks on dead calls. The time is in seconds.
    #callIdAffinityMaxTimeInCache=500
    
    # Uncomment to enable the consistent hash based on Call-ID algorithm.
    #algorithmClass=org.mobicents.tools.sip.balancer.HeaderConsistentHashBalancerAlgorithm
    # This property is not required, it defaults to Call-ID if not set, cna be "from.user" or "to.user" when you want the SIP URI username
    #sipHeaderAffinityKey=Call-ID
    #specify the GET HTTP parameter to be used as hash key
    #httpAffinityKey=appsession
     
    # Uncomment to enable the persistent consistent hash based on Call-ID algorithm.
    #algorithmClass=org.mobicents.tools.sip.balancer.PersistentConsistentHashBalancerAlgorithm
    # This property is not required, it defaults to Call-ID if not set
    #sipHeaderAffinityKey=Call-ID
    #specify the GET HTTP parameter to be used as hash key
    #httpAffinityKey=appsession
     
    #This is the JBoss Cache 3.1 configuration file (with jgroups), if not specified it will use default
    #persistentConsistentHashCacheConfiguration=/home/config.xml
     
    # Call-ID affinity algortihm settings. This algorithm is the default. No need to uncomment it.
    #algorithmClass=org.mobicents.tools.sip.balancer.CallIDAffinityBalancerAlgorithm
    # This property specifies how much time to keep an association before being evitcted.
    # It is needed to avoid memory leaks on dead calls. The time is in seconds.
    #callIdAffinityMaxTimeInCache=500
    
    # Uncomment to enable the consistent hash based on Call-ID algorithm.
    #algorithmClass=org.mobicents.tools.sip.balancer.HeaderConsistentHashBalancerAlgorithm
    # This property is not required, it defaults to Call-ID if not set, cna be "from.user" or "to.user" when you want the SIP URI username
    #sipHeaderAffinityKey=Call-ID
    #specify the GET HTTP parameter to be used as hash key
    #httpAffinityKey=appsession
    
    # Uncomment to enable the persistent consistent hash based on Call-ID algorithm.
    #algorithmClass=org.mobicents.tools.sip.balancer.PersistentConsistentHashBalancerAlgorithm
    # This property is not required, it defaults to Call-ID if not set
    #sipHeaderAffinityKey=Call-ID
    #specify the GET HTTP parameter to be used as hash key
    #httpAffinityKey=appsession
     
    #This is the JBoss Cache 3.1 configuration file (with jgroups), if not specified it will use default
    #persistentConsistentHashCacheConfiguration=/home/config.xml
    
    #Adjusting the heatbeat. The hearbeat must be specified together with the individual server JAIN SIP property org.mobicents.ha.javax.sip.HEARTBEAT_INTERVAL
    #If a node doesnt check in within that time (in ms), it is considered dead
    nodeTimeout=5100
    #The consistency of the above condition is checked every heartbeatInterval milliseconds
    heartbeatInterval=5000
    
    
    #JSIP stack configuration.....
    javax.sip.STACK_NAME = SipBalancerForwarder
    javax.sip.AUTOMATIC_DIALOG_SUPPORT = off
    // You need 16 for logging traces. 32 for debug + traces.
    // Your code will limp at 32 but it is best for debugging.
    gov.nist.javax.sip.TRACE_LEVEL = 32
    gov.nist.javax.sip.DEBUG_LOG = logs/sipbalancerforwarderdebug.txt
    gov.nist.javax.sip.SERVER_LOG = logs/sipbalancerforwarder.xml
    gov.nist.javax.sip.THREAD_POOL_SIZE = 64
    gov.nist.javax.sip.REENTRANT_LISTENER = true
    
                

    host

    Local IP address, or interface, on which the SIP load balancer will listen for incoming requests.

    externalPort

    Port on which the SIP load balancer listens for incoming requests from SIP User Agents.

    internalPort

    Port on which the SIP load balancer forwards incoming requests to available, and healthy, SIP Servlets Server cluster nodes.

    rmiRegistryPort

    Port on which the SIP load balancer will establish the RMI heartbeat connection to the application servers. When this connection fails or a disconnection instruction is received, an application server node is removed and handling of requests continues without it by redirecting the load to the lie nodes.

    httpPort

    Port on which the SIP load balancer will accept HTTP requests to be distributed across the nodes.

    internalTransport

    Transport protocol for the internal SIP connections associated with the internal SIP port of the load balancer. Possible choices are UDP, TCP and TLS.

    externalTransport

    Transport protocol for the external SIP connections associated with the external SIP port of the load balancer. Possible choices are UDP, TCP and TLS. It must match the transport of the internal port.

    externalIpLoadBalancerAddress

    Address of the IP load balancer (if any) used for incoming requests to be distributed in the direction of the application server nodes. This address may be used by the SIP load balancer to be put in SIP headers where the external address of the SIP load balancer is needed.

    externalIpLoadBalancerPort

    The port of the external IP load balancer. Any messages arriving at this port should be distributed across the external SIP ports of a set of SIP load balancers.

    internalIpLoadBalancerAddresst

    Address of the IP load balancer (if any) used for outgoing requests (requests initiated from the servers) to be distributed in the direction of the clients. This address may be used by the SIP load balancer to be put in SIP headers where the internal address of the SIP load balancer is needed.

    internalIpLoadBalancerPort

    The port of the internal IP load balancer. Any messages arriving at this port should be distributed across the internal SIP ports of a set of SIP load balancers.

    extraServerNodes

    Comma-separated list of hosts that are server nodes. You can put here alternative names of the application servers here and they will be recognized. Names are important, because they might be used for direction-analysis. Requests coming from these server will go in the direction of the clients and will not be routed back to the cluster.

    algorithmClass

    The fully-qualified Java class name of the balancing algorithm to be used. There are three algorithms to choose from and you can write your own to implement more complex routing behaviour. Refer to the sample configuration file for details about the available options for each algorithm. Each algorithm can have algorithm-specific properties for fine-grained configuration.

    nodeTimeout

    In milliseonds. Default value is 5100. If a server node doesnt check in within this time (in ms), it is considered dead.

    heartbeatInterval

    In milliseconds. Default value is 5000 milliseonds. The hearbeat interval must be the same or close to the interval specified in the JAIN SIP property on the server machines - org.mobicents.ha.javax.sip.HEARTBEAT_INTERVAL

  2. Configure the server.xml configuration file

    Ensure the following attributes are configured for the <service> element in server.xml.

    • The className attribute must have the value org.mobicents.servlet.sip.startup.failover.SipStandardBalancerNodeService instead of org.mobicents.servlet.sip.startup.SipStandardService.

    • The balancers attribute must contain a IP address (or list of addresses) of the SIP load balancer(s) to which heartbeat information will be sent.

    • The sipPathName attribute must contain the following value org.mobicents.ha to indicate that the server will be using the Mobicents JAIN SIP HA SIP Stack which is an extension of the JAIN SIP Stack offering transparent replication.

the SIP load balancer uses Java Logging as a logging mechanism. As such you cna configure it through a property file and specify the property file to be used by using the following command -Djava.util.logging.config.file=./lb-logging.properties. Please refer to JDK logging for more informationon how to configure the Java logging.

Configuration File Locations

On MSS for Tomcat server installations, server.xml is located in <install_directory>/conf.

On MSS for JBoss server installations, the default server.xml configuration file is located in server/default/deploy/jboss-web.deployer.

On MSS for JBoss installations, with JBoss clustering support enabled, the "all" server.xml file must be configured. It is located in server/all/deploy/jboss-web.deployer.

To determine what profile should be altered for each MSS for JBoss installation, refer to Section 5.1, “Mobicents SIP Servlets for JBoss: Clustering Support”.

Easy Node Configuration with JMX

Both SIP Servlet-enabled JBoss and Tomcat have JMX (Java Management Extensions) interfaces that allow for easy server configuration. The JMX Console is available once the server has been started by navigating to http://localhost:8080/jmx-console/.

Both the balancers and heartBeatInterval attribute values are available under serviceName=jboss.web,type=Service in the JMX Console.

balancers

Host names of the SIP load balancer(s) with corresponding addBalancerAddress and removeBalancerAddress methods.

heartBeatInterval

Interval at which each heartbeat is sent to the SIP load balancer(s).

Procedure 5.2. Running the SIP Load Balancer and Servlet Server Nodes

  1. Start the SIP Load Balancer

    Start the SIP load balancer, ensuring the Configuration Properties file (lb.properties in this example) is specified. In the Linux terminal, or using the Windows Command Prompt, the SIP Load Balancer is started by issuing a command similar to this one:

    java -jar sip-balancer-1.0-20080829.103906-21-jar-with-dependencies.jar lb-configuration.properties

    Executing the SIP load balancer produces output similar to the following example:

    home]$ java -jar sip-balancer-1.0-20080829.103906-21-jar-with-dependencies.jar lb-configuration.properties 
    Oct 21, 2008 1:10:58 AM org.mobicents.tools.sip.balancer.SIPBalancerForwarder start
    INFO: Sip Balancer started on address 127.0.0.1, external port : 5060, port : 5065
    Oct 21, 2008 1:10:59 AM org.mobicents.tools.sip.balancer.NodeRegisterImpl startServer
    INFO: Node registry starting...
    Oct 21, 2008 1:10:59 AM org.mobicents.tools.sip.balancer.NodeRegisterImpl startServer
    INFO: Node expiration task created
    Oct 21, 2008 1:10:59 AM org.mobicents.tools.sip.balancer.NodeRegisterImpl startServer
    INFO: Node registry started

    The output shows the IP address on which the SIP load balancer is listening, as well as the external and internal listener ports.

  2. Configure SIP Servlet Server Nodes

    SIP Servlets Server nodes can run on the JBoss Application Server, or the Tomcat Servlet Container. The SIP Servlets Server binary distributions define the type of SIP Servlets Server nodes used, and should already be installed from Software Prerequisites.

    The server.xml file specifies the nodes used. Because there is more then one client node specified, unique listener ports must be specified for each node to monitor HTTP and/or SIP connections. Example 5.3, “Changing the SIP Connector Port for Servlet Server Nodes in server.xml” describes the affected element in the server.xml file.

    Configuration File Location

    For the JBoss SIP Servlets Server binary distribution, server.xml is located in the <install_directory>/server/all/deploy/jboss-web.deployer/ directory. For the Tomcat binary distribution, server.xml is located in the <install_directory>/conf/ directory.


  3. Start Load Balancer Client Nodes

    Start all SIP load balancer client nodes.