Configure SIP Feature Server applications

Your Feature Server deployment differs depending on the deployment option you choose: single-site, multisite (with one or multiple data centers), or Business Continuity (single-site or multisite). If you haven't yet decided, review the options.

You must install and configure Cassandra database management system before installing Feature Server.

Important

Feature Server versions prior to 8.1.203 might have been installed with the embedded Cassandra database. This setup is now obsolete and not recommended for new deployments.

These instructions include the Cassandra options specific to Feature Server. To learn more about Cassandra, see the Cassandra wiki and the DataStax Cassandra documentation website.

Important

After SIP Feature Server is started for the first time, the option [Cluster].disable-initial-import must be configured and set to true. For more details, refer to Configuration Options.

To deploy Feature Server on a single site, you deploy two Feature Server instances configured as an active-active HA (High Availability) pair, running with a single SIP switch and SIP Server. See Deployment Options for architectural details.

To deploy SIP Feature Server on a single site:

1. Ensure that you have met all the installation prerequisites for SIP Feature Server. If you assign port numbers, ensure that you do not use any of the reserved ports.
2. Configure the SIP Feature Server applications: In Genesys Administrator, use the supplied template (Templates > GenesysSIPFeatureServer_812.apd) to create an application. Note the Application object name, which the application installer requires.
3. Create a Host for the target machine.
4. If this is the first Feature Server instance you are deploying:
   • Designate it to handle the initial synchronization of data from Configuration Server to all Feature Servers in a tenant. In the Cluster > Options tab of the Feature Server Application in Genesys Administrator, set master to true. See Configuration options.
   • In the Cassandra section:
     • set replicationOptions to DC1=2
     • set replicationStrategyClassName to NetworkTopologyStrategy
5. For new deployments,
   1. set connection-type to cql in the Cassandra section.
      • If you use Cassandra prior to 4.X or you are deploying Feature Server in an environment that has Embedded Cassandra and your Cassandra version isn't listening on port 9042, you might need to set the value to thrift.
   2. set nodes in the Cassandra section with a list of Cassandra cluster node(s) that works with the newly deployed instance of Feature Server.
   3. set cassandra-counter to false in the VoicemailServer section. SIP Feature Server uses Cassandra counters to maintain the MWI count for the mailboxes. The Cassandra counters are not stable and may result in inconsistency in the MWI count. When cassandra-counter is set to false, Feature Server maintains consistency in the MWI count at all times.
6. For the other Feature Server, in the Cluster section of the Feature Server Application, set master to false and confsync to false.
   Important: Ensure that you designate only one Feature Server instance as the master.
7. In the Feature Server Connections tab, add the SIP Server to the Feature Server. Ensure that the PortID is the default SIP Server port.
8. Ensure that your Configuration Server history log settings are large enough to accommodate all configuration changes that occur whenever you simultaneously shut down your master Feature Server and your confsync-enabled Feature Server (note that such shutdowns are not recommended; try to leave at least one confsync-enabled server running at all times). In the [history-log] section of the Configuration Server application object:
   • set expiration to at least the maximum number of days you expect your servers to be offline
   • set max-records to the maximum number of configuration records you expect your servers to handle during the offline period

   For option details, see Configuration Server Configuration Options.

9. Review the current known issues and recommendations for this release.
10. To install Feature Server, run install.sh (Linux) or setup.exe (Windows) from the product DVD. Follow the installer prompts, using the default values except for:
    • Set the deployment mode to Standalone.
    • Supply the Cassandra cluster name (use the same name for all Cassandra instances in the Cassandra cluster).
    • Important

      Depending on the version of Feature Server you use, you might have to provide a Cassandra storage location that is not part of the installation directory and Seeds (the IP address of the master Feature Server). Setting these options initialize the embedded Cassandra used in previous releases. Skip this step if you plan to use external Cassandra with the latest version of Feature Server.
11. Set the startCassandra parameter (com.genesyslab.common.application.cassandraServer) to false in <Feature Server installed directory>\launcher.xml (or launcher_64.xml on linux).
12. Set up the co-located/external Cassandra cluster by referring the following articles:
    • Deploy co-located/external Cassandra cluster
    • Configure SIP Feature Server for co-located/external Cassandra cluster.
13. If this is the master Feature Server, disable the server firewall.
14. Repeat the above steps to create the non-master Feature Server, keeping in mind the differences between the master instance and the other instance.
15. If your environment includes more than two Feature Server instances per SIP switch, create an FQDN that includes the IP addresses of all the N Feature Server instances (the total number of instances minus 1), then set up a DNS server (your choice) to distribute the workload if the first instance goes down.

    For example, if 172.24.128.34, 172.24.128.35, and 172.24.128.36 are the IP addresses of three instances, you create the FQDN with any of the two instances: FQDN1 = fs.genesys.com, which resolves to 172.24.128.34 and 172.24.128.35. You use the IP address of the "extra" instance as the FS(n+1) IP address, and the FQDN1 value, during the Configure voicemail and Implement device management procedures.

16. To enable a Transport Layer Security autodetect (upgradable) connection, configure an autodetection port. See Introduction to Genesys Transport Layer Security in Genesys 8.1 Security Deployment Guide.
17. If you are planning to use the Dialplan functionality, provide the process-launcher option in the python section pointing to a Python 3.X executable.
18. Set the remaining Feature Server configuration options.

Appendix

Use the following configuration if you're using an Embedded Cassandra cluster in your SIP Feature Server deployment. However, note that this cluster mode is being deprecated beginning with version 8.1.203.xx and will no longer be supported in future versions.

To configure an embedded Cassandra cluster, follow all the steps from the above procedure but replace the Step-11 configuration with the following:

1. Edit the file Cassandra storage location/etc/Cassandra.yaml:
   • Verify that the file contains these properties and values, and update as needed (do not change any other values):
     • cluster_name: 'FeatureServerCluster' (or whatever name you supplied as the Cassandra cluster name during installation)
     • data_file_directories: Cassandra storage location/storage/data
     • commitlog_directory: Cassandra storage location/storage/commitlog
     • endpoint_snitch: PropertyFileSnitch/GossipingPropertyFileSnitch
     • listen_address: IP address or FQDN of the instance that you are configuring
     • saved_caches_directory: Cassandra storage location/storage/saved_caches
     • storage_port: 7000 (set each Cassandra node to 7000)
     • -seeds: master Feature Server IP address or FQDN

       Cassandra nodes use the seed node list to find each other and learn the topology of the ring.

2. For PropertyFileSnitch, in the Feature Server home/resources folder, create or edit the cassandra-topology.properties file and add the following, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • #Cassandra Node IP=Data Center:Rack
   • IP or FQDN of the FS1 host=data center 1 name:RAC1
   • IP or FQDN of the FS2 host=data center 1 name:RAC2
3. For GossipingPropertyFileSnitch, in the Feature Server home/resources folder, create or edit the cassandra-rackdc.properties file in each node and add data center and rack information specific to that node, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • dc=name of data center to which the specific node belongs
   • rack=name of rack to which the specific node belongs

You can deploy Feature Server in a multisite (multi-switch) environment, using one or multiple data centers:

• Use a single data center if your sites are co-located.
• Use multiple data centers, one for each site, if your sites are in different physical locations.

Multisite configurations require a minimum of four Feature Server instances, two for each site.

To deploy SIP Feature Server in a multisite, single-data center environment:

1. Ensure that you have met all the installation prerequisites for SIP Feature Server. If you assign port numbers, ensure that you do not use any of the reserved ports.
2. Configure the SIP Feature Server applications: In Genesys Administrator, use the supplied template (Templates > GenesysSIPFeatureServer_812.apd) to create an application. Note the Application object name, which the application installer requires.
3. Create a Host for the target machine.
4. If this is the first Feature Server instance you are deploying:
   • Designate it to handle the initial synchronization of data from Configuration Server to all Feature Servers in a tenant. In the Cluster > Options tab of the Feature Server Application in Genesys Administrator, set master to true. See Configuration options.
   • In the Cassandra section:
     • set replicationOptions to DC1=3 or more, depending on the number of nodes in the cluster: increment the value by one for each node you add beyond 4.
     • set replicationStrategyClassName to NetworkTopologyStrategy
5. For new deployments,
   1. set connection-type to cql in the Cassandra section.
      1. If you use Cassandra prior to 4.X or you are deploying Feature Server in an environment that has Embedded Cassandra and your Cassandra version isn't listening on port 9042, you might need to set the value to thrift.
   2. set nodes in the Cassandra section with a list of Cassandra cluster node(s) that works with the newly deployed instance of Feature Server.
   3. set cassandra-counter to false in the VoicemailServer section. SIP Feature Server uses Cassandra counters to maintain the MWI count for the mailboxes. The Cassandra counters are not stable and may result in inconsistency in the MWI count. When cassandra-counter is set to false, Feature Server maintains consistency in the MWI count at all times.
6. On one other Feature Server instance on each site, in the Cluster section of the Feature Server Application, set master to false and confsync to true. On all other instances, set master to false and confsync to false.
   Important: Ensure that you designate only one Feature Server instance as the master.
7. In the Feature Server Connections tab, add the SIP Server to the Feature Server. Ensure that the PortID is the default SIP Server port.
8. Ensure that your Configuration Server history log settings are large enough to accommodate all configuration changes that occur whenever you simultaneously shut down your master Feature Server and your confsync-enabled Feature Server (note that such shutdowns are not recommended; try to leave at least one confsync-enabled server running at all times). In the [history-log] section of the Configuration Server application object:
   • set expiration to at least the maximum number of days you expect your servers to be offline
   • set max-records to the maximum number of configuration records you expect your servers to handle during the offline period

   For option details, see Configuration Server Configuration Options.

9. Review the current known issues and recommendations for this release.
10. To install Feature Server, run install.sh (Linux) or setup.exe (Windows) from the product DVD. Follow the installer prompts, using the default values except for:
    • Set the deployment mode to Standalone.
    • Supply the Cassandra cluster name (use the same name for all Cassandra instances in the Cassandra cluster).
    • Important

      Depending on the version of Feature Server you use, you might have to provide a Cassandra storage location that is not part of the installation directory and Seeds (the IP address of the master Feature Server). Setting these options initialize the embedded Cassandra used in previous releases. Skip this step if you plan to use external Cassandra with the latest version of Feature Server.
11. Set the startCassandra parameter (com.genesyslab.common.application.cassandraServer) to false in <Feature Server installed directory>\launcher.xml (or launcher_64.xml on linux).
12. Set up the co-located/external Cassandra cluster by referring the following articles:
    • Deploy co-located/external Cassandra cluster
    • Configure SIP Feature Server for co-located/external Cassandra cluster.
13. If this is the master Feature Server, disable the server firewall.
14. Repeat the above steps for each Feature Server instance you want to create (at least four total), keeping in mind the differences between the master instance and the other instances.
15. If your environment includes more than two Feature Server instances per SIP switch, create an FQDN that includes the IP addresses of all the N Feature Server instances (the total number of instances minus 1), then set up a DNS server (your choice) to distribute the workload if the first instance goes down.

    For example, if 172.24.128.34, 172.24.128.35, and 172.24.128.36 are the IP addresses of three instances, you create the FQDN with any of the two instances: FQDN1 = fs.genesys.com, which resolves to 172.24.128.34 and 172.24.128.35. You use the IP address of the "extra" instance as the FS(n+1) IP address, and the FQDN1 value, during the Configure voicemail and Implement device management procedures.

16. To enable a Transport Layer Security autodetect (upgradable) connection, configure an autodetection port. See Introduction to Genesys Transport Layer Security in Genesys 8.1 Security Deployment Guide.
17. If you are planning to use the Dialplan functionality, provide the process-launcher option in the python section pointing to a Python 3.X executable.
18. Set the remaining Feature Server configuration options.

Appendix

Use the following configuration if you're using an Embedded Cassandra cluster in your SIP Feature Server deployment. However, note that this cluster mode is being deprecated beginning with version 8.1.203.xx and will no longer be supported in future versions.

To configure an embedded Cassandra cluster, follow all the steps from the above procedure but replace the Step-11 configuration with the following:

1. Edit the file Cassandra storage location/etc/Cassandra.yaml:
   • Verify that the file contains these properties and values, and update as needed (do not change any other values):
     • cluster_name: 'FeatureServerCluster' (or whatever name you supplied as the Cassandra cluster name during installation)
     • data_file_directories: Cassandra storage location/storage/data
     • commitlog_directory: Cassandra storage location/storage/commitlog
     • endpoint_snitch: PropertyFileSnitch/GossipingPropertyFileSnitch
     • listen_address: IP address or FQDN of the instance that you are configuring
     • saved_caches_directory: Cassandra storage location/storage/saved_caches
     • storage_port: 7000 (set each Cassandra node to 7000)
     • -seeds: master Feature Server IP address or FQDN

       Cassandra nodes use the seed node list to find each other and learn the topology of the ring.

2. For PropertyFileSnitch, in Feature Server home/resources folder, create or edit the cassandra-topology.properties file and add the following, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • #Cassandra Node IP=Data Center:Rack
   • IP or FQDN of the FS1 host=data center 1 name:RAC1
   • IP or FQDN of the FS2 host=data center 1 name:RAC2
3. For GossipingPropertyFileSnitch, in the Feature Server home/resources folder, create or edit the cassandra-rackdc.properties file in each node and add data center and rack information specific to that node, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • dc=name of data center to which the specific node belongs
   • rack=name of rack to which the specific node belongs

You can deploy Feature Server in a multisite (multi-switch) environment, using one or multiple data centers:

• Use a single data center if your sites are co-located.
• Use multiple data centers, one for each site, if your sites are in different physical locations.

Multisite configurations require a minimum of four Feature Server instances, two for each site. In multi-data center mode, each site contains its own data center.

To deploy SIP Feature Server in a multisite, multiple-data center environment:

1. Ensure that you have met all the installation prerequisites for SIP Feature Server. If you assign port numbers, ensure that you do not use any of the reserved ports.
2. Configure the SIP Feature Server applications: In Genesys Administrator, use the supplied template (Templates > GenesysSIPFeatureServer_812.apd) to create an application. Note the Application object name, which the application installer requires.
3. Create a Host for the target machine.
4. If this is the first Feature Server instance you are deploying:
   • Designate it to handle the initial synchronization of data from Configuration Server to all Feature Servers in a tenant.In the Cluster > Options tab of the Feature Server Application in Genesys Administrator, set master to true. See Configuration options.
   • In the Cassandra > Options tab:
     • set replicationOptions to data center 1 name=2,data center 2 name=2 (remember these data center names to use in the cassandra-topology.properties file you create or edit below)
     • set replicationStrategyClassName to NetworkTopologyStrategy
5. For new deployments,
   1. set connection-type to cql in the Cassandra section.
      1. If you use Cassandra prior to 4.X or you are deploying Feature Server in an environment that has Embedded Cassandra and your Cassandra version isn't listening on port 9042, you might need to set the value to thrift.
   2. set nodes in the Cassandra section with a list of Cassandra cluster node(s) that works with the newly deployed instance of Feature Server.
   3. set cassandra-counter to false in the VoicemailServer section. SIP Feature Server uses Cassandra counters to maintain the MWI count for the mailboxes. The Cassandra counters are not stable and may result in inconsistency in the MWI count. When cassandra-counter is set to false, Feature Server maintains consistency in the MWI count at all times.
6. On one other Feature Server instance on each site, in the Cluster section of the Feature Server Application, set master to false and confsync to true. On all other instances, set master to false and confsync to false.
   Important: Ensure that you designate only one Feature Server instance as the master.
7. In the Feature Server Connections tab, add the SIP Server to the Feature Server. Ensure that the PortID is the default SIP Server port.
8. Ensure that your Configuration Server history log settings are large enough to accommodate all configuration changes that occur whenever you simultaneously shut down your master Feature Server and your confsync-enabled Feature Server (note that such shutdowns are not recommended; try to leave at least one confsync-enabled server running at all times). In the [history-log] section of the Configuration Server application object:
   • set expiration to at least the maximum number of days you expect your servers to be offline
   • set max-records to the maximum number of configuration records you expect your servers to handle during the offline period

   For option details, see Configuration Server Configuration Options.

9. Review the current known issues and recommendations for this release.
10. To install Feature Server, run install.sh (Linux) or setup.exe (Windows) from the product DVD. Follow the installer prompts, using the default values except for:
    • Set the deployment mode to Standalone.
    • Supply the Cassandra cluster name (use the same name for all Cassandra instances in the Cassandra cluster).
    • Important

      Depending on the version of Feature Server you use, you might have to provide a Cassandra storage location that is not part of the installation directory and Seeds (the IP address of the master Feature Server). Setting these options initialize the embedded Cassandra used in previous releases. Skip this step if you plan to use external Cassandra with the latest version of Feature Server.
11. Set the startCassandra parameter (com.genesyslab.common.application.cassandraServer) to false in <Feature Server installed directory>\launcher.xml (or launcher_64.xml on linux).
12. Set up the co-located/external Cassandra cluster by referring the following articles:
    • Deploy co-located/external Cassandra cluster
    • Configure SIP Feature Server for co-located/external Cassandra cluster.
13. If this is the master Feature Server, disable the server firewall.
14. Repeat the above steps for each Feature Server instance you want to create, keeping in mind the differences between the master instance and the other instances.
15. In an environment with more than two Feature Server instances, you must create an FQDN that includes the IP addresses of all the N Feature Server instances (the total number of instances minus 1), then set up a DNS server (your choice) to distribute the workload if the first instance goes down.

    For example, if 172.24.128.34, 172.24.128.35, and 172.24.128.36 are the IP addresses of three instances, you create the FQDN with any of the two instances: FQDN1 = fs.genesys.com, which resolves to 172.24.128.34 and 172.24.128.35. You use the IP address of the "extra" instance as the FS(n+1) IP address, and the FQDN1 value, during the Configure voicemail and Implement device management procedures.

16. To enable a Transport Layer Security autodetect (upgradable) connection, configure an autodetection port. See Introduction to Genesys Transport Layer Security in Genesys 8.1 Security Deployment Guide.
17. If you are planning to use the Dialplan functionality, provide the process-launcher option in the python section pointing to a Python 3.X executable.
18. Set the remaining Feature Server configuration options.

Appendix

Use the following configuration if you're using an Embedded Cassandra cluster in your SIP Feature Server deployment. However, note that this cluster mode is being deprecated beginning with version 8.1.203.xx and will no longer be supported in future versions.

To configure an embedded Cassandra cluster, follow all the steps from the above procedure but replace the Step-11 configuration with the following:

1. Edit the file Cassandra storage location/etc/Cassandra.yaml:
   • Verify that the file contains these properties and values, and update as needed (do not change any other values):
     • cluster_name: 'FeatureServerCluster' (or whatever name you supplied as the Cassandra cluster name during installation)
     • data_file_directories: Cassandra storage location/storage/data
     • commitlog_directory: Cassandra storage location/storage/commitlog
     • endpoint_snitch: PropertyFileSnitch/GossipingPropertyFileSnitch
     • listen_address: IP address or FQDN of the instance that you are configuring
     • saved_caches_directory: Cassandra storage location/storage/saved_caches
     • storage_port: 7000 (set each Cassandra node to 7000)
     • -seeds: master Feature Server IP address or FQDN

       Cassandra nodes use the seed node list to find each other and learn the topology of the ring.

2. For PropertyFileSnitch, in the folder Feature Server home/resources, create or edit a file called cassandra-topology.properties and add the following, where the data center names are the names you specified in the replicationOptions configuration option above:
   • # Cassandra Node IP=Data Center:Rack
   • IP or FQDN of the FS1 host=data center 1 name:RAC1
   • IP or FQDN of the FS2 host=data center 1 name:RAC2
   • IP or FQDN of the FS3 host=data center 2 name:RAC1
   • IP or FQDN of the FS4 host=data center 2 name:RAC2
   • # default for unknown nodes
   • default=data center 1 name:RAC1
3. For GossipingPropertyFileSnitch, in the Feature Server home/resources folder, create or edit the cassandra-rackdc.properties file in each node and add data center and rack information specific to that node, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • dc=name of data center to which the specific node belongs
   • rack=name of rack to which the specific node belongs

Though you can achieve some degree of Business Continuity by deploying Feature Server in single-data center mode, the recommended deployment uses multiple data centers, which provides disaster recovery. All Business Continuity deployments must contain at least two Feature Server instances per site.

To deploy SIP Feature Server in Business Continuity mode:

1. Ensure that you have met all the installation prerequisites for SIP Feature Server. If you assign port numbers, ensure that you do not use any of the reserved ports.
2. Configure the SIP Feature Server applications: In Genesys Administrator, use the supplied template (Templates > GenesysSIPFeatureServer_812.apd) to create an application. Note the Application object name, which the application installer requires.
3. Create a Host for the target machine.
4. If this is the first Feature Server instance you are deploying:
   • Designate it to handle the initial synchronization of data from Configuration Server to all Feature Servers in a tenant. In the Cluster > Options tab of the Feature Server Application in Genesys Administrator, set master to true. See Configuration options.
   • In the Cassandra > Options tab:
     • set replicationOptions to data center 1 name=2,data center 2 name=2 (remember these data center names to use in the cassandra-topology.properties file you create or edit below)
     • set replicationStrategyClassName to NetworkTopologyStrategy
5. For new deployments,
   1. set connection-type to cql in the Cassandra section.
      1. If you use Cassandra prior to 4.X or you are deploying Feature Server in an environment that has Embedded Cassandra and your Cassandra version isn't listening on port 9042, you might need to set the value to thrift.
   2. set nodes in the Cassandra section with a list of Cassandra cluster node(s) that works with the newly deployed instance of Feature Server.
   3. set cassandra-counter to false in the VoicemailServer section. SIP Feature Server uses Cassandra counters to maintain the MWI count for the mailboxes. The Cassandra counters are not stable and may result in inconsistency in the MWI count. When cassandra-counter is set to false, Feature Server maintains consistency in the MWI count at all times.
6. On one other Feature Server instance on each site, in the Cluster section of the Feature Server Application, set master to false and confsync to true. On all other instances, set master to false and confsync to false.
   Important: Ensure that you designate only one Feature Server instance as the master.
7. In the Feature Server Connections tab, add the SIP Server to the Feature Server. Ensure that the PortID is the default SIP Server port.
8. Ensure that your Configuration Server history log settings are large enough to accommodate all configuration changes that occur whenever you simultaneously shut down your master Feature Server and your confsync-enabled Feature Server (note that such shutdowns are not recommended; try to leave at least one confsync-enabled server running at all times). In the [history-log] section of the Configuration Server application object:
   • set expiration to at least the maximum number of days you expect your servers to be offline
   • set max-records to the maximum number of configuration records you expect your servers to handle during the offline period

   For option details, see Configuration Server Configuration Options.

9. Review the current known issues and recommendations for this release.
10. To install Feature Server, run install.sh (Linux) or setup.exe (Windows) from the product DVD. Follow the installer prompts, using the default values except for:
    • Set the deployment mode to Standalone.
    • Supply the Cassandra cluster name (use the same name for all Cassandra instances in the Cassandra cluster).
    • Supply a Cassandra storage location, but do not use the installation directory.
    • Important

      Depending on the version of Feature Server you use, you might have to provide a Cassandra storage location that is not part of the installation directory and Seeds (the IP address of the master Feature Server). Setting these options initialize the embedded Cassandra used in previous releases. Skip this step if you plan to use external Cassandra with the latest version of Feature Server.
11. Set the startCassandra parameter (com.genesyslab.common.application.cassandraServer) to false in <Feature Server installed directory>\launcher.xml (or launcher_64.xml on linux).
12. Set up the co-located/external Cassandra cluster by referring the following articles:
    • Deploy co-located/external Cassandra cluster
    • Configure SIP Feature Server for co-located/external Cassandra cluster
13. If this is the master Feature Server, disable the server firewall.
14. Repeat the above steps for each Feature Server instance you want to create, keeping in mind the differences between the master instance and the other instances.
15. In an environment with more than two Feature Server instances, you must create an FQDN that includes the IP addresses of all the N Feature Server instances (the total number of instances minus 1), then set up a DNS server (your choice) to distribute the workload if the first instance goes down.

    For example, if 172.24.128.34, 172.24.128.35, and 172.24.128.36 are the IP addresses of three instances, you create the FQDN with any of the two instances: FQDN1 = fs.genesys.com, which resolves to 172.24.128.34 and 172.24.128.35. You use the IP address of the "extra" instance as the FS(n+1) IP address, and the FQDN1 value, during the Configure voicemail and Implement device management procedures.

16. To enable a Transport Layer Security autodetect (upgradable) connection, configure an autodetection port. See Introduction to Genesys Transport Layer Security in Genesys 8.1 Security Deployment Guide.
17. If you are planning to use the Dialplan functionality, provide the process-launcher option in the python section pointing to a Python 3.X executable.
18. Set the remaining Feature Server configuration options.

Appendix

Use the following configuration if you're using an Embedded Cassandra cluster in your SIP Feature Server deployment. However, note that this cluster mode is being deprecated beginning with version 8.1.203.xx and will no longer be supported in future versions.

To configure an embedded Cassandra cluster, follow all the steps from the above procedure but replace the Step-11 configuration with the following:

1. Edit the file Cassandra storage location/etc/Cassandra.yaml:
   • Verify that the file contains these properties and values, and update as needed (do not change any other values):
     • cluster_name: 'FeatureServerCluster' (or whatever name you supplied as the Cassandra cluster name during installation)
     • data_file_directories: Cassandra storage location/storage/data
     • commitlog_directory: Cassandra storage location/storage/commitlog
     • endpoint_snitch: PropertyFileSnitch/GossipingPropertyFileSnitch
     • listen_address: IP address or FQDN of the instance that you are configuring
     • saved_caches_directory: Cassandra storage location/storage/saved_caches
     • storage_port: 7000 (set each Cassandra node to 7000)
     • -seeds: master Feature Server IP address or FQDN

       Cassandra nodes use the seed node list to find each other and learn the topology of the ring.

2. For PropertyFileSnitch, in the folder Feature Server home/resources, create or edit a file called cassandra-topology.properties and add the following, where the data center names are the names you specified in the replicationOptions configuration option above:
   • # Cassandra Node IP=Data Center:Rack
   • IP or FQDN of the FS1 host=data center 1 name:RAC1
   • IP or FQDN of the FS2 host=data center 1 name:RAC2
   • IP or FQDN of the FS3 host=data center 2 name:RAC1
   • IP or FQDN of the FS4 host=data center 2 name:RAC2
   • # default for unknown nodes
   • default=data center 1 name:RAC1
   • For GossipingPropertyFileSnitch, in the Feature Server home/resources folder, create or edit the cassandra-rackdc.properties file in each node and add data center and rack information specific to that node, where the data center names are the names you specified in the replicationOptions configuration option earlier:
   • dc=name of data center to which the specific node belongs
   • rack=name of rack to which the specific node belongs