This feature deploys SIP RA in a clustered Rhino configuration
Below is an overview of how the RA behaves in a cluster, and any issues the Rhino administrator or developer needs to be aware of.
When a SIP RA entity is created in a Rhino cluster, each cluster node creates an instance of a SIP RA object. Each SIP RA instance will bind to the local IP interfaces on its node.
Each node has its own unique IP address. Rhino does not provide any form of IP address failover or load balancing. An external load balancer must be used if it is necessary to present a single virtual IP address for the cluster.
Activities, such as transactions and dialogs, created by the SIP RA instances on each node are local to each node. If a node fails, all SIP activities on the node will be lost, but the SIP RAs and services on other nodes can continue running, providing high availability of services.
It is possible to use replicated dialog activities. These are disabled by default. If enabled, replicated dialog activities, and service instances that are attached to them, can continue on other nodes after a failure, providing some level of fault tolerance.
In the default configuration, the SIP RA cannot be deployed in a cluster where multiple nodes are running on the same host. This is because each RA instance will try to bind to the same SIP port, and the OS will not allow this if they are on the same host.
This can be resolved by specifying two additional
configuration properties when deploying the RA:
These properties tell the RA to add an offset to the SIP port used on
each node, so that each node will use a unique port number. For example,
if the RA is configured with Port=5060, and the cluster has nodes with
node IDs 101, 102, and 103, and
PortOffset=101, the SIP ports used by
the three nodes will be 5060, 5061, and 5062 respectively.
If the SIP RA is deployed in a cluster behind an IP load balancer, the
load balancer typically provides a virtual IP address (VIP) that
external hosts use to connect to the cluster. The SIP RA has an optional
VirtualAddresses configuration property, which specifies a list of
hostnames or VIPs that the cluster is known by. This allows the SIP RA
to detect when a SIP URI or hostname should be treated as a local
address, if it matches a virtual address for the cluster. See
network address properties.
In the SLEE programming model, SBBs are location-independent, meaning they can run on any node that is part of the SLEE. SBBs do not need to know where they are running, and the SLEE does not provide this information. This allows SBBs to be portable between different SLEE implementations that may or may not support clustering.
However, in SIP applications it is often necessary to know something about the platform, such as the IP address and port that is being used by the SIP stack. For example, a proxy application must check incoming route headers, and remove the top route header if it is addressed to the proxy. To make this decision, the proxy must know the IP address and port that it is running on. In a clustered environment, the local IP address and port information may not be known in advance, so it cannot be provisioned in a profile or SBB env-entry.
To help solve this problem, the JAIN SIP RA Type provides some helper
methods that SBBs can use when they need to know the local SIP network
configuration. These methods are defined on the
interface, and are summarized below.
|Method||What it does|
Determines if a SIP URI is addressed to the SIP RA on this node or one of its virtual addresses. This is useful in the above proxy scenario — the proxy can easily check the URI in the Route header.
Determines if a hostname corresponds to the IP address of the SIP RA, or a virtual address.
Returns a SIP URI that is addressed to this node. This is useful for generating Contact or Record-Route headers. When the SIP RA is configured with virtual addresses, the first virtual address in the list will be used as the host part of the SIP URI.
Creates a Via header containing the correct address and port for this node.