SIP Business Continuity Architecture

The SIP Business Continuity Solution defines a formal architecture to support geographic redundancy (also known as Disaster Recovery) for deployments that include Genesys SIP Server 8.1 and higher. The solution supports pairs of active sites and provides site-wise redundancy, as well as local High Availability (HA) at each site.

SIP Server Peers

As shown in the following figure, SIP Business Continuity is based on a group of four SIP Servers configured as two HA pairs, which are known as SIP Server peers. The SIP Server peers collaborate to provide Active-Active redundancy between two sites, with full HA at each site. The solution can scale by adding additional groups of four SIP Servers. Agent SIP Phones are typically configured to maintain simultaneous registrations with both SIP Server peers, whereas Agent Desktop applications maintain a login to only one peer at any given time. The SIP Server peers collaborate to deliver calls to a given agent, including 3PCC calls and direct-dialed calls, via the peer at which the agent is currently logged in. Outbound 1PCC calls can be originated via either peer, but one peer is generally preferred based on phone configuration or DNS SRV priority. For more details about SIP Business Continuity, refer to the Framework 8.1 SIP Server High-Availability Deployment Guide.

Desktop Connections

The following figure illustrates the server applications to which the desktop application can connect. These are:

• Configuration Server Proxy. The desktop must connect and log in to Configuration Server Proxy to obtain configuration data for the desktop application and the agent that is logging in.
• SIP Server. As previously noted, the desktop must connect and log in to one of the SIP Server peers.
• Stat Server. The desktop application can optionally connect to Stat Server to obtain real-time report data.

These connections utilize the Genesys ConfigLib, Tlib, and StatLib protocols, respectively. Each agent has a preferred site defined in the configuration. To provide the flexibility of configuration, the preferred site should be configurable hierarchically at the Tenant, Agent Group, and Person levels. When an agent logs in, the desktop, by default, connects and logins to the server application instances at the agent's preferred site. If the desktop is unable to log in initially to Configuration Server Proxy or SIP Server at the preferred site, or if it is subsequently unable to maintain its login to either server, it switches over its connection to the other site. These switchovers are referred to as Disaster Recovery (DR) switchovers.

Business Continuity Relationship to High Availability

All components of the SIP Business Continuity solution that support HA, including Configuration Server Proxy, SIP Server and Stat Server, are deployed with local HA at each site. In the event that the primary instance of any of these applications fails, Genesys Management Layer initiates an HA failover of that application to its backup instance. Genesys SDKs handle HA failovers through existing protocols; these HA failovers are transparent to desktop applications that utilize the SDKs. Additionally, Genesys applications that support Hot Standby High Availability (for example; SIP Server) employ synchronization (for example; call state, agent state), between the primary and backup members of an HA pair. This synchronization allows instantaneous recovery following a failure, with zero or minimal loss of stable, in-setup, or new calls. SIP Business Continuity does not involve the use of Genesys High Availability mechanisms or Genesys Management Layer and does not support synchronization between SIP Server peers. Genesys SDKs do not provide explicit support for SIP Business Continuity; therefore desktop applications must implement the Business Continuity logic discussed above at the application level. In the event of a site failure, the time typically taken for all components of the SIP Business Continuity solution to detect and recover from the failure is 60 seconds. During this time, it is expected that stable and in-setup calls, and some new calls, will be lost.