Jump to: navigation, search

Deploying SIP Feature Server

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

Complete these steps to configure the SIP Feature Server instances for standalone operation.

Configuring SIP Feature Server in standalone mode

<multistep> Configure SIP Feature Server applications.=

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To deploy one standalone SIP Feature Server:

  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 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 on a given switch.
    • In the Cluster > Options tab of the Feature Server Application, set master to true. See Configuration options.
    • For other Feature Servers in the cluster, in the Cluster > Options tab of the Feature Server Application, set master to false and confsync to true.
      Important: Ensure that you designate only one Feature Server instance as the master.
  5. In the Feature Server Connections tab, add the SIP Server to the Feature Server. Ensure that the PortID is the default SIP Server port.
  6. Review the current known issues and recommendations for this release.
  7. 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 the IP address of the master Cassandra server.
    • Supply a Cassandra storage location other than the installation directory.
  8. In the file <Cassandra storage location>/etc/Cassandra.yaml:
    • Verify that the file contains these properties, and update the path set at installation as needed:
      • data_file_directories: - <Cassandra storage location>/storage/data
      • commitlog_directory: - <Cassandra storage location>/storage/commitlog
      • saved_caches_directory: - <Cassandra storage location>/storage/saved_caches
      • storage_port: - 7000 (set each Cassandra node to 7000)
    • Enable the Cassandra replication of data between SIP Feature Server instances by supplying all the IP addresses of all feature servers after the instance is started:
      <SIPFS1 IP Address>,<SIPFS2 IP Address>,<SIPFS_N IP Address>
      For example:
      135.39.18.1,135.39.18.2,135.39.18.3
  9. If this is the master Feature Server, disable the server firewall.
  10. To enable a Transport Layer Security autodetect (upgradable) connection with a Configuration Server, configure the Configuration Server autodetect port. See Introduction to Genesys Transport Layer Security in Genesys 8.1 Security Deployment Guide.
  11. Set the remaining Feature Server configuration options.


|-| Configure environment monitoring.=


Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To configure monitoring for the components that you want to monitor from within the SIP Feature Server administration web application:

  1. In Genesys Administrator, add the components to be monitored in the Connections tab of Feature Server applications.
  2. Using the following table, create an http-port ID in the applications of the components that are to be monitored, where <port> is any free port in the host machine of a specific component:
Application Navigate to Value
SIP Server Options > TServer <port>
Stat Server Server Info <port>
ICON Server Info <port>
URS Server Info <port>
SIP Proxy Server Info <port>

|-| Start and verify SIP Feature Server.=

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To start and verify SIP Feature Server:

Warning
Do not start Feature Server until you have set the configuration options replicationStrategyClassName and replicationOptions. See Cassandra options.
  1. To run Feature Server in secure (https) mode:
    • Open the start.ini file and uncomment etc/jetty-ssl.xml
    • In the IVR Profile, set initial-page-url = https://Feature Server IP address or host name:8443/fs
  2. Use Genesys Administrator, not the command line, to start SIP Feature Server. If you are running more than one Feature Server, start the Master first.
  3. In Genesys Administrator, verify that the Feature Server is running.
  4. Verify that the administration Web interface is running by logging in as the Default administrator (in other words, the Default user in Configuration Server):
    <Feature Server IP address>:<port>/fs/admin
    To enable other users to log in as administrators, assign the Administrator role to them.

|-| Configure SIP Server for Feature Server.=

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To configure the SIP Server application and SIP switch DNs:

  1. On the SIP switch that is associated with the SIP Server, in the Options > TServer section, create a DN of type VoIP Service (VOIPDN = 9999, for example) to point to the Resource Manager IP address and port, and configure these options:
    • contact = <Resource Manager IP:Port>
    • service-type = voicemail
  2. To use the Feature Server administrative web application to configure and administer your dial plan, on the SIP switch that is associated with the SIP Server, create a VoIP Service DN named mixed-dialplan and configure these options:
    • service-type = extended
    • url = http://<FS Node>:8800/

      For n+1 High Availability (HA), add the following parameters:
    • url-1 = http://<FS Node2>:8800/
    • url-2 = http://<FS Node3>:8800/
    • url-<n> = http://<FS Node_N>:8800/
  3. To use your existing SIP Server dial plan to administer your dial plan, create a DN of type VoIP Service named standalone-dialplan. Specify one or more dial plan rules. See the Dial-Plan Rule section in the Framework 8.1 SIP Server Deployment Guide. The following example directs all calls to 2001 to be forwarded to voicemail; 9999 refers to the voicemail VoIP DN configured on the switch. If you use a different number, change the dial plan accordingly.
    • service-type = dial-plan
    • rulename = "2001=>2001;onbusy=9999;ondnd=9999;ontimeout=9999;timeout=1"
  4. In the SIP Server Application object, on the Options > TServer tab, configure these options:
    • dial-plan = mixed-dialplan or standalone-dialplan (the name of the dial-plan created above)
    • mwi-implicit-notify = true
    • subscription-event-allowed = "*"
  5. On the SIP switch that is associated with the SIP Server, in the Options > TServer section, create a DN of the type Extension and configure these options:
    • contact = "*"
    • gvm_mailbox = <mailbox ID>


|-| Configure for voicemail.=

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To configure Feature Server for voicemail:

  1. In Genesys Administrator, in the rm section of the Options tab of the Resource Manager (RM) application, set sip-header-for-dnis to request-uri.
  2. Create a resource group of type gateway between SIP Server and RM.
  3. Create a resource group of type Media control platform between MCP and RM.
  4. Create an IVR profile using Define New IVR Profile and create the following options:
    • service-type,value voicexml
    • initial-page-url, value [http: https:]//<Feature Server1 IP address>:8080/fs/
    • (N+1 HA only) alternatevoicexml,value [http: https:]//<Feature Server2 IP address>:8080/fs/
  5. Create a DID group and add the IVR profile created in the step above:
    • Add a DID with the same value as the one set for the VoIP DN option in the previous step. The recommended option and value are service-type and voicexml.
  6. To configure external voicemail deposit, configure a URS strategy that considers the DN/Agent dial-plan settings for business calls that land at a route point. In TRouteCall to SIP Server, the strategy must respond to the value full with UseDialPlan.
  7. Configure a URS strategy to retrieve an individual or group voicemail. This strategy must respond with TRouteCall to the P-Alcatel-CSBU header.
    For example, on this routing point the strategy should generate the following TRouteCall:
    message RequestRouteCall
    AttributeThisDN '1519'
    AttributeConnID 010a02020db9f03c
    AttributeOtherDN 'gcti::voicemail'
    AttributeLocation
    AttributeExtensions [152] 00 04 00 00..
    'SIP_HEADERS' 'P-Alcatel-CSBU'
    'P-Alcatel-CSBU' 'call_condition=localdirect;categparty=internal;rd=unconditional'
    AttributeDNIS '1519'
    AttributeRouteType 1 (RouteTypeDefault)


Partial dial plan processing

For voicemail deposit using the URS strategy, the destination of TRouteCall needs to be provided as a special voicemail forwarding number “gcti::voicemail”. If the customer wants to use the regular forwarding number (9999, for example) instead of gcti::voicemail then the number conversion dial plan (dial-plan-rule-1=9999=>gcti::voicemail) does not work by default. The following needs to be configured to support regular forwarding number.

When a call is routed to any destination using TRouteCall (business calls), then the SIP Server dial plan functionality is not activated. This dial plan restriction is configurable through an AttributeExtension of TRouteCall “UseDialPlan = partial”. The possible values of the UseDialPlan extension are: UseDialPlan = partial/full/false (default=false for internal dial plan functionality)

  • If false, the call is routed directly to the target mentioned in the TRouteCall.
  • If partial, SIP Server processes the above dial plan, and requests Feature Server to apply number translation and authorization check on target.
  • If full, Feature Server has full authority to perform number translation, authorization, and call forwarding.


|-| Configure for group voicemail.=

Warning
This Deployment Guide applies ONLY to the Legacy SIP Feature Server 8.1.200.xx release. Unless you have been told to use this documentation, use the current 8.1.2 Deployment Guide

To configure group voicemail:

  1. Create a new agent group named Agent_Group_1 under the Agent Groups folder.
  2. Add a TServer section on the Annex tab of the new Agent_Group_1 group.
  3. Create a gvm_mailbox option with the value set to 2200 (the mailbox number) in the T-Server section.
  4. Add agents to the Agent_Group_1 group.
  5. Log on to the SIP Feature Server administration page at http://<Feature Server IP address>:8080/fs/admin.
  6. Search for any user added to the Agent_Group_1 group. You can see that the group mailbox is associated with that user.
  7. Create a routing point (for example, 5000).
  8. Configure a URS strategy to deposit a group voicemail when none of the Agent group members answer the call. This strategy must respond with TRouteCall to gcti::voicemail.
    1. Configure the UseDialPlan Extensions attribute with its value set to false.
    2. Configure the gvm_mailbox with its value set to the group mailbox number.

      These configurations ensure that SIP Server does not use the SIP Feature Server dial plan and builds an INVITE to the mailbox number provided by the strategy.
  1. Load the routing point with the above strategy.
  2. Make a call to the route point loaded with this strategy. If no agent in the group answers, the call reaches the group mailbox (2200) after timeout.


|-| </multistep>

This page was last edited on August 21, 2015, at 23:36.
Comments or questions about this documentation? Contact us for support!