Configuring multi-site support
SIP Server instances operating in a SIP Cluster environment can communicate with external T-Servers/SIP Servers that might be running in the Genesys environment and support traditional multi-site functionality, such as:
- User Data Propagation
- Event Party Propagation
- Transaction Monitoring
When an external T-Server/SIP Server connects to a SIP Server instance, that SIP Server plays a "proxy" role and performs the following functions for multi-site support:
- Establishes connections with external T-Servers/SIP Servers.
- Manages its own pool of multi-site–related resources (access resources, External Routing Points for the route ISCC transaction type).
- Processes ISCC transactions for its own calls that were distributed by SIP Proxy.
- Retransmits the user data synchronization events and remote party events to SIP Server nodes.
- Reports unsuccessful non-distributed transactions by the Transaction Monitoring protocol.
SIP Server instances that do not have connections with external T-Servers/SIP Servers play a "node" role and perform the following functions for multi-site support:
- Establish connections to the SIP Servers that act as proxies.
- Contain the resources distribution among SIP Servers that act as proxies to properly detect the owner of the arrived call.
- Use the SIP Server that acts as a proxy to communicate with an external T-Server/SIP Server.
- Transmit all multi-site call updates (user data or party event ) through the appropriate SIP Server.
Note: Each external T-Server/SIP Server connects to only one SIP Server instance in the cluster.
Backward Compatibility
SIP Cluster provides backward compatibility for multi-site support and is able to communicate with previous versions of T-Servers/SIP Servers. External T-Servers/SIP Servers, when connecting to the SIP Cluster, do not require any configuration modification.
SIP Server in cluster mode supports the following transaction types: route (in both directions) and dnis-pool (for outbound calls only).
In the case of DNIS pooling, SIP Server does not support targeting to a switch which is linked to the multiple T-Server applications (load-balancing deployment).
Configuration
The following configuration options support multi-site call handling:
SIP Server Application > extrouter section:
- cluster-role - Mandatory option
- proxy-name - Mandatory option for SIP Servers with the cluster-role set to iscc-proxy
- pct-ci-req-tout
- pct-rci-tout
SIP Cluster Switch > DN of type External Routing Point > TServer section:
- proxy-name - Mandatory option
Mandatory configuration steps:
- SIP Server that is acting as ISCC proxy (cluster-role=iscc-proxy) must have configured the ISCC connection to all SIP Server instances in the cluster and to external T-Servers/SIP Servers that it serves. And vice versa, all SIP Server instances must have configured the ISCC connection to each SIP Server acting as ISCC proxy.
- To provide the ISCC functionality between external T-Servers/SIP Servers and SIP Servers in the cluster, the external T-Servers/SIP Servers must have configured the ISCC connection to the SIP Server which serves them (acting as ISCC proxy).
Note: If SIP Server has the cluster-role option set to a value of iscc-proxy and the proxy-name option has a default value (an empty string), SIP Server prints an error message to the SIP Server log and immediately triggers application shutdown.