Jump to: navigation, search

Architecture

SIP Feature Server provides a scalable, load-balanced architecture that enables you to add Feature Server instances as your needs expand. A Cassandra-based data cluster maintains data consistency and performance across all instances.

Deployment options

Standard Feature Server deployment includes a High Availability (HA) installation with a SIP Server pair and at least two Feature Servers, one primarily dedicated to voicemail, dial plan, and provisioning, and the other to device management. Multi-site (multi-switch) deployments replicate that basic structure for each switch. Business Continuity adds a further layer of reliability.

You can use these sample deployments as a model for your chosen deployment option.

Core Feature Server architecture

Single-site deployment

Standard single-site Feature Server architecture

Each Feature Server connects to only one SIP Server, but all Feature Servers use a common Cassandra cluster that sites can share, enabling any user to access voicemail from any site. Further, because all the Feature Server nodes share the same Cassandra database, if one Feature Server is down, the other Feature Servers can operate without loss of functionality.

To learn more about SIP Server HA deployment, see SIP Server 8.1 High-Availability Deployment Guide.

Multi-site deployment

Standard multi-site Feature Server architecture

You can deploy SIP Feature Server across multiple data centers, in an active-active configuration. Feature configuration is the same for both multi-site and single-site deployments.

You can install Feature Server in a multi-tenant framework, but each Feature Server deployment can service only a single Tenant.

Business Continuity deployment

Business Continuity provides the ability for a group of agents to continue offering critical business functions to customers in the event of a loss of all Genesys components running at a particular site. Specifically, phones can connect and be administered on either site when the other is inoperable.

Feature Server Business Continuity architecture
Important
Business Continuity deployments do not support IVR provisioning.

Feature Server Business Continuity deployment begins with a SIP Server Business Continuity deployment, then adds the standard Feature Server multisite deployment. Each site acts as the backup for the other.

Business Continuity deployment requires you to create at least one device profile for each site. You then specify Business Continuity settings for each profile.

Provisioning and dial plan setup

Initial program configuration occurs primarily in Genesys Administrator (GA). You can create users, DNs, and mailboxes only in GA. To set up your dial plan, a highly configurable set of call disposition patterns, you can select either of two methods:

  • the Feature Server plug-in for Genesys Administrator Extension (GAX)
  • the existing SIP Server methodology, using GA

Administrators can also use the Feature Server GAX plug-in to provision users, devices, voicemail, and call settings.

Important
A Feature Server's dial plan URL must be configured only on a VOIP Service DN that was created on the Switch controlled by the SIP Server that is connected to that particular Feature Server. Step 2 in Configure SIP Server for Feature Server describes creating the VOIP Service DN.

Voicemail

SIP Feature Server combines with Genesys Voice Platform (GVP) and SIP Server to handle voicemail tasks.

The Feature Server GAX plug-in and the Telephone User Interface (TUI) enable users to specify mailbox settings and manage their voicemail.

Device management

The Device Management GAX Plug-in provides an administrative interface for provisioning and management of SIP phones, including extension assignment, standard and custom configuration, firmware updates, and IVR provisioning. Feature Server supports phones behind SBCs and firewalls.

Data management

SIP Feature Server uses Apache Cassandra data clusters to replicate data across the environment, achieving scalability and high availability. Feature server supports the following types of Cassandra cluster modes:

  • Embedded Cassandra cluster
  • Co-located/External Cassandra cluster

In embedded Cassandra cluster:

  1. SIP Feature Server uses its own embedded Cassandra and Cassandra is not required to be installed separately.
  2. Cassandra starts when SIP Feature Server is started.
  3. SIP Feature Server supports Cassandra monitoring and maintenance.

In co-located/external Cassandra cluster:

  1. Cassandra must be installed and configured separately.
  2. SIP Feature Server supports Cassandra version 2.2.8 or higher.
  3. SIP Feature Server does not control Cassandra monitoring tasks such as start, restart, or stop. This control is performed separately.
  4. SIP Feature Server supports secure connection with Cassandra.

Embedded Cassandra cluster

The SIP Feature Server installer deploys the embedded Cassandra cluster.

SIP Feature Server with embedded Cassandra cluster

Co-located Cassandra cluster

In the Co-located Cassandra cluster mode, Cassandra is deployed separately but in the same host where SIP Feature Server is deployed.

SIP Feature Server with co-located Cassandra cluster

External Cassandra cluster

In the External Cassandra cluster mode, Cassandra is deployed separately and in a different host.

SIP Feature Server with external Cassandra cluster

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on April 26, 2018, at 19:54.