Configuring Routing
The pages in this section will give you an idea of the important aspects to be considered when providing routing services in SIP cluster and the different configuration options that are involved in Universal Routing Server (URS) and Orchestration Server (ORS).
Routing Principles in SIP Cluster
Given below is a sample deployment diagram to illustrate the routing principles in SIP Cluster:
In the above sample, there are two Data Centers with two SIP Cluster nodes each. All 4 SIP Cluster nodes talk to the same SIP Cluster switch, which is used to configure all DNs except the VQ DNs. The VQ DNs are configured using a separate switch.
SIP Cluster Nodes and SIP Cluster Switch
- Each SIP Cluster node has a dedicated routing solution consisting of URS, ORS, and Stat Server.
- All SIP Cluster nodes share the same switch where all routing point DNs and agent DNs are configured.
- The same strategy is loaded to all nodes. This allows for distribution of inbound calls across all SIP Cluster nodes and processing them using the same strategy.
ORS Deployment
- A dedicated 2-node ORS Cluster is deployed to serve each SIP Cluster node.
- By default ORS instances are running on the primary and backup SIP Cluster VMs.
- A dedicated Cassandra ring is deployed for each ORS Cluster.
- cassandra-keyspace-name: Orchestration
- cassandra-nodes: FQDN_SIP_Cluster_Primary_VM; FQDN_SIP_Cluster_Backup_VM
VQ Switch Deployment and Connectivity
VQ switches offer a distributed agent reservation solution for a blended environment (voice and multi-media). A VQ switch is a centralized place for VQ DN configuration and they help simplify provisioning. VQ switches also result in a performance improvement by helping unload VQ traffic from the SIP cluster.
In the above sample, there is one VQ SIP Server pair per DC. Having independent SIP Server pairs configured with the same switch is possible because we are not provisioning any real DNs on this switch. Only VQ DNs are on this switch. As a result, the SIP Server pair do not interfere with each other.
- One VQ SIP Server is deployed per DC.
- All VQ SIP Servers share the same VQ switch. Only VQ DNs are configured in the VQ switch.
- Each URS, ORS, and routing Stat Server instance is connected to all VQ SIP Servers in the environment.
Mandatory URS Configuration Options
The following are mandatory options that need to be configured in the default section of the URS application:
- environment—Set to tcluster.
- agent_reservation—Set to true or implicit.
environment
This option is configured at the URS Application-level.
Default Value: none
Valid Values: Comma separated list of the following values:
tcluster : Set to deploy URS in a SIP Cluster environment.
outbound : Set to integrate URS with OCS so that all Agents/Places can participate in an Outbound campaign for the purpose of sharing multi-skilled Agents and/or Places.
Changes Take Effect: After restart
Informs URS of various environment parameters in situations where URS should undertake certain actions to guarantee it functions successfully in the particular environment. See the Universal Routing 8.1 Reference Manual for additional details on this option.
agent_reservation
This option can be configured at the T-Server Application-level and at the URS Application-level. The settings at the T-Server Application-level take precedence over the URS Application-level settings.
Default Value: false
Valid Values: true, false, implicit
Changes Take Effect: Immediately
Enables two or more Universal Routing Servers to work cooperatively by preventing them from trying to route to the same target. To turn agent reservation on, this option must be set to true or implicit for URS. See the Universal Routing 8.1 Reference Manual for additional details on this option.
Other URS Configuration Options
The following options are configured in the default section of the URS application:
prototype
This option is configured at the URS Application-level.
Default Value: none
Valid Values: Name of a URS application
Changes Take Effect: After restart
Allows multiple URS instances to share a common configuration which is presented by a single Prototype URS Application object which should be configured in Configuration Manager, and does not require an installation. All URS instances referring to these URS applications through the prototype option inherit a set of servers, tenants, and options defined in the Prototype Application object. In cases of conflicting options, the URS application overrides the same options specified in the Prototype Application object. Lists of tenants and/or servers are merged (with the removal of duplicates).
rlimit_attaches
This option is configured at the URS Application-level.
Default Value: 100 for SIP Cluster environments, and 0 (zero) for regular environments
Valid Values: Non-negative number of occurrences
Changes Take Effect: Immediately
Controls how many requests to attach user data that a strategy can make before being terminated by URS. When a termination happens, it is followed by a corresponding alarm message. A value of 0 (zero) means there is no limit set.
Note: The rlimit_attaches and rlimit_failures options control how many CTI resources every call can use. The purpose of these options is to limit the degree that incorrectly written strategies can affect the call center.
rlimit_failures
This option is configured at the URS Application-level.
Default Value: 10 for SIP Cluster environments, and 0 for regular environments
Valid Values: Non-negative number of occurrences
Changes Take Effect: Immediately
Controls how many failures in a row of routing or mandatory treatment requests a strategy can make before being terminated by URS. When a termination happens, it is followed by a corresponding alarm message. A value of 0 (zero) means that there is no limit set.
Note: The rlimit_attaches and rlimit_failures options control how many CTI resources every call can use. The purpose of these options is to limit the degree that incorrectly written strategies can affect the call center.
virtual_queue_attach
This option is configured at the URS Application-level.
Default Value: false in SIP Cluster environments, and true in regular environments
Valid Values: true, false
Changes Take Effect: Immediately
When set to true, URS propagates AttachedDataChanged events through Virtual Queue DNs, and does not when set to false.
Note: The purpose of this option is to reduce network traffic by limiting the amount of changed events in the attached data of calls.
IRD Configuration Option
The following option is configured in the default section of the IRD application:
tcluster
This option is configured at the IRD Application-level.
Default Value: false
Valid Values: true or false
Changes Take Effect: After restart
When set to true, IRD only provides the set of objects that can be used in a SIP Cluster environment. This includes the applicable functions, and certain blocks in the ‘Segmentation’, ‘Routing’ and ‘Data and Services’ groups of objects.
Note: Some predefined objects like Macros and Statistics are not supported in the SIP Cluster environment, but are still visible in the IRD Shortcut Bar.
Existing Options Changed in SIP Cluster Environment
- The call_kpl_time option by default becomes 0 (zero means no “keep alive” notifications) in the SIP Cluster environment (instead of 60 in a non SIP Cluster environment). The minimum value that this option should be set to in the SIP Cluster environment is 600. The purpose of this is to limit network traffic resulted from extreme amounts of call is still in queue notification messages. See the Universal Routing 8.1 Reference Manual for additional details on this option.
- The automatic_attach option by default becomes false. The purpose of this is to reduce network traffic by limiting the amount of attached data. See the Universal Routing 8.1 Reference Manual for additional details on this option. Genesys recommends that this new default value is not modified.
Reducing Network Traffic
- URS, by default, does not register on Routing Points that are not loaded. As a result, every instance of URS is isolated from calls to which it cannot apply a strategy. The purpose of this is to reduce network traffic and assign Routing Points to different URS applications simply by loading/unloading a strategy on Routing Points.
- URS, when reporting data, does not provide information related with cost based routing (keys started with CBR). The purpose of this is to reduce network traffic by limiting the amount attached data on a call.
- URS, when reporting data, only provides information about the final target that is selected.
- URS, by default, does not register on Virtual Queues (behaves as if the transit_dn option for a Virtual Queue is set to false. The purpose of this is to reduce network traffic by eliminating Virtual Queue events to URS applications.
- Attaching user data explicitly is executed in delayed mode (behaves like the strategy function SetDelayedAttach[TRUE] is invoked). The purpose of this is to reduce network traffic which results from numerous attach data requests.