Jump to: navigation, search

Configuring SIP Feature Server

Genesys SIP Feature Server integrates with Genesys SIP Cluster to provide a SIP-based voicemail and SIP feature manager for Genesys contact centers and enterprise environments. Callers leave voicemail, and users retrieve and manage that voicemail. Administrators manage users, devices, voicemail, and call disposition (the dial plan). A distributed architecture enables scalability and enhances performance.

Standard Feature Server deployment includes a High Availability (HA) installation with the SIP Server in cluster mode and at least one active-active pair of Feature Servers should be deployed to serve one SIP Cluster node. Refer to Deployment options for more details.

You can deploy SIP Feature Server across multiple data centers, in an active-active configuration. The following image shows Feature Server deployment in External Cassandra cluster mode.

Feature Server in SIP Cluster Environment

Configuration and provisioning

Initial program configuration occurs primarily in Genesys Administrator (GA). You can create users, DNs, and mailboxes only in GA, but can use the Feature Server plug-in for Genesys Administrator Extension (GAX) to provision them with devices, voicemail, and call settings.

Dial plan

SIP Feature Server enables the configuration of the dial plan, a highly configurable set of call disposition patterns. You configure the dial plan using either of two methods:

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

Voicemail

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

Agents and other users can use the Feature Server GAX plug-in and the Telephone User Interface (TUI) to manage their personal and group voice mailboxes and call settings.

Data management

SIP Feature Server uses Apache Cassandra data clusters to replicate data across the environment, achieving scalability and high availability. Refer to Data management for more details. It is recommended to use External Cassandra cluster in the SIP Cluster environment.

Feature Server configuration options

See Configuration options for information about the SIP Feature Server configuration options.

Deploying SIP Feature Server

This section explains how to install and configure the SIP Feature Server instances for SIP Cluster.

Planning and pre-installation

Before installing and configuring SIP Feature Server, you must plan your environment and install required hardware and software. In your planning, you must:

Deployment steps

Complete these steps to install and configure the SIP Feature Server instances for SIP Cluster.

Important
For deployments using employee ID as agent login code, set the use-employee-login option in the [VoicemailServer] section to TController on all Feature Server Application objects.
Important
It is recommended to use External Cassandra cluster.

Configure voicemail

To configure voicemail in Cluster mode:

  1. In Genesys Administrator, navigate to the rm section of the Options tab of the Resource Manager (RM) application, and set the option value of the sip-header-for-dnis option to request-uri.
  2. Create a resource group of type Media control platform to make the Media Control Platform (MCP) instances in the cluster available for RM instances.
  3. Create a resource group of type gateway between SIP Server and each RM instance in the cluster.
  4. Under the SIP Cluster Switch, create a unique DN of type Voice over IP Service with the same name as the configured Direct Inward Dialing (DID). Create two DNs (DID) to Feature Server HA pair. The voicemail DNs will be used for configuring voicemail.
    • In the Annex > TServer section, configure the following options:
      • contact = ::msml
      • geo-location = <A string identifying the data center to which this DN belongs>
      • service-type = voicemail
  5. Each SIP node will be connected to one Feature Server HA pair having two voicemail IVR profiles per Feature Server HA pair. Under the Voice Platform tab, create IVR profile for Feature Server instances in the cluster as shown below:
    • service-type,value voicexml
      For Feature Server 1
    • initial-page-url, value [http: https:]//FQDN1 or //FS1 IP address:port/fs
      FQDN1 is the FQDN you created while configuring Feature Server applications, if your environment includes more than two Feature Server instances per SIP switch.
    • alternatevoicexml,value [http: https:]//FQDN2 or //FS2 IP address:port/fs
      FS2 IP address is the IP address of the "extra" Feature Server instance that is not included in FQDN1.
      For Feature Server 2
    • initial-page-url, value [http: https:]//FQDN2 or //FS2 IP address:port/fs
    • alternatevoicexml,value [http: https:]//FQDN1 or //FS1 IP address:port/fs
  6. For each IVR profile created above, configure a unique DID.
  7. Configure a GVP DID Group by specifying the following parameter in the Annex tab of the tenant:
    • Under the [gvp.dn-groups] section configure the <DNs in the group> value for each FS application in the Feature Server HA pair, where <DNs in the group> are configured DNs under a Switch with which the voicemail SIP Server Application is associated.
      Option Value
      FS1 application name DID 1
      FS2 application name DID 2
    • Under the [gvp.dn-group-assignments] section, configure the <DBID of the Voicemail IVR Profile> value for each FS application in the Feature Server HA pair.
      Option Value
      FS1 application name DBID of IVR profile created for Feature Server 1
      FS2 application name DBID of IVR profile created for Feature Server 2

Configure Message Waiting Indicator (MWI)

To configure Feature Server to issue a Message Waiting Indicator (MWI):

  1. In your SIP Proxy application, select Options > sipproxy > feature-server-address. Configure the Feature Server IP address with port 5160.
  2. To use a different SIP port from the default SIP port on the SIP Feature Server, create a [sip] section on the SIP Feature Server and add a localport option to assign the SIP port.

Notes:

  • The SIP MWI is supported only for individual mailboxes.
  • For group mailboxes, only the T-Library MWI is supported.
  • Feature Server does not accept subscriptions for device numbers (except where the mailbox number matches the device number).
  • To support SIP MWI notification, the SIP endpoints must be configured to subscribe to the voice mailbox number directly.
  • The subscription should be sent to SIP Proxy—for example, mailbox number@SIP Proxy IP.

Configuring dial-plan in Feature Server

Configuring dial-plan DNs

The SIP Cluster Switch might contain one or more dial-plan DNs. A typical SIP Cluster deployment will have one dial-plan DN configured per geo-location.

  1. Under the SIP Cluster Switch, create a DN of type Voice over IP Service named dial-plan-<datacenter>, for example, dial-plan-sfo.
  2. In the Annex > TServer section, configure the following mandatory options:
Name Value Notes Example
url A URL of a local SIP Feature Server Set this option to the URL for the local SIP Feature Server in this data center.

If there is more than one SIP Feature Server in the data center, create as many url options as needed to accommodate all of their addresses in one DN. The first option must always be named url. All consecutive options must be named url-<n>, depending on the number of deployed Feature Server instances (see url-1 below).

url=http://sfo-001.example.com:8800/
url-1 A URL of the second SIP Feature Server Set this option to the URL for the second SIP Feature Server in this data center. All consecutive options must be named url-<n>, depending on the number of deployed Feature Server instances. url-1=http://sfo-002.example.com:8800/
geo-location A string identifying the data center to which this DN belongs. geo-location=sfo
service-type feature-server

Calling profiles and its associations

Calling profile can be assigned to the following contact center objects:

  • Switch—Generic rules that are applicable for all calls in the cluster deployment.
  • User—Specific set of rules that need to be configured for a set of users.
  • Extension—Specific set of rules that need to be configured for a set of extensions.
  • Trunk—Customized dial-plan for a particular trunk because external calling profile is used for all inbound calls.
  • Softswitch—Customized dial-plan for a particular softswitch. For example, 10-digit numbers must be converted into E.164 to match PSTN carrier requirement.
  • Trunk Group—Calling profile used for predictive calls.
  • Route Point—Calling profile used only for predictive calls. This calling profile does not affect call routing.

Example of minimum required basic dial-plan configuration

The following table explains the mandatory configuration to use dial-plan.

Name Description Rule
Basic Used for digit translation. .=>${DIGITS}
Voicemail Used for voicemail access number to gcti::voicemail translation. 5555=>gcti::voicemail

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on September 4, 2018, at 15:56.