Support for Split-Node Deployments
Contents
The Siemens OpenScape PBX can be configured to operate in a SIP Business Continuity configuration. There are two supported modes:
- High-availability pair configuration, in which two OpenScape Voice nodes are physically located in the same area and share the same IP address for initiating and receiving calls.
- Split-node configuration, in which each OpenScape Voice node is geographically separated from the other. In this configuration, each PBX node has its own IP address on different subnets. Each node can be active for certain DNs; so, when a failure occurs, the remaining node will handle all calls, without taking over the IP address of the failed node.
Previous deployments of SIP Server with OpenScape Voice utilized only the first mode. Beginning with release 8.1, SIP Server supports a split-node configuration.
In a split-node configuration of the OpenScape Voice (with the same SIP Server), each OpenScape Voice node has a different IP address on different subnets. When both nodes are active, calls from each node arrive at SIP Server (typically, each node handles a subset of DNs). SIP Server recognizes all calls as coming from the same switch, as both nodes are part of the same OpenScape Voice switch.
When one of the OpenScape Voice nodes fails, the remaining node takes over all existing and future calls. SIP Server will handle existing and future calls to and from the remaining node, which has a different IP address on a different subnet. This take-over process will be transparent to endpoints (which are registered at the OpenScape Voice switch and will be re-registered at the remaining node in case of failure), to agents, and to Genesys T-Library client applications. See the Split-Node Deployment figure.
Configuring Split-Node deployment
To support the split-node configuration, all OpenScape Voice (or PBX) nodes are represented in the configuration environment as a single Voice over IP Service object with the service-type option set to softswitch.
All PBX nodes share the same FQDN, which could be resolved through the DNS SRV records. DNS SRV records must be administered in such a way that the IP address of the node, in which endpoints are registered by default, has the highest priority. SIP Server tests the availability of all resolved addresses by using OPTION requests. The available address with the highest priority is used for SIP communication. If the original node fails, endpoints are re-registered at an alternative node. SIP Server starts using the alternative node when it discovers that the original node is not available.
Configuration steps:
- Configure each SIP Server. In the SIP Server Application object, in the TServer section, configure the following options:
- sip-enable-gdns—Set this option to true. This enables the internal DNS client.
- sip-address—Set this option to the IP address of the SIP Server host computer (not the URI).
- sip-address-srv—Set this option to the FQDN of the SIP Server host computer. SIP Server will send this address as its own contact inside SIP requests to the PBX.
- Configure the Voice over IP Service DN:
- service-type—Set this to softswitch.
- contact—Specify the FQDN of Siemens PBX. The FQDN must be resolvable by DNS SRV records.
- oos-check—Specify the time interval, in seconds, in which SIP Server will send OPTION requests to transport addresses returned by DNS SRV resolution. SIP Server will send an OPTION request by transport for those addresses at which active SIP communication is not present.
- oos-force—Specify the time interval, in seconds, in which SIP Server will mark the transport address as unavailable when there is no response to the OPTION request. This configuration option applies only if the configuration option oos-check is set to a non-zero value.
- See also the following configuration options for this softswitch DN.
- Configure Extension DNs by completing the following procedure:
- (Optional) Configure a Trunk DN for SIP Server to handle outbound calls with the following option:
- contact=<FQDN of Siemens PBX>—This is the same value as configured on the softswitch DN.
Feature Limitations
Verification of split-node functionality was done with geographically-separated nodes that were configured without RG8700 as a SIP Proxy Server.